A kiberbiztonsági fenyegetettségek térképe gyakorlatilag a legtöbb elektronikai termékszegmensben jelentős terebélyesedett a „dolgok internete” (IoT: Internet of Things) korszak beköszöntével. A hálózatba bekerülő, minden IoT eszköz nemcsak a rendeltetés szerinti funkcionalitással, hanem egyben új támadási felülettel is bővíti a rendszert, amely nem korlátozódik pusztán az érintett eszközre, hanem kiterjed a menedzselésükért felelős teljes hálózatra lokálisan és felhős léptékben egyaránt.
A támadások súlyos következményekkel járhatnak, mivel egy IoT eszközön végrehajtott, sikeres támadás lehetővé teheti azt is, hogy az eszközre új, kártékony célokra alkalmas firmware-t töltsön fel a támadó. Bár néhány támadás csupán arra alkalmas, hogy az érintett eszköz üzemszerű működését gátolja (pl. webes robotokból álló ún. botnet egy csomópontjaként működve szolgáltatásmegtagadás típusú támadásokat folytatva), a kifinomultabb támadások konkrétan behatolást is lehetővé tesznek a szolgáltatói hálózatba, nagyobb mértékű károkozásra lehetőséget adva.
A behatolás tekintetében a támadók dolga egyszerűbb, ha csak szoftveres tanúsítványokkal (pl. csak jelszavakkal) működik a rendszer. Az ilyen alapvető tanúsítványok kijátszásával a támadók felhasználhatják az így kinyert információkat arra, hogy távoli szolgáltatásokhoz férjenek hozzá, és kisebb energiabefektetéssel hajtsanak végre további támadásokat. A hardveres típusú biztonsági mechanizmusok megfelelő védelmet nyújtanak az eszközök illetéktelen felhasználása ellen, és alapvetően elmondható, hogy az első támadások sikerességét számottevően csökkentik.
A hardveres biztonság lényege, hogy valódi identitást és hozzáférési kódokat az adott eszközhöz csak a gyártáskor, ún. nyilvános kulcsos infrastruktúra (PKI: Public Key Infrastructure) használatával lehet létrehozni. A PKI-ben minden eszköz rendelkezik egy egyedi privát kulccsal, amelyet matematikai úton kötnek egy ismert minőségű digitális tanúsítványhoz, amelyet maga a gyártó tart biztonságban. Ezt a privát kulcsot használják fel egy lekérdezéskor annak aláírására, amely végeredményben az eszköz egyedi azonosítását jelenti bármely olyan szerver számára, amely számára a megfelelő nyilvános kulcs ismert. A nyilvános kulcs nem más, mint egy bárki számára látható információhalmaz, ezáltal nem jelent veszélyt olyan szempontból senki számára, hogy közkézen forog, beleértve akár a potenciálisan illetéktelen felhasználókat is. IoT eszközök vonatkozásában az eszköz identitását a saját privát kulcsa biztosítja. A kapcsolódó nyilvános kulcsot a kommunikációs protokollok annak megállapítására használhatják, hogy az állított identitás valós-e? Az eszköz identitása és annak igazolása a teljes életciklusa alatt biztosítható ily módon, ezáltal többek között a távoli firmware frissítés kérdése is megoldottnak tekinthető.
A hitelesítési mechanizmus leírásából nyilvánvaló, hogy kritikus fontosságuk miatt bármilyen titkosítási rendszerben biztosítani kell, hogy az eszközök privát kulcsa se fizikai, se távoli úton ne legyen belőlük kinyerhető. Optimális esetben ezeket a kriptográfiai azonosítókat az eszközökön egy titkosító egység tárolja, amely leválasztottságának köszönhetően biztosítja, hogy a kulcs sosem kerül kiadásra. A megoldás elméletben egyszerűnek hangzik, azonban messze nem triviális. A rendszernek támadásbiztosnak kell lennie, megfelelő védelemmel kell rendelkeznie a lehallgatásos típusú támadások (pl. mellékcsatorna-figyeléses támadás) ellen is. A privát kulcs megfelelő védelme ily módon magas fokú biztonságtechnikai szakértelmet kíván, másrészről pedig a komplett IoT alkalmazás fejlesztési idejét is kiterjeszti. A kellemetlen vonzatok dacára azonban egyáltalán nem olyan típusú felelősség és kényszer fejlesztői oldalról, amely alól ki szabad bújni, hiszen a privát kulcsok biztonságos tárolásának fontossága az IoT-ben létfontosságú. Szerencsére állnak rendelkezésre olyan piaci megoldások biztonságos kulcstárolás céljára, mint például a Microchip Technology-féle ATECC608, amelyek megadják az elvárható szintű védelmet.
1. ábra. A Microchip-féle Trust Platform biztonsági egysége képes olyan titkos információk (pl. kulcsok, tanúsítványok stb.) tárolására, amelyek gyártás közben keletkeznek a gyártó saját, titkosított üzemeiben, és normál üzem közben semmilyen körülmények között nem kerülnek ki a külvilágba.
Bár ilyen megoldások valóban léteznek, a hardveres hátterű identitásmenedzsmenttel kapcsolatban maradnak még további tennivalók. A legtöbb alkatrészgyártó, rendszerintegrátor és szolgáltató számára igencsak bonyolult feladatot jelent, hogy olyan minőségben implementálja a biztonsági mechanizmusokat, hogy azok még egy mindenre felkészült támadó elől is rejtve tartsák az érzékeny adatokat. A hagyományos megközelítés szerint a titkosított adattárat hardverszinten a titkosított adatokkal dolgozó gyártóüzemben konfigurálják fel a megfelelő privát kulcsokkal, azonban az ellátási lánc és logisztikai megfontolások miatt e megoldás korlátozottan használható csak a nagyléptékű telepítések miatt. Minden egyes eszköz titkosított identitással való ellátásához a gyártási folyamatot ennek megfelelően kell kialakítani, amely rendkívül költséges mulatság, hacsak a nagy költség nem oszlik el a nagy termékmennyiségen, így az egy darabra jutó többletköltség végeredményben elenyésző mértékűre zsugorodik.
Most már azonban arra is lehetőség van, hogy a szükséges titkosított konfiguráció feltöltését már minimális rendelési mennyiség esetén is költséghatékonyan elvégezzék a gyártók IoT-re való előkonfiguráció és megelőző kiutalás alkalmazásával. Ezzel a Microchip-féle Trust Platform által is támogatott szolgáltatási modellel még a legegyszerűbb IoT biztonsági kamera, hálózati átjáró, légkondicionáló vagy bármilyen hasonló alkalmazás is megfelelően ellátható titkosítási szempontból előgenerált, eszközfüggő tanúsítvánnyal, amely egy titkosító egységben foglal helyet, és autonóm felhőalapú hitelesítést szolgál. Az eszközönkénti teljes költség ennél a hardveralapú, általános tanúsítvánnyal működő titkosítást kínáló modellnél lényegesen alacsonyabb, mint amit bármely PKI szolgáltató és tanúsítványkezelő harmadik fél nyújtani képes, továbbá ez a modell jelentősen kisebb fejlesztési bonyolultságot és rövidebb piacra kerülési időt is ígér.
A kiválasztott megoldás gyakorlati telepítése
Most, hogy már a kis- és közepes darabszám esetében is megnyílt a mód a költséghatékony hardveres eszközönkénti titkosított kulcstárolásra, a következő lépésben a titkosított adattárat fel kell konfigurálni a legjellemzőbb felhasználási módokra. Ez azért van így, mert az eszközöket el kell látni azokkal a tanúsítványokkal és egyéb kriptográfiai eszközökkel, amelyekre a hitelesítési modellek miatt szükség lesz. Az eszköz legbelső identitásához hasonlóan további privát kulcsok és egyéb titkos információk is előfordulhatnak a rendszerben, amelyeket a hardveres adattárolóban el kell helyezni titkosítva. Például a gyökérkulcsból nem származtatható esetekben szükség van hitelesítésre perifériák, tartozékok, harmadik féltől származó tartalmak, távoli gazdavezérlők stb. hitelesítésére is, ezáltal a tanúsítványok külön kezelésére van szükség.
A titkosító egység működése mögötti elvi filozófia értelmében kezeli a hozzáférést a kritikus fontosságú erőforrásokhoz, illetve illetéktelen tevékenység (pl. gyártó által jóváhagyott firmware cseréje kártékony kóddal ellátott egyedi programra) ellen mintegy ellenőrzőpontiként funkcionál, mintegy elejét véve a kritikus adatok illetéktelen személy általi megismerésének és kiszivárogtatásának. Az illetéktelen behatolás és átprogramozás elleni védekezés egyik kulcseleme a titkosított bootolási mechanizmus alkalmazása, amely a titkosító egység védelmét élvezi. A biztonságos bootolás során az IoT eszköz csak hitelesített programkód futtatására alkalmas, tehát titkosított bootolási körülmények között csak olyan programkódblokkok betöltésére és futtatására van lehetősége, amelyet a gyártó birtokában lévő privát kulccsal írtak alá.
Ha a mikrokontrollernek a bootolásra kijelölt, csak olvasható memóriából kell programkódot betöltenie, a mikrovezérlő ellenőrzést kér a teljességgel megmásíthatatlan nyilvános kulcs által, amelyet a titkosító egység tárol. A mikrokontroller csak abban az esetben kísérli meg a programkód betöltését, ha az ellenőrzés pozitív eredménnyel zárult. Ha a mikrokontroller helytelenül aláírt programkódblokkba fut, felfüggeszti a kompromittált programkód betöltését, és megkísérel visszatérni gyári alapállapotba, vagy ha arra nem képes, lekapcsolni saját magát. Egész addig, amíg a mikrokontroller bootolási kódja nem változtatható meg csak olvasható memóriaterület vagy védett flash memória alkalmazásával, ez az ellenőrzési mechanizmus nem kerülhető ki.
Miután ez a biztonsági mag helyre került, további felhasználási esetekre lehet a rendszert felkészíteni, így például távoli kiszolgálókon lévő tanúsítványalapú hitelesítés támogatására, amely az IoT eszközök esetében gyakorlatilag létkérdés. A távoli hitelesítés olyan szabványosított protokollokkal működik, mint például a titkosított kommunikációt vezérlő a TLS (Transport Layer Security) és az X.509, amely olyan digitális tanúsítványok kezelését végzi, amelyek kezeskednek az eszköz vagy szolgáltatás eredetisége felől.
Az X.509 szabványban minden digitális tanúsítvány egy legbelső szinten lévő OEM tanúsítványra hivatkozik vissza egy leszármazott tanúsítványokból álló hierarchián keresztül. A tanúsítványok által hordozott információ lehetővé teszi a tanúsítványok legitim tulajdonosainak azonosítását, illetve azokból a nyilvános tanúsítványkulcsok kinyerését a hierarchia felsőbb szintjeire nézve, így végeredményben a leszármazottak tanúsítványa validálhatóvá válik.
Ha egy megfelelően titkosított IoT eszköz egy távoli kiszolgálóval kommunikál, az általa tárolt tanúsítványokban található információkat használja fel annak igazolása érdekében, hogy jogos használója a szolgáltatásnak. Ezzel analóg módon a kiszolgáló pedig a saját maga által tárolt tanúsítványok felhasználásával igazolja az eszköz felé, hogy ő is eredeti. Egész addig, amíg az eszközök fel tudják mutatni a szükséges tanúsítványokat, a kétirányú hitelesítés lehetősége adott.
Az IoT kontextusában a digitális tanúsítványok segítségével a hálózatba belépő eszközök integrálási folyamata leegyszerűsíthető első bekapcsolásuk és hálózathoz történő csatlakozási kísérletük során az interneten keresztül. Ez úgy történik a gyakorlatban, hogy a szükséges tanúsítványok a kiszolgálókhoz elküldésre kerülnek a titkosító egység első programozása során, illetve az eszközön eltárolásra kerül az eszköz saját privát kulcsa, illetve azok a tanúsítványok, amelyekkel az új IoT eszköz a szervereket tanúsítani fogja. Erre a mintára dolgozta ki a Microchip az Amazon Web Services (AWS) szolgáltatóval közösen azt a módszert, amellyel a Trust Platformon így létrehozott IoT termékek AWS IoT szolgáltatásba integrálását teszi lehetővé. A standard protokollok és tanúsítványrendszerek támogatása azt jelenti, hogy azonos technikák könnyen használhatók más felhőszolgáltatással, így pl. a Microsoft-féle Azure-ral is, illetve beleértve természetesen a privát és hibrid felhős infrastruktúrák üzemeltetőit is.
Az IoT egy másik fontos felhasználási modellje a rádiós interfészen keresztül érkező firmware frissítések támogatása az IoT eszközökön. Ezek a frissítések az eszköz frissítés alatti integritásának veszélyeztetése nélkül javítják a biztonsági sebezhetőségeket. A digitálisan aláírt, rádiós interfészen keresztül érkező frissítések hitelessége a bootolási titkosított programkód hitelességének ellenőrzéséhez hasonlatos módon biztosítható, természetesen még a frissítés eszközbe integrálását megelőzően. Amint a frissítés hitelessége ellenőrzésre került és felkerült az IoT eszköz memóriájába, a titkosított bootolás során kötelező teszteket természetesen újra teljesítenie kell az eszköz újraindulását követően.
További felhasználási modelleket jelentenek az integrált elvi megoldások védelme, a tartalékok és opcionális kiegészítők érvényességének ellenőrzése, a felhasználói adatok védelme, a kulcsok rotációja, a LoRaWAN™ hitelesítés stb. Néhány gyártónak olyan külön igényei is lehetnek, amelyek túlmutatnak a legbelső szolgáltatások által nyújtott lehetőségeken. Némely gyártó a korlátozott erőforrásokkal rendelkező IoT eszközök miatt kisebb „rezsiköltségű” hitelesítés implementálását kérheti. A Google Cloud IoT belső hitelesítésben például nincs szükség teljes digitális tanúsítványok létrehozására. A szolgáltatás maga ún. JSON webtokeneket (JWT: JSON Web Token) használ, amelyeket az ATECC608B titkosító egységben található, belső privát kulcsból származtatnak, mintegy kiváltva egy hagyományos jelszavas azonosítást.
A különböző felhasználási modellek rugalmas kezelésének lehetőségét a Microchip által feltalált Trust Platform gyártási/szolgáltatási modellnek, illetve a nagy számú megközelítési módnak köszönhetjük. Az első modell egyszerűséget kínál a felhasználóknak arra, hogy biztonságos tanúsítványokkal rendelkező eszközökhöz jussanak egy alapértelmezett ellátási láncban. Ebben a modellben a titkosító egység privát kulcsa és az általános tanúsítvány gyártás közben kerül előállításra a magas biztonsági fokozattal működő Microchip gyáregységekben. A privát kulcs és a tanúsítványok a teljes kiszervezési folyamat alatt nem kerülhetnek ki, be vannak zárva szilárdan a titkosító egység megfelelő területére, és a szállítás teljes ideje alatt megtartják ezen állapotukat. A vonatkozó nyilvános tanúsítványok a felhőn keresztül vagy a LoRaWAN hálózati beléptető szerverhez továbbíthatók.
2. ábra. Az egyedi kulcskiutalás folyamatát leíró blokkvázlat. A prototípus- és programkód lépést követően a kiutalás egy „kulcsátadó szertartással” és a titkos adatok létrehozásával kezdődik. A prototípustesztelés után a titkos információk a titkosító egységben eltárolásra kerülnek.
Mivel sok gyártó nagyobb hitelesítési rugalmasságot szeretne és megvan a lehetősége tanúsítványok létrehozására és beiktatására a saját hitelesítési láncuk támogatásával, a másodikféle modell egy sor előkonfigurált felhasználási modellt kínál, amelyek e lépések automatikus végrehajtását ígérik. A harmadik típusú modell biztosítja a legszélesebb körű módosítási lehetőségeket, ugyanis ebben a megközelítésben (lásd 2. ábra) a vevő a megrendelését egy üres titkosító egységre adja le, majd a Microchip által biztosított eszközök segítségével valósítja meg a kiutalást. Ebbe beleértendő az az XML program is, amely a privát kulcsok és tanúsítványok hozzárendelésének a vezérlését végzi a titkosító egységbe a Microchip nagybiztonságú gyártóüzemeiben.
Összefoglalva, az online eszközök és a hardvertámogatású biztonságot megvalósító biztonságtechnikai megoldások fejlődésének és terjedésének köszönhetően a cégek gyakorlatilag ma már bármely sorozatnagyság mellett képesek IoT megoldásaikat minden igénynek megfelelően biztonságossá tenni. A konfigurálást és kiutalást kezdetben megnehezítő és jelentősen megdrágító korlátok leomlottak, a fejlődési folyamat végeredményeként létrejött egy széles tömegek számára gazdaságosan elérhető, titkosított ellátási lánc, amely lehetővé teszi a legjobb gyakorlati biztonságtechnikai megoldások akadálytalan terjedését a komplett IoT ökoszisztémában.
Szerző: Xavier Bignalet, termékmarketing-menedzser, biztonságtechnikai termékcsoport, Microchip Technology
