Are there possible concurrency issues with the CC310 when having SD (s140) enabled and using CC310 in Application

[M. David.]

Dear DevZonees

I'd like to reach some more clarity and confidence in using the hardware accelerated cryptography (CC310) while the SD is enabled.

• sdk_config - here are some of the configurations I made in the sdk_config. CC310 is the only crypto backend which is enabled.
  
  • enable LESC
  • enable NRF_CRYPTO_ENABLED
  • enable NRF_CRYPTO_BACKEND_CC310_ENABLED
  • enable NRF_CRYPTO_BACKEND_CC310_ECC_SECP256R1_ENABLED
• I've linked the appropriate libnrf_cc310 library

1. As of my understanding, this makes the SD using the CC310 for crypto related operations during pairing and data-exchange over a LESC connection, is this correct?

2. Concurrency

 2.1. Triggering crypto operations using the CC310 from the application, could this lead to concurrency issues when the SD accesses the CC at the same time? If yes, is there a way to avoid this?

  2.1.1. If there are concurrency issues, does the NRF_SDH_DISPATCH_MODEL configured in the sdk_config have any impact on this? As I understand the dispatch model only configures how the events are communicated from the SD to the application, but has no impact on how the SD is ran.

  2.1.2. If there are concurrency issues, does it make any difference between using the linked libnrf_cc310 library with or without interrupt (NRF_CRYPTO_BACKEND_CC310_BL_INTERRUPTS_ENABLED configuration in the sdk_config)?

 2.2. I've seen there are those cc310_backend_mutex APIs, does this mutex only help in accessing the CC from different places within the application or also between application and SD?

Br

david

[Sigurd]

Hi,

1. As of my understanding, this makes the SD using the CC310 for crypto related operations during pairing and data-exchange over a LESC connection, is this correct?

Well, not directly. Here is the list over HW peripherals that the SoftDevice uses.

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/sd_resource_reqs/hw_block_interrupt_vector.html

The computing of the LESC/DH key is done by the Peer Manager, that uses nrf_crypto library, and will for nRF52840 use(if enabled) use the CC310 as the backend for nrf_crypto.

It's typically done in the idle state(main loop) like this:

/**@brief Function for handling the idle state (main loop).
 *
 * @details If there is no pending log operation, then sleep until next the next event occurs.
 */
static void idle_state_handle(void)
{
    ret_code_t err_code;

    err_code = nrf_ble_lesc_request_handler();
    APP_ERROR_CHECK(err_code);

    if (NRF_LOG_PROCESS() == false)
    {
        nrf_pwr_mgmt_run();
    }
}

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_crypto.html

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_pm_architecture.html?cp=9_1_3_2_7_0

2. Concurrency

I don't see any issues with concurrency. As you mentioned, the different backends already implements and use mutexes.

[M. David.]

Hi Sigurd

Thank you for the clarification. This is good news, I was worried how to solve this, but it turns out to be no issue.

However what about the encryption/decryption of the data transferred over a BLE LESC connection? Is this also done on the Application level and not in the SD itself? And by which mechanism, because the nrf_ble_lesc_request_handler only provides the key if requested by the SD.

[Sigurd]

Hi,

M. David. said:

However what about the encryption/decryption of the data transferred over a BLE LESC connection?

This is done by other peripherals, like the CCM. https://infocenter.nordicsemi.com/topic/ps_nrf52840/ccm.html?cp=5_0_0_5_3

M. David. said:

Is this also done on the Application level and not in the SD itself?

This is done in the SD.