Secure Provisioning

The provisioning service acts as a relying party, releasing secrets only after validating a hardware-signed attestation report. This report proves the enclave is running a specific, unmodified code hash on genuine hardware. No attestation, no secrets.

• Verifies enclave identity via cryptographic measurement
• Binds secrets to a specific code version and security patch level
• Prevents secrets from being delivered to a compromised or simulated environment

Before any secret is transmitted, a mutually authenticated, encrypted channel is established between the provisioning service and the enclave. This often uses Enclave TLS, where the TLS termination point is inside the TEE, not the host OS.

• Prevents man-in-the-middle attacks by the host or hypervisor
• Ensures end-to-end encryption from key source to protected memory
• Binds the session to the attested enclave identity

Secrets received by the enclave are often sealed to disk for persistence across reboots. Sealing encrypts data using a key derived from the enclave's identity and the platform's hardware root of trust, ensuring the data can only be decrypted by the exact same enclave on the exact same hardware.

• Prevents offline decryption of persisted secrets
• Binds data to a specific platform instance
• Protects against cloning attacks on stored state

Long-lived static credentials are avoided. The provisioning service generates ephemeral, short-lived tokens or dynamically retrieves secrets from a Key Management Service (KMS) at the moment of enclave initialization. This minimizes the window of exposure if a secret is ever compromised.

• Eliminates hard-coded secrets in images
• Integrates with cloud-native secret stores like HashiCorp Vault
• Supports automatic credential rotation without enclave rebuilds

The provisioning process verifies the entire software supply chain, not just the final enclave binary. This includes validating signatures on the bootloader, operating system components, and all libraries loaded into the TEE. Measured Boot extends the chain of trust from silicon to application.

• Validates every link in the software supply chain
• Detects tampering in build pipelines or dependency poisoning
• Provides a verifiable provenance record for auditors

The provisioning service enforces fine-grained policies dictating which secrets an enclave can access based on its attested attributes. Policies may consider the code version, security patch level, geolocation, or hardware generation. This prevents a development enclave from accessing production credentials.

• Attribute-Based Access Control (ABAC) for TEEs
• Prevents privilege escalation across environments
• Enables staged rollout of secrets to canary deployments

The isolated compute sanctuary where provisioning targets. A TEE is a hardware-enforced memory region that isolates code and data from the host OS, hypervisor, and DMA attacks. Key capabilities:

• Memory encryption transparently protects data in use
• Sealing binds secrets to a specific enclave identity
• Attestation proves integrity to remote parties

Intel SGX, AMD SEV-SNP, and AWS Nitro Enclaves are common implementations.

The mechanism that binds provisioned secrets to a specific TEE instance. Data encrypted via sealing can only be decrypted by the exact same enclave on the exact same hardware. Two sealing policies exist:

• MRENCLAVE: Binds to the enclave's code identity (version-locked)
• MRSIGNER: Binds to the enclave author's signing key (allows updates)

This ensures a stolen disk image yields no usable secrets.

The immutable foundation upon which all attestation chains are built. This is a physically unclonable identity fused into the silicon during manufacturing. It anchors the chain of trust:

• The root key signs the firmware measurement
• Firmware measures the bootloader
• Bootloader measures the TEE
• TEE attests to the application

A single compromise at any link breaks the entire chain.

The external system that holds secrets until attestation succeeds. A KMS integrates with attestation verification to implement conditional release:

1. Enclave generates an attestation report
2. KMS verifies the report against a policy
3. KMS releases keys only if the enclave identity matches

Cloud-native examples include AWS KMS with Nitro Enclaves and Azure Key Vault with confidential VMs.

Extends trust verification beyond the TEE to the entire software delivery pipeline. Supply chain attestation cryptographically proves:

• The source code repository and commit hash
• The CI/CD pipeline that built the artifact
• Every dependency's integrity (via SBOM)
• The container image digest deployed to the enclave

This ensures the provisioned code hasn't been tampered with from development to deployment.