Blockchain for Systems Management and CybersecurityView this Special Issue
Research Article | Open Access
Miqi Wu, Lin You, Gengran Hu, Liang Li, Chengtang Cao, "A Blockchain-Based Hierarchical Authentication Scheme for Multiserver Architecture", Security and Communication Networks, vol. 2021, Article ID 5592119, 20 pages, 2021. https://doi.org/10.1155/2021/5592119
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. 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.
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  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  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 . Xiong et al.  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.  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 , 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 , 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  and Ren et al.’s scheme ). 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.  proposed a neural network-based multiserver authentication system. In 2014, Chuang et al.  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.  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  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.  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  using smart cards that resisted various attacks. In 2015, Tsai and Lo  proposed an efficient authentication scheme for distributed mobile cloud computing services. Later in 2017, Odelu et al.  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  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.  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.  proposed a blockchain-based two-factor authentication scheme for cross-domain authentication. Mohsin et al.  proposed a biometric-based patient identity authentication scheme that solved the problem of storing biometric information on the blockchain. Ren et al.  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 . 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 , IoT , healthcare , and smart vehicles .
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.  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 , 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 .
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 , 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.
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 .
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 ) 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 , 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 , 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.
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