Strumenti per sviluppatori · SHA calcolatore hash
Un checksum corrispondente non è una firma: integrità vs autenticità
· Perché è importante
sha-256 crittografia sicurezza
Un SHA-256 pubblicato consente agli utenti di rilevare un download danneggiato, ma se l'aggressore controlla la pagina, controlla anche il checksum. Questo post separa l'integrità dall'autenticità e spiega cosa aggiungono le firme.
Il checksum nella stessa pagina del download: perché protegge dalla corruzione ma non da un host compromesso
Una versione software viene pubblicata con un checksum SHA-256 nella stessa pagina del download. Gli utenti possono recuperare l'archivio, sottoporlo ad hashing e confrontare il risultato con il valore pubblicato. Se corrispondono, il download non è danneggiato. Questa è la verifica dell'integrità ed è un controllo reale e utile. Tuttavia, se un utente malintenzionato compromette il server Web che ospita la versione, può sostituire il file binario, ricalcolarne SHA-256 e aggiornare il checksum sulla pagina. L'utente verifica il checksum e il malware dell'aggressore sembra provenire dall'editore. Il sistema ha funzionato esattamente come previsto, ma non è riuscito a rispondere alla domanda che l'utente pensava di porre.
Questo non è un errore del checksum stesso. È un'osservazione corretta su cosa fa e cosa non fa un checksum. Un checksum dimostra che due copie di dati sono identiche. Non dimostra chi ha creato i dati. Questa è la distinzione tra integrità e autenticità e la loro fusione è uno degli errori di sicurezza più comuni nella verifica del rilascio. Molti sistemi non funzionano perché i loro checksum sono errati, ma perché gli utenti si fidano di loro per rispondere a domande a cui non possono rispondere.
Ciò che dimostra un hash: che due input sono gli stessi byte e nulla su chi li ha prodotti
L'integrità è una proprietà dei dati stessi. Se hai un file e il suo SHA-256 e il file non è stato modificato, l'hash corrisponde. L'hash dimostra che ogni byte è rimasto invariato rispetto a quando è stato calcolato. Se il file è stato danneggiato da un errore di trasmissione, da un guasto del disco o da un bit invertito su un cavo di rete, l'hash non corrisponderà. Questo è ciò che fanno bene i checksum. Sono eccellenti nel rilevare incidenti e corruzione casuale. Falliscono contro un avversario che può anche calcolare gli hash.
L'autenticità è una proprietà dell'affermazione su chi ha prodotto i dati. La domanda "questo file proviene dall'editore di cui mi fido?" è fondamentalmente diverso dalla domanda "questo file è stato modificato?" Un hash da solo non può rispondere alla domanda di autenticità perché chiunque può calcolarlo. L'aggressore che modifica il file può calcolare il nuovo hash e pubblicarlo con la stessa facilità con cui potrebbe farlo l'editore legittimo. L'hashing è simmetrico; sia il difensore che l'attaccante hanno la stessa capacità computazionale.
Il requisito del canale affidabile: perché un checksum è affidabile tanto quanto il luogo in cui lo hai ottenuto
Il requisito del canale affidabile è la chiave di lettura. Un checksum è affidabile tanto quanto il canale attraverso il quale è arrivato. Se scarichi il binario del software dal CDN ufficiale dell'editore e scarichi il checksum dallo stesso server, hanno percorso lo stesso percorso. Compromettere il server significa che un utente malintenzionato controlla entrambi. Il checksum fornisce difesa contro la corruzione durante la consegna (un file danneggiato non corrisponderà) ma non contro un utente malintenzionato che controlla l'origine. Il checksum e il file condividono un singolo punto di errore.
Se il checksum fosse pubblicato separatamente, su un server diverso, con controlli di accesso diversi, fornirebbe una maggiore difesa. Un utente malintenzionato che compromette il sito primario dovrebbe compromettere entrambe le posizioni per falsificare una coppia corrispondente. Questo è meglio, ma si basa comunque sulla sicurezza di due punti di controllo indipendenti. L’aggressore deve ora violare due sistemi invece di uno, aumentando il costo dell’attacco. Ma non è ancora una prova di autenticità; è solo un attacco più costoso.
Le firme legano un hash a un'identità: il modo in cui firmare il digest con una chiave privata aggiunge autenticità
Una firma digitale risolve questo problema legando i dati a un'identità utilizzando la crittografia. L'editore genera una coppia di chiavi: una chiave privata che mantiene segreta e una chiave pubblica che pubblica. Firmano il file calcolando un digest e quindi crittografandolo con la loro chiave privata. Il risultato è la firma. Un utente verifica la firma decodificandola con la chiave pubblica dell'editore e controllando che il risultato corrisponda al digest calcolato del file ricevuto. La crittografia crea un'asimmetria che il checksum non può raggiungere.
Se funziona, sono dimostrate due cose: i dati corrispondono al digest firmato dall’editore e la chiave privata utilizzata per firmarlo corrisponde alla chiave pubblica pubblicata. Ciò dimostra che è stato l'editore a crearlo e non solo un utente malintenzionato. La chiave pubblica deve provenire attraverso un canale sicuro, in genere un certificato emesso da un'autorità di certificazione attendibile, ma una volta ottenuta la chiave pubblica, è possibile verificare le firme di quell'editore a tempo indeterminato. L’attacco ora richiede il furto della chiave privata, cosa molto più difficile che compromettere un server web.
Esempio funzionante: tre scenari di minaccia (mirror corrotto, pagina compromessa, insider dannoso) e quale checksum e firma vengono rilevati
Tre scenari di minaccia illustrano la differenza. Scenario uno: il mirror del download è danneggiato da un errore casuale. Il checksum lo rileva; la firma lo coglie. Entrambi funzionano ugualmente bene perché nessuno dei due ha bisogno di sconfiggere un aggressore. Scenario due: il mirror viene compromesso da un utente malintenzionato che sostituisce il file e il checksum. Il checksum non riesce a proteggere; la firma funziona comunque, perché l'aggressore non ha la chiave privata e non può falsificare una firma valida. L'aggressore può pubblicare qualsiasi cosa, ma la firma dimostra che non proviene dall'editore.
Scenario tre: CDN è compromesso ma la firma è stata pubblicata tramite un canale diverso. Il checksum su CDN non può essere considerato attendibile, ma la verifica della firma funziona comunque, poiché il controllo di integrità è crittograficamente legato alla chiave dell'editore, non al canale. L'aggressore deve ora falsificare una firma, che richiede la chiave privata. La firma è l'unica verifica che sopravvive alla compromissione del server. Ecco perché le firme sono necessarie per l'autenticità; sono l'unico strumento che dimostra l'identità nonostante la compromissione del canale.
Il ruolo di TLS e i suoi limiti: la sicurezza del trasporto protegge il download in volo, non il server dell'editore
La sicurezza del trasporto protegge la connessione all'host indicato dal certificato. Può impedire a un osservatore sul percorso di sostituire i byte di download, ma non può rendere onesta l'origine di un editore compromessa. Se tale origine fornisce un archivio modificato e un checksum appena calcolato su TLS valido, entrambi arrivano intatti e descrivono comunque contenuti controllati dall'aggressore.
Questo è il motivo per cui trasporto, integrità e autenticità sono livelli separati. TLS protegge un canale, un digest confronta i byte e una firma lega un risultato di verifica al controllo di una chiave privata. Nessun livello dovrebbe essere descritto come provante della proprietà fornita da un altro, anche quando un flusso di lavoro di rilascio li combina in modo sensato tutti e tre.
Ciò che questo non copre: distribuzione delle chiavi e radici di fiducia, che sono la parte difficile delle firme
La distribuzione delle chiavi è il confine rigido che questo calcolatore digest non oltrepassa. Un verificatore di firma necessita comunque di una chiave pubblica autentica o di una catena di certificati e di una politica di rotazione, revoca e algoritmi accettabili. Una firma matematicamente valida sotto una chiave non attendibile dimostra solo che il detentore di quella chiave non attendibile ha firmato i byte.
Di conseguenza, gli scenari elaborati si fermano dove è già disponibile una chiave attendibile. Non prescrivono il blocco dei certificati, l'infrastruttura a chiave pubblica o le cerimonie di rilascio della chiave. Tali scelte di distribuzione necessitano di una progettazione rivista; ToolAcre fornisce il semplice digest che può essere firmato, non la root di fiducia utilizzata per convalidare un'identità.
Conclusione: checksum per l'integrità, firme per l'autenticità: il calcolatore di hash ToolAcre SHA calcola i digest; verificare chi li ha pubblicati è un passaggio separato
Il calcolatore hash ToolAcre SHA calcola il lato integrità di questa verifica. Usalo per eseguire l'hashing del file scaricato e confrontarlo con un valore pubblicato. Se corrispondono, il download non è danneggiato. Ma se corrispondono perché un utente malintenzionato li ha riscritti entrambi, la sola verifica dell'integrità non sarà in grado di rilevarli. Lo strumento è onesto riguardo a questa limitazione e non pretende di verificare l'autenticità. Solo per l'integrità, i checksum sono rapidi e validi. Per l'autenticità, sono necessarie le firme. TLS fornisce la sicurezza del trasporto per il download stesso. La connessione al server è crittografata e autenticata, quindi un utente malintenzionato sulla rete non può modificare il file in transito. Tuttavia, TLS non aiuta se il server stesso è compromesso. Un server compromesso può servire qualsiasi file tramite qualsiasi connessione sicura TLS. Questo è il motivo per cui la verifica a livello di applicazione (checksum e firme) è importante separatamente dalla sicurezza del trasporto.
Uno schema comune nelle versioni software è quello di pubblicare sia checksum che firme. I checksum sono convenienti; gli utenti possono verificarli rapidamente con un comando shell di una riga. Le firme forniscono autenticità agli utenti che dispongono della chiave pubblica dell'editore. Un utente potrebbe prima controllare il checksum per un rapido passaggio di integrità, quindi verificare l'autenticità della firma rispetto a una chiave memorizzata nel proprio portachiavi GPG. I due controlli hanno scopi diversi e possono essere stratificati per una difesa approfondita. La parte difficile delle firme è la distribuzione e la fiducia delle chiavi. Hai bisogno della chiave pubblica dell'editore e devi avere fiducia che sia davvero la sua. Questo è il problema che le autorità di certificazione esistono per risolvere: firmano i certificati dell'editore e i certificati della CA radice vengono precaricati nei browser e nei sistemi operativi. Per un progetto più piccolo, potresti pubblicare una chiave GPG su un sito Web protetto e separato o su un server di chiavi pubbliche. Il checksum è economico da verificare; le firme richiedono la gestione delle radici di trust. La complessità aggiuntiva è il prezzo dell’autenticità.