Implementing Eddystone EID (and AES) on the nRF52805

[adojang]

Hello, I'm in the process of attempting to implement Eddystone EID on the nRF52805.

It's been a bit of a nightmare, so I'm finally taking the bold step to make my first forum post!

The current sample for eddystone doesn't have any EID implementations yet... It's under 'TODO'

Here is all the documentation from Google:

 https://github.com/google/eddystone/tree/master/configuration-service

https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/bluetooth/eddystone#id1

For now, I'm stuck on even just figuring out how to encrypt the beacons UUID and get the EID.

Please help

[Einar Thorsrud]

Hi,

IRK handling is automatic in the sense that if you enable privacy (CONFIG_BT_PRIVACY=y), it is automatically generated and used by the stack. However, there are API functions you can use to mage identities (the bt_id_* functions). The simplest way here is perhaps to use bt_id_create(). Depending on the parameters, it will generate an IRK for you (and populate a buffer with it so that you can do with it what you need), or use an IRK you provide. See the API doc for more details.

[adojang]

I tried to make a few identities, but I think my issue lies in the parameters I call.

I'm trying to enable RPA, but there is no BT_LE_ADV_PARAM that exists by default for it.

I've tried to create my own, and put this in the main.c file:

	#define BT_LE_ADV_PARAM(_options, _int_min, _int_max, _peer) \
				((struct bt_le_adv_param[]) { \
					BT_LE_ADV_PARAM_INIT(_options, _int_min, _int_max, _peer) \
				})



				#define BT_LE_ADV_NCONN_DIR_RPA(_peer) BT_LE_ADV_PARAM(BT_LE_ADV_OPT_DIR_ADDR_RPA, \
						0, 0,\
						  _peer)

But it seems to freeze and doesn't give me an error or success message when I start BLE with:

bt_le_adv_start(BT_LE_ADV_NCONN_DIR_RPA(peer), ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));

The devices successfully connect when I start with:

    err = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));

My current approach has nrf be connectable with a random address [This part works], then send over the IRK information with UART [Struggling with this]. Next, it disconnects, stops broadcasting, and changes to a non-connectable random resolvable address.[not working]

Something I've also noticed is that the IRK is said to be 16 bytes, but the pointer is only a uint8_t. How do I fit all that data in there?

[Einar Thorsrud]

Hi,

adojang said:

I'm trying to enable RPA, but there is no BT_LE_ADV_PARAM that exists by default for it.

You do not need any specific configuration of the advertiser, just enable privacy. The simplest is to take the beacon example and add "CONFIG_BT_PRIVACY=y". Then you will see that it advertises with a RPA. If you also set CONFIG_BT_RPA_TIMEOUT to a low value you can easily that the address changes every interval.

adojang said:

Something I've also noticed is that the IRK is said to be 16 bytes, but the pointer is only a uint8_t. How do I fit all that data in there?

This is a pointer to an array of uint8_t. Generally in C programming, arrays are passed around as pointers to the first element. So this is how it is done in all APIs that handle arrays.

[adojang]

Thank you once again, I've learned a lot!

I'm having trouble establishing a connection from my client (ESP32) to my peripheral (NRF) when enabling privacy. Without privacy, the uart example works great, and I can exchange information.

My current approach is going to be to connect to the NRF while it has a non-private address, exchange the IRK key over UART, then switch the NRF device to it's privacy enabled mode, setup a new identity with that specific IRK key, and start advertising.

On my client side, I'd like to generate a large whitelist of MAC addresses using the IRK, but I haven't been able to find the low level mathematical implementation of how to convert the IRK to a mac address. Could you point me to a resource?

[Einar Thorsrud]

To the math you can refer to BT core spec 5.3 page 1559 and page 3085. There are references there for digging further down. Note that this is not normally something you would need to do, as any Bluetooth stack out there should be capable of it. I cannot say how this is with Espressif so you would need to ask them for details about their devices. I would expect that they provide some tools for whitelisting IRKs though, as this is an essential feature.