IoT-toepassingen beveiligen

Voorgeprogrammeerd op de hardware

Met de komst van het Internet der Dingen is de bedreiging van het cybersecurity landschap gigantisch toegenomen over alle marktsegmenten. Beveiliging tegen dergelijke aanvallen is dan ook van essentieel belang. Dit kan met behulp van wachtwoorden, maar nog beter is beveiliging die diep in de hardware van de microcontroller zelf is vastgelegd.

Aanvallen kunnen serieuze gevolgen hebben voor IoT-apparaten. Hun werking kan daardoor verstoord raken of erger nog, door nieuwe firmware kunnen ze zelfs een onderdeel gaan vormen van bijvoorbeeld een botnet voor het uitvoeren van diverse kwaadwillende acties. Bij veel IoT-apparaten wordt het binnendringen slechts beperkt door software-legitimatie, zoals wachtwoorden. Deze kunnen op verschillende manieren in handen vallen van hackers en vormen daarmee niet echt een gedegen beveiliging. Beveiliging in hardware, gekoppeld aan beveiligde identiteit, voorziet in een mechanisme dat veel veiliger is.

Diep in de hardware
Deze in de hardware vastgelegde beveiliging bestaande uit een geldige identiteit en toegangscodes voor het apparaat, kan alleen worden vastgelegd tijdens het fabricageproces door het inzetten van public key infrastructure (PKI) mechanismen. Bij PKI heeft elk apparaat een unieke persoonlijke sleutel die wiskundig is afgeleid van een betrouwbaar digitaal certificaat dat geheim wordt gehouden door de fabrikant. Deze persoonlijke sleutel wordt gebruikt voor het ondertekenen van een oproep om een apparaat als uniek te identificeren voor elke server die toegang heeft tot de bijbehorende publieke sleutel. De publieke sleutel is een publiekelijk zichtbare set van informatie en het levert geen risico op als die sleutel door niet gemachtigde gebruikers wordt verspreid. In de context van een IoT-apparaat wordt de identiteit van het apparaat bepaald door het gebruik van een persoonlijke sleutel. De verwante publieke sleutel wordt gebruikt in protocollen die vaststellen dat de geclaimde identiteit geldig is. Deze identiteit kan tijdens de hele levensduur van het apparaat worden gebruikt voor het verifiëren van firmware updates die van toepassing zijn alsook voor de identiteit van het apparaat bij de toegang tot diensten op afstand.

Als spil in elk willekeurig cryptosysteem mogen de componenten waarin de persoonlijke sleutels van het apparaat zijn opgeslagen niet kwetsbaar zijn voor fysieke aanvallen of uitlezen/overschrijven op afstand. In het ideale geval worden de geheime sleutels ondergebracht in een beveiligd element dat een geïsoleerde, beveiligde begrenzing vormt zodat de sleutels nooit kunnen worden ontmaskerd. Dit is geen eenvoudige opgave. Het ontwerp vereist vervalsingsbestendigheid en beveiliging tegen afluisteringsaanvallen, zoals zijkanaal analyse. Het adequaat beveiligen van de sleutel op deze manier vereist diepgaande kennis op beveiligingsgebied. Ook zal het ontwerpen van de IoT-toepassing meer tijd in beslag nemen.
Deze verantwoordelijkheid kan echter niet worden genegeerd, omdat het beveiligen van de sleutel van vitaal belang is voor het implementeren van een dichtgetimmerde beveiliging. Gelukkig zijn er voor fabrikanten beveiligingselementen, zoals de ATECC608 van Microchip, beschikbaar met de gewenste beveiligingsniveaus (zie afbeelding 1).
Alhoewel dergelijke componenten bestaan, blijven er problemen rond het gebruik van hardware-afgedwongen identiteitsbeheer. De noodzaak om de beveiligde identiteit op een zodanige manier toe te passen dat deze niet kan worden omzeild door een goed uitgeruste aanvaller bleek voor de meeste fabrikanten, systeemintegratoren en dienstverleners niet gemakkelijk te realiseren. De conventionele benadering is om een beveiligingselement in hardware te configureren tijdens de fabricage met de geschikte persoonlijke sleutels. Echter, om logistieke redenen bij de toeleveringsketen wordt deze benadering in het algemeen voorbehouden aan grote series. Het programmeren van elke component met een eigen beveiligde identiteit maakt het fabricageproces klantspecifiek: een kostbare aangelegenheid, mits dit proces kan worden afgezet tegen een grote serie, zodat de kosten per component nauwelijks worden beïnvloed.
Het is nu echter mogelijk om de gewenste beveiligingselement-configuratie goedkoop te leveren, zelfs bij een minimum bestelaantal (MOQ) van tien stuks die vooraf worden geconfigureerd en geprogrammeerd. Met dit model, dat wordt ondersteund door het Microchip Trust Platform, kan zelfs een simpele IoT-bewakingscamera, gateway, airconditioner of overeenkomstige toepassing worden beveiligd door vooraf gegenereerde, apparaat-eigen certificaten die zijn vergrendeld binnenin een beveiligingselement voor het inwerkingstellingsproces van autonome cloud verificatie.

Inzetten van een toepassing
Omdat kleine tot middelgrote series nu kunnen beschikken over een goedkope manier om beveiligd identiteitsbeheer in hun apparaten te stoppen, is de volgende stap het configureren van het beveiligingselement op de meest geschikte manier voor de beoogde toepassingen. Dit is nodig omdat de component moet worden geprogrammeerd met de referenties en andere cryptografische assets die worden gebruikt voor het specifieke verificatiemodel. Naast de oorspronkelijke identiteit van de component kunnen er aanvullende persoonlijke sleutels en geheime codes zijn die moeten worden geïnjecteerd in het hardware element. Dat ze bijvoorbeeld niet zijn afgeleid van de hoofdsleutel, kan nodig zijn voor het verifiëren van toebehoren, periferie, inhoud van derde partijen en hosts op afstand zodat hun referenties afzonderlijk kunnen worden beheerd.
Het principe achter het beveiligingselement is dat het de toegang controleert tot vitale hulpbronnen en fungeert als een test tegen ongewenste activiteiten, zoals pogingen om de door de fabrikant goedgekeurde firmware te vervangen door een kwaadwillende code die zal proberen om de geheime informatie die de component bevat te gebruiken om verdere aanvallen uit te voeren.
Een hoofdvoorwaarde om te garanderen dat aanvallers niet kunnen binnendringen om een component te herprogrammeren is het toepassen van een beveiligde opstartstrategie die, op zijn beurt, is beschermd door een beveiligingselement. Beveiligd opstarten garandeert dat het IoT-apparaat uitsluitend gemachtigde codes kan draaien. Onder beveiligde opstartcondities kan het apparaat uitsluitend codeblokken laden die zijn verknipt en ondertekend met een persoonlijke sleutel die in eigendom is bij de fabrikant.
Wanneer de microcontroller codes wil laden van de opstart-ROM, vraagt de microcontroller eerst om verificatie van de echt onveranderlijke publieke sleutel die wordt beheerd door het beveiligingselement. Alleen als die verificatie lukt, zal de MCU proberen om de code te laden. Als het apparaat een codeblok tegenkomt dat niet correct is ondertekend, stopt het met het laden van de gesaboteerde software en poogt terug te keren naar een door de fabriek geprogrammeerde toestand of, als dat niet mogelijk is, uit te schakelen. Zo lang de MCU bootloader code niet kan worden gewijzigd, omdat deze in ROM of beveiligd flashgeheugen is ondergebracht, kan de testfunctie zelf niet worden omzeild.
Als de beveiliging van de kern op orde is, kunnen andere gebruikstoepassingen gemakkelijk worden toegevoegd, zoals de ondersteuning van op certificaten gebaseerde verificatie op servers op afstand, een hoofdingrediënt voor IoT-apparaten. Deze verificatie op afstand maakt gebruik van standaard protocollen, zoals Transport Layer Security (TLS) voor versleutelde communicatie en X.509, dat wordt gebruikt voor het beheren van digitale certificaten die aangeven dat een apparaat of dienst echt is.
Onder de X.509-standaard refereren alle digitale certificaten terug naar een oorspronkelijk OEM certificaat via een hiërarchie van kindcertificaten. De informatie die de certificaten bevat voorziet in de middelen om de rechtmatige eigenaar van elk certificaat te identificeren en van daaruit de publieke sleutel te verkrijgen van het certificaat verderop in de hiërarchie zodat de handtekening van het onderliggende certificaat geldig kan worden verklaard.
Wanneer een passend beveiligd IoT-apparaat communiceert met een server op afstand, gebruikt het de informatie in de bijbehorende certificaten om aan te geven dat het om een geldige gebruiker van de dienst gaat. Aan de andere kant gebruikt de server zijn eigen set van certificaten om het apparaat mee te delen dat hij ook echt is. Zo lang het apparaat over de vereiste certificaten beschikt, is verificatie in beide richtingen gegarandeerd.
In de context van het IoT kunnen digitale certificaten worden gebruikt voor het vereenvoudigen van het inwerkstellingsproces van apparaten wanneer ze voor de eerste keer worden ingeschakeld en proberen om contact te maken met hun service provider over het internet. Dit wordt bereikt door het doorsturen van de noodzakelijke certificaten naar de servers wanneer het beveiligingselement eerst is geprogrammeerd, alsook de opslag van de certificaten die het apparaat zal gebruiken voor de verificatie van die servers in het element naast de oorspronkelijke persoonlijke sleutel van het apparaat. Als een voorbeeld van deze benadering heeft Microchip gewerkt met functies van Amazon Web Services (AWS) om het mogelijk te maken dat elk ontwikkeld product dat het Trust Platform gebruikt hiermee in werking kan worden gesteld binnen AWS IoT-diensten. Ondersteuning voor standaard protocollen en certificatiesystemen betekent dat dezelfde technieken gemakkelijk kunnen worden ingezet met andere diensten in de cloud, zoals Microsoft Azure, alsook particuliere- en hybride-cloud infrastructuren.
Een andere hoofdtoepassing voor IoT is om via de ether (over-the-air; OTA) firmware updates naar IoT-apparaten te sturen. Deze updates voorzien in de mogelijkheid om kwetsbaarheden in de beveiliging te patchen zonder het risico dat de apparaten worden gecompromitteerd door het update proces zelf. Digitaal ondertekende updates, verzonden via OTA, kunnen op dezelfde manier worden gecontroleerd als de code die wordt getest tijdens het veilig opstarten voor verificatie voordat de update kan worden aangebracht. Eenmaal op zijn plaats moet de opgeslagen code ook nog beveiligde opstarttesten ondergaan als het apparaat herstart.
Andere gebruiksmogelijkheden zijn IP-beveiliging voor het controleren van de geldigheid van reserves en optioneel toebehoren, alsook de beveiliging van data van gebruikers, omdraaien van sleutels, en LoRaWAN-verificatie. Bepaalde fabrikanten kunnen klantspecifieke opties nodig hebben die buiten deze kerndiensten vallen. Anderen willen graag een lagere overheadbenadering qua beveiliging voor de wat simpeler IoT-apparaten. Google Cloud IoT core machtiging vraagt bijvoorbeeld niet om het creëren van de volledige digitale certificaten. Deze dienst maakt gebruik van ‘JSON web tokens’ (JWT), die zijn afgeleid van de oorspronkelijke persoonlijke sleutel die is opgeslagen binnenin de al eerder genoemde ATECC608B en die de plaats inneemt van een conventionele login via een wachtwoord.

Trust Platform
De flexibiliteit voor het verwerken van deze verschillende toepassingen met lage aanloopkosten is mogelijk gemaakt door het Microchip Trust Platform en de ondersteuning voor een aantal verschillende engagement modellen. Het eerste model biedt klanten een gemakkelijke manier om apparaten van beveiligingsreferenties te voorzien, gebruikmakend van een default flow. In dit model worden de persoonlijke sleutel van het beveiligingselement en de generieke certificaten gegenereerd tijdens de productie binnen een beveiligde fabriek van Microchip. De sleutel en certificaten blijven onzichtbaar tijdens het beveiligde programmeerproces, vastgelegd binnenin het beveiligingselement waar ze veilig blijven tijdens transport. De afgeleide publieke legitimatiebewijzen kunnen worden doorgestuurd naar inwerkstellingsdiensten in de cloud of naar een LoRaWAN network join server.
Omdat veel fabrikanten graag willen beschikken over een hoger en flexibeler verificatieniveau met de mogelijkheid om zelf certificaten aan te maken en te injecteren, gebaseerd op hun eigen verificatieketen, voorziet een tweede engagement model in een set van vooraf geconfigureerde toepassingen die de mogelijkheid bieden om deze acties automatisch uit te voeren. Nog grotere veranderingen zijn mogelijk in het derde engagement model. Bij deze benadering, zoals weergegeven in afbeelding 2, begint de klant met het bestellen van een onbeschreven beveiligingselement. Met gebruikmaking van de door Microchip geleverde tools worden de programmeerstappen doorlopen, inclusief de XML die controleert of de persoonlijke sleutels en certificaten aan het beveiligingselement in Microchip’s beveiligde fabriek worden afgeleverd.

Tot slot
Alles overziend kan worden gesteld dat dankzij de meest recente ontwikkelingen in online tools en componenten voor op hardware-gebaseerde beveiliging, bedrijven met projecten van elke willekeurige grootte nu een beveiligingselement kunnen implementeren met hun IoT-apparaten. De obstakels die het moeilijk en prijzig maakten om beveiligingselementen te configureren en programmeren zijn verwijderd. Het proces heeft uiteindelijk tot het stroomlijnen van een compleet beveiligde leveringsketen geleid, waardoor beveiligingsmodellen voor het totale IoT-ecosysteem kunnen worden geïmplementeerd.

Auteur: Xavier Bignalet, Microchip Technology