Firmware replacement is one of the quietest and most consequential attack vectors against autonomous platforms. An adversary who can load unauthorized firmware onto a payload processor doesn't need to jam the communications link or physically disable the aircraft — they can degrade, misdirect, or falsify the classification output that mission planners rely on. Our team spent a significant amount of time early in the KS-100 development cycle working through exactly this threat model, and the conclusion was unambiguous: software-only security measures are insufficient. The protection has to start in hardware.
This article covers what a hardware root of trust is, how it applies specifically to UAV edge-AI payloads, and the practical design decisions that separate a genuine security architecture from one that looks secure on paper but fails in the field.
What "Root of Trust" Means in Practice
A root of trust is the first piece of code executed when a device powers on — the foundation that everything else in the boot sequence depends on. If the root of trust can be compromised or bypassed, no subsequent security mechanism is reliable. The critical property of a hardware root of trust (HRoT) is that the trust anchor is stored in immutable hardware — typically in one-time programmable (OTP) fuses or mask ROM — and cannot be overwritten after manufacturing.
The boot chain then looks like this:
- Stage 0 (ROM bootloader) — Immutable code in silicon ROM. Reads the Stage 1 bootloader from non-volatile storage and verifies its cryptographic signature against a public key embedded in OTP fuses. If verification fails, the device halts. Full stop.
- Stage 1 (secondary bootloader) — Signed by the hardware manufacturer or program-level key authority. Responsible for initializing DRAM, setting up secure memory regions, and verifying the next stage.
- Stage 2 (OS/RTOS loader) — Signed by the system integrator. Loads the operating environment and verifies all component images before transfer of control.
- Stage 3 (inference model + application) — Signed by program-specific keys. For edge-AI modules, this includes the neural inference graph itself, not just the application code.
The chain-of-custody matters at every stage. A module that verifies Stage 1 but executes Stage 3 without verification has a gap in the boot chain that can be exploited. We've reviewed firmware security documentation from several competing edge-compute modules on the market and found that this gap — verification through the OS but not through the application layer — is common. It's the difference between a secure loader and a secure system.
The Threat Model for UAV Payloads
Defense supply chains for UAV payloads involve a long sequence of hands: hardware manufacturer, board bring-up contractor, sensor integrator, prime subcontractor, depot, forward operating base. Each transfer is a potential injection point for unauthorized firmware. The threat isn't hypothetical — DARPA and NSA research programs have documented supply chain firmware attacks against embedded hardware, and the defense industrial base has treated this as a credible operational risk since at least the late 2010s.
For an ISR payload specifically, the risk has two dimensions. First, an adversary could degrade classification performance by modifying model weights to increase false negative rates — the module continues operating, returns valid-looking output, but misses the contacts it should be detecting. This attack is difficult to detect in flight and could persist across multiple sorties before analysts notice a pattern in the post-mission data. Second, a compromised firmware could actively falsify STANAG 4609 metadata output — writing fabricated target coordinates or suppressing classifications of specific contact signatures.
Neither attack requires physical access to the aircraft during operations. Both require access to the firmware update path at any point in the supply chain before deployment.
ECDSA Signing and Key Management Architecture
The KS-100 uses Elliptic Curve Digital Signature Algorithm (ECDSA) with 256-bit keys for all firmware and inference graph verification. We chose ECDSA over RSA-2048 for two reasons: the signature verification is faster (relevant for boot time), and the key material is significantly smaller (32 bytes versus 256 bytes), which matters when embedding public keys in OTP fuse arrays where capacity is limited.
Key management is where many programs underinvest. The signing key is only as secure as the key management infrastructure around it. For program-specific deployments, we support a two-tier key hierarchy:
- Root key authority — held by the program office or designated key custodian. Used only to sign intermediate authority certificates. Should never touch a networked system.
- Program signing key — delegated authority for signing inference model updates. Can be rotated without reflashing the device OTP fuses, because the root key authority signs the new program key and the device verifies the delegation chain.
This separation means that if a program signing key is compromised — which is a realistic risk for a key that needs to be operationally accessible — the root key authority can issue a new signing key and revoke the old one without hardware changes to deployed modules. The revocation is propagated the next time a firmware update is pushed to the module.
Inference Model Updates as a Separate Attack Surface
Most hardware security frameworks for embedded systems stop at the OS/RTOS level. For edge-AI modules, that's insufficient. The inference model itself — the neural network weights and graph structure — is a critical executable artifact. A module that runs a modified inference graph produces different classification results regardless of whether the operating system is intact.
This is a relatively new attack surface that traditional firmware security frameworks weren't designed to address, because traditional embedded systems don't have a large, mutable, functionally critical binary artifact separate from the application code. Neural inference models can be 10-50 MB in size. They're updated relatively frequently as training data improves or new target classes are added. And their outputs are trusted by the humans and systems downstream without real-time validation of the model's integrity.
The KS-100 model partition is separate from the OS partition. Each inference graph stored in the model partition carries an ECDSA signature that the secure boot chain verifies before any model is loaded for inference. The module maintains up to four signed inference graphs simultaneously. Unsigned or signature-invalid graphs are refused — the module falls back to the most recently verified valid graph and logs the rejection event with a timestamp for post-mission review.
Hardware Attestation for Supply Chain Verification
Beyond boot-chain security, some programs require the ability to verify at any point — pre-deployment, mid-program, post-incident — that a specific module is running exactly the firmware and model versions it's supposed to be running. Hardware attestation provides this.
The attestation mechanism works as follows: a challenge is issued to the module (typically over the avionics bus or a dedicated attestation interface), and the module responds with a signed measurement — a cryptographic hash of the currently loaded firmware and inference graph, signed by a device-unique key that was provisioned during manufacturing and is not exportable. The verifier can check the signature and compare the hash against the known-good measurement for the authorized firmware version.
This process takes under 200ms on the KS-100. The device-unique key used for attestation is separate from the program signing keys — it can't be used to sign firmware updates, only to sign attestation responses. That separation ensures that compromise of the attestation key doesn't enable firmware attacks, and vice versa.
MIL-STD-810G Environmental Considerations for Security Hardware
Security chips and OTP fuse arrays have their own environmental limits. Fuse programming currents are temperature-sensitive; a fuse that blows correctly at 25°C may not blow reliably at -40°C, which is within the MIL-STD-810G operating range for airborne equipment. We validate our fuse programming at both temperature extremes before any production batch ships. It adds test time, but a partially programmed OTP array is a security vulnerability — if key bits don't program correctly, the boot chain comparison can fail in ways that either lock the device or, worse, pass an incorrect signature check on specific bit patterns.
Cryptographic accelerators in the NPU also consume more power during signature verification than during inference — a brief peak of roughly 2W above the normal operating baseline. That peak needs to be accounted for in the power budget for boot time, since the UAV's power rail may be less stable during the initial power-on sequence before the platform's power management comes fully online.
What Good Security Documentation Looks Like
When evaluating edge-AI modules for defense payloads, the security documentation you should ask for isn't a general description of "secure boot support." It's specific answers to these questions:
- What is the immutable root: ROM or OTP? Who programmed it and at what life-cycle stage?
- Is the inference model verified in the boot chain, or only the OS/application?
- What is the key management architecture, and how are program-specific signing keys provisioned?
- Does the module support hardware attestation, and what is the attestation response format?
- How is revocation handled if a signing key is compromised?
Vague answers to these questions — "we use industry-standard security practices" — indicate that the security architecture hasn't been designed for this threat model. For a payload that generates classified target tracks, that's not an acceptable answer.
Security by design, from the fuse layer up. That's the only architecture that holds up when the supply chain is long and the adversary has time and motivation. We built the KS-100 with that reality as the starting point.
