HSM's – Sleutelbeheer

Hardware Security Modules (HSM's) zijn FIPS 140-2 of FIPS 140-3 gevalideerde fysieke apparaten die cryptografische sleutels genereren, opslaan en beschermen binnen een fraudebestendige hardwareomgeving, waaruit de sleutels nooit in onversleutelde vorm tevoorschijn komen. Ze handhaven toegangscontrole via multifactorauthenticatie, genereren sleutels met behulp van hardwarematige willekeurige getallengeneratoren en voeren alle cryptografische bewerkingen binnen de hardware uit, waarbij alleen de resultaten (handtekeningen, versleutelde tekst, onversleutelde gegevens) worden teruggestuurd naar de aanroepende applicatie. De aanbevolen actie: implementeer HSM's als de Root of Trust voor elke infrastructuur waar een compromittering van cryptografische sleutels aanzienlijke gevolgen zou hebben voor de beveiliging of naleving van regelgeving, waaronder PKI, codeondertekening, TLS, databaseversleuteling en betalingsverwerking.

Kort antwoord: Wat doen HSM's voor sleutelbeheer?

Een HSM beheert cryptografische sleutels gedurende hun volledige levenscyclus: generatie (hardwarematige TRNG), opslag (binnen de FIPS-grens, versleuteld in rust), gebruik (ondertekenings- en decryptiebewerkingen uitgevoerd in hardware), rotatie, back-up (alleen versleutelde export) en vernietiging (met auditbewijs). Het dwingt toegangscontrole met meerdere factoren af, zodat alleen geautoriseerde rollen sleutelbewerkingen kunnen uitvoeren. FIPS 140-2 Niveau 3 (de standaard voor de meeste bedrijfs- en compliance-workloads) voegt daar sabotagebestendigheid, identiteitsgebaseerde authenticatie en versleutelde sleutelextractie aan toe. HSM's zijn de erkende beste praktijk voor de bescherming van encryptiesleutels volgens NIST SP 800-57. Voor cloudimplementatieopties, zie onze handleiding over Cloud HSM's: Overzicht en gebruiksscenario's.

Wat is een Hardware Security Module (HSM)?

Een hardwarebeveiligingsmodule (HSM) is een fysiek computerapparaat dat sterke authenticatie en cryptografische verwerking rondom het gebruik van digitale sleutels beschermt en mogelijk maakt. In een geïsoleerde, fraudebestendige omgeving genereren en beveiligen deze apparaten cryptografische sleutels, beschermen ze kritieke cryptografische bewerkingen en handhaven ze het vastgestelde beleid voor het gebruik van die sleutels. HSM's zijn verkrijgbaar in verschillende uitvoeringen:

• Netwerkapparaten: gedeeld over meerdere clients via TCP/IP; het gangbare implementatiemodel voor centrale HSM-services binnen bedrijven.
• PCIe-kaarten: Direct ingebouwd in een hostserver; elimineert netwerklatentie voor applicaties die de hoogste cryptografische doorvoer vereisen.
• Via USB aangesloten apparaten: Draagbaar, lagere doorvoersnelheid; gebruikt voor offline CA-ceremonies en ontwikkelaarswerkstations.
• In de cloud gehoste HSM's: FIPS-gecertificeerde hardware, beheerd door een provider; op afstand toegankelijk zonder hardware op locatie.

De opkomst van hardwarebeveiligingsmodules

Organisaties in alle sectoren implementeren steeds vaker HSM-systemen, omdat de kosten, de nalevingseisen en de beveiligingsrisico's van een sleutelinbreuk steeds groter worden. De belangrijkste drijfveren achter de adoptie van HSM zijn:

• Cyberoorlogvoering en geavanceerde persistente dreigingen: Staten beschouwen cryptografisch sleutelmateriaal als een waardevol doelwit dat permanente toegang tot versleutelde communicatie en gegevens mogelijk maakt.
• Regelgeving gegevensprivacy: GDPR, CCPA, HIPAA, PCI DSS en andere raamwerken stellen eisen aan de bescherming van cryptografische sleutels waaraan HSM's specifiek zijn ontworpen om te voldoen.
• Mobiel betalen en digitale identiteit: Betalingssystemen en digitale identiteitsinfrastructuren zijn voor de meest betrouwbare werking afhankelijk van hardwarematig opgeslagen sleutels.
• IoT en verbonden apparaten: Apparaatidentificatiecertificaten en codeondertekeningssleutels voor firmware-updates vereisen hardwarematige beveiliging om apparaatimitatie of grootschalige verspreiding van kwaadaardige firmware te voorkomen.

Validatieniveaus van FIPS 140 en wat ze betekenen

FIPS 140-niveau	Belangrijke vereisten boven het vorige niveau	Typisch gebruiksvoorbeeld
Niveau 1	Werkend cryptografisch algoritme; apparatuur van productiekwaliteit	Software-encryptiemodules; toepassingen met een lage beveiligingsgraad
Niveau 2	Authenticatie op basis van rollen; fraudebestendige fysieke coatings of zegels; OS goedgekeurd op CC EAL2+-niveau.	Algemene bedrijfsapplicaties; softwarelicenties met hardwarevalidatie.
Niveau 3	Manipulatiebestendigheid; identiteitsgebaseerde authenticatie; versleutelde extractie van cruciale beveiligingsparameters (privésleutels)	PKI CA-sleutels; TLS-privésleutels; codeondertekeningssleutels; financieel sleutelbeheer; de meeste compliance-frameworks.
Niveau 4	Actieve reactie op manipulatie; detectie van omgevingsinvloeden (temperatuur, spanning, straling); automatische reset van de sleutel bij een aanval.	Hoofdsleutels van betalingsnetwerken; geclassificeerde overheidsapplicaties; CA-ceremonies met de hoogste betrouwbaarheid.

FIPS 140-3 is de huidige validatiestandaard; de overgang van FIPS 140-2 is in 2021 begonnen en is nog steeds gaande. De meeste organisaties specificeren FIPS 140-2 niveau 3 als minimum voor zeer gevoelige sleutelbeheerprocessen. Controleer voor HSM's die momenteel worden geëvalueerd, zowel het huidige validatieniveau als of de roadmap van de leverancier FIPS 140-3-certificering voor de specifieke hardwaregeneratie omvat.

Gegevens beveiligen met behulp van hardwarebeveiligingsmodules: sleutelbeheerfuncties

HSM's bieden uitgebreid sleutelbeheer gedurende de volledige levenscyclus van de sleutel:

• Sleutelgeneratie: HSM's gebruiken een hardwarematige True Random Number Generator (TRNG), gebouwd volgens NIST SP 800-90A (Hash_DRBG) en doorgaans op PTG.2-niveau volgens de BSI-specificaties AIS20 en AIS31. Privé- en geheime sleutels kunnen alleen worden gegenereerd uit gegevens die door dergelijke DRBG's worden geretourneerd, waardoor cryptografische entropie van hoge kwaliteit wordt gegarandeerd die niet beschikbaar is bij softwarematige willekeurige bronnen.
• Sleutelopslag: De sleutels worden binnen de FIPS-beveiliging opgeslagen. Tijdens actief gebruik bestaan ​​ze alleen in onversleutelde vorm in het beveiligde RAM-geheugen (CPU-cachegeheugen). In rust in de HSM is het sleutelmateriaal AES-256-versleuteld. Sleutels bestaan ​​nooit in onversleutelde vorm op een externe schijf.
• Sleutelgebruik en autorisatie: Zodra de sleutels in de HSM zijn opgeslagen, wordt de toegang gecontroleerd via multifactorauthenticatie. De meeste HSM's ondersteunen zowel op rollen gebaseerde authenticatie als het vierogenprincipe (tweepersoonsregel), wat betekent dat meerdere geautoriseerde personen nodig zijn om zeer gevoelige bewerkingen uit te voeren.
• Sleutelrotatie: De HSM beheert sleutelrotatie zonder dat oud of nieuw sleutelmateriaal buiten de beveiligingslaag terechtkomt. Applicaties gebruiken de nieuwe sleutel voor nieuwe bewerkingen, terwijl de HSM de oude sleutel bewaart voor het ontsleutelen van eerder versleutelde gegevens totdat deze niet langer nodig is.
• Sleutelback-up: HSM's exporteren sleutelmateriaal alleen in versleutelde vorm, omhuld door een sleutelversleutelingssleutel die zelf nooit in onversleutelde vorm de HSM verlaat. Dit maakt noodherstel mogelijk zonder dat er ooit onversleuteld sleutelmateriaal buiten de hardwaregrens hoeft te worden gegenereerd.
• Sleutelvernietiging: Veilige verwijdering met een verifieerbaar auditspoor, dat voldoet aan de eisen van het compliancekader voor bewijsmateriaal met betrekking tot vernietiging.

Implementatievoorbeeld: HSM-sleutelbeheer voor Enterprise PKI

1. Root CA offline HSM: Een via USB aangesloten of PCIe HSM op FIPS 140-2 niveau 3 bevat de privésleutel van de root-CA. De HSM blijft offline en wordt alleen online gezet voor ondertekeningsceremonies van de root-CA. Toegang vereist een quorum van meerdere personen met M-of-N smartcards.
2. Uitgevende CA-netwerk HSM: Een netwerkgekoppelde HSM bewaart de privésleutel van de uitgevende certificeringsinstantie (CA) voor online certificaatuitgifte. PKCS#11-integratie verbindt de CA-software met de HSM; alle ondertekeningsbewerkingen voor eindgebruikerscertificaten vinden plaats binnen de hardwaregrenzen.
3. TLS-privésleutelbeveiliging: Webservers en loadbalancers slaan TLS-privésleutels op in de HSM van het netwerk. De HSM voert de TLS-handshake-ondertekening uit; de privésleutel komt nooit in het geheugen van de webserver terecht.
4. Codeondertekeningssleutels: De privésleutels voor codeondertekening worden opgeslagen in de HSM en gebruikt door CodeSign Secure Voor alle software-releaseondertekeningen. De doorvoer van ondertekeningsprocessen wordt afgehandeld door de HSM; ondertekeningssleutels kunnen niet naar een ontwikkelaarswerkstation worden geëxporteerd.
5. Levenscyclusbeheer van certificaten: CertSecure Manager Het systeem houdt alle certificaten bij die worden ondersteund door HSM-privésleutels en automatiseert de verlenging vóór de vervaldatum, inclusief de 47-daagse certificaatlevensduur die het CA/Browser Forum vanaf 2029 verplicht stelt.

Risico's van cryptografie die uitsluitend op software gebaseerd is

Voor organisaties die ervoor kiezen om HSM's te omzeilen, is softwarematige cryptografie het alternatief. De risicocategorieën zijn goed bekend:

• Logische aanvallen: Aanvallen op het geheugen of de schijf van de host om cryptografische sleutels te lokaliseren. Methoden omvatten het exploiteren van kwetsbaarheden tijdens runtime om toegang te krijgen tot het servergeheugen, het extraheren van core data dumps en het onderscheppen van wachtwoorden voor softwarematig versleutelde sleutelbestanden.
• Fysieke aanvallen: Het verwijderen van harde schijven of SSD's, het bevriezen van vluchtig geheugen (cold-boot-aanval) en hardwarematige geheugenanalyse om belangrijke informatie van de schijf of het RAM-geheugen te extraheren.

Hoe beschermt een HSM hiertegen? De beschermde geheimen bevinden zich nooit buiten de HSM en bestaan ​​binnen de HSM alleen in platte tekst tijdens actief gebruik in het beschermde RAM-geheugen. Gegevens die zich in het apparaat bevinden, zijn versleuteld met AES-256. HSM's van FIPS 140-2 niveau 3 en hoger detecteren omgevingsveranderingen (abnormale temperatuur, over- of onderspanning). HSM's van niveau 4 breiden dit uit met actieve detectie van fysieke aanvallen en wissen al het sleutelmateriaal als de hardware beschadigd of gemanipuleerd wordt.

Beveiligingsnaleving en -regelgeving

Naleving van privacy- en gegevensbeveiligingsvereisten is een van de belangrijkste drijfveren voor de implementatie van HSM's in diverse sectoren. Belangrijke frameworks die specifiek ingaan op de vereisten voor HSM- of hardwarematige sleutelbescherming zijn:

• Wereldwijde regelgeving: Artikel 32 van de Algemene Verordening Gegevensbescherming (AVG) vereist passende technische maatregelen, waaronder encryptie met sterke sleutelbescherming; vereiste 3 van de PCI DSS (Payment Card Industry Data Security Standard) specificeert beheersmaatregelen voor cryptografische sleutels, inclusief hardwarebeveiliging, voor de bescherming van betaalkaartgegevens.
• Amerikaanse regelgeving: De technische beveiligingsmaatregelen van de HIPAA-beveiligingsregel vereisen encryptie en sleutelbeheer voor elektronische patiëntgegevens (ePHI); HITECH breidt de HIPAA-vereisten uit; validatie volgens FIPS 140-2/140-3 is verplicht voor federale overheidssystemen die gevoelige, niet-geclassificeerde informatie verwerken, conform NIST SP 800-52.
• Frameworkvereisten: NIST SP 800-57 (Key Management Recommendations) specificeert de belangrijkste beheersmaatregelen voor de levenscyclus die HSM's implementeren; NIST SP 800-131A specificeert goedgekeurde algoritmeovergangen die HSM's afdwingen door te bepalen welke bewerkingen zijn toegestaan.

De toekomst van hardwarebeveiligingsmodules

De toekomst van HSM's wordt bepaald door twee belangrijke ontwikkelingen. Ten eerste breiden HSM's zich uit naar cloud- en hybride implementatiemodellen: organisaties hebben hardwarematig sleutelbeheer nodig in cloudomgevingen zonder on-premises hardware in elke regio, wat de groei van HSM as a Service en cloud-gekoppelde HSM-implementaties stimuleert. Ten tweede wordt de gereedheid voor post-kwantumcryptografie (PQC) een selectiecriterium: de huidige HSM-algoritmen, RSA en ECC, zijn kwetsbaar voor het algoritme van Shor op een toekomstige, cryptografisch relevante kwantumcomputer. NIST heeft de post-kwantumstandaarden in 2024 afgerond (ML-KEM, FIPS 203; ML-DSA, FIPS 204; SLH-DSA, FIPS 205). HSM-leveranciers ontwikkelen firmware-updates ter ondersteuning van deze nieuwe algoritmen; organisaties die een nieuwe HSM-infrastructuur bouwen, moeten de roadmap voor PQC-ondersteuning van de leverancier raadplegen. Zie onze PQC-adviesdiensten voor migratieplanning.

Door HSM's in te zetten, leggen organisaties de basis voor bedrijfsbrede encryptie en sleutelbeheer dat cryptografische sleutels nu en tijdens de post-kwantumtransitie kan beschermen. Of het nu gaat om PKI , codeondertekening, sleutelinjectie of database-encryptie, HSM's bieden hardwarematige beveiliging die softwarematige alternatieven niet kunnen evenaren.

Veelgestelde Vragen / FAQ

Wat is een Hardware Security Module (HSM)?

Een fraudebestendig fysiek apparaat dat cryptografische sleutels genereert, opslaat en beheert binnen een hardwarematige beveiliging waaruit de sleutels nooit in platte tekst tevoorschijn komen. Gevalideerd volgens FIPS 140-2 of FIPS 140-3 van niveau 1 tot en met niveau 4. Beschikbaar als netwerkapparaten, PCIe-kaarten, USB-apparaten en cloudgebaseerde instanties.

Wat is het verschil tussen FIPS 140-2 niveau 2, niveau 3 en niveau 4?

Niveau 2 voegt authenticatie op basis van rollen en fraudebestendige coatings toe. Niveau 3 (de meest voorkomende bedrijfsstandaard) voegt fraudebestendigheid, authenticatie op basis van identiteit en versleutelde sleutelextractie toe. Niveau 4 voegt actieve sabotagerespons toe: het apparaat detecteert fysieke aanvallen, temperatuur- en spanningsaanvallen en wist al het sleutelmateriaal. De meeste financiële, overheids- en PKI-toepassingen gebruiken niveau 3.

Hoe beschermt een HSM tegen aanvallen waarbij sleutels worden gestolen?

Sleutels die binnen de beveiligingsgrens worden gegenereerd, bestaan ​​nooit in platte tekst daarbuiten; bewerkingen vinden plaats binnen de hardware; data in rust is AES-256 versleuteld; fysieke manipulatiedetectie op niveau 3+ zorgt ervoor dat het apparaat reageert op fysieke inbraak; multifactorauthenticatie (smartcards plus pincode) is vereist voor toegang. Beschermt tegen zowel logische (software-exploitatie) als fysieke (hardware-extractie) aanvallen.

Wat is de belangrijkste levenscyclus in HSM-sleutelbeheer?

Generatie (hardwarematige TRNG volgens NIST SP 800-90A), opslag (versleuteld binnen de FIPS-grens), gebruik (alle bewerkingen binnen de hardware), rotatie (zonder de sleutel in platte tekst bloot te stellen), back-up (versleutelde export alleen met behulp van de door de HSM gegenereerde KEK) en vernietiging (veilige verwijdering met auditbewijs). De HSM handhaaft de bescherming gedurende alle fasen.

Welke nalevingsvoorschriften zijn vereist voor HSM's?

PCI DSS-vereiste 3 voor het beheer van betaalkaartsleutels; HIPAA-beveiligingsregel voor de bescherming van encryptiesleutels voor elektronische patiëntgegevens; FIPS 140-2/140-3 voor toepassingen van de Amerikaanse federale overheid; NIST SP 800-57 voor algemene best practices voor sleutelbeheer; GDPR-artikel 32 voor passende technische maatregelen; PCI HSM voor HSM-functies voor betalingen.

Wat zijn de risico's van cryptografie die uitsluitend op software gebaseerd is?

Logische aanvallen maken gebruik van het hostgeheugen (core dumps, toegang tot geprivilegieerde processen, toegang tot de hypervisor) en de schijf (versleutelde sleutelbestanden met blootgestelde wachtwoorden). Fysieke aanvallen omvatten het verwijderen van de harde schijf en het uitlezen van het geheugen tijdens een cold boot. HSM's elimineren deze aanvallen: sleutels bestaan ​​nooit in platte tekst buiten de hardware en fysieke toegang zonder inloggegevens levert geen sleutelmateriaal op.