Hardware Roots of Trust — TPM, HSM, Secure Boot

Last updated: April 29, 2026

A Bengaluru hardware startup shipped 50,000 IoT smart-meters to a state utility. Six months later, security researchers extracted the firmware-signing key from one device and demonstrated they could push malicious firmware updates to all 50,000. The recall cost was ₹18 crore; the regulatory fallout was worse. The root cause: the signing key sat in regular flash with no hardware protection. This module covers hardware roots of trust — the chip-level primitives that make device security tractable.

What a hardware root of trust is

A hardware root of trust (HRoT) is a tamper-resistant chip or chip-region that holds cryptographic secrets the rest of the system cannot extract. Software running on the main CPU can ask the HRoT to sign, decrypt, or verify — but never sees the underlying key. The HRoT is the anchor; everything else (boot, attestation, key storage) chains up to it.

The common forms:

• TPM 2.0 — discrete chip on the motherboard, used by Windows/Linux for BitLocker/LUKS, measured boot, attestation
• Apple Secure Enclave — separate processor on iPhone/Mac SoC; holds biometric and keychain keys
• ARM TrustZone — secure-world / normal-world split on ARM SoCs; basis for Android Keystore
• Intel SGX / TDX, AMD SEV-SNP — confidential-computing primitives in server CPUs
• HSM (Hardware Security Module) — network-attached or PCIe; FIPS 140-2/3 certified for high-value keys
• Microcontroller secure-element (Microchip ATECC, NXP A71CH) — small chips for IoT

Measured / verified boot

The classic HRoT use case is secure boot. The boot ROM (immutable, in silicon) verifies the bootloader’s signature against a public key fused into the chip. The bootloader verifies the kernel. The kernel verifies the userspace. Each stage’s hash is extended into a TPM PCR, producing a cryptographic measurement of the entire boot chain.

# On a TPM 2.0 Linux system, read the PCRs after boot:
sudo tpm2_pcrread sha256:0,1,2,3,4,5,7

# Quote the PCRs (signed attestation):
sudo tpm2_quote --key-context ak.ctx \
  --pcr-list sha256:0,1,2,3,4,5,7 \
  --message quote.msg --signature quote.sig

A remote attestation server can verify the quote, compare PCR values to known-good measurements, and decide whether to grant the device access to sensitive resources.

Key storage and use

The other major HRoT use case is key storage. A private key generated inside the HRoT cannot be exported. Software calls the HRoT to sign:

# Generate a non-exportable key inside the TPM:
tpm2_create -C primary.ctx -G ecc256 -u key.pub -r key.priv \
  -a 'fixedtpm|fixedparent|sensitivedataorigin|userwithauth|sign'

# Load and sign with it:
tpm2_load -C primary.ctx -u key.pub -r key.priv -c key.ctx
tpm2_sign -c key.ctx -g sha256 -o sig.bin message.txt

The private key never exists outside the TPM. Even root on the host cannot extract it. An attacker who steals the disk gets nothing useful.

The Bengaluru smart-meter rebuild

After the firmware-signing-key extraction, the startup redesigned with a Microchip ATECC608 secure element on every meter:

• Per-device unique ECC P-256 keypair generated in the secure element at manufacture
• Public keys registered in a backend HSM-backed PKI
• Firmware updates signed by the manufacturer’s HSM-held key; secure element verifies signature before flashing
• Mutual TLS to the cloud, with the device key never leaving the secure element
• Tamper detection — opening the case zeroes the secure element

Cost per device: ₹85 added. Avoidance of the next recall: priceless. The state utility now requires HRoT in all new IoT procurement specifications.

Confidential computing — HRoT for cloud workloads

Intel SGX, AMD SEV-SNP, and Intel TDX let cloud workloads run inside hardware-encrypted enclaves where even the cloud provider cannot read memory. Use cases:

• Multi-party computation across regulators where no party can see others’ data
• Key management with cryptographic guarantees that the key stays in the enclave
• Sensitive ML inference where the model is the IP and the input is the customer’s PII

Indian banks experimenting with confidential computing for inter-bank fraud-detection models — each bank contributes data to a shared enclave; nobody sees others’ data; the model output benefits everyone.

Indian compliance mapping

• RBI Cyber Framework — HSM for cryptographic-key management explicitly required for banks
• SEBI CSCRF — HSMs for trading-system signing keys for Q-RE / MII
• UIDAI Aadhaar — HSM-backed keys for AUA/KUA mandatory
• NPCI guidelines — HSM for UPI signing keys mandatory
• FIPS 140-2 Level 3 / 140-3 — referenced as baseline by RBI for HSMs

Common pitfalls

• Generating keys outside the HRoT and importing them — defeats the purpose; key was already exposed
• Not enrolling devices into a PKI — per-device keys without identity infrastructure are useless
• Using TPM for performance-critical signing — TPMs are slow (single-digit ops/sec); use for low-volume root keys, not bulk operations
• Ignoring firmware updates for the HRoT itself — TPM 2.0 has had its own CVEs (CVE-2023-1017/1018)
• No remote attestation — measured boot data is useless if you don’t verify it from a separate system

Try this in your environment

1. On any modern Linux laptop, run sudo tpm2_pcrread. The values reflect your actual boot chain.
2. Generate a TPM-bound SSH key with ssh-keygen -t ecdsa-sk (with FIDO2) or tpm2-pkcs11. The key cannot leave the device.
3. For your IoT or embedded device project, evaluate ATECC608 or NXP SE050 secure elements. Cost is ~₹100 per device at volume.
4. For cloud workloads handling regulated data, evaluate AWS Nitro Enclaves, Azure Confidential VMs, or GCP Confidential VMs.

Hardware roots of trust are how you make device-level security real instead of theatrical. Software security on a compromised host is a contradiction; HRoT is the foundation that makes everything above it meaningful.