Hardware Security and Cryptographic Integration Questions

Direct answer

Treat the contract manufacturer (CM) as a capable party you must not need to trust with secrets, not as an adversary to exclude entirely: generate each device's cryptographic identity ON the device itself at first power-on, so the CM only ever handles public material; authenticate field updates against that same trust anchor with a monotonic anti-rollback counter; and gate shipment sign-off on milestones that actually attack the chain (overproduction attempts, replay attempts, rollback attempts) rather than just review it on paper.

Structured elaboration

Threat model

• The CM has physical access to unprogrammed silicon and the production line; the realistic risk is not "the CM is malicious" but "the CM's environment leaks or gets misused," whether through an insider, a subcontractor, or a compromised line-programming tool. The single worst outcome to design against is a SHARED secret across the whole production run: if every unit carries the same root key, one leak (or one dishonestly duplicated batch) compromises the entire fleet silently, with no way to tell a legitimate unit from a cloned one.
• Also in scope: a network attacker on the provisioning fixture's LAN, and a field attacker who has bought a real unit and wants to extract its identity key or push an unauthorized update to it.
• The threat model you must explicitly REJECT: "the CM is contractually obligated not to misuse the key we give them, so it's fine to hand it over." A contract doesn't stop a leak, and doesn't detect one either.

Getting a unique identity onto the device without trusting the CM

sequenceDiagram
    participant Dev as Device on fixture at CM
    participant Fix as Provisioning fixture
    participant CA as Your HSM-backed CA
    Dev->>Dev: generate private key on-chip using TRNG
    Dev->>Fix: send CSR (public key only)
    Fix->>CA: forward CSR plus batch quota token
    CA->>CA: check cumulative issued count against production quota
    CA-->>Fix: signed device certificate
    Fix-->>Dev: install certificate
    Note over CA,Fix: CM never sees the private key or an unaccounted valid certificate

• At first power-on in the provisioning fixture, the device's TRNG (True Random Number Generator, a hardware circuit harvesting genuine physical noise) generates a private key that never leaves the chip; the device emits only a CSR (Certificate Signing Request) over the fixture link.
• The fixture forwards CSRs to your OWN CA (Certificate Authority), which is HSM-backed (Hardware Security Module: a dedicated, hardened appliance that performs signing operations without ever exposing the private key it protects) and reachable only through an authenticated channel, never given signing authority directly on the CM's network.
• The CA tracks a cumulative issued-certificate count against your contracted production quota and stops issuing once that quota is met, regardless of how many further CSRs the fixture presents. Now the CM only ever sees public keys, certificates, and a unit count you can audit; without a signed certificate a cloned or over-produced unit can neither enroll in your fleet nor authenticate an OTA (over-the-air) update, so overproduction alone doesn't get an attacker a usable device.
• If the target silicon genuinely can't do on-device keygen, fall back to per-device (never shared) keys generated in an HSM at YOUR facility, individually encrypted to a fixture-specific transport key, and decrypted only inside the fixture's own protected boundary, never sitting in the clear on CM-controlled storage.

Field update authentication and anti-rollback

• Update images are signed under the same root hierarchy (or a scoped, delegated update-signing key), verified by the device against its own trust anchor, with the image's version checked against a monotonic counter before flashing, the same anti-rollback discipline any secure firmware update needs.
• No update path may ever accept an image authenticated only by a symmetric fleet-wide key; that reintroduces the overproduction failure mode at the update layer instead of the identity layer.

Validation milestones before sign-off

1. Provisioning fixture red-team test (hardware and security teams jointly): attempt to extract a private key from a device on the fixture, or replay a captured CSR/response pair to enroll a second device under one identity, before the pilot run ships.
2. Overproduction dry run: physically build one unit beyond the contracted quota and confirm the CA actually refuses to certify it, not merely that the policy document says it should.
3. Rollback attempt on a pilot unit: push a real, validly-signed OLD image at a pilot unit and confirm the anti-rollback counter rejects it.
4. Key-compromise tabletop: walk the revocation path end to end. Can you actually push a revocation list, or rotate the signing key, to devices already deployed with no second key slot? This is far more expensive to retrofit than to design in up front.
5. Joint hardware/firmware sign-off: hardware confirms which values are genuinely one-way and immutable in silicon (not merely "supposed to be locked by firmware convention"), and firmware confirms the boot chain actually enforces what the design document claims.

Worked example

A concrete quota-audit walk-through: contracted production run is 50,000 units. The fixture requests certificates in batches of 500; the CA maintains a running total of certificates issued for this product's provisioning profile. At 50,000 issued, the CA's policy hard-stops further issuance for that profile regardless of additional CSRs presented. If the CM quietly assembles 500 extra boards from leftover components, those boards can be physically built, but each one's CSR is refused a certificate once the quota is hit; an uncertified board has no valid identity, so it fails both the "join the fleet" enrollment check and later OTA authentication, since no update is addressed to an identity that was never issued. This shows the enforcement mechanism directly rather than just asserting that overproduction is prevented.

Security-property check: the claim is "capturing traffic between the fixture and the CA does not let an attacker mint a second valid certificate." Violate it: a network attacker on the CM's LAN replays a captured CSR/response pair, trying to get a second unit accepted under the same identity. The CA binds each issued certificate to the specific public key presented in that CSR; replaying the same CSR produces the identical certificate for the SAME public key, which your fleet-management system deduplicates and refuses to activate twice under one identity. If the attacker instead tries to substitute a different key into the replayed message, the original signature no longer validates for the new key, so the CA rejects it outright.

Trade-offs and pitfalls

On-device keygen only works as designed if the TRNG is genuinely validated; a weak or predictable TRNG quietly reduces to the same failure class as a shared secret, just harder to notice. Batch-quota enforcement requires the CA to be reachable during production, which the factory floor will resent as a new dependency and single point of production delay; plan for that operational cost explicitly rather than discovering it during the first outage. And validation milestones cost real pilot-run time and money to execute properly, which is exactly why skipping them is how the overproduction and clone problems end up shipping silently instead of getting caught in the lab.

Direct answer

Anchor trust in an immutable Boot ROM (mask ROM: code burned into the silicon mask at the factory, so it can never be altered after manufacture) that verifies the next stage using a public-key hash held in OTP (one-time-programmable fuses that can only be burned from 0 to 1, never reset). From there, each stage verifies the next: ROM verifies the bootloader, the bootloader verifies the signed application image and checks a monotonic anti-rollback counter before booting it. Store the root key hash in OTP, put any device-identity or long-term keys in a Secure Element (SE, a small dedicated hardened chip whose only job is protecting key material and crypto operations) or a TPM (Trusted Platform Module, a standardized crypto co-processor with measurement/attestation registers) depending on whether you need TPM-standard interoperability, and never let the private signing key or a shared fleet secret touch the contract manufacturer.

Structured elaboration

Chain of trust

• Stage 0, Boot ROM: minimal, immutable, hashes the public key it is handed and compares that hash against the fixed value in OTP; only then does it verify the stage-1 bootloader's signature against that key.
• Stage 1, bootloader: verifies the application image's signature and checks the image's declared version against the anti-rollback counter before ever branching into it.
• Stage 2, application/OS: can extend the same idea upward (a signed kernel, or Linux's dm-verity checking each block of a read-only filesystem against a hash tree).
• Distinguish verified boot (halts immediately on a signature failure) from measured boot (does not halt, just records a hash of what ran into a register for a later remote party to judge). Secure boot on a small embedded product is almost always verified boot; measured boot matters more once you want remote attestation, where a verifier judges a signed record of what ran rather than the device halting itself.

flowchart LR
    OTP["OTP fuses: root public-key hash (immutable)"] -.trust anchor.-> ROM
    ROM["Boot ROM (mask ROM, immutable)"] -->|verify signature via OTP hash| BL["Stage-1 Bootloader"]
    CNT["Monotonic anti-rollback counter"] -.checked before boot.-> BL
    BL -->|verify signature, check version >= counter| APP["Signed Application Image"]
    SE["Secure Element: device identity + wrap keys"] -.unwraps keys for.-> APP

Key storage decision

• OTP/eFuses: cheapest option, ideal for a small immutable value like a 32-byte SHA-256 hash of the root public key. A hash is enough because the ROM only needs to confirm "is the key I was handed the ONE authorized key", not store the key itself; storing a full 2048-bit RSA key in fuses is expensive and still needs the same immutability property a hash already gives you.
• Secure Element: a discrete chip (or a hardened block on the SoC) that holds device-identity and key-wrapping keys, exposes only a key-handle API (sign/verify/wrap/unwrap operations, never raw key bytes) to firmware. Use it for the per-device identity key and any keys that must survive a full firmware compromise.
• TPM: standardized (ISO/IEC 11889) discrete or firmware crypto module with PCRs (Platform Configuration Registers, which only ever extend/hash-chain, never get overwritten) for measured boot and a well-defined external attestation ecosystem. Reach for a TPM specifically when an external verifier already expects TPM-format quotes; otherwise a plain SE is usually cheaper and sufficient for a closed embedded product.

Anti-rollback

• A monotonic counter (fuse-backed bits, or an SE-backed non-volatile counter) that only ever increases; the bootloader rejects any image whose embedded version number is less than the counter's current value, even if that older image carries a completely valid signature.

Secure provisioning in manufacturing

• Never hand the contract manufacturer the private signing key or a single fleet-wide secret. Generate the per-device identity key on-chip using a TRNG (True Random Number Generator: a hardware circuit that harvests genuine physical noise, such as thermal or oscillator jitter, rather than a deterministic software algorithm), have the device emit only a public-key CSR (Certificate Signing Request), and sign it from your own CA (Certificate Authority), backed by an HSM (Hardware Security Module, a dedicated hardened appliance that performs signing operations without ever exposing the private key it protects), reached through an authenticated provisioning fixture. The CM only ever handles public material and a production count you can audit against your own signing quota.

Side-channel and downgrade mitigations

• Side-channel: implement the OTP-hash comparison and the signature check as constant-time operations. A naive byte-by-byte compare that returns as soon as it finds a mismatch leaks, through timing, how many leading bytes matched, letting an attacker guess the hash one byte at a time even without ever reading the fuse memory directly.
• Downgrade: bind the version field into the SIGNED portion of the image (so it cannot be edited without invalidating the signature) and check it against the anti-rollback counter, not just against "the version looks lower" logic living outside the signature.

Worked example

Claim under test: "an attacker who has captured a real, validly-signed OLDER firmware image cannot get it accepted as an update." Say the device is on version 4 and the anti-rollback counter reads 4. The attacker replays version-2 firmware, which really was signed by the legitimate key back when it shipped, so the signature check on it passes cleanly.

# illustrative pseudocode only, not a runnable snippet
if image.version < persisted_counter:
    reject_boot("stale image: version 2 < counter 4")

The bootloader still refuses it, because acceptance requires BOTH a valid signature AND image.version >= persisted_counter, and 2 < 4 fails the second check regardless of the first. This is the mechanism that actually enforces the "no downgrade" claim; a design that checks the signature alone and treats "signed by us" as sufficient would let this exact replay through, which is the failure mode real products have shipped.

Trade-offs and pitfalls

OTP fuse bits are finite and often shared across several purposes (root hash, lifecycle state, anti-rollback counter); running out mid-life bricks the update path, not just the boot path. A Secure Element adds real per-unit bill-of-materials cost that a pure-OTP design avoids, so match the choice to what the product actually needs to survive (full firmware compromise vs. just tamper-resistance of the root hash). A single root signing key with no revocation story is a catastrophic single point of failure if it ever leaks; a mature design keeps a second, offline backup key path or a multi-key scheme from day one, because retrofitting key revocation onto fielded devices with no second key slot is close to impossible.