4 ms·

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 the

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 4y 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 4y 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)
  - kfreds 4y ago
    As I'm sure you're aware FPGAs are nice because they can complicate things for an attacker in the physical supply chain. Andrew "bunnie" Huang did an excellent talk on the subject: https://www.youtube.com/watch?v=Hzb37RyagCQ https://www.youtube.com/watch?v=Hzb37RyagCQ
MrStonedOne 4y ago
Any security model that can not differentiate the device owner from a threat actor misses the point of who security is meant to protect. TPM and secure boot combined can create computers that run key-per-cpu encrypted system binaries that can not be modified by the device owner meaning next time microsoft does something fucky there will be no path out, no programs to disable it, its just how you have to live now. Its not worth it to head down that path.
kfreds 4y ago
You're spot on. TKey is based on ideas like TPM and DICE. Think of TKey as a TPM-in-time, and a discrete TPM on an x86 mainboard as a TPM-in-space. Both go through the load-hash-measure-trust/execute steps, but TKey only needs one hardware domain to accomplish this whereas a discrete TPM needs two. Measurements and their results need to be computed in a context that can't be subverted by the object that is being measured. In the discrete-TPM case the host loads and hashes the object and then sends it to the TPM before letting the object influence the host's control flow. The only difference in the TKey case is that instead of sending the hash to a TPM the TKey derives key material based on Hash(sk, Hash(object)) and then removes sk from RAM. This is roughly equivalent to TPM sealing. The TKey equivalent of TPM quoting/attestation would involve a signing step using sk, and leaving the resulting certificate in RAM before letting the object influence control flow. A downside to this approach is that each measurement creates another level in a PKI-like structure. If you do the same thing with a discrete TPM you can do multiple measurements and still only have one signature attesting all of them.
the8472 4y ago
If you could replace all the vendor keys (including the firmware signing keys) with your own then TPM could make sense. But today's TPMs don't support that.
- cryptonector 4y ago
  > If you could replace all the vendor keys [...] You very much can. It's trivial. TPMs have four key "hierarchies" each of which has a seed. Of those four, one (the "null" hierarchy) gets a random seed each time the TPM is reset, while the other three (the platform, endorsement, and owner hierarchies) have their seeds stored in EEPROM/NVRAM, and there are functions in the spec for replacing those with new, randomly generated seeds. All primary keys in a TPM are derived from seeds, and the derived keys are not stored anywhere -- they are always derived as needed from the hierarchy's seed and a given template. Therefore changing a hierarchy's seed loses all access to primary keys previously used in that hierarchy. All other keys are saved off-chip encrypted to a primary key. Thus rotating a hierarchy's see loses all access to all keys previously used in that hierarchy (not just the primary keys). The only thing here that is remotely problematic here is that you have to trust the TPM's RNG. If you're paranoid you might believe that the RNG is itself a PRNG with a hidden seed and that the manufacturer knows it. But if you roll the endorsement hierarchy seed and delete the endorsement key certificate from the TPM, then how will the manufacturer identify the TPM in order to look up its putative hidden RNG seed? Even if they could find it, how would they know which RNG output was used as the hierarchy's new seed? So, yes, you can "replace all the vendor keys". It really is trivial. However, before you do it you may want to use the existing keys and certificates to bootstrap (enroll) the host into your organization's network and then change the seeds and certify various public keys as derived after the seeds are changed so that you can continue using the TPM for attestation.
  - the8472 4y ago
    You cut off the "including the firmware signing keys" part, that's critical. Otherwise the vendor could be coerced or subverted to sign malicious firmware which then subverts your system at runtime. Only when you can bring your own keys for the entire boot and trust chain can you untether yourself from the vendor once you have purchased the hardware.
cryptonector 4y ago
TPM 2.0 is a fantastic spec. There's little that's wrong with it. Even the bus sniffing vulnerabilities w/ dTPMs aren't TPM's fault but the BMC's and BIOS', as there is absolutely a way to encrypt and authenticate secrets to/from the TPM. Reinventing this wheel will probably lose a lot of good things. People who reinvent wheels often fail to understand what came before.
- flangola7 4y ago
  Encrypting bus traffic? What kind of mission impossible spy is this supposed to protect from?
  - astrange 4y ago
    That's how console jailbreak mods have worked in the past. The important keyword is authenticated though. If it's not authenticated you can corrupt it.
    - flangola7 4y ago
      They're doing all this to prevent... console jailbreaks? I would have expected some kind of national security use case.
      - astrange 4y ago
        National security information is usually in a better protected environment than a game console or your laptop.
  - cryptonector 4y ago
    The passive attacks on dTPMs in question require physical access, and opening the computer (and can be defeated with software). That is a pretty unlikely event for most users' computers. Active attacks (which can also be defeated with software) are more interesting because those are more likely, since the user doesn't have to cooperate with the attacker in those attacks.
akira2501 4y ago
Is a non removable TPM actually the right level of security? It feels like the same level of security I would get by having one of those realtor lock boxes permanently affixed to my front door and always keeping my house key in it. Maybe the key itself is "more secure" because it only lives in the lockbox and is only taken out to unlock the front door and then put back right away. Is this the right system for actually securing access to my home, though?

als0 4y 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 4y 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)
- kfreds 4y ago
  As I'm sure you're aware FPGAs are nice because they can complicate things for an attacker in the physical supply chain. Andrew "bunnie" Huang did an excellent talk on the subject: https://www.youtube.com/watch?v=Hzb37RyagCQ https://www.youtube.com/watch?v=Hzb37RyagCQ

MrStonedOne 4y ago

Any security model that can not differentiate the device owner from a threat actor misses the point of who security is meant to protect. TPM and secure boot combined can create computers that run key-per-cpu encrypted system binaries that can not be modified by the device owner meaning next time microsoft does something fucky there will be no path out, no programs to disable it, its just how you have to live now. Its not worth it to head down that path.

kfreds 4y ago

You're spot on. TKey is based on ideas like TPM and DICE. Think of TKey as a TPM-in-time, and a discrete TPM on an x86 mainboard as a TPM-in-space. Both go through the load-hash-measure-trust/execute steps, but TKey only needs one hardware domain to accomplish this whereas a discrete TPM needs two. Measurements and their results need to be computed in a context that can't be subverted by the object that is being measured. In the discrete-TPM case the host loads and hashes the object and then sends it to the TPM before letting the object influence the host's control flow. The only difference in the TKey case is that instead of sending the hash to a TPM the TKey derives key material based on Hash(sk, Hash(object)) and then removes sk from RAM. This is roughly equivalent to TPM sealing. The TKey equivalent of TPM quoting/attestation would involve a signing step using sk, and leaving the resulting certificate in RAM before letting the object influence control flow. A downside to this approach is that each measurement creates another level in a PKI-like structure. If you do the same thing with a discrete TPM you can do multiple measurements and still only have one signature attesting all of them.

the8472 4y ago

If you could replace all the vendor keys (including the firmware signing keys) with your own then TPM could make sense. But today's TPMs don't support that.

cryptonector 4y ago
> If you could replace all the vendor keys [...] You very much can. It's trivial. TPMs have four key "hierarchies" each of which has a seed. Of those four, one (the "null" hierarchy) gets a random seed each time the TPM is reset, while the other three (the platform, endorsement, and owner hierarchies) have their seeds stored in EEPROM/NVRAM, and there are functions in the spec for replacing those with new, randomly generated seeds. All primary keys in a TPM are derived from seeds, and the derived keys are not stored anywhere -- they are always derived as needed from the hierarchy's seed and a given template. Therefore changing a hierarchy's seed loses all access to primary keys previously used in that hierarchy. All other keys are saved off-chip encrypted to a primary key. Thus rotating a hierarchy's see loses all access to all keys previously used in that hierarchy (not just the primary keys). The only thing here that is remotely problematic here is that you have to trust the TPM's RNG. If you're paranoid you might believe that the RNG is itself a PRNG with a hidden seed and that the manufacturer knows it. But if you roll the endorsement hierarchy seed and delete the endorsement key certificate from the TPM, then how will the manufacturer identify the TPM in order to look up its putative hidden RNG seed? Even if they could find it, how would they know which RNG output was used as the hierarchy's new seed? So, yes, you can "replace all the vendor keys". It really is trivial. However, before you do it you may want to use the existing keys and certificates to bootstrap (enroll) the host into your organization's network and then change the seeds and certify various public keys as derived after the seeds are changed so that you can continue using the TPM for attestation.
- the8472 4y ago
  You cut off the "including the firmware signing keys" part, that's critical. Otherwise the vendor could be coerced or subverted to sign malicious firmware which then subverts your system at runtime. Only when you can bring your own keys for the entire boot and trust chain can you untether yourself from the vendor once you have purchased the hardware.

cryptonector 4y ago

TPM 2.0 is a fantastic spec. There's little that's wrong with it. Even the bus sniffing vulnerabilities w/ dTPMs aren't TPM's fault but the BMC's and BIOS', as there is absolutely a way to encrypt and authenticate secrets to/from the TPM. Reinventing this wheel will probably lose a lot of good things. People who reinvent wheels often fail to understand what came before.

flangola7 4y ago
Encrypting bus traffic? What kind of mission impossible spy is this supposed to protect from?
- astrange 4y ago
  That's how console jailbreak mods have worked in the past. The important keyword is authenticated though. If it's not authenticated you can corrupt it.
  - flangola7 4y ago
    They're doing all this to prevent... console jailbreaks? I would have expected some kind of national security use case.
    - astrange 4y ago
      National security information is usually in a better protected environment than a game console or your laptop.
- cryptonector 4y ago
  The passive attacks on dTPMs in question require physical access, and opening the computer (and can be defeated with software). That is a pretty unlikely event for most users' computers. Active attacks (which can also be defeated with software) are more interesting because those are more likely, since the user doesn't have to cooperate with the attacker in those attacks.

akira2501 4y ago

Is a non removable TPM actually the right level of security? It feels like the same level of security I would get by having one of those realtor lock boxes permanently affixed to my front door and always keeping my house key in it. Maybe the key itself is "more secure" because it only lives in the lockbox and is only taken out to unlock the front door and then put back right away. Is this the right system for actually securing access to my home, though?