IoT-beveiligingsbeginselen - deel 3: zorgen voor veilig opstarten en firmware-updates

Noot van de redactie: Ondanks de proliferatie van IoT-apparaten blijft de beveiliging van deze apparaten een voortdurende zorg, in die mate zelfs dat beveiligingsproblemen een belemmering kunnen vormen voor de adoptie van aangesloten apparaten in industriële IoT (IIoT) en missiekritische toepassingen waar bedrijfs- en persoonlijke gegevens in gevaar kunnen worden gebracht in het geval van een succesvolle aanval. Het beveiligen van ivd-toepassingen kan ontmoedigend zijn, maar in werkelijkheid kan de beveiliging van ivd-apparaten worden gebaseerd op een paar relatief eenvoudige beginselen die worden ondersteund door hardwarebeveiligingsapparaten. Door gevestigde beveiligingspraktijken te volgen, kunnen deze problemen worden aangepakt. Deze meerdelige serie biedt praktische begeleiding om ontwikkelaars te helpen ervoor te zorgen dat vanaf het begin de beste praktijken worden gevolgd. Deel 1 bespreekt de cryptografische algoritmen die aan veilige ontwerpen ten grondslag liggen. Deel 2 bespreekt de rol van private sleutels, sleutelbeheer, en veilige opslag in veilige IoT-ontwerpen. In deel 3 wordt ingegaan op de mechanismen die zijn ingebouwd in veilige processoren om andere soorten bedreigingen voor ivd-apparaten te beperken. Deel 4 identificeert en toont hoe beveiligingsmechanismen in geavanceerde processoren kunnen worden toegepast om de isolatie te helpen waarborgen die nodig is om aanvallen op de runtime-omgeving van ivd-apparaten te beperken. In deel 5 wordt beschreven hoe de beveiliging van het ivd zich uitstrekt van ivd-apparaten tot beveiligingsmaatregelen op hoger niveau die worden gebruikt om die apparaten te verbinden met ivd-cloudbronnen

De combinatie van hardwarematige cryptografie en veilige opslag biedt essentiële mogelijkheden om veilige ontwerpen voor het internet der dingen (IoT) te implementeren. Eenmaal in gebruik, krijgen ivd-apparaten echter te maken met allerlei bedreigingen die bedoeld zijn om die apparaten te ondermijnen, om onmiddellijke aanvallen uit te voeren of voor subtielere en geavanceerdere aanhoudende bedreigingen.

Dit artikel beschrijft hoe ontwikkelaars de beveiliging van IoT-apparaten kunnen verbeteren door gebruik te maken van een vertrouwensbasis die voortbouwt op onderliggende beveiligingsmechanismen om een vertrouwde omgeving te bieden voor de uitvoering van software op veilige processors van onder andere Maxim Integrated, Microchip Technology, NXP Semiconductors en Silicon Labs.

Wat is de vertrouwensbasis en waarom is die nodig?

Cryptografische methoden en veilige sleutels zijn cruciale enablers voor de beveiliging van alle aangesloten apparatuur. Zoals in deel 1 en deel 2 van deze reeks is opgemerkt, voorzien zij in fundamentele mechanismen die door protocollen van een hoger niveau worden gebruikt om gegevens en communicatie te beschermen. Om het systeem zelf te beschermen, moeten ontwikkelaars rekening houden met kwetsbaarheden die van invloed kunnen zijn op de werking van het systeem en de uitvoering van software in ingebedde systemen.

In een typisch ingebed systeem wordt bij een systeemreset als gevolg van een stroomstoring of een kritische software-uitzondering uiteindelijk het software-opstartproces gestart om een firmware-image uit het niet-vluchtige geheugen te herladen. Normaliter is het opnieuw opstarten van software een belangrijk veiligheidsmechanisme dat wordt gebruikt om de werking te herstellen van een systeem dat per ongeluk of opzettelijk gedestabiliseerd is geraakt. In gekoppelde systemen, waar hackers een verscheidenheid aan "black hat"-tools gebruiken om software te compromitteren, bevelen beveiligingsspecialisten vaak een herstart aan om inbraken tegen te gaan die de uitvoering van software beïnvloeden. Zo raadde de FBI in 2018 consumenten en bedrijfseigenaren aan om hun routers opnieuw op te starten om een massale hackcampagne die toen aan de gang was, te dwarsbomen.

In de praktijk is een herstart geen garantie voor de integriteit van het systeem. Na het herstarten met een gecompromitteerd firmware image, blijft het systeem nog steeds onder controle van de hacker. Om dit soort bedreigingen te beperken, moeten ontwikkelaars ervoor zorgen dat hun software draait op een vertrouwensketen die voortbouwt op een vertrouwensbasis die bij het opstarten wordt vastgesteld en die zich uitstrekt over alle lagen van de software-uitvoeringsomgeving. De mogelijkheid om dit veiligheidsniveau te bereiken hangt in belangrijke mate af van de garantie dat het opstartproces begint met vertrouwde firmware.

Verifiëren van firmware images voor veilig opstarten

In een ingebed systeem laadt de host-processor een firmware-image vanuit het flashgeheugen in het werkgeheugen en begint het uit te voeren (of begint het rechtstreeks vanuit het flashgeheugen uit te voeren met een execute-in-place (XIP)-mogelijkheid). Als hackers de firmware image hebben gecompromitteerd, resulteert het opstartproces in een gecompromitteerd systeem.

Om de integriteit van de firmware te verifiëren alvorens ermee op te starten, gebruiken ontwikkelaars een codeondertekeningsproces dat al vroeg in de toeleveringsketen begint. Binnen een beveiligde faciliteit wordt het firmware-image van het systeem ondertekend met een privésleutel van een privaat-publiek sleutelpaar dat is gemaakt met een cryptografisch robuust algoritme zoals het Elliptic Curve Digital Signature Algorithm (ECDSA). Hoewel de particuliere sleutel de faciliteit nooit verlaat, gaat de openbare sleutel van het systeem met het systeem mee. Tijdens het opstarten gebruikt de processor deze openbare systeemsleutel om de firmwarehandtekening te verifiëren alvorens de image te gebruiken.

Natuurlijk laat het zojuist beschreven proces de openbare sleutel zelf kwetsbaar, en bij uitbreiding de systeemfirmware kwetsbaar voor ongeoorloofde vervanging. Als de openbare sleutel in het ingebedde systeem onbeschermd blijft, kunnen hackers hem mogelijk vervangen door een openbare sleutel van een privaat-publiek sleutelpaar dat zij zelf hebben gegenereerd. Als zij het firmware-image van het systeem vervangen door kwaadaardige firmware die is ondertekend met de bijbehorende privésleutel die zij bezitten, doorstaat de aangetaste firmware-handtekening het verificatieproces en gaat het opstartproces door, met als resultaat een aangetast systeem.

Om deze reden berusten beveiligde systemen op een geldige openbare sleutel die in een beveiligd element binnen de beveiligingsfaciliteit is opgeslagen. BeveiligingsIC's zoals de DS28C36 van Maxim Integrated en de ATECC608A van Microchip Technology bieden zowel de veilige opslag van een traditioneel veilig element, als de veilige uitvoering van authenticatiealgoritmen, zoals ECDSA, voor de verificatie van firmwarehandtekeningen.

Voorafgaand aan het opstarten kan de hostprocessor de firmware bijvoorbeeld via een seriële interface naar de DS28C36 sturen. De DS28C36 gebruikt op zijn beurt de openbare sleutel van het systeem, die eerder in de beveiligde faciliteit werd verstrekt, om te verifiëren dat de firmwarehandtekening inderdaad met de bijbehorende particuliere sleutel in dezelfde beveiligde faciliteit werd aangemaakt. Tenslotte geeft de DS28C36 het verificatieresultaat door aan de hostprocessor, die overgaat tot het laden van het firmware-image indien de handtekening geldig is (figuur 1).

Figuur 1: Ontwikkelaars kunnen beveiligingsIC's zoals de Maxim Integrated DS28C36 gebruiken om firmwarehandtekeningen te verifiëren om te voorkomen dat de hostprocessor gecompromitteerde firmware opstart. (Bron afbeelding: Maxim Integrated)

Een veiliger opstartproces beschermt het firmware-image om elke zorg over gecompromitteerde sleutels of images weg te nemen. Met behulp van veilige opslag en cryptografieversnellers worden effectieve veilige bootmogelijkheden ingebouwd in een groeiend aantal processoren, waaronder de Gecko Series 2-processoren van Silicon Laboratories, de LPC55S69JBD100 van NXP, de MAX32520 van Maxim Integrated, en de ATSAML11D16A van Microchip Technology, om er maar een paar te noemen. Door gebruik te maken van deze mogelijkheden kan deze klasse van veilige processoren de "root of trust" leveren die nodig is om een betrouwbare omgeving te creëren voor de uitvoering van systeem- en toepassingsprogrammatuur.

Zorgen voor een vertrouwensbasis door veilig opstarten

Beveiligde processoren in deze klasse bieden beveiligde opstartopties die de integriteit van het firmware-image dat aan de basis ligt van het vertrouwen, moeten garanderen. De Gecko serie 2-processoren EFR32MG21A en EFR32BG22 van Silicon Laboratories bouwen bijvoorbeeld deze vertrouwensbasis op door middel van een meerfasig opstartproces op basis van respectievelijk een hardwareveilig element en een virtueel veilig element (VSE) (figuur 2).

Figuur 2: De Gecko Series 2 EFR32MG21A-processor van Silicon Laboratories gebruikt een geïntegreerd hardwarematig beveiligd element in de eerste fase van zijn meerfasige opstartproces (hier afgebeeld), terwijl de EFR32BG22 zijn meerfasige opstartproces met een virtueel beveiligd element initieert. (Afbeelding bron: Silicon Laboratories)

In de EFR32MG21A biedt een speciale processorkern cryptografische functionaliteit, samen met een beveiligd hardwarematig element voor veilige sleutelopslag. Ondersteund door deze speciale capaciteit, start de processor het opstartproces met behulp van code die is opgeslagen in het alleen-lezen geheugen (ROM) om de code van de eerste fase van de opstartlader (FSB) te verifiëren. Na verificatie wordt de FSB-code uitgevoerd, die op zijn beurt de codehandtekening van de second-stage bootloader (SSB) verifieert. De opstartsequentie gaat verder met de uitvoering van de geverifieerde SSB, die op zijn beurt de handtekening van de toepassingscode verifieert, die doorgaans zowel de code op systeemniveau als de toepassingscode op hoger niveau omvat. Tenslotte wordt de geverifieerde applicatiecode uitgevoerd en verlopen de systeemoperaties zoals vereist door de applicatie.

Omdat dit proces begint met ROM-code en alleen geverifieerde FSB-, SSB- en applicatiecode uitvoert, resulteert deze aanpak in een geverifieerde vertrouwensketen voor de uitvoering van code. Omdat de eerste schakel in deze vertrouwensketen berust op ROM-code die niet kan worden gewijzigd, breidt elke volgende schakel in de keten deze vertrouwde omgeving uit. Tegelijkertijd kunnen ontwikkelaars met deze aanpak de applicatiecode veilig bijwerken, en zelfs de eerste- en tweedefase bootloadercode. Zolang elk codepakket een geverifieerde handtekening levert, blijft de vertrouwde omgeving intact.

Processoren die dit soort beveiligd opstarten met een root of trust bieden, ondersteunen doorgaans meerdere modi en opties. Zo bieden de Gecko serie 2-processoren van Silicon Laboratories een sterkere, op certificaten gebaseerde, veilige opstartmogelijkheid.

Certificaten, die worden gebruikt in routinetransacties met de public key infrastructure (PKI), bevatten de openbare sleutel, samen met een verwijzing naar een of meer geassocieerde certificaten die uiteindelijk verwijzen naar een basiscertificaat dat is verleend door een certificeringsautoriteit (CA). Elk certificaat in deze keten dient om het certificaat (de certificaten) eronder te verifiëren, wat resulteert in een vertrouwensketen op basis van een betrouwbare CA. Browsers vertrouwen op deze vertrouwensketen tijdens de authenticatiefase van de Transport Layer Security (TLS) om de identiteit van webservers te bevestigen. Op dezelfde manier kunnen ingebedde systemen certificaten gebruiken om de identiteit van de bron van bootloader- of toepassingscode te bevestigen. Hier verloopt het meerfasige opstartproces zoals eerder beschreven, maar met extra verificatie van het certificaat dat bij elke fase hoort (figuur 3).

Figuur 3: De Gecko serie 2-processoren van Silicon Laboratories verbeteren de veiligheid van het systeem door certificaten te verifiëren voor openbare sleutels die worden gebruikt tijdens de verificatie van handtekeningen in elke fase van het opstartproces. (Afbeelding bron: Silicon Laboratories)

Andere processoren, zoals de NXP LPC55S69JBD100, ondersteunen een aantal verschillende opties voor het firmware-image. Naast ondertekende firmware-images ondersteunen deze processoren boot-images die gebruikmaken van de DICE-industriestandaard (device identifier composition engine) van de Trusted Computing Group. Een derde optie stelt ontwikkelaars in staat beelden op te slaan in speciale regio's van de flash van de processor die het PRINCE-cijfer ondersteunen, een blokcijfer met lage latentie waarmee een beveiligingskracht kan worden bereikt die vergelijkbaar is met die van andere cijfers, maar met een veel kleiner siliciumoppervlak. Het PRINCE-cijfer, dat is geïmplementeerd in de LPC55S69JBD100, kan versleutelde code of gegevens die zijn opgeslagen in de PRINCE flashgebieden van de processor, snel ontsleutelen. Omdat de geheime sleutels die voor de ontcijfering worden gebruikt alleen toegankelijk zijn voor de PRINCE-cryptografie-engine, blijft dit ontcijferingsproces veilig. In feite worden deze geheime sleutels beschermd door een sleutel-encryptiesleutel (KEK) die wordt gegenereerd door de LPC55S69JBD100's physical unclonable function (PUF) functie. (Voor meer over het gebruik van PUF en KEK, zie deel 2.)

Deze aanpak biedt ontwikkelaars de mogelijkheid om extra firmware-images op te slaan - een mogelijkheid die nodig is om IoT-apparaten te voorzien van firmware-over-the-air (FOTA) updatemethodes zonder het risico te lopen dat het apparaat "verpest" wordt. Als de processor slechts één plaats kan gebruiken om firmware-images op te slaan, kan een defecte firmware-image de processor in een onbepaalde of vergrendelde toestand brengen waardoor het apparaat wordt vergrendeld of geblokkeerd. Door firmware-images op te slaan in de PRINCE-geactiveerde flashregio's van de LPC55S69JBD100, kunnen ontwikkelaars back-off strategieën gebruiken die een vorige werkende versie van firmware herstellen als de nieuwe versie opstart in een niet-functionele toestand.

Omdat al deze nieuwe firmware-images de controles op handtekeningverificatie moeten doorstaan die vereist zijn in het onderliggende opstartproces, kunnen ontwikkelaars ten volle profiteren van beveiligde FOTA om nieuwe functies toe te voegen of bugs te herstellen zonder het systeem of de vertrouwensketen ervan in gevaar te brengen.

Conclusie

Beveiliging op systeem- en toepassingsniveau vereist een uitvoeringsomgeving die alleen geautoriseerde software toestaat te werken. Hoewel de verificatie van handtekeningen onder codes een essentieel kenmerk is om dit soort omgevingen mogelijk te maken, moeten veilige systemen een beroep doen op een bredere reeks capaciteiten om de vertrouwensketen op te bouwen die nodig is om een betrouwbare uitvoering van software te waarborgen. De basis voor deze vertrouwde omgevingen ligt in een vertrouwensbasis die tot stand wordt gebracht door middel van veilige opstartmechanismen die door veilige processoren worden ondersteund. Met deze klasse processoren kunnen ontwikkelaars veilige ivd-apparatuur implementeren die bestand is tegen aanvallen die bedoeld zijn om de uitvoering van software in een systeem lam te leggen of het systeem volledig te kapen.