Hi Łukasz, Thank you! What is the proper way to verify that the device connecting is the one previously bonded with? Which events should be handled and what should be verified there?
Br, Davis pirmd., 2023. g. 16. okt., plkst. 11:52 — lietotājs Łukasz Rymanowski (< lukasz.rymanow...@codecoup.pl>) rakstīja: > Hi Davis, > > Once you have a remote device bonded you should stop advertising with > general advertisement and use only directed advertisement. This means you > need to reconfigure your advertising instance. > In this way, only the bonded device will be able to reconnect. > > Most probably, you would like to start advertising only when the device is > disconnected. > > Also to make sure that connected device is the one you bond previously, you > probably would like to enable encryption just after connection. > If the encryption fails, you can apply your policy - either disconnect the > device (ble_gap_terminate is fine), or allow it to pair again. > > Hope that helps. > > Best > Łukasz > > > > > > > > On Mon, 16 Oct 2023 at 08:05, Davis <davik...@gmail.com> wrote: > > > Hello! > > > > What is the proper way in NimBLE to restrict all access to a BLE > > peripheral - the peripheral should be accessible only from a single > > previously bounded central? > > > > I want to disable all anonymous access, as well as the ability to make > any > > new pairings or bondings. > > This should be done in a security aware way (that cannot be bypassed by > > violating BLE protocol, sending custom packets etc.). > > > > Currently I have the following questions: > > 1. In the BLE_GAP_EVENT_CONNECT handler I have added > > "ble_gap_security_initiate(event->connect.conn_handle);" (without > quotes). > > Is this the proper way to disable all anonymous access (except reading > > information that is broadcasted in the advertisements)? > > 2. What is the proper way to disable any new bondings and pairings (all > > connections that aren't using keys loaded into memory by calls to > > ble_store_write_our_sec(), ble_store_write_peer_sec(), > > ble_store_write_cccd())? > > In the BLE_GAP_EVENT_PASSKEY_ACTION add > > "ble_gap_terminate(event->passkey.conn_handle, BLE_ERR_AUTH_FAIL);" > > (without quotes). > > In the BLE_GAP_EVENT_REPEAT_PAIRING handler add "return > > BLE_GAP_REPEAT_PAIRING_IGNORE;" (without quotes). > > In the BLE_GAP_EVENT_IDENTITY_RESOLVED handler add calls > > to ble_gap_conn_find() and ble_store_read_peer_sec() that check > > whether ble_store_read_peer_sec() can find the key for peer_id_addr from > > the ble_gap_conn_desc filled by ble_gap_conn_find(). In case the key > cannot > > be found, "ble_gap_terminate(event->identity_resolved.conn_handle, > > BLE_ERR_AUTH_FAIL);" (without quotes) is called. > > Are these things the correct way to disable all new pairings and > bondings? > > Does anything else need to be done to disable all new pairings and > > bondings? > > 3. Is calling ble_gap_terminate() the proper way to terminate a > > rogue connection? > > 4. Is there anything else that needs to be done to secure the NimBLE > based > > peripheral from any kind of access that is not coming from the previously > > bonded central? > > > > P.S. I am using a fork ( > > > > > https://github.com/InfiniTimeOrg/InfiniTime/tree/main/src/libs/mynewt-nimble > > ), however my questions are about NimBLE in general (about how it > > should work). > > > > Br, > > Davis > > >
