Location-based access control system for mobile devices using bluetooth low energy technology

Abstract

The increasing presence of smart mobile devices in sensitive environments raises significant security and privacy concerns, particularly due to the unauthorized usage of built-in sensors such as cameras and microphones. However, space owners currently have limited means to enforce restrictions on mobile devices within their premises. To address this issue, we propose a novel location-based access control system utilizing bluetooth low energy (BLE) beacons to dynamically enforce security policies. The proposed system introduces the jumbo beacon concept, which enables fragmented transmission and reassembly of signed access control policies, overcoming BLE payload limitations. Unlike centralized enforcement models, our approach is fully decentralized, eliminating the need for a trusted central server and providing a flexible, scalable mechanism for enforcing fine-grained access policies. The system is implemented as a native security module within the Android operating system, ensuring tamper-resistant enforcement of policies while preventing unauthorized modifications. A proof-of-concept implementation demonstrates the system’s effectiveness, highlighting its real-time policy enforcement capabilities and resilience against adversarial threats. The results indicate that our approach offers a lightweight, scalable, and secure solution for enforcing location-based access control in dynamic environments.

Keywords

Location-based access control space-based access control access control and authorization location privacy

1. Introduction

The proliferation of smart mobile devices in modern workplaces has brought about significant security and privacy challenges, particularly in highly secure environments such as government facilities and research laboratories. With the widespread use of these devices, unauthorized access to critical device functionalities—such as cameras, microphones, and sensors—poses substantial risks. Mobile device features, including various applications, can inadvertently contribute to data leakage, further exacerbating security concerns. These risks include corporate espionage,¹ unauthorized surveillance,² and sensitive data leakage,³ all of which can have far-reaching consequences for individuals and organizations alike. Traditional security measures, such as network firewalls, device management systems, and physical access restrictions, offer some protection.⁴ However, they fall short in dynamically enforcing fine-grained, location-based security policies on mobile devices, where the flexibility and adaptability needed to respond to changing environments are limited.⁵

In particular, while many existing access control systems provide some level of enforcement, they often rely on centralized trust models and infrastructure.^6–9 This introduces several key concerns, such as scalability issues, reliance on a single trusted authority, and vulnerabilities due to potential single points of failure. Furthermore, many traditional systems are not designed to handle the dynamic and context-sensitive nature of modern, mobile, and highly distributed work environments.¹⁰ This presents a need for a more flexible and efficient solution that can respond to real-time, location-based security requirements in a scalable manner.

To address these challenges, we propose a novel location-aware access control system that utilizes Bluetooth Low Energy (BLE) beacons to dynamically enforce security policies on mobile devices. BLE beacons present an energy-efficient and widely deployable solution for proximity-based enforcement.¹¹ However, the small payload size of BLE advertisements, typically limited to just 160 bits, makes it difficult to communicate complex access control policies. Additionally, the reliance on centralized models for policy distribution and verification introduces scalability issues and vulnerabilities related to trust, as the system requires a single point of control.

To overcome these issues, we introduce the jumbo beacon mechanism, a novel solution that enables fragmented transmission and reassembly of data across multiple BLE beacons. This mechanism effectively bypasses the 160-bit payload limitation of standard BLE broadcasts, enabling the system to handle large, complex data—such as access control policies—more efficiently. This innovation makes the solution applicable to a wide range of BLE-based use cases, from corporate offices to government facilities, while maintaining a high level of flexibility and efficiency.

Furthermore, our system eliminates the need for a central trusted authority by adopting a fully decentralized, whitelist-based enforcement model. In this model, digitally signed policies are verified locally on the mobile device, improving scalability and security. This approach also ensures that policies are tamper-resistant, preventing unauthorized modifications by malicious actors.

Moreover, the system is intended for enterprise-managed deployments, where devices are provisioned by the space owner and support tamper-resistant OS-level enforcement. To implement this model, we have developed a native security module within the Android operating system that ensures seamless enforcement of access control rules without requiring modifications to existing BLE beacon hardware.

In this paper, we present a proof-of-concept implementation of our approach and conduct a comprehensive performance evaluation. Our results demonstrate that the jumbo beacon mechanism enables efficient policy transmission, ensures low-latency enforcement, and provides robust protection against unauthorized access. Additionally, the decentralized model enhances resilience against attacks, making the system a practical and secure solution for enforcing location-based security policies in real-world environments.

This paper presents the following key contributions:

We introduce a novel BLE jumbo beacon mechanism that enables fragmented transmission and reliable reassembly of data, effectively overcoming the payload size limitations of standard BLE advertisements. While designed to support access control policy delivery, this mechanism is broadly applicable to any use case where transmitting larger data over BLE is required.

We propose a whitelist-based, fully decentralized policy enforcement model that eliminates the need for a trusted central authority while ensuring policy integrity.

We implement a native security module within the Android operating system, preventing unauthorized modifications and ensuring robust policy enforcement.

The remainder of this paper is organized as follows: Section 2 presents a review of related work. Section 3 describes the architecture and design of the proposed system. Section 4 discusses our prototype implementation. Section 5 details the experimental setup, performance benchmarks, security analysis, and overall effectiveness of our approach. Section 6 discusses topics related to system deployment and both strength and limitations of our approach, Finally, Section 7 summarizes our findings and discusses potential future work.

2. Related work

Chowdary et al.⁶ proposed a policy-based framework that enforces application-level restrictions based on user profiles and campus WiFi connectivity. Their model supports different user categories (e.g., students vs. faculty), with policies enforced through middleware-level modifications. However, enforcement relies on infrastructure-controlled networks (e.g., WiFi) and lacks support for continuous or fine-grained access restrictions.

Franziska et al.⁷ introduced a world-driven access control framework aimed at preventing untrusted applications from accessing sensitive data, such as video or audio streams, in physical environments (e.g., locker rooms). Their solution requires tagging physical objects (e.g., with QR codes) to associate access policies, which poses scalability and usability challenges in real-world deployments.

Carlos et al.⁸ proposed a space-sensitive access control model that considers both user location and policies defined by application developers or space owners. The model requires application-side logic and centralized policy servers, but does not address critical challenges such as revocation, delegation, space ownership verification, or decentralized enforcement.

Other research has explored the use of proximity-based constraints, which consider the spatial relationship between the requester and other entities in the environment.^12–14 These models extend the traditional label-based access control (LBAC) framework by incorporating dynamic spatial factors. In parallel, several studies have enhanced role-based access control (RBAC) by embedding location-aware attributes,^14–16 enabling roles to be activated or modified based on the user’s geographic context.

Efforts in Hsu and Ray,¹⁷ Zhu et al.¹⁸ explored the use of spatial information in user authentication, while^19–21 examined the protection of location privacy within LBAC systems. Other work addressed accuracy limitations in localization and the integrity of reported location data.^16,22

Security challenges in LBAC have also been studied. For example, Abdou et al.²³ analyzed the risk of users falsifying their location to gain unauthorized access. Additional contributions include proposals for evaluating LBAC models,²⁴ identifying key system requirements,²⁵ and outlining open research directions in the field.¹⁰

Our previous work, ICMS,⁹ introduced a space-based access control system that supports hierarchical and fine-grained policy enforcement on mobile devices based on physical space ownership. It enables space owners to define and enforce access restrictions without requiring user interaction and promotes transparency by revealing the identity of the enforcing authority. ICMS also preserves user location privacy by ensuring that location information is never disclosed to third parties. One limitation of ICMS, however, is its reliance on a central server for policy distribution.

Table 1 provides a comparison between our proposed system and existing LBAC systems that similarly empower space owners to enforce access control policies on mobile devices. Notably, our proposal does not require a centralized trust server, unlike some other systems. It also ensures that user location privacy is preserved, a feature not supported by all systems in the comparison. Additionally, our system does not impose any limitations related to physical spaces, providing greater flexibility. In terms of security, while device rooting remains difficult, similar to other systems, our approach ensures robust privacy and security without relying on a centralized infrastructure.

Table 1.
Comparison of our proposal against existing similar label-based access control (LBAC) systems.

System Requires centralized trust server Requires OS-level modifications Preserves user location privacy Limitations related to physical spaces Security bypass possibilities

Chowdary et al.⁶ Yes Yes No Restrictions only enforced while the user is connected to a specific WiFi infrastructure. (1) Device rooting (difficult); (2) User connects to cellular network rather than WiFi (easy).

Franziska et al.⁷ No Yes Yes Real-world objects must be tagged (e.g., using QR codes). (1) Device rooting (difficult); (2) Misplacement of real-world object tags (easy).

Carlos et al.⁸ Yes No No Require cooperation from application developers to add required logic code. (1) Uncooperative developer who did not include the required logic into the application source code (easy); (2) Location spoofing (difficult).

Abdulla et al.⁹ (Our previous work) Yes Yes Yes No limitations. (1) Device rooting (difficult); (2) Location spoofing (difficult).

Our proposal No Yes Yes No limitations. Device rooting (difficult).

System	Requires centralized trust server	Requires OS-level modifications	Preserves user location privacy	Limitations related to physical spaces	Security bypass possibilities
Chowdary et al.⁶	Yes	Yes	No	Restrictions only enforced while the user is connected to a specific WiFi infrastructure.	(1) Device rooting (difficult); (2) User connects to cellular network rather than WiFi (easy).
Franziska et al.⁷	No	Yes	Yes	Real-world objects must be tagged (e.g., using QR codes).	(1) Device rooting (difficult); (2) Misplacement of real-world object tags (easy).
Carlos et al.⁸	Yes	No	No	Require cooperation from application developers to add required logic code.	(1) Uncooperative developer who did not include the required logic into the application source code (easy); (2) Location spoofing (difficult).
Abdulla et al.⁹ (Our previous work)	Yes	Yes	Yes	No limitations.	(1) Device rooting (difficult); (2) Location spoofing (difficult).
Our proposal	No	Yes	Yes	No limitations.	Device rooting (difficult).

3. Our solution in a nut-shell

This section presents the design of the proposed location-based access control system. It begins by outlining the key design goals, followed by the threat model that identifies potential adversaries. We then describe the overall system architecture and its primary components, as illustrated in Figure 1, which also highlights the associated threats. Subsequently, we introduce the customized BLE beacon structure and the jumbo beacon concept. The section concludes with a detailed explanation of the system’s main operations.

Figure 1.

System architecture and threat model overview. Threat actors are labeled (i–iv) as described in Section 3.2, and components are numbered as defined in Section 3.3 (1–5).

3.1. Design goals

The proposed system is designed to achieve the following goals:

Location-specific policy enforcement: The system should allow space owners to define and enforce access restrictions on mobile devices based on specific physical zones (e.g., offices, meeting rooms, restricted areas). This enables flexible and precise enforcement of policies aligned with the contextual needs of each space.

Simple policy updates: Access policies may require frequent updates due to evolving operational or security needs. The system should facilitate rapid and low-effort policy modifications, minimizing configuration complexity for space owners.

Fine-grained access control: The access control model should support detailed definition of permissions, such as selectively enabling or disabling specific device features (e.g., camera, microphone) for individual applications. This granularity enables tailored policy enforcement.

Whitelist-based enforcement model: To minimize the risk of unauthorized access, the system should adopt a default-deny approach, where all functionalities are disabled by default and only explicitly permitted features are enabled through verified policies.

Elimination of trusted central server: To improve resilience and reduce dependency, the design should avoid reliance on a centralized trust authority. A decentralized infrastructure model should be adopted to remove single points of failure and enhance scalability.

Scalable implementation: The architecture should support scalable deployment across various types and sizes of physical environments. This includes the ability to manage multiple zones and policy sets without significant overhead or performance degradation.

Power and cost optimization: Energy efficiency and cost-effectiveness should be considered key design priorities. The system should operate with minimal power consumption and low deployment cost to support practical adoption at scale.

3.2. Threat model

The threat model identifies potential adversaries and describes possible attacks that could compromise the integrity and effectiveness of the system’s access control policies. Our primary objective is to protect defined access control policies from unauthorized modifications and to ensure their reliable enforcement on end-user mobile devices. We have identified the following threat actors:

i
Malicious user: A malicious user may intentionally attempt to bypass enforced access control policies within controlled premises. Possible methods include disabling Bluetooth functionality, manipulation of BLE beacon’s content, or tampering with the policy enforcement software module on their mobile device to gain unauthorized access to restricted features.
ii
Rogue BLE beacon transmitter: An unauthorized individual may deploy a rogue or malicious BLE beacon transmitter within a controlled space without permission from the legitimate space owner. Such transmitters could broadcast fraudulent access control policies, potentially resulting in unauthorized access being granted to restricted features on users’ mobile devices.
iii
Replay BLE beacons: An attacker may capture legitimate BLE beacon transmissions and replay these signals in unauthorized areas or at unintended times. Such replay attacks can result in unauthorized or incorrect enforcement of access control policies, potentially disrupting normal operations and security within the targeted premises.
iv
BLE signal jamming: An attacker may intentionally disrupt BLE beacon signals by transmitting interference or noise, effectively blocking legitimate beacon transmissions. This prevents mobile devices from receiving access control policies, which may lead to the absence of intended policy enforcement and disruption of normal system behavior.

3.3. System architecture

The proposed system consists of the following primary components:

End-user: An individual roaming into different physical spaces with their mobile device.

Mobile device: A mobile device (e.g., smartphone or tablet) equipped with BLE communication capability, and the required software and hardware functionality to receive BLE beacons.

Access control module (ACM): This customized software component is pre-installed on users’ mobile devices and operates as a privileged system service within the Android operating system.²⁶ A system service cannot be disabled or altered by end users. It operates in a sandboxed environment with a distinct system-level identity, isolated from user-space applications and processes. The only permitted method of interaction is through its explicitly exposed interfaces, accessed via binder transactions that traverse the kernel space. The module is responsible for: (i) Continuously receiving BLE beacon signals; (ii) parsing and storing them in memory; (iii) reconstructing jumbo beacons; (iv) validating their authenticity; (v) enforcing verified access policies; (vi) and revoking them when conditions are no longer met.

BLE beacon transmitter: BLE beacon transmitters are strategically placed within physical spaces to broadcast digitally signed, location-specific access control policies. These policies are defined and configured by the space owner, and subsequently loaded onto the transmitters for broadcasting as BLE beacon signals to mobile devices.

Space owner: The entity or individual responsible for managing a physical space, defining and maintaining the access control policies that govern the permitted functionalities of mobile devices within their controlled premises.

3.4. The jumbo beacons

Transmitting large amounts of data, such as digitally signed access control policies, directly within a single BLE beacon is challenging due to inherent payload size constraints, typically limited to 160 bits of configurable data (e.g., Major and Minor value fields each with 2 bytes, UUID field with 16 bytes, and other protocol specific fields).²⁷ To overcome this limitation, we introduce the concept of a jumbo beacon, which logically aggregates multiple fragmented standard BLE beacons to collectively transmit larger policies. In order to achieve that, we customized the BLE beacon structure by repurposing traditional beacon fields into the following specialized fragmentation fields to facilitate accurate data reassembly (this is illustrated in Figure 2):

Figure 2.

Customized bluetooth low energy (BLE) beacon structure illustrating how standard beacon fields are repurposed to encode fragmentation parameters, including sequence, offset, and size, to enable accurate jumbo beacon reassembly.

Sequence field (8 bits): Uniquely identifies each jumbo beacon.

Size field (4 bits): Denotes the total number of fragments comprising a jumbo beacon.

Offset field (4 bits): Specifies the fragment’s sequential position within the jumbo beacon.

Data field (144 bits): Holds segments of the overall data payload.

Utilizing these fragmentation parameters, recipient devices can accurately reconstruct the overall data payload by logically combining data payload of beacon fragments (concatenating data fields of our custom beacons in order based on their offest values). This approach effectively overcomes BLE payload size limitations, enabling the reliable transmission of large data payload.

3.5. Operations

This section describes essential system operations, including configuring and deploying access policies, scanning BLE beacons, reconstructing and verifying beacon fragments, enforcing policies, and revoking them when required. For ease of reference, we summarize all notations used in Table 2.

Table 2.
System design notations.

Term Definition

S Space owner S is an owner of a controlled physical location. It has a unique identifier, $S_{ID}$ .

$S_{PK}$ Space owner S’s public key.

$S_{SK}$ Space owner S’s private key.

$P$ Access control policy $P$ represents the policy to be enforced in the user’s mobile device. $P$ consists of concatenation of $n$ bits, where each bit corresponds to a specific permission ( $p_{1}, p_{2}, \dots, p_{n}$ ), and a unique identifier for an application ( ${app}_{id}$ ). Thus, $P = (p_{1}, p_{2}, \dots, p_{n} ∥ {app}_{id})$ .

T BLE beacon transmitter hardware T that transmits configurable BLE beacons to nearby BLE-enabled devices.

$T_{t}$ Time delay between consecutive beacons transmitted by T (a.k.a. advertising/broadcast interval).

$T_{p}$ Transmission power (Tx) used by transmitter T to transmit beacons.

$β$ BLE beacon with standard beacon size but with our proposed customized fields structure. It consists of sequence, size, offset, and data payload ( $β_{d}$ ). The details of the fields are highlighted in Section 3.4.

$β_{T}$ BLE beacon $β$ transmitted by BLE beacon transmitter hardware T.

$B$ Jumbo beacon holds a space owner identity responsible for transmitting fragmented beacons ( $B_{S}$ ), sequence field value of the fragmented beacons ( $B_{seq}$ ), payloads of all $n$ fragmented beacons ( $β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}}$ ), and a timestamp that represents the last time any of the fragmented beacons were received ( $B_{t}$ ). Its final representation: $B = (B_{S}, B_{seq}, (β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}}), B_{t})$ .

ACM ACM software implemented as part of the operating system of a mobile device.

$S i g n (k, m)$ A digital signature of message $m$ signed by a private key $k$ .

$V e r i f y (k, m, s)$ A verification of signature $s$ on message $m$ , using public key $k$ .

Term	Definition
S	Space owner S is an owner of a controlled physical location. It has a unique identifier, $S_{ID}$ .
$S_{PK}$	Space owner S’s public key.
$S_{SK}$	Space owner S’s private key.
$P$	Access control policy $P$ represents the policy to be enforced in the user’s mobile device. $P$ consists of concatenation of $n$ bits, where each bit corresponds to a specific permission ( $p_{1}, p_{2}, \dots, p_{n}$ ), and a unique identifier for an application ( ${app}_{id}$ ). Thus, $P = (p_{1}, p_{2}, \dots, p_{n} ∥ {app}_{id})$ .
T	BLE beacon transmitter hardware T that transmits configurable BLE beacons to nearby BLE-enabled devices.
$T_{t}$	Time delay between consecutive beacons transmitted by T (a.k.a. advertising/broadcast interval).
$T_{p}$	Transmission power (Tx) used by transmitter T to transmit beacons.
$β$	BLE beacon with standard beacon size but with our proposed customized fields structure. It consists of sequence, size, offset, and data payload ( $β_{d}$ ). The details of the fields are highlighted in Section 3.4.
$β_{T}$	BLE beacon $β$ transmitted by BLE beacon transmitter hardware T.
$B$	Jumbo beacon holds a space owner identity responsible for transmitting fragmented beacons ( $B_{S}$ ), sequence field value of the fragmented beacons ( $B_{seq}$ ), payloads of all $n$ fragmented beacons ( $β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}}$ ), and a timestamp that represents the last time any of the fragmented beacons were received ( $B_{t}$ ). Its final representation: $B = (B_{S}, B_{seq}, (β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}}), B_{t})$ .
ACM	ACM software implemented as part of the operating system of a mobile device.
$S i g n (k, m)$	A digital signature of message $m$ signed by a private key $k$ .
$V e r i f y (k, m, s)$	A verification of signature $s$ on message $m$ , using public key $k$ .

BLE: bluetooth low energy; ACM: access control module.

Safe-mode by default: Our system adopts a whitelist-based approach, where all mobile device applications and features (e.g., camera, microphone) are disabled by default. Access is granted only when explicitly authorized through policies enforced by the space owner. This ensures robust security guarantees, eliminating potential risks associated with unauthorized or overlooked device functionalities.

Always-on bluetooth functionality: Our system enforces Bluetooth functionality to remain continuously active on the user’s mobile device, preventing users from disabling it. This guarantees persistent reception of BLE beacon signals and ensures uninterrupted delivery of location-specific access control policies. If Bluetooth is turned off for any reason, preventing the mobile device from receiving beacon signals, the ACM relies on a predefined threshold timer to maintain enforcement integrity. Once this threshold is reached without receiving any beacon fragments related to currently applied policies, the ACM immediately revokes the active policy. This mechanism ensures that access is not retained in the absence of continuous beacon reception.

Configuration of access policy: We represent an access control policy as $P = (p_{1}, p_{2}, \dots, p_{n} | | {app}_{id}$ ). Each $p_{i}$ is a bit that corresponds to a specific permission (e.g., use of the camera, microphone, location sharing, etc.). If $p_{i}$ is set to “1,” the corresponding permission is granted; otherwise, it is denied. In addition to the permission bits, the policy includes an application identifier, ${app}_{id}$ , that specifies the target application for which the permissions apply. To support global policies, the system allows setting the ${app}_{id}$ to a wildcard ( ${app}_{id}$ = “*”), indicating that the specified permissions should be granted to all applications on the mobile device. Once defined, the policy $P$ is concatenated with the space owner identifier ( $S_{ID})$ , then it is digitally signed using the space owner’s private key ( $S_{SK}$ ), resulting in a signed policy: $Sign (S_{SK}, (P ∥ S_{ID}))$ .

Deployment of access policy: After configuring an access control policy $P$ , a space owner S deploys this policy to owned BLE beacon transmitters. This deployment involves splitting the complete payload: $P ∥ S_{ID} ∥ Sign (S_{SK}, (P ∥ S_{ID})$ ), which typically exceeds the 160-bit limit of a single beacon, into $n$ separate fragments. Each beacon fragment contains part of the original payload and is populated with fragmentation parameters as follows: The sequence field is assigned a unique identifier (indicating that these fragments belong to the same policy), the size field specifies the total number of fragments ( $n$ ), and the offset field indicates the fragment’s sequential position (ranging from $0$ to $n - 1$ ). Finally, the $n$ beacon fragments ( $β_{1}, β_{2}, \dots, β_{n}$ ) are configured onto transmitter devices (T) owned by S. The fragments may be distributed across multiple transmitters, which are strategically placed throughout areas requiring policy enforcement.

BLE beacon scanning: When a user roams within a controlled area, their mobile device—running our embedded ACM—continuously scans and collects incoming BLE beacon signals. Each received beacon fragment is temporarily stored in memory by the ACM for subsequent processing.

Access policy construction: Upon receiving each beacon, the ACM examines its sequence field to identify the unique policy identifier. The module then checks if all $n$ beacon fragments associated with the same policy have been received. This check is performed by retrieving all stored beacons sharing the same sequence field and using their respective size and offset fields to ensure completeness. Once all fragments are confirmed to be received, the ACM reconstructs the jumbo beacon $B_{S}$ utilizing the offest values to concatenate all of the fragments’ data payloads in the correct order: $(β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}})$ . Additionally, the ACM keeps a timestamp value that represents the last time any of the $n$ fragments were received. The reconstructed jumbo beacon’s data payload represents the policy and its digital signature: $(β_{1_{d}} ∥ β_{2_{d}} ∥ \dots ∥ β_{n_{d}}) = (P ∥ S_{ID} ∥ Sign (S_{SK}, (P ∥ S_{ID})))$ . Thus, the final representation of the jumbo beacon is: $B = (B_{S}, B_{seq}, (P ∥ S_{ID} ∥ Sign (S_{SK}, (P ∥ S_{ID}))), B_{t})$ .

Access policy enforcement: To ensure authenticity and integrity, the ACM verifies the digital signature using the space owner’s public key: $Verify (S_{P K}, (P ∥ S_{ID}), Sign (S_{SK}, (P ∥ S_{ID})))$ . The public key ( $S_{PK}$ ) is retrieved via a trusted Public Key Infrastructure (PKI). If the verification fails, the jumbo beacon and all associated fragments are discarded. If verification succeeds, the access policy $P$ is enforced on the user’s mobile device. Enforcement is performed by granting the application identified by ${app}_{id}$ the set of permissions ( $p_{1}, p_{2}, \dots, p_{n}$ ) for which the corresponding bits are set to “1.” If ${app}_{id}$ is set to the wildcard “*”, the granted permissions apply globally to all applications on the device.

Revocation of access policy: The ACM is configured with a threshold value representing a specific time interval. If the mobile device does not receive beacon fragment ( $β$ ) corresponding to a particular stored jumbo beacon ( $B$ ), where $β$ ’s sequence is equal to $B_{seq}$ , within the threshold interval ( $B_{t} < t h r e s h o l d$ ), the ACM revokes the associated policy and removes all beacon fragments associated with $B$ from storage.

Furthermore, to improve robustness against rogue beacon attacks and unauthorized certificate injection, our architecture requires users to physically scan a QR code at the entrance of the controlled space. This QR code encodes both the space owner’s unique identifier ( $S_{ID}$ ) and a public key certificate issued by a trusted PKI authority. Upon scanning, the ACM imports and locally stores this certificate, thereby binding the cryptographic identity to the specific space. Importantly, public keys are never transmitted within BLE beacon broadcasts. It is worth highlighting that although the PKI architecture is centralized, once the certificate authenticity is verified and pinned on the user’s device through the QR provisioning process, subsequent policy verification no longer depends on the central PKI infrastructure. If a user enters the controlled space without completing QR-code onboarding, the ACM lacks the trusted certificate required to verify received policies. As a result, the device remains in its default safe-mode state, where all applications and device functionalities are disabled. This ensures that, without successful trust establishment, no permissions are granted and the system fails securely by design. Access control policies broadcast by BLE beacons in the zone must be digitally signed using the associated private key; the ACM verifies only those policies using the preloaded PKI-issued certificate. This design physically couples access to the secure space with trust establishment and prevents attackers from broadcasting unauthorized policies, whether self-signed or signed using malicious certificates.

4. Implementation

This section details the prototype implementation of our proposed BLE beacon-based access control system, highlighting essential technical components and design considerations.

4.1. Implementation overview

We developed a prototype implementation of the proposed location-based access control system on Android, focusing on demonstrating the practicality and effectiveness of our decentralized BLE beacon-based approach. The implementation consists solely of a client-side software module—referred to as the ACM—integrated directly as a native system service within the Android operating system. This integration ensures continuous operation, prevents users from disabling or interrupting the module, and guarantees persistent enforcement of location-specific access control policies.

For beacon transmission, we utilized commercial BLE beacon transmitters from Feasycom. Beacon configuration—such as setting beacon payload content, broadcast interval, and transmission power—was performed using Feasycom’s proprietary mobile application.

Our ACM was implemented in Java,²⁸ aligning with the standard programing practices for native Android OS system services. We customized several Android system APIs to ensure secure and uninterrupted module operations. Specifically, we modified the Android Bluetooth API to prevent users from disabling Bluetooth, thereby ensuring continuous beacon reception. Additionally, modifications were made to the application launching and feature-enabling mechanisms of Android, enforcing our whitelist-based approach where all applications and device features are disabled by default until explicitly enabled by a verified access policy.

The received BLE beacon fragments are temporarily stored and managed purely in-memory, providing efficient reconstruction and verification of complete access control policies without additional persistent storage overhead.

4.2. Operations implementation

Safe-mode by default: To enforce a whitelist-based security approach, we modified the startActivityAsUser() function within the Android ActivityTaskManagerService class. This modification enables our ACM to manage and restrict application launches effectively. Additionally, we altered the grantRuntimePermission() function within the PermissionManagerService class to control the activation of specific device features, such as the camera, microphone, and location sharing. By default, all applications and device features remain disabled unless explicitly authorized by validated access control policies.

Always-on Bluetooth functionality: We ensured that Bluetooth functionality remains continuously active by modifying the disable() function within Android’s BluetoothManagerService class. This customization effectively prevents users from disabling Bluetooth, thus guaranteeing uninterrupted beacon reception and policy enforcement by our ACM.

Configuration of access policy: To configure an access policy, the space owner selects the permissions to be granted by setting the corresponding bits ( $p_{1}, p_{2}, \dots, p_{n}$ ) in the policy. The target application is identified by specifying its unique identifier ( ${app}_{id}$ ), which corresponds to the application’s package name in Android, as each app is uniquely identified by its package name. To ensure authenticity and integrity, the complete policy is digitally signed using the Elliptic Curve Digital Signature Algorithm (ECDSA) with a 256-bit key and SHA-256 as the hashing function. ECDSA was chosen for its relatively smaller key size compared to alternative algorithms offering the same level of security.

Deployment of access policy: After digitally signing an access control policy along with the space owner identifier, we split the signed payload into segments fitting the 160-bit payload limitation of BLE beacons. Each fragment was then configured into BLE beacon transmitters along with necessary fragmentation parameters (sequence, size, offset).

BLE beacon scanning: We leveraged Android’s native BLE scanning APIs within the ACM—specifically utilizing the BluetoothAdapter, ScanSettings, and BluetoothLeScanner classes—to continuously detect, receive, and temporarily store incoming beacon fragments in-memory for further processing.

Access policy construction: The ACM implements an in-memory reconstruction mechanism that assembles jumbo beacons from received BLE fragment beacons. Each incoming fragment is parsed and temporarily stored in an indexed in-memory data structure based on its sequence field, which uniquely identifies the associated jumbo beacon. For each fragment, the ACM extracts the size and offset fields to determine the total number of fragments expected and their correct order in the final payload.

As new fragments arrive, the ACM checks for completeness by verifying whether all offsets from 0 to $n - 1$ (where $n$ is the value of the size field) have been received for the same sequence. Once all expected fragments are collected, the ACM proceeds to reassemble the jumbo beacon by concatenating the data fields of the fragments in order according to their offset values. The result is a single, contiguous payload representing the signed access control policy and spacer owner identifier, ready for verification and enforcement.

Access policy enforcement: The ACM uses the ECDSA algorithm to verify the authenticity and integrity of the reconstructed policies by validating their digital signatures. Upon successful verification, the ACM enforces the policy on the mobile device by enabling permitted applications and device features. This enforcement leverages our modifications of the startActivityAsUser() function within the Android ActivityTaskManagerService class and the grantRuntimePermission() function within the PermissionManagerService class.

Revocation of access policy: We implemented a timing mechanism within the ACM to periodically check for beacon fragment reception. If beacon fragments associated with a previously enforced policy are not received within a predefined threshold interval, the ACM automatically revokes the corresponding policy, disables previously permitted applications and features (leveraging similar functions and classes used for policy enforcement), and discards the corresponding jumbo beacon along with all related beacon fragments from its in-memory storage.

5. Evaluation

This section presents a comprehensive evaluation of our proposed system, focusing on key performance dimensions: Policy generation and reconstruction latency, jumbo beacon delivery efficiency, delivery success rate under varying transmission power and distance, and estimated energy consumption of the BLE transmitter. In this evaluation, we used BLE beacon transmitters from Feasycom of model FSC-BP104D.²⁹ These transmitters support long-range broadcasts, feature an extended battery life of up to 10 years, and comply with IP67 waterproof standards, making them suitable for diverse operational environments. The mobile device used was a Samsung Galaxy J7 model with 2 GB of RAM and 1.6 GHz Octa-core Exynos 7870 processor. We conduct both experimental measurements and theoretical comparisons to assess system responsiveness, delivery reliability, and energy efficiency. The results demonstrate that our system operates within lightweight bounds suitable for real-time deployment, while highlighting important trade-offs between performance and configuration parameters such as broadcast interval and transmission power.

5.1. Jumbo beacon generation

We evaluate the performance of generating a jumbo beacon on the space owner’s side. This process includes digitally signing the access control policy $P$ along with the space owner’s identifier ( $S_{ID}$ ) using the ECDSA algorithm with a 256-bit key and SHA-256 as the hash function, followed by fragmenting the signed payload into multiple standard BLE beacon packets.

The time required to digitally sign the policy is approximately $4 ms$ on average. This signing step is performed once per policy and introduces minimal latency to the overall configuration and deployment pipeline.

After signing, the resulting payload is split into 160-bit fragments, each formatted into a BLE beacon payload. For a typical 7-fragment jumbo beacon, the total time taken to construct and populate all fragments is measured at approximately $1.5 ms$ .

In total, the complete jumbo beacon generation process—including signing and fragment formatting—takes about $5.5 ms$ , confirming that policy generation is lightweight and suitable for real-time or on-demand policy deployment.

5.2. Jumbo beacon reconstruction

We first evaluate the time required by the ACM to reconstruct a jumbo beacon from the received BLE fragments in order to read the transmitted access policy. This operation is handled in-memory by the ACM. Our measurements show that the time required to process each beacon fragment (i.e., parse and store) averages $2.9 ms$ . The total jumbo beacon reconstruction latency increases linearly with the number of fragments. For example, reconstructing a 7-fragment policy takes approximately $20.3 ms$ on average.

Once the complete payload is reconstructed, the ACM proceeds to verify the digital signature to ensure the authenticity and integrity of the policy. The ECDSA signature verification operation takes approximately $1 ms$ on average.

Overall, the average latency for reconstructing and verifying a jumbo beacon with 7 fragments is $21.3 ms$ , demonstrating that the end-to-end enforcement pipeline is lightweight and well-suited for real-time operation.

5.3. Theoretical vs. measured delivery time of jumbo beacon

In this experiment, we evaluate the time required to receive complete jumbo beacons under different BLE broadcast intervals. To eliminate the influence of transmission power, we set the transmission power ( $T_{p}$ ) to its maximum supported value of $2.5 dBm$ , and fixed the distance between the BLE transmitter and the mobile device at 10 meters to ensure a stable, unobstructed communication range.

We varied the BLE broadcast interval ( $T_{t}$ ) across four values: $100 ms$ , $500 ms$ , $1000 ms$ , and $2000 ms$ . For each configuration, we transmitted a set of 100 jumbo beacons, with each beacon consisting of 7 fragments, totaling $n = 700$ fragments. We measured the time required by the mobile device to receive all 100 complete jumbo beacons and computed the average delivery time per beacon.

The average theoretical delivery time is computed by multiplying the total number of fragments by the advertising interval and then dividing by the total number of jumbo beacons: $T_{theoretical} = ((n \times T_{t}) / b)$ . In our conducted experiment, $n = 700$ is the total number of fragments and $b = 100$ is the number of jumbo beacons. Table 3 summarizes both the theoretical and measured delivery times (in seconds) for each configuration, while Figure 3 plots the measured overhead percentage between theoretical and actual delivery time.

Figure 3.

Measured overhead percentage between theoretical and actual delivery time for 100 jumbo beacons ( $n = 700$ fragments) under varying broadcast intervals ( $T_{t}$ ). (Distance = $10 m$ , $T_{p} = 2.5 dBm$ ).

Table 3.

Avg. theoretical vs. measured delivery time for 100 jumbo beacons ( $n = 700$ fragments) at different $T_{t}$ . (distance = $10 m$ , $T_{p}$ = $2.5 dBm$ ).

$T_{t}$ (ms)	Theoretical (s)	Measured (s)	Overhead (%)
100	0.7	0.9	35%
500	3.5	4.7	34%
1000	7.0	8.4	20%
2000	14.0	16.1	15%

As shown in the results, the measured delivery time consistently exceeds the theoretical baseline, with overhead ranging from 15% to 35%. The highest overhead is observed at the lowest broadcast interval ( $T_{t}$ = $100 ms$ ), where the average delivery time reaches 0.9 seconds—35% higher than the theoretical 0.7 seconds. This overhead is primarily attributed to BLE stack scheduling delays, timing jitter, and scan response latency on the mobile device.

As $T_{t}$ increases, the relative overhead decreases, indicating more stable and predictable delivery behavior. At $T_{t}$ = $2000 ms$ , the measured delivery time is 16.1 seconds, only 15% higher than the theoretical 14.0 seconds. These findings confirm that although lower intervals offer faster theoretical delivery, they are more sensitive to real-world timing constraints, whereas higher intervals provide more consistent performance across large-scale beacon transmissions.

5.4. Impact of transmission power on delivery success rate

In this experiment, we evaluate the impact of transmission power ( $T_{p}$ ) on the delivery success rate of jumbo beacons across different distances. To isolate the effect of power and range, we fixed the BLE broadcast interval at $T_{t}$ = $100 ms$ and conducted all experiments in an outdoor area to avoid obstacles and ensure clear line-of-sight communication. For each configuration, we transmitted 100 jumbo beacons, where each jumbo beacon consists of 7 BLE fragments.

The delivery success rate is defined as the percentage of jumbo beacons successfully received by the mobile device within the theoretical delivery time window, computed as $T_{theoretical} = n \times T_{t}$ , where $n = 700$ is the total number of transmitted fragments. For example, at $T_{t}$ = $100 ms$ , the theoretical window is $70, 000 ms$ . A jumbo beacon is counted as successfully delivered only if all 7 of its fragments are received within this window.

Figure 4 shows the resulting success rates across different distances and transmission power levels. At a short range of $10 m$ , the success rate remains consistently high across all power levels, reaching up to 99.6% at $T_{p}$ = $2.5 dBm$ . At $50 m$ , the performance remains acceptable, with an 83.6% success rate at $2.5 dBm$ power and above 70% for $T_{p} \geq$ $0 dBm$ . However, at $100$ and $150 m$ , success rates decrease sharply—dropping to 42.3% and 11.0% at $2.5 dBm$ , respectively, and reaching 0% at lower power levels.

Figure 4.

Delivery success rate vs. transmission power ( $T_{p}$ ) for different distances. Based on $n = 700$ transmitted fragments and $T_{t}$ = $100 ms$ .

These results demonstrate that higher transmission power is essential for maintaining reliable jumbo beacon delivery over longer distances. In contrast, at shorter ranges, lower power settings are sufficient for stable performance. This insight is valuable for guiding real-world deployments, enabling developers to adjust $T_{p}$ dynamically based on spatial constraints and desired delivery reliability.

5.5. Beacon delivery in indoor non-line-of-sight environments

In addition to our outdoor experiments, we conducted preliminary evaluations in indoor environments to observe how physical obstructions affect beacon delivery. We found that BLE beacon performance degrades significantly when the transmitter and the mobile device are not within line of sight. In particular, barriers such as concrete walls, metal partitions, or thick glass noticeably attenuated signal strength and introduced delays or losses in fragment reception.

In several cases, the mobile device failed to receive a complete set of fragments within the expected theoretical time window, even at short distances (e.g., 5–10 m) when obstructed by a wall. These results highlight an important limitation of BLE in non-line-of-sight scenarios, which must be accounted for during system deployment. Optimal placement of transmitters in indoor spaces should therefore prioritize open line-of-sight coverage or consider redundancy to mitigate the effects of physical interference.

5.6. Estimated energy consumption of the BLE transmitter

To evaluate the energy consumption of the BLE transmitter, we focused on estimating the average current draw under various broadcast configurations. Our evaluation considers various transmission power levels. Since such measurements are time-consuming, we first performed a direct experiment using the configuration expected to yield the highest power consumption—namely, the maximum supported transmission power ( $T_{p}$ = $2.5 dBm$ ) and the shortest advertising interval ( $T_{t}$ = $100 ms$ ).

In this setting, we measured the time taken for the transmitter to consume 1% of its battery capacity. The transmitter is powered by two AAA 1.5 V zinc-carbon batteries in series, providing a total capacity of approximately $600 mAh$ . A 1% drop corresponds to $6 mAh$ . The battery level dropped by 1% after approximately 70 hours, allowing us to calculate the average current consumption as approximately $85.71 μ A$ .

This value reflects the current consumption for the configuration of $T_{p}$ = $2.5 dBm$ and $T_{t}$ = $100 ms$ . To estimate energy consumption for the other configurations, we applied extrapolation based on known relationships between transmission power, advertising interval, and current draw. These extrapolated values enable us to predict battery behavior under various deployment scenarios without requiring extensive long-term measurements for every configuration. Figure 5 presents the estimated energy consumption across various transmission power levels and broadcast intervals, derived from our measured baseline. The results confirm that energy usage increases with higher transmission power and shorter intervals, highlighting the trade-off between delivery reliability and battery efficiency. Notably from previously discussed evaluation (in Section 5.4), lower intervals and higher power settings improve delivery performance, but at the cost of increased energy consumption. These findings help inform the selection of BLE transmitter settings that balance power efficiency with performance requirements.

Figure 5.

Estimated energy consumption ( $μ$ A) across varying broadcast intervals ( $T_{t}$ ) and transmission power levels ( $T_{p}$ ).

6. Discussion

This section explores several key design aspects, deployment strategies, and practical considerations of our proposed system. We highlight how the system achieves fine-grained and location-aware policy enforcement, supports flexible and scalable deployment across physical spaces, and enables advanced capabilities such as dwell-time enforcement and path-based access control. Additionally, we discuss system-level design choices—such as Bluetooth availability enforcement and support for variable permission sets—that enhance both the security guarantees and adaptability of our solution. These discussion points collectively demonstrate the practicality, robustness, and extensibility of our system in diverse real-world environments.

6.1. Fine-grained access control

Our system enables space owners to define and enforce highly fine-grained access control policies based on both application identity and physical location. Each policy specifies a set of permissions—such as camera, microphone, or location access—and the specific application (via its package name) to which those permissions apply. This allows space owners to precisely control which functionalities are accessible on a per-application basis.

Moreover, the system inherently supports spatial granularity. By deploying BLE beacon transmitters in specific physical areas, space owners can associate different policies with different zones. For example, access to the camera might be permitted in an open office area but disabled in a meeting room or secure zone. This design empowers space owners to tailor access control decisions not only to user context but also to the physical environment in which the device is operating.

The combination of application-level and location-specific control enables practical enforcement of real-world security policies, such as allowing messaging apps only in designated lounge areas or restricting sensor access in confidential meeting rooms. This flexibility makes the system suitable for a wide range of deployment scenarios, including corporate, healthcare, governmental, and industrial environments.

6.2. Policy deployment across multiple transmitters

Our system supports the distribution of a single access control policy across multiple BLE beacon transmitters by splitting the associated jumbo beacon fragments among them. As illustrated in Figure 6, each transmitter is configured to broadcast a distinct subset of the total fragments required to reconstruct the complete policy. This design enables parallel transmission of fragments, significantly reducing the time required for a mobile device to receive all necessary fragments for jumbo beacon reconstruction.

Figure 6.

Parallel policy deployment: Fragments of a single policy are broadcast from multiple transmitters and received simultaneously.

In addition to improving policy delivery latency, this approach enhances the overall energy efficiency of the system. By dividing the workload among multiple transmitters, the broadcasting frequency of each individual device can be reduced, thereby extending the battery lifetime of each unit. This makes the system more sustainable and scalable, particularly in large deployments such as enterprise buildings or campus-wide environments, where continuous operation and long-term maintenance efficiency are critical.

Furthermore, different transmitters can be configured to broadcast overlapping fragments, providing redundancy that enhances resilience against localized beacon failures. This is illustrated in Figure 7.

Figure 7.

Four transmitters configured with overlapping beacon fragments. The mobile device can reconstruct the complete jumbo beacon even if one transmitter fails.

6.3. Enforcing dwell time via controlled broadcast intervals

Our system supports the enforcement of dwell time—i.e., the minimum amount of time a user must remain within a specific physical area—by leveraging the configurable broadcast interval of BLE transmitters. Since each transmitter periodically broadcasts beacon fragments, we can control the rate at which fragments are emitted by adjusting the broadcast interval ( $T_{t}$ ). By doing so, we effectively control the time it takes for a mobile device to collect all fragments required to reconstruct a complete jumbo beacon and enforce the corresponding access policy. Figure 8 illustrates two users interacting with a BLE transmitter. User A remains within the transmitter’s range for the full duration required to receive all fragments—i.e., $7 T_{t}$ —successfully reconstructing the jumbo beacon and being granted access. In contrast, User B leaves the broadcast range prematurely, before the full $7 T_{t}$ has elapsed, and thus fails to collect all necessary fragments. As a result, User B is unable to reconstruct the policy and is denied access. This example highlights the system’s ability to enforce minimum dwell time as a prerequisite for policy enforcement.

Figure 8.

User must remain within the transmitter’s range for $7 T_{t}$ to receive all fragments ( $β_{1}$ to $β_{7}$ ). Access is granted immediately after the complete jumbo beacon is reconstructed.

This mechanism allows space owners to intentionally delay policy enforcement until the user has spent a predetermined amount of time in a specific zone. For example, in a secure meeting room, the BLE transmitter could be configured with a longer broadcast interval, requiring the user to remain in the area for several seconds before their mobile device has received all necessary fragments to activate permissions such as screen sharing or document access.

This strategy enhances security in sensitive environments by preventing quick drive-by access and ensuring that users are physically present and stationary long enough to satisfy the intended access control requirements.

6.4. Path-based access policy delivery

Our system enables the enforcement of physical movement patterns by distributing the fragments of a single jumbo beacon across multiple BLE transmitters placed along a predefined path. Each transmitter broadcasts a unique subset of the fragments associated with a given access policy. As illustrated in Figure 9, a mobile device must move through the designated path and sequentially collect all fragments in order to reconstruct the complete jumbo beacon and activate the corresponding policy.

Figure 9.

Jumbo beacon fragments $β_{1}$ to $β_{7}$ are distributed across transmitters: T1, T2 and T3. The user must traverse all locations to collect the full set and reconstruct the access policy.

This capability is particularly useful in scenarios where access must be granted only after the user passes through specific locations. For example, in a high-security research facility, access to sensitive data might require the user to physically move through multiple verification checkpoints—such as an identity validation zone, a security scan room, and a decontamination area. Each area is equipped with a BLE transmitter broadcasting different fragments of the same policy. The policy will only be enforced once the mobile device has collected all fragments by passing through all required zones.

This approach strengthens location assurance and ensures that users follow a predefined physical workflow before being granted access, reducing the risk of shortcutting or bypassing essential security steps.

6.5. Path-based access with station-specific dwell time

Our system supports not only path-based access policy delivery but also the enforcement of minimum dwell times at each station along the path. This is achieved by strategically distributing jumbo beacon fragments across multiple BLE transmitters placed at different physical locations (stations) and configuring each transmitter with a specific broadcast interval ( $T_{t}$ ). By controlling the fragment count and $T_{t}$ at each station, the system enforces that users must remain in the coverage area of each transmitter for a predefined duration before proceeding to the next.

This combination enables more than just spatial path enforcement—it also allows for temporal control at each step. Only after collecting all fragments broadcast at a given station, the user can proceed toward gathering fragments at the next station. The complete access control policy (jumbo beacon) is reconstructed only after the user has passed through all required stations and satisfied their respective dwell time conditions.

Figure 10 illustrates this mechanism. A user follows a predefined path consisting of three stations, each broadcasting a subset of the jumbo beacon fragments. Each transmitter is configured with a different broadcast interval, resulting in varying dwell time requirements (e.g., $2 T_{t 1}$ , $3 T_{t 2}$ , $2 T_{t 3}$ ). The access policy is enforced only after the user has visited all stations and collected the required fragments within the expected timeframes.

Figure 10.

Each transmitter transmits a subset of jumbo beacon fragments at different broadcast intervals. Users must dwell at each station long enough to receive all fragments. Access is granted only after the final station is completed and the full policy is reconstructed.

A real-world example where such a mechanism is particularly suitable is crowd management during large events such as concerts, sports events, or public festivals. Authorities can enforce controlled flow by requiring attendees to move along predefined checkpoints—such as entry gates, health screening stations, and holding areas—where they must remain for a minimum duration. For example, attendees might be required to stay for a few seconds at a temperature screening zone and a few minutes at a crowd dispersal buffer area. Only after visiting all checkpoints and fulfilling the time conditions will their device be granted access to services such as digital tickets, maps, or entry activation.

This capability offers a lightweight, infrastructure-free method for enforcing structured and safe movement through physical spaces while ensuring compliance with operational or safety procedures.

6.6. Bluetooth availability enforcement

Our system relies on the continuous availability of Bluetooth to receive and enforce location-based access control policies. This requirement is enforced by the ACM, which operates in kernel mode and ensures that Bluetooth remains enabled at all times. Any attempt by the user to disable Bluetooth through the system settings or app-level interfaces is blocked by the ACM at the system level.

While a user may attempt a physical-level attack—such as tampering with or disabling the Bluetooth chip—such attacks are considered beyond the scope of our threat model. However, even in the presence of such hardware tampering, our system maintains a strong security posture. This is achieved through our safe-mode-by-default design, where all permissions and application access are denied unless explicitly granted by a verified access control policy. As a result, in the absence of beacon reception (due to physical tampering or environmental factors), the mobile device remains locked down, preventing any unauthorized functionality.

This mechanism ensures that policy enforcement fails securely, thereby maintaining the integrity of the access control guarantees even under hardware-level denial-of-service attempts.

6.7. Support for variable permission sets

One of the key advantages of our system is its flexibility in supporting access control policies with varying numbers of permissions. This is achieved by defining a parameter $n$ , which represents the total number of supported permission types in the system. Each permission is encoded as a single bit in the policy structure, allowing for compact and efficient representation.

By adjusting $n$ , the system can be easily extended to support additional permissions beyond the current set (e.g., camera, microphone, location sharing). For instance, to support new permissions such as file sharing or call initiating, additional bit positions can be appended to the existing policy bitstring format. The policy parsing, enforcement, and signature verification mechanisms remain unchanged, making this extension seamless.

This design ensures forward compatibility and scalability. Space owners can define fine-grained policies tailored to specific environments without requiring architectural changes, allowing the system to adapt to evolving security requirements and device capabilities.

6.8. Integrity of beacons

To ensure the integrity of access control policies delivered over BLE, each policy is digitally signed, along with the spacer owner identifier, by the space owner’s private key prior to fragmentation. The resulting payload is then split into multiple BLE beacon fragments, each carrying a portion of the data along with essential metadata fields, including sequence, size and offset.

Any tampering with these fragments—whether in their metadata or payload—leads to a failure in policy reconstruction or signature verification. Specifically:

If any of the metadata fields (sequence, size, and offset) are altered, the ACM will not be able to reconstruct the complete jumbo beacon correctly.

If the data portion of any fragment is tampered with, the reconstructed policy will no longer match the original signed message, and signature verification will also fail.

In all such cases, the policy is discarded. After fragment reassembly, the digital signature of the access policy is verified using the space owner’s public key stored within the ACM, ensuring that even correctly formatted beacon transmissions signed by unauthorized entities (e.g., self-signed or malicious certificates) are detected and rejected. By introducing a PKI-based QR code onboarding process, the proposed approach links cryptographic trust to verified space ownership and physical presence at the secure zone boundary. Consequently, modified or injected beacon fragments and unauthorized policies are rendered ineffective, and even if an attacker deploys a rogue beacon, the device will ignore it unless the corresponding public key has been legitimately provisioned through direct user interaction via the QR code.

6.9. Robustness against identified threats

This section discusses how the proposed system addresses the threats identified in Section 3.2. The following design choices and enforcement mechanisms ensure that the system maintains its security guarantees under adversarial conditions:

Malicious user: The ACM is introduced as a privileged system service within the mobile operating system and cannot be disabled or bypassed by the end-user. All permissions are denied by default, and only explicitly verified policies can grant access. Attempts to tamper with the ACM or bypass policy enforcement are inherently blocked by the operating system layer.²⁶ Previous work has also deployed their access control logic as system services to ensure integrity and robustness against tampering.⁹ However, a feasible attack vector that could compromise the ACM’s integrity is device rooting,³⁰ which grants users superuser privileges and enables them to modify or remove any system component, including the ACM. This type of attack is considered a side-channel threat and falls outside the primary scope of this work. Indeed, proven techniques and mechanisms exist to detect and prevent rooting and device tampering attacks, effectively mitigating these risks by verifying device integrity and ensuring secure boot processes.^31,32 Moreover, a software-based integrity check can be integrated into the QR onboarding process (e.g., Android’s Play Integrity API ^³³) to verify device integrity before provisioning the space-owner certificate.

Rogue BLE beacon transmitter: Each access control policy is digitally signed by the legitimate space owner before being broadcast. Any rogue transmitter that attempts to inject a fake or unauthorized policy will fail signature verification, and the associated beacon fragments will be discarded without enforcement.

Replay BLE beacons: An attacker may capture legitimate beacon fragments and replay them later, either within the same physical area or in a different location. This type of attack is considered physical, as it requires the adversary to be near the premises to place a rogue transmitter. To mitigate this, several lightweight mechanisms can be incorporated into the system. First, the policy payload can include an expiry timestamp as part of the signed data. The ACM can check this timestamp upon reconstruction and discard any expired policies, ensuring that replayed beacons are ineffective after a specified time window. Alternatively, policies can carry a rolling sequence identifier assigned by the space owner. The ACM can track the most recent valid sequence per space and reject any older or duplicate values. Additionally, if beacon fragments with inconsistent space owner identifiers or conflicting signatures are received simultaneously, the ACM can detect this inconsistency and raise a flag or warning. In such cases, or under suspected replay activity, the ACM may be configured to reject all policies and fall back to the default-deny state to preserve security. These mechanisms are easy to integrate into the system design and provide effective protection against delayed or cross-location replay attacks.

BLE signal jamming: An attacker may attempt to block beacon signals to prevent policy delivery. In such cases, the ACM is unable to reconstruct a valid jumbo beacon and therefore enforces no permissions. As the system follows a whitelist (default-deny) model, the absence of policy reception results in no access being granted, preserving system security even under denial-of-service conditions.

These combined defenses ensure that the proposed system maintains its integrity and enforcement guarantees, even in the presence of active adversaries or challenging operating conditions.

6.10. User location privacy preservation

Our system design supports the preservation of user location privacy. BLE transmitters are utilized to broadcast access policies to nearby devices, ensuring that only the necessary information for enforcing access control is shared. These transmitters are one-way communication devices, meaning they do not collect any data from the mobile devices nor have the ability to track or store personal information. As a result, no location details—such as the user’s exact position or movements—are shared back to the space owner or any other party. The BLE communication is focused solely on transmitting policy updates to authorized devices within a defined area, ensuring that the user’s location remains private and is not tracked or recorded. However, in highly sensitive environments, users should anticipate that their movements may be monitored. Although the system is designed to preserve user location privacy, users should be aware that tracking, through any means, may be implemented in these environments for security enforcement purposes.

7. Conclusions

In this paper, we proposed a novel location-based access control system utilizing BLE beacon technology to dynamically enforce security policies on mobile devices within sensitive physical environments. Our system introduces the innovative jumbo beacon mechanism, effectively addressing the inherent payload size constraints of BLE beacon transmissions by enabling the fragmented dissemination and subsequent reassembly of digitally signed access control policies. Additionally, our decentralized, whitelist-based enforcement approach eliminates reliance on a centralized trust authority, enhancing scalability, resilience, and security.

We implemented a proof-of-concept prototype as a native security module integrated within the Android operating system, ensuring robust policy enforcement while preventing unauthorized modifications by end-users. Initial performance evaluations demonstrate that the proposed system achieves effective real-time enforcement with minimal overhead, making it highly suitable for deployment in practical, dynamic environments.

Future research directions include evaluating system performance and scalability in large, real-world deployments while exploring ideal transmitter placement and configuration settings. The system may also be extended to support public visitors’ devices (i.e., non–enterprise-managed devices) through a dedicated application that replicates the core functionality of the ACM, subject to a thorough assessment of the associated security guarantees and enforcement limitations. Additional work could explore alternative cryptographic schemes to further optimize both computational efficiency and energy consumption. Moreover, practical exploration of real-world scenarios—such as enforcing dwell time, path-based movement, and path-based movement with station-specific dwell time—can help identify deployment contexts where these mechanisms are most effective, as well as determine optimal parameter configurations for each use case.

Footnotes

Acknowledgements

Not applicable.

Ethical considerations

Not applicable.

Consent to participate

Not applicable.

Consent for publication

Not applicable.

Declaration of conflicting interest

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding statement

The authors received no financial support for the research, authorship, and/or publication of this article.

Data availability

All data used in this study are available from the corresponding author upon reasonable request.

ORCID iDs

Ahmed Khalil Abdulla

Gabriele Oligeri

Spiridon Bakiras

References

How to detect and prevent corporate espionage, 2025. https://www.mimecast.com/blog/what-is-corporate-espionage-and-prevention-techniques.

Blanton

. Iot security risks: Stats and trends to know in 2025, 2025. https://jumpcloud.com/blog/iot-security-risks-stats-and-trends-to-know-in-2025.

Waltham

. Unauthorised access to employee mobile devices leads to more than half of organisations experiencing a data breach, new report finds, 2024. https://www.imprivata.com/uk/company/press/unauthorized-access-employee-mobile-devices-leads-more-half-organizations.

Wang

, et al. Research on Mobile Computing and Network Security. New York, NY, USA: Association for Computing Machinery, 2025.

Farhadighalati

Estrada-Jimenez

Nikghadam Hojjati

, et al. A systematic review of access control models: Background, existing research, and challenges. IEEE Access 2025; 13: 1–1.

Chowdary

Raj

Anupama

, et al. Location & user profile based mobile application access. In: International conference on informatics and analytics. Association for Computing Machinery. ISBN 9781450347563.

Roesner

Molnar

Moshchuk

, et al. World-driven access control for continuous sensing. In: ACM conference on computer and communications security. Association for Computing Machinery. ISBN 9781450329576, p.1169–1181.

Rubio-Medrano

Jogani

Leitner

, et al. Effectively enforcing authorization constraints for emerging space-sensitive technologies. In: ACM symposium on access control models and technologies. association for computing machinery. ISBN 9781450367530, p.195–206.

Abdulla

Bakiras

She

. ICMS: A flexible location-based access control system for mobile devices. IEEE Syst J 2023; 17: 1536–1547.

10.

Bertino

Kirkpatrick

. Location-based access control systems for mobile users: Concepts and research directions. In: ACM International workshop on security and privacy in GIS and LBS. Association for Computing Machinery. ISBN 9781450310321, p.49–52.

11.

The bluetooth®low energy primer, 2025. https://www.bluetooth.com/bluetooth-le-primer.

12.

Oluwatimi

Midi

Bertino

. A context-aware system to secure enterprise content. In: ACM symposium on access control models and technologies. Association for Computing Machinery. ISBN 9781450338028, p.63–72.

13.

Martin

Rushanan

Tantillo

, et al. Applications of secure location sensing in healthcare. In: ACM International conference on bioinformatics, computational biology, and health informatics. Association for Computing Machinery. ISBN 9781450342254, p.58–67.

14.

Kirkpatrick

Damiani

Bertino

. Prox-rbac: A proximity-based spatially aware RBAC. In: ACM international symposium on advances in geographic information systems. Association for Computing Machinery. ISBN 9781450310314, p.339–348.

15.

Cruz

Gjomemo

Lin

, et al. A location aware role and attribute based access control system. In: International symposium on advances in geographic information systems. Association for Computing Machinery. ISBN 9781605583235.

16.

Kirkpatrick

Bertino

. Enforcing spatial constraints for mobile RBAC systems. In: ACM symposium on access control models and technologies. Association for Computing Machinery. ISBN 9781450300490, p.99–108.

17.

Hsu

Ray

. Specification and enforcement of location-aware attribute-based access control for online social networks. In: ACM international workshop on attribute based access control. Association for Computing Machinery. ISBN 9781450340793, p.25–34.

18.

Zhu

Huang

, et al. Enabling secure location-based services in mobile cloud computing. In: ACM SIGCOMM workshop on mobile cloud computing. Association for Computing Machinery. ISBN 9781450321808, p.27–32.

19.

Hengartner

Steenkiste

. Implementing access control to people location information. In: ACM symposium on access control models and technologies. Association for Computing Machinery. ISBN 1581138725, p.11–20.

20.

Karimi

Palanisamy

Joshi

. A dynamic privacy aware access control model for location based services. In: IEEE international conference on collaboration and internet computing. pp.554–557. DOI: 10.1109/CIC.2016.084.

21.

Mainali

Shepherd

Petitcolas

. Privacy-enhancing context authentication from location-sensitive data. In: International conference on availability, reliability and security. Association for Computing Machinery. ISBN 9781450371643.

22.

Ardagna

Cremonini

Damiani

, et al. Supporting location-based conditions in access control policies. In: ACM symposium on information, computer and communications security. Association for Computing Machinery. ISBN 1595932720, p.212–222.

23.

Abdou

Matrawy

van Oorschot

. Accurate manipulation of delay-based internet geolocation. In: ACM on asia conference on computer and communications security. Association for Computing Machinery. ISBN 9781450349444, p.887–898.

24.

Cleeff

Pieters

Wieringa

. Benefits of location-based access control: A literature study. In: IEEE/ACM international conference on green computing and communications international conference on cyber, physical and social computing. pp.739–746. DOI: 10.1109/GreenCom-CPSCom.2010.148.

25.

Decker

. Requirements for a location-based access control model. In: ACM International conference on advances in mobile computing and multimedia. Association for Computing Machinery. ISBN 9781605582696, p.346–349.

26.

Android architecture, 2025. https://source.android.com/docs/core/architecture.

27.

Altbeacon protocol specification v1.0, 2015. https://github.com/AltBeacon/spec.

28.

Java — oracle. https://www.java.com/en/, 2021.

29.

Feasycom fsc-bp104d: Bluetooth 5.1 waterproof ip67 beacon — 10-year battery life — ibeacon, eddystone, altbeacon support, 2025. https://www.feasycom.com/product/fsc-bp104d.

30.

Bhat

Dutta

. A survey on various threats and current state of security in android platform. ACM Comput Surv 2019; 52: 1–35.

31.

Aldoseri

Chothia

Moreira

, et al. Symbolic modelling of remote attestation protocols for device and app integrity on android. In: Proceedings of the 2023 ACM Asia conference on computer and communications security. ASIA CCS ’23, New York, NY, USA: Association for Computing Machinery. ISBN 9798400700989, p. 218–231. DOI: 10.1145/3579856.3582812.

32.

Ibrahim

Imran

Bianchi

. Safetynot: on the usage of the safetynet attestation api in android. In: Proceedings of the 19th annual international conference on mobile systems, applications, and services. MobiSys ’21, New York, NY, USA: Association for Computing Machinery. ISBN 9781450384438, p.150–162. DOI: 10.1145/3458864.3466627.

33.

Overview of the Play Integrity API |

Android Developers,

2025. https://developer.android.com/google/play/integrity/overview.