Roots of Trust, Secure Boot, and Measurements

Where does trust begin?

A verification chain needs a starting point.

A Root of Trust is a component that is accepted as the foundation for one or more security functions.

NIST describes roots of trust as highly reliable hardware, firmware, or software components that perform critical security functions. Because they are inherently trusted, they must be secure by design.

Roots of trust may support:

• Measurement
• Verification
• Reporting
• Storage
• Key generation
• Device identity
• Secure update
• Recovery

Examples of hardware roots of trust

A hardware root of trust may include:

• Immutable boot ROM
• Device-specific keys
• Processor fuses
• Secure processors
• Trusted Platform Modules
• Protected key storage
• Hardware random-number generators
• Secure measurement registers

Different TEE systems use different roots.

A mobile secure subsystem may use its own boot ROM. A confidential VM may depend on a separate platform security processor. A process enclave may depend on processor keys, microcode, and enclave instructions.

Chain of trust

A chain of trust connects one verified or measured component to the next.

A simplified chain may look like:

`` Immutable boot code ↓ Platform firmware ↓ Bootloader ↓ Operating system ↓ TEE runtime ↓ Trusted application ``

NIST describes a chain of trust as a process in which one software module measures the next before control is transferred.

The chain is meaningful only if:

• The starting root is protected.
• Verification keys are correct.
• Measurements cannot be silently altered.
• Old or revoked versions can be rejected.
• The verifier has an approved policy.
• The boot process covers the relevant components.

Secure boot

Secure boot is an enforcement process.

Before executing the next component, the current trusted stage checks whether the component is authorized.

A simplified flow is:

1. Load the next component. 2. Verify its digital signature. 3. Check the signing key against an approved policy. 4. Check security version information. 5. Run the component only when verification succeeds.

Secure boot answers: Is this software authorized to run?

Trusted Computing Group material describes secure boot as validating software before execution through a chain of trust.

Measured boot

Measured boot records which software and configuration were loaded.

A simplified measurement may be written as:

`` measurement = Hash(code || configuration || security attributes) ``

The measurement is stored in a protected register or report.

Measured boot answers: What software and configuration were loaded?

Measured boot does not always stop unapproved software from running. It may record the state so that a verifier can reject it later.

Secure boot and measured boot are complementary

A platform may use both.

The system can:

1. Verify that a component is authorized. 2. Measure the component. 3. Store the measurement. 4. Include the measurement in attestation evidence. 5. Allow an external party to evaluate the result.

Secure boot applies a local execution policy. Measured boot provides information that may be evaluated locally or remotely.

Runtime measurements

TEE platforms often calculate measurements when an enclave or protected VM is created.

The measurement may include:

• Application code
• Initial data
• Page permissions
• Memory layout
• Guest firmware
• Kernel
• Root filesystem
• Boot configuration
• Runtime configuration
• Security version

The exact contents depend on the platform.

A measurement is not a security score

A measurement may identify a particular binary or system state.

It does not prove that:

• The code has no bugs.
• The application respects privacy.
• The output is correct.
• The application was audited.
• The source code matches the binary.
• The code is side-channel resistant.

A measurement becomes useful when someone knows what value should be accepted. That approved value is called a reference value.

Example: One changed line

An approved program contains:

`` result = calculate_average(private_dataset) return result ``

A modified version contains:

`` upload(private_dataset) result = calculate_average(private_dataset) return result ``

The modified binary should produce a different measurement.

But several questions remain: Who reviewed the source? Who built the binary? Can users reproduce the measurement? Who publishes the approved measurement? Can the operator replace the reference value? Who authorizes software updates?

A measurement supports verification. It does not replace governance or code review.

Key takeaways

• A Root of Trust is the starting point for security claims.
• A chain of trust connects verified or measured components.
• Secure boot enforces which software may run.
• Measured boot records which software did run.
• Runtime measurements identify code and configuration.
• Measurements do not prove that an application is safe.