Yes, if you want to recover keys from a dTPM you have two options:
- decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip
- force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it
A few nation states could probably pull off the latter, but probably very few. And I suspect they haven't bothered and won't until TPM usage finally gets in the way. This is pure speculation, and they may well have forced all the manufacturers already for all any one of us knows.
More nation states could pull of the former. But again, they might not bother until TPM usage finally gets in the way.
As long as BMCs and BIOSes continue to use non-encrypted sessions to talk to dTPMs there is no need to do any of this when the attacker has physical access to the motherboard.
They have some weaknesses. A dTPM uses an unencrypted protocol to communicate with the CPU (simple i2c or SPI) and it's pretty easy to sniff it if you manage to get legit access. But you do need a legit user to log in to the machine once. This is a bit of an achilles heel.
In this sense an integrated solution is better because there is no simple bus to sniff, but it does have to be properly implemented of course. Which seems to be not the case here.
By the way a dTPM should have a real entropy RNG so technically it shouldn't have any (usable) seed. It's basically a smartcard soldered onto the mainboard. Of course smartcards can also have key generation flaws like the Infineon flaw a while back. https://www.schneier.com/blog/archives/2017/10/security_flaw...
> A dTPM uses an unencrypted protocol to communicate with the CPU
While that is strictly speaking true, the TPM command set allows you to set up an encrypted session to the TPM using an ECDH or RSA key for key exchange that authenticates the TPM.
The problem is that the BMCs and BIOSes out there don't record a public key for a primary key on the TPM and then don't bother using encrypted sessions (not even opportunistically getting that public key from the TPM, which would defeat passive attacks).
Thanks, I didn't know that, I thought indeed that it was simply not possible with TPM 2.0.
I do think it's time for a TPM 3.0 though. What apple does with their T2 security chip, and later with the M1/M2, is having the secure element not only handle the key material but the actual encryption as well. They have hardware acceleration that can handle encryption at full disk speeds. This is still a much better option than a TPM especially with symmetric encryption where the key would inevitably end up in the main CPU. In Apple's scenario this no longer happens.
- encrypt all command and response parameters instead of up to just one
- add a version of TPM2_Quote() that encrypts and signs so one can have ciphertext that one can demonstrate were made by a TPM encrypting to a restricted, shielded key
- add a small secure enclave facility
- add more EC algorithms, EdDSA, etc.
- add more cipher modes for AES
- increase RAM and NVRAM requirements
All of this can be done incrementally in 2.x, so calling it 3.0 would be just marketing (perhaps pretty good marketing).
> By the way a dTPM should have a real entropy RNG so technically it shouldn't have any (usable) seed. It's basically a smartcard soldered onto the mainboard. Of course smartcards can also have key generation flaws like the Infineon flaw a while back. https://www.schneier.com/blog/archives/2017/10/security_flaw...
The seeds are an essential part of the TPM story as for generation (derivation) of primary keys, and being able to "take ownership" of a TPM by changing those seeds.
The seeds are not an essential part of the TPM story for its RNG. A TPM absolutely can and should have a solid HW RNG. Though, were I designing a TPM, I'd combine the output of a HW RNG w/ a PRNG seeded internally.
But the seed itself should still be fully random though? And generated on-device during initialisation. Derived keys are a thing of course, and I understand the benefit thereof.
But a manufacturer-installed seed that they have control over sounds like a very bad idea.
- decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip
- force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it
A few nation states could probably pull off the latter, but probably very few. And I suspect they haven't bothered and won't until TPM usage finally gets in the way. This is pure speculation, and they may well have forced all the manufacturers already for all any one of us knows.
More nation states could pull of the former. But again, they might not bother until TPM usage finally gets in the way.
As long as BMCs and BIOSes continue to use non-encrypted sessions to talk to dTPMs there is no need to do any of this when the attacker has physical access to the motherboard.