Last July, the Eddystone project was launched, an open and extensible standard from Google , defining the message format for Bluetooth Low Energy (BLE) beacons and natively supported in Android, iOS, and the Chrome browser. Beacons can mark important and interesting places or objects in a manner that is understandable for mobile devices. To do this, beacons, as a rule, unilaterally broadcast open messages - such as iBeacon , Eddystone-UID or Eddystone-URL , which makes them vulnerable to cloning, compromise, and spying. These problems have existed since 2013.

On Thursday, March 14th, Google announced in its security blog a new Eddystone-EID frame, with the support of an Ephemeral ID , for the Eddystone standard. An encrypted version of the Eddystone-TLM telemetry frame and a new standard interface for configuring beacons — the Eddystone GATT service — were also presented.

In this post I will talk in a little more detail about these innovations designed to significantly increase the safety of beacons and expand their use scenarios.

Technical details

For the observer, the Eddystone-EID-enabled beacon changes its 8-byte AES-encrypted identifier in a pseudo-random manner with an average period that is set by the developer in the range from 1 second to 9 hours. To generate an identifier, a key is used ( Ephemeral Identity Key or EIK ) and a timer at the beacon itself. The key is generated during the preparation and configuration of the beacon and then transferred to the resolution service, for example, the Proximity Beacon API, using the DiFiff-Heellman key agreement protocol on elliptic curves ( Elliptic curve Diffie – Hellman or ECDH ). This protocol is quite reliable and allows you to get a shared secret key using an unprotected communication channel, for example, during preparation and configuration of the beacon. Thus, only the beacon and the service with which it is registered have access to the key.
As for the registration of the beacon, the Google Proximity Beacon API allows you to do this in two ways:

1. By exchanging public keys with a beacon, in a completely secure end-to-end manner
2. By transferring a shared EIK key directly, which is somewhat less secure than the first option

At the time of the beacon registration, in addition to the key, the resolution service also needs to be informed of the current value of the beacon timer and the indicator of the rotation period. Those. The timer is also synchronized with the service. The Google Proximity Beacon API supports a rotation period of 2 ^X , where 10 <= X <= 15. The implementation is resistant to power outages for several days. With longer shutdowns of energy, resynchronization of the timer and the period of rotation will take some time.

Additional security measures

Eddystone-EID has additional security measures to prevent various attacks. For example, the rotation period for each beacon is slightly different from the identifier to the identifier, thus the attacker will not be able to use the rotation period to identify a specific beacon. Eddystone-EID also supports proximity reporting, device authentication, and data encryption during packet transmission. The capabilities of the Eddystone-TLM frame were also expanded with the new version, now the telemetry data is encrypted using the shared key, i.e. the attacker will not be able to use information about the battery level to identify the beacon.

Eddystone GATT service and Beacon Tools

In addition to the Eddystone-EID and the new encrypted version of the previously available Eddystone-TLM, a common beacon configuration protocol was introduced - Eddystone GATT service . It allows you to configure any Eddystone beacon using any tools that support this protocol.

The Beacon Tools app for Android and iOS was also introduced . This is an additional tool for the Google beacon platform, which allows you to register beacons and bind data to them.

Use Cases and Benefits

When properly implemented and in combination with the Proximity Beacon API, which supports a number of access control checks, Eddystone-EID has several advantages, for example:

• Location beacon can not be forged. This is ideal for cases where the developer wants to use additional features for the user in a particular place.
• Eddystone-EID allows those who deploy a network of beacons to reliably control access to it.
• Eddystone-EID-enabled beacons can be embedded in things or devices that people carry with them, without leaving users vulnerable to spying

What happens on the client device?

And nothing special! Eddystone-EID-enabled beacons can be used in projects where the Nearby Messages API is used, the Google beacon platform component scans and receives messages from them, without any changes in the code. When a client device detects a beacon broadcasting the Eddystone-EID frame and subscribes to it, the current EID is sent to the Google Proximity Beacon API along with the application API key. The Google Proximity Beacon API checks whether the provided API key has the authority to receive the attachment that was attached to the beacon. If there are such permissions, then the application receives the attachment in the usual way, like a Nearby message object. Otherwise, if there is no authority, the Google Proximity Beacon API returns an empty value, as if the beacon were not registered at all.

Eddystone-UID support from beacon manufacturers

Google is actively cooperating with industry players, for example, over the past year the number of beacon manufacturers supporting the Eddystone format has grown from 5 to over 25. And the following 15 manufacturers already support the Eddystone-EID format:

• Accent Systems
• Bluvision
• Reco / Perples
• Beacon inside
• Estimote
• Sensoro
• Blesh
• Gimbal
• Signal360
• Bluebite
• Nordic
• Swirl
• Bluecats
• Radius Networks
• Zebra

In addition to beacon manufacturers, Google actively collaborates with a number of innovative companies to demonstrate the advantages of Eddystone-UID in a variety of scenarios. For example:

• Samsonite jointly with Accent Systems developed an Eddystone-EID case for users to safely track their personal luggage.
• K11 is a museum in Hong Kong and retail stores use Sensoro beacons with Eddystone-UID support to guide visitors and encourage customers.
• Monumental Sports Entertainment in Washington, DC, uses Ediusstone-EID-enabled beacons from Radius Networks to deliver prizes to customers during the Washington Wizards and Capitals sporting events.
• Sparta Digital has released an application called Buzzin, which uses Eddystone-EID beacons deployed in the city of Manchester, UK.

Conclusion

This is a big step in the direction of security to solve the problems that have existed for several years. All this allows not only to use the beacons in new scenarios, where it is important that users can reliably and confidentially share information, but also stimulates the development of an open ecosystem around beacons, their hardware and software, eliminating existing limitations and shortcomings.

For more information about the security of BLE beacons and ephemeral identifiers, see this article.

The technical details of the specification for the Eddystone-EID package are available on github.

About Google beacon platform I wrote in detail in my previous articles:
Google's beacon platform. Part 1 - Proximity beacon API
Google's beacon platform. Part 2 - Nearby meassages API