Chip Authentication Program

A GemAlto EZIO CAP Device Whitelabeled as Barclays PINSentry

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 decimal 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 ‘phishing’ emails.^[2]

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 2 or 3 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 in to 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. The transaction value and currency may be 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 during the computation.
• 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. The computation differs as there is no transaction data included, making these responses very easy to precompute or reuse.
• Mode2 with 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 using the value that would result from a Mode2 operation as the key for the hashing algorithm. The resultant hash is used in place of the cryptogram calculated in a non-TDS Mode2 operation.

Mode1 sounds very much like a specific use of Mode2 with TDS (Transaction Data Signing), 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

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 already fielded EMV cards.

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 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. CAP device sends challenge of 011100111010 as an ARQC transaction (we are assuming PIN entry was successful).
3. Smartcard gives a response of 110101110110 and CAP device cancels the fake transaction.
4. CAP device uses the IAI mask: 111011011000 to determine which bits to drop - where you see a 0 in the IAI, you delete that bit from the response.
5. Hence the final response is 1100110 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 (0x80) or the more complex Response Message Template Format 2 (0x77) 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 - currently this attack is only possible with the Gemalto-made EZIO CAP devices (Barclays PINsentry) as the Xiring-made devices will not proceed until an amount of at least 0.01 is entered. 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.

The same on-card PIN retry counter is used as in 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.

Vulnerabilities

Cambridge University researchers Saar Drimer, Steven Murdoch, Ross Anderson conducted research ^[3] 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.

Users

Sweden

• Nordea began using CAP in November 2007.^[4] The Nordea eCode solution is used by Nordea both for eBanking, eCommerce (3DS) and also with eID. The reader which has some more advanced functionality that extends CAP, makes Nordea's CAP implementations more secure against trojans and man-in-the-middle attacks. When used for eID, the user is able to file his "tax declaration" online, or any implemented eGoverment functions. The device is also equipped with a USB-port, that enables the bank to perform Sign-What-You-See for approval of sensitive transactions.

United Kingdom

A Nationwide CAP Device

• APACS defined a CAP subset for use by UK banks. Currently used by:
• Barclays Bank
• Ulster Bank
• NatWest
• Co-operative Bank and Smile
• Royal Bank of Scotland
• Lloyds TSB Commercial
• Nationwide

• The CAP readers of Barclays, Lloyds TSB, Nationwide, NatWest, Co-operative Bank/Smile and RBS are all intercompatible.
• Barclays began issuing CAP readers (called "PINsentry") in 2007 .^[5][6] Their online-banking website uses the "identify" mode for login verification and the "sign" mode for transaction verification. The "respond" mode is not currently used. The device is also now used in branches, replacing traditional chip and pin devices in order to further prevent attempted fraud.
• Bank cards issued by HBOS are technically compatible with the system, though HBOS has not (yet) introduced CAP readers for use with their online banking.^[3]

References

1. ^ Dynamic passcode authentication, VISA Europe
2. ^ http://www.theregister.co.uk/2007/04/18/pinsentry/
3. ^ ^{a b} Optimised to fail: Card readers for online banking
4. ^ New security solution | nordea.se, in Swedish.
5. ^ "Barclays PINsentry". http://www.barclays.co.uk/pinsentry/. 
6. ^ Barclays to launch two-factor authentication, The Register, 2006-08-09.