CC2745R10-Q1: PSA Key Storage During BLE Connection

Hello Kento, 

Can you try this with the psa_import_key() function? The Keystore functions are wrappers around the ARM PSA functionality. We recommend using the psa functions for the CC27xx. If you are using any other Keystore functions, please switch them out with the proper psa functions which you can find here. The psa functions can be found in the crypto.h header file. Try this and let me know if this helps.

Additionally, are you executing the crypto functions within a different thread?

Let me know. 

Thanks,
Isaac  

Hello Isaac,

Keystore_psa_importkey() exists within the processing of psa_import_key(). Could this mutual exclusion control cause the BLE connection to disconnect?

Hello Kento, 

Yes, I am aware that psa_import_key function is within the processing of Keystore_psa_importkey(). Please replace the Keystore functions with the correct psa functions to see if that fixes the problem first. The Keystore functions should not be used on CC27xx, you should opt for the psa functions instead. 

Thanks,
Isaac

Hello Isaac,

I used psa_import_key(), but obtained the same result as when using Keystore_psa_importkey().
Similar to when using Keystore_psa_importkey(), the BLE connection was disconnected while accessing the PSA keystore.
Is it impossible to maintain a BLE connection while accessing the PSA keystore?
Is it possible to store keys in the PSA keystore without using the mutual exclusion control within the psa_import_key() processing?

Thanks

Kento, 

I am looking into this further. Please expect a response on Friday (01/30). 

Thanks,
Isaac

Hello,

I hope things turn out well.

Hello, Isaac

Have you been able to confirm this feature?
I was expecting a response by January 30th, but since I haven't received one yet, please confirm.

Hello Kento, 

I am not sure why you are seeing this when calling psa_import_key. The psa_import_key function does not use a mutual exclusion. Are you using a different thread for your crypto functionality? What are the time constraints for calling this function? 

Please explain your configuration a bit more. 

Thanks,

Isaac

Hello Isaac,

There are no time constraints on calls to psa_import_key().
This function and the BLE stack share the same resources.
Is there any other information you require?

Thanks.

By acquiring the semaphore with psa_import_key(), the BLE task halts, and communication scheduling becomes misaligned, leading to the complete stoppage of the BLE task.

Hello, Isaac,

When using the cc2745 as the target board and executing `psa_import_key()`, does the BLE stack halt because the semaphore is acquired by `SemaphoreP_pend()` inside `psa_import_key()`?
Also, would using a different resource prevent this issue?
Additionally, is there a way to store the key in the PSA without acquiring the semaphore?

Hello Kento, 

I apologize for the delay. I have not been able to look into the problem further. I will provide a response by Friday next week (02/20). 

Thanks,

Isaac

Hello Kento, 

Can you provide to me the attributes you are passing into the psa_import_key function? Additionally, can you provide your connection parameters? I talked to our R&D expert on the psa functions, he mentioned depending on the attributes, the time taken for execute the function is between microseconds to 1ms. This should not affect your connection unless you are calling the function directly before a connection event. 

Also, do you see the disconnection every time you run the psa_import_key function or is the disconnection intermittent? 

Let me know. 

Thanks,

Isaac

Hello Kento, 

Additionally, are you invoking the psa_import_key function call? If both the BLE stack and psa_import_key function share the same stack/thread, then I would expect you to use BLEAppUtil_invokeFunction to call the psa_import_key function. Invoking the function would allow the execution of the function to be added to the BLE stack queue. This would prevent any overlap between BLE events and the psa_import_key execution. 

Please try this if you do not have this implemented already. 

Thanks,

Isaac

Hello Isaac,

>Can you provide to me the attributes you are passing into the psa_import_key function?
The attributes passed to the psa_import_key function include Key_Type as KEYSTORE_PSA_KEY_TYPE_AES, Key_Bytes as 16, LifeTime as persistent key and local storage, Key_Usage as KEYSTORE_PSA_KEY_USAGE_SIGN_MESSAGE, and Key_Algorithm as KEYSTORE_PSA_ALG_CMAC.

>the time taken for execute the function is between microseconds to 1ms.
When saving the key for the above attribute, it takes about 10 milliseconds. Why is that?

>Additionally, can you provide your connection parameters?
Could you please tell me specifically what the connection parameters refer to?

>Also, do you see the disconnection every time you run the psa_import_key function or is the disconnection intermittent?
This issue does not occur every time, but rather intermittently. It happens when a connection event is executed while the psa_import_key function is being called.

Thanks.

Hello Kento, 

The connection parameters refer to the connection interval, connection latency, and supervision timeout. There are more parameters related to the connection parameters, but those are the variables that I need. 

Ok, the last point is interesting. Please try invoking the psa_import_key function by using the BLEAppUtil_invokeFunction API. This will schedule the psa_import_key function, so it does not interfere with BLE related events. 

Thanks,
Isaac

Hello Isaac,

Hello, 

1. Yes, BLEAppUtil_invokeFunction will add the function execution to the current queue, this makes sure the function is not being executed when an BLE event is supposed to occur. 

2. This is basically what BLEAppUtil_invokeFunction is doing. It is enqueuing an event related to the function you are attempting to execute. 

Thanks,

Isaac

Hello Isaac,

Thank you for your response.
We understand that by queuing function execution in the BLEAppUtil task, it is possible to prevent the function from being executed at a timing when BLE events are supposed to occur.

However, we are not integrating the BLEAppUtil task in our system.
Instead, we generate an event from Task A to Task B, and perform PSA key storage at the timing when Task B receives the event.
We believe that this achieves behavior equivalent to queuing function execution in the BLEAppUtil task, as you described.
Is this understanding correct?
If not, we would appreciate it if you could clarify what the differences are.

In addition, if our understanding is correct, in our environment we are experiencing an issue where advertising transmission overlaps with the timing at which key storage into PSA is performed in Task B, resulting in advertising not being transmitted.
We do not understand why this issue would be resolved by using the BLEAppUtil_invokeFunction function.
We would appreciate it if you could explain the reason why this approach is effective.

Thanks.

Hello, 

Can you send me your code for the BLEAppUtil event queue you are using? If the queue is interrupting BLE task functionality, then I would assume its not working the way you expect. Can you please try using BLEAppUtil_invokeFunction as a test? 

Thanks,
Isaac

Hello Isaac,

In the User Application, event queue processing is implemented using the following FreeRTOS functions.
・vListInsertEnd
・xEventGroupSetBitsFromISR
・xEventGroupWaitBits

[Procedure]
1. Task B invokes the vListInsertEnd function and enqueues a message into the queue handle list of Task C.
2. At the end of Task B, Task B executes xEventGroupSetBitsFromISR to notify Task C of the event.
3. Task C waits for an event notification by executing the xEventGroupWaitBits function, and upon receiving the event,
dequeues a message from the queue handle list.
4. Task C performs the appropriate processing based on the content of the message dequeued in Step 3.

Note:
I have interpreted your question as being about the event queue mechanism of UserApp, and have shared the above information accordingly.
Please let me know if this does not align with your question or intent.

The timing chart illustrates the current issue together with the procedures described in Steps 1 through 4 above.
In UserApp, processing is performed according to the flow shown in the attached diagram.

When the timing of PSA key storage coincides with the reception of empty packets for the Connection Interval, a contention occurs,
resulting in an interruption of the Connection Interval and the subsequent occurrence of a Supervision Timeout.

Note:
The numbers 1 through 4 shown in the figure below correspond to the procedure steps.

[Timing Chart]

Thanks.

Hello, 

Thank you for the explanation. Can you try using BLEAppUtil_invokeFunction and see if you still see the problem? 

Also, what is your connection interval? The import key function does not take long enough to block a connection interval unless the function is called right before the connection event. Again, I ask for you to try executing this function using BLEAppUtil_invokeFunction. Please 

Thanks,
Isaac

Hello Isaac,

Thank you for your response.

As we mentioned last week, we have implemented PSA key storage by enqueueing events in the UserApp.
Our understanding is that this approach achieves the same behavior as using BLEAppUtil_invokeFunction.

Could you please tell us what differences, if any, would result from using BLEAppUtil_invokeFunction, and why it is considered to be an effective approach?

Thanks.