Beveiliging en updatemechanismen voor IoT-firmware: een diepgaande analyse

Het gebruik van netwerkgekoppelde Internet of Things (IoT)-apparaten neemt snel toe, wat leidt tot diverse cyberaanvallen en aanvallen op de toeleveringsketen die zich op deze apparaten richten. Aanvallen in de praktijk hebben aangetoond hoe firmware kan worden misbruikt om botnets te creëren, gegevens te stelen of zelfs de controle over kritieke infrastructuur over te nemen. Het beruchte Mirai-botnet maakte bijvoorbeeld gebruik van onveilige IoT-apparaten om massale DDoS-aanvallen uit te voeren. Veel van deze apparaten hadden hardgecodeerde inloggegevens en geen mogelijkheid om hun firmware bij te werken.

Daarom is het up-to-date houden van de firmware van uw IoT-apparaten een cruciaal onderdeel van uw cybersecuritybeleid. Firmware-updates zijn cruciaal om softwarefouten te verhelpen, kwetsbaarheden te verhelpen of nieuwe beveiligingsfuncties toe te voegen. Net zo belangrijk is het om ervoor te zorgen dat deze updates veilig en betrouwbaar zijn.

Beveiliging van IoT-firmware, gedefinieerd: ervoor zorgen dat alleen authentieke, ongewijzigde firmware op een apparaat draait en dat elke update cryptografisch wordt geverifieerd vóór installatie. Dit combineert beveiligd opstarten (vertrouwen bij inschakelen), ondertekende OTA-updates (vertrouwen tijdens de update) en bescherming tegen terugdraaien (geen downgraden naar een kwetsbare versie), en is toepasbaar op apparaten die vaak te weinig resources hebben om traditionele beveiligingssoftware te draaien.

Key Takeaways

• Deze pagina behandelt de levenscyclus van IoT-apparaten en OTA-updates: praktijkvoorbeelden, verantwoordelijkheden van leveranciers en eindgebruikers, en standaarden. Voor een gedetailleerde beschrijving van de opstartcryptografie zelf (hardware-roots of trust, rollback-tellers, productie-identiteiten), zie Bootloader-vertrouwen: de cruciale rol van firmware-ondertekening.
• Een gelekte of gecompromitteerde firmware-ondertekeningssleutel vereist een volledig herstelproces, geen simpele sleutelwissel: elk apparaat dat al in gebruik is, vertrouwt de oude sleutel en intrekking daarvan betekent een update, geen certificaatcontrole.
• ML-DSA (FIPS 204) en SLH-DSA (FIPS 205) zijn de definitieve post-kwantumsignatuurstandaarden van NIST, zoals vastgesteld in augustus 2024; LMS en XMSS (NIST SP 800-208) zijn de stateful hash-gebaseerde schema's die CNSA 2.0 specifiek voorschrijft voor het ondertekenen van firmware.

Belangrijkste uitdagingen met betrekking tot de beveiliging van IoT-firmware

Het beveiligen van firmware is niet zo eenvoudig als het beveiligen van een webapplicatie. IoT-apparaten hebben vaak beperkte resources, wat betekent dat ze niet de verwerkingskracht of het geheugen hebben om traditionele beveiligingsprotocollen te ondersteunen. Ze zijn ook ongelooflijk divers: verschillende chipsets, verschillende besturingssystemen, verschillende updatemechanismen. Dit gebrek aan standaardisatie maakt het lastig om een ​​pasklare oplossing te vinden.

Kwetsbaarheid in de toeleveringsketen is een belangrijke uitdaging voor firmwarebeveiliging, aangezien firmware vaak wordt ontwikkeld door externe leveranciers of wordt samengesteld uit open-sourcecomponenten. Dit opent de deur voor manipulatie lang voordat het apparaat de eindgebruiker bereikt. En zodra het in gebruik is, wordt het updaten van die firmware een logistieke nachtmerrie, tenzij je er vanaf het begin rekening mee hebt gehouden.

Bovendien kunnen aanvallers zich via ongeautoriseerde toegang tot code-ondertekeningssleutels of firmware-ondertekeningsmechanismen voordoen als vertrouwde apparaten en schadelijke updates installeren op apparaten die vertrouwd lijken.

Ten slotte kunnen onveilige coderingspraktijken aanvallers in staat stellen om buffer overflows te misbruiken om op afstand toegang te krijgen tot apparaten en DDoS- of malware-injectieaanvallen uit te voeren.

Gevolgen van onveilige IoT-firmware

Onveilige IoT-firmware kan leiden tot diverse aanvallen die op afstand en zonder waarschuwing door een aanvaller kunnen worden uitgevoerd. Laten we eens kijken naar enkele voorbeelden hieronder:

1. In september 2016 lanceerden de makers van Mirai een DDoS-aanval op de website van een bekende beveiligingsexpert. Kort daarna gaven ze de broncode vrij, die snel door andere cybercriminelen werd overgenomen. Dit leidde in oktober 2016 tot een grootschalige aanval op de aanbieder van domeinregistratiediensten, Dyn, die voor wijdverspreide verstoring zorgde.

2. Het RIFT-botnet ontstond in december 2018 en maakte gebruik van diverse exploits om IoT-apparaten te infecteren. Volgens online bronnen maakte het botnet gebruik van 17 exploits.

   Op 11 december 2018 werd een kwetsbaarheid voor code-uitvoering op afstand in het ThinkPHP-framework gemeld, waarbij de OS-opdrachten werden geïnjecteerd via de queryparameter "vars". Dit volgt op een typische exploitatievolgorde die wordt waargenomen bij RIFT-aanvallen.

3. In een ander incident lekte D-Link per ongeluk privé-codeondertekeningssleutels die gebruikt werden om software te ondertekenen. Hoewel het niet bekend is of de sleutels door kwaadwillende derden zijn gebruikt, bestaat de mogelijkheid dat ze door een hacker zijn gebruikt om malware te ondertekenen, waardoor aanvallen veel gemakkelijker konden worden uitgevoerd.
4. Bij een van de aanvallen op connected cars onthulden onderzoekers van het Chinese bedrijf Tencent dat ze via de wifi-verbinding van een Tesla S toegang konden krijgen tot de rijsystemen en op afstand de remmen van het rijdende voertuig konden activeren.

Het beveiligen van IoT-firmware-updates – perspectief van leveranciers

Met OTA-updates (Over-the-Air) kunt u firmwarepatches, beveiligingsupdates en zelfs nieuwe functies op afstand naar apparaten pushen, zonder dat u fysieke toegang nodig hebt. OTA-updates worden meestal geleverd via mobiele data (4G of 5G) of via internetverbindingen.

OTA maakt uw firmware-updateproces niet alleen eenvoudiger, maar vergroot ook de veerkracht, waardoor uw organisatie crypto-flexibiliteit krijgt bij het omgaan met elke vorm van cyberaanval. Zonder OTA zit u vast aan de firmware die bij de lancering op het apparaat stond. En als die firmware een fout bevat, zit u in de problemen.

Het ontwerpen van een veilig OTA-systeem is cruciaal voor de beveiliging van de firmware. Elke update moet worden ondertekend met een privésleutel en op het apparaat worden geverifieerd met een bijbehorende publieke sleutel. Dit zorgt ervoor dat alleen vertrouwde updates worden geïnstalleerd. Apparaten moeten elke update weigeren die niet aan deze criteria voldoet. Het updateproces moet ook integriteitscontroles bevatten om manipulatie tijdens de overdracht te voorkomen. Daarnaast is bescherming tegen terugdraaien essentieel om te voorkomen dat aanvallers de firmware kunnen downgraden naar een kwetsbare versie.

Net zo belangrijk is de infrastructuur achter de updates. Je hebt een veilige serveromgeving nodig om de firmware te hosten, een betrouwbaar leveringsmechanisme en een monitoringsysteem om het succes en de mislukkingen van updates bij te houden. Gebruikerstransparantie is ook belangrijk om gebruikers te informeren over updates en de redenen daarvoor, om vertrouwen op te bouwen en weerstand te verminderen.

Herstellen van een gecompromitteerde firmware-ondertekeningssleutel

Het bovenstaande D-Link-incident is een nuttig voorbeeld om na te denken over herstel, omdat het illustreert waarom dit verschilt van een typische certificaatintrekking. Zodra een firmware-ondertekeningssleutel is blootgesteld, zorgt het intrekken van het certificaat ervoor dat nieuwe kwaadwillige handtekeningen niet meer gevalideerd kunnen worden op systemen die de intrekkingsstatus controleren. Het zorgt er echter niet voor dat de sleutel met terugwerkende kracht onbetrouwbaar wordt op apparaten die al in gebruik zijn, waarvan vele nooit contact opnemen met de server om de intrekking te controleren. Herstel vereist het identificeren van elk apparaatmodel en elke firmwareversie die is ondertekend met de gecompromitteerde sleutel, het overschakelen naar een nieuwe sleutel die is opgeslagen in een HSM, en het uitrollen van een ondertekende update met de nieuwe sleutel die apparaten kunnen verifiëren. Dit alles terwijl apparaten zonder netwerkverbinding of updatefunctie permanent kwetsbaar kunnen blijven. Dit is precies de reden waarom rollback-bescherming en een gedocumenteerd sleutelrotatieplan moeten bestaan ​​vóór een inbreuk plaatsvindt, en niet pas tijdens een inbreuk worden ontworpen.

Het beveiligen van IoT-firmware-updates – het perspectief van de eindgebruiker

Onveilige IoT-firmware-updates kunnen ernstige gevolgen hebben voor de gebruikers van deze apparaten, vooral omdat allerlei kwaadaardige aanvallen op afstand kunnen worden uitgevoerd, zonder dat fysieke toegang tot het apparaat nodig is.

Om je te beschermen tegen onveilige firmware-updates, vermijd je automatische updates, vooral op onbetrouwbare netwerken, en download je updates alleen van de beveiligde website van de fabrikant via HTTPS . Houd bovendien altijd rekening met firmware-ondersteuning bij je aankoopbeslissingen.

Toepassingen, standaarden en innovaties in de praktijk op het gebied van firmwarebeveiliging

Sectoren die sterk afhankelijk zijn van IoT, zoals de auto-industrie, de gezondheidszorg en de maakindustrie, zien al de voordelen van veilige OTA-updates. In de auto-industrie worden OTA-updates bijvoorbeeld niet alleen gebruikt voor infotainmentsystemen, maar ook voor kritieke veiligheidsvoorzieningen. Tesla staat erom bekend OTA te gebruiken voor de uitrol van allerlei zaken, van prestatieverbeteringen tot bugfixes, vaak binnen een dag.

In de gezondheidszorg, waar apparaten zoals insulinepompen en hartmonitoren steeds vaker met elkaar verbonden zijn, kunnen OTA-updates een kwestie van leven of dood zijn. Een kwetsbaarheid in een medisch apparaat is niet alleen een beveiligingsprobleem, maar ook een probleem voor de veiligheid van de patiënt. Veilige OTA-mechanismen zorgen ervoor dat deze apparaten snel en veilig kunnen worden bijgewerkt, zonder dat een ziekenhuisbezoek nodig is.

Normen zoals het IoT-cyberbeveiligingsraamwerk van NIST en ETSI EN 303 645 stimuleren IoT-fabrikanten om veilige ontwikkelingspraktijken, strenge tests en een robuuste OTA-infrastructuur te hanteren. De EU-verordening inzake cyberweerbaarheid voegt hieraan een relevante eis toe: fabrikanten moeten bewijs kunnen leveren, zoals auditsporen, ondertekeningsdocumenten en gedocumenteerde processen, waaruit blijkt dat de integriteit van updates is geverifieerd, en niet alleen dat dit het geval is.

Recent onderzoek heeft geavanceerde cryptografische technieken voorgesteld om firmware-updates te beveiligen tegen aanvallen in de toeleveringsketen. NIST heeft in augustus 2024 zijn eerste post-kwantumsignatuurstandaarden afgerond: ML-DSA (FIPS 204, voorheen bekend als Dilithium) en SLH-DSA (FIPS 205, voorheen bekend als SPHINCS+). Specifiek voor firmware zijn de stateful hash-gebaseerde schema's LMS en XMSS (NIST SP 800-208) ook goedgekeurd en worden door de NSA's CNSA 2.0-suite gespecificeerd voor het ondertekenen van software en firmware.

Hoe kan Encryption Consulting u helpen?

CodeSign Secure van Encryption Consulting beschermt uw software met een krachtige, op beleid gebaseerde oplossing voor het ondertekenen van codes, waarmee u de beveiliging moeiteloos kunt stroomlijnen. Dit omvat onder andere HSM-ondersteunde sleutelopslag voor firmware-ondertekeningssleutels en volledige auditregistratie van elke ondertekeningsgebeurtenis.

De adviesdiensten van Encryption Consulting kunnen uw organisatie helpen bij het ontdekken van bedrijfsbrede gegevensbescherming met end-to-end-encryptiestrategieën die de naleving van regelgeving verbeteren, blinde vlekken in risico's elimineren en de beveiliging afstemmen op uw bedrijfsdoelstellingen in cloud-, on-premise- en hybride omgevingen.

Daarnaast kan de PQC-assessmentdienst van Encryption Consulting uw organisatie helpen door een gedetailleerde beoordeling uit te voeren van uw on-premises, cloud- en SaaS-omgevingen, kwetsbaarheden te identificeren en de beste strategieën aan te bevelen om de kwantumrisico's te beperken.

Voor meer informatie over onze producten en diensten kunt u terecht op:

Code Signing Solution | Snelle, gemakkelijke en veilige codeondertekening met CodeSign Secure

Post Quantum Cryptografische Diensten | Encryptie Consulting

Encryptie Adviesdiensten

Conclusie

Firmware is misschien onzichtbaar voor de meeste gebruikers, maar het vormt de ruggengraat van elk IoT-apparaat. Investeren in veilige firmwarepraktijken en robuuste OTA-updatesystemen is de sleutel tot het beschermen en beperken van de risico's die gepaard gaan met kwetsbaarheden in firmware en cryptografische aanvallen.

Veelgestelde Vragen / FAQ

Is dilithium hetzelfde als ML-DSA?

Ja. ML-DSA (FIPS 204) is de gestandaardiseerde naam die NIST in augustus 2024 voor Dilithium heeft vastgesteld. Op dezelfde manier is SLH-DSA (FIPS 205) de gestandaardiseerde naam voor SPHINCS+.

Is het intrekken van het certificaat voldoende als een ondertekeningssleutel voor firmware is gecompromitteerd?

Nee. Intrekking voorkomt dat nieuwe handtekeningen gevalideerd worden wanneer apparaten de intrekkingsstatus controleren, maar de meeste IoT-apparaten controleren dit niet in realtime. Apparaten die al in gebruik zijn, blijven de oude sleutel vertrouwen totdat ze een update ontvangen en installeren die is ondertekend met een nieuwe sleutel. Herstel vereist het identificeren van de getroffen apparaten, het vernieuwen van de sleutel en het uitrollen van een verifieerbare update, niet alleen het intrekken van een certificaat.

Welke bewijzen verwacht de EU-verordening inzake cyberweerbaarheid met betrekking tot de integriteit van firmware-updates?

Gedocumenteerde processen en auditsporen, ondertekeningsverslagen, sleutelbeheerlogboeken en verificatiestappen, die aantonen dat de integriteit van updates daadwerkelijk werd gewaarborgd, en niet slechts een bewering. Dit is hetzelfde bewijs dat de auditlogboeken van een gecentraliseerd ondertekeningsplatform moeten opleveren.