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

Introductie

Het Wet Cyberweerbaarheid (CRA) is een EU-verordening die gericht is op het verbeteren van de cyberbeveiliging en digitale veerkracht voor alle producten met digitale elementen, waaronder IoT-apparaten, medische apparatuur en industriële systemen. Deze verordening stelt gemeenschappelijke normen vast voor hardware- en softwareproducten die direct of indirect verbinding maken 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. 

Wat is code-ondertekening? 

Code ondertekening is als een digitale stempel die bewijst dat software of updates afkomstig zijn van een vertrouwde bron en niet zijn gewijzigd. Het werkt met een paar speciale sleutels, één privé en één openbaar, die de identiteit van de software helpen 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 geverifieerde en ongewijzigde code wordt uitgevoerd telkens wanneer een apparaat wordt ingeschakeld. Het creëert een vertrouwensketen, een stapsgewijs validatieproces dat begint in 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 

• Beperk de toegang tot de privésleutel tot geautoriseerd personeel door middel van sterke toegangscontroles: Dit is in lijn met artikel 13(1)(c) van de CRA, waarin staat dat fabrikanten verplicht zijn passende toegangscontrole en veilig beheer van cryptografische sleutels te implementeren. Hoewel de CRA geen expliciete verplichting oplegt voor multifactorauthenticatie of rolgebaseerde toegang, worden deze praktijken sterk aanbevolen om te voldoen aan de algemene beveiligingsdoelstellingen. 
• Voeg tijdstempels toe aan handtekeningen om de geldigheid van het certificaat te behouden nadat het verlopen is: In overeenstemming met de CRA-vereisten voor software-integriteit en traceerbaarheid, zoals uiteengezet in Artikel 6 en Bijlage I, zorgt het bijhouden van tijdstempels ervoor dat de authenticiteit van codehandtekeningen verifieerbaar blijft, zelfs nadat het certificaat is verlopen. Dit draagt ​​bij aan de naleving van traceerbaarheidsdoelstellingen. 
• Houd aparte cryptografische sleutels aan voor test- en productieomgevingen: Artikel 13 vereist dat fabrikanten een risicogebaseerde scheiding van omgevingen implementeren om beveiligingsrisico's te beperken. Hoewel de CRA geen expliciete aparte sleutels voorschrijft, is dit een aanbevolen best practice die consistent is met de CRA-doelen om aanvalsoppervlakken en omgevingsspecifieke risico's te verminderen. 
• Implementeer fraudebestendige auditlogging en gedetailleerde technische documentatie: Artikel 31 schrijft het bijhouden van uitgebreide technische documentatie voor, inclusief audit trails. Het bijhouden van veilige, onveranderlijke logs van codeondertekeningsactiviteiten ondersteunt de traceerbaarheid en verantwoording bij conformiteitsbeoordelingen. 
• Integreer malware- en kwetsbaarheidsscans vóór codeondertekening: Bijlage I vereist dat producten worden geleverd zonder bekende, exploiteerbare kwetsbaarheden of malware. Door geautomatiseerd scannen te integreren in het ondertekeningsproces, kunnen fabrikanten voldoen aan deze essentiële cybersecurityvereiste en een veilige productlevering ondersteunen. 
• Roteer cryptografische sleutels regelmatig en beheer de levenscyclus van de sleutels op een veilige manier: Dit is in overeenstemming met CRA-artikel 13(1)(c) en de vereisten voor het omgaan met kwetsbaarheden in Bijlage I Deel II. Effectief beheer van de levenscyclus van sleutels, met inbegrip van periodieke rotatie, vermindert de risico's die samenhangen met inbreuken op sleutels gedurende de levenscyclus van het product. 
• Integreer geautomatiseerde codeondertekening in gecontroleerde CI/CD-pijplijnen: Artikel 13(1)(b) verplicht fabrikanten om strikte controle en beveiliging van softwareproductie- en updateprocessen te garanderen. Het automatiseren van codeondertekening binnen gecontroleerde build- en implementatiepijplijnen helpt bij het handhaven van beleid en het waarborgen van de beveiliging van de toeleveringsketen. 
• Stel duidelijke en snelle intrekkingsprocedures in voor gecompromitteerde sleutels: Artikel 13(1)(e) vereist dat fabrikanten snel reageren op beveiligingsincidenten, inclusief intrekking en mitigatie. Duidelijke intrekkingsmechanismen zorgen voor snelle ongeldigverklaring van gecompromitteerde codeondertekeningssleutels en voorkomen zo ongeautoriseerde of kwaadaardige softwaredistributie. 

Hoe encryptieconsultancy kan helpen 

Encryption Consulting biedt CodeSign Secure, een uitgebreide codeondertekeningsoplossing op ondernemingsniveau die is ontworpen om organisaties te helpen voldoen aan de strenge cyberbeveiligingsvereisten, zoals die van 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.