• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 71 subscribers
  • Views 2481 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112187
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Generating my own LTK/EDIV/RAND

RK

Is there a hook anywhere in the SD (130/132) to let me generate my own LTKs, EDIV and RAND during the bonding process? I don't think so, I've not found one, but perhaps I missed it.

I wanted to move to a security model which uses one private on-device piece of data to generate all LTKs from the diversifier, yes that's 16 bit but it's enough for my purposes and would help making devices with pre-shareable keys. It also drastically cuts down on the amount of data you need to store in flash for devices which are expected to bond with many others, in fact it cuts it down to just remembering the highest diversifier you've used because everything else can be calculated on the fly.

Parents
  • 0

    Hi,

    It's not possible to override those yourself in the way you ask, but you shouldn't need to. If you have the means to generate the LTK based on some EDIV and RAND, you do not need to bond at all. On the central side, simply call sd_ble_gap_encrypt with the custom EDIV, RAND and LTK fields filled into the arguments. On the peripheral side, fetch the BLE_GAP_EVT_SEC_INFO_REQUEST event, recalculate the custom LTK based on the EDIV/RAND in the event, then fill in the datatypes for the sd_ble_gap_sec_info_reply call with the LTK.

    If the peer device is not one of your special devices, it should signal that it doesn't have a bond, and you can then choose to bond normally.

  • 0 in reply to Ulrich Myhre

    Thanks - not a critical thing for me - it was a nice-to-have for a particular use case where it looks like a peripheral would end up with a lot of bonds to it, all of which I'd prefer to remember. Mostly because iOS does a cruddy bad job of dealing sanely with devices which have lost their bond information (or thrown it away), it just quietly fails, doesn't ask if you want to re-bond, doesn't even consider that perhaps you might want to re-bond and you have to go to settings and remove the device by hand. This would have been a good scheme for storing a huge number of bonds without actually storing a huge number of bonds.

    But you have plenty else more useful to work on that odd use cases like this.

Reply
  • 0 in reply to Ulrich Myhre

    Thanks - not a critical thing for me - it was a nice-to-have for a particular use case where it looks like a peripheral would end up with a lot of bonds to it, all of which I'd prefer to remember. Mostly because iOS does a cruddy bad job of dealing sanely with devices which have lost their bond information (or thrown it away), it just quietly fails, doesn't ask if you want to re-bond, doesn't even consider that perhaps you might want to re-bond and you have to go to settings and remove the device by hand. This would have been a good scheme for storing a huge number of bonds without actually storing a huge number of bonds.

    But you have plenty else more useful to work on that odd use cases like this.

Children
No Data
Related
Terms of service