A „kommunikáló” járművek biztonsága
A járműbiztonság erősödő kihívása: kapcsolt járművek, növekvő fedélzeti adatforgalom
Elképesztő arra gondolni, hogy egy korszerű autó ma már akár 100, egymással és a külvilággal intenzíven kommunikáló, a biztonságunkért és a kényelmünkért dolgozó mikroprocesszort is tartalmazhat. Ez a komplexitás a pozitív tulajdonságok mellett jelentős biztonsági kockázatokat is hordoz. Rendkívül átgondolt tervezésre van szükség a támadható felület minimálisra csökkentéséhez.
Ha elmondom valakinek, hogy a félvezető-iparágban dolgozom, és azon belül is a járműbiztonság a szakterületem, a beszélgető partnerem jellemzően gépkocsiriasztókra és más lopásgátlókra gondol. Ám miközben a gépkocsilopások megelőzése továbbra is lényeges szempont, ezeknél jelentősen nagyobb biztonsági fenyegetéseket hordoznak a jármű belső elektronikus vezérlőegységei (Electronic Control Unit – ECU) és a köztük zajló adatforgalom a jármű belsejében éppúgy, mint a külvilág felé. A jelenleg évente eladott új járművek nagyjából 50%-a már „csatlakoztatott” (kommunikáló) járműnek tekinthető, és ez az arány 2030-ra várhatóan 95%-ra emelkedik. Azok az adatátviteli útvonalak, amelyek olyan kommunikációs szabványok útján valósulnak meg, mint a Bluetooth®, az USB, az LTE, az 5G vagy a Wi-Fi®, egyfelől jelentős használati kényelmet nyújtanak a felhasználónak, másfelől azonban hatalmas ütemben növekvő támadási felületet is kínálnak az illetéktelen és/vagy rosszindulatú beavatkozásokkal foglalkozó támadók számára. Elég egy gyors Google-keresés a járműhekkelés témakörében, és máris számtalan találatot böngészhetünk az olyan valóságos biztonsági hiányosságokról, amelyek költséges visszahívásoknak, pereknek és valamely márkával szembeni komoly bizalomvesztésnek váltak okozóivá. Tény, hogy a szoftverek hajlamosak hibákat tartalmazni, a hekkerek pedig hajlamosak kihasználni ezeket a hibákat. Számos dolgot tehetünk a hibák számának csökkentésére és – ha már tudunk róluk – azok kijavítására, de amíg az emberek új programkódokat írnak, addig új hibák „beépítésére” is van lehetőség.
A járműfedélzeti hálózatok követelményei szerint kidolgozott Controller Area Network (CAN-busz) feletti ellenőrzés megszerzése a hekkerek rendszeres célja. Mutattak már példát olyan hekkelésre, amely a Bluetooth kommunikációban rejlő sebezhetőségen keresztül használt ki egy, az operációs rendszerben található programhibát, amely által végül is távoli hozzáféréssel lehetett manipulálni a CAN-buszon küldött üzeneteket. A modern járművekben akár 100 ECU is található, amelyek biztonságkritikus kommunikációt folytatnak az adathálózaton.
A CAN-busznak van néhány előnye. Egyszerű protokollt használ, nem túl költséges, rendkívül robusztus és viszonylagosan védett az elektromágneses zavarok ellen. Mindez megbízható lehetőséget kínál arra, hogy rajta keresztül biztonsági szempontból kritikus fontosságú hálózati csomópontok kommunikáljanak egymással. Hátránya ugyanakkor, hogy évtizedek óta megoldatlan a protokoll biztonsága, amely azt jelenti, hogy ha egy hekker megszerezte az irányítást a rendszer felett, megtévesztő üzeneteket küldhet, amellyel befolyásolhatja a járműfedélzeti kommunikációt. Néhány példa ezekre: az ablaktörlő beindítása vagy leállítása, a világítás kikapcsolása, a vezető figyelmének elvonása a hangrendszer befolyásolásával, hamis, zavaró hibaüzenetek generálása, helytelen sebességérték megjelenítése, az ülések mozgatása, vagy akár a jármű levezetése az útról. A jó hír az, hogy a CAN-busz továbbfejlesztéseként megjelent a CAN FD, amely az üzenet hasznos részében többletbájtoknak ad helyet, amelyeket kihasználva a biztonság fokozható: alkalmasak például üzenethitelesítő kód (Message Authentication Code – MAC) beépítésére, amely kriptográfiai módszerekkel ellenőrzi az üzenet hitelességét, kiszűrve ezzel a megtévesztő üzeneteket. Kétféle MAC-módszer közül választhatunk: az egyik a hash-alapú HMAC, a másik az AES szimmetrikus kulcsú blokk-kódolásra épülő CMAC. Jelenleg a CMAC az esetek túlnyomó többségében használt megoldás.
Az eredeti berendezéseket gyártó vállalatoknak (OEM-eknek) folyamatosan naprakészen kell tartaniuk a kiberbiztonsági specifikációikat, hogy megakadályozzák az újra és újra napfényre kerülő hekkelések révén ismertté váló sebezhetőségek kihasználását. Alkalmilag majdnem minden OEM rákényszerül, hogy frissítse biztonságkritikus ECU-inak programkódját, sőt, néhány esetben akár az összes ECU kódjának frissítése is szükségessé válhat. Az alapvető biztonsági blokknak rendelkeznie kell a biztonságos rendszerbetöltés (secure boot) képességével, amely kriptográfiai ellenőrzést hajt végre arra nézve, hogy a hosztprocesszoron futó rendszerbetöltő és alkalmazási kód érvényes, változatlan és hiteles állapotban van bekapcsoláskor, újraindításkor, továbbá megfelelő gyakorisággal ismétlődik a rendszerbetöltés után. A legfontosabb követelmények listáján rögtön ez után következik a biztonságos firmware-frissítés támogatása. Szoftverfrissítéskor minden szoftver ki van téve a veszélynek, hogy újabb hibák kerüljenek a rendszerbe, ezért gyakran szükséges olyan firmware-hibajavításokat készíteni, amelyek a „terepen”, az üzemeltetési környezetben is alkalmazhatók. Ezek a firmware-frissítések kriptográfiai biztonsági megoldásokat is igényelnek, amelyek általában megkövetelik, hogy a bejövő firmware kódot szimmetrikus (AES) kulccsal titkosítsák, és egy aszimmetrikus privát kulccsal aláírják, leggyakrabban az elliptikus görbealapú titkosítás (Elliptic Curve Cryptography – ECC) használatával. Ily módon, amikor egy frissített memóriakép (image) megjelenik a gazdagép vezérlőjében, addig nem történik semmilyen művelet, amíg az új memóriakép aláírását a vezérlőbe ágyazott nyilvános ECC-kulccsal nem ellenőrizték. Az aláírás ellenőrzése után az image visszakódolható, és a vezérlő firmware-ét hibajavítási képességgel vagy funkcióbővítéssel is el lehet látni. A harmadik kiegészítés a biztonsági evolúcióban az üzenethitelesítés a fent leírtak szerint.
A járművek világában az elektromos hajtásúak különös sajátossága az akkumulátorok hitelesítésének egyre fokozódó igénye. A legtöbb akkumulátorcsomagban a nagyobb energiatároló egységek cserélhető cellamodulokból állnak össze, ezért amikor egy modul meghibásodik, az önállóan cserélhető anélkül, hogy az egész akkumulátorcsomagot kellene cserélni, vagy az elégtelen teljesítményt nyújtó akkumulátorcsomaggal alaposabban foglalkozni kellene. A rosszul tervezett modulok biztonsági kockázatot jelentenek a jármű tűzbiztonságának veszélyeztetése révén, tehát az OEM-ek számára fontos a jármű ökoszisztéma-kezelésének megerősítése, ami azt jelenti, hogy minden egyes modult titkosított hitelesítő adatokkal kell ellátni, amely igazolja, hogy az OEM az akkumulátormodul gyártóját ellenőrizte, és az általa gyártott terméket megfelelőnek fogadta el, mielőtt az felhasználásra kerül egy akkumulátorcsomagban. Ha egy modul tüzet ugyan nem okoz, de a teljesítőképessége elmarad az elvárttól, az ronthatja az OEM márka jó hírnevét, amely negatív sajtóvisszhangot és végső soron bevételcsökkenést is ereményezhet. Ez tehát egy újabb jó ok arra, hogy a gyártó kriptográfiailag hitelesítse az akkumulátormodul eredetét. De mit is jelent egy modul eredetének kriptográfiai hitelesítése? Ez megvalósítható azzal, hogy vevőspecifikus aláírási kulcsot hozunk létre, amit arra használunk, hogy beépítsük azt az X.509 tanúsítványláncba, amivel eszközszintű tanúsítványokat lehet előállítani egy egyedi ECC-kulcspár segítségével. Az ilyen szinten dokumentált eszköz bármelyik akkumulátorcsomagba beépíthető. Amikor egy modult cserélünk egy akkumulátorcsomagban, az akkumulátorkezelő rendszer (Battery Management System – BMS, amelyet „akkumulátor gateway” néven is szokás említeni) lekérdezi a modul egyedi X.509-tanúsítványát, és visszaköveti azt a digitális aláírásláncon keresztül egészen annak megbízható kibocsátójáig.
Az aláírás ellenőrzése után a kezelőrendszer egy kihívást intéz a modulhoz, hogy az digitális aláírással lássa el a modult anélkül, hogy a saját privát kulcsát továbbítaná a buszon, vagy néhány esetben vezetékmentes RF csatornán. A folyamat modulszinten itt véget is ér. A BMS belsejében azonban az OEM gyakran ennél bonyolultabb használati esetet ír elő. Mivel a BMS/Gateway játsza a kommunikációs csatlakozópont szerepét a külvilág felé, hogy rajta keresztül továbbítsa a szokásos jelentést a felhőbe az akkumulátormodul egészségi állapotáról. A biztonsági használati eset kiegészül a biztonságos programbetöltés, a biztonságos programfrissítés és a szállítási réteg biztonságáért felelős Transport Layer Security (TLS) funkcióival annak érdekében, hogy biztonságos kommunikációs csatornát létesítsen a felhő felé.
A fentiekben említett biztonsági alrendszerek mindegyike biztonságos kulcstárolást feltételez, amelyet csak valódi, hardveralapú biztonsági eszközrendszerrel lehet megvalósítani. A szokásos mikrovezérlőkből, de még azoknak a mikrokontrollereknek is a nagy részéből, amelyet „biztonságosnak” neveznek, könnyű a kulcsokat megszerezni olyan szokványos feltörési technikákkal, mint a kulcs kiolvasása mikroszondákkal (micro-probing), hibaállapotba kényszerítéssel, az elektromágneses szórás megfigyelésével, ciklikus hő- és tápellátási terheléssel és időzítési támadással, hogy csak néhányat említsünk. Ezért különösen fontos, hogy megfelelő eszközt válasszunk a titkosítás nehéz feladatának ellátásához, amely védett az említett támadási lehetőségek ellen.
A piacon a kimondottan biztonsági célú eszközök számos különféle architektúrája érhető el, számos egyedi néven. Ilyen a Hardware Security Module (HSM) mind integrált kivitelben, mind pedig „külső biztonsági elem” formájában, továbbá „biztonsági tároló alrendszer” (Secure Storage Subsystem), „kulcstároló” (key vault) vagy „okoskártya” megnevezéssel, és így tovább. Ezeknek az eszközöknek roncsolásos fizikai beavatkozás elleni védelemmel (tamper protection) is rendelkezniük kell, hogy védettek legyenek az előbbiekben említett, a biztonsági kulcs megszerzésére irányuló támadási módszerekkel szemben.
A Microchip TA100 biztonsági elem
De hogyan tud egy OEM vagy egy első szintű (Tier 1) beszállító meggyőződni arról, hogy az általa megvalósított biztonsági intézkedések elég hatásosak-e? Hogy a biztonsági elemek szállítói bizonyíthassák termékeik biztonsági alkalmasságát, a legjobb, ha átadják az eszközt egy harmadik félnek a sebezhetőség felmérése céljából. A harmadik felet megbízható, akkreditált források közül kell kiválasztani, mint például az Észak-Amerikában elismert National Institute of Technology (NIST), a németországi Szövetségi Információbiztonsági Hivatal (BSI) vagy a világszerte elismert Senior Officials Group Information Systems Security (SOGIS). Az utóbbi akkreditált laboratóriumai egy globálisan elismert egyesített sebezhetőségértékelési pontrendszert (Joint Interpretation Library – JIL) használnak, amely „fehér doboz” értékelést feltételez. Ez azt jelenti, hogy a beküldő IC-gyártónak minden publikus vagy akár illegálisan megszerezhető információt át kell adnia, amelyhez egy kódtörő egyáltalán hozzájuthat; köztük az eszköz tervezésére vonatkozó laboratóriumi dokumentációt (adatfolyam, alrendszer, memóriatérkép-definíció), hardver és firmware indítási sorrendet, a biztonsági védelmi mechanizmusok leírását, a teljes adatlapot, a biztonsági és rendszerbetöltő útmutató dokumentációt, minden elérhető kódot (futásidejű könyvtárak C-szinten, kriptokönyvtár, firmware), az implementált algoritmusokat, a programozási szkripteket, a kommunikációs protokollokat, a csip elrendezését és a forráskódot. A független labor ezután áttekinti az összes dokumentációt, és feltérképezi a beküldött mintaeszközök elleni lehetséges támadási tervet. A pontozási rendszer az alapján osztja ki a pontokat, hogy mennyi ideig tart egy titkos kulcs kinyerése, a szükséges szakértelem szintje (a „friss diplomától” a több szakértőből álló munkacsoportig), az értékelés céljának ismerete (Target of Evaluation – TOE), hány minta szükséges a TOE eléréséhez, melyek a sikeres támadás végrehajtásához szükséges eszközök, a feltörő berendezések bonyolultsága és költsége, valamint a mintákhoz való könnyű hozzáférés biztosítása. Az eredményül kapott JIL-pontszámok az „értéktelen” minősítéssel kezdődnek, majd következik az alapszintű (Basic), az emelt alapszintű (Enhanced Basic), a közepes (Moderate) és végül a magas (High), amely a legjobb elérhető pontszám. Bármelyik, a High-nél alacsonyabb fokú JIL-minősítés azt jelenti, hogy a labor képes volt privát kulcso(ka)t kinyerni az eszközből. Az olyan eszközök, mint a Microchip CryptoAutomotiveTM TrustAnchor100 (TA100) külső HSM, amelyek JIL High minősítést kaptak, több mint három hónapon át képesek ellenállni a támadásoknak. Ekkor a laboratórium gyakorlatilag nem támadhatónak („Not practical”) minősíti az eszközt.
Kérdéses, hogy a biztonsági elemet a mikrovezérlőbe integrálva vagy attól függetlenül előnyösebb-e megvalósítani. Az olyan egyedi megoldások, mint a 32 bites kétmagos MCU-k, költséges frissítést jelenthetnek az előző generációs ECU-hoz képest, amelyet szabványos MCU-val is tökéletesen meg lehetett valósítani, mielőtt az OEM-ek számára kötelezővé tették a valódi biztonságot. A 32 bites processzorokra való áttérés jelentős késedelmet is okozhat a piacképes termék létrehozásában, mivel az alkalmazáskódot teljesen újra kell tervezni. A biztonsági kód fejlesztése házon belül rendkívül kockázatos, harmadik félnek kiszervezni pedig túlságosan költséges. A Tier 1 beszállítók számára is nehéz a megoldást többféle ECU-típusra kiterjeszteni, az egyes típusok eltérő teljesítménye és perifériás követelményei következtében. Ez az a helyzet, ahol a külső HMS-ek vagy kívülről csatlakoztatott biztonsági elemek jelentősen csökkenthetik a Tier 1 beszállítók biztonsági továbbfejlesztési terheit. Hozzáadott elemként társíthatók egy szabványos MCU-val egy meglévő megoldásba, vagy beépíthetők minden új termékbe, akkor is, ha eltérő hoszt-MCU-környezetre épülnek. A külső HSM-ek – mint például a TA100 – minden szükségeset tartalmazó megoldáscsomagok, beleértve az összes biztonsági kódot, kulcsot és tanúsítványt, amivel jelentősen csökkenthető a piacképes végtermék előállításához szükséges idő. Könnyen hordozható bármely MCU-ra, mivel a kapcsolódó kriptokönyvtár MCU-független. Csökken a kockázat, a piacra jutás ideje és az összköltség, így az 1. szintű beszállítók előtt jól járható út nyílik ahhoz, hogy versenytársaikat megelőzve üzleteket nyerjenek, és egy teljesen újratervezett úton haladjanak végig.
Napjaink csatlakoztatott autóinak és a járművön belüli erős hálózati kommunikációs forgalomnak is köszönhető, hogy az autóbiztonság iránti igény ma már messze túlmutat az autóriasztókon. Mivel a biztonság és a márka hírneve forog kockán, minden eddiginél fontosabb olyan, valóban biztonságos eszközöket választani, amelyeket harmadik felek ellenőriztek az ECU-kkal való bővítés során, hogy megfeleljenek az új OEM kiberbiztonsági specifikációk sokaságának, a SAE és az ISO-szabványoknak és a regionális kormányzatok biztonsági előírásainak.
Szerző: Todd Slack, Üzletfejlesztés | Stratégia és Termékmarketing |
Automotive és kereskedelmi biztonsági IC-k – Microchip Technology, Inc.
www.microchip.com
