Tenant-KEK-Rotation ohne Neuverschlüsselung des Archivbestands
(Envelope-Encryption bleibt aus ARC-02 unverändert, Objekt-DEKs werden
nicht angefasst).
Core (API-10, RotateTenantKEK) ersetzt den Tenant-KEK durch einen neuen
Wert und hält keine Historie vor — TenantKEKHandler liefert immer nur den
aktuellen Schlüssel. Damit Mail Altbestand nach einer Rotation weiterhin
lesen kann, versioniert Mail selbst jeden bezogenen Tenant-KEK:
- crypto/kekversions.go: KEKVersionStore, lokal verschlüsselt mit
eigenem Wrap-Schlüssel (nur über Umgebungsvariable), erkennt Rotation
automatisch (RecordIfNew), erlaubt gezieltes Sperren einer Version
(Revoke).
- crypto/service.go: Service.WithVersionStore (optional, Open bleibt für
Rückwärtskompatibilität unverändert), Seal zeichnet die verwendete
KEK-Version auf, neue Methode OpenAtVersion liest mit historischer
statt aktueller Version.
- encstorage.go: neuer .dek.version-Sidecar (gleiches Muster wie der
bestehende .dek-Sidecar), GetDecrypted nutzt OpenAtVersion; fehlender
Sidecar (Altobjekte vor ARC-08) fällt auf Version 0 zurück, identisches
Verhalten wie vorher.
Prüfungen (alle real durchgeführt, siehe mail/docs/ARC-08-PRUEFPROTOKOLL.md):
1. TestRotation_OldArchiveStaysReadableAfterMasterKeyRotation: Altbestand
nach realer Rotation weiterhin lesbar über OpenAtVersion, naives Open
mit dem neuen Schlüssel schlägt für das alte Objekt real fehl.
2. TestRotation_CompromisedOldKeyCanBeRevoked: gesperrte Version blockiert
Lesezugriff real, andere Versionen bleiben unberührt.
3. Rotationsvorgang vollständig durchgespielt (siehe Prüfprotokoll).
Kein Umbau: storage/dedup/indexworker/search unverändert, bestehende
ARC-02-Tests (encstorage_test.go) unverändert weiterhin grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
- mail/internal/crypto: Envelope-Encryption (AES-256-GCM), DEK pro
Objekt, HTTPKEKProvider bezieht Tenant-KEK ueber Core API-12 -
bewaehrtes Muster aus DMS FDN-09, Neuimplementierung (Mail kann DMS
nicht importieren)
- mail/internal/encstorage: verbindet ARC-01 (storage.Service) mit
ARC-02 (crypto.Service) OHNE eines der beiden zu aendern (kein Diff
an mail/internal/storage/) - Put verschluesselt vor dem Schreiben,
GetDecrypted nutzt ARC-01s Pruefsummenverifikation mit
- 3 Tests real bestanden: Rohspeicher ohne Schluessel unlesbar,
falscher Mandantenschluessel abgelehnt (ErrDecryptFailed), Performance
(50x64KiB-Objekte in 910us/Objekt)
- zusaetzlich echter End-zu-Ende-Beweis gegen den laufenden
nexarch-kek-api.service (API-12): vollstaendiger Put->GetDecrypted-
Roundtrip ueber echten HTTP-KEK-Bezug, nicht-existenter Tenant real
abgelehnt (404)
- offener Punkt ehrlich vermerkt: internal/crypto/internal/encstorage
fehlen noch in QA-01s Pflichttest-Gate-Pfadmustern
Pruefungen siehe mail/docs/ARC-02-PRUEFPROTOKOLL.md
