The Honeypot Under Your Desk

Cristina asked me what would happen if someone stole the box. I started explaining the encryption setup and stopped halfway through because I was answering the wrong question. A thief can't make you type your password. A person holding a gun to your head can, the standard wrench attack, and ghost.secd is built to protect against exactly this scenario, because the attacker doesn't know how many PINs you have, you could have one or five, and there is no easy way to check.

I'd been so focused on building something that protects you from the cloud that I hadn't sat with what it actually means to carry your entire indexed life on a single piece of hardware that someone with legal authority can compel you to unlock. The same thing that makes LocalGhost useful, the fact that the box knows everything about you and can pull threads across years of context, is exactly what makes the box the worst thing to surrender. A normal laptop seized at a border crossing leaks your email and your photos. A LocalGhost box hands over the searchable index to your entire life, perfectly correlated, with the daemons standing ready to answer questions about you that you wouldn't have thought to ask yourself.

Encryption protects data at rest. Encryption does not protect you when someone is standing in front of you with the legal authority to compel you to unlock the device. Border agents can require decryption in most jurisdictions, courts can issue warrants compelling cooperation, and the XKCD wrench attack is the simplest version of the same threat model: a thirty-dollar wrench applied to a kneecap defeats any cryptographic system, because the attacker doesn't need to break the math, they just need to break the person.

The standard advice is to encrypt your stuff and hope, which works fine until the day it doesn't. The model LocalGhost has to work under is that you assume the box will eventually be seized, examined, or pointed at by someone with the authority to make you cooperate, and you build the security around that assumption rather than around the assumption that the encryption alone will hold forever.

v1 of ghost.secd is built primarily for the bored border agent, the curious customs officer, the routine inspection where someone with legal authority wants to look but isn't running forensics. v1 is built secondarily for the wrench attack scenario where you want to be able to cooperate convincingly under coercion. It is not built for a targeted forensic examination by a state-level adversary who knows LocalGhost ships duress PINs and is specifically looking for the hidden volume signature, because hidden volume detection is a known research area, VeraCrypt's design has known statistical fingerprints, and any system that documents duress mode as a feature is by definition known to ship duress mode. If your threat model is a nation-state with prior knowledge and time, you need a different tool, and probably a different country.

At the other end of the coercion scale there is a hard limit. A border agent in an adversarial jurisdiction can compel every PIN you have, someone holding a weapon to your head can compel every PIN you have, and no duress architecture, including this one, physically prevents you from sharing every PIN when the cost of refusing is high enough. What v1 actually offers against unlimited coercion is structural ambiguity about completeness and nothing stronger, and I want to be clear that ambiguity is not the same as physical impossibility.

The basic idea is borrowed from VeraCrypt and similar tools that have done this for years. Hidden volumes work by encrypting parallel filesystems with different derived keys, where each PIN unlocks its own volume, and the same hardware key proves you're physically present regardless of which PIN you typed. Only the PIN determines which world you walk into.

The mechanical version is simple. ghost.secd manages two or more encrypted volumes with different derived keys. The FIDO2 hardware key proves physical possession but doesn't store the PINs anywhere. ghost.secd derives the decryption key from whichever PIN you entered, and the volume that derived key opens is the volume you see. There's no toggle in the software, no setting that says "duress mode active," nothing for a forensic examiner to find that would suggest other worlds exist. Each duress volume is just a different filesystem mounted by a different derived key, and the real volume sits in unallocated space that looks like random noise to anyone without the real PIN.

You configure your PINs once, at setup, and you remember them. You will never accidentally type a duress PIN when you meant the real one because each PIN is meaningfully distinct from the others, and the way you choose them is up to you. When someone is standing in front of you with the authority to make you unlock the box, you cooperate, you type a duress PIN, you watch them browse through six months of weather observations and grocery receipts, and you walk away with your real life intact.

v1 of ghost.secd actually generalises this beyond two PINs. You can configure one PIN if you don't want duress mode at all, two if you want a single decoy, five if you want layered plausibility where some PINs open populated decoy volumes and others open volumes that look freshly initialised, or any combination that includes a purge PIN that destroys everything instead of unlocking anything useful. The architecture treats every PIN identically by deriving a separate key from each and unlocking whatever volume that derived key happens to open, and the contents of the volume tell ghost.secd what to do next. Most volumes are filesystems, your real data or a decoy. One of the volumes can be almost empty, holding nothing but a marker that ghost.secd recognises as the instruction to start destroying everything.

The advantage is structural: there is no metadata anywhere on the box recording how many PINs exist or what each one does, because the configuration lives inside the encrypted volumes themselves and is invisible without the keys. An attacker who demands every PIN you have can't verify they got them all, can't distinguish a duress PIN from a real one without typing it, and can't tell from the outside which PIN unlocks a volume and which one wipes the box.

The duress PIN architecture and the volume separation are the v1.0 work, the part where multiple encrypted volumes coexist on the same disk with separate derived keys for each and the box can be unlocked into whichever one a PIN happens to open. The part where ghost.secd generates a fully convincing decoy life to populate a duress volume, with believable journals and plausible spending patterns and a lived-in photo library, is aspirational and substantially harder. For the initial release the duress volumes will be either fresh-looking systems that appear recently set up or manually populated decoys you build yourself. The automatic decoy generation comes later, and the design has problems I have not solved, including how to make a generated life look lived in without falling into the uncanny valley where the absence of texture is the tell.

This is the part I keep coming back to because it changes the threat model completely. The traditional security mindset treats compelled disclosure as a failure state, the point at which the system has lost. The hidden volume design treats compelled disclosure as a normal operating mode, something the architecture handles cleanly because the architecture was designed to handle compelled disclosure from the start.

You can hand over a PIN. You can let them browse. You can answer their questions about why your photo library is so small or why you don't journal much. The decoy life looks plausible because the only person who knows the decoy is a decoy is you, and the decoy is a different boring person who happens to use the same hardware. Sanitised data wouldn't work because the patterns themselves are identifying, and any decoy that preserved your real patterns with the dangerous bits redacted would just be a slightly worse version of surrender.

The duress PIN architecture works partly because attackers don't always know to ask for additional PINs. The moment LocalGhost ships duress mode as a documented public feature, every adversary who has heard of LocalGhost knows to ask how many PINs exist, and VeraCrypt has this same problem with its two-volume design and has never solved it. The multi-PIN design only partially closes the gap, and partial is the right word, because I am not pretending the architecture beats a determined targeted adversary who has prior knowledge of how the system works.

Hidden volumes are for the case where you want your data to survive the encounter. The Purge is for the case where you don't.

The Purge is just another PIN in the multi-PIN scheme. ghost.secd does not distinguish between a real PIN, a duress PIN, and a purge PIN at the architecture level, because every PIN derives a key, every key opens a volume, and the only thing that determines what happens next is what ghost.secd finds inside that volume after it mounts. Most volumes contain a filesystem with your data, or a decoy filesystem with someone else's. The purge volume is almost empty, holding nothing but a short string that ghost.secd recognises as the instruction to start destroying everything.

The user experience is deliberately undramatic. You type the purge PIN, the volume mounts, ghost.secd reads the marker, and the screen shows what looks like a first-run setup wizard, the kind of screen you would see on a brand-new device that has never been configured. Behind that screen, every other encrypted volume is being overwritten with random data, every daemon's database is being dropped, the Postgres instances are being wiped, the Redis caches are being flushed, the Mist shards on the network are being dereferenced so the distributed copies become unrecoverable, and the encryption keys are being destroyed. By the time the destruction finishes the box is on its way back to factory state with no trace of what was on it before. The attacker watching you type sees nothing alarming. They see a fresh-looking device that could be a brand-new install, or maybe the wrong PIN, or maybe just a box that was never set up properly, and the assumptions they walk away with are not the assumptions they walked in with.

Remembering several PINs is harder than it sounds and most people do it badly. The way I handle it is to anchor everything to one number I already know and offset from there. If my real PIN is 2525, then 2524 is one decoy, 2523 is another, and 1525 is the purge. The first three digits stay constant across the decoys with the last digit walking down by one each time, and the purge changes a different position entirely so I can never confuse the decoy pattern with the destruction pattern. Each PIN is distinct enough that I will not confuse them under stress, and related enough that I do not have to memorise four unrelated four-digit numbers. Build whatever mnemonic works for you, but build the system before you set the PINs, because trying to invent a memory aid after the fact is how you end up locking yourself out of the real volume.

The two options exist alongside each other because they answer different questions. The duress PIN answers how to cooperate without surrendering. The Purge answers how to make sure no one ever recovers anything from the box, ever. Those are not the same question, and neither answer is sufficient on its own.

ghost.secd handles encryption, key management, presence verification, the duress flow, and the purge. There are other things ghost.secd will do that I am not ready to write about yet, including the harder parts around mobile integration where biometric APIs don't expose which finger unlocked the device, key recovery without compromising the hidden volume, and how the box behaves under cold-boot and DMA attacks when it's seized while still powered on. Those will get their own posts when the design is far enough along to defend in writing.

LocalGhost only works if the hardware can be carried, used, and occasionally surrendered without the surrender being total. If the design treats every encounter with authority as a failure state, the box becomes too dangerous to own, and the privacy benefits of running everything locally collapse the first time the box leaves your house.

We do not roll our own crypto. ghost.secd uses LUKS2 with detached headers, Argon2id for key derivation, AES-256-GCM for the encryption itself, and FIDO2 hardware keys for presence verification. Every primitive is established and audited and has been studied longer than I have been writing software. The contribution we are making with ghost.secd is architectural: combining tools that already exist into a system where compliance and surrender stop being the same thing.