Reading public data of EMV card

Question

Say I want to read public elements of EMV card. I will list some steps which I think are involved.

1. First, select application
   In order to select application we must:
   (1) find out AID of application using PSE (if present)
   (2) Try existing AID list.

Now, imagine I successfully selected application using one of the two methods above.

My question is: What steps I must undertake further to read the public elements of EMV card? More precisely: Do I need to provide card with PDOL and get AIP and AFL (http://www.openscdp.org/scripts/tutorial/emv/initiateapplicationprocess.html) using GET PROCESSING OPTIONS and then read out the records?

Or after selecting application like I mentioned initially, I can directly proceed with something like this (reading out records): link to source?

Adeleadelheid

Answer 1

The EMV specifications for payment systems are publicly available at http://www.emvco.com/. These specifications contain details processes and flows how EMV compliant payment terminsal can read that data from a card, so you could simply implement the relevant parts of these specifications.

To summarize, what you would typically do to get the static data stored on the card:

1. Find the application (as you indicated).
2. Select the application by its AID.
3. Read the data files using READ RECORD commands (usually the first few records of the first few files contain the interesting data). On the cards I tried so far, there is no requirement to issue a GET PROCESSING OPTIONS command first, but you can only get a list of actual files/records relevant to transactions by issuing the GPO command and evaluationg the AFL sent by the card. But you can still use a brute-force approch to find the records relevant to you.
4. Read the data elements using GET DATA commands (of course you need to know what data elements you are looking for).

Barrister

Hi Michael thanks. Are you sure about GET DATA command? I have heard for it for the first time. ??? ps. Indeed here: #13119004 also says one can try reading all records without using "GET PROCESSING OPTIONS". But this GET DATA command you mention confused me – Adeleadelheid

I don't know if that's part of the standard, but all of the MasterCard and Visa chip application implementations I have tested so far contain several readable data elements (they could be a result of the way the application is personalizable, though). Just try with a couple of EMV DOs and check if your cards give any results. – Barrister

I meant I haven't heard of those commands. I know only READ RECORD and SELECT commands. Also check the answer to question I linked, it doesn't mention GET DATA either. – Adeleadelheid

GET DATA is just another ISO/IEC 7816-4 command (like READ RECORD, SELECT, and many others). – Barrister

Ok just I meant what I have seen so far (some code, question I linked, etc.) only READ RECORD and SELECT was enough to get the data I mentioned ... – Adeleadelheid

Michael one more question if it is ok. We know there are two ways to select app. (1) using PSE or (2) using AID. My question is: what if I use method (2) always? Is it OK? And never use method (1) for example. The reason I am asking it maybe less work to use method (2) than method (1) - so if method (2) does all that method (1), why use method(1)? – Adeleadelheid

As defined by EMV 4.3 book 3 (7.3 Data Retrievable by GET DATA Command), GET DATA can only retrieve the Application Transaction Counter (ATC), PIN Try Counter, Last Online ATC Register, and Log Format. And only the ATC support is mandatory for the card. You wouldn't be able to retrieve, for example, the card number and owner using GET DATA. Going through GET PROCESSING OPTIONS AND READ RECORD wold be the proper way. – Gambado

Answer 2

Just to add to Michel's excellent answer:-

• You don't need to select PSE or PPSE before selecting the AID of the payment application but by doing so you should get a list of payment apps present on the card. You can safely skip this step if you want.
• GET DATA can indeed read the data mentioned by Nicolas Riousset as well as a whole lot of proprietary data from either Visa and MasterCard. You would need a Visa or MC spec to know those tags for the proprietary data.
• GPO to read AFL and AIP is not necessary but if you don't use this you need to use brute force and check all SFI and records. Wouldn't AFL be easier? The PDOL doesn't need to provide real data to the card - just supply the tag requested by the card with a '00' bytes value of the requested length.

Boarish

Hi, thanks. Yes, I was just mentioning maybe selecting app using PSE has advantage over selecing app using predefined list of AIDs (e.g., which can read more cards?). I think I might not need GET DATA, I just want to read basic info such as card holder name, expiry, etc. – Adeleadelheid

Some very old cards may not have a PSE in which case you need a list of AID's to check but mostly the PSE is the best way to find out what is on the card. If you just want card holder name, expiry and some track equivalent data then you can use read record. Be aware that the track equivalent you read from the chip can't be used on a real magstripe. The CVV stored in the chip is different to the one in the actual magstripe. – Boarish

No, I have contactless reader. And just wanted basic info, so thought directly using predefined list of AIDs – Adeleadelheid