Identity resolving

[sven.kr...@gmail.com]

Hi all, 

I'm trying to remove bonding information for host devices which are failed to bond by implementing the hook SM_EVENT_PAIRING_COMPLETE -> ERROR_CODE_AUTHENTICATION_FAILURE. The devices have some bonding information from previous connections. I'm using a smartphone with NRFConnect and do the following

- Connect to the device and accept bonding

- Dissconnect from the device

- Delete bonding information on the smartphone

- Re-Connect to the device and press abort when the smarthone asks for bonding.

Due to some address randomization the same smartphone connects with an other address. I've added the following to the FAILURE-Hook:

bd_addr_type_t address_type = sm_event_pairing_complete_get_addr_type(packet);

sm_event_pairing_complete_get_address(packet, address);

gap_delete_bonding(address_type, address);

This does not work because the address isn't found in the LE device DB. How can I remove the bonding information? I need a way to get the "old" address from the device db. 

Some log output:

0000232 I hci.c.3161: New connection: handle 1025, 69:21:08:F2:3D:67

...

0000232 I sm.c.2181: device type 0, addr: DC:E5:5B:1C:2F:78

0000232 I sm.c.2203: LE Device Lookup: calculate AH

0000232 I btstack_util.c.304: IRK    ***************************

0000232 I sm.c.2175: LE Device Lookup: device 3/4

0000232 I sm.c.2181: device type 0, addr: DC:E5:5B:1C:2F:78

0000232 I sm.c.3416: LE Device Lookup: matched resolvable private address

0000232 I sm.c.1308: ADDRESS_RESOLUTION_SUCCEEDED, index 3

0000232 I le_device_db_tlv.c.334: LE Device DB encryption for 3, ediv xbe60, keysize 16, authenticated 0, authorized 0, secure connection 0

0000232 I sm.c.1331: peripheral: pairing request local 0, have_ltk 1 => trigger_security_request 0

0000232 I att_server.c.416: SM_EVENT_IDENTITY_RESOLVING_SUCCEEDED

...

0000232 I Identity succeded -> Addr 69:21:08:f2:3d:67

Kind regards

Sven

[Matthias Ringwald]

Hi Sven

You might have ran into an XY problem here :)

If a Central (smartphone) deletes the bonding information and starts a new pairing, the stored bonding information on the Peripheral will not be used - as a result, deleting it won't make any difference to the pairing itself.

As for the pairing: BTstack will reject a downgrade attack if the previous pairing had higher security (e.g. Numeric Comparison before and now a Just Works attempt). However, the main reason I've seen pairing fail is caused by using the wrong peer Bluetooth address for the cryptographic operations.

Please post a full log in .pklg format for further analysis for the failed pairing.

Deleting the bonding is a bit tricky. On a failed pairing, we cannot know the peer's identity address (as it didn't tell us), so BTstack cannot use the current private address to delete the bonding directly.
If you want, you can store the resolved identity address and call gap_delete_bonding with that upon authentication failure, but as mentioned, it won't change the pairing process.

Cheers
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/btstack-dev/6795af2a233921e4c7586b3f1728f9b1548399b0.camel%40gmail.com.