Bug 1823820 - RFE: always create a recovery key when enabling disk encryption
Summary: RFE: always create a recovery key when enabling disk encryption
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-04-14 14:55 UTC by Chris Murphy
Modified: 2021-09-20 12:53 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Chris Murphy 2020-04-14 14:55:01 UTC
Description of problem:

Primary context is the "encrypt my data" option in the installer's automatic/default path, for Fedora Workstation.

Users sometimes forget the LUKS user passphrase; and there are myriad ways the encoding of this passphrase can be affected in-between the user's finger tips and cryptsetup luksOpen entry. If that encoding differs from luksFormat time, it's not possible to unlock the volume.

This problem comes up on the dmcrypt list regularly, and periodically results in data loss. It's one reason why upstream developers strongly recommend passphrases only use printable ASCII characters (the i18n implications of this are recognized).

It's technically possible to use one of the keyslots for a recovery key. This enhancement request suggests always and automatically generating a random and suitably long passphrase (upstream suggests modhex as the character set as a further constrain to improve the chance this key will work/be unaffected by things that can affect passphrase encoding) and setting it as a "recovery passphrase" using one of these extra LUKS keyslots. A mechanism for the user to save this key also needs consideration: display it so they can screen shot it; possibly a means to save it to a USB storage key.

Version-Release number of selected component (if applicable):
Future release

Additional info:

Comment 1 Chris Murphy 2020-04-14 16:26:52 UTC
In particular, if there are no restrictions on character set for the user entered passphrase, having a recovery key becomes all the more important.

Comment 2 Chris Murphy 2020-04-14 18:01:59 UTC
I also think the proposed feature, or a subset of it, is useful for the TPM/yubikey use case down the road. [1]

For example, while I'm not certain of the TPM limitations for encoding, certainly modhex [2] will work. It might be true that this use case calls for using and setting only a recovery key, rather than two keys (user specified and recovery). And then reuse whatever mechanism for saving that randomly generated key. Kickstart installs may want an install time specified key rather than random, but it's a good bet to enforce a restricted character set to make sure this is actually going to work and be recoverable should the need arise.

[1] dmcrypt/cryptsetup folks are working on this but no ETA yet.

[2] modhex references

Comment 3 Vendula Poncova 2020-04-15 09:41:19 UTC
Hi Vojta,

could you look at this RFE, please? Does Blivet support multiple passphrases?

Comment 4 Vojtech Trefny 2020-04-15 12:03:09 UTC
We currently support creating a backup passphrase using volume key -- https://pagure.io/volume_key -- but only in kickstart using the `--backuppassphrase` and `--escrowcert` options. Backup keys are then stored in the /root directory encrypted by the provided certificate.

Note You need to log in before you can comment on or make changes to this bug.