Paring and bonding with one button

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DeTo_1826166
Level 3
Level 3
First like received First like given

Hello,

I have hard time figuring out how, i could pairing and  bond with a device having only 1 button, and a smartphone with resolvable random adress.

The device has only 1 button, the user can pair his smartphone with it, but for the other uses, the device have to be bond (mostly because this single button is not very accessible.

It run on a BLE 4.1 PROC/PSOC4

So from what i see there are some possibilities :

Because only 1 button: where are in NoInput/NoOutput : so unauthenticated connection + encrypted data

1) The good one :

Use the button to change the advertissement mode : - in normal mode : scan request : white list ;  connect list white list :

                                                                                    -  in pairing mode (button pressed) :  scan request any : connect list : any

But the problem is that we can't use whitelist because the smartphone now use resolvable random adress.

(And if we want a good compatibility we can't use the BLE 4.2 with all the things, irk resolved in the other layer, im right ?)

2)

Use the button to discard connection when we are in the connected states :

In the CYBLE_EVT_GAP_DEVICE_CONNECTED  state

if (ButtonPressed)

{

cyBle_authInfo.authErr = CYBLE_GAP_AUTH_ERROR_NONE;

}

else

{

cyBle_authInfo.authErr = CYBLE_GAP_AUTH_ERROR_PAIRING_NOT_SUPPORTED;              

}

That work perfectly when we pair for the first time, but for the reconnection we have to compare the device adress, with the bonded device adress list.

So can i use something like that  ? :

So in the connected state :

use GapGetPeerBdAddr to get the device Adress

and compare it to the list of previous bonded device that we get with : CyBle_GapGetBondedDevicesList (that we call in disconnected state for exemple)

Is that ok to do that  ? I didn"t see something similar in examples

Thank you.

0 Likes
1 Solution
Anonymous
Not applicable

The IRK is meant for obscuring who is associated with a bluetooth address (to prevent tracking). This means that you won't want to do whitelisting, or filtering based on the bluetooth address, as it will always be wrong.

I think GapGetPeerBdAddr() will return the random Bd (bluetooth device) Address, as the device can't change it's address when it connects to your peripheral, and if it did so, it would become "trackable" to other devices with a return to its old Bd address.

Based on this thread: Whitelisting with resolvable random address

The resolving of the Bd address is handled by the application in BLE 4.1, but handled by the LL in BLE 4.2. Ultimately, all you need to do is:

Encrypt the connection so only one other device is seeing the transmitted data, and verify the authenticity of the connected device as the authorized user for connecting.

Encrypting the connection is part of the connection, and thus you probably already have it working;

As far as authenticating the remote user, any security username/password variation will work. (Setup the username how you want, then store the password on first bonding/setting up the device. Then upon reconnection, verify user enters accurate password before allowing device access; Otherwise, disconnect after some timeout)

View solution in original post

0 Likes
1 Reply
Anonymous
Not applicable

The IRK is meant for obscuring who is associated with a bluetooth address (to prevent tracking). This means that you won't want to do whitelisting, or filtering based on the bluetooth address, as it will always be wrong.

I think GapGetPeerBdAddr() will return the random Bd (bluetooth device) Address, as the device can't change it's address when it connects to your peripheral, and if it did so, it would become "trackable" to other devices with a return to its old Bd address.

Based on this thread: Whitelisting with resolvable random address

The resolving of the Bd address is handled by the application in BLE 4.1, but handled by the LL in BLE 4.2. Ultimately, all you need to do is:

Encrypt the connection so only one other device is seeing the transmitted data, and verify the authenticity of the connected device as the authorized user for connecting.

Encrypting the connection is part of the connection, and thus you probably already have it working;

As far as authenticating the remote user, any security username/password variation will work. (Setup the username how you want, then store the password on first bonding/setting up the device. Then upon reconnection, verify user enters accurate password before allowing device access; Otherwise, disconnect after some timeout)

0 Likes