Principali schemi di uso improprio della crittografia

La modalità Electronic Codebook (ECB) cifra ogni blocco indipendentemente usando la stessa chiave. Blocchi di testo in chiaro identici producono blocchi di testo cifrato identici. La dimostrazione classica è il "pinguino ECB": cifrando un’immagine bitmap con ECB si preserva la struttura dell’immagine a livello di blocchi, rendendo chiaramente visibile il contorno del pinguino nel testo cifrato. La modalità ECB non offre sicurezza semantica e non dovrebbe mai essere utilizzata per alcuno scopo pratico di cifratura.

Implementare da zero primitive crittografiche è una delle pratiche più pericolose nello sviluppo software. La crittografia richiede una correttezza assoluta in condizioni avversariali: una sottile fuga di informazioni temporali, un errore di uno nella gestione del padding o un’interpretazione errata dei requisiti di sicurezza possono creare vulnerabilità sfruttabili, indistinguibili dal comportamento corretto nei test normali. Anche i crittografi esperti commettono errori di implementazione; gli sviluppatori di applicazioni dovrebbero utilizzare esclusivamente librerie sottoposte a verifiche approfondite.

MD5 è vulnerabile alle collisioni dal 2004: creare due file con lo stesso hash MD5 è computazionalmente banale. Gli attacchi alle collisioni di SHA-1 sono stati dimostrati concretamente dall’attacco SHAttered di Google nel 2017, che ha generato due file PDF con lo stesso hash SHA-1. Nessuno dei due algoritmi dovrebbe essere utilizzato per scopi di sicurezza: firme digitali, integrità dei contenuti, memorizzazione delle password o HMAC. Per le implementazioni moderne utilizzi SHA-256, SHA-3 o BLAKE2.

Utilizzare time() o altri valori prevedibili per inizializzare un generatore di numeri pseudocasuali è una vulnerabilità critica quando l’output del PRNG viene usato per scopi di sicurezza. Un attaccante che sa approssimativamente quando è stata generata una chiave può provare per forza bruta tutti i possibili seed in una finestra temporale ristretta e recuperare la chiave. Un esempio classico: le prime versioni di Netscape inizializzavano la generazione delle chiavi SSL usando l’ora e l’ID del processo, entrambi osservabili da un attaccante sulla stessa macchina.

rand() in C, java.util.Random e il modulo random di Python utilizzano generatori congruenziali lineari deterministici o Mersenne Twister, progettati per offrire una buona qualità statistica nelle simulazioni, non per la sicurezza. Un attaccante che osserva un numero sufficiente di output di questi generatori può ricostruirne lo stato interno e prevedere tutti gli output futuri. Per scopi di sicurezza, utilizzi i CSPRNG forniti dal sistema operativo: secrets.token_bytes() in Python, crypto.randomBytes() in Node.js o /dev/urandom su Linux.

La cifratura senza autenticazione garantisce solo la riservatezza, non l’integrità. Un attaccante che non può leggere il testo in chiaro può comunque modificare il testo cifrato, causando potenzialmente modifiche prevedibili al testo in chiaro, soprattutto nelle modalità CTR o CBC. Questa malleabilità abilita attacchi: un attaccante che intercetta una transazione bancaria cifrata potrebbe invertire alcuni bit per modificare l’importo del trasferimento o il conto destinatario senza conoscere il testo in chiaro. Utilizzi sempre la cifratura autenticata (AEAD).

Inserire chiavi di cifratura o vettori di inizializzazione nel codice sorgente è una vulnerabilità critica. Il codice sorgente viene spesso sottoposto a versionamento, talvolta in repository pubblici. Anche nei repository privati, chiunque abbia accesso al codice dispone della chiave. Le chiavi inserite nel codice fanno sì che tutte le istanze utilizzino la stessa chiave e che la rotazione delle chiavi richieda una nuova distribuzione. Le chiavi devono essere archiviate in variabili d’ambiente, sistemi di gestione dei segreti come HashiCorp Vault e AWS Secrets Manager, oppure moduli hardware di sicurezza.

Utilizzare lo stesso vettore di inizializzazione per più operazioni di cifratura con la stessa chiave crea gravi vulnerabilità. In modalità CTR, il riutilizzo dell’IV crea lo stesso keystream, consentendo di recuperare il testo in chiaro tramite XOR. In modalità CBC, il riutilizzo dell’IV permette a un attaccante di rilevare quando due messaggi iniziano con gli stessi blocchi di testo in chiaro. In GCM, il riutilizzo del nonce (IV) è catastrofico; consulti la lezione sul riutilizzo dei nonce. Generi un IV casuale nuovo per ogni operazione di cifratura e lo anteponga al testo cifrato per archiviarlo insieme al contesto di decrittografia.

Memorizzare le password usando hash calcolati con MD5, SHA-256 o qualsiasi altro hash crittografico veloce non è adeguato. Le GPU moderne possono calcolare miliardi di hash SHA-256 al secondo, rendendo estremamente rapidi gli attacchi offline per forza bruta contro database di hash sottratti. L’hashing delle password richiede funzioni lente e memory-hard progettate appositamente: bcrypt, scrypt o Argon2id. Queste funzioni sono progettate per rendere costosa la forza bruta anche con hardware specializzato, mantenendo gli attacchi offline computazionalmente impraticabili.

Disabilitare la validazione dei certificati SSL/TLS, impostando ssl.CERT_NONE in Python, passando -k a curl o impostando trustAllCerts=true in Android, elimina la protezione contro gli attacchi man-in-the-middle. Un attaccante può presentare qualsiasi certificato e intercettare tutte le comunicazioni. Questa pratica compare negli ambienti di sviluppo per aggirare gli errori relativi ai certificati autofirmati, ma spesso rimane anche in produzione. Utilizzi sempre una corretta validazione dei certificati e risolva correttamente i problemi alla base.

Le funzioni crittografiche segnalano gli errori tramite valori restituiti o eccezioni. Ignorarli consente all’esecuzione di proseguire con uno stato non valido: una decrittografia che ha prodotto dati senza senso, una verifica fallita o una generazione di chiavi terminata con un errore. Nelle API basate su C come OpenSSL, ignorare i valori restituiti è particolarmente pericoloso perché il programma potrebbe proseguire usando memoria non inizializzata. Verifichi sempre ogni valore restituito dalle funzioni crittografiche e gestisca gli errori in modo sicuro.

Perché la modalità ECB (Electronic Codebook) è considerata insicura per la cifratura dei dati?

Principali usi impropri da evitare: non utilizzi mai la modalità ECB, che rivela i pattern dei blocchi; non implementi personalmente le primitive crittografiche; rifiuti MD5 e SHA-1 per la sicurezza; inizializzi i PRNG con un CSPRNG e non con time(); utilizzi un CSPRNG per ogni casualità sensibile alla sicurezza; autentichi sempre i dati cifrati con AEAD; non inserisca mai chiavi o IV nel codice; generi un IV nuovo per ogni cifratura; utilizzi Argon2id per le password e non hash veloci; validi sempre i certificati TLS; e verifichi ogni valore restituito dalle funzioni crittografiche.