The Embedded Cryptography Problem Is Actually a Hardware Root of Trust Problem

Most engineers who work on defense embedded systems treat cryptography as a solved problem. You pick a FIPS 140-3 validated module, wire it into your design, check the compliance box, and move on. The assumption baked into that workflow is that the cryptographic algorithm itself is the hard part.

Photo by Pixabay on Pexels.

It isn't. The algorithm is the easy part.

The genuinely hard part is answering one question: what does your system trust first? Before a single byte of encrypted data is processed, before any key is loaded, before any secure channel is established, something has to bootstrap the entire trust chain. That something is the hardware root of trust, and for most deployed defense hardware, it is embarrassingly fragile.

What a Root of Trust Actually Does

Think of it as the axle everything else rotates around. A hardware root of trust (HRoT) typically combines three capabilities: a source of cryptographic identity (usually a device-unique key burned into one-time programmable fuses or derived from a physically unclonable function), a secure boot process that validates firmware before execution, and a tamper-resistant environment where key material lives without exposure to the main processor bus.

When any of those three fail, the cryptography running on top of them is theatre. An attacker who can subvert the boot sequence or extract the root key doesn't need to break AES-256. Breaking AES-256 is computationally impossible. Corrupting the thing that hands AES-256 its key is not.

This is the actual threat model that matters in contested environments, and it is the one that most embedded defense designs underweight.

graph TD
    A((Physical Device)] --> B[One-Time Programmable Fuses / PUF]
    B --> C{Root Key Derivation}
    C --> D[Secure Boot Verification]
    D --> E[Firmware Integrity Check]
    E --> F[Key Loading into Secure Enclave]
    F --> G[Application Crypto Operations]
    C --> H[/Tamper Detection Logic/]
    H --> D

The PUF Problem Nobody Talks About

Physically unclonable functions have been the darling of academic hardware security for a decade. The pitch is elegant: every silicon die has nanoscale manufacturing variations that produce a unique, stable fingerprint without any key material needing to be stored. You can't extract what was never written.

The problem is stability under real-world conditions. PUFs produce noisy outputs. Temperature swings, radiation exposure, and device aging all shift the response. Military hardware operates across temperature ranges that would make a commercial silicon vendor wince. The error-correction codes needed to stabilize PUF outputs (called fuzzy extractors) introduce their own attack surface, and the helper data those extractors require has to be stored somewhere. That somewhere is often not hardened.

Several fielded defense platforms running PUF-based HRoTs have discovered in test that their PUF responses drift enough under thermal cycling to fail authentication at extreme cold soak. That's not a hypothetical. It's a reliability problem that lands squarely on the program office that skipped environmental characterization because schedule pressure was real.

Secure Boot Is Only as Good as the Signing Infrastructure

Even a well-implemented PUF doesn't protect you if your code-signing process is compromised. Secure boot works by verifying a cryptographic signature on firmware before executing it. The verification key is anchored in the hardware root of trust. But the signing key, the private half of that pair, lives somewhere in your development or manufacturing pipeline.

Where exactly? That question is uncomfortable to ask and surprisingly hard to answer at many defense contractors. The private signing keys for deployed platforms are sometimes managed through processes that would embarrass a mid-sized fintech company: spreadsheets tracking who has access, HSMs that haven't been audited in three years, key ceremonies that nobody has revisited since the program's initial contract.

A compromised signing key means an adversary can produce firmware that your hardware will accept as authentic. The HRoT does exactly what it was designed to do; it trusts the signature. The trust chain is intact all the way to the point where it was poisoned.

Where the Industry Is Heading

The most serious work happening right now combines open hardware security specifications with formal verification. The OpenTitan project, originally a Google initiative now stewarded by lowRISC, is producing a fully open-source silicon root of trust with a verifiable hardware design. Several defense primes are watching it closely. A few are quietly contributing.

The appeal is auditability. A proprietary HRoT is a black box. You trust the vendor's claims about its security properties. An open design with formal proofs of specific properties lets a government customer actually verify what they're deploying, at least at the logic level.

Parallel to that, DARPA's AISS and SHEATH programs have been pushing toward automated insertion of security features into chip designs, attempting to make HRoT capabilities a standard output of the design toolchain rather than an afterthought bolted on by a security team at tapeout.

None of this solves the signing infrastructure problem. That one requires organizational discipline more than clever silicon, and organizational discipline is always the harder sell.