Enclave Architecture

A guide to the hardware-isolated secure enclave — the trusted execution environment that processes sensitive data without exposing it to the broader server infrastructure.

What Is An Enclave?

An enclave is a hardware-isolated execution environment that runs on the server but is completely separated from the OS and all other software — with its own dedicated memory, its own processor context, no direct network access, and no persistent storage. Server operators cannot inspect or tamper with its internals; the CPU enforces the isolation.

The enclave performs operations that require temporary access to decrypted data: document processing, verification, search index generation, key derivation, and audit log management. These operations happen in a sealed environment where plaintext data exists only in memory for the duration of the operation and is never written to persistent storage.

The Trust Boundary

The architecture draws a clear trust boundary between two zones:

Components outside the enclave — the API layer, the database, the storage system — handle ciphertext, wrapped keys, blind tokens, and operational metadata. They cannot interpret sensitive content or recover encryption keys.

The enclave is the only server-side component that ever sees plaintext document content. And even the enclave holds plaintext only transiently — in memory, for the duration of a single operation.

What Happens Inside The Enclave

The enclave is responsible for every operation that requires access to sensitive data:

• Document processing — Decrypting uploaded documents, extracting text via OCR, generating verification seals, and re-encrypting results for storage
• Key derivation — Creating and managing organization-level encryption keys, member keys, and data keys. All key material is generated or unwrapped inside the enclave and never leaves in plaintext
• Search index generation — Producing blind index tokens from document content. These tokens allow encrypted search without revealing what you searched for or what your documents contain
• Blind token computation — Deriving one-way HMAC tokens (ownership, membership, document, and grant tokens) from entity and user keys inside the enclave. These tokens replace plaintext identifiers in tokenized tables
• Verification — Processing identity documents and proof-of-address documents to produce verification seals
• Audit log management — Encrypting audit entries and maintaining a cryptographic chain that makes tampering detectable

Every one of these operations follows the same pattern: encrypted data enters the enclave, is processed in isolated memory, and encrypted results exit. No sensitive plaintext crosses the trust boundary.

What Happens Outside The Enclave

The components outside the enclave handle everything that does not require access to plaintext:

• API layer — Authenticates requests, enforces rate limits, and routes operations to the enclave. The API layer never decrypts sensitive content — it passes encrypted payloads through unchanged
• Database — Stores encrypted documents, wrapped keys, blind index tokens, and operational metadata. A full database dump would reveal no sensitive content or relationship associations in the tokenized tables
• Storage — Holds encrypted blobs. The storage layer has no knowledge of what it stores
• Parent host — Manages the enclave lifecycle and proxies communication between the enclave and external services. The parent host cannot read the encrypted payloads it proxies — it sees only encrypted bytes for sensitive content, though it does see operational identifiers in the current vsock protocol

This separation means that compromising any component outside the enclave — even gaining full administrative access to the server — does not expose document content, encryption keys, or the contents of sensitive metadata.

Attestation: Proving Enclave Identity

Attestation gates enclave access to encryption keys. Before the key management service releases any key material, the enclave must prove its identity through a hardware-signed cryptographic proof embedded in the request.

The proof certifies:

1. Code integrity — A measurement (cryptographic hash) of the exact running code. If even one byte changes, the measurement changes, and the key management service rejects the request
2. Hardware authenticity — The code is executing inside a genuine hardware-isolated enclave, not a simulation or emulator
3. No tampering — The CPU itself signs the attestation document. This signature cannot be forged by software

Think of it as a tamper-evident seal on a ballot box: a fingerprint of the contents (code integrity), a statement the box is genuine hardware (authenticity), and a manufacturer's signature only the hardware can produce. The key management service checks this seal on every key request — there is no "remember me."

How Attestation Protects Your Keys

Platform master keys — the keys that protect organization secrets and enable document processing — are managed by a hardware security module that enforces attestation-based access policies.

The access policy works like this:

1. The enclave generates a fresh attestation document and includes it with its key request
2. The key management service verifies the attestation: Is the measurement correct? Is the hardware genuine? Is the enclave untampered?
3. Only if all checks pass, the key management service releases the requested key material — encrypted specifically to the requesting enclave's ephemeral public key
4. If any check fails, the request is denied. No key material is released

This means:

• A modified enclave (with altered code) cannot pass attestation and therefore cannot access any keys
• A fake enclave (software pretending to be an enclave) cannot produce a valid hardware-signed attestation document
• A replayed attestation from a previous session is rejected because each attestation includes fresh, session-specific data

Attestation is not a policy decision that can be overridden — it is a cryptographic guarantee enforced by hardware.

The Communication Model

The enclave has no direct network access. It cannot make HTTP requests, resolve DNS, or open sockets to the outside world. All communication flows through narrow channels to the parent host.

This design limits the enclave's attack surface:

• Inbound — The enclave receives requests from the parent host over a dedicated internal channel. Sensitive payloads are encrypted and only the enclave can decrypt them
• Outbound — When the enclave needs to call an external service (such as the OCR provider or identity verification service), the request is tunneled through the parent host over a vsock-proxy TLS channel. The parent acts as a transparent relay — it forwards encrypted bytes without the ability to read or modify them. The enclave establishes its own end-to-end encrypted session with the external service, so the parent never sees the plaintext traffic
• Key requests — Requests to the key management service include attestation documents and are fulfilled only after hardware-level verification

This architecture ensures that even if the parent host were fully compromised, an attacker could not extract sensitive plaintext from the communication channel.

No Persistent State

The enclave maintains no persistent storage — no disk, filesystem, or database. All data is volatile RAM that exists only for the duration of a single operation.

Think of it like a scratch pad: every reboot erases everything. On startup, the enclave regenerates ephemeral keys and re-proves its identity through attestation before any key operation.

Security implication: There is no "enclave database" to steal, no cached keys to extract, and no residual data from previous operations. Each operation starts from a clean slate.

Tamper-Evident Processing

Documents that complete enclave processing receive a verification seal — a cryptographic proof that:

• The document was processed by a genuine, attested enclave
• The processing result has not been altered since it was created
• The seal is bound to the specific document and cannot be transferred or reused

Verification seals are signed using a platform key that is accessible only after passing attestation. A commitment hash of the seal payload is stored alongside the document, allowing independent verification that the seal exists and is authentic — without revealing the seal's contents. The seal fields are populated when the processing pipeline completes verification; they remain null for documents that do not reach that path.

The enclave also maintains a tamper-evident audit trail for authentication and administrative events. Each audit entry is encrypted inside the enclave and cryptographically chained to the previous entry. Deleting or modifying a single entry would break the chain, making tampering immediately detectable.

What The Enclave Cannot Do

The enclave's power is deliberately limited:

• It cannot access the network directly. All external communication is proxied through the parent host
• It cannot store data persistently. Everything in memory is lost on reboot
• It cannot be inspected by operators. Server administrators cannot attach debuggers, read memory, or observe operations inside the enclave
• It cannot operate without attestation. No key access is possible without passing hardware-level identity verification
• It cannot be silently replaced. Swapping the enclave software would change the attestation measurement, causing all key requests to fail

These constraints are enforced by the hardware, not by software policy. They cannot be overridden by configuration changes or administrative access.

Summary

The enclave architecture provides a hardware-enforced trust boundary between the server infrastructure and sensitive data processing: