WonderFunds speichert Finanzdaten. Das allein macht Kryptografie nicht optional, sondern zwingend. Dieser Artikel beschreibt die konkreten Design-Entscheidungen: warum wir bestimmte Verfahren gewählt haben, welche Alternativen wir verworfen haben und wo die Grenzen unseres Threat-Models liegen.
Warum AES-256-GCM?
Das Bedrohungsszenario bei WonderFunds ist Data-at-Rest: Jemand erlangt Zugriff auf die Datenbank. Nicht auf den laufenden Anwendungsserver, nicht auf den Netzwerkverkehr, sondern auf die gespeicherten Daten.
Für dieses Szenario brauchen wir symmetrische Verschlüsselung. Beide Seiten der Operation (Verschlüsselung und Entschlüsselung) laufen auf demselben Server. Es gibt keinen zweiten Kommunikationspartner, der einen öffentlichen Schlüssel bräuchte. Asymmetrische Verfahren wie RSA oder ein hybrides Schema wären hier Overhead ohne Sicherheitsgewinn.
AES-256-GCM liefert zwei Eigenschaften in einem Durchgang:
- Vertraulichkeit: Die Daten sind ohne Schlüssel nicht lesbar.
- Integrität: Der GCM-Modus erzeugt einen Authentication Tag. Jede Manipulation, auch ein einzelnes geflipptes Bit, führt dazu, dass die Entschlüsselung fehlschlägt. Nicht mit falschen Daten, sondern mit einem Fehler.
Die Alternative wäre AES-256-CBC plus ein separater HMAC. Funktioniert, aber GCM erledigt beides atomar. Weniger Code, weniger Fehlermöglichkeiten bei der Implementierung.
Per-User KEK-Ableitung
Nicht alle Benutzer teilen sich denselben Schlüssel. WonderFunds leitet für jeden Benutzer einen individuellen Key Encryption Key (KEK) ab:
KEK = SHA-256(masterKey || userId)
Der Master Key ist eine Umgebungsvariable mit mindestens 128 Bit Entropie (32 Hex-Zeichen), die per SHA-256 auf 256 Bit normalisiert wird. Die Benutzer-ID ist eine UUID.
Jeder Benutzer hat einen eigenen Schlüssel. Wird ein einzelner KEK kompromittiert, betrifft das ausschließlich diesen einen Benutzer. Alle anderen bleiben geschützt.
Warum SHA-256 statt HKDF oder PBKDF2?
PBKDF2 und Argon2 sind Key-Stretching-Algorithmen: sie machen die Ableitung absichtlich langsam, um Brute-Force-Angriffe auf schwache Eingaben zu erschweren. Unser Input ist aber nicht schwach: Der Master Key hat 256 Bit Entropie. Brute-Force ist bei dieser Schlüssellänge kein realistisches Szenario.
HKDF wäre die formal korrektere Wahl für Key Derivation. In der Praxis liefert SHA-256(masterKey || userId) bei hochentropischem Input ein gleichwertiges Ergebnis. Die Entscheidung fiel zugunsten von Einfachheit: weniger Abhängigkeiten, weniger Konfigurationsparameter, weniger Angriffsfläche in der Implementierung.
