Content deleted Content added
→United Kingdom: +photo |
|||
| (111 intermediate revisions by 74 users not shown) | |||
Line 1:
{{Short description|Aspect of banking security}}
[[image:Barclays pinsentry.jpg|thumb|right|250px|A
The '''Chip Authentication Program''' '''(CAP)''' is a [[MasterCard]] 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] {{webarchive|url=https://web.archive.org/web/20081119231409/http://www.visaeurope.com/aboutvisa/products/dynamicpasscode.jsp |date=2008-11-19 }}, VISA Europe</ref>
==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
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 sounds very much like a specific use of Mode2 with TDS
==Protocol details==
[[Image:
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]]/[[
An EMV smartcard contains a (typically 16-bit) transaction counter that is
# 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<sub>[[binary number|2]]</sub>).
# After successful PIN entry, CAP device sends challenge of 011100111010<sub>2</sub> as an Authorization Request Cryptogram (ARQC) transaction.
# Smartcard gives a response of 110101110110<sub>2</sub> and CAP device cancels the fake transaction.
# CAP device uses the IAI mask: 111011011000<sub>2</sub> to drop bits; those bits that correspond to a 0 in the mask are dropped.
# Hence the final response is 1100110<sub>2</sub> 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. 80{{sub|16}}) or the more complex Response Message Template Format 2 (id. 77{{sub|16}}) which splits the ARQC data into separate TLV values that need to be reassembled sequentially to match that of the type 1 format.
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.▼
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.<ref name="cambridge"/> 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.{{clarify|reason=how does this fix the issue?|date=August 2012}} 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.<ref name="cambridge"/>
▲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.{{cn|date=March 2024}}
==Vulnerabilities==
==Users==
===Belgium===
[[Image:lecteur-de-carte-belfius.png|right|thumb|A [[Belfius]] card reader]]
Most majors banks of Belgium (including [[Belfius]], [[BNP Paribas Fortis]], [[ING Group|ING]], [[KBC Bank]]) provide such a card reader. It is used for two main purposes:
* Authenticating to the bank eBanking website. In order to access private information like balance checking.
* Signing a transaction. For example in eCommerce (3DS) to buy goods or service on an online merchant, or to perform a [[bank transfer]]. The merchant would ask for the bank card information, then redirect the user to the bank website where a webpage is displayed with instructions to follow to verify the transaction. Then the bank redirects the user to the merchant page with a success or a failure.
The device is equipped with an optional USB port, those two operations can be used without connecting the cable on a computer.
It was the most used method to pay online, offering a verification method similar to PIN in POS. Since the wide acceptation of smartphones, the banks offer an alternative using a local application on the phone, using a QR-Code to scan, or using the popular {{Interlanguage link|Itsme|fr|Itsme}} app.
The device is also compatible with the [[Belgian identity card|Belgian eID card]] to access government services like tax declaration, medical insurance information, unemployement, etc. Those services are also generally available using Itsme.
===Sweden===
* [[Nordea]]
===United Kingdom===
[[Image:nationwide-CAP-reader.jpg|right|thumb|A Nationwide CAP Device with a 20p coin to scale]]
[[Image:Natwest--CAP-reader.jpg|right|thumb|A Natwest CAP Device with a 10p coin to scale]]
*[[APACS]] defined a CAP subset for use by UK banks.▼
[[File:Barclays Pinsentry 5920.jpg|right|thumb|Barclays Pinsentry 5920]]
*[[Barclays Bank]] began issuing CAP readers (which they call "PINsentry") in 2007 to customers who make an online payment to a new recipient.<ref>{{cite web|url=http://www.barclays.co.uk/pinsentry/ | title=Barclays PINsentry}}</ref><ref>[http://www.theregister.co.uk/2006/08/09/barclays_launches_cardreaders/ Barclays to launch two-factor authentication], The Register, 2006-08-09.</ref> 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 PINsentry device is powered by four [[LR44]] [[button cell]] batteries, which the manual claims will last from five to seven years. A version for vision-impaired users (with voice output) is available on request. The device is also now used in branches in order to replace traditional chip and pin devices in order to further prevent attempted fraud.▼
▲*The [[
**[[
**[[
*
**[[The
**[[Royal Bank of Scotland]]
*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.<ref name="cambridge"></ref>▼
**[[Lloyds Bank]]
**[[Nationwide Building Society|Nationwide]]
*The CAP readers of Barclays, Lloyds Bank, Nationwide, NatWest, Co-operative Bank/Smile and RBS are all compatible.
▲*[[Barclays
▲*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.<ref name="cambridge"
==Software implementations==
There exists<ref>{{Cite web|title=Application|url=https://sites.uclouvain.be/EMV-CAP/Application/|access-date=2021-04-30|website=sites.uclouvain.be}}</ref> 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|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==
* [[3-D Secure]]
==References==
Line 52 ⟶ 91:
<references/>
[[Category:Payment
[[Category:Smart cards]]
| |||