3 Replies Latest reply on Nov 2, 2020 2:34 AM by PY_21

    BLE 4.2 RPA, Bonding and WhiteList. It's even stranger.

    VaIk_2708246

      To begin with, I made a test application that outputs whitelists after bonding.

       

      And I saw that the address (RPA) of the bonded device is automatically included in the white list. In addition, since the RPA address of the bonded device changes from time to time, the RPA address (of the same device!) in the bonding list also changes. But this new address is simply added to the whitelist, and the old one is not removed. And all these are random addresses, which is strange in itself.

      Further, I found an some example in the discussion https://community.cypress.com/thread/44998?start=0&tstart=0

       

      This example suggests adding the device Identity Address (ID) to the whitelist after bonding.

      But wait, I see that the whitelist is automatically updated with random addresses (RPA) by the BLE stack itself. This is the first thing.

      And secondly, in this case, both the RPA address and the ID address will be on the white list.

      But this is some kind of nonsense.

       

      Can someone explain how it all works properly?

        • 1. Re: BLE 4.2 RPA, Bonding and WhiteList. It's even stranger.
          PY_21

          Hello,

           

          Yes, after bonding the device, the device will be automatically added to the whitelist also. If  the central device uses RPA(Random Private Address) as their Bluetooth device address, then you have to add the device to the Resolving List as well. That means, you have to add the central device address in the Resolving list as well as in the White list (if you are bonded the device then it will be automatically added to the whitelist, it is not required to add the device to whitelist again) of your peripheral device.
          The project provided in that thread will be helpful when the central/peripheral resolution is not enabled. So, adding the device Identity address to the whitelist will helps in using the whitelist feature.
          Please refer the PSoC Creator Code Example 'BLE_4.2_Datalength_Security_Privacy' ( PSoC Creator-> File-> Code Example) for more information.

           

          Thanks,
          P Yugandhar.

          • 2. Re: BLE 4.2 RPA, Bonding and WhiteList. It's even stranger.
            VaIk_2708246

            This is clear. Thanks.

            Explain only please, why BLE stack will whitelist the RPA address, and the given example is the Identification Address?

             

             

            From all this, it can be assumed that it does not matter which address (RPA or ID address) to add (both to the white list and the resolving list). BLE stack normally deals with this itself.

            Can you confirm or refute this guess?

            • 3. Re: BLE 4.2 RPA, Bonding and WhiteList. It's even stranger.
              PY_21

              Hello,

               

              Q: Can you confirm or refute this guess?

              Ans: Yes, if you enable the resolution(using CyBle_GapSetAddressResolutionEnable api) then stack will resolve the RPA address. This API will causes the BLE Stack to use the resolving list whenever the Controller receives a local or peer Resolvable Private Address. You can check with the Code Example 'BLE_4.2_Datalength_Security_Privacy' ( PSoC Creator-> File-> Code Example) in the PSoC Creator.

              The example project in the thread will be helpful when the central/peripheral resolution is not enabled. So, adding the device Identity address(Every Privacy-enabled BLE device has a unique address called the Identity Address) to the whitelist will helps in using the whitelist feature.

               

              Thanks,
              P Yugandhar.