// encrypted storage

secure-luks-dropbox

Step-by-step schemes for building encrypted, remotely-unlockable storage systems on low-power hardware.

Wooden blocks spelling cybersec on a table

Photo by Markus Winkler on Unsplash

This project is a secure self-hosting system built around a Raspberry Pi 4 Model B and a Raspberry Pi Zero 2 W. The Pi 4B hosts the primary services from a remote location, such as a friend’s house, allowing those services to stay online independently of my home internet connection. Rather than encrypting the full operating system, the design uses an encrypted data partition that protects sensitive files while keeping the core system bootable. The Pi Zero 2W functions as a passive, offline unlock device that stores or provides the information needed to decrypt that partition. It does not actively connect to networks or the internet during normal operation, which is refreshing in an age where even refrigerators demand cloud accounts.

The goal of the project is to balance uptime, privacy, and practical trust boundaries using inexpensive hardware. By hosting the server elsewhere, the system gains resilience against outages at home. By keeping the unlock device offline and physically separate, the remote host cannot casually inspect the encrypted data. Wireless interception attacks are effectively removed from the threat model because the Pi Zero is not participating in live network communication. Access would instead require a physical man-in-the-middle attack: obtaining the device or storage media, examining the hardware, and understanding the custom setup well enough to replicate or subvert it. In short, it is an experiment in making self-hosted infrastructure harder to snoop on without turning it into an enterprise compliance nightmare built by committee.

// implemented
  • LUKS-encrypted partition on the vault

  • Split-key derivation — vault CPU serial + key CPU serial + passphrase; neither device alone unlocks

  • Physical presence requirement — vault only unlocks when key device is reachable over the hotspot

  • WPA2/RSN encrypted private Wi-Fi hotspot (ciphernet) as the unlock channel

  • Network isolation during unlock — vault joins hotspot, unlocks, then switches to home Wi-Fi

  • UFW firewall on both devices — default deny, SSH rate-limited

  • Fail2Ban SSH brute-force protection on both devices

  • SSH key-only auth for the unlocker service account — password auth disabled post-setup

  • Scoped sudoers rule — only specific unlock commands run without password

  • Tailscale VPN for remote access

  • Auto-lock on shutdown via luks-halt.service systemd unit

  • Auto-unlock on boot — only succeeds if key device is reachable on the private hotspot

// to-do
  • bluetooth
  • wireguard
  • cipher for service passphrase
  • TOTP