Google dà la mazzata finale all'algoritmo crittografico SHA1

Google dà la mazzata finale all'algoritmo crittografico SHA1

Google ha finalmente crackato l'agoritmo SHA1, utilizzato come funzione di hashing per verificare l'attendibilità di un file o identificare eventuali modifiche forzate

di pubblicata il , alle 14:31 nel canale Sicurezza
Google
 

L'algoritmo crittografico SHA1 (Secure Hash Algorithm 1) è adesso considerabile inutile, morto sotto l'ultimo colpo inferto da Google. Big G ha riportato il primo attacco avvenuto con successo per portare a compimento una collisione hash fra due file protetti dalla crittografia mediante SHA1. La tecnologia dovrebbe infatti generare hash unici per ogni serie di dati per identificare ciascun file con un identificativo. Quello che ha dimostrato Google è che, nella pratica e non solo nella teoria, due file diversi possono essere contrassegnati con lo stesso hash.

La funzione SHA1 è stata progettata dalla National Security Agency (la famosa NSA) americana e l'algoritmo è stato reso pubblico nel 1995. Già nel 2005 alcuni cripto-analisti avevano messo in dubbio la sua efficacia e annunciato alcune falle che in via teorica avrebbero potuto essere sfruttate via "collision hash". Una pratica estremamente pericolosa se si considera che in questo modo file malevoli potrebbero essere scambiati per file del tutto legittimi senza lasciare alcuna traccia, dando via libera quindi ad un potenziale aggressore che potrebbe iniettare malware sul computer vittima.

Un altro duro colpo alla tecnologia è stato inferto di recente, quando nel 2015 un gruppo di ricercatori di diverse università del mondo hanno collaborato per redigere il documento noto come The SHAppening, in cui in linea di massima si consigliava di passare alle più moderne ed efficaci tecnologie SHA2 e SHA3 abbandonando del tutto SHA1 per la potenziale vulnerabilità agli attacchi "collision hash". Gli scienziati all'occorrenza avevano dimostrato che la maggiore potenza dei computer odierni può rappresentare un forte pericolo per i file protetti con SHA1.

Stando al documento con un investimento fra i 75.000 e i 120.000 dollari chiunque avrebbe potuto crackare SHA1 utilizzando il servizio EC2 di Amazon (di cloud computing), una cifra che diversi governi e realtà aziendali possono investire senza troppi patimenti. Una volta che la potenziale vulnerabilità è divenuta pubblica parecchi produttori di browser (Mozilla, Microsoft, Google) hanno iniziato ad abbandonare rapidamente SHA1 come funzione di hashing per i certificati TLS/SSL, ampiamente utilizzati sul web fra le soluzioni di crittografia.

Da allora Google ha contattato due dei ricercatori coinvolti nel progetto The SHAppening e ha offerto la propria collaborazione e l'enorme potenza di calcolo in cloud di cui dispone per continuare il lavoro, al fine di ottenere una prova pratica di quanto dimostrato teoricamente fino ad oggi. Un team composto complessivamente da sette uomini ha infine pubblicato una nuova ricerca che spiega le caratteristiche di un attacco "collision hash" realmente avvenuto. Come prova del successo dell'esperimento sono stati rilasciati due file PDF diversi con lo stesso hash SHA1.

Per intuire l'entità della problematica vi proponiamo l'esempio di un documento importante, magari un accordo di lavoro, salvato online come PDF e protetto attraverso hash SHA1 per identificarlo come unico e attendibile, e per dimostrare che nessuno lo ha modificato dopo la stipulazione. Adesso che si ha la certezza comprovata che SHA1 non è più attendibile, lo stesso metodo non può più essere considerato valido dal momento che non si può più offrire la certezza che non sia stato modificato dopo l'ultima interazione legittima con il documento.

Bisogna tuttavia fare una precisazione importante: per effettuare l'attacco Google ha dovuto organizzare, stando ai propri stessi annunci, "uno dei più grandi calcoli computazionali mai portati a termine". Sembra quindi economicamente molto difficile che l'attacco possa essere effettuato se non da enti enormi, come ad esempio governi o società che possono affidarsi a grossi sistemi o servizi in cloud. Google rilascerà un codice "proof-of-concept" con le modalità di esecuzione dell'attacco nei prossimi 90 giorni, dopo i quali sarebbe meglio abbandonare del tutto SHA1. Senza se e senza ma.

12 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
cignox124 Febbraio 2017, 15:15 #1
Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?
banaz24 Febbraio 2017, 15:32 #2
Originariamente inviato da: cignox1
Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?


https://shattered.it/static/shattered-1.pdf

https://shattered.it/static/shattered-2.pdf

due click ci son voluti eh...
djfix1324 Febbraio 2017, 15:41 #3
da quello che so io 2 doc identici non danno lo stesso SHA1
coschizza24 Febbraio 2017, 16:20 #4
Originariamente inviato da: djfix13
da quello che so io 2 doc identici non danno lo stesso SHA1


io ci ho messo invece 4 click per fare questo

38762cf7f55934b34d179ae6a4c80cadccbb7f0a *shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a *shattered-2.pdf

e poi se 2 doc identici non danno lo stesso SHA1 allora a che servirebbe lo SHA, a nulla.
jepessen24 Febbraio 2017, 16:36 #5
Un conto e' essere uguali dal punto di vista del contenuto, un punto e' essere uguali dal punto di vista binario, o quantomeno nel calcolo dell'hash.

Il concetto e' che puoi avere un file qualunque che, con opportuno codice aggiunto, presenta lo stesso hash di un altro.

L'esempio dei PDF e' fatto perche' il formato di file permette di aggiungere informazioni in un header che non inficia il documento... Teoricamente potrebbe essere fatta la stessa cosa per I tag dei file MP3.. potresti avere un file con un hash e poi un altro diverso dove aggiungi dei byte in un tag, tipo quello della copertina, per fare in modo che alla fine il calcolo dell'hash sia lo stesso.
kreijack24 Febbraio 2017, 19:24 #6
Originariamente inviato da: cignox1
Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?


Originariamente inviato da: cignox1
Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?


Credo che la tecnica sia un po' più raffinata.

Queste checksum vengono calcolate a blocchi. Il che significa che se trovo due blocchi diversi con la stessa checksum, concatenandoli ad un file ottengo due file *diversi* che continuano ad avere la *stessa checksum*.

Infatti confrontando i due file, solo 62 byte sono differenti (ed hanno la stessa lunghezza).

A questo punto se il tipo di file può contenere del codice eseguibile, questo codice può verificare quale file è verificando se è presente (o meno) uno dei due blocchi ed eseguire delle azioni che sono diverse a seconda del blocco.

La prima volta che ho sentito parlare di questo problema, era relativo ad un documento postscript ed ad una collisione md5 [*]; visto che gli esempi sono dei PDF (che credo possano a loro volta contenere del codice javascript), mi viene da pensare che la tecnica usata sia simile

Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).

Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


[*] http://www.educatedguesswork.org/20...collisions.html
rockroll25 Febbraio 2017, 01:34 #7
Originariamente inviato da: cignox1
Qualcuno ha dato una occhiata ai due file? Immagino che al massimo uno dei due "abbia senso", mentre l'altro sia un accrocchio di byte cercati proprio perché fornissero la stessa hash.

Corretto?


Penso anch'io.

Ciò non toglie che da un punto di vista teorico anche files che non hanno alcun senso devono essere sempre distinguibili con hash univoco (pensa a files binari magari criptati); e questo non sarà matematicamente mai garantito (per improbabile che sia in pratica) se l'hash contiene meno bit del file!
melo8625 Febbraio 2017, 01:47 #8
Originariamente inviato da: kreijack
Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).


le firme di questi file ne garantiscono l'autenticità, basti pensare ai certificati rilasciati per i vari siti web che devono essere firmati da un garante fidato (e sono file di testo, nondegli eseguibili).

Originariamente inviato da: kreijack
Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


l'articolo dice esattamente che è possibile creare blocchi arbitrari con la stessa checksum, non ho capito cosa intendi
rockroll25 Febbraio 2017, 02:30 #9
Originariamente inviato da: kreijack
Credo che la tecnica sia un po' più raffinata.

Queste checksum vengono calcolate a blocchi. Il che significa che se trovo due blocchi diversi con la stessa checksum, concatenandoli ad un file ottengo due file *diversi* che continuano ad avere la *stessa checksum*.

Infatti confrontando i due file, solo 62 byte sono differenti (ed hanno la stessa lunghezza).

A questo punto se il tipo di file può contenere del codice eseguibile, questo codice può verificare quale file è verificando se è presente (o meno) uno dei due blocchi ed eseguire delle azioni che sono diverse a seconda del blocco.

La prima volta che ho sentito parlare di questo problema, era relativo ad un documento postscript ed ad una collisione md5 [*]; visto che gli esempi sono dei PDF (che credo possano a loro volta contenere del codice javascript), mi viene da pensare che la tecnica usata sia simile

Questo spiega perchè non ha senso firmare digitalmente documenti che possano contenere codice (vedi file word o similia).

Riassumendo, è vero quello che dici tu (non è possibile creare due blocchi arbitrari con la stessa checksum); ma, per alcuni file, potrebbero apparire simili.


[*] http://www.educatedguesswork.org/20...collisions.html


Parlo con te che mi sembri il più ferrato sull'argomento; io, nella mia dabbenaggine idealistica, ho sempre snobbato questo campo, per cui sono ignorante, ma questo non significa privo di logica.
Ripeto anche a te quello appena detto rispondendo a cignox1: da un punto di vista teorico anche files che non hanno alcun senso devono essere sempre distinguibili con hash univoco (pensa a files binari magari criptati); e questo non sarà matematicamente mai garantito (per improbabile che sia in pratica) se l'hash contiene meno bit del file!

Un hash, per lungo che sia, sarà nella realtà composto di un numero di bit nh di parecchi ordini di grandezza inferiore al numero di bit nf del file da esaminare. Come si può pretendere che un numero di configurazioni possibili 2^nh possa individuare univocamente tutte le 2^nf configurazioni possibili di un file composto di nf bit, dove nh << nf ???
Pur ammettendo una distribuzione ottimale delle corrispondenze generate dal calcolo dell'hash, ci sarà sempre inevitabilmente almeno un numero 2^(nf-nh) di casi in cui si presenta almeno un doppione, cioè in cui lo stesso hash corrisponde ad almeno due files diversi, e chiedo scusa se quel numero di casi è troppo piccolo...

L'unica cosa di cui siamo sicuri è che a files uguali corrispondono hash uguali.

Che poi all'atto pratico le cose possano andar decisamente meglio, questo non inficia quanto ho esposto.

Perchè decisamente neglio? Perchè all'atto pratico si vuol evitare che qualcuno cambi qualche valore (in sostanza pochi bit) su un documento che comunque dovrebbe mantenere una conformazione che corrisponda ad un documento possibile e riconoscibile come tale. Da quanto su esposto è sicuramente possibile, con le attuali potenze di calcolo, creare in tempi ragionevoli un file di ugual hash, ma che questo possa corrispondere ad un documento valido come caratteristiche è molto più difficile, è potrebbe essere impossibile, dipende da come è strutturato l'algoritmo, che potrebbe essere in grado, riconoscendo la struttura nota del documento, di orientare il calcolo dell'hash in maniera da differenziare sicuramente l'hash per pochi bit di differenza in zone ristrette del file documento.
Certo se il documento contiene delle zone cieche nelle quali posso mettere manciate di bit che poi non vengono evidenziati e non vanno ad inficiarne la conformazione e le caratteristiche di utilizzo (Vedi PDF contenente Java o Tag mp3), se voglio hackerare il contenuto ho a disposizione la zona cieca per riportare l'hash al valore voluto, per lungo che sia se vado a brute force, basta che la zone cieca contenga pochi bit più dell'hash, a meno che l'algoritmo sia a conoscenza della zona cieca e la escluda dal calcolo hash..
kaidan25 Febbraio 2017, 13:53 #10

Birthday attack

Si tratta di un birthday attack. Si modifica leggermente un file di partenza e ne si calcola l'hash. E' un attacco di forza bruta allo scopo di trovare collisioni tra due input molto simili, ma differenti. Il vantaggio è che sono necessario 2^n/2 tentativi invece di 2^n tentativi per trovare con probabilità maggiore del 0,5 una collisione.
Per adesso basta usare algoritmi con digest superiore a 160bit, simile a come avvenuto quando è stato crackato il DES che poi fu sostituito da 3DES.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^