Binnen de sleutelceremonie: PKI, HSM, het proces, de mensen en waarom het belangrijk is

Gepubliceerd: augustus 2025. Bijgewerkt: augustus 2026. Beoordeeld door het PKI- en HSM-adviessteam van Encryption Consulting.

Wanneer mensen praten over de fundamenten van digitaal vertrouwen, bedoelen ze meestal encryptie , certificaten en de Public Key Infrastructure (PKI) . Bijna niemand heeft het proces gezien dat dat vertrouwen daadwerkelijk creëert: de sleutelceremonie waarbij de basissleutel van een certificeringsinstantie ontstaat, in een kluis, onder videobewaking, in het bijzijn van getuigen die een logboek ondertekenen voordat ze vertrekken.

Dit artikel gaat dieper in op dat proces. Het behandelt wie een sleutelceremonie uitvoert, hoe M-van-N-quorum en gedeelde kennis in de praktijk werken, waar de FIPS-grens van de HSM zich bevindt, waarom een ​​offline root-CA en een online uitgevende CA ceremonies van een andere orde zijn, hoe back-up en escrow van het resulterende sleutelmateriaal werken, wat er vóór de ceremonie gecontroleerd moet worden en de faalmodi die een routineceremonie in een auditbevinding veranderen.

Wat is een sleutelceremonie en waarom is die belangrijk?

Een sleutelceremonie is de formele, gecontroleerde procedure waarbij een cryptografisch sleutelpaar wordt gegenereerd, geactiveerd en beveiligd. Dit gebeurt doorgaans voor een certificeringsinstantie (CA) , maar ook voor root-sleutels van bedrijven, code-ondertekeningssleutels of ander waardevol cryptografisch materiaal. Het is een combinatie van technische procedure, beveiligingscontrole en compliance-vereiste. Of de sleutel nu toebehoort aan een publiekelijk vertrouwde root-CA, een nationaal eID-systeem of de interne PKI van een particulier bedrijf, de ceremonie dient om alle betrokken partijen, zoals auditors en de organisatie zelf, de verifieerbare zekerheid te geven dat de sleutel onder strikte, gedocumenteerde controle is gegenereerd.

Een belangrijke ceremonie is om drie concrete redenen van belang:

• Transparantie schept vertrouwen. Het proces wordt waargenomen, vastgelegd en geregistreerd, zodat externe auditors en partijen die op de sleutel vertrouwen niet zomaar op het woord van de certificeringsinstantie hoeven aan te nemen hoe de sleutel is aangemaakt.
• Gedistribueerd vertrouwen vermindert risico's. Quorumgebaseerde controles betekenen dat geen enkele persoon, hoe hooggeplaatst ook, de sleutel in zijn eentje kan genereren, openen of misbruiken.
• Het is een wettelijke vereiste. WebTrust voor certificeringsinstanties, ETSI-standaarden en frameworks zoals PCI DSS en eIDAS Ze vereisen allemaal een gedocumenteerd en gecontroleerd proces voor het genereren van CA-sleutels.

Zie het als het cryptografische equivalent van het slaan van geld: iedereen die van dat geld afhankelijk is, moet er zeker van zijn dat het op de juiste, veilige en gecontroleerde manier is geproduceerd, en dat de authenticiteit ervan achteraf kan worden geverifieerd. De WebTrust Principles and Criteria for Certification Authorities is de auditstandaard waaraan de meeste publiekelijk vertrouwde certificeringsinstanties worden getoetst, en sleutelgeneratieceremonies behoren tot de meest nauwlettend gecontroleerde gebeurtenissen.

Wie zijn er betrokken bij een sleutelceremonie?

Niemand voert in zijn eentje een belangrijke ceremonie uit, en dat is precies de bedoeling. Rolscheiding is de sleutel tot controle, geen formaliteit eromheen. Bij een typische ceremonie worden de volgende rollen toegewezen:

• Ceremoniebeheerder. De ontwikkelaar is verantwoordelijk voor het script, voert elke stap in de juiste volgorde uit en is de enige die ervan mag afwijken, en alleen door het programma te pauzeren en de reden daarvoor te documenteren.
• Crypto-officieren / sleutelbeheerders. Ieder bezit een deel van het quorum, meestal een smartcard of PED-sleutel, en toont deze alleen wanneer het script daarom vraagt.
• Systeem- of HSM-beheerder. Bedient de HSM- en Security World-tools onder leiding van de ceremoniemeester.
• Getuigen. Onafhankelijk personeel (of, bij openbare wortelceremonies, een externe auditor) houdt elke stap in de gaten, bevestigt dat er niets buiten het plan is gebeurd en ondertekent het logboek.
• Schrijver. Registreert elke actie, tijdstempel en deelnemer in realtime; dit logboek dient als bewijs voor de controle.
• Accountant. Bij openbare CA's die gecontroleerd worden door WebTrust of ETSI, is een onafhankelijke, gekwalificeerde auditor aanwezig die afzonderlijk bevestigt dat de ceremonie overeenkwam met het goedgekeurde draaiboek.

Niemand kan een ceremonie in zijn eentje voltooien. Dat is een bewuste keuze: een ceremoniebeheerder zonder getuige heeft geen onafhankelijke bevestiging dat het script is gevolgd, en een cryptograaf zonder quorum kan niets zelfstandig ontgrendelen.

Wat zijn M-van-N-quorum, gedeelde kennis en dubbele controle?

Deze drie principes, rechtstreeks afkomstig uit de belangrijkste managementrichtlijnen van NIST SP 800-57 Deel 1 , zorgen ervoor dat een ceremonie bestand is tegen zowel inbreuken door insiders als simpele menselijke fouten.

1. M-van-N quorum Dit betekent dat de HSM zo is geconfigureerd dat een gedefinieerde subset (M) van een grotere groep sleutelbeheerders (N) fysiek aanwezig moet zijn om een ​​gevoelige actie te autoriseren. Een quorum van 3 van de 5 betekent dat vijf personen elk een pasje hebben, en dat drie, maar nooit minder, deze tegelijkertijd moeten tonen. Een te lage drempel verzwakt de beveiliging; een te hoge drempel brengt het risico met zich mee van operationele stagnatie wanneer medewerkers op reis zijn of niet beschikbaar zijn.
2. Gesplitste kennis Dit betekent dat niemand ooit over voldoende informatie beschikt om de sleutel zelfstandig te reconstrueren. De kaart of PED-sleutel van elke beheerder beschermt slechts een fragment van het autorisatiemateriaal, niet de privésleutel zelf in een vorm die ze zelfstandig zouden kunnen extraheren en gebruiken.
3. Dubbele bediening Dit betekent dat ten minste twee bevoegde personen moeten samenwerken om een ​​gevoelige bewerking, het genereren, back-uppen of herstellen van gegevens uit te voeren, zodat een enkel persoon die onder druk staat of gecompromitteerd is, niet eenzijdig kan handelen.

Deze drie principes verklaren samen waarom een ​​gestolen laptop, een onder druk staande beheerder of één kwaadwillende binnen de organisatie niet voldoende is om een ​​goed verlopen ceremonie te verstoren. Het quorum moet fysiek bijeenkomen en het logboek registreert precies wie erbij was.

Welke rol speelt de HSM en waar ligt de FIPS-grens?

De hardwarebeveiligingsmodule (HSM) is de plek waar de privésleutel daadwerkelijk wordt gegenereerd en waar deze blijft. Binnen de fraudebestendige cryptografische grens van de HSM, gedefinieerd en getest volgens FIPS 140-3 , wordt het sleutelmateriaal gegenereerd met behulp van een gevalideerde willekeurige getallengenerator, gebruikt om het rootcertificaat te ondertekenen, en blijft vervolgens ofwel verzegeld in de module, of verlaat deze alleen als een versleutelde, ingekapselde back-up. De onversleutelde privésleutel overschrijdt die grens nooit. Als dat wel zou gebeuren, zou het hele uitgangspunt van de ceremonie, namelijk dat niemand de sleutel kan achterhalen of misbruiken, in duigen vallen.

FIPS 140-3 is de huidige Amerikaanse en Canadese standaard voor het valideren van cryptografische modules en heeft FIPS 140-2 vervangen. Volgens het CMVP-overgangsschema van NIST worden alle resterende FIPS 140-2-certificaten op 21 september 2026 op de historische lijst geplaatst. Na deze datum vereisen nieuwe federale aanbestedingen modules die gevalideerd zijn volgens FIPS 140-3. Voor sleutelceremonies van root- en intermediaire CA's is beveiligingsniveau 3, dat authenticatie van de operator op basis van identiteit en detectie van manipulatie met respons vereist, de praktische ondergrens die de meeste publiekelijk vertrouwde CA's en gereguleerde ondernemingen hanteren; sommige implementaties vereisen de extra bescherming van niveau 4 tegen aanvallen vanuit de omgeving en niet-invasieve aanvallen.

Wat dit operationeel betekent: controleer vóór de ceremonie of de exacte HSM-firmwareversie en het FIPS-validatiecertificaat de algoritmen en sleutelgroottes dekken die u wilt genereren. Een ceremonie waarbij een sleutel wordt gegenereerd op niet-gevalideerde firmware, of op een module die in een niet-FIPS-goedgekeurde modus draait, kan het auditspoor ongeldig maken, zelfs als alle procedurele controles correct zijn uitgevoerd.

Offline root-CA versus online uitgevende CA: waarom de implementatietopologie de ceremonie verandert.

De meeste PKI-hiërarchieën volgen dezelfde structuur: een zelfondertekende root-CA bovenaan, een of meer intermediaire (uitgevende) CA's daaronder, en eindgebruikerscertificaten die door die intermediaire CA's worden uitgegeven. Deze structuur bestaat specifiek om de blootstelling van de root tot een minimum te beperken en bepaalt direct hoe de sleutelceremonie van elke laag wordt uitgevoerd.

Aspect	Root-CA	Tussenliggende / Uitgevende CA
Netwerkstatus	Offline, met een tijdsverschil tussen de ceremonies.	Online, verbonden met CA/RA-software
Fysieke locatie	Afgesloten kluis of brandkast, uitgeschakeld of verzegeld wanneer deze niet in gebruik is.	Beveiligd datacenter, actief in bedrijf
Ceremoniefrequentie	Zeldzaam, doorgaans eenmalig bij het aanmaken van een hiërarchie, daarna alleen voor vernieuwing of DR.	Vaker, bij uitgifte, verlenging of omwisseling.
Doorgaans aantal getuigen	Hoogste niveau: meerdere functionarissen, onafhankelijke getuigen, vaak een externe accountant	Gemiddeld: crypto-officieren plus interne getuige
Gevolg van het compromis	Catastrofaal, de hele hiërarchie moet worden ingetrokken en opnieuw worden ingesteld.	Ernstig maar beheersbaar, de betreffende tussenliggende vergunning intrekken en opnieuw uitgeven.

Omdat een gecompromitteerde root-CA alle certificaten die eronder zijn uitgegeven ongeldig maakt, worden root-CA-ceremonies onderworpen aan de strengste procedures die een PKI-hiërarchie te bieden heeft: speciale kluisruimte, video-opnames van het openen tot het sluiten van de kluis, notariële logboeken in de meest veilige gevallen en meerdere onafhankelijke getuigen. Certificeringen van intermediaire CA's volgen nog steeds een vast script, quorum en dubbele controle, maar de operationele impact is kleiner omdat een gecompromitteerde intermediaire CA een afgebakende, herstelbare gebeurtenis is in plaats van een existentiële.

Voor een stapsgewijze handleiding van een openbare root CA-ceremonie, inclusief hoe de authenticiteit van de root achteraf wordt geverifieerd, raadpleegt u ons artikel in het Educatiecentrum over de root CA-sleutelceremonie.

Hoe verloopt een sleutelceremonie eigenlijk?

Belangrijke ceremonies worden nooit geïmproviseerd. Elke ceremonie volgt een vooraf geschreven en goedgekeurd draaiboek, ook wel een draaiboek genoemd, dus er wordt niets ter plekke besloten. De algemene volgorde ziet er als volgt uit:

1. Voorbereiding. Rollen worden toegewezen, de ruimte wordt beveiligd (videobewaking, verzegelingen die manipulatie tegengaan, beperkte toegang) en het draaiboek voor de ceremonie wordt van tevoren afgerond en goedgekeurd.
2. HSM- en omgevingsconfiguratie. De HSM en alle ondersteunende infrastructuur, waaronder voor Entrust nShield-implementaties het Remote File System (RFS) dat de versleutelde Security World opslaat, worden geïnstalleerd, beveiligd en op connectiviteit getest voordat er sleutelmateriaal wordt aangeraakt.
3. Het aanmaken van een domein genaamd Security World of een vergelijkbare domeinnaam. De HSM-operator initialiseert de beveiligde omgeving waarin de sleutels worden opgeslagen, waarbij het algoritme, de sleutelsterkte en het quorumbeleid worden gedefinieerd. Deze configuratie wordt zowel op de HSM opgeslagen als versleuteld op de RFS of een equivalent daarvan.
4. Definitie van quorum. De M-van-N-drempelwaarde wordt ingesteld en vastgelegd in het script.
5. Personalisatie en distributie van pasjes of PED-sleutels. Voor elke beheerder wordt een pas aangemaakt, beveiligd met een pincode en onder toezicht aan hem of haar overhandigd. Wanneer de pas niet in gebruik is, wordt deze geregistreerd en veilig opgeslagen.
6. Sleutelgeneratie en certificering. Het root- of intermediaire sleutelpaar wordt gegenereerd binnen de FIPS-grens van de HSM, waarna het bijbehorende certificaat wordt aangemaakt en, voor een rootcertificaat, zelfondertekend; voor een intermediair certificaat, ondertekend door de moeder-CA.
7. Documentatie en goedkeuring. Het realtime logboek van de notulist, de handtekeningen van de getuigen en de video-opname worden samengevoegd in het auditpakket.
8. Verzegelen en bewaren. De kaarten worden in verzegelde zakken in een kluis bewaard, de back-ups worden versleuteld en naar een secundaire, beveiligde locatie overgebracht, en de HSM wordt verzegeld of uitgeschakeld tot de volgende geplande ceremonie.

Elke stap in die reeks bestaat omdat het overslaan ervan bewijsmateriaal zou verwijderen waar een auditor, of de advocaat van een aanklager, later om zou vragen.

Hoe worden belangrijke documenten opgeslagen en in bewaring gegeven?

Een ceremonie die een sleutel genereert en deze nooit back-upt, heeft een single point of failure gecreëerd, vermomd als een beveiligingsmaatregel. De back-up vindt plaats binnen dezelfde gecontroleerde sessie met dubbele controle als de generatie, niet als een nabeschouwing:

• Versleutelde export of klonen. De belangrijkste gegevens worden in versleutelde vorm (nooit in platte tekst) geëxporteerd naar een back-uptoken, een gekloonde HSM of een versleuteld Security World/RFS-back-upbestand, afhankelijk van de leverancier.
• Gedeeld beheer van de back-up. De back-upmedia, en alle kaarten of PED-sleutels die nodig zijn om deze te herstellen, zijn verdeeld over verschillende beheerders en opgeslagen op geografisch gescheiden locaties met toegangscontrole. Zo wordt voorkomen dat een storing op één locatie zowel de actieve sleutel als de enige kopie ervan vernietigt.
• Escrow voor gereguleerde omgevingen. Sommige compliance-regimes en bedrijfsbrede sleutelbeheerbeleidsregels vereisen een gedocumenteerde kopie die onder gezamenlijk beheer (vaak juridisch én beveiligingsbeheer) wordt bewaard, met een eigen toegangslogboek dat losstaat van de dagelijkse werkzaamheden.
• Periodieke hersteltests. Een back-up die nooit is hersteld, is een hypothese, geen herstelplan. Voor de operationele kant van het testen van HSM-back-ups en failover onder productiebelasting, zie ons bericht over HSM-clustering en hoge beschikbaarheid.

Dezelfde M-van-N-quorum- en dual-control-principes die gelden voor het genereren van een root-sleutel, gelden ook voor het herstellen ervan. Een herstelprocedure waarbij slechts één persoon nodig is om een ​​root-sleutel weer online te brengen, heeft stilletjes het zwakke punt opnieuw geïntroduceerd dat de oorspronkelijke ceremonie juist moest elimineren.

Wat heb je nodig vóór de ceremoniedag? (Vereisten voor integratie)

De meeste problemen tijdens een ceremonie ontstaan ​​eigenlijk vóór de ceremonie en komen pas te laat aan het licht om ze netjes op te lossen. Een praktische checklist met benodigdheden omvat vier gebieden:

• Milieu. De fysieke locatie is beveiligd, netwerkisolatie is bevestigd (de hoofdceremonies mogen geen actieve netwerkverbinding hebben), en de video- en opnameapparatuur is vooraf getest.
• Personeel. Elke rol is op naam toegewezen, de identiteitsverificatie is voltooid, er is bevestigd dat er een quorum aanwezig is voor de volledige sessie, en er zijn back-ups aangewezen voor het geval een aangewezen beheerder niet aanwezig kan zijn.
• Hardware. Het HSM-model, serienummer en de firmwareversie zijn gedocumenteerd en bevestigd aan de hand van het vereiste FIPS-validatiecertificaat; de verzegelingen zijn gecontroleerd; een testrun is uitgevoerd op niet-productiehardware om commandofouten op te sporen voordat ze in de registratie worden vastgelegd.
• Documentatie. Het draaiboek voor de ceremonie was van tevoren afgerond en goedgekeurd, blanco logboekpagina's waren voorbereid, media waren gelabeld en klaar voor gebruik, en er waren aftekenregels die specifiek genoeg waren om de exacte opslaglocaties en serienummers vast te leggen in plaats van alleen "veilig opgeslagen".

De regel die je moet onthouden: als het niet in het draaiboek staat, is het niet gebeurd, althans niet vanuit het perspectief van een auditor. Het achteraf schrijven van het draaiboek, of het improviseren van een stap omdat de generale repetitie is overgeslagen, is de meest voorkomende oorzaak van bevindingen bij audits van verder goed verlopen ceremonies.

Hoe ziet dit er in de praktijk uit?

Vier scenario's dekken de meeste situaties waarin organisaties daadwerkelijk ceremonies houden:

• Generatie van een openbare root-CA. Een door WebTrust gecontroleerde CA genereert een nieuwe root-sleutel. Verwacht een speciale kluis, vijf of meer deelnemers met de bovengenoemde rollen, een onafhankelijke auditor, notariële documentatie en continue videobewaking vanaf het moment dat de kluis opent tot het moment dat deze sluit.
• Enterprise intermediate CA stand-up. Een intern PKI-team brengt een nieuwe uitgevende CA online onder een bestaande offline root. De ceremonie is nog steeds gescript en wordt bijgewoond door getuigen, maar de omvang is kleiner: doorgaans zijn er twee crypto-officieren, een getuige en een ceremoniebeheerder aanwezig, die de ceremonie uitvoeren in een beveiligd datacenter in plaats van een kluis.
• HSM-firmware-upgrade of -migratie. Bij het overstappen naar nieuwe hardware (bijvoorbeeld het opnieuw instellen van een Entrust nShield Security World op geüpgrade apparaten, of het migreren tussen Thales Luna-partities) moeten clients opnieuw worden geregistreerd en de connectiviteit opnieuw worden getest voordat de productiesleutelbewerkingen kunnen worden hervat, onder dezelfde quorumcontroles die bij de oorspronkelijke generatie werden gebruikt.
• Herstel na een ramp. Na een hardwarestoring of verlies van toegang tot de site herstellen de beheerders het quorum en herstellen ze de hoofdsleutel of tussenliggende sleutel vanuit de versleutelde back-up naar de vervangende hardware. Dit is een geoefende, niet geïmproviseerde procedure met dubbele controle.

Wat gaat er mis en hoe voorkom je dat?

De meeste problemen met ceremonies die tijdens audits of incidentenanalyses aan het licht komen, zijn te wijten aan drie soorten fouten:

• Afwijking van het script. Een stap wordt overgeslagen, in een andere volgorde geplaatst of geïmproviseerd omdat de testrun niet is uitgevoerd of het script niet gedetailleerd genoeg was om een ​​uitzonderingsgeval af te dekken. Oplossing: een verplichte testrun op niet-productiehardware, een vergrendeld en vooraf goedgekeurd script en een regel dat elke afwijking wordt gepauzeerd, gedocumenteerd en opnieuw goedgekeurd voordat verder wordt gegaan, in plaats van dat er stilletjes omheen wordt gewerkt.
• Tekortkomingen in getuigenverklaringen of audits. Een getuige verlaat de ruimte, zelfs maar even, en die onderbreking in de continue getuigenverklaring wordt later als een bevinding beschouwd, of het logboek wordt achteraf uit het geheugen gereconstrueerd in plaats van live opgeschreven. Mogelijke oplossingen: continue getuigenbewaking met gedocumenteerde vervangingen indien iemand de ruimte moet verlaten, live registratie van elke handeling en video-opname als back-up voor het schriftelijke logboek.
• HSM-storing midden in de ceremonie. Hardwarefouten treden op voordat de back-upstap is voltooid, waardoor het team moet beslissen of en vanaf waar de back-up moet worden hervat. Oplossing: controleer of de versleutelde back-up is voltooid en gevalideerd voordat de sessie als afgesloten wordt beschouwd, houd een gevalideerde reserve-HSM bij de hand voor cruciale root-procedures en programmeer de procedure voor afbreken/hervatten vooraf in plaats van dit ter plekke te beslissen.

Al deze problemen zijn te voorkomen met een goede planning vóórdat de zaal op slot gaat, en niet tijdens de ceremonie zelf.

Welk type ceremonie heeft u nodig?

Ceremonietype	Typisch gebruiksvoorbeeld	Strengheid / getuigen	Frequentie
Genereren van root CA-sleutels	Het creëren van een nieuwe basis van vertrouwen, publiek of zakelijk.	Hoogste aantal deelnemers: 5+ deelnemers, vaak een externe auditor, video, offline archief.	Eenmaal aanwezig bij het creëren van een hiërarchie, daarna zelden nog.
Generatie van tussenliggende/uitgevende CA-sleutels	Het opzetten van een nieuwe ondergeschikte CA onder een bestaande root-CA	Gemiddeld: crypto-officieren plus interne getuige	Om de paar jaar, of volgens een nieuwe CA-regeling.
Sleutelrotatie / -vernieuwing	Een sleutel vervangen vóór het verlopen van het certificaat.	Matig, volgt het oorspronkelijke goedgekeurde script.	Gepland volgens certificaatbeleid
Herstel na rampen	Het herstellen van een CA of HSM na hardwarestoring of verlies van locatiegegevens	Hoog: herstel met dubbele controle vanuit versleutelde back-up	Zo nodig; periodiek geoefend
HSM-buitenbedrijfstelling / vernietiging van sleutels	Hardware buiten gebruik stellen of een gecompromitteerde of verlopen sleutel vernietigen	Hoog: nulstelling waargenomen, goedkeuring door de audit	Einde van de levensduur van de hardware of sleutel

Beperkingen

Dit bericht beschrijft algemeen aanvaarde praktijken voor sleutelceremonies op praktijkniveau en is geen vervanging voor het goedgekeurde certificeringsbeleid/certificeringspraktijkverklaring (CP/CPS) van uw organisatie, de officiële ceremoniedocumentatie van een specifieke HSM-leverancier of de gecontroleerde vereisten waaraan een publiekelijk vertrouwde CA moet voldoen onder WebTrust of ETSI. De exacte scriptstructuur, kaartmechanismen en terminologie (Security World en RFS voor Entrust nShield; PED-geauthenticeerde versus wachtwoordgeauthenticeerde partities voor Thales Luna; cloud-HSM-consoleworkflows voor AWS CloudHSM, Azure Managed HSM of Google Cloud HSM) variëren per leverancier en implementatiemodel, en de toepasselijke wettelijke vereisten verschillen per rechtsgebied en branche. Beschouw dit als het kader om te plannen en valideer de details vervolgens aan de hand van uw CPS en de actuele documentatie van uw HSM-leverancier vóór de ceremoniedag.

Wat zou Encryption Consulting aanbevelen?

Een sleutelceremonie goed laten verlopen vereist meer dan alleen mensen in een beveiligde ruimte verzamelen en sleutels genereren. Het vereist gevalideerde procedures, strikte rolverdeling en documentatie die zelfs jaren later nog een audit kan doorstaan. Onze PKI Services- en HSM Services- teams ondersteunen ceremonies van begin tot eind:

• Ontwerp van de ceremonieprocedure. Stapsgewijze scripts op maat, afgestemd op uw compliance-eisen, WebTrust, PCI DSS, FIPS 140-2/3en de eigen CP/CPS van uw organisatie.
• Uitgebreide documentatie. Stel documenten, checklists voor de ceremonie, ceremoniescripts en rapporten na de ceremonie samen die een audit kunnen doorstaan.
• Firmware- en configuratieondersteuning. HSM-firmware-upgrades, hardware-initialisatie en Security World- of partitie-configuratie, zodat de ceremonie op een gevalideerde basis begint.
• Uitvoering en begeleiding van de ceremonie. Wij kunnen optreden als ceremonieleider, beheerder of onafhankelijke getuige, waarbij we toezien op het quorum en elke handeling vastleggen.
• Training en kennisoverdracht. We geven uw interne team de kennis en vaardigheden die nodig zijn om toekomstige ceremonies zelfstandig en vol vertrouwen te organiseren.
• Garantie na de ceremonie. Definitieve documentatie, auditvalidatie en aanbevelingen voor doorlopend sleutelbeheer en back-uptesten.

Voor organisaties die hardwarematige sleutelbeveiliging willen zonder zelf de HSM-infrastructuur te bezitten en te beheren, biedt HSM-as-a-Service gevalideerde, zeer betrouwbare HSM-capaciteit met dezelfde strenge eisen als hierboven beschreven, zonder de last van het aanschaffen en onderhouden van de hardware.

Veelgestelde Vragen / FAQ

Hoe lang duurt een sleutelceremonie?
Een ceremonie voor een root-CA duurt doorgaans een hele dag, inclusief de installatie, verificatie, generatie, back-up, documentatie en verzegeling. Certificeringen voor een intermediate CA zijn meestal korter, vaak slechts een paar uur, omdat de fysieke beveiligings- en getuigenvereisten minder streng zijn.

Wie moet er aanwezig zijn bij een sleutelceremonie?
Minimaal zijn er een ceremoniebeheerder, de crypto-officieren die quorumaandelen bezitten, een HSM-operator en ten minste één onafhankelijke getuige nodig. Publiekelijk vertrouwde rootceremonies voegen doorgaans een externe auditor en extra getuigen toe om te voldoen aan de WebTrust- of ETSI-vereisten.

Wat is nu eigenlijk het echte verschil tussen een root CA-ceremonie en een intermediate CA-ceremonie?
Een inbreuk op het rootcertificaat is catastrofaal en heeft gevolgen voor elk certificaat dat de hiërarchie ooit heeft uitgegeven. Daarom worden rootcertificaten met de hoogste beveiliging beveiligd: offline kluizen, meer getuigen, video-opnames en vaak notariële bekrachtiging. Tussenliggende certificaten maken nog steeds gebruik van quorum en dubbele controle, maar de fysieke beveiliging wordt afgeschaald omdat een gecompromitteerd tussenliggend certificaat geïsoleerd en herstelbaar is.

Kan een sleutelceremonie op afstand worden uitgevoerd?
Sommige organisaties voeren ceremonies met een lager risico uit, zoals het rouleren van een interne tussenliggende sleutel, met deelnemers op afstand onder videobewaking en schermdeling. Certificeringen voor root-CA's voor publiekelijk vertrouwde hiërarchieën worden bijna altijd fysiek uitgevoerd, omdat deelname op afstand het fysieke bewijs van de bewijsketen verzwakt dat auditors vereisen.

Wat gebeurt er als de HSM tijdens de ceremonie uitvalt?
Een goed uitgewerkte procedure houdt hier rekening mee voordat het gebeurt: het script specificeert of de procedure moet worden afgebroken en hervat vanaf de laatst voltooide stap, of dat er verder moet worden gegaan met een gevalideerde reserve-HSM. Geen enkele back-up wordt als voltooid beschouwd en de sessie wordt niet gesloten totdat de versleutelde back-up is gegenereerd en geverifieerd.

Conclusie

Een sleutelceremonie is een van de meest cruciale gebeurtenissen in de levenscyclus van een PKI. Het combineert rolscheiding, een M-van-N-quorum, gedeelde kennis en de FIPS-gevalideerde grens van een HSM in één enkele, controleerbare procedure. Dit geeft iedereen stroomafwaarts – auditors, vertrouwende partijen en de organisatie zelf – een verifieerbaar antwoord op de vraag: "Hoe weten we dat deze sleutel betrouwbaar is?" Zorg voor de juiste topologie (offline root, online tussenliggende sleutels), documenteer elke stap van tevoren, maak een back-up onder dezelfde dubbele controle die gebruikt is voor het genereren van de sleutel, en oefen de faalscenario's voordat ze zich onverwacht voordoen. Dan doet de ceremonie precies wat ze moet doen: een vertrouwensbasis creëren die niemand zomaar hoeft te vertrouwen.

Met deskundige begeleiding van een partner die dit proces al in diverse publieke en zakelijke organisaties heeft uitgevoerd, hoeft u uw eerste, of uw vijftigste, ceremonie niet alleen te plannen.

Referenties

• WebTrust-principes en -criteria voor certificeringsinstanties, CPA Canada
• Basisvereisten van het CA/Browser Forum voor de uitgifte en het beheer van publiekelijk vertrouwde TLS-certificaten
• NIST SP 800-57 Deel 1 Revisie 5, Aanbeveling voor sleutelbeheer
• FIPS 140-3, Beveiligingseisen voor cryptografische modules, NIST
• FIPS 140-3 Overgangsinspanning, NIST CSRC
• Operatorkaartsets (OCS), Entrust nShield-documentatie