11
Choosing the Correct Card Technologies, Options and Card Management Strategies for Issuers Philip Andreae Director Field Marketing – Oberthur Technologies

Choosing the Correct Card Technologies, Options and Card

  • 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  

Applications, Offline Characteristics and Interfaces Establish the Requirement of the Chip

11  

1  

2

3  

4  

5  

MChip    VSDC    AEIPS   Transit  Access  PKI  

1. AID(s)  2. Keys  3. ConfiguraBon  Parameters  

4. Card  Risk  Management  Parameters  

5. Counters  6. PIN  

RSA  TDES  

Secrets  Contact  Contactless  Dual