ABACS: Attribute-Based Access Control System using digital keys

ABACS: Attribute-Based Access Control System using digital keys | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article ABACS: Attribute-Based Access Control System using digital keys Samer I. Mohamed, Manal Mostafa, Jalal Assaly, Ahmed S. Shalabi This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-4630516/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract Access control systems are the most utilized preventive and protective solution for guaranteeing highly secure and monitored environments where people can move about and live in complete safety. The Smart Building Access Management System using Digital Keys provides an efficient means of granting or revoking access to users in residential and commercial buildings. It responds to the ever-increasing demand for internet-connected devices and the need for a system that is secure, convenient, and easy to manage. Despite the pivotal role of access control systems, the current technological standing shows severe security vulnerabilities, a lack of practical management solutions and a non-optimized user conveniency. Majorly used credential technologies show an absence of encryption capabilities. Some user management solutions do not scale well and present a lack of proper scalability. Our proposed system in this paper is the Attribute-Based Access Control System (ABACS) for Smart Building Access Management System, which offers an internet-oriented physical access control system, based on an end-to-end secured solution, an easy-to-use hybrid cloud-based system for effective access management and a mobile user application for optimal convenience. Authentication, integrity, and confidentiality are guaranteed using multiple security methods, including a Trusted Execution Environment (TEE) for a safe digital key storage and encryption, and the Transport Layer Security (TLS) protocol for secured channel communication, supported by a trusted third-party Certification Authority (CA). The Near-Field Communication (NFC) channel is used for quick key sharing. Access policies and user management is achieved using the hybrid fog-cloud paradigm and the Attribute-Based Access Control (ABAC) model. Finally, user convenience and optimal user experience are reached by means of an aesthetic mobile application for digital key generation and storage. The testing results and performance evaluation show that our proposed system’s backend, efficiently processes requests in both sequential and concurrent scenarios. With sequential requests, our proposed system’s longest-performing request outperforms iPACS’s by at least tenfold. In addition, with concurrent requests, our system shows a performance at least twice better than iPACS’s. Attribute-Based Access Control Near Field Communication Trusted Execution Environment Transport Layer Security Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 1. Introduction The rapid evolution of the Internet of Things (IoT) has made it a crucial technology in today’s digital world. IoT systems simplify our daily activities, enhance systems security, and offer great user convenience. One of the areas that witnessed a large development thanks to IoT technologies is access control systems in smart buildings. A Physical Access Control System (PACS) provides the ability of limiting entrance privileges to a room, a building, or a property to authorized users only (P.-C. Huang, C.-C. Chang, Y.-H. Li and Y. Liu, 2017). The traditional access method remained for long a simple key and keylock system. Whoever possessed the key had the access rights to enter the restricted area. However, as time passed and issues were identified, new credential technologies and methods of access validation emerged. The most noticeable changes in the industry happened in the last 10 to 15 years. Multiple sorts of user credentials were developed and implemented, such as Quick Response (QR) codes, Radio-Frequency Identification (RFID), biometric and mobile-based technologies, just to name a few (S. Barsukov, 2021). Over the years, the industry’s interests and focus shifted from one concern to the other. For instance, with the advent of IoT and network-connected devices, cybersecurity became one of the top challenges faced by companies. According to a worldwide survey conducted in collaboration between IFSEC and HID Global, a trusted provider of secure identity and access control solutions, 40% of the 1000 respondents cited “protecting against the threat of security vulnerabilities as a top challenge” (P. Sethi and S. R. Sarangi, 2017). Another primary challenge faced by 37% of the respondents to the same survey, is being capable of issuing and revoking ID credentials efficiently. In fact, managing credentials efficiently stems from a more general concern that is to provide user convenience. Around 43% of the respondents claimed that their major concern was to make the management of physical access control easier. Other noteworthy contemporary challenges are the ability to integrate physical access control with other infrastructure systems and, to reduce physical touchpoints as cited by 27% and 13% of the respondents respectively. Overall, the industry of PACSs currently faces important and severe concerns, such as security threat prevention, ease of management and use, integration with open platforms and touchless solutions. PACSs are security solutions that regulate and monitor entry to physical spaces, such as buildings or rooms. In the past two decades, these systems rapidly went from the traditional mechanical keys to the more modern digital keys, often in the form of electronic cards or mobile credentials, to grant or restrict access. Recent advancements in this field include sophisticated authentication methods, such as secure RFID smart cards and biometrics (e.g., fingerprint, retina scans, face ID), and integration with smart technologies and established building management systems. Various local and international competitors contribute to this sector, each with distinct market shares and product features. In 2020 (J. Moore, 2022), the market for physical access control solutions was worth approximately $5.66 billion and was projected to grow by 7.3% each year to reach $8.07 billion by 2025. However, after the COVID-19 pandemic, the rate of adoption for physical access control systems, aimed to aid in disease prevention and employee monitoring, has probably pushed this estimation even higher. As of 2023, the market is still in rapid expansion and new technologies see the light of research and adoption every day. To efficiently manage PACSs, the proposed system is implemented using an Attribute-Based Access Control (ABAC) model, which grants or revokes access based on the concurrent attributes of users (e.g., roles), access points (e.g., server room) and environmental factors (e.g., time). In addition, the system shall focus on creating a seamless user experience using mobile devices. A mobile smartphone solution shall be devised to act as a wallet for the digital keys, and as such, a mobile application should be developed. It also aims to comprehensively analyze and implement several security measures, including device, internet, and key generation security. The system will address these security concerns by implementing the latest Near-Field Communication (NFC) protocol alongside a Trusted Execution Environment (TEE) in the smartphone’s operating system to establish a seamless and fortified physical environment, guaranteeing the secure transmission and storage of the sensitive digital keys. Furthermore, the Transport Layer Security (TLS) protocol will be used in both symmetric and asymmetric modes, to ensure robust security at the transport and application layers during internet communication. The TLS asymmetric encryption will be supported by a Certification Authority (CA) that shall add server authentication features. Additionally, to achieve multifactor authentication, the system relies on the initial mobile authenticating credentials (e.g., fingerprint, PIN, face ID), with the correct combination of authenticating attributes and finally, frequently generated nonces to provide one-time digital keys. Finally, the system shall include audit trails and reporting features to provide enhanced security levels and monitoring. The proposed contribution hence lies in the unique collaboration of management, usage, and security solutions. First, the ABAC model will be physically implemented for efficient management. Secondly, a mobile digital wallet application will be developed for an enhanced end user experience and convenience. Furthermore, an end-to-end security algorithm will be designed to leverage advanced NFC and TEE physical protocols, as well as the TLS and CA transport and application protocols. Finally, the system employs multifactor authentication and features audit trails for enhanced security and monitoring. The rest of this paper is organized as follows: literature review and design of the proposed system are discussed in Sects. 2 and 3 respectively. Evaluation results are presented in Sect. 4 followed by conclusions and issues for future research in Sect. 5. 2. Background and related work The evolution of physical access control systems has witnessed a transformative journey from traditional lock-and-key mechanisms to sophisticated, technology-driven solutions that define the current state of the art. In the early stages, mechanical locks and physical keys were the primary means of securing access to buildings and rooms. The limitations of these systems, including the risk of lost or duplicated keys, pushed the development of electronic access control systems. The advent of electronic access control systems marked a significant shift, introducing key cards and key fobs that could be easily managed and monitored. These systems provided enhanced security through audit trails, enabling administrators to track access events and manage permissions more efficiently. Magnetic stripe cards, characterized by a black strip on their back, were the first type of cards in use. Then, with the uprising of RFID technologies, newer more convenient cards were conceived. Often termed as proximity cards, the low frequency 125kHz RFID cards are read from a close distance without the need for physical contact. However, since the first introduction of electronic access control systems in the 1980s and 1990s, magnetic and proximity cards can no longer be termed as major improvements since they lack basic security features such as encryption. Hence, following this constatation, newer electronic RFID cards called smart cards, operating at 13.56MHz, were designed and implemented, to provide a higher and smarter security access solution. Later, as technology advanced, biometric authentication, such as fingerprint, facial recognition, and retina scans, became integrated into access control solutions, adding an additional layer of security and eliminating the need for physical tokens. The market for biometric-based solutions is on a current uptake where 30% of the HID Global survey participants stated actively using it. In the current state of the art, access control systems leverage the power of the IoT and connectivity. Cloud-based solutions allow for centralized management and real-time monitoring, providing administrators with greater flexibility and control. Furthermore, the software parts of the system need to be more frequently updated than the hardware where cloud-based solutions can easily provide patches and improved performance to the components through regular updates. Mobile credentials, utilizing smartphones as digital keys, have gained popularity, offering convenience and improved user experiences. The market perfectly reflects this observation as 32% of the interviewees cited actively using mobile IDs (J. Moore, 2022 ) . (C. Arnosti, D. Gruntz and M. Hauri,2015) propose a smartphone based PACS that utilizes the connectivity of the mobile phone to authorize user access requests online by a central access server, while ensuring independence to the PACS from third parties like mobile network operators and handset manufacturers. The paper explores different secure element architectures, such as Host Card Emulation (HCE) and microSD-based secure element (microSD-SE), to achieve this goal (Cambou, 2017 ). (E. G. Petrakis, F. Antonopoulos, S. Sotiriadis and N. Bessis,2020) aim to present a PACS powered by a cloud service to control and monitor users’ activity, navigation and access in public and residential areas such as shopping malls and apartment buildings. The working principle is that multiple beacon Bluetooth radio transmitters are installed around the supervised area and broadcast the area identification number to nearby mobile devices. Through a mobile application, smartphones then communicate with a private local cloud (i.e., fog) to issue access requests and provide activity monitoring capabilities to the system. The system aims to track people’s location and activities to offer timely responses in case of emergencies and dangerous situations such as overcrowding or health incidents. The system also aims to monitor and handle access requests for restricted areas based on subscription or authorized criteria. Validation and identification processes are handled on a private cloud. Finally, anonymous reports are generated and sent to a public cloud server for further analysis and extraction of business intelligence. (T. Hakamäki and H. Palomäki, 2015) focus on the security of the communication technologies used between readers and controllers, especially the RFID technology. One of the RFID data structures is Wiegand, a communication protocol used in access control systems, it has been used since the 80’s. It is used to connect several things such as access cards and readers, binary reader to controller. Thus, Wiegand format is widely utilized in access control applications. (P. S. JosephNg, P. S. BrandonChan and K. Y. Phan, 2023) aim to design and prototype a smart and autonomous door access system for hotels in Malaysia. The system design choices are extracted from the analysis of hotel guests and employees’ opinions on current and future access control systems technology. The system settled on utilizing a contactless NFC technology, together with a mobile application developed to store and simulate smart digital keys for access validation. The HCE application grants effective financial benefits and complies with the protective protocols in the post-pandemic era. Feedback from hotel visitors and staff was collected through a comprehensive questionnaire, yielding important insights into the proposed system's impact on door access technologies and its perceived security level. RBAC model (A. Ben Fadhel, D. Bianculli, L. Briand, and B. Hourte, 2016 ), comprising users, roles, operations, objects, and permissions, establishes a dynamic framework where permissions are assigned to roles, and users are associated with specific roles. The role-centric approach of RBAC aims to shift the permission control from being assigned to specific users, to being associated with more general engineered roles. This methodology ensures logical independence through role-based policies, adherence to the least privileges principle, and support for the separation of duties. RBAC's versatile application across domains, together with its ability to simplify security policy management and administration through role-based structures, makes it a powerful model for access control in diverse organizational contexts. ABAC is introduced as a model operating with attributes, which are associated with three core entities: subjects, objects, and environment. Each of these entities can hold multiple attributes, which are used by the access policies to make access decisions. Subject attributes contain information about the user requesting access; the subject may include the role, job title, and subject ID. Object attributes could include the maximum number of users in the room. Finally, environmental attributes may encompass factors such as the current time and the emergency status of the environment. 3. ABACS architecture and design As concluded from the previous section of background and related work, the ABAC model is an access management solution that presents tangible advantages when compared to the more traditional RBAC model. The ABAC model was designed to solve the common issues of RBAC, which are the role-centric approach, lack of fine-grained control and scalability issues. Therefore, we aim to utilize ABAC, to add dynamicity and detailed access policy definition, while facilitating the management of the system (V. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, and K. Scarfone, 2014). 3.1. Technical specifications Downloadable Android-based mobile application. NFC-enabled mobile device to communicate digital keys to a PN532 NFC reader using 13.56 MHz radio frequency. 12V Mini Solenoid Door Lock to lock and unlock the door upon electric signal. MDF Wooden Door with frame for access point simulation. 5V DC relay module to open and close the current for door lock control. LCD, LED, and Buzzer to provide sensory feedback to user about his access status. ESP32 microcontroller equipped with a WIFI chip for components orchestration. Raspberry Pi model 4B aimed to act as a private server to locally process the access requests and reduce time latency. Attribute-Based Access Control (ABAC) control model to generate and manage access policies and components attributes on the backend server side. HTTP application and TLS encryption protocols applied on the server side to secure intranet and internet communication. CoAP and DTLS (with PSK) protocols for performant and efficient communication between the access point and backend server for access request authorization. 3.2. ABAC Attributes The ABAC has 3 main arbitrary attributes which are subject attributes, resource attributes and environment attributes. Each of these attributes plays a role in the ABAC to give the Access Control (AC) to the right subject. A subject, whether it’s a user, application, or process, is an entity that interacts with a resource. Each subject has its own specific attributes like (User ID, Role, Department, Time schedule, Clearance level, Employment status) that establish their identity and characteristics. A resource, which could be something like a web service, a physical or system component, is an entity that undergoes actions performed by a subject. Much like subjects, resources also contain attributes like (Access Point ID, Location, Temper detection, Occupancy level) that can be utilized to inform AC decisions. Environmental attributes like (Date, Time, Emergency status) characterize the operational, technical, and contextual aspects of the environment in which information access takes place. 3.3. ABAC Policy model The ABAC policy model is characterized by, \(S\) , \(R\) and \(E\) which are respectively the Subject, Resource and Environment. Moreover, the attributes that have been established in advance for subjects, resources, and environments are going to be represented with the following equations respectively. SA \(x\) (1 ≤ \(x\) ≤ X), RA \(y\) (1 ≤ \(y\) ≤ Y), and EA \(z\) (1 ≤ \(z\) ≤ Z). (3.1) Furthermore, the attribute assignment relations for the subject, resource and environment are going to be represented respectively as follows ATTR(s), ATTR(r), and ATTR(e), i. ATTR( \(s\) ) ⊆ SA1 × SA2 ×…× SA \(x\) (3.2) ii. ATTR( \(r\) ) ⊆ RA1 × RA2 ×…× RA \(y\) (3.3) i ii . ATTR( \(e\) ) ⊆ EA1 × EA2 ×…× EA \(z\) , (3.4) these relations specify how attributes are assigned to subjects, resources, and environments. The Policy Rule (PR) is responsible for determining whether a subject ( \(s\) ) can have an AC on a resource ( \(r\) ) in the environment ( \(e\) ). The PR in the most general form can be as follows, can_access ( \(s\) , \(r\) , \(e\) ) ← ƒ(ATTR( \(s\) ), ATTR( \(r\) ), ATTR( \(e\) )). Considering all the attributes assigned to each one of them, the function evaluates and provides an output. If the output is True, AC is granted; otherwise, AC is denied. The Attribute Authorities (AA) administrators are the ones who are responsible for maintaining (creating, managing, etc.) the attributes for subjects, resources, and environments. This means they are responsible for the characteristics or properties that describe subjects, resources, and the environment. AA may or may not store the attributes by themselves, but in any case, they are responsible for associating or "binding" attributes to the entities they describe (E. Yuan and J. Tong,2015). The Policy Authority (PA) administrators are responsible for formulating and overseeing access control policies. These can include decision rules, conditions, and additional constraints related to resource access. The Policy Administration Point (PAP) is the software component used by the AA and PA to design and define the access policies, rules and attributes that will be used to grant or revoke access. It handles common functions such as create, manage, test, and debug access attributes and policies, and to store the attributes definitions and policies in the designated database (M. Afshar, S. Samet and T. Hu, 2017 ). The Policy Enforcement Point (PEP) is the software component responsible for receiving access requests, demanding authorization decisions, and enforcing them. Essentially, it serves as the AC point and should have the capability to intercept service requests between those seeking information and those supplying it (M. Afshar, S. Samet and T. Hu, 2017 ). The Policy Decision Point (PDP) is the core software component of the system, and it plays an important role which is evaluating the policies and attributes against the rules provided by the PA and AA, respectively, to generate an access control decision (M. Afshar, S. Samet and T. Hu, 2017 ). Furthermore, it is tasked with assessing the relevant policies and rendering an authorization decision (grant or deny). Essentially, the PDP functions as a policy execution engine. If a policy refers to a subject, resource, or environmental attribute that is absent from the request (e.g., department missing), the PDP communicates with the PEP to trigger an alerting mechanism. The information is then relayed to the PA and AA administrators who will adjust the access policies and rules where necessary to solve the issue. The Policy Information Point (PIP) is a software component responsible for fetching the additional attributes necessary data for policy evaluation, such as the environment attributes for example. Its role is to supply the essential information to the PDP to facilitate its decision-making (A. A. Jabal, M. Davari, E. Bertino, C. Makaya, S. Calo, D. Verma, A. Russo, and C. Williams, 2019). 3.4. Transport Layer Security (TLS) In the proposed ABACS, the mobile device as well as the embedded access control system need to communicate with the local server over the internet; hence, there is the need to use an adequate internet protocol that provides privacy, data security and reliability. We preferred to use Transport Layer Security (TLS) protocol as one of the most widely adopted methods that satisfies the challenging security concerns and is nowadays a critical component for global trusted internet communication (B. Weber,2020). The TLS protocol can be decomposed into four main phases: key exchange, authentication, bulk encryption, and hashing. The four algorithms are often described in a cipher suite which details the algorithms being used for each phase. For example, a cipher suite can be “ECDHE_ECDSA_WITH_AES128_SHA256”, meaning that it utilizes Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) for key exchange, Elliptic-Curve Digital Signature Algorithm (ECDSA) for authentication, Advanced Encryption Standard 128-bits (AES128) for bulk encryption and Secure Hash Algorithm 256-bits (SHA256). Depending on the used cipher suite, the protocol’s confidentiality, integrity, and responsiveness is impacted (B. Weber,2020). We adopted the latest 1.3 version of TLS which provides many optimized features and satisfies the important computer security pillars of confidentiality, integrity, availability, authenticity, non-repudiation and more. However, the most important feature provided by the latest TLS protocol is the Perfect Forward Secrecy (PFS). It consists of providing enough security to the exchange so that at any point in the future, if the secured keys were to ever be compromised, any data that was previously sent can never be decrypted. A CA will be used to generate digital certificates to the backend server to enhance the integrity and authentication of the system components. 3.5. Constrained Application Protocol (CoAP) To establish a communication between devices over the internet, application layer protocols are used to govern the shape, size and method of requests and responses. The Hypertext Transfer Protocol (HTTP) is the most convenient application protocol used for data communication over traditional networks, containing capable devices with no limitations on resources or power consumption. However, when it comes to IoT devices, HTTP has shown to be a particularly wasteful protocol that does not comply with the constrained nature of the network devices and bandwidth and power constrains available. Hence, newer protocols were developed to solve this issue. The Constrained Application Protocol (CoAP) is an application layer protocol specifically developed for constrained environments and devices commonly found in IoT networks. It guarantees low processing overhead, optimized power consumptions, and fast communication bandwidth when compared to HTTP.CoAP is designed to resemble HTTP.It operates on a REST-style architecture, uses Uniform Resource Identifiers (URIs) to identify network resources and services, and initiate requests through the GET, POST, PUT and DELETE methods. By default, HTTP works over the Transmission Control Protocol (TCP) and CoAP over User Datagram Protocol (UDP) (A. A. Ali,2018). For these different reasons we adopted CoAP in our proposed system. 3.6. Near-Field Communications (NFC) NFC technology, embedded within most of mobile smartphones nowadays. First, it provides high-portability, user convenience, and it ensures that users will not forget or lose their credentials, as carrying mobiles around has become a standard habit for everyone. Secondly, NFC is a cost-effective solution, because it does away with physical cards which entailed a high cost of production and maintenance. Finally, it grants a reliable and secured way of communication due to its operating radio frequency being established at 13.56 MHz, which enables fast and encrypted-capable communication (A. A. Ali,2018). Therefore, we will use the NFC physical communication protocol to provide a secure mobile access solution. 3.7. Trusted Execution Environment (TEE) A Trusted Execution Environment (TEE) is a secure and isolated section within the primary processor (CPU) of devices, such as smartphones. Its primary purpose is to ensure the secure storage, processing, and protection of sensitive data in a trusted and isolated environment (G. Kasagiannis,2018). The processor controls a dual operating system (OS) environment respectively called the Rich OS and the Trusted OS. The Rich OS serves as the device's primary operating system. It controls and manages general functions and user applications, essentially acting as an interface for everyday interactions. In parallel, the Trusted OS operates within the TEE. It is responsible for critical security functions and the protection of sensitive data. Within this isolated execution environment, the TEE fulfills a range of important security requirements. Its security architecture is characterized by its ability to enable isolated execution, provide secure storage for both binaries and application data, support remote attestation for authenticity verification, facilitate secure provisioning of data, and establish a trusted communication path with the external world. These collective measures fortify the TEE against a variety of security threats, and satisfy the principles of code authentication, confidentiality, authenticity, privacy, system integrity, and precise control over data access rights which leads us to use as one of the core pillars of our system. 3.8. Mobile application As concluded from the current state-of-the art, the future trends as well as the literature review, mobile-based solutions will dominate the future of PACSs. Therefore, we aim to build a user-friendly mobile application for our ABACS to generate and store digital keys. The digital keys are generated using the user attributes and encrypted using the public key of the local server. The mobile application will also implement a local authentication process such as entering a Personal Identification Number (PIN) code or scanning a fingerprint to provide an added factor of authentication. Coupled with the server authentication for the digital key, the system can therefore achieve a multifactor authentication mechanism. Digital key will be encrypted using AES128. Digital key is generated and nonce is added for OTP behavior, to ensure second-factor authentication. (P. Danquah and H. Kwabena-Adade, 2020 ). 3.9. ABAC system architecture 3.9.1. Block diagram The block diagrams shown in Fig. 1 provides a high-level overview of the proposed ABACS components and modules, in addition to the logic that connects those entities. Each block in the diagram represents a hardware or software component or subsystem, aiding in the identification of essential elements in the system. User: An employee or a guest who wishes to access the restricted area. Smartphone: A smart device with NFC capabilities, that generates, stores, and sends the user’s digital key to the access point reader. Through the mobile application, it presents an authentication portal to the PACS online system and displays profile page and access history. Access Point Unit: A collection of electronic components responsible for capturing, preprocessing, and communicating the user’s digital key to the local server, as well as enforcing the access decision on the access point door. Local Server: A local server that acts as the central hub for communication and control in the PACS. It performs four main tasks: user login and registration, access control and authentication, access policies and attributes design and system monitoring. Administrator: A company’s employee in charge of managing, monitoring, and troubleshooting the PACS’s activity and performance. The administrator is also in charge of creating and managing access policies for the system. Figure 2 represents the core logic which resides inside the local server. The server is structured according to the ABAC model described previously in section 3.2. In addition to those components, more business logic can be performed by the server. For instance, the user activity can be monitored and saved as logs for security and auditing purposes (Goyal, V., Pandey, O., Sahai, A., Waters, B, 2006 ). 3.9.2. Flowchart diagram The flowchart summarizes in great lines the events and steps achieved during the normal operation of the system. Decisions are also reflected along the diagram to show the different branches and outcomes the system undergoes. Figure 3 shows the flowchart of our proposed ABACS, along with the important activities, decision branches and database stores. 1. Firstly, at the very beginning of the system flow, users open their mobile device and are presented with login or registration options to access the ABACS. If users are not already registered, they are prompted to register with their full user credentials. Otherwise, they can simply log in with their respective email and password credentials. Their records will be retrieved from the user database. 2. Upon login completion, the mobile application receives the user attributes from the server and initiates the secure generation and storage of the digital key for access control. 3. Then, users can present their mobile device to the access point readers to transfer their one-time-use digital key to the device through NFC communication. 4. Once the digital key is received, the device’s controller processes the digital key and generates an access request that includes the digital key and access point attributes. The newly created digital key is sent to the backend server for thorough verification against the predefined access point policies. 5. The access request’s attributes are extracted and checked against an access policy that is fetched from the policy store. After a decision is made, the backend server promptly communicates the decision back to the microcontroller, detailing the outcome of the validation process. 6. Based on the server's decision, the microcontroller executes access control measures: a. Authorized Access: The door mechanism is activated, accompanied by the illumination of a green LED and an audible buzzer signal. b. Unauthorized Access: Activation of a red LED and a distinct buzzer alert signify denial of access. In both cases, the local server meticulously logs the access attempts for auditing purposes. 3.9.3. Sequence diagram The sequence diagrams are presented to show the interaction between the various objects and components within the system in a chronological order. The components communicate through messages going back and forth along with arrows to depict the communication direction and the type of message being passed. This time around, the flow is shown in greater details to aid in better understanding the system functionalities. Figure 4 shows the interaction between the administrator and the local server to create and deploy access policies. First, the administrator is required to authenticate himself through login. Once authentication is done, he can design access policies, validate them, and deploy them on the server as needed (Ambrosin, M., Anzanpour, A., Conti, M., Dargahi, T., Moosavi, S.R., Rahmani, A.M., Liljeberg, P, 2016). Figure 5 shows the interaction between the user, mobile device, and local server when the user attempts to login or register onto the system. First, the user either chooses to login or register and enters his respective personal information on the mobile device. The mobile device establishes a TLS communication with the server and sends the user credentials. It then receives the authentication decision from the server. Depending on whether the decision is positive or negative, the mobile device receives different payloads. If authentication is successful, the mobile device receives a seed for nonce generation along with the user attributes which are stored after encryption inside the mobile device’s memory. Finally, the user is granted access to the application. Otherwise, if the authentication decision is negative, nothing is sent to the mobile device and access to the application is revoked to the user. Figure 6 shows the interaction during access control between the mobile device, the access point, and the local server. First, the mobile device generates a sequence of nonces based on the seed previously received. It then retrieves the user attributes from its storage, decrypts them and appends the generated nonce to them. The digital key is now ready and can be sent through NFC to the access point. The access point, constantly emitting a detection radio signal, detects the mobile devices and receives the digital key. Once received, the digital key is again modified to add the access point attributes retrieved from the microcontroller’s non-volatile storage. Once the payload is ready, the payload is attached to a CoAP request, which is then sent through a DTLS channel. The server receives the access request, parses it, evaluates it against the access policy and responds back to the access point with its decision. Depending on the decision, the access point will either open the door or keep it closed (D. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo, 2010 ). 4. ABACS implementation The backend of the proposed ABACS relies on the microservices design architecture, where each microservice is independent from the other and communicates using API requests. This paradigm enforces the separation of concerns principle and drastically improves development and debugging. Each microservice is responsible for implementing a set of related features that can be logically containerized within the microservice. All microservices are implemented using the RESTful design pattern, which offers simplicity and scalability, operating over the widely adopted HTTP protocol. Additionally, REST's compatibility with various devices and programming languages ensures seamless integration across different technologies (D. Rajapaksha, 2021). The backend server will be deployed on a prototype server that must be capable enough to provide great servicing of requests and rapid response times, for that we selected Raspberry Pi 4 Model B for our IoT backend server with its 64-bit CPU cores and up to 8 GB of RAM, ideal for running multiple internet services simultaneously. Combined with its community support, versatile connectivity, and GPIO pins, it's the best choice for scalable IoT solutions (R. P. T. Ltd., 2019). 4.1. ABACS architecture decisions The architectural decisions for the proposed ABACS are based on the adoption of the ABAC model over the RBAC for the backend server. The model was intentionally chosen for its ability to address limitations like role-centricity, lack of fine-grained control, and scalability issues. Leveraging ABAC, our system incorporates dynamicity and detailed access policy definitions, enhancing management efficiency. TLS for HTTP and DTLS for CoAP are adopted to fortify internet communication, ensuring privacy, data security, and reliability. Additionally, the CoAP enforces good practices to enable communication between constrained-resource devices and addresses the specific constraints of IoT networks. The utilization of the TEE within the mobile device ensures secure data processing and protection, addressing critical security concerns. The system's software stack includes a versatile array of tools and frameworks for server, embedded system, and mobile application development, purposefully chosen to ensure robustness, scalability, and compatibility. Hardware component selections are meticulously made, aligning with performance, connectivity, and security requirements. These architectural decisions collectively contribute to the robustness, scalability, and security of the proposed ABACS (D. Servos and S. L. Osborn, 2017). 4.2. ABACS deployment strategy The backend system must be deployed on a local server to manage and receive all the access requests. The first deployment strategy was to implement a service registration mechanism which provides multiple advantages, especially in terms of scalability. First, it provides automatic service detection at runtime, which eliminates the need for hardcoded endpoints and port numbers. This behavior is essential, especially in scaled environments where duplicate instances can be created at runtime. In addition, service registration also performs load balancing, which is a mechanism for even distribution of request traffic across services. Finally, service registration facilitates communication between all services as it constitutes a central hub for communication and service instances identification. The second employed deployment strategy is the API gateway. It provides a unique entry point to the system, which prevents microservice instances from communicating with external clients in an uncontrolled manner. In addition, the gateway constitutes a unique secure entry point, which can authenticate and verify all incoming requests (Sicari, S., Rizzardi, A., Dini, G. et al, 2021 ). Finally, as the third deployment strategy, we opted to deploy our backend system using Docker containers for each microservice. Docker allows to encapsulate all the necessary system environment inside a virtual machine that runs applications and services. It ensures dependency consistency and compatibility. All containers are also managed using the “Portainer” container orchestration software. It provides a user-friendly GUI to monitor the status and performance of all running containers and integrates seamlessly with Docker features, such as Docker Compose and Docker Hub for image downloads. The entire deployed system is installed and ran on the Raspberry Pi 4 Model B. This had been chosen for its large memory capacity of 8GB of RAM and various connectivity options like Gigabit Ethernet and 802.11ac Wi-Fi. Adopting microservices architecture enables our proposed ABACS to scale to support concurrent requests without having single point of failure or constrained resources contention that may lead to performance degradation which will be shown in detail in the following evaluation section. In terms of physical deployment, one local server per building remains essential to maintain a proper localized control and minimize communication latency. However, there still needs to be a centralized management solution to guarantee proper scalability across multiple buildings. In our proposed scaled deployment scenario, the minimum hardware requirements for local servers should include multi-core processors (e.g., quad-core or higher) with sufficient RAM (e.g., 8GB or more) to handle increased communication, concurrent requests and processing demands. Additionally, local servers should feature ample storage capacity to store access control data and logs efficiently. For public cloud servers, the minimum requirements should align with industry standards for hosting scalable applications. This includes virtual machines or containers with appropriate CPU and RAM allocations, as well as high-speed network interfaces to handle the high stream of incoming data from multiple buildings. Bandwidth requirements for inter-building communication should be substantial, with a minimum of 1 Gbps dedicated bandwidth to ensure seamless data transfer between buildings and the central management infrastructure. Furthermore, robust network security measures, including encryption protocols and firewall configurations, are essential to safeguard data integrity and prevent unauthorized access to our ABACS infrastructure. Regular monitoring and maintenance of both hardware and software components are crucial to ensure optimal system performance and reliability across all deployment sites. By adhering to these guidelines and leveraging a hybrid cloud approach, the proposed ABACS can be effectively managed and scaled to meet the evolving needs of multiple buildings while maintaining robust security and performance standards (Yao, X., Chen, Z., Tian, Y.: A, 2015). 4.3. ABACS attributes and payload design Each entity within the system has a set of attributes that is used during the access request evaluation to formulate a decision. The attributes were selectively chosen according to their relevance to the access request evaluation. For instance, user attributes include user id, role, department, time schedule, clearance level and employment status. Beside the id, which is used for auditing purposes, all the attributes contribute to the access request decision-making. The proposed system includes multiple subsystems that exchange HTTP, NFC, and CoAP payloads. During user login and registration, the mobile device communicates with the backend server via HTTP, receiving a payload with user attributes. The mobile device then sends these attributes and an access nonce to the embedded access point system via NFC. The access point appends its own attributes and sends a CoAP request containing all the attributes. To optimize communication speed and latency, it is crucial to reduce the payload format and size. Consequently, a set of rules were applied on the attributes contained inside the various payloads to avoid sending unnecessarily large and redundant information. First, size constraints were applied on all attributes to prevent them from exceeding a limit of 20 characters, where one character has a size of one byte. Secondly, the JSON payload is structured in a key-pair fashion, where keys represent the attribute name, and the value represents the actual information contained within the attribute. The attributes keys were condensed to a maximum of two or three characters to minimize the overall size of the JSON payload and only include nonredundant information. 4.4. Embedded system design and implementation Embedded system for the Access point is designed using ESP32 microcontroller that is capable of handling internet connection with the backend server and capable of interfacing with all the other hardware components. Its built-in Wi-Fi capabilities, which allows for a wireless communication with the backend server of our IoT system. Its 34 General-Purpose Input-Output (GPIO) pins enable direct interfacing with many components without additional hardware. Its dual cores running at up to 240 MHz ensure smooth operation and efficient management of tasks. The embedded system was programmed inside the ESP-IDF framework with a feature called “Arduino as a component” which allows to integrate and call Arduino-specific functions from the ESP-IDF framework. 4.5. Mobile application design and implementation Our Android application adheres to the Model-View-View Model (MVVM) architecture pattern (Microsoft, 2022). Its essential benefits are a clean separation of concerns, scalability, reusability, maintainability, and testability. This pattern separates the application into three core layers, namely the UI, business logic, and data layers, which promotes clean architecture, making the codebase more modular and easier to understand (A. S. Gillis,2022). The application is decomposed into the following layers of development: Data: To allow the mobile application to communicate through HTTP, the Retrofit client was used and allows for efficient communication with the remote backend server. In addition, the “BackEndApi” interface defines the HTTP endpoints to be requested from the backend server. It abstracts away the implementation details of network communication and provides a clear and standardized interface for interacting with remote resources. Furthermore, the “BackEndApi” interface acts as the principal gateway for making API requests. POJO: Within our application's directory structure, the “pojo” directory serves as a repository for Plain Old Java Objects (POJOs) representing various data models crucial for communication with the backend. The collection of models ensures streamlined data exchange between the client and server. By centralizing these models within the “pojo” directory, our application promotes code organization, maintainability, extensibility, and adaptability to evolving backend requirements. UI: On the presentation layer, our application's user interface (UI) components are meticulously structured within the “UI” directory. Activities such as main, signup, signin, home, and profile, all reside in this directory. Each activity is designed with a specific user interaction flow in mind. 5. ABACS testing results and evaluation Our proposed ABACS physical access control system can successfully process requests and grant, or revoke access based on users, access point and environment attributes (C. Asiminidis, G. Kokkonis and S. Kontogiannis,2018). However, we must verify that the system can withstand a heavy traffic of requests and still respond in short periods of time. Consequently, as Petrakis et al. ( 2020 ) mentioned in their research paper and proposed system (iPACS), the server’s access control endpoint needs to be benchmarked to verify its behavior in high-traffic environments. The iPACS system utilized the traditional HTTP protocol to send access requests from users’ mobile device to the fog server. However, our proposed system relies on the CoAP protocol established between the access point unit and the local server. Consequently, our benchmarking procedure utilized different benchmarking tools and procedures. We used the Californium CoAP-Extplugtest software program to conduct our benchmarking like the way Petrakis et al. ( 2020 ) obtained their results. Along with the POST request and URI instructions, a payload file containing valid user and access point attributes was attached with the request. In addition, a file containing the PSK information was attached to authenticate our benchmark clients to the server (Bonomi F, Milito R, Zhu J, Addepalli S ( 2012 ). Benchmarking was conducted in two phases. The first phase included sending 200 and 2000 requests with concurrency levels 1, 40 and 120, without restraining the upload data rate, to observe how the backend system handles rapidly incoming requests. The second phase included sending those same requests but with an upload data rate limit, to find out the minimum bandwidth required from the network installation to allow a proper communication between the access point and the local server. Finally, along the maximal servicing time per request percentile, we also monitor the average CPU and memory consumption in the Raspberry Pi using the Linux top command, which provides exhaustive details about system processes and resource utilization. Finally, data rates were defined using the “NetLimiter” software application. The results of the first phase of benchmarking are presented in Tables 1 to 4. The obtained average times per percentile are included, along the observed data rate and the CPU consumption. Table 1: 200 CoAPS requests (concurrency = 1) Percentage of served requests 95% 99% 99.9% 100% Average time (ms) Average CPU Time taken at 3.83 KB/s (ms) 34 44 45 45 22.34 19.7 % Table.2: 2000 CoAPS requests (concurrency = 1) Percentage of served requests 95% 99% 99.9% 100% Average time (ms) Average CPU Time taken at 21.36 KB/s (ms) 49 59 74 83 29.30 18.51 % Table.3: 2000 CoAPS requests (concurrency = 40) Percentage of served requests 95% 99% 99.9% 100% Average time (ms) Average CPU Time taken at 62.16 KB/s (ms) 744 794 824 837 434.41 53.28 % Table.4: 2000 CoAPS requests (concurrency = 120) Percentage of served requests 95% 99% 99.9% 100% Average time (ms) Average CPU Time taken at 56.63 KB/s (ms) 2’494 2’804 2’859 2’871 1’367.22 62.22 % It is noticed that the system performs very well with different number of requests and at different concurrency rates. It achieves our target latency included in our non-functional requirements. Sequential requests had to be served under 1 second of average servicing time, which has been achieved, as shown in Tables 1 and 2, where the average time hovered between 20 and 30 milliseconds only. In addition, when it comes to concurrent requests, the target of servicing all requests under an average time of 3 seconds has also been achieved. Tables 3 and 4 show that with high levels of concurrency, 40 and 120, the system still achieves a low average servicing time of 434.41 and 1’367.22 milliseconds respectively. First, we notice that as the concurrency level rises, the data rate and CPU consumption also rise to meet the demand of sending and processing a high number of incoming requests. It is also worth noting that the CPU consumption does not increase as the number of requests increases in sequential scenarios, most likely because requests are always processed one at a time and increasing their number will not result in a change in the behavior of the system. The system needs to be benchmarked at lower data rates, to evaluate its performance under constrained networks and evaluate the minimum required data rate that still achieves our target average times of 1 and 3 seconds in sequential and concurrent scenarios respectively. To limit the network speed, the NetLimiter software program was used. In every scenario, two graphs were used to represent both the average servicing time and the corresponding CPU consumption as shown in Fig. 8. Results are presented in the form of linear graphs in Figs. 7 to 12. In Fig. 7, when benchmarking the backend system with 200 requests and concurrency 1, it is noticed that the system achieves the target average time of 1 second between data rates of 0.6 and 0.7 Kbytes per second. With the slight variations and inconsistencies that happen in network quality and latency, it is safe to assume that our system’s breakeven data rate is around 0.7 Kbytes per second in sequential scenarios (concurrency 1). In Fig. 9, when running 2000 requests with concurrency 40, there is a clear increase in the minimum data rate required to achieve the target time of 3 seconds maximum. In fact, it seems that around 17 Kbytes per second are needed to provide an average servicing time of 3 seconds. This is explained by the fact that requests are now sent concurrently, which overloads the network infrastructure and necessitates higher speeds to successfully transfer all the requests from the client to the server. In addition, Fig. 10 shows that the backend system also needs to process all the incoming requests in a concurrent manner, which consequently increases the CPU consumption as the data rate increases as well. Finally, in Fig. 11, when running 2000 requests with concurrency 120, the minimum data rate threshold increases even more and seems to hover around 49 Kbytes per second, which is again explained by the sheer number of requests that saturate the network and demand a higher rate to be successfully transferred without errors. The CPU consumption also increases along the data rate proportionally as shown in Fig. 12. It is important to compare our system performance to an existing system, like iPACS, to evaluate the impact of the use of CoAP and our microservice backend implementation on similar access control systems. Figures 13 and 14 represent the longest performing request of iPACS against our proposed system. We also benchmarked our system with the same data rates observed in the iPACS benchmarking to closely compare our results. The data rates used were relatively low. The data rates are 0.61 KB/s for both sequential scenarios, 7.04 KB/s with concurrency 40 and 7.61 KB/s with concurrency 120. Consequently, it is noticed that our system’s comparative performance varies a lot and heavily depends on the network data rate. When comparing both systems at similar low bandwidths, our system performs slightly better than iPACS in sequential scenarios. However, when processing concurrent requests at the same low data rates, iPACS outperforms our proposed system. This is likely due to the difference in payload format and size between the two systems. Our reliance on the ABAC model means that all access point and user attributes must be sent within the request payload. As mentioned in previous sections, a significant advantage of using the ABAC model over the RBAC model is its flexibility and granularity in access control. ABAC can consider a wider array of attributes, such as user properties, resource characteristics, and environmental conditions, which allows for more fine-grained and context-aware access decisions. It also enhances security by ensuring that access decisions are made based on comprehensive information rather than just predefined roles. On one hand, the ABAC model certainly provides more versatility but on the other hand, it also noticeably increases the payload size, even though it was largely optimized and reduced. A larger payload size needs a higher bandwidth to be promptly sent without connection timeouts. On the other hand, the iPACS relies on the RBAC model, which bases its decision-making on the code area and the user role only; therefore, reducing the amount of information needed inside the payload. Unfortunately, details about the payload format and size were not exposed in Petrakis et al.’s work (2020). Nonetheless, when removing data rate limits, we notice that our system becomes much more efficient and outperforms iPACS. This confirms that data transmission rates and payload sizes are the main factor behind our system’s performance against iPACS’s. Once communication rates are suitably adapted to our payload requirements, we notice that our proposed system’s backend efficiently processes requests in both sequential and concurrent scenarios. With sequential requests, our proposed system’s longest-performing request outperforms iPACS’s by at least tenfold. With concurrent requests, our system shows a performance at least twice better than iPACS’s. The main communication protocol in the proposed system between the embedded client and the server is conducted via CoAP instead of HTTP.The CoAP protocol reduces the header size and optimizes the bandwidth consumption, which makes it more efficient than the HTTP protocol. To support these claims, we reattempted the benchmarking on our system with both HTTP and CoAP protocols. The CoAP request is sent to the CoAP server, which in turn communicates with the access control microservice, while the HTTP request is sent to the API gateway, which communicates with the access control microservice too. Both protocols use a secure channel, DTLS and TLS respectively. The results are shown in Table 5. Table ‎5: Performance comparison between CoAP and HTTP (average request servicing time) HTTP CoAP 200 requests with concurrency 1 (in ms) 61.43 at 10.77 KB/s 53.99 at 10.77 KB/s 2000 requests with concurrency 1 (in ms) 54.26 at 12.59 KB/s 49.69 at 12.59 KB/s 2000 requests with concurrency 40 (in ms) 1’257.82 at 47.14 KB/s 768.10 at 47.14 KB/s 2040 requests with concurrency 120 (in ms) 5’521.77 at 30.55 KB/s 4’947.14 at 30.55 KB/s We notice that the CoAP communication protocol performs better than the HTTP protocol given the same data rate and communicated payloads. First, the difference between the performance of both protocols in sequential requests is very small, because there is effectively no stress being put on either the server nor the network to communicate and process the request; but the CoAP protocol still sends less data and hence, performs better by a small margin. Secondly, when evaluating concurrent requests, the CoAP protocol surpasses the performance of the HTTP protocol by a large margin. Due to the heavy load put on the network, it is essential that payloads be minimized so that they can be transferred more quickly, and the CoAP protocol achieves this, as demonstrated by our results. 6. Conclusion Physical access control systems play a great part in securing buildings and providing safe environments for companies and individuals to accomplish their activities with a tranquil mind. As such, it is important to provide a highly secured solution that is fault proof, highly convenient, and easily scalable. However, according to experts’ reports, roughly 30% of the current access credential solutions are not encrypted and are highly vulnerable to eavesdropping, stealing, and masquerading. Consequently, our proposed ABACS as a physical access control system based on the IoT paradigm was proposed to solve a major industry concern as well as to respond to the demands and challenges faced by regular clients. The proposed system tackles the challenge of security through multiple means. First, an end-to-end encrypted communication channel is established between devices and system components using the internet TLS protocol. To support this communication, the local server is authenticated using a digital certificate generated by a trusted third-party CA. In addition, digitally generated credentials on user smartphones are safely stored in their devices using TEE, which provides a secured enclave for storing and processing digital keys. Finally, the access point reader is protected against tampering using a simple but efficient magnetic reed switch, that detects when the internal circuitry is exposed. Secondly, the proposed system utilizes the end users’ mobile device to integrate the access credentials in the form of a digital key. This provides a high convenience and instinctive solution that both satisfy the user as well as facilitates the management and security. Finally, the backend server of the system implements the ABAC model to provide improved management and scalability. Declarations Author Contribution The first and main author (Samer I. ) was the one who is responsible for the main and core idea of the research and the one who coordinate the efforts and participation of all other researchers in this project work. The second author (Manal M.) is the one who mange the review for the work done by all other researchers and review the results against benchmarks to ensure consistency and accuracy. (Jalal A.) is the one who is responsible to develop the hardware components of the proposed system including the implementation and unit testing. (Ahmed S.) is the one who is responsible to develop the software components including the frontend portal along with the mobile application for the proposed system. References P.-C. Huang, C.-C. Chang, Y.-H. Li and Y. Liu, 2017, "Efficient access control system based on aesthetic QR code," Springer-Verlag London Ltd., p. 11. J. Moore, 2022, "The 2022 State of Physical Access Control Report," IFSEC Global. C. Arnosti, D. Gruntz and M. Hauri,2015, "Secure Physical Access with NFC-enabled Smartphones," in in Proceedings of the 13th International Conference on Advances in Mobile Computing and Multimedia, New York. B. Cambou,2017, "Enhancing Secure Elements - Technology and Architecture," Northern Arizona University, Arizona, US. E. G. Petrakis, F. Antonopoulos, S. Sotiriadis and N. Bessis,2020, "iPACS: a physical access control system as a service and mobile application," Journal of Ambient Intelligence and Humanized Computing, vol. 11, pp. 929-943. T. Hakamäki and H. Palomäki, "Security of RFID-based technology,",2015, in International Symposium on Ambient Intelligence and Embedded Systems, Oostende. P. S. JosephNg, P. S. BrandonChan and K. Y. Phan,2023, "Implementation of Smart NFC Door Access System for Hotel Room," Applied System Innovation, vol. 6, no. 67, pp. n/a - n/a. E. Yuan and J. Tong,2015, "Attributed based access control (ABAC) for Web services," in IEEE International Conference on Web Services (ICWS'05), Orlando, FL, USA. M. Afshar, S. Samet and T. Hu,2017, "An Attribute Based Access Control Framework for Healthcare System," Journal of Physics, vol. 933, p. 7. B. Weber,2020, "Benefits and Adoption Rate of TLS 1.3," SANS Institute. P. Danquah and H. Kwabena-Adade,2020, "Public Key Infrastructure: An Enhanced Validation Framework," Journal of Information Security, vol. 11, no. 4, pp. n/a - n/a. A. A. Ali,2018, "Constrained Application Protocol (CoAP) for the IoT," in IoT Seminar, High Integrity System, Frankfurt. S. Barsukov,2021, "Diving into RFID Protocols with Flipper Zero," Flipper, 22 September 2021. [Online]. Available: https://blog.flipper.net/rfid/. G. Kasagiannis,2018, "Security Evaluation Of Android Keystore," University of Piraeus - Department of Digital Systems, Piraeus. R. P. T. Ltd.,2019, "Raspberry Pi 4 Computer Model B,". D. Rajapaksha,2021, "Integration Testing with Spring Boot," Java Code House, 12 April 2021. [Online]. Available: https://javacodehouse.com/courses/spring-boot/lesson-7-integration-testing-with-spring-boot/. P. Sethi and S. R. Sarangi,2017, "Internet of Things: Architectures, Protocols, and Applications," Journal of Electrical and Computer Engineering. C. Asiminidis, G. Kokkonis and S. Kontogiannis,2018, "Database Systems Performance Evaluation," International Journal of Database Management Systems, vol. 10, no. 6. A. S. Gillis,2022, "Digital Ocean," TechTarget, June 2022. [Online]. Available: https://www.techtarget.com/searchcloudcomputing/definition/DigitalOcean. Microsoft, "Model-View-ViewModel (MVVM)," Microsoft, 11 April 2022. [Online]. Available: https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm. Bonomi F, Milito R, Zhu J, Addepalli S, 2012 Fog computing and its role in the internet of things. In: MCC workshop on mobile cloud computing (MCC’12), Helsinki, Finland, 2012, pp 13–16. https ://dl.acm.org/citation.cfm?id=2342513. Accessed 21 Jan 2019 A. Ben Fadhel, D. Bianculli, L. Briand, and B. Hourte, 2016. “A Model-driven Approach to Representing and Checking RBAC Contextual Policies”. In Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy, CODASPY ’16, pages 243–253 V. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, and K. Scarfone, 2014,” Guide to Attribute Based Access Control (ABAC) Definition and Considerations”,. NIST SP 800-162, National Institute of Standards and Technology, url: http://nvlpubs.nist.gov/ nistpubs/SpecialPublications/NIST.SP.800-162.pdf. A. A. Jabal, M. Davari, E. Bertino, C. Makaya, S. Calo, D. Verma, A. Russo, and C. Williams, 2019. “Methods and Tools for Policy Analysis”. ACM Computing Surveys, 51(6):121:1–121:35 D. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo, 2010. “EXAM: a comprehensive environment for the analysis of access control policies”. Intl. Journal of Information Security, 9(4):253–273. D. Servos and S. L. Osborn, 2017. “Current Research and Open Problems in Attribute-Based Access Control”. ACM Comput. Surv., 49(4):65:1– 65:45. Sicari, S., Rizzardi, A., Dini, G. et al, 2021. “Attribute-based encryption and sticky policies for data access control in a smart home scenario: a comparison on networked smart object middleware. Int. J. Inf. Secur. 20, 695–713. https://doi.org/10.1007/s10207-020-00526-3 La Manna, M., Perazzo, P., Rasori, M., Dini, G.: Fabelous, 2019: “an attribute-based scheme for industrial internet of things. In: 2019 IEEE International Conference on Smart Computing (SMART-COMP), IEEE, pp. 33–38. Rasori, M., Perazzo, P., Dini, G, 2020. “A lightweight and scalable attribute-based encryption system for smart cities”. Comput. Com-mun. 149. Yao, X., Chen, Z., Tian, Y.: A, 2015. “Lightweight attribute-based encryption scheme for the Internet of Things”. Future Gener. Comput. Syst. 49, 104–112. https://doi.org/10.1016/j.future.2014.10.010 Goyal, V., Pandey, O., Sahai, A., Waters, B, 2006. “Attribute-based encryption for fine-grained access control of encrypted data”. In: Proceedings of the 13th ACM conference on Computer and Communications Security, pp. 89–98. Ambrosin, M., Anzanpour, A., Conti, M., Dargahi, T., Moosavi, S.R., Rahmani, A.M., Liljeberg, P, 2016. “On the feasibility of attributebased encryption on Internet of Things devices”. IEEE Micro 36(6), 25–35. Additional Declarations No competing interests reported. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-4630516","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":327287739,"identity":"42066631-3e88-40e3-a249-65695de2de55","order_by":0,"name":"Samer I. Mohamed","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABDUlEQVRIiWNgGAWjYDCCAzAGMw8DA2ODBAM/iJNQQIoWyQaQFgNitDCAtTAwGIBF8Gjhu32A+cPPHJt8BnbeYx9+7rCINj6/OvHDAwMGeX6xA1i1SJ5LYJPs3ZZm2cDMlzyz94xE7rYbbzdLAB1mOHN2AlYtBmcY2Bh4tx02APrFmIG3DaTl7AaQlgSD2zi1MH/8u+0/WAvjX6CWzTPObv5BQAuDNO+2A2AtzCBbNvD3bsNri+QZxjZp2W3JBmxAvzDLArXMuMG7zSLBQAKnX/jOMB/++HabnQE//9nDjG/b6nL7+89uvvmjwkaeXxq7FkhcAAEbXEACrFICh3KsgP8AKapHwSgYBaNgBAAABNNaksofTBMAAAAASUVORK5CYII=","orcid":"","institution":"October University of Modern Sciences and Arts","correspondingAuthor":true,"prefix":"","firstName":"Samer","middleName":"I.","lastName":"Mohamed","suffix":""},{"id":327287742,"identity":"58b07a09-3f1e-4922-b90f-51f0ac8e55b0","order_by":1,"name":"Manal Mostafa","email":"","orcid":"","institution":"Al Azhar University","correspondingAuthor":false,"prefix":"","firstName":"Manal","middleName":"","lastName":"Mostafa","suffix":""},{"id":327287744,"identity":"7b3ddfc7-39e3-4208-89ce-b639ea56b57c","order_by":2,"name":"Jalal Assaly","email":"","orcid":"","institution":"October University of Modern Sciences and Arts","correspondingAuthor":false,"prefix":"","firstName":"Jalal","middleName":"","lastName":"Assaly","suffix":""},{"id":327287745,"identity":"f954b4ba-eefd-47ca-977c-00377c61e75a","order_by":3,"name":"Ahmed S. Shalabi","email":"","orcid":"","institution":"October University of Modern Sciences and Arts","correspondingAuthor":false,"prefix":"","firstName":"Ahmed","middleName":"S.","lastName":"Shalabi","suffix":""}],"badges":[],"createdAt":"2024-06-24 13:27:13","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-4630516/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-4630516/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":60483818,"identity":"f51fc92d-ea00-4b10-9029-1258621a3a60","added_by":"auto","created_at":"2024-07-17 09:09:03","extension":"jpg","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":78101,"visible":true,"origin":"","legend":"\u003cp\u003eCore PACS Components Block Diagram\u003c/p\u003e","description":"","filename":"1.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/222c914d239a357ee8484f40.jpg"},{"id":60483825,"identity":"7fc2347f-ddbf-4cf0-bafa-72f2a069ac6b","added_by":"auto","created_at":"2024-07-17 09:09:04","extension":"jpg","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":67478,"visible":true,"origin":"","legend":"\u003cp\u003eBackend Server ABAC Software Components Block Diagram\u003c/p\u003e","description":"","filename":"2.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/8c162022a9b8737c0fa2a0ce.jpg"},{"id":60483820,"identity":"effec1fd-54cb-41e7-8599-ac02771157ea","added_by":"auto","created_at":"2024-07-17 09:09:04","extension":"jpg","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":67591,"visible":true,"origin":"","legend":"\u003cp\u003eABACS flowchart\u003c/p\u003e","description":"","filename":"3.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/61cd21545d0b00e8c0ac2719.jpg"},{"id":60485399,"identity":"a5580135-8360-4dc2-a2c1-a1fd4950696f","added_by":"auto","created_at":"2024-07-17 09:25:04","extension":"jpg","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":38496,"visible":true,"origin":"","legend":"\u003cp\u003eAccess Policy Development Sequence Diagram\u003c/p\u003e","description":"","filename":"4.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/d4ee84c2aa3b3724d84d0b9b.jpg"},{"id":60485400,"identity":"533a84b9-2fe7-45df-9d65-724944a72ccd","added_by":"auto","created_at":"2024-07-17 09:25:04","extension":"jpg","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":73810,"visible":true,"origin":"","legend":"\u003cp\u003eLogin and Registration Sequence Diagram\u003c/p\u003e","description":"","filename":"5.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/c07f97f88928895babbc5d24.jpg"},{"id":60483824,"identity":"54c4bbe4-def8-41a5-abe7-a088486824e9","added_by":"auto","created_at":"2024-07-17 09:09:04","extension":"jpg","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":57210,"visible":true,"origin":"","legend":"\u003cp\u003ePhysical Access Control Sequence Diagram\u003c/p\u003e","description":"","filename":"6.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/ff0a3c74204172c9ebbfced8.jpg"},{"id":60484601,"identity":"6a41a770-8b25-4b4a-a30d-e24794ae6eac","added_by":"auto","created_at":"2024-07-17 09:17:04","extension":"jpg","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":22761,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on Average Servicing Time for 200 requests (concurrency = 1)\u003c/p\u003e","description":"","filename":"7.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/ca42c31b4e2afacb27d3831d.jpg"},{"id":60484603,"identity":"674323f8-9652-4862-b47e-5bfe33d1638c","added_by":"auto","created_at":"2024-07-17 09:17:04","extension":"jpg","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":18572,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on CPU Usage for 200 requests (concurrency = 1)\u003c/p\u003e","description":"","filename":"8.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/7fb40deab00f6b9110cfff89.jpg"},{"id":60483830,"identity":"df3770a2-2dc4-4888-9221-d35d6ae0cf11","added_by":"auto","created_at":"2024-07-17 09:09:05","extension":"jpg","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":22043,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on Average Servicing Time for 2000 requests (concurrency = 40)\u003c/p\u003e","description":"","filename":"9.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/7fbe3f96dc82dad77ab774a9.jpg"},{"id":60484605,"identity":"74bf729a-50c1-4523-8a3b-733a3eafc02a","added_by":"auto","created_at":"2024-07-17 09:17:04","extension":"jpg","order_by":10,"title":"Figure 10","display":"","copyAsset":false,"role":"figure","size":20540,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on CPU Usage for 2000 requests (concurrency = 40)\u003c/p\u003e","description":"","filename":"10.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/d618a0ae663da3ea891226e0.jpg"},{"id":60483831,"identity":"d2e82646-b8d0-4ef0-a64d-d6e0147f261e","added_by":"auto","created_at":"2024-07-17 09:09:05","extension":"jpg","order_by":11,"title":"Figure 11","display":"","copyAsset":false,"role":"figure","size":21150,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on Average Servicing Time for 2000 requests (concurrency = 120)\u003c/p\u003e","description":"","filename":"11.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/27ca89f63dd7830589f9c711.jpg"},{"id":60483829,"identity":"ff3a2916-3b62-4f58-a0fd-40693fc5ee41","added_by":"auto","created_at":"2024-07-17 09:09:05","extension":"jpg","order_by":12,"title":"Figure 12","display":"","copyAsset":false,"role":"figure","size":18600,"visible":true,"origin":"","legend":"\u003cp\u003eData Rate Impact on CPU Usage for 2000 requests (concurrency = 120)\u003c/p\u003e","description":"","filename":"12.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/f8dd01cfc64f1846f3251040.jpg"},{"id":60483832,"identity":"e0ce4c6f-2cf0-46c8-ad80-737f6a52845c","added_by":"auto","created_at":"2024-07-17 09:09:05","extension":"jpg","order_by":13,"title":"Figure 13","display":"","copyAsset":false,"role":"figure","size":34087,"visible":true,"origin":"","legend":"\u003cp\u003eSystem Comparison of Longest Performing Request (concurrency = 1)\u003c/p\u003e","description":"","filename":"13.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/3fd19b9e83d6b0d18ab9959d.jpg"},{"id":60483819,"identity":"cc3d42ca-6ea1-43af-8921-25ed7610686d","added_by":"auto","created_at":"2024-07-17 09:09:03","extension":"jpg","order_by":14,"title":"Figure 14","display":"","copyAsset":false,"role":"figure","size":36262,"visible":true,"origin":"","legend":"\u003cp\u003eSystem Comparison of Longest Performing Request (concurrencies 40 and 120)\u003c/p\u003e","description":"","filename":"14.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/8b3f361d33c81047d875dd5d.jpg"},{"id":64173164,"identity":"35030f7b-afa5-4dcf-b500-bf1a56e7826c","added_by":"auto","created_at":"2024-09-09 11:48:48","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1269536,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-4630516/v1/39866ee8-b1a5-44a6-96f5-d9f27672f08a.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"ABACS: Attribute-Based Access Control System using digital keys","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eThe rapid evolution of the Internet of Things (IoT) has made it a crucial technology in today\u0026rsquo;s digital world. IoT systems simplify our daily activities, enhance systems security, and offer great user convenience. One of the areas that witnessed a large development thanks to IoT technologies is access control systems in smart buildings. A Physical Access Control System (PACS) provides the ability of limiting entrance privileges to a room, a building, or a property to authorized users only (P.-C. Huang, C.-C. Chang, Y.-H. Li and Y. Liu, 2017).\u003c/p\u003e\n\u003cp\u003eThe traditional access method remained for long a simple key and keylock system. Whoever possessed the key had the access rights to enter the restricted area. However, as time passed and issues were identified, new credential technologies and methods of access validation emerged. The most noticeable changes in the industry happened in the last 10 to 15 years. Multiple sorts of user credentials were developed and implemented, such as Quick Response (QR) codes, Radio-Frequency Identification (RFID), biometric and mobile-based technologies, just to name a few (S. Barsukov, 2021).\u003c/p\u003e\n\u003cp\u003eOver the years, the industry\u0026rsquo;s interests and focus shifted from one concern to the other. For instance, with the advent of IoT and network-connected devices, cybersecurity became one of the top challenges faced by companies. According to a worldwide survey conducted in collaboration between IFSEC and HID Global, a trusted provider of secure identity and access control solutions, 40% of the 1000 respondents cited \u0026ldquo;protecting against the threat of security vulnerabilities as a top challenge\u0026rdquo; (P. Sethi and S. R. Sarangi, 2017). Another primary challenge faced by 37% of the respondents to the same survey, is being capable of issuing and revoking ID credentials efficiently. In fact, managing credentials efficiently stems from a more general concern that is to provide user convenience. Around 43% of the respondents claimed that their major concern was to make the management of physical access control easier. Other noteworthy contemporary challenges are the ability to integrate physical access control with other infrastructure systems and, to reduce physical touchpoints as cited by 27% and 13% of the respondents respectively.\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;Overall, the industry of PACSs currently faces important and severe concerns, such as security threat prevention, ease of management and use, integration with open platforms and touchless solutions. PACSs are security solutions that regulate and monitor entry to physical spaces, such as buildings or rooms. In the past two decades, these systems rapidly went from the traditional mechanical keys to the more modern digital keys, often in the form of electronic cards or mobile credentials, to grant or restrict access. Recent advancements in this field include sophisticated authentication methods, such as secure RFID smart cards and biometrics (e.g., fingerprint, retina scans, face ID), and integration with smart technologies and established building management systems. Various local and international competitors contribute to this sector, each with distinct market shares and product features. In 2020 (J. Moore, 2022), the market for physical access control solutions was worth approximately $5.66 billion and was projected to grow by 7.3% each year to reach $8.07 billion by 2025. However, after the COVID-19 pandemic, the rate of adoption for physical access control systems, aimed to aid in disease prevention and employee monitoring, has probably pushed this estimation even higher. As of 2023, the market is still in rapid expansion and new technologies see the light of research and adoption every day.\u003c/p\u003e\n\u003cp\u003eTo efficiently manage PACSs, the proposed system is implemented using an Attribute-Based Access Control (ABAC) model, which grants or revokes access based on the concurrent attributes of users (e.g., roles), access points (e.g., server room) and environmental factors (e.g., time). In addition, the system shall focus on creating a seamless user experience using mobile devices. A mobile smartphone solution shall be devised to act as a wallet for the digital keys, and as such, a mobile application should be developed. It also aims to comprehensively analyze and implement several security measures, including device, internet, and key generation security. The system will address these security concerns by implementing the latest Near-Field Communication (NFC) protocol alongside a Trusted Execution Environment (TEE) in the smartphone\u0026rsquo;s operating system to establish a seamless and fortified physical environment, guaranteeing the secure transmission and storage of the sensitive digital keys. Furthermore, the Transport Layer Security (TLS) protocol will be used in both symmetric and asymmetric modes, to ensure robust security at the transport and application layers during internet communication. The TLS asymmetric encryption will be supported by a Certification Authority (CA) that shall add server authentication features. Additionally, to achieve multifactor authentication, the system relies on the initial mobile authenticating credentials (e.g., fingerprint, PIN, face ID), with the correct combination of authenticating attributes and finally, frequently generated nonces to provide one-time digital keys. Finally, the system shall include audit trails and reporting features to provide enhanced security levels and monitoring.\u003c/p\u003e\n\u003cp\u003eThe proposed contribution hence lies in the unique collaboration of management, usage, and security solutions. First, the ABAC model will be physically implemented for efficient management. Secondly, a mobile digital wallet application will be developed for an enhanced end user experience and convenience. Furthermore, an end-to-end security algorithm will be designed to leverage advanced NFC and TEE physical protocols, as well as the TLS and CA transport and application protocols. Finally, the system employs multifactor authentication and features audit trails for enhanced security and monitoring.\u003c/p\u003e\n\u003cp\u003eThe rest of this paper is organized as follows: literature review and design of the proposed system are discussed in Sects. 2 and 3 respectively. Evaluation results are presented in Sect. 4 followed by conclusions and issues for future research in Sect. 5.\u003c/p\u003e"},{"header":"2. Background and related work","content":"\u003cp\u003eThe evolution of physical access control systems has witnessed a transformative journey from traditional lock-and-key mechanisms to sophisticated, technology-driven solutions that define the current state of the art. In the early stages, mechanical locks and physical keys were the primary means of securing access to buildings and rooms. The limitations of these systems, including the risk of lost or duplicated keys, pushed the development of electronic access control systems.\u003c/p\u003e \u003cp\u003eThe advent of electronic access control systems marked a significant shift, introducing key cards and key fobs that could be easily managed and monitored. These systems provided enhanced security through audit trails, enabling administrators to track access events and manage permissions more efficiently. Magnetic stripe cards, characterized by a black strip on their back, were the first type of cards in use. Then, with the uprising of RFID technologies, newer more convenient cards were conceived. Often termed as proximity cards, the low frequency 125kHz RFID cards are read from a close distance without the need for physical contact. However, since the first introduction of electronic access control systems in the 1980s and 1990s, magnetic and proximity cards can no longer be termed as major improvements since they lack basic security features such as encryption. Hence, following this constatation, newer electronic RFID cards called smart cards, operating at 13.56MHz, were designed and implemented, to provide a higher and smarter security access solution. Later, as technology advanced, biometric authentication, such as fingerprint, facial recognition, and retina scans, became integrated into access control solutions, adding an additional layer of security and eliminating the need for physical tokens. The market for biometric-based solutions is on a current uptake where 30% of the HID Global survey participants stated actively using it.\u003c/p\u003e \u003cp\u003eIn the current state of the art, access control systems leverage the power of the IoT and connectivity. Cloud-based solutions allow for centralized management and real-time monitoring, providing administrators with greater flexibility and control. Furthermore, the software parts of the system need to be more frequently updated than the hardware where cloud-based solutions can easily provide patches and improved performance to the components through regular updates. Mobile credentials, utilizing smartphones as digital keys, have gained popularity, offering convenience and improved user experiences. The market perfectly reflects this observation as 32% of the interviewees cited actively using mobile IDs (J. Moore, \u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2022\u003c/span\u003e) .\u003c/p\u003e \u003cp\u003e(C. Arnosti, D. Gruntz and M. Hauri,2015) propose a smartphone based PACS that utilizes the connectivity of the mobile phone to authorize user access requests online by a central access server, while ensuring independence to the PACS from third parties like mobile network operators and handset manufacturers. The paper explores different secure element architectures, such as Host Card Emulation (HCE) and microSD-based secure element (microSD-SE), to achieve this goal (Cambou, \u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e2017\u003c/span\u003e).\u003c/p\u003e \u003cp\u003e(E. G. Petrakis, F. Antonopoulos, S. Sotiriadis and N. Bessis,2020) aim to present a PACS powered by a cloud service to control and monitor users\u0026rsquo; activity, navigation and access in public and residential areas such as shopping malls and apartment buildings. The working principle is that multiple beacon Bluetooth radio transmitters are installed around the supervised area and broadcast the area identification number to nearby mobile devices. Through a mobile application, smartphones then communicate with a private local cloud (i.e., fog) to issue access requests and provide activity monitoring capabilities to the system. The system aims to track people\u0026rsquo;s location and activities to offer timely responses in case of emergencies and dangerous situations such as overcrowding or health incidents. The system also aims to monitor and handle access requests for restricted areas based on subscription or authorized criteria. Validation and identification processes are handled on a private cloud. Finally, anonymous reports are generated and sent to a public cloud server for further analysis and extraction of business intelligence.\u003c/p\u003e \u003cp\u003e(T. Hakam\u0026auml;ki and H. Palom\u0026auml;ki, 2015) focus on the security of the communication technologies used between readers and controllers, especially the RFID technology. One of the RFID data structures is Wiegand, a communication protocol used in access control systems, it has been used since the 80\u0026rsquo;s. It is used to connect several things such as access cards and readers, binary reader to controller. Thus, Wiegand format is widely utilized in access control applications.\u003c/p\u003e \u003cp\u003e(P. S. JosephNg, P. S. BrandonChan and K. Y. Phan, 2023) aim to design and prototype a smart and autonomous door access system for hotels in Malaysia. The system design choices are extracted from the analysis of hotel guests and employees\u0026rsquo; opinions on current and future access control systems technology. The system settled on utilizing a contactless NFC technology, together with a mobile application developed to store and simulate smart digital keys for access validation. The HCE application grants effective financial benefits and complies with the protective protocols in the post-pandemic era. Feedback from hotel visitors and staff was collected through a comprehensive questionnaire, yielding important insights into the proposed system's impact on door access technologies and its perceived security level.\u003c/p\u003e \u003cp\u003eRBAC model (A. Ben Fadhel, D. Bianculli, L. Briand, and B. Hourte, \u003cspan citationid=\"CR22\" class=\"CitationRef\"\u003e2016\u003c/span\u003e), comprising users, roles, operations, objects, and permissions, establishes a dynamic framework where permissions are assigned to roles, and users are associated with specific roles. The role-centric approach of RBAC aims to shift the permission control from being assigned to specific users, to being associated with more general engineered roles. This methodology ensures logical independence through role-based policies, adherence to the least privileges principle, and support for the separation of duties. RBAC's versatile application across domains, together with its ability to simplify security policy management and administration through role-based structures, makes it a powerful model for access control in diverse organizational contexts.\u003c/p\u003e \u003cp\u003eABAC is introduced as a model operating with attributes, which are associated with three core entities: subjects, objects, and environment. Each of these entities can hold multiple attributes, which are used by the access policies to make access decisions. Subject attributes contain information about the user requesting access; the subject may include the role, job title, and subject ID. Object attributes could include the maximum number of users in the room. Finally, environmental attributes may encompass factors such as the current time and the emergency status of the environment.\u003c/p\u003e"},{"header":"3. ABACS architecture and design","content":"\u003cp\u003eAs concluded from the previous section of background and related work, the ABAC model is an access management solution that presents tangible advantages when compared to the more traditional RBAC model. The ABAC model was designed to solve the common issues of RBAC, which are the role-centric approach, lack of fine-grained control and scalability issues. Therefore, we aim to utilize ABAC, to add dynamicity and detailed access policy definition, while facilitating the management of the system (V. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, and K. Scarfone, 2014).\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e3.1. Technical specifications\u003c/em\u003e\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\n \u003cp\u003eDownloadable Android-based mobile application.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eNFC-enabled mobile device to communicate digital keys to a PN532 NFC reader using 13.56 MHz radio frequency.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e12V Mini Solenoid Door Lock to lock and unlock the door upon electric signal.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eMDF Wooden Door with frame for access point simulation.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e5V DC relay module to open and close the current for door lock control.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eLCD, LED, and Buzzer to provide sensory feedback to user about his access status.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eESP32 microcontroller equipped with a WIFI chip for components orchestration.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eRaspberry Pi model 4B aimed to act as a private server to locally process the access requests and reduce time latency.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eAttribute-Based Access Control (ABAC) control model to generate and manage access policies and components attributes on the backend server side.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eHTTP application and TLS encryption protocols applied on the server side to secure intranet and internet communication.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eCoAP and DTLS (with PSK) protocols for performant and efficient communication between the access point and backend server for access request authorization.\u003c/p\u003e\n \u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv id=\"Sec3\" class=\"Section2\"\u003e\n \u003ch2\u003e3.2. ABAC Attributes\u003c/h2\u003e\n \u003cp\u003eThe ABAC has 3 main arbitrary attributes which are subject attributes, resource attributes and environment attributes. Each of these attributes plays a role in the ABAC to give the Access Control (AC) to the right subject. A subject, whether it\u0026rsquo;s a user, application, or process, is an entity that interacts with a resource. Each subject has its own specific attributes like (User ID, Role, Department, Time schedule, Clearance level, Employment status) that establish their identity and characteristics. A resource, which could be something like a web service, a physical or system component, is an entity that undergoes actions performed by a subject. Much like subjects, resources also contain attributes like (Access Point ID, Location, Temper detection, Occupancy level) that can be utilized to inform AC decisions. Environmental attributes like (Date, Time, Emergency status) characterize the operational, technical, and contextual aspects of the environment in which information access takes place.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec4\" class=\"Section2\"\u003e\n \u003ch2\u003e3.3. ABAC Policy model\u003c/h2\u003e\n \u003cp\u003eThe ABAC policy model is characterized by, \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(S\\)\u003c/span\u003e\u003c/span\u003e, \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(R\\)\u003c/span\u003e\u003c/span\u003e and \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(E\\)\u003c/span\u003e\u003c/span\u003e which are respectively the Subject, Resource and Environment. Moreover, the attributes that have been established in advance for subjects, resources, and environments are going to be represented with the following equations respectively.\u003c/p\u003e\n \u003cdiv class=\"BlockQuote\"\u003e\n \u003cp\u003e\u003cem\u003eSA\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(x\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e \u003cem\u003e(1 \u0026le;\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(x\\)\u003c/span\u003e\u003c/span\u003e \u003cem\u003e\u0026le; X), RA\u003c/em\u003e\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(y\\)\u003c/span\u003e\u003c/span\u003e \u003cem\u003e(1 \u0026le;\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(y\\)\u003c/span\u003e\u003c/span\u003e \u003cem\u003e\u0026le; Y), and EA\u003c/em\u003e\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(z\\)\u003c/span\u003e\u003c/span\u003e \u003cem\u003e(1 \u0026le;\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(z\\)\u003c/span\u003e\u003c/span\u003e \u003cem\u003e\u0026le; Z).\u003c/em\u003e (3.1)\u003c/p\u003e\n \u003c/div\u003e\n \u003cp\u003eFurthermore, the attribute assignment relations for the subject, resource and environment are going to be represented respectively as follows ATTR(s), ATTR(r), and ATTR(e),\u003c/p\u003e\u003cspan\u003e\n \u003cp\u003e\u003cem\u003ei. ATTR(\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(s\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e \u003cem\u003e) \u0026sube; SA1 \u0026times; SA2 \u0026times;\u0026hellip;\u0026times; SA\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(x\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e (3.2)\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e\u003cem\u003e\u003cem\u003eii.\u0026nbsp;\u003c/em\u003eATTR(\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(r\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e \u003cem\u003e) \u0026sube; RA1 \u0026times; RA2 \u0026times;\u0026hellip;\u0026times; RA\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(y\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e (3.3)\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e\u003cem\u003e\u003cem\u003ei\u003cem\u003eii\u003c/em\u003e.\u0026nbsp;\u003c/em\u003eATTR(\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(e\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e \u003cem\u003e) \u0026sube; EA1 \u0026times; EA2 \u0026times;\u0026hellip;\u0026times; EA\u003c/em\u003e \u003cspan class=\"InlineEquation\"\u003e\u0026nbsp;\u003cspan class=\"mathinline\"\u003e\\(z\\)\u003c/span\u003e\u0026nbsp;\u003c/span\u003e, (3.4)\u003c/p\u003e\n \u003c/span\u003e\n \u003cp\u003ethese relations specify how attributes are assigned to subjects, resources, and environments. The Policy Rule (PR) is responsible for determining whether a subject (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(s\\)\u003c/span\u003e\u003c/span\u003e) can have an AC on a resource (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(r\\)\u003c/span\u003e\u003c/span\u003e) in the environment (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(e\\)\u003c/span\u003e\u003c/span\u003e). The PR in the most general form can be as follows, can_access (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(s\\)\u003c/span\u003e\u003c/span\u003e, \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(r\\)\u003c/span\u003e\u003c/span\u003e, \u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(e\\)\u003c/span\u003e\u003c/span\u003e) \u0026larr; \u0026fnof;(ATTR(\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(s\\)\u003c/span\u003e\u003c/span\u003e), ATTR(\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(r\\)\u003c/span\u003e\u003c/span\u003e), ATTR(\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(e\\)\u003c/span\u003e\u003c/span\u003e)). Considering all the attributes assigned to each one of them, the function evaluates and provides an output. If the output is True, AC is granted; otherwise, AC is denied.\u003c/p\u003e\n \u003cp\u003eThe Attribute Authorities (AA) administrators are the ones who are responsible for maintaining (creating, managing, etc.) the attributes for subjects, resources, and environments. This means they are responsible for the characteristics or properties that describe subjects, resources, and the environment. AA may or may not store the attributes by themselves, but in any case, they are responsible for associating or \u0026quot;binding\u0026quot; attributes to the entities they describe (E. Yuan and J. Tong,2015).\u003c/p\u003e\n \u003cp\u003eThe Policy Authority (PA) administrators are responsible for formulating and overseeing access control policies. These can include decision rules, conditions, and additional constraints related to resource access.\u003c/p\u003e\n \u003cp\u003eThe Policy Administration Point (PAP) is the software component used by the AA and PA to design and define the access policies, rules and attributes that will be used to grant or revoke access. It handles common functions such as create, manage, test, and debug access attributes and policies, and to store the attributes definitions and policies in the designated database (M. Afshar, S. Samet and T. Hu, \u003cspan class=\"CitationRef\"\u003e2017\u003c/span\u003e).\u003c/p\u003e\n \u003cp\u003eThe Policy Enforcement Point (PEP) is the software component responsible for receiving access requests, demanding authorization decisions, and enforcing them. Essentially, it serves as the AC point and should have the capability to intercept service requests between those seeking information and those supplying it (M. Afshar, S. Samet and T. Hu, \u003cspan class=\"CitationRef\"\u003e2017\u003c/span\u003e).\u003c/p\u003e\n \u003cp\u003eThe Policy Decision Point (PDP) is the core software component of the system, and it plays an important role which is evaluating the policies and attributes against the rules provided by the PA and AA, respectively, to generate an access control decision (M. Afshar, S. Samet and T. Hu, \u003cspan class=\"CitationRef\"\u003e2017\u003c/span\u003e). Furthermore, it is tasked with assessing the relevant policies and rendering an authorization decision (grant or deny). Essentially, the PDP functions as a policy execution engine. If a policy refers to a subject, resource, or environmental attribute that is absent from the request (e.g., department missing), the PDP communicates with the PEP to trigger an alerting mechanism. The information is then relayed to the PA and AA administrators who will adjust the access policies and rules where necessary to solve the issue.\u003c/p\u003e\n \u003cp\u003eThe Policy Information Point (PIP) is a software component responsible for fetching the additional attributes necessary data for policy evaluation, such as the environment attributes for example. Its role is to supply the essential information to the PDP to facilitate its decision-making (A. A. Jabal, M. Davari, E. Bertino, C. Makaya, S. Calo, D. Verma, A. Russo, and C. Williams, 2019).\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec5\" class=\"Section2\"\u003e\n \u003ch2\u003e3.4. Transport Layer Security (TLS)\u003c/h2\u003e\n \u003cp\u003eIn the proposed ABACS, the mobile device as well as the embedded access control system need to communicate with the local server over the internet; hence, there is the need to use an adequate internet protocol that provides privacy, data security and reliability. We preferred to use Transport Layer Security (TLS) protocol as one of the most widely adopted methods that satisfies the challenging security concerns and is nowadays a critical component for global trusted internet communication (B. Weber,2020). The TLS protocol can be decomposed into four main phases: key exchange, authentication, bulk encryption, and hashing. The four algorithms are often described in a cipher suite which details the algorithms being used for each phase. For example, a cipher suite can be \u0026ldquo;ECDHE_ECDSA_WITH_AES128_SHA256\u0026rdquo;, meaning that it utilizes Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) for key exchange, Elliptic-Curve Digital Signature Algorithm (ECDSA) for authentication, Advanced Encryption Standard 128-bits (AES128) for bulk encryption and Secure Hash Algorithm 256-bits (SHA256). Depending on the used cipher suite, the protocol\u0026rsquo;s confidentiality, integrity, and responsiveness is impacted (B. Weber,2020). We adopted the latest 1.3 version of TLS which provides many optimized features and satisfies the important computer security pillars of confidentiality, integrity, availability, authenticity, non-repudiation and more. However, the most important feature provided by the latest TLS protocol is the Perfect Forward Secrecy (PFS). It consists of providing enough security to the exchange so that at any point in the future, if the secured keys were to ever be compromised, any data that was previously sent can never be decrypted. A CA will be used to generate digital certificates to the backend server to enhance the integrity and authentication of the system components.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec6\" class=\"Section2\"\u003e\n \u003ch2\u003e3.5. Constrained Application Protocol (CoAP)\u003c/h2\u003e\n \u003cp\u003eTo establish a communication between devices over the internet, application layer protocols are used to govern the shape, size and method of requests and responses. The Hypertext Transfer Protocol (HTTP) is the most convenient application protocol used for data communication over traditional networks, containing capable devices with no limitations on resources or power consumption. However, when it comes to IoT devices, HTTP has shown to be a particularly wasteful protocol that does not comply with the constrained nature of the network devices and bandwidth and power constrains available. Hence, newer protocols were developed to solve this issue. The Constrained Application Protocol (CoAP) is an application layer protocol specifically developed for constrained environments and devices commonly found in IoT networks. It guarantees low processing overhead, optimized power consumptions, and fast communication bandwidth when compared to \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003eHTTP.CoAP\u003c/span\u003e\u003c/span\u003e is designed to resemble \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003eHTTP.It\u003c/span\u003e\u003c/span\u003e operates on a REST-style architecture, uses Uniform Resource Identifiers (URIs) to identify network resources and services, and initiate requests through the GET, POST, PUT and DELETE methods. By default, HTTP works over the Transmission Control Protocol (TCP) and CoAP over User Datagram Protocol (UDP) (A. A. Ali,2018). For these different reasons we adopted CoAP in our proposed system.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec7\" class=\"Section2\"\u003e\n \u003ch2\u003e3.6. Near-Field Communications (NFC)\u003c/h2\u003e\n \u003cp\u003eNFC technology, embedded within most of mobile smartphones nowadays. First, it provides high-portability, user convenience, and it ensures that users will not forget or lose their credentials, as carrying mobiles around has become a standard habit for everyone. Secondly, NFC is a cost-effective solution, because it does away with physical cards which entailed a high cost of production and maintenance. Finally, it grants a reliable and secured way of communication due to its operating radio frequency being established at 13.56 MHz, which enables fast and encrypted-capable communication (A. A. Ali,2018). Therefore, we will use the NFC physical communication protocol to provide a secure mobile access solution.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec8\" class=\"Section2\"\u003e\n \u003ch2\u003e3.7. Trusted Execution Environment (TEE)\u003c/h2\u003e\n \u003cp\u003eA Trusted Execution Environment (TEE) is a secure and isolated section within the primary processor (CPU) of devices, such as smartphones. Its primary purpose is to ensure the secure storage, processing, and protection of sensitive data in a trusted and isolated environment (G. Kasagiannis,2018). The processor controls a dual operating system (OS) environment respectively called the Rich OS and the Trusted OS. The Rich OS serves as the device\u0026apos;s primary operating system. It controls and manages general functions and user applications, essentially acting as an interface for everyday interactions. In parallel, the Trusted OS operates within the TEE. It is responsible for critical security functions and the protection of sensitive data. Within this isolated execution environment, the TEE fulfills a range of important security requirements. Its security architecture is characterized by its ability to enable isolated execution, provide secure storage for both binaries and application data, support remote attestation for authenticity verification, facilitate secure provisioning of data, and establish a trusted communication path with the external world. These collective measures fortify the TEE against a variety of security threats, and satisfy the principles of code authentication, confidentiality, authenticity, privacy, system integrity, and precise control over data access rights which leads us to use as one of the core pillars of our system.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec9\" class=\"Section2\"\u003e\n \u003ch2\u003e3.8. Mobile application\u003c/h2\u003e\n \u003cp\u003eAs concluded from the current state-of-the art, the future trends as well as the literature review, mobile-based solutions will dominate the future of PACSs. Therefore, we aim to build a user-friendly mobile application for our ABACS to generate and store digital keys. The digital keys are generated using the user attributes and encrypted using the public key of the local server. The mobile application will also implement a local authentication process such as entering a Personal Identification Number (PIN) code or scanning a fingerprint to provide an added factor of authentication. Coupled with the server authentication for the digital key, the system can therefore achieve a multifactor authentication mechanism. Digital key will be encrypted using AES128. Digital key is generated and nonce is added for OTP behavior, to ensure second-factor authentication. (P. Danquah and H. Kwabena-Adade, \u003cspan class=\"CitationRef\"\u003e2020\u003c/span\u003e).\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec10\" class=\"Section2\"\u003e\n \u003ch2\u003e3.9. ABAC system architecture\u003c/h2\u003e\n \u003cdiv id=\"Sec11\" class=\"Section3\"\u003e\n \u003ch2\u003e3.9.1. Block diagram\u003c/h2\u003e\n \u003cp\u003eThe block diagrams shown in Fig. \u003cspan class=\"InternalRef\"\u003e1\u003c/span\u003e provides a high-level overview of the proposed ABACS components and modules, in addition to the logic that connects those entities. Each block in the diagram represents a hardware or software component or subsystem, aiding in the identification of essential elements in the system.\u003c/p\u003e\n \u003cul\u003e\n \u003cli\u003e\n \u003cp\u003eUser: An employee or a guest who wishes to access the restricted area.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eSmartphone: A smart device with NFC capabilities, that generates, stores, and sends the user\u0026rsquo;s digital key to the access point reader. Through the mobile application, it presents an authentication portal to the PACS online system and displays profile page and access history.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eAccess Point Unit: A collection of electronic components responsible for capturing, preprocessing, and communicating the user\u0026rsquo;s digital key to the local server, as well as enforcing the access decision on the access point door.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eLocal Server: A local server that acts as the central hub for communication and control in the PACS. It performs four main tasks: user login and registration, access control and authentication, access policies and attributes design and system monitoring.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eAdministrator: A company\u0026rsquo;s employee in charge of managing, monitoring, and troubleshooting the PACS\u0026rsquo;s activity and performance. The administrator is also in charge of creating and managing access policies for the system.\u003c/p\u003e\n \u003c/li\u003e\n \u003c/ul\u003e\n \u003cp\u003eFigure 2 represents the core logic which resides inside the local server. The server is structured according to the ABAC model described previously in section 3.2. In addition to those components, more business logic can be performed by the server. For instance, the user activity can be monitored and saved as logs for security and auditing purposes (Goyal, V., Pandey, O., Sahai, A., Waters, B, \u003cspan class=\"CitationRef\"\u003e2006\u003c/span\u003e).\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec12\" class=\"Section3\"\u003e\n \u003ch2\u003e3.9.2. Flowchart diagram\u003c/h2\u003e\n \u003cp\u003eThe flowchart summarizes in great lines the events and steps achieved during the normal operation of the system. Decisions are also reflected along the diagram to show the different branches and outcomes the system undergoes. Figure \u003cspan class=\"InternalRef\"\u003e3\u003c/span\u003e shows the flowchart of our proposed ABACS, along with the important activities, decision branches and database stores.\u003c/p\u003e\u003cspan\u003e1. Firstly, at the very beginning of the system flow, users open their mobile device and are presented with login or registration options to access the ABACS. If users are not already registered, they are prompted to register with their full user credentials. Otherwise, they can simply log in with their respective email and password credentials. Their records will be retrieved from the user database.\u003cbr\u003e\u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e2. Upon login completion, the mobile application receives the user attributes from the server and initiates the secure generation and storage of the digital key for access control.\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e3. Then, users can present their mobile device to the access point readers to transfer their one-time-use digital key to the device through NFC communication.\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e4. Once the digital key is received, the device\u0026rsquo;s controller processes the digital key and generates an access request that includes the digital key and access point attributes. The newly created digital key is sent to the backend server for thorough verification against the predefined access point policies.\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e5. The access request\u0026rsquo;s attributes are extracted and checked against an access policy that is fetched from the policy store. After a decision is made, the backend server promptly communicates the decision back to the microcontroller, detailing the outcome of the validation process.\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003e6. Based on the server\u0026apos;s decision, the microcontroller executes access control measures:\u003c/p\u003e\n \u003c/span\u003e\u003cspan\u003e\n \u003cp\u003ea. Authorized Access: The door mechanism is activated, accompanied by the illumination of a green LED and an audible buzzer signal.\u003c/p\u003e\n \u003c/span\u003e \u003cspan\u003e\n \u003cp\u003eb. Unauthorized Access: Activation of a red LED and a distinct buzzer alert signify denial of access.\u003c/p\u003e\n \u003c/span\u003e\n \u003cp\u003eIn both cases, the local server meticulously logs the access attempts for auditing purposes.\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec13\" class=\"Section3\"\u003e\n \u003ch2\u003e3.9.3. Sequence diagram\u003c/h2\u003e\n \u003cp\u003eThe sequence diagrams are presented to show the interaction between the various objects and components within the system in a chronological order. The components communicate through messages going back and forth along with arrows to depict the communication direction and the type of message being passed. This time around, the flow is shown in greater details to aid in better understanding the system functionalities.\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan class=\"InternalRef\"\u003e4\u003c/span\u003e shows the interaction between the administrator and the local server to create and deploy access policies. First, the administrator is required to authenticate himself through login. Once authentication is done, he can design access policies, validate them, and deploy them on the server as needed (Ambrosin, M., Anzanpour, A., Conti, M., Dargahi, T., Moosavi, S.R., Rahmani, A.M., Liljeberg, P, 2016).\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan class=\"InternalRef\"\u003e5\u003c/span\u003e shows the interaction between the user, mobile device, and local server when the user attempts to login or register onto the system. First, the user either chooses to login or register and enters his respective personal information on the mobile device. The mobile device establishes a TLS communication with the server and sends the user credentials. It then receives the authentication decision from the server. Depending on whether the decision is positive or negative, the mobile device receives different payloads. If authentication is successful, the mobile device receives a seed for nonce generation along with the user attributes which are stored after encryption inside the mobile device\u0026rsquo;s memory. Finally, the user is granted access to the application. Otherwise, if the authentication decision is negative, nothing is sent to the mobile device and access to the application is revoked to the user.\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan class=\"InternalRef\"\u003e6\u003c/span\u003e shows the interaction during access control between the mobile device, the access point, and the local server. First, the mobile device generates a sequence of nonces based on the seed previously received. It then retrieves the user attributes from its storage, decrypts them and appends the generated nonce to them. The digital key is now ready and can be sent through NFC to the access point. The access point, constantly emitting a detection radio signal, detects the mobile devices and receives the digital key. Once received, the digital key is again modified to add the access point attributes retrieved from the microcontroller\u0026rsquo;s non-volatile storage. Once the payload is ready, the payload is attached to a CoAP request, which is then sent through a DTLS channel. The server receives the access request, parses it, evaluates it against the access policy and responds back to the access point with its decision. Depending on the decision, the access point will either open the door or keep it closed (D. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo, \u003cspan class=\"CitationRef\"\u003e2010\u003c/span\u003e).\u003c/p\u003e\n \u003c/div\u003e\n\u003c/div\u003e"},{"header":"4. ABACS implementation","content":"\u003cp\u003eThe backend of the proposed ABACS relies on the microservices design architecture, where each microservice is independent from the other and communicates using API requests. This paradigm enforces the separation of concerns principle and drastically improves development and debugging. Each microservice is responsible for implementing a set of related features that can be logically containerized within the microservice. All microservices are implemented using the RESTful design pattern, which offers simplicity and scalability, operating over the widely adopted HTTP protocol. Additionally, REST's compatibility with various devices and programming languages ensures seamless integration across different technologies (D. Rajapaksha, 2021).\u003c/p\u003e \u003cp\u003eThe backend server will be deployed on a prototype server that must be capable enough to provide great servicing of requests and rapid response times, for that we selected Raspberry Pi 4 Model B for our IoT backend server with its 64-bit CPU cores and up to 8 GB of RAM, ideal for running multiple internet services simultaneously. Combined with its community support, versatile connectivity, and GPIO pins, it's the best choice for scalable IoT solutions (R. P. T. Ltd., 2019).\u003c/p\u003e \u003cdiv id=\"Sec15\" class=\"Section2\"\u003e \u003ch2\u003e4.1. ABACS architecture decisions\u003c/h2\u003e \u003cp\u003eThe architectural decisions for the proposed ABACS are based on the adoption of the ABAC model over the RBAC for the backend server. The model was intentionally chosen for its ability to address limitations like role-centricity, lack of fine-grained control, and scalability issues. Leveraging ABAC, our system incorporates dynamicity and detailed access policy definitions, enhancing management efficiency. TLS for HTTP and DTLS for CoAP are adopted to fortify internet communication, ensuring privacy, data security, and reliability. Additionally, the CoAP enforces good practices to enable communication between constrained-resource devices and addresses the specific constraints of IoT networks. The utilization of the TEE within the mobile device ensures secure data processing and protection, addressing critical security concerns. The system's software stack includes a versatile array of tools and frameworks for server, embedded system, and mobile application development, purposefully chosen to ensure robustness, scalability, and compatibility. Hardware component selections are meticulously made, aligning with performance, connectivity, and security requirements. These architectural decisions collectively contribute to the robustness, scalability, and security of the proposed ABACS (D. Servos and S. L. Osborn, 2017).\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec16\" class=\"Section2\"\u003e \u003ch2\u003e4.2. ABACS deployment strategy\u003c/h2\u003e \u003cp\u003eThe backend system must be deployed on a local server to manage and receive all the access requests. The first deployment strategy was to implement a service registration mechanism which provides multiple advantages, especially in terms of scalability. First, it provides automatic service detection at runtime, which eliminates the need for hardcoded endpoints and port numbers. This behavior is essential, especially in scaled environments where duplicate instances can be created at runtime. In addition, service registration also performs load balancing, which is a mechanism for even distribution of request traffic across services. Finally, service registration facilitates communication between all services as it constitutes a central hub for communication and service instances identification.\u003c/p\u003e \u003cp\u003eThe second employed deployment strategy is the API gateway. It provides a unique entry point to the system, which prevents microservice instances from communicating with external clients in an uncontrolled manner. In addition, the gateway constitutes a unique secure entry point, which can authenticate and verify all incoming requests (Sicari, S., Rizzardi, A., Dini, G. et al, \u003cspan citationid=\"CR27\" class=\"CitationRef\"\u003e2021\u003c/span\u003e).\u003c/p\u003e \u003cp\u003eFinally, as the third deployment strategy, we opted to deploy our backend system using Docker containers for each microservice. Docker allows to encapsulate all the necessary system environment inside a virtual machine that runs applications and services. It ensures dependency consistency and compatibility. All containers are also managed using the \u0026ldquo;Portainer\u0026rdquo; container orchestration software. It provides a user-friendly GUI to monitor the status and performance of all running containers and integrates seamlessly with Docker features, such as Docker Compose and Docker Hub for image downloads. The entire deployed system is installed and ran on the Raspberry Pi 4 Model B. This had been chosen for its large memory capacity of 8GB of RAM and various connectivity options like Gigabit Ethernet and 802.11ac Wi-Fi.\u003c/p\u003e \u003cp\u003eAdopting microservices architecture enables our proposed ABACS to scale to support concurrent requests without having single point of failure or constrained resources contention that may lead to performance degradation which will be shown in detail in the following evaluation section. In terms of physical deployment, one local server per building remains essential to maintain a proper localized control and minimize communication latency. However, there still needs to be a centralized management solution to guarantee proper scalability across multiple buildings.\u003c/p\u003e \u003cp\u003eIn our proposed scaled deployment scenario, the minimum hardware requirements for local servers should include multi-core processors (e.g., quad-core or higher) with sufficient RAM (e.g., 8GB or more) to handle increased communication, concurrent requests and processing demands. Additionally, local servers should feature ample storage capacity to store access control data and logs efficiently. For public cloud servers, the minimum requirements should align with industry standards for hosting scalable applications. This includes virtual machines or containers with appropriate CPU and RAM allocations, as well as high-speed network interfaces to handle the high stream of incoming data from multiple buildings. Bandwidth requirements for inter-building communication should be substantial, with a minimum of 1 Gbps dedicated bandwidth to ensure seamless data transfer between buildings and the central management infrastructure.\u003c/p\u003e \u003cp\u003eFurthermore, robust network security measures, including encryption protocols and firewall configurations, are essential to safeguard data integrity and prevent unauthorized access to our ABACS infrastructure. Regular monitoring and maintenance of both hardware and software components are crucial to ensure optimal system performance and reliability across all deployment sites. By adhering to these guidelines and leveraging a hybrid cloud approach, the proposed ABACS can be effectively managed and scaled to meet the evolving needs of multiple buildings while maintaining robust security and performance standards (Yao, X., Chen, Z., Tian, Y.: A, 2015).\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec17\" class=\"Section2\"\u003e \u003ch2\u003e4.3. ABACS attributes and payload design\u003c/h2\u003e \u003cp\u003eEach entity within the system has a set of attributes that is used during the access request evaluation to formulate a decision. The attributes were selectively chosen according to their relevance to the access request evaluation. For instance, user attributes include user id, role, department, time schedule, clearance level and employment status. Beside the id, which is used for auditing purposes, all the attributes contribute to the access request decision-making. The proposed system includes multiple subsystems that exchange HTTP, NFC, and CoAP payloads. During user login and registration, the mobile device communicates with the backend server via HTTP, receiving a payload with user attributes. The mobile device then sends these attributes and an access nonce to the embedded access point system via NFC. The access point appends its own attributes and sends a CoAP request containing all the attributes. To optimize communication speed and latency, it is crucial to reduce the payload format and size. Consequently, a set of rules were applied on the attributes contained inside the various payloads to avoid sending unnecessarily large and redundant information. First, size constraints were applied on all attributes to prevent them from exceeding a limit of 20 characters, where one character has a size of one byte. Secondly, the JSON payload is structured in a key-pair fashion, where keys represent the attribute name, and the value represents the actual information contained within the attribute. The attributes keys were condensed to a maximum of two or three characters to minimize the overall size of the JSON payload and only include nonredundant information.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec18\" class=\"Section2\"\u003e \u003ch2\u003e4.4. Embedded system design and implementation\u003c/h2\u003e \u003cp\u003eEmbedded system for the Access point is designed using ESP32 microcontroller that is capable of handling internet connection with the backend server and capable of interfacing with all the other hardware components. Its built-in Wi-Fi capabilities, which allows for a wireless communication with the backend server of our IoT system. Its 34 General-Purpose Input-Output (GPIO) pins enable direct interfacing with many components without additional hardware. Its dual cores running at up to 240 MHz ensure smooth operation and efficient management of tasks. The embedded system was programmed inside the ESP-IDF framework with a feature called \u0026ldquo;Arduino as a component\u0026rdquo; which allows to integrate and call Arduino-specific functions from the ESP-IDF framework.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec19\" class=\"Section2\"\u003e \u003ch2\u003e4.5. Mobile application design and implementation\u003c/h2\u003e \u003cp\u003eOur Android application adheres to the Model-View-View Model (MVVM) architecture pattern (Microsoft, 2022). Its essential benefits are a clean separation of concerns, scalability, reusability, maintainability, and testability. This pattern separates the application into three core layers, namely the UI, business logic, and data layers, which promotes clean architecture, making the codebase more modular and easier to understand (A. S. Gillis,2022). The application is decomposed into the following layers of development:\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eData: To allow the mobile application to communicate through HTTP, the Retrofit client was used and allows for efficient communication with the remote backend server. In addition, the \u0026ldquo;BackEndApi\u0026rdquo; interface defines the HTTP endpoints to be requested from the backend server. It abstracts away the implementation details of network communication and provides a clear and standardized interface for interacting with remote resources. Furthermore, the \u0026ldquo;BackEndApi\u0026rdquo; interface acts as the principal gateway for making API requests.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003ePOJO: Within our application's directory structure, the \u0026ldquo;pojo\u0026rdquo; directory serves as a repository for Plain Old Java Objects (POJOs) representing various data models crucial for communication with the backend. The collection of models ensures streamlined data exchange between the client and server. By centralizing these models within the \u0026ldquo;pojo\u0026rdquo; directory, our application promotes code organization, maintainability, extensibility, and adaptability to evolving backend requirements.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eUI: On the presentation layer, our application's user interface (UI) components are meticulously structured within the \u0026ldquo;UI\u0026rdquo; directory. Activities such as main, signup, signin, home, and profile, all reside in this directory. Each activity is designed with a specific user interaction flow in mind.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e \u003c/div\u003e"},{"header":"5. ABACS testing results and evaluation","content":"\u003cp\u003eOur proposed ABACS physical access control system can successfully process requests and grant, or revoke access based on users, access point and environment attributes (C. Asiminidis, G. Kokkonis and S. Kontogiannis,2018). However, we must verify that the system can withstand a heavy traffic of requests and still respond in short periods of time. Consequently, as Petrakis et al. (\u003cspan class=\"CitationRef\"\u003e2020\u003c/span\u003e) mentioned in their research paper and proposed system (iPACS), the server\u0026rsquo;s access control endpoint needs to be benchmarked to verify its behavior in high-traffic environments. The iPACS system utilized the traditional HTTP protocol to send access requests from users\u0026rsquo; mobile device to the fog server. However, our proposed system relies on the CoAP protocol established between the access point unit and the local server. Consequently, our benchmarking procedure utilized different benchmarking tools and procedures. We used the Californium CoAP-Extplugtest software program to conduct our benchmarking like the way Petrakis et al. (\u003cspan class=\"CitationRef\"\u003e2020\u003c/span\u003e) obtained their results. Along with the POST request and URI instructions, a payload file containing valid user and access point attributes was attached with the request. In addition, a file containing the PSK information was attached to authenticate our benchmark clients to the server (Bonomi F, Milito R, Zhu J, Addepalli S (\u003cspan class=\"CitationRef\"\u003e2012\u003c/span\u003e).\u003c/p\u003e\n\u003cp\u003eBenchmarking was conducted in two phases. The first phase included sending 200 and 2000 requests with concurrency levels 1, 40 and 120, without restraining the upload data rate, to observe how the backend system handles rapidly incoming requests. The second phase included sending those same requests but with an upload data rate limit, to find out the minimum bandwidth required from the network installation to allow a proper communication between the access point and the local server.\u003c/p\u003e\n\u003cp\u003eFinally, along the maximal servicing time per request percentile, we also monitor the average CPU and memory consumption in the Raspberry Pi using the Linux top command, which provides exhaustive details about system processes and resource utilization. Finally, data rates were defined using the \u0026ldquo;NetLimiter\u0026rdquo; software application. The results of the first phase of benchmarking are presented in Tables \u003cspan class=\"InternalRef\"\u003e1\u003c/span\u003e to 4. The obtained average times per percentile are included, along the observed data rate and the CPU consumption.\u003c/p\u003e\n\u003cp\u003eTable 1: 200 CoAPS requests (concurrency = 1)\u003c/p\u003e\n\u003cdiv align=\"center\"\u003e\n \u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"103%\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd width=\"35.05154639175258%\"\u003e\n \u003cp\u003e\u003cstrong\u003ePercentage of served requests\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e95%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e99%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;99.9%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;100%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.43298969072165%\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage time (ms)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.402061855670103%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;Average CPU\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd width=\"35.05154639175258%\"\u003e\n \u003cp\u003eTime taken at 3.83 KB/s (ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e34\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e44\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u0026nbsp;45\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u0026nbsp;45\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.43298969072165%\"\u003e\n \u003cp\u003e22.34\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.402061855670103%\"\u003e\n \u003cp\u003e\u0026nbsp;19.7 %\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003cp\u003eTable.2: 2000 CoAPS requests (concurrency = 1)\u003c/p\u003e\n\u003cdiv align=\"center\"\u003e\n \u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"103%\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd width=\"35.05154639175258%\"\u003e\n \u003cp\u003e\u003cstrong\u003ePercentage of served requests\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e95%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e99%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;99.9%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;100%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.43298969072165%\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage time (ms)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.402061855670103%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;Average CPU\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd width=\"35.05154639175258%\"\u003e\n \u003cp\u003eTime taken at 21.36 KB/s (ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e49\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e59\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u0026nbsp;74\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.278350515463918%\"\u003e\n \u003cp\u003e\u0026nbsp;83\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.43298969072165%\"\u003e\n \u003cp\u003e29.30\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.402061855670103%\"\u003e\n \u003cp\u003e\u0026nbsp;18.51 %\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003cp\u003eTable.3: 2000 CoAPS requests (concurrency = 40)\u003c/p\u003e\n\u003cdiv align=\"center\"\u003e\n \u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"104%\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd width=\"34.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003ePercentage of served requests\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e95%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e99%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;99.9%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;100%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.541666666666666%\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage time (ms)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.583333333333334%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;Average CPU\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd width=\"34.375%\"\u003e\n \u003cp\u003eTime taken at 62.16 KB/s (ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e744\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e794\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u0026nbsp;824\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u0026nbsp;837\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"13.541666666666666%\"\u003e\n \u003cp\u003e434.41\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"14.583333333333334%\"\u003e\n \u003cp\u003e\u0026nbsp;53.28 %\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003cp\u003eTable.4: 2000 CoAPS requests (concurrency = 120)\u003c/p\u003e\n\u003cdiv align=\"center\"\u003e\n \u003ctable border=\"1\" cellspacing=\"0\" cellpadding=\"0\" width=\"104%\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd width=\"34.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003ePercentage of served requests\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e95%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e99%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;99.9%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;100%\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"15.625%\"\u003e\n \u003cp\u003e\u003cstrong\u003eAverage time (ms)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"12.5%\"\u003e\n \u003cp\u003e\u003cstrong\u003e\u0026nbsp;Average CPU\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd width=\"34.375%\"\u003e\n \u003cp\u003eTime taken at 56.63 KB/s (ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e2\u0026rsquo;494\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e2\u0026rsquo;804\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u0026nbsp;2\u0026rsquo;859\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"9.375%\"\u003e\n \u003cp\u003e\u0026nbsp;2\u0026rsquo;871\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"15.625%\"\u003e\n \u003cp\u003e1\u0026rsquo;367.22\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd width=\"12.5%\"\u003e\n \u003cp\u003e\u0026nbsp;62.22 %\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003cdiv class=\"gridtable\"\u003e\n \u003ctable id=\"Tab1\" border=\"1\"\u003e\u003c/table\u003e\n\u003c/div\u003e\n\u003cp\u003eIt is noticed that the system performs very well with different number of requests and at different concurrency rates. It achieves our target latency included in our non-functional requirements. Sequential requests had to be served under 1 second of average servicing time, which has been achieved, as shown in Tables \u003cspan class=\"InternalRef\"\u003e1\u003c/span\u003e and 2, where the average time hovered between 20 and 30 milliseconds only. In addition, when it comes to concurrent requests, the target of servicing all requests under an average time of 3 seconds has also been achieved. Tables 3 and 4 show that with high levels of concurrency, 40 and 120, the system still achieves a low average servicing time of 434.41 and 1\u0026rsquo;367.22 milliseconds respectively.\u003c/p\u003e\n\u003cp\u003eFirst, we notice that as the concurrency level rises, the data rate and CPU consumption also rise to meet the demand of sending and processing a high number of incoming requests. It is also worth noting that the CPU consumption does not increase as the number of requests increases in sequential scenarios, most likely because requests are always processed one at a time and increasing their number will not result in a change in the behavior of the system. The system needs to be benchmarked at lower data rates, to evaluate its performance under constrained networks and evaluate the minimum required data rate that still achieves our target average times of 1 and 3 seconds in sequential and concurrent scenarios respectively. To limit the network speed, the NetLimiter software program was used. In every scenario, two graphs were used to represent both the average servicing time and the corresponding CPU consumption as shown in Fig.\u0026nbsp;8. Results are presented in the form of linear graphs in Figs.\u0026nbsp;7 to 12.\u003c/p\u003e\n\u003cp\u003eIn Fig.\u0026nbsp;7, when benchmarking the backend system with 200 requests and concurrency 1, it is noticed that the system achieves the target average time of 1 second between data rates of 0.6 and 0.7 Kbytes per second. With the slight variations and inconsistencies that happen in network quality and latency, it is safe to assume that our system\u0026rsquo;s breakeven data rate is around 0.7 Kbytes per second in sequential scenarios (concurrency 1).\u003c/p\u003e\n\u003cp\u003eIn Fig.\u0026nbsp;9, when running 2000 requests with concurrency 40, there is a clear increase in the minimum data rate required to achieve the target time of 3 seconds maximum. In fact, it seems that around 17 Kbytes per second are needed to provide an average servicing time of 3 seconds. This is explained by the fact that requests are now sent concurrently, which overloads the network infrastructure and necessitates higher speeds to successfully transfer all the requests from the client to the server. In addition, Fig.\u0026nbsp;10 shows that the backend system also needs to process all the incoming requests in a concurrent manner, which consequently increases the CPU consumption as the data rate increases as well.\u003c/p\u003e\n\u003cp\u003eFinally, in Fig. 11, when running 2000 requests with concurrency 120, the minimum data rate threshold increases even more and seems to hover around 49 Kbytes per second, which is again explained by the sheer number of requests that saturate the network and demand a higher rate to be successfully transferred without errors. The CPU consumption also increases along the data rate proportionally as shown in Fig. 12.\u003c/p\u003e\n\u003cp\u003eIt is important to compare our system performance to an existing system, like iPACS, to evaluate the impact of the use of CoAP and our microservice backend implementation on similar access control systems. Figures\u0026nbsp;13 and 14 represent the longest performing request of iPACS against our proposed system. We also benchmarked our system with the same data rates observed in the iPACS benchmarking to closely compare our results. The data rates used were relatively low. The data rates are 0.61 KB/s for both sequential scenarios, 7.04 KB/s with concurrency 40 and 7.61 KB/s with concurrency 120. Consequently, it is noticed that our system\u0026rsquo;s comparative performance varies a lot and heavily depends on the network data rate. When comparing both systems at similar low bandwidths, our system performs slightly better than iPACS in sequential scenarios. However, when processing concurrent requests at the same low data rates, iPACS outperforms our proposed system. This is likely due to the difference in payload format and size between the two systems. Our reliance on the ABAC model means that all access point and user attributes must be sent within the request payload. As mentioned in previous sections, a significant advantage of using the ABAC model over the RBAC model is its flexibility and granularity in access control. ABAC can consider a wider array of attributes, such as user properties, resource characteristics, and environmental conditions, which allows for more fine-grained and context-aware access decisions. It also enhances security by ensuring that access decisions are made based on comprehensive information rather than just predefined roles.\u003c/p\u003e\n\u003cp\u003eOn one hand, the ABAC model certainly provides more versatility but on the other hand, it also noticeably increases the payload size, even though it was largely optimized and reduced. A larger payload size needs a higher bandwidth to be promptly sent without connection timeouts. On the other hand, the iPACS relies on the RBAC model, which bases its decision-making on the code area and the user role only; therefore, reducing the amount of information needed inside the payload. Unfortunately, details about the payload format and size were not exposed in Petrakis et al.\u0026rsquo;s work (2020). Nonetheless, when removing data rate limits, we notice that our system becomes much more efficient and outperforms iPACS. This confirms that data transmission rates and payload sizes are the main factor behind our system\u0026rsquo;s performance against iPACS\u0026rsquo;s. Once communication rates are suitably adapted to our payload requirements, we notice that our proposed system\u0026rsquo;s backend efficiently processes requests in both sequential and concurrent scenarios. With sequential requests, our proposed system\u0026rsquo;s longest-performing request outperforms iPACS\u0026rsquo;s by at least tenfold. With concurrent requests, our system shows a performance at least twice better than iPACS\u0026rsquo;s.\u003c/p\u003e\n\u003cp\u003eThe main communication protocol in the proposed system between the embedded client and the server is conducted via CoAP instead of \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003eHTTP.The\u003c/span\u003e\u003c/span\u003e CoAP protocol reduces the header size and optimizes the bandwidth consumption, which makes it more efficient than the HTTP protocol. To support these claims, we reattempted the benchmarking on our system with both HTTP and CoAP protocols. The CoAP request is sent to the CoAP server, which in turn communicates with the access control microservice, while the HTTP request is sent to the API gateway, which communicates with the access control microservice too. Both protocols use a secure channel, DTLS and TLS respectively. The results are shown in Table 5.\u003c/p\u003e\n\u003cp\u003eTable \u0026lrm;5: Performance comparison between CoAP and HTTP (average request servicing time)\u003c/p\u003e\n\u003ctable id=\"Tabe\" border=\"1\"\u003e\n \u003cthead\u003e\n \u003ctr\u003e\n \u003cth align=\"left\"\u003e\u0026nbsp;\u003c/th\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003eHTTP\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003eCoAP\u003c/p\u003e\n \u003c/th\u003e\n \u003c/tr\u003e\n \u003c/thead\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e200 requests with concurrency 1 (in ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e61.43 at 10.77 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e53.99 at 10.77 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e2000 requests with concurrency 1 (in ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e54.26 at 12.59 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e49.69 at 12.59 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e2000 requests with concurrency 40 (in ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e1\u0026rsquo;257.82 at 47.14 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e768.10 at 47.14 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e2040 requests with concurrency 120 (in ms)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e5\u0026rsquo;521.77 at 30.55 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003e4\u0026rsquo;947.14 at 30.55 KB/s\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e\n\u003cp\u003eWe notice that the CoAP communication protocol performs better than the HTTP protocol given the same data rate and communicated payloads. First, the difference between the performance of both protocols in sequential requests is very small, because there is effectively no stress being put on either the server nor the network to communicate and process the request; but the CoAP protocol still sends less data and hence, performs better by a small margin. Secondly, when evaluating concurrent requests, the CoAP protocol surpasses the performance of the HTTP protocol by a large margin. Due to the heavy load put on the network, it is essential that payloads be minimized so that they can be transferred more quickly, and the CoAP protocol achieves this, as demonstrated by our results.\u003c/p\u003e"},{"header":"6. Conclusion","content":"\u003cp\u003ePhysical access control systems play a great part in securing buildings and providing safe environments for companies and individuals to accomplish their activities with a tranquil mind. As such, it is important to provide a highly secured solution that is fault proof, highly convenient, and easily scalable. However, according to experts\u0026rsquo; reports, roughly 30% of the current access credential solutions are not encrypted and are highly vulnerable to eavesdropping, stealing, and masquerading. Consequently, our proposed ABACS as a physical access control system based on the IoT paradigm was proposed to solve a major industry concern as well as to respond to the demands and challenges faced by regular clients. The proposed system tackles the challenge of security through multiple means. First, an end-to-end encrypted communication channel is established between devices and system components using the internet TLS protocol. To support this communication, the local server is authenticated using a digital certificate generated by a trusted third-party CA. In addition, digitally generated credentials on user smartphones are safely stored in their devices using TEE, which provides a secured enclave for storing and processing digital keys. Finally, the access point reader is protected against tampering using a simple but efficient magnetic reed switch, that detects when the internal circuitry is exposed. Secondly, the proposed system utilizes the end users\u0026rsquo; mobile device to integrate the access credentials in the form of a digital key. This provides a high convenience and instinctive solution that both satisfy the user as well as facilitates the management and security. Finally, the backend server of the system implements the ABAC model to provide improved management and scalability.\u003c/p\u003e"},{"header":"Declarations","content":"\u003ch2\u003eAuthor Contribution\u003c/h2\u003e\u003cp\u003eThe first and main author (Samer I. ) was the one who is responsible for the main and core idea of the research and the one who coordinate the efforts and participation of all other researchers in this project work. The second author (Manal M.) is the one who mange the review for the work done by all other researchers and review the results against benchmarks to ensure consistency and accuracy. (Jalal A.) is the one who is responsible to develop the hardware components of the proposed system including the implementation and unit testing. (Ahmed S.) is the one who is responsible to develop the software components including the frontend portal along with the mobile application for the proposed system.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n \u003cli\u003eP.-C. Huang, C.-C. Chang, Y.-H. Li and Y. Liu, 2017, \u0026quot;Efficient access control system based on aesthetic QR code,\u0026quot; Springer-Verlag London Ltd., p. 11.\u003c/li\u003e\n \u003cli\u003eJ. Moore, 2022, \u0026quot;The 2022 State of Physical Access Control Report,\u0026quot; IFSEC Global.\u003c/li\u003e\n \u003cli\u003eC. Arnosti, D. Gruntz and M. Hauri,2015, \u0026quot;Secure Physical Access with NFC-enabled Smartphones,\u0026quot; in in Proceedings of the 13th International Conference on Advances in Mobile Computing and Multimedia, New York.\u003c/li\u003e\n \u003cli\u003eB. Cambou,2017, \u0026quot;Enhancing Secure Elements - Technology and Architecture,\u0026quot; Northern Arizona University, Arizona, US.\u003c/li\u003e\n \u003cli\u003eE. G. Petrakis, F. Antonopoulos, S. Sotiriadis and N. Bessis,2020, \u0026quot;iPACS: a physical access control system as a service and mobile application,\u0026quot; Journal of Ambient Intelligence and Humanized Computing, vol. 11, pp. 929-943.\u003c/li\u003e\n \u003cli\u003eT. Hakam\u0026auml;ki and H. Palom\u0026auml;ki, \u0026quot;Security of RFID-based technology,\u0026quot;,2015, in International Symposium on Ambient Intelligence and Embedded Systems, Oostende.\u003c/li\u003e\n \u003cli\u003eP. S. JosephNg, P. S. BrandonChan and K. Y. Phan,2023, \u0026quot;Implementation of Smart NFC Door Access System for Hotel Room,\u0026quot; Applied System Innovation, vol. 6, no. 67, pp. n/a - n/a.\u003c/li\u003e\n \u003cli\u003eE. Yuan and J. Tong,2015, \u0026quot;Attributed based access control (ABAC) for Web services,\u0026quot; in IEEE International Conference on Web Services (ICWS\u0026apos;05), Orlando, FL, USA.\u003c/li\u003e\n \u003cli\u003eM. Afshar, S. Samet and T. Hu,2017, \u0026quot;An Attribute Based Access Control Framework for Healthcare System,\u0026quot; Journal of Physics, vol. 933, p. 7.\u003c/li\u003e\n \u003cli\u003eB. Weber,2020, \u0026quot;Benefits and Adoption Rate of TLS 1.3,\u0026quot; SANS Institute.\u003c/li\u003e\n \u003cli\u003eP. Danquah and H. Kwabena-Adade,2020, \u0026quot;Public Key Infrastructure: An Enhanced Validation Framework,\u0026quot; Journal of Information Security, vol. 11, no. 4, pp. n/a - n/a.\u003c/li\u003e\n \u003cli\u003eA. A. Ali,2018, \u0026quot;Constrained Application Protocol (CoAP) for the IoT,\u0026quot; in IoT Seminar, High Integrity System, Frankfurt.\u003c/li\u003e\n \u003cli\u003eS. Barsukov,2021, \u0026quot;Diving into RFID Protocols with Flipper Zero,\u0026quot; Flipper, 22 September 2021. [Online]. Available: https://blog.flipper.net/rfid/.\u003c/li\u003e\n \u003cli\u003eG. Kasagiannis,2018, \u0026quot;Security Evaluation Of Android Keystore,\u0026quot; University of Piraeus - Department of Digital Systems, Piraeus.\u003c/li\u003e\n \u003cli\u003eR. P. T. Ltd.,2019, \u0026quot;Raspberry Pi 4 Computer Model B,\u0026quot;.\u003c/li\u003e\n \u003cli\u003eD. Rajapaksha,2021, \u0026quot;Integration Testing with Spring Boot,\u0026quot; Java Code House, 12 April 2021. [Online]. Available: https://javacodehouse.com/courses/spring-boot/lesson-7-integration-testing-with-spring-boot/.\u003c/li\u003e\n \u003cli\u003eP. Sethi and S. R. Sarangi,2017, \u0026quot;Internet of Things: Architectures, Protocols, and Applications,\u0026quot; Journal of Electrical and Computer Engineering.\u003c/li\u003e\n \u003cli\u003eC. Asiminidis, G. Kokkonis and S. Kontogiannis,2018, \u0026quot;Database Systems Performance Evaluation,\u0026quot; International Journal of Database Management Systems, vol. 10, no. 6.\u003c/li\u003e\n \u003cli\u003eA. S. Gillis,2022, \u0026quot;Digital Ocean,\u0026quot; TechTarget, June 2022. [Online]. Available: https://www.techtarget.com/searchcloudcomputing/definition/DigitalOcean.\u003c/li\u003e\n \u003cli\u003eMicrosoft, \u0026quot;Model-View-ViewModel (MVVM),\u0026quot; Microsoft, 11 April 2022. [Online]. Available: https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm.\u003c/li\u003e\n \u003cli\u003eBonomi F, Milito R, Zhu J, Addepalli S, 2012 Fog computing and its role in the internet of things. In: MCC workshop on mobile cloud computing (MCC\u0026rsquo;12), Helsinki, Finland, 2012, pp 13\u0026ndash;16. https ://dl.acm.org/citation.cfm?id=2342513. Accessed 21 Jan 2019\u003c/li\u003e\n \u003cli\u003eA. Ben Fadhel, D. Bianculli, L. Briand, and B. Hourte, 2016. \u0026ldquo;A Model-driven Approach to Representing and Checking RBAC Contextual Policies\u0026rdquo;. In Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy, CODASPY \u0026rsquo;16, pages 243\u0026ndash;253\u003c/li\u003e\n \u003cli\u003eV. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, and K. Scarfone, 2014,\u0026rdquo; Guide to Attribute Based Access Control (ABAC) Definition and Considerations\u0026rdquo;,. NIST SP 800-162, National Institute of Standards and Technology, url: http://nvlpubs.nist.gov/ nistpubs/SpecialPublications/NIST.SP.800-162.pdf.\u003c/li\u003e\n \u003cli\u003eA. A. Jabal, M. Davari, E. Bertino, C. Makaya, S. Calo, D. Verma, A. Russo, and C. Williams, 2019. \u0026ldquo;Methods and Tools for Policy Analysis\u0026rdquo;. ACM Computing Surveys, 51(6):121:1\u0026ndash;121:35\u003c/li\u003e\n \u003cli\u003eD. Lin, P. Rao, E. Bertino, N. Li, and J. Lobo, 2010. \u0026ldquo;EXAM: a comprehensive environment for the analysis of access control policies\u0026rdquo;. Intl. Journal of Information Security, 9(4):253\u0026ndash;273.\u003c/li\u003e\n \u003cli\u003eD. Servos and S. L. Osborn, 2017. \u0026ldquo;Current Research and Open Problems in Attribute-Based Access Control\u0026rdquo;. ACM Comput. Surv., 49(4):65:1\u0026ndash; 65:45.\u003c/li\u003e\n \u003cli\u003eSicari, S., Rizzardi, A., Dini, G. et al, 2021. \u0026ldquo;Attribute-based encryption and sticky policies for data access control in a smart home scenario: a comparison on networked smart object middleware. Int. J. Inf. Secur. 20, 695\u0026ndash;713. https://doi.org/10.1007/s10207-020-00526-3\u003c/li\u003e\n \u003cli\u003eLa Manna, M., Perazzo, P., Rasori, M., Dini, G.: Fabelous, 2019: \u0026ldquo;an attribute-based scheme for industrial internet of things. In: 2019 IEEE International Conference on Smart Computing (SMART-COMP), IEEE, pp. 33\u0026ndash;38.\u003c/li\u003e\n \u003cli\u003eRasori, M., Perazzo, P., Dini, G, 2020. \u0026ldquo;A lightweight and scalable attribute-based encryption system for smart cities\u0026rdquo;. Comput. Com-mun. 149.\u003c/li\u003e\n \u003cli\u003eYao, X., Chen, Z., Tian, Y.: A, 2015. \u0026ldquo;Lightweight attribute-based encryption scheme for the Internet of Things\u0026rdquo;. Future Gener. Comput. Syst. 49, 104\u0026ndash;112. https://doi.org/10.1016/j.future.2014.10.010\u003c/li\u003e\n \u003cli\u003eGoyal, V., Pandey, O., Sahai, A., Waters, B, 2006. \u0026ldquo;Attribute-based encryption for fine-grained access control of encrypted data\u0026rdquo;. In: Proceedings of the 13th ACM conference on Computer and Communications Security, pp. 89\u0026ndash;98.\u003c/li\u003e\n \u003cli\u003eAmbrosin, M., Anzanpour, A., Conti, M., Dargahi, T., Moosavi, S.R., Rahmani, A.M., Liljeberg, P, 2016. \u0026ldquo;On the feasibility of attributebased encryption on Internet of Things devices\u0026rdquo;. IEEE Micro 36(6), 25\u0026ndash;35.\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":true,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"Attribute-Based Access Control, Near Field Communication, Trusted Execution Environment, Transport Layer Security","lastPublishedDoi":"10.21203/rs.3.rs-4630516/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-4630516/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eAccess control systems are the most utilized preventive and protective solution for guaranteeing highly secure and monitored environments where people can move about and live in complete safety. The Smart Building Access Management System using Digital Keys provides an efficient means of granting or revoking access to users in residential and commercial buildings. It responds to the ever-increasing demand for internet-connected devices and the need for a system that is secure, convenient, and easy to manage. Despite the pivotal role of access control systems, the current technological standing shows severe security vulnerabilities, a lack of practical management solutions and a non-optimized user conveniency. Majorly used credential technologies show an absence of encryption capabilities. Some user management solutions do not scale well and present a lack of proper scalability. Our proposed system in this paper is the Attribute-Based Access Control System (ABACS) for Smart Building Access Management System, which offers an internet-oriented physical access control system, based on an end-to-end secured solution, an easy-to-use hybrid cloud-based system for effective access management and a mobile user application for optimal convenience. Authentication, integrity, and confidentiality are guaranteed using multiple security methods, including a Trusted Execution Environment (TEE) for a safe digital key storage and encryption, and the Transport Layer Security (TLS) protocol for secured channel communication, supported by a trusted third-party Certification Authority (CA). The Near-Field Communication (NFC) channel is used for quick key sharing. Access policies and user management is achieved using the hybrid fog-cloud paradigm and the Attribute-Based Access Control (ABAC) model. Finally, user convenience and optimal user experience are reached by means of an aesthetic mobile application for digital key generation and storage. The testing results and performance evaluation show that our proposed system’s backend, efficiently processes requests in both sequential and concurrent scenarios. With sequential requests, our proposed system’s longest-performing request outperforms iPACS’s by at least tenfold. In addition, with concurrent requests, our system shows a performance at least twice better than iPACS’s.\u003c/p\u003e","manuscriptTitle":"ABACS: Attribute-Based Access Control System using digital keys","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2024-07-17 09:08:59","doi":"10.21203/rs.3.rs-4630516/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"63b5aa1c-8aae-4546-868c-936187b6a467","owner":[],"postedDate":"July 17th, 2024","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[],"tags":[],"updatedAt":"2024-09-09T11:40:41+00:00","versionOfRecord":[],"versionCreatedAt":"2024-07-17 09:08:59","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-4630516","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-4630516","identity":"rs-4630516","version":["v1"]},"buildId":"qtupq5eGEP_6zYnWcrvyt","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}