7 ms·

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporation

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporations? Whose computer is this, anyway?

jeroenhd 3y ago
Mine, and I like it to stay that way. A TPM can be a valuable tool for protecting my data, making it difficult if not impossible for anyone to decrypt my drives. TPM+PIN is hard to beat.
- taraharris 3y ago
  TPM's true owner is the NSA, not you or I. https://www.stat.rice.edu/~dobelman/kstorm.txt https://www.stat.rice.edu/~dobelman/kstorm.txt https://news.ycombinator.com/item?id=6337282 https://news.ycombinator.com/item?id=6337282 https://www.militaryaerospace.com/computers/article/16711478/nsa-teams-with-trusted-computing-group-on-software-could-help-secure-the-supply-chain https://www.militaryaerospace.com/computers/article/16711478... https://www.businessinsider.com/leaked-german-government-warns-key-entities-not-to-use-windows-8--links-the-nsa-2013-8 https://www.businessinsider.com/leaked-german-government-war... https://supplychaindigital.com/technology/nsa-trusted-computing-group-and-intel-collaborate-standardise-supply-chain-risk-management https://supplychaindigital.com/technology/nsa-trusted-comput... https://redmondmag.com/articles/2013/08/22/windows-8-security-issues?m=1 https://redmondmag.com/articles/2013/08/22/windows-8-securit... https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-trusted-computing-in-the-post-snowden-age/ https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-...
  - charcircuit 3y ago
    Protecting American's, American businesses', and the American government's security is in the interest of the NSA.
    - BlueTemplar 3y ago
      Probably, but the biggest issue here is that most people aren't American, even on this website.
      - charcircuit 3y ago
        The technology doesn't discriminate people based on their nationality. Secure products are being built and exported to the rest of the world.
  - cryptonector 3y ago
    The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're wrong: > It is also important to note that any user concerns about TPM 2.0 are addressable. The first concern, generally expressed as "lack of user control," is not correct as OEMs have the ability to turn off the TPM in x86 machines; thus, purchasers can purchase machines with TPMs disabled (of course, they will also be unable to utilize the security features enabled by the technology). The second concern, generally expressed as "lack of user control over choice of operating system," is also incorrect. In fact, Windows has been designed so that users can clear/reset the TPM for ownership by another OS of they wish. Many TPM functions can also be used by multiple OSes (including Linux) concurrently. This refers to the fact that you can: - disable the TPM if you don't want to use it - change the platform/endorsement/owner hierarchies' seeds, delete all the platform and endorsement certificates, and thus render any agreements between the NSA and the TPM manufacturers useless to backdooring the host (unless the agreement involves voluntary vulnerabilities in the TPM's firmware) The last article you link to is much more interesting because it actually involves thinking about how the NSA (or other such agency) could have a backdoor inserted into the TPM: > However, such “trust” can be easily misused to break security. In the talk, I used TPM as an example. Suppose TPM is used to implement secure data encryption/decryption. A standard-compliant implementation will be trivially subject to the following attack, which I call the “trap-door attack”. The TPM first compresses the data before encryption, so that it can use the saved space to insert a trap-door block in the ciphertext. The trap-door block contains the decryption key wrapped by the attacker’s key. The existence of such a trap-door is totally undetectable so long as the encryption algorithms are semantically secure (and they should be). Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately. That doesn't mean that there aren't other backdoors. For example, the ciphertext could be larger than necessary rather than use a compression of the plaintext. But this too fails because the sizes of the ciphertexts are easy to determine from the plaintext sizes. The best way to add a backdoor is to have secret commands that use public keys for authentication (and even encryption) so that you have to know the backdoor in order to be able to use it. I cannot prove that there is no such backdoor, but if you have the means to decap and reverse engineer a dTPM then you can do this.
- deleted 3y ago
  [deleted]
- nly 3y ago
  TFA literally shows a TPM+PIN is totally insufficient to protect your data
  - DethNinja 3y ago
    Why is PIN insufficient? Assuming encryption algorithms are sane, a 20 character long PIN should be able to achieve adequate entropy to keep the data safe.
  - cryptonector 3y ago
    By... compromising the SP, thence the fTPM, but compromising the SP is sufficient to compromise the whole host so...
dathinab 3y ago
Mine and I want a TPM, it's a device essential for modern laptop security. _Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_ through potential a different implementation and not some of the features build on top of it like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the EFI itself) would probably be a convenient, simple, way to have the necessary security without many of the problems ... or did I just reinvent TPM ?
- als0 3y ago
  TPM is more or less an API specification. The specification is fine but people are worried about implementation backdoors and pre-provisioned keys. It should be possible to have an open source public trustable implementation that anyone can synthesise onto an FPGA or a real chip design. This ought to avoid fears about backdoors, while keeping a mature security model and good software support. I suspect there isn't sufficient demand or skill for such a project.
  - dathinab 3y ago
    > I suspect there isn't sufficient demand or skill for such a project. IMHO more like: There is little to no profit in this, nor much motivations for AMD/Intel to provide this. But it does involve additional work, especially if the fTPM implementation they use currently does (partially) use code they got from other companies which they can't open source. Through you wouldn't need a FPGA, for a TPM to really be secure you want it to be integrated into the CPU. And most times this means it's not a "special" physical chip but just a "standard co-processor" running some software. E.g. in case of ARM Android smart phones it's likely a more or less normal Cortex M0 processor (and it likely runs more then "just" a TPM, e.g. some DRM pipe protection code). So theoretically you would just need to publish the "bar metal" code and anyone could analyze it and then build and run it e.g. using qemu (if qemu can handle co-processors idk.). And by also allowing to extract the build code from the CPU combined with reproducible builds you could also verify it runs what it says it runs (kinda, I mean who says there isn't a hardware backdoor rewriting the code, and it being a FPGA doesn't help there because the FPGA hardware could also rewrite the FPGA bin-code.... at least theoretically)
flangola7 3y ago
Without a TPM servers can't verify that their genuine app is being used. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...
- gkbrk 3y ago
  Why would users want a server to know they're using their official crapware or an alternative/modded client that serves users better? Surely the device should serve the interests of the user that pays for it, and not some random developer.
  - flangola7 3y ago
    1 is anti cheat.
- MrStonedOne 3y ago
  Why should they have that right?
  - flangola7 3y ago
    What do you mean? It's their server, their service.
cryptonector 3y ago
This isn't a TPM spec vulnerability. This is a CPU (SP) vulnerability, and it's devastating regardless of whether you use a TPM or not. TFA is fine, but thinking that this is specifically a vulnerability because of TPM is a serious mistake. Not using a TPM won't make you safer.
rasz 3y ago
Obviously computer belongs to Microsoft. They are the ones paying for AMD SOC development and millions of units per year under multi year contracts.

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporations? Whose computer is this, anyway?

jeroenhd 3y ago

Mine, and I like it to stay that way. A TPM can be a valuable tool for protecting my data, making it difficult if not impossible for anyone to decrypt my drives. TPM+PIN is hard to beat.

taraharris 3y ago
TPM's true owner is the NSA, not you or I. https://www.stat.rice.edu/~dobelman/kstorm.txt https://www.stat.rice.edu/~dobelman/kstorm.txt https://news.ycombinator.com/item?id=6337282 https://news.ycombinator.com/item?id=6337282 https://www.militaryaerospace.com/computers/article/16711478/nsa-teams-with-trusted-computing-group-on-software-could-help-secure-the-supply-chain https://www.militaryaerospace.com/computers/article/16711478... https://www.businessinsider.com/leaked-german-government-warns-key-entities-not-to-use-windows-8--links-the-nsa-2013-8 https://www.businessinsider.com/leaked-german-government-war... https://supplychaindigital.com/technology/nsa-trusted-computing-group-and-intel-collaborate-standardise-supply-chain-risk-management https://supplychaindigital.com/technology/nsa-trusted-comput... https://redmondmag.com/articles/2013/08/22/windows-8-security-issues?m=1 https://redmondmag.com/articles/2013/08/22/windows-8-securit... https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-trusted-computing-in-the-post-snowden-age/ https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-...
- charcircuit 3y ago
  Protecting American's, American businesses', and the American government's security is in the interest of the NSA.
  - BlueTemplar 3y ago
    Probably, but the biggest issue here is that most people aren't American, even on this website.
    - charcircuit 3y ago
      The technology doesn't discriminate people based on their nationality. Secure products are being built and exported to the rest of the world.
- cryptonector 3y ago
  The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're wrong: > It is also important to note that any user concerns about TPM 2.0 are addressable. The first concern, generally expressed as "lack of user control," is not correct as OEMs have the ability to turn off the TPM in x86 machines; thus, purchasers can purchase machines with TPMs disabled (of course, they will also be unable to utilize the security features enabled by the technology). The second concern, generally expressed as "lack of user control over choice of operating system," is also incorrect. In fact, Windows has been designed so that users can clear/reset the TPM for ownership by another OS of they wish. Many TPM functions can also be used by multiple OSes (including Linux) concurrently. This refers to the fact that you can: - disable the TPM if you don't want to use it - change the platform/endorsement/owner hierarchies' seeds, delete all the platform and endorsement certificates, and thus render any agreements between the NSA and the TPM manufacturers useless to backdooring the host (unless the agreement involves voluntary vulnerabilities in the TPM's firmware) The last article you link to is much more interesting because it actually involves thinking about how the NSA (or other such agency) could have a backdoor inserted into the TPM: > However, such “trust” can be easily misused to break security. In the talk, I used TPM as an example. Suppose TPM is used to implement secure data encryption/decryption. A standard-compliant implementation will be trivially subject to the following attack, which I call the “trap-door attack”. The TPM first compresses the data before encryption, so that it can use the saved space to insert a trap-door block in the ciphertext. The trap-door block contains the decryption key wrapped by the attacker’s key. The existence of such a trap-door is totally undetectable so long as the encryption algorithms are semantically secure (and they should be). Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately. That doesn't mean that there aren't other backdoors. For example, the ciphertext could be larger than necessary rather than use a compression of the plaintext. But this too fails because the sizes of the ciphertexts are easy to determine from the plaintext sizes. The best way to add a backdoor is to have secret commands that use public keys for authentication (and even encryption) so that you have to know the backdoor in order to be able to use it. I cannot prove that there is no such backdoor, but if you have the means to decap and reverse engineer a dTPM then you can do this.
deleted 3y ago
[deleted]
nly 3y ago
TFA literally shows a TPM+PIN is totally insufficient to protect your data
- DethNinja 3y ago
  Why is PIN insufficient? Assuming encryption algorithms are sane, a 20 character long PIN should be able to achieve adequate entropy to keep the data safe.
- cryptonector 3y ago
  By... compromising the SP, thence the fTPM, but compromising the SP is sufficient to compromise the whole host so...

dathinab 3y ago

Mine and I want a TPM, it's a device essential for modern laptop security. _Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_ through potential a different implementation and not some of the features build on top of it like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the EFI itself) would probably be a convenient, simple, way to have the necessary security without many of the problems ... or did I just reinvent TPM ?

als0 3y ago
TPM is more or less an API specification. The specification is fine but people are worried about implementation backdoors and pre-provisioned keys. It should be possible to have an open source public trustable implementation that anyone can synthesise onto an FPGA or a real chip design. This ought to avoid fears about backdoors, while keeping a mature security model and good software support. I suspect there isn't sufficient demand or skill for such a project.
- dathinab 3y ago
  > I suspect there isn't sufficient demand or skill for such a project. IMHO more like: There is little to no profit in this, nor much motivations for AMD/Intel to provide this. But it does involve additional work, especially if the fTPM implementation they use currently does (partially) use code they got from other companies which they can't open source. Through you wouldn't need a FPGA, for a TPM to really be secure you want it to be integrated into the CPU. And most times this means it's not a "special" physical chip but just a "standard co-processor" running some software. E.g. in case of ARM Android smart phones it's likely a more or less normal Cortex M0 processor (and it likely runs more then "just" a TPM, e.g. some DRM pipe protection code). So theoretically you would just need to publish the "bar metal" code and anyone could analyze it and then build and run it e.g. using qemu (if qemu can handle co-processors idk.). And by also allowing to extract the build code from the CPU combined with reproducible builds you could also verify it runs what it says it runs (kinda, I mean who says there isn't a hardware backdoor rewriting the code, and it being a FPGA doesn't help there because the FPGA hardware could also rewrite the FPGA bin-code.... at least theoretically)

flangola7 3y ago

Without a TPM servers can't verify that their genuine app is being used. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...

gkbrk 3y ago
Why would users want a server to know they're using their official crapware or an alternative/modded client that serves users better? Surely the device should serve the interests of the user that pays for it, and not some random developer.
- flangola7 3y ago
  1 is anti cheat.
MrStonedOne 3y ago
Why should they have that right?
- flangola7 3y ago
  What do you mean? It's their server, their service.

cryptonector 3y ago

This isn't a TPM spec vulnerability. This is a CPU (SP) vulnerability, and it's devastating regardless of whether you use a TPM or not. TFA is fine, but thinking that this is specifically a vulnerability because of TPM is a serious mistake. Not using a TPM won't make you safer.

rasz 3y ago

Obviously computer belongs to Microsoft. They are the ones paying for AMD SOC development and millions of units per year under multi year contracts.