A teljes ellátási láncra kiterjedő, méretezhető beágyazott biztonság

Az IoT megjelenése és rohamos térhódítása rendkívüli biztonsági kihívás a rendszerek tervezőinek. Minden IoT-eszköz sebezhető, ha tervezői nem gondoskodnak arról, hogy az biztonsági szempontból egyedi legyen. Ez utóbbit viszont csak úgy lehet megvalósítani, ha a biztonsági félvezető elemek gyártásától a felhasználásukkal készült végtermék helyszíni üzembe helyezéséig terjedő „szállítási lánc” minden pontjának biztonsága megkérdőjelezhetetlen. A Microchip Trusted Platformja a példa rá, hogy ez a követelmény költséghatékonyan is teljesíthető.

Az eszközbiztonság évek óta másodlagos szempont a beágyazott eszközök gyártói számára – mintha az IoT-területen teljesen megfeledkeztek volna a biztonságról. Az OEM-gyártók gyakran úgy kezelik a biztonsági kérdéseket, mintha azokkal a használati kényelem rovására kellene foglalkozniuk. Tipikus volt az a megközelítés, hogy a karbantartó mérnököknek egyetlen jelszót adtak meg, amellyel feloldhatták a termékcsalád bármely eszközét. Elméletileg ezt mások elől titokban tartották. A gyakorlatban azonban a jelszavak kiszivárogtak, így a rendszerek leghatékonyabb védelmét csak a fizikai biztonság jelenthette. Ha egy eszközt zároltak és elérhetetlenné tettek, ahhoz csak az arra jogosult személyek férhetnek hozzá. Azután viszont, hogy az eszközök az internethez csatlakoztak, és elérhetővé váltak az otthonon vagy a gyáron kívülről is, hihetetlenül sebezhetőkké váltak. Annak a következményei, hogy ugyanazt a jelszót használták egy termékcsalád minden tagjának védelmére, az olyan informatikai támadások során váltak nyilvánvalóvá, mint amely Mirai néven vált ismertté 2016-ban. A támadás révén beágyazott készülékek millióit szervezték botnetté (a felhasználó tudta nélkül, távvezérléssel irányított eszközök „zombihálózatává” – A szerk. megj.), amelyekkel más rendszereket tettek használhatatlanná azok szolgáltatásmegtagadással (denial of service) járó túlterheléses támadásával. A Mirai-támadás célpontjai tömeggyártásban készült eszközök voltak. A kis sorozatban gyártott IoT-termékek számára viszonylagos védettséget jelenthet az, hogy valószínűleg nem válnak azoknak a támadóknak a célpontjaivá, akik új botneteket akarnak megszervezni. A hasonló támadások azonban a kis szériákat előállító gyártók profitját is veszélyeztetik, mivel az IoT megváltoztatja az üzleti modelleket; a bevétel ugyanis egyre növekvő arányban keletkezik a szolgáltatásokban, amely iránt viszont – ha az eszközök könnyen támadhatók – csökken a kereslet. Kritikus fontosságú tehát, hogy minden eszköz egyedi, megbízható identitással és hozzáférést hitelesítő adatokkal rendelkezzék, mivel ezáltal bármilyen tömeges támadás terjedelme korlátozható. Ha a megbízható identitások használata az átfogó biztonsági stratégia részévé válik, az megnehezíti a visszaélést az IoT-szolgáltatásokkal.

Egyedülálló, megbízható identitásuknak köszönhetően a felhőalapú alkalmazások és más IoT-rendszerek képesek eldönteni, hogy mely eszközök férhetnek hozzá szolgáltatásaikhoz. Ezt az identitást azonban valahogyan szavatolni kell annak érdekében, hogy a rendszereket illetéktelenül felhasználni szándékozók számára ne legyen egyszerű feladat azok hitelesítő adatainak felhasználása vagy meghamisítása a hálózathoz és annak szolgáltatásaihoz való hozzáférésre.
A támadás egy másik lehetséges iránya egy készülék védelmének feltörése és olyan új firmware rátöltése, amellyel az eszköz a hekker szándéka szerint működik. Ha nem alkalmazunk olyan módszereket, amelyekkel az egyes eszközökön futó kód eredetisége ellenőrizhető, a rendszer többi eleme nem tudja eldönteni, hogy egy szabályos, fel nem tört készülékkel kommunikál-e vagy sem.
Az eszközök hitelesített azonosításához és a használati jogosultság ellenőrzéséhez egy biztonsági elemre van szükség. Ezt a szerepet egy mikrovezérlő belsejében létrehozott biztonságos zóna is elláthatja. Azonban az ilyen monolitikus architektúra bizonyos erőforrásokon (például a tápvezetékeken, az órajeleken és regisztereken) osztozik is a rendszer többi részével, amely lehetővé teszi, hogy egy képzett hekker illetéktelenül hozzáférjen az egyedi biztonsági adatokhoz. Ráadásul jelentős költségnövekedést is okozhat, ha új mikrovezérlő-achitektúrát kényszerülünk alkalmazni még járulékos szoftveres szakértelem elsajátítása árán is egyedül csak azért, hogy garantálhassuk a tervezett rendszer informatikai biztonságát. A specializáltabb mikrovezérlő használatából adódó többletköltség korlátozhatja a termék piaci versenyképességét és rugalmasságát.
Azonban ezt a váltást nem is szükséges végrehajtani. Helyette a tervezők élvezhetik egy biztonsági elemként működő, külön alkatrész előnyeit. Ez egy olyan félvezetőeszköz, amely – jellemzően egy soros interfészen keresztül – bármilyen mikrovezérlővel képes kommunikálni, és egyesíti magában egy biztonságos, kikapcsoláskor nem törlődő tároló funkcióját egy, a titkosítóalgoritmusok hardveres gyorsítására szolgáló egységgel, amely képes támogatni a nyilvános kulcsú infrastruktúra (Public Key Infrastructure – PKI) használatához szükséges algoritmusok futtatását.
A PKI aszimmetrikus titkosítási algoritmust használ. Ez egy olyan eljárás, amely két numerikus kulcsadatot kapcsol össze matematikai módszerekkel. Ezek egyike a nyilvános kulcs, amely jellemzően a titkosított üzenet hitelességének igazolására szolgál. A nyilvános kulcsot minden probléma nélkül, széles körben bárki ismerheti. A nyilvános kulccsal tehát az üzenet valódisága igazolható. Az üzenetet azonban csak az az eszköz képes hitelesen aláírni, amely a másik numerikus adat, a titkos kulcs birtokában van. Ezt a titkos kulcsot biztonságosan, bizalmasan kell tárolni az aláírásra jogosult eszközben, és sohasem szabad elküldeni egyetlen másik készüléknek sem – így a titkos és nyilvános kulcsok használatával, a PKI segítségével olyan biztonsági funkciók is megvalósíthatók, mint a digitális tanúsítványok. Ezeket a tanúsítványokat általában arra használjuk, hogy azzal az eszköz identitását bemutassuk a rendszer többi tagjának és igazoljuk, hogy az jogosult velük együttműködni. Az olyan protokolloknál, mint az X.509 szabvány, a digitális tanúsítványok láncot alkotnak, amely egy elsődleges tanúsítványra utal vissza. Ez a lánc létfontosságú bármelyik származtatott tanúsítvány érvényességének bizonyításához. Tipikusan egy rendszer, amely ellenőrizni kívánja egy tanúsítvány érvényességét, a „gyermek” (leszármaztatott) -tanúsítvány kibocsátójának nevét használja arra, hogy megszerezze a közvetlen „szülőtanúsítvány” nyilvános kulcsát. A teljes tanúsítványhierarchia ellenőrzése adja a felhasználónak azt a lehetőséget, hogy megbízhasson abban, hogy a tanúsítvány aláírása jogszerűen a tulajdonosé, és eszközt nyújt a hamisítási célú támadások és más, a hekkerek hálózathoz vagy rendszerhez való hozzáférésének megkísérlésére irányuló mechanizmusok elleni védekezéshez. A tanúsítványok cseréjével nem csak a felhőszolgáltatások képesek meggyőződni arról, hogy a készülék a rendszer megbízható tagja; a készülék is ugyanilyen tanúsítványcserékkel győződhet meg arról, hogy megbízható szerverrel kommunikál. Az 1. ábra a tanúsítványláncolatra mutat egy példát.

1. ábra A tanúsítványlánc felépítése (példa)

A felhőszolgáltatások más megoldást kínálnak a biztonság ellenőrzésére. A felhőalapú kezelés egyik fő előnye a szolgáltatók számára, hogy lehetővé teszi a kommunikáció elutasítását egy olyan eszköz nevében, amely például már nincs használatban. Azzal, hogy a szerver eltávolítja az eszközt és annak kulcsait az aktív szolgáltatásból, a hekker nem tudja újraaktiválni a kiiktatott hardvert annak érdekében, hogy azt felhasználva támadást kíséreljen meg a hálózat ellen.
A digitális tanúsítványok és aláírások használata az elektronikai ellátási lánc (a biztonsági félvezetők gyártásától azoknak a végtermékben való aktiválásáig tartó folyamat – A szerk. megj.) gondos kezelésének létfontosságú eleme. A szabványos X.509 tanúsítványokon alapuló rendszerek egyik lehetséges gyenge pontja, hogy az ellátási lánc problémái potenciálisan ahhoz vezethetnek, hogy a hekkerek manipulálhatják a tanúsítványokat, vagy megszerezhetik a titkos kulcsokat, amikor azokat a gyártósoron lévő eszközbe programozzák.
Ideális körülmények között a titkos kulcsok soha nem kerülhetnek ki a biztonsági elem határain kívülre, de ahhoz a művelethez, amely során a tanúsítványok és a megfelelő kulcsok között létrejön a kapcsolat, néhány megoldásnál a biztonsági elembe annak készre szerelése után írják bele a kulcsot egy flashmemória-programozó segítségével. Ha a hekker hozzáférést szerez a programozóhoz, képes megszerezni a kulcsokat is, vagy a saját tanúsítványaival helyettesítheti azokat, amelyek révén az eszközhöz – annak beépítése után – hozzáférhet.
Ennél biztonságosabb alternatívát jelent az a megoldás, amelyet a Microchip ATECC608b – valamint az eszközcsaládjába tartozó többi alkatrész – gyártása során használnak. A titkosításhoz szükséges adatokat a Microchip gyártóüzemeiben telepített hardverbiztonsági modulok (Hardware Secure Module – HSM) generálják minden egyes gyártott biztonsági elem programozásával azonos időben. Az ATEC608a nem teszi elérhetővé a titkos kulcsokat a saját kommunikációs portjain keresztül, és olyan hardveralapú „babrálásvédelmet” is tartalmaz, amely az eszköz fizikai megbontása esetén is megakadályozza az eszközben tárolt titkos információ megszerzését. Ha például egy támadó megbontja a biztonsági elem tokozatát, és átvágja az érzékeny áramköröket védő fémborítást, hogy megkísérelje az eszközben tárolt titkos információt érintkezőszonda segítségével kiolvasni, az alkatrész azonnal működésképtelenné válik. Ezenkívül ellenintézkedéseket építettek be a titkosítási folyamatoknak a külső paraméterek megváltoztatásával elérhető megzavarása (glitching attack), valamint az eszköz elektromágneses sugárzásának vagy tápáramfelvételének passzív megfigyelése útján végrehajtható támadása ellen is.
Nem elég azonban a titkos kulcsokat és tanúsítványokat egyszerűen csak kívülről elérhetetlenül tárolni a biztonsági elemben. A biztonsági elemek szállítási láncában szükség van olyan mechanizmusok megvalósítására is, amelyek tanúsítványokat generálnak és továbbítják azokat a biztonsági elemet gyártó cég telephelyére, ezért az OEM vagy a rendszeroperátor gyakran tárol olyan listákat is, amelyekben azok az eszközök vannak feltüntetve, amelyek – majd a telepítésük után – a hálózathoz csatlakoztathatók. Ezen tanúsítványok némelyikét át kell küldeni abba az adatbázisba is, amelyet a felhőszolgáltató használ az eszközök használati jogosultságának ellenőrzésére. Könnyű elképzelni, hogy egy ilyen gyártási infrastruktúra létesítése összetett és költséges vállalkozás. Nemcsak abból áll, hogy megvásároljuk és üzemeltetjük a hardverinfrastruktúrát, mint például a HSM-eket a biztonsági elemek programozásához, hanem magában foglalja a kiképzés és a személyi feltételek biztosításának magas költségeit is. A házon belüli biztonságspecifikus programozás magas költségei miatt létezik egy olyan megoldás is, amelyben a műveleteket kiszervezzük egy szerződött elektronikai gyártónak vagy más szolgáltatónak. Azonban ennek általában magas a létesítési költségvonzata. A tanúsítványokat generáló és az eszközöket a felhasználónak leszállító szolgáltatásokat minden termékhez „testre kell szabni”. A telepítés önköltségének fedezésére a rendszerszolgáltatók rendszerint minimális rendelési mennyiségeket írnak elő, amelyek a százas vagy ezres nagyságrendű tételszámokat is elérhetik.
A problémára az egyik válasz a kulcskezelés egyetemes, „minden méretre ugyanazt kínáló” megközelítése lett. Ez az alkatrészgyártók és a felhőszolgáltatók között mély partnerséget feltételez, beleértve a tanúsítványok létrehozását és kezelését is. Az összes tanúsítvány a központi tanúsító hatóságként működő felhőszolgáltatóhoz vezethető vissza. Adatbázisát minden olyan IoT-eszköz felügyeletére használják, amelyek tanúsítványait és egyéb adatait a rendszerfelhasználók megbízásából nyilvántartja. Ehhez azonban nem szükséges, hogy az ügyfél egy bizonyos felhőszolgáltatáshoz legyen kötve. Ehelyett a központi szolgáltatás hitelesítési és egyéb biztonsági szolgáltatásokat nyújt, amelyeket az ügyfelek saját felhőalkalmazásai használhatnak. Ez megszabadítja őket a biztonság és a hitelesítés napi kezelésétől, és segíti őket abban, hogy a saját alapvető alkalmazásukra összpontosíthassanak. Ebben a modellben viszont a gyártó nem járhat el tanúsító hatóságként saját eszközeihez, és minden hitelesítési szolgáltatáshoz ugyanazt a felhőszolgáltatót kell használnia. Sok gyártó igényel ennél rugalmasabb megközelítést a biztonság kezelésének megoldására. Az ideális tanúsítványkezelő struktúrát az alkalmazás igényei határozzák meg. Egy tipikus IoT-forgatókönyvben, ahol nagyszámú eszközt kell sok végfelhasználónak kiszállítani, a legfelsőbb szintű tanúsítványt valószínűleg az OEM birtokolja és kezeli. Ugyanakkor több művelet végrehajtását ruházza át olyan szolgáltatóknak, amelyek működése közbenső szintű tanúsítványokon alapul. Például, ha a rendszereket a kiválasztott hálózatba kívánja beépíteni, minden egyes ügyfél az adott „gyökérből” (root – a legmagasabb szintű tanúsítvány) származtatott köztes szintű tanúsítványt használhat az eszközszintű tanúsítványok előállításához. Ez lehetővé teszi, hogy az ügyfél szerverei vagy felhőben futó alkalmazásai ellenőrizzék az eszközök identitását, és gondoskodjanak arról, hogy csak a megfelelő IoT-eszközök működhessenek a területükön.
A biztonság és a tanúsítványkezelés rugalmasabb megközelítése érdekében a Microchip kidolgozta az ATECC608b biztonsági elemre, mint hardveralapra épülő Trust Platform (2. ábra) rendszerét. Ez számos automatizált szolgáltatás révén teszi lehetővé, hogy a felhasználók minden alkalmazásukhoz a legjobban illő tanúsítványstratégiát választhassák, továbbá számos fejlesztőeszközt és forráskódot is tartalmaz, amelyekkel az általánosan használt hitelesítési és biztonsági műveleteket valósíthatják meg.

2. ábra A Microchip Trust Platform rendelési és szállítási folyamata

A Trust Platformnak három szintje van. Az eszköztanúsítványon alapuló Trust&GO szint csupán csak egy architektúra azokkal a képességekkel felruházva, amelyekkel biztonságos jogosultságkezelést lehet előállítani a leszállított eszközökkel, de bármiféle egyedi titkos információ beírására vonatkozó igény nélkül. Az eszközbe épített összes műveletvégző képességet olyan hiteles felhőszolgáltatók támogatják, mint az AWS, a Google vagy a Microsoft Azure. Azáltal, hogy az eszköz minimális rendelési mennyisége mindössze 10 egység – a kulcsok telepítését is beleértve –, a szolgáltatás jól illeszkedik a prototípusok előállításának, helyszíni tesztelésének és kis sorozatú gyártásának igényeihez, például olyan termékeknél, mint a LoRaWAN hálózatok és más TLS titkosítást alkalmazó rendszerek.
A 2000 egységes minimális rendelési mennyiséggel szállítható TrustFLEX megoldásszint azt a lehetőséget kínálja, hogy a gyártási folyamatba integráltan a Microchip a HSM-technológiája segítségével egyedi tanúsítványokat is betölt a biztonsági elembe. Az eszközök előkonfigurált, generikus tanúsítványokkal is szállíthatók. A TrustFLEX fejlesztői támogatása a használati esetek széles tartományát fedi le, beleértve a biztonságos rendszerbetöltés, a firmware érvényességének ellenőrzése, az I/O-védelem és a rendszeres kulcscsere támogatását is, amelyek a biztonság hosszú távú fenntartásának lényeges feltételei.
A TrustCUSTOM szint kínálja a maximális rugalmasságot teljesen alkalmazásfüggő, „testre szabott” megvalósításban, amely akár már 4000 egységnyi minimális rendelési mennyiségnél is elérhető, és az eszköz aktiválását is magában foglalja. A felhasználók hozzáférhetnek a Microchip gyáraiban használt HSM-berendezések aktiválási képességeihez, ezáltal tehát akár még a gyártás folyamán is megadhatják az eszközben tárolni kívánt titkos biztonsági adatokat. Az egyes hozzáférési szinteknek megfelelő eszközök lehetővé teszik a konfigurációs fájlok és a Microchip által előállított minden egyes biztonsági elem beállításához szükséges tanúsítványok feltöltését. Minden eszköz szállításakor a Microchip nyilvános fájlt ad át, amely tartalmazza az egyes biztonságos elemek sorozatszámát és nyilvános kulcsát, így a részletek beilleszthetők az adatbázisokba, amikor a késztermék csatlakoztatásra kész. Ezek az információk nem bizalmasak, ezért nem biztonságos csatornákon keresztül is továbbíthatók.

3. ábra A felhasználó által bejárt útvonal a Microchip Trusted Platform különböző szintjein

Az igazolható egyedi identitás az IoT alapvető jellemzője. Nélküle lehetetlen teljesíteni a biztonságos működés feltételeit. Mindezideig az IoT-alkalmazások biztonságát sikeresen szavatoló egyedi identitás elérése az ellátási lánc nagyfokú testreszabásával volt csak lehetséges. Ez a testreszabás többletköltséget okoz, mivel minden mikrokontroller számára egyedi firmware előállítását tételezi fel a gyártási környezetben. A világméretű, mégis töredezett IoT-gazdaságban a beágyazott rendszerek erősen költségérzékenyek, és a biztonság költségigénye a szorosan vett anyagköltségen felül jelenik meg a gyártási költségekben. A Microchip Trust Platform megoldásszintjei (3. ábra) viszont a feladat jellegéhez és terjedelméhez igazított, „skálázható” szállítási lánc igénybevételével költséghatékony eszközöket kínálnak minden beágyazott rendszerhez az egyedi eszközidentitás és a távoli jogosultságellenőrzés előnyeinek kihasználására.

Szerző: Nicolas Demoulin, EMEA marketingigazgató –
Secure Products Group, Microchip Technology Inc.

www.microchip.com