Bezpečnost embedded standardy

Proč jsou bezpečnostní standardy v embedded vývoji klíčové

Embedded zařízení dnes řídí automobily, zdravotnické přístroje, průmyslové linky, chytré elektroměry i domácí IoT. Selhání nebo kompromitace takových systémů může ohrozit lidské zdraví, kontinuitu provozu i důvěrnost dat. Bezpečnostní standardy poskytují společný jazyk, ověřené postupy a měřitelné požadavky, které umožňují navrhovat, testovat a provozovat vestavěná zařízení systematicky a auditovatelně. Tento článek shrnuje klíčové rámce, metody a konkrétní techniky, které by měl znát každý vývojář firmware a systémový architekt.

Terminologie: bezpečnost (safety) vs. zabezpečení (security)

• Safety – ochrana před neúmyslným poškozením způsobeným chybou systému (např. zkrat, porucha senzoru, softwarová chyba vedoucí k nebezpečnému stavu).
• Security – ochrana před úmyslným útokem (např. podvržení firmware, manipulace s komunikací, exfiltrace dat).

Oblasti se prolínají: bezpečnostní opatření (security) chrání i bezpečnost provozu (safety). Moderní standardy proto vyžadují jejich společné řízení a „co-engineering“.

Přehled klíčových standardů podle domén

• Průmysl a automatizace: IEC 62443 (bezpečnost průmyslových řídicích systémů), ISO/IEC 27001 (ISMS) a 27002 (kontroly).
• Automotive: ISO 26262 (funkční bezpečnost), ISO/SAE 21434 (kybernetická bezpečnost vozidel), AUTOSAR (Classic/Adaptive) a pokyny MISRA C/C++.
• Letecká technika: DO-178C (software) a DO-254 (hardware), s důrazem na důkazní artefakty a pokrytí testy (MC/DC).
• Zdravotnictví: IEC 62304 (životní cyklus SW ve zdravotnických prostředcích), ISO 14971 (řízení rizik), IEC 60601-1 (elektrická bezpečnost).
• IoT a spotřební elektronika: ETSI EN 303 645 (baseline pro IoT), NISTIR 8259x (profil bezpečného IoT), doporučení OWASP IoT Top 10.
• Obecná funkční bezpečnost: IEC 61508 (matka norem safety), na kterou navazují doménové standardy.
• Kryptografie a moduly: FIPS 140-3 (validace kryptomodulů), ISO/IEC 19790, SP 800-56/57 (řízení klíčů).
• Supply chain a software: SLSA (úrovně integrity dodavatelského řetězce), SBOM (SPDX/CycloneDX), ISO/IEC 5230 (OpenChain).

Integrované řízení rizik: od hrozeb k požadavkům

1. Klasifikace aktiv a rozhraní: MCU/SoC, senzory, bootloader, komunikace (UART, CAN, Ethernet), update kanál, cloud.
2. Modelování hrozeb: STRIDE (spoofing, tampering, repudiation, information disclosure, DoS, elevation of privilege) pro technické hrozby; LINDDUN pro rizika soukromí.
3. Analýzy bezpečnosti a bezpečnosti provozu: TARA (Threat Analysis and Risk Assessment), FMEA/FMEDA, HAZOP, Attack Trees.
4. Derivace požadavků: bezpečnostní cíle → systémové požadavky → hardwarové/softwarové → testy a ověřování.

Secure Development Lifecycle (SDL) pro embedded

Standardy jako IEC 62443-4-1 nebo ISO/SAE 21434 vyžadují formální životní cyklus. Prakticky:

• Plánování: bezpečnostní plán, rozdělení odpovědností, klasifikace SW komponent (kritičnost).
• Architektura: oddělení důvěryhodných oblastí (TrustZone/MPU), minimální privilegia, jasná hranice TCB (Trusted Computing Base).
• Implementace: kodex bezpečného programování (MISRA, AUTOSAR C++14, CERT C/C++), povinné code-review, statická/dynamická analýza.
• Verifikace: jednotkové testy, integrační testy na HIL, fuzzing protokolů, penetrační testy, měření pokrytí.
• Uvedení do provozu: bezpečná výroba, párování klíčů, testy na lince, kontrola lotu a evidence sérií.
• Provoz a údržba: bezpečné OTA aktualizace, monitoring telemetrie, proces reakce na zranitelnosti (PSIRT), EOL politika.
• Artefakty a sledovatelnost: požadavky ↔ rizika ↔ implementace ↔ testy ↔ vydání (audit trail).

Architektonické principy: obrana do hloubky a zmenšování TCB

• Segregace: oddělení řídicí (safety) a komunikační (connectivity) části, fyzicky nebo alespoň logicky (MMU/MPU, TrustZone, hypervizor).
• Nejmenší privilegia: driver nemá vyšší práva než nutná; RTOS úlohy s nejnižším potřebným oprávněním (permissions, capability-based přístupy).
• Minimalismus: odstraňte nepoužité knihovny, rozhraní, debug porty; vypněte JTAG/SWD v produkci (nebo použijte secure debug s autentizací).
• Bezpečná konfigurace by design: default-deny firewall, povinné šifrování, explicitní whitelist protokolů a portů.

Řetězec důvěry: secure boot, měření a podepisování

1. Root of Trust (RoT): klíče uložené v OTP/eFuse/PUF, HSM/SE, nebo v chráněné oblasti SoC.
2. Secure Boot: bootloader ověřuje podpis firmware (RSA/ECC/Ed25519) a integritu (SHA-2/3); nepodepsané obrazy se nespustí.
3. Měřené spouštění: uložení hashů firmware pro atestaci (TPM/Device Identity Composition Engine/DTLS certifikáty).
4. Antireplay a verzování: monotónní čítač, rollback protection, A/B sloty pro bezpečné OTA.

Bezpečné OTA aktualizace a správa verzí

• End-to-end podpis: výrobní pipeline podepisuje build; zařízení verifikuje před instalací.
• Bezpečný transport: TLS 1.3/DTLS 1.3 s ověřením serveru a volitelně klientskými certifikáty.
• Transakční aktualizace: duální banky (A/B), atomický přechod a automatický rollback při selhání.
• Politiky: staged rollout, postupné vlny, možnost okamžitého kill-switch při kritické zranitelnosti.

Standardy pro kód: MISRA, AUTOSAR C++14, CERT a bezpečné C

Vestavěné systémy s jazykem C/C++ profitují z kodifikačních pravidel, která snižují pravděpodobnost chyb a zneužitelných vzorů.

• MISRA C/C++: omezují nejednoznačné a nebezpečné konstrukce; vyžadují přesnou typovost a determinismus.
• AUTOSAR C++14: zaměřený na moderní C++ v automotive s ohledem na bezpečnost a testovatelnost.
• CERT C/C++: prevence zranitelností (přetečení, UAF, závody, nesprávná správa paměti), pravidla pro rozhraní a chybové stavy.

Součástí je povinná statická analýza (např. pravidla MISRA checker), taint analýza vstupů a „gate“ v CI, který blokuje buildy porušující kritická pravidla.

Hardwarové bezpečnostní prvky a izolace

• MPU/MMU a domény: mapujte paměť podle principu need-to-access. Omezte spouštění kódu z RAM, RX vs. RW oblasti.
• TrustZone-M / TrustZone-A: oddělení Secure/Non-Secure světa s řízením přechodů skrze SG brány.
• TPM/SE/HSM: bezpečná identita zařízení, uchování klíčů, kryptografické operace mimo běžné jádro.
• Fyzická ochrana: tamper detekce, anti-glitch, ochrana proti DPA/SPA (boční kanály), stínění a epoxidové zalití dle rizik.

Komunikační protokoly a kryptografie v praxi

• TLS/DTLS 1.3: moderní křivky (X25519, P-256), AEAD (AES-GCM, ChaCha20-Poly1305), striktní ověřování certifikátů, pinning kde dává smysl.
• IoT protokoly: MQTT over TLS, CoAP over DTLS, OPC UA s integrovaným modelem bezpečnosti, zabezpečený CAN (CAN-FD s autentizací na aplikační vrstvě).
• Správa klíčů: rotace, expirace, politika síly klíčů, secure storage, ochrana před key-extraction.
• Random: TRNG/DRBG validovaný vůči NIST SP 800-90A/B/C, zdravotní testy entropie.

Supply chain, SBOM a integrita buildů

• SBOM: generujte pro každý release v SPDX nebo CycloneDX; udržujte mapu CVE → komponenty → ovlivněná zařízení.
• SLSA: podepisujte build provedeni (provenance), izolujte CI běhy, používejte reprodukovatelné buildy, hermetické závislosti.
• OpenChain: procesy pro používání open-source (licence, zranitelnosti, aktualizační strategie).

Testování a ověřování bezpečnosti

• Statická analýza: MISRA/AUTOSAR/CERT pravidla, detekce integer wrap, null-deref, data race.
• Fuzzing: protokoly (BLE, CAN gateway, TCP/IP stack), mutační a generativní přístup; sanitizery v emulaci.
• Penetrační testy: black/grey/white-box, zkoušky odolnosti proti glitchingu, fault injection a side-channel analýza dle kritičnosti.
• Validace timingů: WCET, latence ISR, determinismus v RTOS, testy brown-out a power-cycle scénářů.
• Pokrytí: statement/branch a v safety doménách MC/DC; traceabilita testů na požadavky.

Bezpečnost RTOS a plánování úloh

• Izolace vláken: využití MPU regionů na úrovni tasků; kontrola přístupu k periferiím přes systémové volání.
• Ochrany běhového prostředí: stack canaries, W^X, watchdog, ASLR tam, kde je podpora (na MCU často omezená).
• Bezpečné IPC: fronty se značkami integrity, ověřování identity komunikujících úloh.

Provozní bezpečnost: logování, telemetrie a reakce na incidenty

• Bezpečné logy: neobsahují tajné klíče, minimalizují PII; kryptograficky chráněná integrita.
• Detekce anomálií: limity chyb, selhání handshake, neobvyklá latence; lokální „bezpečný režim“ při podezření.
• PSIRT proces: příjem hlášení, CVSS hodnocení, náprava, servisní bulletiny, koordinované zveřejnění.

Ochrana soukromí a regulace

Zařízení pracující s osobními daty musí plnit principy privacy-by-design: minimalizace sběru, pseudonymizace/anonimizace, data retention a práva subjektů dat (GDPR). Prokazujte shodu pomocí DPIA, mapujte datové toky a uplatňujte ISO/IEC 27701 pro PIMS.

Bezpečná výroba a personalizace zařízení

• Provisioning klíčů: bezpečná linka, HSM, oddělení rolí; jedinečné identity zařízení (X.509, ECDSA klíče).
• Test a kalibrace: bez úniku tajemství, debug rozhraní chráněno a po výrobě uzamčeno.
• Evidence a dohledatelnost: párování SBOM/verze firmwaru se sériovým číslem, auditovatelné záznamy.

Metriky zralosti a auditní připravenost

• Maturity model: definujte úrovně (ad hoc → řízené → měřené → optimalizované) dle procesů SDL, testování a reakce na zranitelnosti.
• KPI: MTTR na zranitelnost, podíl pokrytí pravidel MISRA/CERT, procento komponent s aktuálními závislostmi, počet zjištěných chyb na KLOC.
• Interní audity: pravidelné kontroly shody artefaktů (plány, rizika, testy, SBOM, podpisy buildů) a readiness pro certifikace.

Checklist pro projekt vestavěného systému

1. Vybrány relevantní standardy (IEC 62443, ISO/SAE 21434, atd.) a definován rozsah shody.
2. Zhotovena analýza hrozeb (STRIDE/TARA) a mapování na požadavky.
3. Návrh architektury s izolací, minimálními privilegii a definovaným TCB.
4. Zaveden SDL: pravidla kódu (MISRA/AUTOSAR/CERT), povinné review a statická analýza.
5. Implementován secure boot, správa klíčů a bezpečné OTA (A/B, rollback protection).
6. Generován SBOM, zaveden SLSA a podepisování buildů.
7. Testy: fuzzing, pen-testy, WCET, pokrytí, HIL; evidence výsledků.
8. Provozní bezpečnost: logování, telemetrie, PSIRT, politika EOL.
9. Soulad s ochranou soukromí (GDPR, ISO/IEC 27701) a s doménovými regulacemi.
10. Příprava na audit: úplná sledovatelnost požadavků a důkazních artefaktů.

Závěr

Bezpečnostní standardy v embedded vývoji nejsou překážkou kreativity, ale multiplikátorem kvality. Přinášejí jednotný rámec pro řízení rizik, zvyšují odolnost vůči útokům i chybám a zjednodušují audit a certifikaci. Klíčová je důslednost: začít analýzou hrozeb, promítnout požadavky do architektury a kódu, ověřit je testy a udržovat bezpečnost po celou dobu životního cyklu zařízení.