Rugalmas, robusztus és megbízható IoT-biztonsági rendszerek tervezése

A „dolgok internete” megjelenésével korábban elképzelhetetlen ütemben növekszik az internetre kapcsolódó eszközök száma. Ezeknek éppen ezért kell egyszerűeknek és olcsóknak lenniük. Azonban az egyszerűség és a korlátozott rendeltetés sokszor „elaltatja az éberséget”, és ezzel kaput nyit a rosszindulatú támadások előtt. A szerző fontos szempontokra hívja fel a biztonságos IoT iránt érdeklődő olvasó figyelmét.

A „dolgok internetére” (IoT) csatlakozó beágyazott rendszerek tervezése eltérő megközelítéseket kíván attól, amit a klasszikus beágyazott rendszereknél megszoktunk. Az eltérés oka az, hogy az előbbiek az internetre csatlakoznak.  
Ugyanakkor még egy kis képességű beágyazott rendszertől is elvárjuk, hogy lépést tudjon tartani az informatika (IT) és az információs biztonság (InfoSec) világának gyors változásaival, miközben olyan egyszerű rajta egy rendszerfrissítést végrehajtani, mint egy PC-n, és olyan biztonságos, mint egy álladóan felügyelt adatközpont. Igen, ez nehéz feladat, de megfelelő rendszertervezési megközelítéssel megvalósítható.
Egy IoT-célra szánt IoT-rendszernél alapvetően fontos megvizsgálni, hogyan kapcsolódik a készülék a teljes rendszerhez. Ez úgy kivitelezhető, hogy modellezzük az eszközt várhatóan érő fenyegetéseket és kockázatelemzést végzünk a teljesítőképességének meghatározása, valamint azoknak a jellemzőknek a felismerése érdekében, amelyekre az eszköznek képesnek kell lennie. Akár vezetéken, akár vezetékmentesen csatlakozzék is a hálózatra, az eszköz 1-től 20 évig terjedő kalkulált üzemideje során valószínűsíthető az informatikai támadás előfordulása. Annak érdekében, hogy ennek ellenállhasson, a biztonságot elsődleges tervezési szempontként kell tekintetbe venni, amelynek az is része, hogy bármilyen szoftverkarbantartást és rendszerfrissítést is biztonságosan el kell tudni végezni.
Ez azt jelenti, hogy már a tervezési folyamat kezdetén létfontosságú átgondolni, hogyan kapcsolódik majd a készülék az internetre, milyen lesz a rendszer architektúrája, hogyan fogja majd kezelni a működés közben történő eseményeket, és minden lehetséges interakciót a magasabb szintű rendszerrel.
Mivel egy IoT-eszköz iránti igények többféle forrásból is megfogalmazódhatnak – IT, marketing, tervező és értékesítő csapat, felsőbb vezetési szint, pénzügyi és jogi ügykezelés – világosan meg kell határozni és megérteni az eszközzel szemben támasztott igényeket, elvárásokat, a készülék árát és szállítási-értékesítési körülményeit. Azon problémák közé, amelyeket szükséges figyelembe venni, a termék szabványoknak való megfelelése, a termékfelelősség, az adatok gyűjtése, tárolása és felhasználása éppúgy oda tartozik, mint az adatkezeléssel vagy az adatok integritásának megőrzésével kapcsolatos problémák megoldása.
Ezenkívül meg kell határozni az üzleti modellt, az eszköz használatával járó hosszú távú költségeket egy felhőalapú rendszernél, továbbá azokat az előnyöket, amelyeket ez az eszköz a felhasználónak kínál, és végül: hogyan történik az eszköz tervezése és karbantartása a hosszú távú használat során, mivel azokat ezek a kezdetben meghozott döntések jelentősen befolyásolják.
A helyzet még bonyolultabbá vált az olyan – aránylag újkeletű – jogi szabályozások következtében, mint az Általános Adatvédelmi Szabályozás (General Data Protection Regulation, amely GDPR néven került a köztudatba). Segítő szándékú útmutatók érhetők el például az Egyesült Királyság kormányzatának Secure by Design (Tervezés a biztonság szem előtt tartásával) szervezetétől, az Európai Unió Agency for Network and Information Security (ENISA, az EU hálózati és informatikai biztonsági ügynöksége) és az IoT Security Foundation (IoT biztonsági alapítvány) gondozásában.
A könnyű használat és a fokozott biztonság követelményei gyakran ellentmondó tervezési szempontokat jelentenek, például a bonyolult jelszavak és készülékregisztrálási eljárások következtében. Ez azt jelenti, hogy a készüléket kezdettől fogva úgy kell tervezni, hogy egyidejűleg tegyen eleget a biztonság és az egyszerűség követelményének.
Ha megvizsgálunk egy kommunikáló, beágyazott terméket, négy kulcsfontosságú hardverelemet fedezhetünk fel benne:

• Feldolgozás

• Memória

• Kommunikáció

• Biztonsági hardverelemek

1. ábra  Egy IoT-megoldás kulcselemei

Ezenkívül pedig van egy mindig jelenlevő és mindig fontos ötödik elem: a szoftver. (1. ábra)
Ezek a központi elemek általában minden rendszerben előfordulnak. Tervezői döntés kérdése viszont, hogy hogyan vannak ezek az elemek megvalósítva egy konkrét termékben, tervezési elgondolásban, a kockázat, a költség, a fejlesztési lehetőségek, a biztonság és a karbantarthatóság szempontjainak figyelembevételével.
A tervezési cél egy olyan rendszer megvalósítása, amely robusztus, megbízható, rugalmas, hibaállapotából helyreállítható, biztonságos, hiteles, skálázható, karbantartható, gyártható és használható. Fenn kell tartania a márkanév elismertségét, és olyan költségmodellt kell követnie, amely összhangban van azokkal a követelményekkel, amelyekkel a készüléknek szembe kell néznie. Tudomásul kell venni, hogy egy kommunikációra képes berendezés tervezési, fejlesztési és gyártási költségei magasabbak egy egyedülálló, rendszerfrissítésre alkalmatlan, klasszikus beágyazott rendszeréinél. Ha viszont a tervezés megfelelően történt, a termék értéke olyan hosszú időtávon érvényesül, ami messze meghaladja a magasabb tervezési és anyagköltség hátrányait. Pénzügyi értelemben tehát helyesebb az IoT-eszközt eleve jól tervezni, mint későbbre halasztani a problémák megoldását, amikor majd azok felmerülnek.

A bizalom gyökere

A biztonságos rendszer megkövetel egy megbízható módszert a titkos információk tárolására és az érvényességük hitelesítésére, mégpedig úgy, hogy a titkos információhoz soha ne lehessen hozzáférni. Ez a „bizalom horgonya” általában egy biztonságos hardverelem formájában valósul meg. Ezek az eszközök többféle fizikai módszert kínálnak az ismert hardveres támadások megelőzésére, miközben olyan funkciókat is hozzáadnak, mint a NIST SP 800 minőségű véletlenszám-generátorok (RNG) és olyan kriptográfiai algoritmusok, mint például a FIPS-kompatibilis „Elliptikus Görbe Digitális Aláírás” algoritmus (ECDSA-P256).

Egy biztonsági elem képes a biztonságot az alábbi szolgáltatásokkal támogatni:

• A készülék autentikációja (hozzáférési jogosultság-ellenőrzés) egy felhőalapú szolgáltatáshoz alaposan tesztelt és érthető működésű nyilvános kulcsú infrastruktúra (Public Key Infrastructure – PKI) -módszerekkel. Ez lehetővé teszi az eszközök előzetes regisztrációját már a gyártás folyamán, készülékenként egyedi biztonsági tanúsítványokkal, és képes olyan QR-kódot generálni, amely a végtermék minden példányához hozzá tudja rendelni a saját egyedi tanúsítványát. A felhasználó a beszerzés során ugyanezt a QR-kódot csatolja egy biztonságos háttérrendszer segítségével a végtermék vásárlójának biztonsági fiókjához, amely ezzel egy egyszerű, biztonságos beszerzési folyamatot alkot az érvényes biztonsági előírások követelményeit teljesítve.

• A Microchip Technology nemrég vezette be a szakma első, előtelepített biztonságikulcs-megoldását, amely már 10 db-os minimális rendelési mennyiség esetén is elérhető, segítve ezzel a fejlesztőket abban, hogy tetszőleges méretű projekteket valósíthassanak meg az automatikus, felhőalapú jogosultságellenőrzés felhasználásával. A Trust Platform néven ismert rendszer háromlépcsős eljárással teszi lehetővé a biztonsági elemek raktárról történő szállítását előtelepített, előkonfigurált, vagy éppen a felhasználó által szabadon konfigurálható elemekkel, olyan kivitelben, amely közvetlenül autentikálható bármilyen nyilvános vagy zárt felhőszolgáltatáshoz vagy akár a LoRaWAN™ hálózathoz.

• Az adatok hitelességének ellenőrzése. A „bizalom horgonya” segítségével lehetséges azt is megvizsgálni, hogy egy mérés eredménye biztosan csak az előre meghatározott készülékből származik, és az eredményt nem manipulálták. Ez segíthet az adatokban észlelhető valódi anomáliák felismerésében is a felhőben tárolt adatok feldolgozása során, mivel nagyléptékű fizikai beavatkozást nehéz előidézni.

• Biztonságos rendszerbetöltés, amely a biztonsági elemben tárolt titkos kulcs segítségével lehetővé teszi a hoszt CPU- titkosítási „aláírásának” megváltozását, mielőtt a tárolt firmware-frissítési képfájl futtatását lehetővé tenné. Ezenkívül további futásidejű integritás-ellenőrzés is végrehajtható, például a Class B Safety Libraries biztonsági könyvtár elemeinek felhasználásával.

• Secure Firmware Upgrade Over the Air (FUOTA – biztonságos firmware-frissítés), amelyben a biztonsági elemben tárolt titkos kulcs segítségével ellenőrizhető a firmware-frissítés forrásának integritása, továbbá, hogy a képfájl digitális aláírása érvényes-e – és mindezt azt megelőzően, hogy az újonnan letöltött frissítő képfájl futtatásra kerülne.

• Klónozás elleni védelem. Ha a gyártásirányítás megfelelően működik, a beépített biztonsági elem segítséget nyújt a szoftver lemásolásának és a hardver visszafejtésének megelőzésében.

Ám, ha van is eszközünk a titkos kulcsok tárolására minden egyes termékbe épített hardver biztonsági elem formájában, feltétlenül szükséges, hogy annak programozása biztonságos gyártási környezetben történjen. Ez problémát okozhat a termék skálázhatóságát illetően, mivel a titkos információt sok esetben meg kell osztani az alvállalkozó gyártóval. A gyártás rugalmassága és a könnyű alkatrészbeszerzés ezért csak akkor biztosítható, ha a titkos információ elhelyezése az eszköz gyártójánál, biztonságos környezetben, előreprogramozottan megy végbe, mégpedig úgy, hogy a nyilvános kulcsok átvitelét a felhasználó felhőszolgáltatásába egyszerű, automatizálható folyamat végezheti.

2. ábra  Példa egy vezetékmentes megoldásra
Sok esetben egy IoT-készülékben egynél több processzor található.
A vezetékmentes gyakran önmagában is tartalmaz egy bizonyos mennyiségű feldolgozó kapacitást, különösen a Wi-Fi^® és a Bluetooth^® kommunikáció esetén, hogy kezelje a komplex kommunikációs protokollt. A rendszer pontos architektúrája az alkalmazástól, az igényektől, a kockázatvállalás mértékétől és más tényezőktől függ

Tömegtároló

A firmware-frissítés rendszerint kábelcsatlakozással történik, amelyet közvetlenül az eszköz soros portjához kapcsolnak. Ez a megoldás jól működött sok-sok éven át, de vajon hogyan működhet ez a megközelítés kommunikációra képes eszközöknél, gyakran szinte hozzáférhetetlen helyeken, ráadásul nagy darabszámú készüléket tartalmazó IoT-rendszerben?
Még abban az esetben is, ha egy IoT-végpontnál olyan probléma merül fel, aminek a megoldásához – a szokásos szoftverkarbantartási ciklusidő lejárta előtt – szoftverfrissítést kell végrehajtani, a fizikai beavatkozást célszerű elkerülni. Az alternatív megoldás a FUOTA szoftverfrissítési eljárás – ideális esetben ennek garantáltan biztonságos változata – alkalmazása. Mivel ez egy közvetlen fizikai beavatkozást nem igénylő megoldás, a rendszernek ki kell használnia azokat az előnyöket az integritást garantálva, amelyeket a biztonsági elem kínál az ismeretlen vagy nem hiteles forrásból származó, rosszindulatú kódok befogadásának megelőzésére.
De hogyan is lehet egy ilyen rendszerfrissítést végrehajtani? Ideális esetben a biztonságos FUOTA frissítéseit kell végrehajtani, a hoszt MCU működését érintetlenül hagyva. Ha viszont a frissítést közvetlenül a rendszer flash programmemóriájába töltjük be, az előző, működő változat biztonságos helyi mentése nélkül, a rettegett „téglásodás” forgatókönyvét kockáztatjuk, amelyben helyreállíthatatlan hiba keletkezik a rendszerfrissítés közben.
A FUOTA-módszernek az adatátviteli közegtől függetlenül kell működnie. Ez azt jelenti, hogy képesnek kell lennie ugyanazt az eljárást végrehajtani akár a sávszélesség korlátozottsága, akár a hosszú válaszidő, akár a jelkimaradások és jelvesztések esetén, bármilyen fizikai átviteli közeg használata közben. Ezen a módon ugyanaz a szerveroldali háttérszolgáltatás, ugyanaz a végpontoldali letöltési, tárolási és integritásellenőrzési eljárás használható a legkülönbözőbb adatátviteli eljárások esetén is.
Elkerülhetetlen természetesen, hogy van némi változatosság a „minden szituációra érvényes közös” megoldások között egy teljes rendszer megvalósításakor, de ha törekszünk arra, hogy ne távolodjunk el szükségtelenül a szabványos megoldásoktól, a módszerek moduláris megvalósítása segít abban, hogy a programkód hosszú időn át karbantartható maradjon.

Tápellátás

Ha az eszközöket földrajzilag elszórtan, „globálisan” helyezi ki a felhasználó, és bármennyire is igyekszik ellenőrzött környezetet biztosítani a végpontok csoportjai számára, nehéz áttekinteni minden egyes készülék energiaellátottsági és környezeti állapotát. Ennek ellenére elvárjuk, hogy a rendszer végpontjai ugyanúgy működjenek, mint a tesztfázisban a laboratórium körülményei között tették, és továbbra is garantáltan ideális működési feltételek közt tarthassuk azokat. Mi van azonban, ha ez nem sikerül? Mi van például, ha az eszközök egy csoportjának működését egy elektrosztatikus kisülés (Electrostatic Discharge – ESD) jelensége zavarja meg, míg az más eszközöket nem érint? A tápegységünk tervezésénél ugyancsak figyelembe kell venni a „mi van, ha” típusú forgatókönyvek lehetséges kimeneteleit, ha a rugalmasság és a hibatűrés problémáira általános stratégiát akarunk kidolgozni.

Ha ez sohasem történik meg és a rendszerünket sosem próbálják megtámadni…

Legyünk hálásak a jósorsunknak. Lehet, hogy a gondos tervezés és a megelőzésre építő megközelítés teszi a kihívást túlságosan nehézzé ahhoz, hogy az esetleges rendszertámadó inkább máshol próbálkozzon, de lehet, hogy egyszerűen csak szerencsénk van.
Nincs tökéletes biztonság, és ez kihívást jelent a jövőre nézve. De megtehetjük, hogy a legjobb ma ismert eljárásokat és lehetőségeket alkalmazzuk, és úgy tervezünk, hogy legyen elegendő mozgásterünk a jövőben felmerülő kockázatok mérsékléséhez. Ha a rendszerünket úgy terveztük, hogy abban helye legyen a „bizalom gyökerét“ kínáló hardvereszközöknek, és a szoftver biztonságosan frissíthető legyen, és végül eléggé rugalmas felhőoldali megoldásokat alkalmaztunk ahhoz, hogy a rendszerünk kezelni tudja a problémák többségét – akkor ezeket az elvárásokat szem előtt tartva végeztük a tervezést.
Javasoljuk, hogy az IoT Security Foundation, a Gov.UK Secure by Design, az UL2900, az ISA 62443 és az ISA Secure és mások által elérhető technikák segítségével közelítse meg a tervezést. Hagyjon elegendő tartalék programmemória-helyet az elkerülhetetlen kódméret-növekedés számára.
Tervezzen a legrosszabb esetre, majd tegyen észszerű kompromisszumokat ahelyett, hogy egyedül a költségre tekintettel végezné a tervezést a „mi lenne, ha” forgatókönyveket figyelmen kívül hagyva. Az IoT-eszközök hatalmas potenciális támadási felületet jelentenek a hekkerek, a rossz szándékú szereplők számára – beleértve még azokat az „okos” embereket is, akik csak egy kicsit játszadozni akarnak.
Azoknak az okoknak, amiért a rendszerünket támadják, nem kell, hogy „értelmük” legyen – az emberek, anyagi javak, termelőüzemek, márkák és vállalatok elleni támadás által okozott kár ettől függetlenül jelentős lehet.
Ne feledje: azt mondani, hogy „ez velem nem történhet meg”, nem jó védekezés akkor, ha már megtörtént.

Szerző: Ian Pearson, alkalmazástechnikai főmérnök – vezetékmentes, felhő- és IoT-rendszerek, Microchip Technology

www.microchip.com

még több Microchip