That snap-based TPM setup also breaks spectacularly. I would highly recommend people using something else entirely.
Basically if any bug surfaces in the encryption setup snap permanently loses the ability to update kernel, which, if you care about security, means the system has to be reinstalled to resume receiving kernel bug fixes. The issue is in "Wishlist".
Jokes aside, I agree on the sense that this should be a solved problem. On the other hand, if the only implementation is a broken one, there's only one way to help yourself, and that is learning how to do it and helping yourself
so, if you use encryption on ubuntu you get a vendor controlled delivery path that has all the practical properties of a backdoor, without the transparency to easily prove its not being used as one
Nice to see a Linux vendor developing a sealed environment, but rather cruel of them to hide it silently behind a disk encryption checkbox. I suppose they must consider their non-paying users as test subjects? Lots of bugs in process here that need to be cleaned up for this to remain viable if Steam Linux decides to compete in the sealed-signed-attested space someday.
can someone explain like I'm 5, what's the point of during storing disk encryption keys in TPM? What kind of attack or attacker do we protect from?
my logic is following:
- if the attacker is remote and somehow modifies my kernel... Yes, the tpm and hardware attestation (is this the term?) would have saved me. But I'm fucked anyway since the attacker already has root on my computer
- if the attacker is local -- yes, with tpm they cannot steal just the hard drive and bruteforce it offline. But they can just reset bios and install their own os and trick me into typing the os passwords? Or even if they cannot trick me (hard to spoof my os UI) they can just install a physical keylogger?
The disk encryption key(s) isn't typically stored in the TPM, it is sealed by the TPM. A sealed key can only be unsealed if the TPM is in the same state as it was sealed against (simplifying some things here). With the proper selection of Platform Configuration Registers (PCRs), this can prevent the key from being unsealed if the system has not securely booted (sealed against PCR 7). In more complicated configurations, it is also possible to seal the key against a particular phase of boot such that it can't be unsealed once userspace is reached.
In your scenario, yes it is bad if the attacker gets root on your computer, but sealing the key with the TPM means they can't retrieve the key itself. Where the TPM helps is preventing the attacker from establishing low level (kernel, bootloader, or firmware) persistence, since modifications of these components would change the TPM PCR measurements and result in a boot failure.
If the attacker is local and they reset the UEFI, the TPM PCRs are now different and as before, the disk encryption keys will not unseal.
It is also generally recommended to use a pin with TPM, which further complicates this scenario for the attacker because the TPM enforces rate limiting. As the other commenter mentioned, the physical access scenario is commonly a stolen laptop situation, where the attacker would not be in communication with the victim and probably wouldn't return the laptop.
Suppose the physical attacker doesn't reset the bios. He boots Ubuntu or any other os which is signed. Will the tpm unlock and give out the key? I guess it depends on the setup and it's possible to unlock only on your own signed kernel but I doubt this is a default?
I think this is like the windows bit locker vulnerability that was seen a while ago.
The windows recovery put the TPM in the same state as the normal windows OS, so it released bit locker keys, but you could bypass the login on the recovery environment.
At which point they will be stopped by Ubuntu login screen which requires user password (or fingerprint, pin, etc).
Basically there are two options for have to enter 1 password:
1. TPM disk encryption + login password.
2. Password for disk encryption and automatic login (doesn't support multiple user accounts well).
no, I mean the attacker boots his own copy of Windows or Ubuntu, which is supposedly trusted by the UEFI keys. Will tpm somehow detect that it shouldn't unlock secrets for this boot?
This is contingent on the sealing policy including PCRs that would change as a result of booting a different operating system, like PCR 11, which, when booting a UKI, contains those measurements. Only sealing against PCR 7 would allow this attack, since the default platform secure boot policy would not need to change.
The keys can be indirectly sealed against specific system and software configurations such that this attack is not possible. Additionally, as you noted, using custom secure boot keys would prevent the attacker from booting an arbitrary OS.
With TPM backed keys the point is that the user doesn’t know the decryption key, and he doesn’t need to enter it to boot. There can be a backup/recovery key, but being prompted for it should set off alarm bells.
That snap-based TPM setup also breaks spectacularly. I would highly recommend people using something else entirely.
Basically if any bug surfaces in the encryption setup snap permanently loses the ability to update kernel, which, if you care about security, means the system has to be reinstalled to resume receiving kernel bug fixes. The issue is in "Wishlist".
https://bugs.launchpad.net/snapd/+bug/2045417
Far better to just use the raw tools and manage it yourself ala arch wiki:
https://wiki.archlinux.org/title/Trusted_Platform_Module#PCR...
The problem with manuals like that is they are like commercial flight checklists, except in most cases the user is not a professional pilot.
Skill issue
Jokes aside, I agree on the sense that this should be a solved problem. On the other hand, if the only implementation is a broken one, there's only one way to help yourself, and that is learning how to do it and helping yourself
so, if you use encryption on ubuntu you get a vendor controlled delivery path that has all the practical properties of a backdoor, without the transparency to easily prove its not being used as one
Nice to see a Linux vendor developing a sealed environment, but rather cruel of them to hide it silently behind a disk encryption checkbox. I suppose they must consider their non-paying users as test subjects? Lots of bugs in process here that need to be cleaned up for this to remain viable if Steam Linux decides to compete in the sealed-signed-attested space someday.
It seems it's quite often that Ubuntu reminds me how much I appreciate Mint dropping everything snap.
Except the graphical installer, which is bizarrely still a snap
the tpm model is silly and always has been. if you need encryption why would you care if the cpu or motherboard is the same?
the threat model does not make sense. especially in the past when it was i2c
https://osresearch.net/Heads-threat-model/#threat-model
[dead]
Basically following the path that same other OSes are trailing in security, Windows, macOS, mobile, container-based immutable infrastruture.
Also a reminder that when OEMs ship Linux distros, it is always customised.
holy hell! snap-based kernel
can someone explain like I'm 5, what's the point of during storing disk encryption keys in TPM? What kind of attack or attacker do we protect from?
my logic is following: - if the attacker is remote and somehow modifies my kernel... Yes, the tpm and hardware attestation (is this the term?) would have saved me. But I'm fucked anyway since the attacker already has root on my computer
- if the attacker is local -- yes, with tpm they cannot steal just the hard drive and bruteforce it offline. But they can just reset bios and install their own os and trick me into typing the os passwords? Or even if they cannot trick me (hard to spoof my os UI) they can just install a physical keylogger?
The disk encryption key(s) isn't typically stored in the TPM, it is sealed by the TPM. A sealed key can only be unsealed if the TPM is in the same state as it was sealed against (simplifying some things here). With the proper selection of Platform Configuration Registers (PCRs), this can prevent the key from being unsealed if the system has not securely booted (sealed against PCR 7). In more complicated configurations, it is also possible to seal the key against a particular phase of boot such that it can't be unsealed once userspace is reached.
In your scenario, yes it is bad if the attacker gets root on your computer, but sealing the key with the TPM means they can't retrieve the key itself. Where the TPM helps is preventing the attacker from establishing low level (kernel, bootloader, or firmware) persistence, since modifications of these components would change the TPM PCR measurements and result in a boot failure.
If the attacker is local and they reset the UEFI, the TPM PCRs are now different and as before, the disk encryption keys will not unseal.
It is also generally recommended to use a pin with TPM, which further complicates this scenario for the attacker because the TPM enforces rate limiting. As the other commenter mentioned, the physical access scenario is commonly a stolen laptop situation, where the attacker would not be in communication with the victim and probably wouldn't return the laptop.
It all weird still
Suppose the physical attacker doesn't reset the bios. He boots Ubuntu or any other os which is signed. Will the tpm unlock and give out the key? I guess it depends on the setup and it's possible to unlock only on your own signed kernel but I doubt this is a default?
I think this is like the windows bit locker vulnerability that was seen a while ago.
The windows recovery put the TPM in the same state as the normal windows OS, so it released bit locker keys, but you could bypass the login on the recovery environment.
At which point they will be stopped by Ubuntu login screen which requires user password (or fingerprint, pin, etc).
Basically there are two options for have to enter 1 password: 1. TPM disk encryption + login password. 2. Password for disk encryption and automatic login (doesn't support multiple user accounts well).
no, I mean the attacker boots his own copy of Windows or Ubuntu, which is supposedly trusted by the UEFI keys. Will tpm somehow detect that it shouldn't unlock secrets for this boot?
Yes. The PCR state after booting won't match that of the regular system, so the TPM will refuse to give up the key.
This is contingent on the sealing policy including PCRs that would change as a result of booting a different operating system, like PCR 11, which, when booting a UKI, contains those measurements. Only sealing against PCR 7 would allow this attack, since the default platform secure boot policy would not need to change.
The keys can be indirectly sealed against specific system and software configurations such that this attack is not possible. Additionally, as you noted, using custom secure boot keys would prevent the attacker from booting an arbitrary OS.
The point is that you don't have a separate password just for the disk encryption. It all works transparently.
The downside is after all that, is you end up with an running Ubuntu system, and you realise you're running a shitty NIH Debian fork.
How often do you reboot your laptop anyway? It takes a couple seconds to type in a well-rehearsed passphrase.
When I reboot mine it's actually three passwords that I need to put in: disk encryption, linux login, and firefox master key.
i so wish the firefox master key was better implemented. they need at least a dont remind me for x minutes option.
I believe that the goal is mainly to protect the data of stolen laptops.
With TPM backed keys the point is that the user doesn’t know the decryption key, and he doesn’t need to enter it to boot. There can be a backup/recovery key, but being prompted for it should set off alarm bells.