Säkerhet och uppdateringsmekanismer för IoT-firmware: En djupdykning

Användningen av nätverksanslutna sakernas internet (IoT)-enheter ökar snabbt, vilket introducerar olika cybersäkerhets- och leveranskedjeattacker som riktar sig mot dessa slutpunkter. Verkliga attacker har visat hur firmware kan utnyttjas för att skapa botnät, stjäla data eller till och med ta kontroll över kritisk infrastruktur. Det ökända botnätet Mirai utnyttjade till exempel osäkra IoT-enheter för att starta massiva DDoS-attacker. Många av dessa enheter hade hårdkodade inloggningsuppgifter och inget sätt att uppdatera sin firmware.

På grund av detta blir det en avgörande aspekt av din cybersäkerhet att hålla firmware för dina IoT-enheter uppdaterad. Firmware-uppdateringar är avgörande för att åtgärda programvarufel, korrigera sårbarheter eller lägga till nya säkerhetsfunktioner. Lika viktigt är att se till att dessa uppdateringar är säkra och pålitliga.

Säkerhet för IoT-firmware, definierad: säkerställande av att endast autentisk, omodifierad firmware någonsin körs på en enhet och att varje uppdatering verifieras kryptografiskt före installation, kombinerat med säker start (förtroende vid start), signerade OTA-uppdateringar (förtroende vid uppdateringstillfället) och rollback-skydd (ingen nedgradering till en sårbar version), över enheter som ofta är för resursbegränsade för att köra traditionell säkerhetsprogramvara.

Key Takeaways

• Den här sidan behandlar livscykeln för IoT-enheter och OTA-uppdateringar: verkliga incidenter, leverantörers och slutanvändares ansvar samt standarder. För mer information om själva startkedjekryptografin (hårdvarubaserade förtroenderötter, rollback-räknare, tillverkningsidentiteter), se Bootloader Trust: Den avgörande rollen för firmwaresignering.
• En läckt eller komprometterad signeringsnyckel för firmware är en fullständig återställningshändelse, inte ett enkelt nyckelbyte: varje enhet som redan är i fältet litar på den gamla nyckeln, och återkallelse där innebär en uppdatering, inte en certifikatkontroll.
• ML-DSA (FIPS 204) och SLH-DSA (FIPS 205) är NIST:s slutgiltiga standarder för postkvantsignering från och med augusti 2024; LMS och XMSS (NIST SP 800-208) är de tillståndsfulla hashbaserade scheman som CNSA 2.0 specificerar specifikt för firmwaresignering.

Viktiga utmaningar med IoT-firmwaresäkerhet

Att säkra firmware är inte lika enkelt som att säkra en webbapplikation. IoT-enheter är ofta resursbegränsade, vilket innebär att de inte har processorkraften eller minnet för att stödja traditionella säkerhetsprotokoll. De är också otroligt mångsidiga – olika chipset, olika operativsystem, olika uppdateringsmekanismer. Denna brist på standardisering gör det svårt att tillämpa en universallösning.

Sårbarhet i leveranskedjan är en viktig utmaning för firmwaresäkerhet, eftersom firmware ofta utvecklas av tredjepartsleverantörer eller sätts samman från komponenter med öppen källkod. Detta öppnar dörren för manipulering långt innan enheten når slutanvändaren. Och när den väl är ute i fält blir uppdatering av firmware en logistisk mardröm, om du inte har planerat för det från början.

Dessutom tillåter obehörig åtkomst till kodsigneringsnycklar eller signeringsmekanismer för firmware angripare att utge sig för att vara betrodda och leverera skadliga uppdateringar till enheter som verkar betrodda.

Slutligen kan osäkra kodningsmetoder göra det möjligt för angripare att utnyttja buffertöverflöden för att få fjärråtkomst till enheter och skapa DDoS- eller malware-injektionsattacker.

Konsekvenser av osäker IoT-firmware

Osäker IoT-firmware kan leda till olika attacker som kan användas på distans av en angripare utan förvarning. Låt oss titta på några av exemplen nedan:

1. I september 2016 lanserade skaparna av Mirai en DDoS-attack mot webbplatsen för en välkänd säkerhetsexpert. Kort därefter släppte de källkoden, som snabbt anammades av andra cyberbrottslingar. Detta ledde till en massiv attack mot leverantören av domänregistreringstjänster, Dyn, i oktober 2016, vilket orsakade omfattande störningar.

2. Botnätet RIFT dök upp i december 2018 och använde en mängd olika exploits för att infektera IoT-enheter. Enligt onlinekällor använde botnätet 17 exploits.

   Den 11 december 2018 rapporterades en sårbarhet för fjärrkörning av kod i ThinkPHP-ramverket, där operativsystemkommandon injicerades via frågeparametern "vars". Detta följer en typisk exploateringssekvens som observeras i RIFT-attacker.

3. I en annan incident läckte D-Link av misstag privata kodsigneringsnycklar som används för att signera programvara. Även om det inte är känt om nycklarna användes av illvilliga tredje parter, finns det en möjlighet att de kan ha använts av en hackare för att signera skadlig kod, vilket gör det mycket enklare att utföra attacker.
4. I en av attackerna mot uppkopplade bilar avslöjade forskare vid det kinesiska företaget Tencent att de kunde tränga sig igenom Wi-Fi-anslutningen på en Tesla S hela vägen till dess körsystem och på distans aktivera det rörliga fordonets bromsar.

Säkra IoT-firmwareuppdateringar – leverantörers perspektiv

OTA-uppdateringar (over-the-air) låter dig skicka firmware-patchar, säkerhetsfixar och till och med nya funktioner till enheter på distans utan behov av fysisk åtkomst. OTA-uppdateringar levereras vanligtvis via mobildata (4G eller 5G) eller via internetanslutningar.

OTA gör inte bara din firmwareuppdateringsprocess smidigare utan ökar även motståndskraften, vilket ger din organisation kryptoflexibilitet i hanteringen av alla typer av cyberattacker. Utan OTA sitter du fast med den firmware som fanns på enheten vid lanseringen. Och om den firmware har en brist har du problem.

Att utforma ett säkert OTA-system är avgörande för att säkerställa firmwaresäkerhet. Varje uppdatering bör signeras med en privat nyckel och verifieras på enheten med en motsvarande offentlig nyckel. Detta säkerställer att endast betrodda uppdateringar installeras. Enheter bör avvisa alla uppdateringar som inte uppfyller dessa kriterier. Uppdateringsprocessen bör också inkludera integritetskontroller för att förhindra manipulation under överföring. Återställningsskydd är också avgörande för att säkerställa att angripare inte kan nedgradera firmware till en sårbar version.

Lika viktigt är infrastrukturen bakom uppdateringarna. Du behöver en säker servermiljö för att vara värd för den inbyggda programvaran, en pålitlig leveransmekanism och ett övervakningssystem för att spåra uppdateringars framgång och misslyckanden. Användartransparens är också viktigt för att hålla dina användare informerade när uppdateringar sker och varför, bygga förtroende och minska motstånd.

Återställa från en komprometterad signeringsnyckel för firmware

D-Link-incidenten ovan är ett användbart exempel för att tänka igenom återställning, eftersom den illustrerar varför detta skiljer sig från en typisk certifikatåterkallelse. När en firmware-signeringsnyckel har exponerats, hindrar återkallelsen av certifikatet nya skadliga signaturer från att valideras på system som kontrollerar återkallningsstatus, men det avför inte retroaktivt nyckeln på enheter som redan är distribuerade ute i fält, av vilka många aldrig ringer hem för att kontrollera återkallelsen alls. Återställning kräver att varje enhetsmodell och firmwareversion som signerats med den komprometterade nyckeln identifieras, roteras till en ny nyckel som lagras i en HSM och skickas en signerad uppdatering från den nya nyckeln som enheter kan verifiera, allt medan enheter utan nätverksanslutning eller uppdateringsmekanism kan förbli permanent exponerade. Det är just därför återställningsskydd och en dokumenterad nyckelrotationsplan måste finnas före en kompromiss, inte utformas under en.

Säkra IoT-firmwareuppdateringar – slutanvändarens perspektiv

Osäkra uppdateringar av IoT-firmware kan få allvarliga konsekvenser för användarna av dessa enheter, särskilt eftersom alla typer av skadliga attacker kan utföras på distans utan att det krävs någon fysisk åtkomst till enheten.

För att skydda dig mot osäkra firmwareuppdateringar, undvik automatiska uppdateringar, särskilt på otillförlitliga nätverk, och hämta endast uppdateringarna från leverantörens säkra webbplats med HTTPS . Överväg också alltid att prioritera firmwaresupport i dina köpbeslut.

Verkliga tillämpningar, standarder och innovationer inom firmwaresäkerhet

Branscher som är starkt beroende av IoT, som fordonsindustrin, sjukvården och tillverkningssektorn, ser redan fördelarna med säkra OTA-uppdateringar. Inom fordonssektorn används till exempel OTA-uppdateringar inte bara för infotainmentsystem utan även för kritiska säkerhetsfunktioner. Tesla använder OTA för att lansera allt från prestandaförbättringar till buggfixar, ofta över en natt.

Inom sjukvården, där enheter som insulinpumpar och hjärtmonitorer i allt högre grad är uppkopplade, kan OTA-uppdateringar vara en fråga om liv eller död. En sårbarhet i en medicinteknisk produkt är inte bara ett säkerhetsproblem, det är ett patientsäkerhetsproblem. Säkra OTA-mekanismer säkerställer att dessa enheter kan uppdateras snabbt och säkert, utan att det krävs ett sjukhusbesök.

Standarder som NIST:s ramverk för cybersäkerhet inom IoT och ETSI EN 303 645 driver IoT-tillverkare att anta säkra utvecklingsmetoder, rigorösa tester och en robust OTA-infrastruktur. EU:s lag om cybermotståndskraft lägger till ytterligare ett krav som är relevant här: tillverkare måste kunna uppvisa bevis, revisionsloggar, signeringsregister och dokumenterade processer som visar att uppdateringsintegriteten har verifierats, inte bara hävda att den har det.

Ny forskning har föreslagit avancerade kryptografiska tekniker för att säkra firmwareuppdateringar mot attacker i leveranskedjan. NIST slutförde sina första standarder för postkvantsignering i augusti 2024: ML-DSA (FIPS 204, tidigare känt som Dilithium) och SLH-DSA (FIPS 205, tidigare känt som SPHINCS+). Specifikt för firmware är de tillståndsfulla hashbaserade schemana LMS och XMSS (NIST SP 800-208) också godkända och är vad NSA:s CNSA 2.0-svit specificerar för programvaru- och firmwaresignering.

Hur kan krypteringskonsulting hjälpa?

Encryption Consultings CodeSign Secure skyddar din programvara med en kraftfull, policydriven kodsigneringslösning för att effektivisera säkerheten utan problem, inklusive HSM-baserad nyckellagring för firmwaresigneringsnycklar och fullständig granskningsloggning för varje signeringshändelse.

Encryption Consultings rådgivningstjänster kan hjälpa din organisation att hitta dataskydd i företagsklass med heltäckande krypteringsstrategier som förbättrar efterlevnad, eliminerar riskblinda fläckar och anpassar säkerheten till dina affärsmål i moln-, lokala och hybridmiljöer.

Dessutom kan Encryption Consultings PQC-bedömningstjänst hjälpa er organisation genom att genomföra en detaljerad bedömning av era lokala, moln- och SaaS-miljöer, identifiera sårbarheter och rekommendera de bästa strategierna för att minska kvantriskerna.

För mer information om våra produkter och tjänster, besök:

Kodsigneringslösning | Få snabb, enkel och säker kodsignering med CodeSign Secure

Postkvantumkryptografiska tjänster | Krypteringskonsulttjänster

Krypteringsrådgivningstjänster

Slutsats

Firmware kan vara osynlig för de flesta användare, men det är ryggraden i varje IoT-enhet. Att investera i säkra firmwarerutiner och robusta OTA-uppdateringssystem är nyckeln till att skydda och minska riskerna i samband med firmwaresårbarheter och kryptografiska attacker.

Vanliga frågor om partihandel med mat och dryck

Är Dilithium samma sak som ML-DSA?

Ja. ML-DSA (FIPS 204) är det standardiserade namnet som NIST slutförde för Dilithium i augusti 2024. På liknande sätt är SLH-DSA (FIPS 205) det standardiserade namnet för SPHINCS+.

Om en signeringsnyckel för firmware har komprometterats, räcker det att återkalla certifikatet?

Nej. Återkallelse hindrar nya signaturer från att validera där enheter kontrollerar återkallningsstatus, men de flesta IoT-enheter kontrollerar det inte i realtid, och enheter som redan är i fält fortsätter att lita på den gamla nyckeln tills de tar emot och installerar en uppdatering som är signerad med en ny. Återställning kräver att berörda enheter identifieras, nyckeln roteras och en verifierbar uppdatering skickas, inte bara att ett certifikat återkallas.

Vilka bevis förväntas enligt EU:s cyberresilienslagstiftning för integriteten hos firmwareuppdateringar?

Dokumenterade processer och revisionsloggar, signeringsregister, nyckelhanteringsloggar och verifieringssteg som visar att uppdateringsintegriteten faktiskt tillämpades, inte bara ett påstående om att den gjorde det. Detta är samma bevis som en centraliserad signeringsplattforms revisionsloggning är utformad för att producera.