[Discuss] Beginnings of a how-to -- full-disk encryption on a small LAN

[Rich Braun]

Last week I posed the question of how to set up full-disk encryption for a
small LAN, with central key management (for forgetful people like myself).
Today's marketplace faces a chicken-and-egg problem: users think encryption is
difficult so they've pretty much decided not to use it, vendors don't bother
making easy-to-use products, and not much has changed except the names of the
few brave vendors since Symantec came out with some PC-based thing whose name
I've forgotten back in, oh, the '80s. Meanwhile Intel quietly put
munitions-grade encryption capability into every chip made since about 2007:
few of us use it and not many more are even aware of it.

I've dreamed up a full-LAN encryption solution based on open-source tools, one
that should be easy to implement. There are some fairly inexpensive commercial
versions of this out there, but aside from Winmagic, they don't support Linux
clients (Symantec seems to have quietly dropped Linux support from their
Endpoint Encryption system), and they all seem to want you to run a hefty
Server 2008 or later system with SQL Server--a bit more complicated than I
want to deal with at cold-reboot time.

So this solution assumes the following:

* Your file/database/virtualization-host servers are running Linux

* Clients are either Windows or Linux (alas, Mac OS X clients aren't supported
by dm-crypt/LUKS)

* Key server is either a small device like a Raspberry Pi that you can take
offsite between file-server reboots, or is installed on a well-protected
server at a separate location (could be on a cloud service like Dropbox or
AWS)

* Connectivity between client and key server should require no more complexity
than ssh and an off-the-shelf multi-platform client (sshfs is selected)

* Your CPU chips have aes-ni extension so encryption performance is not
substantially less than rotating-media I/O throughput.

The goals I'm seeking are:

* Unattended boot of each LAN-connected machine so long as key-server service
is authorized

* Security is (more or less) set-and-forget; like backups, this is not
something you want in the way of your productivity (or that of fellow users of
the LAN/wifi network): inconvenient security quickly becomes bypassed
security, and thus no security.

The threat model I'm addressing is limited to:

* Encryption-at-rest; a theft or seizure of systems that the intruder keeps
running with a battery (such as might be done by police), or a breach of your
network will allow access to unencrypted data.

* I don't address the need for plausible-deniability that any encrypted data
exists: presence of randomized data on your storage media, under certain
conditions, could lead to coercive efforts to give up your keys (which can be
mitigated but not eliminated by routinely keeping key server offline and under
separate control). In USA the need for this is much less than in some other
locales.

* Root and swap filesystems aren't part of my encryption scheme because I
don't store any user data under root, and given the scenario this is
protecting against (simple theft of hardware intended for sale, not a
concerted attack seeking specific data), swap is assumed not to contain data
of interest upon casual perusal of your media. Also, distro vendors provide
scripts for accomplishing this at boot time.

OK so here's the basic outline of the setup:

* Choose a machine to act as your keyserver. It should have a fixed IP
address, be physically small, and more secure than your other machines -- keep
it at another location, or as one person here suggested, put it in a welded
dog cage of heavy steel and pad-lock the sucker to an immovable part of your
structure inside a locked room. If it's off-site, you'd better have a
really-reliable network line to it.

* Create a small (<10Mb) LUKS-encrypted file on the keyserver machine, and if
locally-hosted (I recommend an SDcard or USB flash drive) mount it under the
loopback device (to a particular directly, /secure-keys or some other name of
your choice).

* For each volume you want to protect on your server(s), create a
LUKS-encrypted volume or partition, and create a 4096-byte keyfile.  Transfer
existing data to the encrypted partition.  Put the keyfile on your keyserver's
/secure-keys filesystem: a separate keyfile per volume, in a directory named
for the client.

* LUKS supports multiple pass-phrases via luksAddKey.  Create a second
back-door pass phrase that you can use to get in the event your key-server
content is lost.  (I won't tell you how to set up your back door, just make
sure you have a second way in and either memorize it or save its keys
somewhere else. Human memory fades quickly for any pass-phrase that's not used
more than several times a year, and it's hard to create a high-entropy
pass-phrase, so be careful.)

* Add a script on each server which uses sshfs to mount the keyserver's
/secure-keys directory. Set permissions of the ssh user as appropriate
(read-only of the files for that particular client); ssh natively supports
whatever access controls you want.

* Use your distro's cryptsetup mount capability (systemd in modern Linux
distros) to reference the sshfs-mounted keyfile (usually through a config file
/etc/crypttab).

* Once all your machines have completed their mounts, go to your keyserver,
dismount the /secure-keys directory and invoke 'cryptsetup remove' to delete
keys from kernel memory.  (You can accomplish something similar at a cloud
service like AWS/Dropbox by revoking access permissions, however you'll either
have to store keys in clear-text or use a decryption proxy of some sort.
That's why for now I'm just planning to use a Raspberry Pi or laptop that I
can carry with me.)

* There may be some intermittent-use machines such as laptops which require
24x7 access to the keyserver. I recommend putting keyfiles for their encrypted
volumes in a separate storage volume on the keyserver; that way you can
minimize attack surface for your core servers.

* Make two copies of the secure-keys encrypted volume: one is a physical flash
drive that goes into a bank vault, and the other can be either a flash drive
or a network download with access only by a trusted associate or family
member.  Don't forget to update the backups if you add or revoke keys.

---

I was discussing a related topic with a coworker today. He shared with me the
news that he'd recently lost some important personal work into a disk
encryption system he'd created with a lot more layers of security than this,
yet his use-case and threat model are very similar to what I've summarized
above. He locked himself out in the obvious way, by forgetting the password:
created 128-byte random pass phrases which he mistakenly thought he'd saved. 
Now he's toying with the idea of buying high-end GPUs to run an
encryption-cracking tool.  So: do something simple like the above, don't put
yourself at risk of creating a write-only volume.

The same key-server could work with Mac OS X volumes, I just don't know if
there's a way to have FileVault read a keyfile from a mounted directory (sshfs
is available for the Mac, so that's all you'd need).

Last week's discussion centered on the "why would you want this" rather than
"assuming you want this, how would you do it?" I'm interested in constructive
criticism of this approach: fire away.

-rich