Trusted Computing Base (TCB)

The security of a system is inversely proportional to the size and complexity of its TCB. A smaller TCB has a smaller attack surface, fewer lines of code to audit, and a lower probability of containing exploitable vulnerabilities.

• Goal: Reduce the TCB to the absolute minimum required to enforce the security policy.
• Exclusion: Components like device drivers, user applications, and the OS kernel (in a TEE model) are explicitly excluded from the TCB.
• Verification: Formal methods and mathematical proofs become feasible only with a sufficiently small TCB.

Every access to a protected resource or object must be mediated by the TCB. There can be no backdoors, undocumented interfaces, or alternative paths that allow an untrusted entity to circumvent the TCB's security checks.

• Reference Monitor Concept: The TCB must function as a complete and always-invoked reference monitor.
• Hardware Enforcement: Modern TCBs use hardware features like nested paging and memory encryption to enforce non-bypassability at the silicon level.
• Example: In Intel SGX, the CPU hardware prevents even the OS or hypervisor from reading enclave memory.

The TCB must be protected from unauthorized modification, both at rest and during execution. Its integrity must be verifiable at load time and continuously monitored at runtime.

• Secure Boot: A hardware root of trust cryptographically verifies the TCB's firmware and software signatures before execution.
• Measured Boot: Each component's hash is extended into a Platform Configuration Register (PCR) for remote attestation.
• Runtime Protection: Hardware isolates TCB memory regions, preventing DMA attacks or privilege escalation from corrupting TCB state.

A TCB must be evaluable. Its correctness and trustworthiness must be demonstrable to a remote party through rigorous analysis, formal verification, or cryptographic attestation.

• Remote Attestation: The TCB generates a signed report quoting its measurement, proving it is genuine and running unmodified code.
• Open Source: While not strictly required, open-source TCB components allow independent security audits and community scrutiny.
• Formal Verification: The highest assurance comes from mathematically proving the TCB's implementation matches its specification, a technique used in high-assurance separation kernels like seL4.

The TCB must correctly enforce the intended security policy. A perfectly isolated and non-bypassable TCB that enforces a flawed policy is still insecure. The policy definition is itself part of the TCB.

• Policy vs. Mechanism: The TCB provides the mechanism (isolation, access control), but the configured policy defines what is allowed.
• Example: A TEE might perfectly isolate an enclave, but if the enclave code has a buffer overflow, the security policy is violated.
• Implication: All code executing within the TCB boundary must be trusted to enforce the correct policy, reinforcing the need for minimality.

The TCB must provide a secure, unspoofable communication channel between itself and the user or a remote relying party. This prevents an untrusted intermediary from intercepting or manipulating sensitive interactions.

• Local Trusted Path: A secure attention key (e.g., Ctrl+Alt+Del) that guarantees the user is communicating directly with the TCB, not a spoofed login prompt.
• Remote Trusted Path: Enclave TLS terminates a network connection directly inside a TEE, ensuring data is decrypted only within the protected TCB boundary.
• Attestation Binding: The trusted path is established only after the remote party has cryptographically verified the TCB's identity via attestation.

A TEE-specific operation that encrypts data and cryptographically binds it to the unique identity of the enclave and platform that created it. Sealing ensures that sensitive data can only be decrypted by the exact same enclave on the exact same hardware. This protects data at rest outside the TCB. An attacker who steals a sealed blob cannot decrypt it on a different machine or inside a tampered enclave, enforcing a strict data-in-use protection policy.

A class of exploits that targets the physical implementation of the TCB rather than its logical flaws. Attackers observe timing variations, power consumption, or electromagnetic emanations to infer secret data like cryptographic keys. Defending against side-channel attacks is a primary driver for keeping the TCB as small and simple as possible. Modern TEEs incorporate countermeasures like constant-time algorithms and memory encryption to mitigate these physical-layer threats.

A hierarchical sequence of validation where each component in the system is authenticated by the preceding component, beginning with the immutable Hardware Root of Trust. The chain extends from the bootloader to the OS kernel and finally to the application enclave. A break at any link—such as a compromised bootloader—invalidates all subsequent trust. The TCB encompasses every component in this chain that lacks a higher authority to verify it.