Crypto & Anti-Tamper in avionics is the trust core that proves software integrity at boot, keeps keys non-exportable, detects physical or fault-injection intrusion, and can rapidly zeroize secrets. It centers on a Root of Trust (RoT) that enforces the chain of trust, validates updates, manages key lifecycles using proven randomness, and records auditable security evidence.

Output of this page is evidence: verifiable boot state, key usage boundaries, tamper events, and zeroization completion signals.

Attacker capability tiers (what changes across field, depot, lab, supply chain)

• Field access (minutes–hours): limited tools, opportunistic access to maintenance ports or enclosures; aims for quick extraction or bypass.
• Depot access (hours–days): device can be opened; parts may be swapped; storage can be probed; update media and service workflows become a target.
• Lab attacker (days–weeks): fault injection (voltage/clock/temperature), side-channel probing, micro-probing; attempts to break extraction boundaries.
• Supply chain adversary: pre-injection of modified firmware, counterfeit RoT devices, or contaminated provisioning steps; targets trust anchors before deployment.

Design implication: defenses should be graded (block, detect, limit blast radius, prove state) rather than assuming a single attacker profile.

Protected assets (prioritized by blast radius)

Rule of thumb: if compromise enables persistent impersonation or silent downgrade, it is S-Class and must be non-exportable or provably measured.

Attack surface → Control point → Evidence (engineering-ready)

Use this table as a chapter map: each later section should strengthen a control point and define its evidence format.

Engineering closure checklist (use as “chapter exit criteria”)

• Every control point has a named evidence artifact (record, counter state, event chain, wipe proof, TRNG status).
• Every evidence artifact has a collection rule that does not leak secrets (no raw keys, no sensitive dumps).
• Tamper response is graded and deterministic: same trigger class → same action + same reason codes.
• Power/clock anomaly handling is auditable: anomaly counters correlate with boot failures and tamper escalation.

Next chapters should reference this mapping table instead of restating threat theory, keeping the page vertically deep and non-overlapping.

• Non-exportable root secrets: root key / seed never leaves the RoT boundary; only “use” operations are exposed (sign/unwrap/derive).
• Signature verification: verifies image signatures and certificate chains; rejects unknown issuers; records deterministic reason codes.
• Key derivation & wrapping: derives KEKs/DEKs and wraps blobs inside the RoT policy boundary; enforces per-key access control.
• Anti-rollback state: monotonic counter / version state updated inside the RoT; prevents downgrade even if external storage is modified.
• Optional secure time: only required when evidence timelines need trusted monotonicity beyond a boot counter (e.g., signed event sequencing).

Implementation rule: each duty should map to a named evidence artifact (counter state, boot record, tamper state snapshot), never to “trust by design intent.”

Decision table (5–8 criteria that force clear boundaries)

Selection outcome should explicitly state which duties are enforced inside the RoT and which evidence artifacts will be collected in validation.

• ROM / immutable stage: anchors trust (pinned hash/key) and verifies the first loadable stage.
• 1st stage: performs minimal initialization; verifies the second stage and enforces debug policy gates.
• 2nd stage / loader: verifies OS/RTOS image(s), critical drivers, and the update manifest policy.
• OS/RTOS: verifies trusted services and configuration; optionally records measured state for audit.
• Application: verifies mission-critical tasks/modules and enters mission mode only under valid state.

Verification should be bound to an RoT-enforced anti-rollback counter. “Valid signature” must not be sufficient for downgrade.

Engineering pitfalls (symptom → cause → fix)

• Certificate rotation bricks fleet: issuer changes without overlap window → implement dual-trust window and versioned chain policy.
• Debug unlock becomes a backdoor: unlocking not bound to RoT policy or not audited → require authenticated unlock token + time limit + reason codes.
• Boot-time budget blow-up: excessive chain depth or heavy algorithms → partition verification (critical first) while preserving measured evidence for the rest.
• Power loss during update causes “brick”: non-atomic writes → use A/B slots, write-then-verify, and commit flags only after full verification.
• Signed downgrade still boots: rollback counter outside RoT or not checked at every stage → keep monotonic counter inside RoT boundary and enforce per-stage.

A secure boot design is “done” when every pitfall above has a deterministic test case and produces expected evidence artifacts.

Measured boot records stage-by-stage measurements (hashes and policy snapshots) so “what executed at boot” can be proven later. Attestation signs a summarized evidence package inside the RoT and lets a verifier decide compliance (allowed version ranges, revocation state, debug/tamper gates). The output is a deterministic, storable artifact—useful for audits, maintenance checks, and fleet governance.

Secure boot vs measured boot (practical comparison)

Design rule: treat measured boot as a compliance proof layer; secure boot remains the enforcement gate.

Minimal attestation structure (evidence shape, not protocol)

• Measurement: stage hashes (ROM/stage1/stage2/OS/app), plus a compact measurement digest for signing.
• Policy snapshot: debug lock state, rollback counter, tamper state, TRNG health flags (non-secret indicators).
• Nonce binding: evidence must include a verifier-provided challenge (or a verifiable freshness token) to prevent replay.
• RoT signature: RoT signs the evidence digest that includes nonce + counter + measurements to make it unforgeable and time-ordered.
• Verifier decision: checks allowlists/versions/revocations and records the verdict with the evidence for audit.

Avoid protocol sprawl: keep the chapter at “inputs/outputs and invariants.” Transport can vary by platform without changing evidence validity.

Engineering rules (nonce, anti-replay, retention, and version strategy)

• Nonce must be signed: challenge value must be included in the signed material; otherwise old evidence can be replayed.
• Replay defense needs two anchors: nonce freshness plus a monotonic counter/policy version snapshot prevents “old-but-valid” reuse.
• Retention must be non-secret: store hashes, reason codes, counters, and signatures—never store raw secret material or unwrap outputs.
• Version strategy must be explicit: evidence should carry version identifiers and policy IDs so verifier rules stay deterministic over time.
• Audit must be explainable: verifier verdict should be reproducible from evidence + policy rules, not from undocumented heuristics.

Validation idea: replay the same evidence with a new nonce and confirm it is rejected; change only policy rules and confirm verdict changes are explainable.

• Root key / root seed: exists only inside the RoT; used for signing or deriving other keys; never used to encrypt bulk data.
• KEK (Key Encryption Key): wraps/unwraps DEKs; defines who can unlock data keys; must not be reused across devices as a single shared secret.
• DEK (Data Encryption Key): encrypts data/config; often stored only as a wrapped blob; rotates on schedule or on events.
• Session keys: short-lived keys for runtime sessions; should be volatile and derived from TRNG/DRBG + policy.

Practical rule: Root never leaves RoT; KEK governs DEK access; DEK binds to data domains; session keys do not persist.

Key storage model (slots, wrapping, and non-exportability)

• Key slots: RoT-managed identifiers with attributes (usage, lifetime, origin, and exportability = NO).
• Wrapping boundary: DEKs are stored externally only as wrapped blobs (ciphertext + metadata), never as plaintext backups.
• Policy/ACL: host can request “unwrap-and-use” but cannot request “export plaintext,” and every request is policy-checked.
• Metadata is part of security: key version, domain ID, and policy ID must bind to wrapping to avoid mix-and-match attacks.

Non-exportable means “no plaintext extraction path exists,” not merely “the API does not document export.”

Key table (type / where stored / who can use / rotation)

Service boundary: RMA procedures must never require exporting root/KEK material; recovery should be re-provisioning, not “secret backup restore.”

Lifecycle checklist (generate → provision → use → rotate → revoke → destroy)

• Generate / provision: key origin is defined (TRNG/controlled injection); device identity binds to certificate chain.
• Activate: switch from factory mode to deployed mode; lock debug/provision interfaces with auditable state.
• Use: expose only “use” operations; log non-secret audit events (reason codes, key version, policy ID).
• Rotate: allow overlap windows (old+new key versions) and define deterministic cutover rules.
• Revoke: maintain a revocation policy keyed by version/domain; verifier decisions remain reproducible.
• Destroy / zeroize: define which slots, caches, and staging buffers are cleared; ensure correct behavior on reset/power loss.
• RMA / repair boundary: define what can be preserved (non-secret logs) vs what must be re-provisioned (keys/identity).

Validation idea: prove that cloning a wrapped DEK blob onto another device does not decrypt data (device/domain binding must fail deterministically).

Common pitfalls (what breaks, and why it becomes unrecoverable)

• Reusing one KEK across devices enables fleet-wide compromise after one leak → enforce per-device or strictly segmented domains.
• Key version confusion makes verifier decisions inconsistent → bind key version + policy ID into wrapping and evidence.
• Over-detailed logs leak sensitive context → store reason codes and versions, never raw secrets or unwrap results.
• “Backup” that contains recoverable root material defeats zeroize → root secrets must be non-backupable by design.
• Dev/prod mixing creates supply-chain shortcuts → isolate environments and make the switch-to-deployed state auditable.

TRNG is the entropy source. DRBG is the controlled expansion mechanism. Both must be backed by health tests and a clear failure policy, because temperature, voltage, aging, and startup conditions can reduce effective entropy. A defensible design produces audit-safe evidence (reason codes, counters, and status snapshots) without exposing secrets.

TRNG vs DRBG (what each “owns” in practice)

• TRNG owns entropy: it must produce unpredictable raw bits under real operating conditions (cold start, hot soak, brownout margins).
• DRBG owns determinism control: it expands entropy into output with defined state, reseed rules, and testable failure handling.
• Conditioning is not optional: whitening/conditioning reduces bias, but does not replace health tests that detect “entropy collapse.”
• Security decisions depend on freshness: key generation and nonce creation should be gated by TRNG/DRBG health state.

Review-friendly framing: “entropy is measured and policed,” not “randomness is assumed.”

Entropy sources (high-level) and the evidence that matters

The source type is less important than what can be measured and monitored. Typical sources include jitter-based oscillators, thermal-noise-based circuits, and metastability-based elements. In all cases, the defensible part is the evidence chain: health tests → reason codes/counters → policy gates.

• Startup entropy shortfall: early bits may be biased before steady-state; require startup tests and “no-keygen-before-healthy.”
• Temperature/voltage drift: bias and repetition can rise at corners; require continuous tests and drift-aware alert thresholds.
• Entropy decay/aging: long-term degradation can hide until stressed; require trendable counters and periodic self-check routines.

TRNG/DRBG health-test checklist (what reviewers expect to see)

Implementation invariant: evidence must be non-secret (no raw entropy samples, no internal state dumps).

Failure policy (safe handling without guessing)

• Level 0 — log only: transient anomalies produce reason codes and counters for review, without changing security posture.
• Level 1 — gate sensitive ops: block new key generation and nonce issuance; allow limited non-secret functions.
• Level 2 — key lockdown: deny unwrapping/signing operations until health is restored and verified.
• Level 3 — security escalation: if combined with tamper or repeated failures, trigger stronger actions (session wipe / zeroize path).

The policy should be deterministic and testable: same input health state → same allowed/denied outcomes.

A “good” intrusion/tamper design has controllable false alarms, traceable events, a short response path to security controls, and high bypass difficulty. The system should support graded actions—log only, key lockdown, session wipe, and full zeroize—while producing audit-safe evidence (sensor ID, reason codes, latch state, and counters) that enables reproducible post-event review.

Tamper sensor categories (what they mitigate)

• Lid / enclosure open: detects physical access to internals; pair with latch + self-test to avoid simple bypass.
• Light exposure: detects enclosure breach; best used with multi-point sensing and correlation (not a single photodiode).
• Temperature extremes: detects thermal attacks and abnormal service conditions; require debounce and policy thresholds.
• Acceleration / shock: detects forced access events; use correlation to reduce false positives.
• Power / clock anomaly: detects glitch-style manipulation attempts; tie into shortest-path security gating.
• Tamper mesh (probe grid): detects probing; require continuity monitoring and open/short detection with latching.

Keep the scope security-focused: only tamper-relevant sensing and response are covered here.

Response levels (log → lockdown → session wipe → zeroize)

• Log only: record event chain with sensor ID and reason code; used for low-confidence or single-sensor anomalies.
• Key lockdown: immediately deny signing/unwrapping and other sensitive key operations in the RoT boundary.
• Session wipe: clear volatile session material; forces re-attestation and re-establishment of trusted state.
• Full zeroize: destroy selected RoT-managed secrets and set a latched “tamper” state requiring controlled recovery/re-provisioning.

The response ladder should be deterministic and testable with fault injection and bypass attempts.

Matrix: sensor → attack mitigated → recommended response → evidence

Use correlation to control false alarms: multi-sensor triggers can justify stronger actions than single noisy channels.

“Zeroize” means sensitive material becomes non-recoverable or non-usable under a latched security state. A defensible implementation identifies every storage location (RoT, external NVM, RAM/cache/DMA), defines trigger sources and response levels, meets a worst-case time budget, and produces audit-safe evidence (reason codes, latch state, counters, and verification status) without exposing secrets.

Zeroize targets (what must be covered to avoid “leftovers”)

A reliable zeroization definition starts with targets and where they can persist. Group targets by boundary and by persistence risk to avoid missing common leak paths.

Non-negotiable: include cache/DMA paths and any “diagnostic dump” region that might capture plaintext.

Trigger sources and response ladder (avoid over-destruction)

Zeroization should be policy-driven. Not every abnormal event should immediately destroy all secrets. Use a response ladder so serviceability is not accidentally eliminated.

• Tamper (high confidence): latch security state → key lockdown → session wipe → zeroize (per policy).
• Debug policy violation: latch violation → key lockdown; escalate on repetition or correlation with tamper.
• Attestation/authentication failure: deny privileged actions; escalate after threshold/time-window rules.
• Maintenance mode switch: wipe sessions; restrict key ops; require controlled re-verify before full enable.
• Commanded zeroize: accept only via authenticated control path; always produce an evidence record.

Keep the shortest path: triggers should reach the RoT boundary without depending on untrusted host software.

NVM “irreversibility” (what can be guaranteed under power loss)

Not all storage behaves the same under wear leveling, journaling, or partial writes. A defensible approach defines two safety goals: (A) non-recoverable (material is physically destroyed), or (B) non-usable (latched policy prevents use even if remnants exist).

• Prefer “no plaintext in external NVM”: store only wrapped blobs that require RoT approval to unwrap.
• Invalidate first: make old blobs/config invalid immediately, so a power cut cannot “restore” usability.
• Overwrite when required: when policy demands physical removal, overwrite with verification readback (concept-level).
• Latch blocks recovery: after a tamper/zeroize latch, deny unwrap/sign operations and require controlled re-provisioning.

The safest definition under brownout is often “non-usable under latch,” because physical erase may not complete for every medium.

Time budget and minimal energy window (link to hold-up design)

Zeroization must complete within a worst-case t_total budget: detection → latch → erase/wipe → verify → proof log. The platform must guarantee a minimal energy window to meet t_total at the worst operating corner.

• t_detect: trigger detection and debounced qualification.
• t_latch: security latch set (no further secret use allowed).
• t_erase: wipe targets (RoT slots, RAM/cache/DMA, policy-defined NVM actions).
• t_verify: verify outcomes (status flags, deny counters) + record proof evidence.

System-level energy delivery methods are covered by the Hold-Up & Emergency Power page; this chapter only defines the required window.

Zeroize checklist (scope · trigger · time · evidence)

Secure manufacturing does not mean “a powerful fixture with secrets.” It means per-device identity and keys are created under control, injected into the secure boundary (RoT/SE/HSM-class element), verified via a measurable evidence step, and then the device is moved to a production-locked lifecycle. Serviceability is preserved through controlled maintenance modes that restrict operations and require re-verification.

Roles and boundaries (who can do what)

Keep “serviceability” by controlling modes, not by making debug permanently open.

Factory loop (generate → inject → verify → lock → ship)

• Generate identity material: per-device identity and certificate chain are prepared in a controlled environment.
• Inject into secure boundary: secrets land in RoT/SE slots; external storage holds only wrapped/derived artifacts.
• Verify: run an evidence step (attestation-style) to confirm keys, policy, and firmware state.
• Lock lifecycle: switch from development to production (debug restrictions, rollback policy enabled).
• Ship with evidence bundle: fingerprints, policy ID, lock state, version IDs—no secrets.

Fixtures should trigger operations, not store reusable secrets.

Maintenance / RMA boundary (secure recovery without bypass)

A service workflow should support controlled re-provisioning while keeping the RoT boundary intact. A practical approach is to use a restricted maintenance mode that allows updates and re-binding, but not secret export.

• Entry control: authorized transition into maintenance mode, time-limited, with explicit evidence logging.
• Allowed actions: firmware reflash, certificate refresh, controlled reprovisioning steps.
• Denied actions: exporting root/KEK, permanent debug unlock, bypassing verify/attestation.
• Exit control: re-verify state and re-lock lifecycle before returning to production mode.

Common pitfalls (and how to prevent them)

• Fixture leakage: a programming fixture stores reusable secrets → prevent by removing secrets from fixtures and enforcing per-device derivation/injection.
• Key reuse across a batch: “same KEK for convenience” → prevent with per-device uniqueness and domain binding; detect via evidence checks.
• RMA bypass: service path can skip RoT checks → prevent with maintenance mode limits and mandatory re-verify before relock.

Evidence-based gates (verify + lock state) turn these pitfalls into detectable failures, not silent compromises.

H2-11 · Validation & attack-informed test plan (what proves it’s done)

Tip for audits: keep a one-page “evidence dictionary” mapping each reason code/counter to the test rows above. That makes review faster than long prose.