seal/open (bzw. wrap/unwrap) in allen vier betroffenen Stellen binden
ein Additional Authenticated Data an Chiffretext/DEK-Wrapper: ein
Austausch zwischen zwei Kontexten faellt beim Entschluesseln auf,
statt still zu funktionieren.
- dms/internal/crypto/envelope.go + service.go: AAD = Tenant-Slug
(bereits vorhandener Parameter in Service.Seal/Open, Signatur
unveraendert -- keine der rund 30 externen Aufrufstellen musste
angepasst werden)
- archive/internal/backupcrypto/envelope.go + reposecret.go/file.go:
gleiches Muster, AAD = Tenant-Slug
- mail/internal/crypto/envelope.go + service.go + kekversions.go:
gleiches Muster, AAD = Tenant-Slug (inkl. ARC-08
KEK-Versionsverwaltung)
- internal/kek/master.go + store.go: wrap/unwrap sowie
EncryptWithTenantKEK/DecryptWithTenantKEK binden AAD. Die drei
echten externen Aufrufer angepasst: ldapsync (Tenant-ID + Zweck),
webhook (Ziel-URL des Abonnements), account-api modulekeys (fester
Zweck-Bezeichner -- SecretCipher-Interface aus internal/moduletrust
reicht keine Datensatz-ID durch, eine Erweiterung wuerde in andere
Module hineinwirken, bewusst nicht Teil dieser Kachel)
Rueckwaertskompatibel: jedes open/unwrap versucht zuerst mit AAD,
faellt bei Fehlschlag auf kein-AAD zurueck -- vor dieser Aenderung
versiegelte Datensaetze bleiben lesbar.
Bekannte, dokumentierte Grenze: ein Austausch zwischen zwei
Datensaetzen DESSELBEN Mandanten/Kontexts bleibt unerkannt (identisches
AAD) -- volle Bindung an den einzelnen Datensatz braeuchte eine
Datensatz-ID an rund 30 Aufrufstellen, bewusst nicht Teil dieser
kleinstmoeglichen Loesung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
patrickandClaude Sonnet 5
0ea129e71c