Firmware Signing

Wat is Firmware Signing?

Firmware signing is een beveiligingsmaatregel waarbij de fabrikant firmware voorziet van een cryptografische digitale handtekening, zodat een apparaat vóór installatie of uitvoering kan controleren dat de code van een vertrouwde bron komt en onderweg niet is gewijzigd. Firmware die niet of verkeerd ondertekend is, weigert het apparaat. Firmware signing is de toepassing van code signing op de laagste softwarelaag van een apparaat.

In OT-systemen voorkomt firmware signing dat aanvallers malafide of gemanipuleerde firmware installeren op bijvoorbeeld PLC’s, RTU’s, IED’s of IIoT-apparaten. Omdat firmware onder het besturingsprogramma draait, is een gemanipuleerde versie vrijwel onzichtbaar en blijft ze na een herstart gewoon actief.

🧠 Hoe werkt firmware signing?

Firmware signing gebruikt asymmetrische cryptografie: de fabrikant ondertekent met een geheime private key, het apparaat controleert met de bijbehorende public key die in het apparaat is vastgelegd.

1. Hashing - de buildomgeving berekent een cryptografische hash van het firmware-image, meestal met SHA-256 of SHA-384.
2. Ondertekenen - een signeerservice berekent met de private key een handtekening over die hash. De sleutel staat idealiter in een hardware security module (HSM) en verlaat die nooit.
3. Verpakken - het image wordt geleverd met handtekening, versienummer en vaak een certificaat of sleutel-ID.
4. Verificatie bij installatie - de bootloader of het updateproces van het apparaat berekent de hash opnieuw en controleert de handtekening met de ingebouwde public key.
5. Weigeren bij afwijking - klopt de handtekening niet, of is het versienummer lager dan toegestaan, dan wordt de update geblokkeerd en blijft de oude firmware actief.
6. Logging - pogingen om niet-geverifieerde firmware te laden, worden bij voorkeur gelogd en naar een centrale omgeving gestuurd.

Een veelgehoorde vereenvoudiging is dat de hash “versleuteld” wordt met de private key. Dat klopt alleen voor klassiek RSA; bij ECDSA en EdDSA is ondertekenen een eigen wiskundige bewerking. Het principe blijft gelijk: alleen wie de private key heeft, kan een geldige handtekening maken.

🔧 Welke algoritmen en sleutellengtes zijn gangbaar?

Voor firmware die twintig jaar of langer in het veld blijft, is de keuze van het algoritme een langetermijnbeslissing. De Amerikaanse NSA wil in haar CNSA 2.0-planning dat software- en firmware-signing vanaf 2025 bij voorkeur, en uiterlijk in 2030 uitsluitend, met quantumbestendige hash-gebaseerde handtekeningen gebeurt.

🔄 Wat is het verschil tussen firmware signing en Secure Boot?

Firmware signing en Secure Boot gebruiken dezelfde cryptografie, maar controleren op een ander moment.

Beide werken samen: signing houdt foute firmware buiten, Secure Boot controleert bij elke start of wat in het geheugen staat nog klopt. Zonder hardware root of trust kan een aanvaller met fysieke toegang beide omzeilen. Dat bleek in januari 2023 bij de Siemens S7-1500 (CVE-2022-38773): de CPU’s hebben geen onveranderlijke root of trust in hardware, waardoor de integriteit van de code bij het laden niet kan worden gecontroleerd en iemand met fysieke toegang het boot-image kan vervangen. Siemens bracht voor een deel van de CPU-typen nieuwe hardwareversies met een nieuw secure-bootmechanisme uit en adviseert voor de overige CPU’s fysieke afscherming, zoals afgesloten kasten.

🏭 Waar is firmware signing relevant in OT?

Het belang werd duidelijk bij de aanval op Oekraïense energiebedrijven op 23 december 2015. De stroomstoring trof ongeveer 225.000 klanten. De aanvallers corrumpeerden daarnaast de firmware van serial-to-Ethernet-converters in onderstations, waardoor die onbruikbaar werden en het herstel werd bemoeilijkt. Apparaten die alleen ondertekende firmware accepteren, maken zo’n aanval veel moeilijker.

Firmware signing is een essentieel verdedigingsmechanisme tegen persistente aanvallen via de supply chain, fysieke toegang of interne sabotage.

🔐 Welke normen en wetten vragen om ondertekende firmware?

• IEC 62443-4-2 - eis EDR 3.10 vraagt ondersteuning van updates; de versterking RE(1) vraagt dat het apparaat de authenticiteit en integriteit van een update controleert. EDR 3.14 gaat over de integriteit van het opstartproces en CR 3.4 over software- en informatie-integriteit.
• IEC 62443-3-3 - op systeemniveau valt dit onder SR 3.4 Software and information integrity, binnen FR 3 Systeemintegriteit.
• IEC 62443-4-1 - de ontwikkelprocesnorm vraagt dat leveranciers updates zo leveren dat de gebruiker de echtheid kan controleren (praktijk SUM-4), en dat private keys voor code signing beschermd worden (SM-8).
• Cyber Resilience Act - bijlage I eist dat fabrikanten de integriteit van programma’s en configuratie beschermen tegen ongeautoriseerde wijziging en updates veilig distribueren. De meldplicht geldt sinds 11 september 2026, de volledige eisen vanaf 11 december 2027.
• Machineverordening - vanaf 20 januari 2027 moeten veiligheidskritische software en data in machinebesturingen beschermd zijn tegen corruptie.
• NIST SP 800-193 - de richtlijn Platform Firmware Resiliency (mei 2018) gaat uit van beschermen, detecteren en herstellen van firmware.

Voor organisaties onder NIS2 en de Cyberbeveiligingswet is ondertekende firmware geen directe wettelijke eis, maar wel een logisch onderdeel van supply-chainbeveiliging en patchmanagement.

🔁 Hoe valt firmware signing in de CSIR-classificatie?

In de CSIR-indeling van deze kennisbank valt firmware signing onder twee labels, met een duidelijke koppeling naar de IEC 62443-eisen.

🛠️ Hoe pakt u firmware signing aan als eindgebruiker?

Als asset owner ondertekent u zelf geen firmware, maar u bepaalt wel of de bescherming werkt.

1. Inventariseer - leg per apparaat in uw asset-inventaris vast of het ondertekende firmware afdwingt en of er een hardware root of trust is.
2. Stel inkoopeisen - vraag bij leveranciersbeveiliging naar EDR 3.10 RE(1), het sleutelbeheer en hoe een gecompromitteerde sleutel wordt ingetrokken.
3. Download alleen uit de officiële bron - controleer daarnaast de gepubliceerde hash, zeker bij apparaten die geen handtekening afdwingen.
4. Test vooraf - installeer nieuwe firmware eerst op een testopstelling en leg de wijziging vast via change management.
5. Blokkeer downgrades - schakel anti-rollback in waar dat kan, zodat een aanvaller geen oudere, kwetsbare maar wél ondertekende versie terugzet.
6. Beperk fysieke toegang - sluit kasten af en zet de beschermingsstand of sleutelschakelaar van de CPU op run, als aanvulling op hardening.

⚠️ Wat zijn de beperkingen en aandachtspunten?

• Niet alle apparatuur ondersteunt het - veel oudere OT-apparatuur controleert geen handtekening of alleen een eenvoudige checksum.
• Sleutelbeheer is de achilleshiel - wie de private key steelt, kan geldige malware maken. Stuxnet gebruikte gestolen certificaten van Realtek en JMicron om zijn drivers te ondertekenen, en bij PKfail (2024) bleken veel apparaten een openbaar bekende testsleutel te vertrouwen.
• Een handtekening zegt niets over kwetsbaarheden - een ondertekende versie kan nog steeds lekken bevatten; kwetsbaarheidsbeheer en een SBOM blijven nodig.
• Vendor lock-in - sommige leveranciers houden het signing-proces gesloten, waardoor alleen hun eigen firmware ooit draait.
• Risico op onbruikbare apparaten - een fout in het signing- of updateproces kan een asset na een update onbruikbaar maken; dual-bank-flash met terugvaloptie beperkt dat.

❓ Veelgestelde vragen

Is firmware signing hetzelfde als code signing?

Firmware signing is een vorm van code signing, gericht op de firmware van apparaten. Code signing omvat ook applicaties, drivers en scripts op pc’s en servers. De cryptografie is gelijk, maar bij firmware signing gebeurt de controle in de bootloader of het updateproces van het apparaat zelf.

Welke public key gebruikt een PLC om firmware te controleren?

Een PLC controleert firmware met een public key van de fabrikant die tijdens de productie in het apparaat is vastgelegd, bijvoorbeeld in ROM, eenmalig programmeerbare fuses of een secure element. De bijbehorende private key blijft bij de fabrikant, meestal in een hardware security module. Daardoor kan alleen de fabrikant firmware maken die de PLC accepteert.

Beschermt firmware signing tegen een aanval zoals TRITON?

Niet volledig. Bij TRITON laadden aanvallers in 2017 kwaadaardige code in het werkgeheugen van een draaiende Triconex-veiligheidscontroller, zonder de firmware via een normale update te vervangen. Firmware signing beschermt het updatekanaal, maar aanvullende maatregelen zoals de sleutelschakelaar, netwerksegmentatie en monitoring blijven nodig.

Wat gebeurt er als de signing key van een leverancier uitlekt?

Als de signing key van een leverancier uitlekt, kunnen aanvallers firmware maken die apparaten als echt accepteren. De leverancier moet dan een nieuwe sleutel uitrollen en de oude intrekken, wat bij apparaten met een vaste sleutel in hardware soms alleen via vervanging kan. Vraag leveranciers daarom vooraf hoe zij sleutels beschermen en vervangen.

Is firmware signing verplicht onder de Cyber Resilience Act?

De Cyber Resilience Act noemt firmware signing niet letterlijk, maar eist vanaf 11 december 2027 dat fabrikanten programma’s beschermen tegen ongeautoriseerde wijziging en updates veilig distribueren. In de praktijk is een digitale handtekening op firmware de gangbare manier om dat aan te tonen. De eis geldt voor fabrikanten, niet voor de gebruikers van OT-apparatuur.

Kan ik bestaande apparatuur zonder firmware signing beveiligen?

Bestaande apparatuur zonder firmware signing kunt u alleen compenseren met andere maatregelen. Denk aan het controleren van hashes bij downloads, fysieke afscherming, het blokkeren van engineeringtoegang buiten onderhoudsvensters en netwerksegmentatie volgens IEC 62443. Bij vervanging kunt u ondertekende firmware als harde inkoopeis opnemen.

📌 Samengevat

Firmware signing waarborgt dat alleen authentieke, ongewijzigde firmware van de fabrikant op een apparaat terechtkomt. In OT is dit cruciaal voor de bescherming van PLC’s, RTU’s en veldapparatuur tegen manipulatie via leveranciersupdates, onderhoud op afstand of fysieke toegang. De maatregel werkt pas echt in combinatie met Secure Boot, een hardware root of trust en zorgvuldig sleutelbeheer, en de Cyber Resilience Act maakt veilige updates vanaf 2027 een plicht voor leveranciers.