29C3: A Rambling Walk Through an EMV Transaction (EN)

Summary

The 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

00:00

😀 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.

05:00

📘 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.

10:01

🔍 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.

15:02

🛍️ 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.

20:02

🔐 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.

25:03

💳 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.

30:05

🛡️ 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.

35:06

📑 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.

40:06

🔎 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.

45:08

📉 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.

50:09

🤝 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.

Keywords

💡EMV

EMV stands for Europay, Mastercard, and Visa, referring to the global standard for credit and debit card transactions that use a chip (integrated circuit) to store and protect cardholder data. It is central to the video's theme as it discusses the protocol's security, history, and technical aspects.

💡APDU

APDU stands for Application Protocol Data Unit, which is the protocol used for communication between a smart card and a card reader. In the context of the video, APDU is a key concept as it explains the packet structure for data exchange between the card and the terminal during a transaction.

💡PCSC

PC/SC is a set of standards that define a method for application programs to communicate with smart cards. In the video, PCSC is mentioned as a way to connect a card reader to a laptop, which is crucial for the speaker's demonstration of interacting with the card.

💡Smart Card

A smart card is a plastic card that contains an embedded microprocessor. In the video, the smart card is the primary subject, as it delves into how data is stored and processed on these cards, particularly in the context of EMV transactions.

💡Cryptogram

A cryptogram is a piece of information that has been encrypted in some way. In the context of the video, the cryptogram is a key element in the transaction process, used to authenticate the card and ensure the transaction's legitimacy.

💡Magnetic Stripe

The magnetic stripe is the band on the back of a credit card that stores the cardholder's account information. The video discusses the magnetic stripe as a fallback or supplementary method to the chip in cases where chip technology is not used or fails.

💡Contactless Payment

Contactless payment involves using a card or device with near-field communication (NFC) to make a payment without physically inserting or swiping the card into a reader. The video touches on this technology as an evolution of the EMV standard, noting its similarities and security considerations.

💡Cardholder Verification Method (CVM)

CVM refers to the method used to verify the identity of the person presenting the card, such as a PIN, signature, or biometric verification. In the video, CVM is discussed as a critical part of the transaction process, highlighting the different types and the order of verification methods.

💡ISO 7816

ISO 7816 is a series of standards that define smart cards and their interfaces. The video mentions ISO 7816 as the standard that deals with the physical characteristics and communication protocols of the card, which is foundational to understanding how the card operates.

💡Tag-Length-Value (TLV)

TLV is a method of encoding data in a form that is widely used in computer networking and storage. In the video, TLV is discussed in the context of how data on the card is structured, with the speaker explaining the importance of understanding TLV for parsing data from the card.

💡Man-in-the-Middle Attack

A man-in-the-middle attack is a type of cyber attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. The video discusses this type of attack in the context of card transactions, highlighting the vulnerabilities present in the unencrypted data transmission between the card and the reader.

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