Habár a támadások elsődleges célpontjai mindenekelőtt a szerverek, az IoT-alkalmazásoknál egyre több támadásnál a relatíve egyszerű felépítésű (és alapszintű védettségű) és a hálózat szempontjából látszólag ártalmatlan szerepű eszközök válnak célponttá. Elvégre ki gondolná komolyan, hogy egy akváriumban elhelyezett, elektromos hőmérő potenciális veszélyt jelenthet egy nagyvállalati informatikai hálózat biztonságára? Pedig egy kaszinóban pontosan ez történt, ugyanis a hackerek pontosan ennek a gyengén védett hőmérőnek a sebezhetőségét kihasználva nyertek hozzáférést az infrastruktúra maghálózatához, amely révén kényelmesen hozzáfértek az érzékeny adatokat tartalmazó ügyféladatbázishoz, amit természetesen le is másoltak. A behatolásra csak akkor derült fény, amikor egy biztonságtechnikai szakértő elemezte a hálózati hozzáférésekről vezetett naplófájlokat, amelyből láthatta, hogy egy finnországi szerverre olyan protokollokkal végeztek adatáttöltést, amelyet normálesetben médiaszolgáltatók használnak a műsoraik streamelésére.
Egy további példa a bankszektorból származik, ahol is a behatolást a zárt láncú televíziós (CCTV) hálózaton keresztül hajtották végre. Az eset paradox jellegét erősíti, hogy éppen a biztonságtechnikai célból telepített rendszer segítette hozzá a támadókat a behatoláshoz. Ismét egy másik példa, ezúttal az otthoni kémkedésre, a robotporszívók fedélzeti kamerája által készített képek ellopása. A jó hír az, hogy ezek és a hozzájuk hasonló támadások kivédhetők, a maghálózat és az eszközök védett állapotban tarthatók. Ennek a kulcsa a többszintű biztonság alkalmazása, amely jelentősen megbonyolítja a sikeres támadást és növeli annak időszükségletét.
Manapság a hackerek figyelme leginkább azokra a hibákra irányul, amelyek helytelen fejlesztői döntések eredményei. Ezek egyike az alapértelmezett jelszók megtartása, amelynek használatával a felhasználók távolról bejelentkezve vezérlőfelületekhez férhetnek hozzá. E jelszók viszonylag gyakoriak, és azt a célt szolgálják a gyártók ajánlása szerint, hogy az IoT eszközök minél gyorsabban működésre bírhatók legyenek. A legjobb gyakorlati megoldás az, ha minden eszközt saját, egyedi jelszóval látnak el. Ettől független tény, hogy ahogy a gyártók fejlesztik az alapvető biztonsági megoldásaikat, a kiberbűnözők tudása és eszköztára is annak megfelelően gyarapodik. A beágyazott rendszereknél nem elég mostantól a számítástechnikai tudásukhoz és bekerülési költségükhöz mérhető biztonsági megoldásokat alkalmazni, hiszen láthattuk, hogy rajtuk keresztül mekkora károkozás lehetséges (lásd a kaszinó példáját).
Egy hálózatos rendszer támadása kapcsán többféle támadástípust különböztethetünk meg (a különböző jellegű támadástípusokat és az ellenük lehetséges óvintézkedéseket az 1. ábra foglalja össze). Ezek egyike a szoftveres eredetű sebezhetőségek kihasználása általános technikákkal. Például, ha az eszköz a pufferrel allokáltnál nagyobb mennyiségű adatot kap valamely csomagban, a kapacitáson túlmutató bájtok túlcsordulnak a szomszédos adatstruktúrákba. Ha egy később induló rutin kiveszi ezeket a bájtokat a stackből, az adatokat más rutin is felhasználhatja, amely összeomláshoz vagy hibás eredményekhez vezethet, sőt a processzor tévesen elágazási címként is értelmezheti azokat az adatokat, amely téves programkódfuttatáshoz vezet. Ha a hacker számára ismeretes az eszköz memóriarendszere, ezen elv mentén képes olyan miniprogramokat írni, amelyek feltárják előtte magát az eszközt. Egy hasonló működési elvű támadás képes olyan hibás adatokat küldeni az eszközre, amely szándékosan bedönti az adatfeldolgozó szubrutinokat, sebezhetőséget kínálva az eszköz felett.
Néhány támadásfajta az eszköz által futtatott szoftver helyett a kommunikációs protokollokat helyezni előtérbe, azzal a céllal, hogy a rendszert túlterhelve térdre kényszerítse azt. A túlterhelés hatására az IoT-alkatelem megkezdi a visszaállítást, és ez az a pont, amelynél a támadó megkísérli a behatolást. Ha a támadó képes közeli hálózati eszköz vezérlésére vagy akár a közvetlen fizikai hozzáférésre, képes lehet megszemélyesíteni legitim szervereket is, amelyekkel az eszközök normálesetben kommunikálnának. Ezek a közbeékelődéses, ún. man-in-the-middle jellegű támadások képesek arra, hogy az eszközből érkező adatokat befogadják és elemezzék, felhasználva egy későbbi potenciális támadáshoz. E támadástípus egy alternatív lehetősége keretén belül a támadó megkísérelheti a saját firmware-ének feltöltését az eszközre, amely az eszköz újraindulása alatt élesedik, kiváltja az eredeti, gyártói firmware-t a támadó által írt kártékony változattal, amely máris képessé teszi az IoT-csomópontot a támadó szándékai szerinti működésre.
Ideális esetben a rendszer megtagadja a kommunikációt azon partnerekkel, amelyek nem képesek hitelesen demonstrálni a megfelelő jogaikat. Ebben az esetben az eszköz egyszerűen visszautasítja a támadó által kreált, nem hiteles firmware-t, és képes lehet arra is, hogy érzékelje a szolgáltatásmegtagadásra irányuló, elárasztásos támadásokat, meggátolva az erőforrások teljes lekötését és a rendszer letérdelését. Hovatovább megakadályozható az is, hogy a rendszer érzékeny adatokat küldjön egy olyan partnernek, amely tanúsítványa nem megbízható. Az eszköz általi fogadhatóság szempontjából nem megfelelő hosszúságú csomagok terjedelme és tartalma ellenőrizhető lehet, ezáltal az eltorzított csomagok visszautasíthatók, elkerülhető a puffer túlcsordulása és a parancsbefecskendezéses támadás is. Ez mind nagyon szépen hangzik, a gond csupán az, hogy mindezek gyakorlati implementálása olyan drága lehet, amely a gyakorlatban, piaci körülmények között ellehetetleníti az alkalmazást (különösen a harmadik féltől származó függvénykönyvtárakra és alkalmazásokra gazdagon építkező megoldások esetében).
Ehelyett egy gyakorlatiasabb és realisztikusabb megoldás az, ha a firmware-t eleve szekciókra osztják, amelyek egy részéhez magas szintű biztonsági tanúsítványokra van szükség, egy másik része pedig akár el is bukhat támadás esetén, mivel nem tartalmaz biztonsági szempontból kritikus részeket. Ez utóbbira példa lehet a hőmérsékletmérést végző szubrutin, amely JSON formátumba csomagolja az adatokat és készíti elő őket egy okostelefonos alkalmazásba továbbításra alkalmas formába, amelynél könnyen belátható, hogy nem jelent biztonsági kockázatot a működése. A biztonságos programkód azonban biztosítja, hogy az adat kiküldése előtt a titkosítás megfelelően megtörténjék.
Az eszközön futó, teljes biztonsági körültekintést igénylő szoftverhányad csupán egy töredéke az eszköz teljes programkódbázisának. A két kódterület elkülönítése csak abban az esetben hatékony, ha a nem titkosított programkódok oldaláról nincsenek olyan hátsó hozzáférési pontok, amelyek hozzáférést adnak a nagy biztonságú rutinokhoz, hiszen ezeket a sebezhetőségeket a hackerek előszeretettel és nagy szakértelemmel használják ki privilégiumeszkalációs támadások során. Ha például egy puffertúlcsordultatásos támadás olyan adatot tölt be a biztonságosnak titulált memóriába, amely alapján a támadó biztonságos partnerként személyesítheti meg önmagát, a rendszer védettsége nyomban elillan. A tanulság az, hogy a titkosított memóriát a nem titkosított területtől mindenképpen el kell szeparálni, amely csakis hardveres úton valósítható meg.
Az olyan fejlett beágyazott mikrovezérlők, mint a Microchip SAM L11 termékcsalád, tartalmaznak Arm® TrustZone® architektúrabővítményen alapuló, integrált biztonságtechnikai hardvert, amely a szoftveres támadások ellen egyedi védelmet biztosít. A SAM L11-sorozatú mikrokontrollerek hardvereszközei lehetővé teszik bizalmi rendszer felépítését, amely alapján kiterjeszthető a biztonsági védettség a rendszer többi elemére, megteremtve ezzel egy széles körű biztonsági keretrendszer kiépítésének feltételeit.
Ez a bizalmi gyökér képes olyan kriptográfiai műveleteket végrehajtani, amelyek a biztonsági zónát önmagából növesztve kiterjesztik, és ezzel további rendszerelemeket magukba foglalni, illetve a kommunikációt egy nem megbízható hálózattól védett állapotban tartani. A beépített kriptográfiai vezérlő hatékonyság szempontjából csoportosítja és kezeli a műveleteket, amelyek tartalmazzák a munkamenet kialakulását megelőző kulcsgenerálást és a sifrírozó/desifrírozó műveleteket is. A kontroller képes továbbá nemcsak a bejövő adatok hitelességét ellenőrizni, hanem a rendszer által futtatott programkódét is, a kriptográfiai védelem pedig hamisított hardverek ellen is védelmet garantál. Ebben az esetben a megbízható zónán belül futtatott szoftver képes a rendszer más kártyáinak megszólítgatására is olyan kérdésekkel, amelyekre garantáltan csak a hiteles bővítmények ismerik a helyes választ.
A biztonsági gyökér üzemszerű állapotban megtartása érdekében a SAM L11-sorozat hardvere titkosított bootolást is biztosít, megsértése ellen az eszköz úgy védekezik, hogy a kezdeti bootszekvenciát egy, csak olvasható memóriaterületen tárolja, amelynek tartalma a mikrovezérlő gyártása után már nem módosítható, illetve tartalmának betöltése a bootolás során nem megkerülhető. Amint a kezdeti indulás megkezdődött, a boot ROM-ban található kódellenőrző rutin ellenőrzi a fennmaradó, bootolás befejezéséhez szükséges firmware hitelességét. A mikrokontroller kriptográfiai gyorsítójának támogatásával mindezt úgy végzi, hogy ellenőrzi az egyes firmware-szegmensekkel együtt tárolt hashelési paramétereket, annak biztosítása érdekében, hogy azok megfeleljenek a mikrokontroller gyártása során beégetett referencia-ellenpároknak. Ha az ellenőrzés során a vezérlő nemegyezést tapasztal, az eszközt újraindítja, és ezzel együtt újraindul a titkosított bootolás is. Ez oda vezet, hogy még ha a hackernek sikerül is a mikrokontroller flash-memóriájába hamisított firmware-t feltölteni, az eszköz addig nem fog tudni megfelelően bootolni, amíg a gyártói firmware-változat vissza nem kerül a helyére.
Amint a mikrovezérlő bootolása sikeresen megtörtént, amelynek eredményeként egy ismerten hiteles firmware-t futtat, a SAM L11-ben működő Arm TrustZone technológiai implementáció gondoskodik róla, hogy a titkosított és potenciális veszélynek kitehető memóriaterület egymástól tisztán elszeparált módon létezzék. A SAM L11-ben működő, Arm Cortex-M23 processzormag Arm TrustZone technológiája lényegében biztonsági célú utasítások egy gyűjteménye, amelyekkel ellenőrizhetők a nem biztonságos minősítésű programkód függvényhívásai a titkosított memóriaterületre. Az Arm TrustZone technológia lehetővé teszi olyan szoftveres biztonsági tartományok definiálását, amelyek korlátozzák a hozzáférést a memóriához, perifériákhoz, I/O-vonalakhoz stb. a megbízhatónak titulált szoftverek számára, így fenntartva a komplett rendszer biztonságosságát (lásd 2. ábra). A biztonságos programkódok begyűjthetők és védhetők, ezáltal az Arm TrustZone technológia jelentősen egyszerűsíti a beágyazott eszközök biztonsági kiértékelését.
2. ábra. Standard interakciók a biztonságos és nem biztonságos állapotok között
A biztonságos és nem biztonságos kódok közötti megkülönböztetés és elválasztás érdekében a SAM L11 memóriája több, különböző régióra van particionálva, amelyek mind biztosítottak a szoftveres támadások ellen. Ha bármely biztonságos régiót nem biztonságos programkódból próbálnak meg elérni, vagy eltérést érzékel a rendszer a végrehajtott kód és a rendszer biztonsági besorolása között, hardverhibára fut a rendszer, amely megakadályoz minden további végrehajtást, és a rendszer újraindulását eredményezi. Ez a fajta védelem a megszakításkezelés és hibavadászat során is fenntartott.
Az Arm TrustZone technológiai implementáció két stack pointert kezel, amelyek elkülönítik egymástól a biztonságos és nem biztonságos végrehajtást, és megszakításkezelőn keresztül megakadályozzák a stackben lévő adatok elérhetőségét (lásd 3. ábra). Hibavadászat során a biztonságos és nem biztonságos kódot hibavadász-hozzáférési szintekkel különbözően kezeli a rendszer. A nem biztonságos részeken dolgozó fejlesztő közvetlenül nem fér hozzá és pláne nem változtathatja meg a titkosított programkódokat és a hibavadászattal kapcsolatos információkat. Ez elősegíti a felelősségek határozott szétválasztását is, így csak a megfelelő biztonsági tanúsítványokkal rendelkező fejlesztőknek áll módjában a titkosított programkódokon aktívan dolgozni (lásd 4. ábra).
Jellemzően a gyakorlatban mindez úgy történik, hogy a biztonságos programkód fejlesztésével megbízott fejlesztő biztosítja azokat a headerfájlokat és függvénykönyvtár-rutinokat, amelyek lehetővé teszik nem biztonságos programkódok számára kérések intézését, amely lehet például hálózati csomag titkosítása interneten keresztül történő továbbítás céljából. A titkosított alkalmazás egy védett memóriaterületre kerül az eszközben. Ha egy biztonsági tanúsítványokat nem birtokló fejlesztő írja a hálózati programkódot, felhasználhatja a könyvtárakat és linkerfájlokat minden további nélkül, azonban csak alkalmazásprogramozási interfész (API)-szintű hozzáférésre lesz jogosult, tehát maga a titkosított programkód és adatai feketedobozként fognak látszani számára. A titkosított kód megváltoztatására tett kísérlet alapján kényszeríthető az eszköz újraindítása, amelynek ellenőrzési alapját a hash-paraméterek összehasonlítása képezheti. A konzisztencia-ellenőrzés a SAM L11-sorozatú mikrovezérlőkön a hamisíthatatlan titkosított bootolás alatt erre tökéletesen lehetőséget kínál, és például a pointer manipulálására (nem jóváhagyott helyre irányítására) tett kísérlet hibaeseményhez is vezethet.
A perifériákat is lehet biztonságos és nem biztonságos jellegűként katalogizálni, amelynek eredménye szerint csak a tanúsított szoftverek kaphatnak hozzájuk hozzáférést vagy felettük közvetlen vezérlési lehetőséget. A mindkét fajta régió számára szolgáltató perifériák esetében a hozzáférés-vezérlés a függvényhívásokhoz hasonlóan valósítható meg. A nem biztonságos programkódnak hozzáférés-igénylést kell küldenie API-alkalmazáson keresztül, amelyet a titkosított kód szolgáltatója biztosít. Ez a működési mechanizmus garantálja, hogy a periféria közvetlen vezérlésére csak tanúsított programkódból van lehetőség, amely az illetéktelen használat ellenőrzésére is fel van készítve. Nem biztonságos programkódból mód van olyan kérések indítására, mint például időzítőállapot kiolvasása, azonban annak alaphelyzetbe állítására már nincs lehetősége.
A külső perifériák és alrendszerek csak akkor intézhetnek kéréseket a mikrokontroller felé, amennyiben a mikrovezérlő titkosított, fedélzeti memóriájában tárolt, digitális tanúsítvánnyal összecsengő hash-paraméterértéket tudnak szolgáltatni. Ez megakadályozza, hogy a hackerek a kompromittált periféria felhasználásával módosíthassák a rendszer működését, és egyúttal meggátolja azt is, hogy a gyártói eszközt hamisított alrendszerek eszközeként használhassák fel. Még ha a támadó elméletileg képes is lenne a RAM kulcstárolásra kijelölt 256 bájtjának kiolvasására és átírására, a SAM L11 biztonsági mechanizmusai kinullázzák a kulcsokat és az adatokat is abban az esetben, amint ilyen jellegű tevékenységet érzékelnek.
Ezen összefonódó biztonsági mechanizmusok a SAM L11-sorozatú mikrovezérlőkön kiemelkednek a fizikai memóriavédelem síkjából, és az Arm TrustZone szeparációs technológia jóvoltából olyan további lehetőségeket biztosítanak a készülékfejlesztők számára, amelyek alapján holisztikus biztonsági rendszer építhető fel a beágyazott eszközeikben, garantálva azt, hogy ne váljanak az IoT-infrastruktúra gyenge láncszemévé.
