The security model behind confidential computing depends on several connected concepts: Roots of Trust establish a trustworthy foundation, the Trusted Computing Base defines what must be trusted, and boot measurements record the software loaded into a Trusted Execution Environment (TEE). This chapter explains each concept and how it contributes to protecting data in use.
Root of Trust (RoT)¶
A Root of Trust is an essential, foundational security component that provides a set of trustworthy functions that the rest of the device or system can use to establish strong levels of security.
Trusted Computing Group What is a Root of Trust?
Functions a RoT Provides¶
| Function | Description |
|---|---|
| Trusted Boot | Ensures only authorized software starts |
| Measurement | Records what software ran (in a tamper-proof way) |
| Secure Storage | Stores cryptographic keys isolated from system software |
| Reporting | Produces signed attestation reports |
| Verification | Validates other components’ integrity |
Example RoTs - AMD Secure Processor, Trusted Platform Module (TPM), Virtual Trusted Platform Module (vTPM), Device Identifier Composition Engine (DICE)
Trusted Platform Module (TPM) and vTPM¶
TPM (Trusted Platform Module) is a computer chip (microcontroller) that can securely store artifacts used to authenticate the platform (your PC or laptop). These artifacts can include passwords, certificates, or encryption keys. A TPM can also be used to store platform measurements that help ensure that the platform remains trustworthy. It’s an example of a RoT component.
A Virtual Trusted Platform Module (vTPM) is a software-based representation of a physical Trusted Platform Module (TPM) 2.0 chip.
Trusted Computing Group TPM summary
TPM Platform Configuration Registers (PCRs)¶
PCRs are special registers inside a TPM where measurements (hashes) are stored. They can only be extended (not overwritten):
New_PCR_Value = SHA256(Old_PCR_Value || New_Measurement)| PCR | What It Measures |
|---|---|
| 0 | UEFI firmware |
| 1 | UEFI firmware configuration |
| 4 | Boot manager code and boot attempts |
| 7 | Secure Boot policy (PK/KEK/db/dbx + the db entry used to authorize each loaded image) |
| 8-15 | OS/application measurements |
Trusted Computing Base (TCB)¶
The Trusted Computing Base is the set of all hardware, firmware, and software components that you must trust for your system’s security to hold. In a traditional cloud VM, this includes the hypervisor and host OS, both controlled by the cloud provider.
Secure Boot, Trusted Boot, and Measured Boot¶
Secure Boot and Trusted Boot¶
Secure Boot verifies digital signatures before running bootloaders.
It is a feature of the Unified Extensible Firmware Interface (UEFI). It’s used to check bootloaders, key operating system files, and the ROM for any tampering attempts.
UEFI firmware has signatures stored in a database and Secure Boot will check those signatures. If the signatures don’t match, then something was modified incorrectly and the boot process will halt.
Trusted Boot extends this with a chain of verification — each stage checks the next before passing control.
The bootloader (which we’ve verified to be trustworthy) will check the digital signature of the operating system kernel before loading it.
The verified kernel will then verify every other part of the OS startup process including boot drivers and startup files, to make sure those components are all safe.
Measured Boot¶
Measured boot uses hardware Root of Trust (RoT) eg. TPM to record a cryptographic hash of every stage of the boot process into PCRs. This creates a tamper-evident audit trail that can be verified remotely at any point in time.
Measured Boot doesn’t block anything, instead it records everything that runs (eg. into the TPM’s PCRs). This enables remote attestation where a third party can cryptographically verify the exact software stack that booted.
Summary Comparison¶
Comparison of boot security mechanisms: Secure Boot and Trusted Boot prevent unauthorised software from running; Measured Boot records what ran and enables remote verification via attestation.
Trusted Execution Environments (TEEs)¶
A Trusted Execution Environment (TEE) is a hardware-enforced execution environment that provides runtime isolation for code and data, protecting them from unauthorised access or tampering by privileged software such as the operating system, hypervisor, and even firmware.
| Characteristic | Description |
|---|---|
| Memory Encryption | All data in the TEE’s memory is encrypted by the hardware. Even physical DRAM access reveals only ciphertext. |
| Isolation | The TEE is isolated from other processes, VMs, and the host OS. Hardware enforces this boundary. |
| Remote Attestation | The TEE can prove its identity and integrity to remote parties cryptographically. |
| Data Integrity | The hardware detects and prevents tampering with TEE memory. |
Types of TEEs¶
VM-Based TEEs encrypt memory along a traditional VM boundary. The hypervisor cannot read VM memory.
Examples: AMD SEV-SNP, Intel TDX, IBM Secure Execution, IBM PEF
Protects entire existing applications without code changes
Supports standard Linux distributions
Scales to large memory and multi-core workloads
Process-Based TEEs split an app into trusted and untrusted components. Only the sensitive part runs in encrypted memory.
Example: Intel SGX
Smaller attack surface (only enclave code is in the TCB)
Requires application refactoring to separate trusted/untrusted components
Historically constrained to small enclave memory sizes
TCB Reduction with Confidential Computing¶
Confidential Computing dramatically reduces the TCB. The hypervisor and host OS move out of the TCB. You no longer need to trust the cloud provider’s software stack.
The next section shows how each TEE vendor — AMD SEV-SNP, Intel TDX, and Intel SGX, implements these concepts in practice, and how choices like vTPM placement affect what remains in the TCB.