Trust Boundaries and the Trusted Computing Base

What is a trust boundary?

A trust boundary separates components with different security assumptions.

Inside the boundary are components that the system depends on for a specific security property.

Outside the boundary are components that may be considered untrusted, compromised, curious, malicious, or outside the system owner's control.

A trust boundary can exist around:

• A function
• A process
• An enclave
• A virtual machine
• A secure operating system
• A cryptographic module
• A hardware device
• A network service

What is the Trusted Computing Base?

The Trusted Computing Base (TCB) is the set of hardware, firmware, and software mechanisms responsible for enforcing a system's security policy.

NIST defines the TCB as the totality of protection mechanisms, including hardware, firmware, and software, that enforce a security policy.

If a component inside the TCB is compromised, the protection may fail.

Traditional application TCB

Consider a normal application running in a cloud virtual machine.

Its practical TCB may include:

• Application code
• Libraries
• Language runtime
• Guest operating system
• Guest kernel
• Hypervisor
• Host operating system
• Firmware
• Processor
• Cloud management systems
• Key management service

This is a large trust boundary. The application may depend on all these components to keep plaintext data safe.

Process enclave TCB

A process enclave attempts to remove the host operating system and hypervisor from the confidentiality boundary of selected code and data.

A simplified TCB may include:

• Enclave application code
• Enclave runtime
• Trusted libraries
• Processor hardware
• Processor microcode
• Relevant firmware
• Attestation infrastructure

The operating system may remain responsible for scheduling, storage, and network access. It should not be able to directly inspect protected enclave memory.

Confidential virtual machine TCB

A confidential virtual machine places the boundary around a complete guest environment.

The TCB may include:

• Application
• Libraries
• Language runtime
• Guest operating system
• Guest kernel
• Guest firmware
• Confidential computing firmware
• Processor
• Attestation components

The host hypervisor may be outside the confidentiality boundary. However, the guest operating system is now inside the trusted boundary.

This makes deployment easier, but it increases the amount of trusted software.

Why a smaller TCB matters

Every trusted component may contain:

• Software bugs
• Unsafe configuration
• Vulnerable dependencies
• Privilege-escalation paths
• Supply-chain risks
• Update risks
• Incorrect assumptions

A smaller TCB gives developers fewer critical components to review.

A smaller TCB is not automatically secure. A small enclave with a memory-safety bug may still leak secrets. The goal is to keep the TCB both small and reviewable.

Trust is property-specific

A component may be trusted for one property but not another.

Examples:

• A host may be trusted to provide network access but not confidentiality.
• A hypervisor may be trusted for scheduling but not for reading guest memory.
• A key service may be trusted to release a key only after valid attestation.
• A blockchain may be trusted to order transactions but not hide them.
• A hardware vendor may be trusted to issue correct platform certificates.
• A storage provider may be trusted for availability but not secrecy.

A good threat model should state the exact property attached to each trust assumption.

Example: Confidential AI service

Consider an AI service with a user device, API gateway, load balancer, confidential VM, guest Linux kernel, AI model, confidential GPU, attestation verifier, key management service, logging service, and object storage.

For each component, the design should answer:

1. Can it see plaintext user data? 2. Can it modify the model? 3. Can it change the input? 4. Can it release a key? 5. Can it change the accepted measurement? 6. Can it stop the service? 7. Can it observe request timing? 8. Is it inside or outside the TCB?

The operator still has power

A cloud TEE may reduce the operator's ability to read protected memory.

The operator may still control:

• Machine availability
• Network routing
• Host scheduling
• Firmware rollout
• Service access
• Hardware placement
• Billing
• Some attestation infrastructure

A TEE changes the operator's powers. It does not remove the operator from the system.

Key takeaways

• A trust boundary separates different security assumptions.
• The TCB contains components required to enforce the security policy.
• Process enclaves usually have a smaller application boundary.
• Confidential VMs usually include the guest operating system in the TCB.
• A smaller TCB reduces review scope but does not guarantee safety.
• Trust assumptions must be tied to specific security properties.