sysopsandClaude Sonnet 5
bf7559e118
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
3.0 KiB
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 Coresinternal/kek.Handler.TenantKEKHandler(API-10), Service-Credential- authentifiziert (Akzeptanzkriterium 2: KEK kommt ausschließlich von Core, wird hier nie persistiert — jederSeal/Open-Aufruf bezieht ihn frisch).Service— verbindetKEKProvidermit 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.