This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: Encryption for OTA data when using Just Works Pairing mode

Part Number: CC2640R2F

Simplelink Academy 1.50

TI-RTOS

CCS ver 8.0.0

For our project we use a central and peripheral. We are sending raw data using a custom characteristic using GATTServApp_ProcessCharCfg. We are sending data as notifications.

On the central we read the incoming notifications in the processGATTMsg() : (pMsg->method == ATT_HANDLE_VALUE_NOTI)

We are able to successfully read all notifications being sent. 

We are implementing Just Works pairing mode since we do not have any IO capabilities. 

We use the following pairing parameters.

PERIPHERAL:

       uint32_t passkey = 0; // passkey "000000"

       uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;

       uint8_t mitm = TRUE;

       uint8_t ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;

       uint8_t bonding = TRUE;

 

CENTRAL:

        uint8_t pairMode = DEFAULT_PAIRING_MODE;

        uint8_t mitm = DEFAULT_MITM_MODE;

        uint8_t ioCap = DEFAULT_IO_CAPABILITIES;

        uint8_t bonding = DEFAULT_BONDING_MODE;

We would like to add Link Layer encryption for the data being sent over the air. I came across a few posts and noticed that all that's required for enabling encryption is to modify the permissions for characteristic value to GATT_PERMIT_ENCRYPT_READ. I have made that change and also added the following :

 uint8_t secureConn = GAPBOND_SECURE_CONNECTION_ALLOW;

No changes made on the central side. 

However, i am still not able to encrypt the link. I send known data values from the peripheral and using a BLE sniffer, I am able to read the raw data values. 

Is there anything i'm missing for enabling the encryption? Any help is appreciated.

Thank you,

Nikhil

  • Hi Nikhil,

    I have assigned an expert to comment on this. In the meantime, I believe you may find the BLE Security Fundamentals lab useful. There is a section that covers how to encrypt characteristics as well as other security features that I believe you may find useful. I see that you are using the 1.50 SDK, is it possible to migrate to the latest SDK? The 1.50 SDK was released several years ago and many features and bug fixes have been included throughout all of the releases since 1.50.

    Best Regards,

    Jan

  • Hi Jan,

    I followed the instructions in the BLE security Lab and tried enabling the encryption. I am still able to see the raw data values in the sniffer.

    I am using the nRF Sniffer for BLE. When I start capturing packets from the Peripheral before the connection takes place, I can see the raw data even on enabling encryption. If I start capturing the packets after the connection was established, I don't see any traffic irrespective of whether encryption is enabled/ disabled. Does that mean the data is already encrypted?

    In that case my question is- what would be the best way to confirm that the data is being encrypted or not?

    Thanks,

    Nikhil

  • Also, regarding the 1.5 SDK, We are in the process of upgrading the SDK. However, there was an immediate requirement for encryption and so we would have to stick to 1.5 version for this issue. But, yes we are eventually planning to upgrade to the latest SDK.  

  • Nikhil,

    I am not very familiar with the nRF sniffer for BLE, but the fact you see packets from the peripheral before a connection may simply indicate it is advertising itself to other hosts in the channels 37, 38 and 39. After a bonded connection takes place, a full featured sniffer (Ellisys, Frontier) will explicitly mention the packets consist of Encrypted Data but your sniffer may simply ignore the encrypted data.

    Depending on your packet sniffer, you can enable the Encryption keys (via the #define SC_HOST_DEBUG) and decode the encrypted data normally on a sniffer. Keep in mind this does not work well in all sniffers and/or hosts. Additional details at:

    https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_5_10_00_02/docs/blestack/ble_user_guide/html/ble-stack-3.x/gapbondmngr.html?highlight=sc_host_debug#gap-bond-manager-and-le-secure-connections

    Hope this helps,

    Rafael

  • Hi Rafael,

    Thanks for your reply. I am concerned whether the packets are being encrypted at all. I noticed that when my Central tries to establish connection with peripheral, the peripheral does not send a LL_ENC_REQ to the central(from sniffer log).

    I tried running a simple peripheral on the dev kit and connecting it using LightBlue on my phone, and i could see the LL_ENC_REQ go over the air. Is there anything that triggers the LL_ENC_REQ from the peripheral side? 

    Let me know if you have any suggestions for me to try out.

    Thanks,

    Nikhil

  • Nikhil,

    Please apologize for the delay; are you still having this issue?

    The LL_ENC_REQ is sent immediately after a successful bond between the two devices - either by exchange of a passkey or in "Just Works" method (what you are using).

    However, I was searching around and found out the following e2e post which describes an option that may be getting in the way of a proper encryption connection update. Can you check to see if that may help you?

    https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/592890/cc2640r2f-pairing-problem-with-android-samsung-s7-edge

    I will try to find additional scenarios and report back in case I find anything relevant.

    Regards,

    Rafael