Resolved "private resolvable address" does not match Android tablet (central) MAC address

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Guilherme de Paula — Thu, 23 May 2019 16:13:20 GMT

Cool. Thanks! I understand the whole process now.

Cheers,

Gil

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Kenneth — Thu, 23 May 2019 08:49:28 GMT

Yes, the IRK is unique and won't change. So the peripheral do an address resolve calculation for any peer that try to connect (when whitelist is enabled) to identify if the peer should be allowed to connect or not. This is handled by the softdevice typically by supplying a list of IRK when advertisement is started from the application.

The IRK is received during bonding phase.

Best regards,
Kenneth

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Guilherme de Paula — Wed, 22 May 2019 16:24:00 GMT

Thanks Kenneth. It's BLE. Ok, so the MAC address is not transferred, and I would have to possibly get it via a custom characteristic that I can set up. No problem.

But that brings up one more question:

Since the peer address changes every 15 minutes, what is unique about a peer that makes it possible to bond/pass whitelist at connection time? Is it the IRK? The peer has to have a unique number to be identified during that process, right?

Thanks.

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Kenneth — Wed, 22 May 2019 07:41:26 GMT

Not sure what the address you refer to is (maybe it's Bluetooth classic or other legacy reasons) , but for BLE typically all android devices use private resolvable address (e.g. for privacy reason to ensure no one can track them in real life, the address change every <15 minutes). I assume you may create an app that expose or write the address you refer to in a custom characteristic, however such an address you refer to is not transferred/exposed in any way by itself no.

Best regards,
Kenneth

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Guilherme de Paula — Tue, 21 May 2019 16:16:25 GMT

Hi Kenneth,

Thanks for the reply. I previously had not quite understood the 24-bit/24-bit prand/hash, so thanks for the detailed explanation. I understand it now.

But that only shows me that the peer/central generated a valid prand and hash, and sent me the correct IRK, which are not my real goals.

My real goal is to verify if the peer/central is a device with Bluetooth MAC address of 80 4E 70 0F 05 9C (which happens to be an Android tablet). How can I do that? How can I get that address?

Is it not possible to know the peer's real address if the peer/central is using "random resolved private address"? The actual address is not sent at all, not even in encrypted/hashed form?

I still don't understand that.

Thanks.

Gil

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Kenneth — Tue, 21 May 2019 11:39:10 GMT

Hi,

So looking at the connection request packet:

The Access Address is randomly generated on each connection. The initiator (peer) and advertiser (own) address can be read out on connected event (note that if the peer use random resolvable address it will change at least every 15 minutes):

case BLE_GAP_EVT_CONNECTED:
{
ble_gap_addr_t peer_addr = p_ble_evt->evt.gap_evt.params.connected.peer_addr;
ble_gap_addr_t own_addr = p_ble_evt->evt.gap_evt.params.connected.own_addr;
}

If the peer use a random resolvable address it will be generated to this format according to the BLE core spec:

Then to the resolve the address:

So this explains why "It successfully decrypts the higher 3 bytes of the address and compares it with the original lower 3 bytes."

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

Guilherme de Paula — Mon, 20 May 2019 21:11:27 GMT

This compares the decrypted higher 3 bytes with the original lower 3 bytes:

#define IM_ADDR_CLEARTEXT_LENGTH    3
#define IM_ADDR_CIPHERTEXT_LENGTH   3
#define SOC_ECB_KEY_LENGTH          16

void ah(uint8_t const * p_k, uint8_t const * p_r, uint8_t * p_local_hash)
{
    ret_code_t err_code;
    nrf_ecb_hal_data_t ecb_hal_data;
    for (uint32_t i = 0; i < SOC_ECB_KEY_LENGTH; i++)
    {
        ecb_hal_data.key[i] = p_k[SOC_ECB_KEY_LENGTH - 1 - i];
    }
    memset(ecb_hal_data.cleartext, 0, SOC_ECB_KEY_LENGTH - IM_ADDR_CLEARTEXT_LENGTH);

    for (uint32_t i = 0; i < IM_ADDR_CLEARTEXT_LENGTH; i++)
    {
        ecb_hal_data.cleartext[SOC_ECB_KEY_LENGTH - 1 - i] = p_r[i];
    }

    err_code = sd_ecb_block_encrypt(&ecb_hal_data); // Can only return NRF_SUCCESS.
    UNUSED_VARIABLE(err_code);

    for (uint32_t i = 0; i < IM_ADDR_CIPHERTEXT_LENGTH; i++)
    {
        p_local_hash[i] = ecb_hal_data.ciphertext[SOC_ECB_KEY_LENGTH - 1 - i];
    }
}

bool im_address_resolve(ble_gap_addr_t const * p_addr, uint8_t * p_real, ble_gap_irk_t const * p_irk)
{
    if (p_addr->addr_type != BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE)
    {
        return false;
    }
    uint8_t hash[IM_ADDR_CIPHERTEXT_LENGTH];
    uint8_t local_hash[IM_ADDR_CIPHERTEXT_LENGTH];
    uint8_t prand[IM_ADDR_CLEARTEXT_LENGTH];
    memcpy(hash, p_addr->addr, IM_ADDR_CIPHERTEXT_LENGTH);
    memcpy(prand, &p_addr->addr[IM_ADDR_CIPHERTEXT_LENGTH], IM_ADDR_CLEARTEXT_LENGTH);
    ah(p_irk->irk, prand, local_hash);

    memcpy(&p_real[IM_ADDR_CIPHERTEXT_LENGTH], local_hash, IM_ADDR_CIPHERTEXT_LENGTH);
    
    return (memcmp(hash, local_hash, IM_ADDR_CIPHERTEXT_LENGTH) == 0);
}

RE: Resolved "private resolvable address" does not match Android tablet (central) MAC address

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

This does the whole 6-byte decryption and returns the address at p_real:

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];
  }
}