Card holder's name in APDU commands (ICC Card)

Question

We are reading visa card information from APDU commands, here is the command sequence that we are sending

1. 00A404000E315041592E5359532E444446303100
2. 00B2010C00

at this time, we know that we can send Processing Command as 80A80000048302084000 but it will gives us an error, therefore we skipped this command and sent the READ SFI 1 record.

00B2010C00

With this, we can get the card number and the expire date, but we can't get the card holder's name. So if somebody know what is going on, kindly help us.

Answer 1

Reading the card holders name and other info on a chip & pin card is not as simple as you might think.

It's not as simple as just one straight forward APDU , there are several more steps you have to go through first.

First you need to perform an application selection.

How you do this, depends on your card and your terminal.

There are 2 standard ways.

• 1) Application file selection
• 2) AID Scanning

For type 1, you typically call a known file name using the select file apdu

(NOTE: I'm not going to implement full apdu sentences in what I type here as there is just too much data to try and represent, if there is enough attention to this post then I might do a blog entry)

The file name to select for most EMV standard cards is '1PAY.SYS.DDF01' or '2PAY.SYS.DDF01' for contactless cards.

The second method involves keeping a list of AID's (Application identifiers) which you then attempt to read in turn, until you get one or more positive results back. AIDs are those numbers that look something like this:

A00000002501
A0000000031010
A0000000041010

The 3 above are partial matches for 'amex', 'visa' and mastercard and all are credit cards.

Credit/debit/loyalty all have their own AIDs and there are unofficial lists available floating around the net, but in general to get the definitive list you need to shell out some cash and approach the financial services worldwide authority to buy it.

Once you've performed an application selection, and gotten the data from that, to tell you what's on the card, you then need to use what's been returned to read the cards file identifiers.

Decode the data you got back and extract the SFI (Short file identifier), this will tell you the short ID's of the files to read that contain the actual application lists.

The application lists will be a list of entries, each following the same base BER-TLV (Tag length value) objects, and containing the preferred language, the AID (As mentioned in AID selection) and a few other bits.

Once you have your application list, read the directory elementary file from each of those application entries, playing close attention to the priority's, the priority's tell you which application structure you should treat as most important, for example on my UK Visa Debit I have 2 applications.

One for my banks own private network, and one for the UK & Europe 'LINK' network. If I use my card in my own banks cash machines, then their app has priority, but if I use it in any other then 'LINK' has priority.

Once you get to this point, you have an active AID (Either from the application selection list, or via scanning a list of valid AID's your interested in), it's now time to perform 'Final Selection'

Select the file with your chosen AID, then once that's done you need to use the data returned in the TLV object for that selection to perform a GPO call (Get Processing Options)

Perform this GPO call, and that will return yet more BER-TLV data.

Making the GPO tells the card that your ready to start a transaction, the data that's returned from the GPO call, is then used to build the 'PDOL' (Processing Data Objects List) with the PDOL data you can now extract the AIP and AFL (Sorry cant remember what those ones stand for :-) ) which finally, gives us the short file identifiers to be able to read the ADS (Application data structure)

Once you have the ADS, you then have not just the card holder name, but the PAN, expiry date, issuer discretionary data, service code, X509 public certificates and a ton of other stuff.

As I previously mentioned however, for me to actually document the exact APDU flows and an analysis of decoding the various TLV objects, I'd need to make this post about 20 pages long!!

I have however, written several bits of .NET code to work with this stuff over the years, and to be honest I've been meaning to write a blog post on it for more than a year now anyway :-)