Política de criptografia e autoteste FIPS 140-2/3

Visão geral

O NextPDF Enterprise restringe as escolhas criptográficas que uma operação de assinatura ou criptografia pode fazer a um conjunto aprovado pelos Federal Information Processing Standards (FIPS) e recusa qualquer escolha fora desse conjunto. Uma guarda em tempo de execução verifica cada hash, identificador de algoritmo de assinatura, algoritmo de criptografia e força de chave antes que a operação seja executada. Uma bateria de autoteste de inicialização (power-on) é executada uma vez quando o processo é iniciado. Se qualquer teste de resposta conhecida (known-answer) falhar, o módulo entra em estado de erro. Esta página descreve esse comportamento: o que a política permite, o que a guarda recusa, o que o autoteste cobre e a posição explícita quanto à certificação.

O NextPDF Enterprise ajuda na conformidade. Ele não é um módulo criptográfico certificado. Consulte Segurança e conformidade para ver a posição explícita de não certificação.

O front matter lista os pré-requisitos, que também aparecem em Pré-requisitos.

Edição e licenciamento

O perfil de política criptográfica em modo FIPS, a guarda em tempo de execução e a guarda de autoteste de inicialização (power-on) são fornecidos pelo pacote nextpdf/enterprise e exigem o sinalizador de recurso de licença enterprise. O NextPDF Core e o NextPDF Pro não fornecem um perfil em modo FIPS. A guarda e o autoteste são executados no próprio processo; as verificações de política e os autotestes não enviam conteúdo do documento para fora do host. Comparar edições.

O que este recurso faz

O recurso tem três partes: uma política de criptografia, uma guarda em tempo de execução e um autoteste de inicialização (power-on).

A política de criptografia limita as escolhas criptográficas a um conjunto aprovado, com duas predefinições:

• Strict (alinhada com a geração FIPS 140-3) — hashes SHA-256, SHA-384 e SHA-512; identificadores de objeto (OIDs) de assinatura RSA e ECDSA com esses hashes; criptografia AES-256-CBC; e tamanhos mínimos de chave de RSA 2048 e curva elíptica 256.
• Standard (alinhada com a geração FIPS 140-2) — equivale à strict e também permite AES-128-CBC para interoperabilidade com sistemas mais antigos.

Para a geração de assinaturas, o NIST SP 800-131A Rev.2 §3 aceita uma chave RSA de pelo menos 2048 bits e uma ordem ECDSA de pelo menos 224 bits; os pisos 2048/256 da predefinição strict atingem ou excedem esses mínimos. A política nega, por padrão, um tipo de chave desconhecido — ela não aceita silenciosamente um tipo não reconhecido.

A guarda em tempo de execução envolve a política e expõe métodos no estilo assert para hash, OID de assinatura, algoritmo de criptografia e força de chave. Quando uma escolha não é permitida, ela levanta uma violação tipada que identifica a política e o item infrator e, em seguida, interrompe a operação. O caminho falha de forma fechada: a política nunca se flexibiliza e nunca substitui por um algoritmo mais fraco. Para uma assinatura RSASSA-PSS, o portão de geração vincula explicitamente o digest da mensagem. Toda variante PSS compartilha um único OID de assinatura; o hash fica nos parâmetros PSS, não no OID. Uma lista de permissões de OID, por si só, não comprova o digest efetivo; por isso, o portão verifica se o digest é aprovado pela FIPS (SHA-256/384/512). Ele nega, falhando de forma fechada, qualquer token PSS cujo digest seja desconhecido ou não aprovado, por exemplo SHA-1 PSS, antes de qualquer despacho ao signatário (FIPS 186-5 §5.4(b)).

O autoteste de inicialização (power-on) executa uma bateria de testes de resposta conhecida (known-answer test, KAT) uma vez no início do processo. A bateria cobre as funções aprovadas de hash, autenticação de mensagem, criptografia, criptografia autenticada, assinatura e geração de bits aleatórios. Conforme a ISO/IEC 19790:2025 §7.10.4.2, um teste de resposta conhecida falha quando a saída calculada não é igual à resposta conhecida. Em caso de qualquer falha, o módulo entra em estado de erro e recusa serviços criptográficos (ISO/IEC 19790:2025 §7.2.4.3). O estado de erro fica fixo ao processo: depois que qualquer guarda de inicialização no processo observa um erro, todo o processo continua falhando de forma fechada durante todo o seu tempo de vida. Construir uma nova guarda de inicialização ou política não limpa esse estado. Uma reexecução posterior do autoteste com aprovação não limpa um erro travado — apenas a reinicialização do processo (um verdadeiro ciclo de energia) o faz, conforme a ISO/IEC 19790:2025 §7.10.2. O resultado é armazenado em cache durante o tempo de vida do processo; você pode executar uma reexecução sob demanda para um endpoint administrativo ou um comando, mas ela atende à obrigação de autoteste periódico, não à recuperação de erro.

A política exige um vetor de inicialização (IV) único por chave ao usar criptografia autenticada, conforme o NIST SP 800-38D §5.2.1.

Pré-requisitos

1. Instale o NextPDF Core e o pacote Enterprise, e mantenha uma licença Enterprise ativa.
2. Para reivindicar operação compatível com FIPS, configure o NextPDF com um provedor criptográfico validado pela FIPS — por exemplo, um provedor OpenSSL validado pela FIPS — ou um módulo de segurança de hardware (HSM) validado pela FIPS. O NextPDF Enterprise realiza a montagem estrutural, o cálculo do digest e a aplicação da política; a primitiva subjacente é executada dentro do limite validado que você fornece.
3. Escolha a predefinição: strict para aplicação alinhada à FIPS 140-3, ou standard quando a interoperabilidade com AES-128-CBC for necessária.

Configuração

• Predefinição — escolha strict ou standard. A strict permite apenas AES-256-CBC; a standard também permite AES-128-CBC.
• Guarda — construa a guarda com a política escolhida. Use a guarda como o limite em que você verifica cada escolha criptográfica.
• Conexão do autoteste — conecte a guarda de inicialização ao bootstrap da aplicação para que cada processo de trabalho execute o próprio ciclo de autoteste. Cada instância de processo executa o próprio autoteste de inicialização (power-on).

Passo a passo

1. No bootstrap da aplicação, execute o autoteste de inicialização (power-on) por meio da guarda de inicialização e verifique se o módulo está operacional. Interrompa o processo se ele não estiver.
2. Construa a guarda com a política strict ou standard.
3. Antes de cada operação criptográfica, verifique o hash, o OID de assinatura, o algoritmo de criptografia e a força da chave por meio da guarda.
4. Capture a violação tipada, registre uma mensagem estrutural e recuse a operação. Não recorra a uma escolha mais fraca.

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

Verificação

1. Execute o autoteste de inicialização (power-on) e confirme se ele informa que está operacional. Confirme que ele exercita todas as classes de algoritmo aprovadas — hash, autenticação de mensagem, criptografia, criptografia autenticada, assinatura e geração de bits aleatórios.
2. Verifique uma escolha aprovada, por exemplo SHA-256, RSA 2048, e confirme que ela é aceita. Verifique uma escolha não permitida, por exemplo SHA-1, RSA 1024, e confirme que ela levanta uma violação tipada.
3. Injete um hash ou uma fonte aleatória deliberadamente defeituosos no autoteste e confirme que o módulo entra em estado de erro e recusa serviços.
4. Confirme que um tipo de chave desconhecido é negado por padrão, em vez de aceito.

Segurança e conformidade

• Falha de forma fechada. Quando uma escolha criptográfica não é permitida, a guarda levanta uma violação tipada e interrompe a operação. A política nunca se flexibiliza e nunca substitui por um algoritmo mais fraco.
• O autoteste recusa em caso de divergência. Uma falha no teste de resposta conhecida coloca o módulo em um estado de erro fixo ao processo. Todo o processo permanece falhando de forma fechada; uma nova guarda de inicialização ou política não consegue recuperá-lo, e uma reexecução com aprovação não libera a trava. Apenas a reinicialização do processo a limpa (ISO/IEC 19790:2025 §7.10.4.2; §7.10.2).
• Força da chave. A predefinição strict impõe mínimos de RSA 2048 e curva elíptica 256, que atingem ou excedem os pisos aceitáveis do NIST SP 800-131A Rev.2 §3.
• Unicidade do IV. O uso de criptografia autenticada exige um IV único por chave (NIST SP 800-38D §5.2.1).

Esta página está marcada como export_control_class: legal-review-required porque trata de política criptográfica. Toda fonte normativa é parafraseada; nenhum texto normativo é reproduzido. A aprovação jurídica é necessária antes que o sinalizador publish seja definido.

O NextPDF Enterprise não é um módulo criptográfico validado pela FIPS e não faz nenhuma reivindicação de certificação FIPS. Ele opera em modo compatível com FIPS somente quando você o configura com um provedor criptográfico validado pela FIPS — por exemplo, um provedor OpenSSL validado pela FIPS — ou um módulo de segurança de hardware (HSM) validado pela FIPS. A política em modo FIPS ajuda na conformidade; ela não é uma certificação nem uma opinião jurídica. Consulte seus próprios assessores de conformidade e jurídicos sobre as suas obrigações regulatórias.

Tratamento de falhas

• Falha no autoteste durante a inicialização. A guarda de inicialização levanta uma exceção de estado de erro do módulo. Interrompa o processo; não prossiga por um caminho criptográfico não verificado.
• Violação de política. A guarda levanta uma violação tipada que identifica a política e o item infrator. Recuse a operação; não faça downgrade.
• Tipo de chave desconhecido. A política o nega por padrão. Mapeie o tipo de chave explicitamente apenas se ele for genuinamente aprovado.
• Reexecução do autoteste. Uma reexecução está disponível sob demanda para um endpoint administrativo ou um comando, atendendo à obrigação de autoteste periódico sob demanda. Ela não é um mecanismo de recuperação: uma reexecução que falha também trava o processo, e uma reexecução aprovada não libera uma trava existente. Recuperar um módulo em estado de erro exige a reinicialização do processo.

Contexto comercial

O NextPDF Core fornece o signatário por software e a criptografia sem um perfil em modo FIPS. O NextPDF Enterprise adiciona o perfil de política criptográfica em modo FIPS, a guarda em tempo de execução e a guarda de autoteste de inicialização (power-on), para que você possa restringir as escolhas criptográficas a um conjunto aprovado e falhar de forma fechada em caso de divergência no autoteste. Combine-o com assinatura com HSM para executar a primitiva dentro de um dispositivo validado pela FIPS. Comparar edições.

Veja também

• Segurança — NextPDF Enterprise — os controles de segurança Enterprise em conjunto.
• Assinatura com HSM — NextPDF Enterprise — custódia de chaves em hardware Public-Key Cryptography Standards #11 (PKCS#11).
• Assinatura — NextPDF Enterprise — o produtor de longo prazo de PDF Advanced Electronic Signatures (PAdES) B-LT e B-LTA.
• Segurança — NextPDF Core — a superfície de criptografia e assinatura do core.
• modo FIPS · KAT · criptografia autenticada (AEAD) — termos do glossário.