3 Replies Latest reply on Apr 24, 2018 11:10 AM by e.pratt_1639216

    Whitelist, bonded list and resolve list




      I'm trying to understand how all these lists work. Please, let me do some afirmations and correct them if they are wrong.


      Firstly, I started working with whitelist to filter address of centrals that were trying to connect to my peripheral device. I managed this whitelist manually and it worked fine until appears ble 4.2 and its privacy 1.2. Here we have RPA or random address and now, the same device that is trying to connect to my peripheral has different BD address from one connection to next one. We can not employe whitelist longer for device connection filtering.


      So, I started working with bonded addresses list. Bonding requires pairing, and pairing is not mandatory after a connection is stablished. Pairing is necessary for encrypt a connection and for keys exchange. I mean that bonding process will save BDA to bond list and keys to resolve list. These keys are which we will need to resolve random address from central and to be able to encrypt connection again, but not to manage the connection itself. I mean, any central device (bonded or unbonded) will get to connect to my peripheral. Only bonded devices will get authenticate succesfuly. Others, will not get authentication but they could stay connected and unauthenticated if it is not requiered. Pairing and authentication can be requested from central as well as from peripheral.


      I've been testing diferent things and I've seen followings:

      - When Pairing process is completed it automatically includes the central's BDA in the peripheral's whitelist. Up to 8 address can be saved. The 9th one will not be saved. If central's address is random type and it changes every connection, each new address will be included as new index in the whitelist.

      - When Pairing process is completed it automatically includes the central's BDA in the peripheral's bond list. If central's BDA is RPA type and change every connection, the previous random address in the list will be updated with the new one.


      I've not tested resolve list yet. Is there any document in which all that list management mechanism is described ?


      Any correction/clarification of my text will be appreciated.


      Best regards,


        • 1. Re: Whitelist, bonded list and resolve list

          Note: The peripheral can request a disconnect and manually disconnect if needed to prevent malicious extended connections.

          The lists are generally used as storage buffers for some number of addresses related to the function (whitelist, bonding, resolve). But the functionality follows the Bluetooth specification I believe, so looking at the Bluetooth SIG Specifications for the whitelist/bonding/RPA might yield results.

          Otherwise, the information you listed from your own experience with testing looks correct to me.

          • 2. Re: Whitelist, bonded list and resolve list

            I saw in BLE 3.10 component datasheet next text:


            Auto Populate Whitelist with Bonded Devices.

            Provides an option to link the whitelist to bonded device list. It is required for maintaining backward compatibility and it not recommended for new designs. When this option is enabled, use CyBle_GapRemoveDeviceFromWhiteList API to remove a device from both bond list and whitelist together. For new designs uncheck this option and use new APIs for removing device separately from whitelist: CyBle_GapRemDeviceFromWhiteList and bond list: CyBle_GapRemDeviceFromBondList.


            In BLE 3.30 component this option not appear, so I suppose that both list are manage independently. But I see that when pairing with bond option enabled, new address is added in bond list as well as in whitelist. Is whitelist autopopulate with bond list yet ?


            Thank you,


            • 3. Re: Whitelist, bonded list and resolve list

              It might be that the address is added to the bond list intentionally when you set the unit for bonding, and then bond, and it adds it to the whitelist because the bonded device needs to be in the whitelist to connect. But, I would expect it not to add devices to the bond list when you request to add it to the whitelist, as the devices in the whitelist aren't necessarily bonded with the unit.

              (Basically, units that are bonded are logically in the whitelist as well, whereas whitelisted units aren't necessarily bonded).