Aircraft Hardware Identity

Andi Lamprecht ·2026-05-11· 13 min read· Draft

1. The Hardware

Physical device identity is rooted in a hardware-bound private key — a cryptographic key generated inside a secure chip at manufacture that can sign data but can never be extracted, even by the OS or root processes.

For drones lacking any of the above, ATOMx supports a TPM-or-encrypted-vault fallback (Mar 12, 2026 ARB decision): a non-root encrypted vault inside a read-only Docker container. The trust tier degrades from L5 to L4. See Origins and Decisions §3.13.

2. Two Independent Certificate Chains

A drone’s hardware identity is established by two parallel X.509 chains. Neither is downstream of the other. They are cross-referenced by value to bind the drone body to the TPM chip inside it.

Chain 1 — TPM chip provenance

TPM Chip Manufacturer Root CA   (e.g. Infineon, STMicroelectronics, NXP)
  → EK Certificate

The EK Certificate is an X.509 certificate issued by the TPM chip manufacturer at the silicon factory. Its subject is the TPM chip itself — it contains the chip’s unique Endorsement Key (EK) public key and the chip’s serial number. It proves that a specific EK public key belongs to a genuine, unmodified TPM chip produced by that manufacturer. It is written to TPM NV storage at the silicon factory under a WRITE_ONCE policy and is permanently immutable.

Chain 2 — Drone body provenance

Drone OEM Root CA   (e.g. Skydio, Joby, Firestorm)
  → Drone Assembly Certificate

The Drone Assembly Certificate is an X.509 certificate issued by the drone OEM at the assembly line. Its subject is the drone — it contains the drone’s serial number and, critically, the EK public key of the TPM chip that was physically installed in that drone. It is written to TPM NV storage at assembly under a WRITE_LOCKED policy and locked before the drone leaves the factory.

The binding

The two chains answer different questions:

• Chain 1 answers: is this a genuine TPM chip?
• Chain 2 answers: did the OEM assemble a drone with this serial number, containing this specific TPM chip?

The EK public key is the cross-reference. It appears as the subject in the EK Certificate (signed by the chip manufacturer) and as a field in the Drone Assembly Certificate (signed by the OEM). A verifier checks both chains independently and confirms the EK public key in both certificates is identical. This proves the drone body and the TPM chip inside it are the same ones the OEM assembled — neither can be swapped out without invalidating one of the chains.

Forging the binding requires compromising both the TPM manufacturer CA and the Drone OEM CA simultaneously.

    flowchart TB
    TPMCA["TPM Manufacturer Root CA<br/>e.g. Infineon"]
    OEMCA["Drone OEM Root CA<br/>e.g. Skydio"]
    EK["EK Certificate<br/>subject: TPM chip<br/>contains: EK public key"]
    DA["Drone Assembly Certificate<br/>subject: drone body<br/>contains: drone serial + EK public key"]
    TPMCA --> EK
    OEMCA --> DA
    EK -. EK public key cross-referenced .-> DA
    classDef ca fill:#fff7d6,stroke:#b58900
    classDef cert fill:#eef3ff,stroke:#1f6feb
    class TPMCA,OEMCA ca
    class EK,DA cert
  

3. TPM NV Storage

TPM NV (Non-Volatile) storage is a small persistent memory area (typically 8–64 KB) on the chip, designed for storing certificates and data that must survive power cycles. Each NV index is created with an access policy:

The lock state of each NV index is queryable — a verifier confirms both are locked before trusting their contents.

4. Platform Configuration Registers (PCRs)

PCRs are a set of registers inside the TPM that record the integrity of the device’s entire software stack from power-on. They work by sequential hashing: each component in the boot chain measures the next and extends the relevant PCR — PCR_new = SHA256(PCR_current || new_measurement). Once extended, a PCR value cannot be reset without a full reboot.

At attestation time, the TPM produces a PCR Quote — a signed snapshot of all PCR values, signed by an Attestation Key (AK) that is itself proven hardware-bound via the EK. This allows a remote verifier to confirm not just that the device has a genuine TPM, but that the firmware, bootloader, and OS kernel match known-good hashes recorded at manufacture or certification time.

5. What PCR Attestation Covers — and Does Not

PCR attestation proves the integrity of the software stack running on the device. It does not cover the SoC itself — the CPU microcode, radio firmware, flight controller ASIC, or other chips on the board. The TPM sits beside the SoC on a bus (SPI / I²C) and has no visibility into what happens inside it. Hardware backdoors in silicon, or compromised radio chips, are invisible to TPM attestation.

SoC-level assurance is a supply chain problem, not a cryptography problem. It is addressed through:

• Platform certificates — issued by the drone OEM at assembly, asserting the specific bill of materials: which SoC, radio chip, and other components were installed
• NDAA compliance — for US government customers, asserting domestic component provenance and excluding prohibited foreign-origin components

This is the residual gap to surface to certification reviewers: TPM attestation is a strong claim about software state and a weaker claim about hardware composition.

6. At Runtime

The drone performs mTLS — presenting its Drone Assembly Certificate and signing a server challenge with the hardware-bound key. The server verifies the chain back to the Drone OEM Root CA and the EK chain back to the TPM manufacturer Root CA. The drone’s identity is proven without any shared secret.

For the lifecycle of a single in-flight signature, see Flight Lifecycle §3.

7. Linux / TPM Integration

Applications access the TPM through tpm2-tss and a PKCS#11 interface, which makes the hardware key look like a normal key to OpenSSL, curl, and any TLS library. Access to /dev/tpm0 is controlled by standard Linux file permissions — only privileged processes can use it.

8. Android: Key Attestation

Android extends the basic model with Key Attestation — a mechanism where the device proves to a remote server that a key lives in genuine certified hardware. The attestation certificate includes the device serial number, Android version, boot state (rooted / unlocked?), and the calling app’s package name. The chain:

Google Hardware Attestation Root CA
  → Device OEM intermediate CA       (provisioned by Google at Android certification)
    → Device certificate             (burned in at factory)
      → App key                      (generated on device, attested)

Why Google operates the root CA

Google provisions OEM intermediate CAs as part of Android device certification. This solves two problems: it protects the Play Store from fraudulent or modified devices, and it gives the entire ecosystem a universal trust anchor so any developer can verify any certified Android device without a bilateral relationship with each device OEM.

The implication is that Google is the ultimate trust anchor for Android device identity. For most applications this is acceptable. For sovereign or government use cases — including ATOMx — it is worth evaluating whether a custom OEM CA, independent of Google, is preferable. Android’s model collapses the two independent chains (§2) into one Google-rooted hierarchy.

9. Specification, Lifecycle, and Edge Cases

9.1 TPM Specification Minimum

ATOMx requires TPM 2.0 (Trusted Computing Group spec, ISO/IEC 11889-1:2015). TPM 1.2 is not accepted — its SHA-1-only PCR bank and limited algorithm set do not meet the cryptographic posture in PKI §3.1. The TPM must support:

• ECDSA P-256 and SHA-256 (mandatory)
• Restricted Signing Keys for Attestation Keys
• TPM2_ActivateCredential for AK enrollment
• NV index policies WRITE_ONCE and WRITE_LOCKED
• Hardware monotonic counters with replay protection

Discrete TPM packages are preferred over firmware TPMs (fTPM) running inside the SoC, because fTPMs share their threat surface with the SoC and undercut the dual-chain assumption in §2.

9.2 TPM Hierarchies and Key Derivation

TPM 2.0 defines three persistent hierarchies — Endorsement (manufacturer-rooted; holds the EK), Storage (owner-rooted; holds operational keys), and Platform (firmware-rooted). ATOMx aircraft use:

• Endorsement hierarchy for the EK, attested at onboarding
• Attestation Key derived under the EK as a Restricted Signing Key — used to sign PCR Quotes and the live-flight broadcast nonces
• Storage hierarchy for derived session keys for telemetry mTLS

The AK is enrolled at onboarding via TPM2_ActivateCredential — the platform encrypts a credential blob to the EK; only the genuine TPM can decrypt it and unlock the AK certificate.

9.3 OTA Firmware Updates and PCR Drift

A baseline PCR set is captured at onboarding (Flight Lifecycle §1.3). Legitimate firmware updates change PCR values — the baseline must roll forward without the aircraft being treated as compromised.

This is the only mechanism by which a baseline changes — there is no “operator-overridden” baseline.

9.4 RMA and Hardware Replacement

When a TPM, mainboard, or whole airframe is replaced, the EK ↔ Drone Assembly Certificate binding is invalidated (the TPM serial changes, or the Drone Assembly Cert no longer matches the new TPM’s EK). The aircraft must be re-onboarded from scratch:

Operator notifies ATOMx; previous operator-binding and pilot-assignments are migrated only after the new Drone Assembly Cert is verified.

9.5 NV Storage Constraints

NV indexes have finite write endurance (~100k writes typical). The WRITE_ONCE / WRITE_LOCKED policies (§3) protect against runtime writes; certificate rotation requires re-provisioning, not in-place rewrite. This is consistent with the “TPM Cert is permanent for the airframe” model.

9.6 NDAA / Section 889 / Blue UAS

For US government customers, the OEM must attest that components meet:

• NDAA Section 889 prohibitions on covered foreign-origin components
• Blue UAS / Trusted Component listing where required by program contracts
• TAA compliance for federal procurement

These are supply-chain attestations, not cryptographic proofs — see Threat Model §8. The Drone Assembly Certificate may carry an attestation extension naming the component-set provenance.

9.7 Drone-Specific Hardware Constraints

Drone TPM selection is constrained by:

10. For Non-Repudiation

A complete audit record requires both:

• Who — user identity chaining to a government IdP (login.gov, PIV) — see Pilot Identity §4
• What device — hardware identity chaining through the drone OEM CA to the TPM chip manufacturer CA (this page)

Together they produce evidence that neither the user nor ATOMx can fabricate without breaking a cryptographic chain that a third party can independently verify.

11. Cross-References

• The PKI substrate (algorithms, FIPS, root operations): PKI and Chains of Trust
• The lifecycle event that materializes this identity: Onboarding Aircraft
• How the manufacturer CA itself is provisioned: Onboarding Manufacturers
• How the hardware-bound key signs telemetry in flight: Flight Lifecycle §3
• How aircraft_assurance fields produced here are consumed: Authorization Package §4
• How the chain validates without server contact during austere ops: Disconnected Operations §6.2
• Hardware-identity-related threats (counterfeit TPM, capture/forensics, side-channel, supply-chain): Threat Model §8

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.