One-Time Code Cardholder Veri(cid:28)cation Method in Electronic Funds Transfer Transactions

(cid:21) Card payments are getting more and more popular across the world. The dominant standard used for Electronic Funds Transfer transaction is EMV. It is widely used across Europe and Canada, and currently it is being introduced in the USA. The most frequently used Cardholder Veri(cid:28)cation Method in EMV transaction is PIN, which requires from the payment terminal to be equipped with pinpad which increases the cost of the whole payment device. In this article I present an alternative Cardholder Veri(cid:28)cation Method (CVM) that can be used instead of traditional PIN. The key advantage of the presented mechanism is that it can be easily implemented in currently utilized authorization protocols, it does not a(cid:27)ect rules of EMV speci(cid:28)cation and may decrease time of transaction processing.


Introduction
Smart cards have almost completely replaced traditional magstripe cards, but not in the USA. Magstripe cards are still very popular there, which has direct impact on level of frauds. It is the only region in the world, where volume of counterfeit card frauds is constantly growing []. Because of this kind of frauds, the USA issuers accounted for over 26% of global fraud losses in 2013. This is the main reason why there is very high pressure from banks to introduce EMV in the USA. As we can imagine, the whole process will be very costly, so there are still contentious discussions how to make this transition and how the technology standard will be implemented in the PoS (Point of Sale) [ ]. There are several obstacles to be overcome. Americans are used to making the transactions with the magstripe card veried by signature, and probably it will be hard for them to get used to paying by chip card and entering the PIN 2 Payment System Architecture The standard four-party card scheme is depicted in Fig. 1. Each party can be described as follows: Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 20/05/2022 12:37:21 U M C S 48 One-Time Code Cardholder Verication Method in Electronic...
• Cardholder a person who wants to buy some goods or services and pays by card, • Merchant a person who sells goods or services and operates payment terminal to accept card transactions, • Acquirer an institution that processes payment transaction. It is forwarding the authorization request to the Issuer and sends authorization response back to the terminal, • Issuer its an institution (bank) that issued the Cardholders card. After receiving the authorization request, it checks if the transaction can be authorized by checking cardholders account balance and (in the case of EMV transaction) by validating transaction cryptogram generated by the card. It also generates the authorization response and sends it back to the Acquirer.
There are also some fees that are charged from the transaction amount:

Authorization Protocols
The authorization protocol is used in order to communicate between Merchants terminal and Acquirer. It is mainly used for: • Exchanging authorization requests, • Performing settlement usually at the end of day, • Performing network diagnostics, • Transferring conguration to the terminal. For instance, the most popular authorization protocol in Poland is ISO 8583. Its customized versions are used for example by: • Elavon one of the most popular acquirer in Europe and USA • eService the biggest Polish acquirer, currently exploring European countries Short description of this protocol can be found in Section 3.1. The other, known for the author, authorization protocols are: • SPDH used for example by FirstData Poland, • EP2 the most popular protocol in Swiss and neighboring countries, used for example by SIX Payments Services.

EMV Security Mechanisms
The EMV standard (named after Europay, Visa and MasterCard) introduced many security mechanisms that rapidly decreased volume of fraudulent transactions. In fact, the goal of introducing EMV was to shift the costs of dispute from the issuing bank in the following way: • If a disputed transaction has been authorized by a signature, it would be charged to the merchant, • If a disputed transaction has been authorized by a PIN then it would be charged to the customer.
It other words, the banking industry, which designed the whole system, carries less liability for the fraud. This is also called the liability shift [$].

EMV Transaction Steps
Each EMV transaction consists of several processing steps: • Application Selection each smart card can have a few payment applications available. Application may be selected manually by the cardholder from the displayed list, or may be selected automatically by the terminal the decision is made based on priorities assigned to each application, • Application Initialization the terminal sends certain information to the card in order to decide if transaction processing should be continued. If yes, then the card responds to its processing capabilities (AIP) and application le location (AFL), indicating from where to read application data, • Application Data Read in this step the terminal reads application data from location pointed by AFL. The terminal retrieves all data necessary to perform payment transaction. Card controls data that can be read for example it is not possible to read PIN value. In other words it is not possible to clone a smart card • Card Data Authentication this step is intended to verify if the presented card in not a counterfeit one. All possible methods to be performed in this step were described in Section 4.2, • Processing Restrictions the terminal checks if the requested service is allowed, if the application has not expired etc., • Cardholder Verication the terminal veries if the person who presents the card is the genuine cardholder. The whole Cardholder Verication step is described in detail in Section 4.3, • Card Action Analysis in this step the card performs its own issuer specic analysis. The card can change the terminal decision only to a stricter one. The card decision is indicated by the type of cryptogram generated in response for GENERATE AC command, • Online Processing this step is performed only if the generated cryptogram was Authorization Request Cryptogram (ARQC). In that case the generated cryptogram is sent to the issuer host for authorization. The issuer sends back its Authorization Response Cryptogram (ARPC) which is forwarded to the card in order to make a nal authorization decision. Even if the host authorized the transaction, the card can decline it if it failed to authenticate the received cryptogram, • Issuer Script Processing this step is optional and is performed only when the issuer sends its script with the authorization response. Such scripts allow to update the card data, for example unlock or change the PIN code, block the card etc. As can be seen, the EMV standard species a lot of security mechanisms that drive transaction processing in a certain way. The whole Risk Management and the Action Analysis procedures are performed on the terminal and card side, so only a few context factors can be taken into account. The presented approach assumes that the key Risk Management processing is performed on the issuer host side, so a lot of context factors can be freely analyzed and a more accurate decision can be made. cards are not able to perform the RSA calculation, so they are cheap, but this type of cards is vulnerable to a trivial and well-known replay attack in which the certicate is read from a card and written to a counterfeit one (these are often called yes cards because they will respond yes to any entered PIN during the PIN verication phase) [$], • DDA Dynamic Data Authentication in this method the terminal veries a dynamic digital signature generated by the card over the unpredictable number sent by the terminal. As this algorithm is dynamic, it is better than SDA but it also requires that the card has an RSA private key along with the RSA processing capability so those cards are more expensive than the SDA ones [%], • CDA -Combined Data Authentication -this method can be performed on the cards supporting DDA, and assumes that the terminal veries a digital signature computed by the card over the full transaction data (including the symmetric cryptogram that can be veried by the issuer). CDA is better than DDA because CDA protects against the use of so-called wedges that, if undetected, could fraudulently modify the transaction data exchanged between the card and the terminal.

Cardholder Verication Method
During the EMV card personalization each card is equipped with the so-called CVM List. This list presents the issue choice of supported CVMs ordered by priority. This list also indicates what should happen if this failed to perform the current CVM method to go to the next CVM from the list, to decline the transaction etc. Because dierent types of terminals support dierent CVMs, multiple CVMs enable the EMV card to be accepted at as many merchant terminals as possible. The card and the terminal use the rst matching CVM type for transaction authorization [&].
There are a few possible Cardholder Verication Methods dened by the EMV standard: the unique key, a few key management schemes like DUKPT [9] or Master/Session have been proposed. There are also proprietary key management schemes like for example in EP2 [10], • Signature This Cardholder Verication Method is performed always after online of oine authorization. In this case the merchant veries if the signature on the transaction receipt matches that on the card. If the merchant arms that the signature is not valid, the automatic reversal for the current transaction is generated and the decline receipt is printed on the terminal. This CVM method can be only performed on the attended terminals, • NoCVM in this case, the transaction is authorized without the PIN or the signature. It is usually utilized for low-amount transactions, and it is the fastest way to complete the transaction. As mentioned before, Cardholder Verication Method during the EMV transaction is agreed by the terminal in cooperation with the card. In the EMV terminal conguration there is a special parameter called the CVM limit. This parameter indicates the amount of transaction above which it cannot be authorized with NoCVM. In particular, if this parameter is set to 0, every transaction will require a kind of PIN or signature. There are also terminals (usually unattended ones) that require NoCVM for every transaction because they are not equipped with pinpad and there is no merchant to validate the signature.

Non implemented Cardholder Verication Methods Recently researchers
have focused on introducing the biometric-based Cardholder Verication Methods [15,16]. As smart cards are getting more and more powerful such approach is quite reasonable. Those methods assume that during the Cardholder Verication step some biometric data will be gathered from the Cardholder, converted to a special format and sent to the card for validation. The following biometric information can be veried: Unfortunately, none of those Cardholder Verication Methods have been implemented in real payment system. This can happen because of high costs of biometric devices.

Attacks on EMV Security
In 2010 a group of researchers from Cambridge proved that stolen cards can be successfully used without knowing PIN code [6]. It can happen only when Oine PIN is used. In that case after PIN is entered, the Verify command is sent to the card. Card simply responds with OK or NOK answer, that is not tied to any data nor secured Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 20/05/2022 12:37:21 U M C S by any signature. An attack assumes that the whole communication between the card and the terminal is routed via the proxy device that blocks the Verify command and always responds with OK to the terminal. In that situation the terminal thinks that Oine PIN was performed, and the card thinks that NoCVM was forced.
Another interesting attack was proposed by Adam Laurie, Andrea Barisani, Daniele Bianco and Zac Franken and it is called the CVM Downgrade attack []. This attack assumes that the CVM List sent by the card is changed by the proxy device in order to force the Oine PIN verication. Such change may cause Oine Data Authentication to fail, but they proved that it may not lead to decline the transaction (because they have also changed IAC Issuer Action Codes ). Moreover, in most cases such modied transaction will be successfully authorized by the Issuer.

Proposed Solution
Nowadays almost everyone has its own mobile phone and always carries it in his pocket. Mobile phones are used not only for texting and voice call, but also for example for authentication. One time passwords sent via SMS or generated from the dedicated application are currently very frequently used for conrmation of online fund transfers. The presented approach assumes that the transaction is conrmed by entering one time code if the issuers system decides to perform Customer Verication. The whole diagram of transaction that involves the new Context-based Cardholder Verication Method is depicted in Fig. 3.
The transaction ow can be described as follows: • Payment terminal is congured to accept only NoCVM transactions, • After the amount and card entry steps, the transaction process regarding the NoCVM rules. The results of such processing can be: Oine Approved Transaction Certicate (TC) has been generated by the card, Oine Decline -Application Authentication Cryptogram (AAC) has been generated by the card, Request for online authorization Authorization Request Cryptogram (ARQC) has been generated by the card, • Let us assume that the card requested for online authorization. In that case Authorization Request is generated by the terminal and sent via the Acquirer to the Issuer, In the presented approach the processed transaction is fully compliant with the EMV standard, it means that: • Card authentication is veried, • In the case of Contact EMV card, the issuer authentication is veried. Moreover, our approach is not prone to attacks described in chapter 5.3 because: • It prevents from using Oine PIN, • It utilizes the less secure CVM dened by EMV, so the CVM List downgrade attack is not applicable.
The behaviour of payment terminal during one time code verication will be similar to that during the signature check, it means that: • If one time code is invalid, then the transaction is automatically declined, • If there is a cut in the power supply on one time code verication step, the non-veried transaction will be automatically reversed just after the next terminal boot.
What is more, the signature verication is prone to accidental acceptance (because there is only simple question: Is signature valid? with possible answers YES or NO). In our approach, one time code is only known by the terminal application, so the only way to accept the transaction is to enter valid one time code. Also communication between the terminal and the Acquirer is secured usually with TLS, so there is no chance to eavesdrop on one time code during the transmission.
Paradoxically, our solution can increase security of low-amount transactions. Due to the fact that the decision about CVM is made by the Issuer, fraudulent transactions can be revealed earlier and CVM can be requested also for low-amount transaction which is not possible in the standard EMV approach.
One time code can be delivered to the Cardholders device for example via: • SMS, • Dedicated application that will download one time code from the Issuers server, • Dedicated application that will generate RSA tokens. In order to unlock mobile device usually there is a need to enter PIN code, draw special pattern on the screen and so on. Because of that, in the case of stolen or lost device, the security of the whole solution still holds high level. We must consider that in such cases fraudulent transactions are possible only till the Cardholder blocks his card. The key thing in introducing any change in such big systems as Payment Systems is to utilize as many present mechanisms as it is possible. Introducing any big change does not make sense because it will be not protable and will take a lot of time to rollout. In this paper I presented the new Context-based Cardholder Verication Method which can be easily adapted to the present Payment Systems and it utilizes mechanisms provided by EMV specication. What is more, the presented CVM reduces costs of payment devices (because it does not use a pinpad) which could be a real accelerator for rollouts in new countries like the USA. Thanks to the risk management algorithm running on the Issuer side, there is possibility to optimize the transaction processing time ask for CVM only if there is real need to do so. The decision about CVM will be made based on transaction context, so the result will be accurate.
Moreover, contrary to signature verication, the presented Cardholder Verication Method can be used in unattended solutions, which are getting more and more popular across the world. Such solutions are exposed to acts of vandalisms and hard weather conditions, so in fact they are more expensive than the attended ones. Utilizing the presented CVM method can also reduce price of unattended devices.
The next step in the future research could be design and validation of the risk management algorithm running on the Issuer side. It is also worth to prove, that currently congured in the payment terminals CVM limit (equal to 50 PLN in Poland) could be easily increased without major impact on the transaction security. Such approach could allow to reduce average transaction processing time diametrically, because large majority of authorized transactions have the amount less than 100 PLN.
Another interesting topic for future research could be deployment of one time codes.