[tpm2] Re: Check to see if signature is okay, then reboot

[tpm2] Re: Check to see if signature is okay, then reboot

[Roberts, William C]

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



> -----Original Message-----
> From: Frederick Gotham [mailto:cauldwell.thomas(a)gmail.com]
> Sent: Thursday, December 5, 2019 12:14 PM
> To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2 <tpm2(a)lists.01.org>
> Subject: Re: Check to see if signature is okay, then reboot
> 
> > But anyways, you can use nvram to store it, and then use the key
> > externally with openssl or call tpm2_loadexternal again.
> 
> 
> 
> 
> First I will try to load a keypair into the TMP2, such that the private part is garbage
> but the public part is correct.

That only works for the null hierarchy, which get you back to tpm2_evictcontrol error.
Per spec of tpm2_loadexternal:
Load of a public external object area allows the object be associated with a hierarchy so that the correct
algorithms may be used when creating tickets. The hierarchy parameter provides this association. If the
public and sensitive portions of the object are loaded, hierarchy is required to be TPM_RH_NULL.

I would also be surprised if the tpm2_loadexternal tool's interface would be flexible enough to allow this easily.

Even if you got this to work, you bump back into the evictcontrol issue:
If objectHandle references a Transient Object:
The TPM shall return TPM_RC_ATTRIBUTES if
1) it is in the hierarchy of TPM_RH_NULL,
2) only the public portion of the object is loaded, or
3) the stClear is SET in the object or in an ancestor key.


> 
> 
> To achieve this, I will first try to zero out parts of the private key before I load it in.
> I'm not sure if this will work. (It works with openssl anyway).

[tpm2] Re: Check to see if signature is okay, then reboot

[Frederick Gotham]

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

> But anyways, you can use nvram to store it,
> and then use the key externally with openssl
> or call tpm2_loadexternal again.


First I will try to load a keypair into the TMP2, such that the private
part is garbage but the public part is correct.

To achieve this, I will first try to zero out parts of the private key
before I load it in. I'm not sure if this will work. (It works with openssl
anyway).

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

[tpm2] Re: Check to see if signature is okay, then reboot

[Roberts, William C]

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



> -----Original Message-----
> From: Frederick Gotham [mailto:cauldwell.thomas(a)gmail.com]
> Sent: Wednesday, December 4, 2019 2:04 PM
> To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2 <tpm2(a)lists.01.org>
> Subject: Re: Check to see if signature is okay, then reboot
> 
> 
> 	You need to call tpm2_loadexternal again to load the public portion of the
> key into
> 	The TPM or you need to mark the pubic object persistent with
> tpm2_evictcontrol.
> 	However, I would urge against that. Just load the object when you need
> it. A RM
> 	Should take care of flushing "transient" objects when your don't with
> them, or if
> 	Using the TPM directly, tpm2_flushcontext.
> 
> 
> 
> 
> Against all logic or rationale, I simply have to fulfill one of the requirements that
> my boss has given me (which was handed down to him from another person).
> The requirement is that no RSA keys are stored on the hard disk. Therefore a
> public key must be loaded into the TPM2 chip once in the factory where is to be
> stored persistently and used to verify signatures.

You can't persist a public only portion of a key. Per the spec:
If objectHandle references a Transient Object:
The TPM shall return TPM_RC_ATTRIBUTES if
1) it is in the hierarchy of TPM_RH_NULL,
2) only the public portion of the object is loaded, or
3) the stClear is SET in the object or in an ancestor key.

> 
> So how should I go about this?

To do this, which makes no sense. Unless your gating access to a secret/private on the TPM
via policy/password or using attestation features, it doesn't make sense. But anyways, you can
use nvram to store it, and then use the key externally with openssl or call tpm2_loadexternal
again.

assuming you have a certificate or whatever as public.pem
size=$(wc -c public.pem | cut -d' ' -f1-1)

# NOTE: you can pick the nvindex by passing an argument starting at 0 or the actual tpm address
tpm2_nvdefine -s $size
nv-index: 0x1000000

tpm2_nvwrite -i public.pem 0

tpm2_nvread 0
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoFPZTTN+JvjQuAuFCx5Y
lrziFRKfreNrqmp0rBZwv7D2fElBBPKBglpPBD30XYQV+d+Rj6gIwN5vAt64Rrqd
dAM1SGOnj9WL0O7aL3KAJB6JuOpd9eWa7bftviEg/u4P18K3h5rxlqy1AYrLSMg1
lJHMmibyxCgf8K5cAZAcGz5zc5VtHD6hO/IsvJwwltOLadhJFPC9mcjhjlfLzXdl
jx+PlJ0RQp6ZzAChLB0UkqVHaF41YSCYmJhIM8INu6n3+HwcSbFK93jP12+AmBKX
thRUcdaf3FxttKfIUQ5dHhyxAhxVCgrAhsVEQTMO9LDIMBMouVIRWd6aat77tRC0
pQIDAQAB
-----END PUBLIC KEY-----

You could tpm2_loadexternal that back If you desire.

That will get it loaded in, but again it’s a public key, thus you just assume everyone
has it, that’s how PKI works.

A better way, would be that FW is not released from a server unless an attestation
Is done with a key gated on policysignature using at least a pcr policy. The key could
Tied to the manufacturer certificate/EndorsmentCRredential or part of the endorsement
hierarchy. A quote could be exchanged with the server, so the server can validate the device
is in a known state, and then release the firmware encrypted with that machines public key
and sent to the client. That private key, which is gated on policy, can then be used to decrypt
the firmware.

I'm not sure if this is the best way, but it's better than storing a public key for verification in the TPM,
That doesn't buy you anything except persistence against accidental file system deletion.

> 
> Should I do "createprimary", then follow it with "loadexternal" to load the public
> key into the chip? What should I do next? Should I use "evictcontrol" to move it
> into non-volatile storage? I tried using evictcontrol today to move it into non-
> volatile storage but I couldn't find the handle for the public key when I queried
> "getcap".
> 
> 
> 
> 
> 	Those files used in the -C and -c options are context files. Between
> command invocations
> 	The tools save the object context for re-use during, essentially, that boot
> of the TPM.
> 	After reboot, you need to re-get a context file, in your case
> tpm2_loadexternal will
> 	provide it.
> 
> 
> 
> 
> How do I get a context file for a key that's already stored persistently inside the
> TPM2 chip?

Context files are only for transient objects, if it's loaded persistently you can either use 
the raw handle (which is a TPM address) or better yet an ESYS_TR handle file. The
ESYS_TR's contain metadata so you cannot be MITM by an attacker intercepting calls
(perhaps bus snooping) and giving you the wrong object.

[tpm2] Re: Check to see if signature is okay, then reboot

[Frederick Gotham]

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

>
>
> You need to call tpm2_loadexternal again to load the public portion of the
> key into
> The TPM or you need to mark the pubic object persistent with
> tpm2_evictcontrol.
> However, I would urge against that. Just load the object when you need it.
> A RM
> Should take care of flushing "transient" objects when your don't with
> them, or if
> Using the TPM directly, tpm2_flushcontext.




Against all logic or rationale, I simply have to fulfill one of the
requirements that my boss has given me (which was handed down to him from
another person). The requirement is that no RSA keys are stored on the hard
disk. Therefore a public key must be loaded into the TPM2 chip once in the
factory where is to be stored persistently and used to verify signatures.

So how should I go about this?

Should I do "createprimary", then follow it with "loadexternal" to load the
public key into the chip? What should I do next? Should I use
"evictcontrol" to move it into non-volatile storage? I tried using
evictcontrol today to move it into non-volatile storage but I couldn't find
the handle for the public key when I queried "getcap".




> Those files used in the -C and -c options are context files. Between
> command invocations
> The tools save the object context for re-use during, essentially, that
> boot of the TPM.
> After reboot, you need to re-get a context file, in your case
> tpm2_loadexternal will
> provide it.
>


How do I get a context file for a key that's already stored persistently
inside the TPM2 chip?

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

[tpm2] Re: Check to see if signature is okay, then reboot

[Roberts, William C]

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



> -----Original Message-----
> From: Frederick Gotham [mailto:cauldwell.thomas(a)gmail.com]
> Sent: Wednesday, December 4, 2019 7:41 AM
> To: tpm2 <tpm2(a)lists.01.org>
> Subject: [tpm2] Check to see if signature is okay, then reboot
> 
> I'm trying to use the TPM2 check to verify a signature. Here's what I'm doing:
> 
>     # 1 : Generate a key pair
>     openssl genrsa -out rsa.private 2048
>     openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
> 
>     # 2 : Create two firmware files, the real one and the hacked one
>     echo "this is our actual   firmware yeah" > rootfs.tar
>     echo "this it our hacked  firmware yeah" > rootfs_hacked.tar
> 
>     # 3 : Create a signature file
>     openssl dgst -sha256 -sign rsa.private -out signature_file rootfs.tar
> 
>     # 4 : Use the TPM2 chip to verify the signature

Verifying a signature with the TPM doesn't really provide much for
guarantees directly over software verification. Especially when it's
an externally sourced public key. Unless you're in an environment where
OSSL doesn't exist, and your just using it as an offload mechanism.

>     tpm2_loadexternal -G rsa -u rsa.public -c key_context_file_for_tpm2
>     tpm2_verifysignature -Q -c key_context_file_for_tpm2 -g sha256 -m
> rootfs_hacked.tar -f rsassa -s signature_file
> 
>     return_code=$?
>     echo The returned code was: ${return_code}
> 
>     case $return_code in
>             0) echo 0 means success;;
>             1) echo 1 means general error;;
>             2) echo 2 means options handling error;;
>             3) echo 3 means authentication error;;
>             4) echo 4 means tcti error;;
>             5) echo 5 means unsupported scheme;;
>     esac
> 
> 
> This works fine. But of course then I reboot, and I try to verify the signature again
> with this one line:
> 
>     tpm2_verifysignature -Q -c key_context_file_for_tpm2 -g sha256 -m
> rootfs_hacked.tar -f rsassa -s signature_file
> 
> This fails. . . presumably because the key was in volatile memory the last time
> around (and so it got wiped upon reboot).

You need to call tpm2_loadexternal again to load the public portion of the key into
The TPM or you need to mark the pubic object persistent with tpm2_evictcontrol.
However, I would urge against that. Just load the object when you need it. A RM
Should take care of flushing "transient" objects when your don't with them, or if
Using the TPM directly, tpm2_flushcontext.

Those files used in the -C and -c options are context files. Between command invocations
The tools save the object context for re-use during, essentially, that boot of the TPM.
After reboot, you need to re-get a context file, in your case tpm2_loadexternal will
provide it.


> 
> So I load the public key back in again, and this time around I want to make it
> persistent. So after I load it in, I get a list of all handles with these four commands:
> 
>     tpm2_getcap handles-transient
>     tpm2_getcap handles-persistent
>     tpm2_getcap handles-loaded-session
>     tpm2_getcap handles-saved-session
> 
> All of these four commands return nothing. If I haven't got a handle then I can't
> make it persistent.
> 
> Any ideas?
> _______________________________________________
> 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