[TW] Use LUKS2 and offer TPM-auth in installer

[bbrunner]

While the YaST-installer in Tumbleweed still uses LUKS1 for Full Disk Encryption as default (to enable LUKS2 you have to add "YAST_LUKS2_AVAILABLE=1" as kernel command line option), Agama on ALP already supports LUKS2 with the additional authentication mechanism via TPM2.0.

With the last SRs (sr#1090915 and sr#1090821) being accepted into Factory, the sources in ALP and Factory are finally in sync and IMHO it would be a good time to do the switch from LUKSv1 to v2 with the same defaults as we have in ALP.

While grub2 currently does not support Argon2, we are currently tied to use PBKDF2 as encryption-algorithms. Nevertheless, there are also plans to introduce Argon2 support.
Therefore, it would be nice if the functionality could be easily extended to select an Algorithm in the future.

Please let me know if you need any additional information.

[bbrunner]

Please also see https://en.opensuse.org/SDB:Encrypted_root_file_system#Unattended_boot_with_TPM_2.0 for implementation-details of unattended boot with TPM.

[bbrunner]

Are there any news, or do you need any additional information?

[ancorgs]

We are working on adding TPM unlocking via fdetools to YaST.

In the first version, it will only be available for AutoYaST for the very same reasons LUKS2 is hidden behind the YAST_LUKS2_AVAILABLE - it's very easy for users to shoot themselves.

So stay tuned for news.

[bbrunner]

Thanks Ancor for the update!
In regards to LUKS2 (without TPM), it should already be safe to use, if the selected default-algorythm for the password is PBKDF2 instead of Argon2.

But after the TPM enablement is already in progress, it should be fine to wait till everything is in place, before moving it to the "regular" installer.

[ancorgs]

[...] In regards to LUKS2 (without TPM), it should already be safe to use, if the selected default-algorythm for the password is PBKDF2 instead of Argon2.

Yes. But that could give users a false sense of security. Since LUKS2 with PBKDF2 is not really more secure than LUKS1.

[lnussel]

any news on this one? With systemd-boot, encryption can safely use luks2 with argon

[lnussel]

Given that luks2 metadata is precondition for many other features systemd brings such as TPM, FIDO2 and recovery keys, and grub2 argon support is still not there even after more than six months, maybe we need to reconsider. I'm not a huge fan of a non-default luks2 setup ie using it with pbkdf2 but luks1 is really getting in our way now.

[aplanas]

LUKS2 with PBKDF2 is not really more secure than LUKS1

That is true but defaulting to LUKS2 always will help us to introduce the FDE based on systemd that we have for MicroOS / TW. The selection of using the default Argon2 or downgrade to PBKDF2 can be done later, when the user select systemd or grub based fde.

In any case LUKS2 is an invariant.

[ancorgs]

In Agama we are already going for LUKS2 with PBKDF2 (with TPM unlocking if possible and chosen by the user). See openSUSE/agama#995 (still not merged).

I guess the same (forcing PBKDF2) is acceptable for TW installed with YaST.

[lnussel]

So what's needed to move this forward?

[ancorgs]

Ok. Time for next steps. Sorry for not being responsive, but I was busy with other stuff (Agama-related, mostly).

Bringing TPM-auth to YaST would be quite some work. I will summarize below everything that is missing in case somebody wants to try.

But unleashing LUKS2 in YaST for TW should not be much of a problem, so I think it's time to take the next steps.

Introducing LUKS2 support

• First, I would remove the need to use YAST_LUKS2_AVAILABLE by removing this method definition
  • That would make LUKS2 available to anyone using the Expert Partitioner.
    • All my initial concerns about people using this wrongly and then opening bug reports still stand. I expect unpredictable out-of-memory errors and users wrongly using Argon2 for file-systems needed for booting. But let's try and see.
    • We may mitigate that by setting PBKDF2 as the default value in the Expert Partitioner interface.
  • That would not change the default encryption technology used by the Guided Setup. It would still be LUKS1.
• Then I would make the Guided Setup configurable by product/role in the control file
  • That implies adding the fields ProposalSettings#encryption_method and ProposalSettings#encryption_pbkdf to #load_features
  • It would also be good to document that here.
• Finally I would create a temporary system role to use LUKS2 with PBKDF2 as the encryption method in the Guided Setup (roles can redefine sections of the control file). I wouldn't check the default configuration for regular TW roles yet.

Using a role to adjust the configuration (both encryption method of the Guided Setup and default bootloader) is much preferred over #1109. Adding the password field to that hidden dialog and then passing it to the Guided Proposal is indirect and insecure.

Introducing support for TPM-based unlocking

As mentioned above, I think this would need more work for the following reasons:

• Lack of support in the inst-sys. This can have changed, but the last time I checked it couldn't check whether there was a functional TPM (missing kernel modules and tools).
• No specific user interface in the Expert Partitioner.
• We need to ensure all affected devices share the recovery password. That's always the case with the Guided Setup but not with the Expert Partitioner.
• During installation, the UI and the AutoYaST documentation need to properly explain the need to boot from the target device after installation (no DVD → boot from hard disk) and check any possible interaction with the second stage.
• When creating new devices with that encryption method in an already installed system: it’s not 100% clear how the feature should work.

[lnussel]

Could we just make luks2 with pbkdf the default?

Roles are already used for desktop selection IIRC. So unless there are layers of roles we'd have to duplicate all of them to offer FDE.

[ancorgs]

Could we just make luks2 with pbkdf the default?

I guess we could. But I would also do this part then:

We may mitigate that by setting PBKDF2 as the default value in the Expert Partitioner interface.

Right now, the default pbkdf2 is a setting of the storage proposal (a.k.a. Guided Setup). I would make the Expert Partitioner also honor that setting.

[lnussel]

Ok, sure. If there isn't one central place that sets the default kdf everywhere then lets change all places.

[lnussel]

(the sd-boot path would still need to switch to argon2)

[schubi2]

Could we just make luks2 with pbkdf the default?
I guess we could.

But then when and where should be the password input by the user ?

[schubi2]

I have tried to summaries the points:

General

• Making LUKS2 in general available besides LUKS1.
• Pre-selecting, if an encryption will be done while an installation and
  if yes, which one (LUKS1/LUKS2) will be taken for it.
  This will be done in the product definition XML file (encryption_method, encryption_pbkdf).
  So, each product can define if an encryption is in a default installation.
  Unfortunately it cannot be defined via roles, because we would double all entries.
  E.G we would have two GNOME roles. One with and one without encryption.
• If an encryption has been set in the product description, following possibilities would
  be available for the encryption password input:
  -- An own dialog between role-selection and partitioning proposal overview in the installation
  workflow.
  -- If no password has been set the user will be report an error in the partitioning proposal
  overview and he can set it there via the dialog described above.

Details

1. LUKS2 is always available
   -- Removing YAST_LUKS2_AVAILABLE and the dialog luks2_checkbox.rb
   -- LUKS2 and pbkdf is available everywhere (Guided Setup / Expert Partitioner)

2. Adding entries in the product control file proposal section
   -- Adding encryption_method, encryption_pbkdf.
   -- If an encryption has been defined in the proposal section, the password will be also set in the way
   of yast/system-role-common-criteria@feb23e6
   I like this solution and believe it is not a hack ;-)

3. Implementing or reusing the Dialog in storage-ng for encryption password input.

4. Adapting the storage proposal to report an error, if an encryption has been selected but no password has been defined.

5. I am still a fan of the solution in LUKS2 and systemd-boot can be set by the user for the proposal #1109 but with following
   changes.
   -- Let the user decide, which bootloader he would like to have(systemd-boot,grub,grub2)
   -- Let the user decide, which encryption he would like to have (none, LUKS1, LUKS2)
   -- Let the user decide, which pbkdf he would like to have for encryption.
   -- Set password, if an encryption has been set.
   The settings will be written proposal settings. They are the same like the Product have been defined.
   So, the product specific settings can be overwritten here by the user again.
   The decision to have it is up to you :-)

I will start with 1. because we will need it anyway and it is not depending on the decision how we are going on.

[ancorgs]

My own summary :-)

• In Tumbleweed, we should use LUKS2 with PBKDF2 as default encryption settings for anyone using encryption (no matter whether they use the default Grub2 or systemd-boot, whether they use the Expert Partitioner or Guided Setup, etc.). That implies

  • Change the value of ProposalSettings#encryption_method and ProposalSettings#encryption_pbkdf for Tumbleweed.
    • I would suggest to do that by adding those fields to ProposalSettings#load_features and then modifying the control file for Tumbleweed.
    • Ludwig suggested me in a call a more hacky approach of simply modifying the default values with a patch in the spec file that would only be applied at TW.
  • Make LUKS2 always available in the Expert Partitioner.
  • Always use LUKS2 + PBKDF2 as default value in the Expert Partitioner form for encryption.
    • I would suggest to do that by honoring ProposalSettings#encryption_method here and ProposalSettings#encryption_pbkdf here
    • You can also follow Ludwig's hacky approach and patch that file at the spec file for TW.

• I still don't see the need of having an extra form or field or workflow step or anything for enabling encryption and for asking the password. With the above changes, anyone could just use the Guided Setup or the Expert Partitioner to enable encryption in the usual way and all Tumbleweed users would get a LUKS2+PBKDF2 system.

• About opting for systemd-boot or Grub2, I don't have an opinion about what is better (expert console or just a new setting at bootloader UI or just forcing it for TW...).

[lnussel]

I actually had a configure switch in mind rather than a patch. cryptsetup itself has this:

%if %{?suse_version} < 1550
  --with-default-luks-format=LUKS1 \
%endif

I kind of assumed that the default would be in native code that has some equivalent of a configure script. However looks like it's several places in Ruby. No idea how to do a proper build time default there. I really don't think this needs to be runtime configurable. LUKS1 is dead. The only reason for yast to keep it around is SLE15 compat. Going forward there is no need to give the user a choice for LUKS1.

[aplanas]

My own summary :-)

* In Tumbleweed, we should use LUKS2 with PBKDF2 as default encryption settings for anyone using encryption (no matter whether they use the default Grub2 or systemd-boot, whether they use the Expert Partitioner or Guided Setup, etc.). That implies

I fail to see the logic here. There are two kinds of FDE as now:

• grub-base encryption: LUKS2 + PBKDF2
• user-space encryption: LUKS2 + argon2id (cryptsetup default)

The user space encryption is agnostic of the bootloader: you can use grub2 (+bls patch) or systemd-boot.

For user safety seems more logical to default to LUKS2 + argon2id unless the grub-base encryption is selected. Or what am I missing?

[lnussel]

The idea would be to start with the most simple and least intrusive change to get this issue moving at all finally. So first switch to the smallest common denominator of both setups, ie luks2+pbkdf2. Then we can improve the logic from there.

[schubi2]

Ok, I have tried to fulfill Ancors requirements of

#1088 (comment)

Lets see, if we are going the right way:

#1115

yast/yast-storage-ng#1380

@ancorgs it would be nice if you can check it.