Unattended Disk Encryption

Question

I have been asked to implement disk encryption on a machine that needs to be able to run unattended. The machine has two disks. The first disk has a boot partition and an OS partition, while the second disk only has one partition and is used for storage for an application. The goal is to protect the data in the storage partition from being read, should someone decide to steal the disks.

My plan is to use Linux's dm-crypt module to encrypt the OS and storage partitions. I figure that it makes the most sense to use a key for each encrypted partition. However, I'm struggling to figure out the best way to store each key.

For the key for the storage partition, it seems safe to store it in the OS partition. However, it seems that the only option for storing the key for the OS partition is to keep it in the boot partition. It would be really nice if there were some kind of TPM or other storage local to the machine, but unfortunately there is no other storage available.

Therefore, since I'll need to use an initramfs to decrypt the OS disk anyway, I figured I would store the key for the OS partition in the initramfs, which would get embedded into the kernel, which would be stored in the boot partition. This would prevent the data from being read from some random person who happens to feel like stealing some disks. However, I realize that this isn't ideal, because a sufficiently knowledgeable attacker would be able to extract the initramfs from the kernel, and extract the key from the initramfs image.

The way I see it, no matter how complex a scheme I can come up with, I need to be able to tell the machine how to carry out the decryption routine; an attacker needs only to read the decryption routine to determine how to decrypt the system.

With the storage available, is there a better way that I can encrypt the partitions that will be more resilient against an attacker who has possession of the disks?

Answer 1

This is the endless problem of: I know how to securely encrypt this, but where should I securely store the key?. Unfortunately, there is no nice solution, because if you want to allow an unattended reboot, the key must be accessible from the machine. That means that you can only rely on a something you have.

Said differently, if only the storage disk is stolen, your system will be safe, but if both disk are, the attacker will have all he needs to decrypt everything.

The best technical solution I can imagine, would be to use a HSM to decrypt the keys. But it only adds security if you can hope that the HSM will not be stolen with the disks. That means that the only efficient way will be to improve the physical security of the data center.

Answer 2

There are actually quite a few solutions utilizing initramfs:

Mandos

This is the the Mandos system, which allows computers to have encrypted root file systems and at the same time be capable of remote and/or unattended reboots. The computers run a small client program in the initial RAM disk environment which will communicate with a server over a network. All network communication is encrypted using TLS. The clients are identified by the server using an OpenPGP key; each client has one unique to it. The server sends the clients an encrypted password. The encrypted password is decrypted by the clients using the same OpenPGP key, and the password is then used to unlock the root file system, whereupon the computers can continue booting normally.

https://wiki.recompile.se/wiki/Mandos#Documentation

https://man.cx/intro(8)

https://manpages.ubuntu.com/manpages/bionic/man8/intro.8mandos.html

Clevis and Tang

Clevis is a plugable framework for automated decryption. It can be used to provide automated decryption of data or even automated unlocking of LUKS volumes.

https://github.com/latchset/clevis

Tang is a server implementation which provides cryptographic binding services without the need for an escrow. Clevis has full support for Tang.

https://github.com/latchset/tang

Dropbear and BusyBox

Using this approach enables you to ssh into your machine and unlock LUKS by entering the passphrase. The installation procedure varies heavily depending on the version of your os and the packages used.

https://matt.ucc.asn.au/dropbear/dropbear.html

https://busybox.net/

Answer 3

"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." Kerckhoff's principle

Since there is already an excellent answer I will just point to it here: How valuable is secrecy of an algorithm?

Answer 4

As you have said, and others too, the issue is allowing the computer to reboot while storing its key somewhere readable.

You say the system will be unattended so I will assume headless / inaccessible. Have you considered using KVM over IP? Obviously with this there is a potential issue of an on-site attacker powering off the computer and positioning a sniffer between the keyboard ports before taking the disks. My only real idea here here is decent on site security.

Answer 5

The best solution is to use an HSM. But if you can't do that, then you need a key server. This key server should be another machine that's in the same secured network or accessed via a VPN if you're concerned about physical theft. The key server should hold the key, and be accessible only from local machines (i.e. it shouldn't be publicly exposed), at boot time, the machines should request the decryption key from the key server.

The key server could be your one weak point still, you'll still need to enter the decryption key to the key server itself manually when you need to restart the key server. As an alternative to manually inputting the key to the key server, you can have redundant key server clusters. When the key server reboots, it will fetch decryption keys from other peered key servers. This way, any single machine in your system can reboot unattended, though you need to take care that the key servers does not all reboot simultaneously.

You may want the key server to log any key accesses, and possibly send email alerts when keys are accessed from the key server.