OCTOBER, 2018

MOBILE POINT OF SALE SOLUTIONS:ENABLEMENT THROUGH SECURITY

© In

side

Sec

ure

- 20

18 -

All

right

s re

serv

ed

2 3

One of the fastest moving and most exciting parts of the payment chain today is that of Mobile Point of Sale. What has been seen as a hardware-intensive and complex process – particularly with the EMV migration in the United States – is becoming in many ways a simpler but more fragmented market.

This poses opportunities and challenges in equal measure; opportunities for new players to come through and build a successful business and challenges to first- and second generation companies who have built their businesses on “traditional” models.

This paper focusses on the technologies, standards and security headaches that are arising as a result.

TABLE OF CONTENTSAbstract

Introduction

Why?

But?

How?

Risks

Summary

mPOS Glossary

3

4

7

8

9

12

14

15

Abstract

4 5

Mobile Point Of Sale (mPOS)

Of course, nothing stays still. Inspired by HCE Payment Wallets, and motivated by the EMV migration in the US; the Card Schemes, EMVco and PCI have developed standards to begin to remove both the expensive dedicated PEDs, with which everyone in Europe is very familiar, and even the relatively cheap Bluetooth PEDs supplied by the (generally) European upstarts from the process.

This has recently resulted in two new developments, these are related but are not (yet) interchangeable standards: Tap-to-phone and PIN-on-COTS. This last point is important to remember, these are not the same technically nor in terms of use-cases.

Downloadable mPOS (or Tap-to-Phone)

As the name suggests, this is software that allows any Android Phone to take tap-to-pay NFC payments from a contactless card (or device) for goods and services, under the contactless value limit (unless authenticated by a consumer device).

In this use-case, the transaction values are restricted and therefore a further level of authentication (PIN) is not required, there is no provision for PIN-entry in the software or on the device.

The most likely retail uses will be for low value, fast transactions; coffee shops and food trucks, newspaper stands, market traders and even charity donations.

What is noticeable is that because this is a 100% software solution, there is potential for traditional customers of POS systems & hardware to decide to develop solutions for themselves, not waiting for their traditional hardware vendors to catch up.

If we stretch the definition slightly, it is clear that many self-service panels appearing in fastfood and other high foot-fall, low transaction value sites, can benefit from the ability to take a Tap-to-Phone payment and then the customers simply goes to a pick-up window. These could even be at drive-thru?

Mobile Point Of Sale (mPOS) is one of the most exciting areas in Payments right now (and no it doesn't feature Blockchain or AI - yet anyway).

There are a plethora of companies developing mPOS systems and software, many of these are small, can be classed as startups but in addition, the large incumbent players are increasingly active.

This market is increasingly being driven by established “Unicorns” of mobile payments like Square and iZettle (now being acquired by PayPal).

It is fair to say that Square pretty much invented the category, providing small merchants (and latterly some very large ones) with innovative and attractive hardware and software, backed up by systems and services. Of course, this has been primarily in the United States before the EMV migration started and simple mag stripe (and minimal security) was allowable. In other parts of the world where EMV was already deployed, the

original Square solution was not allowed.

This created a space for new entrants in the market, like iZettle, to develop EMV compliant mPOS products. These used dedicated “Pin Entry Devices” (PEDs); and could be considered a hybrid, combining traditional POS devices with some of the benefits of Square’s approach. Thus, the mPOS market has grown and it's now common to see a stall holder at a farmers' market in California taking Square payments or a food-cart in Stockholm taking chip and pin payments via an iZettle terminal; use-cases where the larger EMV POSes from established players are simply too expensive to make sense.

INTRODUCTION

6 7

WHY?

PIN-on-COTS platforms (or Pin-on-Glass)

The New Specifications allow any capable device to become an EMV Payment terminal. That same device also processes the transaction to the acquiring entity.

In the case of PIN-on-COTS the device connects to a Secure Card-Reader (SCR), eliminating the need for a PIN-entry device, and allowing the entry of the PIN upon the mobile device (sometimes referred to as PIN-on-Mobile).

In the Tap-to-Phone example, even the need for the SCR is eliminated, there is the contactless payment amount limit to take into consideration but for many small merchants this is not an issue.

This takes the market back to the massive advantage of Square’s original business model; minimal cost, minimal hassle, easy payments.

Immediately we can see from the point of view of capital investment by a small trader there is a saving, indeed any mobile retail or transactional platform now has no need of a complex (or even a simple) separate PED device as a simple card reader can be connected to a standard, commercial off-the-shelf (COTS) mobile platform such as a phone or tablet.

These are new Specifications from the PCI1 which will allow higher value transaction on (primarily) mobile devices.

In this case they feature a piece of hardware; a Secure Card Reader (SCR) to read the chip on a card, and downloadable software featuring an on-screen PIN entry – commonly termed “PIN-on-Glass” or “PIN-on-COTS”.

The additional component separates the chip-access from the PIN-entry process. This separation is important maintaining PCI’s all important security requirements. Like the mPOS examples, the use-cases will vary, from small merchants being able to take cards – supplementing or even supplanting the present mPOS-style hardware products through to line-busting in major retailers.

Also, like mPOS, there are self-serve use-cases; ordering at table as we see in Amsterdam’s Schiphol Airport and Burger King in the US.

Again, although the principles were developed for mobile, there is no reason why we cannot support the migration of such technologies to larger, fixed self-serve screens and tablets. The potential for disruption of the traditional PED manufacturers’ business is obvious, why pay $1,000+ for a device, when a $20 SCR and any iPad can take payments?

The problem is, as always, replacing Secure Hardware with Secured Software isn’t easy – but we’ve done this before: Inside Secure delivers proven PCI/EMV Certified Mobile Payments software products for Issuers.

It can be reasonably argued that the same security tools and systems can be re-purposed to help protect the flip-side – Acquisition of payments. The first iteration of this has been announced and is being actively trialled by Ingenico in Italy now.

The publication of the Payment Card Industry (PCI) "Software-based PIN entry on COTS" document in January 2018 is arguably as much of a revolution in the Point of Sale market as was Host Card emulation to Mobile Payments. Both swept away established norms, both removed apparently mandatory security requirements and as a result both offer significant opportunity for innovation among new market entrants and established companies alike.

1 https://www.pcisecuritystandards.org/assessors_and_solutions/spoc_solutions

8 9

Tap-to-phone and PIN-on-Mobile raise massive security questions. There’s a move from an established and trusted security model to a new model that hasn’t been seen before in the POS market. Of course, the model has been proven elsewhere – such as HCE cloud-based payments.

Like HCE, Tap-to-Phone has all of the transaction processing within the mobile app, on the same mobile device on which the merchant will do his own Mobile Banking, messaging via WhatsApp and play Fortnite. This demands that the transaction flows and the processing of the transaction be secure & ring-fenced. Exactly as certified secure HCE Apps are.

To ensure the transaction security within these new mPOS device, both Tap-to-Phone and PIN-on-Mobile start from a principle of “separating church & state”. The "church" in this case is the PIN and the "state" being the credentials for the card managed by that PIN. If an attacker can’t know both at the same time, the risk is greatly reduced. With

Tap-to-Phone the separation is achieved by removing the PIN. All transactions are “low value” – below the requirement to enter a PIN.

When it comes to PIN-on-COTS. The transaction (and so card details) are handled by the secure card reader; and so are never seen by the device controlling the “glass”. Of course, manging risk does not remove the requirement for security. As these are off the shelf consumer devices, that means the security has to be provided by the mPOS software.

For Tap-to-Phone, that means securing the transaction processing, so the all-important cryptographic keys are not leaked to an attacker. For PIN-on-Glass, that means, ensuring no-one is snooping on the PIN entry and that it is not possible to tie the PIN back to card. Not an easy task. For this reason, the new PCI PIN-on-COTS specifications are over 100 pages on security!

BUT?As stated above, the comparison with Cloud Based Payments is striking; an Application is required to manage on-boarding, account authentication, cryptographic processing and secure communications - all in a fully protected manner. Regardless of what else is loaded onto the device or if it’s rooted/jail-broken2. This is pretty much exactly what Security Certified Mobile Payment solutions are doing on Android devices right now.

Inside Secure is a leading vendor of these

solutions, utilising our own proprietary technology to ensure that the above requirements are secured to Visa and Mastercard (EMVCo & PCI standards).

It therefore stands to reason that the same tools can be used to help protect transactions being received on Tap-to-Phone and on devices operating within the PCI security requirements for Software-based PIN Entry on COTS devices.

Of course, the variable that requires to be addressed is the architecture of the applications. There may be a number of options to be considered by vendors in this market and these can be part of their own IP and competitive advantage:

HOW?

• Which Platform will I support?

• iOS?

• Android?

• Windows Surface for more large-scale Register or Self-Service applications?

• Will I provide the Server-Side support or rely upon an established POS vendor or Payment Processor/Acquirer?

• Can my architecture be EMV certified?

• Which card reader is certifiable in this case?

These questions are out of scope of this paper but should be part of any potential vendor'sdecision-making process.2 Note that the PCI PIN-on-COTS specifications clearly disallow Rooted Devices from use in this case. However, as we know from long experience, there are many ways of masking a rooted device from a network. All Apps must therefore be built to survive in this high-threat environment.

10 11

But, to get back to the question of "How?"We’ll focus for now on the PCI’s PIN-on-COTS, as this is the most developed security model, however Tap-to-Phone architectures will be similar, changing the exchange from the SRC hardware to the internal NFC antenna on the device.

The diagram below shows the PCI’s PIN-on COTS architecture and data flows within the COTS Device (circled), the light blue area is the Mobile App.

In summary; the Application is the bridge between the Card within the Secure Card Reader (SCR) and the back-end processor, the potential for a number of attacks on a standard platform are significant and are well understood among cloud-based payment vendors.

The application requires to be able to defend itself against Dynamic and Static attacks, attempts to understand the cryptographic processes (at rest, in transit and in memory) along with a secure communication protocol reaching from within the Application itself through to the SCR and back-end monitoring/attestation processing server.

As is well known from Mobile Payments, which feature similar principles, the achievement of a Secure App in the above use case is a challenge and is heavily policed by PCI, EMV and the payment schemes themselves. Mobile devices (of all Operating Systems) are among the most effective hacking tools ever created.

They are in the hands of billions of individuals, they have a standardized set of

characteristics and traditional IT security techniques simply don't apply. Even one of the best known "security" techniques, and repeated in the PCI requirements, is that of root detection. This is a process by which the Application can recognise if the device has been rendered more open to manipulation of the operating system.

That manipulation can leave the OS and device more open to attack by Malware or other vectors. Unfortunately, like pretty much all OS-level protections this relies on an outdated whitelist/ black-list technique which requires that the defender (or the tool vendor selling the detection software) knows what attacks are coming.

This almost never happens and is an illustration why Inside Secure does not rely upon the OS to protect the key components of any application.

Mobile Devices and their Operating Systems can never be trusted, any application you create is the only component you control, as such it is therefore the only component in which you can build your own level of trust.

PCI Software-based PIN Entry on COTS Security Requirements, v1.0 Page 18© 2018 PCI Security Standards Council, LLC. All Rights Reserved. January 2018

Software-based PIN Entry Solution OverviewThe following diagram illustrates the flow of a PIN transaction in a software-based PIN entry solution. Steps 1-7 are detailed on the following page.

Figure 3: Software-based PIN Entry Solution

12 13

Mobile devices are about convenient and easy access to services and data. That means that they display, process and store lots of personal data.

The analysis of Mobile Banking apps carried out for UL Labs & Inside Secure’s “Wild West” research, showed that most Financial Services organisations are entirely unaware of the risk they are running.

The PCI security objective is stated as:

“The objective of these security requirements is to provide reasonable assurance that Software-based PIN CVM Solutions provide adequate security mechanisms, controls and mitigations to protect the consumer’s cardholder data, PIN and other assets—e.g., cryptographic keys, correlatable data, etc.—from unauthorized disclosure, modification or misuse by providing an attack surface that may be perceived as uneconomic for an attacker to penetrate. It is recognized that an attacker may have other objectives—e.g., self-promotion, nation-state attack, etc.—and may expend more resources to circumvent established controls than is warranted by the direct financial fraud payback. For the COTS

components, the objective of these security requirements is to provide reasonable assurance that these components have been kept up to date and have not been modified from what had been deployed by the COTS provider.”

So, this basically sets out the minimum requirement for the security of the Application combined with the SCR.

Organisations should be protecting their applications with strong Code Protection technologies that resist attempts to reverse engineer or modify code (sometimes known as RASP3). Whitebox cryptography provides a proven technology to keep those cryptographic keys safe even in open and insecure environments like mobile phones.

Combined, these technologies and techniques are “state of the art”. Of course, this doesn't directly mention GDPR, a mandatory consideration in the EU.

Remember, any data that can directly or indirectly identify an individual is in scope of GDPR, so personal data on mobile devices needs to be protected at rest, in transit and during use.

RISKS?

3 RASP – Runtime Application Security Protection – one of a number of acronyms for Code and Application protection 4 Read the white paper : https://www.insidesecure.com/Company/More/whitepapers/The-Wild-West-of-Mobile-Security

Well, as said above, the good thing is that the principles of mPOS running in a software solution is pretty much the flip-side of the existing, proven and certified mobile payments (HCE) technology.

Exactly the same tools as are able to deliver certifiable solutions, without additional hardware on the mobile device, can be used.

Fundamentally:

So how does a developer address these issues?

• App Code needs to be protected from Static & Dynamic analysis

• Crypto Data needs not only to be protected but also to be able to run in a protected fashion

• Connectivity to the SCR and Cloud Series need to be secured and authenticated

• Architectural and deployment support

The PCI specifications helpfully list some of these, however the detail of implementation, as with Cloud-Based payments, is left to the individual developers. And while tools are able to secure the transactions to that required by PCI, these are not a panacea.

Any tools effectiveness can be challenged by architectural errors. It is essential that the architecture and even the developer languages chosen are actually able to be secured - many Mobile Financial apps have ignored or forgotten this and are therefore open to compromise (see Inside Secure and UL Labs Wild West of Mobile Banking white paper4 for details).

14 15

A whole new market has opened up on the Acquiring side of Mobile Payments; for small merchants through to some of the largest, and the developers supporting them. As has been seen in the development of Mobile Payments, developers' and Issuers imaginations have allowed new integrated solutions, innovative new Banking apps and new opportunity. The same is possible for mPOS market.

Cloud-services can gather payment patterns and help Merchants plan and develop strategies. Marketing to specific segments via mPOS devices or self-service devices, becomes possible with the closure of a major stumbling block – lack of integrated payments. mPOS developers can unleash their UI

creativity, why should System developers be restricted in the development of a UI/UX for one type of restaurant versus another? Should a door to door hair-dresser be forced to use the same UX as a handyman or small market trader?

Software is flexible, it's malleable too, the advantage of the flexibility wince developed needs to be tempered by security solutions delivered by companies that both understand these two vital characteristics but also have a unique approach and experience in ensuring developers vision and company strategies are not hamstrung by 20th century thinking.

Welcome to 21st century retail & hospitality with Inside Secure.

Point of Sale (Merchant) A generic term for systems used by merchants to manage the purchase of their goods and services. These may be as simple as a Cash Register or as complex as fully automated stores such as Amazon Go.

ePOSAn Electronic Point of Sale (ePOS) is a modern Cash Register that is connected to a merchants wider systems for managing stock and customer relationships.

Point of Sale (Cards industry) Point of Sale or (POS) in the card market refers to the

mechanisms in place at merchants to read and receive payments from payment cards.

Point of Sale Terminal (Cards industry) A POS Terminal is the device the consumer tap, inserts or

swipes their debit or credit card against.

mPOSMarket pioneered by Square and iZettle. Mobile Point of Sale

(mPOS) gives the ability to receive card payments on a standard mobile device. Traditionally this uses an accessory to securely manage a "chip" transaction and accept the card holder's PIN.

mPOS Glossary

• Code Protection Tool: ensure that applications implementing Strong Authentication or managing personal data remain secure.• Whitebox Tool: State of the art protection crypto data as required by PCI.

• Strong Authentication Solution: Perfectly meets PSD2’s strong customer authentication requirements.• Secure Communication Tools: Ensuring the servelinks are securely maintained.

Where does Inside Secure come in?

SUMMARY

16

About Inside SecureInside Secure (Euronext Paris – INSD) is at the heart of security solutions for mobile and connected devices, providing software, silicon IP, tools, services, and know-how needed to protect customers’ transactions, ID, content, applications, and communications. With its deep security expertise and experience, the company delivers products having advanced and differentiated technical capabilities that span the entire range of security requirement levels to serve the demanding markets of network security, IoT and System-on-Chip security, video content and entertainment, mobile payment and banking, enterprise and telecom. Inside Secure’s technology protects solutions for a broad range of customers including service providers, operators, content distributors, security system integrators, device makers and semiconductor manufacturers.

For more information, visit www.insidesecure.com

Queue BustingUse of mobile POS devices, remote from the counter on the shopfloor at retail, entertainment and transit. Given merchants extra POS capacity at busy times without needing physical infrastructure.

Tap-to-phoneA simpler model than the traditional mPOS; allowing payments to be taken on a standard mobile device without any accessory. In this case via the NFC within the device. Payments are limited to the contactless value set by the country in which it is used.

Pin-on-glassAlso known as PIN-on-COTS. This is a new PCI standard allowing mobile devices to become payment terminals. These can read chip-cards via a secure card-reader and take payments above

the contactless limits when the PIN is entered on the device screen.

mPOS Glossary