Creating a trust infrastructure to support mobile payments

Transcription

1 Thales e-security Creating a trust infrastructure to support mobile payments Hardening cryptographic security for HCE, SE, P2P and more White Paper October 2014

2 Contents Scope and target audience Mobile changes everything Apple breathes fresh air into mobile payments Different options, different risks for issuers Mobile payments using secure elements (SEs) Mobile payments using host card emulation (HCE) Mobile person-to-person payments (P2P) Thales HSMs used in the mobile ecosystem...20 nshield Connect payshield Conclusions Glossary...25 Further information...26 page Thales e-security, Inc. All rights reserved.

3 Scope and target audience One data breach could end it all if the underlying security architecture is not sufficiently robust. For many people in the payments industry, the mobile device is seen as a viable alternative to the plastic payment card. Much of the early activity in mobile payments has involved mobile network operators (MNOs) eager to profit from their new role in preparing devices to make payments and start-up companies, the disruptors, who are often trying to deliver extra value for both merchants and consumers by redefining the commerce experience. There is much proprietary activity resulting in local rather than global interoperability with many solutions bypassing the established payment networks. The race to find a compelling consumer proposition and a focus on convenience over security means that there is always the possibility that one data breach could end it all if the underlying security architecture is not sufficiently robust. Perhaps this is one of the reasons why merchants are confused by the bewildering array of options on the table. They are the ones impacted the most in the payments chain and the ones expected to make the biggest investments but are unsure where to place their money. Something that they can trust which will be accessible to most of their customers (just like the benefits of card acceptance today) is more likely to get them to act. A set of innovative mobile offerings promoted by the banks and leveraging their security expertise could address this inertia. The banks and the card schemes are now in a good position to offer standards-based mobile payments to the merchant community. Visa and MasterCard have ramped up their mobile activity especially in helping to establish a set of mobile payment tools that are secure, scalable, globally interoperable and leverage as much as possible of the existing payment rails and security infrastructure. They have developed numerous sets of specifications, security best practices and contributed to certification schemes needed to validate solutions prior to deployment. Apple has introduced Apple Pay, a secure hybrid solution for mobile payments which leverages the existing acceptance infrastructure making use of standard contactless point-of-sale (POS) terminals; the door is open for all issuers, acquirers, merchant and card schemes to participate. Industry surveys regularly indicate that consumers are wary about trusting their mobile device to make payments because of security fears. The reality that the card schemes, many leading banks and now Apple are standing behind the more sophisticated mobile payment methods provides additional confidence and should help drive adoption amongst consumers. The fact that Apple chose to cooperate rather than compete with the payment incumbents delivers a massive boost to the industry and takes away many of the security and technology uncertainties that have hampered progress for years. page 2

4 The primary goal of this white paper is to provide practical assistance to banks so that they can best leverage and extend their existing trust infrastructure in order to launch a new range of secure mobile-based payment solutions for their customers. Based on experience with solutions that are live today, the paper describes options to use a mobile phone to support contactless payments at POS (both with and without a Secure Element) and the growing trend for person-to-person payments initiated by a mobile app. Thales e-security is very active in this market, working with leading payment solution vendors to integrate hardware-based key management and encryption technologies. This enables banks to get to market quickly with a proven security solution for integration with their existing trusted issuance and transaction processing infrastructures. The advantage to a bank of being able to offer their own branded mobile solutions to their existing cardholders for retail /personal payments reinforces their experience and knowledge of how to launch secure solutions with the critical security challenges being solved by Thales technology. Thales e-security is very active in this market, working with leading payment solution vendors to integrate hardware-based key management and encryption technologies. page Thales e-security, Inc. All rights reserved.

5 Mobile changes everything The mobile device creates a tremendous opportunity for the payments industry (and banks in particular) to deliver significant innovation in customer engagement expanding customer relationships, building loyalty and driving top of wallet status. Mobility is the new benchmark in the world of payments enabling consumers to make payments when they want, where they want and how they want, together with a richer experience. All of this is facilitated by a mobile device, typically a smartphone or tablet, through a variety of convenient methods that bypass the limitations of plastic payment cards. Mobile is an active environment enabling banks to conduct real-time two-way communication with their customers, benefitting from location information, dynamic feedback, rich user interface, instant over-the-air updates and the increasing use of integrated biometric authentication. Mobile is undoubtedly the future in our ever-increasing complex world of payments and commerce. The long standing relationship between banks and card schemes is challenged by disruption. Disruption in payments is generally accepted as meaning moving away from the traditional four party card-based model (involving the merchant, acquirer, card scheme and issuer) and its associated fee structure towards solutions where established rules get broken, new business models and partnerships emerge and different methods of initiating, processing and settling transactions are introduced. The long standing relationship between banks and card schemes is challenged by disruption as opportunities arise for both parties to form alliances with new players at the potential expense of the other. The early days of mobile were dominated by innovative start-ups trying to convince merchants and consumers to adopt their new way of purchasing goods or services. The focus was on convenience for the consumer and the promise of lower cost to the merchant but security was not at the forefront. Often the solutions were for local use only in individual stores or branded chains rather than the global interoperability and acceptance consumers expect from their bank cards. Many solutions used a password to activate the mobile app so that it could read a QR code displayed on the payment terminal merchants needed to invest in hardware and/or software upgrades to support the new mobile payment method in addition to continuing to support the legacy card processing infrastructure. There were no standards, no security certifications, no obvious bank involvement/branding and no consistent global deployment approach. Merchant confusion over which solution to adopt had the effect of opening the door for the established card schemes to formulate a range of secure mobile solutions that maximize the use of the existing merchant infrastructure, avoiding disruption and maintaining trust. page 4

6 There has been significant activity driven by the card schemes in developing different types of approaches, all with varying levels of security and risk management, to offer an alternative to cards for paying at the physical POS. Numerous trials and pilots have taken place using secure chips inside the phones (under a variety of business models) but it has been very hit or miss regarding the reaching of critical mass. Unlike the disruptive systems the card schemes have focused on making as few changes as possible to the consumer experience, leveraging the tap or wave gesture with contactless cards to provide a similar experience with a mobile device. At this relatively early stage of the market it is unclear which solutions will prevail in the long term. It is important that the banks cover all bases to avoid the potential costly mistake of depending on just one type of solution being dominant. Apple Pay, announced in September 2014, would appear to have a good chance of success, albeit only available to iphone users as currently designed and therefore not able to cover the complete bank cardholder base. The solutions that are explained in this white paper are particularly suitable for banks because they enable much of the trust infrastructure and risk management techniques from their established card systems to be integrated with the new mobile solution components. Banks fundamentally know how to make payment systems secure and have strong risk management approaches to compensate for any potential vulnerabilities of the mobile device. Apple breathes fresh air into mobile payments In the future when we look back at the announcement in September 2014 from Apple regarding their new payment solution, Apple Pay, we may consider that to be a defining moment in the payments industry. Until that point the mobile payments landscape had been very fragmented and locked into a battle of the business model for years. There was considerable uncertainty over technologies, securities and standards making it difficult for all participants (particularly banks and merchants) to know where to invest. Perhaps the most disturbing part of all was the abundance of commentary and debate on how mobile payments could be implemented but very little real insight into why we really needed mobile payments for in-store payments paying by card was not broken after all. All of this contributed to a mobile payments industry that was stuck in neutral. page Thales e-security, Inc. All rights reserved.

7 Apple then changed everything it reminded everyone of the need to serve the customer rather than being caught up in a conversation of self-interest where the how dominates. The mobile payments industry is not really about mobile payments at all, it is about mobile selling. Everyone can always find a way to pay when they want to buy. What is much more challenging is getting someone to want to buy in the first place and that is an area where Apple excels. Before it declared its hand, many in the industry expected Apple to be a disruptor and go its own way renouncing NFC, trashing secure elements and competing head-to-head with the card schemes. Instead Apple did the exact opposite it embraced the standards, utilized the best parts of technology (including NFC, integrated mobile wallet, biometric authentication, secure credential storage, EMV cryptograms and tokenization) creating a hybrid approach, and built an ecosystem that enables the issuers, acquirers and card schemes to do what they do best process and authorize transactions on proven payment rails. Apple chose potential competitors as allies in a move that has high hopes of driving adoption of mobile payments by providing consumers with a simplified payment experience and confidence that it is secure and can be trusted. Apple Pay started its rollout in October 2014 in the United States where merchants and issuers are assessing their strategies regarding the October 2015 EMV liability shift. The biggest potential fraud liability threat is to merchants who do not introduce EMV capable terminals. Nowadays the NFC/contactless feature comes as standard with most hardware it just needs to be enabled to accept payments. Apple Pay and its inherent use of an EMV contactless compliant processing infrastructure may be the incentive needed for merchants to upgrade their terminals and support contact and contactless chip transactions as well as the mobile payment options. As more and more customers migrate to the latest iphone required for Apple Pay and Apple signs up more card schemes, acquirers, processors and merchants, the mobile payments revolution at POS should gather momentum. This in turn will likely stimulate further use cases and implementation models for tokenization (a key part of the Apple Pay security architecture which replaces the PAN with a token to protect merchants in data breach attacks) and cause Apple Pay to roll out to countries outside the United States. Ironically one side effect of Apple s move is that it will cause issuers to think about how they will support their customers who do not own iphones. The preferred option to address this specific need is host card emulation (HCE) which is available now for the Android and Blackberry platforms which cover the majority of the remaining smartphone installed base globally outside of Apple. Banks therefore as a result of Apple s entry into NFC-based mobile payments need to cover all bases. The next section in the white paper explains how they can achieve this objective. Apple chose potential competitors as allies in a move that has high hopes of driving adoption of mobile payments by providing consumers with a simplified payment experience and confidence that it is secure and can be trusted. page 6

8 Different options, different risks for issuers There are three major mobile payments approaches that are ideally suited to the banks which have one thing in common they all rely on a major component which is not under the direct control of the bank. Fortunately the back end infrastructure controlled by the bank to support the different approaches has a proven trust model which minimizes the risk of fraudulent transactions while protecting all critical keys and payment credentials. Two of the approaches covered in this paper are in the retail payments world Secure Element (SE) representing a real card and host card emulation (HCE) representing a virtual card inside the mobile phone. The other approach is in the real-time payments space mobile person-to-person (P2P) payments allows a person to send money to another person using a banking mobile app with the recipient mobile phone number being their payment reference rather than the account information. Traditional payments made using cards are synonymous with certified hardware POS terminals, PIN pads, EMV chip cards and hardware security modules (HSMs). Everything needs to be designed to meet strict security certification and audit standards, normally directly or indirectly controlled by the card schemes. This in turn involves significant formal testing and approval before deployment. Mobile payments are very different everything revolves around the mobile device which is a standard consumer product with no inherent security certification. As a consequence it means the potential solutions involving mobile devices have various options available at implementation level work around the security weakness of the phone by taking it out of scope (P2P), add other systems to bolster the phone security (HCE), or modify the phone to make it secure (SE). In the world of mobile it is not always essential to have a bank-owned chip in the phone to deliver a secure solution. The Secure Element approach to contactless mobile payments uses a tamper-resistant chip (similar to an EMV payment card) which is owned and controlled by a third party, normally a mobile network operator (MNO) or a handset manufacturer (for example Apple). Cloud-based payments using HCE and mobile P2P payments both rely on a commercial off-the-shelf (COTS) mobile device which has no bank/card scheme involvement in its manufacture, distribution or initial customer registration. page Thales e-security, Inc. All rights reserved.

9 HSMs play a significant role in all the approaches to mobile covered in this white paper. They provide a hardened, tamper-resistant environment for performing secure cryptographic processing, key protection and key management. With these devices high assurance mobile solutions can be deployed that satisfy widely established and emerging standards of the mobile payments industry while also maintaining high levels of operational efficiency. Importantly, they overcome the security vulnerabilities and performance challenges typically associated with software-only cryptography. Issuing banks have used HSMs for many years in their acquiring and transaction processing solutions to ensure the best possible protection for their critical assets. The following sections describe each of the solutions, demonstrating how the banks can leverage their existing HSM infrastructure to deliver secure offerings for each while managing risk, helping to reduce fraud and most significantly overcoming any inherent weakness of a standard mobile device. Mobile payments using secure elements (SEs) The Secure Element (SE) approach to contactless mobile payments is essentially putting a payment chip card inside a mobile phone. The SE typically can take one of three form factors embedded (owned by the handset manufacturer), UICC (owned by the MNO) or MicroSD (owned by the bank). Although the MicroSD option looks like the best one from a bank s point of view (due to ownership and control) this option has gained very little market adoption due to a much higher cost when compared with the other options and either limited phone compatibility or the need to replace the standard MicroSD card supplied with the phone. The option with most industry collaborative activity currently is the UICC model which has comprehensive GlobalPlatform specification support and an associated formal testing and certification infrastructure. Apple Pay is a specific implementation introduced with Apple iphone 6 devices which employs an embedded Secure Element under Apple control and uses a fingerprint biometric to replace the PIN for user authentication. The Secure Element world for issuing banks has become more complicated in that there are now three distinct permutations for issuers to address to ensure maximum coverage amongst customers: Apple phones prior to iphone 6 iphone 6 (and later in the future) Non-Apple phones (especially Android and Blackberry) page 8

10 The mobile device operating system itself is not a trusted entity, but the way that SEs are implemented, any operating system application running on the phone cannot access the SE and its contents; the SE is connected to the NFC controller by a special secure channel called the single wire protocol (SWP). Providing the phone is not rooted 1 or jailbroken 2, there is no way for any application legitimately to intercept the data to or from the SE. This makes the SE behave just like a contactless chip card. The security of the solution is therefore reliant on the secure provisioning of the SE which for most banks will involve the use of a Trusted Service Manager (TSM). It is not practically feasible for a bank to perform this task due to the need for business relationship with all MNOs in every country supported and specialist knowledge of the mobile operating system, mobile network protocols and the GlobalPlatform messaging standards required during device provisioning. Consumer Provisioning Confirmation Trusted Service Manager (TSM) Mobile Network Operator Mobile Network NFC Mobile Phone with Secure Elements Consumer Bank Token Management System Provisioning System page 9 Receiver

11 The infrastructure required for a bank to support SEs involves HSMs to securely manage keys and payment credentials together with the interface to the TSM. A bank who manages the keys for its card portfolio in-house will find it easy to perform the same task for mobile SEs. It is likely that the bank will need to migrate to a token management system that can manage cards as well as the SEs. For maximum flexibility and to help reduce costs, the main role that the bank needs to play is in performing the EMV data preparation stage in-house. This involves using HSMs to generate the cryptographic keys for the SEs and the associated payment application-specific security parameters that are required during the subsequent provisioning stage which will be carried out by a TSM. Ultimately each customer gets a unique set of keys loaded into the SE and keeping the keys secure at all times (at the issuer, at the TSM and while being loaded into the SE) is by far the important aspect hence the use of HSMs and well established procedures to install key encrypting keys to enable secure sharing of keys and data between the issuer and the TSM. The process for the bank is virtually identical to that used during EMV card issuance where the bank generates keys and provides a secure file containing card records to a third party card personalization bureau to create the cards. The TSM is in effect a card bureau for digital cards. For the initial roll out of Apple Pay, a variation of the SE provisioning model shown previously is used since Apple makes use of tokenization. Traditionally SE-based solutions have not used tokenization and therefore this is another aspect for pilot schemes and established SE deployments to consider as another security layer to minimize fraud. Apple also adds a fingerprint biometric on-device authentication identifier in the authorization message for additional security and presumably to facilitate higher value transactions in due course. Apple has worked closely with the card schemes, acquirers and issuers who have signed up to support Apple Pay to keep this processing as simple as possible and to leverage the existing cards stored by Apple securely in its itunes database. One instant benefit is that any magnetic stripe card stored in itunes will benefit from EMV transaction security when used as part of the Apple Pay system. Issuers at present are not playing a major role in the card provisioning for the iphone 6 because Apple is using the card schemes exclusively to perform the tokenization process and the provisioning. This is likely to change over time when issuers, processors and acquirers get more involved as the solution expands to countries beyond the United States. 1 Rooting applies to Android devices where users gain privileged control of the device, overcoming limitations that MNOs and handset manufacturers put on devices, allowing complete removal and replacement of the entire operating system if desired. 2 Jailbreaking is the process of removing certain restrictions and limitations put into place by Apple on devices that run the IOS operating system. page 10

12 Thales HSMs, both nshield and payshield, are used extensively by token management systems (covering cards and mobile payment tokens) involved in mobile SE provisioning. Thales integration partners supply components that can be used by both banks and third party service providers (TSMs). The choice of HSM depends primarily on how extensively the integrator, bank or service provider wants to be involved in sourcing, reading and understanding the various card scheme and GlobalPlatform specification documents that are available with a view to developing and implementing compliant HSM software. For those HSM implementers who desire a significant level of software programming control, nshield and its developer toolkit is the preferred option. For those wanting to leverage Thales expertise and take a high level approach to the software code, payshield is the product of choice since Thales already has packaged all the functions required for the ecosystem into a proven, certified high-level HSM API. Mobile payments using host card emulation (HCE) HCE is an alternative to the Secure Element (SE) approach described in the previous section in this paper. The general consensus within the industry is that using HCE is not as secure as using an SE approach - there are a few significant differences in the solution design and objectives and the industry objective is to deliver security for HCE that is more than adequate for the intended usage: HCE payments are primarily targeted at replacing cash for low value transactions and it is accepted that the mobile device is vulnerable the aim is to limit the impact of key compromise by concentrating on single use keys and blocking duplicate transactions during online authorization. SE payments under some circumstances can support higher value transactions (when a suitable cardholder verification method (CVM) is available) and rely on the fact that the chip in the device delivers the same level of protection as an EMV payment card where the focus is on protecting the key for its lifetime; the aim is to eliminate any mobile device vulnerability by using the tamper-resistant chip to perform all the cryptographic processing and communicate directly with the NFC controller, bypassing the mobile operating system which is vulnerable to malware. page Thales e-security, Inc. All rights reserved.

13 HCE as a viable option for contactless mobile payments was kick-started by Google in late 2013 with the Android 4.4 Operating System (OS) release, codenamed KitKat. This enabled apps on phones for the first time to communicate directly with the NFC controller and hence interact with a contactless POS terminal. Prior to this innovation, all NFC communications required participation by the secure element under MNO control. This critical change enables issuing banks to offer contactless mobile payment applications on the Android platform without needing business relationships with MNOs and is therefore expected to require less initial investment and lower ongoing costs. Building on their existing mobile banking platform expertise and/or harnessing the app developer community expertise, it suddenly looks a lot easier for issuers to introduce phone payments at POS that deliver transaction fee income similar to card payments. Since issuers do not control what types of phones their cardholders purchase, it is imperative that their contactless mobile payment offerings cover the widest possible audience. Although Apple may be in competition with Android, Blackberry and Windows phones primarily for market share, issuers cannot afford to just support one option, especially if they have operations in multiple countries where market share dynamics may vary considerably on a country by country basis - supporting both HCE and SE based approaches is essential for issuers. Thales HSMs, both nshield and payshield, are used extensively by token management systems (covering cards and mobile payment tokens) involved in mobile SE provisioning. page 12

14 Encrypted Database Issuer Back Office Systems Transaction Processing Account Management Derive session keys Fraud management Payment authorization Device Provisioning Manage master keys and card keys Manage customer accounts Manage PINs/passcodes Manage session keys Manage apps Provision device Acquirer Card Network Merchant POS Internet The diagram above shows the solution infrastructure required by issuers who wish to roll out the HCE payment capability to their cardholders. Three core modules are involved which perform different critical tasks in the overall solution which are best controlled and managed by issuers inside their existing data centers or in private clouds: 1. The Account Management module maintains customer account information relating to the card accounts and mobile device details and in many cases could just be an enhancement to the existing card-based system. It also is used to generate, manage and secure customer PIN/password/passcode credentials which form part of the strong user authentication mechanisms which are essential for use with HCE. The other major security task performed is the generation, storage and distribution of the issuer master keys and the card master keys for both the card and the HCE payment systems. The master keys are securely shared with the Transaction Processing module. page Thales e-security, Inc. All rights reserved.

15 2. The Device Provisioning module is responsible for generating the single use keys unique to each mobile device and delivering these in encrypted format to the phone and replenishing them on a regular basis. It acts as the interface between the phone and the bank for payment application management and is the component of the system which ideally is integrated with the bank s existing mobile banking platform. 3. The Transaction Processing module is an enhanced version of one that is used today for card processing it needs to be updated to support validation of the new cryptograms defined by the card schemes for HCE payments and to recognise the new BIN/PAN ranges involved. In the case where the issuer adopts tokenization as part of the solution, this module would perform the de-tokenization process. In theory an issuer can develop the complete infrastructure for HCE from scratch based on the appropriate card scheme specification documents which have been available in their first published versions to the vendor community since June/July In practice the issuer is more likely to buy core components from solution providers like Thales and its integration partners to reduce time to market and avoid a steep learning curve relating to the detailed cryptographic implementation involving new keys, cryptograms and an option to deploy tokenization. There are three critical security processes involved in supporting HCE payments that the banks are very well placed to deliver and are based on processes that involve their HSMs today in the card world. 1. Protection for all the master keys required to manage the HCE portfolios 2. Generation of all limited use keys no other entity (including the mobile device) can generate keys which are used to generate the cryptogram for the transaction 3. Provision of the trust environment involving a combination of encryption, user authentication and secure messaging support to enable secure storage of critical keys and payment credentials at the issuer data center or in the private cloud page 14

16 The HCE infrastructure does not fundamentally introduce any new security processes or procedures for banks it just enables them to combine their existing inherent strong security practices, comprising key generation/distribution, data encryption and message authentication, digital signing into a single cohesive offering. They have the flexibility to develop and take full control of the overall HCE system themselves or leverage any existing or future cloud services from the card schemes or third party service providers for one or more of the modules. The HSM enables banks to completely protect sensitive data and keys right up to the point where they are loaded onto the phone in encrypted form. It is only during payment initiation that the mobile application performs selected decryption (of the encrypted single use key supplied through the Device Provisioning module) to generate the cryptogram. The big question to answer is: what is the threat in using the phone rather than a secure chip to generate the transaction cryptogram? The risk of major fraud with HCE even if the phone is compromised is low due to the way the HSMs protect the critical infrastructure and the fact that device keys can only be used once. For example, the use of HSMs in the Account Management, Device Provisioning and Transaction Processing modules means that no master keys used for protecting the device keys in storage or in transit can be compromised in a similar way to managing keys for payment cards. The HSMs are used to ensure that all devices keys are protected from creation (inside an HSM) right through to delivery (in encrypted form) via a secure channel between the Device Provisioning module and the phone. The issuer has the ability through the individual design of the mobile application to implement strong hardware-based session security to complement the traditional TLS/SSL layer of security typically used for the communication link. The weakest link in the overall process is the storage of the key in the phone since in theory it could be captured by malware during delivery to or usage on the phone this risk is mitigated by careful application design and mobile device management and monitoring during the application activation process involving the issuer. page Thales e-security, Inc. All rights reserved.

17 The card schemes have outlined two practical ways for banks to effectively isolate the HCE payment channel from the other payment channels (such as physical cards at POS and e-commerce) with both involving the use of HSMs. The first method is to create a totally separate BIN/PAN range for HCE so that it has its own set of master keys. The second method is to use tokenization to ensure that the PAN used by the phone is not the same as the one used during a card payment (online or offline) linked to the same bank account. In both cases any fraudster using malware to capture data from the phone would be unable to make use of the data (even if successfully decrypted) to create a counterfeit payment card or perform an e-commerce transaction. Thales works with integration partners to support the provisioning of HCE applications. nshield is the preferred HSM for use with the Device Provisioning module because it can be used to establish a secure hardware-based TLS/SSL session with the smartphone to load the payment credentials. payshield is the HSM most often deployed in the Account Management and Transaction Processing modules because they are already in widespread use by banks today for EMV card data preparation and payment authorization respectively banks just need updated software to support the new incremental requirements for HCE transactions. The HSM enables banks to completely protect sensitive data and keys right up to the point where they are loaded onto the phone in encrypted form. page 16

18 Issuer Back Office Systems Mobile person-to-person payments (P2P) Provisioning Confirmation Mobile Network Operator Mobile Consumer NFC Mobile Phone with Secure Elements Network Mobile P2P is a service that many Trusted banks Service are now starting to provide as a value-added option for their Manager mobile (TSM) banking customers to facilitate transfer of money between two parties without either one having to know the bank account Provisioning details of the other. There are two major System pre-requisites for banks the country where the bank Consumer wishes to offer the service must have a real-time payment Bank infrastructure capable of supporting P2P and the bank must be registered with that Token service, meeting all of Management the necessary security requirements. An example of such a System scheme, known as Paym, was launched in the UK in April 2014 supported by all major UK banks and making use of the Faster Payment System and LINK real-time networks managed by Vocalink to process the transactions. Unlike the other mobile payment solutions covered in this paper there is normally no direct revenue to the banks from transaction fees arising from use of the service in the developed world the sender pays no fees to the bank to send the money and the likewise the recipient pays no fees to its bank to receive the money. The business drivers for banks are in helping their customers become more efficient and leveraging their existing mobile banking platform to offer an alternative to cash and checks which in turn helps banks to lower their branch infrastructure costs. Receiver Receiver s Bank Sender s Bank Authorize Payments & Notify Receiver Sender Confirm & Authorize Payments Service Provider Validate payment & route to receiver s bank Real-time payments platform Encrypted Database page Thales e-security, Inc. All rights reserved.

19 From a customer viewpoint, using mobile P2P is very straightforward and other than the entering of the PIN/passcode to activate the mobile app the vast majority of the trust infrastructure involves the extensive use of HSMs to secure all credential storage and transaction messaging between the banks and the central service provider. Each system is proprietary and therefore specific implementation details vary but there are some common critical tasks where HSMs are involved: The underlying real-time payment platform operated by the service provider will have been created initially with bank involvement and typical HSM deployment includes: 1. PKI certificate management where banks need to have their dedicated public key certificates certified by the service provider 2. Key encrypting key management where each bank will establish a symmetric key (using a key component loading ceremony) with the service provider in order to facilitate symmetric key exchange, message encryption and MACing for subsequent transactions flowing through the system The registration process for P2P uses HSMs during: 1. Authentication of the customer to start the registration process the HSM normally is used to generate a random value/code that is supplied out-of-band to the customer to enter as part of the registration for the service 2. Protection of the customer record created during the registration process which involves the mapping of the bank account number and sort code with their mobile phone number and is held as part of the bank customer account information the HSM is typically used to encrypt, sign and/or MAC the record to protect it during storage at the bank 3. Secure transfer of the customer details from the bank to the central service provider the HSM is used to encrypt, sign and/or MAC the specific customer record required for the service provider system and as a minimum includes name, bank account sort code and mobile phone number details which must be protected from eavesdropping at all times to maintain overall system integrity and security page 18

20 The P2P payment process uses HSMs during: 1. Validation of the user during the logon process for the mobile P2P app the bank can leverage the numerous cryptographic functions inside the HSM (which are used to support the various standard and proprietary user authentication methods) enabling the required level of user authentication to be provided appropriate to their own risk management policy 2. Encryption and signing/macing of the message from the sender s bank to the service provider this is to ensure that the instruction between the banks to debit one account and credit another is protected while in transit 3. Encryption, signing/macing and verification of messages after successful acceptance of the payment instruction by the service provider when the P2P transaction is accepted the HSMs used in the underlying real-time payment system come into play to help protect and authenticate the messaging between the banks and the central service provider, which happens electronically and almost instantaneously without any customer interaction A typical pre-requisite that P2P schemes to date have enforced is that the service cannot be used with mobile phones that are rooted. The bank P2P app specifically tests for this condition during the customer registration process and will prevent activation if necessary. Most banks already have a mobile banking app for their customers to download and use and the P2P app is seen as a useful extension to mobile banking and payments. Banks can utilize the expertise of the vendor community in the development of the apps while concentrating on making as most use as possible of their existing HSM infrastructure to support the needs of the registration processes and the interaction with the real-time payment system. Both Thales nshield and payshield HSMs are involved in helping banks offer P2P services, covering some or all of the cryptographic processes outlined above. page Thales e-security, Inc. All rights reserved.

21 Thales HSMs used in the mobile ecosystem Mobile solutions are constantly evolving and for many issuers and service providers, flexibility in HSM technology is a major consideration. Thales can offer two distinct options: 1. nshield - a multi-purpose HSM with all the latest cryptographic algorithms and key management methods for integration including the ability to utilize a developer toolkit to develop additional user-defined sensitive application security code to run inside the HSM rather than on a vulnerable host application software platform 2. payshield a payment-specific HSM with a comprehensive set of high level API functions dedicated to payment card and mobile issuing and transaction processing complemented with a Thales software customization service to meet additional user-specific requirements nshield Connect page 20

22 The Thales nshield Connect is a high-performance network-attached hardware security module (HSM) that delivers secure cryptographic services as a shared resource for distributed application instances and virtual machines. With nshield Connect, issuers have a cost-effective way to establish appropriate levels of physical and logical controls for their server-based systems where software-based cryptography fails to meet risk management and security requirements. The security boundary of nshield is validated to FIPS level 3. Some of the main benefits that nshield Connect delivers to issuers and ultimately to the consumers making mobile payments are as follows: Generates and protects the limited use keys in HCE solutions that are regularly provisioned to the phone the same high levels of security as used for EMV chip-based payment cards Provides high levels of cryptographic performance, scalability and resilience essential for a mission critical mobile provisioning environment Supports the latest cryptographic algorithms and key management schemes to provide issuer flexibility for the mobile application - designed to future-proof the solution as standards emerge Implements strong role-based user authentication and key separation - helping to prevent exposure of sensitive data during the provisioning process Offers issuers the ability to develop their own code with the nshield CodeSafe Developer Toolkit to ensure sensitive processing runs in a highly secure tamper-resistant environment page Thales e-security, Inc. All rights reserved.

23 payshield 9000 The Thales payshield 9000 hardware security module (HSM) is the most widely deployed payment HSM in the world, used in an estimated 80% of all payment card transactions. The cryptographic functionality and management features of payshield 9000 meet or exceed the card application and security audit requirements of the major international payment systems, including American Express, Discover, JCB, MasterCard, UnionPay and Visa. payshield 9000 is certified to FIPS level 3 and is also available in configurations certified to the PCI HSM specification as published by the PCI Security Standards Council. Thales payshield 9000 provides features to support the latest payment system applications for contact chip, contactless chip, mobile secure elements / digitized cards and to support evolving standards from leading industry organizations including EMVCo, PCI SSC, Global Platform and Multos International. page 22

24 Some of the main benefits that payshield 9000 delivers to issuers and ultimately to the consumers making mobile payments are as follows: Delivers comprehensive, certified security specially designed for card issuing, mobile provisioning and payment processing Incorporates high level functions to support the card scheme proprietary requirements for HCE provisioning and transaction processing, simplifying integration with the issuer mobile banking platform Mobile opens up the potential of new revenue streams for banks. Maximizes business continuity with redundant hardware, field serviceable components, and support for clustering and failover, essential for the 24 x 7 requirements to replenish keys in phones for HCE-based systems Offers a range of scalable, high-performance models, with performance upgrade options to avoid hardware replacement/swap-out as transaction volumes increase Provides issuers with a turnkey software customization service through the Thales Advanced Solution Group (ASG) to ensure all issuer proprietary requirements are addressed in a secure and timely manner page Thales e-security, Inc. All rights reserved.

25 Conclusions Consumers trust banks with card payments and banks are best placed to offer mobile payments. The disruptive nature of mobile is leading to new security models, new risks and new partnerships - the bank is no longer in complete control of the consumer payment token. Apple has recently entered the mobile NFC payments market creating new technology and business relationships with established players (including large US-based issuers) and leveraging the latest security techniques helping to improve the overall user experience. The mobile device is an untrusted device and for it to play a role in the payments ecosystem a comprehensive security infrastructure needs to be established to support the evolving mobile environment. Apple has shown its hand with a focus on security and privacy using an implementation tightly coupled to its handsets, operating system and applications issuers need to launch other comparable secure solutions to make best use of the infrastructure around other non-apple mobile handsets. This is essential to deliver the necessary trust required for consumers and merchants to be motivated to adopt mobile payments and reach critical mass. The three approaches covered in this white paper are well aligned with the proven expertise of banks in delivering solutions which have high inherent levels of security and where risk is well understood and can be effectively mitigated. Mobile opens up the potential of new revenue streams for banks. Through their experience with card payments, banks know how to use HSMs as a coherent, unifying platform across all new mobile solutions to: Secure keys and sensitive data protecting critical assets and dealing with a virtual world rather than a physical world Authenticate users ensuring only registered customers have access to the mobile service Block fraudulent transactions preventing stolen or counterfeit credentials leading to monetary loss Thales has a proven track record in supporting banks by providing highly secure HSM implementations. Thales and its integration partners are well positioned to help banks now fulfill their mobile strategy with proven hardware and software components already in use by innovative banks in many developed countries. The market is evolving quickly with proprietary solutions being deployed (especially in the case of the HCE and P2P approaches) without waiting for the inevitable standards to be developed and ratified. Thales has a proven track record in supporting banks by providing highly secure HSM implementations covering both standard and proprietary APIs and functions. Successful mobile solutions demand trusted partnerships Thales is eager to assist banks in driving adoption of mobile payment solutions, reducing their integration task and time to market. The opportunity for issuers to succeed is now. page 24

26 Glossary API BIN COTS CVM EMV HCE HSM MAC MNO NFC PAN P2P P2PE PCI Application programming interface Bank identification number Commercial off-the-shelf Cardholder verification method Europay MasterCard Visa Host card emulation Hardware security module Message authentication code Mobile network operator Near field communications Primary account number Person-to-person Point-to-point encryption Payment card industry PCI DSS Payment card industry data security standard PIN PKI POS QR SE SSL SWP TLS TSM UICC Personal identification number Public key infrastructure Point-of-sale Quick response Secure Element Secure sockets layer Single wire protocol Transport layer security Trusted service manager Universal integrated circuit card page Thales e-security, Inc. All rights reserved.

27 Further information Content relating to mobile payments can be found on the Thales e-security web site at locations including: Mobile Payments solution page mpos solution page nshield and payshield HSMs Technology partner section Case studies Thales e-security blog Thales partners working in the mobile payments market have various useful articles and documents including: Aconite Bell ID Cryptomathic Industry organizations and standards bodies provide good sources of information at the following locations: MasterCard Mobile Solutions Visa Digital Solutions usa.visa.com/clients-partners/mobile-acceptance/visa-ready.jsp EMVCo GlobalPlatform There are various portals and blog sites that regularly cover mobile activities including: Finextra NFC World PaymentsSource The PAYPERS PYMNTS.com Celent banking blog bankingblog.celent.com/ Consult Hyperion blog Glenbrook blog page 26