Crypto fronted doesn't work with Softdevice in SDK17

[Viktor Venczel]

Dear Devzone!

I am trying to add AES-128 decryption support for secure DFU with cc310_bl backend. However when I call nrf_crypto_aes_update it never returns. Examining the call stack it is waiting in SaSi_HalWaitInterrupt function forever. Looking at the code I assume the CRYPTOCELL_IRQHandler is never called. The same code works with SDK 15.3.0 though. 

I tried the nrf_crypto/aes/aes_cbc_with_padding example code, it works well, but if I add the same code to the secure_bootloader project I am able to reproduce the issue.

Could be the softdevice does not forward this interrupt to the application? 

[Jørgen Holmefjord]

Hi,

The cc310_bl backend is a minimal backend for use in the bootloader. This backend only implements support for the algorithms used by the bootloader (secp224r1/secp256r1 ECC and SHA-256 hash) to keep the flash footprint of the bootloader as small as possible. If you want to use AES through the CC310 Cryptocell you need to replace the cc310_bl backend with the standard cc310 backend in the bootloader. Note that the full CC310 backend will consume significantly more flash, so you might want to consider using AES through one of the SW backends if this will only be used for DFU. SW backends will use more time, resulting in a bit higher current consumption, but this is something you need to consider/decide based on your application requirements.

Best regards,
Jørgen

[Marcin Zapolski]

Hi,

I know it is an old thread, but I have encountered this exact same issue. On SDK 15.2.0 AES-128 worked just fine when using cc310_bl backend. After migrating to SDK 17.1.0 it freezes on SaSi_HalWaitInterrupt.

I managed to solve it just by surrounding the aes function calls by cc310_bl_backend_enable/disable.

What bothers me though is why the libnrf_cc310_bl binary contains the aes code, but does not advertise it in the headers (I had to use "cc310_backend_aes.h")? Using the headers from cc310 backend is a hack that I don't feel comfortable with. But it works and I don't have to link against a much larger library.

Why are the AES functions not exposed through cc310_bl_backend_aes.c/h even though the library contains them?