December 2010 Santa’s Crypto Get-together in Prague
Unleashing EMV Cards
For Security Research
Tomáš Rosa
crypto.hyperlink.cz
December 2010 Santa’s Crypto Get-together in Prague
Remember…
The one and only purpose of this
lecture is to promote rigorous
academic research of payment
cards security.
Any presentation of possible results shall obey all the rules
of academic ethics as well as of responsible vulnerability
disclosure paradigm…
December 2010 Santa’s Crypto Get-together in Prague
Agenda
EMV card transaction process
essentials – contact interface
Certain immediate issues
CAP/DPA overview
Contactless cards – RF interface
Certain immediate issues
NFC and payment cards
December 2010 Santa’s Crypto Get-together in Prague
Foreword
EMV is a Europay-MasterCard-VISA general chip
payment cards application framework.
It is publicly available at www.emvco.org as EMV Book 1-4.
This presentation cannot substitute the Books. It shall rather
serve as a quick reference guide for security researchers.
Card associations, however, define their own nonpublic
extensions of EMV.
Whenever possible, we are basing on the pure EMV.
If a particular out-of-EMV topic is presented, we are basing
on publicly reachable sources only.
Publicly leaked documents [15] are used for examples only
without being included into the rigorous citations.
December 2010 Santa’s Crypto Get-together in Prague
Part ONE
EMV Card Transaction Process Essentials
December 2010 Santa’s Crypto Get-together in Prague
Foreword
We describe the whole transaction flow
solely from the chip card interaction
viewpoint.
Since we are focused on APDUs only.
Between the steps mentioned hereafter,
several decision procedures usually occur.
For instance – terminal/card risk management,
online authorization, etc.
EMV book 3 gives a concise overview of them.
December 2010 Santa’s Crypto Get-together in Prague
TLV Everywhere & Anywhere
The data model of the whole payment card
application relies on ASN.1/BER tag-length-value
encoding really heavily.
List of general tags can be found in EMV book 3 and [5].
If a template is used, tag-length fields can be omitted.
TLVs can be spread out anywhere around the
application, e.g.:
ATR history bytes (even so…)
SELECT response template
Elementary data files (of course)
Getting a picture of the whole card basically means
catching various TLVs whenever you see them.
So, BE PREPARED!
December 2010 Santa’s Crypto Get-together in Prague
Notation Regarding TLVs
We use *(tag) to denote the Value
from the particular TLV record.
E.g. *(9F36) is the value of ATC.
If the tag is not present in the particular
card setup, we assume it takes its default
value instead.
December 2010 Santa’s Crypto Get-together in Prague
#1: Application Selection
Described in EMV book 1.
Either direct approach based on a
predefined AIDs list,
or an indirect one based on the
“1PAY.SYS.DDF01” PSE redirector.
This is a DDF providing just one EF with several
records listing available AIDs.
PSE stands for Payment System Environment.
December 2010 Santa’s Crypto Get-together in Prague
Certain AIDs
A0 00 00 00 04 80 02MasterCard CAP
A0 00 00 00 04 30 60Maestro
A0 00 00 00 04 10 10MasterCard
A0 00 00 00 03 80 02VISA DPA
A0 00 00 00 03 10 10VISA debit/credit
A0 00 00 00 03 20 10VISA Electron
December 2010 Santa’s Crypto Get-together in Prague
#2: Get Processing Options
CLA=8x (80), INS=A8 (GET PROCESSING
OPTIONS)
Starts the payment transaction.
Besides the others, Application Transaction Counter (ATC,
tag 9F36) is incremented.
Expects variable list of initial data (PDOL, tag 9F38).
The list is either default, or specified in application selection
response template.
Response includes Application File Locator (AFL, tag
94).
List of short elementary files identifiers and record numbers.
December 2010 Santa’s Crypto Get-together in Prague
#3: Read Application Data
CLA=0x (00), INS=B2 (READ RECORD)
Reads the files and records listed in AFL
obtained in step 2.
Data structure obeys ASN.1 based TLV syntax.
Recall, it is not so important which file the data
comes from, it is the tag that decides.
So, you have to obediently read all those
records listed in AFL while collecting the TLVs
you get for their later processing.
December 2010 Santa’s Crypto Get-together in Prague
#4: Data Authentication
Static Data Authentication (SDA)
Simple digital signature verification (message recovery scheme).
AFL indicates which records are signed.
No APDU activity here.
Dynamic Data Authentication (DDA)
Implicit static data signature verification (via public key certificate
attribute) together with a challenge-response chip authentication.
INTERNAL AUTHENTICATE (CLA=0x (00), INS=88).
Combined DDA/Application Cryptogram Generation (CDA)
Extended form of DDA.
Potentially interesting for side channel attacks on asymmetric
cryptography (DDA and CDA employ RSA computation).
Further details are described in EMV books 2 and 3.
December 2010 Santa’s Crypto Get-together in Prague
#5: Get Data
CLA=8x (80), INS=CA
Allows retrieving certain specific data
which are not obtained during step 3.
ATC (tag 9F36)
Last Online ATC Register (tag 9F13)
PIN Try Counter (tag 9F17)
Log Format (tag 9F4F)
December 2010 Santa’s Crypto Get-together in Prague
#6: Offline PIN Verification
CLA=0x (00), INS=20 (VERIFY)
Optional, execution depends on the
Cardholder Verification Method
chosen.
Expects PIN blob (possibly encrypted).
Returns OK/FAIL (unprotected).
Successful attack presented in [11].
December 2010 Santa’s Crypto Get-together in Prague
#7: 1st Application Cryptogram
CLA=8x (80), INS=AE (GENERATE AC)
Authenticates certain transaction processing
data with MKAC or its derivative.
Input data are described in CDOL1 (tag 8C)
field obtained during step 3.
Response includes CBC-MAC together with
some application specific data.
Needs to be profiled card-by-card.
December 2010 Santa’s Crypto Get-together in Prague
AC Types
Transaction approvedTCTransaction Certificate
Online authorization
requested
ARQCAuthorization Request
Cryptogram
Referral requested by
the card
AARApplication Authorization
Referral
Transaction declinedAACApplication
Authentication
Cryptogram
MeaningAbbreviationType
Encoded in Cryptogram Information Data (CID, tag 9F27).
December 2010 Santa’s Crypto Get-together in Prague
#8: Issuer Authentication
CLA=0x (00), INS=82 (EXTERNAL
AUTHENTICATE)
Can be also part of 2nd GENERATE AC
command processing.
Occurs in transactions authorized online.
Processes the Authorization Response
Cryptogram (ARPC, proprietary tag).
Uses symmetric key MKAC or its derivative.
The eventual derivation has been usually made
before (e.g. in step 7).
December 2010 Santa’s Crypto Get-together in Prague
#9: Issuer Script Processing
Various APDUs belonging to the issuer script batch.
Used for card (re)personalizations, counters update, PIN
unblock/change, etc.
Security relies on a variant of Secure Message scheme
according to ISO 7816.
Pretending the ISP activity, the attacker could also
gain useful side channel data here.
This approach is, however, considerably more
complicated and beyond the scope of this introductory
lecture.
December 2010 Santa’s Crypto Get-together in Prague
#10: 2nd App. Cryptogram
CLA=8x (80), INS=AE (GENERATE AC)
Completes the whole transaction.
The same computation as in step 7, the input data,
however, are described in CDOL2 (tag 8D).
Allows the card to reflect results from online authorization
procedure.
Finally allows or declines the whole transaction.
Should be performed even if we do not plan side channel
measurement for it – just to calm down the card risk mgmt.
No more GENERATE AC commands allowed for the
particular transaction.
Another transaction must be started (causing ++(*9F36))…
December 2010 Santa’s Crypto Get-together in Prague
Part TWO
Certain Immediate Issues (contact if.)
December 2010 Santa’s Crypto Get-together in Prague
PIN-less Computation
It is still common belief that EMV cards allow
cryptographic computations only after a
valid (client) PIN is presented.
This assumption is, however, FALSE.
PIN (offline) verification is just a part of EMV
application service (cardholder verification).
It is not linked to any authorization for the APDU
processing itself.
If the card was requiring to always perform
offline PIN verification, it would be merely
useless for any real life payment application.
December 2010 Santa’s Crypto Get-together in Prague
Prime Target
Regardless the PIN is entered or not, the
GENERATE AC command is accessible.
Assuming the whole application is not blocked.
This APDU forces certain CBC-MAC
computation using the card master key
MKAC or its ephemeral derivative.
MKAC is a highly secure value protecting the
online card authentication procedure.
This is the very natural place where to start
with e.g. side channel experiments.
December 2010 Santa’s Crypto Get-together in Prague
Risk of MKAC Disclosure
The attacker could freely forge EMV card
responses during transaction authorization.
For SDA-only cards, the complete duplicate of
the card can be made.
Even for DDA or CDA cards, the attacker could
still succeed with Man-In-The-Middle attack.
In CAP/DPA application, the attacker could
issue a valid transaction over the client
banking account.
December 2010 Santa’s Crypto Get-together in Prague
Notes on AC Computation
Sometimes, there is no MKAC derivation
applied, the master key itself is used again
and again…
This property is highly welcome from the side
channel attacks exploration viewpoint.
Sometimes, the MKAC is shared with the
contactless part of the application.
This allows extension of possible RF side
channel attack on the whole card.
December 2010 Santa’s Crypto Get-together in Prague
Cautionary Note on APDU
Integrity Checks
There is a weak protection of the ISO 7816
interface in between the payment card and
the terminal (e.g. the POS).
Only certain parts of certain APDU messages
are cryptographically protected.
The attacker can spy/modify/insert messages in
this channel relatively easily, provided she has a
suitable HW equipment allowing her to play the
role of MITM.
Rather classical attack was presented in [11].
December 2010 Santa’s Crypto Get-together in Prague
Certain Extension of [11]
During practical verification of [11], we have met a
payment cards with PIN Try Counter set to 0.
This actually means, that offline PIN verification was
blocked. Note it seems to be the only “legal” way on how
to block offline PIN, since for a majority of cards the
associations require offline PIN to be in the CVM list.
We have been informed, that these cards:
support the PIN-change functionality,
are working correctly in POS transactions.
Direct mounting of the “Chip&PIN Broken” attack
was obviously impossible.
December 2010 Santa’s Crypto Get-together in Prague
GET DATA Integrity Failure
The PIN Try Counter is to be read by the
GET DATA(9F17) command.
Recall there is no cryptographic integrity check
for its response.
Extending the MITM scenario to also spoof the
GET DATA response, the whole attack started
working again…
Therefore, setting PIN Try Counter = 0 is not a
countermeasure against [11].
Furthermore, all the data accessible through
GET DATA must be considered as potential
subjects to forge!
December 2010 Santa’s Crypto Get-together in Prague
Velocity Checking Spoofing
Another example of GET DATA integrity failure.
Now, we focus on Last Online ATC Register (9F13).
Assuming the MITM attack, it is possible to force *(9F13) =
*(9F36) – 1 = ATC – 1; we further assume ATC > 1.
Doing so, the (offline spending) velocity checking done by a
terminal is minimized.
Furthermore, the „new card“ terminal check is bypassed as well.
Finally, the attacker could continue spending money offline
without being forced to undergo online authorization.
Spending limits check done by the card is not affected this way. On
the other hand, the attacker does not care for SDA/DDA cards. The
attacker simply spoofs the TC response as well, since the terminal
cannot check application cryptogram when working offline.
December 2010 Santa’s Crypto Get-together in Prague
Modest MITM Experiments
inverse card connector relay core board
original card
MITM
December 2010 Santa’s Crypto Get-together in Prague
Frequently Rumored Question
Is it possible to create working
magnetic-stripe card basing on the
data stored on the EMV chip?
December 2010 Santa’s Crypto Get-together in Prague
Magnetic Stripe Recalled
Up to three data tracks.
Track 1 (RO), F2F modulation, 210 bits/in
PAN, cardholder name, expiration, service code,
discretionary data incl. cryptographic checksum, etc.
Track 2 (RO), F2F modulation, 75 bits/in
PAN, expiration, service code, discretionary data incl.
cryptographic checksum, etc.
Track 3 (RW), F2F modulation, 210 bits/in
Data for offline transaction processing.
Using track 3 is obsolete, now.
December 2010 Santa’s Crypto Get-together in Prague
Public Standards Apply
Following standards create general magnetic stripe framework
for payment cards.
Particular details (cryptographic checksums, discretionary
processing data, etc.) are subjects to particular proprietary
extensions described by the respective association.
Anyway, it definitely pays off to look at those public sources.
ISO 7811-2, ISO 7811-4, ISO 7811-5
recording techniques, data encoding
location of tracks
ISO 7813
data format of track 1 and 2
ISO 4909
data format of track 3
December 2010 Santa’s Crypto Get-together in Prague
F2F Modulated Data Example
Peeks correspond to magnetic flux changes as observed by a reading head (track 1).
Physical fingerprinting based on magnetic noise is a possible countermeasure against
skimming attacks. It is, however, really seldom used in practice.
December 2010 Santa’s Crypto Get-together in Prague
Cross-channel Attack
Re-creation of data tracks based on EMV
chip data, contactless chip data or even
data printed on the card itself.
Theoretically possible.
Since there is often no physical fingerprinting
used, we can take any data we have and put
them on arbitrary magnetic stripe.
However, nowadays it shall be regarded as a
configuration failure, since mechanisms already
exist to prevent this attack.
December 2010 Santa’s Crypto Get-together in Prague
Countermeasure no. 1
Cryptographic checksum values used to protect
tracks data are (computationally) independent for
each potential data storage.
So, there is e.g. a different code required for the magnetic
stripe and the particular track data stored in EMV chip.
In particular, it is a shortened 3DES CBC-MAC computed
over PAN, expiration, and service code.
This prevents re-creation of original magnetic stripe from
data obtained “elsewhere”.
It also prevents forced fall-back from EMV card to a stripeonly
card by altering the service code value.
December 2010 Santa’s Crypto Get-together in Prague
Countermeasure no. 2
There is a mandatory processing data
element (DE 22) indicating which interface
was used to enter transaction PAN, etc.
It distinguishes data entered through magnetic
stripe, chip card reader, RF interface, keyboard,
etc.
It prevents e.g. entering contactless chip data
through magnetic stripe reader while still
regarding them as a kind of legacy contactless
transaction (and hence use different rules for
card and cardholder verification).
December 2010 Santa’s Crypto Get-together in Prague
Note on Shimming
Instead of magnetic stripe, the chip and its communication is
the prime target, now.
Attacker uses a very thin PCB plate inserted and fixed in the
contact area of the EMV terminal.
The PCB also bears a miniature low-power microcontroller.
The whole device is referred to as a shim.
It works as MITM in the ISO 7816 channel.
Particular details of these attacks are not publicly known, yet.
Despite not being theoretically surprising, these attacks are
rather new in the criminal area.
Apparently, EMV protocol security research starts to be
especially important, since it is desirable to know how far these
shimming attacks can ever go…
December 2010 Santa’s Crypto Get-together in Prague
Part THREE
CAP/DPA Overview
December 2010 Santa’s Crypto Get-together in Prague
CAP/DPA Technology
Allows using an existing payment
cards infrastructure for authentication
of clients and their payment orders in
e.g. internet banking applications.
MasterCard – Chip Authentication
Program (CAP)
VISA – Dynamic Passcode
Authentication (DPA)
December 2010 Santa’s Crypto Get-together in Prague
Based on EMV Framework
For CAP/DPA, we use mainly:
offline PIN verification via VERIFY cmd.,
online card authentication via
GENERATE AC cmd.
Other services play more or less
insignificant roles here.
SDA, DDA, CDA, etc.
December 2010 Santa’s Crypto Get-together in Prague
Application Topology
CAP/DPA allows
either sharing exactly the same application for
payment transactions as well as for client
authentication,
or installing a separate application (stub) that
shares only a certain data objects.
Usually, the concept of two separate
applications is applied.
Shared: offline PIN, PAN (tag 5A), etc.
Independent: ATC (tag 9F36), AIP (tag 82),
MKAC, file locators, etc.
December 2010 Santa’s Crypto Get-together in Prague
Security Cornerstone
The CBC-MAC computed by GENERATE AC is
transformed (decimated) using the Issuer
Proprietary Bitmap (IPB, tag 9F56) vector.
The result is displayed to the client using a numerical (or
some more general) alphabet. It is then used as a kind of
one-time password at the bank.
The Card Verification Result (CVR, proprietary tag) flags
(part of CBC-MAC input data) must indicate a successful
offline PIN verification. This is an implicit countermeasure
against [11].
Recall that the CBC-MAC is computed using MKAC
or its derivative.
MKAC is therefore the cornerstone of the CAP/DPA
security.
December 2010 Santa’s Crypto Get-together in Prague
Public Information
Further public information on
CAP/DPA can be found in [1].
Presents certain reverse engineering of
CPA/DPA protocols together with some
comments on how (not) to design real life
applications.
December 2010 Santa’s Crypto Get-together in Prague
CAP/DPA Readers
Besides their original purpose, these device
can also serve the role of EMV etalons.
Spying the reader action helps a lot to
understand all those practical aspects of EMV.
If necessary, a MITM technique can be used to
force the reader to work with the real payment
application instead of the CAP/DPA stub.
Simply say “not present” for the CAP/DPA AID.
December 2010 Santa’s Crypto Get-together in Prague
CAP/DPA Teachers
Confused about the new card?
Just take the CAP/DPA reader and let it
show you the way…
Especially, the CDOL1/2 filling for the
1st/2nd GENERATE AC commands
deserves certain attention.
Details are elaborated in [13].
December 2010 Santa’s Crypto Get-together in Prague
Learning the Lessons…
December 2010 Santa’s Crypto Get-together in Prague
Part FOUR
Contactless (CL) Payment Cards
December 2010 Santa’s Crypto Get-together in Prague
Design Objectives
Despite not being explicitly declared, we can
see the following objectives are obeyed:
standard-based RF interface,
simplified data exchange to improve
communication reliability and speed,
certain backward compatibility with mag. stripe,
offering higher security standard if possible,
compatibility with EMV framework if possible,
offline transaction authorization is preferred.
December 2010 Santa’s Crypto Get-together in Prague
Standard Interface
The RF interface is based on widespread
ISO 14443 A/B.
Terminal must support both A and B variants,
the card may choose one.
At this moment, this is the only part which is
covered by EMV.
Covers card detection, singulation (anticollison),
and activation [7].
Anything else at EMV is just a stub, now [8].
December 2010 Santa’s Crypto Get-together in Prague
Application Selection
PPSE method returns AIDs directly in
FCI template of “2PAY.SYS.DDF01”
Subsequent record reading is omitted.
PPSE stands for Proximity-PSE and is
mandatory for VISA and MC CL cards.
contrary to the PSE for contact cards
December 2010 Santa’s Crypto Get-together in Prague
MagStripe Compatibility API
Originally developed (perhaps) mainly for
USA markets.
Allows CL cards acceptance with minimum
existing infrastructure changes.
We call them “1st generation” cards, now.
Their security was – to say – not surprising [9].
Today, we see them as a separate application
besides the “2nd generation” card profile.
Not surprisingly, there is certain suasion to
remove this profile at all.
December 2010 Santa’s Crypto Get-together in Prague
VISA’s PW-qVSDC
This is an obvious refinement, in fact also
replacement, of VISA Low-Value Payment (VLP)
mechanism as it was specified for VISA chip cards
version 1.4.
PW stands for Pay Wave.
qVSDC stands for quick-VSDC
VSDC (VISA Smart Debit/Credit) is the name of the EMV
contact application of VISA.
The new protocol is even more atomic and faster than
VLP.
On the other hand, the integration with the contact (VSDC)
application is nearly the same as for VLP.
Mainly with respect to offline spending counters reset.
December 2010 Santa’s Crypto Get-together in Prague
MasterCard’s PP-M/Chip
Very similar to the M/Chip application
available through the contact interface.
PP stands for Pay Pass
Changes or refinements often due to a
reflection of RF communication.
VERIFY(PIN) not available in PP-M/Chip
Static data shall not contain personal data.
Strong push towards CDA method to enhance
security of transactions authorized offline.
Etc…
December 2010 Santa’s Crypto Get-together in Prague
How to Approach CL Cards
At this moment, the application interfaces
are proprietary, covered by confidential
materials.
On the other hand, the RF communication is
publicly known thanks to the EMV standard.
We can silently assume the application interface
is somehow similar to that one for contact cards.
We shall look, listen, and experiment…
December 2010 Santa’s Crypto Get-together in Prague
Dual Cards
Dual interface smartcards are often used for
payment cards supporting both contact and
contactless applications.
Instead of producing hybrid cards with two
independent chips.
Furthermore, there is a certain visible
interconnection in between these two
applications.
E.g. offline counters reset, application blocking, etc.
December 2010 Santa’s Crypto Get-together in Prague
Part FIVE
Certain Immediate Issues (RF if.)
December 2010 Santa’s Crypto Get-together in Prague
APDU Protection
Similarly to EMV contact interface, there is
often no cryptographic APDU protection.
Regarding the nature of RF interface, this can
be potentially dangerous.
We can see some tries to cope with this on the
application layer.
Personal data shall not be accessible.
VERIFY(PIN) is not accessible.
…
On the other hand, systematic treatment on the
transport layer would be more appropriate.
December 2010 Santa’s Crypto Get-together in Prague
Key Management
Sometimes, keys can be shared in
between contact and contactless
application parts.
Potential side-channel attack targeted at
the RF interface can threat the contact
application security as well.
It is definitely recommended to keep all
the keys separate whenever possible.
December 2010 Santa’s Crypto Get-together in Prague
UID
Probably, the UID of the CL interface is not involved
in the upper layer protocol protection [7].
Obviously, there is no UID-based key diversification, etc.
Moreover, the UID is often constant.
Comparing to the electronic passports case, this can be
viewed as a “certification weakness”.
This can allow or simplify certain attacks.
Using NFC controller as a card emulator with no special
UID-treatment (cf. www.libnfc.org).
Active/passive radiolocation of card holders. At this
moment, this is rather theoretical threat which can,
however, become practical with a time.
December 2010 Santa’s Crypto Get-together in Prague
Part SIX
NFC and Payment Cards
December 2010 Santa’s Crypto Get-together in Prague
NFC at Glance
Device equipped with the NFC front-end can work in the
following modes:
Passive-mode initiator (or just a “reader”)
Passive-mode target (or just a “tag emulator”)
Active-mode initiator/target (or just “reader-to-reader”)
Covered by the ISO 18092 standard
In fact, several parts duplicate the ISO 14443 A or FeliCa, but
with a rather “innovative” wording.
Attention – the word “passive” does no longer equal to “without
autonomous power source” here.
It is used to address those ISO 14443 A or FeliCa compatible modes
in general (reader as well as tag).
Furthermore, ISO 21481 addresses possible RF interference
issues of NFC and other standards occupying 13.56 MHz.
Those mainly are ISO 14443 and ISO 15693.
December 2010 Santa’s Crypto Get-together in Prague
NFC and Payment Cards
NFC-equipped device can address CL
payment cards world in two ways
As a terminal
ISO 14443 A – passive-mode initiator
As a card itself
ISO 14443 A – passive-mode target
December 2010 Santa’s Crypto Get-together in Prague
NFC-based Payment Card or Terminal
The principle is easy – simply implement the
particular payment card API or payment
terminal functionality (e.g. POS) over the
NFC front-end.
The question is, however, which module will
then:
hold all those sensitive data, and
perform all those certified code procedures.
At present, this problem seems to be solved
only for certain special devices.
Namely for GSM phones.
December 2010 Santa’s Crypto Get-together in Prague
NFC in GSM Phones
So far, this is rather a marketing stunt than anything else.
Some manufacturers already provide at least one NFC-equipped
phone, but this is merely a testing sample.
We can see them as generation-zero devices.
Furthermore, several incompatible architectures do exist, now.
What seems to be the future:
SIM card is the security cornerstone.
Also called Secure Element here.
The payment card (or terminal – e.g. POS) application runs on
the SIM card and communicates directly with the CLF
(contactless front-end).
Phone-side application is possibly involved only indirectly.
Either through separate SIM interfaces (SIM-Toolkit over ISO 7816-3
or even web services over ISO 7816-12),
or through a serial link to the monitor firmware running on CLF.
December 2010 Santa’s Crypto Get-together in Prague
CLF
Provides SWP (Single Wire Protocol) interface.
Described in public standards:
ETSI TS 102 613 (physical and data link layer),
ETSI TS 102 622 (host controller interface).
At present, CLF can be bought separately.
Cf. e.g. www.bladox.com
Seldom GSM operators, however, issue SWP-capable
SIMs, now.
SWP<->USB interface converter is one of those wanted
technical projects, since CLF seems to be a valuable tool
for security analysts in itself.
December 2010 Santa’s Crypto Get-together in Prague
Hacking Into&With NFC
When successfully mastered, the NFC is a vital tool
for any security analyst.
Mainly the passive-mode target promises, obviously, many
interesting applications.
The whole approach has, however, two steps:
Hacking into NFC. While it is relatively easy to buy a
device with a NFC controller, it is much harder to get full
documentation for it.
Even the NFC devices themselves try to somehow limit their
usage for this purpose – e.g. UID setting obstacles.
Very important and useful project is www.libnfc.org.
Hacking with NFC. The NFC devices can be used to
implement e.g. relay (wormhole) or MITM attack, etc.
December 2010 Santa’s Crypto Get-together in Prague
Hacking with GSM-NFC
We shall start taking the relay (wormhole) attacks really
seriously!
Their principle is very simple, but their impact can be very
dangerous [2], [14].
Once NFC in mobile phones becomes reality, we can expect
enormous rise of these attacks, since GSM phone:
is fully programmable,
offers sufficient network connectivity,
is highly inconspicuous.
Unfortunately, EMV standard for contactless interface data link
layer [7] is such that it:
does not provide any explicit distance bounding protocol,
relies fully on ISO 14443 augmented with ISO 7816-4, which is a
combination known to actually facilitate rather than prevent relay
attacks [10].
December 2010 Santa’s Crypto Get-together in Prague
Conclusion
The area of chip payment cards attains several
acmes.
Highly complex and mature, widespread, highly important
for almost everybody, impressive financial potential, etc.
Surprisingly, there are just a few academic papers
touching the security of chip payment cards.
The reason is, perhaps, the horrible obscurity of this area.
This lecture tries to clarify the most important topics.
It also points out several parts where to start researching.
It, of course, cannot substitute hundreds of pages the
researchers will probably have to read.
It can, however, provide a tiny light and encouraging
guidance during their first steps on their own way.
December 2010 Santa’s Crypto Get-together in Prague
Thank you for attention…
Tomáš Rosa
crypto.hyperlink.cz
December 2010 Santa’s Crypto Get-together in Prague
References
1. Drimer, S., Murdoch, S.-J., and Anderson, R.: Optimised to Fail: Card Readers for Online
Banking, Financial Cryptography 2009,
www.cl.cam.ac.uk/~sjm217/papers/fc09optimised.pdf
2. Drimer, S. and Murdoch, S.-J.: Relay Attack on Card Payment – Vulnerabilities and
Defences, 24C3, December 2007,
www.cl.cam.ac.uk/~sjm217/talks/ccc07relayattacks.pdf
3. EMV Integrated Circuit Card Specification for Payment Systems, Book 1 – Application
Independent ICC to Terminal Interface Requirements, v. 4.2, June 2008
4. EMV Integrated Circuit Card Specification for Payment Systems, Book 2 – Security and
Key Management, v. 4.2, June 2008
5. EMV Integrated Circuit Card Specification for Payment Systems, Book 3 – Application
Specification, v. 4.2, June 2008
6. EMV Integrated Circuit Card Specification for Payment Systems, Book 4 – Cardholder,
Attendant, and Acquirer Interface Requirements, v. 4.2, June 2008
7. EMV Contactless Specifications for Payment Systems, EMV Contactless Communication
Protocol Specification, v. 2.0.1, July 2009
8. EMV Contactless Specifications for Payment Systems, Entry Point Specification, v. 1.0,
May 2008
December 2010 Santa’s Crypto Get-together in Prague
References
9. Heydt-Benjamin, T.-S., Bailey, D.-V., Fu, K., Juels, A., and O'Hare, T.:
Vulnerabilities in First-Generation RFID-Enabled Credit Cards, In Proc. of
Financial Cryptography and Data Security 2007
10. Hlaváč, M. and Rosa, T.: A Note on the Relay-Attacks on e-passports – The Case
of Czech e-passports, IACR ePrint 2007/244, June 2007
11. Murdoch S.-J., Drimer, S., Anderson, R., and Bond, M.: Chip and PIN is Broken,
2010 IEEE Symposium on Security and Privacy,
www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
12. www.emvlab.org
13. Rosa, T.: EMV Cards Trivium – Fast Way to Side Channel Experiments, June
2010, crypto.hyperlink.cz/files/emv_side_channels_v1.pdf
14. Weiss, M.: Performing Relay Attacks on ISO 14443 Contactless Smart Cards
using NFC Mobile Equipment, Master’s thesis in computer science, May 2010,
www.sec.in.tum.de/assets/studentwork/finished/Weiss2010.pdf
15. Certain “leaked” documents available e.g. through www.google.com