A Blockchain-Based Hierarchical Authentication Scheme for Multiserver Architecture

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. *is 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. *e 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 andman-in-the-middle attacks. In addition, our performance analysis shows that the proposed scheme has less computation overhead.


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][3][4][5][6][7][8] have been proposed, including various improvements to scheme security and performance. e common feature of these schemes is the existence of three participants: the user, the registration center, and the server. e 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. e 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. e 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. eir 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. e 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. e 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. e 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.
In this paper, a blockchain-based hierarchical authentication scheme for a multiserver architecture is proposed. e 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]). is 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. e remainder of the paper is organized as follows. Section 2, 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.

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. ey 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 blockchainbased two-factor authentication scheme for cross-domain authentication. Mohsin et al. [19] proposed a biometricbased 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.

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].
ere are three main concepts in blockchain technology, that is, nodes, consensus, and blocks. e 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. e 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). e node broadcasts the block after a block is generated. e 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. e 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.

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

Elliptic Curve Cryptography.
Let p be a large prime number and F p be a finite field of order p, then the elliptic curve E over the finite field F p is defined. e 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: it is easy to calculate A 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 compute (a · b) · P as a, b are unknown elements in Z * q , 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:  Figure 1: A blockchain-based hierarchical multiserver authentication system in a school league. Each school has its own confidential servers and normal servers. ese 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.
(i) Keygen(1 k ) ⟶ (SK, PK): Key Generation Function. e function generates a random private key SK and the corresponding public key PK. (ii) Sig(SK, m) ⟶ SIG: Signature Function. e function uses the private key SK to calculate the signature SIG of massage m. (iii) Ver(PK, SIG, m) ⟶ bool ∈ true, false { } Verify Function. e 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.

Notations.
We provide the definition of notations appearing in our scheme in Table 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. e architecture of the system is shown in Figure 2. 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. e 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. e permission server has the authority to commit transaction proposal to the blockchain network. e 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.

Blockchain.
e 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. e 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.

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. e endorser node verifies the legality of transaction, endorses the transaction, and sends the result to the client node. e client node sends the result to the orderer node. e orderer node packages transactions together to generate a new block and sends it to the committer node. e committer node checks the block and appends the block to the local blockchain, and then the transaction is completed.

World State.
In the Hyperledger Fabric system, a ledger consists of two parts: a world state and a blockchain [29]. e 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. e 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 Figure 3.

The Proposed Blockchain-Based Hierarchical
Authentication Scheme for Multiserver Architecture

Initialization Phase.
At the initialization of the system, a blockchain network is established. e blockchain network chooses an elliptic curve E over the finite field F p : where p(>2 160 ) is a large prime number. e point P is an element with large prime order q(>2 160 ) on the additive group G on E. en, it chooses the following hash function h 1 : 0, 1 where l 1 , l 2 are the bit length of the hash function's output. en, it exposes F p , E, G, P, p, q, h 1 , h 2 .

Server Registration Phase.
e server registration phase is as follows, and the main steps are provided in Table 2.
e server S j chooses the identity ID S j , selects a random number SK s j ← $ Z * q as the private key, and then calculates its public key PK s j � SK s j · P. e server uses the private key to sign the message ID S j � � � � � PK s j : en, the server commits a transaction proposal to the blockchain network. e transaction content is SIG s j , ID S j , PK s j .
Step 2. e 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 Ver(PK s j , SIG s j , ID s j � � � � � PK s j )� ? 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 ID S j , PK s j are stored in the blockchain.
Step 3. After receiving that the notification of the transaction is successful, the server saves the SK s j . e server registration phase is complete.

User Registration
Phase. Users need to register at the registration terminal offline and get his or her smart card. e user registration phase is as follows, and the main steps are provided in Table 3: as the user's private key. en, it calculates the public key PK U i � SK U i · P, signs the message . e registration terminal packages SIG U i , ID U i , PK U i as the transaction content and commits the transaction proposal to the blockchain network.
e blockchain network processes the transaction proposal: the endorser node verifies A generator of the group G with order q U i i th user S j j th server ID U i i th user's identity ID S j j th server's identity PW i i th user's password ω i i th user's biometrics information R i i th user's biometrics key L n Access permission level PK U i ,SK U i i th user's public-private key pair PK S j ,SK S j i th application server's public-private key pair PK P r ,SK P r r th permission server's public-private key pair a‖b Encoding a and b as strings from which the constituent objects are easily recoverable a ⊕ b Encoding a and b as a binary bit string for an XOR operation

Security and Communication Networks
whether the submitter has the right for the operation and rejects this transaction if it does not; if it does, the endorser node verifies Ver(PK U i , 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 ID U i , PK U i 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 U i enters the password PW i , the biometric information ω i . e registration terminal runs the fuzzy-extractor generation algorithm on the input biometric infor- Verifies Ver(PK s j , SIG s j , ID s j � � � � � PK s j )� ? true if holds, stores:

Success
Stores: SK s j Table 3: User registration phase.

U i
Blockchain network true if holds, stores: where n 0 is a medium integer (as defined in [30]) which determines the capacity of the pool of the pair (ID U i , PW i , R i ) against online guessing. Finally, the registration terminal saves A i , B i , BP i in the smart card. e user registration phase is complete.

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. e proposed hierarchical access control method is as follows.

Initialization of Permission
(i) Step 1. e permission server sets a total of max levels of hierarchical access permission.
e permission server takes a random number d and then publishes d.
e permission server takes max random numbers a 1 , a 2 , . . . , a max as the permission keys. (iv) Step 4. e permission server sets the access permission of the application server S j is level The permission server sends a L j , a L j +1 , . . . , a max to the application server S j which access permission level is L j in a secure channel. e permission key array in the application server of each level is listed in Table 4.

Granting Access Permission
Phase. e 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. e main steps are provided in Table 5: Step 1. e user U i inserts the smart card and enters ID U i , PW i , and biometric information ω i ′ on the registration terminal. e registration terminal uses the fuzzy-extractor recovery algorithm to get e permission server packages PK P r , SIG P r , ID U i , s i as the transaction content and commits the transaction proposal to the blockchain network. (iii) Step 3.
e 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 SIG P r : Ver(PK P r , SIG P r , ID U i � � � � � s i )� ? 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 ID U i , s i . (iv) Step 4. After receiving a notification that the transaction is successful, the permission server saves ID U i , I i and sends L i , e i to the registration terminal.
(v) Step 5. After receiving L i , e i , the registration terminal writes L i , e i into the smart card.

Authentication Phase.
In this phase, a remote user and an application server have reached mutual authentication and key agreement. e main steps are provided in Table 6: Step 1. e user U i inserts the smart card and enters ID U i , PW i , and biometric information ω i ′ on the e level of the application server Permission key array Security and Communication Networks 7 client. e client uses the fuzzy-extractor recovery algorithm to get , and then sends X, SID { } to the application server. (ii) Step 2.
e application server S j calculates to get X, ID U i , e i , L i and queries the blockchain node to get the information PK U i , s i corresponding to ID U i . e operation of querying data on the blockchain can be performed through a smart contract [31], which is called the chaincode in Table 5: Granting access permission phase.

U i
Permission server Blockchain network if holds: stores: Stores: L i , e i in the smart card  en, the access permission verification process begins as follows: (1) e application server finds whether the a L i exists in its permission key array, and if it does not exist, the application server rejects the user's authentication request. (2) e application server calculates s i ) and then verifies whether s i ′ is equal to s i . If not, the application server rejects the user's authentication request.
(3) e application server completes the access permission verification process and continues the authentication phase.
e application server takes a random number After that, the application server sends Y, AUTH S j to the client. (iii) Step 3. After receiving the massages, the client calculates and checks whether AUTH U i and the received AUTH S j are equal. If they are equal, U i confirms that S j is legitimate. If not equal, the client stops the session. e client cal- . e client sends M U i to the application server. (iv) Step 4. e application server calculates . e application server checks whether M S j and the received M U i are equal. If they are equal, S j confirms that U i is legitimate and a session key KEY is negotiated by U i and S j . If they are not equal, the application server stops the session.

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. e user reregistration phase is the same as the initial user registration phase. e user revocation phase is described as follows: (i) Step 1. e user sends a revocation request to the permission server offline with his or her identity ID U i and personal information I i . (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 ID U i , the permission server signs message en, the permission server packages SIG P r , ID U i , s i ′ as the transaction content and commits the transaction proposal to the blockchain network. (iii) Step 3. e blockchain network processes the transaction proposal: the endorser node verifies whether the submitter has the right for the operation or not. e endorser node rejects this transaction if it does not. Otherwise, the endorser node verifies the signature SIG P r : Ver(PK P r , SIG P r , ID U i � � � � � s i ′ )� ? 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 ID U i , s i ′ , where s i ′ � 0

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 key I D, 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.

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 B defines the security of our scheme. Referring to the literature [32], we define that A has the following capabilities: (i) e adversary A can enumerate offline all the items in the Cartesian product D id * D pw * D b within polynomial time, where D id denotes the identity space, D pw denotes the password space, and D b denotes the biometric key space. (ii) e adversary A has the capability of somehow learning the victim's identity when evaluating security strength (but not privacy provisions) of our scheme. (iii) e adversary A has full control over the communication channels between participants. (iv) e adversary A 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.

Security and Communication Networks
(v) e adversary A can learn session keys of previous sessions. (vi) When evaluating the security of mutual authentication, the adversary A 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) e adversary A 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).
e adversary A can issue queries to the challenger B and get answers from B. We define the following rules of the game: System building phase: B runs the system building algorithm, initializes the public parameters and hash functions, and then exposes them to the public. Meanwhile, B maintains some lists during the entire process of interacting with A which are empty at the beginning. issues queries of application server's identity ID S j : if ID S j exists in L S , B returns the corresponding public key; otherwise, B randomly generates application server's public and private key pairs and stores them in L S , and then it returns the public key. (4) Send ( t i,j , m): A sends a message to B, which belongs to the t th session of the user U i and the server S j . B receives the message and processes the message according to our scheme and returns the corresponding result.
query to B, A can query the user U i 's private key. B will return U i 's private key SK U i to A from the list L U . (6) CorruptS (ID S j ): if A has already sent ExtractS (ID S j ) query to B, A can query the application server S j 's private key. B will return S j 's private key SK S j to A from the list L S . (7) Reveal ( t i,j ): A issues query for the session key of the session t i,j , and B returns the session key generated by the session t i,j .

Issue Query Phase.
After issuing the queries above, the adversary A begins the challenge phase: A initiates a session key guess for session t i,j . If A has never sent Reveal ( t i,j ) query, challenger B randomly flips a coin to obtain b ∈ 0, 1 { }. If b � 1, the challenger B outputs the session key of the session t i,j . If b � 0, B outputs a random number which length is equal to that of the session key of the session t i,j . 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 Definition 1. AKA-Secure: our scheme is authentication key agreement secure (AKA-Secure) if Adv AKA (A) is negligible for any polynomial-time adversary A.
If A 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 A U i ⟶ S j as A can successfully forge the authentication message sent by the legitimate user U i to the legitimate server S j . Defining the event A S j ⟶ U i as A can successfully forge the response message sent by the legitimate server S j to the legitimate user U i , then we can define the advantage of A attacking the mutual authentication game as Definition 2. MA-Secure: our scheme is mutual authentication secure (MA-Secure) if Adv MA (A) is negligible for any polynomial-time adversary A.

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 adversary A can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability if the ECCDH problem is hard. Proof
Suppose that a polynomial-time adversary A can forge an authentication message sent by the legitimate user to the legitimate server with a nonnegligible probability, then the challenger B 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 U c to the legitimate server S d as a challenge, and the objective of challenger B is to compute SK U c · y · P as SK U c , y are unknown elements in Z * q , where PK U c � SK U c · P, Y � y · P, and PK U c , Y, P ∈ G. In the following, we will demonstrate how B can solve the ECCDH problem by exploiting the adversary A. B runs the system building algorithm: B initializes the public parameters and hash function params �  F p , E, G, P, p, q, h 1 , h 2 and sends them to A. Meanwhile, B maintains several lists L H , L U , L S , which are empty at the beginning. en, A makes the following queries: (1) Hash n (str): B maintains a list L Hn � str, h n (str) , which is empty at the beginning. After receiving the query Hash n (str) from A, B checks whether str, h n (str) exists in the list L Hn . If it exists, B returns the corresponding value h n (str); otherwise, B takes a random number h n (str), stores str, h n (str) in L Hn , and finally returns h n (str) to A.
After receiving the query ExtractU (ID U i ) from A, B checks whether ID U i , SK U i , PK U i exists in L U or not. If it exists, B returns PK U i to A. Otherwise, B executes the operations as follows: as the private key of U i and calculates the public key PK U i � SK U i · P, then stores ID U i , SK U i , PK U i into the list L U , finally returns PK U i to A.
(ii) If i � c, B takes PK U c ← $ G as the public key of U c and sets the private key SK U c to ⊥ (which means an unknown value), then stores ID U c , SK U c , PK U c into the list L U , finally returns PK U c to A. PK S j to A. Otherwise, B takes SK S j ← $ Z * q as the private key of S j , then calculates the public key PK S j � SK S j · P, then stores ID S j , SK S j , PK S j into the list L S , and returns PK S j to A.
processes the received message according to our scheme and sends the result to A.
According to the given instance of the ECCDH problem, B can transform the equation to get and B gets SK S d , PK U c , X, x, Y by searching the query records and gets TK U c by search the hash-query records with the probability of (1/q h ) (q h denotes the number of hashqueries). en, B outputs TK U c − SK S d · PK U c − SK S d · X − x · Y as the solution to the given instance of the ECCDH problem. e probability that B can solve the ECCDH problem is described as follows.
We define the event E 1 as B does not abort in any queries. We define the event E 2 as A successfully forges an authentication message sent by the legitimate user U c to the legitimate server S d . Let l denote the number of bits of biometric information, q s denote the number of sendqueries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user U c to the legitimate server S d . We use Zipf 's law [33] to enhance the security of the security model. C' and s' are Zipf's parameters. We can get Pr(E 1 ) ≥ (1 − (1/q s + 1)) q s and Pr(E 2 |E 1 ) ≥ ε, and then we get

Security and Communication Networks
It implies that B can solve an instance of the ECCDH problem with nonnegligible probability.
is is contradicting with the hardness of the ECCDH problem. erefore, 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 adversary
A can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability if the ECCDH problem is hard.

Proof
Suppose that a polynomial-time adversary A can forge a response message sent by the legitimate server to the legitimate user with a nonnegligible probability, then the challenger B 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 S d to the legitimate user U c as a challenge, and the objective of challenger B is to compute SK S d · x · P as SK S d , x are unknown elements in Z * q , where PK S d � SK S d · P, X � x · P, and PK S d , X, P ∈ G. In the following, we will demonstrate how B can solve the ECCDH problem by exploiting the adversary A. B runs the system building algorithm: B initializes the public parameters and hash function params � F p , E, G, P, p, q, h 1 , h 2 and sends them to A. Meanwhile, B maintains several lists L H , L U , L S , which are empty at the beginning. en, A makes the following queries: (1) Hash n (str): B maintains a list L Hn � str, h n (str) , which is empty at the beginning. After receiving the query Hash n (str) from A, B checks whether str, h n (str) exists in the list L Hn ; if it exists, B returns the corresponding value h n (str); otherwise, B takes a random number h n (str), stores str, h n (str) in L Hn , and finally returns h n (str) to A.
as the private key of U i , then calculates the public key PK U i � SK U i · P, then stores ID U i , SK U i , PK U i into the list L U , and returns PK U i to A. returns PK S j to A. Otherwise, B executes the operations as follows: (i) If j ≠ d, B takes SK S j ← $ Z * q as the private key of S j and calculates the public key PK S j � SK S j · P, then stores ID S j , SK S j , PK S j into the list L S , finally returns PK S j to A.
(ii) If j � d, B takes PK S d ← $ G as the public key of S d and sets the private key SK S d to ⊥ (which means an unknown value), then stores ID S d , SK S d , PK S d into the list L S , finally returns PK S d to A.  (ID S j ) query to B, A can query the application server S j 's private key. If j � d, B aborts the game; otherwise, B searches for S j 's private key SK S j in the list L S and returns SK S j to A. (7) Reveal ( t i,j ): A issues query for the session key of the session t i,j . If t i,j � t c,d , B aborts the game; otherwise, B returns the session key generated by the session t i,j . According to the above queries, if A can successfully forge a response message sent by the legitimate server S d to the legitimate user U c , it means that A can output AUTH S d belonging to the session According to the given instance of the ECCDH problem, B can transform the equation to get and B gets SK U c , PK S d , X, y, Y by searching the query records and gets TK S d by search the hash-query records with the probability of (1/q h ) (q h denotes the number of hashqueries). en, B outputs TK S d − SK U c · PK S d − SK U c · Y − y · X as the solution to the given instance of the ECCDH problem. e probability that B can solve the ECCDH problem is described as follows.
Defining the event E 1 as B does not abort in any queries. Defining the event E 2 as A successfully forges an authentication message sent by the legitimate user U c to the legitimate server S d . Let l denote the number of bits of biometric information, q s denote the number of sendqueries, and ε demote the probability of A successfully forges an authentication message sent by the legitimate user U c to the legitimate server S d . We can get Pr(E 1 ) ≥ (1 − (1/q s + 1)) q s , Pr(E 2 |E 1 ) ≥ ε, and then we get It implies that B can solve an instance of the ECCDH problem with nonnegligible probability.
is is contradicting with the hardness of the ECCDH problem. erefore, 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.
Proof According to Lemma 1 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. erefore, our scheme is MAsecure.

Theorem 2. Our scheme is AKA-secure if the ECCDH problem is hard. Proof
In the proof of Lemma 1, we learn if A can successfully forge an authentication message sent by the legitimate user U c to the legitimate server S d , it means that A sends M U c belonging to the session . en, B can get KEY as the session key of the session t c,d from the query records with probability of Pr(A U i ⟶ S j ). 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. erefore, our scheme is AKA-secure if the ECCDH problem is hard.

Security Requirement Analysis.
e 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 identity ID U i exists in the message SID, M U i , and AUTH S j , where , 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 · PK S j . And it is impossible for the adversary to know ID U i by inferring M U i or AUTH S j because of the oneway property of the hash function. erefore, our scheme can provide user anonymity.

Untraceability.
In our scheme, each session generates new random secret values x and y. Due to the randomness of x and y, the values of message SID, M U i , and AUTH S j which contain ID U i or ID S j are different in each session and the polynomial-time adversary cannot analyze their interconnection even for the same user and server's session. erefore, our scheme can provide untraceability.

Perfect Forward Secrecy.
We assume that the adversary obtains the private keys of the user U i and the application server S j and intercepts the messages X, SID { }, Y, AUTH S j , M U i of a past session between the user U i and the server S j , 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 � h 1 (TK‖X‖Y‖AUTH), where TK � (SK U i + x) · (SK S j + y) · P, and x, y is unknown elements. It means that the adversary must solve an instance of the ECCDH problem. erefore, if the ECCDH problem is hard, our scheme can provide the perfect forward secrecy.

No Smart Card Lose Attack.
According to the definition of the adversary, we assume that the adversary obtains the data A i and B i in the user's smart card by using the sidechannel 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 PW i , R i may output erefore, our scheme can provide three-factor security.
6.3.7. Decentralized Registration. In our scheme, users register their accounts on the blockchain network. e 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. e n-level application server has the permission key array a n , a n+1 , . . . , a max− 2 , a max− 1 , a max }, 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 or the response message so as to make the message pass the verification. erefore, our scheme can resist the modification attack.
6.3.14. Resistance to Temporary Information Attack. We assume that the adversary obtains the temporary session secrets x, y and intercepts the massages X, SID { }, Y, AUTH S j , and M U i of a past session between the user U i and the server S j , but the adversary does not obtain the private keys of the user U i and the application server S j . If the adversary wants to get the session key of that session, it needs to calculate KEY � h 1 (TK‖X‖Y‖AUTH), where TK � (SK U i + x) · (SK S j + y) · P, and SK U i , SK S j are unknown elements. It means that the adversary must solve an instance of the ECCDH problem. erefore, if the ECCDH problem is hard, our scheme can resist the temporary information attack.

Performance Analysis
In this section, we compare the performance of the proposed scheme with other multiserver architecture schemes which include Kou [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. us, 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 curve E over the finite field F p : y 2 � x 3 + ax + b, where p( > 2 160 ) 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]. e point P is an element with large prime order q( > 2 160 ) on the additive group G on E. us, we get the size of the point in G to be 320 bits and the size of the number in Z * q to be 160 bits. e output length of the hash functions h 1 , h 2 is 160 bits and 512 bits. We take e: G 1 × G 1 ⟶ G 2 as the bilinear map used in Kou's scheme [2].

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. e execution time of cryptographic operations comes from He et al.'s compute [37]. e 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. e notations   e 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. Table 8 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%.

Communication Overhead.
In the mutual authentication phase of our scheme, the client and the application server communicate three times, sending X, SID { }, Y, AUTH S j , and M U i , and the application server also queries from the nearest blockchain node to get ID U i , PK U i , s i . Messages XYPK U i ∈ G and their length are both 320 bits. Messages M U i , AUTH S j , s i ∈ H 1 , and their length are both 160 bits. Message SID ∈ H 2 , its length is 512 bits, and ID U i 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]. Ying and Nayak's scheme [36] Xiong et al.'s scheme [11] He and Wang's scheme [4] Odelu et al.'s scheme [5] Computation overhead (ms) at user\server\total Client Server

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 blockchainbased 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.

Data Availability
e data used to support this novel scheme are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this article. Ying and Nayak's scheme [36] Xiong et al.'s scheme [11] He and Wang's scheme [ Ying and Nayak's scheme [36] Xiong et al.'s scheme [11] He and Wang's scheme [4] Odelu et al.'s scheme [5] Communication overhead (number of bits)