Add TPM2 systemd-cryptenroll to Tips and Tricks #176
Conversation
This worked for me; I'm not sure if it's complete, or the most secure possible configuration, but it's frustrating to try to piece this together from blogs and discussion pages, so looking to firm it up here; would appreciate testing/confirmation/edits/corrections.
|
|
||
| Then, enroll the device: | ||
|
|
||
| $ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /your/boot/device |
There was a problem hiding this comment.
I think /your/boot/device is confusing. It makes it sound like you should specify your /boot or ESP device here, when actually it's your LUKS block device.
Maybe /your/luks/device is better?
And then also add a follow-up paragraph that explains you can determine which device that is by running sudo cryptsetup status /dev/mapper/luks-* or looking in /etc/crypttab.
There was a problem hiding this comment.
added some steps around finding the proper device, changed my shorthand for the device location
We found out in containers/bootc#421 that you probably don't want to do that...it will appear to work just fine until the day that you update shim (which we don't do by default, but will happen if you run bootupctl update). Also for pcr0, I'd be a little wary as I suspect at least running things like Basically in general, IMO systemd upstream is doing the right thing in supporting binding to PCRs, but it's extremely easy to blast off your own feet with it. (Like many other security technologies, it's a balance between preventing attacks vs system usability) |
Is the takeaway here to omit the --tpm2-pcrs flag? |
|
I don't think you can do that? The way cryptenroll works (as I understand it) is to derive a key from the specified PCRs and add that to a free LUKS slot. I think @cgwalters is warning us that PCRs are subject to change in surprising ways. Take a look at this page: https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/ In fact, it's not just the shim itself that can affect PCR 7, I'm pretty sure if you let fwupd upgrade your DBX with newer sig exclusions that also influences PCR 7 state. Upgrading your system BIOS will certainly cause PCR 0 to change. I think these are all okay though. It's just worth mentioning in these docs you're proposing to add that using TPM2 to bind your disk is a convenience thing and that you absolutely MUST keep a regular passphrase enrolled in a keyslot of your LUKS container in case the PCRs change. |
incorporating some feedback and changes, clarifying some of the drawbacks and caveats around this setting
|
Thanks for writing this! I'll give it a try. |
|
So I've found the following related discussions:
Reading this PR, I think it would be great to figure out why the |
make a note that the re-enroll will need to be re-run if the boot process changes enough to upset the pcr; clarify which device needs to be passed to the cryptenroll command
|
I've made https://gitlab.com/fedora/ostree/sig/-/issues/33 for Rawhide/F41 to help improve the situation here. |
trading security for convenience, not the other way around
|
|
||
| == Enabling TPM2 for LUKS | ||
|
|
||
| It is possible to use the TPM2 device in your machine to automatically decrypt your LUKS-encrypted device. It is important to note a few things regarding this setup: first, it is trading security for convenience. Anyone who has access to both the disk and the TPM2 device can unlock your data. Second, it is crucial to keep a LUKS passphrase in addition to the TPM2 device that you can use to unlock the LUKS device; if you update BIOS, or the kernel shim, or make other substantial changes to your device, the TPM will refuse to sign your session and you will fall back to manually entering a LUKS passphrase. In this case, you can re-enable TPM2 for unlocking by re-running the enroll command below. This tip assumes you have a single LUKS device created during the Anaconda installer; if you have more than one LUKS device, you will need to correctly identify the device you want to enroll. |
There was a problem hiding this comment.
This paragraph is a bit of a wall right now I think :D
How about:
| It is possible to use the TPM2 device in your machine to automatically decrypt your LUKS-encrypted device. It is important to note a few things regarding this setup: first, it is trading security for convenience. Anyone who has access to both the disk and the TPM2 device can unlock your data. Second, it is crucial to keep a LUKS passphrase in addition to the TPM2 device that you can use to unlock the LUKS device; if you update BIOS, or the kernel shim, or make other substantial changes to your device, the TPM will refuse to sign your session and you will fall back to manually entering a LUKS passphrase. In this case, you can re-enable TPM2 for unlocking by re-running the enroll command below. This tip assumes you have a single LUKS device created during the Anaconda installer; if you have more than one LUKS device, you will need to correctly identify the device you want to enroll. | |
| It's possible to use your machine's TPM2 device to automatically decrypt your LUKS-encrypted boot disk. | |
| It's important to understand that by doing this, you are trading security for convenience. When your LUKS device can be decrypted automatically by your TPM2 device, you are making this device more vulnerable to an ["evil maid attack"](https://en.wikipedia.org/wiki/Evil_maid_attack). Anybody with physical access to this machine will be able to access the data. | |
| It's crucial to keep a LUKS passphrase *in addition to* the TPM2 enrollment. If you update BIOS, the `shim` package, or make changes to your BIOS settings (in particular your Secure Boot configuration), the TPM2 unlock will not work and you will fall back to manually entering a LUKS passphrase. In this case, you can re-enable TPM2 for unlocking by re-running the enroll command below. | |
| This tip assumes you have a single LUKS device created during the Anaconda installer; if you have more than one LUKS device, you will need to correctly identify the boot device you want to enroll. |
|
|
||
| To set up TPM2 unlocking, first, find the LUKS device you want to enroll. This is probably in /etc/cryptsetup; you can also use `cryptsetup status /dev/mappper/luks*` to identify the device. | ||
|
|
||
| Next, enable the required initramfs and kernel features. Note that the initramfs command below will overwrite any other initramfs changes you have made: |
There was a problem hiding this comment.
I think the initramfs section should be moved to the "first step", with a note that it's only necessary for F40
| $ sudo rpm-ostree kargs --append=rd.luks.options=tpm2-device=auto | ||
| $ sudo rpm-ostree initramfs --enable --arg=-a --arg=systemd-pcrphase | ||
|
|
||
| Then, using the device you identified with 'crpysetup status' previously, enroll the device: |
There was a problem hiding this comment.
(Assuming that the previous suggestion to reorder the initramfs customization has happened, so that contextually the following changes make sense)
| Then, using the device you identified with 'crpysetup status' previously, enroll the device: | |
| Enroll the identified device: |
Co-authored-by: Sam <[email protected]>
|
|
||
| Then, using the device you identified with 'crpysetup status' previously, enroll the device: | ||
|
|
||
| $ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/boot-device |
There was a problem hiding this comment.
Is 0+7 secure enough? Correct me if I am wrong, but changing the kernel parameters would allow to mount the disk and change the root password.
There was a problem hiding this comment.
It's not, but it's the best we can do right now as the kernel parameters change on every boot as ostree includes the hash of the deployment to boot in the kernel parameters.
There was a problem hiding this comment.
I don't think it's a good idea to recommend this because it will appear to work for a while, until such time as you update shim, and then it will break.
We discovered this in e.g. containers/bootc#421 (comment)
At least if you have this it needs to have a big warning label about this...
There was a problem hiding this comment.
Yes, the fact that the TPM2-backed credential can stop working is well understood and has been discussed a few times in the diff discussions in this PR already
There was a problem hiding this comment.
See the most recent wording I proposed here: https://github.com/fedora-silverblue/silverblue-docs/pull/176/files#r1721249426
So line 168 of my proposed changes would ideally be wrapped in some kind of styling element that turns that paragraph into a warning of some sort.
There was a problem hiding this comment.
Also, I think the warning should be sufficient and that some documentation here should be merged letting folks know how to use this. shim updates seem to be about as regular as UEFI platform f/w updates from my perspective - that is, once every year or so... I boot my computer daily, so I'm certainly glad I only have to type my password once every 500-1000 boots nowadays, rather than every time 😅
This worked for me; I'm not sure if it's complete, or the most secure possible configuration, but it's frustrating to try to piece this together from blogs and discussion pages, so looking to firm it up here; would appreciate testing/confirmation/edits/corrections.