3. Related Works
3.1 He et al.’s EMV-based Offline Payment with Mutual Authentication
In this chapter, we will discuss He et al.’s [33] off-line payment protocol in session 3.1. He et al. proposed a protocol which is not only allows the user to deal with merchants in off-line mode, but is also compatible with EVM standard.
And the other we will discuss in session 3.2 is Chen et al.’s [26] protocol which can allow the user can be anonymous and keep the user’s information confidential.
3.1 He et al.’s EMV-based Offline Payment with Mutual Authentication
In 2014, Yang et al. [24] point out the transaction problems in the EMV, including:
cards fail to identify the card readers, unencrypted connection; merchants cannot confirm the validity of the credit cards immediately in off-line mode, etc. However, the protocol which proposed by Yang et al. may cause the problems of credit expansion after performing off-line transaction for many times, which can lead to the behaviors of double spending by malicious users.
In order to improve the method proposed by Yang et al. in 2014, He et al. [33]
proposed an EMV based secure protocol which improves the security of the method proposed by He et al.
Under this protocol, off-line transaction certificates applied by users contain two hash chains, which include both the Payword value of user consumption and the Payword value of merchant identify. Through the authorization of Issuer, users can generate the off-line certificates for the amount of the transaction before each off-line transaction;
merchants can confirm the correctness of the user payments after receipt of the Paywords and off-line certificates.
The protocol symbols show as table 1.
‧
Table 1. Symbol table of He’s protocol[33]
Certtargetpublisher Target’s certificate which is issued by Publisher include target’s Public and Private key pairs
Certoff Certificate for Off-line transaction
PKA The public key of A
SKA The private key of A
Kencemv The symmetric key between card and card Issuer used for encrypting
Kmacemv The symmetric key between card and Issuer used for computing message authentication code
Kβ The symmetric key between Issuer for encrypting off-line transaction message which give to Issuer.
TK The session key between cell phone and merchant Kiss The key only own by Issuer which used for encrypting
specific serial number and random number to create the secret value in hash chain
Ekey(X) Encrypt function that uses key to encrypt message X Dkey(X) Decrypt function that uses key to decrypt message X MACKmacemv(X) Computing X’s message authentication code by key
Kmacemv in EMV protocol
HMACkey(X) Hash function that uses key to hash message X
h(X) Hash function that to hash message X
n Amount of transaction in off-line mode, also means computable times in hash chain
‧
t The maximum number of transactions
m The number of authorized merchants for off-line transaction wn The first value in hash chain used for payment w0 The last value in hash chain used for payment
s0 The first value in hash chain used for record by user
sn The last value in hash chain used for record by user
STable The table which record wn, s0 hold by Issuer
SNi The ith serial number
Ri The ith random number
Rlim The information of the off-line credit card
Lim The content include manage amount of transaction and limit
W W={w0, ..., wn}
S S={S0, ..., Sn}
M A set include all authorized merchants which can dealing in off-line mode
IDMi Identity of Merchant i
counter The amount of transaction counter in off-line
φ The signature on w0 signed by issuer means the amount for off-line transaction endorsed by the issuer
𝑙 The number of the hash iterations
end_time The maximum off-line transaction time set by merchant
Issuer The identity of Issuer
PAN Primary Account Number
ET Expiry Time
Current Time transaction time
‧
c The amount of the transaction
u The number of the last transaction
𝑣 The number of the current transaction, v = u+1 β The message for the card issuer to verify the validity of the
off-line transaction
μ The message for the merchant to verify the validity of the off-line transaction
3.1.1 Revisit of He et al.’s Protocol
This protocol is divided into five stages: 1. Mutual authentication stage between users and merchants 2. Function selection stage 3. Off-line certificate application and authorization stage 4. Off-line/on-line transaction stage 5.Merchant payout request stage
The dotted box (ie., -..-..-) in the Figure 3, 4 is an additional part of this protocol. This protocol is based on the EMV proposed in the EPMAR by Hong et al. [32], which can increase its off-line security in the transaction part of users and merchants.
In the transaction parts between mobile phones and the merchant, we will all use the session key TK generated in the Users’ stage for encryption and communication.
Stage 1 and 2 of this protocol are all the same with the EPMAR of Hong et al. [32], so no more discussions will be made on that.
Stage 1 is for users and the merchant to verify status of both parties by exchanging certificate; stage 2 is feature selection stage, which will confirm whether the user has
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
off-line certificates, and it will enter the transaction stage if the user has it; stage 3 off-line certificate application stage, the user will apply for off-line transaction certificates to Issuer in this stage and hand it over to the next stage; stage 4 is for transaction, the transaction is off-line at the beginning, and the transaction info will be delivered to Issuer if the merchant support on-line transaction; stage 5 is for the payout request of the merchant
The protocol flow chat show as figure 2.
Figure 2. Flow of the protocol 3.1.3.1 Off-line Certificate Application
In stage 3 for off-line certificate application, the user will perform the following steps:
Step 1. Merchants request users’ NFC mobile phone to present off-line certificates
Step 2. If the users’ mobile phone does not have off-line certificates
(2a-1) The phone applies for the required off-line transaction certificates o to Issuer.
(2a-2) Issuer produces off-line certificates. After that the users’ NFC mobile phone receives that, it will be stored in the SE of the phone.
If the phone has off-line certificates
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(2b) The mobile phone sends the off-line certificates to the merchant
Figure 3 is the off-line certificate application during the transaction between users and the merchant; the reserve field means the additional information in the protocol that is compatible with EMV instruction; the blue part is additional step based on EPMAR.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 3. Contents of the off-line certificate application
‧
2. The user will encrypt OCRC, ATC, AC by session key TK and send to merchants 3. After the merchant received cipher text form the above step then decrypted by using the TK, it passes Datacdol1,the longest time (end_time) and the random number to Issuer for the off-line environment, and let Issuer produce the certificate according to the information
4. When Issuer receives the OCRC request, it can use its shared key with the user to verify the correctness of the message delivered by the merchant. If it is a wrong message, it will set the ARC (Authorization Response Code) as failure, otherwise it will produce the off-line transaction certificates, quota segmentation and other relevant information:
(1) Produce two secret factors {Wn, S0} where Wn representing the quota and the S0 representing the merchant
(2) Separately calculate the hash chain of each secret factor W = {wi|wi = h(wi−1), where i ∈ {1 … n} }
S = {si|si = h(si+1), where i ∈ {0 … t − 1}
(3) Set M as the set of all identities of authorized merchants.
(4) Produce a key Kβ with which Issuer can verify transaction information, current
‧
that the merchant can confirm the transaction in the future(6) Use the public key of the credit card PKemv to produce the off-line transaction information Lim, Lim = EPKemv{Kβ, wn, SNw, s0, SNs, b, φ, Rlim}. It contains the key Kβ which share on user and Issuer, secret quota factor, usage quota and random number Rlim of the user and Issuer
(7) According to the EMV standard and the end_time delivered by merchants, Issuer will produce the off-line certificate, which contains the name of Issuer, credit card account of the user PAN, certificate expiration date, limit of consumption quota n, all authorized merchants M.
And it will use with the shared key with the user to deliver the certificate and Lim to the merchant
5. If the ARC replies that the merchant fails to receive from Issuer, it is deemed as termination of the transaction, otherwise, it will adopt EXTERNAL AUTHEENTICATION to deliver the information that is sent by Issuer back to the user.
The user performs the following steps after receiving the certificate information from the merchant:
(1) Use the shared key with Issuer to decrypt the cipher text and confirm whether its MAC and verification if certificates are correct or not.
(2) If it’s correct, just put the Dataemv in certificate and stored.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(3) Use the private key of the credit card SKemv to decrypt Lim and put it into the SE.
After the mobile phone receives Lim, it will directly be sent to the SE for decryption.
There the role of mobile phone is a transshipment part between the merchant and the SE
(4) Decrypt φ, conduct n times hash operations, and then verify whether wn is equal to w0, if it succeeds, the counter in the SE should be set to 0, and if the counter is n, it represents that the consumption amount is full, and then set the ACK as success.
(5) Send ACK to the merchant.
6. If the ACK that the merchant receive is failure, that represents the certificate verification fails, we must reapply the certificate.
3.1.3.2 Off-line/On-line Transaction Stage
In this stage, the user will send certificate to the merchant. The merchants will decide to do transaction on-line or off-line, as shown in Figure 4 and 5.
Figure 4. Flow chart of the off-line transaction
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 5. Contents of the transaction step
‧
7. When the user receives GEMERATE AC instruction delivered by the merchant, it will use session key TK to decrypt the information and display it on the users’ device, and let the user to make verification on the correctness of the transaction information.
If it’s correct, it will conduct the following steps in accordance with the EMV payment protocol.
(1) Generate a random number Rm and generate MAC with the transaction serial number ATC Kmacemv, transaction information Data𝑐𝑑𝑜𝑙1, random number Rm as AC1 by 𝐾𝑚𝑎𝑐𝑒𝑚𝑣. In short, compute AC1 = MACKmacemv( Datacdol1, 𝐴𝑇𝐶, Rm).
(2) Compute the hash value by hashing with AC1, the random number RP, Req which is type of transaction, Rm, Data𝑐𝑑𝑜𝑙1 and ATC . In short, compute H(RP, Req, AC1, Rm, Data𝑐𝑑𝑜𝑙1, ATC).
(3) Use the private key of EMV card 𝑆𝐾𝑒𝑚𝑣 to encrypt the above information and hash values as SDAD (Signed Dynamic Application Data). In short, compute SDAD
= ESKemv(RP, Req, AC1, h(RP, Req, AC1, Rm, Datacdol1, ATC))
(4)See whether the ID delivered by the merchant is included in Issuer verification list M
(5) Adopt the used quota b to calculate the used hash value wb= hn−b(wn) and compute the amount of the transaction c by wb+c= hc(wb).
(6) Calculate the merchant code sv = h(su), and if it’s the first consumption then it should be: u = 0, v = 1. All the transaction after it will generate the unique number value sv that represents the merchant. In the transfer of transaction information, the merchants won’t know the unique number, only the user and Issuer know it.
(7) Add this transaction amount c to the amount b that has been consumed, and update
‧
the position used in the hash chain
(8) Add c to the counter to update the consumption amount
(9) Use off-line verification key Kβ to encrypt with merchant identify hash value sv ,
And then keep the additional message into the reserved fields of the GENERATE AC.
After the merchant receives information send by the user, the merchant can decrypt the cipher text form the user and get Req, ATC, SDAD, β and μ by using TK. Then the merchant can decrypt μ and get β, φ, wb, wb+c, counter, IDMg by public key of issuer PKemv.After that, the merchant can follow the below steps to verify whether the users’ information is correct:
(1) Use the public key of the credit card PKemv to verify whether SDAD is correct or not.
(2) Verify whether IDMg is correct or not (3) Check whether off-line certificates expires
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(4) Check whether the counter is less than or equal to n in off-line certificates (5) Verify the correctness of wb by checking whether hc(wb)is equal to wb+c To complete the transaction if the above steps are all correct.
3.1.3.3 Merchant Payout Request Stage
In this stage, the merchant deliver the parameters obtained in the transaction stage back to the users’ Issuer and apply for the payout request of the transaction, as shown in Figure 6 and 7.
Figure 6. Flow chart of the merchant payout request stage
Figure 7. Contents of the merchant payout request stage
‧
The merchant sends the β, μ back to Issuer for verification, and Issuer can verify the content after encrypting the β and μ by Kβ, PKemv. Issuer calculates the value in the off-line certificate, β in the wn and the random number Rlim sent by the merchant, so as to confirm whether the merchant name is in the list M, and will check whether the user consumption balance exceeds n.
If all the above is correct, Issuer will transfer money to the merchant Issuer account.
3.1.4 Security Features
He et al. [33] claimed that this protocol would be able to achieve the following security:
1. Verifiability: In the transaction stage and payout request stage, the merchant and Issuer can verify all messages to ensure the correctness of the transaction
2. Resistance to forgery: In the application stage, the users’ hash chains will all be signed with Issuer's private key to ensure that they are the hash chains sent by Issuer;
when the user send information to the merchant in the transaction stage, they are all signed by the private key of the credit card. After the merchant confirms it, they will request the payout to Issuer. If the user uses fake amount, it will be found.
3. Resistance to tampering: In the application stage, the message sent by Issuer and the user will all use a shared key and a public-key of credit card for encryption and protection; the hash chain will be signed by Issuer’s private key. Fake hash chain cannot be verified and will fail; the verification information given to the merchant should be signed by a private key of the credit card, and the private key is stored in the SE, if the users’ phone is infected with malicious software, the malicious software cannot read the content in the SE.
‧
4 Resistance to replay attack: Issuer will put a random number in the protocol, and after receipt of the payout request, Issuer will verify whether these random number is the same as the random number sent at the beginning.
5. Non-repudiation: In the transaction stage, the user will use the private key to sign the information that is sent to the merchant to ensure that it is given out by the user; in the payout request stage, the corresponding hash value of a unknown merchant will be put into the verification message given to Issuer to confirm whether the quota is used by this merchant.
6. Resistance to repeated consumption: Set up a rule in the SE of the users’ mobile phone so that the counter value is forced to increase after each transaction, and this counter value must be lower than the transaction quota that the user applies for. If the user reuses the quota hash value, the counter value will still be forced to increase.
3.1.5 Protocol Discussion
In the protocol proposed by He et al. [33], the off-line certificate that the user apply for will be passed over from the merchant, to the user and finally to the SE. If the merchant modifies users’ off-line certificates, the user cannot know whether the problem is from Issuer or the merchant even after the certificate is verified through
Moreover, malicious users also have the opportunity to modify the information during
‧
cards and private key, so that SE information may has the risks of being modified, for example, after receiving Lim, SE will store the limit value b of the users’ credit card.At this moment, if someone uses private key of the credit card to modify Lim and also modify the limit of b to be higher and then put the modified Lim back to SE. SE will just store it without being able to distinguish whether the Lim has been modified or not. Besides, the user can also know the content value of the hash chain.
In addition, in the process of consumption, as the merchant can only judge the correctness of the hash chain and the SE can only judge the consumption amount, so if the user adopts the used hash chain to do the verification with the merchant, the merchant will not be able to detect that hash chain has been consumed and will receive it, thus causing the double spending problem. If the user modifies the Datacdol consumption amount to 1, the consumption amount can thus be modified, and the SE will be cheated on as if the transaction amount is 1. At this moment, the user can pass the transaction if he sends the correct length of the known hash chain content back to the merchant.