# NFC Secure Payment and Verification Scheme with CS E-Ticket

Authors: Kai Fan; Panfei Song; Zhao Du; Haojin Zhu; Hui Li; Yintang Yang; Xinghua Li; Chao Yang
Journal: Security and Communication Networks
 (2017)

---

## Abstract

As one of the most important techniques in IoT, NFC (Near Field Communication) is more interesting than ever. NFC is a short-range, high-frequency communication technology well suited for electronic tickets, micropayment, and access control function, which is widely used in the financial industry, traffic transport, road ban control, and other fields. However, NFC is becoming increasingly popular in the relevant field, but its secure problems, such as man-in-the-middle-attack and brute force attack, have hindered its further development. To address the security problems and specific application scenarios, we propose a NFC mobile electronic ticket secure payment and verification scheme in the paper. The proposed scheme uses a CS E-Ticket and offline session key generation and distribution technology to prevent major attacks and increase the security of NFC. As a result, the proposed scheme can not only be a good alternative to mobile e-ticket system but also be used in many NFC fields. Furthermore, compared with other existing schemes, the proposed scheme provides a higher security.


---

## Body

## 1. Introduction

IoT [1] is a large network that consists of various information sensing devices and the Internet. As a short-range, high-frequency communication technology, NFC (Near Field Communication) [2, 3] is one of the core technologies of IoT and is listed as one of the most promising technologies.NFC is a development and breakthrough of the RFID (Radio Frequency Identification) [4–6] technology. It is a short-range, high-frequency, noncontact automatic identification wireless communication technology using the 13.56 MHz frequency band at a distance of less than 10 cm. Compared with traditional identification technology, it can not only provide simple and fast secure wireless connection but also has a good compatibility and low power consumption characteristic. Because its communication distance is less than 10 cm and it has SE (Secure Element) for storing data, NFC has a higher security performance and can be applicable to the payment and verification field which needs a higher security demand such as electronic train ticket, electronic movie ticket, and other fields [7]. Though it has lots of advantages, NFC faces many security problems. Especially in the open wireless communication environment [8, 9], the information exchange between the device and the device will make it easier to suffer any kinds of security attacks, such as man-in-the-middle attack and brute force attack, which will lead to disclosure of user privacy. These security problems have become one of the bottlenecks of NFC to promote its development.On the current research status, researchers at home and abroad do not put forward a universal applicability scheme. In NFC mutual authentication phase, Yun-Seok et al. [10] propose a scheme that uses the asymmetric encryption and hash function to try to eliminate the security and privacy thread. Although the solution can solve the problem of mutual authentication and prevent replay attack and the man-in-the-middle attack, it lacks some necessary security attributes, such as the message authentication. Ceipidor et al. [11] propose a scheme which uses the symmetric encryption. This scheme implements the mutual authentication between the NFC mobile device and mobile POS device, but it cannot guarantee the integrity of the message.In recent years, because the application of electronic ticket became wider and wider, more and more people are paying attention to security and privacy problems in ticket purchase and verification process. In the purchase process, Ceipidor et al. [12] put forward a scheme using symmetric encryption, asymmetric encryption, calibration values, and other technologies. For the possible security problems in the purchase ticket process, this solution is able to achieve mutual authentication and message integrity function and resist the man-in-the-middle attack to some extent. However, because of using the fixed symmetric key encryption, this scheme not only increases the complexity of mobile devices purchasing tickets on the Internet but also leads to the security performance being reduced greatly. Furthermore, the solution cannot cope with “spike refund” malicious ticket transactions behavior.Meanwhile, in the verification process, some scholars believe that we can use infrastructure treatment scheme that is based on PKI (Public Key Infrastructure) system; the solution adopts asymmetric public key way to generate a digital signature. E-ticket holders and mobile verification devices can ensure its security through the random number verification mode under the PKI system. But this solution needs very complex calculation and cannot achieve necessary security attributes. At the same time, there are many other shortcomings, for example, the poor user experience and ticket clone issue, so the solution cannot solve security and privacy thread in the verification process. In order to better promote the NFC technology, a scheme is needed to be proposed to solve the security and privacy thread.Therefore, in this paper, we propose a new NFC mobile electronic ticket payment and verification system. Compared with the old NFC system, this system not only solves problems that exist in purchase and verification process of e-ticket but also designs a CS E-Ticket, making entire system resist stronger attack with greater security.The rest of this paper is organized as follows. In Section2, the related works are provided. In Section 3, the NFC mobile electronic ticket system is provided, including scheme structure, CS E-Ticket, CS E-Ticket secure payment, and verification schemes. In Section 4, the performance analysis of the system is evaluated in terms of security and practicality. Section 5, the security proof with BAN logic of proposed protocol will be provided. Finally, concluding remarks are provided.


## 2. Related Works

### 2.1. The Session Key Generation Technology

In this part, we mainly discuss the offline session key generation technology [13] used in payment and verification system we proposed below. It can generate a set of new session keys in the offline environment. Key generation will be divided into two parts: the first part is initialization and the second part is the key generation process.Initialization Settings. Alice and Bob share (KAB,DK,m), KAB is a long-term key assumed to be never expired, DK is called “distributed key,” and m is a random number used to specify the number of keys that will be generated. m also varies randomly among different pairs of parties.c
o
n
c
(
M
1
,
M
2
,
M
3
) operation represents the concatenation of the messages M1, M2, and M3, respectively.H
(
M
,
K
) stands for the keyed-hash function of the message M and the key K.M
i
d
(
K
1
,
K
w
) stands for the middle key among {K1,K2,…,KW}.The key generation process is shown in Figure1.Figure 1
Session key generation.The following steps show the details of the session key generation.After sharing(KAB,DK,m), Alice and Bob generate a set of “preference keys” Ki, where i=i,…,m, based on KAB as follows:(1)Ki=hKi-1,DK,where KAB=K0. After generating the set of Ki,KAB and DK can be removed from the system, to prevent the potential security problem.The next step is to generate sets of intermediate keys. The purpose of intermediate key generation is to increase the difficulty for cryptanalysis. In other words, it increases difficulty to trace back to the preference key and crack the session key. Our proposed framework is general in that it does not specify the number of rounds the engaging parties need to perform. The higher the number of rounds performed, the greater the security of system. However, increasing the number of rounds will take more time to complete. The proposed intermediate key generation is performed as follows:(2)IKjx=hconcIKMidx-1,IKj-1X,where  x specifies the round number. j specifies the number of intermediate keys that is generated, j=1,…,m. IKMid1x-1 stands for the set of {IKMid1x-1,IKMid2x-1,IKMid3x-1}. IKMid1x=mid(IK1x,IKrmx) and rm is the remaining number of intermediate keys in the set of IKjx. IKMid2x=mid(IKmid1x,IKrmx). IKMid3x=mid(IK1x,IKmid2x). IKMid11=KMid1,IKMid21=KMid2, and IKMid31=KMid3. The generation of KMid1,KMid2, and KMid3 is the same as that of IKMid1x,IKMid2x,IKMid3x. IK0x=ϕ.The previously used intermediate keys in any round can be removed from the system. Thus, the remaining intermediate keys in each round can be written as follows:(3)K1,K2,…,KrmIK11,IK21,…,IKrm1IK22,IK22,…,IKrm2⋮IK1n,IK2n,…,IKrmn.The output of the last round of intermediate key generation is considered as session keysSKj, where j=1,…,m, which is shown below:(4)IK1n=SK1,IK2n=SK2,…,IKrmn=SKm.Then Alice and Bob can useSKj as a credential to secure transactions. Because the session key was generated purely offline and is based on dynamically chosen input, it increases greatly the difficulty of crack.


### 2.2. Description of the NTRU Algorithm

The NTRU algorithm [14–16] is an open secret system invented by three professors of mathematics at Brown University in 1996. It is a cryptosystem based on polynomial rings, and its security depends on the shortest vector problem (SVP). Compared with RSA and ECC algorithm, the NTRU is simple and fast, has small storage space, and has the ability to resist quantum attacks. Therefore, next we will introduce the key generation, encryption, and decryption process as follows.The NTRU cryptosystem depends on three integer parameters(N,p,q) and four sets Lf,Lg,Lm,Lϕ of polynomials of degree N-1 with integer coefficients. Note that p and q need not be prime, but we will assume that gcd(p,q)=1, and q will always be considerably larger than p.


#### 2.2.1. Key Generation

To create an NTRU key, we need to randomly choose two polynomialsf,g∈Lg. The polynomial f must satisfy the additional requirement of having inverse modulo q and modulo p. We will denote these inverses by Fq and Fp; that is, Fq⊗f≡1(modq) and Fp⊗f≡1(modp).Next compute the quantityh≡Fq⊗g(modq).Finally, the polynomialh is the public key. The polynomial f is the private key. In practice, the Fq and Fp also need to be kept confidential.


#### 2.2.2. Encryption

If Alice wants to send a message to Bob, she begins by selecting a messagem from the set of plaintexts Lm. Next she randomly chooses a polynomial ϕ∈Lϕ and uses Bob’s public key h to compute e≡pϕ⊗h+m(modq).This is the encrypted message which Alice sends to Bob.


#### 2.2.3. Decryption

Suppose that Bob has received the messagee from Alice and wants to decrypt it using his private key f. To do this efficiently, Bob should have precomputed the polynomial Fp described before.In order to decrypte, Bob first computes a≡f⊗e(modq), where he chooses the coefficients of a in the interval from -q/2 to q/2. Now treating a as a polynomial with integer coefficients, Bob recovers the message by computing m=Fp⊗a(modp).Finally, Bob gets the plaintextm that Alice sends to him.


## 2.1. The Session Key Generation Technology

In this part, we mainly discuss the offline session key generation technology [13] used in payment and verification system we proposed below. It can generate a set of new session keys in the offline environment. Key generation will be divided into two parts: the first part is initialization and the second part is the key generation process.Initialization Settings. Alice and Bob share (KAB,DK,m), KAB is a long-term key assumed to be never expired, DK is called “distributed key,” and m is a random number used to specify the number of keys that will be generated. m also varies randomly among different pairs of parties.c
o
n
c
(
M
1
,
M
2
,
M
3
) operation represents the concatenation of the messages M1, M2, and M3, respectively.H
(
M
,
K
) stands for the keyed-hash function of the message M and the key K.M
i
d
(
K
1
,
K
w
) stands for the middle key among {K1,K2,…,KW}.The key generation process is shown in Figure1.Figure 1
Session key generation.The following steps show the details of the session key generation.After sharing(KAB,DK,m), Alice and Bob generate a set of “preference keys” Ki, where i=i,…,m, based on KAB as follows:(1)Ki=hKi-1,DK,where KAB=K0. After generating the set of Ki,KAB and DK can be removed from the system, to prevent the potential security problem.The next step is to generate sets of intermediate keys. The purpose of intermediate key generation is to increase the difficulty for cryptanalysis. In other words, it increases difficulty to trace back to the preference key and crack the session key. Our proposed framework is general in that it does not specify the number of rounds the engaging parties need to perform. The higher the number of rounds performed, the greater the security of system. However, increasing the number of rounds will take more time to complete. The proposed intermediate key generation is performed as follows:(2)IKjx=hconcIKMidx-1,IKj-1X,where  x specifies the round number. j specifies the number of intermediate keys that is generated, j=1,…,m. IKMid1x-1 stands for the set of {IKMid1x-1,IKMid2x-1,IKMid3x-1}. IKMid1x=mid(IK1x,IKrmx) and rm is the remaining number of intermediate keys in the set of IKjx. IKMid2x=mid(IKmid1x,IKrmx). IKMid3x=mid(IK1x,IKmid2x). IKMid11=KMid1,IKMid21=KMid2, and IKMid31=KMid3. The generation of KMid1,KMid2, and KMid3 is the same as that of IKMid1x,IKMid2x,IKMid3x. IK0x=ϕ.The previously used intermediate keys in any round can be removed from the system. Thus, the remaining intermediate keys in each round can be written as follows:(3)K1,K2,…,KrmIK11,IK21,…,IKrm1IK22,IK22,…,IKrm2⋮IK1n,IK2n,…,IKrmn.The output of the last round of intermediate key generation is considered as session keysSKj, where j=1,…,m, which is shown below:(4)IK1n=SK1,IK2n=SK2,…,IKrmn=SKm.Then Alice and Bob can useSKj as a credential to secure transactions. Because the session key was generated purely offline and is based on dynamically chosen input, it increases greatly the difficulty of crack.


## 2.2. Description of the NTRU Algorithm

The NTRU algorithm [14–16] is an open secret system invented by three professors of mathematics at Brown University in 1996. It is a cryptosystem based on polynomial rings, and its security depends on the shortest vector problem (SVP). Compared with RSA and ECC algorithm, the NTRU is simple and fast, has small storage space, and has the ability to resist quantum attacks. Therefore, next we will introduce the key generation, encryption, and decryption process as follows.The NTRU cryptosystem depends on three integer parameters(N,p,q) and four sets Lf,Lg,Lm,Lϕ of polynomials of degree N-1 with integer coefficients. Note that p and q need not be prime, but we will assume that gcd(p,q)=1, and q will always be considerably larger than p.


### 2.2.1. Key Generation

To create an NTRU key, we need to randomly choose two polynomialsf,g∈Lg. The polynomial f must satisfy the additional requirement of having inverse modulo q and modulo p. We will denote these inverses by Fq and Fp; that is, Fq⊗f≡1(modq) and Fp⊗f≡1(modp).Next compute the quantityh≡Fq⊗g(modq).Finally, the polynomialh is the public key. The polynomial f is the private key. In practice, the Fq and Fp also need to be kept confidential.


### 2.2.2. Encryption

If Alice wants to send a message to Bob, she begins by selecting a messagem from the set of plaintexts Lm. Next she randomly chooses a polynomial ϕ∈Lϕ and uses Bob’s public key h to compute e≡pϕ⊗h+m(modq).This is the encrypted message which Alice sends to Bob.


### 2.2.3. Decryption

Suppose that Bob has received the messagee from Alice and wants to decrypt it using his private key f. To do this efficiently, Bob should have precomputed the polynomial Fp described before.In order to decrypte, Bob first computes a≡f⊗e(modq), where he chooses the coefficients of a in the interval from -q/2 to q/2. Now treating a as a polynomial with integer coefficients, Bob recovers the message by computing m=Fp⊗a(modp).Finally, Bob gets the plaintextm that Alice sends to him.


## 2.2.1. Key Generation

To create an NTRU key, we need to randomly choose two polynomialsf,g∈Lg. The polynomial f must satisfy the additional requirement of having inverse modulo q and modulo p. We will denote these inverses by Fq and Fp; that is, Fq⊗f≡1(modq) and Fp⊗f≡1(modp).Next compute the quantityh≡Fq⊗g(modq).Finally, the polynomialh is the public key. The polynomial f is the private key. In practice, the Fq and Fp also need to be kept confidential.


## 2.2.2. Encryption

If Alice wants to send a message to Bob, she begins by selecting a messagem from the set of plaintexts Lm. Next she randomly chooses a polynomial ϕ∈Lϕ and uses Bob’s public key h to compute e≡pϕ⊗h+m(modq).This is the encrypted message which Alice sends to Bob.


## 2.2.3. Decryption

Suppose that Bob has received the messagee from Alice and wants to decrypt it using his private key f. To do this efficiently, Bob should have precomputed the polynomial Fp described before.In order to decrypte, Bob first computes a≡f⊗e(modq), where he chooses the coefficients of a in the interval from -q/2 to q/2. Now treating a as a polynomial with integer coefficients, Bob recovers the message by computing m=Fp⊗a(modp).Finally, Bob gets the plaintextm that Alice sends to him.


## 3. The Design of NFC Mobile Electronic Ticket System

In this section, in order to better describe the system which we proposed, we will introduce it from the scheme structure, CS E-Ticket, CS E-Ticket secure payment, and verification schemes.


### 3.1. Scheme Structure

The system consists of server, mobile device, mobile POS terminals, and mobile verification terminals. There are four stages: registration, booking, purchase, and verification. The communication in e-ticket registration and booking process is done in a wireless way. In order to make the whole system more convenient and secure, the communication between mobile devices will be done via the NFC. Structure of the proposed scheme is shown in Figure2.(1)
Registration: the user signs up to an online service. Server will store user’s personal information, user’s bank information, and sensitive information into its own database. Sensitive information includes the serial number of mobile device security element (IC) and shared key K0,DK,m where K0 is initial key, DK is distribution key, and m is random number. Later both user mobile device and server can create a set of session keys, SKMD-Sj,j=1,2,…,m, by using the key generation technology.(2)
Booking: user will use mobile device to book tickets on the ticket platform which service providers provide.(3)
Purchase: after booking process is finished, the user will use mobile device to complete payment operation via the mobile POS device. Later the mobile device will get e-ticket information. The communication between server and mobile POS terminal is realized by wireless way.(4)
Verification: the mobile verification terminal can communication with the user mobile device by NFC and easily verify the validity of the e-ticket stored in mobile device.Figure 2
Scheme structure.


### 3.2. CS E-Ticket

This CS E-Ticket consists of the security and context, two parts [17]. The context part mainly consists of some ticket certification information that ticket providers provide. The security part mainly includes some confidential information.As shown in Table1, the content part of ticket has title, location, seat number, time, and Mark. Among them, the Mark is used to indicate whether or not the ticket has been locked. The security part contains the following field: IDticket, one time certification for ticket, and IC serial number. IC serial number is unique number built in the SE IC that cannot be modified or erased and IDcompany represents service provider. R denotes a random number of tickets for each transaction.Table 1
CS E-Ticket.
Content part
Security part
Title
I
D
t
i
c
k
e
t
Location
IDcompany
Seat
IC
Time
R
Mark
S
K
h
(
m
)
PackageThe content part is encrypted by symmetric key. The security party is stored by using the calculated hash values. The CS E-Tickets style could be various depending on the service providers; take bus ticket as an example; it might not have the seat information. Finally, the CS E-Ticket providers will package the context and security part of ticket which has been encrypted.This scheme clearly classifies the ticket information. On the one hand, it uses symmetric encryption encrypt content part to prevent information leakage; on the other hand, it adopts hash values to keep ticket information confidential, making the CS E-Ticket have stronger security.


### 3.3. CS E-Tickets NFC Payment Scheme

In this section, there are three entities involved in our payment scheme: the mobile device (MD from now on), the mobile POS terminal (MDPOS from now on), and the server (S from now on). Description of symbols used in the program is shown in Symbols.The user holds mobile device (MD) containing the necessary data information to achieve the certification of MDPOS. MDPOS is responsible for the transaction process. The server as a trusted third party shares symmetric key and each entry ID with MD. All communication between MD and MDPOS is done via NFC. The communication between the server and MDPOS is done via the wireless communication which is based on the wireless security transport layer protocol (WTLS). Both sides of communication transfer payment information, key information, and entry id information in a safe way.When session key needs to be updated, we can take the offline session key generation technology [11] to update the session key.In order to start the payment process, user has to moveMD closer to the RF field of the MDPOS by using NFC multimodal features. Considering the e-ticket information security, we can store e-ticket information in NFC SE. Specific steps are in Figure 3.Figure 3
CS E-Ticket NFC payment scheme.


#### 3.3.1. Initialization

Firstly, the database generates the private keyF and public key H and shares the public key H with the MD. Then the secret key K is generated by database and initialized to Ki=Rot(ID⊕ri,j). The ri,j is the random number that the system randomly assigns to the ith tag at the initialization phase. Meanwhile, it is shared with MD. In addition to the secret key K, the ID is stored in both the database and the MD.


#### 3.3.2. The Authentication Process

There are two stages in the scheme that we proposed. One is authentication stage, and the other is payment stage. Then we will introduce the two stages in detail as follows.Authentication Stage
(1)
TheMDPOS first generates the random number Trw by a pseudo-random generator and sends the authentication query Query and Trw to the MD.
(2)
TheMD generates the random number Tmd and calculates the message S1=h(ID⊕Key⊕Trw⊕Tmd) by Tmd and the received random number Trw. After the calculation is complete, the MD will encrypt the message S1 by the public key H of the NTRU to get the encrypted message M1=EH(S1) and sends Tmd and M1 to MPOS.
(3)
WhenMPOS receives message M1=EH(S1), it will decrypt the message by the private key F in order to get the message S1. Then MPOS tries to find an MD which can satisfy the requirement S1′=h(ID⊕Keynew⊕Trw⊕Tmd)=S1 in the database back. If this search succeeds, MD is authenticated. Otherwise, the protocol is abandoned. After MD is authenticated, MPOS will update the key as shown in Figure 3 and calculate the response message M2=EH(ID∪Trw∪Tmd) by the public key H. Finally, MPOS sends message M2∥{O}SKMD-Sj to the MD.
(4)
As soon as receiving the response messageM2, this value will be compared with a computed local version M2′. If comparison is successful, MPOS is authenticated and the key will be updated as shown in Figure 2; otherwise, the protocol is abandoned.Payment Phase
(1)
After theMD is authenticated, the MDPOS sends message M2∥{O}SKMD-Sj to the MD. MD decrypts the payment submessage {O}SKMD-Sj by session key SKMD-Sj which is stored into itself. Once MD verifies the payment information O, MD will agree and finish the payment (see Figure 3). Meanwhile, it will send payment verification information {accept/reject}SKMD-Sj+1 to MDPOS.
(2)
When theMDPOS receives the payment verification information, it will first view the random numbers s1 and s2, when s1 and s2 meet a certain threshold, the user will be blacklisted. Then MDPOS will use SKMD-Sj+1 to decrypt {accept/reject}SKMD-Sj+1 and view the content. Once the verification information is accepted, the MDPOS will send ticket information to the MD. MD will store the received ticket information into SE of itself (see Figure 3).


### 3.4. Offline CS E-Ticket Secure Verification

In the verification process, there are two entries: user mobile device (MD) and mobile verification device (MDV). The verification process is similar to the payment process, which is shown in Figure 4.Figure 4
CS E-Ticket NFC verification protocol.Firstly, theMD and MDV need to complete the mutual authentication by using M1/M2; then MD will send MDV the e-ticket information P1, P2 where MDPOS sends MD in the payment phase. Finally, the MDV will verify whether the content and security parts of e-ticket information are right.


## 3.1. Scheme Structure

The system consists of server, mobile device, mobile POS terminals, and mobile verification terminals. There are four stages: registration, booking, purchase, and verification. The communication in e-ticket registration and booking process is done in a wireless way. In order to make the whole system more convenient and secure, the communication between mobile devices will be done via the NFC. Structure of the proposed scheme is shown in Figure2.(1)
Registration: the user signs up to an online service. Server will store user’s personal information, user’s bank information, and sensitive information into its own database. Sensitive information includes the serial number of mobile device security element (IC) and shared key K0,DK,m where K0 is initial key, DK is distribution key, and m is random number. Later both user mobile device and server can create a set of session keys, SKMD-Sj,j=1,2,…,m, by using the key generation technology.(2)
Booking: user will use mobile device to book tickets on the ticket platform which service providers provide.(3)
Purchase: after booking process is finished, the user will use mobile device to complete payment operation via the mobile POS device. Later the mobile device will get e-ticket information. The communication between server and mobile POS terminal is realized by wireless way.(4)
Verification: the mobile verification terminal can communication with the user mobile device by NFC and easily verify the validity of the e-ticket stored in mobile device.Figure 2
Scheme structure.


## 3.2. CS E-Ticket

This CS E-Ticket consists of the security and context, two parts [17]. The context part mainly consists of some ticket certification information that ticket providers provide. The security part mainly includes some confidential information.As shown in Table1, the content part of ticket has title, location, seat number, time, and Mark. Among them, the Mark is used to indicate whether or not the ticket has been locked. The security part contains the following field: IDticket, one time certification for ticket, and IC serial number. IC serial number is unique number built in the SE IC that cannot be modified or erased and IDcompany represents service provider. R denotes a random number of tickets for each transaction.Table 1
CS E-Ticket.
Content part
Security part
Title
I
D
t
i
c
k
e
t
Location
IDcompany
Seat
IC
Time
R
Mark
S
K
h
(
m
)
PackageThe content part is encrypted by symmetric key. The security party is stored by using the calculated hash values. The CS E-Tickets style could be various depending on the service providers; take bus ticket as an example; it might not have the seat information. Finally, the CS E-Ticket providers will package the context and security part of ticket which has been encrypted.This scheme clearly classifies the ticket information. On the one hand, it uses symmetric encryption encrypt content part to prevent information leakage; on the other hand, it adopts hash values to keep ticket information confidential, making the CS E-Ticket have stronger security.


## 3.3. CS E-Tickets NFC Payment Scheme

In this section, there are three entities involved in our payment scheme: the mobile device (MD from now on), the mobile POS terminal (MDPOS from now on), and the server (S from now on). Description of symbols used in the program is shown in Symbols.The user holds mobile device (MD) containing the necessary data information to achieve the certification of MDPOS. MDPOS is responsible for the transaction process. The server as a trusted third party shares symmetric key and each entry ID with MD. All communication between MD and MDPOS is done via NFC. The communication between the server and MDPOS is done via the wireless communication which is based on the wireless security transport layer protocol (WTLS). Both sides of communication transfer payment information, key information, and entry id information in a safe way.When session key needs to be updated, we can take the offline session key generation technology [11] to update the session key.In order to start the payment process, user has to moveMD closer to the RF field of the MDPOS by using NFC multimodal features. Considering the e-ticket information security, we can store e-ticket information in NFC SE. Specific steps are in Figure 3.Figure 3
CS E-Ticket NFC payment scheme.


### 3.3.1. Initialization

Firstly, the database generates the private keyF and public key H and shares the public key H with the MD. Then the secret key K is generated by database and initialized to Ki=Rot(ID⊕ri,j). The ri,j is the random number that the system randomly assigns to the ith tag at the initialization phase. Meanwhile, it is shared with MD. In addition to the secret key K, the ID is stored in both the database and the MD.


### 3.3.2. The Authentication Process

There are two stages in the scheme that we proposed. One is authentication stage, and the other is payment stage. Then we will introduce the two stages in detail as follows.Authentication Stage
(1)
TheMDPOS first generates the random number Trw by a pseudo-random generator and sends the authentication query Query and Trw to the MD.
(2)
TheMD generates the random number Tmd and calculates the message S1=h(ID⊕Key⊕Trw⊕Tmd) by Tmd and the received random number Trw. After the calculation is complete, the MD will encrypt the message S1 by the public key H of the NTRU to get the encrypted message M1=EH(S1) and sends Tmd and M1 to MPOS.
(3)
WhenMPOS receives message M1=EH(S1), it will decrypt the message by the private key F in order to get the message S1. Then MPOS tries to find an MD which can satisfy the requirement S1′=h(ID⊕Keynew⊕Trw⊕Tmd)=S1 in the database back. If this search succeeds, MD is authenticated. Otherwise, the protocol is abandoned. After MD is authenticated, MPOS will update the key as shown in Figure 3 and calculate the response message M2=EH(ID∪Trw∪Tmd) by the public key H. Finally, MPOS sends message M2∥{O}SKMD-Sj to the MD.
(4)
As soon as receiving the response messageM2, this value will be compared with a computed local version M2′. If comparison is successful, MPOS is authenticated and the key will be updated as shown in Figure 2; otherwise, the protocol is abandoned.Payment Phase
(1)
After theMD is authenticated, the MDPOS sends message M2∥{O}SKMD-Sj to the MD. MD decrypts the payment submessage {O}SKMD-Sj by session key SKMD-Sj which is stored into itself. Once MD verifies the payment information O, MD will agree and finish the payment (see Figure 3). Meanwhile, it will send payment verification information {accept/reject}SKMD-Sj+1 to MDPOS.
(2)
When theMDPOS receives the payment verification information, it will first view the random numbers s1 and s2, when s1 and s2 meet a certain threshold, the user will be blacklisted. Then MDPOS will use SKMD-Sj+1 to decrypt {accept/reject}SKMD-Sj+1 and view the content. Once the verification information is accepted, the MDPOS will send ticket information to the MD. MD will store the received ticket information into SE of itself (see Figure 3).


## 3.3.1. Initialization

Firstly, the database generates the private keyF and public key H and shares the public key H with the MD. Then the secret key K is generated by database and initialized to Ki=Rot(ID⊕ri,j). The ri,j is the random number that the system randomly assigns to the ith tag at the initialization phase. Meanwhile, it is shared with MD. In addition to the secret key K, the ID is stored in both the database and the MD.


## 3.3.2. The Authentication Process

There are two stages in the scheme that we proposed. One is authentication stage, and the other is payment stage. Then we will introduce the two stages in detail as follows.Authentication Stage
(1)
TheMDPOS first generates the random number Trw by a pseudo-random generator and sends the authentication query Query and Trw to the MD.
(2)
TheMD generates the random number Tmd and calculates the message S1=h(ID⊕Key⊕Trw⊕Tmd) by Tmd and the received random number Trw. After the calculation is complete, the MD will encrypt the message S1 by the public key H of the NTRU to get the encrypted message M1=EH(S1) and sends Tmd and M1 to MPOS.
(3)
WhenMPOS receives message M1=EH(S1), it will decrypt the message by the private key F in order to get the message S1. Then MPOS tries to find an MD which can satisfy the requirement S1′=h(ID⊕Keynew⊕Trw⊕Tmd)=S1 in the database back. If this search succeeds, MD is authenticated. Otherwise, the protocol is abandoned. After MD is authenticated, MPOS will update the key as shown in Figure 3 and calculate the response message M2=EH(ID∪Trw∪Tmd) by the public key H. Finally, MPOS sends message M2∥{O}SKMD-Sj to the MD.
(4)
As soon as receiving the response messageM2, this value will be compared with a computed local version M2′. If comparison is successful, MPOS is authenticated and the key will be updated as shown in Figure 2; otherwise, the protocol is abandoned.Payment Phase
(1)
After theMD is authenticated, the MDPOS sends message M2∥{O}SKMD-Sj to the MD. MD decrypts the payment submessage {O}SKMD-Sj by session key SKMD-Sj which is stored into itself. Once MD verifies the payment information O, MD will agree and finish the payment (see Figure 3). Meanwhile, it will send payment verification information {accept/reject}SKMD-Sj+1 to MDPOS.
(2)
When theMDPOS receives the payment verification information, it will first view the random numbers s1 and s2, when s1 and s2 meet a certain threshold, the user will be blacklisted. Then MDPOS will use SKMD-Sj+1 to decrypt {accept/reject}SKMD-Sj+1 and view the content. Once the verification information is accepted, the MDPOS will send ticket information to the MD. MD will store the received ticket information into SE of itself (see Figure 3).


## 3.4. Offline CS E-Ticket Secure Verification

In the verification process, there are two entries: user mobile device (MD) and mobile verification device (MDV). The verification process is similar to the payment process, which is shown in Figure 4.Figure 4
CS E-Ticket NFC verification protocol.Firstly, theMD and MDV need to complete the mutual authentication by using M1/M2; then MD will send MDV the e-ticket information P1, P2 where MDPOS sends MD in the payment phase. Finally, the MDV will verify whether the content and security parts of e-ticket information are right.


## 4. Security Analysis of NFC Mobile Electronic Ticket System

### 4.1. Security Analysis

In this section, we will analyze our proposed system scheme from the point of view of security and practicability.


#### 4.1.1. Mutual Authentication

The scheme uses messageM1=EH(S1) to implement the authentication for mobile POS device and then use again M2=EH(ID∪Trw∪Tmd) to implement the authentication for mobile device. So the scheme can implement mutual authentication.


#### 4.1.2. Confidentiality

In the proposed scheme, all exchange information will use symmetric key to ensure that the message is in the cipher state.


#### 4.1.3. Nontracking

Because the response message generated by the same devices is different in each session, attacker could not assure the tracking attack successfully because there is no the fixed messages [5].


#### 4.1.4. Brute Force Attack

According to the proposed system scheme, it is difficult to find the correct session key as session key change every time at the completion of transaction. In addition, applying an offline key generation technology can increase resistance to brute force attacks [18].


#### 4.1.5. Forward Security

Because the session key is different in each session, the attacker cannot obtain the previous interactive information.


#### 4.1.6. Replay Attack Prevention

By using nonce and limited-use session keys, the proposed system scheme can prevent replay attack [16] as the session keys used in this scheme are used only once.


#### 4.1.7. Man-in-the-Middle-Attack

An attacker who pretends to be an authorized party is not able to analyze the transmitted message since the session keys used in our scheme are changed constantly by using strong encryption.


#### 4.1.8. The “Spike Refund” Attack

Because the scheme will calculate the times of purchase and refund within a certain period of time, if the times reach the upper limit, the user will be pulled into the blacklist. By this way, the system scheme we proposed can prevent “spike refund” attack.


#### 4.1.9. The e-Ticket Clone Attack

For the system scheme we proposed, on the one hand, the security part information is displayed to user in the form of hash value. On the other hand, we bind the IC serial number to user mobile device. By this way, the cloned e-ticket cannot finish the authentication and verification process, which prevent the e-ticket clone attack [19].


### 4.2. Practicability Analysis

For the train stations, airports and other places where the flow of people is large and the security needs are higher, the proposed scheme has a strong practicability comparing with other schemes in Table2.Table 2
The analysis of practicability.
Symmetric encryption
Symmetric decryption
Nonsymmetric encryption
Nonsymmetric decryption
Hash function
Message number
Yun-Seok et al.
4
4
1
1
3
6
Ceipidor et al.
—
—
2
2
3
6
León-Coca et al.
7
7
—
—
—
7
E-ticket NFC payment scheme
2
2
1
1
1
5
Offline e-ticket verification scheme
2
2
1
1
1
5According to Table2, the proposed scheme has fewer operations and hash computation and spends less time to complete the transaction. The scheme only adopts simple shift operation and symmetric key with a lightweight.Computation Cost. Compared with other protocols, the protocols we have proposed only require less operation, including hash operation and encryption operation. Therefore, our protocol is more low-cost.Communication Cost. When the protocol we proposed is compared with other protocols, we can observe that the authentication phase and transaction phase only require five messages; it is less than other protocols in communication. This means that our protocol is more fast and effective.


## 4.1. Security Analysis

In this section, we will analyze our proposed system scheme from the point of view of security and practicability.


### 4.1.1. Mutual Authentication

The scheme uses messageM1=EH(S1) to implement the authentication for mobile POS device and then use again M2=EH(ID∪Trw∪Tmd) to implement the authentication for mobile device. So the scheme can implement mutual authentication.


### 4.1.2. Confidentiality

In the proposed scheme, all exchange information will use symmetric key to ensure that the message is in the cipher state.


### 4.1.3. Nontracking

Because the response message generated by the same devices is different in each session, attacker could not assure the tracking attack successfully because there is no the fixed messages [5].


### 4.1.4. Brute Force Attack

According to the proposed system scheme, it is difficult to find the correct session key as session key change every time at the completion of transaction. In addition, applying an offline key generation technology can increase resistance to brute force attacks [18].


### 4.1.5. Forward Security

Because the session key is different in each session, the attacker cannot obtain the previous interactive information.


### 4.1.6. Replay Attack Prevention

By using nonce and limited-use session keys, the proposed system scheme can prevent replay attack [16] as the session keys used in this scheme are used only once.


### 4.1.7. Man-in-the-Middle-Attack

An attacker who pretends to be an authorized party is not able to analyze the transmitted message since the session keys used in our scheme are changed constantly by using strong encryption.


### 4.1.8. The “Spike Refund” Attack

Because the scheme will calculate the times of purchase and refund within a certain period of time, if the times reach the upper limit, the user will be pulled into the blacklist. By this way, the system scheme we proposed can prevent “spike refund” attack.


### 4.1.9. The e-Ticket Clone Attack

For the system scheme we proposed, on the one hand, the security part information is displayed to user in the form of hash value. On the other hand, we bind the IC serial number to user mobile device. By this way, the cloned e-ticket cannot finish the authentication and verification process, which prevent the e-ticket clone attack [19].


## 4.1.1. Mutual Authentication

The scheme uses messageM1=EH(S1) to implement the authentication for mobile POS device and then use again M2=EH(ID∪Trw∪Tmd) to implement the authentication for mobile device. So the scheme can implement mutual authentication.


## 4.1.2. Confidentiality

In the proposed scheme, all exchange information will use symmetric key to ensure that the message is in the cipher state.


## 4.1.3. Nontracking

Because the response message generated by the same devices is different in each session, attacker could not assure the tracking attack successfully because there is no the fixed messages [5].


## 4.1.4. Brute Force Attack

According to the proposed system scheme, it is difficult to find the correct session key as session key change every time at the completion of transaction. In addition, applying an offline key generation technology can increase resistance to brute force attacks [18].


## 4.1.5. Forward Security

Because the session key is different in each session, the attacker cannot obtain the previous interactive information.


## 4.1.6. Replay Attack Prevention

By using nonce and limited-use session keys, the proposed system scheme can prevent replay attack [16] as the session keys used in this scheme are used only once.


## 4.1.7. Man-in-the-Middle-Attack

An attacker who pretends to be an authorized party is not able to analyze the transmitted message since the session keys used in our scheme are changed constantly by using strong encryption.


## 4.1.8. The “Spike Refund” Attack

Because the scheme will calculate the times of purchase and refund within a certain period of time, if the times reach the upper limit, the user will be pulled into the blacklist. By this way, the system scheme we proposed can prevent “spike refund” attack.


## 4.1.9. The e-Ticket Clone Attack

For the system scheme we proposed, on the one hand, the security part information is displayed to user in the form of hash value. On the other hand, we bind the IC serial number to user mobile device. By this way, the cloned e-ticket cannot finish the authentication and verification process, which prevent the e-ticket clone attack [19].


## 4.2. Practicability Analysis

For the train stations, airports and other places where the flow of people is large and the security needs are higher, the proposed scheme has a strong practicability comparing with other schemes in Table2.Table 2
The analysis of practicability.
Symmetric encryption
Symmetric decryption
Nonsymmetric encryption
Nonsymmetric decryption
Hash function
Message number
Yun-Seok et al.
4
4
1
1
3
6
Ceipidor et al.
—
—
2
2
3
6
León-Coca et al.
7
7
—
—
—
7
E-ticket NFC payment scheme
2
2
1
1
1
5
Offline e-ticket verification scheme
2
2
1
1
1
5According to Table2, the proposed scheme has fewer operations and hash computation and spends less time to complete the transaction. The scheme only adopts simple shift operation and symmetric key with a lightweight.Computation Cost. Compared with other protocols, the protocols we have proposed only require less operation, including hash operation and encryption operation. Therefore, our protocol is more low-cost.Communication Cost. When the protocol we proposed is compared with other protocols, we can observe that the authentication phase and transaction phase only require five messages; it is less than other protocols in communication. This means that our protocol is more fast and effective.


## 5. Security Proof with BAN Logic

Because the authentication of payment and verification protocol is the same, we will use the BAN logic [20, 21] to prove the mutual authentication part of the payment in this section.The core security assurance of the proposed protocol is the secure mutual authentication, which means the following security aims should be achieved.Security Aim  1. Database needs to make sure the received message M1∥Trw∥Tmd is exactly the one sent by MD. This means that we need to achieve Database∣≡MDi∣~(M1,Trw,Tmd) and Database∣≡MDi∣≡(M1,Trw,Tmd).Security Aim  2. The MD needs to make sure the received message M2 is exactly the one sent by the Database, which means the following formulas need to be achieved: MDi∣≡Database∣~M2 and MDi∣≡Database∣≡M2.


### 5.1. Security Assumption

According to the given protocol, with the Database andMDPOS connected securely, the following conditions can be achieved:AS1:Database∣≡Database⇄ri,jMDiAS2:MDi∣≡Database⇄ri,jMDiAS3:MDPOS⇒(Trw)AS4:MDPOS∣≡#(Trw)AS5:Database∣≡#(Trw)AS6:MDi⇒(Tmd)AS7:MDi∣≡#(Tmd)


### 5.2. Security Analysis

According to the payment protocolKi=Rot(ID⊕ri,j), together with the assumptions AS1 and AS2, we can deduce Databasei∣≡Database⇌KiMDi and MDi∣≡Database⇌KiMDi. In this scheme, the database will receive the message M1∥Trw∥Tmd forwarded from the MDPOS, where M1=EH(ID⊕K⊕Tmd⊕Trw). As we have achieved Ki as secret between the database and MD, we can take Ki as the secret key to protect messages. So we can simply write the received message of database as (M1∥Trw∥Tmd)Ki, and we have Database⊲(M1∥Trw∥Tmd)Ki. For the reason of “message-meaning rule” of BAN, P∣≡Q⇌YP,P⊲〈X〉Y/P∣≡(Q∣~X), we can deduce Database∣≡MDi∣~(M1,Trw,Tmd).From the assumptionAS5:Database∣≡#(Trw) and the BAN rule of P∣≡#(X),/P∣≡#(X,Y), we know Database∣≡#(M1,Trw,Tmd). Because we have achieved Database∣≡MDi∣~#(M1,Trw,Tmd), together with the “nonce-verification” rule P∣≡(#(X)),P∣≡(Q∣~X)/P∣≡(Q∣≡X), we will achieve Database∣≡MDi∣≡(M1,Trw,Tmd), and the first security aim of the given protocol is achieved.For the same reason, we can also deduceMDi∣≡Database∣~M2 and MDi∣≡Database∣≡M2, and the second of security aim is also achieved, and the security of mutual authentication of the proposed protocol has been proved.


## 5.1. Security Assumption

According to the given protocol, with the Database andMDPOS connected securely, the following conditions can be achieved:AS1:Database∣≡Database⇄ri,jMDiAS2:MDi∣≡Database⇄ri,jMDiAS3:MDPOS⇒(Trw)AS4:MDPOS∣≡#(Trw)AS5:Database∣≡#(Trw)AS6:MDi⇒(Tmd)AS7:MDi∣≡#(Tmd)


## 5.2. Security Analysis

According to the payment protocolKi=Rot(ID⊕ri,j), together with the assumptions AS1 and AS2, we can deduce Databasei∣≡Database⇌KiMDi and MDi∣≡Database⇌KiMDi. In this scheme, the database will receive the message M1∥Trw∥Tmd forwarded from the MDPOS, where M1=EH(ID⊕K⊕Tmd⊕Trw). As we have achieved Ki as secret between the database and MD, we can take Ki as the secret key to protect messages. So we can simply write the received message of database as (M1∥Trw∥Tmd)Ki, and we have Database⊲(M1∥Trw∥Tmd)Ki. For the reason of “message-meaning rule” of BAN, P∣≡Q⇌YP,P⊲〈X〉Y/P∣≡(Q∣~X), we can deduce Database∣≡MDi∣~(M1,Trw,Tmd).From the assumptionAS5:Database∣≡#(Trw) and the BAN rule of P∣≡#(X),/P∣≡#(X,Y), we know Database∣≡#(M1,Trw,Tmd). Because we have achieved Database∣≡MDi∣~#(M1,Trw,Tmd), together with the “nonce-verification” rule P∣≡(#(X)),P∣≡(Q∣~X)/P∣≡(Q∣≡X), we will achieve Database∣≡MDi∣≡(M1,Trw,Tmd), and the first security aim of the given protocol is achieved.For the same reason, we can also deduceMDi∣≡Database∣~M2 and MDi∣≡Database∣≡M2, and the second of security aim is also achieved, and the security of mutual authentication of the proposed protocol has been proved.


## 6. Conclusions

Firstly, this paper designs and introduces an electronic ticket system from the point of view of the registration, booking, ticketing, and verification. This system is composed of servers, mobile device, mobile POS device, and mobile verification terminals. For the problems existing in ticketing process, this paper proposes an e-ticket NFC payment scheme. This scheme can not only give the user good experience but also protect the user e-ticket security information. For the problems in the verification process, an offline session key generation and distribution technology is introduced. On the one hand, this technology increases the security of the communication between each entity. On the other hand, it can cope with the “spike refund” issue so that the system we proposed can be applied to train tickets, air tickets, and other fields which need higher requirements.



---

*Source: 4796373-2017-07-10.xml*