Encrypted at rest, unattended at home: building network disk unlock with Nuklatch

Encrypted computers have an awkward habit: the reboot happens when nobody is there to type the passphrase. A power cut or routine update can leave a perfectly healthy home server waiting at its unlock prompt.

I want unattended reboots at home without making a stolen, powered-off computer equally easy to start elsewhere. That is the problem behind Nuklatch, my network-unlock appliance project. The client work now has useful VM test evidence, alongside some limits that matter just as much as the successful boots.

The useful idea: leave one requirement at home

Network-bound disk unlock makes access to a particular service part of the automatic unlock process. At home, the machine can contact it and continue booting. Take the powered-off machine away, without that service, and the automatic route no longer works.

This protects a specific situation. It does not protect files already accessible on a running, compromised computer. Nor does “on my network” automatically mean “trusted”: the real requirement is access to the enrolled provider and its cryptographic capability.

Physical separation is therefore part of the design. Keeping the unlock appliance somewhere separate from the computer is useful. Putting both in the same easily carried box undermines that benefit.

Linux: Tang and Clevis already do the important work

On Linux, Tang supplies the network-side operation and Clevis integrates policy-based unlocking with LUKS. Tang is not a vault containing a list of clients’ plaintext disk keys: the protocol lets a client recover its bound secret without revealing that secret to Tang.

“Could a Raspberry Pi do this?” Yes: a Pi running an appropriate Linux installation can host Tang. Existing Tang and Clevis documentation is a good starting point for that route. Network-bound encryption is established technology; my work is about making a dedicated appliance and careful client setup practical.

The simplest Linux policy requires Tang for automatic unlock. Its limit is explicit: if someone steals both the disk and the usable Tang appliance, assume they can unlock that disk, including on another computer. Network-only binding does not authenticate the boot software or require the original TPM.

TPM AND network needs a protected boot path

A stronger automatic route requires both the original TPM under an approved policy and the network provider. Adding a TPM-only slot and a Tang-only slot does not achieve this: either slot would independently open the volume. Both requirements must protect the same automatic credential.

Boot integrity matters too. The kernel, early boot environment and policy must be protected against substitution; merely having a TPM is insufficient. My protected-root work uses signed boot images and TPM signed policies, with signing keys kept off the client. The systemd documentation explains TPM enrollment and signed PCR policies; those mechanisms require deliberate policy and version choices.

The current Debian 13 workflow starts with an already trusted signed manual-recovery boot setup. It is a component preview, not a turnkey conversion from ordinary GRUB, and not a claim of universal BitLocker parity. A successful protected boot also does not prove that every other unlock slot on the disk has been hardened.

Windows uses a different protocol

Windows BitLocker Network Unlock combines a TPM-held component with a network component. It requires eligible firmware with UEFI DHCP support and wired preboot networking. When the provider is unavailable, an existing TPM+PIN protector can supply the normal attended route. Microsoft documents the mechanism and its domain/WDS deployment model.

My Windows helper tests a separate, experimental local-policy workgroup path on an already encrypted OS drive. It uses native Windows PowerShell 5.1, stages a public provider certificate, and preserves existing TPM+PIN and recovery protectors. Its eligibility gate accepts selected Enterprise or Education builds; ordinary BitLocker availability on other editions does not establish eligibility for this helper. Microsoft’s BitLocker overview covers edition and licensing requirements. These tests do not establish Microsoft support or certification for the workgroup path.

What I actually tested

These are disposable VM results using virtual TPMs and isolated software providers. A configuration check is useful evidence, but an actual reboot and recovery attempt answer different questions.

The basic Linux root profiles use wired DHCP: Debian’s tested layout has one linear root LV inside LUKS; Ubuntu’s has ext4 directly inside LUKS. Wi-Fi, static addressing and other storage/network layouts need separate work. These results do not qualify physical hardware or appliance firmware. First-update evidence does not establish arbitrary chained upgrades.

Recovery is part of the feature

An independent LUKS passphrase or BitLocker recovery password remains a valid way into the disk. That is intentional. It must be strong, available to its owner, and tested with the provider unavailable. Losing an appliance should not mean losing the data.

The helpers work on existing encrypted volumes. They do not format disks or replace independent recovery. Their changes are explicit, recorded by ownership, and removable without deleting unrelated slots or protectors. Linux root work also needs backups, trusted recovery media and a complete retained kernel. Offline recovery sometimes took minutes in the VM fixtures; an immediate response is not promised.

For me, a successful demonstration includes the unglamorous ending: disconnect the provider, recover independently, roll back an update, interrupt removal, resume it, and boot again after the automatic protector is gone. That is the standard I want Nuklatch to meet before asking anyone to depend on it.