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

[Guilherme de Paula]

Hi all,

I use nRF52832-QFAA, S132 2.0.0, SDK 11.0.0, IAR 7.5 under Windows

Upon connection, I am trying to resolve the peer "random private resolvable" address (not for whitelisting, just to check who I am connected to).

I have most information needed, including the IRKs array. 

I have used a few different "resolving" functions, including im_address_resolve() in id_manager.c (belongs to the peer manager in sdk 11).

This example function actually just checks 3 bytes... 

It successfully decrypts the higher 3 bytes of the address and compares it with the original lower 3 bytes.

But...

1) They are not partly nor wholly the Bluetooth MAC address of the Android tablet I am using as central.

2) How do I obtain that address?  I still don't know.

I have also modified the function to handle all 6 bytes...

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

Can someone help?

Thanks,

Gil

[Kenneth]

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."

[Guilherme de Paula]

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

[Kenneth]

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

[Guilherme de Paula]

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.

[Kenneth]

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

[Guilherme de Paula]

Cool.  Thanks!  I understand the whole process now.

Cheers,

Gil