Návrh hardvérovej bezpečnosti je prax ukotvenia reťazca dôvery zariadenia v kremíku odolnom voči manipulácii — čím sa fyzicky znemožňuje extrakcia kryptografických kľúčov, falšovanie podpisov firmvéru alebo obchádzanie autentifikačných mechanizmov výlučne prostredníctvom softvérových útokov. Na rozdiel od softvérovej bezpečnosti (ktorá sa spolieha na korektnosť kódu) hardvérová bezpečnosť poskytuje hardvérový základ dôvery (Hardware Root of Trust), ktorý nie je možné kompromitovať zraniteľnosťami v aplikácii, operačnom systéme ani sieťovom zásobníku.
So zákonom o kybernetickej odolnosti EÚ (EU 2024/2847), ktorý nariaďuje bezpečný boot, autentifikované aktualizácie a správu zraniteľností pre všetky pripojené produkty do decembra 2027, hardvérová bezpečnosť už nie je voliteľná — je to regulačná požiadavka.
Stack hardvérovej bezpečnosti
Správne zabezpečené vstavané zariadenie implementuje bezpečnosť na každej vrstve:
| Vrstva | Komponent | Funkcia | Príklad |
|---|---|---|---|
| Hardware Root of Trust | Secure Element (SE) alebo TPM | Úložisko kľúčov odolné voči manipulácii, kryptografické operácie | Infineon OPTIGA Trust M (CC EAL6+), NXP SE050 |
| Bezpečný boot | Prvostupňový bootloader v OTP/chránenej flash | Overenie podpisu firmvéru pred spustením | ARM TrustZone + Secure Boot ROM |
| Bezpečná partícia OS | TrustZone Secure World alebo RISC-V PMP | Izolované vykonávanie bezpečnostne kritického kódu | OP-TEE, TF-M (Trusted Firmware-M) |
| Kryptografický engine | Hardvérový akcelerátor AES, SHA, ECC | Výkonná kryptografia bez zaťaženia CPU | STM32 CRYP/HASH, ESP32 AES-XTS |
| Bezpečné úložisko | Šifrovaná flash s kľúčom derivovaným z SE | Chránený firmvér a konfiguračné dáta | OTFDEC (on-the-fly dešifrovanie) |
| Bezpečná komunikácia | TLS 1.3 s hardvérovo podloženými povereniami | Autentifikovaný, šifrovaný prenos dát | ATECC608B + AWS IoT Core |
| Bezpečná aktualizácia | Dual-bank A/B OTA s ochranou proti rollbacku | Autentifikované aktualizácie firmvéru | MCUboot, SWUpdate |
Bezpečnostné elementy: Základ hardvérovej dôvery
Bezpečnostný element (SE) je dedikovaný integrovaný obvod odolný voči manipulácii, navrhnutý na uchovávanie kryptografických kľúčov a vykonávanie kryptografických operácií vo fyzicky chránenom prostredí:
| Bezpečnostný element | Certifikácia | Úložisko kľúčov | Kryptografické algoritmy | Rozhranie | Cenový rozsah |
|---|---|---|---|---|---|
| Infineon OPTIGA Trust M | CC EAL6+ | ECC P256/P384, RSA 2048 | ECDSA, ECDH, SHA-256, TRNG | I²C | 0,80–1,50 € |
| NXP SE050 | CC EAL6+ | ECC, RSA, AES, Ed25519 | ECDSA, ECDH, AES-128/256, SHA-256/384/512 | I²C | 1,00–2,00 € |
| Microchip ATECC608B | FIPS 140-2 (v konaní) | ECC P256 | ECDSA, ECDH, SHA-256, AES-128, TRNG | I²C | 0,50–0,80 € |
| STMicro STSAFE-A110 | CC EAL5+ | ECC P256/P384 | ECDSA, ECDH, SHA-256/384, TRNG | I²C | 0,60–1,00 € |
Prečo hardvér, nie softvér? Kryptografický kľúč uložený vo flash pamäti MCU je možné extrahovať prostredníctvom rozhrania JTAG/SWD, útokov postranným kanálom (analýza spotreby, elektromagnetická emisia) alebo priameho vyčítania flash pamäte. Bezpečnostný element uchováva kľúče v tienenom prostredí s detekciou manipulácie a aktívnymi protiopatreniami — kľúč doslova nemôže opustiť čip.
PSA Certified: Priemyselný bezpečnostný rámec
Rámec ARM PSA (Platform Security Architecture) Certified poskytuje štandardizovanú bezpečnostnú certifikáciu pre zariadenia založené na MCU:
| Úroveň | Čo certifikuje | Vyžaduje laboratórne hodnotenie | Typické MCU |
|---|---|---|---|
| PSA Certified Level 1 | Bezpečnostný dotazník, model hrozieb, základné bezpečnostné funkcie | Vlastné hodnotenie | STM32L5, Nordic nRF5340 |
| PSA Certified Level 2 | Odolnosť voči softvérovým útokom, bezpečný boot, bezpečná aktualizácia | Nezávislé laboratórium (8–12 týždňov) | STM32U5, NXP LPC55S69 |
| PSA Certified Level 3 | Odolnosť voči hardvérovým útokom (fault injection, SCA) | Pokročilé laboratórium (12–16 týždňov) | STM32H5 + SE, Renesas RZ/G |
PSA Certified Level 2 sa stáva minimálnym očakávaním pre komerčné IoT produkty. Úzko korešponduje s technickými požiadavkami CRA a poskytuje jasný argument zhody.
Reťazec bezpečného bootu
Správne implementovaný reťazec bezpečného bootu zabraňuje spusteniu akéhokoľvek neautorizovaného kódu na zariadení:
1. ROM bootloader (nemeniteľný, vypálený do kremíku)
├── Overuje podpis druhostupňového bootloadera
└── Ak neplatný → ZASTAVENIE (zariadenie nenabootuje)
2. Druhostupňový bootloader (MCUboot / U-Boot)
├── Overuje podpis aplikačného firmvéru
├── Spravuje A/B sloty firmvéru pre OTA aktualizácie
└── Ak neplatný → Rollback na poslednú známu funkčnú verziu
3. Aplikačný firmvér
├── Beží v Non-Secure World (TrustZone)
├── Pristupuje ku kryptografickým službám cez Secure World API
└── Nemá priamy prístup ku kľúčom bezpečnostného elementuKritická požiadavka: Prvostupňový bootloader musí byť nemeniteľný — uložený v OTP (One-Time Programmable) pamäti alebo ROM. Ak útočník dokáže modifikovať bootloader, celý bezpečnostný reťazec sa zrúti.
Post-kvantová kryptografia: Príprava na kvantovú hrozbu
Súčasná asymetrická kryptografia (RSA, ECC, Diffie-Hellman) bude prelomená dostatočne výkonnými kvantovými počítačmi. NIST v roku 2024 finalizoval prvé post-kvantové kryptografické štandardy:
| Algoritmus | Štandard NIST | Typ | Veľkosť kľúča | Výkon na Cortex-M4 |
|---|---|---|---|---|
| ML-KEM (CRYSTALS-Kyber) | FIPS 203 | Zapuzdrenie kľúča | 1 568 bajtov (KEM-768) | ~1 ms zapuzdrenie |
| ML-DSA (CRYSTALS-Dilithium) | FIPS 204 | Digitálny podpis | 2 420 bajtov (DSA-65) | ~3 ms podpis, ~1 ms overenie |
| SLH-DSA (SPHINCS+) | FIPS 205 | Digitálny podpis (bezstavový) | 7 856 bajtov | ~50 ms podpis |
Dopad na vstavané systémy: Post-kvantové veľkosti kľúčov a podpisov sú 10–100× väčšie ako ekvivalenty ECC. To ovplyvňuje flash úložisko (pre reťazce certifikátov), RAM (pre vyrovnávacie pamäte overenia podpisov) a šírku pásma (pre podpisy OTA aktualizácií). Hardvéroví architekti musia plánovať tieto požiadavky už teraz — ešte pred mandátom PQC.
Odporúčaný prístup: hybridné certifikáty, ktoré obsahujú podpisy ECC aj PQC, čím zabezpečujú kompatibilitu so súčasnou infraštruktúrou a zároveň poskytujú kvantovú odolnosť.
Bežné chyby v bezpečnostnej architektúre
| Chyba | Prečo je nebezpečná | Správny prístup |
|---|---|---|
| Zdieľané poverenia zariadení | Jedno kompromitované zariadenie odhalí všetky ostatné zariadenia | Unikátne poverenia pre každé zariadenie, provisionované počas výroby |
| Výmena kľúčov len symetricky | Žiadna dopredná utajenosť (forward secrecy), možné replay útoky | ECDHE alebo ML-KEM výmena kľúčov pre každú reláciu |
| Ponechané povolené ladiace porty | JTAG/SWD umožňuje úplné vyčítanie pamäte | Zakázanie ladenia vo výrobe cez option bytes + RDP Level 2 |
| Čisto softvérové úložisko kľúčov | Kľúče extrahovateľné cez dump flash alebo voltage glitching | Hardvérový SE s detekciou manipulácie a aktívnym tienením |
| Žiadna ochrana proti rollbacku firmvéru | Útočník môže vykonať downgrade na zraniteľnú verziu | Monotónny čítač v SE/OTP zabraňuje downgradu |
Prístup k bezpečnostnému inžinierstvu
Hardvérová bezpečnosť je architektonické rozhodnutie prijaté vo fáze požiadaviek — nie funkcia pridaná pred certifikáciou. Bezpečnosť sa navrhuje od kremíku nahor:
- Modelovanie hrozieb — Analýza STRIDE počas systémovej architektúry na identifikáciu útočných plôch
- Výber bezpečnostného IO — Správny SE/TPM pre danú aplikáciu (náklady, úroveň certifikácie, podpora algoritmov)
- Implementácia bezpečného bootu — Nemeniteľný bootloader + MCUboot pre spravované A/B aktualizácie
- Provisioning poverení — Injekcia kľúčov pre každé zariadenie počas výroby pomocou automatizovaného HSM workflow
- OTA infraštruktúra — Podpísané, šifrované doručovanie firmvéru s delta aktualizáciami a ochranou proti rollbacku
Všetky bezpečnostné implementácie dodržiavajú smernice PSA Certified a sú navrhnuté pre súlad s CRA od prvého dňa. Kontaktujte nás a prediskutujeme vašu bezpečnostnú architektúru.