Announcement

Collapse
No announcement yet.

Ubuntu 23.10 Adding Experimental TPM-Backed Full Disk Encryption

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Jakobson View Post

    TPM does not compromise full-disk encryption. Instead, it serves as an additional layer that binds the master key of the disk to the TPM hardware, making offline decryption more challenging. Naturally, a passphrase must still be required.
    Not at all, the TPM unlocks the disk upon boot automatically. There will be an additional passphrase that may be used in case of emergency, if that's what you mean.

    Comment


    • #12
      Originally posted by Jakobson View Post

      The only drawback is the dependency on Snap. It may have made it more challenging to boot up with a self-compiled kernel. However, for the average user, this is a brilliant solution that makes enabling full-disk encryption as easy as using BitLocker on Windows.
      There's no hard Snap dependency, and it's not even new, it's been working for like 5 years now. All you had to do was to recompile tpm2-tools and Clevis.

      Enterprise Ubuntu development environment with Active Directory integration - noobient/noobuntu


      RH-based distros have been supporting this out of the box since forever.

      Comment


      • #13
        Originally posted by anarki2 View Post
        Not at all, the TPM unlocks the disk upon boot automatically. There will be an additional passphrase that may be used in case of emergency, if that's what you mean.
        To ensure real security, it's always advisable to use an additional passphrase, or at the very least, a shorter one, which we can refer to as a password. While it is possible to configure it without one, doing so would provide only Secure Boot and IMA protection, leaving your system vulnerable in case of theft or other unauthorized access.

        From a security perspective, automatically unlocking disk encryption is equivalent to having automatic login without a password.

        Comment


        • #14
          Originally posted by anarki2 View Post

          There's no hard Snap dependency, and it's not even new, it's been working for like 5 years now. All you had to do was to recompile tpm2-tools and Clevis.

          Enterprise Ubuntu development environment with Active Directory integration - noobient/noobuntu


          RH-based distros have been supporting this out of the box since forever.
          Yes, but this is Ubuntu.

          Namely, the bootloader (shim and GRUB) and kernel assets will be delivered as snap packages (via gadget and kernel snaps), as opposed to being delivered as Debian packages.

          Comment


          • #15
            Ah yes, now my UKI will have to unsquash before booting my system, exactly what I wanted (sarcasm)

            Anyways, Canonical at this point should just come out and abandon "Ubuntu: the Debian fork" in favor of "SnapOS" that is what they really want to build. If they do that Snap is just going to end up as another package manager (that coincidentally plays nice working together with other package managers, like Nix) but I think its better than the hybrid monster they currently have.

            Comment


            • #16
              Canonical. Experimental. Full Disk Encryption.

              What could possibly go wrong?

              Comment


              • #17
                What's the benefit of TPM? What does it provide over the traditional way of entering a password upon boot?

                Comment


                • #18
                  Originally posted by sarmad View Post
                  What's the benefit of TPM? What does it provide over the traditional way of entering a password upon boot?
                  Encryption does not open without that particular piece of HW. Advanced enterprise Android phones already has Secure Element for that purpose. Credit card has a chip instead of cloneable data stripe.
                  Passphrases/passwords chosen by people usually don't have very strong. Additional binding to HW improves security. Otherwise encrypted disk for example can be cloned and tried to brute-force by mush more faster supercomputers.

                  Comment


                  • #19
                    I've been using the TPM on my Arch installations for several months now. systemd-cryptenroll makes it easy to enable, and the TPM will unlock the drive as long as there's no hardware change or BIOS update. In that case, you would just enter the LUKS password to boot and then re-associate the TPM with systemd-cryptenroll again.

                    Comment


                    • #20
                      Originally posted by sarmad View Post
                      What's the benefit of TPM? What does it provide over the traditional way of entering a password upon boot?
                      If you're using it as sole factor for unlocking disk encryption, it means you don't have to type in your password. Useful if you have a personal server running at home and you want it to come back automatically after power loss, while still having the disk encrypted.

                      I think some people here are missing the nuance of the compromise being made: yes, it won't protect you from the CIA/FSB/SIS/etc, but since the disk is still encrypted it takes away the option of just slapping it in another system and taking the data. With TPM unlocking you have to find a software or hardware vulnerability to get access, which is typically well outside the competency of your local thief or police agency.

                      In regards to defending against CIA/FSB/SIS/etc ... obligatory xkcd

                      Comment

                      Working...
                      X