EMV Considerations for Transit   Mike Burden   Commercial Manager   Consult Hyperion

Agenda

•  Introduction • Relationships with Schemes • Reader Design • Security • Transaction Model • Back office • Testing • Prototyping • Revenue Inspection Device • Summary

Ticketing technology has evolved significantly over the last 100 years

3

Metal Tokens

Paper Ticket

Smart Cards & Tokens

2D Barcodes

Cash

Magnetic Tickets

Contactless Payment Cards

Public Service Cards & Other ID

NFC

Biometrics?

Why migrate from cash and proprietary cards?

 Cash is expensive and inconvenient  Proprietary cards are expensive to

issue, re-issue and maintain against attacks

 What is being used for smarter tickets?

–  International Standards (e.g. Contactless Payment cards, TfL, SEPTA, CTA)

–  National standards (e.g. ITSO) –  Proprietary e-purse (e.g. Squid) –  Barcodes (e.g. UK Rail) –  Mobile apps (e.g. Arriva) –  Ski passes (e.g. Utah) –  Gov’t ID (e.g. Malasia)

4

Majority of public transport fares come from infrequent or irregular customers

“Commuters” “Non-commuters”

There is a trend away from card based schemes towards account based

6 Transport Ticketing 2013!

Smar

t N

on-S

mar

t

Account Card

Relationships with Schemes

Having a good working relationship with the schemes will make the process easier

•  Begin speaking with the schemes as soon as possible •  Both sides need to understand the other’s business and agree

a compromise solution •  Apportionment of risk is key •  The transaction model should maximise card holder

convenience and minimise operator and card issuer risk •  The certification process needs to be understood as it can

impact implementation

Reader Design

Transit & Payment Cards – A perfect marriage?

Transit  Market has driven Contactless uptake  Typically higher performance requirements

than payment (~ 200 – 300ms)   ‘Transaction’ may be driven by card

entering reader field – no driver / staff interaction – AUTOMATIC

 Fare may not be known at point of entry Payment

 EMV heritage  Optimised and faster than contact

payments (but slower than transit)  POS drives the transaction – the reader

requires staff  Transaction amount generally known

10

Contactless Payments – Why bother?

Transaction Speed – is it quick enough?

Is it secure  EMV - Offline Transaction Authentication  Magnetic Stripe – No offline Authentication – Overseas issuers

Transaction amount may not be known   If it is – easy!   If it’s not – some extra processing will be required

That’s all fine, but what’s in it for me?  Cash handling savings  Card issuance savings   Improved customer experience  Proven security

11

Reader Architecture

 Card Detection & Activation Complex:  Due to variety of accepted card types

 Certification hurdle

 Make use of Prototyping:  Prototyped algorithms to test options for detection & activation

 Optimal method identified  Impact on performance

New Multi-Scheme Reader

  ‘Ideal’ / modular architecture proposed at TfL   Designed for efficient re-certification

Security

Reader Architecture – PCI-DSS

PCI-DSS Security requirements on Merchants Scope is network components, servers, applications Specifies data where storage permitted & protection required

  PAN and Cardholder Name, Service code & Expiry Date Specifies data where storage prohibited after authorisation and

settlement   Track 2, CVC/CVV2/CID PIN/Encrypted PIN block

15

Reader Architecture – Payment Transaction Integrity

Transaction communication and storage –  Transaction records must meet PCI-DSS standards

– Vital Data should be encrypted – Communication MAC’d for integrity

 Records should be acknowledged by the back office prior to deletion.

 Records need to be maintained / stored

16

System Features

Key Architecture – What Cryptography?

Back Office Functionality – Reader / SAM

Management – Transaction Decryption – Authentication

Reader Functionality – Transaction Encryption

SAM Selection

17

PCI-DSS

Key Architecture

Back Office Functionality

Reader Functionality

Transaction Model

Contactless transaction rules won’t work for urban transport fare collection

General Contactless Payment rules

Challenges implicit in transport PAYG

Price is known before the card is presented

Price not known until rail journey is completed (or end-of-day if capped)

Use of card counters to manage risk & occasionally fall-forward to Chip & PIN

•  Throughput needs set maximum acceptable transaction time of 500ms

•  No PIN pads on transit infrastructure

Terminal field is activated manually by store staff

Neither staff nor time to manually activate terminal field for each customer

UK banks have developed a new transport transaction model

General Contactless Payment rules

Agreed new rules for transport PAYG

Price is known before the card is presented

Each tap is £0, then operator back-office calculates price at end of day

Use of card counters to manage risk & occasionally fall-forward to Chip & PIN

Operator manages risks to provide equivalent protection within the 500ms time limit: •  Offline data authentication of card •  Deny Lists (DLs) in terminals •  Online auths from the back-office

Terminal field is activated manually by store staff

Terminal field is always active to maximise throughput

Back Office

Back office

• Aggregation • Pricing • List mgmt • Tokenisation • Authorisation and settlement • Travel Plan • Employer Programs • Free travel? • Communications • < Show as Diagram>

Opportunities exist to provide a back office service to other operators

23

Data gathering

Head Office

TfL

Merchant Acquirer

Taps Deny Lists

Fare Tables

MI

Customer Query

Settlement Funds Transfer Auth Req Auth Resp

Funds Transfer less %

Testing and Verification

What is Verification For?

For Establishing Compliance (typically to Industry or International Standards)

•  Certification Testing •  Compliance Testing •  Type Approval Testing For Establishing Readiness for Service (typically Pilot or soft

launch) •  Confidence Testing •  Interoperability Testing, Combination Testing •  Performance Testing •  Characterisation Testing ,Power Drop Testing For Establishing Fitness for Purpose (typically based on Customer

Specifications / Contracts) •  Acceptance Testing

25

Critical Success Factors

Comprehensiveness •  Coverage of all possible conditions, •  Subjected to limitations on budget and

time •  Chosen by areas of least business risk Traceability •  Trace down from Specification to test

cases to demonstrate comprehensiveness •  Trace up from test run via test specification

to original specification statement Transparency •  Open linear test scripts to eliminate

uncertainties in test implementation Automation •  Repeatability, Efficiency, Reliability

26

Prototyping

There are many reasons to prototype new products and devices

•  Proves concepts cheaply •  Demonstrate technical design and user interaction •  Better prediction of time delivery schedules •  Bring specifications to life - making them tangible •  Establish functional requirements •  Builds confidence before going to market •  Identify constraints or issues and propose solutions •  Manage technical risk

28

The Consult Hyperion Prototype Transit Reader addressed several issues

 Card activation algorithm defined and tested

  Impact of configurable activation options examined

Payment reader / card performance  Full scheme Transactions

measured   Impact of longer RSA keys

measured

29

Revenue Inspection Device

The problems in accepting payment cards!

Revenue Inspection:"  Need to know where a contactless payment card has been used."  No ability to store data on current EMV cards."  Operators need to develop, perhaps costly, methods to carry out Revenue Inspection

on current specification contactless bank cards."  Regulation issues in implementing revenue inspection without on card record"

  Risk of chargebacks"  Unable to charge a penalty – only the maximum fare (TfL)"

White/Black List Management:"  If a fare is unpaid or a payment card is denied access:"

  Cardholder is in debt to the operator."  Cardholder has asked to block their card (mislaid, left at retailer, etc). "

  Operators need a way to mark the card as being reactivated in real time: "  When a customer has repaid their debt."

Fare Management:"  For offline capable systems managing a value balances."  Traditional fare calculation at the gateline."  Customer service requires back office access."

31 Client Confidential AXP Internal!Feb-26-13 Ver 1.0!

What is a TDA?!

  The term TDA is a transit industry defined name."

  The data storage area is available to all types of merchants."

  ISO standards body defining ʻTDAʼ transit functionality ISO TR14806."

Client Confidential AXP Internal!32 Feb-26-13 Ver 1.0!

“Integrated data storage area on a payment card

for merchant use”!

How could a TDA be used in Transit?!

  Storing a transport application and a transport product:"  Likely to be just the transport product."  The UK ITSO Scheme tickets have at least two parts (Fixed and Variable)."

  Storing a transport entitlement: "  Discount card, staff pass etc / personalisation."  Transport operator has a deal with an issuer."

  Storing a log of recent taps:!  To help with fare calculation."  Cardholder information."

  Storing a recent retail transaction: !  To gain immediate access for deny-listed people."

  Storing details of a revenue protection check:!  Prevent multiple inspection penalties."

33 Client Confidential AXP Internal!Feb-26-13 Ver 1.0!

Summary

Key points in implementing EMV in Transit

•  Develop a strong relationship with the card schemes •  Develop a Transaction Model that both sides can work with •  Understand all the Risk Liabilities •  Design for multiple technologies •  Ensure an E2E security approach and be clear where PCI

requirements apply and where they do not •  Test thoroughly

 Smart Card Alliance  191 Clarksville Rd. · Princeton Junction, NJ 08550 · (800) 556-6828  www.smartcardalliance.org

For more information please contact Mike Burden

Commercial Manager +44 1483 301 793

+447976 951 161 mike.burden@chyp.com

www.chyp.com