10.2 Cloud Cryptography: Data at Rest, In Transit (TLS 1.3) & In Use (Confidential Computing)

10.2 Cloud Cryptography: Data at Rest, In Transit (TLS 1.3) & In Use (Confidential Computing)

Quick Answer: Cryptographic defense in cloud environments spans three distinct operational states: Data in Transit, Data at Rest, and Data in Use. For transit security, TLS 1.3 (RFC 8446) reduces latency to a 1-RTT handshake, deprecates broken primitives (static RSA, CBC ciphers), mandates Perfect Forward Secrecy (PFS) via Ephemeral Diffie-Hellman (ECDHE), and restricts ciphers to AEAD algorithms; however, its 0-RTT Early Data feature introduces replay risks that require strict application safeguards. For rest security, organizations balance Server-Side Encryption (SSE) against Client-Side Encryption (CSE), utilizing Envelope Encryption (encrypting data with a Data Encryption Key [DEK] and wrapping the DEK with a Key Encryption Key [KEK]) to eliminate KMS throughput bottlenecks. For use security, Confidential Computing leverages hardware-based Trusted Execution Environments (TEEs) (such as AMD SEV-SNP, Intel SGX/TDX, and AWS Nitro Enclaves) with memory encryption and remote cryptographic attestation to shield data in memory from hypervisors and host compromises.

Cryptography is the primary mathematical mechanism that enables cloud multi-tenancy. When an enterprise transitions workloads from dedicated physical servers to shared cloud infrastructure, it relinquishes physical control of the hardware. Cryptographic safeguards establish logical boundaries, ensuring that unauthorized tenants, malicious actors, and the cloud service provider itself cannot inspect, modify, or compromise corporate assets.

The Cloud Security Alliance (CSA) Security Guidance v5 (Domain 9: Data Security) and CCM v4.1 (Domain CEK: Cryptography, Encryption & Key Management) categorize cryptographic protections into three operational states:

1. Data in Transit: Data traversing network paths between clients and cloud endpoints, between cloud regions, or between microservices.
2. Data at Rest: Data stored persistently on digital media (object stores, block devices, tape archives, databases).
3. Data in Use: Data loaded into volatile memory (RAM, CPU registers, caches) during active execution and processing.

---

Data in Transit: TLS 1.3 Specifications & Network Overlays

Securing data in transit requires protecting network payloads against eavesdropping, tampering, man-in-the-middle (MitM) interception, and session hijacking.

The Architectural Evolution to TLS 1.3 (RFC 8446)

The Internet Engineering Task Force (IETF) standardized TLS 1.3 in August 2018 (RFC 8446). TLS 1.3 represents a ground-up cryptographic redesign compared to TLS 1.2, focusing on performance, latency reduction, and the total eradication of vulnerable legacy cryptographic algorithms.

┌────────────────────────────────────────────────────────────────────────┐
│                     TLS 1.2 VS. TLS 1.3 HANDSHAKE                      │
├────────────────────────────────────────────────────────────────────────┤
│  TLS 1.2 HANDSHAKE (2-RTT: Two Full Round Trips)                       │
│  Client                                                      Server    │
│    │ ─── ClientHello (Supported ciphers) ──────────────────────► │     │
│    │ ◄── ServerHello, Certificate, Key Exchange Parameters ──── │     │
│    │ ─── ClientKeyExchange, [ChangeCipherSpec], Finished ─────► │     │
│    │ ◄── [ChangeCipherSpec], Finished ───────────────────────── │     │
│    │ ─── Application Data (Encrypted) ────────────────────────► │     │
├────────────────────────────────────────────────────────────────────────┤
│  TLS 1.3 HANDSHAKE (1-RTT: One Round Trip)                             │
│  Client                                                      Server    │
│    │ ─── ClientHello + ECDHE Key Share(s) + Supported Groups ─► │     │
│    │ ◄── ServerHello + ECDHE Key Share + Encrypted Certificate─ │     │
│    │     + Server Finished                                       │     │
│    │ ─── Application Data (Encrypted) ────────────────────────► │     │
└────────────────────────────────────────────────────────────────────────┘

Key Technical Enhancements in TLS 1.3

1. Latency Reduction (1-RTT Standard Handshake):
   • In TLS 1.2, establishing an encrypted session required two round trips (2-RTT) of network latency before application data could be transmitted.
   • TLS 1.3 optimizes this by having the client anticipate the server's key exchange algorithm. The client transmits its ECDHE key share directly inside the initial ClientHello message. The server responds with its key share and finished message in ServerHello. Application data can be sent immediately following this single exchange (1-RTT), cutting connection latency by 50%.
2. 0-RTT Resumption (Early Data) & Replay Attack Vulnerability:
   • TLS 1.3 allows clients that have previously connected to a server to send encrypted application data in the very first packet (ClientHello), eliminating handshake latency entirely (0-RTT).
   • The Cryptographic Vulnerability (Replay Attacks): Because 0-RTT data is transmitted before the cryptographic handshake establishes forward-secure session keys, an attacker who intercepts a 0-RTT network packet can re-transmit (replay) that packet to the server multiple times.
   • Remediation & Governance: Cloud architects must enforce strict application-layer controls: 0-RTT must only be permitted for idempotent HTTP requests (e.g., read-only GET or HEAD operations). API gateways must reject 0-RTT for state-changing, non-idempotent operations (such as financial transactions, fund transfers, POST, PUT, or DELETE API calls).
3. Mandatory Perfect Forward Secrecy (PFS):
   • TLS 1.3 completely eliminates static RSA key exchange and static Diffie-Hellman. In static RSA, if an attacker records encrypted network traffic for years and subsequently steals the server's private RSA certificate key, the attacker can retroactively decrypt all historical sessions.
   • TLS 1.3 mandates Ephemeral Diffie-Hellman (ECDHE or DHE). Unique, ephemeral key pairs are generated for every individual session and discarded immediately after session termination. Even if a server's long-term private signing key is compromised in the future, past encrypted sessions remain mathematically secure.
4. Pruning Broken Ciphers & Hashing Primitives:
   • TLS 1.3 removes all cipher modes vulnerable to padding oracle attacks (such as CBC-mode ciphers exploited by BEAST, Lucky Thirteen, and POODLE).
   • It eliminates RC4, 3DES, DES, MD5, and SHA-1.
   • It exclusively permits Authenticated Encryption with Associated Data (AEAD) cipher suites, which provide simultaneous confidentiality, integrity, and authenticity:
     • TLS_AES_256_GCM_SHA384
     • TLS_CHACHA20_POLY1305_SHA256
     • TLS_AES_128_GCM_SHA256
     • TLS_AES_128_CCM_SHA256

Mutual TLS (mTLS) for Cloud Microservices

Traditional TLS authenticates only the server to the client. In cloud-native microservice architectures (Kubernetes clusters, service meshes), systems enforce Mutual TLS (mTLS):

• Both the client and the server present cryptographically signed X.509 certificates to each other.
• Service mesh proxies (e.g., Envoy, Istio) handle certificate injection, rotation, and cryptographic verification transparently.
• Enforces Zero Trust network principles: Workload identities are attested via cryptographic frameworks like SPIFFE/SPIRE (Secure Production Identity Framework for Everyone).

Network Overlays: IPsec Tunnels & Dedicated Interconnects

• IPsec VPNs: Encapsulates and encrypts IP packets at Layer 3 using Encapsulating Security Payload (ESP) in tunnel mode, securing traffic over public internet routes.
• Dedicated Interconnects with MACsec / IPsec: While dedicated cloud links (such as AWS Direct Connect or Azure ExpressRoute) bypass the public internet, they traverse third-party physical telecommunications infrastructure. Enterprise governance mandates Layer 2 MACsec (IEEE 802.1AE) point-to-point hardware encryption or an IPsec VPN overlay on top of dedicated circuits.

---

Data at Rest: Server-Side vs. Client-Side Encryption

Data at rest refers to inactive data housed in persistent storage. Cloud architectures implement encryption at rest through two fundamental paradigms: Server-Side Encryption (SSE) and Client-Side Encryption (CSE).

The Mechanics of Envelope Encryption

Encrypting massive data files (e.g., multi-gigabyte database backups, video files, machine learning datasets) directly using a centralized Key Management Service (KMS) introduces severe architectural liabilities:

1. Network throughput bottlenecks caused by streaming gigabytes of data to KMS APIs.
2. Cloud KMS payload size limits (e.g., AWS KMS Encrypt API caps direct payload encryption at 4 KB).
3. High API latency and KMS request rate quota throttling.

To solve these challenges, cloud systems enforce Envelope Encryption (NIST SP 800-57 Part 1). Envelope encryption uses a hierarchy of keys:

• Data Encryption Key (DEK): A short-lived, symmetric cryptographic key (typically AES-256) used to encrypt a specific piece of plaintext data.
• Key Encryption Key (KEK): A durable, asymmetric or symmetric root key managed securely inside a Hardware Security Module (HSM) or KMS, used exclusively to encrypt (wrap) and decrypt (unwrap) DEKs.

┌────────────────────────────────────────────────────────────────────────┐
│                     ENVELOPE ENCRYPTION WORKFLOW                       │
├────────────────────────────────────────────────────────────────────────┤
│  ENCRYPTION WORKFLOW                                                   │
│                                                                        │
│   1. App calls KMS API: GenerateDataKey(KeyId = KEK)                   │
│          │                                                             │
│          ▼                                                             │
│   ┌──────────────┐                                                     │
│   │ Cloud KMS/HSM│ ──► Generates DEK inside HSM                        │
│   └──────┬───────┘ ──► Encrypts DEK using KEK                          │
│          │                                                             │
│          ▼ Returns two components to App:                              │
│   [Plaintext DEK]  AND  [Encrypted DEK]                                │
│          │                                                             │
│          ▼                                                             │
│   2. App encrypts Raw Data using [Plaintext DEK] (AES-256-GCM)         │
│          │                                                             │
│          ▼                                                             │
│   3. App immediately ERASES [Plaintext DEK] from volatile memory!      │
│          │                                                             │
│          ▼                                                             │
│   4. Storage commits: [Ciphertext Data] + [Encrypted DEK (Metadata)]   │
├────────────────────────────────────────────────────────────────────────┤
│  DECRYPTION WORKFLOW                                                   │
│                                                                        │
│   1. App reads [Ciphertext Data] and [Encrypted DEK] from storage      │
│   2. App sends [Encrypted DEK] to KMS API: Decrypt(EncryptedDEK)       │
│   3. KMS verifies IAM permissions, unwraps DEK using KEK inside HSM    │
│   4. KMS returns [Plaintext DEK] to App                                │
│   5. App decrypts [Ciphertext Data] using [Plaintext DEK]              │
│   6. App immediately WIPES [Plaintext DEK] from memory                 │
└────────────────────────────────────────────────────────────────────────┘

Why Envelope Encryption is Essential for Cloud Architecture

• Massive Performance & Scalability: Plaintext data never travels across the network to the KMS. Encryption occurs locally at line speed within application memory using hardware-accelerated CPU instructions (AES-NI).
• Bypasses API Limits: KMS only handles tiny cryptographic keys (typically 32 bytes for AES-256), completely avoiding payload size restrictions.
• Localized Blast Radius: Every individual object, database row, or block volume has its own unique DEK. A compromise of one DEK exposes only that single object.
• Instantaneous Cryptographic Erasure: Deleting or revoking the single KEK in KMS instantly renders millions of encrypted DEKs across petabytes of storage permanently un-decryptable.

---

Data in Use & Confidential Computing

For decades, cryptography secured data at rest (via storage encryption) and data in transit (via TLS/IPsec). However, Data in Use remained the critical missing link in cloud security. To process, query, sort, or analyze data, compute systems historically had to decrypt ciphertext into plaintext volatile memory (RAM, CPU registers, CPU caches).

The Threat Vector of Data in Use

When plaintext data resides in physical RAM, it is vulnerable to:

• Hypervisor Compromise: A threat actor or rogue cloud provider employee possessing hypervisor administrative access can execute live memory dumps of guest virtual machines.
• Host Operating System Exploitation: Kernel-level root compromises on the physical host can read VM memory pages.
• Physical Hardware Attacks: Bus snooping, cold boot attacks, or compromised server firmware (UEFI/BIOS).
• Cross-VM Side-Channel Attacks: Microarchitectural attacks (such as Spectre, Meltdown, and cache-timing attacks) that leak memory across CPU cores.

Confidential Computing: Hardware-Enforced TEEs

Confidential Computing resolves this vulnerability by encrypting data in use through hardware-based Trusted Execution Environments (TEEs). The Confidential Computing Consortium (a Linux Foundation project including Google, Microsoft, AWS, Intel, AMD, and ARM) defines Confidential Computing as: $\text{"The protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment."}$

┌────────────────────────────────────────────────────────────────────────┐
│               CONFIDENTIAL COMPUTING ARCHITECTURAL BOUNDARY            │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   PHYSICAL SERVER HOST                                                 │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │ Cloud Hypervisor / Host OS (UNTRUSTED!)                        │   │
│   │ • Cloud Provider System Admins (Blocked)                       │   │
│   │ • Hypervisor Root Exploits (Blocked)                           │   │
│   └────────────────────────────────┬───────────────────────────────┘   │
│                                    │ Cannot inspect or alter!          │
│                                    ▼                                   │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │ HARDWARE-ENFORCED TEE / CONFIDENTIAL VM                        │   │
│   │                                                                │   │
│   │   ┌───────────────────────────────────────────────────────┐    │   │
│   │   │ Guest Virtual Machine / Secure Enclave                │    │   │
│   │   │ • Customer Operating System                           │    │   │
│   │   │ • Applications & Sensitive Analytics Processing       │    │   │
│   │   └───────────────────────────┬───────────────────────────┘    │   │
│   │                               │                                │   │
│   │                               ▼                                │   │
│   │   ┌───────────────────────────────────────────────────────┐    │   │
│   │   │ HARDWARE MEMORY ENCRYPTION ENGINE (CPU Silicon)       │    │   │
│   │   │ • Keys managed exclusively by embedded Security Co-proc│    │   │
│   │   │ • Real-time AES memory line encryption/decryption     │    │   │
│   │   └───────────────────────────┬───────────────────────────┘    │   │
│   └───────────────────────────────┼────────────────────────────────┘   │
│                                   │                                    │
│                                   ▼ Plaintext NEVER exists on bus!     │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │ PHYSICAL RAM (DRAM Modules)                                    │   │
│   │ • Completely Encrypted with Ephemeral Hardware AES Keys        │   │
│   └────────────────────────────────────────────────────────────────┘   │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

Major Hardware Confidential Computing Technologies

1. AMD Secure Encrypted Virtualization (SEV, SEV-ES, SEV-SNP):
   • SEV: Encrypts the entire memory space of each VM using a unique AES encryption key managed by an isolated, on-die AMD Secure Processor. The hypervisor cannot read guest memory pages.
   • SEV-ES (Encrypted State): Encrypts all CPU register states when a VM yields control to the hypervisor, preventing register snooping.
   • SEV-SNP (Secure Nested Paging): Adds hardware-level memory integrity protection to prevent hypervisor-induced memory replay attacks, memory remapping, and memory corruption.
   • Adopted by: Google Cloud Confidential VMs, Azure Confidential VMs, AWS EC2 instances powered by AMD processors.
2. Intel Software Guard Extensions (SGX) and Trust Domain Extensions (TDX):
   • Intel SGX: Application-level enclaves. Developers refactor code into trusted and untrusted components. Sensitive logic and data run inside an isolated Enclave Page Cache (EPC). Even the guest OS kernel cannot inspect enclave memory.
   • Intel TDX: Hardware-isolated virtual machine abstraction (Trust Domains), providing VM-level confidential computing without requiring developers to rewrite application code.
3. AWS Nitro Enclaves:
   • Leverages the custom AWS Nitro Security Chip and Nitro Card hypervisor architecture.
   • Creates completely isolated, hardened compute environments with no persistent storage, no external network interface, and no interactive operator access (no SSH, no console).
   • Communicates strictly with the parent EC2 instance via a secure local virtual socket (vsock) interface.

Remote Cryptographic Attestation

A critical requirement of Confidential Computing is Cryptographic Attestation:

• Before an application or database releases sensitive data into a TEE, the TEE generates a signed cryptographic measurement (hash) of its hardware state, bootloader, firmware, and loaded code.
• This attestation document is signed by an on-die cryptographic key burnt into the CPU silicon at manufacturing.
• A remote Attestation Service or cloud KMS verifies the signature. Only when the TEE's integrity is proven will the KMS release decryption keys to unwrap data inside the enclave.

---

Implementation Pitfalls & Real-World Anti-Patterns

1. Enabling TLS 1.3 0-RTT on Non-Idempotent Financial Endpoints: Enabling 0-RTT to optimize mobile API performance without restricting it to GET requests. An attacker sniffing Wi-Fi traffic captures an encrypted 0-RTT packet representing a fund transfer API call and replays it 100 times, causing duplicate transactions.
2. Failing to Wipe Plaintext DEKs from Memory: In envelope encryption, an application decrypts a DEK, decrypts a database column, and leaves the plaintext DEK allocated on the application heap. If an attacker exploits a remote memory disclosure vulnerability (like Heartbleed) or triggers a core dump, the plaintext key is exposed. Remediation: Explicitly zeroize byte arrays containing key material immediately after use.
3. Believing Server-Side Encryption (SSE) Protects Against Stolen IAM Credentials: Relying on SSE-S3 or default SSE-KMS and assuming data is protected against compromise. If an attacker steals an administrative or service role credential with s3:GetObject and kms:Decrypt permissions, the cloud provider automatically decrypts the data upon request. SSE protects against physical and storage-layer threats, not control-plane credential compromise.
4. Confusing Storage Encryption with Confidential Computing: An architect claims that because EBS volumes are encrypted with AES-256, "data in use" is secure. Disk volume encryption only protects data when it is sitting idle on the storage controller. The moment the VM reads a block into system RAM, it is plaintext unless protected by a Confidential Computing TEE.