2 Replies Latest reply on Oct 22, 2020 1:58 PM by VaIk_2708246

    BLE 4.2 RPA and connection not expected behavior

    VaIk_2708246

      Hello

       

      I am using RPA in my device.

      And I expected that when the resolve list is empty (right at start) and resolve list is enable , then, in accordance with the standard,

      no device with an RPA address can connect to my device.

       

      6.2.1 ADV_IND

      ...

      When an advertiser receives a connection request that contains a resolvable private address for the initiator’s address (InitA field); the Link Layer shall resolve the private address (see Section 1.3.2.3). The advertising filter policy where white list is enabled (see Section 4.3.2) and the successful resolution of the initiator’s address shall determine if the advertiser establishes a connection.

       

      However, it is not.

       

       

      CYBLE_EVT_STACK_ON:

       

          CyBle_GapSetAddressResolutionEnable(1u);       //(Resolve list is empty !!!)

          apiResult = CyBle_GappStartAdvertisement(CYBLE_ADVERTISING_FAST);

       

      I use CySmart 1.3 for testing, and Resolvable Random Address in it config.

       

      And when I connect to my device, the connection is successful.

       

      Link Layer Privacy Enable is allowed in the project.

       

       

      –°ontinuing the topic.

      I studied the suggested example BLE_4.2_DataLength_Security_Privacy And I have a few questions regarding it

       

      1.

      Before calling CyBle_GapAddDeviceToResolvingList,which occurs in two places in main.c,the rpaInfo structure is filled, with bdAddr.

       

      bdAddr is Peer Identity device address, but it is assigned the peer Bluetooth device address, which in my case is random (RPA)

       

      In my opinion this is a bug, or not?

       

      What is in DisplayBondList:

                  memcpy(rpaInfo.bdAddr, bondedDeviceAddress.bdAddr, CYBLE_GAP_BD_ADDR_SIZE);

                  rpaInfo.type = bondedDeviceAddress.type;

       

      What should be DisplayBondList:

                  memcpy(rpaInfo.bdAddr, &securityKeys.idAddrInfo[1], CYBLE_GAP_BD_ADDR_SIZE);

                  rpaInfo.type = securityKeys.idAddrInfo[0];

       

      And you also need to fix it in the place where the event is processed CYBLE_EVT_GAP_AUTH_COMPLETE:

       

      2. But in any case, I'm testing the original code, or the code in which these changes are made, when the code is in the ADVERTISEMENT_PRIVETLY state and   sends ads type's CYBLE_GAPP_CONNECTABLE_UNDIRECTED_ADV (in this case RPA resulution is enabled), any device, which not added to the Resolving List CAN connect to the device under test.

       

      But this is against the standard.

       

      Can you somehow clarify the situation?

       

      Thnx.

        • 1. Re: BLE 4.2 RPA and connection not expected behavior
          PY_21

          Hello,

           

          1. Directed advertising types accept connection requests from a known peer device, whereas Undirected accept connection requests from any peer device. So, please check the advertising type defined in your project.
          2. Every Privacy-enabled BLE device has a unique address called the Identity Address. The Identity Address is the Public Address or Static Address of the BLE device. Every Privacy-enabled BLE device also has an Identity Resolving Key (IRK). The IRK is used by the BLE device to generate its RPA and is used by peer devices to resolve the RPA of the BLE device. Both the Identity Address and the IRK are exchanged during the third stage of the pairing process. So, while using a RPA for device, pairing has to be done for exchanging the keys to resolve the RPA.
          3. Privacy-enabled BLE devices maintain a list that consists of the peer device’s Identity Address, the local IRK used by the BLE device to generate its RPA, and the peer device’s IRK used to resolve the peer device’s RPA. This is called the Resolving List. Each entry in the Resolving List follows the format shown in below image. Please refer to the section 7.2 Privacy Concepts in the datasheet for more information.

           

          Question: bdAddr is Peer Identity device address, but it is assigned the peer Bluetooth device address, which in my case is random (RPA)

          Ans: The devices share a fixed address called the Identity Address. This Identity Address can be a Public or Random Static Address type. Because the devices, which have bonded earlier, know the IRK and Identity address, they can easily resolve the peer device's private address.

           

          Please share your project so that we can check at our end.

           

          Thanks,
          P Yugandhar.

          • 2. Re: BLE 4.2 RPA and connection not expected behavior
            VaIk_2708246

            Thanks for the answer, but it was not clear.

            Originally, I pointed to the standard page BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] page 115, topic 6. PRIVACY.

             

            6.2 PRIVACY IN THE ADVERTISING STATE

             

            6.2.1 ADV_IND The Link Layer may use resolvable private addresses or non-resolvable private addresses for the advertiser’s device address (AdvA field) when entering the Advertising State and using connectable undirected events. The connectable undirected advertising event PDU AdvA field is generated using the Local IRK value and the Resolvable Private Address Generation Procedure (see Section 1.3.2.2). If the Host has not provided any Resolving List IRK pairs for the peer to the Link Layer, then the AdvA field shall use a Host-provided address.

             

            When an advertiser receives a connection request that contains a resolvable private address for the initiator’s address (InitA field); the Link Layer shall resolve the private address (see Section 1.3.2.3). The advertising filter policy where white list is enabled (see Section 4.3.2) and the successful resolution of the initiator’s address shall determine if the advertiser establishes a connection.

             

            It is clearly written here, being in the state of sending connectable undirected advertising, communication is possible ONLY if  "the successful resolution" InitA field.

            Apparently you missed the beginning of this post?

            Or should your answer be understood as the fact that Cypress in this part decided not to follow the standard?

             

            Thnx.