• 沒有找到結果。

Updating virtual credit card and optional virtual transaction account stage…40

Chapter 4 Our new NFC-based anonymous mobile payment protocol

4.5 Updating virtual credit card and optional virtual transaction account stage…40

4.5 Updating virtual credit card and optional virtual transaction account stage

The detail is shown as Figure 4.4, the goal of the stage is that user will request a new virtual credit card to bank through TSM when the expiry date is coming or the remained limit is exhausted. Besides, if user desires, user can change the virtual transaction account TID in this stage. Through the change of TID, merchants or the others cannot trace the user’s identity. The detailed description is listed as below:

(1) IDU: (XU´, TIDU´)

User generates a new random number XU´. If user wants to change his virtual transaction account, he will also generate a new virtual transaction account TIDU´.

(2) IDU→ IDTSM: (Update-request, TIDU´,𝑆𝑆𝑋𝑋𝑈𝑈) mod p). If user also desires to change a new virtual transaction account, TSM will also generate a new expiry date (TIDU_Extime´) and a new credit limit (TIDU_Limit´). Besides, TSM will re-issue a virtual credit card, it and its corresponding information are called

Credit_INFO'. TSM will also record the relation between TIDU and PAN of new card.

(4) IDTSM→ IDU: (𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇′, Credit_INFO´, TIDU_Extime´, TIDU_Limit´)

After receiving the new credit card. TSM delivers the encrypted message 𝐶𝐶𝑆𝑆𝑇𝑇𝑇𝑇𝑇𝑇"𝑈𝑈"(IDTSM||

AIDU||(TIDU´||TIDU_Extime´||TIDU_Limit´)||𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇||Credit_INFO´||𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑇𝑇𝑇𝑇𝑇𝑇(IDTSM||AIDU||(T

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

41

IDU´||TIDU_Extime´||TIDU_Limit´)||𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇||Credit_INFO´)) and 𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇 to user.

(7) IDU: (𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇′, Credit_INFO´, TIDU_Extime´, TIDU_Limit´)

User computes the session key KTSM´´U´´ by parameter 𝑆𝑆𝑌𝑌𝑇𝑇𝑇𝑇𝑇𝑇. User uses the session key to decrypt the encrypted message and obtains the content inside the message.

(8) IDU→ SE: (KTSM´´U´´, Credit_INFO´, TIDU_Extime´, TIDU_Limit´)

User delivers the necessary security parameters which includes new virtual credit card

(Credit_INFO´), new session key (KTSM´´U´´), new expiry date (TIDU_Extime´) and new credit limit (TIDU_Limit´) to SE.

(7) The following transaction processes comply with the EMV standard and the NFC-chip has to be set to card emulation mode.

Figure 4.4 Updating virtual credit card and optional virtual transaction account stage

4.6 The compatibility between protocol and EMV standard

In this section, we describe the related process which is relevant to our protocol in brief.

Each credit card has its own card number, we call it personal account number (PAN). In the transaction process which uses the virtual credit card, the user (cardholder) will deliver the PAN or token to merchant in different situations. Therefore, user needs to get token before the beginning of transaction. The other role of merchant is the token requestor which is responsible for applying for the token to the token service provider (TSP), and token requestor asks TSP to issue the token to replace the PAN. TSP is an entity which is responsible for providing tokens to registered token requestors, it also records the related information about the token requestor and PAN. For confirming the data which is sent with the request from token requestor to TSP, TSP will send a request to the bank which is related to user’s credit card to verify the correctness of data. After verifying successfully, TSP will generate a token and the corresponding token requestor ID, and sends them to token requestor. Besides, TSP will also record the relation between PAN and the token in the table which is called token vault. Moreover, we assume the entity TSM to be the TSP in our protocol.

What we have to pay attention to that PAN doesn’t always need to return to the user (cardholder), it is decided by the type of transaction. But we assume it is sent to user in our protocol. So far, the payment token provision step is done. In other words, user has own the token. The detail is shown as Figure 4.5.

According to the content of EMV standard [8], the data which is used during credit card transaction is listed in the parameter Dataemv = {PAN, EX_DATE, CDOL1, CDOL2…} [18].

EX_DATE (Expiry date) and CDOL (Card risk management Data Object List) are the necessary parameters which we can’t discuss here, but our key parameter is PAN. In our

protocol, we assume our PAN of virtual credit card to be the role of token and TIDU to be the role of PAN before transforming. The diagram is shown as Figure 4.7.

When user uses the virtual credit card, merchant will verify the information of credit card. The PAN of virtual credit card (=token) will be delivered to merchant, and it will be pass through Acquirer (the bank of merchant’s side) into local financial network. Then it enters the payment network, network will pass it to TSP (=TSM). TSP (=TSM) will search the token vault and return the corresponding TIDU to payment network if token existed in the table. If there are other information which needs to verify from the issuer (the bank of user’s side). TSP (=TSM) will send the information to issuer for verifying. After the

authentication of issuer, payment network will return the result about this transaction through Acquirer to merchant and user (cardholder). Then the verification step of merchant will finish. The detail is shown as Figure 4.6. Then the transaction is finished.

The detailed instruction step and parameters transmission describe below:

(1) At the beginning of the transaction, user’s cellphone and a reader of merchant have to authenticate and communicate with each other. The diagram is shown as Figure 4.8.

First, merchant will send the SELECT instruction to user to request the chosen type of credit card. User will return the chosen type of credit card and the File Control

Information (FCI) for continued message. The content of FCI= {type}. The parameter type shows the chosen type of credit and the format of message of FCI, and it is also the mandatory parameter in FCI in EMV standard.

(2) After receiving the FCI, merchant will use a GET PROCESSING OPTIONS instruction to send the certification of merchant (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎) to user. Then, user uses the public key (PKacq) to verify the certification (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎). If certification is correctly, then user’s cellphone will do the following steps:

𝐶𝐶𝑃𝑃𝑆𝑆𝑇𝑇𝑇𝑇𝑇𝑇(PAN))) into the first location which is pointed by the AFL (Application File

Locator).

• User will return parameters AFL and AIP (Application Interchange Profile) to merchant. AFL is a list which is recorded needed files and records used in the authentication and transaction process. AIP is also a list which specifies the application functions which are available in the transaction.

If verification of certifications is wrong, then it terminates the process.

(3) Merchant uses a GET DATA instruction to get the value ATC from user

(4) When merchant received ATC, it will send an READ RECORD instruction which includes the first reading address in AFL to user. User will fetch the parameters which is

computed in the above step, and return it to merchant. After receiving it, merchant will decrypt 𝐶𝐶𝑃𝑃𝑆𝑆𝑚𝑚(SU) and compute a session key TK. Then, merchant uses it to decrypt the ETK (IDTSP||𝐶𝐶𝑃𝑃𝑆𝑆𝑇𝑇𝑇𝑇𝑇𝑇(PAN)||H (IDTSP||𝐶𝐶𝑃𝑃𝑆𝑆𝑇𝑇𝑇𝑇𝑇𝑇(PAN))) and send the cipher text inside it to TSP (=TSM) through IDTSP. TSP (=TSM) will verify PAN and return ResTSP to represent the result of verification. If verification fails, then it terminates the process. Otherwise, merchant computes the response Resm= 𝐶𝐶𝑆𝑆𝑆𝑆𝑚𝑚(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎||ResTSP||SU||ATC)

(5) Merchant sends the response Resm to user by a VERIFY instruction. After receiving it, user verifies the content of response. If verification failed, user will set ACK=fail and terminate the process. Otherwise, user will compute response ResU=ETK (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎||SU||

ResTSP+1||ATC). Then, user will put ResU into the second location which is pointed by

ACK=success and return ACK to merchant. ACK is a parameter represent the result of verification

(6) If ACK is equal to success, merchant sends a READ RECORD instruction which includes the second reading address in AFL to user. Then user returns ResU to merchant, and merchant will verify the content of ResU. If verification fails, then it terminates the process. Otherwise, merchant will send a READ RECORD instruction which includes the third reading address in AFL to user. Afterwards, user returns ETK (Dataemv) to merchant. Merchant decrypts message to get needed information (PAN) inside Dataemv. (7) Following the above flow, one who needs the token into Dataemv uses a READ RECORD

instruction to request the front one who owns the parameter Dataemv to return it. Besides, these transmissions which are located after the merchant in the flow are inside financial network which has the highly secure property. Therefore, we return a parameter Dataemv

directly without encryption. The detail of transaction process is shown as Figure 4.9.

In this figure, we only change the original verification parameter SDAD (Signed Dynamic Application Data), because there is no key-pair in user’s side in our assumption. We use a session key TK to encrypt verification message for the use in process.

According to [9], there are many possible entities to be the role of TSP (=TSM) in different situations. Therefore, we discuss the situations about (TSP=TSM) and (TSP≠

TSM) separately.

If TSP is equal to TSM as we assumed. In the transaction process, when merchant requests TSM (the issuer of virtual credit card) to pay the bill that user consumed. TSM will transform the PAN of virtual credit card to TIDU according to token vault. Then it sends the corresponding AIDU and payment request to Issuer (bank of user’s side). Issuer will execute

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

46

the money moving from user’s account to the account of bank.

If TSP is not equal to TSM. In the transaction process, when merchant requests TSM to pay the bill that user consumed. TSM will send the PAN of virtual credit card to TSP, then TSP will transform PAN to TIDU and return it to TSM. Then TSM sends the

corresponding AIDU and payment request to Issuer. Issuer will execute the money moving from user’s account to the account of bank.

Figure 4.5 Payment token provision overview [9]

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

47

Figure 4.6 Payment token transaction overview [9]

Figure 4.7 Comparison of token vaults between the original one and the new one

Figure 4.8 Mutual authentication process [44]

User Merchant

Dataemv SKm,𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎

EMV commands

1. Merchant select the application

SELECT 2. FCI= {type}

Receive the result ResTSP from TSP If ResTSP fails, then abort the session Resm=𝐶𝐶𝑆𝑆𝑆𝑆𝑚𝑚(𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎||ResTSP||SU||ATC)

7. Resm

VERIFY If Resm fails, then set ACK=fail; abort the session;

ResU=ETK (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎||SU||ResTSP +1||ATC)

Set ResU and ETK (Dataemv) in expected file locations Set ACK=success

8. ACK READ RECORD 9. ResU

If ResU fails, then abort the session READ RECORD 10. ETK (Dataemv)

Figure 4.9 Transaction process [44]

User Merchant Issuer

TK, SKm, ATC,𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝑚𝑚𝑎𝑎𝑎𝑎𝑎𝑎 K

If user check amount in Datacdol1 fail, then abort the session AC1= MACK (Datacdol1||ATC)

ResData= ETK (Req||AC1||H (Req||AC1||Datacdol1||ATC)) GENERATE AC

11. ETK (Req||ATC||ResData)

DTK (ETK (Req||ATC||ResData)) DTK (ETK (ResData))

If check H (Req||AC1||Datacdol1||ATC) fail, then abort the session 12. Req, Datacdol1, ATC, AC1

if checking MACK (AC1⊕ARC)||ARC fail, set ACK=fail Else set ACK=success

EXTERNAL AUTHENTICATE

15. ETK (ACK)

If ARC =success and ACK=success, Req=TC Else Req= AAC

18. Request, ATC, AC2, Datacdol1, Datacdol2

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

50

相關文件