De essentiële rol van hardwarebeveiligingsmodules (HSM's) in Public Key Infrastructures (PKI)

Hardware Security Modules (HSM's) vormen de hardwarematige vertrouwensbasis voor Public Key Infrastructure (PKI) -omgevingen. Ze genereren privésleutels van certificeringsinstanties (CA's) binnen een FIPS-gevalideerde omgeving, voeren alle ondertekeningsbewerkingen uit op fraudebestendige hardware en beschermen de meest cruciale asset in elke PKI-hiërarchie: de privésleutel van de CA. Een gecompromitteerde privésleutel van een CA stelt een aanvaller in staat om frauduleuze certificaten uit te geven voor elke identiteit binnen het vertrouwensbereik van die CA. De aanbevolen actie: implementeer HSM's met FIPS 140-2 Level 3 of hoger voor alle CA-lagen, voer een formele sleutelceremonie uit voor de generatie van de root-CA-sleutel en zorg voor hoge beschikbaarheid van de HSM's en geteste back-ups voordat de PKI in productie wordt genomen.

Kort antwoord: Waarom zijn HSM's essentieel voor PKI?

De beveiliging van PKI is volledig afhankelijk van de integriteit van de privésleutels van de certificeringsinstantie (CA). Softwarematige sleutelopslag is kwetsbaar voor logische aanvallen (uitlezen van geheugen, toegang tot het besturingssysteem met privileges) en fysieke aanvallen (verwijdering van schijven). HSM's beschermen de privésleutels van CA's binnen een FIPS-gevalideerde, fraudebestendige hardwareomgeving waaruit de sleutel nooit in onversleutelde vorm tevoorschijn komt. Zelfs als de hostserver waarop de CA-software draait volledig gecompromitteerd is, blijft de privésleutel beschermd binnen de HSM. Deze hardwarematige bescherming strekt zich uit over de volledige levenscyclus van de sleutel: generatie binnen de hardwareomgeving tijdens een sleutelceremonie, alle ondertekeningsbewerkingen die binnen de omgeving worden uitgevoerd en alleen versleutelde back-ups. Voor certificaatlevenscyclusbeheer op basis van door HSM's ondersteunde CA-sleutels, zie CertSecure Manager.

De cruciale rol van PKI in digitale beveiliging

PKI biedt een gestructureerd raamwerk voor het beheren van digitale certificaten en cryptografische sleutels, waardoor veilige communicatie tussen entiteiten mogelijk wordt. Het vormt de basis voor HTTPS voor websites, e-mailversleuteling en -ondertekening, digitale handtekeningen voor documenten en code, en toegangscontrolemechanismen in bedrijfsomgevingen. PKI is gebaseerd op asymmetrische versleuteling: een paar publieke en private sleutels waarbij de private sleutel ondertekent en de publieke sleutel verifieert, met een vertrouwensrelatie die is verankerd in de CA-hiërarchie.

De veiligheid van de gehele PKI-hiërarchie is afhankelijk van de integriteit van de privésleutels van de certificeringsinstanties (CA's). De privésleutel van de root-CA ondertekent certificaten van ondergeschikte CA's; een privésleutel van een ondergeschikte CA ondertekent eindgebruikerscertificaten voor websites, gebruikers, apparaten en code. Als een privésleutel van een CA wordt gecompromitteerd, kan de aanvaller geldige certificaten uitgeven voor elke identiteit binnen het bereik van die CA, waardoor alle certificaten in die vertrouwensketen onbetrouwbaar worden. Daarom is de bescherming van de privésleutels van CA's de allerbelangrijkste beveiligingsmaatregel in elke PKI-implementatie.

Wat is een Hardware Security Module (HSM)?

Een HSM is een speciaal hardwareapparaat dat cryptografische sleutels genereert, opslaat en beheert binnen een veilige, fraudebestendige omgeving. Alle cryptografische bewerkingen vinden plaats binnen de hardware; privésleutels verlaten deze omgeving nooit in onversleutelde vorm. Belangrijke kenmerken relevant voor PKI:

• Bescherming tegen manipulatie: De ingebouwde fysieke en logische sabotagebeveiliging reageert op inbraakpogingen door belangrijke gegevens te wissen voordat deze kunnen worden buitgemaakt.
• FIPS 140-validatie: HSM's worden gevalideerd volgens FIPS 140-2 of de huidige FIPS 140-3-standaard. Niveau 3 (vereist voor de meeste PKI-workloads) voegt identiteitsgebaseerde authenticatie toe en reageert op fysieke manipulatie.
• Hardware-sleutelgeneratie: De sleutels worden gegenereerd met behulp van een hardwarematige True Random Number Generator (TRNG), die cryptografische entropie produceert die softwarematige RNG's niet kunnen evenaren.
• Multi-factor authenticatie: Voor toegang tot HSM-functies zijn fysieke smartcards, pincodes of gelijkwaardige inloggegevens vereist, waardoor meerdere personen de controle over CA-sleutelbewerkingen moeten hebben.
• Flexibiliteit bij de implementatie: Beschikbaar als PCIe-kaarten ingebouwd in servers, netwerkapparaten, via USB aangesloten draagbare apparaten en in cloudgebaseerde HSM-services.

FIPS-grens in PKI: Wat betekent dit voor CA-sleutels?

De FIPS 140-grens is de fysieke en logische perimeter waarbinnen cryptografische bewerkingen plaatsvinden en sleutels worden beschermd. Voor PKI is dit onderscheid tussen de grenzen cruciaal:

• CA-privésleutels die binnen de beveiligingsgrens worden gegenereerd, bestaan ​​onder geen enkele omstandigheid in onversleutelde vorm buiten die grens, ook niet tijdens back-upbewerkingen (waarbij sleutelmateriaal in versleutelde vorm wordt geëxporteerd, omhuld door door de HSM gegenereerde sleutelversleutelingssleutels).
• Alle CA-ondertekeningshandelingen (ondertekening van ondergeschikte CA-certificaten, ondertekening van eindgebruikerscertificaten, ondertekening van CRL's) vinden plaats binnen de beveiligingsgrens; alleen handtekeningen en openbaar sleutelmateriaal verlaten deze grens.
• FIPS 140-2 Niveau 3 (de standaard voor PKI in bedrijven) vereist dat de module fysiek reageert op manipulatie, waardoor wordt gewaarborgd dat fysieke inbreuk op het apparaat geen sleutelmateriaal oplevert.
• FIPS 140-3 is de huidige standaard. Organisaties die nu HSM's evalueren, moeten zowel de huidige validatiestatus als de roadmap van de leverancier voor FIPS 140-3-certificering controleren.

Implementatietopologie: HSM-modellen voor PKI

PKI-niveau	Aanbevolen HSM-vormfactor	FIPS-niveau	Connectiviteit	HA-model
Offline root CA	Via USB of PCIe aangesloten HSM; offline gehouden tussen de ceremonies.	Minimaal niveau 3; niveau 4 voor de hoogste mate van zekerheid.	Luchtdicht; geen netwerkverbinding	Eén apparaat; belangrijke gegevens worden geback-upt naar een versleuteld archief onder M-of-N-beheer.
Online uitgifte CA	Netwerkgekoppeld HSM-apparaat of cloud-HSM	Niveau 3 minimum	Verbonden met de CA-server via TCP/IP of PKCS#11 via het netwerk.	HSM-cluster van minimaal 2 apparaten; sleutelmateriaal gesynchroniseerd over het hele cluster.
Uitgifte van grote volumes (bedrijfs- of openbare CA)	Netwerk-HSM-cluster met taakverdeling	Niveau 3	Aangesloten op het netwerk; meerdere HSM-clients	Actief-actief cluster; geografische redundantie over beschikbaarheidszones
Cloud / hybride PKI	Cloud HSM (HSM as a Service) of hybride on-premises root + cloud-uitgevende CA	Niveau 3 (controleer het hardwareapparaat, niet de softwarelaag)	Cloudgehost; toegankelijk via het netwerk van de provider.	Door de provider beheerde clusterreplicatie; back-up tussen regio's

Sleutelceremonie: Het opzetten van de root-CA in hardware.

De ceremonie voor het verkrijgen van de root-CA-sleutel is de meest cruciale operationele gebeurtenis in een PKI-implementatie. Hiermee wordt de privésleutel vastgesteld die de basis vormt voor de gehele vertrouwenshiërarchie. De ceremonie moet worden uitgevoerd in aanwezigheid van getuigen, gedocumenteerd in een ondertekend auditrapport en plaatsvinden met de HSM op een fysiek beveiligde locatie.

1. Voorbereidingen voorafgaand aan de ceremonie: Identificeer de beheerders voor het M-van-N-quorum (doorgaans 3 van de 5 of 2 van de 3); bevestig de FIPS 140-validatiestatus en het attestatiecertificaat van de HSM; bereid het air-gapped ceremoniewerkstation voor; plaats de offline HSM en smartcardlezers; bevestig de getuigenlijst en regel de fysieke beveiliging van de ceremonieruimte.
2. HSM-initialisatie: De HSM terugzetten naar de fabrieksinstellingen om te controleren of er geen eerder sleutelmateriaal aanwezig is; de firmwareversie en validatiestatus controleren.
3. Aanmaken van beheerdersreferenties: Maak de inloggegevens voor de HSM-beveiligingsfunctionaris (SO) aan met behulp van smartcards met een M-van-N-quorum; verdeel elke smartcard over een aparte beheerder; niemand bezit de meerderheid van de kaarten.
4. Genereren van root CA-sleutels: Genereer het root CA RSA- of ECC-sleutelpaar binnen de HSM-grenzen; de privésleutel wordt in hardware aangemaakt en bestaat nooit in platte tekst buiten de grenzen; de publieke sleutel wordt geëxporteerd voor het zelfondertekende root CA-certificaat.
5. Aanmaken van een root-CA-certificaat: Het zelfondertekende root-CA-certificaat wordt aangemaakt; de ondertekeningsbewerking vindt plaats binnen de HSM; de output is het root-CA-certificaat, waarbij de privésleutel in de hardware blijft.
6. Versleutelde sleutelback-up: Maak een versleutelde back-up van het root CA-sleutelmateriaal met behulp van het back-upmechanisme van de HSM; de back-up wordt versleuteld met de eigen sleutelversleutelingssleutel van de HSM; verdeel de autorisatiegegevens voor de back-up over de beheerders via het delen van geheimen; sla de back-up op een fysiek gescheiden, beveiligde locatie op.
7. Auditdocumentatie: Leg alle stappen van de ceremonie vast in een ondertekend auditdocument; dit document wordt met dezelfde zorgvuldigheid behandeld als het belangrijkste materiaal zelf; getuigen ondertekenen het verslag.

Hoe HSM's de PKI-beveiliging versterken

Veilige sleutelgeneratie en -opslag

HSM's genereren CA-privésleutels in een beveiligde hardwareomgeving met behulp van een hardwarematige TRNG (True Number Generator). Dit garandeert dat sleutels worden geproduceerd met cryptografische entropie van hoge kwaliteit, iets wat softwarematige sleutelgeneratie niet kan garanderen. In tegenstelling tot softwarematige sleutelopslag, bevindt de sleutel zich nooit in het geheugen van het besturingssysteem of op de schijf in platte tekst, waardoor de belangrijkste aanvalsoppervlakken die cybercriminelen misbruiken, worden geëlimineerd.

Cryptografische integriteit gedurende de gehele levenscyclus van de sleutel

De integriteit van PKI is afhankelijk van correct sleutelbeheer gedurende de gehele levenscyclus. HSM's verzorgen de rotatie, vernieuwing en intrekking van CA-sleutels, terwijl ze de hardwarematige beveiliging continu handhaven. Alle CA-ondertekeningsbewerkingen vinden plaats binnen de HSM; noch de privésleutel, noch de tussenliggende waarden van bewerkingen verlaten de hardwarematige beveiliging.

Fraudebestendige architectuur

HSM's detecteren en reageren op ongeautoriseerde fysieke toegangspogingen. Op FIPS 140-2 niveau 3 reageert de module actief op manipulatie door sleutelmateriaal te wissen voordat het kan worden geëxtraheerd. Dit betekent dat een aanvaller die fysieke toegang krijgt tot de HSM-module de privésleutel van de CA niet kan achterhalen, zelfs niet met behulp van gespecialiseerde hardware-analysetechnieken.

Naleving van regelgeving en certificering

Organisaties in gereguleerde sectoren moeten voldoen aan regelgeving zoals GDPR , PCI DSS en HIPAA . HSM's bieden FIPS-gecertificeerde hardwarebeveiliging voor CA-sleutels, voldoen aan de vereisten voor hardwarematige sleutelopslag in deze regelgeving en verminderen de documentatielast tijdens audits.

Schaalbaarheid voor Enterprise PKI

Naarmate PKI-implementaties groeien en meer identiteiten, apparaten en applicaties ondersteunen, schalen HSM's mee. Netwerk-HSM-apparaten ondersteunen meerdere CA-clients tegelijk; HSM-clusters verdelen de ondertekeningslast over meerdere apparaten; PKI as a Service- modellen gebruiken cloud-HSM's om geografische spreiding te bieden zonder dat er in elke regio hardware op locatie nodig is.

HSM's in certificaatlevenscyclusbeheer

Het efficiënt beheren van digitale certificaten is onlosmakelijk verbonden met het beheer van HSM's. HSM's spelen een rol in elke fase van de certificaatlevenscyclus waarin de privésleutels van de certificeringsinstantie worden gebruikt:

• Certificaatuitgifte: Elk certificaat dat de CA uitgeeft, wordt ondertekend met de privésleutel van de CA in de HSM; de HSM voert de ondertekening uit en stuurt alleen de handtekening terug.
• CRL-ondertekening: Certificaatintrekkingslijsten (CRL's) moeten volgens een vast schema door de CA-sleutel worden ondertekend; de HSM voert deze ondertekeningsbewerkingen automatisch uit voor de geplande uitgifte van CRL's.
• Vernieuwing van het CA-certificaat: Wanneer een CA-certificaat bijna verloopt, ondertekent de CA-sleutel in de HSM de verlenging; de privésleutel kan hetzelfde blijven (sleutelrollover) of er wordt een nieuwe sleutel gegenereerd in de HSM (sleutelgeneratieceremonie).
• Gecontroleerde toegang tot cryptografische materialen: De HSM dwingt multifactorauthenticatie en op rollen gebaseerde toegangscontroles af, zodat alleen geautoriseerde CA-beheerders sleutelbewerkingen kunnen initiëren.

Voor geautomatiseerd beheer van de levenscyclus van certificaten voor de volledige certificaatinventaris die wordt ondersteund door HSM-beveiligde CA-sleutels, raadpleegt u CertSecure Manager . Nu het CA/Browser Forum een ​​TLS-certificaatlevensduur van 200 dagen verplicht stelt vanaf maart 2026, en oplopend tot 47 dagen in 2029, is automatisering van certificaatuitgifte door HSM-beveiligde CA's niet langer optioneel.

HSM versus softwarematige sleutelopslag voor PKI: beslissingstabel

Afmeting	Hardwarebeveiligingsmodule (HSM)	Softwaregebaseerde sleutelopslag
Belangrijke beschermingsgrens	FIPS-gevalideerde hardwaregrens; sleutels bevinden zich nooit in platte tekst buiten de grens.	Sleutels opgeslagen in het bestandssysteem of de sleutelopslag van het besturingssysteem; toegankelijk voor processen met beheerdersrechten.
Weerstand tegen logische aanvallen	De sleutel bevindt zich nooit in het hostgeheugen; een inbreuk op het besturingssysteem legt de sleutel niet bloot.	Sleutels die kunnen worden geëxtraheerd uit geheugendumps, core-bestanden of toegang tot geprivilegieerde processen.
Weerstand tegen fysieke aanvallen	Sabotagedetectie op FIPS-niveau 3+ wist sleutels bij fysieke inbraak.	Na verwijdering van de schijf wordt een versleuteld sleutelbestand gevonden; de sterkte van de versleuteling hangt af van de kwaliteit van het wachtwoord.
CA-sleutelceremonie	Sleutel gegenereerd in de hardware tijdens een ceremonie waarbij getuigen aanwezig waren; auditrapport opgesteld.	Sleutel gegenereerd in software; geen hardwarematige bevestiging van de generatieomgeving.
Naleving van de regelgeving	FIPS 140-2 Niveau 3; voldoet aan PCI DSS, HIPAA en de PKI-vereisten van de overheid.	Voldoet mogelijk niet aan de hardware-specifieke eisen in gereguleerde kaders.
Bediening door meerdere personen	Fysiek smartcardquorum afgedwongen door HSM-hardware.	Bediening door meerdere personen is afhankelijk van toegangscontrole via de software; deze kan worden omzeild met de juiste besturingssysteemrechten.
Prestaties	Speciaal ontwikkelde cryptografische hardware; geoptimaliseerd voor grootschalige ondertekening.	Afhankelijk van de processor van de host; acceptabel voor workloads met een laag volume.
Geschiktheid van PKI-gebruiksscenario's	Vereist voor root-CA, uitgevende CA en elke openbaar vertrouwde CA-hiërarchie.	Alleen geschikt voor interne, niet-kritieke of test-PKI-omgevingen.

Integratievoorwaarden

• PKCS#11 of CNG/CSP-interface: Controleer of de CA-software de cryptografische interface van de HSM ondersteunt. Microsoft ADCS gebruikt CNG/CSP-providers; EJBCA, Dogtag en OpenCA gebruiken PKCS#11. Installeer de providerbibliotheek van de HSM-leverancier op de CA-server voordat u de CA-software installeert.
• Netwerkverbinding (netwerk-HSM): De CA-server moet de HSM-appliance kunnen bereiken via de geconfigureerde poort. Wederzijdse TLS-authenticatie tussen de CA-client en de HSM is vereist; configureer het clientcertificaat en het HSM-servercertificaat vóór de inschrijving.
• HSM-partitie aanmaken: Maak een speciale HSM-partitie aan voor de PKI-omgeving voordat u CA-sleutels genereert. De toegangsgegevens van de partitie moeten worden gedocumenteerd en onder M-of-N-beheer worden bewaard.
• Cluster met hoge beschikbaarheid: Configureer ten minste twee HSM-apparaten in een cluster met gesynchroniseerd sleutelmateriaal voordat de CA in productie gaat. Een PKI HSM-implementatie met slechts één apparaat vormt een single point of failure voor alle CA-activiteiten.

Richtlijnen voor storingsmodi

• Storing in het HSM-apparaat: Als het HSM-cluster volledig uitvalt, stoppen de CA-ondertekeningsprocessen; de uitgifte van certificaten en het ondertekenen van CRL's kunnen niet doorgaan. Vóór de productie: implementeer minimaal twee apparaten in het cluster; controleer de failover van het cluster; zorg voor een geteste sleutelback-up met een gedocumenteerde herstelprocedure.
• Verloren HSM-referenties (quorumverlies): Als M-van-N beheerders niet beschikbaar zijn, kunnen administratieve HSM-bewerkingen waarvoor een quorum vereist is, niet worden uitgevoerd. Zorg voor reservebeheerders voor elke quorumpositie; test het herstel jaarlijks met de reservegegevens.
• Verlopen CA-certificaat: Zelfs als de privésleutel van de certificeringsinstantie veilig in de HSM is opgeslagen, verhindert een verlopen certificaat de uitgifte van nieuwe certificaten. Houd de vervaldatum van het certificaat van de certificeringsinstantie in de gaten; vernieuw het certificaat tijdig met behulp van de in de HSM beveiligde sleutel.
• Mislukte CRL-publicatie: Als de HSM niet beschikbaar is wanneer een CRL-ondertekeningsbewerking is gepland, verloopt de CRL en beginnen vertrouwende partijen certificaten van die CA te weigeren. Verleng de geldigheidsperiode van de CRL vóór gepland HSM-onderhoud; implementeer waarschuwingen voor CRL-monitoring.
• Compromittering van de privésleutel van de certificeringsinstantie (softwarematige opslag): Als in software opgeslagen CA-sleutels worden gecompromitteerd, moet de volledige PKI-hiërarchie van de grond af opnieuw worden opgebouwd (alle certificaten opnieuw uitgegeven, vertrouwensankers bijgewerkt bij alle vertrouwende partijen). HSM's voorkomen dit scenario door het softwarematig extraheren van sleutels onmogelijk te maken.

Cloud HSM-oplossingen voor PKI

Cloud-HSM's bieden dezelfde FIPS-gevalideerde hardwarebeveiliging als on-premises HSM's via een beheerd servicemodel, waardoor de aanschaf en het beheer van hardware overbodig worden. Voor PKI-implementaties:

• Offline root CA: Het is nog steeds de beste werkwijze om een ​​draagbare, on-premises HSM (USB of PCIe) te gebruiken voor de offline root CA-ceremonie, zelfs als de uitgevende CA een cloud-HSM gebruikt. De root CA-HSM wordt alleen online gebracht voor de root-ondertekeningsceremonies.
• Online uitgevende CA: Cloud-HSM's zijn geschikt voor het beschermen van de privésleutels van certificeringsinstanties (CA's); de cloud-HSM biedt de FIPS-grens en HA-clusterfunctionaliteit; de CA-software maakt verbinding via PKCS#11 of een interface die specifiek is voor de cloudprovider.
• Hybride model: Een lokale root CA HSM plus cloud-issuing CA HSM's; het uitgevende CA-certificaat wordt ondertekend tijdens een ceremonie waarbij zowel de offline root HSM als de cloud HSM aanwezig zijn.

Zie onze handleiding over Cloud HSM's: Overzicht en gebruiksscenario's voor een gedetailleerde vergelijking van cloud HSM versus cloud KMS en beslissingen over de implementatietopologie. Voor beheerde HSM-services voor uw PKI, zie HSM as a Service.

Beste werkwijzen voor HSM-implementatie in PKI

1. Formuleer duidelijke kernbeleidslijnen voor het management: Leg de quorumgroottes, de toewijzing van beheerders, de procedures voor de sleutelceremonie, de vereisten voor back-upopslag en het toegangscontrolebeleid vast voordat u een HSM aanschaft.
2. Gebruik nooit een PKI HSM die slechts één apparaat bevat: Een enkele HSM zonder clusterpartner vormt een single point of failure voor alle CA-ondertekeningsbewerkingen; implementeer minimaal twee geclusterde apparaten per omgeving.
3. Test het herstel van back-ups vóór de productie: Maak een back-up van de HSM-sleutel en herstel deze naar een secundaire HSM voordat de CA in gebruik wordt genomen; een ongeteste back-up die tijdens een noodherstel mislukt, is gelijk aan geen back-up.
4. Controleer de vervaldatum van het CA-certificaat en de CRL: HSM-ondersteunde CA-activiteiten stoppen als het CA-certificaat of de CRL verloopt; implementeer monitoringwaarschuwingen met voldoende waarschuwingstijd om actie te kunnen ondernemen vóór de vervaldatum.
5. Automatiseer de uitgifte van certificaten: Nu de levensduur van TLS-certificaten in 2029 richting de 47 dagen gaat, is handmatig certificaatbeheer niet langer haalbaar; integreer de HSM-ondersteunde CA met een geautomatiseerd CLM-platform zoals... CertSecure Manager.

Conclusie

HSM's zijn geen optionele componenten in PKI: ze vormen de hardwarematige vertrouwensbasis die de hele PKI-hiërarchie betrouwbaar maakt. CA-privésleutels die alleen door software worden beschermd, zijn slechts één logische aanval verwijderd van een catastrofale inbreuk die de hele vertrouwensketen ongeldig maakt. FIPS 140-2 Level 3 HSM's elimineren dit risico door CA-privésleutels te binden binnen een fraudebestendige hardwarematige beveiliging waaruit ze nooit in onversleutelde vorm tevoorschijn komen. Naarmate PKI de basis blijft vormen voor TLS, codeondertekening, e-mailbeveiliging en digitale identiteit in elke sector, groeit ook de behoefte aan hardwarematige bescherming van CA-sleutels. Zie onze gerelateerde artikelen over HSM's en sleutelbeheer , Cloud-HSM's en PKI as a Service.

Veelgestelde Vragen / FAQ

Waarom vereisen PKI-omgevingen HSM's in plaats van softwarematige sleutelopslag?

De privésleutels van certificeringsinstanties (CA's) in software zijn kwetsbaar voor logische aanvallen (uitlezen van geheugen, toegang tot bevoorrechte besturingssystemen) en fysieke aanvallen (verwijderen van schijven). Een gecompromitteerde CA-sleutel stelt een aanvaller in staat om frauduleuze certificaten uit te geven voor elke identiteit binnen het vertrouwensbereik van die CA. Hardware-space managers (HSM's) beschermen CA-sleutels binnen een FIPS-gevalideerde hardwareomgeving, waardoor ze nooit in platte tekst naar buiten komen. Dit maakt extractie onmogelijk, zelfs als de host volledig is gecompromitteerd.

Welk FIPS 140-niveau is vereist voor PKI HSM's?

FIPS 140-2 Niveau 3 is de standaard voor de meeste PKI-implementaties binnen bedrijven en overheidsinstellingen. Niveau 3 vereist fraudebestendige hardware, identiteitsgebaseerde authenticatie (fysieke smartcardgegevens) en versleutelde sleutelextractie. FIPS 140-3 is de huidige standaard. Niveau 4 (actieve omgevingsrespons op manipulatie) wordt gebruikt voor de meest betrouwbare root CA-ceremonies.

Wat is een sleutelceremonie voor een root-CA?

Een gecontroleerd, gecontroleerd proces voor het genereren van de privésleutel van de root-CA binnen een HSM. Er zijn meerdere beheerders aanwezig; een M-van-N smartcardquorum zorgt ervoor dat niemand de sleutel in handen heeft; de HSM genereert de sleutel intern, zodat deze nooit buiten de hardware bestaat; alle stappen worden vastgelegd in een ondertekend auditdocument.

Hoe integreren HSM's met CA-software?

Via PKCS#11 (de meeste CA-software op Linux/Unix) of Microsoft CNG/CSP (Windows ADCS). De CA-software gebruikt de providerbibliotheek van de HSM; sleutelgeneratie en alle ondertekeningsbewerkingen worden omgeleid naar de HSM in plaats van naar het bestandssysteem van de host. De privésleutel van de CA wordt tijdens de ceremonie in de HSM gegenereerd en verlaat deze nooit in platte tekst.

Wat gebeurt er als de PKI HSM uitvalt?

De uitgifte van certificaten en het ondertekenen van CRL's worden stopgezet totdat de HSM is hersteld. Preventie vereist HSM-clusters (minimaal twee apparaten), geteste back-ups van sleutels en een verlengde geldigheidsduur van de CRL vóór gepland onderhoud. Een niet-geteste back-up is gelijk aan geen back-up.

Wat is het verschil tussen een on-premises HSM en een cloud-HSM voor PKI?

HSM's op locatie bieden de laagste latentie, volledige fysieke controle en zijn niet afhankelijk van een netwerk. Cloud-HSM's (HSM as a Service) bieden dezelfde FIPS-gevalideerde grens via een beheerde service, waardoor de aanschaf van hardware en de bijbehorende overheadkosten komen te vervallen. Aanbevolen werkwijze: een offline root-CA gebruikt een draagbare HSM op locatie; een online uitgevende CA kan, afhankelijk van het operationele model, een HSM op locatie of een cloud-HSM gebruiken.