goal: use TPM to protect a blob of data (using tpm 2.0)
option # 1: Doing seal using the TPM2_Create() and then TPM2_Load() and using TPM2_Unseal() to get the data from the TPM.
option # 2: Using TPM2_EncryptDecrypt() on a software TPM but on the hardware TPM it says that TPM2_EncryptDecrypt is NOT supported.
Common stuff for above 2 options: Created a primary key (key_1) (RSA key-pair).
Difference b/w 2 options: As per my understanding the difference between seal and TPM2_EncryptDecrypt() is as follows:
option # 1 (seal/unseal): Use the primary key (key_1) as the parent to create another key pair (key_2) and providing the blob of data to be sealed. Using TPM2_Load() to load both priv and pub part of key_2 to the TPM. TPM2_Load() will give a handle which will be used to TPM2_Unseal(). In this option, the private part of key created using create (key_2) is wrapped by the parent key (key_1) and then loaded into the TPM. Here the data is protected by encrypting using the public part of the key (key_2) and decrypted using he private part of the key (key_2) which is created using TPM2_create().
option # 2: TPM2_EncryptDecrypt(): Does symmetric encryption of the data. Here there is just one key which is used for encrypt/decrypt and this key never leaves the TPM.
Is my understanding correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your option #1 is very close.
1. The sealed blob can be a primary object as well as a child.
2. The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
See testunseal.sh for examples.
Option 1 uses structured data (create) and the authorization to unseal is part of the data structure. The load uses the authorization of the parent.
Option 2 works on unstructured data and authorization is that of the key.
FYI, encryptdecrypt is typically not implemented because general purpose symmetric key encryption has legal issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
from the testunseal.sh script consider the following code:
53echo"Create a sealed data object"54 ${PREFIX}create-hp80000000-bl-ktf-ktp-oprtmppriv.bin-oputmppub.bin-pwdpsto-pwdksea-ifmsg.bin>run.out55checkSuccess $?
5657echo"Load the sealed data object"58 ${PREFIX}load-hp80000000-iprtmppriv.bin-iputmppub.bin-pwdpsto>run.out59checkSuccess $?
6061echo"Unseal the data blob"62 ${PREFIX}unseal-ha80000001-pwdsea-oftmp.bin>run.out63checkSuccess $?
80000000: handle of primary key which is RSA key pair
msg.bin: is the blob to be sealed
create: creates asymmetric key pair tmppriv.bin & tmppub.bin and the msg.bin will be part of the tmppriv.bin. And tmppriv.bin is protected by the parent key with handle 80000000.
load : loads tmppriv.bin & tmppub.bin
In the above msg you mentioned: The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
Follow up questions:
qts1: The parent is the primary key with handle 80000000 which is a asymmetric RSA key as I created that usnig ./createprimary -hi o. How is then the sealed blob protected by the symmetric key of the parent; when the parent is an asymmetric key?
qts2: What is a maning of asymmetric key is used for duplication and import. Is this tmppriv.bin & tmppub.bin you were referring to.
Last edit: noway 2020-10-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every storage key has a symmetric key that is used to wrap the child objects of the parent storage key. It also has an asymmetric key that is used for duplication and import.
Those tmp parts are not keys in this case. They are sealed data blobs, -bl. The private part contains the data, password, and integrity over the public part. The public part contains the attributes and policy.
That is, create can create various keys, but it can also create sealed data. The difference is that there is no API to request a private key. There is an API, unseal, to get the private part of sealed data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
from the testunseal.sh script consider the following code:
53echo"Create a sealed data object"54 ${PREFIX}create-hp80000000-bl-ktf-ktp-oprtmppriv.bin-oputmppub.bin-pwdpsto-pwdksea-ifmsg.bin>run.out55checkSuccess $? 5657echo"Load the sealed data object"58 ${PREFIX}load-hp80000000-iprtmppriv.bin-iputmppub.bin-pwdpsto>run.out59checkSuccess $? 6061echo"Unseal the data blob"62 ${PREFIX}unseal-ha80000001-pwdsea-oftmp.bin>run.out63checkSuccess $?
80000000: handle of primary key which is RSA key pair
msg.bin: is the blob to be sealed
create: creates asymmetric key pair tmppriv.bin & tmppub.bin and the msg.bin will be part of the tmppriv.bin. And tmppriv.bin is protected by the parent key with handle 80000000.
load : loads tmppriv.bin & tmppub.bin
In the above msg you mentioned: The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
Follow up questions:
qts1: The parent is the primary key with handle 80000000 which is a asymmetric RSA key as I created that usnig ./createprimary -hi o. How is then the sealed blob protected by the symmetric key of the parent; when the parent is an asymmetric key?
qts2: What is a maning of asymmetric key is used for duplication and import. Is this tmppriv.bin & tmppub.bin you were referring to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
goal: use TPM to protect a blob of data (using tpm 2.0)
option # 1: Doing seal using the TPM2_Create() and then TPM2_Load() and using TPM2_Unseal() to get the data from the TPM.
option # 2: Using TPM2_EncryptDecrypt() on a software TPM but on the hardware TPM it says that TPM2_EncryptDecrypt is NOT supported.
Common stuff for above 2 options: Created a primary key (key_1) (RSA key-pair).
Difference b/w 2 options: As per my understanding the difference between seal and TPM2_EncryptDecrypt() is as follows:
option # 1 (seal/unseal): Use the primary key (key_1) as the parent to create another key pair (key_2) and providing the blob of data to be sealed. Using TPM2_Load() to load both priv and pub part of key_2 to the TPM. TPM2_Load() will give a handle which will be used to TPM2_Unseal(). In this option, the private part of key created using create (key_2) is wrapped by the parent key (key_1) and then loaded into the TPM. Here the data is protected by encrypting using the public part of the key (key_2) and decrypted using he private part of the key (key_2) which is created using TPM2_create().
option # 2: TPM2_EncryptDecrypt(): Does symmetric encryption of the data. Here there is just one key which is used for encrypt/decrypt and this key never leaves the TPM.
Is my understanding correct?
Your option #1 is very close.
1. The sealed blob can be a primary object as well as a child.
2. The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
See testunseal.sh for examples.
Option 1 uses structured data (create) and the authorization to unseal is part of the data structure. The load uses the authorization of the parent.
Option 2 works on unstructured data and authorization is that of the key.
FYI, encryptdecrypt is typically not implemented because general purpose symmetric key encryption has legal issues.
from the testunseal.sh script consider the following code:
80000000: handle of primary key which is RSA key pair
msg.bin: is the blob to be sealed
create: creates asymmetric key pair tmppriv.bin & tmppub.bin and the msg.bin will be part of the tmppriv.bin. And tmppriv.bin is protected by the parent key with handle 80000000.
load : loads tmppriv.bin & tmppub.bin
In the above msg you mentioned: The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
Follow up questions:
qts1: The parent is the primary key with handle 80000000 which is a asymmetric RSA key as I created that usnig ./createprimary -hi o. How is then the sealed blob protected by the symmetric key of the parent; when the parent is an asymmetric key?
qts2: What is a maning of asymmetric key is used for duplication and import. Is this tmppriv.bin & tmppub.bin you were referring to.
Last edit: noway 2020-10-01
That is, create can create various keys, but it can also create sealed data. The difference is that there is no API to request a private key. There is an API, unseal, to get the private part of sealed data.
from the testunseal.sh script consider the following code:
80000000: handle of primary key which is RSA key pair
msg.bin: is the blob to be sealed
create: creates asymmetric key pair tmppriv.bin & tmppub.bin and the msg.bin will be part of the tmppriv.bin. And tmppriv.bin is protected by the parent key with handle 80000000.
load : loads tmppriv.bin & tmppub.bin
In the above msg you mentioned: The sealed blob is protected by the symmetric key of the parent, not the asymmetric key (which is used for duplication and import).
Follow up questions:
qts1: The parent is the primary key with handle 80000000 which is a asymmetric RSA key as I created that usnig ./createprimary -hi o. How is then the sealed blob protected by the symmetric key of the parent; when the parent is an asymmetric key?
qts2: What is a maning of asymmetric key is used for duplication and import. Is this tmppriv.bin & tmppub.bin you were referring to.
For duplication, it's far too complex for a posting. Read the TPM spec part 1, then ask questions if an item is unclear.
Thank you much Ken. It's getting clearer.