fix(format-v3): harden system binding against replay and bypass attacks (F-01, F-02, F-03)

- F-02: Require restore_nonce token and explicit confirmation (--rebuild-mac) for PendingRebuild
- F-01: Extend canonical MAC transcript to include chunk generation tuples (node_id, chunk_index, generation) and support transparent legacy migration
- F-03: Make V2-to-V3 container upgrade atomic with transactional rollback and dual-slot version update
- Bump version to 0.9.4 and update changelog and security docs

README.md

@@ -31,10 +31,10 @@ Sanctum ist eine eigenständige, speichersichere und hochperformante CLI-Anwendu
   Zufälliger 256-Bit Schlüssel via CSPRNG (`OsRng`). Der DEK wird mit dem KEK via AES-256-GCM verschlüsselt und im Header abgelegt.
 - **Speichersicherheit (Zeroize & VirtualLock)**:
   Alle Schlüsselstrukturen implementieren das `Zeroize`-Trait (`Zeroizing<[u8; 32]>`), um sensible Schlüsseldaten beim Verlassen des Gültigkeitsbereichs im RAM sofort sicher zu nullen. Schlüsseldaten werden mittels `VirtualLock` / `mlock` vor Paging geschützt.
-- **Chunk-Verschlüsselung (AES-256-GCM)**:
-  Dateien werden in Blöcken von 1 MB verschlüsselt.
-- **Swap-Attack-Schutz**:
-  Als Authenticated Associated Data (AAD) werden `node_id` (8 Bytes LE) und `chunk_index` (8 Bytes LE) an jeden Block gebunden. Ein Vertauschen von Chunks zwischen Dateien oder innerhalb einer Datei führt zum Authentifizierungsfehler.
+- **Chunk-Verschlüsselung (AES-256-GCM & 24-Byte AAD, K-02)**:
+  Dateien werden in Blöcken von 1 MB verschlüsselt. Als Authenticated Associated Data (AAD) werden `node_id` (8 Bytes LE), `chunk_index` (8 Bytes LE) und `generation` (8 Bytes LE) an jeden Block gebunden. Ein Vertauschen oder Zurücksetzen von Chunks führt zum Authentifizierungsfehler.
+- **Metadaten-Authentifizierung & Replay-Schutz (HMAC-SHA256, K-01 / F-01)**:
+  Ein kryptografischer HMAC-SHA256 (abgeleitet via HKDF `SANCTUM_META_MAC_V3`) bindet den gesamten Verzeichnisbaum deterministisch an den Datenschlüssel (DEK). Das kanonische Transcript sichert nicht nur Inode-Metadaten (Namen, Pfade, Größen, Zeitstempel), sondern auch die sortierte Sequenz aller Chunk-Generationen (`node_id LE64 ‖ chunk_index LE32 ‖ generation LE64`, F-01). Dies schließt Angriffe aus, bei denen ein Angreifer alte Datenbankzeilen gleicher Dateigröße wiederherstellt (Content-Replay).
 - **Dual-Vault (Multi-Slot & Carrier)**:
   Konstante 2-Slot-Architektur. Slot 0 dient als Standard-/Decoy-Vault, Slot 1 als Second Safe (Hidden Vault) oder CSPRNG-Dummy. Dient dem Schutz vor neugierigen Blicken oder beiläufigem Zwang im Alltag. (Hinweis: Die Trägerdatei besitzt hohe Entropie und ist forensisch nachweisbar; kein Anspruch auf juristisch unnachweisbare Abstreitbarkeit gegen behördliche Beschlagnahme).
   *Carrier-Format V2 mit Paged Manifest*: Das steganografische Dateisystem des Hidden Vaults nutzt eine skalierbare Paged-Manifest-Architektur. Blöcke 0 und 1 speichern den redundanten Superblock (C-02), während Inodes über dedizierte Inode-Pages (~1 MB Nutzdaten je Seite, ca. 4.500–7.000 Inodes pro Seite) dynamisch aus dem Blockpool verwaltet werden. Die Kapazität ist nicht mehr auf 7.000 Dateien limitiert, sondern skaliert dynamisch mit den verfügbaren Trägerblöcken. Robuste Fail-Soft-Resilienz (D-01) isoliert Seitenbeschädigungen, ein In-Memory Sekundärindex (D-02) beschleunigt Pfadoperationen auf O(Geschwister), und Sanctum warnt beim Einbinden automatisch bei Blockknappheit (< 20 freie Blöcke oder < 5% Restkapazität).
@@ -160,10 +160,29 @@ sanctum.exe backup --path "C:\Pfad\tresor.sanctum" --output "D:\Backup\tresor_ba
 # Container aus Backup wiederherstellen:
 sanctum.exe restore --path "D:\Backup\tresor_backup.sanctum" --output "C:\Pfad\tresor_restored.sanctum"
 
-# Vollständige Integritätsprüfung (B-Tree, Knoten und AEAD-Tags aller Chunks):
+# Header in separate Sicherungsdatei (.sanctum.hdr) sichern:
+sanctum.exe backup-header --path "C:\Pfad\tresor.sanctum" --output "D:\Backup\tresor.hdr"
+
+# Header aus Sicherungsdatei (.sanctum.hdr) wiederherstellen:
+sanctum.exe restore-header --path "C:\Pfad\tresor.sanctum" --header "D:\Backup\tresor.hdr"
+
+# Nach Header-Wiederherstellung: Metadaten-MAC mit autorisierter Neubindung mounten (F-02):
+sanctum.exe mount --path "C:\Pfad\tresor.sanctum" --rebuild-mac
+
+# Vollständige Integritätsprüfung (B-Tree, Knoten, Chunk-AEAD und Metadaten-MAC):
 sanctum.exe verify --path "C:\Pfad\tresor.sanctum"
 ```
 
+> [!IMPORTANT]
+> **Sicherheitsgarantie bei Header-Wiederherstellungen (F-02)**: Nach einem `restore-header` setzt Sanctum ein einmaliges 32-Byte CSPRNG-Token (`restore_nonce`). Der nachfolgende `mount` verlangt zwingend `--rebuild-mac` (oder eine interaktive Bestätigung mit `JA`), um den Metadaten-MAC neu aufzubauen und das Token zu löschen. Ein stillschweigendes Signieren manipulierter Metadaten ist ausgeschlossen; `-y` allein autorisiert keinen Rebuild.
+
+```powershell
+# Ältere V2-Container auf Format V3 aktualisieren (atomar & transaktional, F-03):
+sanctum.exe upgrade-format --path "C:\Pfad\tresor.sanctum"
+```
+> [!NOTE]
+> `upgrade-format` führt die Umschlüsselung aller Chunks von 16-Byte- auf 24-Byte-AAD und die Aktualisierung beider Header-Slots auf `version = 3` in einer **einzigen atomaren SQLite-Transaktion** durch. Bei Fehlern greift ein automatischer Rollback ohne inkonsistente Mischzustände.
+
 ---
 
 ### 6. Storage Compaction (Speicherbereinigung)