Skip to main content

Practical CoCo

A Trusted Execution Environment is useless if you don't know what you're verifying.

What this is​

Most TEE documentation is either academic or vendor-specific marketing. Engineers evaluating or building on TEEs need practical guidance: what to verify, what you're trusting, where verification stops, and what tools exist. This handbook fills that gap.

It is built around the KRAB model — a framework that asks four questions about any confidential computing system:

  • A — Attestation: Does the hardware actually prove what's running? How deep does that proof go?
  • R — Reproducibility: Can anyone rebuild the software and get the same binary? At every layer?
  • B — Binding: Can the outside world prove it's talking to this specific instance right now?
  • K — Key Release: Does the system that hands out secrets actually enforce all of the above?

These four dimensions combine into a CoCo Vector — a compact notation like A2[Azure TDX] | R[f1/o0/l4/a4] | B2 | K4 that maps exactly where a system's verifiability holds up and where it breaks down. If any dimension collapses to zero, the whole thing collapses with it.

This isn't a score to optimize. It's a diagnostic tool — a way to make trust assumptions visible and architectural weaknesses impossible to hide.

Who this is for​

  • Security engineers evaluating TEEs for their infrastructure
  • Developers building applications on TEE platforms
  • Technical decision-makers assessing trust assumptions before committing to a TEE strategy

No prior TEE experience required. Start from the beginning and the concepts build on each other.

How to read this​

Start with Foundations — it builds the KRAB model one dimension at a time, from the hardware up. By the end of the section, you'll be able to read and produce CoCo Vectors for real systems.

Then dive into platform-specific sections as they become available.

Principles​

  • Practical over theoretical — real verification steps, real tools, real bugs encountered
  • Honest about limitations — every section surfaces what you can't verify and must trust
  • Progressive disclosure — foundations first, then platform specifics, then patterns
  • Pragmatism over purity — trusting a mature CSP is a valid engineering choice; the framework makes that choice explicit, not invisible