Is the Low level bluetooth description of bonding correct?

[brianreinhold]

The documentation describes bonding as follows:

Bonding is the process of storing those secrets into non-volatile storage. When bonded, a device is able to resolve a resolvable private address (RPA) from another device based on the stored identity resolving key (IRK). To support bonding, an application must implement the _IRQ_GET_SECRET and _IRQ_SET_SECRET events.

My understanding is that bonding requires more than just the saving of the Long Term Keys but also the enabling of characteristics and saving of service discovery. The idea being that on a reconnect, in an idealized situation, the only thing a central would need to do is encrypt using the LTKs and then the data would be indicated/notified and the device could shut off when everything is sent. Minimal power use. No service discovery or re-enabling of the characteristics needed. There is often an equal sign placed between pairing and bonding but that is not true. In practice most devices that pair and save LTKs also save service discovery results and the enabled state.

[jimmo]

@brianreinhold That's right, this is not implemented yet, we only implement the "persist keys" part of bonding, but yes we're also supposed to persist other state (including pending indications!).

Service discovery also requires implementing the service db hash characteristic too.

There's a bit of work to be done here... I'm not sure when we'll get to it but it's definitely a known issue and unfortunately not that simple to implement (and needs to be implemented for both NimBLE and BlueKitchen). Are you interested in contributing?

[andrewleech]

for reference service hash db was started / implemented on nimble here: apache/mynewt-nimble#1112
With some matching mpy support in #8027 & micropython/micropython-lib#467

I hadn't seen there was further feedback on the nimble PR that hasn't been followed up on; at the time we were using successfully this for a work project which has since shipped, haven't spent the time to keep up with getting it all merge-ready though.

[brianreinhold]

@jimmo To be honest with you my Python is at the newbie level and I would probably cause more problems than I would solve. I find it really difficult to follow code of dynamically typed languages! That being said if I can successfully write some health device clients (low level or aioble) I would be glad to contribute these as examples. I do have a tendency to 'over comment' my code which other developers often complain about but I never regret it when I have to come back to it in six months and try to figure out what I was doing.

Right now I need to make a decision of whether to use the low-level or aioble library. I need to support MITM dynamically generated passkeys and from what I understand this support is not yet possible in aioble.