# Heterogeneous Cross-Domain Identity Authentication Scheme Based on Proxy Resignature in Cloud Environment

Authors: Yongyang Lv; Wenju Liu; Ze Wang
Journal: Mathematical Problems in Engineering
 (2020)

---

## Abstract

Based on proxy resignature, the signature transformation between trust domains of different cryptographic systems is realized with the help of the cloud authentication center, so as to achieve cross-domain access between users and cloud service providers in heterogeneous environment. Hierarchical ID tree realizes the uniqueness of identity in communication, and the security of heterogeneous cross-domain identity authentication is enhanced by the two-factor authentication of “password + key” and temporary identity replacing real identity. The security of the scheme is proved under the CK model, which can anonymously trace entity identity, resist replay attacks, replacement attacks, and man-in-the-middle attacks, and the simulation experiment is carried out. By searching it in related fields, no paper on heterogeneous cross-domain identity authentication based on proxy resignature has been published yet. The results of this paper show that the proposed scheme has better computing performance and higher security.


---

## Body

## 1. Introduction

A trend of integration has begun among various cloud services in the current cloud environment [1], and more cloud services need to be connected with other cloud services of different domains. Different security domains may adopt different security management mechanisms and password systems [2], and each is only responsible for identity authentication and management within its domain. When users access other domains of different cryptographic systems, there is the problem of heterogeneous cross-domain authentication. Current identity authentication schemes based on mainstream cryptography systems are (a) PKI (public key infrastructure) system based on digital certificates [3], (b) identity-based cryptography (IBC) [4, 5], and (c) certificateless cryptography (CLC) [6]. Among them, PKI system is the best system to guarantee network security, which can provide identity authentication in the open cloud environment. The CLC can effectively solve the key escrow problem in the IBC system.Proxy resignature was proposed by Blaze et al. [7] at the European Cryptography Conference in 1998, and the specific definition of formal security was given by Ateniese and Hohenberger [8]. In proxy resigning, the semitrusted proxy uses the resigning key to convert the trustee’s signature into the entrusting side's signature for the same message, but it cannot generate the message’s legal signature on behalf of either side of them. The meaning of “semitrusted” is believing that the proxy will make the signature transformation according to the scheme. The proxy resignature is used to guarantee the confidentiality, bidirectional authentication, unforgeability, and anonymity of identity information. Malicious attackers cannot obtain the identity information of the sender or receiver from the ciphertext, which plays an effective role in protecting the privacy of user identity on both sides and allows the intercloud identity authentication center to verify the user's identity information and return the authentication results, reducing the computation load carried by users. Yang et al. [9] proposed a threshold proxy resignature scheme to prevent agents from abusing the power of signature conversion. Tian [10] proposed a lattice-based identity proxy resignature scheme in the random prediction model, but the signature length was large and the practicability was poor. Tian et al. [10] constructed a lattice-based proxy resignature scheme to resist the attack of quantum computing. Yang et al. [11] proposed a separable online/offline proxy resignature scheme, which effectively improved the real-time performance of the proxy resignature. Wang and Lv [12] constructed two server-assisted proxy resignature schemes, both of which are provable and secure in the random prediction model, but the second scheme cannot resist the collusion attack from the server and the malicious agent. In order to reduce the computational cost of the verifier, the papers [12, 13] constructed a secure server-assisted verification agent resignature scheme under the random prediction model and the standard model, respectively. However, the existing proxy resignature schemes [9–13] almost all realize the existence unforgery, which can only ensure that the attacker cannot forge the signature of new messages. In order to meet the security requirements of cross-domain authentication in cloud computing environment, Yang et al. [9], based on CDH and CRF assumptions, proposed a strongly nonfalsifiable server-assisted authentication proxy resignature algorithm under the standard model and delegated most of the computing tasks of signature verification to the server.Literature [14] uses certificates and PKI to realize cross-domain certification scheme, but both schemes involve complex certificate management and need to afford relatively high computational cost. Literature [15] proposes a grid-based PKI multidomain authentication model, but the model cannot resist forgery attack. Literature [16, 17] takes IBC domain authentication server as an entity in PKI domain and adopt the method of exchanging certificates for authentication, which is inefficient and the trusted domains are not of the same level. Literature [18] proposed an identity authentication scheme based on PTPM and certificatelessness, which realizes the credibility of authentication results between users and cloud service providers but does not consider cross-domain authentication and other issues. Literature [19] proposes a key exchange protocol for cross-domain authentication in the wireless grid, but the use of symmetric encryption causes high computing cost. Literature [20] proposes a cross-domain authentication scheme based on blockchain, inheriting such security defects as blockchain algorithm vulnerability. Literature [21] proposes cross-domain authentication based on different cryptographic systems, but a heavy load is carried by intercloud authentication centers, which is likely to lead to single point authentication failure. Literature [22] proposes key negotiation between different cryptographic systems to achieve cross-domain authentication between trusted domains of different levels, but users carry a large amount of computation and communication. At present, signature encryption algorithm has been widely used in cross-domain authentication schemes, but most of the authentication algorithms are based on the same cryptographic system or use the same system parameters in different cryptographic systems. This security mechanism does not apply well to the actual Internet of Things authentication scenario. Wang et al. [23] proposed a signature scheme based on PKI and IBC, which not only satisfies anonymity but also supports bidirectional verification. However, it has problems such as large traffic and large computation. The cross-domain authentication mechanism proposed by Ferrag et al. [24] can meet the requirements of internal security but does not verify the security of temporary keys. Wang et al. [25] propose a scheme to ensure the security of temporary keys, but it does not support the use of different system parameters in each domain environment. In addition, in the existing cross-domain authentication technologies [26, 27], certificate authentication requires detection from the book to the root certificate. The authentication path is too long and the efficiency of path authentication is low, which greatly affects the practical application scenarios of cross-domain authentication technology.Most of the existing cross-domain authentication models cannot implement the authentication of different cryptographic systems well. In the authentication schemes which can realize different cryptographic systems, there are either big security problems or high computational cost. This paper proposes a heterogeneous cross-domain identity authentication scheme under the cloud environment. Based on the highly antiforgery proxy resignature algorithm by server-aided verification in literature [28], the scheme realizes the identity authentication and secure access between users of CLC and PKI and cloud service providers. Cloud authentication (CA) center is introduced to issue certificates for the security domains of different cryptographic systems and provides signature transformation for cross-domain users, so that users can access the security domains of different cryptographic systems. The scheme uses the hierarchical ID tree to realize the uniqueness of identity in communication and enhances the security of heterogeneous cross-domain identity authentication through two-factor authentication of “password + key.” According to the analysis, the security of the scheme is verified under the CK model, which can resist replay attack, replacement attack, and man-in-the-middle attack. Meanwhile, temporary identity is introduced for the anonymous tracing in the authentication, realizing bidirectional authentication between users and cloud service providers. Finally, the simulation experiment is carried out to further strengthen the security proof of the scheme. Compared with the existing literature, it has higher security and computational efficiency. Searching it in related fields, no paper on heterogeneous cross-domain identity authentication based on proxy resignature has been published yet.Section2 of this paper introduces the basic knowledge used in the scheme. Section 3 describes in detail the heterogeneous authentication scheme. Section 4 provides proof of the scheme’s security and makes a comparison of the existing work and the scheme in this paper. Section 5 gives the conclusion.


## 2. Preliminary Knowledge

### 2.1. Bilinear Mapping

LetG1 and G2 be cyclic groups of order p, p is a prime number, and g is a generator of G1. Define bilinear mapping e: G1 × G1 ⟶ G2.


### 2.2. Assumptions of the Security Theory

Computational CDH (Computational Diffie-Hellman) problem: for a given triplet (g, ga, gb) ∈ G13, for any a, b ∈ Zp∗, compute gab∈.Definition 1.
(CDH hypothesis). For any probabilistic polynomial time algorithmB, the probability of successfully solving CDH problem is AdvCDH (B) = Pr [B (g, ga, gb) = gab: g∈G1, a, b ∈ Zp∗]. If AdvCDH (B) is negligible, CDH problem on G1 is difficult [17].Definition 2.
(CRH hypothesis). Suppose a family of anticollision hash functionsHK:0,1∗⟶0,1nk, where k is an indicator and nk is the length of the output message. The probability of any probabilistic polynomial time algorithm B successfully finding a pair of collision of HK is AdvCRH (B) = Pr [B(k) = (m0, m1): m0 ≠ m1, HK(m0) = HK(m1)]. If AdvCRH (B) is negligible, then HK is anticollision [29].


### 2.3. CK Security Model

The CK (Canetti-Krawczyk) security model [30, 31] defines two attack models as the AM model for authenticated links and the UM model for unauthenticated links. In the ideal model AM, any attacker cannot forge, tamper, and replay messages and can only pass the same message once and has the ability to query session key, call operation, compromise protocol participants, expose the session key, and test the session key.Definition 3.
Given that A is any attacker in the AM, if the session key of the authentication protocol is safe in the AM, the properties below are satisfied.Property 1.
Both parties can obtain the same session key after they are not compromised and execute the agreement successfully.Property 2.
The attacker A makes the test of attacking the session key query, and according to the result, A can correctly determine whether the output value of the session key is a random value or A real value with the probability not exceeding (1/2) +ε (ε represents any value that can be ignored within the security parameter range).


## 2.1. Bilinear Mapping

LetG1 and G2 be cyclic groups of order p, p is a prime number, and g is a generator of G1. Define bilinear mapping e: G1 × G1 ⟶ G2.


## 2.2. Assumptions of the Security Theory

Computational CDH (Computational Diffie-Hellman) problem: for a given triplet (g, ga, gb) ∈ G13, for any a, b ∈ Zp∗, compute gab∈.Definition 1.
(CDH hypothesis). For any probabilistic polynomial time algorithmB, the probability of successfully solving CDH problem is AdvCDH (B) = Pr [B (g, ga, gb) = gab: g∈G1, a, b ∈ Zp∗]. If AdvCDH (B) is negligible, CDH problem on G1 is difficult [17].Definition 2.
(CRH hypothesis). Suppose a family of anticollision hash functionsHK:0,1∗⟶0,1nk, where k is an indicator and nk is the length of the output message. The probability of any probabilistic polynomial time algorithm B successfully finding a pair of collision of HK is AdvCRH (B) = Pr [B(k) = (m0, m1): m0 ≠ m1, HK(m0) = HK(m1)]. If AdvCRH (B) is negligible, then HK is anticollision [29].


## 2.3. CK Security Model

The CK (Canetti-Krawczyk) security model [30, 31] defines two attack models as the AM model for authenticated links and the UM model for unauthenticated links. In the ideal model AM, any attacker cannot forge, tamper, and replay messages and can only pass the same message once and has the ability to query session key, call operation, compromise protocol participants, expose the session key, and test the session key.Definition 3.
Given that A is any attacker in the AM, if the session key of the authentication protocol is safe in the AM, the properties below are satisfied.Property 1.
Both parties can obtain the same session key after they are not compromised and execute the agreement successfully.Property 2.
The attacker A makes the test of attacking the session key query, and according to the result, A can correctly determine whether the output value of the session key is a random value or A real value with the probability not exceeding (1/2) +ε (ε represents any value that can be ignored within the security parameter range).


## 3. Heterogeneous Cross-Domain Identity Authentication Scheme Based on Proxy Resignature

### 3.1. Heterogeneous Cross-Domain Authentication Model Based on Proxy Resignature

The cross-domain authentication model under heterogeneous environment is shown in Figure1. The model includes five participating entities: (1) cloud service provider (CSP), which provides users with a variety of cloud services and uses secure devices of Trusted Platform Module (TPM) to store, encrypt, and sign sensitive data such as keys and random numbers; (2) user (U), who uses any terminal device that supports Portable TPM (Portable TPM, PTPM) security module to access the cloud service and complete the cross-domain identity authentication process with the cloud service provider. TPM and PTPM can ensure credible identity authentication and correct authentication results; (3) PKI domain certification center (CA1), which is responsible for the application, issuance, revocation, and inquiry of certificates of users in the domain and signing their temporary identity in the domain; (4) CLC key generation center (KGC), which mainly generates and distributes part of the keys for users in the domain and cloud service providers and is responsible for tracing the true identity of users with malicious anonymous behaviors; (5) intercloud authentication center (CA2) for identity authentication between different trust domains and signature conversion.Figure 1
Heterogeneous cross-domain authentication model based on proxy resignature.


### 3.2. Scheme Description

In this scheme, any two trusted domains are set as PKI domain and CLC domain, respectively. CA1 is the authentication center of PKI domain, KGC is the key generation center of CLC domain, and intercloud authentication center (CA2) generates resignature keys for domains of different cryptosystems and provides trust support and signature conversion. At the same time, it verifies the legitimacy of the subdomain of different cryptographic systems, and if it is legitimate, it issues a certificate for the security domain. The subdomains manage users and cloud service providers in their own domains, respectively, and provide authentication for users in their own security domains to access cloud service providers and authentication of public cross-domain identities from other domains. In this scheme, if a user of a security domain sends access requests to the CSP of another security domain with a different password system, the CSP will, after receiving it, verify the message and send the user’s message to the CA2, which uses the resignature keys to transform the signature on the user’s certificate given by CA1 into one by KGC or one by KGC into one by CA1, followed by the conversion of the certificate. Then, the converted certificate and related identity information are sent to CA1 or KGC, where the converted signature is verified. If the verification is passed, the identity information of the user is sent to the CSP, which then sends out a response. The user, receiving the response, verifies the CSP’s identity. If the whole process works out, the cloud service provider establishes a trust connection with the user. The process of cross-domain authentication scheme based on proxy resignature under the heterogeneous environment is shown in Figure2.Figure 2
Flowchart of heterogeneous cross-domain authentication scheme based on proxy resignature.Because they share the same proxy resignature key and work independently, each intercloud authentication center (CA2) is equal on the signature transformation, so this paper only discusses the heterogeneous cross-domain authentication scheme based on a single cloud certification center, which can be easily extended to multiple intercloud authentication center with the security ensured.


#### 3.2.1. System Establishment

LetG1 and G2 be cyclic groups of order p, p is a prime number, and g is a generator of G1. Define bilinear mapping e: G1 × G1 ⟶ G2. Select two anticollision hash functions H1:0,1∗⟶0,1nc and H2:0,1∗⟶0,1nm, nm<p, nc<p, and the output of the hash function is a member of Zp∗. Randomly select three elements g1, g2, and u ∈ G1, and randomly select nm elements u1,…,unm; the symbol “||” represents the string connection operator, exposing the system parameter pa = {G1, G2p, g, e, g1, g2, u, uii=1nm,H1,H2}.PKI authentication center (CA1) randomly selectsα∈Zp∗ as the master key of the system and calculates the public key PKCA1 = gα. Key generation center KGC randomly selects β∈Zp∗ as the master key of the system and calculates the public key PKKGC = gβ. The intercloud authentication center (CA2) randomly selects θ∈Zp∗ as the master key of the system and computes the public key PKCA2 = gθ. Finally, the public keys PKCA1, PKKGC, and PKCA2 are published. The public-private key pair for U is {PKU, skU}, and the public-private key pair for CSP is {PKCSP, skCSP}.Intercloud authentication center (CA2) generates resignature keys for domains of different cryptography systems and verifies the legitimacy of the subdomain of the security domain of different cryptography systems, and if it passes the verification, a certificate is issued to it. According to the proxy resignature generation algorithm proposed in literature [16], the resignature key generation process in this paper is as follows: CA2 randomly selects rp∈Zp∗, calculates Rp=grp, and sends to CA1; CA1 calculates Rp1=Rpg2α through its own private key and sends it to KGC; KGC calculates Rp2=g2β/Rp1 through its own private key and returns the result to CA2; CA2 calculates the resignature key rk=RpRp2=g2β−α. Because this paper has more symbols, Table 1 explains the meaning of these symbols.Table 1
Explanation of symbols.
SymbolMeaning of the symbolCLCCertificateless cryptographyPKIPublic key infrastructureUserCloud service providerKGCKey generation center in the CLC domainCertificate authority in the PKI domainCloud certification centerIDUThe true identity of userUIDCSPThe true identity of cloud service provider (CSP)TIDUTemporary identity of userUTIDCSPTemporary identity of cloud service provider (CSP)PKαThe public key of the certificate authority (CA1)PKβThe public key of the key generation center (KGC)PKCAThe public key of the cloud certification center CA2RkThe resignature key of the CA2DNαThe identity of the certificate authority (CA1)DNβThe identity of the key generation center (KGC)DNUThe identity of userUDNCSPThe identity of cloud service provider (CSP)αThe master key of the certificate authority (CA1)βThe master key of the key generation center (KGC)θThe master key of the cloud certification center (CA2)pkUThe public key of userUskUThe private key of userUpkCSPThe public key of the cloud service provider (CSP)pskCSPThe partial private key of the cloud service provider (CSP)skCSPThe private key of the cloud service provider (CSP)δCA1 ⟶UThe CA1’s signature of the user’s certificateCertUA certificate issued by a CA1 to userU


#### 3.2.2. Identity Generation

In this scheme, the hierarchical ID tree in literature [32] is adopted to define the ID value in order to realize the uniqueness of identity. As shown in Figure 3, in the 2-tier ID tree, the root node is the identity mark of the CLC key generation center or the authentication center CA of the PKI domain, and the leaf node is the identity mark of the users and cloud service providers in the trusted domain. If the identity of CA1 in the PKI domain is DNα and that of user U is DNU, then the real identity of U is defined as IDU = DNα||DNU. Similarly, the identity of KGC of the CLC domain is DNβ, and the identity of the CSP is DNCSP; then, the real identity of the CSP is defined as IDCSP = DNβ||DNCSP.Figure 3
Hierarchical ID tree.
(a)(b)


#### 3.2.3. Key Generation

(1)
User registration of the PKI domain(1)
User U selects a random secret value ofrU. Calculate temporary identity TIDU=H1IDU‖grU according to U’s real identity IDU. Encrypt the registration request EnIDU,IDCA1,TIDU,grU,PKUPKCA1 with CA1’s public key PKβ, and send it to CA1.(2)
CA1 uses its master key to decrypt the received registration message and verify whether U is a legitimate user of local security domain, by verifying user temporary identityTIDU = H1IDU‖grU. If it fails, give a response of failure or else check in the registered user list whether IDU already exists. If so, the certificate is issued directly to U, and if not, CA1 randomly selects SU∈Zp∗, generates the certificate message mCA1⟶U composed of CA1, TIDU, and PKU, computes MCA1⟶U =  H2mCA1⟶U = (MCA1⟶U,1,...MCA1⟶U,nm)∈0,1nm, E1 = u∏i=1nmuiMCA1⟶U,i, and h = H1mCA1⟶U‖gSU and uses CA1’s private key α to generate the signature δCA1⟶U=(δCA1⟶U,1,δCA1⟶U,2) = g2α£g3hSU,gSUof the certificate message mCA1⟶U. CA1 issues to U a certificate CertU = {TIDU,PKU,IDCA1,Tbegin,TendmCA1⟶U,δCA1⟶U}, where Tbegin,Tend is the valid start and end time of the certificate. CA1 saves {IDU,TIDU,grU,PKU} in the list of registered users, stores the certificate to the certificate library, reads the local timestamp TU, and sends the response EnIDU,IDCA1,TU,CertUPKU to U.(3)
User U decrypts the response through its private key and checks freshness of the timestampTU, verifies the validity of certificate CertU with public key PKCA1 of the root certificate CA1, and stores PKU,skU,CertU in PTMP if it is valid; otherwise, the registration fails and the certificate is refused.(2)
User registration of the CLC domain(1)
Cloud service provider CSP selects the random secret valuerCSP, xCSP∈Zp∗ and computes the public key PKCSP = gxCSP. According to the real identity of the cloud service provider (CSP), calculate the temporary identity TIDCSP = H1IDCSP‖grCSP. The message applying for registration is encrypted through the public key of the KGC and EnIDCSP,TIDCSP,grCSP,PKCSPPKKGC is sent to KGC.(2)
After decrypting the encrypted message with its master key, KGC obtains the real identityIDCSP according to DNCSP and verifies whether the temporary identity TIDCSP = H1IDCSP‖grCSP is correct. If not, give the response of failure, or else compute QCSP = H1TIDCSP and the partial private key pskCSP =  QCSPβ. Read the local timestamp TCSP, return the message EnpskCSP,TCSP,QCSPPKCSP to the CSP, and save {IDCSP,TIDCSP,grCSP,PKCSP,TCSP} in the user registration list.(3)
After receiving the message, the CSP uses its own private key to decrypt the message and verify the freshness of the timestampTCSP, calculates the complete private key skCSP = (xCSP,pskCSP), and keeps it in PTMP secretly. Finally, the public key pkCSP is shared.


#### 3.2.4. Cross-Domain Authentication

(1)
PKI domain ⟶CLC domain cross-domain authentication(1)
UserU randomly selects y∈Zp∗ and uses the private key skU= (xU,pskU) to calculate the key negotiation parameterY′ = gy, randomly select the password value pw, and calculate w  = H1TIDU‖pw. Let m1=request1,IDCSP,TIDU,w,TU,NU,Y′, where request1 is the identity of access request, TU is the timestamp, and NU is the random parameter to keep the freshness of the message. Using the signature algorithm in literature [13], user U randomly selects rm∈Zp∗, calculates M1 = H2m1=M1,ii=1nm∈0,1nm, h1=H1m1‖grm, and £1 = u∏i=1nmuiM1,i, and uses the user’s private key sku to generate the signature of a message m1, (δU′=δU,1′,δU,2′) = g2skuE1g3h1rm,grm. Read certificate CertU and send the authentication request Enrequest1,IDCSP,TIDU,w,TU,NU,Y′,δU′,CertUPKCSP to the cloud service provider CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and perform the following operations:First check whetherrequest1 is an access request; if not, then refuse to accept it; if so, then proceed to the next step.Extract the public keyPKU of U in the certificate CertU and calculate m1=request1,IDCSP,TIDU,w,TU,NU,Y′ to verify whether e=δU,1′,g = eg2,PKUeE1g3h1,δU,2′ is true. If not, the authentication is terminated. If it is true, the authentication of U’s identity is completed. Then check whether user U’s identity exists. If so, go straight to repeat the cross-domain authentication. If it does not exist, check the freshness of timestamp TU and verify whether the start and end time of the certificate are valid. If any of the above steps fails, terminate the access; otherwise, proceed to the next step.Randomly selectNCSP1∈Zp∗, read timestamp TCSP1, and send the message applying for the certificate conversion EnIDCSP,IDCA2,TCSP1,NCSP1,CertUPKCA2 to CA2.(3)
CA2 decrypts the message with its own master key and performs the following operations:Check the freshness of timestampTCSP1 and use the public key of CA1 to verify the validity of CertU. If the verification fails, return the message of failure, or else, perform the next step.Use the resignature keyrk = g2β−α to convert CertU’s signature by CA1 δCA1⟶U = δCA1⟶U,1,δCA1⟶U,2 = g2α£g3hSU,gSU into a signature by KGC δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 = rkδCA1⟶U,1,δCA1⟶U,2 = g2β£g3hSU,gSU. Then, CertU issued by CA1 is converted into CertU1 issued by KGC. The validity period of CertU1 can be set to be very short, and CA2 cannot calculate the private keys of CA1 and KGC through the resignature key; that is, it cannot issue certificates in place of CA1 and KGC.CA2 calculatesH1IDCA2, reads the timestamp TCA, and sends the message EnIDCSP,IDCA2,TCA,NCSP1,H1IDCA2,CertU,CertU1PKKGC to KGC.(4)
KGC take the following steps concerning the message:KGC checks the freshness of the timestampTCA after receiving the message. If the verification fails, the authentication is terminated. If it passes the verification, the signature of CertU1, δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 is verified by KGC’s public key, which means calculating eδKGC⟶U,1,g = −eg2,PKKGCe£g3h,δKGC⟶U,2 and seeing whether it is valid or not. If it is not, the authentication is terminated. If it is valid, CertU1 is a legal certificate, and KGC accepts the certificate CertU and sends the message EnIDCSP,IDCA2,NCSP1,H1IDCA2,CertU,CertU1PKCSP to the CSP.(5)
After receiving the message, the CSP will check whetherNCSP1 in the message is the same as the random parameter in the message applying for transformation. If not, the authentication will be terminated. Otherwise, save TIDU,w,N1,D1,CertU in the authentication list, N1and D1as the number of times and valid time of U repeating cross-domain authentication. Finally, the CSP randomly selects NCSP2, z∈Zp∗ and uses the private key to calculate the key negotiation parameter Z′ = gz, reads the timestamp TCSP2, calculates the signature of IDCSPδCSP′ = H1IDCA2β, sends the response Enrequest1,IDCSP,IDCA2,TIDU,Z′,Y′,TCSP2,NCSP2,NU,PKCSP,H1IDCA2δCSP′PKU to user U, and calculates the session key with U, K = PKUskCSPY′z.(6)
UserU checks whether NU in the response is consistent with the authentication request message sent, checks the freshness of timestamp TCSP2, verifies whether eδCSP′,g = eH1TIDCSP,PKβ is true, calculates whether H1IDCA2 is the same as that in the response message, and terminates the authentication if any step fails. If all hold, save {IDCA2,IDCSP, PKCSP, H1IDCA2} to the authentication list and calculate the session key K = PKCSPskUZ′y. The PKI domain will establish a trusted heterogeneous cross-domain connection with the CLC domain.(2)
CLC domain ⟶ PKI domain cross-domain authenticationWhen a user in the CLC domain sends an access request to a CSP in the PKI domain, the KGC in the CLC domain signs the certificate issued by CA2 and sends it to user U, who then sends it to the CSP as part of the access request. The rest steps are the same as that in the “PKI domain ⟶ CLC domain cross-domain authentication,” so it will not be repeated.


#### 3.2.5. Repeated Cross-Domain Authentication

User U and cloud service provider CSP pass the first cross-domain authentication, and the cloud service provider records the user’s identity information in the user registration list. Repeated cross-domain authentication is mainly used to determine whether the number of times of domain crossing and timestamps are within the valid range through the session keys provided by users and cloud service providers, so as to determine whether the repeated cross-domain authentication is successful. Repeated cross-domain authentication no longer requires interaction with the intercloud authentication center, and users and cloud service providers are not required to carry heavy loads of computation. This means the completion of security authentication of the bidirectional cross-domain identity. The repeated cross-domain authentication model is shown in Figure4.(1)
User U reads the timestampTi, selects random parameters Ni, yi∈Zp∗, calculates key negotiation parameter Yi = gyi, enters temporary id TIDU and password pw, calculates w′  = H1TIDU‖pw , and sends the message Enrequesti,IDCSP,TIDU,w,Ti,Ni,Yi, CertUPKCSP to CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and then performs the following operations:Determine whetherrequesti is an access request, check the freshness of the timestamp Ti, query user information in the access user list according to TIDU, and verify whether it is the same as w in the user list. If they are different, terminate authentication and return the information of error to user U.Verify whetherD1 exceeds the time validity, and verify whether N1 exceeds the maximum number of visits. If either of them exceeds its range, then terminate the authentication.If any part of the above verification fails, stop execution or update the access list toN1 = N1+1. The CSP reads timestamp To, selects the random parameters NO, zi∈Zp∗, calculates the session key parameter Zi = gzi, and calculates the session key Ki = PKUskCSPYizi. Finally, it sends the message Enrequesti,To,Ni,No,Zi,YiPKU to U.(3)
UserU checks whether the Ni in the response is consistent with the one in the authentication request sent, checks the freshness of the timestamp To, and terminates authentication if the verification fails. If the above verification is passed, the session key Ki = PKcspskUZiyi is calculated and a trusted heterogeneous cross-domain connection is established between the PKI domain and the CLC domain.Figure 4
Repeated cross-domain authentication model.


## 3.1. Heterogeneous Cross-Domain Authentication Model Based on Proxy Resignature

The cross-domain authentication model under heterogeneous environment is shown in Figure1. The model includes five participating entities: (1) cloud service provider (CSP), which provides users with a variety of cloud services and uses secure devices of Trusted Platform Module (TPM) to store, encrypt, and sign sensitive data such as keys and random numbers; (2) user (U), who uses any terminal device that supports Portable TPM (Portable TPM, PTPM) security module to access the cloud service and complete the cross-domain identity authentication process with the cloud service provider. TPM and PTPM can ensure credible identity authentication and correct authentication results; (3) PKI domain certification center (CA1), which is responsible for the application, issuance, revocation, and inquiry of certificates of users in the domain and signing their temporary identity in the domain; (4) CLC key generation center (KGC), which mainly generates and distributes part of the keys for users in the domain and cloud service providers and is responsible for tracing the true identity of users with malicious anonymous behaviors; (5) intercloud authentication center (CA2) for identity authentication between different trust domains and signature conversion.Figure 1
Heterogeneous cross-domain authentication model based on proxy resignature.


## 3.2. Scheme Description

In this scheme, any two trusted domains are set as PKI domain and CLC domain, respectively. CA1 is the authentication center of PKI domain, KGC is the key generation center of CLC domain, and intercloud authentication center (CA2) generates resignature keys for domains of different cryptosystems and provides trust support and signature conversion. At the same time, it verifies the legitimacy of the subdomain of different cryptographic systems, and if it is legitimate, it issues a certificate for the security domain. The subdomains manage users and cloud service providers in their own domains, respectively, and provide authentication for users in their own security domains to access cloud service providers and authentication of public cross-domain identities from other domains. In this scheme, if a user of a security domain sends access requests to the CSP of another security domain with a different password system, the CSP will, after receiving it, verify the message and send the user’s message to the CA2, which uses the resignature keys to transform the signature on the user’s certificate given by CA1 into one by KGC or one by KGC into one by CA1, followed by the conversion of the certificate. Then, the converted certificate and related identity information are sent to CA1 or KGC, where the converted signature is verified. If the verification is passed, the identity information of the user is sent to the CSP, which then sends out a response. The user, receiving the response, verifies the CSP’s identity. If the whole process works out, the cloud service provider establishes a trust connection with the user. The process of cross-domain authentication scheme based on proxy resignature under the heterogeneous environment is shown in Figure2.Figure 2
Flowchart of heterogeneous cross-domain authentication scheme based on proxy resignature.Because they share the same proxy resignature key and work independently, each intercloud authentication center (CA2) is equal on the signature transformation, so this paper only discusses the heterogeneous cross-domain authentication scheme based on a single cloud certification center, which can be easily extended to multiple intercloud authentication center with the security ensured.


### 3.2.1. System Establishment

LetG1 and G2 be cyclic groups of order p, p is a prime number, and g is a generator of G1. Define bilinear mapping e: G1 × G1 ⟶ G2. Select two anticollision hash functions H1:0,1∗⟶0,1nc and H2:0,1∗⟶0,1nm, nm<p, nc<p, and the output of the hash function is a member of Zp∗. Randomly select three elements g1, g2, and u ∈ G1, and randomly select nm elements u1,…,unm; the symbol “||” represents the string connection operator, exposing the system parameter pa = {G1, G2p, g, e, g1, g2, u, uii=1nm,H1,H2}.PKI authentication center (CA1) randomly selectsα∈Zp∗ as the master key of the system and calculates the public key PKCA1 = gα. Key generation center KGC randomly selects β∈Zp∗ as the master key of the system and calculates the public key PKKGC = gβ. The intercloud authentication center (CA2) randomly selects θ∈Zp∗ as the master key of the system and computes the public key PKCA2 = gθ. Finally, the public keys PKCA1, PKKGC, and PKCA2 are published. The public-private key pair for U is {PKU, skU}, and the public-private key pair for CSP is {PKCSP, skCSP}.Intercloud authentication center (CA2) generates resignature keys for domains of different cryptography systems and verifies the legitimacy of the subdomain of the security domain of different cryptography systems, and if it passes the verification, a certificate is issued to it. According to the proxy resignature generation algorithm proposed in literature [16], the resignature key generation process in this paper is as follows: CA2 randomly selects rp∈Zp∗, calculates Rp=grp, and sends to CA1; CA1 calculates Rp1=Rpg2α through its own private key and sends it to KGC; KGC calculates Rp2=g2β/Rp1 through its own private key and returns the result to CA2; CA2 calculates the resignature key rk=RpRp2=g2β−α. Because this paper has more symbols, Table 1 explains the meaning of these symbols.Table 1
Explanation of symbols.
SymbolMeaning of the symbolCLCCertificateless cryptographyPKIPublic key infrastructureUserCloud service providerKGCKey generation center in the CLC domainCertificate authority in the PKI domainCloud certification centerIDUThe true identity of userUIDCSPThe true identity of cloud service provider (CSP)TIDUTemporary identity of userUTIDCSPTemporary identity of cloud service provider (CSP)PKαThe public key of the certificate authority (CA1)PKβThe public key of the key generation center (KGC)PKCAThe public key of the cloud certification center CA2RkThe resignature key of the CA2DNαThe identity of the certificate authority (CA1)DNβThe identity of the key generation center (KGC)DNUThe identity of userUDNCSPThe identity of cloud service provider (CSP)αThe master key of the certificate authority (CA1)βThe master key of the key generation center (KGC)θThe master key of the cloud certification center (CA2)pkUThe public key of userUskUThe private key of userUpkCSPThe public key of the cloud service provider (CSP)pskCSPThe partial private key of the cloud service provider (CSP)skCSPThe private key of the cloud service provider (CSP)δCA1 ⟶UThe CA1’s signature of the user’s certificateCertUA certificate issued by a CA1 to userU


### 3.2.2. Identity Generation

In this scheme, the hierarchical ID tree in literature [32] is adopted to define the ID value in order to realize the uniqueness of identity. As shown in Figure 3, in the 2-tier ID tree, the root node is the identity mark of the CLC key generation center or the authentication center CA of the PKI domain, and the leaf node is the identity mark of the users and cloud service providers in the trusted domain. If the identity of CA1 in the PKI domain is DNα and that of user U is DNU, then the real identity of U is defined as IDU = DNα||DNU. Similarly, the identity of KGC of the CLC domain is DNβ, and the identity of the CSP is DNCSP; then, the real identity of the CSP is defined as IDCSP = DNβ||DNCSP.Figure 3
Hierarchical ID tree.
(a)(b)


### 3.2.3. Key Generation

(1)
User registration of the PKI domain(1)
User U selects a random secret value ofrU. Calculate temporary identity TIDU=H1IDU‖grU according to U’s real identity IDU. Encrypt the registration request EnIDU,IDCA1,TIDU,grU,PKUPKCA1 with CA1’s public key PKβ, and send it to CA1.(2)
CA1 uses its master key to decrypt the received registration message and verify whether U is a legitimate user of local security domain, by verifying user temporary identityTIDU = H1IDU‖grU. If it fails, give a response of failure or else check in the registered user list whether IDU already exists. If so, the certificate is issued directly to U, and if not, CA1 randomly selects SU∈Zp∗, generates the certificate message mCA1⟶U composed of CA1, TIDU, and PKU, computes MCA1⟶U =  H2mCA1⟶U = (MCA1⟶U,1,...MCA1⟶U,nm)∈0,1nm, E1 = u∏i=1nmuiMCA1⟶U,i, and h = H1mCA1⟶U‖gSU and uses CA1’s private key α to generate the signature δCA1⟶U=(δCA1⟶U,1,δCA1⟶U,2) = g2α£g3hSU,gSUof the certificate message mCA1⟶U. CA1 issues to U a certificate CertU = {TIDU,PKU,IDCA1,Tbegin,TendmCA1⟶U,δCA1⟶U}, where Tbegin,Tend is the valid start and end time of the certificate. CA1 saves {IDU,TIDU,grU,PKU} in the list of registered users, stores the certificate to the certificate library, reads the local timestamp TU, and sends the response EnIDU,IDCA1,TU,CertUPKU to U.(3)
User U decrypts the response through its private key and checks freshness of the timestampTU, verifies the validity of certificate CertU with public key PKCA1 of the root certificate CA1, and stores PKU,skU,CertU in PTMP if it is valid; otherwise, the registration fails and the certificate is refused.(2)
User registration of the CLC domain(1)
Cloud service provider CSP selects the random secret valuerCSP, xCSP∈Zp∗ and computes the public key PKCSP = gxCSP. According to the real identity of the cloud service provider (CSP), calculate the temporary identity TIDCSP = H1IDCSP‖grCSP. The message applying for registration is encrypted through the public key of the KGC and EnIDCSP,TIDCSP,grCSP,PKCSPPKKGC is sent to KGC.(2)
After decrypting the encrypted message with its master key, KGC obtains the real identityIDCSP according to DNCSP and verifies whether the temporary identity TIDCSP = H1IDCSP‖grCSP is correct. If not, give the response of failure, or else compute QCSP = H1TIDCSP and the partial private key pskCSP =  QCSPβ. Read the local timestamp TCSP, return the message EnpskCSP,TCSP,QCSPPKCSP to the CSP, and save {IDCSP,TIDCSP,grCSP,PKCSP,TCSP} in the user registration list.(3)
After receiving the message, the CSP uses its own private key to decrypt the message and verify the freshness of the timestampTCSP, calculates the complete private key skCSP = (xCSP,pskCSP), and keeps it in PTMP secretly. Finally, the public key pkCSP is shared.


### 3.2.4. Cross-Domain Authentication

(1)
PKI domain ⟶CLC domain cross-domain authentication(1)
UserU randomly selects y∈Zp∗ and uses the private key skU= (xU,pskU) to calculate the key negotiation parameterY′ = gy, randomly select the password value pw, and calculate w  = H1TIDU‖pw. Let m1=request1,IDCSP,TIDU,w,TU,NU,Y′, where request1 is the identity of access request, TU is the timestamp, and NU is the random parameter to keep the freshness of the message. Using the signature algorithm in literature [13], user U randomly selects rm∈Zp∗, calculates M1 = H2m1=M1,ii=1nm∈0,1nm, h1=H1m1‖grm, and £1 = u∏i=1nmuiM1,i, and uses the user’s private key sku to generate the signature of a message m1, (δU′=δU,1′,δU,2′) = g2skuE1g3h1rm,grm. Read certificate CertU and send the authentication request Enrequest1,IDCSP,TIDU,w,TU,NU,Y′,δU′,CertUPKCSP to the cloud service provider CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and perform the following operations:First check whetherrequest1 is an access request; if not, then refuse to accept it; if so, then proceed to the next step.Extract the public keyPKU of U in the certificate CertU and calculate m1=request1,IDCSP,TIDU,w,TU,NU,Y′ to verify whether e=δU,1′,g = eg2,PKUeE1g3h1,δU,2′ is true. If not, the authentication is terminated. If it is true, the authentication of U’s identity is completed. Then check whether user U’s identity exists. If so, go straight to repeat the cross-domain authentication. If it does not exist, check the freshness of timestamp TU and verify whether the start and end time of the certificate are valid. If any of the above steps fails, terminate the access; otherwise, proceed to the next step.Randomly selectNCSP1∈Zp∗, read timestamp TCSP1, and send the message applying for the certificate conversion EnIDCSP,IDCA2,TCSP1,NCSP1,CertUPKCA2 to CA2.(3)
CA2 decrypts the message with its own master key and performs the following operations:Check the freshness of timestampTCSP1 and use the public key of CA1 to verify the validity of CertU. If the verification fails, return the message of failure, or else, perform the next step.Use the resignature keyrk = g2β−α to convert CertU’s signature by CA1 δCA1⟶U = δCA1⟶U,1,δCA1⟶U,2 = g2α£g3hSU,gSU into a signature by KGC δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 = rkδCA1⟶U,1,δCA1⟶U,2 = g2β£g3hSU,gSU. Then, CertU issued by CA1 is converted into CertU1 issued by KGC. The validity period of CertU1 can be set to be very short, and CA2 cannot calculate the private keys of CA1 and KGC through the resignature key; that is, it cannot issue certificates in place of CA1 and KGC.CA2 calculatesH1IDCA2, reads the timestamp TCA, and sends the message EnIDCSP,IDCA2,TCA,NCSP1,H1IDCA2,CertU,CertU1PKKGC to KGC.(4)
KGC take the following steps concerning the message:KGC checks the freshness of the timestampTCA after receiving the message. If the verification fails, the authentication is terminated. If it passes the verification, the signature of CertU1, δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 is verified by KGC’s public key, which means calculating eδKGC⟶U,1,g = −eg2,PKKGCe£g3h,δKGC⟶U,2 and seeing whether it is valid or not. If it is not, the authentication is terminated. If it is valid, CertU1 is a legal certificate, and KGC accepts the certificate CertU and sends the message EnIDCSP,IDCA2,NCSP1,H1IDCA2,CertU,CertU1PKCSP to the CSP.(5)
After receiving the message, the CSP will check whetherNCSP1 in the message is the same as the random parameter in the message applying for transformation. If not, the authentication will be terminated. Otherwise, save TIDU,w,N1,D1,CertU in the authentication list, N1and D1as the number of times and valid time of U repeating cross-domain authentication. Finally, the CSP randomly selects NCSP2, z∈Zp∗ and uses the private key to calculate the key negotiation parameter Z′ = gz, reads the timestamp TCSP2, calculates the signature of IDCSPδCSP′ = H1IDCA2β, sends the response Enrequest1,IDCSP,IDCA2,TIDU,Z′,Y′,TCSP2,NCSP2,NU,PKCSP,H1IDCA2δCSP′PKU to user U, and calculates the session key with U, K = PKUskCSPY′z.(6)
UserU checks whether NU in the response is consistent with the authentication request message sent, checks the freshness of timestamp TCSP2, verifies whether eδCSP′,g = eH1TIDCSP,PKβ is true, calculates whether H1IDCA2 is the same as that in the response message, and terminates the authentication if any step fails. If all hold, save {IDCA2,IDCSP, PKCSP, H1IDCA2} to the authentication list and calculate the session key K = PKCSPskUZ′y. The PKI domain will establish a trusted heterogeneous cross-domain connection with the CLC domain.(2)
CLC domain ⟶ PKI domain cross-domain authenticationWhen a user in the CLC domain sends an access request to a CSP in the PKI domain, the KGC in the CLC domain signs the certificate issued by CA2 and sends it to user U, who then sends it to the CSP as part of the access request. The rest steps are the same as that in the “PKI domain ⟶ CLC domain cross-domain authentication,” so it will not be repeated.


### 3.2.5. Repeated Cross-Domain Authentication

User U and cloud service provider CSP pass the first cross-domain authentication, and the cloud service provider records the user’s identity information in the user registration list. Repeated cross-domain authentication is mainly used to determine whether the number of times of domain crossing and timestamps are within the valid range through the session keys provided by users and cloud service providers, so as to determine whether the repeated cross-domain authentication is successful. Repeated cross-domain authentication no longer requires interaction with the intercloud authentication center, and users and cloud service providers are not required to carry heavy loads of computation. This means the completion of security authentication of the bidirectional cross-domain identity. The repeated cross-domain authentication model is shown in Figure4.(1)
User U reads the timestampTi, selects random parameters Ni, yi∈Zp∗, calculates key negotiation parameter Yi = gyi, enters temporary id TIDU and password pw, calculates w′  = H1TIDU‖pw , and sends the message Enrequesti,IDCSP,TIDU,w,Ti,Ni,Yi, CertUPKCSP to CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and then performs the following operations:Determine whetherrequesti is an access request, check the freshness of the timestamp Ti, query user information in the access user list according to TIDU, and verify whether it is the same as w in the user list. If they are different, terminate authentication and return the information of error to user U.Verify whetherD1 exceeds the time validity, and verify whether N1 exceeds the maximum number of visits. If either of them exceeds its range, then terminate the authentication.If any part of the above verification fails, stop execution or update the access list toN1 = N1+1. The CSP reads timestamp To, selects the random parameters NO, zi∈Zp∗, calculates the session key parameter Zi = gzi, and calculates the session key Ki = PKUskCSPYizi. Finally, it sends the message Enrequesti,To,Ni,No,Zi,YiPKU to U.(3)
UserU checks whether the Ni in the response is consistent with the one in the authentication request sent, checks the freshness of the timestamp To, and terminates authentication if the verification fails. If the above verification is passed, the session key Ki = PKcspskUZiyi is calculated and a trusted heterogeneous cross-domain connection is established between the PKI domain and the CLC domain.Figure 4
Repeated cross-domain authentication model.


## 3.2.1. System Establishment

LetG1 and G2 be cyclic groups of order p, p is a prime number, and g is a generator of G1. Define bilinear mapping e: G1 × G1 ⟶ G2. Select two anticollision hash functions H1:0,1∗⟶0,1nc and H2:0,1∗⟶0,1nm, nm<p, nc<p, and the output of the hash function is a member of Zp∗. Randomly select three elements g1, g2, and u ∈ G1, and randomly select nm elements u1,…,unm; the symbol “||” represents the string connection operator, exposing the system parameter pa = {G1, G2p, g, e, g1, g2, u, uii=1nm,H1,H2}.PKI authentication center (CA1) randomly selectsα∈Zp∗ as the master key of the system and calculates the public key PKCA1 = gα. Key generation center KGC randomly selects β∈Zp∗ as the master key of the system and calculates the public key PKKGC = gβ. The intercloud authentication center (CA2) randomly selects θ∈Zp∗ as the master key of the system and computes the public key PKCA2 = gθ. Finally, the public keys PKCA1, PKKGC, and PKCA2 are published. The public-private key pair for U is {PKU, skU}, and the public-private key pair for CSP is {PKCSP, skCSP}.Intercloud authentication center (CA2) generates resignature keys for domains of different cryptography systems and verifies the legitimacy of the subdomain of the security domain of different cryptography systems, and if it passes the verification, a certificate is issued to it. According to the proxy resignature generation algorithm proposed in literature [16], the resignature key generation process in this paper is as follows: CA2 randomly selects rp∈Zp∗, calculates Rp=grp, and sends to CA1; CA1 calculates Rp1=Rpg2α through its own private key and sends it to KGC; KGC calculates Rp2=g2β/Rp1 through its own private key and returns the result to CA2; CA2 calculates the resignature key rk=RpRp2=g2β−α. Because this paper has more symbols, Table 1 explains the meaning of these symbols.Table 1
Explanation of symbols.
SymbolMeaning of the symbolCLCCertificateless cryptographyPKIPublic key infrastructureUserCloud service providerKGCKey generation center in the CLC domainCertificate authority in the PKI domainCloud certification centerIDUThe true identity of userUIDCSPThe true identity of cloud service provider (CSP)TIDUTemporary identity of userUTIDCSPTemporary identity of cloud service provider (CSP)PKαThe public key of the certificate authority (CA1)PKβThe public key of the key generation center (KGC)PKCAThe public key of the cloud certification center CA2RkThe resignature key of the CA2DNαThe identity of the certificate authority (CA1)DNβThe identity of the key generation center (KGC)DNUThe identity of userUDNCSPThe identity of cloud service provider (CSP)αThe master key of the certificate authority (CA1)βThe master key of the key generation center (KGC)θThe master key of the cloud certification center (CA2)pkUThe public key of userUskUThe private key of userUpkCSPThe public key of the cloud service provider (CSP)pskCSPThe partial private key of the cloud service provider (CSP)skCSPThe private key of the cloud service provider (CSP)δCA1 ⟶UThe CA1’s signature of the user’s certificateCertUA certificate issued by a CA1 to userU


## 3.2.2. Identity Generation

In this scheme, the hierarchical ID tree in literature [32] is adopted to define the ID value in order to realize the uniqueness of identity. As shown in Figure 3, in the 2-tier ID tree, the root node is the identity mark of the CLC key generation center or the authentication center CA of the PKI domain, and the leaf node is the identity mark of the users and cloud service providers in the trusted domain. If the identity of CA1 in the PKI domain is DNα and that of user U is DNU, then the real identity of U is defined as IDU = DNα||DNU. Similarly, the identity of KGC of the CLC domain is DNβ, and the identity of the CSP is DNCSP; then, the real identity of the CSP is defined as IDCSP = DNβ||DNCSP.Figure 3
Hierarchical ID tree.
(a)(b)


## 3.2.3. Key Generation

(1)
User registration of the PKI domain(1)
User U selects a random secret value ofrU. Calculate temporary identity TIDU=H1IDU‖grU according to U’s real identity IDU. Encrypt the registration request EnIDU,IDCA1,TIDU,grU,PKUPKCA1 with CA1’s public key PKβ, and send it to CA1.(2)
CA1 uses its master key to decrypt the received registration message and verify whether U is a legitimate user of local security domain, by verifying user temporary identityTIDU = H1IDU‖grU. If it fails, give a response of failure or else check in the registered user list whether IDU already exists. If so, the certificate is issued directly to U, and if not, CA1 randomly selects SU∈Zp∗, generates the certificate message mCA1⟶U composed of CA1, TIDU, and PKU, computes MCA1⟶U =  H2mCA1⟶U = (MCA1⟶U,1,...MCA1⟶U,nm)∈0,1nm, E1 = u∏i=1nmuiMCA1⟶U,i, and h = H1mCA1⟶U‖gSU and uses CA1’s private key α to generate the signature δCA1⟶U=(δCA1⟶U,1,δCA1⟶U,2) = g2α£g3hSU,gSUof the certificate message mCA1⟶U. CA1 issues to U a certificate CertU = {TIDU,PKU,IDCA1,Tbegin,TendmCA1⟶U,δCA1⟶U}, where Tbegin,Tend is the valid start and end time of the certificate. CA1 saves {IDU,TIDU,grU,PKU} in the list of registered users, stores the certificate to the certificate library, reads the local timestamp TU, and sends the response EnIDU,IDCA1,TU,CertUPKU to U.(3)
User U decrypts the response through its private key and checks freshness of the timestampTU, verifies the validity of certificate CertU with public key PKCA1 of the root certificate CA1, and stores PKU,skU,CertU in PTMP if it is valid; otherwise, the registration fails and the certificate is refused.(2)
User registration of the CLC domain(1)
Cloud service provider CSP selects the random secret valuerCSP, xCSP∈Zp∗ and computes the public key PKCSP = gxCSP. According to the real identity of the cloud service provider (CSP), calculate the temporary identity TIDCSP = H1IDCSP‖grCSP. The message applying for registration is encrypted through the public key of the KGC and EnIDCSP,TIDCSP,grCSP,PKCSPPKKGC is sent to KGC.(2)
After decrypting the encrypted message with its master key, KGC obtains the real identityIDCSP according to DNCSP and verifies whether the temporary identity TIDCSP = H1IDCSP‖grCSP is correct. If not, give the response of failure, or else compute QCSP = H1TIDCSP and the partial private key pskCSP =  QCSPβ. Read the local timestamp TCSP, return the message EnpskCSP,TCSP,QCSPPKCSP to the CSP, and save {IDCSP,TIDCSP,grCSP,PKCSP,TCSP} in the user registration list.(3)
After receiving the message, the CSP uses its own private key to decrypt the message and verify the freshness of the timestampTCSP, calculates the complete private key skCSP = (xCSP,pskCSP), and keeps it in PTMP secretly. Finally, the public key pkCSP is shared.


## 3.2.4. Cross-Domain Authentication

(1)
PKI domain ⟶CLC domain cross-domain authentication(1)
UserU randomly selects y∈Zp∗ and uses the private key skU= (xU,pskU) to calculate the key negotiation parameterY′ = gy, randomly select the password value pw, and calculate w  = H1TIDU‖pw. Let m1=request1,IDCSP,TIDU,w,TU,NU,Y′, where request1 is the identity of access request, TU is the timestamp, and NU is the random parameter to keep the freshness of the message. Using the signature algorithm in literature [13], user U randomly selects rm∈Zp∗, calculates M1 = H2m1=M1,ii=1nm∈0,1nm, h1=H1m1‖grm, and £1 = u∏i=1nmuiM1,i, and uses the user’s private key sku to generate the signature of a message m1, (δU′=δU,1′,δU,2′) = g2skuE1g3h1rm,grm. Read certificate CertU and send the authentication request Enrequest1,IDCSP,TIDU,w,TU,NU,Y′,δU′,CertUPKCSP to the cloud service provider CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and perform the following operations:First check whetherrequest1 is an access request; if not, then refuse to accept it; if so, then proceed to the next step.Extract the public keyPKU of U in the certificate CertU and calculate m1=request1,IDCSP,TIDU,w,TU,NU,Y′ to verify whether e=δU,1′,g = eg2,PKUeE1g3h1,δU,2′ is true. If not, the authentication is terminated. If it is true, the authentication of U’s identity is completed. Then check whether user U’s identity exists. If so, go straight to repeat the cross-domain authentication. If it does not exist, check the freshness of timestamp TU and verify whether the start and end time of the certificate are valid. If any of the above steps fails, terminate the access; otherwise, proceed to the next step.Randomly selectNCSP1∈Zp∗, read timestamp TCSP1, and send the message applying for the certificate conversion EnIDCSP,IDCA2,TCSP1,NCSP1,CertUPKCA2 to CA2.(3)
CA2 decrypts the message with its own master key and performs the following operations:Check the freshness of timestampTCSP1 and use the public key of CA1 to verify the validity of CertU. If the verification fails, return the message of failure, or else, perform the next step.Use the resignature keyrk = g2β−α to convert CertU’s signature by CA1 δCA1⟶U = δCA1⟶U,1,δCA1⟶U,2 = g2α£g3hSU,gSU into a signature by KGC δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 = rkδCA1⟶U,1,δCA1⟶U,2 = g2β£g3hSU,gSU. Then, CertU issued by CA1 is converted into CertU1 issued by KGC. The validity period of CertU1 can be set to be very short, and CA2 cannot calculate the private keys of CA1 and KGC through the resignature key; that is, it cannot issue certificates in place of CA1 and KGC.CA2 calculatesH1IDCA2, reads the timestamp TCA, and sends the message EnIDCSP,IDCA2,TCA,NCSP1,H1IDCA2,CertU,CertU1PKKGC to KGC.(4)
KGC take the following steps concerning the message:KGC checks the freshness of the timestampTCA after receiving the message. If the verification fails, the authentication is terminated. If it passes the verification, the signature of CertU1, δKGC⟶U = δKGC⟶U,1,δKGC⟶U,2 is verified by KGC’s public key, which means calculating eδKGC⟶U,1,g = −eg2,PKKGCe£g3h,δKGC⟶U,2 and seeing whether it is valid or not. If it is not, the authentication is terminated. If it is valid, CertU1 is a legal certificate, and KGC accepts the certificate CertU and sends the message EnIDCSP,IDCA2,NCSP1,H1IDCA2,CertU,CertU1PKCSP to the CSP.(5)
After receiving the message, the CSP will check whetherNCSP1 in the message is the same as the random parameter in the message applying for transformation. If not, the authentication will be terminated. Otherwise, save TIDU,w,N1,D1,CertU in the authentication list, N1and D1as the number of times and valid time of U repeating cross-domain authentication. Finally, the CSP randomly selects NCSP2, z∈Zp∗ and uses the private key to calculate the key negotiation parameter Z′ = gz, reads the timestamp TCSP2, calculates the signature of IDCSPδCSP′ = H1IDCA2β, sends the response Enrequest1,IDCSP,IDCA2,TIDU,Z′,Y′,TCSP2,NCSP2,NU,PKCSP,H1IDCA2δCSP′PKU to user U, and calculates the session key with U, K = PKUskCSPY′z.(6)
UserU checks whether NU in the response is consistent with the authentication request message sent, checks the freshness of timestamp TCSP2, verifies whether eδCSP′,g = eH1TIDCSP,PKβ is true, calculates whether H1IDCA2 is the same as that in the response message, and terminates the authentication if any step fails. If all hold, save {IDCA2,IDCSP, PKCSP, H1IDCA2} to the authentication list and calculate the session key K = PKCSPskUZ′y. The PKI domain will establish a trusted heterogeneous cross-domain connection with the CLC domain.(2)
CLC domain ⟶ PKI domain cross-domain authenticationWhen a user in the CLC domain sends an access request to a CSP in the PKI domain, the KGC in the CLC domain signs the certificate issued by CA2 and sends it to user U, who then sends it to the CSP as part of the access request. The rest steps are the same as that in the “PKI domain ⟶ CLC domain cross-domain authentication,” so it will not be repeated.


## 3.2.5. Repeated Cross-Domain Authentication

User U and cloud service provider CSP pass the first cross-domain authentication, and the cloud service provider records the user’s identity information in the user registration list. Repeated cross-domain authentication is mainly used to determine whether the number of times of domain crossing and timestamps are within the valid range through the session keys provided by users and cloud service providers, so as to determine whether the repeated cross-domain authentication is successful. Repeated cross-domain authentication no longer requires interaction with the intercloud authentication center, and users and cloud service providers are not required to carry heavy loads of computation. This means the completion of security authentication of the bidirectional cross-domain identity. The repeated cross-domain authentication model is shown in Figure4.(1)
User U reads the timestampTi, selects random parameters Ni, yi∈Zp∗, calculates key negotiation parameter Yi = gyi, enters temporary id TIDU and password pw, calculates w′  = H1TIDU‖pw , and sends the message Enrequesti,IDCSP,TIDU,w,Ti,Ni,Yi, CertUPKCSP to CSP.(2)
After receiving the message, the CSP uses its own private key to decrypt the message and then performs the following operations:Determine whetherrequesti is an access request, check the freshness of the timestamp Ti, query user information in the access user list according to TIDU, and verify whether it is the same as w in the user list. If they are different, terminate authentication and return the information of error to user U.Verify whetherD1 exceeds the time validity, and verify whether N1 exceeds the maximum number of visits. If either of them exceeds its range, then terminate the authentication.If any part of the above verification fails, stop execution or update the access list toN1 = N1+1. The CSP reads timestamp To, selects the random parameters NO, zi∈Zp∗, calculates the session key parameter Zi = gzi, and calculates the session key Ki = PKUskCSPYizi. Finally, it sends the message Enrequesti,To,Ni,No,Zi,YiPKU to U.(3)
UserU checks whether the Ni in the response is consistent with the one in the authentication request sent, checks the freshness of the timestamp To, and terminates authentication if the verification fails. If the above verification is passed, the session key Ki = PKcspskUZiyi is calculated and a trusted heterogeneous cross-domain connection is established between the PKI domain and the CLC domain.Figure 4
Repeated cross-domain authentication model.


## 4. Scheme Analysis

### 4.1. Security Analysis

The security of key generation and cross-domain authentication algorithm proposed in this scheme is based on the security of proxy resignature scheme proposed in literature [28], which has been proved. This scheme is based on the CK model proposed in literature [33, 34] to prove the security of cross-domain identity authentication scheme.This scheme describes cross-domain identity authentication as a protocolψ in the AM. The security of the protocol ψ is analyzed under the CK security model. Since the algorithm has been proved to be unforgeable, it is only necessary to prove that the protocol ψ satisfies the two properties of Definition 3, in order to prove that the session key of the protocol ψ is secure in the AM.(1)
Because neither of the message participants of the protocol is compromised by the attacker A in the AM, both userU and the cloud service provider CSP can obtain the key negotiation parameters YU and ZCSP that are not tampered with and calculate and obtain the same session key K, which satisfies the first property of Definition 3 concerning session key security.(2)
Assuming that the attacker A initiatesq rounds of guessing in the AM, there is an Algorithm B which uses the nonnegligible probability ε based on the guessing results of A to correctly distinguish whether the session key of the protocol ψ is a real value or a random value. Randomly select the number of rounds for testing sessions, n ∈ {1, 2, 3, …, q}. In n rounds of session, the input value of B is YU, ZCSP, and K, among which YU is the key negotiation parameter of user U, ZCSP is the key negotiation parameter of the CSP, and K is the response of query. The following 2 situations are discussed:(1)
A is selected in then-th round of sessions. If A can guess whether the response value is real or random with the probability of 1/2+ε, B can also guess whether the input value is real or random with the probability of 1/2+ε, because if the input of B is a real session, the response A is the real value of the session key Y, and if the input is a random value, the response K is a random value.(2)
A is not selected in then-th round of sessions. Choosing another round except the n-th round, B can guess whether the input is a real value or random value with the probability of 1/2. The probability that the tested session is the n-th session is 1/q , and the probability of A guessing correctly the test response is 1/2+ε. The probability that the test session is not the n-th session is 1−1/q , and the probability of A guessing right the test response is 1/2, so the probability of making a successful guess is 1/q1/2+ε+1−1/q1/2. From this, the probability that B guesses the right session key is 1/2+ε/q; that is, the second property of Definition 2 is satisfied, so the session key of the protocol ψ is secure.


### 4.2. Antireplay Attacks

In this scheme, during cross-domain authentication, user U and the cloud service provider CSP randomly select the local timestamp and random parameters which keep the session fresh to ensure the validity of the message. If a malicious attacker intercepts the message and replays it in the cross-domain authentication, the verification conducted by the receiving party will fail, because the freshness of the timestamp of the replayed message is different from that of the original one. As a result, this scheme can effectively resist replay attacks.


### 4.3. Antireplacement Attacks

In this scheme, the real identities of user U and the cloud service provider CSP are replaced by randomly selected secret values as their temporary identitiesTIDU and TIDCSP, and, at the stage of key generation, the KGC signs the temporary identity of user U in CLC domain and the CA signs the user’s certificate in PKI domain, so as to protect user identity. In the cross-domain authentication, w = H2 (TIDU||pw) binds the password and user’s temporary identity and further strengthens the security by the two-factor authentication of “password + key.” If the attacker replaces the user's identity in the message interaction of cross-domain authentication, the authentication will fail at the time when the other party receives the message for authentication. Therefore, this scheme can effectively resist the replacement attack.


### 4.4. Anonymous Tracking of Entity Identity

In order to ensure the identity security of user U and the CSP, the temporary identitiesTIDU and TIDU are established to replace the real identities IDU and IDCSP, so as to realize the anonymity of identity. If an illegal user sends an illegal request to the cloud service provider, the CSP submits TIDU and certificate CertU to the authentication CA2 for verification. After CA2 verifies the validity of CertU, it searches the user registration list {IDU,TIDU,grU,PKU} according to the temporary identity TIDU and verifies whether the temporary identity is TIDU by TIDU  = H1IDU‖grU. If the verification is passed, it means that the user who sends the illegal message is IDU. CA2 will send the result to the CSP. If the user is a user in the CLC domain, TIDU will be sent to the KGC for authentication, and the remaining steps are the same as the above ones. In this way, the scheme can anonymously trace the entity’s identity.


### 4.5. Anti-Man-in-the-Middle Attacks

When user U crosses the domain to access the cloud service provider, user U includes in the message the signature by CA1 on its temporary identity and encrypts the message through the public key of the CSP in the communication. The CSP can decrypt the message only by means of its own private key and then verifies the message, thus ensuring that the identity is real. Man-in-the-middle attacks are resisted.


### 4.6. Simulation Experiment

AVISPA, an automatic formal security verification tool, is used to analyze the security properties of the scheme. AVISPA is a formalized security verification tool widely recognized and used in the industry that analyzes the potential security risks of security protocols at a very fine level of granularity and defines security services in protocols, such as key confidentiality, authentication, and capability against man-in-the-middle attack and replay attack, with great precision. In addition, AVISPA integrates OFMC, Cl-ATSE, SATMC, TA4SP, and other four background model analysis tools. In this scheme, OFMC and Cl-ATSE are selected for mutual verification to ensure the reliability of analysis results. The source code is shown in Figure5.Figure 5
Simulation experiment source code.Figure 6
(a) CL-ATSE analysis engine validation results. (b) OFMC analysis engine validation results.
(a)(b)This scheme uses the HLPSL language built in AVISPA tool to describe the process of the identity authentication scheme in this paper. In the process of identity authentication, public key, multiplication, addition, and logarithm operations are essentially one-way functions, and their inverse operations are difficult to obtain, so we replace these operations with one-way hash functions with the same security properties. In this model, the attacker has complete control over the entire network and can forward, modify, replay, block, and forge any information at any location in the network. Meanwhile, the attacker can also pretend to be a protocol participant and have the same knowledge as the protocol participant but cannot crack the encryption function defined in AVISPA.The experimental model was independently verified by Cl-ATSE and OFMC analysis engines for many times, proving that the scheme in this paper is safe against replay attack, substitution attack, and man-in-the-middle attack. The verification results are shown in Figures6(a) and 6(b), respectively, and the results are all safe.The above is the security analysis of this scheme. Compared with cross-domain schemes in recent years, it can be seen from Table2 that this scheme is superior in ensuring security. “No” means that the literature does not meet the performance, and “Yes” means that the literature meets the performance.Table 2
Security comparison of heterogeneous cross-domain authentication schemes based on proxy resignature.
SchemeAnonymous trackingAnti-man-in-the-middle attackAntireplay attacksAntireplacement attacksTwo-factor authentication[33]YesNoYesYesYes[34]NoNoNoYesNo[35]NoNoYesYesNo[36]NoNoNoYesNo[37]NoYesYesNoNo[38]NoYesYesYesNo[39]NoYesYesYesNoOur schemeYesYesYesYesYesThis scheme uses hierarchical ID tree to define the ID values of users, cloud service providers, and other entities to realize the uniqueness of entity identity. Compared with literature [34–39], this scheme replaces the real identity with the temporary identity, and the KGC or CA1 signs user U’s temporary identity, further enhancing security and meanwhile realizing anonymous tracking. Compared with literature [33–36], the KGC or CA1 in this scheme signs the temporary identity of user U and encrypts the message by the public key of the CSP, which results in better performance in resisting man-in-the-middle attacks. Compared with literature [34, 36], this scheme randomly selects the local timestamp and random parameters for keeping the session fresh to ensure the validity of the message in cross-domain authentication, which realizes the resistance of the replay attack. Compared with literature [37], this scheme can resist the replacement attack by using temporary identities and the two-factor authentication of “password + key,” making itself more secure. Compared with literature [33, 34, 37–39], this scheme realizes cross-domain identity authentication under different cryptographic systems, which better satisfies the needs of contemporary society.


### 4.7. Performance Analysis

On account of the higher computational cost of double linear calculation and exponent operation, compared with multiplication, addition, and hash function, this scheme will be compared with others concerning the computational cost of double linear calculation and exponent operation in the three stages as key generation, the first-time cross-domain authentication, and repeated cross-domain authentication. Pa means the time required for bilinear calculation, and Dex means the time for exponent operation.As shown in Table3, the scheme performs two exponential operations in the process of key generation. The first-time cross-domain authentication needs three-time bilinear calculation and three-time exponent operation. The repeated cross-domain authentication does not require verification of certificate and complex bilinear operation. What is more, the authentication is clearer. Compared with the literature [18, 28, 30, 31, 33], the overall computational efficiency is higher. The computational cost of the first-time cross-domain authentication is close to this scheme and the scheme in literature [30], but the cost of the scheme in literature [30] is much higher in the repeated cross-domain authentication. Compared with literature [33], after receiving the response, user U does not need to send another authentication request to the intercloud authentication center to guarantee the legitimacy of the identity of the CSP, which increases security and reduces the cost. At the same time, this paper does not use the secure channel when requesting access, which increases the reality of the scheme. According to research, this paper is the first one to propose a cross-domain identity authentication scheme based on proxy resignature under the heterogeneous environment.Table 3
Comparison of computational cost of the heterogeneous cross-domain authentication schemes based on proxy resignature.
SchemeKey generationFirst cross-domain authenticationRepeated cross-domain authentication[18]2Dex + 2 Pa5Dex + 3 Pa3Dex[28]Dex + 2 Pa6Dex + Pa3Dex[30]2Dex7Dex7Dex[31]3Dex6Dex3Dex[33]2Dex + 2 Pa3Dex + 4 Pa3DexOur scheme2Dex3Dex + 3 Pa3Dex


## 4.1. Security Analysis

The security of key generation and cross-domain authentication algorithm proposed in this scheme is based on the security of proxy resignature scheme proposed in literature [28], which has been proved. This scheme is based on the CK model proposed in literature [33, 34] to prove the security of cross-domain identity authentication scheme.This scheme describes cross-domain identity authentication as a protocolψ in the AM. The security of the protocol ψ is analyzed under the CK security model. Since the algorithm has been proved to be unforgeable, it is only necessary to prove that the protocol ψ satisfies the two properties of Definition 3, in order to prove that the session key of the protocol ψ is secure in the AM.(1)
Because neither of the message participants of the protocol is compromised by the attacker A in the AM, both userU and the cloud service provider CSP can obtain the key negotiation parameters YU and ZCSP that are not tampered with and calculate and obtain the same session key K, which satisfies the first property of Definition 3 concerning session key security.(2)
Assuming that the attacker A initiatesq rounds of guessing in the AM, there is an Algorithm B which uses the nonnegligible probability ε based on the guessing results of A to correctly distinguish whether the session key of the protocol ψ is a real value or a random value. Randomly select the number of rounds for testing sessions, n ∈ {1, 2, 3, …, q}. In n rounds of session, the input value of B is YU, ZCSP, and K, among which YU is the key negotiation parameter of user U, ZCSP is the key negotiation parameter of the CSP, and K is the response of query. The following 2 situations are discussed:(1)
A is selected in then-th round of sessions. If A can guess whether the response value is real or random with the probability of 1/2+ε, B can also guess whether the input value is real or random with the probability of 1/2+ε, because if the input of B is a real session, the response A is the real value of the session key Y, and if the input is a random value, the response K is a random value.(2)
A is not selected in then-th round of sessions. Choosing another round except the n-th round, B can guess whether the input is a real value or random value with the probability of 1/2. The probability that the tested session is the n-th session is 1/q , and the probability of A guessing correctly the test response is 1/2+ε. The probability that the test session is not the n-th session is 1−1/q , and the probability of A guessing right the test response is 1/2, so the probability of making a successful guess is 1/q1/2+ε+1−1/q1/2. From this, the probability that B guesses the right session key is 1/2+ε/q; that is, the second property of Definition 2 is satisfied, so the session key of the protocol ψ is secure.


## 4.2. Antireplay Attacks

In this scheme, during cross-domain authentication, user U and the cloud service provider CSP randomly select the local timestamp and random parameters which keep the session fresh to ensure the validity of the message. If a malicious attacker intercepts the message and replays it in the cross-domain authentication, the verification conducted by the receiving party will fail, because the freshness of the timestamp of the replayed message is different from that of the original one. As a result, this scheme can effectively resist replay attacks.


## 4.3. Antireplacement Attacks

In this scheme, the real identities of user U and the cloud service provider CSP are replaced by randomly selected secret values as their temporary identitiesTIDU and TIDCSP, and, at the stage of key generation, the KGC signs the temporary identity of user U in CLC domain and the CA signs the user’s certificate in PKI domain, so as to protect user identity. In the cross-domain authentication, w = H2 (TIDU||pw) binds the password and user’s temporary identity and further strengthens the security by the two-factor authentication of “password + key.” If the attacker replaces the user's identity in the message interaction of cross-domain authentication, the authentication will fail at the time when the other party receives the message for authentication. Therefore, this scheme can effectively resist the replacement attack.


## 4.4. Anonymous Tracking of Entity Identity

In order to ensure the identity security of user U and the CSP, the temporary identitiesTIDU and TIDU are established to replace the real identities IDU and IDCSP, so as to realize the anonymity of identity. If an illegal user sends an illegal request to the cloud service provider, the CSP submits TIDU and certificate CertU to the authentication CA2 for verification. After CA2 verifies the validity of CertU, it searches the user registration list {IDU,TIDU,grU,PKU} according to the temporary identity TIDU and verifies whether the temporary identity is TIDU by TIDU  = H1IDU‖grU. If the verification is passed, it means that the user who sends the illegal message is IDU. CA2 will send the result to the CSP. If the user is a user in the CLC domain, TIDU will be sent to the KGC for authentication, and the remaining steps are the same as the above ones. In this way, the scheme can anonymously trace the entity’s identity.


## 4.5. Anti-Man-in-the-Middle Attacks

When user U crosses the domain to access the cloud service provider, user U includes in the message the signature by CA1 on its temporary identity and encrypts the message through the public key of the CSP in the communication. The CSP can decrypt the message only by means of its own private key and then verifies the message, thus ensuring that the identity is real. Man-in-the-middle attacks are resisted.


## 4.6. Simulation Experiment

AVISPA, an automatic formal security verification tool, is used to analyze the security properties of the scheme. AVISPA is a formalized security verification tool widely recognized and used in the industry that analyzes the potential security risks of security protocols at a very fine level of granularity and defines security services in protocols, such as key confidentiality, authentication, and capability against man-in-the-middle attack and replay attack, with great precision. In addition, AVISPA integrates OFMC, Cl-ATSE, SATMC, TA4SP, and other four background model analysis tools. In this scheme, OFMC and Cl-ATSE are selected for mutual verification to ensure the reliability of analysis results. The source code is shown in Figure5.Figure 5
Simulation experiment source code.Figure 6
(a) CL-ATSE analysis engine validation results. (b) OFMC analysis engine validation results.
(a)(b)This scheme uses the HLPSL language built in AVISPA tool to describe the process of the identity authentication scheme in this paper. In the process of identity authentication, public key, multiplication, addition, and logarithm operations are essentially one-way functions, and their inverse operations are difficult to obtain, so we replace these operations with one-way hash functions with the same security properties. In this model, the attacker has complete control over the entire network and can forward, modify, replay, block, and forge any information at any location in the network. Meanwhile, the attacker can also pretend to be a protocol participant and have the same knowledge as the protocol participant but cannot crack the encryption function defined in AVISPA.The experimental model was independently verified by Cl-ATSE and OFMC analysis engines for many times, proving that the scheme in this paper is safe against replay attack, substitution attack, and man-in-the-middle attack. The verification results are shown in Figures6(a) and 6(b), respectively, and the results are all safe.The above is the security analysis of this scheme. Compared with cross-domain schemes in recent years, it can be seen from Table2 that this scheme is superior in ensuring security. “No” means that the literature does not meet the performance, and “Yes” means that the literature meets the performance.Table 2
Security comparison of heterogeneous cross-domain authentication schemes based on proxy resignature.
SchemeAnonymous trackingAnti-man-in-the-middle attackAntireplay attacksAntireplacement attacksTwo-factor authentication[33]YesNoYesYesYes[34]NoNoNoYesNo[35]NoNoYesYesNo[36]NoNoNoYesNo[37]NoYesYesNoNo[38]NoYesYesYesNo[39]NoYesYesYesNoOur schemeYesYesYesYesYesThis scheme uses hierarchical ID tree to define the ID values of users, cloud service providers, and other entities to realize the uniqueness of entity identity. Compared with literature [34–39], this scheme replaces the real identity with the temporary identity, and the KGC or CA1 signs user U’s temporary identity, further enhancing security and meanwhile realizing anonymous tracking. Compared with literature [33–36], the KGC or CA1 in this scheme signs the temporary identity of user U and encrypts the message by the public key of the CSP, which results in better performance in resisting man-in-the-middle attacks. Compared with literature [34, 36], this scheme randomly selects the local timestamp and random parameters for keeping the session fresh to ensure the validity of the message in cross-domain authentication, which realizes the resistance of the replay attack. Compared with literature [37], this scheme can resist the replacement attack by using temporary identities and the two-factor authentication of “password + key,” making itself more secure. Compared with literature [33, 34, 37–39], this scheme realizes cross-domain identity authentication under different cryptographic systems, which better satisfies the needs of contemporary society.


## 4.7. Performance Analysis

On account of the higher computational cost of double linear calculation and exponent operation, compared with multiplication, addition, and hash function, this scheme will be compared with others concerning the computational cost of double linear calculation and exponent operation in the three stages as key generation, the first-time cross-domain authentication, and repeated cross-domain authentication. Pa means the time required for bilinear calculation, and Dex means the time for exponent operation.As shown in Table3, the scheme performs two exponential operations in the process of key generation. The first-time cross-domain authentication needs three-time bilinear calculation and three-time exponent operation. The repeated cross-domain authentication does not require verification of certificate and complex bilinear operation. What is more, the authentication is clearer. Compared with the literature [18, 28, 30, 31, 33], the overall computational efficiency is higher. The computational cost of the first-time cross-domain authentication is close to this scheme and the scheme in literature [30], but the cost of the scheme in literature [30] is much higher in the repeated cross-domain authentication. Compared with literature [33], after receiving the response, user U does not need to send another authentication request to the intercloud authentication center to guarantee the legitimacy of the identity of the CSP, which increases security and reduces the cost. At the same time, this paper does not use the secure channel when requesting access, which increases the reality of the scheme. According to research, this paper is the first one to propose a cross-domain identity authentication scheme based on proxy resignature under the heterogeneous environment.Table 3
Comparison of computational cost of the heterogeneous cross-domain authentication schemes based on proxy resignature.
SchemeKey generationFirst cross-domain authenticationRepeated cross-domain authentication[18]2Dex + 2 Pa5Dex + 3 Pa3Dex[28]Dex + 2 Pa6Dex + Pa3Dex[30]2Dex7Dex7Dex[31]3Dex6Dex3Dex[33]2Dex + 2 Pa3Dex + 4 Pa3DexOur scheme2Dex3Dex + 3 Pa3Dex


## 5. Conclusion

The authentication based on the PKI password system is the most widely used authentication mechanism at present, and the authentication scheme with certificateless password system can effectively solve such problems as the key escrow problem existing in the IBC system, making it more popular. This paper proposes a heterogeneous cross-domain authentication scheme for the PKI cryptosystem and certificateless cryptosystem, which can anonymously track the entity’s identity and effectively resist replay attack, replacement attack, and man-in-the-middle attack. The analysis shows that the heterogeneous cross-domain authentication scheme proposed in this paper has better computing performance and higher security and can effectively meet the current complex requirements for cross-domain access in cloud environment. The next step will be to investigate cross-domain authentication schemes based on lattice or other mathematical problems.



---

*Source: 2078032-2020-11-17.xml*