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
58 lines
3.0 KiB
Markdown
58 lines
3.0 KiB
Markdown
# 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.
|