Need nrf crypto library to have support of importing certificates signed by RSA with SHA1 or SHA-224

[jli157@intel]

Hi Nordic folks, 

Our project is using nrf52840-DK boards as the development beds. We're developing a security application by leveraging the internal CryptoCell CC310 inside the SoC. Right now, we found a problem in parsing the imported certificates:

The device needs to import some certificates signed by RSA with SHA-1 or SHA-384. When the certificate is imported, the function `mbetls_rsa_import_raw` returns the error with the code:

MBEDTLS_X509_BADCERT_BAD_MD

 

I'm wondering if it is possible to add the support to parse this kind of certificates? If so, how? 

Sorry the head has a typo, it should be SHA-384. 

Thank you! 

Jun 

Intel | Santa Clara| CA| USA

[Martin Lesund]

Hi Jun,
We do not have support for importing of certificates, and no support for SHA-1 or SHA-384 in nrf_crypto. 
SHA-1 and SHA-384 are supported in CC310-code, but I am not sure if it's enabled by default.

When it comes to certificates in general, then you could parse them yourself with the help of some crypto libraries, and then use that raw key in the certificate when you have it. Here is an example on certification handling:  components/libraries/crypto/backend/optiga/optiga_backend_utils.c

(that example is in the optiga-backend, but that is not so relevant since the point is to give some reference to how you can implement it)

[jli157@intel]

Thanks for the reply, Martin! 

Is it possible to submit a change request to nrfconnct-sdk to ask enabling this specific feature? Right now, importing SHA-256 certificates is ok but we need to parse those with SHA-384. 

Also on Zephyr, there is only nrfconnect-sdk available: https://github.com/nrfconnect/sdk-nrfxlib/commits/master. I can't use the original sdk directly. 

Thank you!

[Martin Lesund]

Hi Jun,

You are now talking about additions to the nRF5x SDK scope.

What you can do is that you build libraries in nrfxlib in the same way that OpenThread does. 

That means that you would take libraries from nrfxlib (configured and build) and use that in the context of nRF5. In this case, you would need to use mbed TLS API instead of nrf_crypto. 

It may also happen to be that the last version of OpenThread SDK actually has the support you need. 

(The latest OpenThread SDK is based on the nRF5 SDK, but with crypto libraries from nrfxlib/NCS scope).

Please note that we do not have thread support in the nRF5 scope. This is handled with some files that are included in the OpenThread SDK (which is based around FreeRTOS). There are some files that are included in the nrf_security delivery that's called "_zephyr.c" or "_freertos.c" which lets you use RTOS mutexes inside the library.

I am not sure which system you want to base on, but please note that there isn't really full mutex functionality in nRF5. What I mean by that is there are no mutexes that can do "priority inheritance". Typical things that are called into CryptoCell from another higher priority will block lower priority behavior.

In zephyr and in FreeRTOS we have support for mutexes that lets you change the priority. That means that if you have set a mutex as low priority and something with high priority tries to run operations on the same mutex, then the one with low priority will get up-prioritized to finish so that the mutex with higher priority can finish "afterward".

The only way to get around the issue in the nRF5-scope is to run all crypto in the same priority or to never collide a library of CryptoCell from NCS ('nrf_cc310_platform' and 'nrf_cc310_mbedcrypto') run without functions to initialize RTOS-mutexes which behave the same way as the 'nrf_cc310 library' (from old nRF5 SDK). That means that it takes a mutex with load-store exclusive, which only works on the same priority.