Verifica e selezione delle dipendenze crittografiche

La libreria crittografica scelta è una delle decisioni di sicurezza più importanti in un progetto. Anche sviluppatori ben intenzionati possono creare sistemi non sicuri usando una libreria inadeguata. Al contrario, una libreria ben progettata rende difficili gli errori catastrofici. Il processo di selezione dovrebbe essere sistematico e valutare il livello di sicurezza dimostrato, la progettazione dell'API, lo stato della manutenzione e l'adeguatezza allo scopo.

Una delle prime domande da porsi per qualsiasi libreria crittografica è quando sia stata sottoposta all'ultimo audit indipendente e che cosa comprendesse tale audit. Un audit eseguito cinque anni fa sulla versione 1.0 offre meno garanzie per la versione 3.0 usata oggi. Cercate audit condotti da aziende di sicurezza affidabili (NCC Group, Trail of Bits, Quarkslab, Cure53) che coprano le funzionalità specifiche che intendete usare. Alcune librerie pubblicano i rapporti di audit; l'assenza di qualsiasi audit è un fattore di rischio significativo.

Esaminate la cronologia delle CVE della libreria nel NVD (National Vulnerability Database). Verificate quanti siano le CVE presenti, i relativi livelli di gravità, le classi di vulnerabilità che rappresentano (errori logici, corruzione della memoria o debolezze degli algoritmi) e la rapidità con cui i manutentori hanno rilasciato le patch. Una libreria con CVE occasionali risolte tempestivamente dimostra una manutenzione reattiva. Una libreria con molte CVE ad alta gravità o con tempi di applicazione delle patch lenti è un segnale d'allarme.

Le librerie crittografiche non manutenute sono pericolose. Verificate la data dell'ultimo commit, la frequenza dei rilasci e se gli avvisi di sicurezza vengono gestiti. Una libreria il cui ultimo commit risale a tre anni fa potrebbe avere vulnerabilità note che non verranno mai corrette. Le dimensioni della comunità sono importanti per l'ampiezza della revisione: le librerie ampiamente usate ricevono un'attenzione maggiore da parte dei ricercatori di sicurezza rispetto ai progetti di nicchia.

Per la sicurezza è preferibile una superficie dell'API più piccola e caratterizzata da scelte predefinite precise. Le librerie che espongono molte opzioni di algoritmo e manopole di configurazione creano opportunità di configurazione errata. Confrontate libsodium (una funzione per ogni caso d'uso, con algoritmo fisso) con OpenSSL EVP (scelta separata di cifrario, modalità, dimensione della chiave, padding e gestione dell'IV). Quanto più è difficile usare una libreria in modo errato, tanto più è adatta ai progetti attenti alla sicurezza.

Per le operazioni che coinvolgono dati segreti (confronto di chiavi, decifratura, verifica delle firme), l'implementazione deve usare algoritmi a tempo costante che non eseguano diramazioni né accedano alla memoria in base ai valori segreti. Verificate che la documentazione della libreria dichiari esplicitamente garanzie di tempo costante per le operazioni sensibili oppure che il codice sorgente usi funzioni approvate per i confronti a tempo costante. Le librerie prive di questa garanzia sono vulnerabili agli attacchi a canale laterale basati sui tempi di esecuzione.

Una buona libreria crittografica dovrebbe supportare algoritmi moderni e prevedere la dismissione di quelli obsoleti. Dovrebbe offrire ChaCha20-Poly1305 o AES-256-GCM per la cifratura, Ed25519 o ECDSA P-256 per le firme, X25519 per lo scambio di chiavi e Argon2id per l'hashing delle password. Le librerie che offrono solo algoritmi legacy (DES, RC4, MD5, SHA-1) non sono adatte alle nuove distribuzioni, indipendentemente dalle loro altre qualità.

Valutate le dipendenze transitive: da quali librerie dipende la vostra libreria crittografica e qual è il loro livello di sicurezza? Una libreria priva di dipendenze esterne, come libsodium, presenta un rischio minimo per la catena di approvvigionamento. Una libreria che dipende da una dozzina di pacchetti npm, ciascuno con le proprie dipendenze, presenta un'ampia superficie d'attacco nella catena di approvvigionamento. Verificate se la libreria usa build riproducibili, così da poter verificare che il binario distribuito corrisponda al codice sorgente.

I settori regolamentati (sanità, finanza e pubblica amministrazione) richiedono spesso moduli crittografici convalidati secondo FIPS 140-2 o 140-3. La convalida FIPS è costosa e richiede tempo, quindi solo una parte delle librerie ne dispone. OpenSSL con il suo provider FIPS, BoringCrypto (usato in Go's crypto/tls) e alcune librerie HSM hanno la convalida FIPS. Se la vostra distribuzione deve essere conforme a FIPS, questo requisito restringe notevolmente la scelta delle librerie.

I moduli di sicurezza hardware (HSM) e i servizi KMS cloud usano spesso API proprietarie per le operazioni sulle chiavi. Legare strettamente l'applicazione ad AWS KMS o a un fornitore specifico di HSM crea un rischio di lock-in. Valutate se la libreria fornisce livelli di astrazione, come l'integrazione KMS di Tink, che consentano di cambiare provider. Considerate inoltre che, se il fornitore dell'HSM interrompe il supporto o aumenta i prezzi, i costi di migrazione potrebbero essere considerevoli.

La regola più importante nella scelta delle dipendenze crittografiche è usare librerie note e ampiamente distribuite, che implementino standard consolidati, e non implementare mai personalmente le primitive crittografiche. Indipendentemente da quanto comprendiate bene la teoria, implementare correttamente AES, RSA, le operazioni sulle curve ellittiche o la cifratura autenticata nel codice di produzione è estremamente difficile e quasi mai vale il rischio rispetto all'uso di una libreria collaudata.

Qual è il fattore PIÙ importante da considerare quando si valuta una libreria crittografica per un nuovo progetto?

Lista di controllo per la scelta della libreria: verificate l'ambito e il rapporto di un audit indipendente recente, esaminate la cronologia delle CVE e i tempi di risposta alle patch, verificate la manutenzione attiva e il coinvolgimento della comunità, preferite superfici dell'API più piccole e resistenti all'uso improprio, confermate le garanzie di tempo costante per le operazioni sensibili, assicuratevi che siano supportati algoritmi moderni, valutate le dipendenze della catena di approvvigionamento, controllate la convalida FIPS nei settori regolamentati, considerate il rischio di lock-in del fornitore KMS e usate sempre librerie consolidate invece di implementare personalmente le primitive.