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

Authors: Shin-Yan Chiou
Journal: Mathematical Problems in Engineering
 (2013)

---

## Abstract

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 public-key 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 easy-to-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.


---

## Body

## 1. 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–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–16], and public-key system protocols [17–20].Generally, mobile authentication [21–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 PKB from Bob and Bob needs an authenticated public key PKA from Alice.Given the difficulty of deploying a PKI system, easy-to-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 public-key cryptosystem. Unlike traditional certificate-based public-key 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–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–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 ofkey 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 deviceDA can reproduce new authenticated keys to other devices DF or DU so that (1)  DF and DU can pass system verification, (2) the system can precisely identify who (DA, DF, or DU) is accessing the system, and (3) the key issuer A does not know the values of the keys issued to DF or DU. Our scheme provides a secure key-reproducing method which does not require a third party.We design amaster 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 storage-free 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 astorage-free choice to reduce database storage requirements;(8)
reduces vulnerability to replay attacks and man-in-the-middle attacks;(9)
can be implemented in existing environments.The rest of this paper is organized as follows. In Section2, 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.


## 2. Preliminaries

Our scheme assumes two grades of keys, amaster key (ℳ𝒦) and a visitor key (𝒱𝒦). We also assume there are two rules, a key owner and a key verifier. A key owner possesses either ℳ𝒦 or 𝒱𝒦, 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 ℳ𝒦 or 𝒱𝒦 has a validity time. Only ℳ𝒦 is authorized to generate another new ℳ𝒦 or 𝒱𝒦 for other users.For a general scenario, we define three roles:administrator (〈𝒜〉), super user (〈𝒮〉), and normal user(〈𝒰〉). We assume both the administrator and the super users have ℳ𝒦 and the normal users hold 𝒱𝒦. 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 𝒱𝒦s. This reduces system storage space requirements because the 𝒱𝒦s’ data is not stored in the system database.


### 2.1. Notations, Model, and Protocol Goals

In this section we first list notations, our model, and our protocol goals. The notations are shown in Table1. 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 (〈𝒜〉), super user (〈𝒮〉), and normal user (〈𝒰〉). The key grades of (〈𝒜〉) and (〈𝒮〉) are ℳ𝒦 and the key grade of 〈𝒰〉 is 𝒱𝒦. Each user 𝒰i in any status 〈𝒜〉, 〈𝒮〉, and 〈𝒰〉 has a validity time VT𝒰i. The guard system 𝒢j is a key verifier (or access control) system and its status is 〈𝒢〉. The guard system verifies the validity and validity times of keys, and store the related data of key owners in its database.Table 1
Notations.
Notation
Meaning
〈
𝒜
〉
Administrator status
〈
𝒮
〉
Super user status
〈
𝒰
〉
Normal user status
〈
𝒢
〉
Guard system status
ℳ
𝒦
Master grade authentication key
𝒱
𝒦
Visitor grade authentication key
ID
U
Entity identityU
T
U
Time stamp used for an entityU
VT
U
Validity time of an entityU
E
k
(
x
)
Encryption of messagex using symmetric key k
D
k
(
x
)
Decryption of messagex using symmetric key k
H
k
(
x
)
Hash value of messagex using hash function H and key k
|
x
|
Bit length of messagexTable 2
The models and protocol goals.
Status
Key grade
Issued-key grade
〈
𝒜
〉
ℳ
𝒦
ℳ
𝒦, 𝒱𝒦
〈
𝒮
〉
ℳ
𝒦
ℳ
𝒦, 𝒱𝒦
〈
𝒰
〉
𝒱
𝒦
noneOur protocol goals are(1) only ℳ𝒦s are permitted to issue (generate) other new ℳ𝒦s or 𝒱𝒦s; (2) the key issuers (generators) do not know the values of their issued (generated) keys; (3) only legitimate ℳ𝒦 and 𝒱𝒦 can pass the verification of the guard system; (4)𝒢 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 man-in-the-middle attack resistance. Of course, the first item can be designed arbitrarily.


### 2.2. Security Requirements

The security requirements of our proposed protocol are as follows.(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.


## 2.1. Notations, Model, and Protocol Goals

In this section we first list notations, our model, and our protocol goals. The notations are shown in Table1. 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 (〈𝒜〉), super user (〈𝒮〉), and normal user (〈𝒰〉). The key grades of (〈𝒜〉) and (〈𝒮〉) are ℳ𝒦 and the key grade of 〈𝒰〉 is 𝒱𝒦. Each user 𝒰i in any status 〈𝒜〉, 〈𝒮〉, and 〈𝒰〉 has a validity time VT𝒰i. The guard system 𝒢j is a key verifier (or access control) system and its status is 〈𝒢〉. The guard system verifies the validity and validity times of keys, and store the related data of key owners in its database.Table 1
Notations.
Notation
Meaning
〈
𝒜
〉
Administrator status
〈
𝒮
〉
Super user status
〈
𝒰
〉
Normal user status
〈
𝒢
〉
Guard system status
ℳ
𝒦
Master grade authentication key
𝒱
𝒦
Visitor grade authentication key
ID
U
Entity identityU
T
U
Time stamp used for an entityU
VT
U
Validity time of an entityU
E
k
(
x
)
Encryption of messagex using symmetric key k
D
k
(
x
)
Decryption of messagex using symmetric key k
H
k
(
x
)
Hash value of messagex using hash function H and key k
|
x
|
Bit length of messagexTable 2
The models and protocol goals.
Status
Key grade
Issued-key grade
〈
𝒜
〉
ℳ
𝒦
ℳ
𝒦, 𝒱𝒦
〈
𝒮
〉
ℳ
𝒦
ℳ
𝒦, 𝒱𝒦
〈
𝒰
〉
𝒱
𝒦
noneOur protocol goals are(1) only ℳ𝒦s are permitted to issue (generate) other new ℳ𝒦s or 𝒱𝒦s; (2) the key issuers (generators) do not know the values of their issued (generated) keys; (3) only legitimate ℳ𝒦 and 𝒱𝒦 can pass the verification of the guard system; (4)𝒢 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 man-in-the-middle attack resistance. Of course, the first item can be designed arbitrarily.


## 2.2. Security Requirements

The security requirements of our proposed protocol are as follows.(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.


## 3. 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. 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 𝒜, 𝒮, and 𝒰 for different guard systems 𝒢1, 𝒢2, 𝒢3, and 𝒢4. He or she uses different keys 𝒦𝒰1, 𝒦𝒰2, 𝒦𝒰3, and 𝒦𝒰4, respectively, for guard systems 𝒢1, 𝒢2, 𝒢3, and 𝒢4. In addition, the various guard systems have different validity times, issuers, and key status, where key status will be explained later.Table 3
Possible storage of a key owner𝒰i.
Status
Guard system
Key
Valid time
Issuer
Key status
〈
𝒜
〉
I
D
𝒢
1
𝒦
𝒰
1
VT
𝒰
1
N/A
ok
〈
𝒮
〉
ID
𝒢
2
𝒦
𝒰
2
VT
𝒰
2
ID
𝒰
1
ok
〈
𝒰
〉
ID
𝒢
3
𝒦
𝒰
3
VT
𝒰
3
ID
𝒰
1
EMK
𝒰
3
〈
𝒰
〉
ID
𝒢
4
𝒦
𝒰
4
VT
𝒰
4
ID
𝒰
2
okTable4 shows the possible database contents of a guard system 𝒢j. 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).Table 4
Possible database contents of a Guard𝒢j.
Status
User ID
Key
Valid time
Issuer
〈
𝒜
〉
ID
𝒰
1
𝒦
𝒜
𝒢
VT
𝒰
1
00
〈
𝒮
〉
ID
𝒰
2
𝒦
𝒰
2
VT
𝒰
2
ID
𝒰
1
〈
𝒮
〉
ID
𝒰
3
𝒦
𝒰
3
VT
𝒰
3
ID
𝒰
2
〈
𝒰
〉
ID
𝒰
4
𝒦
𝒰
4
VT
𝒰
4
ID
𝒰
1
〈
𝒰
〉
ID
𝒰
5
𝒦
𝒰
5
VT
𝒰
5
ID
𝒰
2
〈
𝒰
〉
ID
𝒰
6
𝒦
𝒰
6
VT
𝒰
6
ID
𝒰
3


### 3.1. Initialization

Basically, each guard system𝒢 matches at least one administrator 𝒜. Therefore, for each guard system, an administrator must execute an initialization phase to switch on a new guard system.We assume the administrator𝒜 and guard system 𝒢 share a secret key 𝒦𝒜𝒢 after the initialization phase. A validity time VT𝒜 is also recorded in the data base of 𝒢 along with the storage space (memory or hard disc) of 𝒜. Normally, an administrator’s VT𝒜 is recorded as “never expired.”There are many methods for exchanging a secret key𝒦𝒜𝒢 between 𝒜 and 𝒢. For example, the 𝒜 can choose a secret key 𝒦𝒜𝒢, encrypt it using 𝒢’s public key, and send the encrypted secret key to 𝒢. Alternatively, 𝒜 and 𝒢 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𝒜 and 𝒢 exchange secret key 𝒦𝒜𝒢 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, 𝒜 chooses a random number r𝒜, prime p and then sends gr𝒜, p, its identity ID𝒜, and initialization request “Ini” to 𝒢. Next, 𝒢 chooses a random number r′𝒜, stores the information 〈𝒜〉||ID𝒜||𝒦𝒜𝒢||VT𝒜||00 in its database, and sends a response “IniRes” to 𝒜, where “||” means concatenation and 𝒦𝒜𝒢=grAr′𝒜 mod p. A stores the information 〈𝒜〉||ID𝒢||𝒦𝒜𝒢||VT𝒜||00||ok in its database and finishes this phase.Figure 1
Initialization (under a secure environment).


### 3.2. Authentication

There are two grades of authentication key,master key (ℳ𝒦) and visitor key (𝒱𝒦). 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𝒜, for example (as shown in Figure 2). A key owner first sends its identity (ID𝒜) and a request “Auth” to a guard system 𝒢. Next, 𝒢 checks whether VT𝒜 is valid. If it is not, 𝒢 sends the message “Key expired” and terminates this phase. Else, 𝒢 chooses a random number r and sends r and its identity ID𝒢 to 𝒜.Figure 2
Authentication.After receivingID𝒢 and r, 𝒜 computes v=H𝒦𝒜𝒢(r) and sends v to 𝒢. To verify whether v is a valid authentication value, 𝒢 checks whether the equation v=H𝒦𝒜𝒢(r) holds. If it does not hold, 𝒢 sends the message “The authentication is invalid” and terminates the phase. Otherwise, 𝒢 takes 𝒜 as a legitimate user and lets 𝒜 pass the verification.


### 3.3. Key Generation

Except for the current administrator in〈𝒜〉, who shares a secret key with the guard system, a new super user in status 〈𝒮〉 may request a new key in grade ℳ𝒦. (Other new administrators in status 〈𝒜〉 may need to do the same thing.) Also, a new normal user in status 〈𝒰〉 may request a new key in grade 𝒱𝒦. He can ask a ℳ𝒦 owner to generate a new key for him. This key generation phase lets an authentication key in grade ℳ𝒦 generate a new key in grade ℳ𝒦 or 𝒱𝒦. For security considerations, this phase should be carried out face-to-face via mobile devices. 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.


#### 3.3.1.ℳ𝒦 Generation

In the phase, assume a new super user𝒮i requests the administrator 𝒜 for a new key which is in grade ℳ𝒦 and is used in guard system 𝒢. As shown in Figure 3, 𝒮i first chooses a random number r𝒮i and computes w𝒮i=gr𝒮i mod p. Then 𝒮i sends w𝒮i, its identity ID𝒮i, the guard system’s identity ID𝒢, and ℳ𝒦 generation request “MKGen” to 𝒜. Next, 𝒜 computes EMK𝒮i=E𝒦𝒜𝒢(ℳ𝒦𝒮i) and then sends EMK𝒮i and its validity time value VT𝒮i to 𝒮i, where MK𝒮i = 〈𝒮〉||ID𝒮i||w𝒮i||VT𝒮i||ID𝒜||T𝒮i and T𝒮i is a time stamp. After receiving EMK𝒮i and VT𝒮i, 𝒮i stores the information 〈𝒮〉||ID𝒢||r𝒮i||VT𝒮i||ID𝒜||EMK𝒮i in its storage space and finishes this phase.Figure 3
Key generation (master key).


#### 3.3.2.𝒱𝒦 Generation

𝒱
𝒦 generation lets a valid key in grade ℳ𝒦 generate a new key in the grade 𝒱𝒦. The steps are similar to those in ℳ𝒦 generation. Assume a new normal user 𝒰j requests super user 𝒮i to provide a new key which is in grade 𝒱𝒦 and is used in guard system 𝒢. As shown in Figure 4, 𝒰j chooses a random number r𝒰j, computes w𝒰j=gr𝒰j mod p, and sends w𝒰j, ID𝒰j, ID𝒢, and “VKGen” to 𝒮i. Then, 𝒮i computes EMK𝒰j=E𝒦𝒮i(𝒱𝒦𝒰j) and sends EMK𝒰j and VT𝒰j to 𝒰j, where VK𝒰j = 〈𝒰〉||ID𝒰j||w𝒰j||VT𝒰j||ID𝒮i||T𝒰j. After receiving EVK𝒰j and VT𝒰j, 𝒰j stores 〈𝒰〉||ID𝒢||r𝒰j||VT𝒰j||ID𝒮i||EMK𝒰j in its storage space and finishes this phase.Figure 4
Key generation (visitor key).


### 3.4. Registration

After finishing the key generation phase, each newℳ𝒦 or 𝒱𝒦 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.


#### 3.4.1.ℳ𝒦 Registration

In this phase, assume a super user𝒮i wants to register a generated pseudo key to a guard system 𝒢. As shown in Figure 5, 𝒮i sends EMK𝒮i, ID𝒮i, VT𝒮i, the key issuer ID𝒜, and the registration request “MKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒜 is in status 〈𝒜〉 or 〈𝒮〉 and is thus permitted to issue keys. If it is not, 𝒢 sends the message “the key issuer is illegal” and terminates this phase. Otherwise, 𝒢 computes MK𝒮i′=D𝒦𝒜𝒢(EMK𝒮i) and verifies time stamp T𝒮i. If T𝒮i is inappropriate, 𝒢 sends the message “the time stamp is inappropriate” and terminates this phase. Otherwise, 𝒢 checks whether ID𝒮i, VT𝒮i, and ID𝒜 match the values in MK𝒮i′. If they are not, 𝒢 sends the message “Data inconsistent” and terminates this phase. If they are, 𝒢 chooses r𝒮i′, computes w𝒮i′=gr′𝒮i mod p and 𝒦𝒮i=w𝒮ir′𝒮i mod p, and stores the information 〈𝒮〉||ID𝒮i||𝒦𝒮i||VT𝒮i||ID𝒜 in its database. Then 𝒢 sends the command “ok” and w𝒮i′ back to 𝒮i. After receiving them, 𝒮i computes 𝒦𝒮i=w𝒮i′r𝒮i mod p, changes r𝒮i to 𝒦𝒮i, alters the value EMK𝒮i to “ok”, and finishes this phase.Figure 5
Registration (master key).Following this phase,𝒦𝒮i is a valid ℳ𝒦. 𝒮i can use 𝒦𝒮i to authenticate itself to guard system 𝒢 via authentication phase.


#### 3.4.2.𝒱𝒦 Registration

𝒱
𝒦 registration is similar to ℳ𝒦 registration. Assume a normal user 𝒰j registers a generated pseudo key to a guard system 𝒢. As shown in Figure 6, 𝒰j sends EVK𝒰j, ID𝒰j, VT𝒰j, the key issuer ID𝒮i, and “VKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒮i is in status 〈𝒜〉 or 〈𝒮〉. 𝒢 computes VK𝒰j′=D𝒦𝒮i(EVK𝒰j) and verifies T𝒰j. 𝒢 checks whether ID𝒰j, VT𝒰j, and ID𝒮i match the values in VK𝒰j′. 𝒢 chooses r𝒰j′, computes w𝒰j′=gr′𝒰j mod p and 𝒦𝒰j=w𝒰jr′𝒰j mod p, and stores 〈𝒰〉||ID𝒰j||𝒦𝒰j||VT𝒰j||ID𝒮i in its database. Then 𝒢 sends the command “ok” and w𝒰j′ to 𝒰j. Then, 𝒰j computes 𝒦𝒰j=w𝒰j′r𝒰j mod p, replaces r𝒰j to 𝒦𝒰j, alters EMK𝒰j to “ok,” and finishes this phase.Figure 6
Registration (visitor key).


### 3.5. Short-Term Visitor Key Authentication(SVA)

We proposeshort-term visitor key authentication(SVA), which is used for rarely or briefly used 𝒱𝒦s. 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 𝒱𝒦 owner in the guard system’s database. SVA combines the registration and authentication phases. Assume a normal user 𝒰j wants to proceed SVA to a guard system 𝒢. As shown in Figure 7, 𝒰j sends EVK𝒰j, ID𝒰j, VT𝒰j, the key issuer ID𝒮i, and “SVA” to 𝒢. Next, 𝒢 checks the legal status of the key issuer ID𝒮i. Then 𝒢 checks validation of VT𝒰j, computes VK𝒰j′=D𝒦𝒮i(EVK𝒰j), and verifies T𝒰j. 𝒢 then checks whether ID𝒰j, VT𝒰j, and ID𝒮i match the values in VK𝒰j′. Later, 𝒢 chooses a random number r′, computes w′=gr′ mod p, and sends w′ and ID𝒢 to 𝒰j. 𝒰j then computes v=w′r𝒰j mod p and sends v to 𝒢. 𝒢 then checks whether the equation v=w𝒰jr′ mod p holds. If all the verifications above are legitimate, 𝒰j passes to the SVA verification.Figure 7
Short-term visitor key authentication (SVA).


### 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 userA generates a key for a super user B, and B generates a key for a normal user C. If A’s key is compromised, we should revoke the keys of both B and C 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 u to a child v when u 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.


### 3.7. Scheme Designs

Aside from the designed model shown in Table2, 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.Table 5
Protocol goals of other scenarios.
Status
Key grade
Issued-key grade
Level
Administrator
ℳ
𝒦
𝒮
𝒦, 𝒫𝒦, 𝒰𝒦
3
Super user
𝒮
𝒦
𝒫
𝒦, 𝒰𝒦
2
Power user
𝒫
𝒦
𝒰
𝒦
1
Normal user
𝒰
𝒦
None
0Table 6
Guard system database for Table5.
Status
User ID
Key
Valid time
Issuer
〈
𝒜
〉
ID
𝒰
1
𝒦
𝒜
𝒢
VT
𝒰
1
00
〈
𝒮
〉
ID
𝒰
2
𝒦
𝒰
2
VT
𝒰
2
ID
𝒰
1
〈
𝒫
〉
ID
𝒰
3
𝒦
𝒰
3
VT
𝒰
3
ID
𝒰
2
〈
𝒫
〉
ID
𝒰
4
𝒦
𝒰
4
VT
𝒰
4
ID
𝒰
1
〈
𝒰
〉
ID
𝒰
5
𝒦
𝒰
5
VT
𝒰
5
ID
𝒰
2
〈
𝒰
〉
ID
𝒰
6
𝒦
𝒰
6
VT
𝒰
6
ID
𝒰
4
〈
𝒰
〉
ID
𝒰
7
𝒦
𝒰
7
VT
𝒰
7
ID
𝒰
1


## 3.1. Initialization

Basically, each guard system𝒢 matches at least one administrator 𝒜. Therefore, for each guard system, an administrator must execute an initialization phase to switch on a new guard system.We assume the administrator𝒜 and guard system 𝒢 share a secret key 𝒦𝒜𝒢 after the initialization phase. A validity time VT𝒜 is also recorded in the data base of 𝒢 along with the storage space (memory or hard disc) of 𝒜. Normally, an administrator’s VT𝒜 is recorded as “never expired.”There are many methods for exchanging a secret key𝒦𝒜𝒢 between 𝒜 and 𝒢. For example, the 𝒜 can choose a secret key 𝒦𝒜𝒢, encrypt it using 𝒢’s public key, and send the encrypted secret key to 𝒢. Alternatively, 𝒜 and 𝒢 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𝒜 and 𝒢 exchange secret key 𝒦𝒜𝒢 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, 𝒜 chooses a random number r𝒜, prime p and then sends gr𝒜, p, its identity ID𝒜, and initialization request “Ini” to 𝒢. Next, 𝒢 chooses a random number r′𝒜, stores the information 〈𝒜〉||ID𝒜||𝒦𝒜𝒢||VT𝒜||00 in its database, and sends a response “IniRes” to 𝒜, where “||” means concatenation and 𝒦𝒜𝒢=grAr′𝒜 mod p. A stores the information 〈𝒜〉||ID𝒢||𝒦𝒜𝒢||VT𝒜||00||ok in its database and finishes this phase.Figure 1
Initialization (under a secure environment).


## 3.2. Authentication

There are two grades of authentication key,master key (ℳ𝒦) and visitor key (𝒱𝒦). 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𝒜, for example (as shown in Figure 2). A key owner first sends its identity (ID𝒜) and a request “Auth” to a guard system 𝒢. Next, 𝒢 checks whether VT𝒜 is valid. If it is not, 𝒢 sends the message “Key expired” and terminates this phase. Else, 𝒢 chooses a random number r and sends r and its identity ID𝒢 to 𝒜.Figure 2
Authentication.After receivingID𝒢 and r, 𝒜 computes v=H𝒦𝒜𝒢(r) and sends v to 𝒢. To verify whether v is a valid authentication value, 𝒢 checks whether the equation v=H𝒦𝒜𝒢(r) holds. If it does not hold, 𝒢 sends the message “The authentication is invalid” and terminates the phase. Otherwise, 𝒢 takes 𝒜 as a legitimate user and lets 𝒜 pass the verification.


## 3.3. Key Generation

Except for the current administrator in〈𝒜〉, who shares a secret key with the guard system, a new super user in status 〈𝒮〉 may request a new key in grade ℳ𝒦. (Other new administrators in status 〈𝒜〉 may need to do the same thing.) Also, a new normal user in status 〈𝒰〉 may request a new key in grade 𝒱𝒦. He can ask a ℳ𝒦 owner to generate a new key for him. This key generation phase lets an authentication key in grade ℳ𝒦 generate a new key in grade ℳ𝒦 or 𝒱𝒦. For security considerations, this phase should be carried out face-to-face via mobile devices. 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.


### 3.3.1.ℳ𝒦 Generation

In the phase, assume a new super user𝒮i requests the administrator 𝒜 for a new key which is in grade ℳ𝒦 and is used in guard system 𝒢. As shown in Figure 3, 𝒮i first chooses a random number r𝒮i and computes w𝒮i=gr𝒮i mod p. Then 𝒮i sends w𝒮i, its identity ID𝒮i, the guard system’s identity ID𝒢, and ℳ𝒦 generation request “MKGen” to 𝒜. Next, 𝒜 computes EMK𝒮i=E𝒦𝒜𝒢(ℳ𝒦𝒮i) and then sends EMK𝒮i and its validity time value VT𝒮i to 𝒮i, where MK𝒮i = 〈𝒮〉||ID𝒮i||w𝒮i||VT𝒮i||ID𝒜||T𝒮i and T𝒮i is a time stamp. After receiving EMK𝒮i and VT𝒮i, 𝒮i stores the information 〈𝒮〉||ID𝒢||r𝒮i||VT𝒮i||ID𝒜||EMK𝒮i in its storage space and finishes this phase.Figure 3
Key generation (master key).


### 3.3.2.𝒱𝒦 Generation

𝒱
𝒦 generation lets a valid key in grade ℳ𝒦 generate a new key in the grade 𝒱𝒦. The steps are similar to those in ℳ𝒦 generation. Assume a new normal user 𝒰j requests super user 𝒮i to provide a new key which is in grade 𝒱𝒦 and is used in guard system 𝒢. As shown in Figure 4, 𝒰j chooses a random number r𝒰j, computes w𝒰j=gr𝒰j mod p, and sends w𝒰j, ID𝒰j, ID𝒢, and “VKGen” to 𝒮i. Then, 𝒮i computes EMK𝒰j=E𝒦𝒮i(𝒱𝒦𝒰j) and sends EMK𝒰j and VT𝒰j to 𝒰j, where VK𝒰j = 〈𝒰〉||ID𝒰j||w𝒰j||VT𝒰j||ID𝒮i||T𝒰j. After receiving EVK𝒰j and VT𝒰j, 𝒰j stores 〈𝒰〉||ID𝒢||r𝒰j||VT𝒰j||ID𝒮i||EMK𝒰j in its storage space and finishes this phase.Figure 4
Key generation (visitor key).


## 3.3.1.ℳ𝒦 Generation

In the phase, assume a new super user𝒮i requests the administrator 𝒜 for a new key which is in grade ℳ𝒦 and is used in guard system 𝒢. As shown in Figure 3, 𝒮i first chooses a random number r𝒮i and computes w𝒮i=gr𝒮i mod p. Then 𝒮i sends w𝒮i, its identity ID𝒮i, the guard system’s identity ID𝒢, and ℳ𝒦 generation request “MKGen” to 𝒜. Next, 𝒜 computes EMK𝒮i=E𝒦𝒜𝒢(ℳ𝒦𝒮i) and then sends EMK𝒮i and its validity time value VT𝒮i to 𝒮i, where MK𝒮i = 〈𝒮〉||ID𝒮i||w𝒮i||VT𝒮i||ID𝒜||T𝒮i and T𝒮i is a time stamp. After receiving EMK𝒮i and VT𝒮i, 𝒮i stores the information 〈𝒮〉||ID𝒢||r𝒮i||VT𝒮i||ID𝒜||EMK𝒮i in its storage space and finishes this phase.Figure 3
Key generation (master key).


## 3.3.2.𝒱𝒦 Generation

𝒱
𝒦 generation lets a valid key in grade ℳ𝒦 generate a new key in the grade 𝒱𝒦. The steps are similar to those in ℳ𝒦 generation. Assume a new normal user 𝒰j requests super user 𝒮i to provide a new key which is in grade 𝒱𝒦 and is used in guard system 𝒢. As shown in Figure 4, 𝒰j chooses a random number r𝒰j, computes w𝒰j=gr𝒰j mod p, and sends w𝒰j, ID𝒰j, ID𝒢, and “VKGen” to 𝒮i. Then, 𝒮i computes EMK𝒰j=E𝒦𝒮i(𝒱𝒦𝒰j) and sends EMK𝒰j and VT𝒰j to 𝒰j, where VK𝒰j = 〈𝒰〉||ID𝒰j||w𝒰j||VT𝒰j||ID𝒮i||T𝒰j. After receiving EVK𝒰j and VT𝒰j, 𝒰j stores 〈𝒰〉||ID𝒢||r𝒰j||VT𝒰j||ID𝒮i||EMK𝒰j in its storage space and finishes this phase.Figure 4
Key generation (visitor key).


## 3.4. Registration

After finishing the key generation phase, each newℳ𝒦 or 𝒱𝒦 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.


### 3.4.1.ℳ𝒦 Registration

In this phase, assume a super user𝒮i wants to register a generated pseudo key to a guard system 𝒢. As shown in Figure 5, 𝒮i sends EMK𝒮i, ID𝒮i, VT𝒮i, the key issuer ID𝒜, and the registration request “MKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒜 is in status 〈𝒜〉 or 〈𝒮〉 and is thus permitted to issue keys. If it is not, 𝒢 sends the message “the key issuer is illegal” and terminates this phase. Otherwise, 𝒢 computes MK𝒮i′=D𝒦𝒜𝒢(EMK𝒮i) and verifies time stamp T𝒮i. If T𝒮i is inappropriate, 𝒢 sends the message “the time stamp is inappropriate” and terminates this phase. Otherwise, 𝒢 checks whether ID𝒮i, VT𝒮i, and ID𝒜 match the values in MK𝒮i′. If they are not, 𝒢 sends the message “Data inconsistent” and terminates this phase. If they are, 𝒢 chooses r𝒮i′, computes w𝒮i′=gr′𝒮i mod p and 𝒦𝒮i=w𝒮ir′𝒮i mod p, and stores the information 〈𝒮〉||ID𝒮i||𝒦𝒮i||VT𝒮i||ID𝒜 in its database. Then 𝒢 sends the command “ok” and w𝒮i′ back to 𝒮i. After receiving them, 𝒮i computes 𝒦𝒮i=w𝒮i′r𝒮i mod p, changes r𝒮i to 𝒦𝒮i, alters the value EMK𝒮i to “ok”, and finishes this phase.Figure 5
Registration (master key).Following this phase,𝒦𝒮i is a valid ℳ𝒦. 𝒮i can use 𝒦𝒮i to authenticate itself to guard system 𝒢 via authentication phase.


### 3.4.2.𝒱𝒦 Registration

𝒱
𝒦 registration is similar to ℳ𝒦 registration. Assume a normal user 𝒰j registers a generated pseudo key to a guard system 𝒢. As shown in Figure 6, 𝒰j sends EVK𝒰j, ID𝒰j, VT𝒰j, the key issuer ID𝒮i, and “VKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒮i is in status 〈𝒜〉 or 〈𝒮〉. 𝒢 computes VK𝒰j′=D𝒦𝒮i(EVK𝒰j) and verifies T𝒰j. 𝒢 checks whether ID𝒰j, VT𝒰j, and ID𝒮i match the values in VK𝒰j′. 𝒢 chooses r𝒰j′, computes w𝒰j′=gr′𝒰j mod p and 𝒦𝒰j=w𝒰jr′𝒰j mod p, and stores 〈𝒰〉||ID𝒰j||𝒦𝒰j||VT𝒰j||ID𝒮i in its database. Then 𝒢 sends the command “ok” and w𝒰j′ to 𝒰j. Then, 𝒰j computes 𝒦𝒰j=w𝒰j′r𝒰j mod p, replaces r𝒰j to 𝒦𝒰j, alters EMK𝒰j to “ok,” and finishes this phase.Figure 6
Registration (visitor key).


## 3.4.1.ℳ𝒦 Registration

In this phase, assume a super user𝒮i wants to register a generated pseudo key to a guard system 𝒢. As shown in Figure 5, 𝒮i sends EMK𝒮i, ID𝒮i, VT𝒮i, the key issuer ID𝒜, and the registration request “MKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒜 is in status 〈𝒜〉 or 〈𝒮〉 and is thus permitted to issue keys. If it is not, 𝒢 sends the message “the key issuer is illegal” and terminates this phase. Otherwise, 𝒢 computes MK𝒮i′=D𝒦𝒜𝒢(EMK𝒮i) and verifies time stamp T𝒮i. If T𝒮i is inappropriate, 𝒢 sends the message “the time stamp is inappropriate” and terminates this phase. Otherwise, 𝒢 checks whether ID𝒮i, VT𝒮i, and ID𝒜 match the values in MK𝒮i′. If they are not, 𝒢 sends the message “Data inconsistent” and terminates this phase. If they are, 𝒢 chooses r𝒮i′, computes w𝒮i′=gr′𝒮i mod p and 𝒦𝒮i=w𝒮ir′𝒮i mod p, and stores the information 〈𝒮〉||ID𝒮i||𝒦𝒮i||VT𝒮i||ID𝒜 in its database. Then 𝒢 sends the command “ok” and w𝒮i′ back to 𝒮i. After receiving them, 𝒮i computes 𝒦𝒮i=w𝒮i′r𝒮i mod p, changes r𝒮i to 𝒦𝒮i, alters the value EMK𝒮i to “ok”, and finishes this phase.Figure 5
Registration (master key).Following this phase,𝒦𝒮i is a valid ℳ𝒦. 𝒮i can use 𝒦𝒮i to authenticate itself to guard system 𝒢 via authentication phase.


## 3.4.2.𝒱𝒦 Registration

𝒱
𝒦 registration is similar to ℳ𝒦 registration. Assume a normal user 𝒰j registers a generated pseudo key to a guard system 𝒢. As shown in Figure 6, 𝒰j sends EVK𝒰j, ID𝒰j, VT𝒰j, the key issuer ID𝒮i, and “VKRgst” to 𝒢. Next, 𝒢 checks whether the status of ID𝒮i is in status 〈𝒜〉 or 〈𝒮〉. 𝒢 computes VK𝒰j′=D𝒦𝒮i(EVK𝒰j) and verifies T𝒰j. 𝒢 checks whether ID𝒰j, VT𝒰j, and ID𝒮i match the values in VK𝒰j′. 𝒢 chooses r𝒰j′, computes w𝒰j′=gr′𝒰j mod p and 𝒦𝒰j=w𝒰jr′𝒰j mod p, and stores 〈𝒰〉||ID𝒰j||𝒦𝒰j||VT𝒰j||ID𝒮i in its database. Then 𝒢 sends the command “ok” and w𝒰j′ to 𝒰j. Then, 𝒰j computes 𝒦𝒰j=w𝒰j′r𝒰j mod p, replaces r𝒰j to 𝒦𝒰j, alters EMK𝒰j to “ok,” and finishes this phase.Figure 6
Registration (visitor key).


## 3.5. Short-Term Visitor Key Authentication(SVA)

We proposeshort-term visitor key authentication(SVA), which is used for rarely or briefly used 𝒱𝒦s. 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 𝒱𝒦 owner in the guard system’s database. SVA combines the registration and authentication phases. Assume a normal user 𝒰j wants to proceed SVA to a guard system 𝒢. As shown in Figure 7, 𝒰j sends EVK𝒰j, ID𝒰j, VT𝒰j, the key issuer ID𝒮i, and “SVA” to 𝒢. Next, 𝒢 checks the legal status of the key issuer ID𝒮i. Then 𝒢 checks validation of VT𝒰j, computes VK𝒰j′=D𝒦𝒮i(EVK𝒰j), and verifies T𝒰j. 𝒢 then checks whether ID𝒰j, VT𝒰j, and ID𝒮i match the values in VK𝒰j′. Later, 𝒢 chooses a random number r′, computes w′=gr′ mod p, and sends w′ and ID𝒢 to 𝒰j. 𝒰j then computes v=w′r𝒰j mod p and sends v to 𝒢. 𝒢 then checks whether the equation v=w𝒰jr′ mod p holds. If all the verifications above are legitimate, 𝒰j passes to the SVA verification.Figure 7
Short-term visitor key authentication (SVA).


## 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 userA generates a key for a super user B, and B generates a key for a normal user C. If A’s key is compromised, we should revoke the keys of both B and C 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 u to a child v when u 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.


## 3.7. Scheme Designs

Aside from the designed model shown in Table2, 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.Table 5
Protocol goals of other scenarios.
Status
Key grade
Issued-key grade
Level
Administrator
ℳ
𝒦
𝒮
𝒦, 𝒫𝒦, 𝒰𝒦
3
Super user
𝒮
𝒦
𝒫
𝒦, 𝒰𝒦
2
Power user
𝒫
𝒦
𝒰
𝒦
1
Normal user
𝒰
𝒦
None
0Table 6
Guard system database for Table5.
Status
User ID
Key
Valid time
Issuer
〈
𝒜
〉
ID
𝒰
1
𝒦
𝒜
𝒢
VT
𝒰
1
00
〈
𝒮
〉
ID
𝒰
2
𝒦
𝒰
2
VT
𝒰
2
ID
𝒰
1
〈
𝒫
〉
ID
𝒰
3
𝒦
𝒰
3
VT
𝒰
3
ID
𝒰
2
〈
𝒫
〉
ID
𝒰
4
𝒦
𝒰
4
VT
𝒰
4
ID
𝒰
1
〈
𝒰
〉
ID
𝒰
5
𝒦
𝒰
5
VT
𝒰
5
ID
𝒰
2
〈
𝒰
〉
ID
𝒰
6
𝒦
𝒰
6
VT
𝒰
6
ID
𝒰
4
〈
𝒰
〉
ID
𝒰
7
𝒦
𝒰
7
VT
𝒰
7
ID
𝒰
1


## 4. Analysis of Proposed Scheme

### 4.1. Security Analysis

We analyze the security of our protocols according to the requirements defined in Section2.2 as follows.Authentication. In the Authenticationphase, take 𝒜, for example (as shown in Figure 2). 𝒢 can authenticate 𝒜 from his response v since r is a random number chosen from 𝒢 and is hashed via the secret key 𝒦𝒜𝒢 between 𝒜 and 𝒢, where v=H𝒦𝒜𝒢(r). In the Registrationphase, take 𝒮i, for example (as shown in Figure 5). 𝒢 can authenticate 𝒮i from EMK𝒮i since 𝒢 computes MK𝒮i′=D𝒦𝒜𝒢(EMK𝒮i), verifies T𝒮i, and checks whether ID𝒮i, VT𝒮i, and ID𝒜 match the values in MK𝒮i′.Confidentiality of Key Values. Take 𝒮i, for example (as shown in Figures 3 and 5). The secret key 𝒦𝒮i between 𝒮i and 𝒢 is confidential because r𝒮i and r𝒮i′ are chosen by 𝒮i and 𝒢, and an adversary (or 𝒜) cannot evaluate 𝒦𝒮i from w𝒮i and w𝒮i′, where w𝒮i=gr𝒮i mod p, w𝒮i′=gr𝒮i′ mod p, and 𝒦𝒮i=w𝒮i′r𝒮i mod p=w𝒮ir𝒮i′ mod p. Therefore, the key values between the users and 𝒢 are kept private.ReplayAttack Resistance. In the Authenticationphase, take 𝒜, for example (as shown in Figure 2). 𝒢 transmits r to 𝒜 and 𝒜 transmits v=H𝒦𝒜𝒢(r) to 𝒢. Since the value r changes, the value v is different in different authentication phases. Therefore, the Authentication phase can resist replay attacks. In the Key generation phase (as shown in Figures 3 and 4), the key requester and key issuer should interact face-to-face via mobile devices in a secure environment, such as encrypted Wi-Fi Direct, Bluetooth, or IrDA. Therefore, the Key generation phase can resist replay attacks. In the Registration phase, take 𝒮i, for example (as shown in Figure 5). EMK𝒮i cannot be modified or reused since EMK𝒮i is authenticated and ID𝒮i is stored in 𝒢’s database. Therefore, Registration phase can resist replay attacks.MITM Attack Resistance. In the Registration phase, take 𝒮i, for example (as shown in Figure 5). An adversary cannot make 𝒢 believe that he is talking directly to 𝒮i since EMK𝒮i has to be authenticated and therefore w𝒮i in MK𝒮i is prevented from changing. Also, an adversary can not make 𝒮i believe that he is talking directly to 𝒢 since w𝒮i cannot be known from EMK𝒮i without secret key 𝒦𝒜𝒢 or from the Key generation phase (as shown in Figure 3) which should be run in a mobile, face-to-face, and secure environment, such as through encrypted Wi-Fi Direct or Bluetooth. Even if w𝒮i is known via cryptanalysis, the value w𝒮i is unchanged because it is difficult for an adversary to intercept the data between 𝒜 and 𝒮i and make independent connections with 𝒜 and 𝒮i in mobile and face-to-face environments. Therefore, this system can resist man-in-the-middle attacks.


### 4.2. Protocol Efficiency

In this subsection, we analyze the performance of our proposed methods. First, we show the symbols used in analysis in Table7. We then compare the cost, including computational cost and communication cost, of each phase: key generation, registration, authenticate, and SVA in Tables 8 and 11, respectively. Finally, the storage space cost is discussed in Table 12.Table 7
Symbols used in performance analysis.
Symbol
Meaning
l
N
Length of〈𝒰〉, |ID𝒰j|, |T|, |VT|, and each command (e.g., 32 bits)
l
H
Length of the output of hash function (e.g., 128 bits)
l
K
Length of a symmetric key𝒦𝒰j (e.g., 128 bits)
l
W
Length of|w𝒮i| and |w𝒰j| (e.g., 1024 bits)
l
E
Length of|MK𝒰j| and |EMK𝒰j| (e.g., 6·lN + lW = 1184 bits)
T
M
The cost of running MAC algorithm
T
C
The cost of running the comparison or element-existence checking
T
E
The cost of running the symmetric-key encryption function
T
D
The cost of running the symmetric-key decryption function
T
X
The cost of running the module exponential computation
Note: normally,TM<TC<TE≈TD<TX, and lN<lH≈lK<lW<lE.Table 8
Cost ofkey generation.
Item
Key requester
Key issuer
Computational cost
T
E
T
X
Communication cost
3
·
l
N
+
l
W
l
N
+
l
E
(140 bytes)
(152 bytes)
Transaction number
1
1Table8 shows that, in the key generation phase, the computational costs of key requester and key issuer are TE and TX, and the communication costs are 3·lN+lW and lN+lE. As per the assumption of bit length in Table 7, the communication costs are 140 bytes and 152 bytes. Similarly, Table 9 shows the computational costs and communication costs of user and guard in the registration phase.Table 9
Cost ofRegistration.
Item
User
Guard
Computational cost
T
X
2
·
T
X
+
T
D
+
5
·
T
C
Communication cost
4
·
l
N
+
l
E
l
N
+
l
W
(164 bytes)
(132 bytes)
Transaction number
1
1In both Tables10 and 11, the computational costs of user are the same (TM). The other costs of SVA are higher than those of general authentication, because users, if SVA is run, do not have to run the registration phase. Actually, aside from the computational cost of user, the other costs of SVA are approximate to the sum of the registration cost and the authentication cost. Note that, for both general authentication or SVA, the computational cost of User is just TM, which means a user only has to run an MAC algorithm to complete authentication.Table 10
Cost ofauthenticate.
Item
User
Guard
Computational cost
T
M
T
M
+
T
C
Communication cost
2
·
l
N
+
l
H
l
N
+
l
H
(24 bytes)
(20 bytes)
Transaction number
1
1Table 11
Cost ofSVA.
Item
User
Guard
Computational cost
T
M
2
·
T
X
+
T
D
+
5
·
T
C
+
T
C
Communication cost
4
·
l
N
+
l
E
+
l
H
l
N
+
l
W
(180 bytes)
(132 bytes)
Transaction number
2
1Table 12
Storage space cost.
Item
User
Guard
General scheme
3
·
l
N
+
l
K
+
l
E
None
(before registration)
(176 bytes)
(0 bytes)
General scheme
4
·
l
N
+
l
K
4
·
l
N
+
l
K
(after registration)
(32 bytes)
(32 bytes)
SVA scheme
3
·
l
N
+
l
K
+
l
E
None
(no registration required)
(176 bytes)
(0 bytes)Table12 compares storage space costs. Before registration, users keep the value EMK𝒰j, of which the length is lE and is about 1184 bits. After registration, users replace EMK𝒰j to “ok,” for which the length is lN and is about 32 bits. Therefore, 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 Section2.1.(1)
Onlyℳ𝒦s are permitted to issue (generate) other newℳ𝒦s or𝒱𝒦s. In the Registration phase, 𝒢 checks whether the key issuer is in status 〈𝒜〉 or 〈𝒮〉. Also, 𝒢 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 ℳ𝒦s 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 𝒮i (or 𝒰j) chooses a random number r𝒮i (or r𝒰j), computes w𝒮i=gr𝒮i mod p (or w𝒰j=gr𝒰j mod p), and sends it to key issuer. The key issuer then encrypts w𝒮i (or w𝒰j) into EMK𝒮i (or EMK𝒰j) and sends it to the key requester. Then, in the Registration phase, the key requester sends it to 𝒢. 𝒢 then uses w𝒮i (or w𝒰j) to make a Diffie-Hellman key exchange indirectly and authentically and exchange a secret key 𝒦𝒮i (or 𝒦𝒰j). Therefore, key issuers do not know the values of their issued keys.(3)
Only legitimateℳ𝒦and𝒱𝒦can pass the guard system verification. After running the Registration phase, the legitimate ℳ𝒦 or 𝒱𝒦 key owner can pass the verification of 𝒢 by running the Authentication phase. (𝒱𝒦 key owner can choose to run SVA directly without running the Registration phase.) Without assistance from the key issuers, who use secret keys to generate EVK, illegitimate key users fail the verification of 𝒢 in running the Registration, Authentication, or SVA phases.(4)
𝒢can precisely identify who is accessing the system.𝒢 can use the IDs and secret keys stored in its database to identify who is accessing the system. In SVA mode, 𝒢 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 7, 𝒱𝒦 key owners, who run SVA, do not run the Registration phase. Therefore, 𝒢 does not need to store data related to 𝒱𝒦 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 TM, 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, 𝒢 poses a challenge using a random r, which is different in each authentication instance. Key owners then use their secret keys to compute the MAC value of r. 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 w𝒮i (or w𝒰j) and w𝒮i′ (or w𝒰j′). 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 w𝒮i (or w𝒰j) from attack. Even if an attacker can simultaneously forge them, the key requester will eventually fail to verify 𝒢 and become aware of the attacks.


### 4.4. 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.Table 13
Comparison of properties.
Wang-Zhao
Niu-Wang
Proposed
protocol
protocol
protocol
Authentication
√
√
√
Blindness of secret keys
√
√
√
Blind key issuing
(
*
1
)
(
*
1
)
√
Non-PKI requirement
√
√
√
Replay attack resistance
√
√
√
MITM attack resistance
√
√
√
Empowered issuing
√
Independent key generation
√
Non-TTP requirement
√
Specific-key revocation
√
Storage-free choice
√


## 4.1. Security Analysis

We analyze the security of our protocols according to the requirements defined in Section2.2 as follows.Authentication. In the Authenticationphase, take 𝒜, for example (as shown in Figure 2). 𝒢 can authenticate 𝒜 from his response v since r is a random number chosen from 𝒢 and is hashed via the secret key 𝒦𝒜𝒢 between 𝒜 and 𝒢, where v=H𝒦𝒜𝒢(r). In the Registrationphase, take 𝒮i, for example (as shown in Figure 5). 𝒢 can authenticate 𝒮i from EMK𝒮i since 𝒢 computes MK𝒮i′=D𝒦𝒜𝒢(EMK𝒮i), verifies T𝒮i, and checks whether ID𝒮i, VT𝒮i, and ID𝒜 match the values in MK𝒮i′.Confidentiality of Key Values. Take 𝒮i, for example (as shown in Figures 3 and 5). The secret key 𝒦𝒮i between 𝒮i and 𝒢 is confidential because r𝒮i and r𝒮i′ are chosen by 𝒮i and 𝒢, and an adversary (or 𝒜) cannot evaluate 𝒦𝒮i from w𝒮i and w𝒮i′, where w𝒮i=gr𝒮i mod p, w𝒮i′=gr𝒮i′ mod p, and 𝒦𝒮i=w𝒮i′r𝒮i mod p=w𝒮ir𝒮i′ mod p. Therefore, the key values between the users and 𝒢 are kept private.ReplayAttack Resistance. In the Authenticationphase, take 𝒜, for example (as shown in Figure 2). 𝒢 transmits r to 𝒜 and 𝒜 transmits v=H𝒦𝒜𝒢(r) to 𝒢. Since the value r changes, the value v is different in different authentication phases. Therefore, the Authentication phase can resist replay attacks. In the Key generation phase (as shown in Figures 3 and 4), the key requester and key issuer should interact face-to-face via mobile devices in a secure environment, such as encrypted Wi-Fi Direct, Bluetooth, or IrDA. Therefore, the Key generation phase can resist replay attacks. In the Registration phase, take 𝒮i, for example (as shown in Figure 5). EMK𝒮i cannot be modified or reused since EMK𝒮i is authenticated and ID𝒮i is stored in 𝒢’s database. Therefore, Registration phase can resist replay attacks.MITM Attack Resistance. In the Registration phase, take 𝒮i, for example (as shown in Figure 5). An adversary cannot make 𝒢 believe that he is talking directly to 𝒮i since EMK𝒮i has to be authenticated and therefore w𝒮i in MK𝒮i is prevented from changing. Also, an adversary can not make 𝒮i believe that he is talking directly to 𝒢 since w𝒮i cannot be known from EMK𝒮i without secret key 𝒦𝒜𝒢 or from the Key generation phase (as shown in Figure 3) which should be run in a mobile, face-to-face, and secure environment, such as through encrypted Wi-Fi Direct or Bluetooth. Even if w𝒮i is known via cryptanalysis, the value w𝒮i is unchanged because it is difficult for an adversary to intercept the data between 𝒜 and 𝒮i and make independent connections with 𝒜 and 𝒮i in mobile and face-to-face environments. Therefore, this system can resist man-in-the-middle attacks.


## 4.2. Protocol Efficiency

In this subsection, we analyze the performance of our proposed methods. First, we show the symbols used in analysis in Table7. We then compare the cost, including computational cost and communication cost, of each phase: key generation, registration, authenticate, and SVA in Tables 8 and 11, respectively. Finally, the storage space cost is discussed in Table 12.Table 7
Symbols used in performance analysis.
Symbol
Meaning
l
N
Length of〈𝒰〉, |ID𝒰j|, |T|, |VT|, and each command (e.g., 32 bits)
l
H
Length of the output of hash function (e.g., 128 bits)
l
K
Length of a symmetric key𝒦𝒰j (e.g., 128 bits)
l
W
Length of|w𝒮i| and |w𝒰j| (e.g., 1024 bits)
l
E
Length of|MK𝒰j| and |EMK𝒰j| (e.g., 6·lN + lW = 1184 bits)
T
M
The cost of running MAC algorithm
T
C
The cost of running the comparison or element-existence checking
T
E
The cost of running the symmetric-key encryption function
T
D
The cost of running the symmetric-key decryption function
T
X
The cost of running the module exponential computation
Note: normally,TM<TC<TE≈TD<TX, and lN<lH≈lK<lW<lE.Table 8
Cost ofkey generation.
Item
Key requester
Key issuer
Computational cost
T
E
T
X
Communication cost
3
·
l
N
+
l
W
l
N
+
l
E
(140 bytes)
(152 bytes)
Transaction number
1
1Table8 shows that, in the key generation phase, the computational costs of key requester and key issuer are TE and TX, and the communication costs are 3·lN+lW and lN+lE. As per the assumption of bit length in Table 7, the communication costs are 140 bytes and 152 bytes. Similarly, Table 9 shows the computational costs and communication costs of user and guard in the registration phase.Table 9
Cost ofRegistration.
Item
User
Guard
Computational cost
T
X
2
·
T
X
+
T
D
+
5
·
T
C
Communication cost
4
·
l
N
+
l
E
l
N
+
l
W
(164 bytes)
(132 bytes)
Transaction number
1
1In both Tables10 and 11, the computational costs of user are the same (TM). The other costs of SVA are higher than those of general authentication, because users, if SVA is run, do not have to run the registration phase. Actually, aside from the computational cost of user, the other costs of SVA are approximate to the sum of the registration cost and the authentication cost. Note that, for both general authentication or SVA, the computational cost of User is just TM, which means a user only has to run an MAC algorithm to complete authentication.Table 10
Cost ofauthenticate.
Item
User
Guard
Computational cost
T
M
T
M
+
T
C
Communication cost
2
·
l
N
+
l
H
l
N
+
l
H
(24 bytes)
(20 bytes)
Transaction number
1
1Table 11
Cost ofSVA.
Item
User
Guard
Computational cost
T
M
2
·
T
X
+
T
D
+
5
·
T
C
+
T
C
Communication cost
4
·
l
N
+
l
E
+
l
H
l
N
+
l
W
(180 bytes)
(132 bytes)
Transaction number
2
1Table 12
Storage space cost.
Item
User
Guard
General scheme
3
·
l
N
+
l
K
+
l
E
None
(before registration)
(176 bytes)
(0 bytes)
General scheme
4
·
l
N
+
l
K
4
·
l
N
+
l
K
(after registration)
(32 bytes)
(32 bytes)
SVA scheme
3
·
l
N
+
l
K
+
l
E
None
(no registration required)
(176 bytes)
(0 bytes)Table12 compares storage space costs. Before registration, users keep the value EMK𝒰j, of which the length is lE and is about 1184 bits. After registration, users replace EMK𝒰j to “ok,” for which the length is lN and is about 32 bits. Therefore, 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 Section2.1.(1)
Onlyℳ𝒦s are permitted to issue (generate) other newℳ𝒦s or𝒱𝒦s. In the Registration phase, 𝒢 checks whether the key issuer is in status 〈𝒜〉 or 〈𝒮〉. Also, 𝒢 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 ℳ𝒦s 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 𝒮i (or 𝒰j) chooses a random number r𝒮i (or r𝒰j), computes w𝒮i=gr𝒮i mod p (or w𝒰j=gr𝒰j mod p), and sends it to key issuer. The key issuer then encrypts w𝒮i (or w𝒰j) into EMK𝒮i (or EMK𝒰j) and sends it to the key requester. Then, in the Registration phase, the key requester sends it to 𝒢. 𝒢 then uses w𝒮i (or w𝒰j) to make a Diffie-Hellman key exchange indirectly and authentically and exchange a secret key 𝒦𝒮i (or 𝒦𝒰j). Therefore, key issuers do not know the values of their issued keys.(3)
Only legitimateℳ𝒦and𝒱𝒦can pass the guard system verification. After running the Registration phase, the legitimate ℳ𝒦 or 𝒱𝒦 key owner can pass the verification of 𝒢 by running the Authentication phase. (𝒱𝒦 key owner can choose to run SVA directly without running the Registration phase.) Without assistance from the key issuers, who use secret keys to generate EVK, illegitimate key users fail the verification of 𝒢 in running the Registration, Authentication, or SVA phases.(4)
𝒢can precisely identify who is accessing the system.𝒢 can use the IDs and secret keys stored in its database to identify who is accessing the system. In SVA mode, 𝒢 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 7, 𝒱𝒦 key owners, who run SVA, do not run the Registration phase. Therefore, 𝒢 does not need to store data related to 𝒱𝒦 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 TM, 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, 𝒢 poses a challenge using a random r, which is different in each authentication instance. Key owners then use their secret keys to compute the MAC value of r. 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 w𝒮i (or w𝒰j) and w𝒮i′ (or w𝒰j′). 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 w𝒮i (or w𝒰j) from attack. Even if an attacker can simultaneously forge them, the key requester will eventually fail to verify 𝒢 and become aware of the attacks.


## 4.4. 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.Table 13
Comparison of properties.
Wang-Zhao
Niu-Wang
Proposed
protocol
protocol
protocol
Authentication
√
√
√
Blindness of secret keys
√
√
√
Blind key issuing
(
*
1
)
(
*
1
)
√
Non-PKI requirement
√
√
√
Replay attack resistance
√
√
√
MITM attack resistance
√
√
√
Empowered issuing
√
Independent key generation
√
Non-TTP requirement
√
Specific-key revocation
√
Storage-free choice
√


## 5. 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.



---

*Source: 858579-2013-06-20.xml*