SHA-1 come e quando è davvero un problema

An attacker creates an certificate for example.com and the SHA-1 value also equals X, so again, we have a collision, but this time it is not by any trustworthy CA!

La CA per un certificato è specificata dal campo emittente all'interno del certificato. Il certificato viene verificato cercando un certificato attendibile che abbia questo soggetto emittente come soggetto e quindi utilizzi questo certificato per convalidare la firma.

Ciò significa che se un utente malintenzionato ha un certificato valido che è stato firmato con SHA-1 da una CA attendibile e desidera utilizzare questa firma per il proprio certificato falso, il certificato falso deve avere entrambe le stesse informazioni sull'emittente del certificato originale e risultato nello stesso SHA-1. Se entrambi vengono dati, questo falso certificato è considerato attendibile come quello originale. Poiché l'autore dell'attacco ha il pieno controllo sul contenuto del certificato falso, ha anche il controllo del campo emittente e quindi può impostarlo secondo necessità.

C'è un sacco di allarmismo su SHA1 in corso.

Capire che ci sono diversi tipi di attacco su una funzione hash. L'attuale attacco di collisione su sha1 fa sì che l'attaccante faccia quanto segue.

1. Scegli un prefisso comune per i due file collidenti prima che generano i "blocchi di collisione".
2. Scegli un suffisso comune per i due file in collisione dopo che generano i "blocchi di collisione".

Questo è tipico degli attacchi di collisione iniziali trovati sulle funzioni hash merkle-damgaurd.

Tipicamente gli exploit per questo tipo di attacco di collisione prendono il seguente modulo.

1. L'utente malintenzionato sceglie un formato di file in cui è possibile nascondere facilmente i dati inutili e in cui è possibile implementare una logica ragionevole (il pdf è il figlio di poster).
2. L'utente malintenzionato costruisce un prefisso comune contenente l'intestazione pdf e un po 'di logica per saltare i blocchi di collisione.
3. L'attaccante genera i blocchi di collisione.
4. L'attaccante genera un suffisso comune distinto che esamina i blocchi di collisione e modifica il contenuto apparente del documento in base a quale dei blocchi di collisione è presente.
5. L'attaccante convince la vittima a firmare il documento "buono".
6. L'autore dell'attacco trapianta la firma sul documento "cattivo".

L'autore dell'attacco ora ha una copia del documento "malvagio" apparentemente firmato dalla vittima. Può usare quel documento per convincere le persone che la vittima ha accettato qualcosa che in realtà non era d'accordo.

Ora, in che modo si riferisce alle CA?

L'attaccante ha l'obiettivo di trasferire una firma da un certificato legittimo firmato da una CA a un certificato malvagio. Il certificato legittimo sarà per un dominio che l'utente malintenzionato possiede legittimamente, il certificato Malvagio potrebbe essere per un dominio che l'autore dell'attacco desidera impersonare o potrebbe essere un "certificato intermedio" che consente all'aggressore di firmare i certificati a piacimento per i domini che desidera impersonare.

Questo è molto più difficile dell'attacco descritto sopra per due motivi.

1. Le CA danno solo al cliente un controllo limitato sul contenuto dei certificati.
2. I formati di certificato Afaict non hanno spazio per il livello di logica complicata possibile in qualcosa come un pdf.

A causa di ciò, non credo che sarebbe possibile sfruttare un attacco di collisione "semplice" contro una CA.

Più pericoloso è un attacco di collisione "distinto prefisso scelto". Nessun attacco di collisione prefisso distinto è attualmente noto per SHA1. Per MD5 ne è stato trovato uno circa 5 anni dopo che è stata trovata la prima collisione di base.

In questo caso l'attaccante può.

1. Scegli due prefissi distinti prima che generano i blocchi di collisione.
2. Scegli un singolo suffisso scelto comune dopo che genera i blocchi di collisione.

Un distinto attacco di collisione prefisso scelto è molto più pericoloso perché il contenuto del file "cattivo" non deve essere nascosto all'interno del file "buono". Solo un piccolo blocco di rifiuti apparentemente casuali deve essere nascosto. Significa anche che finché l'attaccante può prevedere la maggior parte del contenuto del file, è sufficiente che ne controllino solo una parte.

Tuttavia c'è ancora un problema, i certificati hanno un "numero di serie". Poiché il numero di serie è uno dei primi campi nel certificato, verrà inevitabilmente prima dei blocchi di collisione e quindi l'attaccante deve essere in grado di prevederlo in anticipo.

Il forum CA / browser richiede che le CA inseriscano almeno 64 bit di casualità nei loro numeri seriali. Se le CA seguono le regole dovrebbe essere virtualmente impossibile per l'attaccante predire il numero di serie.

OTOH se una CA è sciatta e non usa numeri seriali casuali, quindi sfruttare gli attacchi di collisione prefissi distinti scelti diventa più fattibile. Tale attacco è stato dimostrato con successo con MD5 da un gruppo di accademici. Una volta che l'attacco è stato dimostrato, la CA in questione ha iniziato a randomizzare i loro numeri di serie.

Se viene trovato un attacco di collisione prefisso scelto su SHA1 e l'attaccante può trovare una CA sufficientemente sciatta da poter creare un certificato SHA1 forgiato.

È apparentemente sufficiente che i produttori di browser decidano di eliminare SHA1.

L'ultimo attacco a una funzione di hash sarebbe un attacco preimage. Con un tale attacco l'attaccante potrebbe trapiantare una firma da qualsiasi certificato esistente sul nuovo certificato. Tuttavia, gli attacchi di preimage sono molto più difficili degli attacchi di collisione. L'afaict anche con gli attacchi di preimage MD5 è ancora computazionalmente impossibile.

Un attacco di collisione pratico contro l'infrastruttura PKI Web è stato già dimostrato nel 2008 , sfruttando le CA che ancora usato MD5. La struttura generale dell'attacco era:

1. Crea due richieste di firma del certificato progettate per collidere: una onesta per un sito web legittimo e una disonesta che impersonica una CA intermedia ed è quindi autorizzata a emettere certificati .
2. Invia il CSR onesto a una CA. Poiché è un CSR legittimo, la CA emetterà un certificato onesto per questo.
3. Combina la firma sul certificato onesto e il CSR disonesto per creare un certificato CA intermedio forgiato.
4. Utilizza il certificato falsificato per emettere i certificati che desideri, per qualsiasi sito desideri.

La pagina ha i dettagli nitidi, ma questo illustra la forma generale degli attacchi di collisione contro le firme digitali: il problema è che se Eva può convincere Alice a firmare un documento legittimo che è stato creato per scontrarsi con una falsificazione, allora Eve può usare la firma legittima per convincere Bob che Alice ha firmato il documento contraffatto. Nell'attacco PKI web, Alice è una CA e Bob è un browser Web.

Gli attacchi di collisione contro MD5 che hanno permesso questo attacco erano più potenti dell'attacco di oggi su SHA1, quindi oggi non siamo in grado di effettuare un simile attacco contro i certificati SHA1. Ma un principio chiave qui è che dovremmo anticipare gli attacchi prima che si verifichino , non solo reagire a loro dopo che sono stati su di noi. Il fatto che sia stata trovata una collisione per SHA1 significa che è probabile che arriveranno attacchi più potenti nel prossimo futuro, quindi dovremmo abbandonare SHA1.

Per usare la cronologia come esempio, la prima collisione MD5 è stata trovata nel 2004, quattro anni prima del pratico attacco PKI web di cui sopra. Non sappiamo quando verranno trovati (o sono già stati trovati) analoghi attacchi migliorati contro SHA1, né quanto grande sarà la nostra finestra tra una scoperta segreta e una conoscenza pubblica.