If we need to set a PIN to get the TPM ownership. Then how can we keep the PIN security?

[qq8512852]

If we need to set a PIN to get the TPM ownership. Then how can we keep the PIN security? If we don't want other unauthorized user or application to use our TPM to already created key. So we should take ownership for TPM. Firstly it should be set a PIN code. But if we need implement the function by writing code. How can we keep the PIN code security?

[williamcroberts]

Taking ownership is setting the Endorsement, Lockout and Owner auth values. The Endorsement, Lockout and Owner are "hierarchies" which form the root of a tree. These are only required for initial provisioning and modification of the hierarchy. Once set, initial provisioning also includes creating a storage root key, SRK, under the owner hierarchy and persisting it [1]. This persistent key has no password and is used a working space for subordinate keys. People then create keys under the SRK and can apply whatever policies and passwords they want. So once you initial provision you don't need to store the password except for administrative purposes. For generated keys, you can set them up to PCR policies so you don't need a password per key object.

[1] See Section 7.5 of https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf

[qq8512852]

Sorry， I'm a little confused. My question is from commands（encrypt and decrypt demo with tpm2-tools） as follow: 1、tpm2_takeownership -o ownerpass -e endorsepass -l lockpass 2、tpm2_createprimary -A e -K objectpass -g 0x000b -G 0x0001 -C po.ctx 3、tpm2_create -c po.ctx -P objectpass -K subobjectpass -g 0x000b -G 0x0001 -o key.pub -O key.priv 4、tpm2_load -c po.ctx -P objectpass -u key.pub -r key.priv -n key.name -C obj.ctx 5、tpm2_rsaencrypt -c obj.ctx -I data.in -o data.encrypted 6、tpm2_rsadecrypt -c obj.ctx -P subobjectpass -I data.encrypted -o data.out As we see the objectpass is created from step 2 as input passcode. And it will be used at step 3 and 4. Now this process is executed through commands. In the actual product development. Step 2 we can set objectpass in advance before the product leave to factory product line.(We can regard it as a security environment) However, when objectpass is requred in step 3 and step 4, it is after the actual delivery. At this point, the product is in a non-security environment，how should app get the objectpass. If objectpass is present in the code in advance, I think it's unsafe. Is there any solution?

[williamcroberts]

In step 2, just make the key not have a password. You would need the endorsement password as well in step 2 which is missing. This is with the updated tools, you're on some old stuff:

tpm2 changeauth -ce endorsepass
# no need for a password on this key as long as you don't use it for anything
tpm2 createprimary -Ce -Pendorsepass -c primary.ctx 
# persist it so you don't need it again
tpm2 evictcontrol -c primary.ctx 
persistent-handle: 0x81000001
action: persisted

# do this out of initial environment
tpm2 create -C 0x81000001 -u key.pub -r key.priv
tpm2 load -C 0x81000001 -u key.pub -r key.priv -c key.ctx
...

[qq8512852]

In step 2, just make the key not have a password. You would need the endorsement password as well in step 2 which is missing. This is with the updated tools, you're on some old stuff:

tpm2 changeauth -ce endorsepass
# no need for a password on this key as long as you don't use it for anything
tpm2 createprimary -Ce -Pendorsepass -c primary.ctx 
# persist it so you don't need it again
tpm2 evictcontrol -c primary.ctx 
persistent-handle: 0x81000001
action: persisted

# do this out of initial environment
tpm2 create -C 0x81000001 -u key.pub -r key.priv
tpm2 load -C 0x81000001 -u key.pub -r key.priv -c key.ctx
...

So as long as you know 0x81000001, any app（Malicious APP） can use key.priv, right?

[qq8512852]

In step 2, just make the key not have a password. You would need the endorsement password as well in step 2 which is missing. This is with the updated tools, you're on some old stuff:

tpm2 changeauth -ce endorsepass
# no need for a password on this key as long as you don't use it for anything
tpm2 createprimary -Ce -Pendorsepass -c primary.ctx 
# persist it so you don't need it again
tpm2 evictcontrol -c primary.ctx 
persistent-handle: 0x81000001
action: persisted

# do this out of initial environment
tpm2 create -C 0x81000001 -u key.pub -r key.priv
tpm2 load -C 0x81000001 -u key.pub -r key.priv -c key.ctx
...

So as long as you know 0x81000001, any app（maybe a Malicious APP in my host device） can use key.priv, right?

@williamcroberts Could you help to explain the problem?

[williamcroberts]

tpm2 create -C 0x81000001 -u key.pub -r key.priv

You would set a password or policy for the child key created under the parent key at 0x81000001.

tpm2 create -C 0x81000001 -p mypassword -u key.pub -r key.priv

You only keep a blank password on the persistent key so anyone can use it as parent key. You would never use that parent key for anything but a storage key. This is the guidance of the PC Provisioning Document https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf see section 7.5