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.
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 Section 2, 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 , is a long-term key assumed to be never expired, is called “distributed key,” and is a random number used to specify the number of keys that will be generated. also varies randomly among different pairs of parties.
operation represents the concatenation of the messages , , and , respectively.
stands for the keyed-hash function of the message and the key .
stands for the middle key among .
The key generation process is shown in Figure 1.
The following steps show the details of the session key generation.
After sharing , Alice and Bob generate a set of “preference keys” , where , based on as follows:where . After generating the set of and 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: where specifies the round number. specifies the number of intermediate keys that is generated, . stands for the set of . and is the remaining number of intermediate keys in the set of . . . , and . The generation of , and is the same as that of .
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:
The output of the last round of intermediate key generation is considered as session keys , where , which is shown below:
Then Alice and Bob can use 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 and four sets of polynomials of degree with integer coefficients. Note that and need not be prime, but we will assume that , and will always be considerably larger than .
2.2.1. Key Generation
To create an NTRU key, we need to randomly choose two polynomials . The polynomial must satisfy the additional requirement of having inverse modulo and modulo . We will denote these inverses by and ; that is, and
Next compute the quantity .
Finally, the polynomial is the public key. The polynomial is the private key. In practice, the and also need to be kept confidential.
2.2.2. Encryption
If Alice wants to send a message to Bob, she begins by selecting a message from the set of plaintexts . Next she randomly chooses a polynomial and uses Bob’s public key to compute .
This is the encrypted message which Alice sends to Bob.
2.2.3. Decryption
Suppose that Bob has received the message from Alice and wants to decrypt it using his private key . To do this efficiently, Bob should have precomputed the polynomial described before.
In order to decrypt , Bob first computes , where he chooses the coefficients of in the interval from to . Now treating as a polynomial with integer coefficients, Bob recovers the message by computing .
Finally, Bob gets the plaintext 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 Figure 2.(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 where is initial key, is distribution key, and is random number. Later both user mobile device and server can create a set of session keys, , 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.
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 Table 1, 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: , 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 represents service provider. denotes a random number of tickets for each transaction.
The 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 ( from now on), the mobile POS terminal ( from now on), and the server ( from now on). Description of symbols used in the program is shown in Symbols.
The user holds mobile device () containing the necessary data information to achieve the certification of . is responsible for the transaction process. The server as a trusted third party shares symmetric key and each entry with . All communication between and is done via NFC. The communication between the server and 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 move closer to the RF field of the 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.
3.3.1. Initialization
Firstly, the database generates the private key and public key and shares the public key with the . Then the secret key is generated by database and initialized to . The is the random number that the system randomly assigns to the th tag at the initialization phase. Meanwhile, it is shared with . In addition to the secret key , the is stored in both the database and the .
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)The first generates the random number by a pseudo-random generator and sends the authentication query and to the .(2)The generates the random number and calculates the message by and the received random number . After the calculation is complete, the will encrypt the message by the public key of the NTRU to get the encrypted message and sends and to .(3)When receives message , it will decrypt the message by the private key in order to get the message . Then tries to find an which can satisfy the requirement in the database back. If this search succeeds, is authenticated. Otherwise, the protocol is abandoned. After is authenticated, will update the key as shown in Figure 3 and calculate the response message by the public key . Finally, sends message to the .(4)As soon as receiving the response message , this value will be compared with a computed local version . If comparison is successful, is authenticated and the key will be updated as shown in Figure 2; otherwise, the protocol is abandoned.
Payment Phase(1)After the is authenticated, the sends message to the . decrypts the payment submessage by session key which is stored into itself. Once verifies the payment information , will agree and finish the payment (see Figure 3). Meanwhile, it will send payment verification information to .(2)When the receives the payment verification information, it will first view the random numbers and , when and meet a certain threshold, the user will be blacklisted. Then will use to decrypt and view the content. Once the verification information is accepted, the will send ticket information to the . 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 () and mobile verification device (). The verification process is similar to the payment process, which is shown in Figure 4.
Firstly, the and need to complete the mutual authentication by using ; then will send the e-ticket information , where sends in the payment phase. Finally, the 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 message to implement the authentication for mobile POS device and then use again 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 Table 2.
According to Table 2, 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 is exactly the one sent by . This means that we need to achieve and .
Security Aim 2. The needs to make sure the received message is exactly the one sent by the Database, which means the following formulas need to be achieved: and .
5.1. Security Assumption
According to the given protocol, with the Database and connected securely, the following conditions can be achieved:
5.2. Security Analysis
According to the payment protocol , together with the assumptions AS1 and AS2, we can deduce and . In this scheme, the database will receive the message forwarded from the , where . As we have achieved as secret between the database and , we can take as the secret key to protect messages. So we can simply write the received message of database as , and we have . For the reason of “message-meaning rule” of BAN, , we can deduce .
From the assumption and the BAN rule of , we know . Because we have achieved , together with the “nonce-verification” rule , we will achieve , and the first security aim of the given protocol is achieved.
For the same reason, we can also deduce and , 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.
Symbols
| SE: | Security element of NFC devices |
| : | User mobile device |
| : | Mobile POS device |
| : | User mobile device ID |
| : | Random number generated by , |
| : | Payment information |
| : | The public key of database |
| : | The content part and security of e-ticket |
| : | The message encrypted by the key |
| : | The hash of the message m |
| : | The number of times of purchase and refund in a certain time |
| : | Shared session key between MD and server |
| : | The hash of the message m encrypted by key SK |
| : | The private key of database. |
Disclosure
Part of the work entitled “NFC Secure Payment and Verification Scheme for Mobile Payment” was presented at the 11th International Conference on Wireless Algorithms, Systems, and Applications (WASA 2016), Bozeman, Montana, USA, August 8–10, 2016.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work has been financially supported by the National Natural Science Foundation of China (nos. 61303216, 61272457, U1401251, and 61373172), the National High Technology Research and Development Program of China (863 Program) (no. 2012AA013102), the Open Research Project of the State Key Laboratory of Industrial Control Technology, Zhejiang University, China (no. ICT170312), and National 111 Program of China B16037 and B08038.