On 22/08/2019 00:10, Chris Murphy wrote: > Anyway, the Fedora Workstation working group has this as an issue > being explored by a subgroup very soon, and make recommendations back > to the working group. So there will be a lot more discussion about > this in the near future. > https://pagure.io/fedora-workstation/issue/82 > https://meetbot.fedoraproject.org/fedora-meeting-2/2019-08-19/workstation.2019-08-19-13.01.html Hi, and while the subgroup of the group investigates ... Perhaps it would be a good idea to ask LUKS maintainers during the process, what do you think about the idea? :-) With the upstream maintainer hat on, there are several groups, that pushes very hard for TPM use, and others against it, for years already. (Just TPM1.2 is now obsolete, and most hw vendors pretend it never even existed.) This is Linux, there are so many possible use cases that the only strategy is to allow maintainers to configure it. If you see what is going upstream now, I am trying to prototype support for dynamic token handlers. (A LUKS2 token is an object that can be used to unlock LUKS keyslot using some external input - like TPM2). All this stuff can be completely disabled/compiled out, but also we can have TPM2 token handler installed by default - it depends on user/distro policy. You can use wrappers like Clevis/Tang, but there will also be a more straightforward solution to use TPM2 in LUKS2 in the near future. The initial idea behind LUKS is that it is a hw-independent solution, that's why we have very strong memory-hard password-based key derivation there for opening a keyslot. (If you have a decently strong passphrase, offline dictionary attack cost is very high, even if you have massive computation power.) If you enable an attacker to just unlock it using present hw, most of the parameters do not make sense anymore. It depends on the threat model, but let just expect stolen laptop that unlocks the disk automagically on that hw. And of course, we can use TPM with a PIN. Then our brave automation will try to use a cached passphrase (for example), and locks out TPM chip with exceeding number of PIN tries :) Also, the use of TPM2 can be very fragile. Seems that PCR registers changes are very different on different hw. Changing some BIOS option can cause that your system no longer boots, while on other hw it still works. So before you enable any such mechanisms, be very careful, you are opening a big can of worms. Milan p.s. Actually, there are also plans for much broader academic research for TPM2 behavior, and I would be more than happy if Fedora users could help us. Stay tuned ;-) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
