Simulated device authentication and pairing with Android emulator

[ftrias]

I created a simulated device by modifying run_gatt_server.py and have it working with an app running on the Android emulator. I have a characteristic that I would like to require authentication and encryption by pairing using a fixed pin, similar to the following. I am at a loss about how to proceed.

char_tickcounter = Characteristic(
                    '00000001-8e22-4541-9d4c-21edae82ed19',
                    Characteristic.Properties.READ | Characteristic.Properties.NOTIFY,
                    Characteristic.READABLE,
                    CharacteristicValue(read=read_tickcounter),
                )

[zxzxwu]

If I understand correctly, do you want to make your own pairing process over GATT, instead of general Bluetooth pairing?

[zxzxwu]

A more Pythonic way to do this is mock.patch.object(secrets, "randbelow", lambda x: 111111), but a more formal answer in Bumble is that smp.Manager allows you to provide your own SMP session implementation, so you can just derive another class from smp.Session overriding display_passkey with a constant passkey, and set it to smp.Manager.session_proxy like:

# run_fixed_passkey.py

class Session(smp.Session):
  def display_passkey(self):
    self.passkey = 123456
    ...

device.smp_manager.session_proxy = Session

https://github.com/google/bumble/blob/main/bumble/smp.py#L1956

[ftrias]

@zxzxwu, thank you for the suggestion to use mock and the explanation. If I override display_passkey, don't I also have to implement all the other logic in that function? If the logic changes with future versions, won't that cause me problems? It's the same dilemma with overriding randbelow.

[zxzxwu]

Yes, you need to override the entire display_passkey. If you don't need to upgrade Bumble frequently, that should be easier.
A potential change is to replace fixed passkey generator with a dedicated factory function, like

class Session:
  ...
def display_passkey(self):
  self.passkey = self.manager.passkey_factory()
  ...

...

class Manager:
  passkey_factory = lambda: secrets.randbelow(1000000)
  ...

[barbibulle]

Since one of the goals of Bumble is to make it easier for developers to simulate all sorts of Bluetooth devices, I think it makes sense to support a mode where the pairing is done with a key supplied by the pairing delegate (it is via the delegate mechanism that all pairing customization happens) rather than a random source (and that's also more flexible than hard-coding a fixed pin, since with a delegate you could decide to have a fixed PIN that depends on the peer, or other context).
I'll send a PR shortly with support for that.