Společnost

Bezpečné protokoly C2: moderní kryptografie pro integritu a autentizaci

Jankoš 0

Proč bezpečné C2 (command & control) vyžaduje moderní kryptografii

Komunikační kanál C2 mezi pozemní řídicí stanicí (GCS) a bezpilotním prostředkem (UAV) je životně důležitý. Porucha integrity nebo dostupnosti C2 může vést ke ztrátě stroje či ohrožení bezpečnosti osob. Moderní C2 proto musí splňovat přísné požadavky na důvěrnost, integritu, autentizaci, dostupnost a auditovatelnost při velmi omezené latenci, proměnlivém kanálu a energetických limitech. Tento článek představuje návrhové principy, kryptografické primitiva, protokolové konstrukce a nástroje, které umožňují bezpečný C2 stack od fyzické vrstvy až po aplikaci – včetně připravenosti na post-kvantové hrozby.

Model hrozeb a specifická rizika C2 pro UAV

  • Odcouchávání a deanonymizace: protivník zachytává uplink/downlink, snaží se extrahovat příkazy, telemetrii či polohu.
  • Vkládání a modifikace: útoky typu man-in-the-middle a command injection s cílem převzít kontrolu nad UAV.
  • Replay a roll-back: opakované přehrání legitimních paketů k vyvolání nežádoucích stavů.
  • Jamming a spoofing: cílené rušení, falešné majáky, GNSS spoofing a zneužití rozhraní pro nouzové režimy.
  • Supply-chain a firmware útoky: vložení škodlivého kódu, únik klíčů, neautorizované moduly.
  • Post-kvantový protivník: dlouhodobé ukládání provozu („harvest-now, decrypt-later“).

Bezpečnostní a provozní požadavky na C2 protokol

  • Mutuální autentizace GCS ↔ UAV ještě před jakýmkoliv příkazem.
  • Důvěrnost a integrita s AEAD, ochrana směrem uplink-first (příkazy) s nejvyšší prioritou.
  • Forward secrecy a post-kvantová odolnost alespoň v hybridní formě.
  • Ochrana proti replay: monotónní čítače, nonce, časová okna a anti-rollback.
  • 1–1, 1–N i N–N režimy (swarms), škálovatelná správa skupinových klíčů.
  • Nízká latence, deterministický provoz, malý overhead, robustní rekey rutina při ztrátách paketů.
  • Bezpečné zotavení: degradace do failsafe režimu bez ztráty bezpečnosti, odvolání kompromitovaných uzlů.

Kryptografická primitiva vhodná pro UAV

  • AEAD šifrování: AES-GCM/GMAC na HW akcelerátorech; XChaCha20-Poly1305 pro MCU bez AES; Ascon-128a/Ascon-AEAD (nízkoenergetické, finalisté NIST LWC) pro ultra-lehké uzly.
  • Digitální podpisy: Ed25519/Ed448 pro rychlé autentizace a krátké podpisy; v PKI hierarchii s krátkou životností certifikátů.
  • Výměna klíčů: X25519/ECDH; hybridní KEM (např. X25519+Kyber) pro kvantovou připravenost; při skupinách MLS (Message Layer Security) s post-kvantovým rozšířením.
  • Kvalitní entropie: TRNG/DRBG podle NIST SP 800-90, zdraví RNG testováno on-line (kontinuální testy).

Protokolové rámce: TLS 1.3/DTLS 1.3, QUIC, Noise, COSE/OSCORE

  • TLS 1.3 / DTLS 1.3: 1-RTT handshake, 0-RTT pouze pokud je důkladně posouzen rizikový profil; klientské certifikáty nebo EAP-TLS pro síťový přístup.
  • QUIC: vestavěné šifrování, řízení přetížení a migrace cest (5G/LTE/Wi-Fi) – vhodné pro mobilitu a bonding.
  • Noise Protocol Framework: přímočaré handshake patterns (IK/XX) pro ultra-lehké linky mimo IP; jednoduché formální argumenty, malé binárky.
  • CBOR/COSE + OSCORE: drátově efektivní formát pro telemetrii a příkazy; integrita a důvěrnost na aplikační vrstvě (i přes nešifrované transporty).

Hybridní (PQ) handshake pro C2: doporučený návrh

Propojení výkonu, latence a post-kvantové odolnosti:

  1. Bootstrapping identity: GCS a UAV mají dlouhodobé klíče (Ed25519) a zařízení nese výrobní atestační kořeny (DICE/TPM/SE).
  2. 1-RTT handshake (Noise IK-psk2 / TLS1.3): ECDH (X25519) + PQ KEM (Kyber) → hybridní shared secret.
  3. AEAD session keys odvozené přes HKDF; samostatné klíče pro uplink a downlink, rozdělené podle priorit.
  4. Rekey po N paketech nebo T sekundách, s key update bez přerušení toku a s ochranou proti key/nonce opětovnému použití.

Správa klíčů a identit (PKI, atestace, životní cyklus)

  • Výrobní personalizace: bezpečný prvek (SE/TPM) s neexportovatelným privátním klíčem, zařízení získá device cert a atestační řetězec.
  • Onboarding: ověřená registrace do flotily (EAP-TLS/EST/ACES), mapování identity → letová oprávnění.
  • Rotace a odvolání: krátce žijící certifikáty (hodiny/dny), CRL/„OCSP-stapling“ nebo úplná offline validace s time-stamping.
  • Skupinové klíče: MLS nebo LKH (Logical Key Hierarchy) pro swarm; bezpečné vyradení kompromitovaného uzlu (forward/backward secrecy skupiny).

Strategie proti replay a manipulaci s rámci

  • Per-směry nonce/sekvenční čísla s detekcí mezer; okna pro doběhající pakety bez rizika opakování.
  • Časové razítka a monotónní počítadla vázaná na atestovaný čas (GNSS/PPS nebo PTP) – s odolností proti resetu.
  • AEAD tag pokrývá i směrování, typ zprávy a politiku (např. prioritu), aby nebyl možný cut-and-paste útok.

Jamming, spoofing a vícenásobné přístupové cesty

Bezpečnost C2 není pouze kryptografie. Navrhujte vícenásobné přístupové cesty:

  • Diverzita linek: 5G/LTE, TDD-RF linka, satelit – s bondingem na QUIC/MP-TCP a samostatným klíčem pro každou cestu.
  • Adaptivní FEC a ARQ pro kompenzaci výpadků bez navýšení latence (např. krátké systémové kódy na C2, delší na telemetrii).
  • FHSS/LBT a spektrální dohled pro detekci rušení; automatická změna kanálu se zachováním kryptografického stavu.

Efektivita drátového formátu a priorit

C2 zprávy musí být krátké a deterministické. Používejte CBOR s pevnými klíči, vyhýbejte se JSON. Zavádějte kompresi hlaviček (QPACK/HPACK nebo vlastní varint schémata). Dávejte pozor, aby šifrování nezvětšovalo rámce nad MTU. Uplink příkazy mají přísnou prioritizaci a deadlines, downlink telemetrie adaptuje rychlost podle zatížení kanálu.

Bezpečný boot, OTA aktualizace a supply-chain

  • Secure boot s ukotveným kořenem důvěry (ROM/OTP), ověření podpisu FW (Ed25519/Ed448) a měřené spuštění (TPM PCR/DICE CDI).
  • OTA update přes podepsané balíčky, rollback protection, A/B oddíly a atestace verze před vytvořením C2 session.
  • Oddělení klíčů: provozní klíče ≠ update klíče ≠ výrobní klíče; minimální oprávnění (least privilege).

Formální ověření a testování protokolů

  • Formální modely: ProVerif/Tamarin/Verifpal pro handshake; důkaz vlastností (PFS, aliveness, agreement).
  • Fuzzing: coverage-guided fuzzery (AFL/LibFuzzer/Hongfuzz) proti parserům a stavovým automatům.
  • Stranové kanály: knihovny v konstantním čase, ochrana proti DPA/EMA při SE/TPM, audit implementace MISRA-C nebo Rust no_std.

Implementační ekosystém a knihovny

  • Embedded C/C++: mbedTLS, wolfSSL, tinyDTLS, micro-ECC, PQClean/PQCrypto pro PQ primitiva; Ascon referenční implementace pro LWC.
  • Rust: ring, rustls, quinn, heapless a embassy pro async na MCU; crates s no-std profily.
  • Správa identit: est/CoAP-est, SUIT-Manifest pro OTA, KMS/CA integrace přes HSM na straně GCS.

Praktický příklad: lehký C2 protokol s Noise IK & AEAD

  1. Předpoklady: UAV má dlouhodobý klíč (Ed25519) v SE; GCS má operátorský certifikát.
  2. Handshake: Noise IK s prologue (kontext mise); ECDH(X25519) + Kyber KEM → HKDF → klíče (uplink/downlink).
  3. Data: rámce CBOR, COSE_Encrypt0 s AEAD (XChaCha20-Poly1305); sekvence/nonce 64-bit, okno 1024 rámců.
  4. Rekey: každých 2^20 bajtů nebo 60 s, in-band „KeyUpdate“ se starými klíči potvrzujícími přechod.
  5. Failover: při ztrátě linky migruje přes záložní cestu (QUIC), zachovává epochu a inkrementuje path id v AAD.

Skupinové C2 pro dronové roje (MLS/LKH)

Pro skupinové příkazy se využívá Message Layer Security (MLS) s přizpůsobením na nízkou latenci nebo hierarchické LKH stromy. Klíčové je eviction kompromitovaného člena s okamžitým rekey bez přerušení ostatních kanálů a s garantovanou backward/forward secrecy.

Metodika měření a provozní metriky

  • Handshake čas (p50/p95) a goodput po započítání AEAD a hlaviček.
  • Konstantnost latence (jitter), PDR (packet delivery ratio) při rušení a přetížení.
  • CPU/mem/energie na MCU/SoC, využití akcelerátorů AES/PMULL.
  • Detekce anomálií v C2: statistiky sekvencí, chybné tagy AEAD, míra rekey událostí.
  • Bezpečnostní KPI: pokrytí testů fuzzingem, formálně ověřené vlastnosti, intervaly rotace klíčů, MTTD/MTTR na incidenty.

Provozní politiky a lidské faktory

  • Správa pověření operátorů, duální kontrola pro kritické příkazy.
  • Least privilege v GCS aplikaci, oddělení rolí (pilot, payload operátor, admin PKI).
  • Incident response: rychlé odvolání certifikátů, bezpečný kill-switch přes separátní atestovaný kanál.

Nejčastější chyby v návrhu C2 bezpečnosti

  • Opakované použití nonce u AEAD; zamíchání počítadel mezi směry.
  • Nedostatečná kvalita RNG a ignorování zdravotních testů DRBG.
  • Neformálně specifikované AAD → umožněné cut-and-paste útoky na pole hlaviček.
  • 0-RTT bez důsledného posouzení rizik přerovnání a replay.
  • Chybějící secure boot a atestace → protokol je zbytečný, pokud útočník ovládá firmware.

Doporučená cesta adopce

Bezpečné C2 pro UAV vyžaduje souhru robustní kryptografie, efektivní implementace a síťové odolnosti. Praktická cesta: (1) zavést TLS1.3/DTLS1.3 nebo Noise s AEAD, (2) přidat hybridní PQ handshake, (3) formalizovat PKI a životní cyklus klíčů, (4) zajistit secure boot a OTA, (5) testovat formálně a fuzzingem, (6) zavést multi-link s bondingem a ochranou proti jamování. Takto navržený protokolový stack poskytne nízkou latenci, kvantovou připravenost a provozní spolehlivost i v náročných podmínkách provozu dronů.

Jankoš

Website:

Related Story