This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LP-EM-CC2340R5: Queries - CAR and RPAO characteristics

Part Number: LP-EM-CC2340R5
Other Parts Discussed in Thread: SYSCONFIG, CC2340R5

Hi, 

I am using CC2340 Basic BLE example. 

From CC2340 BLE guide, peripheral device should set RPA in TargetA field of directed advertisement if central device enabled CAR (Central Address Resolution) characteristics and support it. 

I have 2 queries related to this Characteristics

  1. I am using my phone as central device, when reading bond record using GapBondMgrReadBondRec  API, the bond record flags shows no CAR and no RPAO. Even if there is no CAR and no RPAO characteristic, CC2340 uses RPA in TargetA field of directed advertisement. Why this behaviour?
  2. Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?

Regards,
Prince

  • Hello Prince,

    Please first help me answering the following questions:

    1. When are you calling the GapBondMgrReadBondRec API function? A code snippet of the section would be helpful.
    2. Are you reading pBondRec, what are the flag values that show no CAR and no RPAO?

    BR,

    David.

  • Hi David,

    When are you calling the GapBondMgrReadBondRec API function? A code snippet of the section would be helpful.

    Are you reading pBondRec, what are the flag values that show no CAR and no RPAO?

    Yes, I am reading this flag values. The flag value is 0x08 (GAP_BONDED_STATE_SECURECONNECTION).

    Regards,
    Prince

  • Hello Prince,

    Is it possible to provide a Bluetooth sniffer log for this situation?

    I need to double check what the GAP_BONDED_STATE_SECURECONNECTION flag is actually making a reference to.

    BR,

    David.

  • Hi David,

    I am using CC2642 as sniffer and it can sniff packets up to CONN_IND packet. So its not possible to send an sniffer log. 

    I need to double check what the GAP_BONDED_STATE_SECURECONNECTION flag is actually making a reference to.

    We are enabled Secure Connection as supported in sysconfig. I think thats why we getting this flag. When we set GAPBOND_SECURE_CONNECTION_NONE to gapbond manager we getting flag as 0.

    Regards,
    Prince

  • Hello Prince,

    Understood.

    To make sure we on the right track, could you please confirm you are following this procedure as reference: Extract Bonding Information. Apologies for not mention it earlier. This to make sure we are getting the peer related info (type and address) correctly (at the BLEAPPUTIL_LINK_ESTABLISHED_EVENT event for example) before calling gapBondMgrReadBondRec().

    When we set GAPBOND_SECURE_CONNECTION_NONE to gapbond manager we getting flag as 0.

    In this case do you still get CAR and RPAO flags as disabled?

    BR,

    David.

  • Hi David,

    To make sure we on the right track, could you please confirm you are following this procedure as reference: Extract Bonding Information.

    Yes, we are following the same.

    In this case do you still get CAR and RPAO flags as disabled?

    Yes.

    Regards,
    Prince

  • Hello Prince,

    Thanks. Looking further into the code (gapbondmgr.c).

    The functions that sets CAR and RPAO flag values are:

    1. gapBondMgrReadRPAORsp() -> Set Bond Resolvable Private Address only flag for this connection
    2. gapBondMgrReadCARRsp() -> Set Central Address Resolution state flag for this connection

    And both are called from the gapBondMgr_ProcessGATTMsg() function which processes an incoming GATT message. This is not defined by the type of advertisement being directed or not.

    gapbondmgr.c

    BR,

    David.

  • Hi David,

    Here we attaching 2 statements from CC2340 BLE User Guide .

    1. Per the Bluetooth Core Specifications Version 5.3, the peripheral device must read the CAR characteristic if it wishes to send a Directed Advertisement when it uses an RPA. The BLE5-Stack reads this characteristic if the local device is a Peripheral that has bonded to a peer using an RPA. This characteristic is checked by GapAdv_enable() when attempting to send directed advertisements in the BLE5-Stack.
      • In our case the CAR characteristics is not present on central side. And peripheral sending directed advertising using RPA.
      • Shall the CC2340 use direct advertisement with peer device identity address as targetA field, if CAR characteristics not present in peer device?
    2. The RPAO is read automatically by the GAP Bond Manager if it has bonded to a peer using a private address. If a GATT_MSG_EVENT with an ATT_READ_BY_TYPE_RSP with a value of ‘0’ is generated, then the Host sets the peer in Network Privacy mode.
      • Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?
      • We wanted to test our peripheral's privacy mode.
      • But we don't have any option to send any command using identity address, if we enabled privacy.
      • Is there any API provided by CC2340 BLE stack, if we want to send a command using identity address?

    Regards,
    Prince

  • Hello Prince,

    Apologies for the delay.

    1. I am working on reproducing this on my side to double check if the CAR related status is not set, to make sure this is not because we are reading characteristics incorrectly.
    2. What type of test you want to implement? You can use HCI commands that work with the Identity Address (HCI_LE_ReadPeerResolvableAddressCmd(), HCI_LE_ReadLocalResolvableAddressCmd() for example). For this you can flash the host_test example from the SDK (\examples\rtos\LP_EM_CC2340R5\ble5stack\hexfiles) and try them after paring has been implemented.

    BR,

    David.

  • Hi David,

    We would like to send a scan request connection request using identity address from BLE central side after pairing and bonding. 
    Can we instruct stack to use identity address instead of local RPA ? I looked through HCI commands, but no APIs found .

    Regards,
    Prince

  • Hello Prince,

    After the devices bond, they are able to resolve the RPA address to the identity address. So the central can use its RPA address and the paired peripheral will then be able to resolve the address to the identity. From a privacy perspective I don't understand what case would require to use the identity address again after bonding. You could change the addressing mode during runtime but is this required for new connections?

    BR,

    David.

  • Hi David,

    What type of test you want to implement?

    I was answering this question.

    If we are able to send a CONN_IND packet using identity address, we can know whether our peripheral device will accept the CONN_IND packet or not. In this way we can test our peripheral device is in device privacy mode or network privacy mode.

    Regards,
    Prince

  • Hello Prince,

    Have you tried looking for GATT_MSG_EVENT with an ATT_READ_BY_TYPE_RSP and see if the value is '0' for network privacy mode and GATT_MSG_EVENT response with a ATT_ERROR_RSP or a ATT_READ_BY_TYPE_RSP with a non-zero value for device privacy mode?

    You can see this events are generated at bleapputil_task.c and that the BLEAppUtil_processGATTEvents function will look for the ATT specific where you can check up the value after bonding.

    You can also see with a bluetooth sniffer if they are in privacy mode as well.

    Best Regards,

    David.

  • Hi David,

    Have you tried looking for GATT_MSG_EVENT with an ATT_READ_BY_TYPE_RSP and see if the value is '0' for network privacy mode and GATT_MSG_EVENT response with a ATT_ERROR_RSP or a ATT_READ_BY_TYPE_RSP with a non-zero value for device privacy mode?

    This is for RPAO characteristics, right?

    Shall the CC2340 use direct advertisement with peer device identity address as targetA field, if CAR characteristics not present in peer device?
    Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?

    Can you help me on getting answer for these 2 queries ? 

    Regards,
    Prince

  • Hello Prince,

    Yes, it is for RPAO and to check for privacy mode.

    Shall the CC2340 use direct advertisement with peer device identity address as targetA field, if CAR characteristics not present in peer device?

    A peer CAR characteristic must be read/checked by the peripheral if it wants to send a Directed Advertisement when it uses an RPA. This characteristic is checked by the stack inside BLEAppUtil_advStart() by the GapAdv_enable() function. The CAR characteristic defines whether the device supports privacy with address resolution. Therefore it should be present to start a directed adv with targetA field as RPA.

    Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?

    So, the privacy mode will reduce the ability for an unwanted scanner to track devices over a period of time by periodically generating a new address to use over the air. However, this addresses are generated using the IRK which is exchange over the air during the paring process. For example, if the IRK is known by a unwanted third-party, then it can be possible for it to resolve the address and track the device. Using Out of Band key exchange can be a way of avoiding this and having Man in the Middle protection.

    BR,

    David.

  • Hi David,

    I am using my phone as central device, when reading bond record using GapBondMgrReadBondRec  API, the bond record flags shows no CAR and no RPAO. Even if there is no CAR and no RPAO characteristic, CC2340 uses RPA in TargetA field of directed advertisement. Why this behaviour?

    This is our original query.

    A peer CAR characteristic must be read/checked by the peripheral if it wants to send a Directed Advertisement when it uses an RPA. This characteristic is checked by the stack inside BLEAppUtil_advStart() by the GapAdv_enable() function. The CAR characteristic defines whether the device supports privacy with address resolution. Therefore it should be present to start a directed adv with targetA field as RPA

    This is your reply. So can you please clarify why CC2340 uses RPA in TargetA field of directed advertisement ?

    The document only specifies the CAR characteristics should be present in Central. It doesn't specify anything about negative cases(our example).

    Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?

    The device privacy mode is within the privacy feature. We can divide privacy of a device into two.

    1. Network Privacy Mode

    2. Device Privacy Mode

    This is statement from CC2340 BLE User Guide

    The RPAO is read automatically by the GAP Bond Manager if it has bonded to a peer using a private address. If a GATT_MSG_EVENT with an ATT_READ_BY_TYPE_RSP with a value of ‘0’ is generated, then the Host sets the peer in Network Privacy mode.

    However, if a GATT_MSG_EVENT response with a ATT_ERROR_RSP or a ATT_READ_BY_TYPE_RSP with a non-zero value is generated, then the Host will interact with the device in Device Privacy Mode.

    In our case central device doesn't have this RPAO characteristic. Thats why we ask is there any issue with Device Privacy Mode.

    Regards,
    Prince

  • Hello Prince,

    I think we first need to double check that the CAR and RPAO characteristics are being properly saved by looking into the previous functions that I mention earlier (gapBondMgrReadRPAORsp() -> Set Bond Resolvable Private Address only flag for this connection and gapBondMgrReadCARRsp() -> Set Central Address Resolution state flag for this connection). If this is the case then there may be something we are missing when doing gapBondMgrReadBondRec() when receiving BLEAPPUTIL_PAIRING_STATE_BOND_SAVED event, but will confirm that RPAO and CAR are actually enabled.

    To do this I would ask you to please do the following. It should be similar to what you already have and is based on the user guide:

    1. Initiate a connection and make sure to bond with the central device.
    2. Include the "gapbondmgr.c" file (you can find it inside <SDK>\source\ti\ble5stack_flash\host\gapbondmgr.c).
    3. Inside you will find the gapBondMgr_ProcessGATTMsg() function that processes incoming GATT messages. Here two events will trigger the tasks/functions of storing RPAO and CAR in bond record, GBM_STATE_WAIT_GATT_RPAO and GBM_STATE_WAIT_GATT_CAR respectively.
    4. Set a break point to each case to check for RPAO and CAR functions (gapBondMgrReadRPAORsp and gapBondMgrReadCARRsp).
    5. Double check that a "BLEAPPUTIL_PAIRING_STATE_BOND_SAVED" event flag is generated. If using basic_ble, a message will state this through the serial monitor ("Pairing Status: Bond saved").

    BR,

    David.

  • Hi Prince,

    Jumping in here a little late, but I believe you may be looking for this:

    I am using my phone as central device, when reading bond record using GapBondMgrReadBondRec  API, the bond record flags shows no CAR and no RPAO. Even if there is no CAR and no RPAO characteristic, CC2340 uses RPA in TargetA field of directed advertisement. Why this behaviour?

    https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_7_20_01_10/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/privacy-cc23xx.html?highlight=car#bluetooth-5-1-privacy-additions

    This very well could be the reason you're seeing the TargetA field being populated with the RPA. The TargetA field and InitA field may need to be different for backwards compatibility. Do you have DONT_TRANSMIT_NEW_RPA defined in your project? If you do define this, do you see a difference in behavior?

    1. Is there any issues if we are using device privacy mode? By using this device privacy mode are we prone to any type of attacks?

    The difference between these two privacy modes is that network privacy mode will only accept peer requests using an RPA. Whereas device privacy mode will accept either. 
    The purpose of using an RPA is so that connections are harder to track. Ultimately, this means if device A cares about the connecting device B's privacy. I believe the question is whether you are concerned about the other device's security. 

    Let me know if that helps.

    Best,

    Nima Behmanesh

  • Hi David,

    We put breakpoints as you suggested. But these breakpoints are not invoked. Therefore we checked CAR and RPAO pairing state events by registering theses characteristics events in pairing state event handler. But this events not get invoked. Our mobile phone does have CAR characteristics (we don't know the value). But CAR characteristic event is also not getting invoked.

    But BLEAPPUTIL_PAIRING_STATE_BOND_SAVED event is getting invoked from pairing state event handler.

    Regards,
    Prince

  • Hi Nima,

    dev.ti.com/.../privacy-cc23xx.html

    I don't get it. InitA field described in this above link is from Connection Req packet. Our concern is about directed advertisement packet.

    In directed advertisement packet there are 2 fields. 1. AdvA field (advertiser's address), 2. TargetA field (peer device address).
    We are using privacy feature. Therefore in our case both fields are RPA.

    But based on BLE documentations, if CAR characteristics not present in Central role device means the BLE stack of Peripheral shouldn't use RPA on TargetA field. This is what we understood. Can you please tell us our understanding is right or wrong ?

    Do you have DONT_TRANSMIT_NEW_RPA defined in your project? If you do define this, do you see a difference in behavior?

    We defined this flag using sysconfig. But no change in behaviour. Here I configured RPA update time as 1 minute. 

    Behaviour when DONT_TRANSMIT_NEW_RPA flag not defined

    * RPA on AdvA field is getting updated as per configuration of RPA update time
    * RPA on TargetA field is getting updated only after a connection-disconnection

    Behaviour when DONT_TRANSMIT_NEW_RPA flag defined

    * RPA on AdvA field is getting updated as per configuration of RPA update time
    * RPA on TargetA field is getting updated only after a connection-disconnection

    Regards,
    Prince

    [/quote]
  • Hello,

    I believe I've found what's going on.

    In directed advertisement packet there are 2 fields. 1. AdvA field (advertiser's address), 2. TargetA field (peer device address).
    We are using privacy feature. Therefore in our case both fields are RPA.

    But based on BLE documentations, if CAR characteristics not present in Central role device means the BLE stack of Peripheral shouldn't use RPA on TargetA field. This is what we understood. Can you please tell us our understanding is right or wrong ?

    I'm seeing that the specification doesn't indicate what value should be used for the TargetA address should be in this case. The default way to handle this in our stack is to set the AdvA and TargetA fields as the same address. So what you're seeing here is the expected behavior.

    I'll double confirm this with the R&D team Monday and will let you know. 

    Best,

    Nima Behmanesh

  • Hi Nima,

    I'm seeing that the specification doesn't indicate what value should be used for the TargetA address should be in this case. The default way to handle this in our stack is to set the AdvA and TargetA fields as the same address. So what you're seeing here is the expected behavior.

    Are you telling that, by default stack is using RPA for both AdvA field and TargetA field if our application and peer application enabled privacy feature (without considering RPAO characteristics).

    Regards,
    Prince

  • Hi Prince,

    Still waiting on R&D for confirmation on this. Should have an update tomorrow morning.

    Best,

    Nima Behmanesh

  • Hi Prince,

    Quick update, I'll be meeting with a colleague from my team to find the exact behavior on this. 

    After testing myself, I'm unable to read the CAR or RPAO characteristics as well. 

    According to the spec, this characteristic should be read before sending a directed advertisement with RPA:

    What's not clear to me is how our stack handles this--whether or not we allow this behavior even if the characteristics were never read, or if the value of the characteristic is 0. 

    I'll get back to you on Wednesday.

    Best,

    Nima Behmanesh

  • Hi Prince,

    After speaking with my colleague, I believe we need to take a step back and understand the use-case here. Additionally, I'll need to see a log where a service discovery and characteristic discovery is occurring. These two discoveries is needed to receive the handle of the CAR characteristic.

    What is the purpose of using directed advertisements?

    What is the use-case?

    Best,

    Nima Behmanesh

  • Hi Nima,

    Additionally, I'll need to see a log where a service discovery and characteristic discovery is occurring.

    Is this about discovery for CAR and RPAO characteristics done by our application ?

    We don't have any sniffer that can capture BLE packets after a CONNECT_IND packet. We are using CC26x2 with Wireshark for packet sniffing and it can only sniff advertisement and CONNECT_IND packets. So it is not possible to share a sniffer log.

    What is the purpose of using directed advertisements?

    What is the use-case?

    By using directed advertisement our application can achieve faster connection to BLE Central side. BLE Central side can also save some power. It doesn't need to go through advertisement payload for a specific name or any IDs. For privacy concern we are using RPA. 

    Regards,
    Prince

  • Hi Prince,

    How can you tell when you need to advertise?

    Best,

    Nima Behmanesh

  • Hi Nima,

    Our application will start advertisement after a disconnection. After first connection, our application will get paired and bonded to peer side. Then after a disconnection our application will start to advertise using directed advertisements.

    Can we have further discussions on mail?

    Regards,
    Prince

  • Hi Prince,

    Yes that sounds good. Reach out to your FAE and we can get an email thread started.

    One note about directed advertisements--they do result in a quicker connection, at the cost of higher current consumption. We don't usually see directed advertisements used in keyfobs, since it's uncertain when the keyfob will be near enough for a connection. We can comment further on this topic in the email chain.

    In the meantime, I will close this thread, and will continue over email.

    Best,

    Nima Behmanesh