Cosa c'è che non va con SHA-1 che ha collisioni? [duplicare]

Da un po 'di tempo che la collisione SHA-1 è stata raggiunta con successo da G oogle ricercatori Come prova del concetto, la ricerca presenta due file PDF [PDF1 , PDF2] che hanno lo stesso hash SHA1, ma mostrano contenuti completamente diversi.

Puoi saperne di più nel questo documento accademico.

Vale anche la pena di menzionare che questa funzione hash crittografica ha 22 anni, ma per quanto mi riguarda siamo ancora lontani dal vedere un attacco del mondo reale condotto specialmente nello scenario che hai descritto, eccetto se sei preso di mira da un governo o una ricca impresa criminale:

A practical collision attack against SHA-1 would cost $700,000 in 2015 and $143,000 in 2018. He surmised at that cost attacks, especially if they were carried out by a wealthy criminal enterprise or government entity, could be feasible. (Bruce Schneier)

Ora, per essere più pratico, una collisione SHA-1 può influire sul criterio di firma del codice in modalità Kernel di Microsoft, ad esempio. Questo attacco si basava sulla verifica della firma per caricare solo i driver in modalità kernel firmati. Puoi trovare ulteriori qui ma per ora non sono sicuro che tu debba preoccuparti di un attacco MITM che fornisce un file alterato ..

Anche se è stato possibile creare due file con lo stesso hash (collisione), non è possibile creare un file che corrisponda ad un hash predeterminato (attacco preimage). Pertanto, lo scenario che descrivi non è particolarmente vulnerabile a una collisione hash.

Tuttavia, tieni presente che se l'utente malintenzionato può iniettare un altro eseguibile, potrebbe anche essere in grado di iniettare un altro valore hash.

Le collisioni SHA1 sono particolarmente un problema quando si firmano documenti, come le richieste di certificati. Con la possibilità di creare una collisione hash, un utente malintenzionato può creare due richieste di certificati, una per legit.com e una per evilattacker.com, con lo stesso hash. L'autorità di certificazione firmerà quindi legit.com e l'utente malintenzionato può utilizzare la firma per creare un certificato valido per evilattacker.com e viceversa.

Viene chiesto uno scenario in cui un utente malintenzionato è in grado di creare una collisione hash con un file arbitrario che l'utente malintenzionato non controlla (in questo caso, il download valido). Questo è chiamato un attacco Preimage , ed è generalmente più difficile di un semplice attacco di collisione, ma il tuo scenario prevede un attacco pre-attacco piuttosto che una semplice collisione. In tale scenario, la seguente affermazione non tieni premuto:

It would be extremely improbable for an attacker to be able to generate a collision that would be a runnable program, and could somehow infect your system.

Supponendo che tu abbia determinato come produrre qualsiasi file Y che ha una collisione hash con il file X valido, è probabile che altrettanto facile produca invece una Z funzionante Z con lo stesso valore di hash. I binari hanno enormi gradi di libertà: è possibile modificare le risorse incorporate (tabelle e icone delle stringhe e così via), i metadati (nome del programma, autore, data di compilazione, ecc.) E ovviamente basta attaccare la "spazzatura" usata per produrre l'hash collisione alla fine del file, dopo il vero programma (dannoso).

Quando le persone producono una collisione di hash, non stanno lavorando da uno stato pristine in cui non c'è hash, con cura elaborando dati che a poco a poco producono l'hash desiderato (almeno, non se ne usano anche solo vagamente -algoritmo hash moderno). Tutti i possibili input, inclusa la stringa vuota , hanno un hash digest valido. L'obiettivo del cercatore di collisione è trovare un input che produca l'output desiderato, ma non c'è motivo per cui l'input non possa essere parzialmente un blob di dati fissi (come un programma malware). Sì, quel blob avrà il proprio valore di hash iniziale (digest) ... ma lo stesso vale per la stringa vuota!

Quindi sì, se il blob arbitrario A produce di per sé la collisione desiderata, blob A da solo (come un file) è estremamente improbabile che sia un programma significativo, molto meno dannoso. Tuttavia, la quantità di lavoro necessaria per trovare BLOB A è la stessa quantità necessaria per trovare BLOB B che, una volta concatenato alla fine del programma dannoso fisso M, il digest di M + B produce la collisione.

Ora, con quello detto, le collisioni trovate finora su SHA1 non sono pre-immagini. Cioè, i ricercatori della sicurezza hanno trovato due blob arbitrari A e B che hanno lo stesso digest SHA1, ma hanno non dimostrato la capacità di, per un file specificato X (o specificato Digest D, dove presumibilmente D = SHA1 (X) per alcuni X), produce un file Y che ha lo stesso digest di SHA1 D di X. Hanno prodotto una collisione, ma non un attacco di pre-immagine.

La resistenza di collisione è una caratteristica di una funzione di hash sicura, quindi trovare qualsiasi collisione ha messo in dubbio la sicurezza generale di SHA1. Tuttavia, siamo ancora in alcuni modi dall'essere in grado di produrre attacchi preimage (contro digest arbitrari o file arbitrari) contro SHA1.