• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 2468 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BLE Security

Ansgar Strother
Intellectual 435 points
Other Parts Discussed in Thread: CC2541

Hello,

I'm working with the cc2541 to create a lock that can be controlled via an Android or iOS app. I've been reading through the forums and it seems like that I want to use Out-of-Band (OOB) pairing and encrypt the communication. It seems that using this method the user would not have to interact with the hardware but only authorized users would be able to connect in a hostile environment. Do I have this right?

If so are their any example that anyone could point me to on the firmware and app side? 

Thank you!

Ansgar

  • 0
    TI__Guru** 105180 points
    Hi Ansgar,

    You are correct in that OOB pairing is the most secure, if implemented securely in that if you don't compromise the key. We don't have any examples of OOB pairing as key exchange is heavily implementation specific, but the BLE Stack does have an API to supply the key to the stack: GAPBondMgr_SetParameter().

    Once you are paired/bonded to an authorized smartphone, you can require authentication before any data is accessed. This will ensure that only an authorized device is connected. In terms of a good reference project for understanding BLE security, I would take a look at the HIDEmuKbd project.

    Best wishes
  • 0 in reply to JXS
    Intellectual 435 points
    Thank you for your quick response.

    OOB after further reading I realize that I may have misunderstood OOB. To confirm OOB keys are sent via NFC, cellular network ect, not BLE.

    If I can't use OOB what is the best way to secure the device, as I've read that with sniffing that passkey isn't secure. Is that just the best one can do or are there other options?

    Thank you!
  • 0 in reply to Ansgar Strother
    TI__Guru** 105180 points
    Hi,

    Yes, when OOB is used, the keys must be supplied to both devices via another means besides BLE pairing. This can be from NFC or Cellular, which you mention, or via any other medium, including pre-programmed or serial link. Some implementations have developed their own key exchange protocol (e.g. Diffie-Hellman) to securely exchange the keys over an unsecure BLE link. This exchange occurs at the application layer, though. In BT4.2, this will be integrated into the BLE controller.

    If BLE pairing (Passkey or JustWorks) is the only option, then I would suggest reducing the tx power to absolute minimum needed to complete the pairing procedure. This doesn't enhance security, just makes it marginally more difficult to intercept the keys.

    Best wishes
  • 0 in reply to JXS
    Genius 4470 points

    Apart from GAP_BondManager, you can think of using AES encryption of data before sending it over BLE to prevent it from sniffing attack.

  • 0 in reply to Dhaval V
    Intellectual 435 points
    Good idea, after looking into it some more Android doesn't support OOB so this looks like the best solution.

    Based on that I'm planning on having the server give the app an AES encrypted password with message number (to prevent replay attacks). The app can then send this over to the ble lock and assuming the message count is higher and the password matches the hardcoded value the lock will be released.

    Assuming that the AES key is kept secret will this be secure?

    Thank you for all of your help.
  • 0 in reply to Ansgar Strother
    Genius 4470 points

    Yes, you can store the AES encryption key in your code and you can program CC254x with Debug Lock enabled. Also, you need to think of how to store the AES encryption key on central device.