Hi Brian,
It is true that each persistent key has only one owner who can access it, the partition that created it.
But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own.
I think a more expected flow would look like:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID. 3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1. 4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material.
But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted.
I am adding the psa-crypto mailing list to this, as people on there may have more/better input.
Kind regards, Jamie
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Quach, Brian via TF-M Sent: 10 July 2020 06:18 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Persistent key storage ownership/access
Hi,
I see that keys can only be accessed/modified by their owning secure partition.
File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1)
Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3.
However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work.
Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be:
| 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver
The file ID would not match what the App imported and the key would not be found.
Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated?
Another explanation of the scenario if the above was not clear:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function and provides the key ID. 3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition.
RoT Partition 1:
* PSA Crypto (with keystore)
RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators)
RoT Partition 3:
* ITS
Regards,
Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076