Enterprise édition

Sécurité — HSM, PKCS#11 et mode FIPS

En bref

NextPDF Enterprise ajoute un chemin de signature par jeton matériel PKCS#11 et une politique cryptographique en mode FIPS au-dessus de la surface de sécurité de Core et Pro. Cette page énonce le comportement, les frontières et la posture explicite de certification FIPS et de garde des clés.

Disponibilité & licence

Cette fonctionnalité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement sans ce droit ne charge pas les classes de la fonctionnalité. Comparer les éditions et obtenir une licence.

Vue d’ensemble conceptuelle

La surface de sécurité Enterprise comporte trois parties : un signataire par jeton matériel, une politique cryptographique en mode FIPS et un garde-fou d’auto-test au démarrage.

Le signataire par jeton matériel adapte un jeton PKCS#11 — une carte à puce, un dispositif USB ou un HSM connecté au réseau. Le signataire localise le certificat et la clé privée sur le jeton par étiquette (label). Il demande ensuite au jeton de calculer la signature. La clé privée ne quitte pas la frontière du jeton ; l’opération s’exécute à l’intérieur du jeton. L’opération de signature du jeton, la session et la connexion utilisateur suivent PKCS#11 v3.1 §5. Le chemin HSM nécessite l’extension PHP ext-pkcs11. Cette extension ne fait pas partie de PHP standard. Installe-la séparément. Utilise la vérification de disponibilité avant de construire le signataire.

La politique cryptographique en mode FIPS restreint les choix cryptographiques à un ensemble approuvé. Elle comporte deux préréglages. Le préréglage strict autorise les empreintes SHA-256, SHA-384 et SHA-512 ; les OID de signature RSA et ECDSA avec ces empreintes ; le chiffrement AES-256-CBC ; et des tailles de clé minimales de RSA 2048 et EC 256. Le préréglage standard est identique mais autorise aussi AES-128-CBC pour l’interopérabilité avec d’anciens systèmes. Un garde-fou à l’exécution enveloppe la politique. Le garde-fou vérifie chaque empreinte, OID de signature, algorithme de chiffrement et force de clé avant l’exécution de l’opération. Un choix interdit lève une violation typée et arrête l’opération. Le chemin est en échec sûr (fail-closed) : la politique ne se relâche jamais et ne substitue jamais un algorithme plus faible. La longueur minimale de clé RSA suit NIST SP 800-131A Rev.2 §3. L’appariement courbe et empreinte ECDSA suit FIPS 186-5 §6.1.1.

Le garde-fou d’auto-test au démarrage exécute une batterie de tests à réponse connue (known-answer-test) une fois au démarrage du processus. La batterie couvre les fonctions approuvées d’empreinte, de MAC, de chiffrement, de signature et de génération de bits aléatoires. Si un test échoue, le garde-fou FIPS Enterprise entre dans un état d’erreur et refuse les services cryptographiques jusqu’à réinitialisation. Le résultat est mis en cache pour la durée de vie du processus ; une réexécution à la demande est disponible. La catégorie d’auto-test et le déclencheur de test conditionnel suivent ISO/IEC 19790:2025 §7.10 et §7.10.3.

Pourquoi ça fonctionne ainsi

La décision porteuse est de garder la clé privée à l’intérieur de la frontière du jeton et de rendre la politique cryptographique en échec sûr. Un signataire qui pourrait exporter une clé, ou se rabattre silencieusement sur un algorithme plus faible, anéantirait l’assurance qu’un HSM existe pour fournir. Le signataire demande donc au jeton de calculer la signature sur place, et le garde-fou en mode FIPS rejette toute empreinte, OID ou force de clé en dehors du préréglage approuvé avant l’exécution de l’opération. L’auto-test au démarrage étend la même posture au lancement : un module non vérifié refuse le service plutôt que de signer avec des primitives non testées. Le résultat est une frontière sur laquelle tu peux raisonner, où la garde des clés est détenue par l’opérateur et le jeton, et non par ce logiciel.

Contexte de conception : Signature adossée à un HSM.

Surface d’API

Surface publique	Type	Objet	Stabilité	Depuis
Signataire par jeton PKCS#11	classe (implémente l’interface `HsmSignerInterface` du Core)	Signer avec un jeton PKCS#11 ; la clé reste sur le jeton	stable	1.0.0
Politique cryptographique FIPS	classe (implémente l’interface `CryptoPolicyInterface` du Core)	Un préréglage d’algorithmes autorisés et de force de clé	stable	1.9.0
Garde-fou en mode FIPS	classe	Assertit qu’une empreinte, un OID de signature, un algorithme de chiffrement ou une force de clé est autorisé	stable	1.9.0
Garde-fou de démarrage FIPS	classe	Exécute et met en cache l’auto-test au démarrage ; assertit que le module est opérationnel	stable	3.2.0
Signataire OpenSSL CLI / engine	classe (implémente `HsmSignerInterface`)	Signer via un engine OpenSSL ou la CLI OpenSSL pour les jetons adossés à un engine	stable	1.0.0

Le constructeur du signataire par jeton prend le chemin de la bibliothèque PKCS#11, le numéro de slot, le PIN du jeton, l’étiquette du certificat et une étiquette de clé distincte facultative. Le paramètre PIN est marqué sensible ; il n’est ni journalisé ni sérialisé. Le signataire expose également le certificat du signataire et la chaîne de certificats sous forme DER. Le contrat de paramètres et de types faisant autorité est la référence d’API publiée du paquet nextpdf/enterprise ; traite cette référence — et non cette page — comme le contrat.

Exemple de code — Démarrage rapide

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);

Exemple de code — Production

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.

La liste complète des arguments du constructeur, les types d’exception et la construction du signataire par jeton PKCS#11 sont documentés dans la référence approfondie de sécurité Enterprise.

Cas limites & pièges

Le constructeur du signataire par jeton PKCS#11 lève une exception d’opération typée lorsque ext-pkcs11 n’est pas chargée. Vérifie d’abord la disponibilité.
Le signataire par jeton met en cache un module PKCS#11 par chemin de bibliothèque par processus. Cela satisfait la règle « initialiser une fois par module » de l’interface du jeton.
Les mécanismes ECDSA des jetons renvoient une signature brute. Le signataire la convertit vers la forme encodée en DER pour l’interopérabilité avec le PDF et OpenSSL.
Le garde-fou FIPS refuse un type de clé inconnu par défaut. Un type de clé non reconnu n’est pas accepté silencieusement.
Le chemin de signature post-quantique est expérimental, en opt-in et désactivé par défaut. Les profils d’archivage à long terme PAdES standard ne reconnaissent pas encore les suites post-quantiques. Ne l’active pas pour des signatures AdES de production.

Performance

Les vérifications du garde-fou FIPS sont des recherches en table de hachage en temps constant. L’auto-test au démarrage s’exécute une fois par processus ; son coût est amorti sur la durée de vie du processus, et non par appel de signature. Une opération de signature PKCS#11 ajoute un aller-retour vers le jeton. Un HSM connecté au réseau ajoute la latence réseau de cet aller-retour.

Notes de sécurité

Le chemin de signature est en échec sûr (fail-closed). Un échec de primitive ou une lacune de politique lève une exception typée. Le chemin ne se dégrade jamais silencieusement vers un algorithme plus faible.
Le paramètre PIN du jeton est marqué sensible. Il n’est ni journalisé ni sérialisé.
La clé privée d’un jeton PKCS#11 reste sur le jeton. L’opération de signature s’exécute à l’intérieur de la frontière du jeton.
L’auto-test au démarrage entre dans un état d’erreur en cas de non-concordance d’un test à réponse connue et refuse les services cryptographiques jusqu’à réinitialisation.
L’usage d’AES-GCM exige un vecteur d’initialisation unique par clé, conformément à NIST SP 800-38D §5.

Résidence des données & mesures d’atténuation des PII

Le code de signature et de politique FIPS s’exécute en mémoire (in-process). Aucun contenu de document ne quitte l’hôte pour la vérification de politique FIPS ni l’auto-test au démarrage. Un jeton PKCS#11 reçoit les données à signer, et non un contenu de document sans rapport. Un HSM connecté au réseau reçoit ces données via le canal réseau que tu configures. Le matériel de clé reste à l’intérieur de la frontière du jeton ou du HSM.

Télémétrie sûre & nettoyage des journaux

Le PIN du jeton est un paramètre de constructeur sensible et est exclu des journaux et de la sérialisation. N’ajoute pas le PIN, l’étiquette du jeton ni le matériel de clé à tes propres journaux applicatifs. Traite tous les identifiants de jeton comme des secrets dans ta politique de journalisation et de traçage.

Modèle de menace

C’est une frontière cryptographique, le modèle de menace est donc explicite. Les données à signer sont remises au jeton ; le jeton détient la clé. Une erreur de jeton ou de HSM lève une exception typée ; le signataire ne produit pas de résultat non signé ou partiellement signé. La protection des clés dépend du jeton ou du HSM, du déploiement et de l’opérateur — et non de ce logiciel seul. Voir la frontière de déploiement.

Conformité

Le modèle d’auto-test au démarrage et conditionnel s’aligne sur ISO/IEC 19790:2025 §7.10 et §7.10.3.
La longueur minimale de clé de signature RSA s’aligne sur NIST SP 800-131A Rev.2 §3.
L’appariement approuvé courbe et empreinte ECDSA s’aligne sur FIPS 186-5 §6.1.1.
L’opération de signature du jeton PKCS#11 et la connexion de session s’alignent sur PKCS#11 v3.1 §5.
La responsabilité de protection des clés s’aligne sur NIST SP 800-57 Part 1 Rev.5 §5.5.2.
L’unicité du vecteur d’initialisation d’AES-GCM s’aligne sur NIST SP 800-38D §5.

Chaque source normative est paraphrasée. Aucun texte normatif n’est reproduit sur cette page. Cette page concerne la signature cryptographique.

Comportement en mode FIPS

La politique en mode FIPS restreint les choix cryptographiques à l’ensemble approuvé décrit ci-dessus. Lorsqu’elle est configurée avec un fournisseur OpenSSL validé FIPS, la primitive sous-jacente s’exécute dans cette frontière validée. NextPDF Enterprise lui-même réalise l’assemblage structurel, le calcul d’empreinte et l’application de la politique.

NextPDF Enterprise n’est pas un module cryptographique validé FIPS et ne formule aucune revendication de certification FIPS. NextPDF Enterprise fonctionne en mode compatible FIPS uniquement lorsqu’il est configuré avec un fournisseur cryptographique validé FIPS — par exemple un fournisseur OpenSSL validé FIPS — ou un HSM validé FIPS. La politique en mode FIPS assiste la conformité ; ce n’est pas une certification.

Frontière d’édition

NextPDF Core livre le signataire logiciel, la consommation d’horodatage RFC 3161, la validation de chemin RFC 5280, et la vérification de révocation OCSP et CRL. Le Core produit les niveaux PAdES B-B et B-T. NextPDF Pro ajoute le masquage, la détection de PII dans la couche de texte, la signature séquentielle multipartite, et les stratégies de signature distantes et cloud-KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault). NextPDF Pro ne fournit pas de chemin par jeton matériel PKCS#11 et ne fournit pas de profil de politique cryptographique en mode FIPS. Le signataire par jeton matériel PKCS#11, le profil de politique cryptographique en mode FIPS, le garde-fou d’auto-test au démarrage et le producteur PAdES B-LT et B-LTA sont livrés uniquement dans le paquet nextpdf/enterprise. Un déploiement sans le droit Enterprise ne charge pas les classes Enterprise.

Repli sur Pro

Dans un déploiement Pro uniquement, le chemin de signature adossé au matériel et au cloud pris en charge est la stratégie cloud-KMS de Pro : un KMS cloud ou un KMS adossé à un HSM détient la clé, et Pro envoie l’empreinte des attributs signés, et non le document, au fournisseur. Pro fournit l’intégration KMS, et non la fabrique de jetons PKCS#11 Enterprise ni le profil en mode FIPS. Une configuration qui demande B-LT, B-LTA, un jeton PKCS#11 ou le profil en mode FIPS dans un déploiement Pro uniquement échoue de manière sûre avec un message qui nomme le composant Enterprise manquant. Voir Sécurité — NextPDF Pro pour la surface de signature Pro.

Repli sur le Core

Dans un déploiement Core uniquement, le signataire logiciel produit PAdES B-B et B-T avec une clé locale ou une clé fournie via le contrat de stratégie de signature du Core. Le Core n’a aucun chemin par jeton matériel ni aucun profil en mode FIPS. Voir Sécurité — NextPDF Core.

Note sur la frontière Enterprise

L’intégration par jeton PKCS#11, son mappage de mécanisme et sa gestion de session sont décrits au niveau du comportement uniquement. La table interne de mappage de mécanisme, la logique interne de récupération de session et le matériel de migration post-quantique sont hors du périmètre de la surface publique et ne sont pas reproduits ici.

Frontière de déploiement

NextPDF Enterprise s’intègre à un jeton PKCS#11, à un HSM ou à un KMS. Il ne stocke, ne génère et ne garantit pas lui-même la sécurité de la clé de signature. La sécurité de la clé dépend du jeton, du HSM ou du KMS, du déploiement et de l’opérateur — et non de NextPDF Enterprise seul. L’opérateur est responsable de l’approvisionnement du jeton, de la gestion du PIN, de la configuration du slot, de la protection réseau d’un HSM connecté au réseau et de la configuration de confiance. La responsabilité de protection des clés suit NIST SP 800-57 Part 1 Rev.5 §5.5.2. NextPDF Enterprise n’expose pas la gestion du PIN du jeton, les détails internes de configuration de slot ni le matériel d’identifiants du fournisseur dans cette documentation.

Frontière de conformité légale

Cette page concerne la signature cryptographique et l’intégration de module matériel de sécurité. La politique en mode FIPS est une fonctionnalité d’assistance à la conformité. Ce n’est pas un avis juridique ni une certification. Consulte tes propres conseillers conformité et juridiques pour tes obligations réglementaires.

Frontière de publication

Cette page documente uniquement le comportement observable de l’extérieur et la surface d’API publique prise en charge. Les chemins d’espace de noms internes, les classes utilitaires, les tables de mécanismes, les noms de fichiers de runbook et les préfixes de tickets sont hors périmètre.

Contrat de comportement

Le garde-fou FIPS assertit chaque empreinte, OID de signature, algorithme de chiffrement et force de clé au regard du préréglage actif et lève une violation typée sur un choix interdit.
L’auto-test au démarrage s’exécute une fois par processus et refuse les services cryptographiques en cas d’échec d’un test à réponse connue jusqu’à réinitialisation.
Le signataire par jeton PKCS#11 nécessite ext-pkcs11 ; il lève une exception d’opération typée lorsque l’extension est absente.
Le chemin de signature est en échec sûr (fail-closed) et ne substitue jamais un algorithme plus faible.

Voir aussi

Sécurité — NextPDF Enterprise (référence approfondie)
Sécurité — NextPDF Pro
Signature — NextPDF Enterprise
Accélérateur — NextPDF Enterprise
Sécurité — NextPDF Core
PAdES · HSM · PKCS#11 · FIPS mode · KMS — termes du glossaire.