Microchip Technology Inc
Avtor: Nicolas Demoulin
2020_285_20
Zakon, ki ga je konec septembra 2018 sprejel kalifornijski senat, predstavlja enega od poskusov vlad po vsem svetu, da se spopadejo s problemom varnosti v povezanih napravah. Zakon je dober pokazatelj dejstva, kako se družba počasi spoprijema z dejansko grožnjo široko razpredenega hekerskega in kibernetskega kriminala. Vendar se je potrebno zavedati, da sprejemanje kakršnihkoli zakonov, kot je ta, ne bo odpravilo temeljne težave v zvezi z varnostjo.
Hekerski napadi postajajo vse bolj izpopolnjeni in pogosto zasnovani tako, da izkoriščajo več naprav hkrati, zato jih je mogoče uporabiti kot dostopne točke pri napadih distribuiranega zavračanja storitve (DDoS) ali jih zaposliti v obsežnih robotskih omrežjih (botnet) za izvajanje različnih operacij kibernetskega kriminala. Priložnost hekerjem za avtomatizacijo napadov, s katerimi jim uspe namestiti več kopij iste naprave, je pogosto posledica slabe varnostne arhitekture in šibke zaščite varnostnih poverilnic.
Zelo pogost razlog, da hekerji najdejo lahko ranljive sisteme je, da so si razvojniki izdelkov bolj prizadevali za njihovo lažjo namestitev kot za doseganje sprejemljive varnosti. Šibka gesla – včasih tako preprosta, kot so na primer štiri zaporedne ničle, so preproste bližnjice, ki uporabnikom olajšajo začetno namestitev.
Celo zapletena gesla, ki jih enaka dodelite vsem priključenim napravam, ogrožajo celotno populacijo nameščenih naprav. Ko hekerji z analizo ene same enote odkrijejo to geslo, morda tudi s pomočjo zapletenih napadov prek stranskih kanalov, lahko to isto geslo uporabijo za katero koli ciljno enoto.
Na napravah za končne uporabnike, kot so na primer domači internetni prehodi, obstaja rešitev, ki se je proizvajalci takšne opreme oklepajo in ki je sprejemljiva po kalifornijskem zakonu o zasebnosti informacij za povezane naprave, je programiranje edinstvenega gesla v napravo in posebna nalepka na sami enoti, s katero sta o tem obveščena kupec ali monter. Vendar to nikakor ni rešitev, ki bi bila primerna v dobi interneta stvari (IoT). Številne aplikacije zahtevajo tudi samodejni zagon in vključitev.
Tudi v primerih, ko je inženir za namestitve na voljo, obstajajo težave pri zasnovah z zaščito na podlagi gesla. Ne le zato, ker običajno ni nekega uporabniškega vmesnika, ki bi bil primeren za vnos gesel, ampak takšen tradicionalni pristop k varovanju IoT naprav tudi ni smiseln, izpostavljanje vidnega gesla na katerikoli napravi pa povzroči tveganje, da ga izdajo tudi nepooblaščenim osebam, ki s tem dobijo dostop do te enote. Čeprav posamezna gesla lahko znatno omejijo obseg enega samega napada, pa še vedno obstaja veliko tveganje, da se v omrežje priključenih naprav zlonamerno dostopa in se jih preprogramira, s čimer se potem lahko izkoristijo še druge slabosti. Zato je za najpreprostejše naprave potreben samodejni način nameščanja varnih poverilnic.
Ker se mora IoT naprava povezati s strežnikom, da lahko opravlja celoten nabor svojih funkcij, je najpreprostejši način ta, da se naprava poveže v omrežje s standardnim naborom poverilnic in edinstveno digitalno identifikacijsko kodo, ki se uporablja za identifikacijo vsake posamezne enote. Ko prepozna digitalno identifikacijsko kodo naprave, lahko strežnik nastavi šifriran kanal in prenese vse potrebne informacije, da se naprava prijavi na varen strežnik in sporoči svoje podatke.
Pri oblikovanju tega preprostega mehanizma pa obstaja kritična pomanjkljivost. Vse, kar mora napadalec storiti, je iskanje in poskus dostopa z neuporabljenimi, vendar veljavnimi kodami digitalnih identitet ali uporaba očitnih vzorcev na način, kot se mu zdi, da se kode ustvarijo, nato pa jih s pomočjo lastnih orodij prevara. Alternativno lahko pridobijo seznam veljavnih digitalnih identifikacijskih kod s pomočjo tehnik socialnega inženiringa ali prestrezanja v tovarni, kjer se naprave programirajo in jih uporabljajo za dostop do omrežja. Z dostopom do brezžičnih prehodov lahko hekerji prestrežejo komunikacijo z napadi človeka v sredini. Z uporabo svojih zlonamernih naprav po zagonu lahko napadalci poskušajo vdreti v druge dele omrežja ali prekinejo delovanje njihove osnovne storitve.
Potrebna je neka oblika za zanesljive identifikacije naprav z uporabo poverilnic, ki jih ni mogoče pridobiti z drugimi sredstvi. To je mogoče doseči le z uporabo ustreznih varnostnih praks in z upoštevanjem celotne dobavne verige.
Prva težava je že pri ugotavljanju, ali je naprava IoT zakonita. To je atribut, ki ga je mogoče doseči s ključi, bodisi da se uporabimo na tehnologijo javnih ključev (PKI) ali digitalno potrdilo, ki vsebujeta javni ključ ali preprost par javnih / zasebnih ključev brez vključitve certifikata. Pod PKI ima vsaka naprava edinstven zasebni ključ, ki je matematično povezan z znanim dobrim digitalnim potrdilom, ki ga proizvajalec varuje. Ta zasebni ključ se uporablja za podpis izzivov, ki enolično prepoznajo napravo na katerem koli strežniku, ki ima dostop do ustreznega javnega ključa. Javni ključ je javno viden niz informacij in zato ne predstavlja tveganja, tudi če ta ključ dobijo v roke nepooblaščeni uporabniki.
Digitalna potrdila je mogoče upravljati s standardnimi protokoli, kot je X.509. V skladu s tem standardom se vsa digitalna potrdila prek hierarhije podrejenih certifikatov sklicujejo na izvirno potrdilo proizvajalca opreme. Stranka lahko prek imena izdajatelja na podlagi vsakega podrejenega potrdila pridobi javni ključ potrdila navzgor po hierarhiji, s čimer lahko preveri, ali je podpis podrejenega potrdila zakonit.
Tristopenjska hierarhija digitalnih potrdil je najprimernejša izbira za številne IoT aplikacije. V tem primeru je certifikat proizvajalca izdelka shranjen pri njem. Vsaka posamezna stranka bi nato uporabila certifikat na ravni naročnika, ki izhaja iz tega potrdila, za ustvarjanje potrdil na ravni naprave. Ko vsaka naprava dobi svoj certifikat, je mogoče preveriti podatke, ki jih vsebuje, s čimer se prepriča, da je to resnični podrejeni certifikat originalnega proizvajalčevega certifikata.
X.509 zagotavlja mehanizem, s katerim je mogoče prepoznati naprave kot zakonite. Poleg tega ni vezan na sisteme s preprostim besedilom, kot so na primer serijske številke. Vendar pa to samo po sebi ni dovolj, da bi zagotovili, da certifikati na ravni naprave in ustrezni zasebni ključ ne bi bili ogroženi na kateri od točk dobavne verige. V mnogih scenarijih dobavne verige je treba podatke potrdil programirati v vsako napravo med ali po montaži na ploščico tiskanega vezja.
Proizvajalec lahko uporabi serijski programator za programiranje v vezju za nalaganje potrdil in z njimi povezanih zasebnih ključev v ROM pomnilnik na vsaki enoti na proizvodni liniji. Uporabnik bi lahko uporabil dostop prek zunanjih serijskih vrat za nalaganje praznih naprav z ustreznimi ključi in certifikati, ko prevzame blago. Toda s temi pristopi obstaja velika nevarnost, da lahko do zasebnih ključev dostopate z omrežnim hekerskim socialnim inženiringom.
Nadaljnje vprašanje je prestrezanje po prodaji. Heker s fizičnim ali omrežnim dostopom bi kasneje lahko izvlekel zasebne ključe ali poškodoval napravo, če ROM pomnilnik ni zaščiten. Ključna zahteva za zagotovitev, da se to ne bi bilo mogoče, je uporaba strojno uveljavljenega korena zaupanja. Koren zaupanja zagotavlja, da ni znanega mehanizma, po katerem bi lahko zasebni ključi ali druge kritične poverilnice uhajali prek vgrajenega sistema. To vključuje tako zaščito pred posegi, zaščito pred stranskimi kanali ter podporo za preverjanje programske opreme.
Varen zagon zagotavlja, da lahko IoT naprava poganja samo pooblaščeno kodo. Vsak poskus izvajanja programske kode, ki bi jo naloži heker in ki lahko deluje zlonamerno, je blokiran že na ravni strojne opreme. Naprava se lahko med zagonom zažene samo iz blokov programske kode, ki jih razgradijo in podpišejo z zasebnim ključem, ki je last OEM-ja. Če naprava naleti na napačno podpisan blok kode, preneha z nalaganjem zlonamerne programske kode in se poskusi vrniti v stanje s tovarniško sprogramirano programsko kodo, če pa tega ne more, se deaktivira.
Preverjanje ugnezdene programske opreme je prav tako bistveno za omogočanje posodobitev ugnezdene programske opreme (FOTA) v IoT napravah, ne da bi pri tem tvegali, da bodo ogrožene. Digitalno podpisane posodobitve je mogoče preveriti na podoben način kot zagonsko kodo za pristnost, preden se posodobi. Ko bo koda shranjena v notranjosti, mora opraviti podobne preizkuse varnega zagona, kot vgrajena programska oprema, ki jo nadomešča.
Eden izmed pristopov k izvajanju postopkov varnega zagona in shranjevanja ključev je vključitev vseh potrebnih blokov v sam mikrokontroler. Vendar takšnih varnih mikrokontrolerjev ni na voljo v številnih različicah, ki bi jih načrtovalci ugnezdenih sistemov imeli na voljo za izbiro, kar lahko poveča stroške sistema. Prilagodljiva alternativa je uporaba namenskega varnega elementa, kot je ATECC608a. Ta čip ponuja kombinacijo ključnih pomnilniških in kriptografskih pospeševalnih funkcij, ki so lahko nadgradnja kakršnihkoli mikrokontrolerjev in mikroprocesorjev. Ko mora mikrokontroler naložiti zagonsko programsko kodo iz programskega pomnilnika ROM, zahteva preverjanje iz javnega ključa, ki ga resnično ne more nihče spreminjati in ki ga hrani ATECC608a.
Komplementarno se komunikacija z oddaljenim strežnikom lahko vzpostavi s protokoli PKI, ki iz shranjenega zasebnega ključa pridobivajo efemeralne ključe, ki so potrebni za TLS seje. Zasebni ključ sam nikoli ne zapusti ATECC608a, ustvarjen pa je znotraj samega čipa v varnih tovarnah podjetja Microchip, opremljenih s strojno varnimi moduli (HSM). Poleg tega varni element uporablja različne mehanizme za zaščito ključev pred razkritjem tudi v primeru fizičnih napadov, kot je fizično odstranjevanje plasti. Aktivni kovinski ščit nad matrico bo na primer deaktiviral funkcije čipa, če napadalec poseže v ščit pri fizičnem sondiranju naprave. Ukrepi pred znanimi napadi prek stranskih kanalov, na primer napadi z napetostnimi konicami in diferencialna analiza porabe, preprečujejo pridobivanje ključnih podatkov z uporabo nekaterih orodij za vdor z metodo penetracije, ki so na trgu zlahka dostopna.
V nasprotju s številnimi proizvodnimi postopki načrtovanja in izdelave ATECC608a, pa poseben izziv predstavlja celotna dobavna veriga, s katerim se soočajo razvijalci IoT naprav, poleg tega pa tudi logistična zapletenost distribucije ključev. Namesto da bi bil dobavljen prazen za poznejše programiranje, se varni element pošlje iz Microchipovih varnih proizvodnih obratov kupcu ali proizvajalcu pogodb že z nameščenimi s ključi in potrebnimi certifikati. To zagotavlja, da ključi niso nikoli razkriti ali izpostavljeni tretjim osebam, kar znatno zmanjša tveganje za razkritje.
Končna točka v dobavni verigi je namestitev in preverjanje. Naprava mora biti prepričana, da se pri zagonu povezuje z zakonito storitvijo v oblaku in ni izpostavljena napadu z vmesnim prisluškovanjem, ki bi ga lahko uporabili za razkrivanje skrivnosti, ki jih zbira sama naprava. Naprava lahko z uporabo PKI interakcij zagotavlja, da se pogovarja s pooblaščenim strežnikom.
Da bi strežniku zagotovil potrdilo ali javni ključ, podjetje Microchip kupcu pošlje ustrezna potrdila podpisnika ali javne ključe, ki jih generira jih z uporabo HSM nastavitve pred odpremo. Stranka se lahko odloči, da bo ta potrdila in javne ključe uporabila neposredno na svojem lokalnem strežniku ali jih usmerila na drugega ponudnika storitev v oblaku, kot sta Amazon Web Services (AWS) in Google CloudPlatform, ki bo upravljal verigo zaupanja, ki vsaki veljavni napravi zagotavlja, da se neposredno pogovarja s pooblaščenim strežnikom. Ko so potrebne povezave vzpostavljene, naprava IoT postane polnopravni član omrežja z edinstveno, zaupanja vredno, zaščiteno in upravljano identiteto, ki podatke varno prenaša s šifriranimi protokoli, kot je na primer TLS.
Čeprav digitalna potrdila in PKI omogočajo dostop do številnih spletnih storitev, so lahko stroški na najpreprostejših senzorskih vozliščih kar precejšnji. Ponudniki storitev v oblaku so razvili mehanizme, ki izkoriščajo PKI infrastrukturo, ne da bi pri vsaki končni napravi zahtevali uporabo celotnih certifikatov X.509. Google Cloud, na primer, v sodelovanju z Microchipom lahko prinese prednosti zagotavljanja varnega delovanja tudi najpreprostejših IoT naprav. Dovoljenje za jedro Google Cloud IoT ne zahteva izdelave popolnih digitalnih potrdil. Namesto tega uporablja enostavnejše ‘JSON spletne žetone’ (JWT), ki so ustvarjeni na podlagi zasebnega ključa znotraj ATECC608a.
Ko se naprava prvič poveže z omrežjem, dostopa do Googla Cloud v mqtt.google.com. Običajno gre za prijavo na podlagi gesla. Vendar Google Cloud namesto gesla sprejme tudi spletni žeton JSON (JWT) in te podatke uporabi za odobritev nove naprave in povezovanje s svojim digitalnim dvojčkom v oblaku. Preprost protokol omogoča izvajanje tudi na preprostih 8-bitnih mikrokontrolerjih, ne da bi s tem na kakršen koli način ogrozili varnost. Tesno partnerstvo Microchipa in Googla zagotavlja celovito varno upravljanje poverilnic naprav.
S storitvami, kot je Googlova platform v oblaku, uporabniki ATECC608a varno dostopajo do storitev v oblaku, praktično iz kateregakoli kraja na svetu in brez potrebe po postavljanju zasebnih strežnikov in na varen način. Model celovite dobavne verige, ki ga Microchip ponuja za delo s storitvami v oblakih, kot sta Google in AWS, pomeni, da razvijalcem IoT naprav tudi ni potrebno implementirati lastnih tehnologij za njihovo zagotavljanje, s čimer bi seveda tvegali možnost napak, ki bi hekerjem omogočale dostop do njihovih virov podatkov. Rezultat je celostni pristop k varnosti povezanih naprav, ki je pripravljen za IoT sedanjosti in prihodnosti.
Opomba: Ime in logotip Microchip sta registrirani blagovni znamki podjetja Microchip Technology Incorporated v ZDA in drugih državah. Vse druge blagovne znamke, ki so morda tu omenjene, so last njihovih podjetij.
