Certificazione FIPS 140 e Golang
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 particolare modulo o libreria crittografica soddisfa i requisiti di sicurezza definiti dal NIST. Pertanto, superare la certificazione FIPS 140 significa che il modulo in questione possiede una sicurezza ufficialmente affidabile e può essere utilizzato in settori critici per la sicurezza come la finanza, la sanità e la difesa.
Il FIPS 140 è stato originariamente istituito nel 1994, poi rivisto come FIPS 140-2 nel 2001 e come FIPS 140-3 nel 2019. Ancora oggi, molti sistemi e applicazioni richiedono la certificazione FIPS 140-2 o FIPS 140-3.
FIPS 140 e Linguaggi di Programmazione
Per queste ragioni, i moduli crittografici certificati FIPS 140 sono utilizzati come standard de facto in vari linguaggi e ambienti di programmazione. Tra i più rappresentativi figurano OpenSSL, BoringSSL, LibreSSL e NSS, che sono i moduli più ampiamente utilizzati nelle applicazioni critiche per la sicurezza.
La maggior parte dei moduli certificati FIPS 140 sono scritti in C o C++. Per questo motivo, linguaggi come PHP, Python e Javascript non utilizzano direttamente questi moduli, ma configurano l'ambiente FIPS collegandosi tramite moduli Provider esterni. Tuttavia, questo approccio presenta alcune limitazioni.
Problema di disallineamento delle versioni
La certificazione FIPS 140 è concessa solo per una versione specifica. Pertanto, per utilizzare la versione più recente di un modulo, è necessario ripetere il processo di certificazione, e durante questo processo può verificarsi un disallineamento di versione tra il modulo utilizzato dall'applicazione e il modulo certificato FIPS. Se si utilizza una versione non autorizzata, l'ambiente non sarà più considerato un ambiente certificato FIPS.
Caricamento dinamico e degrado delle prestazioni
La maggior parte dei linguaggi carica e utilizza i moduli certificati FIPS 140 come librerie dinamiche. Questo approccio può causare un degrado delle prestazioni durante l'inizializzazione e l'esecuzione, e in caso di problemi a runtime, esiste il rischio di un impatto diretto sulla stabilità complessiva dell'applicazione.
Vulnerabilità di sicurezza
Come menzionato in precedenza, in una struttura che interconnette moduli esterni come OpenSSL Provider, esiste il rischio che le vulnerabilità di sicurezza di tali moduli si propaghino direttamente all'applicazione. Inoltre, il livello di comunicazione tra l'applicazione e i moduli esterni diventa di per sé una superficie di attacco aggiuntiva, rendendo necessario un livello di sicurezza separato per proteggerla. Ciò può aumentare la complessità e causare vulnerabilità impreviste.
FIPS 140 e Golang
Per queste ragioni, Golang ha adottato una strategia diversa. Go ha scelto di supportare direttamente la certificazione FIPS 140 all'interno della libreria crittografica ufficiale, senza dipendere da strumenti esterni. Pertanto, gli sviluppatori non devono installare o configurare Provider separati; è sufficiente attivare la modalità certificata FIPS (GOFIPS=1) pur continuando a utilizzare il pacchetto crypto standard. Questo processo elimina i confini di comunicazione con i moduli esterni, rafforzando la sicurezza, e semplifica le operazioni poiché è sufficiente distribuire un unico binario compilato staticamente.
FIPS 140-2 e Golang
A tal fine, Golang ha integrato il modulo BoringCrypto, derivato da BoringSSL, nel runtime di Go per ottenere 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 moduli esterni separati.
Tuttavia, poiché BoringCrypto è basato su OpenSSL, esiste ancora una dipendenza dal linguaggio C. Pertanto, le applicazioni Go non venivano compilate come binari completamente indipendenti, e vi era la limitazione di dover distribuire anche le librerie C necessarie.
FIPS 140-3 e Golang
Il team di Go ha superato queste limitazioni migliorando la libreria crypto standard di Go per conformarsi alle specifiche FIPS 140-3. Questo modulo migliorato è stato reso disponibile in via sperimentale a partire dalla versione Go 1.21, e attualmente è in corso la valutazione della certificazione NIST FIPS 140-3.Elenco dei moduli in fase di valutazione per la certificazione NIST FIPS 140-3
Ciò dimostra la maturità della libreria crittografica di Go, e grazie a ciò, Go è ora in grado di fornire un ambiente certificato FIPS 140-3 come un unico binario completamente indipendente.
Inoltre, il team di Go non si è limitato a soddisfare lo standard FIPS 140-3, ma ha anche rafforzato autonomamente la sicurezza.
Fail Fast
La modalità FIPS di Go adotta il modello di sicurezza Fail Fast, interrompendo immediatamente l'esecuzione con un
panicse viene richiamato un algoritmo non certificato. A differenza dei modelli basati su Provider in altri linguaggi, che lasciano la possibilità di fallback, questo approccio offre una garanzia più rigorosa e chiara in termini di sicurezza e conformità normativa.Hedged Signature
Lo standard FIPS 140-3 raccomanda il metodo RFC6979 per le firme ECDSA. Tuttavia, Go ha introdotto anche il metodo Hedged, che consente una risposta più robusta agli attacchi a canale laterale che potrebbero verificarsi durante il processo di firma.
Generatore di numeri casuali potenziato
Il generatore di numeri casuali di Go utilizza un DRBG (Deterministic Random Bit Generator) nello spazio utente, ma inietta anche entropia aggiuntiva al kernel del sistema operativo, generando numeri casuali di alta qualità non solo nello spazio utente ma anche nello spazio del kernel. Ciò rafforza ulteriormente la sicurezza del generatore di numeri casuali.