737
BitLocker encryption broken in less than 43 seconds with sub-$10 Raspberry Pi Pico — key can be sniffed when using an external TPM (www.tomshardware.com)
submitted 2 years ago by to c/technology@lemmy.world
69 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 67 points 2 years ago* (2 children)

I thought the point of the TPM was that the keys would be kept internally to the TPM at all times and that any data lanes would only be used for transferring payload. Why are they sending keys between the TPM and the CPU?

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 43 points 2 years ago

    There are some functions like that, like Passkey signing. For Bitlocker, the encryption/decryption key is transferred to the CPU (and RAM) in order for it to operate. The problem described here has been around for a while, but putting it on a key like that makes the attack method available to "everyone". There has been a solution for a while too: 1) put in pre-boot Bitlocker PIN, and 2) use integrated TPM like the article mentions.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 18 points 2 years ago (1 child)

    Because the CPU has to decrypt the bulk of the data coming from the disc. And it needs a key to do that. Unless we route all traffic through the TPM to decrypt the disc. The CPU needs a key to do that

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 2 years ago (1 child)

    Surely some smart key exchange algorithm could be used for that, e.g. the CPU provides a public key to the TPM and the TPM encrypts the symmetric disk key with that public key. Similar to how TLS works.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 8 points 2 years ago (3 children)

    The private key would have to stored in clear text somewhere. Potentially if you had non volatile space on cpu that to store the private key, that might work. But if you’re going to do that, might as well just use an ftpm.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    Why not store it directly in the TPM, if that's the device that will do that initial decryption?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (2 children)

    You can't do that since vulnerability is the connection between the TPM and the CPU, you need to encrypt that path.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 2 years ago

    The TPM comes out from the factory with a private key stored in it. The CPU has the public key.

    You turn on the laptop for the first time, and the communication between the CPU and the TPM is encrypted from the start.

    That's what I'm referring to. Can't this be done? I'm guessing it's not that easy because I'm sure computer designers have already considered this idea.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago (1 child)

    Just generate one anew. You don't need to use the same one each time

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    What do you mean by that? Generate a new private/public key pair every time you setup a new TPM? Or when you boot the system or something?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (last edited 2 years ago)

    On each connection. Or boot. Whenever you need

    Edit: to be clear, this would still be vulnerable to mitm attacks without a user entered password on top but at least you can't just read the secrets from the bus. E2: And having a password wouldn't be fully secure without such a scheme neither

  • permalink
  • fedilink
  • source
  • parent