Secure Boot, Attestation, and Key Management
This domain tests the chain from an immutable root of trust to a running workload, and how keys are bound to that chain. Questions often ask what a given mechanism proves, and what it does not.
Boot integrity
- Secure boot verifies signatures at each stage: boot ROM verifies the first-stage bootloader against a public key hash fused in OTP, which verifies the next stage, and so on. It enforces an image; it does not produce evidence about later runtime state.
- Measured boot records hashes into a TPM PCR or a DICE CDI chain. Measurement is evidence, not enforcement; the verifier decides whether the values are acceptable.
- A root of trust must be immutable and updateable only through an authenticated, anti-rollback path. Debug unlock and test modes are common bypasses; check lifecycle state.
Attestation
- Remote attestation has four roles: attester (the TEE), verifier, relying party, and endorsements. Evidence is signed by a hardware-rooted key; the verifier checks the signature chain, reference values, freshness via a nonce, and policy.
- Standards: IETF RATS (RFC 9334) architecture and EAT (RFC 9397) token format; platform formats include SGX quotes, SEV-SNP reports, and PSA attestation tokens. Local attestation proves identity to another enclave on the same platform.
Key management
- Derive keys from a hardware unique key or sealing key, bind them to measurements such as MRENCLAVE or to signer identity such as MRSIGNER, and wrap them for storage. Use a KMS or HSM for release policies, rotation, and revocation.
- Sealing protects data at rest; it does not protect data in use from a compromised TA.
Worked example
A KMS releases a disk-unwrap key only to an approved enclave. The enclave requests a quote with a 32-byte nonce from the KMS. The verifier checks the quote signature against Intel's root, the nonce, MRENCLAVE against the allowlist, and the TCB level. Only then does the KMS wrap the key to the enclave's ephemeral public key. If the nonce is reused or not checked, a replay gives an attacker a stale quote for an old, vulnerable build.
Traps
- Saying secure boot proves runtime integrity.
- Skipping nonce and freshness checks.
- Binding to MRENCLAVE when the policy meant any build by this signer.
- Forgetting TCB recovery: accepting revoked microcode in attestation is a vulnerability.