Applied Cryptography in Digital Systems

Introduction and Context

Cryptography is no longer confined to military communications or specialist banking networks. It is embedded in cloud platforms, smartphones, connected devices, payment infrastructure, blockchains, digital identity systems, software delivery pipelines and organizational transformation programmes. In each setting, cryptography supports some combination of confidentiality, integrity, authentication, accountability, privacy and non-repudiation.

Applied cryptography is concerned with using cryptographic mechanisms correctly within a larger system. A mathematically strong algorithm can still provide weak protection if keys are poorly managed, identities are not verified, encrypted data is exposed through application logs, or cryptographic controls are bypassed by insecure interfaces. Consequently, cryptographic evaluation must consider algorithms, protocols, implementation, key lifecycle, governance, usability and operational monitoring together.

This chapter examines how cryptography is applied across major digital systems. The focus is not merely on naming algorithms, but on evaluating whether a cryptographic design is appropriate for its threat model, business purpose and regulatory environment.

Learning Objectives

By the end of this chapter, you should be able to:

• explain how cryptographic goals differ across digital platforms;
• evaluate encryption, hashing, digital signatures, certificates and key-management practices;
• compare cryptographic use in cloud, mobile, IoT, payment, blockchain and identity systems;
• explain the role of cryptography in zero-trust architectures and DevSecOps;
• identify implementation, governance, privacy and compliance risks;
• analyse an applied cryptographic scenario and recommend proportionate controls;
• recognize contemporary developments, including post-quantum migration and confidential computing.

1. A Systems View of Applied Cryptography

A cryptographic control should be selected by first identifying the asset, threat, trust boundary and required security property.

Symmetric encryption uses the same secret key, or closely related secret material, for encryption and decryption. It is efficient for large volumes of data. Authenticated encryption is generally preferred because it provides confidentiality and integrity together. Examples include AES-GCM and ChaCha20-Poly1305 when used with correct nonce management.

Public-key cryptography uses a public key and a private key. Public-key encryption can provide confidentiality, while digital signatures use a private key to sign and a public key to verify. Public-key operations are usually more computationally expensive than symmetric encryption, so practical protocols commonly use public-key methods to authenticate parties or establish a symmetric session key, and then use symmetric authenticated encryption for the data stream.

A cryptographic design must distinguish encryption from encoding and hashing. Encoding, such as Base64, changes representation but provides no secrecy. A cryptographic hash maps input data to a fixed-length digest. A secure hash is designed to make it computationally infeasible to find an input producing a chosen digest, although hashing is not encryption and cannot be reversed reliably.

For an authenticated-encryption operation, a simplified abstract relationship is:

Here, K is the secret key, N is a nonce, P is plaintext, A is associated data authenticated but not encrypted, C is ciphertext and T is the authentication tag. The exact construction depends on the algorithm. The nonce must satisfy the algorithm’s uniqueness requirements; in particular, reusing a nonce with the same key can seriously compromise security for several AEAD schemes.

Threat modelling and trust boundaries

The same mechanism can have different value in different environments. Encrypting a cloud database protects against some forms of storage compromise, but may not protect data from an authorized application identity that has unrestricted read access. A mobile application may use TLS correctly but still expose secrets through screenshots, debugging logs or compromised endpoints. An IoT device may contain strong cryptography but remain vulnerable if its private key is shared across every device.

A practical evaluation asks:

1. What is being protected?
2. Who should be able to access it?
3. Where does plaintext exist?
4. How are keys generated, stored, rotated, revoked and destroyed?
5. What happens when a device, account or key is compromised?
6. Can the system produce trustworthy evidence of security events?

2. Cryptographic Building Blocks and Key Management

Encryption at rest and in transit

Data at rest includes databases, object storage, backups, disks and removable media. Data in transit includes traffic between users, services, regions and devices. Encryption at rest limits exposure if storage media or snapshots are obtained, while transport encryption protects communications against interception and alteration. Neither automatically protects data while it is being processed in plaintext.

Transport Layer Security (TLS) illustrates layered cryptographic use. A client and server negotiate supported parameters, authenticate the server through a certificate chain, establish shared secret material and use authenticated encryption for application traffic. Secure configuration requires current protocol versions, appropriate cipher suites, certificate validation, protection of private keys and removal of obsolete algorithms.

Hashing, password verification and key derivation

Passwords should not normally be encrypted for later recovery. They should be processed using a password-hashing or key-derivation function designed to resist guessing. A unique salt prevents identical passwords from producing identical stored values and makes precomputed tables less useful. A work factor, memory requirement or parallelism setting increases the cost of each guess.

A simplified password-verification model is:

The verifier V is stored with the salt and cost parameters. During login, the supplied password is processed again and compared using a suitable constant-time comparison. The expression is conceptual: a real deployment must select a standardized, well-reviewed function such as Argon2id, scrypt, bcrypt or PBKDF2 according to platform and policy requirements. The cost should be calibrated on the actual service, since excessive cost can create denial-of-service risk.

Key lifecycle management

Key management is often the decisive factor in cryptographic security. A lifecycle normally includes generation, registration, distribution, activation, use, rotation, suspension, revocation, archival and destruction.

Important practices include:

• generate keys using an approved cryptographically secure random source;
• limit key use through purpose, identity and policy controls;
• store high-value keys in a hardware security module or managed key-management service where appropriate;
• separate key-encryption keys from data-encryption keys;
• maintain audit records without logging secret key material or plaintext;
• rotate keys according to risk, exposure and algorithm requirements;
• plan recovery and emergency revocation before an incident occurs;
• test restoration of encrypted backups, including access to required keys.

Envelope encryption is widely used in cloud systems. A data-encryption key encrypts the data, while a key-encryption key protects the data-encryption key. This allows large data objects to be processed efficiently while centralizing control over higher-level keys.

3. Cloud Services

Cloud environments introduce shared responsibility and numerous machine identities. Cryptography must be evaluated across infrastructure, platform and software layers rather than treated as a single “encryption enabled” setting.

Cloud storage and databases

Cloud providers commonly offer server-side encryption for object storage, disks and managed databases. Provider-managed keys may be adequate for low-risk data, but customer-managed keys can provide stronger separation of duties, customer-controlled rotation and more detailed access policy. Highly regulated organizations may require externally controlled or dedicated key-management arrangements.

Encryption does not remove the need for authorization. If an application role can decrypt every object, a stolen role credential may still expose all plaintext. Stronger designs use least privilege, separate keys or cryptographic domains by tenant or data class, and enforce access decisions before decryption.

Key management and multi-tenancy

Cloud key-management services usually provide policy enforcement, audit logging and integration with identities. Administrators should distinguish:

• the identity authorized to request cryptographic operations;
• the service that performs the operation;
• the key policy governing permitted use;
• the data access policy governing the underlying object.

A common failure is to configure storage encryption correctly but allow broad administrative roles to disable keys, change policies or export plaintext. Key administrators, data administrators and application operators should have appropriately separated responsibilities.

Confidential computing and cloud cryptography

Confidential-computing technologies aim to protect data while it is being processed inside a hardware-protected execution environment. Attestation can provide evidence that approved code is running before secrets are released. This may reduce exposure to certain infrastructure administrators or compromised host software, but it does not solve insecure application logic, malicious authorized users or all hardware side-channel risks. It should be treated as an additional trust boundary, not a substitute for secure software design.

4. Mobile Applications

Mobile cryptography must account for lost devices, hostile networks, reverse engineering, rooted or jailbroken devices, malicious applications and insecure backups.

Transport security should use validated TLS and correct certificate verification. Certificate pinning can reduce reliance on a compromised certificate authority in some controlled applications, but it creates operational risks when certificates or keys must be changed. Pinning should not be introduced without a safe recovery strategy.

Platform secure-storage facilities can protect cryptographic keys using hardware-backed keystores or secure elements. Applications should avoid embedding long-term secrets in source code, binaries or configuration files. Obfuscation may increase attacker effort but is not a substitute for proper key protection.

Mobile applications should minimize local sensitive data, use short-lived tokens, protect refresh tokens, enforce secure logout and consider whether screenshots, clipboard contents, notifications and crash reports reveal confidential information. A local encryption key protected only by a device PIN may be vulnerable if the platform’s authentication and hardware protections are weak.

End-to-end encryption deserves careful definition. It generally means that plaintext is accessible only at communicating endpoints and not to an intermediary service. If a service can decrypt messages for search, moderation or recovery, the system may provide transport or server-side encryption rather than strict end-to-end confidentiality.

5. Internet of Things

IoT systems include constrained sensors, gateways, mobile applications, cloud services and operational technology. Their long service lives make key provisioning, update authenticity and compromise recovery especially important.

Each device should ideally have a unique identity and key pair. Shared factory passwords and one global private key create systemic failure: compromise of one device can enable impersonation of all devices. Secure boot verifies that only authorized firmware executes. Digitally signed updates provide authenticity and integrity, but update systems also need rollback protection, availability planning and a process for revoking compromised signing keys.

Device identity may be established through certificates, pre-shared keys or hardware-rooted credentials. Certificate-based identity supports scalable rotation and revocation, but requires lifecycle infrastructure. Pre-shared keys can be simpler for constrained systems, yet become difficult to manage when devices are numerous or geographically distributed.

IoT cryptography must also consider resource constraints. Algorithms should be selected according to available processing power, memory, energy and secure-storage capability, while maintaining current security assurance. Operational technology may require carefully staged updates because availability and safety constraints can be more important than rapid patching.

6. Payment Systems

Payment systems require confidentiality, transaction integrity, strong authentication, fraud resistance and evidence suitable for dispute handling. They also operate under detailed industry and legal requirements.

Card payment systems commonly use cryptographic keys for terminal authentication, PIN protection, transaction authentication and secure communication. Hardware security modules are used in payment processors and banks to protect high-value keys and perform controlled cryptographic operations. Tokenization replaces a sensitive payment identifier with a token whose usefulness is limited by context. Tokenization is not identical to encryption: the token may have no mathematical relationship to the original value and depends on a controlled mapping service.

Digital signatures or message authentication codes can protect transaction messages. A signature is useful when independent verification and evidence about the signing key are required. A MAC is efficient when the communicating parties share a secret, but either party possessing the same secret could have generated the MAC; this affects accountability and dispute analysis.

Payment security is not achieved by cryptography alone. Secure terminals, transaction limits, fraud analytics, customer authentication, key ceremonies, tamper resistance, segregation of duties and incident response are equally significant. Cryptographic controls must also be evaluated against applicable payment-security standards and data-protection obligations.

7. Blockchain and Distributed Ledgers

Blockchains use cryptography to link records, authenticate transactions and support agreement among distributed participants. Hashes provide data fingerprints and help form chained or tree-structured commitments. Digital signatures authenticate the holder of a private key. Consensus mechanisms determine which valid transactions are accepted and in what order.

A blockchain address is not automatically a legal identity. Possession of a private key may authorize transactions, but it does not prove who controls the key in the physical world. Key loss can be permanent, and stolen keys may enable valid-looking unauthorized transactions. Hardware wallets, multi-signature arrangements, transaction policies, recovery procedures and segregation of signing authority reduce some risks.

Smart contracts illustrate the difference between cryptographic validity and business correctness. A signed transaction may be authentic and correctly recorded while invoking flawed code. Oracles introduce external data and therefore create additional trust assumptions. Immutability can preserve fraudulent or erroneous information as effectively as legitimate information, so governance and correction mechanisms remain necessary.

Public ledgers may conflict with privacy and deletion requirements because replicated data is difficult to remove. Storing only commitments, pointers or selectively disclosed attributes on-chain may reduce exposure, but metadata can still reveal relationships and activity patterns.

8. Digital Identity and Zero-Trust Architectures

Digital identity systems bind people, organizations, devices or services to credentials and authorization decisions. Public-key infrastructure uses certificates, certificate authorities, registration processes, revocation and trust stores. Identity assurance depends on the quality of enrolment and recovery, not solely on the cryptographic key.

Modern identity architectures often combine asymmetric cryptography, hardware-backed credentials, multifactor authentication and signed tokens. A signed token can provide integrity and issuer authentication, but its safe use also requires audience validation, expiry checking, scope restrictions, secure storage and revocation or short lifetimes. Encryption may be necessary when token contents are confidential; a signature alone does not hide claims.

Zero trust is a security architecture in which access is continuously evaluated rather than granted solely because a user or device is inside a network perimeter. Cryptography supports zero trust by enabling mutual TLS, device certificates, signed workload identities, protected service-to-service communication and verifiable policy evidence. It does not replace policy: a valid certificate proves possession of a credential, not that access to a particular resource is appropriate at a particular time.

A useful decision model combines identity, device posture, requested resource, context and policy. Short-lived credentials reduce the value of stolen secrets. Workload identity systems can issue credentials dynamically, but their control planes become critical assets and must themselves be protected and monitored.

9. DevSecOps and Software Supply Chains

DevSecOps integrates security into development, testing, deployment and operations. Cryptography contributes through signed commits, protected secrets, secure package repositories, artifact signing, provenance metadata, encrypted pipelines and verified deployment identities.

Build artifacts should be signed using keys protected from ordinary build processes. Verification must occur at deployment, not only during a manual release review. A signature confirms that an artifact corresponds to a signing key; it does not prove that the source code is safe. Provenance, dependency analysis, reproducible-build practices, code review and vulnerability management remain necessary.

Secrets should be retrieved at runtime from a managed secret store rather than committed to repositories or placed in container images. Rotation must be automated where feasible. CI/CD service accounts should have narrowly scoped permissions and separate credentials for development, testing and production.

Cryptographic agility is an engineering capability: systems should be able to replace algorithms, key sizes, certificates and providers without extensive redesign. This matters because algorithms may be weakened, regulations may change, and post-quantum migration may require hybrid mechanisms.

10. Digital Transformation and Governance

Digital transformation expands the number of applications, partners, APIs, devices and data flows. Cryptographic decisions should therefore be included in enterprise architecture, data classification, procurement, privacy impact assessments and business continuity planning.

A practical governance framework should define:

• approved algorithms, protocols and minimum parameters;
• data classifications and corresponding protection requirements;
• ownership of keys, certificates and cryptographic services;
• separation of duties and approval for high-risk key operations;
• retention, destruction and legal-hold procedures;
• audit, monitoring and incident-reporting requirements;
• vendor and supply-chain assurance;
• migration plans for deprecated and quantum-vulnerable algorithms.

Privacy by design may require minimizing collection, encrypting sensitive fields, separating identifiers from attributes and using pseudonymous or selective-disclosure credentials. Cryptography can reduce exposure but cannot make unlawful or excessive data collection acceptable.

Artificial intelligence systems create additional cryptographic concerns. Training data, model weights, prompts and outputs may require protection in transit, at rest and during collaboration. Signed models and provenance records can help establish origin and integrity. However, a signature does not establish that a model is unbiased, safe or appropriate. Confidential-computing approaches may protect model inputs during processing, but performance, side-channel and verification limitations must be assessed.

11. Applied Case: Multi-Platform Health Service

Background

This illustrative case concerns a regional health provider moving from on-premises systems to a cloud platform. Clinicians use mobile applications, connected diagnostic devices send measurements, patients make payments, and external laboratories exchange records through APIs.

Problem

An initial review identifies shared device credentials, long-lived API tokens, broad cloud administrator permissions, unencrypted backups and a CI/CD pipeline containing a test secret. Management proposes “encrypting everything” but has no integrated key lifecycle or identity plan.

Analysis

The provider’s risks are not limited to network interception. A stolen device credential could impersonate many diagnostic devices. A leaked CI/CD secret could access production services. Broad decryption permissions could expose all patient records even if storage encryption is enabled. Long-lived tokens increase the impact of theft. Backups may be copied outside the primary platform and require independent recovery testing.

Approach and solution

The provider adopts the following architecture:

1. Each device receives a unique hardware-protected identity and signed firmware updates.
2. Device-to-gateway and service-to-service communication uses mutually authenticated TLS.
3. Cloud storage uses envelope encryption with customer-controlled key policies and separated administrative roles.
4. Patient records are classified, access is least-privilege and particularly sensitive fields are cryptographically separated where justified.
5. Mobile refresh tokens are stored in platform secure storage and are short-lived or revocable.
6. Payment processing is delegated to a compliant provider, reducing unnecessary retention of payment data.
7. CI/CD secrets are removed from repositories and retrieved from a managed secret store.
8. Release artifacts are signed and verified before deployment.
9. Logging records identity, key operations and policy decisions without recording patient plaintext or secret material.
10. Incident playbooks include certificate revocation, key rotation, device quarantine, backup restoration and patient notification assessment.

Outcome

The resulting design reduces the blast radius of a single compromised credential, improves evidence for investigations and separates cryptographic protection from authorization decisions. It also exposes residual risks: compromised endpoint applications, insider misuse, incorrect access policy and availability failures during key-service outages. These risks require monitoring, testing and governance rather than additional encryption alone.

Learning points

The case demonstrates that applied cryptography is an ecosystem capability. The strongest algorithms cannot compensate for shared identities, uncontrolled keys, weak deployment practices or unclear responsibility. Good designs combine cryptographic mechanisms with identity assurance, least privilege, secure software engineering, resilience and accountable governance.

12. Challenges, Limitations and Best Practices

Common failure patterns

• Reusing nonces with authenticated-encryption algorithms.
• Using obsolete protocols or unsupported algorithms for compatibility.
• Treating Base64 or hashing as encryption.
• Storing encryption keys beside encrypted data without access separation.
• Embedding secrets in source code, mobile binaries or container images.
• Using one key for every tenant, device or environment.
• Failing to validate certificate chains, token audiences or signature algorithms.
• Assuming a valid signature proves that content is safe or truthful.
• Rotating keys without testing backup recovery and historical decryption requirements.
• Designing cryptography without considering denial of service, accessibility or operational recovery.

Professional evaluation checklist

A diploma-level practitioner should be able to document:

1. the protected asset and threat model;
2. the selected primitive and why it is appropriate;
3. key ownership, storage, rotation and revocation;
4. identity and authorization conditions around decryption;
5. failure behaviour and incident response;
6. compliance, privacy and retention implications;
7. testing evidence, monitoring and residual risk.

Cryptographic libraries should normally be preferred over custom implementations. Implementations must be patched, algorithms should be selected from current standards, and security testing should include negative cases such as invalid signatures, expired certificates, replayed messages, altered ciphertext and unavailable key services.

Contemporary Developments

Post-quantum cryptography addresses the possibility that sufficiently capable quantum computers could threaten widely used public-key systems. Symmetric cryptography and hash functions are affected differently from public-key schemes, but organizations should begin inventorying cryptographic dependencies, identifying data that must remain confidential for many years and designing migration paths. Hybrid approaches may combine classical and post-quantum mechanisms during transition, subject to standards and implementation guidance.

Other developments include passkeys based on public-key credentials, privacy-enhancing technologies, confidential computing, hardware-backed identity and automated certificate management. Their security depends on implementation, recovery design, interoperability and governance. New technology should be adopted because it addresses a defined risk, not because it carries a cryptographic label.

Chapter Summary

Applied cryptography protects digital systems through confidentiality, integrity, authentication, key establishment, privacy and accountability. Its effectiveness depends on the complete system: algorithms, protocols, identities, key lifecycle, authorization, implementation and governance.

Cloud services require careful separation between storage encryption, key policies and data-access permissions. Mobile systems must protect local keys, tokens and user interfaces. IoT deployments need unique device identities, secure boot and signed updates. Payment systems combine cryptographic controls with hardware security, fraud management and regulatory compliance. Blockchain systems use hashes and signatures but do not automatically provide real-world identity, privacy or correct business logic.

Digital identity and zero-trust architectures use certificates, signed credentials, mutual authentication and short-lived tokens, while still requiring policy-based authorization. DevSecOps applies signing, secret management and provenance to software supply chains. Digital transformation demands enterprise cryptographic governance, privacy-aware design, resilience and cryptographic agility. The central professional lesson is that encryption is one control within a broader security architecture, not a complete security strategy.

Key Terms

Cryptography: The discipline of protecting information using mathematical techniques.

Authenticated encryption: Encryption that provides confidentiality and integrity assurance.

Hash function: A function that produces a fixed-length digest from input data.

Digital signature: A public-key mechanism used to authenticate signed data and its signer’s key.

Message authentication code: A keyed integrity mechanism shared by communicating parties.

Nonce: A value intended for limited or single use in a cryptographic operation.

Key management: The governance and technical handling of keys throughout their lifecycle.

Envelope encryption: Encrypting data with a data key and protecting that key with another key.

Hardware security module: A specialized device that protects keys and performs controlled cryptographic operations.

Certificate: A signed binding between an identity and a public key.

Public-key infrastructure: The people, processes, policies and technologies supporting certificates and public-key trust.

Tokenization: Replacing sensitive data with a controlled token representing it.

Secure boot: A process that permits execution only of authorized startup software.

Zero trust: An architecture that continuously evaluates access rather than trusting network location.

DevSecOps: Integrating security into development, delivery and operations.

Cryptographic agility: The ability to replace cryptographic algorithms and parameters with limited redesign.

Post-quantum cryptography: Cryptography designed to resist attacks by large-scale quantum computers.

Confidential computing: Protecting data during processing through hardware-supported execution isolation.

Review Questions

Short Answer Questions

1. Why is authenticated encryption generally preferred to encryption without integrity protection?
2. What is the purpose of a salt in password verification?
3. Explain the difference between a data-encryption key and a key-encryption key.
4. Why should IoT devices have unique identities?
5. Why does a digital signature not necessarily provide confidentiality?

Long Answer Questions

1. Evaluate the cryptographic requirements of a cloud-hosted multi-tenant application.
2. Explain how cryptography supports, but does not complete, a zero-trust architecture.
3. Compare cryptographic risks in mobile applications and IoT systems.
4. Discuss the role of cryptography in a secure DevSecOps software supply chain.
5. Analyse the governance requirements for cryptographic key management in a regulated organization.

Analytical / Application Questions

1. A company encrypts its cloud database but gives every application administrator permission to decrypt every record. Analyse the residual risks and recommend improvements.
2. An IoT manufacturer uses one private signing key for all devices and stores it in a build server. Evaluate the consequences and design a safer update-signing process.
3. A payment application uses signed transaction messages but retains long-lived signing keys on employee laptops. Assess the design and propose a stronger operational model.

Multiple Choice Questions with Answers

Question 1

Which mechanism provides confidentiality and integrity together when correctly used?

A. Base64 encoding

B. Authenticated encryption

C. Plain hashing

D. Digital watermarking

Correct Answer: B. Authenticated encryption

Question 2

What is the primary purpose of a salt in password verification?

A. To make the password reversible

B. To replace the password entirely

C. To reduce the usefulness of precomputed attack tables

D. To provide network encryption

Correct Answer: C. To reduce the usefulness of precomputed attack tables

Question 3

In envelope encryption, what normally protects the data-encryption key?

A. A key-encryption key

B. A public DNS record

C. A password hint

D. A checksum

Correct Answer: A. A key-encryption key

Question 4

Why is a unique cryptographic identity important for each IoT device?

A. It eliminates the need for updates

B. It prevents all physical attacks

C. It limits the impact of one device compromise

D. It makes encryption unnecessary

Correct Answer: C. It limits the impact of one device compromise

Question 5

What does a digital signature primarily provide?

A. Confidentiality of the signed message

B. Integrity and authentication associated with a signing key

C. Guaranteed truth of the message content

D. Permanent deletion of the message

Correct Answer: B. Integrity and authentication associated with a signing key

Question 6

Which statement best describes zero trust?

A. All internal network traffic is trusted

B. Access is granted permanently after first login

C. Access is continuously evaluated using identity, context and policy

D. Encryption is unnecessary inside the organization

Correct Answer: C. Access is continuously evaluated using identity, context and policy

Question 7

What is a major risk of reusing a nonce with the same key in some authenticated-encryption schemes?

A. It can seriously weaken confidentiality and integrity

B. It automatically increases key strength

C. It prevents all decryption

D. It converts ciphertext into a certificate

Correct Answer: A. It can seriously weaken confidentiality and integrity

Question 8

Which practice is most appropriate for protecting high-value cryptographic keys?

A. Embedding them in public source code

B. Storing them in ordinary application logs

C. Using a hardware security module or managed key service where appropriate

D. Using one shared key for all environments

Correct Answer: C. Using a hardware security module or managed key service where appropriate

Question 9

What does signing a software artifact establish most directly?

A. That the software is free of vulnerabilities

B. That the artifact is associated with the signing key

C. That the software is legally compliant

D. That the source code contains no malicious logic

Correct Answer: B. That the artifact is associated with the signing key

Question 10

Why is cryptographic agility important?

A. It allows systems to avoid all authentication

B. It enables replacement of algorithms and parameters as requirements change

C. It guarantees that keys never need rotation

D. It removes the need for security testing

Correct Answer: B. It enables replacement of algorithms and parameters as requirements change