Autoinstall with TPM FDE (LUKS) support on 24.04 Server

Ubuntu Version:
24.04 Server

Desktop Environment (if applicable):
NA

Problem Description:
I’m trying to add TPM2/LUKS support via autoinstall

How to get a clean working install of ubuntu server via autoinstall.yaml with TPM2 support for the LUKS partition automatic decryption?

For clarity, I started of with a fully working autoinstall, and i’m trying to add an encrypted disk with a password in the autoinstall, this works for the creation of the partition and every following reboot the password is required to continue booting. So far so good.

Now the goal is to have the system boot automatic with a password that is stored in the TPM. Via some workaround for initramfs and missing TPM support, I install dracut and tpm2tools so I can get the system to boot. This works except on the very first boot when it switches from “live cd” to the actual host. In itself this is explained because I have the workaround in the cloudinit/user-data phase of the autoinstall (and at the time of switching from live cd to host we haven’t reached this part of autoinstall yet). If i try to do the same things in the “late-commands” section with all the same commands (adapted for ‘/target’ directory change) it fails. i’ve tried using the ‘curtain in-target - - …’ approach but to no avail.

Can someone point me in the right direction for how to continue?

Side question: Would waiting a couple of months for ubuntu server 26.xx make a difference here?

Please find all commands below :

storage section of autoinstall.yaml (working)

  storage:
    layout:
      name: lvm
      password: testing123
  user-data: 
    runcmd:
      #LUKS
      - apt install -y dracut tpm2-tools
      - systemd-cryptenroll --wipe-slot=tpm2
      - systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --unlock-key-file=/opt/luks.key /dev/nvme0n1p3
      - sed -i 's/luks/luks,tpm2-device=auto/' /etc/crypttab
      - echo 'hostonly="yes"' > /etc/dracut.conf.d/tpm2.conf
      - echo 'add_dracutmodules=" tpm2-tss "' >> /etc/dracut.conf.d/tpm2.conf
      - dpkg-reconfigure linux-image-$(uname -r)

fyi: /opt/luks.key contains the correct key (‘testing123‘)

Not working solution:

late-commands:
      - curtin in-target -- apt install -y dracut tpm2-tools
      - curtin in-target -- 'systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --unlock-key-file=/opt/luks.key /dev/nvme0n1p3'
      - sed -i 's/luks/luks,tpm2-device=auto/' /target/etc/crypttab
      - echo 'hostonly="yes"' > /target/etc/dracut.conf.d/tpm2.conf
      - echo 'add_dracutmodules=" tpm2-tss "' >> /taget/etc/dracut.conf.d/tpm2.conf
      - curtin in-target -- dpkg-reconfigure linux-image-$(uname -r)

This ends up in the emergency shell.

Hi Kenny!
I’d like to do exactly the same thing. For my setup, I’m using Raspberry pi Compute Modules (with eMMC memory), with the TPM compute blades. I was considering doing the following thing:

  1. Autoinstalling Ubuntu on a LUKS drive in the eMMC flash memory
  2. adjusting crypttab to store the passphrase unencrypted in the /etc/crypttab or an unencrypted partition such that the partition can be automatically unlocked
  3. mounting the raspberry pi in the computer blade and logging into SSH
  4. Changing encryption key, setting up the new key in the TPM module, and removing unencrypted key.
    Haven’t figured it out yet, but somehow it must be possible to have the drive LUKS encrypted but unlocked automatically on first boot. If not, this is a chicken and the egg problem.

Not sure if this will work. Another approach is installing Ubuntu without LUKS and then doing open-heart surgery to build the LUKS drive and move all files into the encrypted partition.. This does not feel like a safe solution.

Another thing I found is adding dropbear to initramfs such that one can SSH into the machine before boot, to for example fill in the LUKS passphrase. After this is done once, the TPM can be setup to unlock the drive instead and dropbear (optionally) removed.

Just my $0.02, hope this helps. Looking forward to hear what you learn.

Turns out there is a neat provisioning tool for raspberry pis that does exactly this already using the OTP key:

Will use this for my provisioning and use TPM to secure the LUKS of my second drive. (just gotto be careful with upgrading, resigning my TPM after any change before rebooting :stuck_out_tongue:).

Maybe not useful for you, but I just thought I’d share.

Good luck!

I have successfully set up my notebook, which is not suitable for the “FDE with TPM” under Ubuntu 25.10 by the installation routine, manually according to this guide:

https://blog.fernvenue.com/archives/debian-with-luks-and-tpm-auto-decryption/

(This differs in some points from the procedure of the theme starter.)

But then it turned out that the live system of Ubuntu 25.10 automatically decrypted the encrypted partition based on the key in the TPM without a password query. In my opinion, this means that full encryption is being undermined and completely superfluous. Therefore, I rejected the approach with TPM again. – Better to decrypt manually with password every day than to have to fear a live system.

BTW: What is the point of encrypting a server? As soon as it is operational, it is decrypted. It is the task of a server to be accessible. So full encryption is actually useless. If data are to be protected, then they must be placed in encrypted containers and only unlocked if necessary exclusively for the duration of access.

jm2c

puts his CISSP+ISSAP hat on

For numerous policy reasons at the enterprise level, it is necessary that “data at rest” is encrypted. Which is why for servers encryption should be done.

In the modern Enterprise, we see quite a lot of use of virtualization and containerization. For containers, they tend to run on a specific host and require encryption on the host level to protect that data at rest. For individual VMs running lots of servers (read: 100s or 1000s of servers), you’re correct it is usually not feasible to encrypt every server VM, but it is possible (usually with the host system or external network storage with on disk encryption enabled or in VMware environment vSAN, etc.) to encrypt the underlying storage mechanisms on the systems itself for compliance.

(CIS and other benchmarks say servers should be encrypted for data at rest. At scale this is not feasible for large deployment setups, so a mitigating control for that is to encrypt the underlying system storage that holds the VM virtual disks, etc. for control of data at rest)

As a side note, you could put a Tang server on the network and have that do the decryption for you

I think any further discussion on ‘alternatives’ for encryption, decryption, etc. is offtopic to this post. OP is asking how to use TPM2/LUKS and FDE with autoinstall scripts. Tang server integration, etc. go beyond that, and is a bit off topic for this thread.

Hence the “side note” prefix