Förstå kraven för kodsignering för CA/Browser Forum  

I juni 2023 lanserade CA/Browser Forum en betydande uppdatering av sina kodsigneringskrav, vilket direkt påverkar utvecklare, DevOps-team och företag som förlitar sig på offentligt betrodda certifikatutfärdare (CA:er ) för att signera och säkra sin programvara. Dessa uppdateringar, som trädde i kraft den 1 juni 2023, kräver att privata nycklar för kodsignering lagras och skyddas säkert i en certifierad Hardware Security Module (HSM). Denna ändring påverkar både Extended Validation (EV) och icke-EV-certifikat.

Ett andra bindande krav följde: Ballot CSC-31 begränsar giltigheten för kodsigneringscertifikat till 460 dagar, med verkan från och med den 1 mars 2026 , och ersätter de tidigare fleråriga utgivningsfönstren som vissa CA:er erbjöd. Tillsammans utgör dessa två mandat, HSM-kravet och giltighetstaket, den nuvarande bindande CA/B-forumets baslinje för offentligt betrodda kodsigneringscertifikat.

Kort sagt: från och med den 1 juni 2023 måste privata nycklar för kodsignering genereras och lagras i en FIPS 140-2 nivå 2 (eller Common Criteria EAL 4+) HSM; från och med den 1 mars 2026 är certifikatets giltighetstid begränsad till 460 dagar. Båda är krav, inte rekommendationer, och icke-kompatibla utfärdandeförfrågningar avvisas av CA:er som tillämpar baslinjen.

Key Takeaways

• HSM-mandatet (1 juni 2023) och giltighetsgränsen på 460 dagar (1 mars 2026) är båda hårda krav som upprätthålls av CA:er vid utfärdande, inte interna riktlinjer för bästa praxis som en organisation kan välja att hoppa över.
• 460-dagarstaket innebär att förnyelse nu sker ungefär årligen snarare än vart 1-3 år, vilket ökar de operativa insatserna för HSM-integrationen och CI/CD-automatiseringsutmaningarna som tas upp nedan, eftersom förnyelseproblem nu återkommer mycket oftare.

Checklista för efterlevnadsrevision

1. Bekräfta att signeringsnyckeln genererades inuti, och aldrig exporterades från, en HSM som är certifierad enligt FIPS 140-2 nivå 2 eller Common Criteria EAL 4+.
2. Bekräfta att certifikatets giltighetstid vid utfärdande eller förnyelse inte överstiger 460 dagar.
3. Bekräfta att varje signatur innehåller en betrodd tidsstämpel, så att signaturen förblir giltig även efter att certifikatet har löpt ut.
4. Bekräfta att det finns ett dokumenterat återkallelseförfarande som har testats, inte bara skrivits ner.
5. Bekräfta att förnyelsen spåras specifikt mot 460-dagarsfönstret, inte mot ett äldre flerårigt antagande från före omröstningen CSC-31.

Varför HSM-kravet?

De nya kraven härrör från behovet av starkare säkerhetsrutiner inom mjukvaruutveckling. I takt med att cyberattacker blir alltmer sofistikerade är det avgörande att säkerställa programvarans integritet från det ögonblick den signeras. Att skydda de privata nycklarna för kodsignering i en HSM minskar drastiskt risken för att nyckeln komprometteras, eftersom HSM:er är utformade för att vara manipulationssäkra och ge en säker miljö för kryptografiska operationer.

Från och med den 1 juni 2023 måste alla certifikatbegäranden använda en HSM som uppfyller följande standarder:

• FIPS 140-2 Nivå 2
• Gemensamma kriterier EAL 4+

Dessa certifieringar är allmänt erkända som branschstandarder för säkra kryptografiska moduler, vilket säkerställer att privata nycklar skyddas i en hårdvarumiljö som inte kan kringgås eller manipuleras.

Viktiga utmaningar enligt de nya kraven för kodsignering

Även om övergången till att använda HSM :er för kodsignering är ett positivt steg för säkerheten, medför det flera tekniska utmaningar som måste åtgärdas:

1. Bevisa överensstämmelse med HSM-kravet

   Det första hindret för organisationer är att bevisa att deras privata nycklar lagras säkert i en HSM. Detta bevis är nödvändigt för att erhålla kodsigneringscertifikat från CA:er . Även om många CA:er erbjuder USB-baserade HSM:er som en lösning, kan detta vara besvärligt för företag som arbetar i molnet eller med storskaliga kodsigneringskrav. USB-HSM:er är inte idealiska för team spridda över olika regioner eller de som behöver snabba, storskaliga signeringsoperationer.

   Ett mer skalbart alternativ är att använda nätverksbaserade HSM:er, som antingen kan vara lokalt installerade eller hyras från molnleverantörer. Lösningar som AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM och nShield as a Service är alla gångbara alternativ. Det är dock viktigt att se till att den HSM du väljer stöder de verifieringsmetoder som krävs av din CA, såsom nyckelattestering (dvs. bekräftelse av att den privata nyckeln finns i HSM:en).

2. Hantera nyckel- och certifikatoperationer

   När dina privata nycklar är säkrade i en HSM blir hanteringen av dem mer komplex. HSM:er är utformade för att förvara privata nycklar i sin säkra miljö, vilket innebär att du inte kan exportera nycklar direkt för användning i programvara. Istället måste du interagera med HSM:n via ett mellanliggande lager, till exempel:

   • Nyckelgenerering
   • Begäran om certifikatsignering (CSR) skapande
   • Import/export av certifikat

   Dessa operationer kräver specialiserad programvara och kryptografiska verktyg. Dessutom måste du se till att åtkomstbehörigheterna för nycklarna är noggrant kontrollerade. Varje åtgärd som utförs på HSM (t.ex. nyckelanvändning, certifikatutfärdande) måste loggas och granskas för att följa bästa säkerhetspraxis.

3. Integrera kodsignering med HSM:er

   En av de mest tekniska utmaningarna är att integrera HSM:er med de olika kodsigneringsverktyg som används på olika plattformar. De flesta organisationer använder tredjepartsverktyg för kodsignering, till exempel:

   • skyltverktyg (Windows)
   • jarsigner (Java)
   • Samdesign och produktdesign (macOS)
   • rpmsign och debsign (Linux)
   • medsignering (behållare)

   När man använder en HSM kräver integrationen av dessa verktyg användning av plattformsspecifika kryptografiska tjänsteleverantörer (CSP:er). Till exempel:

   • Windows: Använder KSP (Key Storage Providers) eller CSP (Cryptographic Service Providers).
   • Java: Använder JCE-leverantörer (Java Cryptography Extension).
   • Linux: Förlitar sig på PKCS#11-bibliotek för hårdvarubaserad kryptografi.
   • MacOS: Använder CTK (kryptografisk verktygslåda).

   Dessa integrationer kan vara knepiga, eftersom signeringsverktygen måste konfigureras för att interagera med HSM via lämplig tjänsteleverantör. Detta kräver ofta anpassad konfiguration och testning för att säkerställa smidig drift.

4. Optimera prestanda i CI/CD-pipelines

   För moderna DevOps-miljöer är hastighet och effektivitet av största vikt. Att introducera en HSM i kodsigneringsprocessen kan sakta ner pipelinen om den inte är korrekt konfigurerad. En vanlig metod som många team initialt använder är att ladda upp de data som ska signeras, utföra signeringsoperationen och sedan ladda ner det signerade resultatet. Denna metod kan dock vara ineffektiv, förbruka avsevärd bandbredd och orsaka förseningar.

   För att optimera den här processen byter många organisationer till klientsidig hashning. Med klientsidig hashning hashas koden på klientsidan innan den skickas till HSM för signering, vilket minskar mängden data som överförs och snabbar upp signeringsprocessen. Denna metod kräver dock att både din kryptografiska tjänsteleverantör och signeringsinfrastruktur stöder den här funktionen.

Hur krypteringskonsulting kan stödja din efterlevnadsprocess?

På Encryption Consulting specialiserar vi oss på att hjälpa organisationer att uppfylla kraven för kodsignering från CA/Browser Forum. Så här kan vi stödja er genom denna övergång:

• HSM-integrationOavsett om du väljer USB-baserade eller nätverksbaserade HSM:er kan vi hjälpa dig att välja den bästa lösningen för dina behov och vägleda dig genom integrationsprocessen.

• NyckelhanteringslösningarVi erbjuder expertis inom säker hantering av era privata nycklar inom HSM:er, och säkerställer att alla nyckel- och certifikatoperationer utförs säkert och i enlighet med branschstandarder.

• Optimering av kodsigneringVårt team kan hjälpa dig att integrera din kodsigneringsprocess med nödvändiga kryptografiska tjänsteleverantörer, vilket säkerställer att processen är smidig och säker på alla plattformar.

• CI/CD-pipelineoptimeringVi kan hjälpa er att implementera effektiva kodsigneringsstrategier inom er CI/CD-pipeline för att minimera eventuella prestandaproblem.

Introduktion till CodeSign Secure: Lösningen du behöver

För att göra din kodsigneringsprocess ännu säkrare och effektivare rekommenderar vi CodeSign Secure . Vår lösning erbjuder en sömlös och automatiserad metod för kodsignering som integreras helt med HSM:er, vilket hjälper dig att uppfylla de senaste kraven från CA/Browser Forum utan komplexiteten. CodeSign Secure förenklar nyckelhanteringen, förbättrar efterlevnaden och säkerställer att dina signeringsoperationer förblir snabba och effektiva, även i storskaliga DevOps-miljöer.

Med CodeSign Secure får du:

• Säker integration med hårdvarusäkerhetsmoduler
• Strömlinjeformad hantering av kodsigneringscertifikat
• Förbättrad prestanda för CI/CD-pipelines
• Fullständig efterlevnad av CA/Browser Forums kodsigneringskrav

Låt oss hjälpa dig att hålla din programvara säker, kompatibel och snabb med CodeSign Secure . Kontakta Encryption Consulting idag för att lära dig hur vi kan optimera din kodsigneringsprocess.

Förnyelse, tidsstämpling och återkallelse enligt den nya baslinjen

460-dagarsgränsen förändrar den operativa rytmen för kodsignering mer än den förändrar något enskilt tekniskt steg. Tre implikationer följer direkt av den:

• Förnyelse: Ett certifikat som utfärdats under ett äldre flerårigt fönster kommer fortfarande att löpa ut enligt schemat, men eventuella förnyelser eller återutgivningar efter den 1 mars 2026 är begränsade till 460 dagar oavsett vad certifikatutfärdaren tidigare erbjöd. Förnyelsetakten bör spåras specifikt mot detta tak, inte antas utifrån historiska certifikatlivslängder.
• Tidsstämpling: En betrodd tidsstämpel på en signatur registrerar att certifikatet var giltigt vid signeringstillfället. Eftersom certifikat nu löper ut ungefär en gång per år spelar tidsstämpling av varje signatur större roll, inte mindre: utan den blir en signerad artefakts förtroende knutet till certifikatets nu kortare giltighetsfönster, och signaturen upphör i praktiken att gälla tillsammans med certifikatet även om inget annat med det ändrats.
• Återkallande: HSM-kravet begränsar hur en nyckel kan komprometteras, men det eliminerar inte behovet av en testad återkallningsprocedur. En dokumenterad plan som aldrig har repeterats är en lucka som en revision bör upptäcka; tätare förnyelsecykler är också tätare möjligheter att verifiera att återkallelseprocessen fortfarande fungerar från början till slut.

Slutsats

De uppdaterade kraven för kodsignering från CA/Browser Forum markerar ett avgörande skifte mot starkare säkerhetsrutiner inom programvaruutvecklingens livscykel. Även om övergången till HSM-baserad kodsignering medför tekniska utmaningar, är fördelarna i form av förbättrad säkerhet och integritet obestridliga. Genom att effektivt hantera HSM- integration, optimera arbetsflöden för nyckelhantering och säkerställa effektiv prestanda i din CI/CD-pipeline kan du uppfylla de nya standarderna samtidigt som du bibehåller utvecklingseffektiviteten.

Encryption Consulting finns här för att vägleda dig genom varje steg i processen och säkerställa att dina kodsigneringsrutiner är säkra och helt i enlighet med de senaste branschstandarderna.

Vanliga frågor om partihandel med mat och dryck

Är giltighetsgränsen på 460 dagar en rekommendation eller ett strikt krav?

Ett hårt krav. Enligt omröstning CSC-31 är 460 dagar den maximala giltighetsperioden för offentligt betrodda kodsigneringscertifikat som utfärdats eller förnyats den 1 mars 2026 eller senare. CA:er som tillämpar CA/B-forumets baslinje kommer inte att utfärda certifikat med längre giltighetstid.

Gäller HSM-kravet även interna, icke-offentligt betrodda certifikat?

CA/B-forumets baslinje styr offentligt betrodda CA:er och de certifikat de utfärdar. Internt utfärdade certifikat är inte direkt bundna av CA/B-forumets omröstningar, även om många organisationer tillämpar samma HSM-baserade nyckelskydd som en intern policy oavsett, eftersom den underliggande säkerhetsrationalen inte ändras baserat på vem som utfärdade certifikatet.