# Secure Multifactor Authentication and Access Control Mechanism for Electronic Bill Service in a 5G Cloud-Fog Hybrid Architecture

Authors: Zhenyang Guo; Yueyu Zhang; Jin Cao; Xiongpeng Ren; Xingwen Zhao; Hui Li
Journal: Security and Communication Networks
 (2022)

---

## Abstract

The electronic bill service was greatly encouraged by electronic commerce and paperless bills. However, the massive authentication and authorization access requests from users in the electronic bill services cannot be efficiently processed by a conventional client/server-based scheme during the 5G era. This paper proposes a secure multifactor authentication and access control scheme tailored for electronic bill service in a 5G cloud-fog hybrid architecture. The proposed scheme can realize many security properties, including mutual authentication, privacy protection, batch authentication, authorization and revocation of authority, and resistance to multiple protocol attacks. Moreover, the scheme has the desired performance compared to similar schemes. Finally, we used BAN logic and Scyther to analyze and verify the proposed protocol, and the result shows that the proposed scheme is stable and can achieve the previous security goals.


---

## Body

## 1. Introduction

### 1.1. Background and Motivation

With the continuous enlargement of the e-commerce and the mobile communication technology such as the fifth generation (5G), electronic bill have also become a requisite part of people’s quotidian lives. At the same time, some countries have issued regulations to promote the application of paperless receipt systems. Existing paper invoices have problems such as low efficiency, high cost, high management risk, poor user experience, difficulty to keep, and are not conducive to resource protection. The implementation of electronic bill will help further reduce invoice costs and invoice claims. Electronic bill, convenient for the storage and retrieval of financial and taxation departments, can promote environmental protection and reduce the time for users to issue invoices [1, 2]. Additionally, benefited from the low latency and wide coverage of 5G, 5G can support more and more new type applications and provide better services for them. For electronic bill service, 5G cloud-fog hybrid architecture, as a multiserver architecture can make it more reliable and scalable [3–5].However, electronic bill services are still facing many new security and performance challenges.First, the electronic bill service system is constructed by the state taxation department. To promote the evolution of paper bill to electronic bill, the national tax authorities should complete the functions of the electronic bill service system promptly and improve the reliability, availability, and security of the electronic bill service system to meet the growing needs of citizens for electronic bill.Second, due to the openness of the Internet, when users access the electronic bill service system, the data transmitted by the user may be intercepted, tampered, replayed, and modified by attackers [6]. Therefore, the electronic bill service system must establish an efficient and secure authentication mechanism to prevent illegal users from malicious attacks and protect the system security. Moreover, in the era of 5G, the network structure comes into the cloud-fog hybrid structure. The calculation requirements of the cloud server can be reduced by the fog server. In addition, the electronic bill service is a multiserver, cross-domain network service [6, 7], and thus, the electronic bill service also needs to consider its network environment when designing an authentication mechanism.Finally, in order to prevent malicious users, devices, and service systems [8] from illegally accessing and calling electronic bill services to obtain illegal benefits, the electronic bill service system should perform authority control and authority identification for different users, devices, and service systems.In summary, studying a secure authentication and access control scheme for electronic bill service in the 5G cloud-fog hybrid architecture is required.


### 1.2. Threat Model

This paper mainly considers an authentication scenario based on proxy signature with four entities: user, proxy signer, original signer, and verifier. We define that the electronic bill device is the proxy signer, the electronic bill authentication server is the original signer, and the electronic business server is the verifier. For convenience, we abbreviate the electronic bill service device as theDevice, the electronic bill authentication server as the Service, and the electronic business server as the Server.First, the user registers to theService. The Device also applies for proxy signature authority from the Service. After registration, the user chooses a Device to bind. Once the user binds to the Device, the Device will obtain the user’s authentication vector. Before the user accesses the Server, the user needs to sign in and get the TOKEN from the Device. The Server once receives the TOKEN from the user, and it can verify the proxy signature by the TOKEN.We define thatDevice constitutes the fog layer, and Service and Server work in the cloud layer. Since users can communicate with fog nodes through a local area network (LAN) and with cloud nodes through wide area network (WAN) [9, 10], the Dolev–Yao model [11] in this paper is suitable.(i)
AdversaryA can obtain and attempt to modify, intercept, or delete information on the channel.(ii)
AdversaryA can know how the protocol is transmitted and obtain public parameters.(iii)
AdversaryA cannot obtain the user password, biometric feature, and user private key simultaneously.


### 1.3. Proposed Approach

In this paper, we propose a multifactor authentication scheme, which effectively overcomes the limitations of previous methods. We take advantage of the proxy signature mechanism, which effectively disperses the authentication pressure of the authentication center, reduces the cost of authentication signaling, and protects the privacy of the user’s authority.To verify the security of our protocol, we used informal analysis and formal verification including Burrows–Abadi–Needham (BAN) logic and the official Scyther simulation. Moreover, we compared the previous scheme [12–15] with ours in several aspects, such as calculation cost, storage cost, and communication cost.


### 1.4. Key Contributions and Results

First, we design a new cloud-fog hybrid electronic bill services structure in 5G network shown as Figure1. Subsequently, we propose a revocable anonymous proxy signature scheme in which the Service allows Devices as a proxy signer to give the user’s TOKEN as a proxy signature. We also propose a multifactor authentication for the user. Moreover, our scheme provides a multifactor update phase and proxy signer privacy revocation phase.Figure 1
Electronic bill service security authentication and authority control system.The contributions are described in detail as follows: (1) A new electronic bill service structure is designed based on the cloud-fog hybrid in 5G network. (2) A multifactor user identity authentication scheme is proposed based on biometrics, passwords, public and private keys, and one-time passwords. (3) By adopting the proxy signature mechanism, the computational overhead of our scheme is lower than that of the similar schemes. (4) The proposed scheme can realize the privacy protection of user biometrics, passwords, public and private keys, and one-time passwords. (5) The electronic bill business server can deal with TOKEN in batch processing. (6) The BAN logic and Scyther tool have been employed to analyze and verify the security of our scheme.The chapters of this article consist as follows: we investigate the related work in Section2. The system model and secure goal of our scheme are presented in Section 3. Section 4 offers the process of our scheme. The security and performance analysis is given in Sections 5 and 6, respectively. Finally, we summarize the paper in Section 7.


## 1.1. Background and Motivation

With the continuous enlargement of the e-commerce and the mobile communication technology such as the fifth generation (5G), electronic bill have also become a requisite part of people’s quotidian lives. At the same time, some countries have issued regulations to promote the application of paperless receipt systems. Existing paper invoices have problems such as low efficiency, high cost, high management risk, poor user experience, difficulty to keep, and are not conducive to resource protection. The implementation of electronic bill will help further reduce invoice costs and invoice claims. Electronic bill, convenient for the storage and retrieval of financial and taxation departments, can promote environmental protection and reduce the time for users to issue invoices [1, 2]. Additionally, benefited from the low latency and wide coverage of 5G, 5G can support more and more new type applications and provide better services for them. For electronic bill service, 5G cloud-fog hybrid architecture, as a multiserver architecture can make it more reliable and scalable [3–5].However, electronic bill services are still facing many new security and performance challenges.First, the electronic bill service system is constructed by the state taxation department. To promote the evolution of paper bill to electronic bill, the national tax authorities should complete the functions of the electronic bill service system promptly and improve the reliability, availability, and security of the electronic bill service system to meet the growing needs of citizens for electronic bill.Second, due to the openness of the Internet, when users access the electronic bill service system, the data transmitted by the user may be intercepted, tampered, replayed, and modified by attackers [6]. Therefore, the electronic bill service system must establish an efficient and secure authentication mechanism to prevent illegal users from malicious attacks and protect the system security. Moreover, in the era of 5G, the network structure comes into the cloud-fog hybrid structure. The calculation requirements of the cloud server can be reduced by the fog server. In addition, the electronic bill service is a multiserver, cross-domain network service [6, 7], and thus, the electronic bill service also needs to consider its network environment when designing an authentication mechanism.Finally, in order to prevent malicious users, devices, and service systems [8] from illegally accessing and calling electronic bill services to obtain illegal benefits, the electronic bill service system should perform authority control and authority identification for different users, devices, and service systems.In summary, studying a secure authentication and access control scheme for electronic bill service in the 5G cloud-fog hybrid architecture is required.


## 1.2. Threat Model

This paper mainly considers an authentication scenario based on proxy signature with four entities: user, proxy signer, original signer, and verifier. We define that the electronic bill device is the proxy signer, the electronic bill authentication server is the original signer, and the electronic business server is the verifier. For convenience, we abbreviate the electronic bill service device as theDevice, the electronic bill authentication server as the Service, and the electronic business server as the Server.First, the user registers to theService. The Device also applies for proxy signature authority from the Service. After registration, the user chooses a Device to bind. Once the user binds to the Device, the Device will obtain the user’s authentication vector. Before the user accesses the Server, the user needs to sign in and get the TOKEN from the Device. The Server once receives the TOKEN from the user, and it can verify the proxy signature by the TOKEN.We define thatDevice constitutes the fog layer, and Service and Server work in the cloud layer. Since users can communicate with fog nodes through a local area network (LAN) and with cloud nodes through wide area network (WAN) [9, 10], the Dolev–Yao model [11] in this paper is suitable.(i)
AdversaryA can obtain and attempt to modify, intercept, or delete information on the channel.(ii)
AdversaryA can know how the protocol is transmitted and obtain public parameters.(iii)
AdversaryA cannot obtain the user password, biometric feature, and user private key simultaneously.


## 1.3. Proposed Approach

In this paper, we propose a multifactor authentication scheme, which effectively overcomes the limitations of previous methods. We take advantage of the proxy signature mechanism, which effectively disperses the authentication pressure of the authentication center, reduces the cost of authentication signaling, and protects the privacy of the user’s authority.To verify the security of our protocol, we used informal analysis and formal verification including Burrows–Abadi–Needham (BAN) logic and the official Scyther simulation. Moreover, we compared the previous scheme [12–15] with ours in several aspects, such as calculation cost, storage cost, and communication cost.


## 1.4. Key Contributions and Results

First, we design a new cloud-fog hybrid electronic bill services structure in 5G network shown as Figure1. Subsequently, we propose a revocable anonymous proxy signature scheme in which the Service allows Devices as a proxy signer to give the user’s TOKEN as a proxy signature. We also propose a multifactor authentication for the user. Moreover, our scheme provides a multifactor update phase and proxy signer privacy revocation phase.Figure 1
Electronic bill service security authentication and authority control system.The contributions are described in detail as follows: (1) A new electronic bill service structure is designed based on the cloud-fog hybrid in 5G network. (2) A multifactor user identity authentication scheme is proposed based on biometrics, passwords, public and private keys, and one-time passwords. (3) By adopting the proxy signature mechanism, the computational overhead of our scheme is lower than that of the similar schemes. (4) The proposed scheme can realize the privacy protection of user biometrics, passwords, public and private keys, and one-time passwords. (5) The electronic bill business server can deal with TOKEN in batch processing. (6) The BAN logic and Scyther tool have been employed to analyze and verify the security of our scheme.The chapters of this article consist as follows: we investigate the related work in Section2. The system model and secure goal of our scheme are presented in Section 3. Section 4 offers the process of our scheme. The security and performance analysis is given in Sections 5 and 6, respectively. Finally, we summarize the paper in Section 7.


## 2. Related Work

Recently, there has been an increasing number of researches on electronic bill service systems in academia. Still, less studies on the authentication and authority control schemes of electronic bill service systems since the electronic bill service system has the characteristics of multiple servers in parallel, multiple data domains, coexisting with management domains. The electronic bill system is a typical multiserver architecture system. This section gives some related multiserver authentication (MSA) and cloud-fog hybrid architecture protocols proposed by academic researchers.In 2014, by combining the biometrics and elliptic curve cryptosystem (ECC), He et al. [16] gave the first MSA scheme. In the same year, the scheme in [16] indicated that it is vulnerable to some attacks such as simulation attacks by Odelu et al. [17]. The scheme in [17] also presented a new protocol based on biometric, smart cards, and ECC. The schemes in [18, 19] also proposed a new authentication and key agreement (AKA) protocol. Moreover, the scheme in [19] pointed out that the scheme in [18] is vulnerable to smart card theft attacks.In 2015, for the telemedicine environment, Barman et al. [20] successfully solved the multiserver identity authentication problem by proposing a user authentication scheme with low computational overhead. However, this solution incurs several security issues including poor scalability, vulnerability to privilege attacks, and lack of access control. Lin et al. [21] further analyzed the scheme proposed by the scheme in [18] and pointed out that it is prone to server spoofing attacks and cannot protect user anonymity and session keys. Chuang and Chen enhanced the scheme in [18] by proposing a new AKA scheme of multiserver with robust privacy protection.In 2016, Moon et al. [22] proposed a three-factor authentication scheme. In [22], users can sign in to the service at the multiserver scenario by their smart cards, password, and biometrics. This scheme makes up for the problems of the scheme proposed by [23] that cannot resist camouflage attacks and password guessing attacks. However, it has still problems such as lack of forward security and denial of service attacks.In 2017, Irshad et al. [24] analyzed the schemes in [25–27] and pointed out that the abovementioned schemes are easy to incur different forms of attacks. Subsequently, an improved protocol is proposed on the abovementioned work. Reddy et al. [28] also analyzed the scheme in [27] and indicated that the scheme in [27] is vulnerable to multiple attacks.In 2018, aiming at the mobile cloud computing environment, Chatterjee et al. [29] proposed an identity authentication protocol that has a small computational and communication overhead. The registry does not take part in the login, identity verification, and key establishment stages in [29]. However, this solution has the problems that it cannot resist counterfeiting attacks, does not have user untraceability, and cannot guarantee multifactor security.In 2019, Qiao et al. [30] proposed an extended AKA scheme for a multiserver environment with robust anonymity in a telecare medicine information system (TMIS) and improved about 20% efficiency compared with the schemes in [31, 32]. Limbasiya and Sahay [33] studied the remote authentication scheme for multiserver systems and presented a protocol. The scheme in [33] improves efficiency and reduces the communication overhead comparing with the previous solution. Ying and Nayak [4] imported 5G network to the multiserver system and gave a lightweight protocol using self-certified public key cryptography (SCPKC), the performance analysis shows Ying’s protocol can reduce the communication and computational overhead.From 2020, Wu et al. [3] proposed an enhanced protocol for the 5G multiserver network using only hash functions, and the result of formal security analysis shows [3] can resist various attacks such as privileged insider attacks. Wang and Zhu [5] pointed out that the scheme in [4] is vulnerable to multiple attacks such as identity guessing and password impersonation attacks. Reference [5] also proposed an improved protocol based on SCPKC. For the healthcare system, Limbasiya et al. [34] proposed an AKA scheme. Roy and Bhattacharya [35] designed a lightweight MAKA protocol based on the group key. Shamshad et al. [36] proposed an identity-based authentication protocol for TMIS based on physically unclonable function (PUF).Likewise, there are also some works on the authentication schemes for the cloud-fog hybrid architecture.In fog-cloud based vehicular ad hoc networks scenes, Yang et al. [37] proposed a certificateless aggregate signcryption scheme (CASS) that realized the privacy protection of sender. Based on the proposed CASS, Yang et al. designed a new privacy-preserving aggregation authentication scheme (PPAAS). This scheme effectively reduces the bandwidth overhead by allowing the vehicle to preload the public keys of all RSUs on the driving route, and the RSUs aggregate the received ciphertext. However, it incurs a lot of computational cost due to the use of the bilinear map, which is not suitable for vehicles with limited computing resources. In TMIS scenes, Liu et al. [15] constructed a novel privacy-preserving mutual authentication (NPMA) scheme based on certificateless cryptography and shared secrets. This scheme can provide double anonyms for patients and edge-severs to protect the privacy during the authentication and trace malicious patients or edge-severs.In fog-cloud based Internet of Things (IoT) scenes, Ali and Sridevi [38] proposed an attributes-based authentication mechanism for IoT devices. This scheme assumes that the fog broker is a high-performance central fog node responsible for the key and credential generation (KCG). Also, the IoT device is defined as an object with seven attributes. The KCG can use unique identifiers and features such as user names and passwords to generate the device’s credentials. However, there is no attribute update process in the scheme in [38]. Additionally, the secret is shared by the KGC to the IoT device and the specific fog server using the public key, while it is guaranteed that only the particular fog server can authenticate this device. However, it is not resistant to insider attacks. Loffi et al. [39] designed a mutual authentication protocol with a tolerance time rate ttr to defend man-in-the-middle attacks and imitation attacks in the IoT. In this scheme, both the two parties maintain a total time counter ctt and use the sum of the processing time tpA, network delay trB, and ttr to infer whether the currently received datagram has been attacked, that is, if ctt≤tpA+trB+trr holds, it means that the message is less likely to be tampered or intercepted. Otherwise, the receiver believes that the message may be tampered with or intercepted. However, there are the following problems in the scheme in [39]. On the one hand, for different devices, the server needs to save different ttr, which is lack of dynamic update process of ttr. On the other hand, the process of getting ttr is not friendly to energy-constrained IoT devices.Based on the analysis in the abovementioned work, there are few existing authentication models and security solutions for electronic bill service. Therefore, it is key point to provide secure and robust authentication for an electronic bill architecture.


## 3. System Model and Goal

### 3.1. System Model

As shown in Figure1, the electronic bill security authentication and authority control system mainly includes the following four parts: users, electronic bill service device Device, electronic bill authentication server Service, and electronic bill business server Server. In our scheme, we suppose the electronic bill authentication server and electronic bill business server are located in the cloud, the electronic bill service device is situated in the fog, and user can access electronic bill service through the 5G network.(i)
Electronic Bill Authentication Server: It is a cloud server and is mainly responsible for authenticating the user. If the authentication is successful, it issues an authentication token to the user. If the authentication fails, the corresponding prompt information are directly returned to the user. The electronic bill authentication service, as the original signer, can issue his signature right to the electronic bill service device. The electronic bill authentication service also has the function of a key distribution center.(ii)
Electronic Bill Business Server: It is a cloud server and is a provider of electronic bill services. After completing user authentication, the user can send a query with a TOKEN to the electronic bill business server. The electronic bill business server can verify the TOKEN. It is the verifier and can effectively distinguish between the original and proxy signatures.(iii)
Electronic Bill Service Device: It is a fog server and is mainly responsible for authenticating the users who bind with it. It is a subsystem of the electronic bill authentication service and can legally generate the proxy signature of the electronic bill authentication service.(iv)
User: The user is the issuer and receiver who use the electronic bill service. Before using the electronic bill service, the user must download an electronic bill client. Each legal user has a unique legal user ID and a matching public and private key pair.Before users try to access theServer, they must sign in and get the TOKEN from the Device bound to them as shown in Figure 2. Subsequently, the user sends the access request with the TOKEN to Server, specifically including the following two steps. (1) The user needs to choose a Device from the Service and then assist the Device to complete the service registration and device binding phase. (2) When the user accesses the Server, he needs to provide the Device with multifactor information required for authentication: biometrics, a time-based one-time password (TOTP) code, password, and authentication information combined with the user’s private key. The Device calculates and compares the authentication information provided by the user with the corresponding authority value, then signs the TOKEN by proxy signature and issues the TOKEN to the user. The user initiates a data access request with a TOKEN. The Server verifies the token in the data access request and completes the user’s request.Figure 2
Authentication and authentication access process.


### 3.2. Protocol Architecture

The proposed scheme includes 11 polynomial time algorithms shown as follows.(1)
System Initialization Phase: By specifying two prime numbers,p and q, Service generates its IDM, a key pair xM,yM, where xM is the private key of the Service, and yM is the public key. The Service also generates required general parameters, which all parties use to the agreement, and IDM and yM are included in these public parameters.(2)
User Registration: The userA registers with the service M through a secure channel.(3)
Service Registration and Binding Phase: The user first chooses a device, like the “nearest” fog server as the targetDeviceD. The user provides authentication information to the DeviceD and completes the service registration and the binding of the user and the device D. If this stage is successful, the user can initiate an authentication request to the DeviceD instead of requesting Service.(4)
Proxy Signature Key Agreement Phase: TheDeviceD applies to the Service for proxy signature authority. The Service responds to the DeviceD in a polynomial time and signs its proxy signature warrant. Finally, the DeviceD generates a legal secret key pair xp,yp where xp is the D’s proxy signature private key and yp is the proxy signature public key.(5)
User Authentication and Proxy Signature Generation Phase: After theDeviceD completes the previous two stages, it can obtain the authentication vector of the user bound to it and the proxy signature authority. In this stage, DeviceD can use the above information to complete the user’s authentication and issue the TOKEN.(6)
Proxy Signature Verification and Authentication Phase: After the user is authenticated, he or she can access theService. The Service verifies the TOKEN carried in the user request and determines user permissions. If all the abovementioned criteria pass, the user can access the Service. Otherwise, the Service rejects the user’s request.(7)
Proxy Signature Batch Verification Phase: TheServer often handles massive user requests. In the 5G cloud-fog hybrid environment, the Server can perform batch verification to deal with massive user requests received at the same time. If the batch verification fails, the Server can use the binary search to find the wrong signature.(8)
Binding Release Phase: The user can unbind with theDeviceD bound to it for personal reasons. In the binding release phase, the user only needs to interact with the DeviceD and does not interact with the Service, reducing the communication overhead.(9)
Proxy Signer Privacy Revocation Phase: When aServer finds that the proxy signer hD is abnormal when verifying the TOKEN, it can obtain the real ID of the proxy signer hD from the ServiceM.(10)
Proxy Signature Authority Revocation Phase: Under normal circumstances, after the time limit described in themw of the DeviceD expires, the proxy signature authority of DeviceD is automatically revoked. For DeviceD that abuses its power, the ServiceM maintains a proxy signature revocation list. The proxy signature revocation list holds part of the device information, the timestamp T when the device was added to the list, and the urgency level G of the revocation event. For different urgency levels G, we give different handling methods. At the same time, to reduce system overhead, the data put into the proxy signature revocation list is automatically removed by the system when the corresponding proxy warrant expires, thereby avoiding unlimited expansion of the list.(11)
User Multifactor Update Phase: In our scheme, the user can update the authentication factor. The user needs to input the original and updated authentication factors simultaneously to update the user authentication information on theDeviceD and the ServiceM.In addition, what needs to be explained is that the user assists theDevice to complete the service registration and binding phase. The Service safely delivers the user’s multifactor authentication information to the Device and generates a service authentication code. The Device automatically completes the agreement of the proxy signature right and the proxy signature key of the Service.The user needs to perform authentication and authorization before attempting to access other services of the electronic bill service. After the user initiates an authentication request to theDevice, the Device completes user authentication according to the multifactor authentication information input by the user. It then issues a TOKEN with a proxy signature. After adding the TOKEN to the data request, the user can access other services of the electronic bill service. After the Server receives the TOKEN, it can perform signature verification or batch verification. Suppose the Server discovers that a proxy signer has committed multiple violations. The Server can ask the Service to revoke the privacy of the proxy signer. If the circumstances are severe, the Service can revoke the proxy signature authority of the corresponding proxy signer in advance. When the Device is no longer needed, the user can unbind with the Device. The user can update the multiple factors required for authentication.The timestamps involved in this scheme are all UNIX timestamps. The protocol continues if the received timestamp is less than 5s earlier than the current timestamp. Otherwise, the protocol terminates.


### 3.3. Secure Goal

A secure protocol must satisfy the following goals.(i)
Mutual Authentication: Participants of the authentication protocol can authenticate other participants to ensure that the protocol participants are honest and credible.(ii)
Data Confidentiality and Integrity: Unauthorized entities cannot crack the message, and once the message is tampered, deleted, or replaced, it can be noticed by the recipient.(iii)
Resist Several Types of Attacks: The protocol must be resistant to some attacks such as reply attacks, mobile device loss attack, offline password guessing attack, privileged insider attack, and so on.Furthermore, a proxy-signed scheme must meet the following security goals defined in [40–43].(i)
Proxy Privacy: No one can judge who signs the proxy signature from only the proxy signature.(ii)
Strong Unforgeability: A legal proxy signature can only be generated by a legal proxy signer.(iii)
Proxy signer’s deviation: The proxy signer can only create a proxy signature, not an original signature [44].(iv)
Verifiability: A valid proxy signature can pass the verification equation.(v)
Strong identifiability: Proxy signatures and general signatures can be distinguished easily.(vi)
Strong Recognizability: Any verifier can distinguish who signs the proxy signature by a legal proxy signer.(vii)
Strong Non-repudiation: Once a legal proxy signature is generated, the proxy signer denies that its signature is prohibited.(viii)
Anti-abuse: Proxy signers can only exercise their powers within the scope specified by the proxy signature warrants and cannot use them beyond their authority.


### 3.4. Preliminary

Discrete Logarithm Problem. Denote its group operation by multiplication for any finite cyclic groupG, and its generator is g. Let a be an element of G, and it is not easy to solve an x that satisfies x=logga.(1)
The Computational Diffie–Hellman Problem (CDH): Given the finite cyclic groupG, the generator g of G, it is challenging to find guv∈G when gu∈G and gv∈G are known.(2)
The Decisional Diffie–Hellman Problem (DDH): Given the finite cyclic groupG, the generator g of G, it is not easy to judge whether gw=guv holds when gu∈G and gv∈G are known.Fuzzy extractors have the ability of feature extraction and secret recovery of biological features with specific probability distribution characteristics, such as fingerprints. As defined in [45], a quintuple of ℳ,m,ℓ,t,ε can represent a fuzzy extractor where ℳ represents a set. Fuzzy extractors include a pair of procedures (generate (GEN) and reproduce (REP)).(1)
GEN:ℳ⟶R0,1ℓ×0,1∗,.(1)GENb=B,C.For any low-entropy stringb, the process GEN output is a pair of strings B,C. B is called a characteristic string, and C is an auxiliary string.(2)
REP:ℳ×0,1∗⟶D0,1ℓ(2)REPb′,C=Bifdisb,b′≤t.For eachb,b′∈ℳ, if B,C are generated by GENb and disb,b′≤t, the fuzzy extractor can recover the characteristic string B through the process REPb′,C. The function disb,b′ is similar to the function that calculates the Hamming distance, and its output represents a measure of the difference between two variables.


## 3.1. System Model

As shown in Figure1, the electronic bill security authentication and authority control system mainly includes the following four parts: users, electronic bill service device Device, electronic bill authentication server Service, and electronic bill business server Server. In our scheme, we suppose the electronic bill authentication server and electronic bill business server are located in the cloud, the electronic bill service device is situated in the fog, and user can access electronic bill service through the 5G network.(i)
Electronic Bill Authentication Server: It is a cloud server and is mainly responsible for authenticating the user. If the authentication is successful, it issues an authentication token to the user. If the authentication fails, the corresponding prompt information are directly returned to the user. The electronic bill authentication service, as the original signer, can issue his signature right to the electronic bill service device. The electronic bill authentication service also has the function of a key distribution center.(ii)
Electronic Bill Business Server: It is a cloud server and is a provider of electronic bill services. After completing user authentication, the user can send a query with a TOKEN to the electronic bill business server. The electronic bill business server can verify the TOKEN. It is the verifier and can effectively distinguish between the original and proxy signatures.(iii)
Electronic Bill Service Device: It is a fog server and is mainly responsible for authenticating the users who bind with it. It is a subsystem of the electronic bill authentication service and can legally generate the proxy signature of the electronic bill authentication service.(iv)
User: The user is the issuer and receiver who use the electronic bill service. Before using the electronic bill service, the user must download an electronic bill client. Each legal user has a unique legal user ID and a matching public and private key pair.Before users try to access theServer, they must sign in and get the TOKEN from the Device bound to them as shown in Figure 2. Subsequently, the user sends the access request with the TOKEN to Server, specifically including the following two steps. (1) The user needs to choose a Device from the Service and then assist the Device to complete the service registration and device binding phase. (2) When the user accesses the Server, he needs to provide the Device with multifactor information required for authentication: biometrics, a time-based one-time password (TOTP) code, password, and authentication information combined with the user’s private key. The Device calculates and compares the authentication information provided by the user with the corresponding authority value, then signs the TOKEN by proxy signature and issues the TOKEN to the user. The user initiates a data access request with a TOKEN. The Server verifies the token in the data access request and completes the user’s request.Figure 2
Authentication and authentication access process.


## 3.2. Protocol Architecture

The proposed scheme includes 11 polynomial time algorithms shown as follows.(1)
System Initialization Phase: By specifying two prime numbers,p and q, Service generates its IDM, a key pair xM,yM, where xM is the private key of the Service, and yM is the public key. The Service also generates required general parameters, which all parties use to the agreement, and IDM and yM are included in these public parameters.(2)
User Registration: The userA registers with the service M through a secure channel.(3)
Service Registration and Binding Phase: The user first chooses a device, like the “nearest” fog server as the targetDeviceD. The user provides authentication information to the DeviceD and completes the service registration and the binding of the user and the device D. If this stage is successful, the user can initiate an authentication request to the DeviceD instead of requesting Service.(4)
Proxy Signature Key Agreement Phase: TheDeviceD applies to the Service for proxy signature authority. The Service responds to the DeviceD in a polynomial time and signs its proxy signature warrant. Finally, the DeviceD generates a legal secret key pair xp,yp where xp is the D’s proxy signature private key and yp is the proxy signature public key.(5)
User Authentication and Proxy Signature Generation Phase: After theDeviceD completes the previous two stages, it can obtain the authentication vector of the user bound to it and the proxy signature authority. In this stage, DeviceD can use the above information to complete the user’s authentication and issue the TOKEN.(6)
Proxy Signature Verification and Authentication Phase: After the user is authenticated, he or she can access theService. The Service verifies the TOKEN carried in the user request and determines user permissions. If all the abovementioned criteria pass, the user can access the Service. Otherwise, the Service rejects the user’s request.(7)
Proxy Signature Batch Verification Phase: TheServer often handles massive user requests. In the 5G cloud-fog hybrid environment, the Server can perform batch verification to deal with massive user requests received at the same time. If the batch verification fails, the Server can use the binary search to find the wrong signature.(8)
Binding Release Phase: The user can unbind with theDeviceD bound to it for personal reasons. In the binding release phase, the user only needs to interact with the DeviceD and does not interact with the Service, reducing the communication overhead.(9)
Proxy Signer Privacy Revocation Phase: When aServer finds that the proxy signer hD is abnormal when verifying the TOKEN, it can obtain the real ID of the proxy signer hD from the ServiceM.(10)
Proxy Signature Authority Revocation Phase: Under normal circumstances, after the time limit described in themw of the DeviceD expires, the proxy signature authority of DeviceD is automatically revoked. For DeviceD that abuses its power, the ServiceM maintains a proxy signature revocation list. The proxy signature revocation list holds part of the device information, the timestamp T when the device was added to the list, and the urgency level G of the revocation event. For different urgency levels G, we give different handling methods. At the same time, to reduce system overhead, the data put into the proxy signature revocation list is automatically removed by the system when the corresponding proxy warrant expires, thereby avoiding unlimited expansion of the list.(11)
User Multifactor Update Phase: In our scheme, the user can update the authentication factor. The user needs to input the original and updated authentication factors simultaneously to update the user authentication information on theDeviceD and the ServiceM.In addition, what needs to be explained is that the user assists theDevice to complete the service registration and binding phase. The Service safely delivers the user’s multifactor authentication information to the Device and generates a service authentication code. The Device automatically completes the agreement of the proxy signature right and the proxy signature key of the Service.The user needs to perform authentication and authorization before attempting to access other services of the electronic bill service. After the user initiates an authentication request to theDevice, the Device completes user authentication according to the multifactor authentication information input by the user. It then issues a TOKEN with a proxy signature. After adding the TOKEN to the data request, the user can access other services of the electronic bill service. After the Server receives the TOKEN, it can perform signature verification or batch verification. Suppose the Server discovers that a proxy signer has committed multiple violations. The Server can ask the Service to revoke the privacy of the proxy signer. If the circumstances are severe, the Service can revoke the proxy signature authority of the corresponding proxy signer in advance. When the Device is no longer needed, the user can unbind with the Device. The user can update the multiple factors required for authentication.The timestamps involved in this scheme are all UNIX timestamps. The protocol continues if the received timestamp is less than 5s earlier than the current timestamp. Otherwise, the protocol terminates.


## 3.3. Secure Goal

A secure protocol must satisfy the following goals.(i)
Mutual Authentication: Participants of the authentication protocol can authenticate other participants to ensure that the protocol participants are honest and credible.(ii)
Data Confidentiality and Integrity: Unauthorized entities cannot crack the message, and once the message is tampered, deleted, or replaced, it can be noticed by the recipient.(iii)
Resist Several Types of Attacks: The protocol must be resistant to some attacks such as reply attacks, mobile device loss attack, offline password guessing attack, privileged insider attack, and so on.Furthermore, a proxy-signed scheme must meet the following security goals defined in [40–43].(i)
Proxy Privacy: No one can judge who signs the proxy signature from only the proxy signature.(ii)
Strong Unforgeability: A legal proxy signature can only be generated by a legal proxy signer.(iii)
Proxy signer’s deviation: The proxy signer can only create a proxy signature, not an original signature [44].(iv)
Verifiability: A valid proxy signature can pass the verification equation.(v)
Strong identifiability: Proxy signatures and general signatures can be distinguished easily.(vi)
Strong Recognizability: Any verifier can distinguish who signs the proxy signature by a legal proxy signer.(vii)
Strong Non-repudiation: Once a legal proxy signature is generated, the proxy signer denies that its signature is prohibited.(viii)
Anti-abuse: Proxy signers can only exercise their powers within the scope specified by the proxy signature warrants and cannot use them beyond their authority.


## 3.4. Preliminary

Discrete Logarithm Problem. Denote its group operation by multiplication for any finite cyclic groupG, and its generator is g. Let a be an element of G, and it is not easy to solve an x that satisfies x=logga.(1)
The Computational Diffie–Hellman Problem (CDH): Given the finite cyclic groupG, the generator g of G, it is challenging to find guv∈G when gu∈G and gv∈G are known.(2)
The Decisional Diffie–Hellman Problem (DDH): Given the finite cyclic groupG, the generator g of G, it is not easy to judge whether gw=guv holds when gu∈G and gv∈G are known.Fuzzy extractors have the ability of feature extraction and secret recovery of biological features with specific probability distribution characteristics, such as fingerprints. As defined in [45], a quintuple of ℳ,m,ℓ,t,ε can represent a fuzzy extractor where ℳ represents a set. Fuzzy extractors include a pair of procedures (generate (GEN) and reproduce (REP)).(1)
GEN:ℳ⟶R0,1ℓ×0,1∗,.(1)GENb=B,C.For any low-entropy stringb, the process GEN output is a pair of strings B,C. B is called a characteristic string, and C is an auxiliary string.(2)
REP:ℳ×0,1∗⟶D0,1ℓ(2)REPb′,C=Bifdisb,b′≤t.For eachb,b′∈ℳ, if B,C are generated by GENb and disb,b′≤t, the fuzzy extractor can recover the characteristic string B through the process REPb′,C. The function disb,b′ is similar to the function that calculates the Hamming distance, and its output represents a measure of the difference between two variables.


## 4. Proposed Scheme

In this section, we introduce the proposed scheme in detail.


### 4.1. System Initialization Phase

Given large prime numberp, choose a prime number q which satisfies q|p−1. Choose a generator g with order q on Zp∗. The ServiceM selects a key pair xM,yM, a random number γ, where xM is M’s private key, yM is M’s public key satisfying yM=gxMmodp. γ is a secret value used for M to calculate the authentication vector of the member. M publishes IDM,p,q,g,yM and saves γ securely.For each deviceD in this system, the ServiceM distributes IDD and RD, and device D will use the public parameters to generate a key pair xD,yD. D publishes IDD,yD and saves RD securely.For each userA, the ServiceM distributes IDA, a security device with a public and private key pair xA,yA and a shared secret RA. A publishes IDA,yA and saves RA securely. The notations used in our proposed scheme are shown in Table 1.Table 1
Notations.
NotationDescriptionp,qLarge prime andq|p−1gGenerator of orderq on Zp∗mwProxy signature warrantσDigital signaturexM,yMEntityM’s public and private key pair and satisfy yM=gxMmodphHash functionγA secret value used forM to calculate the authentication vector of the memberIDMEntityM’s IDBIOUser’s biometric informationRDA secret key shared betweenM and DkA random number,k∈RZp∗TA timestampAVxyAn authentication vector sent by entity X to entity YpwUser’s passwordoptTOTP code,opt=TOTPRX,TAMMAMessage authentication code between entityM and ASMDSecret shared between entitiesM and DGENBIOA process on the fuzzy extractor that can generate characteristic stringB and auxiliary string CREPBIO′,CA process on the fuzzy extractor that can restore the characteristic stringBTOTPR,TReturn a time-based one-time passwordENC/DESSymmetric encryption and decryption function


### 4.2. User Registration

The userA needs to apply his key device to the system first, which should be performed offline, so we do not discuss it here. User A requires to provide identity IDA and authentication factors such as password pw to send to the service during the signup process. Once the service M receives user information, it checks whether the identity IDA exists. If it exists, the registrant needs to be warned. Otherwise, the service M will complete the user registration process after verifying the received message. The specific steps are shown in Figure 3.Figure 3
User registration phase.


### 4.3. Service Registration and Binding Phase

At the current phase, the userA needs to complete the binding with the device. The device D requires to assist the user A in completing this process to obtain key information RA,CMA,SCRM for user authentication. The user A first needs to provide his identity IDA and authentication factors such as password and send the calculated value to the device. The device D then needs to use its own private key xD and shared secret RD with the service to safely assist the user in this process. The specific steps are shown in Algorithm 1. Method freshRandomNumber() returns a random number and Method checkTimestamps (T) judges whether the input timestamp T is within the validity period, if so, it returns true; otherwise, it returns false.Algorithm 1: Service registration and binding phase.
Step 1: UserA⟶Device DInput: UserA enters IDA, pw, BIO, opt(1)
kl⟵freshRandomNumber(2)
rl⟵gklmodp(3)
BA,CA⟵GENBIO(4)
HPW⟵hhpw∥hBA(5)
AVAM⟵xA⋅HPW+kl⋅hTl∥hoptmodqOutput: SendIDA,rl,Tl,AVAM to device DStep 2: DeviceD⟶ Service MInput: DeviceD’s private key xD and message from user A(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
AVDM⟵xD⋅hAVAM+ka⋅TamodqOutput: SendIDD,IDA,AVDM,AVAM,rl,ra,Tl,Ta to service MStep 3: ServiceM⟶ Device DInput: ServiceM’s private key xM, shared informations RA,RD, user information hpw and the message from device D(1)
if checkTime stampsTl and checkTimestamps Ta then(2)
HPW′⟵hhpw′∥hBA′(3)
HOPT′⟵hTOTPRA,Tl(4)
ifgAVAM==yAHPW′⋅rlhTl∥HOPT′modp&&gAVDM==yDhAVAM′⋅raTamodp then(5)
kc⟵freshRandomNumber(6)
kd⟵freshRandomNumber(7)
ke⟵freshRandomNumber(8)
MA⟵hIDAIDDIDM∥σ(9)
CRA⟵ENCRD,RA(10)
CHMA⟵ENCHPW′,MA(11)
rc⟵gkcmodp(12)
re⟵gkemodp(13)
CMA⟵xM⋅RD+kc⋅hHPW′∥MAmodq(14)
for ServerS in System do(15)
AMXA⟵xM⋅hIDARXhIDXmodq(16)
ALA⟵hIDM,AMMA,hIDD,AMDA(17)
end for(18)
hD⟵xM⋅hIDD∥IDA⋅kdmodq(19)
ta⟵ALA,IDAandCHMA(20)
AVMA⟵xM⋅hta+ke⋅Tbmodq(21)
tb⟵AVMA,CMA,CRA,rc,hD(22)
AVMD⟵xM⋅htb+ke⋅Tbmodq(23)
SaveIDD,IDA,hD,kd,ALAOutput: SendTb,rc,re,CHMA,CMA,ALA,CRAAVMD,AVMA,hD, to device D(24)
end if(25)
end ifOutput: Send an error message to deviceDStep 4: DeviceD⟶ User AInput: DeviceD’s private key xD, shared information RD and message from service M(1)
if this message is not an error message, then(2)
if checkTimestampsTb then(3)
ifgAVMD==yMhAVMACMACRArchD⋅reTbmodp&&gAVMA==yMhALAIDACHMA⋅reTbmodp then(4)
SaveCMA,hD,rc,IDA,CRA,SCRM=yMRD,DM⟵yA⋅yMIDARDhIDDOutput: SendALA,CHMA,re,Tb,AVMA to user A(5)
end if(6)
end if(7)
end ifOutput: Send an error message to userAStep 5: UserAInput: UserA’s private key xA, shared information RA and message from Device D(1)
if this message is not an error message, then(2)
ifgAVMA==yMhALA∥IDA∥CHMAA⋅reTbmodp then(3)
KeepCHMA,ALA,CA securelyOutput: Success(4)
end if(5)
end ifOutput: Failure


### 4.4. Proxy Signature Key Agreement Phase

After the deviceD completes the binding with the user A, it needs to apply for the proxy signature authority of the service M, so as to have the ability to generate a legal TOKEN for the user instead of the service M. During this process, the device D will generate a proxy signature warrant mw, and the service M will check whether mw is compliant. If the mw is compliant, the service M will compute a signature σ for it. Finally, the proxy signing key pair for device D is xp,yp. The detailed steps of this stage are shown in Algorithm 2.Algorithm 2: Proxy signature key agreement phase.
Step 1: DeviceD⟶Service MInput: DeviceD’s private key xD and shared information RD(1)
kf⟵freshRandomNumber(2)
kh⟵freshRandomNumber(3)
rf⟵gkfmodp(4)
rh⟵gkhmodp(5)
mw⟵IDM,hD,ΔT,yN(6)
AVDM⟵xD⋅hmw∥RD+kf⋅TdmodqOutput: SendTd,rf,mw,IDD,hD,AVDM to service MStep 2: ServiceM⟶Device DInput: ServiceM’s private key xM, shared information RD and the message from device D(1)
hD,RD← Select form its database by IDD(2)
ifgAVDM==yDhmw∥RD⋅rfTdmodp then(3)
kg⟵freshRandomNumber(4)
rg⟵gkgmodp.(5)
σ⟵xM+kg⋅hmwrghD∥Temodq(6)
AVMD⟵xM⋅hRD∥σ+kg⋅hTe∥rgOutput: SendTe,rg,σ,AVMD to device D(7)
end ifOutput: Send an error message to deviceDStep 3: DeviceDInput: DeviceD’s private key xD, shared information RD and the message from service M(1)
if this message is not an error message, then(2)
ifgAVMD==yMhRD∥σ⋅rghTe∥rgmodp&&gσ==yM⋅rghmwrghD∥Tgmodp then(3)
xp⟵xD⋅yD+1+σ+kh⋅rhmodp(4)
yp⟵gxpmodp=yDyD⋅gσ⋅yNmodpOutput: Success(5)
end if(6)
end ifOutput: Failure


### 4.5. User Authentication and Proxy Signature Generation Phase

To complete user authentication, the user needs to enterIDA and a series of authentication factors such as password pw, private key xA. The user equipment calculates the above factors and delivers it to the device D, and the device D uses its stored authentication information RA,CMA,SCRM to authenticate the user by gCMA+OPT=SCRM⋅rcHM⋅yAhTOTPRA,Tamodp . If the authentication is successful, a TOKEN signed by the proxy signature private key xp will be issued, and the device D and the user A will successfully negotiate a session key KS. Otherwise, the device D will prompt the user authentication failure. The detailed steps are shown in Algorithm 3.Algorithm 3: User authentication and proxy signature generation phase.
Step 1: UserA⟶ Device DInput: UserA‘s AIDA,ALA,pw,BIO(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
OPT⟵xA⋅hoptmodq(4)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(5)
AALA⟵hIDX,AAMXA(6)
BA,CA⟵GENBIO(7)
MA⟵DESHPW,CHMA(8)
HM⟵hHPW∥MAOutput: SendIDA,HM,OPT,AALA,ra,Ta. To device DStep 2: DeviceD⟶User AInput: authentication informationRA,CMA,SCRM and the message from userA(1)
ifgAAMDA==raTa⋅DMmodp then(2)
RA⟵DESRD,CRA(3)
ifgCMA+OPT==SCRM⋅rcHM⋅yAhTOTPRA,Tamodp then(4)
ku⟵freshRandomNumber(5)
ru⟵gkumodp(6)
KS⟵raku(7)
msg⟵ (IDA, hAALA, Ta, ra, ru, Tg)(8)
σm⟵xp+ku⋅hmsgmodp(9)
TOKEN⟵mw, σ, rg, Te, ru, Tg, yp, IDA, AALA, Ta, ra, σmOutput: SendTOKEN to The user A(10)
end if(11)
end ifOutput: Send an error message to userAStep 3: UserA⟶Device DInput: The message from deviceD(1)
if this message is not an error message, then(2)
kc⟵freshRandomNumber(3)
KS⟵ru=gka⋅ku(4)
msg⟵hKSTcTOTPRA,TcOutput: Sendmsg,IDA,Tc to device D(5)
end ifOutput: FailureStep 4: DeviceDInput: The message from userA(1)
ifmsg′==hKSTcTOTPRA,Tc then Output: Success(2)
end ifOutput: Failure


### 4.6. Proxy Signature Verification and Authentication Phase

Once the userA receives the token, the user sends a query to server S with a TOKEN. The server S should use the following steps to perform the authentication and token verification on user’s requests.(1)
Check the validity ofmw: Server S checks the validity of mw by the following steps.(a)
Check the validity ofmw by gσ=yM⋅rghmwrghD∥Temodp(b)
If passed, serverS checks the validity of the rg by the following query.(i)
Is therg in the revocation list?(ii)
If therg is in the revocation list, is the Tg earlier than the ΔT?(iii)
If therg is in the revocation list, is the urgency of revocation “Serious”?The validrg must meet the condition “do not exist in the revocation list or (the Tg is earlier than ΔTand the urgency of revocation is not “Serious”)”.(2)
Check the validity of theσm: Server S checks the validity of σm by the following steps.(a)
CombineIDA, hAALA, Ta, ra, ru, and Tg into msg.(b)
Verify theσm by gσm=yp⋅ruhmsg.If passed, serverS checks user A’s access right.(3)
Check userA’s access right: The server S performs the following steps to check user A’s access right.(a)
Check the existence of its ownAAMXA in AALA.(b)
IfAAMXA exists, verify the AAMXA by gAAMXA=yA⋅raTa⋅yMhIDARXhIDXmodp.If all of the above criteria passed, serverS responds to the user A. Otherwise, server S terminates this session.


### 4.7. Proxy Signature Batch Verification Phase

If serverS receives a large number of tokens generated by the same device D simultaneously, server S can use the following steps to perform batch verification.(1)
ServerS uses the Step 1 and Step 3 defined in the Proxy Signature Verification and Authentication Phase to check the validity of mw and user A’s access right.(2)
If Step 1 and Step 3 pass, ServerS performs the following steps.(a)
CombineIDA, hAALAi, Tai, rai, rui, and Tgi into msgi.(b)
Verifyσmi by ∑i=1ngσmi=yp⋅∑i=1nruihmsgimodp.


### 4.8. Binding Release Phase

UserA can release their binding device D in this phase as shown in Algorithm 4. The authentication information, including (pw, BIO, opt), are needed to ensure that only the user can release their own devices.Algorithm 4: Binding release phase.
Step 1: UserA⟶Device DInput: UserA inputs pw, BIO, opt(1)
ka⟵freshRandomNumber(2)
OPT⟵xA⋅hoptmodq(3)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(4)
AALA⟵hIDX,AAMXA(5)
BA,CA⟵GENBIO(6)
MA⟵DESHPW,CHMA(7)
HM⟵hHPW∥MAOutput: Send <ID〉IDA,HM,OPT,AALA,ra,Ta〉 to device DStep 2: DeviceDInput: The message from userA(1)
RA⟵DESRD,CRA(2)
ifgCMA+OPT==SCRM⋅rcHM⋅yAhTOTPRA,Tamodp then(3)
delete all information aboutIDAOutput: Success(4)
end ifOutput: Failure


### 4.9. Proxy Signer Privacy Revocation Phase

The serverS can send the alias hD to the service M to obtain the real identity. The service M can use the public key ys of the server S and the shared information RS to ensure that only the server S can obtain the real identity, and no attacker can get it from the intercepted message. A detailed description of the steps can be found in Algorithm 5.Algorithm 5: Proxy signer privacy revocation phase.
Step 1: ServerS⟶Service MInput: ServerS’s private keyxs(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
AVSM⟵xs⋅hIDS∥hD+ka⋅hTa∥ramodqOutput: Send <ID〉IDS,hD,ra,Ta,AVSM〉 to service MStep 2: ServiceM⟶Server SInput: The message from serverS and the shared information RS(1)
ifgAVSM==yshIDS∥hD⋅rahTa∥ramodp then(2)
selectIDD,kd from its database by hD(3)
kc⟵freshRandomNumber(4)
rc=gkcmodp(5)
CMS=ENCRS,IDDIDAyMkd(6)
AVMS=xM⋅hTb∥CMS+kc⋅TbmodqOutput: Send<〈Tb,rc,AVMS,CMS〉 to server S(7)
end ifOutput: Send an error message to serverSStep 3: ServerSInput: The message from serviceM and the shared information RS(1)
if this message is not an error message, then(2)
ifgAVMS==yMhTb∥CMS⋅rcTbmodp then(3)
IDDIDAyMkd⟵DESRS,CMS(4)
ifghD==yMkd⋅hIDD∥IDAmodp thenOutput:IDD(5)
end if(6)
end if(7)
end ifOutput: Failure


### 4.10. Proxy Signature Authority Revocation Phase

Under normal circumstances, after the time limit described in deviceD’s proxy ticket expires, device D’s proxy authority will be automatically revoked. However, there will still be a problem that device D abuses its proxy signature authority. Service M should establish a public signature revocation list to solve the abovementioned issues. The general signature revocation list RL records the rg of the revoked device D, the timestamp T when the device was added to the list, and the degree of urgency G of the revocation.Any verifier should check whether therg is on the public signature revocation list when performing proxy signature verification. If rg is on the public revocation list, it means that service M has discovered the proxy signer for abuse of rights. At this time, it is necessary to consider the operations that need to be performed in conjunction with the timestamp ΔT and the urgency G. Table 2 shows the cancellation urgency and corresponding disposal methods.Table 2
Cancellation urgency and corresponding disposal method table.
LevelApproachAttentionThe serviceM will retain all proxy signatures generated by rg.WarningAfterrg is added to the list, all proxy signatures generated by rg are invalid.SeriousAll proxy signatures generated byrg are invalid.At the same time, in order to reduce system overhead, when theΔT of the revoked mw expires, the rg of the mw will be automatically deleted from the list by the system to prevent unlimited expansion.


### 4.11. User Multifactor Update Phase

For the key pairxA,yA, user A should apply to the service M for an update in a secure channel. Then, the service M generates a new key pair xA′,yA′ and reissues it to user A in a secure way, then the service M publishes the new IDA,yA′. User A also will update the other factors during these phases. This phase is detailed in Algorithm 6.Algorithm 6: User multi-factor update phase.
Step 1: UserA⟶Device DInput: UserA inputs pw,BIO,pwn,BIOn(1)
ka⟵freshRandomNumber(2)
kl⟵freshRandomNumber(3)
ra⟵gkamodp(4)
OPT⟵xA⋅hTOTPRA,Tamodp(5)
rl⟵gklmodp(6)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(7)
AALA⟵hIDX,AAMXA(8)
BA,CA⟵GENBIO(9)
MA⟵DESHPW,CHMA(10)
HM⟵hHPW∥MA(11)
BAn,CAn⟵GENBIOn(12)
M1⟵ENCRA,hpwn∥hBAn(13)
BAn,CAn⟵GENBIOn(14)
HPWn⟵hhpwn∥hBAn(15)
AVAM⟵xAn⋅HPWn+kl⋅hTahTOTPRA,TaM1modqOutput: SendIDA,HM,OPT,AALA,ra,Tarl,AVAM,M1, to device DStep 2: DeviceD⟶ Service MInput: The message from userA(1)
kd⟵freshRandomNumber(2)
rd⟵gkdmodp(3)
AVDM⟵xD⋅hAVAM+kd⋅TbmodpOutput: SendIDD,IDA,AVDM,AVAM,rl,rdTb,Ta,M1, Tb,Ta,M1> to server MStep 3: ServiceM⟶ Device DInput: The message from deviceD(1)
selectshpw,hBA,RA from its database by IDA(2)
HOPT⟵hTOTPRA,Ta(3)
hpwn∥hBAn⟵DESRA,M1(4)
HPWn′⟵hhpwn∥hBAn(5)
ifgAVAM==yAHPWn′⋅rlhTa∥hTOTPRA,Ta∥M1modp&&gAVAM==yAHPWn′⋅rlhTa∥hTOTPRA,Ta∥M1modp then(6)
k⟵⟵freshRandomNumber(7)
ke⟵freshRandomNumber(8)
r⟵⟵gk⟵modp(9)
re⟵gkemodp(10)
CRAnD⟵ENCRD,RAn(11)
CRAnA⟵ENCRA,RAn(12)
CMAn⟵xM+k⟵⋅hHPWn′∥MA⋅RDmodq(13)
AVMA⟵xM⋅hCRAnA+ke⋅Tcmodq.(14)
AVMD⟵ke⋅Tc+xM⋅hCMAnCRAnACRAnD∥r⟵modq.Output: SendTc,r⟵,re,CMA,CRAnD,CRAnA,AVMDAVMA, to device D.(15)
end ifOutput: Send an error message to deviceDStep 4: DeviceD⟶ User AInput: The message from serviceM(1)
if this message is not an error message, then(2)
ifgAVMD==yMhCMAnCRAnACRAnD∥r⟵⋅reTcmodp then(3)
RAn⟵DESRD,CRAnD(4)
Update its databaseCMAn,r⟵,RAn by IDAOutput: SendTc,re,CRAnA,AVMA to user A(5)
end if(6)
end ifOutput: Send an error message to userAStep 5: UserAInput: The message from deviceD(1)
if this message is not an error message, then(2)
ifgAVMA==yMhCRAnA⋅reTcmodp then(3)
RAn⟵DESRA,CRAnAOutput: Success(4)
end if(5)
end ifOutput: Failure


## 4.1. System Initialization Phase

Given large prime numberp, choose a prime number q which satisfies q|p−1. Choose a generator g with order q on Zp∗. The ServiceM selects a key pair xM,yM, a random number γ, where xM is M’s private key, yM is M’s public key satisfying yM=gxMmodp. γ is a secret value used for M to calculate the authentication vector of the member. M publishes IDM,p,q,g,yM and saves γ securely.For each deviceD in this system, the ServiceM distributes IDD and RD, and device D will use the public parameters to generate a key pair xD,yD. D publishes IDD,yD and saves RD securely.For each userA, the ServiceM distributes IDA, a security device with a public and private key pair xA,yA and a shared secret RA. A publishes IDA,yA and saves RA securely. The notations used in our proposed scheme are shown in Table 1.Table 1
Notations.
NotationDescriptionp,qLarge prime andq|p−1gGenerator of orderq on Zp∗mwProxy signature warrantσDigital signaturexM,yMEntityM’s public and private key pair and satisfy yM=gxMmodphHash functionγA secret value used forM to calculate the authentication vector of the memberIDMEntityM’s IDBIOUser’s biometric informationRDA secret key shared betweenM and DkA random number,k∈RZp∗TA timestampAVxyAn authentication vector sent by entity X to entity YpwUser’s passwordoptTOTP code,opt=TOTPRX,TAMMAMessage authentication code between entityM and ASMDSecret shared between entitiesM and DGENBIOA process on the fuzzy extractor that can generate characteristic stringB and auxiliary string CREPBIO′,CA process on the fuzzy extractor that can restore the characteristic stringBTOTPR,TReturn a time-based one-time passwordENC/DESSymmetric encryption and decryption function


## 4.2. User Registration

The userA needs to apply his key device to the system first, which should be performed offline, so we do not discuss it here. User A requires to provide identity IDA and authentication factors such as password pw to send to the service during the signup process. Once the service M receives user information, it checks whether the identity IDA exists. If it exists, the registrant needs to be warned. Otherwise, the service M will complete the user registration process after verifying the received message. The specific steps are shown in Figure 3.Figure 3
User registration phase.


## 4.3. Service Registration and Binding Phase

At the current phase, the userA needs to complete the binding with the device. The device D requires to assist the user A in completing this process to obtain key information RA,CMA,SCRM for user authentication. The user A first needs to provide his identity IDA and authentication factors such as password and send the calculated value to the device. The device D then needs to use its own private key xD and shared secret RD with the service to safely assist the user in this process. The specific steps are shown in Algorithm 1. Method freshRandomNumber() returns a random number and Method checkTimestamps (T) judges whether the input timestamp T is within the validity period, if so, it returns true; otherwise, it returns false.Algorithm 1: Service registration and binding phase.
Step 1: UserA⟶Device DInput: UserA enters IDA, pw, BIO, opt(1)
kl⟵freshRandomNumber(2)
rl⟵gklmodp(3)
BA,CA⟵GENBIO(4)
HPW⟵hhpw∥hBA(5)
AVAM⟵xA⋅HPW+kl⋅hTl∥hoptmodqOutput: SendIDA,rl,Tl,AVAM to device DStep 2: DeviceD⟶ Service MInput: DeviceD’s private key xD and message from user A(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
AVDM⟵xD⋅hAVAM+ka⋅TamodqOutput: SendIDD,IDA,AVDM,AVAM,rl,ra,Tl,Ta to service MStep 3: ServiceM⟶ Device DInput: ServiceM’s private key xM, shared informations RA,RD, user information hpw and the message from device D(1)
if checkTime stampsTl and checkTimestamps Ta then(2)
HPW′⟵hhpw′∥hBA′(3)
HOPT′⟵hTOTPRA,Tl(4)
ifgAVAM==yAHPW′⋅rlhTl∥HOPT′modp&&gAVDM==yDhAVAM′⋅raTamodp then(5)
kc⟵freshRandomNumber(6)
kd⟵freshRandomNumber(7)
ke⟵freshRandomNumber(8)
MA⟵hIDAIDDIDM∥σ(9)
CRA⟵ENCRD,RA(10)
CHMA⟵ENCHPW′,MA(11)
rc⟵gkcmodp(12)
re⟵gkemodp(13)
CMA⟵xM⋅RD+kc⋅hHPW′∥MAmodq(14)
for ServerS in System do(15)
AMXA⟵xM⋅hIDARXhIDXmodq(16)
ALA⟵hIDM,AMMA,hIDD,AMDA(17)
end for(18)
hD⟵xM⋅hIDD∥IDA⋅kdmodq(19)
ta⟵ALA,IDAandCHMA(20)
AVMA⟵xM⋅hta+ke⋅Tbmodq(21)
tb⟵AVMA,CMA,CRA,rc,hD(22)
AVMD⟵xM⋅htb+ke⋅Tbmodq(23)
SaveIDD,IDA,hD,kd,ALAOutput: SendTb,rc,re,CHMA,CMA,ALA,CRAAVMD,AVMA,hD, to device D(24)
end if(25)
end ifOutput: Send an error message to deviceDStep 4: DeviceD⟶ User AInput: DeviceD’s private key xD, shared information RD and message from service M(1)
if this message is not an error message, then(2)
if checkTimestampsTb then(3)
ifgAVMD==yMhAVMACMACRArchD⋅reTbmodp&&gAVMA==yMhALAIDACHMA⋅reTbmodp then(4)
SaveCMA,hD,rc,IDA,CRA,SCRM=yMRD,DM⟵yA⋅yMIDARDhIDDOutput: SendALA,CHMA,re,Tb,AVMA to user A(5)
end if(6)
end if(7)
end ifOutput: Send an error message to userAStep 5: UserAInput: UserA’s private key xA, shared information RA and message from Device D(1)
if this message is not an error message, then(2)
ifgAVMA==yMhALA∥IDA∥CHMAA⋅reTbmodp then(3)
KeepCHMA,ALA,CA securelyOutput: Success(4)
end if(5)
end ifOutput: Failure


## 4.4. Proxy Signature Key Agreement Phase

After the deviceD completes the binding with the user A, it needs to apply for the proxy signature authority of the service M, so as to have the ability to generate a legal TOKEN for the user instead of the service M. During this process, the device D will generate a proxy signature warrant mw, and the service M will check whether mw is compliant. If the mw is compliant, the service M will compute a signature σ for it. Finally, the proxy signing key pair for device D is xp,yp. The detailed steps of this stage are shown in Algorithm 2.Algorithm 2: Proxy signature key agreement phase.
Step 1: DeviceD⟶Service MInput: DeviceD’s private key xD and shared information RD(1)
kf⟵freshRandomNumber(2)
kh⟵freshRandomNumber(3)
rf⟵gkfmodp(4)
rh⟵gkhmodp(5)
mw⟵IDM,hD,ΔT,yN(6)
AVDM⟵xD⋅hmw∥RD+kf⋅TdmodqOutput: SendTd,rf,mw,IDD,hD,AVDM to service MStep 2: ServiceM⟶Device DInput: ServiceM’s private key xM, shared information RD and the message from device D(1)
hD,RD← Select form its database by IDD(2)
ifgAVDM==yDhmw∥RD⋅rfTdmodp then(3)
kg⟵freshRandomNumber(4)
rg⟵gkgmodp.(5)
σ⟵xM+kg⋅hmwrghD∥Temodq(6)
AVMD⟵xM⋅hRD∥σ+kg⋅hTe∥rgOutput: SendTe,rg,σ,AVMD to device D(7)
end ifOutput: Send an error message to deviceDStep 3: DeviceDInput: DeviceD’s private key xD, shared information RD and the message from service M(1)
if this message is not an error message, then(2)
ifgAVMD==yMhRD∥σ⋅rghTe∥rgmodp&&gσ==yM⋅rghmwrghD∥Tgmodp then(3)
xp⟵xD⋅yD+1+σ+kh⋅rhmodp(4)
yp⟵gxpmodp=yDyD⋅gσ⋅yNmodpOutput: Success(5)
end if(6)
end ifOutput: Failure


## 4.5. User Authentication and Proxy Signature Generation Phase

To complete user authentication, the user needs to enterIDA and a series of authentication factors such as password pw, private key xA. The user equipment calculates the above factors and delivers it to the device D, and the device D uses its stored authentication information RA,CMA,SCRM to authenticate the user by gCMA+OPT=SCRM⋅rcHM⋅yAhTOTPRA,Tamodp . If the authentication is successful, a TOKEN signed by the proxy signature private key xp will be issued, and the device D and the user A will successfully negotiate a session key KS. Otherwise, the device D will prompt the user authentication failure. The detailed steps are shown in Algorithm 3.Algorithm 3: User authentication and proxy signature generation phase.
Step 1: UserA⟶ Device DInput: UserA‘s AIDA,ALA,pw,BIO(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
OPT⟵xA⋅hoptmodq(4)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(5)
AALA⟵hIDX,AAMXA(6)
BA,CA⟵GENBIO(7)
MA⟵DESHPW,CHMA(8)
HM⟵hHPW∥MAOutput: SendIDA,HM,OPT,AALA,ra,Ta. To device DStep 2: DeviceD⟶User AInput: authentication informationRA,CMA,SCRM and the message from userA(1)
ifgAAMDA==raTa⋅DMmodp then(2)
RA⟵DESRD,CRA(3)
ifgCMA+OPT==SCRM⋅rcHM⋅yAhTOTPRA,Tamodp then(4)
ku⟵freshRandomNumber(5)
ru⟵gkumodp(6)
KS⟵raku(7)
msg⟵ (IDA, hAALA, Ta, ra, ru, Tg)(8)
σm⟵xp+ku⋅hmsgmodp(9)
TOKEN⟵mw, σ, rg, Te, ru, Tg, yp, IDA, AALA, Ta, ra, σmOutput: SendTOKEN to The user A(10)
end if(11)
end ifOutput: Send an error message to userAStep 3: UserA⟶Device DInput: The message from deviceD(1)
if this message is not an error message, then(2)
kc⟵freshRandomNumber(3)
KS⟵ru=gka⋅ku(4)
msg⟵hKSTcTOTPRA,TcOutput: Sendmsg,IDA,Tc to device D(5)
end ifOutput: FailureStep 4: DeviceDInput: The message from userA(1)
ifmsg′==hKSTcTOTPRA,Tc then Output: Success(2)
end ifOutput: Failure


## 4.6. Proxy Signature Verification and Authentication Phase

Once the userA receives the token, the user sends a query to server S with a TOKEN. The server S should use the following steps to perform the authentication and token verification on user’s requests.(1)
Check the validity ofmw: Server S checks the validity of mw by the following steps.(a)
Check the validity ofmw by gσ=yM⋅rghmwrghD∥Temodp(b)
If passed, serverS checks the validity of the rg by the following query.(i)
Is therg in the revocation list?(ii)
If therg is in the revocation list, is the Tg earlier than the ΔT?(iii)
If therg is in the revocation list, is the urgency of revocation “Serious”?The validrg must meet the condition “do not exist in the revocation list or (the Tg is earlier than ΔTand the urgency of revocation is not “Serious”)”.(2)
Check the validity of theσm: Server S checks the validity of σm by the following steps.(a)
CombineIDA, hAALA, Ta, ra, ru, and Tg into msg.(b)
Verify theσm by gσm=yp⋅ruhmsg.If passed, serverS checks user A’s access right.(3)
Check userA’s access right: The server S performs the following steps to check user A’s access right.(a)
Check the existence of its ownAAMXA in AALA.(b)
IfAAMXA exists, verify the AAMXA by gAAMXA=yA⋅raTa⋅yMhIDARXhIDXmodp.If all of the above criteria passed, serverS responds to the user A. Otherwise, server S terminates this session.


## 4.7. Proxy Signature Batch Verification Phase

If serverS receives a large number of tokens generated by the same device D simultaneously, server S can use the following steps to perform batch verification.(1)
ServerS uses the Step 1 and Step 3 defined in the Proxy Signature Verification and Authentication Phase to check the validity of mw and user A’s access right.(2)
If Step 1 and Step 3 pass, ServerS performs the following steps.(a)
CombineIDA, hAALAi, Tai, rai, rui, and Tgi into msgi.(b)
Verifyσmi by ∑i=1ngσmi=yp⋅∑i=1nruihmsgimodp.


## 4.8. Binding Release Phase

UserA can release their binding device D in this phase as shown in Algorithm 4. The authentication information, including (pw, BIO, opt), are needed to ensure that only the user can release their own devices.Algorithm 4: Binding release phase.
Step 1: UserA⟶Device DInput: UserA inputs pw, BIO, opt(1)
ka⟵freshRandomNumber(2)
OPT⟵xA⋅hoptmodq(3)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(4)
AALA⟵hIDX,AAMXA(5)
BA,CA⟵GENBIO(6)
MA⟵DESHPW,CHMA(7)
HM⟵hHPW∥MAOutput: Send <ID〉IDA,HM,OPT,AALA,ra,Ta〉 to device DStep 2: DeviceDInput: The message from userA(1)
RA⟵DESRD,CRA(2)
ifgCMA+OPT==SCRM⋅rcHM⋅yAhTOTPRA,Tamodp then(3)
delete all information aboutIDAOutput: Success(4)
end ifOutput: Failure


## 4.9. Proxy Signer Privacy Revocation Phase

The serverS can send the alias hD to the service M to obtain the real identity. The service M can use the public key ys of the server S and the shared information RS to ensure that only the server S can obtain the real identity, and no attacker can get it from the intercepted message. A detailed description of the steps can be found in Algorithm 5.Algorithm 5: Proxy signer privacy revocation phase.
Step 1: ServerS⟶Service MInput: ServerS’s private keyxs(1)
ka⟵freshRandomNumber(2)
ra⟵gkamodp(3)
AVSM⟵xs⋅hIDS∥hD+ka⋅hTa∥ramodqOutput: Send <ID〉IDS,hD,ra,Ta,AVSM〉 to service MStep 2: ServiceM⟶Server SInput: The message from serverS and the shared information RS(1)
ifgAVSM==yshIDS∥hD⋅rahTa∥ramodp then(2)
selectIDD,kd from its database by hD(3)
kc⟵freshRandomNumber(4)
rc=gkcmodp(5)
CMS=ENCRS,IDDIDAyMkd(6)
AVMS=xM⋅hTb∥CMS+kc⋅TbmodqOutput: Send<〈Tb,rc,AVMS,CMS〉 to server S(7)
end ifOutput: Send an error message to serverSStep 3: ServerSInput: The message from serviceM and the shared information RS(1)
if this message is not an error message, then(2)
ifgAVMS==yMhTb∥CMS⋅rcTbmodp then(3)
IDDIDAyMkd⟵DESRS,CMS(4)
ifghD==yMkd⋅hIDD∥IDAmodp thenOutput:IDD(5)
end if(6)
end if(7)
end ifOutput: Failure


## 4.10. Proxy Signature Authority Revocation Phase

Under normal circumstances, after the time limit described in deviceD’s proxy ticket expires, device D’s proxy authority will be automatically revoked. However, there will still be a problem that device D abuses its proxy signature authority. Service M should establish a public signature revocation list to solve the abovementioned issues. The general signature revocation list RL records the rg of the revoked device D, the timestamp T when the device was added to the list, and the degree of urgency G of the revocation.Any verifier should check whether therg is on the public signature revocation list when performing proxy signature verification. If rg is on the public revocation list, it means that service M has discovered the proxy signer for abuse of rights. At this time, it is necessary to consider the operations that need to be performed in conjunction with the timestamp ΔT and the urgency G. Table 2 shows the cancellation urgency and corresponding disposal methods.Table 2
Cancellation urgency and corresponding disposal method table.
LevelApproachAttentionThe serviceM will retain all proxy signatures generated by rg.WarningAfterrg is added to the list, all proxy signatures generated by rg are invalid.SeriousAll proxy signatures generated byrg are invalid.At the same time, in order to reduce system overhead, when theΔT of the revoked mw expires, the rg of the mw will be automatically deleted from the list by the system to prevent unlimited expansion.


## 4.11. User Multifactor Update Phase

For the key pairxA,yA, user A should apply to the service M for an update in a secure channel. Then, the service M generates a new key pair xA′,yA′ and reissues it to user A in a secure way, then the service M publishes the new IDA,yA′. User A also will update the other factors during these phases. This phase is detailed in Algorithm 6.Algorithm 6: User multi-factor update phase.
Step 1: UserA⟶Device DInput: UserA inputs pw,BIO,pwn,BIOn(1)
ka⟵freshRandomNumber(2)
kl⟵freshRandomNumber(3)
ra⟵gkamodp(4)
OPT⟵xA⋅hTOTPRA,Tamodp(5)
rl⟵gklmodp(6)
AAMXA⟵xA+ka⋅Ta+AMXAmodq(7)
AALA⟵hIDX,AAMXA(8)
BA,CA⟵GENBIO(9)
MA⟵DESHPW,CHMA(10)
HM⟵hHPW∥MA(11)
BAn,CAn⟵GENBIOn(12)
M1⟵ENCRA,hpwn∥hBAn(13)
BAn,CAn⟵GENBIOn(14)
HPWn⟵hhpwn∥hBAn(15)
AVAM⟵xAn⋅HPWn+kl⋅hTahTOTPRA,TaM1modqOutput: SendIDA,HM,OPT,AALA,ra,Tarl,AVAM,M1, to device DStep 2: DeviceD⟶ Service MInput: The message from userA(1)
kd⟵freshRandomNumber(2)
rd⟵gkdmodp(3)
AVDM⟵xD⋅hAVAM+kd⋅TbmodpOutput: SendIDD,IDA,AVDM,AVAM,rl,rdTb,Ta,M1, Tb,Ta,M1> to server MStep 3: ServiceM⟶ Device DInput: The message from deviceD(1)
selectshpw,hBA,RA from its database by IDA(2)
HOPT⟵hTOTPRA,Ta(3)
hpwn∥hBAn⟵DESRA,M1(4)
HPWn′⟵hhpwn∥hBAn(5)
ifgAVAM==yAHPWn′⋅rlhTa∥hTOTPRA,Ta∥M1modp&&gAVAM==yAHPWn′⋅rlhTa∥hTOTPRA,Ta∥M1modp then(6)
k⟵⟵freshRandomNumber(7)
ke⟵freshRandomNumber(8)
r⟵⟵gk⟵modp(9)
re⟵gkemodp(10)
CRAnD⟵ENCRD,RAn(11)
CRAnA⟵ENCRA,RAn(12)
CMAn⟵xM+k⟵⋅hHPWn′∥MA⋅RDmodq(13)
AVMA⟵xM⋅hCRAnA+ke⋅Tcmodq.(14)
AVMD⟵ke⋅Tc+xM⋅hCMAnCRAnACRAnD∥r⟵modq.Output: SendTc,r⟵,re,CMA,CRAnD,CRAnA,AVMDAVMA, to device D.(15)
end ifOutput: Send an error message to deviceDStep 4: DeviceD⟶ User AInput: The message from serviceM(1)
if this message is not an error message, then(2)
ifgAVMD==yMhCMAnCRAnACRAnD∥r⟵⋅reTcmodp then(3)
RAn⟵DESRD,CRAnD(4)
Update its databaseCMAn,r⟵,RAn by IDAOutput: SendTc,re,CRAnA,AVMA to user A(5)
end if(6)
end ifOutput: Send an error message to userAStep 5: UserAInput: The message from deviceD(1)
if this message is not an error message, then(2)
ifgAVMA==yMhCRAnA⋅reTcmodp then(3)
RAn⟵DESRA,CRAnAOutput: Success(4)
end if(5)
end ifOutput: Failure


## 5. Security Analysis

The security goals provided by our scheme are shown as follows.


### 5.1. Informal Verification

Mutual Authentication: Our protocol can ensure the mutual authentication between the userA and the device D. At the same time, it can provide the mutual authentication between the service M and the device D.The user’s authentication vectorCMA, the one-time password secret RA, and the service access and authentication code list ALA are securely shared by the service M to device D during the service registration and binding process. The device D can use equation gAVMD=yMhAVMACMACRArchD⋅reTbmodp and gAVMA=yMhALAIDACHMA⋅reTbmodp to verify the received shared secret information to ensure the data integrity of the shared secret.In the subsequent interaction process, the serviceM can authenticate user A according to the authentication information passed by user A, or authenticate device D according to the authentication vector given by device D. User A and the device D can authenticate the service M according to the authentication vector returned by the service M, thereby the process can realize the mutual authentication among device D, user A, and service M.When userA sends the authentication request to device D, device D authenticates the user by the equation gCMA+OPT=SCRM⋅rcHM⋅yAhTOTPRA,Tamodp with the locally stored information (RA and CMA). After user A receives the TOKEN issued by device D, user A can authenticate device D according to the signature value. In this way, user A and device D complete the mutual authentication.Data Confidentiality and Integrity: In this scheme, symmetric encryption is used to ensure data confidentiality and a signature is used to ensure data integrity. The private data such aspw,BIO,B,C,opt,xA,MA,RA are all securely shared in the abovementioned form in our protocol. It is not transmitted or transferred in plain text to the user or device. The attacker cannot obtain the private data by calculating the discrete logarithm. In addition, its private key of each entity is used to sign each interactive data to protect the integrity. Once the received data are modified, the verification equation does not hold. Therefore, the proposed scheme can guarantee data integrity.Resistance to Several Types of Attacks:(i)
Replay Attack: Our scheme uses the timestamp and the nonce to resist replay attacks. When the authentication vector is generated, they are encrypted with the private key of the user or device. Based on the abovementioned proof, the attacker cannot obtain the user or device’s private key in polynomial time. Therefore, the attacker cannot modify the replay message’s timestamp or random number to implement the replay attack successfully.(ii)
Forward and Backward Secrecy: The session keyKS=raku is only affected with the random numbers ka and ku. Even if the Eve obtains all long-term secrets of A and D and can intercept all messages, the previous and future session keys are still secure because of the CDH and DDH problems.(iii)
Mobile Device Loss Attacks: Once Eve steals a mobile device ofA, Eve can extract all stored values CA,CHMA,ALA by side-channel attacks. Eve can also get IDA by analyzing the messages. Eve will try to guess A’s pw and BA if the above process happens. It is intractable to guess the two values in the meantime because of the collision-resistant property of the hash function.(iv)
Offline Password Guessing: Only if Eve can obtain thepw, and BA, he or she can successfully impersonate user A. However, Eve cannot reveal the BA using only CA without knowing the BIO. Eve also needs pw to compute HPW to decrypt CHMA, However, HPW is not stored in any device. There is no way but to guess for Eve to obtain the pw in offline password guessing attack.(v)
Privileged Insider Attacks: In our scheme, the userA’s pw is not transmitted in any phases. We use BA and random number rc to mask the pw. Obviously, only A owns the pw, so our scheme is resistant to privileged insider attacks.Table3 epitomizes the comparison of the security properties among ours and the schemes in [12–15].Proxy Privacy: We use the aliashD to protect the device’s privacy in our scheme. The alias hD not only hides the device’s true ID but shows the relationship of IDA and IDD as well. Therefore, for each user bonded with the device IDD, the device will own a unique alias hD to present the relationship. The alias hD is calculated by the private key of service M, IDA, IDD, and kd through the hash function. No one can directly obtain the true ID through the alias hD or infer from the other alias the association implied by this alias. Therefore, this scheme can realize the anonymity of proxy signatures.Strong Unforgeability: The proxy signature private keyxP is comprised of the proxy private keys of the proxy signer and the original signer and the secret value of the proxy signer. yP, the public key of the proxy signer, includes the proxy signer’s customized and secret data and the original signer’s data. When the proxy signature public key yP, the signature σ of the proxy signature warrant, and the device public keys yD and yN are known, the original signer or attacker cannot obtain the proxy signatures private key xP through the free combination or calculation of the above information. Therefore, this scheme satisfies the strong unforgeability of proxy signatures.Proxy signer’s deviation: In our scheme, when the proxy signer tries to generate a validmw, the difficulty lies in finding the original signer’s xM and r−1modp in polynomial time when only one alias hD and a proper original signature σ are known. However, the attacker cannot solve the discrete logarithm in polynomial time, so this scheme satisfies the nondivergence of proxy signatures.Verifiability: In our scheme, the proxy signatures can be verified bygσm=yp⋅ruhmsgmodp.Strong identifiability: The format is different between the raw signaturesm,σ,rg,Te and proxy signatures mw,hD,σ,rg,ru,Te,Tg,yp,σm,m in our scheme. Anyone can distinguish the raw signatures and proxy signatures in polynomial time.Strong Recognizability: When verifying the signature, anyone can get〈hD,mw,σ〉 in the proxy signature. Only the original signer M can generate the alias hD and the correct signature of proxy signature warrant in this scheme. Therefore, any verifier can believe that the hD is who produces the proxy signature.Strong Nonrepudiation: When the original signerM tries to attack a proxy signature private key xP, the original signer M needs to know xD, xM, and kh. However, in this scheme, xN=xD+kh⋅rhmodp is something that the original signer M and any attacker cannot calculate in polynomial time.Anti-abuse: In this scheme, a signature revocation list is added to prevent the proxy signer from abusing the proxy signature authority. Once the proxy signer is found to be abusive, the original signer can add the corresponding information to the signature revocation list and correct the proxy signer’s abuse further.Table 3
Security properties comparison.
Security properties[12][13][14][15]Our schemeMutual authenticationYYYYYMultifactor authentication3 factors3 factors3 factors1 factor4 factorsAuthorizationNYNNYPrivileged insider attacksYYYYYMobile device loss attacksYYYNYForward and backward secrecyYYYYY


### 5.2. Scyther Simulation

In this section, we conduct a Scyther simulation [46] to prove the security of our scheme. The Scyther tool can output the protocol role execution trajectory. In addition, the several security models are included in Scyther simulation tool, such as the standard Dolev–Yao model and other nine adversary models, such as CK model and eCK model etc. The Scyther tool uses the Security Protocol Description Language (SPDL) to describe and analyze security protocols and can detect protocol vulnerabilities such as replay, man-in-the-middle, and reflection attacks based on several different security objectives. The Scyther tool will automatically output the verification results: if the assumption is valid, then output ok and verified. If the assumption is not valid, then output is false and give the existing attack.In the proposed model described by SPDL, to simplify the analysis, this article defines three roles, A, P, andM, which represent user A, device D, and service M, respectively. We verify the proposed scheme under the Dolev–Yao attack model.As shown in Figures4 and 5, this article uses the SPDL language to model the protocol. The modeling of this scheme is divided into two steps, registration and certification. The security of the proposed scheme can be ensured through a series of Scyther’s requirements. As shown in Figures 6 and 7, the designed scheme meets all the security objectives in Scyther, and no attack is found under its simulation.Figure 4
Simulation code during registration phase.Figure 5
Simulation code during authentication phase.Figure 6
Simulation results during the registration phase.Figure 7
Simulation results during the authentication phase.


### 5.3. Authentication Proof Using BAN Logic

We use BAN logic [47] to prove the security of the proposed scheme. Since the registration phase runs in a secure channel, only the security of the User Authentication and Proxy Signature Generation Phase needs to be considered. The User Authentication and Proxy Signature Generation Phase must meet the following goals:Goal 1.User∣≡Device↔KSUserGoal 2.Device∣≡Device↔KSUserGoal 3.User∣≡Device∣≡Device↔KSUserGoal 4.Device∣≡User∣≡Device↔KSUserFirst, we convert the protocol as follows:Msg 1.User⟶Device:NAKA−1,NAMsg 2.Device⟶User:NB,NBKP−1Msg 3.User⟶Device:NCKSWe then define the hypotheses and initial status as follows:A1. User∣≡♯NAA2. Device∣≡♯NBA3. User∣≡Device∣⇒NBA4. Device∣≡User∣⇒NAA5. User∣≡∣⟶kPDeviceA6. Device∣≡∣⟶kAUserBased on the above informations, the proofs are presented as follows:From the Msg 1, we have the following:(3)Device⊲NAKA−1.FromA6, with the successful confirmation and the message-meaning rule, we can get as follows:(4)Device∣≡User∣∼NAKA−1.According to theNA, freshness rule, A1 and A4, we can get the following:(5)Device∣≡♯NA.According to the nonce verification rule andNA, we can derive the following:(6)Device∣≡User∣≡NA.According toA4, NA and the jurisdiction rule, we can get the following:(7)Device∣≡NA.Device can compute theKS=NANB, according to the belief rule, we can derive the Goal 2:(8)Device∣≡User↔KSDevice.Equally, we can derive Goal 1 according to Msg 2 and the same deductions.From Msg 3, we get the following:(9)Device⊲NCKS.According to Goal 2 we have proved, and message-meaning rule, we can derive the following:(10)Device∣≡User∣∼NC.Based on theA2, the random number and freshness rule and the nonce verification rule, we can derive the following:(11)Device∣≡User∣≡NC.SinceNC is composed of TOTP codes, legal TOTP codes can only be generated by legal users, and according to Device∣≡User∣≡NA and the belief rule, we can derive the Goal 4:(12)Device∣≡User∣≡User↔KSDevice.Equally, we can derive Goal 3 according to Msg 2 and the same deductions.


## 5.1. Informal Verification

Mutual Authentication: Our protocol can ensure the mutual authentication between the userA and the device D. At the same time, it can provide the mutual authentication between the service M and the device D.The user’s authentication vectorCMA, the one-time password secret RA, and the service access and authentication code list ALA are securely shared by the service M to device D during the service registration and binding process. The device D can use equation gAVMD=yMhAVMACMACRArchD⋅reTbmodp and gAVMA=yMhALAIDACHMA⋅reTbmodp to verify the received shared secret information to ensure the data integrity of the shared secret.In the subsequent interaction process, the serviceM can authenticate user A according to the authentication information passed by user A, or authenticate device D according to the authentication vector given by device D. User A and the device D can authenticate the service M according to the authentication vector returned by the service M, thereby the process can realize the mutual authentication among device D, user A, and service M.When userA sends the authentication request to device D, device D authenticates the user by the equation gCMA+OPT=SCRM⋅rcHM⋅yAhTOTPRA,Tamodp with the locally stored information (RA and CMA). After user A receives the TOKEN issued by device D, user A can authenticate device D according to the signature value. In this way, user A and device D complete the mutual authentication.Data Confidentiality and Integrity: In this scheme, symmetric encryption is used to ensure data confidentiality and a signature is used to ensure data integrity. The private data such aspw,BIO,B,C,opt,xA,MA,RA are all securely shared in the abovementioned form in our protocol. It is not transmitted or transferred in plain text to the user or device. The attacker cannot obtain the private data by calculating the discrete logarithm. In addition, its private key of each entity is used to sign each interactive data to protect the integrity. Once the received data are modified, the verification equation does not hold. Therefore, the proposed scheme can guarantee data integrity.Resistance to Several Types of Attacks:(i)
Replay Attack: Our scheme uses the timestamp and the nonce to resist replay attacks. When the authentication vector is generated, they are encrypted with the private key of the user or device. Based on the abovementioned proof, the attacker cannot obtain the user or device’s private key in polynomial time. Therefore, the attacker cannot modify the replay message’s timestamp or random number to implement the replay attack successfully.(ii)
Forward and Backward Secrecy: The session keyKS=raku is only affected with the random numbers ka and ku. Even if the Eve obtains all long-term secrets of A and D and can intercept all messages, the previous and future session keys are still secure because of the CDH and DDH problems.(iii)
Mobile Device Loss Attacks: Once Eve steals a mobile device ofA, Eve can extract all stored values CA,CHMA,ALA by side-channel attacks. Eve can also get IDA by analyzing the messages. Eve will try to guess A’s pw and BA if the above process happens. It is intractable to guess the two values in the meantime because of the collision-resistant property of the hash function.(iv)
Offline Password Guessing: Only if Eve can obtain thepw, and BA, he or she can successfully impersonate user A. However, Eve cannot reveal the BA using only CA without knowing the BIO. Eve also needs pw to compute HPW to decrypt CHMA, However, HPW is not stored in any device. There is no way but to guess for Eve to obtain the pw in offline password guessing attack.(v)
Privileged Insider Attacks: In our scheme, the userA’s pw is not transmitted in any phases. We use BA and random number rc to mask the pw. Obviously, only A owns the pw, so our scheme is resistant to privileged insider attacks.Table3 epitomizes the comparison of the security properties among ours and the schemes in [12–15].Proxy Privacy: We use the aliashD to protect the device’s privacy in our scheme. The alias hD not only hides the device’s true ID but shows the relationship of IDA and IDD as well. Therefore, for each user bonded with the device IDD, the device will own a unique alias hD to present the relationship. The alias hD is calculated by the private key of service M, IDA, IDD, and kd through the hash function. No one can directly obtain the true ID through the alias hD or infer from the other alias the association implied by this alias. Therefore, this scheme can realize the anonymity of proxy signatures.Strong Unforgeability: The proxy signature private keyxP is comprised of the proxy private keys of the proxy signer and the original signer and the secret value of the proxy signer. yP, the public key of the proxy signer, includes the proxy signer’s customized and secret data and the original signer’s data. When the proxy signature public key yP, the signature σ of the proxy signature warrant, and the device public keys yD and yN are known, the original signer or attacker cannot obtain the proxy signatures private key xP through the free combination or calculation of the above information. Therefore, this scheme satisfies the strong unforgeability of proxy signatures.Proxy signer’s deviation: In our scheme, when the proxy signer tries to generate a validmw, the difficulty lies in finding the original signer’s xM and r−1modp in polynomial time when only one alias hD and a proper original signature σ are known. However, the attacker cannot solve the discrete logarithm in polynomial time, so this scheme satisfies the nondivergence of proxy signatures.Verifiability: In our scheme, the proxy signatures can be verified bygσm=yp⋅ruhmsgmodp.Strong identifiability: The format is different between the raw signaturesm,σ,rg,Te and proxy signatures mw,hD,σ,rg,ru,Te,Tg,yp,σm,m in our scheme. Anyone can distinguish the raw signatures and proxy signatures in polynomial time.Strong Recognizability: When verifying the signature, anyone can get〈hD,mw,σ〉 in the proxy signature. Only the original signer M can generate the alias hD and the correct signature of proxy signature warrant in this scheme. Therefore, any verifier can believe that the hD is who produces the proxy signature.Strong Nonrepudiation: When the original signerM tries to attack a proxy signature private key xP, the original signer M needs to know xD, xM, and kh. However, in this scheme, xN=xD+kh⋅rhmodp is something that the original signer M and any attacker cannot calculate in polynomial time.Anti-abuse: In this scheme, a signature revocation list is added to prevent the proxy signer from abusing the proxy signature authority. Once the proxy signer is found to be abusive, the original signer can add the corresponding information to the signature revocation list and correct the proxy signer’s abuse further.Table 3
Security properties comparison.
Security properties[12][13][14][15]Our schemeMutual authenticationYYYYYMultifactor authentication3 factors3 factors3 factors1 factor4 factorsAuthorizationNYNNYPrivileged insider attacksYYYYYMobile device loss attacksYYYNYForward and backward secrecyYYYYY


## 5.2. Scyther Simulation

In this section, we conduct a Scyther simulation [46] to prove the security of our scheme. The Scyther tool can output the protocol role execution trajectory. In addition, the several security models are included in Scyther simulation tool, such as the standard Dolev–Yao model and other nine adversary models, such as CK model and eCK model etc. The Scyther tool uses the Security Protocol Description Language (SPDL) to describe and analyze security protocols and can detect protocol vulnerabilities such as replay, man-in-the-middle, and reflection attacks based on several different security objectives. The Scyther tool will automatically output the verification results: if the assumption is valid, then output ok and verified. If the assumption is not valid, then output is false and give the existing attack.In the proposed model described by SPDL, to simplify the analysis, this article defines three roles, A, P, andM, which represent user A, device D, and service M, respectively. We verify the proposed scheme under the Dolev–Yao attack model.As shown in Figures4 and 5, this article uses the SPDL language to model the protocol. The modeling of this scheme is divided into two steps, registration and certification. The security of the proposed scheme can be ensured through a series of Scyther’s requirements. As shown in Figures 6 and 7, the designed scheme meets all the security objectives in Scyther, and no attack is found under its simulation.Figure 4
Simulation code during registration phase.Figure 5
Simulation code during authentication phase.Figure 6
Simulation results during the registration phase.Figure 7
Simulation results during the authentication phase.


## 5.3. Authentication Proof Using BAN Logic

We use BAN logic [47] to prove the security of the proposed scheme. Since the registration phase runs in a secure channel, only the security of the User Authentication and Proxy Signature Generation Phase needs to be considered. The User Authentication and Proxy Signature Generation Phase must meet the following goals:Goal 1.User∣≡Device↔KSUserGoal 2.Device∣≡Device↔KSUserGoal 3.User∣≡Device∣≡Device↔KSUserGoal 4.Device∣≡User∣≡Device↔KSUserFirst, we convert the protocol as follows:Msg 1.User⟶Device:NAKA−1,NAMsg 2.Device⟶User:NB,NBKP−1Msg 3.User⟶Device:NCKSWe then define the hypotheses and initial status as follows:A1. User∣≡♯NAA2. Device∣≡♯NBA3. User∣≡Device∣⇒NBA4. Device∣≡User∣⇒NAA5. User∣≡∣⟶kPDeviceA6. Device∣≡∣⟶kAUserBased on the above informations, the proofs are presented as follows:From the Msg 1, we have the following:(3)Device⊲NAKA−1.FromA6, with the successful confirmation and the message-meaning rule, we can get as follows:(4)Device∣≡User∣∼NAKA−1.According to theNA, freshness rule, A1 and A4, we can get the following:(5)Device∣≡♯NA.According to the nonce verification rule andNA, we can derive the following:(6)Device∣≡User∣≡NA.According toA4, NA and the jurisdiction rule, we can get the following:(7)Device∣≡NA.Device can compute theKS=NANB, according to the belief rule, we can derive the Goal 2:(8)Device∣≡User↔KSDevice.Equally, we can derive Goal 1 according to Msg 2 and the same deductions.From Msg 3, we get the following:(9)Device⊲NCKS.According to Goal 2 we have proved, and message-meaning rule, we can derive the following:(10)Device∣≡User∣∼NC.Based on theA2, the random number and freshness rule and the nonce verification rule, we can derive the following:(11)Device∣≡User∣≡NC.SinceNC is composed of TOTP codes, legal TOTP codes can only be generated by legal users, and according to Device∣≡User∣≡NA and the belief rule, we can derive the Goal 4:(12)Device∣≡User∣≡User↔KSDevice.Equally, we can derive Goal 3 according to Msg 2 and the same deductions.


## 6. Performance Analysis

In this section, we analyze the performance of the solution from three aspects: (1) communication overhead; (2) storage overhead; and (3) calculation overhead and compare with [12–15]. Table 4 shows the symbols used in this section.Table 4
Performance analysis symbol definition.
OperationSymbolExponential operation of discrete logarithmsTdlexpModulo operationTmodMultiplication operation of discrete logarithmsTdlmulHash operationThAES operationTaesPoint double operation of discrete logarithmsTeccmulIn terms of communication overhead, this article mainly considers the communication overhead in user authentication and proxy signature generation phases. Without loss of generality, the security level defined in this article is equivalent to Advanced Encryption Standard (AES) 128 bits [48, 49], and the AES algorithm is used as the symmetric encryption algorithm. Specifically, the length of ID and PW is set as 128 bits, the key length based on the discrete logarithm algorithm is 256 bits. The key length of the ECC-based cryptographic algorithm is 256 bits, the hash function outputs 256-bits-length result, the random number is 128 bits, the identification length is 128 bits, the timestamp is 32 bits, and the auxiliary string C is 128 bits. 7 hash functions are defined in [15], and we consider that the output length and computational overhead of the above hash functions are consistent with those used in this paper.On the computational cost, we only consider the algorithm shown in Table4, ignoring other less time-consuming operations, and this article assumes that the GEN, REP, and TOTP functions all have the time for hashing complexity. This article uses the JAVA BigInteger library and JPBC library on device 1 (Intel(R) Core(TM) i7-6700K CPU @ 4.00 GHz) as a client and device 2 (Intel(R) Core(TM) i5-10600 KF CPU @ 4.10 GHz) as a server to measure the time of related operations, as shown in Table 5. Refering to [13], we consider GWi as device 2. For convenience, we divide the overhead on GWi as part of the AAS overhead.Table 5
Time requirements for various operations (unit: microsecondsμs).
SymbolClientServerTdlexp5.9274.829Tmod2.4772.201Tdlmul0.0080.005Th0.0500.033Taes0.6700.392Teccmul15.10012.980Table6 lists the computational cost of the schemes and related schemes in [12–15] in the process of User Authentication and Proxy Signature Generation phase. The running time of the proposed scheme is 63.283 (20.127 for client, 43.156 for server). The running time of [12–15] is 69.902 (30.942 for client, 38.96 for server), 84.445 (45.52 for client, 39.025 for server), 129.973 (78.033 for client, 51.94 for server), and 108.195 (30.24 for client, 77.955 for server), respectively. The results show that the computational overhead of our scheme, especially the client’s, is smaller than [12–15]. The server is always considered a rich-resource entity. Therefore, it is acceptable that the computational overhead of the server in our scheme is a little larger than that in [12].Table 6
Computation costs of related schemes (unit: microsecondsμs).
Computation costsClientServerTotal[12]9Th+Taes+2Teccmul=30.9424Th+3Teccmul=38.9669.283[13]15Th+3Teccmul=45.4217Th+3Teccmul=39.02584.445[14]Tmod+7Th+5Teccmul=78.0334Th+4Teccmul=51.94129.973[15]5Th+2Teccmul=30.2415Th+6Teccmul=77.955108.195Ours2TDLP+3Tmod+9Th+2Tdlmul+Taes=20.1277TDLP+4Tmod+5Th+4Tdlmul+Taes=43.15663.283On the storage cost, the client has to storeCHMA,ALA,CA,xA and the server needs to store CMA,hD,rc,rg,kh,IDA,CRA,mw,σ,Te,xD,xp. Table 7 shows that the total storage cost of our scheme is lower than that of the scheme in [13], which is little larger than that of the schemes in [12, 14, 15].Table 7
Storage cost (bytes).
SchemeClientServerOurs112180[12]8016[14]4916[13]224144[15]64112On the communication overhead, the proposed scheme completing authentication protocol needs 4 rounds. Table8 shows the communication overhead of [12–14] and ours. From Table 8, it can be inferred that the communication overhead of our scheme is smaller than that of the scheme in [13], which is little larger than the schemes in [12, 14].Table 8
Communication overhead (bytes).
SchemeRoundsOverheadOurs4132+124+52=308[12]2200[14]4224[13]4528[15]4516Based on the above results of comparison and analysis, our scheme outperforms the schemes in [12–15] in the term of computation cost, and better than the scheme in [14] in the term of storage cost and communication cost. Our scheme needs more storage than the scheme in [12] due to the more fine-grained access control of users.


## 7. Conclusions

We propose a secure multifactor authentication and access control mechanism base on proxy signature for cloud-fog hybrid electronic bill service in the 5G network. The results of BAN logic and Scyther simulation show that our scheme is security, and performance analysis shows that our scheme has a lower computational overhead compared with other schemes. In addition, the proposed scheme can provide more security features without sacrificing performance.



---

*Source: 3658402-2022-05-12.xml*