Julie P
2015-08-13 12:03:41 UTC
Hi everyone,
The spec says that the private key, of an RSA keypair, have to be encrypt before it goes out as a blob.
Loading the blob unencrypt it.
My aim is to verify if the private is accessed somewhere else, and how. (I have to prove it for my internship).
I'm using Trousers 3.13 with an hardware TPM v1.2.
Load the key by its blob (TPM_LoadKey2) load the real private and public part, and return a EVP_PKEY as handle/as reference, am I right?
And this handle only contain some informations about the private key, that's all?
For example in OpenSSL, the 'openssl req' and 'openssl s_client' call : pkey = load_key(...)
pkey type is EVP_PKEY and this type is used everywhere in OpenSSL to represent the private key
But in fact when we connect with a certificate (openssl s_client), even when we create the certificate with our key (openssl req), we don't need to access to the real private key? I see nowhere when the private key is verify in the source code (only compare EVP_PKEY to another), so maybe I didn't understand 100% of both process..
Then the only time when we need to acces to the real private key would be if we want to sign or encrypt a data with it, and so we will to do it inside the TPM etc. so the private key stay private.
So I have to focus on the OpenSSL load_key() function, right?
I found that load_key() refers in the end to tpm_engine_load_key() :
tpm_engine_load_key calls p_tspi_Context_LoadKeyByBlob
<-> TPM_F_Context_LoadKeyByBlob
<-> Tspi_Context_LoadKeyByBlob, which performs:
(1) obj_context_get_loadkey_ordinal(tspContext, &ordinal)
(2) UnloadBlob_TSS_KEY(&offset, rgbBlobData, &keyContainer)
(3) TCS_API(tspContext)->LoadKeyByBlob(tspContext, tcsParentHandle, ulBlobLength, rgbBlobData, pAuth, &myTCSKeyHandle, &keyslot)
(4) obj_rsakey_set_tcpakey(*phKey,realKeyBlobSize, rgbBlobData);
return obj_rsakey_set_tcs_handle(*phKey, myTCSKeyHandle);
rgbBlobData refers to the blob file
phKey refers to the pkey returned in the end
(1) ok : TPM_ORD_LoadKey2 <=> TPM_LoadKey2, spec 1.2
(2) I didn't really understand that...
(4) informations recover by the (3) in myTCSKeyHandle are set in the EVP_PKEY
(3) LoadKeyByBlob refers to RPC_LoadKeyByBlob or Transport_LoadKeyByBlob
I didn't find which one is used, but RPC_LoadKeyByBlob do :
- sendTCSDPacket(hte)
- getData(TCSD_PACKET_TYPE_UINT32, i++, phKeyTCSI, 0, &hte->comm) //phKeyTCSI will became the phkey : the EVP_PKEY pkey
This the final, all that matters no? the hte send contain informations about the command and the key to load.
Finally in "TPM Main-Part 3 Commands, TPM_LoadKey2", just this lines matters? :
8. Perform any processing necessary to make TPM_STORE_ASYMKEY key available for operations
9. Load key and key information into internal memory of the TPM.
So :
- the TPM received the TPM_LoadKey2 command, load the key, and send us a EVP_PKEY.
- the communication between TPM and us is only set by packet with a TPM command (specify in the spec Command)
=> We can't guess or reproduce the private key via EVP_PKEY or packets send.
The spec says that the private key, of an RSA keypair, have to be encrypt before it goes out as a blob.
Loading the blob unencrypt it.
My aim is to verify if the private is accessed somewhere else, and how. (I have to prove it for my internship).
I'm using Trousers 3.13 with an hardware TPM v1.2.
Load the key by its blob (TPM_LoadKey2) load the real private and public part, and return a EVP_PKEY as handle/as reference, am I right?
And this handle only contain some informations about the private key, that's all?
For example in OpenSSL, the 'openssl req' and 'openssl s_client' call : pkey = load_key(...)
pkey type is EVP_PKEY and this type is used everywhere in OpenSSL to represent the private key
But in fact when we connect with a certificate (openssl s_client), even when we create the certificate with our key (openssl req), we don't need to access to the real private key? I see nowhere when the private key is verify in the source code (only compare EVP_PKEY to another), so maybe I didn't understand 100% of both process..
Then the only time when we need to acces to the real private key would be if we want to sign or encrypt a data with it, and so we will to do it inside the TPM etc. so the private key stay private.
So I have to focus on the OpenSSL load_key() function, right?
I found that load_key() refers in the end to tpm_engine_load_key() :
tpm_engine_load_key calls p_tspi_Context_LoadKeyByBlob
<-> TPM_F_Context_LoadKeyByBlob
<-> Tspi_Context_LoadKeyByBlob, which performs:
(1) obj_context_get_loadkey_ordinal(tspContext, &ordinal)
(2) UnloadBlob_TSS_KEY(&offset, rgbBlobData, &keyContainer)
(3) TCS_API(tspContext)->LoadKeyByBlob(tspContext, tcsParentHandle, ulBlobLength, rgbBlobData, pAuth, &myTCSKeyHandle, &keyslot)
(4) obj_rsakey_set_tcpakey(*phKey,realKeyBlobSize, rgbBlobData);
return obj_rsakey_set_tcs_handle(*phKey, myTCSKeyHandle);
rgbBlobData refers to the blob file
phKey refers to the pkey returned in the end
(1) ok : TPM_ORD_LoadKey2 <=> TPM_LoadKey2, spec 1.2
(2) I didn't really understand that...
(4) informations recover by the (3) in myTCSKeyHandle are set in the EVP_PKEY
(3) LoadKeyByBlob refers to RPC_LoadKeyByBlob or Transport_LoadKeyByBlob
I didn't find which one is used, but RPC_LoadKeyByBlob do :
- sendTCSDPacket(hte)
- getData(TCSD_PACKET_TYPE_UINT32, i++, phKeyTCSI, 0, &hte->comm) //phKeyTCSI will became the phkey : the EVP_PKEY pkey
This the final, all that matters no? the hte send contain informations about the command and the key to load.
Finally in "TPM Main-Part 3 Commands, TPM_LoadKey2", just this lines matters? :
8. Perform any processing necessary to make TPM_STORE_ASYMKEY key available for operations
9. Load key and key information into internal memory of the TPM.
So :
- the TPM received the TPM_LoadKey2 command, load the key, and send us a EVP_PKEY.
- the communication between TPM and us is only set by packet with a TPM command (specify in the spec Command)
=> We can't guess or reproduce the private key via EVP_PKEY or packets send.