- Kort antwoord: Wat is een Root CA Key Ceremony?
- Key Takeaways
- Waarom de Root CA-ceremonie belangrijk is
- Fase 1: Voorbereiding op de ceremonie (4 tot 8 weken van tevoren)
- Fase 2: Toewijzing van rollen tijdens de ceremonie
- Fase 3: Ceremonieomgeving en -uitrusting
- Fase 4: Uitvoering van de ceremonie
- Fase 5: Samenstelling van het bewijsmateriaal
- Fase 6: Opslag en controle na de ceremonie
- Root CA-ceremonie in de PKIaaS-context
- Hoe encryptieconsultancy kan helpen
- Conclusie
- Veelgestelde Vragen / FAQ
Elk certificaat in een PKI-hiërarchie herleidt zijn vertrouwensketen tot de root-CA. De privésleutel van de root-CA is het cryptografische anker waarop dat vertrouwen rust. Als de sleutel van de root-CA onveilig is gegenereerd, in een ongecontroleerde omgeving, zonder getuigen, zonder gedocumenteerde procedures of zonder adequate hardwarebeveiliging, dan draagt ​​elk certificaat dat ooit onder die CA is uitgegeven een onzichtbare beperking: de vertrouwensketen is slechts zo betrouwbaar als de omstandigheden waaronder de root-sleutel is gecreëerd.
Een ceremonie voor de sleutel van een root-CA is de formele procedure die de betrouwbaarheid van dat cryptografische anker vaststelt. Het is geen bureaucratische formaliteit. Het is de gebeurtenis waarnaar auditors verwijzen wanneer ze bewijs nodig hebben dat een CA-hiërarchie correct is opgezet. Het is waarnaar een complianceprogramma verwijst om te beweren dat PKI-sleutelmateriaal onder de juiste controles is gegenereerd. En voor organisaties die PKI als een service implementeren met klanthosting of hybride implementatiemodellen, is het een belangrijke operationele gebeurtenis die zorgvuldige planning en deskundige uitvoering vereist.
Deze handleiding beschrijft alles wat komt kijken bij het ontwerpen en uitvoeren van een ceremonie voor een root CA-sleutel: de voorbereidende werkzaamheden, de te vervullen rollen, de benodigde apparatuur, het ceremoniescript van HSM-initialisatie tot en met het verzamelen van bewijsmateriaal, en de opslag- en beheersmaatregelen na de ceremonie ter bescherming van het sleutelmateriaal en het ceremonieverslag.
Kort antwoord: Wat is een Root CA Key Ceremony?
Een root CA-sleutelceremonie is een formeel gedocumenteerde, bekrachtigde en gecontroleerde procedure voor het genereren van de privésleutel van de root CA in een FIPS 140-3 Level 3 gevalideerde HSM onder M-of-N-beheercontroles. De ceremonie levert drie dingen op: het root CA-sleutelpaar (opgeslagen in de HSM en nooit in onversleutelde vorm geëxporteerd), het zelfondertekende root CA-certificaat (gedistribueerd naar vertrouwensarchieven) en het bewijsmateriaal van de ceremonie (het controleerbare document dat aantoont dat de sleutelgeneratie correct heeft plaatsgevonden onder de gestelde beheercontroles). Alles in de PKI-hiërarchie dat na de ceremonie volgt, is afhankelijk van de betrouwbaarheid die ermee is vastgesteld.
Key Takeaways
- De ceremonie voor de hoofd-CA-sleutel is een governance-gebeurtenis, geen louter technische procedure. Het bewijsmateriaal dat hieruit voortvloeit, is een auditdocument waarnaar WebTrust voor CA's, ETSI EN 319 411, SOC 2 Type II, FedRAMP, CMMC en PCI DSS auditors verwijzen. Een onvolledige of niet-gedocumenteerde ceremonie is een veelvoorkomende bevinding bij PKI-audits en een materiële zwakte in de PKI-governance van de organisatie.
- De voorbereiding op de ceremonie is cruciaal voor het succes of falen ervan. Het certificaatbeleid, de CP/CPS (Certificate of Certified Professionals), de rolverdeling, het ceremonieprogramma, de checklist voor de apparatuur en de HSM-configuratie (Hospital Security Module) moeten allemaal vóór de ceremoniedatum definitief zijn. Een ceremonie die wordt gehouden zonder een gecontroleerd en goedgekeurd programma is operationeel riskant: fouten onder tijdsdruk met meerdere getuigen zijn moeilijk op een elegante manier te herstellen.
- M-van-N-controles voor root CA-bewerkingen zijn een verplichte governance-vereiste, geen optionele beveiligingsverbetering. M moet hoog genoeg worden ingesteld, zodat samenspanning meerdere personen vereist die niet allemaal in hetzelfde team of dezelfde rapportagestructuur werken. N moet groot genoeg zijn, zodat het quorum kan worden bereikt zonder afhankelijk te zijn van de beschikbaarheid van één enkele persoon. Een 3-van-5- of 3-van-7-configuratie is gebruikelijk voor root CA-ceremonies binnen een onderneming.
- De omgeving van de ceremonie moet net zo gedetailleerd worden gedocumenteerd als de ceremonieprocedures zelf. Fysieke toegangscontroles, videobewaking, wie de ruimte betrad en verliet, het serienummer en de firmwareversie van de HSM, en de staat van al het bewijsmateriaal aan het einde van de ceremonie maken allemaal deel uit van het bewijsmateriaal dat auditors onderzoeken.
- Het bewaren van de HSM, het back-upsleutelmateriaal en het bewijsmateriaal van de ceremonie na de ceremonie is net zo belangrijk als de ceremonie zelf. Een root-CA waarvan het back-upsleutelmateriaal onveilig is opgeslagen, of waarvan het bewijsmateriaal van de ceremonie niet in een opvraagbaar formaat is gearchiveerd, heeft een onvolledig governanceverhaal, zelfs als de ceremonie correct is uitgevoerd.
Waarom de Root CA-ceremonie belangrijk is
De privésleutel van de root-CA wordt onder normale omstandigheden voor precies één type bewerking gebruikt: het ondertekenen van de certificaten van ondergeschikte CA's (tussenliggende of uitgevende CA's) die zich onder de root in de hiërarchie bevinden. Deze sleutel wordt niet gebruikt voor het uitgeven van eindgebruikerscertificaten; tussen de ceremonies van de ondergeschikte CA's is de sleutel offline. De sleutel is alleen operationeel tijdens de eerste ceremonie (om het eigen zelfondertekende certificaat te genereren en te ondertekenen en het eerste uitgevende CA-certificaat te ondertekenen) en tijdens latere ceremonies om nieuwe of vernieuwde certificaten van ondergeschikte CA's te ondertekenen.
Omdat de root-CA-sleutel zo zelden wordt gebruikt, kan een inbreuk hierop jarenlang onopgemerkt blijven. Een gecompromitteerde root-CA-sleutel stelt een aanvaller in staat om elk gewenst CA-certificaat te ondertekenen, waardoor ze certificaten kunnen uitgeven voor elk domein of elke identiteit die PKI-afhankelijke partijen als legitiem zouden beschouwen. De gevolgen zijn systemisch: elk certificaat dat is uitgegeven onder de gecompromitteerde root-CA-sleutel is potentieel verdacht en de oplossing vereist het vervangen van de root-CA-sleutel en het opnieuw uitgeven van de volledige certificaathiërarchie.
Daarom is de sleutelgeneratieceremonie zo belangrijk. Als de ceremonie correct is uitgevoerd, met gedocumenteerde controles, bijgewoond door meerdere partijen en met het sleutelmateriaal alleen opgeslagen in hardware die extractie verhindert, dan kan de betrouwbaarheid van de root CA-sleutel met bewijs worden aangetoond. Als dit niet het geval is, kan de organisatie hoogstens zeggen dat ze geloven dat de sleutel veilig is, wat geen controleerbare bewering is.
Fase 1: Voorbereiding op de ceremonie (4 tot 8 weken van tevoren)
CP/CPS-afstemming
Het certificeringsbeleid (CP) en de certificeringspraktijkverklaring (CPS) moeten vóór de ceremonie worden opgesteld en beoordeeld, omdat de procedures van de ceremonie moeten overeenkomen met wat het CP/CPS voorschrijft. Als het CP/CPS een 3-van-5 M-van-N-configuratie voor root CA-activiteiten specificeert en de ceremonie wordt uitgevoerd met een 2-van-3-configuratie, voldoet de ceremonie niet aan het vastgestelde beleid en opereert de PKI vanaf dag één buiten het gedocumenteerde governancekader.
De CP/CPS-secties die het meest relevant zijn voor de ceremonie zijn: Sectie 6 (Technische beveiligingscontroles) voor de sleutelgeneratieprocedure, HSM-vereisten en M-of-N-configuratie; Sectie 5 (Beheer-, operationele en fysieke controles) voor de ceremonieomgeving, fysieke toegangsvereisten en personeelscontroles; en Sectie 4.8 (Certificaatwijziging) of de relevante sectie over de uitgifte van ondergeschikte CA's voor de procedures met betrekking tot het ondertekenen van ondergeschikte CA-certificaten. Controleer deze secties aan de hand van het geplande ceremonieprogramma voordat u een van beide documenten definitief vastlegt.
CA-hiërarchieontwerp
Vóór de ceremonie moet het ontwerp van de CA-hiërarchie worden afgerond: hoeveel lagen (twee lagen met root-CA en uitgevende CA, of drie lagen met root-CA, intermediaire CA en uitgevende CA), welke certificaatprofielen voor elke CA worden gebruikt, welke sleutelalgoritmen en sleutelgroottes op elk niveau worden gebruikt en wat de geldigheidsperioden voor elk CA-certificaat zullen zijn. Deze beslissingen kunnen niet meer worden herzien nadat de root-CA-sleutel is gegenereerd zonder een nieuwe root-CA te creëren en de ceremonie te herhalen.
Voor PKIaaS-implementaties moet het hiërarchische ontwerp ook rekening houden met de inschrijvingsprotocollen (ACME, EST, SCEP, WSTEP, CMP) die de uitgevende CA's zullen ondersteunen, de certificaatprofielen (TLS, apparaat, gebruiker, S/MIME, codeondertekening) die zullen worden uitgegeven, en de OCSP- en CRL-infrastructuur waarnaar in de uitgegeven certificaatextensies zal worden verwezen. Het root-CA-certificaat zelf verwijst niet naar een CRL of OCSP AIA (root-CA's zijn zelfondertekend en hun eigen intrekking kan niet via standaardmechanismen worden gecontroleerd), maar alle ondergeschikte CA-certificaten moeten CRL-DP's en AIA-vermeldingen bevatten die verwijzen naar operationele OCSP- en CRL-infrastructuur.
HSM-selectie en -inkoop
De HSM voor de root-CA moet een FIPS 140-2 Level 3- of FIPS 140-3 Level 3-gevalideerd apparaat zijn. FIPS 140-3 Level 3 is de huidige standaard; FIPS 140-2 Level 3-apparaten blijven acceptabel voor bestaande implementaties. Level 3-validatie vereist fysieke fraudebestendige en manipulatiebestendige mechanismen, identiteitsgebaseerde authenticatie voor moduletoegang en de mogelijkheid om alle onbeveiligde CSP's (Critical Security Parameters) te wissen als reactie op een manipulatiepoging. Het specifieke HSM-model moet worden geselecteerd op basis van het CA-softwareplatform (de HSM moet PKCS#11 of CNG/CryptoAPI ondersteunen, afhankelijk van de CA-software), de vereiste sleutelalgoritmen (RSA-4096, ECDSA P-384 of PQC-algoritmen als hybride certificaten van toepassing zijn) en de M-of-N-implementatie die door de firmware van de HSM wordt ondersteund.
Bestel de HSM ruim van tevoren, zodat u deze vóór de ceremonie kunt ontvangen en controleren. Controleer na ontvangst de authenticiteit van de HSM met behulp van de verificatieprocedure van de fabrikant (de meeste HSM-leveranciers bieden een webgebaseerde verificatieservice aan met behulp van het serienummer van het apparaat en een hardware-attestatie). Noteer het serienummer en de firmwareversie in de documentatie voorafgaand aan de ceremonie en bevestig dat het apparaat tijdens de verzending niet is gemanipuleerd.
Ontwikkeling van een ceremoniescript
Het ceremonie-script is het stapsgewijze proceduredocument dat tijdens de ceremonie zal worden gevolgd. Het moet gedetailleerd genoeg zijn zodat elke stap correct kan worden uitgevoerd door het aangewezen personeel, zonder dat er sprake hoeft te zijn van inschattingen of improvisatie. Elke stap in het script moet specificeren: wie de handeling uitvoert, welke opdracht of interfacebewerking wordt uitgevoerd, wat de verwachte output is en wat de getuige moet observeren en bevestigen. Het script moet ook specificeren wat te doen als een stap mislukt of een onverwachte output oplevert: wat een herstelbare fout is (opnieuw proberen, configuratie controleren, voorzichtig te werk gaan) versus een onherstelbare fout (de ceremonie stoppen, alle materialen veiligstellen, een evaluatiegesprek voeren alvorens verder te gaan).
Het draaiboek voor de ceremonie moet vóór de ceremoniedatum worden beoordeeld en goedgekeurd door de interne auditor van de ceremonie en de CA-eigenaar. Wijzigingen in het draaiboek na goedkeuring vereisen een schriftelijke beoordeling van de wijzigingen. Op de dag van de ceremonie wordt elke stap in het draaiboek geparafeerd door de persoon die de stap heeft uitgevoerd en door ten minste één getuige; deze geparafeerde exemplaren maken deel uit van het bewijsmateriaal.
Fase 2: Toewijzing van rollen tijdens de ceremonie
Iedere persoon in de ceremonieruimte heeft een vastgestelde rol met specifieke verantwoordelijkheden. Rollen moeten worden toegewezen aan specifieke personen en schriftelijk worden bevestigd vóór de ceremonie. Niemand mag een rol vervullen die tegelijkertijd ook een conflicterende rol heeft. De specifieke rolbenamingen kunnen variëren per organisatie en PKIaaS-aanbieder, maar de functionele verantwoordelijkheden zijn consistent bij goed opgezette ceremonies.
Ceremoniemeester
De ceremoniemeester is verantwoordelijk voor de stapsgewijze uitvoering van het ceremoniescript en voor de algehele coördinatie van de ceremonie. De ceremoniemeester roept elke stap af, bevestigt dat het juiste personeel gereed is voordat verder wordt gegaan en is verantwoordelijk voor het tempo en de volledigheid van de ceremonie. Hij of zij heeft geen beheerdersrol (om belangenconflicten tussen coördinatie en autorisatie te voorkomen) en dient een ervaren PKI-engineer te zijn die het ceremoniescript grondig heeft doorgenomen. Voor organisaties zonder interne ervaring met ceremonies, verlaagt een externe PKI-consultant in de rol van ceremoniemeester het uitvoeringsrisico aanzienlijk.
Sleutelbeheerders (M-van-N)
Sleutelbeheerders zijn de personen die beschikken over individuele authenticatiegegevens (HSM-operatorkaarten, smartcards of softwaretokens, afhankelijk van de M-van-N-implementatie van de HSM) die nodig zijn om HSM-bewerkingen met hoge privileges te autoriseren. Elke beheerder heeft precies één authenticatiegegeven; geen enkele beheerder heeft er meer dan één. In een 3-van-5-configuratie ontvangen vijf beheerders elk één van de vijf operatorkaarten tijdens de ceremonie, en moeten drie van hen samenwerken (door hun kaarten gelijktijdig of achter elkaar te presenteren, afhankelijk van de HSM-implementatie) om bewerkingen met de root CA-sleutel te autoriseren.
Om samenspanning binnen één commandostructuur te voorkomen, moeten beheerders worden geselecteerd uit verschillende teams of rapportagelijnen. In een PKIaaS-context, waar de PKI wordt beheerd door het beveiligingsteam, kunnen geschikte beheerders bijvoorbeeld de CISO, het hoofd IT, het hoofd infrastructuur, de bedrijfsjurist en een externe auditor of leidinggevende zijn. De diversiteit aan beheerders zorgt ervoor dat het autoriseren van een root CA-bewerking samenwerking vereist over organisatiegrenzen heen.
Internal Auditor
De interne auditor observeert de ceremonie aan de hand van het goedgekeurde draaiboek en bevestigt dat elke stap correct en volledig is uitgevoerd. De interne auditor voert geen technische handelingen uit; zijn of haar rol is observeren en documenteren. De interne auditor ondertekent de bewijsstukken van de ceremonie bij elke stap, en deze handtekening is de bevestiging dat wat in de bewijsstukken is vastgelegd overeenkomt met wat er daadwerkelijk is gebeurd. De interne auditor moet onafhankelijk zijn van het team dat de CA beheert; het aanstellen van de projectmanager van het PKI-team als interne auditor ondermijnt de onafhankelijkheid van de bevestiging.
Externe getuige (optioneel, maar aanbevolen)
Een externe getuige is een persoon die niet in dienst is van de organisatie en die de ceremonie bevestigt. Voor organisaties die WebTrust- of ETSI-certificering nastreven, maakt een externe auditor in de rol van getuige deel uit van het certificeringsproces. Voor organisaties die geen publiek vertrouwen nastreven, maar wel extra zekerheid willen over het bewijsmateriaal van de ceremonie, versterkt een externe PKI-consultant of juridisch adviseur in de rol van getuige de onafhankelijkheid van de bevestiging van de ceremonie.
IT-ondersteuning / HSM-operator
De IT-ondersteuning omvat technische handelingen die geen beheerdersrechten vereisen: het aansluiten van apparatuur, het installeren van CA-software op het ceremoniewerkstation, het initialiseren van de HSM onder leiding van de ceremoniemeester en het oplossen van verbindings- of configuratieproblemen. De IT-ondersteuning voert de technische stappen uit op het ceremoniewerkstation; zij beschikken niet over beheerdersrechten en kunnen geen sleutelhandelingen zelfstandig autoriseren.
Bewijsrecorder
De bewijsrecorder documenteert de ceremonie in realtime: hij registreert tijdstempels voor elke stap van de ceremonie, legt de console-uitvoer en de commandogeschiedenis van het ceremoniewerkstation vast, bewaart de video-opname en verzamelt de fysieke bewijsstukken (ondertekende scriptpagina's, HSM-verpakking, formulieren voor ontvangstbevestiging van de beheerder). De bewijsrecorder is een aparte functie van de interne auditor; de auditor bevestigt dat het proces correct is, de bewijsrecorder legt vast wat er is gebeurd.
Fase 3: Ceremonieomgeving en -uitrusting
De fysieke ceremonieomgeving moet voldoen aan de eisen die in de CP/CPS voor sleutelgeneratiefaciliteiten zijn vastgelegd. Typische eisen zijn onder andere: een fysiek beveiligde ruimte met toegang via een pasje of biometrische authenticatie, registratie van de toegang tot de ruimte gedurende de ceremonie, geen toegang voor onbevoegd personeel en een videobewakingssysteem dat de ceremonie continu vastlegt. De ceremonieruimte moet worden geïnspecteerd voordat deelnemers binnenkomen om te controleren of er geen ongeautoriseerde opnameapparatuur of hardwarematige keyloggers aanwezig zijn.
De checklist met benodigdheden voor de ceremonie moet minimaal 48 uur voor de ceremoniedatum worden opgesteld en gecontroleerd. De benodigde apparatuur omvat doorgaans:
- HSM (FIPS 140-3 niveau 3 gevalideerd), geverifieerde authenticiteit, in originele verpakking tot aan de ceremonie.
- Werkstation voor de ceremonie: laptop of werkstation zonder internetverbinding (niet verbonden met een netwerk tijdens de ceremonie), besturingssysteem recent geïnstalleerd vanaf geverifieerde media, CA-software geïnstalleerd en geverifieerd, geen andere software aanwezig
- Netwerkgeïsoleerde voeding: UPS om te voorkomen dat het werkstation tijdens de ceremonie tijdens de werking zonder stroom komt te zitten.
- HSM-operatorkaarten (N kaarten, één per beheerder, indien de HSM gebruikmaakt van kaartgebaseerde M-van-N), met kaartlezer
- Reserve-HSM of HSM-reservetoken (voor sleutelback-up; de back-up moet na de ceremonie apart van de primaire HSM worden opgeslagen)
- Video-opnameapparatuur, zo geplaatst dat de HSM, het werkstationscherm en de handen van de operator worden vastgelegd.
- Gedrukte exemplaren van het goedgekeurde ceremonieprogramma (voldoende voor alle deelnemers om te kunnen volgen)
- Formulieren voor de bewaring van elk fysiek medium dat tijdens de ceremonie is geproduceerd.
- Verzegelde zakken of containers voor het bewaren van HSM's en back-upmedia na de ceremonie.
- Handtekeningpennen (geen viltstiften, om duurzame handtekeningen te garanderen) voor alle deelnemers.
- Documentatie over de entropiebron (indien naast de interne entropie van de HSM een externe entropiebron wordt gebruikt voor het genereren van sleutels)
Het werkstation dat tijdens de ceremonie wordt gebruikt, mag geen internetverbinding hebben. Als de CA-software een netwerkverbinding vereist voor licentievalidatie of softwareactivering, moet dit vóór aanvang van de ceremonie zijn voltooid; de netwerkkabel wordt vervolgens fysiek losgekoppeld en deze ontkoppeling wordt gedocumenteerd voordat de sleutelgeneratie verdergaat.
Fase 4: Uitvoering van de ceremonie
De ceremonie verloopt via een vastgestelde reeks fasen. Hieronder worden de kernfasen beschreven die gangbaar zijn bij goed ontworpen root CA-sleutelceremonies; de specifieke commando's en interfacebewerkingen variëren per HSM-leverancier en CA-softwareplatform.
Fase 4.1: Opening en bezoekersaantallen
De ceremonie begint met de ceremoniemeester die controleert of alle vereiste personen aanwezig zijn, de naam en rol van elke persoon in het ceremonielogboek noteert, bevestigt dat de ruimte veilig is en de opnameapparatuur werkt, en de doelstelling van de ceremonie voorleest uit het script (waarvan de interne auditor en alle deelnemers bevestigen dat deze de reikwijdte van de ceremonie nauwkeurig weergeeft). Elke deelnemer ondertekent het aanwezigheidsformulier. Personen die niet op de goedgekeurde aanwezigheidslijst staan, worden niet toegelaten. Indien een vereiste rol niet kan worden vervuld door de aangewezen persoon (ziekte, afwezigheid), dient de ceremonie te worden uitgesteld in plaats van te worden uitgevoerd met een vervanger die niet voor de rol is gescreend.
Fase 4.2: HSM-verificatie en -initialisatie
De HSM wordt voor alle aanwezigen uit de verpakking gehaald. De persoon die het bewijsmateriaal vastlegt, noteert het serienummer, het model en de firmwareversie van de HSM en maakt een foto van de verpakking. De authenticiteit van de HSM wordt geverifieerd (met behulp van het verificatiemechanisme van de leverancier) in aanwezigheid van de interne auditor, die in het ceremonieverslag bevestigt dat de verificatie is geslaagd.
De HSM wordt vervolgens geïnitialiseerd: de standaard fabrieksinstellingen worden gewist, de HSM wordt in een bekende, correcte beginstatus geplaatst (meestal "fabrieksreset" of "nulstellen" genoemd) en de initiële beheerdersgegevens worden ingesteld. De nulstellingsstap bevestigt dat er geen sleutelmateriaal van een eerder gebruik in de HSM aanwezig is voordat het sleutelmateriaal voor de ceremonie wordt gegenereerd. De bewijsrecorder registreert het tijdstempel en de console-uitvoer van het nulstellingscommando.
Fase 4.3: M-van-N-configuratie en initialisatie van de beheerder
De M-van-N-configuratie wordt op de HSM ingesteld: het totale aantal beheerders (N), het quorum dat vereist is voor bewerkingen met hoge privileges (M) en de cryptografische parameters voor sleutelshares van beheerders worden geconfigureerd volgens de CP/CPS-specificatie. Vervolgens wordt voor elke beheerder een sleutelshare of operatorkaart gegenereerd en geactiveerd, één beheerder tegelijk. Elke beheerder:
- Loop naar de ceremoniewerkplek terwijl andere medewerkers op een bepaalde afstand blijven staan ​​(om te voorkomen dat iemand over de schouder meekijkt bij het invoeren van de pincode of legitimatie).
- Stelt hun persoonlijke pincode of wachtwoord in op hun operatorkaart.
- Ontvangt zijn/haar operatorpas of -token in een ondoorzichtige envelop die hij/zij verzegelt en ondertekent.
- Ondertekent een formulier voor de bevestiging van ontvangst van de legitimatie, de verantwoordelijkheden als beheerder en de voorwaarden waaronder de legitimatie mag worden gebruikt.
- Keert terug naar de groep
De bewijsrecorder registreert elke initialisatiestap van de beheerder met een tijdstempel. De interne auditor bevestigt dat elke initialisatie correct is verlopen en dat geen andere deelnemer de pincode van een beheerder tijdens de toegang heeft kunnen zien.
Fase 4.4: Genereren van de root CA-sleutel
Voor het genereren van de root CA-sleutel is een quorum van M van de N beheerders vereist. De ceremoniemeester instrueert M beheerders (de eerste M uit de lijst, of zoals gespecificeerd in het script) om naar voren te treden en hun referenties achtereenvolgens of gelijktijdig te presenteren, zoals vereist door de HSM. Zodra het quorum is geverifieerd, geeft de ceremoniemeester de IT-ondersteuningsmedewerker opdracht om de sleutelgeneratieopdracht uit te voeren.
Het commando voor sleutelgeneratie specificeert: het sleutelalgoritme (RSA-4096, ECDSA P-384, of zoals gespecificeerd in de CP/CPS), de HSM-partitie waarin de sleutel wordt opgeslagen en het label waarmee naar de sleutel wordt verwezen. De Evidence Recorder legt het volledige commando en de console-uitvoer van de sleutelgeneratie vast, inclusief eventuele sleutelidentificaties, handle of hashes van de openbare sleutel die door de HSM worden geretourneerd. Deze uitvoer is een cruciaal bewijsstuk: het koppelt het later gegenereerde root-CA-certificaat aan de specifieke sleutel die tijdens deze ceremonie is gegenereerd.
Na het genereren van de sleutels authenticeren de M-beheerders zich opnieuw om de generatie van het zelfondertekende certificaat van de root-CA te autoriseren. Het commando voor certificaatgeneratie specificeert de Subject DN (conform de CP/CPS), de geldigheidsperiode van het certificaat, de Basic Constraints-extensie (CA:TRUE zonder padlengtebeperking voor een root-CA), de Key Usage-extensie (keyCertSign en cRLSign) en alle andere extensies die vereist zijn door de CP/CPS. Het resulterende root-CA-certificaat wordt geëxporteerd naar een bestand op het werkstation van de ceremonie. De vingerafdruk van het certificaat (SHA-256 van het DER-gecodeerde certificaat) wordt weergegeven, hardop voorgelezen door de IT-supportmedewerker, vastgelegd door de Evidence Recorder en bevestigd door de interne auditor.
Fase 4.5: Ondertekening van de CSR door de ondergeschikte CA (indien binnen de scope)
Als de ceremonie het ondertekenen van een of meer ondergeschikte CA-certificaten (tussenliggende of uitgevende CA-certificaten) omvat, worden deze in deze fase ondertekend. Elk CSR voor een ondergeschikte CA moet vooraf zijn gegenereerd (op de CA-software of HSM die de ondergeschikte CA zal hosten), gecontroleerd op correcte inhoud (Subject DN, sleutelalgoritme, basisbeperkingen, certificeringsbeleidsextensies, AIA/CDP-extensies) door het ceremonieteam en goedgekeurd door de interne auditor vóór de ceremonie. CSR's die niet vóór de ceremonie zijn gecontroleerd en goedgekeurd, mogen niet tijdens de ceremonie worden ondertekend; het ondertekenen van een niet-gecontroleerde CSR creëert een CA waarvan de certificaatinhoud niet is geattesteerd.
Voor elke te ondertekenen CSR van een ondergeschikte CA, authenticeren M beheerders zich, voert de IT-ondersteuningsmedewerker het ondertekeningscommando uit met specificatie van het CSR-bestand en het beoogde certificaatprofiel, en legt de Evidence Recorder de resulterende certificaatvingerafdruk vast. Het ondertekende certificaat van de ondergeschikte CA wordt geëxporteerd naar een bestand op het werkstation van de ceremonie.
Fase 4.6: Procedures voor het maken van back-ups van sleutels en HSM-back-ups
De privésleutel van de root-CA moet een geverifieerde back-up hebben om verlies te voorkomen in geval van een storing van de HSM. De back-upprocedure is afhankelijk van het HSM-platform: sommige HSM's ondersteunen de export van versleutelde sleutels onder M-of-N-beheerautorisatie (waarbij de geëxporteerde sleutelblob is versleuteld met een sleutel die M-of-N-beheerssamenwerking vereist om te decoderen); andere ondersteunen het rechtstreeks klonen van de sleutel naar een back-up-HSM van hetzelfde model onder beheer van de beheerder. Beide benaderingen zijn acceptabel; wat belangrijk is, is dat het back-upsleutelmateriaal tijdens de ceremonie wordt gegenereerd onder dezelfde M-of-N-controle als de primaire sleutel, en dat de back-up wordt geverifieerd (door te proberen deze te laden en te gebruiken) voordat de ceremonie is voltooid.
Nadat de back-up is gemaakt en geverifieerd, wordt het back-upmedium (of het nu een back-up-HSM, een versleuteld back-uptoken of een versleuteld sleutelbestand op een opslagmedium betreft) gelabeld, verzegeld in een fraudebestendige verpakking, ondertekend door de interne auditor en de ceremoniemeester, en gedocumenteerd in het bewijsmateriaal van de ceremonie. De opslaglocatie van de back-up en de toegangscontroles worden gedocumenteerd in het bewijsmateriaal van de ceremonie. De back-up moet gescheiden van de primaire HSM worden opgeslagen: een brand, diefstal of fysieke schade aan één van beide mag geen gevolgen hebben voor beide.
Fase 4.7: Afsluiting van de ceremonie
De afsluitingsfase van de ceremonie omvat: het exporteren van alle gegenereerde certificaten naar de aangewezen beveiligde distributiemedia (doorgaans een alleen-lezen USB-stick voor ceremonies zonder internetverbinding, of een geverifieerd beveiligd kanaal voor ceremonies met internetverbinding), het controleren van de integriteit van al het geëxporteerde materiaal door de hashes van de bestanden te vergelijken met de waarden die tijdens de generatie zijn vastgelegd, het veilig wissen van het werkstation van de ceremonie (of het voltooien van de geplande procedures voor het bewaren ervan in een gecontroleerde staat), en het verzegelen van de primaire HSM in een fraudebestendige verpakking voor transport naar de operationele opslaglocatie.
De ceremoniemeester leest het voltooide ceremonieprogramma door om te bevestigen dat alle stappen zijn geparafeerd. Stappen die zijn overgeslagen of waarvan is afgeweken, moeten worden gedocumenteerd met de reden voor de afwijking en de verklaring van de interne auditor. Het aanwezigheidsformulier wordt gecontroleerd om te bevestigen dat alle gegevens volledig zijn ingevuld. De interne auditor bevestigt de voltooiing van de ceremonie door de verklaring van voltooiing te ondertekenen, en alle deelnemers die nog in de zaal aanwezig zijn, ondertekenen deze mede.
Fase 5: Samenstelling van het bewijsmateriaal
Het bewijsmateriaal van de ceremonie is de verzameling documenten en gegevens die aantonen dat de ceremonie correct is verlopen. Het wordt samengesteld door de notulist na afloop van de ceremonie en gecontroleerd door de interne auditor voordat het wordt gearchiveerd. Een compleet bewijsmateriaal omvat:
- Aanwezigheidslijst ceremonie: Namen, rollen en handtekeningen van alle deelnemers, met aankomst- en vertrektijden voor ieder van hen.
- Ondertekend ceremonieprogramma: Het complete script, waarbij elke stap is geparafeerd door de uitvoerder en ten minste één getuige, en eventuele aantekeningen over afwijkingen.
- HSM-verificatierecord: HSM-model, serienummer, firmwareversie, resultaat van de leveranciersverificatie en foto's van de verpakking en het apparaat.
- M-van-N configuratierecord: De geconfigureerde M- en N-waarden, de pseudonieme of echte identificaties die aan elke beheerderspositie zijn toegewezen, en de bevestiging dat elke beheerder is geïnitialiseerd.
- Formulieren voor bevestiging van de sleutelbeheerder: Per beheerder dient één ondertekend formulier te worden ingediend waarin de ontvangst van hun legitimatiebewijs en hun begrip van de beheerdersverantwoordelijkheden worden bevestigd.
- Sleutelgeneratierecord: Tijdstempel, algoritme, sleutelgrootte, HSM-partitie, sleutellabel en sleutelidentificatie van elke gegenereerde sleutel, samen met de console-uitvoer van het generatiecommando.
- Certificaatvingerafdrukken: De SHA-256-vingerafdrukken van alle certificaten die tijdens de ceremonie zijn gegenereerd of ondertekend (hoofd-CA-certificaat, alle ondergeschikte CA-certificaten), zijn hardop voorgelezen, opgenomen en bekrachtigd.
- Back-uprecord: Beschrijving van de back-upmethode, het zegelnummer(s) op de back-upcontainer(s), de aangewezen back-upopslaglocatie en het verificatieresultaat (succesvolle back-uptest).
- Video-opname: Een doorlopende video-opname van de ceremonie, van opening tot sluiting, met tijdstempeloverlay. De video moet worden gearchiveerd in een formaat dat gedurende de geldigheidsduur van het root-CA-certificaat plus een eventuele bewaartermijn volgens het compliancekader kan worden opgevraagd.
- Certificering als interne auditor: De interne auditor heeft een verklaring ondertekend waarin staat dat de ceremonie is uitgevoerd in overeenstemming met het goedgekeurde draaiboek en de CP/CPS-vereisten.
- Verklaring van een externe getuige (indien van toepassing): De door de externe getuige ondertekende verklaring over de gang van zaken tijdens de ceremonie.
Het bewijsmateriaal wordt gearchiveerd op een beveiligde locatie met toegangscontrole en een gedocumenteerd toegangslogboek. Voor de meeste compliance-frameworks moet het bewijsmateriaal worden bewaard gedurende de levensduur van het root-CA-certificaat (wat 20 tot 25 jaar kan zijn) plus de toepasselijke bewaartermijn na vervaldatum. Fysieke kopieën moeten worden opgeslagen in een brandveilige kluis; elektronische kopieën moeten worden opgeslagen in een beveiligd, versleuteld archief met regelmatige integriteitscontrole.
Fase 6: Opslag en controle na de ceremonie
De ceremonie sluit het proces van sleutelgeneratie af, maar het beheer van het sleutelmateriaal van de root-CA blijft gedurende de hele levensduur van de CA-hiërarchie van kracht. De opslag en controle na de ceremonie hebben betrekking op drie categorieën: de primaire HSM, het back-upsleutelmateriaal en de inloggegevens van de beheerder.
Primaire HSM-opslag: De primaire HSM wordt opgeslagen in een beveiligde behuizing (kluis of speciale HSM-opslagkast) op een fysiek beveiligde locatie. Toegang tot de HSM moet worden geregistreerd: wie heeft er toegang toe gehad, wanneer en met welk doel. Voor een offline root-CA wordt de HSM tussen de ceremonies uitgeschakeld; de opslaglocatie moet beschikken over omgevingsfactoren (temperatuur, luchtvochtigheid) die geschikt zijn voor langdurige opslag van elektronische apparatuur. Het verzegelingslabel van de HSM wordt bij elke toegang gecontroleerd aan de hand van het ceremonieverslag.
Back-upopslag: De back-up-HSM of het versleutelde back-upsleutelmateriaal wordt apart van de primaire HSM opgeslagen, op een andere fysieke locatie en idealiter in een ander gebouw of faciliteit. De back-up moet toegankelijk zijn onder dezelfde M-van-N-beheersregels als de primaire: voor het herstellen van het back-upsleutelmateriaal zijn M beheerders nodig, niet slechts één beheerder met toegang tot de back-upopslaglocatie. De integriteit van de back-up moet periodiek (minimaal jaarlijks) worden gecontroleerd door deze op te halen, te bevestigen dat de verzegeling intact is en de verificatie te registreren.
Beheer van beheerdersreferenties: De operatorpas of het token van elke beheerder wordt onder eigen beheer bewaard, op een locatie en op een manier die voldoet aan de CP/CPS-vereisten voor de opslag van referenties (doorgaans een persoonlijke kluis of een gelijkwaardige beveiligde opslag, niet een gedeelde lade op kantoor). Beheerders moeten jaarlijks worden herinnerd aan hun verantwoordelijkheden en moeten onmiddellijk melding maken als hun referentie verloren, gestolen of mogelijk gecompromitteerd is. Een verloren beheerdersreferentie vermindert het aantal beschikbare N voor toekomstige ceremonies; als N onder M (alle resterende beheerders) komt, worden root CA-bewerkingen onmogelijk totdat nieuwe beheerders zijn geïnitialiseerd met behulp van de sleutelherstelprocedure die tijdens de oorspronkelijke ceremonie is vastgesteld. De procedure voor het intrekken en vervangen van beheerdersreferenties moet worden gedocumenteerd en getest voordat deze nodig is.
Root CA-ceremonie in de PKIaaS-context
Bij een door een leverancier gehoste PKIaaS-implementatie voert de PKIaaS-provider de ceremonie voor de root-CA-sleutel uit in een eigen gecontroleerde omgeving, met behulp van FIPS 140-3 gevalideerde HSM's en ceremonieprocedures die zijn vastgelegd in hun Certification Practice Statement. Klanten ontvangen het bewijsmateriaal van de ceremonie als documentatie van de sleutelgeneratie. Sommige providers bieden klanten de mogelijkheid om waarnemers naar de ceremonie te sturen. Dit is aan te raden als de PKI wordt gebruikt voor toepassingen met hoge betrouwbaarheidseisen, waarbij onafhankelijke getuigenverklaringen het governanceverhaal versterken.
Bij een door de klant gehoste of hybride PKIaaS-implementatie voert de klant de sleutelceremonie voor de root-CA en alle CA's die zij hosten uit. De PKIaaS-provider levert de CA-software en kan de sjabloon voor het ceremoniescript en de bewijsstukken leveren, maar de fysieke ceremonie, de HSM, de beheerders en de interne auditor zijn de verantwoordelijkheid van de klant. Voor organisaties zonder eerdere ervaring met CA-ceremonies kan het inschakelen van een externe PKI-consultant als ceremoniemeester voor de eerste ceremonie het uitvoeringsrisico aanzienlijk verlagen en een bewijspakket van hogere kwaliteit opleveren.
Ongeacht het implementatiemodel vormen de governance-artefacten die tijdens de ceremonie worden geproduceerd, met name de CP/CPS en het bewijsmateriaal, de basis voor het complianceverhaal van de PKI. Auditors van SOC 2, FedRAMP, CMMC, WebTrust en ETSI onderzoeken deze documenten. Een organisatie die een compleet en goed gedocumenteerd bewijsmateriaal van de ceremonie kan overleggen, staat in een aanzienlijk sterkere positie bij elke PKI-gerelateerde audit dan een organisatie die afhankelijk is van mondelinge toezeggingen over hoe de root CA-sleutel is gegenereerd.
Hoe encryptieconsultancy kan helpen
- PKI-sleutelceremoniediensten: Encryption Consulting biedt end-to-end ondersteuning bij het ontwerpen en uitvoeren van sleutelceremonies: ontwikkeling van ceremoniescripts afgestemd op de CP/CPS, begeleiding bij roltoewijzingen, advies over HSM-selectie en deskundige Ceremony Master-diensten voor door klanten gehoste en hybride PKIaaS-implementaties. We hebben root CA-sleutelceremonies uitgevoerd in de financiële sector, defensie, gezondheidszorg en kritieke infrastructuur. Neem contact met ons op via Encryptie Consulting om uw wensen voor de ceremonie te bespreken.
- PKI als een service: Voor organisaties die gebruikmaken van de diensten van Encryption Consulting PKIaaS-aanbodDe door de leverancier gehoste root CA-sleutelceremonies worden uitgevoerd door het PKI-team van Encryption Consulting met behulp van FIPS 140-3 Level 3 HSM's onder gedocumenteerde M-of-N-controles, waarbij een volledig bewijspakket aan de klant wordt geleverd. Klanten kunnen toegang tot de ceremonie als waarnemer aanvragen.
- PKI-diensten (CP/CPS-ontwikkeling): Encryptie Consulting's PKI-diensten Dit omvat de ontwikkeling van een certificeringsbeleid en een certificeringspraktijkverklaring die aansluiten op de toepasselijke compliance-raamwerken (WebTrust, ETSI EN 319 411, SOC 2, FedRAMP, CMMC). Het CP/CPS is een voorwaarde voor het ceremonieprogramma; we ontwikkelen beide in een geïntegreerd traject.
- PKI-beoordelingsservice: Voor organisaties met een bestaande PKI waarvan het bewijsmateriaal voor de ceremonie onvolledig, ongedocumenteerd of onvindbaar is, biedt Encryption Consulting de volgende oplossing. PKI-beoordelingsservice Het beoordeelt de tekortkomingen in het beheer en stelt een herstelplan op. In sommige gevallen houdt het herstel in dat er een nieuwe ceremonie wordt gehouden om de niet-gedocumenteerde root-CA te vervangen door een correct beheerde CA.
- HSM als een service: Voor organisaties die FIPS 140-3 Level 3 HSM-capaciteit nodig hebben voor een door de klant georganiseerde ceremonie, zonder zelf de HSM-hardware te hoeven beheren, biedt Encryption Consulting de volgende oplossing. HSM als een service Biedt dedicated HSM-capaciteit met volledige controle voor de klant over de partitieconfiguratie en toegangsgegevens.
Conclusie
Een sleutelceremonie voor een root-CA is geen formaliteit. Het is de gebeurtenis die de betrouwbaarheid vaststelt van elk certificaat dat ooit binnen de PKI-hiërarchie zal worden uitgegeven. Organisaties die dit correct uitvoeren, met gedocumenteerde procedures, onder toezicht uitgevoerde handelingen, FIPS-gevalideerde HSM's, M-of-N-beheercontroles en een compleet bewijsmateriaal, bouwen een PKI-programma op een fundament dat ze gedurende de gehele levensduur van de root-CA kunnen verdedigen tegenover auditors, toezichthouders en vertrouwende partijen.
De planning is belangrijker dan de uitvoering. Een ceremonie met een goed doorgenomen script, de juiste rollen ingevuld door de juiste mensen, vooraf gecontroleerde apparatuur en kant-en-klare bewijsstukken zal vrijwel zeker slagen. Een ceremonie die onder tijdsdruk wordt geïmproviseerd, met onduidelijke rolverdelingen en apparatuur die niet is getest, zal waarschijnlijk een verslag opleveren dat meer vragen oproept dan beantwoordt.
Voor organisaties die voor het eerst PKIaaS implementeren, biedt de ceremonie een kans om PKI-governancepraktijken vast te stellen die de organisatie decennialang van dienst zullen zijn. Voor organisaties met een bestaande PKI waarvan de documentatie van de ceremonie summier is, vormt de kloof tussen wat de certificaatketen impliceert (een betrouwbare sleutelgeneratiegebeurtenis) en wat aantoonbaar is (een gedocumenteerde, door getuigen bijgewoonde ceremonie) een governance-risico dat het waard is om proactief aan te pakken in plaats van te wachten tot een auditbevinding.
Als uw organisatie een ceremonie voor de uitreiking van de root-CA-sleutel plant of de volledigheid van een bestaand verslag van een dergelijke ceremonie wil beoordelen, neem dan contact op met Encryption Consulting . Wij hebben CA-sleutelceremonies uitgevoerd en geadviseerd in uiteenlopende organisatorische contexten en compliance-kaders.
Dit bericht wordt jaarlijks herzien en wanneer de validatievereisten van FIPS 140, WebTrust, ETSI EN 319 411 of belangrijke compliance-raamwerken updates publiceren die van invloed zijn op de belangrijkste ceremonievereisten.
Veelgestelde Vragen / FAQ
Wat is een PKI root CA-sleutelceremonie?
Een PKI root CA-sleutelceremonie is een formeel gedocumenteerde procedure voor het genereren van de privésleutel van de root CA in een gecontroleerde, geauditeerde en gecontroleerde omgeving onder M-of-N-beheer in een FIPS 140-3 Level 3 gevalideerde HSM. De ceremonie produceert het root CA-sleutelpaar, het zelfondertekende root CA-certificaat en een bewijspakket van de ceremonie dat dient als controleerbaar verslag van de sleutelgeneratie voor nalevingsdoeleinden.
Wat is M-of-N-controle in een CA-sleutelceremonie?
M-van-N-controle vereist dat een minimum aantal geautoriseerde beheerders (M) van het totale aantal beheerders (N) moet samenwerken om bewerkingen met root-CA-sleutels met hoge privileges te autoriseren. Een 3-van-5-configuratie vereist bijvoorbeeld dat 3 van de 5 aangewezen beheerders hun referenties tonen voordat de HSM een bewerking met een root-CA-sleutel toestaat. M-van-N voorkomt dat één enkele beheerder ongeautoriseerde root-CA-bewerkingen eenzijdig uitvoert. Een 3-van-5- of 3-van-7-configuratie is gebruikelijk voor root-CA-ceremonies binnen een onderneming.
Waarom is het bewijsmateriaal voor de CA-ceremonie van belang voor de naleving van de regelgeving?
Het bewijspakket is het controleerbare document dat aantoont dat de root CA-sleutel correct is gegenereerd onder gedocumenteerde controles. Auditors van WebTrust for CAs, ETSI EN 319 411, SOC 2 Type II, FedRAMP, CMMC en PCI DSS onderzoeken dit pakket om te verifiëren dat de cryptografische basis van de CA voldoet aan de gestelde eisen van het certificeringsbeleid. Zonder een compleet bewijspakket kan de organisatie niet bewijzen dat de root CA-sleutel op een betrouwbare manier is gegenereerd. Een ontbrekend of onvolledig bewijspakket is een veelvoorkomende bevinding bij PKI-audits.
Hoe lang duurt een ceremonie voor het instellen van een root CA-sleutel?
De uitvoering van de ceremonie duurt doorgaans 4 tot 8 uur op de dag zelf, afhankelijk van het aantal aangemaakte CA's, het aantal geïnitialiseerde beheerders en of er ook ondergeschikte CA CSR's worden ondertekend. De voorbereiding op de ceremonie vereist 4 tot 8 weken voor de afstemming van CP/CPS, het ontwerpen van de hiërarchie, de aanschaf van HSM, het ontwikkelen van het ceremoniescript en de roltoewijzing. Het overhaasten van een van deze fasen vergroot de kans op fouten die moeilijk op een elegante manier te herstellen zijn tijdens de ceremonie zelf.
Kan een PKIaaS-leverancier de ceremonie voor het genereren van de root-CA-sleutel namens de klant uitvoeren?
Ja. Bij door de leverancier gehoste PKIaaS-implementaties voert de provider doorgaans de root CA-ceremonie uit in een gecontroleerde omgeving, met behulp van FIPS 140-3 gevalideerde HSM's en CPS-gedocumenteerde procedures. De provider levert vervolgens een bewijspakket van de ceremonie aan de klant. Klanten kunnen observatietoegang aanvragen. Bij door de klant gehoste of hybride implementaties voert de klant de ceremonie uit met behulp van eigen HSM's. De provider levert de CA-software en eventueel sjablonen voor het ceremoniescript; de klant is verantwoordelijk voor de fysieke uitvoering, de beheerders en de interne auditor.
- Kort antwoord: Wat is een Root CA Key Ceremony?
- Key Takeaways
- Waarom de Root CA-ceremonie belangrijk is
- Fase 1: Voorbereiding op de ceremonie (4 tot 8 weken van tevoren)
- Fase 2: Toewijzing van rollen tijdens de ceremonie
- Fase 3: Ceremonieomgeving en -uitrusting
- Fase 4: Uitvoering van de ceremonie
- Fase 4.1: Opening en bezoekersaantallen
- Fase 4.2: HSM-verificatie en -initialisatie
- Fase 4.3: M-van-N-configuratie en initialisatie van de beheerder
- Fase 4.4: Genereren van de root CA-sleutel
- Fase 4.5: Ondertekening van de CSR door de ondergeschikte CA (indien binnen de scope)
- Fase 4.6: Procedures voor het maken van back-ups van sleutels en HSM-back-ups
- Fase 4.7: Afsluiting van de ceremonie
- Fase 5: Samenstelling van het bewijsmateriaal
- Fase 6: Opslag en controle na de ceremonie
- Root CA-ceremonie in de PKIaaS-context
- Hoe encryptieconsultancy kan helpen
- Conclusie
- Veelgestelde Vragen / FAQ
