# A Blockchain-Based Hierarchical Authentication Scheme for Multiserver Architecture

Authors: Miqi Wu; Lin You; Gengran Hu; Liang Li; Chengtang Cao
Journal: Security and Communication Networks
 (2021)

---

## Abstract

In a multiserver architecture, authentication schemes play an important role in the secure communication of the system. In many multiserver authentication schemes, the security of the mutual authentications among the participants is based on the security of the registration center’s private key. This centralized architecture can create security risks due to the leakage of the registration center’s private key. Blockchain technology, with its decentralized, tamper-proof, and distributed features, can provide a new solution for multiserver authentication schemes. In a lot of multiserver authentication schemes, users’ permission is generally controlled by the registration center (RC), but these permission control methods cannot be applied in the decentralized blockchain system. In this paper, a blockchain-based authentication scheme for multiserver architecture is proposed. Our scheme provides a hierarchical authentication method to solve the problems of user permission control and user revocation caused by no registration center. The security of our scheme is formally proved under the random oracle model. According to our analysis, our scheme is resistant to attacks such as impersonation attacks and man-in-the-middle attacks. In addition, our performance analysis shows that the proposed scheme has less computation overhead.


---

## Body

## 1. Introduction

With the developments of the Internet economy and the network application scale, it is difficult for a single server to provide complete services for users. To address this problem, multiserver architectures have emerged. In multiserver systems, the authentication and the corresponding secret key agreement between the servers and the users are important issues to ensure service efficiency and communication security. However, the traditional password-based authentication methods [1] applicable to single client/server architectures are not applicable to multiserver architectures. In recent years, many kinds of new multiserver authentication schemes [2–8] have been proposed, including various improvements to scheme security and performance. The common feature of these schemes is the existence of three participants: the user, the registration center, and the server. The private key of the registration center is used in the process of participant registration and participant mutual authentication. If the private key of the registration center is leaked, the whole system will suffer from significant security risks.The emergence of blockchain technology has provided a new solution to the authentication and key agreement scheme in multiserver architecture. Blockchain technology is decentralized, tamper-proof, and jointly maintained by multiple parties. Using blockchain technology can solve the trust problem between the users and the servers [9] and give better robustness to multiserver systems and avoid the security risks mentioned above. The use of blockchain for enforcing the security of the network systems has proved to be significantly beneficial. For example, blockchain can provide access control, maintain data integrity, and improve availability [10]. Xiong et al. [11] proposed the first blockchain-based two-factor multiserver authentication scheme. Their scheme was claimed to be able to make mutual authentication of the participants without online RC and have effective revocation. However, in fact, the scheme did not take into account the impact of the introduction of decentralized blockchain networks on the design of multiserver authentication schemes. The registration process and revocation process of the users in their scheme were done through only one server, without the supervision of the nodes or other servers, which allows the servers to tamper with the revocation and reregistration messages of users and thus steal their identities. In addition, their scheme lacks user permission control, as each user only needs to register with one of the servers to have unrestricted access to all other servers. In practical applications, access control in multiserver systems is important, and we give an example of a multiserver system for a school league in Figure 1. The creation of the multiserver system can facilitate the students and the teachers to access the resources of other schools’ servers, while the hierarchical access control function can prohibit the users with low-level permission (such as students) from accessing high-level servers (such as confidential servers). Kou et al. [2] proposed a scheme that have a hierarchical approach where the users of different levels could access servers of different levels. The permission level in their scheme construction is bound to the user’s public-private key pair, which requires the user to change his public-private key pair when the permission level is changed. Besides, they used the bilinear pairing operation in their scheme, and it will make Kou et al.’s scheme be of low usability and have high computation overhead.Figure 1
A blockchain-based hierarchical multiserver authentication system in a school league. Each school has its own confidential servers and normal servers. These servers can identify the user’s identity with the help of the blockchain system, regardless of the school they come from. And the confidential server is only available to the teachers who have access to it, while the students do not have access to it.In this paper, a blockchain-based hierarchical authentication scheme for a multiserver architecture is proposed. The main contributions are as follows:(1)
A blockchain-based decentralized multiserver authentication scheme is proposed to deal with the problem of centralization under the original multiserver architecture. Our scheme has three security factors and has a lower computation overhead shown by performance analysis. Compared with Kou et al.’s scheme [2], our scheme does not use the bilinear pairing operation, so the computation overhead in our scheme can be reduced by 82%. Compared with Xiong et al.’s scheme [11], the computation overhead in our scheme can be reduced by 17%.(2)
A blockchain-based hierarchical access control method for a multiserver architecture is proposed in this paper. It makes up for the lack of user permission control in several blockchain-based multiserver authentication schemes (such as Kou et al.’s scheme [2] and Ren et al.’s scheme [12]). This method can adapt to the decentralized operation model of blockchain systems, control user access to the servers, and achieve secure revocation of the user accounts in the blockchain environment.(3)
We provide a security model for blockchain-based multiserver authentication scheme and prove its security under the random oracle model. Also, a security analysis is provided to illustrate that our scheme is secure against impersonation attack, etc.The remainder of the paper is organized as follows. Section2, respectively, reviews the related work on the traditional multiserver authentication schemes and the blockchain-based identity authentication schemes. Section 3 introduces the background knowledge of blockchain technology, fuzzy extractor, and elliptic curve cryptographic theory. Section 4 describes the system in our scheme. Section 5 elaborates the phases in our scheme in detail. Section 6 makes a formal proof of the security of our scheme. Section 7 shows the advantages of our scheme in terms of safety and performance through the comparison with other schemes. Section 8 summarizes this paper and enumerates future application.


## 2. Related Work

In 2001, Li et al. [13] proposed a neural network-based multiserver authentication system. In 2014, Chuang et al. [14] proposed an authenticated key agreement scheme for anonymous multiserver architecture based on trusted computing by combining smart cards, user passwords, and biometrics and claimed that their scheme could meet all the key requirements for the multiserver architectures. Wan et al. [3] observed that Chuang et al.’s scheme could not guarantee anonymity and could not resist smart card loss attacks, so they proposed an improved scheme that not only solved the problems in the above scheme but also inherited the advantages of the original scheme. In 2015, He and Wang [4] proposed a robust biometric-based multiserver authentication scheme which was the first truly three-factor authentication scheme for multiserver environment. They used the fuzzy extractor to extract biometric key from biometric information. Later, Odelu et al. [15] pointed out that He and Wang’s scheme was vulnerable to the known session-specific temporary information attack and impersonation attack. To address these issues, they proposed a secure biometric-based multiserver authentication scheme [5] using smart cards that resisted various attacks. In 2015, Tsai and Lo [16] proposed an efficient authentication scheme for distributed mobile cloud computing services. Later in 2017, Odelu et al. [6] pointed out that Tsai et al.’s scheme did not provide both the session key security and strong user credentials’ privacy. To address these issues, they designed a provably secure authentication scheme for the distributed mobile cloud computing services. In 2016, He et al. proposed a new scheme [7] that reduced the computation and communication costs.Because of the decentralized and tamper-proof features of blockchain, some blockchain-based identity authentication schemes have been proposed. In 2019, Hei et al. [17] proposed an identity information sharing authentication scheme which used smart contract technology to share and update identity information, and it could solve the problem of multiple user registrations on multiple servers. In addition, it used attribute-based cryptography to protect the privacy of users. Zhou et al. [18] proposed a blockchain-based two-factor authentication scheme for cross-domain authentication. Mohsin et al. [19] proposed a biometric-based patient identity authentication scheme that solved the problem of storing biometric information on the blockchain. Ren et al. [12] designed a IoMT node authentication and key agreement scheme for across to the trust domain based on blockchain, but their scheme cannot provide user anonymity and untraceability and do not have user permission control.


## 3. Background and Notations

### 3.1. Blockchain Technology

Blockchain technology originated from a paper “A Peer-to-Peer Electronic Cash System” published in 2008 by an academic with the pseudonym Nakamoto [20]. Blockchain can be applied in various fields owing to its good properties such as auditability, transparency, immutability, and decentralization. In recent years, blockchain has helped improve security and privacy in a variety of application scenarios such as smart cities [21], IoT [22], healthcare [23], and smart vehicles [24].There are three main concepts in blockchain technology, that is, nodes, consensus, and blocks. The node is an entity in a blockchain network that is responsible for recording transactions in the blockchain network and packaging them into a block, which is then broadcasted to other nodes or reach consensus with other nodes. The consensus algorithm is the most important part of blockchain technology. Different blockchain networks use different consensus algorithms. For example, Bitcoin uses PoW (proof of work). The node broadcasts the block after a block is generated. The block is considered to be recorded on the chain when most of the nodes reach consensus about the block and work based on this block.The consortium blockchain is a kind of blockchain, which is suitable for building a system of cooperation among multiple institutions. Each node of the consortium blockchain usually has its corresponding entity organization, which can join and exit the network only after authorization, and each organization forms an alliance with related interests to maintain the healthy operation of the blockchain. Nowadays, Hyperledger Fabric is one of the most mainstream consortium blockchain applications.


### 3.2. Fuzzy Extractor

Fuzzy extractor is an algorithm first proposed by Dodis et al. [25] which can extract a uniformly distributed random secret key R and an auxiliary information BP from input biometric information ω. When another biometric information ω′ similar to ω is input, R can be recovered with the help of BP. According to [25], we define the following two algorithms:(i)
R,BP←Genω: fuzzy-extractor generation algorithm. Upon receiving the user’s biometric information ω, the algorithm will output the random string secret key R and public information BP corresponding to the user’s biometric information.(ii)
R←Repω′,BP: fuzzy-extractor recovery algorithm. Upon receiving the user’s biometric information ω and the corresponding public information BP, the algorithm will output the string R corresponding to the user’s biometric information ω if the error between the two input biometric features is satisfied within the tolerance range, i.e., disω′,ω≤r, where r is the tolerance error.


### 3.3. Elliptic Curve Cryptography

Letp be a large prime number and Fp be a finite field of order p, then the elliptic curve E over the finite field Fp is defined. The point P is an element with large prime order q on the additive group G on E. We introduce the discrete logarithm problem and the computational Diffie–Hellman problem in the elliptic curve cryptography:(i)
Elliptic Curve Discrete Logarithm (ECDL) Problem: it is easy to calculateA by given P and a, but it is hard to determine a by given A and P, where A=a·P, and A∈G.(ii)
Elliptic Curve Computational Diffie–Hellman (ECCDH) Problem: it is hard to computea⋅b⋅P as a,b are unknown elements in Zq∗, where A=a⋅P, B=b⋅P, and P,A,B∈G.Based on the elliptic curve cryptography, we represent the elliptic curve digital signature algorithm ECDSA as the following three functions:(i)
Keygen1k⟶SK,PK: Key Generation Function. The function generates a random private key SK and the corresponding public key PK.(ii)
SigSK,m⟶SIG: Signature Function. The function uses the private key SK to calculate the signature SIG of massage m.(iii)
VerPK,SIG,m⟶bool∈true,false Verify Function. The function uses the public key PK to verify whether SIG is the correct signature of the message m. If SIG is the correct signature of the message m, the function will output true, otherwise output false.


### 3.4. Notations

We provide the definition of notations appearing in our scheme in Table1.Table 1
Definition of notations.
NotationDefinitionp,qPrime numbersFpA finite field of orderpEAn elliptic curve over the finite fieldFpGAn additive group consisting of points onEPA generator of the groupG with order qUiith userSjjth serverIDUiith user’s identityIDSjjth server’s identityPWiith user’s passwordωiith user’s biometrics informationRiith user’s biometrics keyLnAccess permission levelPKUi,SKUiith user’s public-private key pairPKSj,SKSjith application server’s public-private key pairPKPr,SKPrrth permission server’s public-private key paira‖bEncodinga and b as strings from which the constituent objects are easily recoverablea⊕bEncodinga and b as a binary bit string for an XOR operations←$SOperation of assigning tos an element of S chosen at randomh1,h2Two secure hash functionsℋ1, ℋ2The range of the output of the hash functionsh1,h2AAdversary in the security modelℬChallenger in the security model∏i,jttth session between user Ui and server Sj


## 3.1. Blockchain Technology

Blockchain technology originated from a paper “A Peer-to-Peer Electronic Cash System” published in 2008 by an academic with the pseudonym Nakamoto [20]. Blockchain can be applied in various fields owing to its good properties such as auditability, transparency, immutability, and decentralization. In recent years, blockchain has helped improve security and privacy in a variety of application scenarios such as smart cities [21], IoT [22], healthcare [23], and smart vehicles [24].There are three main concepts in blockchain technology, that is, nodes, consensus, and blocks. The node is an entity in a blockchain network that is responsible for recording transactions in the blockchain network and packaging them into a block, which is then broadcasted to other nodes or reach consensus with other nodes. The consensus algorithm is the most important part of blockchain technology. Different blockchain networks use different consensus algorithms. For example, Bitcoin uses PoW (proof of work). The node broadcasts the block after a block is generated. The block is considered to be recorded on the chain when most of the nodes reach consensus about the block and work based on this block.The consortium blockchain is a kind of blockchain, which is suitable for building a system of cooperation among multiple institutions. Each node of the consortium blockchain usually has its corresponding entity organization, which can join and exit the network only after authorization, and each organization forms an alliance with related interests to maintain the healthy operation of the blockchain. Nowadays, Hyperledger Fabric is one of the most mainstream consortium blockchain applications.


## 3.2. Fuzzy Extractor

Fuzzy extractor is an algorithm first proposed by Dodis et al. [25] which can extract a uniformly distributed random secret key R and an auxiliary information BP from input biometric information ω. When another biometric information ω′ similar to ω is input, R can be recovered with the help of BP. According to [25], we define the following two algorithms:(i)
R,BP←Genω: fuzzy-extractor generation algorithm. Upon receiving the user’s biometric information ω, the algorithm will output the random string secret key R and public information BP corresponding to the user’s biometric information.(ii)
R←Repω′,BP: fuzzy-extractor recovery algorithm. Upon receiving the user’s biometric information ω and the corresponding public information BP, the algorithm will output the string R corresponding to the user’s biometric information ω if the error between the two input biometric features is satisfied within the tolerance range, i.e., disω′,ω≤r, where r is the tolerance error.


## 3.3. Elliptic Curve Cryptography

Letp be a large prime number and Fp be a finite field of order p, then the elliptic curve E over the finite field Fp is defined. The point P is an element with large prime order q on the additive group G on E. We introduce the discrete logarithm problem and the computational Diffie–Hellman problem in the elliptic curve cryptography:(i)
Elliptic Curve Discrete Logarithm (ECDL) Problem: it is easy to calculateA by given P and a, but it is hard to determine a by given A and P, where A=a·P, and A∈G.(ii)
Elliptic Curve Computational Diffie–Hellman (ECCDH) Problem: it is hard to computea⋅b⋅P as a,b are unknown elements in Zq∗, where A=a⋅P, B=b⋅P, and P,A,B∈G.Based on the elliptic curve cryptography, we represent the elliptic curve digital signature algorithm ECDSA as the following three functions:(i)
Keygen1k⟶SK,PK: Key Generation Function. The function generates a random private key SK and the corresponding public key PK.(ii)
SigSK,m⟶SIG: Signature Function. The function uses the private key SK to calculate the signature SIG of massage m.(iii)
VerPK,SIG,m⟶bool∈true,false Verify Function. The function uses the public key PK to verify whether SIG is the correct signature of the message m. If SIG is the correct signature of the message m, the function will output true, otherwise output false.


## 3.4. Notations

We provide the definition of notations appearing in our scheme in Table1.Table 1
Definition of notations.
NotationDefinitionp,qPrime numbersFpA finite field of orderpEAn elliptic curve over the finite fieldFpGAn additive group consisting of points onEPA generator of the groupG with order qUiith userSjjth serverIDUiith user’s identityIDSjjth server’s identityPWiith user’s passwordωiith user’s biometrics informationRiith user’s biometrics keyLnAccess permission levelPKUi,SKUiith user’s public-private key pairPKSj,SKSjith application server’s public-private key pairPKPr,SKPrrth permission server’s public-private key paira‖bEncodinga and b as strings from which the constituent objects are easily recoverablea⊕bEncodinga and b as a binary bit string for an XOR operations←$SOperation of assigning tos an element of S chosen at randomh1,h2Two secure hash functionsℋ1, ℋ2The range of the output of the hash functionsh1,h2AAdversary in the security modelℬChallenger in the security model∏i,jttth session between user Ui and server Sj


## 4. System in Our Scheme

### 4.1. Multiserver Architecture

Our scheme mainly contains the following roles: a blockchain network consisting of several nodes, some registration terminals, some clients, some application servers, and some permission servers. The architecture of the system is shown in Figure2. Now, we introduce the functions of each role:(i)
Blockchain network: the main function of the blockchain network is to receive and process transaction requests from the registered terminals and the permission servers and then ensures that the legitimate transactions are stored at each node through consensus algorithms. After comparing various blockchains [26], we build the blockchain network with reference to Hyperledger Fabric [27,28] in our scheme. We will describe the architecture of the blockchain system in detail in Section 4.2.(ii)
Registration terminal: we assume that the user registers offline by using the registration terminal and then gets a smart card. The registration terminal has the power to commit transaction proposal to the blockchain network.(iii)
Client: the remote user accesses the application server through the client. We assume that the client can learn the public key of each server before communicating.(iv)
Application server: the application server is responsible for verifying the user’s identity and permission and providing services to the users who pass the verification. Based on the distributed feature of the blockchain, we reasonably assume that at any time the application server can establish a secure channel with at least one blockchain node, and then it can query the node for information on the blockchain.(v)
Permission server: the main function of the permission server is to accept requests from the users, verify their entity information, and then grant or revoke their permissions. The permission server has the authority to commit transaction proposal to the blockchain network. The permission server is usually managed by some authority in reality. In our scheme, there can exist several different permission servers to achieve flexible permission control.Figure 2
The architecture of the multiserver system.


### 4.2. Blockchain

The blockchain system structure in our scheme is referred to the Hyperledger Fabric system [27,28]. In Hyperledger Fabric system, there are four main types of nodes: the client node, the peer node, the order node, and the CA node. The peer nodes are responsible for verifying the transactions in the blocks sent by the sorting service nodes and storing copies of the blockchain. Some peer nodes also execute transactions and endorse the results, acting as the endorser node.


#### 4.2.1. Transaction Process

Referring to the Hyperledger Fabric system and the specifics of our scheme, the transaction process on the blockchain is designed as follows: the client node (registration terminal or permission server) commits a transaction proposal to the blockchain network. The endorser node verifies the legality of transaction, endorses the transaction, and sends the result to the client node. The client node sends the result to the orderer node. The orderer node packages transactions together to generate a new block and sends it to the committer node. The committer node checks the block and appends the block to the local blockchain, and then the transaction is completed.


#### 4.2.2. World State

In the Hyperledger Fabric system, a ledger consists of two parts: a world state and a blockchain [29].The world state is a database that holds a cache of the current values of a set of ledger states. When a transaction occurs and causes some data to change, it is immediately reflected in the world state. The world state makes it easy for a program to directly access the current value of a state rather than having to calculate it by traversing the entire transaction log. World states are expressed as key-value pairs, and it is shown in Figure3.Figure 3
Blockchain and world state. The result of the transaction will be reflected in the world state. The example in the figure shows the blockchain and the change of the world state. The transaction recorded in the blockchain is the transaction of the user’s registration, the user’s getting access permission, and the user’s revocation. The world state first records the user’s identityIDUc and public key PKUc, then records the user’s permission value sc, and finally sets the permission value to 0.


## 4.1. Multiserver Architecture

Our scheme mainly contains the following roles: a blockchain network consisting of several nodes, some registration terminals, some clients, some application servers, and some permission servers. The architecture of the system is shown in Figure2. Now, we introduce the functions of each role:(i)
Blockchain network: the main function of the blockchain network is to receive and process transaction requests from the registered terminals and the permission servers and then ensures that the legitimate transactions are stored at each node through consensus algorithms. After comparing various blockchains [26], we build the blockchain network with reference to Hyperledger Fabric [27,28] in our scheme. We will describe the architecture of the blockchain system in detail in Section 4.2.(ii)
Registration terminal: we assume that the user registers offline by using the registration terminal and then gets a smart card. The registration terminal has the power to commit transaction proposal to the blockchain network.(iii)
Client: the remote user accesses the application server through the client. We assume that the client can learn the public key of each server before communicating.(iv)
Application server: the application server is responsible for verifying the user’s identity and permission and providing services to the users who pass the verification. Based on the distributed feature of the blockchain, we reasonably assume that at any time the application server can establish a secure channel with at least one blockchain node, and then it can query the node for information on the blockchain.(v)
Permission server: the main function of the permission server is to accept requests from the users, verify their entity information, and then grant or revoke their permissions. The permission server has the authority to commit transaction proposal to the blockchain network. The permission server is usually managed by some authority in reality. In our scheme, there can exist several different permission servers to achieve flexible permission control.Figure 2
The architecture of the multiserver system.


## 4.2. Blockchain

The blockchain system structure in our scheme is referred to the Hyperledger Fabric system [27,28]. In Hyperledger Fabric system, there are four main types of nodes: the client node, the peer node, the order node, and the CA node. The peer nodes are responsible for verifying the transactions in the blocks sent by the sorting service nodes and storing copies of the blockchain. Some peer nodes also execute transactions and endorse the results, acting as the endorser node.


### 4.2.1. Transaction Process

Referring to the Hyperledger Fabric system and the specifics of our scheme, the transaction process on the blockchain is designed as follows: the client node (registration terminal or permission server) commits a transaction proposal to the blockchain network. The endorser node verifies the legality of transaction, endorses the transaction, and sends the result to the client node. The client node sends the result to the orderer node. The orderer node packages transactions together to generate a new block and sends it to the committer node. The committer node checks the block and appends the block to the local blockchain, and then the transaction is completed.


### 4.2.2. World State

In the Hyperledger Fabric system, a ledger consists of two parts: a world state and a blockchain [29].The world state is a database that holds a cache of the current values of a set of ledger states. When a transaction occurs and causes some data to change, it is immediately reflected in the world state. The world state makes it easy for a program to directly access the current value of a state rather than having to calculate it by traversing the entire transaction log. World states are expressed as key-value pairs, and it is shown in Figure3.Figure 3
Blockchain and world state. The result of the transaction will be reflected in the world state. The example in the figure shows the blockchain and the change of the world state. The transaction recorded in the blockchain is the transaction of the user’s registration, the user’s getting access permission, and the user’s revocation. The world state first records the user’s identityIDUc and public key PKUc, then records the user’s permission value sc, and finally sets the permission value to 0.


## 4.2.1. Transaction Process

Referring to the Hyperledger Fabric system and the specifics of our scheme, the transaction process on the blockchain is designed as follows: the client node (registration terminal or permission server) commits a transaction proposal to the blockchain network. The endorser node verifies the legality of transaction, endorses the transaction, and sends the result to the client node. The client node sends the result to the orderer node. The orderer node packages transactions together to generate a new block and sends it to the committer node. The committer node checks the block and appends the block to the local blockchain, and then the transaction is completed.


## 4.2.2. World State

In the Hyperledger Fabric system, a ledger consists of two parts: a world state and a blockchain [29].The world state is a database that holds a cache of the current values of a set of ledger states. When a transaction occurs and causes some data to change, it is immediately reflected in the world state. The world state makes it easy for a program to directly access the current value of a state rather than having to calculate it by traversing the entire transaction log. World states are expressed as key-value pairs, and it is shown in Figure3.Figure 3
Blockchain and world state. The result of the transaction will be reflected in the world state. The example in the figure shows the blockchain and the change of the world state. The transaction recorded in the blockchain is the transaction of the user’s registration, the user’s getting access permission, and the user’s revocation. The world state first records the user’s identityIDUc and public key PKUc, then records the user’s permission value sc, and finally sets the permission value to 0.


## 5. The Proposed Blockchain-Based Hierarchical Authentication Scheme for Multiserver Architecture

### 5.1. Initialization Phase

At the initialization of the system, a blockchain network is established. The blockchain network chooses an elliptic curveE over the finite field Fp: y2=x3+ax+b, where p(>2160) is a large prime number. The point P is an element with large prime order q(>2160) on the additive group G on E. Then, it chooses the following hash function h1: 0,1∗⟶0,1l1,h20,1∗⟶0,1l2, where l1,l2 are the bit length of the hash function’s output. Then, it exposes Fp,E,G,P,p,q,h1,h2.


### 5.2. Server Registration Phase

The server registration phase is as follows, and the main steps are provided in Table2.Table 2
Server registration phase.
SjBlockchain networkSKsj←$Zq∗,PKsj=SKsj·PSIGsj=SigSKsj,IDsj‖PKsj，⟶SIGsj,IDsj,PKsjVerifiesVerPKsj,SIGsj,IDsj‖PKsj=?true if holds, stores: IDSj,PKsj←SuccessStores:SKsjStep 1.
The serverSj chooses the identity IDSj, selects a random number SKsj←$Zq∗ as the private key, and then calculates its public key PKsj=SKsj·P. The server uses the private key to sign the message IDSj‖PKsj: SIGsj=SigSKsj,IDsj‖PKsj. Then, the server commits a transaction proposal to the blockchain network. The transaction content is SIGsj,IDSj,PKsj.Step 2.
The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies the signatureVerPKsj,SIGsj,IDsj‖PKsj=?true; if it does not hold, the endorser node refuses to endorse this transaction; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the data IDSj,PKsj are stored in the blockchain.Step 3.
After receiving that the notification of the transaction is successful, the server saves theSKsj. The server registration phase is complete.


### 5.3. User Registration Phase

Users need to register at the registration terminal offline and get his or her smart card. The user registration phase is as follows, and the main steps are provided in Table3:(i)
Step 1. User Ui enters the identity IDUi. The registration terminal selects a random number SKUi←$Zq∗ as the user’s private key. Then, it calculates the public key PKUi=SKUi·P, signs the message IDUi‖PKUi: SIGUi=SigSKUi,IDUi‖PKUi. The registration terminal packages SIGUi,IDUi,PKUi as the transaction content and commits the transaction proposal to the blockchain network.(ii)
Step 2. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies VerPKUi,SIGUi,IDUi‖PKUi=?true; if it does not hold, the endorser node refuses to endorse this transaction; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the data IDUi,PKUi are stored in the blockchain and the registration terminal receives a notification of successful transaction.(iii)
Step 3. After the registration terminal prompted that the registration is succeed, the user Ui enters the password PWi, the biometric information ωi. The registration terminal runs the fuzzy-extractor generation algorithm on the input biometric information ωi to get Ri,BPi←Genωi. Then, it calculates Ai=SKUi⊕h1PWi‖Ri, Bi=h1h1IDUi+h1PWi‖Rimodn0, where n0 is a medium integer (as defined in [30]) which determines the capacity of the pool of the pair IDUi,PWi,Ri against online guessing. Finally, the registration terminal saves Ai,Bi,BPi in the smart card. The user registration phase is complete.Table 3
User registration phase.
UiBlockchain networkSKUi←$Zq∗,PKUi=SKUi·PSIGUi=SigSKUi,IDUi‖PKUi⟶SIGUi,IDUi,PKUiVerifiesVerPKUi,SIGUi,IDUi‖PKUi=?true if holds, stores: IDUi,PKUi←SuccessRi,BPi←GenωiAi=SKUi⊕h1PWi‖RiBi=h1h1IDUi+h1PWi‖Rimodn0Stores: Ai,Bi,BPi in the smart card


### 5.4. Hierarchical Access Control Method

In order to provide hierarchical access control function and reduce the consumption of storage on the server side, we propose a lightweight hash-based hierarchical access control method based on the blockchain. After a user completing registration, the user needs to request the corresponding permission from the permission server. Only the user’s permission level is higher than the permission level of the application server can access that application server. In our scheme, it is the authority agency that manages the permission server. In practical applications, the authority agency can be the controller of a multiserver system.The proposed hierarchical access control method is as follows.


#### 5.4.1. Initialization of Permission

(i)
Step 1. The permission server sets a total of max levels of hierarchical access permission.(ii)
Step 2. The permission server takes a random number d and then publishes d.(iii)
Step 3. The permission server takes max random numbers a1,a2,…,amax as the permission keys.(iv)
Step 4. The permission server sets the access permission of the application server Sj is level Lj (1≤Lj≤max).(v)
Step 5. The permission server sends aLj,aLj+1,…,amax to the application server Sj which access permission level is Lj in a secure channel. The permission key array in the application server of each level is listed in Table 4.Table 4
The permission key array in the application server of each level.
The level of the application serverPermission key arraymaxamaxmax−1amax−1,amaxmax−2amax−2,amax−1,amax……2a2,…,amax−2,amax−1,amax1a1,a2,…,amax−2,amax−1,amax


#### 5.4.2. Granting Access Permission Phase

The user presents his or her personal information to the permission server through the registration terminal to request an access permission level, which is performed in a secure channel. The main steps are provided in Table5:(i)
Step 1. The user Ui inserts the smart card and enters IDUi, PWi, and biometric information ωi′ on the registration terminal. The registration terminal uses the fuzzy-extractor recovery algorithm to get Ri′←Repωi′,BPi and calculate Bi′=h1h1IDUi+h1PWi‖Ri′modn0. If Bi′=Bi, the preliminary verification passes and the smart card outputs Ai; otherwise, the smart card rejects the current login request. Then, the user inputs personal information Ii. The registration terminal calculates SKUi=Ai⊕h1PWi‖Ri′, PKUi=SKUi·P, signs personal information Ii: SIGIUi=SigSKUi,Ii, and sends the message SIGIUi,IDUi,Ii to the permission server.(ii)
Step 2. After receiving the message, the permission server queries the user’s public key PKUi according to the user’s identity IDUi from blockchain network, verifies the signature VerPKUi,SIGIUi,Ii=?true, and rejects the session if the verification fails; otherwise, the permission server gives the user permission level Li according to the user’s personal information Ii and then takes a random number ei to calculate si=h1d‖h1ei‖aLi. Finally, the permission server signs IDUi‖si with its own private key SKPr: SIGPr=SigSKPr,IDUi‖si. The permission server packages PKPr,SIGPr,IDUi,si as the transaction content and commits the transaction proposal to the blockchain network.(iii)
Step 3. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies the signature SIGPr: VerPKPr,SIGPr,IDUi‖si=?true, and it refuses to endorse this transaction if the signature is not legal; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the blockchain stores IDUi,si.(iv)
Step 4. After receiving a notification that the transaction is successful, the permission server saves IDUi,Ii and sends Li,ei to the registration terminal.(v)
Step 5. After receiving Li,ei, the registration terminal writes Li,ei into the smart card.Table 5
Granting access permission phase.
UiPermission serverBlockchain networkRi′←Repωi′,BPiBi′=h1h1IDUi+h1PWi‖Ri′modn0 Verifies Bi′=?Bi, if holds, outputs AiSKUi=Ai⊕h1PWi‖Ri′PKUi=SKUi·PSIGIUi=SigSKUi,Ii⟶SIGIUi,IDUi,IiVerifiesVerPKUi,SIGIUi,Ii=?true if holds: si=h1d‖h1ei‖aLiSIGPr=SigSKPr,IDUi‖si⟶PKPr,SIGPr,IDUi,siVerifiesVerPKPr,SIGPr,IDUi‖si=?true if holds: stores: IDUi,si←SuccessStores:IDUi,Ii←Li,eiStores:Li,ei in the smart card


### 5.5. Authentication Phase

In this phase, a remote user and an application server have reached mutual authentication and key agreement. The main steps are provided in Table6:(i)
Step 1. The user Ui inserts the smart card and enters IDUi, PWi, and biometric information ωi′ on the client. The client uses the fuzzy-extractor recovery algorithm to get Ri′←Repωi′,BPi to calculate Bi′=h1h1IDUi+h1PWi‖Ri′modn0, and if Bi′=Bi, the preliminary verification passes and the smart card outputs Ai,Li,ei; otherwise, the smart card rejects the current login request. Then, the client calculates SKUi=Ai⊕h1PWi‖Ri′ and PKUi=SKUi·P and takes a random number x←$Zq∗. The client calculates X=x·P, SID=X‖IDUieiLi⊕h2x·SKSj, and then sends X,SID to the application server.(ii)
Step 2. The application server Sj calculates X‖IDUieiLi=SID⊕h2SKSj⋅X to get X,IDUi,ei,Li and queries the blockchain node to get the information PKUi,si corresponding to IDUi. The operation of querying data on the blockchain can be performed through a smart contract [31], which is called the chaincode in Fabric. Then, the access permission verification process begins as follows:(1)
The application server finds whether theaLi exists in its permission key array, and if it does not exist, the application server rejects the user’s authentication request.(2)
The application server calculatessi′=h1d‖h1ei‖aLi and then verifies whether si′ is equal to si. If not, the application server rejects the user’s authentication request.(3)
The application server completes the access permission verification process and continues the authentication phase.The application server takes a random numbery←$Zq∗ and calculate Y=y·P, TKSj=SKSj+y·PKUi+X, AUTHSj=h1TKSj‖X‖YIDUiIDSj. After that, the application server sends Y,AUTHSj to the client.(iii)
Step 3. After receiving the massages, the client calculates TKUi=SKUi+x·PKSj+Y, AUTHUi=h1TKUi‖X‖YIDUiIDSj and checks whether AUTHUi and the received AUTHSj are equal. If they are equal, Ui confirms that Sj is legitimate. If not equal, the client stops the session. The client calculates KEY=h1TKUi‖X‖Y‖AUTHUi and MUi=h1KEY‖X‖YIDUiIDSj. The client sends MUi to the application server.(iv)
Step 4. The application server calculates KEY=h1TKSj‖X‖Y‖AUTHSj and MSj=h1KEY‖X‖YIDUiIDSj. The application server checks whether MSj and the received MUi are equal. If they are equal, Sj confirms that Ui is legitimate and a session key KEY is negotiated by Ui and Sj. If they are not equal, the application server stops the session.Table 6
Authentication phase.
UiSjRi′←Repωi′,BPiBi′=h1h1IDUi+h1PWi‖Ri′modn0 verifies Bi′=?Bi, if holds, outputs Ai,Li,eiSKUi=Ai⊕h1PWi‖Ri′PKUi=SKUi·Px←$Zq∗, X=x·PSID=X‖IDUi‖ei‖Li⊕h2x·SKSj⟶X,SIDX‖IDUi‖ei‖Li=SID⊕h2SKSj⋅Xsi′=h1d‖h1ei‖aLi verifies si′=?si if holds, y←$Zq∗, Y=y·PTKSj=SKSj+y·PKUi+XAUTHSj=h1TKSj‖X‖Y‖IDUi‖IDSj←Y,AUTHSjTKUi=SKUi+x·PKSj+YAUTHUi=h1TKUi‖X‖YIDUiIDSj Verifies AUTHUi=?AUTHSj if holds: KEY=h1TKUi‖X‖Y‖AUTHUiMUi=h1KEY‖X‖YIDUiIDSj⟶MUiKEY=h1TKSj‖X‖Y‖AUTHSjMSj=h1KEY‖X‖YIDUiIDSj verifies MUi=?MSj if it holds, accepts the session key KEY


### 5.6. User Revocation Phase

When the smart card is lost or stolen, in order to prevent fraudulent use of the original account, the user needs to cancel all permissions of his account and then applies for a new account. The user reregistration phase is the same as the initial user registration phase. The user revocation phase is described as follows:(i)
Step 1. The user sends a revocation request to the permission server offline with his or her identity IDUi and personal information Ii.(ii)
Step 2. After receiving the message, the permission server verifies the user’s personal information. If the user is confirmed to be the owner of the IDUi, the permission server signs message IDUi,si′ where si′=0, SIGPr=SigSKPr,IDUi‖si′. Then, the permission server packages SIGPr,IDUi,si′ as the transaction content and commits the transaction proposal to the blockchain network.(iii)
Step 3. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation or not. The endorser node rejects this transaction if it does not. Otherwise, the endorser node verifies the signature SIGPr: VerPKPr,SIGPr,IDUi‖si′=?true, and the endorser node will refuse to endorse this transaction if the signature is not legal; otherwise, the transaction will be processed as we described in Section 4.2.1. Finally, the blockchain stores IDUi,si′, where si′=0


## 5.1. Initialization Phase

At the initialization of the system, a blockchain network is established. The blockchain network chooses an elliptic curveE over the finite field Fp: y2=x3+ax+b, where p(>2160) is a large prime number. The point P is an element with large prime order q(>2160) on the additive group G on E. Then, it chooses the following hash function h1: 0,1∗⟶0,1l1,h20,1∗⟶0,1l2, where l1,l2 are the bit length of the hash function’s output. Then, it exposes Fp,E,G,P,p,q,h1,h2.


## 5.2. Server Registration Phase

The server registration phase is as follows, and the main steps are provided in Table2.Table 2
Server registration phase.
SjBlockchain networkSKsj←$Zq∗,PKsj=SKsj·PSIGsj=SigSKsj,IDsj‖PKsj，⟶SIGsj,IDsj,PKsjVerifiesVerPKsj,SIGsj,IDsj‖PKsj=?true if holds, stores: IDSj,PKsj←SuccessStores:SKsjStep 1.
The serverSj chooses the identity IDSj, selects a random number SKsj←$Zq∗ as the private key, and then calculates its public key PKsj=SKsj·P. The server uses the private key to sign the message IDSj‖PKsj: SIGsj=SigSKsj,IDsj‖PKsj. Then, the server commits a transaction proposal to the blockchain network. The transaction content is SIGsj,IDSj,PKsj.Step 2.
The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies the signatureVerPKsj,SIGsj,IDsj‖PKsj=?true; if it does not hold, the endorser node refuses to endorse this transaction; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the data IDSj,PKsj are stored in the blockchain.Step 3.
After receiving that the notification of the transaction is successful, the server saves theSKsj. The server registration phase is complete.


## 5.3. User Registration Phase

Users need to register at the registration terminal offline and get his or her smart card. The user registration phase is as follows, and the main steps are provided in Table3:(i)
Step 1. User Ui enters the identity IDUi. The registration terminal selects a random number SKUi←$Zq∗ as the user’s private key. Then, it calculates the public key PKUi=SKUi·P, signs the message IDUi‖PKUi: SIGUi=SigSKUi,IDUi‖PKUi. The registration terminal packages SIGUi,IDUi,PKUi as the transaction content and commits the transaction proposal to the blockchain network.(ii)
Step 2. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies VerPKUi,SIGUi,IDUi‖PKUi=?true; if it does not hold, the endorser node refuses to endorse this transaction; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the data IDUi,PKUi are stored in the blockchain and the registration terminal receives a notification of successful transaction.(iii)
Step 3. After the registration terminal prompted that the registration is succeed, the user Ui enters the password PWi, the biometric information ωi. The registration terminal runs the fuzzy-extractor generation algorithm on the input biometric information ωi to get Ri,BPi←Genωi. Then, it calculates Ai=SKUi⊕h1PWi‖Ri, Bi=h1h1IDUi+h1PWi‖Rimodn0, where n0 is a medium integer (as defined in [30]) which determines the capacity of the pool of the pair IDUi,PWi,Ri against online guessing. Finally, the registration terminal saves Ai,Bi,BPi in the smart card. The user registration phase is complete.Table 3
User registration phase.
UiBlockchain networkSKUi←$Zq∗,PKUi=SKUi·PSIGUi=SigSKUi,IDUi‖PKUi⟶SIGUi,IDUi,PKUiVerifiesVerPKUi,SIGUi,IDUi‖PKUi=?true if holds, stores: IDUi,PKUi←SuccessRi,BPi←GenωiAi=SKUi⊕h1PWi‖RiBi=h1h1IDUi+h1PWi‖Rimodn0Stores: Ai,Bi,BPi in the smart card


## 5.4. Hierarchical Access Control Method

In order to provide hierarchical access control function and reduce the consumption of storage on the server side, we propose a lightweight hash-based hierarchical access control method based on the blockchain. After a user completing registration, the user needs to request the corresponding permission from the permission server. Only the user’s permission level is higher than the permission level of the application server can access that application server. In our scheme, it is the authority agency that manages the permission server. In practical applications, the authority agency can be the controller of a multiserver system.The proposed hierarchical access control method is as follows.


### 5.4.1. Initialization of Permission

(i)
Step 1. The permission server sets a total of max levels of hierarchical access permission.(ii)
Step 2. The permission server takes a random number d and then publishes d.(iii)
Step 3. The permission server takes max random numbers a1,a2,…,amax as the permission keys.(iv)
Step 4. The permission server sets the access permission of the application server Sj is level Lj (1≤Lj≤max).(v)
Step 5. The permission server sends aLj,aLj+1,…,amax to the application server Sj which access permission level is Lj in a secure channel. The permission key array in the application server of each level is listed in Table 4.Table 4
The permission key array in the application server of each level.
The level of the application serverPermission key arraymaxamaxmax−1amax−1,amaxmax−2amax−2,amax−1,amax……2a2,…,amax−2,amax−1,amax1a1,a2,…,amax−2,amax−1,amax


### 5.4.2. Granting Access Permission Phase

The user presents his or her personal information to the permission server through the registration terminal to request an access permission level, which is performed in a secure channel. The main steps are provided in Table5:(i)
Step 1. The user Ui inserts the smart card and enters IDUi, PWi, and biometric information ωi′ on the registration terminal. The registration terminal uses the fuzzy-extractor recovery algorithm to get Ri′←Repωi′,BPi and calculate Bi′=h1h1IDUi+h1PWi‖Ri′modn0. If Bi′=Bi, the preliminary verification passes and the smart card outputs Ai; otherwise, the smart card rejects the current login request. Then, the user inputs personal information Ii. The registration terminal calculates SKUi=Ai⊕h1PWi‖Ri′, PKUi=SKUi·P, signs personal information Ii: SIGIUi=SigSKUi,Ii, and sends the message SIGIUi,IDUi,Ii to the permission server.(ii)
Step 2. After receiving the message, the permission server queries the user’s public key PKUi according to the user’s identity IDUi from blockchain network, verifies the signature VerPKUi,SIGIUi,Ii=?true, and rejects the session if the verification fails; otherwise, the permission server gives the user permission level Li according to the user’s personal information Ii and then takes a random number ei to calculate si=h1d‖h1ei‖aLi. Finally, the permission server signs IDUi‖si with its own private key SKPr: SIGPr=SigSKPr,IDUi‖si. The permission server packages PKPr,SIGPr,IDUi,si as the transaction content and commits the transaction proposal to the blockchain network.(iii)
Step 3. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies the signature SIGPr: VerPKPr,SIGPr,IDUi‖si=?true, and it refuses to endorse this transaction if the signature is not legal; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the blockchain stores IDUi,si.(iv)
Step 4. After receiving a notification that the transaction is successful, the permission server saves IDUi,Ii and sends Li,ei to the registration terminal.(v)
Step 5. After receiving Li,ei, the registration terminal writes Li,ei into the smart card.Table 5
Granting access permission phase.
UiPermission serverBlockchain networkRi′←Repωi′,BPiBi′=h1h1IDUi+h1PWi‖Ri′modn0 Verifies Bi′=?Bi, if holds, outputs AiSKUi=Ai⊕h1PWi‖Ri′PKUi=SKUi·PSIGIUi=SigSKUi,Ii⟶SIGIUi,IDUi,IiVerifiesVerPKUi,SIGIUi,Ii=?true if holds: si=h1d‖h1ei‖aLiSIGPr=SigSKPr,IDUi‖si⟶PKPr,SIGPr,IDUi,siVerifiesVerPKPr,SIGPr,IDUi‖si=?true if holds: stores: IDUi,si←SuccessStores:IDUi,Ii←Li,eiStores:Li,ei in the smart card


## 5.4.1. Initialization of Permission

(i)
Step 1. The permission server sets a total of max levels of hierarchical access permission.(ii)
Step 2. The permission server takes a random number d and then publishes d.(iii)
Step 3. The permission server takes max random numbers a1,a2,…,amax as the permission keys.(iv)
Step 4. The permission server sets the access permission of the application server Sj is level Lj (1≤Lj≤max).(v)
Step 5. The permission server sends aLj,aLj+1,…,amax to the application server Sj which access permission level is Lj in a secure channel. The permission key array in the application server of each level is listed in Table 4.Table 4
The permission key array in the application server of each level.
The level of the application serverPermission key arraymaxamaxmax−1amax−1,amaxmax−2amax−2,amax−1,amax……2a2,…,amax−2,amax−1,amax1a1,a2,…,amax−2,amax−1,amax


## 5.4.2. Granting Access Permission Phase

The user presents his or her personal information to the permission server through the registration terminal to request an access permission level, which is performed in a secure channel. The main steps are provided in Table5:(i)
Step 1. The user Ui inserts the smart card and enters IDUi, PWi, and biometric information ωi′ on the registration terminal. The registration terminal uses the fuzzy-extractor recovery algorithm to get Ri′←Repωi′,BPi and calculate Bi′=h1h1IDUi+h1PWi‖Ri′modn0. If Bi′=Bi, the preliminary verification passes and the smart card outputs Ai; otherwise, the smart card rejects the current login request. Then, the user inputs personal information Ii. The registration terminal calculates SKUi=Ai⊕h1PWi‖Ri′, PKUi=SKUi·P, signs personal information Ii: SIGIUi=SigSKUi,Ii, and sends the message SIGIUi,IDUi,Ii to the permission server.(ii)
Step 2. After receiving the message, the permission server queries the user’s public key PKUi according to the user’s identity IDUi from blockchain network, verifies the signature VerPKUi,SIGIUi,Ii=?true, and rejects the session if the verification fails; otherwise, the permission server gives the user permission level Li according to the user’s personal information Ii and then takes a random number ei to calculate si=h1d‖h1ei‖aLi. Finally, the permission server signs IDUi‖si with its own private key SKPr: SIGPr=SigSKPr,IDUi‖si. The permission server packages PKPr,SIGPr,IDUi,si as the transaction content and commits the transaction proposal to the blockchain network.(iii)
Step 3. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies the signature SIGPr: VerPKPr,SIGPr,IDUi‖si=?true, and it refuses to endorse this transaction if the signature is not legal; otherwise, the transaction is processed according to the transaction process we described in Section 4.2.1. Finally, the blockchain stores IDUi,si.(iv)
Step 4. After receiving a notification that the transaction is successful, the permission server saves IDUi,Ii and sends Li,ei to the registration terminal.(v)
Step 5. After receiving Li,ei, the registration terminal writes Li,ei into the smart card.Table 5
Granting access permission phase.
UiPermission serverBlockchain networkRi′←Repωi′,BPiBi′=h1h1IDUi+h1PWi‖Ri′modn0 Verifies Bi′=?Bi, if holds, outputs AiSKUi=Ai⊕h1PWi‖Ri′PKUi=SKUi·PSIGIUi=SigSKUi,Ii⟶SIGIUi,IDUi,IiVerifiesVerPKUi,SIGIUi,Ii=?true if holds: si=h1d‖h1ei‖aLiSIGPr=SigSKPr,IDUi‖si⟶PKPr,SIGPr,IDUi,siVerifiesVerPKPr,SIGPr,IDUi‖si=?true if holds: stores: IDUi,si←SuccessStores:IDUi,Ii←Li,eiStores:Li,ei in the smart card


## 5.5. Authentication Phase

In this phase, a remote user and an application server have reached mutual authentication and key agreement. The main steps are provided in Table6:(i)
Step 1. The user Ui inserts the smart card and enters IDUi, PWi, and biometric information ωi′ on the client. The client uses the fuzzy-extractor recovery algorithm to get Ri′←Repωi′,BPi to calculate Bi′=h1h1IDUi+h1PWi‖Ri′modn0, and if Bi′=Bi, the preliminary verification passes and the smart card outputs Ai,Li,ei; otherwise, the smart card rejects the current login request. Then, the client calculates SKUi=Ai⊕h1PWi‖Ri′ and PKUi=SKUi·P and takes a random number x←$Zq∗. The client calculates X=x·P, SID=X‖IDUieiLi⊕h2x·SKSj, and then sends X,SID to the application server.(ii)
Step 2. The application server Sj calculates X‖IDUieiLi=SID⊕h2SKSj⋅X to get X,IDUi,ei,Li and queries the blockchain node to get the information PKUi,si corresponding to IDUi. The operation of querying data on the blockchain can be performed through a smart contract [31], which is called the chaincode in Fabric. Then, the access permission verification process begins as follows:(1)
The application server finds whether theaLi exists in its permission key array, and if it does not exist, the application server rejects the user’s authentication request.(2)
The application server calculatessi′=h1d‖h1ei‖aLi and then verifies whether si′ is equal to si. If not, the application server rejects the user’s authentication request.(3)
The application server completes the access permission verification process and continues the authentication phase.The application server takes a random numbery←$Zq∗ and calculate Y=y·P, TKSj=SKSj+y·PKUi+X, AUTHSj=h1TKSj‖X‖YIDUiIDSj. After that, the application server sends Y,AUTHSj to the client.(iii)
Step 3. After receiving the massages, the client calculates TKUi=SKUi+x·PKSj+Y, AUTHUi=h1TKUi‖X‖YIDUiIDSj and checks whether AUTHUi and the received AUTHSj are equal. If they are equal, Ui confirms that Sj is legitimate. If not equal, the client stops the session. The client calculates KEY=h1TKUi‖X‖Y‖AUTHUi and MUi=h1KEY‖X‖YIDUiIDSj. The client sends MUi to the application server.(iv)
Step 4. The application server calculates KEY=h1TKSj‖X‖Y‖AUTHSj and MSj=h1KEY‖X‖YIDUiIDSj. The application server checks whether MSj and the received MUi are equal. If they are equal, Sj confirms that Ui is legitimate and a session key KEY is negotiated by Ui and Sj. If they are not equal, the application server stops the session.Table 6
Authentication phase.
UiSjRi′←Repωi′,BPiBi′=h1h1IDUi+h1PWi‖Ri′modn0 verifies Bi′=?Bi, if holds, outputs Ai,Li,eiSKUi=Ai⊕h1PWi‖Ri′PKUi=SKUi·Px←$Zq∗, X=x·PSID=X‖IDUi‖ei‖Li⊕h2x·SKSj⟶X,SIDX‖IDUi‖ei‖Li=SID⊕h2SKSj⋅Xsi′=h1d‖h1ei‖aLi verifies si′=?si if holds, y←$Zq∗, Y=y·PTKSj=SKSj+y·PKUi+XAUTHSj=h1TKSj‖X‖Y‖IDUi‖IDSj←Y,AUTHSjTKUi=SKUi+x·PKSj+YAUTHUi=h1TKUi‖X‖YIDUiIDSj Verifies AUTHUi=?AUTHSj if holds: KEY=h1TKUi‖X‖Y‖AUTHUiMUi=h1KEY‖X‖YIDUiIDSj⟶MUiKEY=h1TKSj‖X‖Y‖AUTHSjMSj=h1KEY‖X‖YIDUiIDSj verifies MUi=?MSj if it holds, accepts the session key KEY


## 5.6. User Revocation Phase

When the smart card is lost or stolen, in order to prevent fraudulent use of the original account, the user needs to cancel all permissions of his account and then applies for a new account. The user reregistration phase is the same as the initial user registration phase. The user revocation phase is described as follows:(i)
Step 1. The user sends a revocation request to the permission server offline with his or her identity IDUi and personal information Ii.(ii)
Step 2. After receiving the message, the permission server verifies the user’s personal information. If the user is confirmed to be the owner of the IDUi, the permission server signs message IDUi,si′ where si′=0, SIGPr=SigSKPr,IDUi‖si′. Then, the permission server packages SIGPr,IDUi,si′ as the transaction content and commits the transaction proposal to the blockchain network.(iii)
Step 3. The blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation or not. The endorser node rejects this transaction if it does not. Otherwise, the endorser node verifies the signature SIGPr: VerPKPr,SIGPr,IDUi‖si′=?true, and the endorser node will refuse to endorse this transaction if the signature is not legal; otherwise, the transaction will be processed as we described in Section 4.2.1. Finally, the blockchain stores IDUi,si′, where si′=0


## 6. Security Analysis

In our scheme, the user revocation phase is carried out in a secure channel, and the registration phase uses the ECDSA algorithm to submit the identity and public keyID,PK to the blockchain, and we assume that the security of the blockchain system is guaranteed by the consensus algorithm; thus, we mainly analyze the security of the authentication phase. In this section, we demonstrate the security of our scheme from three aspects: the security of client-to-server authentication, the security of server-to-client authentication, and the security of session key agreement. In this section, first we construct a security model for authentication and key agreement in a multiserver environment without the registration center, then we make a formal proof of the security of our scheme, and finally we make some discussions on the security of our scheme.


### 6.1. Security Model

Based on the literature studies [2, 8, 11, 32], we construct a security model for the authentication and key agreement scheme in the multiserver environment without the registration center. In our security model, the game of polynomial-time adversary A and polynomial-time challenger ℬ defines the security of our scheme. Referring to the literature [32], we define that A has the following capabilities:(i)
The adversaryA can enumerate offline all the items in the Cartesian product Did∗Dpw∗Db within polynomial time, where Did denotes the identity space, Dpw denotes the password space, and Db denotes the biometric key space.(ii)
The adversaryA has the capability of somehow learning the victim’s identity when evaluating security strength (but not privacy provisions) of our scheme.(iii)
The adversaryA has full control over the communication channels between participants.(iv)
The adversaryA can intercept the password of a legitimate user, or extract secret parameters from a smart card by side-channel attacks, or obtain biometric information of a legitimate user through a special device, but it cannot do all three at the same time.(v)
The adversaryA can learn session keys of previous sessions.(vi)
When evaluating the security of mutual authentication, the adversaryA can obtain the private key of the authenticating party but cannot obtain its temporary session secret in the current session, while A cannot obtain the private key of the authenticated party but can arbitrarily select its temporary session secret in the current session.(vii)
The adversaryA is able to obtain the private keys of both the user and the server only when evaluating the resistance to eventual failing of the system (e.g., forward secrecy).The adversaryA can issue queries to the challenger ℬ and get answers from ℬ. We define the following rules of the game:System building phase:ℬ runs the system building algorithm, initializes the public parameters and hash functions, and then exposes them to the public. Meanwhile, ℬ maintains some lists during the entire process of interacting with A which are empty at the beginning.(1)
Hash(str): A issues query any string and ℬ returns the corresponding hash values and guarantees that the same queries get the same values.(2)
ExtractUIDUi: ℬ maintains a list LU. When A issues queries of the user’s identity IDUi: if IDUi exists in LU, ℬ returns the corresponding public key; otherwise, ℬ randomly generates the user’s public and private key pairs and stores them in LU, and then it returns the public key.(3)
ExtractSIDSj: ℬ maintains a list LS. When A issues queries of application server’s identity IDSj: if IDSj exists in LS, ℬ returns the corresponding public key; otherwise, ℬ randomly generates application server’s public and private key pairs and stores them in LS, and then it returns the public key.(4)
Send∏i,jt,m: A sends a message to ℬ, which belongs to the tth session of the user Ui and the server Sj. ℬ receives the message and processes the message according to our scheme and returns the corresponding result.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. ℬ will return Ui’s private key SKUi to A from the list LU.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application server Sj’s private key. ℬ will return Sj’s private key SKSj to A from the list LS.(7)
Reveal∏i,jt: A issues query for the session key of the session ∏i,jt, and ℬ returns the session key generated by the session ∏i,jt.


#### 6.1.1. Issue Query Phase

After issuing the queries above, the adversaryA begins the challenge phase: A initiates a session key guess for session ∏i,jt. If A has never sent Reveal ∏i,jt query, challenger ℬ randomly flips a coin to obtain b∈0,1. If b=1, the challenger ℬ outputs the session key of the session ∏i,jt. If b=0, ℬ outputs a random number which length is equal to that of the session key of the session ∏i,jt. A guesses the value of b and outputs b′. If b=b′, we consider that A wins the game. We define the advantage of A winning the game as(1)AdvAKAA=PrAb=b′−12.Definition 1.
AKA-Secure: our scheme is authentication key agreement secure (AKA-Secure) ifAdvAKAA is negligible for any polynomial-time adversary A.IfA can forge the authentication message sent by the legitimate user to the legitimate server, or the response message sent by the legitimate server to the legitimate user, then our scheme is considered insecure. Defining the event AUi⟶Sj as A can successfully forge the authentication message sent by the legitimate user Ui to the legitimate server Sj. Defining the event ASj⟶Ui as A can successfully forge the response message sent by the legitimate server Sj to the legitimate user Ui, then we can define the advantage of A attacking the mutual authentication game as(2)AdvMAA=PrAUi⟶Sj+PrASj⟶Ui.Definition 2.
MA-Secure: our scheme is mutual authentication secure (MA-Secure) ifAdvMAA is negligible for any polynomial-time adversary A.


### 6.2. Proof of Security

In this part, we will show our scheme is AKA-secure and MA-secure in the security model we described above.Lemma 1.
No polynomial-time adversaryA can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.ProofSuppose that a polynomial-time adversaryA can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability, then the challenger ℬ can solve an instance of the ECCDH problem by a nonnegligible advantage. Given an instance of the ECCDH problem, we assume that A eventually chooses to forge the authentication message sent by the legitimate user Uc to the legitimate server Sd as a challenge, and the objective of challenger ℬ is to compute SKUc⋅y⋅P as SKUc,y are unknown elements in Zq∗, where PKUc=SKUc⋅P, Y=y⋅P, and PKUc,Y,P∈G. In the following, we will demonstrate how ℬ can solve the ECCDH problem by exploiting the adversary A.ℬ runs the system building algorithm: ℬ initializes the public parameters and hash function params=Fp,E,G,P,p,q,h1,h2 and sends them to A. Meanwhile, ℬ maintains several lists LH,LU,LS, which are empty at the beginning. Then, A makes the following queries:(1)
Hashnstr:ℬ maintains a list LHn=str,hnstr, which is empty at the beginning. After receiving the query Hashnstr from A, ℬ checks whether str,hnstr exists in the list LHn. If it exists, ℬ returns the corresponding value hnstr; otherwise, ℬ takes a random number hnstr, stores str,hnstr in LHn, and finally returns hnstr to A.(2)
Extract UIDUi: ℬ maintains a list LU=IDUi,SKUi,PKUi. After receiving the query ExtractU IDUi from A, ℬ checks whether IDUi,SKUi,PKUi exists in LU or not. If it exists, ℬ returns PKUi to A. Otherwise, ℬ executes the operations as follows:(i)
Ifi≠c, ℬ takes SKUi←$ℤq∗ as the private key of Ui and calculates the public key PKUi=SKUi·P, then stores IDUi,SKUi,PKUi into the list LU, finally returns PKUi to A.(ii)
Ifi=c, ℬ takes PKUc←$G as the public key of Uc and sets the private key SKUc to ⊥ (which means an unknown value), then stores IDUc,SKUc,PKUc into the list LU, finally returns PKUc to A.(3)
ExtractSIDSj: ℬ maintains a list LS=IDSj,SKSj,PKSj. After receiving the query ExtractS IDSj from A, ℬ checks whether IDSj,SKSj,PKSj exists in LS, if it exists, ℬ returns PKSj to A. Otherwise, ℬ takes SKSj←$ℤq∗ as the private key of Sj, then calculates the public key PKSj=SKSj·P, then stores IDSj,SKSj,PKSj into the list LS, and returns PKSj to A.(4)
Send∏i,jt,m: A sends a message m belonging to the session ∏i,jt to ℬ. ℬ processes the message m according to the following rules:(i)
If∏i,jt≠∏c,dt, ℬ processes the received message according to our scheme and sends the result to A.(ii)
If∏i,jt=∏c,dt and m=‘begin’, ℬ picks a random number x←$Zq∗, calculates X=x·P, SID=X‖IDUc‖ei‖Li⊕h2x·PKSd, and sends x,X,SID to A.(iii)
If∏i,jt=∏c,dt and m=X,SID, ℬ calculates X‖IDUc‖ei‖Li=SID⊕h2SKSd·X, picks a random point Y←$G, sets y to ⊥ (which means an unknown value), and sends Y to A.(iv)
If∏i,jt=∏c,dt and m=Y,AUTHSd, ℬ aborts the game.(v)
If∏i,jt=∏c,dt and m=MUc, ℬ aborts the game.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. If i=c, ℬ aborts the game; otherwise ℬ searches for Ui’s private key SKUi in the list LU and returns SKUi to A.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application. ℬ searches for Sj’s private key SKSj in the list LS and returns SKSj to A.(7)
Reveal (∏i,jt): A issues query for the session key of the session ∏i,jt. If ∏i,jt=∏c,dt, ℬ aborts the game; otherwise, ℬ returns the session key generated by the session ∏i,jt.According to the above queries, ifA can successfully forge an authentication message sent by the legitimate user Uc to the legitimate server Sd, it means that A can output MUc belonging to the session ∏c,dt where MUc=h1KEY‖X‖Y‖IDUc‖IDSd and KEY=h1TKUc‖X‖Y‖AUTHUc. According to the given instance of the ECCDH problem, ℬ can transform the equation(3)TKUc=SKUc+x⋅PKSd+Y,to get(4)SKUc⋅y⋅P=TKUc−SKSd·PKUc−SKSd·X−x·Y,and ℬ gets SKSd,PKUc,X,x,Y by searching the query records and gets TKUc by search the hash-query records with the probability of 1/qh (qh denotes the number of hash-queries). Then, ℬ outputs TKUc−SKSd·PKUc−SKSd·X−x·Y as the solution to the given instance of the ECCDH problem. The probability that ℬ can solve the ECCDH problem is described as follows.We define the eventE1 as ℬ does not abort in any queries. We define the event E2 as A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. Let l denote the number of bits of biometric information, qs denote the number of send-queries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. We use Zipf ’s law [33] to enhance the security of the security model. C’ and s’ are Zipf’s parameters. We can get PrE1≥1−1/qs+1qs and PrE2|E1≥ε, and then we get(5)PrℬwinECCDH=1qh·PrE2∩E1=1qh·PrE2|E1·PrE1≥1qh·1−1qs+1qs⋅ε+maxC’·qss′,qs2l.It implies thatℬ can solve an instance of the ECCDH problem with nonnegligible probability. This is contradicting with the hardness of the ECCDH problem. Therefore, we conclude that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.Lemma 2.
No polynomial-time adversaryA can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability if the ECCDH problem is hard.ProofSuppose that a polynomial-time adversaryA can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability, then the challenger ℬ can solve an instance of the ECCDH problem by a nonnegligible advantage. Given an instance of the ECCDH problem, we assume that A eventually chooses to forge the response message sent by the legitimate server Sd to the legitimate user Uc as a challenge, and the objective of challenger ℬ is to compute SKSd⋅x⋅P as SKSd,x are unknown elements in Zq∗, where PKSd=SKSd⋅P, X=x⋅P, and PKSd,X,P∈G. In the following, we will demonstrate how ℬ can solve the ECCDH problem by exploiting the adversary A.ℬ runs the system building algorithm: ℬ initializes the public parameters and hash function params=Fp,E,G,P,p,q,h1,h2 and sends them to A. Meanwhile, ℬ maintains several lists LH,LU,LS, which are empty at the beginning. Then, A makes the following queries:(1)
Hashnstr: ℬ maintains a list LHn=str,hnstr, which is empty at the beginning. After receiving the query Hashnstr from A, ℬ checks whether str,hnstr exists in the list LHn; if it exists, ℬ returns the corresponding value hnstr; otherwise, ℬ takes a random number hnstr, stores str,hnstr in LHn, and finally returns hnstr to A.(2)
ExtractU(IDUi): ℬ maintains a list LU=IDUi,SKUi,PKUi. After receiving the query ExtractU IDUi from A, ℬ checks whether IDUi,SKUi,PKUi exists in LU; if it exists, ℬ returns PKUi to A. Otherwise, ℬ takes SKUi←$ℤq∗ as the private key of Ui, then calculates the public key PKUi=SKUi·P, then stores IDUi,SKUi,PKUi into the list LU, and returns PKUi to A.(3)
ExtractSIDSj: ℬ maintains a list LS=IDSj,SKSj,PKSj. After receiving the query ExtractS IDSj from A, ℬ checks whether IDSj,SKSj,PKSj exists in LS or not. If it exists, ℬ returns PKSj to A. Otherwise, ℬ executes the operations as follows:(i)
Ifj≠d, ℬ takes SKSj←$ℤq∗ as the private key of Sj and calculates the public key PKSj=SKSj·P, then stores IDSj,SKSj,PKSj into the list LS, finally returns PKSj to A.(ii)
Ifj=d, ℬ takes PKSd←$G as the public key of Sd and sets the private key SKSd to ⊥ (which means an unknown value), then stores IDSd,SKSd,PKSd into the list LS, finally returns PKSd to A.(4)
Send(∏i,jt,m): A sends a message m belonging to the session ∏i,jt to ℬ. ℬ processes the message m according to the following rules:(i)
If∏i,jt≠∏c,dt, ℬ processes the received message according to our scheme and sends the result to A.(ii)
If∏i,jt=∏c,dt and m=’begin’, ℬ picks a random point X←$G, sets x to ⊥ (which means an unknown value), picks a random number SID←$ℋ2, and sends X,SID to A.(iii)
If∏i,jt=∏c,dt and m=X,SID, ℬ picks a random number y←$Zq∗ and calculates Y=y·P, and sends Y,y to A.(iv)
If∏i,jt=∏c,dt and m=Y,AUTHSd, ℬ aborts the game.(v)
If∏i,jt=∏c,dt and m=MUc, ℬ aborts the game.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. ℬ searches for Ui’s private key SKUi in the list LU and returns SKUi to A.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application server Sj’s private key. If j=d, ℬ aborts the game; otherwise, ℬ searches for Sj’s private key SKSj in the list LS and returns SKSj to A.(7)
Reveal∏i,jt: A issues query for the session key of the session ∏i,jt. If ∏i,jt=∏c,dt, ℬ aborts the game; otherwise, ℬ returns the session key generated by the session ∏i,jt.According to the above queries, ifA can successfully forge a response message sent by the legitimate server Sd to the legitimate user Uc, it means that A can output AUTHSd belonging to the session ∏c,dt where AUTHSd=h1TKSdXY‖IDUc‖IDSd. According to the given instance of the ECCDH problem, ℬ can transform the equation(6)TKSd=SKSd+y·PKUc+X,to get(7)SKSd⋅x⋅P=TKSd−SKUc·PKSd−SKUc·Y−y·X,and ℬ gets SKUc,PKSd,X,y,Y by searching the query records and gets TKSd by search the hash-query records with the probability of 1/qh (qh denotes the number of hash-queries). Then, ℬ outputs TKSd−SKUc·PKSd−SKUc·Y−y·X as the solution to the given instance of the ECCDH problem. The probability that ℬ can solve the ECCDH problem is described as follows.Defining the eventE1 as ℬ does not abort in any queries. Defining the event E2 as A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. Let l denote the number of bits of biometric information, qs denote the number of send-queries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. We can get PrE1≥1−1/qs+1qs, PrE2|E1≥ε, and then we get(8)PrℬwinECCDH=1qh⋅PrE2∩E1=1qh⋅PrE2|E1⋅PrE1≥1qh⋅1−1qs+1qs⋅ε.It implies thatℬ can solve an instance of the ECCDH problem with nonnegligible probability. This is contradicting with the hardness of the ECCDH problem. Therefore, we conclude that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.Theorem 1.
Our scheme is MA-secure if the ECCDH problem is hard.ProofAccording to Lemma1 and Lemma 2, we learn that if the ECCDH problem is hard, no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability and no polynomial-time adversary can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability. Therefore, our scheme is MA-secure.Theorem 2.
Our scheme is AKA-secure if the ECCDH problem is hard.ProofIn the proof of Lemma1, we learn if A can successfully forge an authentication message sent by the legitimate user Uc to the legitimate server Sd, it means that A sends MUc belonging to the session ∏c,dt to ℬ, where MUc=h1KEY‖X‖Y‖IDUc‖IDSd. Then, ℬ can get KEY as the session key of the session ∏c,dt from the query records with probability of PrAUi⟶Sj. However, we learn that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard in Lemma 1. Therefore, our scheme is AKA-secure if the ECCDH problem is hard.


### 6.3. Security Requirement Analysis

The research of Wang et al. [34] revealed a variety of security defects that are common in the multiserver architecture, such as no truly multifactor security and temporary information attack. Our scheme takes these security defects into consideration and meets the following security requirements.


#### 6.3.1. User Anonymity

In our scheme, user’s identityIDUi exists in the message SID, MUi, and AUTHSj, where SID=X‖IDUi‖ei‖Li⊕h2x·PKSj, MUi=h1KEY‖X‖Y‖IDUi‖IDsj, and AUTHSj=h1TKSj‖X‖Y‖IDUi‖IDsj. It is impossible for the adversary to get IDUi by inferring SID because X‖IDUi‖ei‖Li is encrypted by h2x·PKSj, and at the same time, because x is an unknown number, based on the difficulty of the ECDL problem, the adversary cannot get the value of x·PKSj. And it is impossible for the adversary to know IDUi by inferring MUi or AUTHSj because of the one-way property of the hash function. Therefore, our scheme can provide user anonymity.


#### 6.3.2. Untraceability

In our scheme, each session generates new random secret valuesx and y. Due to the randomness of x and y, the values of message SID, MUi, and AUTHSj which contain IDUi or IDSj are different in each session and the polynomial-time adversary cannot analyze their interconnection even for the same user and server’s session. Therefore, our scheme can provide untraceability.


#### 6.3.3. Perfect Forward Secrecy

We assume that the adversary obtains the private keys of the userUi and the application server Sj and intercepts the messages X,SID, Y,AUTHSj, MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the temporary session secrets x,y of that session, because the temporary session secrets are deleted immediately after used. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x⋅SKSj+y⋅P, and x,y is unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can provide the perfect forward secrecy.


#### 6.3.4. No Smart Card Lose Attack

According to the definition of the adversary, we assume that the adversary obtains the dataAi and Bi in the user’s smart card by using the side-channel attack. Because we use the fuzzy-verifier techniques [30,32] in the process of recovering the user’s private key through smart card, different input PWi,Ri may output the same Bi′, where Bi′=h1IDUi+hPWi‖Rimodn0. Thus, we suppose that the adversary gets PWi′,Ri′ which makes Bi′=Bi, and then it calculates SKUi′=Ai⊕h1PWi′‖Ri′, and it cannot verify the correctness of SKUi′. Therefore, our scheme can resist the smart card lose attack.


#### 6.3.5. No Stolen Verifier Table Attack

In the stolen verifier table attack, the adversary misuses valued data which are stored at servers’ side such as passwords or other parameters and masquerade as legal users [35]. In our scheme, the blockchain maintains the repository that stores public keys, rather than servers or RC maintain the verifier table. Therefore, our scheme can resist the stolen verifier attack.


#### 6.3.6. Three-Factor Security

In our scheme, user’s passwordPWi, personal biometrics ωi, and the secret data Ai,Bi make up the three-factor security. Based on the constructed security model, the adversary cannot obtain all three of these security factors at the same time. Therefore, we discuss the case where the adversary obtains two security factors:(i)
The adversary obtains both the user’s passwordPWi and the secret data Ai,Bi in the smart card or both the user’s personal biometrics ωi and the secret data Ai,Bi in the smart card: according to the security analysis in Section 6.3.4, we can get the adversary cannot verify the correctness of the user’s private key SKUi′.(ii)
The adversary obtains the user’s personal biometricsωi and the password PWi: the adversary cannot calculate SKUi=Ai⊕h1PWi‖Ri without the secret data Ai in the smart card. Therefore, the adversary cannot obtain the user’s private key SKUi.Therefore, our scheme can provide three-factor security.


#### 6.3.7. Decentralized Registration

In our scheme, users register their accounts on the blockchain network. The blockchain network is composed of multiple nodes, allowing up to one-third of the nodes to be down without affecting the function of the blockchain network.


#### 6.3.8. Decentralized Authentication

In our scheme, participants only need to obtain each other’s public key from any blockchain node to complete mutual authentication and key agreement according to our scheme. According to the distributed feature of blockchain nodes, our scheme will not suffer from the security risks caused by centralization such as the leak of master key or the downtime of the registration center server.


#### 6.3.9. Hierarchical Access Control

In our scheme, the application server needs to verify the access permission of the user before responding to the user login. Then-level application server has the permission key array an,an+1,…,amax−2,amax−1,amax, so it cannot verify the user’s permission whose access permission level is lower than it. If the user wants to impersonate a higher level of access permission, the application server calculates si′=h1d‖h1ei‖aLi, verifies si′=?si, and if it does not hold, the application server rejects the user.


#### 6.3.10. Resistance to User Impersonation Attack

According to the proof of Lemma1, no polynomial-time adversary can forge an authentication message sent by the legitimate user Ui to the legitimate server Sj without the private key SKUi of Ui and the server’s temporary session secret y. The server can find out about the attack by verifying the authentication message sent by the user. Therefore, our scheme can resist the user impersonation attack.


#### 6.3.11. Resistance to Server Spoofing Attack

According to the proof of Lemma2, no polynomial-time adversary can forge a response message sent by the legitimate server Sj to the legitimate user Ui without the private key SKSj of Sj and the user’s temporary session secret x. The user can find out about the attack by verifying the response message sent by the server. Therefore, our scheme can resist the server spoofing attack.


#### 6.3.12. Resistance to Replay Attack

In our scheme, each session generates new random temporary session secretsx and y. We discuss the replay attack in the following two scenarios:(i)
Replay the user’s message: after receiving the message sent by the user, the server will calculateMSj=h1KEY‖X‖Y‖IDUi‖IDsj, where Y is generated by the server based on temporary session secret y, and its value in each session is different. If the adversary replays the user’s message in the previous session X′,SID′ and MUi′, where MUi′=h1KEY′‖X′‖Y′‖IDUi‖IDsj. The application server can determine whether the authentication message belongs to the current session of this server Sj with user Ui by verifying whether MUi is equal to MSj.(ii)
Replay the application server’s message: after receiving the message sent by the server, the user will calculateAUTHUi=h1TKUi‖X‖Y‖IDUi‖IDSj, where x is the temporary session secret, and its value in each session is different. If the adversary replays the server’s message in the previous session Y′,AUTHSj′, where AUTHSj′=h1TKSj′‖X′‖Y′‖IDUi‖IDsj. The client can determine whether the response messages belong to the current session by verifying whether AUTHSj is equal to AUTHUi.Therefore, our scheme can resist the replay attack.


#### 6.3.13. Resistance to Modification Attack

According to the proof of Lemma1 and Lemma 2, no polynomial-time adversary can modify the values of the authentication messages or the response message so as to make the message pass the verification. Therefore, our scheme can resist the modification attack.


#### 6.3.14. Resistance to Temporary Information Attack

We assume that the adversary obtains the temporary session secretsx,y and intercepts the massages X,SID, Y,AUTHSj, and MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the private keys of the user Ui and the application server Sj. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x·SKSj+y·P, and SKUi, SKSj are unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can resist the temporary information attack.


#### 6.3.15. Resistance to Insider Attack

In our scheme, the participant’s private key is generated by itself and does not rely on the registration center, so there is no insider attack.


#### 6.3.16. Resistance to Man-in-the-Middle Attack

As an attack that aims at circumventing mutual authentication, the man-in-the-middle attack can succeed only when the adversary can impersonate each participant to their satisfaction as expected from the legitimate participant. Accounting to the previous security analysis, no adversary can impersonate a legitimate participant in our scheme. Therefore, our scheme can resist the man-in-the-middle attack.


## 6.1. Security Model

Based on the literature studies [2, 8, 11, 32], we construct a security model for the authentication and key agreement scheme in the multiserver environment without the registration center. In our security model, the game of polynomial-time adversary A and polynomial-time challenger ℬ defines the security of our scheme. Referring to the literature [32], we define that A has the following capabilities:(i)
The adversaryA can enumerate offline all the items in the Cartesian product Did∗Dpw∗Db within polynomial time, where Did denotes the identity space, Dpw denotes the password space, and Db denotes the biometric key space.(ii)
The adversaryA has the capability of somehow learning the victim’s identity when evaluating security strength (but not privacy provisions) of our scheme.(iii)
The adversaryA has full control over the communication channels between participants.(iv)
The adversaryA can intercept the password of a legitimate user, or extract secret parameters from a smart card by side-channel attacks, or obtain biometric information of a legitimate user through a special device, but it cannot do all three at the same time.(v)
The adversaryA can learn session keys of previous sessions.(vi)
When evaluating the security of mutual authentication, the adversaryA can obtain the private key of the authenticating party but cannot obtain its temporary session secret in the current session, while A cannot obtain the private key of the authenticated party but can arbitrarily select its temporary session secret in the current session.(vii)
The adversaryA is able to obtain the private keys of both the user and the server only when evaluating the resistance to eventual failing of the system (e.g., forward secrecy).The adversaryA can issue queries to the challenger ℬ and get answers from ℬ. We define the following rules of the game:System building phase:ℬ runs the system building algorithm, initializes the public parameters and hash functions, and then exposes them to the public. Meanwhile, ℬ maintains some lists during the entire process of interacting with A which are empty at the beginning.(1)
Hash(str): A issues query any string and ℬ returns the corresponding hash values and guarantees that the same queries get the same values.(2)
ExtractUIDUi: ℬ maintains a list LU. When A issues queries of the user’s identity IDUi: if IDUi exists in LU, ℬ returns the corresponding public key; otherwise, ℬ randomly generates the user’s public and private key pairs and stores them in LU, and then it returns the public key.(3)
ExtractSIDSj: ℬ maintains a list LS. When A issues queries of application server’s identity IDSj: if IDSj exists in LS, ℬ returns the corresponding public key; otherwise, ℬ randomly generates application server’s public and private key pairs and stores them in LS, and then it returns the public key.(4)
Send∏i,jt,m: A sends a message to ℬ, which belongs to the tth session of the user Ui and the server Sj. ℬ receives the message and processes the message according to our scheme and returns the corresponding result.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. ℬ will return Ui’s private key SKUi to A from the list LU.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application server Sj’s private key. ℬ will return Sj’s private key SKSj to A from the list LS.(7)
Reveal∏i,jt: A issues query for the session key of the session ∏i,jt, and ℬ returns the session key generated by the session ∏i,jt.


### 6.1.1. Issue Query Phase

After issuing the queries above, the adversaryA begins the challenge phase: A initiates a session key guess for session ∏i,jt. If A has never sent Reveal ∏i,jt query, challenger ℬ randomly flips a coin to obtain b∈0,1. If b=1, the challenger ℬ outputs the session key of the session ∏i,jt. If b=0, ℬ outputs a random number which length is equal to that of the session key of the session ∏i,jt. A guesses the value of b and outputs b′. If b=b′, we consider that A wins the game. We define the advantage of A winning the game as(1)AdvAKAA=PrAb=b′−12.Definition 1.
AKA-Secure: our scheme is authentication key agreement secure (AKA-Secure) ifAdvAKAA is negligible for any polynomial-time adversary A.IfA can forge the authentication message sent by the legitimate user to the legitimate server, or the response message sent by the legitimate server to the legitimate user, then our scheme is considered insecure. Defining the event AUi⟶Sj as A can successfully forge the authentication message sent by the legitimate user Ui to the legitimate server Sj. Defining the event ASj⟶Ui as A can successfully forge the response message sent by the legitimate server Sj to the legitimate user Ui, then we can define the advantage of A attacking the mutual authentication game as(2)AdvMAA=PrAUi⟶Sj+PrASj⟶Ui.Definition 2.
MA-Secure: our scheme is mutual authentication secure (MA-Secure) ifAdvMAA is negligible for any polynomial-time adversary A.


## 6.1.1. Issue Query Phase

After issuing the queries above, the adversaryA begins the challenge phase: A initiates a session key guess for session ∏i,jt. If A has never sent Reveal ∏i,jt query, challenger ℬ randomly flips a coin to obtain b∈0,1. If b=1, the challenger ℬ outputs the session key of the session ∏i,jt. If b=0, ℬ outputs a random number which length is equal to that of the session key of the session ∏i,jt. A guesses the value of b and outputs b′. If b=b′, we consider that A wins the game. We define the advantage of A winning the game as(1)AdvAKAA=PrAb=b′−12.Definition 1.
AKA-Secure: our scheme is authentication key agreement secure (AKA-Secure) ifAdvAKAA is negligible for any polynomial-time adversary A.IfA can forge the authentication message sent by the legitimate user to the legitimate server, or the response message sent by the legitimate server to the legitimate user, then our scheme is considered insecure. Defining the event AUi⟶Sj as A can successfully forge the authentication message sent by the legitimate user Ui to the legitimate server Sj. Defining the event ASj⟶Ui as A can successfully forge the response message sent by the legitimate server Sj to the legitimate user Ui, then we can define the advantage of A attacking the mutual authentication game as(2)AdvMAA=PrAUi⟶Sj+PrASj⟶Ui.Definition 2.
MA-Secure: our scheme is mutual authentication secure (MA-Secure) ifAdvMAA is negligible for any polynomial-time adversary A.


## 6.2. Proof of Security

In this part, we will show our scheme is AKA-secure and MA-secure in the security model we described above.Lemma 1.
No polynomial-time adversaryA can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.ProofSuppose that a polynomial-time adversaryA can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability, then the challenger ℬ can solve an instance of the ECCDH problem by a nonnegligible advantage. Given an instance of the ECCDH problem, we assume that A eventually chooses to forge the authentication message sent by the legitimate user Uc to the legitimate server Sd as a challenge, and the objective of challenger ℬ is to compute SKUc⋅y⋅P as SKUc,y are unknown elements in Zq∗, where PKUc=SKUc⋅P, Y=y⋅P, and PKUc,Y,P∈G. In the following, we will demonstrate how ℬ can solve the ECCDH problem by exploiting the adversary A.ℬ runs the system building algorithm: ℬ initializes the public parameters and hash function params=Fp,E,G,P,p,q,h1,h2 and sends them to A. Meanwhile, ℬ maintains several lists LH,LU,LS, which are empty at the beginning. Then, A makes the following queries:(1)
Hashnstr:ℬ maintains a list LHn=str,hnstr, which is empty at the beginning. After receiving the query Hashnstr from A, ℬ checks whether str,hnstr exists in the list LHn. If it exists, ℬ returns the corresponding value hnstr; otherwise, ℬ takes a random number hnstr, stores str,hnstr in LHn, and finally returns hnstr to A.(2)
Extract UIDUi: ℬ maintains a list LU=IDUi,SKUi,PKUi. After receiving the query ExtractU IDUi from A, ℬ checks whether IDUi,SKUi,PKUi exists in LU or not. If it exists, ℬ returns PKUi to A. Otherwise, ℬ executes the operations as follows:(i)
Ifi≠c, ℬ takes SKUi←$ℤq∗ as the private key of Ui and calculates the public key PKUi=SKUi·P, then stores IDUi,SKUi,PKUi into the list LU, finally returns PKUi to A.(ii)
Ifi=c, ℬ takes PKUc←$G as the public key of Uc and sets the private key SKUc to ⊥ (which means an unknown value), then stores IDUc,SKUc,PKUc into the list LU, finally returns PKUc to A.(3)
ExtractSIDSj: ℬ maintains a list LS=IDSj,SKSj,PKSj. After receiving the query ExtractS IDSj from A, ℬ checks whether IDSj,SKSj,PKSj exists in LS, if it exists, ℬ returns PKSj to A. Otherwise, ℬ takes SKSj←$ℤq∗ as the private key of Sj, then calculates the public key PKSj=SKSj·P, then stores IDSj,SKSj,PKSj into the list LS, and returns PKSj to A.(4)
Send∏i,jt,m: A sends a message m belonging to the session ∏i,jt to ℬ. ℬ processes the message m according to the following rules:(i)
If∏i,jt≠∏c,dt, ℬ processes the received message according to our scheme and sends the result to A.(ii)
If∏i,jt=∏c,dt and m=‘begin’, ℬ picks a random number x←$Zq∗, calculates X=x·P, SID=X‖IDUc‖ei‖Li⊕h2x·PKSd, and sends x,X,SID to A.(iii)
If∏i,jt=∏c,dt and m=X,SID, ℬ calculates X‖IDUc‖ei‖Li=SID⊕h2SKSd·X, picks a random point Y←$G, sets y to ⊥ (which means an unknown value), and sends Y to A.(iv)
If∏i,jt=∏c,dt and m=Y,AUTHSd, ℬ aborts the game.(v)
If∏i,jt=∏c,dt and m=MUc, ℬ aborts the game.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. If i=c, ℬ aborts the game; otherwise ℬ searches for Ui’s private key SKUi in the list LU and returns SKUi to A.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application. ℬ searches for Sj’s private key SKSj in the list LS and returns SKSj to A.(7)
Reveal (∏i,jt): A issues query for the session key of the session ∏i,jt. If ∏i,jt=∏c,dt, ℬ aborts the game; otherwise, ℬ returns the session key generated by the session ∏i,jt.According to the above queries, ifA can successfully forge an authentication message sent by the legitimate user Uc to the legitimate server Sd, it means that A can output MUc belonging to the session ∏c,dt where MUc=h1KEY‖X‖Y‖IDUc‖IDSd and KEY=h1TKUc‖X‖Y‖AUTHUc. According to the given instance of the ECCDH problem, ℬ can transform the equation(3)TKUc=SKUc+x⋅PKSd+Y,to get(4)SKUc⋅y⋅P=TKUc−SKSd·PKUc−SKSd·X−x·Y,and ℬ gets SKSd,PKUc,X,x,Y by searching the query records and gets TKUc by search the hash-query records with the probability of 1/qh (qh denotes the number of hash-queries). Then, ℬ outputs TKUc−SKSd·PKUc−SKSd·X−x·Y as the solution to the given instance of the ECCDH problem. The probability that ℬ can solve the ECCDH problem is described as follows.We define the eventE1 as ℬ does not abort in any queries. We define the event E2 as A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. Let l denote the number of bits of biometric information, qs denote the number of send-queries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. We use Zipf ’s law [33] to enhance the security of the security model. C’ and s’ are Zipf’s parameters. We can get PrE1≥1−1/qs+1qs and PrE2|E1≥ε, and then we get(5)PrℬwinECCDH=1qh·PrE2∩E1=1qh·PrE2|E1·PrE1≥1qh·1−1qs+1qs⋅ε+maxC’·qss′,qs2l.It implies thatℬ can solve an instance of the ECCDH problem with nonnegligible probability. This is contradicting with the hardness of the ECCDH problem. Therefore, we conclude that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.Lemma 2.
No polynomial-time adversaryA can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability if the ECCDH problem is hard.ProofSuppose that a polynomial-time adversaryA can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability, then the challenger ℬ can solve an instance of the ECCDH problem by a nonnegligible advantage. Given an instance of the ECCDH problem, we assume that A eventually chooses to forge the response message sent by the legitimate server Sd to the legitimate user Uc as a challenge, and the objective of challenger ℬ is to compute SKSd⋅x⋅P as SKSd,x are unknown elements in Zq∗, where PKSd=SKSd⋅P, X=x⋅P, and PKSd,X,P∈G. In the following, we will demonstrate how ℬ can solve the ECCDH problem by exploiting the adversary A.ℬ runs the system building algorithm: ℬ initializes the public parameters and hash function params=Fp,E,G,P,p,q,h1,h2 and sends them to A. Meanwhile, ℬ maintains several lists LH,LU,LS, which are empty at the beginning. Then, A makes the following queries:(1)
Hashnstr: ℬ maintains a list LHn=str,hnstr, which is empty at the beginning. After receiving the query Hashnstr from A, ℬ checks whether str,hnstr exists in the list LHn; if it exists, ℬ returns the corresponding value hnstr; otherwise, ℬ takes a random number hnstr, stores str,hnstr in LHn, and finally returns hnstr to A.(2)
ExtractU(IDUi): ℬ maintains a list LU=IDUi,SKUi,PKUi. After receiving the query ExtractU IDUi from A, ℬ checks whether IDUi,SKUi,PKUi exists in LU; if it exists, ℬ returns PKUi to A. Otherwise, ℬ takes SKUi←$ℤq∗ as the private key of Ui, then calculates the public key PKUi=SKUi·P, then stores IDUi,SKUi,PKUi into the list LU, and returns PKUi to A.(3)
ExtractSIDSj: ℬ maintains a list LS=IDSj,SKSj,PKSj. After receiving the query ExtractS IDSj from A, ℬ checks whether IDSj,SKSj,PKSj exists in LS or not. If it exists, ℬ returns PKSj to A. Otherwise, ℬ executes the operations as follows:(i)
Ifj≠d, ℬ takes SKSj←$ℤq∗ as the private key of Sj and calculates the public key PKSj=SKSj·P, then stores IDSj,SKSj,PKSj into the list LS, finally returns PKSj to A.(ii)
Ifj=d, ℬ takes PKSd←$G as the public key of Sd and sets the private key SKSd to ⊥ (which means an unknown value), then stores IDSd,SKSd,PKSd into the list LS, finally returns PKSd to A.(4)
Send(∏i,jt,m): A sends a message m belonging to the session ∏i,jt to ℬ. ℬ processes the message m according to the following rules:(i)
If∏i,jt≠∏c,dt, ℬ processes the received message according to our scheme and sends the result to A.(ii)
If∏i,jt=∏c,dt and m=’begin’, ℬ picks a random point X←$G, sets x to ⊥ (which means an unknown value), picks a random number SID←$ℋ2, and sends X,SID to A.(iii)
If∏i,jt=∏c,dt and m=X,SID, ℬ picks a random number y←$Zq∗ and calculates Y=y·P, and sends Y,y to A.(iv)
If∏i,jt=∏c,dt and m=Y,AUTHSd, ℬ aborts the game.(v)
If∏i,jt=∏c,dt and m=MUc, ℬ aborts the game.(5)
CorruptUIDUi: if A has already sent ExtractU IDUi query to ℬ, A can query the user Ui’s private key. ℬ searches for Ui’s private key SKUi in the list LU and returns SKUi to A.(6)
CorruptSIDSj: if A has already sent ExtractS IDSj query to ℬ, A can query the application server Sj’s private key. If j=d, ℬ aborts the game; otherwise, ℬ searches for Sj’s private key SKSj in the list LS and returns SKSj to A.(7)
Reveal∏i,jt: A issues query for the session key of the session ∏i,jt. If ∏i,jt=∏c,dt, ℬ aborts the game; otherwise, ℬ returns the session key generated by the session ∏i,jt.According to the above queries, ifA can successfully forge a response message sent by the legitimate server Sd to the legitimate user Uc, it means that A can output AUTHSd belonging to the session ∏c,dt where AUTHSd=h1TKSdXY‖IDUc‖IDSd. According to the given instance of the ECCDH problem, ℬ can transform the equation(6)TKSd=SKSd+y·PKUc+X,to get(7)SKSd⋅x⋅P=TKSd−SKUc·PKSd−SKUc·Y−y·X,and ℬ gets SKUc,PKSd,X,y,Y by searching the query records and gets TKSd by search the hash-query records with the probability of 1/qh (qh denotes the number of hash-queries). Then, ℬ outputs TKSd−SKUc·PKSd−SKUc·Y−y·X as the solution to the given instance of the ECCDH problem. The probability that ℬ can solve the ECCDH problem is described as follows.Defining the eventE1 as ℬ does not abort in any queries. Defining the event E2 as A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. Let l denote the number of bits of biometric information, qs denote the number of send-queries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user Uc to the legitimate server Sd. We can get PrE1≥1−1/qs+1qs, PrE2|E1≥ε, and then we get(8)PrℬwinECCDH=1qh⋅PrE2∩E1=1qh⋅PrE2|E1⋅PrE1≥1qh⋅1−1qs+1qs⋅ε.It implies thatℬ can solve an instance of the ECCDH problem with nonnegligible probability. This is contradicting with the hardness of the ECCDH problem. Therefore, we conclude that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard.Theorem 1.
Our scheme is MA-secure if the ECCDH problem is hard.ProofAccording to Lemma1 and Lemma 2, we learn that if the ECCDH problem is hard, no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability and no polynomial-time adversary can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability. Therefore, our scheme is MA-secure.Theorem 2.
Our scheme is AKA-secure if the ECCDH problem is hard.ProofIn the proof of Lemma1, we learn if A can successfully forge an authentication message sent by the legitimate user Uc to the legitimate server Sd, it means that A sends MUc belonging to the session ∏c,dt to ℬ, where MUc=h1KEY‖X‖Y‖IDUc‖IDSd. Then, ℬ can get KEY as the session key of the session ∏c,dt from the query records with probability of PrAUi⟶Sj. However, we learn that no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard in Lemma 1. Therefore, our scheme is AKA-secure if the ECCDH problem is hard.


## 6.3. Security Requirement Analysis

The research of Wang et al. [34] revealed a variety of security defects that are common in the multiserver architecture, such as no truly multifactor security and temporary information attack. Our scheme takes these security defects into consideration and meets the following security requirements.


### 6.3.1. User Anonymity

In our scheme, user’s identityIDUi exists in the message SID, MUi, and AUTHSj, where SID=X‖IDUi‖ei‖Li⊕h2x·PKSj, MUi=h1KEY‖X‖Y‖IDUi‖IDsj, and AUTHSj=h1TKSj‖X‖Y‖IDUi‖IDsj. It is impossible for the adversary to get IDUi by inferring SID because X‖IDUi‖ei‖Li is encrypted by h2x·PKSj, and at the same time, because x is an unknown number, based on the difficulty of the ECDL problem, the adversary cannot get the value of x·PKSj. And it is impossible for the adversary to know IDUi by inferring MUi or AUTHSj because of the one-way property of the hash function. Therefore, our scheme can provide user anonymity.


### 6.3.2. Untraceability

In our scheme, each session generates new random secret valuesx and y. Due to the randomness of x and y, the values of message SID, MUi, and AUTHSj which contain IDUi or IDSj are different in each session and the polynomial-time adversary cannot analyze their interconnection even for the same user and server’s session. Therefore, our scheme can provide untraceability.


### 6.3.3. Perfect Forward Secrecy

We assume that the adversary obtains the private keys of the userUi and the application server Sj and intercepts the messages X,SID, Y,AUTHSj, MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the temporary session secrets x,y of that session, because the temporary session secrets are deleted immediately after used. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x⋅SKSj+y⋅P, and x,y is unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can provide the perfect forward secrecy.


### 6.3.4. No Smart Card Lose Attack

According to the definition of the adversary, we assume that the adversary obtains the dataAi and Bi in the user’s smart card by using the side-channel attack. Because we use the fuzzy-verifier techniques [30,32] in the process of recovering the user’s private key through smart card, different input PWi,Ri may output the same Bi′, where Bi′=h1IDUi+hPWi‖Rimodn0. Thus, we suppose that the adversary gets PWi′,Ri′ which makes Bi′=Bi, and then it calculates SKUi′=Ai⊕h1PWi′‖Ri′, and it cannot verify the correctness of SKUi′. Therefore, our scheme can resist the smart card lose attack.


### 6.3.5. No Stolen Verifier Table Attack

In the stolen verifier table attack, the adversary misuses valued data which are stored at servers’ side such as passwords or other parameters and masquerade as legal users [35]. In our scheme, the blockchain maintains the repository that stores public keys, rather than servers or RC maintain the verifier table. Therefore, our scheme can resist the stolen verifier attack.


### 6.3.6. Three-Factor Security

In our scheme, user’s passwordPWi, personal biometrics ωi, and the secret data Ai,Bi make up the three-factor security. Based on the constructed security model, the adversary cannot obtain all three of these security factors at the same time. Therefore, we discuss the case where the adversary obtains two security factors:(i)
The adversary obtains both the user’s passwordPWi and the secret data Ai,Bi in the smart card or both the user’s personal biometrics ωi and the secret data Ai,Bi in the smart card: according to the security analysis in Section 6.3.4, we can get the adversary cannot verify the correctness of the user’s private key SKUi′.(ii)
The adversary obtains the user’s personal biometricsωi and the password PWi: the adversary cannot calculate SKUi=Ai⊕h1PWi‖Ri without the secret data Ai in the smart card. Therefore, the adversary cannot obtain the user’s private key SKUi.Therefore, our scheme can provide three-factor security.


### 6.3.7. Decentralized Registration

In our scheme, users register their accounts on the blockchain network. The blockchain network is composed of multiple nodes, allowing up to one-third of the nodes to be down without affecting the function of the blockchain network.


### 6.3.8. Decentralized Authentication

In our scheme, participants only need to obtain each other’s public key from any blockchain node to complete mutual authentication and key agreement according to our scheme. According to the distributed feature of blockchain nodes, our scheme will not suffer from the security risks caused by centralization such as the leak of master key or the downtime of the registration center server.


### 6.3.9. Hierarchical Access Control

In our scheme, the application server needs to verify the access permission of the user before responding to the user login. Then-level application server has the permission key array an,an+1,…,amax−2,amax−1,amax, so it cannot verify the user’s permission whose access permission level is lower than it. If the user wants to impersonate a higher level of access permission, the application server calculates si′=h1d‖h1ei‖aLi, verifies si′=?si, and if it does not hold, the application server rejects the user.


### 6.3.10. Resistance to User Impersonation Attack

According to the proof of Lemma1, no polynomial-time adversary can forge an authentication message sent by the legitimate user Ui to the legitimate server Sj without the private key SKUi of Ui and the server’s temporary session secret y. The server can find out about the attack by verifying the authentication message sent by the user. Therefore, our scheme can resist the user impersonation attack.


### 6.3.11. Resistance to Server Spoofing Attack

According to the proof of Lemma2, no polynomial-time adversary can forge a response message sent by the legitimate server Sj to the legitimate user Ui without the private key SKSj of Sj and the user’s temporary session secret x. The user can find out about the attack by verifying the response message sent by the server. Therefore, our scheme can resist the server spoofing attack.


### 6.3.12. Resistance to Replay Attack

In our scheme, each session generates new random temporary session secretsx and y. We discuss the replay attack in the following two scenarios:(i)
Replay the user’s message: after receiving the message sent by the user, the server will calculateMSj=h1KEY‖X‖Y‖IDUi‖IDsj, where Y is generated by the server based on temporary session secret y, and its value in each session is different. If the adversary replays the user’s message in the previous session X′,SID′ and MUi′, where MUi′=h1KEY′‖X′‖Y′‖IDUi‖IDsj. The application server can determine whether the authentication message belongs to the current session of this server Sj with user Ui by verifying whether MUi is equal to MSj.(ii)
Replay the application server’s message: after receiving the message sent by the server, the user will calculateAUTHUi=h1TKUi‖X‖Y‖IDUi‖IDSj, where x is the temporary session secret, and its value in each session is different. If the adversary replays the server’s message in the previous session Y′,AUTHSj′, where AUTHSj′=h1TKSj′‖X′‖Y′‖IDUi‖IDsj. The client can determine whether the response messages belong to the current session by verifying whether AUTHSj is equal to AUTHUi.Therefore, our scheme can resist the replay attack.


### 6.3.13. Resistance to Modification Attack

According to the proof of Lemma1 and Lemma 2, no polynomial-time adversary can modify the values of the authentication messages or the response message so as to make the message pass the verification. Therefore, our scheme can resist the modification attack.


### 6.3.14. Resistance to Temporary Information Attack

We assume that the adversary obtains the temporary session secretsx,y and intercepts the massages X,SID, Y,AUTHSj, and MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the private keys of the user Ui and the application server Sj. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x·SKSj+y·P, and SKUi, SKSj are unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can resist the temporary information attack.


### 6.3.15. Resistance to Insider Attack

In our scheme, the participant’s private key is generated by itself and does not rely on the registration center, so there is no insider attack.


### 6.3.16. Resistance to Man-in-the-Middle Attack

As an attack that aims at circumventing mutual authentication, the man-in-the-middle attack can succeed only when the adversary can impersonate each participant to their satisfaction as expected from the legitimate participant. Accounting to the previous security analysis, no adversary can impersonate a legitimate participant in our scheme. Therefore, our scheme can resist the man-in-the-middle attack.


## 6.3.1. User Anonymity

In our scheme, user’s identityIDUi exists in the message SID, MUi, and AUTHSj, where SID=X‖IDUi‖ei‖Li⊕h2x·PKSj, MUi=h1KEY‖X‖Y‖IDUi‖IDsj, and AUTHSj=h1TKSj‖X‖Y‖IDUi‖IDsj. It is impossible for the adversary to get IDUi by inferring SID because X‖IDUi‖ei‖Li is encrypted by h2x·PKSj, and at the same time, because x is an unknown number, based on the difficulty of the ECDL problem, the adversary cannot get the value of x·PKSj. And it is impossible for the adversary to know IDUi by inferring MUi or AUTHSj because of the one-way property of the hash function. Therefore, our scheme can provide user anonymity.


## 6.3.2. Untraceability

In our scheme, each session generates new random secret valuesx and y. Due to the randomness of x and y, the values of message SID, MUi, and AUTHSj which contain IDUi or IDSj are different in each session and the polynomial-time adversary cannot analyze their interconnection even for the same user and server’s session. Therefore, our scheme can provide untraceability.


## 6.3.3. Perfect Forward Secrecy

We assume that the adversary obtains the private keys of the userUi and the application server Sj and intercepts the messages X,SID, Y,AUTHSj, MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the temporary session secrets x,y of that session, because the temporary session secrets are deleted immediately after used. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x⋅SKSj+y⋅P, and x,y is unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can provide the perfect forward secrecy.


## 6.3.4. No Smart Card Lose Attack

According to the definition of the adversary, we assume that the adversary obtains the dataAi and Bi in the user’s smart card by using the side-channel attack. Because we use the fuzzy-verifier techniques [30,32] in the process of recovering the user’s private key through smart card, different input PWi,Ri may output the same Bi′, where Bi′=h1IDUi+hPWi‖Rimodn0. Thus, we suppose that the adversary gets PWi′,Ri′ which makes Bi′=Bi, and then it calculates SKUi′=Ai⊕h1PWi′‖Ri′, and it cannot verify the correctness of SKUi′. Therefore, our scheme can resist the smart card lose attack.


## 6.3.5. No Stolen Verifier Table Attack

In the stolen verifier table attack, the adversary misuses valued data which are stored at servers’ side such as passwords or other parameters and masquerade as legal users [35]. In our scheme, the blockchain maintains the repository that stores public keys, rather than servers or RC maintain the verifier table. Therefore, our scheme can resist the stolen verifier attack.


## 6.3.6. Three-Factor Security

In our scheme, user’s passwordPWi, personal biometrics ωi, and the secret data Ai,Bi make up the three-factor security. Based on the constructed security model, the adversary cannot obtain all three of these security factors at the same time. Therefore, we discuss the case where the adversary obtains two security factors:(i)
The adversary obtains both the user’s passwordPWi and the secret data Ai,Bi in the smart card or both the user’s personal biometrics ωi and the secret data Ai,Bi in the smart card: according to the security analysis in Section 6.3.4, we can get the adversary cannot verify the correctness of the user’s private key SKUi′.(ii)
The adversary obtains the user’s personal biometricsωi and the password PWi: the adversary cannot calculate SKUi=Ai⊕h1PWi‖Ri without the secret data Ai in the smart card. Therefore, the adversary cannot obtain the user’s private key SKUi.Therefore, our scheme can provide three-factor security.


## 6.3.7. Decentralized Registration

In our scheme, users register their accounts on the blockchain network. The blockchain network is composed of multiple nodes, allowing up to one-third of the nodes to be down without affecting the function of the blockchain network.


## 6.3.8. Decentralized Authentication

In our scheme, participants only need to obtain each other’s public key from any blockchain node to complete mutual authentication and key agreement according to our scheme. According to the distributed feature of blockchain nodes, our scheme will not suffer from the security risks caused by centralization such as the leak of master key or the downtime of the registration center server.


## 6.3.9. Hierarchical Access Control

In our scheme, the application server needs to verify the access permission of the user before responding to the user login. Then-level application server has the permission key array an,an+1,…,amax−2,amax−1,amax, so it cannot verify the user’s permission whose access permission level is lower than it. If the user wants to impersonate a higher level of access permission, the application server calculates si′=h1d‖h1ei‖aLi, verifies si′=?si, and if it does not hold, the application server rejects the user.


## 6.3.10. Resistance to User Impersonation Attack

According to the proof of Lemma1, no polynomial-time adversary can forge an authentication message sent by the legitimate user Ui to the legitimate server Sj without the private key SKUi of Ui and the server’s temporary session secret y. The server can find out about the attack by verifying the authentication message sent by the user. Therefore, our scheme can resist the user impersonation attack.


## 6.3.11. Resistance to Server Spoofing Attack

According to the proof of Lemma2, no polynomial-time adversary can forge a response message sent by the legitimate server Sj to the legitimate user Ui without the private key SKSj of Sj and the user’s temporary session secret x. The user can find out about the attack by verifying the response message sent by the server. Therefore, our scheme can resist the server spoofing attack.


## 6.3.12. Resistance to Replay Attack

In our scheme, each session generates new random temporary session secretsx and y. We discuss the replay attack in the following two scenarios:(i)
Replay the user’s message: after receiving the message sent by the user, the server will calculateMSj=h1KEY‖X‖Y‖IDUi‖IDsj, where Y is generated by the server based on temporary session secret y, and its value in each session is different. If the adversary replays the user’s message in the previous session X′,SID′ and MUi′, where MUi′=h1KEY′‖X′‖Y′‖IDUi‖IDsj. The application server can determine whether the authentication message belongs to the current session of this server Sj with user Ui by verifying whether MUi is equal to MSj.(ii)
Replay the application server’s message: after receiving the message sent by the server, the user will calculateAUTHUi=h1TKUi‖X‖Y‖IDUi‖IDSj, where x is the temporary session secret, and its value in each session is different. If the adversary replays the server’s message in the previous session Y′,AUTHSj′, where AUTHSj′=h1TKSj′‖X′‖Y′‖IDUi‖IDsj. The client can determine whether the response messages belong to the current session by verifying whether AUTHSj is equal to AUTHUi.Therefore, our scheme can resist the replay attack.


## 6.3.13. Resistance to Modification Attack

According to the proof of Lemma1 and Lemma 2, no polynomial-time adversary can modify the values of the authentication messages or the response message so as to make the message pass the verification. Therefore, our scheme can resist the modification attack.


## 6.3.14. Resistance to Temporary Information Attack

We assume that the adversary obtains the temporary session secretsx,y and intercepts the massages X,SID, Y,AUTHSj, and MUi of a past session between the user Ui and the server Sj, but the adversary does not obtain the private keys of the user Ui and the application server Sj. If the adversary wants to get the session key of that session, it needs to calculate KEY=h1TK‖X‖Y‖AUTH, where TK=SKUi+x·SKSj+y·P, and SKUi, SKSj are unknown elements. It means that the adversary must solve an instance of the ECCDH problem. Therefore, if the ECCDH problem is hard, our scheme can resist the temporary information attack.


## 6.3.15. Resistance to Insider Attack

In our scheme, the participant’s private key is generated by itself and does not rely on the registration center, so there is no insider attack.


## 6.3.16. Resistance to Man-in-the-Middle Attack

As an attack that aims at circumventing mutual authentication, the man-in-the-middle attack can succeed only when the adversary can impersonate each participant to their satisfaction as expected from the legitimate participant. Accounting to the previous security analysis, no adversary can impersonate a legitimate participant in our scheme. Therefore, our scheme can resist the man-in-the-middle attack.


## 7. Performance Analysis

In this section, we compare the performance of the proposed scheme with other multiserver architecture schemes which include Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. Among them, Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], and Xiong et al.’s scheme [11] are the latest schemes since 2019.


### 7.1. Security Comparison

Table7 compares the security performance of our scheme with Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. According to Table 7, only our scheme can meet all 9 security requirements.Table 7
Security comparison.
Security requirementsOur schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]User anonymity✓✓✓✓✓✓Untraceability✓✓✓✓✓✓Decentralized registration✓✗✗✓✗✗No smart card lose attack✓✓✓✓✗✗Impersonation attack✓✓✓✓✓✓Replay attack✓✓✓✓✓✓Man-in-the-middle attack✓✓✓✓✗✓Hierarchical access control✓✓✗✗✗✗


### 7.2. Computation/Communication Overhead Comparison

To demonstrate the advantages of our scheme in terms of computation and communication overheads, our scheme is compared with Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. In all of these schemes, user and server registration is only required once, and the authentication and key agreement processes are the main processes in the practical application of the schemes. Thus, we only consider the overheads in the authentication and key agreement processes of the user and application server in our comparison.We take an elliptic curveE over the finite field Fp: y2=x3+ax+b, where p>2160 is a large prime number, as the elliptic curve used in our scheme, Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. The point P is an element with large prime order q>2160 on the additive group G on E. Thus, we get the size of the point in G to be 320 bits and the size of the number in Zq∗ to be 160 bits. The output length of the hash functions h1,h2 is 160 bits and 512 bits. We take e^:G1×G1⟶G2 as the bilinear map used in Kou’s scheme [2].


#### 7.2.1. Computation Overhead

In order to compare the computation overhead, we calculate the sum of the computation times of the cryptographic operations used in the authentication phase for each scheme. The execution time of cryptographic operations comes from He et al.’s compute [37]. The computing was run on a cryptographic library MIRACL, and it was based on a hardware platform consists of an Intel I7-4770 processor with 3.40 GHz clock frequency and 4 gigabytes memory and runs Windows 7 operating system. The notations about the execution time of the cryptographic operations are defined as follows:(i)
Tbq (=4.211 ms): the execution time of a bilinear pairing operation.(ii)
Tsm−bp (=1.709 ms): the execution time of a scale multiplication operation related to the bilinear pairing.(iii)
Tpa−bp (=0.0071 ms): the execution time of a point addition operation related to the bilinear pairing.(iv)
Tmtp (=4.406 ms): the execution time of a hash-to-point operation related to the bilinear pairing, where the hash function maps a string to a point of G1.(v)
Texp (=0.049 ms): the execution time of an exponentiation operation in G2.(vi)
Tsm−ecc (=0.442 ms): the execution time of a scale multiplication operation related to the ECC.(vii)
Tpa−ecc (=0.0018 ms): the execution time of a point addition operation related to the ECC.(viii)
Th (=0.0001 ms): the execution time of a general hash function.(ix)
Tmul (=0.00001 ms): the execution time of a multiplication operation in Zq∗.(x)
Te/d (=0.0002 ms): the execution time of a symmetric key encryption/decryption.The authentication phase of our scheme has three scale multiplication operations, one point addition operation, and four general hash functions. And it has three scale multiplication operations, one point addition operation, and six general hash functions at the application server side. Table8 and Figure 4 show the comparison of computation overhead between our scheme and other schemes. Compared with Xiong et al.’s scheme [11], our scheme reduces one scale multiplication operation at the application server side, and the computation overhead is reduced by 14.16%. And compared with Kou et al.’s scheme [2], our scheme does not use the bilinear pairing operation which has a large computation overhead, and the computation overhead is reduced by 82.93%.Table 8
Computation overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Client3Tsm−ecc + Tpa−ecc + 4Th ≈ 1.32823Tsm−bp + 2Texp + Tpa−bp+6Th ≈ 5.23274Tsm−ecc + 2Tpa−ecc + 7Th ≈1.77233Tsm−ecc + Tmul + 5Th ≈1.32653Tsm−ecc + 7Th ≈1.32673Tsm−ecc + Te/d + 7Th ≈1.3269Server3Tsm−ecc + Tpa−ecc + 6Th ≈ 1.32842Tbq + Tsm−bp + 4Texp + Tpa−bp + 7Th + Tmul ≈ 10.33484Tsm−ecc + 2Tpa−ecc+3Th ≈1.77194Tsm−ecc + Tmul+5Th ≈1.76853Tsm−ecc + 5Th ≈1.32652Tsm−ecc + 2Te/d + 6Th ≈0.885Total time (milliseconds)≈2.6566≈15.5675≈3.5442≈3.095≈2.6532≈2.2119Figure 4
Computation overhead comparison.


#### 7.2.2. Communication Overhead

In the mutual authentication phase of our scheme, the client and the application server communicate three times, sendingX,SID,Y,AUTHSj, and MUi, and the application server also queries from the nearest blockchain node to get IDUi,PKUi,si. Messages XYPKUi∈G and their length are both 320 bits. Messages MUi, AUTHSj, si∈ℋ1, and their length are both 160 bits. Message SID∈ℋ2, its length is 512 bits, and IDUi is a 32-bit data; thus, the communication overhead is (320 + 512) + (320 + 160) + 160 + (32 + 320 + 160) = 1984 bits. Table 9 and Figure 5 show the comparison of the communication overhead of our scheme with other schemes. In comparison, our scheme’s communication overhead is close to the nearest scheme, Ying and Nayak’s scheme [36] and Xiong’s scheme [11].Table 9
Communication overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Rounds of message exchange322255Number of bits required198415681632156835202944Figure 5
Communication overhead comparison.


## 7.1. Security Comparison

Table7 compares the security performance of our scheme with Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. According to Table 7, only our scheme can meet all 9 security requirements.Table 7
Security comparison.
Security requirementsOur schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]User anonymity✓✓✓✓✓✓Untraceability✓✓✓✓✓✓Decentralized registration✓✗✗✓✗✗No smart card lose attack✓✓✓✓✗✗Impersonation attack✓✓✓✓✓✓Replay attack✓✓✓✓✓✓Man-in-the-middle attack✓✓✓✓✗✓Hierarchical access control✓✓✗✗✗✗


## 7.2. Computation/Communication Overhead Comparison

To demonstrate the advantages of our scheme in terms of computation and communication overheads, our scheme is compared with Kou et al.’s scheme [2], Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. In all of these schemes, user and server registration is only required once, and the authentication and key agreement processes are the main processes in the practical application of the schemes. Thus, we only consider the overheads in the authentication and key agreement processes of the user and application server in our comparison.We take an elliptic curveE over the finite field Fp: y2=x3+ax+b, where p>2160 is a large prime number, as the elliptic curve used in our scheme, Ying and Nayak’s scheme [36], Xiong et al.’s scheme [11], He and Wang’s scheme [4], and Odelu et al.’s scheme [5]. The point P is an element with large prime order q>2160 on the additive group G on E. Thus, we get the size of the point in G to be 320 bits and the size of the number in Zq∗ to be 160 bits. The output length of the hash functions h1,h2 is 160 bits and 512 bits. We take e^:G1×G1⟶G2 as the bilinear map used in Kou’s scheme [2].


### 7.2.1. Computation Overhead

In order to compare the computation overhead, we calculate the sum of the computation times of the cryptographic operations used in the authentication phase for each scheme. The execution time of cryptographic operations comes from He et al.’s compute [37]. The computing was run on a cryptographic library MIRACL, and it was based on a hardware platform consists of an Intel I7-4770 processor with 3.40 GHz clock frequency and 4 gigabytes memory and runs Windows 7 operating system. The notations about the execution time of the cryptographic operations are defined as follows:(i)
Tbq (=4.211 ms): the execution time of a bilinear pairing operation.(ii)
Tsm−bp (=1.709 ms): the execution time of a scale multiplication operation related to the bilinear pairing.(iii)
Tpa−bp (=0.0071 ms): the execution time of a point addition operation related to the bilinear pairing.(iv)
Tmtp (=4.406 ms): the execution time of a hash-to-point operation related to the bilinear pairing, where the hash function maps a string to a point of G1.(v)
Texp (=0.049 ms): the execution time of an exponentiation operation in G2.(vi)
Tsm−ecc (=0.442 ms): the execution time of a scale multiplication operation related to the ECC.(vii)
Tpa−ecc (=0.0018 ms): the execution time of a point addition operation related to the ECC.(viii)
Th (=0.0001 ms): the execution time of a general hash function.(ix)
Tmul (=0.00001 ms): the execution time of a multiplication operation in Zq∗.(x)
Te/d (=0.0002 ms): the execution time of a symmetric key encryption/decryption.The authentication phase of our scheme has three scale multiplication operations, one point addition operation, and four general hash functions. And it has three scale multiplication operations, one point addition operation, and six general hash functions at the application server side. Table8 and Figure 4 show the comparison of computation overhead between our scheme and other schemes. Compared with Xiong et al.’s scheme [11], our scheme reduces one scale multiplication operation at the application server side, and the computation overhead is reduced by 14.16%. And compared with Kou et al.’s scheme [2], our scheme does not use the bilinear pairing operation which has a large computation overhead, and the computation overhead is reduced by 82.93%.Table 8
Computation overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Client3Tsm−ecc + Tpa−ecc + 4Th ≈ 1.32823Tsm−bp + 2Texp + Tpa−bp+6Th ≈ 5.23274Tsm−ecc + 2Tpa−ecc + 7Th ≈1.77233Tsm−ecc + Tmul + 5Th ≈1.32653Tsm−ecc + 7Th ≈1.32673Tsm−ecc + Te/d + 7Th ≈1.3269Server3Tsm−ecc + Tpa−ecc + 6Th ≈ 1.32842Tbq + Tsm−bp + 4Texp + Tpa−bp + 7Th + Tmul ≈ 10.33484Tsm−ecc + 2Tpa−ecc+3Th ≈1.77194Tsm−ecc + Tmul+5Th ≈1.76853Tsm−ecc + 5Th ≈1.32652Tsm−ecc + 2Te/d + 6Th ≈0.885Total time (milliseconds)≈2.6566≈15.5675≈3.5442≈3.095≈2.6532≈2.2119Figure 4
Computation overhead comparison.


### 7.2.2. Communication Overhead

In the mutual authentication phase of our scheme, the client and the application server communicate three times, sendingX,SID,Y,AUTHSj, and MUi, and the application server also queries from the nearest blockchain node to get IDUi,PKUi,si. Messages XYPKUi∈G and their length are both 320 bits. Messages MUi, AUTHSj, si∈ℋ1, and their length are both 160 bits. Message SID∈ℋ2, its length is 512 bits, and IDUi is a 32-bit data; thus, the communication overhead is (320 + 512) + (320 + 160) + 160 + (32 + 320 + 160) = 1984 bits. Table 9 and Figure 5 show the comparison of the communication overhead of our scheme with other schemes. In comparison, our scheme’s communication overhead is close to the nearest scheme, Ying and Nayak’s scheme [36] and Xiong’s scheme [11].Table 9
Communication overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Rounds of message exchange322255Number of bits required198415681632156835202944Figure 5
Communication overhead comparison.


## 7.2.1. Computation Overhead

In order to compare the computation overhead, we calculate the sum of the computation times of the cryptographic operations used in the authentication phase for each scheme. The execution time of cryptographic operations comes from He et al.’s compute [37]. The computing was run on a cryptographic library MIRACL, and it was based on a hardware platform consists of an Intel I7-4770 processor with 3.40 GHz clock frequency and 4 gigabytes memory and runs Windows 7 operating system. The notations about the execution time of the cryptographic operations are defined as follows:(i)
Tbq (=4.211 ms): the execution time of a bilinear pairing operation.(ii)
Tsm−bp (=1.709 ms): the execution time of a scale multiplication operation related to the bilinear pairing.(iii)
Tpa−bp (=0.0071 ms): the execution time of a point addition operation related to the bilinear pairing.(iv)
Tmtp (=4.406 ms): the execution time of a hash-to-point operation related to the bilinear pairing, where the hash function maps a string to a point of G1.(v)
Texp (=0.049 ms): the execution time of an exponentiation operation in G2.(vi)
Tsm−ecc (=0.442 ms): the execution time of a scale multiplication operation related to the ECC.(vii)
Tpa−ecc (=0.0018 ms): the execution time of a point addition operation related to the ECC.(viii)
Th (=0.0001 ms): the execution time of a general hash function.(ix)
Tmul (=0.00001 ms): the execution time of a multiplication operation in Zq∗.(x)
Te/d (=0.0002 ms): the execution time of a symmetric key encryption/decryption.The authentication phase of our scheme has three scale multiplication operations, one point addition operation, and four general hash functions. And it has three scale multiplication operations, one point addition operation, and six general hash functions at the application server side. Table8 and Figure 4 show the comparison of computation overhead between our scheme and other schemes. Compared with Xiong et al.’s scheme [11], our scheme reduces one scale multiplication operation at the application server side, and the computation overhead is reduced by 14.16%. And compared with Kou et al.’s scheme [2], our scheme does not use the bilinear pairing operation which has a large computation overhead, and the computation overhead is reduced by 82.93%.Table 8
Computation overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Client3Tsm−ecc + Tpa−ecc + 4Th ≈ 1.32823Tsm−bp + 2Texp + Tpa−bp+6Th ≈ 5.23274Tsm−ecc + 2Tpa−ecc + 7Th ≈1.77233Tsm−ecc + Tmul + 5Th ≈1.32653Tsm−ecc + 7Th ≈1.32673Tsm−ecc + Te/d + 7Th ≈1.3269Server3Tsm−ecc + Tpa−ecc + 6Th ≈ 1.32842Tbq + Tsm−bp + 4Texp + Tpa−bp + 7Th + Tmul ≈ 10.33484Tsm−ecc + 2Tpa−ecc+3Th ≈1.77194Tsm−ecc + Tmul+5Th ≈1.76853Tsm−ecc + 5Th ≈1.32652Tsm−ecc + 2Te/d + 6Th ≈0.885Total time (milliseconds)≈2.6566≈15.5675≈3.5442≈3.095≈2.6532≈2.2119Figure 4
Computation overhead comparison.


## 7.2.2. Communication Overhead

In the mutual authentication phase of our scheme, the client and the application server communicate three times, sendingX,SID,Y,AUTHSj, and MUi, and the application server also queries from the nearest blockchain node to get IDUi,PKUi,si. Messages XYPKUi∈G and their length are both 320 bits. Messages MUi, AUTHSj, si∈ℋ1, and their length are both 160 bits. Message SID∈ℋ2, its length is 512 bits, and IDUi is a 32-bit data; thus, the communication overhead is (320 + 512) + (320 + 160) + 160 + (32 + 320 + 160) = 1984 bits. Table 9 and Figure 5 show the comparison of the communication overhead of our scheme with other schemes. In comparison, our scheme’s communication overhead is close to the nearest scheme, Ying and Nayak’s scheme [36] and Xiong’s scheme [11].Table 9
Communication overhead comparison.
Our schemeKou et al.’s scheme [2]Ying and Nayak’s scheme [36]Xiong et al.’s scheme [11]He and Wang’s scheme [4]Odelu et al.’s scheme [5]Rounds of message exchange322255Number of bits required198415681632156835202944Figure 5
Communication overhead comparison.


## 8. Conclusions

With the wide application of blockchain technology, some blockchain-based multiserver authentication schemes have been proposed to deal with the centralization problem under the original multiserver architectures. However, most of them do not have effective user permission control and do not have satisfactory performance in terms of computation and communication overheads. In this paper, a blockchain-based hierarchical authentication scheme for multiserver architecture has been proposed. It is decentralized, and it has hierarchical access control functions. Our security proof and performance analysis show that our scheme is securer and more efficient than some existed multiserver authentication schemes such as Xiong et al.’s scheme [11] and Kou et al.’s scheme [2]. Our scheme is well suited for blockchain-based applications, such as a cross-bank blockchain digital currency system or a blockchain-based medical case system of multiple hospitals.



---

*Source: 5592119-2021-04-23.xml*