CCSI

Lesson 1.3 · 15 min read

Drawing the trust boundary and TCB

A repeatable method for drawing the boundary, enumerating the trusted computing base, and writing a testable threat model.

The trusted computing base

The trusted computing base (TCB) is everything whose correct behaviour is required for the security property to hold. Smaller is better, because every component in the TCB is something that, if flawed, breaks the guarantee. Different TEE designs put very different amounts of software in the TCB: a process-level enclave can be small, while a confidential VM includes an entire guest operating system.

Trust boundary for a confidential VMTRUSTED (inside TCB)UNTRUSTED (outside boundary)untrusted inputYour workloadapp code, librariesGuest OS + firmwarekernel, initrd, vTPMCPU TEE hardwarememory encryption, root of trustAttestation verifierand its reference valuesHypervisor / host OSschedules, allocates, can deny serviceCloud operators & other tenantsNetwork, disk, host servicesobservable and tamperable
Everything on the left must be trusted for the guarantee to hold. Everything on the right is assumed hostile; inputs from it must be validated.

A five-step method

  1. Name the asset. What exactly must stay confidential: a dataset, model weights, a signing key, user prompts?
  2. Name the excluded parties. Cloud operator? Your own SRE team? A data partner?
  3. Draw the boundary. List every component inside: hardware, firmware, guest kernel, runtime, libraries, application, and the verifier that decides what to trust.
  4. List every crossing. Each network call, file, environment variable, and host service. Mark how each is protected.
  5. State what happens on failure. If attestation fails or the platform's TCB is revoked, what stops, and who is alerted?

Writing a testable threat model statement

Officers should insist on a short statement that an auditor can test. For example:

text
Asset:      customer prompts and completions for the inference API
Excluded:   cloud provider operators; our own platform admins
Boundary:   AMD SEV-SNP confidential VM + NVIDIA H100 in CC mode;
            guest image built from tagged commit, measured at launch
Crossings:  TLS 1.3 terminated inside the CVM; model weights fetched
            encrypted and unwrapped by a key released only on attestation
Failure:    if attestation fails, KMS denies key release; service
            returns 503 and pages the on-call security officer
Out of scope: denial of service; bugs in the inference server itself
A threat model statement an auditor can check line by line

Key takeaways

  • The TCB is everything that must be correct for the guarantee to hold; keep it small and explicit.
  • The verifier and its reference values are part of what you trust, even though they run elsewhere.
  • A good threat model names the asset, the excluded parties, the boundary, every crossing, and the failure behaviour.

Further reading: Confidential Computing Consortium white papers.

End of module 1

Take the module 1 quiz to check your understanding.