Chip Authentication Program: Difference between revisions

Content deleted Content added
Vimalp (talk | contribs)
added an 'a' to make it gramatically correct.
Jomsborg (talk | contribs)
added note on DPA and proprietary variants implemented by some banks
Line 1:
[[Image:nationwide-CAP-reader.jpg|thumb|right|A CAP reader]]
The '''Chip Authentication Program''' (CAP) is a [[MasterCard]] and [[Visa (company)|Visa]] initiative and technical specification for using [[EMV]] banking [[smartcards]] for [[authentication|authenticating]] users and transactions in online and telephone banking. It was also adopted by [[Visa (company)|Visa]] as '''Dynamic Passcode Authentication''' (DPA)<ref>[http://www.visaeurope.com/aboutvisa/products/dynamicpasscode.jsp Dynamic passcode authentication], VISA Europe</ref>. 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 protocol]]s. 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.<ref>http://www.theregister.co.uk/2007/04/18/pinsentry/</ref>
 
==Operating principle==
Line 10:
==Protocol details==
 
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]]/[[TDES]]) 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 only generated by an EMV card only after itsthe 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 any already fielded EMV cards.
 
An EMV smartcard contains a (typically 16-bit) transaction counter that is increased by one with each payment or CAP transaction. The response displayed by a CAP devicereader essentially consists of a concatenation of the (typically 7) least-significant bits of the transaction counter, followed by selected bits from the message authentication code of the transaction abort message sent by the card, converted from a binary into a decimal number.
 
In the identify mode, the response depends only on the transaction counter value. In the response mode, it depends in addition on the entered challenge, and in signing mode it also depends on the entered transaction details.
 
SinceThe normalsame EMV transactions are used by the CAP reader, its use will be limited by theon-card PIN retry counter builtis intoused theas cardin EMV transactions. JustSo 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. However, some banks found this approach difficult to manage in their existing back-end systems. They instead implemented a modified version of CAP, where the reader selects a dedicated CAP application on the card, separate from the original EMV application. This allows the CAP and EMV applications on the card to use independent secret keys, although the PIN and its retry counter are still shared, at the expense of having to replace all existing cards with CAP-enabled ones. Different banks implemented these modifications slightly differently (e.g., using different application identifiers), therefore CAP readers are currently not necessarily compatible across banks.
 
==Users==