TPM Backed install does not create valid LUKS recovery key

[Mike Ferreira]

As I was helping another User here: https://ubuntuforums.org/showthread.php?t=2491692

I recreated different test cases... Both LUKS encrypted.

In the first test case I created LVM encryted VM.

In the second I recreated the condition the User was facing on a VM (TPM Backed Encrytion). He installed 23.10 from the standard ISO, and use Experimental TPM backed Encrytion. After the install, he received an fwupdate firmware update... Which cleared his TPM, and he was locked out of his installed system. He used his recovery key to get in, that was generated via

Code:
sudo snap recover --show-keys

On boot, he would be prompted that the TPM key failed and to enter his passphrase. He enters the recovery Key and is let in...

I verified that this works.

In the past, the recovery key for LVM on LUKS is entered into the LUKS keyslots as keyslot #2... I can boot from a LiveUSB, unlock the LUKS container with the recovery key entered in as the passphrase...

In the New Experimental TPM backed encryption layout, it creates two LUKS volumes o /dev/sda3 & /dev/sda4... I can see via a dump, that there are 2 keyslots being used by each LUKS container. But neither can be unlocked via the Snap recovery key. It returns:

"No key available with this passphrase."

I know that previously, pre-23.04, with the canned ZFS Encrypted scripts created a LUKS volume, that had to be unlocked with the passphrase, then mouted to /dev/mapper as /dev/mapper/zfskey, which in turn contained system.key, which was the real passphrase for the ZFS native encryption...

This is not seem to be the case, as far as I can see for this new TPM backed install. I cannot see nother volume, containing another key, that needs to be unlocked with the Snap Recovery key, but I suspect this is what is going on somewhere under the covers.

Usually in a LUKS volume install, you use the recovery key as a passphrase to add or change keys... I can use the LVM2 recovery key to add/change passphrases, add keyfiles, and add a binary key, with I caqn dd to a TPM, to auto-unlock on boot... If I install manually I can still do this.

In the ubuntu-desktop-installer installed TPM backed encryption installation-- At present, if something goes wrong with the TPM, as demonstrated with this user getting a fwudate, or a TPM seal error during a kernel update, the user cannot replace the TPM key in the encrypted volume, that they can then seal to the TPM, because there is no valid passphrase key accessible, with the Snap recovery key...

So the only other logical recovery it to reinstall again fresh(?)

ProblemType: Bug
DistroRelease: Ubuntu 23.10
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.486
CloudArchitecture: x86_64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud)
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 18 21:45:20 2023
LiveMediaBuild: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
Snap: ubuntu-desktop-installer 0+git.0ea1f031 ()
SnapChanges: no changes found
SnapConnections:

SnapSource: ubuntu-desktop-installer
SubiquityLog: Error: [Errno 13] Permission denied: '/var/log/installer/subiquity-server-debug.log.2056'
UpgradeStatus: No upgrade log present (probably fresh install)

[ichbinjasokreativ (ichbinjasokreativ)]

Can confirm that this is an issue.

[Mike Ferreira (mafoelffen)]

We found a way in... (https://lemmy.world/post/7029429)

It seems that in key-slot 1 of each of the two LUKS containers, that key is translated from the recovery key into a translated hex key, that is stored within key-slot 1 of each of the containers.

https://<email address hidden> came up with a GO script:
https://pastebin.com/WdFNRb7C

Derived from this post at the Forums of snapcraft:
https://forum.snapcraft.io/t/uc20-fde-boot-flow/27895/13

Which uses the original ParseRecoveryKey():
https://github.com/snapcore/secboot/blob/master/crypt.go

I had him modify the script to create a key.out key-file, as during my tests, it was found to be in raw hex format.

Using that key-file, I can unlock the LUKS containers, and add new keys to them. So now, there is a work-around to be able to add new passphrases, and be able to re-enroll a TPM with this type of failure.

[Daniel Meier (danidd)]

The issue exists furthermore.
I test it on Notebooks from Lenovo. X13Gen4 does not work. X280 with Bios from 2022 does not work, but X280 with Bios from 2020 works fine. I testet it with daily images from 20240408/09 and with images from Ubuntu 23.10
Does TPMFDE need a old Bios?

@Mike the way in lemmy.world I cant verified. Any people have delete own comments