CC2642R: OOB Secure Connections DH Key Check Failed (1-Way OOB + Privacy)

Hello Marco,

Thank you for sending the capture. Looking through the packets, the DH key check is failing because your central is sending the well-known BLE debug keypair but your peripheral is using a real keypair. Set secure connections host debug mode to the same value on both devices, either both debug or both real keys.

Best,
Josh Alderson

Hello Josh,

I disabled debug keys on the Central so both devices are forced to use real keypairs. However, the pairing is still failing with a DH Key Check Failed at the exact same spot.

I have attached the updated Ellisys trace. As you will see, both sides are now successfully exchanging Regular Public Keys, but the math is still breaking during Authentication Stage 2.

To give you the exact context, we have shifted to a 1-Way NFC + ATT OOB architecture:

1. NFC Exchange: The Central (TI) sends its Identity Address and IRK to the Peripheral via NFC. The Central does not receive the Peripheral's data in return.

2. Connection: The Peripheral starts Directed Advertising. Controller Privacy is ENABLED on the TI device (ADDRMODE_RP_WITH_RANDOM_ID), so it connects using a temporary RPA.

3. ATT Exchange: After connection, the TI device sends its local OOB Confirm and Random values to the NXP device over the BLE link via an ATT Write Command.

4. Pairing: SMP Secure Connections pairing initiates.

Best Regards

dhkey_check_failed_issue_regular_key.zip

Hi Marco,

There is a key mismatch when the DH key check is happening. This might be happening due to NXP using the identity address from the NFC instead of TI's RPA.
The central will use the RPA it used when pairing in the calculation for the DH key check.

The exact information I need is not displayed in the ellisys log so I can't look at the exact values to verify.
Check what address the NXP device is using when doing the f6 part of DH key checks and see if it matches the RPA address of the TI device used when pairing.

These sections of the 6.2 bluetooth spec provide more information on what is used in the computation for DH key checks. Vol 3, Part H, Section 2.2.8 and Vol 3, Part H, Section 3.5.7
 

Best,
Josh

Hello Josh,

To give you the exact context of how this mismatch is happening, here is our current architecture:

1. NFC Tap: The Central (TI) sends its Static Identity Address and IRK to the peripheral via NFC.

2. Connection: The peripheral uses that data to start Directed Advertising. The Central (TI) connects. Because ADDRMODE_RP_WITH_RANDOM_ID is active, the Central connects using a temporary RPA.

3. ATT OOB Exchange: Over the BLE link, both devices exchange their OOB Confirm and Random values via ATT.

4. Pairing: SMP Secure Connections pairing initiates. The Central has GAPBOND_OOB_ENABLED = TRUE and we feed the peripheral's Confirm/Random values into the stack.

To clarify why we believe the peripheral is behaving correctly, we have to look back at our previous architecture. When we previously used a 2-Way NFC exchange, the pairing succeeded perfectly(exchanging IRKs and Identity addresses).

Because we explicitly hand the TI device's true Identity Address to the peripheral over a secure out-of-band channel (NFC) to authorize the connection, the peripheral logically prioritizes that trusted Identity Address over the temporary over-the-air RPA for its $f6$ cryptography. This is the expected behavior for a strict OOB trust model.

The mismatch is happening because the CC2642R's GAPBondMgr defaults purely to the radio link's RPA, rather than using its own base Identity Address to match the OOB context we established.

Best regards,

Marco Magdy

Hello Josh,

I checked our peripheral's cryptographic engine at the exact moment it constructs the Initiator and Responder address buffers for the Secure Connections pairing hashes (the f5 and f6 algorithms).

The results confirm that the peripheral is correctly using the over-the-air RPAs, not the Identity Addresses.

• Directed Test (Directed_addresses.png, dhkey_check_failed_issue_regular_key_mac_directed.btt):

  • Ellisys Log: Central RPA is 65:C7:37:0E:C3:62 | Peripheral RPA is 61:CB:71:96:4F:AD

  • Peripheral Crypto Inputs: Initiator Address = 0x65, 0xC7... | Responder Address = 0x61, 0xCB...

• Undirected Test(Undirected_addresses.png, dhkey_check_failed_issue_regular_key_mac_undirected.btt):

  • Ellisys Log: Central RPA is 6F:BC:AA:EA:31:DE | Peripheral RPA is 52:C1:2A:B1:7C:6D

  • Peripheral Crypto Inputs: Initiator Address = 0x6F, 0xBC... | Responder Address = 0x52, 0xC1...

    Debug_Files.zip

Hello Marco,

Thank you for the information, this will help narrow down the root cause.
I am still looking into this and will reply as soon as I can with more information.

Best,
Josh

Hello Marco,

Thanks for your patience.
Looking more into it, it looks like the addresses passed in on the NXP should be correct as you pointed out.
There is a possibility that the TI RPA is rotating during the process and the wrong RPA could be stored and used for SMP key checks on the TI side.
Could you try disabling RPA rotation on the TI device and testing the SMP connection again for me to rule this out?
Something like GAP_SetParamValue(GAP_PARAM_PRIVATE_ADDR_INT, 0xFFFF);  should do the trick.

Best,
Josh

Hello Josh,

No problem, thanks for your assistance.

I tried this one and it doesn't work either. Kindly check the Ellisys logs attached.

Best regards,

Marco

dhkey_check_failed_issue_regular_key_mac_directed_addr.zip