Firmware-signering: En praktisk guide

Firmware-signering är metoden att koppla en kryptografisk signatur till firmware så att en enhet kan verifiera, vid start och uppdatering, att firmware kommer från en betrodd källa och inte har ändrats. Det är grunden för säker start och roten till förtroende för IoT-, inbyggda och fordonssystem.

Med signering av firmware kan en enhet kryptografiskt kontrollera att lågnivåkoden som körs är autentisk och omodifierad innan den körs. Enheten har en betrodd offentlig nyckel, ofta inbyggd i hårdvara, och verifierar firmwares signatur mot den. Om signaturen inte matchar vägrar enheten att köra firmware. Det är detta som hindrar angripare från att installera skadlig firmware, och det är grunden för varje säker startkedja.

Key Takeaways

• Firmware-signering kopplar en digital signatur till firmware så att en enhet kan verifiera dess äkthet och integritet innan den körs, vilket bildar grunden för förtroendet för säker start.
• Förtroendeankaret är en offentlig nyckel som är integrerad i engångsprogrammerbar (OTP) hårdvara och läses av oföränderligt ROM vid varje påslagning, så förtroendekedjan kan inte ersättas i fält.
• Signeringsnycklar måste finnas i en hårdvarusäkerhetsmodul (HSM). En stulen signeringsnyckel för firmware låter en angripare signera skadlig firmware som enheter litar på, vilket är bland de mest skadliga komprometteringar som kan uppstå i leveranskedjan.
• Firmware överlever ofta sin kryptografi: enheter som används idag kan komma att fungera in på 2040-talet. Långa livslängder gör post-kvantumberedskap till ett upphandlingskrav, inte en framtida oro.
• CNSA 2.0 utser firmware-signering till det högst prioriterade användningsfallet för post-kvantövergång. De kvantsäkra alternativen som kan driftsättas idag är de tillståndsfulla hashbaserade schemana LMS och XMSS (NIST SP 800-208), med SLH-DSA (FIPS 205) som ett tillståndslöst alternativ.

Varför firmwaresignering skiljer sig från vanlig kodsignering

Firmware-signering är kodsignering , men med begränsningar som gör det unikt krävande. Firmware körs på den lägsta nivån av en enhet, före operativsystemet, så en kompromiss här är utom räckhåll för de flesta säkerhetsverktyg. Och till skillnad från en applikation som du kan uppdatera varje vecka, bränns firmware ofta in i hårdvaran eller uppdateras sällan, ibland aldrig, under en enhets livstid mätt i årtionden.

Tre egenskaper definierar utmaningen. Firmware är den första koden som körs, så den är roten till förtroendet för allt ovanför den. Den körs på begränsad hårdvara, så signaturverifiering måste vara liten och snabb. Och den är långlivad, så de kryptografiska val som görs vid tillverkningen måste förbli sunda under enhetens hela livslängd. En bil, en industriell styrenhet eller en medicinteknisk produkt som signerats 2026 kan fortfarande behöva verifiera firmware år 2041.

Hur firmwaresignering och säker start fungerar

Att signera firmware i sig är bara halva historien. Dess värde realiseras genom säker start, den körningstid där varje steg i startkedjan verifierar nästa innan kontrollen lämnas över.

• Hårdvarurot för förtroende: En publik nyckel smälts in i ett engångsprogrammerbart (OTP) minne vid kiseltillverkning. Oföränderligt ROM läser denna nyckel vid varje strömpåslag och den kan inte ersättas ute i fält. Detta är ankaret för hela kedjan.
• Signera varje firmware-avbildning: Tillverkaren hashar varje firmware-avbildning (ROM, bootloaders, applikation) och signerar den med motsvarande privata nyckel, som förvaras säkert i en HSM, aldrig på enheten.
• Verifiera steg för steg: Vid uppstart verifierar ROM första stegets bootloader-signatur mot den sammanslagna publika nyckeln. Den bootloadern verifierar nästa steg, som verifierar nästa, och bildar en obruten förtroendekedja från hårdvara upp till applikationen.
• Avvisa vid misslyckande: Om någon signatur inte matchar avbryts den verifierade starten och enheten vägrar att köra den overifierade avbildningen. Manipulerad eller obehörig firmware körs aldrig.

Eftersom rotnyckeln finns i oföränderlig hårdvara och varje steg styr nästa, kan en angripare inte infoga skadlig firmware någonstans i kedjan utan att inneha den privata signeringsnyckeln. Det är därför som att skydda signeringsnyckeln är hela spelet.

Varför signeringsnyckeln är kronjuvelen

Om en angripare stjäl en signeringsnyckel för firmware kan de signera skadlig firmware som alla enheter som litar på nyckeln kommer att acceptera som äkta. Eftersom verifieringsnyckeln ofta är fixerad i hårdvaran och inte kan ändras ute i fält, kan en komprometterad signeringsnyckel för firmware vara oåterkallelig: det kanske inte finns något sätt att återkalla den på enheter som redan är ute i fält. Detta är ett värsta tänkbara scenario för leveranskedjan, och det är därför som signeringsnycklar för firmware måste skyddas mer noggrant än nästan alla andra nycklar en organisation innehar.

Det praktiska kravet är absolut: privata nycklar för firmwaresignering måste genereras och lagras i en Hardware Security Module (HSM), aldrig exporteras till en byggserver eller utvecklarmaskin, med signeringsoperationer autentiserade, åtkomstkontrollerade och loggade. Firmwaren går mellan många händer (kiselleverantör, OEM, Tier-1-leverantör, kontraktstillverkare), och varje överlämning är en plats där kedjan kan undergrävas, så centraliserad, granskad nyckelkontroll är avgörande.

Bästa praxis för signering av firmware

• Fortsätt signera nycklar i en HSM: Generera och lagra signeringsnycklar för firmware i en FIPS 140-2 Nivå 2 eller högre HSM. Låt aldrig den privata nyckeln vidröra en byggserver, CI-runner eller utvecklarbärbar dator.
• Förankra förtroendet för hårdvara: Säkra den offentliga rotnyckeln i OTP och verifiera den från en oföränderlig ROM, så att förtroendeankaret inte kan manipuleras i fält.
• Signera varje steg i startkedjan: Signera ROM-tillägg, bootloaders och applikationens firmware, och verifiera varje steg mot det ovanför, så att det inte finns något osignerat gap.
• Använd starka, aktuella algoritmer: Använd SHA-384 eller starkare hashing och nycklar av lämplig storlek. Planera för post-kvantumsignaturer med tanke på enhetens långa livslängd.
• Kontrollera och granska vem som kan signera: Kräv autentisering och auktorisering för varje signeringsoperation, och logga vem som signerade vad och när, hos varje leverantör i kedjan.
• Design för kryptoagilitet: Där hårdvaran tillåter, aktivera uppdateringar av signaturalgoritmer så att enheter inte är låsta till en algoritm som kan försvagas under sin livstid.

Firmware-signering och övergången efter kvantum

Firmware-signering är det mest brådskande användningsfallet för kodsignering i övergången till postkvantkryptografi , och orsaken är strukturell. I många enheter är firmware-verifieringsalgoritmen fixerad vid driftsättning, inbakad i oföränderlig hårdvara eller startkod. Om den algoritmen är RSA eller ECDSA , skulle en framtida kvantdator som kör Shors algoritm kunna förfalska signaturer, och det kanske inte finns något sätt att uppdatera algoritmen på enheter som redan levererats.

Det är därför NSA:s CNSA 2.0-riktlinjer identifierar firmware-signering som det högst prioriterade användningsfallet för signaturer för kvantövergången, och varför de pekar på hashbaserade signaturer som är standardiserade och distribuerbara idag snarare än att vänta på nyare scheman. Alternativen:

• LMS och XMSS (NIST SP 800-208): Tillståndssäkra hashbaserade signaturer, standardiserade 2019 och godkända enligt CNSA 2.0 för signering av firmware och programvara. De är driftsättbara nu och vilar på väl förstådd hashfunktionssäkerhet, vilket passar långlivad firmware.
• SLH-DSA (FIPS 205): En statslös hashbaserad signatur färdigställdes i augusti 2024. Den undviker tillståndshanteringsbördan från LMS och XMSS på bekostnad av större signaturer och delar deras konservativa säkerhetsgrund.
• ML-DSA (FIPS 204): Den gitterbaserade, generella signaturen. Det är den långsiktiga kandidaten för bred användning, även om många organisationer föredrar hashbaserade scheman för de mest konservativa långlivade rötterna.

Tillståndshanteringsfångsten med LMS och XMSS
LMS och XMSS är tillståndskänsliga: varje privat nyckel kan bara producera ett fast antal signaturer, och signeraren måste spåra vilka engångsnycklar som har använts, eftersom återanvändning av en nyckel bryter mot säkerheten. Detta gör dem opraktiska för högfrekvent signering, men väl lämpade för firmwaresignering, vilket är sällan och kontrollerat. Viktigt är att tillståndet hanteras av signeraren (i din signeringsinfrastruktur), inte av enheten, så det ökar inte den distribuerade hårdvaran i någon komplexitet. En kapabel signeringsplattform hanterar denna tillståndsspårning automatiskt.

CNSA 2.0:s tidslinje för signering av mjukvara och firmware är att föredra kvantsäkra algoritmer senast 2025 och uteslutande använda dem senast 2030, den mest aggressiva kategorin i hela sviten, just för att firmware är så svår att ändra efter distribution.

Firmware-signering i IoT, inbyggda enheter och fordonsindustrin

Firmware-signering är viktigast just där enheterna är många, långlivade och svåra att nå. I sakernas internet är osignerade firmware-uppdateringar en primär attackvektor för att bygga botnät och få beständighet.

Inom fordonsindustrin förväntar sig föreskrifter som UNECE R155 och standarder som ISO/SAE 21434 att hot från modifieringar av firmware ska mildras, och fordon som byggs idag kommer att vara på vägarna in på 2040-talet. Inom industriella och medicinska apparater kan en kompromiss med firmware få säkerhetskonsekvenser, inte bara datasäkerhetskonsekvenser.

Det som dessa domäner gemensamt gör är den kombination som gör firmware-signering omöjlig att förhandla om: begränsad hårdvara som måste verifiera signaturer effektivt, mycket långa livslängder som överträffar kryptografiska antaganden, och en leveranskedja som korsar flera organisationer innan en enhet når fältet. Att få firmware-signering och dess nyckelhantering rätt är grunden för allt annat inom enhetssäkerhet.

Hur krypteringskonsulting hjälper

Encryption Consultings CodeSign Secure är byggt för just detta problem. Den förvarar signeringsnycklar för firmware i en FIPS 140-2 Level 2 HSM så att den privata nyckeln aldrig lämnar hårdvaran, tvingar fram vem som är behörig att signera och loggar varje signeringsoperation för granskning hos dina leverantörer och byggsystem.

Den integrerar signering i CI/CD-pipelines så att firmware signeras automatiskt mot hårdvaruskyddade nycklar, och den stöder de hashbaserade och post-kvantumsigneringsscheman som firmwaresignering i allt högre grad kräver, inklusive den tillståndsbaserade tillståndshantering som LMS och XMSS kräver. Resultatet är en enda, styrd signeringsprocess för firmware, säkra startkedjor och resten av din kodsignering. Stöds av ISO/IEC 27001:2022- och SOC 2-certifierade metoder.

Vanliga frågor om partihandel med mat och dryck

Vad är firmware-signering?

Firmware-signering är praxisen att koppla en kryptografisk signatur till firmware så att en enhet kan verifiera, innan den körs, att firmware kommer från en betrodd källa och inte har ändrats. Enheten har en betrodd offentlig nyckel, ofta sammanfogad med hårdvara, och kontrollerar firmwares signatur mot den. Om signaturen inte matchar vägrar enheten att köra firmware, vilket förhindrar angripare från att installera skadlig kod på systemets lägsta nivå.

Vad är skillnaden mellan firmware-signering och säker start?

Firmware-signering är handlingen att producera signaturen; säker start är den körningsprocess som verifierar den. När firmware byggs signeras den med en privat nyckel. Vid uppstart kontrollerar säker start varje steg i startkedjan mot en betrodd offentlig nyckel innan den körs, med början från en oföränderlig hårdvarurot. Firmware-signering tillhandahåller signaturerna, och säker start framtvingar dem, så de två arbetar tillsammans för att förhindra att obehörig firmware någonsin körs.

Varför måste signeringsnycklar för firmware lagras i en HSM?

Eftersom en stulen signeringsnyckel för firmware är katastrofal och ofta oåterställbar. En angripare med nyckeln kan signera skadlig firmware som alla enheter som litar på nyckeln kommer att acceptera, och eftersom verifieringsnyckeln ofta är fixerad i hårdvaran kanske det inte finns något sätt att återkalla den på enheter som redan är distribuerade. Att lagra den privata nyckeln i en hårdvarusäkerhetsmodul innebär att den aldrig lämnar manipulationssäker hårdvara, så även ett helt komprometterat byggsystem kan inte stjäla den.

Vilka algoritmer ska jag använda för post-quantum firmware-signering?

För kvantsäker firmwaresignering idag är de distribuerbara alternativen de tillståndsfulla hashbaserade scheman LMS och XMSS, standardiserade i NIST SP 800-208 och godkända under CNSA 2.0. SLH-DSA (FIPS 205) är ett tillståndslöst hashbaserat alternativ som slutfördes i augusti 2024. Hashbaserade scheman föredras ofta för långlivade firmwarerötter eftersom deras säkerhet endast vilar på väl förstådda hashfunktioner. ML-DSA (FIPS 204) är det generella gitterbaserade alternativet för bredare användning.

Varför är firmware-signering högsta prioritet för övergången efter kvantum?

Eftersom firmware är det svåraste att ändra efter driftsättning. I många enheter är signaturverifieringsalgoritmen fixerad i oföränderlig hårdvara eller startkod, så om den använder RSA eller ECDSA skulle en framtida kvantdator kunna förfalska firmwaresignaturer utan att kunna uppdatera algoritmen på enheter som redan är i fält. NSA:s CNSA 2.0-vägledning utser firmwaresignering till det högst prioriterade användningsfallet för signaturer och anger den mest aggressiva tidslinjen, exklusiv kvantsäker användning senast 2030.

Vilka är problemen med tillståndshantering med LMS och XMSS?

LMS och XMSS är tillståndsbaserade hashbaserade signaturer: varje privat nyckel kan bara producera ett fast antal signaturer, och signeraren måste spåra vilka engångsnycklar som har använts, eftersom återanvändning av en sådan äventyrar säkerheten. Detta gör dem olämpliga för högfrekvent signering men väl lämpade för sällan förekommande, kontrollerad firmwaresignering. Tillståndet hanteras av signeringsinfrastrukturen, inte av enheten, så det ökar inte den distribuerade hårdvaran i någon större utsträckning. En kapabel signeringsplattform spårar detta tillstånd automatiskt.

Signera firmware mot hårdvaruskyddade nycklar

Firmware-signering är bara så stark som skyddet runt dess nycklar, och insatserna är högre än i något annat användningsfall för signering. Utforska CodeSign Secure för att signera firmware och säker start-avbildningar mot HSM-skyddade nycklar, med stöd för post-kvantumalgoritmer och fullständig granskning i hela din leveranskedja.