5 ms·

One of the authors here. This attack is relevant if your machine is physically exposed to attacks, e.g., in an office environment or while traveling, and if you

One of the authors here. This attack is relevant if your machine is physically exposed to attacks, e.g., in an office environment or while traveling, and if you don't use any additional pre-boot passphrase to protect the disk (but rely solely on AMD's fTPM). 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.

bo1024 3y ago
This is important because one purpose of TPMs is to prevent the owner of the machine from doing certain things (as in Digital Rights Management). And the owner of the machine presumably has physical access.
- dathinab 3y ago
  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 3y 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 3y 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 3y 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 3y 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 3y ago
- hoffs 3y ago
  No...
- Mindwipe 3y ago
  There aren't really any mainstream DRM systems that use a general computing platform TPM, precisely because they have a terrible track record of being breached.
  - labcomputer 3y ago
    The point isn’t to store keys in the TPM. The point is to ensure you’re running an unmolested version of Windows that will enforce whatever security controls the DRM maker wants to have. 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.
    - Sunspark 3y ago
      All this effort for nothing making life difficult for the end-user. Physical video splitters are a thing. They are asked to respect HDCP, but they don't have to. It's how streamers are able to play a game on their monitor while also streaming the video of them playing the game.
      - labcomputer 3y ago
        Oh, no argument from me there, I’m just pointing out that you kinda need TPM to make your DRM not trivially bypassable. 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.
- cryptonector 3y ago
  TPM can be used for DRM. If you roll all the hierarchy seeds though then the TPM can't be used for DRM and you can just be denied access to media. In order to use a TPM for DRM you need a fairly dystopian secure boot of a consumer OS that enforces all DRM -- this is very much a possibility, naturally, and TPM enables it but does not guarantee it (otherwise we'd already be there today, though we're heading in that direction now).
als0 3y ago
> 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. 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.
- hnj2 3y ago
  We haven't looked to much into encrypted sessions, but for anyone wondering how they prevent MITM attacks in such a scenario: systemd-cryptenroll seems to be ahead in this regard: https://github.com/systemd/systemd/commit/acbb504eaf1be51572b1c0d0d490ac478bc41c64 https://github.com/systemd/systemd/commit/acbb504eaf1be51572...
cryptonector 3y ago
Can you confirm that compromising the SP can compromise the whole system, therefore the focus on fTPM is a bit hyperbolic?

bo1024 3y ago

This is important because one purpose of TPMs is to prevent the owner of the machine from doing certain things (as in Digital Rights Management). And the owner of the machine presumably has physical access.

dathinab 3y ago
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 3y 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 3y 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 3y 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 3y 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 3y ago
hoffs 3y ago
No...
Mindwipe 3y ago
There aren't really any mainstream DRM systems that use a general computing platform TPM, precisely because they have a terrible track record of being breached.
- labcomputer 3y ago
  The point isn’t to store keys in the TPM. The point is to ensure you’re running an unmolested version of Windows that will enforce whatever security controls the DRM maker wants to have. 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.
  - Sunspark 3y ago
    All this effort for nothing making life difficult for the end-user. Physical video splitters are a thing. They are asked to respect HDCP, but they don't have to. It's how streamers are able to play a game on their monitor while also streaming the video of them playing the game.
    - labcomputer 3y ago
      Oh, no argument from me there, I’m just pointing out that you kinda need TPM to make your DRM not trivially bypassable. 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.
cryptonector 3y ago
TPM can be used for DRM. If you roll all the hierarchy seeds though then the TPM can't be used for DRM and you can just be denied access to media. In order to use a TPM for DRM you need a fairly dystopian secure boot of a consumer OS that enforces all DRM -- this is very much a possibility, naturally, and TPM enables it but does not guarantee it (otherwise we'd already be there today, though we're heading in that direction now).

als0 3y ago

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

hnj2 3y ago
We haven't looked to much into encrypted sessions, but for anyone wondering how they prevent MITM attacks in such a scenario: systemd-cryptenroll seems to be ahead in this regard: https://github.com/systemd/systemd/commit/acbb504eaf1be51572b1c0d0d490ac478bc41c64 https://github.com/systemd/systemd/commit/acbb504eaf1be51572...

cryptonector 3y ago

Can you confirm that compromising the SP can compromise the whole system, therefore the focus on fTPM is a bit hyperbolic?