Two words you keep hearing are iBeacon and security. What is a beacon? How do you keep them secure? It’s important when deploying iBeacon technology to understand how beacons are used and appropriate ways to assess beacon security. Let’s start off simple.
How do beacons even work?
Beacons that support iBeacon-technology do not broadcast content (such as coupons or contact information), they broadcast identifiers that can be received by iOS. An app running in iOS can then use that identifier to do things. Let’s break down what this identifier is and what it does. Three different pieces make up the identifiers: a universal identifier (UUID), a major number, and a minor number. The UUID is a very large number that organizations can generate on their own and have confidence that it will not conflict with another organizations’ UUIDs. iOS makes it very easy to limit discovery of beacons to your organization’s defined UUID, while ignoring UUID’s defined by other organizations. While this could be viewed as a limitation of the technology, generating identifiers in a non-centralized way allows organizations to “brand" their beacons which, in a future awash in beacons, will be crucial for apps to be more than beacon-aware, but beacon-intelligent. This UUID scheme illuminates the path for how large-scale iBeacon deployments will be conducted: not apps that discover all beacons, but apps tuned to discover an organization’s beacons and ignore the rest.
It should be noted that UUID assignments are not part of a beacon security strategy, despite the ability to uniquely assign the company beacons. Unique IDs do not mean the broadcast information is at all private or secure. Using a Bluetooth sniffer or a Bluetooth discovery app can discover the identifiers. It is also relatively trivial to broadcast another organization’s identifier. That doesn’t make iBeacons are insecure, but indicates misplaced security concerns. Take a Wi-Fi network’s name, or SSID, for example. It is not possible to stop others from using the same network name, but you can use the network name as way to infer location. Combined with other information, this can help accuracy and speed positioning. iBeacons can be viewed in a similar way. The identifiers should not be used as keys to unlock protected resources, but as one among several reference points to determine location and proximity.
A great illustration can be found in iBeacons used with Passbook on iPhone. An iBeacon is not used to validate or redeem Passbook passes, but to determine when the pass will appear on the lock screen. The actual redemption takes place when the pass is scanned by a barcode scanner. We implemented a similar strategy during the Macworld 2014 iBeacon Scavenger Hunt. Initial ideas for the game involved showing a clue on the iPhone screen when participants arrived in a certain area. That clue would point participants to another iBeacon-enabled area which in turn will show the next clue. The problem with this strategy was that the protection of the valuable resource (in this case, the clue) was based on proximity to the iBeacon. It would be trivial for someone to set up their own iBeacon and use it to discover all the clues and game the system. To prevent this, we added in some physical security. When the participant entered a beacon-enabled area, it triggered the iPhone to show a hint to locate the clue on physical signage and scan a QR code associated with that clue. Someone who might set up an iBeacon to steal the clue would not be able to complete the scavenger hunt without physical proximity to the QR code on the sign.
iBeacons should be viewed as one of several reference points for microlocation. Apps can validate beacon broadcast reception against other information to determine validity including a local Wi-Fi network, geolocation, or other information available to the app. While someone could set up a spoof beacon, it would be much more difficult if an app verifies beacon data with discovery of GPS locations. iBeacons provide an effective way to quickly discover microlocation, but this capability should be used to enhance user interaction rather than protect resources.
In the next post we’ll dive deeper into some of the questions around beacon security. Should beacons be physically secured? What if a beacon ID is spoofed? What are the risks to customers receiving the beacon broadcasts?