Re: [tpm2] Remote Attestation

Re: [tpm2] Remote Attestation

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]



> -----Original Message-----
> From: Matthew Dempsky [mailto:matthew(a)dempsky.org]
> Sent: Thursday, August 29, 2019 1:12 PM
> To: Roberts, William C <william.c.roberts(a)intel.com>
> Cc: Roberto Carvalho <roberto.nogueira.rc(a)gmail.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] Remote Attestation
> 
> On Thu, Aug 29, 2019 at 9:36 AM Roberts, William C <william.c.roberts(a)intel.com
> <mailto:william.c.roberts(a)intel.com> > wrote:
> 
> 
> 	FYI bear in mind these are in host endianness, so if you switch
> architecture endianness
> 	You need to convert these. It would be wise to serialize these properly
> before sending
> 	off the host. Im just using libmu to serialize, which doesn't deal with
> endianness IRRC/IUUC.
> 
> 
> Thanks for pointing out that concern. I think tpm2-tools should work across hosts,
> but it seems like there might still be some issues with that currently.
> 
> tss2-mu serializes integers to network order; and it has to, because the TPM spec
> defines command/response protocol use network order (Part 1, Section 7.1).
> 
> 
> tpm2-tools also looks like it does appropriate endianness swapping in lib/files.c's
> files_{read,write}_{16,32,64} functions.
> 
> So that much seems good.

That does, but a lot of the calls are directly to libmu. For example TPM2B_PRIVATE.
I forgot that libmu does the right thing and converts them to big endian for
serialization, because it's expected that’s part of you command buffer and
Sent to the TPM. So you can just use libmu to unserialize on the other end.

> 
> 
> However, I see that at least tools/tpm2_quote.c's write_pcr_values function
> directly fwrites some data structures without marshaling.
> 
> There are also a handful of direct calls to fread, that might need review for
> endianness issues.

Yeah those all need to be checked and updated and the old formats need to
be preserved. We should be able to guess the endianness values by sanity
and then silently update them to a better format. We can drop the header
magic value and version on them too so we can handle changes easily moving
forward.

Re: [tpm2] Remote Attestation

[Roberto Carvalho]

[-- Attachment #1: Type: text/plain, Size: 4677 bytes --]

I did the test without extending the PCR, so it gave no error, my
apologies, the quote works as expected.

Em dom, 1 de set de 2019 22:13, Roberto Carvalho <
roberto.nogueira.rc(a)gmail.com> escreveu:

> I have already applied the questions of verifying Ek with CA and
> deciphering secret.encrypted back to secret.plain, my question now is about
> using quote.
>
> Let's say the client does the following:
>  tpm2_quote -Q -c ak.ctx -l sha256:15,16,17 -q
> 46b9658af2686c2961f12646a7d236720f1360a0 -m quote.out -s quotesig.out -o
> quotepcr.out -g sha256
> then send quote.out, quotesig.out and *quotepcr.out* to the server
> and purposely keep the quotepcr.out file on disk.
>
> At the next check when the server sends a different nonce the client can
> use the command:
> tpm2_quote -Q -c ak.ctx -l sha256:15,16,17 -q
> a43dee8d7d2e81970316844c3586adc536a6de64 -m quote2.out -s quotesig2.out -o
> quotepcr2.out -g sha256
>
> And sending the quote2.out, quotesig2.out, and *quotepcr.out (First file
> command)* files to the server, even if the PCR's have been extended or
> changed, the server will return SUCCESS on its tpm2_checkquote check as it
> will be validating using an old PCR setting. .
>
> How could I solve this?
>
> Em qua, 28 de ago de 2019 às 22:00, Matthew Dempsky <matthew(a)dempsky.org>
> escreveu:
>
>> Unfortunately, I don't think the complete end-to-end tooling is there yet
>> in tpm2-tools to make trivial to do remote attestation. There's still a bit
>> that's going to require manually handling of TPM2 data structures.
>>
>> In the simplistic case that you just want to verify that the client's key
>> securely resides in a real TPM2, what you'll need to do is:
>>
>> 1. On the client, generate the Endorsement Key (e.g., tpm2_createek -c
>> ek.ctx -u ek.pub) and get the corresponding EK certificate (typically
>> tpm2_nvread -o ek.crt 0x1c00002, for an RSA EK).
>> 2. Get the "public" data structure corresponding to your secret key
>> (e.g., use tpm2_readpublic -c my-key.ctx -o my-key.pub).
>> 3. Send ek.pub, ek.crt, and my-key.pub to the server.
>>
>> 4. On the server, validate ek.crt against your TPM CA root store, and
>> that ek.crt and ek.pub's public keys match.
>> 5. Validate that my-key.pub is acceptable (e.g., that fixedtpm and
>> sensitivedataorigin are set), and that it matches the CSR's public key.
>> 6. Convert the ak.pub into ak.name (this is SHA-256 of ak.pub, skipping
>> the first two bytes, and then prefixing hex "000b" to the result).
>> 7. Use "tpm2_makecredential -e ek.pub -n `cat ak.name` -s secret.plain
>> -o secret.encrypted" to encrypt some secret (up to 32 bytes).
>> 8. Send secret.encrypted to the client.
>>
>> 9. Back on the client, use the example steps in
>> tpm2-tools/man/tpm2_activatecredential
>> <https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_activatecredential.1.md#examples> (in
>> particular, the four commands involving "session.ctx") to decrypt
>> secret.encrypted back into secret.plain.
>>
>>
>> Protocol wise, from the server's point of view:
>>   (1) By verifying ek.crt, you know it corresponds to a real TPM; and
>>   (2) Because of how real TPMs work, you know if the client successfully
>> used tpm2_activatecredential to decrypt secret.encrypted, then that same
>> TPM has a secret key that matches my-key.pub.
>>
>> The best way I've thought of utilizing this is to generate a 32-byte
>> random nonce, encrypt using tpm2_makecredential, send it to the client to
>> decrypt as a challenge, and have them echo it back. If they're able to do
>> so successfully, you can now sign the CSR and issue them the X.509
>> certificate knowing my-key.pub is valid.
>>
>>
>> The other option is to just issue the X.509 certificate, but encrypt it
>> using a random 32-byte key, and seal the key using tpm2_makecredential. But
>> this means the server doesn't know whether the certificate is actually
>> going to be used. If you want to keep a log of all issued certificates,
>> this seems undesirable.
>>
>>
>> Finally, this is the simplest approach to attestation. If you want to be
>> able to do more complex attestation (e.g., checking timestamps, PCR or NV
>> index values, or proving that the key was freshly generated), you'll need
>> to instead use the above steps to validate an Attestation Key (that is, a
>> key with the "restricted" and "signing" attributes set in its "public" data
>> file). And then the client can use the AK to with TPM2_Certify, TPM2_Quote,
>> etc.
>>
>>
>> Hopefully that helps somewhat. If any particular steps are unclear, let
>> me know.
>>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5660 bytes --]

Re: [tpm2] Remote Attestation

[Roberto Carvalho]

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]

I have already applied the questions of verifying Ek with CA and
deciphering secret.encrypted back to secret.plain, my question now is about
using quote.

Let's say the client does the following:
 tpm2_quote -Q -c ak.ctx -l sha256:15,16,17 -q
46b9658af2686c2961f12646a7d236720f1360a0 -m quote.out -s quotesig.out -o
quotepcr.out -g sha256
then send quote.out, quotesig.out and *quotepcr.out* to the server
and purposely keep the quotepcr.out file on disk.

At the next check when the server sends a different nonce the client can
use the command:
tpm2_quote -Q -c ak.ctx -l sha256:15,16,17 -q
a43dee8d7d2e81970316844c3586adc536a6de64 -m quote2.out -s quotesig2.out -o
quotepcr2.out -g sha256

And sending the quote2.out, quotesig2.out, and *quotepcr.out (First file
command)* files to the server, even if the PCR's have been extended or
changed, the server will return SUCCESS on its tpm2_checkquote check as it
will be validating using an old PCR setting. .

How could I solve this?

Em qua, 28 de ago de 2019 às 22:00, Matthew Dempsky <matthew(a)dempsky.org>
escreveu:

> Unfortunately, I don't think the complete end-to-end tooling is there yet
> in tpm2-tools to make trivial to do remote attestation. There's still a bit
> that's going to require manually handling of TPM2 data structures.
>
> In the simplistic case that you just want to verify that the client's key
> securely resides in a real TPM2, what you'll need to do is:
>
> 1. On the client, generate the Endorsement Key (e.g., tpm2_createek -c
> ek.ctx -u ek.pub) and get the corresponding EK certificate (typically
> tpm2_nvread -o ek.crt 0x1c00002, for an RSA EK).
> 2. Get the "public" data structure corresponding to your secret key (e.g.,
> use tpm2_readpublic -c my-key.ctx -o my-key.pub).
> 3. Send ek.pub, ek.crt, and my-key.pub to the server.
>
> 4. On the server, validate ek.crt against your TPM CA root store, and that
> ek.crt and ek.pub's public keys match.
> 5. Validate that my-key.pub is acceptable (e.g., that fixedtpm and
> sensitivedataorigin are set), and that it matches the CSR's public key.
> 6. Convert the ak.pub into ak.name (this is SHA-256 of ak.pub, skipping
> the first two bytes, and then prefixing hex "000b" to the result).
> 7. Use "tpm2_makecredential -e ek.pub -n `cat ak.name` -s secret.plain -o
> secret.encrypted" to encrypt some secret (up to 32 bytes).
> 8. Send secret.encrypted to the client.
>
> 9. Back on the client, use the example steps in
> tpm2-tools/man/tpm2_activatecredential
> <https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_activatecredential.1.md#examples> (in
> particular, the four commands involving "session.ctx") to decrypt
> secret.encrypted back into secret.plain.
>
>
> Protocol wise, from the server's point of view:
>   (1) By verifying ek.crt, you know it corresponds to a real TPM; and
>   (2) Because of how real TPMs work, you know if the client successfully
> used tpm2_activatecredential to decrypt secret.encrypted, then that same
> TPM has a secret key that matches my-key.pub.
>
> The best way I've thought of utilizing this is to generate a 32-byte
> random nonce, encrypt using tpm2_makecredential, send it to the client to
> decrypt as a challenge, and have them echo it back. If they're able to do
> so successfully, you can now sign the CSR and issue them the X.509
> certificate knowing my-key.pub is valid.
>
>
> The other option is to just issue the X.509 certificate, but encrypt it
> using a random 32-byte key, and seal the key using tpm2_makecredential. But
> this means the server doesn't know whether the certificate is actually
> going to be used. If you want to keep a log of all issued certificates,
> this seems undesirable.
>
>
> Finally, this is the simplest approach to attestation. If you want to be
> able to do more complex attestation (e.g., checking timestamps, PCR or NV
> index values, or proving that the key was freshly generated), you'll need
> to instead use the above steps to validate an Attestation Key (that is, a
> key with the "restricted" and "signing" attributes set in its "public" data
> file). And then the client can use the AK to with TPM2_Certify, TPM2_Quote,
> etc.
>
>
> Hopefully that helps somewhat. If any particular steps are unclear, let me
> know.
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5107 bytes --]

Re: [tpm2] Remote Attestation

[Matthew Dempsky]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Thu, Aug 29, 2019 at 9:36 AM Roberts, William C <
william.c.roberts(a)intel.com> wrote:

> FYI bear in mind these are in host endianness, so if you switch
> architecture endianness
> You need to convert these. It would be wise to serialize these properly
> before sending
> off the host. Im just using libmu to serialize, which doesn't deal with
> endianness IRRC/IUUC.


Thanks for pointing out that concern. I think tpm2-tools *should* work
across hosts, but it seems like there might still be some issues with that
currently.

tss2-mu serializes integers to network order; and it has to, because the
TPM spec defines command/response protocol use network order (Part 1,
Section 7.1).

tpm2-tools also looks like it does appropriate endianness swapping in
lib/files.c's files_{read,write}_{16,32,64} functions.

So that much seems good.


However, I see that at least tools/tpm2_quote.c's write_pcr_values function
directly fwrites some data structures without marshaling.

There are also a handful of direct calls to fread, that might need review
for endianness issues.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1512 bytes --]

Re: [tpm2] Remote Attestation

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]



> -----Original Message-----
> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of Matthew Dempsky
> Sent: Wednesday, August 28, 2019 8:00 PM
> To: Roberto Carvalho <roberto.nogueira.rc(a)gmail.com>
> Cc: tpm2(a)lists.01.org
> Subject: Re: [tpm2] Remote Attestation
> 
> Unfortunately, I don't think the complete end-to-end tooling is there yet in
> tpm2-tools to make trivial to do remote attestation. There's still a bit that's going
> to require manually handling of TPM2 data structures.
> 
> In the simplistic case that you just want to verify that the client's key securely
> resides in a real TPM2, what you'll need to do is:
> 
> 1. On the client, generate the Endorsement Key (e.g., tpm2_createek -c ek.ctx -u
> ek.pub) and get the corresponding EK certificate (typically tpm2_nvread -o ek.crt
> 0x1c00002, for an RSA EK).
> 2. Get the "public" data structure corresponding to your secret key (e.g., use
> tpm2_readpublic -c my-key.ctx -o my-key.pub).
> 3. Send ek.pub, ek.crt, and my-key.pub to the server.

FYI bear in mind these are in host endianness, so if you switch architecture endianness
You need to convert these. It would be wise to serialize these properly before sending
off the host. Im just using libmu to serialize, which doesn't deal with endianness IRRC/IUUC.

> 
> 4. On the server, validate ek.crt against your TPM CA root store, and that ek.crt
> and ek.pub's public keys match.
> 5. Validate that my-key.pub is acceptable (e.g., that fixedtpm and
> sensitivedataorigin are set), and that it matches the CSR's public key.
> 6. Convert the ak.pub into ak.name <http://ak.name>  (this is SHA-256 of ak.pub,
> skipping the first two bytes, and then prefixing hex "000b" to the result).
> 7. Use "tpm2_makecredential -e ek.pub -n `cat ak.name <http://ak.name> ` -s
> secret.plain -o secret.encrypted" to encrypt some secret (up to 32 bytes).
> 
> 8. Send secret.encrypted to the client.
> 
> 9. Back on the client, use the example steps in tpm2-
> tools/man/tpm2_activatecredential <https://github.com/tpm2-software/tpm2-
> tools/blob/master/man/tpm2_activatecredential.1.md#examples>  (in particular,
> the four commands involving "session.ctx") to decrypt secret.encrypted back into
> secret.plain.
> 
> 
> 
> Protocol wise, from the server's point of view:
>   (1) By verifying ek.crt, you know it corresponds to a real TPM; and
>   (2) Because of how real TPMs work, you know if the client successfully used
> tpm2_activatecredential to decrypt secret.encrypted, then that same TPM has a
> secret key that matches my-key.pub.
> 
> The best way I've thought of utilizing this is to generate a 32-byte random nonce,
> encrypt using tpm2_makecredential, send it to the client to decrypt as a
> challenge, and have them echo it back. If they're able to do so successfully, you
> can now sign the CSR and issue them the X.509 certificate knowing my-key.pub is
> valid.
> 
> 
> The other option is to just issue the X.509 certificate, but encrypt it using a
> random 32-byte key, and seal the key using tpm2_makecredential. But this
> means the server doesn't know whether the certificate is actually going to be
> used. If you want to keep a log of all issued certificates, this seems undesirable.
> 
> 
> Finally, this is the simplest approach to attestation. If you want to be able to do
> more complex attestation (e.g., checking timestamps, PCR or NV index values, or
> proving that the key was freshly generated), you'll need to instead use the above
> steps to validate an Attestation Key (that is, a key with the "restricted" and
> "signing" attributes set in its "public" data file). And then the client can use the AK
> to with TPM2_Certify, TPM2_Quote, etc.
> 
> 
> Hopefully that helps somewhat. If any particular steps are unclear, let me know.

Re: [tpm2] Remote Attestation

[Matthew Dempsky]

[-- Attachment #1: Type: text/plain, Size: 3142 bytes --]

Unfortunately, I don't think the complete end-to-end tooling is there yet
in tpm2-tools to make trivial to do remote attestation. There's still a bit
that's going to require manually handling of TPM2 data structures.

In the simplistic case that you just want to verify that the client's key
securely resides in a real TPM2, what you'll need to do is:

1. On the client, generate the Endorsement Key (e.g., tpm2_createek -c
ek.ctx -u ek.pub) and get the corresponding EK certificate (typically
tpm2_nvread -o ek.crt 0x1c00002, for an RSA EK).
2. Get the "public" data structure corresponding to your secret key (e.g.,
use tpm2_readpublic -c my-key.ctx -o my-key.pub).
3. Send ek.pub, ek.crt, and my-key.pub to the server.

4. On the server, validate ek.crt against your TPM CA root store, and that
ek.crt and ek.pub's public keys match.
5. Validate that my-key.pub is acceptable (e.g., that fixedtpm and
sensitivedataorigin are set), and that it matches the CSR's public key.
6. Convert the ak.pub into ak.name (this is SHA-256 of ak.pub, skipping the
first two bytes, and then prefixing hex "000b" to the result).
7. Use "tpm2_makecredential -e ek.pub -n `cat ak.name` -s secret.plain -o
secret.encrypted" to encrypt some secret (up to 32 bytes).
8. Send secret.encrypted to the client.

9. Back on the client, use the example steps in
tpm2-tools/man/tpm2_activatecredential
<https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_activatecredential.1.md#examples>
(in
particular, the four commands involving "session.ctx") to decrypt
secret.encrypted back into secret.plain.


Protocol wise, from the server's point of view:
  (1) By verifying ek.crt, you know it corresponds to a real TPM; and
  (2) Because of how real TPMs work, you know if the client successfully
used tpm2_activatecredential to decrypt secret.encrypted, then that same
TPM has a secret key that matches my-key.pub.

The best way I've thought of utilizing this is to generate a 32-byte random
nonce, encrypt using tpm2_makecredential, send it to the client to decrypt
as a challenge, and have them echo it back. If they're able to do so
successfully, you can now sign the CSR and issue them the X.509 certificate
knowing my-key.pub is valid.


The other option is to just issue the X.509 certificate, but encrypt it
using a random 32-byte key, and seal the key using tpm2_makecredential. But
this means the server doesn't know whether the certificate is actually
going to be used. If you want to keep a log of all issued certificates,
this seems undesirable.


Finally, this is the simplest approach to attestation. If you want to be
able to do more complex attestation (e.g., checking timestamps, PCR or NV
index values, or proving that the key was freshly generated), you'll need
to instead use the above steps to validate an Attestation Key (that is, a
key with the "restricted" and "signing" attributes set in its "public" data
file). And then the client can use the AK to with TPM2_Certify, TPM2_Quote,
etc.


Hopefully that helps somewhat. If any particular steps are unclear, let me
know.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3651 bytes --]

[tpm2] Remote Attestation

[Roberto Carvalho]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Hello, I have a server that receives a .CSR from a machine with TPM, I
would like to know the best way to ensure the attestation of this machine,
which is a genuine machine with TPM, I read about using the CA authority of
Infenion which is the manufacturer, and then apply a cryptographic
challenge using a nonce using the ek and ak public keys, but I'm having
difficulty applying using tpm2_tools, any help?
Att.
Roberto

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 648 bytes --]