Salta ai contenuti
NextPDF
getnextpdf.com

Enterprise edizione

Criterio crittografico e self-test FIPS 140-2/3

In breve

Sezione intitolata “In breve”

NextPDF Enterprise limita le scelte crittografiche che un’operazione di firma o cifratura può effettuare a un insieme approvato dai Federal Information Processing Standards (FIPS) e rifiuta qualsiasi scelta esterna a tale insieme. Un guard runtime verifica ogni hash, identificatore di algoritmo di firma, algoritmo di cifratura e robustezza della chiave prima dell’esecuzione dell’operazione. Una batteria di self-test all’avvio viene eseguita una sola volta quando il processo parte. Se un qualsiasi known-answer test fallisce, il modulo entra in uno stato di errore. Questa pagina descrive il comportamento: cosa il criterio consente, cosa il guard rifiuta, cosa copre il self-test e la posizione esplicita in materia di certificazione.

NextPDF Enterprise è uno strumento di supporto alla conformità. Non è un modulo crittografico certificato. Consultare Sicurezza e conformità per la posizione esplicita di non certificazione.

Il front matter elenca i prerequisiti, ripetuti in Prerequisiti.

Disponibilità e licenze

Sezione intitolata “Disponibilità e licenze”

Questa funzionalità è distribuita in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di livello Enterprise. Un deployment privo di tale entitlement non carica le classi della funzionalità. Confronta le edizioni e ottieni una licenza.

NextPDF Core e NextPDF Pro non forniscono un profilo in modalità FIPS. Il guard e il self-test vengono eseguiti nel processo; le verifiche del criterio e i self-test non inviano contenuti del documento fuori dall’host.

Cosa fa questa funzionalità

Sezione intitolata “Cosa fa questa funzionalità”

La funzionalità si articola in tre parti: un criterio crittografico, un guard runtime e un self-test all’avvio.

Il criterio crittografico limita le scelte crittografiche a un insieme approvato, con due preset:

  • Strict (allineato alla generazione FIPS 140-3) — hash SHA-256, SHA-384 e SHA-512; identificatori di oggetto (OID) di firma RSA ed ECDSA con tali hash; cifratura AES-256-CBC; e dimensioni minime pari a chiave RSA 2048 e curva ellittica 256.
  • Standard (allineato alla generazione FIPS 140-2) — come strict, ma consente anche AES-128-CBC per l’interoperabilità con sistemi più datati.

Per la generazione della firma, NIST SP 800-131A Rev.2 §3 accetta una chiave RSA di almeno 2048 bit e un ordine ECDSA di almeno 224 bit; i limiti minimi 2048/256 del preset strict sono pari o superiori a tali minimi. Il criterio nega per impostazione predefinita un tipo di chiave sconosciuto — non accetta silenziosamente un tipo non riconosciuto.

Il guard runtime incapsula il criterio ed espone metodi in stile assert per hash, OID di firma, algoritmo di cifratura e robustezza della chiave. Quando una scelta non è consentita, solleva una violazione tipizzata che indica il criterio e l’elemento in violazione, quindi interrompe l’operazione. Il percorso è fail-closed: il criterio non viene mai allentato e non sostituisce mai un algoritmo più debole. Per una firma RSASSA-PSS, il gate di generazione vincola esplicitamente il digest del messaggio. Ogni variante PSS condivide un unico OID di firma; l’hash risiede nei parametri PSS, non nell’OID. La sola allowlist di OID non può provare il digest effettivo, quindi il gate verifica che il digest sia approvato FIPS (SHA-256/384/512). Nega in modo fail-closed qualsiasi token PSS il cui digest sia sconosciuto o non approvato, per esempio SHA-1 PSS, prima di qualsiasi dispatch verso il signer (FIPS 186-5 §5.4(b)).

Il self-test all’avvio esegue una batteria di known-answer test (KAT) una sola volta all’avvio del processo. La batteria copre le funzioni approvate di hash, autenticazione del messaggio, cifratura, cifratura autenticata, firma e bit casuali. Secondo ISO/IEC 19790:2025 §7.10.4.2, un known-answer test fallisce quando l’output calcolato non è uguale alla risposta nota. In caso di qualsiasi fallimento, il modulo entra in uno stato di errore e rifiuta i servizi crittografici (ISO/IEC 19790:2025 §7.2.4.3). Lo stato di errore è persistente per il processo: dopo che un qualsiasi boot guard nel processo ha osservato un errore, l’intero processo rimane fail-closed per tutta la sua durata. Costruire un nuovo boot guard o criterio non può azzerarlo. Una successiva ri-esecuzione superata del self-test non azzera un errore bloccato — può farlo solo un riavvio del processo (un vero ciclo di spegnimento e riaccensione), secondo ISO/IEC 19790:2025 §7.10.2. Il risultato viene memorizzato nella cache per tutta la durata del processo; è possibile eseguire una ri-esecuzione su richiesta per un endpoint amministrativo o un comando, ma essa soddisfa l’obbligo di self-test periodico, non il ripristino dall’errore.

Il criterio richiede un vettore di inizializzazione (IV) univoco per ciascuna chiave per l’uso della cifratura autenticata, secondo NIST SP 800-38D §5.2.1.

Perché funziona così

Sezione intitolata “Perché funziona così”

La convalida FIPS si applica a un boundary specifico del modulo crittografico, non a un’applicazione che lo richiama. NextPDF applica quindi il criterio ed esegue la batteria di self-test, ma delega ogni primitiva a un provider convalidato FIPS configurato dall’utente — verifica scelte approvate anziché dichiararsi il modulo convalidato. Lo stato di errore è deliberatamente persistente per il processo: una mancata corrispondenza del self-test significa che non ci si può più fidare del modulo, quindi un nuovo guard o una successiva ri-esecuzione superata non devono azzerarlo silenziosamente, e può farlo solo un vero riavvio del processo. Ciò mantiene il fallimento onesto e verificabile anziché ripristinabile in modo silenzioso in loco. Il risultato è una funzionalità che supporta la conformità senza mai sopravvalutare ciò per cui NextPDF è certificato.

Contesto progettuale: Conformità da consegnare a un auditor.

Prerequisiti

Sezione intitolata “Prerequisiti”
  1. Installare NextPDF Core e il pacchetto Enterprise e mantenere una licenza Enterprise attiva.
  2. Per dichiarare un funzionamento compatibile FIPS, configurare NextPDF con un provider crittografico convalidato FIPS — per esempio un provider OpenSSL convalidato FIPS — o un hardware security module (HSM) convalidato FIPS. NextPDF Enterprise esegue l’assemblaggio strutturale, il calcolo del digest e l’applicazione del criterio; la primitiva sottostante viene eseguita nel boundary convalidato fornito dall’utente.
  3. Scegliere il preset: strict per un’applicazione allineata a FIPS 140-3, oppure standard quando è richiesta l’interoperabilità AES-128-CBC.

Configurazione

Sezione intitolata “Configurazione”
  • Preset — scegliere strict o standard. Strict consente solo AES-256-CBC; standard consente anche AES-128-CBC.
  • Guard — costruire il guard con il criterio scelto. Usare il guard come boundary nel quale si verifica ogni scelta crittografica.
  • Wiring del self-test — collegare il boot guard al bootstrap dell’applicazione in modo che ogni processo worker esegua il proprio ciclo di self-test. Ogni istanza di processo esegue il proprio self-test all’avvio.

Passo dopo passo

Sezione intitolata “Passo dopo passo”
  1. Al bootstrap dell’applicazione, eseguire il self-test all’avvio tramite il boot guard e verificare che il modulo sia operativo. Arrestare il processo se non lo è.
  2. Costruire il guard con il criterio strict o standard.
  3. Prima di ogni operazione crittografica, verificare tramite il guard l’hash, l’OID di firma, l’algoritmo di cifratura e la robustezza della chiave.
  4. Intercettare la violazione tipizzata, registrare un messaggio strutturato e rifiutare l’operazione. Non ripiegare su una scelta più debole.
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

Sezione intitolata “Verifica”
  1. Eseguire il self-test all’avvio e verificare che riporti lo stato operativo. Verificare che eserciti ogni classe di algoritmi approvata — hash, autenticazione del messaggio, cifratura, cifratura autenticata, firma e bit casuali.
  2. Verificare una scelta approvata, per esempio SHA-256, RSA 2048, e confermare che venga superata. Verificare una scelta non consentita, per esempio SHA-1, RSA 1024, e confermare che sollevi una violazione tipizzata.
  3. Iniettare nel self-test un hash o una sorgente di casualità deliberatamente difettosi e confermare che il modulo entri nello stato di errore e rifiuti i servizi.
  4. Confermare che un tipo di chiave sconosciuto venga negato per impostazione predefinita anziché accettato.

Sicurezza e conformità

Sezione intitolata “Sicurezza e conformità”
  • Fail-closed. Quando una scelta crittografica non è consentita, il guard solleva una violazione tipizzata e interrompe l’operazione. Il criterio non viene mai allentato e non sostituisce mai un algoritmo più debole.
  • Il self-test rifiuta in caso di mancata corrispondenza. Il fallimento di un known-answer test porta il modulo in uno stato di errore persistente per il processo. L’intero processo rimane fail-closed; un nuovo boot guard o criterio non può ripristinarlo, e una ri-esecuzione superata non rimuove il blocco. Solo un riavvio del processo lo azzera (ISO/IEC 19790:2025 §7.10.4.2; §7.10.2).
  • Robustezza della chiave. Il preset strict impone i minimi RSA 2048 e curva ellittica 256, pari o superiori ai limiti minimi accettabili di NIST SP 800-131A Rev.2 §3.
  • Univocità dell’IV. L’uso della cifratura autenticata richiede un IV univoco per ciascuna chiave (NIST SP 800-38D §5.2.1).

Questa pagina riguarda il criterio crittografico. Ogni fonte normativa è parafrasata; nessun testo normativo viene riprodotto. > NextPDF Enterprise non è un modulo crittografico convalidato FIPS e non formula alcuna dichiarazione di certificazione FIPS. Opera in modalità compatibile FIPS solo quando è configurato con un provider crittografico convalidato FIPS — per esempio un provider OpenSSL convalidato FIPS — o un hardware security module (HSM) convalidato FIPS. Il criterio in modalità FIPS supporta la conformità; non è una certificazione né un parere legale. Consultare i propri consulenti legali e di conformità per gli obblighi normativi applicabili.

Gestione dei guasti

Sezione intitolata “Gestione dei guasti”
  • Fallimento del self-test all’avvio. Il boot guard solleva un’eccezione di stato di errore del modulo. Arrestare il processo; non procedere con un percorso crittografico non verificato.
  • Violazione del criterio. Il guard solleva una violazione tipizzata che indica il criterio e l’elemento in violazione. Rifiutare l’operazione; non effettuare un downgrade.
  • Tipo di chiave sconosciuto. Il criterio lo nega per impostazione predefinita. Mappare esplicitamente il tipo di chiave solo se è effettivamente approvato.
  • Ri-esecuzione del self-test. Una ri-esecuzione è disponibile su richiesta per un endpoint amministrativo o un comando e soddisfa l’obbligo di self-test periodico su richiesta. Non è un meccanismo di ripristino: anche una ri-esecuzione fallita blocca il processo, e una ri-esecuzione superata non rimuove un blocco esistente. Il ripristino di un modulo nello stato di errore richiede un riavvio del processo.

Confine di pubblicazione

Sezione intitolata “Confine di pubblicazione”

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie di API pubblica supportata. Percorsi di namespace interni, classi helper, tabelle di meccanismi, nomi di file di runbook e prefissi dei ticket sono fuori ambito.

Vedere anche

Sezione intitolata “Vedere anche”