GoSudaStruttura delle implementazioni FIPS 140-2 e FIPS 140-3 nella libreria crittografica standard di Go
FIPS 140 ( Federal Information Processing Standard Publication 140 )
FIPS 140 è uno standard di certificazione della sicurezza per i moduli crittografici stabilito dal NIST statunitense. Questo standard valuta se un determinato modulo o libreria crittografica soddisfi i requisiti di sicurezza definiti dal NIST. Pertanto, il superamento della certificazione FIPS 140 indica che il rispettivo modulo possiede una sicurezza ufficialmente affidabile e può essere impiegato in settori in cui la sicurezza riveste un ruolo critico, come la finanza, la sanità e la difesa.
Stabilito per la prima volta nel 1994, FIPS 140 è stato revisionato in FIPS 140-2 nel 2001 e in FIPS 140-3 nel 2019. Fino ad oggi, molti sistemi e applicazioni continuano a richiedere la certificazione FIPS 140-2 o FIPS 140-3.
FIPS 140 e i linguaggi di programmazione
Per tali ragioni, i moduli crittografici certificati FIPS 140 sono utilizzati come standard di fatto in diversi linguaggi di programmazione e ambienti. Tra i principali figurano OpenSSL, BoringSSL, LibreSSL e NSS, i quali rappresentano i moduli più ampiamente impiegati nelle applicazioni ad alta sicurezza.
La maggior parte dei moduli certificati FIPS 140 è scritta in C o C++. Di conseguenza, in linguaggi quali PHP, Python e Javascript, anziché utilizzare direttamente tali moduli, si configura l'ambiente FIPS mediante l'integrazione di moduli Provider esterni. Tuttavia, questo approccio presenta alcune limitazioni.
Problema di disallineamento delle versioni
La certificazione FIPS 140 viene concessa esclusivamente per versioni specifiche. Pertanto, per utilizzare l'ultima versione di un modulo è necessario ripetere il processo di certificazione, il che può generare un disallineamento tra la versione utilizzata dall'applicazione e quella certificata FIPS. Qualora venga impiegata una versione non autorizzata, tale ambiente non sarà più considerato conforme agli standard FIPS.
Caricamento dinamico e calo delle prestazioni
La maggior parte dei linguaggi carica e utilizza i moduli certificati FIPS 140 sotto forma di librerie dinamiche. Tale modalità può causare un calo delle prestazioni durante le fasi di inizializzazione ed esecuzione, con il rischio di ripercussioni dirette sulla stabilità complessiva dell'applicazione in caso di anomalie a runtime.
Vulnerabilità di sicurezza
Come menzionato in precedenza, in una struttura che integra moduli esterni come OpenSSL Provider, sussiste il rischio che le vulnerabilità di sicurezza di tali moduli si propagino direttamente all'applicazione. Inoltre, lo strato di comunicazione stesso tra l'applicazione e il modulo esterno costituisce una superficie di attacco aggiuntiva, rendendo necessario un livello di sicurezza separato per la sua protezione. Ciò accresce la complessità e può generare vulnerabilità impreviste.
FIPS 140 e Golang
Per questi motivi, Golang ha adottato una strategia differente. Go ha scelto di non affidarsi a strumenti esterni per la certificazione FIPS 140, optando invece per un supporto diretto all'interno della propria libreria crittografica ufficiale. Di conseguenza, gli sviluppatori non necessitano di installare o configurare alcun Provider aggiuntivo; è sufficiente utilizzare il pacchetto standard crypto attivando la modalità di certificazione FIPS (GOFIPS=1). In questo modo viene eliminato il confine di comunicazione con i moduli esterni, rafforzando la sicurezza, e la gestione risulta semplificata poiché è sufficiente distribuire un unico binario compilato in modo statico.
FIPS 140-2 e Golang
A tal fine, Golang ha integrato nel runtime di Go il modulo BoringCrypto, derivato da BoringSSL, ottenendo la certificazione FIPS 140-2. BoringCrypto può essere attivato in distribuzioni specifiche a partire dalla versione Go 1.19, consentendo alle applicazioni Go di configurare un ambiente certificato FIPS 140-2 senza la necessità di moduli esterni separati.
Tuttavia, poiché BoringCrypto si basa su OpenSSL, permane una dipendenza dal linguaggio C. Di conseguenza, le applicazioni Go non vengono compilate in binari completamente indipendenti, sussistendo il vincolo di dover distribuire contestualmente le librerie C necessarie.
FIPS 140-3 e Golang
Per superare tali limitazioni, il team di Go ha perfezionato la libreria crittografica standard esistente conformemente alle specifiche FIPS 140-3. Questo modulo migliorato ha iniziato a essere fornito in via sperimentale a partire dalla versione Go 1.21, e attualmente è in corso la valutazione per la certificazione FIPS 140-3 da parte del NIST.Elenco dei moduli in fase di valutazione NIST FIPS 140-3
Ciò dimostra la maturità della libreria crittografica di Go, consentendo a quest'ultimo di fornire un ambiente certificato FIPS 140-3 tramite un singolo binario completamente indipendente.
Inoltre, il team di Go non si è limitato a soddisfare lo standard FIPS 140-3, ma ha rafforzato autonomamente il livello di sicurezza.
Fail Fast
La modalità FIPS di Go adotta un modello di sicurezza Fail Fast, interrompendo immediatamente l'esecuzione tramite un panic nel momento in cui viene invocato un algoritmo non certificato. A differenza dei modelli basati su Provider di altri linguaggi, che lasciano margine a possibilità di fallback, ciò offre una garanzia più rigorosa e trasparente in termini di sicurezza e conformità normativa.
Hedged Signature
Lo standard FIPS 140-3 raccomanda l'adozione della metodologia RFC6979 per le firme ECDSA. Tuttavia, Go introduce ulteriormente il metodo Hedged, garantendo una difesa più robusta contro gli attacchi basati su canali collaterali che possono verificarsi durante il processo di firma.
Generatore di numeri casuali avanzato
Il generatore di numeri casuali di Go impiega un DRBG (Deterministic Random Bit Generator) in spazio utente, iniettando al contempo ulteriore entropia proveniente dal kernel del sistema operativo, generando così numeri casuali di elevata qualità sia nello spazio utente che nello spazio kernel. Tale meccanismo potenzia ulteriormente la sicurezza del generatore di numeri casuali.