I slutet av september 2018 antog den kaliforniska senaten en lag som är ett exempel på de försök som gjorts av myndigheter över hela världen att hantera säkerhetsproblem i uppkopplade enheter. Lagen ger en indikation på att samhället sakta börjar inse realiteten med omfattande hackande och cyberkriminalitet. Men krafttag av detta slag kommer inte att angripa kärnproblemet. Nicolas Demoulin, Microchip Technology’s Secure Products Group, tittar här på vad som kan krävas.

Hackningarna blir alltmer sofistikerade, och de utnyttjar ofta ett stort antal enheter samtidigt för att kunna användas som accesspunkter för DDoS-attacker (Distributed Denial of Services) eller kopplas samman till stora ”botnets” som används för att utföra andra cyberkriminella operationer. Att hackarna får möjlighet att utföra automatiska attacker som angriper flera kopior av en och samma enhet är ofta en följd av dåliga säkerhetsarkitekturer och svagt skydd av säkerhetsreferenser.

Mycket ofta är orsaken till att hackarna upptäcker att systemen är så sårbara att produktutvecklarna har låtit enkel installation gå före att försöka att uppnå en acceptabel säkerhet. Svaga lösenord – ibland så enkla som fyra nollor i rad – gör det ju enkelt för användarna att komma igång med installationen.

Även mycket komplexa lösenord kan, om de används på flera olika enheter, äventyra samtliga installerade enheter. När hackarna väl har dekrypterat lösenordet genom att analysera en enskild enhet, kanske med hjälp av sofistikerade sidokanalsattacker, kan de använda samma lösenord på vilka målenheter som helst.

I slutanvändarprodukter som hem-gateways är en lösning som antagits av tillverkarna – och som skulle vara legalt acceptabel enligt Kaliforniens lag ”Information Privacy: Connected Devices” – att programmera in ett unikt lösenord i varje enhet och sätta en etikett på enheten för att informera kunden eller installatören härom. Men detta är inte någon lösning som passar speciellt bra i en tidsålder med företeelser som Internet of Things (IoT).

Många applikationer kräver automatisk kommissionering och provisionering. Till och med om en installationsingenjör är på plats finns det problem med lösenordsbaserade skydd. Det är inte bara det att det kanske saknas ett användargränssnitt som är lämpligt för inmatning av lösenord som gör denna traditionella metod att säkra en IoT-enhet opraktisk. Att överhuvudtaget etikettera någon enhet som helst med ett giltigt lösenord ger risken att det kan läsas av vilken obehörig person som helst som har tillgång till enheten.

Individuella lösenord kan visserligen begränsa följderna av en enstaka attack. Men det finns fortfarande en stor risk att enheterna på nätet attackeras och omprogrammeras på ett skadligt vis, och de kan sedan användas för att söka efter andra svagheter. Vad som krävs är en automatisk metod att lägga in säkerhet i de enklaste typer av enheter.

När en IoT-enhet behöver anslutas till en server för att utföra alla sina uppgifter är en enkel mekanism att använda en standardiserad uppsättning inloggningsuppgifter, kompletterade med en unik digital identitetskod som identifierar varje enskild enhet. När serven känner igen enhetens kod kan den öppna en krypterad kanal och sända över den information som krävs för att enheten skall kunna logga in på en säker server och rapportera sina data.

Det finns en kritisk svaghet i denna enkla mekanism. Allt en hackare behöver göra är att använda ”trial-and-error” för att hitta en oanvänd men giltig digital identitetskod, eller utnyttja vad som verkar vara uppenbara mönster för hur koden genereras och sedan lura systemet med dess egna verktyg.

Annars kan de skaffa en lista över giltiga koder med hjälp av sociala kontaktmetoder eller intrång i den fabrik där enheterna programmeras. Om hackarna har tillgång till en trådlös gateway kan de också fånga upp kommunikation med ”man-in-the-middle”-attacker. Med sina egna skadliga enheter på plats, som följer kommissioneringen, kan attackerarna försöka att hacka sig in i andra delar av nätverket eller störa själva kärnverksamheten.

Identifiera enheter
Vad som krävs är en tillförlitlig metod att identifiera enheter med hjälp av inloggningsinformation som inte är åtkomlig med andra metoder. Detta kan bara åstadkommas genom att använda lämpliga säkerhetsrutiner och genom att ta med hela leverantörskedjan i beräkningarna.

Det första problemet är att bestämma om en IoT-enhet är legitim. Detta kan åstadkommas med nycklar. Det kan handla om PKI-teknologi (Public Key Infrastructure) och digitala certifikat som innehåller den publika nyckeln, eller om enkla par av publika/privata nycklar som inte kräver några certifikat.

Med PKI har varje enhet en unik privat nyckel som är matematiskt relaterad till ett känt, gott certifikat som hålls hemligt av tillverkaren. Denna privata nyckel används för att identifiera enheten unikt mot vilken server som helst som har tillgång till motsvarande publika nyckel. Den publika nyckeln är helt öppen information, och den kan utan risk distribueras till icke auktoriserade användare.

Digitala certifikat kan hanteras med standardprotokoll som X.509. Enligt denna standard refererar alla digitala certifikat tillbaka till ett OEM-kärncertifikat via en hierarki av ”barn”-certifikat. Via namnet på den som ger ut varje barncertifikat kan en klient erhålla den publika nyckeln till certifikatet högre upp i hierarkin för att verifiera att signaturen hos det beroende certifikatet är legitimt.

En trestegs hierarki av digitala certifikat är ett lämpligt val för många IoT-applikationer. Här är det tillverkaren av slutprodukten som innehar OEM-certifikatet. Varje individuell kund använder sedan ett certifikat på ”signer”-nivå, utvunnet ur detta OEM-certifikat, för att generera certifikat på enhetsnivå. När varje enhet har sitt eget certifikat kan den information som detta innehåller kontrolleras för att garantera att det är äkta.

X.509 ger oss en mekanism som gör det möjligt att avgöra om olika enheter är legitima. Den har inte de brister som textbaserade system, t.ex. serienummer, har. Men den räcker inte för att ensam kunna garantera att certifikat på mellan- eller enhetsnivå och tillhörande privata nycklar inte kan angripas vid någon punkt i kedjan.

I många fall måste certifikatet programmeras in i varje enhet under eller efter kretskortsmonteringen. Tillverkaren kanske använder en seriell flash-programmerare för att ladda in certifikaten och tillhörande privata nycklar i ickeflyktigt minne i varje enskild enhet på tillverkningslinan. En kund kanske använder en externt åtkomlig serieport för att ladda in nycklar och certifikat i tomma enheter när dessa skall levereras.

Men i båda dessa fall finns det stora risker att privata nycklar kan fångas upp med hjälp av nätverksbaserade hackningar eller ”social ingenjörskonst”. Ett annat problem är intrång efter leveransen. En hackare med access direkt eller över ett nätverk kan kanske extrahera privata nycklar senare, eller förvanska enheten om det ickeflyktiga minnet inte är skyddat.

Ett mycket viktigt krav för att kunna minska risken för sådana fel är att använda en hårdvaruförstärkt ”root of trust”. En sådan garanterar att det inte finns någon känd mekanism som gör att privata nycklar eller annan inloggningsinformation kan läckas ut av systemet. Här ingår skydd mot direkt intrång, skydd mot attacker mot sidokanaler samt stöd för firmware-validering.

En säker uppstart garanterar att IoT-enheterna bara kan köra auktoriserad kod. Varje försök att köra kod som laddats in av en hackare och som kan vara skadlig blockeras på hårdvarunivå. Under drift kan enheten bara starta upp från kodblock som är ”hash”-skyddade och signerade med en privat nyckel som ägs av tillverkaren. Om enheten träffar på ett kodblock som är felaktigt signerat slutar den att ladda in den komprometterade mjukvaran och försöker att återgå till ett tillstånd som programmerats in vid tillverkningen. Om detta inte är möjligt avaktiveras enheten.

Firmware-validering är också nödvändig för att göra det möjligt att göra FOTA-uppdateringar (Firmware Over The Air), utan risk att dessa äventyras. Digitalt signerade uppdateringar kan kontrolleras på liknande sätt som uppstartskod innan uppdateringen påbörjas. När den nya koden väl är på plats måste den genomgå liknande säkerhetstester som den gamla koden genomgått.

Ett sätt att göra uppstarter och nyckellagring säkrare är att lägga in alla nödvändiga block i en MCU. Men sådana säkra MCU:er finns inte i alla de många varianter som tillverkarna önskar, vilket kan öka systemkostnaderna. Ett skalbart alternativ är att använda ett dedicerat säkerhetselement som ATECC608a. Denna krets har en kombination av funktioner för nyckellagring och kryptografisk acceleration som kan komplettera alla slags MCU:er och processorer. När MCU:n behöver ladda in kod från bootRAM kräver den verifiering från den helt oföränderliga publika nyckeln som finns i ATECC608a.

På ett kompletterande vis kan kommunikation med en fjärrserver initieras med hjälp av PKI-protokoll som hämtar de kortlivade nycklar som krävs för TLS-sessioner från den lagrade privata nyckeln. Denna nyckel lämnar aldrig ATECC608a. Den genereras inuti kretsen, och av kretsen, i Microchips säkra fabriker som har försetts med HSM (Hardware Secure Modules).

Dessutom använder säkerhetselementen ett antal olika mekanismer som skyddar nycklarna, t.o.m. vid fysiska attacker som direkt våld mot kapseln. Det finns t.ex. en aktiv metallsköld över chippet som avaktiverar dettas funktioner vid angrepp. Motåtgärder mot kända sidoattackskanaler som glitching-attacker och differentiell effektanalys skyddar nyckeldata från åtkomst vid användning av enkelt tillgängliga verktyg för penetrationstest.

Till skillnad från många andra tillverkningsprocesser har man vid konstruktionen och tillverkningen av ATECC608a tagit med i beräkningen de problem med leverantörskedjan som IoT-utvecklarna ställs inför, liksom den logistiska komplexiteten vid distribution av nycklar. Istället för att leverera tomma kretsar för senare programmering levererar Microchip säkerhetselementet från sina säkra anläggningar till kunden eller kontraktstillverkaren med nycklar och nödvändiga certifikat redan installerade. Detta garanterar att nycklarna aldrig avslöjas eller blottas för tredje part, vilket avsevärt minimerar riskerna.

Installation
Den sista länken i leverantörskedjan är installation och provisionering. Enheten måste vara säker på att den ansluts till en legitim tjänst i molnet vid uppstarten, och inte luras av någon ”man-in-the-middle”-attack som kan tänkas användas för att komma åt de hemligheter som enheten samlat in. Enheten kan försäkra sig om att den talar med en auktoriserad server med hjälp av PKI-procedurer.

För att förse servern med certifikat och publika nycklar sänder Microchip matchande signeringscertifikat och -nycklar till kunden. Dessa genereras med hjälp av HSM-setup före leverans. Kunden kan välja att använda dem direkt på sin egen lokala server, eller utnyttja någon tredjepartsleverantör av molntjänster, som Amazon Web Services (AWS) eller Google Cloud Platform, för att hantera allt som krävs för att garantera att alla valida enheter talar med en auktoriserad server direkt. När de nödvändiga förbindelserna har upprättats blir IoT-enheten en fullvärdig medlem av nätverket, med en unik, betrodd, skyddad och hanterad identitet, och som överför data säkert via krypterade protokoll som TLS.

Även om digitala certifikat och PKI ger tillgång till ett stort antal olika webbtjänster kan mängden overhead även på de enklaste sensornoder vara betydande. Molnleverantörerna har utvecklat mekanismer som utnyttjar PKI-infrastrukturen utan att kräva att fullständiga X.509-certifikat används på varje slutenhet. Google Cloud kan t.ex. i samarbete med Microchip ge fördelarna av säker provisionering och operation t.o.m. till de enklaste IoT-enheter. Google Cloud IoT-kärnauktorisering kräver inte att några kompletta digitala certifikat skapas. Istället används enklare ”JSON web tokens” (JWT) som genereras baserade på den privata nyckel som finns i ATECC608a.

När en enhet först ansluts till nätverket anropar den Google Cloud på mqqt.google.com. Detta är en lösenordsskyddad inloggning. Men Google Cloud accepterar även ett JWT istället för lösenordet, och använder dessa data för att både auktorisera en ny enhet och associera den med sin digitala tvilling i molnet. Det enkla protokollet går att använda med enkla 8-bits MCU:er utan att säkerheten äventyras på något vis. Det nära samarbetet mellan Microchip och Google garanterar att enheternas inloggningsuppgifter hanteras säkert över hela kedjan.

Genom tjänster som Google Cloud Platform kan användare av ATECC608a få säker tillgång till molntjänster från nästan vilken plats som helst i världen, utan att behöva äga några säkra privata servrar. Den end-to-end-modell som Microchip erbjuder för molntjänster som Google och AWS gör att IoT-utvecklarna inte heller behöver implementera egna teknologier för provisionering – med risk att göra misstag som ger hackare tillgång till deras kärndata. Resultat har blivit en holistisk ansats till säkerhet hos uppkopplade enheter som är helt klar för dagens och framtidens IoT.

(Klicka för större bild)

Nicolas Demoulin, EMEA Marketing Manager. Microchip Technology’s Secure Products Group

Filed under: Embedded