Leftovers of Every Logon

## What volume encryption actually promises Full-disk encryption — BitLocker on Windows, FileVault on macOS, LUKS/dm-crypt on Linux — encrypts a **block device**, not files. A single volume master key encrypts the sectors; that key is itself wrapped by something the machine or the user can supply at boot: a TPM measurement, a pre-boot PIN, a passphrase, a recovery key. The promise is narrow and it is worth stating precisely: **an adversary who obtains the storage while it is at rest, and who does not have the unlock secret, cannot read it.** Lost laptop in a taxi. Drive pulled from a decommissioned machine. Disk sent for warranty repair. Those are the scenarios it removes, and it removes them well. ## What happens the moment the machine boots At unlock, the volume master key is decrypted and held in memory by the kernel's crypto layer. From then on, every read of a sector is decrypted on the way up and every write encrypted on the way down, transparently, for **every** process. There is no per-file password prompt and no per-user separation at this layer — the volume is either mounted or it is not. So on a running, unlocked machine the filesystem looks exactly like an unencrypted one. Ordinary file permissions are what separate users at that point, and nothing else. This is the single fact the question turns on, and it is the one a platform team proposing "just encrypt the disk" has usually not internalised. ## Who is inside the boundary Everything that runs after unlock is inside: - the signed-in user, reading their own profile; - any process running under that user's token, including one they were talked into starting; - a local administrator, reading any profile and the registry hives; - backup and management software running as SYSTEM or root. A departing contractor on their own issued laptop is the cleanest example precisely because nothing about it is exotic. They have legitimate local access, they need no exploit, and they drop no code. They copy files. ## What is readable without elevating, and what needs it Without any elevation, in the user's own profile: - the browser profile directory, holding saved logins and the cookie store; - `~/.ssh/id_ed25519` or `id_rsa` — plaintext key material unless a passphrase was set; - `~/.aws/credentials` and equivalents — long-lived access keys as plain text; - kubeconfigs, API tokens written to dotfiles by command-line clients; - the DPAPI master key files under `%APPDATA%\Microsoft\Protect\<SID>\`. With local administrator on Windows: - `SAM` (local account hashes) together with `SYSTEM` (the boot key that unseals them); - `SECURITY`, which holds the cached domain logon verifiers. On macOS the login keychain plays the DPAPI role and is unlocked by the login password; FileVault reasons identically to BitLocker. ## Why the obvious hardening does not close it Adding a pre-boot PIN to the TPM is a real improvement — it defeats an attacker who steals the whole machine and lets the TPM release the key to a booted OS they then attack. But it strengthens only the powered-off case. It does nothing after unlock. Encrypting the credential file itself with a key the same process can reach is the same mistake one layer down: whatever unwraps it for the legitimate reader unwraps it for the thief in that same context. The property that actually helps is **non-exportability** — a key that lives in a TPM or a security key and can be *used* but never *copied* (a FIDO2/WebAuthn credential is the clean example), or material with a lifetime short enough that a copy is stale before it can be used. ## The honest summary Volume encryption is a good control against a specific, common, physical loss. It is not a credential-storage control, and treating it as one leaves the whole on-disk credential estate exposed to the one person guaranteed to be inside the boundary: the user.