Začnite modelom hrozieb
Určite chránené aktíva: prihlasovacie údaje zariadenia, podpisovú infraštruktúru, osobné údaje, riadiace príkazy a dostupnosť služby. Zistite, kto dosiahne na jednotlivé rozhrania a či môže útočník zariadenie fyzicky získať. Posúďte následky pre bezpečnosť ľudí. Vyberte opatrenia podľa rizík a zaznamenajte skúšky; certifikát komponentu necertifikuje celý výrobok.
Praktický postup návrhu a overovania
- Určite hranice dôvery medzi aplikáciou, privilegovaným firmvérom, perifériami a backendom.
- Oddeľte súkromné podpisové kľúče od overovacieho materiálu zariadenia; naplánujte zavedenie, rotáciu a odvolanie.
- Vyberte ochranu zavádzania, debug a úložiska pre presnú revíziu čipu.
- Overujte aktualizácie a testujte obnovu po prerušení zápisu.
- Obmedzte služby, overujte používateľov a zariadenia a v API kontrolujte oprávnenia.
- Testujte nesprávny obraz, odvolaný kľúč, starú verziu, chybné vstupy a stratu spojenia.
- Udržiavajte záznamy závislostí, triáž zraniteľností, dôkazy vydania a plán podpory.
Výsledky skúšok musia uvádzať cieľ, konfiguráciu a predpoklady útoku. Úspešný test secure boot nedokazuje odolnosť proti každému fyzickému útoku alebo zneužitiu počas behu.
Hardvérová dôvera a ochrana kľúčov
Hardvérový koreň dôvery ukotvuje vybrané bezpečnostné funkcie v hardvérovo podporených mechanizmoch, na ktorých integritu sa systém spolieha. Implementácia môže používať chránený zavádzací kód, kľúčový materiál, izolované vykonávanie alebo samostatný bezpečnostný komponent. Verejný overovací kľúč alebo jeho hash nie je tajný súkromný podpisový kľúč: výrobca zvyčajne chráni podpisový kľúč v podpisovej infraštruktúre. TrustZone, TPM a secure element majú odlišné úlohy; žiadny automaticky nepredstavuje celú architektúru či certifikáciu výrobku. Odolnosť proti manipulácii má model hrozieb a úroveň záruk, nie garanciu fyzickej nemožnosti extrakcie kľúčov. Osobitne posúďte debug, fault injection, postranné kanály a obnovu kľúčov.
Secure boot: ochrana a hranice
Secure boot overuje autenticitu zavádzaného softvéru pred jeho spustením. V bežnom embedded návrhu chránený úvodný overovací kód kontroluje podpísaný bootloader, ktorý overí aplikáciu. Konkrétne fázy a algoritmy závisia od procesora a implementácie. Secure boot chráni pred neoprávnenou výmenou obrazu; nedokazuje neprítomnosť zraniteľností schváleného softvéru a nezabráni všetkým útokom počas behu. Measured boot zaznamenáva merania na ďalšie vyhodnotenie; samotné meranie nemusí blokovať spustenie. Ochranu proti návratu na starú verziu a chránenú obnovu treba osobitne navrhnúť a testovať.
CRA a výber technológií
Požiadavky CRA sú orientované na výsledok a technologicky neutrálne, podľa posúdenia kybernetických rizík a použiteľnosti. Secure boot, hardvérový koreň dôvery, TPM, TrustZone a bezdrôtové OTA môžu byť vhodné technické opatrenia; nie sú univerzálnymi zákonnými povinnosťami každého výrobku. Zdokumentujte, prečo zvolené opatrenia spĺňajú požiadavky, namiesto stotožnenia jednej architektúry so zhodou.
Termíny a pôsobnosť CRA
CRA vstúpilo do platnosti 10. decembra 2024. Oznamovanie podľa článku 14 platí od 11. septembra 2026; hlavné požiadavky na výrobky od 11. decembra 2027. Článok 69 upravuje prechodné pravidlá pre skôr uvedené výrobky. Výrobky podliehajúce MDR alebo IVDR sú vylúčené podľa článku 2 ods. 2; preveriť treba aj ďalšie výnimky a nekomerčný slobodný/otvorený softvér.
Často kladené otázky
Vyžaduje CRA vždy secure boot?
Požiadavky CRA sú orientované na výsledok a technologicky neutrálne, podľa posúdenia kybernetických rizík a použiteľnosti. Secure boot, hardvérový koreň dôvery, TPM, TrustZone a bezdrôtové OTA môžu byť vhodné technické opatrenia; nie sú univerzálnymi zákonnými povinnosťami každého výrobku. Zdokumentujte, prečo zvolené opatrenia spĺňajú požiadavky, namiesto stotožnenia jednej architektúry so zhodou.
Zaručuje secure element zhodu?
Nie. Môže chrániť vybrané kľúče a operácie; zhoda sa týka celého výrobku a príslušných požiadaviek vrátane procesov a dôkazov.