TPM/FDE progress for Ubuntu 25.10

[didrocks]

As announced in Ubuntu Desktop 25.10 - The Questing Quokka Roadmap post, one of the feature we want to develop on this cycle is our TPM/FDE implementation for Ubuntu 25.10.

TPM/FDE in a nutshell

So, first, what is this about? FDE stands for Full Disk Encryption, providing you a way to ensure that all your content on disk is encrypted and inaccessible at rest. We offer a traditional FDE option for many years in Ubuntu and it’s available during installation:

You can then define a passphrase to unlock the disk, before the system boots.

So, what’s different here? TPM, or Trusted Platform Module is a chip (it can be implemented in pure software too) that you find in most modern computing units. This platform helps to ensure the integrity of a platform during boot time. It means that it will measure most of the software and firmware that are running before the operating system (Ubuntu here) starts, alongside some critical components of the early boot of it, and will only allow unlock the encrypted disk under the conditions they assert a given system state. It needs tight cooperation with the operating system to secure this functionality. With all this, you can ensure that your hardware and early firmware/software are the ones you trusted when you did your installation and have not been tampered with afterwards. It also means that the disk will not be readable on another device or if you swap parts of your hardware (but you can still use the recovery key in that case, more on that later).

Please note that this feature is considered experimental on Ubuntu 25.10. This is clearly something you shouldn’t (yet) install on a production environment. However, you can try and play with it on any system you know you can recover your data on. We’ll consider you are now warned about what to do wisely :). Our goal is to progress, collect feedback and work on this set of capabilities during the following development cycles.

Let’s now illustrate the main use cases and features that will be available in Ubuntu 25.10. Not all of them fully landed yet as questing is still in development, so stay tuned!

Better TPM safety and configuration detection.

First thing to note is that we now have more fine-grained checks to ensure that enabling TPM/FDE can be done in a safe and controlled environment. Our goal is to remove a false sense of security due to misconfiguration of the hardware or to fail post-installation.

Under Advanced options on the Encryption and file system screen, you can only select the TPM installation if we detect that your system is ok to run with it (new enough version of the TPM, no known unpatched vulnerabilities, proper configuration…). Under those conditions, you will be able to choose the Use hardware-backed encryption option:

If we detect that anything would prevent this installation to be successful in a trusted manner, we will then print (sometimes a technical) warning:

Or another example:

In the future (post 25.10), we will expand those with Actions that either provide a recommendation of something that has to be done manually (like enabling Secure Boot) or by something that could be performed directly by snapd, like clearing out the TPM, after you gave your consent.

What does it mean for our users who tried TPM/FDE before? It may be that previously allowed installation configurations are more restricted now as deemed not to be safe enough. This detection can have some false positives, as it’s heavily hardware dependent and we need to know what it gives us in the real field (and not only from the TPM specifications which might be partially implemented by the hardware manufacturer).

We plan to do a call for testing with some extra tools for volunteers to run on their setup so that we can collect feedback of successful configuration and what is preventing other types of installation. Subscribe to this thread or lurk our Ubuntu discourse near the 25.10 release next October for such a call if you are interested to help with that effort! That will be invaluable feedback, helping us getting an understanding of the hardware configuration available in the wild and be confident when we will ship it as a stable feature!

Recovery key

When we install a TPM/FDE system, we also generate a recovery key. What is this for?
The recovery key is used to bypass the TPM completely (you can think of a derived LUKS passphrase, for the more technophils). This key can be useful in many cases:

• When you upgrade some of your machine firmwares (more on that later)
• When you change parts of your critical hardware changing the measurements
• When you don’t remember your passphrase

So it’s “key” to save it somewhere. To hilight its imporance, on the last installer screen, you will get it displayed front and center, telling you to either write it somewhere on real paper, save it in file outside of the live system (we have some checks to prevent you doing that and shooting yourself in your foot ;)), or display it as a QR code.

Once you acknowledge having done that, you will be able to reboot to your shiny new hardware-backed FDE installation!

Passphrases

However, there is probably another TPM/FDE related option you noticed: passphrase support.

With traditional TPM usage, the disk is unlocked when the TPM state is the expected one, meaning that your hardware and software is trusted. This is a transparent process (no additional user input needed) with a huge gain in terms of security.

Optionally, you can opt in to use a passphrase in addition to the TPM. Note that this is different from traditional Full Disk Encryption without TPM: the disk will unlock only if the TPM state is the expected one and after you provide your passphrase! You thus have a double protection (the TPM confirms the state of the system, but only you, knowing your passphrase can fully unlock it).

This can be setup during the installation and you will informed of the strength of your passphrase:

This passphrase will be prompted every time you boot your machine:

If you don’t remember the passphrase, you can always use the recovery key that you have safely written down and kept secure (you did write it, right? :)).

You can change your passphrase in the new Security Center panel dedicated to TPM/FDE. It provides a similar user experience than the installer. For the time being, you have to enter your previous passphrase to change it, but an option with admin support (asking for the system admin password, but not the previous passphrase) will be soon available, but potentially, post 25.10.

Firmware and hardware updates

Another point is the advanced integration with our firmware updates UI. For updates like the DBX (secure boot signatures database) updates, where snapd can predict the next TPM state, this is fully transparent. You will upgrade, reboot and won’t be asked for anything else.

However, for other kinds of updates like new firmwares or hardware replacement, we can’t know in advance what will be the new state of TPM on boot. As such, we will request you enter the recovery key to “stamp” the new state as valid and trusted. Then, this becomes the new reference and any followup reboots won’t ask for your recovery key anymore and will use the new TPM state as a reference.

Of course, you should be suspicious if the recovery key is prompted at boot without you being aware of any firmware update or hardware change. This feature is here to help you.

As again we want to protect our users to not end up in a situation where they update some firmware without knowing their recovery key. This would mean otherwise that they can’t reboot their machine as it will prompt for the recovery key they don’t have handy. So, we double check by asking for it before applying any update in the firmware updater! Of course, this additional verification is only done when required, so not when we can predict the next TPM state like on DBX update.

Another use case is firmware upgrade impacting other TPM-related installation even if your Ubuntu installation is not TPM/FDE enabled. For instance, if you have another operating system like Windows with BitLocker installed on your machine, and you update some firmware or DBX from your Ubuntu system, Windows will prompt you for your BitLocker recovery key on next boot. We display a warning before letting the user upgrade their firmware if we detect such a situation.

Recovery key replacement

Now that you understand that your recovery key is very important to your TPM/FDE system, what happens if your system booted successfully, but you don’t remember or lost your recovery key?

Fortunately, we have a solution for you: the security center offers you to regenerate a new one if you are an administrator on your system. Keep this new one safe and secure.

Extensive end to end tests

We are building an extensive end to end testsuite running on both virtual and physical machines (as it should be clear now that the TPM is highly hardware-dependent) to ensure all those user stories are covered. We understand our responsibility as bugs could potentially lock you out of your data and we don’t want to corner you in that situation. You always have your recovery key anyway to bypass the TPM and recover them, so for the last time, keep it safely written and protected!

Documentation

The documentation is currently being updated to integrate TPM/FDE information with all the former points. We aim to have a good technical and a more user oriented ones when we will release it as a stable feature in our general Ubuntu documentation.

What about binary drivers, like nvidia?

The support for such drivers is still in progress, relying on a feature named snap components. When you install a TPM/FDE system, the kernel itself is in a snap and this is completely transparent to the end user! However, this creates unique challenges to expose the drivers to the rest of the system. Work on this is still in progress in that area and we hope to have something available by the end of the cycle.

In summary

Those are the most prominent features that should be available in the incoming Ubuntu 25.10 release. A lot of more fine-grained features have not been detailed here, like TPM state report in the security center, different levels of entropy detection for your chosen passphrase…

Keep in mind that everything described above are currently landing in questing and are not yet fully functional out of the box. For instance, as of today, some manual snap connections are still needed and some polkit files need a manual copy until the next snapd release. We will make the call for testing closer to the 25.10 release.

A lot still needs to be done, like a better UI on boot for asking passphrase/recovery key interchangeably, PIN support, administrative tooling, help the user to enable and reconfigure their system to be TPM/FDE enabled… But the basics that are hitting Ubuntu 25.10 are solid and implemented.

I hope this gives you a better understanding of where we are going with TPM FDE on Ubuntu and gets you equally excited about it as we are!

[SimbiotVenom]

This is great solution, please ping me for testing!
Will the mentioned experimental functionality update also backported to Ubuntu 24.04.3?

[taosecurity]

This is great to see. Thank you for working on it. I apologize if this is the wrong place to ask this question, but can you comment from the Ubuntu perspective on this article?

And how can Ubuntu users query their system to see what secure boot certificates are in use?

Thank you again.

Linux and Secure Boot certificate expiration

https://lwn.net/Articles/1029767/

" Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.

Mateus Rodrigues Costa raised the issue on the Fedora devel mailing list on July 8. He had noticed a warning that came with ““this month’s Windows 11 cumulative update””; it talked about Secure Boot certificates that are scheduled to expire starting in June 2026. Those particular certificates are separate from the one used for shim, which expires much sooner. In any case, the problem of certificate expiration is one that the Linux world will need to tackle.

The situation is rather complicated. Daniel P. Berrangé pointed to a page at the Linux Vendor Firmware Service (LVFS) site that describes it. LVFS is the home of fwupd and other tools that are used to update system firmware from Linux. LVFS and fwupd are the subject of an LWN article from 2020.

There are multiple moving parts to the problem. In order to do a Secure Boot into the Linux kernel, the UEFI boot process requires the first-stage bootloader to be signed with a key in the firmware database that has not expired. Those keys are contained in certificates, which have other information, such as an expiration date and signature(s). The certificate expiration should largely only be a problem when installing a new distribution on a Secure Boot system; the shim that gets installed will have distribution-specific keys and can act as the root of trust for running other programs (e.g. GRUB) using those keys.

Currently, shim is signed with a Microsoft key from 2011 that expires on September 11. Past that point, installation media will no longer boot unless it has an updated shim that is signed with the Microsoft 2023 UEFI key for third-parties (which is different than the specific key mentioned in the Windows update). Any installed distribution should have a bootloader signed with its own key that will continue to boot.

But there are lots of systems out there with a firmware database that lacks Microsoft’s new key, some have both old and new keys, while there are likely some that only have the new key and cannot Secure Boot Linux installation media at all at this point. Vendors can (and hopefully most will) provide firmware updates that add the new key, and installation media can be created with a shim signed by it, but those updates have to be installed on systems. That’s where LVFS and fwupd come in.

LVFS is a repository of vendor-firmware updates of various sorts, which fwupd and other tools can use to install the pieces that are needed into the firmware from Linux. Berrangé noted that older versions of fwupd were unable to solve all of the problems, ““but recent releases have been enhanced to handle the updates that Linux users will need to see, which should mitigate the worst of the impact””. There may still be a bit of a bumpy ride, however: ““Users should be ‘aware’ of the potential for trouble, but hopefully the worst of the ‘worry’ part is handled by the OS vendors and maintainers.””
LVFS creator and maintainer Richard Hughes agreed, noting that there were various ways that people’s systems would be able to get updated Secure Boot functionality. A full firmware update might be provided by the vendor, which would (presumably) add the new database, including the new Microsoft key. Another avenue would be a “key exchange key” (KEK) update, which is a vendor-specific key that is signed by the Microsoft key; it can be used by fwupd to update the database with the new key. But there are some caveats:

The KEK updates are going out at ~98% success, and db update is ~99% success -- but even 1% multiplied by millions of people is a fair few failures to deploy -- the "failed to write efivarfs" thing. What fixes it for some people is rebooting and clearing the BIOS to factory defaults -- this has the effect of triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update. The older your BIOS the more likely you are to hit this. 

Hughes is referring to a known problem with space for new EFI variables.

For systems where the vendor provides no updates, disabling Secure Boot may be the only option to allow a new install. In a few short months, all existing installation images and media will not be installable with Secure Boot—that may already be true for systems that only have the new key. Secure Boot installation just got that much more complicated.

Beyond that, though, is the possibility of mistakes or problems with the vendor updates. Hughes pointed out that at least one manufacturer has lost access to the private part of its platform key (PK), which is a vendor-specific key burned into the hardware when it is made. That means the platform keys in the hardware need to be changed, which is uncharted water and ““a terrible idea from an attestation point of view””. In addition, as Gerd Hoffman pointed out, the KEK update process is new as well: ““a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn’t work””.

The thread has multiple reports on the Secure Boot certificates on various hardware models, as well as reports of updates to the KEK and database. One thing that is not entirely clear is whether the firmware implementations will actually enforce the expiration date on the 2011 key. A working system with a functional trust-chain based on that key might continue to work with a shim signed with that key, even after September. Any shim updates, for, say, security problems, would not be able to be signed with the old key, however—Microsoft will not sign anything using the expired key. That may lead to a “solution” of sorts, as Adam Williamson said:

In theory wouldn't we also have the option to ship an old shim for such cases? If the whole chain is old it should work, right? Of course, we'd then need some heuristic to figure out if we're on the old MS cert and install the old shim... 

He said that it may not really make sense and users should just disable Secure Boot. Hoffman agreed with all of that, but pointed out the problem with shim updates: ““Continuing running shim with known security bugs makes it [kinda] pointless to have secure boot turned on””.

All in all, it seems like the Linux world is doing the best it can under the circumstances—as is so often the case when it comes to hardware from vendors that mostly care about Windows. Given that the Secure Boot root-of-trust keys (both the platform key and the signing key) are under the control of vendors—Microsoft and the hardware makers—it is always going to be a bit of a struggle to keep up. Since older hardware is something that Linux and distributions explicitly support, while the other vendors have long since moved on to the latest shiny, it was clearly going to lead to some tension there. One can only hope that the ride is as smooth as it can be."

[ogra]

The KEK databases are regularly updated … see a recent discussion here when recently the older MS keys got replaced:

Fwupdmgr offers KEK CA updates from 2011 to 2023

Ubuntu Version: 24.04, 25.04, 25.10 Desktop Environment GNOME Problem Description: fwupdmgr offers KEK CA updates from 2011 to 2023. What is KEK CA? what is it needed? I see several problems regarding this online, I don’t have windows, just multiboot with various versions of Ubuntu and Debian. do I need to update it? Thank you. Relevant System Information: corrado@corrado-ns6-qq-0625:~$ inxi -SMxc System: Host: corrado-ns6-qq-0625 Kernel: 6.14.0-15-generic arch: x86_64 bits: 64 com…

As long as you keep your Ubuntu system up to date you should always get the correct keys and bits needed …

[taosecurity]

Excellent, thank you very much!

[didrocks]

@SimbiotVenom

Will the mentioned experimental functionality update also backported to Ubuntu 24.04.3?

Unfortunately, this is quite unlikely. Backporting all those pieces are quite high risk, hence our goal is definitively our next LTS. No backport on experimental features is planned so far.

[aschultz]

Will this support SED drives or is it for CPU based encryption only?

[mlorenzo]

Exactly. Hopefully we will see the option to use either:

cryptsetup --hw-opal
cryptsetup --hw-opal-only

[lproven]

Questions re 3 things that the article does not make clear.

1. You say the setup will use UKI kernel images, is that right? How does that work with snap-packaged kernels?
2. This will obviously require a TPM chip, and that it is enabled. Does it require a TPM version 2 chip like Windows 11?
3. I think it will, but does this require the user to have Secure Boot turned on?

[ogra]

I haven’t used the UbuntuCore implementation on desktop yet, but since they are largely identical:

1. grub loop mounts the squashfs (probably verifies the GPG signature of it at that point, not sure) and simply loads the kernel.img file from it … I haven’t seen the exact spec for our UKI implementation, but i guess you will still use grub to chainload it instead of directly loading from UEFI here which should effectively not make any difference in the process apart from the content of the kernel.img file that gets loaded in the end…

2. Ubuntu always required TPM v2, 1.x is known to be insecure and broken so I doubt we’ll ever support it.

3. Yes, without a full chain of trust TPM/FDE does not make sense (if you can stop the boot before your disk gets decrypted and manually fire off brute force attacks the whole concept is moot)

[lproven]

Thanks @ogra!

Personally I do not use TPM, Secure Boot or disk encryption, and I disable all these things on all my machines. In fact I think I only own 1 computer with a TPM chip at all. So I didn’t know this. Thanks.

[schneeland]

Great to hear things are progressing for TPM-based FDE! I hope things will also work out w.r.t. the proprietary Nvidia drivers.

[kmille]

Hey @ogra,

I have some questions about Ubuntu’s TPM implementation:

1. Are there any docs about how Ubuntu uses the TPM? I would like to learn about the design and why you have it chosen. I use system-cryptenroll. When I use cryptsetup luksDump, I can see which PCRs are used. I tried this on an Ubuntu VM that was encrypted by a TPM, but I could not find any useful metadata in the luks slot. Also, it looks like you use some levels of indirection. It would be nice if you could share your thoughts about this (like which PCRs do you use and why).

2. Can you please share your implementation when enrolling/unsealing the disk? The code is probably somewhere online, but you’re way faster than me finding it.

3. Personally, I like TPMs. But in practice, I think they are useless:

However, for other kinds of updates like new firmwares or hardware replacement, we can’t know in advance what will be the new state of TPM on boot. As such, we will request you enter the recovery key to “stamp” the new state as valid and trusted.
Of course, you should be suspicious if the recovery key is prompted at boot without you being aware of any firmware update or hardware change.

What do you think people will do when they got backdoored at this point? In theory, they should re-install the OS and restore a backup. In practice, they will just enter the recovery key and hope they won’t get asked in the future. People are stressed, have a lot of things to do and want to have their tech just work. Also, if no pre-boot authentication is used, an attacker has an unlimited number of tries to perform cold boot attacks. They can just remove the RAM and put into a controlled Laptop. Until they succeed.

Thank you!

[neurer]

Gave ubuntu-25.10-snapshot3-desktop-amd64.iso a whirl on a Thinkpad X390 and get this:

sudo mokutil --sb-state [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"
SecureBoot enabled
UEFI

sudo tpm2_getcap properties-fixed
TPM2_PT_FAMILY_INDICATOR:
  raw: 0x322E3000
  value: "2.0"
TPM2_PT_LEVEL:
  raw: 0
TPM2_PT_REVISION:
  raw: 0x8A
  value: 1.38
TPM2_PT_DAY_OF_YEAR:
  raw: 0x12F
TPM2_PT_YEAR:
  raw: 0x7E3
TPM2_PT_MANUFACTURER:
  raw: 0x4E544300
  value: "NTC"
TPM2_PT_VENDOR_STRING_1:
  raw: 0x4E504354
  value: "NPCT"
TPM2_PT_VENDOR_STRING_2:
  raw: 0x37357800
  value: "75x"
TPM2_PT_VENDOR_STRING_3:
  raw: 0x22212134
  value: ""!!4"
TPM2_PT_VENDOR_STRING_4:
  raw: 0x726C7300
  value: "rls"
TPM2_PT_VENDOR_TPM_TYPE:
  raw: 0x0
TPM2_PT_FIRMWARE_VERSION_1:
  raw: 0x70002
TPM2_PT_FIRMWARE_VERSION_2:
  raw: 0x20000
TPM2_PT_INPUT_BUFFER:
  raw: 0x400
TPM2_PT_HR_TRANSIENT_MIN:
  raw: 0x5
TPM2_PT_HR_PERSISTENT_MIN:
  raw: 0x7
TPM2_PT_HR_LOADED_MIN:
  raw: 0x5
TPM2_PT_ACTIVE_SESSIONS_MAX:
  raw: 0x40
TPM2_PT_PCR_COUNT:
  raw: 0x18
TPM2_PT_PCR_SELECT_MIN:
  raw: 0x3
TPM2_PT_CONTEXT_GAP_MAX:
  raw: 0xFF
TPM2_PT_NV_COUNTERS_MAX:
  raw: 0x0
TPM2_PT_NV_INDEX_MAX:
  raw: 0x800
TPM2_PT_MEMORY:
  raw: 0x6
TPM2_PT_CLOCK_UPDATE:
  raw: 0x400000
TPM2_PT_CONTEXT_HASH:
  raw: 0xC
TPM2_PT_CONTEXT_SYM:
  raw: 0x6
TPM2_PT_CONTEXT_SYM_SIZE:
  raw: 0x100
TPM2_PT_ORDERLY_COUNT:
  raw: 0xFF
TPM2_PT_MAX_COMMAND_SIZE:
  raw: 0x800
TPM2_PT_MAX_RESPONSE_SIZE:
  raw: 0x800
TPM2_PT_MAX_DIGEST:
  raw: 0x30
TPM2_PT_MAX_OBJECT_CONTEXT:
  raw: 0x714
TPM2_PT_MAX_SESSION_CONTEXT:
  raw: 0x148
TPM2_PT_PS_FAMILY_INDICATOR:
  raw: 0x1
TPM2_PT_PS_LEVEL:
  raw: 0x0
TPM2_PT_PS_REVISION:
  raw: 0x104
TPM2_PT_PS_DAY_OF_YEAR:
  raw: 0x0
TPM2_PT_PS_YEAR:
  raw: 0x0
TPM2_PT_SPLIT_MAX:
  raw: 0x80
TPM2_PT_TOTAL_COMMANDS:
  raw: 0x71
TPM2_PT_LIBRARY_COMMANDS:
  raw: 0x68
TPM2_PT_VENDOR_COMMANDS:
  raw: 0x9
TPM2_PT_NV_BUFFER_MAX:
  raw: 0x400
TPM2_PT_MODES:
  raw: 0x1
  value: TPMA_MODES_FIPS_140_2

Any pointers are appreciated.

[didrocks]

Thanks for trying the feature. Do you mind opening a bug against GitHub - canonical/secboot so that we follow up there? (this is one of the case where having the specific binary we mentioned above will help getting all needed info to see if this is expected or not)

[neurer]

Sure, there you go: Cannot check TPM discreteness using Intel BootGuard status: no TPM2 device is available · Issue #455 · canonical/secboot · GitHub

[SimbiotVenom]

For Dell Latitude 5520
Ubuntu 25.10 Snapshot 3 is blocking TPM FDE, since I must disable Absolute in UEFI settings.
But today I tested Ubuntu 24.04.3, and it installed with Absolute enabled settings without issues.

At the same time, on HP EliteBook 850 G5/G7/G8/G10 and G11 models, if Absolute is enabled in UEFI settings, then Ubuntu 24.04.3 will ask for the Recovery Key after the first OS reboot.

On all devices, I updated the UEFI Firmware to the latest available.
More interestingly, even Ubuntu 25.10 on HP models asks not to disable Absolute, but to disable DA lockout mode, and the only option to bypass this situation is resetting the security settings, which will also initiate the clear TPM option.