Trusted and Efficient Cross-Domain Access Control System Based on Blockchain

In a distributed system, cross-domain access control is an important mechanism to realize secure data sharing among multiple domains. Most of the existing cross-domain access control mechanisms are generally based on a single-server architecture, which has limitations in terms of security and reliability (the access decision may be incorrect) and completeness and confidentiality (the access records can be modified). Blockchain technology with decentralization, verifiability, and immutability properties can solve these problems. Motivated by these facts, in this article, we construct a trusted and efficient cross-domain access control system based on blockchain. Consequently, we integrate blockchain and role mapping technology to provide reliable and verifiable crossdomain access process. We use blockchain to record user roles, role mapping rules, access policies, and audit records, realizing user self-validation, and access nonreputation. Considering the low throughput of the blockchain, we design an efficient smart contract to make the access decision based on the access history of users. Finally, a performance evaluation of the system is presented to demonstrate the feasibility of the proposed system.


Introduction
With the development of cloud computing and the Internet of ings (IoT) technology, distributed systems and distributed storage have been widely used. In the distributed environment, devices and resources are scattered in different domains. ere is an urgent need for resource sharing and device interoperability between domains [1][2][3][4][5][6]. For example, by opening government data, the government can help companies accurately predict corporate financial risks and avoid financial risks. Companies are promoting the development of local tourism by sharing traffic and travel data.
However, the security issues of the distributed environment have become increasingly prominent. According to the IoT security white paper 2018 [7], in March 2018, the Under Armour company exposed personal information for 150 million MyFitnessPal users in a data breach. Similarly, the high-risk vulnerability, identified as CVE-8-0171, allows an attacker bypassing authentication and execute any code to control the device completely, resulting in the configuration files being emptied. In April 2018, it was found that the WIFIKey-universal was involved in stealing personal information, invading others' WIFI networks, and sharing WIFI password.
Access control is a security mechanism that restricts access to critical or valuable resources such as data, services, computational systems, and storage space.
us, a finegrained, dynamic, and secure access control [8] isolates devices and resources between domains by restricting permissions for accessing subjects via access policies [9] and could provide security and privacy protection for a distributed system. However, domains have different security goals that result in heterogeneous access control mechanisms and access policies [10,11]. erefore, a number of cross-domain access control mechanisms have been proposed to realize secure resource sharing between heterogeneous domains [12][13][14][15][16], but almost all of them are based on a single-server architecture. Existing cross-domain access control mechanisms based on single-server architectures generally have the following limitations: (1) Lack of security and reliability: a single-server cannot provide a trusted access decision, for a malicious or compromised server can easily prevent granted users from accessing resources or permit illegal users to access resources. (2) Lack of completeness and confidentiality: users ' historical access records stored by the server may be modified or deleted without the server's knowledge.
To solve these limitations, the role of blockchain technology has been highlighted in multiple-domain access control scenarios due to its properties such as decentralization, immutability, and verifiability [17]. ese properties are beneficial in constructing a more secure, verifiable, and reliable access control systems.
To provide reliable and verifiable cross-domain access control processes, we integrate blockchain and role mapping access control. In our system, the user roles, role mapping rules, and access policies are publicly visible on the blockchain, allowing any users to verify whether their role satisfied the access policy at any time, which prevents a single-server from fraudulently denying the granted users or permitting the illegal users to access the resources. Considering the low throughput of the blockchain, we design an efficient smart contract which makes access decisions directly based on the access history. All requests and decisions will be recorded on the blockchain. Due to the immutability of blockchain, these requests and decisions are not easy to be tampered or deleted, providing reliable auditing.
With regard to secure interoperability in a multidomain environment, numerous literature studies have been proposed. Denker et al. [25] proposed a cross-domain access control mechanism based on PKI and RBAC. According to Grit, the PKI requires each domain has its own CA center to integrate the access control policies. Kapadia et al. [26] proposed an interdomain security interoperability model based on role mapping, which can create a flexible strategy for dynamic role mapping between the local domain and the external domain.
Upon the benefits of distributed access control, the authors in [27][28][29][30][31][32][33] proposed blockchain-based access control schemes for the IoT environment. Sukhodolskiy and Zapechnikov [34] proposed a blockchain-based access control system for cloud storage, which provides access control over the data stored in the cloud. Zhou et al. [35] proposed a blockchain-based access control scheme for smart grids. Wang et al. [36] design a blockchain-based framework for data sharing with fine-grained access control. Guo et al. [37] proposed a hybrid architecture to facilitate access control of EHR data by using both blockchain and edge node. Steichen et al. [38] use blockchain to realize decentralized access control for IPFS. Although these blockchain-based access control systems provide decentralized, reliable, and secure access control methods, they cannot be applied in a multiple-domain system with heterogeneous security and privacy requirements.

Preliminaries
In this section, we review some relevant background knowledge that will be used in this article. Figure 1, the role-based access control (RBAC) model contains three basic elements: Users, Roles, and Permissions (PERM). It grants permissions to roles rather than users; thus, users obtain operation permissions via roles assignment [39,40]. Systems create appropriate roles according to the system's tasks. After roles are created, systems grant their permission. Finally, users are assigned to roles based on the system's security requirement. Users and permissions are linked by roles; therefore, with the roles, users can operate (access or control) the objects (devices or resources).

Blockchain.
Blockchain is more used as the underlying technology to provide decentralized, distributed antidestruction, traceability, and tamper-resistant services, than a decentralized electronic currency trading system. Each node in the distributed network maintains the same ledger, so it does not need a third party to provide data service [41]. When a transaction is synchronized to the blockchain, it cannot be modified or deleted, so all transactions are traceable on the blockchain ledger.

Cross-Domain Access Control Based on Role Mapping.
Role mapping technology realizes cross-domain access by defining rules for mapping roles between two domains. As shown in Figure 2, role mapping rules can be expressed by a tuple <D 1 , r 1 , D 2 , r 2 >, where r 1 is the role in the domain D 1 and r 2 is the mapped role of r 1 in domain D 2 . e user with the role r 1 in D 1 has the corresponding permissions of the role r 2 in domain D 2 .

Identity-Based
Signature. In our system, we use the Identity-based signature (IBS) to provide the identification of entities. IBS allows entity to generate a public key from a known identity (ID) such as email address, domain name, or a physical IP address. A trusted third party, called the Private Key Generator (PKG), generates the corresponding private keys for the ID. Kiltz et al [46] defined a set of four algorithms that form a complete IBS scheme: Setup: this algorithm is run by the PKG one time for creating the whole IBS environment, which includes a master key pair (mpk, msk). KeyDer: on input msk and identity (ID) of the entity, this algorithm is run by the PKG to generate the secret signing key Isk for the ID. Sign: on input usk and a message M, this algorithm returns a signature σ of M. Vf: on input mpk, ID, M, and signature σ, this algorithm returns 1 if σ is valid for ID and M, and returns 0 otherwise. Figure 3, the system model mainly consists of the following three parts: domain organizations (DO), domain management servers (DMS), and the blockchain (BC).

System Model. As shown in
Domain organization: DOs include users, devices, and a DMS. Users are cross-domain requesters. Devices are resource owners and can define access control policies to decide who can access their resources. Domain management server: DMSs are responsible for formulating role mapping rules between DOs. ey upload the role mapping rules, users' roles, and devices' access policies onto the blockchain. DMS is also responsible for providing cross-domain access services for users. In addition, all DMSs jointly maintain the blockchain. Blockchain: the BC is used to supervise the DMSs. It records user roles, role mapping rules, access control policies, and the audit records which contain requests and the access decisions. To prevent malicious attackers, it uses a consensus algorithm to ensure the blockchain ledger is consistent. Private key generator: PKG generates the secret signing key Isk for the entity (DMS, user, and device) with ID.

Secure Assumption.
To ensure the security of our system, we make the following security assumptions. Assumption 1. In our system, we assume that the DMSs cannot forge roles for users' illegal access.
Assumption 2. In our system, as a blockchain maintainer, the DMSs may become byzantine nodes because of various malicious attacks. erefore, we assume that the number of byzantine nodes is no more than n out of 3 n+1 CBMs.
Assumption 3. In our system, we assumed that PKG can verify the authenticity of the entity's identity.

Security Goal
DMS attacks resistant: to ensure that the granted users can access resources, the system should be able to realize user self-validation. Modification attacks resistant: the system should able to resist the attacker to modify the broadcasted request, request transactions, and replied data. In addition, the system should be able to resist the attacker to modify or delete the audit records. Man-in-the-Middle attacks resistant: no one but the requester can read the returned data.

System Design
is section presents the working of our system which is realized upon existing technologies, namely, blockchain and role mapping. Before presenting the system design, here, we first introduce the transaction types and the smart contract design in our system. We design the identity (ID) of the DO entity (DMS, user, and device) which contains the name of the entity and the DO information. us, anyone can determine the DO where the entity is located by its ID and then find the DMS's ID of the DO. For example, assuming DO_A is a DO, we design the DO user's ID as userName@DO_A, device's ID as dev-Name@DO_A, and DMS's ID as DMS@DO_A. erefore, anyone can determine an entity with entity@DO_A is in DO_A and find the DMS's ID (DMS@DO_A) of the DO_A.

5.1.
Transaction. In a blockchain system, a transaction consists of two parts: the transaction header and the payload [47]. In our system, a request transaction consists of a tag, user's ID (uID), device's ID (devID), access control order, and signature, that is, TX request � tag || uID || devID || access_control_order || signature. Assuming that a user, Bob, wishes to read the camera's data in Alice's room, he needs to broadcast the request � 01 ||ID Bob || ID ali cam ||r ||sig Isk Bob (01‖ID Bob ‖ID ali cam ‖r) to DMSs, where 01 means Bob has read the data of this camera before, ID Bob is Bob's ID, ID ali cam is the ID of the Alice's camera, r is the access control order of "read", and sig denotes the signature activities using a digital signature scheme.

Smart Contract.
e smart contract defines some executable logic. It will be installed in the blockchain, and it defined functions which provide interfaces invoked by a transaction.
In our system, in order to provide a trusted access control process, each DMS uses smart contract to upload their users' roles, role mapping rules between DOs, and devices' access policies onto the blockchain. In addition, we design a smart contract, accessDecision, to make access decisions based on the role and access policies recorded on the blockchain. Moreover, we use the smart contract to manage a user access history list (AHL) which records the permitted access requests of users. With this AHL, a user can easily prove he/she has access permission to the device. us, we design another smart contract, AHLaccessDecision, to make the access decision based on the AHL. AHLaccessDecision is more efficient than accessDecision. In order to provide reliable auditing, we adopt the smart contract to record the audit records that contain the requests from users and the access decision from accessDecison/AHLaccessDecision. e smart contract mainly provides the following eleven function interfaces: uploadURole (uID, uRole, sig): this function is invoked by DMSs and used to upload the users' roles onto the blockchain. Each DMS invokes this function by sending a Step 2: users broadcast their cross-domain access requests. Steps 3 and 4: the blockchain records the audit records.
Step 5: smart contract makes and returns the access decision.
Step 6: devices return the resources to users.
user's ID (uID), role, and the signature signed by the DMS. e function verifies the signature and determines whether the user uploaded by the DMS is in its own DO. en, the blockchain stores or updates the role and uses the uID as the key to retrieve the user's role. (Algorithms 1-12).
uploadRM (Uid, rule, sig): this function is invoked by DMSs and used to upload the role mapping rules between the DOs onto the blockchain. DMSs jointly formulated the role mapping rules between DOs. In addition, each DMS can only upload the rule sets that map external DO roles to its (1) Input: uID, uRole, sig (2) output: bool (3) % invoke by DMSs to upload the users' role in the DO. (4) % sig � signature DMS ISK (uID, uRole) (5) if verify(DMS_ID, sig) � true && uID.DO � � DMS_ID.DO then (6) { (7) if stub.GetState(uID) ! � null then % update the user's role (8) updateAHL(uID_update,uID); (9) stub.PutState(uID,uRole); % store key � uPK, value � rRole in blockchain (10) return 0; Scientific Programming local DO roles. DMSs construct the unique identifier (Uid), DMS_ID_sou || DMS_ID_des, as the key to retrieve the rule set, where DMS_ID_sou is the ID of the external DO's DMS and DMS_ID_des is the ID of the local DO's DMS. e DMS invokes this function by sending a Uid, the role mapping rules, and the signature signed by the DMS. is function extracts the DMS_ID_des from the Uid to verify the signature. en, it stores or updates the role mapping rules and uses the Uid as the key to retrieve the role mapping roles. uploadPolicy (devID, policy, sig): this function is invoked by DMSs and used to upload the devices' access policies onto the blockchain. Each DMS invokes this function by sending a device's ID (devID), the device's access policies, and the signature signed by the DMS. e function verifies the signature and determines whether the device uploaded by the DMS is in its own DO. en, the blockchain stores or updates the access policies and uses the devID as the key to retrieve the device's access policies. getURole (uID): Once a user's ID is received, this function returns the role of the user. mapRole (role, Uid): once a role and the unique identifier of the rule mapping rules between two Dos are received, this function maps the role according to the role mapping rules. getPolicy (devID): Once a device's public key is received, this function returns the access policies of the device.
AccessDecision (request, sig): this function is invoked by DMSs and used to make an access decision. Once an access request is received, this function gets the user's role via invoking getURole, maps the user's role via invoking mapRole, and gets the device's policy via invoking getPolicy. en, it determines whether the mapping role is satisfied with the access policies of the device. Finally, it records the audit records on the blockchain via invoking recordAudit and adds the permitted access request to the access history list.
AHLaccessDecision (request, sig): this function is used to make an access decision based on AHL. Once an access request is received, this function retrieves the permitted access history list and makes the access decision based on the receiving result.
recordAudit (request, decision): is function is used to record the requests from users and the access decision from accessDecison/AHLaccessDecision on the blockchain. addAHL(uID||devID||op): is function is used to add the permitted access requests to the AHL. getAHL(): this function is used to get the AHL. updateAHL (string, string): this function is used to delete the invalid permitted access request of the AHL when DMSs updating user roles or device access policies. If a user's role is updated, this function deletes all the list which contains the user's ID in the AHL. Similarly, if a device access policy is updated, this function deletes all the list which contains the device's ID in the AHL.

Construction of the System.
ere are four major phases of the system, including System Setup, Access Control, Data Transmission, and Handel Dispute. e key notations are listed in Table 2.
System setup: DMSs upload the users' roles, the role mapping rules, and access policies onto the blockchain via invoking uploadURole, uploadRM, and uploadPolicy. Access control: when a user wishes to publish a crossdomain access request, he/she constructs the request from his/her requirement. For example, a user wants reading the data of a device which belongs to other DO; the request constructed by the user, in this case, is request � (tag, uID, devID, r, sig), where the sig � sig uIsk (tag, uID, devID, r) is signed by the user.

Security Analysis
In this section, we will explain how our proposed system meets all the security goals as mentioned in Section 5.3.

DMSs' Attack Resistant.
We develop a blockchain to record the corresponding role mapping rules between DMSs and the access policies of the devices. Users can verify whether their roles satisfied the access policies. erefore, our system can resist DMSs denying granted user access.

Modification Attack Resistant.
e modified broadcasted transactions and replied data will be discovered and refused because of the signature and hash functions. Meanwhile, the audit records are stored on the blockchain, which inherits the solutions to resist modification attacks.

Man-in-the-Middle Attack Resistant.
We use asymmetric encryption algorithm to encrypt the returned resources (e.g., data) and then use an asymmetric encryption algorithm and the requester's public key to encrypt the session key. Attacks cannot decrypt, so they cannot read resources.

Performance Evaluation
In this section, we give a performance evaluation of the system.

System Setting.
e system's efficiency mainly depends on the blockchain platform and computing platform. For instance, in this paper, we use the Hyperledger Fabric v1.2.0 (HLF) to test the designed smart contract in our personal computer, where the system configuration is Ubuntu 18.04 LST OS (64 bits) with an Inter (R) core (TM) i3-2130 CPU@ 3.40GHz and 4-G RAM.

Blockchain Efficiency.
Generally, we simulate a system with two DOs, each DO contains three users and three devices. Each user assigned a role, and each device formulates three access policies.
During the System Setup phase, DMSs upload the users' roles, role mapping rules, and devices' policies of the DOs onto the blockchain, via invoking uploadURole, uploadRM, and uploadPolicy. We obtained the approximate time cost of these smart contracts using shell script with 1000 running times. Table 3 shows the time cost for each smart contract during the system setup phase.
After the system setup, we tested the AHLaccessDecision and accessDecision and obtained the approximate time cost of these smart contracts using shell script with 1000 running times. Table 4 shows the time cost for each smart contract during the access control phase.
In our system, users can verify an access decision (9000/ 9001/9002/9003/9004) recorded on the blockchain. Concretely, a user gets the audit records form blockchain and then verifies the correctness of the access decision on their own devices. e time cost of the handle dispute phase is shown in Table 5.
To evaluate the scalability of our system, we also conduct extensive system performance evaluation by increasing the number of DO from 2 to 5 and increasing the number of users and devices inside the DO from 3 to 20, 50, and 80. Figures 4-6 show the time cost for the system setup, access control, and handle dispute with different numbers of DOs whose users and devices number range from 3 to 20, 50, and 80.

Conclusions
Cross-domain access control and blockchain are two trending topics at the moment, and in this article, we proposed a cross-domain access control system based on blockchain. We demonstrated how blockchain can be utilized with role mapping technology to provide a user-certification and access nonreputation cross-domain access control. Specifically, the system uploads the users' roles, role mapping rules, and access policies onto the blockchain, realizing the access control process trustful. Considering the efficiency of the blockchain, we design an efficient smart contract to make the access decision based on the AHL. Finally, we record the user's access request and access decision onto the blockchain to realize the access nonreputation. e security analysis has proved our system to be secure in practical application, and the simulation experiments demonstrated that our scheme is feasible. In the future, we will research on how to solve the centralized limitations of IBS and enhance the distributed characteristics of the system.

Data Availability
No data were used to support this study.

Conflicts of Interest
e authors declare that they have no conflicts of interest.