On 30.07.2023 20:59, Martin Winter wrote:

Gary Lin wrote:

...

Hi, I'm pleased to introduce a new feature for openSUSE Tumbleweed: disk auto-unlocking with TPM 2.0. In short, it boots the encrypted root without asking for a passphrase.

What is the actual use case for that? I'm encrypting my disk to protect it in case the Notebook gets stolen or otherwise lost. When it is auto-unlocked, everybody with access to my computer can read the data.

Or am I missing something? Is there another protection mechanism before the disk is unlocked?

If implemented properly, unlocking is tied to the measured boot sequence. If you boot with different bootloader (e.g. from USB stick), different kernel, different initrd or even try to pass different parameters to kernel unlocking should fail. If system is booted using original bootloader/kernel, then presumably your system requires valid login before someone can access your data. Are you using automatic login? Data at rest encryption remains valid use case as well. For a system that never leaves your basement theft may not be the highest priority, but you may care that your RMA HDD is not readable.

On 7/30/23 17:39, Chan Ju Ping 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 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

On Mon, Jul 31, 2023 at 05:56:44AM -0000, 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. - 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!

Nice summary :) Maybe I should add a few possible use cases to the wiki page so that the reader will have some basic ideas. Gary Lin

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-... 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!

On Tue, Aug 01, 2023 at 12:15:41PM +0300, Andrei Borzenkov wrote:

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.

Thanks for the suggestion. Just add a few more lines to the wiki page :) Gary Lin

...

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!

On 7/31/23 00:24, J Leslie Turriff 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? If you use the same LUKS passphrase for the encrypted partitions, grub will

On 2023-07-30 20:39:14 Lew Wolfgang wrote: try the first one entered on each of them. I use this method to automagically decrypt my /var and /tmp partitions at bootup; I only need to enter the passphrase once. (Encrypted password partitions, of course, should have separate passphrases.) You can do the same with the swap partitions, or tell the OS to encrypt your swap partitions with a key generated by /dev/random.

In fact, rereading the announcement in https://en.opensuse.org/SDB:Encrypted_root_file_system#Setup_LUKS2_partition..., I see that it is capable of handling encrypted swap and other encrypted partitions as well (as long as their keys are all the same), so yes, you can already do this (once the new features are installed in your system).

Leslie

...

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 the pointers, Leslie.  But grub needs to get the secret from somewhere, either TPM or to prompt for it.  That's the problem with remotely managed systems without TPM, grub can't get the secret.

If grub could start the network stack and kick off sshd to prompt for a remotely supplied secret I'd be happy.  But I don't think it can do that without knowledge of encrypted network configuration.  Maybe it could get the secret to boot up the core operating system, including /tmp and swap, from TPM, then the administrator could login via ssh and supply the secret to decrypt the rest of the system and start the required daemons?  I'd rather not let the system boot up completely by itself, I think it's a security threat, plus the servers don't have TPM anyway. Regards, Lew

At work we rent dedicated servers and we use Dropbear which is basically a lightweight SSH server to be able to decrypt them remotely. Basically when a server boots it first boots into Dropbear, you SSH into it with your SSH key, enter a command with the LUKS passphrase, the partitions are unlocked and the regular OS continues to boot.

On 8/24/23 04:02, Gary Lin via openSUSE Factory wrote:

...

I do have a question for you: is there any plan to support TPM + a second factor, like a PIN, or HMAC challenge via a security key? Systemd-boot supports this, but I'm assuming the plumbing for something like this would need to be added to Grub.

FIDO2 maybe. It would take some effort to enable FIDO2 support in grub2 though.

LUKS supports unlocking with a Yubikey already, and this should in principle work with any FIDO2 key. See e.g. https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/ I've not done this yet myself, it's still on my bucket list. LUKS supports up to 8 key slots, so it should be possible to have TPM or Yubikey (plus PIN) or a predefined passphrase, in case the TPM breaks and you loose your Yubikey. Sadly only available in German, but an excellent talk on the possibilities of a Yubikey, was done by Florian Winkler at the "Chemnitzer Linux Tage" this year: https://media.ccc.de/v/clt23-148-yubikey-mehr-als-nur-fido2 Best, phoenix

On Thu, Aug 24, Gary Lin via openSUSE Factory wrote:

On Thu, Aug 24, 2023 at 09:01:12AM +0200, Felix Niederwanger wrote:

...

See e.g. https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/

In the article, the author is using 'systemd-cryptenroll' to secure the LUKS key with the FIDO2 token. Unfortunately, this only works in the userspace, i.e. after the linux kernel is loaded, and those FIDO2 tools are not accessible to grub2.

That's why we have: https://en.opensuse.org/Systemd-boot With the pre-built MicroOS image it should be easy to add FIDO2 support as described in that article. Disadvantage: only UEFI systems are supported. systemd-boot support is on the way into yast2-bootloader to make the setup easier, FIDO2 support is on the wishlist, help is always welcome :) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

Hi, Am Donnerstag, 24. August 2023, 10:35:16 CEST schrieb Andrei Borzenkov:

On Thu, Aug 24, 2023 at 11:06 AM Thorsten Kukuk wrote:

...

On Thu, Aug 24, Gary Lin via openSUSE Factory wrote:

...

On Thu, Aug 24, 2023 at 09:01:12AM +0200, Felix Niederwanger wrote:

...

See e.g. https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/

...

In the article, the author is using 'systemd-cryptenroll' to secure the LUKS key with the FIDO2 token. Unfortunately, this only works in the userspace, i.e. after the linux kernel is loaded, and those FIDO2 tools are not accessible to grub2.

That's why we have: https://en.opensuse.org/Systemd-boot

I am not sure I understand how it is related. systemd-boot is not user space and does not support unlocking because it does not need it - it never reads encrypted content. Nothing prevents configuring grub to use kernel/initrd from ESP instead of reading it from the encrypted container.

This page is also about the plumbing to make this possible, especially with btrfs snapshots. You can then also use GRUB instead of systemd-boot, even as a drop-in replacement with the bls/bli integration in GRUB. In fact, this is one of the options to support legacy boot in the future. Cheers, Fabian

...

With the pre-built MicroOS image it should be easy to add FIDO2 support as described in that article. Disadvantage: only UEFI systems are supported.

On legacy BIOS it would be possible to dedicate an unencrypted filesystem to store kernel/initrd similar to ESP if grub is used.

...

systemd-boot support is on the way into yast2-bootloader to make the setup easier, FIDO2 support is on the wishlist, help is always welcome :)

...

Thorsten

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

On Tue, Sep 12, 2023 at 12:16:20PM +0800, Chan Ju Ping wrote:

On Thursday, 27 July 2023 15:54:45 +08 Gary Lin via openSUSE Factory wrote:

...

# fdectl tpm-authorize

We are still working on a solution to update the signature automatically after shim and grub2 update to reduce such hassles.

Admittedly, I have forgotten to run this enough times to ask what are the current methods that are being tested to automate running `fdectl tpm- authorize` after running zypper dup? I would love to give it a shot.

I have a POC fde-tools(*) to add the RPM macros and helper for shim and grub2 to update the signature with the post/posttrans scripts. So far, the helper script works as expected in my testing VM. Will update the status here once it's ready for openSUSE:Factory :) Gary Lin (*) https://github.com/lcp/fde-tools/commits/tpm-auto-update

On Thu, Oct 05, 2023 at 07:18:52PM +0800, Chan Ju Ping wrote:

On Tuesday, 12 September 2023 14:33:15 +08 Gary Lin via openSUSE Factory wrote:

...

I have a POC fde-tools(*) to add the RPM macros and helper for shim and grub2 to update the signature with the post/posttrans scripts. So far, the helper script works as expected in my testing VM. Will update the status here once it's ready for openSUSE:Factory :)

Gary Lin

(*) https://github.com/lcp/fde-tools/commits/tpm-auto-update

I noticed fde-tpm-helper-rpm-macros was part of the new update and happy to report it works! I did nothing but run zypper dup as usual.

Thanks for the excellent job to get this working Gary! I'm glad it works for you :)

BTW, the change for shim is still on the way due to the blocking shim signature request, and it may take a while. Gary Lin

On Mon, Oct 09, 2023 at 09:42:11PM +0200, Ulf wrote:

Am Freitag, 6. Oktober 2023, 03:58:19 CEST schrieb Gary Lin via openSUSE Factory:

...

BTW, the change for shim is still on the way due to the blocking shim signature request, and it may take a while.

Where need to signature shim? Microsoft or an other company / government office?

There is a opensource review board for shim, after their approvals Microsoft signs the shim with its third party CA. Ciao, Marcus