Strumenti per sviluppatori · SHA calcolatore hash
SHA-1 Spiegazione delle collisioni: cosa è ancora sicuro e cosa deve migrare
· Perché è importante
sha-256 crittografia sicurezza
Uno scanner segnala SHA-1 e la direzione chiede quanto sia urgente. Questo post spiega cosa fa e cosa non interrompe un attacco di collisione, dove SHA-1 è ancora tollerato e come pianificare una migrazione.
Lo scanner dice che SHA-1 è rotto, ma rotto per cosa? La domanda che decide l'urgenza della migrazione
Uno scanner di sicurezza di rete contrassegna SHA-1 sulla tua infrastruttura. La direzione chiede quanto sia urgente. La risposta dipende interamente dallo scopo per cui stai utilizzando SHA-1 e la domanda rivela se hai un problema di conformità, un problema di sicurezza attivo o semplicemente un artefatto legacy che deve essere catalogato. SHA-1 è crittograficamente rotto: dimostrazioni accademiche hanno dimostrato collisioni. Ma "rotto" significa cose diverse a seconda del ruolo che SHA-1 gioca nel tuo sistema.
Un hash crittografico ha scopi diversi in contesti diversi. A volte è un checksum che protegge dalla corruzione accidentale. A volte si tratta di un impegno, come un checksum di download pubblicato che consente agli utenti di verificare di aver ricevuto il file previsto dall'editore. A volte fa parte di una catena di firme o certificati, in cui un utente malintenzionato con sufficiente controllo può produrre due documenti, entrambi significativi, che condividono lo stesso hash e quindi falsificare l'autenticazione. La gravità di una collisione SHA-1 dipende in modo critico da quale di questi ruoli SHA-1 ha nel tuo sistema.
Collisione o preimmagine: perché gli attacchi pubblicamente dimostrati prendono di mira le collisioni e cosa significa per un hash esistente
Un attacco di collisione produce due input diversi con lo stesso output. Un utente malintenzionato non trova un messaggio con un valore hash predeterminato: si tratterebbe di un attacco preimmagine e rimane irrealizzabile per SHA-1. Invece, un attacco di collisione significa che l’aggressore può creare due documenti con lo stesso hash. Se un sistema si basa su un hash per dimostrare che due cose sono identiche, una collisione infrange tale prova. L’attaccante deve creare entrambi gli input, il che richiede tempo e calcoli, ma il risultato è che due cose distinte appaiono identiche sotto l’hash.
Un attacco preimmagine significherebbe che un utente malintenzionato potrebbe prendere un hash SHA-1 pubblicato e trovare alcuni input che lo corrispondono. Non è così che funzionano gli attacchi SHA-1. Se disponi di un repository di digest SHA-1 e ti preoccupi se un file li corrisponde davvero, un attacco di collisione non è la minaccia. Il pericolo è che qualcuno con accesso al tuo repository possa creare un file diverso nello stesso digest. Nella maggior parte dei casi, anche questo non è realistico senza il controllo del processo di hashing stesso. Il modello di attacco specifico conta tanto quanto l’algoritmo.
Le dimostrazioni di 2017: due file diversi con lo stesso SHA-1, descritti qualitativamente, e il lavoro con il prefisso scelto che ne è seguito
L'attacco SHAttered di 2017 ha dimostrato una collisione pratica: due diversi file PDF con lo stesso digest SHA-1. I ricercatori hanno costruito attentamente entrambi i file, trasformandoli in PDF validi durante la collisione. Il lavoro ha richiesto un notevole sforzo computazionale e hardware specializzato. Ciò che conta è che sia stato possibile: la resistenza alle collisioni che giustifica l'utilizzo di SHA-1 per la sicurezza è scomparsa. L'attacco ha dimostrato che due documenti semanticamente diversi potrebbero condividere un digest, il che distrugge qualsiasi sistema che si fida del digest come prova di identità.
L'attacco seguito in 2020, chiamato "SHA-1 is a Shambles", ha compiuto il passo successivo: collisioni con il prefisso scelto. Questa variante significa che un utente malintenzionato può prendere due documenti arbitrari, concatenare suffissi diversi a ciascuno e produrre una collisione. Questo è il pericoloso attacco alle firme e ai certificati. Un utente malintenzionato non deve necessariamente iniziare da zero; possono far scontrare due documenti significativi e distinti. Ciò rompe il modello di sicurezza di qualsiasi sistema che firma digest SHA-1. L'aggressore può produrre due documenti che hanno lo stesso hash ed entrambi significano qualcosa di diverso.
Laddove SHA-1 è inaccettabile: firme, certificati e tutto ciò che un utente malintenzionato può influenzare entrambi i lati
La distinzione è importante perché SHA-1 è ancora tollerabile in alcuni ruoli e assolutamente inaccettabile in altri. In Git, SHA-1 viene utilizzato come indirizzo di contenuto, un nome per una particolare istantanea di file. Git non utilizza SHA-1 per l'autenticazione; è uno schema di denominazione. Un utente malintenzionato potrebbe teoricamente calcolare due diversi stati del repository con lo stesso ID, ma ciò richiede il controllo dell'intero processo di creazione del contenuto e il push di entrambe le versioni prima che qualcuno se ne accorga. Per la maggior parte dei team, questo livello di controllo degli aggressori non rappresenta il modello di minaccia. Questo è il motivo per cui Git sta passando deliberatamente a SHA-256 invece di trattarlo come un'emergenza.
In uno scenario di verifica del download Web, un editore pubblica un file e il relativo checksum SHA-1 sullo stesso server. Un utente malintenzionato che compromette quel server controlla sia il file che il checksum. Possono caricare un file e pubblicarlo SHA-1 e non è richiesta alcuna collisione. Se il checksum viene pubblicato altrove, su un VPN sicuro, stampato in un'e-mail firmata, pubblicato in un'infrastruttura diversa, allora l'aggressore deve scontrarsi e ciò diventa impossibile. Il checksum è affidabile tanto quanto il suo canale. Questo è il motivo per cui la verifica del download richiede più di un hash.
Dove permane con meno rischi: identificazione dei contenuti in contesti non contraddittori e transizione graduale di Git a SHA-256
Per firme e certificati, SHA-1 è indifendibile. Un certificato si concatena da una radice attendibile. Se una CA firma due certificati diversi utilizzando lo stesso digest SHA-1, un attacco di collisione consente a un utente malintenzionato di falsificarli entrambi. Questo non è teorico: sono stati documentati attacchi contro CA intermedie. Qualsiasi schema di firma che si basa su SHA-1 è potenzialmente falsificabile da un utente malintenzionato con risorse sufficienti. Tutti i principali fornitori di browser e sistemi operativi hanno deprecato SHA-1 nei certificati. I nuovi certificati devono utilizzare SHA-256. I venditori della piattaforma hanno parlato chiaramente perché la minaccia è reale e immediata.
NIST, l'ente statunitense per gli standard, ha stabilito una tempistica esplicita. A partire da 2024, SHA-1 non deve essere utilizzato per nessuna nuova applicazione. A partire dal 2030, si prevede che SHA-1 verrà ritirato completamente dai sistemi federali. Questa non è una vaga deprecazione; è un mandato concreto per gli appaltatori pubblici e un segnale per l’industria. Il rispetto della sequenza temporale di NIST garantisce che i tuoi sistemi rimangano un passo avanti rispetto alla curva di deprecazione anziché affrettarsi dopo la scadenza.
Le prove del repository supportano la deprecazione di SHA-1, non una pubblicazione NIST non letta o una data di ritiro
I documenti di origine del repository SHA-1 poiché l'interoperabilità e i nomi legacy hanno dimostrato il lavoro di collisione, ma non contengono un programma di ritiro degli organismi di standardizzazione. Questa sezione pertanto corregge la struttura trattando la deprecazione come un problema di inventario tecnico anziché citare un numero di pubblicazione o una data di conformità non letti.
Per gli ambienti controllati da policy, consultare l'autorità che governa tale distribuzione e registrare l'esatto documento esaminato. Le prove del prodotto qui supportano un'azione più ristretta: mantenere SHA-1 disponibile per riprodurre i valori esistenti, etichettarlo come inadatto per nuovi usi di sicurezza e calcolare una sostituzione SHA-256 ovunque il protocollo circostante consenta la migrazione.
Esempio funzionante: un elenco di controllo della migrazione applicato a una pagina di verifica dei download legacy
Un percorso di migrazione da SHA-1 inizia solitamente con un inventario: dove viene utilizzato SHA-1? Certificati e firme? Priorità immediata. Repository Git e indirizzamento dei contenuti? Priorità media, segui il ritmo della migrazione Git. Checksum pubblicati per i download? Dipende dal modello di fiducia. Checksum interni per la deduplicazione o l'archiviazione? Priorità inferiore, più tempo per la pianificazione. La fase di inventario rivela la reale superficie e aiuta a stabilire le priorità in base al rischio reale piuttosto che all'urgenza astratta.
Per ogni ruolo, la migrazione ha un aspetto diverso. I certificati vengono aggiornati a SHA-256 immediatamente. I repository Git vengono inseriti gradualmente nei riferimenti SHA-256 mantenendo SHA-1 per la compatibilità con le versioni precedenti. I checksum dei download iniziano a essere pubblicati sia in SHA-1 che in SHA-256, poi alla fine solo in SHA-256. I digest SHA-1 legacy in un database di checksum possono essere verificati con il calcolatore hash ToolAcre SHA e le nuove voci dovrebbero utilizzare SHA-256. Lo strumento supporta entrambi i lati della transizione, consentendoti di verificare i vecchi hash e crearne di nuovi.
Conclusione: SHA-1 per confronto, SHA-256 per nuovo lavoro: il calcolatore hash ToolAcre SHA include SHA-1 in modo che i digest legacy possano essere controllati, non come approvazione
Per la maggior parte delle organizzazioni, la migrazione non significa "disattivare SHA-1 domani". Si tratta di "capire dove viene utilizzato, dare priorità ai ruoli critici per la sicurezza e avere un piano pluriennale". Un repository Git con anni di commit SHA-1 dovrebbe effettuare la transizione gradualmente, con strumenti che gestiscano entrambi. Un'infrastruttura di certificato dovrebbe essere già migrata. I checksum pubblicati dovrebbero essere a doppio algoritmo durante una finestra di transizione. La migrazione graduale riduce i cambiamenti radicali e dà ai sistemi il tempo di adattarsi alla nuova realtà.
Il calcolatore hash ToolAcre SHA fornisce entrambi i lati di tale transizione. Puoi verificare i digest SHA-1 esistenti dai tuoi sistemi legacy per confermare che un file li corrisponda. Puoi calcolare gli hash SHA-256 per iniziare a pubblicare il percorso di migrazione. Lo strumento non pretende che SHA-1 sia sicuro; lo etichetta come rotto e spiega il motivo. Ma ti consente di lavorare con gli hash legacy che devi ancora mantenere mentre costruisci il ponte verso SHA-256 e pianifichi la tua deprecazione.