EMV mobile Point of Sale (mpos) Initial Considerations

Transcription

1 EMV mobile Point of Sale EMV mobile Point of Sale (mpos) Initial Considerations Version 1.1 June EMVCo, LLC ( EMVCo ). All rights reserved. Any and all uses of the EMV Specifications ( Materials ) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at

2 Contents 1 Executive Summary 1 2 Purpose and Scope Purpose Scope Audience 2 3 General Architecture of an mpos Solution Architectural Components Functional Elements Attachment Mobile Server Functional Components Card Reader (L1) (L2) PIN Entry Device (PED) Signature pad User Interface (UI) 4 4 Example mpos Solution Architectures Standalone Attachment Reader Attachment, on Server Reader Attachment, Multiple s Reader Attachment, PED on Mobile Integrated Reader Fully Integrated Mobile 7 5 PCI SSC Considerations 8 6 Conclusions and Next Steps 8 June EMVCo, LLC ( EMVCo ). All rights reserved. Page ii

3 Figures Figure 1 General mpos Solution Architecture 3 Figure 2 Standalone Attachment 5 Figure 3 Reader Attachment, on Server 5 Figure 4 Reader Attachment, Split 6 Figure 5 Reader Attachment, PED on Mobile 6 Figure 6 Integrated Reader 7 Figure 7 Fully Integrated Mobile 7 June EMVCo, LLC ( EMVCo ). All rights reserved. Page iii

4 References 1. EMVCo: A Guide to EMV 2. PCI Security Standards: Accepting Mobile Payments with a Smartphone or Tablet 3. PCI Mobile Payment Acceptance Security Guidelines for Developers, version 1.0, September PCI Mobile Payment Acceptance Security Guidelines for Merchants as End- Users, version 1.0, February PCI DSS Applicability in an EMV Environment A Guidance Document, Version 1.0, October 2010 June EMVCo, LLC ( EMVCo ). All rights reserved. Page iv

5 Terminology mpos CMP L1 L2 PIN CVM PCI PED TEE PTS PDA DSS PA NFC SE Mobile Point of Sale Contactless Mobile Payment Level 1 (in respect of Terminals) Level 2 (in respect of Terminals) Personal Identification Number Cardholder Verification Method Payment Card Industry PIN Entry Device Trusted Execution Environment Payment Terminal Security Personal Digital Assistant Data Security Standard Payment Application Near Field Communication Secure Element June EMVCo, LLC ( EMVCo ). All rights reserved. Page v

6

7 1 Executive Summary There is increasing market interest in enabling consumer grade mobile devices as merchant acceptance devices. This document provides an overview and framework for the work that EMVCo is undertaking in the area of mobile Point Of Sale (mpos). It attempts to document the various architectural configurations by which such systems might be implemented. An mpos solution typically comprises: A mobile device consumer grade mobile phone or tablet device with wireless connectivity Card Reading functionality Applications supporting the payment functionality, the EMV kernel and user interface Server-side software There are many permutations for configuring mpos solutions. The mpos solution architectures documented in this paper will serve as a basis for examination of the impact on EMV specifications. The functionality and security considerations of these solutions are currently split between the organisations of EMVCo and PCI. 1 EMVCo, owned by American Express, Discover, JCB, MasterCard, UnionPay and Visa, manages, maintains and enhances the EMV 1 Integrated Circuit Card Specifications to ensure global interoperability of chip-based payment cards with acceptance devices including point of sale terminals and ATMs. EMVCo also administers a testing and approval process, and oversees the procedures for confirming compliance with the EMV standards. These activities include compliance testing for chip-based payment accepting devices. The testing process and procedures help ensure cross-payment system interoperability, which is the over-arching goal of the EMV Specifications and EMVCo. The PCI Security Standards Council is responsible for the security requirements of acceptance devices, and has published three documents providing guidelines for the implementation of mpos systems. These documents do not provide a basis for PCI PTS approval of mpos systems based on general-purpose mobile devices (category 3 devices in the PCI SSC definitions). Note however that such mpos systems, or components within the systems, may qualify for PCI DSS or PA DSS validation. The PCI Security Standards Council currently provides for approval of mpos systems only evaluated against PCI PTS and applications for these and purpose-built devices but not general-purpose mobile devices, EMVCo will liaise with the PCI Security Standards Council on this topic, to better understand if and when there may be general payment industry approval of such systems, and the need for a mobile profile. 1 Note that payment systems may also have their own additional requirements. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 1

8 2 Purpose and Scope 2.1 Purpose This document identifies a number of potential architectures for mpos solutions used for acceptance of EMV based transactions. The document: Serves as basis for analysing possible EMV specification changes that might facilitate innovative mpos solutions; Assists in identifying if and when EMVCo should consider developing additional specifications or other documents to facilitate such innovations; and, Assists in identifying where EMVCo should be liaising with other parties such as the PCI Security Standards Council to support development in the mpos space. 2.2 Scope This document considers merchant acceptance of card present EMV based contact or contactless transactions. Other types of mpos solutions that do not support full EMV processing, such as magnetic stripe, manually entered transactions and others, are not in scope. EMVCo does not currently engage in any activity to define the security requirements for mpos solutions. Security remains the responsibility of the PCI Security Standards Council. 2.3 Audience This document is intended to provide information about EMVCo s work on mpos solutions to EMVCo associates, subscribers and other interested stakeholders. It is assumed the audience has an understanding of EMV and the associated terminology, if not please refer to [1] A Guide to EMV. 3 General Architecture of an mpos Solution 3.1 Architectural Components The general architecture of an mpos solution is shown in Figure 1 General mpos Solution Architecture. The functional elements are identified in section 3.2 and the functional components that are distributed across these in 3.3. Not all implementations of an mpos solution will include all of the functional elements or all functional components. A component may be repeated, for example separate contact and contactless card readers, or be distributed across multiple elements, for example the kernel. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 2

9 mpos Attachment Mobile Server User Reader UI Acquirer Signature Pad PED Figure 1 General mpos Solution Architecture 3.2 Functional Elements Attachment The attachment is a hardware component that supports some or all of the functional components (see 3.3 below). The attachment connects to a mobile device via either a data / audio port or local area wireless connection (i.e. Bluetooth) and may provide encryption services. Certain mpos architectures may not require an attachment and will be discussed later Mobile A mobile device is defined as a consumer grade mobile phone or tablet device with wireless connectivity Server The server is a remote component that may support some of the kernel, decryption services, merchant services (such as receipt management, transaction history etc.) and message translation to the acquirer host / gateway services. 3.3 Functional Components The following functional components are considered to be part of an mpos solution and can be distributed across the different functional elements Card Reader (L1) The card reader implements the EMV Level 1 (L1) functionality. A card reader may implement contact chip reading, contactless chip reading, or both. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 3

10 The card reader may be located in an attachment or as an integrated part of the mobile device. At present the majority of card readers are implemented as attachments. However, contactless card acceptance could potentially be implemented using the NFC antenna of the mobile device. Note that an implementation may contain multiple card readers, for example, an integrated contactless card reader, and an attachment implementing a contact card reader (L2) The software that performs the EMV processing is referred to as the kernel. For the purpose of this analysis, no distinction is made between the individual payment systems contactless kernels and the equivalent contact EMV Level 2 (L2) functionality PIN Entry Device (PED) The PED allows for secure entry of the cardholders PIN and is required to meet the PCI-SSC requirements for PIN entry devices (PCI-PTS) Signature pad Mobile devices with touch screens may be used to electronically capture a cardholder signature User Interface (UI) The UI is a critical component of the EMV transaction and includes the entry and display of transaction amount information as well as terminal instructions for use by the merchant or the cardholder. 4 Example mpos Solution Architectures In this section, a number of examples of mpos solution architectures are considered in more detail. The list is not exhaustive, but examples are chosen to identify the key considerations for EMVCo. These examples do not imply any proposed or preferred implementations. As has been noted, implementations may include separate contact and contactless card readers. For simplicity in this document, and to keep the number of combinations down, these architectures are not explicitly addressed. The example architectures highlight the suitability for contact and contactless transactions, and an implementation employing multiple card readers may have an architecture which is a combination of the example architectures. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 4

11 4.1 Standalone Attachment The standalone attachment has most of the functional components in the attachment. The mobile device supports the merchant UI, signature pad and communications to the server (or directly to the acquirer). Attachment Mobile Server Reader PED UI UI Signature Pad Figure 2 Standalone Attachment This architecture could support all Cardholder Verification Methods (including online PIN, offline PIN and signature). The attachment would be required to achieve EMVCo L1 and L2 approval and comply with appropriate PCI Security Standards (PCI-PTS, PCI-DSS). 4.2 Reader Attachment, on Server In this architecture, an attachment implementing a reader is connected to the mobile device. UI capabilities and signature capture are performed on the mobile device. The kernel is located in the server, with the mobile device communicating between the reader and the kernel. In this example, there are no PIN entry capabilities. Attachment Mobile Server Reader UI Signature Pad Figure 3 Reader Attachment, on Server This architecture does not support all Cardholder Verification Methods (no online or offline PIN). The standalone attachment and server would be required to achieve EMVCo L1 and L2 approval and comply with appropriate PCI Security Standards (PCI-DSS). PCI-PTS encompasses a number of different elements and may also apply. SRED or P2PE could be applicable even if the PIN aspect is not required. Due to performance requirements for contactless transactions, it may not be feasible to implement the entire kernel in the server, due to communication latency between the kernel and the reader. It may be necessary to distribute the kernel as described in sections 4.3 and 4.4. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 5

12 4.3 Reader Attachment, Multiple s This architecture is similar to that in section 4.2 Reader Attachment, on Server, however for performance reasons there are multiple kernels, on the server and the attachment. The kernel on the attachment implements operations which are time sensitive to meet the performance requirements of contactless transactions. Attachment Mobile Server Reader UI Signature Pad Figure 4 Reader Attachment, Multiple s This architecture as depicted does not support all Cardholder Verification Methods (no online or offline PIN), however, a PED may also be included in the attachment. The attachment is required to achieve EMVCo L1 approval. The combination of the attachment and the server would be required to achieve EMVCo L2 approval and comply with appropriate PCI Security Standards (PCI-DSS & PCI-PTS if a PED is included). PCI-PTS encompasses a number of different elements and may also apply. SRED or P2PE could be applicable even if the PIN aspect is not required. 4.4 Reader Attachment, PED on Mobile The kernel is contained on the attachment and the PED is on the mobile device. Attachment Mobile Server UI Reader PED Signature Pad Figure 5 Reader Attachment, PED on Mobile This architecture is intended to support all Cardholder Verification Methods (including online PIN, offline PIN and signature). The attachment would be required to achieve EMVCo L1 and L2 approval and comply with appropriate PCI Security Standards (PCI-DSS). The mobile would be required to comply with PCI Security Standards (PCI-PTS). June EMVCo, LLC ( EMVCo ). All rights reserved. Page 6

13 4.5 Integrated Reader In this architecture, the reader is integrated into the mobile device. The kernel is split between the mobile device and the server. Mobile Signature Pad Reader UI Server Figure 6 Integrated Reader This architecture is most likely to be applicable to contactless transactions, and for the performance reasons discussed earlier the kernel is split between the server and the mobile device. This architecture does not support all Cardholder Verification Methods (no online or offline PIN). The mobile device is required to achieve EMVCo L1 approval and the combination of the mobile device and the server would be required to achieve EMVCo L2 approval and comply with appropriate PCI Security Standards (PCI-DSS). PCI-PTS encompasses a number of different elements and may also apply. SRED or P2PE could be applicable even if the PIN aspect is not required. 4.6 Fully Integrated Mobile In the fully integrated mobile architecture, all functional components are contained in the mobile device. Mobile UI Server Reader Signature Pad PED Figure 7 Fully Integrated Mobile This architecture is most likely to be applicable to contactless transactions. This architecture is intended to support all Cardholder Verification Methods (including online PIN, offline PIN and signature). The mobile device is required to achieve EMVCo L1 approval and the mobile is also required to achieve EMVCo L2 approval and comply with appropriate PCI Security Standards (PCI-DSS, PCI-PTS). June EMVCo, LLC ( EMVCo ). All rights reserved. Page 7

14 5 PCI SSC Considerations The PCI Security Standards Council has defined 3 categories of mobile device applications used as acceptance for payment card data: Category 1: The payment application operates only on a PTS-approved mobile device. Category 2: The payment application is only provided as a complete solution bundled with a specific mobile device. The underlying mobile device is purposebuilt (by design or constraint) with a single function of performing payment acceptance. The payment application, when installed on the bundled mobile device provides an environment which allows the merchant to meet and maintain PCI DSS compliance. Category 3: The payment application operates on any consumer electronic handheld device (e.g. smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing. The considerations in this paper are primarily addressing category 3, and may also be applicable to category 2 where a general purpose mobile device is constrained to be used for payment acceptance only. The PCI Security Standards Council has published several documents relating to the use of Category 3 applications and the supporting environment of general-purpose devices; an information paper, Accepting Mobile Payments with a Smartphone or Tablet [2], two guidelines: PCI Mobile Payment Acceptance Security Guidelines for Developers [3] and PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users [4] and a guidance document PCI DSS Applicability in an EMV Environment [5]. These papers provide guidance, but category 3 mobile applications are not, by themselves, currently eligible for listing for PA-DSS approval. 6 Conclusions and Next Steps The market for mpos solutions is fast evolving. Current solutions are focused on reader attachments (see examples 4.1 and 4.2) as such architectures are able to meet existing EMVCo Level 1 and Level 2 requirements. In order to better understand and identify the impact of potential mpos solution architectures, EMVCo has formed the mpos Task Force to research the topic, solicit industry input and make appropriate recommendations for EMVCo work efforts. The Task Force will work with the relevant EMVCo working groups as necessary. EMVCo will also liaise with the PCI Security Standards Council on the topic of the acceptance security of mpos solutions. We are interested in your views on new solution constructs and where EMVCo can add value. To that end, if you would like to contribute, we recommend you complete our survey in order to inform the mpos Task Force of specifications, processes, or other areas that you believe require review. June EMVCo, LLC ( EMVCo ). All rights reserved. Page 8