Enterprise édition

Validation HSM et FIPS

En bref

La signature NextPDF Enterprise se connecte aux modules matériels de sécurité (HSM) via PKCS#11 et exécute la cryptographie avec des modules validés selon les Federal Information Processing Standards (FIPS). La clé privée à l’origine d’une signature reste à l’intérieur d’un matériel certifié, et la cryptographie s’exécute dans un module validé de manière indépendante. Tu obtiens ainsi les deux propriétés d’assurance dont dépendent les workflows de signature réglementés et à forte valeur.

Cette page apporte aux acheteurs preuve et assurance. Elle explique les standards que suit l’intégration de signature, les classes d’appareils avec lesquelles elle fonctionne, la posture d’interopérabilité et les preuves de validation que tu peux demander avant de t’engager. Elle ne décrit pas les détails d’implémentation. Pour l’aperçu de la conformité aux standards, consulte Conformité et validation.

Prise en charge des modules matériels de sécurité

Un module matériel de sécurité est un appareil certifié qui génère et conserve les clés privées, et effectue les opérations cryptographiques à ta place, de sorte que le matériel de clé ne quitte jamais l’appareil. NextPDF Enterprise signe au moyen de ces appareils à l’aide de PKCS#11. PKCS#11 est l’interface de programmation standard largement adoptée, également connue sous le nom de Cryptoki, pour les appareils qui détiennent des informations cryptographiques et exécutent des fonctions cryptographiques. Elle définit aussi la manière dont les clés sont gérées sur un jeton cryptographique, ce qui permet à une seule intégration standard de couvrir une large gamme d’appareils.

Comme l’intégration suit PKCS#11 plutôt qu’une interface propre à un fournisseur, elle fonctionne avec les classes courantes de garde matérielle des clés :

Les HSM réseau et sous forme d’appareil utilisés pour centraliser la garde des clés pour des parcs de services de signature.
Les services HSM cloud qui exposent une interface PKCS#11 aux applications s’exécutant dans un environnement géré.
Les cartes à puce et jetons de signature utilisés lorsqu’un signataire conserve la clé sur un appareil personnel.

La garde matérielle des clés s’associe au profil de signature d’archivage à long terme, si bien qu’une signature provient d’une clé protégée tout en restant vérifiable pendant des années. Consulte Conformité et validation pour les profils de signature et leurs standards.

Cryptographie validée FIPS

Pour les déploiements soumis à des exigences d’assurance cryptographique, NextPDF Enterprise fonctionne avec des modules cryptographiques validés FIPS. FIPS 140-3 est le standard des États-Unis pour les exigences de sécurité des modules cryptographiques. Il remplace FIPS 140-2 et s’aligne sur le standard international ISO/IEC 19790.

La validation est un processus indépendant, et non une simple affirmation du fournisseur. La conformité d’un module aux exigences de sécurité des modules cryptographiques s’établit par des tests accrédités menés selon un ensemble défini d’assertions. L’autorité de validation répertorie les modules validés. Lorsque tu utilises un module validé, la cryptographie à l’origine d’une signature s’exécute à l’intérieur d’un matériel qui a passé ce processus indépendant, plutôt que dans du code non vérifié.

NextPDF Enterprise n’émet pas sa propre validation FIPS ; il fonctionne avec des modules validés afin que ta signature hérite de leur assurance. Le module applicable dépend du matériel ou du service cloud que tu déploies.

Pourquoi ça fonctionne ainsi

L’intégration cible l’interface standard PKCS#11, et non l’API d’un fournisseur. Une seule intégration standard atteint alors les HSM réseau, les services de clés cloud, les cartes à puce et les jetons de signature en tant que classe. NextPDF fonctionne avec des modules validés FIPS plutôt que d’émettre sa propre validation. La validation se rattache à un module cryptographique, et non au logiciel qui l’appelle, si bien qu’hériter de l’assurance d’un module est la position honnête et durable. La garde des clés s’arrête à la frontière de l’appareil, et l’assurance qu’un acheteur confirme est la validation publiée du module auprès de l’autorité de validation. Cela maintient le chemin de signature conforme aux standards et neutre vis-à-vis des fournisseurs, si bien qu’une signature provient d’une clé protégée tout en restant vérifiable de manière indépendante.

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

Interopérabilité et preuves de validation

NextPDF Enterprise est conçu pour interopérer avec du matériel conforme aux standards, et non avec un fournisseur unique. La posture d’interopérabilité est la suivante :

Interface standard. La signature accède au matériel via le standard PKCS#11, de sorte que les appareils dotés d’une interface conforme sont pris en charge en tant que classe.
Modules validés. La cryptographie s’exécute avec des modules validés FIPS dont la validation est établie de manière indépendante.
Signatures fondées sur des standards. Les signatures produites suivent les profils de référence PDF Advanced Electronic Signatures (PAdES), y compris le niveau d’archivage à long terme pour une vérifiabilité durable. Consulte Conformité et validation.

Si tu es acheteur ou auditeur et que tu dois le confirmer avant de t’engager, NextPDF peut fournir des éléments de preuve sur demande, notamment :

Les classes de modules matériels de sécurité sur lesquelles l’intégration de signature est testée, et la posture d’interopérabilité pour ton appareil cible.
Les modules validés FIPS utilisés, et la manière de confirmer leur validation auprès de l’autorité de validation.
Les profils de signature produits, et la manière dont un vérificateur indépendant les valide.

Demander un rapport de validation

Pour demander un rapport de validation ou discuter de tes exigences en matière de matériel et d’assurance avant l’achat, contacte le service commercial via le portail de licences. Indique-nous ton module matériel de sécurité cible ou ton service de clés cloud ainsi que ton niveau d’assurance FIPS. Nous ferons correspondre ton besoin aux classes d’appareils prises en charge et aux preuves de validation disponibles pour celui-ci.

Limite 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’espaces 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.