Enterprise Edition

HSM- und FIPS-Validierung

Auf einen Blick

Die Signierung in NextPDF Enterprise bindet Hardware-Sicherheitsmodule (HSMs) über PKCS#11 ein und führt Kryptografie mit Federal-Information-Processing-Standards(FIPS)-validierten Modulen aus. Der private Schlüssel hinter einer Signatur bleibt innerhalb zertifizierter Hardware, und die Kryptografie läuft innerhalb eines unabhängig validierten Moduls. So erhalten Sie die beiden Sicherheitseigenschaften, auf die regulierte und hochwertige Signatur-Workflows angewiesen sind.

Diese Seite liefert Käufern Nachweis und Sicherheit. Sie erläutert die Standards, denen die Signaturintegration folgt, die Geräteklassen, mit denen sie zusammenarbeitet, die Interoperabilitätshaltung und die Validierungsnachweise, die Sie anfordern können, bevor Sie sich festlegen. Sie beschreibt keine Implementierungsdetails. Eine Übersicht zur Standardkonformität finden Sie unter Compliance und Konformität.

Unterstützung für Hardware-Sicherheitsmodule

Ein Hardware-Sicherheitsmodul ist ein zertifiziertes Gerät, das private Schlüssel erzeugt und verwahrt und kryptografische Operationen für Sie ausführt, sodass das Schlüsselmaterial das Gerät nie verlässt. NextPDF Enterprise signiert über diese Geräte mithilfe von PKCS#11. PKCS#11 ist die weit verbreitete standardisierte Programmierschnittstelle, auch als Cryptoki bekannt, für Geräte, die kryptografische Informationen vorhalten und kryptografische Funktionen ausführen. Der Standard definiert außerdem, wie Schlüssel auf einem kryptografischen Token verwaltet werden — deshalb erreicht eine einzige standardkonforme Integration eine breite Palette von Geräten.

Da die Integration PKCS#11 statt einer herstellerspezifischen Schnittstelle folgt, funktioniert sie über die gängigen Klassen der Hardware-Schlüsselverwahrung hinweg:

Netzwerk- und Appliance-HSMs, die eingesetzt werden, um die Schlüsselverwahrung für Flotten von Signaturdiensten zu zentralisieren.
Cloud-HSM-Dienste, die Anwendungen in einer verwalteten Umgebung eine PKCS#11-Schnittstelle bereitstellen.
Smartcards und Signing-Token, die eingesetzt werden, wenn ein Unterzeichner den Schlüssel auf einem persönlichen Gerät verwahrt.

Die Hardware-Schlüsselverwahrung lässt sich mit dem Signaturprofil für die Langzeitarchivierung kombinieren, sodass eine Signatur aus einem geschützten Schlüssel stammt und über Jahre hinweg prüfbar bleibt. Die Signaturprofile und ihre Standards finden Sie unter Compliance und Konformität.

FIPS-validierte Kryptografie

Für Deployments mit Anforderungen an den Nachweis kryptografischer Sicherheit arbeitet NextPDF Enterprise mit FIPS-validierten kryptografischen Modulen. FIPS 140-3 ist der US-amerikanische Standard für die Sicherheitsanforderungen an kryptografische Module. Er löst FIPS 140-2 ab und orientiert sich am internationalen Standard ISO/IEC 19790.

Die Validierung ist ein unabhängiger Prozess, keine Herstellerbehauptung. Die Konformität eines Moduls mit den Sicherheitsanforderungen für kryptografische Module wird durch akkreditierte Prüfungen anhand eines definierten Satzes von Assertionen festgestellt. Die Validierungsstelle listet validierte Module. Wenn Sie ein validiertes Modul verwenden, läuft die Kryptografie hinter einer Signatur innerhalb von Hardware, die diesen unabhängigen Prozess bestanden hat, statt in ungeprüftem Code.

NextPDF Enterprise stellt keine eigene FIPS-Validierung aus; es arbeitet mit validierten Modulen, sodass Ihre Signierung deren Sicherheitsgewährleistung erbt. Welches Modul gilt, hängt von der Hardware oder dem Cloud-Dienst ab, den Sie einsetzen.

Warum es so funktioniert

Die Integration zielt auf die PKCS#11-Standardschnittstelle ab, nicht auf eine herstellerspezifische API. Eine einzige standardkonforme Integration erreicht dann Netzwerk-HSMs, Cloud-Schlüsseldienste, Smartcards und Signing-Token als Klasse. NextPDF arbeitet mit FIPS-validierten Modulen, statt eine eigene Validierung auszustellen. Die Validierung ist an ein kryptografisches Modul gebunden, nicht an die Software, die es aufruft — deshalb ist es die ehrliche und dauerhafte Position, die Sicherheitsgewährleistung eines Moduls zu erben. Die Schlüsselverwahrung endet an der Gerätegrenze, und die Sicherheit, die ein Käufer bestätigt, ist die veröffentlichte Validierung des Moduls bei der Validierungsstelle. So bleibt der Signaturpfad standardkonform und herstellerneutral, sodass eine Signatur aus einem geschützten Schlüssel stammt und unabhängig prüfbar bleibt.

Design-Hintergrund: HSM-gestützte Signierung.

Interoperabilität und Validierungsnachweise

NextPDF Enterprise ist darauf ausgelegt, mit standardkonformer Hardware zusammenzuarbeiten, nicht mit einem einzelnen Hersteller. Die Interoperabilitätshaltung lautet:

Standardschnittstelle. Die Signierung erreicht die Hardware über den PKCS#11-Standard, sodass Geräte mit einer konformen Schnittstelle als Klasse unterstützt werden.
Validierte Module. Die Kryptografie läuft mit FIPS-validierten Modulen, deren Validierung unabhängig festgestellt wurde.
Standardbasierte Signaturen. Die erzeugten Signaturen folgen den Baseline-Profilen der PDF Advanced Electronic Signatures (PAdES), einschließlich der Stufe für die Langzeitarchivierung zur dauerhaften Prüfbarkeit. Siehe Compliance und Konformität.

Wenn Sie als Käufer oder Auditor dies vor einer Entscheidung bestätigen müssen, kann NextPDF auf Anfrage Nachweise bereitstellen, darunter:

Die Klassen von Hardware-Sicherheitsmodulen, gegen die die Signaturintegration getestet wird, sowie die Interoperabilitätshaltung für Ihr Zielgerät.
Die verwendeten FIPS-validierten Module und wie sich ihre Validierung bei der Validierungsstelle bestätigen lässt.
Die erzeugten Signaturprofile und wie ein unabhängiger Prüfer sie validiert.

Einen Validierungsbericht anfordern

Um einen Validierungsbericht anzufordern oder Ihre Hardware- und Sicherheitsanforderungen vor dem Kauf zu besprechen, wenden Sie sich über das Lizenzportal an den Vertrieb. Nennen Sie uns Ihr Ziel-Hardware-Sicherheitsmodul oder Ihren Cloud-Schlüsseldienst und Ihre FIPS-Sicherheitsstufe. Wir ordnen Ihre Anforderung den unterstützten Geräteklassen und den dafür verfügbaren Validierungsnachweisen zu.

Veröffentlichungsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismustabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Geltungsbereichs.