Qual è il valore dei checksum MD5 se l'hash MD5 stesso potrebbe potenzialmente essere stato manipolato?

I download su siti Web a volte hanno un checksum MD5, che consente alle persone di confermare l'integrità del file. Ho sentito che ciò consente di identificare non solo i file danneggiati immediatamente prima che possano causare un problema, ma anche di rilevare facilmente eventuali modifiche dannose.

Seguo la logica per quanto riguarda la corruzione dei file, ma se qualcuno vuole deliberatamente caricare un file dannoso , potrebbe generare un checksum MD5 corrispondente e pubblicarlo sul sito di download insieme al file modificato. Ciò ingannerebbe chiunque scarichi il file pensando che fosse inalterato.

Come possono i checksum MD5 fornire alcuna protezione contro i file deliberatamente modificati se non c'è modo di sapere se il checksum stesso è stato compromesso?

Ho sentito questo per consentire [...] anche il rilevamento di eventuali modifiche dannose.

Bene, allora hai sentito male. I checksum MD5 (o SHA o altro) vengono forniti ( accanto ai collegamenti per i download, in particolare ) solo per verificare un download corretto. L'unica cosa che mirano a garantire è che hai lo stesso file del server. Niente di più, niente di meno. Se il server è compromesso, sei SOL. È davvero così semplice.

La soluzione utilizzata da alcuni sistemi di gestione dei pacchetti come dpkg è firmare l'hash : utilizzare l'hash come input per uno degli algoritmi di firma della chiave pubblica. Vedi http://www.pgpi.org/doc/pgpintro/#p12

Se si dispone della chiave pubblica del firmatario, è possibile verificare la firma, a dimostrazione che l'hash non è modificato. Questo ti lascia solo con il problema di ottenere in anticipo la giusta chiave pubblica, anche se una volta qualcuno manomette la distribuzione delle chiavi deve anche manomettere tutto ciò che potresti verificare, altrimenti noterai che sta succedendo qualcosa di strano.

Il tuo presupposto è corretto. C'è un'eccezione però. Se il server che fornisce il file e la pagina in cui si trova l'hash non sono gestiti dalla stessa entità. In tal caso, lo sviluppatore del software potrebbe voler dire "hey persone lo scaricano da quel posto ma credono solo se hash = xxxx". (Questo potrebbe essere utile per le CDN come esempio). Immagino che questo sia stato il motivo per cui qualcuno l'ha fatto in primo luogo. Gli altri hanno appena seguito pensando che sarebbe stato bello mostrare l'hash. Neanche a pensare a quanto sia utile, sia il file sia l'hash non si trovano nella stessa posizione.

Detto questo, vale la pena. Non dare troppa importanza alla sicurezza come già affermato da altri. Se e solo se puoi assolutamente fidarti dell'hash originale, allora il file è buono. Altrimenti un utente malintenzionato con sufficiente motivazione e conoscenza può manomettere sia il file sia l'hash, anche se questi si trovano in server diversi e gestiti da entità diverse.

A volte i checksum sono forniti in modo sicuro, ma il download non lo è. Poiché MD5 è rotto , i checksum MD5 di sicurezza forniti sono più deboli di checksum più sicuri, ma prima che MD5 fosse rotto, un MD5 fornito in modo sicuro (ad esempio uno che era stato firmato con PGP o GPG o Gatekeeper o recuperato su HTTPS) che corrispondeva a MD5 di il download era una prova evidente che il download ricevuto era quello che il server stava mettendo a disposizione.

Ho scritto per anni la deplorevole mancanza di checksum sicuri, qui .

Gli utenti non devono scaricare eseguibili non attendibili su reti non attendibili ed eseguirli, a causa del rischio di attacchi MITM. Vedere, ad esempio, "Insicurezze nei sistemi di aggiornamento automatico" di P. Ruissen, R. Vloothuis.

Addendum 2014: No, NON è sbagliato "che i checksum pubblicati su pagine Web vengano utilizzati per rilevare modifiche dannose", poiché questo è un ruolo che possono svolgere. Aiutano a proteggere dalla corruzione accidentale e se offerti su HTTPS o con una firma verificata (o meglio ancora, entrambi) aiutano a proteggere dalla corruzione malevola! Ho ottenuto checksum su HTTPS e verificato che corrispondevano a download HTTP molte volte.

Al giorno d'oggi, i binari sono spesso distribuiti con hash firmati e verificati automaticamente, ma anche questo non è perfettamente sicuro .

Estratto dal link sopra: "L'applicazione KeRanger è stata firmata con un certificato di sviluppo di app Mac valido, pertanto è stata in grado di aggirare la protezione di Apple Gatekeeper." ... "Da allora Apple ha revocato il certificato abusato e aggiornato la firma antivirus XProtect e Transmission Project ha rimosso gli installatori malevoli dal suo sito Web. Palo Alto Networks ha anche aggiornato il filtro URL e la prevenzione delle minacce per impedire a KeRanger di avere un impatto sui sistemi. Analisi tecnica

I due installatori della trasmissione infetti da KeRanger sono stati firmati con un certificato legittimo rilasciato da Apple. Lo sviluppatore ha elencato questo certificato è una società turca con ID Z7276PX673, che era diverso dall'ID sviluppatore utilizzato per firmare le versioni precedenti del programma di installazione di Transmission. Nelle informazioni sulla firma del codice, abbiamo riscontrato che questi programmi di installazione sono stati generati e firmati la mattina del 4 marzo. "

Addenda 2016:

@Cornstalks: Re. il tuo commento qui sotto: sbagliato. Come attualmente notato nell'articolo Wikipedia relativo all'attacco di collisione a cui ti colleghi, "Nel 2007, è stato trovato un attacco di collisione a prefisso scelto contro MD5" e "l'attaccante può scegliere due documenti arbitrariamente diversi e quindi aggiungere valori calcolati diversi che risultano nel documenti con un valore di hash uguale ". Pertanto, anche se MD5 viene fornito in modo sicuro e un utente malintenzionato non può modificarlo, un utente malintenzionato può comunque utilizzare un attacco di collisione con prefisso scelto con un prefisso scelto contenente malware, il che significa che MD5 NON è sicuro per scopi crittografici. Questo è in gran parte il motivo per cui US-CERT ha affermato che MD5 "dovrebbe essere considerato crittograficamente rotto e inadatto per un ulteriore utilizzo".

Un altro paio di cose: CRC32 è un checksum. MD5, SHA, ecc. Sono più che checksum; sono destinati ad essere hash sicuri. Ciò significa che dovrebbero essere molto resistenti agli attacchi di collisione. A differenza di un checksum, un hash sicuro comunicato in modo sicuro protegge da un attacco man-in-the-middle (MITM) in cui il MITM si trova tra il server e l'utente. Non protegge da un attacco in cui il server stesso è compromesso. Per proteggersi da ciò, le persone in genere si affidano a qualcosa come PGP, GPG, Gatekeeper, ecc.

Questo è il motivo preciso per cui i checksum pubblicati spesso riportano un disclaimer che dice "Questo non può proteggere da modifiche dannose del file". Quindi, la risposta breve è "non possono fornire alcuna protezione da un file deliberatamente modificato" (anche se, se la pagina viene recapitata su HTTPS, HTTPS stesso protegge dalle modifiche; se il file non viene recapitato su HTTPS ma il checksum è, quindi ciò potrebbe aiutare alcuni, ma non è un caso comune). Chiunque ti abbia detto che i checksum pubblicati sulle pagine Web vengono utilizzati per rilevare modifiche dannose, ha sbagliato, perché questo non è un ruolo che può svolgere; tutto ciò che fanno è aiutare a proteggere dalla corruzione accidentale e dalla corruzione malevola pigra (se qualcuno non si prende la briga di intercettare la pagina che ti dà il checksum).

Se si desidera proteggere da modifiche deliberate, è necessario impedire alle persone di fare confusione con il checksum o rendere impossibile a chiunque altro generare un checksum valido. Il primo può comportare la distribuzione di persona o simili (quindi il checksum stesso è attendibile); il secondo va agli algoritmi di firma digitale (dove è necessario ottenere in modo sicuro la chiave pubblica per il downloader; in TLS, questo viene fatto affidandosi direttamente alle autorità di certificazione e facendole verificare a tutti gli altri; può anche essere fatto su una rete di fiducia , ma il punto è che a un certo punto qualcosa deve essere trasferito in modo sicuro e non è sufficiente pubblicare qualcosa sul tuo sito).

Questo è davvero un problema. La visualizzazione dei checksum sullo stesso sito del file da scaricare non è sicura. Una persona che può modificare il file può anche cambiare il checksum. Il checksum dovrebbe essere mostrato attraverso un sistema separato completo ma questo è difficilmente fattibile, perché come dire all'utente in modo sicuro dove si trova il checksum.

Una possibile soluzione è l'uso di file firmati.

(A proposito: MD5 non è sicuro ovunque e non dovrebbe più essere utilizzato.)

Come possono i checksum MD5 fornire alcuna protezione contro i file deliberatamente modificati se non c'è modo di sapere se il checksum stesso è stato compromesso?

Hai completamente ragione. L'obiettivo, quindi, sarebbe quello di rendere il tuo "se" sbagliato - se sappiamo che un hash crittografico sicuro di un file non è compromesso, allora sappiamo che neanche il file è compromesso.

Ad esempio, se pubblichi un hash di un file sul tuo sito Web e quindi colleghi a una copia del file su un server mirror di terze parti - pratica comune nella distribuzione di software libero vecchio stile - i tuoi utenti possono essere protetti da alcuni tipi di attacchi. Se il server mirror è dannoso o compromesso, ma il tuo sito Web è a posto, il mirror non sarà in grado di sovvertire il tuo file.

Se il tuo sito Web utilizza HTTPS o se firmi l'hash con gpg, il tuo file può anche essere (principalmente) protetto da attacchi di rete come hotspot Wi-Fi dannosi, nodi di uscita di Tor illegali o NSA.

Non è possibile modificare il checksum MD5 senza modificare anche il file. Se scarichi il file, quindi scarica l'hash e quindi il tuo calcolo dell'hash del file non corrisponde a ciò che viene fornito, l'hash o il file sono errati o incompleti.

Se si desidera "legare" il file a qualcosa di esterno, come autore, macchina, ecc., È necessario firmarlo , utilizzando un processo di tipo PKI con certificati. L'autore del file, ecc. Può firmare il file con la sua chiave privata e puoi verificare le firme con la chiave pubblica, che dovrebbe essere disponibile pubblicamente, firmata da un'autorità di certificazione di fiducia sia te che l'autore, e scaricabile, preferibilmente da più posizioni.

La modifica del file renderebbe non valida la firma, quindi può essere utilizzata anche per verificare l'integrità del file.

Gli hash indicano se la tua versione del file (il "download") differisce dalla versione del server. Non offrono alcuna garanzia per l'autenticità del file.

Le firme digitali (crittografia asimmetrica + funzione hash) possono essere utilizzate per verificare che il file non sia stato modificato da chiunque non disponga della chiave privata corrispondente.

Il creatore del file esegue l'hashing del file e crittografa l'hash utilizzando la loro chiave privata (segreta). In questo modo, chiunque abbia la chiave pubblica (non segreta) corrispondente può verificare che l'hash corrisponda al file, ma mentre il contenuto del file può essere modificato, nessuno può sostituire l'hash corrispondente con uno che corrisponde al file (dopo che l'hash è stato decifrato usando la chiave pubblica) - a meno che non riescano a forzare la chiave privata o ad accedervi in ​​qualche modo.

Cosa impedisce a Mr "A.Hacker" di modificare semplicemente il file, quindi di firmarlo con la propria chiave privata?

Per convalidare il file, devi confrontare il suo hash con quello ottenuto decrittografando la firma digitale associata. Se pensi che il file provenga da "IMAwesome", decodifichi l'hash usando la sua chiave e l'hash non corrisponde al file, poiché l'hash è stato crittografato usando la chiave di A.Hacker.

Le firme digitali consentono quindi di rilevare sia cambiamenti accidentali che dannosi.

Ma come possiamo ottenere la chiave pubblica di IMAwesome in primo luogo? Come possiamo assicurarci che quando abbiamo ottenuto la sua chiave, in realtà non era la chiave di A. Hacker servita da un server compromesso o da un attacco man-in-the-middle? È qui che entrano in gioco catene di certificati e certificati radice attendibili, nessuna delle quali è una soluzione perfettamente sicura [1] al problema, ed entrambe le cose dovrebbero probabilmente essere ben spiegate su Wikipedia e su altre domande su SO.

[1] Al momento dell'ispezione, i certificati radice forniti con il sistema operativo Microsoft sul mio PC di lavoro includono un certificato del governo degli Stati Uniti. Chiunque abbia accesso alla tosse della chiave privata corrispondente NSA tosse può quindi servire il contenuto del mio browser Web che passa il controllo "c'è un lucchetto nella barra degli indirizzi". Quante persone si preoccuperanno effettivamente di fare clic sul lucchetto e vedere chi è la coppia di chiavi utilizzata per "proteggere" la connessione?

Come possono i checksum MD5 fornire alcuna protezione contro i file deliberatamente modificati se non c'è modo di sapere se il checksum non è stato compromesso?

Questa è davvero una buona domanda. In generale, la tua valutazione della manipolazione MD5 è perfetta. Ma credo che il valore dei checksum MD5 sui download sia al massimo superficiale. Forse dopo aver scaricato un file puoi controllare l'MD5 che hai su un sito Web, ma tendo a vedere l'archiviazione MD5 affiancata come una "ricevuta" o qualcosa di bello da avere ma non affidabile. In quanto tale, in genere non mi sono mai preoccupato dei checksum MD5 dai file scaricati, ma posso parlare della mia esperienza nella creazione di processi MD5 basati su server ad hoc.

Fondamentalmente quello che ho fatto quando un client vuole eseguire lo sweep di un file system per i checksum MD5 è di averli generati in file CSV che mappano nome file, percorso, MD5 — e altre informazioni di file varie — in un formato dati strutturato che ho quindi ingerito in un database per confronto e archiviazione.

Quindi, usando il tuo esempio, mentre un checksum MD5 potrebbe trovarsi accanto a un file nel suo file di testo, il checksum MD5 del record di autorità verrebbe archiviato in un sistema di database non connesso. Quindi, se qualcuno in qualche modo fosse entrato in una condivisione di file per manipolare i dati, quell'intruso non avrebbe alcun accesso ai record dell'autorità MD5 o alla cronologia connessa.

Di recente ho scoperto un bel software di archiviazione delle biblioteche chiamato ACE Audit Manager che in pratica è un'applicazione Java progettata per sedere e guardare un filesystem per le modifiche. Registra le modifiche tramite le modifiche MD5. E opera secondo una filosofia simile a quella del mio processo ad-hoc: archivia i checksum in un database, ma fa un ulteriore passo avanti, ma creando un checksum MD5 di checksum MD5 che è noto come albero hash o albero Merkle .

Supponiamo che tu abbia 5 file in una raccolta. Quei 5 file in ACE Audit Manager otterrebbero quindi un altro — chiamiamolo “genitore” —checksum che è un hash generato dai 5 checksum MD5 di ciascun file. Quindi, se qualcuno dovesse manomettere un solo file, l'hash per il file cambierebbe e così anche l'hash per l'intera raccolta "parent".

In generale, il modo in cui è necessario esaminare i checksum MD5 e gli hash di integrità correlati è a meno che non siano collegati a una memoria non diretta per gli hash MD5 stessi, possono essere danneggiati. E il loro valore come strumento di integrità dei dati a lungo termine equivale a un lucchetto economico che viene “gratis” su un nuovo bagaglio; se sei seriamente intenzionato a bloccare i bagagli, otterrai una serratura che non può essere aperta in 5 secondi con una graffetta.

velocità

Spesso le persone scoprono che è molto più veloce (a) scaricare un file di grandi dimensioni da una rete di consegna di contenuti (CDN) non attendibile, siti mirror, peer torrent, ecc. E anche scaricare il corrispondente file di checksum breve (spesso SHA256; software precedente spesso usato MD5) da alcune fonti attendibili. Trovano insopportabilmente lento (b) scaricare l'intero file di grandi dimensioni direttamente da una fonte attendibile.

convalida

Spesso quella persona scopre che tutto convalida: le fonti (affidabili e non attendibili) concordano sullo stesso checksum ed eseguono shasum (o md5sum) con uno di quei file di checksum brevi (non importa quale, quando sono tutti identici ) indica che il file di grandi dimensioni ha un checksum corrispondente.

modifica

Hai ragione quando Mallory altera maliziosamente un file di grandi dimensioni che si trova su un sito di download, sarebbe facile per Mallory anche il checksum per quel file sullo stesso sito di download in modo che shasum (o md5sum) venga eseguito su quel file di checksum dannoso sembra convalidare il file di grandi dimensioni. Ma quel file di checksum non è (l'unico) quello che il downloader dovrebbe usare per la validazione.

Quando il downloader confronta quel file di checksum dannoso con i file di checksum scaricati da fonti attendibili, se il checksum originale scorre attraverso una sola volta, il downloader vedrà che tutto non viene convalidato e saprà che qualcosa è andato storto.

Come cpast ha detto prima, se un buon checksum crittografico viene trasmesso su una connessione fidata, può fornire sicurezza (che deriva dalla connessione fidata).

Come ha già detto Supercat, i file di checksum di un sito non aiutano le persone che scaricano file di grandi dimensioni dallo stesso sito e allo stesso modo in cui scaricano i file di checksum: aiutano le persone che vogliono scaricare file da qualche altro sito.

"In termini di sicurezza, gli hash crittografici come MD5 consentono l'autenticazione dei dati ottenuti da mirror non sicuri. L'hash MD5 deve essere firmato o provenire da una fonte sicura (una pagina HTTPS) di un'organizzazione di cui ti fidi." - https://help.ubuntu.com/community/HowToMD5SUM

I checksum crittografici sono una parte importante delle firme pratiche a chiave pubblica (come implementato in GnuPG e altri software compatibili con OpenPGP). Le firme a chiave pubblica presentano alcuni vantaggi rispetto ai soli checksum.

Ho sentito che [checksum MD5] è per consentire [...] anche di rilevare facilmente eventuali modifiche dannose.

Bene, non hai sentito totalmente sbagliato . La firma digitale è effettivamente utilizzata per rilevare modifiche dannose. Per alcuni motivi importanti, l' hash è una parte fondamentale della firma digitale, in quanto solo l'hash è effettivamente firmato , non l'intero file originale.

Detto questo, se la fonte non fornisce la firma dell'hash e un modo affidabile per verificarlo , allora hai ragione, non viene fornita alcuna protezione contro i file deliberatamente modificati , ma l'hash è ancora utile come checksum contro accidentale corruzione .

Ecco un esempio del mondo reale che potrebbe chiarire il tutto. Il seguente passaggio è particolarmente significativo in materia:

Per le versioni di CD archiviate meno recenti, sono stati generati solo checksum MD5 [...] Per le versioni più recenti, vengono utilizzati algoritmi di checksum più recenti e crittograficamente più efficaci (SHA1, SHA256 e SHA512)