Il Lato Oscuro della Crittografia: Quando Gli Algoritmi Ti Tradiscono

Matteo Brandi : 3 Settembre 2024 22:22

I fallimenti crittografici (Cryptographic Failures), sono un problema maledettamente serio, tanto da essere uno dei OWASP TOP 10 nella posizione A2, scalando una posizione dal 2017 (qui il sito ufficiale). Se pensi che tutti i tuoi dati che transitano in rete o che sono conservati nei server sono (o dovrebbero essere) crittografati, capisci che un fallimento aprirebbe scenari catastrofici, ma sento arrivare la domanda…come possono accadere?

Se fossero storie…sarebbero state scritte da Edgar Allan Poe…

I principali motivi di fallimento di un algoritmo crittografico sono :

1. implementazione vulnerabile
2. utilizzo di algoritmi deboli 
3. debolezza nella generazione delle chiavi

Seguimi in una storia di terrore crittografico: Heartbleed

Fallimenti Crittografici: HEARTBLEED

Nel 2014, fu scoperta una vulnerabilità in OpenSSL, una libreria molto utilizzata in quanto progetto Open Source per aiutare l’implementazione di  SSL/TLS (il famoso lucchetto in alto a sinistra nel Browser per esempio) nelle comunicazione via internet rendendole crittografate e quindi più sicure.
Questa vulnerabilità sconvolse il mondo di internet: permetteva agli attaccanti di leggere porzioni di memoria del server, potenzialmente esponendo chiavi private, nomi utente, password e altri dati sensibili. 

Un esempio di fallimento crittografico che ha avuto conseguenze disastrose.

Questa falla fu introdotta nel 2012 (quindi è stata attiva per circa 2 anni) nella versione 1.0.1 della libreria insieme all’estensione Heartbeat. Vediamo di capirci qualcosa.

La nuova funzionalità introdotta, Heartbeat, faceva una cosa semplice: verificava che la connessione SSL/TLS fosse ancora attiva. Come lo faceva?

Il client mandava un messaggio Heartbeat contenente dei dati specificandone la dimensione al server e questo rispondeva al cliente con gli stessi dati, specificandone a sua volta la dimensione.

Tutto molto lineare, ma allora il problema che scatenò il panico mondiale dove sta?

Nei dettagli…Non avevano previsto di controllare che la dimensione dei dati dichiarata nel messaggio heartbeat fosse uguale a quella dei dati inviati.

Mandando per esempio 1 byte di dati ma dichiarandone 200, il server rispondeva con il byte di dati inviato e 199 byte di dati presi dalle celle di memoria adiacenti al fine di arrivare a 200 byte. Simpatico vero? In questo modo il server avrebbe potuto inviare qualsiasi tipo di dato: password, dati personali, chiavi crittografiche etc.etc.

Comunque questa storia ha un lieto fine: una volta scoperto fu prontamente risolto.

Quando il sale serve…sulle password

Cambiando decisamente paradigma, passiamo da una storia dell’orrore di fallimenti crittografici a questioni di cucina: benché esista il detto “troppo salato si butta, non salato si mangia” il sale crittografico sulle password serve. Non metterlo esporrebbe dati sensibili come le password a vulnerabilità crittografiche come l’attacco con Rainbow Table. Ma andiamo per ordine.

Gli hash. Oggi il 99,99% dei salvataggi di una password avviene sotto forma di hash (per saperne di più c’è l’articolo del nostro Davide Cavallini qui. Con la speranza che il nostro Davide non me ne voglia, ne do una definizione in campo gastronomico:  immagina di avere una pietanza (la password) che inserisci in un calderone (la funzione hash). Da questo calderone esce una pozione unica (l’hash), che rappresenta la tua pietanza in modo unico. Le caratteristiche di questa pozione sono:

1. anche un piccolo cambiamento nella pietanza cambia completamente la pozione.
2. la stessa chiave produce sempre la stessa pozione
3. è impossibile risalire alla chiave originale dalla pozione
4. è molto difficile trovare due pietanze diverse che producano la stessa pozione.

Gli arcobaleni pericolosi. Sfortunatamente oggi esistono tabelle (chiamate Rainbow Tables) di hash di password già calcolati con cui tentare di decifrare quelli rubati. Quindi nessuno sforzo ed ad oggi il solo algoritmo di hashing risulta debole visti gli strumenti che ci sono in giro.

Salatura degli hash. Qui interviene il sale (in gergo tecnico si utilizza veramente la parola “salt” ossia sale in inglese quindi il paragone culinario mi è parso adeguato) : come è un potente conservante in campo alimentare, così lo è anche in campo crittografico. Ora, immagina di aggiungere un pizzico di sale alla tua chiave magica prima di metterla nel calderone. Questo rende la pozione ancora più unica. Ecco i vantaggi:

• anche usando la stessa pietanza, le due pozioni saranno diverse grazie al sale
• le rainbow tables diventano inutili perché ogni pozione richiede una combinazione unica di pietanza e sale

Quindi la salagione della password è un rafforzamento della difesa crittografica per cui il mancato utilizzo ne crea una vulnerabilità.

Una chiave debole

“Tra bit danzanti,segreti cifrati.Crittografia.” Questo antico componimento ci svela un grande segreto: la crittografia è intorno a noi, ci abbraccia e ci accompagna con la sua presenza discreta. Ma quando ci sono dei fallimenti crittografici? Hai mai apposto una firma digitale? Se lo hai fatto, hai usato un modalità crittografica chiamata crittografia asimmetrica. Hai firmato il documento cifrandolo con la tua chiave privata. Di questa chiave ne esiste una derivata chiamata chiave pubblica con la quale, in quanto pubblica, chiunque potrà decifrare il documento e quindi verificare che la firma sia tua.

Anche se la chiave privata è correlata alla chiave pubblica, da questa non si può ricavare, a meno che…
Gli algoritmi utilizzabili per la generazione dell chiavi e porre in essere la crittografia asimmetrica, sono di pubblico dominio, quindi non c’è alcun segreto.

Dove sta la forza allora se si conosce il metodo di cifratura?? La forza sta nelle chiavi.

Tutta l’architettura si basa sullo sforzo computazionale esagerato sia in termini di energia che di tempo che servirebbe per trovare la chiave privata da quella pubblica. Ammesso che ci volessero 3.000 anni (ma sono molti di più) per trovare la chiave privata e quindi falsificare la tua firma…che senso avrebbe?

Ma potevo non raccontarti una storia sui fallimenti crittografici? Se hai letto i miei precedenti articoli ormai mi conosci…

C’era una volta un matematico appassionato di sfide intellettuali e di enigmi crittografici viveva in una piccola casa ai margini di un bosco, lontano dai clamori della città, circondato da libri polverosi e fogli di carta pieni di equazioni. Aveva sempre sognato di affrontare l’algoritmo RSA nonostante la mancanza di strumenti moderni, possedeva una mente acuta e una passione incrollabile per la matematica.

Era affascinato dalla possibilità di creare un sistema di crittografia sicuro basato solo sulla teoria dei numeri e sui calcoli matematici. Decise di mettersi alla prova e di implementare l’algoritmo RSA con carta e penna. Si sedette al suo tavolo, prese un foglio di carta bianca e iniziò a scrivere con il suo fidato pennino.

Come prima scelse due numeri primi casuali che chiamò P e Q. P= 5 e Q = 17. Fatta questa scelta, calcolò il parametro n dato dalla moltiplicazione di P e Q n = P ∙ Q = 5 ∙ 17 = 85. Il parametro n, quindi 85,sarà il modulo con cui lavorerà. Il secondo parametro che scaturisce dalla scelta di P e Q lo calcolò così: z = (P-1) ∙ (Q-1) = 4 ∙ 16 = 64 . z è il numero dei numeri coprimi relativi al modulo 85. Ci sono 64 numeri per cui se divido 85 per uno di questi, non ottengo un numero intero.

Generazione delle chiavi. Doveva scegliere un numero, che indicò con e,  tale che fosse coprimo rispetto a z ed inferiore a 85. Scelse 5 visto che che se divideva 64 per 5 non otteneva un numero intero ed era inferiore ad 85 quindi e=5. Aveva generato la prima chiave (privata) che era Kpriv = (5,85) !! Adesso doveva calcolare la chiave pubblica. Doveva calcolare il numero d tale che d ∙ e = 1mod (85). Significa che la moltiplicazione di d per e doveva essere un multiplo di 64 più uno. Il primo multiplo di 64  più che trovò fu  65. Lo divise per 5 e trovo 13. Quindi: d = 13.

Ecco la chiave pubblica Kpub = (d,n) = (13, 85) !!!

Visti i numeri in gioco, si capisce benissimo che con un calcolatore automatico, a forza di prova, può essere trovata la chiave privata da quella pubblica vista la sua debolezza. Quindi un algoritmo crittografico valido può essere reso insicuro da una chiave eccessivamente debole.