Upload
others
View
10
Download
0
Embed Size (px)
Citation preview
Choosing the Correct Card Technologies, Options and Card
Management Strategies for Issuers Philip Andreae
Director Field Marketing – Oberthur Technologies
• August 2011: Visa Inc. announced its roadmap • June 2012: American Express, Discover and MasterCard agreed to converge on the
same common Bmeline • April 2013: Acquirers and processors must support EMV transacBons • October 2015: Liability shiK
• Liability is the responsibility of the party not protecBng the transacBon • Liability remains the issuer’s if merchant upgrades to EMV
• October 2017: Liability shiK for gas staBons • December 2013: Following a number of compromises – Target, Neiman Marcus
– the @me has come for the U.S. to embrace EMV
Why Are We Here?
2
• What capabiliBes? • AuthenBcaBon method: DDA/CDA to support
offline or 100% online? • VerificaBon method: Online/in chip PIN or
signature?
• AuthorizaBon method: Offline capable or 100% online?
• Which applicaBons to support? • Transit, data storage or access control? • MChip, VIS, AEIPS, D-‐Pas or CPA?
• Durbin approach: Which debit networks?
• Which chip? • What operaBng system? • What memory size? • Cryptographic capabiliBes? • Interface contact or dual?
Key Decisions
• Leader, fast following or not interested? • InternaBonal travelers first? • Which segments of the credit por]olio? • Which segments of the debit por]olio? • Which segments of the commercial and
T&E por]olio? • Mass issuance or standard reissuance?
3
Three Key Capabilities Define the Capability the Smart Card Must Support
4
PIN verified in chip or on issuer host
Unique serial number and cerBficates valid scheme, issuer and card
Online authen6ca6on with offline op6on
Terminal risk management
Card risk management
“What you have”
Authentication
“What you know”
Verification
“You have the funds”
Authorization
Public key loaded in terminal
• Payment networks have cerBficate authority
• Public keys are distributed to all terminals supporBng offline data authenBcaBon
Issuer is a member
• Issuer registers with payment network • Payment networks provides issuer cerBficate
Card is authenBcated
• A set of keys and cerBficates are loaded in the card at personalizaBon
• The point of sale terminal authenBcates the digital cerBficates provided by the card
Authentication
• EMV supports 3 offline card authenBcaBon methods: • Sta@c data authen@ca@on (SDA): The
data verified by the POS is always the same
• Dynamic data authen@ca@on (DDA): The data verified by the POS is dynamic for each transacBon
• Combined DDA and applica@on cryptogram (CDA): Merges DDA with the applicaBon cryptogram
• InternaBonal schemes require DDA
or CDA if offline capable is desired
5
Chip and PIN
Chip and Signature
Chip and Choice
Verified in Card or On Host
PIN SynchronizaBon
Consumer Choice
Verification
• EMV offers the issuer various cardholder verificaBon methods, like: • Online PIN verificaBon • In-‐chip PIN verificaBon • Clear text or encipher PIN • Signature verificaBon • No CVM
• Or any combinaBon, including rules: • No CVM below $10 • Offline PIN between $10 and $100 • Offline PIN + signature above $1,000
• Phantom PIN is also possible
6
• The design of EMV assured issuer control: • Terminal risk management: The
merchant sets a floor limit under which the terminal will ask the card to approve the transacBon
• Card risk management: Parameters defined – the issuer ulBmately decides
• The value of offline authorizaBon:
• The issuer always decides • Reduces the cost of authorizaBon • Reduced the transacBon Bme
Authorization
7
TC Offline
ARQC Online
AAC Decline
TC Offline Yes Yes Yes
ARQC Online Why Yes Yes
AAC Decline Why Why Yes
Term
inal
Re
ques
ts
Card Decided
Field 55 Supports Online Authentication and Card Life Cycle Management
8
Interface to chip: • Prepare
authorizaBon request
• DraK data capture
Terminal
• Select appropriate route
• Forward to payment network
Acquirer • Validate
transacBons • Route to issuer
Payment Network
• AuthenBcate ARQC
• Authorize transacBon
• Prepare ARPC and scripts
• Return authorizaBon response
Issuer
Authoriza@on or Financial Request: The ARQC to authenBcate the card to the issuer
Authoriza@on or Financial Response: The ARPC authenBcates the issuer to the card (A
chance to update the card with scripts)
Clearing Record: The transacBon cerBficaBon to assure irrefutability
• AuthenBcate TC • Seole towards
payment system
Merchant Acquiring Bank Payment Switch Issuing Bank
How Will the Chip Card Communicate with the Terminal?
9 *Not compa6ble with foil card designs
Pure contactless card*: 1. One chip connected to the antenna and buried inside plasBc body 2. Works only in contactless mode
Dual interface card*: 1. One chip embedded with external contacts and antenna connecBons 2. Works in contact and contactless mode (contactless like US contactless and NFC
transacBons – future proof soluBon)
Contact card: 1. One chip connected to external contacts 2. Works only in contact mode
Elements of Comparison
NATIVE JAVASCRIPT MULTOS • Proprietary OS: Supplied by all major
vendors • Highly secure: Hardware (EAL5+) and
soKware (EAL4+). • Dominant smart card technology: Most
widely deployed to date • Full EMV compaBbility for single and
mulB-‐applicaBons payment cards • Offer best price compeBBveness to
issuers. Ideal choice for EMV migraBng markets and mass volume penetraBon strategy
• OpBmized OS and applicaBons for best-‐in-‐class memory consumpBon and Bming performances
• Full compaBbility with EMV common personalizaBon systems offering issuers mulBple sourcing and seamless products migraBons (lower switching cost).
• Many providers compeBng on performance and security, with mulBple silicon providers
• Industry open standard: Offer the largest mulB-‐sourcing to issuers
• High portability and security • Open business model: Issuer-‐centric or
mulB-‐issuer • Possibility to reuse exisBng
infrastructure (KMS, CA) • Java cards can be issued using any
global pla]orm compliant infrastructure such as personalizaBon equipment and key management system
• Healthy compeBBon brings innovaBon faster to the market place, along with compeBBve prices for the issuers
• ApplicaBons developed in Java standard language known by most developers
• Large pool of OS implementers compeBng on performance and security, with mulBple silicon providers
• Proprietary standard • High security standards • Issuer-‐centric model • Must set up a MULTOS compliant KMA
or outsource the service to StepNexus • All MULTOS implementaBons must pass
MULTOS type approval • Centralized applicaBon model • Applet code size is usually smaller than
for Java card. This saves space in EEPROM.
• ApplicaBons developed in MEL proprietary assembly language known by few developers
• 5 OS implementers with 5 different silicon providers. 1 OS implementer has 80% market share.
• Limited price compeBBon between card vendors
10