Seminar on Demand

by FSD Learning

Seminar on Demand: Study Guide.

Study Guides are designed to accompany Seminar on Demand
presentations by providing a useful reference resource that combines the
presenter’s slides and transcript in a single document.

__________________________________________________________

EMV - Building a
Candidate List
By Ian Davidson

Duration: 13 minutes
Released: August, 2009

__________________________________________________________

Abstract:

In this presentation Ian Davidson explains how an EMV

terminal can use two methods to find all of the applications
available on a smart card..

Key points discussed by Ian Davidson are:

 Payment System Environment (PSE)

 List Method of selecting Applications
 The Select and Read Record commands
 The Application Selection and Initialisation phase of EMV

In his presentation, Ian Davidson helps you to gain a better

understanding of the Application Selection and Initialisation
phase required to be done by an EMV terminal.

__________________________________________________

NCR Confidential - Use Pursuant to Company Instructions

Page 1 of 7
 Seminar on Demand
by FSD Learning

(Slide 1)
This is the fourth presentation in a series of
seminars designed to introduce the core
concepts of the EMV standards and the
technical aspects of processing smart cards
in general.
Hi, I am Ian Davidson and in this seminar,
originally written by Neil Esler, we will look
at the two methods that the terminal can
use to build a list of all the suitable
applications that are available on an ICC,
before finally selecting and starting to use
one.

(Slide 2)
When an ICC is inserted and staged in a
card reader, the first thing to do is power up
the card and get the Answer To Reset from
the ICC to establish comms between the
terminal and the card.
Having established comms the next thing to
do is build a list of applications on the ICC
and determine if they are suitable for use on
the terminal. At this stage the application
may still turn out to be unusable based on
details about the transaction, but until we
have those details we can't tell.

An application on a smart card is normally related to an account type, i.e. your current
account offering, your savings account, a Visa credit card account etc. It is possible to
have an application for other things like services, but normally one application will be one
institution’s account type and this is where you can add branding for your accounts, the
Application Label which is displayed to the cardholder would be something like
“FlexAccount” or whatever the marketing name is for that particular account.
There are two methods of building the candidate list described in the EMV standards, the
Payment System Environment (PSE) Directory Method which checks each directory to
see what files they contain; and the List Method, where the terminal has a list of known
working application identifiers and it tries to select each one in turn.

NCR Confidential - Use Pursuant to Company Instructions

Page 2 of 7
 Seminar on Demand
by FSD Learning

(Slide 3)
So the first method of building the candidate
list is the Payment System Environment
(PSE) Directory Method.
According to the EMV standards, an ICC
that supports the PSE will have a Directory
Definition File called '1PAY.SYS.DDF01' as
the root or Master File. So the terminal
selects the '1PAY.SYS.DDF01' file using
the SELECT command which returns the
Short File Name of its associated
Elementary File or Files.
Using the READ RECORD command on
this (or these) Elementary Files may give
you the name of the Application Definition
File or of another Directory Definition File.
So the terminal does another SELECT
command on the new file which again gives
the name of an Elementary File and so on
until all of the directories and all of the
applications have been discovered.

(Slide 4)
The Master File, 1PAY.SYS.DDF01 is a
Directory Definition File (DDF) which when
selected returns the Definition File Name
and the Short File Identifier of the
associated Elementary Files.
So the terminal then uses the READ
RECORD command until the Elementary
File returns Record Not Found.
In our example on the previous page the
root only contains a single directory so the
first READ RECORD command returns the
name of the Directory Definition File.

NCR Confidential - Use Pursuant to Company Instructions

Page 3 of 7
 Seminar on Demand
by FSD Learning

(Slide 5)
So the terminal will now select the DDF
returned, which then returns the Short File
Identifier of the Elementary File, which
using the READ RECORD command
returns the Application Identifier of the two
Application Definition Files. The third
READ RECORD command returns Record
Not Found so the search is complete.
So the candidate list now contains two
applications; these applications will be
presented to the cardholder for selection in
priority sequence, with the highest priority
application listed first.
If there is no priority sequence specified in the card, the list should be in the order in which
the applications were encountered in the card, unless the terminal has its own preferred
order.
The same applies where duplicate priorities are assigned to multiple applications, or
individual entries are missing the Application Priority Indicator; in which case, the terminal
may use its own preferred order or display the duplicate priority or non prioritised
applications in the order they were encountered in the card.
That is the PSE Directory Method of building the candidate list; remember what I said at
the start though; 'According to the EMV standards, an ICC that supports the PSE…'; in
other words, the PSE Master File, '1PAY.SYS.DDF01', is optional so the terminal must
also support the next, List Method, of selecting applications.

NCR Confidential - Use Pursuant to Company Instructions

Page 4 of 7
 Seminar on Demand
by FSD Learning

(Slide 6)
The second method of building the
candidate list is to start off knowing which
applications you support on your terminal,
then try to select each of the known
application IDs in turn.
This second method is called the List
Method or Explicit Select. In this example,
the terminal supports three applications;
AID1, AID2 and AID3 which are kept in a
list in the terminal that we are calling the
'Terminal Acceptable AID Table'.
Once the terminal establishes comms with
the card we can issue a SELECT command
with the first of the known Application
Identifiers.
In this example this is successful and gives us back the Application Label, the Priority and
the name of the Elementary File or Files associated with this application – although at this
time we are only interested in the Application Label and the Priority.
We issue a second SELECT command which is not successful and a third which is.
So our candidate list now contains the two applications by using just three commands.
To make this method even more useful, the EMV specification allows for the SELECT
command to be used with a partial AID; the AID in the terminal must match the first few
characters of the ADF. So for instance if the first AID on the card was A12345 and the
second was A12346; and in the Terminal Acceptable AID table we had A1234, we can do
multiple SELECT commands with the partial AID, A1234, and get back both applications.
The first and second time we use the SELECT we get back the full DF Name, which is the
AID, the third time we get back '6A82' File Not Found.

NCR Confidential - Use Pursuant to Company Instructions

Page 5 of 7
 Seminar on Demand
by FSD Learning

(Slide 7)
Now that we know the two applications that
are available on this card, we would
normally present those as options to the
cardholder who will select the one to use
this time.
If there was only one application available
then the terminal can automatically choose
that one but be careful, if the Application
Priority Indicator is returned by the SELECT
command then the most significant bit is
used to say if the cardholder must be
allowed to confirm the use of the
application.
With the NDC solution we can always display the Application Label on the PIN screen so
that the cardholder can enter their PIN as confirmation or click Cancel to get their card
back.
OK, so the customer selects or confirms the use of the application, so we issue the Select
command again with the chosen application. At this point, the card returns several
variables to us in that BER-TLV format that we talked about earlier. The application on
the card, tells us the Label for this application and the priority level, it may tell us the
customer’s preferred language and will normally give us a list of questions, a DOL, this
one is the PDOL or Processing Options Data Object List.
In this example PDOL is requesting Terminal Type and is expecting a 1 byte answer; and
Terminal Country Code which is expecting 2 bytes. It is important to remember that each
application may request different data, and our terminal application has to respond with
information known to the terminal, in this case we are returning 14 as the terminal type
and 08 26 as the terminal country code.
We give the card the responses to PDOL using the GET PROCESSING OPTIONS
command which makes the ICC application evaluate whether it is suitable to run on this
terminal. For example your application may be for an account that supports only domestic
transactions, so when the application sees a country code other than its own, it rejects the
use of the application on this terminal. From what we see, it may be that not all
applications are suitable for an ATM environment, but all will be used in a point-of-sale
terminal. It is unlikely, but it is allowable under EMV. Remember with smart cards, the
card is playing an active role in the transaction.
One of the most critical pieces of information that the card will return now, is which folder
and which file we should read data from. This is the data that is going to be critical to
processing such as the encryption keys that will be used later when doing authentication.

NCR Confidential - Use Pursuant to Company Instructions

Page 6 of 7
 Seminar on Demand
by FSD Learning

(Slide 8)
So the next part of application selection and
initialisation is the Read Record command
which we will repeat until we have read all
of the data available from the file that we
have been told to read.
At this stage, the terminal will assess the
suitability of the application from a terminal
perspective. The card has had its say in
whether it is a suitable terminal, now we do
the same from an ATM standpoint.
One of the records that we will have read is
called the Application Usage Control and
one of the fields in that record will be a flag,
Valid at ATMs. If this flag is not set then the
terminal application will reject the usage of
this application. So both sides get their say
in whether an application is usable.
This processing along with a lot more is the
subject of our next seminar.

(Slide 9)

//End of Presentation//

NCR Confidential - Use Pursuant to Company Instructions

Page 7 of 7