BLE Payments. Part 1

Introduction

In addition to the standard payment methods offered by Apple smartphones, some contactless payment specialists are trying to devise their own payment methods. Various options have been proposed, ranging from simply sticking a card sticker to the back of a phone case, to attempting to turn a POS terminal into an NDEF tag and interacting with it using an iPhone as a read/write device.

Today, this article proposes to consider an option for implementing contactless payment using Bluetooth Low Energy (BLE) technology. A solution of this kind, code-named “Volna,” is currently under development. This technology offers hope for restoring a convenient user experience for iPhone owners in those countries where standard smartphone payment methods do not work.

There are many articles online that discuss BLE technology in general and its specific features, but this article will focus on its application in the payment sector, specifically for paying for goods and services in stores, and also look at the challenges and features that may arise when implementing such a solution.

Bluetooth Low Energy technology

But still, to save you the time of surfing the internet, let’s briefly explain what BLE is.

Bluetooth Low Energy (BLE) is a wireless data transfer technology, the most significant advantage of which is its ultra-low power consumption (including in idle mode). It operates on the same frequencies as standard Bluetooth Classic (2.402-2.48 GHz) but differs from it in using shorter data packets.

This makes BLE ideal for use in devices that require long battery life, such as fitness trackers, sensors, and other Internet of Things (IoT) devices. In many cases, devices can operate for more than a year on a single miniature button cell battery without recharging.

But today’s discussion is not about these devices, and it’s not primarily because of its low power consumption that BLE is well-suited for payments. To minimize changes to the customer experience, it is necessary to choose a technology that will have minimal impact (at least in a negative way) on the current customer experience when making payments. Bluetooth Classic requires a preliminary pairing procedure with each new device (in this case, a POS terminal), so using Bluetooth Classic for payments would be very inconvenient and complex for participants in the payment process. However, one of the defining features of BLE, in terms of its application for payment, is the ability to establish a connection and transmit payment data in both directions (from the terminal to the phone and back) without explicit human interaction.

BLE technology was introduced in 2010 in the Bluetooth specification version 4.0 as an independent technology incompatible with Bluetooth Classic. Bluetooth Classic is used, for example, for wireless headphones, speakers, and car audio systems. Nevertheless, BLE can coexist with Bluetooth Classic in the same device, as is the case in modern smartphones.

Problems and Challenges

Now let’s consider the main problems and challenges that need to be addressed to implement payments using BLE technology:

1. Range of Operation

The first problem stems from the specific nature of BLE, namely its longer range of operation (usually 10-50 meters depending on the configuration of the receiver/transmitter and the space between them) compared to NFC technology, which was originally designed for payments or other communication over a short distance (~10 cm) between devices. This poses a problem for identifying the payment terminal where the payment will be made. Accordingly, to solve this problem, it is necessary to develop a mechanism for determining the distance between the customer’s smartphone and the terminal on which the payment should be made (in order to avoid making a payment at a neighboring checkout).

This task can be solved, for example, by tracking the Received Signal Strength Indicator (RSSI) or, simply put, the signal strength. Here, the following questions inevitably arise: how to detect and construct the dependency of the RSSI indicator value on the distance between devices, the impact of different BLE implementations on different devices on this dependency, and the identification of correction coefficients to mitigate these differences. It is also possible to develop backup semi-manual mechanisms that can be activated when the main mechanisms fail. For example, in the event of a weak signal insufficient for standard transaction activation (even at a short distance between devices), the customer may be prompted to initiate the payment transaction manually.

2. Infrastructure

Each time a new service is implemented that requires a large reception infrastructure (a payment service is unlikely to be in demand if it is only available at specific points of sale, i.e., not universally), the question arises: how can the service be implemented while minimally affecting and maximally reusing the existing payment infrastructure? The more changes that need to be implemented, the higher the cost of the project for participants and, accordingly, the lower the chances for broad deployment of the acceptance network and the success of the project.

In this case, the cornerstone is the support of BLE technology on POS terminals, as well as the imposition of some additional requirements (for example, security), which complicate the updating of the acceptance terminal network. Currently, the share of Android terminals in the market is rapidly increasing, and, accordingly, the number of devices that support BLE is also increasing. There are also many non-Android terminals that support BLE technology and can also support BLE payments through software modifications only (without requiring hardware modifications or replacement). And there are a number of terminals that, in principle, do not support BLE technology—these terminals will not be able to accept payments, and retailers with such terminals will either have to be excluded or the terminals replaced.

3. Adaptation of Payment Software

Another nuance related to the terminal network is the large number of different vendors present in the market (currently, there are more than 4 million POS terminals of different manufacturers, models and configurations operating). Moreover, previously, Bluetooth technology was not used directly for payments, but could be used for certain auxiliary purposes (for example, for connecting the terminal to a cash register). Therefore, efforts will be required from vendors and acquirers to refine the terminal software.

4. Client Devices

The next task is to support the technology on the client-side devices. With a limited set of devices in the form of the iPhone model line, this is a relatively simple task, solvable by developing application software (all iPhone models support BLE technology). The main challenge in the current reality of some countries seems to be the distribution of the application, considering the difficulty of getting and securing an application in the AppStore for a long period.

If it becomes necessary to add a service for customers using smartphones based on Android OS, there will be no problems from the hardware or application development point of view (almost all modern Android phones support BLE at the hardware level, and there is operating system support starting with Android 4.3). However, problems may arise due to the large number of manufacturers and models, related to the peculiarities of BLE operation (the diversity and range of quality of implementations may vary significantly from that of Apple). In this case, it will be necessary to conduct a large-scale study of the most popular models.

5. Integration with Payment Systems

At the moment, there are 2 main methods of contactless non-cash payment: using Mir cards (or tokens) or through the Faster Payments System (FPS). Accordingly, when implementing payments using BLE, it is desirable to integrate with existing payment systems, as building a new payment system is a task that requires huge resources (human, financial, administrative). Therefore, when developing the BLE data exchange protocol, it is necessary to change the data transport (for example, from NFC to BLE) while maintaining the data format and mechanisms of operation as much as possible so that it is not necessary to redo protocols and logic at the level of the terminal, acquirer, payment system, and issuer.

6. Interface Collisions

The next task is to solve collision problems. We already mentioned the problem of “accidental” payment at a neighboring checkout above, but there is also a potential problem with the conflict of two interfaces, BLE and NFC. In the case of iPhones in some countries, NFC payment is frozen, so the problem should not arise (except for the case when a user has a foreign bank card added to Apple Pay). As for Android, such collisions are theoretically possible, and their resolution can be attempted either on the client’s phone (if a single application is used for payment through both interfaces), or on the POS terminal, allowing simultaneous payment via only one technology: either BLE or NFC.

7. Security

And the last, particularly sensitive issue that we will consider in this article is security. The key difference between BLE and NFC payments in terms of potential attacks is the increased range of BLE. This gives more scope for the imagination and actions of attackers. Let’s look at the main types of attacks that can be attempted on BLE payment technology.

Spam attacks

Spam attacks, which do not lead to financial losses, but potentially have a negative impact on the service and the customer experience. Theoretically, attackers may try to create emulators of POS terminals with more powerful Bluetooth transmitters and try to offer anyone within the range of their devices to start payment via the BLE channel.

It is likely that, as they will not receive any financial benefit from such actions, these attacks will not be widespread and may be more of a prank by “amateur hackers.”

Nevertheless, there are ways to protect against such attacks – for example, building a network of trusted terminals, or implementing a mechanism that allows reliably distinguishing a real terminal belonging to the system from a third-party terminal. Such a mechanism could be, for example, the construction of a PKI (Public Key Infrastructure), which consists of loading a chain of certificates into each POS terminal so that the client device, before making a payment, could request the chain of certificates and validate it using a root key of the payment system’s certification authority preloaded into the client mobile application.

Another security measure could be a preliminary check of the transaction request through trusted channels on the payment system backend (some payment systems, for example, FPS, allow this mechanism to be implemented since the payment request comes directly from the client’s mobile application via trusted channels).

Relay Attacks in Their Various Forms

Relay attacks are attacks in which the attacker uses special hardware and software to redirect the payment transaction traffic from the POS terminal where they pay for their goods/services to the “victim’s” client application, and tries to pay for their goods at the expense of the “victim’s” payment instrument. There have been discussions about such attacks in the context of NFC payments, and theoretically this is also possible. However, with the advent of BLE payments, it will become “easier” and simpler for attackers to carry out such attacks (if they are not protected against) precisely because of the longer range of BLE.

Measures of protection and compensation in this case could include a mechanism for the customer to confirm the amount of the transaction and the name of the place of payment (store, company) on the screen of their smartphone.

A mechanism for determining the distance and initiating payment only when a short distance is reached can also serve as protection, but attackers could theoretically try to circumvent it by using more powerful BLE signal transmitters.

Another mechanism that would completely eliminate the risk of relay attacks, but negatively affect the customer experience, is the online entry of a PIN on the POS terminal’s keyboard—a mechanism used in classic card payments.

Man-in-the-Middle Attacks

Man-in-the-middle attacks are another class of attacks in which the attacker attempts to interject themselves between the payment terminal and the client device and change some or all of the data. These attacks and ways to counter them have long been known in the payment industry, and the introduction of a new data transport in the form of BLE does not introduce additional risks. One of the protection mechanisms is cryptographic signing of sensitive data (in this case, data substitution will be detected, and the transaction will be rejected).

Replay attacks

Replay attacks are an attempt by attackers to intercept transaction data, take a “snapshot” of it, and try to “pass it off” when another payment is made. This class of attacks is also well known in the payment industry, and the main mechanism for countering them is the generation by the terminal of a random number unique to the transaction, as well as maintaining a counter on the client device, the value of which is unique for each subsequent transaction.

As a general measure of countering attacks, it can be proposed to limit the use of BLE payments at the organizational level. For example, exclude cash withdrawals at ATMs from the possible ways of using BLE due to the particular interest of fraudsters in obtaining cash in places where there are no cashiers/operators.

Conclusion

In conclusion, it can be said that the implementation of BLE payments in the market seems to be a quite feasible and relatively inexpensive task (provided that the existing infrastructure and technologies are used as much as possible), which can meet the demand of a certain category of customers. We will monitor the development of the market and expect the first implementations probably this year.