How Would You Like to Pay Card Phone

How Would You Like to Pay: Card, Phone or Cloud? An introduction to Secure Element in the Cloud Jan Dart, Advisory Director, Bell ID // 5 th February 2014

Agenda • • Evolving TSMs The emergence of another way - cloud What are the principles of cloud How might it be implemented now and in the future (many options) • Summary - What are advantages and disadvantages of cloud • Questions

Evolving TSMs

Service Provider & Root TSMs Application Service Providers Mobile Network Operators Secure Element owners Bank A MNO A Bank B Bank C MNO B Public Transport A MNO C MNO D Public Transport C Service Provider TSM Loyalty XYZ Root (Secure Element) TSM Device Manufacturer A Loyalty ABC Loyalty C Device Manufacturer B

Example: Bell ID Experience in Canada Root MNO Collaborative Root with OTA SP TSM SP SP SP Issuer TSM Initial Wallet

A Payment Evolution From Stripe to Cloud

Moving The Chip To The Phone

Using The Same Infrastructure For standard NFC No acquiring infrastructure changes But agreement with Mobile Network Operators is required

Cards & ‘’Standard’’ NFC Provisioning Cards Host System Data. Prep System Perso Machines ‘Standard’ NFC 01001101001100011 Real-time Host System 01001101001100011 Real-time Data. Prep System OTA TSM with OTA

Not a replacement, more an alternative… …maybe disruptive Secure Element In The Cloud

Secure Element In The Cloud What is it? “The Secure Element in the cloud is a concept of storing private data, such as payment card details, in a ‘remote secure element’ in the cloud. When a consumer makes a purchase, the data from the remote secure element is used and passes through the phone to the POS terminal, where the data is presented in the same format as that used in standard card emulation mode transactions. ”

The Next Step In The Evolutionary Process… • Move the ‘’chip’’ to the cloud. • Transact remotely Secure Element in the Cloud

The Next Step In The Evolutionary Process… Secure Element in the Cloud Issuer SE Data • Communication happens via cloud. • In reality SE data sits in bank’s secure data centre

Cards & NFC - Provisioning Secure Element In The Cloud … Cloud based NFC SE in the Cloud with OTA 0100110100 Real-time Host System 0100110100 Real-time Data. Prep System SELECT Host System Merchant POS 0100110100

The User Experience

SEit. C – The user experience – In preparation • Start wallet application • Wallet consults Cloud Secure Element for selected card. • Select the “Make • Transaction data is prepared payment” option • Available cards are displayed on screen for selection (swipe to select). • Payment started by selecting “Pay now” button

Payment In Progress. . . • Negotiation between phone and Cloud based Secure element • Indicator shows communication in progress to user • Transaction between phone POS • Indicator shows communication in progress to user POS SE in the Cloud

Behind The Scenes… SE In The Cloud Work Flow

SE in the Cloud using Host Card Emulation 1. 3 5 re Ch anne Phone OS PAY APP 4 2 3. Secu 1 Host Card Emulation 2. l TCP SE in the Cloud GPRS/ GSM NFC Controller 4. 5. App on phone initiates connection to SE in the Cloud via (mobile) internet. A secure channel is setup between SE in the Cloud and App On Phone. SE in the Cloud generates transaction cryptogram and passes to App On Phone App on phone uses Host Card Emulation to connect to NFC Controller sends transaction cryptogram to Point Of Sale system

The Transaction Flow

“Pure” SE in the Cloud Payment Transaction (Option 1) (7) validates Authorization request (4) SE cloud generates Authorization Token based on Card Key and POS input parameters SE in the Cloud Mobile Internet (Dataplan) (2) SE cloud identifies Consumer and activates Card as “Preferred” (3) Consumer taps Phone against POS starts transaction by requesting Authorization request to SE Cloud Issuing Bank Host (6) POS sends Authorization Request to Bank Host through Acquirer and Payment Network (8) POS receives Authorization from Bank Host indicating Success Or Failure Payment Network Acceptance (1) Consumer launches Wallet, selects card in Cloud and activates Host Card Emulation (5) Wallet receives Authorization data and forwards it to POS Merchant Acquirer

Typical objections • Cloud SE availability (Tokenization is the solution) • Cloud SE latency (‘tap time’ +1. 5 secs, solution - Tokenization) • Security (multiple solutions): – Handset protection, TEE, unlock PIN, Dynamic Pan, Hybrid solution with physical SE. • Trusted Execution Environment (TEE) provides additional handset security. • NFC chipsets must support ‘Host Card Emulation’ – Android Devices with NFC (see Android 4. 4 news) – RIM Black. Berry with NFC • All OS 7 and OS 10 devices – Nokia/Microsoft with NFC • Expected 2014

SE Tokenization

Solution = SE in the Cloud & Tokenization SE in the Cloud Mobile Internet (Dataplan) Acceptance (1) Consumer launches Wallet, selects card in Cloud and requests payment tokens (Online before going to the store) OR Tokens sent to phone without Consumer interaction (4) Wallet receives Authorization request Token. The latter is stored on Device temporarily and no further connection is needed • (2) SE cloud identifies Consumer and activates Card as “Preferred” • (3) SE cloud generates Authorization Request Token based on Card Key and predefined POS data input (5) Consumer selects Card. (6) Token readied for use. Transaction Manager (7) Consumer taps Phone against POS starts transaction and a Token stored on the device is used to provide required card data. Merchant POS (9) Bank Host recognises Token TX, routes request to Transaction Manager which verifies that it’s under limit, not expired & validates token. Cryptogram also validated. Issuing Bank Host Payment Network (8) POS sends Authorization Request to Bank Host through Acquirer and Payment Network (10) POS receives Authorization from Bank Host indicating Success Or Failure Merchant Acquirer

SE in the Cloud with Tokenisation (Option 2) • Cloud SE availability Tokenization is the solution • Cloud SE latency (up-to 4 sec) • Security (multiple solutions): – Handset protection, TEE, unlock PIN, Dynamic Pan • Quick: ~200 ms for the m. Device/Reader interaction • Hardware security Level possible through TEE • NFC chipsets must support ‘Host Card Emulation’ – with NFC • – with NFC • – From Android 4. 4 All OS 7 and OS 10 devices with NFC • Early 2014

Hybrid Model – using the Secure Element

SE in the Cloud with Tokenization (Option 3) Uses physical SE in Device combined with cloud based SE SE Cloud Server Service Provider (SP) TSM Tokens (n times) Mobile Internet (Dataplan) Root (Secure Element) TSM Once Only NFC Reader

SE in the Cloud with Tokenization Considerations • • Cloud SE availability Tokenization is the solution Cloud SE latency (up-to 4 sec) Interaction with MNO for accessing physical SE => TSMs. Any NFC device; No ‘Host Card Emulation’ necessary – Assuming that SE has interface with NFC controller (SWP) • Physical SE used for: – Authentication – Cardlet installation to manage pre-authorized tokens used during transactions • Root TSM only required for initial cardlet installation – No need for further SSDs to be created • Advantage: No capacity issues on Physical SE • Quick: ~200 ms for the m. Device/Reader interaction

SE in the Cloud Comparison of different options MODE / FEATURE 1. Pure Cloud 2. m. Device with Tokenization 3. SE with Tokenization TSM NECESSARY SE NECESSARY HCE NECESSARY COST REDUCTION Offline Transaction NFC DEVICE (O. S COMPLIANCY) Transaction Time Multiple tokens • ANDROID +4. 3 • BBRY OS 7 & OS 10 • Windows Mobile 1. 4 sec • ANDROID +4. 3 • BBRY OS 7 & OS 10 • Windows Mobile ~200 ms • Any NFC device ~200 ms

Conclusion

SE in the Cloud: Reality check – how real? • First customer production rollout for Canadian bank is live • Many other initiatives have started • Payment schemes : Advanced ongoing discussion • On-going Projects and Trials building Bell ID experience – Using legacy USIM or embedded SE for strong authentication • • • Any NFC ‘phone. No Software Card Emulation or TEE required. No memory restrictions, apps updated in the cloud Implemented Hybrid solution with data stored and exercised from a "token manager Applet" loaded into the SE. – Looking at TEE deployments – Legacy SIM via HCE

Solution summary • “Card” Issuer retains customer ownership • Many MNO or network options (None to cooperative) • Any NFC device with Software Card Emulation –. . or without SCE for Hybrid SIM or embedded solution • Reduced integration effort – possible to not need a TSM • Payment Data remains with SP - easy management, etc. • Carrier has a role in SIM for secure storage of data in hybrid solution – Hybrid uses SE for token storage – Possible Small SIM presence, with large data & multi apps stored in the cloud • Handset provider can provide solution using embedded SE hybrid

Bell ID experience - SE Cloud Root MNO Collaborative Root with OTA SP TSM SE in the cloud SP SP Issuer TSM Initial Wallet

Want to know more? Questions? Contact: j. dart@bellid. com or p. chepalich@bellid. com Bell ID // Stationsplein 45 A 6. 002 // 3013 AK Rotterdam P. O. Box 29141 // 3001 GC Rotterdam // The Netherlands // www. bellid. com

SE in the Cloud Value Chain Impact Token Issuing Token Validation SE in the Cloud Server Service Management POSSIBLE INTEGRATION Issuer Host NO ACQUIRER IMPACT Visa. Net Mastercard Net Amex, Others m. WALLET INTEGRATION (possibly + Cardlet) NFC Reader Acquirer