5 ms·
> 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, [
by michaelt 2y ago
> 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 https://github.com/nccgroup/TPMGenie
- p_l 2y agoFunnily 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...
- SSLy 2y agovast majority of fTPM 2.0's are chips placed on the CPU die anyway
- p_l 2y agoit'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.
- baybal2 2y ago[dead]
- kukrimate 2y agoUnfortunately 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 2y agoWhy 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 2y agoBecause 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 2y ago> 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 2y ago> 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.
- Vogtinator 2y agoDoesn'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 2y agoI think he's saying you can verify the other end by manufacturing the PC yourself and making the initial connection in your factory.
- izacus 2y ago> 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?
- user_7832 2y agoThere might be hardware "solutions" to that problem.
- contingencies 2y agoI believe https://xkcd.com/538/ https://xkcd.com/538/ is the comic you're looking for.
- user_7832 2y agoLol that’s also true, though I was alluding to hardware sitting next to/after the keyboard. But whatever is easier I guess.
- wooosh 2y agoProbably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.
- izacus 2y agoAnd then return me my laptop and steal it again?
- xzjis 2y agoYou 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.
- Foxboron 2y agoBUS 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 https://www.dlp.rip/tpm-genie
- kukrimate 2y agoThe 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 2y ago> 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 2y ago> 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.
- zoeysmithe 2y agoand 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.