Výrobci čipů integrují řadu bezpečnostních řešení na hardwarové i softwarové úrovni. Hned na počátku je nutné si uvědomit, že integrovaná bezpečnost na čipu neřeší celý problém zabezpečení aplikace, protože do hry vstupuje zabezpečení dat, komunikace, správa zařízení i update software. Požadavky, které popisují minulé články série Secure by Design, musí splnit vývojář s ohledem na celé aplikační prostředí, jeho potenciál, byznys model a možné hrozby.
Ideální modul nebo System on chip poskytuje bezpečnostní prvky pro ochranu:
- Firmware a software zařízení před vyřazením z provozu nebo nahrazením jiným kódem
- Periferií před útokem postranními kanály
- Systémových a uživatelských dat
Architektura takového řešení není levná a obvykle využívá hned několik čipů, které se starají v podstatě jen o zabezpečení. Prvním samostatným čipem je obvykle koprocesor, který má na starosti pouze šifrování a dešifrování dat a obsluhu klíčů. Vzhledem k tomu, že tento proces je výpočetně náročný, u bezpečnějších modulů lze najít takových čipů více. Autonomie zaručuje, že změny firmware zařízení se nijak nedotknou čipu. Samostatný blok se prosazuje také u řízení update firmware. Prioritou je zachování funkce a možnost oživení zařízení i v případě neúspěšného update. Často jsou pro firmware vyhrazeny dva bloky paměti, které se přepínají po ověření integrity přijatého upgradu. Zabezpečení se týká i manipulace s pamětí.
Trendem je oddělení bloků firmware, aplikačního sw, provozních dat a uživatelských dat podle typu a úrovně zabezpečení. Zvláště pro přijímaná data je dedikováno prostředí sandboxu, kde je provedena nejprve jejich validace a následně jsou teprve zpracována aplikací.
Jak tomu jdou vstříc výrobci čipů?
Popsané prvky využívá například ARM Platform Security Architecture (PSA). Součástí technologie je rozšíření ARM TrustZone, které umožňuje fyzicky izolovat kód aplikace, paměťovou oblast jako je RAM a periferie v hardware. Služba TrustZone umožňuje software rozdělit do zabezpečených a nezabezpečených oblastí, které pak budou spouštěny buď v bezpečném nebo nezabezpečeném režimu procesoru. Podrobně se tomu věnuje samostatný článek.
Další výrobci
NXP A71CH je hotové řešení bezpečného připojení IoT zařízení přímo do cloudu nebo peer-to-peer. Je určen pro inteligentní domácí/městské, průmyslové aplikace včetně senzorových sítí a IP kamer. Zabezpečení Root of Trust (RoT) je řešeno na úrovni čipu. Zahrnuje šifrované ukládání klíčů, generování a odvození klíčů, které slouží k ochraně soukromých informací a vzájemné autentizaci.
Microchip u svých procesorů a MCU uvádí přehledně informace o dostupných bezpečnostních technologiích v jednotlivých řadách. Vedle toho nabízí řadu čipů CryptoAuthentication ATECCxxx. U ST Microelectronics je bezpečnost a zabezpečení jedním z výchozích kritérií pro výběr čipů řady STM 32, takže lze využít rozcestník, který nabízí filtrování produktů přes bezpečnost. U Infineonu najdeme Trusted Platform moduly Optiga, určené pro zabezpečení průmyslových a embedded systémů. Ty jsou mimochodem součástí modulů TPM pro Raspberry Pi.
Různé úrovně bezpečnostních služeb u Microchipu.
ARM Platform Security Architecture (PSA)
Bezpečnostní nástroje, integrované v čipech se u jednotlivých výrobců liší. Na první pohled se zdá, že výrobci berou otázku bezpečnosti vážně a v nabídce mají procesory, mikrokontroléry i SoC, které nabízí výchozí technická řešení pro:
- Šifrování dat a procesování autentizačních klíčů
- Šifrování firmware a software
- Bezpečný update a kontrolní mechanismy pamětí
- Oddělení firmware, aplikací a dat
To jsou východiska, bez kterých se vývoj bezpečného zařízení neobejde. Nabídka jednotlivých výrobců se liší zejména v nabídce symetrických a nesymetrických kryptovacích algoritmů, ale také v zabezpečení pamětí. U Microchipu najdeme zabezpečení pro EEPROM paměti, Renesas u MCU řady RX65N/RX651 podporuje zejména SRAM a SDRAM.
Rozdíly jsou také v zabezpečení pro update. Drahé, ale spolehlivé je řešení duální flash paměti, která podporuje BGO (Back Ground Operation) pro update firmware i možnost swapování, tedy přepínání. To umožňuje nepřerušovaný běh bezpečnostních algoritmů v době update, resetu i startu zařízení. V případě chyby update vždy existuje starší verze flash, ze které se zařízení bootuje. K jejímu přepsání dochází až při dalším update, kdy je funkčnost provozní verze dostatečně ověřena.
Bezpečnost není univerzální
Zde ovšem rady v podstatě končí, protože výrobci čipů nemohou vyřešit celou problematiku právního rámce, ani požadavky aplikací. I když pro vývoj použijeme stejnou čipovou sadu, požadavky na bezpečnost IoT senzorů, zařízení, pracující s citlivými osobními daty nebo průmyslové systémy se budou lišit. Většina těchto bezpečnostních řešení byla navíc představena mezi lety 2014 a 2016, kdy právní regulace ochrany proti kybernetickým hrozbám v USA ani v Evropě neměla tak pevné obrysy jako dnes.
U některých SoC je podpora kybernetické bezpečnosti přímo odvozena od typu sítě, pro který je SoC určen. To je běžné u LPWAN, protože Sigfox, LoRA i celá rodina lehkých protokolů Thread, ZigBee, Bluetooth Low Energy...) využívá pouze určitou kombinaci šifrovacích algoritmů a zabezpečení.
I když se to před rokem či dvěma zdálo být zcela dostačující, dnešní vývoj ukazuje opak. Trendem jsou zařízení a nody, které pro komunikaci využívají zároveň několik standardů a protokolů s různými šifrovacími a bezpečnostními algoritmy. V takovém případě se vývoj vrací na začátek a výběr čipů musí reflektovat navrhované aplikační prostředí a regulace globálního trhu.
Komplexní pohled na otázky bezpečnosti tak najdeme u systémových integrátorů, kteří řeší IoT platformu jako celek od zařízení, přes cloudové služby až po aplikace. Příkladem může být Bosch IoT Suite nebo platforma Digi IoT s Digi Remote Manager a také HPE Universal IoT Platform.
Řadu podrobných informací najdete v sekci https://vyvoj.hw.cz/bezpecnost-iot
- https://www.element14.com/community/docs/DOC-91377/l/element14-essentials-iot-iii-iot-security
- https://www.infineon.com/cms/en/product/promopages/iot-demos/
- https://www.microchip.com/design-centers/32-bit
https://www.arm.com/why-arm/architecture/platform-security-architecture