diff --git a/artifacts/design-decisions.yaml b/artifacts/design-decisions.yaml index 011d366..cb04238 100644 --- a/artifacts/design-decisions.yaml +++ b/artifacts/design-decisions.yaml @@ -664,6 +664,12 @@ artifacts: - INTEGRITY (the safety-critical part of update, same either way): sigil-signed images (embedded sig / Sigstore / SLSA provenance) + relay-sec authenticated/ anti-replay transport + anti-rollback; the bootloader verifies before flashing. + REFINED by DD-020: this sigil + relay-sec layer is the SOFTWARE FALLBACK of a + HARDWARE-FIRST root-of-trust - the production/certified build anchors the boot + chain in i.MX RT HAB (fused SRK + CSF-signed loader) and the keys in the SE050 + secure element, with this software path used when the hardware is open/ + unprovisioned/unhealthy. So integrity is no longer software-only; sigil + relay-sec + stay as the fallback + the application-layer E2E, with HW as the root. So the storage/ROM route (jess owns its drivers, no ROM in flight) is CONFIRMED for flight; the only ROM use jess might keep is the update bootloader's NOR write (b1) - bounded, on-ground, integrity-gated. Renode fidelity follow-on: model the @@ -902,3 +908,80 @@ artifacts: - type: satisfies target: REQ-PIX-017 + + - id: DD-020 + type: design-decision + title: Root-of-trust = HARDWARE-FIRST (SE050 secure element + i.MX RT HAB secure boot) with a SOFTWARE FALLBACK (sigil + relay-sec) when the hardware is absent/unprovisioned/unhealthy + status: accepted + description: > + The 6X-RT security root-of-trust decision (user direction: "hardware with a + software fallback if the hardware does not provide"). GROUNDED in the PX4 + fmu-v6xrt source (read directly, research-first): + WHAT THE BOARD HAS (two distinct hardware trust anchors, both PRESENT but neither + ACTIVE in the stock dev build): + - NXP SE050 EdgeLock SECURE ELEMENT on I2C4 @ 0x48 (PX4_I2C_OBDEV_SE050; init.c + power/enable-sequences it via HW_VER_REV_DRIVE) - a tamper-resistant key vault + + ECC/RSA/AES + ECDSA/ECDH + attestation + TRNG. BUT PX4's default v6xrt crypto + backend is sw_crypto (src/drivers/sw_crypto) - the SE050 is wired, not the + default trust anchor. + - i.MX RT1176 HAB (High Assurance Boot) ROM secure boot: the IVT (struct ivt_s) + carries a `csf` (Command Sequence File / signature) field, but on v6xrt + CSF_ADDRESS=0 / csf=0 -> the default image is UNSIGNED (HAB "open" mode). HAB is + a silicon capability (CAAM engine + OCOTP SRK-hash fuses + boot ROM); enforcing + it = burn the SRK hash into OCOTP, sign with a CSF, "close" the device. + DECISION (two layers, each HW-first / SW-fallback): + (A) BOOT/LOAD-CHAIN INTEGRITY (is the flight image authentic before it runs): + HW = HAB - fused SRK + CSF-signed loader, ROM verifies before execution + (anchors the chain in silicon: ROM -> HAB-verified loader -> loads the + sigil-verified flight image to TCM, DD-016 load-to-RAM). FALLBACK (HAB open / + fuses not burned, e.g. dev + unprovisioned units) = the loader verifies the + sigil signature IN SOFTWARE (DD-016's current posture) + relay-sec anti-replay/ + anti-rollback. Selection = device HAB state (closed -> HW enforces; open -> SW + gate). + (B) KEY STORAGE + CRYPTO OPS (where the verify keys + relay-sec long-term keys + live, where ECDSA-verify/attestation runs): HW = SE050 - holds the + image-verification public key + relay-sec keys, does verify/attest in the + tamper-resistant element. In the maximal-wasm model (DD-018) the SE050 is just + ANOTHER relay-hal I2c transport + a verified SE050 driver; the crypto ops are + SE050 I2c commands. FALLBACK (SE050 absent / unenumerated / unhealthy) = the + software crypto backend (relay-sec software AEAD + a key in protected FRAM/ + flash). The HW/SW SELECTION REUSES THE EXISTING MECHANISM: DD-018's Presence/ + health descriptor + DD-014's health-driven posture - "SE050 present & healthy + -> use it; else degrade to software" is the same enumerate-and-vote pattern, + with the downgrade LOGGED as a health event (monitor-visible, like DD-014 + power redundancy), not silent. + HONEST CAVEAT (the safety/security trade): a SOFTWARE root is WEAKER - a software + signature check can be bypassed by an attacker who replaces the loader itself, and a + software key store lacks tamper resistance. So the software fallback is for (i) dev/ + bring-up, (ii) unprovisioned units, and (iii) graceful field degradation if the SE050 + fails - NOT the certified-flight target. The PRODUCTION / safety-certified + configuration MUST provision the hardware (burn HAB SRK fuses, provision the SE050), + and the fallback-active state is a reported, lower-assurance mode. This keeps dev + velocity (no fuse-burning to iterate) while making the hardware root the default for + shipped units. + FITS THE STACK: SE050 -> relay-hal I2c transport (DD-018); HW/SW select -> + Presence/health (DD-014/DD-018); HAB -> the boot/update-chain anchor for DD-016's + update TCB; sigil + relay-sec stay as the software-layer integrity (DD-009/DD-016) - + now positioned as the FALLBACK + the application-layer E2E, with HW as the root. + tags: [phase-2, security, root-of-trust, se050, hab, secure-boot, attestation, relay-sec, sigil, fallback] + fields: + rationale: >- + Hardware-first gives a tamper-resistant, silicon-anchored root (SE050 key vault + + HAB-fused secure boot) appropriate for an ASIL-D / DO-178 posture, while the + software fallback (sigil + relay-sec, already designed) keeps dev + unprovisioned + + degraded-field units functional without fuse-burning. Reusing the DD-014/DD-018 + Presence/health pattern for the HW/SW selection means no new mechanism - the + secure element is enumerated, health-checked, and voted exactly like a sensor, with + the downgrade logged, not silent. + alternatives: >- + Software-only (sigil + relay-sec, no HW) - rejected as the production target: no + silicon root-of-trust, software signature/key bypassable; kept only as the + fallback. Hardware-only (require SE050 + HAB always) - rejected: blocks dev + iteration (fuse-burn per change), bricks unprovisioned units, and gives no graceful + degradation if the SE050 fails in the field. DPS/TPM or a different secure element - + rejected: the SE050 is the part already on the 6X-RT (I2C4 @ 0x48) and PX4-supported; + no reason to add another. + release: v0.8.0 + links: + - type: satisfies + target: REQ-PIX-019 diff --git a/artifacts/phase2-pixhawk.yaml b/artifacts/phase2-pixhawk.yaml index a32f19d..982d84a 100644 --- a/artifacts/phase2-pixhawk.yaml +++ b/artifacts/phase2-pixhawk.yaml @@ -629,3 +629,40 @@ artifacts: links: - type: traces-to target: REQ-PIX-001 + + - id: REQ-PIX-019 + type: requirement + title: Hardware-first root-of-trust on the 6X-RT - bind the SE050 secure element + HAB secure boot, with an automatic software fallback (sigil/relay-sec) gated on hardware presence/health + status: draft + description: > + jess implements the DD-020 hardware-first / software-fallback root-of-trust on the + Pixhawk 6X-RT. Two layers: + (A) BOOT-CHAIN: support i.MX RT HAB secure boot (fused SRK + CSF-signed loader) as + the silicon root that verifies before execution; when HAB is open/unprovisioned, the + loader falls back to verifying the sigil image signature in software + relay-sec + anti-rollback (DD-016). The certified-flight build provisions HAB; dev/unprovisioned + units run the software gate (a reported lower-assurance mode). + (B) KEY VAULT + CRYPTO: bind the NXP SE050 (I2C4 @ 0x48) as a relay-hal I2c transport + + a verified SE050 driver (DD-018 maximal-wasm), holding the image-verification public + key + relay-sec long-term keys and performing ECDSA-verify/attestation in hardware; + fall back to the software crypto backend (relay-sec software AEAD + protected-FRAM key) + when the SE050 is absent/unenumerated/unhealthy. The HW/SW selection REUSES the + DD-018 Presence/health + DD-014 health-vote mechanism - enumerate the SE050, check + health, use it if present+healthy, else degrade to software with the downgrade LOGGED + as a health event (not silent). + VERIFICATION: SE050 driver Kani-totality (relay-side, like the sensor drivers) + + on-silicon enumeration/attestation on the connected 6X-RT (greenlit board access) + + a Renode/SIL test of the fallback selection (SE050-present vs SE050-absent paths) + + HAB provisioning validated on real silicon (fuse burn is irreversible -> gated on + explicit greenlight, tested on a dev unit first). GROUNDED in the PX4 fmu-v6xrt + research (SE050 @ I2C4 0x48, HAB IVT/CSF unsigned by default, sw_crypto default) - + DD-020. NOTE: this is a NEW security surface jess had not modeled; sequenced after the + core HAL binding (REQ-PIX-012) since the SE050 reuses the same embedded-hal-async I2c + seam. + fields: + category: functional + priority: should + release: v0.8.0 + links: + - type: traces-to + target: REQ-PIX-001