Enclave TLS

Unlike standard TLS where the private key and decrypted session data reside in OS-managed memory, Enclave TLS binds the TLS session key to the enclave's identity. The private key is sealed to the specific TEE and is never exposed in plaintext to the host. Decryption occurs exclusively within the encrypted memory pages of the enclave, protecting against memory scraping by a compromised kernel.

The TLS handshake is augmented with a remote attestation step. The enclave generates a cryptographically signed report (quote) containing a hash of its initial state and the ephemeral public key. The client verifies this quote against the hardware vendor's attestation service before completing the handshake, establishing a channel bound not just to a domain name, but to a specific, verifiable code identity running on genuine hardware.

Standard TLS is vulnerable to a compromised host OS intercepting traffic before encryption or after decryption. Enclave TLS eliminates this attack surface. The TLS endpoint is the enclave itself, not a local proxy.

• No OS visibility: The host network stack only sees ciphertext.
• No hypervisor access: Even a malicious cloud administrator cannot extract session keys from the encrypted memory regions.
• Integrity guarantee: The attested channel ensures the client is talking directly to the intended application logic, not an impostor.

Enclave TLS enables a stronger form of mutual authentication. The server proves its identity not just with a certificate, but with a hardware-backed attestation report. This creates a cryptographic binding between the TLS session and the specific enclave instance. The client can be assured that the private key is under the exclusive control of the attested software, preventing certificate theft from the host file system.

Enclave TLS is typically implemented as a drop-in replacement for standard TLS libraries, requiring minimal application changes. Frameworks like RATS-TLS (Remote ATtestation procedureS) integrate the attestation extension directly into the TLS handshake. The application calls familiar APIs, while the underlying library handles enclave quote generation, verification, and session key binding transparently.

In machine learning deployments, Enclave TLS secures the path between the client and a model running inside a TEE. The user's inference query is encrypted from the client application until it reaches the model inside the enclave. This ensures:

• Query confidentiality: The prompt or input data is never visible to the cloud provider.
• Model weight protection: The model's response is encrypted within the same attested channel, preventing extraction of proprietary weights through traffic analysis.

The Trusted Computing Base is the set of all hardware, firmware, and software components critical to security. A core goal of Enclave TLS is to radically shrink the TCB on the server side. By terminating TLS inside an enclave, the host OS, hypervisor, and cloud provider are excluded from the TCB for data-in-use. A smaller TCB means fewer potential vulnerabilities and a simpler audit surface. The TCB for an Enclave TLS endpoint typically includes only the CPU package, the enclave code, and the TLS library compiled into it.

Once an Enclave TLS session decrypts data, the enclave often needs to store it securely for later processing. Sealing is the TEE operation that encrypts data and binds it to a specific enclave identity on a specific platform. The sealed blob can be safely written to untrusted storage because only the exact same enclave code on the exact same CPU can unseal it. This ensures that session keys or decrypted payloads persisted to disk remain confidential and tamper-proof, extending the protection boundary beyond the lifetime of the TLS session.

A critical threat that Enclave TLS implementations must mitigate. Side-channel attacks infer secrets by observing physical characteristics like execution timing, memory access patterns, or power consumption rather than breaking cryptography. For TLS inside a TEE, attackers with OS-level control can observe page faults or cache timings to leak keys. Defenses include:

• Constant-time cryptographic code to eliminate timing leaks
• Data-oblivious algorithms that access memory in patterns independent of secrets
• Hardware mitigations like Intel's microcode updates against specific cache attacks

The primary application domain driving Enclave TLS adoption. Confidential AI applies TEE isolation to machine learning workloads, ensuring model weights and inference data remain encrypted during computation. Enclave TLS is the critical transport layer: a client sends a prompt or query over an attested TLS channel directly into a GPU-connected enclave. The model processes the data, and the response is encrypted before leaving the TEE. This guarantees the cloud provider never sees proprietary model weights or sensitive user queries in plaintext.