Chapter 9. iBeacon Security – Understanding the Risks
The final chapter of this book is about understanding the security issues surrounding iBeacon for you as both a developer and a consumer. If you've followed all of the tutorials in this book, then you've already got a good understanding of what security issues you might face as a developer. This chapter gives more depth to that understanding.
I thought a rundown of some security considerations together with a vocabulary of common security concerns of users would be a great way to finish off the book.
We've covered some of the security risks in Chapter 1, Welcome to iBeacon, so we may go over some old ground but since this chapter is entirely dedicated to security, we'll cover the topics in more depth.
As a developer, one of your primary concerns should be the vulnerability of your iBeacon profile. It's very easy for anyone equipped with a Bluetooth sniffer app to determine your beacon signatures and spoof them in their own app. After all, you've already made your iPhone act as a beacon during the course of this book.
The Consumer
Electronics Show (CES) 2014 offered its visitors a treasure hunt powered by iBeacons and before the conference even began, the show had been hacked by the team at Make Magazine so that they could win the treasure hunt without even being at the event. Read more about Make's audacious hack at http://bit.ly/makehacks.
What Make Magazine did is downloaded the Android APK file (a compiled zip containing the Android app) and ran it through a decompiler to discover the beacon profiles used by CES.
Defending against beacon spoofing
Ultimately, the best way to defend against people maliciously is to first decide whether or not you...
We've already discussed buying beacons and different types of beacons in Chapter 1, Welcome to iBeacon and Chapter 7, Vendor SDKs – Buying and Configuring Beacons, so we already know that there are various differences in the way beacon vendors implement their security models.
Beacon vendors have a catch-22 situation. They need a way to allow you as the owner to configure the UUID, major, and minor values, while at the same time stopping malicious persons hijacking the beacons and repurposing them for their own requirements.
Most beacons are configured over the air using Bluetooth devices, so if they aren't properly locked down, you only need a hacker within 100 meters of your beacon to repurpose them. For example, if you place beacons all over a public place such as a mall with a weak security model, then a hacker can leave the beacons where they are and change their UIUD/major/minor triplet for their own app.
What's worse, if hackers know they can change your beacon profiles...
Dispelling security myths
We already dispelled most of the common security myths in Chapter 1, Welcome to iBeacon, but I thought I'd just reiterate them so that you've got a complete vocabulary for your wary clients or users. Consider the following steps:
Beacons are tracking my location: Beacons aren't tracking your location. They're not doing anything at all except telling you they're nearby. They push data and don't receive data at all and what's more, most beacons your app comes into contact with don't even care that they are there.
Beacons are delivering targeted offers: Beacons aren't delivering anything except their UUID/major/minor triplet values. In order to deliver targeted offers, your app needs to know more about your habits and so ultimately needs your permission and some other understanding about you as a person.
Beacons can track me without my permission: Your mobile device will come in contact with beacons every day and as the technology gains momentum, your device will encounter...
Overcoming users' fears with good UX
As with any new technology, it's important to alleviate your users' fears about their privacy with a good UI.
Instead of just using the default location permission dialog box, it's important to tell the user why you want permission for their location with a full description. What's more, since iOS 7, you have been able to add this description using the NSLocationUsageDescription key in the app's info.plist file.
It's also important to ask for location at a relevant point; don't just spring the request on your user as soon as they start the app; otherwise, they're likely to deny your request.
Finally, only get the location if you have to. There's no quicker way to get a user to delete your app than by spamming them with marketing messages.
My final piece of advice when developing apps with beacons is to look at your app as a user and not just a developer. If your piece of functionality feels right from a user perspective, then it is. If you ask yourself whether...
In this chapter, we discussed some of the security issues surrounding iBeacon deployment and ways to protect against some of those security issues. Finally, we discussed common fears of users who encounter iBeacon solutions and ways to alleviate those fears.
We've come to the end of the chapter and your initial journey into iBeacon solutions, but this is by no means the end of your journey. If you have any questions at all about the book, then I'd love to hear from you, catch me on Twitter at @craiggilchrist and I'll gladly help you out. All that remains is to wish you the best of luck with your future proximity-powered endeavors from myself and everyone involved in the book. Thank you for reading and I hope you build incredible iBeacon solutions.
