Firmwareondertekening: een praktische handleiding

Firmwareondertekening is het proces waarbij een cryptografische handtekening aan firmware wordt toegevoegd, zodat een apparaat bij het opstarten en bij updates kan verifiëren dat de firmware afkomstig is van een vertrouwde bron en niet is gewijzigd. Het vormt de basis van beveiligd opstarten en de vertrouwensbasis voor IoT-, embedded- en automobielsystemen.

Firmwareondertekening stelt een apparaat in staat om cryptografisch te controleren of de code die het uitvoert authentiek en ongewijzigd is voordat deze wordt uitgevoerd. Het apparaat beschikt over een vertrouwde openbare sleutel, vaak in de hardware geïntegreerd, en verifieert de handtekening van de firmware hiermee. Als de handtekening niet overeenkomt, weigert het apparaat de firmware uit te voeren. Dit voorkomt dat aanvallers kwaadaardige firmware installeren en vormt de basis van elke beveiligde opstartketen.

Key Takeaways

• Firmwareondertekening voegt een digitale handtekening toe aan de firmware, zodat een apparaat de authenticiteit en integriteit ervan kan verifiëren voordat deze wordt uitgevoerd. Dit vormt de basis voor een veilige opstartprocedure.
• Het vertrouwensanker is een publieke sleutel die is ingebed in eenmalig programmeerbare (OTP) hardware en die bij elke inschakeling wordt uitgelezen door onveranderlijk ROM-geheugen, waardoor de vertrouwensketen in het veld niet kan worden vervangen.
• Ondertekeningssleutels moeten zich in een hardwarebeveiligingsmodule (HSM) bevinden. Een gestolen firmware-ondertekeningssleutel stelt een aanvaller in staat om kwaadaardige firmware te ondertekenen die apparaten vervolgens vertrouwen. Dit is een van de meest schadelijke inbreuken op de toeleveringsketen die mogelijk zijn.
• Firmware gaat vaak langer mee dan de cryptografie: apparaten die vandaag de dag worden ingezet, kunnen tot in de jaren 2040 blijven functioneren. Door deze lange levensduur is paraatheid voor het post-kwantumtijdperk een vereiste bij de aanschaf, en geen zorg voor de toekomst.
• CNSA 2.0 noemt het ondertekenen van firmware als de belangrijkste toepassing voor de overgang naar het post-kwantumtijdperk. De momenteel inzetbare kwantumveilige opties zijn de stateful hash-gebaseerde schema's LMS en XMSS (NIST SP 800-208), met SLH-DSA (FIPS 205) als een stateless alternatief.

Waarom firmwareondertekening verschilt van gewone codeondertekening

Firmware-ondertekening is in feite code-ondertekening , maar met beperkingen die het bijzonder veeleisend maken. Firmware draait op het laagste niveau van een apparaat, vóór het besturingssysteem, waardoor een compromis op dit gebied buiten het bereik van de meeste beveiligingssoftware ligt. En in tegenstelling tot een applicatie die je wekelijks kunt patchen, is firmware vaak in de hardware ingebrand of wordt deze zelden, soms zelfs nooit, bijgewerkt gedurende de levensduur van een apparaat die tientallen jaren kan duren.

Drie eigenschappen definiëren de uitdaging. Firmware is de eerste code die wordt uitgevoerd, dus het vormt de basis van vertrouwen voor alles wat erboven staat. Het draait op hardware met beperkte mogelijkheden, dus de verificatie van digitale handtekeningen moet klein en snel zijn. En het heeft een lange levensduur, dus de cryptografische keuzes die tijdens de fabricage zijn gemaakt, moeten gedurende de hele levensduur van het apparaat betrouwbaar blijven. Een auto, een industriële controller of een medisch apparaat dat in 2026 is ondertekend, moet mogelijk in 2041 nog steeds de firmware verifiëren.

Hoe firmwareondertekening en Secure Boot werken

Het ondertekenen van firmware is op zich slechts de helft van het verhaal. De waarde ervan komt pas echt tot uiting in secure boot, het runtime-proces waarbij elke fase van de opstartketen de volgende verifieert voordat de controle wordt overgedragen.

• Hardware root of trust: Een publieke sleutel wordt tijdens de fabricage van de chip in een eenmalig programmeerbaar (OTP) geheugen opgeslagen. Het onveranderlijke ROM leest deze sleutel bij elke inschakeling en kan niet in het veld worden vervangen. Dit is het anker van de gehele keten.
• Onderteken elke firmware-image: De fabrikant hasht elke firmware-image (ROM, bootloaders, applicaties) en ondertekent deze met de bijbehorende privésleutel, die veilig wordt bewaard in een HSMnooit op het apparaat.
• Controleer stap voor stap: Bij het opstarten controleert het ROM de handtekening van de eerste bootloader aan de hand van de gekoppelde publieke sleutel. Die bootloader controleert vervolgens de volgende fase, die op zijn beurt de volgende controleert, waardoor een ononderbroken vertrouwensketen ontstaat van de hardware tot aan de applicatie.
• Afwijzen bij fout: Als een van de handtekeningen niet overeenkomt, stopt het geverifieerde opstartproces en weigert het apparaat de niet-geverifieerde image uit te voeren. Gemanipuleerde of ongeautoriseerde firmware wordt nooit uitgevoerd.

Omdat de hoofdsleutel zich in onveranderlijke hardware bevindt en elke fase de volgende afschermt, kan een aanvaller nergens in de keten kwaadaardige firmware invoegen zonder de privésleutel voor de ondertekening te bezitten. Daarom is het beschermen van de ondertekeningssleutel van het grootste belang.

Waarom de ondertekeningssleutel het kroonjuweel is

Als een aanvaller een firmware-ondertekeningssleutel steelt, kan hij kwaadaardige firmware ondertekenen die elk apparaat dat die sleutel vertrouwt, als authentiek accepteert. Omdat de verificatiesleutel vaak in de hardware is vastgelegd en niet in het veld kan worden gewijzigd, kan een gecompromitteerde firmware-ondertekeningssleutel onherstelbaar zijn: er is mogelijk geen manier om deze in te trekken op apparaten die al in gebruik zijn. Dit is een worstcasescenario voor de toeleveringsketen en daarom moeten firmware-ondertekeningssleutels zorgvuldiger worden beschermd dan vrijwel elke andere sleutel die een organisatie bezit.

De praktische eis is absoluut: de privésleutels voor het ondertekenen van firmware moeten worden gegenereerd en opgeslagen in een hardwarebeveiligingsmodule (HSM), nooit worden geëxporteerd naar een buildserver of ontwikkelmachine, en de ondertekeningshandelingen moeten worden geauthenticeerd, beveiligd met toegangscontrole en gelogd. De firmware gaat door vele handen (chipfabrikant, OEM, Tier-1-leverancier, contractfabrikant), en elke overdracht is een punt waar de keten kan worden ondermijnd. Daarom is gecentraliseerd, gecontroleerd sleutelbeheer essentieel.

Best practices voor het ondertekenen van firmware

• Blijf sleutels ondertekenen in een HSM: Genereer en bewaar firmware-ondertekeningssleutels in een FIPS 140-2 HSM niveau 2 of hoger. Zorg ervoor dat de privésleutel nooit in contact komt met een buildserver, CI-runner of ontwikkelaarslaptop.
• Vertrouwen in hardware verankeren: Voeg de openbare root-sleutel samen met de OTP en verifieer deze vanuit het onveranderlijke ROM, zodat het vertrouwensanker in het veld niet kan worden gemanipuleerd.
• Onderteken elke fase van de productieketen: Onderteken ROM-extensies, bootloaders en applicatiefirmware, en verifieer elke fase ten opzichte van de voorgaande fase, zodat er geen hiaat in de ondertekening ontstaat.
• Gebruik sterke, actuele algoritmen: Gebruik SHA-384 of een sterkere hashfunctie en sleutels van de juiste grootte. Houd rekening met digitale handtekeningen na de kwantumcomputer, gezien de lange levensduur van de apparaten.
• Controleer en auditeer wie bevoegd is om te tekenen: Vereis authenticatie en autorisatie voor elke ondertekeningshandeling en registreer wie wat wanneer heeft ondertekend, bij elke leverancier in de keten.
• Ontwerp voor crypto-flexibiliteit: Schakel, waar de hardware dit toelaat, updates voor het handtekeningalgoritme in, zodat apparaten niet vastzitten aan een algoritme dat in de loop van hun levensduur mogelijk minder effectief wordt.

Firmware-ondertekening en de post-kwantumtransitie

Het ondertekenen van firmware is de meest urgente toepassing van codeondertekening in de overgang naar post-kwantumcryptografie , en de reden hiervoor is structureel. In veel apparaten is het firmwareverificatiealgoritme vastgelegd bij de implementatie, ingebouwd in onveranderlijke hardware of opstartcode. Als dat algoritme RSA of ECDSA is , zou een toekomstige kwantumcomputer die het algoritme van Shor gebruikt, handtekeningen kunnen vervalsen, en is er mogelijk geen manier om het algoritme op reeds geleverde apparaten bij te werken.

Daarom beschouwt de NSA in haar CNSA 2.0-richtlijnen het ondertekenen van firmware als de belangrijkste toepassing voor digitale handtekeningen in de overgang naar kwantumtechnologie, en wijst ze op hash-gebaseerde handtekeningen die vandaag de dag al gestandaardiseerd en inzetbaar zijn, in plaats van te wachten op nieuwere methoden. De opties:

• LMS en XMSS (NIST SP 800-208): Stateful hash-gebaseerde handtekeningen, gestandaardiseerd in 2019 en goedgekeurd onder CNSA 2.0 voor het ondertekenen van firmware en software. Ze zijn nu al inzetbaar en berusten op de bekende hashfunctiebeveiliging, die geschikt is voor firmware met een lange levensduur.
• SLH-DSA (FIPS 205): Een stateless hash-gebaseerde handtekening, die in augustus 2024 is afgerond. Deze vermijdt de last van state management zoals bij LMS en XMSS, ten koste van grotere handtekeningen, en deelt hun conservatieve beveiligingsprincipes.
• ML-DSA (FIPS 204): De op een raster gebaseerde, algemene handtekening. Het is de meest geschikte kandidaat voor breed gebruik op de lange termijn, hoewel veel organisaties voor de meest conservatieve, langdurige root-certificaten de voorkeur geven aan hash-gebaseerde schema's.

De valkuil van staatsbeheer met LMS en XMSS
LMS en XMSS zijn stateful: elke privésleutel kan slechts een vast aantal handtekeningen genereren, en de ondertekenaar moet bijhouden welke eenmalige sleutels zijn gebruikt, omdat hergebruik van een sleutel de beveiliging ondermijnt. Dit maakt ze onpraktisch voor frequente ondertekening, maar zeer geschikt voor het ondertekenen van firmware, wat infrequent en gecontroleerd gebeurt. Belangrijk is dat de status wordt beheerd door de ondertekenaar (in uw ondertekeningsinfrastructuur), niet door het apparaat, waardoor er geen extra complexiteit aan de hardware wordt toegevoegd. Een capabel ondertekeningsplatform verzorgt deze statusregistratie automatisch.

De planning van CNSA 2.0 voor het ondertekenen van software en firmware is om vanaf 2025 de voorkeur te geven aan kwantumveilige algoritmen en deze vanaf 2030 exclusief te gebruiken. Dit is de meest ambitieuze categorie binnen de hele reeks, juist omdat firmware na implementatie zo moeilijk te wijzigen is.

Firmware-ondertekening in IoT, embedded systemen en de automobielindustrie

Het ondertekenen van firmware is met name belangrijk wanneer apparaten talrijk, langdurig en moeilijk bereikbaar zijn. In het Internet of Things vormen niet-ondertekende firmware-updates een belangrijk aanvalspunt voor het bouwen van botnets en het verkrijgen van persistentie.

In de automobielindustrie vereisen regelgeving zoals UNECE R155 en normen zoals ISO/SAE 21434 dat bedreigingen door firmware-aanpassingen worden beperkt, en voertuigen die vandaag worden gebouwd, zullen tot in de jaren 2040 op de weg blijven. Bij industriële en medische apparaten kan een inbreuk op de firmware niet alleen gevolgen hebben voor de gegevensbeveiliging, maar ook voor de veiligheid.

Wat deze domeinen gemeen hebben, is de combinatie die firmware-ondertekening onmisbaar maakt: beperkte hardware die handtekeningen efficiënt moet verifiëren, een zeer lange levensduur die langer meegaat dan cryptografische aannames, en een toeleveringsketen die meerdere organisaties omvat voordat een apparaat in gebruik wordt genomen. Het correct uitvoeren van firmware-ondertekening en het bijbehorende sleutelbeheer vormt de basis voor alle andere aspecten van apparaatbeveiliging.

Hoe encryptieconsultancy kan helpen

CodeSign Secure van Encryption Consulting is speciaal ontwikkeld voor dit probleem. Het bewaart de ondertekeningssleutels van de firmware in een FIPS 140-2 Level 2 HSM, zodat de privésleutel de hardware nooit verlaat. Daarnaast wordt vastgelegd wie bevoegd is om te ondertekenen en wordt elke ondertekeningshandeling geregistreerd voor controledoeleinden bij al uw leveranciers en in uw buildsystemen.

Het integreert ondertekening in CI/CD-pipelines, waardoor firmware automatisch wordt ondertekend met hardwarematig beveiligde sleutels. Het ondersteunt hash-gebaseerde en post-quantum-ondertekeningsschema's die steeds vaker vereist zijn voor firmwareondertekening, inclusief het stateful state management dat LMS en XMSS vereisen. Het resultaat is één gereguleerd ondertekeningsproces voor firmware, secure-boot-ketens en de rest van uw codeondertekening. Gecertificeerd volgens ISO/IEC 27001:2022 en SOC 2-normen.

Veelgestelde Vragen / FAQ

Wat is firmwareondertekening?

Firmware-ondertekening is het proces waarbij een cryptografische handtekening aan firmware wordt toegevoegd, zodat een apparaat, voordat het de firmware uitvoert, kan controleren of deze afkomstig is van een vertrouwde bron en niet is gewijzigd. Het apparaat beschikt over een vertrouwde publieke sleutel, vaak ingebouwd in de hardware, en vergelijkt de handtekening van de firmware hiermee. Als de handtekeningen niet overeenkomen, weigert het apparaat de firmware uit te voeren, waardoor aanvallers geen kwaadaardige code op het laagste niveau van het systeem kunnen installeren.

Wat is het verschil tussen firmware-ondertekening en beveiligd opstarten?

Firmwareondertekening is het proces waarbij de digitale handtekening wordt gegenereerd; secure boot is het runtime-proces dat deze verifieert. Wanneer firmware wordt gecompileerd, wordt deze ondertekend met een privésleutel. Bij het inschakelen controleert secure boot elke fase van de opstartketen aan de hand van een vertrouwde publieke sleutel voordat deze wordt uitgevoerd, beginnend bij een onveranderlijke hardware-root. Firmwareondertekening levert de handtekeningen en secure boot handhaaft deze, zodat de twee samenwerken om te voorkomen dat ongeautoriseerde firmware ooit wordt uitgevoerd.

Waarom moeten de ondertekeningssleutels van de firmware in een HSM worden opgeslagen?

Een gestolen firmware-ondertekeningssleutel is catastrofaal en vaak onherstelbaar. Een aanvaller met de sleutel kan kwaadaardige firmware ondertekenen die door elk apparaat dat die sleutel vertrouwt, wordt geaccepteerd. Omdat de verificatiesleutel vaak in de hardware is vastgelegd, is er mogelijk geen manier om deze op reeds in gebruik genomen apparaten in te trekken. Door de privésleutel in een hardwarebeveiligingsmodule op te slaan, verlaat deze nooit de fraudebestendige hardware, waardoor zelfs een volledig gecompromitteerd buildsysteem de sleutel niet kan stelen.

Welke algoritmes moet ik gebruiken voor het ondertekenen van firmware na de quantum-implementatie?

Voor kwantumveilige firmwareondertekening zijn de beschikbare opties de stateful hash-gebaseerde schema's LMS en XMSS, gestandaardiseerd in NIST SP 800-208 en goedgekeurd onder CNSA 2.0. SLH-DSA (FIPS 205) is een stateless hash-gebaseerd alternatief dat in augustus 2024 is afgerond. Hash-gebaseerde schema's hebben vaak de voorkeur voor langdurige firmware-roots omdat hun beveiliging alleen berust op goed begrepen hashfuncties. ML-DSA (FIPS 204) is de algemene, op roosters gebaseerde optie voor breder gebruik.

Waarom is het ondertekenen van firmware de hoogste prioriteit voor de overgang naar het post-kwantumtijdperk?

Omdat firmware het moeilijkst te wijzigen is na de implementatie. In veel apparaten is het algoritme voor handtekeningverificatie vastgelegd in onveranderlijke hardware of opstartcode. Als het dus RSA of ECDSA gebruikt, zou een toekomstige kwantumcomputer firmwarehandtekeningen kunnen vervalsen zonder dat het algoritme op reeds in gebruik zijnde apparaten kan worden bijgewerkt. De NSA's CNSA 2.0-richtlijnen noemen het ondertekenen van firmware de belangrijkste toepassing voor handtekeningen en stellen de meest ambitieuze tijdlijn vast: exclusief kwantumveilig gebruik tegen 2030.

Wat zijn de aandachtspunten voor het beheer van de status van LMS en XMSS?

LMS en XMSS zijn stateful hash-gebaseerde handtekeningen: elke privésleutel kan slechts een vast aantal handtekeningen genereren en de ondertekenaar moet bijhouden welke eenmalige sleutels zijn gebruikt, omdat hergebruik de beveiliging in gevaar brengt. Dit maakt ze ongeschikt voor frequente ondertekening, maar zeer geschikt voor incidentele, gecontroleerde firmware-ondertekening. De status wordt beheerd door de ondertekeningsinfrastructuur, niet door het apparaat, waardoor er geen extra complexiteit aan de hardware wordt toegevoegd. Een capabel ondertekeningsplatform houdt deze status automatisch bij.

Firmware ondertekenen met hardwarebeveiligde sleutels

De beveiliging van firmware-ondertekening hangt volledig af van de bescherming van de sleutels, en de risico's zijn groter dan bij elk ander ondertekeningsscenario. Ontdek CodeSign Secure voor het ondertekenen van firmware en secure-boot-images met HSM-beveiligde sleutels, met ondersteuning voor post-quantum-algoritmen en volledige auditmogelijkheden in uw gehele toeleveringsketen.