Research on Distributed Network Authentication and Access Control Mechanism Based on Blockchain Technology

During the operation of the network, some undesirable situations may occur, such as the stability of the operation of a link is affected by external factors, or the structure of certain nodes may change when they temporarily leave or join the network for some reason. In this case, due to some characteristics it has, it automatically repairs the network and thus maintains its availability [1]. For the network, this characteristic is an advantage to ensure its stable operation, and for the attacker, this process is also an ideal time to take an attack. For example, attackers attack the network through denial of service attacks. Therefore, a reasonable and effective authentication scheme is quite important for distributed networks [2]. For the threat of illegal access and unauthorized access, it is necessary to make the network itself have the ability of subject identification through the design of security functions, and be able to permit different operations for different subjects according to certain security policies, that is, on the one hand, authentication should be carried out when the user accesses to the network, on the other hand, permission control should be carried out when the user invokes the operation, and the two processes can be collectively referred to as access control [3]. Blockchain is a new technology application consisting of existing technologies such as smart contracts, chained storage of distributed data, etc., and its network structure consists of distributed peer-to-peer nodes, which are completely equal to each other, and the function of authentication can be uniformly distributed throughout the blockchain network [4]. The study of distributed network authentication and access control mechanism based on blockchain technology, by using the relevant knowledge in the field of cryptography security authentication and combining with some of the unique advantages of the blockchain in the premise of not relying on the centralized authentication server, to efficiently and safely solve the authentication and access control problems in the distributed network, and at the same time to ensure the feasibility and security of the authentication and access control [5–6].

In this paper, based on blockchain technology, we design an identity authentication system for distributed networks and improve the traditional KP-ABE access control scheme to successfully design a collaborative fine-grained access control scheme based on blockchain. The scheme replaces the identity management and authentication center in the traditional KP-ABE scheme with the blockchain-based decentralized self-sovereign identity management, and combines with the decentralized secret sharing technology to realize the collaborative KP-ABE scheme with multiple administrators. Meanwhile, this paper simulates and tests the scheme from three aspects, namely access control delay, access judgment performance, and protocol performance, respectively, to verify its effectiveness.

2

Overview

Under the development of economy and science and technology, the network appears in people’s life, it puts forward high requirements for the security of various information, therefore, how to solve for the network information security, it becomes a very important topic at this stage. Literature [7] proposed a role-based access control model by combining blockchain-based smart contract and threat and security model, and proved the scientific and applicability of the proposed method on Ropsten Ethereum test network, which can effectively cope with user authentication and authorization challenges. Literature [8] proposed a new access control scheme for IoT system based on blockchain technology record attributes in order to reduce the security risk of IoT system and ensure the security of data, and verified that the proposed scheme can be efficiently implemented in IoT system through security and performance analysis. Literature [9] proposes a blockchain-based data sharing and access control system that can be used for communication between IoT devices, and the superior performance of the proposed system is verified through experiments, and the proposed system is more efficient in terms of cost and overcomes the problems associated with trust and authentication for access control in IoT networks compared to existing systems. Literature [10] proposed a blockchain based distributed Attribute Based Access Control (ABAC) system for securing computer systems, and used independent digital libraries as an application case to validate the feasibility and validity of the proposed system, which can improve the trustworthy auditing of computer systems. Literature [11] combines Ethernet blockchain and attribute-based cryptography to design a will decentralized storage system interstellar file system, and verifies the feasibility of the involved system through simulation experiments, which not only solves the problem of data privacy and fine-grained access control, but also deals with the serious problems such as key misuse and privacy data leakage. Literature [12] points out the ongoing challenges of access control in the current IoT and proposes a novel privacy-preserving access control model based on blockchain technology, which implements current access control standards and protects user privacy rights. Literature [13] presents and discusses the details and applicability of centralized and distributed access control schemes in blockchain systems under the IoT ecosystem and the use of blockchain-based user authentication with smart contracts in centralized access control to improve the security and privacy of IoT networks.

Meanwhile, literature [14] proposes a blockchain-based access control management strategy for distributed online social networks, and evaluates the superiority of the proposed strategy using the Rinkeby Ethernet test network, which provides a real solution to the privacy problem in decentralized systems. Literature [15] pointed out the shortcomings of centralized access control mechanisms, designed a blockchain-based access control scheme for distributed IoT, and verified its practicality through experiments, which enables secure access in distributed IoT environments, and at the same time, can effectively solve the problem of data tampering and leakage. Literature [16] proposes a new blockchain-based distributed key management architecture to meet the decentralization, fine-grained auditability, high scalability and extensibility requirements as well as privacy protection principles of IoT layered access control, and the superior performance of the proposed architecture is verified through simulation tests, which can be used for layered access control in IoT scenarios. Literature [17] proposed an efficient distributed authentication and access control system management for IoT based on blockchain technology for the key issues related to the management and communication security of the Internet of Things (IoT), and its feasibility was verified by experiments, and compared to digital certificate authentication, the proposed scheme has the superior performance of low overhead and high response, which improves the overall security of the access control system for inter-device communication to a certain extent. Literature [18] designed a blockchain-based identity management and access control mechanism for Industrial Internet of Things (IoT) in order to solve the security problem of edge computing, aiming to provide data security such as authentication, auditability and confidentiality for IoT. Literature [19] proposed a distributed role-centric identity authentication and resource access management technique supporting blockchain as a starting point for creating an efficient centralized system for distributed applications, and the results of the test experiments proved that the proposed method is highly efficient in terms of access management and privilege authentication, low-cost, and able to satisfy the requirements of distributed environments. Literature [20] designed a distributed IoT authentication and key management based on blockchain technology in order to ensure the privacy of users and data, and the experimental analysis confirms that the scheme outperforms the traditional institutions, ensures the confidentiality of data in IoT scenarios, and provides a secure environment for communication.

3

Blockchain technology

3.1

Block structure

Block is the data structure in which the blockchain stores the transaction records. The header records the overall information of this block, while the body records the detailed information of each transaction within it.

Blockchain stores transaction data in the form of a Merkle tree within the block body, and stores timestamps, versions, random numbers, Merkle roots, and other information in the block header. The Merkle tree uses hashing operations in the binary tree structure to compress and tamper-proof transaction information, and to achieve the purpose of data checking and fast summarization. Timestamp is used to record the writing time of the current block, which adds a time dimension to the block data and enhances the traceability of the data. Difficulty and random numbers are used to achieve consensus among block nodes for competitive bookkeeping. The block hash is the hash value of all the data in this block, which will be used as the parent block hash of the next block. Under this mechanism, the block hash becomes the link “pointer” between blocks, realizing the chain structure of the blockchain and guaranteeing the trustworthiness of block data storage.

3.2

Encryption algorithms

Encryption algorithms are the basis for driving blockchain to have security features such as tamperproof and traceability. Various types of encryption are used in blockchain, including hash algorithms, asymmetric encryption, and so on.

Hashing algorithms can convert the plaintext of a message of any length into a fixed-length binary string output, called a hash or digest. Even if the two messages differ only by one character, after the hash operation, they produce a string that is very messy and random, and there is no correlation at all. It is because of this feature, so that the hash algorithm is widely used to detect the validity of the signature and integrity of the scene. Common hash algorithms are MD5, SHA-1 and RIPEMD-160, and SHA-1 has become the most widely used hash algorithm due to its security strength and computing efficiency advantages. Currently, blockchains usually use SHA-256, Keccak-256CSHA3 or higher security level mainstream algorithms to construct objects such as currency addresses, hash pointers, message digests, and so on.

Asymmetric encryption refers to the use of different keys for encryption and decryption, and is more secure than symmetric encryption. Currently commonly used asymmetric encryption algorithms mainly include RSA algorithm, Elgamal algorithm, and elliptic curve encryption algorithm. Blockchain digital signatures are realized based on asymmetric encryption, and most blockchain platforms currently use elliptic curve encryption algorithms to encrypt and decrypt transactions. Compared to the common RSA algorithm, elliptic curve algorithms use a more concise key and provide higher security.

3.3

Digital signatures

In blockchain, there are constantly nodes generating and sending transactions, in order to ensure the correctness of all transactions stored in the block, the blockchain must verify the content of each transaction and the identity of the submitter of the transaction, the technology is digital signature. Digital signatures are an application of asymmetric cryptographic algorithms that provide message authentication, integrity, and non-repudiation. The process of authenticating a message using digital signature is shown below: 1)

The signer and the verifier agree in advance on the hash function to be used to perform the digest calculation.

2)

The signer hashes the original message M to get the message digest D1.

3)

The signing party uses the private key to encrypt the message digest D1 to obtain the digital signature S. The signing party then sends M, D1, and D1 to the verifier.

4)

The signer sends M, D1 and S together to the verifier.

5)

The verifier receives the message, decrypts S with the public key of the signer to get the message digest D1, passes the received message into the hash function to get the message digest D2, and compares the two whether they are identical or not to identify the message.

3.4

Consensus mechanisms

In the blockchain system, due to the frequent transactions between nodes, the data in the ledger is constantly changing, how to make different nodes agree on the state of the ledger after the transaction is the problem that the consensus mechanism needs to solve.

Proof of Work (PoW) is the first consensus mechanism introduced by the Bitcoin transaction system, which is called “mining” in Bitcoin, i.e., through its own arithmetic power, it constantly calculates to find a hash value that satisfies the rules and is less than the difficulty target (the value of the first few bits all being 0). The hash value is obtained by taking the 80 bytes in the block header as proof-of-work input, trying to transform the random number Nonce in the block header, and doing two consecutive SHA-256 hash operations. Therefore, the process of “mining” is the process of finding the collision random number Nonce. Typically, the time it takes to find this random number depends on the difficulty target threshold, and the time it takes to generate a new block is controlled by controlling the difficulty target. This is how the Bitcoin transaction system controls the block generation rate to stabilize at about 10 minutes, with the agreement that the node that finds the random number Nonce the fastest competes for the right to book the transaction block and receives a certain number of Bitcoins as a reward.

The disadvantage of PoW is that it requires a significant amount of arithmetic power and is susceptible to the 51% attack problem. In addition to PoW, blockchain can also support other consensus mechanisms, the current common ones include PoS, PBFT, Raft, etc., which have their own different characteristics in terms of compliance and regulation, performance efficiency, resource consumption, and fault tolerance.

3.5

Smart Contracts

A smart contract is a set of digitally defined promises on which contract participants can execute those promises. It is a contract that uses computer language instead of legal language to record terms.

In the field of blockchain technology, a smart contract is a computer program that is triggered based on a predetermined event, is tamper-proof, and executes automatically. In Ether, smart contracts need to be written and compiled into byte code published through the Solidity language, with the Ether virtual machine running its functions. In Fabric, smart contracts are known as chain codes, which need to be written in languages such as Golang, Java, etc. and run by local blockchain nodes after being instantiated.

Through smart contracts, one can transfer business logic in various scenarios to the blockchain for execution, ensuring that the running process and results are trustworthy and secure.

3.6

Blockchain architecture

Blockchain architecture is shown in Figure 1, which can be divided into data layer, network layer, consensus layer, incentive layer, contract layer and application layer from bottom up.

The data layer includes encryption algorithms, block data, transaction information, and other content. The network layer mainly includes the network structure between blockchain nodes and the transmission protocols used such as P2P. The consensus layer contains the consensus mechanism used by the blockchain. The incentive layer includes the issuance and distribution mechanism of cryptocurrencies, and a rational mechanism is an incentive for nodes to participate in consensus, such as Bitcoin in the Bitcoin system versus Ether in Ether. The contract layer encapsulates the code, algorithms, and other logical content of the smart contract. The application layer is the specific on-chain application.

4

Blockchain-based distributed network authentication and access control

4.1

Blockchain-based distributed network authentication system

4.1.1

Overall system architecture design

In this paper, we design a distributed authentication system based on blockchain and access control based on the authentication results. The overall system architecture is shown in Fig. 2, which is divided into blockchain underlying platform, contract layer, business layer and application layer.

The blockchain underlying platform consists of CA (Certificate Authority) nodes, Peer nodes, and Order nodes that constitute the blockchain basic network. Among them, CA node is the root of the blockchain infrastructure network, responsible for maintaining and managing the rights of node members in the network, and at the same time, providing the functions of issuing, extending and revoking node digital certificates, and maintaining the distributed ledger status of other nodes in the network. Peer node is the blockchain network infrastructure that can be used to store key identity data, execute specific programs, and its can store complete data and smart contracts in the distributed ledger. Order node is responsible for the communication channel creation, configuration, and update. Transaction requests submitted by the client need to be processed through the Order node, which is arranged chronologically according to the time of the transaction, maintains the consistency of the transaction order of the entire distributed ledger, and provides services such as broadcasting, block distribution, and so on, for the blockchain network.

The smart contract layer contains a variety of smart contracts such as registration, authorization, and update contracts. Registration contract is to bind the user’s digital signature, identity information and system code to register a new account in the system. Authorization contract is the user’s part of their own information signature authorization for others to read, proof, etc. The update contract stipulates that when the user’s identity information status changes or the transaction information recorded on the blockchain changes, the system must update the transaction status and record it on the blockchain. The query contract allows the user to query and verify the status of the decentralized identity based on key information such as the feature code and system code of the decentralized identity.

The business layer is comprised of the system’s back-end services. Through the SDK, the client nodes of the system are able to communicate with the Peer nodes in the blockchain network. Client nodes enter specific business requests to invoke appropriate smart contracts. The business layer provides an interface for the front-end application to process the requests issued by the front-end and return the processing results to the front-end.

The application layer is the front-end presentation layer of the system. It provides users with interfaces for registration, checking, and authorization, and is divided into registration, adding, updating, selective disclosure, and verification modules. The modular front-end display interface provides users with an interactive operating platform.

4.1.2

DID structural design

Decentralized Identifiers (DID) is a new type of identifier designed based on the W3C framework standard [21]. The new type of digital identity can be queried and verified, and can cover many current Internet identity authentication scenarios. The content in the DID space can be determined by the digital identity holder, and DID has a stronger advantage of data sovereignty compared to traditional identity identifiers. The DID controller is able to prove the control of the digital identity without the need of other parties. DID can be designed so that the identity information provision, registration and digital certificate DID identifiers are essentially Uniform Resource Identifiers (URIs) that associate a DID subject with a DID document and bridge the interaction between the DID subject and the DID document.

The DID structure design defines two types of DIDs, account DIDs and ledger DIDs. The DID space is a collection that contains the user’s DID identity information and the content of the transactions associated with the identity. The account DID is used to identify the identity characteristic information of an individual or organization in the system, and will record the unique identifier and public key of the identity provider, as well as the authentication method and other information. The account DID records all of the user’s transaction records, including transaction additions, deletions, and updates, etc., and its recorded transactions are associated with one or more account DIDs, indicating which specific accounts are involved in executing the transaction.

The DID space also holds key user attributes such as the DID identifier UID, the user’s public key, the subject, and the time stamp for creating the DID. During the creation of the DID space, the system generates a unique identifier UID for each user based on the user’s identity information. The subject of the DID space summarizes the main content of the DID, which can state the personal name or organization name of the UID. An individual account UID represents an identity entity, while an organizational account UID represents an identity group entity. An individual user’s UID can be associated with one of the DID group entities.

The public key (PK) in the user DID space is the basis for establishing secure communication with other user endpoints, and it can be used for signing and verification. Authentication is the ability to cryptographically prove that the UID is associated with the user’s identity, and the user marks the cryptographic method he or she uses at the authentication method, such as RSA (Rivest-Shamir-A dleman) and Elliptic Curve Digital Signature Algorithm (ECDSA). The timestamp indicates the time information created by the user.

Users can manage multiple sub-identities in the account DID in addition to holding a UID. Among the elements of the account DID that record a sub-identity are the sub-identity identifier did, a public key, a digital signature, a timestamp, and an expiration time. Unlike a UID, a sub-identity DID can only represent a particular account identity of a user. Sub-identity and account identity information has a logical correlation link, it is necessary to add a parent identity identifier DID index in the subidentity, through which the DID can be queried, proving that the DID is based on the DID generated from the DID.

The book DID stores the specific transactions in the DID. The transactions therein point to one of the user’s account DIDs, indicating that the identity is involved in the transaction on behalf of the user. In addition to the specific transaction content, the transaction record in the ledger DID includes the user’s encryption key and authentication method. The encryption key and authentication method provided can be used to verify that the content recorded in the transaction is correct. The encryption key can be used for authentication or authorization in the information interaction between the user and relevant parties, and the materials to be provided also include the unique identifier UID. The transaction in the ledger DID will record the business type, so that the interacting parties can more conveniently decipher the information recorded in the DID document, including the user’s UID, the public key information, and the business type.

DID is not only used for personal identity management but also for building identity credentials. Users can create identity credentials with different topics and data content. Identity credentials are divided into credential header and credential load. The credential header stores key information about the user’s identity, such as UID, public key PK, signature Sig, creation timestamp Timestamp and credential validity time. The credential load contains specific credential content about the DID, which documents the credential subject, authentication method, type, identity identifier, public key and specifics. The interaction between identity credentials between different users is schematically shown in Fig. 3.

The system generates a globally unique identifier (UID) based on the user’s node information and personal identity characteristics on the blockchain. The DID document contains structures such as public keys, authentication, and services. The public key and validation specify the authentication methods for the data identity holder and the authority. The service meets the functional requirements of the DID and provides the user with services including registration, update, authorization, and query.

4.2

Distributed Network Access Control Scheme

In this chapter, a blockchain-based fine-grained access control scheme for distributed cloud storage is proposed to address the data security and user privacy issues faced in decentralized distributed cloud storage. The scheme consists of five parts: system initialization, data outsourcing storage, anonymous key generation, anonymous data access, and anonymous attribute revocation.

4.2.1

System initialization

1)

Initialization of BbSSIM platform

The data owner, data user, attribute authority, and cloud service provider are registered as nodes of the BbSSIM platform and configured as follows:

(1)

Generate a globally unique Verifiable Identity (VerID) and VerID related document, which includes VerID, blockchain platform public key PK_VerID, cloud service provider address CS_VerID, verifiable reputation link (VerREL_VerID) and related signature of the ID certificate owner. The VerID document can be represented as: 1 ${\begin{array}{l} V e r I D, P K_{V e r I D}, C S_{V e r I D}, V e r R E L_{V e r I D} \\ S i g n_{o w n e r} [V e r I D | | P K_{V e r I D} | | C S_{V e r I D} | | V e r R E L_{V e r I D}] \end{array}}$ where: CS_VerID = [CS_ad₁,…,CS_{ad_m}] points to the cloud service provider.

(2)

Receive/publish Verifiable Reputation Evaluation Certificates (VerRECs), VerRECs are certificates that evaluate the behavior of a node in a blockchain. Each node publishes and stores received VerRECs, which can be found using VerREL_VerID. A VerREC can be defined as: 2 $(\begin{matrix} V e r I D, R e p u t a t i o n_{v} a l u e, T i m e, V e r I D_{i s s u s e r} \\ S i g n_{i s s u e r} [H (E v a l u a t e_{V e r t D} | | R e p u t a t i o n_{v} a l u e | | T i m e)] \end{matrix})$

(3)

Issue Verifiable Attribute Certificates (VerACs) for other nodes of the blockchain or receive VerACs issued by other nodes: 3 ${\begin{matrix} V e r I D_{o w n e r}, A t t r i b u t e, T i m e, V e r I D_{i s u s e r}, V e r I A_N u m b e r \\ S i g n_{i s s u e r} [H (V e r I D_{i s s u e r} | | A t t r i b u t e | | V e r I A_N u m b e r)] \\ S i g n_{i s s u s e r} [H (V e r I D_{i s s u s e r} | | A t t r i b u t e | | V e r I A_N u m b e r | | H (V e r I D_{o w n e r}))] \end{matrix}}$

Where: VerID_owner is the VerID of the ID book owner. VerIA_ Number is the number of that VerAC during the publishing process. VerID_issuer is the identity of the ID certificate issuer.

(4)

The Verifiable Attribute Revocation Certificate (VerARC) and its signature are stored into the Attribute Revocation List maintained jointly by all nodes and the VerARC can be defined as: 4 ${\begin{array}{l} V e r I D_{i s s u e r}, V e r I A_{-} N u m b e r, T i m e \\ S i g n_{i s s u e r} [H (V e r I D_{i s s u e r} | | V e r I A_{-} N u m b e r | | T i m e)] \end{array}}$

2)

Cryptosystem initialization

Using the POR consensus algorithm, N nodes are selected as attribute authorities. The public parameters params of the system are generated based on the security parameter λ. params contains bilinear groups G and G_T of order prime p, and the generators of group G are g, bilinear mapping e : G×G → G_T and two hash functions $H : {^{0, 1} *} \to G, H_{1} : {^{0, 1} *} \to Z_{p}^{*}$ , and threshold value t [22]. The set of attributes of the system can be denoted as S= {1…z}, where z denotes the number of attributes of the system. N and AA can be represented as VVerID₁, …,VVerID_N respectively and the threshold multi-authoritative CP-ABE scheme can be executed together to generate their own attribute private key shares and corresponding attribute public keys for data consumers [23]. The specific steps are as follows:

(1)

For attribute x ∈ {1,…,z}, each AA_m chooses two random numbers α_m,x, β_m,x, m ∈ {1,…,N} as its own attribute private key share. As a result, the private key of attribute x can be represented as $α_{x} = \sum_{m} = 1^{N} α_{m, x}$ and $β_{x} = \sum_{m = 1}^{N} β_{m, x}$ . Any AA_m cannot obtain the complete attribute private key (α_x, β_x), and each AA_m chooses two random (t – 1)th polynomials: 5 $f_{m} (z) = a_{m, 0} + ... + a_{m, i - 1} z^{t - 1}, α_{m, x} = f_{m} (0) = a_{m, 0}$ 6 $l_{m} (z) = b_{m, 0} + ... + b_{m, t - 1} z^{l - 1}, β_{m, x} = l_{m} (0) = b_{m, 0}$ where a_m,0,…,a_m,t–1 ∈ Z_p, b_m,0,…,b_m,t–1 ∈ Z_p. Each AA_m then computes the respective endorsement value: A_m,k = e(g, g)^a_m,k, B_m,k = g^b_m,k, k, ∈ [0,t – 1] and broadcasts it to the other attribute authorities. Additionally, the sub-shares s_m,j = f_m(H₁(VVerID_j)) and o_m,j = l_m(H₁(VVerID_j)) of the respective attribute private keys are computed and signed to be sent to the other AA_{j,j∈{1…,m–1,m+1…,N}}. Meanwhile, each AA_m each computes s_m,m = f_m(H₁(VVerID_m)) and o_m,m = l_m(H₁(VVerID_m)) to be saved locally.

(2)

Each AA_m receives a sub-share s_j,m, o_j,m of the attribute private key from the other N – 1 , AA and verifies whether Equation $e (^{g, g) s_{j, m}} = \prod_{k = 0}^{t - 1} A_{j, k}^{H_{1} {(V V e r I D_{m})}^{k}}$ , $g^{o_{j, m}} = \prod_{k = 0}^{t - 1} B_{j, k}^{H_{i} {(V V e r I D_{m})}^{k}}$ holds. If it holds, AA_j is considered a trusted node. Otherwise, AA_j must resend the sub-share s_j,m, o_j,m until the verification passes.

(3)

After performing steps (1)~(2), each AA_m receives the broadcast value {A_m_,0 = e(g,g)^α_m,x, B_m_,0 = g^β_x}_m∈[1,N] and can be publicly verified. The public keys of attribute x can be represented as: $e (^{g, g) α_{x},} = e (^{g, g) \sum_{m = 1}^{N} α_{m, x}} = \prod_{m = 1}^{N} A_{m, 0}$ and $g^{β_{x}} = g^{\sum_{m = 1}^{N} β_{m, x}} = \prod_{m = 1}^{N} B_{m, 0}$ , APK_x = (e(g,g)^α_x, g^β_x). Finally, adding APK_x to params, params can be represented as: {p,g,e,G,G_T,H,H₁,APK_x}.

4.2.2

Outsourced data storage

The data owner encrypts the private data and stores it on the cloud server through the CP-ABE scheme with the following encryption algorithm steps:

The input data m, the public parameters params, a set of attribute public keys {APK_x}, x ∈ R_τ and the access structure τ = {M,ρ}, M is a l*n matrix, the function ρ represents the mapping of each row element of the matrix M to an attribute x, and R_τ represents the set of attributes in the access structure.

Randomly select a secret value $s \in Z_{p}^{*}$ and a vector $\vec{ν} = (^{s, v_{2}, ..., v_{n}) T}$ , where $v_{2}, ..., v_{n} \in Z_{p}^{*}$ . Then compute $λ_{i} = M_{i} \cdot \vec{ν}$ , where M_i represents row i of matrix M. Select a random vector $\vec{w} \in Z_{p}^{n}$ , with the first element of vector $\vec{w}$ set to 0 and compute $ω_{i} = M_{i} \cdot \vec{w}$ . Randomly select r₁,…,r_l ∈ Z_p and generate secret message CT: 7 ${\begin{matrix} τ, C_{0} = m \cdot e {(g, g)}^{s}, C_{1, i} = e {(g, g)}^{λ_{i}} \cdot e {(g, g)}^{α_{ρ (i)} r_{i}} \\ C_{2, i} = g^{r_{i}}, C_{3, i} = g^{β_{ρ (i)} r_{i}} \cdot g^{ω_{i}} \end{matrix}}$

Of these, ∀ ρ(i) ∈ R_τ.

4.2.3

Anonymous key generation

The anonymous key generation process is as follows: 1)

The anonymous key request format is set to: 8 $(P K_{t e m p} | | H (V e r I D_{o w n e r}) | | V e r A C_{1} | | ... | | V e r A C_{u})$

Where (PK_temp, SK_temp) is a generated temporary key, PK_temp is used to ensure security during the transmission of the attribute private key share, and SK_temp is stored locally by the data user. In the key generation request, H (VerID_owneσ) is used to protect the identity privacy of the data user. The data user individually encrypts the key generation request using the blockchain public key of each attribute authority and sends the ciphertext to the corresponding attribute authority. At this point, VerAC can be represented as: 9 ${\begin{matrix} A t t r i b u t e_{x}, V e r L A_{x}_N u m b e r, V e r I D_{i s s u e r}^{(x)} \\ S i g n_{i s s u e r} [H (A t t r i b u t e_{x} | | V e r L A_{x} - N u m b e r | | V e r I D_{i s s u e r}^{(x)} | | H (V e r I D_{o w n e r}))] \end{matrix}}$

2)

Upon receiving the request, the attribute authority decrypts the key generation request using its own blockchain private key and verifies the binding relationship between each attribute in the key request and the data user. Then, the identity of the attribute publisher and its VerAC number $(V e r I D_{i s s u e r}^{(x)}, V e r L A_{x}_N u m b e r)$ are used as the index of the ARL to verify whether the attributes in the request submitted by the data user have been revoked. If not revoked, the attribute authority generates an attribute key share for each attribute in the key request: 10 $K_{x, V e r I D_{o w n e r}, m} = g^{A z k_{m, a_{x}}} H (^{V e r I D_{o u n e r}) A z k_{m, β_{x}}}$ where Ask_{m,α_x} denotes the share of the attribute private key received by each AA_m from the other AA, $A s k_{m, α_{x}} = \sum_{j = 1}^{N} s_{j m}$ . Similarly, $A s k_{m, β_{x}} = \sum_{j = 1}^{N} o_{j m}$ . H(VerID_owner) denotes the hash of the identity of the data user in the key request. Encrypt the generated attribute private key share {K_{x.VerID_owner,m}, x = 1,…, u} using the temporary public key PK_temp generated by the data user in the key request, and send the generated ciphertext to the data user.

3)

The data user decrypts the ciphertext sent by the first t attribute authority using the locally saved private key SK_temp. Then, performs the Lagrange interpolation algorithm [24] and obtains the complete attribute private key: 11 ${K_{x, V e r I D_{o w n e r}} = g^{α_{x}} H (^{V e r I D_{o w n e r}) β_{x}}, x = 1, ..., u}$

4.2.4

Anonymous data access

Data access is divided into two phases: pre-decryption by the cloud service provider and local decryption by the user. The corresponding steps are as follows: 1)

Cloud service provider pre-decryption

(1)

The data user selects a random number $t \in Z_{p}^{*}$ and converts its own identity and attribute private keys to obtain H(VerID_owner)^1/t and K_{x,VerID_owner}^1/t. Then, an anonymous data access request is constructed, which consists of: 12 $(H {(V e r I D_{o w n e r})}^{1 / t} | | C e r t (x) | | F L, x = 1, ..., u)$ where Cert(x) indicates a certificate owned by the data user that contains the following: 13 ${\begin{matrix} K_{x, V e r D_{o w n e r}}^{1 / t}, A t t r i b u t e_{x}, V e r L A_{x}_N u m b e r, V e r I D_{i s s u e r}^{(x)} \\ S i g n_{i s s u e r} [H (A t t r i b u t e_{x} | | V e r L A_{x}_N u m b e r | | V e r I D_{i s s u e r}^{(x)}] \end{matrix}}$ wherein Attribute_x denotes attribute x, $V e r I D_{i s s u e r}^{(x)}$ denotes an identity of the publisher of attribute x, VerLA_x_Number denotes a VerAC number of attribute x during the publishing process, and FL denotes a list of files that the data user wants to access. The data user encrypts the data access request using the blockchain public key of the cloud service provider and sends the ciphertext to the cloud service provider.

(2)

The cloud service provider receives the ciphertext and decrypts it using its own blockchain private key and verifies the signature of VerAC in the request using the blockchain public key of the identity attribute publisher. At the same time, it verifies whether the attributes in the request submitted by the data user have been revoked. If yes, the data user’s data access request will be rejected. If not, a search is carried out using the FL and the corresponding ciphertext is discovered.

(3)

For each ciphertext found, the cloud service provider verifies whether the set of attributes in the access request satisfies the access policy in the ciphertext. If so, decrypt the document ciphertext using H(VerID_owner)^1/t and K_{x,VerID_owner}^1/t, and send the decryption result to the data user. Otherwise, the access request is denied. Order I ⊂ {1,…,l}, Definition I = {i : ρ(i) ∈ R_τ}. for ∀i : 14 $\frac{e (H {(V e r I D_{o w n e r})}^{1 /_{t}}, C_{3, i})}{e (K_{ρ (i), V e r I D_{o w n e r}}^{1 /_{t}}, C_{2, i})} = \frac{e (H {(V e r I D_{o w n e r})}^{1 /_{t}}, g^{ω_{i}})}{e (g^{a_{ρ (i) /_{t}}}, g^{r_{i}})}$

The pre-decryption results are as follows: 15 ${C_{0} = m \cdot e {(g, g)}^{s}, C_{1, i} = e {(g, g)}^{λ_{i}} \cdot e {(g, g)}^{α_{ρ (i) r}_{_{i}}}, {[\frac{e (H (V e r I D_{o w n e r}), g^{ω_{i}})}{e (g^{a_{ρ (i)}}, g^{r_{i}})}]}^{1 / t}}$

2)

User local decryption

(1)

According to the access matrix τ = (M,ρ), λ_i is a valid share of s, there exists a set of constants {d_i ∈ Z_p, i ∈ I} such that $s = \sum_{i} \in I d_{i} λ_{i}$ . In addition, $\sum_{i \in I} d_{i} M_{i} = (1, 0, ..., 0)$ is satisfied.

(2)

When the data user receives the pre-decryption result, using the previously chosen random number t, it can be calculated: 16 $A = {{[\frac{e (H (V e r I D_{o w n e r}), g^{ω_{i}})}{e (g^{α_{ρ (i)}}, g^{r_{i}})}]}^{1 / t}}^{t} = \frac{e (H (V e r I D_{o w n e r}), g^{ω_{i}})}{e (g^{α_{ρ (i)}}, g^{r_{i}})}$

The data user then uses A to calculate to obtain m : 17 $m = \frac{C_{0}}{\prod_{i \in I} {(C_{1, i} \cdot A)}^{d_{i}}} = \frac{C_{0}}{\prod_{i \in I} {(C_{1, i} \cdot \frac{e (H (V e r I D_{o w n e r}), g^{ω_{i}})}{e (g^{a_{ρ (i)}}, g^{r_{i}})})}^{d_{i}}}$

5

Simulation experiments and analysis

5.1

Experimental environment

In this chapter, the performance analysis of the proposed distributed network authentication and access control scheme is carried out by constructing an Ethernet private chain, where Ethernet is deployed on an Ubuntu 20.04 server with a processor of Intel(R) Core i5-7500 CPU @3.40 GHz and running on 16.00 GB of RAM. The framework of this system is built on Windows 11 with a processor of Intel(R) Core i5-7500 CPU @3.40 GHz and running on 16.00 GB of RAM and the web3j 5.0.0 toolkit is utilized to implement the interaction between Intelli J IDEA 2024.3.1 and the blockchain. The experiments in this chapter are based on the set of attributes and policies in the standard policy conformance test package provided by XACML. The experimental environment is: Ubuntu 24.04 server system, web3j 3.4.0, JDK 22, Node.js 23.0.0.

5.2

Access Control Latency Testing

For five types of privacy level data resources, 6000 different access control policies are set up in the policy set, 1200 access requests are set up for each type of data resource, and 12 experiments are conducted for each type of data, and the access control latency is recorded for each time. The results of a comparison of access control delays are shown in Fig. 4.

From Fig. 4, it can be seen that the access control delay is lower than 900s for the data of privacy level L1. The access control delay fluctuates between 1100s~1800s for the data of privacy level L2. For data with privacy level L3~L5, the access control latency is around 2500s, 4500s and 5500s respectively. It can be seen that as the data privacy level decreases, the access control latency also decreases. This is because the higher the data privacy level, the more complex the access control policy is, and the longer the policy retrieval and judgment time are.

5.3

Access to judgment performance analysis

The performance of access control is mainly determined by the efficiency of policy retrieval and the delay in policy judgment. First, the number of policies in the policy set is set to 3600, and then 1200 access control requests are constructed. The policy retrieval time consumption and policy judgment delay are recorded. With 1200 access control policies and an increase in the number of access requests, the time required to retrieve policies is shown in Fig. 5.

From Fig. 5, it can be seen that when the number of access requests increases to 1200, the policy retrieval time consumption is 70.3 s. As the number of access control requests increases, the policy retrieval time also increases. The time consumption for retrieving policies and the number of access control requests have a linear growth trend. This is due to the fact that as the number of requests increases, there is a need to queue for the contract to process the requests.

As the number of access requests keeps increasing, the variation of policy judgment delay is shown in Fig. 6.

As the number of access requests increases, the policy judgment delay also increases, and when the number of access requests is 1200, the policy judgment delay reaches about 5500s. This is because when the access requests increase, they need to be queued for contract judgment processing.

The relationship between the policy verdict success rate and the number of access control policies is shown in Figure 7. Where 100 to 1200 indicates the number of access control policies and 84% to 100% indicates the policy verdict success rate.

From Fig. 7, it can be seen that as the number of access control policies continues to increase, the policy verdict success rate, although relatively increased under 500 and 800 access control policies, has generally declined, from 97.55% for 100 access control policies to 86.19% at 1200. This may be due to the fact that the increase in the number of access control policies results in conflicting policies, which leads to the failure of the contract policy judgment.

In addition, this paper also compares the time required to perform various operations on access policies simultaneously, and the experimental results are shown in Fig. 8. Where the horizontal line of the horizontal gradient line represents the corresponding average delay.

From Fig. 8, it can be seen that the time spent on reading, updating and deleting operations on access policies grows as the number of access requests increases. The time taken to perform update and delete operations on the access policy increases compared to performing read operations on the access policy, and the increase is greater for delete operations. The average latency of performing read, update and delete operations on access policies reaches 110.s, 123.6s and 141.8s respectively for a number of 1200 access requests.

5.4

Protocol Performance Analysis

This section focuses on the collaborative authentication process between users and information service entities, and will analyze the protocol performance of the access control schemes in terms of protocol communication and computation, comparing the two identity authentication protocols proposed in the existing researches, which are named as Scheme I and Scheme II, respectively.

First, the volume of protocol communication is analyzed, and the comparison of the three schemes’ protocol communication volume is shown in Fig. 9.

The total protocol communication volume of the proposed scheme in this paper is 3391.6bite, which is smaller than the 4293.7bite of scheme two and close to the 3368.0bite of scheme one. However, Scheme I directly sends user identifiers during the authentication process, on the one hand, the difference in the size of user identifiers will indirectly lead to the change in the size of the protocol communication volume, on the other hand, the practice of directly sending user identifiers does not guarantee the anonymity of user information. From the perspective of ISE side communication volume, the scheme of this paper is 1651.5bite, which is larger than other protocols, but the communication volume of the user side is obviously reduced, which is because this paper considers the limited computational capacity of the user side, so it reduces the weight of the user side through the ISE side. In summary, the collaborative identity authentication protocol proposed in this paper is to take into account the communication volume on the basis of ensuring the anonymity of the user, so it is in a certain advantage in terms of communication volume compared with the other two schemes.

Secondly, this paper analyzes the computational overhead of the proposed collaborative authentication protocol, ignoring the system initialization and key generation process for the time being, and compares and analyzes the collaborative authentication process only for the user nodes and information service entity nodes. In the fast authentication process and secure authentication process, the computing operations of user and information service entity request messages are the same, so we continue to analyze the computational overhead of the request messages in a unified way, and this paper still compares it with Scheme 1 and Scheme 2, and the time of various types of computing operations in the scheme are as follows: the computing time of the bilinear pairs is T_e is 4.581ms, the time of the dot multiplication operation in the group G₁ is T_PM is 1.824 ms, the point addition operation time T_PA in group G₁ is 0.008ms, the exponent operation time T_E in group G₂ is 0.265ms, the hash operation time T_H is 0.004ms, and the mapping to point operation time T_TP is 4.724ms.

To address the computational overhead of the protocols, in order to differentiate between the actual computational capabilities of the user side and the ISE side of the information service entity, they are therefore also discussed separately in this paper. In this paper, the computing operations and time overhead of each protocol at the user and ISE sides are organized as shown in Table 1.

Table 1.

Protocol operation

Time overheadScheme	Client-side	ISE-side
Scheme 1	7T_PM+5T_H+1T_TP	2T_e+5T_PM+1T_PA+4T_H+1T_TP
Scheme 2	7T_PM+1T_PA+8T_H+1T_TP	2T_e+5T_PM+1T_PA+3T_H+1T_TP
This article’s scheme	3T_PM+1T_PA+1T_E+4T_H	3T_e+3T_PM+3T_H

In Table 1, taking the authentication request message computation in this paper as an example, the user node needs to perform two T_PM operations, one T_E operation, one T_PA operation and four T_H operations during the authentication process, and the information service entity node needs to perform three T_e operations, three T_PM operations and three T_H operations during the authentication process.

In addition, this paper further compares the computational overhead of the three protocols in detail as shown in Fig. 10.

As can be seen from Fig. 10, this paper’s scheme significantly shortens the computation at the user side with a computation overhead of only 5.9ms relative to schemes 1 and 2, which is mainly due to the fact that this paper’s scheme reduces one mapping-to-point operation, and thus there is no need to consider the mapping time T_TP, which likewise achieves the purpose of anonymity protection of the user’s identity. In terms of the computing time at the ISE side of the information service entity, this paper’s scheme and the other two schemes do not reflect a significant difference, which is mainly due to the fact that all the three schemes transfer the computation at the user side to the ISE side of the information service entity in consideration of the constrained computing devices and computational capabilities at the user side. Nevertheless, the total computational overhead of this paper’s scheme in requesting information is still much lower than that of the other two schemes, reflecting the superiority of this paper’s protocol in terms of computational overhead.

6

Conclusion

In this paper, based on blockchain technology, we successfully realize the design of identity authentication system for distributed networks, and by improving the traditional KP-ABE scheme, we realize the design of collaborative fine-grained access control scheme based on blockchain. In order to test the performance of the scheme, simulation experiments are conducted in this paper, and the conclusions obtained are as follows: 1)

The values of access control latency range from (400s,900s), (1100s,1800s), (2300s,2800s), (4400s,4800s), and (5400s,5800s) for the data of privacy level L1~L5, respectively. This indicates that the latency of access control decreases as the data privacy level decreases. The reason for this is that the higher the data privacy level, the more complex the access control policy is, and the longer the policy retrieval and judgment time.

2)

Both policy retrieval time and judgment delay are increasing with the increase in the number of access control requests. The time spent on reading, updating, and deleting operations on access policies is increasing with the increase in the number of access requests. And the time taken to perform update and delete operations on the access policy increases as compared to performing read operations on the access policy. Under the number of 1200 access requests, the average latency of reading, updating and deleting operations on access policies reaches 110.s, 123.6 s and 141.8 s. With the increasing number of access control policies, the success rate of policy adjudication is decreasing in general.

3)

In terms of communication volume, the total protocol communication volume of the authentication and access control scheme proposed in this paper is 3391.6bite, which is smaller than the 4293.7bite of Scheme 2 and close to the 3368.0bite of Scheme 1. In terms of the communication volume of ISE side, the scheme of this paper is 1651.5bite, which is larger than the other protocols, but the communication volume of the user side is significantly reduced, which is because this paper reduces the weight of the user side through the ISE side. Overall, this paper’s scheme can take into account communication volume while ensuring user anonymity, and it is better than the other two schemes in terms of communication volume. As for the computational overhead, this paper’s scheme is much smaller than the other two schemes in terms of the total computational overhead of requesting information, which fully illustrates the superiority of this paper’s scheme in terms of computational overhead.

Language:: English

Publication timeframe:: 1 times per year
Journal Subjects:: Life Sciences, Life Sciences, other, Mathematics, Applied Mathematics, General Mathematics, Physics, Physics, other

Journal RSS Feed

Research on Distributed Network Authentication and Access Control Mechanism Based on Blockchain Technology

Ting Yin

Sijia Zhao

Published Online: Mar 19, 2025

Received: Oct 28, 2024

Accepted: Feb 06, 2025

DOI: https://doi.org/10.2478/amns-2025-0447

KeywordsBlockchain technology, Authentication, Access control, KP-ABE scheme

© 2025 Ting Yin et al., published by Sciendo

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Keywords
Blockchain technology, Authentication, Access control, KP-ABE scheme