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.

[Ulrich Myhre]

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.

[RK]

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.

[Ulrich Myhre]

We actually used to do something like this in the older variants of S110, but the potential for collisions became such a big problem that we changed it. The SoftDevice would combine the ediv and rand into a diversifier, then encrypt it with a device-specific secret to get the LTK. On the s13x, the LTK is always set by the device, and cannot be overridden. If you feel that this is a must-have, then please contact the closes sales representative so we get the correct idea about interest. We already allow you to change IRK with an options API, so it's not impossible that something like this could go into the same API - given interest.

[RK]

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.