Upprätta ett ramverk för firmwaresignering för efterlevnad av kreditvärderingsregler

För att förstå varför signering av firmware är viktigt är det bra att börja med själva firmware. Med den snabba tillväxten av uppkopplade enheter och inbyggda system har firmware framstått som en av de mest kritiska men ofta förbisedda attackytorna inom modern cybersäkerhet. Software, som verkar under operativsystem- och applikationslagret, styr i tysthet hårdvaran som driver allt från industriella system och medicintekniska produkter till konsumentprodukter för IoT och fordonsplattformar.

De flesta användare tänker sällan på det, utvecklare slutar ofta att återvända till det efter driftsättning, och säkerhetsteam har traditionellt fokuserat mer på hot på programvaru- och nätverksnivå. Men när firmware komprometteras kan effekten vara allvarlig samtidigt som angripare kan få permanent åtkomst, kringgå säkerhetskontroller eller manipulera enheter på deras mest grundläggande nivå.

I erkännande av dessa växande risker införde Europeiska unionen Cyber ​​Resilience Act (CRA) , förordning (EU) 2024/2847, som trädde i kraft den 10 december 2024. Förordningen fastställer obligatoriska cybersäkerhetskrav för produkter med digitala element som släpps ut på EU-marknaden, med stark betoning på säkra utvecklingsmetoder, sårbarhetshantering och skydd mot obehöriga programvaruändringar. Bland dess viktigaste krav finns behovet av kryptografiskt verifierbar firmwareintegritet, vilket säkerställer att endast betrodd och autentiserad firmware kan distribueras och köras på enheter.

CRA täcker dock inte alla enheter som innehåller firmware. Enligt artikel 2(1) gäller den endast produkter med digitala element vars avsedda syfte eller rimligen förutsebara användning inkluderar en direkt eller indirekt logisk eller fysisk dataanslutning till en enhet eller ett nätverk. Följaktligen kan firmware i genuint fristående, icke-anslutna ("offline") produkter utan avsedd eller rimligen förutsebar dataanslutning falla utanför dess tillämpningsområde. Medan fullständig efterlevnad av CRA blir obligatorisk senast den 11 december 2027, kommer skyldigheterna att rapportera sårbarheter att börja mycket tidigare, från och med den 11 september 2026.

För att uppfylla dessa krav måste organisationer gå bortom traditionella metoder för programvarusäkerhet och etablera starka skyddsmekanismer för firmware under hela produktens livscykel. En av de viktigaste kontrollerna i denna process är firmwaresignering, en kryptografisk mekanism som hjälper till att verifiera äktheten och integriteten hos firmware innan den installeras eller körs. Ett säkert ramverk för firmwaresignering skyddar inte bara enheter från obehörig eller skadlig kod utan stärker också leveranskedjans säkerhet , stöder säkra uppdateringsmekanismer och hjälper organisationer att visa efterlevnad av regelverk.

I den här bloggen utforskar vi hur organisationer kan utforma och implementera ett säkert, skalbart och CRA-anpassat ramverk för firmwaresignering, inklusive grundläggande tekniker, operativa överväganden och bästa praxis som krävs för att skydda moderna inbyggda system.

Firmware-signering och dess behov

Firmware är den lågnivåprogramvara som är inbäddad i en hårdvaruenhet och som styr hur enheten fungerar och kommunicerar med dess hårdvarukomponenter. Till skillnad från vanliga programvaruapplikationer arbetar firmware nära hårdvarulagret och ansvarar för viktiga funktioner som enhetsinitiering, startprocesser, hårdvarukommunikation, minneskontroll och systemdrift. Den finns i nästan alla moderna anslutna enheter, inklusive IoT-enheter, industriella styrsystem, fordonsstyrenheter, routrar, smartphones, sjukvårdsutrustning och konsumentelektronik. Eftersom firmware fungerar på en så grundläggande nivå kan varje kompromiss inom den ge angripare djupgående och ihållande kontroll över enheten.

Firmware-signering är en säkerhetsmekanism som används för att säkerställa att endast betrodd och autentisk firmware kan installeras eller köras på en enhet. I den här processen signeras den binära firmwarefilen digitalt med en kryptografisk privat nyckel som kontrolleras av tillverkaren eller en betrodd myndighet. Motsvarande publika nyckel är säkert inbäddad i enheten, ofta som en del av den säkra startprocessen. Närhelst firmware installeras, uppdateras eller laddas under start verifierar enheten den digitala signaturen innan körning. Om signaturvalideringen misslyckas eller om firmware har manipulerats, avvisar enheten omedelbart firmware, vilket förhindrar att obehörig eller skadlig firmware körs.

Firmware-signering spelar en avgörande roll för att skydda enheter från manipulering av firmware, attacker i leveranskedjan, skadliga uppdateringar och obehöriga modifieringar. Det skapar förtroende mellan tillverkaren och enheten och säkerställer firmware-integritet under hela produktens livscykel. I takt med att cyberhot mot inbyggda system fortsätter att öka har firmware-signering blivit ett grundläggande säkerhetskrav för moderna uppkopplade enheter och en viktig efterlevnadsåtgärd enligt regler som EU:s Cyber ​​Resilience Act (CRA).

Vad NIST rekommenderar för firmwaresignering

CRA fastställer den regulatoriska skyldigheten, men den förblir medvetet teknikneutral och föreskriver inte exakt vilka kryptografiska mekanismer organisationer måste använda. För att översätta ett krav som "skydda mot obehörig modifiering" till konkreta tekniska kontroller vänder sig de flesta organisationer till National Institute of Standards and Technology (NIST), vars publikationer har blivit den de facto globala referensen för firmwareintegritet. Flera NIST-dokument kartlägger direkt problemet med firmwaresignering.

NIST SP 800-147 och SP 800-147B (BIOS Protection Guidelines): SP 800-147 (2011) riktar sig till klientplattformar som stationära och bärbara datorer, medan SP 800-147B (2014) utvidgar samma principer till serverklasssystem, en skillnad i omfattning som en upphandlingspublik behöver. Dessa etablerar den grundläggande principen att firmwareuppdateringar måste autentiseras med digitala signaturer innan de tillämpas. De introducerar RTU (Root of Trust for Update), en oföränderlig verifieringskomponent förankrad i hårdvara som innehåller signaturverifieringslogiken och den betrodda publika nyckeln. En uppdateringsavbildning installeras endast om dess signatur verifieras mot en nyckel i RTU:n, och riktlinjerna kräver också skydd mot återställning till tidigare, sårbara versioner.

NIST SP 800-193 (Riktlinjer för plattformsfirmwaremotståndskraft): Detta breddar omfattningen från enbart BIOS till all plattformsfirmware och kritiska data, och organiserar kontroller kring tre principer: Skydd (autentisera firmwareuppdateringar med digitala signaturer och skydda kritiska data), Detektering (identifiera obehörig eller skadad firmware innan den körs) och Återställning (återställ firmware till ett känt bra tillstånd efter korruption). Denna skydd-detektering-återställningsmodell är en användbar ritning för CRA, som förväntar sig integritet inte bara vid installationstillfället utan under hela produktens stödda livslängd.

FIPS 186-5 och FIPS 140-3: FIPS 186-5, standarden för digitala signaturer, specificerar de godkända signaturalgoritmerna (som ECDSA, RSA och EdDSA) som används för att generera firmwaresignaturer, medan FIPS 140-3 definierar säkerhetskraven för de kryptografiska moduler, vanligtvis hårdvarusäkerhetsmoduler (HSM), som skyddar signeringsnycklar. Observera att den äldre algoritmen för digitala signaturer (DSA) inte längre är godkänd för att generera nya signaturer enligt FIPS 186-5 och endast behålls för att verifiera befintliga. FIPS 186-5 anger också att algoritmerna i standarden inte förväntas motstå attacker från en storskalig kvantdator, vilket kan ses som en anledning till att de hashbaserade och gitterbaserade scheman nedan är viktiga för långlivad firmware.

NIST SP 800-57 och SP 800-89: SP 800-57 styr hur signeringsnycklar genereras, lagras, roteras och tas ur bruk under sin livscykel, medan SP 800-89 ger rekommendationer för att säkerställa att digitala signaturer är giltiga och tillförlitliga.

NIST SP 800-208 (Stateful Hash-Based Signature Schemes): SP 800-208 godkänner två stateful hash-baserade signaturscheman för firmware- och programvarusignering, LMS och XMSS (tillsammans med deras flerträdsvarianter HSS och XMSSMT), vars säkerhet enbart vilar på kryptografiska hashfunktioner. Eftersom schemana är stateful får varje engångsnyckel endast användas en gång, så signeraren får aldrig återanvända eller återställa sitt signeringstillstånd. Om det tillståndet förloras eller spolas tillbaka, till exempel genom strömavbrott, kloning av virtuell maskin eller en återställning från säkerhetskopia, kan en återanvänd nyckel utnyttjas för att förfalska signaturer och äventyra nyckelns säkerhet.

Av denna anledning rekommenderar SP 800-208 inte bara hårdvaruskydd; den kräver att nyckel- och signaturgenerering utförs inuti en FIPS 140-2- eller 140-3 nivå 3 (eller högre) hårdvarumodul som aldrig exporterar privat nyckelmaterial. Organisationer bör därför bekräfta kraschkonsekvent tillståndshantering och validerat HSM-stöd innan de inför LMS eller XMSS.

FIPS 204 och FIPS 205 (Stateless Post-Quantum Signature Schemes): Organisationer som planerar ny firmware-signering bör också väga in de två statslösa post-quantum-standarderna som NIST slutförde i augusti 2024: FIPS 204 ( ML-DSA ) och FIPS 205 (SLH-DSA). Eftersom de är statslösa undviker de den tillståndshantering med engångsnyckel som LMS och XMSS kräver, vilket förenklar distribuerad och högvolymsignering. ML-DSA, ett gitterbaserat schema, är en stark generell standard för sin balans mellan hastighet och signaturstorlek, medan SLH-DSA, härlett från SPHINCS+, är det mer konservativa alternativet för team som vill att säkerheten enbart ska vila på hashfunktioner.

Specifikt för firmware, observera att NSA:s CNSA 2.0 fortfarande anger de tillståndsfulla SP 800-208-schemana (LMS och XMSS) som sitt kortsiktiga val, så låt din efterlevnadskontext vägleda beslutet. Oavsett vilket schema du väljer, fortsätt att signera nycklar i FIPS 140-3-validerade kryptografiska moduler, eftersom FIPS 140-2-valideringar upphör att gälla den 21 september 2026.

Sammantaget ger dessa publikationer tillverkarna ett försvarbart, standardbaserat svar på CRA:s integritetskrav: signera firmware med godkända algoritmer, skydda nycklarna i certifierad hårdvara, verifiera signaturer i en hårdvaruförankrad rot av förtroende, förhindra återställning till sårbara versioner och planera i förväg för en övergång efter kvantum. Utöver NIST pekar NSA:s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) i samma riktning för firmware: den utser SP 800-208-scheman LMS och XMSS för programvaru- och firmwaresignering i nationella säkerhetssystem. Den efterlyser en omedelbar övergång, stöd och preferens för CNSA 2.0-algoritmer senast 2025, och exklusiv användning senast 2030.

Implementera ett ramverk för firmwaresignering

Att bygga ett ramverk för firmwaresignering som uppfyller CRA-kraven handlar mindre om att distribuera ett enda verktyg och mer om att etablera en pålitlig, repeterbar och granskningsbar signeringspipeline. En typisk implementering går igenom följande steg.

• Upprätta en hårdvarubaserad förtroendekälla. Tillhandahåll enhetens hårdvara med en oföränderlig offentlig nyckel (eller dess hash) i ett engångsprogrammerbart minne eller ett säkert element, så att enheten kan verifiera signaturer under säker start och innan uppdateringar accepteras.
• Generera och skydda signeringsnycklar i en HSMSkapa de privata signeringsnycklarna i en FIPS 140-2- eller 140-3 nivå 3 HSM så att nyckelmaterial aldrig exponeras i klartext eller lagras på byggservrar och utvecklarmaskiner.
• Definiera signeringsprocessen och arbetsflödet för godkännande. Integrera signering i bygg- och lanseringspipelinen och tillämpa rollbaserad åtkomstkontroll med flerpartsgodkännande (M-of-N) så att ingen enskild ingenjör kan signera och leverera firmware ensidigt.
• Signera och tidsstämpla den inbyggda programvaran. Använd den digitala signaturen på den inbyggda programvarans avbildning (inbäddad eller som en fristående signatur) och lägg till en betrodd tidsstämpel så att signaturen förblir verifierbar även efter att signeringscertifikatet har löpt ut.
• Verifiera på enheten. Under säker start och före varje uppdatering validerar bootloadern signaturen mot den inbäddade publika nyckeln och avvisar alla osignerade eller manipulerade bilder, medan återställningsskydd förhindrar nedgraderingar till sårbara firmwareversioner.
• Upprätthåll granskningsbarhet och livscykelhantering. Logga varje signeringshändelse, rotera och återkalla nycklar enligt policy och behåll de register som behövs för att visa överensstämmelse med kreditvärderingsmyndighetens krav under produktens livstid.

Ett väl utformat ramverk bör också vara kryptoagilt. I takt med att algoritmer utvecklas, särskilt med övergången mot postkvantkryptografi, bör signeringsinfrastrukturen kunna anta nya algoritmer utan att omstrukturera hela pipelinen. Att få detta rätt är inte bara god ingenjörskonst, att förstå vad som står på spel ekonomiskt förstärker varför snabb implementering är så brådskande.

Påföljder för bristande efterlevnad

Kreditvärderingsmyndigheten (CRA) stöder sina krav med betydande ekonomiska och operativa konsekvenser, nära modellerade efter GDPR:s strategi att ta ut det högsta av ett fast belopp eller en procentandel av den globala omsättningen. Enligt artikel 64 nivåeras påföljderna efter hur allvarligt brottet är.

Överträdelsetyp	Högsta böter	Omsättningstak (beroende på vilket som är högst)
Brott mot väsentliga cybersäkerhetskrav (bilaga I) eller tillverkarens centrala skyldigheter (artiklarna 13 och 14) – omfattar svag eller saknad firmwareintegritet	€ 15 euro	2.5 % av den totala globala årliga omsättningen
Brott mot andra skyldigheter (bedömning av överensstämmelse, teknisk dokumentation, importörs-/distributörsskyldigheter)	€ 10 euro	2 % av den globala årliga omsättningen
Att lämna felaktig, ofullständig eller vilseledande information till anmälda organ eller marknadskontrollmyndigheter	€ 5 euro	1 % av den globala årliga omsättningen

Böter är inte den enda risken. Marknadsövervakningsmyndigheterna kan beordra att en produkt som inte uppfyller kraven ska dras tillbaka eller återkallas helt från EU-marknaden, vilket avskär tillträdet till en inre marknad med ungefär 450 miljoner konsumenter. Tidslinjen har redan inletts: skyldigheten att rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter till Enisa och nationella CSIRT-enheter börjar den 11 september 2026, medan fullständig efterlevnad blir obligatorisk den 11 december 2027. För tillverkare är kostnaden för att bygga ett ordentligt program för firmwaresignering blygsam jämfört med de ekonomiska, juridiska och anseendemässiga kostnaderna för bristande efterlevnad.

Vanliga utmaningar vid signering av firmware

Även organisationer som förstår värdet av firmware-signering kämpar ofta med de praktiska förutsättningarna för att göra det bra, särskilt i stor skala. Vanliga utmaningar inkluderar följande.

• Skydd av signeringsnycklar. En läckt eller stulen privat nyckel låter en angripare signera skadlig firmware som alla enheter litar på helt och hållet. Nycklar som lagras i programvara, på byggservrar eller på utvecklares bärbara datorer är en vanlig felkälla.
• Begränsade enhetsresurser. Många inbyggda enheter och IoT-enheter har begränsat minne, processorkraft och lagring, vilket gör det tekniskt utmanande att verifiera signaturer och stödja större postkvantumsignaturer.
• Hantera nycklar över en lång livscykel. Firmware kan behöva signeras och verifieras på nytt i ett decennium eller mer, vilket kräver noggrant nyckelrotation, återkallelse och rollback-skydd utan att blockera enheter som redan finns i fält.
• Decentraliserad och manuell signering. Ad hoc-signeringsskript och nycklar utspridda över team skapar inkonsekvens, svaga revisionsspår och efterlevnadsluckor som är svåra att täcka i efterhand.
• Säker provisionering i hela leveranskedjan. Att bädda in rätt förtroendeankare i enheter under tillverkning, ofta över distribuerade globala leveranskedjor, är operativt komplext och säkerhetskänsligt.
• Förberedelser för postkvantkryptografi. Att välja kvantresistenta algoritmer som LMS eller XMSS och hantera deras tillståndsfulla krav på engångsnycklar ökar komplexiteten som äldre signeringsverktyg aldrig utformades för att hantera.

Bästa praxis för signering av firmware

För att etablera ett ramverk för firmware-signering som är både säkert och CRA-anpassat bör organisationer anta följande bästa praxis.

• Lagra alla signeringsnycklar i FIPS 140-2- eller 140-3 nivå 3-certifierade HSM:er och se till att privata nycklar genereras inuti modulen och aldrig exporteras.
• Förankra verifiering i en hårdvarurot av förtroende och framtvinga säker start så att endast signerad, opåverkad firmware någonsin körs.
• Använd NIST-godkända signaturalgoritmer med lämpliga nyckellängder och tillämpa betrodd tidsstämpling så att signaturer förblir giltiga även efter att certifikatet har löpt ut.
• Tillämpa minsta möjliga behörighet genom rollbaserad åtkomstkontroll och kräva godkännande från flera parter (M-of-N) för signeringsåtgärder.
• Automatisera signering inom CI/CD pipeline för att eliminera manuell nyckelhantering och minska mänskliga fel.
• Implementera rollback-skydd för att blockera nedgraderingsattacker som återinför äldre, sårbar firmware.
• Upprätthåll omfattande, manipulationssäker revisionsloggar för varje signeringshändelse för att stödja kreditvärderingsinstitutets överensstämmelse och incidenthantering.
• Bygg för kryptoagilitet och börja planera övergången till postkvantalgoritmer nu, med tanke på den långa livslängden för de flesta firmware-program.

Hur krypteringskonsulting kan hjälpa

Att designa, driftsätta och driva ett ramverk för firmwaresignering som motstår verkliga hot och uppfyller CRA-kraven kräver djupgående expertis inom tillämpad kryptografi, PKI och nyckelhantering. Det är här Encryption Consulting kan hjälpa till.

Vår kodsigneringsplattform, CodeSign Secure , tillhandahåller en centraliserad, policybaserad lösning för att signera firmwarebinärfiler tillsammans med alla typer av programvaruartefakter. Privata signeringsnycklar genereras och lagras i FIPS 140-2 nivå 3-certifierade HSM:er och lämnar aldrig modulen; endast artefakthashen överförs för signering, aldrig själva firmware-avbildningen eller den privata nyckeln. CodeSign Secure integreras med ledande HSM:er, inklusive Thales Luna , Entrust nCipher , Utimaco och Securosys , såväl som moln-HSM:er, och den upprätthåller stark styrning genom rollbaserad åtkomstkontroll, M-of-N-kvorumgodkännanden, säkra tidsstämplar och fullständiga revisionsloggar. Eftersom den ansluts direkt till befintliga CI/CD-pipelines blir signeringen automatiserad och konsekvent snarare än manuell och felbenägen.

Avgörande för långlivad firmware är att CodeSign Secure levereras med inbyggt post-quantum-stöd, inklusive ML-DSA och det stateful hash-baserade LMS-schemat NIST SP 800-208 , så att organisationer kan börja signera firmware med kvantresistenta algoritmer idag. Utöver plattformen hjälper våra PKI-, HSM-, PQC-rådgivnings- och efterlevnadstjänster organisationer att bedöma sin nuvarande kryptografiska situation, utforma en standardbaserad signeringsarkitektur och bygga en försvarbar väg till CRA-efterlevnad.

Slutsats

Firmware ligger till grund för varje ansluten enhet, och en kompromiss på det lagret kan i tysthet undergräva varje säkerhetskontroll som byggts ovanför. EU:s Cyber ​​Resilience Act har förvandlat firmwareintegritet från ett valfritt skydd till en rättslig skyldighet, och NIST:s riktlinjer ger en tydlig och försvarbar färdplan för att uppfylla den.

Genom att signera firmware med godkända algoritmer, skydda nycklar i certifierad hårdvara, verifiera signaturer i en hårdvarurot av förtroende och planera för framtiden efter kvantumsgränserna kan organisationer skydda sina enheter, säkra sina leveranskedjor och visa efterlevnad långt före CRA:s deadline 2027. De tillverkare som behandlar firmwaresignering som en förstklassig säkerhetsfunktion idag kommer att vara de som är bäst positionerade för att förtjäna kundernas förtroende och undvika kostsamma påföljder imorgon.