Directiva criptográfica y autocomprobación FIPS 140-2/3

De un vistazo

NextPDF Enterprise restringe las opciones criptográficas que puede usar una operación de firma o de cifrado a un conjunto aprobado por las Federal Information Processing Standards (FIPS) y rechaza cualquier opción ajena a ese conjunto. Una protección en tiempo de ejecución valida cada hash, identificador de algoritmo de firma, algoritmo de cifrado y fortaleza de clave antes de ejecutar la operación. Una batería de autocomprobación de encendido se ejecuta una vez al iniciar el proceso y coloca el módulo en un estado de error si falla alguna prueba de respuesta conocida. Esta página describe el comportamiento: qué permite la directiva, qué rechaza la protección, qué cubre la autocomprobación y cuál es la postura explícita sobre la certificación.

NextPDF Enterprise es una herramienta de asistencia al cumplimiento, no un módulo criptográfico certificado. La declaración explícita de no certificación se indica en Seguridad y cumplimiento.

Los requisitos previos se indican en el front matter y se repiten en Requisitos previos.

Edición y licencias

El perfil de directiva criptográfica en modo FIPS, la protección en tiempo de ejecución y la protección de autocomprobación de encendido forman parte del paquete nextpdf/enterprise y están condicionados por el indicador de característica de licencia enterprise. NextPDF Core y NextPDF Pro no proporcionan un perfil en modo FIPS. La protección y la autocomprobación se ejecutan dentro del proceso; ningún contenido del documento sale del host durante la comprobación de la directiva ni durante la autocomprobación. Comparar ediciones.

Qué hace esta funcionalidad

La funcionalidad consta de tres partes: una directiva criptográfica, una protección en tiempo de ejecución y una autocomprobación de encendido.

La directiva criptográfica restringe las opciones criptográficas a un conjunto aprobado, con dos preajustes:

• Strict (alineado con la generación FIPS 140-3): hashes SHA-256, SHA-384 y SHA-512; identificadores de objeto (OID) de firma RSA y ECDSA con esos hashes; cifrado AES-256-CBC; y tamaños mínimos de clave de RSA 2048 y curva elíptica 256.
• Standard (alineado con la generación FIPS 140-2): igual que strict, pero permite además AES-128-CBC para la interoperabilidad con sistemas más antiguos.

Una clave RSA de al menos 2048 bits y un orden ECDSA de al menos 224 bits son los mínimos aceptables para la generación de firmas según NIST SP 800-131A Rev.2 §3; los límites mínimos 2048/256 del preajuste strict se sitúan en esos mínimos o por encima de ellos. Un tipo de clave desconocido se deniega de forma predeterminada: la directiva no acepta silenciosamente un tipo no reconocido.

La protección en tiempo de ejecución envuelve la directiva y expone métodos de tipo assert para un hash, un OID de firma, un algoritmo de cifrado y una fortaleza de clave. Una opción no permitida genera una infracción tipada que nombra la directiva y el elemento infractor, y detiene la operación. La ruta falla de forma cerrada: la directiva nunca se relaja a sí misma ni sustituye un algoritmo por otro más débil. En el caso de una firma RSASSA-PSS, el control de generación vincula explícitamente el resumen del mensaje: dado que todas las variantes de PSS comparten un mismo OID de firma (el hash reside en los parámetros de PSS, no en el OID), la lista de OID permitidos por sí sola no puede demostrar el resumen efectivo, por lo que el control valida que ese resumen esté aprobado por FIPS (SHA-256/384/512) y deniega de forma cerrada un token PSS cuyo resumen sea desconocido o no esté aprobado, por ejemplo SHA-1 PSS, antes de enviar cualquier operación al firmante (FIPS 186-5 §5.4(b)).

La autocomprobación de encendido ejecuta una batería de pruebas de respuesta conocida (KAT) una vez al iniciar el proceso y cubre las funciones aprobadas de hash, autenticación de mensajes, cifrado, cifrado autenticado, firma y bits aleatorios. Una prueba de respuesta conocida falla cuando la salida calculada no coincide con la respuesta conocida, según ISO/IEC 19790:2025 §7.10.4.2. Ante cualquier fallo, el módulo entra en un estado de error y rechaza los servicios criptográficos (ISO/IEC 19790:2025 §7.2.4.3). El estado de error es persistente a nivel de proceso: una vez que cualquier protección de arranque del proceso observa un error, todo el proceso permanece en modo de fallo cerrado durante el resto de su vida útil. Crear una nueva protección de arranque o una nueva directiva no permite eludirlo, y una reejecución correcta posterior de la autocomprobación no borra un error retenido: solo lo hace un reinicio del proceso (un verdadero ciclo de apagado y encendido), según ISO/IEC 19790:2025 §7.10.2. El resultado se almacena en caché durante la vida útil del proceso; hay disponible una reejecución a petición para un endpoint de administración o un comando, pero cumple la obligación de autocomprobación periódica, no la recuperación de errores.

El uso de cifrado autenticado en el marco de la directiva requiere un vector de inicialización (IV) único por clave, según NIST SP 800-38D §5.2.1.

Requisitos previos

1. Instalar NextPDF Core y el paquete Enterprise, y disponer de una licencia Enterprise activa.
2. Para afirmar un funcionamiento compatible con FIPS, configurar NextPDF con un proveedor criptográfico validado por FIPS (por ejemplo, un proveedor OpenSSL validado por FIPS) o un HSM validado por FIPS. NextPDF Enterprise realiza el ensamblaje estructural, el cálculo del resumen y la aplicación de la directiva; la primitiva subyacente se ejecuta en el límite validado que se proporciona.
3. Decidir el preajuste: strict para una aplicación alineada con FIPS 140-3, o standard cuando se requiera la interoperabilidad con AES-128-CBC.

Configuración

• Preajuste: elegir strict o standard. Strict permite únicamente AES-256-CBC; standard permite además AES-128-CBC.
• Protección: construir la protección con la directiva elegida. La protección es el límite en el que se valida cada opción criptográfica.
• Conexión de la autocomprobación: conectar la protección de arranque en el bootstrap de la aplicación para que cada proceso de trabajo ejecute su propio ciclo de autocomprobación. Cada instancia de proceso ejecuta su propia autocomprobación de encendido.

Paso a paso

1. En el bootstrap de la aplicación, ejecutar la autocomprobación de encendido a través de la protección de arranque y validar que el módulo está operativo. Detener el proceso si no lo está.
2. Construir la protección con la directiva strict o standard.
3. Antes de cada operación criptográfica, validar el hash, el OID de firma, el algoritmo de cifrado y la fortaleza de clave a través de la protección.
4. Capturar la infracción tipada, registrar un mensaje estructural y rechazar la operación: no recurrir a una opción más débil.

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;
        }
    }
}

Verificación

1. Ejecutar la autocomprobación de encendido y confirmar que informa de que está operativa. Confirmar que se ejercita cada clase de algoritmo aprobada: hash, autenticación de mensajes, cifrado, cifrado autenticado, firma y bits aleatorios.
2. Validar una opción aprobada (por ejemplo, SHA-256, RSA 2048) y confirmar que se acepta; validar una opción no permitida (por ejemplo, SHA-1, RSA 1024) y confirmar que genera una infracción tipada.
3. Inyectar un hash o una fuente de aleatoriedad deliberadamente defectuosos en la autocomprobación y confirmar que el módulo entra en el estado de error y rechaza los servicios.
4. Confirmar que un tipo de clave desconocido se deniega de forma predeterminada en lugar de aceptarse.

Seguridad y cumplimiento

• Fallo cerrado. Una opción criptográfica no permitida genera una infracción tipada y detiene la operación. La directiva nunca se relaja a sí misma ni sustituye un algoritmo por otro más débil.
• La autocomprobación rechaza ante una discrepancia. El fallo de una prueba de respuesta conocida coloca el módulo en un estado de error persistente a nivel de proceso. Todo el proceso permanece en modo de fallo cerrado; una nueva protección de arranque o directiva no puede recuperarlo, y una reejecución correcta no libera el bloqueo: solo un reinicio del proceso lo borra (ISO/IEC 19790:2025 §7.10.4.2; §7.10.2).
• Fortaleza de clave. El preajuste strict exige mínimos de RSA 2048 y curva elíptica 256, situados en los límites mínimos aceptables de NIST SP 800-131A Rev.2 §3 o por encima de ellos.
• Unicidad del IV. El uso de cifrado autenticado requiere un IV único por clave (NIST SP 800-38D §5.2.1).

Esta página está marcada como export_control_class: legal-review-required porque aborda una directiva criptográfica. Toda fuente normativa se parafrasea; no se reproduce ningún texto normativo. Se requiere la aprobación legal antes de establecer el indicador publish.

NextPDF Enterprise no es un módulo criptográfico validado por FIPS y no realiza ninguna afirmación de certificación FIPS. Funciona en un modo compatible con FIPS únicamente cuando se configura con un proveedor criptográfico validado por FIPS (por ejemplo, un proveedor OpenSSL validado por FIPS) o un HSM validado por FIPS. La directiva en modo FIPS asiste al cumplimiento; no es una certificación ni una opinión legal. Consulte a sus propios asesores de cumplimiento y jurídicos sobre sus obligaciones regulatorias.

Gestión de fallos

• Fallo de la autocomprobación en el arranque. La protección de arranque genera una excepción de estado de error del módulo. Detener el proceso; no continuar con una ruta criptográfica no verificada.
• Infracción de la directiva. La protección genera una infracción tipada que nombra la directiva y el elemento infractor. Rechazar la operación; no degradarla.
• Tipo de clave desconocido. La directiva lo deniega de forma predeterminada. Asignar el tipo de clave de forma explícita si está realmente aprobado.
• Reejecución de la autocomprobación. Hay disponible una reejecución a petición para un endpoint de administración o un comando, que cumple la obligación de autocomprobación periódica bajo demanda. No es un mecanismo de recuperación: una reejecución fallida también bloquea el proceso, y una reejecución correcta no libera un bloqueo existente. Recuperar un módulo en estado de error requiere un reinicio del proceso.

Contexto comercial

NextPDF Core incluye el firmante por software y el cifrado sin un perfil en modo FIPS. NextPDF Enterprise añade el perfil de directiva criptográfica en modo FIPS, la protección en tiempo de ejecución y la protección de autocomprobación de encendido, de modo que una implementación puede restringir las opciones criptográficas a un conjunto aprobado y fallar de forma cerrada ante una discrepancia en la autocomprobación. Puede combinarse con la firma con HSM para ejecutar la primitiva dentro de un dispositivo validado por FIPS. Comparar ediciones.

Véase también

• Seguridad — NextPDF Enterprise — la superficie de seguridad combinada de Enterprise.
• Firma con HSM — NextPDF Enterprise — custodia de claves por hardware PKCS#11.
• Firma — NextPDF Enterprise — producción a largo plazo de PAdES B-LT y B-LTA.
• Seguridad — NextPDF Core — la superficie principal de cifrado y firma.
• Modo FIPS · KAT · AEAD — términos del glosario.