Nel caso più semplice e insicuro, sia il file che il checksum sono serviti tramite un protocollo in chiaro come HTTP o FTP. In questo caso, no, non c'è nulla che impedisca la modifica Man-in-the-Middle sia del file che del checksum.
La prima domanda, tuttavia, è stata: "Perché alcuni processi si basano sui checksum pubblicati?" La risposta è che, se correttamente autenticato, i checksum forniscono protezione dell'integrità. Vale a dire, se posso garantire l'integrità e l'autenticità del checksum, posso verificare l'integrità del file scaricato.
Questo può sembrare ridondante, dal momento che se ho qualche metodo per verificare l'autenticità e l'integrità di un checksum, perché lo stesso metodo non protegge il file stesso? La risposta è che il checksum non è principalmente inteso a contrastare la manomissione dannosa , ma è inteso a scoprire il danneggiamento dei dati. Se si dispone di una connessione di rete o un'unità disco o un modulo RAM che introduce errori ad una velocità di 1 bit ogni 10 MB, allora le probabilità sono molto buone che si avrà un errore in un download da 50 MB. Ma le probabilità sono piuttosto basse che il checksum a 20 byte avrà un piccolo errore.
Questo è tutto a posto, ma come proteggere da manomissioni dannose? Ecco alcune soluzioni:
-
Fornisci il checksum su un canale autenticato e protetto dall'integrità. La soluzione più comune qui è HTTPS, in cui TLS fornisce autenticazione, integrità e crittografia. Il fornitore di dati può (e dovrebbe) raddoppiare e fornire il file anche su questo canale.
-
Fornisci una firma crittografica del file. Invece di fornire solo la protezione dell'integrità, questo metodo fornisce anche l'autenticità, ma richiede un po 'più di lavoro da parte del downloader, che deve avere o ottenere in modo sicuro la chiave pubblica del provider per verificare la firma. Lo stesso principio di base viene utilizzato per fornire la protezione dell'integrità all'interno di TLS, ma una firma separata per il file si basa su un canale di distribuzione delle chiavi diverso che può essere o non essere più difficile da corrompere per l'autore dell'attacco.
Questi metodi possono e devono essere combinati, poiché ci saranno alcuni utenti che diffidano delle protezioni di TLS, e altri che non possono essere disturbati a verificare una firma crittografica, ma per vari motivi possono solo supportare il checksum di base.
Naturalmente tutto ciò pone la domanda se il file può essere corrotto in modo tale che il checksum sia ancora valido. Questo è chiamato un attacco preimage , e MD5 ha dimostrato di essere teoricamente vulnerabile. Dovresti sempre usare la funzione di hash più sicura disponibile: SHA-2 e SHA-3 sono buone scelte; MD5 e SHA-1 sono più rischiosi.