Digitale Signaturen für Dateien: Authentizität beweisen

Eine digitale Signatur ist ein kryptografischer Beweis, dass eine bestimmte Person oder Organisation eine Datei erstellt hat und dass die Datei seitdem unverändert ist. Technisch gesehen hashen Sie die Datei mit SHA-256 und „signieren" dann den Hash mit Ihrem privaten Schlüssel mittels RSA-PSS, ECDSA oder Ed25519. Jeder mit Ihrem öffentlichen Schlüssel kann die Signatur prüfen — stimmt sie, wissen sie, dass Sie die Datei verfasst haben und sie byte-identisch mit dem ist, was Sie signiert haben. So prüft macOS App-Updates, so signiert Git Commits (git commit -S), und so funktionieren PGP-signierte E-Mails. Signaturen lösen ein Problem, das Verschlüsselung allein nicht lösen kann: beweisen, wer was gesendet hat.

Signaturen vs. Verschlüsselung: unterschiedliche Aufgaben

Verschlüsselung hält Inhalte geheim. Signaturen beweisen Urheberschaft und Integrität. Sie sind komplementär, keine Alternativen.

Nur verschlüsseln: Der Empfänger kennt den Inhalt, aber nicht den Absender. Jeder mit dem öffentlichen Schlüssel hätte verschlüsseln können.
Nur signieren: Der Empfänger weiß, wer gesendet hat und dass nichts manipuliert wurde, aber der Inhalt ist für jeden sichtbar, der ihn abfängt.
Signieren und verschlüsseln: Vollständige Authentizität, Integrität und Vertraulichkeit. PGPs Standardmodus.

Dateiübertragungsdienste konzentrieren sich typischerweise auf Verschlüsselung. Signaturen kommen in hochvertrauenswürdigen Kontexten ins Spiel: Software-Vertrieb, Rechtsdokumente, Verträge, forensische Beweisketten.

Wie Signierung tatsächlich funktioniert

Der kanonische Ed25519-Signierungsablauf:

Nachricht hashen: h = SHA-512(Nachricht).
Deterministisches Nonce berechnen: r = SHA-512(privat_schlüssel_prefix || h).
Signaturpunkt berechnen: R = r·G (wobei G der Basispunkt der Kurve ist).
s = r + SHA-512(R || öffentlich_schlüssel || h) · privat_schlüssel mod ℓ berechnen.
Signatur ist (R, s), insgesamt 64 Bytes.

Die Verifizierung nutzt nur den öffentlichen Schlüssel, die Nachricht und die Signatur. Geht die Mathematik auf, weiß der Prüfer, dass die Signatur von jemandem produziert wurde, der den passenden privaten Schlüssel hält.

RSA-PSS (PKCS#1 v2.2) und ECDSA funktionieren ähnlich, mit anderer zugrundeliegender Mathematik. Ed25519 wird für neue Systeme bevorzugt, weil es deterministisch ist (kein zufälliges Nonce pro Signatur) und schneller.

Die drei gängigen Signaturalgorithmen

| Algorithmus | Schlüsselgröße | Signaturgröße | Geschwindigkeit | Anmerkungen | |-------------|----------------|---------------|-----------------|-------------| | RSA-PSS-2048 | 256 Bytes | 256 Bytes | ~1.000 Sign./s | Weit verbreitet, langsame Schlüsselgenerierung | | ECDSA P-256 | 32 Bytes | 64 Bytes | ~30.000 Sign./s | NIST-Kurve, benötigt sicheres RNG pro Signatur | | Ed25519 | 32 Bytes | 64 Bytes | ~50.000 Sign./s | Deterministisch, moderner Standard |

Alle drei sind in NISTPs FIPS 186-5 (2023) zugelassen. Ed25519 ist die Wahl für neue Protokolle: WireGuard, SSH (Standard seit OpenSSH 8.0), Signal, Git-Commit-Signierung und Rusts Cargo-Paketsignierung.

Code-Signierung: ein milliardenschwerer Anwendungsfall

Software-Vertrieb basiert auf Signaturen. Ohne sie können Nutzer das echte Installationsprogramm nicht von Malware unterscheiden:

Apple Developer ID + Notarisierung. Alle macOS-Apps müssen seit Catalina (2019) signiert und notarisiert sein. Nutzt RSA-2048 oder ECDSA P-256.
Microsoft Authenticode. Windows-Executables signiert mit RSA-3072 oder ECDSA P-384.
Android APK v2/v3. Ed25519-Signaturen über APK-Inhalte.
Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Alle nutzen abgetrennte Signaturen (typischerweise GPG Ed25519 oder RSA) über Paket-Manifeste.

Ein bekannter Vorfall: 2020 wurde SolarWinds' Orion-Update mit dem legitimen Zertifikat des Unternehmens signiert, nachdem Angreifer das Build-System kompromittiert hatten. Die Signatur war gültig — sie bewies nur, dass der Code aus einer kompromittierten Quelle stammte. Signaturen garantieren die Identität des Unterzeichners, nicht sein Urteilsvermögen.

PGP und abgetrennte Signaturen für Dateien

GnuPG (gpg) ist weiterhin das Arbeitspferd für Datei-Signaturen außerhalb von Unternehmens-PKI. Eine abgetrennte Signatur lässt die Datei unverändert und legt die Signatur in eine separate .sig-Datei:

gpg --detach-sign --armor dokument.pdf
# Erzeugt dokument.pdf.sig

gpg --verify dokument.pdf.sig dokument.pdf
# gpg: Gute Signatur von "Alice <alice@example.com>"

PGPs Schwäche ist die Schlüsselverteilung: Woher weiß der Prüfer, dass der Signaturschlüssel wirklich Alice gehört? Optionen umfassen Schlüsselserver, Web of Trust, keybase.io oder Out-of-Band-Verifizierung (veröffentlichter Fingerabdruck auf einer Visitenkarte).

Moderne Alternativen: Sigstore (genutzt von Kubernetes, npm) macht schlüsselloses Signieren mit OIDC-Identity-Tokens möglich, wobei Transparency-Logs das Web of Trust ersetzen. minisign von Frank Denis bietet einfaches Ed25519-Signieren ohne PGPs Komplexität.

Hash-basierte Signaturagregation

Für Dateisammlungen ist das individuelle Signieren jeder Datei ineffizient. Besser: Jede Datei hashen, einen Merkle-Baum aufbauen, den Root signieren. Vorteile:

Eine Signatur deckt viele Dateien ab.
Einzelne Dateien können gegen den Root mit log(n) Geschwister-Hashes verifiziert werden.
Genutzt von Certificate-Transparency-Logs, Git und zunehmend von Supply-Chain-Tools wie in-toto.

Ein 10.000-Dateien-Release so signiert produziert eine Signatur plus einen 32-Byte-Root-Hash, verifizierbar gegen jeden Teilbestand der Dateien.

Zeitstempelung: beweisen, wann

Eine Signatur beweist wer, aber nicht wann. Ein Angreifer, der Ihren privaten Schlüssel stiehlt, kann Signaturen rückdatieren. Vertrauenswürdige Zeitstempelierungsbehörden (TSAs) lösen das, indem sie einen Zeitstempel über Ihre Signatur signieren und sie an einen bestimmten Moment binden.

Standards:

RFC 3161 Zeitstempelung — genutzt von Microsoft Authenticode, Adobe PDF-Signaturen.
RFC 5544 (CMS mit Zeitstempeln).
Roughtime — ein neueres Protokoll von Google für verifizierte Zeit mit niedriger Latenz.

Rechtliche Dokumentensignierung (DocuSign, Adobe Sign, EU-eIDAS-qualifizierte Signaturen) stützt sich auf RFC-3161-Zeitstempel von vertrauenswürdigen Behörden, um festzustellen, wann ein Vertrag unterzeichnet wurde.

Signaturen bei Dateiübertragungen

Die meisten verbraucherorientierten Dateiübertragungsdienste stellen Signaturen nicht direkt bereit — der AES-GCM-Authentifizierungs-Tag beweist Integrität innerhalb der Übertragung, und TLS beweist die Identität des Servers, aber es gibt keine eingebaute Möglichkeit, die Identität des Absenders zu beweisen.

Bei hochvertrauenswürdigen Übertragungen erfolgt die Signierung vor dem Upload:

Absender signiert die Datei mit Ed25519 oder PGP und erzeugt datei.ext und datei.ext.sig.
Beide Dateien werden bei einem beliebigen Übertragungsdienst hochgeladen (HexaTransfer, SwissTransfer, WeTransfer).
Empfänger lädt beide herunter und verifiziert die Signatur mit dem öffentlichen Schlüssel des Absenders.

Das entkoppelt Authentizität vom Übertragungsmechanismus — der Übertragungsdienst könnte kompromittiert werden, ohne die Gültigkeit der Signatur zu brechen, solange der private Schlüssel des Absenders geheim bleibt und der Empfänger den korrekten öffentlichen Schlüssel hat.

EU-eIDAS-qualifizierte Signaturen

Die eIDAS-Verordnung der Europäischen Union (EU 910/2014, 2024 als eIDAS 2.0 überarbeitet) definiert drei Signatur-Stufen:

Elektronische Signatur — grundlegend, umfasst eingescannte handschriftliche Unterschriften.
Fortgeschrittene elektronische Signatur (FES/AdES) — mit dem Unterzeichner verknüpft, erkennt Manipulationen. PGP-Signaturen qualifizieren.
Qualifizierte elektronische Signatur (QES) — AdES plus qualifiziertes Zertifikat von einem Vertrauensdiensteanbieter, gespeichert auf einer qualifizierten Signaturerstellungseinheit (Chipkarte oder HSM).

Die QES hat in allen EU-Mitgliedstaaten dasselbe Rechtsniveau wie eine handschriftliche Unterschrift. Anbieter umfassen DocuSign EU, Adobe Sign EU, Namirial und DTrust.

Wann Signaturen übertrieben sind

Nicht jede Datei benötigt eine Signatur. Verzichten Sie, wenn:

Der Empfänger dem Übertragungskanal Ende-zu-Ende vertraut (Signal, USB-Stick persönlich übergeben).
Der Inhalt nicht sicherheitskritisch ist (Meeting-Fotos, Rezepte, Entwurfsdokumente).
Integrität allein ausreicht und durch AES-GCM oder TLS bereitgestellt wird.

Fügen Sie Signaturen hinzu, wenn:

Rechtliches oder vertragliches Gewicht wichtig ist (Verträge, Gerichtsbeweise, Krankenakten).
Supply-Chain-Vertrauen auf dem Spiel steht (Software-Releases, Firmware-Updates).
Die Datei durch nicht vertrauenswürdige Zwischenstellen weitergeleitet wird.
Sie eine dauerhafte Revisionsspur benötigen, die die ursprüngliche Übertragung überdauert.

In der Praxis umsetzen

Für einen einfachen Workflow: Ed25519-Schlüssel mit ssh-keygen -t ed25519 -f ~/.ssh/signing_key generieren, eine Datei mit openssl pkeyutl -sign -inkey signing_key -in datei -out datei.sig signieren, Ihren öffentlichen Schlüssel auf einem anderen Kanal teilen und die Datei über einen beliebigen sicheren Übertragungsdienst senden. Empfänger prüfen mit openssl pkeyutl -verify.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.