Trusted Computing and TPM in the Software Supply Chain

Software can lie about itself. A compromised operating system can report that everything is fine while a rootkit operates underneath. A tampered binary can pass checksums if the verification tool itself is compromised. To break this cycle of trust, you need something that software alone can't provide: a hardware root of trust.

That's where the Trusted Platform Module comes in. TPMs are dedicated security chips that provide cryptographic operations, secure key storage, and integrity measurement capabilities that are isolated from the main processor and operating system. They're the foundation for verifying that the software running on a system is the software you intended to run.

What a TPM Does

A TPM is a small chip (or firmware module) that provides several core capabilities:

Platform Configuration Registers (PCRs)

PCRs are special-purpose registers that record measurements (cryptographic hashes) of software and configuration data. The key property of PCRs is that they can only be extended, never directly written. To extend a PCR, a new value is computed as:

new_PCR = Hash(current_PCR || new_measurement)

This means the PCR value reflects the entire history of measurements, in order. If any measurement differs -- even slightly -- the final PCR value will be completely different.

Sealed Storage

The TPM can encrypt data such that it can only be decrypted when the PCRs contain specific values. This means you can seal encryption keys, secrets, or configuration data to a known-good platform state. If the platform is tampered with, the PCR values change, and the sealed data becomes inaccessible.

Remote Attestation

The TPM can sign a report of the current PCR values with its unique, hardware-bound attestation key. A remote verifier can check this signature to confirm that the platform is in a known-good state, without trusting any software running on the platform.

Key Generation and Storage

The TPM can generate and store cryptographic keys that never leave the chip. This provides hardware-protected key storage that is resistant to software-based extraction.

Measured Boot and Supply Chain Integrity

Measured boot is the primary mechanism by which TPMs support supply chain integrity. During the boot process:

1. CPU microcode measures the initial firmware (BIOS/UEFI) and records the measurement in PCR 0.
2. Firmware measures the bootloader and records it in PCR 4.
3. Bootloader measures the operating system kernel and records it in PCR 8.
4. OS kernel measures critical drivers and configuration, recording in additional PCRs.

At any point after boot, the PCR values can be checked against expected values. If any component in the boot chain was modified -- whether by a supply chain attack, a firmware implant, or a bootkit -- the PCR values won't match.

What Measured Boot Catches

• Modified firmware: A supply chain attack that alters UEFI firmware changes PCR 0.
• Tampered bootloaders: A compromised GRUB or Windows Boot Manager changes PCR 4.
• Rootkits: OS-level rootkits that load during boot change the relevant PCRs.
• Configuration changes: Boot configuration modifications are captured in PCR 1 and PCR 5.

What Measured Boot Doesn't Catch

• User-space malware: Measured boot verifies the boot chain, not applications running after boot.
• Runtime attacks: Memory corruption or injection after boot isn't measured.
• Hardware implants below TPM: If the TPM itself is compromised or bypassed, measurements are meaningless.

TPM in Supply Chain Verification Workflows

Build Environment Attestation

Use TPM attestation to verify that build environments are in a known-good state before running builds:

1. Define a known-good build environment with specific firmware, OS, and toolchain versions.
2. Record the expected PCR values for this environment.
3. Before each build, request TPM attestation from the build machine.
4. Verify that PCR values match the expected state.
5. Only proceed with the build if attestation passes.

This ensures that builds run on verified, untampered infrastructure.

Artifact Provenance

TPM-based attestation can be included in artifact provenance metadata:

• The build environment's PCR values at build time.
• TPM-signed attestation reports accompanying each build artifact.
• Verification records showing that the build machine was in a known-good state.

SLSA (Supply-chain Levels for Software Artifacts) higher levels can leverage TPM attestation for build environment verification.

Secure Key Storage for Signing

Code signing keys stored in TPMs are protected against extraction. Even if the build server is compromised at the OS level, the attacker can't extract the signing key from the TPM. They might be able to use the key while they control the machine, but they can't take it with them.

For maximum security, combine TPM key storage with attestation-gated key access: the TPM only allows the signing key to be used when the platform is in a known-good state.

Device Identity and Supply Chain Tracking

Each TPM has a unique Endorsement Key (EK) that's provisioned during manufacturing. This key can serve as a hardware identity, enabling:

• Tracking of specific hardware through the supply chain.
• Verification that hardware hasn't been swapped or substituted.
• Binding of software licenses or configurations to specific hardware.

Challenges and Limitations

TPM Supply Chain

The TPM itself is a hardware component with its own supply chain. If the TPM is counterfeit, compromised, or misconfigured, the trust model breaks down. TPM vendors (Infineon, STMicroelectronics, Nuvoton) have had their own vulnerabilities:

• In 2017, Infineon TPMs were found to have a weak key generation algorithm (ROCA vulnerability) that allowed private key recovery.
• Firmware vulnerabilities in TPMs could potentially allow manipulation of PCR values or key extraction.

Performance Overhead

TPM operations are slow compared to software cryptography. The chip communicates via a low-speed bus, and operations like key generation or signing take hundreds of milliseconds. This can impact build pipeline performance if TPM operations are in the critical path.

Complexity

Properly implementing TPM-based verification requires deep expertise:

• Understanding PCR allocation and measurement order.
• Managing attestation key provisioning and distribution.
• Handling TPM firmware updates without breaking sealed data.
• Integrating with existing build and deployment workflows.

Firmware TPM (fTPM) Considerations

Many modern systems use firmware-based TPMs rather than discrete hardware chips. fTPMs run as trusted applications within the CPU's trusted execution environment. While more cost-effective, they inherit the security properties of the CPU's TEE, which may have its own vulnerabilities (e.g., AMD fTPM voltage fault injection attacks).

Practical Implementation Steps

1. Inventory TPM capabilities: Determine which systems have TPMs and what version (1.2 vs 2.0).
2. Enable measured boot: Configure systems for measured boot and collect baseline PCR values.
3. Implement attestation: Set up a verification server that can validate TPM attestation reports.
4. Integrate with CI/CD: Add attestation checks to build pipeline workflows.
5. Seal critical secrets: Use TPM sealed storage for encryption keys and other secrets on build servers.
6. Monitor drift: Continuously compare PCR values against baselines to detect unauthorized changes.

How Safeguard.sh Helps

Safeguard.sh complements TPM-based hardware verification by providing comprehensive software-level supply chain analysis. While TPMs verify the integrity of the boot chain and build environment, Safeguard.sh verifies the integrity of the software components within those environments. Together, they create a complete verification chain from hardware through software. Safeguard.sh's SBOM management, vulnerability scanning, and policy enforcement operate at the application and dependency level, ensuring that even when the hardware platform is verified as trustworthy, the software running on it is equally verified and compliant with your security requirements.