iBeacon security overview

2. Beacon Security B E A C O N S E C U R I T Y Bluetooth Low Energy (Smart) Beacons leverage a common wireless standard that can be detected by nearly every modern smartphone. Beacons can be detect from a range of up to 70 meters. Because of this wide and wireless coverage, concerns have been raised on the security of beacons. © 2015 Localz Pty. Ltd.

3. Static Beacon IDs By default, Beacons are open and static. For example, Apple’s iBeacons constantly broadcast a single repeating payload: UUID, Major ID and Minor ID. Once deployed, anyone can detect these Beacon IDs. This gives rise to two specific risks: Beacon Spoofing & Piggybacking. There are additional but unrelated security concerns related to Beacon provisioning and configuration updates. However, we’ll save those for another paper. 1234… 1234… 1234… 1234… 1244… 1244… 1244… 1244… 1245… 1245… 1245… 1245… B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

4. Beacon Spoofing Beacon Spooﬁng is possibility of detecting and cloning beacon IDs. Another beacon (or phone) could be created with the same beacon ID. Malicious users can use spoofed beacons to trigger events and messages in a diﬀerent physical space than intended. A store entrance beacon triggering a welcome message could be copied by an attacker and replayed at the entrance to a train line. Consumers with the store app would receive the welcome message at train entrance. This could create consumer annoyance and confusion. Example risk: Beacon ID detected and copied cloned Beacon ID Later on . . . Store entrance Train entrance cloned beacon placed elsewhere B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

5. Beacon Piggybacking Beacon Piggybacking or Hĳacking is possibility of using beacons deployed for one application in another, unauthorised, application. Beacon IDs can be detected and their profile included in applications deployed by third parties. Providing a consumer has this third party app installed, these hĳacked beacons can then be used to trigger events, messages and analytics unrelated to the intended deployment. A coffee house, Small’s Coffee, deploys beacons for their mobile app. A competing coffee house, Big Coffee, visits small’s coffee to detect and copy beacons. Big Coffee deploys their own mobile app that includes beacon IDs from Small’s coffee. When consumers with the Big Coffee app installed visit Small’s Coffee, they receive a message for discount coffee at Big Coffee. Example risk: Small’s Coffee Small’s CoffeeBeacon ID detected Beacon ID included in competing app Big Coffee App “Get a discount at Big Coffee” App installed on consumer phone Later on . . . B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

6. Risk Mitigation There are four general controls to mitigating beacon risks Geolocation Validation + Cloud Validation + Hardware ManagementSoftware Seed ++ B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

7. Geolocation Validation After identifying a registered beacon the mobile device validates the phone geo location (during each session) to ensure it is near the intended physical space. This type of control prevents spooﬁng of beacons outside of the retail store. Further, the control is simple, inexpensive to deploy and permits the use of native iBeacon mode for greater compatibility. + B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

8. Software Seed Beacons are provisioned with changing IDs which prevent direct copying and piggybacking. A seed value is used to determine the ID sequence and change interval. The seed is synched to mobile devices via a SDK. When a beacon is detected, the mobile device checks with the SDK to determine if it is valid and what, if any action, is permitted. Although this approach helps to mitigate against spooﬁng and piggybacking, the seed value can be easily extracted and copied by a determined attacker. For this reason, several providers oﬀer cloud based propositions. + Seed value similar in concept to… B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

9. Cloud Validation Beacons are provisioned with changing IDs which prevent direct copying and piggybacking. A seed value is used to determine the ID sequence and change interval. The seed is synched to a cloud based service. When a beacon is detected, the mobile device checks with the Cloud service to determine if it is valid and what, if any action, is permitted. This approach provides a high degree of mitigation against spooﬁng and piggybacking. However, testing indicated that reliance on cloud services introduces latency that can signiﬁcantly detract from the user experience - especially in retail environments with poor mobile reception. + Seed value B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

10. Hardware Management Beacons are provisioned and managed by hardware controllers. Connected WiFi/Bluetooth devices such as BluVision’s BluFi and Kontakt’s Cloud Beacon are used to remotely manage and update the beacon fleet via cloud services. These devices can be used to change Beacon IDs at will, with corresponding changes sent to mobile apps. This approach provides a high degree of mitigation against spoofing and piggybacking. However, additional hardware is required. Further, this hardware must be able to connect over Bluetooth to covered beacons, which may limit effectiveness (e.g., will not work if beacons are placed in remote parking lots. + B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.

11. Other Controls B E A C O N S E C U R I T Y Hardware Validation: • There are additional controls to deter spoofing attacks that rely on beacon hardware manufacturer identifiers • This type of control is available from several manufactures but to our knowledge has not been widely deployed in production • Though challenging, it is possible to spoof nearly any aspect of a Bluetooth broadcast protocol - cloning may still be possible Hybrid Controls: • Many beacon vendors provide SDKs that combine one or more security controls • A common configuration leverages a combination of Cloud Validation and Software Seeds • Software seeds can be updated periodically via API calls © 2015 Localz Pty. Ltd.

12. Additional Considerations Rotating Beacon IDs: • Any scheme which relies on rotating beacon ID runs some level of risk that such changes will not be synchronised with mobile apps • Synchronisation may be lost due to: • Loss of internet connection • Failed background updates (register/ deregister) • A limit on iOS registrations • Failed beacon conﬁgurations • Where there is a lack of synchronisation, the app will not deliver the intended experience B E A C O N S E C U R I T Y iBeacon Alternatives: • Several secure beacon methods rely on alternative Bluetooth Low Energy protocols • Several of these approaches force iOS apps to use Bluetooth as an accessory and/or UIBackgroundMode • If implemented incorrectly, these modes can cause material battery drain • These approaches can be rejected by Apple for production deployment: stackoverﬂow.com/questions/15980481/my-app-has- been-rejected-because-of-uibackgroundmodes Geofence Triggers: • Piggyback style risks cannot be fully mitigated. It is possible to trigger background messages and events without the use of beacons • Geofence (clustered) registrations can be used to initiate messages and events using course location technologies • For example: location push messages could be triggered by third party apps on approach to a competitor store © 2015 Localz Pty. Ltd.

13. Comparison Control Geolocation Validation Software Seed Cloud Validation Hardware Management Benefit • Least expensive mitigation • Simple to configure and operate • Can be enabled/disabled on demand • Permits use of native iBeacon mode for greater compatibility • Helps mitigate spoofing and piggybacking attacks • No reliance on internet connections • No additional hardware required • Provides high degree of mitigation against spoofing & piggyback attacks • No additional hardware required • Difficult for determined attackers to compromise • Provides high degree of mitigation against spoofing & piggyback attacks • Provides a device to remotely monitor & update the beacon fleet • Changes can be deployed or backed out on-demand • Permits use of native iBeacon mode for greater compatibility Disadvantage • Does not protect against piggybacking attacks • Geolocation reliance does not provide same level of precision as other anti-spoofing controls • Location lookup may cause delay on initial start of session • Difficult to change or backout in case of issue • Beacon IDs can be easily identified by determined attackers • More complex deployment • Some schemes may not work reliably for Apple apps - not a native iOS iBeacon standard • Difficult to change or backout in case of issue • More complex deployment • Latency can diminish user experience • Requires reliable internet connections - may not work in all store environments • Some schemes may not work reliably for Apple apps - not a native iOS iBeacon standard • Most expensive deployment option • Requires additional hardware • Does not work for beacons out of range (i.e., parking lots) • Requires periodic internet connection for WiFi/BT devices B E A C O N S E C U R I T Y © 2015 Localz Pty. Ltd.