Sécurité — Référence approfondie

En bref

Voici la référence approfondie de la surface de sécurité de NextPDF Pro : masquage au moment de la génération, détection de PII dans la couche texte, session de signature à distance et par cloud-KMS, signature séquentielle multipartite, chemin d’ingestion CAdES et XAdES, niveau de base PAdES B-B et prise en charge de la signature PAdES B-T (une signature B-B plus un horodatage de signature RFC 3161 sur la valeur de signature). Elle énonce le contrat d’API publique, le comportement observable de l’extérieur et la frontière Enterprise B-LT/B-LTA. Elle se situe au niveau du comportement ; elle ne cite aucun chemin d’implémentation interne.

Disponibilité et licence

Cette capacité est livrée dans NextPDF Pro (nextpdf/pro) et s’active avec une enveloppe de licence de niveau Pro. Un déploiement sans ce droit ne charge pas les classes de la capacité. Compare les éditions et obtiens une licence.

Core fournit le signataire CMS logiciel, le client d’horodatage RFC 3161, la validation de chemin RFC 5280, ainsi que la vérification de révocation OCSP et CRL. Pro ajoute le masquage, la détection de PII, la surface de signature à distance et par cloud-KMS, et la prise en charge de la signature PAdES B-T (il compose la pile RFC 3161 de Core pour ajouter un horodatage de signature) décrits ici. L’indicateur de capacité de cette surface est pro : un déploiement sans droit Pro actif ne charge pas ces classes, le contrat de signature Core continue de fonctionner sans changement, et le code qui dépend du contrat Core ne casse pas lorsque le droit est absent.

Installation

composer require nextpdf/pro:^3

Contrat de comportement

Le moteur de masquage applique une liste de règles ordonnée au texte avant que la page ne soit écrite. Une règle correspond à un motif PCRE et remplace une correspondance selon l’un des trois modes :

• BlackBox — supprime le texte correspondant du flux de contenu et réserve une zone de remplissage. Ce mode supprime les objets texte sous-jacents, comme testé.
• Asterisks — remplace chaque caractère correspondant par un astérisque, en préservant le nombre de caractères.
• FixedLabel — remplace la correspondance entière par une étiquette configurable, [REDACTED] par défaut.

Une règle se construit à partir d’un littéral exact via MaskingRule::exactMatch (le littéral est échappé en regex) ou à partir d’un motif PCRE personnalisé via MaskingRule::regex. MaskingConfig contient la liste de règles ordonnée, un mode par défaut et la couleur de remplissage. MaskingConfig::fromArray analyse une carte de configuration et supprime silencieusement une entrée de règle dépourvue de motif de chaîne exploitable, plutôt que de faire échouer tout l’import.

La surface PII extrait la couche texte du PDF, puis applique des motifs intégrés pour les adresses e-mail, les numéros de téléphone, les numéros de sécurité sociale des États-Unis et les numéros de carte de crédit. Elle renvoie un résultat structuré : un booléen indiquant si une correspondance a été trouvée, un décompte de correspondances, la vue masquée du texte et la liste des types analysés. L’appelant peut restreindre l’analyse à un sous-ensemble des quatre types. La surface n’écrase pas les glyphes rendus de la page ; une page numérisée sans couche texte ne produit aucune correspondance. Traite le résultat comme une détection de motifs dans la couche texte pour les types configurés, et non comme une suppression complète de données personnelles, ni comme une affirmation de conformité réglementaire.

La session de signature est en deux phases. RemoteSigningSession::create ouvre une session. prepare calcule le condensé du document sur les deux régions ByteRange, puis construit les attributs signés CMS. complete appelle la stratégie et incorpore le résultat ; suspend sérialise la session pour qu’un worker puisse la reprendre plus tard avec resume et completeWithRawSignature. La session assemble un CMS SignedData et le stocke encodé en DER dans l’entrée Contents du dictionnaire de signature — ISO 32000-2 §12.8.1. Lorsqu’un certificat X.509 analysable est fourni, la session émet l’ensemble complet d’attributs signés obligatoires PAdES B-B : content-type, message-digest, signing-time, signing-certificate-v2 et un attribut de protection d’algorithme — RFC 5652 §5.3 et RFC 5652 §5. Le vérificateur recalcule le condensé du contenu et le compare à l’attribut message-digest ; la comparaison doit correspondre pour que la signature soit valide — RFC 5652 §5.4.

Lorsque le niveau PAdES configuré est B-T (RemoteSigningConfig::default->withLevel(SignatureLevel::PAdES_B_T), ou via SequentialSigner::withTimestamping) et qu’un fournisseur d’horodatage est branché, la session incorpore en outre exactement un signature-time-stamp RFC 3161 en tant qu’attribut non signé CMS sur le premier SignerInfo. Un signature-time-stamp est un attribut non signé portant un jeton d’horodatage calculé sur la valeur de signature numérique d’un signataire — ETSI EN 319 122-1 §5.3 ; son MessageImprint est le condensé de la valeur du champ signature du SignerInfo, balise ASN.1 et longueur exclues — ETSI EN 319 122-1 §5.3 et RFC 3161 Appendix A (OID id-aa-timeStampToken = 1.2.840.113549.1.9.16.2.14). Comme l’horodatage est un attribut non signé, les attributs signés B-B, le message-digest, la valeur de signature du SignerInfo et le /ByteRange du PDF sont identiques octet par octet à la sortie B-B ; seul le CMS grandit de l’attribut non signé, et l’espace réservé /Contents du B-T est augmenté pour qu’il tienne. Le jeton est demandé au fournisseur d’horodatage configuré (le client RFC 3161 Core par défaut, ou un fournisseur fourni par l’appelant). Sur le chemin du fournisseur par défaut, le condensé de l’empreinte est SHA-256 ; la forme héritée ESSCertID v1 liée à SHA-1 est refusée et ESSCertIDv2 est requis — RFC 5816 §1. Une défaillance de TSA, une requête refusée, un nonce ou un écho de message-imprint erroné, un jeton malformé ou à algorithme non pris en charge, ou un jeton qui échoue à la vérification cryptographique, remonte sous la forme d’une exception typée PadesBt avec l’exception Core d’origine préservée comme throwable précédent. NextPDF Pro implémente la prise en charge de la signature PAdES B-T selon ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 et RFC 5816, et elle est vérifiée par fixtures ; il n’affirme pas une certification ETSI EN 319 142-1 indépendante et n’affirme pas la validité juridique du document.

SequentialSigner coordonne la signature multipartite. Chaque signataire est une révision distincte par mise à jour incrémentale. Le premier signataire peut être une signature de certification avec une restriction DocMDP définie via certifyFirst. PadesWrapper ingère une signature existante : fromCades incorpore directement une structure CMS, fromXades analyse un document XAdES et réutilise son matériel de signature principal, et detect sélectionne automatiquement selon le format. Le chemin XAdES réutilise le certificat, la chaîne, la valeur de signature et l’algorithme ; il ne transfère pas les propriétés qualifiantes XAdES.

Surface d’API publique

composer require nextpdf/pro:^3

Type	Genre	Rôle	Stabilité	Depuis
RemoteSigningSession	class	Session de signature à distance ou asynchrone en deux phases	stable	1.9.0
RemoteSigningConfig	class	Configuration de session immuable, incluant le niveau PAdES et l’algorithme	stable	1.9.0
SequentialSigner	class	Signature séquentielle multipartite avec prise en charge de DocMDP	stable	1.9.0
SequentialSigningResult	class	Résultat d’une exécution séquentielle : octets du PDF, chaîne, décompte, complétude	stable	1.9.0
SigningStrategy	interface	Le contrat de mécanisme de signature qu’une session appelle	stable	1.9.0
PadesWrapper	class	Enveloppe une signature CAdES ou XAdES existante pour l’incorporation PAdES	stable	1.9.0
KmsSignerInterface	interface (SPI)	Contrat de pilote HSM et KMS tiers ; étend le contrat de signataire HSM de Core	stable	2.1.0
SignatureAlgorithm	enum	OID d’algorithme de signature Pro et noms de condensé	stable	2.1.0
GenerationTimeMasker	class	Masquage piloté par règles appliqué avant que la page ne soit écrite	stable	1.9.0
MaskingConfig	class	Configuration de masquage immuable	stable	1.9.0
MaskingRule	class	Une règle de masquage unique (littéral ou PCRE)	stable	1.9.0
MaskingMode	enum	BlackBox, Asterisks, FixedLabel	stable	1.9.0

Contrat SigningStrategy

Une stratégie opère sur les attributs signés encodés en DER et renvoie les octets bruts de signature. C’est la session, et non la stratégie, qui assemble le CMS SignedData. Une stratégie expose le DER du certificat de signataire, le DER de la chaîne ordonnée de la feuille à la racine, l’OID de l’algorithme de signature, le nom de l’algorithme de condensé, et un indicateur isAsync qui marque une stratégie dont la session peut être sérialisée et reprise.

SPI KmsSignerInterface

KmsSignerInterface étend le contrat de signataire HSM de Core. Il ajoute un providerId stable pour la recherche dans le registre, une méthode signWithVersion avec un paramètre explicite de version de clé par appel, ainsi que supportsAlgorithm et supportedAlgorithms pour qu’un appelant découvre la compatibilité d’algorithme avant l’appel de signature. Les identifiants de fournisseur intégrés réservés sont aws-kms, azure-keyvault, gcp-kms, pkcs11, openssl-cli et openssl-engine. Un pilote tiers doit préfixer son identifiant d’un espace de noms pour éviter une collision. La sémantique de version de clé par défaut varie selon le fournisseur : un fournisseur résolvant les alias résout la clé active depuis l’alias lorsque la version est null ; un fournisseur qui sélectionne la dernière version activée le fait via son transport ; un fournisseur qui n’a pas de notion de version active côté serveur doit utiliser une version épinglée dans sa configuration, et doit lever une erreur de gestion de clés lorsque ni l’appel ni la configuration n’épinglent une version. Une version non vide épingle cette version, et le fournisseur doit lever une erreur de gestion de clés lorsque la version est inconnue, désactivée ou révoquée.

Cas limites et pièges

• Une signature produite n’est pas une signature vérifiée. La validation de chemin s’exécute chez le vérificateur avec les ancres de confiance et les vérifications de contrainte de base de ce vérificateur — RFC 5280 §6.1. Le producteur ne peut pas en affirmer le résultat.
• La session dispose d’un repli hérité à trois attributs pour des octets de certificat synthétique non X.509. Les stratégies de production fournissent toujours du vrai DER X.509, si bien que l’ensemble complet d’attributs B-B est le chemin de production. Le repli n’existe que pour la surface de test historique de la mécanique DER.
• La structure CMS doit tenir dans l’espace Contents réservé. Le SignedData B-B avec une chaîne de certificats complète a une taille ; la session lève une erreur de dépassement lorsque le CMS assemblé dépasse l’espace hexadécimal réservé. Dimensionne l’espace réservé en conséquence. Pour le B-T, le jeton RFC 3161 incorporé (dominé par la chaîne de certificats de la TSA) agrandit le CMS ; l’espace réservé B-T est augmenté automatiquement, et un espace configuré sous-dimensionné échoue de manière fermée avec une erreur de configuration typée plutôt que de tronquer.
• MaskingConfig::fromArray supprime une entrée dépourvue de motif de chaîne exploitable au lieu de faire échouer l’import. Valide la source de configuration si une suppression silencieuse est inacceptable.
• Le mode boîte noire du masquage émet un remplacement vide pour la séquence correspondante et supprime le texte sous-jacent. Une règle qui ne correspond pas à une valeur ne la masque pas ; le moteur n’affirme pas que tout le contenu sensible est trouvé.
• Le B-T nécessite un fournisseur d’horodatage branché. Sur le chemin du fournisseur RFC 3161 Core par défaut, le condensé de l’empreinte est SHA-256 ; un condensé d’empreinte autre que SHA-256 sur ce chemin est rejeté avec une erreur de configuration typée plutôt que silencieusement rétrogradé, et un fournisseur personnalisé fourni par l’appelant peut légitimement utiliser un autre condensé approuvé. Un serialNumber d’horodatage est unique par jeton émis par une autorité d’horodatage donnée, et genTime est l’instant UTC où le jeton a été créé — RFC 3161 §2.4.1, §2.4.2. Le matériel de validation à long terme B-LT/B-LTA reste une préoccupation de la frontière Enterprise ; Pro ne produit ni DSS, ni VRI, ni horodatage de document.
• OCSP unknown n’est pas good, et la fraîcheur du statut est bornée par thisUpdate et nextUpdate — RFC 6960 §2.2, §4.2.

Comportement en mode FIPS

Pro sélectionne l’algorithme à partir de l’algorithme de signature configuré et de la stratégie. Lorsqu’il est configuré contre un KMS ou un HSM validé FIPS, l’opération cryptographique s’exécute dans cette frontière validée, et l’ensemble d’algorithmes est celui que cette frontière permet. NextPDF Pro effectue l’assemblage structurel du CMS et le calcul du condensé ; ce n’est pas un module cryptographique validé FIPS et il ne formule aucune revendication de certification FIPS. Un déploiement qui exige une posture FIPS doit configurer un KMS ou un HSM validé FIPS, et le profil de politique cryptographique FIPS 140-3 est une capacité Enterprise.

Posture de contrôle des exportations

Ce module concerne des fonctionnalités cryptographiques ; traite-le comme sensible du point de vue de la sécurité dans ta propre revue.

Frontière Enterprise

NextPDF Pro produit la base B-B et le niveau B-T. Pour le B-B, la session assemble un CMS SignedData avec l’ensemble d’attributs signés B-B et n’applique aucun horodatage. Pour le B-T, il ajoute exactement un signature-time-stamp RFC 3161 en tant qu’attribut non signé CMS calculé sur la valeur de signature numérique d’un signataire — ETSI EN 319 122-1 §5.3. NextPDF Pro l’implémente selon ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 et RFC 5816, et elle est vérifiée par fixtures ; il n’affirme pas une certification, conformance ou conformité ETSI EN 319 142-1 indépendante, et n’affirme pas la validité juridique du document.

Les niveaux B-LT et B-LTA sont des capacités Enterprise et ne sont pas produits par Pro. B-LT et B-LTA ajoutent un Document Security Store et des horodatages de document pour la validation d’archivage à long terme — ETSI EN 319 142-2 §5.5. Un gestionnaire de signature qui produit ces niveaux prend en charge les entrées DSS et les horodatages de document — ETSI EN 319 142-2 §6.3.3.3. Le RemoteSigningConfig de Pro peut porter un niveau au-dessus de B-T (B-LT ou B-LTA) qui demande un Document Security Store, mais Pro ne livre pas ce producteur et n’agit pas dessus ; un tel niveau est une valeur déclarée par anticipation. Le flux de signature Core résout le producteur à long terme à l’exécution via le contrat Core, et ce producteur est livré dans le package nextpdf/enterprise. Dans un déploiement Pro uniquement, une demande de B-LT ou de B-LTA échoue de manière fermée avec un message qui nomme le composant Enterprise manquant. Pro ne produit ni DSS, ni dictionnaire VRI, ni horodatage de document, ni boucle d’archivage, et ne formule aucune revendication de validation à long terme (LTV). La garde matérielle des clés via PKCS#11, et le profil de politique cryptographique FIPS 140-3, sont aussi des capacités Enterprise. Cette page ne documente pas l’implémentation de validation à long terme d’Enterprise ; elle énonce seulement la frontière et le nom de package public.

Niveau PAdES	Ajoute	Édition productrice
B-B	Signature CMS avec attributs signés	Core, Pro
B-T	Un attribut non signé signature-time-stamp RFC 3161 sur la valeur de signature	Core, Pro
B-LT	Document Security Store avec matériel de validation	Enterprise (nextpdf/enterprise)
B-LTA	Horodatages de document pour la validité d’archivage	Enterprise (nextpdf/enterprise)

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 ticket sont hors périmètre.

Repli Core

Un déploiement sans le droit Pro conserve le contrat de signature Core. Le code qui dépend du contrat Core SignerInterface continue de signer avec le signataire CMS logiciel au niveau de base B-B. Le masquage, la détection de PII, et les stratégies de signature à distance et par cloud-KMS ne sont pas présents sans le package Pro, et un appel vers ces types est une erreur de dépendance dure, et non un no-op silencieux.

Résidence des données et atténuations PII

Les surfaces de masquage et de PII s’exécutent en cours de processus. Aucun contenu de document ne quitte l’hôte pour le masquage ou la détection de PII. Une stratégie cloud-KMS envoie le condensé des attributs signés, et non le document, au fournisseur pour l’opération de signature. La détection de PII est appariée par motif sur les types configurés et supprime les objets texte sous-jacents pour le mode boîte noire, comme testé. Ce n’est pas une garantie de suppression complète des données personnelles, ni une affirmation de conformité réglementaire.

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

La bibliothèque lève des exceptions typées avec des messages structurels. Elle n’écrit pas le contenu de document ni les valeurs de PII détectées dans les messages d’exception ou les journaux. Un déploiement qui journalise autour du chemin de signature devrait journaliser des champs structurels, et non des octets de document.

Conformité

Affirmation	Norme	Clause
La signature CMS est stockée encodée en DER dans l’entrée Contents du dictionnaire de signature.	ISO 32000-2	§12.8.1
Le processus de calcul du condensé de message ; les attributs signés portent content-type et message-digest.	RFC 5652	§5.4
Le vérificateur ne doit pas se fier aux condensés calculés par l’émetteur ; il recalcule indépendamment et compare (processus de vérification de signature).	RFC 5652	§5.6
Le SignerInfo porte l’identifiant d’algorithme de condensé et le bloc d’attributs signés.	RFC 5652	§5
Une requête d’horodatage renvoie une structure TSTInfo.	RFC 3161	§2.4.1
Un serialNumber d’horodatage est unique par jeton émis par une TSA donnée.	RFC 3161	§2.4.2
Le genTime de l’horodatage est l’instant UTC où le jeton a été créé.	RFC 3161	§2.4.2
Un signature-time-stamp PAdES B-T est un attribut non signé portant un jeton d’horodatage calculé sur la valeur de signature numérique d’un signataire (Pro produit le B-T).	ETSI EN 319 122-1	§5.3
L’empreinte du signature-time-stamp est le condensé de la valeur du champ signature du SignerInfo, balise et longueur ASN.1 exclues.	ETSI EN 319 122-1	§5.3
Le jeton signature-time-stamp utilise l’OID id-aa-timeStampToken ; son MessageImprint est un condensé de la valeur du champ signature du SignerInfo.	RFC 3161	Appendix A
Côté vérification, NextPDF lie le MessageImprint d’un signature-time-stamp à la valeur de signature du SignerInfo et échoue de manière fermée en cas de non-correspondance, de jeton manquant/dupliqué ou d’empreinte SHA-1 (vérification stricte, et non une certification).	RFC 3161	Appendix A
ESSCertIDv2 remplace l’ESSCertID hérité lié à SHA-1 ; le chemin B-T strict requiert ESSCertIDv2.	RFC 5816	§1
La validation de chemin de certification vérifie les contraintes de base et les entrées de chemin jusqu’à une ancre de confiance.	RFC 5280	§6.1
OCSP rapporte certStatus comme good, revoked ou unknown.	RFC 6960	§2.2
La fraîcheur du statut OCSP est bornée par thisUpdate et nextUpdate.	RFC 6960	§4.2
B-LT et B-LTA ajoutent un Document Security Store et des horodatages de document pour la validation à long terme (frontière Enterprise).	ETSI EN 319 142-2	§5.5
Un gestionnaire de signature qui produit les niveaux à long terme prend en charge les entrées DSS et les horodatages de document (frontière Enterprise).	ETSI EN 319 142-2	§6.3.3.3

Toutes les clauses sont paraphrasées. NextPDF ne reproduit pas le texte normatif. Consulte les normes publiées pour le libellé faisant autorité. NextPDF Pro implémente la prise en charge de la signature PAdES B-T selon ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 et RFC 5816, et elle est vérifiée par fixtures. ETSI EN 319 142-1 (la partie sur les niveaux de base PAdES) est hors de l’ensemble de preuves cité ; NextPDF Pro n’affirme donc pas une certification, conformance ou conformité ETSI EN 319 142-1 indépendante, et n’affirme pas la validité juridique du document. Cette page énonce la structure produite, les normes que la prise en charge B-T implémente, et la frontière Enterprise B-LT/B-LTA, et non un niveau de conformance certifié.

Voir aussi

• Signature Core — le signataire CMS, l’horodatage RFC 3161, la validation de chemin RFC 5280, OCSP et CRL.
• Correspondance de base PAdES — B-B, B-T, B-LT, B-LTA selon les éditions.
• Security (aperçu de la capacité) — la page de capacité de sécurité Pro publique.
• CMS · PAdES · Horodatage RFC 3161 · KMS · DSS — termes du glossaire.