EMV 1

EMV
EMV stands for Europay, MasterCard and VISA, the global
standard for inter-operation of integrated circuit cards (IC
cards or "chip cards") and IC card capable point of sale
(POS) terminals and automated teller machines (ATMs), for
authenticating credit and debit card transactions.
It is a joint effort between Europay, MasterCard and Visa to
ensure security and global interoperability so that Visa and
MasterCard cards can continue to be accepted everywhere.
Europay International SA was absorbed into MasterCard in
2002. JCB (formerly Japan Credit Bureau) joined the
organization in December 2004, and American Express
joined in February 2009. IC card systems based on EMV are Credit card with EMV chip. The 3 by 5 mm chip embedded in
the card is shown enlarged in the inset. The contact pads on
being phased in across the world, under names such as "IC
the card enable electronic access to the chip
Credit" and "Chip and PIN".

The EMV standards define the interaction at the physical, electrical, data and application levels between IC cards
and IC card processing devices for financial transactions. There are standards based on ISO/IEC 7816 for contact
cards, and standards based on ISO/IEC 14443 for contactless cards.
The first standard for payment cards was the Carte Bancaire B0' standard deployed in France in 1989. Geldkarte in
Germany also predates EMV. EMV was designed to allow cards and terminals to be backwardly compatible with
these standards. France has since migrated all its card and terminal infrastructure to EMV.
The most widely known chip card implementations of EMV standard are:
• VSDC - VISA
• MChip - MasterCard
• AEIPS - American Express
• J Smart - JCB
Visa and MasterCard have also developed standards for using EMV cards in devices to support card-not-present
transactions over the telephone and Internet. MasterCard has the Chip Authentication Program (CAP) for secure
e-commerce. Its implementation is known as EMV-CAP and supports a number of modes. Visa has the Dynamic
Password Authentication (DPA) scheme, which is their implementation of CAP using different default values.
In February 2010 computer scientists from Cambridge University demonstrated that an implementation of EMV PIN
entry is vulnerable to a man-in-the-middle attack; however, the way PINs are processed depends on the capabilities
of the card and the terminal. This attack is not a general weakness, but it does show that attacks are possible
depending on the implementation.
In May 2010, a press release from Gemalto (a global EMV card producer) indicated that United Nations Federal
Credit Union in New York would become the first EMV card issuer in the US, offering an EMV Visa credit card to
its customers.[1]
EMV 2

Differences and benefits of EMV

The purpose and goal of the EMV standard is to specify interoperability between EMV compliant IC cards and EMV
compliant credit card payment terminals throughout the world. There are two major benefits to moving to smart card
based credit card payment systems: improved security (with associated fraud reduction), and the possibility for finer
control of "offline" credit card transaction approvals. One of the original goals of EMV was to allow for multiple
applications to be held on a card: for instance, a credit and debit card application or an e-purse.
EMV chip card transactions improve security against fraud compared to magnetic stripe card transactions that rely
on the holder's signature and visual inspection of the card to check for features such as hologram. The use of a PIN
and cryptographic algorithms such as DES, Triple-DES, RSA and SHA provide authentication of the card to the
processing terminal and the card issuer's host system. The processing time is comparable to online transactions, in
which communications delay accounts for the majority of the time, while cryptographic operations take
comparatively little time. The supposed increased protection from fraud has allowed banks and credit card issuers to
push through a 'liability shift' such that merchants are now liable (as from 1 January 2005 in the EU region) for any
fraud that results from transactions on systems that are not EMV capable.[2] For transactions in which an EMV card
is used, the cardholder is assumed to be liable unless they can unquestionably prove they were not present for the
transaction, did not authorize the transaction, and did not inadvertently assist the transaction through PIN disclosure.
Although not the only possible method, the majority of implementations of EMV cards and terminals confirm the
identity of the cardholder by requiring the entry of a PIN (Personal Identification Number) rather than signing a
paper receipt. Whether or not PIN authentication takes place depends upon the capabilities of the terminal and
programming of the card. For more details of this (specifically, the system being implemented in the UK) see Chip
and PIN.

EMV commands
ISO/IEC 7816-3 defines the transmission protocol between chip cards and readers. Using this protocol, data is
exchanged in application protocol data units (APDUs). This comprises sending a command to a card, the card
processing it, and sending a response. EMV uses the following commands:
• application block
• application unblock
• card block
• external authenticate (7816-4)
• generate application cryptogram
• get data (7816-4)
• get processing options
• internal authenticate (7816-4)
• PIN change / unblock
• read record (7816-4)
• select (7816-4)
• verify (7816-4)
Commands followed by "7816-4" are defined in ISO/IEC 7816-4 and are interindustry commands used for many
chip card applications such as GSM SIM cards.
EMV 3

EMV transaction flow

An EMV transaction has the following steps:[3]
• Application selection
• Initiate application processing
• Read application data
• Processing restrictions
• Offline data authentication (not carried out in ATMs)
• Cardholder verification
• Terminal risk management
• Terminal action analysis
• First card action analysis
• Online transaction authorisation (only carried out if required by the result of the previous steps; mandatory in
ATMs)
• Second card action analysis
• Issuer script processing

Application selection
ISO/IEC 7816 defines a process for application selection. The intent of application selection was to allow cards to
contain completely different applications e.g. GSM and EMV. EMV however took application selection to be a way
of identifying the type of product so that all product issuers (Visa, MasterCard etc.) have to have their own
application rather than there being an "EMV" application, which would have been much simpler. The way
application selection is prescribed in EMV is far more complicated than it need be and is a frequent source of
interoperability problems between cards and terminals. Book 1 [4] of the EMV standard devotes 15 pages to
describing the application selection process.
An application identifier (AID) is used to address an application in the card. An AID consists of a registered
application provider identifier (RID) of five bytes, which is issued by the ISO/IEC 7816-5 registration authority.
This is followed by a proprietary application identifier extension (PIX) which enables the application provider to
differentiate between the different applications offered. The AID is printed on all EMV cardholder receipts.

Card scheme RID Product PIX AID

Visa A000000003 Visa credit or debit 1010 A0000000031010

Visa Electron 2010 A0000000032010

V PAY 2020 A0000000032020

Plus 8010 A0000000038010

MasterCard A000000004 MasterCard credit or debit 1010 A0000000041010

Maestro (debit card) 3060 A0000000043060

Cirrus (interbank network) 6000 A0000000046000

UK Domestic Maestro - Switch (debit card) A000000005 Maestro UK [5] 0001 A0000000050001

Solo 0002 A0000000050002

American Express A000000025 American Express 01 A00000002501

LINK (UK) ATM network A000000029 ATM card 1010 A0000000291010

ZKA A000000359 Girocard 1010028001 A0000003591010028001

Consorzio BANCOMAT A000000141 PagoBANCOMAT 0001 A0000001410001

EMV 4

Initiate application processing

The terminal sends the get processing options command to the card. When issuing this command, the terminal
supplies the card with any data elements requested by the card in the processing options data objects list (PDOL).
The PDOL (a list of tags and lengths of data elements) is optionally provided by the card to the terminal during
application selection. The card responds with the application interchange profile (AIP), a list of functions to be
performed in processing the transaction. The card also provides the application file locator (AFL), a list of files and
records that the terminal needs to read from the card.

Read application data

Smart cards store data in files. The AFL contains the files that contain EMV data. These all need to be read using the
read record command. EMV does not specify which files data is stored in, so all the files need to be read. Data in
these files is stored in BER TLV format. EMV defines tag values for all data used in card processing.

Processing restrictions
The purpose of the processing restrictions is to see if the card should be used. Three data elements read in the
previous step are checked.
• Application version number
• Application usage control (This shows whether the card is only for domestic use etc.)
• Application effective/expiration dates checking
If any of these checks fail, the card is not necessarily declined. The terminal sets the appropriate bit in the terminal
verification results (TVR), the components of which form the basis of an accept/decline decision later in the
transaction flow. This feature allows, for example, card issuers to permit their cardholders to continue to use expired
cards after their expiry date, but for all transactions made with an expired card to be performed on-line.

Offline data authentication

Offline data authentication is a cryptographic check to makes sure that the card is valid using Public-key
cryptography. There are three different processes that can be undertaken depending on the card:
• Static data authentication (SDA) ensures data read from the card has been signed by the card issuer. This
prevents modification of data, but does not prevent cloning.
• Dynamic data authentication (DDA) provides protection against modification of data and cloning.
• Combined DDA/generate application cryptogram (CDA) combines DDA with the generation of a card's
application cryptogram to assure card validity. Support of CDA in devices may be needed, as this process has
been implemented in specific markets. This process is not mandatory in terminals and can ony be carried out
where both card and terminal support it.
Offline data authentication is never carried out at ATMs.
EMV 5

Cardholder verification
Cardholder verification is used to evaluate whether the person presenting the card is the legitimate cardholder. There
are many cardholder verification methods (CVMs) supported in EMV. They are:
• Signature
• Offline plaintext PIN
• Offline enciphered PIN
• Offline plaintext PIN and signature
• Offline enciphered PIN and signature
• Online PIN
• No CVM required
• Fail CVM processing
The terminal uses a CVM list read from the card to determine the type of verification to be performed. The CVM list
establishes a priority of CVMs to be used relative to the capabilities of the terminal. Different terminals support
different CVMs. ATMs generally support online PIN. POS terminals vary in their support of CVM depending on
their type and in which country they are located.

Terminal risk management

Terminal risk management is only performed in devices where there is a decision to be made whether a transaction
should be authorised on-line or offline. If transactions are always carried out on-line (e.g. ATMs) or always off-line,
this step can be missed. Terminal risk management checks the transaction amount against a floor limit (above which
transactions should be processed on-line). It is also possible to have a 1 in n online counter, and a check against a hot
card list (which is only necessary for off-line transaction). If the result of any of these test is positive, the terminal
sets the appropriate bit in the terminal verification results (TVR).

Terminal action analysis

The results of previous processing steps are used to determine whether a transaction should be approved offline, sent
online for authorization, or declined offline. This is done using a combination of Terminal action codes (TACSs)
which are held in the terminal and Issuer action codes (IACs) which are read from the card.
An online only device such as an ATM always attempts to go on-line with the authorization request, unless declined
off-line due to Issuer action codes—Denial settings. During IAC—Denial and TAC—Denial processing, for an
online only device, the only relevant Terminal verification results bit is “Service not allowed”.
When an online only device performs IAC—Online and TAC—Online processing the only relevant TVR bit is
“Transaction value exceeds the floor limit”. Because the floor limit is set to zero, the transaction should always go
online and all other values in TAC—Online or IAC—Online are irrelevant.
Online only devices do not need to perform IAC-default processing.

First card action analysis

One of the data objects read from the card in the Read application data stage is CDOL1 (Card Data object List). This
object is a list of tags that the card want to be sent to it to make a decision on whether to approve or decline a
transaction (including transaction amount, but many other data objects too). The terminal sends this data and
requests a cryptogram using the generate application cryptogram command. Depending on the terminals decision
(offline, online, decline) the terminal requests one of the following cryptograms from the card:
• Transaction certificate (TC)—Offline approval
• Authorization Request Cryptogram (ARQC)—Online authorization
• Application Authentication Cryptogram (AAC)—Offline decline
EMV 6

This step gives the card the opportunity to accept the terminal's action analysis or to decline a transaction or force a
transaction on-line. The card cannot return a TC when an ARQC has been asked for, but can return an ARQC when a
TC has been asked for.

Online transaction authorisation

Transactions go online when a ARQC has been requested. The ARQC is sent in the authorisation message. The card
generates the ARQC. Its format depends on the card application. EMV does not specify the contents of the ARQC.
The ARQC created by the card application is a digital signature of the transaction details which can be checked in
real time by the card issuer. This provides a strong cryptographic check that the card is genuine. The issuer responds
to an authorisation request with a response code (accepting or declining the transaction), an authorisation response
cryptogram (ARPC) and optionally an issuer script (a string of commands to be sent to the card).

Second card action analysis

CDOL2 (Card data object list) contains a list of tags that the card wants to be sent following online transaction
authorisation (response code ARPC etc.). Even if for any reason the terminal could not go online (e.g.
communication failure), the terminal should send this data to the card again using the generate authorisation
cryptogram command. This lets the card know the issuer's response. The card application may then reset offline
usage limits.

Issuer script processing

If a card issuer wants to update a card post issuance it can send commands to the card using issuer script processing.
Issuer scripts are encrypted between the card and the issuer, so are meaningless to the terminal. Issuer script can be
used to block cards, or change card parameters.

Control of the EMV standard

The first version of EMV standard was published in 1995. Now the standard is defined and managed by the public
corporation EMVCo LLC [6].The current members of EMVCo are JCB International, American Express, MasterCard
Worldwide, and Visa, Inc. Each of these organizations owns one quarter of EMVCo and has representatives in the
EMVCo organization and EMVCo working groups.
Recognition of compliance with the EMV standard (i.e. device certification) is issued by EMVCo following
submission of results of testing performed by an accredited testing house.
EMV Compliance testing has two levels: EMV Level 1, which covers physical, electrical and transport level
interfaces, and EMV Level 2, which covers payment application selection and credit financial transaction processing.
After passing common EMVCo tests, the software must be certified by payment brands to comply with proprietary
EMV implementations such as VISA VSDC, American Express AEIPS, MasterCard MChip, JCB JSmart, or
EMV-compliant implementations of non-EMVCo members such as LINK in the UK, or Interac in Canada.
The EMVCo standards have been integrated into the broader electronic payment security standards being developed
by the Secure POS Vendor Alliance, with a specific effort to develop a common interpretation of EMVCo's place
relative to, and interactions with, other existing security standards, such as PCI-DSS.[7]
EMV 7

List of EMV documents and standards

Since version 4.0, the official EMV standard documents, that define all the components in an EMV payment system,
are published as four "books":
• Book 1 [4] - Application Independent ICC to Terminal Interface Requirements
• Book 2 [8] - Security and Key Management
• Book 3 [9] - Application Specification
• Book 4 [10] - Cardholder, Attendant, and Acquirer Interface Requirements

Versions
First EMV standard came into view in 1995 as EMV 2.0. This was upgraded to EMV 3.0 in 1996 with later
amendments to EMV3.1.1 in 1998 This was further amended to version 4.0 in December 2000.
Version 4.0 became effective in June 2004. Version, 4.1 became effective in June 2007. version EMV 4.2 is in effect
since June 2008.

Vulnerabilities

Examples
• The Guardian, 5 September 2005, "Fraudsters show how to beat chip and pin" [11]
• BBC News Online, Poor print exposing Pin numbers [12] 25 Aug 2005
• The Guardian, 27 October 2004, "Safety in numbers? Not likely" [13]
• Chip and SPIN ! [14] (critical website)
• The Inquirer: Does he take PINs with his chips? [15] (critical editorial)
• Attack methods against Chip & PIN (EMV) [16] (academic research site)
• New Law Journal: statistical and legal analysis of claimed card fraud, 16 October 2009 [17]
EMV 8

Decreased security for PINs

A PIN alone obtained by an unauthorised person is not enough for
fraudulent card use. A card alone without PIN can be used in a
merchant's terminal which allows authorisation by magnetic
strip—such terminals are increasingly rare in countries using
EMV—but not in an ATM until 2010. A PIN can, however, be used in
conjunction with a cloned magnetic strip or a card which is stolen or
misused. Consequently criminals attempt to obtain both card and PIN.
A card can be used in a PIN terminal without entering a valid PIN
using malicious special hardware announced by researchers in
February 2010; it is not known if this vulnerability has been exploited
by criminals.

Direct observation

It is always possible to find a PIN by watching it being typed in

("shoulder surfing"). Before Chip and PIN this could happen at an
ATM in a bank or other relatively secure area. The use of PINs by all
merchants accepting cards has increased the opportunities to observe
PINs; the environment is more open and public, and more care is
needed to shield the PIN when typing it in to a legitimate terminal.
PINs obtained in this way are only of use if the card is then stolen, or
misused (e.g., by a family member).

Counterfeit PIN pads are sometimes used to log PINs and stripe details A Chip and PIN machine may be observed by
in systems which swipe the magnetic stripe, allowing a fraudster to other shoppers, staff, or anyone with access to
footage from security cameras (as above).
clone the card and know the PIN for use in ATMs that allow magnetic
stripe authorisation. This would not work in countries (including the
UK) where all ATMs require authorisation by chip rather than magnetic stripe.

Indirect observation
Security cameras at the cash register intended to deter shoplifters and thieves may compromise the security of Chip
and PIN by recording customers entering PINs if recordings are not dealt with securely.[18] Again, fraudulent use is
possible only in conjunction with a stolen card or cloned magnetic stripe.
Hidden pinhole camera on cash machines are sometimes used by criminals to harvest PINs, usually in conjunction
with card theft. For example, there have been instances where a customer is told by a "friendly bystander" that they
have dropped £5 after they have inserted the card and entered the PIN; when they bend down to pick it up, the card is
stolen from the machine's slot and used with the PIN obtained by pinhole camera or binocular observation from a
distance.

Opportunities to harvest PINs and clone magnetic stripes

In addition to the track-two data on the magnetic stripe, EMV cards generally have identical data encoded on the
chip which is read as part of the normal EMV transaction process. If an EMV reader is compromised to the extent
that the conversation between the card and the terminal is intercepted, then the attacker may be able to recover both
the track-two data and the PIN, allowing construction of a magnetic stripe card which, while not usable in a chip and
PIN terminal, can be used, for example, in terminal devices which permit fallback to magstripe processing for
foreign customers without chip cards, and defective cards. This attack is possible only where (a) the offline PIN is
presented in plaintext by the PIN entry device to the card, where (b) magstripe fallback is permitted by the card
EMV 9

issuer and (c) where geographic and behavioural checking may not be carried out by the card issuer.
It was claimed that changes specified to the protocol (specifying different card verification values between the Chip
and Magnetic Stripe – the iCVV) rendered this attack ineffective. APACS (the UK payments association) stated that
such measures would be in place from January 2008, although tests on cards in February 2008 indicated this may
have been delayed.[19] However, there was a very large scale and successful attack which went on for 9 months in
2008 (see below).
Within the UK and Ireland, plaintext offline PIN is the standard mode of operation and cards which support
encrypted offline PIN are rare, despite being common in other countries. Permitting magstripe fallback transactions
to take place is a risk known to card issuers; it is usually permitted when fraud levels are low, in order to increase
profits and avoid antagonising cardholders by allowing transactions which could not otherwise have taken place.
When magstripe fallback fraud levels grow, this processing option is disallowed.
Geographic and behavioural fraud analysis tools are in use by many card issuers to track and decline transactions
considered suspicious—for example, an EMV card-present transaction at a UK ATM, followed hours later by a
magstripe fallback transaction in the Far East.
Successful attacks
Conversation-capturing is the form of attack which was reported to have taken place against Shell terminals in May
2006, when they were forced to disable all EMV authentication in their petrol stations after more than £1 million was
stolen from customers.[20]
In October 2008 it was reported that hundreds of Chip and PIN readers for use in Britain, Ireland, the Netherlands,
Denmark, and Belgium had been expertly tampered with in China during or shortly after manufacture so that details
and PINs of credit and debit cards were sent during the 9 months before over mobile phone networks to criminals in
Lahore, Pakistan. US National Counterintelligence Executive Joel Brenner said "Previously only a nation state's
intelligence service would have been capable of pulling off this type of operation. It's scary". Data were typically
used a couple of months after the card transactions to make it harder for investigators to pin down the vulnerability.
After the fraud was discovered it was found that tampered-with terminals could be identified as the additional
circuitry increased their weight by about 100 g. Tens of millions of pounds sterling are believed to have been
stolen.[21] This vulnerability spurred efforts to implement better control of electronic POS devices over their entire
life cycle, a practice endorsed by electronic payment security standards like those being developed by the SPVA.[22]
Demonstration of PIN harvesting and stripe cloning
Cambridge University researchers Steven Murdoch and Saar Drimer demonstrated in a February 2008 BBC
Newsnight programme one example attack, to illustrate that Chip and PIN is not secure enough to justify passing the
liability to prove fraud from the banks onto customers.[23] [24] The Cambridge University exploit allowed the
experimenters to obtain both card data to create a magnetic stripe and the PIN.
APACS, the UK payments association, disagreed with the majority of the report, saying: "The types of attack on PIN
entry devices detailed in this report are difficult to undertake and not currently economically viable for a fraudster to
carry out."[25] They also said that changes to the protocol (specifying different card verification values between the
Chip and Magnetic Stripe – the iCVV) would make this attack ineffective from January 2008. The fraud reported in
October 2008 to have operated for 9 months (see above) was probably in operation at the time, but was not
discovered for many months.
EMV 10

2010: hidden hardware disables PIN checking on stolen card

On 11 February 2010 Murdoch and Drimer's team at Cambridge University announced that they had found "a flaw in
chip and PIN so serious they think it shows that the whole system needs a re-write" that was "so simple that it
shocked them".[26] [27] A stolen card is connected to an electronic circuit and to a fake card which is inserted into the
terminal ("man-in-the-middle attack"). Any 4 digits are typed in and accepted as a valid PIN. A team from the BBC's
Newsnight programme visited a Cambridge University cafeteria (with permission) with the system, and were able to
pay using their own cards (a thief would use stolen cards) connected to the circuit, inserting a fake card and typing in
"0000" as the PIN. The transactions were registered as normal, and were not picked up by banks' security systems. A
member of the research team said "Even small-scale criminal systems have better equipment than we have. The
amount of technical sophistication needed to carry out this attack is really quite low". The announcement of the
vulnerability said "The expertise that is required is not high (undergraduate level electronics) ... We dispute the
assertion by the banking industry that criminals are not sophisticated enough, because they have already
demonstrated a far higher level of skill than is necessary for this attack in their miniaturized PIN entry device
skimmers." It is not known if this vulnerability has been exploited.
EMVCo disagreed and published a response saying that, while such an attack might be theoretically possible, it
would be extremely difficult and expensive to carry out successfully, that current compensating controls are likely to
detect or limit the fraud, and that the possible financial gain from the attack is minimal while the risk of a declined
transaction or exposure of the fraudster is significant.[28]
When approached for comment, several banks each said that this was an industry-wide issue, and referred the
Newsnight team to the banking trade association for further comment. According to Phil Jones of the Consumers'
Association, chip and PIN has helped to bring down instances of card crime, but many cases remain unexplained
"What we do know is that we do have cases that are brought forward from individuals which seem quite persuasive".
Because the submission of the PIN is suppressed, this is the exact equivalent of a merchant performing a PIN bypass
transaction, such transactions will never succeed offline as a card will never generate an offline authorisation without
a successful PIN entry. As a result of this, the transaction ARQC must be submitted online to the issuer who will
know that the ARQC was generated without a successful PIN submission (since this information is included in the
encrypted ARQC) and hence would be very likely to decline the transaction if it were for a high value, out of
character or otherwise outside of the typical risk management parameters set by the issuer.
Originally bank customers had to prove that they had not been negligent with their PIN before getting redress, but
UK regulations in force from 1 November 2009 placed the onus firmly on the banks to prove that a customer has
been negligent in any dispute, with the customer given 13 months to make a claim.[29] Murdoch said that "[the
banks] should look back at previous transactions where the customer said their PIN had not been used and the bank
record showed it has, and consider refunding these customers because it could be they are victim of this type of
fraud".
Drimer and Murdoch published a paper with Ross Anderson on the closely related topic of "Failures of
Tamper-Proofing in PIN Entry Devices" in IEEE Security and Privacy, November/December 2009.[30]
EMV 11

See also
• Supply chain attack

References
[1] United Nations Federal Credit Union Selects Gemalto for First U.S. Issued Globally Compliant Payment Card (http:/ / www. gemalto. com/
php/ pr_view. php?id=749), Gemalto NV,
[2] Chip and PIN liability Shift (http:/ / www. chipandpin. co. uk/ business/ card_payments/ means/ shift_liability. html), The UK Cards
Association,
[3] http:/ / www. emvx. co. uk/ flow_chart. aspx
[4] http:/ / www. emvco. com/ download_agreement. aspx?id=4
[5] http:/ / www. maestrocard. co. uk
[6] http:/ / www. emvco. org
[7] SPVA Launch Presentation (http:/ / www. spva. org/ Files/ SPVA Press Conference and Customer Meeting CDO final version . ppt#306,11),
Secure POS Vendor Alliance, 2009,
[8] http:/ / www. emvco. com/ download_agreement. aspx?id=5
[9] http:/ / www. emvco. com/ download_agreement. aspx?id=11
[10] http:/ / www. emvco. com/ download_agreement. aspx?id=7
[11] http:/ / money. guardian. co. uk/ scamsandfraud/ story/ 0,13802,1562682,00. html
[12] http:/ / news. bbc. co. uk/ 1/ hi/ technology/ 4183330. stm
[13] http:/ / money. guardian. co. uk/ creditanddebt/ creditcards/ story/ 0,1456,1336619,00. html
[14] http:/ / www. chipandspin. co. uk/
[15] http:/ / www. theinquirer. net/ ?article=27304
[16] http:/ / www. cl. cam. ac. uk/ research/ security/ banking/
[17] http:/ / www. newlawjournal. co. uk/ nlj/ content/ chip-pin-fallacies
[18] http:/ / boakes. org/ chip-pin-camera
[19] http:/ / www. cl. cam. ac. uk/ research/ security/ banking/ ped/
[20] *[http://news.bbc.co.uk/1/hi/england/4980190.stm Petrol firm suspends chip-and-pin], BBC News, 6 May 2006 (http:/ / news. bbc. co. uk/ 1/
hi/ england/ 4980190. stm)
[21] Organized crime tampers with European card swipe devices, The Register, 10th October 2008, http:/ / www. theregister. co. uk/ 2008/ 10/
10/ organized_crime_doctors_chip_and_pin_machines/
[22] Technical Working Groups, Secure POS Vendor Alliance, 2009, http:/ / www. spva. org/ technicalWorking. aspx/
[23] "Is Chip and Pin really secure?" (http:/ / news. bbc. co. uk/ 1/ hi/ programmes/ newsnight/ 7265437. stm). BBC News. 26 February 2008. .
Retrieved 2 May 2010.
[24] http:/ / www. bbc. co. uk/ consumer/ tv_and_radio/ watchdog/ reports/ insurance_and_finance/ insurance_20070206. shtml
[25] http:/ / www. channelregister. co. uk/ 2008/ 02/ 27/ credit_card_reader_security_pants/
[26] EMV PIN verification "wedge" vulnerability (http:/ / www. cl. cam. ac. uk/ research/ security/ banking/ nopin/ ), Computer Laboratory,
University of Cambridge, , retrieved 2010-02-12
[27] BBC: New flaws in chip and pin system revealed, 11 February 2010 (http:/ / www. bbc. co. uk/ blogs/ newsnight/ susanwatts/ 2010/ 02/
new_flaws_in_chip_and_pin_syst. html)
[28] Response from EMVCo to the Cambridge University Report on Chip and PIN vulnerabilities ('Chip and PIN is Broken' - February 2010)
(http:/ / www. emvco. com/ documents/ EMVCo_response_to_Cambridge_Report. pdf), EMVCo, , retrieved 2010-03-26
[29] Telegraph - Card fraud: banks now have to prove your guilt, 12 February 2010 (http:/ / www. telegraph. co. uk/ finance/ personalfinance/
consumertips/ banking/ 6338659/ Bank-payments-13-months-to-dispute-suspicious-transactions. html)
[30] Failures of Tamper-Proofing in PIN Entry Devices, Drimer, Murdoch, and Anderson, IEEE Security and Privacy, November/December
2009 (http:/ / www. cl. cam. ac. uk/ ~sjm217/ papers/ ieeesp09tamper. pdf)
EMV 12

External links
• EMVCo (http://www.emvco.com), the organisation responsible for developing and maintaining the standard
• Chip and PIN (http://www.chipandpin.co.uk/), site run by the Association For Payment Clearing Services
(APACS), the UK's central coordinating authority for the implementation of EMV
• Chip and SPIN (http://www.chipandspin.co.uk/), discussion of some security aspects of EMV, from members
of the University of Cambridge Security Group
• What is EMV? (http://www.emvx.co.uk/emv_guide.aspx), a technical guide to EMV transactions, complete
with a glossary of terms a flowchart showing the stages of a typical transaction
• Selected list of EMV data TAGs (http://cheef.ru/docs/HowTo/TAG.info) Smartcard Type-length-value
TAGs, samples, TLV decoder.
Article Sources and Contributors 13

Article Sources and Contributors

EMV  Source: http://en.wikipedia.org/w/index.php?oldid=393717488  Contributors: Aurorasophia, Banej, Barefootguru, Bearcat, Bliksim, BonsaiViking, Bovineone, Cancun771, CesarB,
CharlieMG, ClementSeveillac, Corydon76, Damieng, David.Monniaux, Davidsteed, Dgwbirch, EMVCo Board of Managers, EMVSupporter, Edward, ForthOK, Frispar, Glatk, Guffydrawers,
Guy Harris, H3llbringer, Hadseys, Hairy Dude, Halpernsiegel, Herbythyme, Hopkapi, IMSoP, Ilgicioglu, Jfdwolff, Johnnaylor, Karl-Henner, Kiv, Leeatcookerly, LindsayH, Logi, Lotu, Mauls,
Melsaran, Mike Moreton, MikeKn, Mitch Ames, MrC, NathanBeach, Nigel jewell, Nurg, Olipro, Optimisteo, OwenS, Pathoschild, Pawlov, PeterC, Peyna, Plop, Pol098, Quidnam, Qutezuce,
Rbrwr, Rich Farmbrough, Robindch, Siddhant, SmitherIsGod, Socrates2008, Stephan Leeds, The Anome, The Thing That Should Not Be, The wub, Tonyfaull, Toutoune25, Uncle G,
VISIONTEKTELE, Web-Crawling Stickler, Woohookitty, Yintan, Yousou, Zaian, 111 anonymous edits

Image Sources, Licenses and Contributors

Image:Smartcard3.png  Source: http://en.wikipedia.org/w/index.php?title=File:Smartcard3.png  License: Creative Commons Attribution-Sharealike 3.0  Contributors: User:Channel R
Image:chip pin camera flaw.jpg  Source: http://en.wikipedia.org/w/index.php?title=File:Chip_pin_camera_flaw.jpg  License: GNU Free Documentation License  Contributors: Ear1grey

License
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/