1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Growing Eddystone with Ephemeral Identifiers: A Privacy Aware & Secure Open Beacon Format

Discussion in 'Google Online Security Blog' started by RSS, Apr 14, 2016.

  1. RSS

    RSS New Member Member

    Posted by Nirdhar Khazanie, Product Manager and Yossi Matias, VP Engineering

    Last July, we launched Eddystone, an open and extensible Bluetooth Low Energy (BLE) beacon format from Google, supported by Android, iOS, and Chrome. Beacons mark important places and objects in a way that your phone can understand. To do this, they typically broadcast public one-way signals ‒ such as an Eddystone-UID or -URL.

    Today, we're introducing Ephemeral IDs (EID), a beacon frame in the Eddystone format that gives developers more power to control who can make use of the beacon signal. Eddystone-EID enables a new set of use cases where it is important for users to be able to exchange information securely and privately. Since the beacon frame changes periodically, the signal is only useful to clients with access to a resolution service that maps the beacon’s current identifier to stable data. In other words, the signal is only recognizable to a controlled set of users. In this post we’ll provide a bit more detail about this feature, as well as Google’s implementation of Eddystone-EID with Google Cloud Platform’s Proximity Beacon API and the Nearby API for Android and CocoaPod for iOS.

    Technical Specifications

    To an observer of an Eddystone-EID beacon, the AES-encrypted eight byte beacon identifier changes pseudo-randomly with an average period that is set by the developer ‒ over a range from 1 second to just over 9 hours. The identifier is generated using a key and timer running on the beacon. When the beacon is provisioned, or set up, the key is generated and exchanged with a resolution service such as Proximity Beacon API using an Elliptic Curve Diffie-Hellman key agreement protocol, and the timer is synchronized with the service. This way, only the beacon and the service that it is registered with have access to the key. You can read more about the technical details of Eddystone-EID from the specification ‒ including the provisioning process ‒ on GitHub, or from our recent preprint.

    An Eddystone-EID contains measures designed to prevent a variety of nuanced attacks. For example, the rotation period for a single beacon varies slightly from identifier to identifier, meaning that an attacker cannot use a consistent period to identify a particular beacon. Eddystone-EID also enables safety features such as proximity awareness, device authentication, and data encryption on packet transmission. The Eddystone-TLM frame has also been extended with a new version that broadcasts battery level also encrypted with the shared key, meaning that an attacker cannot use the battery level as an identifying feature either.

    When correctly implemented and combined with a service that supports a range of access control checks, such as Proximity Beacon API, this pattern has several advantages:
    • The beacon’s location cannot be spoofed, except by a real-time relay of the beacon signal. This makes it ideal for use cases where a developer wishes to enable premium features for a user at a location.
    • Beacons provide a high-quality and precise location signal that is valuable to the deployer. Eddystone-EID enables deployers to decide which developers/businesses can make use of that signal.
    • Eddystone-EID beacons can be integrated into devices that users carry with them without leaving users vulnerable to tracking.
    Integrating Seamlessly with the Google Beacon Platform

    Launching today on Android and iOS, is a new addition to the wider Google beacon platform: Beacon Tools. Beacon Tools allows you to provision and register an Eddystone-EID beacon, as well as associate content with your beacon through the Google Cloud Platform.

    In addition to Eddystone-EID and the new encrypted version of the previously available Eddystone-TLM, we’re also adding a common configuration protocol to the Eddystone family. The Eddystone GATT service allows any Eddystone beacon to be provisioned by any tool that supports the protocol. This encourages the development of an open ecosystem of beacon products, both in hardware and software, removing restrictions for developers.

    Eddystone-EID Support in the Beacon Industry

    We’re excited to have worked with a variety of industry players as Eddystone-EID develops. Over the past year, Eddystone manufacturers in the beacon space have grown from 5 to over 25. The following 15 manufacturers will be supporting Eddystone-EID, with more to follow:


    In addition to beacon manufacturers, we’ve been working with a range of innovative companies to demonstrate Eddystone-EID in a variety of different scenarios.
    • Samsonite and Accent Systems have developed a suitcase with Eddystone-EID where users can securely keep track of their personal luggage.
    • K11 is a Hong Kong museum and retail experience using Sensoro Eddystone-EID beacons for visitor tours and customer promotions.
    • Monumental Sports in Washington, DC, uses Radius Networks Eddystone-EID beacons for delivering customer rewards during Washington Wizards and Capitals sporting events.
    • Sparta Digital has produced an app called Buzzin that uses Eddystone-EID beacons deployed in Manchester, UK to enable a more seamless transit experience.
    You can get started with Eddystone-EID by creating a Google Cloud Platform project and purchasing compatible hardware through one of our manufacturers. Best of all, Eddystone-EID works transparently to beacon subscriptions created through the Google Play Services Nearby Messages API, allowing you to run combined networks of Eddystone-EID and Eddystone-UID transparently in your client code!
    [​IMG] [​IMG]

    Continue reading...

Share This Page