Chip Authentication Program

Last updated
A Gemalto EZIO CAP device with Barclays PINsentry styling Barclays pinsentry.jpg
A Gemalto EZIO CAP device with Barclays PINsentry styling

The Chip Authentication Program (CAP) is a MasterCard initiative and technical specification for using EMV banking smartcards for authenticating users and transactions in online and telephone banking. It was also adopted by Visa as Dynamic Passcode Authentication (DPA). [1] The CAP specification defines a handheld device (CAP reader) with a smartcard slot, a numeric keypad, and a display capable of displaying at least 12 characters (e.g., a starburst display). Banking customers who have been issued a CAP reader by their bank can insert their Chip and PIN (EMV) card into the CAP reader in order to participate in one of several supported authentication protocols. CAP is a form of two-factor authentication as both a smartcard and a valid PIN must be present for a transaction to succeed. Banks hope that the system will reduce the risk of unsuspecting customers entering their details into fraudulent websites after reading so-called phishing emails. [2]

Contents

Operating principle

The CAP specification supports several authentication methods. The user first inserts their smartcard into the CAP reader and enables it by entering the PIN. A button is then pressed to select the transaction type. Most readers have two or three transaction types available to the user under a variety of names. Some known implementations are:

Code/identify
Without requiring any further input, the CAP reader interacts with the smartcard to produce a decimal one-time password, which can be used, for example, to log into a banking website.
Response
This mode implements challenge–response authentication, where the bank's website asks the customer to enter a "challenge" number into the CAP reader, and then copy the "response" number displayed by the CAP reader into the web site.
Sign
This mode is an extension of the previous, where not only a random "challenge" value, but also crucial transaction details such as the transferred value, the currency, and recipient's account number have to be typed into the CAP reader.

The above noted transaction types are implemented using one of two modes. One of these modes has two forms in which it can operate, creating three distinct modes, though they are not named this way in the specification.

Mode1
This is the mode for normal monetary transactions such as an online purchase through a merchant. A transaction value and currency are included in the computation of the cryptogram. If the card does not require it or the terminal does not support it, then both amount and currency are set to zero.
Mode2
This mode may be useful for authenticating a user in which no transaction is taking place, such as logging into an Internet banking system. No transaction value, currency, or other data are included, making these responses very easy to precompute or reuse.
With transaction data signing (TDS)
This mode may be used for more complicated transactions, such as a funds transfer between accounts. Multiple data fields pertaining to the transaction are concatenated and then hashed with a Mode2 cryptogram as the key for the hashing algorithm. The resultant hash is used in place of the cryptogram calculated in a non-TDS Mode2 operation. [3]

Mode1 sounds very much like a specific use of Mode2 with TDS, but there is a critical difference. In Mode1 operation, the transaction data (amount and currency type) are used in the cryptogram calculation in addition to all the values used in Mode2 without TDS, whereas Mode2 includes its transaction data in a successive step rather than including it in the cryptogram calculation step. If it were not for this difference, then all operations could be generalized as a single operation with varying optional transaction data.

Protocol details

A Nordea E-code reader Nordea e-kod.jpg
A Nordea E-code reader

In all three modes, the CAP reader asks the EMV card to output a data packet that confirms the cancellation of a fictitious EMV payment transaction, which involves the details entered by the user. This confirmation message contains a message authentication code (typically CBC-MAC/Triple DES) that is generated with the help of a card-specific secret key stored securely in the smartcard. Such cancellation messages pose no security risk to the regular EMV payment application, but can be cryptographically verified and are generated by an EMV card only after the correct PIN has been entered. It provided the CAP designers a way to create strong cryptographic evidence that a PIN-activated EMV card is present and has seen some given input data, without having to add any new software functions to EMV cards already in use.

An EMV smartcard contains a (typically 16-bit) transaction counter that is incremented with each payment or CAP transaction. The response displayed by a CAP reader essentially consists of the various parts of the card's response (Application Transaction Counter, MAC, etc.) which is then reduced to specific bits as determined by the Issuer Authentication Indicator (IAI) record stored in the card (this is set on a per-issuer basis, although should an issuer desire, it could be set randomly for each card providing a database of each card's IAI is kept), finally, after unwanted bits are discarded (essentially the absolute position of bits is irrelevant, a bit in the IAI that is 0 means the corresponding bit in the card response will be dropped rather than merely being set to 0). Finally the value is converted from binary into a decimal number and displayed to the user. A truncated example is provided below:

  1. CAP device selects EMV application, reads IAI info from card and the user selects an action to perform (in this example, IAI will be 111011011000 2 ).
  2. After successful PIN entry, CAP device sends challenge of 0111001110102 as an Authorization Request Cryptogram (ARQC) transaction.
  3. Smartcard gives a response of 1101011101102 and CAP device cancels the fake transaction.
  4. CAP device uses the IAI mask: 1110110110002 to drop bits; those bits that correspond to a 0 in the mask are dropped.
  5. Hence the final response is 11001102 or 102 in decimal.

The real world process is of course somewhat more complex as the card can return the ARQC in one of two formats (either the simple Response Message Template Format type 1 (id. 8016) or the more complex Response Message Template Format 2 (id. 7716) which splits the ARQC data into separate TLV values that need to be reassembled sequentially to match that of the type 1 format.

In the identify mode, the response depends only on the required bits from the IAI as the amount and reference number are set to zero; this also means that selecting respond and entering a number of 00000000 will in fact generate a valid identify response. More concerningly however, if a respond request is issued by a bank, using the sign mode with the same number and an amount of ¤0.00 will again generate a valid result which creates a possibility for a fraudster to instruct a customer to do a "test" challenge response for an amount of ¤0.00 which is in fact going to be used by the fraudster to verify a respond command in order for them to add themselves as a payee on the victim's account; these attacks were possible to carry out against banks that used strong authentication devices that were not canceling activities until an amount of at least 0.01 was entered. [4] The likelihood of these kinds of attacks was addressed in 2009 when new generations of devices were rolled out, implementing secure domain separation functionality that is compliant with the MasterCard Application note dated October 2010.[ clarification needed ] Similarly of course; a bank that implements the identify command makes it possible for a fraudster to request a victim to do a "test" respond transaction using 00000000 as the reference, and will then be able to successfully login to the victim's account. [4]

The same on-card PIN retry counter is used as in other EMV transactions. So just like at an ATM or POS terminal, entering an incorrect PIN three times in a row into a CAP reader will block the card.

Incompatibility

The original CAP specification was designed to use normal EMV transactions, such that the CAP application could be deployed without updating the firmware of existing EMV cards if necessary. The preferred implementation uses a separate application for CAP transactions. The two applications may share certain data, such as PIN, while other data is not shared in instances where it is only applicable to one application (i.e., terminal risk management data for EMV) or advantages to have separate (i.e., transaction counter, so that EMV and CAP transactions increment separate counters which can be verified more accurately). The reader also carries implementation specific data, some of which may be overridden by values in the card. Therefore, CAP readers are generally not compatible with cards from differing issuing banks.

However, most UK banks that issue card readers conform to a CAP subset defined by APACS, meaning that, in most cases, cards issued by a UK bank can be used in a card reader issued by a different bank.[ citation needed ]

Vulnerabilities

University of Cambridge researchers Saar Drimer, Steven Murdoch, and Ross Anderson conducted research [4] into the implementation of CAP, outlining a number of vulnerabilities in the protocol and the UK variant of both readers and cards. Numerous weaknesses were found. Radboud University researchers found a vulnerability in the Dutch ABN AMRO e.dentifier2, allowing an attacker to command a USB connected reader to sign malicious transactions without user approval. [5]

Users

Sweden

United Kingdom

A Nationwide CAP Device with a 20p coin to scale Nationwide-CAP-reader.jpg
A Nationwide CAP Device with a 20p coin to scale
A Natwest CAP Device with a 10p coin to scale Natwest--CAP-reader.jpg
A Natwest CAP Device with a 10p coin to scale

Software implementations

There exists [9] a software implementation written in Python supporting Mode 1, Mode 2 and Mode 2 with TDS to be used for educational purposes only. The identify function (without challenge) corresponds to the m1 function with the challenge "00000000".

Note that using this software for real financial operations can lead to some risks. Indeed, the advantage of using a standalone reader is to isolate the banking card from malware potentially located on the PC. Using it in a non-secured reader is taking the risk that a keylogger intercepts the PIN, and point of sale malware gains access to the card details, or even intercepts a transaction to modify it or operates its own transaction.

See also

Related Research Articles

<span class="mw-page-title-main">EFTPOS</span> Type of electronic payment system

Electronic funds transfer at point of sale is an electronic payment system involving electronic funds transfers based on the use of payment cards, such as debit cards or credit cards, at payment terminals located at points of sale. EFTPOS technology was developed during the 1980s.

<span class="mw-page-title-main">Automated teller machine</span> Electronic telecommunications device to perform financial transactions

An automated teller machine (ATM) is an electronic telecommunications device that enables customers of financial institutions to perform financial transactions, such as cash withdrawals, deposits, funds transfers, balance inquiries or account information inquiries, at any time and without the need for direct interaction with bank staff.

<span class="mw-page-title-main">Secure cryptoprocessor</span> Device used for encryption

A secure cryptoprocessor is a dedicated computer-on-a-chip or microprocessor for carrying out cryptographic operations, embedded in a packaging with multiple physical security measures, which give it a degree of tamper resistance. Unlike cryptographic processors that output decrypted data onto a bus in a secure environment, a secure cryptoprocessor does not output decrypted data or decrypted program instructions in an environment where security cannot always be maintained.

<span class="mw-page-title-main">Smart card</span> Pocket-sized card with embedded integrated circuits for identification or payment functions

A smart card (SC), chip card, or integrated circuit card, is a card used to control access to a resource. It is typically a plastic credit card-sized card with an embedded integrated circuit (IC) chip. Many smart cards include a pattern of metal contacts to electrically connect to the internal chip. Others are contactless, and some are both. Smart cards can provide personal identification, authentication, data storage, and application processing. Applications include identification, financial, public transit, computer security, schools, and healthcare. Smart cards may provide strong security authentication for single sign-on (SSO) within organizations. Numerous nations have deployed smart cards throughout their populations.

<span class="mw-page-title-main">Personal identification number</span> PIN code

A personal identification number (PIN), or sometimes redundantly a PIN number or PIN code, is a numeric passcode used in the process of authenticating a user accessing a system.

<span class="mw-page-title-main">EMV</span> Smart payment card standard

EMV is a payment method based on a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them. EMV stands for "Europay, Mastercard, and Visa", the three companies that created the standard.

<span class="mw-page-title-main">One-time password</span> Password that can only be used once

A one-time password (OTP), also known as a one-time PIN, one-time authorization code (OTAC) or dynamic password, is a password that is valid for only one login session or transaction, on a computer system or other digital device. OTPs avoid several shortcomings that are associated with traditional (static) password-based authentication; a number of implementations also incorporate two-factor authentication by ensuring that the one-time password requires access to something a person has as well as something a person knows.

<span class="mw-page-title-main">Security token</span> Device used to access electronically restricted resource

A security token is a peripheral device used to gain access to an electronically restricted resource. The token is used in addition to, or in place of, a password. Examples of security tokens include wireless keycards used to open locked doors, a banking token used as a digital authenticator for signing in to online banking, or signing a transaction such as a wire transfer.

A transaction authentication number (TAN) is used by some online banking services as a form of single use one-time passwords (OTPs) to authorize financial transactions. TANs are a second layer of security above and beyond the traditional single-password authentication.

ISO 8583 is an international standard for financial transaction card originated interchange messaging. It is the International Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders using payment cards.

<span class="mw-page-title-main">Hardware security module</span> Physical computing device

A hardware security module (HSM) is a physical computing device that safeguards and manages secrets, performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. A hardware security module contains one or more secure cryptoprocessor chips.

<span class="mw-page-title-main">Payment card</span> Card issued by a financial institution that can be used to make a payment

Payment cards are part of a payment system issued by financial institutions, such as a bank, to a customer that enables its owner to access the funds in the customer's designated bank accounts, or through a credit account and make payments by electronic transfer with a payment terminal and access automated teller machines (ATMs). Such cards are known by a variety of names, including bank cards, ATM cards, client cards, key cards or cash cards.

A card reader is a data input device that reads data from a card-shaped storage medium and provides the data to a computer. Card readers can acquire data from a card via a number of methods, including: optical scanning of printed text or barcodes or holes on punched cards, electrical signals from connections made or interrupted by a card's punched holes or embedded circuitry, or electronic devices that can read plastic cards embedded with either a magnetic strip, computer chip, RFID chip, or another storage medium.

A contactless smart card is a contactless credential whose dimensions are credit card size. Its embedded integrated circuits can store data and communicate with a terminal via NFC. Commonplace uses include transit tickets, bank cards and passports.

<span class="mw-page-title-main">Gemalto</span> International digital security company

Gemalto was an international digital security company providing software applications, secure personal devices such as smart cards and tokens, e-wallets and managed services. It was formed in June 2006 by the merger of two companies, Axalto and Gemplus International. Gemalto N.V.'s revenue in 2018 was €2.969 billion.

<span class="mw-page-title-main">Contactless payment</span> Technology enabling payment without physical contact

Contactless payment systems are credit cards and debit cards, key fobs, smart cards, or other devices, including smartphones and other mobile devices, that use radio-frequency identification (RFID) or near-field communication (NFC) for making secure payments. The embedded integrated circuit chip and antenna enable consumers to wave their card, fob, or handheld device over a reader at the Point-of-sale terminal. Contactless payments are made in close physical proximity, unlike other types of mobile payments which use broad-area cellular or Wi-Fi networks and do not involve close physical proximity.

<span class="mw-page-title-main">Credit card fraud</span> Financial crime

Credit card fraud is an inclusive term for fraud committed using a payment card, such as a credit card or debit card. The purpose may be to obtain goods or services or to make payment to another account, which is controlled by a criminal. The Payment Card Industry Data Security Standard is the data security standard created to help financial institutions process card payments securely and reduce card fraud.

Man-in-the-browser, a form of Internet threat related to man-in-the-middle (MITM), is a proxy Trojan horse that infects a web browser by taking advantage of vulnerabilities in browser security to modify web pages, modify transaction content or insert additional transactions, all in a covert fashion invisible to both the user and host web application. A MitB attack will be successful irrespective of whether security mechanisms such as SSL/PKI and/or two- or three-factor authentication solutions are in place. A MitB attack may be countered by using out-of-band transaction verification, although SMS verification can be defeated by man-in-the-mobile (MitMo) malware infection on the mobile phone. Trojans may be detected and removed by antivirus software;, but a 2011 report concluded that additional measures on top of antivirus software were needed.

Apple Pay is a mobile payment service by Apple Inc. that allows users to make payments in person, in iOS apps, and on the web. It is supported on iPhone, Apple Watch, iPad, Mac, and Vision Pro. It digitizes and can replace a credit or debit card chip and PIN transaction at a contactless-capable point-of-sale terminal. It does not require Apple Pay–specific contactless payment terminals; it can work with any merchant that accepts contactless payments. It adds two-factor authentication via Touch ID, Face ID, Optic ID, PIN, or passcode. Devices wirelessly communicate with point of sale systems using near field communication (NFC), with an embedded secure element (eSE) to securely store payment data and perform cryptographic functions, and Apple's Touch ID and Face ID for biometric authentication.

<span class="mw-page-title-main">Google Pay (payment method)</span> Mobile payments platform developed by Google

Google Pay is a mobile payment service developed by Google to power in-app, online, and in-person contactless purchases on mobile devices, enabling users to make payments with Android phones, tablets, or watches. Users can authenticate via a PIN, passcode, or biometrics such as 3D face scanning or fingerprint recognition.

References

  1. Dynamic passcode authentication Archived 2008-11-19 at the Wayback Machine , VISA Europe
  2. Leyden, John. "Barclays deploys PINsentry to fight fraud". www.theregister.com. Retrieved 2021-04-30.
  3. Banques en ligne : à la découverte d’EMV-CAP Archived 2012-11-27 at the Wayback Machine , UnixGarden
  4. 1 2 3 4 Drimer, Saar; Murdoch, Steven J.; Anderson, Ross (2009). Optimised to Fail: Card Readers for Online Banking (PDF). Financial Cryptography and Data Security. LNCS. Vol. 5628. Springer. pp. 184–200. doi:10.1007/978-3-642-03549-4_11.
  5. Designed to Fail: A USB-Connected Reader for Online Banking
  6. New security solution | nordea.se, in Swedish.
  7. "Barclays PINsentry". Archived from the original on 16 June 2007.
  8. Barclays to launch two-factor authentication, The Register, 2006-08-09.
  9. "Application". sites.uclouvain.be. Retrieved 2021-04-30.