Politique cryptographique et autotest FIPS 140-2/3

En bref

NextPDF Enterprise limite à un ensemble approuvé par les Federal Information Processing Standards (FIPS) les choix cryptographiques qu’une opération de signature ou de chiffrement peut effectuer, et refuse tout choix en dehors de cet ensemble. Un garde d’exécution valide chaque hachage, chaque identifiant d’algorithme de signature, chaque algorithme de chiffrement et chaque niveau de robustesse de clé avant l’exécution de l’opération. Une batterie d’autotests au démarrage s’exécute une fois au lancement du processus. Si un test à réponse connue échoue, le module entre dans un état d’erreur. Cette page décrit le comportement : ce que la politique autorise, ce que le garde refuse, ce que l’autotest couvre et la position explicite en matière de certification.

NextPDF Enterprise contribue à la conformité. Ce n’est pas un module cryptographique certifié. Voir Sécurité et conformité pour la position explicite de non-certification.

Le front matter liste les prérequis, et Prérequis les reprend.

Disponibilité et licence

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

NextPDF Core et NextPDF Pro ne fournissent pas de profil en mode FIPS. Le garde et l’autotest s’exécutent dans le processus ; les contrôles de politique et les autotests n’envoient aucun contenu de document hors de l’hôte.

Ce que fait cette capacité

La capacité comporte trois parties : une politique cryptographique, un garde d’exécution et un autotest au démarrage.

La politique cryptographique limite les choix cryptographiques à un ensemble approuvé, avec deux préréglages :

• Strict (aligné sur la génération FIPS 140-3) — hachages SHA-256, SHA-384 et SHA-512 ; identifiants d’objet (OID) de signature RSA et ECDSA avec ces hachages ; chiffrement AES-256-CBC ; et tailles minimales de clé RSA 2048 et courbe elliptique 256.
• Standard (aligné sur la génération FIPS 140-2) — identique au préréglage strict, et autorise en plus AES-128-CBC pour l’interopérabilité avec les versions plus anciennes.

Pour la génération de signature, NIST SP 800-131A Rev.2 §3 accepte une clé RSA d’au moins 2048 bits et un ordre ECDSA d’au moins 224 bits ; les planchers 2048/256 du préréglage strict atteignent ou dépassent ces minimums. La politique refuse par défaut un type de clé inconnu — elle n’accepte pas silencieusement un type non reconnu.

Le garde d’exécution encapsule la politique et expose des méthodes d’assertion pour un hachage, un OID de signature, un algorithme de chiffrement et un niveau de robustesse de clé. Lorsqu’un choix n’est pas autorisé, il lève une violation typée qui nomme la politique et l’élément fautif, puis arrête l’opération. Ce chemin échoue en mode fermé : la politique ne s’assouplit jamais et ne substitue jamais un algorithme plus faible. Pour une signature RSASSA-PSS, la barrière de génération lie explicitement le condensé du message. Toutes les variantes PSS partagent un même OID de signature ; le hachage réside dans les paramètres PSS, pas dans l’OID. Une liste d’autorisation d’OID ne peut pas à elle seule prouver le condensé effectif, aussi la barrière vérifie que ce condensé est approuvé FIPS (SHA-256/384/512). Elle refuse en mode fermé tout jeton PSS dont le condensé est inconnu ou non approuvé, par exemple SHA-1 PSS, avant tout acheminement vers un signataire (FIPS 186-5 §5.4(b)).

L’autotest au démarrage exécute une batterie de tests à réponse connue (KAT) une fois au lancement du processus. La batterie couvre les fonctions approuvées de hachage, d’authentification de message, de chiffrement, de chiffrement authentifié, de signature et de génération de bits aléatoires. Selon ISO/IEC 19790:2025 §7.10.4.2, un test à réponse connue échoue lorsque la sortie calculée n’est pas égale à la réponse connue. En cas d’échec, quel qu’il soit, le module entre dans un état d’erreur et refuse les services cryptographiques (ISO/IEC 19790:2025 §7.2.4.3). L’état d’erreur est rémanent au niveau du processus : dès qu’un garde de démarrage du processus constate une erreur, l’ensemble du processus reste en mode fermé pour toute sa durée de vie. Créer un nouveau garde de démarrage ou une nouvelle politique ne permet pas de l’effacer. Une nouvelle exécution réussie de l’autotest ne réinitialise pas une erreur verrouillée — seul un redémarrage du processus (un véritable cycle d’alimentation) le fait, selon ISO/IEC 19790:2025 §7.10.2. Le résultat est mis en cache pour la durée de vie du processus ; tu peux lancer une nouvelle exécution à la demande pour un point d’accès d’administration ou une commande, mais elle répond à l’obligation d’autotest périodique, pas à une récupération après erreur.

La politique exige un vecteur d’initialisation (IV) unique par clé pour l’usage du chiffrement authentifié, selon NIST SP 800-38D §5.2.1.

Pourquoi ce fonctionnement

La validation FIPS s’attache à une frontière de module cryptographique précise, pas à une application qui en appelle un. NextPDF applique donc la politique et exécute la batterie d’autotests, mais délègue chaque primitive à un fournisseur validé FIPS que tu configures — il affirme des choix approuvés plutôt que de prétendre être le module validé. L’état d’erreur est délibérément rémanent au niveau du processus : une non-correspondance d’autotest signifie qu’on ne peut plus faire confiance au module, aussi un garde neuf ou une nouvelle exécution réussie ultérieure ne doit pas l’effacer silencieusement, et seul un véritable redémarrage du processus le fait. Ainsi, la défaillance reste honnête et auditable au lieu d’être discrètement récupérable sur place. Le résultat est une capacité qui contribue à la conformité sans jamais exagérer ce pour quoi NextPDF est certifié.

Contexte de conception : Une conformité que tu peux remettre à un auditeur.

Prérequis

1. Installe NextPDF Core et le paquet Enterprise, et conserve une licence Enterprise active.
2. Pour revendiquer un fonctionnement compatible FIPS, configure NextPDF avec un fournisseur cryptographique validé FIPS — par exemple un fournisseur OpenSSL validé FIPS — ou un module matériel de sécurité (HSM) validé FIPS. NextPDF Enterprise effectue l’assemblage structurel, le calcul de condensé et l’application de la politique ; la primitive sous-jacente s’exécute dans la frontière validée que tu fournis.
3. Choisis le préréglage : strict pour une application alignée sur FIPS 140-3, ou standard lorsque l’interopérabilité AES-128-CBC est requise.

Configuration

• Préréglage — choisis strict ou standard. Strict autorise uniquement AES-256-CBC ; standard autorise également AES-128-CBC.
• Garde — construis le garde avec la politique choisie. Utilise le garde comme point de contrôle où tu valides chaque choix cryptographique.
• Câblage de l’autotest — câble le garde de démarrage à l’amorçage de l’application afin que chaque processus de travail exécute son propre cycle d’autotest. Chaque instance de processus exécute son propre autotest au démarrage.

Étape par étape

1. À l’amorçage de l’application, exécute l’autotest au démarrage via le garde de démarrage et vérifie que le module est opérationnel. Arrête le processus s’il ne l’est pas.
2. Construis le garde avec la politique strict ou standard.
3. Avant chaque opération cryptographique, valide le hachage, l’OID de signature, l’algorithme de chiffrement et la robustesse de clé via le garde.
4. Capture la violation typée, journalise un message structuré et refuse l’opération. Ne te rabats pas sur un choix plus faible.

examples/enterprise/fips-boot-and-guard.php

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Security\Fips\FipsBootGuard;
use NextPDF\Enterprise\Security\Fips\FipsCryptoPolicy;
use NextPDF\Enterprise\Security\Fips\FipsModeGuard;
use NextPDF\Enterprise\Security\Fips\FipsSelfTest;
use NextPDF\Enterprise\Security\Fips\FipsModuleErrorStateException;
use Psr\Log\LoggerInterface;

/**
 * Run the power-on self-test, then build a guard on the strict policy.
 *
 * The self-test runs once per process. A known-answer failure raises a
 * module-error-state exception; the caller must stop rather than proceed
 * with an unverified crypto path.
 *
 * @param LoggerInterface $logger Structural diagnostics only — never secrets.
 *
 * @throws FipsModuleErrorStateException When a power-on known-answer test fails.
 *
 * @return FipsModeGuard A guard ready to assert each cryptographic choice.
 */
function bootFipsGuard(LoggerInterface $logger): FipsModeGuard
{
    $bootGuard = new FipsBootGuard(new FipsSelfTest());

    try {
        $bootGuard->assertOperational();
    } catch (FipsModuleErrorStateException $e) {
        $logger->critical('FIPS power-on self-test failed; refusing crypto services.', [
            'reason' => $e->getMessage(),
        ]);

        throw $e;
    }

    return new FipsModeGuard(FipsCryptoPolicy::strict());
}

examples/enterprise/fips-assert-choices.php

<?php

declare(strict_types=1);

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

use NextPDF\Enterprise\Security\Fips\FipsModeGuard;
use NextPDF\Enterprise\Security\Fips\FipsViolationException;
use Psr\Log\LoggerInterface;

final readonly class FipsCheckedSigning
{
    public function __construct(
        private FipsModeGuard $guard,
        private LoggerInterface $logger,
    ) {}

    /**
     * Assert the signing choices against the active policy before signing.
     *
     * A disallowed hash, signature OID, or key strength raises a typed
     * violation; the operation is refused rather than downgraded.
     *
     * @param string       $hash         The hash algorithm name (e.g. 'sha256').
     * @param string       $signatureOid The signature algorithm OID.
     * @param string       $keyType      The key type (e.g. 'rsa', 'ec').
     * @param positive-int  $keyBits      The key length in bits.
     *
     * @throws FipsViolationException When any choice is not approved.
     */
    public function assertApproved(
        string $hash,
        string $signatureOid,
        string $keyType,
        int $keyBits,
    ): void {
        try {
            $this->guard->assertHashAllowed($hash);
            $this->guard->assertSignatureAlgorithmAllowed($signatureOid);
            $this->guard->assertKeyStrengthAllowed($keyType, $keyBits);
        } catch (FipsViolationException $e) {
            $this->logger->error('FIPS policy violation', ['reason' => $e->getMessage()]);

            throw $e;
        }
    }
}

Vérification

1. Exécute l’autotest au démarrage et confirme qu’il signale un état opérationnel. Confirme qu’il sollicite chaque classe d’algorithme approuvée — hachage, authentification de message, chiffrement, chiffrement authentifié, signature et génération de bits aléatoires.
2. Valide un choix approuvé, par exemple SHA-256, RSA 2048, et confirme qu’il passe. Valide un choix non autorisé, par exemple SHA-1, RSA 1024, et confirme qu’il lève une violation typée.
3. Injecte dans l’autotest une fonction de hachage ou une source d’aléa délibérément défectueuse et confirme que le module entre dans l’état d’erreur et refuse les services.
4. Confirme qu’un type de clé inconnu est refusé par défaut plutôt qu’accepté.

Sécurité et conformité

• Échec en mode fermé. Lorsqu’un choix cryptographique n’est pas autorisé, le garde lève une violation typée et arrête l’opération. La politique ne s’assouplit jamais et ne substitue jamais un algorithme plus faible.
• L’autotest refuse en cas de non-correspondance. L’échec d’un test à réponse connue place le module dans un état d’erreur rémanent au niveau du processus. L’ensemble du processus reste en mode fermé ; un garde de démarrage ou une politique neuve ne peut pas le rétablir, et une nouvelle exécution réussie ne lève pas le verrou. Seul un redémarrage du processus le réinitialise (ISO/IEC 19790:2025 §7.10.4.2 ; §7.10.2).
• Robustesse de clé. Le préréglage strict impose les minimums RSA 2048 et courbe elliptique 256, qui atteignent ou dépassent les planchers acceptables de NIST SP 800-131A Rev.2 §3.
• Unicité de l’IV. L’usage du chiffrement authentifié exige un IV unique par clé (NIST SP 800-38D §5.2.1).

Cette page concerne la politique cryptographique. Chaque source normative est paraphrasée ; aucun texte normatif n’est reproduit. > NextPDF Enterprise n’est pas un module cryptographique validé FIPS et ne revendique aucune certification FIPS. Il ne fonctionne en mode compatible FIPS que lorsque tu le configures avec un fournisseur cryptographique validé FIPS — par exemple un fournisseur OpenSSL validé FIPS — ou un module matériel de sécurité (HSM) validé FIPS. La politique en mode FIPS contribue à la conformité ; il ne s’agit ni d’une certification ni d’un avis juridique. Consulte tes propres conseillers en conformité et conseillers juridiques au sujet de tes obligations réglementaires.

Gestion des défaillances

• Échec de l’autotest au démarrage. Le garde de démarrage lève une exception d’état d’erreur du module. Arrête le processus ; ne poursuis pas avec un chemin cryptographique non vérifié.
• Violation de la politique. Le garde lève une violation typée qui nomme la politique et l’élément fautif. Refuse l’opération ; ne procède à aucune rétrogradation.
• Type de clé inconnu. La politique le refuse par défaut. Associe explicitement le type de clé uniquement s’il est réellement approuvé.
• Nouvelle exécution de l’autotest. Une nouvelle exécution est disponible à la demande pour un point d’accès d’administration ou une commande, ce qui satisfait l’obligation d’autotest périodique à la demande. Ce n’est pas un mécanisme de récupération : une nouvelle exécution en échec verrouille elle aussi le processus, et une nouvelle exécution réussie ne lève pas un verrou existant. Récupérer un module en état d’erreur nécessite un redémarrage du processus.

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

Voir aussi

• Sécurité — NextPDF Enterprise — les contrôles de sécurité Enterprise consolidés.
• Signature HSM — NextPDF Enterprise — garde des clés matérielles selon Public-Key Cryptography Standards #11 (PKCS#11).
• Signature — NextPDF Enterprise — le producteur longue durée PDF Advanced Electronic Signatures (PAdES) B-LT et B-LTA.
• Sécurité — NextPDF Core — la surface de chiffrement et de signature du cœur.
• Mode FIPS · KAT · chiffrement authentifié (AEAD) — termes du glossaire.