Digitaal vertrouwen opbouwen door middel van CRA-gecoördineerde codeondertekening

Introductie

De Cyber ​​Resilience Act (CRA) is een EU-verordening die tot doel heeft de cyberbeveiliging en digitale weerbaarheid te verbeteren voor alle producten met digitale elementen, waaronder IoT-apparaten, medische apparaten en industriële systemen. De verordening stelt gemeenschappelijke normen vast voor hardware- en softwareproducten die direct of indirect verbonden zijn met een apparaat of netwerk.

Volgens de CRA moeten fabrikanten de beveiliging gedurende de gehele levenscyclus van hun product waarborgen (artikel 13) door te voldoen aan vereisten zoals het melden van beveiligingsincidenten en het automatisch aanbieden van beveiligingsupdates. Hiermee wordt het cruciale belang van veilige codering en ontwikkelingspraktijken in deze uiteenlopende digitale producten benadrukt. 

Niet-naleving van CRA-regels is kostbaar, met mogelijke boetes tot € 15 miljoen of 2.5% van de wereldwijde omzet. Dit onderstreept de noodzaak van sterke cryptografische controles, veilige codeondertekening en end-to-end integriteit van de softwaretoeleveringsketen om continue CRA-naleving en digitaal vertrouwen te garanderen. 

CRA-conforme codeondertekening, gedefinieerd: een codeondertekeningsprogramma waarbij elke controle, sleutelopslag, toegangsscheiding, tijdstempeling, intrekking en auditregistratie is gekoppeld aan een specifiek CRA-artikel, met een duidelijke scheiding tussen wat de regelgeving expliciet voorschrijft en wat een sterk aanbevolen praktijk is om de bredere doelstellingen van 'security by design' te bereiken, ondersteund door bewijs dat daadwerkelijk kan worden geverifieerd door een conformiteitsbeoordeling.

Key Takeaways

• Niet elke goede praktijk voor het ondertekenen van code is een letterlijke CRA-verplichting; verschillende, zoals MFA bij toegang tot ondertekening of aparte test-/productiesleutels, zijn sterk aanbevolen manieren om te voldoen aan een bredere, op risico's gebaseerde verplichting die de CRA wél expliciet stelt. Dit onderscheid is belangrijk voor de manier waarop u de naleving documenteert.
• Deze pagina koppelt individuele, aan de CRA-richtlijnen afgestemde codeondertekeningspraktijken aan specifieke artikelen, vereiste voor vereiste. Voor de architectuur met twee regimes die de CRA combineert met de stemvereisten van de CA/Browser Forum en een geconsolideerde actiechecklist, zie CRA-nalevingsarchitectuur voor veilige codeondertekening.
• Het HSM-mandaat van het CA/Browser Forum (FIPS 140-2 niveau 2 of hoger, van kracht vanaf 1 juni 2023) is van toepassing op alle publiekelijk vertrouwde codeondertekeningssleutels, ongeacht de reikwijdte van de CRA; CRA-naleving vervangt deze basis niet, maar bouwt er bovenop.
• Een verbroken vertrouwensketen vereist geen gestolen sleutel: de BootHole-kwetsbaarheid bracht beveiligd opstarten in gevaar door een fout in de verificatielogica van GRUB2 zelf, terwijl geldige sleutels en beveiligd opstarten wel degelijk waren ingeschakeld.

Wat is code-ondertekening? 

Codeondertekening is als een digitale stempel die bewijst dat software of updates afkomstig zijn van een betrouwbare bron en niet zijn gewijzigd. Het werkt met behulp van een paar speciale sleutels, een privésleutel en een openbare sleutel, die helpen de identiteit van de software te verifiëren en ervoor zorgen dat deze veilig te gebruiken is.

Er zijn twee hoofdtypen codeondertekeningscertificaten: 

• Standaardcertificaten: Deze bewijzen dat de software van de juiste uitgever afkomstig is en niet is gewijzigd. 
• Extended Validation (EV)-certificaten: Deze gaan een stap verder door strengere identiteitscontroles en extra beveiligingsmaatregelen te vereisen, zoals het opslaan van sleutels op beveiligde hardware. Producten die voldoen aan de Cyber ​​Resilience Act gebruiken vaak EV-certificaten omdat ze meer vertrouwen bieden en minder waarschuwingen geven wanneer gebruikers de software installeren.

 Kortom, codeondertekening zorgt ervoor dat gebruikers software kunnen vertrouwen door te bevestigen waar de software vandaan komt en te garanderen dat deze veilig en ongewijzigd is.

Hoe codeondertekening werkt

• Een unieke vingerafdruk creëren:  Een cryptografische hash (zoals SHA-256) wordt gegenereerd door de software. Deze hash fungeert als een unieke digitale vingerafdruk; als er ook maar één byte verandert, verandert de vingerafdruk ook. 
• De digitale handtekening genereren: De uitgever versleutelt die hash met zijn/haar privésleutel, waardoor een digitale handtekening ontstaat die uniek is voor zowel de software als de ondertekenaar. 
• Identiteitsbewijs bijvoegen:  De digitale handtekening en een codeondertekeningscertificaat (dat de openbare sleutel van de uitgever en geverifieerde identiteit bevat) worden meegeleverd met de software. 
• De code verifiëren:  Wanneer gebruikers de software downloaden of installeren, gebruikt hun systeem de openbare sleutel om de handtekening te verifiëren. Als deze overeenkomt met de huidige hash van de software, wordt de code bevestigd als authentiek en ongewijzigd. 

Waarom codeondertekening belangrijk is voor CRA-naleving

Codeondertekening speelt een cruciale rol bij het voldoen aan de CRA-vereisten door te garanderen dat software authentiek, betrouwbaar en beschermd is tegen manipulatie. Het ondersteunt direct verschillende belangrijke compliance-gebieden: 

• Beveiliging in de toeleveringsketenCodeondertekening is essentieel voor CRA-naleving, omdat het de beveiliging van de toeleveringsketen direct versterkt door de authenticiteit en integriteit van elke softwarecomponent te verifiëren, inclusief afhankelijkheden die vatbaar zijn voor manipulatie of kwaadaardige invoeging. Dit garandeert dat de aan gebruikers geleverde software betrouwbaar en fraudebestendig is, en voldoet aan de kritische CRA-vereisten voor software-integriteit, traceerbaarheid en toeleveringsketen risico beperking. 
• Integriteitsbescherming: De CRA vereist dat software, opdrachten en configuraties veilig blijven tegen ongeautoriseerde wijzigingen (Artikel 6 en Bijlage I specificeren technische vereisten voor cyberbeveiliging). Codeondertekening voldoet hieraan door cryptografische handtekeningen te gebruiken om aan te tonen dat de software niet is gewijzigd sinds de ondertekening, waardoor zowel ontwikkelaars als eindgebruikers worden beschermd tegen gecompromitteerde code. 
• Veilig opstarten: Volgens de CRA moeten apparaten de authenticiteit van software verifiëren in elke opstartfase (artikelen 6 en 13, ondersteund door bijlage I). Veilige opstartmechanismen zijn afhankelijk van codeondertekening om een ​​vertrouwensketen tot stand te brengen, beginnend bij hardwaregebaseerde roots en zich uitstrekkend door elke laag firmware en software die tijdens het opstarten wordt geladen. 
• Veilige updates: Om te voldoen aan de CRA-normen, mogen apparaten alleen authentieke en vertrouwde software-updates accepteren (artikelen 5, 6 en 13). Codeondertekening zorgt ervoor dat updates worden geverifieerd vóór installatie, waardoor systemen worden beschermd tegen kwaadaardige of ongeautoriseerde wijzigingen. 
• Controleerbaarheid en traceerbaarheid: Om te voldoen aan de CRA-vereisten, moeten organisaties aantonen dat ze controle hebben over en verantwoording afleggen over softwareondertekeningsprocessen (artikelen 13 en 31). Codeondertekeningssystemen genereren uitgebreide audit trails die vastleggen wie wat, wanneer en met welke sleutels heeft ondertekend, wat duidelijk bewijs oplevert tijdens CRA-conformiteitsbeoordelingen. 

Secure Boot: het opbouwen van een vertrouwensketen 

Secure boot is een hoeksteen van CRA-compliance en zorgt ervoor dat alleen geauthenticeerde en ongewijzigde code wordt uitgevoerd telkens wanneer een apparaat wordt ingeschakeld. Het creëert een vertrouwensketen, een stapsgewijs validatieproces dat begint bij de hardware en zich uitstrekt tot elke softwarelaag van het systeem.

• Hardware Root of Trust (RoT): Het beveiligde opstartproces begint met de hardware root of trust, meestal een onveranderlijke boot-ROM die rechtstreeks in de chip van het apparaat is ingebouwd. Praktische implementaties van hardware root of trust omvatten technologieën zoals Trusted Platform Module (TPM) en Secure Enclave. Deze modules bewaren en beschermen hardgecodeerde publieke sleutelhashes of root-ondertekeningssleutels die na de productie niet meer kunnen worden gewijzigd. Wanneer het apparaat wordt opgestart, wordt deze ROM of beveiligde module als eerste uitgevoerd, waarmee de trust chain wordt verankerd voor alles wat vervolgens wordt geladen.  
• Bootloaderverificatie en cryptografische flexibiliteit: Nadat de beveiligde opstartprocedure is gestart, verifieert het opstart-ROM de digitale handtekening van de bootloader met behulp van een vertrouwde openbare sleutel die is opgeslagen in beveiligde hardware (bijv. TPM of Secure Enclave). Als de verificatie mislukt, stopt het apparaat of gaat het naar de herstelmodus om ongeautoriseerde code te blokkeren. Na validatie controleert de bootloader de daaropvolgende softwarecomponenten, zoals secundaire bootloaders of de kernel van het besturingssysteem. Deze fasen kunnen worden bijgewerkt om de beveiliging te verbeteren of nieuwe cryptografische algoritmen te implementeren zonder de vertrouwensketen te verbreken.
• Verificatie van besturingssysteem en applicatie: Nadat de kernel en de belangrijkste OS-componenten zijn geladen, vervolgt Secure Boot zijn validatieketen. Het verifieert de integriteit van rootbestandssystemen, apparaatstuurprogramma's en applicaties op gebruikersniveau en voert deze alleen uit als hun cryptografische handtekeningen geldig zijn. In geavanceerdere systemen kan deze bescherming worden uitgebreid naar firmware, versleutelde bestandssystemen en individuele applicaties, waardoor vertrouwen op elke operationele laag behouden blijft. 
• Implementatie in de praktijk: In de praktijk maakt veilig opstarten gebruik van industriestandaard cryptografie, doorgaans RSA of ECC voor digitale handtekeningen en SHA-256 voor hashing. Elke fase van het opstartproces wordt ondertekend door een vertrouwde instantie en elke update of configuratiewijziging moet vóór uitvoering worden gevalideerd. Veel moderne apparaten implementeren ook certificaatgebaseerde sleutelhiërarchieën en maken gebruik van Hardwarebeveiligingsmodules (HSM's) om persoonlijke sleutels veilig op te slaan.

Als deze vertrouwensketen ooit wordt verbroken, bijvoorbeeld als een gelekte of ongepatchte sleutel een aanvaller toegang geeft tot een kwaadaardige bootloader, kan de beveiliging tegen veilig opstarten volledig falen. De "BootHole"-kwetsbaarheid is een duidelijk voorbeeld van hoe aanvallers kwetsbaarheden in de handtekeningcontroles van GRUB2 misbruikten om de controle over apparaten over te nemen, ondanks dat veilig opstarten was ingeschakeld. Dit laat zien waarom apparaten met CRA-bescherming sterke cryptografie moeten gebruiken, ondertekeningssleutels moeten beveiligen en beveiligingspatches up-to-date moeten houden om deze risico's te vermijden. 

De cruciale rol van HSM's 

Het beschermen van de privésleutels die voor codeondertekening worden gebruikt, is essentieel. Als deze sleutels worden gecompromitteerd, kunnen aanvallers schadelijke software implementeren die legitiem lijkt. Om dit te voorkomen, moeten codeondertekeningssleutels worden opgeslagen in HSM's: fraudebestendige apparaten die cryptografische sleutels veilig genereren, opslaan en gebruiken zonder ze bloot te stellen aan software of externe toegang. 

Sinds 1 juni 2023 vereist het CA/Browser Forum dat alle privésleutels voor codeondertekening worden opgeslagen op hardware die gecertificeerd is volgens FIPS 140-2 Level 2 of hoger (of een gelijkwaardige standaard) voor het verkrijgen van betrouwbare codeondertekeningscertificaten. Veel moderne HSM's voldoen ook aan de nieuwere FIPS 140-3-standaard en bieden een toekomstbestendige optie. Bovendien ondersteunen deze HSM's vaak ondertekening op afstand en in de cloud met beveiligde attestatie, waardoor verspreide teams cryptografische sleutels veilig kunnen beheren zonder de beveiliging in gevaar te brengen. Dit verbetert de beveiliging van de softwaretoeleveringsketen en sluit aan bij actuele cybersecuritynormen. 

Voordelen van HSM's zijn onder meer:

• Niet-extraheerbare sleutels zijn beveiligd in de HSM. 
• Detectie van manipulatie met automatische vernietiging van sleutels bij inbraakpogingen. 
• Toegangscontrole op basis van rollen, zodat alleen geautoriseerd personeel toegang heeft tot de sleutels. 
• Onveranderlijke auditlogs van alle cryptografische bewerkingen. 

Best practices voor CRA-gealigneerde codeondertekening 

De onderstaande tabel maakt onderscheid tussen wat de CRA daadwerkelijk voorschrijft en wat een sterk aanbevolen werkwijze is om daaraan te voldoen, aangezien het door elkaar halen van beide een veelgemaakte fout is in de documentatie tijdens een conformiteitsbeoordeling.

Praktijk	Status	CRA-basis
Toegangscontrole en veilig sleutelbeheer	Nodig	Artikel 13, lid 1, onder c)
Specifiek mechanisme: MFA of op rollen gebaseerde toegang	Aanbevolen (geen specifiek mandaat van de CRA)	Ondersteunt de algemene verplichting van artikel 13(1)(c).
Het voorzien van een tijdstempel van gesigneerde artefacten	Aanbevolen	Ondersteunt de traceerbaarheidsdoelstellingen van artikel 6 / bijlage I.
Aparte ondertekeningssleutels voor test- en productieomgevingen	Aanbevolen (niet expliciet gespecificeerd)	Ondersteunt de op risico's gebaseerde milieuscheiding van artikel 13.
Fraudebestendige auditlogboeken en technische documentatie	Nodig	Artikel 31
Voorafgaande scan op malware/kwetsbaarheden	Vereist (producten moeten zonder bekende exploiteerbare kwetsbaarheden worden verzonden)	Bijlage I
Periodieke sleutelrotatie	Aanbevolen	Ondersteunt de afhandeling van kwetsbaarheden in artikel 13(1)(c) en bijlage I deel II.
Geautomatiseerd ondertekenen in gecontroleerde CI/CD-pipelines	Vereist (strikte controle van productie-/updateprocessen)	Artikel 13 (1) (b)
Gedocumenteerde, geteste intrekkingprocedure	Vereist (snelle reactie op incidenten)	Artikel 13, lid 1, onder e)

Vernieuwingsfrequentie volgens de huidige stemregels

Los van de CRA zelf heeft het CA/Browser Forum de maximale geldigheidsduur van publiekelijk erkende codeondertekeningscertificaten teruggebracht tot 460 dagen voor certificaten die op of na 1 maart 2026 zijn uitgegeven. Elk CRA-conform sleutelbeheerproces dat u opzet, moet uitgaan van een verlenging ongeveer elke 15 maanden, in plaats van de 39 maanden die veel teams gewend waren. Een verlopen certificaat blokkeert namelijk het ondertekenen van nieuwe releases, ongeacht hoe CRA-conform de rest van de pipeline is.

Hoe encryptieconsultancy kan helpen 

Encryption Consulting biedt CodeSign Secure aan , een uitgebreide codeondertekeningsoplossing van enterprise-niveau die is ontworpen om organisaties te helpen voldoen aan strenge cybersecurity-eisen, zoals die welke worden opgelegd door de EU CRA.

CodeSign Secure pakt de belangrijkste uitdagingen op het gebied van CRA-naleving aan door het volgende te bieden: 

• HSM-ondersteunde sleutelbeveiliging:Privé-ondertekeningssleutels worden veilig opgeslagen in FIPS 140-2 Level 3-gecertificeerde HSM's. Hierdoor is er geen enkel risico op blootstelling of diefstal van de sleutel. Dit is volledig in overeenstemming met de branchevereisten en best practices die essentieel zijn voor CRA-naleving. 
• Automatisering en CI/CD-integratieDe oplossing integreert naadloos met populaire DevOps-pipelines en geautomatiseerde build-workflows, zodat beveiliging nooit de ontwikkelingssnelheid of innovatie in de weg staat. 
• Beleidshandhaving en gedetailleerde toegangscontroleOrganisaties kunnen gedetailleerde beveiligingsbeleidsregels definiëren en afdwingen, ondertekeningsmachtigingen automatiseren en het beheer van de levenscyclus van ondertekening voor alle teams beheren. Zo voldoen ze aan de audit- en verantwoordingsvereisten van CRA. 
• Uitgebreide audittrails:Gedetailleerde gebeurtenisregistratie, goedkeuringen op meerdere niveaus en quorumcontroles zorgen ervoor dat elke ondertekeningsactie wordt gevolgd, gevalideerd en voldoet aan de eisen, waardoor conformiteitsbeoordelingen door CRA's worden vereenvoudigd. 
• Schaalbare implementatiemodellen:Encryption Consulting ondersteunt implementaties in de cloud, hybride en on-premises, waardoor organisaties van elke omvang robuuste codeondertekening kunnen implementeren zonder overmatige infrastructuurkosten. 
• Ondersteuning van hybride ondertekeningsalgoritmen (traditioneel en PQC): Wij maken het gebruik van zowel traditionele cryptografische algoritmen zoals RSA & ECC (ECDSA) mogelijk als post-kwantumcryptografie (PQC) algoritmen zoals ML-KEM, ML-DSA, LMS en meer in hybride ondertekeningsworkflows. Dit garandeert de veerkracht van digitale handtekeningen op lange termijn tegen opkomende kwantumbedreigingen. 

Een organisatie die IoT-apparaten produceert, ondervond uitdagingen met betrekking tot CRA-compliance, met name wat betreft het veilig beheren van codeondertekeningssleutels en het aantonen van traceerbaarheid voor elke release. We hebben deze problemen aangepakt door HSM's in hun omgeving te integreren voor sleutelbeveiliging, multi-factorauthenticatie voor toegang en geautomatiseerde codeondertekening in hun CI/CD-pijplijn. Fraudebestendige auditlogging werd ook ingeschakeld om te voldoen aan de strenge traceerbaarheids- en documentatievereisten van CRA, terwijl strenge procedures voor het intrekken van sleutels ervoor zorgden dat gecompromitteerde sleutels snel ongeldig konden worden gemaakt, wat cruciaal is voor de afhandeling van kwetsbaarheden en de respons van CRA op incidenten. 

Conclusie

Voldoen aan de EU CRA draait om het opbouwen van vertrouwen in elke regel code die uw organisatie levert. Codeondertekening, gecombineerd met secure boot en HSM's, zorgt ervoor dat alleen geverifieerde, manipulatievrije software gebruikers en apparaten bereikt. Organisaties wordt geadviseerd een CRA-gapanalyse uit te voeren of hun huidige codeondertekeningsworkflows te controleren om compliance-hiaten te identificeren en aan te pakken.

Een goed geïmplementeerde CRA-naleving beperkt risico's in de toeleveringsketen, maakt veilige updates mogelijk en bevordert het vertrouwen van gebruikers. Tegelijkertijd worden ondertekeningssleutels beschermd, audit trails onderhouden en codeondertekening geïntegreerd in ontwikkelingsworkflows. Dit versterkt de beveiliging en zorgt voor volledige afstemming met de CRA-vereisten. 

Met CodeSign Secure van Encryption Consulting kunt u compliance automatiseren en vereenvoudigen, uw softwaretoeleveringsketen beschermen en innovatie veilig voortzetten. In de huidige, verbonden wereld is veilige codeondertekening niet alleen een stap in de compliance; het is de manier waarop u bewijst dat uw software betrouwbaar is. 

Veelgestelde Vragen / FAQ

Vereist de CRA specifiek codeondertekening?

De CRA noemt "codeondertekening" niet als een afzonderlijke eis, maar de verplichtingen inzake integriteit, veilige updates en traceerbaarheid onder artikel 6, 13 en bijlage I zijn in de praktijk moeilijk te vervullen zonder codeondertekening. Codeondertekening is het praktische mechanisme dat de meeste fabrikanten gebruiken om aan die verplichtingen te voldoen, en geen afzonderlijk benoembaar mandaat.

Is multifactorauthenticatie bij het ondertekenen van toegang een vereiste van de CRA (Canada Revenue Agency)?

Niet expliciet. Artikel 13(1)(c) vereist in het algemeen passende toegangscontrole en veilig sleutelbeheer; MFA is een sterk aanbevolen manier om aan die verplichting te voldoen, geen expliciete vereiste op zich.

Waarin verschilt dit van het andere artikel van Encryption Consulting over naleving van de CRA-wetgeving?

Deze pagina koppelt individuele codeondertekeningspraktijken aan specifieke CRA-artikelen, één vereiste per keer. De CRA-nalevingsarchitectuur voor veilige codeondertekening behandelt de bredere architectuur, inclusief hoe CRA-verplichtingen samenwerken met afzonderlijke CA/Browser Forum-certificaatregels op dezelfde ondertekeningsinfrastructuur, en biedt een geconsolideerde actiechecklist.

Kan een vertrouwensketen verbroken worden zonder dat er een ondertekeningssleutel gestolen is?

Ja. De BootHole-kwetsbaarheid bracht Secure Boot in gevaar door een fout in de manier waarop GRUB2 handtekeningen controleerde, niet door sleuteldiefstal. De sleutels bleven geldig en Secure Boot bleef ingeschakeld; de verificatielogica zelf was het zwakke punt.