Attestation: Your Platform Ceiling
You've picked a TEE platform. The CPU can generate a signed statement — a quote — proving what code is running inside the enclave. That's attestation. But here's the thing most vendor docs skip: the platform you're running on determines how trustworthy that proof can ever be.
This is the A dimension of the KRAB model. It measures the attestation ceiling — the highest level of hardware proof available on your platform, before you've written a single line of code.
How attestation works
Remote attestation is a three-party handshake:
- A verifier (you, a KBS, a client) sends a challenge — a random nonce.
- The workload asks the hardware to produce a quote incorporating that nonce.
- The CPU signs the quote with a key rooted in silicon. The quote contains cryptographic measurements of what was loaded and the nonce proving freshness.
- The verifier checks the signature against the silicon vendor's certificate chain, confirms the measurements match expectations, and validates the nonce.
If this sounds like a TLS handshake with extra hardware steps, that's roughly what it is. The difference: the proof is rooted in a physical chip, not a software certificate authority.
The ceiling concept
Not all attestation is equal. The platform — your deployment context — sets a strict upper bound on how much the quote can prove. An application can never exceed the ceiling that the platform below it establishes.
This is scored as the A level:
| Level | Name | What it means | Example |
|---|---|---|---|
| A0 | Unmeasured | No cryptographic proof. The workload runs, but nothing signs for it. | Traditional VM |
| A1 | Provider-Rooted | Hardware isolates the workload, but the root of trust belongs to the cloud provider, not the silicon vendor. A compromised provider could forge attestation. | AWS Nitro Enclaves |
| A2 | Silicon-Rooted, Mediated | Silicon root of trust exists, but a CSP-controlled paravisor sits between your workload and the quoting interface. The CSP's software is inside your TCB. | Azure TDX, Azure SEV-SNP |
| A3 | Silicon-Rooted, Direct | Full silicon root of trust. Your workload accesses the hardware quoting interface directly — no provider software in the attestation path. | GCP TDX, bare-metal TDX |
What each level means in practice
A0 is the baseline. No TEE, no attestation. You're trusting the infrastructure operator completely. Every traditional VM and container runs here.
A1 means the hardware isolates your workload, but the proof that it's isolated comes from the provider's own PKI — not from the silicon vendor. AWS Nitro Enclaves work this way: the Nitro Security Module (NSM) computes measurements and ensures isolation, but the root of trust is the AWS Nitro PKI. If AWS were compromised, they could forge attestation documents without hardware alarms. You cannot verify the system without trusting AWS.
A2 means the silicon vendor (Intel, AMD) anchors the trust, but the provider interposes software — a paravisor or vTPM — between your workload and the raw quoting interface. Azure TDX runs this way: the OpenHCL paravisor intercepts the quote flow. The silicon root of trust is real, but Azure's mediation layer is now inside your TCB. The guest cannot access the hardware directly — configfs-tsm is behind the paravisor.
A3 is the strongest. Your workload talks directly to the CPU's quoting interface. On GCP TDX, the guest accesses configfs-tsm with no paravisor intercept. On bare-metal, you own the entire path. The attestation proof traces from your application straight to Intel's or AMD's silicon, with nothing in between.
A is bottom-up
This is the key insight: A is an architectural property of the platform, not a knob you can turn. You cannot write your way to A3 on an A2 platform. If Azure TDX mediates your attestation, your ceiling is A2 — no matter how carefully you build your application.
Choosing a platform is choosing an attestation ceiling. Everything else in the KRAB model builds on top of what the platform allows.
A is necessary but not sufficient
A high A level doesn't mean the system is secure. It means the proof infrastructure is strong. An A3 platform with opaque firmware, no session binding, and a permissive KMS is still broken — just broken on good hardware.
The next dimension — Reproducibility — asks: can anyone verify what was loaded into that attested environment?
A1 and A2 are not automatically insecure — they are explicit trust delegations. If your threat model accepts the CSP as trusted, A2 can be a valid engineering choice. But the delegation must be conscious and documented, not accidental.
To determine your platform's A level, ask: "Can my workload access the raw hardware quoting interface (/dev/sev-guest, configfs-tsm), or does a provider-controlled component sit in the path?" If there's a paravisor or vTPM intercept, you're at most A2.