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,

The Eddystone sample in nRF Connect SDK (Zephyr) is very basic, and at the same time a full Eddystone beacon is quite complex. This is included in the nRF5 SDK though (Eddystone Beacon Application), so I suggest you consider that if you need it. May I ask why you are interested in Eddysone, seen as it is no longer maintained and Google discontinued support for it in 2018?

[adojang]

Hi, thank you for the response!

I've been trying to understand that example for the past few days.

I'm attempting to use Eddystone's EID as a convenient way to change my beacon's MAC address to prevent tracking, while still retaining the identity when the MAC address is decrypted. I suppose it doesn't actually have to be Eddystone, I'm just trying to use the existing framework to simplify what I'm trying to do.

[Einar Thorsrud]

If the only point is to prevent tracking, would it be an alternative to use privacy in form of a random resolvable address? That is the standard Bluetooth solution for avoiding tracking.

[adojang]

Definitely  - that's what I'm attempting to do with EID.

It might be that I just haven't done enough research.

Could you point me at a resource for resolving/predicting a random address?

Requirements for what I'm trying to do:

Authorize an nRF52805 beacon by using some protocol. The Resolver must sync with the beacon, and be able to predict the beacon's change of MAC address which will occur at set intervals. It is okay if information is briefly exposed when the resolver and beacon are initially syncing. The sync should only occur once.

I was thinking of using some kind of time / counter component onboard the beacon and resolver, 

Issues/Limitations with my approach:

The beacon / resolver will each have a clock drift. I'm unsure how to correct this (without forcing a resync often)

If the resolver's power is interrupted, the beacon will have to be resynced.

[Einar Thorsrud]

Hi,

The way this works with resolvable random addresses is that the device use a Identity Resolution
Key (IRK) to generate an address and change that regularly. When the address change, an observer cannot know that it is the same device unless it also has the IRK. If so, it just does some math on it and sees that the address comes from the same IRK. There is no need for clock synchronization etc, as this resolution always happens. For instance, the nRF (and I assume most other BLE products) has HW that does this automatically so it does not require CPU resources. I recommend you read 7.5.2.3 Resolvable Private Addresses from the newly released Bluetooth LE primer to get a basic understanding. Our SDKs support using this feature out of the box, though it is not used in the samples by default. 

The only down side of this that the only standardized way to exchange the IRK is via bonding. So in order to get the IRK in to the BT stack of phones you typically need to bond (if you are using other types of devices where you have full control you can do this in an application specific way).