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

[adojang]

This is exactly what I'm trying to do, thank you!

I'm working with an ESP32 as my client, and the nrf as my server.

My preferred method of authentication is to hold the nrf chip very close to the client, have the client scan ble devices, choose the one with the strongest RSSI (which will be the nrf).

The nrf beacon will be power cycled, and the client will attempt to connect to it.

When the nrf first powers on, it must be connectable/vulnerable for 30 seconds, allowing any device to bond with it, and obtain some kind of authentication or key.

I'm currently using the peripheral sample.

is the auth_passkey somehow related to IRK?

I found I was able to connect directly to the device using my iphone and the nrf Connect app without needing any passkey. That's mildly concering as I set it through:

bt_passkey_set(123456)

For my client, bonding with the passkey doesn't seem to solve the issue. The nrf spits out error code 0x13 which indicates that [BT_HCI_ERR_REMOTE_USER_TERM_CONN] - although my client certainly did not try to disconnect.

Any further advice?

[Einar Thorsrud]

Hi,

adojang said:

is the auth_passkey somehow related to IRK?

No, these are completely different keys. The IRK is used only to generate and resolve resolvable random addresses. The pass key is used for MITM protection (authentication) during pairing/bonding. If you are new to BLE, I really suggest the primer I linked to in my previous post. There feature set is quite big but that will give you a good overview, also of the security features.

adojang said:

I found I was able to connect directly to the device using my iphone and the nrf Connect app without needing any passkey. That's mildly concering as I set it through:

This is expected. One important thing to understand about Bluetooth security is that the security requirements are linked to specific each characteristic. Even if a device support a number of security features (bonding with legacy or LE secure connections, with or without MITM protection like passkey etc), all these features may not always be used. That is also application specific. Just as an example, iOS devices normally never use higher security level than needed. If they try to access a characteristic and access is denied, it will pair/bond, but not before that. So if you want to require pairing with a passkey you need to configure that for the specific characteristic you want to protect.

adojang said:

The nrf spits out error code 0x13 which indicates that [BT_HCI_ERR_REMOTE_USER_TERM_CONN] - although my client certainly did not try to disconnect.

The log is not very ambiguous, and this is a standardized disconnect reason so I would not be too sure to rule that out. How do you know that the peer (client) did not disconnect? Do you have logs from the peer / client that shows what happened there, and perhaps why id did disconnect?