Key Release: The Final Gate
Everything you've learned so far — attestation, reproducibility, measurement chains, binding — converges on a single moment: the point where secrets get released.
A Key Broker Service (KBS) or Key Management Service (KMS) evaluates the attestation evidence and decides: does this workload deserve these secrets? The K dimension of the KRAB model measures how strictly that gate enforces what it should.
Why this is the payoff
Without key release, attestation is an academic exercise. You can measure, quote, verify, and bind — but if the signing key, database credential, or encryption seed is available to anyone who asks, none of it matters.
The entire point of confidential computing in practice is this: release sensitive material only to workloads that prove they are exactly what they claim to be, running on hardware you trust, in a session you can verify.
Every other dimension feeds this one.
The K levels
| Level | Name | What it means |
|---|---|---|
| K0 | Credential-Gated | Secrets released via API keys, IAM policies, network location, or operator approval. No attestation checked. |
| K1 | Signature-Bound | The service verifies a hardware quote, but the release policy is anchored to a developer signature or certificate — not an exact artifact identity. K1 is capped at R2 trust regardless of the underlying binary's actual R-grade — a compromised maintainer key collapses the claim to R1. |
| K2 | Provider-Delegated | The system relies on the CSP's internal attestation engine to gate release (e.g., AWS KMS with RecipientAttestation). Useful, but trust is delegated to the provider's opaque verifier. |
| K3 | Artifact-Bound | The service independently verifies the quote and enforces exact artifact measurements (PCR0, MRTD, deterministic binary hashes). Supports R4 verification — but doesn't check session binding. |
| K4 | Dynamically-Bound / Full Enforcement | Verifies exact artifact measurements and the dynamic session binding in reportdata. Secrets released only to the exact session requesting them. |
K0 — the default everywhere
K0 is how most systems release secrets today, even "confidential" ones. An IAM role, a network policy, a static API key. The TEE might be running, attestation might be available, but nobody checks it before handing over the keys.
If your KMS is K0, your TEE is decoration.
K1 — trusting the developer
K1 checks attestation, but the policy is bound to a developer's signing key rather than an exact binary identity. "Release secrets to anything signed by this key." This works — until the key is compromised, at which point any binary signed with it gets secrets.
K1 is capped at R2 trust regardless of the underlying binary's actual R-grade. Even if your binary is deterministically reproducible (R4), K1 policy can only verify the maintainer's signature — not the binary hash itself. A compromised maintainer key collapses the verification claim to R1.
K2 — trusting the provider
K2 delegates attestation verification to the CSP. AWS KMS with RecipientAttestation is the canonical example: AWS verifies the Nitro enclave's measurements before releasing the key. The verification is real, but it happens inside the provider's black box. You cannot audit the verification logic or the policy engine independently. You trust AWS to enforce what they say they enforce.
For many teams, this is fine. AWS's incentive to maintain the integrity of their attestation pipeline is strong. But it's a trust delegation — not independent verification.
K3 — trusting the artifact
K3 is where things get rigorous. The KBS independently verifies the hardware quote, checks the silicon vendor's certificate chain, and enforces exact measurement values: "release this secret only if MRTD matches this hash, RTMR[1] matches this value, and the firmware registers match these expected measurements."
This supports R4 verification — if the binary is deterministically reproducible, the KBS can enforce the exact expected hash. But K3 has a blind spot: it doesn't verify reportdata. It knows the right binary is running, but it can't prove this session is the one talking to it. A man-in-the-middle could redirect the secret.
K4 — trusting nothing but the evidence
K4 is K3 plus session binding enforcement. The KBS checks artifact measurements and the dynamic reportdata payload. Secrets are released only when:
- The quote is valid and signed by the silicon vendor
- All artifact measurements match the expected values
- The
reportdatacontains the exact session identity the verifier expects
This closes the MITM gap. The secret goes to the right binary, in the right environment, in the right session.
KMS/KBS patterns in practice
Different K levels correspond to different deployment patterns:
| Pattern | Typical K level | Who's verifying |
|---|---|---|
| Cloud-native (Azure MAA + AKV, GCP Confidential Space) | K2 | The CSP |
| Trustee KBS (CoCo/Kata ecosystem) | K3-K4 | Your own infrastructure |
| Decentralized KMS (Phala, dstack) | K3-K4 | Network of verifiers |
| Custom attestation-aware KBS | K3-K4 | You |
The higher you go on K, the more infrastructure you own and operate. K2 is turnkey. K4 requires you to run and maintain the verification pipeline yourself (or trust a decentralized network to do it).
The alignment equation
For full dynamic security — resistant to MITM and attestation replay — three dimensions must align:
- A3 — direct, non-mediated quoting path (smallest platform TCB)
- B2 — fresh session identity in the quote
- K4 — full enforcement of both artifacts and session binding
If A drops to A2, the CSP's paravisor is in the trust path. If B drops to B0/B1, session identity is weak or absent. If K drops to K3, the right binary gets the secret but possibly in the wrong session.
A system on an A2 platform (like Azure TDX) can technically achieve B2 and K4, but it does so by extending its trust boundary to include the CSP's paravisor. Only A3 achieves this alignment with a pure silicon root of trust.
Instance identity vs. session binding
Some platforms expose launch identity fields such as TDX HOSTDATA. These are distinct from dynamic session binding:
- Session binding ties a live session to a quote — it proves this request came from the attested workload.
- Instance identity distinguishes one launched workload instance from another — it proves which launch this is.
A strong K policy should use both. Session binding prevents MITM within a running instance; instance identity prevents confusion between different launches of the same workload image.
K2 is not weak — but it means you are trusting the CSP to verify attestation correctly. If your threat model includes "the CSP might act against us," K2 is insufficient. If the CSP is explicitly trusted, K2 can be the right pragmatic choice.
Check your current secret injection path. If secrets are released via IAM, network policy, or operator action without checking an attestation quote, you're at K0 — regardless of whether the workload runs on a TEE. The TEE is only earning its keep when the key release path enforces it.