Fordan — Threat Model
This document describes the security assets Fordan protects, the adversaries it is designed to resist, and — equally important — the threats it explicitly does not defend against. Honesty about scope is part of the security design.
1. Assets Under Protection
1.1 Vault Master Key
The key material derived from the user's passphrase via Argon2. Compromise of the master key gives an attacker full access to every file in the vault. The key lives only in process memory during an active session and is never written to disk, logged, or sent over a network.
1.2 Plaintext File Contents
The actual bytes of files imported from the source disk — photos, documents, source code, personal records. At rest, every artifact is protected by an AEAD cipher (ChaCha20-Poly1305 or AES-GCM). Plaintext exists only in memory during import, encryption, and recovery operations.
1.3 File Names and Directory Structure
Metadata — the names of files, directory hierarchies, and timestamps — can reveal sensitive information even without the file contents. Fordan encrypts the vault payload including path metadata; the on-disk layout of vault entries does not expose the original file names or directory tree to an observer who lacks the master key.
1.4 Source Disk Integrity
The original data on the foreign NTFS/FAT32 disk. Accidental writes to a source drive can corrupt irreplaceable files. Fordan treats preserving source integrity as a first-class security property, not merely a UX concern.
2. Design Principles That Shape the Model
read-only-first
Filesystem access to foreign and source volumes is structurally read-only. The SourceVolume handle (and any equivalent abstraction) exposes no write, move, rename, or delete methods. The Rust type system enforces this at compile time; there is no runtime flag to bypass it. A foreign disk is untrusted input we only ever read.
Tamper-evidence guarantee
Every encrypted artifact in the vault carries an AEAD authentication tag. There are no unauthenticated ciphertext blobs. The verify subcommand re-checks every authentication tag on every artifact and fails loudly if any tag does not verify. A vault that cannot be fully verified is treated as corrupt — there is no "partially valid" state. This means any modification of vault bytes by a third party is detected before plaintext is ever returned.
No network in core
The fordan-core library and the fordan CLI binary contain zero network calls. Keys and plaintext never reach a server under any code path. An attacker with only network access cannot reach vault contents.
3. Adversaries and Scenarios
3.1 Lost or Stolen Laptop
Scenario: An attacker has physical possession of the machine on which a Fordan vault is stored, but the machine is locked or powered off at the time of theft.
What they see: Encrypted ciphertext blobs with AEAD tags. Without the passphrase they cannot derive the master key or recover plaintext. The encrypted vault is safe to store on a laptop, an external drive, or a cloud-synced folder.
Defence: Argon2 key derivation with tunable memory and time cost raises the cost of brute-force attacks against the passphrase. The strength of the defence is proportional to passphrase quality (see Section 4).
3.2 Malicious or Untrusted Foreign Disk
Scenario: The user plugs in a disk of unknown provenance — a drive found at a garage sale, borrowed from an untrusted party, or intentionally crafted to exploit a parser vulnerability.
What could go wrong: A malformed NTFS/FAT32 filesystem could trigger bugs in the volume parser, potentially allowing arbitrary code execution or path traversal during scanning.
Defence: The scanner uses a vetted, read-only parsing crate (ntfs, fatfs) with no write-back capability. Fordan never executes content found on the foreign disk (no autorun, no script evaluation, no DLL loading). All paths returned by the scanner are normalised and validated before being used as output destinations.
3.3 Ransomware-style Mass Encryption of the Vault
Scenario: Malware running on the host machine attempts to encrypt or destroy the vault directory while Fordan is not running.
Defence: Fordan does not defend the vault directory at the filesystem level — that is the operating system's job (backups, snapshots, filesystem permissions). What Fordan does guarantee is tamper evidence: if ransomware encrypts vault files and then the user recovers a backup, the verify subcommand will detect any byte-level corruption before returning plaintext.
3.4 Cloud-Sync Snooping
Scenario: The user stores the vault directory in a synced folder (Dropbox, iCloud, OneDrive). The cloud provider — or an attacker who compromises the provider — reads the uploaded files.
Defence: All vault contents are encrypted before they ever reach the local filesystem. The cloud provider sees only ciphertext and AEAD tags. File names and directory structure within the vault are also encrypted, so the provider cannot infer what the user rescued.
3.5 Offline Attack on the Vault
Scenario: An attacker exfiltrates the vault (e.g. from a cloud backup or a stolen drive) and runs a dictionary or brute-force attack against the master key offline, without time pressure.
Defence: Argon2id is tuned to make each password-check expensive in both time and memory. The security margin is directly proportional to passphrase entropy. Users should be advised to choose a strong passphrase; Fordan cannot enforce this.
4. What We DO Defend Against
- Passive ciphertext analysis by a laptop thief. The vault is cryptographically opaque without the passphrase.
- A malicious foreign disk supplied as untrusted input. Parsing is read-only; no bytes from the source are executed or written back.
- Silent tampering of vault artifacts. Every AEAD tag must verify; any modification is detected before plaintext is returned.
- Key or plaintext leakage via network. The core library has no network dependency; keys never leave the process.
- Source disk corruption during a rescue operation. The importer asserts that source checksums are unchanged before and after every copy.
- Accidental writes to the source volume. The type system prevents it at compile time; there is no runtime bypass.
5. What We Do NOT Defend Against
- Malware running on an unlocked machine. If an attacker has code execution on the same machine while Fordan is running, they can read process memory, intercept keystrokes, and exfiltrate plaintext. We do NOT defend against a compromised host OS.
- Weak or reused passphrases. Argon2 raises the cost of offline attacks but cannot compensate for a passphrase that appears in a breach database.
- Secure-delete guarantees on SSD or copy-on-write filesystems. When plaintext is written to a temp file during recovery and then deleted, the underlying storage may retain the bytes in flash wear-levelling blocks, CoW snapshots, or journalling artifacts.
- Hiding that a vault exists. The vault directory is visible on the filesystem. An attacker can see that a Fordan vault is present and how large it is, even if they cannot read its contents.
- Key escrow or account-based recovery. There is no way to recover the vault without the passphrase. Lost passphrases mean lost data.
- Multi-terabyte forensic data-carving. Fordan is a selective rescue tool, not a disk imager or forensic chain-of-custody system.
- BitLocker or FileVault source volumes. Encrypted source disks must be unlocked by OS tools before Fordan will scan them.
6. Summary Table
| Threat | Defended? | Mechanism |
|---|---|---|
| Laptop theft (machine off/locked) | Yes | Argon2 + AEAD encryption |
| Malicious foreign disk (parser exploit) | Yes | Read-only vetted parsers |
| Cloud-sync provider reads vault | Yes | All contents encrypted at rest |
| Offline brute-force of master key | Partial | Argon2id (depends on passphrase) |
| Ransomware encrypts vault files | Partial | Tamper evidence detects corruption |
| Malware on unlocked machine (live session) | No | Out of scope — OS problem |
| Weak user passphrase | No | Cannot be enforced by the tool |
| Secure-delete on SSD/CoW filesystem | No | Storage layer — out of scope |
| Hiding vault existence (steganography) | No | Explicitly out of scope |
| Source disk write corruption | Yes | Compile-time read-only enforcement |
| Silent vault tampering | Yes | AEAD tag verification on every read |