Inzicht in de codeondertekeningsvereisten van het CA/Browser Forum  

In juni 2023 heeft het CA/Browser Forum een ​​belangrijke update doorgevoerd in hun vereisten voor codeondertekening. Deze update heeft directe gevolgen voor ontwikkelaars, DevOps-teams en bedrijven die afhankelijk zijn van publiekelijk vertrouwde certificeringsinstanties (CA's ) voor het ondertekenen en beveiligen van hun software. Deze updates, die op 1 juni 2023 van kracht werden, schrijven voor dat privésleutels voor codeondertekening veilig moeten worden opgeslagen en beschermd in een gecertificeerde hardwarebeveiligingsmodule (HSM). Deze wijziging is van toepassing op zowel Extended Validation (EV) -certificaten als niet-EV-certificaten.

Een tweede bindende vereiste volgde: Ballot CSC-31 beperkt de geldigheidsduur van codeondertekeningscertificaten tot 460 dagen, ingaande 1 maart 2026 , ter vervanging van de eerdere meerjarige uitgifteperiodes die sommige certificeringsinstanties aanboden. Samen vormen deze twee mandaten, de HSM-vereiste en de geldigheidsbeperking, de huidige bindende basislijn van het CA/B Forum voor publiekelijk vertrouwde codeondertekeningscertificaten.

Kort samengevat: vanaf 1 juni 2023 moeten privésleutels voor codeondertekening worden gegenereerd en opgeslagen in een FIPS 140-2 Level 2 (of Common Criteria EAL 4+) HSM; vanaf 1 maart 2026 is de geldigheidsduur van certificaten beperkt tot 460 dagen. Beide zijn vereisten, geen aanbevelingen, en aanvragen voor niet-conforme uitgifte worden afgewezen door certificeringsinstanties die de basislijn handhaven.

Key Takeaways

• De HSM-verplichting (1 juni 2023) en de maximale geldigheidsduur van 460 dagen (1 maart 2026) zijn beide strikte vereisten die door certificeringsinstanties bij uitgifte worden gehandhaafd, en geen interne richtlijnen voor beste praktijken die een organisatie naar eigen inzicht kan negeren.
• De limiet van 460 dagen betekent dat verlenging nu ongeveer jaarlijks plaatsvindt in plaats van elke 1-3 jaar. Dit verhoogt de operationele risico's van de HSM-integratie en de CI/CD-automatiseringsuitdagingen die hieronder worden besproken, aangezien wrijving bij verlenging nu veel vaker voorkomt.

Checklist voor nalevingsaudit

1. Bevestig dat de ondertekeningssleutel is gegenereerd binnen een HSM die is gecertificeerd volgens FIPS 140-2 niveau 2 of Common Criteria EAL 4+, en er nooit vandaan is geëxporteerd.
2. Controleer of de geldigheidsduur van het certificaat bij uitgifte of verlenging niet langer is dan 460 dagen.
3. Zorg ervoor dat elke handtekening een betrouwbare tijdstempel bevat, zodat de handtekening geldig blijft nadat het certificaat zelf is verlopen.
4. Bevestig dat er een gedocumenteerde intrekkingsprocedure bestaat en dat deze is getest, en niet alleen op papier staat.
5. Bevestig dat de verlenging specifiek wordt bijgehouden binnen een periode van 460 dagen, en niet op basis van een oude meerjarige aanname die is overgebleven van vóór stemming CSC-31.

Waarom de HSM-vereiste?

De nieuwe eisen vloeien voort uit de behoefte aan strengere beveiligingsmaatregelen bij softwareontwikkeling. Nu cyberaanvallen steeds geavanceerder worden, is het cruciaal om de integriteit van software te waarborgen vanaf het moment dat deze wordt ondertekend. Het beschermen van de privésleutels voor codeondertekening in een HSM (Hardware Security Module) verkleint het risico op sleutelcompromis aanzienlijk, omdat HSM's zijn ontworpen om manipulatiebestendig te zijn en een veilige omgeving te bieden voor cryptografische bewerkingen.

Met ingang van 1 juni 2023 moeten alle aanvragers van certificaten een HSM gebruiken die aan de volgende normen voldoet:

• FIPS 140-2 Niveau 2
• Gemeenschappelijke criteria EAL 4+

Deze certificeringen worden algemeen erkend als industriestandaarden voor veilige cryptografische modules en garanderen dat persoonlijke sleutels worden beschermd in een hardwareomgeving die niet kan worden omzeild of gemanipuleerd.

Belangrijkste uitdagingen onder de nieuwe codeondertekeningsvereisten

Hoewel de overstap naar het gebruik van HSM's voor codeondertekening een positieve ontwikkeling is voor de beveiliging, brengt het ook een aantal technische uitdagingen met zich mee die moeten worden aangepakt:

1. Bewijs van naleving van de HSM-vereiste

   De eerste hindernis voor organisaties is aantonen dat hun privésleutels veilig zijn opgeslagen in een HSM. Dit bewijs is nodig om codeondertekeningscertificaten van certificeringsinstanties (CA's) te verkrijgen . Hoewel veel CA's USB-gebaseerde HSM's als oplossing aanbieden, kan dit omslachtig zijn voor bedrijven die in de cloud werken of die grootschalige codeondertekeningsprocessen vereisen. USB-HSM's zijn niet ideaal voor teams die verspreid zijn over verschillende regio's of voor bedrijven die snelle, grootschalige ondertekeningsprocessen nodig hebben.

   Een schaalbaardere optie is het gebruik van netwerkgebaseerde HSM's, die on-premises kunnen worden geïnstalleerd of gehuurd van cloudproviders. Oplossingen zoals AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM en nShield as a Service zijn allemaal haalbare opties. Het is echter essentieel om ervoor te zorgen dat de HSM die u kiest de verificatiemethoden ondersteunt die uw CA vereist, zoals sleutelattestatie (d.w.z. bevestiging dat de privésleutel zich in de HSM bevindt).

2. Beheren van sleutel- en certificaatbewerkingen

   Zodra uw privésleutels in een HSM zijn opgeslagen, wordt het beheer ervan complexer. HSM's zijn ontworpen om privésleutels binnen hun beveiligde omgeving te bewaren, wat betekent dat u sleutels niet rechtstreeks kunt exporteren voor gebruik in software. In plaats daarvan moet u via een tussenlaag met de HSM communiceren, zoals:

   • Sleutelgeneratie
   • Certificaatondertekeningsaanvraag (CSR) het aanmaken
   • Certificaat importeren/exporteren

   Voor deze bewerkingen zijn gespecialiseerde software en cryptografische tools nodig. Daarnaast moet u ervoor zorgen dat de toegangsrechten voor de sleutels strikt worden beheerd. Elke actie die op de HSM wordt uitgevoerd (bijvoorbeeld sleutelgebruik, certificaatuitgifte) moet worden geregistreerd en gecontroleerd om te voldoen aan de best practices voor beveiliging.

3. Codeondertekening integreren met HSM's

   Een van de meest technische uitdagingen is het integreren van HSM's met de verschillende codeondertekeningstools die op verschillende platforms worden gebruikt. De meeste organisaties gebruiken tools van derden voor codeondertekening, zoals:

   • tekentool (Windows)
   • jarsigner (Java)
   • Codesign en productsign (macOS)
   • rpmsign en debsign (Linux)
   • medeondertekenen (containers)

   Bij gebruik van een HSM vereist de integratie van deze tools het gebruik van platformspecifieke cryptografische serviceproviders (CSP's). Bijvoorbeeld:

   • Windows: Maakt gebruik van KSP (Key Storage Providers) of CSP (Cryptographic Service Providers).
   • Java: Maakt gebruik van JCE (Java Cryptography Extension) providers.
   • Linux: Maakt gebruik van PKCS#11-bibliotheken voor hardwaregebaseerde cryptografie.
   • MacOS: Maakt gebruik van CTK (Cryptographic Toolkit).

   Deze integraties kunnen lastig zijn, omdat de ondertekeningstools geconfigureerd moeten worden om via de juiste serviceprovider met de HSM te communiceren. Dit vereist vaak aangepaste configuratie en tests om een ​​naadloze werking te garanderen.

4. Optimalisatie van prestaties in CI/CD-pijplijnen

   Voor moderne DevOps-omgevingen zijn snelheid en efficiëntie van het grootste belang. Het introduceren van een HSM in uw codeondertekeningsproces kan de pipeline vertragen als deze niet correct is geconfigureerd. Een veelgebruikte aanpak die veel teams in eerste instantie hanteren, is het uploaden van de te ondertekenen gegevens, het uitvoeren van de ondertekening en vervolgens het ondertekende resultaat downloaden. Deze methode kan echter inefficiënt zijn, aanzienlijk bandbreedte verbruiken en vertragingen veroorzaken.

   Om dit proces te optimaliseren, schakelen veel organisaties over op client-side hashing. Bij client-side hashing wordt de code aan de clientzijde gehasht voordat deze ter ondertekening naar de HSM wordt verzonden. Dit vermindert de hoeveelheid overgedragen data en versnelt het ondertekeningsproces. Deze methode vereist echter wel dat zowel uw cryptografische serviceprovider als uw ondertekeningsinfrastructuur deze functie ondersteunen.

Hoe kan encryptieconsultancy uw compliancetraject ondersteunen?

Bij Encryption Consulting zijn we gespecialiseerd in het helpen van organisaties om te voldoen aan de eisen van CA/Browser Forum voor codeondertekening. Hieronder leggen we uit hoe we u kunnen ondersteunen tijdens deze overgang:

• HSM-integratieOf u nu kiest voor USB-gebaseerde of netwerkgebaseerde HSM's, wij helpen u graag bij het selecteren van de beste oplossing voor uw behoeften en begeleiden u door het integratieproces.

• Oplossingen voor sleutelbeheerWij zijn deskundig in het veilig beheren van uw privésleutels binnen HSM's. Zo zorgen wij ervoor dat alle sleutel- en certificaatbewerkingen veilig en in overeenstemming met de industrienormen worden uitgevoerd.

• Optimalisatie van codeondertekeningOns team kan u helpen uw codeondertekeningsproces te integreren met de benodigde cryptografische dienstverleners. Zo zorgen we ervoor dat het proces soepel en veilig verloopt op alle platforms.

• CI/CD-pijplijnoptimalisatieWij kunnen u helpen bij het implementeren van efficiënte codeondertekeningsstrategieën binnen uw CI/CD-pijplijn om prestatieverliezen tot een minimum te beperken.

Introductie van CodeSign Secure: de oplossing die u nodig hebt

Om uw codeondertekeningsproces nog veiliger en efficiënter te maken, raden we CodeSign Secure aan . Onze oplossing biedt een naadloze en geautomatiseerde aanpak voor codeondertekening die volledig integreert met HSM's. Zo voldoet u aan de nieuwste CA/Browser Forum-vereisten zonder de complexiteit. CodeSign Secure vereenvoudigt sleutelbeheer, verbetert de compliance en zorgt ervoor dat uw ondertekeningsprocessen snel en efficiënt blijven, zelfs in grootschalige DevOps-omgevingen.

Met CodeSign Secure krijgt u:

• Veilige integratie met hardwarebeveiligingsmodules
• Gestroomlijnd beheer van codeondertekeningscertificaten
• Verbeterde prestaties voor CI/CD-pijplijnen
• Volledige naleving van de codeondertekeningsvereisten van het CA/Browser Forum

Met CodeSign Secure helpen we u uw software veilig, conform de regelgeving en snel te houden . Neem vandaag nog contact op met Encryption Consulting om te ontdekken hoe we uw codeondertekeningsproces kunnen optimaliseren.

Vernieuwing, tijdstempeling en intrekking onder de nieuwe basislijn

De limiet van 460 dagen verandert het operationele ritme van codeondertekening meer dan dat het een individuele technische stap verandert. Daaruit vloeien direct drie gevolgen voort:

• Vernieuwing: Een certificaat dat is uitgegeven onder een oude meerjarige periode verloopt nog steeds volgens schema, maar elke verlenging of heruitgifte na 1 maart 2026 is beperkt tot 460 dagen, ongeacht wat de certificeringsinstantie eerder aanbood. De frequentie van verlengingen moet specifiek worden afgestemd op deze limiet en niet worden afgeleid van historische geldigheidsduur van certificaten.
• Tijdstempeling: Een betrouwbare tijdstempel op een handtekening registreert dat het certificaat geldig was op het moment van ondertekening. Nu certificaten ongeveer jaarlijks verlopen, is het toevoegen van een tijdstempel aan elke handtekening belangrijker geworden: zonder tijdstempel wordt de betrouwbaarheid van een ondertekend document gekoppeld aan de kortere geldigheidsperiode van het certificaat, waardoor de handtekening in feite vervalt met het certificaat, zelfs als er verder niets aan is veranderd.
• Herroeping: De HSM-vereiste beperkt de manieren waarop een sleutel kan worden gecompromitteerd, maar neemt de noodzaak van een geteste intrekkingsprocedure niet weg. Een gedocumenteerd plan dat nooit is geoefend, is een tekortkoming die een audit zou moeten signaleren; frequentere verlengingscycli bieden ook meer mogelijkheden om te controleren of het intrekkingsproces nog steeds van begin tot eind werkt.

Conclusie

De bijgewerkte codeondertekeningsvereisten van het CA/Browser Forum markeren een cruciale verschuiving naar strengere beveiligingspraktijken binnen de softwareontwikkelingscyclus. Hoewel de overstap naar HSM-gebaseerde codeondertekening technische uitdagingen met zich meebrengt, zijn de voordelen op het gebied van verbeterde beveiliging en integriteit onmiskenbaar. Door de HSM- integratie effectief te beheren, de workflows voor sleutelbeheer te optimaliseren en te zorgen voor gestroomlijnde prestaties in uw CI/CD-pipeline, kunt u aan de nieuwe standaarden voldoen en tegelijkertijd de ontwikkelingsefficiëntie behouden.

Encryption Consulting begeleidt u door elke stap van het proces en zorgt ervoor dat uw codeondertekeningspraktijken veilig zijn en volledig voldoen aan de nieuwste industrienormen.

Veelgestelde Vragen / FAQ

Is de maximale geldigheidsduur van 460 dagen een aanbeveling of een strikte vereiste?

Een strikte eis. Stemmingsvoorstel CSC-31 stelt een maximale geldigheidsduur van 460 dagen vast voor publiekelijk vertrouwde codeondertekeningscertificaten die op of na 1 maart 2026 worden uitgegeven of verlengd. Certificeringsinstanties die de CA/B Forum-basislijn hanteren, zullen geen certificaten met een langere geldigheidsduur uitgeven.

Geldt de HSM-vereiste ook voor interne certificaten die niet openbaar worden erkend?

De CA/B Forum-richtlijnen zijn van toepassing op publiekelijk vertrouwde certificeringsinstanties (CA's) en de certificaten die zij uitgeven. Intern uitgegeven certificaten vallen niet direct onder de stemprocedures van het CA/B Forum, hoewel veel organisaties dezelfde HSM-ondersteunde sleutelbeveiliging als intern beleid hanteren, aangezien de onderliggende beveiligingsreden niet verandert ongeacht wie het certificaat heeft uitgegeven.