Enterprise edizione

Convalida HSM e FIPS

In sintesi

La firma di NextPDF Enterprise si collega ai moduli di sicurezza hardware (HSM) tramite PKCS#11 ed esegue la crittografia con moduli convalidati secondo i Federal Information Processing Standards (FIPS). La chiave privata alla base di una firma rimane all’interno di hardware certificato e la crittografia viene eseguita in un modulo convalidato in modo indipendente. Si ottengono così le due proprietà di garanzia su cui si basano i flussi di lavoro di firma regolamentati e a elevato valore.

Questa pagina offre agli acquirenti prove e garanzie. Illustra gli standard seguiti dall’integrazione di firma, le classi di dispositivi con cui funziona, l’approccio all’interoperabilità e le prove di convalida che è possibile richiedere prima di procedere. Non descrive i dettagli implementativi. Per una panoramica della conformità agli standard, vedere Conformità e aderenza agli standard.

Supporto dei moduli di sicurezza hardware

Un modulo di sicurezza hardware è un dispositivo certificato che genera e custodisce le chiavi private ed esegue per conto dell’utente le operazioni crittografiche, in modo che il materiale delle chiavi non lasci mai il dispositivo. NextPDF Enterprise firma tramite questi dispositivi utilizzando PKCS#11. PKCS#11 è l’interfaccia di programmazione standard ampiamente adottata, nota anche come Cryptoki, per i dispositivi che custodiscono informazioni crittografiche ed eseguono funzioni crittografiche. Definisce inoltre come vengono gestite le chiavi su un token crittografico, il che consente a un’unica integrazione standard di raggiungere un’ampia gamma di dispositivi.

Poiché l’integrazione segue PKCS#11 anziché un’interfaccia specifica del fornitore, funziona con le classi comuni di custodia hardware delle chiavi:

HSM di rete e appliance usati per centralizzare la custodia delle chiavi per un insieme di servizi di firma.
Servizi HSM nel cloud che espongono un’interfaccia PKCS#11 alle applicazioni eseguite in un ambiente gestito.
Smart card e token di firma utilizzati quando un firmatario custodisce la chiave su un dispositivo personale.

La custodia hardware delle chiavi si abbina al profilo di firma per l’archiviazione a lungo termine, in modo che una firma provenga da una chiave protetta e rimanga verificabile per anni. Vedere Conformità e aderenza agli standard per i profili di firma e i relativi standard.

Crittografia convalidata FIPS

Per le distribuzioni con requisiti di garanzia crittografica, NextPDF Enterprise opera con moduli crittografici convalidati FIPS. FIPS 140-3 è lo standard statunitense per i requisiti di sicurezza dei moduli crittografici. Sostituisce FIPS 140-2 ed è allineato allo standard internazionale ISO/IEC 19790.

La convalida è un processo indipendente, non una dichiarazione del fornitore. La conformità di un modulo ai requisiti di sicurezza dei moduli crittografici viene stabilita mediante test accreditati rispetto a un insieme definito di asserzioni. L’autorità di convalida elenca i moduli convalidati. Quando si utilizza un modulo convalidato, la crittografia alla base di una firma viene eseguita all’interno di hardware che ha superato tale processo indipendente, anziché in codice non verificato.

NextPDF Enterprise non rilascia una propria convalida FIPS; opera con moduli convalidati affinché la firma erediti la loro garanzia. Il modulo applicabile dipende dall’hardware o dal servizio cloud distribuito.

Perché funziona così

L’integrazione si rivolge all’interfaccia standard PKCS#11, non a un’API di un fornitore. Un’unica integrazione standard raggiunge quindi come classe gli HSM di rete, i servizi di chiavi nel cloud, le smart card e i token di firma. NextPDF opera con moduli convalidati FIPS anziché rilasciare una propria convalida. La convalida è associata a un modulo crittografico, non al software che lo richiama, quindi ereditare la garanzia di un modulo è la posizione onesta e duratura. La custodia delle chiavi si ferma al confine del dispositivo e la garanzia che un acquirente conferma è la convalida pubblicata del modulo presso l’autorità di convalida. Questo mantiene il percorso di firma conforme agli standard e indipendente dal fornitore, in modo che una firma provenga da una chiave protetta e rimanga verificabile in modo indipendente.

Approfondimento progettuale: Firma con supporto HSM.

Interoperabilità e prove di convalida

NextPDF Enterprise è progettato per interoperare con hardware conforme agli standard, non con un singolo fornitore. L’approccio all’interoperabilità è il seguente:

Interfaccia standard. La firma raggiunge l’hardware tramite lo standard PKCS#11, quindi i dispositivi con un’interfaccia conforme sono supportati come classe.
Moduli convalidati. La crittografia viene eseguita con moduli convalidati FIPS la cui convalida è stabilita in modo indipendente.
Firme basate su standard. Le firme prodotte seguono i profili di base PDF Advanced Electronic Signatures (PAdES), compreso il livello di archiviazione a lungo termine per una verificabilità duratura. Vedere Conformità e aderenza agli standard.

Se si è un acquirente o un revisore e occorre confermarlo prima di procedere, NextPDF può fornire prove su richiesta, tra cui:

Le classi di moduli di sicurezza hardware rispetto alle quali l’integrazione di firma viene testata e l’approccio all’interoperabilità per il dispositivo di destinazione.
I moduli convalidati FIPS in uso e le modalità per confermarne la convalida presso l’autorità di convalida.
I profili di firma prodotti e il modo in cui un verificatore indipendente li convalida.

Richiedere un report di convalida

Per richiedere un report di convalida o discutere i requisiti hardware e di garanzia prima dell’acquisto, contattare il reparto vendite tramite il portale delle licenze. Indicare il modulo di sicurezza hardware o il servizio di chiavi nel cloud di destinazione e il livello di garanzia FIPS. Il requisito verrà mappato sulle classi di dispositivi supportate e sulle prove di convalida disponibili per esso.

Ambito di pubblicazione

Questa pagina documenta esclusivamente il comportamento osservabile esternamente e la superficie dell’API pubblica supportata. I percorsi dei namespace interni, le classi helper, le tabelle dei meccanismi, i nomi dei file dei runbook e i prefissi dei ticket sono fuori ambito.