Canonical dusts off TPM encryption for Ubuntu 25.10 Canonical's Director of Engineering for Ubuntu Desktop has published a roadmap for the 25.10 release, which includes a feature that was originally planned for 23.10. Jean-Baptiste Lallement posted the Questing Quokka roadmap to Ubuntu Discourse, and one of the more interesting bits is full-disk encryption backed by the Trusted …
"When it comes to disk encryption, we agree with this XKCD. Especially the mouseover text, which those afflicted by tablets can see here. Get over yourself, nobody cares. ®"
The XKCD cartoon points out that Encryption isn't an infallible solution (like most security, it has to deal with the meat sacks it's trying to protect). And yes, most people aren't guarding life and death state secrets.
Doesn't make it bad idea. Unless we want to start to follow the logic that one might as well use 'password1' for all your accounts because passwords are fallible.
I'm still encrypting my work laptop because it costs me nothing in real terms and, if I were to lose it (accidentally or otherwise), I'd rather not have to care about it. And I'll probably lock the door when I leave my house, even if you could get through it with a crowbar in a few seconds.
> Just how do you transfer the key from the old computer?
An excellent point.
*If* you have a backup of the external keys then you *might* be able to get it to unlock and boot manually, and then you are merely faced with the fun issue of either enrolling the new keys in the new mobo's firmware, or, possibly -- and possibly rather harder -- decrypting and then re-encrypting.
Or, full backup, then recreate encrypted volumes, then restore.
The easiest option would probably be to backup all your settings, nuke and reinstall with a freshly-created encrypted disk, then restore them.
Reinstalling the user's apps is left as an additional exercise for the reader.
It does not sound like my idea of a fun way to spend a couple of days.
When using any sort of disk encryption, having an excellent, robust, *tested* backup system becomes imperative. Most people do not, of course.
Which then leads to fun questions about encrypting the backups...
It's exactly to protect disks being moved to another computer and/or being accessed using a different booted OS. That's why you need backups. Encrypted, of course.
Noone forces use to encrypt your disks. Those who do, should know the drawbacks and plan accordingly.
You can of course also setup a passphrase in another LUKS keyslot to provide an alternative way to unlock the LUKS volume, so provided a mechanism to handle either (a) the TPM failing and/or (b) moving the disk to another computer and needing a way to unlock it there.
> "Noone forces use to encrypt your disks."
Newer versions of Windows 11 turn Bitlocker encryption on by default- without making that obvious, to the best of my knowledge- if they're clean installed with an MS account associated.
This is a certainly problem if users aren't aware both of that *and* of its implications.
For one-off/"data recovery", you use the recovery code (which you did store in a secure, retrievable place, right? :O ); for transferring the disk to a new motherboard/machine I would expect a command to (re)enroll a TPM key[a], but I wouldn't expect it to be available yet.
Note that "the key" isn't what's in the TPM/what you type in the password/recovery box. "The key"(s) is(are) stored encrypted on disk, hashed/encrypted/protected by the TPM/recovery code/password. LUKS allows you to have multiple passwords that will work equally as well for each volume (8 or up to 32 depending on whether it's LUKS1 or LUKS2), and in my notebooks I use that to enter my passphrase once on boot. I only have the EFI boot partition unencrypted; GRUB stage 1 asks for my passphrase to decrypt its stage 2, and then I have a different key on the machine's initramfs which avoids Linux from asking the passphrase again.
[a]: Dunno how it works on Windows/Bitlocker, but on a machine I was setting up with dual boot I had issues with the TPM refusing to provide the decryption key; I fully expect that after entering the recovery code Windows threw away the TPM key and generated a new one.
"The current version uses a somewhat complex software stack called LUKS, short for Linux Unified Key Setup. This creates an encrypted disk entirely in software, using the Linux Logical Volume Manager (LVM)."
Nope, LUKS uses the Linux device mapper (which LVM also uses), not LVM.
You can of course layer LUKS on top of LVM or layer LVM on top of LUKS, but that's a different matter.
Indeed. LUKS and LVM are independent, but can be used together.
I think that what the quoted text is trying to say is that the Ubuntu installer, if you ask for FDE (at least, old-style, TPM-less FDE) will build a configuration that uses both.
My Ubuntu system has LVM layered on top of LUKS, but I can't recall whether the installer built that for me automagically, or I had to configure it myself.
<aside>
I've finally settled on a setup with:
1. The EFI System Partition, of course
2a. A /boot partition
2b. A small LVM volume group (VG) for Ubuntu -- /, /var, and the like (it also used to have a /usr LV until Ubuntu went the way of evil and started demanding that /usr live on the root filesystem)
3a/3b. Another boot / system-VG pair like (2), but not currently in use
4. A large volume group, taking up most of the drive, for my own stuff -- /home and whatever other filesystems I decide, in my wisdom or lack thereof, that I need.
When I next decide to do a clean O/S install instead of upgrading -- as I do every few upgrade cycles -- I'll install into (3a and 3b); i.e. the two boot/system pairs are used in an A/B upgrade strategy.
And because (4) is independent of both pairs, it sits above the fray, blissfully untouched. In theory, anyway; of course there are backups in case things go awry.
Obviously I created (4) by hand, a long time ago.
> You can of course layer LUKS on top of LVM or layer LVM on top of LUKS, but that's a different matter.
Hmm. All right. I've only used this on 3 distros and on all 3 the installer configures LUKS in conjunction with LVM, but I am willing to give you the benefit of the doubt: maybe this is just for convenience or something and it's not actually essential.
If I am _required_ to use encrypted volumes, my preferred setup is an unencrypted disk with a separate partition for `/home` which is the only thing that's encrypted. In my testing this is much easier and it performs better too.
"Hmm. All right. I've only used this on 3 distros and on all 3 the installer configures LUKS in conjunction with LVM, but I am willing to give you the benefit of the doubt: maybe this is just for convenience or something and it's not actually essential."
Benefit of the doubt? There's no doubt about it, LUKS and LVM are two distinct things that do not have to be used together.
As you've written about Alpine Linux in the past, try running "setup-disk -h" and you'll see:
"options:
-h Show this help
-e Encrypt disk
...
-L Use LVM to manage partitions
"
You could also try installing Alpine (i.e. on a VM) using either 'DISK_MODE="sys" USE_LVM=1 setup-alpine' for only LVM, or 'DISK_MODE="sys" USE_CRYPT=1 SWAP_SIZE=0 setup-alpine' for only LUKS (Alpine's setup-disk has code that auto-selects LVM if encryption is specified and swap is not disabled) which should pass these setting through to setup-disk.
For reference: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref_type=heads#L1626-1629
>I am willing to give you the benefit of the doubt
That's... not how this works. The article should strive to inform correctly, and that part was wrong.
Also, GParted not supporting LUKS and LVM is hardly news. partition-manager does support this setup, yet goes completely unmentioned, unlike Devuan which is a fringe distro completely irrelevant to the story.
If you need automatic unlocking on your Linux servers, make sure to use Network Unlock with Tang and not a TPM-only approach. If you’re on a single-user device like a laptop or personal computer you should at least use TPM+PIN or just a straight up very long passphrase. Anything less and your data is not very well protected in the event of physical hardware theft at all.
TPM-only exists to allow people who do not care about security to say “yes, we encrypt all our data with AES-256” but the moment you’re able to boot an OS that’s vulnerable to exploitation, you then can exfiltrate data. Even worse, if your computer lacks a proper method to encrypt the contents of RAM with a random key at boot time (Total Memory Encryption), you can simply boot the OS and dump the keys (remanence attack) from the RAM sticks directly, since encryption keys need to be stored in RAM for everything to work (encryption/decryption is not performed by the TPM itself). To defend against these attacks, you need a w@y to make sure auto-unlock does not happen without some kind of additional external input, even if it’s automated.
It’s worth noting even Microsoft recommends TPM+PIN for single-user devices, and to use hibernate (or to shut down) not suspend to protect against the aforementioned attacks. It should also be assumed if the computer is stolen while on that you’re knackered. Likewise, the fruit company ships with the equivalent of TPM-only security by default on Apple Silicon and considers it to be an unprotected state, essentially FileVault enablement adds a username/password requirement to unwrap keys at boot time to actually protect data properly. Canonical is positioned no differently, and Fedora, RHEL, ArchLinux have all provided Clevis for quite a while, they’ve all simply advised against TPM-only as a secure solution.
It's all down to what the use case is.
TPM only is useful if when you dispose of the hardware you separate storage from machine and send them off in different directions (e.g. for destruction). The disk content is safe when shorn from the machine. In some jurisdictions, that's a valuable legal compliance thing.
Also, in scenarios where the hardware is usually adequately physically secure but might get tampered with in extremis, the system recognising the tampering happening can simply wipe the TPM. Data automatically safe.
Most of that I agree with, but I'm wondering about this part:
"the moment you’re able to boot an OS that’s vulnerable to exploitation, you then can exfiltrate data"
I thought the whole point of a TPM is that one *can't* boot another O/S, vulnerable or otherwise (unless, of course, it also has been registered with the TPM; but before doing that, one is supposed to have ensured that the second O/S is also secure enough for one's purposes).
Willing to be corrected; my understanding of TPMs and their intricacies is strictly theoretical and rather vague. So far I've managed to avoid that tar pit.
"I thought the whole point of a TPM is that one *can't* boot another O/S, vulnerable or otherwise (unless, of course, it also has been registered with the TPM"
Nope, a TPM is effectively just secure data storage (a "poor man's" HSM). The UEFI on a computer does not rely on a TPM for booting (otherwise how would all those PCs out there without TPMs present have booted all these years?). Note I said UEFI, not UEFI Secure Boot.
AFAIK TPM is not (directly) related to UEFI Secure Boot, Secure Boot can potentially use a TPM if present but does not require one.
Bootloaders and/or Linux initramfs' can decide to use a TPM for securely storing data for them (such as data for unlocking an encrypted volume as discussed in this article). This also means that bootloaders may also not rely upon a TPM and so boot whatever OS you want regardless (i.e. Grub only added support for TPMs to its development version in recent months which is likely to be many months away becoming the next Grub release).
> Is there evidence that Ubuntu will require TPM 2.0?
No, and I did not say or imply that it will.
Ubuntu will not require any TPM at all. I doubt it ever will. There is no plan to make Ubuntu as an OS require or use a TPM.
This article is *ONLY* about a new form of full-disk encryption, and nothing else.
> Bitlocker (for just disk, not full device) is fine with TPM 1.2...
Bitlocker on Win10 does. AIUI Win11 needs TPM 2 and therefore Win11 Bitlocker needs it too.
> AIUI Win11 needs TPM 2 and therefore Win11 Bitlocker needs it too.
Win 11 does not need TPM 2.0 (in fact, it doesn't need any TPM), it's just that the installer's hardware check insists on a TPM 2.0 (as well as other hardware, neither which is actually required to run Win 11).
Bitlocker on Windows 11 doesn't care and works just as well with a TPM 1.2, the same way Windows 10 did.
I'm fine with TPM storing the keys for my disk encryption, much easier than inputting a password. And whilst there may be ways to obtain the keys from the TPM once the OS has booted, in practice it's going to be easier to guess most people's boot password than it is to have the skills and required hardware required to extract the keys from the system. Skills which I'm going to guess that your run of the mill burglar or opportunist thief doesn't have. So unless you have something of real importance on there (eg documents that would threaten national security or real cutting edge research) that would make you a target of a professional data thief, a TPM is likely to do you just fine.
Now if only Ubuntu can sort out the abysmal hibernate situation in Linux (ie so that it a. actually works, and b. doesn't hibernate to the swap file or partition that's potentially already full up, and c. is encrypted), then I might be persuaded to give it another go.
For the vast majority of users it adds unnecessary security at the expense of imposed and opaque complexity, thus increasing the likelihood of 'something going wrong' which is out of the user's control and beyond their ability to fix.
That's ridiculous. You may as well be saying the same of a login password, or house front door key. If you don't want to get locked out because you've lost your key and haven't bothered with a snuck-away spare, leave the front door unlocked.
Really? So, something I have no control over, didn't ask for, and don't need gets fitted—in fact I may be forced to buy it, and even throw away perfectly good kit because someone else insists that their product uses said something—and then the something hides the keys and demands that I make copies and hide the copies somewhere myself. Keys that are not straightforward to manage at the best of times. And if I lose them or stuff up the process I lose everything the something is supposed to protect.
We're talking about Jo Public here. It's a bloody stupid idea for general use, even if it's useful to a particular minority, i.e. at very best it should be switched off by default and only accessible to determined people, who hopefully have half a clue about managing cryptographic keys.
Hopefully this particular farrago will remain a largely academic argument so long as MS only require TMP to be present, but not activated.
But then we're still left with the egregious 'landfill' consequences of even that requirement, for all those people who slavishly feel obliged to 'upgrade' to W11.
So you designed your own front door lock then? If not, you have no control over the reliability of that lock or over access to your dwelling.
If you don't like the idea of keeping a back up of keys, either don't install Ubuntu 25.10 with FDE enabled or just be content to lose your data should it ever go wrong. You go off and do you. Everyone else is entitled to do the same, which includes not making or using computer hardware to your personal satisfaction.
I think there is a difference between losing my house keys and losing crypto keys—with one of them there is no way back. With the other I can even just kick the door in, if I can't afford a locksmith.
And we all know how prone Jo Public is to losing their house keys. Any reason to think they'll do any better with crypto keys?
I have always said, security that is more likely to foil the legitimate user than protect them is NFG. It should not be applied for such users.
I keep my TPM disabled in BIOS, because it's adversarial hardware that can only be used against me. Its purpose, other than a convenient source of keys for encryption, is to protect IP from YOU and serve as a unique way of identifying your machine to RESTRICT you from doing things, or implicate you.
If I need to test something (e.g. applications on Windows 11) I'll use a KVM virtual machine with a software emulated, fake TPM 2.
>I have always said, security that is more likely to foil the legitimate user than protect them is NFG. It should not be applied for such users.
I doubt that. I suspect more laptops are lost / stolen per day than those that suffer TPM failures leading to a user being locked out.
>I keep my TPM disabled in BIOS, because it's adversarial hardware that can only be used against me. Its purpose, other than a convenient source of keys for encryption, is to protect IP from YOU and serve as a unique way of identifying your machine to RESTRICT you from doing things, or implicate you.
You do realise that a TPM in no way enhances or degrades the ability for an operating system or software to uniquely identify your specific computer? CPUs and HDD/SDDs, NICs, monitors, graphics cards, etc. have all had unique serial numbers for decades. If software wants to keep you from accessing IP because it doesn't like it being accessed from your specific computer, it can already do that without a TPM present. And it's not like there's a permissions engine running inside the TPM on behalf of all the world's IP holders; that would be impossible (there's a lot of IP holders including, probably, yourself)
Mostly it's the other way round - for software licensing; such a unique ID is used to allow your specific computer to access the licensed software (node locked licensing, which has been a thing for at least the past 40 years). If you have no intention of using such software, the absence or presence of a TPM is not going to make any difference to you whatsoever.
> So while it's fine for a laptop, it's no help on a server.
Actually, LUKS can use a key file (instead of a password), and you can configure the key file in crypttab, which ought to be copied to initramfs. You might also be able to build this into the initramfs, keeping the initramfs stored on /boot, and unmounted at runtime -- and also with permissions making it unreadable by any non-root user.
or, If you, say, wrote some data to a USB key, and referenced that USB key by /dev/xxx path, then you could use it as a keyfile for the boot process. Then you have an encrypted disk, with non-TPM key (of really any length/complexity), that works on reboot with no user interaction. Then via udev rules you could mark this specific device as permissions 000 -- no one can access it but root (but really, how many users to you add to the `disk` group?). As an added bonus, you can back the key up (which you can't do with TPM), and LUKS as well allows you to add a master administrative key (does this TPM method? I haven't finished the article yet).
What happens if someone steals they server? They have your decryption USB key!! ... but the same is true of TPM.
I wondered if somebody would mention this.
It seems to me you can get decryption keys from (1) the TPM; (2) the keyboard (user enters password); or (3) a file on a USB drive. (Or some combination of these. If the machine controls a Doomsday Device, you might require two people to each enter their half of a password and plug in their USB keys. My car requires that a key fob be nearby; that might be more even more convenient than the USB drive.)
These would each have benefits and drawbacks, depending on your use case. As the Fine Article says, the keyboard is problematic for a server that may suffer a power failure. For that case, it's hard for me to see the benefit of the TPM over the USB drive.
For Microsoft, the TPM has the benefit of making it hard to move/copy your Windows install to another machine (as others have noted), and of providing a convenient excuse to force upgrades to Win11. I'm not really all that interested in benefits to Microsoft, though (Linux user) [0].
For, say, a laptop that travels with me, I might not mind having to plug in a USB drive when I boot it, then unplug and pocket said drive.
[0] Though I did recently acquire a pretty good non-TPM laptop relatively cheaply, and we'll doubtless see still more good deals as the WIn10-pocalyspe approaches.
"For that case, it's hard for me to see the benefit of the TPM over the USB drive."
A TPM being involved in encryption unlocking is a way to "ensure" that the computer where the unlocking is occurring is the expected computer (i.e. that the drive has not been moved, or copied, to a different computer). It doesn't protect against the computer being stolen, it doesn't protect against an unauthorised person booting the computer.
I would never rely solely on TPM-based unlocking for the above reason, I would combine it with some other additional mechanism (whether manual entry of a passphrase, network-based unlock i.e. clevis/tang, a hardware token like a Yubikey is activated, a HOTP/TOTP code is entered, or something else) similar to how MFA works.
Ridiculous but true, if you already use LVM for storage, you can't install Ubuntu 24.04 without wiping the entire disk. They describe that as "wish list", seemingly not planning to fix it.
The best you can do is install it on a new disk and then copy the volume/partition after, and fix grubby issues.
> you can't install Ubuntu 24.04 without wiping the entire disk.
I did not mention that as it was a bit outside remit of the story, but yes, that was the case years ago and I thought it still might be. I had not -- and have not, for clarity; this is a passing comment, not a researched article -- checked, but the case as I met it a decade or more back:
LUKS needs LVM, and LVM does not play nice with dual boot, and so you can't dual-boot and use LUKS.
I like dual-boot. All my computers dualboot. Even my Mac, between old and new macOS but still, 3 instances. (Live, backup, old OS.)
Anything that stops me doing this can FOAD.
"LUKS needs LVM, and LVM does not play nice with dual boot, and so you can't dual-boot and use LUKS."
In theory that's incorrect.
The actual reality of Windows installer I cannot comment on as I haven't installed Windows in decades.
Windows cannot understand/use either a LUKS volume or an LVM volume (as I mentioned in my other comment earlier LUKS does *not* need LVM, that many/most Linux distros' installers use both together would be due to a decision taken by those installers' developers).
Therefore I would expect that if you partition your HDD/SSD to have (a) a suitably sized EFI partion (ESP), (b) create another partition to be used by Windows or whatever other OS other than the one you're using LUKS and/or LVM with, and (c) create a 3rd partition (and perhaps more) to be used by the Linux distro where you want to use LUKS/LVM.
Then install Windows onto partition B, install the Linux distro onto partition C.
Thanks for the heads-up!
I was planning to do just that next week (but giving the new Ubuntu its own partition to create its own VG in, independent of my main data VG, as described in another of my comments on this article). Now I'll be sure to test it in a VM first.
I'll try to remember to report back.
For reference, here's the bug report (or rather, what looks to be one of many related ones).
The _installer_ may not support this, but you absolutely can dual-boot Ubuntu with any other OS, even if one (or both) OSes use LUKS+LVM.
You don't have to use the installer, or you can manually partition the disk to your liking before starting the installer.
Unless I've missed something, FDE with TPM without an additional password only protects against theft of the drive not against theft of the whole device. Which while better than nothing is limited.
The TPM chip is probably more useful for other use-cases.
For servers, in the past I've encrypted the partitions where sensitive data is stored and the server configured that only SSHd starts on boot. On reboot manual action is required but can be performed remotely. For the paranoid a tripwire is required for the non-encrypted parts.
I promised to report back. It's rather late now -- the party's moved on -- but for the benefit of anyone who trips across this, here's my experience.
I should note that everything I say here is with respect to a GPT-partitioned drive, though I have no reason to believe anything would be different with an MBR-partitioned one. I've described in another comment what I was trying to accomplish, but short version: my goal was to do a clean installation of Ubuntu 24.04, while preserving the drive's existing LVM-on-LUKS Ubuntu installation (and in particular, my data VG). I don't know whether things would have been different had the existing installation been LUKS-on-LVM. I rather suspect the end result would have been the same, but some of the details might have differed. And to be clear, these issues are all with the Ubuntu installers. LVM and LUKS are both very flexible tools; neither one requires the other. But as Ubuntu uses them, one's choices are a lot more limited.
In short, It's not good; it's one of those frustrating cases where "you can't get there from here".
Some time between 22.04 and 24.04, they redid the installer's partitioning tool, and the new one is a distinct step backward. *Grrr* change for change's sake *grrr*
With both the 22.04 and 24.04 installers, there are three main partitioning options: (A) Install Ubuntu alongside other partitions; (B) Erase disk and install Ubuntu; or (C) Something else. The first two provide canned setups. The third lets you configure all the partitions manually, which should let let you do pretty much whatever you want.
Great in theory; however...
First problem (which IIRC is the case with both 22.04 and 24.04): Install alongside is only offered to you if the installer detects another OS. Worse, as far as I can tell, it only searches for a list of specific OSes -- and it's a pretty short list. If it sees Windows or MacOS or a few other things, it'll offer to install alongside that. But if there are only partitions whose contents it doesn't recognize, no such luck; Erase disk and Something else are the only choices offered. It can recognize a vanilla Ubuntu installation, but not an LVM-on-LUKS one like mine, which meant Install alongside wasn't an option for me.
That's ridiculous! If there are other partitions, the installer should give me the option of keeping them intact. It shouldn't need to have the faintest clue what's on them; the mere fact of their existence should suffice (as long as there's sufficient unallocated space, which there was on my system).
But then, even if Install alongside had been available, I don't think it would have let me do what I wanted, because...
Second problem: Install alongside -- assuming you're offered it -- doesn't understand either LVM or LUKS; it only knows how to do basic GPT (or presumably MBR) partitions and put filesystems directly on them. The only option to have the installer create an LVM and/or LUKS setup for you is in Erase disk, where you get Use LVM and Use LVM and encryption checkboxes.
Even here, you can only create the most basic of setups. That would be acceptable, if not ideal, except that...
Third problem: The Something else option got dumber. In 22.04, as noted, the installer can't create any but the simplest LVM/LUKS setup, but Something else serves as an escape hatch. You can (1) get a root shell before launching the installer, courtesy of the Try Ubuntu option, (2) create your partitions manually, along with the LUKS[*] and/or LVM[**] configuration you want on top of them, (3) launch the installer, (4), choose Something else in the partitioner, and finally (5) tell it to use the LVs and/or encrypted volumes you created at step #2. Step #5 has a klunky UI that could really stand improvement, but it's doable.
In 24.04, however, step #5 is impossible. The Something else tool recognizes your LUKS volume as such, but offers no way to decrypt and use it (and if you decrypt it in advance using cryptsetup open /dev/foo bar, it doesn't offer to let you use the bar).[†]
Thus, in 24.04, you can't create an LVM/LUKS setup using Install alongside, nor can you pre-create one and then install into it using Something else. Erase disk is the only way. Feh!
What I finally ended up doing was to perform a clean install of 22.04, using the five-step process I described above; then I immediately upgraded it.[‡] That's not an acceptable long-term solution as the upgrade chain gets longer with each new LTR. I sure hope they see fit to fix this in time for 26.04.
[*] cryptsetup(8)
[**] pvcreate(8), vgcreate(8), lvcreate(8)
[†] To be honest, I don't know how the 24.04 Something else tool would handle an unencrypted LVM setup. That's not a variant I tried.
[‡] I ended up backing off to 22.04 for other reasons, but this is how I got far enough into 24.04 to discover the need
