iBeacon security overview

14
Secure Beacons Overview & Options © 2015 Localz Pty. Ltd.

Transcript of iBeacon security overview

Secure BeaconsOverview & Options

© 2015 Localz Pty. Ltd.

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.

Static Beacon IDsBy 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.

Beacon SpoofingBeacon Spoofing 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 different 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.

Beacon PiggybackingBeacon Piggybacking or Hijacking 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 hijacked 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 Coffee Beacon 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.

Risk MitigationThere 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.

Geolocation ValidationAfter 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 spoofing 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.

Software SeedBeacons 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 spoofing and piggybacking, the seed value can be easily extracted and copied by a determined attacker. For this reason, several providers offer 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.

Cloud ValidationBeacons 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 spoofing and piggybacking. However, testing indicated that reliance on cloud services introduces latency that can significantly 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.

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.

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.

Additional ConsiderationsRotating 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 configurations

• 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: stackoverflow.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.

ComparisonControl 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.

© 2015 Localz Pty. Ltd.

[email protected]✉ ✉[email protected]

@localzco