FDN-09: verschluesselung at rest & schluesselverwaltung

Envelope-Encryption: DEK (32 Byte) frisch je Objekt, AES-256-GCM fuer Objektinhalt, DEK selbst mit Tenant-KEK verpackt (WrapDEK/UnwrapDEK). KEK kommt ausschliesslich ueber HTTPKEKProvider von Core API-10 (internal/kek.Handler.TenantKEKHandler-Vertrag, Service-Credential- authentifiziert), wird nie persistiert - jeder Seal/Open-Aufruf bezieht ihn frisch. RewrapDEK fuer KEK-Rotation ohne Neuverschluesselung der Objekte (nur der DEK-Wrapper wird neu verpackt, Chiffretext bleibt unveraendert). Auf 192.168.1.131 verifiziert: Round-Trip Encrypt/Decrypt, manipulierter Chiffretext UND falscher Schluessel werden beide ueber GCM-Auth-Tag abgelehnt, KEK-Rotation real getestet (RewrapDEK, altes Objekt danach mit neuem KEK weiterhin lesbar, alter KEK funktioniert nicht mehr). Befund dokumentiert: Cores internal/kek.Handler (Gegenstelle fuer den KEK-Bezug) ist noch in keinem cmd/*/main.go verdrahtet, dieselbe Fehlerklasse wie FDN-03/QA-05/AUD-06. HTTPKEKProvider daher gegen den dokumentierten Vertrag getestet, nicht gegen eine laufende Core-Instanz. Siehe dms/docs/FDN-09-PRUEFPROTOKOLL.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
2026-08-29 22:13:49 +02:00
parent bfea94b032
commit bf7559e118
7 changed files with 671 additions and 0 deletions
@@ -0,0 +1,57 @@
+# FDN-09 – Prüfprotokoll: Verschlüsselung at rest & Schlüsselverwaltung
+
+Welle 2. Voraussetzung: FDN-01 (Status "Fertig"), Core API-10 (Status
+"Fertig").
+
+## Umsetzung
+
+`internal/crypto`:
+
+- `GenerateDEK` — 32-Byte-Zufallsschlüssel je Objekt (Akzeptanzkriterium 1).
+- `EncryptStream`/`DecryptStream` — AES-256-GCM auf dem Objektinhalt.
+- `WrapDEK`/`UnwrapDEK` — Envelope-Verpackung des DEK mit dem Tenant-KEK.
+- `RewrapDEK` — verpackt einen DEK-Wrapper von altem auf neuen KEK um,
+  ohne DEK oder Objekt-Chiffretext anzufassen (Akzeptanzkriterium 3).
+- `HTTPKEKProvider` — bezieht den Tenant-KEK über Cores
+  `internal/kek.Handler.TenantKEKHandler` (API-10), Service-Credential-
+  authentifiziert (Akzeptanzkriterium 2: KEK kommt ausschließlich von Core,
+  wird hier nie persistiert — jeder `Seal`/`Open`-Aufruf bezieht ihn frisch).
+- `Service` — verbindet `KEKProvider` mit den Envelope-Operationen
+  (`Seal`/`Open`), das ist die einzige öffentliche Schnittstelle, die
+  FDN-03/DOC-01 nutzen sollen.
+
+## Wichtiger Befund: Core-Endpunkt noch nicht live verdrahtet
+
+Dieselbe Fehlerklasse wie in FDN-03 (dort: `internal/resync.Handler`):
+`internal/kek.Handler` (inkl. `TenantKEKHandler`) ist in Core vollständig
+implementiert und eigenständig getestet, aber **in keinem `cmd/*/main.go`
+registriert** (per `grep` bestätigt, Stand 2026-08-29). `HTTPKEKProvider`
+ist daher gegen den **dokumentierten Vertrag** getestet (exakte
+Feldnamen/Header/Query-Parameter aus `internal/kek/handler.go` gelesen),
+nicht gegen eine echte laufende Core-Instanz. Empfehlung wie schon bei
+FDN-03: Core-Board-Folgeticket analog `AUD-06`/dem FDN-03-Befund, das
+sowohl den Resync- als auch den KEK-Endpunkt in einen laufenden Dienst
+verdrahtet.
+
+## Prüfungen
+
+| # | Prüfung | Ergebnis |
+|---|---|---|
+| 1 | Round-Trip Encrypt/Decrypt liefert identischen Klartext | **bestanden** — `TestEncryptDecryptStream_RoundTrip`, `TestService_SealOpen_RoundTrip` |
+| 2 | Manipulierter Chiffretext wird bei Decrypt erkannt und abgelehnt (GCM-Auth-Tag) | **bestanden** — `TestDecryptStream_RejectsTamperedCiphertext` (letztes Byte gekippt) UND `TestDecryptStream_WrongKeyRejected` (falscher Schlüssel, zweite mögliche Fehlerursache) |
+| 3 | KEK-Rotation getestet, alte Objekte weiterhin lesbar | **bestanden** — `TestRewrapDEK_RotationKeepsObjectReadable`: Objekt vor Rotation verschlüsselt, `RewrapDEK` von altem auf neuen KEK, Chiffretext bleibt UNVERÄNDERT, alter KEK kann neuen Wrapper nicht mehr entpacken (Rotation wirksam), neuer KEK + neuer Wrapper entschlüsseln das unveränderte, alte Objekt korrekt |
+
+## Build/Test-Ergebnis (192.168.1.131, `make check`)
+
+```
+go build ./...  -> clean
+go vet ./...    -> clean
+golangci-lint run ./...  -> 0 issues
+go test ./... -p 1 -count=1  -> 5/5 Pakete ok, 0 Fehlschläge (10 neue crypto-Tests)
+```
+
+## Gesamtergebnis
+
+**Bestanden**, mit derselben dokumentierten Core-seitigen Abhängigkeit wie
+FDN-03 (Abschnitt "Wichtiger Befund"). Alle drei Akzeptanzkriterien und
+alle drei Pflichtprüfungen im Rahmen des DMS-seitigen Scopes erfüllt.