7 ms·

TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

189 points by osks 2y ago

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 ago
  Funnily 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 ago
    vast majority of fTPM 2.0's are chips placed on the CPU die anyway
    - p_l 2y ago
      it'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.
      - SSLy 2y ago
        You're correct, but also I'm reasonably certain that, as much bullshit the list of Win 11 supported CPUs is, all the CPUs on it have fTPM 2.0 available.
        p_l 2y ago
        In practice it's a matter of how the motherboard firmware is set up, so there's a lot of possible breakage.
    - baybal2 2y ago
      [dead]
  - kukrimate 2y ago
    Unfortunately 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 ago
      Why 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 ago
        Because 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 ago
    Doesn'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 ago
      I 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 ago
    There might be hardware "solutions" to that problem.
    - contingencies 2y ago
      I believe https://xkcd.com/538/ https://xkcd.com/538/ is the comic you're looking for.
      - user_7832 2y ago
        Lol that’s also true, though I was alluding to hardware sitting next to/after the keyboard. But whatever is easier I guess.
  - wooosh 2y ago
    Probably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.
    - izacus 2y ago
      And then return me my laptop and steal it again?
      - rwmj 2y ago
        Bluetooth keyloggers are a thing. The attacker would need to be nearby.
        2y ago
- Foxboron 2y ago
  BUS 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 ago
    The 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 ago
  and 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.
rf15 2y ago
> briefly grounding the reset pin of a discrete TPM device with a pair of tweezers Ah, the tweezers strike again, just not for Nintendo this time. Truly the most universal hardware hacking tool.
- bee_rider 2y ago
  I have to believe there are hardware engineers out there who know locking people out of their devices is essentially bad, and so they leave in those tweezer based attacks on purpose. Although, designing against physical attacks is very difficult, so I guess there’s no need to imagine a good-hearted conspiracy of conscientious hardware folks.
  - II2II 2y ago
    The problem with that approach is that it also weakens security for people who genuinely need it.
    - bee_rider 2y ago
      There’s some value to being able to lock a device against somebody who physically has control of it. Like it is nice that stolen iPhones have reduced value. But there’s a pretty big social harm to locking people out of their devices, like the generation of tech-illiterate kids growing up that haven’t been allowed to break their computers well enough to learn anything about them.
  - LeifCarrotson 2y ago
    The fundamental operation in hardware engineering is the digital signal, pulling a pin to one or zero - which is all the tweezer attack does. It's comparable to writing a byte of memory. Imagine how hard software security would be if your adversaries could write arbitrary data to your process: there's no ASLR or even an MMU to randomize trace layouts on physical circuit boards.
    - hun3 2y ago
RedShift1 2y ago
TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can't just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don't have to be a genius to figure that out...
- sim7c00 2y ago
  its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can't disable it (otherwise it's still tricky and possible to get around your protections likely). (windows -> process protection light / telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that's signed / secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...). If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey. that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).
  - RedShift1 2y ago
    Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.
    - Foxboron 2y ago
      It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain. This is a common misconception.
nottorp 2y ago
Can you use this to install linux on motherboards locked to windows boot loaders in firmware? :)
- kukrimate 2y ago
  No. But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please. Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.
  - Foxboron 2y ago
    > Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow. All of them. The Secured Core machines still allows you to reset Secure Boot into user mode as mandated by the spec.
    - josephcsible 2y ago
      Isn't this only true of x86 ones, not ARM ones?
      - Foxboron 2y ago
        If ARM implements the UEFI specification then there are escape hatches to enroll your own PKI. I don't own ARM machines with UEFI so I have no clue.
userbinator 2y ago
Good. The only widespread uses of TPM are as user-hostile as any other DRM scheme. Stallman was right: https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html (Last few paragraphs.) See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...
- mindslight 2y ago
  Not the only uses, but certainly all of the widespread implementations of trusted hardware just haven't been able to avoid that temptation of privileging the manufacturer while securing against the user themselves. Every little hole is another setback that keeps the designers/implementers working on this layer instead of starting to tighten the noose on the next one.
- kukrimate 2y ago
  TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of a device trying to access a corporate network. Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights. In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them. I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.) In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.
  - userbinator 2y ago
    Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights. AES and RSA are just algorithms, not implementations. I'd compare TPMs to HDCP, AACS, or CSS (the DVD one) instead.
anthk 2y ago
There's full fdisk encryption under OpenBSD and forcing the user to boot from USB.
StillBored 2y ago
Ok, I understand how a TPM gets attached to a muxable GPIO block. But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions? So, IMHO this starts as a hardware bug.
- marshray 2y ago
  The CPUs and OSs (other than Windows 11) support operation without any TPM. So either the pin is configurable, or you've wasted a pin that could otherwise be used for decorating the motherboard with RGB LEDs. Also, the pin layout has to be standardized by the socket specification (eg "LGA 2011"), which may have to retain compatibility for a decade or more. This strongly favors defining reconfigurable over fixed-function pins.
jwells89 2y ago
A bit tangential, but it’s a bit shocking how consistently bad firmware for x86 motherboards and laptops is, as is most visible in the UEFI configuration screen. It makes me wonder if a new entrant in the motherboard/laptop space couldn’t make a name for themselves by simply caring about the quality of their firmware and trying to make it good.
- justaj 2y ago
  Such an entrant exists. It's called Libreboot.

189 points by osks 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 ago
Funnily 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 ago
  vast majority of fTPM 2.0's are chips placed on the CPU die anyway
  - p_l 2y ago
    it'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.
    - SSLy 2y ago
      You're correct, but also I'm reasonably certain that, as much bullshit the list of Win 11 supported CPUs is, all the CPUs on it have fTPM 2.0 available.
      - p_l 2y ago
        In practice it's a matter of how the motherboard firmware is set up, so there's a lot of possible breakage.
  - baybal2 2y ago
    [dead]
- kukrimate 2y ago
  Unfortunately 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 ago
    Why 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 ago
      Because 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 ago
  Doesn'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 ago
    I 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 ago
  There might be hardware "solutions" to that problem.
  - contingencies 2y ago
    I believe https://xkcd.com/538/ https://xkcd.com/538/ is the comic you're looking for.
    - user_7832 2y ago
      Lol that’s also true, though I was alluding to hardware sitting next to/after the keyboard. But whatever is easier I guess.
- wooosh 2y ago
  Probably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.
  - izacus 2y ago
    And then return me my laptop and steal it again?
    - rwmj 2y ago
      Bluetooth keyloggers are a thing. The attacker would need to be nearby.
      - 2y ago
Foxboron 2y ago
BUS 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 ago
  The 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 ago
and 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.

rf15 2y ago

> briefly grounding the reset pin of a discrete TPM device with a pair of tweezers Ah, the tweezers strike again, just not for Nintendo this time. Truly the most universal hardware hacking tool.

bee_rider 2y ago
I have to believe there are hardware engineers out there who know locking people out of their devices is essentially bad, and so they leave in those tweezer based attacks on purpose. Although, designing against physical attacks is very difficult, so I guess there’s no need to imagine a good-hearted conspiracy of conscientious hardware folks.
- II2II 2y ago
  The problem with that approach is that it also weakens security for people who genuinely need it.
  - bee_rider 2y ago
    There’s some value to being able to lock a device against somebody who physically has control of it. Like it is nice that stolen iPhones have reduced value. But there’s a pretty big social harm to locking people out of their devices, like the generation of tech-illiterate kids growing up that haven’t been allowed to break their computers well enough to learn anything about them.
- LeifCarrotson 2y ago
  The fundamental operation in hardware engineering is the digital signal, pulling a pin to one or zero - which is all the tweezer attack does. It's comparable to writing a byte of memory. Imagine how hard software security would be if your adversaries could write arbitrary data to your process: there's no ASLR or even an MMU to randomize trace layouts on physical circuit boards.
  - hun3 2y ago

RedShift1 2y ago

TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can't just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don't have to be a genius to figure that out...

sim7c00 2y ago
its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can't disable it (otherwise it's still tricky and possible to get around your protections likely). (windows -> process protection light / telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that's signed / secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...). If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey. that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).
- RedShift1 2y ago
  Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.
  - Foxboron 2y ago
    It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain. This is a common misconception.

nottorp 2y ago

Can you use this to install linux on motherboards locked to windows boot loaders in firmware? :)

kukrimate 2y ago
No. But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please. Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.
- Foxboron 2y ago
  > Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow. All of them. The Secured Core machines still allows you to reset Secure Boot into user mode as mandated by the spec.
  - josephcsible 2y ago
    Isn't this only true of x86 ones, not ARM ones?
    - Foxboron 2y ago
      If ARM implements the UEFI specification then there are escape hatches to enroll your own PKI. I don't own ARM machines with UEFI so I have no clue.

userbinator 2y ago

Good. The only widespread uses of TPM are as user-hostile as any other DRM scheme. Stallman was right: https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html (Last few paragraphs.) See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...

mindslight 2y ago
Not the only uses, but certainly all of the widespread implementations of trusted hardware just haven't been able to avoid that temptation of privileging the manufacturer while securing against the user themselves. Every little hole is another setback that keeps the designers/implementers working on this layer instead of starting to tighten the noose on the next one.
kukrimate 2y ago
TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of a device trying to access a corporate network. Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights. In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them. I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.) In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.
- userbinator 2y ago
  Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights. AES and RSA are just algorithms, not implementations. I'd compare TPMs to HDCP, AACS, or CSS (the DVD one) instead.

anthk 2y ago

There's full fdisk encryption under OpenBSD and forcing the user to boot from USB.

StillBored 2y ago

Ok, I understand how a TPM gets attached to a muxable GPIO block. But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions? So, IMHO this starts as a hardware bug.

marshray 2y ago
The CPUs and OSs (other than Windows 11) support operation without any TPM. So either the pin is configurable, or you've wasted a pin that could otherwise be used for decorating the motherboard with RGB LEDs. Also, the pin layout has to be standardized by the socket specification (eg "LGA 2011"), which may have to retain compatibility for a decade or more. This strongly favors defining reconfigurable over fixed-function pins.

jwells89 2y ago

A bit tangential, but it’s a bit shocking how consistently bad firmware for x86 motherboards and laptops is, as is most visible in the UEFI configuration screen. It makes me wonder if a new entrant in the motherboard/laptop space couldn’t make a name for themselves by simply caring about the quality of their firmware and trying to make it good.

justaj 2y ago
Such an entrant exists. It's called Libreboot.