Mutex needed for mbedtls APIs using Cryptocell backend on Zephyr?

[Barry]

I am running a Zephyr OS, and I am using the mbedtls APIs to do my cryptographic operations using the Cryptocell as my backend. My question is should I be using a mutex of some sort around mbedtls API calls, or is that being done at a lower level. I am wondering if it is possible that a different thread that also uses the cryptocell could try to access it at the same time and cause an issue.

So for example on this set of functions should I implement a mutex to protect the Cryptocell from other threads doing similar function calls, or is that being handled for me. I can't see the source below this level, its just your library.

mbedtls_aes_context aes;
mbedtls_aes_init(&aes);
mbedtls_aes_setkey_enc(&aes, key, DB_KEY_SIZE * 8); // key size in bits
mbedtls_aes_crypt_ctr(&aes, crypt_size, &nc_off, iv, stream_block, input, output);
mbedtls_aes_free(&aes);

[Carl Richard]

Hello!

The mbedTLS APIs of the CryptoCell backend basically follow the same pattern as the original mbedTLS. When an mbedTLS function is thread safe in the software implementation then it is also thread safe when you are using CryptoCell. I am saying that because not all the mbedTLS functions are thread safe. For the AES that the you are looking for you should be fine without a mutex since it is thread safe.

Best regards,
Carl Richard

[Barry]

Thank you for that information. As a follow up. Are the mbedTLS API that we are using with the Cryptocell also safe with any Cryptocell use the BLE stack is doing. So like I see bluetooth uses sdc_soc_ecb_block_encrypt. That function uses the Cryptocell also right. So if the BLE thread gets control while another thread was in the middle of a thread safe mbedTLS API operation. Could there be an issue?

[Carl Richard]

Hello again!

The BLE stack doesn't use Cryptocell. It uses the AES CCM and AES ECB peripherals which are entirely independent.

Best regards,
Carl Richard