Enterprise edición

Seguridad — HSM, PKCS#11 y modo FIPS

De un vistazo

NextPDF Enterprise añade una ruta de firma con token de hardware PKCS#11 y una política criptográfica en modo FIPS sobre la superficie de seguridad de Core y Pro. Esta página indica el comportamiento, las fronteras y la postura explícita de certificación FIPS y de custodia de claves.

Disponibilidad y licencias

Esta capacidad se distribuye en NextPDF Enterprise (nextpdf/enterprise) y se activa con un envoltorio de licencia de nivel Enterprise. Un despliegue sin esa habilitación no carga las clases de la capacidad. Comparar ediciones y obtener una licencia.

Descripción conceptual

La superficie de seguridad de Enterprise tiene tres partes: un firmante de token de hardware, una política criptográfica en modo FIPS y una protección de autodiagnóstico de encendido.

El firmante de token de hardware adapta un token PKCS#11 —una tarjeta inteligente, un dispositivo USB o un HSM conectado a la red—. El firmante localiza el certificado y la clave privada en el token por etiqueta. A continuación, pide al token que calcule la firma. La clave privada no sale de la frontera del token; la operación se ejecuta dentro del token. La operación de firma del token, la sesión y el inicio de sesión del usuario siguen PKCS#11 v3.1 §5. La ruta HSM necesita la extensión de PHP ext-pkcs11. Esa extensión no forma parte de PHP estándar. Instálela por separado. Use la comprobación de disponibilidad antes de construir el firmante.

La política criptográfica en modo FIPS restringe las opciones criptográficas a un conjunto aprobado. Tiene dos preajustes. El preajuste estricto permite hashes SHA-256, SHA-384 y SHA-512; OID de firma RSA y ECDSA con esos hashes; cifrado AES-256-CBC; y tamaños mínimos de clave de RSA 2048 y EC 256. El preajuste estándar es el mismo, pero también permite AES-128-CBC para interoperabilidad más antigua. Una protección de tiempo de ejecución envuelve la política. La protección comprueba cada hash, OID de firma, algoritmo de cifrado y fortaleza de clave antes de que se ejecute la operación. Una opción no permitida genera una violación tipada y detiene la operación. La ruta falla de forma cerrada: la política nunca se relaja a sí misma y nunca sustituye por un algoritmo más débil. La longitud mínima de clave RSA sigue NIST SP 800-131A Rev.2 §3. El emparejamiento de curva y hash de ECDSA sigue FIPS 186-5 §6.1.1.

La protección de autodiagnóstico de encendido ejecuta una batería de pruebas de respuesta conocida una vez al inicio del proceso. La batería cubre las funciones aprobadas de hash, MAC, cifrado, firma y bits aleatorios. Si alguna prueba falla, la protección FIPS de Enterprise entra en un estado de error y rechaza los servicios criptográficos hasta el restablecimiento. El resultado se almacena en caché durante toda la vida del proceso; hay disponible una nueva ejecución bajo demanda. La categoría de autodiagnóstico y el desencadenante de prueba condicional siguen ISO/IEC 19790:2025 §7.10 y §7.10.3.

Por qué funciona así

La decisión determinante es mantener la clave privada dentro de la frontera del token y hacer que la política criptográfica falle de forma cerrada. Un firmante que pudiera exportar una clave, o degradar silenciosamente a un algoritmo más débil, echaría por tierra la garantía que un HSM existe para proporcionar. Por eso el firmante pide al token que calcule la firma en el sitio, y la protección de modo FIPS rechaza cualquier hash, OID o fortaleza de clave fuera del preajuste aprobado antes de que se ejecute la operación. El autodiagnóstico de encendido extiende la misma postura al arranque: un módulo no verificado rechaza el servicio en lugar de firmar con primitivas no probadas. El resultado es una frontera sobre la que se puede razonar, donde la custodia de claves es propiedad del operador y del token, no de este software.

Contexto de diseño: firma respaldada por HSM.

Superficie de la API

Superficie pública	Tipo	Propósito	Estabilidad	Desde
Firmante de token PKCS#11	clase (implementa la interfaz de Core `HsmSignerInterface`)	Firmar con un token PKCS#11; la clave permanece en el token	estable	1.0.0
Política criptográfica FIPS	clase (implementa la interfaz de Core `CryptoPolicyInterface`)	Un preajuste de algoritmos permitidos y fortaleza de clave	estable	1.9.0
Protección de modo FIPS	clase	Comprobar que un hash, OID de firma, algoritmo de cifrado o fortaleza de clave está permitido	estable	1.9.0
Protección de arranque FIPS	clase	Ejecutar y almacenar en caché el autodiagnóstico de encendido; comprobar que el módulo está operativo	estable	3.2.0
Firmante CLI / engine de OpenSSL	clase (implementa `HsmSignerInterface`)	Firmar a través de un engine de OpenSSL o de la CLI de OpenSSL para tokens respaldados por engine	estable	1.0.0

El constructor del firmante de token toma la ruta de la biblioteca PKCS#11, el número de ranura, el PIN del token, la etiqueta del certificado y una etiqueta de clave independiente opcional. El parámetro del PIN está marcado como sensible; no se registra ni se serializa. El firmante también expone el certificado del firmante y la cadena de certificados en forma DER. El contrato autoritativo de parámetros y tipos es la referencia de API publicada del paquete nextpdf/enterprise; trate esa referencia —no esta página— como el contrato.

Ejemplo de código — Inicio rápido

composer require nextpdf/core
composer require nextpdf/enterprise:^3

use NextPDF\Enterprise\Security\Fips\FipsCryptoPolicy;
use NextPDF\Enterprise\Security\Fips\FipsModeGuard;

$guard = new FipsModeGuard(FipsCryptoPolicy::strict());

// Throws a typed FIPS violation if the algorithm is not approved.
$guard->assertHashAllowed('sha256');
$guard->assertKeyStrengthAllowed('rsa', 2048);

Ejemplo de código — Producción

use NextPDF\Enterprise\Security\Fips\FipsBootGuard;
use NextPDF\Enterprise\Security\Fips\FipsSelfTest;

// At application bootstrap (one self-test cycle per worker process):
$bootGuard = new FipsBootGuard(new FipsSelfTest());
$bootGuard->assertOperational(); // throws on a known-answer-test failure
$container->set(FipsBootGuard::class, $bootGuard);

// The PKCS#11 token signer is only available when ext-pkcs11 is loaded.
// Check availability before you construct the signer. The PIN is a secret;
// supply it from your secret manager, never from source or logs.

La lista completa de argumentos del constructor, los tipos de excepción y la construcción del firmante de token PKCS#11 están documentados en la referencia detallada de seguridad de Enterprise.

Casos límite y trampas

El constructor del firmante de token PKCS#11 genera una excepción de operación tipada cuando ext-pkcs11 no está cargado. Compruebe primero la disponibilidad.
El firmante de token almacena en caché un módulo PKCS#11 por ruta de biblioteca por proceso. Esto satisface la regla de «inicializar una vez por módulo» de la interfaz del token.
Los mecanismos ECDSA del token devuelven una firma en bruto. El firmante la convierte a la forma codificada en DER para la interoperabilidad con PDF y OpenSSL.
La protección FIPS deniega un tipo de clave desconocido de forma predeterminada. Un tipo de clave no reconocido no se acepta silenciosamente.
La ruta de firma poscuántica es experimental, opcional y está desactivada de manera predeterminada. Los perfiles estándar de archivado a largo plazo de PAdES aún no reconocen las suites poscuánticas. No la active para firmas AdES de producción.

Rendimiento

Las comprobaciones de la protección FIPS son búsquedas en mapa hash de tiempo constante. El autodiagnóstico de encendido se ejecuta una vez por proceso; su costo se amortiza durante la vida del proceso, no por llamada de firma. Una operación de firma PKCS#11 añade un ciclo de ida y vuelta al token. Un HSM conectado a la red añade la latencia de red de ese ciclo de ida y vuelta.

Notas de seguridad

La ruta de firma falla de forma cerrada. Un fallo de primitiva o una laguna de política genera una excepción tipada. La ruta nunca se degrada silenciosamente a un algoritmo más débil.
El parámetro del PIN del token está marcado como sensible. No se registra ni se serializa.
La clave privada de un token PKCS#11 permanece en el token. La operación de firma se ejecuta dentro de la frontera del token.
El autodiagnóstico de encendido pone la protección FIPS de Enterprise en un estado de error ante una discrepancia de prueba de respuesta conocida y rechaza los servicios criptográficos hasta el restablecimiento.
El uso de AES-GCM requiere un vector de inicialización único por clave, según NIST SP 800-38D §5.

Residencia de datos y mitigaciones de PII

El código de firma y de política FIPS se ejecuta en proceso. Ningún contenido del documento sale del host para la comprobación de la política FIPS ni para el autodiagnóstico de encendido. Un token PKCS#11 recibe los datos a firmar, no contenido del documento no relacionado. Un HSM conectado a la red recibe esos datos a través del canal de red que usted configure. El material de claves permanece dentro de la frontera del token o del HSM.

Telemetría segura y depuración de registros

El PIN del token es un parámetro de constructor sensible y se excluye de los registros y de la serialización. No añada el PIN, la etiqueta del token ni el material de claves a sus propios registros de aplicación. Trate todas las credenciales del token como secretos en su política de registro y rastreo.

Modelo de amenazas

Esto es una frontera criptográfica, por lo que el modelo de amenazas es explícito. Los datos a firmar se entregan al token; el token guarda la clave. Un error del token o del HSM genera una excepción tipada; el firmante no produce un resultado sin firmar ni parcialmente firmado. La protección de claves depende del token o del HSM, del despliegue y del operador — no de este software por sí solo. Consulte la frontera de despliegue.

Conformidad

El modelo de autodiagnóstico de encendido y condicional se alinea con ISO/IEC 19790:2025 §7.10 y §7.10.3.
La longitud mínima de clave de firma RSA se alinea con NIST SP 800-131A Rev.2 §3.
El emparejamiento aprobado de curva y hash de ECDSA se alinea con FIPS 186-5 §6.1.1.
La operación de firma del token PKCS#11 y el inicio de sesión se alinean con PKCS#11 v3.1 §5.
La responsabilidad de protección de claves se alinea con NIST SP 800-57 Part 1 Rev.5 §5.5.2.
La unicidad del vector de inicialización de AES-GCM se alinea con NIST SP 800-38D §5.

Toda fuente normativa está parafraseada. No se reproduce ningún texto normativo en esta página. Esta página trata sobre firma criptográfica.

Comportamiento en modo FIPS

La política de modo FIPS restringe las opciones criptográficas al conjunto aprobado descrito anteriormente. Cuando se configura contra un proveedor de OpenSSL validado por FIPS, la primitiva subyacente se ejecuta en esa frontera validada. NextPDF Enterprise por sí mismo realiza el ensamblaje estructural, el cálculo del resumen y la aplicación de la política.

NextPDF Enterprise no es un módulo criptográfico validado por FIPS y no hace ninguna declaración de certificación FIPS. NextPDF Enterprise opera en un modo compatible con FIPS solo cuando se configura con un proveedor criptográfico validado por FIPS —por ejemplo, un proveedor de OpenSSL validado por FIPS— o un HSM validado por FIPS. La política de modo FIPS asiste al cumplimiento; no es una certificación.

Frontera de edición

NextPDF Core incluye el firmante por software, el consumo de marcas de tiempo RFC 3161, la validación de ruta RFC 5280 y la comprobación de revocación OCSP y CRL. Core produce los niveles PAdES B-B y B-T. NextPDF Pro añade enmascaramiento, detección de PII en la capa de texto, firma secuencial multiparte y estrategias de firma remota y de KMS en la nube (AWS KMS, GCP Cloud KMS, Azure Key Vault). NextPDF Pro no proporciona una ruta de token de hardware PKCS#11 y no proporciona un perfil de política criptográfica en modo FIPS. El firmante de token de hardware PKCS#11, el perfil de política criptográfica en modo FIPS, la protección de autodiagnóstico de encendido y el productor PAdES B-LT y B-LTA se incluyen únicamente en el paquete nextpdf/enterprise. Un despliegue sin la habilitación de Enterprise no carga las clases de Enterprise.

Alternativa de Pro

En un despliegue solo con Pro, la ruta de firma respaldada por hardware y por la nube compatible es la estrategia de KMS en la nube de Pro: un KMS en la nube o un KMS respaldado por HSM guarda la clave, y Pro envía el resumen de los atributos firmados, no el documento, al proveedor. Pro proporciona integración con KMS, no la fábrica de tokens PKCS#11 de Enterprise ni el perfil de modo FIPS. Una configuración que solicita B-LT, B-LTA, un token PKCS#11 o el perfil de modo FIPS en un despliegue solo con Pro falla de forma cerrada con un mensaje que nombra el componente de Enterprise ausente. Consulte Security — NextPDF Pro para la superficie de firma de Pro.

Alternativa de Core

En un despliegue solo con Core, el firmante por software produce PAdES B-B y B-T con una clave local o una clave suministrada a través del contrato de estrategia de firma de Core. Core no tiene ruta de token de hardware ni perfil de modo FIPS. Consulte Security — NextPDF Core.

Nota sobre la frontera de Enterprise

La integración del token PKCS#11, su asignación de mecanismos y su gestión de sesión se describen únicamente a nivel de comportamiento. La tabla interna de asignación de mecanismos, la lógica interna de recuperación de sesión y el material de migración poscuántica quedan fuera del alcance de la superficie pública y no se reproducen aquí.

Frontera de despliegue

NextPDF Enterprise se integra con un token PKCS#11, un HSM o un KMS. No almacena, genera ni garantiza por sí mismo la seguridad de la clave de firma. La seguridad de la clave depende del token, el HSM o el KMS, del despliegue y del operador — no de NextPDF Enterprise por sí solo. El operador es responsable del aprovisionamiento del token, del manejo del PIN, de la configuración de la ranura, de la protección de red de un HSM conectado a la red y de la configuración de confianza. La responsabilidad de protección de claves sigue NIST SP 800-57 Part 1 Rev.5 §5.5.2. NextPDF Enterprise no expone el manejo del PIN del token, los detalles internos de configuración de la ranura ni el material de credenciales del proveedor en esta documentación.

Frontera de cumplimiento legal

Trata sobre firma criptográfica e integración con módulos de seguridad de hardware. La política de modo FIPS es una función de asistencia al cumplimiento. No es una opinión legal ni una certificación. Consulte a sus propios asesores de cumplimiento y legales sobre sus obligaciones regulatorias.

Frontera de publicación

Esta página documenta únicamente el comportamiento observable desde fuera y la superficie pública de API compatible. Las rutas internas de espacio de nombres, las clases auxiliares, las tablas de mecanismos, los nombres de archivo de runbook y los prefijos de ticket quedan fuera del alcance.

Contrato de comportamiento

La protección FIPS comprueba cada hash, OID de firma, algoritmo de cifrado y fortaleza de clave frente al preajuste activo y genera una violación tipada ante una opción no permitida.
El autodiagnóstico de encendido se ejecuta una vez por proceso y rechaza los servicios criptográficos ante un fallo de prueba de respuesta conocida hasta el restablecimiento.
El firmante de token PKCS#11 requiere ext-pkcs11; genera una excepción de operación tipada cuando la extensión está ausente.
La ruta de firma falla de forma cerrada y nunca sustituye por un algoritmo más débil.

Véase también

Security — NextPDF Enterprise (referencia detallada)
Security — NextPDF Pro
Signature — NextPDF Enterprise
Accelerator — NextPDF Enterprise
Security — NextPDF Core
PAdES · HSM · PKCS#11 · Modo FIPS · KMS — términos del glosario.