#43 Add an option in the installer to automatically create key files when encrypting with LUKS
Opened 2 years ago by nPrime. Modified a year ago

A common complaint with openSUSE’s implementation of encryption is needing to enter the LUKS password twice because of /boot being encrypted. Even though it is being done for good reasons (improved security over other distros that do not encrypt /boot), end users who don’t search for the reason won’t know this and are left with the impression that openSUSE’s implementation of LUKS encryption is poor.

Proposal is to automate the process of creating key files described in the wiki (https://en.opensuse.org/SDB:Encrypted_root_file_system) for root + any other encrypted volumes configured to be automatically mounted, and create an option for this in the installer when LUKS encryption is selected.

The option could say:

Create key files for single LUKS password prompt at boot

On mouseover (or when something is clicked for more information), it should explain that by default openSUSE encrypts /boot for additional security, but this has the effect of requiring the LUKS password to be entered twice when booting if key files aren't used.

If the option is selected, a pop up should include a warning that says where the key files are located and that they should not be copied to unencrypted backups or between systems.

If the user has opted for a separate /boot partition, the option should not be given (or if it is made visible, it should include a strongly worded disclaimer advising against its use).

The current setup also breaks hibernate (silently, without any warning or error message). It is quite strange for a laptop to have to choose between encryption, and suspend2disk/hybrid-suspend.

For the key passing, it would be much nicer if grub passed the password to the kernel directly, to store it in the kernel keyring. Also see

Metadata Update from @lkocman:
- Issue assigned to lkocman

2 years ago

I asked YaST team for a quick feedback on the feature. And if we find some agreement I'll simply track it as a SLE feature request.

Please be aware that SLE already treats features opened at this point in time as late features. But we're typically more flexible with community features than typical partner features.

We already have a SLE feature for this. Except that it does not contain this proposal / solution. So, instead of creating a new one, we could extend the current one ... after I find it :) Or you can create a SLE feature and we'll merge them if appropriate.

I think it'd be a better idea to just always force a separate /boot instead of juggling weird key file things for encrypted root filesystem.

Metadata Update from @Pharaoh_Atem:
- Issue tagged with: SLE

2 years ago

JFTR, we do not enforce anything that is not really necessary. I can almost see those bugreports: Why do you always enforce /boot when XYZ is possible? It does not make sense! etc.

Yes, but having a separate unencrypted /boot also means that you always have a way to troubleshoot booting your system.

Having the possibility to set a key file for an encrypted LUKS device may be a useful feature in several scenarios.

But I don't see why we should link that to the scenario of the separate /boot and its associated problem of asking the password twice. Actually, as far as I had understood, the right solution for such problem would be to implement a secure handover of the password from the boot-loader to the kernel and from there to cryptsetup (something that is in the mid-term roadmap).

But, as far as key files are useful in several scenarios, using them to bypass the need of entering the password twice during boot looks to me like exchanging security for convenience.

Metadata Update from @lkocman:
- Custom field SUSE Jira adjusted to https://jira.suse.com/browse/SLE-16231

2 years ago

Hello team,

SLE-16231 - Full disk encryption - enter password just once - autologin looses it's original meaning, which is according to YaST team an existing feature with same goal, will not be implemented prior Public Beta and SLE Release Manager is suggesting to release implementation via maintenance update.

We do not have self-update mechanism for installer in place yet. The self-update mechanisnm being requested in #26. Another way would be quarterly image respins that we're enabling for 15.3+. So the long story short, this would not be in 15.4 GA.

However, there is a set of related features to enable TPM 2.0 / FIDO integration with cryptsetup. Perhaps this would be another path to take, that could in overall improve the current experience with full disk encryption.

I'll re-discuss what user scenarios do we plan to cover. I can see from existing discussions that PM is bit afraid of hybernate/resume security holes.

The calamares installer (Debian Live, Manjaro, KDE Neon, others) is doing this -- installing the keyfile to the initrd when choosing full disk encryption -- for some time, if it helps (to see what problems arise/an example implementation).

I think it'd be a better idea to just always force a separate /boot instead of juggling weird key file things for encrypted root filesystem.

The problem with that (in addition to possible security concerns from leaving /boot unencrypted) is that boot-to-snapshot does not work with /boot on a separate partition (or at least it didn't last time I tried), and the contents of /boot would not be snapshoted.

/boot is already not supposed to be snapshotted. In the default configuration, we have /boot as a separate subvolume specifically so it doesn't get snapshotted with /.

Has boot-to-snapshot with a separate /boot been fixed?

Anyway, I tried it now and /boot is not on a subvolume, either on Tumbleweed or Leap.

If I understand correctly the issue is that boot-from-snapshot works by including a grub snippet stored alongside each snapshot. Therefore /.snapshots has to be on the same partition as /boot and unlocked at the same time as /boot.

Neal, the default config does not have /boot as a different subvolume, and it is included in snapshots. The initrd matches the modules on disk if a kernel install is rolled back.

Yeah, you're right. I misremembered. We have subvolumes in /boot to exclude them, but not /boot itself...

Login to comment on this ticket.