1. Introduction to the EMV technology

With the growing use of the Internet for commercial transactions, there has been much effort in developing systems and protocols for securing payments on the Internet. A prominent example of such a protocol is the Secure Electronic Transaction protocol. It is, however, not designed with smart-card support in mind. Current implementations require the customer to make SET transactions from a fixed, trusted personal computer. A secure SET implementation on a smart-card for use with public terminals would require the smart-card to store the users account data and cryptographic keys as well as the SET client implementation, which is not feasible with current smart-card technology.
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 smart-cards for Internet payments. A standard in this area is the EMV’96 Specification, which describes the functionality required by such smart-card-based payment systems.

2. Model and Security Requirements for Smart-card Internet Payments

The model of a generic Internet payment system (Figure 1) consists of a customer and a merchant who exchange money for goods or receipts, and at least one financial institution linking electronic payments to the transfer of "real money".


Figure 1. Payment Model.

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 authorisation 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, a number of assumptions about trust relations and liability distributions between the parties involved will be exposed :

• Issuer and acquirer enjoy some degree of mutual trust and share an infrastructure for secure communication. This allows to join their security requirements into "bank" requirements.

• Money transfers between accounts are traceable. This gives the user some assurance of refund in case of fraud by hackers or bank insiders.

• A contract determines the business, trust, responsibility, and liability relationships between the merchant and the bank. The contract especially defines valid payments by specifying the requirements to be fulfilled to provide the merchant with a payment guarantee.

• A contract determines the business, trust, responsibility, and liability relationships between the customer and the issuing bank. The contract defines what the bank considers proofs of payment by the customer and specifies the requirements for liability and disputability.

• The customer can trust critical parts of his or her system to enable secure authorisation of a transaction. In the specific case of the user payment instrument being a smart-card authorising the payment on the user behalf, the user interacts with the card reader (or electronic wallet) by verifying output (e.g., transaction amount, merchant ID) on its display, and by entering data (e.g., PIN-code) on a keyboard or PIN-pad. The user can trust that :

• 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 authorisation of the transaction by an authorising party to a verifying party. This is achieved by an authorisation message containing a non-forgeable cryptographic proof of authentication by the authorising party of critical transaction-related data, satisfying the following properties:

The verifying party can verify authenticity and integrity of the critical data in the authorisation message, and can verify that the data originated from the authorising party.

The message cannot be used to authorise another transaction (non-repayable), it can’t be used in any other way by an attacker to falsely authorise another transaction on behalf of the customer. The last requirement applies to schemes where secret authorisation 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.

A weak proof cannot serve as a proof for third parties while an undeniable proof (based on a digital signature) provides non-repudiation and therefore can be used in the case of disputes.

Based on these notions the following security requirements for a payment protocol can be formulate :

• Authorisation customer to bank. The bank should posses an authorisation for the payment from the customer before it debits a certain amount from the customers account.

• Authorisation merchant to bank. The bank should only authorise a payment to a merchant if the corresponding transaction has been authorised by that merchant.

• Payment guarantee for merchant. Before delivering goods, the merchant should have a payment guarantee. This is achieved by either of :

• Authorisation of the transaction by the bank.

• Authorisation of the transaction by the customer, where the bank guarantees customer-approved transactions.

• Authentication and certification of merchant to customer. The customer should have a minimum of authenticated and certified information about the merchant s/he makes a payment to.

• Payment receipt for customer. After completion of the payment, the customer should possess a proof that the payment was successful. This can either be:

• Explicit payment receipt from the merchant.

• Payment receipt from the bank.

• Atomicity of payments. No party can benefit from an interrupted protocol run.

• Privacy, anonymity. The customer may require privacy of order and payment information and possibly anonymity (from eavesdroppers and eventually from merchants and/or banks).

• Cardholder authorisation. The customers payment system should be protected against unauthorised use. In the case of smart-card-based payments, unauthorised use of the card should be protected against. The customer also needs to trust at least the terminal (or electronic wallet) he is using in conjunction with the smart-card.

3. Security Mechanisms Provided by EMV

This section gives an overview of EMV’96 security mechanisms securing transaction flows. Mechanisms such as card and terminal risk management are not discussed here.

For a detailed description of security mechanisms provided by EMV’96 we refer to.

Figure 2 shows the general EMV POS scenario of an Integrated Circuit terminal interacting with an Integrated Circuit card, with the human user presenting the card, and with the bank. (The actual EMV functionality for authorising transactions resides with the issuing bank. In this analysis, we make abstraction of the distinction between the issuing bank and the merchants 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 authorisation 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 authorising the transaction (such as a PIN-code).

EMV uses both asymmetric (public-key) and symmetric (shared-key) security mechanisms:

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.

The full set of security mechanisms is shown in Figure 3 which is taken from a transaction flow example.

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

The first four messages exchanged implement the Dynamic Data Authentication (DDA) authenticating the card to the terminal using a public-key based challenge-response protocol. The READ_RECORD command returns the necessary Certification Authority (CA) identifier and public-key certificates needed by the terminal to authenticate the cards public key in CERT_C. CERT_C is certified by the issuer and can be verified using the issuers public key in CERT_I, which in turn is certified by the CA and can be verified using the CAS public key known to the terminal. The actual challenge-response authentication is then executed by the terminal issuing an INTERNAL_AUTHENTICATE command containing authentication-related data (ARD), and the card responding with a signature over this data using its private signature key.

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

EMV supports online (PIN sent to and verified by the bank) and offline (PIN verified by the card) PIN verification; the exact method supported by the card is read by the terminal with the initial READ_RECORD. Offline PIN verification is executed by the terminal issuing the VERIFY command, containing the PIN data entered by the user; the cards response indicates success or failure.

The GENERATE_AC command, including Transaction Data (TD), triggers the card to produce a cryptogram that can be verified by the issuer. If both card and terminal agree on completing the transaction offline (based on both entities risk management policies) the card returns a TC (Transaction Certificate) approving the transaction. If either card or terminal want to continue online, the card produces an ARQC (Authorisation Request Cryptogram), which the terminal passes on to the bank in an online authorisation request. If verification is successful, the bank returns an authorisation response message containing Issuer Authentication Data (IAD) and possibly a command script to be delivered to the card. The terminal then issues the second GENERATE_AC command including the IAD and the command script.

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 issuers 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 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 : 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) communication, the PIN appears in clear in the merchants software, which is too high an exposure.

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.

• Authorisation customer to bank. In both scenarios the transaction is weakly authorised to the bank by the customer who generates an ARQC and a TC using a key shared with the issuer.

• Authorisation merchant to bank. The merchant does not explicitly authorise the transaction in the above protocols; there is only an implicit authorisation by asking the bank for an authorisation (by sending ARQC) or clearing of the payment (by sending TC).

• 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 authorisation of the transaction by the bank nor by the customer because it cannot verify any of TC, ARQC, or IAD.

• Authentication and certification of merchant to customer. EMV does not provide mechanisms to authenticate the terminal and to certify the merchant. The merchants 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.

• 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. 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 banks authorisation 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.

• Atomicity of payments. Atomicity of payments is provided in both protocols based on assumption A2 that money transfers between accounts are traceable.

• 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 analysed in the following.

• Cardholder authorisation. 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).

Table 1. Security Analysis of Online and Offline EMV Internet Scenarios

(Y = Requirement Satisfied; N= Requirement Not Satisfied)

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.

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).

A secure channel is assumed between terminal and bank :

• No tools for secure messaging between terminal and bank are provided.

The merchant is assumed to trust the bank :

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

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.

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.

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).

Before discussing mechanisms which can increase the security of using EMV over the Internet, the most important vulnerabilities resulting from the above "N"s are summarise in the table.

This is probably the most serious problem: without a payment guarantee the merchant may lose money when delivering goods which are not paid for afterwards.

No bank to merchant authorisation:

• Since the merchant cannot verify the banks authorisation 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 authorisation afterwards.

No customer to merchant authorisation:

• 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 cardholders behalf or the cardholder can repudiate a payment he actually made.

• Even if a valid TC was issued by the card, it can be modified on the way to the merchant.

The absence of an explicit authorisation of the transaction by the merchant means that an attacker may impersonate a real merchant to both customer and bank, and conduct a successful transaction on behalf of the real merchant who might not even be aware. This vulnerability can be exploited also by dishonest customers and merchants: a merchant can repudiate a transaction afterwards, claiming the above attack scenario has occurred. A dishonest customer may exploit the lack of merchant authorisation by intercepting and modifying the transaction data on the merchant to bank channel. In the attack scenario as well as the dishonest merchant scenario, the customer does not get the ordered goods and has to claim refund while in the last scenario the merchant does not receive the expected payment for possibly delivered goods.

For debit or credit payments the danger for the customer caused by lack of merchant authentication is limited: the customer can only lose money to a legitimate merchant if we assume that the bank only clears payments for legitimate merchants. The absence of a merchant-to-customer (M-C) authentication mostly reinforces the danger caused by the absence of a merchant-to-bank (M-B) authorisation, in the sense that a fully complete, normal and legitimate payment to M can take place without M being involved in any stage of the EMV protocol. On the contrary, a reasonable protection can be achieved if at least one of the two, M-C authentication or M-B authorisation, is provided. Then either the customer or the bank can verify whether M is the merchant corresponding to the TermID in the ARQC or TC. If there is M-B authorisation (at least during clearing), but no M-C authentication then it only remains critical that the customer might communicate with a different merchant than intended.

Not receiving a payment receipt is mainly critical for the customer if he buys goods to conditions which change rapidly (e.g. stocks or shares). Especially in the offline protocol, the customer does not have any proof of having bought something to specified conditions before the actual clearing is performed and he has received his statement of account. This can cause a loss of goods, opportunities, or money to the customer if the merchant denies certain conditions.

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, which is out of the scope of EMV.

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

The protocol vulnerabilities of EMV over the Internet relate to the absence of authorisation of certain messages, and to the absence of authentication and certification of the merchant to the customer.

To the extent that SSL can provide initial authentication between communicating parties and integrity and/or confidentiality protection of the ensuing dialogue, it can provide a reasonable degree of protection against attacks by outsiders, under the condition that all parties involved adequately secure their systems. However, as discussed in the following paragraphs, SSL cannot provide the necessary authorisations we discussed before that are needed to protect parties against dishonest insiders.

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.

The authorising value they have to the receiving party during the connection depends entirely on the receivers trust in the senders system and the senders honesty. In a model where banks and merchants trust each other, this may suffice to add a weak authorisation value to EMV messages exchanged between them. Less clear is the authorisation value for messages exchanged between customer and merchant. Specifically, in the offline scenario, it cannot provide a customer-authorised payment guarantee for the merchant.

Summarising, we can say that SSL, under certain conditions, can add reasonable security against outsider attacks, but does not provide the authorisation of EMV messages necessary to protect against dishonest insiders (or against honest insiders using insecure systems).

In the online scenario, an undeniable payment guarantee for the merchant may be provided by the (issuing) bank signing the authorisation response message with its private signature key. The authorisation response message becomes SIGN_I (Y/N, Transaction Data, IAD) where SIGN_I() stands for a signature with message recovery using the (issuer) banks private signature key. This message can then be verified by the merchant (who already has obtained the issuers 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 EMV protocols.

• 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 authorisation of the merchant to the bank.

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 to assuming at least that the customer gets the IAD from the merchant. 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 issuers certificate CERT_I. Only slight modifications of the terminal specifications are required to accommodate the increased length of the data fields of the authorisation response message.

A disadvantage of the approach as described above is that the issuers private key intended only to certify card public keys is used more often and for other purposes, increasing its exposure. This is critical because the corresponding public key is stored on many cards and therefore hard to replace in case of a compromise.

A solution which combines security and low overhead can be provided by the acquirer signing the authorisation response (as opposed to the issuer). Since the merchant has a long-term relationship with the acquirer, it can be assumed that the acquirers public key is stored permanently by the merchant.

Another proposed change to the EMV specifications is the use of a public-key signature also for TC generation. The TC becomes TC = SIGN_C (TD, [IAD] ) signed using the cards 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 authorisation of the transaction by the customer and thus possibly (depending on contracts) a payment guarantee also without online authorisation.

• The transaction data cannot be modified without the merchant noticing it. This denies some of the threats incurred by a missing merchant-to-bank authorisation.

• The TC can now also be considered an undeniable authorisation customer-to-bank, as opposed to the weak authorisation using the shared-key mechanism.

Changes proposed in 5.2 (online payments only) or 5.3 (especially important for offline payments) can greatly improve the security of the respective EMV-Internet scenarios. Vulnerabilities remain, primarily related to the lack of authentication and authorisation of the merchant to both customer and bank. Closing these holes in a rigorous way by providing merchant authentication in EMV largely impacts the EMV infrastructure which currently does not allow for the storage of secret keys in merchant terminals. However, to the extent that the keys stored need not be system-wide symmetric keys but rather the merchants own private signature key for authentication to bank and/or customer.

Such a change first of all allows the merchant to sign the authorisation request message, providing secure authorisation by the requesting merchant. It also allows merchants to authenticate to the card and to deliver a signed payment receipt to the customer which in the offline case is the only means for the customer to get a receipt (other than an after-the-fact account statement). Since cards with signature verification capability are not likely to be used soon, the signature verification could be done in the trusted card reader (or eventually, in the PC software).

6. Related Works

The principle of using existing payment smart cards to secure Internet transactions has been applied in recent projects such as the e-COMM and C-SET projects in France. Both integrate shared-key based Transaction Certificates from existing EMV-like banking cards within SET or SET-like protocols. In this paper, rather than proposing a specific solution, we have tried to give a comprehensive and systematic overview of the security features and limits of a variety of related solutions, and hope it can be applied in the evaluation or design of similar systems.

7. Conclusion

The use of EMV over the Internet has major (and unacceptable) security shortcomings. Securing the communication channels between the different parties (customer, merchant, bank) using secure communication protocols can prevent mainly outsider attacks. However it does not solve the inherent lack of authentication in the EMV protocol.

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 authorisation in an Internet setting, though currently insecure because of merchant as well as bank impersonation attacks, can be made more secure by digitally signing authorisation 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-users 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.