Architektura důvěry: Implementace hardwarově akcelerované zabezpečené boot sekvence

Proč bezpečná boot sekvence rozhoduje o důvěře v autopilot

Autopilot je „mozkem“ UAV, který řídí let, bezpečnostní funkce a komunikaci s okolím. Pokud je kompromitován již při startu, všechny další vrstvy ochrany ztrácejí význam. Bezpečná boot sekvence (secure boot) a řetězec důvěry (chain of trust) zajišťují, že od prvního instrukčního cyklu procesoru až po nahrání aplikačního kódu běží pouze ověřený a nezměněný software, podepsaný legitimním vlastníkem zařízení nebo výrobcem.

Model hrozeb pro autopilot: čemu musí boot sekvence odolávat

Trvalé kompromitace: vložení škodlivého bootloaderu, implantáty v paměti Flash, manipulace s boot konfigurací.
Útoky přes OTA (over-the-air) aktualizace: podvržené firmware balíčky, downgrade na zranitelnou verzi.
Fyzické zásahy: přímý přístup k debug rozhraním (JTAG/SWD), glitching (napěťové/časové), fault injection, side-channel analýzy.
Supply-chain rizika: kompromitované komponenty, klonované bezpečnostní čipy, nespolehlivé klíčové materiály.
Mezi-doménové útoky: průnik z payloadu (např. kamery se systémem Linux) do řídící avioniky.

Principy bezpečného startu: kořen důvěry a kryptografické podpisy

Secure boot stojí na kořenu důvěry (Root of Trust, RoT), který obsahuje nebo chrání kryptografické klíče pro verifikaci další fáze. Každá fáze ověří integritu a původ následující, čímž vzniká řetězec důvěry až po aplikaci:

ROM Boot (neměnný): malý kód v maskované ROM MCU/SoC. Obsahuje veřejný klíč výrobce nebo hash „public key hash“ (PKH).
První stupeň bootloaderu (FSBL): podepsaný výrobcem HW nebo platformy; inicializuje paměti, hodiny, periferie, autentizuje druhý stupeň.
Druhý stupeň bootloaderu (SSBL): vlastník zařízení/operátor; řeší výběr partition, „A/B“ sloty a načítání OS/RTOS jádra.
Jádro/Hypervisor/RTOS: verifikované před spuštěním; aktivuje izolace (MPU/MMU), SELinux/AppArmor (pokud Linux), případně unikernelová prostředí.
Autopilotní aplikace a knihovny: poslední články řetězce; validované přes podpisy a politiky verzí.

Na úrovni kryptografie se používá digitální podepisování (ECDSA/EdDSA, případně RSA) s verifikací hashů (SHA-256/384). Klíčové je správné řízení klíčů a ochrana proti downgrade.

Měřený start (Measured Boot) a atestace integrity

Measured boot rozšiřuje secure boot o telemetrii důvěry: každá fáze nejen verifikuje další, ale také měří (hashuje) spouštěné binárky a ukládá otisky do bezpečného úložiště (TPM/TEE/SE). Následně je možné provést:

Lokální politiku: spuštění autopilota pouze pokud naměřené hodnoty odpovídají povoleným profilům („allowlist“).
Vzdálenou atestaci: GCS či flotilový manažer si vyžádá podepsanou zprávu – autopilot prokáže, co skutečně běží, ještě před povolením arm/disarm.

Komponenty kořene důvěry: TEE, TPM a Secure Element

Secure Element (SE): samostatný čip s ochrannými vrstvami; chrání privátní klíče, provádí podpisy a drží monotónní čítače.
TPM 2.0/firmware TPM: poskytuje PCR registry pro měření bootu, správu klíčů a atestaci. V embedded sféře často jako integrovaná periferie.
TEE/TrustZone: rozdělení na „secure world“ a „normal world“. Secure world provádí kryptografii a boot logiku; normal world nemá přístup k tajemstvím.

Politika klíčů: hierarchie, rotace a delegace

Bez klíčové politiky secure boot rychle zastará. Doporučená hierarchie:

Root Signing Key (RSK): nejvyšší autorita; uložená offline (HSM), používá se pouze k podepisování „intermediate“ klíčů.
Platform/Boot Signing Key (BSK): podepisuje FSBL/SSBL. Rotovatelný přes „key-roll“ mechanismus s přechodným obdobím, kdy zařízení důvěřuje starému i novému klíči.
Application Signing Keys (ASK): pro autopilot a moduly (navigace, komunikační stacky). Může existovat více domén (výrobce platformy vs. integrátor).
Anti-downgrade mechanismus: verzované manifesty a monotónní čítače v SE/TPM, které brání nahrání staršího, zranitelného FW.

Manifesty a metadata obrazu: co se podepisuje

Místo podepisování samotných binárek se běžně podepisuje manifest, který obsahuje:

Hash obrazu (FW/BL/OS), verzi (semver + build číslo), cílovou platformu a parametr „security level“.
Politiky spouštění (požadované periferie, RAM limity, bezpečnostní kontext, požadované PCR otisky nižších vrstev).
Informace pro „A/B“ aktualizační sloty a časové platnosti (valid-from/valid-until pro plánované end-of-life).

Architektury secure boot v praxi: RTOS vs. Linux

MCU + RTOS (Cortex-M, RISC-V): ROM Boot s PKH → FSBL (XIP z QSPI) → verifikace obrazu RTOS + autopilotního modulu. Důležitá je ochrana QSPI proti zápisu (HW write-protect) a deaktivace SWD/JTAG po výrobních testech.
SoC + Linux: ROM Boot → FSBL (DDR init) → U-Boot/TF-A (SSBL) s verifikací FIT/DM → signed kernel + initramfs + signed rootfs (dm-verity). Vhodná je kombinace „measured boot“ s TPM a vzdálená atestace před arm/disarm.

Oddělení domén: avionika vs. payload a komunikační subsystémy

Silné oddělení minimalizuje laterální pohyb útočníka:

Fyzikálně oddělené MCU/SoC: autopilot v izolovaném MCU, payload na Linuxu. Komunikace přes vybraná rozhraní (UART/CAN) s protokoly s autentizací rámců.
Virtuální separace: hypervisor/micro-VM, kde autopilot běží v chráněné doméně, payload v jiné; IOMMU blokuje DMA útoky.
Přísné ACL: pouze whitelisted zprávy s typy „nav, status, arm/disarm“. Žádný přímý file transfer do avioniky.

Obnova a „A/B“ slotování: bezpečné aktualizace bez přerušení

Aktualizace musí být atomické a reverzibilní:

A/B sloty: nahraje se nový obraz do neaktivního slotu, po restartu se spustí zkušební fáze. Pokud telemetrie nepotvrdí úspěch, bootloader se vrátí do slotu A.
Bezpečný recovery režim: dostupný pouze s lokální přítomností (fyzický klíč, proximity token) nebo s kryptografickým schválením „break-glass“ klíčem; recovery obraz je rovněž podepsaný.
Delta OTA: menší balíčky, ale podepisuje se vždy výsledný obraz; delta se aplikuje v sandboxu a verifikuje před aktivací.

Ochrana proti downgrade a replay

Verzování v manifestu + monotónní čítač v SE/TPM, který se inkrementuje při každém úspěšném updatu.
Časové razítka: pokud je dostupný spolehlivý čas (GNSS PPS + secure-time), kontrola „valid-from“.
Nonce při atestaci: zabraňuje opakovanému použití starých, platných reportů integrity.

Zpevnění boot fáze: anti-tamper a anti-glitch opatření

Deaktivace debug rozhraní: fuse/option bytes na trvalé zamknutí SWD/JTAG, oddělení testovacích pinů.
Detekce glitchů: dohled nad napětím a hodinami (brown-out, clock monitor), randomizace časování kryptografických operací.
Anti-rollback pojistky: jednosměrné fuses s verzí bootloaderu; fyzická pečeť krytu s tamper switchem a logováním událostí.

Výběr kryptografie a výkonové kompromisy

Pro embedded autopiloty je kritická velikost kódu a latence verifikace:

Podpisy: ECDSA P-256 nebo Ed25519 (rychlejší na verifikaci, menší klíče). RSA pouze pokud je požadována kompatibilita.
Hash: SHA-256 je standard; při dlouhém řetězci nebo větších obrazech lze uvažovat SHA-384.
PQC (post-kvantová kryptografie): v experimentálních režimech „hybridní podpisy“ (např. Ed25519 + PQC) s ohledem na velikost manifestu; do produkce až po stabilizaci standardů a HW podpory.

Bezpečná konfigurace periferií při startu

Boot fáze musí nastavit bezpečné defaulty:

Vypnutí nepotřebných rozhraní (USB gadget, telnet/ssh v payload doméně).
MPU/MMU pravidla před načtením aplikací: kód pouze ke čtení a spouštění, data bez spouštění (W^X), zásobníky s guard stránkami.
Secure boot pro souběžné MCU (např. komunikační moduly) – žádná „boční“ cesta do avioniky.

Politiky spouštění a autorizace letových režimů

I po úspěšném bootu má mít autopilot gate na kritické akce:

Arming podmínky: platná atestace, ověřený čas, schválený geofencing, bateriové limity a autentizovaná GCS.
Rozdělení privilegií: modul pro navigaci nemá právo měnit RF parametry; komunikační stack nemá přístup k senzorickým kalibracím.
Policy-as-code: jednoduchý, formálně verifikovatelný DSL pro rozhodování (např. „pokud PCR≠X → DISARM“).

Telemetrie důvěry a audit

Boot logy: podepisované a timestampované; obsahují verze, PCR otisky, výsledky verifikací a případné odchylky.
Bezpečnostní KPI: % startů s úspěšnou atestací, počet odmítnutých OTA balíčků, čas verifikace, výskyt tamper událostí.
Forenzní záznamy: při fail-boote uložit minimalizovaný dump diagnostiky do bezpečného kruhového bufferu.

Integrace se systémy řízení flotily a C2

Flotilový management musí být trust-aware:

Před autorizací mise vyžádat atestaci; bez ní mise není nasaditelná.
Distribuce klíčů a OTA přes „zero-trust“ kanály (mTLS, krátkodobé tokeny, device identity přes SE/TPM atestaci).
Politiky odstavení: pokud dojde k narušení integrity, zařízení se přepne do „safe-mode“ s omezeními (bez vrtulí, pouze diagnostika a geolokace).

Testování a verifikace bezpečného startu

Jednotkové a integrační testy: verifikace podpisů, selhání I/O, fallback cesty A/B, časové limity startu.
Chaos/Tamper testy: korupce manifestu, neplatný podpis, starší firmware, glitchování napájení během verifikace.
Penetrační testy: zaměření na debug porty, fault-injection, analýzu SWD/JTAG pojistek, side-channel měření při podepisování.
Formální ověřování: kritické části boot state machine a policy DSL mohou být verifikovány model-checkingem.

Supply-chain zabezpečení: od výroby po nasazení

Secure provisioning: ve výrobě generovat device identity (DI) v SE/TPM, nikdy neexportovat privátní klíče.
HSM pipeline: všechny podpisy FW a manifestů musí procházet přes HSM s auditním záznamem.
Serializace a traceability: vazba DI ↔ sériové číslo ↔ produktová šarže ↔ certifikáty; snadné stažení konkrétních šarží v případě incidentu.

Bezpečný boot v kontextu proti-dronových systémů

Proti-dronová opatření často cílí na soft-kill (rušení/klamání). Secure boot snižuje riziko „přeprogramování za letu“ nebo aktivace skrytých režimů. Při „hard-kill“ scénářích poskytuje telemetrie důvěry forenzní hodnotu a umožňuje prokázat, že platforma běžela v autorizované konfiguraci.