(*) This paper reports on work done at the IBM Zurich Research Laboratory, Ruschlikon, Switzerland.

Abstract

Existing payment smartcards developed for traditional point-of-sale transactions are being considered for use in Internet transactions. Such solutions have been suggested as alternatives to using payment protocols more specifically designed for Internet payments (such as SET  [8]) but often lacking smartcard support. In this paper, we analyze EMVā96  [7], a representative example of an existing payment smartcard specification. We investigate which security requirements for an Internet payment system can and cannot be met when using EMV for Internet payments. We suggest possible modifications that can enhance the security of an Internet payment scheme based on EMV.

1. Introduction

The lack of portability of Internet-specific systems such as SET has caused the payment industry to look at the possibility of using existing debit and credit payment smartcards for Internet payments. A standard in this area is the EMVā96 Specification  [7] , which describes the functionality required by such smartcard-based payment systems.

The objective of this paper is to discuss the potentials and restrictions of using EMV payment cards for debit and credit payments over the Internet. In Section 2 we formulate a set of general security requirements for smartcard-based debit and credit Internet payments. After summarizing EMVā96 security mechanisms in Section 3, we analyze in Section 4 the security properties of using EMV Īas isā for Internet payments, by checking the resulting protocols against the formulated requirements. Since the Internet scenario differs from the scenario assumed by EMVā96, these protocols exhibit a number of vulnerabilities. In Section 5, we finally discuss possible mechanisms to increase the security of using EMV in the Internet scenario.

2. Model and Security Requirements for Smartcard Internet Payments

Customer and merchant communicate over an open network (the Internet) with each other and with their banks (issuing bank and acquiring bank, respectively).

During a transaction, actual connectivity may be limited to certain subsets of players. In a typical online purchase scenario, the customer only has a connection to the merchant, and communicates indirectly with his issuing bank (e.g., through an authorization message sent to the merchant and forwarded by the merchant to acquiring and issuing banks). The underlying communication model, however, does not influence the security requirements stated in the following.

Before formulating security requirements for a payment transaction, we need to make a number of assumptions about trust relations and liability distributions between the parties involved:
 

• The correct transaction data are displayed;
• Secret data such as a PIN-code entered by the user is not exposed or intercepted.

A number of requirements deal with proof of authorization of the transaction by an authorizing party to a verifying party. This is achieved by an authorization message containing a non-forgeable cryptographic proof of authentication by the authorizing party of critical transaction-related data, satisfying the following properties:

• The verifying party can verify authenticity and integrity of the critical data in the authorization message, and can verify that the data originated from the authorizing party;
• The message cannot be used to authorize another transaction (non-replayable); nor can it be used in any other way by an attacker to falsely authorize another transaction on behalf of the customer. The last requirement applies to schemes where secret authorization data (such as a PIN) is sent to the bank for verification. In such cases, this requirement translates into the requirement that this data be confidentiality-protected (encrypted) during transfer from card to bank.

1. Authorization of the transaction by the bank;
2. Authorization of the transaction by the customer, where the bank guarantees customer-approved transactions (see assumption A3).

1. Explicit payment receipt from the merchant;
2. Payment receipt from the bank.

3. Security Mechanisms Provided by EMV

Figure 2 shows the general EMV POS scenario of an IC (Integrated Circuit) terminal interacting with an IC card, with the human user presenting the card, and with the bank. (The actual EMV functionality for authorizing transactions resides with the issuing bank. In this analysis, we make abstraction of the distinction between the issuing bank and the merchantās acquiring bank. )

• Terminal-card interaction consists of EMV commands issued by the terminal and responses by the card;
• Interaction between terminal and bank consists of the exchange of authorization requests and responses, often over a telephone connection;
• Interaction between terminal and human user consists of output to the user via the terminal display, and input by the user authorizing the transaction (such as a PIN-code).

• Asymmetric security mechanisms authenticate the card as a valid card to the terminal;
• Symmetric security mechanisms generate and verify transaction cryptograms (essentially Message Authentication Codes, MACs) based on a key k shared between card and (issuer) bank.

Figure 3. Model EMV Transaction Flow
 

3.1. Public-key based authentication of IC card to IC terminal

For cards without digital signature capability, EMV also provides the Static Data Authentication mechanism using static card data signed by the Issuer.

3.2 Cardholder Verification

3.3. Shared-key based application cryptograms and off- or online processing

ARQC, TC and IAD are authenticated using MACs (Message Authentication Codes). These are generated by 64-bit block ciphers using a session key k derived from a master key shared by the card and the issuer. The issuer can verify both ARQC and TC; in the online case the card verifies the IAD in the second GENERATE_AC command and thereby authenticates the issuerās response. The terminal triggers the generation and verification of these cryptograms but cannot verify them.

4. EMV Payments in the Internet Scenario

The scenario (Figure 4) depicts a customer using his or her EMV card for online purchases from a PC that has a card acceptance device (reader) attached to it. The merchant still acts as the EMV terminal, issuing and receiving EMV commands and responses, but now communicates with customer and bank over the Internet.

PIN verification deserves some special attention. While, in the POS scenario, the terminal secures the transaction by making sure the PIN is verified correctly (by card or bank), PIN verification in an Internet setting can and should no longer be controlled by the merchant:

1. Online PIN verification now requires the PIN to be sent from card to merchant to bank over insecure Internet connections. Even when encrypting (e.g., using SSL  [5] ) communication, the PIN appears in clear in the merchantās software, which is too high an exposure.
2. Even offline PIN verification (using VERIFY) can no longer be controlled by the merchant:

• requiring VERIFY (including the PIN) to be issued by the merchant assumes the PIN first to be sent to the merchant over an Internet connection (and unnecessarily expose it);
• furthermore, the merchant doesnāt gain any security from the VERIFY result since it is not authenticated, and when received over the Internet, doesnāt guarantee to the merchant that this was the PIN verification result produced by the card (or, stronger, that the card ever executed the VERIFY command!)

• Only the offline PIN authentication mechanism (VERIFY by the card) to be used;
• The VERIFY command to be issued locally (at the cardholder terminal); and
• The card to actually enforce cardholder verification by only issuing ARQC/TC after a successful VERIFY. This is currently not an explicit condition in the EMV specifications; but since in our scenario, neither merchant nor bank can enforce cardholder verification, we now have to make this an explicit condition.

 Figure 5. On-and offline Internet EMV scenarios

In the following paragraph we analyze the security of these two scenarios by checking them against the security requirements defined in Section 2. Table 1 also summarizes the results of this analysis.

1. Authorization customer to bank. In both scenarios the transaction is weakly authorized to the bank by the customer who generates an ARQC and a TC using a key shared with the issuer.
2. Authorization merchant to bank. The merchant does not explicitly authorize the transaction in the above protocols; there is only an implicit authorization by asking the bank for an authorization (by sending ARQC) or clearing of the payment (by sending TC).
3. Payment guarantee for merchant. In both protocols the merchant does not obtain a sufficient guarantee for the payment which is desirable before delivering goods. The merchant neither receives an authorization of the transaction by the bank nor by the customer because it cannot verify any of TC, ARQC, or IAD.
4. Authentication and certification of merchant to customer. EMV does not provide mechanisms to authenticate the terminal and to certify the merchant. The merchantās terminal identifier TermID is included in both ARQC and IAD such that the customer does have a guarantee that only a merchant with the TermID in the ARQC can claim the payment. However, the customer has no way of linking the TermID to the merchant s/he thinks the payment is made to, such that merchant impersonation attacks cannot be excluded.
5. Payment receipt for customer. The evaluation of protocols with regard to this requirement depends on the definition of valid payments and the contract between the customer and the issuer (see A3 and A4). In the offline scenario the customer does not get any authenticated proof of the payment. In the online case, one might consider the IAD as a payment receipt from the bank. This assumes, in turn, that the bankās authorization response completes the payment and that the merchant can consider the ARQC together with the IAD as a guarantee for payment. This is unlikely since the merchant can neither verify the ARQC nor the IAD.
6. Atomicity of payments. Atomicity of payments is provided in both protocols based on assumption A2 that money transfers between accounts are traceable.
7. Privacy, anonymity are not supported: EMV does not encrypt transaction data on the card-terminal channel, and the constant customer identification is present in the data read from the card. Privacy and anonymity issues are not further analyzed in the following.
8. Cardholder authorization. Based on assumption A5, this is achieved when using card-enforced PIN verification as recommended earlier in this section. Note that local PIN Verification in Figure 5 is shown to occur just before the card generates the ARQC; however it may be performed in an earlier stage (as long as the user is made aware of and agrees with the transaction data at the moment s/he enters the PIN).

The results of the analysis in Table 1 show a majority of unsatisfied requirements (N) without a distinction between offline and online scenarios. This is a result of the EMV specifications being developed for the POS scenario where the EMV terminal is under some control by the merchant (sometimes also bank), the purchase is performed face-to-face and merchant and bank communicate over secure connections. We shortly list and illustrate these assumptions.

1. A (physically) immediate and secure channel is assumed between card and terminal:

• No tools for secure messaging between card and terminal are provided;
• The result of PIN verification cannot be authenticated by the terminal;
• Terminal applications rely upon correctness and integrity of other data returned by the card (e.g., static data authentication, risk management data).

1. A secure channel is assumed between terminal and bank:

• no tools for secure messaging between terminal and bank are provided (e.g., online authorization messages are not authenticated between them).

1. The merchant is assumed to trust the bank:

• the terminal cannot verify Application Cryptograms (ARQC, TC) or IAD.

1. The bank is assumed to trust the terminal to deliver messages to the card:

• some security mechanisms rely upon the delivery of issuer messages to the card by the terminal (e.g. command scripts in the authorization response).

1. The terminal is assumed not to be counterfeitable and not to be illegally manipulatable:

• there is no explicit mechanism to authenticate the terminal to the card;
• the terminal does not explicitly authorize/sign any part of the transaction;
• the card does not obtain a payment receipt from the terminal.

1. The purchase is assumed to be performed face-to-face:

• merchant authentication is not in the scope of EMV;
• a guarantee for the delivery of goods is out of the scope of EMV;
• a description of goods is not part of the transaction data.

1. It is assumed that the physical presence of the same card is verifiable during the transaction:

• different parts of the transaction protocol are not explicitly linked;
• there is no mechanism for the terminal to verify that the same card is used for different parts of the protocol (e.g. DDA, ARQC generation, TC generation).

4.1. No payment guarantee for the merchant

• No bank to merchant authorization: Since the merchant cannot verify the bankās authorization response (IAD), an attacker could impersonate the bank to the merchant with an invalid IAD, convincing the merchant the transaction was successful; alternatively, valid transaction data or a valid IAD can be modified during the transaction without the merchant being aware; or, the bank might repudiate the authorization afterwards.
• No customer to merchant authorization: This is especially critical in the offline case because the merchant has to accept a payment without being able to verify the TC. Anyone can make a payment on the cardholderās behalf (though DDA would at least require the fraudster to have the card) or the cardholder can repudiate a payment s/he actually made. Even if a valid TC was issued by the card, it can be modified on the way to the merchant .

4.2. No merchant authorization

4.3 No merchant-to-customer authentication and certification

4.4. No receipt for the customer

Note that within EMV it is impossible to simultaneously provide the merchant with a payment guarantee and the customer with a receipt because one message always has to be sent last. A simultaneous payment guarantee and customer receipt could be provided if the protocol were embedded in some fair-exchange protocol (such as [2]), which is out of the scope of EMV.

5. Mechanisms to Add Security when Using EMV over the Internet

5.1. Securing communication channels

SSL cannot authenticate individual EMV messages, rather it integrity-protects a data stream, which in addition could carry data generated by applications other than EMV. It secures the data using a shared session key which is temporary and cannot be tied to a specific party, except by its communication partner, and then only during the existence of the connection. Obviously, SSL Īauthenticatedā messages or data streams can never have any authenticating value to a third party, regardless of trust assumptions of this third party. (One could of course argue whether this is the case for EMV ARQCs or TCs. But given the assumed tamperproofness of the cards, and possibly certified security of a bankās systems, EMV ARQCs or TCs may be considered by a third party as non-repudiable evidence.)

The authorizing value they have to the receiving party during the connection depends entirely on the receiverās trust in the senderās system and the senderās honesty. In a model where banks and merchants trust each other, this may suffice to add a weak authorization value to EMV messages exchanged between them; less clear is the authorization value for messages exchanged between customer and merchant. Specifically, in the offline scenario, it cannot provide a customer-authorized payment guarantee for the merchant.

Summarizing, we can say that SSL, under certain conditions, can add reasonable security against outsider attacks, but does not provide the authorization of EMV messages necessary to protect against dishonest insiders (or against honest insiders using insecure systems). In the next subsections, we suggest two modifications to EMV which can help towards solving these problems.

5.2. Signed authorization response

where SIGN_I() stands for a signature with message recovery using the (issuer) bankās private signature key. This message can then be verified by the merchant (who already has obtained the issuerās public key during DDA) and can be submitted to the issuer again for final clearing.

The advantages of this extension are:

• This signature provides the merchant with an undeniable payment guarantee. Lack of a payment guarantee for the merchant was a major vulnerability in the above Ībare EMVā protocols (see 4.1).
• The signature prevents the Transaction Data (TD) from being modified during a protocol run without the merchant noticing it. Since the TD is included in the signature the merchant can refuse to deliver the goods if the TD is not correct. This simultaneously weakens the threats incurred by a missing authorization of the merchant to the bank (see 4.2).
• Since the merchant now has a payment guarantee before passing the IAD to the customer, the second GENERATE_AC command may now be considered as a payment receipt for the customer ö assuming at least that the customer gets the IAD from the merchant (and not directly from the bank!) (see 4.4).
• No further keys have to be distributed in addition to the ones already needed for DDA.
• The extension is possible with current cards which support DDA and therefore have stored the issuerās certificate CERT_I. Only slight modifications of the terminal specifications are required to accommodate the increased length of the data fields of the authorization response message.

5.3. Public-key Transaction Certificate (TC)

signed using the cardās private key. A public key-based TC is verifiable by the merchant and can be considered as a payment guarantee depending on contract terms between merchant and acquirer (which may require certain risk management measures by the merchant). A public-key signed TC seems to be a natural extension given that DDA-capable cards already have the signature generation capability. However, in order to support this extension, message formats for cryptogram generation need to be changed, which may have a major impact on the whole EMV infrastructure and poses challenges related to backward compatibility.

Security gains that can be achieved by using a public-key based TC are:

• The merchant receives an undeniable authorization of the transaction by the customer and thus possibly (depending on contracts) a payment guarantee (see 4.1) also without online authorization;
• The transaction data cannot be modified without the merchant noticing it. This denies some of the threats incurred by a missing merchant-to-bank authorization (see 4.2).
• The TC can now also be considered an undeniable authorization customer-to-bank, as opposed to the weak authorization using the shared-key mechanism (see R1).

5.4. Merchant authentication

6. Related Work

7. Conclusion

The most challenging is the EMV offline scenario, where only the use of a public-key based Transaction Certificate provides appropriate security to the merchant. This scenario is particularly important if EMVā96 is used for purse (e-cash) applications.

Online EMV authorization in an Internet setting, though currently insecure because of merchant as well as bank impersonation attacks, can be made more secure by digitally signing authorization requests and responses. Lack of initial authentication and certification of the merchant to the customer is a vulnerability only to be solved by extending the EMV infrastructure with terminal-to-card (alternatively, terminal-to-reader or terminal-to-userās PC) dynamic authentication. In the absence of terminal authentication, software-based mechanisms (e.g. SSL server-to-client authentication) can be put in place to thwart the biggest risks of outsider attacks.

8. Acknowledgment

9. References