• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 854 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.

Original question:

CC2650MODA: BLE 4.2 Security on Dual MCU Solution (MSP432+CC2650MODA)

CC2640R2F: Advice on Utilizing SNP Security Features for Device Provisioning

Pranata
Intellectual 480 points
Part Number: CC2640R2F

Hello,

I have questions on implementing the security on my BLE application which uses CC2640R2 as SNP.

My use case requires a single BLE device to be controlled by multiple devices (mobile app). This is achieved by implementing security on application layer (on top of GATT value) which uses 256-bits symmetric key.
Here is my previous thread question & other reference that relates to this use case:
https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/613046/2257490#2257490
https://devzone.nordicsemi.com/b/blog/posts/intro-to-application-level-security-using-the-ecb-

As I develop my application, the problem that I found is on provisioning the key when setup the BLE device before it can be used. I decide to let the SNP generate the key by using its RNG. This key should be retrieved by mobile app and be synchronized to cloud because this key will be distributed to other mobile app that is authenticated to the cloud and have privilege to control the BLE device.

To retrieve the key means the mobile app should be paired to BLE device and I am still finding a way to secure this connection. My questions are:

  1. Is it enough if I only use Just Works mechanism?
  2. How I can enable the BLE provided pairing method with encryption (Just Works) on SNP API? Pardon me as I do not see the example from Simplelink BLE SDK plugin that demonstrates how to use the SNP Set Security or SNP Send Security Request.
  3. Assume that I use Just Works, I plan to implement a command such as test command that would blink the LED on BLE device. This command is triggered by user consent (via button) on mobile app.
    Does it provide a better security since adversary needs to physically present and observe the user who configure the device?
  4. Other thing that I can think of is to generate a setup key (256-bits) on device production and encode it in QR code on a sticker or a card. Each device would have unique setup key and mobile app should scan the QR code first before it can communicate securely. This setup key is different than generated key because it is fixed and will never be changed, that is why I limit the usage for setup only and let the user keep the QR code whenever they factory reset the device and needs to setup again. However I think this is quite complicated on the production line so I do not make it a priority.

Thank you for your attention

Kind regards,
Pranata

  • 0
    TI__Mastermind 23440 points
    Hi Pranata,

    If you are using BLE 4.2 Secure Connections, then "JustWorks" should be secure. Otherwise it's not secure at all with the legacy pairing. You still don't really know who you have connected to because the BLE pairing doesn't include authentication.

    If you have a look at dev.ti.com/.../ you will see the 9.3.8 SNP Set Security Parameter chapter. If you set the IO capabilies to no input / no output it will be Just Works. I don't think that SNP supports LE4.2 Secure Connections however.

    Blinking a LED, or better yet, requiring a button press to enable pairing, increases security. But as mentioned, LE Legacy pairing is not secure if somebody is sniffing the initial exchange. Since you don't bond here, all pairings are that initial exchange. After the initial connection however it is secure, because then the BLE security uses an exchanged symmetric key.

    I don't really think it's worth it to involve link layer security here at all. Especially as not all phones support secure connections in any case.

    I'd suggest one of

    1) As you say, append a completely random and device specific key to the hex file during production, and store this somewhere, possibly in a QR code as well.

    1b) Same as above, but the individual keys are stored in the "cloud" and a cloud service authenticates the phone commands and encrypts them for that device, and gives the phone the encrypted data to send over BLE. The phone never knows the key.

    1c) Same as above, but through the cloud service, a session key is generated which can be used between the phone and the device directly.

    2) Implement your own asymmetric key exchange protocol. Essentially, with symmetric keys the exchange is the tricky part to do securely.

    The disclaimer here has to be that I can't give you a full recipe for how to do it correctly, but perhaps this can get you started. Also, possibly, liability issues if we give dumb advice on security :)

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    Intellectual 480 points

    Hi Aslak,

    Thank you for your advice!
    I also want to clarify about the SNP API docs. If SNP does not support 4.2 LE secure connection like you think, then on SNP API Guide 5.3 Limitations there is a line that says:
    Bluetooth 4.2 Host and Controller options are limited to Secure Connections.

    Does it mean that SNP support the LE Secure Connection?

    I agree with you as not all phones support the secure connections so it is better to protect at application layer

    Thanks Aslak

  • 0 in reply to Pranata
    TI__Mastermind 23440 points
    Hi,

    I have to admit some ignorance on the SNP. I'm notifying a colleague who knows things but he's travelling so might not answer straight away.

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    Intellectual 480 points

    Thanks Aslak, hope it will make clear the documentation and the SNP firmware :)

  • 0 in reply to Pranata
    TI__Mastermind 33460 points
    Hi Pranata,

    You are correct that the SNP does support LE Secure Connections. It can also support/fallback to LE Legacy Pairing if LESC is not supported by your peer.

    Aslak had mentioned setting the IO capabilities above, these can be set with the SNP Set Security Parameter command.
    If you choose an authenticated pairing method then you will also need to issue a SNP Set Authentication Data command.