fingerprint Bestand Checksum Verifiëren star

Waarom softwareleveranciers checksums publiceren

Wanneer u een Linux-ISO, een opensourcebinary of een ondertekend installatieprogramma downloadt, staat er op de downloadpagina meestal een checksum naast het bestand — een korte tekenreeks zoals a94a8fe5ccb19ba61c4c0873d391e987982fbbd. Die tekenreeks is de uitvoer van een cryptografische hashfunctie die over elke byte van het bestand wordt uitgevoerd. Verander zelfs één bit ergens in het bestand, en de hash komt er volledig anders uit. Leveranciers publiceren deze waarde zodat u, nadat u het bestand hebt gedownload, dezelfde hashfunctie zelf kunt uitvoeren en uw resultaat kunt vergelijken met het gepubliceerde resultaat. Als de twee tekenreeksen exact overeenkomen, kunt u erop vertrouwen dat de kopie op uw schijf precies dezelfde bytes bevat die de leverancier heeft gebouwd en geüpload — niets toegevoegd, niets ontbrekend, niets gewijzigd.

Een checksum vangt twee heel verschillende soorten problemen op. De eerste is alledaags: netwerkverbindingen vallen weg tijdens een overdracht, proxy's knippen grote bestanden af, en schijven schrijven af en toe naar slechte sectoren — elk hiervan kan u opzadelen met een bestand dat compleet lijkt (juiste grootte, opent zonder duidelijke fout) maar op een handvol beschadigde bytes na afwijkt van het origineel, wat vaak genoeg is om een installatieprogramma te laten crashen of gegevens later stilletjes te corrumperen. De tweede is vijandig: als een aanvaller een spiegelserver compromitteert of een download onderweg onderschept en een gewijzigde binary met malware erin verwisselt, is het vergelijken van de checksum met de waarde die op de officiële, vertrouwde pagina staat een van de weinige controles die dit daadwerkelijk zou opvangen — een bestandsnaam en bestandsgrootte zijn triviaal na te bootsen, maar het reproduceren van een exacte hash vereist het bezit van precies de originele bytes.

Checksums zijn geen encryptie

Het loont om precies te zijn over wat een checksum verifieert, want de terminologie raakt vaak door elkaar. Hashen is een eenrichtings-, onomkeerbare bewerking: SHA-256 zet een bestand om in een vaste hexadecimale tekenreeks van 64 tekens, maar er is geen bewerking die die tekenreeks weer terugzet naar het bestand. Alleen al dat vertelt u dat dit geen encryptie is — encryptie is ontworpen om omkeerbaar te zijn met de juiste sleutel, hashen is ontworpen om nooit omkeerbaar te zijn. Een checksum verifieert integriteit, niet vertrouwelijkheid: het bevestigt dat de bytes die u hebt, de bytes zijn die gehasht werden. Iedereen met toegang tot het bestand kan nog steeds elke byte ervan in gewone tekst lezen; hashen verbergt de inhoud niet. Wat het garandeert, is dat als er ook maar één byte werd gewijzigd — bewust of per ongeluk — de hash die u berekent niet meer overeen zou komen met de gepubliceerde hash, en u onmiddellijk zou weten dat er iets anders is.

Dit onderscheid is ook van belang voor de keuze van het algoritme. SHA-1 werd in 2017 formeel als cryptografisch onveilig aangemerkt, toen onderzoekers van Google en CWI Amsterdam de "SHAttered"-aanval publiceerden: twee verschillende PDF-bestanden, zo ontworpen dat ze exact dezelfde SHA-1-hash opleveren, waarmee werd bewezen dat een voldoende vastberaden aanvaller een kwaadaardig bestand kon construeren dat een checksum deelt met een legitiem bestand. Dat resultaat heeft SHA-1 met pensioen gestuurd voor alles wat veiligheidskritisch is — TLS-certificaten, digitale handtekeningen, verdediging tegen een vijandige actor die opzettelijk een botsing engineert. Maar voor het veel voorkomendere geval waarvoor deze tool bedoeld is — bevestigen dat een download niet is beschadigd door een haperende verbinding — werkt SHA-1 in de praktijk nog steeds prima, omdat niemand uw specifieke beschadigde download engineert om overeen te komen met een doelhash; toevallige corruptie is willekeurig bit-flippen, geen opzettelijke botsingsconstructie. Dat gezegd hebbende, wanneer een leverancier een keuze biedt, kost SHA-256 niets extra om te berekenen en sluit het die kloof volledig — daarom is het de veiligere standaardkeuze.