41–49 of 49 posts
Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.
I wonder, at what point will it be cheaper to kidnap and ransom those remote attestation engineers' families for key material than to work around those schemes with technical measures. Keeping in mind that people set up bot farms with physical phones just for attestation keys, it seems like tightening it all too much will just shift the balance towards the $5 wrench approach...
Joke's on them, I don't have the key either.
Earlier quoted context omitted.
A dedicated HSM will give you stronger trust that the private key material can't be extracted, but there's no real way to bind an HSM to a specific client and that's a very easy thing to do in the vTPM case.
How often do we need to bind a specific machine to a specific key in the case of TLS? In every case of TLS I've seen we are concerned with organizational identity, not machine identity. This effectively extends to client certificates in cases like B2B & vendor integration. In both scenarios you would definitely want to use an HSM style solution. Protecting the HSM from inappropriate use (proving you are allowed to si…
At work we deploy industrial IoT gateways, these are very much not end-user devices. We are actually concerned about the device's identity, and more specifically about being able to attest that the device is in fact the one we thought it was and it hasn't been tampered with. By putting the key for TLS client certificate in the device's TPM, locked behind attestation that what's been booted is what we expected to boot, we can have a reasonable degree of confidence that we're communicating with the device we thought we were rather than just someone who managed to copy the private key off disk.
I might be missing something: is this any conceptually different from using PKCS11 provider for TPM in OpenSSL? Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.
PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover.
> with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs.
A vTPM is as real as a physical TPM chip.
The question is which TPM endorsement certificate CAs you are willing to trust.
For some that might the manufacturer of TPM chips, for others it might be their VM provider. (For some, none: for some both!)
Trusting their VM provider isn't so crazy if the VM provider is able to influence the guest code anyway.
Earlier quoted context omitted.
Joke's on them, I don't have the key either.
Well I guess AMD/Intel/Qualcomm/Infineon/Google people are at the greatest risk, with places like TSMC also in play. Infineon TPMs and smartcards in particular had so many flaws that I wonder if it already happened. Also, note that even if you don't have the keys you may still control the implementation, and potentially introduce flaws. Keep safe.
> even if you don't have the keys you may still control the implementation
The sorts of places that care about remote attestation also care about insider risk.
I might be missing something: is this any conceptually different from using PKCS11 provider for TPM in OpenSSL? Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.
> is this any conceptually different from using PKCS11 provider for TPM in OpenSSL? PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover. > with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. A vTPM is as real as a physical TPM chip. The question is which TPM endorse…
You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.
Earlier quoted context omitted.
> is this any conceptually different from using PKCS11 provider for TPM in OpenSSL? PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover. > with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. A vTPM is as real as a physical TPM chip. The question is which TPM endorse…
> PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover. You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.
That said, TPM quotes are attesting the value of TPM PCRs which are just registers of hashes (representing the state of the machine).
When making a CSR, you can use https://tpm2-tools.readthedocs.io/en/latest/man/tpm2_certify... to attest a key is TPM-resident.
I think your central thesis is that at the time of TLS establishment, why not use PKCS11 (with a cert signed by a CA that has validated a TPM certification), and I agree: services should probably integrate via PKCS11.
Earlier quoted context omitted.
> PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover. You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.
I thought you was suggesting a TPM wasn't needed at all, but a TPM is needed to get quotes. That said, TPM quotes are attesting the value of TPM PCRs which are just registers of hashes (representing the state of the machine). When making a CSR, you can use https://tpm2-tools.readthedocs.io/en/latest/man/tpm2_certify... to attest a key is TPM-resident. I think your central thesis is that at the time of TLS establishme…
Sorry to have missed that!
Earlier quoted context omitted.
Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner. Of course the website itself would need to support that, but it's all possible in time.
Chrome would be more likely to implement a persistent and identifiable (to Google alone) tracking cookie replacement and ship it worldwide, which iirc they did — and then cancelled, of course. They seem to be focusing instead on improved tracking of Android users from the kernel up, rather than browsers from the headers down; GrapheneOS is, presumably, viewed as a serious threat to their advertising revenue. https://…