TPM backed encryption got me locked out on reboot

[superm1]

What happened?

I experimented today with the TPM backed FDE offered in Ubuntu 23.10 beta in the desktop installer in a prototype system.

I turned on UEFI secure boot, and then in the installer let it do the updated installer from git when prompted. In advanced I enabled the TPM backed encryption.

The system booted up fine after install. But after I tried to reboot it, I noticed that it wouldn't boot up and was requesting a recovery key.

I do recall during install being told to get the recovery key from the command line after install was done, but as I wasn't changing anything that I expected would break boot I hadn't done this yet.

As I don't have the recovery key, the system is toast. It's a prototype system, so I don't really care about any data loss but I wanted to raise the bug in case there is a fundamental reason this is happening and see if there should be some flow changes to mitigate the problem.

What was expected?

I expected system to keep rebooting properly.

I also think the recovery key flow is really sub-optimal. I wasn't reminded on first boot to get a recovery key, or save it anywhere.

I realize this is a lot of work; but I would think a better flow for the recovery key would be a QR code during installer that could be enrolled into a TOTP application like Google Authenticator or Microsoft Authenticator. If you need to activate a recovery key flow for any reason it would be a lot easier to whip out your phone and get a TOTP key instead of a static recovery key that you could more easily lose or not be notified to get/save.

Steps to reproduce

1. Turn on secure boot
2. Install ubuntu 23.10 beta with FDE enabled
3. Boot system
4. Reboot system

Additional context

Since I can't get to a shell, I don't have a lot of recourse to figure out what actually went wrong.

[superm1]

BTW those other Invalid config param messages observed above although loud are a red herring. They are because the Ubuntu kernel is missing the fix to set them to the appropriate error level.

[superm1]

While the system was in this state, I booted off the USB live key to try to reinstall with FDE. I couldn't but there was this error:

CORE_BOOT_ENCRYPTION_UNAVAILABLE: not encrypting device storage as checking TPM gave: the TPM is in DA lockout mode

I cleared TPM in BIOS and then I could reinstall with FDE again.

[mwhudson]

Do you have absolute enabled in the firmware?

[superm1]

Do you have absolute enabled in the firmware?

I just double checked and there is no support for Computrace / Absolute.

[conromia]

Same thing happening to me on the first reboot from the installer, so I can never record the recovery key. Is there a way of getting that key straight after install before rebooting?

(MSI X570 Mobo)

[WizardBit]

Oddly enough I was able to reboot without a problem for the last 5 days, but today when I booted up I got this same message to enter my recovery key. I agree that there should be a prompt during install to take note of the recovery key. TOTP is a great idea too.

[Mafoelffen1]

<<I am not connected with Canonical, nor am I a contributor here>>

@conromia -- Continue Exploring > from a terminal: sudo snap recovery --show-keys I remember that "that" is shown as a message in the Flutter Installer during the installation, to tell the user that "that" is what they need to do to get the recovery key...

There is still a problem, even if you do have the recovery key for the 23.10.1 "TPM backed LUKS" install. Just like this, I don't know that they are going to look at as a Bug or issue, but that they made a decision path to do some things in a certain way.

The key they call a "recovery key" is NOT the stored key in the LUKS2 key-slot. Rather, they use an algorithm to store the key in a raw hex format, from the recovery key. So the recovery key is really just an "interpreted key" that looks similar to a UUID. For example, the key revealed through the command: sudo snap recovery --show-keys Which returns something like this: recovery: NNNNN-NNNNN-NNNNN-NNNNN-NNNNN-NNNNN-NNNNN-NNNNN with "N" being a Number. (I guess they thought that a number would be easier to enter from a numeric keypad.) What is stored within the key slot is a raw hex key-file.

Why didn't they just add that to the key-slot directly? I do not speak for them. I am not connected to them. I guess they thought that the added complexity would add more security. But that adds another issue, mentioned here, and in this Launchpad Bug Report: launchpad: #2039741 TPM Backed install does not create valid LUKS recovery key

The current issue there, is that there was no way to change or add a key to the LUKS container. If the TPM fails, or the TPM was cleared, as in a fwupdate, the user was locked out the the LUKS container. That key-file is also required to re-enroll the key to the TPM. Or as brought up by this issue, if the user does not have that recovery key... That key is not the real key to manually unlock the LUKS2 container to recover the system.

I (we) found a way in... That is, if you have the recovery key. What we did, was to use that original code with that algorithm to re-encode the key to it's raw hex key format and store it as a key-file (stored somewhere securely), to be able to use it to unlock the LUKS container, and to be able to add new keys to the key-slots.

I documented that process in that Bug Report at Launchpad. I then came up with a script to automate the process of using that key-file for unlocking the LUKS container, adding more keys, and re-enrolling the TPM...

But: That process to do that is still above the skill level of a normal user. And an additional tool set has to be installed to do that.

I note that I have a question here, that I do need answered from the team here to help support Ubuntu Users, and it has been ignored, and not even a single reply in the 3 weeks since it was posted. I really feel "THAT" is an issue here also. Note that no-one at Launchpad addressed that ubuntu-desktop-installer issue there for that Bug Report. ""crickets:: Nor are there any responses here in Issues from anyone from the Canonical Team that I can see(???)

So where is the place to report issues and Bugs? 'apt-cache' says Launchpad. But is it not being covered there, because ubuntu-desktop-installer is a Snap? There seems to be confusion from lack of guidance and undefined territories.

[ghost]

Reproducable on first boot.

i5-9500 gigabyte gaming Z390 UEFI, with CSM disabled intel PTT enabled, tpm 2.0 mode

[Jarartur]

Yeah, happened to me too on a fresh install on Lenovo ThinkPad T14 AMD Gen 1.