Code Signing

Wat is Code Signing?

Code signing is het cryptografisch ondertekenen van software, Firmware, scripts en andere uitvoerbare bestanden met een private key en een digitaal certificaat, zodat een systeem vóór installatie of uitvoering kan controleren wie de code heeft gemaakt en dat deze sindsdien niet is gewijzigd. Een geldige handtekening bewijst dus herkomst (authenticiteit) en ongeschonden inhoud (integriteit). Ze bewijst niet dat de code zelf veilig of foutloos is.

In OT-omgevingen is code signing cruciaal bij Firmware-updates, PLC-programmering en softwaredistributie in productienetwerken, waar betrouwbaarheid en continuïteit essentieel zijn. Een gemanipuleerde update kan hier niet alleen data, maar ook een fysiek proces raken.

🧠 Waarom is code signing belangrijk in OT?

Installaties in de procesindustrie, energie en water draaien tien tot twintig jaar of langer en krijgen updates via veel kanalen: engineeringsoftware, USB-sticks, leveranciersportals, servicemonteurs en steeds vaker over-the-air. Code signing maakt elk van die kanalen controleerbaar.

1. Bescherming tegen manipulatie - een gewijzigd bestand levert een ongeldige handtekening op en wordt geweigerd of gemarkeerd.
2. Verificatie van de bron - alleen code van vertrouwde leveranciers of van uw eigen engineeringafdeling wordt geaccepteerd.
3. Ondersteuning voor Secure Boot - alleen ondertekende Firmware en bootloaders worden bij het opstarten uitgevoerd.
4. Minder kans op Malware - ongetekende of verkeerd getekende code wordt geblokkeerd, bijvoorbeeld via application whitelisting.
5. Aantoonbare Compliance - code signing ondersteunt eisen uit IEC 62443, NIS2 en de Cyber Resilience Act, al maakt het u op zichzelf niet compliant.

🔧 Hoe werkt code signing stap voor stap?

Code signing gebruikt asymmetrische cryptografie: wie ondertekent, gebruikt een geheime private key; wie controleert, gebruikt de bijbehorende public key uit het certificaat.

1. Hashen - de buildomgeving berekent een cryptografische hash van de code, meestal SHA-256 of SHA-384.
2. Ondertekenen - met de private key wordt over die hash een handtekening berekend (bijvoorbeeld RSA of ECDSA). De sleutel staat in een hardware security module (HSM) en verlaat die nooit.
3. Tijdstempel toevoegen - een timestamping authority (volgens RFC 3161) bevestigt wanneer is ondertekend. Daardoor blijft de handtekening geldig nadat het certificaat zelf is verlopen.
4. Verpakken - handtekening, certificaatketen en tijdstempel worden in of naast het bestand meegeleverd.
5. Verifiëren - het besturingssysteem, de bootloader of het updateproces berekent de hash opnieuw, controleert de handtekening en de certificaatketen tot een vertrouwde root, en kijkt of het certificaat niet is ingetrokken.
6. Accepteren of weigeren - alleen geldige, ongewijzigde en vertrouwde code wordt geïnstalleerd of uitgevoerd; afwijkingen worden bij voorkeur in de logging vastgelegd.

De vaak gehoorde uitleg dat de hash met de private key wordt “versleuteld”, klopt alleen voor klassiek RSA. Bij ECDSA is ondertekenen een eigen wiskundige bewerking. Het principe blijft hetzelfde: alleen wie de private key heeft, kan een geldige handtekening maken.

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

De drie begrippen gebruiken dezelfde cryptografie, maar verschillen in reikwijdte en moment van controle.

Firmware signing is dus de toepassing van code signing op de laagste softwarelaag. Secure Boot gebruikt die handtekeningen om bij elke start te controleren of wat in het geheugen staat nog klopt. Een Trusted Platform Module of een ander secure element kan aan de apparaatkant als hardwarematige root of trust dienen.

🏭 Waar wordt code signing in OT toegepast?

🔐 Hoe beschermt u signeersleutels en certificaten?

De handtekening is precies zo betrouwbaar als de private key. Wie de sleutel steelt, kan malware maken die er legitiem uitziet. Daarom hoort sleutelbeheer bij certificaatbeheer en niet op een ontwikkelaarslaptop.

• Hardware-opslag - sinds juni 2023 eist het CA/Browser Forum dat private keys van publiek vertrouwde code-signingcertificaten in een hardwaremodule staan die voldoet aan FIPS 140-2 niveau 2 of Common Criteria EAL 4+, zoals een HSM, cloud-HSM of token.
• Kortere looptijd - certificaten die vanaf 1 maart 2026 worden uitgegeven, zijn maximaal 460 dagen geldig, waar dat eerder 39 maanden was. Plan vernieuwing daarom als vast proces.
• Altijd timestampen - zonder tijdstempel wordt een handtekening ongeldig zodra het certificaat verloopt, terwijl OT-software vaak jaren later nog wordt geïnstalleerd.
• Scheiding van rollen - volgens RBAC en least privilege mag alleen een beperkt aantal geautoriseerde mensen of pijplijnen ondertekenen, bij voorkeur met goedkeuring door twee personen.
• Integratie met CI/CD - de buildpijplijn ondertekent automatisch na geslaagde tests, zodat er geen handmatige kopieën van de sleutel circuleren.
• Intrekken en loggen - bij compromittering trekt u het certificaat direct in. Log elke ondertekening, zodat u achteraf kunt zien wat met welke sleutel is getekend.

Voor interne code, zoals eigen scripts of PLC-bibliotheken, kunt u een interne CA gebruiken. Dan moet u het rootcertificaat zelf veilig verspreiden naar alle systemen die controleren.

⚠️ Wat kan code signing niet voorkomen?

Een handtekening zegt wie de code heeft ondertekend, niet of die code te vertrouwen is. Drie bekende incidenten laten dat zien:

• Stuxnet (2010) - de drivers van de worm waren ondertekend met gestolen certificaten van Realtek en JMicron. Windows installeerde ze daardoor zonder waarschuwing. VeriSign trok beide certificaten in juli 2010 in.
• SolarWinds (2020) - aanvallers plaatsten de SUNBURST-achterdeur in de buildomgeving van Orion. De besmette DLL werd met het legitieme certificaat van SolarWinds ondertekend en via de normale updates verspreid, vanaf ten minste maart 2020.
• 3CX (2023) - de desktopapp van deze VoIP-leverancier werd via een eerdere supply chain-aanval besmet en met het geldige certificaat van 3CX uitgeleverd.

Code signing is daarom één laag naast een veilig ontwikkelproces, een SBOM, patchmanagement, netwerkdetectie en een test in een OTAP-omgeving vóór productie.

📜 Welke normen en wetten vragen om code signing?

• IEC 62443-4-1 - leveranciers moeten private keys voor code signing beschermen (praktijk SM-8) en updates zo leveren dat de gebruiker de echtheid kan controleren (SUM-4).
• IEC 62443-4-2 - CR 3.4 vraagt software- en informatie-integriteit; EDR 3.10 RE(1) vraagt dat een apparaat de authenticiteit en integriteit van een update controleert.
• IEC 62443-3-3 - op systeemniveau valt dit onder SR 3.4 Software and information integrity.
• NIST SP 800-218 (SSDF 1.1, februari 2022) - taak PS.2.1 vraagt dat producenten integriteitsinformatie, zoals hashes en handtekeningen van een erkende CA, beschikbaar maken voor afnemers.
• Cyber Resilience Act - bijlage I eist bescherming van de integriteit van software en veilige distributie van updates. De meldplicht geldt sinds 11 september 2026, de volledige eisen vanaf 11 december 2027.
• NIS2 en Cyberbeveiligingswet - de zorgplicht omvat beveiliging van de toeleveringsketen en van aanschaf, ontwikkeling en onderhoud van systemen. Ondertekende software is een gangbare manier om dat aan te tonen.

🧭 Hoe voert u code signing in een OT-omgeving in?

1. Inventariseer welke software, firmware en scripts u gebruikt en welke daarvan al zijn ondertekend. Vraag leveranciers naar hun signeerproces en certificaten.
2. Zet verificatie aan waar het kan: Secure Boot op IPC’s, firmwarecontrole op PLC’s, AllSigned voor PowerShell en application control op Windows-systemen.
3. Leg eisen vast in inkoop - vraag ondertekende updates, gepubliceerde hashes en een SBOM, conform IEC 62443-4-1 en de CRA.
4. Richt een signeerdienst in voor eigen code, met HSM, interne CA of publiek certificaat, timestamping en goedkeuring via change management.
5. Controleer bij ontvangst - verifieer handtekening en hash van elke update vóór gebruik, ook bij installatie via USB of door een servicemonteur.
6. Plan levenscyclus en noodgevallen - vernieuw certificaten tijdig, oefen het intrekken van een sleutel en houd rekening met post-quantumalgoritmen voor systemen die lang meegaan.

❓ Veelgestelde vragen

Wat is het verschil tussen code signing en encryptie?

Code signing beschermt de authenticiteit en integriteit van code, maar houdt de inhoud niet geheim. Iedereen kan ondertekende code lezen, alleen niet ongemerkt wijzigen. Encryptie maakt inhoud juist onleesbaar voor wie de sleutel niet heeft.

Is ondertekende software altijd veilig?

Ondertekende software is niet automatisch veilig. Code signing bewijst alleen wie de code heeft ondertekend en dat deze daarna niet is gewijzigd. Bij Stuxnet en SolarWinds was kwaadaardige code met echte of gestolen certificaten ondertekend.

Wat gebeurt er met een handtekening als het certificaat verloopt?

Als de code bij het ondertekenen een tijdstempel kreeg, blijft de handtekening na het verlopen van het code-signingcertificaat geldig. Zonder tijdstempel weigeren veel systemen de code na de vervaldatum. Voor OT-software die jaren later nog wordt geïnstalleerd, is timestamping daarom essentieel.

Hoe lang is een code-signingcertificaat geldig?

Publiek vertrouwde code-signingcertificaten die vanaf 1 maart 2026 worden uitgegeven, zijn maximaal 460 dagen geldig. Eerder was dat maximaal 39 maanden. Interne certificaten van een eigen CA volgen het beleid van de organisatie zelf.

Waarom moet de signeersleutel in een HSM staan?

Een gestolen code-signingsleutel laat een aanvaller malware maken die er legitiem uitziet. Een HSM voert de ondertekening uit zonder dat de private key het apparaat verlaat. Voor publiek vertrouwde code-signingcertificaten is hardware-opslag sinds juni 2023 verplicht.

Kan ik eigen PLC-code of scripts zelf ondertekenen?

Eigen scripts, bibliotheken en software kunt u met een certificaat van een interne CA of een publieke CA ondertekenen. Of PLC-projecten zelf ondertekend kunnen worden, hangt af van de leverancier en de engineeringsoftware. Controleer dat per platform en leg het vast in uw change management.

📌 Samengevat

Code signing is een onmisbare beveiligingslaag in OT-omgevingen voor het vertrouwen in software en Firmware: het bewijst wie code heeft gemaakt en dat die onderweg niet is gewijzigd. Zonder digitale handtekening is er geen garantie dat de code origineel en onveranderd is. Met de handtekening alleen bent u er niet: bescherm de signeersleutel in een HSM, gebruik tijdstempels, controleer elke update en combineer code signing met een veilig ontwikkelproces, SBOM en patchmanagement.