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 cross-domain 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.
With the development of cloud computing and the Internet of Things (IoT) technology, distributed systems and distributed storage have been widely used. In the distributed environment, devices and resources are scattered in different domains. There is an urgent need for resource sharing and device interoperability between domains [1–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 , 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. Thus, a fine-grained, dynamic, and secure access control  isolates devices and resources between domains by restricting permissions for accessing subjects via access policies  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]. Therefore, a number of cross-domain access control mechanisms have been proposed to realize secure resource sharing between heterogeneous domains [12–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 . These 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.
2. Related Works
With regard to secure interoperability in a multidomain environment, numerous literature studies have been proposed. Denker et al.  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.  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–33] proposed blockchain-based access control schemes for the IoT environment. Sukhodolskiy and Zapechnikov  proposed a blockchain-based access control system for cloud storage, which provides access control over the data stored in the cloud. Zhou et al.  proposed a blockchain-based access control scheme for smart grids. Wang et al.  design a blockchain-based framework for data sharing with fine-grained access control. Guo et al.  proposed a hybrid architecture to facilitate access control of EHR data by using both blockchain and edge node. Steichen et al.  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.
In this section, we review some relevant background knowledge that will be used in this article.
3.1. Role-Based Access Control
As shown in 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 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 . When a transaction is synchronized to the blockchain, it cannot be modified or deleted, so all transactions are traceable on the blockchain ledger.
Common blockchain platforms include Bitcoin , Ethereum , EOS , and Hyperledger Fabric , which can be divided into five layers: network layer, consensus layer, data layer, smart contract layer, and application layer. The structure of these blockchain platforms are shown in Table 1.
3.3. 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 <>, where is the role in the domain and is the mapped role of in domain . The user with the role in has the corresponding permissions of the role in domain .
3.4. 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  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 (, ). KeyDer: on input and identity () of the entity, this algorithm is run by the PKG to generate the secret signing key for the . Sign: on input and a message , this algorithm returns a signature of . Vf: on input , , , and signature , this algorithm returns 1 if is valid for ID and , and returns 0 otherwise.
4. An Overview of the Proposed System
4.1. System Model
As shown in Figure 3, the system model mainly consists of the following three parts: domain organizations (DO), domain management servers (DMS), and the blockchain (BC). 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. They 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 for the entity (DMS, user, and device) with ID.
4.2. 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. Therefore, 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.
4.3. 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.
5. System Design
This 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. Thus, 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 devName@DO_A, and DMS’s ID as DMS@DO_A. Therefore, 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.
In a blockchain system, a transaction consists of two parts: the transaction header and the payload . 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, = 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 |||| ||r || to DMSs, where 01 means Bob has read the data of this camera before, is Bob’s ID, 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.
5.2. Smart Contract
The 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. Thus, 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. The 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 user’s ID (uID), role, and the signature signed by the DMS. The function verifies the signature and determines whether the user uploaded by the DMS is in its own DO. Then, 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 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. The DMS invokes this function by sending a Uid, the role mapping rules, and the signature signed by the DMS. This function extracts the DMS_ID_des from the Uid to verify the signature. Then, 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. The function verifies the signature and determines whether the device uploaded by the DMS is in its own DO. Then, 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. Then, 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): This function is used to record the requests from users and the access decision from accessDecison/AHLaccessDecision on the blockchain.
addAHL(uID||devID||op): This 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.
5.3. Construction of the System
There are four major phases of the system, including System Setup, Access Control, Data Transmission, and Handel Dispute. The key notations are listed in Table 2.
6. Security Analysis
In this section, we will explain how our proposed system meets all the security goals as mentioned in Section 5.3.
6.1. 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. Therefore, our system can resist DMSs denying granted user access.
6.2. Modification Attack Resistant
The 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.
6.3. 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.
7. Performance Evaluation
In this section, we give a performance evaluation of the system.
7.1. System Setting
The 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 [email protected] and 4-G RAM.
7.2. 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. The 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.
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. The 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.
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
This work was supported by the Strategic Priority Research Program of the Chinese Academy of Sciences, Grant no. XDC02070600.
B. Adriano, N. Yokoya, J. Xia, G. Baier, and S. Koshimura, “Cross-domain-classification of tsunami damage via data simulation and residual-network-derived features from multi-source images,” in Proceedings of the International Conference on Geoscience and Remote Sensing Symposium, pp. 4947–4950, Yokohama, Japan, July 2019.View at: Publisher Site | Google Scholar
A. S. Salehi, C. Rudolph, and M. Grobler, “A dynamic cross-domain access control model for collaborative healthcare application,” in Proceedings of the IFIP/IEEE Symposium on Integrated Network and Service Management (IM), pp. 643–648, Arlington, VA, USA, April 2019.View at: Google Scholar
K. Niu, Y. Huang, and L. Wang, “Fusing two directions in cross-domain adaption for real life person search by language,” in Proceedings of the IEEE/CVF International Conference on Computer Vision Workshop (ICCVW), pp. 1815–1818, Seoul, Korea (South), October 2019.View at: Publisher Site | Google Scholar
IoT security white paper 2018 [Online]. Available: https://www.huawei.com/minisite/iot/img/iot_security_white_paper_2018_v2_en.pdf.
Z. Q. He, Y. L. Zhang, L. G. Zhang et al., “Access control architecture of service composition based on role mapping,” Computer Technology and Development, vol. 25, no. 10, pp. 149–153, 2015.View at: Google Scholar
H. Zhang, J. Wang, and J. Chang, “A multi-level security access control framework for cross-domain networks,” in Proceedings of the 2017 IEEE International Conference on Computational Science and Engineering (CSE) and IEEE International Conference on Embedded and Ubiquitous Computing (EUC), pp. 316–319, Guangzhou, China, July 2017.View at: Publisher Site | Google Scholar
J. Du, C. Chen, J. Zhu, and X. Li, “Research on association securities in cross-domain interoperation model in pervasive computing,” in Proceedings of the Third International Conference on Pervasive Computing and Applications, pp. 953–958, Alexandria, Egypt, October 2008.View at: Publisher Site | Google Scholar
A. Liguori, F. Benedetto, G. Giunta, N. Kopal, and A. Wacker, “SoftGap: a multi independent levels of security cross-domain solution,” in Proceedings of the 3rd International Conference on Future Internet of Things and Cloud, pp. 754–759, Rome, Italy, August 2015.View at: Publisher Site | Google Scholar
R. Patel, U. Thakar, and V. Tewari, “A mechanism for operation level role based access control in web services,” in Proceedings of the 7th International Conference on Communication Systems and Network Technologies (CSNT), pp. 384–388, Nagpur, India, November 2017.View at: Publisher Site | Google Scholar
T. Phillips, X. Yu, B. Haakenson, and X. Zou, “Design and implementation of privacy-preserving, flexible and scalable role-based hierarchical access control,” in Proceedings of the 1st IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS-ISA), pp. 46–55, Los Angeles, CA, USA, December 2019.View at: Publisher Site | Google Scholar
J. F. Chan, T. C. Yang, and H. T Liaw, “A cross cloud authorization mechanism using NFC and RBAC technology,” in Ubiquitous Computing Application and Wireless Sensor. Lecture Notes in Electrical Engineering, J. Park, Y. Pan, HC. Chao, and G. Yi, Eds., vol. 331, Springer, Berlin, Germany, 2015.View at: Google Scholar
N. Ghosh, D. Chatterjee, and S. K. Ghosh, “An efficient heuristic-based role mapping framework for secure and fair collaboration in SaaS cloud,” in Proceedings of the International Conference on Cloud and Autonomic Computing, pp. 227–236, London, UK, September 2014.View at: Publisher Site | Google Scholar
A. Kapadia, J. Al-Muhtadi, R. H. Campbell et al., “Irbac 2000: secure interoperability using dynamic role translation,” in Proceedings of International Conference Internet Computing (IC), pp. 26–29, Las Vegas, NV, USA, June 2000.View at: Google Scholar
V. C. Hu, D. F. Ferraiolo, R. Kuhn et al., Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NIST Special Publication, Gaithersburg, MD, USA, 2014.
D. R. Putra, B. Anggorojati, and A. P. Pratama Hartono, “Blockchain and smart-contract for scalable access control in internet of things,” in Proceedings of the International Conference on ICT for Smart Society (ICISS), pp. 1–5, Bandung, Indonesia, November 2019.View at: Publisher Site | Google Scholar
I. Sukhodolskiy and S. Zapechnikov, “A blockchain-based access control system for cloud storage,” in Proceedings of the IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EIConRus), pp. 1575–1578, Moscow, Russia, January 2018.View at: Publisher Site | Google Scholar
M. Steichen, B. Fiz, R. Norvill, W. Shbair, and R. State, “Blockchain-based, decentralized access control for IPFS,” in Proceedings of the IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pp. 1499–1506, Halifax, NS, Canada, July 2018.View at: Publisher Site | Google Scholar
S. T. Chen, J. F. Xu, Y. X. Hang, and J. W. Li, “Role-based access control for memory security on Network-on-Chips,” in Proceedings of the 13th IEEE International Conference on Solid-State and Integrated Circuit Technology (ICSICT), pp. 1422–1424, Hangzhou, China, October 2016.View at: Publisher Site | Google Scholar
S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system. [Online]. Available: http://bitcoin.org/bitcoin.pdf.
Ethereum smart contract platform [Online]. Available: https://www.ethereum.org/.
EOS.IO Technical White Paper v2 [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md.
C. Cachin, “Architecture of the hyperledger blockchain fabric,” in Proceedings of the Workshop on Distributed Cryptocurrencies and Consensus Ledgers, Chicago, Illinois, USA, July 2016.View at: Google Scholar
E. Kiltz and G. Neven, “Identity-based signatures,” Identity-Based Cryptography, vol. 2, pp. 31–44, 2009.View at: Google Scholar