Whitelist, bonding, random addresses

[Anonymous]

Any tips on how to implement a secure server when the client uses the 'random' address type? I found that with "bonding requirement" set to "Bonding" my server would still accept a connection from an un-bound client. So I set the Advertising Filter Policy to "Scan request: Any | Connect request: White list" and wrote some code to keep the whitelist aligned with the bonded devices list. This worked well until I encountered a client device that used a random address for privacy (CyBle_GapGetPeerBdAddr returns type 1 in CYBLE_GAP_BD_ADDR_T:type). Now it works fine immediately after bonding, but gets locked out (because of whitelisting) when the address changes.

   

So how can I prevent un-bonded clients from connecting while allowing bonded clients which use random addresses?

   

EDIT: Arghh! On further research I tried:

   

        case CYBLE_EVT_GAP_AUTH_REQ:
            wrAuthInfo = (CYBLE_GAP_AUTH_INFO_T *)eventParam;
            if (bond_closed) {
                wrAuthInfo->bonding = CYBLE_GAP_BONDING_NONE;
                wrAuthInfo->authErr = CYBLE_GAP_AUTH_ERROR_AUTHENTICATION_REQ_NOT_MET;
            }
            break;

   

In my event handler. This appears to be quantum code - if I have a breakpoint in the conditional it gets triggered and the pairing request is rejected as intended. However remove that breakpoint and pairing (with bonding) happens as if the conditional is false!

   

I am beginning to see why so much IoT technology gets shipped insecure! I've spent days banging my head against this brick wall - all my good intentions get thwarted by awful documentation and "insecure by default" APIs!

   

Help please!

[Anonymous]

Hi John,

   

If the client is using a RPA or Random Private Address, you can add the device's idAddr to the resolving list after bonding. When the security keys are exchanged, the idAddr is also exchanged. You can add this address to the resolving list and the whitelist. So, when then central's address changes after the first time, your peripheral will be able to resolve this new address(provided its RPA) and will allow the central to connect. If it is not able to resolve, it will not allow the central to connect because of the filter policy. APIs you will need to include:

   

    
1. CyBle_GapGetPeerDevSecurityKeyInfo()
    
2. CyBle_GapAddDeviceToResolvingList()
    
3. CyBle_GapAddDeviceToWhiteList()
   

   

However, this feature is a part of the Privacy 1.2 which is associated with Bluetooth 4.2. So you will not be able to implement this in Bluetooth 4.1.

   

Coming to your second problem, I cannot comprehend as to how/why it is happening so. Its behaving differently because of a breakpoint?

[Anonymous]

I do not think I can safely use Bluetooth 4.2 features as they will not be in most client devices (I'm not sure if support is even in Android yet). However even in 4.1 bonding does seem to be able to resolve the RPA because it continues to recognise the device. All I want is that information at API level so I can respond differently depending on whether the client is bonded or not.

   

I'm getting the impression I should not be seeking to block connections at all, but rather should lock down the individual characteristics to require encryption and therefore bonding to actually do anything. I need to do some more tests.

   

As for the quantum debugger, I've noticed this kind of problem a lot when debugging BLE. For example if you break in the callback and then single step you usually end up in an ISR you do not have source for.