Recently, Google introduced some news about Eddystone. At the same time, we released a first implementation of the new specification on GitHub to get developers started. I would like to share some insights on what this is all about.

For those of you who are unfamiliar with Eddystone you can find detailed information on these websites:

• https://github.com/google/eddystone
• https://developers.google.com/beacons/

What’s new in Eddystone?

A new Eddystone GATT Configuration Service enables simple configuration of beacons. The user can configure the beacon to broadcast all Eddystone frame types:

• URL
• UID
• EID
• TLM
• eTLM

Each frame type is given a dedicated slot and it is possible to set unique advertising intervals for each slot.

This means that a beacon can send a Eddystone-URL every two seconds and a Eddystone-UID every second or any other combination. The current firmware has a lower limit of 100ms for advertising interval. It will be up to the user or developer to choose values that best fit with the use case and desired power consumption.

In addition to the new Eddystone GATT Configuration Service there are also two new frame types aimed at secure use cases. The new frame types are Eddystone-EID and Eddystone eTLM.

EID, or Ephemeral Identifier, is a secure version of UID. eTLM, or Ephemeral TLM, is a secure telemetry format and provides information on the health of a beacon.

What about security in the new Eddystone frame types?

Eddystone-EID and eTLM uses rotating ephemeral identifiers to broadcast a more secure beacon signal, to protect against the following security issues which are known for beacons.

Spoofing

Beacon spoofing is pretending to be a beacon. With regular beacons it is possible for someone to hijack the advertising data, which is always the same, and connect it to their own app. This could for instance enable an app for company A to serve information when a user is near a beacon for company B.

Eddystone-EID prevents this since the advertising data is encrypted and regularly updated.

Replay Attacks

If a beacon is unlocked with a fixed value it is possible to listen to the radio communication between a phone and a beacon and record the unlock value. A malicious user could now replay this unlock value to the beacon and gain configuration access.

By randomizing and never sending the Unlock Key in clear text it is difficult to perform replay attacks with the new Eddystone GATT Configuration Service. The beacon creates a random challenge token every time a user tries to unlock it. The user then encrypts the Lock Key with the challenge token and sends the result to the beacon. The result will be different for every unlock and replay attacks are therefore impossible.

Unauthorized authentication

Unauthorized authentication could allow someone to connect to and configure a beacon. This way company A could simply reconfigure a beacon owned by company B to advertise company A data.

The new Eddystone GATT Configuration Service is locked down by default. In order to configure the beacon a user must write a Lock Key to the Unlock Characteristic. The Lock Key is unique to each beacon and it will not be possible to remotely reconfigure the beacon without the Lock Key. The Lock Key is encrypted with a random challenge token before it is sent.

Malicious Asset Tracking

If a beacon is attached to a bus it could be possible to track the location of the beacon and therefore the bus. This is especially true if the beacon is always advertising the same data.

Eddystone-EID randomizes the device ID of the beacon as well as the encrypted advertising data. Since there are no constant values to track it will be difficult to track the location of a single beacon over any significant time period.

Note that a beacon should only be configured as EID and eTLM slots in order to have all the security benefits. A beacon configured as both EID and UID would still be vulnerable to tracking.

What’s in the nRF5 SDK for Eddystone?

Nordic Semiconductor has been collaborating with Google in the development of the firmware for nRF52 and a supporting mobile app which are released on GitHub.

The open source firmware at this point supports all characteristics except the three optional characteristics; Advertised Tx Power, Factory Reset and Remain Connectable. These characteristics will be added in a later release.

The Lock Key, at this point, is hard-coded into the beacon for simplicity and this must be changed to a beacon unique code before production. It is up to the beacon provider to write code for this. One possibility is to create the unique 16-byte Lock Key with data from the FICR device ID registers.

Currently there is a firmware limit of five slots although this can be extended.

Note that this firmware is in an alpha state and uses third party encryption libraries and the end user is responsible for the licenses of these libraries.

What’s in the nRF Beacon for Eddystone app?

The open source Android mobile app supports all Eddystone GATT configuration parameters which will allow the user to configure a beacon according to their preference.

The app also has the Nearby API integrated which can retrieve data attached to UID beacons and EID beacons when they are in range. The Nearby API will identify beacons registered under the same application namespace and hence only retrieve data attached to these beacons under the same namespace.

The app allows the user to register and attach data to beacons such as UID and EID in the Proximity API.

How do I get started developing?

The simplest way to start experimenting is by flashing the pre-compiled hex file to a nRF52 development kit, then open the app on your phone and start configuring the beacon.

The pre-compiled firmware and source code is available in the nRF5 SDK for Eddystone GitHub repository.

Download the Android app from Google Play or check out the source code in the Android nRF Beacon for Eddystone repository.