Trusted Computing Base (TCB)

The security of a system is inversely proportional to the size of its TCB. A smaller TCB means fewer lines of code and hardware components to audit, resulting in a lower probability of exploitable vulnerabilities.

• Goal: Reduce the TCB to the absolute minimum required for functionality.
• Strategy: Strip non-essential drivers, services, and libraries from the security-critical boundary.
• Example: A microkernel architecture keeps the TCB in kernel space tiny, moving file systems and device drivers to unprivileged user space.

Every component within the TCB must be subject to rigorous formal or semi-formal verification. The system's security guarantees are only as strong as the ability to prove the correctness of the TCB's implementation.

• Formal Verification: Using mathematical proofs to ensure the TCB code adheres strictly to its specification.
• Reproducible Builds: Ensuring the binary deployed matches the audited source code exactly.
• Example: seL4, a formally verified microkernel, provides a mathematical proof of functional correctness, eliminating entire classes of bugs within its TCB.

The TCB must be an unavoidable gatekeeper for all security-critical operations. It is impossible for a subject to bypass the TCB to access a protected object.

• Non-Bypassable: Every access request must be intercepted and validated by the TCB's reference monitor.
• Tamper-Proof: The TCB's own code and data structures must be protected from unauthorized modification.
• Example: A hypervisor acting as the TCB must trap every privileged instruction from a guest OS, leaving no vector for the guest to directly control hardware resources.

The TCB must maintain a strict, hardware-enforced boundary between itself and untrusted processes. This isolation prevents a compromise in a non-TCB component from escalating privileges into the trusted core.

• Hardware Protection: Leveraging CPU rings, memory management units (MMUs), and I/O MMUs to enforce separation.
• Sandboxing: Confining untrusted code to a restricted environment where it cannot interfere with the TCB.
• Example: Intel SGX creates an enclave that isolates a security-sensitive computation from the host OS, hypervisor, and even other enclaves, shrinking the TCB to just the enclave code and the processor package.

The TCB's components must originate from a trusted source and maintain their integrity over their entire lifecycle. Trust is not an inherent property but a judgment based on provenance and continuous monitoring.

• Provenance: The supply chain for TCB hardware and software must be secured against tampering.
• Integrity: Mechanisms like secure boot and remote attestation cryptographically verify that the TCB hasn't been modified.
• Example: A Hardware Root of Trust anchors the boot process, cryptographically measuring each firmware and software layer before execution to establish a chain of trust up to the TCB.

The TCB must function exactly as specified, with no deviations. A single bug in a TCB component can invalidate the security of the entire system, making correctness a paramount design goal.

• Defensive Programming: Applying rigorous input validation, fail-safe defaults, and least privilege within the TCB itself.
• Eliminating Side Channels: Ensuring the TCB's implementation doesn't leak secrets through timing, power consumption, or electromagnetic emissions.
• Example: A side-channel attack on a cryptographic library within the TCB can extract private keys by measuring the precise time taken for operations, bypassing the mathematical security of the algorithm.

The seL4 microkernel represents the gold standard for minimizing the software TCB. At approximately 10,000 lines of C code, it is the first operating-system kernel to be mathematically proven to be free of implementation bugs. This formal verification ensures the kernel enforces integrity and confidentiality exactly as specified.

• TCB Scope: CPU, memory, kernel, and hardware drivers
• Verification: Machine-checked proof of correctness
• Use Case: Defense systems, autonomous vehicles, and critical infrastructure

Intel SGX shrinks the TCB for a specific workload to just the application code and the processor package. The OS, hypervisor, and firmware are excluded from the trust boundary. An enclave's memory is hardware-encrypted and inaccessible to any software outside it.

• TCB Scope: CPU package, enclave code, and supporting libraries
• Excluded: Operating system, hypervisor, and cloud provider
• Attestation: Cryptographic proof of enclave identity via MRENCLAVE

Qubes OS implements a 'security by isolation' architecture using the Xen hypervisor. It decomposes the user's digital life into isolated virtual machines (qubes), each with a distinct security domain. The hypervisor itself is the primary TCB.

• TCB Scope: Xen hypervisor, dom0 admin domain, and hardware
• Isolation: Separate VMs for work, personal, and untrusted tasks
• Principle: Compromise of one qube does not affect others