From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Ubuntu (on which Pop!_OS is based) only added support for TPM disk encryption in Ubuntu 23.10, so my guess is that you'll have to wait for Pop!_OS 24.04
Note that, as I understand it, using TPM will only protect data on your encrypted disk if it is removed from your computer. If someone steals your entire computer, the disk will be decrypted on boot.
There are plenty of ways to do TPM backed FDE on earlier Ubuntu. They're just not officially supported. Clevis is one of the easier ways.
The disk will be decrypted on boot, but then they'll have to contend with needing a password to log in
Unless recovery (single user) mode is enabled. If it is, you can boot right into a root shell from the bootloader.
Guess I'll wait for COSMIC DE's alpha release then. It should come with Pop!_OS 24.04
Why would you do this when PopOS offers LUKS1/2 disk encryption?
The TPM holds the LUKS key.
Ideally the key isn’t stored anywhere on the machine that contains the storage medium the key is for.
That is the tradeoff if one desires TPM-backed encryption. It really depends on the threat model.
But what is the threat model where a TPM-stored LUKS key protects against?
I fail to see it. It doesn't protect against any physical attacks at all, and it also doesn't protect against attacks while the system is powered on.
It seems to only protect against the attack of someone stealing your hard drive out of your system but leaving the entire system behind. Maybe for encrypting extra data drives that will want to be resold later? But that is more a datacenter threat model
Let's say you have LUKS with TPM enabled. Verified or Safe Boot is also on, so someone cannot access your decrypted files just with some live usb distro. And let's say you also have a password set for changing BIOS/UEFI settings so the attacker cannot disable safe boot without a password. So the attacker might want to steal the hard drive in this case to get the data, but that's also not possible because the hard drive is encrypted and the key is in the TPM. The way TPM also checks for integrity makes the system tamper-proof. So any attempt at tampering with the hardware will trigger the tamper protection and ask the user for a recovery passphrase to let the TPM hand over the decryption key again. So actually TPM is useless without safe boot and without a password for the user account in your OS. The only thing protecting your data from the attacker in this case is your user password... unless the user has one of these raspberry pi pico devices that are programmed to take the TPM keys sent to the CPU at boot in plaintext. Though I am pretty sure this is also fixed or will be fixed in the future. Maybe public key cryptography could help. I haven't researched that yet.
TL;DR: TPM is pretty useless without safe boot, but is pretty decent with safe boot. TPM is not the securest thing in the world but for a regular user it's probably the best choice without sacrificing convenience.
Just wanted to add that your BIOS password can be circumvented by taking out the CMOS battery. That will clear all your settings and allow unrestricted access. A BIOS password should absolutely never be used as a form of security, it is trivial to bypass.
Granted, I don't believe that the TPM will give the key if secure boot were disabled, I just wanted to mention that BIOS passwords don't do anything against any real attack.
I also want to add that the TPM will request the recovery key if the BIOS goes back to factory defaults. I also think changing the secure boot setting might trigger it. If that's the case then a BIOS password is pretty useless.
I believe that the TPM will refuse to provide keys after secure boot is disabled, but I didn't intend to imply that it could be used to bypass TPM decryption or anything. Just as an aside that BIOS passwords are effectively useless at preventing access to the BIOS.
It does seem like most of the TPMs indeed do not provide the keys if secure boot is disabled. Sorry for the misunderstanding.
Aside from the full scenarios provided in the other comments, there is another, more simple reason to still prefer it: your daily workflow is not intercepted, but if your disk dies, you can throw it out and replace it without a second thought, since it was encrypted all the time.
It does protect against physical attacks. PCRs are used to tie keys to specific hardware and software configurations and versions, boot paths, kernel command line arguments, etc and will lock out if changed. One of the reasons Ubuntu waited so long for official support was to set up the infrastructure for unified kernels and signing, the kernel and initrd are unified and signed and verified before it will unlock to protect against sophisticated attacks that most people will never encounter. For most people worried about theft, having it lock out when the boot order is changed would be enough. And when running, brute forcing the login process is slow and can be made even more painful with lockouts.
The TPM functions very differently than putting keys on a permanently attached usb drive.
The threat ia that someone who uses a shitty password and then their laptop gets taken by a sophisticated actor that could crack their stupid password in an hour without the TPM wiping itself after X failed attempts.
The solution, of course, is to not use shitty passwords
If being able to boot unattended is more important than potential data leak if the server is physically compromised, then that’s what you have to do.
@hperrin @Dirk you can do this somehow and I even had it working at one point, but it was kinda a pain in the ass and I never redid it
https://glentomkowiak.medium.com/luks-with-tpm-in-ubuntu-df867cad9a1
Not necessarily?
Im pretty sure I used PopOS for 3 years with LUKS encryption with TPM disabled.
You don't need TPM to enable LUKS. TPM allows you to store the LUKS keys in a secure enclave in order to automatically decrypt the drives on boot.
You also do not need TPM to automatically decrypt drives on boot, I have also done this on PopOS for 3 years, with TPM disabled.
Yes, and we are responding to someone asking about using it with the TPM.
Ok... so... if you have TPM... and LUKS...
You still have a scenario where the encryption key is still on your physical device, LUKS with or without TPM, or ... some kind of TPM based Linux encryption solution I have never heard of?
Does Windows Secure Boot work on Linux via the TPM?
No...
Am I missing something?
Theres no point in involving TPM in securing a linux computer.
In a scenario where you've physically lost your computer, using TPM or not it wont matter if your pc gets into the hands of someone who can attempt to brute force the keys.
If your pc is remotely compromised to the point it has something on it that can grab your keys, it also will not matter if you are using TPM in some way.
The only practical use of full disk encryption is if your linux pc and or laptop gets stolen and falls into the hands of a non tech savvy person, and in that scenario, going through the trouble of correctly binding LUKS to TPM will have just been a waste of time.
Thus, you should probably just use LUKS and not bother routing it through TPM.
It’s not a new feature, it’s convenient and also has use cases outside of convenience (it’s also generally going to make stronger keys than any passphrase). Here is one way that has existed for years, except Ubuntu specifically patches it out: https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptenroll.html
It’s not a lot of work, it’s one command and a one word update in the crypttab.
Secure boot is generally a requirement to use the TPM.
TPM isn't an encryption algorithm. TPM just holds the decryption key (in my case the LUKS decryption key) and hands it to the CPU if all checks pass for convenience. No key is stored in the storage in plaintext. TPM isn't the most secure thing but at least its better than nothing at all.
Sure but you dont need to use TPM at all to use LUKS.
You can store the encryption key on the harddrive, in the LUKS partition layer.
Like thats the default of how LUKS works.
Im really confused why people think TPM needs to be involved in anyway when using LUKS.
Generally speaking you have to go out of your way to correctly cajole TPM v1 or v2 to actually correctly interface with LUKS.
The point is to have the system automatically unlock without the need for a boot password. This provides decent security if secure boot is enabled, but requires very little from the user. It isn't a stopper for high threats, but a simple theft will mean the data is safe. It also ensures that if the drive is separated from the host machine, it is useless without a copy of they key. It doesn't stop all threats, but stops a lot of them, and all of the most common.
Nobody thinks it needs to be involved. They want it involved so the drive is automatically unlocked at boot, but inaccessible if someone removes it from the machine to try and bypass login (and in the future, if someone tries tampering). Especially useful in machines you want useable without being physically present.
It’s not cajoling anything, it’s a built in feature you configure, although Ubuntu currently goes out of their way to remove the support from some tools.
Im really confused why people think TPM needs to be involved in anyway when using LUKS.
Because it's convenient
Its not though, it requires a ton of extra work to set up, isn't necessary, doesn't allow you to do anything you can't do without it.
You didn’t even know what it was how exactly do you know how much work it is to implement? Its about to be built into the Ubuntu installer.
doesn't allow you to do anything you can't do without it.
That's false. It allows you to not need a password to unlock the volume at boot.
They correctly point out elsewhere that you could just store the unlock on an unencrypted portion of drive itself.
Yes, I know.
You can but I personally won't trust TPM
This. But not because the tech is sketch. because storing keys in a TPM is a disaster waiting to happen
Did you make a backup of the key before storing it in the TPM? If not, then say goodbye to you data when the TPM fails.