• thingsiplay@beehaw.org
    link
    fedilink
    arrow-up
    14
    arrow-down
    1
    ·
    3 days ago

    The intent was on better TPM security after a prior security demonstration showed TPM key recovery from Microsoft Windows BitLocker as well as TPM sniffing attacks.

    I am not sure if this is a good change. Isn’t this “dangerous”?

    The hope is that now it’s disabled by default, the Linux kernel developers can spend more time evaluating the security benefits and performance optimizations to make it worthwhile to re-enabled by default in a future Linux kernel version.

    I’m confused. They disable security feature and then want spend time on the benefits and performance optimizations, to possible enable it again?

    • nomad@infosec.pub
      link
      fedilink
      arrow-up
      5
      ·
      3 days ago

      If you use TPM for signing, that is not an issue most of the time. But if you store decryption keys for a storage device there that’s not a good idea.

            • nomad@infosec.pub
              link
              fedilink
              arrow-up
              1
              ·
              3 days ago

              AFAIK there is. But even if not, it simulates a keyboard which can input your passphrase. Also modification of the initrd is a matter of providing a bash script or binary to launch which returns the passphrase in the crypttab file and adding it to the correct directory.

              • Mihies@programming.dev
                link
                fedilink
                arrow-up
                2
                ·
                2 days ago

                From what I read so far, hardware key is just another way to decrypting, not the required. So it’s just a convenient method to avoid typing a (long) password and instead just few PIN chars. So, if somebody gets hold of password, can still decrypt the disk even without the hardware key. Not perfect, but still better than only password.