# 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.