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.

  • TI Thinks Resolved

CC2540: CVE-2019-2102 - LTK authentication problem

Prodigy 195 points

Replies: 11

Views: 261

Part Number: CC2540


we still have several CC2540 devices active. Since latest Windows 1903 update microsoft blocks devices using a known LTK see:

It apreas our devices are affected.

We use:

Bonding = true

MITM = true

PassKey = "XXXXX"

To be more precise:

- we are using Stack

- not all devices are affected - it seems it is mainly a 2016 production line (but not all devices) - are there any known problems about those chips?

- the error occurs when we first pair one device - then a second - we can see the error in the windows event log and seconds device wont get paired

- if we do it the other way round we also can pair one device and we get an error on the second

- other devices from same production line still work fine - it might be MAC address related? Is the LTK based on the MAC?

As stated here:

"You can find the following sentence in our software developer's guide, section 5:
"Most of the Bluetooth low energy protocol stack is object code in a single library file (TI does not provide
the protocol stack source code as a matter of policy). A developer must understand the functionality of the
various protocol stack layers and how they interact with the application and profiles. This section explains
these layers."

TI's BLE STACK takes care of the LTK generation and make sure the distribution follows the Bluetooth Specification. Users do not need to worry about the LTK generation while using pairing and bonding feature in our BLE STACK."

It seems we can't affect LTK creation - even this is not for the CC254x i assume it will be te same?

Still the question is - how can we fix that?

Help is needed urgent!

Customers are angry & devcies don't work anymore!


  • Guru 57705 points

    Hi Frederik,

    Assigning one of the experts to look into the details asap. Stay tuned.

    Regards, Joakim


  • In reply to J Lindh:

    Hi Joakim,

    thanks for your help - meanwhile we also spottet a 2017 production line in wich even more sensors are affected!

    So devices produced in 2016 seem to have same LTK sometimes - and devices produced in 2017 have same LTKs.

    Interesting enough different procution line don't block eachother.

    So for the devices having that problem we are seeing:

    - Pair 1 device 2016 - works

    - Pair 2 devices 2016 - fails - 1 gets paired - 2nd will fail (always the first pairing attempt is successful)

    - Pair 1 device 2017 - works

    - Pair 2 devices 2017 - fails - 1 gets paired - 2nd will fail (always the first pairing attempt is successful)

    - Pair 1 device 2016 & 1 device 2017 - works !!!

    Windows blocks a device if there is already another paired device with same key since update 1903.

    We tested this with 18 devices from 2017 prodcution line - 11 seem to create same LTK (can't be paired together anymore) - 7 devices still work as expected

    Further more we can rule out that the problem is receiver related since we tested this with two BCM20702 chipset devices & 1 CSR device.

    Also it is not PC dependent - we could reproduce the problem with the same affected sensors on 3 PCs having latest 1903 udpate.

    We also investigated the problem with BTool & an Nordic receiver - were we COULD NOT see that the devices produce the same LTK - still in windows environment we can't pair them anymore.

    Next step here is sniffing the pairing process...

    Even the above mentioned microsoft article tells windows will create error 22 we get error 35!

    Protocolname: System
    Source: BTHUSB
    ID: 35
    Das Gerät (xx:xx:xx:xx:xx:xx) versucht, einen Identitätsauflösungsschlüssel zu verteilen, der bereits von einem gekoppelten Gerät verwendet wird. Das Pairing wurde abgelehnt. Wenn Sie beabsichtigen, mit diesem Gerät zu koppeln, müssen Sie möglicherweise zuerst die vorhandenen Pairing-Informationen löschen.

    (sry german pc)

    So the problem is not exacly the described one (default key) but more that microsoft also added a new block for devices wich create same LTK & that seems to happen.

    If you need the HW IDs for investigation please PM me.


  • In reply to Frederik:

    Hi Fredrik,

    According to my translation the error message is something like:

    The device (xx: xx: xx: xx: xx: xx) attempts to distribute an identity resolution key that is already being used by a paired device. The pairing was rejected. If you plan to pair with this device, you may need to clear the existing pairing information first.

    1) Are you using bonding?

    2) If you are - is the bonding information erased on any of the devices before the second (failing) pairing attempt? (Seems like this could happen is if bonding information is erased on one device but not the other)

    3) Do you use MITM, what are the I/O capabilities on the devices (what kind of pairing is used)?

    4) When you say 2016 production line  and 2017 production line, are all the devices using the same software (BLE Stack

    Marie H.

  • In reply to Marie H:

    Hi Marie,

    the translation doesn't sound too bad - you might be right that windows is complaining about the same IRKs while pairing a 2nd device not LTKs.

    According to:

    "The probability that two devices will have the same IRK and generate the same random number is low, but not absolute."

    If that is the problem - how could we fix it? Im not aware of any special privacy functions in our FW? Our devcies are connectable via public address.

    1) Yes

    2) We dont erase any bonding information on the sensor manualy

    Our Firmware is fully based on SimpleBlePeripheral - nothing aditional - BondMgrCBs = NULL

    // GAP Bond Manager Callbacks
    static gapBondCBs_t simpleBLEPeripheral_BondMgrCBs =
    NULL, // Passcode callback (not used by application)
    NULL // Pairing / Bonding state Callback (not used by application)


    uint32 passkey = XXXXXX;
    uint8 mitm = TRUE;
    uint8 bonding = TRUE;

    4) When you say 2016 production line  and 2017 production line, are all the devices using the same software (BLE Stack

    Yes - latest FW for all product lines is based on - but I even tested with an old 1.4.0... stack FW -> same results


  • In reply to Frederik:

    Yes I can confirm the IRK is the same for some devices!

    I just tested 3 devices from the 11 "non working ones" & 1 from the "working ones" with BTool

    The 3 devices all have the same IRK !

    The wokring one has another IRK !

    Sorry I wasn't aware of the IRK yet since we don't use private address / privacy functions.

    So it seems windows blocks devices with same IRK from 1903 update !

    In It is stated the IRK will be randomly generated if it is set all 0s.... we don't explicitly set this value.

    1) What would happen if i set this to 0 at startup? Will it be random at each startup -> Change with each startup?

    2) Woudl 1) be a problem for already bonded devices (since it would change again AFTER the central saved that key already)? (Would it be spec conform?)

    3) How is the current process for IRK generation if we dont set this up explicitly ? (= our FW = SimpleBlePeripheral)

    4) So why so many devices !!! 11 of 18 !!! randomly choosen devices have the same IRK? Is it a bug? According to the source mentioned above it should rarely happen... [We also tried some devices form 2016 series - there it happened to 3 of 7 devices - so I guess this happens a lot]

    5) How can we change the IRK generation to fix this problem?


  • In reply to Frederik:

    Hi Frederik,

    1) The IRK is stored in NV, so it will only be set once. On startup it is read from NV. (See peripheral.c.) If you want a new IRK at startup you would have to intentionally overwrite the SNV BLE_NVID_IRK area.

    2) No, since you are not using privacy the IRK isn't really being used. (I am not sure whether the spec explicitly forbids this.)

    3) IRK is generated by using the RFPSRND register. You can see the document you linked (swru191), chapter 25.10 Random Number Generation.

    4) Here I need to get back to you.

    5) Yes, you can manually assign different IRKs to the devices.

    - Alternatively, since you are not using Privacy you could try altering the Pairing response packet not to include the IRK. 

    - You should also manually delete all paired devices under the Bluetooth settings menu in Win10 before starting the test.

    Marie H.

  • In reply to Frederik:

    Hi Fredrik,

    Did you figure it out?

    I will close this thread due to inactivity.

    Marie H.

  • In reply to Marie H:

    Hi Marie,

    I still was hopping for an answer to 4) since this seems to be the main problem & it still exists... As soon as we understand the reason we can fix it properly.


  • In reply to Frederik:

    Hi Fredrik,

    I would expect each device to have a new IRK. Are you programming his devices from an image that contains the OSAL NV image of a ‘golden’ unit that previously computed and stored it’s IRK? (This can be ruled out if you reprogram simpleBLEperipheral on the device, then use the CC debugger to check the return value from the associated NV read of the IRK and GAP DeviceInit, if the NV value is read as all FF’s. GAP DevInit should give you a “random” IRK. )

    Marie H.

  • In reply to Marie H:

    We currently dont do that but create one SuperHex by joining images. But it might be that way in older production lines. Will check an come back to you...

    Thanks for the hint. Still I'm not sure since we also have devices with different keys from same production as well. So either all devices should be affected or none? Any other suggestions?


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.