[michaelt]

> If attacker have physical access, the discrete TPM is an attack surface anyway and even a known attack already.

If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications.

The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-called "trusted execution environment" so there's no I2C to interpose. Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger.

[1] https://github.com/nccgroup/TPMGenie

[p_l]

Funnily enough, in TPM 2.0 there's way around MITM attacks like that - you can establish encrypted connection between TPM and CPU, which outside first-time configuration (which should happen in controlled environment anyway) should provide reasonable roadblock to successful MITM attack.

But CPU-side software needs to use it, and without default well-known keys...

[Vogtinator]

Doesn't work either: To establish the secure connection, you need some way to verify the other end (through public keys, certificates). That verification happens before any measurements can be done securely, so it can be bypassed.

[IshKebab]

I think he's saying you can verify the other end by manufacturing the PC yourself and making the initial connection in your factory.

[kukrimate]

Unfortunately encrypted sessions without an interactively provided secret like a PIN are no defence against attacker with physical access.

You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.

[wtallis]

Why doesn't a key exchange in a secure environment before any attacker has physical access give the same security benefits of "an interactively provided secret like a PIN"?

[kukrimate]

Because where do you store the CPU side private key after the exchange for future sessions?

The secure storage is the TPM, but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem.

Thus your secret could only be on disk or in flash in and the attacker can just get it.

[oasisaimlessly]

> Because where do you store the CPU side private key after the exchange for future sessions?

eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

> CryptoAuthentication devices have full metal shields over all of the internal circuitry, so that if an attacker cuts or short circuits any trace in the shield, the product stops functioning.

[kukrimate]

> eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

To clarify, I was referring to the status quo of current discrete TPM implementations, from a bigger picture perspective, there is certainly room for improvement.

Also I am not sure the current TPM standard is compatible with that idea at all. Operating systems set up their own TPM sessions, so there would need to be secret storage only available to a specific operatings system, e.g. similar to what TPM provides, and we are back to the chicken and egg scenario.

[SSLy]

vast majority of fTPM 2.0's are chips placed on the CPU die anyway

[p_l]

it's a misnomer, a bit.

fTPM is a firmware-based TPM implemented, usually, by coprocessor (or trustzone style enclave) inside the CPU, yes. It's not related to what TPM standard it implements

You can also have external TPM 2.0 compliant devices (commonly referred to as dTPM, probably brought the naming from iGPU/dGPU), and in fact many options offered for making desktops fully compliant with windows 11 (which requires TPM 2.0) involve a dedicated TPM 2.0 chip.

Ultimately, TPM standard does not care where the chip is, it just provides mechanisms for their use, which do include encrypted tamper protected interface... if one wants to use it.

[SSLy]

You're correct, but also I'm reasonably certain that, as much bullshit the list of Win 11 supported CPUs is, all the CPUs on it have fTPM 2.0 available.

[p_l]

In practice it's a matter of how the motherboard firmware is set up, so there's a lot of possible breakage.

[Foxboron]

BUS interposers are trivially defeated with encrypted sessions and a PIN.

Bitlocker is traditionally the implementation susceptible for this attack, but for that I'll just defer to Chris Fenner.

https://www.dlp.rip/tpm-genie

[kukrimate]

The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them all, e.g. desoldering the chip and connecting it to a microcontroller you control)

I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opinion is unattended unlock.

I think discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC to defend against such attacks.

[transpute]

> discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC

What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators?

Should system attestation roots of trust be based on open-source firmware?

Recent AI/Copilot PCs based on Qualcomm SDXE/Oryon/Nuvia, AMD Zen5 and Intel Lunar Lake include Microsoft Pluton.

[kukrimate]

> What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators?

I am not familiar enough of the technical details of Pluton or OpenTitan to make a meaningful statement on their security.

> Should system attestation roots of trust be based on open-source firmware?

Yes, and not only root of trusts, I am strong believer in open source firmware in general. I have been developing coreboot as a hobby for a long time. I wish their was more industry support for such things, especially at the lowest levels of modern systems.

[transpute]

Microsoft has supported open firmware for OCP Caliptra RoT, https://news.ycombinator.com/context?id=40131126

Hopefully we will see open firmware (Rust TockOS) on some version of Pluton, https://news.ycombinator.com/context?id=40557081

[logical_person]

> encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation

this is completely incorrect, encrypted sessions defeat TPM interposers when there is a factory burned-in processor side secret to use. lol at being just "obfuscation" because you can spend $5m to decap and fetch the key then put the processor back into working order for the attack.

that just requires a vertically integrated device instead of a consumer part-swappable PC.

[kukrimate]

What you are saying is sound, and I agree it could be done.

But there are multiple caveats: - How do you hide the secret so that only "legitimate" operating systems can use it for establishing their sessions and not "Mate's bootleg totally not malware live USB"? - And unfortunately current CPUs don't implement this. - Additionally don't be so smug to think you need to decap a CPU to extract on-die secrets. Fault injection attacks are very effective and hard to defend against.

I agree the security of this can somewhat be somewhat improved, but if you are building a custom CPU anyhow, you might as well move the TPM on-die and avoid this problem entirely.

[logical_person]

before the popularity of ARM SoCs that contain everything on-die there were much fewer choices for vertically integrated devices. it's a different segment.

if you look at apple's vertically integrated devices, they chose a cryptography coprocessor that was not on die originally. with a key accessible only by both pieces of silicon's trusted execution environments, rather than the operating system directly, encrypted comms are established in a similar fashion as the TPM2.0 proposal.

[dTal]

>robust system state attestation (both local and remote) against attackers with physical access

Phrases like this give me the shivers, as it translates into "mandatory surveillance by some authority telling me what I can and can't do with my computer".

TPM is an evil concept. Physical access should be final.

[kukrimate]

Is anyone here talking about survaillance??

That "attestation" in the full disk encryption case means your disk encryption key only being available to the operating system you chose to install. And disallowing the ability of a laptop thief to change that.

Or remote attestation can be used to restrict access to a corporate network to corporate controlled devices only. No one surveills you, or has access to your device in this scenario either, the TPM there is used to produce a certificate of the device state that can effectively act as access credentials to a resource.

This is about recognising the fact that the person in physical possession of a device isn't necessarily the legitimate owner.

[brendank310]

I get the reaction, but what about the trust factor of a box you own and have running on the other side of the world? TPM isn’t an evil concept, it’s fairly useful for some scenarios. Coercion to use TPMs, that sounds evil.

[tiberious726]

So I get my hands on your laptop for a few minutes, there should be nothing you can do to impede me from doing whatever I want to it?

TPMs are awesome of you use them correctly, it's like having a yubikey built into your computer

[dTal]

>So I get my hands on your laptop for a few minutes, there should be nothing you can do to impede me from doing whatever I want to it?

Correct. This is true of all my other possessions as well.

Ultimately, the physical hardware of the computer cannot tell the difference between a legitimate user and an illegitimate one. The distinction is social, not mathematical - the kind of thing one might litigate in court, rather than by multiplying some large primes together. Technologically enforcing the concept of ownership over an object implies the construction of a parallel, extra-legal system of rights management, with some final higher authority that is neither you nor in all likelihood your government. Here's how that plays out: yes, you paid for the computer, yes, you "legally" own it, but you did something to it that Microsoft doesn't approve of and so we're afraid it doesn't work anymore. Might makes right. Too bad!

[cryptonector]

Problem is that the BCM and the BIOS/UEFI and every component talking to the TPM all need to store one (or more) public keys for it (and the corresponding templates and/or save files) in order to set up encrypted sessions to the TPM.

[izacus]

> Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger.

How would that attack work if someone stole my Ryzen powered laptop with full disk encryption, TPM2.0 and secure boot with firmware password enabled?

[blueflow]

I'd buy you an replacement laptop of the same model and then install a rendering of your boot process and password prompt on it. Doing a switcheroo and waiting in my bunker until the fake sends me the password you entered.

The screen/keyboard is not authenticated to the user, and TPM is not capable of fixing that.

It doesn't require some state actor to do that. Just money.

[Foxboron]

`tpm2-totp` defeats the entire "replace the laptop" threat scenario.

https://github.com/tpm2-software/tpm2-totp

[blueflow]

The "replaced laptop" scenario is a full MITM on the hardware. TOTP generally does not protect against MITM. The required TOTP code is, in this scenario, generated by the device in the attackers hand. So the fake could also display it.

[Foxboron]

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop?

The TOTP token here is sealed inside TPM.

[blueflow]

And what do you need to do to unseal it? And why cant the fake laptop relay that to the real laptop?

[dist-epoch]

A solution would be to have two passwords, and display a secret security image between them.

User is required to not enter the second password if the wrong security image is displayed.

You can still attack it with a fancy radio transmitter which transmits the security image from the stolen laptop when it's displayed after you've entered the first password to the second laptop.

[p_l]

Attestation closes this vulnerability, for example through tools like Ultrablue [1] which provides a self-hosted method of verifying that the TCB has not been modified through external tool (in this case, your phone running Ultrablue)

[1] https://github.com/ANSSI-FR/ultrablue

[blueflow]

The TCB has not been modified - that's the point of that attack. Its just physically elsewhere. A high 24 dBi high gain antennae to close that gap costs 70 EUR and you would attest the device in the attackers hands, not the one in front of you.

[hedora]

I think some of those hardware attestation thingies use clocks and tight latency jitter bounds to make replay attacks harder. If it takes more than "2 x time light takes to move 10 ft + deterministic delay from the other side", or less than the deterministic delay, then they refuse to unlock.

Some cars even get this right these days. Most don't.

[fargle]

i like the way you think

[wooosh]

Probably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.

[izacus]

And then return me my laptop and steal it again?

[xzjis]

You have to consider what kind of risk you are protecting yourself against.

It's highly unlikely that you would be the target of such a highly sophisticated attack, but a hacker could get into a place where you left your computer without surveillance (such as your home or a hotel) for about 15 minutes, and install it inside your computer.

If you think you could be the target of such an attack, you could maybe enable an alert in the settings of your UEFI if your computer has been opened (I know that my ThinkPad has that option), or the better option is to always keep your laptop with you.

[izacus]

I'm mostly asking because the original poster was painting a process that can be sniffed off the bus (that is - buy a stolen laptop off ebay, try to boot it, sniff the key off the bus) with a process that requires active targeting and multiple breakins to work as equivalent.

It seems like these security discussions always devolve into rather funny moving of goalposts without actually considering how much work each exploit requires.

[michaelt]

The goalposts haven't moved in my mind, but I suppose I didn't make them clear in my first post.

Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely.

And for casual home Windows users, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too. If every OS now needs Microsoft's signature of approval, or a really fiddly setup process? Well they were running Windows anyway, so no problem.

These usability/support benefits rely on self-unlocking disk encryption, which is vulnerable to sniffing if someone gets a stolen laptop on ebay.

For the kind of technically sophisticated, security enthusiast users who comment on blog posts about TPMs? We're more than happy to key in a strong unique password at every boot, and if we forget the password and lose access to everything on that disk that's just the system working as it's supposed to.

For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.

[michaelt]

A high grade hardware implant doesn't just capture your password, it'll also replay your password along with a curl | sudo bash at 4am

[rwmj]

Bluetooth keyloggers are a thing. The attacker would need to be nearby.

[xattt]

Not if there’s some sort of cell bridging device nearby as well.

[HeatrayEnjoyer]

Relays can be prevented with a round-trip timeout. Limit to 8ft/c, should be plenty for a keyboard. You can't outpace light.

[izacus]

I'd have to use bluetooth keyboard then, right?

[Foxboron]

Glitter nailpolish on your machine seams/screws and tamper detection. Keyboard sniffing is not as trivial as people make it out to be.

[fellerts]

I doubt your physical keyboard's connection to the motherboard is encrypted (I'd guess USB, I2C or maybe even PS/2 internally). I would also not be surprised if you can get small in-line sniffers that an attacker, with physical access for half an hour, could hide in your laptop.

All bets are off if your attacker is determined and has physical access.

[atoav]

There have been papers about extracting key presses from acceleration sensors of a phone, or from the sounds of key clicking by statistical inference what feels like a decade ago. You probably don't even need to touch the laptop to do that.

[izacus]

I mean, I wouldn't be there to type in my password because the laptop was stolen.

[user_7832]

There might be hardware "solutions" to that problem.

[contingencies]

I believe https://xkcd.com/538/ is the comic you're looking for.

[user_7832]

Lol that’s also true, though I was alluding to hardware sitting next to/after the keyboard. But whatever is easier I guess.

[zoeysmithe]

and by recent, TPM was external last in gen 8 of intels, so this attack works on cpus released last in October 2017. That's almost 7 years ago. Most organizations have a 3-5 year replacement schedule.