Hacker News Reader

Comment by FirmwareBurner | Hacker News Reader

>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.

View on HN

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.

>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.

> but fTPM could always be patched

dTPMs can also be patched, the TPM in my Dell laptop is discovered by fwupd as being updatable.

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.

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

That vulnerability allowed unauthenticated access to AMT, not arbitrary code execution on the ME. I agree that an ME-based fTPM has a larger attack surface than a dTPM, but we haven't seen many cases where that's had real-world poor outcomes.

> 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.

That’s Microsoft’s Proton chip, I believe.

Pluton rather than Proton, but yes.

Yes, that’s right, thanks!

I was always under the impression that once an attacker got physical access: all bets were off. Literally anything is possible at that point.

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.

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

> 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?

>> 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/Int...

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

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

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.

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...

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?

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.

Yeah I was unclear, it's supposed to address the physical attacks part. If no key leaves the CPU unwrapped, it's down to software exploits and decapping the CPU...

Gotcha. Yes

There's also this project https://www.cs1.tf.fau.de/research/system-security-group/tre... which reserves some CPU registers (iirc. A hardware aes accelerator on one core) to prevent key leakage.

Should protect against warm boot attacks since the key is supposed to be reset on CPU reboot.

Reply on news.ycombinator.com