[tpm2] Re: Device Identity Attestation with tpm2-tools

[tpm2] Re: Device Identity Attestation with tpm2-tools

[Roberts, William C]

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



> -----Original Message-----
> From: nicolasoliver03(a)gmail.com [mailto:nicolasoliver03(a)gmail.com]
> Sent: Wednesday, January 15, 2020 10:14 AM
> To: tpm2(a)lists.01.org
> Subject: [tpm2] Re: Device Identity Attestation with tpm2-tools
> 
> Thanks for that info,
> 
> For reference to others, TPM2_ChangeEPS and TPM2_ChangePPS can be found
> in https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-
> Part-3-Commands-01.38.pdf, page 280.
> 
> I noticed that the https://github.com/tpm2-software/tpm2-
> tools/blob/master/man/tpm2_changeeps.1.md man page is a copy of
> https://github.com/tpm2-software/tpm2-
> tools/blob/master/man/tpm2_changepps.1.md. I created an issue for that
> https://github.com/tpm2-software/tpm2-tools/issues/1887

Darn that's my fault, thanks for pointing that out!

> 
> An example for that 1% of the times is present here
> https://github.com/intel/INTEL-SA-00086-Linux-Recovery-Tools, where you have
> to regenerate the Endorsement Platform Seed after patching the Intel ME/TXE

Ahh yes I forgot about that one... Thanks!

> 
> Good to know that the endorsement key are not 100% immutable
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: Device Identity Attestation with tpm2-tools

[Tadeusz Struk]

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

On 1/15/20 6:08 AM, Roberts, William C wrote:
> <snip>
>> working even after the device disk and tpm is cleared.
>> The tpm will always derive the same EK if one provides the same parameters.
> This is true 99+% of the time. However, the spec allows TPMs to to implement the CHANGEEPS
> Command that will cause the endorsement hierarchy seed to change. When this occurs, calls
> to createprimary  with the same templates to produce different keys. While this is rare, I've never
> seen one in the wild, you may wish to check the command interface for changeeps so you know
> what's possible with that TPM. Similar commands exist for other hierarchies as well.

Also keep in mind that tpm2_clear command changes the SPS so any keys in
the storage hierarchy will be invalid.

-- 
Tadeusz

[tpm2] Re: Device Identity Attestation with tpm2-tools

[nicolasoliver03]

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

Thanks for that info,

For reference to others, TPM2_ChangeEPS and TPM2_ChangePPS can be found in https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Commands-01.38.pdf, page 280.

I noticed that the https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_changeeps.1.md man page is a copy of https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_changepps.1.md. I created an issue for that https://github.com/tpm2-software/tpm2-tools/issues/1887

An example for that 1% of the times is present here https://github.com/intel/INTEL-SA-00086-Linux-Recovery-Tools, where you have to regenerate the Endorsement Platform Seed after patching the Intel ME/TXE

Good to know that the endorsement key are not 100% immutable

[tpm2] Re: Device Identity Attestation with tpm2-tools

[Roberts, William C]

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

<snip>
> working even after the device disk and tpm is cleared.
> The tpm will always derive the same EK if one provides the same parameters.

This is true 99+% of the time. However, the spec allows TPMs to to implement the CHANGEEPS
Command that will cause the endorsement hierarchy seed to change. When this occurs, calls
to createprimary  with the same templates to produce different keys. While this is rare, I've never
seen one in the wild, you may wish to check the command interface for changeeps so you know
what's possible with that TPM. Similar commands exist for other hierarchies as well.

> 
<snip>

[tpm2] Re: Device Identity Attestation with tpm2-tools

[Oliver, Dario N]

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

Thank you Charles for your input,

From our internal analysis, we also agreed that the EK + AK approach provides more benefits than the others (EK only, EK + SRK). 
The EK + AK approach enables the server to also validate the integrity of the host  based on the provided quote. And this is only possible to do with an AK.
The other approaches are also valid in other scenario, specially the EK only one, given that it does not require any persistence in the device, and it can keep working even after the device disk and tpm is cleared.
The tpm will always derive the same EK if one provides the same parameters. 

The problem that I had to persist the AK in that approach was a bad man page, and it was solved here https://lists.01.org/hyperkitty/list/tpm2(a)lists.01.org/thread/DLWL7HYW4QHQEHQLRP275EOOBNL5JYAF/ 
For the other problems, I created specific issues in github

Endorsement Key created with tpm2_createek cannot be used with tpm2_activatecredential: https://github.com/tpm2-software/tpm2-tools/issues/1883
Cannot create child key of an EK created with tpm2_createek: https://github.com/tpm2-software/tpm2-tools/issues/1884

The following script is an updated EK + AK example, without the previous problems to persist the AK, and also with nonce validation in the server using tpm2_cehckquote

echo "Enrolling with Atestation Key"

# Clear the TPM
tpm2_clear

# Create Endorsment Key
tpm2_createek -c ek.ctx -G rsa -u ek.pub

# Create Attestation Key
tpm2_createak -C ek.ctx -c ak.ctx -G rsa -g sha256 -s rsassa
tpm2_evictcontrol -C o -c ak.ctx 0x81010002
tpm2_readpublic -c ak.ctx -f pem -o ak.pem > ak.yaml
cat ak.yaml | grep '^name:' | awk '{ print $2 }' > ak.name

# Generate the nonce and credential for challenge
openssl rand -hex 6 > nonce.plain
tpm2_makecredential -e ek.pub -s nonce.plain -n $(cat ak.name) -o nonce.encrypted

# Decrypt nonce with Endorsement Key
tpm2_startauthsession --policy-session -S session.ctx
TPM2_RH_ENDORSEMENT=0x4000000B
tpm2_policysecret -S session.ctx -c ${TPM2_RH_ENDORSEMENT}
tpm2_activatecredential -c 0x81010002 -C ek.ctx -i nonce.encrypted -o nonce.decrypted -P "session:session.ctx"
tpm2_flushcontext session.ctx

# Generate Attestation Quote
tpm2_quote -c 0x81010002 -l sha256:0,1,2,3,4,5,6,7,8,9 -q $(cat nonce.decrypted) -m quote.message -s quote.signature -o quote.pcrs -g sha256

# Validate Attestation Quote in the server
tpm2_checkquote -u ak.pem -m quote.message -s quote.signature -f quote.pcrs -g sha256 -q $(cat nonce.plain)

Even if the server does not implements a PCR values validation, the tpm2_checkquote command can be used to verify that the device was able to decrypt the nonce.
A very simple quote attestation system could use this initial quote to establish the "golden values" of the device, and detect unexpected modifications of the components that affects the PCRs in future quotes

Regards,

Nicolas Oliver

[tpm2] Re: Device Identity Attestation with tpm2-tools

[Munson, Charles - 0553 - MITLL]

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

Hi Dario, 

 

The combination of EK+AK is the method that we are using for the Keylime project as well (https://github.com/keylime/keylime), since we rely on attestation as well. 

 

You can get a good idea of the workflow we use in the tpm2-tools attestation integration test (which was designed to roughly follow the Keylime workflow): 

https://github.com/tpm2-software/tpm2-tools/blob/master/test/integration/tests/attestation.sh

 

Here the key name is output to a file during the tpm2_createak phase using “-n”: 

tpm2_createak -Q -C $handle_ek -c $context_ak -G $ak_alg -g $digestAlg -s $signAlg -u $output_ak_pub_pem -f pem -n $output_ak_pub_name

 

Then, the binary blob name needs to be converted to hex if you want it in the same format as given by tpm2_readpublic: 

file_size=`ls -l $output_ak_pub_name | awk {'print $5'}`

loaded_key_name=`cat $output_ak_pub_name | xxd -p -c $file_size`

 

Best,

Charlie 

 

---- 

Charles Munson, Ph.D.

Technical Staff

Secure, Resilient Systems and Technology (5-53)

MIT Lincoln Laboratory 

Email: charles.munson(a)ll.mit.edu

Office: 781-981-9331

 

 

From: "Oliver, Dario N" <dario.n.oliver(a)intel.com>
Date: Thursday, January 9, 2020 at 2:39 PM
To: "tpm2(a)lists.01.org" <tpm2(a)lists.01.org>
Subject: [tpm2] Device Identity Attestation with tpm2-tools

 

Hello!

 

I have been working to create a reference design for Device Identity Attestation, using the latest available tpm2 tools package.

I want to share the reference design with you for comments. Examples of how to implement those with tpm2 tools are also provided. 

 

The approach is a TLS-like handshake. To over-simplify, it consist on a challenge that a server present to the device. If the device is able to solve the challenge, then the server can trust that is talking the correct device.

A good explanation of TLS can be found in https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

 

The pseudo-protocol for device identity attestation is:
The device contact the server
The server reply to the device a nonce (random bytes) encrypted with the device public identity key
The device uses its private identity key to decrypt the random nonce. 
The device reply to the server the same nonce, encrypted with the server public key
The server decrypts the nonce with its private key, and verify that it was the same nonce that it previously generated
If the nonce matches, then the device is the owner of the private key, and it can be trusted.
The server sends to the now trusted device the configuration, package, or tokens to start operating. If the nonce does not match, the server close the connection
 

There are several important details on the previous flow that are left behind to simplify this, to mention:
The encryption of the communication channel (i.e. using https)
The length and complexity of the nonce
The encryption/decryption algorithm that should be used (rsa in the examples)
 

There are 3 potential solutions explored:
Using the device Endorsement Key (EK) to identify the device
Using a combination of Endorsement Key and Storage Root Key (SRK) 
Using a combination of Endorsement and Attestation Key (AK)
 

The versions of software used to implement this examples are:
Fedora Server 31
Tpm2-tools-4.0.1-1.fc31.x86_64
Tpm2-tss-2.3.1-1.fc31.x86_64
Openssl-1-1.1d-2.fc31.x86_64
In kernel tpm resource manager (tpmrm), kernel version is 5.4.7-200.fc31.x86_64
 

Device Identity with EK

==================

 

According to https://google.github.io/tpm-js/#pg_keys, “Generally speaking, the endorsement hierarchy is reserved for objects created and certified by the TPM manufacturer. The endorsement seed (eseed) is randomly generated at manufacturing time and never changes during the lifetime of the device. The primary endorsement key is certified by the TPM manufacturer, and because its seed never changes, it can be used to identify the device. Since there's only one TPM device per machine, the primary endorsement key can also be used as the machine's identity.“

 

The sample implementation of this approach is:

 

  export TPM2TOOLS_TCTI="device:/dev/tpmrm0"

 echo "Enrolling with Endorsement Key"

   # Clear the TPM

   tpm2_clear

   # Create Endorsement Key

   tpm2_createprimary -c ek.ctx -C e

   tpm2_readpublic -c ek.ctx -o ek.pub > ek.yaml

   cat ek.yaml | grep '^name:' | awk '{ print $2 }' > ek.name

 

   # Generate the nonce and credential for challenge in the server

  openssl rand -hex 6 > nonce.plain

   tpm2_makecredential -T none -e ek.pub -s nonce.plain -n $(cat ek.name) -o nonce.encrypted

 

  # Decrypt nonce with EK

  tpm2_activatecredential -c ek.ctx -C ek.ctx -i nonce.encrypted -o nonce.decrypted

   # Validate nonce

  diff nonce.decrypted nonce.plain

 

Details:
The server just needs to store the ek.pub and ek.name to generate the challenge
The challenge is generated with tpm2_makecredential
The challenge is solved with tpm2_activate credential
There is no need to persist the EK, given that the tpm always generate the same EK
 

Problems:
The EK is, by definition, a restricted decrypt key. So, its private part cannot be used to decrypt data external to the TPM. But tpm2_activatecredential can do that. Is this the correct usage of activatecredential?
If the EK is created with tpm2_createek, I receive an “authorization handle is not correct for command” error in tpm2_activatecredential. Any hints why this happens?
According to documentation, tpm2_activatecredential receives the context (-c) and parent context (-C). In this case, I am passing ek.ctx to both of them. Is this the correct approach?
 

This approach is useful to identify a device, regardless of the current owner of it. 

This approach is similar to the one implemented in VMware Pulse IoT Center, in the “Onboard a Gateway Using a TPM-Based Authentication” section in the user guide https://docs.vmware.com/en/VMware-Pulse-IoT-Center/2019.11/iotc-user-guide.pdf

 

Device Identity with EK + SRK

========================

 

If you want to identify a device and its current owner, the approach is a little different. The device identity in this case is a combination of the EK and SRK, being the SRK created by the current owner of the device.

 

The sample implementation of this approach is:

 

  echo "Enrolling with Storage Root Key"

  # Clear the TPM

  tpm2_clear

  # Create Endorsement Key

  tpm2_createprimary -c ek.ctx -C e

  tpm2_readpublic -c ek.ctx -o ek.pub > ek.yaml

  cat ek.yaml | grep '^name:' | awk '{ print $2 }' > ek.name

  # Create Storage Root Key

  tpm2_create -C ek.ctx -G rsa2048 -u srk.pub -r srk.priv -a 'restricted|decrypt|fixedtpm|fixedparent|sensitivedataorigin|userwithauth'

  tpm2_load -C ek.ctx -u srk.pub -r srk.priv -c srk.ctx

  tpm2_evictcontrol -C o -c srk.ctx 0x81010002

  tpm2_readpublic -c srk.ctx > srk.yaml

  cat srk.yaml | grep '^name:' | awk '{ print $2 }' > srk.name

 

  # Generate the nonce and credential for challenge

  openssl rand -hex 6 > nonce.plain

  tpm2_makecredential -T none -e ek.pub -s nonce.plain -n $(cat srk.name) -o nonce.encrypted

 

  # Decrypt nonce with SRK

  tpm2_activatecredential -c 0x81010002 -C ek.ctx -i nonce.encrypted -o nonce.decrypted

 

  # Validate nonce

  diff nonce.decrypted nonce.plain

 

Details:
Similar to first approach, but the owner creates and persists an SRK. The SRK must be also a restricted encryption key, and it cannot be used for general decryption, because it could then leak the child key secrets. 
The server needs to know the ek.pub and srk.name to generate the challenge
The device uses the EK and persisted SRK to resolve the challenge
After a tpm2_clear, the device will not be able to proof its identity anymore with that server, because the SRK is removed. This is a desired capability to transition the device ownership (or perform a data sanitization process in it before discarding it).
 

Problems:
If I use tpm2_createek, I run into an “authValue or authPolicy is not available for selected entity” error on tpm2_create. Any hints on why this happens?
Are the attributes and parameters in tpm2_create enough to call that generated key an SRK? i.e. is noda required? Comments are welcomed
 

The additional benefit of this approach is that you should be using an SRK anyways to protect all your secrets, and you can cryptographically erase all your secrets by calling tpm2_clear. This is the approach used (and recommended) by the Azure Device Provisioning Service for Device Attestation, more information can be found here https://docs.microsoft.com/en-us/azure/iot-dps/concepts-tpm-attestation. The Azure C SDK also implements something similar to this https://github.com/Azure/azure-iot-sdk-c/search? q=TPM+Attestation

 

Device Identity with EK + AK

=======================

 

In the case that you want to add an integrity requirement before considering the device trusted, we can use a combination of EK and AK to achieve it.

 

The sample implementation of this approach is:

 

  echo "Enrolling with Atestation Key"

  # Clear the TPM

  tpm2_clear

  # Create Endorsement Key

  tpm2_createek -c ek.ctx -G rsa -u ek.pub

  # Create Attestation Key

  tpm2_createak -C ek.ctx -c ak.ctx -G rsa -g sha256 -s rsassa

  tpm2_readpublic -c ak.ctx | grep '^name:' | awk '{ print $2 }' > ak.name

 

  # Generate the nonce and credential for challenge in the Server

  openssl rand -hex 6 > nonce.plain

  tpm2_makecredential -e ek.pub -s nonce.plain -n $(cat ak.name) -o nonce.encrypted

 

  # Decrypt nonce with AK

  tpm2_startauthsession --policy-session -S session.ctx

  TPM2_RH_ENDORSEMENT=0x4000000B

  tpm2_policysecret -S session.ctx -c ${TPM2_RH_ENDORSEMENT}

  tpm2_activatecredential -c ak.ctx -C ek.ctx -i nonce.encrypted -o nonce.decrypted -P "session:session.ctx"

  tpm2_flushcontext session.ctx

 

  # Validate nonce

  diff nonce.decrypted nonce.plain

 

Details:
The AK needs to be created by the device owner, and persisted for later use. 
The server needs to know the ek.pub and ak.name to generate the challenge
The device uses the EK and persisted AK to solve the challenge
The same nonce could be use to generate a quote of the PCRs, and proof the integrity state to the server. This improves the level of trust of the device, given that the server knows that the device is the expected one, and the software (BIOS, bootloader, kernel, etc) running in the device is the correct.
After a tpm2_clear, the AK will be deleted, and the device will not be able to proof it identity to the server. This is desired.
 

Problems:
I cannot persist the AK. Using tpm2_evictcontrol -c 0x81010002 -o ak.ctx causes a ”the handle is not correct for use” error.
The AK name saved by tpm2_createak is a binary blob (apparently), and cannot be used to create the challenge. I have to grep the AK name from the public AK information. Is this a bug?
 

A similar approach (including the attestation quote validation) is taken by StrongSwan in its Trusted Network Connect (TNC) HOWTO guide: https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect

 

Hope you can help me clarify some of the problems and details with the 3 approaches!

And also, I hope this is useful information for any tpm2-software user.

 

Thank you!


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

[-- Attachment #3: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5243 bytes --]