EP2EMV+Multi Custom+12 11 2009

EMV
Part 1 : Technical Presentation

Part 2 : Certification Process
Part 3 : Easy Path to EMV Training Course
1 •
E.M.V (Part 1)
Technical presentation :
“A summary of EMV specifications”
2 •
EMV - Summary
EMV in a few words

EMV Data Management
EMV Transaction overview
Security impact
EMV implementation
Glossary
3 Easy Path to EMV • Training course

EMV in a few words : What is EMV ?
Common requirements initially created by :

Europay, MasterCard and Visa (now MCI and VISA)
Main goals to enable smart card utilisation for payment :
– Global requirement :
• Versatile specification,
• Open to be adaptable to local rules
– Guarantee interoperability :
• EMV Cards shall be usable worldwide.
• Cards from any country should be accepted on any terminal

EMV in a few words : Why a Smart Card ?
SWIPE card SMART Card

Only one application in the card Multi-applications capability
– Debit/Credit
– E-purse
– Loyalty …
Not secure : Easy to duplicate High security level, with dynamic data
authentication
PIN online verification only Enable off-line PIN transaction with same
security level
All intelligence in terminal or host Card takes its own decision
Card has static behaviour Scripts can be sent to dynamically

customise card behaviour
And EMV C’less technologie is now coming …

EMV in a few words : Benefits and Loss
Cost
 Fraud reduction
 Reduced communication cost
Cards are more expensive, especially when a high security level is required
New infrastructure needed :
• Terminals must be updated or replaced to manage smart cards
• Host must be updated to manage new data
 Transaction Time
 With off-line transactions, no time lost in communication with the host.
 With slow terminals, transaction time may be quite long
 Need to change habits
 Need to learn a PIN code , Card insertion in the terminal
 New Points of acceptance possible (where online capability is a problem), new
use possible (restaurant, unattended terminal, outdoor markets …)

EMV in a few words : Which requirements ?
 2 levels of Requirements :
Level 1 : Physical layer and Data Link Layer
Level 2 : Application Layer
only latest release of specification is valid :

EMV 4.2 June 2008
see also a set of evolutions “bulletins” published by EMVCo

EMV in a few words : Where to find requirements ?
EMV requirements are available freely on internet :

www.emvco.com
 EMV Requirements 4.2 are split into 4 books :

Book 1 : EMV Level 1 + Application Selection
Book 2 : Security requirements.
Book 3 : Application Description
Book 4 : Others interfaces
 Bulletins edited for specification updates, or explanations

EMV in a few words : Transaction Actors
Issuer Provides card to Cardholder

 Wants to be sure that card won’t be used fraudulently
Cardholder Payment card Owner

 Wants to be confident card can’t be duplicated or used by any other
person.
Merchant Accepts card for payment

 Wants a fast transaction, low cost
 Wants to be sure he will be credited for transaction amount
Acquirer Merchant terminal Provider. Handle communication

with issuer
 Wants to be sure accepted cards are genuine

EMV in a few words : Transaction principles
 Roughly, a transaction is driven by both ICC (i.e issuer), and terminal

(i.e acquirer).
EMV application and parameters in ICC may change between different
issuers.
EMV application and parameters in the terminal may also vary.
On the same terminal, the behaviour of an EMV transaction may change
completely from one card to an other or even with the same card
depending on :
Application Selection process, (depending on terminal an card capabilities and
parameters)
Cardholder Verification Method used may change, depending on terminal and
card capabilities and parameters, and on transaction data values.
Transaction may be performed online, or offline, of declined offline
Issuer host response to require a referral, or to send scripts.

EMV - Summary
EMV in a few words

EMV Data Management
Security impact
EMV implementation
Glossary

EMV Transaction : Card Description
EMV Cards are 7816 compliant

EMV Cards may be either T=0 or T=1
A subset of 13 commands is defined in EMV, with provision
for proprietary commands or future commands

EMV APDU Commands
COMMAND Description
APPLICATION BLOCK Used only in scripts
APPLICATION UNBLOCK Used only in scripts
CARD BLOCK Used only in scripts
EXTERNAL AUTHENTICATE Host authentication
GENERATE APPLICATION Generate a cryptogram used for
CRYPTOGRAM clearing
GET CHALLENGE Generate a random number
GET DATA Read Data of the application
GET PROCESSING OPTION Initiate application
INTERNAL AUTHENTICATE Compute Dynamic Data
Authentication value
PIN CHANGE/UNBLOCK Used only in scripts
READ RECORD Read a record in a file
SELECT Select a file (application)
VERIFY Ask for a PIN verification

Card directory structure
Follows hierarchy, as described in ISO 7816

One DDF (Directory Definition File) may be defined if
several applications are present in the card.
A DDF may reference application and other sublevel of
DDF
 One single name “1PAY.SYS.DDF01”, for the root DDF, if
the PSE method is supported
For each application present in the card, one ADF
(Application Definition File) is defined
Each ADF contains some AEF (Application Elementary
File)

Card directory structure : Sample 1
ADF1
AEF1 AEF2
•PSE method not supported

•One single application
•2 elementary files

DDF
“1PAY.SYS.DDF01”, DIR FILE
ADF1 ADF2 ADF3
AEF1 AEF2 AEF1 AEF2 AEF3 AEF1 AEF2
•PSE method supported

•1 level hierarchy structure
•3 EMV applications in the card

DDF
“1PAY.SYS.DDF01”, DIR FILE
DDF2 DIR FILE ADF3
ADF1 ADF2 ADF4
AEF1 AEF2 AEF1 AEF2 AEF3 AEF1 AEF2 AEF1

•PSE method supported
•2 levels hierarchy structure
•4 EMV applications in the card
•Application 4 not linked with the payment structure

EMV Data – Data Object
 All Data are expressed in the form of TLV (Tag, Length,

Value :
 Tag : Coded on one or more bytes, unique data identifier
 Length : Data length (may be zero)
 Value
 Data objects can be basic or constructed. Value of a

constructed Data Object contains a list of Data Objects,
basic or constructed again
Tag Length Constructed Value
Tag Length Value Tag Length Value …

EMV Data – DOL Principle
 Principle :The Data Object Lists (DOL) are used when the ICC
needs the terminal to send a list of data.
 The ICC sends the data list requested to the terminal, as a
constructed data Object, containing Tag and Values
Terminal Tag1 Length1 Tag2 Length2 … ICC
 The terminal looks for the value of each Data Object in its Data
base. It fills a record with all the values concatenated and sends
this record to the terminal.
Terminal Value1 Value2 … ICC
 Dol defined in EMV :
PDOL : Sent to the ICC with the GET_PROCESSING OPTION Command.
DDOL : Used for the Dynamic Data Authentication
CDOL1, CDOL2 : sent to the ICC with the first and second GENERATE AC Command
TDOL : used to construct a TC Hash value, for the GENERATE AC Command

EMV Data – ICC
 up to 4 Data Objects, transaction dependent, can be read

through GET_DATA command :
 Application Transaction Counter : Mandatory
 Last Online ATC Register : Optional
 Pin Try Counter : Optional
 Log Format : Optional
 Most of other Data Objects, not transaction dependent, are

to be read in AEF files, using READ_RECORD command
 Some other Data are only returned in response to specific

commands :
 Application File Locator (AFL) : GET PROCESSING OPTIONS
 Application Interchange Profile (AIP) : GET PROCESSING OPTIONS
 Cryptogram Information Data (CID) : GENERATE AC

EMV Data – Terminal
Data inside terminal can be regrouped into 3 sets
 Application Independent Data : General terminal characteristics

 Local Date, Local time
 Terminal Country Code
 Transaction Sequence Counter
 Terminal Type
 IFD Serial Number
 Application Dependent Data : AID Parameters

 Application Identifier,
 Certification Authority Public Keys
 Default DDOL, Default TDOL
 Terminal Capabilities, Additional Terminal Capabilities
 Terminal Action Codes
 Terminal Floor Limit, Threshold Value for Biased Random Selection
…

 Transaction Dependent Data :

 Transaction Amount
 Transaction Type
 Terminal Verification Result
 Transaction Status Information
…

Transaction Status Information (TSI)

2 bytes bit field : Each one represents an operation made by terminal
Defined values :
Offline data authentication was performed
Cardholder verification was performed
Card risk management was performed
Issuer authentication was performed
Terminal risk management was performed
Script processing was performed
Terminal Verification Result (TVR)

 5 bytes bit field, filled during transaction, an image of all test results.
 Each time a test or a process fail , relevant bit is set in TVR
 Used at the Terminal Action Analysis step for the terminal decision.

EMV Data – TVR
TVR – Byte 1 TVR – Byte 2

8 Offline data authentication was not 8 ICC and terminal have different application
performed versions
7 Offline static data authentication failed 7 Expired application
6 ICC data missing 6 Application not yet effective
5 Card appears on terminal exception file 5 Requested service not allowed
4 Offline dynamic data authentication failed 4 New card
3 Combined DDA/AC Generation failed 3 RFU
2 RFU 2 RFU
1 RFU 1 RFU

EMV Data – TVR
TVR – Byte 3 TVR – Byte 4

8 Cardholder verification was not 8 Transaction exceeds floor limit
successful 7 Lower consecutive offline limit exceeded
7 Unrecognised CVM 6 Upper consecutive offline limit exceeded
6 PIN Try Limit exceeded 5 Transaction selected randomly for online
5 PIN entry required and PIN pad not processing
present or not working 4 Merchant forced transaction online
4 PIN entry required, PIN pad present, but 3 RFU
PIN was not entered
2 RFU
3 Online PIN entered
1 RFU
2 RFU
1 RFU

EMV Data – TVR
TVR – Byte 5
8 Default TDOL used
7 Issuer authentication was unsuccessful
6 Script processing failed before final
GENERATE AC
5 Script processing failed after final
GENERATE AC
4 RFU
3 RFU
2 RFU
1 RFU

EMV Transaction Overview
Find a matching application

Application Selection between card and terminal
Initiate Application Provide ICC information about

transaction
Read Application Data Read Card data for selected AID
Ensure card is genuine

Data Authentication

Verify compatibility between

Processing Restrictions terminal application and ICC
version
Ensure that the person using ICC
Cardholder Verification is the real card owner
Terminal Risk Evaluate transaction risk level

Management
Terminal Action Terminal decision for transaction
Analysis

Inform ICC with terminal decision.
Card Action Analysis Ask for card decision
Online Processing If required, ask for issuer

decision
Issuer to Card Script Allows issuer to send scripts

commands to ICC before Completion
Processing 1
Completion Terminate the transaction
Issuer to Card Script Allows issuer to send scripts

commands to ICC after Completion
Processing 2
EMV Transaction Flow
Application Selection Terminal Risk Management
Initiate Application Terminal Action Analysis
Read Application Data Card Action Analysis
Data Authentication Online Processing
Processing Restrictions Issuer to Card Script Processing 1
Cardholder Verification Completion
Issuer to Card Script Processing 2

EMV Transaction : Application Selection
PSE
Supported ?
Build the
candidate list List of AID PSE Method
Method
Perform the final

selection Manual selection Automatic
selection

EMV Transaction : Build the candidate list
Objective : Find the list of applications managed by both the

card and the terminal
 Applications in the terminal are AID (Application Identifier)
AID : 5 to 16 digits
RID (5 digits) Identify the PIX : 0 to 11 digits.
Payment Scheme. Identify the application into the
A0 00 00 00 03 : VISA Payment SCHEMES
A0 00 00 00 04 : MCI
 Applications in the card are stored into ADF.
 An application is supported if one condition is True :

 The AID matches the ADF name
 ADF names longer than AID, the first bytes match, and ASI is
set, enabling ADF name to be longer

EMV Transaction : Build the candidate list
AID managed by the terminal Applications in the card

ASI AID
ADF
1 A0000001 A0000001
0 A0000002 A00000021
1 A0000003 A00000031
1 A0000004 A00000032
Candidate list
AID
A0000001
A00000031
A00000032

Build candidate list : List of AID Method
 For each AID managed by the terminal, the terminal sends a

SELECT command
 The card may respond :
6A81 : Card blocked :
=> Application Selection fails
6A82 : File not found
6283 : Application blocked
=> In these two cases, the terminal does not add the AID in
the candidate list, and try the next AID.
9000 : Response successful
=> The terminal checks the validity of the response, adds the
AID in the candidate list if valid, and continues the algorithm.

Build candidate list : List of AID Method
SELECT AID (A0000001)

(9000, A0000001)
Recognised, same AID length
=> Add to Candidate list
(9000, A00000021)
Recognised, ADF length > AID length
ASI not set => skip AID,
Select Next AID SELECT AID (A0000003)
(9000, A00000031)
Recognised, ADF length > AID
length
ASI set => Add to Candidate list, SELECT AID (A0000003, NEXT)
select same AID (9000, A00000032)
SELECT AID (A0000003, NEXT)

(6A82
No more ADF beginning with A0000003
Select Next AID
File not found, end of list of supported (6A82)
AID => candidate list completed

Build candidate list : PSE Method
The terminal reads files containing the list of supported ADF

in the card, and compares the list to AID it supports
1. Select the PSE file
2. Read a record of the associated DIR file
3. Parse the record, extract one element
4. If the element is an ADF, test if present in the list of supported
AID
5. If the element is a DDF, Save the context, and go to Step 2.
6. If other elements in the record, go to Step 3
7. If other records present, go to Step 2
8. If a context has been saved resume the context, and go to
Step 6

Build candidate list : PSE Method : ONE Level, One Record
DDF DIR FILE

REC1 :A0000001, A00000021, A00000031, A00000032
“1PAY.SYS.DDF01”,
A0000001 A00000021 A00000031 A00000032
SELECT AID (1PAY.SYS.DDF01)

(9000, SFI1)
PSE Managed by the card, Read all
records in file SFI1
READ RECORD (SFI1, 01)
(9000, RECORD CONTENT)
PARSE RECORD, for each ADF read,
Search if present in the list of AID managed
If present, add to the candidate list. READ RECORD (SFI1, 02)
(6A82)
Record 2 does not exist
=> Candidate list completed

Build candidate list : PSE Method : One Level, 2 records
DDF DIR FILE

REC1 :A0000001, A00000021,
“1PAY.SYS.DDF01”, REC 2: A00000031, A00000032
A0000001 A00000021 A00000031 A00000032

(9000, SFI1)
records in file SFI1
(9000, REC1 CONTENT)
PARSE RECORD, for each ADF read,
Search if present in the list of AID managed
If present, add to the candidate list. READ RECORD (SFI1, 02)
(9000, REC2 CONTENT)

Record 3 does not exist (6A82)

Build candidate list : PSE Method : Two Levels
DDF DIR FILE

REC1 :A0000001, A00000021, DDF1
“1PAY.SYS.DDF01”,
A0000001 A00000021 DDF1

DIR FILE
REC1 :A00000031, A00000032
A00000031 A00000032

Build candidate list : PSE Method : Two Levels

records in file SFI1 (9000, SFI1)
PARSE RECORD, Add A0000001 READ RECORD (SFI1, 01)

to the candidate list. Save Context (9000, REC1 CONTENT)
and explore DDF1
SELECT AID (DDF1)
(9000, SFI2)
PARSE RECORD, Add A00000031 and
A00000032 READ RECORD (SFI2, 01)
to the candidate list. (9000, REC1 CONTENT)
Record 2 does not exist READ RECORD (SFI2, 02)

=> Resume previous context (6A82)
Record 2 does not exist READ RECORD (SFI1, 02)

(6A82)
! Standard algorithm. Alternative algorithms are

accepted, as long as they yield the same result

Build candidate list : Data returned with AID
DATA Presence List of AID Method PSE Method
Language O Returned for each AID, in Returned once in the SELECT PSE
Preference the Select Command Command response.
response
Issuer Code Table O Idem Idem
Index
Application Label M Idem Part of Data linked with each AID,
read with the read record
command
Application O Idem Idem
Priority Indicator
PDOL O Idem Idem
Application O Idem Idem

Preferred Name
Proprietary Data O Idem Returned once in the SELECT PSE
Command response.
Some proprietary Data may be
added for each AID.

Build the candidate list : Method comparisons
List of AID Method PSE Method
Mandatory in EMV Optional in EMV (may be locally

mandatory)
Always managed Not managed by all the cards
In some cases, some ADF are not seen

with PSE method
One command sent for each AID At least 3 commands sent (1 PSE and 2
managed by the terminal. READ RECORD)
Number of commands sent independent
of number of AID managed by terminal

EMV Transaction : Final selection
2 methods
allowed
Manual selection Automatic selection

•Only if one AID in candidate list and •Suppress all AID requesting a
confirmation not mandatory (b8 = 0 in confirmation (b8 = 1 in API)
API), select automatically this AID • If the list is not void select AID with the
•In all other cases, list of AID shown to highest priority
cardholder
•Display Preferred Name if exists, and • Some applications are never selectable
code table index if managed, or use • Simple solution for cardholder
Application Label • May be a good solution on unattended
terminals
•All applications are « selectable »
•May be complex for cardholder
Once the Application is chosen, the terminal sends

a SELECT command, with the AID selected

Processing Restrictions Issuer to Card Script Processing

EMV Transaction : Initiate Application
Objective : Inform the card of the beginning of a transaction.
The terminal builds a list of data requested by card in the PDOL

! This list can include transaction amount. For a merchant controlled terminal, amount
must be available at this point of the transaction.
The terminal sends this list of data through
GET PROCESSING OPTION command
CARD responds with 2 Data :
AIP : Application Interchange Profile
Specify card supported functions
AFL : Application File Locator

! At this point the terminal will return to
the final application selection step if the
List of files and records to be read for this card responds 6985 (Conditions of use not
transaction satisfied) to the GET PROCESSING
OPTION Command.


EMV Transaction : Read Application Data
 Objective : The terminal reads all data related with application.
 Terminal uses AFL returned in previous step.
 The AFL contains a list of files to be read. 4 bytes for each file
1. SFI : Short File Identifier
2. First record to be read
3. Last record to be read
4. Number of records involved in Static Data Authentication.
Terminal reads records, extract and store data in its database.


EMV Transaction : Offline Data Authentication
Objective : To ensure card is genuine

Principle : terminal verifies a certificate given by the card,
associated with a set of data.
Three methods are available , from the lowest to the highest

security :
SDA
DDA
CDA
The terminal uses supported method by both card and terminal
with highest security level available.

EMV Transaction : Offline Data Authentication
Low Security
SDA : Static data Data used are not transaction Low cost : cards have not RSA
dependent. Certificate is written once algorithm wired
authentication at card personalisation. Low security : not protection against
card cloning
Fast transaction : No RSA calculation
by card, 2 RSA calculation by terminal
DDA : Dynamic Data used are transaction Higher cost : cards have RSA
dependent, and include a random algorithm wired
data authentication number given by terminal. For each High security : card used at that step
transaction, card generate a new of transaction is genuine.
certificate. Slow transaction : One RSA calculated
by card, 3 by terminal
CDA : Combined Same as DDA, but data Highest security : card used at the end
authentication is made at the end of of the transaction is genuine.
DDA / Generate AC the transaction, with
GENERATE_AC command
High Security

EMV Transaction : Static Data Authentication
Data used for SDA are those indicated in the AFL.

AFL
An optional tag (SDA TAG LIST)LIST may add other data to be
included. !In EMV 2000, SDA Tag List, if present, may only
contain the AIP.
A certificate is associated with this list of data.

data Certificate is
calculated on a SHA of this data list, using RSA algorithm, with
Issuer Private Key.
Terminal verifies certificate using the Issuer Public Key. Issuer
Public Key is read from the card.

Dynamic Data Authentication
The data used for DDA are those indicated in the AFL, plus a list
of Data, given by the terminal to the card.
card The list of Data is defined
in the DDOL, and shall contain at least an unpredictable number.
The terminal sends the data listed in the DDOL to the card, using
a command INTERNAL AUTHENTICATE
The card calculates a certificate on these data, using a card

private key. It returns this certificate in response of the INTERNAL
AUTHENTICATE command. The card public key has been given to
the terminal at the previous step.
The terminal verifies the Data Authentication Certificate.

Offline Data Authentication : Key and certificate hierarchy
A set of Certification Authority Public Keys is loaded inside

terminal under acquirer responsibility.
Each issuer products its own RSA, public and private keys. It
requests Certification Authority for a certificate on its public keys.
Issuer Public Key and its associated certificate is written in the
card, and read by terminal during read application data step.
For each ICC with DDA capability, issuer processes one RSA
public/private key pair. It also produces a certificate on card public
key, calculated with its own Issuer Private Key. Card key pair and
certificate are written in the card. Terminal read card public key and
its certificate. Card private key is kept secret.

Offline Data Authentication : Key and certificate hierarchy
Certification Authority Public Key

Used to verify issuer
Public Key Certificates
Issuer Public Key
Used to verify Card

Public Key Certificates
Card Public Key
whole security in terminal

depends on the manner
Certification Authority Public
Keys are entered !!!


EMV Transaction : Processing restrictions
Objective : Determine degree of compatibility between terminal and

card application. Three controls are performed during this step
Application version number : Verify that

terminal and card applications have same
Version Number. AUC conditions list
Valid for domestic cash transactions
Application Usage Control. A 2 bytes bit map, Valid for international cash transactions
each bit corresponding to a condition. Terminal Valid for domestic goods
checks if conditions are satisfied Valid for international goods
Valid for domestic services
Valid for international services
Application Effective/Expiration Date Valid at ATMs
checking. Terminal verifies that current date is Valid at terminals other than ATMs
Domestic cash back allowed
between Application Effective Date and International cash back allowed
Application Expiration Date.


EMV Transaction : Cardholder Verification
Objective : Ensure that the person holding ICC is genuine card

owner :
Principle : Card gives a CVM List to terminal, containing :
amount X
amount Y
A list of rules : Each rule contains two bytes, corresponding to :
 A Cardholder Verification Method
 A condition to apply this method
Terminal processes each rule of the list until it finds one with
condition satisfied. Methodis then applied.
If method is successful, step is ended with success.
If method fails, depending on one bit in the method, either :
Terminal tries the following rule
Or step ends with an error.

Cardholder Verification : Methods
Fail CVM : Method always failing

Plaintext PIN Verification Performed by ICC :
Terminal retrieves pin try counter through GET DATA command.
Cardholder enters its PIN Code.
Terminal sends it plaintext to ICC in VERIFY PIN command.
ICC verifies the pin code.
Enciphered PIN Verification Performed by ICC :
Terminal retrieves pin try command through GET DATA command.
Terminal sends a GET CHALLENGE to the card to obtain an unpredictable number.
Terminal enciphers PIN Code, unpredictable and padding values with Card Public Key, being
the same as DDA, or a specific one
Tterminal sends enciphered PIN in VERIFY PIN command.
ICC deciphers and verifies the PIN.
Enciphered PIN Verified online:

Terminal retrieves pin try command through GET DATA command.
Terminal enciphers PIN with an issuer proprietary method
Terminal sends enciphered PIN to acquirer host.
Issuer host verifies PIN value and gives its agreement.

Cardholder Verification : Methods
 Plaintext PIN Verification Performed by ICC and signature:

Terminal performs a Plaintext Pin Verification
At the end of the transaction, it asks for a signature on ticket receipt.
 Enciphered PIN Verification Performed by ICC and signature:

Terminal performs an enciphered PIN verification
At the end of the transaction, it asks for a signature on ticket receipt.
 Signature
At the end of the transaction, it only asks for a signature on ticket receipt.
 NO CVM : A method always succeeding if supported by

terminal.

Cardholder Verification : Applicable Rules
 Always : Always perform the method

 If Cash or Cash back : Apply the method if the transaction is a
cash or cash back transaction
If not Cash or Cash back : Apply the method if the transaction is not
a cash or cash back one
 If transaction amount is in the application currency and is under X
 If transaction amount is in the application currency and is over X
 If transaction amount is in the application currency and is under Y
 If transaction amount is in the application currency and is over Y


EMV Transaction : Terminal Risk Management
Objective : Determine whether transaction is to go online.

3 applicable methods :
 Floor Limit Checking : Transaction above a Floor Limit will go

online.
 Random Transaction Selection : Transaction under Floor Limit will
go online with a probability increasing with amount value.
 Velocity Checking : Transaction will go online after N consecutive

off-line transactions.

Terminal Risk Management : Floor Limit Checking
 Terminal retrieves in its log file, last transaction with same PAN.
 If found, it is then added to current transaction amount
 It compares this cumulative amount with terminal Floor Limit
 If result greater than threshold, transaction is to go online.

Terminal Risk Management : Random Transaction Selection
 4 transaction dependent parameters are used:

Target Percentage
Threshold Value for Biased Random Selection
Maximum Target Percentage
Floor Limit
Maximum
Probability to Target
go online Percentage
Target
Percentage
0
Biased Selection Floor Limit
Threshold
-- Transaction Amount ->

Terminal Risk Management : Velocity Checking
 The terminal reads two parameters in the card, using GET_DATA

command :
 Application Transaction Counter
 Last Online ATC Register
 If one of this data doesn’t exist, velocity checking fails

 If both data exist, terminal compares difference between the two registers
against lower consecutive offline limit.
 If limit is exceeded, then velocity checking fails.
 If Last Online ATC Register has a zero value, ICC is detected as new
card.


EMV Transaction : Terminal Action Analysis
Objective : Terminal decides on transaction result :

Accept transaction off-line
Go on-line for a host authorisation
Reject transaction off-line.
 Principle : Terminal compares the result of all the previous steps

(stored in TVR) with a set of decision tables
 Each decision table has same format as TVR : 5 bytes bit field.
 Terminal should have its own decision tables, reflecting the

Acquirer decision rules calledTerminal Action Codes (TAC).
 Card should have its own decision tables, reflecting Issuer

decision rules called Issuer Action Codes (IAC).

Terminal Action Analysis
 Both Terminal Action Code and Issuer Action Code consists in a

set of 3 Decision Tables :
 Denial : Decision Table used to check if the transaction is to be
rejected offline or not.
 Online : Decision Table used to check if the transaction is to go
online.
 Default : Decision Table used if transaction is to be rejected
offline after trying but unable to go online
 Decision tables are always processed in this order :

Denial, Online, and Default if needed.
 Decision tables are processed by pair : Terminal Action Code –

Denial with Issuer Action Code – Denial …

TVR 0 0 1 0 0 1 1 …
TAC 0 0 0 1 0 1 0 …
IAC 0 0 0 0 1 0 1 …
Result 0 0 0 0 0 1 1 …
 if any bit is set in result

=> Relevant decision is taken

Process Action Code - Denial
YES Denial Condition NO

fulfil ?
Process Action Code - Online
Reject YES NO
Online Condition
Transaction fulfil ?
YES
Able to go NO
online ?
Process Action Code - Default
YES Default Condition NO

Perform the fulfil ?
transaction Reject Accept Transaction
online Transaction Off-line


EMV Transaction : Card Action Analysis
Objective : Make ICC know terminal decision, and ask for card final
decision.
 Terminal sends a first GENERATE AC command to the card, and

specify cryptogram type required.
 Card takes its decision and responds with a cryptogram that can
be different (more severe decision) from terminal one.
 Cryptogram is calculated by ICC with a secret key, and will be

used by issuer to authenticate transaction a host clearing process.
 If authentication method is a CDA, cards adds dynamic certificate

in its response.

Card Action Analysis : Generate AC parameters and data
Parameter for first Generate AC command
Accept Transaction Perform transaction Reject

Off-line online Transaction
Ask for TC (Transaction Ask for ARQC Ask for AAC (Application
Certificate) (Authorisation Request Authentication Cryptogram)
Cryptogram)
 In first Generate AC, terminal sends data objects required by ICC

in CDOL1.
 CDOL may require a TC Hash Value :
 Terminal fills a buffer with Data Objects requested in TDOL.
 Then calculates a hash value on this buffer.

Card Action Analysis : Card response
Terminal decision
TC ARQC AAC
Card decision
TC Transaction approved off-line

ARQC ARQC A host authorisation is required
AAR AAR A referral is required (*)
AAC AAC AAC The transaction is declined
 (*) under bulletin decision, referrals initiated by card are no more accepted

Card Action Analysis : Card response
 If ICC responds with TC or ARQC and if authentication method is

CDA, then card includes a certificate in its response.
Card may also send to terminal an advice message for issuer host,
to be send in on-line authorisation or during clearing.
Only “PIN TRY Limit exceeded” currently identified as a

possible advice message


EMV Transaction : Online Processing
Objective : If card response is ARQC to GENERATE AC command, an

authorisation message is to sent to host.
 Terminal sends this message to acquirer host forwarded to issuer
host.
Protocol used and data sent are out of EMV scope …
Issuer response is given into Authorisation Response Code Data

Object. 3 main responses are possible :
 Approved
 Declined
 Referral : Issuer asks merchant to call the bank for voice authorisation
 If Issuer response includes Issuer Authentication Data (IAD) and if
card supports External Authenticate then terminal sends an
EXTERNAL AUTHENTICATE command to the card.


EMV Transaction : Issuer to Card Script Processing
Objective : In its response message, issuer may send a list of

commands to be submitted to ICC allowing issuer to dynamically update
the card behaviour.
 Host may sends one ore several scripts. Each one containing one
or several commands to be delivered to ICC.
 Two types or scripts are defined. First ones (71) to be delivered
before second GENERATE AC. Second ones (72) to be delivered
after second GENERATE AC, just after completion.
 Terminal delivers each command to the card, one after each
other, and checks card response code.
 In case of error returned in response code, terminal doesn’t deliver
following command to the card, but attempts to deliver the following
script.

Issuer to Card Script Processing : Script Format
 A script is a constructed Data Object.
Optional field Command List
Script Command Command

71/72 L 9F18 04 86 L1 86 L2 …
Identifier 1 2
 Terminal fills an Issuer Script Result, containing for each script :

 Script identifier if present.
 A byte indicating script result and in case of error, sequence number

of failing command.


EMV Transaction : Completion
Objective : Close transaction process.
 If transaction has been performed online, terminal sends a second

GENERATE AC command, requesting either TC or AAC.
 In second Generate AC,terminal sends data objects required by

ICC in CDOL2.
 In case of CDA authentication method, card includes dynamic

certificate in response to second GENERATE AC.
ICC responds with either TC or AAC.

Processing Restrictions Issuer to Card Script Processing 1

EMV - Summary
EMV in a few words

EMV Data Management
Security impact
EMV implementation
Glossary

Security Impact
Any actor can be requested to be authenticated :
Host Terminal ICC Cardholder
Offline Data Authentication

Online Data Authentication
Cardholder Verification Method
External Authentication
Transaction Cryptogram
In EMV, terminal is never authenticated by any

other actor !!!

Security Impact : Key Management
 Certification Authority Public Keys are distributed to Issuers and

Acquirers, by Certification Authority.
 Certification Authority Public Keys are then distributed to merchant
terminals on behalf acquirer responsibility.
 Terminal must ensure Key integrity and origin authenticity.
 Terminal must be able to manage at least 6 Public Key by RID

(Certification Authority).

Security Impact : Parameters and Software Management
 before any software loading, terminal must ensure software

integrity and origin authenticity :
In Telium environment :
AID
Easy Path Secure downloading solution : parameter
to EMV
file
application
CAKeys
SST
T-DES signature
SST/SAT signed file signed file … or… with KMac
(RSA signature)
.par file
Terminal KMac
SKMT … or…
SSL

EMV - Summary
EMV in a few words

EMV Data Management
Security impact
EMV implementation
Glossary

EMV Implementation : Fall Back
 A fall back is the way to continue a swipe transaction when ICC

transaction fails.
 EMV Requirements state that a terminal shall contain a magnetic

stripe reader that can be combined with ICC reader or separated.
 When a card is swiped in the magnetic stripe reader, terminal shall

check if it is an ICC card through ISO2 service code from stripe.
 If IC card is detected in stripe, terminal force to use it. Stripe is

accepted only after ICC use fails.
 Fall back conditions are not fully defined in EMV, and are specific
to each acquirer.

EMV Implementation : Refund
 A refund transaction is not described in EMV, but is expected by

acquirer
 Both MCI and Visa describe refund transactions with the same
principle :
 A refund transaction may be seen as a

truncated EMV transaction, stopping after card
reading step after getting PAN.
 Visa also accepts a refund transaction as a
complete EMV transaction, always accepted
whatever is card decision.

EMV Implementation : Unattended Terminals
 An unattended terminal can be offline only, online only, or offline

with online capabilities.
 Operation may be controlled under responsibility of :
 A financial institution : ATM…
 A merchant : Vending Machines…
 The Cardholder itself : Personal Computer…
 Terminal is not required to support voice referrals.
 Terminal is not required to have a cardholder display.

Master Card Requirements for Unattended Terminals
 MasterCard defines 3 categories of unattended terminals
1 Automated Dispensing Machines PIN-based transaction

Online authorised
No Maximum transaction values
2 Self Service terminals No CVM required
All transactions authorised online
Maximum transaction amount 50 $
3 Off-line only, limited amount No CVM required
terminals
Host List checking (optional)
 Fallback are not allowed on unattended terminals.

Visa Requirements for Unattended Terminals
 Visa also defines three categories of unattended terminals :
ADM : Automated Dispensing PIN online mandatory

Machines PIN offline as an option
Non Signature
Visa Electron allowed
Online authorised
No Maximum transaction values
SST : Self Service Terminal No CVM required, PIN (online, offline optional)
All transactions authorised online
Online capable.
Visa Electron allowed
LAT : Limited Amount Terminal No CVM required. Offline PIN optional
Off-line only terminal.
No Signature, No Pin online.
Visa Electron not allowed
 A terminal can comply with one or more category, depending on transaction.
EMV - Summary
EMV in a few words

EMV Data Management
Security impact
EMV implementation
Glossary

Glossary
•AAC Application Authentication Cryptogram : Cryptogram indicating a rejected transaction

•AAR Application Authorisation Referral : Cryptogram asking for a referral
•AC Application Cryptogram : Cryptogram calculated by the card at the end of a
transaction/
•ADF Application Definition File : Directory in the card, associated with an application
•AEF Application Elementary File : Elementary file in the card, containing data for an
application
•AFL Application File Locator : List of files, with relevant records, to be read
•AID Application Identifier :  Name of the ADF in the card containing the
application
•APDU Application Protocol Data Unit : Elementary exchange between the terminal and the
card, C_APDU for a command sent by the terminal, R_APDU for the card response.
•ARC Authorisation Response Code : Response Code given by the host acquirer.
•ARPC Authorisation Response Cryptogram : Cryptogram generated by the Issuer and verified by
the card, permitting Issuer host authentication.
•ARQC Authorisation Request Cryptogram : Cryptogram asking for a host authorisation
•ATC Application Transaction Counter : Number of transactions done with the application,
into the card.
•ATM Automatic Teller Machine : Cash distributor

Glossary
•CDOL Card Risk Management Data Object List

•CVM Cardholder Verification Methods : List of methods used to verify if the cardholder
is the auhorised user of the card.
•DDA Dynamic Data Authentication : Method for the offline card authentication,
requesting the card to dynamically certify a set of data, different for each transaction.
•DDF Directory Definition File : Directory File, referencing either other DDF,
or Application Directory Files.
•DDOL Dynamic Data Authentication Data Object List
•DES Data Encryption Standard : Symmetric cryptographic algorithm.
•IAC Issuer Action Code (Denial, Default, Online) : Decision tables reflecting the issuer
rules for the terminal decision, at the end of the transaction;
•ICC : Integrated Circuit(s) Card : A card into which one or more integrated
circuits are inserted to perform processing and memory functions
•PAN Primary Account Number : Card Number
•PDOL Processing Options Data Object List
•PIN Personal Identification Number : a 4 to 12 digits value, entered by the
cardholder, and used to verify he is the authorised user of the card.

Glossary
•POS Point of Service : Synonym for a payment terminal, used by a

merchant.
•PSA Payment System Application
•PSE Payment System Environment : Algorithm used to build the candidate list
during application selection.
•RID Registered Application Provider Identifier : A five bytes identifier, identifying a
Payment Scheme. Radix of the AIDs.
•RSA Rivest, Shamir, Adleman Algorithm : Public key enciphering algorithm, used in
EMV.
•SDA Static Data Authentication : Simplest method allowing the offline card
authentication.
•SFI Short File Identifier : File identifier on one digit. Permits a direct
access
•SHA Secure Hash Algorithm : Normalised algorithm producing a 20 bytes
hash value on messages, used in EMV.
•SW1 Status Word One
•SW2 Status Word Two

Glossary
•T=0 : Character oriented, asynchronous, half duplex transmission protocol

•T=1 : Block oriented, asynchronous, half duplex transmission protocol
•TAC Terminal Action Code(s) (Default, Denial, Online)
•TC Transaction Certificate : Cryptogram for an approved transaction
•TDOL Transaction Certificate Data Object List
•TLV Tag Length Value : Method used to express all data in EMV
•TVR Terminal Verification Results : A five bytes bit-map, containing the result of
all controls done by the terminal during the transaction.

E.M.V (Part2)
Easy Pass to EMV Certification :
“always delivered EMVCo certified”
100 •
EMV Application certification process
SAGEM Monétel
Level 1 Certified Terminal
International
EMVCO HW & OS
Certified kernel
Visa & MasterCard Level 2
Function
Support for
Visa Or MasterCard Application application/ICS
Integration testing
Acquirer
Local
Application Tools for

integration
End To End Testing
Partners

Easy Path to EMV : certification Process
SAGEM
Monétel EMV Level 1
Certified Terminal certified Interface Module (IFM)

– Telium IFMs are certified Level 1
– TQM Process
Certified kernel See www.emvco.com
Support for application
Tools for integration
Partners

SAGEM
Monétel
EMV Level 2 kernel Certification : International
Certified Terminal – A certification is valid for a given ICS
(Implementation Conformance Statement)
– Contents of standard ICS :
• Terminal Characteristics
Certified kernel • EMV Level 1 Type Approval
• EMV kernel Characteristics
» Terminal Capabilities (Cash, Services, Goods …)
» Application selection
» Terminal Resident Objects
# 80 Items
Support for application » …
» Terminal Details
Partners

SAGEM
EMV Level 2 kernel Certification International
Monétel
– In-house qualification is perform using same tools as official

Certified Terminal laboratory.
– ICS and terminal are sent to a laboratory
– Test results are directly sent by laboratory to EMVCo for Type
Approval
Certified kernel – A level 2 certification keeps valid if terminal change (As Tested In …)
We can provide you a letter and specifications to explain why an

application can be used without any modifications (with the same CRC)
Support for application on each TELIUM Product. This letter can be cost effective.
Partners

SAGEM
Monétel
EMV Application Development
Certified Terminal
– Get acquirer specifications : Partners
• Man machine interface
• Communication to host
Certified kernel • Terminal management
– Personalization of EMV Custom : Partners
Usually ICS has to be modified to meet the local need

Support for
– Specific ICS definition : Partners / SAGEM Monétel
application
– Certification for a specific ICS : SAGEM Monétel
Partners

SAGEM
Monétel
Last local EMV Application certification
Certified Terminal
– Tests are conducted by acquirer with Card Schemes
qualified tools
• ETEC for MasterCard
Certified kernel
• ADVTK for VISA
– Tests performed by VARs and / or acquirer
– Acquirer drives End to End qualifications and pilot
Support for application – This process is TIP (Terminal Integration Process) for
MasterCard
– Acquirer network is certified for an end to end
transaction (TQM Required by MasterCard)
Tools for – Terminal can be send on the field
integration
Partners

EMV Application certification with Easy Path to EMV
SAGEM Monétel
Level 1 Certified Terminal

International
HW & OS Telium product

EMVCO
Certified kernel
Visa & MasterCard Level 2
Standard ICS
Function
Support for
application/ICS
Application
Visa or MasterCard Integration testing ICS Definition
Local
Acquirer Tools for

Application integration
End To End Testing ETEC, ADVTK
Partners

E.M.V Generic (Part 3) Easy path to
EMV
Training Course
108 •
EMV Generic Package – Training Summary
EMV Generic Package presentation

Phases for EMV Generic customisation
EMV Custom interfaces
EMV functions implementation
EMV Custom Design Overview
Glossary

EMV Generic Package – Training Prerequisites
Knowledge of EMV requirements

Knowledge of SDK for Telium
platform

Main principles
Application architecture
Application status

EMV Generic Package : Main EMV characteristics
International specification for Debit/Credit applications using smart

cards
– Open specification. Many treatments are optional.
• Depending on local rules, the transaction may be very different, with different
security levels.
– The whole transaction and related treatments are not described in the
specification. For example are not present :
• Interface with the host acquirer
• Management of transaction logging, parameter files …
Open specification
– Includes multi-application concept.
– Usable by other issuers.

EMV Generic : main goals
Build a common EMV Kernel, versatile and usable in most countries,

implementing most of EMV requirements.
Provide a complete application, with source code (for modules to
customise), usable as a reference for current application
development.
Give Facilities for application customisation :
– Adaptable user interface
– At each step of the transaction a hook to custom application is called to give the
designer an opportunity to add a specific treatment.
– File parameters, for parametrisation of managed AID.
Enable integration with existing multi-application environment

– EMV application selection is processed by M2OS manager.
– Facilities for fallback to magstripe application.

EMV application overview: 4 components
APPLICATION
EMV CUSTOM takes in
EMV application : EMV EMV account all non standard
ENGINE (.exe files only) ENGINE EMV treatments.
(source code)
EMV
CUSTOM
GENERIC CUSTOMISATION
EMV DC
EMV Kernel :
EMV COMM takes into
EMV DC (Data/Command)
account communication
manages dialog with the card EMV
with the acquirer host.
(.exe files only) COMM
(source code)
KERNEL

Inter-application exchanges via M2OS
EMV DC
EMV CUSTOM EMV ENGINE EMV COMM
(EMV Kernel)
M2OS (Applications Manager)
 Application are protected against unexpected memory access MMU of

Telium platform.
=> Only encapsulated access to EMV DC is permitted
 Communication between components is done via IAC mechanism

Crypto-Processor Usage
Main Processor Crypto Processor
EMV CUSTOM NO ACCESS TO PIN PIN entry

CODE FROM MAIN
PIN enciphering for
PROCESSOR
online verification
EMV DC PIN enciphering for
offline verification and
presentation to the
ICC
PIN management in Telium Platform

EMV Data&Commands overview
EMV DC is EMV kernel

Manages all EMV Card access
Manages all treatments needed for EMV
Transaction
Provide services to engine for each transaction
step
Keeps a mirror image of EMV Card and
transaction data

EMV ENGINE overview
Manages application step sequence (EMV

transaction flow)
Calls “CUSTOM” for every non EMV treatments
Initiate Authorisation request requests if needed
but alows forward it now to custom to allow full
protocol compatibility (*) .
(*) Older method where engine calls directly

comm still exist for older package compatibilty
by setting a specific tag.

EMV COMM overview
Gives an access to Acquirer Host

Provide services for on-line treatments during
a transaction
Provide services for on-line batch treatments
Specific for each protocol

EMV COMM overview
“Custom” is compliant with SAGEM protocol

packages such as ISO8583, SPDH or
APACS40.
If a specific protocol is to be implemented, it is
hardly advise that API comply with “Generic
Interface for Financial Communication
Components”doc from SDK to allow this
protocol to be used again with any other
generic application.

EMV CUSTOM overview (1/3)
Specific for each country and/or each acquirer,

depending on local requirements.
This module is designed to be customized by
developer to comply with local requirements.
A generic “CUSTOM” module is provided as
reference application (used for certification). This
module can be used as a development frame by
local designers.
Get AID parameters in a parameter file
Ability to add specific controls during the
transaction process.
EMV CUSTOM Overview (2/3)
Human interface
– Manages Amount Entry process
– Manages all displayed messages, tickets and inputs
– Application Selection customization possible.
Parameters
– Currency, Terminal Country Code
– AID list, and AID parameters
– Certification Authority Keys
– Terminal Capabilities, Extended Terminal Capabilities,
Transaction Type, Transaction Category Code
– List of revoked certificates …

EMV CUSTOM Overview (3/3)
Transaction treatments
– Amount Entry
– Exception File Control
– Exception handling of card errors
– Online and Offline PIN Entry and Management
– Messages or tickets for referral, and forced acceptance
– Transaction logging
Other treatments
– Batch data capture
– Maintenance menu and associated treatments
– Outside EMV kernel Authentication capability
– Fallback to magnetic stripe procedure management

function distribution
TRANSACTION SEQUENCE
EMVDC Engine Custom Comm M2OS
Card access X
EMV transaction X
treatments
Non EMV transaction X
treatments
Transaction X
sequence
(transaction flow)
Application Selection X X X

HUMAN INTERFACE
EMVDC Engine Custom Comm M2OS
Amount Entry X
Tickets X
Maintenance Menu X
Messages X X
PIN Code entry X
Navigation, X(*)
application selection
(*) Final selection of applications

may be customised

ONLINE TREATMENTS
EMVDC Engine Custom Comm
PIN on-line (*) X X
Online authentication X X
Financial transaction X X
messages
Batch data capture X X
(*) historical mode. No more used

EMV Generic application : Current status
APPLICATION SELECTION
Function Status
PSE selection Method Managed – (can be disabled)
Cardholder Managed – ASI associated with each AID
Confirmation
Final selection by Managed – Default management by M2OS.
cardholder Selection can be managed by CUSTOM
Automatic Selection of Alternative algorithm optional.
the application with the
highest priority
Selection customisation Customisation can be performed outside
M2OS selection for specific purposes

EMV Generic application ! Current status
CARD AUTHENTICATION METHODS
Function Status
SDA Key length 1984 bits
DDA Key length 1984 bits
CDA Enhanced version – Key length 1984 bits

EMV level 2 application : Current status
CARDHOLDER VERIFICATION METHOD

Function Status
Plaintext PIN for ICC verification Managed – Crypto Processor used
Enciphered PIN for ICC Verification Managed – Crypto Processor used
Enciphered PIN for online Managed – Crypto Processor used

Verification – DES used as default algorithm
Signature processing Managed
Bypass PIN entry Managed

NO CVM Managed
Fail CVM Managed

EMV level 2 application : Current status
Compatible all Telium platforms :
Smart2 ICT2xx ML30 EFT930xxx
UCM-CAD30 CAD30 UCR SPM (IPA280) PP30S pinpad PP30 pinpad

EMV Generic Package Training Summary

Glossary

Phases for EMV Generic : customisation
Specific Requirements
Published by the local Local
Authority (bank …) requirements file Local EMV
application
1 Local Requirements
analysis 2 Implementation
Design
ICS
3 Certification
Process
Authorisation for Local EMV

exploitation

Phases for customisation : 1 - Local Requirements analysis
Analyse local requirements, local usages,

infrastructure…
– EMV options implemented (PIN online, PIN bypass…)
– Extra requirements or constraints
– Parameter management, Key management…
– Protocol used for Acquirer Host interface
– Means of communication

Phases for customisation : 2 – Implementation Design
General design depends on EMV application

environment and terminal constraints :
EMV application environment :

– Existing application already developed for the terminal.
– Other applications to be developed.
Constraints :
– Limited number of application on the terminal (13)
– Memory constraints
– Application certification constraints :
modular design avoids multiple re-certifications in case of update.
– Terminals management constraints : module design enables to
reload only modified components.

Design Samples :
Independent applications.
EMV
COMM Some shared treatments
COMMON SERVICES
(Batch File, parameters
are located in DLL
…)
Located in DLL
EMV EMV D/C

CUSTOM
OTHER APPLI SWIPE EMV ENGINE

(e-purse, Debit/Credit
Healthcare …) Application
M2 OS TELIUM
OEMC TELIUM

Design Samples
Independent applications. No
common treatments, except
EMV
COMM communication services
EMV EMV D/C

CUSTOM
OTHER APPLI SWIPE EMV ENGINE

(e-purse, Debit/Credit
Application
Healthcare …)
M2 OS TELIUM
OEMC TELIUM

Design Samples
Independent applications. EMV

Custom also includes Swipe Debit/
EMV Credit application
COMM
EMV CUSTOM
Includes SWIPE EMV D/C
Debit Credit
application
OTHER APPLI
(e-purse,
EMV ENGINE
Healthcare …)
M2 OS TELIUM
OEMC TELIUM

Phases for customisation : 3 – Certification process
ICS compliance and acquirer final acceptance :
Phase 1 analysis may result in an ICS different from

the one used for reference EMVCO approval. In this
case, a re-certification is necessary : provided by
Sagem Monétel.
Acquirer makes integration testing, before putting
terminals on the field.


Glossary

EMV
M2OS
ENGINE
M2OS Entry Points
Services provided by
Application dependent EMV Custom to EMV
Treatments Engine
Non EMV EMV
Components CUSTOM
- Common functions
- Fallback
- Remote payment Communication
requests
Transaction Database
Consultation only EMV
EMV DC COMM

M2OS and Custom Interfaces
As any application, EMV Custom needs to implement Manager APIs :
M2OS EMV CUSTOM
 Standard M2OS compliance : after_reset(), consult, state(), is_change_init(),

Is_evol(), modif_Param(), give_your_domain(), file_received() …
 Related to Fallback management, or Swipe transactions management :
fall_back(), is_for_you_after(), debit_non_emv()
 including now in multi-custom mode :
 idle_message()
 is_name()
 time_function()
 give_AID()
 is_card_EMV_for_you()
 more_function()
 keyboard_event()
 debit_EMV()
DEL Mechanism
All interfaces of EMV Generic uses a single mechanism :

DEL mechanism : Data Element List (but soon replaced by TLV tree mechanism…)
All Data exchanged are expressed in BER-TLV format. Tags can be :

 Defined in EMV Requirements TVR, TSI …
 SMO Proprietary TAGs TAG_USE_PSE, TAG_BYPASS_PIN…
A DEL is a list of data expressed in TLV format (*) Due to the

MMU mechanism,
Each Service call has an entry DEL and an output DEL application cannot
Data are copied from one application to an other (*) share memory
Entry DEL
Calling Called
Component Output DEL Component

Internal DEL management : DEL by pointer …
Take care on the way DEL are managed inside an application.

2 internal DEL mechanisms exist. One must be chosen.
With the First mechanism, data are not copied but passed as pointers :
Tag1 Length1 Pointer on Tag2 Length Pointer on …

value1 2 value2
Effective Value 1 Effective Value 2
Value are copied only when the DEL is sent to an external application
=> Values must be still valid at that time.
Potential problems :
Value is on the stack (local variable), and the DEL is sent outside the function where
data where introduced.
 A variable, pointed as value, may be modified before DEL is sent.

Internal DEL management : DEL by Value
With the second mechanism, data are physically copied and passed by value :
Tag1 Length1 Value 1 Tag2 Length 2 Value 2 …
Benefits : The potential problems of the previous solution disappear.
Drawback : The DEL type is bigger :

=> A DEL variable can not be put in the stack.
DEL variable must be global data
=> Data size of the application increases.
A compilation option enables to chose between the 2 DEL mechanisms.
To figure out both problems, TLV Tree format is used now since EMV Pack13

Engine and Custom Interface
EMV Custom offers a set of services to EMV Engine using IAC mechanism.
Following services are available :
 Return Application parameters :

 I_EMVCUST_Get_Global_Param : Return general parameters, independent from AID
 I_EMVCUST_Get_AID_List : Return list of AID when transaction initiated from “F” menu
 I_EMVCUST_Get_AID_DATA : Return EMV parameters, depending from the AID
 I_EMVCUST_Get_AID_Param : return other parameters, depending from the AID
 Perform Transaction Treatments

 I_EMVCUST_Process_Step : Called after each EMV step, during transaction.
 I_EMVCUST_Display_Message : Called to display one specific message.
 I_EMVCUST_Get_Last_Transaction : Search last transaction performed with the same card
 I_EMVCUST_Voice_Referral : Manage MMI for voice referral function.
 I_EMVCUST_Authorisation : Manage authorisation request message.

Multi-Custom configuration
Capability to have several custom sharing same engine and emvdc kernel
Each custom can have one or more ICS to be loaded dynamically at the beginning of each transaction
when IAD is known. (require as much certifications as different ICS)
Principle :
• Each custom manages now all standard manager API and respond to application selection process.
• Only when AID is selected, relevant debit_EMV() is called and custom launch engine flow.
• Engine receive “Application type” from custom and start transaction with calls-back to custom
• If “application type” remains “0X51” then flow is same as before (pack <13) for compatibility
• If “application type” is different of “0X51” (and in the customer range) then flow is “multi-custom”
• both custom different of “0X51” and equal to “0X51” can run at the same time in the same terminal

Development rules and adaptations :
• set “application type” in Custom with a value different of “0X51” (In customer range)
• modify in cu_msgEnglish.h and cu_msgFrench.h (line 5 / Custom project) following line :
// #APPLITYPE 51 -> replace by your own “application type” above
•EMVCUST_Initialise() is now to called in after_reset() for custom initialisation
• is_card_emv_for_you() has to returns a priority=30
• more_function() initiates a transaction by calling Engine_DoTransaction()
• more_function() initiates a transaction log by calling Engine_DoReadTransactionLog()
• Engine_DoTransaction () is to be called in keyboard_event() if a transaction is to be initiated by a key
• debit_EMV() now calls Engine_DoTransaction() to start manager selected transaction
Note that : I_EMVCUST_Periodic_Call, I_EMVCUST_Get_AID, I_EMVCUST_More_Function and

I_EMVCUST_KeyManagement are no more existing in multi-custom mode.

Engine_DoTransaction() entry parameters :
TAG_ENG_CUSTOM_APPLI_TYPE Custom Application type (2 bytes)
TAG_ENG_APPLI_SEL_ALREADY_DONE = 1 for Debit_EMV / = 0 else
TAG_AID_ICC TAG_GIVE_AID_AID_VALUE (from manager)
TAG_APPLICATION_LABEL TAG_GIVE_AID_APP_NAME (from manager)
TAG_APPLI_PRIOR_IND TAG_GIVE_AID_APP_PRIO (from manager)
TAG_LANGUAGE_PREFERENCE TAG_GIVE_AID_PREF_LANGUAGE (from manager)
And only if (ParamIn->entry != NO_ENTRY ) then fill followng fields :
TAG_TRANSACTION_CURRENCY_CODE ParamIn->currency.code (from manager)
TAG_TRANSACTION_CURRENCY_EXP ParamIn-> currency.posdec (from manager)
TAG_AMOUNT_AUTH_BIN ParamIn->amount (from manager)
TAG_AMOUNT_OTHER_BIN =0 or requested value by merchant (from manager)

New names for parameters files :
In order to have a different parameters files for each Custom, it is necessary to rename
parameters files as following :
• “file”.par must be renamed into “file_ application_type”.par
Example with Custom Application type = 0x151 :

•AID1_0151.par
•CAKEYS_0151.par
•BLACKL_0151.par
•ICS_0151.par
•krevok_0151.par
•EMVCUST151.par
Allowing each custom to receive only its own files.
Parameters files are now passed as one as a TLV tree :
TLVTree library allows to find out any element in this tree structure
(extract from C:\Program Files\SDK30\Easy Path to EMV 16\Documents\Parameters management.pdf)

EMV DC and Custom Interface
The only services available from Custom to EMVDC are the data
base consultation service to retrieve data or commands.
EMVDC_get_data_elements()
Input parameter : DEL containing a list of elements to be

consulted. Length should be 0, value is not filled.
 Output parameter : DEL containing the list of elements, with
length and value set.
EMVDC_get_commands()
Use to retrieve list of command sent to the card (used later for
fallback processing)

Custom and COMM Interface
EMV Custom fully manage communication with the acquirer host.

(For historical reasons and compatibility, it is also possible that
Engine manage authorisation request by setting a specific tag).
As both EMV Custom and EMV Comm are local application,

interface between the 2 components is free.
It is however suggested is protocol is specific that interface

complies with the “Generic interface for communication
components” API description (under TDS/doc)


Glossary

Application Selection
Application Selection is managed by M2OS. To

achieve this step, it uses services of Custom,
EMVDC and others application.
EMV Custom is involved in this function to provide
Engine with the list of managed AID and related
information.
Detailed process is described in TDS training
course.
! It is also possible to launch an EMV transaction by an amount entry
or by application menu or even dedicated function key. In the
two last cases, M2OS is no more involved in the application
selection process. This process is initiated by Custom

Application Initialisation
During application initialisation, Custom

component shall :
– Prepare the new transaction (initialise internal data,
transaction date and time, manage display …)
– Manage amount entry
 In case amount is entered before card insertion, amount entry is not performed
during application initialisation
 In some cases, it may be requested to postpone amount entry after
READ_APPLICATION_DATA step, => but possible only if card does not
require amount during application initialisation step !
– Retrieve and return all parameters related to the AID

M2OS EMV ENGINE EMV CUSTOM EMV DC ICC

debit_emv (Selected AID)
Engine_DoTransaction()
Start new
transaction
EMVCUST_process_step (START)
Initialise data for the
new transaction
EMVCUST_Get_AID_Data (AID)
Extract EMV
application Dependent
Data
EMVCUST_Get_AID_Param (AID)
Extract application
parameters

M2OS EMV ENGINE EMV CUSTOM EMV DC ICC

EMVDC_process_step (FINAL_APPLICATION_SELECTION)
SELECT (AID)
EMVCUST_process_step (FINAL_APPLICATION_SELECTION)
Amount entry
EMVDC_process_step (INITIATE_APPLICATION_PROCESSING)
GET_PROCESSING_OPTIONS
EMVCUST_process_step (INITIATE_APPLICATION_PROCESSING)

Read Application Data
At this step, Custom Component should :

– Stop the transaction, depending on transaction type (if refund …).
This is linked to local rules.
EMV Custom may force the end of the transaction by a “CANCELLED” status code
– Perform exception file control. To do this, the custom shall :
• Read the PAN number from EMVDC
• Search in exception file if PAN is present
• Write the result into TAG_CUST_PAN_IN_BLACK_LIST

Custom component is to retrieve Certification

Authority public key :
• Read AID and extract RID.
• Read Certification Authority Public Key Index used
• Retrieve relevant CA key from the parameter local Database
• Put the result in the output DEL to engine

EMV ENGINE EMV CUSTOM EMV DC ICC

EMVDC_process_step (READ_APPLICATION_DATA)
READ_RECORD
READ_RECORD
………………….
EMVCUST_process_step (READ_APPLICATION_DATA)
Analyse Transaction Status,
depending on transaction type
Exception File Control
Reply with CA Keys Extract CA Keys

Data Authentication and Processing Restrictions
EMVDC_process_step (OFFLINE_DATA_AUTHENTICATION)
INTERNAL_AUTHENTICATE
(if method is DDA)
EMVCUST_process_step (OFFLINE_DATA_AUTHENTICATION)
EMVDC_process_step (PROCESSING_RESTRICTIONS)
EMVCUST_process_step (PROCESSING_RESTRICTIONS)

Cardholder Verification Process
EMV Custom is in charge of human interface during this phase

(MMI).
In case CVM is online PIN verification, EMV Custom is in
charge to initiate PIN enciphering.
Two transaction steps are dedicated to this process :
– EMVDC_CARDHOLDER_VERIFICATION_FIRST is called the first
time the first method is applied.
– EMVDC_CARDHOLDER_VERIFICATION_OTHER is called
repetitively until the end of the Cardholder Verification phase.


EMVDC_process_step (CARDHOLDER_VERIFICATION_FIRST)
Search first applicable method

from candidate list
EMVCUST_process_step (CARDHOLDER_VERIFICATION_FIRST)
Apply first method. Perform
PIN entry when needed


Sequence performed repetitively, if needed
EMVDC_process_step (CARDHOLDER_VERIFICATION_OTHER)
GET_CHALLENGE (when needed)
VERIFY_PIN (when needed)
Search next applicable

method if needed
EMVCUST_process_step (CARDHOLDER_VERIFICATION_OTHER)
Apply next method if needed.

Perform PIN entry when needed

Cardholder Verification Process PIN code management
PIN code management is fully under control of crypto

processor. Main processor has no access to the PIN code
value in plaintext mode.
In each case, 2 schemes are involved for the PIN
management :
– PIN code verified by ICC (Enciphered pin offline)

• One scheme for PIN Entry, located in Custom component
• One scheme for PIN enciphering (if needed) and PIN presentation to card located
in EMVDC component
– PIN code verified online (Enciphered pin online)
• One scheme for PIN Entry, located in Custom component
• One scheme for PIN enciphering, also located in Custom component

Cardholder Verification Process : PIN OFFLINE configuration :
CUSTOM EMVDC
PIN ENTRY PIN in dedicated PIN CODE

Crypto.
SCHEME
crypto processor PRESENTATION
area
SCHEME
EMV EMV
Main Proc.
CUSTOM DC

Cardholder Verification Process : PIN ONLINE configuration :
CUSTOM CUSTOM
PIN in dedicated
PIN ENTRY crypto processor PIN CODE enciphering
Crypto. area for online presentation
SCHEME
Main Proc. EMV

CUSTOM

In default EMV Custom, PIN entry scheme is used.

In default EMV Custom, ISO9564 scheme is used for PIN
enciphering. It is to be replaced by the one effectively needed.
Key injection is done by the default EMV Custom. In a real
application, it shall be done separately by SKMT
Default CUSTOM also used an additional shemes to delete
working secret area (to be removed too)

Online treatments
EMV Custom is in charge of initiate communication with

acquirer host.
By default Authorisation Request is initiated by custom, forwarded to CUSTOM. Then
CUSTOM manages itself the communication.
For this purpose, TAG_CUST_IS_COMM_MANAGED_BY_CUSTOM is set.
EMV Engine calls service EMVCUST_Authorisation to perform

authorisation request.
EMV Engine calls then step
EMVDC_ON_LINE_PROCESSING. It is the Custom
responsibility to check if a new communication try is to be
done.

TERMINAL RISK MANAGEMENT

EMVDC_process_step (TERMINAL RISK MANAGEMENT)
GET_DATA (for Velocity checking)
EMVCUST_process_step (TERMINAL_RISK_MANAGEMENT)

TERMINAL ACTION ANALYSIS CARD ACTION ANALYSIS
EMVDC_process_step (TERMINAL ACTION_ANALYSIS)
EMVCUST_process_step (TERMINAL_ACTION_ANALYSIS)
EMVDC_process_step (CARD ACTION_ANALYSIS)
GENERATE_AC
EMVCUST_process_step (CARD_ACTION_ANALYSIS)

Authorisation request & referral management

Authorisation request is asked only if decision after card action analysis is to go online
EMVCUST_AUTHORISATION ()
Send authorisation request to the acquirer host
wait for host response.
Referral is asked only if requested by host (no more by card)
EMVCUST_VOICE_REFERRAL ()
Manages referral, according to EMV and

local requirements
If referral is requested by host, EMV ENGINE calls EMVCUST_AUTHORISATION first, and

then EMVCUST_VOICE_REFERRAL
If referral is asked by the card, EMV Engine calls EMVCUST_VOICE_REFERRAL first, and
then EMVCUST_AUTHORISATION (but this case is no more acepted by payment schemes)

Online Processing

EMVDC_process_step (ONLINE_PROCESSING)
EXTERNAL_AUTHENTICATE
(when needed)
EMVCUST_process_step (ONLINE_PROCESSING)
EMVDC_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_1)
All commands in the script
EMVCUST_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_1)

Completion
At the end of the transaction, EMV Custom shall :

– Display a message giving the transaction result.
– Print a receipt.
– Register the transaction into the batch file.

Completion

EMVDC_process_step (COMPLETION)
2nd GENERATE_AC
EMVCUST_process_step (COMPLETION)
EMVDC_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_2)
All commands in the script
EMVCUST_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_2)
EMVDC_process_step (STOP)
Power_Down
EMVCUST_process_step (STOP)

Fallback
A fallback occurs when terminal attempts and fails to read ICC.

In this case terminal allows transaction to be performed using
Magnetic stripe.
Fallback function involves both EMV and Magstripe Debit/Credit
Application.
– Architecture design involves the way fallback function is
implemented.
EMV requirements does not describe the fallback cases :
– Visa and MasterCard published their own requirements.
– Local requirements may be specific.

Fall back
3 main cases of fall back may occur :

Terminal is unable to access the card (I.e Power On
failure)
Application selection fails because card is blocked or
application is blocked.
Card dialog error occurs during transaction.

Fall back when terminal is unable to read the card
In this case, M2OS displays a message “USE MAG STRIPE”.

When a magnetic card is swiped, Mag Stripe application is
called.
In this case, M2OS sets parameter “report_piste”.
An application can manage fallback instead of M2OS, by
implementing an entry point called “fall_back”
EMV Custom is not involved in this case.

Fall back at the end of application selection
In this case, magstripe application or Custom has to detect a case of

fallback. When detected by Custom, MagStripe application is called
through a specific service call to perform fall back process.
Detection may be done by adding an entry point if_for_you_after().
This entry point will be called after the EMV application selection.
Detection of “number of matching AID” :
– Check tag TAG_NUMBER_OF_MATCHING_APP
Detection of card blocked :
– Check tag TAG_LAST_APDU_CMD_RESPONSE
Detection of application blocked :
– Use service EMVDC_get_commands and check individually each
SELECT command if no PSE was used.

Fall back at the end of application selection
Read “number of matching AID” :

Read tag TAG_NUMBER_OF_MATCHING_APP from EVMDC
NO
NB AID > 0 ? NO FALL BACK
YES
Read the tag TAG_LAST_APDU_CMD_RESPONSE from EVMDC
YES
Card blocked ? FALL BACK Call service EMVDC_get_commands
to retrieve the list of commands used
NO during application selection process.
If the PSE algorithm was used, no
Read the list of SELECT commands. check possible.
Check if an application is blocked Else, check the status word in
YES response of the Select commands, to
determine whether the application is
NO
Appli blocked ? FALL BACK blocked or no.
YES
NO FALL BACK

Fall back during transaction
In this case, EMV Custom has to detect fallback case. It has to

tell MagStripe application to perform fallback treatments
Detection is done during EMV transaction flow an a specific
error code is set.
Later in EMVDC_STOP step, Custom check the reason why the
transaction is declined by testing this specific error code and
initiate fallback.
different detection cases :
– Check tag TAG_LAST_APDU_CMD_RESPONSE to find the status
word
– Check error code given by EMVDC.
– …


Glossary

Module hierarchy
CUSTOM
CU_ENTRY CU_SERV
M2OS entry points Services implementation
CU_STR CU_MORE CU_PIN CU_PARAM

Magstripe Management Maintenance menu PIN Code management Parameter files management
Low Level Modules

CU_COMM CU_BATCH
Batch file management
Access to the COMM component
CU_TERM
CU_BASE
Internal Database Management Utility functions for Terminal management
CU_RECEIPT CU_MESS
Receipt printing Message tables
CU_LOGOS CU_BLACKL
Bitmap to print or display Exception file management

Glossary
•AAC Application Authentication Cryptogram : Cryptogram indicating a rejected transaction

•AAR Application Authorisation Referral : Cryptogram asking for a referral
•AC Application Cryptogram : Cryptogram calculated by the card at the end of a
transaction/
•ADF Application Definition File : Directory in the card, associated with an application
•AEF Application Elementary File : Elementary file in the card, containing data for an
application
•AFL Application File Locator : List of files, with relevant records, to be read
•AID Application Identifier :  Name of the ADF in the card containing the
application
•APDU Application Protocol Data Unit : Elementary exchange between the terminal and the
card, C_APDU for a command sent by the terminal, R_APDU for the card response.
•ARC Authorisation Response Code : Response Code given by the host acquirer.
•ARPC Authorisation Response Cryptogram : Cryptogram generated by the Issuer and verified by
the card, permitting Issuer host authentication.
•ARQC Authorisation Request Cryptogram : Cryptogram asking for a host authorisation
•ATC Application Transaction Counter : Number of transactions done with the application,
into the card.
•ATM Automatic Teller Machine : Cash distributor

Glossary
•CDOL Card Risk Management Data Object List

•CVM Cardholder Verification Methods : List of methods used to verify if the cardholder
is the authorised user of the card.
•DEL Data Element List : Internal mechanism, enabling an application
to transmit data elements to an other one.
•DDA Dynamic Data Authentication : Method for the offline card authentication,
requesting the card to dynamically certify a set of data, different for each transaction.
•DDF Directory Definition File : Directory File, referencing either other DDF,
or Application Directory Files.
•DDOL Dynamic Data Authentication Data Object List
•DES Data Encryption Standard : Symmetric cryptographic algorithm.
•IAC Issuer Action Code (Denial, Default, Online) : Decision tables reflecting the issuer
rules for the terminal decision, at the end of the transaction
•IAC(2) Inter-Application Communication : Mechanism enabling data exchanges
between 2 applications
•ICC : Integrated Circuit(s) Card : A card into which one or more integrated
circuits are inserted to perform processing and memory functions
•PAN Primary Account Number : Card Number

Glossary
•PDOL Processing Options Data Object List

•PIN Personal Identification Number : a 4 to 12 digits value, entered by the
cardholder, and used to verify he is the authorised user of the card.
•POS Point of Service : Synonym for a payment terminal, used by a
merchant.
•PSA Payment System Application
•PSE Payment System Environment : Algorithm used to build the candidate list
during application selection.
•RID Registered Application Provider Identifier : A five bytes identifier, identifying a
Payment Scheme. Radix of the AIDs.
•RSA Rivest, Shamir, Adleman Algorithm : Public key enciphering algorithm, used in
EMV.
•SDA Static Data Authentication : Simplest method allowing the offline card
authentication.
•SFI Short File Identifier : File identifier on one digit. Permits a direct
access
•SHA Secure Hash Algorithm : Normalised algorithm producing a 20 bytes
hash value on messages, used in EMV.

Glossary
•SW1 Status Word One

•SW2 Status Word Two
•T=0 : Character oriented, asynchronous, half duplex transmission protocol
•T=1 : Block oriented, asynchronous, half duplex transmission protocol
•TAC Terminal Action Code(s) (Default, Denial, Online)
•TC Transaction Certificate : Cryptogram for an approved transaction
•TDOL Transaction Certificate Data Object List
•TLV Tag Length Value : Method used to express all data in EMV
•TVR Terminal Verification Results : A five bytes bit-map, containing the result of
all controls done by the terminal during the transaction.

EP2EMV+Multi Custom+12 11 2009

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EP2EMV+Multi Custom+12 11 2009

Uploaded by

Copyright:

Available Formats

EMV

Part 1 : Technical Presentation

EMV in a few words

3 Easy Path to EMV • Training course

Common requirements initially created by :

Main goals to enable smart card utilisation for payment :

4 Easy Path to EMV • Training course

SWIPE card SMART Card

Card has static behaviour Scripts can be sent to dynamically

And EMV C’less technologie is now coming …

5 Easy Path to EMV • Training course

6 Easy Path to EMV • Training course

only latest release of specification is valid :

see also a set of evolutions “bulletins” published by EMVCo

7 Easy Path to EMV • Training course

EMV requirements are available freely on internet :

 EMV Requirements 4.2 are split into 4 books :

 Bulletins edited for specification updates, or explanations

8 Easy Path to EMV • Training course

Issuer Provides card to Cardholder

Cardholder Payment card Owner

Merchant Accepts card for payment

Acquirer Merchant terminal Provider. Handle communication

9 Easy Path to EMV • Training course

 Roughly, a transaction is driven by both ICC (i.e issuer), and terminal

10 Easy Path to EMV • Training course

EMV in a few words

11 Easy Path to EMV • Training course

EMV Cards are 7816 compliant

12 Easy Path to EMV • Training course

13 Easy Path to EMV • Training course

Follows hierarchy, as described in ISO 7816

14 Easy Path to EMV • Training course

•PSE method not supported

15 Easy Path to EMV • Training course

ADF1 ADF2 ADF3

AEF1 AEF2 AEF1 AEF2 AEF3 AEF1 AEF2

•PSE method supported

16 Easy Path to EMV • Training course

DDF2 DIR FILE ADF3

ADF1 ADF2 ADF4

AEF1 AEF2 AEF1 AEF2 AEF3 AEF1 AEF2 AEF1

17 Easy Path to EMV • Training course

 All Data are expressed in the form of TLV (Tag, Length,

 Data objects can be basic or constructed. Value of a

Tag Length Constructed Value

Tag Length Value Tag Length Value …

18 Easy Path to EMV • Training course

19 Easy Path to EMV • Training course

 up to 4 Data Objects, transaction dependent, can be read

 Most of other Data Objects, not transaction dependent, are

 Some other Data are only returned in response to specific

20 Easy Path to EMV • Training course

Data inside terminal can be regrouped into 3 sets

 Application Independent Data : General terminal characteristics

 Application Dependent Data : AID Parameters

21 Easy Path to EMV • Training course

 Transaction Dependent Data :

22 Easy Path to EMV • Training course

Transaction Status Information (TSI)

Terminal Verification Result (TVR)

23 Easy Path to EMV • Training course