• State Verified Answer
  • Replies 2 replies
  • Subscribers 74 subscribers
  • Views 888 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 230688
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Share LTK between two centrals

Chad

We have a requirement for the ble-peripheral device that we are designing to be able to be "registered" to a user through their iphone. If that user has multiple iOS devices that they've logged in to they should be able to talk to our ble-peripheral device without having to re-register.

We've tried designing our own registration process, to meet this requirement but I don't love anything that we've come up with so far.

I'm wondering if standard BLE security could help us meet this requirement with the normal pairing/bonding system. Specifically:

1. During manufacturing each ble-peripheral device is given a TK that is saved in a database.

2. When user registers we perform an OOB bond using the TK retrieved from the database for the iOS device, peripheral will remember what it was from manufacturing. (ideally using LE Secure Connection, although LE legacy isn't completely off the table)

3. iOS device saves LTK (maybe EDIV & Random Value as well) to a database.

4. Any other iOS device in which the user logs in would be able to use the LTK to talk to the device as if it was already bonded.

Would step 4 work? Could the LTK be used by two different centrals to connect to a bonded peripheral? Does anyone know if iOS would allow an LTK retrieved from a database to be loaded and used?

We are using an nRF52840, SDK 15.3, SD 140

  • +1

    Hi Chad, 

    I don't think it's possible to do step 3 and 4. iOS won't allow the app to access any information regarding the bonding data, neither to use predefined LTK to encrypt a connection. This applied for the mainstream Android OS as well. 

    If you have full control of the central device, for example if you use the NRF52 as your central, then it's possible what you proposed. 

    For your application, I would suggest to use your own proprietary method to "pair" phones to a device. Your device may send a challenge packet and your phone need to use a key to calculate the answer to send it back to the device so that the device will accept the phone. Or you can use other encrypting method. By doing this, you may not need your device to be paired (normal pairing) to the phone. 

  • 0

    Thanks for your response Hung. Very helpful information

Related
Terms of service