The pairing/bonding/authentification procedure

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

cross mob
Anonymous
Not applicable

I have read the book "Bluetooth Low Energy - The Developer's Handbook" by Robin Heydon, but I am still not sure how my problem should be solved. I have also searched for help in two forums, StackOverflow (http://stackoverflow.com/questions/34964757/hide-a-connectable-peripheral-device) and in the official Bluetooth forum (https://developer.bluetooth.org/Community/SitePages/Topic.aspx?RootFolder=%2FCommunity%2FLists%2FCom...), but I have not got any answer. Hopefully, there is help here!

   

The behavior I want to achieve is very similar to a Bluetooth Smart mouse: After a central device (say, computer) has connected to it, this computer "owns" the mouse, so that only this computer is able to connect and use the mouse. The data from the mouse is not sensitive, so it does not matter if a third person can read this data. So the first time the mouse is used, no central device owns it, and any scanning central device can see it and connect. After that, that central device owns the mouse and the mouse will in the future only accept connection requests from that central device. A peripheral device must do advertising to be connectable. But a connectable mouse that has an "owner" (and therefore only accepts connection requests from that), should not pollute scanning for others, i.e. that mouse shall not be presented in the user interface of other computers scanning for a mouse. Hence the peripheral need to tell, using its advertisement data, that it does not accept connection requests from anyone. Of course, the owning central device knows it can connect to it.

   

I think pairing/bonding is the correct way for me to go. Is this true, even though I do not need encryption? For example, iOS central devices uses random addresses and so I probably need an IRK for a long time relationship.

   

Pairing can be initiated by both the central and peripheral. Which one is the typical initiator? It seems that both Android and iOS will request pairing if the peripheral responds with "insufficient authentification". In fact, the central device shall be the only initiator on iOS (https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf, "3.9 Pairing"). Does this means that a peripheral will always be connectable, but can then prevent further usage (over ATT) by responding with "insufficient authentification" and not reply positive to a pairing request (or just "insufficient authorization")? I can't see that the Cypress BLE component has an API function to stop/reply to a connection request. (I can use the CYBLE_GAPP_DISC_PARAM_T member advFilterPolicy in the call to CyBle_GappEnterDiscoveryMode for whitelists, but whitelists prevents random addresses (iOS)). Is pairing (and bonding - long time pairing) only needed when accessing a GATT service that is not of "Security Mode 1 Level 1: No security"? (As far as I understand, GAP security mode/levels are per service basis). If so, wouldn't denial of service (DoS) attack be possible then?

   

Since I have control of the application development for the central device (iOS/Android), filtering out "owned" devices in the user interface can easily be done with a hack, for example by putting a flag in the field "manufacturer specific data" of the advertise data. But I am looking for an "official" way of hiding my peripheral when it has an owner. For example, the "flags" field of advertisement data has bits for limited and general discoverable mode. If I set both to zero and advertise, will the owning central device still be able to connect? Advertisement data also has two other interesting fields: "public target address" and "random target address", see Bluetooth CSS6 (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735). Can they be used?

0 Likes
2 Replies
Anonymous
Not applicable

PS: I mentioned replies to pairing requests. The Cypress BLE component API has a funtion CyBle_GappAuthReqReply. Here I can use the CYBLE_GAP_AUTH_INFO_T argument to reply positive or negative. None of the "100 projects in 100 days"-projects Day015_Bonding and Day016_Authentification calls this or CyBle_GappAuthReq upon receiving CYBLE_EVT_GAP_AUTH_REQ. Isn't that a bug (cf. API documentation of  CyBle_GapAuthReq)?

0 Likes
Anonymous
Not applicable

I'm facing the same problem, but my need is when I disconnect from ios actively, do not want ios automatically connect back, so what should I do if I need to disconnect from central, only accept reconnection when user pressed the bonded device if user want to connect it again.

0 Likes