HSM-gestütztes Signieren

Spec: ISO 32000-2, §12.8 Spec: FIPS 140-3 Evidence: Standard-backed

Auf einen Blick

Ein Hardware-Sicherheitsmodul (HSM) verlagert den Signaturschlüssel aus Ihrem Prozess in ein Gerät, das auf Anforderung signiert, den Schlüssel aber niemals herausgibt. Diese Seite erklärt die PKCS#11-Nahtstelle, über die NextPDF signiert, wo die Schlüsselgrenze genau verläuft und welche Teile des Ergebnisses in die Verantwortung der Engine fallen und nicht in die des Geräts oder in Ihre eigene.

Warum das wichtig ist

Ein Signaturschlüssel im Prozessspeicher kann von allem gelesen werden, was den Prozess auslesen kann: von einem Heap-Dump, einem Debugger, einem Logging-Fehler oder einer Abhängigkeit mit einer Schwachstelle. Sobald ein privater Schlüssel kopiert wurde, ist jede jemals damit erstellte Signatur infrage gestellt, und Sie können dieses Leck nicht rückgängig machen. Der Sinn eines HSM ist, dass es keine Kopie gibt, die entwendet werden könnte.

Eine falsch gezogene Grenze wird teuer, ohne dass es sofort auffällt. Ein Workflow, der aussieht, als sei er hardwaregestützt, den Schlüssel zum Signieren aber in den Speicher holt, hat die Betriebskosten eines HSM und das Risikoprofil eines Software-Schlüssels. Der Unterschied ist im fertigen PDF nicht sichtbar, deshalb muss er von vornherein eingeplant und überprüft werden, nicht vorausgesetzt.

Die Kurzfassung

Der PKCS#11-Standard definiert ein Schlüsselobjekt, das als sensibel und nicht extrahierbar gekennzeichnet ist. Sein privater Wert kann außerhalb des Tokens nicht im Klartext offengelegt werden. Spec: PKCS#11, v3.1 §10.9
NextPDF erstellt die PDF-Signaturstruktur und den CMS-Container. Es übergibt die zu signierenden Bytes über die PKCS#11-Nahtstelle und erhält die Signatur zurück. Der Schlüssel überschreitet diese Nahtstelle nie.
Die Nahtstelle ist ein stabiler Vertrag. Derselbe Vertrag wird von einem Smartcard-Token, einem USB-HSM, einem Netzwerk-HSM und einem Cloud-KMS erfüllt. Der Engine-Code bleibt dabei unverändert.
NextPDF ist Signatur-Engine-Software. Die Hardware-Sicherheitszusage des Geräts, sein Validierungsstatus, die PIN-Richtlinie und die Bereitstellung sind keine Dinge, die die Engine zertifiziert. Sie nutzt das Gerät; sie bürgt nicht dafür.

Wie NextPDF damit umgeht

Die Nahtstelle, genau betrachtet

NextPDF trennt das Zusammensetzen einer Signatur vom Berechnen des Signaturwerts. Das Zusammensetzen ist Aufgabe der Engine: das Signaturfeld platzieren, Platz in der Datei reservieren, den Byte-Bereich berechnen und das CMS-SignedData samt seinen signierten Attributen aufbauen. Spec: ISO 32000-2, §12.8

Das Berechnen des Signaturwerts wird delegiert. Die Engine definiert dafür einen kleinen Vertrag für den Signaturanbieter: Er erhält eine opake Bytefolge (in der Praxis die DER-codierten signierten Attribute) und gibt die rohen Signaturoktette zurück. Dieser Vertrag ist die Nahtstelle. Auf der einen Seite steht das Wissen über PDF und CMS; auf der anderen Seite ein Schlüssel. Ein Anbieter kann diesen Schlüssel als lokalen Software-Schlüssel im Prozess halten, in einem Cloud-KMS verwalten oder über PKCS#11 auf einem Hardware-Token nutzen. Der Engine-Code oberhalb der Nahtstelle ist in jedem Fall identisch. Nur der dahinterliegende Anbieter unterscheidet sich.

Wo die Grenze tatsächlich verläuft

PKCS#11 — das OASIS Cryptographic Token Interface, historisch „Cryptoki“ — ist die standardisierte C-Schnittstelle zu Hardware-Tokens. Der Hardware-Pfad von NextPDF spricht PKCS#11 (direkt oder über eine OpenSSL-Kommandozeilenbrücke für Engine- oder Provider-Bereitstellungen, bei denen die In-Process-Anbindung kein Token laden kann).

Das Schlüsselobjekt auf dem Token wird mit zwei Attributen erstellt, die die Grenze definieren. Wenn der Schlüssel als sensibel oder als nicht extrahierbar gekennzeichnet ist, können bestimmte private Attribute außerhalb des Tokens nicht im Klartext offengelegt werden. Spec: PKCS#11, v3.1 §10.9 Der Signaturvorgang selbst ist eine einzelne Token-Operation — C_SignInit dann C_Sign —, die vom Gerät ausgeführt wird. Spec: PKCS#11, v3.1 §5.10 Der Klartext, der bei NextPDF ankommt, sind die zu signierenden Bytes. Zurückgegeben werden die Signatur und das Zertifikat. Der private Schlüssel befindet sich auf keinem der beiden Wege. Das ist die Grenze, und durchgesetzt wird sie vom Token, nicht von der Bibliothek.

Step 1 of 4: ISO 32000-2 §12.8 — signature dictionary, ByteRange, Contents
Step 2 of 4: RFC 5652 CMS SignedData — the signature container
Step 4 of 4: FIPS 140-3 / ISO/IEC 19790 cryptographic module assurance (device-level, deployment-dependent)

Worauf eine hardwaregestützte PDF-Signatur fußt, der Reihe nach: der PDF-Träger (ISO 32000-2 §12.8), der darin enthaltene CMS-Container, die Token-Schnittstelle, über die NextPDF signiert (PKCS#11), und die Standards zur Modul-Sicherheitszusage, die das dahinterliegende Gerät beschreiben — es aber nicht von sich aus garantieren.

PIN und erneute Authentifizierung

PKCS#11 erlaubt, dass ein Schlüssel bei jeder Verwendung eine erneute Authentifizierung verlangt: Wenn das CKA_ALWAYS_AUTHENTICATE-Attribut gesetzt ist, muss der Benutzer die PIN für jeden kryptografischen Vorgang erneut eingeben, nicht nur einmal pro Sitzung. Spec: PKCS#11, v3.1 §10.9 Der PKCS#11-Pfad von NextPDF ist genau dafür geschrieben. Die PIN ist ein sensibler Parameter. Sie wird nicht protokolliert oder serialisiert. Wenn eine Sitzung eine bestehende Anmeldung meldet, setzt NextPDF diese zurück in einen sauberen Zustand, damit für die nächste Signatur eine frische PIN-Prüfung erfolgt. Das ist wichtig für Tokens im PIV-Stil, deren Richtlinie eine PIN pro Signatur verlangt. Es ist Engine-Verhalten, das die Richtlinie des Geräts respektiert; es lockert sie nicht.

Was die Belege sagen

Evidence: Standard-backed Die Eigenschaft, dass ein Schlüssel nicht extrahierbar ist, ist keine Behauptung von NextPDF. Sie folgt dem PKCS#11-Modell: ein Schlüsselobjekt, dessen CKA_SENSITIVE wahr oder CKA_EXTRACTABLE falsch ist, gibt seinen privaten Wert außerhalb des Tokens nicht im Klartext preis. Spec: PKCS#11, v3.1 §10.9 Der Beitrag von NextPDF besteht darin, diesen Wert nie zu benötigen: Es signiert über die C_Sign-Operation des Tokens, statt nach Schlüsselmaterial zu fragen.

Evidence: Standard-backed Die PDF-Seite ist in Spec: ISO 32000-2, §12.8 verankert. Der Byte-Bereichs-Digest wird über die Datei berechnet, mit Ausnahme des Signaturwerts. Der Signaturwert, der im Contents-Eintrag abgelegt wird, ist ein DER-codiertes CMS-SignedData-Objekt für Public-Key-Signaturen. Das HSM erzeugt nur die innersten Signaturoktette. NextPDF baut alles um diese herum auf und schreibt sie in die Struktur, die der Standard definiert.

Evidence: Standard-backed Die Sicherheitszusage des Geräts wird durch Spec: FIPS 140-3 und seinen Basisstandard ISO/IEC 19790 beschrieben, die vier aufeinander aufbauende qualitative Sicherheitsstufen über elf Anforderungsbereiche definieren — von der Algorithmusspezifikation bis zur physischen Manipulationssicherheit. Diese Standards beschreiben, was ein Modul erfüllen muss, um eine Stufe zu beanspruchen. Sie sind eine Eigenschaft des Geräts und seiner Validierung, nicht von NextPDF, und — in den Worten von ISO/IEC 19790 selbst — ist Konformität für sich allein nicht hinreichend, um sicherzustellen, dass ein Modul in einer gegebenen Bereitstellung sicher ist.

Praktisches Beispiel

Die folgende Form ist veranschaulichend. Sie zeigt die Nahtstelle, keine Bereitstellung zum Kopieren und Einfügen. Entscheidend ist, dass der Engine ein Signierer übergeben wird und sie nie einen Schlüssel sieht: Das sign() des Signierers ist ein Aufruf an das Gerät.

<?php

declare(strict_types=1);

use NextPDF\Contracts\HsmSignerInterface;

/**
 * Sign a PDF where the private key lives on a PKCS#11 token.
 *
 * `$hsm` is a hardware-backed signer. Its sign() delegates to the token;
 * the key never enters this process. Everything that makes the bytes a
 * valid PDF signature — field, byte range, CMS SignedData — is built by
 * the engine around the value the device returns.
 *
 * Token wiring (library path, slot, PIN, key label) is deployment
 * configuration and is intentionally out of scope here: those values are
 * operator-owned secrets, not library inputs to hardcode.
 */
function signWithToken(
    string $pdfPath,
    HsmSignerInterface $hsm,
): string {
    // The engine asks the signer only for: the certificate (to embed in
    // the CMS) and a signature over the bytes it computes. It never asks
    // for, and the contract never exposes, the private key.
    $certificateDer = $hsm->getCertificateDer();
    $chainDer       = $hsm->getCertificateChainDer();

    // Pseudocode for the engine's own assembly step: build the signature
    // dictionary + CMS SignedData, then hand the signed-attributes bytes
    // to $hsm->sign(...) and place the returned octets in /Contents.
    return nextpdf_sign_pdf(
        pdfPath: $pdfPath,
        signer: $hsm,
        certificateDer: $certificateDer,
        chainDer: $chainDer,
    );
}

Zu dieser Form gehören zwei ehrliche Anmerkungen. Die In-Process-PKCS#11-Anbindung ist eine separate PHP-Erweiterung, die Standard-PHP-Builds nicht enthalten. Eine Hardware-Bereitstellung installiert und überprüft sie (oder nutzt die OpenSSL-Kommandozeilenbrücke) als Teil der Plattform und nicht erst im Nachhinein. Und der Algorithmus, den das Gerät ausführen soll, muss einer sein, den der Schlüssel tatsächlich ausführen kann. Die Engine verweigert frühzeitig, wenn der konfigurierte Algorithmus keine Zuordnung für den gewählten Anbieter hat, statt erst tief in einem Token-Aufruf fehlzuschlagen.

Häufiges Missverständnis

„Ein HSM zu verwenden bedeutet, dass die Signatur FIPS-validiert ist.“

Das tut sie nicht, und die beiden zu verwechseln ist die Falle. Ein HSM ist der Ort, an dem der Schlüssel liegt und die Operation ausgeführt wird. Eine FIPS 140-3- / ISO/IEC 19790-Validierung ist eine Eigenschaft, die das Gerät (oder eine bestimmte Modulkonfiguration) besitzen kann und die durch ein Validierungsprogramm festgestellt wird — nichts, was eine aufrufende Bibliothek verleiht, und nichts, was NextPDF stellvertretend für ein Gerät behauptet. NextPDF ist kompatibel mit dem Signieren über ein PKCS#11-Gerät, und sein Signaturpfad wurde getestet mit kategorietypischen Tokens. Ob eine bestimmte Bereitstellung auf FIPS-Modulebene validiert ist, hängt vollständig von der Hardware, ihrem Zertifikat und davon ab, wie sie konfiguriert und betrieben wird. Verwenden Sie das genaue Wort für das, was Sie tatsächlich haben.

Grenzen und Abgrenzungen

Diese Seite beschreibt die Nahtstelle und die Standards, auf denen sie ruht. Sie ist keine Bereitstellungsgarantie, und es lohnt sich, die Trennlinie klar zu benennen:

Verantwortung der Engine. Das Signaturfeld aufbauen, Platz reservieren, den Byte-Bereich berechnen, CMS-SignedData zusammensetzen, den Signaturanbieter aufrufen und eine strukturell korrekte Signatur gemäß Spec: ISO 32000-2, §12.8 schreiben. Der Hardware-Pfad von NextPDF ist konform zur PKCS#11-Signaturschnittstelle für diesen Zweck.
Verantwortung von Gerät und Betreiber. Die Manipulationssicherheit der Hardware, ihr FIPS 140-3- / ISO/IEC 19790-Validierungsstatus, Schlüsselerzeugung und -verwahrung, PIN-Richtlinie, Slot-Konfiguration, Firmware und physische Sicherheit. Nichts davon zertifiziert die Engine.
Getestet-mit ist nicht zertifiziert. Dass NextPDF einen verifizierten Pfad gegen repräsentative Token-Kategorien hat — Smartcard-, USB-, Netzwerk- und Cloud-KMS-Formen, erreicht über denselben PKCS#11-Vertrag —, ist eine Kompatibilitätsaussage. Es ist keine Zertifizierung, keine Angabe über die Anzahl validierter Module und keine Aussage über Ihr konkretes Gerät. Die Hardware-Kategorien unten sind Integrations-Formen über eine standardisierte Schnittstelle. Behandeln Sie sie als „wo die Nahtstelle erprobt wurde“, niemals als Garantie für ein Gerätemodell, das Sie nicht selbst getestet haben.
Post-Quantum-Signatur ist experimentell. Wo die Engine Post-Quantum-Signatur über ein Token bereitstellt, ist sie optional, abgesichert und gegen Mocks statt gegen Post-Quantum-HSM-Firmware validiert. Die Kataloge kryptografischer Suiten von PAdES und AdES erkennen diese Suiten für die Langzeitarchivierung noch nicht an. Behandeln Sie sie nicht als produktionsreif.

HSM-backed signing via PKCS#11 — edition availability
Edition	Availability
Core	Nicht in dieser Edition. Der Core stellt die Signatur-Engine und die Signaturanbieter-Nahtstelle bereit, mit einem lokalen Software-Schlüssel-Anbieter.
Pro	Cloud-Schlüsselverwaltung — das Signieren über verwaltete KMS-Schlüssel — ist eine Pro-Fähigkeit, die nur auf Verhaltensebene beschrieben wird.
Enterprise	Verfügbar. Hardware-Token-Signatur über die PKCS#11-Schnittstelle (und eine OpenSSL-Kommandozeilenbrücke für engine/provider-Bereitstellungen) ist eine Enterprise-Fähigkeit. Verfügbarkeit ist eine Fähigkeitsaussage, keine Zertifizierung eines Geräts oder einer Bereitstellung.

Integrationsformen über eine Schnittstelle

Dies sind Formen, gegen die die PKCS#11-Nahtstelle erprobt wurde. Die Spalte ist als „wie die Integration aussieht“ zu lesen, nicht als „eine validierte, zertifizierte oder gezählte Geräteliste“.

Integrationsform	Wie sie erreicht wird	Schlüsselgrenze	Sicherheitszusage ist eine Eigenschaft von
Smartcard- / PIV-Token	PKCS#11-Modul; PIN pro Verwendung üblich	Auf der Karte; nicht extrahierbar	Die Karte und ihr Betreiber
USB-HSM	PKCS#11-Modul	Auf dem Gerät; nicht extrahierbar	Das Gerät und sein Betreiber
Netzwerk- / Appliance-HSM	PKCS#11-Modul für ein Netzwerkgerät	Auf der Appliance; nicht extrahierbar	Die Appliance, ihre Konfiguration, der Betreiber
Cloud-KMS	Anbieter verwalteter Schlüssel (Pro)	Im Cloud-Dienst; nie zurückgegeben	Der Cloud-Anbieter und seine Attestierungen
OpenSSL-Provider-Brücke	PKCS#11 über eine OpenSSL-Brücke	Auf dem Token; nicht extrahierbar	Das Token und sein Betreiber

Mini-FAQ

Gelangt der Schlüssel jemals in den PHP-Prozess? Nein. Bei einem nicht extrahierbaren PKCS#11-Schlüssel kann der private Wert außerhalb des Tokens nicht im Klartext offengelegt werden. NextPDF signiert über die Token-Operation und sieht immer nur die zu signierenden Bytes und die zurückgegebene Signatur.

Sieht eine HSM-gestützte Signatur im PDF anders aus? Nein. Die Signaturstruktur ist dasselbe CMS-SignedData im selben Contents-Eintrag über denselben Byte-Bereich. Das HSM ändert, wo das Signieren stattfindet, nicht die Form auf der Festplatte.

Kann ich FIPS-Konformität beanspruchen, weil ich ein HSM über NextPDF verwendet habe? Nur mit Sorgfalt. NextPDF behauptet nichts über den FIPS-Status eines Geräts. Jede solche Behauptung muss aus der eigenen Validierung des Geräts und der Art seiner Bereitstellung stammen, nicht daraus, dass NextPDF es aufgerufen hat.

Was passiert, wenn die In-Process-PKCS#11-Anbindung nicht verfügbar ist? Die Engine meldet, dass die Hardware-Signatur nicht verfügbar ist, statt stillschweigend auf einen Software-Schlüssel zurückzufallen. Ein Pfad über die OpenSSL-Kommandozeilenbrücke existiert für Bereitstellungen, bei denen die In-Process-Anbindung kein Token laden kann.

Glossar

HSM (Hardware-Sicherheitsmodul) — ein gehärtetes Gerät, das Schlüssel hält und kryptografische Operationen ausführt, sodass das Schlüsselmaterial es nie verlässt.
PKCS#11 — der OASIS-Standard „Cryptographic Token Interface“ (historisch „Cryptoki“); die C-Schnittstelle, über die NextPDF mit Hardware-Tokens kommuniziert.
Nicht extrahierbarer Schlüssel — ein PKCS#11-Schlüsselobjekt, dessen privater Wert außerhalb des Tokens nicht im Klartext offengelegt werden kann (CKA_SENSITIVE wahr oder CKA_EXTRACTABLE falsch).
Die Nahtstelle — die Signaturanbieter-Grenze in NextPDF: opake Bytes hinein, Signaturoktette heraus. Das Wissen über PDF und CMS sitzt darüber; der Schlüssel sitzt dahinter.
CMS SignedData — die Cryptographic-Message-Syntax-Struktur (RFC 5652), die die Signatur und die Zertifikate im PDF trägt.
FIPS 140-3 / ISO/IEC 19790 — Sicherheitsstandards für kryptografische Module, die vier qualitative Stufen definieren; eine Eigenschaft eines Geräts und seiner Validierung, nicht einer aufrufenden Bibliothek.