Feature request: Add a supported post-install tool to enable TPM-backed full disk encryption

Project Discussion Security
, ,
1

Hi Ubuntu Desktop team,

I would like to suggest adding a supported way to enable TPM-backed full disk encryption on an existing Ubuntu installation, without requiring users to wipe the disk and reinstall Ubuntu from scratch.

At the moment, Ubuntu’s TPM-backed full disk encryption is a great security feature, but it appears to be available only during installation. That creates a frustrating gap for users who have already installed Ubuntu and later decide they want stronger device protection.

This would be especially helpful for:

  • Users who installed Ubuntu before TPM/FDE became more mature.

  • People who moved from Windows/BitLocker and expect encryption to be something they can turn on later.

  • Businesses managing laptops where rebuilding every machine is disruptive.

  • Users who have spent time setting up development environments, VPNs, certificates, apps, user profiles, and local data.

  • People who want to improve security without having to back up everything, reinstall, restore, and reconfigure their system.

I understand this is not a simple feature. TPM/FDE depends on Secure Boot, firmware state, TPM measurements, recovery keys, kernel/initramfs handling, and disk layout. A post-install conversion tool would need to be careful and conservative.

However, even a limited tool would be very useful. For example, Ubuntu could provide a “Disk Encryption Migration” tool in Security Center or as a guided command-line utility that:

  1. Checks hardware readiness: TPM 2.0, Secure Boot, UEFI, firmware support, kernel requirements, disk layout, free space, and known unsupported configurations.

  2. Warns clearly that the process is sensitive and requires a full backup.

  3. Generates and verifies a recovery key before making changes.

  4. Refuses to continue if the system has an unsupported partition layout or risky configuration.

  5. Supports only common/default Ubuntu Desktop layouts at first.

  6. Offers an offline/live-environment migration path if online conversion is too risky.

  7. Allows users to add a TPM-bound unlock method, with optional PIN or passphrase.

  8. Gives a clear rollback or recovery path if the migration fails.

This would bring Ubuntu closer to the user experience many people expect from modern operating systems, where device encryption can be enabled after setup through a trusted system tool.

Could the Ubuntu Desktop/security team consider adding a supported post-install TPM/FDE enablement or migration workflow, even if it initially supports only simple default installations?

Thanks for all the work going into TPM-backed encryption. I think this would make the feature much more useful for everyday desktop users and managed laptop fleets.

2

Reasonable ask, and the bits you’ve listed (cryptsetup reencryption, systemd-cryptenroll for TPM) aren’t hypothetical, people do this manually already. The problem isn’t the LUKS conversion itself, it’s everything around it. The installer gets a known disk layout to work with. A post-install tool has to cope with whatever’s actually out there: LVM-on-LUKS, ZFS root, dual boot, custom partitioning, no spare space to fit a header into. That’s a much bigger support matrix than “wipe and reinstall.”

Then there’s PCR sealing surviving a kernel or shim update without locking you out of your own disk, which Ubuntu’s only recently got solid for the clean-install case. Doing that reliably on an already-running system, indefinitely, into the future, is a harder problem than getting it right once at install time.

So not impossible, just high risk for a small team. One bad bug here doesn’t just break a build, it bricks someone’s laptop. That’s probably why nobody’s shipped it yet even though everyone agrees it’d be useful. Might land better scoped down: ext4 + LVM only, CLI tool, no Security Centre GUI promise on day one.

1 Like
3

(emphasis added :wink: )

Other than “because I can”, what is the point, really? One shouldn’t do this without backup. So why not do the backup, install from scratch, which has the benefit of really starting from a clean slate and ending in a well-defined state and then just restore said backup? Since one should always keep recent backups anyway and, most importantly, test them, i.e. can they be restored and does everything run as designed afterwards(?) — many a business have found out the hard way that’s not a given —, why not use the opportunity for a test run?