A Blockchain-Based Authentication and Authorization Scheme for Distributed Mobile Cloud Computing Services

Authentication and authorization constitute the essential security component, access control, for preventing unauthorized access to cloud services in mobile cloud computing (MCC) environments. Traditional centralized access control models relying on third party trust face a critical challenge due to a high trust cost and single point of failure. Blockchain can achieve the distributed trust for access control designs in a mutual untrustworthy scenario, but it also leads to expensive storage overhead. Considering the above issues, this work constructed an authentication and authorization scheme based on blockchain that can provide a dynamic update of access permissions by utilizing the smart contract. Compared with the conventional authentication scheme, the proposed scheme integrates an extra authorization function without additional computation and communication costs in the authentication phase. To improve the storage efficiency and system scalability, only one transaction is required to be stored in blockchain to record a user’s access privileges on different service providers (SPs). In addition, mobile users in the proposed scheme are able to register with an arbitrary SP once and then utilize the same credential to access different SPs with different access levels. The security analysis indicates that the proposed scheme is secure under the random oracle model. The performance analysis clearly shows that the proposed scheme possesses superior computation and communication efficiencies and requires a low blockchain storage capacity for accomplishing user registration and updates.


Introduction
In recent years, with the increase in the number of smart mobile devices and the popularization of cloud computing technologies, mobile cloud computing (MCC) as a novel computing paradigm has received extensive attention and significant development [1]. A mobile user can use resource-limited mobile devices to subscribe to and access the remote cloud computing services from different types of service providers (SPs), e.g., Netflix, Apple Music, and Amazon cloud drive [2]. The distributed locations of SPs enable subscribers to access the resources efficiently and conveniently [3]. However, the MCC environment possesses the characteristics of openness and complexity since it is dependent on insecure wireless technology [4]. Hence, to protect the interests of users and SPs, it is essential to provide vital security assurances, especially authentication and authorization [5]. In addition, the quantum-safe authentication protocol for mobile devices has recently been proposed to resist quantum computer attacks [6].
The openness of wireless communication causes the data transmitted between mobile users and SPs to be easy to maliciously intercept and modify [7]. The attacker is likely to impersonate a legitimate mobile user or SP to steal benefits. Thus, authentication has been widely applied to assist users and SPs to identify each other [8][9][10][11][12]. In addition, a kind of cloud service is usually divided into several levels, e.g., 'Bronze', 'Silver', and 'Gold', to satisfy the different subscription demands of users [13,14]. Authorization is essential for SPs to determine the access privilege levels of users as they use a hierarchical cloud service [15]. For example, as shown in Figure 1, a mobile user subscribes to a 'Silver' level of cloud video service from a video SP. When this user accesses the video SP to use the service, the video SP verifies the user's identity and provides a 'Silver'-level service based on the user's access privilege. Therefore, authentication and authorization compose an indispensable security component, i.e., access control, preventing malicious adversaries from accessing resources and low-level users from accessing higher-level services [16]. Mobile users can subscribe to new types of services or update their service levels anytime and anywhere in the distributed MCC environment. However, when a user intends to subscribe to multiple different types of hierarchical services, the user usually needs to register on different SPs and maintain corresponding credentials inconveniently, e.g., accounts, private keys, or passwords. Instead, it is more convenient for users to use only one certificate to access hierarchical services from different SPs. This security requirement is called single registration [17]. The obstacle to single registration is that there is generally no trust relationship among isolated SPs to manage user registration information jointly [18].
In addition to introducing a trusted third party, blockchain is an effective technology for establishing a trust relationship in the distributed environment [19]. The distributed trust is assured by the immutability of the blockchain, as well as automatic and transparent smart contracts [20]. Therefore, blockchain is widely used in access control schemes for distributed scenarios, e.g., information-centric networking (ICN) [21] and Internet of Things (IoT) [22]. Moreover, there are usually two types of access control designs. One is where a subject (requester) sends a transaction to trigger the smart contract deploying the access policy in order to access resources [23][24][25]. This method is not effective enough for the MCC scenarios since the blockchain needs to store the enormous number of resourceaccess transactions submitted by mobile users. Another promising approach is where a subject's access privilege is stored in the transaction for the object (resource) owner to make authorization decisions when the subject accesses resources [26][27][28][29]. This method is more suitable for the MCC scenarios, since it avoids the mobile user submitting frequent access requests to the blockchain.

Motivation and Contributions
Single registration has been widely considered in multi-server authentication schemes. Some centralized multi-server authentication and authorization schemes, using a registration center (RC), also inherit this advantage [9,15]. However, all users and SPs need to fully trust the RC, leading to expensive trust costs and single-point failure [12,30,31]. In the distributed MCC hierarchical service scenarios, we believe that achieving single registration without a trusted third party has the following characteristic: a mobile user just needs to register on an arbitrarily selected SP once and can subscribe to hierarchical services on other SPs concurrently; then, the mobile user can use one credential to access multiple SPs to use services with different levels. In order to make this idea work, the following three security issues need to be considered: (1) when a mobile user registers, identity forgery should be prevented; (2) the mobile user's subscription request should be checked in a trusted way, and not by the user's selected registration SP; (3) subscription fees paid by a mobile user belonging to other SPs cannot be embezzled by the selected registration SP. This paper uses the non-interactive zero-knowledge (NIZK) proof of knowledge and blockchain technology to solve the above issues: (1) the registration SP verifies NIZK proof of knowledge to confirm the validity of user identities; (2) the smart contract checks the user's subscription request and decides whether to complete the registration; (3) other SPs ask for their deserved fees from the selected registration SP based on the tamper-proof distributed ledger. In these ways, all SPs trust that a mobile user registered on an arbitrary SP is also their legitimate subscription user, enabling the single registration.
Using blockchain to design an authentication and authorization scheme possesses the advantages of a low trust cost and single-point-of-failure resistance. However, it is also faces some issues, especially storage overhead [32,33]. In other distributed scenarios, generally, an object owner generates a transaction to record a subject's access privilege [26][27][28][29]. Afterwards, the object or owner make access control decisions by reading the authorization transaction. However, when a subject requests access privileges from multiple object owners, it means that multiple transactions are required to be stored in blockchain, since each transaction only loads one authorization relationship between a subject and an object owner. A subject's multiple authorization transactions aggravate the storage burden of the blockchain. Especially in the MCC scenarios, it is hard to ignore the blockchain storage pressure caused by a numerous number of mobile users and SPs. Therefore, the proposed scheme consolidates multiple authorization relationships between a mobile user (subject) and multiple SPs (object owners) into one transaction. In this way, when a user registers, even if there is a large number of SPs, the different access privileges of a mobile user only need to be stored in one transaction. This reduces the storage overhead of blockchain and improves the system scalability.
In practical applications, user access privileges updates should be considered for user convenience. This enables mobile users to subscribe to new levels of hierarchical services at any time. User access privileges updates, in our scheme, can follow the feature of the registration phase: a mobile user can update access privilege levels on multiple SPs at once, and all updated access privileges only need to be stored in one transaction. However, it requires two additional considerations. First, mobile users should not pay repeatedly when updating their unexpired access privileges. In other words, mobile users can inherit the service time that has not been used up before. Second, the immutability of the blockchain makes it impossible to delete and modify privileges, causing mobile users to reuse previously expired privileges, i.e., double-spending attack [34]. The proposed scheme uses the smart contract deploying flexible update strategies and the world state to solve the above two issues, respectively [35]. The contributions of this work are mainly summarized as follows: • This paper proposes a blockchain-based authentication and authorization scheme for distributed mobile cloud services that enables the mobile user to access different SPs with different access levels by using the same identity and credential. In addition, the mobile user just needs to register on an arbitrary SP once to apply for access privileges from different SPs with the participation of the smart contract. • Each time a mobile user registers or updates, only one transaction needs to be stored in blockchain to record the user's access privileges on multiple SPs. The detailed theoretical and experimental analysis indicates that the proposed scheme alleviates the storage burdens on the blockchain and provides scalability when the number of SPs and users increases. • The proposed scheme utilizes the smart contract to achieve efficient and flexible user access privilege updates, and uses the world state to resist the double-spending attack. We implemented the smart contract algorithms for the registration phase and update phase on Hyperledger Fabric.

Organization
The rest of this paper is organized as follows. Section 2 reviews the related works. Section 3 describes the system model and security model. Section 4 explains the system building block of the blockchain and the transaction structure. In Section 5, we present the details of our proposed scheme. We perform the smart contract experiment in Section 6. Section 7 demonstrates the security analysis of our proposed scheme. The performance analysis is introduced in Section 8. Section 9 discusses our work in depth. And Section 10 summarizes our work and prospects for future work.
The abbreviations and symbols used in this paper are defined in Table 1.

Related Work
This section will present the situation of the multi-server authentication technology for the MCC environment and blockchain-based access control schemes, respectively.

Multi-Server Authentication Schemes for MCC Environment
In 2015, the multi-server authentication scheme designed for the MCC environment was first introduced in Tsai et al.'s paper [17]. However, [3,8] indicated that this scheme [17] is vulnerable to server impersonation attack. Their schemes avoid the faults existing in Tsai-Lo's scheme and achieves lower computational overhead and communication costs. In 2021, ref. [36] presented an efficient dynamic reciprocal authentication scheme using a one-time password to achieve multi-factor authentication, which is good at preventing the social engineering attack and replay attack. Ref. [4] not only considers scalability but also avoids using computation-intensive pairing operations on resource-constrained mobile devices. New users or servers are free to join the system, and there are no expensive pairing operations in their scheme to enhance efficiency.
Recently, some designs that combine authentication with authorization have been proposed for the MCC scenario. Ref. [9] combined attribute-based encryption (ABE) and multi-server authentication for MCC healthcare applications. A user with the corresponding access privileges is able to authenticate with the server by decrypting parameters encrypted with ABE. However, the user side needs to perform costly pairing operations of ABE. Ref. [15] designed an authentication and authorization scheme for a hierarchical cloud service. In the authentication phase, SPs determine users' access privileges in order to reject unauthorized access or authenticate with users. In addition, mobile users are allowed to subscribe to new levels of cloud services on RC at any time.
All above-mentioned schemes suffer from the weakness of single-point failure due to the use of trusted third parties. Some blockchain-based authentication schemes do not require a trusted third party. Ref. [11] proposed a blockchain-based authentication scheme for multi-server architectures. Their scheme allows users to select any server to upload the registration certificate to blockchain for the single registration. Ref. [12] presented a blockchain-based authentication scheme for the MCC environment. This scheme is more efficient in computation but has a higher communication cost than Xiong et al.'s scheme [11]. However, neither of the decentralized designs consider the extra authorization property for hierarchical services by using smart contracts.
More recently, ref. [13] designed an excellent distributed access control framework for pervasive edge computing (PEC) services. Their scheme combines the advantages of decentralization, authentication, and authorization. The PEC server determines the level of service that the user can access according to the plaintext authorization token forwarded by the base station. They adopted an innovative method that utilizes multi-authority ABE to implement decentralized asynchronous authentication. However, their scheme is deficient in user anonymity and privilege updates.

Blockchain-Based Access Control Schemes
This section mainly reviews the blockchain-based access control schemes utilizing transactions or tokens, which is similar to our scheme. Ref. [26] proposed a blockchainbased user private data protection scheme where the user sends a transaction that records the access permissions of the service to their data. In addition, the service can send an access transaction to trigger a permission check, and then access user data from an off-chain database. In CapChain [27], a device owner sends a transaction that delegates device operational capabilities to a user. When a user accesses a device, the device can query the authorized transaction to determine the user's permissions. FairAccess [22,37] enables the owner of the device to send a transaction that loads their access control policy in order to grant a subject the access token. Then, the subject meeting the access control condition sends a transaction to prove its permissions, and uses the token to access the device.
In BlendCAC [28], the object owner launches a transaction to save a token that records the subject's authorized operations for the object. After receiving the access request from a subject, the object fetches the token from the smart contract to make the decision to grant access to the object. Ref. [29] proposed an improved method that divides the token of BlendCAC into multiple tokens, and each token is associated with an operation. This improvement achieves a more flexible capability delegation, but it leads to the need for more transactions. In SBAC [21], a content provider generates an access token based on a content requester's attribute score, and sends a transaction to securely transfer the token on blockchain. Then, the content requester can access the content after the content provider verifies the validity of the received token from blockchain. Ref. [23] proposed a smart-contract-based access control scheme where an access control contract records the authorization relationship of one subject-object pair. The subject can send a transaction for the verification of its access request, and the access control contract will return the validated result to both the subject and object.
These blockchain-based access control schemes solve the threats in traditional centralized access control schemes, e.g., a central leak, single-point failure, and internal attack. However, when a subject wants to access the resources of many object owners, it is required to make multiple requests to those object owners. This is very inconvenient for the subject. Furthermore, these object owners generate multiple transactions or tokens separately, stored in blockchain, to record the subject's various access permissions. It also increases the storage overhead of the blockchain. Combined with our discussion in Section 1.1, applying blockchain to implement an authentication and authorization scheme for MCC scenarios should consider convenient single registration and low storage overhead.

System Model
The two types of participants and the blockchain network in the proposed scheme are shown in Figure 2.

1.
Mobile users (U i ): Mobile users can use mobile devices to access hierarchical cloud services on all SPs after registering on an arbitrarily selected SP.

2.
Service providers (S j ): Each SP in our system needs to be a semi-trusted party. After verifying the mobile users' identities, privileges, and service periods, S j provides the hierarchical cloud services for them.

3.
Blockchain network: The proposed scheme adopts an access-restricted but efficient consortium blockchain. SPs constitute the blockchain network as the nodes, and SPs also generate transactions that record users' identity and subscription information (access privileges, service periods, and service fees paid).

Adversary Model
We assume that there exists a probabilistic polynomial time (PPT) adversary A. The purpose of the adversary A is that A can successfully impersonate an SP or mobile user to authenticate with another mobile user or SP. In addition, A can perform the following feasible attacks: A can control the public channel between U i and S j ; that is, the adversary can inject, block, eavesdrop, and tamper with all of the transmitted messages through the public channel.
A can obtain either the mobile device or the password, which are the two authentication factors. Moreover, A can extract the secret information from the mobile device obtained by the adversary. Then, the password space |D PW | can be enumerated by A using offline dictionary attacks.
A is probably a legal but malicious mobile user.

Security Requirements
According to the previous multi-server authentication schemes [3,8,38], our authentication component should satisfy the following security requirements, including mutual authentication, user anonymity and un-traceability, user-friendly password local updates, multi-factor security, resistance to a wrong password login/update attack, and resistance to a reply attack. Furthermore, according to the latest centralized authentication and authorization scheme [15], we believe that a blockchain-based authentication and authorization scheme for the MCC hierarchical service scenario may consider the following security properties.

1.
Single registration: Mobile users just need to register on an arbitrarily selected SP once to access cloud services provided by multiple SPs.

2.
Hierarchical access control: In practical applications, the services provided by an SP are usually divided into different access rights. The trial services can be freely accessed by any legitimate user. Other high-level services need to be purchased by mobile users. In the authentication phase, an SP can determine mobile users' access privileges to authorize users to access the corresponding level of service.

3.
Access within limits of permission: This guarantees that unauthorized mobile users cannot access the services above their permission level. Moreover, the SP cannot provide services below users' access privileges.

4.
Efficient and flexible update user access privilege: Mobile users can update their access privileges at any time. However, expired users can only access the trial service, and even if a mobile user only updates the service privilege on one SP, the user's access privileges on other SPs must be updated at the same time.

System Building Blocks
This section will introduce zero-knowledge proof of knowledge, Hyperledger Fabric, the transaction process, the structure of transactions, the service subscription list, and the smart contracts in our scheme.

Zero-Knowledge Proof of Knowledge
In a zero-knowledge proof of knowledge (ZkPoK) protocol [39], a prover can convince a verifier that a statement is true, and the verifier only learns the validity of the statement (without disclosing much else). Following the notation in [40,41], let ZkPoK{(x) : y = g x } indicate a ZkPoK protocol that proves the knowledge of x ∈ Z * q such that y = g x . The ZkPoK protocol is able to be transformed into being noninteractive by using the Fiat-Shamir heuristics [42].

Hyperledger Fabric
The proposed scheme uses Hyperledger Fabric, or Fabric for short. Fabric focuses on the distributed storage of data in ledgers, which is different from other cryptocurrency blockchain platforms. The smart contract, also called chaincode in Fabric, implements the application logic of the modification, writing, and check, and Fabric deploys a key-value database to store the world state that is the most recent value of transactions. In addition, a modular membership service provider (MSP) used in Fabric makes it more convenient to manage the access rights of organizations. MSP also issues credentials and manages the identities of all nodes in the organizations. The organizations that are joined into the blockchain can own four types of nodes with different functions (peers , clients, endorser, and orders) [35]. The structure of Fabric is shown in Figure 3.

Transaction Process
The transaction process is shown in the Figure 3. The SP invokes CLI or SDK (clients) to upload the transaction to the endorser on the blockchain. Each endorser calls the smart contract to check the correctness of the transaction content, which checks the payment of mobile users in our scheme, and then returns the signed endorsement result to the clients. After collecting enough endorsements, the clients submits the transaction to the orders node. Then, the orders node executes a consensus algorithm, e.g., RAFT [43], to pack the received transactions into blocks, and orders broadcasts blocks to peers nodes that store these blocks. The latest transactions are stored in a key-value database, which can be queried by an SP using the keyword immediately.

Transaction Structure
To reduce the number of transactions, a transaction needs to record a user's identity information and subscription information on multiple SPs. A flexible transaction structure was used in our scheme, which is similar to the tabular structured ledger [44,45]. In this way, a transaction records the authorization relationships between a user and multiple SPs. The abstract structure and data structure in the transaction are shown in Figure 2 and Algorithm 1 separately.

Service Subscription List
In our proposed scheme, L = [L S , L P , L D , L C ] is a service subscription list that is used to provide hierarchical access control and subscription during the authentication, registration, and update phase. The detailed structure of L is illustrated in Table 2. Table 2. Service subscription list L.

S n Lev Sn Day Sn C Sn
The entry S j , Lev Sj , Day Sj , C Sj in Table 2 is explained as follows. U i subscribes to a service with the level of Lev Sj on S j for Day Sj days used, and costs the service fee C Sj .
Assume that there are j existing SPs and n-j unjoined SPs. L S = [S 1 ,...,S j ,...,S n ] is an array of all SPs.
L P is a non-negative integer array that indicates the user's access privileges on all SPs. In L P , the access privileges published on the website are mapped onto non-negative integers. For instance, the levels [0, 1, 2, ...] represent the access privileges {trial-user, elementary-user, intermediate-user, ...} separately. In addition, Lev Sj represents the access privilege of the user U i on S j . L D is a non-negative array that indicates the days where U i intends to use the privilege service on all SPs. Furthermore, Day Sj represents the number of days where the user U i uses the privilege service on S j . L C is a non-negative integer array that indicates service fees for all privilege services paid by U i . Moreover, the service fee that U i pays to S j is C Sj = UP sj × Day Sj (unit price UP sj for a day of privilege service can be found on the website of S j ).
Furthermore, it is flexible for the new SP to join our system. The sub-array [S j+1 , ..., S n ] indicates the unjoined new SPs, whose values in L P , L D , and L C are all initialized to 0. After a new SP is added to the MCC system, U i can use the trial privilege service of the new SP, even if the user is not registered on it. However, as U i wants to access higher privilege services on the new SP, the mobile user must update their access privileges.

Smart Contracts in Our Scheme
Our scheme uses four smart contract algorithms, namely Init_Ledger(), Check_ registration&subscription(), Read(), and Check_user_update() in Algorithms 1-4. Algorithm 1 Init_Ledger() is called only once when deploying the smart contract. Algorithm 2 is called to check the validity of user registration and subscription information. Algorithm 3 is called to read the most recent value of transactions (world state) from the blockchain. Algorithm 4 is called to check the validity of the user access privilege update.
1: var U User = PID i , PK ui , ID r sj , PK r sj , L, T 1 , S ui , S r sj ; 2: Take out the latest transaction U * about key U.PID i from key-value database to check the uniqueness of user identity. 3: if U * ! = Null then 4: return Error("user is registered"); 5: end if 6: Take out the service subscription list L from U. 7: for j = 1 → j = n do %Traverse all SPs in L 8: UP sj is one-day unit price of the access privilege L P [j] on S j ; 9: 10: if cost! = L C [j] then 11: return Error("L is not correct or user did not pay enough"); 12: end if 13: end for%Finishing checking user subscription information. 14: Storing the transaction U in the blockchain. 15: Finishing user registration and subscription. 16: return Success("Mobile user is successfully registered !"); Algorithm 3 Read(PID i ) 1: var user User = Get_WorldState(PID i ); 2: %The key-value database stores the world state, which is the last transaction data about the key PID i . 3: if user == Null then 4: return Null, fmt.Errorf("PID i is not in the blockchain"); 5: end if 6: return user; Check user update 1: var N User = PID i , PK ui , ID u sj , PK u sj , L , T 1 , S ui , S u sj ; 2: Take out the old transaction O from the blockchain. 3: if O == Null then 4: return Error("user is not registered"); 5: end if%Report an error and exit the program. 6: Take out the new service subscription list L from N. 7: Take out the old service subscription list L from O. 8: for j = 1 → j = n do if then return Error; 21: end if%Cannot downgrade in unexpired service. 22: 33: end if 34: end for%Finish checking the new service subscription list L . 35: Storing the updated transaction N in the blockchain. 36: return Success("Mobile user is successfully updated !");

The Proposed Scheme
The proposed scheme consists of five phases: an initialization phase, user registration and subscription phase, authentication and authorization phase, user-friendly password update phase, and user access privilege update phase.

Initialization Phase
In the initialization phase, the authorized SPs will be joined into the identical blockchain network as nodes. MSP, i.e., the manager of consortium blockchain, selects an additive group of point G with order q, where P is a generator of G, and six hash secure where l 0 , l 3 , l 4 , l 5 are the output bit length of the hash functions. Each SP S j generates a private key SK sj ∈ Z * q , calculates its public key PK sj = SK sj · P, and stores the private key into its secret memory. S j registers on MSP with a public key PK sj . On the website, S j publishes its own privilege unit price list, which records the current one-day unit price of each different privilege service. On the blockchain, all smart contracts Algorithms 1-4 are initialized and deployed. MSP publishes the parameters {G, q, P, PK sj , h 0 , h 1 , h 2 , h 3 , h 4 , h 5 }.

User Registration and Subscription Phase
Each SP shares the identical ledger of the blockchain, so users can select the currently closest SP for registration and subscribing services. The Table 3 illustrates the phase of user registration and subscription. Table 3. User registration and subscription phase.
PK ui PK r sj L T 1 ) Then, S j submits the transaction {PID i , PK ui , ID r sj , PK r sj , L, T 1 , S ui , S r sj } to the blockchain. Smart contract Algorithm 2 checks whether U i has not registered, and the correctness of L.
If it holds, one registration transaction is written into the blockchain.
Step 1: U i chooses an SP S r j closest to the mobile device MD, selects a random number SK ui ∈ Z * q , and generates a service subscription list L that records users' desired privileges, service periods, and amount of payment. In addition, MD calculates the public key PK ui = SK ui · P and PID i = h 5 (PK ui ), where PID i is the pseudonym of U i . Then, MD generates a signature S ui = Sig(SK ui , PID i T 1 L), where T 1 is the current timestamp, and generates a NIZK proof of knowledge π: Finally, U i transmits {PID i , PK ui , S ui , L, reg, T 1 , π} to S r j and the fees paid to purchase services to S r j through a secure channel, where reg is the registration requirement.
Step 2: After receiving the message from U i at the time T 2 , S r j checks an inequality | T 2 − T 1 |< ∆T, where ∆T is the maximum allowable transmission delay. If the inequality is satisfied, S r j validates π to determine the validity of PK ui . If it holds, S r j confirms whether the signature Ver(PK ui , S ui , PID i T 1 L) = 1 is correct. If it is correct, S r j checks whether the fees paid by U i are equivalent to the sum of all costs in array L C . If they are equivalent, S r j calculates a signature S r sj = Sig(SK r sj , PID i ID r sj PK ui PK r sj L T 1 ). Then, S r j submits the user registration transaction {PID i , PK ui , ID r sj , PK r sj , L, T 1 , S ui , S r sj } to the blockchain. Here, T 1 is the registration time of U i .
Step 3: An overview of the transaction processing process is presented in Section 4.3. The transaction belonging to U i is verified by a smart contract Algorithm 2. Algorithm 2 checks whether U i has not registered, recalculates the entire cost, and confirms whether C Sj = UP sj × Day Sj is correct for each SP, i.e., whether U i pays enough service fees for each hierarchical service. If both conditions are satisfied, one transaction that records the user identity and subscription information is stored in the blockchain. If any of the judgment conditions in Steps 2 and 3 above are not satisfied, S r j will interrupt the session and refund service fees to users. Finally, S r j sends {registration success} to U i through a secure channel.
Step 4: Upon receipt of the message, U i inputs PW ui into the mobile device MD. Then, MD chooses a random number b i and computes and L into the secret memory of the mobile device.
Step 5: All SPs detecting the generation of a new transaction in blockchain ask for their deserved user subscription service fees from S r j off chain according to the identity ID r sj of the acceptance SP and the list L in the transaction.

Authentication and Authorization Phase
Before accessing an SP S j , U i needs to implement mutual authentication with S j . At the same time, S j also refers to the service subscription list L to determine which level of service Lev Sj the user can access within the validity service period Day Sj . Table 4 illustrates the phase of authentication and authorization.
Step 1: , and checks whether V 0 and V are equal. If they are not equal, MD interrupts the operation. Otherwise, MD extracts the private key SK ui . Then, MD determines the user's access privilege lv ∈ L P on S j according to the list L. If the privilege of U i has expired or is not paid for, U i can only access the trial privilege service, lv = 0. Otherwise, U i can access the unexpired privilege service, lv = Lev Sj . Next, MD generates a random number α ∈ Z * q and computes X = α · P, Then, U i sends the messages {X, M 1 , T 3 } to S j through a public channel.
Step 2: Upon receipt of the message, S j verifies whether | T 4 − T 3 |< ∆T, where T 4 is the timestamp when messages were received from U i . If the inequality is satisfied, S j calculates PID i ID sj st lv = M 1 ⊕ h 4 (SK sj · X). Using PID i , the latest transaction belonging to U i can be queried by S j . S j calls the smart contract Algorithm 3 Read(PID i ) to extract the transaction {PID * i , PK * ui , ID r * sj , PK r * sj , L * , T * 1 , S * ui , S r * sj } from blockchain. Then, S j obtains PK * ui from the transaction, and verifies whether the equation st · P = X + h 1 (X PID i ID sj T 3 lv) · PK * ui is satisfied. If it is satisfied, S j confirms that U i is a legal user.
Step 3: Then, S j checks the user's access privilege lv and the validity period of service Day Sj requested by the U i . If T 4 − T * 1 < Day Sj ∈ L * D , this indicates that the U i is within the validity period for using the privilege service at level Lev Sj , lev = Lev Sj . If T 4 − T * 1 ≥ Day Sj ∈ L * D , this indicates that U i has expired or the privilege service (Day Sj = 0) on S j has not been paid for, and that only the trial privilege service, lev = 0, can be used. Then, S j checks whether lev = lv. If the equation is satisfied, S j provides lev level of service for U i . S j generates a random number β ∈ Z * q and computes Y = β · P, key = h 3 (PID i ID sj X Y st β · X lev), M 2 = MAC(key, PID i ID sj Y X T 4 lev). If any of the judgment conditions in Steps 2 and 3 above are not satisfied, S j will interrupt the session. After that, S j sends {Y, M 2 , T 4 } to U i via a public channel.
Step 4: After receiving the message {Y, M 2 , T 4 } from S j at the time T 5 , MD verifies whether | T 5 − T 4 |< ∆T. If it holds, MD sets lev = lv. MD computes key = h 3 (PID i ID sj X Y st α · Y lev ), M 2 = MAC(key , PID i ID sj Y X T 4 lev ). Then, MD checks whether M 2 matches with the received M 2 . If M 2 holds, U i authenticates with S j . Meanwhile, U i is also allowed to access the service with the privilege level lv on S j in the service period. Otherwise, U i fails to authenticate with the S j .
If V 0 =V, extracts SK ui and PID i , determines lv ∈ L P on S j , according to list L. Then, generates α ∈ Z * q , computes X = α · P, . S j uses the pseudonym PID i to extract the transaction {PID * i , PK * ui , ID r * sj , PK r * sj , L * , T * 1 , S * ui , S r * sj } from key-value database, verifies st · P ? = X + h 1 (X PID i ID sj T 3 lv) · PK * ui . If it holds, accepts U i . Then, checks lv and service period.
If it holds, accepts S j .

User-Friendly Password Update Phase
When U i wants to update PW i , the user just needs to perform the following steps in the mobile device.
Step 1: U i inputs PID i and PW ui into MD. Then, MD computes Z i = h 0 (PID i PW ui b i ), SK ui T 1 = F i ⊕ Z i , and V 0 = h 3 (h 2 (SK ui T 1 Z i )), and checks whether V 0 and V are equal. If they are not equal, MD interrupts the phase of the password update. Otherwise, U i inputs a new password PW .
Step 2: Step 3: Finally, U i stores F i and V in MD to replace F i and V, respectively.

User Access Privilege Update Phase
The mobile user can select the closest SP to flexibly update the access privileges on n SPs in or not in the validity periods, and the mobile user can inherit the service periods that have not been used up before. Our scheme applies two arrays, p and t, to record the new privileges applied by U i and the extended service periods of U i , respectively, on all SPs.
Step 1: First, U i chooses an SP S u j closest to the mobile device MD, inputs its PID i and PW ui , obtains T 1 , PK ui , π, and SK ui , and sets two arrays, p and t, to determine the new levels of services desired and the extended service periods. Then, U i chooses the current timestamp T 1 and uses Algorithm 5 to obtain the new service subscription list L with the input of L, T 1 , T 1 , p, and t. After that, U i calculates S ui = Sig(SK ui , PID i T 1 L ).
Finally, U i submits {PID i , PK ui , S ui , L , renew, T 1 , π} and service fees to S u j through the secure channel, where renew is the updated requirement. if RT = 0 then %U i has expired or the service on S j has not been bought. 8: if t[j] == 0 then %U i do not buy the service period on S j this time. if t[j]! = 0 then %U i buy the service period on S j . 12: end if%U i buy new privilege services. 14: end if 15: if RT > 0 then %U i has not expired on S j . 16: if p[j] < L P [j] then return Error; 17: end if%Privileges cannot be reduced during service periods. 18: if t[j] == 0 then %Do not extend the use period on S j . 19: Step 2: After receiving the message, S u j checks the inequality |T 6 − T 1 | < ∆T, where T 6 denotes the timestamp of when S u j received the updated message. If the inequality is satisfied, S u j validates π to determine the validity of PK ui . If it holds, S u j confirms whether the signature Ver(PK ui , S ui , PID i T 1 L ) = 1 is correct. If it is correct, S u j checks whether fees paid by U i are equivalent to the sum of all costs in array L C . If they are equivalent, S u j calculates S u sj = Sig(SK u sj , PID i ID u sj PK ui PK u sj L T 1 ). Then, S u j submits update transaction {PID i , PK ui , ID u sj , PK u sj , L , T 1 , S ui , S u sj } to the blockchain.
Step 3: The overview of the transaction processing process is presented in Section 4.3. The update transaction belonging to the U i is verified by a smart contract Algorithm 4. Algorithm 4 checks whether the U i has been registered and whether the cost L C of the L is set correctly. If both conditions are satisfied, one transaction that records the user update information is stored in the blockchain. If any of the above conditions in Steps 2 and 3 are not satisfied, S u j interrupts the session and refunds fees to users. Finally, S u j sends {update success} to U i through the secure channel.
Step 4: After receiving the message, . Finally, U i stores F * i , V * , and L in the secret memory of MD to replace F i , V, and L, respectively.
Step 5: All SPs, detecting the generation of a new transaction in blockchain ask for their deserved user update service fees from S u j off chain according to the identity ID u sj of the acceptance SP and the list L in the transaction.

Example
To illustrate our algorithms, we give an example that implements smart contracts Algorithms 1-4 on the blockchain platform. Since Algorithm 1 is only called once in the initialization phase, we mainly present the realization of Algorithms 2-4, which are used in the user registration and subscription phase, authentication and authorization phase, and user access privilege update phase.

Blockchain Platform
In the proposed scheme, the blockchain platform is implemented on Hyperledger Fabric 2.3, with the functions of ledger initialization, user registration, read transaction, and user update. The four functions are achieved by the smart contract. We set up two peer nodes that store transaction data independently and an order node that can publish transactions in the blockchain. A Hyperledger Fabric-sdk-java was used to operate the transaction and invoke the smart contract. The platform device information is shown in Table 5, and the browser page of Hyperledger Fabric shows an overview of our blockchain in Figure 4. In addition, Figure 5 indicates the invoked result of the registration Algorithm 2 on the virtual machine. However, for explaining our experiment more clearly, we used a java application, as shown in Figure 6, to invoke smart contract algorithms from the blockchain. In the java application, we used the string to replace the static encoding result of identities, public keys, and signatures, to focus on the dynamic check of the service subscription list.

Implementation of User Registration and Subscription
In the registration phase, as shown in Table 6, U i chooses L S = [S 1 , S 2 , S 3 , S 4 , S 5 ], where [S 4 , S 5 ] are unjoined SPs. In the list L 1 , U i sets the privileges L P = [1, 1, 3, 0, 0] to be accessed and the days L D = [1, 2, 3, 0, 0] to use the privilege service, and S 1 to S 5 set the unit price UP of privilege services to be accessed as [1, 4, 3, 0, 0]. According to the calculation formula C Sj = UP × Day Sj , the cost array L C is set to [1,8,9,0,0]. The arrays L P , L D , L C of the unjoined new SPs S 4 , S 5 should be set to 0 in the L 1 . In this experiment, the field TIME in the transaction of the registration phase was set to the integer 1 (TIME needs to be a timestamp in the practical application). Figure 6. The smart contracts invoked in the java application: the "Register" button is clicked, the smart contract Algorithm 2 Check_registration&subscription() is invoked through Fabric-sdkjava, and registration information is entered in the text box as input algorithm parameters. Then, the smart contract returns the running result. The same is true for the button "Read" of Algorithm 3 Read() and the button "Update" of Algorithm 4 Check_user_update(). Table 6. The list L 1 in the user registration and subscription phase.
Then, U i sends service fees 18 and registration information that contains L 1 to S 3 , which is currently close to U i . S 3 checks π, S ui , and whether the sum of L C is equal to 18. If it holds, S 3 signs the registration information and submits it to the blockchain by invoking the smart contract Algorithm 2, as shown in Figure 6. Algorithm 2 checks whether the user has not registered and whether L 1 is correct. The returned result of invoking Algorithm 2 was "Mobile user is successfully registered !", which indicates that the service fees paid for each SP passed the check, and that the registration transaction has been written into the blockchain. In addition, we successfully queried the registration transaction with the key "user" in the CouchDB. Finally, S 1 and S 2 can ask for their deserved service fees 1 and 8 from S 3 off chain according to list L 1 in the transaction.

Implementation of User Access Privilege Update
In the user access privilege update phase, U i updated the service subscription list L 1 submitted in the registration phase. As shown in Table 7, the settings of SPs in the new service subscription list L 2 remained unchanged. The field TIME in the transaction of the update phase was set to the integer 2. The change in the field TIME in two phases indicated that one day has passed, and U i extended the usage time of the privilege service on S 3 by 1 day. Thus, the days L D to use the privilege service should be set to [0, 1, 3, 0, 0]. Since the time of using the service of S 1 was 0, the user's privilege to access S 1 should be set to 0. U i updated the user's privilege on S 2 to 2, and the privilege on S 3 remained as 3. In brief, the privileges L P = [0, 2, 3, 0, 0] were updated in the list L 2 . The unit price UP of privilege services access in the update phase was set to [0, 5, 3, 0, 0]. According to Algorithm 5, U i calculated the costs on S 1 , S 2 , and S 3 , which were 0 × 0, (5 − 4) × 1, and 3 × 1. The service on S 2 is only upgraded, and the price difference needs to be made up. U i pays for one day to extend the service period on S 3 . Therefore, the cost array L C should be set to [0, 1, 3, 0, 0]. Similar to the registration stage, the arrays L P , L D , L C of S 4 , S 5 should be set to 0. Table 7. The list L 2 in the access privilege update.
Then, U i sends service fees 4 and update information that contains L 2 to S 1 , which is currently close to U i . S 1 checks π, S ui , and whether the sum of L C is equal to 4. If it holds, S 1 signs the update information and submits it to the blockchain by invoking the smart contract Algorithm 4, as shown in Figure 6. Algorithm 4 checks whether the user has registered and whether L 2 is correct. The returned result of Algorithm 4 was "Mobile user is successfully updated !", which indicates that the amount paid for each SP passed the check, and that the update transaction has been written into the blockchain. In addition, we successfully queried the update transaction with the key "user" in the CouchDB. Finally, S 2 and S 3 can ask for their deserved service fees 1 and 3 from S 1 off chain according to list L 2 in the transaction.

Security Analysis of the Proposed Scheme
This section proves that the proposed scheme satisfies the security requirements defined in Section 3 using the random oracle model. Since the authentication phase is executed in an insecure public channel, and other phases are implemented in the secure channel, this section shows the resistance to security threats in the authentication phase.
Security Model. Following the literature [11,39,46] a security model was designed for the proposed scheme, which was demonstrated by a game played by a probabilistic polynomial time (PPT) Turing machine and a PPT adversary A. We used the instances ∏ S U and ∏ S S to represent the mobile user oracle and the SP oracle, respectively, in session S. The adversary A was allowed to perform the following attack capabilities: 1.
RegisterU i -Oracle : A issues this inquiry to simulate registering as a legal mobile user U i with the identity PID i . generates the access privilege lv and the private key and public key of U i , records them in the list L U , and returns PID i and lv to A.

2.
RegisterS j -Oracle : A issues this inquiry to simulate registering as a legal SP S j with the identity ID sj . generates the access privilege lev and the private key and public key of S j , records them in the list L S , and returns ID sj and lev to A.

3.
Send-Oracle(ϑ, S, ϑ , M) : A issues this inquiry to simulate that the participant ϑ transmits the message M to the oracle ∏ S ϑ , and returns an answer specified by the protocol to A.

4.
Execute-Oracle : A issues this inquiry to simulate using all passive attacks, and returns all messages transmitted between U i and S j .

5.
There are three corruption queries: (a) Corrupt(PID i , PW i ) : A issues this inquiry to simulate the password leakage attack, and returns the mobile user password PW i to A.
Corrupt(PID i , MD i ) : A issues this inquiry to simulate the mobile device MD i loss attack, and returns secret parameters stored in MD i to A. (c) Corrupt(S j ) : A issues this inquiry to simulate the SP compromise attack.

Definition 1.
Matching sessions: If the session in ∏ S U and the session in ∏ S S are the same session S = S , the peer identity of ∏ S S is Pid S = U, the peer identity of ∏ S U is Pid U = S, and two instances have both been accepted, the two session S and S are said to be matching. Definition 2. Security authentication protocol: The secure authentication scheme needs to satisfy the following properties: 1.
∏ S U and ∏ S S are matching sessions, and two instances accept each other.

2.
The probability that A is accepted as ∏ S S by ∏ S U is negligible.

3.
The probability that A is accepted as ∏ S U by ∏ S S is negligible.
MAC-Game: there exist two participants, the challenger and the MAC oracle ∏ M , where ∏ M possesses the key. The challenger is able to input any messages to the MAC oracle ∏ M to obtain an MAC value as many times as needed. The probability for the adversary to win the MAC-Game is assumed to be Pr adv [MAC]. The MAC-Game has the following steps:

Formal Security Analysis
In this section, the adversary A and Turing machine play a game to show that if A can successfully impersonate a mobile user or SP to pass authentication with a nonnegligible probability, then a PPT can be constructed to solve the potential hard problems with a non-negligible probability using the abilities of A.
Our proposed protocol is reviewed as below: 1.
Lemma 1 (Secure Mobile User Authentication). In our proposed scheme, if ∏ S S is accepted, solving the DL problem is infeasible, all hash functions are ideal random functions, and the probability that a PPT adversary A forges a legitimate mobile user authentication message is negligible.
Proof. We assume that a PPT adversary A is able to forge a legitimate mobile user authentication message to pass authentication with a non-negligible probability. Afterwards, a PPT Turing machine is able to win the DL problem with a non-negligible probability by using the abilities of A. The probability that the advantage for A wins the DL problem is assumed to be Pr adv [DL].
Giving an example of a DL problem, the Turing machine needs to calculate the α ∈ Z * q using the known values X = α · P and P. In addition, all oracle queries of A must be answered by to simulate an environment where A cannot distinguish from the real proposed scheme. Therefore, all initialization parameters {G, q, P, PK sj , h 0 , h 1 , h 2 , h 3 , h 4 , h 5 } should be generated and published by . The private key of the challenger PID c is assumed to be SK c , and answers all oracle queries of A as follows: 1.
After receiving the message m i , inspects whether [m i , h] is kept in L hi . If it is kept, returns h to A. Otherwise, randomly generates a number h, maintains the tuple [m i , h] in the list L hi , and returns h to A.

2.
RegisterU i -Oracle: In this query, maintains a list L U initialized to empty. inspects if [PID i , PK ui , SK ui , lv] is kept in L U . If it is kept, returns PID i and lv to A. Otherwise, operates as follows: If PID i = PID c , sets SK ui =⊥ and obtains the public key PK ui and access privilege lv from the mobile user oracle ∏ S U . Then, maintains the tuple [PID i , PK ui , SK ui , lv] in the list L U , and returns PID i and lv to A.
If PID i = PID c , generates an access privilege lv, randomly selects a number SK ui ∈ Z * q , and computes the public key PK ui = SK ui · P. Then, the tuple [PID i , PK ui , SK ui , lv] is maintained in the list L U , and returns PID i and lv to A.

3.
Send-Oracle(U i , S, S j , M) : In this query, A transmits the first message M 1 to . M 1 is decrypted by to obtain PID i , PK ui and lv. Then, is executed following the specification of the proposed protocol and returns M 2 .

4.
Send-Oracle(S j , S, U i , M) : In this query, A first checks whether PID i =PID c is satisfied. If not, is executed following the specification of the proposed protocol and returns M 1 to A. Otherwise, asks ∏ S U for M 1 , and then returns M 1 to A.

5.
Execute-Oracle: In this query, returns all messages transmitted between U i and S j to A. 6.
Corrupt(ID i , PW i ): In this query, asks ∏ S U for the password PW i and returns it to A.

7.
Corrupt(ID i , MD i ): In this query, asks ∏ S U for the secret parameters in mobile devices MD i and returns it to A. 8.
Corrupt(S j ) : In this query, returns the private key SK sj of the SP S j to A.
If A can successfully falsify an authentication message M 1 = {X, M 1 , T 3 } sent to , the adversary will pass user authentication, where M 1 = (PID i ID sj st lv) ⊕ h 4 (α · PK sj ), and st = α + H 1 SK ui mod q. Due to the forking lemma [47], a counterfeit authentication message M 1 = {X, M 1 , T 3 } is forged by A using the repeat of the simulation with the value of h 4 (α · PK sj ). Therefore, two Equations (2) and (3) are shown as follows: Calculating the two equations, the following Equation (4) is obtained: According to the above analysis, (st − st )(H 1 − H 1 ) −1 is the solution of the DL problem. A further analysis of the probability is shown below. If A successfully forges a legitimate authentication message with the non-negligible probability η, can solve the DL problem. If A cannot achieve forgery, γ represents the probability that A wins the DL problem. Hence, the probability that the advantage for A wins the DL problem is computed as the following Equation (5), similar to that of the paper [46]: where n s represents the number of queries sent by A. Since the probability η is nonnegligible and the probability γ is negligible, Pr adv [DL] is also non-negligible. Thus, has a non-negligible probability of winning the DL problem using the abilities of A. However, this is a contradiction to our assumption. In our scheme, there is no PPT A that can successfully forge a legal authentication message of mobile users with a nonnegligible probability.
Lemma 2 (Secure SP Authentication). In our proposed scheme, if ∏ S U is accepted, solving the DL problem is infeasible, all hash functions are ideal random functions, and the probability that a PPT adversary A forges a legal SP authentication message is negligible.
Proof. We assume that a PPT adversary A is able to forge a legitimate SP authentication message to pass authentication with a non-negligible probability. Afterwards, a PPT Turing machine is able to win the latent game of MAC (MAC-Game) with a non-negligible probability by using the abilities of A without knowing the key.
All oracle queries of A must be answered by to simulate an environment where A cannot distinguish from the real proposed scheme. Therefore, all initialization parameters need to be generated and published by , except the private key SK cs of the challenger ID cs . The oracle queries H i (m i ), RegisterU i -Oracle, Reveal-Oracle, and Execute-Oracle are answered by operating in the proof of Lemma 1, and answers other oracle queries of A as follows:

1.
RegisterS j -Oracle: In this query, maintains a list L S initialized to empty. inspects if [ID sj , PK sj , SK sj , lev] is kept in L S . If it is kept, returns ID sj and lev to A. Otherwise, operates as follows: (a) If ID sj = ID cs , sets SK sj =⊥ and obtains the public key PK sj and the access privilege lev from the SP oracle ∏ S S . Then, maintains the tuple [ID sj , PK sj , SK sj , lev] in the list L S and returns ID sj and lev to A. (b) If ID sj = ID cs , randomly selects a number SK sj ∈ Z * q , sets lev, and computes the public key PK sj = SK sj · P. Then, maintains the tuple [ID sj , PK sj , SK sj , lev] in the list L S and returns ID sj and lev to A.

2.
Send-Oracle(U i , S, S j , M): In this query, A transmits the first message M 1 to . Then, is executed following the specification of the proposed protocol and returns M 2 . After receiving M 2 from A, asks ∏ M to test and check the received MAC value in M 2 , and returns the result of verification.

3.
Send-Oracle(S j , S, U i , M): In this query, A first checks whether ID sj = ID cs is satisfied.
If not, is executed following the specification of the proposed protocol and returns M 1 to A. Otherwise, terminates the MAC-Game.

4.
Corrupt(S j ): In this query, checks whether ID sj = ID cs is satisfied. If it is not satisfied, returns the private key SK sj of the SP S j to A. Otherwise, terminates the MAC-Game.
If A can successfully falsify an SP authentication message M 2 = {Y, M 2 , T 4 } sent to , the adversary will pass SP authentication, where M 2 = MAC(key, PID i ID sj Y X T 4 lev). After receiving M 2 = {Y, M 2 , T 4 }, transmits the message m 0 = {PID i ID sj Y X T 4 lev} and a random m 1 whose bit length is equal to m 0 to ∏ M . ∏ M returns an MAC value MAC(key, m b ) to . According to the value of M 2 , is able to inspect whether the value of MAC(key, m b ) is MAC(key, m 0 ) or MAC(key, m 1 ) to obtain b = 0 or b = 1. If A successfully forges a legitimate SP authentication message with a non-negligible probability η, can win the MAC-Game. If A cannot achieve forgery, has a probability of 1/2 to win the MAC-Game. Hence, the probability that the advantage for A wins the MAC-Game is computed as the following formula 6, similar to that of the paper [46]: Since the probability η is non-negligible, Pr adv [MAC] is also non-negligible. Thus, has a non-negligible probability of winning the MAC-Game using the abilities of A. However, this is a contradiction to our assumption. In our scheme, there is no PPT A that can successfully forge a legal SP authentication message with a non-negligible probability. Proof. Lemma 1 and Lemma 2 can confirm that there is no PPT A that is able to successfully forge a legitimate mobile user or SP authentication message with a non-negligible probability if solving the DL problem is infeasible and MAC is the ideal random function. Thus, our proposed scheme is secure based on Definition 2.

Single Registration
A mobile user, interested in multiple services, just needs to selects the arbitrary (nearest) SP S r j to submit the identity, subscription information, and service fees. (1) S r j validates π to determine that the user is the owner of SK ui , ensuring the validity of the user identity. In addition, the smart contract Algorithm 2 checks the uniqueness of the user identity by reading the information about PID i on the blockchain. (2) Algorithm 2 inspects the correctness of the user's subscription information in the list L and decides whether to store the transaction in the blockchain to accomplish the single registration for the mobile user.
(3) Other SPs can ask for their deserved user registration service fees from S r j off chain according to the identity ID sj of the acceptance SP and the list L in the transaction. The three phases are secure under the ZkPoK protocol, the automatic and transparent smart contract, and the tamper-proof distributed ledger.

Mutual Authentication
Based on Theorem 1, there is no PPT adversary A that is able to successfully forge a legitimate mobile user or SP authentication message with a non-negligible probability if solving the DL problem is infeasible and MAC is the ideal random function. Hence, mutual authentication between mobile users and SPs can be guaranteed.

User Anonymity and Un-Traceability
To provide user anonymity on the blockchain, the pseudonym PID i = h 5 (PK ui ) is used in the transaction. PID i is only bound to the user's subscription information, and not the real identity. In the public channel, PID i is protected by h 4 (α · PK sj ). The random number α will change for each authentication session. PK sj is calculated by SK sj , but SK sj is confidentially stored in the memory of SP. After intercepting the message {X, M 1 , T 3 }, A either guesses the value of α or solves the DL problem. Both operations are practically infeasible. Thus, A cannot obtain the mobile user's true identity and track the communication process of a mobile user.

Two-Factor Security
There exist two security factors in our scheme. One is PW, and the other is the mobile device. When only having the password without a mobile device, the adversary cannot accurately generate each cryptographic parameter to forge the mobile user authentication message. On the other hand, when the mobile device is lost or stolen by an adversary, then A is able to extract the secret parameters from the mobile device. During offline dictionary attacks, the password space |D PW | is divided into 1024 candidate passwords |D PW /1024| [48,49]. Consequently, A is still unable to obtain the correct password.

Resistance to Reply Attack
The timestamp and challenge0-response mechanism are used in our proposed scheme to prevent the replay attack. Mobile user authentication message {X, M 1 , T 3 } and SP authentication message {Y, M 2 , T 4 } are protected by timestamps T 3 and T 4 . After an SP or the mobile user receives the timestamp, the validity of T 3 or T 4 will be checked. Hence, the user and SP will only accept each other in the current session. 7.2.6. Resistance to Wrong Password Login/Update Attack If A enters the wrong password PW , the mobile device will calculate a wrong V 0 = h 3 (h 2 (SK ui T 1 Z i )), and check whether V 0 and V are equal. This equation is untenable, and the wrong password login/update will be refused.

Hierarchical Access Control
The service provided by each SP is divided into several levels, e.g., 'Bronze', 'Silver', and 'Gold'. A mobile user can subscribe to different levels of hierarchical services on multiple SPs. The service subscription list L records service levels (access privileges) and service periods that users want to subscribe to. Users only need to determine service levels that they are interested in and the service usage time in L, and submit L to the blockchain for the inspection of Algorithm 2. Users are not required to interact with SPs in advance. In the authentication and authorization phase, the SP looks up the mobile user's service level (access privilege) and service period in L to determine which level of service the user can access.

Access within Limits of Permission
In the authentication and authorization phase, U i sends the access privilege lv to SP. Then, SP reads the service subscription list L from the blockchain and checks the user's access privilege lv and the validity period of service. If U i has not expired on the S j with the privilege Lev Sj , T 4 − T * 1 < Day Sj ∈ L * D , SP sets lev = Lev Sj to allow users to access privilege services. If U i has expired on the S j , T 4 − T * 1 ≥ Day Sj ∈ L * D , SP sets lev = 0 to provide the free trial service. More importantly, SP needs to check whether lv = lev. If they are not equal, this indicates that U i is trying to access beyond its authority or has expired, and the SP will reject the access request and interrupt the session. In addition, if the SP sets the wrong privilege lev, the session will also be interrupted.

Efficient and Flexible Update User Access Privilege
If U i has expired or the service has not been purchased on an SP, the mobile user can subscribe to all levels of services. Even if U i is still within the validity period of the service on an SP, the mobile user can also subscribe to the service period of new privilege services, and the user only needs to make up the price difference without having to fully pay again. Moreover, Algorithm 5 will set up the user's new access privileges and service periods on all SPs simultaneously in order to generate a correct new service subscription list L . L is sent to S u j and stored in a new transaction after inspection. Hence, our scheme only needs U i to send an update request, and the user's service levels on all SPs can be updated concurrently.

Resistance to Double-Spending Attack
The SP reads the world state to obtain the latest transaction to ensure that mobile users can only use the latest access privileges. Each transaction records the registration and update time of user access privileges. Thus, the improper behavior of mobile users using expired privileges can be detected by the SP.

Security Features Analysis
This section evaluates the proposed scheme by comparing its security features with several related schemes [8,12,13,15]. Ref. [8] is the representative multi-server authentication scheme for MCC services. Ref. [15] is the latest RC-based multi-server authentication and authorization scheme for MCC hierarchical services. Ref. [12] is the newest blockchain-based multi-server authentication scheme for the mobile cloud environment. Ref. [13] is the latest distributed multi-authority ABE-based authentication and authorization scheme for cloud hierarchical services. Table 8 compares the security features among five schemes. The comparison results indicate that our scheme has better security attributes than the above related schemes. In this section, we compare the computation costs and communication efficiencies of our proposed scheme with the related multi-server authentication schemes for the MCC environment [8,12,15].

Computation Comparison Analysis
This section compares the computation costs of our proposed scheme with other schemes [8,12,15] in the authentication phase, which is used most frequently. To obtain a credible result of the computation cost comparison, we continue to follow the running time of the computing operations mentioned in He et al.'s scheme and Xiong et al.'s scheme [8,15]. Using software implementation, the running time of one MAC operation and one fuzzy extraction are approximately equal to the running time of two hash operations and one scalar multiplication operation, respectively [12,50]. Table 9 indicates the notations, as well as their running time, of all of operations in our scheme and other related schemes.  In Table 10, we calculated the computation cost of our scheme and the previous relevant schemes [8,12,15]. From the comparison in Tables 8 and 10, and Figure 7, we conclude that, compared with the latest blockchain-based multi-server authentication scheme [12], our scheme is slower, but we use smart contracts to achieve the additional authorization function. In comparison to the representative multi-server authentication scheme [8] and the newest centralized multi-server authentication and authorization scheme [15], the computation cost in our scheme is reduced by 42% and 30%, respectively.

. Communication Comparison Analysis
This setcion evaluates the proposed scheme by comparing its communication cost with several related schemes [8,12,15]. We only compare the communication cost in the authentication phase used most frequently. Table 11 indicates the bit length of the data structure used in our scheme and other relevant schemes. In addition, we assume that the bit length of the access control level lv is 3, which is enough to represent eight kinds of access privileges. In the authentication phase of our scheme, the first message {X, M 1 , T 3 } requires 320 + (32 + 32 + 160 + 3) + 32 = 579 bits, and the second message {Y, M 2 , T 4 } requires 320 + 160 + 32 = 512 bits. The total communication cost of our scheme is 579 + 512 = 1091 bits. Table 12 illustrates the total communication cost of other related schemes in the authentication process. From the comparison in Table 12 and Figure 8, we find that our scheme is the most efficient in communication overhead. The reason for this is that our scheme requires minimal message exchange rounds.

Blockchain Storage Overhead Analysis
In this section, we analyze the impact of the number of transactions on the blockchain storage in our scheme and other related schemes. In other blockchain-based access control scenarios, a transaction is usually used to record one authorization relation between a subject and an object owner [21,22,[26][27][28][29]. This type of transaction in this paper is called one to one. In our scheme, a transaction records multiple authorization relations between a mobile user (subject) and multiple SPs (object owners). This type in this paper is called one to many. The transaction structure {PID i , PK ui , ID r sj , PK r sj , L, T 1 , S ui , S r sj } is a one to many type in our scheme. Reasonably, {PID i , PK ui , ID r sj , PK r sj , S n , P, Day, C, T 1 , S ui , S r sj } is supposed to be a one to one type in our scheme.

The Blockchain Storage Overhead in Our Scheme
In our blockchain structure, m mobile users are off chain and n SPs maintain the blockchain network. one to one type means that n transactions record a user's access privileges on n SPs. one to many type means that one transaction record a user's access privileges on n SPs. In the registration phase, the total number of transactions in the one to one type is mn 2 . m users need mn transactions completing registration that are dispersedly stored on n SPs. The total number of transactions in the one to many type is mn. m users need m transactions completing registration that are dispersedly stored on n SPs. In the update phase, when each mobile user updates k times in total, the total number of transactions is shown in Table 13. Our scheme enables users to update the privileges on all SPs at once by using one transaction. However, if the one to one type updates the privileges on all SPs simultaneously, a user needs n transactions each time. We discuss the actual storage overhead of blockchain in both types. Suppose the bit length of the access privilege p is 3 bits, the service period Day is 10 bits, the cost C is 10 bits, and the signature is 320 bits. We test that one transaction of Fabric 2.3 in CouchDB is approximately 0.3KB. According to Table 11, the storage sizes of a transaction in one to one and one to many types are 3889 bits and 3834 + 55n bits separately. Thus, the total storage overhead of blockchain in one to one and one to many type is (k + 1) 3889 mn 2 bits and (k + 1) (3834 mn + 55 mn 2 ) bits, respectively. Figure 9 shows that, compared with the one to one type, the one to many type in our scheme requires less storage overhead and possesses a higher scalability when the number of SPs grows. Figures 10 and 11 indicates the relationship between the total storage of blockchain and the growth in the number of users in the one to one type and ours under a different number of SPs. It can be seen that the blockchain storage overhead in ours is much less than in the one to one type.

The Blockchain Storage Overhead in Related Schemes
Other blockchain-based access control schemes possess different blockchain structures and transaction structures. Hence, we conducted a qualitative analysis for the number of transactions to indicate the impact on blockchain storage. In addition, granting permission and accessing resources are two functions common to all schemes. Thus, we compared the number of transactions required for these two functions with other schemes. Assume that there are m subjects, n object owners, and x external nodes. We consider the situation where a subject wants to request access permissions from all object owners. In this way, there is the largest number of transactions in blockchain. Table 14 summarizes the number of transactions that grant permission in the one to one type and one to many type in three usual cases of blockchain structures.

•
Case 1 : n object owners constitute the blockchain network. • Case 2 : x external nodes constitute the blockchain network. • Case 3 : m subjects and n object owners constitute the blockchain network.  Table 15 shows the comparison results of the number of transactions with other schemes in the functions of granting permission and accessing resources [21,22,[26][27][28][29]. It is worth noting that accessing resources is usually the most frequent operation. Therefore, if each resource access requires a transaction, it also puts a burden on the storage of the blockchain. Our scheme and some other schemes [27][28][29] avoid this insufficiency. IoT mn(m + n) 1 [26] IoT mnx 1 [27] IoT mn(m + n) 0 [28] IoT mn(m + n) 0 [29] IoT mn(m + n) 0 Ours MCC mn 0

Discussion
In this section, we discuss the difference between the RC-based authentication and authorization scheme and our blockchain-based authentication and authorization scheme, single registration, blockchain storage, access privilege updates, and double-spending attack.
In the traditional RC-based multi-server authentication and authorization scheme, the server verifies the identity of the user and concurrently verifies whether the user has correct access privilege or not [9]. The integration of authentication and authorization at the same stage makes the cloud service system more efficient [15]. However, such a centralized scheme requires a trusted third party to issue identity and permission credentials for users, which makes it faces a single point of failure and have a high trust overhead. In our blockchain-based multi-server authentication and authorization scheme, the user can register on the arbitrary SP and obtain corresponding identity and permission credentials. It has the fault-tolerant capability to resist a single point of failure. In addition, our scheme uses the blockchain to establish the distributed trust relationship in the MCC environment, which avoids the use of RC, which needs to be completely trusted.
Single registration in the RC-based authentication and authorization scheme is straightforward. The user only needs to register on RC once and obtain one credential. All SPs trust the validity of credentials issued by RC for users and make authorization decisions according to the privileges in the credential. However, it is challenging to achieve single registration in our blockchain-based scheme without a trusted third party that distributes credentials for users. On the one hand, users need to prove the validity of the registration information submitted, e.g., public keys generated by themselves. On the other hand, SPs need to trust that a user registered on an arbitrary SP obtains the credential that can be used to access their services. Therefore, we used the NIZK proof of knowledge to force users to prove the discrete logarithm knowledge of the public key. Moreover, an automatic and transparent smart contract was applied to complete the single registration without the trusted third party.
Although the blockchain can enhance the security of the MCC system and reduce trust overhead, it has the issue of high storage overhead. Each node in the blockchain needs to store the same ledger, which leads to expensive storage overhead and restricts the system's scalability. In particular, the total storage capacity is n 2 transactions, where the blockchain, which is maintained by n servers, needs to store a user's n transactions that, respectively, record different access rights on n servers. Based on this storage feature, our scheme consolidates the user's multiple access privileges into one transaction. In this way, the total storage capacity is n transactions since n servers, which maintain the blockchain, just need to store n transactions. In the MCC scenarios, the number of mobile users in the tens of millions emphasizes the importance of reducing the storage pressure on the blockchain.
The proposed scheme enables the mobile user to update access privileges anytime and anywhere. It brings convenience to users as well as the risks of double-spending attacks. In the access privilege update phase, the user submits new transactions that record new privileges to the blockchain. After the smart contract check, new transactions are written to the blockchain to complete the privileges update. However, old transactions that record old privileges cannot be deleted and modified due to the immutability of the blockchain. If no processing is made, the adversary can use the privileges in old transactions to access the service. In this paper, we used the world state to prevent this double-spending attack. The world state is stored in the key-value database and is the last transaction data about the key. In our solution, we used the user's unique pseudonym "PID" as the key. In the authorization phase, the SP both uses the key "PID" to read the newest transaction content that records the newest privilege of the user and makes corresponding authorization decisions. In this way, the double-spending attack is prevented.

Conclusions
This paper proposes a blockchain-based authentication and authorization scheme for MCC hierarchical services. By using the zero-knowledge proof and the smart contract, we achieved user single registration without a trusted third party, which reduces trust overhead and resists the single point of failure. In addition, only one transaction is needed to load all authorization relationships between a mobile user and all SPs, which significantly reduces the number of transactions required to complete registration and updates. We implemented a flexible update strategy that provides convenience for users and avoids multiple updates. In addition, we used the world state to prevent the reuse of expired privileges in old transactions, i.e., the double-spending attack, and our scheme has more useful security features than several related schemes. The performance analysis indicates that our proposed scheme is efficient and scalable.
In our scheme, transactions are stored on the transparent blockchain in plaintext. The user's registration information is publicly visible. Hence, our proposed scheme must work on the permissioned blockchain and cannot be directly used on the permissionless blockchain. In future work, we will focus on decentralized authorization with the storage of access privileges in the form of ciphertext, and we will introduce anonymous credential technology to enhance privacy.