Trust Platform znamená bezpečně. Od návrhu až po nasazení

Zabezpečení se stává v oblasti vestavných systémů klíčovým požadavkem. Chcete svá zařízení připojit k internetu a těžit přitom z jejich snadnějšího ovládání a také okamžitého přenosu dat ze senzorů? V tom případě podstupujete vysoké riziko, že se do systému někdo nabourá. V nebezpečí nejsou pouze jednotlivá zařízení, ale i celé sítě.

Pokud jde o dodavatele, postup je zcela zřejmý. Nemohou totiž přijít na trh se zařízením internetu věcí (IoT), které by nebylo bezpečně navržené již ze své podstaty. Výrobci zařízení však ve snaze o využití celého potenciálu IoT u svých systémů naráží na složité zapracování nezbytných, efektivních bezpečnostních mechanismů. O základní potřebě ověřování a také šifrování mluví všichni, zavedení do praxe ale bývá mnohem náročnější.

Předně zde máme několik součástí, softwarových i hardwarových, které jsou k vytvoření bezpečné podstaty daného vestavného systému nezbytné. Zranitelné místo u kterékoli z nich pak může snadno vést k napadení hardwaru zákeřným softwarem použitým při síťovém útoku, resp. k zachycení citlivých informací kyberzločinci. Spousta vývojových týmů bude navíc problémům souvisejícím se zabezpečením svého systému čelit poprvé.

Jeden z klíčových požadavků na efektivní zabezpečení spočívá v tom, že každé nasazené zařízení bude mít svou vlastní jedinečnou identitu. Častým nedostatkem, kterého útočníci využívají, je obyčejné heslo nebo přihlašovací údaje pro servisní účely. Uhádnout zmíněné detaily nebývá vůbec složité, a pokud by to mělo přesto znamenat nějaké komplikace, hackeři si umí poradit. Díky přihlašovacím údajům pak lze získat přístup nejen k jednomu zařízení, ale i celým skupinám produktů. Kyberzločinci vytvořili na základě jednoduchých automatizovaných skriptů tzv. botnety – armády identických počítačů používaných při útocích typu DoS (Denial-of-Service). Skripty dokážou rozpoznat cíle a poté se přihlásit do každého zařízení určitého typu, které je připojeno k internetu.

Díky neopakovatelné identitě lze pro každý systém zajistit jeho vlastní bezpečnostní „kredit“ a výrazně tím snížit pravděpodobnost, že se útočníkům ve spojitosti s botnety otevře snadná cesta. Přístup je tedy povolen pouze autorizovanému uživateli s náležitým oprávněním k manipulaci s konkrétním zařízením. Taková rostoucí míra ochrany se nicméně odráží ve způsobu návrhu, vývoji a také samotném provozu.

Návrh efektivního zabezpečení, které celý vývoj zjednoduší, spíše než aby jej dále komplikovalo, znamená pečlivě vybírat. První kroky zde budou souviset se samotnými hardwarovými základy pro zajištění integrity koncového zařízení. Nejde přitom pouze o to, abychom znemožnili neautorizovaný přístup ke stěžejnímu firmwaru, ale také zaručili, že funkce nebudou zneužity a zařízení neposlouží k dalšímu síťovému útoku. Pokud například hacker získá přístup k jednomu zařízení, potřebujeme zajistit, aby u ostatních nebylo možné spustit podobnou lavinu událostí a vytvořit zde třeba botnet. Identita je tedy úzce provázána s integritou.

Infrastruktura PKI (Public-Key Infrastructure) nabízí prostředky pro zřízení a také osvědčování jedinečné a nezpochybnitelné totožnosti a to nejen v rámci samotného zařízení, ale také na úrovni sítě. Vše se přitom odvíjí od principů asymetrické kryptografie, tedy postupů, při kterých matematicky spojíme dva numerické klíče. Jedním z nich je veřejný klíč, používaný obvykle k ověření zpráv. Jak již naznačuje samotné pojmenování, lze jej obecně šířit, aniž bychom tím ohrozili bezpečnost. Kdokoli proto může zařízení snadno poslat zabezpečené zprávy, pokud ovšem ví, který z veřejných klíčů použít. Samotné zařízení pak bude potřebovat privátní klíč umožňující podpis zasílaných zpráv ověřených příslušným veřejným klíčem.

Na základě zmíněných operací lze dále vystavět více strukturované modely pro ověřování pravosti, např. digitální certifikáty odhalující totožnost zařízení. Abychom vytvořili digitální certifikát, zařízení podepisuje zprávu či výzvu, přičemž signatura bude vytvořena s využitím privátního klíče. Odpovídající veřejný klíč je adresátem použit ke stanovení právoplatnosti podpisu.

Je zřejmé, že privátní klíč vyžaduje silnou ochranu. Nestačí jen tedy naprogramovat klíč do non-volatilní paměti v zařízení před jeho nasazením, protože tak bude snadno k dispozici. Privátní klíč by nikdy neměl být prozrazen. Pokud totiž dojde k jeho odhalení, dokážou již útočníci vytvořit vlastní klonovaná zařízení. Umí tak původní zařízení napodobit a ohrozit přitom bezpečnost propojených aplikací, které jsou na datech odesílaných ze zařízení závislé.

Problém pro klasické návrhy založené na mikrokontroléru však spočívá v tom, že jakýkoli kryptografický software v jádru procesoru vyžaduje přístup k privátnímu klíči, aby tak mohl provést nezbytné výpočty a „předpokládá“ proto přítomnost klíče v rámci kontroléru. Klíčovým požadavkem se tudíž stává zabezpečený prvek sloužící k uzavření zmiňovaných kryptografických operací do samostatné části chráněného hardwaru společně s bezpečným úložištěm pro privátní klíče. Vzhledem k tomu, že teď máme klíč i kryptografické funkce společně obklopené stejnou, bezpečnou fyzickou hranicí, není již nutné odesílat citlivá data po interní systémové sběrnici.

Obr. 1 Bezpečnostní prvek je jako trezor chránící tajemství. Na hardwarové úrovni vystupuje v pozici doprovodné součástky mikrokontroléru
 

Pokud systém potřebuje komunikovat zabezpečeně, příp. prokázat svou identitu, osloví místo toho bezpečnostní prvek s požadavkem, aby reagoval na náhodnou výzvu. Odezva na takovou výzvu je kódem vyvozeným aritmeticky z nahodilé součásti výzvy a příslušného privátního klíče uloženého uvnitř bezpečnostního prvku. Náhodná výzva tak bude jinými slovy podepsána s využitím privátního klíče. Bezpečnostní prvek proto může výše zmíněným způsobem dát najevo, že má v držení příslušné tajemství, nicméně nemá zapotřebí odhalit samotný, tajný privátní klíč.

Bezpečnostní prvek dokáže zařízení také ochránit před podvrženým kódem, který se může útočník pokusit spustit s cílem ovládnout systém. Ochranný mechanismus, který je z preventivních důvodů nezbytný, spočívá v ověření kódu. Taktéž zde hovoříme o bezpečném zavádění či verifikaci za běhu. Výzva odeslaná bezpečnostnímu prvku bude v tomto případě signaturou získanou ve spojitosti s podepsaným obrazem uloženým v zařízení (boot). Jakékoli aktualizace kódu musí být podepsány OEM na základě jeho privátního klíče. Prostřednictvím bezpečného zavádění a verifikace za běhu může systém podporovat aktualizace typu „over-the-air“ zajišťované ze strany výrobce a to bez rizika spuštění aktualizací poskytnutých třetí stranou, třeba při útocích vedených prostředníkem (man-in-the-middle) apod.

Zmíněný klíč použitý v případě kódu k potvrzení pravosti podpisu je citlivou záležitostí, která by měla mít své místo v chráněné a nezměnitelné paměťové oblasti. Jestliže dojde ke změně klíče, systém by jednoduše neměl pracovat. Pokud se tak stane v případě jejich páru, může rovněž dojít k neregulérnímu zásahu.

Jako příklad efektivní ochrany si uveďme obvod ATECC608A od společnosti Microchip Technology. Jedná se o bezpečnostní prvek, který lze díky využití standardní komunikační linky I²C či Single-Wire zapracovat v libovolném systému s mikrokontrolérem. Součástka spojuje non-volatilní paměť s několika kryptoakcelerátory navrženými tak, aby podporovaly algoritmy založené na eliptických křivkách, např. v rámci zabezpečené polovodičové struktury. Součástka prostřednictvím komunikační linky nikdy neodhalí privátní klíče a dále přichází i s řadou hardwarových funkcí zamezujících neoprávněnému zásahu, takže se jejího obsahu prakticky nelze dopátrat.

Pravda, bezpečnostní prvek ve spojení s mikrokontrolérem sice poskytuje účinné prostředky pro návrh vestavných propojených zařízení, které mohou zaručit vysokou míru bezpečí, zmíněná kombinace je však pouze dílčí součástí celkového řešení. Existuje zde totiž spousta případů, které si v rámci vestavného softwaru žádají složité protokoly mimo pole působnosti stěžejních funkcí, jež může bezpečnostní prvek nabídnout. Vedle bezpečného zavádění bude zařízení internetu věcí kupříkladu potřebovat komunikovat se vzdálenými host systémy a využívat přitom šifrovaných protokolů, jako je TLS, resp. vytvářet na vyžádání certifikáty dokládající, že zařízení, které se hodlá připojit k nové službě, nebylo napadeno. Když pak chce výrobce či provozovatel služby odeslat aktualizovaný kód, bude potřeba takový podpis u firmwaru zkontrolovat ještě předtím, než dojde ke změně v paměti Flash a systém znovu naběhne.

Jindy se u systému zase setkáváme s požadavkem na detekci příslušenství nebo např. spotřebních náplní s cílem vyhodnotit, zda se nejedná o padělky. Takovou funkci lze realizovat s využitím protokolů, které jsou podobné těm, používaným při verifikaci kódu, ovšem s některými odlišnostmi. Každá periférie může mít například svůj vlastní bezpečnostní prvek sloužící ke kontrole, že host systém, ke kterému se připojuje, bude sám originální.

Ačkoli mohou být principy stojící za každým z protokolů zajišťujících zmiňované funkce docela jasné, samotná implementace již může být složitější. Schopnost odladit problémy je totiž omezena potřebou systému jednat v souladu se zabezpečenými protokoly.

Ve vývoji se potkáváme s běžným předpokladem, že stisk resetovacího tlačítka nebo vyčištění obsahu paměti umožní technikům získat přístup k nereagujícímu zařízení. Režimy pro ladění obvykle dávají vývojáři privilegovaný přístup do systému. Pokud ale máme co do činění s vyššími úrovněmi zabezpečení vyžadovanými pro systémy, které se budou následně připojovat k internetu, některé z těchto domněnek již nemusí platit. Pokud tedy implementace softwaru selže tím „správným způsobem“, může to znamenat, že se k prototypu nebude možné dostat. Nejproblémovější oblasti vývoje zabezpečeného systému souvisí s laděním základních protokolů. Je kupříkladu snadné zanést programové chyby do kódu použitého ke zpracování hesel či bezpečnostních certifikátů, takže již zařízení nebude schopné reagovat na platné požadavky. Pokud by bylo možné zařízení resetovat k získání přístupu, mohla by se útočníkům otevřít snadno použitelná zadní vrátka do systému. Vývoj zaměřený na bezpečnost tak ve výsledku vnáší do celého procesu komplikace. Jestliže ale tým nemá s vyžadovanými postupy zkušenosti, bývá obtížné se s nimi vypořádat.

Jedna výhoda systémů vystavěných na základě infrastruktury PKI nicméně spočívá ve skutečnosti, že aplikace lze realizovat na vyšší úrovni a případy, jako je ověřování podepsaných záležitostí, pak můžeme opakovaně využít rovněž u řady dalších projektů. To se již ale postupně dostáváme k principům Trust Platformy od Microchipu. Zmíněná platforma přichází s možnostmi konfigurace, zdrojovým kódem a také hardwarovými nebo softwarovými nástroji navrženými tak, aby mohli vývojáři během návrhu směřujícího od konceptu až po realizaci s využitím hardwaru v podobě bezpečnostního prvku, kterým je obvod ATECC608A, pohodlně vyhovět různým požadavkům.

S Trust Platform se pojí tři hlavní záležitosti. Nejjednodušší je Trust&GO, která poskytuje pevně danou sadu funkcí zajišťujících pro zařízení přístup k cloudovým službám řešeným přes AWS, Google Cloud, Microsoft Azure či privátní systémy. V případě zařízení, která se mají připojovat k bezdrátové síti LoRaWAN, pak Trust&GO rovněž podporuje ucelené možnosti bezpečnostního ověřování.

Další úroveň při uzpůsobení dle konkrétních potřeb nabízí TrustFLEX řešící otázku celé řady operací – od zabezpečeného bootování až po tvorbu certifikátu. Třetí z možností, TrustCUSTOM, konečně pomáhá při tvorbě a také zapracování bezpečnostních prvků v rámci požadovaného modelu.

Obr. 2 Postup během vývoje založeného na Trust Platform od Microchipu
 

Důležitá součást Trust Platformy, která v porovnání s ostatními zjednodušuje dostupnost zajištěného řešení, spočívá ve způsobu nasazení služby spojené s bezpečnostními klíči v případě aplikací z oblasti malosériové výroby. Konkurenční přístupy mohou v této oblasti počítat s minimálním odběrem 100 000 kusů. Důvodem je režie spojená s nastavením výchozích certifikátů a klíčů, které bude potřeba na straně dodavatele a jeho zabezpečené výrobní linky v rámci hardwaru naprogramovat. Pokud jde o Trust&GO, zákazníci mohou zakoupit bezpečnostní prvky již od desíti kusů a obdržet přitom kompletní podporu, kterou infrastruktura Trust Platform nabízí, a to včetně zřizování. V případě TrustFLEX zahrnuje minimální objednávka pouze dva tisíce jednotek, taktéž včetně zřizování, nicméně stále zde máme k dispozici vyšší úroveň řízení, pokud jde o certifikáty, klíče nebo aplikace, které mohou být v rámci zabezpečených řešení na zakázku očekávány.

Díky Trust Platformě od společnosti Microchip získávají vývojáři přístup k velmi dobře přizpůsobitelným bezpečnostním mechanismům, navíc s výrazně menším rizikem spojovaným s vývojem a také následným nasazením, než je tomu u stávajících řešení. Kombinace jednotlivých nástrojů, zdrojového kódu a stejně tak i podpůrné infrastruktury při dodávkách otevírá pro vývojáře pracující na vestavných zařízeních možnosti kompletního bezpečného systému, který směřuje od fáze konceptu až po výsledné nasazení a celý proces dokáže zkrátit z řádu měsíců až na dny.

Obr. 3 Trust Platforma od Microchipu a otázka objednávek/doručení
 

www.microchip.com/design-centers/security-ics/trust-platform