Table of Contents Author Guidelines Submit a Manuscript
Mathematical Problems in Engineering
Volume 2015, Article ID 807213, 16 pages
http://dx.doi.org/10.1155/2015/807213
Research Article

Provable Secure and Efficient Digital Rights Management Authentication Scheme Using Smart Card Based on Elliptic Curve Cryptography

1School of Mathematics and Statistics, Wuhan University, Wuhan 430072, China
2Center of Excellence in Information Assurance, King Saud University, Riyadh 12372, Saudi Arabia

Received 30 June 2014; Accepted 28 July 2014

Academic Editor: Jong-Hyuk Park

Copyright © 2015 Yuanyuan Zhang et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

Since the concept of ubiquitous computing is firstly proposed by Mark Weiser, its connotation has been extending and expanding by many scholars. In pervasive computing application environment, many kinds of small devices containing smart cart are used to communicate with others. In 2013, Yang et al. proposed an enhanced authentication scheme using smart card for digital rights management. They demonstrated that their scheme is secure enough. However, Mishra et al. pointed out that Yang et al.’s scheme suffers from the password guessing attack and the denial of service attack. Moreover, they also demonstrated that Yang et al.’s scheme is not efficient enough when the user inputs an incorrect password. In this paper, we analyze Yang et al.’s scheme again, and find that their scheme is vulnerable to the session key attack. And, there are some mistakes in their scheme. To surmount the weakness of Yang et al.’s scheme, we propose a more efficient and provable secure digital rights management authentication scheme using smart card based on elliptic curve cryptography.

1. Introduction

In 1991, ubiquitous computing was firstly proposed by Mark Weiser, who thought that ubiquitous computing technology could provide users service with a variety of equipment in environment which would be disappeared from the user’s consciousness [1]. Later, IBM Corporation scientists also raised the idea in 1999, and they forecasted that pervasive computing can be a way to compute everywhere, anytime, and anywhere [2, 3]. Since the computer and internet technology development, multimedia contents (image, document, music, movie, video, etc.) have been greatly enriched all the time, and all of them can be easily redistributed, copied, and downloaded on the internet without authorization. This drawback results in rampant piracy and causes huge revenue to lose to the electronic commerce [4]. As a result, in pervasive computing application environment, the protection of digital publication copyright becomes more and more important. Digital rights management (DRM) technology is developed to overcome the problem [5]. Normally, DRM is only software which usually restricts the usage of the content to protect copy and distributed contents [69]. The DRM system manages the procedure of the digital contents including protection, distribution, and authorization. Using DRM technology, intellectual property is respected and protected by data encryption, so it can only be accessed by authorised users without limitless distribution [10, 11].

In 2009, the first three-role based DRM implementation scenario authentication scheme using smart card was proposed by Zhang et al. [12]. Then, Yang et al. showed that Zhang et al.’s scheme was vulnerable to the insider attack and the stolen smart card attack [10]. Due to surmounting the weaknesses of Zhang et al.’s scheme, Yang et al. proposed an enhanced digital rights management authentication scheme based on smart card. They demonstrated that their scheme could preclude all the weaknesses existing in Zhang et al.’s scheme. Recently, Mishra and Mukhopadhyay cryptanalyzed Yang et al.’s scheme and found that their scheme cannot resist the password guessing attack and the denial of service attack. Moreover, they also pointed out that Yang et al.’s scheme is not efficient enough when the user inputs an incorrect password, and this drawback may cause a denial of service attack [13]. Except for the attacks mentioned by Mishra et al., we find out that Yang et al.’s scheme does not resist the session key attack. In addition to this, we also discover that there are some mistakes in their scheme.

We proposed a new efficient and provable secure digital rights management authentication scheme using smart card based on elliptic curve cryptography [1416]. To demonstrate the scheme is provable secure, we introduce a security model AFP05 [17, 18] and analyze our scheme in this model. In the following, we will give the proof that our proposed scheme is secure in the AFP05 model. As known to all, one-way hash function is more efficient than the operation of scalar multiplication and pairings [1921]. Moreover, the pairing operation costs much more than the scalar multiplication operation. The effort of evaluating one pairing operation is approximately three times the effort of evaluating one scalar multiplication operation. So, we cut down some pairings operation of point on elliptic curve and use hash function instead to increase the scheme’s efficiency.

The structure of this paper is arranged as follows. In Section 2, we introduce the notations and definitions used in this paper. Section 3 reviews Yang et al.’s scheme, and Section 4 discusses its weakness analysis. We show the scheme details we propose in Section 5. Section 6 shows a formal security proof of the scheme, while Section 7 demonstrates the security analysis of our proposed scheme. In Section 8, we compare our proposed scheme with Yang et al.’s and Zhang et al.’s scheme. Section 9 concludes the paper.

2. Notations and Definitions

Let be an additive group with an elliptic curve by the generator and a multiplicative cyclic group by the generator . And both of them have the prime order . Let denote a computable bilinear map satisfying the following three properties [10, 12]:(i)Computability. Given , there is an efficient algorithm to compute .(ii)Bilinear. , where and .(iii)Nondegenerate. Let be the generator of , .

Several commonly used notations and their descriptions are described after the Conclusions Section to facilitate the following references.

3. Review of Yang et al.’s Scheme

There are three phases in their scheme; they are, respectively, registration phase, mutual authentication and key agreement phase, and password update phase.

3.1. Registration Phase
3.1.1. User’s Registration Section

In this part, a user requests to be a legal user and the server conducts the next operations.

U1 (: ). The user generates his/her own identity and password freely. Then, chooses a nonce randomly and computes After that, sends to the server securely.

U2 (: ). After obtaining the message sent by , the server begins to computeThen, stores in the verification table. Afterward, the server issues a smart card containing and transmits it to through a secure channel.

U3. The is input into the smart card by the , which contains , finally.

3.1.2. Device’s Registration Section

In this section, the device requests to be authorized by the , and the following steps should be performed together with the server.

D1 (: ). The device transmits its identity to the server through a secure channel.

D2 (: ). After obtaining the message sent by , the begins to computeAnd it is sent to via a secure channel. Afterward, the device’s public key and secret key are and .

3.2. Mutual Authentication and Key Agreement Phase

M1 (: ). After the inserts his/her smart card into a smart card reader and inputs his/her identity and password , the smart card randomly chooses a secret number and a nonce . And it computesNext transmits the message to .

M2 (: ). Upon obtaining the message sent by , the chooses a number randomly and computesThen, transmits the message to .

M3 (: ). When the server receives the message, it computes and checks whether is equal to . If this holds, the will authenticate and update with . Otherwise, this authentication request is rejected. Then, computes and checks whetherIf this holds, the device is authenticated by . Otherwise, this authentication request is rejected. After that, the server generates two random strings , , and a random number . computesAt last, the replies with the message to .

The correctness of (8) is shown as follows:

 M4 (: ). After receiving the message from , computesand checks whether If this holds, the server is authenticated by the device . Otherwise, this authentication procedure fails. Then, generates a random string and computesFinally, sends the message to the user .

The correctness of (12) is shown as follows:

M5 (: ). The user computes and checks whether is equal to . If it holds, the is authenticated by the . Otherwise, this authentication procedure fails. Then, updates and with and , which are saved in the smart card. After that, generates a random string and computesFinally, generates the session key shared with by computing and sends the message back to the device .

M6. After obtaining the message sent by , the device computes The is the session key between and device .

3.3. Password Update Phase

When the user requests to change the password to a new one (), he/she should perform the next procedures.

P1 (: ). After the inserts the smart card into a smart card reader and inputs his/her identity , old password and new password . Then the smart card chooses a secret nonce randomly to compute the following results:Then, transmits to .

P2 (: ). Once obtaining the message sent by , the computesand checks whether is equal to . If it holds, the will accept the user’s request and update the verifier . Otherwise, this request procedure is rejected. Then, the server transmits the message back to the user .

P3. Once the user obtains the message sent by the server, he/she checks whether is equal to . If this holds, the user replaces and with and , where .

4. Cryptanalysis of Yang et al.’s Scheme

Recently, Mishra and Mukhopadhyay demonstrated Yang et al.’s scheme is vulnerable to the password guessing attack and the denial of service attack. Moreover, they also pointed that Yang et al.’ scheme does not present efficient login and password change phases such that smart card executes the session in case of incorrect input [13]. Based on the attacks and problems mentioned in Mishra et al.’s article, we analyze Yang et al.’s scheme and find out that the scheme does not resist the session key attack. In addition to this, we also discover that there are some mistakes in their scheme. We will introduce our new discoveries in the following.

4.1. Session Key Attack

If an attacker intercepted the message which was sent from the server to the device and modified some data in it, the user and the device may establish different session key. So the attacker can realize the session key attack as the following steps.

(1) The attacker can intercept and capture the message sent to device by the server. Next, generates a number randomly and computesThen, the message is sent to the device by the attacker .

(2) After receiving the message, computesand checks the equationObviously, they are equal. Then, generates a random string and computesFinally, sends the message to the user . In this step, the string is not equal to the random string generated by the server.

The correctness of (22) is shown as follows:(3) Because did not modify the message , is equal to . Then, updates and . After that, generates a random string and computesFinally, generates the session key shared with the device and sends the message back to the device . In this step, the string is equal to the random string generated by the server and not equal to the string computed by the device.

(4) Once obtaining the message sent by the user, the device computes is the session key shared between the user and the device . Obviously, the session key computed by the user is different from the session key computed by the device. So Yang et al.’s scheme suffers from the session key attack.

4.2. Some Mistakes

In mutual authentication and key agreement phase, the identity has not been sent to the device . But, when the device computes , it already knows the user’s identity. According to the common sense, if the user has not sent identity to the device, the device cannot obtain the user’s identity. So there is a mistake in this phase. What is more, this mistake also exists in the password update phase of Yang et al.’s scheme.

5. Our Proposed Scheme

Based on Yang et al.’s scheme, our protocol also contains four phases: the registration phase, the login phase, the key agreement phase, and the password update phase. Algorithm 1 describes our scheme’s registration phase. The login phase and the key agreement phase will be shown in Algorithm 2. At last, we show the password update phase in Algorithm 3. The detail is shown as the following.

Algorithm 1: The registration phase.

Algorithm 2: The login phase and the key agreement phase.

Algorithm 3: The password update phase of our scheme.

5.1. Registration Phase

In our proposed scheme, the registration phase also can be divided into two parts: the user’s registration phase and the device’s registration phase. Our device’s registration phase is the same as the device’s registration phase in Yang et al.’s scheme. We will describe our user’s registration phase as follows.

R1 (: ). An identity and password are chosen by user freely. Then, generates a nonce randomly and computes After that, sends to the server via a secure channel.

R2 (: ). After obtaining the message sent by , computesThen, the server issues a smart card containing and passes it to securely.

R3. enters into the smart card, so it contains .

5.2. Login Phase

inserts his/her smart card into a smart card reader and inputs his/her identity and password . Then the smart card begins to computeand checks whether is equal to . If this holds, it will authenticate the identity and password of the user. Otherwise, this user’s request procedure is rejected.

5.3. Key Agreement Phase

There are six steps and five messages during each run of the proposed protocol. The details are as follows.

A1 (: ). Then, the smart card generates a secret string randomly and computesNext transmits the message to .

A2 (: ). Upon obtaining the message sent by , the generates a number randomly and computesThen, transmits the message to the server .

A3 (: ). When the server received the message, it computes and checks whether is equal to . If this holds, the device is authenticated by . Otherwise, this authentication request is rejected. Then, computes and checks whether is equal to . If this holds, the user is authenticated by . Otherwise, this authentication request is rejected. After that, the server generates a random string . Then computes

Finally, the replies with the message to the device .

A4 (: ). After receiving the message, computesand checks whether is equal to . If this holds, the is authenticated by the device . Otherwise, this authentication procedure fails. Then, generates a random number and computesFinally, the device transmits the message to the user .

A5 (: ). The user checks whether is equal to . If this holds, the user authenticates the . Otherwise, this authentication procedure fails. After that, computesThen, the user checks whether is equal to . If this holds, the device is authenticated by the user . Otherwise, this authentication procedure fails. generates a random number and computeswhere is the session key shared between the user and the device . Finally, sends the message back to the device .

A6. After obtaining the message sent by the user, the device checks whether is equal to . If this holds, the user is authenticated by the device . Otherwise, this authentication procedure fails. Then, computesThe is the session key between the user and the device .

5.4. Password Update Phase

When the user requests to update his/her password to a new , he/she should perform the next procedures.

C1 . inserts his/her smart card into a smart card reader and inputs his/her identity , old password , and new password . Then the smart card checks whether is equal to . If this holds, it will authenticate the identity and password of the user. Otherwise, this user’s password update request procedure is rejected. After this, the smart card generates a secret string randomly and computesNext transmits the message to the .

C2 (: ). Once obtaining the message sent by the user, the computesand checks whether is equal to . If this holds, will accept the user’s request. Otherwise, this request procedure is rejected. Then, the server computesand sends the message back to the user .

C3. When the user received the message from the server, he/she computesand checks whether is equal to . If not, the request is rejected. Otherwise, the user computesand replaces , , and with , , and , which are all saved in the smart card.

6. Security Model and Proof

In this part, the provable secure method will be employed to prove that our proposed protocol is provable secure in the models in [18].

6.1. Security Model

In 2005, Abdalla et al. proposed a security model AFP05, which is suitable for the three-party authenticated key agreement scenario. It contains two types of participants, such as the client and the trusted server [18]. But there are three types of participants in our proposed protocol, a user, a trusted device, and a trusted server. So we add a query SendDevice in our security model. During the execution of the protocol, and have many instances, respectively. and denote the th instance of and the th instance of . There exists one state of accept, reject, and ⊥ in an oracle. If the oracle gets correct message, it turns the accept state; otherwise, it turns reject. ⊥ means that no decision has been reached or no result has been returned. The adversary , which is abstracted as a probabilistic polynomial time Turing Machine, interacts with other participants through a bounded number of queries which model the capabilities of the adversary in an actual attack. The queries are listed as follows.

SendClient. After receiving message sent by the adversary, the generates a message and outputs as the result of this query. A query SendClient begins a new key agreement process.

SendDevice. After receiving message sent by the adversary, the generates a message and output.

SendServer. After receiving message sent by the adversary, the generates a message and output.

Reveal. If no session key is defined for instance or if either or its partner is asked a Test query, the result of this query is the invalid symbol ⊥. Otherwise the session key generated by the instance is returned.

Test. If no session key is defined for instance or if either or its partner is asked a Reveal query, the result of this query is the invalid symbol ⊥. Otherwise, the oracle flips a coin . If , the session key is output. Otherwise, a value randomly chosen from the distribution space of session key is output.

The queries defined in our improved AFP05 security model can be simulated using the SendClient, SendDevice, and SendServer queries repeatedly if we assume that there is at least one benign adversary which faithfully relays message flows. In our improved AFP05 security model, the notion of freshness is already embedded in the definition of the oracles. A Find-Then-Guess (FTG) model exists in our improved AFP05 security model, in which the semantic security is defined by a game with two phases. In the first phase, the adversary is able to adaptively execute SendClient, SendDevice, SendServer, Reveal, and Test query. In the second, executes a single Test query and guesses a bit for , where is selected in the Test query. If , the adversary wins the game. Let denote the event that the adversary correctly guesses the bit , and the advantage of that attacks the protocol is defined as

A 3PAKA protocol is considered semantically secure in FTG model if and only if is negligible, where the maximum time executed by all the adversaries with time-complexity at most and the number of queries at most .

6.2. Mathematical Computational Problems [10]

Let , be two large prime numbers and . Let be a multiplicative subgroup of , with prime number order and element generator.

Computational Diffie-Hellman Problem (CDH). Given and , it is hard to compute mod .

The probabilistic polynomial time Turing Machine denoted as , the probability of which could successfully solve CDH problem in , is defined as

CDH Assumption. For any probabilistic Turing Machine , the probability of is negligible.

Elliptic Curve Computational Diffie-Hellman (ECCDH) Assumption. Let be an additive point group with an elliptic curve by the generator and and are elements of . is able to compute the value of only with and in time at most

The fact is negligible means that the ECCDH assumption holds.

6.3. Security Proof

Theorem 1. The hash functions , , and are modeled as random oracles. Let be an adversary against our protocol within time . We denote that , , and , respectively, represent the number of , , and oracle queries executed by , and , and denote the number of SendClient queries, SendDevice queries, and SendServer queries. Then,where and , with denoting the computational time of one scalar multiplication in .

Proof. We define several attack games from Game to Game . For each game , denotes the event that has successfully guessed the bit in the test session. The games are listed as follows.
Hash, Reveal, Test Queries.(i)For a hash query , , we proceed as follows: (a) Rule : If a record exists on list , is returned. Otherwise, and is returned. Record is added to list . If the adversary directly issues this query, the record is added to list .(ii)For a query Reveal , we proceed as follows: (a) If no session key is defined for instance or if either or its partner is asked a Test query, the output is ⊥. Otherwise the output of this query is which is defined for the instance .(iii)For a query Test , we proceed as follows: (a) If no session key is defined for instance or if either or its partner is asked a Reveal query, the output is ⊥. Otherwise, the oracle flips a bit . If , the session key is output. Otherwise, a value randomly chosen from the distribution space of session key is output.
Game . This is the actual attack game. According to the definition, we have Otherwise, we randomly generate a bit if the game aborts or stops without answer from or has not finished the game.
Game . We simulate all the oracles for each query and keep three lists to store the oracles answers. stores answers of random oracles , , and . is denoted for random oracle query asked by . is for the transcripts in the channel. We simulate the SendClient, SendDevice, SendServer, Reveal, and Test queries as in the actual attack. We list hash, Reveal, Test queries in Hash, Reveal, Test Queries and SendClient, SendDevice, SendServer queries in SendClient, SendDevice, SendServer Queries. Obviously, game and game are indistinguishable. So we haveGame . In this game, all the oracles simulated are almost the same as in the game , but here, we avoid some collisions in the transcripts. The hash oracles , , and may collide with different input values. We use the following rule.
Rule . If this query is directly issued by the adversary, and , the game abort; Otherwise, is returned.
Given that hash value is selected from a random uniform distribution, the probability of collisions is at most [22].
Game and game are perfectly indistinguishable unless the abovementioned rule causes the game abort. Hence,Game . The game is defined by aborting the executions in which the adversary has obtained a valid authenticator without asking the corresponding hash query by guessing , , , , , or . The following rules are used.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we verify whether , , , , or . If the two tests fail, rejects the authenticator and terminates without accepting; otherwise, accepts and continues.
Rule : , , , . We check the equation . If it does not hold, terminates without accepting; else we verify whether or , , , , . If the two tests fail, rejects the authenticator and terminates without accepting; Otherwise, accepts and continues.
SendClient, SendDevice, SendServer Queries.(i)For a query SendClient(, Start), we proceed as follows:(a)Rule : , , and is returned. Then, instance proceeds to an expecting state.(ii)For a query SendClient(, ), we proceed as follows if instance is in an expecting state:(a)Rule : We check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(b)Rule : , and we check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(c)Rule : , ,, and instance accepts and applies the following rule.(d)Rule : , , and is returned. Then, instance terminates and record , , is added to list .(iii)For a query SendDevice(, ), we proceed as follows:(a)Rule : , , , , and is returned. Then, instance proceeds to an expecting state.(iv)For a query SendDevice(, ), we proceed as follows if instance is in an expecting state:(a)Rule : , and we check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(b)Rule : , , , , and is returned. Then, instance proceeds to an expecting state.(v)For a query SendDevice(), we proceed as follows if instance is in an expecting state:(a)Rule : We check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(b)Rule : , , and instance terminates.(vi)For a query SendServer(), we proceed as follows:(a)Rule :, and we check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(b)Rule :, , , and we check whether . If the equation does not hold, instance terminates without accepting. Otherwise, instance accepts and applies the following rule.(c)Rule : , , , , , , , and is returned. Then, instance terminates.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we verify whether , , or , , , , . If the two tests fail, rejects the authenticator and terminates without accepting; otherwise, accepts and continues.
Rule . We check the equation . If it does not hold, terminates without accepting; else we verify whether , or . If the two tests fail, rejects the authenticator and terminates without accepting; otherwise, accepts and continues.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we verify whether or . If the two tests fail, rejects the authenticator and terminates without accepting; otherwise, accepts and continues.
Rule . We check the equation . If it does not hold, terminates without accepting; else we verify whether or . If the two tests fail, rejects the authenticator and terminates without accepting; otherwise, instance accepts and continues.
Game and Game are almost indistinguishable only if the rules mentioned above cause the instance to reject a valid authenticator. Because the adversary deduces the authenticator without issuing the corresponding hash queries, the probability of guessing is at most . Hence,Game . We define game by aborting the executions in which the adversary may have obtained valid authenticator , , , , , or by guessing the corresponding secret messages and querying the corresponding hash function. We use the following rules.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we confirm whether , . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether . If this is the case, we abort the game.
Rule : , , , . We check the equation . If it does not hold, terminates without accepting; else we confirm whether . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether . If this is the case, we abort the game.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we confirm whether , . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether. If this is the case, we abort the game.
Rule . We check the equation . If it does not hold, terminates without accepting; else we confirm whether . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether . If this is the case, we abort the game.
Rule : . We check the equation . If it does not hold, terminates without accepting; else we confirm whether , . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether . If this is the case, we abort the game.
Rule . We check the equation . If it does not hold, terminates without accepting; else we confirm whether , . If the test fails, rejects the authenticator and terminates without accepting; otherwise, we check whether . If this is the case, we abort the game.
Games and are almost indistinguishable only if the rules mentioned above cause the game to abort. Because the secret messages corresponding to valid authenticators , , , , , and are deduced by the adversary, the probability of guessing is at most . Hence,Game . Here we simulate a private hash function and take place of random oracle with . Then, we do not use the or to generate session key or . As the result, the session key is completely independent of and either or .
Rule : , , and is returned. Then, instance terminates and record , is added to list .
Rule : , , and instance terminates.
Games and are almost indistinguishable only if the following event AskH5 occurs: queries the hash function on or on . Because the is a private oracle, the probability that correctly guesses the value of is . Hence,Game . In this game, the random self-reducibility of the CDH problem is used to simulate the executions. Given a CDH instance , where