Step 24: DEK rotation.

RotateDEK generates a new DEK, re-encrypts all encrypted blobs, and
re-wraps with all existing KEK slots (passphrase + FIDO2). CLI wired
as `sgard encrypt rotate-dek`. 4 tests covering rotation, persistence,
FIDO2 re-wrap, and requires-unlock guard.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-03-24 12:01:57 -07:00
parent 3fabd86150
commit 5529fff649
7 changed files with 428 additions and 9 deletions

View File

@@ -577,12 +577,24 @@ Both flags must be specified together on the server side; on the client
side `--tls` alone uses the system trust store, and `--tls-ca` adds a
custom root.
### Planned: DEK Rotation (Phase 4)
### DEK Rotation
`sgard encrypt rotate-dek` generates a new DEK, re-encrypts all
encrypted blobs, and re-wraps the new DEK with all existing KEK slots.
Required when the DEK is suspected compromised (re-wrapping alone is
insufficient since the old DEK could decrypt the existing blobs).
encrypted blobs with the new key, and re-wraps the new DEK with all
existing KEK slots. Required when the DEK is suspected compromised
(re-wrapping alone is insufficient since the old DEK could decrypt
the existing blobs).
The rotation process:
1. Generate a new random 256-bit DEK
2. For each encrypted entry: decrypt with old DEK, re-encrypt with new DEK,
write new blob to store, update manifest hash (plaintext hash unchanged)
3. Re-derive each KEK (passphrase via Argon2id, FIDO2 via device) and
re-wrap the new DEK. FIDO2 slots without a matching connected device
are dropped during rotation.
4. Save updated manifest
Plaintext entries are untouched.
### Planned: Multi-Repo + Per-Machine Inclusion (Phase 5)