Documente Academic
Documente Profesional
Documente Cultură
1 •
E.M.V (Part 1)
Technical presentation :
“A summary of EMV specifications”
2 •
EMV - Summary
– 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
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
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 …)
2 levels of Requirements :
Level 1 : Physical layer and Data Link Layer
Level 2 : Application Layer
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
ADF1
AEF1 AEF2
DDF
“1PAY.SYS.DDF01”, DIR FILE
DDF
“1PAY.SYS.DDF01”, DIR FILE
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
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
Analysis
PSE
Supported ?
Build the
candidate list List of AID PSE Method
Method
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
Candidate list
AID
A0000001
A00000031
A00000032
A00000031 A00000032
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
2 methods
allowed
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.
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
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.
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
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.
Signature
At the end of the transaction, it only asks for a signature on ticket receipt.
Terminal retrieves in its log file, last transaction with same PAN.
Maximum
Probability to Target
go online Percentage
Target
Percentage
0
Biased Selection Floor Limit
Threshold
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 …
Reject YES NO
Online Condition
Transaction fulfil ?
YES
Able to go NO
online ?
Process Action Code - Default
Objective : Make ICC know terminal decision, and ask for card final
decision.
Ask for TC (Transaction Ask for ARQC Ask for AAC (Application
Certificate) (Authorisation Request Authentication Cryptogram)
Cryptogram)
Terminal decision
TC ARQC AAC
Card decision
(*) under bulletin decision, referrals initiated by card are no more accepted
Card may also send to terminal an advice message for issuer host,
to be send in on-line authorisation or during clearing.
External Authentication
Transaction Cryptogram
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
Both MCI and Visa describe refund transactions with the same
principle :
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
Partners
SAGEM
Monétel EMV Level 1
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
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
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
SAGEM Monétel
Partners
Training Course
108 •
EMV Generic Package – Training Summary
Main principles
Application architecture
Application status
Open specification
– Includes multi-application concept.
– Usable by other issuers.
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
EMV DC
EMV CUSTOM EMV ENGINE EMV COMM
(EMV Kernel)
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 …
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
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
ONLINE TREATMENTS
EMVDC Engine Custom Comm
Online authentication X X
Financial transaction X X
messages
Batch data capture X X
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
Function Status
SDA Key length 1984 bits
DDA Key length 1984 bits
CDA Enhanced version – Key length 1984 bits
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
Independent applications.
EMV
COMM Some shared treatments
COMMON SERVICES
(Batch File, parameters
are located in DLL
…)
Located in DLL
M2 OS TELIUM
OEMC TELIUM
Independent applications. No
common treatments, except
EMV
COMM communication services
M2 OS TELIUM
OEMC TELIUM
EMV CUSTOM
Includes SWIPE EMV D/C
Debit Credit
application
OTHER APPLI
(e-purse,
EMV ENGINE
Healthcare …)
M2 OS TELIUM
OEMC TELIUM
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
Entry DEL
Calling Called
Component Output DEL Component
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.
With the second mechanism, data are physically copied and passed by value :
To figure out both problems, TLV Tree format is used now since EMV Pack13
EMV Custom offers a set of services to EMV Engine using IAC mechanism.
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
• 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
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
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)
The only services available from Custom to EMVDC are the data
base consultation service to retrieve data or commands.
EMVDC_get_data_elements()
EMVDC_get_commands()
Use to retrieve list of command sent to the card (used later for
fallback processing)
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
EMVCUST_process_step (FINAL_APPLICATION_SELECTION)
Amount entry
EMVDC_process_step (INITIATE_APPLICATION_PROCESSING)
GET_PROCESSING_OPTIONS
EMVCUST_process_step (INITIATE_APPLICATION_PROCESSING)
READ_RECORD
………………….
EMVCUST_process_step (READ_APPLICATION_DATA)
Analyse Transaction Status,
depending on transaction type
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)
EMVCUST_process_step (CARDHOLDER_VERIFICATION_FIRST)
Apply first method. Perform
PIN entry when needed
EMVDC_process_step (CARDHOLDER_VERIFICATION_OTHER)
GET_CHALLENGE (when needed)
EMVCUST_process_step (CARDHOLDER_VERIFICATION_OTHER)
CUSTOM EMVDC
EMV EMV
Main Proc.
CUSTOM DC
CUSTOM CUSTOM
PIN in dedicated
PIN ENTRY crypto processor PIN CODE enciphering
Crypto. area for online presentation
SCHEME
EMVCUST_process_step (TERMINAL_RISK_MANAGEMENT)
EMVCUST_process_step (TERMINAL_ACTION_ANALYSIS)
GENERATE_AC
EMVCUST_process_step (CARD_ACTION_ANALYSIS)
EMVCUST_AUTHORISATION ()
Send authorisation request to the acquirer host
wait for host response.
EMVCUST_VOICE_REFERRAL ()
EXTERNAL_AUTHENTICATE
(when needed)
EMVCUST_process_step (ONLINE_PROCESSING)
EMVDC_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_1)
EMVCUST_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_1)
EMVCUST_process_step (COMPLETION)
EMVDC_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_2)
EMVCUST_process_step (ISSUER_TO_CARD_SCRIPT_PROCESSING_2)
EMVDC_process_step (STOP)
Power_Down
EMVCUST_process_step (STOP)
NO
NB AID > 0 ? NO FALL BACK
YES
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
CUSTOM
CU_ENTRY CU_SERV
M2OS entry points Services implementation
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