Hi Sherry,

Thanks for the quick response. The following sequence, explicitly closing the key after creation, seems to allow me to use psa_open_key, thank you:

/* Import the private key, creating the persistent key on success */
psa_import_key(&key_attributes, key_data, key_len, &key_handle);

/* Close the key to free up a volatile slot. */
psa_close_key(key_handle);

/* Now try to re-open the persisted key based on the key ID. */
psa_open_key(key_id, &key_handle);

Best regards,
Kevin

On Wed, 13 May 2020 at 12:48, Sherry Zhang <Sherry.Zhang2@arm.com> wrote:

Hi Kevin,

 

Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open).

 

After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly.

 

Hope it can help you!

 

Regards,

Sherry Zhang

 

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: Wednesday, May 13, 2020 5:47 PM
To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Query on persistent keys Crypto API

 

Hi,

 

Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8

 

This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/crypto/crypto_tests_common.c#n939

 

Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M?

 

Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access?

 

The 1.0 API documentation, for example, describes:

 

psa_status_t psa_export_public_key(psa_key_id_t key,
                                   uint8_t * data, size_t data_size, size_t * data_length);

 

 

psa_status_t psa_export_public_key(psa_key_handle_t handle,
                                   uint8_t *data,
                                   size_t data_size,
                                   size_t *data_length);

 

Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1?

 

Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/crypto/crypto_tests_common.c#n939

 

However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back.

 

I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-psa_crypto-c-L99

 

If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)?

 

Best regards,

Kevin