Hi Ruchika,

On 11/07/2023 19:14, Ruchika Gupta via mbed-tls wrote:

Hi,

I am currently working on PSA driver for our SoC’s security crypto-processor. This processor needs to do some handling when a key is destroyed.

In the current implementation in mbedTLS,  I don’t see a driver wrapper function available in psa_destroy_key(). Is there a specific reason for not having wrapper for driver function available for psa_destroy_key() ?

Mbed TLS does not yet support drivers for secure elements that store the key material themselves, only secure elements for which the outside world must store a wrapped (encrypted) copy of the key. The absence of a destroy_key driver wrapper is not the only thing that's missing: a bigger part is correct handling of power failures.

On our roadmap (https://mbed-tls.readthedocs.io/en/latest/project/roadmap/) this is listed as “Handle Opaque Persistent Key in Secure Element - Implementation” and currently scheduled for early 2024. (Note that the roadmap more than a quarter ahead is very tentative.) A design specification is in https://github.com/Mbed-TLS/mbedtls/blob/development/docs/architecture/psa-s...

Another query pertaining to the tests in the testsuite in mbedTLS. I was exploring if I could reuse the tests for the crypto-processor implementation.  Have these been written with this kind of reuse in mind ?

Basically I would like the ability to add driver location to the cases. The few cases I have looked at for psa seem to be very specific. Any pointers/suggestions if anyone is reusing this test suite to test their specific PSA drivers?

That is something we'd like to do in the long term, but we do not have concrete plans yet, and we don't know when we might work on it. There are several aspects:

* Getting the tests to call the secure element. I think we'd accept a patch for that if it isn't too invasive, but I'm not sure what could work and would be “not too invasive”. A workaround could be to define accelerator driver wrappers that import the key into the secure element each time it's used. * A few test cases might run into legitimate differences. For example, in some error cases, the PSA specification allows multiple error codes, but our tests insist on the particular error code that our implementation returns. Generally we'd be ok with either making these test cases less constraining, or moving them to a separate test suite that driver implementers can skip. * The test coverage for the PSA API mostly focuses on the kind of mistake that might happen in a software implementation. It assumes that the underlying software implementation is itself mostly correct. For example, PSA cipher tests don't particularly try to check that the AES permutation is implemented correctly for a lot of different inputs, but they check things like buffer sizes, use of the intended algorithm, rejecting bad inputs, etc. Conversely, our tests do not try to look for the kind of mistakes that might happen in a hardware implementation, for example data leakage between operations if an accelerator is not reset properly between calls.

If anyone has ideas on this topic and time to work on this, feel free to discuss it with us. We (the Mbed TLS developer team) probably won't have much time to spend on this for at least another year, but we can at least look at proposals and see if it's something that we might integrate at some point.

Best regards,