Politique cryptographique et autotests FIPS 140-2/3

En bref

NextPDF Enterprise limite les choix cryptographiques utilisables par une opération de signature ou de chiffrement à un ensemble approuvé FIPS, 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 et place le module dans un état d’erreur si un test à réponse connue échoue. Cette page décrit le comportement attendu : ce que la politique autorise, ce que le garde refuse, ce que l’autotest couvre, ainsi que la position explicite en matière de certification.

NextPDF Enterprise est un outil d’aide à la conformité, pas un module cryptographique certifié. La position explicite de non-certification est précisée sous Sécurité et conformité.

Les prérequis sont indiqués dans le front matter et repris sous Prérequis.

Édition et licence

Le profil de politique cryptographique en mode FIPS, le garde d’exécution et le garde d’autotest au démarrage sont fournis dans le paquet nextpdf/enterprise et conditionnés par l’indicateur de fonctionnalité de licence enterprise. NextPDF Core et NextPDF Pro ne fournissent pas de profil en mode FIPS. Le garde et l’autotest s’exécutent dans le processus ; aucun contenu de document ne quitte l’hôte pour le contrôle de la politique ou pour l’autotest. Comparer les éditions.

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 de courbe elliptique 256.
Standard (aligné sur la génération FIPS 140-2) — identique au préréglage strict, mais autorisant en plus AES-128-CBC pour l’interopérabilité avec les versions plus anciennes.

Une clé RSA d’au moins 2048 bits et un ordre ECDSA d’au moins 224 bits sont les minimums acceptables pour la génération de signature selon NIST SP 800-131A Rev.2 §3 ; les seuils 2048/256 du préréglage strict sont égaux ou supérieurs à ces minimums. Un type de clé inconnu est refusé par défaut : la politique 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é. Un choix non autorisé 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 : comme toutes les variantes PSS partagent un même OID de signature — le hachage réside dans les paramètres PSS, pas dans l’OID —, la liste d’autorisation d’OID ne peut pas prouver à elle seule le condensé réellement utilisé ; la barrière vérifie donc que ce condensé est approuvé FIPS (SHA-256/384/512) et refuse en mode fermé un jeton PSS dont le condensé est inconnu ou non approuvé, par exemple SHA-1 PSS, avant de l’acheminer vers le 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, couvrant 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. Un test à réponse connue échoue lorsque la sortie calculée n’est pas égale à la réponse connue, selon ISO/IEC 19790:2025 §7.10.4.2. 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 d’effacer cet état, et 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 ; une nouvelle exécution à la demande est disponible pour un point d’accès d’administration ou une commande, mais elle répond à l’obligation d’autotest périodique, et non à une récupération après erreur.

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

Prérequis

Installe NextPDF Core et le paquet Enterprise, et assure-toi de disposer d’une licence Enterprise active.
Pour revendiquer un fonctionnement compatible FIPS, configure NextPDF avec un fournisseur cryptographique validé FIPS — par exemple un fournisseur OpenSSL validé FIPS — ou un 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.
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. Le garde est le 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. Plusieurs instances de processus exécutent chacune leur propre autotest au démarrage.

Étape par étape

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

<?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());
}

<?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

Exécute l’autotest au démarrage et confirme qu’il signale un état opérationnel. Confirme que chaque classe d’algorithme approuvée — hachage, authentification de message, chiffrement, chiffrement authentifié, signature et génération de bits aléatoires — est sollicitée.
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.
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.
Confirme qu’un type de clé inconnu est refusé par défaut plutôt qu’accepté.

Sécurité et conformité

Échec en mode fermé. Un choix cryptographique non autorisé 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 toute 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 rétablir cet état, 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, égaux ou supérieurs aux 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 porte la marque export_control_class: legal-review-required parce qu’elle concerne la politique cryptographique. Chaque source normative est paraphrasée ; aucun texte normatif n’est reproduit. Une validation juridique est requise avant que l’indicateur publish ne soit activé.

NextPDF Enterprise n’est pas un module cryptographique validé FIPS et ne revendique aucune certification FIPS. Il ne fonctionne en mode compatible FIPS que 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 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é à un type reconnu 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. La récupération d’un module en état d’erreur nécessite un redémarrage du processus.

Contexte commercial

NextPDF Core fournit le signataire logiciel et le chiffrement sans profil en mode FIPS. NextPDF Enterprise ajoute le profil de politique cryptographique en mode FIPS, le garde d’exécution et le garde d’autotest au démarrage, afin qu’un déploiement puisse restreindre les choix cryptographiques à un ensemble approuvé et échouer en mode fermé en cas de non-correspondance de l’autotest. Associe-le à la signature HSM pour exécuter la primitive à l’intérieur d’un dispositif validé FIPS. Comparer les éditions.

Voir aussi

Sécurité — NextPDF Enterprise — la surface de sécurité Enterprise consolidée.
Signature HSM — NextPDF Enterprise — garde des clés matérielles PKCS#11.
Signature — NextPDF Enterprise — le producteur PAdES B-LT et B-LTA longue durée.
Sécurité — NextPDF Core — la surface de chiffrement et de signature du cœur.
Mode FIPS · KAT · AEAD — termes du glossaire.