4 ms·

no 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 fe

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

labcomputer 4y ago
Erm… yes, actually. 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.
- dathinab 4y ago
  no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls and in a full secure boot implementation the user can freely choose what _they_ trust 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).
  - labcomputer 4y ago
    > no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls 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.
- hnj2 4y ago
  Author here: TPMs are not a TEE (trusted execution environment), and the TEE included in AMD's CPUs function completely separately from the TPM. So you could disable the TPM and still have the TEE run DRM code. The fact that both TEE and fTPM run on the PSP (or AMD-SP) might add a little confusion, but is nevertheless interesting.
  - labcomputer 4y ago
    > TPMs are not a TEE (trusted execution environment), 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.
  - bo1024 4y ago
    Thanks for this clarification!
- yrro 4y ago
  There is some confusion because there _are_ DRM systems that require users to use Secure Boot with a TPM: https://www.reddit.com/r/pcgaming/comments/phutif/riot_games_valorant_enforcing_tpm_20_and_secure/ https://www.reddit.com/r/pcgaming/comments/phutif/riot_games...
  - officeplant 4y ago
    How am I not surprised to find our favorite kernel level anti-cheat company doing this.

labcomputer 4y ago

Erm… yes, actually. 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.

dathinab 4y ago
no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls and in a full secure boot implementation the user can freely choose what _they_ trust 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).
- labcomputer 4y ago
  > no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls 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.
hnj2 4y ago
Author here: TPMs are not a TEE (trusted execution environment), and the TEE included in AMD's CPUs function completely separately from the TPM. So you could disable the TPM and still have the TEE run DRM code. The fact that both TEE and fTPM run on the PSP (or AMD-SP) might add a little confusion, but is nevertheless interesting.
- labcomputer 4y ago
  > TPMs are not a TEE (trusted execution environment), 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.
- bo1024 4y ago
  Thanks for this clarification!
yrro 4y ago
There is some confusion because there _are_ DRM systems that require users to use Secure Boot with a TPM: https://www.reddit.com/r/pcgaming/comments/phutif/riot_games_valorant_enforcing_tpm_20_and_secure/ https://www.reddit.com/r/pcgaming/comments/phutif/riot_games...
- officeplant 4y ago
  How am I not surprised to find our favorite kernel level anti-cheat company doing this.