Private Inference

The foundational property of private inference is bidirectional isolation. The model owner's proprietary weights and architecture are never exposed to the client, while the client's sensitive input data remains opaque to the model server and infrastructure operator.

• Model Protection: Weights and architecture are decrypted only inside a hardware-enforced enclave
• Input Privacy: Client data is encrypted end-to-end, often using transport layer security plus enclave-specific key derivation
• Operator Blindness: Even the cloud provider or system administrator with root access cannot inspect the data in use

Private inference relies on a physically immutable, tamper-resistant hardware module that anchors the entire security chain. This root of trust underpins secure boot, cryptographic key generation, and the attestation process that proves the enclave's identity to remote clients.

• The root of trust is burned into silicon during manufacturing and cannot be altered by software
• It generates and protects the endorsement keys unique to each processor
• All subsequent trust derivations—measurements, attestation reports, and sealing keys—chain back to this physical anchor

Before a client sends sensitive data, the enclave must execute a remote attestation handshake. This cryptographic ceremony proves three things to the relying party:

• Identity: The enclave is running on genuine hardware with a valid Trusted Execution Environment
• Integrity: The exact code and configuration loaded matches an approved MRENCLAVE or MRSIGNER measurement
• Freshness: The attestation report includes a nonce or timestamp to prevent replay attacks

The client verifies this report against a trusted attestation service before provisioning decryption keys.

Private inference closes the data-in-use vulnerability gap. While traditional security protects data at rest (disk encryption) and in transit (TLS), the model and input remain encrypted even when loaded into RAM for active computation.

• Transparent Encryption: Memory controllers automatically encrypt and integrity-protect data moving between the processor and RAM
• Enclave Page Cache: Dedicated encrypted memory region inaccessible to the operating system, hypervisor, or DMA attacks
• Integrity Protection: Cryptographic hashes prevent an attacker from silently modifying memory contents or replaying stale data

The enclave exposes a minimal, well-defined attack surface through controlled entry and exit points. All communication between the trusted and untrusted execution environments must pass through these gates.

• ECALLs: Controlled entry points allowing untrusted code to invoke trusted functions inside the enclave
• OCALLs: Controlled exits enabling the enclave to make necessary system calls to the untrusted host
• Interface Validation: All parameters crossing the boundary are rigorously sanitized to prevent pointer manipulation and confused deputy attacks
• The enclave treats all external data as malicious by default, validating inputs before any processing

Enclaves are stateless by design—their memory is destroyed when the enclave terminates. Data sealing cryptographically binds persistent data to a specific enclave's identity, allowing secure storage across sessions.

• Seal Key Derivation: A unique encryption key is derived from the enclave's measurement and the processor's root key
• Identity Binding: Sealed data can only be unsealed by the exact same enclave on the exact same platform (or by enclaves signed by the same authority, depending on sealing policy)
• Version Rollback Protection: Security version numbers prevent an attacker from restoring old, vulnerable data to a patched enclave

The cryptographic handshake that establishes trust between a client and a remote TEE before any inference data is transmitted. The enclave generates a signed report proving its identity, code hash, and security posture.

• MRENCLAVE Verification: The client checks that the enclave's code hash matches the expected inference service binary
• Freshness Guarantee: Attestation reports include nonces to prevent replay attacks
• DCAP Infrastructure: Intel's Data Center Attestation Primitives enable scalable, third-party verification without relying on Intel's cloud service

Techniques that ensure a model's intellectual property remains encrypted at all times except during active computation inside the TEE. The model is provisioned to the enclave over a secure channel established after successful attestation.

• Encrypted Model Distribution: Weights are transmitted in ciphertext and decrypted only within the enclave
• Data Sealing: Models can be persisted to untrusted storage encrypted with keys bound to the specific enclave's identity
• Anti-Extraction: Hardware memory encryption prevents model theft even with physical access to the server

Mitigations against attacks that infer secrets from physical leakage—timing variations, power consumption, or cache access patterns—rather than breaking cryptographic primitives directly.

• Constant-Time Cryptography: Algorithms designed to execute in identical cycles regardless of input values
• Cache Partitioning: Hardware features like Intel CAT isolate enclave cache lines from untrusted processes
• Speculative Execution Barriers: Microcode patches that prevent Spectre-class attacks from leaking enclave data

The broader paradigm applying Confidential Computing to machine learning workloads end-to-end. Private inference is one component; Confidential AI also encompasses secure training, federated aggregation, and multi-party model evaluation.

• Training Protection: Training data and gradients remain encrypted during computation
• Multi-Party Collaboration: Multiple organizations can jointly train models without revealing proprietary datasets
• Regulatory Compliance: Hardware-backed data-in-use protection satisfies GDPR and HIPAA data processing requirements

A cryptographic hash of the enclave's initial state—code, data, stack, and configuration—that serves as an unforgeable fingerprint. During attestation, the client compares this measurement against a known-good reference value.

• MRENCLAVE: Identifies the exact binary version running inside the enclave
• MRSIGNER: Identifies the software vendor's signing identity, enabling trust based on the publisher rather than a specific build
• Reproducible Builds: Deterministic compilation ensures the same source code produces identical measurements across builds