Re: Disk auto-unlocking with TPM 2.0

On Tue, Aug 1, 2023 at 11:48 AM Gary Lin wrote:

On Tue, Aug 01, 2023 at 11:33:38AM +0300, Andrei Borzenkov wrote:

...

On Mon, Jul 31, 2023 at 8:57 AM Martin Winter wrote:

...

Lew Wolfgang wrote:

...

...

Or am I missing something? Is there another protection mechanism before the disk is unlocked? I help run a few community servers for our local makerspace here, and auto- unlocking of encrypted drives using TPM 2.0 would allow me to remotely manage an encrypted filesystem setup. Since the normal procedure would be for me to ask someone on the other side of the island to help key in the passphrase every time I need to reboot the server. I set up a few remotely managed servers by moving all of the important data to LUKS encrypted filesystems. These filesystems aren't in /etc/fstab so they don't get mounted after a reboot. Once rebooted I remotely SSH in and run a script that mounts the encrypted filesystem that prompts for the password. It then starts the appropriate daemons (Postgresql, etc) and everything is fine. I know there's a possibility of data leakage via /tmp and swap, but I think the risk is minimal and the servers are in a protected space anyway. I wonder if swap and /tmp could be encrypted

On 7/30/23 17:39, Chan Ju Ping wrote: this way too, it might be fun to fiddle with it someday? So the basic idea is to set up a server so that it partially boots, but boots far enough to set up the network and start the SSH daemon. Then, log in remotely to finish the rest of the boot after entering the LUKS password. Could something like this be added to the Leap install process to make it easier to set up? Regards, Lew

Thanks for all your answers. This now makes it much clearer to me. My takeaway is:

- Encryption with auto-unlocking still protects against booting another OS or taking the disk device to another computer to read the data.

Just to avoid confusion.

Unlocking with fde-tools is limited to grub2 only (unless something has changed recently). Unlocking happens *very* early, before grub2 even started to process its configuration file. So at this point at most the boot device can be verified. The unlocking of root after kernel is loaded is implemented by passing *existing* key (recovered from TPM) from grub2 to initrd and so is not protected by boot measurements at all.

Unless editing of grub2 boot menu, escaping into grub2 CLI etc are prohibited, nothing prevents an attacker from booting into init=/bin/sh and taking over your unlocked root.

To prevent it one must use systemd-cryptsetup tied to TPM to unlock root, not key forwarded from grub2.

https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/L...

Michael has added the patch to discard the key if grub2 enters the interactive mode:

https://build.opensuse.org/package/view_file/Base:System/grub2/0002-discard-...

Thanks. That probably needs some mention in documentation too :) As well as what exactly is measured when using this method.

Cheers,

Gary Lin

...

...

- It is not a good idea to combine it with auto-login. - Remote servers are a very good use case, but even for a local server it makes things easier (e.g. automatic reboot after power outage). - And more people have more ideas to use it...

So from my side the question is answered and I have learned something again. Thanks!