The semiconductor supply chain spans at least six trust boundaries between design intent and deployed silicon: the RTL design house, the mask shop, the wafer fab, the OSAT packaging and test facility, the distributor, and the system integrator. At each step, the chip is physically handled by parties whose security posture you cannot audit, under manufacturing conditions that include opportunities for substitution, modification, or counterfeit insertion. The 2020 SolarWinds supply chain attack made software provenance a boardroom concern. The hardware equivalent — a modified chip or a counterfeit HSM inserted into a security-critical deployment — is harder to detect and has already happened in documented incidents. The question is how cryptographic attestation, rooted in keys that exist only in ROM, can provide verifiable provenance across this chain.
Why Software-Only Provenance Attestation Falls Short
Current supply chain provenance approaches for hardware mostly rely on software-level attestation: firmware version checks, serial number databases, and chain-of-custody documentation. These work as deterrents but fail against a determined adversary who can also modify the firmware that reports the serial number. An HSM that has been physically modified to exfiltrate key material will correctly report its serial number from firmware — the firmware, after all, is on the modified chip and can report whatever it was programmed to say.
Cryptographic attestation from a ROM-fused key breaks this circularity. A key fused into read-only memory during wafer fabrication — before any firmware is written, before any packaging occurs, before any software can run on the chip — cannot be modified by any downstream supply chain participant. The key is in the silicon, not in flash, not in an eFuse that can be re-programmed, not in SRAM that can be overwritten. When that chip produces an attestation signed with the ROM key, the signature can be verified against the manufacturer's root CA, which holds the public key. No amount of firmware modification changes what the ROM contains.
The TCG DICE Architecture for Layered Boot Attestation
The Trusted Computing Group's Device Identifier Composition Engine (DICE) specification provides the architectural framework for extending ROM-anchored identity through the boot chain. DICE is specifically designed for constrained devices where a traditional TPM is too costly — which makes it directly applicable to standalone HSM ASICs that need to provide provenance attestation without a separate TPM.
The DICE model works as follows:
- Layer 0 (ROM): The unique device secret (UDS) is fused into ROM at manufacturing. On each boot, the ROM layer measures the next-layer firmware image (hash of the firmware binary) and uses the UDS to derive a Compound Device Identifier (CDI) specific to that firmware measurement:
CDI = KDF(UDS, Hash(firmware)). - Layer 1 (Boot firmware): Receives the CDI from Layer 0, uses it to derive its own identity keys, measures Layer 2 (the next stage), and derives a new CDI specific to that measurement. The original UDS is never passed up the chain.
- Layer N (Operating environment): Each layer's CDI is a hash of all previous measurements, bound to the specific firmware stack. An attestation quote signed with the Layer N CDI proves not just that the chip is authentic (ROM-anchored) but that this specific firmware stack is running on it.
The critical property is that each layer's CDI is only valid for one specific combination of hardware identity and firmware measurements. If the boot firmware is replaced — by a supply chain attacker who swaps the firmware flash — the CDI changes. The attestation certificate derived from the modified CDI won't chain to the manufacturer's root CA for the expected firmware measurements. The substitution is detectable.
From Wafer to Deployment: The Provenance Chain in Practice
Here's how a ROM-anchored attestation chain maps to the actual semiconductor supply chain steps:
| Supply chain stage | Provenance event | Cryptographic record |
|---|---|---|
| Wafer fabrication | ROM keys fused at wafer probe; unique per-die UDS or ECDSA private key written to ROM | Manufacturer signs per-die certificate with offline root CA; records chip UID + public key |
| Packaging and test | OSAT runs functional test; chip produces first attestation quote verifiable against CA | Test record includes attestation verification receipt; any chip that fails attestation is flagged |
| Firmware programming | Boot firmware written to flash; DICE Layer 1 CDI derived from UDS + firmware hash | Firmware hash signed by manufacturer; expected CDI published to attestation verification service |
| Distribution | Chip ships with attestation certificate bundle; distributor cannot modify ROM contents | Certificate bundle includes per-chip certificate + firmware signature + expected CDI range |
| System integration | Integrator verifies attestation before deployment; requires ROM-derived quote with current firmware hash | Integration test records pass/fail against expected certificate chain; anomalies trigger hold |
| Field operation | Periodic re-attestation verifies chip identity and firmware integrity haven't changed | Attestation freshness checked against nonce; replay attacks detectable by nonce binding |
The ROM Key: What Happens at Manufacturing
The practical implementation of ROM-fused keys varies across foundry processes, but the common pattern for TSMC 16nm FinFET (which our ASIC uses) involves laser fusing or electrical fusing of individual bits into dedicated one-time-programmable ROM cells at the wafer probe stage. The probe station runs custom test code that generates the key pair on-die — the private key is generated inside the chip and never exists off-chip in any form. The public key is read out over the probe interface and registered in the manufacturer's key database.
This is a critical operational point: the private key generation and registration must happen in the foundry probe environment, under secure manufacturing protocols. If the private key is generated off-chip and then programmed into ROM, the key existed somewhere outside the chip at some point. Any legitimate ROM-key attestation scheme requires that the private key is generated and remains on-chip from the moment of its creation.
"In our architecture, the ECDSA P-384 ROM key is generated by the on-chip TRNG during the wafer probe step, used immediately to sign a certificate request containing the chip's public key and manufacturing metadata, and the private key bytes are never output on any test or probe interface. The public key leaves the chip. The private key never does."
Counterfeit Detection in the Field
The scenario that ROM-anchored attestation specifically addresses is counterfeit chip insertion — a scenario that's more common in the HSM market than is publicly reported. A counterfeit HSM with modified firmware that exfiltrates key derivation material while appearing to function normally is indistinguishable by software means from a legitimate unit. Serial numbers can be cloned. Firmware version strings can be spoofed. The only reliable detection is cryptographic attestation that requires the ROM key.
For field deployment, this means implementing a provisioning flow that requires attestation verification before any key material is generated or loaded onto the device. A chip that fails attestation verification — either because its ROM certificate doesn't chain to the expected manufacturer root CA, or because its firmware measurement doesn't match the expected value — should never be provisioned, regardless of how it looks physically or what its serial number reports.
In our early access program, we've found that most security teams have the provisioning gate in their procedures but not consistently automated in their tooling. Verification that runs only during initial rack provisioning and not during firmware update events is a gap — a firmware update from a compromised build pipeline can still insert modified firmware after initial provisioning. Continuous attestation re-verification on firmware events closes this gap.
What to Look for in an HSM Vendor's Attestation Architecture
When evaluating any HSM for supply chain provenance requirements, the questions that distinguish genuine ROM-anchored attestation from software-level claims are:
- Where is the attestation root key generated? On-chip or off-chip? If off-chip, who had access to the private key during generation?
- Is the key in ROM (truly immutable) or in fuse-programmable memory that can be modified under special conditions?
- What does the attestation quote cover? Hardware identity only, or hardware identity plus firmware measurement?
- Is there a verification service that maintains the expected certificate chain and firmware measurements, and what are its availability guarantees?
- Does the attestation architecture follow TCG DICE, TPM 2.0 attestation, or a proprietary scheme? Proprietary schemes should be treated with more scrutiny since they haven't been subject to community review.
Supply chain provenance attestation is not a solved problem across the semiconductor industry. TCG DICE provides the right architectural primitives, and ROM-fused keys provide the right hardware anchor. But implementation quality varies significantly, and the manufacturing security protocols that protect key generation at the foundry are as important as the cryptographic design. Those protocols — and the security of the manufacturer's offline root CA — are worth scrutinizing in any evaluation.
