emv overview

Overview of EMV

Specification

Objective of the Session

To explain the scope of the EMV specifications and

associated hierarchy. Additionally to gain an

understanding of EMV functions.

Agenda

Payment specifications review

EMV functional overview

Transactions flow

Functions available

Offline authentication processes

Offline risk management processes

Online authentication and message integration

Payment Specifications Review

EMV specification hierarchy with the payment industry

AEIPS MCHIP VIS

CB5 NATIONAL (examples)

ASSOCIATIONS

INDUSTRY

J/Smart D/PAS

EMV ICC Specifications for Payment

Systems

Book 1 :

Application Independent ICC to Terminal Interface

Requirements

Book 2 :

Security & Key Management

Book 3 :

Application Specification

Book 4 :

Cardholder, Attendant and Acquirer Interface

Requirements

Book 1: ICC to Terminal Interface

Specification

This specification describes the minimum functionality

required for integrated circuit cards (ICC) and terminals to

ensure correct operation and interoperability independent of

the application to be used.

ISO 7816 – 1 / 2 / 3

Electromechanical characteristics

Logical interface

Transmission protocols

ISO 7816 – 4 / 5

Files structure & referencing

Message structure

Application selection

Book 2: Security & Key Management

Offline Static Data Authentication (SDA)

Offline Dynamic Data Authentication (DDA)

Offline PIN Encipherment

Application Cryptogram generation

Public key management principles and policies

Terminal security requirements

Secure messaging

Defines the terminal payment application

Mapping of data elements to files

Transaction flow and the set of commands issued to the

card

Coding of specific data objects

Chip electronic commerce specification

Acquirer Issuer Issuer

NPCI

Book 3: Application Specification

Book 4: Terminal Specification

General requirements

Terminal types and capabilities

Functional requirements

Physical characteristics

Security requirements

Software architecture

Interfaces: Cardholder, Attendant, Acquirer

EMV Transaction Flow

Application Selection

Application Initiation

Reading Application Data

Setting Up

Offline Data

Authentication

Processing Restrictions

Cardholder Verification

Terminal Risk Management

Card Action Analysis

Online Processing

Issuer Authentication

Script Processing

Terminal Risk

Checks

Authorization

Decision

Completion

Card Risk Management

Terminal Action Analysis

Preventing Fallback Transactions

SWIPE

Please read card via

chip reader. Service Code = Chip

2 (chip international)

6 (chip domestic)

Chip Card Chip Device


Terminal decides which application

to use for the transaction – important

as we move into multiple application

cards

Application Identifier – AID

(2 components)

Identifies scheme : AXXXXXXXXX

Identifies Product/Acceptance Mark

Credit / Debit: XXXX


Approve?

Decline?

Online?

Online

Scripts

Offline



Offline Data Authentication





Authe

nticatio

n

Application Selection: 1 Match

RuPay Debit

E-Purse

RuPay Debit

Loyalty

Easy Air Miles

Application Selection: 2 Matches

RuPay Debit

Visa Electron

Easy Air Miles

RuPay Debit

Loyalty

Easy Air Miles

Application Selection: 2 Matches

Cardholder selects which application to use

Press 1 for RuPay Debit

Press 2 for Easy Air Miles

E-Purse

Easy Air Miles

RuPay Debit

Application Selection: No Matches

Applications Selection: No Matches

Transaction is terminated

No Application

Found


Before the transaction starts, the

terminal needs to know the profile of the

card:

Do you support SDA? DDA?

Do you support Issuer authentication?

Where are the data (needed for the

transaction) stored in the chip?

The card will send this information to the

terminal (AIP, AFL), in order to initiate

the transaction

AIP: Application Interchange Profile

AFL: Application File Locator


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n


With the information gathered during the

“Application Initiation” phase, the terminal

reads the data (referred to as tags) from

the card

At this stage of the transaction the data

are stored by the terminal

The terminal will use the data during the

transaction and the risk management

phase (SDA, check expiry date,…)

SDA: Static Data Authentication


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n



Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Offline authentication (SDA or

DDA) is performed

Terminal uses RSA cryptography

to verify the authenticity of the data

in the card

SDA: Static Data Authentication

DDA: Dynamic Data Authentication

RSA: Rivest Shamir Adleman


Before a card transaction can take place, certain card data is

authenticated by the terminal.

There are three methods of offline card authentication, both

involving RSA and EMV certificates.

Static Data Authentication (SDA)

Dynamic Data Authentication (DDA)

Combined DDA/Application Cryptogram Generation (CDA)

In all cases, payment system public keys are stored in the terminal

and an Issuer public key certificate is stored on the card.

Issuer certificate is signed by the Payment System CA

CA: Certification Authority

Static Data Authentication (SDA)

Static data on the card is signed using the RSA private key of the Issuer and the result is stored on the card.

Static Authentication Data includes:

– Primary Account Number (PAN)

– Application Expiry Date

– Issuer Parameters

SDA does not prevent replay attacks.

Benefits

SDA is used to validate that certain data elements on the card have not changed since the card was issued.

(Issuer)

SISS

Private Key

(Issuer)

PISS

Public Key

Private Key

(CA)

SCA

Public Key

(CA)

PCA

PISS certified

with SCA PCA distributed to Acquirer

for loading in Terminal

Card static

data

SDA - Initialization Phase

Dynamic Data Authentication (DDA)

DDA provides authenticity and integrity of ICC and terminal dynamic

application data (signed by ICC private key).

Allows detection of unauthorized alteration of ICC data after the card

has been personalized.

Prevents replay attacks and ICC counterfeiting.

DDA involves a terminal Unpredictable Number and Dynamic ICC

Data. ICC: Integrated Circuit Card

… It requires a special type of chip (crypto-processor) which is more expensive and DDA is more complex to personalise

Benefits

DDA is stronger than SDA because it is dynamic and uses transaction specific data so it protects against skimming but…

(Issuer)

SISS

Private Key

(Issuer)

PISS

Public Key

Private Key

(CA)

SCA

Public Key

(CA)

PCA

PISS certified

with SCA PCA distributed to Acquirer

for loading in Terminal

(ICC)

SIC

Private Key

(ICC)

PIC

Public Key

PIC certified

with SISS

DDA - Initialization Phase

First four steps are the same as with standard DDA

– Retrieval of Certificate Authority Public Key

– Retrieval of Issuer Public Key

– Retrieval of Issuer Public Key

– Verification of Signed Static Application Data

No other DDA processing is done until later in the transaction when the card signs

and returns the Application Cryptogram and other data to the terminal

Successful recovery of the data proves that the Application Cryptogram came from

the genuine card

Benefits

• Like DDA and SDA, it proves that the card data is valid and has not been

altered

• Like DDA, it proves that a genuine card is present

• Additionally, it allows the terminal to verify that the Application Cryptogram

came from the valid card

Combined DDA/AC Generation

Do the Application

Version Numbers match?

Can the card be used

for the transaction?

Is the card effective?

Is the card expired?

Usage Controls

» Domestic cash

» International cash

» Domestic goods

» International goods

» Domestic services

» International services

» ATM’s

» Devices other than ATM

» Cashback domestic

» Cashback International



Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n


The issuer decides on their

Cardholder Verification Method (CVM)

List and personalises it onto the card

Offline PIN (Plaintext and/or

Enciphered), Signature, Online

PIN, No CVM

The terminal reviews the card’s

Cardholder Verification Method (CVM)

List and determines which cardholder

verification method to use for the

transaction (based on the cardholder

verification methods supported by the

terminal)


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Signature

No CVM

Offline Enciphered PIN

Offline Plaintext PIN

Online PIN

Signature

No CVM

Terminal’s Supported CVMs Card’s CVM List

The terminal checks the card’s CVM list and the first mutually supported method Is selected

For this example: Signature

X

X

X

CVM Decision: Signature

The terminal checks the card’s CVM list and the first mutually supported method Is selected

For this example: Offline Plaintext PIN

Offline Enciphered PIN


Online PIN

Signature

No CVM


Online PIN

Signature

No CVM

Terminal’s Supported CVMs Card’s CVM List

X

CVM Decision: Offline Plaintext PIN


Card on terminal exception file?

Amount over the floor limit?

Randomly selected for online?

All processing executed by the terminal


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Terminal checks results

so far. Generates

Terminal Verification

Results (TVR) and

provides its position

to the card

Approve Request

Decline request

Go online request

The terminal records results of risk management checks in Terminal Verification Results (TVR)


I think we should go

online – what about you?

Terminal Sends Decision to Card

Card Responds

Let me do some further

checks to see if I agree

with you


The card does additional risk

management checks to see if it

agrees with the terminal’s decision

Think of “checks and balances”

Helps to prevent a fraudulent card

and merchant collusion


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Decision

Previous Txn

checks

Not completed

Issuer script failed

SDA failed

DDA failed

Counter checks

Dom. Offline Limits

Int’l Offline Limits

Domestic currency

Offline spend

2nd currency

Offline spend

New Card

PIN exceeded

The card records results of risk management checks in Card Verification Results (CVR)


These are some of the Offline Authorisation Control limits on the

card

50

Total Offline Trans.

Amount Limit

Total # of Offline

Trans. Limit

3

Example of Offline Authorisation Controls

of the Card

I purchase train ticket for $20

How much do I have left to spend off-line?

How many more times can my card stay off-line?

Cumulative Total Offline

Trans. Amount

50


Amount Limit

0 0 0 2 0

Total # of Offline

Trans. Limit

3

Cumulative # of

Offline Trans.

0 1


of the Card

$30 and 2 transactions left for off-line


of the Card

I purchase a coat for $300.

What happens?


Trans. Amount

50


Amount Limit

0 0 0 2 0

Total # of Offline

Trans. Limit

3

Cumulative # of

Offline Trans.

0 1

Transaction is sent online because Total Offline

Transaction Amount Limit is triggered.

(Total # of Offline Transaction Limit is not triggered).

Once my card goes on-line, all off-line

parameters are reset back to ‘0’


Trans. Amount

50


Amount Limit

0 0 0 0 0 0

Total # of Offline

Trans. Limit

3

Cumulative # of

Offline Trans.

0 0


of the Card

Terminal

requests

Decline

Online

Approve

Decline

Decline

Decline

Online

Online Approve

Card can respond with

Approve? Decline? Send Online?

Who is in control of the decision?

X X

X


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Online Message (Card to Issuer)

The transaction is sent online to the

issuer

The card generates a cryptogram to be

sent to the issuer (online authentication)

The cryptogram and the results of all the

offline risk management checks (SDA

results, expiry date results, etc.) are sent

online


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

EMV Functional Overview

Important Note :

All EMV messages (generated from terminals using EMV cards)

will be longer than normal magnetic stripe messages as they

include additional chip data

Mag stripe Authorisation message

EMV Authorisation message CHIP DATA

Online Message (Issuer to Card)

The issuer validates the cryptogram

using their host system (DES keys)

The issuer can review the offline risk

management checks

The issuer must send a cryptogram in

the response so that the card can

validate the issuer (for mutual

authentication)

The issuer can send Issuer Scripts in the

response (to dynamically update

information on the card)


Approve?

Decline?

Online?

Online

Scripts

Offline








Authe

nticatio

n

Card validates Issuer

Via secure message

Sends secure message

(MAC) using DES

Card validates integrity

of the script request

Sends script command

Enciphered with DES

Card applies script

command

Terminal is used as a

pass through device

Issuer Scripts

Transaction Certificate Generation


NPCI

MDK

UDK MDK

Transaction Certificate Generation

NFC must validate ARQC using MDK (Card Authentication)


NPCI

MDK

UDK

MDK UDK

MDK


SDA

Static data

authentication

Off-line auth

controls

On-line

Card / Issuer

authentication

DDA

Dynamic data

authentication

Script updates CVM

Card Verification Method

Off-line PIN

On-line PIN

Signature

No CVM


Benefits

Offline checks (SDA, DDA, PIN, …)

Different level of offline security (different cost)

Online authorisation for added security

Enables flexibility in the cardholder verification

Ensures global inter-operability in the cardholder verification

method (CVM)

Allows card to make risk management decisions

Reduces account losses

Expand into new market segments

Key Points

EMV covers card-terminal interface

EMV transaction more complex than magnetic stripe

EMV functions provide different benefits to payment

processing

Business decisions can drive EMV functionality

EMV Functionality will have different impacts on the

system

Thank you

emv overview

Documents

mutually supported method

initialization phaseprivate key

sca public key

offline authorisation controls

terminals supported cvms

cardholder verification method

risk management checks

piss pca distributed