Bug 1823820

Summary:	RFE: always create a recovery key when enabling disk encryption
Product:	[Fedora] Fedora	Reporter:	Chris Murphy <bugzilla>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	anaconda-maint-list, jkonecny, jonathan, katyaberezyaka, kellin, vanmeeuwen+fedora, vponcova, vtrefny, wwoods
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
https://pagure.io/fedora-workstation/issue/136

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.
https://www.saout.de/pipermail/dm-crypt/2020-April/006416.html

[2] modhex references
https://www.saout.de/pipermail/dm-crypt/2019-December/006285.html
https://en.wikipedia.org/wiki/YubiKey#ModHex

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.