Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages(bare.systems)
20 pointsby 6jQhWNYh4 hours ago3 comments
  • voidnullvalue39 minutes ago
    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
  • tryauuum2 hours ago
    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?

    • evan_a_aan hour ago
      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.

    • mono44220 minutes ago
      The point is that you don't have a separate password just for the disk encryption. It all works transparently.
    • Graziano_M36 minutes ago
      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.
    • stefanfiskan hour ago
      I believe that the goal is mainly to protect the data of stolen laptops.
  • lostmsu3 hours ago
    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