29C3: A Rambling Walk Through an EMV Transaction (EN)
Summary
TLDRThe speaker, Tim Becker, provides an in-depth analysis of the EMV (Europay, Mastercard, and Visa) protocol, which is the communication standard between chip-based credit cards and payment terminals. He discusses the history and technicalities of the protocol, highlighting its age and pragmatic design from the 1980s. Becker demonstrates how the protocol works at a low level, explaining the use of APDU (Application Protocol Data Units) for data exchange and the reliance on static data authentication. He also touches on the security aspects, including the potential for man-in-the-middle attacks and the fact that the data transmitted between the card and reader is unencrypted. The talk concludes with a live demonstration of interacting with a card using a card reader and custom Ruby code, emphasizing the accessibility of understanding and experimenting with EMV technology.
Takeaways
- 📍 EMV stands for Europay, Mastercard, and Visa, and it's a payment protocol that facilitates communication between a chip card and a payment terminal.
- 🔍 The presenter has extensive experience in credit card processing and fraud management, having worked at a German bank and a consultancy, and is currently an independent contractor.
- 💡 EMV technology is being mandated in the United States, which will lead to a significant increase in its usage, despite its age and known security shortcomings.
- 🛠 The session covered both basic and low-level aspects of EMV, including text, numbers, and technical specifications, without revealing secrets or sophisticated hacks.
- 💳 The presenter demonstrated how to use a card reader to interact with a chip card, showcasing that no special terminal is needed, and that the process is standardized and accessible.
- 🔗 PC/SC (PCSC) is the method used to connect a card reader to a computer, and most operating systems support it to some extent.
- 📚 ISO 7816 is the standard that defines the low-level characteristics of how the physical layer communicates with the card, which uses a simple serial interface.
- 🛂 APDU (Application Protocol Data Unit) is the method of exchanging packets between the card and the host, and it's a straightforward process of sending and receiving data bits.
- 🔐 The EMV protocol includes various security features such as key derivation, certificates, and data dictionaries, although not all cards use the most secure options like DDA (Dynamic Data Authentication).
- 📈 The general flow of EMV transactions includes card and terminal introduction, application selection, data verification, cardholder verification, and the generation of a cryptogram to validate the transaction.
- ⚠️ The EMV protocol has been criticized for its age and lack of robust security features, and these concerns are carried over to new technologies like contactless payments.
Q & A
What does EMV stand for and what is its purpose?
-EMV stands for Europay, Mastercard, and Visa. It is a global standard for credit and debit card transactions that defines the protocols between the chip on the card and the payment terminal.
What is the significance of the ATR (Answer to Reset) in the context of EMV?
-The ATR is a series of bytes sent by a smart card to the card reader after the card is powered up. It provides essential information for the terminal to communicate with the card, including the supported communication protocols and other settings.
What does PCSC stand for and what is its role in smart card communication?
-PCSC stands for PC/SC, which is a framework for smart card communication. It allows a smart card reader to communicate with a smart card when connected to a PC, enabling the card to be used for various applications.
What is APDU and how does it relate to EMV transactions?
-APDU stands for Application Protocol Data Unit. It is the format of the packets exchanged between the card and the host during an EMV transaction. APDUs carry the commands and data used in the transaction process.
What are the main components of the EMV specifications?
-The main components of the EMV specifications are divided into four books: Book 1 covers general information, Book 2 deals with cryptography, Book 3 specifies the APDUs and card commands, and Book 4 describes the card acceptance environment.
How does the EMV protocol handle security and authentication?
-The EMV protocol uses a combination of chip-based technology, cryptography, and secure messaging to ensure security and authentication. It includes features like static data authentication, dynamic data authentication, and cardholder verification methods.
What is the role of the issuer certificate in EMV transactions?
-The issuer certificate is used in EMV transactions to authenticate the card and ensure the data on the card is from a legitimate issuer. It contains the issuer's public key, which is used to verify a hash of the card's static data.
What is the significance of the AFL (Application File Locator) in an EMV card?
-The AFL is a list of file identifiers on the EMV card that tells the terminal which files to read during a transaction. It is crucial for the terminal to access the correct data, such as the cardholder name, account number, and other relevant information.
How does the EMV protocol handle cardholder verification?
-The EMV protocol provides several methods for cardholder verification, including PIN verification by the card, signature verification, and PIN verification by the bank. The terminal will attempt to use the most secure method supported by the card and available at the terminal.
What are the potential security weaknesses in the EMV protocol?
-Despite its security features, the EMV protocol has potential weaknesses, such as the lack of encryption in the communication between the card and the terminal, which makes it susceptible to man-in-the-middle attacks. Additionally, the reliance on static data authentication can make cards easier to clone.
How does the EMV protocol compare to magnetic stripe transactions in terms of security?
-The EMV protocol is designed to be more secure than magnetic stripe transactions due to its chip-based technology and cryptographic authentication. However, magnetic stripe data is still present on EMV cards, which can be read and potentially cloned, representing a weaker link in the security chain.
Outlines
😀 Introduction to EMV and Personal Background
The speaker introduces EMV, which stands for Europay, Mastercard, and Visa, and explains it is a payment protocol between a chip and a payment terminal. They share their professional background in credit card processing and involvement in software projects related to chip card technology. The talk aims to cover both basic and low-level aspects of EMV, and the speaker expresses their motivation for discussing a topic that, while old and rudimentary, is gaining traction in the United States and has interesting security considerations.
📘 Basic Interaction with the Card and EMV Standards
The speaker dives into the basic interaction with an EMV card, mentioning the use of the ISO 7816 standard for low-level communication and the concept of Application Protocol Data Units (APDUs) for exchanging information between the card and the terminal. They discuss the structure of APDUs, including the use of class bytes, instruction bytes, and data fields. The talk touches on the historical bytes in the card's ATR that can help identify the card vendor.
🔍 In-Depth Analysis of APDU and EMV Specifications
The speaker provides a detailed look at APDU commands, such as 'select', and how they are used to interact with the card's file system. They explain the use of Elementary Files (EF), Directory Files (DF), and the Master File (MF). The talk also covers the importance of the EMV books 1 through 4, which contain specifications for the EMV application framework, including cryptographic practices, key derivation algorithms, and the data dictionary for understanding tags.
🛍️ Transaction Flow and Cardholder Verification
The speaker outlines the general flow of EMV transactions, starting from the introduction between the card and terminal to the selection of the appropriate application. They discuss how the terminal requests information from the card, the cardholder verification methods (such as PIN or signature), and the generation of a cryptogram to secure the transaction. The talk highlights the misconception that the chip is only for data storage, emphasizing that it acts as a small computer performing cryptographic operations.
🔐 Static Data Authentication and Security Considerations
The speaker explains the process of static data authentication (SDA), which involves hashing data and comparing it with a certificate signed by the issuer to verify the card's authenticity. They discuss the limitations of SDA, such as the ease of card cloning due to static certificates on the card. The talk also touches on the potential for man-in-the-middle attacks and the lack of encryption in the communication between the card and the terminal.
💳 Issuer Authentication and Cardholder Verification Methods
The speaker details the process of issuer authentication and the various cardholder verification methods (CVM) supported by the card. They explain how the terminal decides which verification method to use based on the CVM list provided by the card. The talk also covers the concept of issue action codes and how they influence the terminal's decision to perform an online or offline transaction.
🛡️ Terminal Risk Management and Cryptogram Generation
The speaker discusses the terminal's role in risk management and how it uses the card's application file locator (AFL) to determine which data to read and authenticate. They explain the generation of cryptogram by the card, which is essential for proving the card's involvement in a transaction. The talk also highlights the importance of the transaction counter and the card's ability to approve or decline transactions based on the provided data.
📑 Certificates and Data Authentication in EMV
The speaker provides an in-depth look at the issuer certificate and how it is used to decrypt data on the card. They explain the structure of the certificate, including headers, trailers, and public key modulus. The talk also covers the process of static data authentication using a certificate that contains a hash of the card data, allowing verification of the data's integrity.
🔎 Exploring the EMV Transaction Process
The speaker walks through the EMV transaction process, from confirming the cardholder's identity with a PIN to generating a cryptogram for transaction authorization. They discuss the use of different fields in the transaction data, such as the amount, transaction type, and random number. The talk also touches on the card's ability to approve transactions offline and the potential for online authorization.
📉 Limitations and Risks of the EMV Protocol
The speaker concludes by highlighting the limitations and risks associated with the EMV protocol, including its age and the reluctance of card organizations to move away from legacy technology. They discuss the solid nature of the crypto and hardware but emphasize that the protocol's general problems are more significant. The talk also mentions the transfer of these risks to new technologies, such as contactless payments.
🤝 Closing Remarks and Q&A Session
The speaker wraps up the talk with an invitation for questions, emphasizing the availability of the presentation slides and software on GitHub. They address audience questions about the possibility of using magnetic stripe data for transactions, the potential for tampering with magnetic stripe data, and the aspects of card data that are signed and authenticated. The speaker also comments on the variability of the ISO 8583 standard across different countries and its impact on transaction processing.
Mindmap
Keywords
💡EMV
💡APDU
💡PCSC
💡Smart Card
💡Cryptogram
💡Magnetic Stripe
💡Contactless Payment
💡Cardholder Verification Method (CVM)
💡ISO 7816
💡Tag-Length-Value (TLV)
💡Man-in-the-Middle Attack
Highlights
EMV stands for Europay, Mastercard, and Visa, and is the protocol used between the chip on a card and the payment terminal.
The presenter has extensive experience in credit card processing and fraud management, having worked in a German bank and later as an independent contractor.
The EMV protocol is quite old, dating back to the 1980s, and is pragmatic in nature with less emphasis on security.
The technology behind EMV is being mandated in the United States, which will lead to a significant increase in its usage.
The presenter demonstrates how to use a card reader that costs around $20 to perform transactions, indicating low barriers to entry for this technology.
ISO 7816 is the standard that defines the physical characteristics and communication with the card, which is handled by the PC/SC (PCSC).
APDU (Application Protocol Data Unit) is the method of exchanging packets between the card and the host.
The EMV specifications are extensive, with the main application framework described in four books totaling around 800 pages.
Book three of the EMV specifications is particularly important as it contains the specific APDUs and instructions exchanged with the cards.
The PSSE (Payment System Specific Environment) is a file that lists the applications on a card that the card wants the terminal to know about.
The process of authenticating a card and confirming a transaction involves several steps, including static data authentication and cardholder verification.
The card itself performs cryptographic functions and is not just a storage device for data, contrary to common misconceptions.
Contactless payment technologies operate on similar principles to the EMV protocol, with the same potential vulnerabilities.
The presenter discusses the potential for man-in-the-middle attacks due to the unencrypted nature of data transmission between the card and the terminal.
The risk of skimming attacks persists even with chip cards, as fraudsters can insert skimmers into ATMs to capture data.
The EMV protocol has many specifications that are not always implemented perfectly, leading to potential security vulnerabilities.
The presenter's software and slides are available on GitHub, providing a resource for further exploration of the topics discussed.
Transcripts
okay hi um and I don't know if anybody
doesn't know what EMV is and just sort
of came in here by random luck EMV is
stands for europay master visa and it's
it's the protocol that's spoken between
the chip and and and the payment
terminal that you have um
the Euro pay thing should already
suggest to you how old this is because
Euro pay hasn't not been around uh for a
long time um about myself I worked for a
long time at a at a big German Bank uh
in the in the credit card processing in
the backend and then I was working the
last several years at a at a consultancy
doing mainly uh well doing General
technical things but mainly focused
on uh credit card processing backends
fraud management stuff like that and was
involved in several projects where we
actually wrote the software that that
runs on the
chip um since this year I've been I've
been working as an independent
contractor and and working on a lot of
the same sort of
um uh
topics um the motivation for this talk
this talk is kind of weird it's it's
it's it's sort of a strange mixture it's
really basic really introductory to EMV
on the other hand it's super low level
so there's a lot of bits and bites um
we're not going to see a lot of pictures
or anything it's going to be a lot of
text and
numbers I'm not really revealing any
secrets of the credit card industry I'm
not showing any super special hacks and
this stuff is really really old I think
on the first Congress that I was at the
18 C3 um there was already a talk about
this and so the question is why would
you actually want to deal with it one of
the things is um this technology is
being mandated in in the United States
soon so there's going to be a giant
uptake in usage and the other really
part of the thing that makes it
interesting is that this protocol is so
old and this was always a very um
pragmatic protocol and this back in the
80s so there's not a lot of um Security
in it um I'm also not really going to go
into low-level Hardware stuff um
attacking these chips I'm not going to
go into any any attacks on the crypto
and what you'll see though is that this
this protocol is so rudimentary and
weird that it's not really necessary
there's so much more that you can do and
it's also if you were at Carson and
Dexter's talk um about you know scraping
off the chips and and actually taking
pictures uh and and probing the chip in
operation that's I mean they said this
was this would be an this is easy but um
this is a lot easier I mean you can you
can you can just look into your own card
see what sort of data is stored on it
and and do these own transactions with a
with a card reader that cost maybe maybe
20
bucks so I'm going to go through a
this is more or less to get you started
on on doing the stuff yourself so I'm
going to go through a bunch of acronyms
and specifications and stuff I mean the
the stuff that the card can do or that
it could do in the 80s was really really
rudimentary so the protocol is actually
really easy the hard thing is though
that it's a very steep learning curve
there's a lot of weird technology and
acronyms and and and things that aren't
really in common usage that you're not
really used to so going to start off
with pcsc uh pcsc is how you're going to
connect to how you're going to connect a
reader to your um to your to your laptop
basically almost all um operating
support pcsc on some level most
languages have bindings the transactions
that I'm going to do are with some Ruby
code I wrote um this smart card project
is are the um are the pcsc bindings for
Ruby um my um the stemo code that I'm
going to I'm going to be showing that
I'll be talking with this card with um
is available in in my GitHub r
repository under 29 C3 and while I'm
showing URLs there is this open scdp
Smart Card shell which is a JavaScript
implementation which is a lot more
feature complete so if you want to play
around with smart cards that's a really
good suggestions and they also have
stuff for for dealing with Sims or
German the German health card and and
things like
that um so basically that was already
the first point I mean you don't need a
special terminal all of the stuff and
and talking to the card is entirely
standardized you don't need to buy
something like this you can just go to
Amazon and get one of these Swiss army
knife uh card readers that um if you're
paying 20 bucks for them you're getting
ripped off um and they will work just as
good as anything else so it's it's it's
a very very low entry to uh barrier to
entry um so I'll I'll go ahead and start
my little shell and basically this is
just I can see now I have one reader
plugged in fantastic I'll put my card
in
um
um and then what is it dump card dump
card
data show card show card um that will
come later um so this is this is already
the basic interaction with the card
we're connected to the card and and the
session has has already started at this
point um and it's you know we're maybe
two or 3 minutes into the talk so
um all this low-level stuff of how chip
cards are dealt with is is is taken care
of in in ISO
7816 uh you don't really have to worry
about those standards you don't really
need to get them if you are really into
standards you need book three and four
um they Define sort of the low-level
characteristics of how um the the
physical layer communication with the
card which is basically just a uart it's
just a simple serial
interface um and level four uh is is
sort of the the the transport layer
there's rudimentary how how how to talk
back and forth with the card uh again
you don't need any of this the next five
slides will sort of be all you need to
know about it first thing that we saw
here down here this answer to reset um
is basically just the um ATR is the
thing that you will hear it basically is
just the terminal um settings the B rate
and things like that there's one
interesting thing about it if if we're
approaching it from a from a really high
application Level like we are which is
the historical btes um and the vendor
can put anything in there so sometimes
it helps to have those historical bites
to identify who the vendor of a of a
card is that you're dealing with but you
normally don't need to do that because
most of the cards if you look at yours
will have the actual um vendor printed
on the back of the card um you will see
like credit card numbers and stuff from
this card this is a demo card so you
don't need to worry about that I'm I'm
I'm being a total idiot yet um and I'm
using a demo card for the one hand I
don't want my credit card number to be
uh known to you guys and on the other
hand um for the demo cards that that get
handed out at like trade fairs and stuff
you know the keys that are on the card
so you can uh you can you can reverse
engineer the crypto um with
them um so 78164 does a it describes a
couple of further things first they have
this weird file system like thing that
you don't really need to know much about
but if you see terms like EF MF DF those
are either directories EFS are
Elementary files MF is the master start
of the file but don't really they call
it a file system but don't really think
of it as a file system a file in on a
smart card can be anything from an
application to some sort of cyclic
buffer to to all sorts of things but um
em doesn't use a lot of that so we can
we can skip it the main thing that you
need to know is apdu apdu is basically
the the packets that get exchanged
between the card and and the host um and
it's just a bunch of um bites which I
purposely put an exclamation mark behind
it it really I mean you're just
basically assembling five or six bites
sending them to the card and getting
them back there's very little crypto
involved in in the communication so all
of the communication that you'll see in
my demo I'm I'm not doing anything
special to decrypt what's going on I
mean these are really the bites that are
getting back and forth um so I'll just
go through it on one example if you want
to select one of these files or in this
case um an application there's always a
class bite a class bite of zero says
this is this apdu select file is defined
in the ISO standards most of the EMV
ones start with 80 that means it's a
proprietary apdu stuff like that I'm
just going to skip over because it's not
really that important to to to dealing
with and then there will be some
instruction bites um some some apdus
will take uh parameters so there's two
bytes for parameters then if you're
transmitting data you you there's one
bite for the length of the data and
finally um the data that you want to um
transmit so this is basically the
application name of a visa application
on a card what we're doing here is
selecting the visa application to to
make a to make a payment
transaction um there's one more thing
that we
saw here that this card speaks in the
protocol t t equals
z um there's there's two low-level
Communications protocols defined as I
said this whole thing is just a uart and
there's one character-based way of doing
it and one block based doing it and all
that you really need to know
is you can't if you are using t0 um you
can't send and receive data in the same
um packet so if you wanted to have this
last Le is length expected if you you
expect data back from the card you have
to tell the card how much data um you
want back and um if you're using T
equals z you can't send data and expect
to receive data in the same uh packet
but we'll see how that will work in a in
in just a second um but basically what
you really need to know is that the
difference uh doesn't really matter
because T1 is complicated the terminals
all speak both and nobody actually uses
T1 uh at least in in payment cards so
just ignore that so we we just learned
this select command
and
um and we'll just execute it against the
card I don't know is this large enough
to see or should
I yeah so basically
um right here are the bites that we saw
on the slide uh and I used a different
file name I used the one. pay no one
pay. cy. DDF 01 DF is a directory file
um but basically this is just a
well-known file name for a file that's
called the psse the payment service
environment which um Can is basically a
table of contents for the card a card
can have several applications and these
are the applic and the psse lists the
applications that the card wants you to
know about and use so there could be
other applications on the card um but
there don't necessarily need to be you
don't always need a PSC we can um
the response that we get back so I said
you can't send and respond in the same
in the same Transaction what happens
when you do that when you need to do
that anyway in t equals z is
um okay uh if you're this 9,000 is is
interesting the card always um responds
with two status words one and two and if
you get 9,000 that's perfect that's okay
so that's a HTTP 200 um most other
status codes mean errors um but
basically this select gets a 6126 back
and all the
61 status word one error codes mean
there's more data coming and it will be
26
bytes so basically this is one
transaction you can you can ignore the
second one the second one gets um gets
executed automatically when you get the
6100 um response and it says please give
me back the 26 bytes that you told me
that you that you
um that you can give me back so we can
look at the
response uh this is all tag length value
um in here and this is something that's
called the file control information this
is a basically a metadata that
contains
um data about the file that you just
selected one of the things it this one
contains is the name of of the actual
file that we selected thanks very much
uh just typed that in and um this file
is also identifiable by a short file ID
now the special file has
records and each
record uh
basically tells us about one application
on the
card um so this first one this first uh
record
um
contains so this this card contains two
application one is a Visa debit card and
one is a credit
card um and so I I read the first record
out of this PSC file and it tells me
okay this there's one application that's
called Visa debit and sometimes you get
that shown in in a uh in a terminal that
you're that you're that you're paying
with and it also says the priority of
that application so if you need to make
a choice terminal this one has Priority
One so so then we can look at uh check
for more
records um there's a second application
on here the credit application that has
priority too so um and then we the
terminal will keep doing this until it
has a list of all the records finally it
gets a there's no such record um you can
you can quit looking
now okay so that was the basic of how an
apdu works just these these
these the bites on the screen get sent
back and forth and clear text that's
that's it and and the pcsc libraries
have a command transmit data and you
just give it a raw buffer of
data so it's fairly easy to program but
very low
level um
so em has has a huge number of
specifications um the the main
application framework is defined in
books 1 2 3 and four that's about 800
Pages um and I'm just going to skip over
really quickly what what which ones are
important and and which ones you should
look at um book one is maybe interesting
because it contains a summary of all of
the stuff that's in the iso Norms how
these apdus are set up how the lowlevel
UR communication is how the ATR is set
up and stuff like that so it's just a
review of how this stuff works that's
something that that's good to look at um
book two is the one of the most
interesting um books it contains all of
the crypto that's done by the card so um
the card doesn't get
its it gets its own keys but those are
derived for master keys from the bank
all of these key derivation algorithms
are described in here all of the
certificates that are um uh placed onto
the card the format of these
certificates are described in this book
too and the interesting thing is if you
think certificates usually you think
x509 certificates but um in the EM SP
everything was reinvented and and is a
little bit different than than you would
expect it to be um the the most
important book to look at is is book
three which um contains all of the
specific apdus and the instructions that
are exchanged with the cards um how
those work how those
interact um and one of the most
important things and I put a little
heart to emphasize this point is that
there's a data dictionary that explains
what all of the tags mean you know I um
so so here all of the the the you know
the tags are are separated um but
basically you know you don't know what
50 means but you have to look it up and
and know that oh this is application
label and the statea dictionary is
really the thing that you work with most
when when when you're dealing with the
data in the in the card um another thing
that you could look at and this is also
freely available on the net where um
this tlv be is is is is defined this
this is an um International
telecommunications Union standard um and
there's some tricky bits to to doing tlv
the way that they want you to do it then
there's a book four which you can
basically ignore I mean it's it's kind
of funny because it it it tells you all
sorts of stuff of how you should enter
the pin and and how you could Implement
a virtual machine whether you should
interpret by code or or translate it
into the native instruction set of your
terminals Hardware
architecture all the way to um what what
the receipt is supposed to look like
that that the thing prints um but it
fails to mention stuff like what data of
the transactions the terminal supposed
to save to present to the bank later
it's it's really weird I've never used
it it's it's it's sort of fun to skim
through but it's not useful um CPS is
you probably won't ever need it this is
the application that's on the card
before it's in the field that in the
personalization Bureau will be used to
place your personal data onto the card
but if if you're dealing with if if you
want to take a closer look at cards this
is something useful to look at because
it um provides some some really useful
Insight of how data is structured in the
card and what what data is is actually
placed on
it finally um there is CPA so these
books one through four they
describe um a general framework of how
to
make uh applications for financial
transactions they don't actually
describe an
implementation um EMV published one
standard for an application and this is
sort of interesting to look at to see
what actually goes on um books 1 through
4 describe really well the the external
interface but they don't really give you
a good indication of what the card is
supposed to do internally how it's
supposed to check the data they also
leave open a lot of data structures and
what they mean they just say what we'll
see later for example get card
verification results which is a big bit
map of literal checks that the card did
but it doesn't say how what what each
bit is supposed to mean the the actual
implementation um specifies that sort of
information there's also what you will
come across CCD which is also called
doublin core uh it's Common Core
definitions and that goes that's spread
out through all of um through all of the
standards it it specifies some of the
missing pieces so you can um like like
it it will specify a base card
verification results bitfield what you
should put in
there um the specifications that would
be most
interesting
are but you don't really need at the
level that that we're dealing with are
the mchip and bsdc specifications those
are the concrete implementations for
MasterCard and Visa unfortunately those
are proprietary and you can't really get
at those um with MasterCard you really
you can't even get the names or the
current versions of them unless you're a
MasterCard vendor um thisa you can at
least get a list of what the current
specifications are called and and which
ones are available but you'll have a
hard time um finding
them um Okay so we've we've gone over
all the specifications and we're going
to go into uh into actually what happens
and and do a try to get one pound off of
this card um so the general flow of the
trans trans actions in in in normal
human terms would be card and terminal
introduce each other um figure out which
application to use so that's that's the
part we've done so far um then this is
what I call First worst first date ever
it's not just tell me a little bit about
yourself but it's a tell me what
questions to ask you about
myself
um that's what the terminal says to the
card and then the card responds with a
number
of records that it wants the terminal to
read um it doesn't really check that it
reads those records or only those
records um but
it that that's how the mechanism worked
just to introduce it then there's some
simple mechanisms to make sure that the
data that the card returns are actually
valid data and that they come from a
real bank and stuff like that um then
there's
uh what's called card holder
verification so that might be something
as simple as you sign a piece of paper
so it happens totally offline it might
be something that the card checks the
pin or that the terminal or the ATM
sends the PIN to the bank to be checked
and gets a response back and finally the
card will generate a cryptogram with a
um with a symmetric secret key um that
the merchant who owns the terminal can
later present to the bank to prove that
this card was actually involved in the
transaction so one of the common
misconceptions is that the chip is
basically just a dumb storage of data
that's going on so that's not really
what's happening the chip itself is a
little computer um and what
theoretically happens there's a there's
a key on the on the card that can't be
extracted
um and the terminal gives that key a
random number it encrypts that random
number and that way
uh the merchant can prove that this card
was actually physically involved in the
transaction and then nobody just copied
the the card
number okay so we'll do the um tell me
what to
uh uh tell you about myself or whatever
I called it um so first we want we we we
um we want to select this the vstc
application which we figured out the
file name of which we figured out from
um from reading the psse and we get
um we get back another thing of uh file
information data uh basically the same
thing again it tells me the the file
name it tells me the application labels
and some proprietary discretionary stuff
as soon as you see issue or
discretionary or discretionary or
something like that you know you can
ignore it um and it also contains an
application priority indicator that was
in the PSC as well so a lot of cards
don't actually have this PS see they
um the the terminal will just try to um
select the applications directly and and
we'll put them in the right
order so after
we've um after we've selected the first
thing we do is is a get processing
options
command and
uh now I can see this is pretty opaque
data this is response message template
form format one whatever that means um
but this is kind of the most important
um part so um get processing options
there can be something that's called a
processing data object list which would
be returned in the FCI and the select
that wasn't the case here that will be
the card telling the terminal what sort
of data the terminal should provide to
it so the it could say um please when
you call this get processing options
command tell me what sort of terminal
type you are are you an ATM are you a
candy vending machine or whatever um
what the card returns are two data two
pieces of data AIP and
AFL um and this is format one you
remembered that from the
response message template format
one um and it contains two bytes of
AIP so and the second one is really easy
to explain because all those bits in
there are reserved for future use so
they're they're they're always zero and
in this case um 5c I've circled all the
all the bits out of the specifications
what they uh what they mean um this card
supports
stda um card holder verification is
supported it's that's always supported
terminal risk management is to be
performed so the card tells the terminal
kind of what to do which you need to
keep in the back of your head it does
that quite a lot um
and issue issuer authentication is
supported so most of these things don't
really make sense because issue
authentication is always supported card
holder verification is always
supported um and the thing to explain
here is DDA and CDA down here in the
bottom this card only supports SDA
that's static data analysis and that is
how uh in the in the next step once we
have all the data how we check that this
data is actually from the bank in the
static data authentication all of the
data that's to be authenticated is
hashed that hash is put into a
certificate that's signed by the issuer
and so I can get all the data off off of
the card hash it decrypt the certificate
make sure the
hashes um are identical and then I can
see well at least this is the data that
the issuer intended to be on this card
why this is important we'll we'll we'll
see in a minute um unfortunately this is
because it's static um it's it makes the
card sort of trivial to clone because
the certificate is on the card and you
can just read it off of the card and you
can just write it onto another card and
so any copy that you make of this card
will automatically have a correct um
certificate um DDA will also
have um a public will have a public key
mechanism where the um where the
terminal can give the card a random
number and it will cryp that with its
private key and the terminal can decrypt
it so it knows all of the data is
correct and this card is actually in
possession of a secret that's that's
supposed to be on it that I can verify
because the general key on the card is
symmetric only the bank can verify that
the terminal can never can never check
if if any cryptogram that the card
provides is is actually authentic or
real but again this was a pragmatic
protocol back in the 80s and back then
having calculating uh RSA or something
like that was quite expensive putting a
crypto processor on the cards is still
quite expensive um so you can save 50
cents per card or something by not
supporting it I think they're starting
to mandate using it now but this is
still this is still fairly uh recent
card so the next point I'm not going to
go into it too much this is the
application file locator and it's a list
of four byte entries so these are three
application file locator entries the
first bite of each entry um contains the
short file ID that the card wants you to
read um and it's for some reason it's
shifted by three so it's it's the high
five bytes of that uh the second bite is
the first record to start reading the
next bite is the last record that you to
read so this basically means short file
ID one read the first record only short
file ID read records 1 to three short
file ID 3 read records one and two and
the last bite here is interesting
because that indicates which record will
actually go into the static data
authentication so even though this isn't
really a safe way of authenticating the
card not even all of the data that's
being read from the card is being
authenticated um
so so here read records so it does it
goes through here um that Parts the AFL
and it read records uh short file ID
record short file ID one record one 2
one two and
three
and two records from short file ID 3 so
I did that correctly in the
slides This Record here short file ID 3
record one is the only one that is ever
authenticated so
even with this and we can I still have
the last one in the buffer so we can
look at that and that's that's really
a all of this information that we'll go
into into more detail um like the
currency that the card expects the the
expiration date and the effective date
of the card things like that aren't ever
checked for authenticity in this
specific card um usually this is this
this information will also go into into
the
certificates so
this is where the dump card data um came
from so this is all the data that we
collected from the
card um the first the first field is is
fairly simple it's the card holder name
your name would be in that field here
it's simply one because it's
a marketing thing um this is quite
interesting um and also as a as a
general attack um track two and track
one data if you've done anything with
cards this might seem familiar because
this is how magnetic stripes are
structured so basically this card this
this uh this smart card provides the
precise data that's also on the magnetic
card so if you can read out all of this
data you have enough data to clone the
magnetic stripe and and it's already
perfectly formatted in the in in the way
that it's supposed to be formatted on
the magnetic stripe the reason for this
is is that the the bank backend systems
are very very old and they don't
necessarily check all of this uh all of
all of this uh C data that's coming
because it's more complicated and so
what you can do is you can just take uh
on some intermediary system throw away
everything else but these track data
things and then process the transaction
as if it were a normal magnetic stripe
based
transaction um or you can hire uh Visa
MasterCard to do something called stip
where they will have a system in front
of your own back end check all of the um
check all of the chip stuff for you and
just give you the the magnetic stripe
data or you can just ignore to do that
and and and and just not check the check
the EMB stuff at all um then there's um
the issuer certificate the terminals
have lots of CA certificates those sign
these issuer certificates and you need
the issuer certificate to get um to be
able to decrypt the uh the the
certificate that contains the hash with
the with the data that's on the card um
and the rest of the data is is basically
standard the pan is is is the card
number um the expiration date the
effective date this is a card that's
that's issued in England and in pounds
and I'll go into what the other things
mean right here service code again is
something that comes from magnetic
stripes that was one of the things on
here I'm going to skip that because
we're kind of I don't know if I'll even
make it um the first thing that's
interesting is application usage control
um which is again similar
to AIP it's a bunch of big that say what
this card may be used for there's two
two bites in it the first one is FF so
the card could be used for all of these
all of these things which and again
these categories are are really
arbitrary you know I mean what why
differentiate between goods and services
sometimes differentiating between
domestic and international might make
sense but why have a why have a card
that I can pay with to get my haircut
but I can't buy a bottle of shampoo with
it you know this is good and services so
so it's hard to even configure these
things or figure out what they're good
for um and the second bite is in in in
this specific case because it's also
this was the debit card it will allow
domestic so if you're in your own home
country you can get cash back which
would be uh you pay for 10 pounds at at
at the store and and you say well please
give me 20 20 back um and you might not
know where you are internationally so
you might not trust stores anywhere else
to to to do that validly so I mean I can
see how that could make sense the next
thing was the CVM list uh it starts off
with with two amounts and this is a
really really important one um these but
these two amounts aren't aren't never
used so I'm going to skip over this and
then next is a variable length list um
each entry is two bytes long so the
color coding is is is one entry and
these um tell the terminal what sort of
cardholder verifications it should
attempt to do under what
circumstances the first by in in each
entry describes the actual card holder
verification that the card supports so
in this case um this will allow plain
text PIN verification by the card I can
send the card the pin and it will tell
me whether it was correct or not uh it
will support signature it will support
um the pin being sent to the bank and
and being checked there and finally um
this is the nicest one uh none it will
support that as well
and basically the terminal will go
through and and basically if it can
fulfill one of the conditions and these
are the next one the second one is under
which conditions should we use
this um and if it can fulfill it it will
do that else it will try the next one
all the way to the end so basically
these uh these conditions say um do PIN
verification unencrypted if you can do
signature if you can else send the PIN
to the bank if you can and if not don't
worry about it
um so this is quite interesting because
well we're sort of going to going to
going to authenticate the card but um
the card never doesn't know what sort of
terminal you know it doesn't know if
it's in a real terminal or if it's just
sticking in a in a cheap card reader at
some hacker conference so I can't really
trust that I will actually do these uh
these verification methods and
especially not in this order provided uh
another thing to note here and this was
a this was a um this was a um one of the
important hacks recently um as I said
all the data being sent back and forth
between the card and the reader is
completely unencrypted there's no
non-repudiation uh you know the data is
not macked so this is perfect Target for
man in the middle attacks and so the
chip cards are supposed to were supposed
to help to mitigate against skimming
type um type attacks but it turned out
it's a lot easier to actually insert a
skimmer into say an ATM
and then just um
basically read the communication between
the card and and and the and the ATM now
on top of that it's also fairly simple
to modify the um this communication so
one of the hacks that was quite
interesting so we saw that when when we
uh when we read all the data we we we
already have the magnetic stripe data
ready for cloning and and and making our
own card that we can use in Romania or
somewhere to to to at an ATM but now we
want the pin and
technically cards aren't allowed to
accept clear text unencrypted pins at
ATMs I don't know why they're allowed to
do it elsewhere I don't know nobody
would ever install a skimmer in anything
else but so this hack was basically
there was a man in the middle attack a
skimmer or a shim type attack that
whenever the card um sent the sent the
CVM list to the ATM it would say I only
support un encrypt pin please give me
the pin unencrypted and even though the
ATMs wouldn't actually be allowed to do
that I don't know maybe because they use
like candy vending machine firmware in
the ATM they decided okay well if you
say you know send it to me unencrypted
uh I'll just send it to you unencrypted
and then you have the the pin and the
and the Magnetic stripe data and if you
have a nice GSM module in your in your
shim then you can just send that off and
immediately run to the next ATM to to to
to get
money um so and and the whole like I
trust the terminal thing um goes on here
these are issue or action codes and we
have to sort
of uh this gets this gets a little bit
hairy I'm only going to skim over the
details basically while the terminal for
the terminal to um to think about what
it's going to do it fills out this bit
map and basically it has little bits for
for each thing that happens like if the
static data authentication fails it um
it will set that bit if the card is
expired it will set a bit here and this
and there's basically five bytes of bit
maps that can be set and if any of these
correspond this condition will take
effect so if this bit will get set while
the terminal is verifying the card um
the
terminal the card would like the
terminal to decline the transaction
immediately so if we have a look that is
requested service not allowed for card
product so the card might say uh you
know I I don't do domestic services so
please decline that something like
that um if any of these bits are set the
card
um the terminal should ask the card to
go
online and the card will generate a
cryptogram that will get sent to the
bank the bank will decide whether the
transaction is uh authorized or not and
and and it comes back so these are the
conditions under under which that takes
place and default is is quite
interesting because it's if you should
go online but you can't uh you can still
do the uh transaction you can try to to
to do the card off do the transaction
offline with the card and so so I mean
the thing to look at here would be the
difference uh between those so only in
this bit will it will the card actually
have to go um online um
um and that is transaction selected
randomly for online processing so so
again these are these are really weird
uh combinations of things so if the
merchant forced the transaction online
if you pressed the button and said I
want this to be authorized by the bank
the terminal can still try to according
to this uh to this information the
terminal could still try to do it
offline but if there's some sort of
random selection mechanism for risk
purposes to to you know take every 10th
transaction and and send that to the
bank and it can't do it then it could
still it's it doesn't really make sense
so okay so um we're going to confirm the
data and I'm basically just
uh we'll just show one of these um so we
had that issue we had the issuer
certificate if if we decrypt that with
the um with Visa certificate Authority
certificate we get this which based
still looks like random
bytes
um skip over the details so but but this
is described in book two because it's
crypto related and and certificate
related stuff you can see there's a
header 6A and a hex value BC and there's
a bunch of metadata about the
certificate and then the issuers public
key
modulus um so if we look at the the data
more specifically we can see the header
6A the trailer uh BC there's an
expiration date in there and the
interesting part is this bit in the
middle which is actually not the entire
issue public key because it could be
just as long as as as the key that's on
the
uh as as the ca key and you it's okay so
if you have a 1,24 bit um ca key and you
want to encrypt something with it it has
to be in multiples of 1,24 bits as well
so if the ISS key is also 1,24 bits you
can't encrypt it all with all of this
metadata and you have to leave a bit of
the assures public key out so this is
called the remainder which was all also
in here and so to verify this basically
you have to take the
leftmost digits then you put the
remainder on it then you hash it and
then you make sure that this hash
corresponds instead of putting the whole
key into the card and just putting the
hash in there uh they make things rather
diff difficult to deal
with um so this SDA um certificate I
won't go into too much it's very similar
um if we decoded it it would look like
this it has tons and tons of padding and
then it only contains a hash and this
hash is basically a hash over the record
that was marked in the AFL the
application file locator that has the
weird short file ID shifted by three in
it if you remember it it had one marker
that says
this is the data to authenticate which
in our case was just the card holder the
card number and this is basically a hash
over that data so you can take that
record hash it decrypt the certificate
make sure the hash is coincide and then
you know this is the way that the isure
wanted the uh wanted actually put the
data onto the card uh if this card
supported um public key encryption there
would also be uh there would be one
further certificate
um on the card which contains the card's
public
key um and if it's supported
um and there's an option to put a third
public key on there which will be used
to to encrypt the pin um basically what
happens is
um the um the cards public key
certificate will also contain all of the
static data but it will also have a key
uh inside of it so you can recover that
key and then you send the card a random
number the Rand the card will encrypt
that random number with the private half
of that key you can decrypt it and then
you don't only know that the data that's
on the card is what the issue intended
to be on the card but that the card also
contains the the corresponding secret
and is able to to do calculations with
it this is if you if you want to have a
look at that it's in also in book three
in the the uh the command is internal
authenticate so finally finally we
confirmed the card holder what we did in
uh we saw this card
does uh offline unencrypted pin the pin
is formatted in this very special way uh
two is an indicator that this is done in
a very special way four is the length of
the pin and then you have uh the pin is
BCD coded um so you could have up to uh
two two three four five six I think this
is a you could have like TW a 12 digit
PIN if wanted to on the card um so then
we just say verify the pin I don't know
if I need to put pin in yep and it was 1
2 3
4 which is incidentally the combination
on my
luggage um and the 9,000 again that's
always the status word that says okay so
this is the right pin as as the
um the terminal now knows well this has
to be a legitimate card
holder
um so finally we need to seal the deal
now we had I left out two things and
that was the SE doll we've heard doll
before and now we get to C1 so this is
basically lots of tag length value stuff
I've again colorcoded the differences
they're all stuck together and it this
tells the
terminal what data what transaction data
and further data it expects from it to
generate its cryptogram
with um so basically it wants the amount
amount would be for cashback it wants
the country that it's in and the um and
the currency code so it can do offline
checks that it that it hasn't already
authorized too much data on on offline
um again transaction date you really
don't know what it's going to do with it
because this card has expired for like 3
years and it doesn't really know that
because I tell it that it's still
2010 um and it wants a random number um
in there
so that's the data that that we stick
together and then we have to request a
type of um according to the terminal
verification results and the um and the
issue or action codes that we saw
earlier we have to decide do we want to
request this transaction to to be
declined do we want it to be authorized
by the bank or would we like the card to
try to approve it so if we put this
together um which I've already done for
the sake of time these are all the
fields um so amount one we want to get
one pound uh amount two we're not going
to do cash back we're in the
UK um currency is the same it's October
10th
2010 transaction type is um it's it's 0
is purchase um then this number is of
course very random and I stick all of
that together and that will be the
seedall data that I sent to the card and
then I can can do a first generate a
c
and so and and the response I get um is
also sort of
random um this is this is this is the
clarification for the response the and
this is different unfortunately so the
first bit is the cryptogram information
data and that will tell me just because
I want the card to authorize something
online doesn't mean it has to it can
also say I want to talk to the bank or
I'm going to just decline it right away
so this basically says whether it was
authorized or not um the application
transaction counter is a lifetime
counter the card can never do more than
65,000 whatever
transactions um the bit in the middle is
the actual
cryptogram and um the isser application
data is what contains these these the
card verification results we're not
going to look at that so this
cryptogram uh information
data that I that I got when I was when I
was trying it out with this card um was
eight so was an arqc the card wanted to
go
online um in this case we got a
40 so we we have a
TC and um that's the card approved our
transaction so we're done uh what we
would do in case we we wanted to go
online there's a SE doll 2 for second
generate AC and that would want in this
case the authorization Response Code
from the bank and we can just tell it um
and that worked just fine we can just
tell it z z Bank said okay uh
typically typically there'll also be
some sort of cryptogram from the bank
coming back and and the card will want
that and we'll um and we'll par it so
just in order to
um so this this is basically who I got
back now this is an but we can we can
uh skip that so in conclusion I mean
this is a really really old protocol it
doesn't really mitigate the proper risks
that that that go against it for example
when you're when you're actually when
you're making these cards um you take
them to Laboratories the chips get
stripped and and and they shoot lasers
at it hoping that they'll flip some sort
of bit that will make the card reveal
its its secret key it's it's symmetric
secret key um which is
ridiculous because basically if I if I
if I steal your card I mean the options
are oh I can I can I can get a
laboratory for €500,000 and shoot lasers
at it and do all sorts of stuff or I can
just hit you over the head until you
tell me you're a pin because that one
key that I extract from from your card
will allow me to clone your card and not
anything else um so all of these so so
so the crypto and and and and and the
hardware is fairly solid it's you could
probably find lots of stuff too
depending on which card you're using but
just the
general problems in the protocol are are
much larger and and one of the one of
the big problems is that these are these
are being um transferred to new
technology as well so the banks are
really or or the card organizations are
very reluctant to part with this Legacy
technology um all of the contactless
stuff that's that's coming into the
field now work identically there's no
there's there's no transport layer of
protection to those either and and they
they switch the commands around a little
bit but basically it's exactly like uh
like what you saw
so that was it um if somebody has
questions I am also available after the
talk these slides and the software
um I showed are should be available on
the Vicki I don't know if they're up
uploaded
yet um
um yeah and if anybody has any questions
I'd be happy to uh if you have any
questions please line up at the
microphones perfect we have one question
on the right hi if I understood you
correctly it's possible to just use the
magnetic stripe data to do an
transaction is that right well if you're
in Europe at least you're so so what
what's coming out now is is a lot of
these things like square and in in
Europe there's lots of clones off of
that and square worked well because it
just uses the magnetic stripe data in
the United States cards only have
magnetic stripe data the whole point of
these credit card scheme was to have one
card that you can use anywhere in the
whole world
so they can't really mandate that the
terminals in use can only do can only do
em because then Americans couldn't buy
stuff here and the other way around they
can not put magnetic stripes on European
cards because then you couldn't go to
the states and buy
something and basically you can also
just break them there was a there was a
year 2010 bug in in German cards and the
easiest way to get around it was just to
smash the chip and break it and then it
would fall back to Magnetic stripe um so
yeah you still always have that weakest
link of of processing through the
magnetic stripe data yeah what I was
wondering about is whether it's um
possible to temper with the magnetic
stripe data that sent oh yeah and um
thereby check whether Banks actually
check all the crypto things or whether
Banks just do the easiest thing take the
magn stripe data that sent and uh don't
Implement all of the crypto things on
the bank side is it possible to do
experiments in such a way or
not well I mean it would be I wouldn't
do it because you
would I mean that would be illegal right
um and you would also have to do it in
in in the field you know so playing
around with this at home is absolutely
no risk it's you know it's your card and
even even if you break it uh if playing
around with it you take it to the bank
they won't see that anything's wrong
with the chip because they can't look
inside it nobody understands the stuff
and they'll just say oh but we want you
to use your card to buy so and you'll
get a new card immediately so there's no
risk in that
you could that would be a good way to to
to find out whether car whether banks
are actually checking the magnetic
stripe data but you would have to alter
the data on the well okay if you clone
the chip make your own
card um just use random keys for the for
the for the for for the for the
cryptogram stuff um then you could check
whether they actually check the
cryptogram which they doesn't always
happen yeah more like a sort experiment
uh whether it's whether it would be
possible to to test what the banks
actually that would be a good way to
test it yes but I they would also it be
easy to get caught as
well are there any more
questions no please give a warm Applause
to our speaker Tim Becker hello hello
thank
you one more question from the left hand
micro um I have a short question um what
what part of the stuff on the card is
actually signed so for example if my
card doesn't support cashbacks can I put
it into a reader and set one in there
and got the sh and got a cash back um
that that that would be an interesting
thing to look at for individual cards um
I've never found anywhere where there's
some suggestions of what you should sign
but not everybody necessarily does that
so for example all of in this card which
is I mean it's a demo card from Visa
it's obviously VI ly what they kind of
expect you to do they didn't
sign any of this stuff and that included
the seedall data that the card needs to
be sent to generate the cryptogram and
more importantly it included these these
risk action codes you know like when
when are you supposed to decline a
transaction when are you supposed to do
that um and what it also didn't include
was what it certainly didn't include
because that's not usually in these
records is the the application file
locator that tells the terminal what
data to read in the first place so
you're authenticating something but you
read that from the card and you don't
really have any way to know that that's
actually what the card wanted you to
read um so what also wasn't um done here
for example the the certificate
Authority public key the way that you
get that back so if those are ever
revoked you could put you know you could
use another key because that one was was
crack um and and a part that I forgot to
mention what um what what's quite
important
I said that the card isn't really a dumb
storage for data what what most people
think um all of the stuff that we got
with read
record um so all of this card
data that part is just a dumb storage so
the card doesn't know about any of this
the card doesn't know its own card
number it's just stored somewhere in a
filing cabinet but it doesn't use that
for any any any any um any calculations
it doesn't know about any of these
action codes so it doesn't know if the
teral is actually doing the right thing
or
not um but yeah the way that what parts
are actually um encrypted and and and
people forget to put important Fields
into into the certificates all the
time or not all the time I mean they
shouldn't um and but you I'm I'm sure
you could find cards where um vital
pieces are not um actually
authenticated because this is really
complic I mean try to put together stuff
like this this is like that there there
are these guidance rules but nobody you
know it's just like well okay I'll do it
like it says in the
document and the people that make those
decis sorry last last sentence you know
and the people who make those decisions
a lot of the times I mean either they're
really really highly knowledgeable at
Banks but a lot of the time they're just
the project manager for some credit card
project and the normal decisions they
make is what picture goes on the card
you know and then you expect them to
like figure out all these these bit maps
I mean that's not the usual case but
that that happens as well so thank you
very much and thank you there is another
question from the right hand microphone
um not really a question more like a
comment you mentioned that uh that
standard didn't uh tell anything about
what gets sent to the bank for learning
more about it it's ISO
5853 8583 yeah which is uh funnily
supposed to be a standard but it's
somewhat different in different
countries and and that leads to
interesting hustle and another thing was
you were seem to be wondering about why
they would be caring about whether
something is goods or services uh there
are some some payment cards that only
accept for example um paying for
services and even paying for certain
kind of services uh for example I have a
card in my wallet that only let me pay
for lunch ah okay yeah that would make
sense internationally or the
um uh at at the moment unfortunately
only in Finland but maybe maybe the
company that made it will spread um so
8583 is is is at the last level towards
the banks or the card institutions the
protocol that will get spoken and that's
even more than um than EMD is is it's
kind of like XML it just it's just
defines a general framework of how such
a protocol should look and that's why
every single implement a is different
and it's really complicated and
convoluted so the people who do the
entire um specifications of the concrete
protocols usually screw stuff up or make
it make it very difficult to
the any more
questions doesn't look like it well give
a nice round of
applause
تصفح المزيد من مقاطع الفيديو ذات الصلة
Everything you need to know about EMV | emerchantpay
How to mask a field on an Adaptive Card for Input of passwords or sensitive data in Copilot Studio
[HINDI] Networking Basics | Part #54 | Application Layer | File Transfer Protocol (FTP)
TCP vs UDP Comparison
What is Modbus and How does it Work?
Prüfungsvorbereitung Fachinformatiker Firewallregeln
5.0 / 5 (0 votes)