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

Authors: Shuang Sun; Shudong Chen; Rong Du
Journal: Scientific Programming
 (2020)

---

## Abstract

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.


---

## Body

## 1. Introduction

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 [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. Thus, a fine-grained, 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]. 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 [17]. 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

Due to the extensive use of the role-based access control (RBAC) mechanism [18–22], role mapping cross-domain access control is a typical method to realize interoperation between domains [23, 24].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–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.


## 3. Preliminaries

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 Figure1, 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).Figure 1
The RBAC model.


### 3.2. 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.Common blockchain platforms include Bitcoin [42], Ethereum [43], EOS [44], and Hyperledger Fabric [45], 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.Table 1
Blockchain platform.
BitcoinEthereumEOSHyperledger fabricApplicationBitcoinDappEOS/DappHyper ledgerSmart contractScriptSolidityC++Go/javaDataFile systemLevelDBIPFSFile system/level DBConsensusPOWPOW/POSBFT-DPOSPBFT/SBFTNetworkTCP-based P2PTCP-based P2PTCP-based P2PHTTP/2-based P2P


### 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 Figure2, role mapping rules can be expressed by a tuple <D1,r1,D2,r2>, where r1 is the role in the domain D1 and r2 is the mapped role of r1 in domain D2. The user with the role r1 in D1 has the corresponding permissions of the role r2 in domain D2.Figure 2
Role mapping.


### 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 [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 inputmsk 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 inputusk and a message M, this algorithm returns a signature σ of M.Vf: on inputmpk, ID, M, and signature σ, this algorithm returns 1 if σ is valid for ID and M, and returns 0 otherwise.


## 3.1. Role-Based Access Control

As shown in Figure1, 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).Figure 1
The RBAC model.


## 3.2. 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.Common blockchain platforms include Bitcoin [42], Ethereum [43], EOS [44], and Hyperledger Fabric [45], 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.Table 1
Blockchain platform.
BitcoinEthereumEOSHyperledger fabricApplicationBitcoinDappEOS/DappHyper ledgerSmart contractScriptSolidityC++Go/javaDataFile systemLevelDBIPFSFile system/level DBConsensusPOWPOW/POSBFT-DPOSPBFT/SBFTNetworkTCP-based P2PTCP-based P2PTCP-based P2PHTTP/2-based P2P


## 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 Figure2, role mapping rules can be expressed by a tuple <D1,r1,D2,r2>, where r1 is the role in the domain D1 and r2 is the mapped role of r1 in domain D2. The user with the role r1 in D1 has the corresponding permissions of the role r2 in domain D2.Figure 2
Role mapping.


## 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 [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 inputmsk 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 inputusk and a message M, this algorithm returns a signature σ of M.Vf: on inputmpk, ID, M, and signature σ, this algorithm returns 1 if σ is valid for ID and M, and returns 0 otherwise.


## 4. An Overview of the Proposed System

### 4.1. System Model

As shown in Figure3, 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 keyIsk for the entity (DMS, user, and device) with ID.Figure 3
An overview of the proposed system. Step 1: DMSs upload the user roles, role map rules, and policies of devices on the blockchain. 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.


### 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 thann 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.


## 4.1. System Model

As shown in Figure3, 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 keyIsk for the entity (DMS, user, and device) with ID.Figure 3
An overview of the proposed system. Step 1: DMSs upload the user roles, role map rules, and policies of devices on the blockchain. 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.


## 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 thann 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.


### 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, TXrequest = 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 ||IDBob|| IDali_cam ||r ||sigIskBob01IDBobIDali_camr to DMSs, where 01 means Bob has read the data of this camera before, IDBob is Bob’s ID, IDali_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.


### 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. (Algorithms1–12).Algorithm 1: uploadURole.
(1)
Input: uID, uRole, sig(2)
output: bool(3)
% invoke by DMSs to upload the users’ role in the DO.(4)
%sig=signatureDMS_ISKuID,uRole(5)
if verify(DMS_ID, sig) = true && uID.DO = = DMS_ID.DOthen(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;(11)
}(12)
else(13)
return 1;Algorithm 2: uploadRM.
(1)
Input: Uid, rule, sig(2)
output: bool(3)
% invoke by DMS to upload the role map rule.(4)
% Uid is used to retrieve role mapping rules between DOs.(5)
% Uid = ‘DMS_ID_sour-DMS_ID_dest’(6)
% rule = {“role1,role2”, “role1, role3”,…}(7)
%sig=signatureDMS_des_ISKUid,rule(8)
DMS_ID_des = extract(Uid)(9)
if verify(DMS_ID_des, sig) == true then(10)
stub.PutState(Uid, rule); % store key = Uid, value = rule in blockchain(11)
return 0;(12)
else(13)
return 1;Algorithm 3: uploadPolicy.
(1)
Input: devID, policy, sig(2)
output: bool(3)
% invoke by DMS to upload the device’s access policies.(4)
% policy = {“role1, op1&op2&op3”;…}(5)
%sig=signatureDMS_ISKpolicy(6)
if verify (DMS_ID, sig) = true && devID.DO = = DMS_ID.DO then(7)
{(8)
if stub.GetState (devPK) ! = null then(9)
updateAHL (policy_update, devPK);(10)
stub.PutState (devPK, policy);(11)
return 0;(12)
}(13)
else(14)
return 1;Algorithm 4: getURole.
(1)
Input: uID(2)
output: string(3)
% obtain the user’s role from blockchain.(4)
role = stub.GetState (uID)(5)
if role ! = nullthen(6)
return role;(7)
else(8)
return ‘9000’;Algorithm 5: mapRole.
(1)
Input: role, Uid(2)
output: string(3)
% map a role to the DMS’s role.(4)
rule = Stub.GetState (Uid)(5)
role’ = match (role, rule)(6)
if (role’ ! = null) then(7)
return role’;(8)
else(9)
return ‘9001’;Algorithm 6: getPolicy.
(1)
Input: devID(2)
output: string(3)
% obtain the device’s access policy.(4)
policy = Stub.GetState (devID);(5)
if (policy ! = null) then(6)
return policy;(7)
else(8)
return ‘9002’;Algorithm 7: accessDecision.
(1)
Input: request, Uid, sig(2)
output: string(3)
% invoke by DMS to make an access control.(4)
% sig =signatureuIskrequest(5)
% request = 00|| uID || devID || op, op is an access control order.(6)
if verify (uID, sig) = true then(7)
role = getURole (uID)(8)
if role = = ‘9000’ then(9)
{(10)
recordAudit (request, ‘9000’);(11)
return ‘9000’;(12)
}(13)
DMS_ID_sou = find_DMS_ID (uID) % find DMS’s ID whose DMS_ID_sou.DO = = uID.DO(14)
DMS_ID_des = find_DMS_ID (devID) % find DMS’s ID whose DMS_ID_des.DO = = devID.DO(15)
role’ = mapRole (role, DMS_ID_sou||DMS_ID_des);(16)
if role’ = = ‘9001’ then(17)
{(18)
recordAudit (request, ‘9001’);(19)
return ‘9001’;(20)
}(21)
policy = getPolicy (devID)(22)
if policy = = ‘9002’ then(23)
{(24)
recordAudit (request, ‘9002’)(25)
return ‘9002’;(26)
}(27)
if ((role, devID, op)∈ policy) then(28)
recordAudit (request, permit);(29)
addAHL (uID||devID||op);(30)
return permit;(31)
else(32)
recordAudit (request, ‘9003’);(33)
return ‘9003’;(34)
else(35)
return ‘sign_error’;Algorithm 8: AHLaccessDecision.
(1)
Input: request, sig(2)
output: string(3)
% invoke by users to make an AHL based access control.(4)% sig =signatureuIskrequest(5)%request = 01|| uID || devID || op, op is an access control order.(6)if verify (uID, sig) = true then(7) ahList = getAHL();(8)if ahList.isNoexist (uID||devID||op) then(9)  recordAudit (request, ‘9004’);(10)  return ‘9004’;(11) else(12)  recordAudit (request, permit);(13)else(14) return ‘sign_error’;Algorithm 9: recordAudit.
(1)
Input: request, decision(2)
output: string(3)
% record audit on blockchain(4)
% decision = 9000/9001/9002/9003/9004/permit(5)
time = time.Now();(6)
stub.PutState (request||time, decision);Algorithm 10: addAHL.
(1)
Input: uID||devID||op(2)
output: bool(3)
% add a permitted access request on the AHL.(4)
ahList = getAHL();(5)
if ahList.isNoexist (uID||devID||op) then(6)
ahList.push (uID||devID||op);(7)
return 0;Algorithm 11: getAHL.
(1)
Input: null(2)
output: string(3)
% get the AHL.(4)
return ahList;Algorithm 12: updateAHL.
(1)
Input: string, string % userRole_update, policy_update %uID, devID(2)
output: bool(3)
ahList = getAHL();(4)
Case “userRole_update”;(5)
for list in ahList(6)
if list.uID = = uIDthen(7)
ahList.DeleteRow (list);(8)
return 0;(9)
Case “policy_update”;(10)
for list in ahList(11)
if list.devID = = devID then(12)
ahList.DeleteRow (list);(13)
return 0;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 Table2.Table 2
Symbols of the system.
SymbolDescriptionH.Collision resistant hash functionSign.Signature algorithmEnckey.Symmetric encryption algorithmEncpk.Asymmetric encryption algorithmpkDMS,skDMSThe device’s DMS’s key pairpku,skuThe user’s key pairpkd,skdThe device’s key pairdataResource data requested by usersSystem 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 cross-domain 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, isrequest=tag,uID,devID,r,sig, where the sig=siguIsktag,uID,devID,r is signed by the user. Then, the user broadcasts the request in the DMSs network. If the tag is 00, the DMS invokes accessDecision. If the tag is 01, the DMS invokes AHLaccessDecision.Data transmission: once the access decision is received, the device returns data to the user who is permitted to access the data resource. The device generates a session key to encrypt the dataEnckeydata and signs the hash of the data SignskdHdata, then returns Enckeydata,Encpkukey,SignskdHdata to the user.Handle dispute: users can verify access decisions (9000/9001/9002/9003/9004). While the DMS can trace back to a user’s access record to detect the user’s abnormal access behavior. Moreover, the audit records can also give evidence to the AHL.


## 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, TXrequest = 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 ||IDBob|| IDali_cam ||r ||sigIskBob01IDBobIDali_camr to DMSs, where 01 means Bob has read the data of this camera before, IDBob is Bob’s ID, IDali_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.


## 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. (Algorithms1–12).Algorithm 1: uploadURole.
(1)
Input: uID, uRole, sig(2)
output: bool(3)
% invoke by DMSs to upload the users’ role in the DO.(4)
%sig=signatureDMS_ISKuID,uRole(5)
if verify(DMS_ID, sig) = true && uID.DO = = DMS_ID.DOthen(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;(11)
}(12)
else(13)
return 1;Algorithm 2: uploadRM.
(1)
Input: Uid, rule, sig(2)
output: bool(3)
% invoke by DMS to upload the role map rule.(4)
% Uid is used to retrieve role mapping rules between DOs.(5)
% Uid = ‘DMS_ID_sour-DMS_ID_dest’(6)
% rule = {“role1,role2”, “role1, role3”,…}(7)
%sig=signatureDMS_des_ISKUid,rule(8)
DMS_ID_des = extract(Uid)(9)
if verify(DMS_ID_des, sig) == true then(10)
stub.PutState(Uid, rule); % store key = Uid, value = rule in blockchain(11)
return 0;(12)
else(13)
return 1;Algorithm 3: uploadPolicy.
(1)
Input: devID, policy, sig(2)
output: bool(3)
% invoke by DMS to upload the device’s access policies.(4)
% policy = {“role1, op1&op2&op3”;…}(5)
%sig=signatureDMS_ISKpolicy(6)
if verify (DMS_ID, sig) = true && devID.DO = = DMS_ID.DO then(7)
{(8)
if stub.GetState (devPK) ! = null then(9)
updateAHL (policy_update, devPK);(10)
stub.PutState (devPK, policy);(11)
return 0;(12)
}(13)
else(14)
return 1;Algorithm 4: getURole.
(1)
Input: uID(2)
output: string(3)
% obtain the user’s role from blockchain.(4)
role = stub.GetState (uID)(5)
if role ! = nullthen(6)
return role;(7)
else(8)
return ‘9000’;Algorithm 5: mapRole.
(1)
Input: role, Uid(2)
output: string(3)
% map a role to the DMS’s role.(4)
rule = Stub.GetState (Uid)(5)
role’ = match (role, rule)(6)
if (role’ ! = null) then(7)
return role’;(8)
else(9)
return ‘9001’;Algorithm 6: getPolicy.
(1)
Input: devID(2)
output: string(3)
% obtain the device’s access policy.(4)
policy = Stub.GetState (devID);(5)
if (policy ! = null) then(6)
return policy;(7)
else(8)
return ‘9002’;Algorithm 7: accessDecision.
(1)
Input: request, Uid, sig(2)
output: string(3)
% invoke by DMS to make an access control.(4)
% sig =signatureuIskrequest(5)
% request = 00|| uID || devID || op, op is an access control order.(6)
if verify (uID, sig) = true then(7)
role = getURole (uID)(8)
if role = = ‘9000’ then(9)
{(10)
recordAudit (request, ‘9000’);(11)
return ‘9000’;(12)
}(13)
DMS_ID_sou = find_DMS_ID (uID) % find DMS’s ID whose DMS_ID_sou.DO = = uID.DO(14)
DMS_ID_des = find_DMS_ID (devID) % find DMS’s ID whose DMS_ID_des.DO = = devID.DO(15)
role’ = mapRole (role, DMS_ID_sou||DMS_ID_des);(16)
if role’ = = ‘9001’ then(17)
{(18)
recordAudit (request, ‘9001’);(19)
return ‘9001’;(20)
}(21)
policy = getPolicy (devID)(22)
if policy = = ‘9002’ then(23)
{(24)
recordAudit (request, ‘9002’)(25)
return ‘9002’;(26)
}(27)
if ((role, devID, op)∈ policy) then(28)
recordAudit (request, permit);(29)
addAHL (uID||devID||op);(30)
return permit;(31)
else(32)
recordAudit (request, ‘9003’);(33)
return ‘9003’;(34)
else(35)
return ‘sign_error’;Algorithm 8: AHLaccessDecision.
(1)
Input: request, sig(2)
output: string(3)
% invoke by users to make an AHL based access control.(4)% sig =signatureuIskrequest(5)%request = 01|| uID || devID || op, op is an access control order.(6)if verify (uID, sig) = true then(7) ahList = getAHL();(8)if ahList.isNoexist (uID||devID||op) then(9)  recordAudit (request, ‘9004’);(10)  return ‘9004’;(11) else(12)  recordAudit (request, permit);(13)else(14) return ‘sign_error’;Algorithm 9: recordAudit.
(1)
Input: request, decision(2)
output: string(3)
% record audit on blockchain(4)
% decision = 9000/9001/9002/9003/9004/permit(5)
time = time.Now();(6)
stub.PutState (request||time, decision);Algorithm 10: addAHL.
(1)
Input: uID||devID||op(2)
output: bool(3)
% add a permitted access request on the AHL.(4)
ahList = getAHL();(5)
if ahList.isNoexist (uID||devID||op) then(6)
ahList.push (uID||devID||op);(7)
return 0;Algorithm 11: getAHL.
(1)
Input: null(2)
output: string(3)
% get the AHL.(4)
return ahList;Algorithm 12: updateAHL.
(1)
Input: string, string % userRole_update, policy_update %uID, devID(2)
output: bool(3)
ahList = getAHL();(4)
Case “userRole_update”;(5)
for list in ahList(6)
if list.uID = = uIDthen(7)
ahList.DeleteRow (list);(8)
return 0;(9)
Case “policy_update”;(10)
for list in ahList(11)
if list.devID = = devID then(12)
ahList.DeleteRow (list);(13)
return 0;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 Table2.Table 2
Symbols of the system.
SymbolDescriptionH.Collision resistant hash functionSign.Signature algorithmEnckey.Symmetric encryption algorithmEncpk.Asymmetric encryption algorithmpkDMS,skDMSThe device’s DMS’s key pairpku,skuThe user’s key pairpkd,skdThe device’s key pairdataResource data requested by usersSystem 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 cross-domain 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, isrequest=tag,uID,devID,r,sig, where the sig=siguIsktag,uID,devID,r is signed by the user. Then, the user broadcasts the request in the DMSs network. If the tag is 00, the DMS invokes accessDecision. If the tag is 01, the DMS invokes AHLaccessDecision.Data transmission: once the access decision is received, the device returns data to the user who is permitted to access the data resource. The device generates a session key to encrypt the dataEnckeydata and signs the hash of the data SignskdHdata, then returns Enckeydata,Encpkukey,SignskdHdata to the user.Handle dispute: users can verify access decisions (9000/9001/9002/9003/9004). While the DMS can trace back to a user’s access record to detect the user’s abnormal access behavior. Moreover, the audit records can also give evidence to the AHL.


## 6. Security Analysis

In this section, we will explain how our proposed system meets all the security goals as mentioned in Section5.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.


## 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-2130CPU@3.40GHz 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. Table3 shows the time cost for each smart contract during the system setup phase.Table 3
System setup phase’s time cost for each smart contract.
Smart contract (implement function)Time cost (ms)System setupuploadURole (user roles storage) (user roles update)1.7786 2.3397uploadRM (role mapping rules storage)2.9921uploadPolicy (access policies storage) (access policies update)1.8215 3.0159Total time6.5922After 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. Table4 shows the time cost for each smart contract during the access control phase.Table 4
Access control phase’s time cost for each smart contract.
Access control phaseSmart contract (implement function)Time cost (AHLaccessDecision)Time cost (accessDecision)getURole (get user’s role)00.087mapRole (map user’s role)00.679getPolicy (get device’s policy)00.023getAHL (get permitted access request list)0.02170Access control (make access decision)0.01320.0872addAHL (add permitted access request)0.02020.0202recordAudit (store request and access decision)0.20550.2055Total time0.26061.1019In 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 Table5.Table 5
Handle dispute phase’s time cost.
Handle dispute phaseFunction (verify error)Time cost (ms)Audit (9000)0.134Audit (9001)0.476Audit (9002)0.0518Audit (9003)0.0326Audit (9004)0.0152To 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.Figures4–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.Figure 4
Time cost for system setup phase with different numbers of DOs and entities.Figure 5
Time cost for access control phase with different numbers of DO entities.Figure 6
Time cost for the handle dispute phase of different numbers of DOs and entities.
(a)(b)(c)(d)(e)


## 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-2130CPU@3.40GHz 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. Table3 shows the time cost for each smart contract during the system setup phase.Table 3
System setup phase’s time cost for each smart contract.
Smart contract (implement function)Time cost (ms)System setupuploadURole (user roles storage) (user roles update)1.7786 2.3397uploadRM (role mapping rules storage)2.9921uploadPolicy (access policies storage) (access policies update)1.8215 3.0159Total time6.5922After 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. Table4 shows the time cost for each smart contract during the access control phase.Table 4
Access control phase’s time cost for each smart contract.
Access control phaseSmart contract (implement function)Time cost (AHLaccessDecision)Time cost (accessDecision)getURole (get user’s role)00.087mapRole (map user’s role)00.679getPolicy (get device’s policy)00.023getAHL (get permitted access request list)0.02170Access control (make access decision)0.01320.0872addAHL (add permitted access request)0.02020.0202recordAudit (store request and access decision)0.20550.2055Total time0.26061.1019In 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 Table5.Table 5
Handle dispute phase’s time cost.
Handle dispute phaseFunction (verify error)Time cost (ms)Audit (9000)0.134Audit (9001)0.476Audit (9002)0.0518Audit (9003)0.0326Audit (9004)0.0152To 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.Figures4–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.Figure 4
Time cost for system setup phase with different numbers of DOs and entities.Figure 5
Time cost for access control phase with different numbers of DO entities.Figure 6
Time cost for the handle dispute phase of different numbers of DOs and entities.
(a)(b)(c)(d)(e)


## 8. 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. 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.



---

*Source: 8832568-2020-08-10.xml*