Un file può essere modificato in modo dannoso in modo da mantenere il suo hash SHA-1 originale?

Secondo questo articolo e molti altri, SHA-1 non è sicuro.

Nel mio caso, non sono preoccupato per password o certificati digitali. Sono preoccupato per l'integrità dei file.

È ragionevolmente possibile che un file (ad esempio un'immagine ISO o un file eseguibile) venga modificato in modo dannoso in modo che:

• Mantiene l'hash SHA-1 del file originale e
• Mantiene il contenuto e le operazioni generali del file (ma ovviamente ora include contenuti dannosi che inizialmente non erano presenti)

Per come la vedo io, la modifica di un file in modo da produrre una collisione SHA-1 renderebbe il file totalmente inutile. L'ISO sarebbe totalmente corrotto, o il file eseguibile sarebbe così completamente confuso da non essere più nemmeno un file eseguibile.

Ma il modo in cui lo vedo potrebbe essere sbagliato. Finora non ho trovato nulla nelle ricerche di Google per quanto riguarda la continua idoneità di SHA-1 per la verifica dei file. Qualche intuizione?

Nessuno lo ha ancora realizzato per SHA-1. In teoria è possibile, ma non è ancora pratico. I rapporti sull'insicurezza in SHA-1 significano solo che il livello di sicurezza non è alto come vorremmo che fosse e ciò significa che non abbiamo tanti anni prima che dobbiamo preoccuparci di questo come pensavamo di fare.

È più difficile produrre un file con lo stesso hash SHA-1 di un determinato file piuttosto che creare due file con lo stesso hash SHA-1. E per quanto ne sappiamo, nessuno al mondo ha ancora portato a termine questo compito più semplice. Ciò non significa che non possa succedere domani, comunque.

È teoricamente possibile, ma non è stato ancora fatto.

Quello che stai cercando si chiama "collisione hash:" due file con lo stesso hash. Codici hash crittografici come SHA-1 sono generalmente progettati per rendere questo difficile. Poiché SHA-1 è un codice a 160 bit, ci vorranno in media 2 ^ 159 tentativi di forza bruta per trovare un duplicato. Se viene trovato un algoritmo che fa in modo affidabile meglio di quello rispetto a un hash crittografico, l'hash viene considerato "interrotto".

MD-5 è un esempio di hash molto rotto. Doveva avere una forza di 128 bit, richiedendo in media 2 ^ 127 tentativi. Allo stesso modo, abusando delle vulnerabilità conosciute, il numero effettivo di tentativi necessari può essere inferiore a 2 ^ 47. Questo è MOLTO inferiore a 2 ^ 127. In effetti, è stato fatto in meno di un giorno su un moderno cluster di elaborazione.

Faccio questo esempio perché è il più vicino a come stai cercando di usare SHA-1. Tuttavia, questo non è l'approccio più comune utilizzato dalla crittoanalisi per assicurarsi che gli hash non vengano rotti. Di solito consentono una collisione tra due file, come scelto dall'attaccante, invece di farti scegliere un file e l'attaccante che cerca di abbinarlo. Questo tipo di attacco ha il vantaggio di essere più facile da valutare. Se trovo che sia "difficile" decifrare il tuo file, significa che un altro file è altrettanto forte? Questo attacco in cui l'attaccante può scegliere entrambi i file ci assicura di catturare il peggio del peggio.

Questo tipo di attacco consente un trucco interessante noto come " attacco di compleanno ". Per farla breve, usare l'attacco del compleanno dimezza la forza dell'algoritmo, quindi SHA-1 richiede 2 ^ 80 tentativi (in media) e MD5 richiede 2 ^ 64 tentativi (in media). Questi sono rispettivamente la metà di 160 e 128.

SHA-1 ha attacchi noti che diminuiscono la sua forza da 2 ^ 80 a 2 ^ 69. Questo non avrà molta importanza per te. 2 ^ 69 tentativi sono lunghi .

Tuttavia, dalla storia, abbiamo scoperto che gli algoritmi di hash non vengono rotti spontaneamente, ma piuttosto rotti nel tempo. Nessuno rompe un algoritmo come MD-5 portandolo da 2 ^ 64 a 2 ^ 47 durante la notte. Succede nel tempo, poiché molte persone pubblicano articoli sulla matematica che stanno usando contro di essa. Di solito si può vedere la complessità degli attacchi scendere lentamente dall'inizio dell'algoritmo (dove l'attacco migliore è di solito l'attacco di compleanno).

Il fatto che stiamo vedendo alcuni cambiamenti nelle collisioni suggerisce che SHA-1 sta vedendo la luce alla fine del tunnel. È ancora forte, ma potrebbe esserci il desiderio di salire sul nuovissimo SHA-3 che attualmente è molto più sicuro.

Dovresti davvero prendere tali decisioni dal punto di vista del modello di minaccia. Quanto danno può essere fatto da un attaccante se subisce una di queste collisioni. I tuoi aggressori scrivono script per bambini con accesso a pochi laptop o governi con interi cluster di supercalcolo a loro disposizione. Quanto è grande l'intervallo di tempo in cui un utente malintenzionato deve interrompere l'hash prima che non sia utile (molti usi della crittografia comportano un "cambio di guardia", come la rotazione della password). Tutto ciò influirà sulla serietà in cui devi considerare le collisioni.

I difetti di SHA-1 discussi in quell'articolo sono molto specifici: consentono agli attaccanti di creare due cose che hanno lo stesso valore (questo è chiamato "attacco di collisione"). Tuttavia, un attacco di collisione richiede che l'attaccante controlli entrambi i file coinvolti. Se l'attaccante non controlla il file originale, un attacco di collisione non consente di trovare un altro file con lo stesso valore hash.

La ragione per cui ciò che importa per TLS / SSL (e le firme in generale) è che con questi, un attaccante spesso può controllare entrambi i file. Un certificato TLS viene in gran parte creato dalla persona che lo richiede (i bit che non controllano sono spesso prevedibili), quindi le collisioni consentono loro di creare un certificato legittimo e uno illegittimo, ottenere la firma legittima e trasferire la firma.

Per i file, la stessa situazione non si applica sempre. Se la tua preoccupazione è che la persona che sta creando il file sia l'attaccante (ad esempio, otterranno una cosa indipendentemente verificata come buona, e quindi ti invieranno il malvagio payload con lo stesso hash), si applica l'attacco SHA-1 e dovresti cercare verso l'eliminazione graduale (anche se non è ancora fondamentale, come ha detto David Schwartz). Se il file originale è attendibile, un utente malintenzionato non può applicare gli attacchi SHA-1 attualmente noti, anche se dovresti comunque pensare di eliminarlo gradualmente (se hai una scelta, usa un hash senza attacchi noti come SHA- 2).

In risposta a "la collisione non sarà utile" - Mentre un attacco non richiede che un attaccante sia in grado di ottenere una collisione utile , in genere non è poi così difficile trasformare "collisione" in "collisione utile". Molti formati di file hanno una buona quantità di spazio in cui puoi avere tutto ciò che vuoi senza influire sulla funzionalità del file; un utente malintenzionato può in genere modificarlo per ottenere una collisione (se le collisioni sono praticamente individuabili), mantenendo la parte funzionale come qualunque cosa voglia che sia. Il divario tra "attacco accademico" e "attacco pratico" può essere ampio; il divario tra "qualsiasi collisione" e "collisione utile" è generalmente molto più piccolo.

Il problema più serio, non correlato alla scelta dell'algoritmo, è come si ottiene l'hash. Tutto ciò che fa un hash è spostare il problema da "get the real file" a "get the real hash value;" un valore di hash inviato dallo stesso server e sullo stesso tipo di connessione del file è assolutamente inutile contro modifiche dannose (qualsiasi utente malintenzionato che può manomettere il file può manomettere l'hash). Gli hash sono utili solo per questo se puoi fidarti dell'hash più di quanto puoi fidarti del file; mentre a volte è così (torrent, mirror), sono spesso usati quando non è così. Quindi dovresti stare molto attento quando usi gli hash per la verifica dell'integrità.

Devi distinguere tra un attacco di collisione e un attacco preimage . Trovare due messaggi qualsiasi che abbiano lo stesso valore è un attacco di collisione.
Sostituire un particolare messaggio dato (qui: un eseguibile) con un altro messaggio che ha lo stesso hash è un (secondo) attacco preimage.

SHA-1 viene interrotto nella misura in cui un attacco di collisione può essere effettuato in 2 ⁵² operazioni secondo un articolo di Wikipedia che non fornisce una citazione per quel numero (l'attacco migliore di cui sono a conoscenza che è effettivamente credibile è quello di Marc Stevens , che richiede 2 ⁶⁰ operazioni). Ma supponiamo che il caso pessimistico di 2 ⁵² .

Ciò è preoccupante perché un attacco a quella scala non è solo teoricamente concepibile, ma è anche perfettamente realizzabile in meno di un giorno su un impianto multi-GPU. Questo è ovviamente un problema per le applicazioni in cui "qualsiasi due" messaggi farà. Anche la cifra di 2 ⁶⁰ data da Stevens (che è 256 volte più lavoro) è perfettamente fattibile se il tuo aggressore è disposto a buttare qualche soldo in più sul problema, o è disposto a passare un anno di tempo.
Che è esattamente il tipo di cosa che non impedisce a qualcuno coinvolto nello spionaggio o nella criminalità informatica di falsificare certificati.

Ora, un attacco preimage ha un esponente due volte più grande, quindi assumendo 2 ⁵² per l'attacco di collisione, sarebbero 2 ¹⁰⁴ operazioni, che è un campo di gioco completamente diverso.

Questo non è solo poco pratico (una macchina che è un miliardo di volte più veloce di quella menzionata nel paragrafo precedente impiegherebbe ancora circa 6 milioni di anni), ma dato il nostro mezzo per produrre energia è del tutto impossibile.

Fare un calcolo così massiccio richiederebbe una fonte di energia che è molto più grande di qualsiasi cosa possiamo permetterci di dedicare a una singola operazione. No, non abbastanza una fonte di energia delle dimensioni del sole, ma comunque abbastanza grande .

Puoi realisticamente aspettarti di ottenere da 10 a 50 GFLOPS su un Watt. Supponendo che avvenga una sorta di miracolo e che i processori ottengano circa diverse migliaia di volte più efficienti dal punto di vista energetico durante la notte, si potrebbe ipotizzare 1 SHA ≈ 1 FLOP (abbastanza ottimista!). Ciò significherebbe che per eseguire 2 ¹⁰⁴ calcoli di hash entro 10 anni, è necessaria una centrale da 10 ¹² W. Per eseguire l'attacco entro 1 anno, è necessaria una centrale da 10 ¹³ W. È circa 50 volte quello che possono produrre insieme tutte le centrali nucleari di Stati Uniti, Francia e Giappone, solo per forgiare un singolo hash.

Questo non accadrà , ci sono modi molto più semplici per raggiungere lo stesso obiettivo (sfruttando il server che memorizza l'hash originale e sostituendo quello, ricattando qualcuno, ecc.).

Il punto generale dell'articolo a cui si fa riferimento nella domanda è: SHA1 è obsoleto e dovrebbe essere gradualmente eliminato mentre si ha ancora tempo per farlo senza problemi. In alcune aree, il tempo sta scadendo da quando Google e Microsoft applicano le scadenze.

Regola empirica per la tecnologia obsoleta :

• Se esegui un nuovo design o aggiungi funzionalità, non utilizzarlo (SHA1).
• Se mantieni qualcosa di vecchio, fai un piano per sostituirlo (SHA1).

Citazione di sintesi dal post sul blog 2012 di Bruce Schneier .: "Il punto è che nella comunità dobbiamo iniziare subito la migrazione da SHA-1 a SHA-2 / SHA-3".

Per la parte della collisione dell'hash SHA-1 della tua domanda, questo è stato risolto da alcune delle risposte.

Tuttavia, gran parte di questo dipende dal tipo di file con cui stiamo lavorando:

Mantiene il contenuto e le operazioni generali del file (ma ovviamente include ora contenuti dannosi che inizialmente non erano contenuti modificati)

Che cosa significa varia notevolmente su ciò che sta rilevando le alterazioni:

• Se è un eseguibile firmato, non una (ragionevole) possibilità: dovresti ottenere in qualche modo due collisioni di hash: lo SHA-1 del file e la firma interna .exe.
• Se si tratta di un eseguibile senza segno, .com, .dll senza segno o simile, è possibile aggiungere le loro forcelle di risorse in modi che non cambieranno il loro funzionamento e quindi potresti (eventualmente) ottenere una collisione di hash che non è rilevabile da 'normale' operazione.
• Se si tratta di un file di codice sorgente o di una struttura simile (.cs, .c, .h, .cpp, .rb, .yml, .config, .xml, .pl, .bat, .ini) le aggiunte, le modifiche o le rimozioni può essere vincolato a una sintassi dei commenti valida in modo tale che la modifica non sia riconoscibile dalla maggior parte degli usi (compilazione o esecuzione, non apertura con un editor di testo).
• Se si tratta di un formato .iso o .zip o altro formato contenitore, è anche più improbabile poiché la maggior parte delle modifiche casuali danneggia il contenitore. È possibile fare: aggiungere una voce di file fasullo o modificare un contenuto all'interno del contenitore e ricontrollarlo, ma si sta aggiungendo un livello di complessità e si aggiunge tempo aggiuntivo per controllare il risultato, oltre ad avere gradi di libertà limitati rispetto a come e quali contenuti possono essere modificati.
• Se si tratta di un formato di testo o simile a un testo, possono essere modificati quasi come desideri, pur essendo comunque un file "valido", anche se il contenuto sarà probabilmente evidente.
• Con molti formati come .rtf, .doc, .html, .xslx e altri formati markup-esque, possono essere aggiunti o modificati in modi che non saranno rilevabili dai parser, quindi diversi dalla lunghezza (o anche con una lunghezza limitata , meno libertà) i file possono essere modificati per (eventualmente) ottenere una collisione dell'hash pur rimanendo non solo un file valido, ma non notevolmente modificati in alcun modo che sarebbero visibili alle applicazioni tipiche con cui verrebbero utilizzati.

Quindi, ciò che ti rimane è come ottenere collisioni in qualsiasi struttura non corrompente e un certo grado di non rilevabile forse:

1. Apporta le modifiche funzionali che desideri (magari inserendo contenuti dannosi) e apporta eventuali modifiche aggiuntive per conservare la validità specifica del formato file
2. Aggiungi una sezione che non funzionerà (tra i blocchi di commenti, alla fine di un file di testo con 3k ritorni a capo sopra di esso, isola un blocco di commenti corrente)
3. Aggiungi o seleziona un carattere / codice punto / byte per la modifica e prova ogni possibile combinazione valida (non tutte le combinazioni di byte sono valide per codifiche diverse, ad esempio).
4. Ricalcola l'hash, vedi se la collisione corrisponde.
5. in caso contrario, vai a 3.

Supponiamo che tu abbia un computer superveloce e un file di dimensioni ridotte, in modo tale che la modifica con una sequenza di byte valida e il ricalcolo dell'hash richieda 1 millisecondo (probabilmente richiede un hardware dedicato). Se la distribuzione dell'hash è perfettamente casuale e distribuita su tutto l'intervallo, si otterrà una collisione con SHA-1 ogni 2^160tentativo (costringendolo bruto).

2^160/1000/60/60/24/365.24 
= 4.63x10^37 years 
= 46,300,000,000,000,000,000,000,000,000,000,000,000 years 
= 46 undecillion years.

Ma hey, proviamo le versioni 2^60e 2^52, e facciamo finta che ci permettano di modificare il file come ci piace (loro no) e che anche loro possono essere fatti in 1ms ogni tentativo:

2^52 yields 142,714 years 
/*humans might still be around to care, but not about these antiquated formats*/
2^60 yields 3.65x10^7 years = 36,500,000 years 
/*machines will probably have taken over anyway*/

Ma ehi, potresti essere fortunato. Davvero, davvero, più di un miracolo di qualsiasi cosa la gente chiami miracoli fortunati.

Non proprio, puoi soddisfare una di quelle condizioni alla volta, ma non entrambe .. è possibile ottenere lo stesso hash per due file diversi ma per qualcuno modificare un file e quindi provare a ottenere lo stesso hash è praticamente impossibile come per quanto ne so

Sì, è possibile. Pensa a come funzionano i virus su EXE. Il payload del malware viene aggiunto all'exe originale, in modo che il programma faccia ancora quello che ha fatto originariamente, ma si diffonde anche come virus. Ora, per mantenere lo stesso hash, avrai bisogno di un'imbottitura aggiuntiva appositamente realizzata .

Ciò significa che il file sarebbe più grande. Ma nel caso di un EXE, forse potresti rimuovere parte del codice meno utilizzato, in modo che il programma sembrerebbe funzionare inizialmente solo. Nel caso di un JPEG, è possibile comprimere ulteriormente l'immagine o utilizzare un'immagine completamente diversa. Per un ISO, è possibile rimuovere set di file. I calcoli necessari per replicare l'hash sarebbero più difficili e forse matematicamente impossibili per casi specifici, ma sarebbero comunque possibili in generale.