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 Commands
By Ian Davidson

Duration: 17 minutes
Released: August, 2009

__________________________________________________________

Abstract:

In this presentation Ian Davidson explains how EMV smart

cards use Data Object Lists to process data and the
commands that the terminal will submit to the card.

Key points discussed by Ian Davidson are:

 Data Object Store

 Data Object Lists (DOLs)
 EMV Commands

In his presentation, Ian helps you to gain a better

understanding of the technical side of processing smart cards
in an EMV compatible terminal.

__________________________________________________

NCR Confidential - Use Pursuant to Company Instructions

Page 1 of 11
 Seminar on Demand
by FSD Learning

(Slide 1)
Hi my name is Ian Davidson and in this
seminar, originally written by Neil Esler, I
would like to explain about DOLs (Data
Object Lists) and the main commands that
the terminal will submit to the card during
normal processing of a CAM application on
an EMV compatible terminal.

(Slide 2)
By now you should have viewed the EMV
Business Overview and the EMV Card
Basics seminars.
Before we get into the EMV processing we
need to understand some key concepts and
commands so first of all we will review what
an object store is and what it does.
Then we will look at what a data object list
is and how we process it.
And finally we will explain what the EMV
commands are and what they do.

NCR Confidential - Use Pursuant to Company Instructions

Page 2 of 11
 Seminar on Demand
by FSD Learning

(Slide 3)
We introduced BER-TLV data objects in the
previous seminar; BER-TLV is the format
used to transfer data between the card and
the terminal.
Data can be obtained from a number of
places.
This can be the terminal itself providing
information such as transaction type,
terminal capabilities, date, time, plus other
transaction and terminal specific
information.
Information will also come from the smart
card through command responses; this data
would include information about the card
capabilities, issuer information and general
personalisation data.
If the terminal is on-line then the card issuer
will also provide information during the
course of a transaction - in addition to that
already on the card.
All of the information from all the different
sources is pooled together and held in a
data store on the terminal.
However, it should be noted that with the
NDC EMV solution, the data store will only
maintain primitive data objects that are
known to the terminal; in our case this
means primitive data objects with valid tags
defined in the EMV standards.

NCR Confidential - Use Pursuant to Company Instructions

Page 3 of 11
 Seminar on Demand
by FSD Learning

(Slide 4)
The next concept to understand is the ‘Data
Object List’ (DOL) and associated
processing.
A DOL is a primitive BER-TLV data object
like any other; however, the value field is
used as a mechanism by which the card
can ask questions.
The value field of the DOL contains a list of
tag and length pairs which are processed
an entry at a time.
The terminal retrieves the data for each tag
in the list; if the length requested in the DOL
is different from the length of the actual data
object then it is truncated or padded as
appropriate to its data type.
Once all the data object values have been
retrieved and formatted they are
concatenated into a single string ready for
submitting to the card via commands.
The data requested by the DOL can only be
primitive data objects, if a constructed data
object is requested then zeroes are used for
the value returned to the card.

(Slide 5)
DOL processing is tricky to visualise so we
will work through a simple example to try
and bring everything into focus.
The data objects are collected from the
various sources and placed in the data
store.
During the course of processing a smart
card, a DOL will be used by the card to
obtain some information from its
environment of use.
In this example the data required is the data
and time; the DOL will have an entry with
the Date tag requesting 3 bytes of
information and another entry with the Time
tag requesting 2 bytes of information.
The two data objects will be retrieved from
the data store and the values concatenated
into a single string.
This string of data will then be submitted
back to the card on the appropriate
command.

NCR Confidential - Use Pursuant to Company Instructions

Page 4 of 11
 Seminar on Demand
by FSD Learning

(Slide 6)
Having examined what a smart card is and
what it will provide in terms of functionality,
it’s time to turn our attention to EMV itself.
Before we get into the EMV processing we
need to understand some key concepts and
commands.

(Slide 7)
We will look at the sequence of processing
in more detail in the next seminar.
For the moment it’s enough to know that
first we must select the application then get
or read all of the data relating to it.
The terminal and the card must
authenticate each other then decide on
how, and if, to authorise the transaction
before finally recording the result of the
processing and running any commands
requested by the issuer.

NCR Confidential - Use Pursuant to Company Instructions

Page 5 of 11
 Seminar on Demand
by FSD Learning

(Slide 8)
The first command we use is the SELECT
command which is defined in ISO 7816.
This command allows the selection of
Directory Definition Files and Application
Definition Files using the appropriate
Application Identifier.
When the SELECT command is used to
access a Directory Definition File then you
will see the Definition File Name (DF name)
and any SFIs (Short File Identifiers) for
Directory Elementary Files returned.
The grey italic text shows data items which
are optionally returned from the card.
In this instance we have the cardholder language preference information and the issuer
code table index (identifying the character set for displaying the ICC application name).
When the SELECT command is used to access an Application Definition File then you will
see different data returned. This time we have no SFI information as the associated
elementary files are now accessed through the application.
However we now have a lot of optional ICC application related information.
The Issuer Code Table Index is the character set that is to be used when displaying the
preferred ICC application name.
The Application Preferred Name is the issuer’s preferred name for the ICC application to
be displayed to the card holder, provided we support the character set referenced in the
Issuer Code Table Index.
The Application Label is the ICC application name to be used if the Issuer Code Table
Index referenced a character set that is not supported, or when certain other conditions do
not allow the use of the preferred name.
The Application Priority Indicator establishes the application’s position in the candidate list
if the card has multiple applications on it.
Also returned from the Select command on an Application Definition File is the first of the
DOLs, PDOL or Processing Option Data Object List. The answers to PDOL are returned
as a string when we issue the GET PROCESSING OPTIONS command.
Finally you may see the Language Preference returned which indicates the cardholder’s
(or issuer’s) preferred language for transactions.

NCR Confidential - Use Pursuant to Company Instructions

Page 6 of 11
 Seminar on Demand
by FSD Learning

(Slide 9)
If we had selected a DDF, then we would
need to retrieve the directory information
from its associated elementary files.
Remember the Elementary Files will tell the
terminal about Application Definition Files or
other Directory Definition Files contained in
the directory.

(Slide 10)
If the SELECT command was used to
select an Application Definition File, then
the next command is GET PROCESSING
OPTIONS.
If PDOL was returned with the SELECT
command then the answers to PDOL are
given to the card with the GET
PROCESSING OPTIONS command which
in turn returns the Application Interchange
Profile and the Application File Locator.
The Application Interchange Profile
specifies the application functions that are
supported by the card. The functions the
card can support are Card Verification using
offline static or dynamic authentication or
online authentication. In addition it
indicates if the terminal should do Terminal
Risk Management.
The terminal should only attempt to use
those functions that the AIP says that the
ICC supports.
The Application File Locator (or AFL) is a
list of files the terminal should read to
continue processing the transaction. Each
entry identifies the file using a Short File
Identifier and the start and end records the
terminal should read from each file.

NCR Confidential - Use Pursuant to Company Instructions

Page 7 of 11
 Seminar on Demand
by FSD Learning

(Slide 11)
So now we know which files to read to get
more information about the application.
The next thing the terminal must do is use
the READ RECORD command. The READ
RECORD command specifies the Short File
Identifier of the application’s Elementary
Files and the record numbers from the AFL.
The minimum data that we need to get back
to continue the transaction is CDOL1 and 2,
the Application Expiry Date and the Track 2
Equivalent Data.
The application can of course return a lot
more information including the Application
Usage Control and Cardholder Verification
Method list that we will look at in the next
seminar.
CDOL1 and 2 are the Card Risk
Management Data Object Lists and they tell
the terminal what data about the transaction
the ICC application requires before it will
consider whether to approve or decline the
transaction.

(Slide 12)
In addition to the data read in the
Elementary files, the terminal must use the
GET DATA command to get at least the
Application Transaction Counter (ATC).
The GET DATA command is used for only
three data objects and they are objects that
are maintained by card but are constantly
changing.
The ATC is a 2 byte counter that the card
increments every transaction, if the ICC
application support it, this can be used with
the last online transaction counter to
determine whether the current transaction
should insist on going online.
There is also the PIN Try Counter which
speaks for itself.

NCR Confidential - Use Pursuant to Company Instructions

Page 8 of 11
 Seminar on Demand
by FSD Learning

(Slide 13)
The ICC application and the Terminal now
go through a number of processes to
determine whether to perform
authentication online or offline and whether
to accept or decline the transaction. These
processes are covered in the next seminar.
If the terminal decides to do off-line
authentication, and the card has indicated
that it allows it, then the INTERNAL
AUTHENTICATE command is used.
The DDOL by the way is the Dynamic Data
Authentication DOL and would have been
one of the records returned using the READ
RECORD commands earlier.
This command returns RSA signed data
that can be used by the terminal to validate
that the card is a valid card from an
authorised issuer.

(Slide 14)
Now that the terminal is happy it is speaking
to a real card it will pass the plain text or
enciphered PIN to the card in the VERIFY
command.
The PIN will be encrypted with the Issuer’s
Public Key which will have been read from
the ICC application in one of the earlier
READ RECORD commands.
The return from the card is an indication of
the PIN being valid or not, and in the case
of the latter, how many retries are
remaining.

NCR Confidential - Use Pursuant to Company Instructions

Page 9 of 11
 Seminar on Demand
by FSD Learning

(Slide 15)
The terminal has three options at this point;
• Firstly it may decide to decline the
transaction, in which case the
GENAC command requests an
Application Authentication
Cryptogram (an AAC)
• Secondly the terminal may decide to
attempt an offline approval then a
GENAC command will request a TC
(Transaction Certificate), to check if
the ICC application also agrees to
process the transaction offline. The
ICC application may accept by
responding with a TC or reject the
transaction by issuing an AAC, or
may request that the terminal goes
online by issuing an ARQC
(Authorisation Request Cryptogram).
• Finally if the terminal decides to
process the transaction online, then
the GENAC command is issued here
to get back an accept or decline from
the ICC application that can be sent
to the issuer. In this case the
GENAC command requests an
ARQC to which the card can agree
to accept the transaction by
responding with an ARQC or it may
decline the transaction by
responding with an AAC.
Even if the card declines the transaction at
this stage, a terminal can go online and see
if the issuer wants to override the decision.

(Slide 16)
Assuming that the issuer has been sent the
data from first GENAC command and has
decided to also accept the transaction then
the next thing (optionally) is to prove the
reply has been from the real issuer.
The data received from the issuer is added
to the EXTERNAL AUTHENTICATE
command to allow the card to verify that the
message is indeed from the issuer and is
not a fake.
Again the card will respond with just a yes
or a no to continue.

NCR Confidential - Use Pursuant to Company Instructions

Page 10 of 11
 Seminar on Demand
by FSD Learning

(Slide 17)
To finish the online transaction, the terminal
issues a second GENAC command
requesting a Transaction Certificate (TC).
This second GENAC command tells the
ICC application that the transaction was
completed by the terminal and the
responding TC is final proof to the issuer
that the card accepted and recorded the
completion of the transaction.
I don’t know whether you noticed but the
first GENAC command used CDOL1 as the
input and this second command uses
CDOL2. The two CDOLs are the Card Risk
Management Data Object Lists.

(Slide 18)
Now that the transaction has completed, in
the online environment the issuer can send
commands to directly affect the ICC.
These include PIN Change or Unlock,
Application Block or Unblock, or Card Block
which will render this ICC unusable.

(Slide 19)
So that completes this seminar.
We started off with the Data Object Store
that takes and stores primitive data from
numerous sources;
We then saw how the ICC uses DOLs to
ask questions about the environment and
transaction.
Finally we looked at the EMV Commands
that are submitted by the terminal to the
ICC Application to drive the transaction.
In the next seminar we will look at how the
terminal can build a list of applications on
an ICC that are suitable for use with that
terminal.

//End of Presentation//

NCR Confidential - Use Pursuant to Company Instructions

Page 11 of 11