• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 255 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R-Q1: BLE Secure Connections issue

Tamas Kovago
Expert 3540 points

Part Number: CC2642R-Q1

We are investigating a BLE Secure Connections issue observed on a CC2642-Q1 device

.

During the pairing process, the HCI commands HCI_LE_READ_LOCAL_P256_PUBLIC_KEY (0x2025) and HCI_LE_GENERATE_DHKEY (0x2026) complete successfully; however, the overall pairing procedure eventually fails with SMP_PAIRING_FAILED_UNSPECIFIED (0x08).

 

To further isolate the issue, we bypassed the BLE stack and tested the cryptographic operation directly using ECDH_computePublicKey() with a fixed 32-byte private key via CryptoKeyPlaintext_initKey().

On multiple known-good boards, the ECDH computation consistently produces the same correct P-256 public key across runs and resets. However, on a specific unit, incorrect public key values are observed. Additionally, the faulty device produces different incorrect public keys from time to time for the same input, while the function still returns ECDH_STATUS_SUCCESS.

 

This is the first time we have encountered such a behavior in our system.

We would like to ask:

  • What internal mechanisms within the PKA engine could result in ECDH_computePublicKey() completing successfully while still producing corrupted or non-deterministic public key output?
  • What additional diagnostic methods or test procedures would you recommend to further isolate this issue at the hardware or driver level?
  •  
  • 0
    TI__Mastermind 41720 points

    Tamas,

    Do you have which version of the SDK the customer is using?

    How often is this issue occurring, is it occasionally or happening regularly?

  • 0
    Prodigy 30 points

    Hi Evan,

    The customer is using cc13xx_cc26xx_sdk_7_10_01_24.

    Regarding the frequency, this is the very first time we have encountered this issue on a board.

    Best Regards.

  • 0 in reply to Faruk D.
    TI__Mastermind 41720 points

    Hi there,

    To clarify, you have only seen the issue once and it's not a reproducible behavior? After the SMP Pariing Failure does the device recover cleanly on the next pairing attempt?

  • 0 in reply to Evan W
    TI__Mastermind 41720 points

    SMP_PAIRING_FAILED_UNSPECIFIED can happen for many reasons - through some quick review some of the following could cause it (not all inclusive):

    • confirm value is identical to the initiator confirm value 
    • if there is another pairing process ongoing the second one will fail
    • if certain keys are not calculated correctly

    To really narrow the issue down here, the issue would need to be reproducible reliably. 

  • 0 in reply to Evan W
    Prodigy 30 points

    To clarify, this issue is 100% reproducible on this specific defective unit. It occurs on every single pairing attempt with this board, and the device does not recover on subsequent attempts.

    When we say we have only seen it once, we mean that out of many identical boards we manufactured, only this one specific board exhibits this failure. On this single faulty unit, the SMP_PAIRING_FAILED_UNSPECIFIED (0x08) error occurs consistently and repeatedly during every pairing attempt.

  • 0 in reply to Faruk D.
    TI__Mastermind 41720 points

    Hi Frk,

    Thanks for the clarification. Do you think you could do an ABA swap to see if this problem follows the IC? Curious to me that it's only on a specific board. 

  • 0 in reply to Evan W
    Prodigy 30 points

    Yes, we performed an ABA swap test. We swapped the chip with one from a known-good board, and the failure followed the chip to the working board.