LUKS2 encryption and TPM2 and FIDO authentication
Hi all, we had a look on how to move from LUKS v1 to LUKS v2 and also how to add functionality for alternative authentication mechanisms like TPM2 chips and FIDO devices during the boot process. While there is no Installer support yet and also no final decision on how it will be implemented in detail, we already wanted to share the current status and document what is achievable manually. For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2. The documentation should work on Tumbleweed and later on openSUSE Leap 15.4. We would really appreciate any feedback, thoughts, or reports in case you encounter any issues. Last but not least, a huge thanks to all involved for the feedback and support! Regards and thanks Benni -- Benjamin Brunner Engineering Manager System Boot and Init SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev
Am Donnerstag, 25. November 2021, 17:33:44 CET schrieb Benjamin Brunner:
Hi all,
we had a look on how to move from LUKS v1 to LUKS v2 and also how to add functionality for alternative authentication mechanisms like TPM2 chips and FIDO devices during the boot process.
While there is no Installer support yet and also no final decision on how it will be implemented in detail, we already wanted to share the current status and document what is achievable manually.
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
Last but not least, a huge thanks to all involved for the feedback and support!
Regards and thanks Benni
Excuse my first wrong reply :-( Am Donnerstag, 25. November 2021, 17:33:44 CET schrieb Benjamin Brunner:
we had a look on how to move from LUKS v1 to LUKS v2 and also how to add functionality for alternative authentication mechanisms like TPM2 chips and FIDO devices during the boot process.
Will be really interesting for me as user. On my Notebook, I've encryption installed (root, home and swap). But the problem is, that the key must be typed in at least two time (on grub and on boot up). Especially this on boot up is not well working with an German Keyboardlayout (so e.g. z <-> y are placed differently, and if it used in the keyboard you must use different letters on grub and boot) :-( That's not a big problem, if you aware about it, but it takes some time to find it out.
While there is no Installer support yet and also no final decision on how it will be implemented in detail, we already wanted to share the current status and document what is achievable manually.
That's nice. If you need a tester - please let me know.
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
OK, the main issue at my side is, that my system seams to be encrypted with LUKS1 - so I check, if I can update/upgrade it with low risk on my Notebook. But at first I will do a image of the main required partitions to be able easily to replace them.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
I let you know. If it works well on my notebook. Question, is there any easy possibility to check if the TPM2 is properly detected at Linux? I searched on it, but no finding till now.
Last but not least, a huge thanks to all involved for the feedback and support!
Many thanks for your work/proposal :-) Ulf
Moin, Am Sonntag, 28. November 2021, 12:20:44 CET schrieb Ulf Bartholom�us:
Excuse my first wrong reply :-(
Am Donnerstag, 25. November 2021, 17:33:44 CET schrieb Benjamin Brunner:
we had a look on how to move from LUKS v1 to LUKS v2 and also how to add functionality for alternative authentication mechanisms like TPM2 chips and FIDO devices during the boot process.
Will be really interesting for me as user. On my Notebook, I've encryption installed (root, home and swap). But the problem is, that the key must be typed in at least two time (on grub and on boot up). Especially this on boot up is not well working with an German Keyboardlayout (so e.g. z <-> y are placed differently, and if it used in the keyboard you must use different letters on grub and boot) :-(
That's not a big problem, if you aware about it, but it takes some time to find it out.
See https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_... to avoid the second entry. The first is still done with the wrong keyboard layout though.
While there is no Installer support yet and also no final decision on how it will be implemented in detail, we already wanted to share the current status and document what is achievable manually.
That's nice. If you need a tester - please let me know.
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
OK, the main issue at my side is, that my system seams to be encrypted with LUKS1 - so I check, if I can update/upgrade it with low risk on my Notebook. But at first I will do a image of the main required partitions to be able easily to replace them.
You can upgrade with fairly low risk (cryptsetup luksConvert works both ways), but the approach in the wiki article requires that the /boot partition is not encrypted, which is likely to require bigger changes on your system. It should also be noted that the /boot contents are not verified during boot (just the kernel through secure boot, if enabled), so it doesn't really provide any protection against physical access.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
I let you know. If it works well on my notebook. Question, is there any easy possibility to check if the TPM2 is properly detected at Linux? I searched on it, but no finding till now.
cat /sys/class/tpm/tpm0/tpm_version_major should print "2". Cheers, Fabian
Last but not least, a huge thanks to all involved for the feedback and support!
Many thanks for your work/proposal :-)
Ulf
Hallo, Am Sonntag, 28. November 2021, 13:05:25 CET schrieb Fabian Vogt:
See https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the _passphrase_twice to avoid the second entry. The first is still done with the wrong keyboard layout though.
OK, I fixed it # cryptsetup luksAddKey /dev/sda1 and add the password with the EN replacements ;-) With your description (I used the german one ;-) ) https://de.opensuse.org/SDB:Verschlüsseltes_root_file_system Was it really easy to add a key for each of my 3 encrypted partitions. (root, swap and home)
You can upgrade with fairly low risk (cryptsetup luksConvert works both ways), but the approach in the wiki article requires that the /boot partition is not encrypted, which is likely to require bigger changes on your system.
OK, read it now :-( The shift of the /boot in a dedicated filesystem was not a big deal.
It should also be noted that the /boot contents are not verified during boot (just the kernel through secure boot, if enabled), so it doesn't really provide any protection against physical access.
But this is not acceptable at all.
Question, is there any easy possibility to check if the TPM2 is properly detected at Linux? I searched on it, but no finding till now.
cat /sys/class/tpm/tpm0/tpm_version_major should print "2".
OK, is correct (sowing 2). But this don't help due to the security restriction :-( But it will be greate, if the automatic on the installation, will implement it automaticly (an also translate the keyboard key issues like z <-> y). The only missing feature, is now the possiblity to use an available security solution (TPM 2.0, included chip-card reader, Nitrokey 3A/3C NFC or similar else). Many Thanks :-) Ulf PS: Written from Fujitsu LifeBook U939X and openSUSE Tumbleweed https://lug-vs.org/lugvswiki/index.php?title=Hardware-Steckbriefe#Fujitsu_Li.... 28von_Ulf.29
Moin, Am Montag, 29. November 2021, 23:07:56 CET schrieb ub22@gmx.net:
Hallo,
Am Sonntag, 28. November 2021, 13:05:25 CET schrieb Fabian Vogt:
It should also be noted that the /boot contents are not verified during boot (just the kernel through secure boot, if enabled), so it doesn't really provide any protection against physical access.
But this is not acceptable at all.
Question, is there any easy possibility to check if the TPM2 is properly detected at Linux? I searched on it, but no finding till now.
cat /sys/class/tpm/tpm0/tpm_version_major should print "2".
OK, is correct (sowing 2). But this don't help due to the security restriction :-(
It's being worked on. https://www.youtube.com/watch?v=C58WLY7FvYk explains some potential approaches. Until seamless update handling is implemented, you can handle it manually by also sealing against PCRs 8 and 9, i.e. passing --tpm2-pcrs=7+8+9 (or even 0+1+2+4+5+7+8+9) to systemd-cryptenroll. That way the TPM will only unseal the secret if grub/kernel/initrd etc. match exactly. On updates, you'll have to enter the passphrase manually and run systemd-cryptenroll again. The other files in /boot (e.g. sysctl.conf) could still be modified without noticing, which can be avoided by placing necessary files on the EFI partition and leaving /boot encrypted. Cheers, Fabian
But it will be greate, if the automatic on the installation, will implement it automaticly (an also translate the keyboard key issues like z <-> y).
The only missing feature, is now the possiblity to use an available security solution (TPM 2.0, included chip-card reader, Nitrokey 3A/3C NFC or similar else).
Many Thanks :-) Ulf
PS: Written from Fujitsu LifeBook U939X and openSUSE Tumbleweed https://lug-vs.org/lugvswiki/index.php?title=Hardware-Steckbriefe#Fujitsu_Li.... 28von_Ulf.29
Moin :-) Am Mittwoch, 1. Dezember 2021, 08:29:08 CET schrieb Fabian Vogt:
Am Montag, 29. November 2021, 23:07:56 CET schrieb ub22@gmx.net:
OK, is correct (sowing 2). But this don't help due to the security restriction> :-(
It's being worked on. https://www.youtube.com/watch?v=C58WLY7FvYk explains some potential approaches.
Very interesting :-) many thanks
Until seamless update handling is implemented, you can handle it manually by also sealing against PCRs 8 and 9, i.e. passing --tpm2-pcrs=7+8+9 (or even 0+1+2+4+5+7+8+9) to systemd-cryptenroll. That way the TPM will only unseal the secret if grub/kernel/initrd etc. match exactly. On updates, you'll have to enter the passphrase manually and run systemd-cryptenroll again.
In the moment for my Notebook I dayly use, it is to risky for me ;-) So I stay with your first proposal | See https://en.opensuse.org/ SDB:Encrypted_root_file_system#Avoiding_to_type_the_passphrase_twice |to avoid the second entry. The first is still done with the wrong keyboard |layout though. Which I fixed with adding an additional passwort with QWERTY keybord ;-) Looking forward to be able to use the Nitrokey 3 to enable the grub2 passwort entrie.
The other files in /boot (e.g. sysctl.conf) could still be modified without noticing, which can be avoided by placing necessary files on the EFI partition and leaving /boot encrypted.
OK. Ulf
On Thu, 2021-11-25 at 17:33 +0100, Benjamin Brunner wrote:
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering. But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD? As long as the PCR values are unchanged and she has root rights on the booted devices, the person should be able to read the entire disk. What am I overlooking here? I guess it would work if the kernel, initrd, and kernel command line were also used for PCR-based protection but that's not the setup described in the Wiki, which uses only PCR 7. I believe the problem could be handled by locking the TPM2 with a password. AFAIK that's possible. But then this password would need to be entered during boot, and I'm unsure whether this is currently supported by the dracut / cryptsetup boot procedure. Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot. Martin
On Tue, Dec 21, Martin Wilck wrote:
On Thu, 2021-11-25 at 17:33 +0100, Benjamin Brunner wrote:
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering. But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD?
The USB stick or DVD will create other boot measurements and thus the TPM will not give out the hash to decrypt the harddisk.
As long as the PCR values are unchanged and she has root rights on the booted devices, the person should be able to read the entire disk. What am I overlooking here?
If the harddisk is encrypted, you cannot read the disk.
I guess it would work if the kernel, initrd, and kernel command line were also used for PCR-based protection but that's not the setup described in the Wiki, which uses only PCR 7.
They are used, even the firmware is normally used.
I believe the problem could be handled by locking the TPM2 with a password. AFAIK that's possible. But then this password would need to be entered during boot, and I'm unsure whether this is currently supported by the dracut / cryptsetup boot procedure.
Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot.
The problem is the initrd: if your boot partition is not encrypted, the initrd is not protected and the weak spot. There is somewhere a blog by Lennart about this, maybe it explains the problems better. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Tue, 2021-12-21 at 13:47 +0100, Thorsten Kukuk wrote:
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering. But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD?
The USB stick or DVD will create other boot measurements and thus the TPM will not give out the hash to decrypt the harddisk.
In which PCR would these different measurements be?
Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot.
The problem is the initrd: if your boot partition is not encrypted, the initrd is not protected and the weak spot.
There is somewhere a blog by Lennart about this, maybe it explains the problems better.
I understand this, but TBH, as long as the excessive slowness of the decryption in grub isn't fixed, I see no practical value in encrypting /boot. IIUC it can currently be "fixed" only by weakening the encryption (using less KDF iterations or a weaker hash), because crypto hw accelleration isn't (easily) available in the restricted environment grub2 operates in. I once saw a reference where the grub author talked about that, can't find it any more. https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unloc... Regards Martin
On 2021-12-21 13:04, Martin Wilck wrote:
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering.
Using only PCR 7 does not guarantee a lot; extending the policy to more PCRs will increase the tampering surface protection.
But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD? As long as the PCR values are unchanged and she has root rights on the booted devices, the person should be able to read the entire disk. What am I overlooking here?
From the PoC nothing. There are some conflicting goals, but the main one is about the scenario of a server: - If there is non authorized change in the BIOS / UEFI, avoid the boot - If someone steal the HD, makes the data useless The PoC mostly should be covering this use case: for example, there is no password request.
I guess it would work if the kernel, initrd, and kernel command line were also used for PCR-based protection but that's not the setup described in the Wiki, which uses only PCR 7.
Yes, the final policy should be extended to more PCR. Using grub-tpm.efi will enable PCR 8 and 9, that will take care of measure the kernel, kernel command line and the initrd.
I believe the problem could be handled by locking the TPM2 with a password. AFAIK that's possible. But then this password would need to be entered during boot, and I'm unsure whether this is currently supported by the dracut / cryptsetup boot procedure.
I think that can be done, but systemd-cryptenroll can also enroll user provided passwords.
Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot.
Martin
Hi, Am Dienstag, 21. Dezember 2021, 13:04:51 CET schrieb Martin Wilck:
On Thu, 2021-11-25 at 17:33 +0100, Benjamin Brunner wrote:
For all interested and curious who would like to have a look or want to directly test it, Antonio Feijoo <antonio.feijoo@suse.com> prepared some step by step guides at https://en.opensuse.org/SDB:LUKS2,_TPM2_and_FIDO2.
The documentation should work on Tumbleweed and later on openSUSE Leap 15.4.
We would really appreciate any feedback, thoughts, or reports in case you encounter any issues.
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering. But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD? As long as the PCR values are unchanged and she has root rights on the booted devices, the person should be able to read the entire disk. What am I overlooking here?
You're not missing anything. I raised that in the thread already, and the wiki article should probably make that also more clear. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... Using just PCR7 does not provide any of the security properties that are usually expected. It only protects against someone having access to data on disks. Cheers, Fabian
On Tue, 2021-12-21 at 15:20 +0100, Fabian Vogt wrote:
You're not missing anything. I raised that in the thread already, and the wiki article should probably make that also more clear.
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...
Using just PCR7 does not provide any of the security properties that are usually expected. It only protects against someone having access to data on disks.
You wrote about /boot not being verified. But even re-reading both posts, I can't find the information that the encryption of the root device is easily circumvented. Protecting private data on disk used to be the main reason for which we used to do device encryption in the past. The integrity/verification aspect is a relatively new one. That doesn't mean it's not important, but loosing encryption in favor of (weak) verifiability seems to be a bad trade-off to me. Call me naïve: IMHO the likelihood of a device being stolen or lost, and private content leaking to a 3rd party more or less accidentally that way, are higher than of a device being actively tampered with, which assumes a concrete malicious intent against the owner of the device. Regards Martin
On Tue, Dec 21, Martin Wilck wrote:
Call me naïve: IMHO the likelihood of a device being stolen or lost, and private content leaking to a 3rd party more or less accidentally that way, are higher than of a device being actively tampered with, which assumes a concrete malicious intent against the owner of the device.
If you look at this from an end user use case traveling with his notebook: I would use a fido2 usb stick to encrypt the harddisk, not TPM2. If you look at this from a company view of point having many Edge devices out there, the chance that someboy is actively tampering with your Edge devices to e.g. steal your data is much, much higher. The work on this started because there are many requests to protect systems much better against attacts on Edge devices, but are in general usefull. Maybe not for everybody using a TPM device, but a fido2 stick instead, but in the end most of the stack is in both cases identical. If I would travel with my notebook and want to protect my personal data in the case my notebook get lost or stolen, I would not use the TPM solution but the fido2 stick. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Wed, 2021-12-22 at 08:08 +0100, Thorsten Kukuk wrote:
The work on this started because there are many requests to protect systems much better against attacts on Edge devices, but are in general usefull. Maybe not for everybody using a TPM device, but a fido2 stick instead, but in the end most of the stack is in both cases identical. If I would travel with my notebook and want to protect my personal data in the case my notebook get lost or stolen, I would not use the TPM solution but the fido2 stick.
I agree FIDO2 is best. But the TPM would be ok too if the secret was password protected, and/or the set of used PCRs would be "complete" in the sense that simply booting from a different device wouldn't reveal the disk contents. Martin
Hi Thorsten 😀 Am Mittwoch, 22. Dezember 2021, 08:08:44 CET schrieb Thorsten Kukuk:
The work on this started because there are many requests to protect systems much better against attacts on Edge devices, but are in general usefull. Maybe not for everybody using a TPM device, but a fido2 stick instead, but in the end most of the stack is in both cases identical. If I would travel with my notebook and want to protect my personal data in the case my notebook get lost or stolen, I would not use the TPM solution but the fido2 stick.
Still looking for a perfect and simple Solution to save my local data. In the moment I've implemented the encryption from Tumbleweed installation and improved it according Fabians proposal: https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_... Due to the fact, that I have 2 brand new Nitrokey 3 (with one USB-C and one with USB_A) for my wive and me: https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-rust-common-crit... I look on a solution which simply boots based on the used key in the Linux wich only requires the login password in Additon. Later on in best case also the kwallet and other wallets e.g. from GnuPG (Kleopatra, ..), Firefox and so on. For sure this is according my knowledge today not fully possible and also there is no automatic way. But step by step with some good manuals it will be greate. After participating Florians explanation TPM2 can only be an additional protection: https://www.youtube.com/watch?v=C58WLY7FvYk Regards Ulf
participants (7)
-
aplanas -
Benjamin Brunner -
Fabian Vogt -
Martin Wilck -
Thorsten Kukuk -
ub22＠gmx.net -
Ulf Bartholomäus