Eddystone-EID is a component of the Eddystone specification for BLE beacons. Eddystone-EID beacons broadcast an identifier that changes every few minutes. The identifier can be resolved to useful information by a service that shares a key (the Ephemeral Identity Key, or EIK) with the individual beacon. Any use of Eddystone-EID requires both a beacon and a resolving service (such as the Google Proximity Beacon API).
Eddystone-EID beacons can be used with Nearby, the beacon scanning component of the Google beacon platform, without making any changes to your code. This makes it possible to support a hybrid deployment of Eddystone-EID and Eddystone-UID beacons.
The Google Proximity Beacon API will only return attachment data associated with Eddystone-EID beacons when the request contains the API key of an authorized project. This means that, provided you take appropriate care of your API key, only your app can make use of the beacon signal.
You can learn more about the cryptographic approach of Eddystone-EID from our preprint.
Use cases for Eddystone-EID beacons
Eddystone-EID is designed to give developers control over which clients can make use of their beacon signals. The beacon identifier changes pseudo-randomly in such a way that it can only be resolved to stable information by a resolution service that shares an encryption key with the beacon. Without access to the resolution service, the beacon identifier is of little use.
Eddystone-EID is appropriate for cases where beacon deployers wish to:
- Prevent other parties from using their beacons.
- Preserve user privacy in scenarios involving wearables or other equipment carried by the user.
- Lease their beacon network to other parties in a way that allows a provable 'off switch' for access.
- Provide a strong signal that a user is at a particular place, that is not easily spoofed.
The shared key between an individual beacon and a beacon registry is exchanged at the time the beacon is provisioned using an elliptic curve Diffie-Hellman key agreement protocol. This protocol is robust against an insecure channel between the beacon that is being provisioned and the service performing the resolution. The Google Proximity Beacon API supports registration of an Eddystone-EID beacon through two channels:
- By exchanging public keys with the beacon, in a fully secure end-to-end fashion.
- By accepting the shared EIK directly, which is less secure but permits a single beacon to be registered multiple times with different services.
At the time a beacon is registered, and in addition to the key exchange, the resolution service also requires current clock value of the beacon and exponent of the rotation period. The Google Proximity Beacon API supports nominal rotation periods of 2K seconds for 10 ≤ K ≤ 15.
The Google Proximity Beacon API uses sightings of the beacon to infer each beacon's characteristic clock drift in order to ensure high reliability. The system is robust against power outages of several days, though re-synchronising the beacon clock's offset may take some time for longer outages.
What happens when a client sights an Eddystone-EID beacon?
When a client device sights an Eddystone-EID beacon as a result of a Nearby subscription, the current EID is sent to the Google Proximity Beacon API along with the API key of the calling app. The Google Proximity Beacon API establishes whether the supplied API key is authorized to fetch attachments that have been associated with the beacon. If resolution is allowed, the attachments are served back as Nearby message objects in the normal way. Otherwise, Google Proximity Beacon API returns an empty value, as it would if the beacon had not been registered.