nrf_crypto asynchronous operations

[Hiihtaja]

Hello !

If I understand right and nrf_crypto is the main Crypto API in nRF SDK. They can be mapped to cc310 or to mbedtls sw routines.

Does exists nrf_crypto asynchronous APIs ? At list for some algos. When I can schedule AES CCM/CTR ( for example ) and get callback when operation is completed.

I can see cc310 supports interrupt driven operation. But it is not so clear what kind of APIs can be used for async operations.

What can be start point if I need to implement AES 128 bit CCM/CTR for cc310 in async way ?

Please suggest shortest way.

Regards,

Eugene

[Jørgen Holmefjord]

Hi,

nrf_crypto does not provide asynchronous APIs. For all other backends than CC310 (mbedtls and nrf_oberon), the CPU is needed to do the cryptographic calculations, as they are SW backends. CC310 is only supported in nRF52840, so it would not make that much sense to add asynchronous APIs only for this. Also, there is currently no support for interrupt driven CC310 outside of the of the ARM runtime libraries, see this post.

If you want to do some work while the CC310 handles its calculations, you would need to do that in interrupt context. You can trigger interrupt using SWI — Software interrupts. It may also be possible to get something done using threading in an RTOS like FreeRTOS or Zephyr/NCS.

Best regards,
Jørgen

[Hiihtaja]

Hi !

Basically CC310 library is wait real interrupt internally. As result  AES-128 ( I need ECB, CTR and CCM only ) operations can't be executed in ISR context or thread mode when global and/or cc310 interrupts are disabled. Is this so ?

May be exists some version of library or some other set of APIs where completion of operation is done as polling operation ?

In this case encryption/decryption can be executed in any context.

Other alternative id find out how to use AES CCM/ECB co-processor. But it not supports CTR mode and also ECB encryption only.

Also SW implementation of AES take 2-3 times longer than HW ones.

Could it be possible to find information about CC310 what can help to implement AES APIs in asynchronous way or using wait loop instead of interrupts ?

In test /nRF5_SDK_17.1.0_ddde560/examples/crypto/nrf_cc310/aes/main.c

I can disable interrupts during AES tests

__disable_irq();

ret = aes_tests();

__enable_irq();

And they still passed.

Can be be there simple tight loop for wait complexion without real ISR ?

Please suggest.

Regards,

Eugene

[Hiihtaja]

Hi !

I have enable only cryptocell but not interrupts of it

//NVIC_EnableIRQ(CRYPTOCELL_IRQn);

NRF_CRYPTOCELL->ENABLE = 1;

And at list  CRYS_CHACHA can be executed in SWI interrupt event_handler what I allocated via driver.

nrfx_swi_alloc(&swin, event_handler, APP_IRQ_PRIORITY_LOWEST);

I hope we are lucky and only tight loop inside library and we can execute short operations inside any ISR.

But async APIs is more useful for sure.

Regards,

Eugene

[Jørgen Holmefjord]

I got confirmation that the nrf_cc310 runtime library does use interrupts, but not a lot. There is a no-interrupts version of the library in the SDK if you plan to use it from interrupt context. Note that we highly recommend only calling the functions from one priority (preferably main/thread). There is only one core in the CC310 Cryptocell, calling the functions from multiple interrupt context will likely cause issues. In nrf_crypto, we have protected the CC310 with mutexes, along with other measures, to prevent issues like this.

[Hiihtaja]

Hi !

Yes one call at the time.

Do I understand right and highlighted lib is the one what I should use with noint and gcc ?

But what is short-wchar versions are ?

Regards,

Eugene

[Jørgen Holmefjord]

Hiihtaja said:

Do I understand right and highlighted lib is the one what I should use with noint and gcc ?

Yes, that's correct.

Hiihtaja said:

But what is short-wchar versions are ?

Those are for IAR v7, see the SDK release notes:

Libraries for IAR 8 require wchar_t to be of size 32 bits while IAR 7 requires 16 bits.
  
To run a project using IAR 8, follow these instructions:
 1. Open the IAR project in IAR 8. The IAR workbench will automatically generate an IAR 8 compatible project file.
 2. If the project contains one of the precompiled libraries listed below, replace it
    with the IAR 8 compatible alternative (there are no projects targeting nRF51 in this SDK).
 3. Save the project.
 4. When building the project, you might get the warning: "The header file 'cmsis_iar.h' is obsolete and should not be used. [...]".
    - The problem is described in DevZone post: devzone.nordicsemi.com/.../iar-ewarm-8-22-1-complains-about-cmsis_iar-h
      The solution is to remove all occurrences of #include <cmsis_iar.h>.
     
The affected libraries are:
 - micro-ecc crypto:
    - IAR7: Includes library located in the folder named “…_iar\…”.
    - IAR8: Switch to using the library from the folder named “…_armgcc\…”.
 - nrf_cc310, nrf_cc310_bl, and nrf_oberon:
    - IAR7: Link to a library where “short_wchar” is part of the folder name.
    - IAR8: Link to a library without “short_wchar” in the folder name.
 - Gazell, NFC Tag, and 802.15.4:
    - IAR7: Includes the library where the file name ends with “_iar”.
    - IAR8: Switch to using the library with similar file name that ends with “_gcc”.