key: cord-0539539-808s6x8g
authors: Chan, Aldar C-F.; Chung, Raymond M. H.
title: Security and Privacy of Wireless Beacon Systems
date: 2021-07-13
journal: nan
DOI: nan
sha: 258d91888cd00a825b6298dd05cc9b486b2339e7
doc_id: 539539
cord_uid: 808s6x8g

Bluetooth Low Energy (BLE) beacons have been increasingly used in smart city applications, such as location-based and proximity-based services, to enable Internet of Things to interact with people in vicinity or enhance context-awareness. Their widespread deployment in human-centric applications makes them an attractive target to adversaries for social or economic reasons. In fact, beacons are reportedly exposed to various security issues and privacy concerns. A characterization of attacks against beacon systems is given to help understand adversary motives, required adversarial capabilities, potential impact and possible defence mechanisms for different threats, with a view to facilitating security evaluation and protection formulation for beacon systems.

BLE (Bluetooth Low Energy) beacons have demonstrated great potential in smart city applications, especially, in context-aware, location-based and proximity-based services. They are particularly useful for implementing smart and social objects [2] . Leveraging on their advantages as small, low-cost devices with low power consumption and high-quality proximity estimation features, they can be placed in indoor or outdoor environments to convert them into smart space supporting interaction with users. Besides, they can also be attached to moving objects to enable object identification and tracking. Their applications have been greatly expanded from proximity marketing to a wide range of smart city applications- including digital signages, localized visitor check-ins, indoor navigation, proximity-aware event notifications and asset tracking. During the COVID-19 pandemic, they are increasingly used to facilitate contact tracing. In fact, BLE beacons can be seen as a practical embodiment of Weiser's vision [14] to make computers vanish into the background to be "an integral, invisible part of the way people live their lives." BLE beacons, or simply, beacons, are small radio transmitting devices which are mounted at strategic locations for the purpose of identifying objects or locations. Examples include Apple's iBeacon [1] and Google's Eddystone. A beacon, based on the advertising mechanism of the BLE wireless communication protocol [3] , regularly broadcasts short messages of static data to advertise its presence to BLE-enabled devices (such as smartphone and smart watches) in proximity. Pre-installed applications on these nearby devices  upon picking up the beacon messages  can then trigger actions like pulling context-aware information or notifications to the devices. The specific actions triggered are usually relevant to the location or context such as marking the current location on a floorplan or downloading product details of a nearby product [8, 13] . Another popular application is object tracking, with a portable beacon tag attached to a valuable object to identify its relative position in a short range with higher granularity. BLE communication, which carry the data, is especially designed for short range communication (up to 80 meters) to ensure maximum battery lifetime of devices. Unlike other BLE devices, the communication channel of a beacon is typically one-way.

Since beacons are typically deployed in human-centric IoT (Internet of Things) and smart city applications which involve users' everyday activities that depend on fine-grained location information, ensuring security and privacy of beacon systems is crucially important. However, like other computing systems, beacon systems face different kinds of attacks, and their deployment raises several security issues and privacy concerns [4] [5] [6] [9] [10] [11] [12] [13] . Their widespread adoption in smart cities also means that beacons are common targets for adversaries with economic or political motives. This article gives a fairly comprehensive exposition of the attack surface of typical BLE beacon systems, enumerating vulnerabilities and characterizing attacks based on attacker goals, attacker capabilities required to launch an attack and the impact of a successful attack. Such a framework would provide practical guidelines for application developers to evaluate the risks of their beacon deployments and understand potential attacks against them so that proper protection can be designed based on the desired security goals. A survey of possible defence mechanisms is also given to help developers formulate protection.

The rest of the article is organized as follows. The next section presents the operation of typical beacon systems. A characterization of attacks against beacon systems is given in Section 3, with security issues and privacy concerns discussed in Section 4 and 5 respectively. Section 6 presents a survey of possible protection mechanisms for beacon systems.

A beacon differs from usual BLE devices in that it only has a one-way channel for broadcasting its predefined ID (identity) for other mobile devices, say, a smartphone, to pick up. Figure 1 shows the operation of a typical beacon system. Beacons usually work with a dedicated smartphone application. A beacon is programmed to broadcast a fixed ID at regular intervals. When a smartphone pre-installed with the application is in proximity of a beacon and successfully receives this ID, the application would look up from this ID relevant actions that should be taken if it can recognize the ID. The action usually includes downloading a piece of content stored on a cloud or backend server and displaying it on the smartphone. The beacon message itself carries no content and has to rely on the installed application to look up from the ID the actual location or URL for downloading relevant content. In this way, a shop with beacons installed could automatically push marketing content to a nearby smartphone. If an adversary manages to interfere the mapping between beacon IDs and the locations of the referred content, wrong content will be delivered to cause confusion.

As depicted in Figure 1 , all beacon messages are carried in the same advertising data structure of BLE regardless of the manufacturers [3] . Yet, there are different message formats (i.e. different components making up the ID) for beacons made by different manufacturers. The choice of the message format may involve different trade-offs. For example, iBeacon offers more space to forward information while Eddystone supports three different types of messages (UID, URL and TLM) for transferring different data [1, 14] .

For iBeacon [1] , a message consists of 4 components: UUID (16 bytes), Major (2 bytes), Minor (2 bytes), and TX Power (1 byte). UUID usually corresponds to a particular application or company. Apple's iOS restrict applications to register up to 20 distinct UUID values for listening. The combination of Major and Minor allows more fine-grained divisions of beacons belonging to the same company or UUID. For instance, Major could refer to a specific outlet of a retailer and Minor a section inside the outlet. TX Power specifies the power at 1 meter from the beacon so that an application able to read the RSSI (Received Signal Strength Indicator) from a smartphone can estimate its distance from the beacon. In contrast to connected BLE sessions with multiple security mechanisms in place, BLE advertising transmissions used by beacons are unprotected. Table 1 shows a detailed characterization of potential threats against typical BLE beacon systems, in terms of the adversary motives, requirements on adversarial capabilities needed to launch a successful attack, resulting impact of a successful attack on beacon infrastructure owners and users, and effectiveness of different defence mechanisms with respect to the attack. This characterization framework could be useful for understanding and evaluating security risks of a given deployment in two aspects. First, it helps assess the likelihood of a potential attack against the deployment based on whether the given motives justify an attacker's investment to launch the attack and how likely an attacker has the necessary skills, information and device/equipment setup required to launch the attack. Second, it helps estimate the potential impact of a successful attack on the beacon infrastructure owner and users. In addition, it gives practical guidelines on the effectiveness of different defence strategies for the concerned attack. As an example, if the likelihood of occurrence of a successful attack against a beacon system is high and the attack could possibly cause relatively great impact on the owner or users, weight should be given to the consideration of investing in one of the defence mechanisms to safeguard the beacon system.

There are several attacks against a BLE beacon system, some of which target at the infrastructure owner (including piggybacking, silencing, spoofing, reprogramming, reshuffling/cracking attacks) and other at the users (including user profiling, presence inference and user device resource draining attacks). User profiling and presence inference, to be discussed in Section 5, mainly aim to track valid users or deduce their habits using a beacon infrastructure, which is concerned with user privacy. The other attacks, to be discussed in Section 4, largely aim at a beacon infrastructure per se to allow an attacker to free-ride on its service or render its service unusable or unavailable to cause annoyance to legitimate use Table 1 . Characterization of different types of attacks against a BLE beacon system

While there are different types of threats associated with a beacon system, the adversary objectives seem rather focused, with roughly three types of motives: 1) Free riding  an attacker aims to use an existing beacon infrastructure established by others for free (piggybacking attacks) to push his selected content or notifications to its users;

2) User profiling  an attacker aims to use an existing beacon infrastructure as tools for tracking its users or deduce their habits (user profiling and presence inference attacks) ; and

3) Service disruption  an attacker aims to disrupt the service of a beacon system to cause annoyance to users of beacon-enabled applications (silencing, spoofing, reprogramming, reshuffling/cracking and user device resource draining attacks) that may lead to the removal of the applications, thereby undermining reputation of the corresponding corporates.

A free-riding attacker could be a company which wants to develop an application to push location-based notifications or content to potential customers but does not want to invest in establishing the needed beacon infrastructure. In the worst case, the attacker could be a business competitor of the beacon owner, so that he can offer a coupon with a more attractive deal for customers whenever the customers receive a coupon from the beacon owner as triggered by the proximity to these beacons.

An attacker aiming to profile users tracks persons of interest and infers their habits with beacons. However, large-scale surveillance would still be challenging [6, 9] . Practically, it is possible to construct  using a user profiling attack  a very accurate profile of a targeted user, including details such as how often he visits a retail chain, which departments he prefers and how much time he spend in front of a particular product, etc. Such data would be valuable for personalized advertising [9] .

An attacker with a service disruption motive aims to bring down service of a beacon infrastructure to make it unavailable to users or disrupt the established mapping between beacon IDs and content addressing information in order to cause wrong content to be delivered to users' applications. For example, signages or navigation instructions can be wrongly delivered or simply unavailable to a user application whenever needed. Consequently, users may find it annoying and therefore remove the application. This could hurt credibility of the respective corporation.

While a free-riding or user profiling attack would be less disruptive to users, an attack aiming to mess up the beacon ID mapping or make beacon service unavailable could possibly bring great confusion and impact on users.

By viewing the beacon broadcast as a communication channel, attacks and attacker motives can be mapped to the conventional CIA (Confidentiality, Integrity, Availability) security goals, which are commonly used to characterize security of an information system. In order to freeride on a beacon infrastructure, an attacker has to be able to read and interpret its beacon messages. This is equivalent to breaching message confidentiality of the beacon channel. An attacker able to mess up the mapping between beacon IDs and content addressing information violates message integrity of the beacon channel to create the wrong mapping. An attacker able to bring down the service of a beacon infrastructure undermines the availability goal of the beacon channel.

Seven adversarial capabilities which allow an attacker to launch various attacks against a beacon system are identified in Table 1 . These attacks usually require an attacker to either intrude beacon devices (re-programming and reshuffling attacks) or, less intrusively, build an overlay coexisting with a beacon infrastructure (silencing, spoofing, presence inference and resource draining attacks). Others (piggybacking and user profiling attacks) only require knowledge of IDs and locations of beacons to leverage on an existing beacon infrastructure. For the case of intrusion, it could be remote (as in re-programming) that an attacker has read/write access to beacon firmware due to poorly secured beacons (Capability-A4) or physical (as in reshuffling/cracking) that an attacker can physically remove or reshuffle beacons to new locations (Capability-A5). Beacons are usually hidden in different spots to cover an area, thus rendering them easily accessible for an attacker to remove them, open them up or relocating them. The intrusive attacks are realistic threats for typical deployments.

For the less intrusive attacks, an attacker is always assumed to possess software and hardware to allow him to sniff BLE packets including beacon messages, in order to learn IDs of different beacons (Capability-A1). Such hardware is typically inexpensive, and the software usually free. This presumes that the attacker can come to proximity with the victim. Yet, an attacker may also use high-gain antennas to allow him to eavesdrop or imitate beacons from a largerthan-typical distance [9] . This would allow an attacker to capture and replay packets or even craft and inject new ones with modified data fields. It is thus fair to assume that an attacker has knowledge of IDs and locations of beacons of interest. This knowledge is necessary for an attacker to rebuild a beacon ID database (Capability-A2), in order to launch the piggybacking and user profiling attacks, or clone beacons (Capability-A3) for silencing and spoofing attacks. Besides cloning beacons, an attacker may also use a BLE transceiver to replay messages of different beacons to imitate them to deceive a user.

To disrupt beacon service in order to annoy legitimate users, an attacker needs to install his cloned beacons or equipment to imitate beacons in areas of interests (Capability-A6) to create the wrong mapping to cause wrong content to be delivered. In a silencing attack, a cloned beacon also needs to be close to the real beacon to deceive smartphone applications. Similarly, to launch a presence inference attack, an attacker needs to install his own surveillance equipment in an area where the person of interest would have a high chance to appear in order to detect his beacon tags.

In some cases, an attacker must be able to develop a beacon-enabled application and distribute it as legit such that users would grant authorization to the required API services (such as CoreLocation services on iOS) to this application (Capability-A7). In piggybacking attacks, the application is indistinguishable from an authentic application since it appears as a common beacon-enabled application. The only difference is that the application uses a third-party beacon infrastructure built by another party without his consent. In contrast, user profiling attacks have to deceive users into installing a malicious application which secretly monitors a user's vicinity for third-party beacons.

The actual impact of an attack is closely related to the adversary motives previously discussed. While attacks aiming at free-riding or user profiling would have no visible impact to users  though user privacy is breached sneakily in user profiling, those targeting at service disruption would cause annoyance to users and normally require prompt remediation by the beacon infrastructure owner.

There are various security issues regarding beacon systems. Figure 2 shows a classification of attacks.

Piggybacking A piggybacking attack [9, 13] (also called a hijacking attack in [9] ) refers to the attack wherein an adversary wants to run its service leveraging on the beacon infrastructure built by others without their consent. Since each beacon ID is broadcast in clear, an attacker can listen to all beacon IDs of interest and build a database of beacon IDs and their locations and other details, with which he can build his services using these third-party beacons. In the worst scenario, the attacker could be a business competitor of the beacon owner, so that he can offer a coupon with a more attractive deal for customers whenever the customers receive a coupon from the beacon owner.

Similarly, after listening and recording a beacon ID and other details, it is possible for an attacker to forge a fake beacon with the same ID (possibly placed in different locations geographically) by spoofing the original beacon ID [13] . Users cannot tell apart a real beacon and a fake beacon since their IDs are the same. It should be noted that while message authentication (such as digital signatures) typically works for assuring integrity of a communication channel, it cannot withhold spoofing attacks against a beacon system. An attacker could record and replay beacon messages and their signatures, which are indistinguishable from those of a real beacon. A fake beacon, however, could cause confusion, especially when it is used for providing location-based services.

A silencing attack [9] aims to manipulate a smartphone application and deceive it into perceiving a beacon as remote by using cloned beacons or BLE transmitters to transmit a flood of spoofed beacon messages with a greater TX Power value. As such, the application's estimation of proximity would become biased towards the fake readings and result in an inflated estimated value for the distance between the real beacon and application. Consequently, the application would not show the content or notification as it should for being in proximity of the beacon, undermining service availability.

The goal of a resource draining attack, which is called user harassment in [9] , is to slow down user devices or make other services on them unavailable. By broadcasting a large number of different beacon IDs, a nearby smartphone with an installed beacon-enabled application would keep comparing and processing these IDs to an extent that computing resources available for other applications are considerably reduced. The smartphone's battery may also be exhausted.

Some beacons allow over-the-air programming or software update, without proper authentication implemented due to cost and power consumption constraints. An attacker can possibly program these beacons with new IDs. This would make the original content service associated with the beacons unavailable, which is a kind of denial of service attack. In addition, by carefully crafting the new IDs, an attacker can cause wrong content to be delivered to user applications as in spoofing attacks. Hence, re-programming attacks can possibly undermine both integrity and availability goals of a beacon system.

Since proximity awareness is a key characteristic of beacon-enabled applications, exposure of beacons to users seems inevitable in most deployment scenarios. Beacons are usually placed to cover an area and physically accessible to all users including potential attackers. If an attacker manages to swap the positions of beacons physically, the mapping between beacon IDs and the URLs or addresses of content (which is programmed on a user application) would be wrong, thus leading to wrong content to be downloaded for a misplaced beacon. In case physical removal of beacon by an attacker occurs, the existing beacon service would become unavailable to user applications [13] .

Beacons can be used for location-based services (with beacons statically mounted) [9, 13] or proximity-based services (with beacons mounted on a person or moving objects) [6, 9, 13] . Both application scenarios are exposed to privacy breaches [5, 6, [8] [9] [10] [11] [12] [13] . The former is usually associated with user profiling [9, 13] while the latter with presence inference [6, 9] .

A user profiling attack usually tracks locations of a user through an application installed on the user's device [9, 13] . The adversary could be the developer of an authorized beacon-enabled application which the user has willingly installed, but the developer has not obtained consent from the user to track his location history. Since the two set of API services  needed by the authorized application to provide beacon-enabled services and used for illegitimate user profiling  usually have a large overlap, it is generally difficult for users to detect the unlawful surveillance functionality hidden in the authorized application. In other cases, the adversary could even deceive a user into granting service authorization to a tracking application and freeride on third-party beacons to track the user's locations [9] . As the installed application listens to beacons in proximity, it will upload these beacon IDs to a dedicated server hosted by the adversary for storage and lookup of locations of the beacons.

A presence inference [5] [6] attack targets at beacon-emitting objects carried by users, with the adversary installing surveillance equipment in certain areas to detect messages emitted from the target users' beacons in order to infer their presence in the areas.

Most attacks require knowledge of beacon IDs and their locations. Correspondingly, there are two approaches for an attacker to collect beacon IDs, namely, the lunch-time attack and pervasive eavesdropping. In a lunch-time attack, an attacker collects all beacon IDs initially in a collection phase and then it would be too costly for him to do so afterwards if the beacon owner makes changes during deployment. In pervasive eavesdropping, an attacker is able to listen to changing beacon IDs on the fly without constraints. It is most difficult to defend against attackers with this eavesdropping capability, and most of the existing defence mechanisms only assume a lunch-time adversary.

It is challenging to implement defence for beacons because they are usually equipped with a unidirectional channel which makes conventional authentication protocols (which require interaction) inapplicable. Simply appending a digital signature to a beacon ID would not work to withhold spoofing attacks. In general, there are three strategies to defend beacons against attacks. Time-varying ID [7, 10] . Beacons are programmed to broadcast evolving or time-varying IDs, thus making it more costly for an attacker to copy and replay beacon messages. Industrial efforts, such as the Gimbal and Kontakt beacons, have also come up with a similar but less secure version based on rotating IDs from a predefined, fixed pattern. In more secure versions [7, 10] , cryptographic techniques such as keyed pseudorandom functions are used to generate time-varying beacon IDs. To overcome synchronization issues between beacons and user applications, [10] applies time as input to the pseudorandom function for generating beacon IDs and uses a Bloom filter to accommodate loose time synchronization. However, generation of evolving IDs could reduce the lifespan of the battery of a beacon. In addition, evolving IDs cannot withhold re-programming and reshuffling attacks.

Outlier/Anomaly Detection [2] . Traces of user queries are gathered at the backend server in order to run hypothesis testing to detect any outlier or anomaly of beacon ID transitions with respect to their geographic mounting positions. As a user device moves around a beaconequipped area, the transitions of consecutive beacon IDs seen by the application would follow certain probability distribution (Figure 3 ). [2] models these transitions with a Markov chain and derive the transition probabilities based on the relative mounting positions of beacons. A merit of outlier detection is that it requires no modification on beacons and does not shorten beacon lifespan While outlier detection is more powerful and can defend all attacks other than piggybacking attacks, careful consideration of user privacy protection is necessary.

Selective Jamming [6] . An additional BLE-enabled guardian device can be installed to opportunistically invoke reactive jamming of messages emitted by a personal beacon tag. Only devices authenticated through an out-of-band channel with the guardian device can read beacon messages indirectly through the guardian device. No modification on beacons is required. But this approach mainly applies to protecting beacon tags carried by a person against presence inference and would not be useful for beacons deployed for location-based services.

While the benefits of BLE beacon systems for smart city applications are clear, they can be undermined by the inherent security and privacy risks of such systems. These risks primarily stem from the unprotected nature of beacon messages over a broadcast channel. This article enumerates various security and privacy attacks against beacon systems to characterize them based on adversary motives, attacker capabilities, potential impact of a successful attack, and effectiveness of known defence techniques. Due to the characteristics of beacon usages, lowskilled attackers can easily gather sufficient information including beacon identities to launch most of the attacks. Similarly, physical compromises or re-programming of beacons are also realistic threats. While various attacks exist, the adversary has rather focused objectives, including free-riding, service disruption and person profiling. The impact of service disruption on beacon system owners and users is generally high, whereas there is no noticeable impact of free-riding and person profiling despite that the latter sneakily breaches user privacy. There are a handful of techniques to protect beacon systems  time-varying beacon identities, outlier/anomaly detection, selective jamming  involving various trade-offs.

From 'Smart Objects' to 'Social Objects': the next evolutionary step of the Internet of Things

System and method for attack detection in wireless beacon systems

Uncovering privacy leakage in BLE network traffic of wearable fitness trackers

Protecting privacy of BLE device users

Ephemeral identifiers: Mitigating tracking & spoofing threats to BLE beacons

BLE beacons for Internet-of-Things applications : survey, challenges and opportunities

Breaking BLE beacons for fun but mostly profit

Secure BLE broadcast system for location based service

Covert channel over Apple iBeacon

Bluetooth: With low energy comes low security

BLE beacons in the smart city: applications, challenges, and research opportunities

The computer for the 21 st century