Trusted Computing Base (TCB)

The TCB must contain only the absolutely essential code required to enforce security policy. Every unnecessary library, driver, or service included in the TCB becomes a potential vulnerability.

• A hypervisor-based TCB might be only 10,000-50,000 lines of code
• General-purpose operating systems contain millions of lines
• Formal verification is exponentially harder as code size increases
• The seL4 microkernel demonstrated that a ~8,700 line kernel can be mathematically proven correct

A minimal TCB anchors its trust chain in immutable hardware—typically a cryptographic key burned into silicon during manufacturing. This root of trust cannot be altered by software, firmware updates, or physical attackers.

• One-Time Programmable (OTP) fuses store the initial key material
• The hardware root verifies the first-stage bootloader signature before execution
• Without a hardware anchor, trust becomes a circular dependency
• Technologies like TPM 2.0 and Apple's Secure Enclave implement this principle

Every access to a protected resource must be intercepted and validated by the TCB. There can be no backdoors, direct hardware access paths, or privileged shortcuts that bypass the security monitor.

• The TCB acts as a reference monitor for all security-critical operations
• Memory accesses, I/O operations, and cryptographic key usage must all pass through TCB checks
• Intel SGX enclaves enforce this by design—the CPU itself blocks unauthorized access
• Incomplete mediation is a common source of privilege escalation vulnerabilities

A minimal TCB must provide cryptographic proof of its own integrity. Remote parties can verify exactly which code is running inside the trusted environment before sending sensitive data.

• The TCB generates a signed measurement (hash) of its initial state
• A remote verifier compares this against a known-good reference value
• AMD SEV-SNP and Intel TDX provide hardware-signed attestation reports
• Attestation enables Confidential Computing—processing data you cannot physically control

Components within the TCB should operate with the minimum permissions necessary to perform their function. Even if a TCB component is compromised, the damage is contained by its limited authority.

• A network driver in the TCB should not have access to disk encryption keys
• Capability-based security models grant fine-grained, revocable tokens instead of broad permissions
• The principle applies recursively: split the TCB into isolated modules
• seL4 enforces this through kernel-managed capabilities for every system call

A TCB small enough to be mathematically verified provides the highest assurance. Formal methods can prove that the TCB's implementation correctly enforces its security specification under all possible inputs.

• Theorem provers like Coq and Isabelle/HOL are used for machine-checked proofs
• The seL4 microkernel has a complete proof of functional correctness
• Formal verification eliminates entire classes of bugs: buffer overflows, null pointer dereferences, race conditions
• Verification is only practical when the TCB is kept deliberately small