Can Your Estimote Be Hacked? Yes It Can (For Now)

Your Beacons Can Be Hijacked (If You Don’t Do It Right)

Estimote beacons can be ‘hacked’ and coders with malicious intent could change the advertising packet data in the devices. If the devices were being deployed on a large scale the exploit would mean that the beacon you put up in your store could, in theory, be changed and made useless – or even worse, made to work for your competitor’s app instead of your own.

While at first glance this might seem to put iBeacon technology at risk of hacks and exploits, the news should be put in the context of two larger observations:

  • While Bluetooth LE might seem like a simple thing to deploy and use, it will quickly fall to developers with advanced expertise to do it right
  • Estimote is not yet a production-ready product and is still classified as a developer kit. The company has yet to release its security measures, cloud control panel, or full specifications around security, connectivity and pairing. So the beacons shouldn’t be evaluated based on the reverse engineering of a developer preview device.

Depending on the use case and security requirements, developers will put in place monitoring, layers of security and device-specific measures that are appropriate to the use case being explored.

Take the CES Scavenger Hunt – an iBeacon event that’s getting a lot of attention because of its association with the major consumer electronics show of the year.  Here’s a use case that doesn’t need a lot of security – it’s meant to be fun, there’s not much at stake, and giving some backdoors to industrious coders might not be such a bad thing.

But the same authors also ‘hacked’ the CES app – completing the Scavenger Hunt without even getting on a plane to Vegas. Hardly a world-breaking security issue and actually of a completely different nature from the Estimote work.

Understanding The Estimote Vulnerability

But the news about Estimote will inject a note of caution into those who believe that the popular beacons are ready for mass market (rather than a developer preview). Following a long description of how they reverse-engineered the beacons, the authors concluded that:

Whilst the Estimote developer preview kit and SDK are still in their early stages if Estimote sticks with their currently security model—although there are signs that they might not do that—anyone who creates an application using their SDK will be able to reconfigure any Estimote Beacon in the wild.

The implications of that are fairly far reaching. If someone maliciously changes the iBeacon Major or Minor characteristic of a beacon, any consumer application configured to use that particular beacon will stop working—the beacons must be configured with a pre-defined identity to trigger the correct behaviour inside the consumer’s own application when their smart phone comes into proximity of the beacon.

Beyond that you could configure a “fake” beacon to act as an impostor of another beacon belonging to a retail chain, potentially gaining access to promotions, gift cards and other location dependant goodies tied to the beacon you’re impersonating.

While Estimote was arguably the first Bluetooth LE beacon company to ride the wave of publicity surrounding Apple’s launch of iBeacon, there seems to be a new beacon coming out every week. Estimote’s advantages have led to a rich ecosystem of 10,000 developers playing with the turtle-shaped beacons.

This has given what I think is a mistaken impression that Estimote are ready to act as a prime time beacon solution. Until we see their security protocols, management tools, back-end dashboards and (not least of all) pricing for all these services, the beacons are still just fun things for developers to play around with.

Its what Estimote does next that’s important – not how secure their beacons are today.

iBeacon and Bluetooth LE: Steps We Need To Take

There is significant misinformation and misunderstanding related to iBeacons. There are perceptions, for example, that beacons:

  • Somehow deliver “content” such as coupons or videos (they don’t)
  • Because they deliver content, someone can hack your beacon and send your app content that you weren’t expecting (they can’t)
  • That beacons are somehow “secure” out of the box
  • Or alternatively, that all beacons are somehow insecure – which I suppose is true to the same degree that ALL technology is to some degree insecure

The trick to beacons, like any technology, is to develop solutions where you build layers of security that are appropriate to your use case. In theory, if you were looking to develop a highly secure transaction system, for example, you’d probably want to use things like a fingerprint scanner (like Apple has deployed) along with multiple layers of authentication and monitoring.

But run a scavenger hunt at a local festival and I doubt you’re going to want PIN and fingerprint authentication – you’ll build a solution appropriate to the use case.

Sonic Notify Gets Real About the Challenges of Deployment

We reached out to Sonic Notify to get their take on some of the security challenges with beacons. Their experience in deploying both Bluetooth LE and audio beacons extends well past a few months of work into millions of transactions delivered and thousands of beacons deployed. We thought they’d give us some good insight into how experienced developers are deploying beacons.

Aaron Mittman, CEO of Sonic Notify, commented on their experience with the issue:

We have given much thought to security. For the last two years we have refined this very issue.  With our  Secure Beacon solution, the major and minor values (aka payload) of our transmission changes frequently. The payload is encrypted to obscure reverse engineering the major and minor values.

Securing the UUID is much more difficult (as has been seen in the case of Estimote). Its is true that the UUID is open and must be searchable by the application. Advanced beacon solutions will need enterprise caliber CMS functions to coordinate changing UUIDs over time. Not to say that servers are uncrackable, (see Snapchat for the latest example) but the task of securing a server is much better understood.

Aaron suggested that the Sonic Notify approach to security will likely be echoed by beacon makers (and perhaps by Estimote):  a randomly timed encrypted payload that changes (i.e. the advertising packet cannot be easily read) and a synchronized rolling UUID and payload (i.e. more secure because it’s partly server based).

We expect to see a similar deployment by Estimote when it comes time for them to release the “production ready” version of their beacons.

The CES Scavenger Hunt Solved: And It Hasn’t Even Started Yet

The same folks who “cracked” the Estimote also took a look at the Scavenger Hunt for the Consumer Electronics Show, a beacon-powered app that’s getting a lot of press, and which they managed to complete not only before the show started but without even getting on a plane to Vegas.

While at first glance it might seem like a major exploit, there actually isn’t much news here: the application file wasn’t encrypted, and so the ID numbers of the beacons were easily found and spoofed. The app was developed by Core Apps of Maryland.

Radius Networks provided technology to support the beacons. We reached out to them and David Helms responded:

The most important thing to bear in mind is that when developing proximity solutions, the security model employed has to be appropriate for the application scenario. In many cases a minimal security model is appropriate if the assets at risk are minimal or if you have other compensating security mechanisms in the supporting systems.

For other scenarios, a more stringent security model may be required, but you always have to balance the cost and complexity against the solution requirements. When deploying Bluetooth Low Energy proximity solutions you always have to bear in mind the inherent risks of man-in-the-middle interception, device spoofing and untrustworthiness of the mobile devices participating in the solution and including compensating security mechanisms in the supporting systems to address those limitations.

Where some see an exploit, I see a super clever winner: sure, they might not have gone to Vegas, but they’ve managed to not only promote the channels at the CES but have had some fun seeing if they could game the system. And, being a game, what’s the harm in that? If this was some kind of super secure banking application I’d be worried – but it isn’t, and it seems to me like the ‘security’ was appropriate to the use case.

And that’s the point: the use case will inform the approach to security.

But what we need to clear up first is confusion about what Bluetooth LE is, how to secure it, what “secure” really means, and how to manage and monitor beacons once they’re in the field. If these sound like tasks you can do on your own or which you can trust to a brand of beacons that don’t have a ton of market exposure yet, then more power to you.

But where this gets really exciting is that it makes us aware that there’s a deep level of expertise needed to get any new technology “right” – and so these early stories and reverse engineering efforts are a reminder of how much fun (and sure, how many sleepless nights) we’ll have as we connect up a world of beacons.

Let’s Have a Discussion

Throw your comments and questions into the discussion below – I’d like to hear what you think, what impression this gives, and what questions you have about Bluetooth LE and iBeacon security. What do you think? What worries you? Let’s discuss.

Give Us A Follow

Join our weekly e-mail list for more on iBeacons. Check out our Twitter list to follow the best beacon tweets. Check out our BEEKn Google page and just generally stay in touch!

11 thoughts on “Can Your Estimote Be Hacked? Yes It Can (For Now)

  1. @Doug: this is again Jakub, CEO & Co-Founder of Estimote, Inc.
    Thanks for mentioning us and your comments on beacon security. I just posted my comment next to the original Makezine article, but if you don’t mind I will include them here as well as part of the discussion.

    As you all know in our API we have included methods for changing major and minor numbers, but we didn’t want developers to easily change UUID yet. It was mostly because the first version of our radar app ( was only able to detect and render our beacons with the same UUID and we didn’t want to confuse users if beacons suddenly disappear because of UUID change.

    Current version of beacons’ firmware doesn’t also implement any beacon authentication method. It means that anyone can connect and change beacon’s settings.
    At the end of the day these are evaluation kits, so we wanted to ship them into developers’ hands as soon as possible. More than 10000 developers around the world are already playing with our beacons and we basically don’t assume they hack each other dev kits : )

    You have to remember that beacons are in fact small computers using 32-bit ARM processor and running our tiny operating system. They can be updated over the air and implement any security authentication/encryption model. We are already running many real-world pilots and beacons configured for the commercial application use the industry standards like private/public keys to secure authentication and perform sophisticated UUID encryption algorithms to prevent monitoring and events hijacking or spoofing you mentioned.

    The secure mode I mentioned as well as an ability to change UUID will be available in the new firmware version in aprox. 2 weeks. Our intention is not to lock developers with our SDK, but provide the most reliable and secure cross-platform solutions for real-world installations. See our GitHub discussion here:

    The contextual computing era is here and we can expect more and more beacons installed all over the places. Retail stores, airports, hospitals, schools just to name a few. There will be new industry standards to secure sensitive applications like contact-less payments or indoor positing. We are in the very beginning of an exciting new offline-online world : ) See you at CES!


  2. Juan – I’d call Estimote “very close” – as Jakub elaborates in his comments, they’ll have a big release in 2 weeks.

    Gimbal by Qualcomm is positioning itself as “ready to deploy” and they’ve done some advanced work on security (as has Estimote – it just isn’t “there” yet).

    Sonic Notify is DEFINITELY production ready and has been in field for a few years, with Bluetooth LE added in the last while.

    Stick n’Find is in the field and they have a great SDK and developer support.

    I’m sure there’s others but those are the ones that jump to mind.

    One final note – Apple hasn’t released its final spec yet for devices. You’ll want to make sure that there’s a way to update the firmware once their spec is released.


  3. […] Estimote beacons can be ‘hacked’ and coders with malicious intent could change the advertising packet data in the devices. If the devices were being deployed on a large scale the exploit would mean that the beacon you put up in your store could, in theory, be changed and made useless – or even worse, made to work for your competitor’s app instead of your own. (More…) […]


  4. Any updates on beacon type tech stuff, seems not much updates or even a market for the devices in 2016 At we are deciding if it is worth our time and money to develop and sell this technology. Looking for updates on security issues and new applications as Eddystone and Google are moving foward (somewhere)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s