When it comes to the internet of things, there is much excitement surrounding the potential for automation and data collection that will make all of our lives easier. With the advent of bluetooth low energy (BLE), we are starting to see more and more applications for internet of things devices because now the devices can be produced at extremely low cost while also not having a large impact on cell phone battery life.
Of particular interest to me is iBeacon, a protocol developed by Apple that allows an application programmer to determine the distance from a BLE device. The protocol requires a device send a unique id and the device’s transmit power. On the other end, libraries have automated the process of determining the distance from the device and allow a developer to tell if the user is within four ranges of the device, the the closest being 10-20cm.
With this in mind, you can quickly think of some interesting applications that can improve user experience. For example, the Starbucks application could automatically send a notification when walking into a Starbucks so that the user could pay with his or her gift card easily without having to dig through pages of apps.
The act of sending a notification is a simple application of the proximity awareness that BLE and iBeacon can give us. As applications become more complex, we need to think of ways to ensure security of the action taken by considering attack vectors.
## Limitations When considering iBeacon security we must first address the limitations of the protocol and devices which implement it. To be considered an iBeacon, a device must simply transmit a unique id and its transmit power. And that’s it. There is no two way communication between devices that read this signal - phones can simply glean proximity information about devices implementing iBeacon.
From this we can learn the following:
- You can’t communicate with the iBeacon through BLE.
- The phone must have prior knowledge of unique ids (UUID’s) in order to take a specific action.
Let’s consider the second point in terms of the Starbucks example. For the phone to send a notification when entering a Starbucks using an iBeacon, the device would need to be aware of every UUID for every Starbucks. UUIDs are 36 bytes and there are fewer than 1200 Starbucks in the US, so we are looking at .0432 megabytes of space in the app - which is extremely manageable.
Now that we have discussed the limitations, we can think of attack vectors.
Think of a situation in which we spoof an iBeacon by copying its UUID and transmitting that UUID in our “malicious” iBeacon. In the Starbucks example, this might lead to unwanted notifications while walking around town or into your office. In the end, if the only action taken is sending a notification so that an app can easily be opened, then the risk is small.
Consider the situation in which the action is context/proximity aware and is causing the user to perform an action such as sending a payment? And some such actions could be automated by developers - for instance, the developer may have programmed the Starbucks app to ping a server every time the user enters an iBeacon enabled store for analytics purposes. Spoofing may have an affect on this metric, but still have a relatively small impact on the user. Even so, many actions may incite the user to take further action - the attack vector is akin to Trojan websites where users are given a context and decide to take an action (make a payment for instance) with unwanted results.
Door lock automation is part of the onslaught of internet of things devices that are flooding the market. Imagine a proximity aware door lock that unlocked when you got within range. The phone would be aware of the lock’s UUID and then send a signal to the home’s IoT manager to unlock the door. With collusion, the home could be unlocked without the user being aware if the lock’s UUID were to be spoofed, even if the user were not home. Now the threat has some merit - it is not simply a matter of unwanted notifications - UUID’s of iBeacons simply cannot be trusted by application developers.
Again here, there are two main takeaways that stem from the limitations above:
- Applications cannot authenticate with iBeacon devices through BLE.
- UUID based actions must be authenticated in some way before they can be trusted.
While the attack vectors looks somewhat daunting due to the limitations of inexpensive iBeacons, the solutions are not complex and do not increase cost. There are a few things that developers can do to properly authenticate iBeacon based actions.
In the case of the door lock, instead of automatically opening the door when a user’s phone is in proximity of a known UUID, the application could simply notify the user of the proximity and ask the user to “Swipe to Unlock” the door. This would also alert the user of suspicious activity if the notification were to appear when the user was in fact not near the door of interest.
This solution assumes that the user has a secure connection to a trusted third party which can verify the user’s permission to access the door and then has the capability to grant such access. This is the case in university settings with building automation. Users can validate their authenticity with their university accounts which is already linked to the rooms they have access to in most universities.
As for the Starbucks application, the application developer should simply refrain from using the iBeacon alert for anything critical or to take meaningful metrics. A way to improve this would be to also take GPS location of the phone and make sure the user was in proximity of a known store, but this increases complexity and users may not be willing to give location data to the application. Another solution would be to authenticate with the iBeacon device itself - this solution would also make the door unlock situation more seamless while not compromising on security.