Helpful first: Formal security models: Bell-LaPadula, Biba, Clark-Wilson, and Brewer-Nash
Key points
- Define the Trusted Computing Base (TCB), Security Perimeter, and the three Reference Monitor invariants (Always Invoked, Tamperproof, Small Enough to Test)
- Contrast TPM (platform boot integrity) vs HSM (high-speed enterprise key lifecycle and crypto acceleration)
- Compare CPU privilege rings, memory protections (DEP/NX, ASLR), and Type 1 vs Type 2 hypervisors against side-channel and escape attacks
Trusted Computing Base (TCB), Reference Monitor, and CPU rings
The Trusted Computing Base (TCB) is the combination of all hardware, firmware, and software components inside a system whose correct operation is required to enforce the security policy. If a vulnerability exists inside the TCB, the security of the entire system is compromised; therefore, architects strive to keep the TCB as small and simple as possible. The boundary separating the TCB from untrusted user-space processes is the Security Perimeter.
At the heart of the TCB sits the Reference Monitor (an abstract access-mediation concept) and its concrete implementation in code and hardware, the Security Kernel. To be trustworthy, a Reference Monitor must satisfy three strict engineering properties: it must provide complete mediation (always invoked on every access attempt), it must be isolated and tamperproof from modification by untrusted processes, and it must be small and simple enough to be exhaustively verified and tested.
Hardware enforces this separation through CPU Privilege Rings and operating modes. Ring 0 (Kernel / Supervisor Mode) executes privileged CPU instructions and accesses physical memory and I/O directly. Ring 3 (User Mode) hosts applications; whenever an application in Ring 3 needs to read a file or open a socket, it must issue a controlled System Call (syscall) trap across the boundary into Ring 0.
| Primitive | What it enforces | Failure mode or exam distinction |
|---|---|---|
| Reference Monitor / Security Kernel | Mediates all subject-to-object access requests inside the TCB. | Must satisfy 3 rules: Always Invoked, Tamperproof, Small Enough to Verify. |
| TPM (Trusted Platform Module) | Motherboard crypto co-processor storing Platform Configuration Registers (PCRs) and local root keys. | Used for UEFI Secure/Measured Boot and full-disk encryption sealing; not a multi-host high-throughput HSM. |
| HSM (Hardware Security Module) | Dedicated tamper-evident/tamper-responsive hardware appliance (FIPS 140-3) for enterprise keys. | Zeroizes keys if physically drilled or probed; accelerates TLS/PKI signing at scale. |
| DEP / W^X and ASLR | DEP/NX marks data pages non-executable; ASLR randomizes stack, heap, and library addresses. | Together they defeat classic buffer-overflow shellcode injection and hardcoded return-to-libc jumps. |
Hardware roots of trust (TPM, HSM, Enclaves) and Common Criteria
Software-only security fails if an attacker modifies the bootloader before the OS kernel starts. A Trusted Platform Module (TPM) solves this by anchoring a Chain of Trust in silicon. During boot, each stage (UEFI firmware -> bootloader -> OS kernel) hashes the next stage before executing it. Secure Boot blocks execution if a signature is invalid, while Measured Boot records the hashes into the TPM’s Platform Configuration Registers (PCRs) for remote attestation and refuses to unseal disk encryption keys if the boot chain changed.
For enterprise-wide secrets such as Certificate Authority root keys or database master keys, organizations use a Hardware Security Module (HSM) validated to FIPS 140-3 (Levels 1 through 4, where Level 3 adds physical tamper resistance/identity-based auth and Level 4 adds full environmental envelope zeroization). For data in use inside shared cloud CPUs, Trusted Execution Environments (TEEs / Confidential Computing enclaves) encrypt RAM contents per process so even a compromised host OS or hypervisor cannot read enclave memory.
When evaluating high-assurance products under ISO/IEC 15408 (Common Criteria), buyers review three artifacts: the Target of Evaluation (TOE, the product being tested), the Protection Profile (PP, the customer’s technology-independent security requirements), and the Security Target (ST, the vendor’s specific security claims), rated from Evaluation Assurance Level EAL1 (functionally tested) to EAL7 (formally verified design and tested).
Type 1 vs Type 2 hypervisors, containers, and side-channel attacks
Virtualization introduces an even deeper privilege ring (often called Ring -1) managed by the Virtual Machine Monitor (VMM) or Hypervisor. A Type 1 (Bare-Metal) hypervisor (such as KVM, Xen, VMware ESXi, or AWS Nitro) runs directly on the host hardware with no underlying general-purpose OS, offering a much smaller TCB and attack surface. A Type 2 (Hosted) hypervisor runs on top of a standard host OS (such as macOS or Windows), inheriting every vulnerability of the host OS.
Whereas virtual machines virtualize hardware and run separate guest kernels, OS containers (Docker / Kubernetes pods) share a single host OS kernel using Linux namespaces (visibility isolation) and cgroups (resource limits). Because containers share Ring 0, a kernel privilege-escalation vulnerability or a container running with --privileged can compromise the entire underlying node.
Even when logical hypervisor isolation holds, shared physical hardware creates microarchitectural side channels and covert channels. Attacks such as Meltdown and Spectre exploit CPU speculative execution and cache timing ( covert timing channels) to infer secret bytes across process or VM boundaries, while Rowhammer flips adjacent DRAM bits through rapid electromagnetic capacitor hammering. Defenses require constant-time cryptographic code, microcode patches, and dedicated bare-metal tenancy for ultra-sensitive workloads.
CHECK YOUR JUDGMENT
Kael Cho is designing the key storage and boot architecture for Meridian Space & Robotics (chronos.orbital). He needs one hardware component soldered to each ground-station server motherboard to verify kernel integrity during boot before unlocking the local NVMe drive, and a second dedicated, tamper-responsive network appliance (FIPS 140-3 Level 3) to generate, store, and zeroize the enterprise PKI root signing keys if physically breached. Which pair of components should he select?
NEXT FIELD LESSON