Enterprise editie

HSM- en FIPS-validatie

In het kort

Ondertekenen met NextPDF Enterprise verbindt via PKCS#11 met hardware security modules (HSM’s) en voert cryptografie uit met Federal Information Processing Standards (FIPS)-gevalideerde modules. De privésleutel achter een handtekening blijft binnen gecertificeerde hardware, en de cryptografie draait binnen een onafhankelijk gevalideerde module. Je krijgt de twee zekerheidseigenschappen waarvan gereguleerde en hoogwaardige ondertekeningsprocessen afhankelijk zijn.

Deze pagina geeft kopers bewijs en zekerheid. Ze legt uit welke standaarden de ondertekeningsintegratie volgt, met welke apparaatklassen ze werkt, wat de interoperabiliteitspositie is en welk validatiebewijs je kunt opvragen voordat je je vastlegt. Ze beschrijft geen implementatiedetails. Zie voor het overzicht van standaardenconformiteit Compliance en conformiteit.

Ondersteuning voor hardware security modules

Een hardware security module is een gecertificeerd apparaat dat privésleutels genereert en bewaart en cryptografische bewerkingen voor je uitvoert, zodat sleutelmateriaal het apparaat nooit verlaat. NextPDF Enterprise ondertekent via deze apparaten met behulp van PKCS#11. PKCS#11 is de breed toegepaste standaardprogrammeerinterface, ook bekend als Cryptoki, voor apparaten die cryptografische informatie bewaren en cryptografische functies uitvoeren. De standaard definieert ook hoe sleutels worden beheerd op een cryptografisch token, waardoor één standaardintegratie een breed scala aan apparaten kan bereiken.

Omdat de integratie PKCS#11 volgt in plaats van een leverancierspecifieke interface, werkt ze met de gangbare klassen van hardwarematig sleutelbeheer:

Netwerk- en appliance-HSM’s die worden gebruikt om het sleutelbeheer voor groepen ondertekeningsdiensten te centraliseren.
Cloud-HSM-diensten die een PKCS#11-interface bieden aan applicaties die in een beheerde omgeving draaien.
Smartcards en ondertekeningstokens die worden gebruikt wanneer een ondertekenaar de sleutel op een persoonlijk apparaat bewaart.

Hardwarematig sleutelbeheer wordt gecombineerd met het handtekeningprofiel voor langdurige archivering, zodat een handtekening afkomstig is van een beschermde sleutel en jarenlang verifieerbaar blijft. Zie Compliance en conformiteit voor de handtekeningprofielen en de bijbehorende standaarden.

FIPS-gevalideerde cryptografie

Voor implementaties met eisen aan cryptografische zekerheid werkt NextPDF Enterprise met FIPS-gevalideerde cryptografische modules. FIPS 140-3 is de standaard van de Verenigde Staten voor beveiligingseisen aan cryptografische modules. Deze vervangt FIPS 140-2 en sluit aan op de internationale standaard ISO/IEC 19790.

Validatie is een onafhankelijk proces, geen bewering van de leverancier. De conformiteit van een module met de beveiligingseisen voor cryptografische modules wordt vastgesteld door geaccrediteerde tests aan de hand van een vastgestelde reeks beweringen. De valideringsautoriteit houdt een lijst bij van gevalideerde modules. Wanneer je een gevalideerde module gebruikt, draait de cryptografie achter een handtekening binnen hardware die dat onafhankelijke proces heeft doorstaan, in plaats van in niet-geverifieerde code.

NextPDF Enterprise geeft geen eigen FIPS-validatie uit; het werkt met gevalideerde modules, zodat jouw ondertekening op hun zekerheid steunt. Welke module van toepassing is, hangt af van de hardware of clouddienst die je implementeert.

Waarom het zo werkt

De integratie richt zich op de standaardinterface PKCS#11, niet op een leverancier-API. Eén standaardintegratie bereikt zo netwerk-HSM’s, clouddiensten voor sleutels, smartcards en ondertekeningstokens als klasse. NextPDF werkt met FIPS-gevalideerde modules in plaats van een eigen validatie uit te geven. Validatie hangt aan een cryptografische module, niet aan de software die zo’n module aanroept, dus het overnemen van de zekerheid van een module is de eerlijke en duurzame positie. Sleutelbeheer stopt bij de apparaatgrens, en de zekerheid die een koper bevestigt is de gepubliceerde validatie van de module bij de valideringsautoriteit. Zo blijft het ondertekeningstraject standaardconform en leverancierneutraal, zodat een handtekening afkomstig is van een beschermde sleutel en onafhankelijk verifieerbaar blijft.

Ontwerpachtergrond: HSM-ondersteund ondertekenen.

Interoperabiliteit en validatiebewijs

NextPDF Enterprise is gebouwd om samen te werken met standaardconforme hardware, niet met één enkele leverancier. De interoperabiliteitspositie is als volgt:

Standaardinterface. Het ondertekenen benadert hardware via de PKCS#11-standaard, zodat apparaten met een conforme interface als klasse worden ondersteund.
Gevalideerde modules. De cryptografie draait met FIPS-gevalideerde modules waarvan de validatie onafhankelijk is vastgesteld.
Op standaarden gebaseerde handtekeningen. De geproduceerde handtekeningen volgen de baselineprofielen van PDF Advanced Electronic Signatures (PAdES), inclusief het niveau voor langdurige archivering voor duurzame verifieerbaarheid. Zie Compliance en conformiteit.

Als je koper of auditor bent en dit wilt bevestigen voordat je je vastlegt, kan NextPDF op verzoek bewijs leveren, waaronder:

De klassen van hardware security modules waartegen de ondertekeningsintegratie wordt getest, en de interoperabiliteitspositie voor jouw doelapparaat.
De FIPS-gevalideerde modules die in gebruik zijn, en hoe je de validatie daarvan bij de valideringsautoriteit kunt bevestigen.
De geproduceerde handtekeningprofielen, en hoe een onafhankelijke verifier deze valideert.

Een validatierapport aanvragen

Om een validatierapport aan te vragen of je hardware- en zekerheidseisen te bespreken voordat je koopt, neem je contact op met sales via het licentieportaal. Vertel ons welke hardware security module of clouddienst voor sleutels je wilt gebruiken en wat je FIPS-zekerheidsniveau is. Wij koppelen je eis aan de ondersteunde apparaatklassen en het validatiebewijs dat daarvoor beschikbaar is.

Publicatiegrens

Deze pagina documenteert uitsluitend extern waarneembaar gedrag en het ondersteunde publieke API-oppervlak. Interne namespace-paden, helperklassen, mechanismetabellen, runbook-bestandsnamen en ticketprefixen vallen buiten de scope.