• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 54 subscribers
  • Views 1676 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R: How do I reject debug keys when using LE secure connections?

Keron
Intellectual 390 points
Part Number: CC2642R

Hello,

We are developing on the CC2642R chip using SDK 3.40.00.02 and IAR 8.32.2. We would like to use LE secure connections when connecting to other devices. Starting off with the example code of the simple_peripheral project, we have enabled secure connections and disabled the use of secure connection debug keys:

uint8_t secureConnection = GAPBOND_SECURE_CONNECTION_ONLY;
uint8_t eccDebugKeys = false;

// Set Secure Connection Usage during Pairing
GAPBondMgr_SetParameter(GAPBOND_SECURE_CONNECTION, sizeof(uint8_t), &secureConnection);

// Set Secure Connection Debug Keys
GAPBondMgr_SetParameter(GAPBOND_SC_HOST_DEBUG, sizeof(uint8_t), &eccDebugKeys);

However, when using these settings I noticed that if the connecting party is using secure connection debug keys, the entire connection uses those keys and my BLE sniffer is able to sniff the connection. The Core spec says “if a device receives this debug public key and it is in a mode in which it cannot accept the debug key then it may send the Pairing Failed command with the reason set to ‘Invalid Parameters’.” So it seems that the core spec leaves this up to the implementation to decide. How do I reject the use of secure connection debug keys in code?

Thanks,

Keron

  • 0
    TI__Expert 5345 points

    Keron,

    Thanks for the details. I've assigned an expert to help you.

    -Luis

  • 0 in reply to Luis M
    Intellectual 390 points

    Hello,

    Are there any updates on this issue?

    Thanks,

    Keron

  • 0 in reply to Keron
    TI__Genius 14845 points

    Hi Keron,

    Thanks for your patience and apologies for the delay. 

    Can you provide the sniffer logs you have of this issue?

    Thanks, 
    Elin 

  • 0 in reply to Elin W
    Intellectual 390 points

    Hi Elin,

    We use an Ellisys Bluetooth Tracker. Can I send the logs to you privately? It seems I'm not able to send you a private message. I also have included a screenshot of a portion of the sniffer log. You can see that the master wants to use debug keys but the slave is using a regular key, yet the sniffer is still able to sniff the connection. Please advise.

    Thanks,

    Keron

  • 0 in reply to Keron
    TI__Genius 14845 points

    Hi Keron, 

    You can attach the log here in the thread. If that is not possible, you can send them to me over a private message. 

    Thanks, 
    Elin

  • 0 in reply to Elin W
    TI__Mastermind 39960 points

    Hi Keron,

    When either the initiating or non-initiating device uses this specific debug key, it enables over-the-air sniffer equipment that supports LE Secure Connections to determine the LTK and therefore monitor/decrypt encrypted traffic throughout the connection. As far as being able to actually reject an attempt by a device using debug keys, allow me to look into this for you. 

  • 0 in reply to Evan W
    TI__Mastermind 39960 points

    Keron,

    Quick question, i am having a tough time locating this quote in the spec. Could you please inform me of the Section you are referring to so that i can read myself?

    Keron said:
    The Core spec says “if a device receives this debug public key and it is in a mode in which it cannot accept the debug key then it may send the Pairing Failed command with the reason set to ‘Invalid Parameters’.”

  • 0 in reply to Evan W
    Intellectual 390 points

    Hi Evan,

    Thanks for looking into this. That quote comes from Vol 3, Part H, section 2.3.5.6.1 of the BLE 5.2 Core spec (p. 1647). It's in the paragraph immediately after where the standard keys for debug mode are specified. My concern is that this could be a security issue. If our device is specifying that debug keys are not to be used, but the peer can still connect using debug keys, this seems to override BLE LE security. So we'd like to have a way to reject the use of debug keys in case the peer tries to use them.

    Thanks,

    Keron 

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Hey Keron,

    Keron said:
    So we'd like to have a way to reject the use of debug keys in case the peer tries to use them.

    While I look into this, the first thing that comes to mind is adding an additional level of security at the application layer. This way, even if debug keys are used by a malicious device to sniff the traffic, the data is still protected.

    Note, that you still have additional methods of authentication, as you are likely aware. i.e. to enter a passcode and authenticate (after the public keys are shared).

    For reference: https://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_4_20_01_04/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr-cc13x2_26x2.html#gap-bond-manager-and-le-secure-connections 

  • 0 in reply to Ammar N
    Intellectual 390 points

    Hi Ammar,

    Thanks for your reply and your suggestion. Indeed, we have already implemented a two-layer security approach. We are relying upon the native BLE stack-level security to establish an encrypted connection, and then once pairing is complete, we have an application-level pairing handshake, which relies on certificates for authentication. On the BLE stack level, we can not use passkey entry or numeric comparison, because our device does not have any input or output (i.e. no buttons, screens, LEDS, etc.), so we authenticate at the application layer. Still, our two-layer security approach degenerates into a single layer if we can not rely upon secure BLE stack security, so we'd like to find a way to reject those debug keys. Please advise.

    Thanks,

    Keron

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Hey Keron,

    It looks like the clarification you quoted above was made in v5.2 spec. Currently, the CC26x2's BLE stack is rated for v5.1. I'm not sure we have a solution to reject the debug keys at this time, but I will follow up with any workarounds (if there are any) for now.

    We are currently working on the next v5.2 stack but I cannot publicly comment on the future road map on this forum.

  • 0 in reply to Ammar N
    Intellectual 390 points

    Thanks Ammar. I just took a look at v5.1 of the spec and I see what you mean. It says "Only one side (initiator or responder) needs to set Secure Connections debug mode in order for debug equipment to be able to determine the LTK and, therefore, be able to monitor the encrypted connection." That explains the behavior I'm seeing. Thanks for looking into this.

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Good to hear we're on the same page!

  • 0 in reply to Ammar N
    Intellectual 390 points

    Hi Ammar,

    We look forward to hearing any proposed workarounds from you. Our team was thinking of one potential solution: find a way to manually check which LTK is being used by the BLE stack, and if it matches the debug keys defined in the BLE core spec, we will reject the pairing. Is this a viable solution? If so, how exactly can we access the LTK being used for a given bond?

    Thanks,

    Keron

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Hey Keron,

    This seems to be the best path forward. Currently, we don't have any method of retrieving the LTK via an API. It is stored in NV memory and is accessible, so this is possible. Let me look into this further.

    A colleague of mine has a similar related thread here if you want a head start on finding the LTK: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/941350/3481370#3481370 . Note: he's working with a CC2640R2 project, so we may have to link in certain files from the SDK into your project to debug those functions.

  • 0 in reply to Ammar N
    TI__Mastermind 25810 points

    Hey Keron,

    You can access the LTK (and other security parameters) by pulling in gapbondmgr.c to your project. It is located here: 

    C:\ti\simplelink_cc13x2_26x2_sdk_3_40_00_02\source\ti\ble5stack\host

     for those with the default install directory.

    Then, you can navigate to GAP_AUTHENTICATION_COMPLETE_EVENT: inside GAPBondMgr_ProcessGAPMsg() and inspect the security parameters most recently used to form the connection. If the key used does not satisfy your requirements, you can trigger a disconnection. Note, this retro active approach only works after the pair/bond has been established.

    I hope this helps resolve the issue.

    EDIT: The LTK is located in the pPkt data struct, i.e. pPkt->pDecSecInfo[0]

  • 0 in reply to Ammar N
    Intellectual 390 points

    Thanks Ammar. This seems quite feasible and we will use this solution.

    Regards,

    Keron

  • 0 in reply to Keron
    Intellectual 390 points

    Hi Ammar,

    After taking some time to try to implement this solution I came to the realization that using the approach where I check the LTK to see if debug keys are in use won't quite work. I had originally assumed that when one party uses debug mode, the LTK used for the connection would be the same for all connections, but this is not necessarily the case. The issue is that if the peer wants to use debug keys, the LTK will be formed using the peer's default public debug key (defined in the BLE Core spec) and my device's own private key. Since my device is not set up to use debug keys by default, it will not necessarily be using the default private debug key defined in the BLE Core spec and so the LTK is not predictable.

    What I actually need is a way to check if the peer is using the default public debug key defined in Vol 3, Part H, section 2.3.5.6.1 of the BLE Core spec. That would immediately let me know that the pairing should be rejected. Alternatively, if I had a way to retrieve my own device's private key, I could combine it with the default public debug key in an ECDH operation and see if the result is equal to the LTK I see in the GAP_AUTHENTICATION_COMPLETE_EVENT case of GAPBondMgr_ProcessGAPMsg(). If the results are equal, that would also indicate that debug keys are in use.

    So to summarize, my questions are:

    • Is there a way I can retrieve the peer's public key in use at pairing time?
    • Is there a way I can retrieve my own device's private key in use at pairing time?

    Thanks,

    Keron

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Hey Keron,

    I apologize for the delay. As I understand, there isn't a way to retrieve the keys at pairing time, as that's handled inside the stack. If there is a way, it would be exposed in gapbondmgr.c. I encourage you to to take a look at that file to familiarize yourself. Inside GAP_DEVICE_INIT_DONE_EVENT, you may be able to view the keys there or read them from NV.

    Revisiting the application level security, is it not sufficient to create a unique characteristic storing a unique value that only your devices would know? You can then have a handshake between devices to confirm identity and terminate if you receive an unknown response.

  • 0 in reply to Ammar N
    Intellectual 390 points

    Hi Ammar,

    I've taken a look in gapbondmgr.c and it seems that none of the public key information that gets exchanged over the air at pairing time is exposed to any of the data in gapbondmgr.c. So currently I have no way of accessing the public key that a peer used at pairing time. Also, my device's own private key is not written to NV (only RAM). It gets generated at pairing time by the stack (I'm assuming at the controller level), so I can't access it either.

    For application level security, we have a certificate-based strategy that handles authentication for us. We just want to make sure that our two-layer security approach (i.e. BLE stack-level security and app-level security) doesn't degenerate into a single layer if we can not ensure that the BLE stack-level security is  resistant to eavesdropping with a sniffer. Since there is no current solution to this issue using the BLE 5.1 stack, we'd like to propose that the ability to reject debug keys be added into the next version of the SDK that supports BLE 5.2. Can you please confirm this will be supported?

    Thanks,

    Keron 

  • 0 in reply to Keron
    TI__Mastermind 25810 points

    Hey Keron,

    I've filed a ticket with our SW team on this. It will be addressed in a future SDK release, but I cannot confirm exactly when this will happen, unfortunately.

    I'm working internally to expedite this as best I can.

  • 0 in reply to Ammar N
    Intellectual 390 points

    Thanks Ammar for looking into this.

    Keron