Hey,

I'm currently using a linux system with 2 disk partitions - one is a boot partition, the other one is a rootfs partition that's LUKS-encrypted with LVM2 ontop. The current setup is programmed to display a password prompt on my screen at boot. It's a typical setup that a lot of distro installers offer today.

I've done some research, and found certain obscure options in cryptsetup and initramfs-tools packages that allow users to setup rootfs decryption in other special ways. I.e. the root partition will unlock once a USB key with proper keyfile on it is plugged into the laptop. But I was wondering...

Is there a solution for having a system with disk encryption (LUKS) try to decrypt itself at boot by attempting to connect and fetch credentials from a remote server in a secure manner (i.e. SSH or TLS)?

This would allow me to use my laptop as long as it is connected to my home LAN.

Thoughts?

You need to ask yourself what are you really trying to achieve and more importantly what are you trying to protect against? From your description, it sounds like you want to simplify the boot process by eliminating the need to enter a password when your connected to a trusted network. I would counter this by pointing out that security is a rigorous process that requires constant effort and convenience measures are often the downfall of security. My second thought is that perhaps encrypting the root file system (distribution binaries) isn't the best approach for you and perhaps you should consider encrypting only the home partition or even a 'private' folder instead that gets mounted automatically when you log on.

Unauthorized access and possible modification of the operating system files.

That's correct. This is for a case where a computer server needs to come back online on its own after an unexpected mains power loss.

I understand. I imagine an attacker could simply pose as my device and try to simulate the auth request to the server to download the decryption password. There's also an option to sniff the traffic or perform a MITM attack. This is why I mentioned credential-based connections i.e. SSH or TLS. There are more problems like physical access of the server/client, so yes it's a broad subject.

This does not prefent an attacker from comprimising the system by installing a backdoor since he has access to an unencrypted rootfs.


Thanks for the comments.

Keep in mind that in order to do this, they would require root privilege and if they have that you've effectively lost anyway. This is why it is important to use a strong password on the root account. Assuming that someone has this level of access to your system, I anticipate that it would be trivial for them to 'camp out' and wait for the system to be decrypted and then engage in their mischief. Instead of encrypting the root file system as a means to try and preemptively thwart a compromise of this nature, I would recommend a good HIDS (host based intrusion detection system) and set it up to give you instant alerts in the event that something changes in the system files. Again, if someone has root level access, it would be possible for them to bypass even a system like this, but the likelihood of you being alerted to any such attempt would be very high.

That or physical access.

Well, if they had root access they could simply disable it. Similar with physical access. I was going to use a setup to try and detect any intrusions. Upon detection an alarm would get signaled, and the device would power itself off to prevent access to encrypted files.

If you have that sort of security requirement, you probably want to start with disk drives that support physical encryption in hardware. This prevents drives that "walk out the door" (or that are picked-up in an airport lobby) from being usable. But, this requires a great deal more ... hardware encryption-key tokens and so on.

"Encrypting the filesystem" won't really help you to prevent critical system files from being modified. Putting them onto a read-only drive ... and I mean, flipping the write-protect switch on the device ... would. Presto, it is now impossible to modify that data: period, game-over, end-of-sentence.

Think in those terms . . .

I much prefer software encryption over hardware because there's no telling, if the HW encryption is backdoored or not. I.e. they may contain a special 'feature' that can be used by the vendor for 'data recovery' when their customers accidentally lose their passwords. And as far as the read-only media goes, it's an interesting concept. Although it's always a bit of a tradeoff, tbh. While it would definitely protect system files from modification, it would also prevent critical updates from being applied.

Just out of curiosity, do you perhaps know of a modern read-only data storage device (please don't mention CD's or DVD's.)? NAND flash is R/W, Hard Disks are R/W, SSD is R/W, EEPROM is R/W. Even BIOS is supposed to be ROM, but we all know that isn't the case.