Authenticate using button

[olovh]

Hi,

we are building a device based on nrf52832. Everyone with the app installed should be able to connect to some characteristics on the device but we want other characteristics (that changes the device behavior) to be protected. The device have a button that can be used to indicate physical access to it and we want to use that as means to enable access to the protected characteristics. How do we best implement this while not violating any basic ideas behind Bluetooth pairing/bonding?

As it stands now we use BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM for the attribute metadata that require physical access and only BLE_GAP_CONN_SEC_MODE_SET_OPEN for attributes that are publicly available. The button controls if bonding is allowed or not by calling pm_sec_params_set() upon keypress. Static keys are used to automatically setup encryption with MITM authentication. Problem with current setup is that all peers with access to the static key, which is distributed in the app, can do MITM level encryption and access the restricted attributes. It is just that they cannot bond unless button is pressed (have physical access to the unit).

Adding a sticker with a generated PIN to the device, instead of distributing a static PIN with the app, would of course solve the problem (and increase security) but we would rather want users to press a button than including an additional sticker and forcing them to enter a pin.

Many thanks, Olov

[dav lion]

My nrf51 product does something like this. We use an unprotected characteristic on the board (peripheral) that the Central writes when it wants to Pair. On receipt of this message, the peripheral shows an indicator to user (in our case a particular pattern of leds). If the user accepts by pressing a button, the Peripheral informs the Central (ios/android) via an hvx on the unprotected characteristic. Also, the peripheral sets a flag that allows connections to an encrypted characteristic, recording the address of the current Central. For the rest of the duration of the current connection, the Central may attempt to read from an encrypted characteristic (setup for JustWorks pairing). The peripheral gates whether pairing is allowed inside it's on_ble_event handler, when processing the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. When the connection to the central closes, the peripheral stops allowing pairing.

[Hung Bui]

@olov: Could you clarify that the issue you have now is central device can pair but cannot bond ? It's a little bit unclear on the issue you described: "Problem with current setup is that all peers with access to the static key, which is distributed in the app, can do MITM level encryption and access the restricted attributes. It is just that they cannot bond unless button is pressed (have physical access to the unit)."

isn't It is just that they cannot bond unless button is pressed (have physical access to the unit). what you want to achieve ?

I don't see any problem of using a physical button to reject bonding /pairing. You simply have to reject pairing when BLE_GAP_EVT_SEC_PARAMS_REQUEST event is received with BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, if the button is not pressed.

Please have a look at our ble_app_uart example, where we always reject pairing.

Another option you can do is to set your protected characteristic with authorization property. So that if the button is not pressed, all the read and write to it will be rejected by the application.

[olovh]

Thanks for your ideas and responses! @hung bui: I was trying to explain that I was looking for a way to also deny pairing requests and not only deny bonding requests. After som sleep and fresh coffee It was easily fixed by supplying a NULL argument to pm_sec_params_set() and I believe it all works fine for us now.

In other words - ok to close this ticket now.