Was ist eine Checksum und wozu brauche ich sie?

Eine Checksum ist ein Hash-Wert über die Bytes einer Datei. Sie dient zwei Zwecken. Erstens dem Erkennen von Übertragungsfehlern: Wenn beim Download ein Bit kippt, hat die Datei einen anderen Hash. Zweitens dem Erkennen von Manipulation: Wenn jemand die Datei verändert hat, weicht der Hash vom Original ab. Klassisches Beispiel sind Linux-Distributionen, die zu jeder ISO-Datei einen SHA256SUMS-File mitliefern. Nach dem Download prüft sha256sum -c, ob die heruntergeladene Datei den erwarteten Hash hat.

Warum reicht eine Checksum allein nicht gegen Manipulation?

Weil der Angreifer, der die Datei manipulieren kann, oft auch die Checksum-Datei manipulieren kann. Wenn beide auf demselben Server liegen und der Server kompromittiert wurde, sind beide gefälscht. Deshalb signieren seriöse Anbieter die Checksum-Datei zusätzlich mit einem GPG-Schlüssel. Beispiel: Ubuntu liefert SHA256SUMS plus SHA256SUMS.gpg. Wer den GPG-Schlüssel von Ubuntu kennt (Out-of-Band verifiziert), kann die Signatur prüfen und damit den Inhalt von SHA256SUMS authentifizieren.

Welcher Befehl prüft eine SHA-256-Checksum?

Auf Linux und macOS: sha256sum -c SHA256SUMS prüft alle Dateien in der SHA256SUMS-Datei, deren Namen im Arbeitsverzeichnis liegen. Auf Windows: Get-FileHash -Algorithm SHA256 datei.iso liefert den Hash, den Sie manuell mit dem erwarteten Wert vergleichen. Alternativ in PowerShell als Skript: (Get-FileHash file.iso -Algorithm SHA256).Hash -eq 'erwarteter-hash'. Im Browser können Sie auf hash-generieren.de die Datei oder den Hex-String prüfen, ohne Tool installieren zu müssen.

Was ist Subresource Integrity in HTML?

Subresource Integrity (SRI) ist ein W3C-Standard, der erlaubt, in HTML-Script- und Link-Tags einen Hash der erwarteten Datei mitzuliefern. Wenn der Browser die Datei vom CDN lädt, vergleicht er den berechneten Hash mit dem erwarteten und verweigert die Ausführung bei Abweichung. Format: integrity='sha384-Q6E9RHvbIyZFJoFt4O7bIVc+jKf3ZG4FxJ7v8OZb...'. Damit ist eine CDN-Manipulation oder ein kompromittierter Upstream-Server kein Angriffsvektor mehr. SRI ist seit 2016 in allen großen Browsern unterstützt.

Welche typischen Fehler passieren beim Checksum-Vergleich?

Drei klassische: Erstens Tippfehler im Hex-String. Wer den Hash manuell aus einem Browser kopiert und in ein Terminal pastes, kann Leerzeichen oder Zeilenumbrüche mitschleppen. Zweitens falsche Datei verglichen: Wer mehrere Versionen einer ISO geladen hat und die Hashes vermischt. Drittens Algorithmus-Verwechslung: SHA-256 vs SHA-1 vs MD5, alle drei produzieren Hex-Strings, aber unterschiedlicher Länge. SHA-256 hat 64 Hex-Zeichen, SHA-1 hat 40, MD5 hat 32. Wer Länge prüft, fängt die Verwechslung früh ab.

Checksums in der Praxis: SHA-256 für Downloads, Backups, Archive

Was eine Checksum technisch ist

Eine Checksum ist die Anwendung einer Hash-Funktion auf den Inhalt einer Datei. Aus einer beliebig großen Datei entsteht ein kurzer Fingerabdruck fester Länge (32 Byte für SHA-256, 64 Byte für SHA-512). Zwei Dateien mit identischem Byte-Inhalt haben denselben Hash, zwei verschiedene Dateien haben praktisch nie denselben Hash.

Die “praktisch nie” ist mathematisch unterfüttert: Bei SHA-256 liegt die Wahrscheinlichkeit einer zufälligen Kollision unter 1 zu 2^128. Das ist eine Zahl mit 39 Nullen. Selbst alle Festplatten der Welt zusammen erzeugen weniger Daten, als nötig wäre, um zufällig eine SHA-256-Kollision zu produzieren.

Was eine Checksum nicht ist: Eine Verschlüsselung (die Datei bleibt im Klartext lesbar), eine Signatur (sie sagt nichts über die Urheberschaft) oder ein Passwort-Schutz. Sie ist ein Werkzeug für Integritätsprüfung, nicht für Vertraulichkeit oder Authentifizierung.

In der Praxis tauchen Checksums in drei Hauptkontexten auf: Download-Verifikation, Backup-Validation und Archiv-Integritätsprüfung. Jeder dieser Kontexte hat eigene Tooling-Konventionen.

Download-Verifikation: das Linux-ISO-Beispiel

Wer ein Linux-Distribution-Image herunterlädt, sieht auf der Mirror-Seite drei Dateien:

ubuntu-24.04-desktop-amd64.iso (das eigentliche Image)
SHA256SUMS (Textdatei mit Hash und Dateiname pro Zeile)
SHA256SUMS.gpg (GPG-Signatur der SHA256SUMS-Datei)

Die SHA256SUMS-Datei sieht zum Beispiel so aus:

b3a8b5a3...d4e7f2c1  ubuntu-24.04-desktop-amd64.iso
a1c5d4f2...e8b9c3d4  ubuntu-24.04-server-amd64.iso

Nach dem Download führen Sie im selben Verzeichnis aus:

sha256sum -c SHA256SUMS

Das Tool berechnet den SHA-256 jeder in der Datei aufgelisteten Datei (sofern lokal vorhanden) und vergleicht mit dem erwarteten Hash. Output ist entweder OK oder FAILED. Bei FAILED ist die Datei korrupt oder manipuliert.

Auf Windows funktioniert das mit PowerShell:

Get-FileHash -Algorithm SHA256 ubuntu-24.04-desktop-amd64.iso

Den ausgegebenen Hash vergleichen Sie manuell mit dem erwarteten Wert aus SHA256SUMS. Etwas eleganter mit String-Vergleich:

$expected = "b3a8b5a3...d4e7f2c1"
$actual = (Get-FileHash file.iso -Algorithm SHA256).Hash
$actual.ToLower() -eq $expected.ToLower()

Auf macOS ist shasum -a 256 der Standardweg. Die GNU-coreutils-Variante sha256sum ist über Homebrew nachinstallierbar.

Warum eine GPG-Signatur dazugehört

Eine reine SHA256SUMS-Datei schützt nicht vor einem kompromittierten Server. Wenn ein Angreifer den Mirror übernimmt, kann er sowohl die ISO als auch SHA256SUMS austauschen. Der Angreifer kann konsistent eine manipulierte ISO mit passendem Hash hinterlegen.

Schutz dagegen: Die SHA256SUMS-Datei wird mit dem privaten GPG-Schlüssel des Projekts signiert. Die Datei SHA256SUMS.gpg enthält diese Signatur. Wer den öffentlichen Schlüssel des Projekts (außerhalb des Mirrors, etwa über mehrere unabhängige Kanäle) verifiziert hat, kann mit gpg --verify SHA256SUMS.gpg SHA256SUMS prüfen, dass die Hash-Liste vom legitimen Maintainer stammt.

Ubuntu, Debian, Fedora, FreeBSD, Tails und andere seriöse Projekte liefern GPG-signierte SHA256SUMS. Wer auf einem unbekannten Mirror landet, sollte die Signatur prüfen und den Schlüssel-Fingerprint mit dem offiziellen Projekt-Schlüssel abgleichen (oft auf der HTTPS-Hauptseite zu finden).

Praktisches Vorgehen für Ubuntu:

# Public Key des Ubuntu Release-Signers importieren
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xD94AA3F0EFE21092
# SHA256SUMS-Signatur verifizieren
gpg --verify SHA256SUMS.gpg SHA256SUMS
# SHA256-Hashes prüfen
sha256sum -c SHA256SUMS

Drei Schritte, drei Sicherheitsebenen: Schlüssel-Authentizität, Hash-Liste-Authentizität, Datei-Integrität. Erst alle drei zusammen ergeben einen vollständigen Schutz.

Vollständiger Checksum-Workflow für seriöse ISO-Downloads. Nur sha256sum ohne GPG ist Halbsicherheit.

Subresource Integrity im Browser

Wenn eine Webseite Skripte oder Stylesheets von einem CDN lädt (jQuery, Bootstrap, Fonts), kann ein kompromittiertes CDN beliebigen Code in alle einbindenden Seiten schleusen. Subresource Integrity (SRI) löst das Problem: Im HTML-Tag wird der erwartete Hash der Datei angegeben, der Browser verifiziert nach dem Laden.

Beispiel für ein eingebettetes jQuery:

<script src="https://code.jquery.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous"></script>

Der integrity-Wert ist sha384- gefolgt vom Base64-kodierten SHA-384-Hash. Wenn der CDN die Datei manipuliert, schlägt die Verifikation fehl, der Browser lädt das Script nicht, ein potenzieller Angriff wird abgewehrt.

Den SRI-Hash erzeugen Sie aus einer lokalen Datei:

shasum -b -a 384 jquery-3.7.1.min.js | awk '{ print $1 }' | xxd -r -p | base64

Oder bequemer über das SRI-Hash-Generator-Tool der Mozilla Developer Network. Oder mit cat file | openssl dgst -sha384 -binary | openssl base64 -A.

SRI ist seit 2016 in Chrome, Firefox, Safari und Edge unterstützt. Wer auf Performance achtet, kombiniert SRI mit crossorigin="anonymous" für CORS-fähige CDNs, was Caching-Vorteile bringt.

Backups und Archive: Content-Addressed Storage

Moderne Backup-Tools wie BorgBackup und restic verwenden Hash-Funktionen nicht nur zur Verifikation, sondern als Grundlage der Speicher-Architektur. Das Prinzip heißt Content-Addressed Storage: Jeder Datei-Block wird mit seinem Hash adressiert. Zwei identische Blöcke (etwa derselbe Mailserver-Anhang in zwei Backups) haben denselben Hash und werden nur einmal gespeichert. Das spart drastisch Speicher.

BorgBackup nutzt BLAKE2b (in der Standard-Konfiguration) oder SHA-256 (in FIPS-Modus). Die Hashes werden zusätzlich mit einem MAC versehen, sodass ein Angreifer keine eigenen Inhalte einschmuggeln kann, ohne den Backup-Schlüssel zu kennen.

restic verwendet SHA-256 für Content-Adressing plus AES-256 für Verschlüsselung. Eine restic-Repo-Verifikation (restic check --read-data) liest jeden Block und prüft den Hash gegen den erwarteten Wert. Bit-Rot auf Festplatten wird damit zuverlässig erkannt.

Für eigene Backup-Skripte ist rsync --checksum eine einfache Variante: Statt nur Größe und Modifikationsdatum vergleicht rsync die Datei-Hashes. Langsamer, aber zuverlässiger gegen subtile Korruption.

Häufige Fehler beim Checksum-Vergleich

Drei wiederkehrende Stolperfallen:

Fehler 1: Tippfehler im Hex-String. Wer den Hash manuell aus einem Browser kopiert und in ein Terminal einfügt, schleppt manchmal Leerzeichen, Zeilenumbrüche oder unsichtbare Unicode-Zeichen mit. Der String-Vergleich schlägt fehl, obwohl die Datei korrekt ist. Lösung: Hash über ein einheitliches Tool (sha256sum oder Get-FileHash) generieren, nicht aus dem Browser kopieren.

Fehler 2: Falsche Datei verglichen. Mehrere ISO-Versionen, mehrere Hashes. Wer den SHA-256-Hash der Server-Variante gegen die Desktop-Variante prüft, bekommt FAILED, obwohl beide Dateien intakt sind. Lösung: Dateiname und Hash konsistent benennen, SHA256SUMS-Datei mit allen erwarteten Hashes verwenden statt einzeln vergleichen.

Fehler 3: Algorithmus-Verwechslung. SHA-256 (64 Hex-Zeichen), SHA-1 (40 Hex-Zeichen), MD5 (32 Hex-Zeichen). Wer einen 32-stelligen Hash gegen einen 64-stelligen vergleicht, sieht sofort, dass die Algorithmen nicht passen. Lösung: vor dem Vergleich Algorithmus-Konsistenz prüfen, am besten am Hash-Längen-Check.

Fehler 4: GPG-Signatur ignoriert. Viele Anwender prüfen sha256sum, aber nicht die GPG-Signatur der SHA256SUMS-Datei. Wenn der Mirror kompromittiert ist, hilft sha256sum allein nicht. Lösung: Bei sicherheitskritischen Downloads immer die GPG-Signatur prüfen und den Schlüssel-Fingerprint mit dem offiziellen Projekt-Schlüssel abgleichen.

Praktische Empfehlung

Für Standard-Downloads (Linux-ISOs, Software-Releases, Backup-Archive) ist SHA-256 der richtige Algorithmus. Er ist überall verfügbar, BSI-konform, kollisions-sicher und im Hex-String mit 64 Zeichen kompakt darstellbar.

Wer eine Datei online schnell verifizieren will, kann den lokalen Hash auf hash-generieren.de berechnen und mit dem erwarteten Wert vergleichen. Das ersetzt keine GPG-Signatur, aber für nicht-sicherheitskritische Übertragungs-Prüfungen reicht es. Die Methodik-Seite dokumentiert, dass die Berechnung im Browser über die Web Crypto API läuft, ohne Server-Upload. Die Autorenseite Eike-Christian ergänzt den rechtlichen Kontext. Bei Korrekturwünschen ist die Korrekturen-Adresse der Anlaufpunkt.

Was hängenbleibt

Eine Checksum prüft Datei-Integrität, eine GPG-Signatur prüft Datei-Authentizität. Beides zusammen gibt vollen Schutz, jedes für sich nur Halbschutz. Auf Linux und macOS ist sha256sum -c Standard, auf Windows Get-FileHash. Subresource Integrity bringt dasselbe Konzept in den Browser, Backup-Tools wie BorgBackup und restic nutzen Hash-Funktionen als Speicher-Architektur. Häufige Fehler sind Tippfehler im Hex-String, Algorithmus-Verwechslung und übersprungene GPG-Verifikation. SHA-256 ist für all diese Zwecke der richtige Algorithmus.