Whitelisting with resolvable random address

[CoNe_349661]

I have a device (peripheral) that uses the link loss service. If this service is set, and the link is lost, an alarm goes off. I only want to allow previously bonded devices to connect back to the peripheral during this alarm condition. This would normally be handled by whitelisting. However, iOS devices (and I assume android too) uses resolvable random addresses, so their address changes. 

   

I don't have a problem switching from Scan Any Connect Any to Scan Any Connect Whitelist, I just set the struct value cyBle_discoveryParam.advFilterPolicy = CYBLE_GAPP_SCAN_ANY_CONN_WHITELIST. My problem is that the whitelisted address becomes obsolete after the iOS client changes its address. 

   

My (limited) understanding of resolvable random addresses seems like I should be able to "resolve" the random address. That is, I can figure out if the new iOS address is from the same client as before using the IRK (Identity Resolving Key).  Does my app have access to the IRK? How can I use this to update the whitelist, or to check if a new client trying to connect is actually an old bonded device? Thoughts?

   

Thanks!

[Anonymous · Accepted solution]

I also had this concern for a long time. The Bluetooth 4.2 specification added Link Layer Privacy (see Core Specification 4.2 [Vol 6, Part B], section 6.2.1: https://www.bluetooth.com/specifications/adopted-specifications, "Core Version 4.2"), which let the Link Layer do the resolving for you. I think the previous way was to not use the Whitelist at all and resolve the private resolvable address manually. If the resolved address was one that you did not like, then disconnect. In addition there is a function CyBle_GattsDbAuthorize() you probably could use. The newer PSoC 4 chips with Bluetooth 4.2 should therefore do the resolving for you, at least Cypress told me that they're capable of this. I have not had time to test my code yet, I will do this soon, but I shall post my code here. Then we can find this out together; a win-win situation 🙂

       

Also take a look here: http://www.edn.com/design/wireless-networking/4439356/2/A-look-into-Bluetooth-v4-2-for-Low-Energy-Pr...

[Anonymous]

Here is the LL resolve code. I have not tested it yet, so it would be nice if some could do this.

       

I am using a CY8C4248-LQI-BL583 (Bluetooth 4.2) which I think is available for the Pioneer Kit as well.

[Anonymous]

Thanks Speedy!

   

Unfortunately I am currently locked into a BLE 4.1 version chip (this could change late down the road). Do you know how I can get the IRK so I can resolve the address myself?

[Anonymous]

If the device is bond, I suppose you just can use CyBle_GapGetDevSecurityKeyInfo()/CyBle_GapGetPeerDevSecurityKeyInfo() as done in the LLResolve.c file I attached above. There is also an event CYBLE_EVT_GAP_KEYINFO_EXCHNGE_CMPLT which probably can be used. But then I don't know how to resolve these manually. Take a look in the API documentation to see if you can find some interesting functions! The "GAP Central and Peripheral Functions" section had some functions, but I was not sure if these needed 4.2 or not.

       

A note: I you are going to use the LL resolve functionality in Bluetooth Smart 4.2 for PSoC4 BLE, the "Enable Link Layer Privacy" option should be checked in the BLE component: "GAP Settings > Security".


 

[Anonymous]

Were you able to get this working?
 Thanks.

[Anonymous]

Hi! I did not have the time to test this, and we decided to use an open GATT instead. I did a good effort (read API documentation) to write the attached codelines, so hopefully it will work (with some minor changes?).