6 ms·

>The use of a discrete (physical) TPM actually decreases the security of the system, using a fTPM would solve the problem. Errr... no. Using no TPM of any kind

>The use of a discrete (physical) TPM actually decreases the security of the system, using a fTPM would solve the problem. Errr... no. Using no TPM of any kind decreases your security. The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data. Unencrypted communications over any channel, SW or HW are bad and dTPM never claimed it would protect you from that, but it's still better than no-TPM, and have your keys in system memory or on the disk where it could be accessed through software vulnerabilities. Of course fTPM, is the next step up in security, even though that's also not impenetrable to attackers with the right side channel analysis equipment and expertise, but security threat model is anyway a matter of time and budget of your attackers, nothing can ever be 100% invulnerable to everything.

candiddevmike 3y ago
Wouldn't the keys for LUKS/Bitlocker be stored in memory regardless of TPM/no TPM?
c4mpute 3y ago
This is highly misleading. fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely, even via the network, even maybe if the computer is switched off. Remember all those (even unauthenticated, remote) XML-parser exploits in the Intel ME? fTPM is just one more ME module, and of course vulnerable to those exploits. So overall, I consider fTPM a huge step back, because you might even get access without physical presence. For an fTPM, attack surface is far larger (because all of the ME software), minimum attack complexity may be smaller (because there will one day be a metasploit module for all those software problems, whereas HW hacking is always a certain hurdle), required attacker privileges are less (prolonged unobserved physical presence vs. network). Thus objectively worse in all aspects. What would be better would be a dTPM that is integrated e.g. into a SoC, such that there are no exposed wires anywhere without decapping the SoC. Some systems such as phones work like that, but this is hard to tell even from the technical specs.
- FirmwareBurner 3y ago
  >fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely Yes, fTPM is more vulnerable in theory to remote attacks, but fTPM could always be patched, while it's more difficult to de-solder the TPM chip off your motherboard and replace with a non-vulnerable one and there are vulnerable dTPM chips out there. Both solutions have their own pros and cons you have to weigh in the context of cost, convenience and threat model. >What would be better would be a dTPM that is integrated e.g. into a SoC Isn't that what fTPM is? The TPM spec firmware runs on the security microcontroller (Intel PTT and AMD PSP) built in the same SoC as the CPU. What would be better is having the TPM be removable from the machine, like the YubiKey. Currently, dTPM and fTPM are basically like having your YubiKey always plugged in and glued to your machine. Convenient for authenticating you, but not secure from guys stealing your machine and probing it in a lab.
  - auguzanellato 3y ago
    > but fTPM could always be patched dTPMs can also be patched, the TPM in my Dell laptop is discovered by fwupd as being updatable.
- Guvante 3y ago
  What threat model assumes it is easier to attack fTPM than the OS that is running? Once you are online Bitlocker does nothing and you can just attack the OS and bypass all of its protections trivially... Your threat model here assumes arbitrary code execution as a starting point of an exploit, the security game is up for the PC once that occurs.
  - c4mpute 3y ago
    Any thread model should take firmware into account. There have been examples of unauthenticated remote code execution against Intel ME[0]. This isn't theoretical, this isn't an assumption, this has happened. Those exploits are independent of the OS running, with certain configurations the system doesn't even need to be switched on, just plugged in. With fTPM as an ME module (not all fTPMs are such) this provides an additional huge attack surface. [0] https://mjg59.dreamwidth.org/48429.html https://mjg59.dreamwidth.org/48429.html
deleted 3y ago
[deleted]
ongy 3y ago
For large symmetric operations like disk encryption, the MVK is still in memory. TPMs are slow and have rather restricted memory. They are fine for PCRs and some asymmetric operations. But here they only unseal a key that is then used in software for speed. It's worse than something protected by a high entropy password. Which is still better than 90% of users would be otherwise
- logical_person 3y ago
  that's still less secure, though. without a TPM you have no guarantee of the underlying state of firmware on the device. this enables a persistent backdoor. TPM with no PIN is practically bitlocker with no password. A high entropy PIN happens to solve this entire attack.
  - ongy 3y ago
    For the claim of GGP (stealing out of memory) it's worse, as that's still possible, and there's a bus the key travels over. The PCRs attest system state to the OS, yes. Though the verified boot (PSB/Secure Guard + Secure Boot) chain is supposed to provide the same security there. Provided we assume security features aren't broken by design...
    - brohee 3y ago
      At least TME-MK and its AMD equivalent are supposed to address in memory key stealing/memory bus snooping (even if it's still unclear to me how the key are generated/stored). There is still decapping and probing the CPU itself but given the size of features is that even remotely doable?
      - ongy 3y ago
        Yes and no. Mostly no IMO The memory encryption features are a solution to very specific problems. If the CPU is able to access the memory, then any exploit that gains the execution context of the legitimate user can also access the memory. If it doesn't, the normal memory access control should be enough. I'm iffy on how well they protect against the various side channels. Mostly because I haven't looked far enough into it. IME it protects against cold boot attacks, a theoretic attack of a logic analyzer on the memory bus, and potentially to some degree unbounded reads. But the latter only with very limited gadgets.
gquere 3y ago
Author here. > Errr... no. Using no TPM of any kind decreases your security. You're right, I wrote too fast, sorry about that. What I meant to say is that it discrete TPM with no PIN is an inferior solution compared to PIN/passphrase or fTPM. Also I should have added that it gives the illusion of security which I hinted at in the foreword. I'm leaving it as is for now, the discussions here are interesting.
- gbil 3y ago
  Some months ago my company (in the 200k+ employees big) decided to remove pin requirement to “enhance UX while staying secure”. Many objections from quite a few people, mine included pointing to PoC key extractions from TPM etc. and… nothing . Seems that a multi billion company with no-ask money for cybersecurity misses the basics
etna_ramequin 3y ago
> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data. I’m always very confused by this. TPM offers encrypted sessions (setup with the Endorsement Key) for exactly this kind of attack. Why couldn’t the firmware get the keys over an encrypted session? Is it for reliability in case certificate verification goes wrong?
zimmerfrei 3y ago
>> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data. This is not really true. All TPMs (or at least since v2.0, but no matter if discrete or not) support encrypted session against passive eavesdroppers. There is also the possibility to protect against MiTM attacks, but that is more complex (since you then need to setup credentials). See here [0]: "Encryption sessions are useful for when the path to a TPM is not trused, such as when a TPM is a remote TPM, or when otherwise the path to the TPM is not trusted." The issue is that the OS / Bootloader does not implement such mechanism. [0] https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Intro/README.md https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Int...

candiddevmike 3y ago

Wouldn't the keys for LUKS/Bitlocker be stored in memory regardless of TPM/no TPM?

c4mpute 3y ago

This is highly misleading. fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely, even via the network, even maybe if the computer is switched off. Remember all those (even unauthenticated, remote) XML-parser exploits in the Intel ME? fTPM is just one more ME module, and of course vulnerable to those exploits. So overall, I consider fTPM a huge step back, because you might even get access without physical presence. For an fTPM, attack surface is far larger (because all of the ME software), minimum attack complexity may be smaller (because there will one day be a metasploit module for all those software problems, whereas HW hacking is always a certain hurdle), required attacker privileges are less (prolonged unobserved physical presence vs. network). Thus objectively worse in all aspects. What would be better would be a dTPM that is integrated e.g. into a SoC, such that there are no exposed wires anywhere without decapping the SoC. Some systems such as phones work like that, but this is hard to tell even from the technical specs.

FirmwareBurner 3y ago
>fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely Yes, fTPM is more vulnerable in theory to remote attacks, but fTPM could always be patched, while it's more difficult to de-solder the TPM chip off your motherboard and replace with a non-vulnerable one and there are vulnerable dTPM chips out there. Both solutions have their own pros and cons you have to weigh in the context of cost, convenience and threat model. >What would be better would be a dTPM that is integrated e.g. into a SoC Isn't that what fTPM is? The TPM spec firmware runs on the security microcontroller (Intel PTT and AMD PSP) built in the same SoC as the CPU. What would be better is having the TPM be removable from the machine, like the YubiKey. Currently, dTPM and fTPM are basically like having your YubiKey always plugged in and glued to your machine. Convenient for authenticating you, but not secure from guys stealing your machine and probing it in a lab.
- auguzanellato 3y ago
  > but fTPM could always be patched dTPMs can also be patched, the TPM in my Dell laptop is discovered by fwupd as being updatable.
Guvante 3y ago
What threat model assumes it is easier to attack fTPM than the OS that is running? Once you are online Bitlocker does nothing and you can just attack the OS and bypass all of its protections trivially... Your threat model here assumes arbitrary code execution as a starting point of an exploit, the security game is up for the PC once that occurs.
- c4mpute 3y ago
  Any thread model should take firmware into account. There have been examples of unauthenticated remote code execution against Intel ME[0]. This isn't theoretical, this isn't an assumption, this has happened. Those exploits are independent of the OS running, with certain configurations the system doesn't even need to be switched on, just plugged in. With fTPM as an ME module (not all fTPMs are such) this provides an additional huge attack surface. [0] https://mjg59.dreamwidth.org/48429.html https://mjg59.dreamwidth.org/48429.html

deleted 3y ago

[deleted]

ongy 3y ago

For large symmetric operations like disk encryption, the MVK is still in memory. TPMs are slow and have rather restricted memory. They are fine for PCRs and some asymmetric operations. But here they only unseal a key that is then used in software for speed. It's worse than something protected by a high entropy password. Which is still better than 90% of users would be otherwise

logical_person 3y ago
that's still less secure, though. without a TPM you have no guarantee of the underlying state of firmware on the device. this enables a persistent backdoor. TPM with no PIN is practically bitlocker with no password. A high entropy PIN happens to solve this entire attack.
- ongy 3y ago
  For the claim of GGP (stealing out of memory) it's worse, as that's still possible, and there's a bus the key travels over. The PCRs attest system state to the OS, yes. Though the verified boot (PSB/Secure Guard + Secure Boot) chain is supposed to provide the same security there. Provided we assume security features aren't broken by design...
  - brohee 3y ago
    At least TME-MK and its AMD equivalent are supposed to address in memory key stealing/memory bus snooping (even if it's still unclear to me how the key are generated/stored). There is still decapping and probing the CPU itself but given the size of features is that even remotely doable?
    - ongy 3y ago
      Yes and no. Mostly no IMO The memory encryption features are a solution to very specific problems. If the CPU is able to access the memory, then any exploit that gains the execution context of the legitimate user can also access the memory. If it doesn't, the normal memory access control should be enough. I'm iffy on how well they protect against the various side channels. Mostly because I haven't looked far enough into it. IME it protects against cold boot attacks, a theoretic attack of a logic analyzer on the memory bus, and potentially to some degree unbounded reads. But the latter only with very limited gadgets.

gquere 3y ago

Author here. > Errr... no. Using no TPM of any kind decreases your security. You're right, I wrote too fast, sorry about that. What I meant to say is that it discrete TPM with no PIN is an inferior solution compared to PIN/passphrase or fTPM. Also I should have added that it gives the illusion of security which I hinted at in the foreword. I'm leaving it as is for now, the discussions here are interesting.

gbil 3y ago
Some months ago my company (in the 200k+ employees big) decided to remove pin requirement to “enhance UX while staying secure”. Many objections from quite a few people, mine included pointing to PoC key extractions from TPM etc. and… nothing . Seems that a multi billion company with no-ask money for cybersecurity misses the basics

etna_ramequin 3y ago

> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data. I’m always very confused by this. TPM offers encrypted sessions (setup with the Endorsement Key) for exactly this kind of attack. Why couldn’t the firmware get the keys over an encrypted session? Is it for reliability in case certificate verification goes wrong?

zimmerfrei 3y ago

>> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data. This is not really true. All TPMs (or at least since v2.0, but no matter if discrete or not) support encrypted session against passive eavesdroppers. There is also the possibility to protect against MiTM attacks, but that is more complex (since you then need to setup credentials). See here [0]: "Encryption sessions are useful for when the path to a TPM is not trused, such as when a TPM is a remote TPM, or when otherwise the path to the TPM is not trusted." The issue is that the OS / Bootloader does not implement such mechanism. [0] https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Intro/README.md https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Int...