Pro édition

Sécurité

En bref

NextPDF Pro ajoute une surface de sécurité au-dessus de NextPDF Core : masquage de contenu au moment de la génération, détection de PII dans la couche texte, stratégies de signature à distance et par cloud-KMS, et signature séquentielle multipartite. NextPDF Core produit les niveaux PAdES B-B et B-T ; Pro produit les mêmes niveaux et ajoute ces flux de signature par-dessus (pour le B-T, une signature B-B plus un horodatage de signature RFC 3161 sur la valeur de signature). Cette page se situe au niveau du comportement. Elle énonce ce que fait chaque partie, ce qu’elle ne fait pas, et où commence la frontière Enterprise.

Disponibilité et licence

Cette fonctionnalité 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 fonctionnalité. 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 et les flux de signature à distance/cloud-KMS/séquentielle ; ces flux produisent les mêmes niveaux Core B-B et B-T via la pile RFC 3161 de Core (pour le B-T, un horodatage de signature sur la valeur de signature). Un déploiement sans droit Pro actif ne charge pas ces classes ; le contrat de signature Core continue de fonctionner sans changement.

Installation

composer require nextpdf/pro:^3

Aperçu conceptuel

Le moteur de masquage applique une liste de règles ordonnée au texte avant que la page ne soit écrite. Chaque règle correspond à une expression régulière. Une règle remplace une correspondance de l’une des trois façons : un remplissage en boîte noire qui supprime le texte du flux de contenu, une séquence d’astérisques du même nombre de caractères, ou une étiquette fixe telle que [REDACTED]. Le moteur supprime les objets texte sous-jacents pour le mode boîte noire, comme testé ; il n’affirme pas que toute forme de contenu sensible est trouvée. La détection dépend des règles que tu configures.

La surface PII est un outil de détection, et non une garantie de masquage. Elle extrait la couche texte, 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 une vue masquée du texte et un décompte de correspondances. Elle n’écrase pas les glyphes rendus dans l’image de la page. Une page numérisée sans couche texte ne produit aucune correspondance. Traite le résultat comme une détection par motif des types configurés, et non comme une suppression complète de données personnelles.

La surface de signature ajoute des flux à distance et asynchrones au-dessus du signataire Core. Une session calcule le condensé du document, construit les attributs signés CMS, et remet les octets des attributs signés à une stratégie de signature. Une stratégie peut être un cloud KMS, un signataire externe différé, ou un chemin d’ingestion qui enveloppe une signature CAdES ou XAdES existante. La session assemble ensuite le CMS SignedData et le stocke encodé en DER dans l’entrée Contents du dictionnaire de signature — ISO 32000-2 §12.8.1. Le SignerInfo porte les attributs signés content-type et message-digest ; le processus de calcul du condensé de message est RFC 5652 §5.4. Un vérificateur ne doit pas se fier aux condensés calculés par l’émetteur ; il recalcule indépendamment le condensé du contenu et le compare à l’attribut message-digest, et la comparaison doit correspondre pour que la signature soit valide — RFC 5652 §5.6 processus de vérification de signature.

NextPDF Core produit les niveaux PAdES B-B et B-T ; NextPDF Pro produit les mêmes niveaux et ajoute ses flux de signature par-dessus. 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, la session ajoute exactement un signature-time-stamp RFC 3161 en tant qu’attribut non signé CMS sur la valeur de signature : 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, et son MessageImprint est un condensé de la valeur du champ signature du SignerInfo, identifié par l’OID id-aa-timeStampToken — RFC 3161 Appendix A. Le genTime de l’horodatage est l’instant UTC où le jeton a été créé — RFC 3161 §2.4.2. Comme l’horodatage est un attribut non signé, le condensé signé B-B, la valeur de signature du SignerInfo et le /ByteRange du PDF sont inchangés ; seul le CMS grandit. Le jeton RFC 3161 est obtenu auprès d’un fournisseur d’horodatage configuré (le client RFC 3161 Core par défaut, ou un fournisseur fourni par l’appelant) ; le B-T utilise une empreinte de message SHA-256 sur le chemin du fournisseur par défaut. 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 ; ceci est vérifié par fixtures. NextPDF Pro n’affirme pas une certification ETSI EN 319 142-1 indépendante et n’affirme pas la validité juridique du document. 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 ; ces niveaux sont une capacité Enterprise (nextpdf/enterprise) et ne sont pas produits par Pro. Voir Frontière Enterprise ci-dessous.

Pourquoi cela fonctionne ainsi

La surface de signature remet les octets des attributs signés à une SigningStrategy plutôt que de détenir une clé privée. Cette seule décision est structurante. Un cloud KMS, un signataire externe différé ou un chemin d’ingestion CAdES/XAdES satisfont tous le même contrat, si bien que le code appelant reste identique et que le matériel de clé n’entre jamais dans NextPDF. Scinder la session en RemoteSigningSession::prepare() et RemoteSigningSession::complete() permet à la signature de revenir de façon asynchrone, car le condensé est fixé avant que la clé ne soit jamais atteinte. L’horodatage est attaché en tant qu’attribut non signé CMS, si bien que le B-T reste additif : le condensé signé B-B, la valeur de signature du SignerInfo et le /ByteRange sont intacts. Chaque jointure est fermée en cas d’échec, car un chemin de signature qui se dégrade silencieusement est pire qu’un qui s’arrête. Contexte de conception : Signer à grande échelle, sans compromis.

Surface d’API

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	stable	1.9.0
`SequentialSigner`	class	Signature séquentielle multipartite avec prise en charge de DocMDP	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	stable	2.1.0
`GenerationTimeMasker`	class	Masquage piloté par règles appliqué avant que la page ne soit écrite	stable	1.9.0
`MaskingConfig` / `MaskingRule` / `MaskingMode`	types	Configuration de masquage, règle et mode de remplacement	stable	1.9.0

RemoteSigningConfig porte un champ de niveau PAdES dont l’énumération est le SignatureLevel de Core. Le chemin de signature Pro produit la base B-B et le niveau B-T : configure RemoteSigningConfig::default()->withLevel(SignatureLevel::PAdES_B_T) (ou utilise SequentialSigner::withTimestamping()) et fournis un fournisseur d’horodatage, et la session ajoute l’attribut non signé signature-time-stamp RFC 3161. L’espace réservé /Contents du B-T est augmenté automatiquement pour que le jeton tienne ; un espace configuré sous-dimensionné échoue de manière fermée avec une erreur de configuration typée plutôt que de tronquer. Un niveau au-dessus de B-T porté dans la configuration (B-LT ou B-LTA) est une valeur déclarée par anticipation sur laquelle Pro n’agit pas ; ce producteur à long terme se résout à l’exécution via le contrat Core et est livré dans le package nextpdf/enterprise.

Exemple de code — Démarrage rapide

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Pro\Security\Signing\RemoteSigningSession;
use NextPDF\Pro\Security\Signing\SigningStrategy;

/**
 * Produce a signed PDF using any signing strategy.
 *
 * @param string          $pdfWithPlaceholder PDF bytes with a signature placeholder.
 * @param SigningStrategy  $strategy           A cloud-KMS, deferred, or ingest strategy.
 *
 * @return string The signed PDF bytes.
 */
function signWithStrategy(string $pdfWithPlaceholder, SigningStrategy $strategy): string
{
    $session = RemoteSigningSession::create($pdfWithPlaceholder);

    $session->prepare(
        certDer: $strategy->getCertificateDer(),
        chainDer: $strategy->getCertificateChainDer(),
        algorithmOid: $strategy->getSignatureAlgorithmOid(),
        digestAlgorithm: $strategy->getDigestAlgorithm(),
        contentsHexStart: 0,
        contentsHexEnd: 0,
    );

    return $session->complete($strategy);
}

L’appelant dépend du contrat SigningStrategy. Une stratégie cloud-KMS et une stratégie d’ingestion CAdES le satisfont toutes deux, si bien que ce code ne change pas d’une stratégie à l’autre.

Exemple de code — Production

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Pro\Security\Signing\SequentialSigner;
use NextPDF\Pro\Security\Signing\SigningStrategy;
use Psr\Log\LoggerInterface;

final readonly class ApprovalWorkflow
{
    public function __construct(private LoggerInterface $logger) {}

    /**
     * Sign a PDF with two parties in sequence.
     *
     * @param string          $pdfData   The PDF bytes to sign.
     * @param SigningStrategy  $approver  The first-party strategy.
     * @param SigningStrategy  $reviewer  The second-party strategy.
     *
     * @return string The signed PDF bytes.
     */
    public function run(string $pdfData, SigningStrategy $approver, SigningStrategy $reviewer): string
    {
        try {
            $result = SequentialSigner::create($pdfData)
                ->addSigner($approver, 'Approver', reason: 'Approved')
                ->addSigner($reviewer, 'Reviewer', reason: 'Reviewed')
                ->sign();

            $this->logger->info('Sequential signing complete', [
                'signatures' => $result->signatureCount,
            ]);

            return $result->pdfData;
        } catch (\Throwable $e) {
            $this->logger->error('Sequential signing failed', ['error' => $e->getMessage()]);

            throw $e;
        }
    }
}

Chaque signataire est une révision incrémentale distincte. Le bloc catch journalise et relève l’exception ; il n’avale pas la défaillance, ce qui maintient le chemin de signature fermé en cas d’échec.

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 de ce vérificateur — RFC 5280 §6.1. Le producteur ne peut pas en affirmer le résultat.
La détection de masquage dépend des règles configurées. Un ensemble de règles qui ne correspond pas à une valeur ne la masque pas. Le moteur n’affirme pas que tout le contenu sensible est trouvé.
La détection de PII porte uniquement sur la couche texte. Une page numérisée sans couche texte ne produit aucune correspondance. L’outil n’écrase pas les glyphes rendus de la page.
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 ; dimensionne l’espace réservé en conséquence, sinon la session lève une erreur de dépassement.
Une stratégie cloud-KMS dépend de l’accessibilité réseau et de la disponibilité du fournisseur. Une erreur de réseau ou de fournisseur lève une exception typée ; la session ne produit pas silencieusement un document non signé.
OCSP unknown n’est pas good. Traite unknown comme une non-détermination — RFC 6960 §2.2.

Performance

Une signature logicielle se chiffre en millisecondes à un chiffre. Une signature cloud-KMS ajoute un aller-retour réseau vers le fournisseur. Une signature B-T ajoute un aller-retour vers le fournisseur d’horodatage configuré, en plus de l’opération de signature. Le budget mural de 1500 ms couvre une seule signature B-B avec un fournisseur distant sur une connexion chaude. Le coût du masquage évolue avec le nombre de règles et la longueur du texte. Le profil de reproductibilité est structural : les attributs signés B-B intègrent l’instant de signature et une signature B-T intègre en outre un jeton d’horodatage, si bien que deux exécutions diffèrent par les octets de signing-time et d’horodatage alors que la structure signée est identique.

Notes de sécurité

C’est une frontière cryptographique, le modèle de menace est donc explicite. La plage d’octets est calculée par le moteur et n’est jamais acceptée de l’appelant. Le chemin de signature est fermé en cas d’échec : une défaillance de primitive ou une lacune de capacité lève une exception typée et ne rétrograde jamais silencieusement vers un algorithme plus faible. Une stratégie cloud-KMS est un point d’intégration, et non un magasin de clés. La protection des clés dépend de la manipulation des clés, du KMS configuré et du déploiement ; NextPDF Pro ne détient pas la clé privée pour une stratégie KMS. Pro opère en mode compatible FIPS lorsqu’il est configuré contre un KMS ou un HSM validé FIPS ; NextPDF Pro n’est pas lui-même un module cryptographique validé FIPS. Cette page concerne la signature cryptographique ; chaque source normative est paraphrasée et aucune n’est reproduite.

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 les champs structurels montrés dans l’exemple de production, et non les octets du document.

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. NextPDF Pro effectue lui-même l’assemblage structurel et le calcul du condensé ; ce n’est pas un module validé FIPS et il ne formule aucune revendication de certification FIPS.

Frontière Enterprise

NextPDF Pro produit la base B-B et le niveau B-T. Le B-T ajoute un signature-time-stamp RFC 3161 en tant qu’attribut non signé CMS sur la valeur de signature, 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 ; il est vérifié par fixtures. NextPDF Pro n’affirme pas une certification 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. Une configuration qui demande un Document Security Store ou la boucle d’archivage à long terme résout ce producteur à l’exécution via le contrat Core ; ce producteur est livré dans le package nextpdf/enterprise. Dans un déploiement Pro uniquement, demander B-LT ou B-LTA échoue de manière fermée avec un message qui nomme le composant Enterprise manquant. Pro ne produit ni Document Security Store, 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.

Niveau PAdES	Ajoute	Édition productrice
B-B	Signature CMS avec attributs signés	Core, Pro, Enterprise
B-T	Un attribut non signé signature-time-stamp RFC 3161 sur la valeur de signature	Core, Pro, Enterprise
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`)

Contrat de comportement

Le masquage applique les règles configurées avant que la page ne soit écrite et supprime les objets texte sous-jacents pour le mode boîte noire, comme testé.
La détection de PII extrait la couche texte, applique les motifs configurés, et renvoie une vue masquée et un décompte de correspondances. Elle n’écrase pas les glyphes rendus.
La signature à distance est en deux phases : prepare calcule le condensé et construit les attributs signés ; complete assemble le CMS et l’incorpore.
Pro produit la base B-B et le niveau B-T. Pour le B-T, la session ajoute un signature-time-stamp RFC 3161 en tant qu’attribut non signé CMS sur la valeur de signature ; le condensé signé B-B et le /ByteRange sont inchangés. Une demande B-T sans fournisseur d’horodatage, ou avec un espace Contents configuré sous-dimensionné, échoue de manière fermée avec une erreur de configuration typée. Une demande de B-LT ou de B-LTA sans le package Enterprise échoue de manière fermée avec une erreur nommée.
Une stratégie cloud-KMS reçoit le condensé des attributs signés, et non le document, et renvoie les octets bruts de signature.

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
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
Le `MessageImprint` du jeton signature-time-stamp `id-aa-timeStampToken` 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-concordance, de jeton manquant/dupliqué ou d’empreinte SHA-1 (vérification stricte, et non une certification).	RFC 3161	Appendix A
Un jeton d’horodatage B-T porte un genTime UTC qui est l’instant où le jeton a été créé.	RFC 3161	§2.4.2
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
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

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é.

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

Voir aussi

Sécurité — référence approfondie — la référence approfondie de cette surface de sécurité Pro.
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.
NextPDF Pro — la surface complète des fonctionnalités Pro.
Sécurité Core — le chiffrement et la surface de signature élargie.
CMS · PAdES · Horodatage RFC 3161 · KMS · DSS — termes du glossaire.