• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 71 subscribers
  • Views 2482 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

    unfortunately the central is an iOS device and I don't get to control how it starts encryption so I don't get to choose the EDIV and RAND it sends, it will only send back what was given to it from the original bonding with the peripheral. To do that I'd need to force the ediv/rand/ltk which the central received at the point it originally bonded so it sends me back them later.

    I got the idea from reading the BTLE spec actually, it envisages a peripheral with just a DSK on it which it can use to generate EDIVs and then reconstruct the DIV it used to then reconstruct the LTK.

    I agree if I had both sides of this, it would be easy. It's ok I didn't think it was possible, it would have been handy.

Reply
  • 0 in reply to Ulrich Myhre

    unfortunately the central is an iOS device and I don't get to control how it starts encryption so I don't get to choose the EDIV and RAND it sends, it will only send back what was given to it from the original bonding with the peripheral. To do that I'd need to force the ediv/rand/ltk which the central received at the point it originally bonded so it sends me back them later.

    I got the idea from reading the BTLE spec actually, it envisages a peripheral with just a DSK on it which it can use to generate EDIVs and then reconstruct the DIV it used to then reconstruct the LTK.

    I agree if I had both sides of this, it would be easy. It's ok I didn't think it was possible, it would have been handy.

Children
No Data
Related
Terms of service