[TrouSerS-users] Communication Protocol between TPM and PrivacyCA;

[Pritha Ganguly]

Hello,

I am working on the ATMEL TPM(1.2) device on an embedded platform.

I wanted to test the attestation feature of TPM to certify an RSA key pair.
This is what I have understood :

I can use the Tspi_TPM_CollateIdentity_Request() API to tell the TPM to
create a AIK for me.
This API returns a certificate request structure(public AIK + Endorsement
credential of my TPM) encrypted with the public key of the Privacy CA. I
need to send this to the Privacy CA so that the Privacy CA can issue a
credential for my AIK.The reply from the Privacy CA will be encrypted by
the public EK of my TPM. The encrypted blob I have to pass it to
Tspi_TPM_ActivateIdentity() to get the credential.

I have a very basic doubt. Who will behave as the Privacy CA in this case?
Do I have to create my own CA?

Also, how do I send the output of Tspi_TPM_CollateIdentity_Request() to the
PrivacyCA, as in what protocol is to be followed for the communication
between the TPM and PrivacyCA?

I am newbie and any help would be highly appreciated.

Thanks and Regards,
Pritha Ganguly

[Ken Goldman]

I'm not an expert on the TSS side, but I'll try a few comments.

Post by Pritha Ganguly
I can use the Tspi_TPM_CollateIdentity_Request() API to tell the TPM
to create a AIK for me. This API returns a certificate request
structure(public AIK + Endorsement credential of my TPM) encrypted
with the public key of the Privacy CA.

The first part (AIK + EK certificate) sounds right. I never heard of
encrypting the request with the CA public key.

Post by Pritha Ganguly
I need to send this to the Privacy CA so that the Privacy CA can
issue a credential for my AIK.The reply from the Privacy CA will be
encrypted by the public EK of my TPM. The encrypted blob I have to
pass it to Tspi_TPM_ActivateIdentity() to get the credential.

This sounds correct.

In detail, activate identity likely returns a symmetric key that you use
to recover the certificate. The certificate is too large to be
encrypted directly with the EK.

Post by Pritha Ganguly
I have a very basic doubt. Who will behave as the Privacy CA in this
case? Do I have to create my own CA?

I have one for TPM 2.0, but not for 1.2. I don't know if there's an
open source CA.

Post by Pritha Ganguly
Also, how do I send the output of Tspi_TPM_CollateIdentity_Request()
to the PrivacyCA, as in what protocol is to be followed for the
communication between the TPM and PrivacyCA?

I don't know of any standard.

I converted the blob to json and sent it over a socket.

[Chris Hawkins]

I did quite a bit of work with the Privacy CA for 1.2. The process, as
described by Pritha, is how I understand it. As for commercially available
Privacy CA's, I don't really know of any that aren't vaporware. Hal
Finney's privacyca.com has been gone for a few years now,
unfortunately. There is at least one in an open source form.
OpenAttestation includes a prototype Privacy CA (
https://github.com/OpenAttestation/OpenAttestation/tree/next/trust-agent/PrivacyCA/src/main/java/gov/niarl/his/privacyca).
It would take some work to get it to work independently, but follows the
basic standards. The code hasn't been touched for a few years, and there
have been relevant updates to the TCG credential standards since then. The
biggest problem that you will face is that there is very little interest in
doing further development on software that is focused specifically on TPM
1.2.

Post by Ken Goldman
I'm not an expert on the TSS side, but I'll try a few comments.

Post by Pritha Ganguly
I can use the Tspi_TPM_CollateIdentity_Request() API to tell the TPM
to create a AIK for me. This API returns a certificate request
structure(public AIK + Endorsement credential of my TPM) encrypted
with the public key of the Privacy CA.

The first part (AIK + EK certificate) sounds right. I never heard of
encrypting the request with the CA public key.

Post by Pritha Ganguly
I need to send this to the Privacy CA so that the Privacy CA can
issue a credential for my AIK.The reply from the Privacy CA will be
encrypted by the public EK of my TPM. The encrypted blob I have to
pass it to Tspi_TPM_ActivateIdentity() to get the credential.

This sounds correct.
In detail, activate identity likely returns a symmetric key that you use
to recover the certificate. The certificate is too large to be
encrypted directly with the EK.

Post by Pritha Ganguly
I have a very basic doubt. Who will behave as the Privacy CA in this
case? Do I have to create my own CA?

I have one for TPM 2.0, but not for 1.2. I don't know if there's an
open source CA.

Post by Pritha Ganguly
Also, how do I send the output of Tspi_TPM_CollateIdentity_Request()
to the PrivacyCA, as in what protocol is to be followed for the
communication between the TPM and PrivacyCA?

I don't know of any standard.
I converted the blob to json and sent it over a socket.
------------------------------------------------------------
------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Ken Goldman]

Post by Chris Hawkins
I did quite a bit of work with the Privacy CA for 1.2. The process, as
described by Pritha, is how I understand it.

The one part I question is the client sending the blob with the AIK
public key and EK certificate to the CA "encrypted with the public key
of the Privacy CA".

1 - This means that the CA would have to use its signing private key in
a decryption operation. Such a dual purpose CA key would be unusual.

2 - It's unlikely that the CA (RSA) public key would be large enough to
encrypt that blob.

[Chris Hawkins]

1. The encryption of the identity request is not necessarily done using the
signing key. I see this as an alternate to HTTPS, where the blob is
encrypted using communication key. It would be unusual to have the CA's web
security using the same key that is used to sign certs.

2. All of this encryption is done by encrypting using a symmetric session
key, which is wrapped in a structure and then encrypted using the RSA key.
It's a symmetric process -- the resulting AIC is wrapped in the same way
with the EK, and unpacked on the client side using the ActivateIdentity
command. Most of the process is handled by software (TrouSerS). The TPM
uses the EK to unwrap the structure containing the AES key that is used by
software to decrypt the larger blob containing the cert.

Post by Ken Goldman

Post by Chris Hawkins
I did quite a bit of work with the Privacy CA for 1.2. The process, as
described by Pritha, is how I understand it.

The one part I question is the client sending the blob with the AIK
public key and EK certificate to the CA "encrypted with the public key
of the Privacy CA".
1 - This means that the CA would have to use its signing private key in
a decryption operation. Such a dual purpose CA key would be unusual.
2 - It's unlikely that the CA (RSA) public key would be large enough to
encrypt that blob.
------------------------------------------------------------
------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Tadd Seiff]

I'm quite sure that in this step there is a session key wrapped with the main PCA RSA key-pair, the public portion of which you send to the TPM in TPM_CollateIdentityRequest(...).

This symmetric/session key is unwrapped and used to decrypt the larger blob containing the AIK identity proof payload.

Ah, here we are, see

https://trustedcomputinggroup.org/tpm-main-specification/
TPM Main-Part 2 TPM Structures_v1.2_rev116_01032011

Sections 12.5, 12.6, 12.7, 12.8, and try and put the pieces together. Compare it to what you get as an output from TPM_CollateIdentityRequest(...). There are a lot of nested structs in this situation.

-Tadd
[phone]


-----Original Message-----
From: Ken Goldman [mailto:***@us.ibm.com]
Sent: Friday, March 10, 2017 11:28 AM
To: trousers-***@lists.sourceforge.net
Subject: Re: [TrouSerS-users] Communication Protocol between TPM and PrivacyCA;

Post by Chris Hawkins
I did quite a bit of work with the Privacy CA for 1.2. The process, as
described by Pritha, is how I understand it.

The one part I question is the client sending the blob with the AIK
public key and EK certificate to the CA "encrypted with the public key
of the Privacy CA".

1 - This means that the CA would have to use its signing private key in
a decryption operation. Such a dual purpose CA key would be unusual.

2 - It's unlikely that the CA (RSA) public key would be large enough to
encrypt that blob.



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
TrouSerS-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/trousers-users
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer:

This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

[Pritha Ganguly]

Thank you everyone. This helps a lot.

Regards,
Pritha.

Post by Tadd Seiff
I'm quite sure that in this step there is a session key wrapped with the
main PCA RSA key-pair, the public portion of which you send to the TPM in
TPM_CollateIdentityRequest(...).
This symmetric/session key is unwrapped and used to decrypt the larger
blob containing the AIK identity proof payload.
Ah, here we are, see
https://trustedcomputinggroup.org/tpm-main-specification/
TPM Main-Part 2 TPM Structures_v1.2_rev116_01032011
Sections 12.5, 12.6, 12.7, 12.8, and try and put the pieces together.
Compare it to what you get as an output from TPM_CollateIdentityRequest(...).
There are a lot of nested structs in this situation.
-Tadd
[phone]
-----Original Message-----
Sent: Friday, March 10, 2017 11:28 AM
Subject: Re: [TrouSerS-users] Communication Protocol between TPM and PrivacyCA;

Post by Chris Hawkins
I did quite a bit of work with the Privacy CA for 1.2. The process, as
described by Pritha, is how I understand it.

The one part I question is the client sending the blob with the AIK
public key and EK certificate to the CA "encrypted with the public key
of the Privacy CA".
1 - This means that the CA would have to use its signing private key in
a decryption operation. Such a dual purpose CA key would be unusual.
2 - It's unlikely that the CA (RSA) public key would be large enough to
encrypt that blob.
------------------------------------------------------------
------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality
This e-mail and any files transmitted with it may contain confidential or
legally privileged information of WDC and/or its affiliates, and are
intended solely for the use of the individual or entity to which they are
addressed. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited. If you have received this e-mail in error, please notify the
sender immediately and delete the e-mail in its entirety from your system.
------------------------------------------------------------
------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users

[Ken Goldman]

Post by Tadd Seiff
Compare it to what you get as an output from
TPM_CollateIdentityRequest(...). There are a lot of nested structs in
this situation.

A hint on this, and the TPM 2.0 are even more deeply nested.

A nice way to understand structures is to run a software TPM in a
debugger like Visual Studio. They can display the structures on an
expandable tree and show the member types as well as the values. It's a
lot easier than traversing Part 2.

Even if you're running your application on Linux, trousers supports a
socket interface, so the SW TPM does not have to run on the same platform.

[Ken Goldman]

Post by Tadd Seiff
I'm quite sure that in this step there is a session key wrapped with
the main PCA RSA key-pair, the public portion of which you send to
the TPM in TPM_CollateIdentityRequest(...).
This symmetric/session key is unwrapped and used to decrypt the
larger blob containing the AIK identity proof payload.

I understand the layered wrapping, but I still doubt that the
privacy CA's signing key will be able to decrypt. Such dual purpose is
discouraged.

I also suspect that you would not want the CA signing key to be so
exposed to the internet as part of the communication protocol. I
imagine it being on a separate server with layers of firewalls shielding it.

That is, cryptographically and physically separate the communication
protocol from the certificate signing.