Resolving random private address ... where is the IRKs array?

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Mon, 20 May 2019 21:02:46 GMT

Final update:

After reading this post ...

https://devzone.nordicsemi.com/f/nordic-q-a/9612/reading-irk-and-gap_evt-params-connected-irk_match-issue

… I realized that I have to wait for BLE_GAP_EVT_SEC_PARAMS_REQUEST and BLE_GAP_EVT_AUTH_STATUS in my dm_ble_evt_handler() function in device_manager_peripheral_custom.c

Now I know that the IRKs are in m_peer_table[handle.device_id].peer_id.id_info.irk array

I have checked that auth_status is BLE_GAP_SEC_STATUS_SUCCESS and addr_type really is BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE

Please notice that ...

p_ble_evt->evt.gap_evt.params.connected.irk_match

and

p_ble_evt->evt.gap_evt.params.connected.irk_match_idx

... may both be 0 ... if no whitelisting is used (which is my case).

Thanks!

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Mon, 20 May 2019 20:53:14 GMT

Hi Runar,

I have decided to close this issue and open a new one about "not getting the expected resolved address". The initial intent of this post was to find the IRKs and that has been achieved. Thanks!

Gil

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Thu, 16 May 2019 17:54:48 GMT

I guess it's just ignoring the 3 bytes of the manufacturer's ID? Is that right?

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Thu, 16 May 2019 17:33:30 GMT

Hi Runar,

I looked at that function and it's similar to the decypher_address that I use. I also started with an example that compares the decrypted highest 3 bytes of the address with the lower 3 bytes. I don't understand that. The result is not what I expected, i.e. a decrypted 6-byte address. Why does it do that? Why doesn't it provide a full 6-byte decrypted address? I'm confused. Thanks!

Cheers,

Gil

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Thu, 16 May 2019 16:28:00 GMT

Hi Runar

The Android tablet's Bluetooth MAC address is 80 4E 70 0F 05 9C

The passed structure:

The received randomized address is (ten 00 then) 7E 82 66 88 8F D8

The received key is 25 29 EF 50 0B 2C 45 66 85 16 95 65 0C D3 AE 1C

The result is (ten "don't care" then) 00 8B D1 34 EA BF .. which does not match the MAC 😞

I will try the im_address_resolve() that you suggested and will let you know... Thanks!

Cheers,

Gil

RE: Resolving random private address ... where is the IRKs array?

run_ar — Thu, 16 May 2019 14:04:54 GMT

Hi,

There is a function called im_address_resolve in id_manager.c (belongs to the peer manager in sdk 11) that you might be able to check against to see if you get the correct address.

You will only get an IRK match on the connected event if you are using the whitelist and the address matches the whitelist. So enabling the whitelist would also be a way to identify the peer.

Which address are you checking against by the way? have you stored the identity address?

RE: Resolving random private address ... where is the IRKs array?

Guilherme de Paula — Wed, 15 May 2019 22:08:58 GMT

Update:

After reading this post ...

https://devzone.nordicsemi.com/f/nordic-q-a/9612/reading-irk-and-gap_evt-params-connected-irk_match-issue

… I realized that I have to wait for BLE_GAP_EVT_SEC_PARAMS_REQUEST and BLE_GAP_EVT_AUTH_STATUS in my dm_ble_evt_handler() function.

So I moved my code there, and modified it:

void decypher_address(uint8_t * p_random, uint8_t * p_real, uint8_t * p_irk_array)
{
  nrf_ecb_hal_data_t encryption_data = {0};
  uint32_t errcode;
  uint8_t i;

  /* Reverse the array as the ECB expect it in big endian format */
  for (i=0; i<sizeof(encryption_data.key); i++)
  {
    encryption_data.key[i] = p_irk_array[sizeof(encryption_data.key)-1-i];
    if (i < 6)
    {
      encryption_data.cleartext[15-i] = p_random[i];
    }
  }

  errcode = sd_ecb_block_encrypt(&encryption_data);
  if(errcode)
  {
    ASSERT(false);
  }
  
  for (i=0; i<6; i++)
  {
    p_real[i] = encryption_data.ciphertext[15-i];
  }
}

void dm_ble_evt_handler(ble_evt_t * p_ble_evt)
{

...

        case BLE_GAP_EVT_AUTH_STATUS:

...

      ble_gap_addr_t tmp_addr;
      uint8_t idx = p_ble_evt->evt.gap_evt.params.connected.irk_match_idx;

//      if (p_ble_evt->evt.gap_evt.params.connected.irk_match)
      {
          decypher_address((uint8_t *)m_connection_table[idx].peer_addr.addr,
                                     tmp_addr.addr, 
                                     m_peer_table[handle.device_id].peer_id.id_info.irk);

          g_ble_conn_stats.central_mac0  = tmp_addr.addr[5];
          g_ble_conn_stats.central_mac1  = tmp_addr.addr[4];
          g_ble_conn_stats.central_mac2  = tmp_addr.addr[3];
          g_ble_conn_stats.central_mac3  = tmp_addr.addr[2];
          g_ble_conn_stats.central_mac4  = tmp_addr.addr[1];
          g_ble_conn_stats.central_mac5  = tmp_addr.addr[0];
      }
/*
      else
      {
          g_ble_conn_stats.central_mac0  = 0;
          g_ble_conn_stats.central_mac1  = 0;
          g_ble_conn_stats.central_mac2  = 0;
          g_ble_conn_stats.central_mac3  = 0;
          g_ble_conn_stats.central_mac4  = 0;
          g_ble_conn_stats.central_mac5  = 0;
      }
*/

...

}

Now I know that the IRKs are in m_peer_table[handle.device_id].peer_id.id_info.irk array

but the resolved MAC address does not match the Android tablet's MAC address. 😞

I have checked that auth_status is BLE_GAP_SEC_STATUS_SUCCESS and addr_type really is BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE

Please notice that ...

p_ble_evt->evt.gap_evt.params.connected.irk_match

and

p_ble_evt->evt.gap_evt.params.connected.irk_match_idx

... are both 0 ... I don't know if that is a problem.

Thanks!