Cross-Domain Access Control Model in Industrial IoT Environment

Abstract

The Industrial Internet of Things (IIoT) accelerates smart manufacturing and boosts production efficiency through heterogeneous industrial equipment, intelligent sensors, and actuators. The Industrial Internet of Things is transforming from a traditional factory model to a new manufacturing mode, which allows cross-domain data-sharing among multiple system departments to enable smart manufacturing. A complete industrial product comes from the combined efforts of many different departments. Therefore, secure and reliable cross-domain access control has become the key to ensuring the security of cross-domain communication and resource-sharing. Traditional centralized access control schemes are prone to single-point failure problems. Recently, many researchers have integrated blockchain technology into access control models. However, most blockchain-based approaches use a single-chain structure, which has weak data management capability and scalability, while ensuring system security, and low access control efficiency, making it difficult to meet the needs of multi-domain cooperation in IIoT scenarios. Therefore, this paper proposes a decentralized cross-domain access model based on a master–slave chain with high scalability. Moreover, the model ensures the security and reliability of the master chain through a reputation-based node selection mechanism. Access control efficiency is improved by a grouping strategy retrieval method in the access control process. The experimental benchmarks of the proposed scheme use various performance metrics to highlight its applicability in the IIoT environment. The results show an 82% improvement in the throughput for the master–slave chain structure over the single-chain structure. There is also an improvement in the throughput and latency compared to the results of other studies.

1. Introduction

The Industrial Internet of Things (IIoT) is an emerging Internet of Things (IoT) technology that provides a technical means for industrial production [1]. As IoT technology has evolved in recent years, its functional aspects, ranging from manufacturing and commerce to healthcare and retail, have become important and are gradually impacting our lives [2]. The same Industrial IoT is an important part of the IoT, and it enables real-time, reliable connections among various industrial devices, allowing them to work together, and thereby improving the efficiency and safety of industrial production [3].

In traditional industrial manufacturing, a group of IIoT devices works together under the control of a server to form an IIoT domain. All devices in the IIoT domain work together to complete the production process, thus reducing resource consumption, increasing productivity, and lowering management costs [4]. However, with manufacturing becoming more complex, it is difficult for separate domains to produce a complete product. A complete product requires multiple domains to work together to manufacture products [5]. In this context, the secure and reliable access control of devices located in different domains is becoming increasingly important.

However, IIoT domains do not necessarily trust each other because one domain is usually reluctant to allow other domains access to its resources. This can result in IIoT devices in different domains not being able to access each other conveniently and share resources securely [6,7]. The secure and reliable cross-domain access control for IIoT devices has become a hot research topic nowadays.

A range of access control techniques has emerged [8] that allows for legitimate access control among different IIoT devices to prevent unauthorized and illegal access. In a traditional access control system, all access control needs to rely on a third-party server. When the third-party server is attacked or goes down, the entire access control system goes down. Since blockchain has some listed advantages, such as decentralization, security, and reliability, many scholars have incorporated blockchain technology into access control systems. Role-based access control techniques were used in [9], in which the system set different roles and assigned appropriate permissions to the roles. However, role-based access control is difficult to achieve fine-grained access control. The attribute-based access control [10] approach provides a good solution for fine-grained access by binding control policies and node attributes together. Only devices whose attribute sets satisfy the policy can access resources. However, as the complexity of industrial manufacturing grows, the policies for accessing resources have become more complex. The time required to match device attributes to resource policies is taking longer and longer. This eventually leads to higher system latency.

In the process of cross-domain access control, cross-domain access is not possible due to the lack of trust among different domains. Therefore, a reliable cross-domain access platform has become especially important. Blockchain has a range of built-in features, such as tamper-proof, decentralized, and traceable data, which can build trust in an untrustworthy environment [11]. Blockchain is increasingly used in many IIoT scenarios to address the access control problem [12]. However, many current scholars have found that single-chain structure has problems such as weak data management capability and poor scalability. Therefore, it is difficult to meet the demand for multi-domain cooperation in the IIoT environment. In addition, the process of cross-domain access has a large number of query operations and multiple types of data processing. In this case, the shortage of the chain data structure itself results in the low efficiency of access. All these problems lead to reducing the efficiency of access.

To solve these problems, the authors of this paper designed a master–slave multi-chain structure and propose a trusted cross-domain access control model with high scalability. The main contributions of this paper are as follows:

• The authors of this research paper designed a master–slave chain based on a cross-domain access control model for Industrial IoT that has high scalability by extending the slave chains;
• A reputation-based master chain node-selecting mechanism is proposed, which selects safe and reliable nodes as the master chain nodes by evaluating their reputation values. Therefore, the security and reliability of the master chain are ensured;
• A grouping strategy retrieval method based on the combination of attributes and roles is proposed to improve the matching speed of attributes and strategies;
• The authors designed a detailed process for intra-domain access control and cross-domain access control based on a master–slave chain.

The rest of this article is organized as follows: Section 2 provides some work related to this article. The Section 3 introduces the system architecture and access control model. Section 4 will conduct a security analysis of the system in this article, and Section 5 validates the approach through experiments. Finally, Section 6 gives the conclusions and outlook of this article.

2. Related Work

This section describes the work on blockchain-based cross-domain access control. It is divided into blockchain technology and access control. A summary of the related work is presented in

Table 1. A summary of the existing work.

Reference	Environment	Architecture	Cross-Domain	Access Control	Scalability
Wu et al. [13]	IoT	Centralized	No	Yes	No
Xuan et al. [14]	IIoT	Centralized	No	Yes	No
Li et al. [15]	IoT	Single-chain	Yes	Yes	No
Ren et al. [16]	IIoT	Single-chain	Yes	Yes	No
Zhang et al. [17]	IoT	Single-chain	No	Smart contract-based	No
Feng et al. [18]	IIoT	Single-chain	No	Role-based	No
Shi et al. [19]	IIoT	Single-chain	No	Attribute-based	No
Zhang et al. [20]	Smart Cities	Single-chain	No	Attribute-based	No
Miao et al. [21]	IoT	Master–slave chain	Yes	Attribute-based	Yes

.

2.1. Blockchain Technology

Traditional cross-domain access models [13,14] usually use centralized systems. Authentication and access to all devices need to go through a centralized server. However, this centralized scheme causes a single point of failure and raises issues regarding the availability of the device.

Blockchain, a decentralized and distributed technology, offers a new solution for IoT sharing across domains. Individual local IIoT devices form relatively independent trust domains in a distributed environment, making it easy to meet local needs. However, it is difficult for a single trust domain to meet the needs of industrial products; instead, multiple domains need to collaborate. To address this issue, Li et al. [15] proposed a blockchain-based cross-domain access control framework for IoT. However, it was not modeled or validated. Ren et al. [16] combined blockchain and edge computing concepts and proposed a cross-domain trust model based on the Consortium chain, which reduces the traditional cross-domain access process. With the increase in IIoT devices and domains, there are higher requirements for system scalability, computing power, and storage capacity. Miao et al. [21] proposed a cross-domain access control approach based on a master–slave chain. However, this study did not address the reliability of the master chain nodes to ensure the security and reliability of the master chains.

The above models have made some contributions to the reliability of blockchain technology. However, most of the literature is not focused on the scalability of the system in access control systems. Therefore, this paper proposes a master–slave chain structure and demonstrates the system’s scalability by continuously adding slave chains. In this study, the master chain nodes were selected by evaluating the reputation, thus providing security and reusability of the master chain. Therefore, the security and reliability of the whole system are also ensured.

2.2. Access Control Methods

In the field of IIoT, with more data being generated by IIoT devices, access control has become increasingly frequent and important. Therefore, Zhang et al. [17] proposed a secure and reliable access control framework based on the maintenance of an access control list via smart contracts. With this framework, each time access control is performed, a new smart contract will be created. With the dramatic increase in the number of accesses, it requires a greater cost to deploy smart contracts and higher requirements for system storage. Feng et al. [18] proposed a role-based access control approach, where each device only needs to maintain its access control list. Access control lists record the resources that devices can access. However, when the number of resources increases, the access control list becomes complex and challenging to maintain. Shi et al. [19] proposed an attribute-based access control (ABAC) scheme in which the Uniform Resource Locator (URL) link of the ABAC strategy is stored on the blockchain, and a smart contract is deployed to receive access requests from the subject and then perform access control. However, the program does not provide a method of implementation. Zhang et al. [20] improved on this basis and proposed a framework based on smart contracts. This framework consists of multiple access control contracts, including a registration contract and a judgment contract, and is used to implement distributed access control for IoT systems, with the Ethernet platform being used as a case study to demonstrate its application. As more and more attributes are added, the strategies for accessing resources become increasingly complex, leading to longer periods of time to match attributes with strategies. This, in turn, increases the latency of the system and reduces its stability.

In summary, access control for the IIoT domain still needs to be enhanced regarding access control efficiency and dynamic fine-grained retrieval. Therefore, this paper proposes a combined attribute and role access control approach and presents a grouping strategy retrieval algorithm to shorten the retrieval strategy time.

3. Distributed Access Control Model Based on a Master–Slave Chain

3.1. Distributed Security Architecture Based on Master–Slave Chain

The master–slave chain-based access control system is designed with a three-layer distributed security architecture, as depicted in Figure 1. The upper layer is the master chain network, serving as the trusted platform for each domain. The middle layer comprises the slave chain network, acting as a reliable access platform within the domain. The lower layer consists of IIoT devices, which provide the function of collecting and accessing resources. The three layers of the architecture work together to accomplish intra-domain and cross-domain access control.

The dynamic selection mechanism of master chain nodes based on their reputation can ensure the security and reliability of the master chain more effectively. It does so by periodically selecting the node with the highest reputation among all the edge nodes in each domain to become the master chain node. Generally, more honest consensus nodes will have a better chance to become the main chain node to ensure the reliability of the master chain node. The details of the mechanism are discussed in Section 3.2. The slave chain is a reliable access platform within the domain, which records its resources’ intra-domain access control processes and access control strategy. The edge nodes within the domain maintain it. Each domain is then composed of edge nodes and IIoT devices within the domain. The Identity Management Server (IMS) IMS provides intra-domain certificate management and issuance, role, attribute, and resource strategy database maintenance. The resource strategy database stores the access control strategies for all resources in the domain. The blockchain can call the access strategy of resources through the resource strategy database to complete the process of matching attributes and help in access control.

Intra-domain access control is the access control among different devices within the same domain. It is divided into three main steps:

• The device sends an intra-domain access request to the edge device;
• After the edge device receives the request, it first checks the identity and then calls the access control smart contract to complete the matching process of attributes and strategies, and finally returns the access token;
• The device completes the access control of resources through the access token.

Cross-domain access control refers to access control among the devices of different domains. It is divided into five main steps:

• The device sends a cross-domain access control request to the edge device;
• After receiving the request, the edge device first performs an identity check on the device and then sends the cross-domain access control request to the master chain node;
• After receiving the request, the master chain node calls the cross-domain access smart contract to first check the node role information, then matches the attributes with the strategy, and finally, generates the access token;
• After the master chain node generates the access token, it sends it to the device through the edge node;
• The device completes the cross-domain access control process through the access token.

3.2. Dynamic Selection Strategy of Master Chain Nodes Based on Reputation Mechanism

In this system, the master chain is composed and maintained by master chain nodes, and both the master chain and slave chain utilize Byzantine consensus (PBFT). In order to prevent the master chain nodes from accidents in the process of cross-domain access control and ensure the security and reliability of cross-domain access control, reliable and honest nodes were selected to become master chain nodes. Therefore, this paper proposes a dynamic selection mechanism of master chain nodes based on a reputation mechanism. The reputation value of a node is affected by many factors of the node and affects the final reputation value [22]. Specifically, different domains periodically select the 10% of edge nodes with the highest reputation value as master chain nodes. All notations in the text will be presented in

Table 2. A summary of the notations.

Notation	Description
$E{n}_i$	Edge node
$D_j^X$	Device $j$ in domain $X$
$Mc{N}_k$	Master chain node
$Do{m}_X$	Domain $X$
$P{K}_i$	Public key of device $i$ or node $i$
$S{K}_i$	Private key of device $i$ or node $i$
$S{C}_i$	Number of historical honest consensus behaviors of $E{n}_i$
$A{C}_i$	Total number of historical consensus behaviors of $E{n}_i$
$M{C}_i$	Number of consensus times of malicious behavior of $E{n}_i$
$OnlineT$	Online hours of $E{n}_i$
$Total{T}_i$	Total time of $E{n}_i$ joining the network
$R_i^j$	Reputation value of $E{n}_i$ in the $bloc{k}_i$
$H_1$	Hash function
$IMS$	Identity management server
$S{C}_A$	Slave chain of domain $A$
IDSC	Intra-domain access control smart contract
CDSC	Cross-domain access control smart contract

.

3.2.1. Reputation Mechanism Process

The reputation values of edge nodes are impacted by their behavior during the selection process of master chain nodes. Moreover, the slave chains will also record the behavior of the nodes and finally affect the final reputation value of the nodes. The block structure of the slave chains is shown in Figure 2. Edge nodes exhibiting good behavior tend to have higher reputation values. Consequently, edge nodes with high reputation values have a greater probability of becoming master chain nodes.

During the reputation-based selection process of master chain nodes, the behavior of edge nodes will be recorded when they participate in the consensus process of the slave chain. Subsequently, the blockchain will evaluate the node’s reputation value through the reputation calculation model based on each edge node’s behavior before the consensus’s end. The reputation calculation model will be further elaborated in the following section. Ultimately, the 10% of edge nodes with the highest reputation will be selected as the master chain nodes.

3.2.2. Reputation Calculation Model

All edge nodes in the slave chain maintain a node behavior record table. This table records the edge node’s reputation value and the reference factors for determining the node’s reputation value. Each edge node caches the behavior record table of all edge nodes, including itself, and the table is updated before each consensus completion.

Next, we discuss the specific calculation rules of the reputation model and calculate the edge node reputation value using the following equations.

We evaluate the degree of honesty of a node by its historically honest consensus behavior $HC{B}_i$. If the node behaves honestly, it has a high degree of honesty and is likely to maintain good honest behavior. Conversely, if a node has a lot of malicious behavior, its historical consensus behavior will be low. The historical consensus behavior of a node is evaluated by assessing the ratio of the number of honest consensus behaviors to the number of historical consensus behaviors for that node. The historical consensus numbers refer to that node’s total number of consensus numbers since it joined the network. The evaluation formula is as follows:

$$HC{B}_i=\frac{S{C}_i}{A{C}_i}$$

(1)

where $S{C}_i$ represents the number of historical honest consensus behaviors of the edge node $E{n}_i$, and $A{C}_i$ represents the number of historical consensus behaviors of $E{n}_i$.

When an edge node sends an error message, other edge nodes can report it when they verify the digital signature, and they send their malicious behavior and data to other edge nodes for inspection. The measure of maliciousness in this reputation model is the number of times that a node acts maliciously. If a node commits malicious behavior, its reputation value will grow slowly, even if it later performs honest behaviors. With this penalty mechanism, nodes are prevented from carrying out malicious behaviors in order to make the main chain system more secure and reliable. The malicious behavior $MC{B}_i$ is calculated by the following formula.

$$MC{B}_i=M{C}_i$$

(2)

where $M{C}_i$ represents the number of consensus behaviors for the malicious behavior of $E{n}_i$.

The historical activity $H{A}_i$ of $E{n}_i$ is used to measure the activity of the node. In the process, edge nodes need to actively complete consensus to achieve high efficiency. If the edge node does not complete the consensus within the specified time, the node may have network latency, downtime, etc., and it is likely to suffer attacks if it is offline for a long time or it has a bad network. Thus, $H{A}_i$ is derived from the ratio of the node’s online time $Online{T}_i$ and the total time $Total{T}_i$ from it joining the network to the current time. The node itself is not a malicious node because of the node’s environment or its own problems. The node does not need to be punished; the probability of the node becoming a master chain node only needs to be reduced. Therefore, the historical consensus participation of $E{n}_i$ can be expressed as:

$$H{A}_i=\frac{Online{T}_i}{Total{T}_i}$$

(3)

The credibility $N{C}_i$ of an edge node is related to the honesty achieved by that node. When an edge node joins the network, its credibility is relatively low, but when the node has reached many consensuses, its reputation will become high. This parameter is used to prevent nodes that are joining the network from increasing their reputation value too quickly, maintaining system stability.

$$N{C}_i=\frac{1}{1+e^{-S{C}_i}}$$

(4)

In this study, we calculated the reputation value of a node in a cross-domain access control system, based on the above reputation assessment factors. The reputation value evaluation model of $E{n}_i$ is:

$$R_i^j=\alpha \ast \frac{1}{1+e^{-N{C}_i\ast (HC{B}_i+H{A}_i)+MC{B}_i}}+{\beta }^{MC{B}_i+1}\ast R_i^{j-1}$$

(5)

where $\alpha$ and $\beta$ represent the balance parameters of the historical reputation value and the impact of the current consensus behavior on the final reputation value, where $\alpha +\beta =1$.

According to the calculation model established above, we obtained a list of evaluation values from the edge nodes in the chain and selected the top 10% of edge nodes in each slave chain to build the master chain nodes. The system sets a period, and after each period, the system selects the master chain node from the node behavior list.

3.3. Cross-Domain Access Control Model

3.3.1. Access Control Based on Combination of Roles and Attribute

The access control process is divided into three phases: identity registration, access request, and access control. In this study, the access request needed to be recognized and processed by the smart contract before access control. Therefore, before the access request control process started, the corresponding smart contracts needed to be deployed in the master–slave chain model.

Intra-domain access control smart contract (IDSC): The intra-domain access control smart contract is deployed on the slave chain and is responsible for intra-domain access control. When an access request is received, the IDSC passes to call a resource strategy from the resource strategy database. Then the IDSC performs its matching Algorithm 1. If the match is successful, an access token is generated. If the match fails, an error result is returned.

Algorithm 1: Intra-Domain Access Control

Input: Access requests $Ar$ Resource strategy Database RSD Output: Access token $Token$

1. $AttrSet=Ar.Cd.Attrs;$

2. $StrSet=RSD.API.GetStr(Ar.Dt);$

3. $Successful\_Math=match(AttrSet,StrSet)$

4. $if(Successful\_Match==true)$

5.  $return$ $Token;$

6. $elseif(Successful\_Match==false)$

7.  $return$ $flase$

8. $Endif$

Smart contracts that need to be deployed in the master chain:

Cross-domain access control smart contract (CDSC): The cross-domain access control smart contract is deployed on the master chain and is responsible for cross-domain access control. When an access request is received, the CDSC first performs a role check, followed by calling a resource strategy from the resource strategy database. Then the CDSC performs its matching Algorithm 2. If the match is successful, an access token is generated. If the match fails, an error result is returned.

With the above smart contracts, IIoT devices can then perform reliable and effective intra-domain access control and cross-domain access control. Due to the diversity of IIoT devices, different domains exist in different IIoT environments, so this paper proposes a cross-domain access control model based on a combination of roles and attributes. Each domain has a role identity, and all devices under that domain inherit the domain identity role. The entire access control process is divided into three main parts: device identity registration, access request, and access control. In the identity registration phase, the device needs to send registration information to IMS, including its device ID, attribute information, role information, etc. Following this, an access request is sent to the edge node, which then judges the access request. If it is an intra-domain access request, the access control smart contract is called to determine the result. If the request is cross-domain, the access request information is sent to the master chain node, which then communicates with the master chain node of the target domain to determine the access request result. Finally, the device is granted access to the target resource. More details about access control are described in Section 3.4.

Algorithm 2: Cross-Domain Access Control

Input: Access requests $Ar$ Resource strategy Database RSD Output: Access token $Token$

1. $if(CheckRole(Ar.C{d}_i.RoId));$

2.  $AttrSet=Ar.Cd.Attrs;$

3.  $StrSet=RSD.API.GetStr(Ar.Dt);$

4.  $Successful\_Math=match(AttrSet,StrSet)$

5.  $if(Successful\_Match==true)$

6.   $return$ $Token;$

7.  $elseif(Successful\_Match==false)$

8.   $return$ $flase$

9.  $Endif$

10. $else$

11.  $return$ $false$

12. $Endif$

3.3.2. Grouping Strategy Retrieval Algorithm

In the process of attribute-based access control, the resource policy becomes more and more complex with more and more devices with properties. Currently, in the access control process of devices, many scholars compare attributes with policies one by one, so the matching of attributes and resources takes a long time, which greatly increases the delay of access requests. In order to improve the retrieval efficiency of retrieval strategies, the authors of this paper designed a binary encoding of strategies and constructed a grouped strategy retrieval algorithm. The strategy set was organized into a strategy tree. The process of attribute and strategy matching was also changed from the previous one-by-one matching of attributes and strategies in the strategy set so that only traversal access to the strategy tree is required. By accessing the attribute strategy tree, a large number of irrelevant strategies can be filtered out in the attribute matching process, thus reducing the time for strategy retrieval. The rules for constructing the strategy tree are as follows.

The number of all attributes in a strategy is taken as the total number of bits N of the binary code, each taking 0 or 1, where 0 means that the attribute is not included and 1 means that the attribute is included. Thus, all strategies in the strategy set of each resource can be represented in the form of a binary code, the code is used as a group number, and the strategies with the same code are combined into a group. The strategy set is grouped as shown in Figure 3, and the root node represents all the strategy information in the strategy set. In addition, all strategy sets are grouped by R1 to Rn. There are several sets of strategies in each grouping R. The rules for grouping the strategy sets are as follows: If a strategy in the strategy set of the root node does not contain the first attribute, it is temporarily merged into the group number 011…111, and if it does not contain the last attribute, it is temporarily merged into the group 111…110, and so on. The final binary code of the strategy group is determined as the group number. The complexity of the strategy tree is determined by the number of strategies, which can be divided into most $2^N-1$ groups.

3.4. Design of Access Control Processes

3.4.1. Initialization

$IMS$ in the slave chain network grants and verifies certificates for all devices in the domain. $IMS$ sets the slave chain system parameters $\left\{G_1,q,G,H_1\right\}$, where $G_1$ represents the elliptic curve cyclic group, q represents the cyclic order, and G represents the recurrent group generator. $H_1$ stands for the hash function.

Based on elliptic curve encryption (ECC), $IMS$ generates its key pair $(S{K}_{MSP},P{K}_{MSP})$ and broadcasts the $P{K}_{MSP}$ to all nodes and devices in the slave chain so that the other nodes and devices can send encrypted messages to it.

3.4.2. Identity Registration

For effective access control, the domain devices must first register their identities. For example, the specific process for authentication of device $D_1^A$ in $do{m}_A$ is as follows:

Step 1: $D_1^A$ generates a public–private key pair $(P{K}_{Ai,1},S{K}_{Ai,1})$ and then sends a registration request $req$ to $IMS$. With this request, $D_1^A$ completes the request phase of identity registration.

$$\begin{array}{l}IMS\leftarrow D_1^A:\\ req=En{c}_{MSP}(P{K}_{A,1},t,I{D}_{A,1},si{g}_{A,1}\left(\begin{array}{c}P{K}_{A,1},t\\ I{D}_{A,1}\end{array}\right))\end{array}$$

(6)

where $t$ denotes the timestamp of the message $req$, and $I{D}_{A,1}$ denotes the $ID$ of the device $D_1^A$. $si{g}_{A,1}$ denotes the digital signature of $D_1^A$. $En{c}_{MSP}$ denotes the elliptic curve encryption for encryption with the public key of $IMS$.

Step 2: $IMS$ receives a registration request $req$ from the device and needs to further verify the message reliability to ensure the trustworthiness of the $D_1^A$ identity through authentication. The formula is as follows:

$$\left\{\begin{array}{c}(P{K}_{A,1},t,I{D}_{A1},si{g}_{A,1}\left(\begin{array}{c}P{K}_{A,1},t\\ I{D}_{A,1}\end{array}\right))=De{c}_{IMS}(req)\\ \begin{array}{l}h=H(P{K}_{A,1},t,I{D}_{A,1})\\ h^{\prime }=De{c}_{A,1}(si{g}_{A,1})\end{array}\end{array}\right.$$

(7)

Step 3: $IMS$ first decrypts req using its own private key to obtain $(P{K}_{Ai,1},t,I{D}_{A1},si{g}_{Ai,1})$, and then it calculates $h$. Then it decrypts the signature $si{g}_{Ai,1}$ using the public key of $D_1^A$ to obtain $h^{\prime }$, and finally it determines whether $h$ and $h^{\prime }$ are equal. If they are equal, the authentication passes.

Step 4: After the authentication is passed, $IMS$ generates the certificate of identity $D{C}_{A1}$ as follows. With this certificate, $D_1^A$ can then perform effective cross-domain or intra-domain access control.

$$\begin{array}{l}IMS\to D_1^A:\\ D{C}_{A,1}=(P{K}_{A,1},t,I{D}_{A,1},Attr{s}_{A1},si{g}_{IMS}\left(\begin{array}{c}P{K}_{A,1},t,I{D}_{A,1}\\ Attr{s}_{A,1},RoId\end{array}\right))\end{array}$$

(8)

where $si{g}_{IMS}$ denotes the digital signature encrypted by the private key of the identity management server. $Attr{s}_{A,1}$ denotes the set of attributes of $D_1^A$; $RoId$ denotes the role identity of $D_1^A$.

The identity management server stores the generated identity certificate $D{C}_{A1}$ for authentication before access control is performed.

3.4.3. Intra-Domain Access Control

Intra-domain access refers to access control among different devices under the same domain where the access behavior occurs. Let domain A be located to send access requests from $D_1^A$ to $D_4^A$ in chain $SCA$.

Step 1: $D_1^A$ sends an $Ar$ request to edge node $E{n}_{A2}$. The $Ar$ request represents $D_1^A$ sending a resource access request to $D_4^A$. The request contains all the access information to make it complete the access request process.

$$\begin{array}{l}{D}_1^A\to E{n}_{A2}:\\ \{P{K}_{A,1},tim{e}_1,si{g}_{A,1}\left(Ar\left(\begin{array}{c}D{C}_{A,1}\\ Ac(type,R{e}_{A,4})\end{array}\right)\right)\}\end{array}$$

(9)

where $tim{e}_1$ denotes sending an access request timestamp, $Ar$ denotes the access request content, $D{C}_{A,1}$ denotes the access certificate of $D_1^A$, $Ac$ denotes the access content, $type$ determines whether the access is intra-domain or cross-domain, and $R{e}_{A,4}$ denotes the resource of $D_1^A$.

Step 2: $E{n}_{A3}$ receives the $Ar$ request for parsing, confirms that it is currently intra-domain access control, and then authenticates it through $IMS$.

(a) If the $D{C}_{A,1}$ is valid and legitimate, the authentication result is recorded, and the status information of $D_1^A$ is modified. It also indicates the legitimacy of the $D_1^A$ status.

$$\begin{array}{l}E{n}_{A3}\leftarrow \\ \{tim{e}_2,si{g}_{IMS}\left(A{r}^{\prime }\left(\begin{array}{c}D{C}_{A,1}\\ Ac(type,R{e}_{A,4})\end{array}\right),Legal\right)\}\end{array}$$

(10)

(b) If the $D{C}_{A,1}$ is invalid, then $E{n}_{A3}$ returns a deny message to $D_1^A$, indicating that $D_1^A$ is an illegitimate device, and access is terminated.

$$\begin{array}{l}{D}_1^A\leftarrow E{n}_{A3}\\ \{tim{e}_2,si{g}_{IMS}\left(A{r}^{\prime }\left(\begin{array}{c}D{C}_{A,1}\\ Ac(type,R{e}_{A,4})\end{array}\right),Illegal\right)\}\end{array}$$

(11)

Step 3: After passing the authentication, $E{n}_{A3}$ calls the strategy tree of the data strategy database through through the IDSC for matching with the strategy using Algorithm 1.

(a) If the attribute matches the resource strategy, the access token $Token$ is generated and then sent to the $D_1^A$ through $E{n}_{A2}$. This also means that $D_1^A$ will have access to the resources. Then $D_1^A$ can perform access control, as follows:

$$\begin{array}{l}{D}_1^A\leftarrow E{n}_{A3}:\\ Token=\left\{\begin{array}{c}Si{g}_{SCA}\left(\begin{array}{c}A{r}^{″}\left(\begin{array}{c}D{C}_{A,1}\\ Ac(type,R{e}_{A,4})\end{array}\right)\\ Legal\end{array}\right)\\ Deadline,tim{e}_3\end{array}\right\}\end{array}$$

(12)

where the $Deadline$ represents the access deadline of $Token$. $D_1^A$ can only have access control within the valid time.

(b) If the attributes do not match, a match failure message is sent to $D_1^A$ through $E{n}_{A2}$. Eventually, the result of this failure will also be stored in the blockchain.

$$\begin{array}{l}{D}_1^A\leftarrow E{n}_{A3}:\\ \left\{\begin{array}{c}Si{g}_{SCA}\left(\begin{array}{c}A{r}^{″}\left(\begin{array}{c}D{C}_{A,1}\\ Ac(type,R{e}_{A,4})\end{array}\right)\\ Legal\end{array}\right)\\ failed\end{array}\right\}\end{array}$$

(13)

Step 4: $D_1^A$ completes the access control of the resource in the domain for $D_4^A$.

The intra-domain access control process is shown in Figure 4.

3.4.4. Cross-Domain Access

Cross-domain access is access control that occurs among devices under different domains, as shown in Figure 5. The access control behavior occurs between $D_5^A$ in the slave chain $SCA$ where $Do{m}_A$ is located and $D_1^B$ in the slave chain $SCB$ where $Do{m}_B$ is located.

Step 1: $D_5^A$ in $SCA$ sends a cross-domain access request to $E{n}_{A2}$.

$$\begin{array}{l}{D}_5^A\to E{n}_{A2}:\\ \{P{K}_{A5},tim{e}_4,si{g}_{A,5}\left(Ar\left(\begin{array}{c}D{C}_{A,5}\\ Ac(type,R{e}_{B,1})\end{array}\right)\right)\}\end{array}$$

(14)

Step 2: After receiving the request, $E{n}_{A2}$ first authenticates the identity of $D_5^A$ through $IMS$ and confirms that the access control type is cross-domain access control.

a. If the authentication passes, the request is identified as a cross-domain access request and sent to $Mc{N}_A$ of $SCA$.

$$\begin{array}{l}E{n}_{A2}\to Mc{N}_A:\\ \{tim{e}_5,si{g}_{A2}\left(\begin{array}{c}A{r}^{\prime }\left(\begin{array}{c}D{C}_{A,5}\\ Ac\left(\begin{array}{c}from,SCB\\ type,R{e}_{B,1}\end{array}\right)\end{array}\right)\\ Legal\end{array}\right)\}\end{array}$$

(15)

where $from$ indicates the domain from which the request comes, and $SCB$ indicates the domain where the resource is located.

b. If the verification does not pass, it means that the $D_5^A$ is not entitled to access, a deny message is returned, and the cross-domain access ends.

$$\begin{array}{l}E{n}_{A2}\to D_5^A:\\ \{tim{e}_6,si{g}_{A2}\left(\begin{array}{c}A{r}^{\prime }\left(\begin{array}{c}D{C}_{A,5}\\ Ac(type,R{e}_{B,1})\end{array}\right),\\ Illegal\end{array}\right)\}\end{array}$$

(16)

Step 3: After $Mc{N}_A$ receives a cross-domain access request, it first calls the CDSC, then the smart contract checks the identity and then matches the attributes with the strategy using Algorithm 2.

(a) If the verification is successful, $Token$ is generated and $Token$ is sent to $D_5^A$ through $E{n}_{A2}$ in $Do{m}_A$.

$$\begin{array}{l}Mc{N}_B\to E{n}_{B2}:\\ Token=si{g}_{SCB}\left\{\begin{array}{c}A{r}^{″}\left(\begin{array}{c}D{C}_{A,5}\\ Ac\left(\begin{array}{c}from,SCB\\ type,R{e}_{B,1}\end{array}\right)\end{array}\right),\\ \begin{array}{l}Legal,\\ \mathrm{State}:ture,tim{e}_8,Deadline\end{array}\end{array}\right\}\end{array}$$

(17)

(b) If authentication fails, the node does not have access to the resource. The results are returned to $D_5^A$.

$$\begin{array}{l}E{n}_{B2}\to U_{A5}:\\ si{g}_{SCB}\left\{\begin{array}{c}A{r}^{″}\left(\begin{array}{c}D{C}_{A,5}\\ Ac\left(\begin{array}{c}from,SCB\\ type,R{e}_{B,1}\end{array}\right)\end{array}\right),\\ \begin{array}{l}Legal,\\ \mathrm{State}:false\end{array}\end{array}\right\}\end{array}$$

(18)

Step 4: After $D_5^A$ obtains $Token$, it gains control access to the resources of $D_1^B$.

4. Security Analysis

In this section, we present a security analysis of the system.

4.1. Security and Privacy Concerns

Privacy protection: In this system, the basic information of the IMS resources is stored in the blockchain, and there is no way to cause information leakage if there is no access to the resources. The basic information of the nodes receives the protection of the IMS, and when interacting with the IMS, they need to encrypt and sign messages. If it is not the node itself, there is no way to steal the node information without the node’s private key.

Resisting masquerade attacks: Masquerade attacks are performed by malicious j-nodes to gain unauthorized access to the system by stealing passwords and login names, finding vulnerabilities in the program, etc. Our scheme is resistant to masquerade attacks because each device is required to sign messages when communicating with the b edge, and an attacker cannot have the private key of the device and, therefore, cannot continue an effective masquerade attack.

Resist replay attack: An attacker may intercept the access request sent by the user and replay the access request for the purpose of invalid access. In the proposed model, since each request is signed, the attacker cannot send multiple identical requests, and when the edge node receives a valid message, the rest of the messages are blocked.

4.2. No Falsification of Certificates

An attacker needs to obtain the $SK$ of a legitimate node in order to forge a legitimate node. Moreover, cryptography-based ECC is an elliptic curve discrete logarithm-based problem (ECDLP). In this model, the difficulty of solving this problem is sought as a system security guarantee. With known $PK$ and $Q$ values, the degree of difficulty of the process of reverse-seeking $SK$ is an ECDLP. The text attempts to solve ECDLPs by the exhaustive search method, verifying that reverse-seeking $SK$ is almost impossible to succeed.

It is known that $Q=q$ and $P=PK$, and the order of P is N. $SK$ is found when L satisfies $Q=LP$, where L satisfies ($0\le L\le N-1$). If the ECDLP holds, then the method does not hold.

Proof. 

Compute the sequence of points $P,2P,3P......,nP$ of $E\in (Fp)$ until $nP=Q$, then $n=L$. Consider the worst case where N steps need to be computed to find the answer satisfying $nP=Q$, and on average, N/2 steps are needed to solve the ECDLP. Therefore, the time complexity of this computation is exponentially $O(N)$. When N is large enough, the method of this solution becomes infeasible in terms of computational time. The validity of the method cannot be guaranteed, and the ECDLP’s difficulty holds. At this point, $SK(PK,P)$ in Equation (19) is infinitesimal, and the success probability $SuccA$ of attacker A successfully forging a legitimate node is almost 0.

$$SuccA=\frac{ECDLP\{SK(PK,Q)\}}{A\{PK,Q,Enc(SK,Hash)\}}$$

(19)

□

5. Experimental Verification and Analysis

In this section, the proposed system in this paper is evaluated in terms of its node reputation value assessment, attribute and strategy matching time, transaction throughput, and time delay. The master–slave chain proposed in this paper is built on the Hyperledger fabric platform. The simulation experiments were conducted on three laptops, and the configurations are shown in

Table 3. Configurations of the three laptops.

IP	Configuration	OS
172.18.18.193	Intel(R) Core (TM) i5-10500	Windows 10
172.18.18.206	Intel(R) Core (TM) i5-9400	Windows 10
172.18.18.141	AMD Ryzen 7 4800H	Windows 10

. Each laptop was deployed with an Ubuntu 18.04 virtual machine, where the blockchain system was configured.

5.1. Figures, Tables, and Schemes

In this paper, a master–slave chain system is proposed in order to test the reliability of slave chain edge nodes through a dynamic selection strategy of master chain nodes based on a reputation mechanism. In this experiment, we simulated the change of the node reputation value by continuously maintaining honest behavior and the occurrence of illegal behavior between nodes. The reputation was calculated as shown in Equation (5), where $\alpha$, $\beta$, and $HA$ were set to 0.3, 0.7 and 0.8, respectively.

In order to study the evolution of the reputation value, we simulated the change process of the reputation value of the three edge nodes 50 times in the consensus process. Two of the nodes had illegal behaviors in the consensus. Among them, edge node 2 generated an illegal consensus between the sixth and seventh times. Edge node 3 generated illegal consensus between the 21st and 22nd times. Each of its illegal consensuses was recorded in the blockchain and finally expressed as a reputation. An honest node reaches the maximum reputation value by multiple consensuses. However, if a malicious behavior occurs in the middle, it will be recorded in the blockchain. The increase in the reputation value will be slight, reducing the possibility of the node competing as a master chain node and protecting the security and reliability of the main chain to some extent. The trust change process of the three nodes is shown in Figure 6.

When an edge node breaks down, it may also be that the bad network condition causes a delay in receiving messages and sending messages to the node, which may not receive messages or may not be able to send messages, but it does not tamper with the messages or perform other illegal actions. In this study, we reduced the reputation value of this node appropriately to reduce the possibility of this node becoming a master chain node. Equation (3) was used to determine that $HA$ indicates the historical activity of the node. In the experiment, we set the change of node reputation by setting $HA$ as 0.2, 0.40, 0.6, and 0.8, respectively. The rest of the parameters remained unchanged. The results are shown in Figure 7, from which it can be seen that the shorter the node was online, the more its reputation value was affected.

5.2. Grouping Strategy Matching Algorithm

In order to improve the matching rate of attributes and strategies, this paper proposes a grouping strategy retrieval algorithm, which avoids comparing unnecessary strategies by grouping them to improve the matching rates of strategies. In the experimental part, 25 strategies in 11 groups were randomly generated. The numbers of attributes of these 11 sets of strategies were 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, and 15. Moreover, this was repeated 20 times to take the average. The average matching times of the strategy sets with different numbers of attributes were compared and analyzed by the traditional method and the strategy grouping method. The results are shown in Figure 8.

As shown in Figure 8, the strategy matching times were relatively close in the beginning. However, with the increase in the number of attributes, the traditional strategy matching time increased rapidly. The grouping strategy matching time was better than the traditional method.

5.3. Throughput

Throughput measures the ability of a system to process requests or transactions per unit of time. Throughput is expressed in terms of the number of transactions per second calculated using Formula (20):

$$TPS=Sumtransactions/\Delta t$$

(20)

where $Sumtransactions$ is the number of transactions stored in the blockchain ledger during the time period $\Delta t$. To observe the changes in the $TPS$, the experimental design was as follows.

Two comparison groups were set up. In the first comparison group, all schemes were master–slave chain structures. We conducted six experiments separately. Each experiment created a block every 10 s. First, the scheme of this paper was compared with the schemes of all other papers. The scheme in [21] used the PBFT consensus, and the scheme in [23] used the proof of work (pow) consensus for the master–slave chain. Figure 9 shows that the average throughputs of the scheme in [21] and the scheme in [23] were 79.2 and 106.9, respectively. The throughput of the proposed scheme in this paper is the highest—1.67 and 1.24 times higher than those of the scheme in [21] and the scheme in [23], respectively.

The second comparison group was between master–slave chains and single chains. The throughput variation between master–slave and single chains was determined by sending access requests at different rates. The results are shown in Figure 10. At lower access request volumes, the difference in throughput between the master–slave and single chains was relatively tiny. However, as accesses increased, the transactions within the domain did not need to be completed through the master chain as in the master–slave chain. The master chain only needed to be responsible for cross-domain access control, making it possible for the master and slave chains to work together. Therefore, the throughput of the master–slave chain was higher than that of the single chain.

5.4. Delay

The system performance is closely related to the time delay, which is calculated as

$$Delay=t_e-t_s$$

(21)

where $t_s$ is the time when the transaction was generated, and $t_e$ is the time when the transaction is confirmed (stored on the ledger). The latency can be calculated by reading the logs of the blockchain operation. Figure 11 shows the comparison of latency between this paper and the scenarios in [23,24]. Due to the reputation selection mechanism in this paper, more reliable and stable nodes were screened to become the master chain nodes, thus ensuring the system’s stability and reducing the system’s latency. Therefore, the latency increased with the number of transactions in all scenarios. For the same number of transactions, the latency in this paper was the lowest compared to the other two scenarios.

6. Conclusions

In this study, we designed a master–slave chain structure and proposed a highly scalable and trusted cross-domain access control authentication model to solve the access control problem of resources among devices in different domains. For the master chain security problem, a reputation-based dynamic selection strategy of master-chain nodes is used. In the reputation-based master chain node selection mechanism, by evaluating the historical consensus behavior of the nodes, the consensus nodes with more honest consensus have a higher reputation, and the nodes with malicious consensus behavior are punished so that it is difficult for them to recover with a higher reputation value. Periodically, the edge node with the highest reputation in each domain is selected as the master chain node. In addition, for the special environment of the IIoT domain, the paper proposes an access control method based on the combination of roles and attributes to achieve high fine-grained access control. Finally, to address the attribute strategy matching rate problem, a grouping strategy-based matching algorithm is proposed to improve the efficiency of attribute strategy matching by constructing policy groups into policy trees so that a large number of irrelevant strategies can be excluded in the matching process. The experimental results show that the master–slave chain structure improved the throughput by 82% over the single-chain structure. There was also an improvement in the throughput and latency compared to the results of other studies.

For future work, expanding the scale of experiments and optimizing the consensus algorithm of the blockchain should be considered to create a service environment with higher performance, lower latency, and higher bandwidth for the blockchain network than the existing scheme. In addition, to further improve intelligent access control, machine learning techniques can be combined to improve access control and optimize the cross-domain access control model. Finally, in real-life blockchain-based access control systems, there are diverse and heterogeneous IoT environments, which will bring many challenges to the network latency, system operation, and unified management of the access control system, which is already our future optimization target.