BLE 4.2 RPA and connection not expected behavior

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
VaIk_2708246
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

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.

0 Likes
1 Solution

Hello,

Cypress products follows the BLE spec standards. When an advertiser receives a connection request that contains a resolvable private address for the initiator’s address, the Link Layer will resolve the private address if it has the required keys already stored. You can refer to the Code Example 'BLE_4.2_Datalength_Security_Privacy' ( PSoC Creator-> File-> Code Example) in the PSoC Creator for more information. In this code example, initially the GAP Peripheral advertises with a public address. When it is connected to a BLE Dongle (GAP Central device), the GAP Peripheral initiates an authentication request, and a key exchange happens between the GAP Central and GAP Peripheral devices. After the key exchange and authentication are complete, the GAP Peripheral stores the peer device’s information in the flash memory (bonding).

After bonding is complete and the GAP Peripheral is disconnected, the device starts advertising with a random address which is a resolvable private address. This address can be resolved by a GAP Central device if it has the required keys (specifically, the Identity Resolving Key or IRK). Only a GAP Central device which has the corresponding IRK can successfully resolve the private address of the GAP Peripheral and identify if this GAP Peripheral is the same as the one it connected to earlier.

Thanks,

P Yugandhar.

View solution in original post

0 Likes
3 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

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.

pastedImage_4.png

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.

0 Likes

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.

0 Likes

Hello,

Cypress products follows the BLE spec standards. When an advertiser receives a connection request that contains a resolvable private address for the initiator’s address, the Link Layer will resolve the private address if it has the required keys already stored. You can refer to the Code Example 'BLE_4.2_Datalength_Security_Privacy' ( PSoC Creator-> File-> Code Example) in the PSoC Creator for more information. In this code example, initially the GAP Peripheral advertises with a public address. When it is connected to a BLE Dongle (GAP Central device), the GAP Peripheral initiates an authentication request, and a key exchange happens between the GAP Central and GAP Peripheral devices. After the key exchange and authentication are complete, the GAP Peripheral stores the peer device’s information in the flash memory (bonding).

After bonding is complete and the GAP Peripheral is disconnected, the device starts advertising with a random address which is a resolvable private address. This address can be resolved by a GAP Central device if it has the required keys (specifically, the Identity Resolving Key or IRK). Only a GAP Central device which has the corresponding IRK can successfully resolve the private address of the GAP Peripheral and identify if this GAP Peripheral is the same as the one it connected to earlier.

Thanks,

P Yugandhar.

0 Likes