This April represented the three year anniversary of an anti-spoofing white -paper that we authored in collaboration with Mark Vandervoord of Thingamabyte, for GeLo, a Bluetooth Low Energy device start-up at the time. To this day, this is the only detailed white paper that I’ve seen on this subject.
A few individuals have contacted us over the years about it and we have shared the white paper selectively, but now we’re making it public. So, if you’re interested in combating BTLE device spoofing then this white paper is something you’ll want to check out.
The white paper looks at:
- Protecting against spoofing a beacon and overriding its message
- Protecting against attempts to uncover encryption scheme and configuration parameters
- Providing the ability to update the message the beacon advertises
- Providing the ability to update key encryption algorithm parameters
Yes, spoofing is a thing
You may be wondering: Spoofing is a thing? How? Why? I won’t go into exhaustive detail, but here’s a basic recap that illustrates the issue.
BTLE devices work using a 128-bit universally unique identifier (UUID), a major number, and a minor number. The UUID is used to identify a device and to distinguish one device from another, but it’s has no security measures.
The UUID, major number, and minor number are all publicly transmitted over the airwaves. You can have one BTLE device spoof another simply by broadcasting with the same UUID, major number, and minor number. This is exactly what happened at the CES show in 2014 where the promotional scavenger hunt got hacked. This is so simple to do, someone with barely any programming experience could get their smartphone to spoof a beacon.
You may be thinking: Is this even really that big of a deal?
The answer is maybe.
It depends on how BTLE devices (especially beacons) are going to be used. BTLE beacons – including Apple’s iBeacons – are dumb devices. They simply broadcast out information and it’s up to an application that receives the broadcasted information to make sense of it. In a lot cases, it’s annoying, but not really a security issue.
For example, consider a museum that uses BTLE beacons to enhance the experience of a museum visitor. It doesn’t really matter if somebody whose not at the museum spoofs a beacon. There’s nothing at risk. But, in the case where a large retailer wants to utilize BTLE as part of location-based promotional marketing campaign or as part of a customer rewards program it may have a larger impact. Retailers won’t want someone sitting at home spoofing the beacon to rack up the rewards that are for customers who visit their stores. For one reason, it could have a real monetary impact on their company.
The number of situations where spoofing can apply are infinite, but all cases of beacon spoofing have the same characteristics. This white paper is one area of research that we explored.
Interestingly enough, BTLE beacons on their own cannot solve the problem. They are only half of the solution. The other half is that the receiving device (e.g. your phone) must have an application that makes sense of the broadcasted information. So, whatever solution is implemented on the device needs to have parity with the application intended to interact with that device. As beacon manufacturers implement solutions they should also provide a library or SDK which takes care of this for you.
So, if you’re looking to solve this problem or just gain insight into the issue you’ll want to read the white paper. Get it by clicking the link below:
If you’re building out BTLE devices, mobile apps or web apps that integrate with BTLE devices or cloud services let us know. We’ve been doing it since before Apple released iBeacons and we’d be happy to put our experience to your use.
Until then, happy coding!
