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. This feature is already integrated into Agama on ALP and we plan to merge it into yast-installation (*1). For now, if you're interested, just type a few commands to enable it. The hard requirements are LUKS2 partition(s), UEFI with Secure Boot enabled, and, of course, TPM 2.0. LUKS2 support in yast-installation is still experimental and needs a few extra steps. You could also choose to convert the existing LUKS1 partition to a LUKS2 one. The LUKS2 setup is addressed in the following link: https://en.opensuse.org/SDB:Encrypted_root_file_system#Setup_LUKS2_partition... First of all, please update all packages, especially shim and grub2. The key package is fde-tools. Currently, there is a minor issue that the TCTI for native devices may not be installed, and the fix is on the way(*2). So, please install fde-tools along with libtss2-tcti-device0 for the time being. # zypper in fde-tools libtss2-tcti-device0 After installing fde-tools, you can test the TPM 2.0 support with # fdectl tpm-present If there is no error, it's time to seal a new random key for your root partition: # fdectl regenerate-key This command will request the passphrase of the root partition to enroll a new random key, seal the random key with TPM, and then update the grub configuration. Next, reboot your system. If everything is setup correctly, the system will boot without showing the passphrase prompt. One thing to be noted is that after a boot component upgrade, such as shim, grub2, or UEFI firmware, the signature in the sealed key may become invalid, and then you have to run the following command to update the signature. # fdectl tpm-authorize We are still working on a solution to update the signature automatically after shim and grub2 update to reduce such hassles. By default, 'fdectl' only manages the keyslots of the root partition. To extend the keyslot management to other partitions such as swap, please check https://en.opensuse.org/SDB:Encrypted_root_file_system#Additional_steps_for_... A complete document is available here: https://en.opensuse.org/SDB:Encrypted_root_file_system#Unattended_boot_with_... In case you encounter any issue, feel free to file a bug and assign it to bootloader-maintainers@suse.de Cheers, Gary Lin (*1) https://github.com/yast/yast-installation/issues/1088 (*2) https://build.opensuse.org/request/show/1100949
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?
On Sunday 2023-07-30 19: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?
One benevolent interpretations to the outrageous proposal is that there is a password to be entered at firmware initialization time to unlock a keystore in the TPM. But I would not trust any horses to firmware as long as it ain't fully open and libre software.
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 Monday, 31 July 2023 01:59:09 +08 Martin Winter wrote:
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?
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. Although it makes it slightly less secure versus in-person unlocking, any thieves interested in the data would need to steal the entire server rack, which is quite a noticeable activity.
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
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!
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 Mon, Jul 31, 2023 at 8:57 AM Martin Winter <me@letsfindaway.de> 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...
- 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 11:33:38AM +0300, Andrei Borzenkov wrote:
On Mon, Jul 31, 2023 at 8:57 AM Martin Winter <me@letsfindaway.de> 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 1, 2023 at 11:48 AM Gary Lin <glin@suse.com> 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 <me@letsfindaway.de> 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!
On Tue, Aug 01, 2023 at 12:15:41PM +0300, Andrei Borzenkov wrote:
On Tue, Aug 1, 2023 at 11:48 AM Gary Lin <glin@suse.com> 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 <me@letsfindaway.de> 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 2023-07-30 20:39:14 Lew Wolfgang wrote:
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? If you use the same LUKS passphrase for the encrypted partitions, grub will 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
-- Platform: Linux Distribution: openSUSE Leap 15.4 (x86_64)
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
Am 31.07.23 um 03:39 schrieb Lew Wolfgang:
I wonder if swap and /tmp could be encrypted this way too, it might be fun to fiddle with it someday?
If you don't use hibernation, you can encrypt swap with a fresh random key on every boot. In /etc/crypttab you might have encrypted_swap /dev/<swap-device> /dev/urandom swap and in /etc/fstab: /dev/mapper/encrypted_swap swap swap defaults 0 0 While /tmp can simply be tmpfs, /var/tmp is tricky, or generally /var. (There is probably more interesting data in /var/log, especially the journal.) Best regards, Aaron
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 7/30/23 13: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?
In guest encrypted cloud images is one use case. Later, Robert 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?
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX rjschwei@suse.com IRC: robjo
Hi Gray Lin and Factory/Tumbleweed team, Am Donnerstag, 27. Juli 2023, 09:54:45 CEST schrieb Gary Lin via openSUSE Factory:
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. This feature is already integrated into Agama on ALP and we plan to merge it into yast-installation (*1). For now, if you're interested, just type a few commands to enable it.
The hard requirements are LUKS2 partition(s), UEFI with Secure Boot enabled, and, of course, TPM 2.0. LUKS2 support in yast-installation is still experimental and needs a few extra steps. You could also choose to convert the existing LUKS1 partition to a LUKS2 one. The LUKS2 setup is addressed in the following link:
https://en.opensuse.org/SDB:Encrypted_root_file_system#Setup_LUKS2_partition s (*1) https://github.com/yast/yast-installation/issues/1088
Is there a plane, till when the TPM 2.0 and LUKS2 support will be integrated in the Tumbleweed installation media? Where I can find the Agama on ALP installation media (I only find the qemu/kvm image). Regards Ulf
On Thu, Aug 10, 2023 at 11:39:20PM +0200, Ulf wrote:
Hi Gray Lin and Factory/Tumbleweed team,
Hi Ulf,
Am Donnerstag, 27. Juli 2023, 09:54:45 CEST schrieb Gary Lin via openSUSE Factory:
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. This feature is already integrated into Agama on ALP and we plan to merge it into yast-installation (*1). For now, if you're interested, just type a few commands to enable it.
The hard requirements are LUKS2 partition(s), UEFI with Secure Boot enabled, and, of course, TPM 2.0. LUKS2 support in yast-installation is still experimental and needs a few extra steps. You could also choose to convert the existing LUKS1 partition to a LUKS2 one. The LUKS2 setup is addressed in the following link:
https://en.opensuse.org/SDB:Encrypted_root_file_system#Setup_LUKS2_partition s (*1) https://github.com/yast/yast-installation/issues/1088
Is there a plane, till when the TPM 2.0 and LUKS2 support will be integrated in the Tumbleweed installation media?
There is no timetable yet.
Where I can find the Agama on ALP installation media (I only find the qemu/kvm image).
I usually download the latest Agama from the following link: https://download.opensuse.org/repositories/YaST:/Head:/Agama/images/iso/ Note: It's for testing so bugs are expected. Cheers, Gary Lin
Great work!! I'd been hoping for this feature for a long time to use for a homeserver. I've already set it up. Thank you! 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. Thanks!
On Wed, Aug 23, 2023 at 05:59:58PM -0000, Tim Edwards via openSUSE Factory wrote:
Great work!! I'd been hoping for this feature for a long time to use for a homeserver. I've already set it up. Thank you! Thanks for trying the feature :)
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. Gary Lin
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, 2023 at 09:01:12AM +0200, Felix Niederwanger wrote:
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.
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. Gary Lin
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)
On Thu, Aug 24, 2023 at 11:06 AM Thorsten Kukuk <kukuk@suse.de> 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.
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)
Hi, Am Donnerstag, 24. August 2023, 10:35:16 CEST schrieb Andrei Borzenkov:
On Thu, Aug 24, 2023 at 11:06 AM Thorsten Kukuk <kukuk@suse.de> 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 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.
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 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!
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
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? Ulf
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
participants (17)
-
Aaron Puchert -
Andrei Borzenkov -
Chan Ju Ping -
David B -
Fabian Vogt -
Felix Niederwanger -
Gary Lin -
J Leslie Turriff -
Jan Engelhardt -
Larry Len Rainey -
Lew Wolfgang -
Marcus Meissner -
Martin Winter -
Robert Schweikert -
Thorsten Kukuk -
Tim Edwards -
Ulf