Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating Pairing : Identifying if a device already is bonded #184

Open
pymenow opened this issue May 1, 2023 · 2 comments
Open

Integrating Pairing : Identifying if a device already is bonded #184

pymenow opened this issue May 1, 2023 · 2 comments

Comments

@pymenow
Copy link

pymenow commented May 1, 2023

I am currently Integrating the pairing functionality into my custom app.

Basically the flow would be when on_connect check if the address is in the keystore , if it is continue else pairing mode.
However I have not been able to get this check correctly done as the address of the connecting device - Android keeps changing .
I looked at the unbond.py app and it seems to remove all bonds and isnt specific to an address or device to unbond from .

Any pointers here will help .

At present I always need to unpair and repair for me to get my app to continue execution of the rest of the code.

The only time a check for if connection.is_encrypted went through was when i paired via Windows and it used the same address as previous connections.

Issue is seen on pair.py as well where when i restart the app after first pairing it doesnt progress until I unpair and repair on an Android phone.

@barbibulle
Copy link
Collaborator

The keys in the file-based key store are stored per-address, and unbond.py should really only remove the keys for a single address (it you don't pass an address, it just prints all the keys but doesn't remove anything, which the help text really should document...).
With Bluetooth LE, things are a bit more complex than with Classic, because of LE privacy. The addresses that are used by LE-privacy-enabled devices (most of them) rotate regularly (typically every 15 minutes for something like a phone). Those rotating addresses can be "resolved" back to a fixed address by peers that have the IRK (identity resolving key), which is obtained when pairing.
When pairing, the paired device will share, along with the IRK, its "identity address" with the pairing peer, and that's the address that's used for key storage in the key store. When you can for devices, you will see the rotating random address (a.k.a "resolvable private address"), and if you have the IRK, it can be resolved. Having the IRK for a device, and being able to resolve a private address is what tells you that you're paired with that advertising device.
In order to resolve addresses, you have to use an AddressResolver object, which you instantiate by passing a list of resolving keys. From keystore instance, keystore.get_resolving_keys() gets you that list.
I'm working on some enhancement to make that key resolving step automatic, but in the current version, that's something you need to do for yourself when you get advertisement results.
The scan.py app is "supposed" to do that for you when your device config has a keystore or if you pass a keystore file explicitly, but I see that it's broken in the current version (because the instantiation of the keystore object have been moved to after power_on(), I will send a PR to fix that (but the code example to resolve keys with a resolver is still valid).

Finally, about encryption on LE: just being paired doesn't mean you'll have encryption enabled. In a connection, one of the peers will need to request it. That's done with connection.encrypt(). With desktop and phone OSes, that may happen automatically if you try to access a GATT characteristic that returns an error indicating that there isn't sufficient encryption. Bumble doesn't (yet) do this automatic request upon GATT error, so if you need encryption, you have to call .encrypt() to request it.

@pymenow
Copy link
Author

pymenow commented May 4, 2023

Thanks again for explaining.
So at a high level :

  1. on_connect , check if you can resolve the keys , if not pair request.
  2. on_pair or on_connect (if already paired) -> connection.encrypt()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants