pkcs11: Generating and storing keys

[abhkr24]

Hi!
I am trying to use op-tee as a virtual HSM and I want to renew the keys periodically.
In the pkcs11 TA, I see that there are commands to generate keys and sign - PKCS11_CMD_GENERATE_KEY and PKCS11_CMD_SIGN_ONESHOT.
But I could not find information about how OP-TEE stores the generated keys. I do not want the keys leaked to the userspace.
(I don't know what this line does in libckteec
memcpy(&key_handle, out_shm->buffer, sizeof(key_handle)); )

So my question is, how does OP-TEE know what keys to use to sign since the command to sign does not have any input parameters relating to key material and where does it store the generated keys? Where is the key tied to the session?
And lastly, are the generated keys persistent across reboot?

Apologies if this has already been answered elsewhere. I am new to implementing op-tee and this piece of information would be of great help to get me started :)
Thanks.

[etienne-lms]

Hi @abhkr24,
OP-TEE's pkcs11 TA uses the generic OP-TEE secure storage TEE_STORAGE_PRIVATE to store pkcs11 objects and pkcs11 token state. OP-TEE native secure storage is an RPMB partition of an eMMC device, using a RPMB key derived from a device HW unique key. OP-TEE encrypts the data stored in secure storage using another key derived from the device HW unique key and the TA UUID (here the pkcs11 TA UUID).
You can find more info in OP-TEE's documentation on secure storage.

[abhkr24]

Thank you for your response! It is now clear to me that OP-TEE natively does secure storage.
My question is more towards the PKCS11 TA -

1. when I use the PKCS11_CMD_GENERATE_KEY_PAIR command, I see that it returns both a public key handle and a private key handle. Does this mean both the keys are exposed to the optee_client application?
2. Is there a way in the pkcs11 TA to just export the public key in a .pem format and not export the private key at all?
3. Does the TA have any functions that maintain the session state?

[etienne-lms]

1. when I use the PKCS11_CMD_GENERATE_KEY_PAIR command, I see that it returns both a public key handle and a private key handle. Does this mean both the keys are exposed to the optee_client application?

The key handles are always exposed to the client on key generation operation but some private key data can be retrieved by the client only if the keys attributes allow it (check attributes CKA_SENSITIVE, CKA_EXTRACTABLE). Public key data can always be exported to a client.

2. Is there a way in the pkcs11 TA to just export the public key in a .pem format and not export the private key at all?

You can use pkcs11-tool to get the public key from the pkcs11 token in DER format, e.g.:
pkcs11-tool --token-label test-token --read-object --label test-key --type pubkey -o pub.key
and convert to PEM using openssl, e.g.:
openssl rsa -pubin -inform DER -in pub.key -outform PEM -out pub.pem

Or extract public key with openssl (needs openssl with pkcs11 engine support) with something like:
openssl rsa -engine pkcs11 -inform engine -in "pkcs11:token=test-token;object=test-key;type=public" -pubout -out pub.pem

3. Does the TA have any functions that maintain the session state?

A session state is handled by struct pkcs11_session. Session management functions are implemented in ta/pkcs11/src/pkcs11_token.c. The session state is also used at several place, to check whether or not an object or its attributes can be accessed or an operation be processed.

[abhkr24]

Thank you for the detailed response. I will work on building this into my system.
To this effect, I tried building optee 3.15.0 and 3.16.0 but both of these builds did not boot on my zcu102 board. It hangs after the BL31 phase. However, OP-TEE 3.7.0 works fine.
I read here that OP-TEE 3.8.0 onwards the boot flow has changed. Could you please point me to any documentation or comment in this regard?
Currently, I am using tee elfs as BL32 and it works for 3.7.0 but fails for the later versions. I need the later version because I am trying to add pkcs11 ta.

Thank you for your attention :)