Hardware-Rooted Secure Boot for Field-Deployed Compute

Why this matters more in the field

A compute device that lives in an office can rely on physical security. The threat model is "someone might run unsigned software on it," and a signed-firmware enforcement is enough.

A compute device that lives in a forward-deployed vehicle, a perimeter sensor, or an unattended unmanned platform has a different threat model:

• Physical capture. An adversary takes the device, opens it, and tries to extract its firmware, its keys, and its data.
• Supply-chain tamper. An adversary intercepts the device before it reaches the user and modifies firmware or hardware to enable later exfiltration or sabotage.
• Persistent rootkit. An adversary gains code execution remotely, then installs a rootkit that survives reboots and OS reinstalls.

Each maps to a different layer of the trust chain. None are solved by signed firmware alone.

The trust chain

A defense-grade trust chain is a sequence of layers, each authenticating the next, starting from an immutable root:

1. Boot ROM — burned into silicon at fabrication. Cannot be modified. Contains the verification key for the first stage of firmware.
2. First-stage bootloader — signed by the silicon vendor's or platform owner's private key, verified by the boot ROM. Loads and verifies the next stage.
3. Second-stage bootloader — verified by first-stage. Typically loads U-Boot or equivalent.
4. Kernel and initramfs — verified by second-stage.
5. Root filesystem — measured (hashed) and either verified against a known-good hash list (dm-verity) or attested to a remote verifier.
6. Application runtime — signed and version-pinned applications, with signature verification at load time.

Each layer hashes the next before passing control. The hashes accumulate in a Platform Configuration Register (PCR) in the device's TPM or equivalent secure element. The final PCR value is a cryptographic summary of the entire boot — any modification anywhere in the chain produces a different PCR value.

Where physical-capture resistance comes from

The boot chain prevents an attacker from running modified firmware on a stolen device, because the silicon's boot ROM will reject any first-stage signed by the wrong key. The attacker cannot replace the boot ROM (it's immutable) and cannot extract the signing key (it's in an HSM, not on the device).

Data-at-rest is harder. A stolen device's storage contains sensitive operational data; the boot chain does not protect that. The standard answer is full-disk encryption with the key sealed against the PCR values: the disk can only be decrypted on a device whose boot has produced the expected sequence of measurements. A stolen device's storage is unrecoverable because:

• The decryption key is not stored in the clear anywhere.
• The boot environment on a different device produces different PCRs, which means the sealed key cannot be unsealed.
• The boot environment on the same device, but with modified firmware, also produces different PCRs.

Where supply-chain-tamper resistance comes from

The trust chain above does not protect against tamper at the boot ROM level — that's the trust root, and if it's compromised the entire chain is compromised. Defenses against that are physical:

• Anti-tamper coatings on the package that destroy the silicon if probed.
• Authenticated parts sourcing through DLA-approved channels for sensitive components.
• Receiving inspection with X-ray and electrical signature comparison against a golden reference.

For lesser components (bootloader, kernel, etc.), the trust chain itself provides supply-chain tamper resistance: an adversary who modifies the bootloader between manufacturing and deployment cannot match its signature against the boot ROM's public key.

Implementation realities

Two recurring lessons from teams that have deployed this chain in the field:

Key management is harder than the cryptography. The signing keys for the firmware images are themselves the highest-value targets. Where do they live? Who has access? How are they rotated? How are revocations distributed to fielded devices? These are organizational questions, not technical ones, and they account for the majority of operational secure-boot failures in production.

Recovery is a first-class concern. A device whose firmware is corrupted (legitimate corruption — flash failure, power-loss during update) must be recoverable. The standard architecture is to maintain two firmware slots and atomically switch between them on successful boot. Without this, a firmware update that bricks one device in a thousand becomes an unacceptable failure rate at fleet scale.

Sustainment relevance

A sustainment platform that runs on fielded compute is, itself, a target. Its sensor inputs, its operational decisions, its data lake — all are valuable to an adversary. The trust chain above is the foundation that lets the platform make integrity guarantees about its own operation, and lets the higher echelon make trust decisions about what a particular fielded node is telling them.