Een framework voor firmwareondertekening opzetten voor naleving van de CRA-regelgeving.

Om te begrijpen waarom het ondertekenen van firmware belangrijk is, is het nuttig om te beginnen met de firmware zelf. Met de snelle groei van verbonden apparaten en embedded systemen is firmware uitgegroeid tot een van de meest kritieke, maar vaak over het hoofd geziene aanvalsoppervlakken in de moderne cybersecurity. Firmware opereert onder het besturingssysteem en de applicatielaag en bestuurt in stilte de hardware die alles aandrijft, van industriële systemen en medische apparaten tot IoT-producten voor consumenten en automotive platforms.

De meeste gebruikers staan ​​er zelden bij stil, ontwikkelaars besteden er na de implementatie vaak geen aandacht meer aan en beveiligingsteams hebben zich traditioneel meer gericht op bedreigingen op software- en netwerkniveau. Wanneer de firmware echter gecompromitteerd raakt, kunnen de gevolgen ernstig zijn en kunnen aanvallers permanente toegang verkrijgen, beveiligingsmaatregelen omzeilen of apparaten op het meest fundamentele niveau manipuleren.

De Europese Unie erkende deze toenemende risico's en introduceerde daarom de Cyber ​​Resilience Act (CRA) , Verordening (EU) 2024/2847, die op 10 december 2024 in werking trad. Deze verordening stelt verplichte cybersecurity-eisen vast voor producten met digitale elementen die op de EU-markt worden gebracht, met een sterke nadruk op veilige ontwikkelingspraktijken, kwetsbaarheidsbeheer en bescherming tegen ongeautoriseerde softwarewijzigingen. Een van de belangrijkste eisen is de noodzaak van cryptografisch verifieerbare firmware-integriteit, die ervoor zorgt dat alleen vertrouwde en geauthenticeerde firmware op apparaten kan worden geïnstalleerd en uitgevoerd.

De CRA is echter niet van toepassing op elk apparaat dat firmware bevat. Volgens artikel 2(1) is de CRA alleen van toepassing op producten met digitale elementen waarvan het beoogde doel of het redelijkerwijs te verwachten gebruik een directe of indirecte logische of fysieke dataverbinding met een apparaat of netwerk omvat. Bijgevolg kan firmware in echt zelfstandige, niet-verbonden ("offline") producten zonder beoogde of redelijkerwijs te verwachten dataverbinding buiten het toepassingsgebied vallen. Hoewel volledige naleving van de CRA verplicht wordt vanaf 11 december 2027, beginnen de meldingsverplichtingen voor kwetsbaarheden veel eerder, namelijk vanaf 11 september 2026.

Om aan deze eisen te voldoen, moeten organisaties verder kijken dan traditionele softwarebeveiligingsmethoden en robuuste firmwarebeveiligingsmechanismen implementeren gedurende de gehele productlevenscyclus. Een van de belangrijkste controles in dit proces is firmwareondertekening, een cryptografisch mechanisme dat de authenticiteit en integriteit van firmware verifieert voordat deze wordt geïnstalleerd of uitgevoerd. Een veilig framework voor firmwareondertekening beschermt apparaten niet alleen tegen ongeautoriseerde of kwaadaardige code, maar versterkt ook de beveiliging van de toeleveringsketen , ondersteunt veilige updateprocessen en helpt organisaties bij het aantonen van naleving van de regelgeving.

In deze blog onderzoeken we hoe organisaties een veilig, schaalbaar en CRA-conform framework voor firmwareondertekening kunnen ontwerpen en implementeren. We bespreken daarbij de fundamentele technologieën, operationele overwegingen en best practices die nodig zijn om moderne embedded systemen te beschermen.

Firmwareondertekening en de noodzaak ervan

Firmware is de software op laag niveau die is ingebed in een hardwareapparaat en die bepaalt hoe het apparaat werkt en communiceert met zijn hardwarecomponenten. In tegenstelling tot reguliere softwareapplicaties werkt firmware dicht bij de hardwarelaag en is verantwoordelijk voor essentiële functies zoals apparaatinitialisatie, opstartprocessen, hardwarecommunicatie, geheugenbeheer en systeemwerking. Het is aanwezig in vrijwel elk modern verbonden apparaat, waaronder IoT-apparaten, industriële besturingssystemen, ECU's in auto's, routers, smartphones, medische apparatuur en consumentenelektronica. Omdat firmware op zo'n fundamenteel niveau werkt, kan elke inbreuk daarin aanvallers diepgaande en permanente controle over het apparaat geven.

Firmware-ondertekening is een beveiligingsmechanisme dat ervoor zorgt dat alleen vertrouwde en authentieke firmware op een apparaat kan worden geïnstalleerd of uitgevoerd. Hierbij wordt het firmwarebestand digitaal ondertekend met een cryptografische privésleutel die wordt beheerd door de fabrikant of een vertrouwde instantie. De bijbehorende publieke sleutel is veilig ingebed in het apparaat, vaak als onderdeel van het beveiligde opstartproces . Telkens wanneer firmware wordt geïnstalleerd, bijgewerkt of geladen tijdens het opstarten, controleert het apparaat de digitale handtekening voordat deze wordt uitgevoerd. Als de validatie van de handtekening mislukt of als de firmware is gemanipuleerd, wordt de firmware onmiddellijk geweigerd, waardoor wordt voorkomen dat ongeautoriseerde of kwaadaardige firmware wordt uitgevoerd.

Firmwareondertekening speelt een cruciale rol bij de bescherming van apparaten tegen manipulatie van de firmware, aanvallen in de toeleveringsketen, kwaadwillige updates en ongeautoriseerde wijzigingen. Het schept vertrouwen tussen de fabrikant en het apparaat en waarborgt de integriteit van de firmware gedurende de gehele levenscyclus van het product. Nu cyberdreigingen gericht op embedded systemen blijven toenemen, is firmwareondertekening een fundamentele beveiligingsvereiste geworden voor moderne verbonden apparaten en een belangrijke compliance-maatregel onder regelgeving zoals de EU Cyber ​​Resilience Act (CRA).

Wat NIST aanbeveelt voor het ondertekenen van firmware

De CRA stelt de wettelijke verplichtingen vast, maar blijft bewust technologie-neutraal en schrijft niet de exacte cryptografische mechanismen voor die organisaties moeten gebruiken. Om een ​​vereiste zoals "bescherming tegen ongeoorloofde wijziging" te vertalen naar concrete technische beheersmaatregelen, wenden de meeste organisaties zich tot het National Institute of Standards and Technology (NIST), waarvan de publicaties de de facto wereldwijde referentie zijn geworden voor de integriteit van firmware. Verschillende NIST-documenten sluiten direct aan op het probleem van firmware-ondertekening.

NIST SP 800-147 en SP 800-147B (BIOS-beveiligingsrichtlijnen): SP 800-147 (2011) richt zich op clientplatformen zoals desktops en laptops, terwijl SP 800-147B (2014) dezelfde principes uitbreidt naar serversystemen, een onderscheid in reikwijdte dat relevant is voor inkopers. Deze richtlijnen stellen het fundamentele principe vast dat firmware-updates moeten worden geverifieerd met digitale handtekeningen voordat ze worden toegepast. Ze introduceren de Root of Trust for Update (RTU), een onveranderlijke verificatiecomponent die in de hardware is verankerd en de logica voor handtekeningverificatie en de vertrouwde publieke sleutel bevat. Een update-image wordt alleen geïnstalleerd als de handtekening ervan overeenkomt met een sleutel in de RTU. De richtlijnen vereisen tevens bescherming tegen terugdraaien naar eerdere, kwetsbare versies.

NIST SP 800-193 (Richtlijnen voor de veerkracht van platformfirmware): Deze richtlijn verbreedt de reikwijdte van alleen het BIOS naar alle platformfirmware en kritieke gegevens, en organiseert de controles rond drie principes: Bescherming (authentiseren van firmware-updates met digitale handtekeningen en beveiligen van kritieke gegevens), Detectie (identificeren van ongeautoriseerde of beschadigde firmware voordat deze wordt uitgevoerd) en Herstel (herstellen van de firmware naar een bekende, goede staat na beschadiging). Dit beschermings-, detectie- en herstelmodel is een nuttig blauwdruk voor de CRA (Configuration Regulatory Authority), die integriteit verwacht, niet alleen tijdens de installatie, maar gedurende de gehele ondersteunde levensduur van het product.

FIPS 186-5 en FIPS 140-3: FIPS 186-5, de Digital Signature Standard, specificeert de goedgekeurde handtekeningalgoritmen (zoals ECDSA, RSA en EdDSA) die worden gebruikt om firmwarehandtekeningen te genereren, terwijl FIPS 140-3 de beveiligingsvereisten definieert voor de cryptografische modules, doorgaans Hardware Security Modules (HSM's), die ondertekeningssleutels beschermen. Het is belangrijk op te merken dat het oude Digital Signature Algorithm (DSA) niet langer is goedgekeurd voor het genereren van nieuwe handtekeningen onder FIPS 186-5 en alleen nog wordt gebruikt voor het verifiëren van bestaande handtekeningen. FIPS 186-5 stelt ook dat de algoritmen in de standaard naar verwachting niet bestand zullen zijn tegen aanvallen van een grootschalige kwantumcomputer, wat kan worden gezien als een reden waarom de onderstaande hash-gebaseerde en lattice-gebaseerde schema's van belang zijn voor firmware met een lange levensduur.

NIST SP 800-57 en SP 800-89: SP 800-57 regelt hoe ondertekeningssleutels worden gegenereerd, opgeslagen, geroteerd en buiten gebruik gesteld gedurende hun levenscyclus, terwijl SP 800-89 aanbevelingen geeft voor het verkrijgen van zekerheid dat digitale handtekeningen geldig en betrouwbaar zijn.

NIST SP 800-208 (Stateful Hash-Based Signature Schemes): SP 800-208 keurt twee stateful hash-gebaseerde ondertekeningsschema's goed voor het ondertekenen van firmware en software, LMS en XMSS (samen met hun multi-tree varianten HSS en XMSSMT), waarvan de beveiliging uitsluitend berust op cryptografische hashfuncties. Omdat de schema's stateful zijn, mag elke eenmalige sleutel slechts één keer worden gebruikt, waardoor de ondertekenaar de ondertekeningsstatus nooit mag hergebruiken of terugdraaien. Als die status verloren gaat of wordt teruggedraaid, bijvoorbeeld door een stroomstoring, het klonen van een virtuele machine of een herstel vanuit een back-up, kan een hergebruikte sleutel worden misbruikt om handtekeningen te vervalsen en de beveiliging van de sleutel in gevaar te brengen.

Om deze reden beveelt SP 800-208 niet alleen hardwarebeveiliging aan; het vereist dat de sleutel- en handtekeninggeneratie plaatsvindt binnen een FIPS 140-2 of 140-3 Level 3 (of hoger) hardwaremodule die nooit privé-sleutelmateriaal exporteert. Organisaties moeten daarom crash-consistent statusbeheer en gevalideerde HSM-ondersteuning controleren voordat ze LMS of XMSS implementeren.

FIPS 204 & FIPS 205 (Stateless Post-Quantum Signature Schemes): Organisaties die nieuwe firmware-ondertekening plannen, zouden ook de twee stateless post-quantum standaarden moeten overwegen die NIST in augustus 2024 heeft afgerond: FIPS 204 ( ML-DSA ) en FIPS 205 (SLH-DSA). Omdat ze stateless zijn, vermijden ze het eenmalige sleutelbeheer dat LMS en XMSS vereisen, wat gedistribueerde ondertekening en ondertekening op grote schaal vereenvoudigt. ML-DSA, een op roosters gebaseerd schema, is een sterke algemene standaard vanwege de balans tussen snelheid en handtekeninggrootte, terwijl SLH-DSA, afgeleid van SPHINCS+, de meer conservatieve optie is voor teams die de beveiliging volledig willen laten rusten op hashfuncties.

Wat firmware betreft, houd er rekening mee dat de NSA's CNSA 2.0 nog steeds de stateful SP 800-208-schema's (LMS en XMSS) aanwijst als de voorkeursmethode voor de nabije toekomst. Laat uw compliance-context dus leidend zijn bij uw beslissing. Welk schema u ook kiest, blijf sleutels ondertekenen in FIPS 140-3 gevalideerde cryptografische modules, aangezien de FIPS 140-2-validaties op 21 september 2026 vervallen.

Samengevat bieden deze publicaties fabrikanten een verdedigbaar, op standaarden gebaseerd antwoord op de integriteitseis van de CRA: firmware ondertekenen met goedgekeurde algoritmen, de sleutels beschermen in gecertificeerde hardware, handtekeningen verifiëren in een hardwarematig verankerde vertrouwensbasis, terugdraaien naar kwetsbare versies voorkomen en vooruit plannen voor een transitie na het kwantumtijdperk. Naast NIST wijst de Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) van de NSA in dezelfde richting voor firmware: het wijst de SP 800-208-schema's LMS en XMSS aan voor het ondertekenen van software en firmware in nationale veiligheidssystemen. Het roept op tot een onmiddellijke overgang, ondersteuning en voorkeur voor CNSA 2.0-algoritmen tegen 2025, en exclusief gebruik tegen 2030.

Implementatie van een framework voor firmwareondertekening

Het bouwen van een framework voor het ondertekenen van firmware dat voldoet aan de CRA-eisen, draait minder om het inzetten van één enkele tool en meer om het opzetten van een betrouwbare, herhaalbare en controleerbare ondertekeningspipeline. Een typische implementatie doorloopt de volgende fasen.

• Stel een hardwarematige vertrouwensbasis in. Voorzie de hardware van het apparaat van een onveranderlijke openbare sleutel (of de hash daarvan) in een eenmalig programmeerbaar geheugen of een beveiligd element, zodat het apparaat handtekeningen kan verifiëren tijdens het veilig opstarten en voordat updates worden geaccepteerd.
• Genereer en bescherm ondertekeningssleutels in een HSMMaak de privésleutels voor ondertekening aan in een FIPS 140-2 of 140-3 Level 3 HSM, zodat sleutelmateriaal nooit in platte tekst wordt blootgesteld of wordt opgeslagen op buildservers en ontwikkelmachines.
• Definieer het ondertekeningsproces en de goedkeuringsworkflow. Integreer ondertekening in de build- en releasepipeline en handhaaf op rollen gebaseerde toegangscontrole met goedkeuring door meerdere partijen (M-van-N), zodat geen enkele engineer de firmware eenzijdig kan ondertekenen en uitbrengen.
• Onderteken en voorzie de firmware van een tijdstempel. Voeg de digitale handtekening toe aan de firmware-image (ingebed of als een aparte handtekening) en voeg een betrouwbaar tijdstempel toe, zodat de handtekening verifieerbaar blijft, zelfs nadat het ondertekeningscertificaat is verlopen.
• Controleer dit op het apparaat. Tijdens een beveiligde opstartprocedure en vóór elke update valideert de bootloader de handtekening aan de hand van de ingebouwde publieke sleutel en wijst elke niet-ondertekende of gemanipuleerde image af. De terugdraaibeveiliging voorkomt bovendien downgrades naar kwetsbare firmwareversies.
• Zorg voor traceerbaarheid en beheer de gehele levenscyclus van het product. Registreer elke ondertekening, vervang en trek sleutels in volgens het beleid en bewaar de benodigde documenten om de naleving van de CRA-richtlijnen gedurende de levensduur van het product aan te tonen.

Een goed ontworpen framework moet ook cryptografisch flexibel zijn. Naarmate algoritmen evolueren, met name met de overgang naar post-kwantumcryptografie, moet de infrastructuur voor digitale handtekeningen nieuwe algoritmen kunnen overnemen zonder dat de hele pipeline opnieuw hoeft te worden ontworpen. Dit goed aanpakken is niet alleen een kwestie van degelijke engineering; inzicht in de financiële belangen onderstreept waarom een ​​tijdige implementatie zo urgent is.

Sancties voor niet-naleving

De CRA onderbouwt haar eisen met aanzienlijke financiële en operationele consequenties, die sterk lijken op de aanpak van de AVG waarbij het hoogste bedrag van een vast bedrag of een percentage van de wereldwijde omzet wordt gehanteerd. Volgens artikel 64 zijn de sancties getrapt naar de ernst van de overtreding.

Type overtreding	Maximale boete	Omzetlimiet (de hoogste van de twee)
Schending van essentiële cybersecurity-vereisten (bijlage I) of kernverplichtingen van de fabrikant (artikelen 13 en 14) — omvat zwakke of ontbrekende firmware-integriteit	€ 15 miljoen euro	2.5% van de totale wereldwijde jaaromzet
Schending van andere verplichtingen (conformiteitsbeoordeling, technische documentatie, importeurs-/distributeursplichten)	€ 10 miljoen euro	2% van de wereldwijde jaaromzet
Het verstrekken van onjuiste, onvolledige of misleidende informatie aan aangemelde instanties of markttoezichtautoriteiten.	€ 5 miljoen euro	1% van de wereldwijde jaaromzet

Boetes zijn niet het enige risico. Markttoezichthouders kunnen een niet-conform product bevelen om volledig van de EU-markt te worden teruggetrokken of teruggeroepen, waardoor de toegang tot een interne markt van ongeveer 450 miljoen consumenten wordt afgesneden. De tijdlijn is al in gang gezet: de verplichting om actief misbruikte kwetsbaarheden en ernstige incidenten te melden aan ENISA en nationale CSIRT's gaat in op 11 september 2026, terwijl volledige naleving verplicht wordt op 11 december 2027. Voor fabrikanten zijn de kosten voor het opzetten van een degelijk firmware-ondertekeningsprogramma bescheiden in vergelijking met de financiële, juridische en reputatieschade die het niet-naleven met zich meebrengt.

Veelvoorkomende uitdagingen bij het ondertekenen van firmware

Zelfs organisaties die het belang van firmware-ondertekening inzien, worstelen vaak met de praktische uitvoering ervan, met name op grote schaal. Veelvoorkomende uitdagingen zijn onder andere de volgende.

• Bescherming van ondertekeningssleutels. Een gelekte of gestolen privésleutel stelt een aanvaller in staat om kwaadaardige firmware te ondertekenen die vervolgens door elk apparaat volledig wordt vertrouwd. Sleutels die zijn opgeslagen in software, op buildservers of op laptops van ontwikkelaars vormen een veelvoorkomend zwak punt.
• Beperkte apparaatbronnen. Veel embedded en IoT-apparaten hebben beperkt geheugen, verwerkingskracht en opslagcapaciteit, waardoor het verifiëren van handtekeningen en het ondersteunen van grotere post-kwantumhandtekeningen technisch lastig is.
• Het beheren van sleutels gedurende een lange levenscyclus. Firmware moet mogelijk tien jaar of langer opnieuw worden ondertekend en geverifieerd, wat zorgvuldige sleutelrotatie, intrekking en bescherming tegen terugdraaien vereist om te voorkomen dat apparaten die al in gebruik zijn onbruikbaar worden.
• Gedecentraliseerde en handmatige ondertekening. Ad-hoc ondertekeningsscripts en sleutels verspreid over verschillende teams zorgen voor inconsistentie, zwakke controlemogelijkheden en nalevingslacunes die achteraf moeilijk te dichten zijn.
• Beveiligde provisioning in de gehele toeleveringsketen. Het inbedden van de juiste vertrouwensankers in apparaten tijdens de productie, vaak in gedistribueerde wereldwijde toeleveringsketens, is operationeel complex en veiligheidsgevoelig.
• Voorbereiding op post-kwantumcryptografie. Het selecteren van kwantumresistente algoritmen zoals LMS of XMSS en het beheren van hun stateful eenmalige sleutelvereisten voegt complexiteit toe waarvoor traditionele ondertekeningssoftware nooit is ontworpen.

Beste werkwijzen voor het ondertekenen van firmware

Om een ​​veilig en aan de CRA-richtlijnen voldoend framework voor firmwareondertekening op te zetten, dienen organisaties de volgende best practices te volgen.

• Bewaar alle ondertekeningssleutels in FIPS 140-2 of 140-3 Level 3 gecertificeerde HSM's en zorg ervoor dat privésleutels binnen de module worden gegenereerd en nooit worden geëxporteerd.
• Veranker de verificatie in een hardwarematige vertrouwensbasis en dwing een veilige opstartprocedure af, zodat alleen ondertekende, ongewijzigde firmware wordt uitgevoerd.
• Gebruik door NIST goedgekeurde handtekeningalgoritmen met de juiste sleutellengtes en pas betrouwbare tijdstempels toe, zodat handtekeningen geldig blijven na het verlopen van het certificaat.
• Handhaaf het principe van minimale bevoegdheden door middel van op rollen gebaseerde toegangscontrole en vereis goedkeuring door meerdere partijen (M-van-N) voor ondertekeningshandelingen.
• Automatiseer het ondertekenen binnen de CI/CD-pijplijn Om handmatige sleutelverwerking te elimineren en menselijke fouten te verminderen.
• Implementeer rollback-beveiliging om downgrade-aanvallen te blokkeren die oudere, kwetsbare firmware opnieuw introduceren.
• Houd uitgebreide, fraudebestendige auditlogboeken bij van elke ondertekening om te voldoen aan de CRA-richtlijnen en om incidenten af ​​te handelen.
• Bouw met het oog op cryptografische flexibiliteit en begin nu al met de planning voor de overgang naar post-kwantumalgoritmen, gezien de lange levensduur van de meeste firmware.

Hoe encryptieconsultancy kan helpen

Het ontwerpen, implementeren en beheren van een framework voor firmwareondertekening dat bestand is tegen reële bedreigingen en voldoet aan de CRA-vereisten, vereist diepgaande expertise in toegepaste cryptografie, PKI en sleutelbeheer. Hier kan Encryption Consulting u bij helpen.

Ons codeondertekeningsplatform, CodeSign Secure , biedt een gecentraliseerde, op beleid gebaseerde oplossing voor het ondertekenen van firmwarebestanden, samen met alle andere softwareartefacten. Privésleutels voor ondertekening worden gegenereerd en opgeslagen in FIPS 140-2 Level 3 gecertificeerde HSM's en verlaten de module nooit; alleen de hash van het artefact wordt verzonden voor ondertekening, nooit de firmware-image of de privésleutel zelf. CodeSign Secure integreert met toonaangevende HSM's, waaronder Thales Luna , Entrust nCipher , Utimaco en Securosys , evenals cloud-HSM's, en handhaaft een sterk beheersysteem door middel van op rollen gebaseerde toegangscontrole, M-van-N-quorumgoedkeuringen, veilige tijdstempels en volledige audit trails. Omdat het direct aansluit op bestaande CI/CD-pipelines, wordt ondertekening geautomatiseerd en consistent in plaats van handmatig en foutgevoelig.

Cruciaal voor firmware met een lange levensduur is dat CodeSign Secure standaard ondersteuning biedt voor post-quantum cryptografie, waaronder ML-DSA en het NIST SP 800-208 stateful hash-gebaseerde schema LMS. Organisaties kunnen daardoor direct beginnen met het ondertekenen van firmware met quantumresistente algoritmen. Naast het platform helpen onze PKI-, HSM-, PQC-advies- en compliance-diensten organisaties bij het beoordelen van hun huidige cryptografische status, het ontwerpen van een op standaarden gebaseerde ondertekeningsarchitectuur en het creëren van een verdedigbaar pad naar CRA-compliance.

Conclusie

Firmware vormt de basis van elk verbonden apparaat, en een inbreuk op dat niveau kan ongemerkt alle daarboven gebouwde beveiligingsmaatregelen ondermijnen. De EU-verordening inzake cyberveiligheid heeft de integriteit van firmware van een optionele beveiliging tot een wettelijke verplichting gemaakt, en de richtlijnen van NIST bieden een duidelijke en verdedigbare routekaart om hieraan te voldoen.

Door firmware te ondertekenen met goedgekeurde algoritmen, sleutels te beschermen in gecertificeerde hardware, handtekeningen te verifiëren in een hardwarematige vertrouwensbasis en te plannen voor de post-kwantumtoekomst, kunnen organisaties hun apparaten beschermen, hun toeleveringsketens beveiligen en ruim voor de deadline van 2027 van de CRA aantonen dat ze aan de regelgeving voldoen. De fabrikanten die firmwareondertekening vandaag de dag als een eersteklas beveiligingsfunctie beschouwen, zullen het best gepositioneerd zijn om het vertrouwen van klanten te winnen en kostbare boetes te voorkomen.