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.

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 [26] 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 [1216], and public-key system protocols [1720].

Generally, mobile authentication [2124] 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 from Bob and Bob needs an authenticated public key 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, 3036] 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 [4044] 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    and can pass system verification, the system can precisely identify who ( , , or ) is accessing the system, and 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 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 a storage-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 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.

2. Preliminaries

Our scheme assumes two grades of keys, a master 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 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 ( ), super user ( ), and normal user ( ). The key grades of ( ) and ( ) are and the key grade of is . Each user in any status , , and has a validity time . The guard system 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.

Our protocol goals are only s are permitted to issue (generate) other new s or s; the key issuers (generators) do not know the values of their issued (generated) keys; only legitimate and can pass the verification of the guard system; can precisely identify who is accessing the system; short-term visitor key authentication (SVA) (i.e., a storage-free choice) eliminates the need for system storage space; keys can be revoked and keys generated from one specified user can be revoked; PKI or public-key cryptosystem is not required; authentication is efficient for users; the system provides replay attack resistance; and 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 , , , and . He or she uses different keys , , , and , respectively, for guard systems , , , and . In addition, the various guard systems have different validity times, issuers, and key status, where key status will be explained later.

Table 4 shows the possible database contents of a guard system . 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,   initialization,   authentication,   key generation,   registration,   short-term visitor key authentication (SVA),   key revocation, and   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).

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 is also recorded in the data base of along with the storage space (memory or hard disc) of . Normally, an administrator’s 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 , prime and then sends , , its identity , and initialization request “Ini” to . Next, chooses a random number , stores the information 00 in its database, and sends a response “IniRes” to , where “ ” means concatenation and mod . A stores the information ok in its database and finishes this phase.

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 ( ) and a request “Auth” to a guard system . Next, checks whether is valid. If it is not, sends the message “Key expired” and terminates this phase. Else, chooses a random number and sends and its identity to .

After receiving and , computes and sends to . To verify whether is a valid authentication value, checks whether the equation 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 requests the administrator for a new key which is in grade and is used in guard system . As shown in Figure 3, first chooses a random number and computes mod . Then sends , its identity , the guard system’s identity , and generation request “MKGen” to . Next, computes and then sends and its validity time value to , where = and is a time stamp. After receiving and , stores the information in its storage space and finishes this phase.

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 requests super user to provide a new key which is in grade and is used in guard system . As shown in Figure 4, chooses a random number , computes mod , and sends , , , and “VKGen” to . Then, computes and sends and to , where = . After receiving and , stores in its storage space and finishes this phase.

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 wants to register a generated pseudo key to a guard system . As shown in Figure 5, sends , , , the key issuer , and the registration request “MKRgst” to . Next, checks whether the status of 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 and verifies time stamp . If is inappropriate, sends the message “the time stamp is inappropriate” and terminates this phase. Otherwise, checks whether , , and match the values in . If they are not, sends the message “Data inconsistent” and terminates this phase. If they are, chooses , computes mod and mod , and stores the information in its database. Then sends the command “ok” and back to . After receiving them, computes mod , changes to , alters the value to “ok”, and finishes this phase.

Following this phase, is a valid . can use to authenticate itself to guard system via authentication phase.

3.4.2. Registration

registration is similar to registration. Assume a normal user registers a generated pseudo key to a guard system . As shown in Figure 6, sends , , , the key issuer , and “VKRgst” to . Next, checks whether the status of is in status or . computes and verifies . checks whether , , and match the values in . chooses , computes mod and mod , and stores in its database. Then sends the command “ok” and to . Then, computes mod , replaces to , alters to “ok,” and finishes this phase.

3.5. Short-Term Visitor Key Authentication (SVA)

We propose short-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 wants to proceed SVA to a guard system . As shown in Figure 7, sends , , , the key issuer , and “SVA” to . Next, checks the legal status of the key issuer . Then checks validation of , computes , and verifies . then checks whether , , and match the values in . Later, chooses a random number , computes mod , and sends and to . then computes mod and sends to . then checks whether the equation mod holds. If all the verifications above are legitimate, passes to the SVA verification.

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 when generates a key for . 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 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.

4. 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 , for example (as shown in Figure 2). can authenticate from his response since is a random number chosen from and is hashed via the secret key between and , where . In the Registration phase, take , for example (as shown in Figure 5). can authenticate from since computes , verifies , and checks whether , , and match the values in .

Confidentiality of Key Values. Take , for example (as shown in Figures 3 and 5). The secret key between and is confidential because and are chosen by and , and an adversary (or ) cannot evaluate from and , where mod , mod , and mod mod . Therefore, the key values between the users and are kept private.

ReplayAttack Resistance. In the Authentication phase, take , for example (as shown in Figure 2). transmits to and transmits to . Since the value changes, the value 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 , for example (as shown in Figure 5). cannot be modified or reused since is authenticated and is stored in ’s database. Therefore, Registration phase can resist replay attacks.

MITM Attack Resistance. In the Registration phase, take , for example (as shown in Figure 5). An adversary cannot make believe that he is talking directly to since has to be authenticated and therefore in is prevented from changing. Also, an adversary can not make believe that he is talking directly to since cannot be known from 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 is known via cryptanalysis, the value is unchanged because it is difficult for an adversary to intercept the data between and and make independent connections with and 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 Table 7. 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 8 shows that, in the key generation phase, the computational costs of key requester and key issuer are and , and the communication costs are and . 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.

In both Tables 10 and 11, the computational costs of user are the same ( ). 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 , which means a user only has to run an MAC algorithm to complete authentication.

Table 12 compares storage space costs. Before registration, users keep the value , of which the length is and is about 1184 bits. After registration, users replace to “ok,” for which the length is 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 Section 2.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 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 (or ) chooses a random number (or ), computes mod (or mod ), and sends it to key issuer. The key issuer then encrypts (or ) into (or ) and sends it to the key requester. Then, in the Registration phase, the key requester sends it to . then uses (or ) to make a Diffie-Hellman key exchange indirectly and authentically and exchange a secret key (or ). 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 , 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 , 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 (or ) and (or ). 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 (or ) 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. 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.

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.

Acknowledgments

This work was partially supported by the National Science Council under Grant NSC 101-2221-E-182-071. The authors also gratefully acknowledge helpful comments and suggestions from the reviewers, which have improved the presentation.