171–180 of 273 posts
Honestly TPM is probably creating more bad than good at this point. Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.
Also, made me remember (once again) decade old presentation on TPM: https://www.youtube.com/watch?v=XgFbqSYdNK4
anyone did similar tests to the el-cheapo ones that will end up on 99% of computers around the world?
My bet is that messing with voltages on those chips too will expose all sorts of exploits too.
Earlier quoted context omitted.
Microsoft is edging closer and closer to dropping support for Windows 10(even a computer I built in 2017 that's still running perfectly fine can't upgrade). But for many users, changing to another OS besides Windows is tantamount to not functioning, so planned obsolescence continues apace.
I wish there was a linux distro made by people who love windows, not linux.
Hell, I installed the Chicago95 XFCE theme on my main system to see how well it emulated the look and feel of Windows 95 and wound up liking it. Why? Because even though it looks dated, the icons were immediately familiar and I felt navigation instantly become easier.
Do not underestimate the power of familiarity. Many of us grew up on DOS/Windows playing games and typing school work up in Word so moving away from those familiar waters is HARD. It's like being an immigrant moving to a new country - you have to put in extra effort to learn to adjust to culture and language. Some can, some cant. YMMV.
It's worth mentioning that standalone TPM chips from Infineon and others are a lot more hardened than Intel or AMD's fTPMs. Infineon's TPMs are tested against fault injection attack, package removal, side channels and so on.
Please note, though, that's imperative to then go for a BitLocker TPM+PIN configuration at least. A standalone (discrete) TPM with TPM-only protectors can be attacked by bus sniffing, a hardware attack much simpler than ours. [1] The beauty of a discrete TPM is its anti-hammering protection, making a numerical PIN a very effective security measure (akin to a SIM/SmartCard). [1] https://www.sciencedirect.com/science/a…
The most important sentences of the article: "Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks [14] to extract a chip-unique secret from the targeted CPU." "The attack requires access to the motherboard of the target system (4.1), particularly its SPI bus and voltage regulators." In other words, it is required to open the laptop and connect custom (but cheap) hardware to the motherboa…
That said, even a host using a dTPM with proper authentication of the dTPM has a problem if the SP is vulnerable to voltage fault injection attacks, because even though SPI bus sniffing wouldn't yield the unlocked FDE keys, the attacker presumably could get full control of the CPU and recover the unlocked FDE keys there.
In other words, the problem here is the voltage fault injection vulnerabilities in general. The fTPM part of it is not as big a deal as the total compromise of the whole system due to those voltage fault injection vulnerabilities.
Honestly TPM is probably creating more bad than good at this point. Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.
The problem isn't the TPM. The problem is the CPU (SP) being vulnerable to voltage fault injection attacks. You could be using no TPM and still have all your secrets leak if the host is fully compromised.
The most important sentences of the article: "Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks [14] to extract a chip-unique secret from the targeted CPU." "The attack requires access to the motherboard of the target system (4.1), particularly its SPI bus and voltage regulators." In other words, it is required to open the laptop and connect custom (but cheap) hardware to the motherboa…
Note that the SPI bus sniffing attacks on dTPMs are simpler to mount (being passive) but also require direct access to the bus (motherboard), and unlike this attack can be prevented in software by knowing the public key of a primary key object on the TPM (e.g., the endorsement key) and using it to authenticate the TPM to the host. That said, even a host using a dTPM with proper authentication of the dTPM has a proble…
This won't help break a PIN that is protected by the dTPM, but it will fully break any protection relying on the host to verify a PIN. (Which is the default BitLocker behavior.)
Earlier quoted context omitted.
[flagged]
Better GNUinos or Trisquel, no propietary bits included.
Earlier quoted context omitted.
Eh, not a great bit of rhetoric. TPM = Trusted Platform Module. Trusted is an adjective modifying platform. The business case is that software should not run on untrusted platforms because hardware can always attack software. So, the promise is that TPM will allow software to guarantee* to users that the hardware is not malicious. * as much as one can guarantee anything in tech
I agree, my rhetoric on TPM is rather elementary. From my perspective TPM is mostly about compliance with security directives. Actual security engineers would realize the TPM's security provided is about as far as you can throw it. You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you.
All wrong, as others have pointed out. As for the last of the above, if the OEM includes (as they should) platform certificates for the TPM, then the TPM cannot have been swapped out while in transit w/o the OEM helping the attacker. For example, Dell includes platform certificates binding the TPM.
Earlier quoted context omitted.
TPM allows government to request your data in the first place. So it should not be trusted by individuals from the beginning.
Uhh what? How does that work? Where do they request it? The TPM manufacturer? Microsoft? TPMs aren't very secure and as a discrete component their connection to the CPU can be intercepted (unlike fTPM or apple's integrated solutions).. There's a big difference between having a deliberate backdoor and just a vulnerable design that can be exploited. I haven't seen them accused of being backdoored. Intel's ME (and AMD's…
The problem here is that while it is possible for a BMC / BIOS to know a dTPM's EKpub and use it to establish encrypted (and authenticated) sessions to the dTPM, most BMCs/BIOSes don't. This is a limitation on the host side, not the TPM side. I get that in total the vulnerability exists, but it doesn't have to, and TPM has a perfectly good solution for it. Take it up with the OEMs!