Beacons leverage a common wireless standard that can be detected by nearly every modern smartphone. Because of this wide and wireless coverage, concerns have been raised on the security of beacons. 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. This doc is a summary of the risks and general controls available to mitigate attacks.

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

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

5. Beacon
Piggybacking
Beacon 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 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 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.

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

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

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

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.

14. © 2015 Localz Pty. Ltd.
tim.andrew@localz.com✉ ✉pete.williams@localz.com
@localzco