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