Threat Model & Sicherheitsarchitektur von Sanctum

Dieses Dokument beschreibt das Bedrohungsmodell, die Sicherheitsannahmen und die Schutzmechanismen von Sanctum v0.8.0 im reinen Userland-Betrieb.

1. Sicherheitsziele (Security Objectives)

Vertraulichkeit & Integrität ruhender Daten (Data at Rest): Containerdaten dürfen ohne Kenntnis des Master-Passworts oder des 24-Wort BIP-39 Notfallschlüssels weder entschlüsselt noch unbemerkt manipuliert oder wiederholt werden (Replay Protection).
Reine Userland-Ausführung ohne Kernel-Treiber: Vermeidung von Angriffsflächen im Betriebssystem-Kernel (kein Dokan, kein WinFsp, kein unsignierter Treiber). Das gemountete Dateisystem läuft vollständig im Benutzerkontext.
Schutz des Session-Tokens im lokalen Benutzerkontext: Das dynamische Session-Token für den lokalen WebDAV-Endpunkt darf weder über Prozesslisten (argv), Dateipfade, URL-Query-Parameter noch über Netzwerkinterfaces lecken.
Schutz vor forensischen Spuren (OpSec & Anti-Leak): Verhinderung von Betriebssystem-Artefakten (Thumbs.db, desktop.ini, ShellBags, NTFS Alternate Data Streams, Swap/Pagefile-Auslagerung).

2. Bedrohungsmodell & Angreiferprofile

2.1 Im Fokus (In Scope)

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).
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.
DNS-Rebinding & Browser-Angriffe	Eine im Browser des Nutzers laufende bösartige Website versucht, über DNS-Rebinding auf `http://localhost:<port>` zuzugreifen.	Strikte Fail-Closed Validierung des `Host`-Headers (`127.0.0.1`, `localhost`, `[::1]`). Abweisung aller externen Hostnamen (RT-02).
Argv- & Prozess-Scraping	Andere Prozesse des gleichen Nutzers oder Monitoring-Tools lesen die Prozess-Kommandozeile aus.	In-Process Netzlaufwerk-Verbindung via `WNetAddConnection2W` (Windows) ohne `net use`-Subprozess. Token wird niemals über `argv` übergeben.
URL- & Proxy-Logging (CWE-598)	Protokollierung von HTTP-Anfragen in lokalen Logs oder WebDAV-Clients.	Strikte Abweisung von Session-Tokens in URL-Pfad oder Query-String (`403 Forbidden`). Tokens dürfen ausschließlich im `Authorization`- oder `X-Sanctum-Token`-Header übertragen werden (SA-05).
Timing Side-Channel Angriffe	Messung von Antwortzeiten beim Token-Vergleich.	Strikter Constant-Time Vergleich (`subtle::ConstantTimeEq`) für alle Authentifizierungsprüfungen (SA-06).
RAM-Dump & Pagefile-Forensik	Windows lagert Arbeitsspeicher in `pagefile.sys` oder `swapfile.sys` aus.	Verriegelung der Schlüssel im physischen RAM via `VirtualLock` (Windows) bzw. `mlock` (Unix) mit RAII-Lebenszeitgarantie (`MemoryLockGuard`, V-03). Sicheres Überschreiben beim Beenden (`zeroize::Zeroizing`).
Slowloris DoS auf Loopback	Ressourcenerschöpfung durch offengehaltene Sockets.	Beschränkung auf max. 64 gleichzeitige Verbindungen (`MAX_CONCURRENT_DAV_CONNECTIONS`) und 15s Header-Read-Timeout (`HTTP_HEADER_READ_TIMEOUT`).
Begleitdateien-Forensik (-wal/-shm)	Angreifer analysiert temporäre SQLite-Dateien während oder nach dem Mount.	Sämtliche Daten werden vor Übergabe an SQLite verschlüsselt; WAL/SHM enthalten ausschließlich Ciphertext; TRUNCATE-Checkpointing und Bereinigung beim Aushängen (Z-03).
Nötigung / Schulterblick	Zwang zur Passwortherausgabe.	Alibi-Carrier (Hidden Vault Modell A) mit steganografisch verstecktem zweiten Tresor und unabhängigen Schlüsseln.

2.2 Außerhalb des Fokus (Out of Scope / Annahmen)

Vollständig kompromittierter Host: Ein Angreifer mit Kernel-Rootkit, Ring-0-Treiberrechten oder administrativem Keylogger kontrolliert das Gesamtsystem. In diesem Fall kann keine Userland-Anwendung Sicherheit garantieren.
Direkte Speicherinjektion unter demselben Benutzerkonto: Wenn Malware unter demselben Benutzerkonto mit denselben Rechten läuft und ReadProcessMemory / OpenProcess ausführt, greift das Betriebssystem-Sicherheitsmodell nicht. Sanctum empfiehlt getrennte Benutzerkonten und die Aktivierung von Windows Defender Exploit Protection.

3. Session-Token Bedrohungsmodell im Detail

3.1 Lebenszyklus und Generierung

Für jede Mount-Sitzung wird ein frisches 128-Bit kryptografisches Zufallstoken via rand::rngs::OsRng (CryptGenRandom bzw. getrandom) generiert.
Das Token existiert ausschließlich im flüchtigen Speicher des Sanctum-Prozesses und wird nach dem Aushängen sicher aus dem RAM genullt.

3.2 Keine Befehlszeilen-Leaks

Unter Windows wird das WebDAV-Netzlaufwerk nicht über einen externen Aufruf wie net use Z: http://127.0.0.1:8443 /user:... eingebunden, sondern über den direkten Win32-API-Aufruf:

WNetAddConnection2W(&net_resource, password, username, CONNECT_TEMPORARY)

Dadurch tauchen weder das Token noch die Zugangsdaten in der Windows-Prozesstabelle (Get-Process, Task-Manager, Sysinternals Process Explorer) auf.

3.3 Header-basierte Authentifizierung (SA-05 & SA-06)

Erlaubt:
- Authorization: Basic <base64(sanctum:token)>
- X-Sanctum-Token: <token>
Streng verboten: Token im URI-Pfad (http://127.0.0.1:8443/<token>/...) oder im Query-String (?token=<token>). Werden solche Anfragen empfangen, bricht Sanctum die Verarbeitung sofort mit HTTP 403 Forbidden ab. Dies verhindert, dass Tokens in Referrer-Headern, Browser-Verläufen oder WebDAV-Caches protokolliert werden.
Alle Vergleiche erfolgen in konstanter Zeit (ConstantTimeEq), sodass Angreifer keine Rückschlüsse auf Token-Präfixe über Laufzeitunterschiede ziehen können.

4. Speicher- und Prozessisolation

VirtualLock & mlock RAII (MemoryLockGuard): Der 256-Bit Data Encryption Key (DEK) wird sofort nach der Entschlüsselung im RAM mit VirtualLock (Windows) bzw. mlock (Linux) verriegelt. Dies garantiert, dass der Schlüssel zu keinem Zeitpunkt vom Windows Memory Manager in die unverschlüsselte Auslagerungsdatei (pagefile.sys / swapfile.sys) ausgelagert wird. Durch die Kapselung in Arc<MemoryLockGuard> bleibt dieser Schutz auch bei parallelen WebDAV-Anfragen erhalten und wird erst aufgehoben, wenn die letzte Referenz freigegeben wird (V-03).
Zeroizing: Alle Schlüsselpuffer (KEK, DEK, KDF-Zwischenergebnisse) implementieren zeroize::ZeroizeOnDrop und werden beim Verlassen des Gültigkeitsbereichs mit Nullen überschrieben.
Session-Lock & Inactivity Shield: Sanctum lauscht über WTSRegisterSessionNotification auf Sperr-Events (Win + L) und Inaktivitäts-Timeouts. Beim Sperren wird das Laufwerk unverzüglich getrennt, alle Caches geleert, WAL-Checkpoints geschrieben und die Schlüssel zerstört.

5. Dateisystem-Forensik & SQLite WAL/SHM Begleitdateien (Z-03)

5.1 Funktionsweise & Ciphertext-Garantie

Während ein Sanctum-Container geöffnet oder aktiv eingebunden ist, nutzt die zugrundeliegende SQLite-Engine den Write-Ahead Logging (WAL) Modus (PRAGMA journal_mode = WAL). Dadurch entstehen temporär zwei Begleitdateien im selben Verzeichnis wie der Container:

<container>.sanctum-wal (Write-Ahead Log für Transaktionsdaten)
<container>.sanctum-shm (Shared-Memory-Index für parallele Lese- und Schreibzugriffe)

Kryptografische Sicherheit: Alle Nutzdaten (Chunks) und Inode-Metadaten (Dateinamen) werden vor der Übergabe an SQLite im Sanctum-Userland via AES-256-GCM verschlüsselt. Die SQLite-Engine verarbeitet und speichert ausschließlich hochgradig ununterscheidbare Ciphertexte, Nonces, Authentifizierungs-Tags und HMAC-Prüfsummen.

Zu keinem Zeitpunkt gelangen Klartextdaten oder kryptografische Schlüssel (KEK, DEK) in die -wal- oder -shm-Dateien.
Selbst bei forensischer Extraktion der -wal- und -shm-Dateien sieht ein Angreifer ausschließlich unknackbares Zufallsrauschen ohne Entschlüsselungsmöglichkeit.

5.2 Sauberes Beenden & Checkpointing

Beim regulären Beenden (sanctum unmount, Ctrl+C, Inaktivitäts-Timeout oder Windows-Sitzungssperre) führt Sanctum automatisch:

Einen vollständigen WAL-Checkpoint durch (PRAGMA wal_checkpoint(TRUNCATE)), der alle ausstehenden Transaktionen in die .sanctum-Hauptdatei überführt und die WAL-Datei auf 0 Bytes kürzt.
Das Schließen der Datenbankverbindung durch, woraufhin SQLite die -wal- und -shm-Dateien vom Dateisystem entfernt.
Ein explizites Bereinigungs-Fallback aus (mount.rs), das verbleibende Begleitdateien sicher vom Host-Dateisystem löscht.

5.3 Abrupter Systemabsturz & OpSec-Überlegungen

Wird der Rechner abrupt stromlos gemacht (Hard Reset), stürzt das Betriebssystem ab oder wird der Prozess via SIGKILL / Task-Manager beendet, verbleiben <container>.sanctum-wal und -shm möglicherweise auf dem Datenträger.

Datenintegrität: Beim nächsten Öffnen des Containers führt SQLite automatisch ein WAL-Recovery durch, wodurch keine Daten verloren gehen und die Metadaten-Authentifizierung (K-01) intakt bleibt.
Forensische Sichtbarkeit: Ein Angreifer kann aus der Existenz und Dateigröße der -wal-Datei ablesen, dass vor dem Absturz Schreiboperationen stattgefunden haben und wie viele Bytes modifiziert wurden.
Flash-Wear-Leveling: Auf SSDs/NVMe-Speichern können gelöschte Dateisystem-Sektoren bis zur TRIM-Bereinigung physisch im Flash-Speicher existieren. Für maximale OpSec empfiehlt Sanctum die Ablage von Containern auf vollverschlüsselten Host-Laufwerken (BitLocker / LUKS) oder RAM-Disks.

10 KiB Raw Blame History