Deadbolt

What it does

The problem. A NAS on your network will hand its files to anything that presents the right credentials — malware included. Credentials can be stolen, sessions can be hijacked, and nothing about a network protocol proves a person is present and consenting. The same gap exists one layer up: if you distribute demo builds of your software, a public download link gives you no idea who is taking what.

The solution. Put the data behind hardware. Deadbolt keeps sensitive files in a LUKS2-encrypted container whose key is derived from a YubiKey challenge–response that refuses to answer until the key's touch sensor is physically pressed. A small daemon on the NAS owns the state machine; a desktop console on my PC surfaces every unlock request the moment it arrives — with the requester's name and source address — and makes the "touch now" window unmissable. The same request → notify → approve pattern extends to my website: visitors ask for a demo build by name, my phone pings, and nothing downloads until I approve it.

The value. Data at rest is ciphertext until a human touches hardware. Every release of data — a file over SMB, a demo build over HTTPS — is a deliberate, attributable, logged act. A leaked token can only ask; it shows up in the audit trail either way.

stack: Python (stdlib-only daemon) · PySide6 console · LUKS2 + dm-crypt · YubiKey HMAC-SHA1 challenge–response · Samba · Cloudflare Pages Functions + KV + R2 · ntfy

See it in action

The console during a live unlock — captured against the daemon's mock backend, which exists precisely so the whole UX can be exercised without hardware.

screenshot

screenshot

screenshot

screenshot

From idea to a live vault

Built and deployed onto a stock UGREEN DXP2800 NAS — no OS wipe, no vendor encryption, everything brought along.

• the constraint
  The NAS OS has no native encryption and must not be re-imaged

  UGOS is Debian underneath, but its package state is broken upstream and firmware updates can revert changes. Deadbolt ships as a single container file inside a normal share, a stdlib-only daemon, and a systemd unit — nothing invasive, everything re-installable.

• the design
  One daemon, two backends — build the UX before touching hardware

  A mock backend simulates the whole flow on the PC, so the console, state machine, tray alerts and audit trail were finished and demoable before the first byte was encrypted. The real backend swaps in LUKS2 + a touch-required YubiKey slot behind the same API.

• deploy day
  Live on the NAS: preflight, vault, service, share

  Kernel dm-crypt verified, dependencies installed against a broken apt by computing the exact package closure, a 500 GB vault created with a touch-derived key plus an offline recovery passphrase, and the decrypted mount wired to a normal SMB share.

• the find
  The first real-world seal exposed a false-LOCKED bug — live

  With a Windows Explorer window holding the share open, the unmount failed quietly and the daemon still reported the vault sealed. Exactly the lie the project exists to prevent — caught on the first live run, because the verification ran against the real thing.

• same day
  Fixed, hardened, and adversarially re-verified

  The seal path now force-closes open SMB handles, verifies against the kernel's own mount table, and refuses to claim LOCKED without proof. Three independent review lenses went after the fix before it shipped; the failure now reports honestly and retries.

• one layer up
  The same approval pattern, extended to this website

  Demo-build requests go through Cloudflare Pages Functions with KV state and private R2 storage: a visitor asks by name, my phone pings, and the download only exists after I approve it — time-boxed and download-capped.

Proof, not promises

Every claim above was exercised against the real system, not a slide.

Engineering notes

The decisions that made it trustworthy.

• The daemon never trusts a subprocess. Seal = force-close SMB handles, unmount, verify against /proc/mounts, close the crypto mapper, verify again. Any step failing keeps the honest state and surfaces the error to the console.
• A leaked API token is a doorbell, not a key. It can never open the vault — the most it can do is raise a request (which lights up the console with its source address) or seal the vault early. Opening requires a finger on hardware I own.
• Recovery is mandatory. A second LUKS keyslot holds an offline recovery passphrase, generated on the NAS and written down — never stored digitally, never in a transcript.
• While sealed, the mount point is immutable. Nothing can write plaintext into the empty directory that would be silently shadowed on the next unlock.
• The web gate assumes abuse. Turnstile, per-IP and global rate caps, notification caps, token-gated streaming from private R2 — and approvals expire on time and on use.
• Everything is attributable. The daemon appends every event to its audit log; the web gate keeps each request's full record — who asked, from where, the decision, the download count — for 30 days.

The first live seal attempt caught a real bug — a vault that claimed to be sealed while it wasn't — because verification ran against the real system. That's the point of building this way: the proof and the product are the same artifact.