Does not rsa is insecure now as qc is can break it in next 3years or so.?
RSA’s demise from quantum attacks is very much exaggerated, expert says | Ars Technica is a good read. If cryptological advances threaten the foundations of TPM2, then there will be a TPM3, and we’ll have to adapt like everyone else.
I am a big fan of PCR signatures these days. Changed my mind 180° on that.
PCR 7-based policies are not that easy to deploy, if you at the same time let fwupd update dbx as part of its firmware upgrade routines (and thus the secureboot policy). I probably should add a note to our docs about that. Because that means fwupd would change PCR 7 values regularly (and you cannot sign the expected values because laptops have keys enrolled specific to the vendor). So for now I’d step away from PCR7 based policies. This needs more preparation in systemd first.
I think what you can do is PCR 11 based policies for now. I’d envision it like this: fedora would create a signing keypair. Each time fedora builds a kernel it would include a “.pcrsig” PE section that contains a signature for the expected PCR 11 value in the boot phase where the rootfs shall be unlocked (i.e. in the initrd), generated with that key. Then, fedora would enroll the rootfs to that public key and thus have a rootfs that can only be unlocked on fedora, from the initrd.
(it might make sense to generate a second keypair at the same time, and sign with it the PCR 11 values expected on that kernel for the boot phases expected during regular runtime too. This should be used for auxiliary encrypted volumes, i.e. not the rootfs but anything else that is activated from later boot or on demand, instead of from the initrd like the rootfs).
PCR 4-based policies are probably out of scope for now too, we also need more infrastructure to make that happen. We probably have to predict changes like Windows does, and then hook into that from fwupd and from boot loader updater (bootctl) or so. It’s a mess, and nothing has been done.
So, under the assumption you stick to PCR 11 based policies for now, there are two attack vectors I see, that we need to address sooner or later.
-
the rollback thing matthew mentioned: we need to cut off old versions of the OS regularly so that people cannot attack the disk encryption by booting old versions of the OS. See above for our ideas on that. No code exists.
-
right now the systemd efi stub that measure the kernel it is about to boot to PCR 11 does so knowing that it is the only user of that PCR. Which is great. But it also means that if you boot through shim, then anything else booted through shim will see an all zero PCR 11, and then can manually measure whatever it wants into PCR 11 and fake the values we expect only to see if a valid fedora UKI kernel is booted. (This vulnerability is not specific to sd-stub btw, IMA has the same weakness, afaics). A fix to this is technically easy, but I didn’t want to deal with the politics of this: shim should probably just measure a string derived from the payload it is about to boot into all PCRs that are not used by itself or by the firmware, including PCR11.That way, shim payloads cannot easily fake each other’s PCR values.
I’d ignore TPM1.2. It’s legacy hw, and pretty useless, given that SHA1 is icky. It’s also different enough from TPM2 that it’s not worth it I think (e.g. you cannot do signed PCR policies with TPM 1.2).
There needs to be graceful fallback for systems lacking TPM anyway, and I’d really treat TPM1.2 systems like TPM-less systems.
(I mean, the TPM2 situation i missing so much infra already, by throwing TPM1.2 in the mix you just add more work on top that’s not going to make anything easier)
Oh and there’s one more problem I see. Unless I am mistaken Fedora uses Grub to boot. And I think it doesn’t boot through the kernel’s EFI stub, does it, but loads the kernel via its own loader? If so, sd-stub won’t run, and hence the PCR 11 measurement and all that magic doesn’t happen.
I think grub can be told to invoke the kernel as EFI program though. Dunno. You’d have to do some research. Grub of course is a icky if you ask me, if I was you I’d address that issue by dropping it too. As I understand RH is working on some new boot loader that is the linux kernel. I think it’s totally nuts, but it might get you into similar problems.
Grub when invoking a kernel as EFI program won’t implement fs interfaces on the EFI image btw, which is another problem, as we try to load various sidecard files from the file system backing the kernel. initrd sysext, systemd credentials, random seed, and so on. We degrade gracefully there, but I think this will sooner or later become a problem for you: if you want modern graphics drivers in the initrd (for plymouth) then you might have to embedd 100M+ into the UKI. We suggest using sysext images for such extensions, so that you basically install one UKI plus a bunch of sysext for the major drivers you need in the ESP, but of course, if you can’t pass the sysext to the UKI safely then this is not going to work.
Yeah, this all is a lot of work to get ready for general purpose distros.
(I cannot participate in this discussion further btw, this stupid discussion webforum doesn’t allow me to post anything anymore. Some limits apply, suggests I edit existing posts instead? This is so stupid.)
Entirely unrelated to the above, here’s what I wanted to post earlier, but the webforum didn’t allow me to.
RSA is the only asymmetric encryption scheme all current TPM2 implementations support. Thus you have few options there.
That said, Fedora could additionally generate UKI PCR sigs with an ECC key, and then provide both in the .pcrsig PE section. Then, local systems can chose against which of the two they lock their disk to, using ECC if supported and RSA otherwise. But not sure this is worth the effort given the SecureBoot signing is RSA only anyway.
1 Like
Interesting thread 
Just from my rather niche perspective (and I saw it was touched on in the document) - but please consider what would happen with Fedora preloads on the Lenovo platforms - and if this is something that can be enabled on a Fedora preloaded system, so that the user can login on first boot.
I imagine a lot of people will appreciate an encrypted and guaranteed non-tampered with preload image (I can see why that’s important) - but I suspect it’s not easy to do.
As a note - we do currently add our documentation to the Fedora preload after getting the image from the Fedora site - and I suspect that would break a lot of this. I’m sure we can find an alternative to that but figured I would flag it so it’s at least a consideration.
Mark
1 Like
As making full disk encryption a default option seems imminent: I would like to remind everyone (a quote from the previous post) that not all Fedora distros are ready to offer FDE by default to users with custom keyboard layouts (= not with the “US English” one), which is not that rare as it might seem. I have seen that Fedora Workstation 37 works fine (respects the custom keyboard layout during boot), while Fedora Silverblue all versions (including F39 Rawhide) for some reason always uses US English during boot even if it was deleted during the setup phase (and does not even show the layout) - which makes unlocking the disk practically impossible after first reboot. And it better be fresh install, as the newly encrypted data will be lost.
A new user would reinstall the system several times trying to guess why the system won’t accept the (apparent) correct passphrase on the first boot… And each time it will refuse to unlock during boot because of the poor keyboard layout handling.
There’s a related Bugzilla report: Bug 1890085 - English keyboard layout is erroneously used during initramfs phase (e.g. decrypting encrypted storage devices) instead of native layout, on Silverblue / ostree installs which has survived several generations of Fedora already; is completely stagnant, and does not seem to have any priority whatsoever 
I have also noticed that during the install phase there’s a great option to test the keyboard layout, but not always the symbols appeared as expected (for example, instead of “ñ” a different symbol appeared), which is unacceptable if you need to define a passkey for FDE.
Unfortunately, this bug appears to be completely abandoned. If “FDE by default” is near, these bugs must be fixed soon as it affects lots of people with national and non-standard keyboard layouts. On behalf of such users, I’d like to remind about it and suggest prioritizing the bug.
- Encrypt / exclusive of /home with a TPM2-stored key, bound to PCR 7
- Encrypt the /home subvolume with the same key
- Encrypt home directories with the user password
Applications sometimes use /var to store user data, and some applications put secrets in /etc. It is currently safe to assume that if the user encrypts their system, then anything in / other than /boot is secure. This plan would let an attacker read anything outside of $HOME with a cold boot attack. While it is usually true that / has no sensitive information, this is not always true, so we should support that use case.
We would need to encrypt /var and /etc to keep a level of security consistent with the current status quo, but then we have problems with multi-user setups. A better solution would be to update applications to stop storing data outside of $HOME, but this will take a lot of time and effort from application devs.
Should we warn users at install time to keep sensitive data in $HOME? This might be confusing and lead to bad UX.
I’ve created a ticket to rpm-ostree to support LUKS decryption using a bluetooth keyboard here: InitramFS Generation with Paired Bluetooth Device Metadata · Issue #4214 · coreos/rpm-ostree · GitHub
I hope the plan would also cover this.
Edit 1: Also created an issue on Bugzilla: 2184519 – InitramFS Generation with Paired Bluetooth Device Metadata
We have a Prioritized Bugs process for cases just like this. I nominated it for discussion at the next meeting, scheduled for 2023-04-19T14:00:00Z in #meeting-1. Anyone can nominate a bug to be a Prioritized Bug, so I encourage you to do that if you see other bugs that meet the guidelines.
2 Likes
I don’t think this problem is relevant. The whole point of this discussion is to figure out how to do encryption without the LUKS password prompt in plymouth, so keyboard layout in initramfs will not be an issue.
I wish Password will be available as a fall back option to unlock the disk.
Hardware can fail and what if mainboard are replaced?
There will be a recovery key if the TPM key is not available.
From the draft plan:
Recovery keys
A user will need a recovery key in a range of situations:
- Motherboard failure/replacement
- Move a harddrive to a different machine
- Reinstall keeping home directory data
- Booting a custom initrd or kernel
- A bios setting is changed that affects the PCR contents (Some of these can be handled by )
Microsoft and Apple store recovery keys in their cloud services by default. We don’t have that option - even if we did have a Fedora cloud service, we would be unlikely to want to store something so sensitive there.
But if we display at install time “Please write down this recovery key and store it in a safe place where you can find it”, we have to assume that many users will fail at the second step. Not clear how to address that best - perhaps suggesting taking a picture of the recovery key with a phone. (For many users, losing their laptop and having someone break into their online photo storage are independent threats.)
1 Like
btw, systemd-cryptenroll supports recovery keys as first class concepts and will generate a QR code for you which you can use to scan the key to store it in your phone or so.
I’ve created an issue to track this work in Silverblue and other related rpm-ostree desktop variants: Future of Encryption in Fedora (Silverblue version) · Issue #447 · fedora-silverblue/issue-tracker · GitHub
1 Like
My understanding was that PCR7 only extends the PCR with the public keys that are actually used in the boot path, not all available public keys. Is that wrong? I discussed this with Richard Hughes earlire and he thought that PCR7 would be stable, but was willing to do the work on the fwupd side for a solution if one is needed.
This sort of issue is why I thought we would need PCR 7+ PCR 11, not just PCR 11. it seems like to fix this and use only 11 you’d need to revoke old versions of shim and then make sure that nothing that left PCR11 0’d was ever signed again. Is that really more feasible than making PCR7 binding work?
The UKI plans for Fedora call out that it will require bootloader changes. Using sd-boot would certainly be simplest…
I’ll be talking to our bootloader team today, I’ll ask them about their plans and how that would relate to using sd-stub or being compatible with it.
1 Like
Can you retitle this “in Fedora Workstation”?
A lot of the discussion is pretty desktop use case specific, especially things like the home directory. I’m not aware of any discussion of applying this approach in e.g. Fedora CoreOS, and there are distinct design considerations. Also notably today FCOS doesn’t use Anaconda.
I want to provide a recovery key that I generate.
I do not want it to touch my phone.
I do not want to have to write it down.
If I provide the key twice then you can confirm I have not made a mistake with it.
But I suppose that I’m tech savy enough to add a recovery key early on in the life of the new system if I cannot provide it at install time.
1 Like