Clientseitige Verschlüsselung: Web Crypto API

Was clientseitige Verschlüsselung bedeutet

Clientseitige Verschlüsselung bedeutet, dass der Klartext das Gerät, auf dem er entstanden ist, nie verlässt. Ver- und Entschlüsselung geschehen im Browser, in der App oder auf dem Rechner der Nutzerin – nicht auf einem Server.

Ein Web-System sieht in der Praxis so aus: Die Nutzerin gibt Daten ein, der Browser leitet lokal einen Schlüssel ab oder importiert ihn, verschlüsselt mit der Web Crypto API, und nur der Chiffretext wird übertragen, gespeichert oder geteilt.

Das Ergebnis ist eine Zero-Knowledge-Architektur: Der Dienstanbieter kann die Daten nicht lesen – selbst wenn seine Datenbank gestohlen, seine Logs beschlagnahmt oder seine Infrastruktur kompromittiert wird.

Das unterscheidet sich von TLS. TLS schützt Daten während der Übertragung zwischen Browser und Server; der Server sieht aber den Klartext. Clientseitige Verschlüsselung schützt Daten im Ruhezustand und vor dem Server selbst.

Das Bedrohungsmodell: was es schützt, was nicht

• Schützt: Daten im Ruhezustand auf einem Server, dem Sie nicht vertrauen – Cloud-Speicher, Sync-Backends, geteilte Dokumente
• Schützt: Daten in der Übertragung, die sonst für Zwischeninstanzen mit Transportzugriff lesbar wären
• Schützt: Datenbankbrüche, unredliche Mitarbeitende, Auskunftsersuchen gegen den Anbieter
• Schützt NICHT: einen kompromittierten Browser, bösartige Browser-Erweiterungen, Keylogger oder Bildschirmaufzeichnung auf dem Gerät der Nutzerin
• Schützt NICHT: den Endpunkt selbst – läuft Malware als Nutzerin, kann sie Daten vor der Verschlüsselung oder nach der Entschlüsselung lesen
• Schützt NICHT: schwache Passphrasen oder schlecht verwaltete Schlüssel – die Kryptografie ist nur so stark wie die Schlüsselhygiene

Web Crypto API: die Primitive, die Sie brauchen

Die Web Crypto API (crypto.subtle) stellt standardisierte, geprüfte kryptografische Operationen in jedem modernen Browser bereit. Sie läuft im selben Prozess wie die Seite, die Operationen selbst sind jedoch von den Browser-Anbietern implementiert und geprüft.

Nutzen Sie sie statt JavaScript-Kryptobibliotheken: native Implementierungen sind schneller und seltener fehleranfällig, und sie unterstützen hardwaregestützte Schlüsselspeicher, wo verfügbar.

Die Primitive, die für clientseitige Verschlüsselung zählen:

• AES-256-GCM – authentifizierte Verschlüsselung für Nutzdaten, die Standardwahl für Text- und Dateiverschlüsselung
• PBKDF2 – leitet einen Schlüssel aus einer Passphrase mit konfigurierbarem Aufwand ab
• HKDF – leitet mehrere Schlüssel aus einem einzelnen hochgradig zufälligen Eingabewert ab
• RSA-OAEP – asymmetrische Verschlüsselung, wenn Sie an einen öffentlichen Schlüssel ohne gemeinsames Geheimnis verschlüsseln müssen
• ECDH – Schlüsselaustausch zur Ableitung eines gemeinsamen Geheimnisses zwischen zwei Parteien
• crypto.getRandomValues – kryptografisch sichere Zufallszahlen für Salts, IVs und Nonces

Wie ein passphrasebasiertes System funktioniert

// Mit Web Crypto verschlüsseln (WebCrypto ist in allen modernen Browsern verfügbar)
const enc = new TextEncoder();
const salt = crypto.getRandomValues(new Uint8Array(16));
const iv = crypto.getRandomValues(new Uint8Array(12));
const keyMaterial = await crypto.subtle.importKey(
  'raw', enc.encode('passphrase'), 'PBKDF2', false, ['deriveKey']
);
const key = await crypto.subtle.deriveKey(
  { name: 'PBKDF2', salt, iterations: 600000, hash: 'SHA-256' },
  keyMaterial, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt']
);
const ciphertext = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv }, key, enc.encode('plaintext')
);
// Salt + IV + Chiffretext gemeinsam speichern

1. Erzeugen Sie pro Verschlüsselungsoperation einen zufälligen Salt und ein zufälliges 12-Byte-IV.
2. Leiten Sie einen 256-Bit-Schlüssel aus der Passphrase mit PBKDF2 und hoher Iterationszahl ab (600.000+ für SHA-256 laut OWASP).
3. Verschlüsseln Sie den Klartext mit AES-256-GCM unter dem abgeleiteten Schlüssel und IV.
4. Speichern Sie zusammen: Salt, IV und Chiffretext (mit dem GCM-Authentifizierungstag).
5. Zum Entschlüsseln den Schlüssel aus Passphrase und gespeichertem Salt erneut ableiten und entschlüsseln – das GCM-Tag schlägt fehl, wenn Chiffretext oder Passphrase falsch sind.

Schlüsselverwaltung ist der schwierige Teil

Der Algorithmus ist standardisiert; an der Schlüsselverwaltung scheitern Systeme. Ein Schlüssel neben dem Chiffretext, eine Passphrase im Quellcode oder ein über Dokumente wiederverwendeter Schlüssel machen die Verschlüsselung wertlos.

Grundsätze für jedes clientseitige Design:

Ein frisches zufälliges IV/Nonce für jede Verschlüsselung – ein IV darf nie mit demselben Schlüssel wiederverwendet werden

Ein eindeutiger zufälliger Salt pro Schlüsselableitung, damit identische Passphrasen nicht identische Schlüssel erzeugen

Hohe PBKDF2-Iterationszahlen oder ein speicherharter KDF wie scrypt oder Argon2 für passphraseabgeleitete Schlüssel

Passphrasen und abgeleitete Schlüssel niemals in Quellcode, localStorage oder URL-Parametern speichern

Eine Wiederherstellungsgeschichte: Ist der Schlüssel verloren, sind die Daten unwiederbringlich – kommunizieren Sie das klar an Nutzerinnen

Schlüsselrotation von Anfang an: Schlüsselmaterial versionieren und bei Schlüsselwechsel neu verschlüsseln

Wann clientseitige Verschlüsselung das falsche Werkzeug ist

• Serverseitige Verarbeitung ist erforderlich – Suche, Analyse, serverseitig gerenderte Berichte
• Sie können die Client-Umgebung nicht garantieren (eingebettete WebViews, unzuverlässige Geräte)
• Daten müssen wiederherstellbar sein, wenn Nutzerinnen Schlüssel verlieren, und Sie haben keine akzeptable Schlüsseltreuhand-Lösung
• Die Bedrohung ist Endpunkt-Kompromittierung – Verschlüsselung bringt wenig, wenn Malware auf derselben Maschine läuft
• Compliance verlangt die Prüfbarkeit von Klartextverarbeitung durch den Anbieter

Produktions-Checkliste

• AES-256-GCM (oder ChaCha20-Poly1305) für symmetrische Nutzdaten verwenden – niemals ECB, niemals unauthentifiziertes CBC
• IVs/Nonces mit crypto.getRandomValues erzeugen, 12 Bytes für GCM, niemals wiederverwenden
• Passphrasen-Schlüssel mit PBKDF2 (600.000+ SHA-256-Iterationen) oder Argon2id/scrypt ableiten, wo verfügbar
• Assoziierte Daten (AAD) authentifizieren, die nicht verschlüsselt, aber manipulationssicher sein müssen – etwa Versionsnummern
• Salt, IV und Chiffretext zusammen in einem dokumentierten, versionierten Containerformat speichern
• Fail-closed: jede Integritätsverletzung beim Entschlüsseln bricht die Operation ab
• Klartext, Schlüssel und Passphrasen niemals loggen – auch nicht in Fehlermeldungen
• Schlüsselrotation, verlorene Schlüssel und Randfälle leerer Eingaben testen
• Strikte CSP setzen, damit die Seite selbst nicht durch injizierte Skripte verändert werden kann
• Code auditieren und ein schriftliches Bedrohungsmodell danebenlegen

FAQ

Referenzen

• W3C Web Cryptography API: https://www.w3.org/TR/WebCryptoAPI/
• NIST SP 800-38D – Galois/Counter Mode (GCM): https://csrc.nist.gov/pubs/sp/800/38/d/final
• NIST SP 800-132 – Passwortbasierte Schlüsselableitung (PBKDF2): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
• RFC 5116 – Authentifizierte Verschlüsselung: https://www.rfc-editor.org/rfc/rfc5116
• OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html