harald/sanctum
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases 19 Wiki Activity

fix(format-v3): transcript versioning in HMAC and atomic upgrade MAC (F-04, F-05)
Sanctum Release / Build & Test (Windows x86_64 & Linux musl) (push) Waiting to run
Details
Sanctum Release / Sign & Release (push) Blocked by required conditions
Details

Browse Source
This commit is contained in:
harald
2026-09-22 21:02:22 +02:00
parent 3a1a1ca6ce
commit 76c23dbfa3
15 changed files with 755 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files
THREAT_MODEL.md
+21 -2
View File
@@ -1,6 +1,6 @@
# Threat Model & Sicherheitsarchitektur von Sanctum
Dieses Dokument beschreibt das Bedrohungsmodell, die Sicherheitsannahmen und die Schutzmechanismen von **Sanctum v0.9.4** im reinen Userland-Betrieb.
Dieses Dokument beschreibt das Bedrohungsmodell, die Sicherheitsannahmen und die Schutzmechanismen von **Sanctum v0.9.5** im reinen Userland-Betrieb.
---
@@ -23,7 +23,7 @@ Dieses Dokument beschreibt das Bedrohungsmodell, die Sicherheitsannahmen und die
| Angreifer / Bedrohung | Beschreibung | Sanctum-Gegenmaßnahme |
|---|---|---|
| **Kalter Datenträger-Angriff** | Angreifer hat physischen oder dateibasierten Zugriff auf die `.sanctum`-Datei auf USB-Stick, SSD oder Cloud-Storage. | Argon2id KDF (256 MiB, t=4, p=4), AES-256-GCM mit eindeutiger Chunk-Generation AAD, kanonische HMAC-SHA256 Metadaten-Authentifizierung (Format V3). |
| **Kalter Datenträger-Angriff** | Angreifer hat physischen oder dateibasierten Zugriff auf die `.sanctum`-Datei auf USB-Stick, SSD oder Cloud-Storage. | Argon2id KDF (256 MiB, t=4, p=4), AES-256-GCM mit eindeutiger Chunk-Generation AAD, kanonische HMAC-SHA256 Metadaten-Authentifizierung mit Transkript-Versionierung (Format V3.2, F-01/F-04). |
| **Böswillige Manipulation / Bitrot** | Gezieltes Verändern von Metadaten oder Chunks im Speicher. | AEAD-Tags auf allen Datenblöcken; `sanctum verify` erkennt jede Modifikation; Schreib- und Leseoperationen verwerfen manipulierte Blöcke sofort (`Fail-Closed`). |
| **Replay- & Chunk-Vertauschungsangriffe** | Vertauschen von Chunks zwischen Dateien oder Einspielen alter Versionen. | Kryptografische Bindung aller Chunks an `(node_id, chunk_index, generation)` in den AEAD Additional Authenticated Data (AAD). |
| **Lokale Benutzerisolation** | Mehrbenutzersysteme: Andere Standardbenutzer auf demselben Rechner. | Windows- und Unix-Dateirechte; TCP-Bind ausschließlich an Loopback `127.0.0.1`; dynamisches 128-Bit Session-Token. |
@@ -139,5 +139,24 @@ In Sanctum werden Dateinamen mit AES-256-GCM verschlüsselt. Um Swap-Angriffe zu
Frühere Versionen von Sanctum (vor v0.8.0) verwendeten leere AAD für Dateinamen. Das Flag `--legacy-names` erlaubt die Entschlüsselung von Dateinamen ohne AAD-Bindung als Fallback.
- **Risiko**: Bei aktiviertem `--legacy-names` ist der Schutz vor Vertauschen von Dateinamen aufgehoben. Ein Angreifer könnte Dateien manipulieren, indem er verschlüsselte Namen zwischen verschiedenen Verzeichnissen vertauscht.
- **Empfehlung**: Dieses Flag darf **ausschließlich** zur einmaligen Migration von Altdaten verwendet werden. Im regulären Betrieb muss es deaktiviert bleiben.
---
## 8. Format-V3 Systembindung & Integritätshärtung (F-01 bis F-05)
### 8.1 Transkript-Bindung & Replay-Schutz (F-01, F-04)
- **Problem**: Bei isolierter AEAD-Bindung der Generation im Chunk-Header (`node_id ‖ chunk_index ‖ generation`) konnte ein Angreifer alte Chunk-Zeilen (`ct, nonce, tag, generation`) wiederherstellen, wenn die Datei dieselbe Größe behielt.
- **Kanonischer HMAC**: Sanctum bindet alle sortierten Chunk-Tupel (`ORDER BY node_id, chunk_index: node_id LE64 ‖ chunk_index LE32 ‖ generation LE64`) direkt in das Metadaten-Transkript ein.
- **Transkript-Versionierung (F-04)**: Um ein unbegrenztes Rollback auf v0.9.3-Metadaten-Blobs (`LegacyValid`) zu verhindern, umfasst der HMAC-Transkript-Input die Little-Endian `transcript_ver`:
`b"SANCTUM_META_V3\0" ‖ metadata_gen (LE64) ‖ transcript_ver (LE32) ‖ canonical`.
Sobald ein Container auf `transcript_ver = 2` migriert wurde, lehnt Sanctum ältere 0.9.3-Transkripte strikt als `Invalid` ab.
### 8.2 Autorisierter Header-Rebuild (F-02)
- Ein Rebuild des Metadaten-MACs (`metadata_gen == 0 && metadata_mac IS NULL`) nach einem Header-Restore wird ausschließlich zugelassen, wenn ein kryptografisches CSPRNG-Token (`restore_nonce`) in `meta` existiert und der Benutzer explizit `--rebuild-mac` übergibt oder interaktiv `"JA"` bestätigt. Manipulierte SQLite-Header ohne dieses Token werden unweigerlich abgewiesen.
### 8.3 Transaktions-Atomarität & Resilienz (F-03, F-05)
- Das Format-Upgrade (`upgrade_to_v3`) wird in einer einzigen atomaren SQLite-Transaktion ausgeführt. Bei jeglichem Entschlüsselungs- oder Umschlüsselungsfehler erfolgt ein vollständiger Rollback auf Version 2.
- Der initiale Metadaten-MAC (`transcript_ver = 2`, `gen = 1`) wird vor dem Transaktions-Commit berechnet und geschrieben (F-05), sodass keine ungeschützten Zombie-Container (`version = 3, metadata_mac IS NULL`) entstehen können.
- Im Falle eines abrupten Stromausfalls vor Commit verbleibt der Container sauber auf Version 2. Sollte ein Altsystem dennoch in einen Zombie-Zustand geraten sein, bietet `sanctum upgrade-format` eine automatische Reparatur, sofern kein unautorisierter Restore vorliegt (`restore_nonce IS NULL`).