BLE-платежи. Часть 1

Введение

Уже несколько лет специалисты по бесконтактным платежам России ищут варианты вернуть привычный и удобный для клиента способ оплаты смартфонами компании Apple. Были предложены различные варианты: начиная от простого приклеивания карты-стикера на чехол телефона, заканчивая попыткой сделать из POS-терминала NDEF-метку и провзаимодействовать с ней с помощью iPhone, используя его в качестве устройства чтения и записи.

Сегодня в данной статье предлагается рассмотреть вариант реализации бесконтактной оплаты с использованием технологии Bluetooth Low Energy (BLE). Подобное решение под названием «Волна» на данный момент разрабатывает Национальная Система Платежных Карт (НСПК). Эта технология даёт надежду на возврат удобного пользовательского опыта обладателям iPhone в России.

В интернете можно найти множество статей, рассматривающих технологию BLE как в целом, так и её особенности, но в данной статье сфокусируемся на её применении в платёжной сфере, а именно в целях оплаты товаров и услуг в магазинах, а также посмотрим на сложности и особенности, которые могут возникнуть при реализации такой задачи.

Технология Bluetooth Low Energy

Но всё же, чтобы вам не пришлось тратить время на серфинг в интернете – коротко расскажем, что такое BLE.

Bluetooth Low Energy (BLE) — это беспроводная технология передачи данных, наиболее существенным достоинством которой является сверхмалое энергопотребление (в том числе в режиме простоя). Она работает на тех же частотах, что и стандартный Bluetooth Classic (2,402-2,48 ГГц), но отличается от него более короткими пакетами данных.

Это делает BLE идеальным для использования в устройствах, которые требуют длительного времени работы от батареи, таких как фитнес-браслеты, датчики и другие устройства Интернета Вещей (IoT). Во многих случаях устройства смогут работать более года на одной миниатюрной батарейке типа таблетка без подзарядки.

Но сегодня разговор будет не об этих устройствах и не об этом – BLE хорошо подходит для платежей в первую очередь не по тому, что мало потребляет энергии. Чтобы опыт покупателей изменялся минимально, необходимо выбрать технологию, которая позволит минимально повлиять (по крайней мере в худшую сторону) на текущий клиентский опыт при совершении оплаты. Bluetooth Classic требует предварительной процедуры pairing-а (спаривания двух устройств) с каждым новым устройством (в данном случае POS-терминалом), поэтому использование Bluetooth Classic в целях проведения платежа выглядело бы очень неудобным и сложным для участников оплаты. Но одной из особенностей BLE, которая стала определяющей с т.з. её применения для оплаты, является возможность создания соединения и передачи платёжных данных в обе стороны (от терминала к телефону и обратно) без явного участия человека.

Технология BLE была введена в 2010 году в спецификации стандарта Bluetooth версии 4.0 как независимая и несовместимая с Bluetooth Classic технология. Bluetooth Classic используется, например, для беспроводных наушников, колонок, музыкальных систем в автомобилях. Тем не менее BLE может существовать совместно с Bluetooth Classic в одном устройстве, как например в современных смартфонах.

Проблемы и задачи

А теперь давайте рассмотрим основные проблемы и задачи, которые необходимо решить для внедрения оплаты с использованием технологии BLE:

1. Радиус действия

Первая проблема вытекает из специфики BLE, а именно более дальнего радиуса её действия (обычно 10 – 50 метров в зависимости от конфигурации приёмника/передатчика и пространства между ними) в сравнении с технологией NFC, которая изначально была разработана с целью проведения платежа или другой коммуникации на небольшом расстоянии (~10 см) между устройствами. Это проблема определения платежного терминала в котором будет совершена оплата. Соответственно, для решения такой задачи необходимо разработать механизм по определению расстояния между клиентским смартфоном и терминалом, на котором должна быть проведена оплата (чтобы не выполнить платёж на соседней кассе).

Данная задача может быть решена, например, с помощью отслеживания индикатор уровня принимаемого сигнала RSSI (Received Signal Strength Indicator) или по-простому - силы сигнала. Здесь обязательно возникают вопросы: обнаружения и построения зависимости значения индикатора RSSI от расстояния между устройствами, влияния различных реализаций BLE на разных устройствах на эту зависимость, и выявления поправочных коэффициентов для нивелирования этих различий. А также возможно разработка запасных полуручных механизмов, которые можно активировать при несрабатывании основных. Например, в случае слабого, недостаточного для штатной активации транзакции, сигнала (даже на небольшом расстоянии между устройствами) клиенту может быть предложено принудительно начать платежную транзакцию.

2. Инфраструктура

Каждый раз внедряя новый сервис, который требует большой инфраструктуры приёма (платежный сервис вряд ли станет востребованным, если он будет предоставлен только в определённых точках продаж, т.е. не повсеместно) стоит вопрос: как можно внедрить сервис, минимально затронув и максимально переиспользовав уже существующую платёжную инфраструктуру? Чем больше изменений потребуется внедрить, тем выше будет стоимость проекта для участников, и соответственно тем меньше шансов на широкое раскрытие сети приёма и успешность проекта.

В данном случае краеугольный камень – это наличие поддержки BLE-технологии на POS-терминалах, а также предъявление каких-то дополнительных требований (например, к безопасности), усложняющих обновление терминальной сети приёма. На текущий момент доля android-терминалов на рынке стремительно увеличивается, а соответственно и становится больше устройств, которые поддерживают BLE. Также существует множество не-android терминалов поддерживают технологию BLE, которые также могут поддержать BLE-платежи только за счёт софтверных доработок (не требуя доработки или замены аппаратной части). И существует часть терминалов, которая в принципе не поддерживает технологию BLE – такие терминалы не смогут принимать платежи, торговые точки с такими терминалами либо придётся исключить, либо заменить терминалы.

3. Адаптация платёжного ПО

Ещё один нюанс, касающийся терминальной сети – это большое количество разнообразных вендоров, присутствующих на Российском рынке (на текущий момент в РФ работает более 4 млн. POS-терминалов разных производителей, моделей и конфигураций). Более того, ранее технология Bluetooth не использовалась непосредственно для оплаты, а могла быть использована для неких вспомогательных нужд (например, для связи терминала с кассой). Поэтому потребуются усилия вендоров и эквайеров по доработке терминального программного обеспечения.

4. Клиентские устройства

Следующая задача - поддержать технологию на стороне клиентских устройств. Имея ограниченный набор устройств в виде модельного ряда iPhone, это относительно несложная задача, решаемая разработкой прикладного ПО (все модели iPhone поддерживают технологию BLE). Основной задачей в современных российских реалиях выглядит задача распространения приложения, с учётом сложностей попадания и закрепления приложения на долгий срок в AppStore.

Если будет необходимость добавить сервис клиентам, использующим смартфоны на базе Android OS, то здесь проблем не предвидится с т.з. аппаратной части и написания прикладного ПО (почти все современные android-телефоны поддерживаю BLE на аппаратном уровне, и на уровне операционной системы есть поддержка начиная с Android 4.3). Но могут возникнуть проблемы из-за большого количества производителей и моделей, связанных с особенностями работы BLE (разнообразие и диапазон качества реализаций может значительно отличаться от того, что есть у Apple). В данном случае необходимо будет провести масштабное исследование наиболее популярных моделей.

5. Интеграция с платёжными системами

На текущий момент существует 2 основных способа бесконтактной безналичной оплаты – по картам (или токенам) Мир или через Систему Быстрых Платежей (СБП). Соответственно, реализуя оплату по BLE желательно встроиться в существующие платежные системы, т.к. построение новой платежной системы – задача, требующая огромных ресурсов (человеческих, финансовых, административных). Поэтому, разрабатывая протокол обмена данными по BLE, необходимо, изменив транспорт данных (например с NFC на BLE), максимально сохранить формат данных и механизмы работы прежними, чтобы не пришлось переделывать протоколы и логику на уровне терминала, эквайера, платежной системы, эмитента.

6. Коллизии интерфейсов

Следующая задача - решить проблемы коллизий. О проблеме «случайной» оплаты на соседней кассе мы уже упомянули выше, но существует также потенциальная проблема конфликта двух интерфейсов BLE и NFC. В случае «российского» iPhone – оплата NFC находится в замороженном состоянии, поэтому проблема не должна возникать (за исключениям случая наличия у пользователя добавленной в Apple Pay карты зарубежного банка). Что касается Android – то теоретически такие коллизии возможны, и их разрешение можно попробовать реализовать как на стороне клиентского телефона (если используется единое приложение для оплаты по обоим интерфейсам), либо на стороне POS-терминала, разрешая одновременно ожидать оплату только по одной технологии: либо по BLE, либо по NFC.

7. Безопасность

И последний, особо чувствительный вопрос, который рассмотрим в рамках данной статьи – это вопрос безопасности. Ключевым отличием BLE- от NFC-платежей с т.з. потенциальных атак является увеличенный радиус действия BLE. Что даёт больший простор для фантазии и действий злоумышленников. Рассмотрим основные виды атак, которые можно попробовать реализовать на технологию BLE-оплаты.

Spam-атаки

Spam-атаки, не приводящие к финансовым потерям, но потенциально оказывающие некое негативное воздействие на сервис и на клиентский опыт. Теоретически, злоумышленники могут пытаться создавать эмуляторы POS-терминалов с более мощными Bluetooth-передатчиками и пробовать предлагать всем кто попадёт в радиус действия их устройств начинать оплату по BLE-каналу.

Вероятно, не получая, финансовый выгоды от подобных действий, такие атаки не будут иметь массовый характер, а могут быть скорее шалостями «хакеров-любителей».

Тем не менее есть способы защиты от таких атак – это, например, построение сети доверенных терминалов, или внедрение механизма, позволяющего достоверно отличить настоящий терминал, принадлежащий системе, от стороннего терминала. Таким механизмом может являться, например, построение PKI (Public Key Infrastructure)-инфраструктуры, заключающийся в загрузке цепочки сертификатов в каждый POS-терминал для того, чтобы клиентское устройство, перед тем как совершить оплату, могло запросить цепочку сертификатов и провалидировать её с помощью заранее загруженного в клиентское мобильное приложение корневого ключа удостоверяющего центра платежной системы.

Другой мерой защиты может являться предварительная проверка запроса на проведение транзакции по доверительным каналам на бэкенде платежной системы (некоторые платёжные системы, например СБП, позволяют реализовать такой механизм, т.к. запрос оплаты происходит непосредственно с клиентского мобильного приложения по доверенным каналам).

Relay-атаки в их различной реализации

Relay-атаки – это атаки, которые заключаются в том, что злоумышленник с помощью специального оборудования и программного обеспечения перенаправляет трафик платёжной транзакции с POS-терминала на котором он оплачивает свой товар/услугу на клиентское приложение «жертвы», и пытается оплатить свой товар за счёт платёжного инструмента «жертвы». О таких атаках шли разговоры и в рамках NFC-платежей и теоретически это тоже возможно, но с появлением BLE-платежей, злоумышленникам станет «удобнее» и проще проводить подобные атаки (если от них не защититься) как раз за счёт более дальнего действия BLE.

Мерами защиты и компенсации в данном случае может являться механизм подтверждения суммы транзакции и названия места платежа (магазина, предприятия) клиентом на экране своего смартфона.

Механизм определения расстояния и инициации платежа только при достижения малого расстояние также может сработать как защита, но его злоумышленники теоретически могут пытаться обойти, используя более мощные передатчики BLE-сигнала.

И ещё один механизм, который полностью бы избавил от риска relay-атак, но негативно бы сказался на клиентском опыте, это ввод PIN-онлайн на клавиатуре POS-терминала – механизм, используемый в классических карточных платежах.

Атаки Man-in-the-middle

Атаки Man-in-the-middle – ещё один класс атак, который заключается в том, что злоумышленник пытается вклиниться между платежным терминалом и клиентским устройством и поменять данные или часть данных. Данные атаки и способы противодействия им давно известны в платёжной индустрии и, введение нового транспорта данных в виде BLE, не вносит дополнительных рисков. Один из механизмов защиты – это криптографическая подпись чувствительных данных (в данном случае подмена данных будет раскрыта, и транзакция будет отклонена).

Replay-атаки

Replay-атаки – попытка злоумышленников перехватить данные транзакции, сделать их «слепок» и попробовать «впарить» их при проведении другой оплаты. Данный класс атак также давно известен в платежной индустрии и основным механизмом противодействия им является генерация терминалом уникального для транзакции случайного числа, а также ведением счётчика на клиентском устройстве, значение которого уникально для каждой последующей транзакции.

Из общих мер противодействия атакам в целом может быть предложено ограничение по применению BLE-платежей на организационном уровне. Например, исключить снятие наличных в ATM из возможных способов использования BLE, по причине особого интереса мошенников к получению наличных денег в местах отсутствия кассиров/операторов.

Заключение

В завершении хочется сказать, что внедрение BLE-платежей на Российском рынке выглядит вполне реализуемой, относительно недорогой (при условии максимального переиспользования существующей инфраструктуры и технологий) задачей, позволяющей удовлетворить спрос определенной категории клиентов. Будем наблюдать за развитием рынка и ожидать первых реализаций вероятно уже в этом году.