How does Identity Resolving Key work? Why does LESC only work when IRK is set to true(zephyr)?

We are using PC-BLE-DRIVER-JS for our central and zephyr in our peripheral  (833).
The central bonded with the peripheral only when the id (IRK) param in our central is set to true.
If IRK set to false the central will not bond with the peripheral.

Only on zephyr we needed to set it to true, on NRF52 we didnt need to set it.

How does IRK work? Why must it be set to enable bonding sec parameters?

code snap(from our central, on authenticate method):

:

    const secParamsCentral: SecurityParameters = {
      bond: true,
      mitm: true,
      lesc: true,
      keypress: false,
      // eslint-disable-next-line camelcase
      io_caps: this.adapter.driver.BLE_GAP_IO_CAPS_KEYBOARD_ONLY,
      oob: false,
      // eslint-disable-next-line camelcase
      min_key_size: 7,
      // eslint-disable-next-line camelcase
      max_key_size: 16,
      // eslint-disable-next-line camelcase
      kdist_own: {
        enc: true /** Long Term Key and Master Identification. */,
        id: true /** Identity Resolving Key and Identity Address Information. */,
        sign: false /** Connection Signature Resolving Key. */,
        link: false /** Derive the Link Key from the LTK. */,
      },
      // eslint-disable-next-line camelcase
      kdist_peer: {
        enc: true /** Long Term Key and Master Identification. */,
        id: true /** Identity Resolving Key and Identity Address Information. */,
        sign: false /** Connection Signature Resolving Key. */,
        link: false /** Derive the Link Key from the LTK. */,
      },
    };

  • Hi Simon,
    CONFIG_BT_PRIVACY is 'n' by default, my issue is with the IRK and not RPA.
    But I did try it and in addition set IRK to false on central side(typescript) and LESC didnt work.
    The LTK is all zero after first pairing(when trying to connect)
    Our nRF Connect SDK is : 2.2.0

    after pairing I am trying to bond and the ltk on central side is array of 0:

    debug: [libs\bleAdapter] encrypt {"ediv":0,"rand":[0,0,0,0,0,0,0,0]} {"ltk":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"auth":false,"ltk_len":0,"lesc":false}
    debug: [logic\ble] securityRequest {"id":30,"name":"BLE_GAP_EVT_SEC_REQUEST","time":"2023-06-18T13:59:35.371Z","conn_handle":0,"bond":true,"mitm":true,"lesc":true,"keypress":false}
    debug: [libs\bleAdapter] dataLengthUpdateRequest {"max_rx_octets":251,"max_tx_octets":251}
    info: [logic\centralDB] ReportWatchDogMethods saving disconnect Mac to DB.
    error: [logic\ble] deviceDisconnected Device <MAC ADDRESS> disconnected incorrectly (BLE_HCI_CONNECTION_TIMEOUT : 8)

  • Hi Ben

    I've asked around as I wasn't able to make sense of this reply, and neither does my colleagues I'm afraid. Are you able to provide a sniffer log so we can see what's going on over the air here? Either with a dedicated Bluetooth sniffer, or a second nRF52 DK running the nRF Sniffer application and Wireshark to capture on-air packets. That should help us get a better view of what's going on here.

    Best regards,

    Simon

  • Hi Ben, I got the same issue, after some investigation, it appears that the tools developed during the time of NRF5 SDK were using LE legacy pairing. Both Bluetooth v5.1 (old SDK) and v5.3(Zephyr) specified that for LESC, only IRK (if you will use RPA) and CSRK can be distributed not LTK (this should not be shared at all for security) during pairing(phase 3). Also IRK is not mandatory for LESC according to Bluetooth 5.3 Core spec Vol 3 Part H section 2.4.3.2 i.e., you can still achieve LESC either you are using RPA or not (CONFIG_BT_PRIVACY=n). When you are using RPA(CONFIG_BT_PRIVACY=y) that's the time IRK will be distributed to the master according to Bluetooth v5.3/v5.1 Core spec Vol 3 Part C section 9.4.4.2. 

Related