Il 23 febbraio 2017 i ricercatori del CWI Amsterdam (il centro nazionale olandese per la matematica e l’informatica) e di Google annunciarono un risultato atteso da tempo e a lungo solo teorizzato: la prima collisione pratica per la funzione hash SHA-1. Il progetto prese il nome di SHAttered, un gioco di parole tra SHA e l’inglese shattered, in frantumi.<\/p>\n
Per la prima volta non si trattava di una previsione su carta o di una stima di costo, ma di due file reali, prodotti e resi pubblici, che condividevano lo stesso valore SHA-1 pur essendo diversi. Era la dimostrazione concreta che SHA-1 non poteva pi\u00f9 essere considerato sicuro laddove serve resistenza alle collisioni.<\/p>\n
Una funzione hash crittografica comprime un input di qualsiasi dimensione in un’impronta di lunghezza fissa. Per SHA-1 l’impronta \u00e8 lunga 160 bit. Poich\u00e9 gli input possibili sono infiniti e le impronte sono in numero finito, \u00e8 matematicamente inevitabile che esistano input diversi con la stessa impronta. La garanzia di sicurezza non \u00e8 quindi che le collisioni non esistano, ma che siano talmente difficili da trovare da risultare praticamente irraggiungibili.<\/p>\n
Una collisione \u00e8 esattamente questo: due messaggi distinti che producono lo stesso digest. Quando un attaccante riesce a costruirne una a piacere, l’impronta smette di identificare in modo univoco un contenuto. E poich\u00e9 moltissimi sistemi di sicurezza trattano il digest come se fosse l’identit\u00e0 del dato, le conseguenze sono profonde.<\/p>\n
Conviene distinguere due nozioni che vengono spesso confuse. Trovare una seconda preimmagine significa partire da un messaggio dato e cercarne un altro con la stessa impronta: un compito difficilissimo, perch\u00e9 il primo documento \u00e8 fissato in anticipo. Trovare una collisione, invece, lascia all’attaccante la libert\u00e0 di scegliere entrambi i messaggi, e questo allarga enormemente lo spazio di manovra. Per ragioni legate alla statistica delle coincidenze (il cosiddetto paradosso del compleanno), cercare una collisione \u00e8 intrinsecamente pi\u00f9 facile che cercare una preimmagine, ed \u00e8 proprio su questo terreno pi\u00f9 debole che SHA-1 ha ceduto per primo.<\/p>\n
Si pensi a una firma digitale. Non si firma l’intero documento, ma il suo digest. Se un attaccante prepara due documenti con la stessa impronta, uno innocuo e uno malevolo, pu\u00f2 far firmare il primo e poi presentare il secondo: la firma resta valida per entrambi, perch\u00e9 matematicamente vede solo l’impronta condivisa. Lo stesso ragionamento vale per i certificati, per i pacchetti software firmati e per i sistemi di controllo versione che identificano gli oggetti tramite hash. Trovare una collisione significa poter sostituire un contenuto con un altro senza che i controlli se ne accorgano.<\/p>\n
La dimostrazione di SHAttered fu deliberatamente concreta e facile da verificare. I ricercatori pubblicarono due file PDF dall’aspetto diverso che, passati attraverso SHA-1, restituiscono lo stesso identico valore:<\/p>\n
38762cf7f55934b34d179ae6a4c80cadccbb7f0a\n<\/code><\/pre>\nChiunque pu\u00f2 scaricare i due documenti e calcolarne l’hash SHA-1 per constatare che coincide. Si tratta di shattered-1.pdf<\/a> e shattered-2.pdf<\/a>.<\/p>\nIl dettaglio cruciale \u00e8 che la collisione esiste solo sotto SHA-1. Se si calcola il digest degli stessi due file con SHA-256, una funzione della famiglia SHA-2 considerata tuttora sicura, i due valori risultano completamente diversi. Questo isola con precisione il problema: non \u00e8 il formato PDF a essere difettoso, e non sono i file a essere identici, ma \u00e8 proprio SHA-1 come algoritmo a non offrire pi\u00f9 la resistenza alle collisioni che ci si aspetta da una funzione hash crittografica.<\/p>\n
La scelta del PDF non fu casuale. Il formato consente di inserire contenuti che non vengono mostrati a schermo, e questo lascia margine per costruire due documenti dall’aspetto differente che convergono comunque sullo stesso digest. \u00c8 il tipo di costruzione che rende l’attacco pericoloso nel mondo reale, dove un avversario vuole produrre coppie utili e non solo dati casuali.<\/p>\n
Vale la pena soffermarsi su un aspetto tecnico. L’attacco di SHAttered \u00e8 quello che si definisce una collisione a prefisso identico: i due file possono iniziare con lo stesso blocco di dati e divergere a partire da una porzione costruita appositamente, contenente le differenze calcolate per far collidere le impronte. In un documento ricco come un PDF, queste differenze possono essere nascoste e usate per pilotare ci\u00f2 che viene effettivamente mostrato, cos\u00ec da ottenere due versioni che appaiono distinte all’occhio umano ma identiche agli occhi di SHA-1. \u00c8 questa capacit\u00e0 di controllare il contenuto visibile, e non solo di generare due blob casuali, a trasformare una curiosit\u00e0 matematica in una minaccia operativa.<\/p>\n
Lo sforzo di calcolo dietro l’attacco<\/h2>\n
Dimostrare la collisione non fu affatto economico. L’attacco richiese circa 9,2 quintilioni di calcoli SHA-1, ovvero 9,2 miliardi di miliardi di operazioni. Per dare un’idea concreta di questa mole, gli autori la tradussero in tempo macchina: all’incirca 6.500 anni di CPU sommati a circa 110 anni di GPU.<\/p>\n
Naturalmente nessuno attese millenni. Quei tempi furono distribuiti su grandi quantit\u00e0 di hardware in parallelo, riducendo la durata effettiva a una scala gestibile per un’organizzazione dotata di risorse di calcolo importanti. Il punto, per\u00f2, non era la velocit\u00e0: era la fattibilit\u00e0. Un attacco che fino a quel momento veniva descritto come teoricamente possibile ma proibitivamente costoso si rivelava finalmente alla portata, perlomeno di chi disponeva di un’infrastruttura adeguata.<\/p>\n
Va sottolineato anche un aspetto economico. Il costo del calcolo tende a diminuire nel tempo, mentre le tecniche di attacco migliorano. Una collisione che nel 2017 richiedeva uno sforzo enorme sarebbe diventata progressivamente pi\u00f9 accessibile, il che rese impossibile rimandare ancora la dismissione di SHA-1.<\/p>\n
Le conseguenze: la dismissione accelerata di SHA-1<\/h2>\n
L’effetto pi\u00f9 immediato di SHAttered fu accelerare l’abbandono di SHA-1, un processo che era gi\u00e0 stato avviato ma che la dimostrazione pratica rese improrogabile.<\/p>\n
Nei certificati TLS, quelli che proteggono le connessioni HTTPS, SHA-1 era gi\u00e0 in via di pensionamento da parte dei principali browser. La collisione conferm\u00f2 che la decisione era corretta e ne consolid\u00f2 l’attuazione: un certificato fondato su un algoritmo con collisioni dimostrate non pu\u00f2 garantire l’autenticit\u00e0 che dovrebbe assicurare.<\/p>\n
Anche il mondo del controllo versione fu toccato direttamente. Git, lo strumento pi\u00f9 diffuso per la gestione del codice sorgente, identifica i propri oggetti tramite hash SHA-1. SHAttered spinse il progetto ad aggiungere contromisure di rilevamento delle collisioni e a pianificare la transizione verso una funzione hash pi\u00f9 solida, per evitare che un attaccante potesse sostituire commit o file sfruttando coppie costruite ad arte.<\/p>\n
Lo stesso vale per la firma del software e dei documenti in generale. Qualsiasi sistema che si affidasse a SHA-1 per garantire che un contenuto firmato non fosse stato alterato divenne sospetto, e la migrazione verso SHA-256 e le altre varianti di SHA-2 si fece prioritaria. Il meccanismo del rischio \u00e8 diretto: una firma digitale viene applicata al digest del contenuto, non al contenuto per intero, quindi due file che collidono sotto SHA-1 condividono di fatto la stessa firma. Una firma raccolta su un documento innocuo pu\u00f2 cos\u00ec risultare valida anche su una versione malevola costruita per collidere, e l’intera garanzia di autenticit\u00e0 si svuota.<\/p>\n
\u00c8 utile chiarire anche ci\u00f2 che SHAttered non implica. La collisione riguarda la resistenza alle collisioni, non la resistenza alla preimmagine: l’attacco non permette, dato un digest qualsiasi gi\u00e0 esistente, di ricostruire un input che lo produca. In altre parole, un avversario non pu\u00f2 prendere l’impronta di un file altrui e fabbricare al volo un secondo file che le corrisponda. Deve invece pianificare in anticipo entrambi i documenti della coppia. Questa distinzione, pur importante sul piano teorico, non attenua la gravit\u00e0 del risultato per tutti gli scenari in cui chi attacca controlla i contenuti da firmare, che sono moltissimi.<\/p>\n
L’eredit\u00e0 di SHAttered<\/h2>\n