In July, Eddystone, an open beacon format from Google, was released with support for three frame types, Eddystone-UID, Eddystone-URL, and Eddystone-TLM. Due to the success and rapid adoption of these frame types, Google has now released the technical specs on the fourth Eddystone frame type, Eddystone-EID. Eddystone-EID uses rotating ephemeral identifiers(EIDs) to broadcast a more secure beacon signal, which helps prevent spoofing, malicious asset tracking, replay attacks, or just unpermitted access. The main purpose of Eddystone-EID is to make beacons and proximity technology more secure.
What are the concerns regarding beacon security?
As mentioned above, there are a number of security concerns when deploying beacons. Eddystone-EID is a frame type that protects against each of these security concerns. Let’s take a look at what each of those are below-
Spoofing– Spoofing a beacon allows someone to clone it, or in other words create a beacon with the same ID. When this happens, it allows someone else to take and send a beacon’s signal in unattended places.
Spoofing example- A store entrance beacon that is triggering a welcome message could be copied by an attacker and replayed at the entrance to a train line. Consumers with the store app would receive the welcome message at the train entrance. Creating consumer annoyance and confusion.
While most spoofing would end up being relatively harmless, Make Magazine used spoofing to win a scavenger hunt at CES 2014 and they weren’t even present.
Malicious asset tracking– Asset tracking allows beacons to assist staff to quickly and accurately locate assets without having to search for them. If someone were to hack a beacon that was tracking an asset, they would gain the location of that asset. This could be especially harmful when assets are being shipped from one location to another.
Malicious asset tracking example- If a company were to track the arrival of their shipments via beacons, then a malicious hacker would known when a shipment has arrived. Potentially allowing them to steal a shipment.
Replay attacks– A replay attack allows an adversary to eavesdrop on the traffic, which gives them access to the data being recorded on the beacon network.
Replay attack example- If beacons in a retail environment were subject to a replay attack, an adversary would be able to see the interactions taking place with the beacon, giving them access to valuable consumer data.
How does Eddystone-EID prevent these from happening?
Eddystone-EID takes advantage of something called rotating ephemeral identifiers(EIDs). In simple terms, the EID will rotate every broadcast with a different unique identifier. To anybody trying to track a beacon broadcasting with Eddystone-EID, the broadcast will appear random. This makes it where the beacon cannot be tracked/spoofed. Since you are the only one who can see each of your beacon’s broadcasts, this makes your beacons much more secure.
Eddystone-EID opens up opportunity for more proximity campaigns
Security is a major concern for many adopters of beacons and the IoT in general. According to Jim Hunter from TechCrunch, security is the second most important thing an IoT device needs (after enough power to function at all). Eddystone-EID allows companies to manage access to beacons for use-cases where privacy and security is a concern. This will allow for further implementation and innovation surrounding the proximity industry.
Looking ahead at IoT security
This is a great step forward for IoT security. Proximity technology is growing fast and is being adopted by many different industries. A BI Intelligence report predicted that beacons will directly influence over $44 billion worth of US retail sales in 2016. With growth like this, security will play a very important role in the long term success of not only beacons, but the IoT industry as a whole. As more companies like Google push to provide IoT security, we will begin to see more consumers and businesses trust the IoT and move to adopt this new technology.
To read more on Eddystone-EID, check out this post from the Google Developers Blog.
