A kódmanipulációk, hackelések egyre kifinomultabb eszközökkel és módszerekkel történnek, és gyakorta egyszerre egynél több eszközre terjednek ki, amelyeket hozzáférési pontként felhasználva valósítanak meg elosztott, szolgáltatásmegtagadással járó (DDoS – Distributed Denial of Service) támadásokat. Ugyanígy előfordulhat, hogy ezeket a hálózati csomópontokat „besorozzák” nagy méretű botnetekbe, amelyek kiváló eszközei a kiberbűnözési cselekményeknek. A hackerek ügyesen képesek támadások automatizált kivitelezésének megtervezésére és végrehajtására is, amelyek többnyire a gyenge védelmi architektúra és elégtelen biztonsági tanúsítványkezelés eredményei.
Nagyon sokszor azért bizonyulnak a hackerek számára igen sebezhetőnek bizonyos rendszerek, mert azok tervezése során az egyszerű telepítést helyezték előtérbe, szemben a biztonságos üzemeltethetőséggel. A kezdeti telepítést például nagyon megkönnyíti a jelszóként beállított, 4 db nulla számjegy használata, azonban biztonsági szempontból ez katasztrofális lehet: még a bonyolultabb, ámde több eszközön felhasznált jelszók is komoly biztonsági kockázatot rejtenek nemcsak egy, hanem egy egész sornyi telepített eszközre nézve. Ha a hacker megoldotta egyetlen eszköz esetében a jelszó visszafejtését akármilyen kifinomult vagy nyers erőn alapuló eszközök használatával, ugyanazon jelszóval további eszközöket is megtámadhat a hálózaton.
Bizonyos végfelhasználói eszközök (pl. otthoni hálózati átjárók) esetében a gyártók esetenként azt a megoldást választják (amelyet egyébként például a kaliforniai információvédelmi törvény is elfogad), hogy az egyedi jelszót nyomtatott címkén feltüntetik a telepített végberendezésen. Ez alapvetően nem teljesen téves elképzelés, azonban az IoT korában egy bizonyos mérték felett kivitelezhetetlen. Számos alkalmazásnál automatizált telepítés és felszerelés kerül a képbe, ami még akkor is komoly nehézségeket okoz a jelszóalapú védelem esetében, ha éppenséggel rendelkezésre áll telepítést végző szakember. Az egész jelszóalapú védelmi módszert nem csupán a betápláláshoz szükséges, megfelelő felhasználói interfész hiánya teszi gyakorlatilag használhatatlanná egy tipikus IoT eszköz esetében, de végeredményben egy fizikailag szemmel leolvasható jelszó feltüntetése bármilyen eszközön potenciális biztonsági kockázatot rejt. Jóllehet az egyedi jelszók képesek az egyedi támadások hatását limitálni, a hálózati eszközök hozzáférhetősége miatt a fennmaradó kockázat mértéke jelentős marad, lehetőséget adva az illetéktelen, ártó szándékú hozzáférésre és átprogramozásra, további sebezhetőségek kihasználása céljából. Az ideális megoldást titkosított, biztonságos tanúsítványok automatikus szétosztása jelentené az egyszerűbb eszközök között.
Mivel az IoT eszközöknek a teljes értékű működésük megvalósításához szerverhez kell csatlakozniuk, az eszköz szempontjából egy egyszerű mechanizmus a hálózati csatlakozásra egy standard tanúsítványállomány és egy egyedi, digitális azonosítást végző kód felhasználása, amely egyedi azonosítást valósít meg. Amint a hálózat felismeri az eszköz egyedi, digitális azonosítóját, a szerver képes létrehozni egy titkosított csatornát, amelyen átküldheti az eszköz számára a szerverre való bejelentkezéshez szükséges információt, megnyitva az utat az eszközön rendelkezésre álló adatok szerverre áttöltéséhez.
Ezen egyszerű mechanizmusban egy kritikus koncepcionális hiba található: a potenciális támadónak nincs más dolga, mint megtalálni egy érvényes digitális azonosítót „próba, szerencse” alapon, vagy egy nyilvánvaló kódgenerálási mintát követve, amelyet követően a hálózat saját eszközeivel garázdálkodhat, megszemélyesítve a legális, tanúsított hálózati eszközöket. További lehetőséget jelent érvényes digitális kódokat megszerezni közösségi technikák követésével vagy a gyári programozás helyszínén kódok megszerzésével, amelyekkel mind-mind nyerhető hálózati hozzáférés. Vezeték nélküli kommunikációs hálózatokról lévén szó, egy újabb megoldás az is, ha az ún. közbeékelődéses (man-in-the-middle) technikával beleállnak a két kommunikáló fél közé, belehallgatva azok társalgásába, illetve járható út a telepített hálózatba saját eszközzel belépni, meghiúsítva/megmásítva a hálózat legális eszközeinek kommunikációját vagy magát az alapszolgáltatást.
A támadási felületek száma elég terjedelmes, ezért a biztonságos üzemeltetés szempontjából leginkább arra van szükség, hogy a legális eszközöket olyan tanúsítványokkal azonosítsuk, amely tanúsítványok semmilyen el nem ismert eszközzel nem beszerezhetők. Ez csakis megfelelő biztonsági protokollok követésével érhető el, kizárólag úgy, hogy a teljes kommunikációs láncra kiterjed.
A probléma megoldásának legelső lépése a legitim IoT eszköz azonosítása. E tulajdonság kulcsok használatával azonosítható be, legyen szó nyilvános kulcsú infrastruktúrás (PKI – Public Key Infrastructre) technológiáról – kulcsot tartalmazó, digitális tanúsítványokkal megtámogatva –, vagy pedig egyszerű nyilvános/privát kulcspárról, tanúsítványok bevonása nélkül. PKI technika használata esetén minden eszköz rendelkezik egy egyedi, privát kulccsal, amely matematikailag kerül származtatásra egy ismerten, valós digitális tanúsítvány alapján, amelyet a gyártó tart titokban. E privát kulcs felhívást és lehetőséget ad azon szerverek számára az eszköz beazonosítására, amelyek hozzáféréssel rendelkeznek a megfelelő nyilvános kulcshoz. A nyilvános kulcs egy mindenki számára elérhető információhalmaz, amely akkor sem rejt biztonsági kockázatot, ha ártó szándékú egyénekhez jut el (lásd 1. ábra).
A digitális tanúsítványok kezelése standard protokollokkal (pl. X.509) is megoldható. Az X.509 alatt például minden digitális tanúsítvány egy központi OEM-tanúsítványra vonatkoztat vissza, leszármazott tanúsítványok hierarchiáján keresztül. A leszármazottak tanúsítványán minden kibocsátó nevén keresztül a kliens hozzáfér a hierarchia felsőbb lépcsőin a tanúsítványok nyilvános kulcsához, amellyel leellenőrizhető, hogy az alárendelt tanúsítvány aláírása legitim-e.
A legtöbb IoT-alkalmazáshoz egy háromszintes, digitális tanúsítványhierarchia megfelelő választás. Ebben az összeállításban az OEM-tanúsítványt a végberendezés gyártója birtokolja. Minden egyedi vásárló egy aláírószintű tanúsítvánnyal rendelkezik, amely az OEM-tanúsítványból kerül származtatásra, és amelynek alapján eszközszintű tanúsítványok kerülnek kiállításra. Amint minden egyes eszköz megkapja saját tanúsítványát, a tartalmazott információ alapján ellenőrizhető (visszakövethető), hogy valóban az eredeti OEM-tanúsítványból származnak-e.
Az X.509-ben rendelkezésre áll egy olyan mechanizmus, amellyel ellenőrizhető az eszközök legitimként való azonosítása, amely ráadásul mentes a szövegalapú rendszerek (pl. sorozatszámok) gyengeségeitől. Ám ez még mindig nem elég annak biztosítására, hogy a közbenső vagy eszközszintű tanúsítványok és a hozzájuk tartozó privát kulcsok teljes elérhetetlenségben legyenek illetéktelenek számára a komplett lánc valamely pontján. Számos kommunikációs láncban a tanúsítványadatokat minden egyes eszközbe be kell programozni az áramköri hordozószintű összeszerelésben vagy után. A gyártók ezeket a tanúsítványokat és privát kulcsokat beprogramozhatják soros flash-programozással is egy nemfelejtő memóriaterületre, gyártósori összeszerelés közben. Alternatív módon, vevőhöz való kiszállítást követően egy kívülről hozzáférhető, soros porton keresztül maga a felhasználó is feltöltheti az üres eszközöket a megfelelő kulcsokkal és tanúsítványokkal, ám mindkét esetben fennáll a veszélye annak, hogy a privát kulcsok hálózati támadás folytán illetéktelen kezekbe kerülhetnek. Ezen túlmenően problémát jelent az eladást követően elkövetett, illetéktelen hozzáférés is, hiszen egy felkészült hacker fizikai vagy hálózati támadással a privát kulcsokat a későbbiekben is kinyerheti és az eszközt meghamisíthatja/megszemélyesítheti, amennyiben a nemfelejtő memória nem rendelkezik megfelelő védelemmel.
A felsorolt hibák és sebezhetőségek komoly veszélyeket rejtenek, megfelelő csillapításuk érdekében hardverszintű alapbiztonságot kell kialakítani, amely azt garantálja, hogy nem létezik olyan ismert mechanizmus, amellyel a privát kulcsok vagy biztonsági szempontból hasonlóképpen fontos tanúsítványelemek a beágyazott rendszerből bárhogyan is kiszivárogtathatók legyenek. Ez védelmet nyújt az illetéktelen babrálás, megkerülő támadások ellen, és megoldást ad firmware-validációra.
A biztonságos bootolás lehetővé teszi, hogy az IoT eszköz csak tanúsított programkódot futtathasson, és bármely, hacker által feltöltött és futtatásra kijelölt, ártalmas programkód végrehajtása hardverszinten tiltott. Normálműködés során az eszközök csak az OEM által birtokolt privát kulccsal aláírt és hashelt kódblokkokról bootolhat, és amennyiben az eszközt aláírás nélküli blokkról történő bootolásra utasítanák, a meghamisított szoftver futtatását megtagadja, kísérletet tesz a gyári alapprogramozott állapot helyreállítására, illetve letiltja saját magát, amennyiben erre is képtelen.
Az IoT eszközök kockázatmentes, vezeték nélküli firmware-frissítésének (FOTA – Firmware-Over-The-Air) alapja a firmware validációs képessége. A digitális aláírással ellátott frissítőcsomagokat a bootoláshoz használt kódhoz hasonlóan hitelesíti a rendszer, mielőtt a konkrét feltöltést a firmware-memóriába megkezdené. Amint feltöltésre került, a betárolt programkód tehát hasonló hitelesítőfolyamatokon megy keresztül, mielőtt az aktuális firmware-t kiváltaná (lásd 2. ábra).
A biztonságos bootolás és kulcstárolás gyakorlati kivitelezésének egyik lehetősége, hogy az összes szükséges adatblokkot egy mikrokontrollerben tárolják el. A gondot az jelentheti, hogy a megfelelően biztonságos mikrovezérlők nem elérhetők olyan választékban, ahogy azt a tervezők elvárhatnák, így drágíthatják a rendszereket, ezzel szemben egy skálázhatóbb alternatívát jelent olyan titkosított egységek használata, mint az ATECC608a titkosított elem. Az ATECC608a lényegében egy kriptográfiai gyorsító és titkosított kulcstároló kombinációját valósítja meg, amely bármely processzorhoz vagy mikrovezérlőhöz illeszthető. Ha a mikrovezérlőnek a bootmemóriából kell kódot betöltenie, a mikrovezérlő az ATECC608a-ban tárolt, totálisan érinthetetlen nyilvános kulcs alapján kér ellenőrzést (lásd 3. ábra).
Ennek kiegészítéseképpen egy távoli kiszolgálóval kommunikáció kezdeményezhető a PKI-alapú protokollokal, amelyek ideiglenes kulcsokat származtatnak TLS titkosított programfolyamatokhoz a letárolt privát kulcs alapján. A privát kulcs önmaga sosem kerül ki az ATECC608a-ból, mivel az eszközön belül, az eszköz által születik meg, a Microchip titkosított, hardverbiztonsági modulokkal felszerelt alkatrészgyáraiban. Ráadásul az ATECC608a egy sor olyan mechanizmust ismer és követ, amelyekkel a tárolt kulcsokat fizikai behatolás ellen is védi, akár az alkatrésztok megbontása esetén is. Például a chipet védő, aktív fémpajzs inaktiválja magát a chipet abban az esetben, ha a támadó fizikailag kontaktál a pajzzsal, és megkísérli a fizikai behatolást az alkatrészre. Az ismert megkerülő támadásokkal kivitelezett kulcslopások ellen hatásos védelmet élvez az eszköz könnyen hozzáférhető, nyilvános behatolástesztelési megoldások alkalmazásával.
Számos gyártási eljárással szemben az ATECC608a fejlesztése és gyártása során figyelembe vették a teljes ellátási/kommunikációs lánc problematikáját az IoT-alkalmazásokat illetően, a kulcsok kérdésének vonatkozásában. Ahelyett, hogy későbbi programozás céljából üres memóriával szállítanák ki az alkatrészeket, a Microchip hardveresen titkosított gyáraiból a vevőhöz vagy szerződéses elektronikai gyártóhoz a szükséges kulcsokkal és tanúsítványokkal a fedélzetén érkeznek ki az eszközök. Ez tökéletesen biztosítja, hogy a kulcsok sosem kerüljenek felfedésre bármilyen harmadik fél előtt, minimalizálva a nyilvánosságra kerülésük esélyét.
A lánc utolsó eleme a helyszíni telepítés. Az eszközt működésbe lépéskor biztosítani kell afelől, hogy egy legitim felhőhálózatba készülnek integrálni, és nem pedig egy közbeékelődéses támadás áldozatává készülnek tenni, titkainak felfedésére kényszerítve. PKI-alapú interakciók segítségével biztosítható, hogy az eszköz egy tanúsított szerverhez beszél.
Annak érdekében, hogy a szerver el legyen látva tanúsítvánnyal vagy nyilvános kulccsal, a Microchip elküldi a vevőnek a megfelelő aláírótanúsítványokat vagy nyilvános kulcsokat, amelyeket a gyári hardverbiztonsági modulok segítségével állítanak elő az alkatrész kiszállítását megelőzően. Az ügyfél döntheti el, hogy ezeket a tanúsítványokat és nyilvános kulcsokat saját szerverén kívánja-e tárolni, vagy „ráengedményezi” őket egy harmadik felhőszolgáltató félre, mint például az Amazon Web Services-re (AWS) vagy Google Cloud Platformra, amelyek kiváló támogatást nyújtanak annak biztosítására, hogy az eszközök ellenőrizhető módon egy tanúsított szerverrel kommunikáljanak. Ha a kezdeti kommunikációs beállítások megtörténtek, az IoT-csomópont a hálózat teljes értékű tagja lesz egy egyedi, megbízható, védett és menedzselt identitással és képességgel a kiszolgáló felé történő, TLS-en keresztüli, biztonságos kommunikációra.
Noha a digitális tanúsítványok és a PKI-alapú kommunikáció számos webalapú szolgáltatáshoz nyújt hozzáférést, az egyszerű szenzorelemek tekintetében ez jelentős felesleges többletterhelést jelenthet. A felhőszolgáltatók ezért olyan megoldást fejlesztettek ki, amely kihasználja a PKI-alapú infrastruktúra előnyeit anélkül, hogy a teljes X.509 tanúsítványkezelést minden egyes eszközön teljes mértékben implementálni kellene. (Például a Microchippel kooperációban dolgozó Google Cloud képes olyan szolgáltatást nyújtani, amely még a legkisebb IoT-csomópont esetében is biztonságos telepítést és üzemeltetést jelent. A Google Cloud-féle IoT központi hitelesítéshez nincs szükség teljes értékű, digitális tanúsítványok létrehozására, ehelyett a sokkal egyszerűbb JSON webtokeneket (JWT – JSON Web Token) használják fel a célra, amelyeket az ATECC608a-ban tárolt privát kulcs segítségével hoznak létre.)
Amikor az eszköz először csatlakozik a hálózatra, egy hozzáféréssel kezdi a Google Cloud szolgáltatáshoz az mqtt.google.com webcímen. Ez kezdetben egy hagyományos, jelszóalapú bejelentkezést jelent, amely helyett a Google Cloud szolgáltatás JSON webtokent is elfogad. Ezen adat birtokában a szolgáltatás egyrészt hitelesíti az új eszközt, másrészt pedig hozzátársítja a felhőben a digitális ikertestvérét. Az egyszerű protokoll egyszerű, 8 bites mikrokontrollereken is támogatja az implementációt anélkül, hogy a biztonságot bármilyen tekintetben és mértékben korlátozná vagy rontaná. A Microchip és Google közötti szoros együttműködés eredményeképpen végpontok közötti, biztonságos tanúsítványkezelés valósítható meg.
Az ATECC608a felhasználói a Google Cloud Platform és hasonló szolgáltatások segítségével gyakorlatilag a világon bárhonnan, tetszőleges helyről, saját szerver nélkül is optimális biztonsággal férhetnek hozzá a felhőalapú szolgáltatásokhoz. A Microchip által kínált, végpontok közötti szolgáltatási modell ideális esetében az AWS-sel, Google Clouddal vagy hasonló szolgáltatással kerül párosításra, amely az IoT-fejlesztőket még a saját telepítési és üzemeltetési technológiák fejlesztése alól is mentesíti, természetesen az illetéktelen hozzáférés ellen irányuló, megnyugtató védelem mellett. Mindezek eredménye egy olyan holisztikus megoldás, amely a jelen és a jövő IoT-alkalmazásainak biztonsági és üzemeltetési igényeit is kielégíti.
