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?
Whose computer is this, anyway?
_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 ?
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)
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.
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.
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.
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.
I.e., I'm objecting to this focus on TPM in TFA and this discussion because a voltage fault injection vulnerability in the SP is fatal to security regardless of TPM usage/non-usage. I'm also objecting to the idea that TPM adds vulnerabilities when a non-TPM-using system already is full of ways for NSA and/or other such agencies to backdoor it.
It's not just about updates through regular channels but about evil maid attacks with signed malicious firmware. This vector would be avoidable if you could sever the trust relationship.
Another wrinkle is that some of the blobs are encrypted (e.g. ME), so they can't even be audited.
Currently too much of the trust chain relies on untrustworthy components. So you can't trust the system. But the DRM vendor can well enough for their purposes. Which makes them a negative.
> I.e., I'm objecting to this focus on TPM in TFA and this discussion because a voltage fault injection vulnerability in the SP is fatal to security regardless of TPM usage/non-usage.
Yes, agreed.
Yes, evil maid attacks are the primary way for targeted attacks using malicious firmware.
So this is something that maybe the TCG should tackle. It should be possible (maybe it is?) to require that the host meet some policy before the firmware update can run -- this would prevent unauthenticated evil maid attacks.
This will always be true unless you build all the components yourself. And you don't have time to build all the components yourself. Therefore this will always be true.
With root of trust measurement you get to see that you're running code you've arbitrarily decided to trust. Everything else you could do would be mitigations (e.g., look for access patterns that imply compromise) or attempts to suss out vulnerable and/or backdoored components (e.g., reverse engineering and analysis). Not that one should not do those other things, but that root of trust measurement is still both, essential and insufficient.
Remember: perfection is the enemy because it's unattainable. We can tilt at windmills, but that won't get us anywhere.
Reinventing this wheel will probably lose a lot of good things. People who reinvent wheels often fail to understand what came before.
The important keyword is authenticated though. If it's not authenticated you can corrupt 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?
https://www.stat.rice.edu/~dobelman/kstorm.txt
https://news.ycombinator.com/item?id=6337282
https://www.militaryaerospace.com/computers/article/16711478...
https://www.businessinsider.com/leaked-german-government-war...
https://supplychaindigital.com/technology/nsa-trusted-comput...
https://redmondmag.com/articles/2013/08/22/windows-8-securit...
https://blogs.ncl.ac.uk/security/2015/07/29/on-the-trust-of-...
> 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.
There are many things to worry about when it comes to firmware backdoors, the TPM ain't one of them.
Excuse me, but wtf. That's BS. Cryptographic material is nothing but data. A Huffman encode will work on a number that happens to be a public key just as happily as it will a anything else.
Cryptographic material doesn't have a magic "immune to compression" characteristic.
Encrypted material should not be compressable because it needs to appear random no matter what the unencrypted contents are, otherwise you have information about those contents. (You can trade off between the security and compressability, but shouldn't.)
In principle, given an n-bit prime p, you can store an expected log₂ n − 0.5 additional bits by using the gap between p and the next prime. Though in practice, I'd be surprised if the 19 or so extra bits could be dangerous.
Thinking about AES-256 will be easier. Say we have 2^40 computers able to randomly generate 2^64 AES-256 keys every day. Well, it will still take a long time to generate all possible AES-256 keys. So say in the best case scenario we get close to 2^120 keys or so. How would we even measure their frequencies so we could assign Huffman codes to them? Well, we can't, and even if we could most keys would have a frequency between 1 and 3. And still the next key to be generated could be outside that set so we really have to assign a code to each key, and there's... 2^256 possible keys... which means that even if we could assign a code to each key we couldn't write that down because there's not enough atoms on Earth to do it with. But let's say we just define a collation of AES-256 keys and assign then Huffman codes in order... But now we'll soon see that most keys will get codes assigned that are longer than 256 bits. Which means that the average input to this compressor would... yield an expansion, not a compression.
And, yes, you can compress specific pseudo-random looking symbols, but only a few. We're talking about arbitrary pseudo-random data, and that will not compress.
Surely the device should serve the interests of the user that pays for it, and not some random developer.
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.