It says any TPM can be defeated in 2-3 hrs with physical access. Is the AMD one different? Can it be defeated over networks? And is this something I should be concerned about since I just bought a new AMD machine?
When TPMs became popular, dedicated TPMs were mainly used, being a separate chip on the mainboard connected via the SPI or LPC bus. These were prone to (relatively primitive) bus sniffing attacks, where you would hook up a Logic Analyzer to the bus, watch a regular boot procedure grab the disk key, and then use software like Dislocker to extract all data from a USB Live Linux or alike.
Nowadays, most modern CPUs (both on Intel and AMD) ship firmware TPMs that are "included" with CPU die, making them safe against the bus sniffing attacks. However, they can still be prone to more sophisticated attacks like ours.
they are for boot chain security which is an essential featur for any laptop
TPM by itself never prevents anyone from doing anything
but it's used with features like secure boot, but as long as they fully implement the spec they don't prevent you from doing with your laptop what you want as long as you don't install software which does so
secure enclave and similar used for DRM isn't directly a TPM feature but more an extension using TPM and other CPU features
and yes it can be used to security store keys in your hardware. Any keys! A feature any user understanding security would appreciate.
For DRM to work, it has to be running in a trusted environment where the user can’t just load up a debugger as superuser and read the keys from memory.
The way you do that is by using secure boot to ensure that you are running a trusted kernel that enforces appropriate access controls… which requires TPM.
One of the main selling points of TPM is that you have chain of trust to ensure the boot process wasn’t tampered by a rogue boot loader that modified your code. And, yes, that has security benefits as well, but don’t for a second think that DRM wasn’t a major consideration.
and attacks which mess with the boot chain have been a huge problem for a long time for enterprises, TPM likely would have ended up very similar to how it did even if there wouldn't be DRM. Also the DRM lobby has since a long time pushed for moving (parts of) the DRM into the firmware (i.e. in a context where TPM doesn't matter much), which is where vendor-locked secure enclaves and similar come in which are related to TPM2.0 but not the same. For example on some ARM/Android chips part of the DRM system is in a locked secure co-processor.
And just because something can be abused doesn't mean it isn't useful or it's fundamentally bad. Through you seem to be making exactly that argument now with a "but it was designed with bad things in mind" added, which is a IMHO pointless argument. What matters is what it _is now_, not why it ended up there.
And what it is now is an _essential_ security feature for laptops, which also can be abused iff used in combination with some other features and that other features are tweaked to harm the user (e.g. don't allow custom keys for secure boot).
Yes, I am aware of that. But having DRM that is not completely ineffective has a prerequisite that it runs on a kernel that does enforce those access controls. The only way that works is with a trusted boot chain.
You originally responded “no” to a post saying that one purpose of TPM is to facilitate DRM.
The fact that both TEE and fTPM run on the PSP (or AMD-SP) might add a little confusion, but is nevertheless interesting.
I was using the phrase “trusted environment” more generally than that.
I do not mean a separate environment from the main CPU. Rather, that applications (like software DRM, or even the graphics driver) running on the CPU can’t trust the OS to enforce access controls without a secure boot environment.
How do you know that windows won’t let the user spin up a debugger and dump all your memory (or load a modified driver that lets them dump the frame buffer after content has been decrypted) for later use?
You need to trust that you are running in an environment where users haven’t just loaded whatever kernel modules or graphics drivers they want.
TPM is generally how you get a secure boot chain, so it is a prerequisite. Hence, TPM facilitates DRM.
https://www.reddit.com/r/pcgaming/comments/phutif/riot_games...
Part of that is things like:
* Don’t load an unsigned (or wrongly-signed) GPU driver, because it might be modified to allow a user to read from framebuffer memory after content has been decrypted.
I imagine that the MPAA et. al. are planning to attack the splitter thingy one day, so they’ll want to make sure you can’t slurp the frame buffer when that avenue is gone.
The TPM supports encrypted sessions, but they are opt in. See Parameter Encryption in the TPM spec. The issue is that Bitlocker doesn't use them for whatever reason. If Bitlocker turned on encrypted sessions, it would be not possible to sniff the key. It's crazy that Microsoft keep things insecure.
"Motivated by Windows 11’s push to use the TPM for even more applications, we apply the vulnerability to Microsoft BitLocker and show the first fTPM-based attack against the popular Full Disk Encryption solution. BitLocker’s default TPM-only strategy manages – without any changes to the user experience – to swiftly step up a user’s security in the face of a lost or stolen device. However, as our work complements the established at- tacks against dTPMs with an even more potent attack against AMD fTPMs, a TPM-only configuration lulls a non-technical user with high protection needs into a false sense of security."
"Users who fear a physical attacker with reasonable resources should opt for a TPM and PIN configuration. When BitLocker identifies that the underlying TPM is an fTPM, users should be urged to turn their PIN into a passphrase."
And there's probably some large enterprises that use regular Linux desktops with LUKS/Btrfs/ZFS encryption in TPM only mode, to match their Windows setups. Systemd e.g. added systemd-cryptenroll with ergonomics comparable to Windows' Bitlocker enrollment.
its a very convenient feature
through is not convenient to setup
and a lot of Linux users never trusted it to be secure, i. e. a lot of people expected an attack like this sooner or later
at least the recent ubuntu versions when using the default full disk encryption setup do setup decryption using TPM you still need an additional password as without you would e.g. lose access to your data if you change some hardware, you motherboard brakes or depending on how they set it up you also need the password after kernel upgrades etc.
but the vulnerability allow someone with hardware access to access all your data by booting their code but messing with the TPM in a way where it still measures as if it's was booting your code
When our attack is successfully executed on a target, this means that TPM+PIN is broken on systemd-cryptenroll, and as secure as PIN-only with the same PIN on BitLocker.
this makes it very very unlikely to be usable in a virus or remote attack
but if you lose your arm laptop and didn't use a encryption password you might want to consider your data leaked
also I would treat Intel cpus the same, Intel having a similar vulnerability is not unlikely