On Tue, Dec 07, 2021 at 05:01:50PM -0500, przemek klosowski via devel wrote: > On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote: > > >>> If available, use > >>>the TPM2 to additionally tie the password to local hardware. If the > >>>user is removed, also remove that password from that storage. > >>> > >>>During boot, if it is necessary to authenticate before the root file > >>>system has been mounted, allow admin users to log in using the credentials > >>>that were stored previously. > >>Is this being worked on? Do you have any references? > >Latest systemd versions have been getting some support for the low-level > >parts, i.e. the low-level encrypted-secret storage. But we're missing the > >upper parts, i.e. how to actually use and update the passwords. I didn't > >even mention this, because we don't have a comprehensive story yet. > > A scenario that wasn't mentioned here yet is using a disk from a failed > system: either moving it to another system, or even simply accessing the > data. If the credentials (including the LUKS encryption key/password) are > protected by TPM2, it may effectively prevent any further access. It would > be useful if any such new scheme avoided that. The recovery password is necessary for encrypted data. For a user account, it could be useful, but is less necessary, because generally you're expected to simply reset the password if lost. Generally the idea is that you have a nice reasonable-to-type password that is protected by the TPM, and in addition a second recovery key that can be used in case the TPM croaks or the disk is moved. systemd-cryptenroll and homectl support generation of such recovery keys [3,4]. In comparison to a password it is longer and generated from entropy instead of entered by the user, so brute-force attacks are not a concern. It is supposed to be written down or saved somewhere when initially creating the encrypted storage. > In enterprise system, there usually is a backup decryption key, accessible > to the enterprise admins. I am not sure what would be appropriate for > single-user systems: some sort of install-time rescue passphrase [1] > perhaps, that the user would write down and safely store [2]? > > [1] https://xkcd.com/936/ > > [2] conveniently stored next to the rubber hose so that the attackers could > forgo its use and type the rescue passphrase themselves. > https://xkcd.com/538/ That's a classic ;) [3] https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html [4] https://www.freedesktop.org/software/systemd/man/homectl.html Zbyszek _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
