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.
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.
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. 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.
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 and an auxiliary information from input biometric information . When another biometric information similar to is input, can be recovered with the help of . According to [25], we define the following two algorithms:(i): fuzzy-extractor generation algorithm. Upon receiving the user’s biometric information , the algorithm will output the random string secret key and public information corresponding to the user’s biometric information.(ii): fuzzy-extractor recovery algorithm. Upon receiving the user’s biometric information and the corresponding public information , the algorithm will output the string corresponding to the user’s biometric information if the error between the two input biometric features is satisfied within the tolerance range, i.e., , where is the tolerance error.
3.3. Elliptic Curve Cryptography
Let be a large prime number and be a finite field of order , then the elliptic curve over the finite field is defined. The point is an element with large prime order on the additive group on . 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 calculate by given and , but it is hard to determine by given and , where , and .(ii)Elliptic Curve Computational Diffie–Hellman (ECCDH) Problem: it is hard to compute as are unknown elements in , where , , and .
Based on the elliptic curve cryptography, we represent the elliptic curve digital signature algorithm ECDSA as the following three functions:(i): Key Generation Function. The function generates a random private key and the corresponding public key .(ii): Signature Function. The function uses the private key to calculate the signature of massage .(iii) Verify Function. The function uses the public key to verify whether is the correct signature of the message m. If is the correct signature of the message , the function will output , otherwise output .
3.4. Notations
We provide the definition of notations appearing in our scheme in Table 1.
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 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. 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.
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 Figure 3.
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 curve over the finite field : , where () is a large prime number. The point is an element with large prime order () on the additive group on . Then, it chooses the following hash function : , , where are the bit length of the hash function’s output. Then, it exposes .
5.2. Server Registration Phase
The server registration phase is as follows, and the main steps are provided in Table 2.
Step 1. The server chooses the identity , selects a random number as the private key, and then calculates its public key . The server uses the private key to sign the message : . Then, the server commits a transaction proposal to the blockchain network. The transaction content is .
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 signature ; 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 are stored in the blockchain.
Step 3. After receiving that the notification of the transaction is successful, the server saves the . 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 Table 3:(i)Step 1. User enters the identity . The registration terminal selects a random number as the user’s private key. Then, it calculates the public key , signs the message : . The registration terminal packages 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 ; 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 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 enters the password , the biometric information . The registration terminal runs the fuzzy-extractor generation algorithm on the input biometric information to get . Then, it calculates , , where is a medium integer (as defined in [30]) which determines the capacity of the pool of the pair against online guessing. Finally, the registration terminal saves in the smart card. The user registration phase is complete.
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 levels of hierarchical access permission.(ii)Step 2. The permission server takes a random number and then publishes .(iii)Step 3. The permission server takes max random numbers as the permission keys.(iv)Step 4. The permission server sets the access permission of the application server is level ().(v)Step 5. The permission server sends to the application server which access permission level is in a secure channel. The permission key array in the application server of each level is listed in Table 4.
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 Table 5:(i)Step 1. The user inserts the smart card and enters , , and biometric information on the registration terminal. The registration terminal uses the fuzzy-extractor recovery algorithm to get and calculate . If , the preliminary verification passes and the smart card outputs ; otherwise, the smart card rejects the current login request. Then, the user inputs personal information . The registration terminal calculates , , signs personal information : , and sends the message to the permission server.(ii)Step 2. After receiving the message, the permission server queries the user’s public key according to the user’s identity from blockchain network, verifies the signature , and rejects the session if the verification fails; otherwise, the permission server gives the user permission level according to the user’s personal information and then takes a random number to calculate . Finally, the permission server signs with its own private key : . The permission server packages 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 : , 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 .(iv)Step 4. After receiving a notification that the transaction is successful, the permission server saves and sends to the registration terminal.(v)Step 5. After receiving , the registration terminal writes into 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 Table 6:(i)Step 1. The user inserts the smart card and enters , , and biometric information on the client. The client uses the fuzzy-extractor recovery algorithm to get to calculate , and if , the preliminary verification passes and the smart card outputs ; otherwise, the smart card rejects the current login request. Then, the client calculates and and takes a random number . The client calculates , , and then sends to the application server.(ii)Step 2. The application server calculates to get and queries the blockchain node to get the information corresponding to . 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 the 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 calculates and then verifies whether is equal to . 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 number and calculate , , . After that, the application server sends to the client.(iii)Step 3. After receiving the massages, the client calculates , and checks whether and the received are equal. If they are equal, confirms that is legitimate. If not equal, the client stops the session. The client calculates and . The client sends to the application server.(iv)Step 4. The application server calculates and . The application server checks whether and the received are equal. If they are equal, confirms that is legitimate and a session key is negotiated by and . If they are not equal, the application server stops the session.
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 and personal information .(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 , the permission server signs message where , . Then, the permission server packages 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 : , 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 , where
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 key 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 and polynomial-time challenger defines the security of our scheme. Referring to the literature [32], we define that has the following capabilities:(i)The adversary can enumerate offline all the items in the Cartesian product within polynomial time, where denotes the identity space, denotes the password space, and denotes the biometric key space.(ii)The adversary has the capability of somehow learning the victim’s identity when evaluating security strength (but not privacy provisions) of our scheme.(iii)The adversary has full control over the communication channels between participants.(iv)The adversary 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 adversary can learn session keys of previous sessions.(vi)When evaluating the security of mutual authentication, the adversary can obtain the private key of the authenticating party but cannot obtain its temporary session secret in the current session, while cannot obtain the private key of the authenticated party but can arbitrarily select its temporary session secret in the current session.(vii)The adversary 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 adversary 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 which are empty at the beginning.(1)Hash(): issues query any string and returns the corresponding hash values and guarantees that the same queries get the same values.(2)ExtractU : maintains a list . When issues queries of the user’s identity : if exists in , returns the corresponding public key; otherwise, randomly generates the user’s public and private key pairs and stores them in , and then it returns the public key.(3)ExtractS : maintains a list . When issues queries of application server’s identity : if exists in , returns the corresponding public key; otherwise, randomly generates application server’s public and private key pairs and stores them in , and then it returns the public key.(4)Send : sends a message to , which belongs to the session of the user and the server . receives the message and processes the message according to our scheme and returns the corresponding result.(5)CorruptU : if has already sent ExtractU query to , can query the user ’s private key. will return ’s private key to from the list .(6)CorruptS : if has already sent ExtractS query to , can query the application server ’s private key. will return ’s private key to from the list .(7)Reveal : issues query for the session key of the session , and returns the session key generated by the session .
6.1.1. Issue Query Phase
After issuing the queries above, the adversary begins the challenge phase: initiates a session key guess for session . If has never sent Reveal query, challenger randomly flips a coin to obtain . If , the challenger outputs the session key of the session . If , outputs a random number which length is equal to that of the session key of the session . guesses the value of and outputs . If , we consider that wins the game. We define the advantage of winning the game as
Definition 1. AKA-Secure: our scheme is authentication key agreement secure (AKA-Secure) if is negligible for any polynomial-time adversary .
If 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 as can successfully forge the authentication message sent by the legitimate user to the legitimate server . Defining the event as can successfully forge the response message sent by the legitimate server to the legitimate user , then we can define the advantage of attacking the mutual authentication game as
Definition 2. MA-Secure: our scheme is mutual authentication secure (MA-Secure) if is negligible for any polynomial-time adversary .
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 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.
Proof
Suppose that a polynomial-time adversary 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 eventually chooses to forge the authentication message sent by the legitimate user to the legitimate server as a challenge, and the objective of challenger is to compute as are unknown elements in , where , , and . In the following, we will demonstrate how can solve the ECCDH problem by exploiting the adversary .
runs the system building algorithm: initializes the public parameters and hash function and sends them to . Meanwhile, maintains several lists , which are empty at the beginning. Then, makes the following queries:(1) : maintains a list , which is empty at the beginning. After receiving the query from , checks whether exists in the list . If it exists, returns the corresponding value ; otherwise, takes a random number , stores in , and finally returns to .(2)Extract U : maintains a list . After receiving the query ExtractU from , checks whether exists in or not. If it exists, returns to . Otherwise, executes the operations as follows:(i)If , takes as the private key of and calculates the public key , then stores into the list , finally returns to .(ii)If , takes as the public key of and sets the private key to (which means an unknown value), then stores into the list , finally returns to .(3)ExtractS : maintains a list . After receiving the query ExtractS from , checks whether exists in , if it exists, returns to . Otherwise, takes as the private key of , then calculates the public key , then stores into the list , and returns to .(4)Send : sends a message belonging to the session to . processes the message according to the following rules:(i)If , processes the received message according to our scheme and sends the result to .(ii)If and , picks a random number , calculates , , and sends to .(iii)If and , calculates , picks a random point , sets to (which means an unknown value), and sends to .(iv)If and , aborts the game.(v)If and , aborts the game.(5)CorruptU : if has already sent ExtractU query to , can query the user ’s private key. If , aborts the game; otherwise searches for ’s private key in the list and returns to .(6)CorruptS : if has already sent ExtractS query to , can query the application. searches for ’s private key in the list and returns to .(7)Reveal (): issues query for the session key of the session . If , aborts the game; otherwise, returns the session key generated by the session .
According to the above queries, if can successfully forge an authentication message sent by the legitimate user to the legitimate server , it means that can output belonging to the session where and . According to the given instance of the ECCDH problem, can transform the equationto getand gets by searching the query records and gets by search the hash-query records with the probability of ( denotes the number of hash-queries). Then, outputs 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 event as does not abort in any queries. We define the event as successfully forges an authentication message sent by the legitimate user to the legitimate server . Let denote the number of bits of biometric information, denote the number of send-queries, and demote the probability of successfully forges an authentication message sent by the legitimate user to the legitimate server . We use Zipf ’s law [33] to enhance the security of the security model. and are Zipf’s parameters. We can get and , and then we get
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 adversary 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 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 eventually chooses to forge the response message sent by the legitimate server to the legitimate user as a challenge, and the objective of challenger is to compute as are unknown elements in , where , , and . In the following, we will demonstrate how can solve the ECCDH problem by exploiting the adversary .
runs the system building algorithm: initializes the public parameters and hash function and sends them to . Meanwhile, maintains several lists , which are empty at the beginning. Then, makes the following queries:(1) : maintains a list , which is empty at the beginning. After receiving the query from , checks whether exists in the list ; if it exists, returns the corresponding value ; otherwise, takes a random number , stores in , and finally returns to .(2)ExtractU(): maintains a list . After receiving the query ExtractU from , checks whether exists in ; if it exists, returns to . Otherwise, takes as the private key of , then calculates the public key , then stores into the list , and returns to .(3)ExtractS : maintains a list . After receiving the query ExtractS from , checks whether exists in or not. If it exists, returns to . Otherwise, executes the operations as follows:(i)If , takes as the private key of and calculates the public key , then stores into the list , finally returns to .(ii)If , takes as the public key of and sets the private key to (which means an unknown value), then stores into the list , finally returns to .(4)Send(): sends a message belonging to the session to . processes the message according to the following rules:(i)If , processes the received message according to our scheme and sends the result to .(ii)If and , picks a random point , sets to (which means an unknown value), picks a random number , and sends to .(iii)If and , picks a random number and calculates , and sends to .(iv)If and , aborts the game.(v)If and , aborts the game.(5)CorruptU : if has already sent ExtractU query to , can query the user ’s private key. searches for ’s private key in the list and returns to .(6)CorruptS : if has already sent ExtractS query to , can query the application server ’s private key. If , aborts the game; otherwise, searches for ’s private key in the list and returns to .(7)Reveal : issues query for the session key of the session . If , aborts the game; otherwise, returns the session key generated by the session .
According to the above queries, if can successfully forge a response message sent by the legitimate server to the legitimate user , it means that can output belonging to the session where . According to the given instance of the ECCDH problem, can transform the equationto getand gets by searching the query records and gets by search the hash-query records with the probability of ( denotes the number of hash-queries). Then, outputs 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 event as does not abort in any queries. Defining the event as successfully forges an authentication message sent by the legitimate user to the legitimate server . Let denote the number of bits of biometric information, denote the number of send-queries, and demote the probability of successfully forges an authentication message sent by the legitimate user to the legitimate server . We can get , , and then we get
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.
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. Therefore, our scheme is MA-secure.
Theorem 2. Our scheme is AKA-secure if the ECCDH problem is hard.
Proof
In the proof of Lemma 1, we learn if can successfully forge an authentication message sent by the legitimate user to the legitimate server , it means that sends belonging to the session to , where . Then, can get as the session key of the session from the query records with probability of . 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 identity exists in the message , , and , where , , and . It is impossible for the adversary to get by inferring because is encrypted by , and at the same time, because is an unknown number, based on the difficulty of the ECDL problem, the adversary cannot get the value of . And it is impossible for the adversary to know by inferring or 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 values and . Due to the randomness of and , the values of message , , and which contain or 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 user and the application server and intercepts the messages , , of a past session between the user and the server , but the adversary does not obtain the temporary session secrets 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 , where , and 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 data and 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 may output the same , where . Thus, we suppose that the adversary gets which makes , and then it calculates , and it cannot verify the correctness of . 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 password , personal biometrics , and the secret data 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 password and the secret data in the smart card or both the user’s personal biometrics and the secret data 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 .(ii)The adversary obtains the user’s personal biometrics and the password : the adversary cannot calculate without the secret data in the smart card. Therefore, the adversary cannot obtain the user’s private key .
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. The n-level application server has the permission key array , 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 , verifies , 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 Lemma 1, no polynomial-time adversary can forge an authentication message sent by the legitimate user to the legitimate server without the private key of and the server’s temporary session secret . 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 Lemma 2, no polynomial-time adversary can forge a response message sent by the legitimate server to the legitimate user without the private key of and the user’s temporary session secret . 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 secrets and . 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 calculate , where is generated by the server based on temporary session secret , and its value in each session is different. If the adversary replays the user’s message in the previous session and , where . The application server can determine whether the authentication message belongs to the current session of this server with user by verifying whether is equal to .(ii)Replay the application server’s message: after receiving the message sent by the server, the user will calculate , where 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 , where . The client can determine whether the response messages belong to the current session by verifying whether is equal to .
Therefore, our scheme can resist the replay attack.
6.3.13. Resistance to Modification Attack
According to the proof of Lemma 1 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 secrets and intercepts the massages , , and of a past session between the user and the server , but the adversary does not obtain the private keys of the user and the application server . If the adversary wants to get the session key of that session, it needs to calculate , where , and , 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
Table 7 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.
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 curve over the finite field : , where 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 is an element with large prime order on the additive group on . Thus, we get the size of the point in to be 320 bits and the size of the number in to be 160 bits. The output length of the hash functions is 160 bits and 512 bits. We take 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) (=4.211 ms): the execution time of a bilinear pairing operation.(ii) (=1.709 ms): the execution time of a scale multiplication operation related to the bilinear pairing.(iii) (=0.0071 ms): the execution time of a point addition operation related to the bilinear pairing.(iv) (=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 .(v) (=0.049 ms): the execution time of an exponentiation operation in .(vi) (=0.442 ms): the execution time of a scale multiplication operation related to the ECC.(vii) (=0.0018 ms): the execution time of a point addition operation related to the ECC.(viii) (=0.0001 ms): the execution time of a general hash function.(ix) (=0.00001 ms): the execution time of a multiplication operation in .(x) (=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. 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%.
7.2.2. Communication Overhead
In the mutual authentication phase of our scheme, the client and the application server communicate three times, sending , and , and the application server also queries from the nearest blockchain node to get . Messages and their length are both 320 bits. Messages , , , and their length are both 160 bits. Message , its length is 512 bits, and 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].
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.
Data Availability
The data used to support this novel scheme are included within the article.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this article.
Acknowledgments
This research was partially supported by the Key Program of the National Natural Science Foundation of China (no. 61772166) and the Natural Science Foundation of Zhejiang Province of China (no. LZ17F020002).