a deeper dive into emv - conexxus deeper dive into emv february 19, 2015. agenda ... emv experience....
TRANSCRIPT
A Deeper Dive Into EMV
February 19, 2015
Agenda
• Housekeeping• About Conexxus• A Deeper Dive Into EMV• Q & A
Presenters• Carl Bayer
Program Manager, Conexxus
• Phil SchwartzManager IS, Valero Energy Corporation
• Bruce MurrayPresident, B2 Payment Solutions
HousekeepingThis webinar is not being recorded. The webinar presentation will be made available to all attendees after completing a short 4 question survey.
Once the survey is completed, a link will be provided to the presentation handout. Conexxus uses the survey results to develop the content for our webinar series.
About Conexxus• We are an independent, non-profit, member
driven technology organization• We set standards…
– Data exchange– Security– Mobile commerce
• We provide vision– Identify emerging tech/trends
• We advocate for our industry– Technology is policy
2015 Conexxus Annual ConferenceApril 26 – April 30, 2015Loews Annapolis Hotel
Annapolis, Maryland
www.conexxus.org/annualconference
© 20147
Who is B2
A products and services company with over a decade of global
EMV experience.
Offices in Toronto, ON Canada and Atlanta, GA USA
We provide world class knowledge, products and services for
EMV, Contactless, NFC, banking, e‐commerce and card payments
B2 is the exclusive distributor for the UL Payment Products
(formally Collis) in Canada and the USA
B2 is a Value Added Partner of VeriFone
© 20148
Introduction
The payment industry is migrating from magstripetechnology to the more secure EMV technology.
In this presentation we will take a deeper dive and:
Define EMV.
Understand how the EMV transaction flow is conducted through the contact interface.
© 20149
What is EMV? What is it not?
EMV is named after the original organizations that developed it: Europay, MasterCard and Visa.
EMV is a global, interoperable, secure standard for paymenttransactions. Security is based on dynamic cryptography.
It is a set of specifications that ensure interoperability between chip products and acceptance devices.
EMVwas designed as an acceptance device specification for card present transactions using a contact chip interface.
© 201410
7816
Application Data
Interface
Protocol + Data layers determine the transaction flow!
EMV Acceptance Device & Card
Chip Silicon
Operating System (native or open)
M/Chip 4.EXE
.TXT .TXT
Terminal Hardware
Operating System
EMV Kernel.EXE
EMV Kernel Configuration.TXT
Visa keys MasterCard keys
Payment Application
Protocol Layer
© 201411
Financial
Technical
Physical
Issuing bank
Card processor
Acquiring bank
Acquirer processorPayment Network
1 – 1st EMV decision2 ‐ Auth. Req.
7 ‐ Auth. Resp.
4 ‐ Auth. Req.
5 ‐ Auth. Resp.
3 ‐ Auth. Req.
6 ‐ Auth. Resp.
EMV Online risk management & Issuer Scripts
EMV Authorization
8 – 2nd EMV decision9 ‐ Goods
© 201412
Physical
Transaction processed by the acceptance
device!
Authorization performed offline
Brand accepted by device?
(AID)
EMV risk management
1st EMV decision
Go online?
DeclineApprove
Card risk management
1 ‐ Card and acceptance device
interaction
EMV Authorization
© 201413
EMV Authorization 1st EMV Decision
End of the 1st EMV decision
Select application
Read Application Data
Terminal Decision
ICC Decision
EMV Risk Management
Offline Data Authentication
Processing Restrictions
Cardholder Verification
Terminal Risk Management
3
5
6
4
1
2
7
8
© 201414
EMV Authorization – EMV Steps 1st Decision
Via interaction between the kernel, the chip and optionally the consumer :
The kernel builds a candidate list which includes all common supported brands (AIDs) between the kernel and the chip
The kernel chooses the AID to use for the transaction based on the priority set by the issuer
Depending on the issuer’s choice or when there is more then 1 AID the consumer is asked to confirm/select
Select application1
© 201415
EMV Authorization – EMV Steps 1st Decision
The chosen AID is activated in both the kernel and the chip
The kernel reads all the related information from the selected AID that is needed to perform the transaction.
The amount of application data that will be read by the terminal, is determined by the card issuer (why?)
Can be compared with reading information of a magnetic stripe bank card
Select application1
Read Application Data2
© 201416
EMV Risk management is used to decide whether the transaction will be conducted offline or online.
Offline Data Authentication –SDA/DDA/CDA
Processing restrictions – Application Expiry; Activation Date; Application Version of smart card and terminal application; Environment (e.g. ATM only, Domestic only)
Cardholder Verification Method (CVM) – No CVM; Signature; Online PIN; Offline plaintext PIN; Offline Encrypted PIN
EMV Authorization – EMV Steps 1st Decision
Terminal risk management ‐ floor limit, random selection for online and exception file checking
Offline Data Authentication
Processing Restrictions
Cardholder Verification
Terminal Risk Management
3
5
6
4
EMV Risk Management
© 201417
EMV Authorization – EMV Steps 1st Decision
The verdict can be one of the following:
decline the transaction
proceed with an online transaction
proceed with an offline transaction
At the end of step 7, the terminal communicates the verdict to the smart card
Select application
Read Application Data
Terminal Decision
EMV Risk Management
1
2
7
© 201418
EMV Authorization – EMV Steps 1st DecisionDuring step 8, the smart card also has to produce a verdict regarding the transaction risk
The smart card’s verdict can only be more restrictive than the terminal’s verdict (why?)
Select application
Read Application Data
Terminal Decision
ICC Decision
EMV Risk Management
1
2
7
8
Declin
e
Go on
line
Approve
offline
Decline
Go online
Approve offline
X X
X
Card
Terminal
© 201419
Physical
Transaction processed by the acceptance
device!
Authorization performed offline
Brand accepted by device?
(AID)
EMV risk management
1st EMV decision
Go online?
DeclineApprove
Card risk management
1 ‐ Card and acceptance device
interaction
EMV Authorization: 1st EMV Decision
© 201420
Select application
Read Application Data
Terminal Decision
ICC Decision
EMV Risk Management
1
2
7
8 Online Authorization 9
Online Processing
Verify the application cryptogram.
Validate consistency of chip data against terminal data.
Validate the Application Transaction Counter (ATC).
The issuer can also decide to send back an issuer script.
EMV Authorization: Online Request
© 201421
Select application
Read Application Data
Terminal Decision
ICC Decision
EMV Risk Management
1
2
7
8 Online Authorization 9
Issuer Scripting 10
Issuer Scripting is a mechanism that allows issuers to perform management actions on a smart card. Examples of issuer scripts are:
Resetting/changing the PINBlocking a smart cardBlocking and unblocking an applicationModifying the floor limit
EMV Authorization: Issuer Scripting
© 201422
Physical
2nd EMV decision
DeclineApprove
8 ‐ Card and acceptance device interaction
EMV Authorization: 2nd EMV Decision
© 201423
EMV Authorization:Steps 2nd Decision
Select application
Read Application Data
Terminal Decision
ICC Decision
EMV Risk Management
1
2
7
8 Online Authorization 9
Issuer Scripting 10
Completion11
There is another interaction between the chip and the kernel.
If a response has been received from the issuer, the kernel will send the issuer response to the chip.
The chip will respond with a final verdict regarding the transaction.
24
Contact Information
• Carl Bayer, Conexxus –[email protected]
• Phil Schwartz, Valero –[email protected]
• Bruce Murray, B2 Payment Solutions –[email protected]
The 411 of EMV - WebinarConexxus: Presentation Title25