Authenticated Blind Issuing of Symmetric Keys for Mobile Access Control System without Trusted Parties

Mobile authentication can be used to verify a mobile user’s identity. Normally this is accomplished through the use of logon passwords, but this can raise the secret-key agreement problem between entities. This issue can be resolved by using a publickey cryptosystem, but mobile devices have limited computation ability and battery capacity and a PKI is needed. In this paper, we propose an efficient, non-PKI, authenticated, and blind issued symmetric key protocol for mobile access control systems. An easyto-deploy authentication and authenticated key agreement system is designed such that empowered mobile devices can directly authorize other mobile devices to exchange keys with the server upon authentication using a non-PKI system without trusted parties. Empowered mobile users do not know the key value of the other mobile devices, preventing users from impersonating other individuals. Also, for security considerations, this system can revoke specific keys or keys issued by a specific user.The scheme is secure, efficient, and feasible and can be implemented in existing environments.


Introduction
Authentication enables authorized persons to use specific services.A password authentication scheme to achieve user authentication [1] was first proposed in 1981.Later, several schemes [2][3][4][5][6] were proposed to remedy some of the security weakness in [1] and many password-based authentication schemes [7,8] have since been proposed.Besides authentication, key establishment protocols are an important cryptographic primitive.The first unauthenticated key agreement protocol based on asymmetric cryptographic techniques was proposed by Diffie and Hellman [9,10].
The rapid development of electronic technologies has resulted in various mobile devices which increase the convenience of everyday tasks, and an increasing number of applications for mobile devices are now used on the Internet or in wireless networks, raising the importance of mobile authentication in insecure channels.Many authentication protocols for wireless networks have been proposed.Some of these protocols are used in portable communication systems (PCSs) such as the global system for mobile (GSM) protocol [11], maintain the architecture of GSM (MGSM) protocols [12][13][14][15][16], and public-key system protocols [17][18][19][20].
Generally, mobile authentication [21][22][23][24] can be implemented via traditional public-key cryptography [6,13].However, mobile devices suffer from limited computation and battery capacity.Thus, traditional public-key cryptograph, which requires the computation of modular exponentiation, cannot be widely used in mobile devices.
Compared with other public-key cryptography methods, the elliptic curve cryptosystem (ECC) [4,17,25,26] has significant advantages including smaller key sizes and faster computation, making ECC-based authentication protocols [27,28] more suitable for use in mobile devices.
However, like other public-key cryptography methods, ECC also needs a public key infrastructure (PKI) to maintain certificates for users' public-keys.As the number of users increases, PKI needs a large storage space to store the users' public keys and certificates.
In addition, implementing an authenticated key agreement protocol requires the corresponding party's authenticated public key.For example, for Alice and Bob to execute the NIST recommended MQV key agreement protocol [14,29], Alice needs an authenticated public key PK  from Bob and Bob needs an authenticated public key PK  from Alice.

Mathematical Problems in Engineering
Given the difficulty of deploying a PKI system, easyto-deploy authentication and authenticated key agreement systems are preferable, such as identity-based cryptosystems and key agreement systems.
Sakai et al. [30] proposed an identity ID-based publickey cryptosystem.Unlike traditional certificate-based publickey systems, ID-based public-key cryptosystems do not need to store users' public keys and certificates, thus simplifying certificate management.However, the user's private key must be generated by the Key Generator Center.
On the other hand, several identity-based key agreement protocols [17,[30][31][32][33][34][35][36] have been proposed.Smart [35], Chen and Kudla [32], Sakai et al. [30], Shim [34], and McCullagh and Barreto [17] designed identity-based and authenticated key agreement protocols based on Weil and Tate pairing techniques.However, Chen and Kudla [32] pointed out that Smart's protocol is not secure in several respects.Cheng et al. [26] showed that Chen-Kudla's protocol is not secure against unknown key share attacks.Scott's protocol is not secure against man-in-the-middle attacks.Sun and Hsieh [37] pointed out that Shim's protocol is insecure against key compromise impersonation attacks or man in the middle attacks.Choo [38] showed that McCullagh and Barreto's protocol is insecure against key revealing attacks.Although McCullagh and Barreto [17] revised their protocol, the revised protocol does not achieve the weak perfect forward secrecy property.Therefore, most identity-based key agreement protocols are impractical or fail to meet all required security properties.
Wang and Zhao [39] proposed an enhanced key agreement protocol based on the semigroup property of the Chebyshev chaotic map.Their method is similar to the Diffie-Hellman algorithm.Compared with other key agreement protocols based on chaos [40][41][42][43][44] their method provides not only mutual authentication but also security resistance to replay attacks, man-in-the-middle attacks, and Bergamo et al. 's attack [45].Later, Niu and Wang [46] proposed an anonymous key agreement protocol based on chaotic maps to improve the security of Tseng et al. 's protocol [47].
In 2010, Sun and Hsieh [37] present a client authentication and key exchange protocol using bilinear pairings for mobile client-server environments.Although both mutual authentication and key exchange are provided, the relative computation cost of pairing is approximately 20 times higher than that of the scalar multiplication [13].Therefore it is not sufficiently efficient for mobile client server environments.
Haist and Osten [48] proposed a secure key distribution method using classical light.Between communicating parties, this method relies on interferometric measurements of white light (by one of the parties) and the random choice of delays (by the others).Their system requires a third party, and all the communicating parties must ensure their devices are appropriately equipped and that measurements are conducted at a particular time and place.In 2012, Álvarez-Bermejo et al. [49] proposed a key multicasting protocol based on the use of orthogonal systems in vector spaces.Their protocol helps a server facing a huge number of users to exchange a small number of messages.
This paper describes the design of an easy-to-deploy authentication and authenticated key agreement system such that empowered mobile devices can directly authorize other mobile devices to exchange authenticated keys with the server using a non-PKI system.We discuss the problem of key reproducing, which means a new authenticated key can be directly generated from another empowered key.New authenticated keys should be different from the empowered key to prevent spoofing.
We address the problem of mobile access key issuing (key reproduction) from other mobile keys for role-based access control models, which is essential in the daily authenticating environment.For example, mobile device can be used to unlock electronic door locks or to access computers.A homeowner can directly issue an access key to his parents, friends, or guests.An empowered mobile device   can reproduce new authenticated keys to other devices   or   so that (1)   and   can pass system verification, (2) the system can precisely identify who (  ,   , or   ) is accessing the system, and (3) the key issuer  does not know the values of the keys issued to   or   .Our scheme provides a secure key-reproducing method which does not require a third party.
We design a master key and a visitor key.A master key owner is empowered to issue keys to another user, where the issued key can be a master key or a visitor key.The newly issued master key is permitted to issue other keys while a visitor key is not.For authentication purpose, the system database keeps some authentication data.Specifically, we provide a storagefree choice for visitor keys, such that the authentication data of the visitor keys do not have to be stored in the system database.For security considerations, this system can revoke specific keys or keys issued by a specific person.
The contributions of the proposed system are as follows.The proposed system (1) authorizes mobile devices to directly exchange authenticated keys with the server from empowered mobile devices; (2) ensures key issuers are blind to the secret keys provided to key requesters; (3) reduces requirements for trusted parties; (4) reduces requirements for public-key cryptography or public-key infrastructure (PKI); (5) provides confidentiality of key values among mobile devices; (6) allows for the revocation of specific keys or keys issued by a specific user; (7) provides a storage-free choice to reduce database storage requirements; (8) reduces vulnerability to replay attacks and man-inthe-middle attacks; The rest of this paper is organized as follows.In Section 2, we provide a technical description of the proposed protocol including notations, model, protocol goals, and security requirements.The construction details of the proposed protocol are presented in Section 3. Security, efficiency, correctness analysis, and property comparison for the proposed protocol are given in Section 4 and we draw conclusions in Section 5.

Preliminaries
Our scheme assumes two grades of keys, a master key (MK) and a visitor key (VK).We also assume there are two rules, a key owner and a key verifier.A key owner possesses either MK or VK, which passes the authentication of key verifiers.
A key verifier is a guard system (such as electronic door locks or computers) that owns its database.Each MK or VK has a validity time.Only MK is authorized to generate another new MK or VK for other users.
For a general scenario, we define three roles: administrator (⟨A⟩), super user (⟨S⟩), and normal user (⟨U⟩).We assume both the administrator and the super users have MK and the normal users hold VK.Although all key owners have their own validity times, the validity time of the administrator is designed to never expire.Furthermore, we design a short-term visitor key authentication (SVA) which is used for rarely used VKs.This reduces system storage space requirements because the VKs' data is not stored in the system database.

Notations, Model, and Protocol Goals.
In this section we first list notations, our model, and our protocol goals.The notations are shown in Table 1.The model and the protocol goals are shown in Table 2.The scheme has two rules, key owners and key verifier (i.e., the guard system).Key owners can be administrator (⟨A⟩), super user (⟨S⟩), and normal user (⟨U⟩).The key grades of (⟨A⟩) and (⟨S⟩) are MK and the key grade of ⟨U⟩ is VK.Each user U  in any status ⟨A⟩, ⟨S⟩, and ⟨U⟩ has a validity time VT U  .The guard system G  is a key verifier (or access control) system and its status is ⟨G⟩.The guard system verifies the validity and validity times of keys, and store the related data of key owners in its database.
Our protocol goals are (1) only MKs are permitted to issue (generate) other new MKs or VKs; (2) the key issuers (generators) do not know the values of their issued (generated) keys; (3) only legitimate MK and VK can pass the verification of the guard system; (4) G can precisely identify who is accessing the system; (5) short-term visitor key authentication (SVA) (i.e., a storage-free choice) eliminates the need for system storage space; (6) keys can be revoked and keys generated from one specified user can be revoked; (7) PKI or public-key cryptosystem is not required; (8) authentication is efficient for users; (9) the system provides replay attack resistance; and (10) the system provides manin-the-middle attack resistance.Of course, the first item can be designed arbitrarily.(1) Authentication.Guard can authenticate users.
(2) Confidentiality of key values.Users can only obtain their own keys and have no access to any information about others.
(3) Replay attack resistance.An adversary (or the originator) who intercepts or eavesdrops the data and retransmits it is prevented from successfully obtaining private information or posing as a party running an authentication protocol.
(4) MITM attack resistance.An adversary who intercepts the data between the Guards and users, makes independent connections with them, and relays messages between them is prevented from successfully making the guards and users believe that they are talking directly to each other.

The Proposed Scheme
In our protocol, there are two basic roles, key owner and key verifier, where key owners have their key storage space and key verifiers have their own database.where key status will be explained later.Table 4 shows the possible database contents of a guard system G  .From the table, we can see user status, user identity, user access key, the key's validity time, and the issuers of user access key.We will show how to establish the data from our protocol later.Our protocols can be separated into seven phases, (1) initialization, (2) authentication, (3) key generation, (4) registration, (5) short-term visitor key authentication (SVA), (6) key revocation, and (7) scheme designs.Aside from registration in the initialization phase, which is assumed to take place in a secure environment, all entities are communicated through insecure channels.(The assumption is reasonable in that users apply and register digital certificates personally in banks or local registration offices).

Initialization.
Basically, each guard system G matches at least one administrator A. Therefore, for each guard system, an administrator must execute an initialization phase to switch on a new guard system.
We assume the administrator A and guard system G share a secret key K AG after the initialization phase.A validity time VT A is also recorded in the data base of G along with the storage space (memory or hard disc) of A. Normally, an administrator's VT A is recorded as "never expired." There are many methods for exchanging a secret key K AG between A and G.For example, the A can choose a secret key K AG , encrypt it using G's public key, and send the encrypted secret key to G.Alternatively, A and G may use key exchange protocols to share an exchanged key.Here, we use the Diffie-Hellman key exchange protocol as a simple example.
In our scheme, we assume A and G exchange secret key K AG in a secure offline environment, such as through encrypted Wi-Fi Direct [50], Bluetooth [51,52] or Infrared Data Association (IrDA) [53].As shown in Figure 1, A chooses a random number  A , prime  and then sends   A , , its identity ID A , and initialization request "Ini"  to G. Next, G chooses a random number   A , stores the information ⟨A⟩||ID A ||K AG ||VT A ||00 in its database, and sends a response "IniRes" to A, where "||" means concatenation and K AG =      A mod .A stores the information ⟨A⟩||ID G ||K AG ||VT A ||00||ok in its database and finishes this phase.

Authentication.
There are two grades of authentication key, master key (MK) and visitor key (VK).The key owners use their keys to pass the guard system's verification via the authentication phase.Since a key owner and a guard system should have shared a secret key, they can use message authentication methods to authenticate each other.There are many message authentication methods, but three-way challenge-response authentication is used here.
Take administrator A, for example (as shown in Figure 2).A key owner first sends its identity (ID A ) and a request "Auth" to a guard system G. Next, G checks whether VT A is valid.If it is not, G sends the message "Key expired" and terminates this phase.Else, G chooses a random number  and sends  and its identity ID G to A.  After receiving ID G and , A computes V =  K AG () and sends V to G. To verify whether V is a valid authentication value, G checks whether the equation V =  K AG () holds.If it does not hold, G sends the message "The authentication is invalid" and terminates the phase.Otherwise, G takes A as a legitimate user and lets A pass the verification.That is, we assume the key requester and key issuer run the key generation phase in a secure environment, such as via encrypted Wi-Fi Direct, Bluetooth, or IrDA.Otherwise, a basic authentication for communicated messages is advised.

MK Generation.
In the phase, assume a new super user S  requests the administrator A for a new key which is in grade MK and is used in guard system G.As shown in Figure 3, S  first chooses a random number  S  and computes  S  =   S  mod .Then S  sends  S  , its identity ID S  , the guard system's identity ID G , and MK generation request "MKGen" to A.

Registration.
After finishing the key generation phase, each new MK or VK requester gets a pseudo key, which is invalid and unusable.He or she has to run the registration phase to produce a real and valid key.The guard system can then store the real key in its database.

MK Registration.
In this phase, assume a super user S  wants to register a generated pseudo key to a guard system G.As shown in Figure 5, S  sends EMK S  , ID S  , VT S  , the key issuer ID A , and the registration request "MKRgst" to G. Next, G checks whether the status of ID A is in status ⟨A⟩ or ⟨S⟩ and is thus permitted to issue keys.If it is not, G sends the message "the key issuer is illegal" and terminates this phase.Otherwise, G computes   U  mod , replaces  U  to K U  , alters EMK U  to "ok, " and finishes this phase.

Short-Term
Visitor Key Authentication (SVA).We propose short-term visitor key authentication (SVA), which is used for rarely or briefly used VKs.SVA does not have to execute the registration phase, followed by authentication.Rather, it can directly proceed the SVA phase to pass the guard system's verification using the generated pseudo key.Although its authentication time takes a little longer, it does not require storing any data about the VK owner in the guard system's database.SVA combines the registration and authentication phases.Assume a normal user U  wants to proceed SVA to a guard system G.As shown in Figure 7, U  sends EVK U  , ID U  , VT U  , the key issuer ID S  , and "SVA" to G. Next, G checks the legal status of the key issuer  3.6.Key Revocation.For a variety of reasons, individual keys, or all keys directly or indirectly generated by a particular, sometimes need to be revoked.For example, assume a super user  generates a key for a super user , and  generates a key for a normal user .If 's key is compromised, we should revoke the keys of both  and  for possible dissimulations.To achieve this goal, all the issued keys can be figured in a tree (or directed graph) structure.Put the administrator on the root vertex, the key generator on the parent vertex, and the key requester on the child vertex.Create a (directed) edge from a parent  to a child V when  generates a key for V.When we revoke the key of one user in a parent vertex, we should also revoke all the keys of users in its child vertexes.

Scheme Designs.
Aside from the designed model shown in Table 2, the proposed scheme can also be used to design other models.For example, as shown in Table 5, we can design four different statuses (administrator, super user, power user, and normal user) with different key grades and issued-key grades.In registration phase, guard systems can judge the ability of key generators according to their statuses or levels.Therefore, the database of guard system may look like the list in Table 6.

Analysis of Proposed Scheme
4.1.Security Analysis.We analyze the security of our protocols according to the requirements defined in Section 2.2 as follows.
Authentication.In the Authentication phase, take A, for example (as shown in Figure 2).G can authenticate A from his response V since  is a random number chosen from G and is hashed via the secret key K AG between A and G, where V =  K AG ().In the Registration phase, take S  , for example (as shown in Figure 5 7, VK key owners, who run SVA, do not run the Registration phase.Therefore, G does not need to store data related to VK key owners in its database. (6) Keys can be revoked and keys generated by one specified user can be revoked.From Section 3.6, we present a tree-structure method of key revocation allowing for the revocation of individual keys and keys generated by a specified user.
(7) PKI or public-key cryptosystem is not required.As we mentioned in Section 1, traditional public-key cryptograph, which requires the computation of modular exponentiation, cannot be broadly used in mobile devices.The proposed system only uses a symmetric key cryptosystem, thus obviating the need for PKI or public-key cryptosystems.
(8) Authentication is efficient for users.As shown in Tables 10 and 11, in our proposed system the computational cost of a user is just   , which means a user only has to run an MAC algorithm to complete authentication.In addition, the total communication cost is about 44 bytes and 312 bytes, respectively, for general authentication and SVA.Therefore, the authentication is efficient for users.
(9) The system provides replay attack resistance.In the Authentication phase, G poses a challenge using a random , which is different in each authentication instance.Key owners then use their secret keys to compute the MAC value of .This change and response method provides replay attack resistance.(10) The system provides man-in-the-middle attack resistance.We assume the Key generation and Registration phases are run at different times, and in different places and environments.Consequently, an attacker can not simultaneously obtain or forge  S  (or  U  ) and   S  (or   U  ).Therefore, the system provides man-in-the-middle attack resistance.Moreover, for security considerations, the Key generation phase should be run face-to-face or provide authenticated messages, thus protecting  S  (or  U  ) from attack.Even if an attacker can simultaneously forge them, the key requester will eventually fail to verify G and become aware of the attacks.

Property Comparison.
The properties of the proposed protocol are compared with those of the Wang-Zhao protocol [39] and Niu-Wang protocol [46] in Table 13, where "Empowered issuing" and "Specific-key revocation", respectively, denote keys issued by empowered entities and the ability to revoke specific keys or keys issued by a specific user.( * 1) indicates that the agreed key is blind to TTP but is not really a "key issuing" action.Their protocols require TTP and the three entities are needed to simultaneously performs key agreement protocols.Our protocol, however, does not need TTP and independent key generation (in the key generation phase) can be independently performed between two mobile entities.That is, our protocol perform the key generation phase (between the key issuer and key requesters) and key registration phase (between the key requesters and guard system) independently, while other protocols perform key agreement among two entities and TTP simultaneously.Therefore, in our protocol, key requesters may perform the key generation phase with key issuer and then perform the key registration phase with a guard system later at another time.In contrast with the other protocols, the proposed protocol is more efficient and effective in the blind issuing of symmetric keys for mobile systems.

Conclusion
In the real world, a new key can be reproduced from any old key.We adapt and improve this concept in the mobile electrical world.In our scheme, the value of the old key is irrelevant to the new key, and the old and new key users are unaware of each other's key values, thus achieving secure identification.Key revocation in a tree structure also increases system security.The system is efficient and feasible and can be used in mobile access systems.

Table 1 :
Notations.Encryption of message  using symmetric key    () Decryption of message  using symmetric key    () Hash value of message  using hash function  and key  || Bit length of message

Table 2 :
The models and protocol goals.
2.2.Security Requirements.The security requirements of our proposed protocol are as follows.

Table 3
shows the possible contents in a key owner's storage space.From the table, we can see that the key owner has three different statuses A, S, and U for different guard systems G 1 , G 2 , G 3 , and G 4 .He or she uses different keys K U 1 , K U 2 , K U 3 , and K U 4 , respectively, for guard systems G 1 , G 2 , G 3 , and G 4 .In addition, the various guard systems have different validity times, issuers, and key status, ID   , ID  , w   Compute = E   (ℳ   ) ID  ‖ r   ‖ VT   ‖ ID  ‖ EMK   EMK   EMK   , VT Generation.Except for the current administrator in ⟨A⟩, who shares a secret key with the guard system, a new super user in status ⟨S⟩ may request a new key in grade MK. (Other new administrators in status ⟨A⟩ may need to do the same thing.)Also, a new normal user in status ⟨U⟩ may request a new key in grade VK.He can ask a MK owner to generate a new key for him.This key generation phase lets an authentication key in grade MK generate a new key in grade MK or VK.For security considerations, this phase should be carried out face-to-face via mobile devices.
Next, A computes EMK S  =  K AG (MK S  ) and then sends EMK S  and its validity time value VT S  to S  , where MK S  = ⟨S⟩||ID S  || S  ||VT S  ||ID A || S  and  S  is a time stamp.After receiving EMK S  and VT S  , S  stores the information ⟨S⟩||ID G || S  ||VT S  ||ID A ||EMK S  in its storage space and finishes this phase.3.3.2.VK Generation.VK generation lets a valid key in grade MK generate a new key in the grade VK.The steps are similar to those in MK generation.Assume a new normal user U  requests super user S  to provide a new key which is in grade VK and is used in guard system G.As shown in Figure 4, U  chooses a random number  U  , computes  U  =   U  mod , and sends  U  , ID U  , ID G , and ID   , ID  , w   ID   ‖ w   ‖ VT   ‖ ID   ‖ T   ) Store ⟨⟩ ‖ ID  ‖ r   ‖ VT    .Then, S  computes EMK U  =  K S  (VK U  ) and sends EMK U  and  U  to U  , where VK U  = ⟨U⟩||ID U  || U  ||VT U  ||ID S  || U  .After receiving EVK U  and VT U  , U  stores ⟨U⟩||ID G || U  ||VT U  ||ID S  ||EMK U  in its storage space and finishes this phase.
"VKGen" to S S  =  K AG (EMK S  ) and verifies time stamp  S  .If  S  is inappropriate, G sends the message "the time stamp is inappropriate" and terminates this phase.Otherwise, G checks whether ID S  , VT S  , and ID A match the values in   S  .If they are not, G sends the message "Data inconsistent" and terminates this phase.If they are, G chooses   S  , computes   S  =    S  mod  and K S  =  S    S  mod , and stores the information ⟨S⟩||ID S  ||K S  ||VT S  ||ID A in its database.Then G sends the command "ok" and   S  back to S  .After receiving them, S  computes K S  =   S   S  mod , changes  S  to K S  , alters the value EMK S  to "ok", and finishes this phase.Following this phase, K S  is a valid MK. S  can use K S  to authenticate itself to guard system G via authentication phase.3.4.2.VK Registration.VK registration is similar to MK registration.Assume a normal user U  registers a generated pseudo key to a guard system G.As shown in Figure 6, U  sends EVK U  , ID U  , VT U  , the key issuer ID S  , and "VKRgst" to G. Next, G checks whether the status of ID S  is in status ⟨A⟩ or ⟨S⟩.G computes VK  U  =  K S  (EVK U  ) MKRgst", ID   , VT   , ID  , EMK   (1) T   legal (2) ID   , VT   , ID  ∈ MK  Replace r   as    Replace EMK   as "ok" Store ⟨⟩ ‖ ID   ‖    ‖ VT   ‖ ID  Figure 5: Registration (master key).and verifies  U  .G checks whether ID U  , VT U  , and ID S  match the values in VK  U  .G chooses   U  , computes   U  =    U  mod  and K U  =  U    U  mod , and stores ⟨U⟩||ID U  ||K U  ||VT U  ||ID S  in its database.Then G sends the command "ok" and   U  to U  .Then, U  computes K U  = " and verifies  U  .G then checks whether ID U  , VT U  , and ID S  match the values in VK  U  .Later, G chooses a random number   , computes   =    mod , and sends   and ID G to U  .U  then computes V =  ID   , VT   , ID   ∈ VK  Replace r   as    Store ⟨⟩ ‖ ID   ‖    ‖ VT   ‖ ID   ID   , VT   , ID   ∈ VK U  mod  and sends V to G. G then checks whether the equation V =  U    mod  holds.If all the verifications above are legitimate, U  passes to the SVA verification.
). G can authenticate S  from EMK S  since G computes MK  S  =  K AG (EMK S  ), verifies  S  , and checks whether ID S  , VT S  , and ID A match the values in MK  S  .Confidentiality of Key Values.Take S  , for example (as shown in Figures 3 and 5).The secret key K S  between S  and G is confidential because  S  and   S  are chosen by S  and G, and an adversary (or A) cannot evaluate K S  from  S  and   S  , where  S  =   S  mod ,   S  =    S  mod , and K S  =    mod .Therefore, the key values between the users and G are kept private.the user's storage costs before and after registration are quite different.In SVA scheme, since users do not have to run the registration phase, the user's space costs in SVA and in general scheme (before registration) are the same.4.3.Protocol Correctness.We analyze the correctness of our protocols according to the goals stated in Section 2.1.(1) Only MKs are permitted to issue (generate) other new MKs or VKs.In the Registration phase, G checks whether the key issuer is in status ⟨A⟩ or ⟨S⟩.Also, G uses the secret key, shared with the key issuer, to decrypt the message EMK and checks the correctness of key issuer's ID, key requester's ID, and validity time.Therefore, only MKs are permitted to issue (generate) other new keys.(2) The key issuers (generators) do not know the values of their issued (generated) keys.In the Key generation phase, user S  (or U  ) chooses a random number  S  (or  U  ), computes  S  =   S  mod  (or  U  =   U  mod ), and sends it to key issuer.The key issuer then encrypts  S  (or  U  ) into EMK S  (or EMK U  ) and sends it to the key requester.Then, in the Registration phase, the key requester sends it to G. G then uses  S  (or  U  ) to make a Diffie-Hellman key exchange indirectly and authentically and exchange a secret key K S  (or K U  ).Therefore, key issuers do not know the values of their issued keys.(3) Only legitimate MK and VK can pass the guard system verification.After running the Registration phase, the legitimate MK or VK key owner can pass the verification of G by running the Authentication phase.(VK key owner can choose to run SVA directly without running the G can use the IDs and secret keys stored in its database to identify who is accessing the system.In SVA mode, G can use the IDs and secret keys of key issuers to determine user identities.(5)Short-term visitor key authentication (SVA) (i.e., a storage-free choice) frees up system storage space.As shown in Figure

Table 13 :
Comparison of properties.