4

I'm learning about and researching the Trusted Platform Module (TPM) to incorporate into a solution involving remote machines.

As I understand it: all attestation methods (AIK, DAA) still require someone to know your identity (well, the chip's identity) and issue a certificate based on this identity. The anonymity only works because the CA is trusted not to reveal your identity in the process. Your identity is only safe from the verifier.

In this case, who is the CA? The manufacturer? And if so, is it the motherboard or chipset manufacturer (e.g. ASUS (mb) or Intel (chipset) or Winbond (IC)?).

Also, how would one contact these CA's? Do they have public facing interfaces? What do I send them?

In short, how do I start using remote attestation right now, with respect to CA authority? How do I contact them and who are they exactly?

Wilbur Whateley
  • 588
  • 6
  • 12

2 Answers2

3

I think you are certainly right, the verifier knows your TPM is trusted. In the DAA case the verifier cannot map TPM to user though.

In AIK certificate enrollment, the Certificate Authority may well be the same entity that verifies the AIK certificate.

Whereas in DAA, there is no Certificate Authority involved. There is an issuer which works with a TPM platform to create credentials. Your TPM platform later creates a AIK and signs this AIK with a DAA signature based on those credentials. This signature and the public key is made available to a verifier. The verifier cannot determine the owner of the TPM based on the information it receives but knows it's trusted. The issuer can be the same as the verifier. An application is some some subscription service where you want some privacy.

You can create your own CA certificate using openssl. web search is your friend.

the Trousers test suite tools can be used along with IBM's software TPM without a TPM hardware chip to try out attestation. I've used a real Infineon TPM using a beagleboard as the TPM and a Kontron with a custom X86_64 Yocto-built linux as my CA. I've also done DAA (I made a lot of fixes to my own copy of TrouSerS 0.3.10 code to get DAA to work) both with the hardware TPM and IBM software TPM. As for AIK certificates, testsuite has Tsp_TPM_CreateIdentity.c which creates an AIK and activates the AIK. Right after creating a AIK that is when you follow the guide in the link below to send out the identity proof to the CA. The identity proof contains the AIK that is created from Tspi_TPM_CollateIdentityRequest. Once the CA sends back the AIK certificate then you call Tsp_TPM_ActivateIdentity and keep the AIK certificate. The late Hal Finney ran a privacy CA but his web link has been inactive for a year and a half.

AIK certificate enrollment https://www.trustedcomputinggroup.org/files/resource_files/738DF0BB-1A4B-B294-D0AF6AF9CC023163/IWG_CMC_Profile_Cert_Enrollment_v1_r7.pdf

Bill Martin
  • 31
  • 2
  • I empathize with your need to hack TrouSerS to get it to do what you want. – Wilbur Whateley Jan 20 '16 at 23:57
  • How is what you refer to as an "issuer" in DAA different from a CA? It's still someone who certifies that an EK belongs to a known TPM ( a real TPM). That's the same thing, right? So, as you say, no CA is involved, per se, but someone still has knowledge about the EK and certifies it. The 3rd party verifier/application still has to trust the issuer, and you have to trust the issuer not to reveal your identity. – Wilbur Whateley Jan 21 '16 at 00:13
  • @WilburWhateley, the CA must only certify a public key as belonging to a TPM if that is true, and the issuer must only grant DAA credentials to a party that demonstrates ownership of the private key corresponding to such a certificate. Both the CA and issuer must perform certain checks, but the precise checks that they perform are different. – user2768 Apr 18 '17 at 13:59
  • @WilburWhateley, the 3rd party verifier/application needs to trust the CA and issuer to perform these checks. (If the CA isn't diligent, then keys are certified as belonging to TPMs, when they do not. Hence, a non-TPM will be granted DAA credentials by an issuer. If the issuer isn't diligent, then DAA credentials will be granted to non-TPMs.) But, these checks aren't necessary for anonymity. I've tried to elaborate upon this in https://security.stackexchange.com/a/157583/91887. – user2768 Apr 18 '17 at 14:07
1

A TPM is equipped with a key pair during manufacture. The private key is stored inside the TPM and it is physically protected by tamper-resistant technologies. The public key is certified. Given such a public key, the owner can be authenticated by demonstrating that they are able to decrypt a message encrypted with their public key. Such authentication is valuable to identify TPMs, but it also has privacy implications. DAA is intended to (partially) overcome such implications.

In DAA, a group of TPMs authenticate to an issuer in the manner described above and the issuer grants credentials to those TPMs. Given such a credential, TPMs can authenticate as a member of the group of TPMs. Thus, a TPM reveals its identity to the issuer to get a credential, but that identity is hidden when using the credential to authenticate. Hence, TPMs are anonymous within the group of TPMs.

The issuer must be trusted to only grant credentials to TPMs, to ensure that a non-TPM cannot authenticate as a member of the group of TPMs, but the issuer is not trusted for anonymity (nor is the verifier nor is ...).

user2768
  • 117
  • 3