Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

bare.systems

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#11

Post by lostmsu »

evan_a_a wrote: post #5
lostmsu wrote: post #2

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.

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#12

Post by altairprime »

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.

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#13

Post by tryauuum »

evan_a_a wrote: post #6
tryauuum wrote: post #3

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 t…

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 configuration…

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?

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#14

Post by LelouBil »

tryauuum wrote: post #13
evan_a_a wrote: post #6

Earlier quoted context omitted.

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 configuration…

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.

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#15

Post by vayun »

tryauuum wrote: post #13
evan_a_a wrote: post #6

Earlier quoted context omitted.

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 configuration…

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?

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).

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#16

Post by tryauuum »

vayun wrote: post #15
tryauuum wrote: post #13

Earlier quoted context omitted.

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?

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?

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#17

Post by evan_a_a »

tryauuum wrote: post #13
evan_a_a wrote: post #6

Earlier quoted context omitted.

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 configuration…

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?

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.

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#18

Post by noisem4ker »

tryauuum wrote: post #16
vayun wrote: post #15

Earlier quoted context omitted.

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.

Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages

#20

Post by downsplat »

mono442 wrote: post #9
tryauuum wrote: post #3

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 t…

The point is that you don't have a separate password just for the disk encryption. It all works transparently.

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.

Post reply on HN