Enterprise Edition

Sicherheit — HSM, PKCS#11 und FIPS-Modus

Auf einen Blick

NextPDF Enterprise ergänzt einen PKCS#11-Hardware-Token-Signierpfad und eine FIPS-Modus-Kryptografie-Policy über der Sicherheitsoberfläche von Core und Pro. Diese Seite benennt Verhalten, Grenzen und die explizite Haltung zu FIPS-Zertifizierung und Schlüsselverwahrung.

Verfügbarkeit & Lizenzierung

Diese Funktion wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und wird mit einem Lizenz-Envelope der Enterprise-Stufe aktiviert. Ein Deployment ohne diese Berechtigung lädt die Klassen der Funktion nicht. Editionen vergleichen und Lizenz erwerben.

Konzeptioneller Überblick

Die Enterprise-Sicherheitsoberfläche hat drei Teile: einen Hardware-Token-Signierer, eine FIPS-Modus-Krypto-Policy und einen Power-on-Self-Test-Guard.

Der Hardware-Token-Signierer adaptiert ein PKCS#11-Token — eine Smartcard, ein USB-Gerät oder ein netzwerkgebundenes HSM. Der Signierer lokalisiert das Zertifikat und den privaten Schlüssel auf dem Token per Label. Anschließend bittet er das Token, die Signatur zu berechnen. Der private Schlüssel verlässt die Token-Grenze nicht; die Operation läuft innerhalb des Tokens. Die Token-Signieroperation, die Session und der Benutzer-Login folgen PKCS#11 v3.1 §5. Der HSM-Pfad benötigt die PHP-Erweiterung ext-pkcs11. Diese Erweiterung ist nicht Teil von Standard-PHP. Installieren Sie sie separat. Verwenden Sie die Verfügbarkeitsprüfung, bevor Sie den Signierer konstruieren.

Die FIPS-Modus-Krypto-Policy schränkt kryptografische Wahlmöglichkeiten auf eine zugelassene Menge ein. Sie hat zwei Presets. Das strikte Preset erlaubt die Hashes SHA-256, SHA-384 und SHA-512; RSA- und ECDSA-Signatur-OIDs mit diesen Hashes; AES-256-CBC-Verschlüsselung; und Mindestschlüsselgrößen von RSA 2048 und EC 256. Das Standard-Preset ist dasselbe, erlaubt aber zusätzlich AES-128-CBC für ältere Interoperabilität. Ein Laufzeit-Guard umhüllt die Policy. Der Guard prüft jeden Hash, jede Signatur-OID, jeden Verschlüsselungsalgorithmus und jede Schlüsselstärke, bevor die Operation läuft. Eine unzulässige Wahl löst eine typisierte Verletzung aus und stoppt die Operation. Der Pfad ist fail-closed: Die Policy lockert sich niemals selbst und substituiert niemals einen schwächeren Algorithmus. Die minimale RSA-Schlüssellänge folgt NIST SP 800-131A Rev.2 §3. Die ECDSA-Kurven- und Hash-Paarung folgt FIPS 186-5 §6.1.1.

Der Power-on-Self-Test-Guard führt beim Prozessstart einmalig eine Known-Answer-Test-Batterie aus. Die Batterie deckt die zugelassenen Hash-, MAC-, Verschlüsselungs-, Signatur- und Zufallsbit-Funktionen ab. Schlägt ein Test fehl, tritt der Enterprise-FIPS-Guard in einen Fehlerzustand und verweigert kryptografische Dienste bis zum Reset. Das Ergebnis wird für die Prozesslebensdauer gecacht; ein On-Demand-Neulauf ist verfügbar. Die Self-Test-Kategorie und der Trigger des bedingten Tests folgen ISO/IEC 19790:2025 §7.10 und §7.10.3.

Warum es so funktioniert

Die tragende Entscheidung besteht darin, den privaten Schlüssel innerhalb der Token-Grenze zu halten und die Krypto-Policy fail-closed zu gestalten. Ein Signierer, der einen Schlüssel exportieren oder stillschweigend auf einen schwächeren Algorithmus zurückfallen könnte, würde die Zusicherung zunichtemachen, für die ein HSM existiert. Daher bittet der Signierer das Token, die Signatur an Ort und Stelle zu berechnen, und der FIPS-Modus-Guard weist jeden Hash, jede OID oder jede Schlüsselstärke außerhalb des zugelassenen Presets zurück, bevor die Operation läuft. Der Power-on-Self-Test überträgt dieselbe Haltung auf den Start: Ein nicht verifiziertes Modul verweigert den Dienst, statt auf ungetesteten Primitiven zu signieren. Das Ergebnis ist eine Grenze, über die Sie nachvollziehbar argumentieren können und in der die Schlüsselverwahrung dem Betreiber und dem Token gehört, nicht dieser Software.

Design-Hintergrund: HSM-gestütztes Signieren.

API-Oberfläche

Öffentliche Oberfläche	Typ	Zweck	Stabilität	Seit
PKCS#11-Token-Signierer	Klasse (implementiert das Core-`HsmSignerInterface`)	Mit einem PKCS#11-Token signieren; der Schlüssel bleibt auf dem Token	stable	1.0.0
FIPS-Krypto-Policy	Klasse (implementiert das Core-`CryptoPolicyInterface`)	Ein Preset für zulässige Algorithmen und Schlüsselstärke	stable	1.9.0
FIPS-Modus-Guard	Klasse	Prüft, ob ein Hash, eine Signatur-OID, ein Verschlüsselungsalgorithmus oder eine Schlüsselstärke zulässig ist	stable	1.9.0
FIPS-Boot-Guard	Klasse	Den Power-on-Self-Test ausführen und cachen; prüfen, dass das Modul betriebsbereit ist	stable	3.2.0
OpenSSL-CLI-/Engine-Signierer	Klasse (implementiert `HsmSignerInterface`)	Über eine OpenSSL-Engine oder die OpenSSL-CLI für engine-gestützte Token signieren	stable	1.0.0

Der Konstruktor des Token-Signierers nimmt den PKCS#11-Bibliothekspfad, die Slot-Nummer, die Token-PIN, das Zertifikats-Label und ein optionales separates Key-Label entgegen. Der PIN-Parameter ist als sensibel markiert; er wird nicht protokolliert und nicht serialisiert. Der Signierer stellt außerdem das Signiererzertifikat und die Zertifikatskette in DER-Form bereit. Der maßgebliche Parameter- und Typvertrag ist die veröffentlichte API-Referenz für das Paket nextpdf/enterprise; behandeln Sie diese Referenz — nicht diese Seite — als den Vertrag.

Codebeispiel — Schnellstart

composer require nextpdf/core
composer require nextpdf/enterprise:^3

use NextPDF\Enterprise\Security\Fips\FipsCryptoPolicy;
use NextPDF\Enterprise\Security\Fips\FipsModeGuard;

$guard = new FipsModeGuard(FipsCryptoPolicy::strict());

// Throws a typed FIPS violation if the algorithm is not approved.
$guard->assertHashAllowed('sha256');
$guard->assertKeyStrengthAllowed('rsa', 2048);

Codebeispiel — Produktion

use NextPDF\Enterprise\Security\Fips\FipsBootGuard;
use NextPDF\Enterprise\Security\Fips\FipsSelfTest;

// At application bootstrap (one self-test cycle per worker process):
$bootGuard = new FipsBootGuard(new FipsSelfTest());
$bootGuard->assertOperational(); // throws on a known-answer-test failure
$container->set(FipsBootGuard::class, $bootGuard);

// The PKCS#11 token signer is only available when ext-pkcs11 is loaded.
// Check availability before you construct the signer. The PIN is a secret;
// supply it from your secret manager, never from source or logs.

Die vollständige Konstruktor-Argumentliste, die Exception-Typen und die Konstruktion des PKCS#11-Token-Signierers sind in der Enterprise-Security-Tiefenreferenz dokumentiert.

Sonderfälle & Fallstricke

Der Konstruktor des PKCS#11-Token-Signierers löst eine typisierte Operations-Exception aus, wenn ext-pkcs11 nicht geladen ist. Prüfen Sie zuerst die Verfügbarkeit.
Der Token-Signierer cacht ein PKCS#11-Modul pro Bibliothekspfad pro Prozess. Dies erfüllt die Regel „einmal pro Modul initialisieren“ der Token-Schnittstelle.
ECDSA-Token-Mechanismen geben eine Roh-Signatur zurück. Der Signierer wandelt sie für die PDF- und OpenSSL-Interoperabilität in die DER-codierte Form um.
Der FIPS-Guard verweigert standardmäßig einen unbekannten Schlüsseltyp. Ein nicht erkannter Schlüsseltyp wird nicht stillschweigend akzeptiert.
Der Post-Quantum-Signierpfad ist experimentell, Opt-in und standardmäßig deaktiviert. Standard-PAdES-Langzeitarchivierungsprofile erkennen Post-Quantum-Suiten noch nicht an. Aktivieren Sie ihn nicht für produktive AdES-Signaturen.

Performance

Die FIPS-Guard-Prüfungen sind Konstant-Zeit-Hash-Map-Lookups. Der Power-on-Self-Test läuft einmal pro Prozess; seine Kosten werden über die Prozesslebensdauer amortisiert, nicht pro Signieraufruf. Eine PKCS#11-Signieroperation fügt einen Roundtrip zum Token hinzu. Ein netzwerkgebundenes HSM fügt die Netzwerklatenz dieses Roundtrips hinzu.

Sicherheitshinweise

Der Signierpfad ist fail-closed. Ein Primitiv-Fehler oder eine Policy-Lücke löst eine typisierte Exception aus. Der Pfad stuft niemals stillschweigend auf einen schwächeren Algorithmus herab.
Der Token-PIN-Parameter ist als sensibel markiert. Er wird nicht protokolliert und nicht serialisiert.
Der private Schlüssel für ein PKCS#11-Token bleibt auf dem Token. Die Signieroperation läuft innerhalb der Token-Grenze.
Der Power-on-Self-Test versetzt den Enterprise-FIPS-Guard bei einem Known-Answer-Test-Mismatch in einen Fehlerzustand und verweigert kryptografische Dienste bis zum Reset.
Die Verwendung von AES-GCM erfordert einen pro Schlüssel eindeutigen Initialisierungsvektor, gemäß NIST SP 800-38D §5.

Datenresidenz & PII-Minderungen

Der Signier- und FIPS-Policy-Code läuft in-process. Für die FIPS-Policy-Prüfung oder den Power-on-Self-Test verlässt kein Dokumentinhalt den Host. Ein PKCS#11-Token empfängt die zu signierenden Daten, nicht unzusammenhängenden Dokumentinhalt. Ein netzwerkgebundenes HSM empfängt diese Daten über den von Ihnen konfigurierten Netzwerkkanal. Das Schlüsselmaterial bleibt innerhalb der Token- oder HSM-Grenze.

Sichere Telemetrie & Log-Bereinigung

Die Token-PIN ist ein sensibler Konstruktorparameter und wird von Logs und Serialisierung ausgeschlossen. Fügen Sie die PIN, das Token-Label oder Schlüsselmaterial nicht zu Ihren eigenen Anwendungslogs hinzu. Behandeln Sie alle Token-Anmeldedaten als Secrets in Ihrer Logging- und Tracing-Richtlinie.

Bedrohungsmodell

Dies ist eine kryptografische Grenze, daher ist das Bedrohungsmodell explizit. Die zu signierenden Daten werden dem Token übergeben; das Token hält den Schlüssel. Ein Token- oder HSM-Fehler löst eine typisierte Exception aus; der Signierer erzeugt kein unsigniertes oder teilweise signiertes Ergebnis. Der Schlüsselschutz hängt vom Token oder HSM, vom Deployment und vom Betreiber ab — nicht von dieser Software allein. Siehe die Deployment-Grenze.

Konformität

Das Power-on- und bedingte Self-Test-Modell ist an ISO/IEC 19790:2025 §7.10 und §7.10.3 ausgerichtet.
Die minimale RSA-Signaturschlüssellänge ist an NIST SP 800-131A Rev.2 §3 ausgerichtet.
Die zugelassene ECDSA-Kurven- und Hash-Paarung ist an FIPS 186-5 §6.1.1 ausgerichtet.
Die PKCS#11-Token-Signieroperation und der Session-Login sind an PKCS#11 v3.1 §5 ausgerichtet.
Die Verantwortung für den Schlüsselschutz ist an NIST SP 800-57 Part 1 Rev.5 §5.5.2 ausgerichtet.
Die Eindeutigkeit des AES-GCM-Initialisierungsvektors ist an NIST SP 800-38D §5 ausgerichtet.

Jede normative Quelle ist paraphrasiert. Auf dieser Seite wird kein normativer Text wiedergegeben. Diese Seite betrifft kryptografisches Signieren.

FIPS-Modus-Verhalten

Die FIPS-Modus-Policy schränkt kryptografische Wahlmöglichkeiten auf die oben beschriebene zugelassene Menge ein. Bei Konfiguration gegen einen FIPS-validierten OpenSSL-Provider läuft das zugrunde liegende Primitiv in dieser validierten Grenze. NextPDF Enterprise selbst führt strukturellen Zusammenbau, Digest-Berechnung und Policy-Durchsetzung aus.

NextPDF Enterprise ist kein FIPS-validiertes kryptografisches Modul und erhebt keinen FIPS-Zertifizierungsanspruch. NextPDF Enterprise arbeitet nur dann in einem FIPS-kompatiblen Modus, wenn es mit einem FIPS-validierten kryptografischen Provider — zum Beispiel einem FIPS-validierten OpenSSL-Provider — oder einem FIPS-validierten HSM konfiguriert ist. Die FIPS-Modus-Policy unterstützt die Compliance; sie ist keine Zertifizierung.

Editions-Grenze

NextPDF Core liefert den Software-Signierer, den RFC 3161-Zeitstempel-Konsum, die RFC 5280-Pfadvalidierung sowie die OCSP- und CRL-Sperrprüfung. Core erzeugt die PAdES-Stufen B-B und B-T. NextPDF Pro ergänzt Maskierung, Textlayer-PII-Erkennung, mehrparteiges sequenzielles Signieren sowie Remote- und Cloud-KMS-Signierstrategien (AWS KMS, GCP Cloud KMS, Azure Key Vault). NextPDF Pro stellt keinen PKCS#11-Hardware-Token-Pfad bereit und stellt kein FIPS-Modus-Kryptorichtlinienprofil bereit. Der PKCS#11-Hardware-Token-Signierer, das FIPS-Modus-Kryptorichtlinienprofil, der Power-on-Self-Test-Guard und der PAdES-B-LT-und-B-LTA-Erzeuger werden ausschließlich im Paket nextpdf/enterprise ausgeliefert. Ein Deployment ohne die Enterprise-Berechtigung lädt die Enterprise-Klassen nicht.

Pro-Fallback

In einem Pro-only-Deployment ist der unterstützte hardware- und cloud-gestützte Signierpfad die Pro-Cloud-KMS-Strategie: Ein Cloud-KMS oder HSM-gestütztes KMS hält den Schlüssel, und Pro sendet den Digest der signierten Attribute, nicht das Dokument, an den Provider. Pro stellt KMS-Integration bereit, nicht die Enterprise-PKCS#11-Token-Factory oder das FIPS-Modus-Profil. Eine Konfiguration, die B-LT, B-LTA, ein PKCS#11-Token oder das FIPS-Modus-Profil in einem Pro-only-Deployment anfordert, scheitert fail-closed mit einer Meldung, die die fehlende Enterprise-Komponente benennt. Siehe Security — NextPDF Pro zur Pro-Signier-Oberfläche.

Core-Fallback

In einem Core-only-Deployment erzeugt der Software-Signierer PAdES B-B und B-T mit einem lokalen Schlüssel oder einem über den Core-Signierstrategie-Vertrag bereitgestellten Schlüssel. Core hat keinen Hardware-Token-Pfad und kein FIPS-Modus-Profil. Siehe Security — NextPDF Core.

Hinweis zur Enterprise-Grenze

Die PKCS#11-Token-Integration, ihr Mechanismus-Mapping und ihre Session-Behandlung werden ausschließlich auf Verhaltensebene beschrieben. Die interne Mechanismus-Mapping-Tabelle, die interne Session-Wiederherstellungslogik und das Post-Quantum-Migrationsmaterial liegen außerhalb des Umfangs der öffentlichen Oberfläche und werden hier nicht wiedergegeben.

Deployment-Grenze

NextPDF Enterprise integriert sich mit einem PKCS#11-Token, einem HSM oder einem KMS. Es speichert, erzeugt oder garantiert die Sicherheit des Signierschlüssels nicht selbst. Die Schlüsselsicherheit hängt vom Token, HSM oder KMS, vom Deployment und vom Betreiber ab — nicht von NextPDF Enterprise allein. Der Betreiber ist verantwortlich für die Token-Bereitstellung, die PIN-Behandlung, die Slot-Konfiguration, den Netzwerkschutz eines netzwerkgebundenen HSM und die Vertrauenskonfiguration. Die Verantwortung für den Schlüsselschutz folgt NIST SP 800-57 Part 1 Rev.5 §5.5.2. NextPDF Enterprise legt in dieser Dokumentation keine Token-PIN-Behandlung, keine Slot-Konfigurationsinterna und kein Anbieter-Anmeldedatenmaterial offen.

Grenze der rechtlichen Compliance

Sie betrifft kryptografisches Signieren und die Integration von Hardware-Sicherheitsmodulen. Die FIPS-Modus-Policy ist eine Compliance-Unterstützungsfunktion. Sie ist kein Rechtsgutachten und keine Zertifizierung. Konsultieren Sie Ihre eigenen Compliance- und Rechtsberater zu Ihren regulatorischen Pflichten.

Publikationsgrenze

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

Verhaltensvertrag

Der FIPS-Guard prüft jeden Hash, jede Signatur-OID, jeden Verschlüsselungsalgorithmus und jede Schlüsselstärke gegen das aktive Preset und löst bei einer unzulässigen Wahl eine typisierte Verletzung aus.
Der Power-on-Self-Test läuft einmal pro Prozess und verweigert kryptografische Dienste bei einem Known-Answer-Test-Fehler bis zum Reset.
Der PKCS#11-Token-Signierer erfordert ext-pkcs11; er löst eine typisierte Operations-Exception aus, wenn die Erweiterung fehlt.
Der Signierpfad ist fail-closed und substituiert niemals einen schwächeren Algorithmus.

Siehe auch

Security — NextPDF Enterprise (Tiefenreferenz)
Security — NextPDF Pro
Signature — NextPDF Enterprise
Accelerator — NextPDF Enterprise
Security — NextPDF Core
PAdES · HSM · PKCS#11 · FIPS mode · KMS — Glossarbegriffe.