Статья Павла Есакова для журнала PLUS: «RTS – новый подход к безопасности транзакций в Европе»

В 6-м выпуске журнала PLUS опубликована статья Павла Есакова, эксперта CSM по системам аутентификации, о новом стандарте для строгой аутентификации клиентов RTS SCA.

4 Сентября 2017

Европейская банковская ассоциация (European Banking Authority, EBA) 23 февраля 2017 года опубликовала долгожданную финальную версию RTS SCA – стандарта (Regulatory Technical Standard – RTS) для строгой аутентификации клиентов (Strong Customer Authentication – SCA), являющейся составной частью Второй платежной Директивы – PSD2 (Payment Services Directive).

Предыстория стандарта

В 2013 году форум SecuRe Pay Европейского центрального банка опубликовал «Рекомендации по безопасности платежей в Интернете». Практически одновременно был опубликован и проект «Рекомендаций по безопасности мобильных платежей». На основании вышеупомянутых документов EBA перевыпустил документ под названием «Рекомендации по безопасности интернет-платежей (финальная версия)», и с 1 августа 2015 года большинство европейских стран руководствовалось этим документом для обеспечения безопасности в системах дистанционного банковского обслуживания. Дальнейшего развития вышеупомянутые документы не получили, поскольку в ноябре того же года Совет Европы принял Вторую платежную Директиву, известную под аббревиатурой PSD2, которая существенно меняет роль и место банков в мире платежей.

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

Так, Вторая платежная директива предполагает наличие операторов информационных услуг (Account Information Service Provider – AISP) и операторов инициализации платежей (Payment Initiation Service Provider – PISP). Задача первых – обеспечить информацию о счетах клиента в привычных нам банках, выполняя роль агрегатора: теперь клиенту не нужно будет обращаться ко всем своим банкам с тем, чтобы получить о состоянии счета (счетов).

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

При этом ни первые, ни вторые не имеют возможности проводить платежи – эта роль по-прежнему отводится банкам, которые в директиве PSD2 определены как Account Servicing Payment Service Provider – ASPSP. Но при этом именно банки обязаны обеспечить для вышеуказанных операторов беспрепятственный доступ к счетам через программный интерфейс, не требуя от данных организаций заключения коммерческого контракта.

Одним из ключевых элементов PSD2 в соответствии со статьей 98 является поручение к EBA конкретизировать требования к строгой аутентификации клиентов. В соответствии с поручением в августе 2015 года была опубликована первая редакция регулирующего стандарта (RTS SCA), которая в целом была основана на предшествующих рекомендациях. После многочисленных обращений от участников платежного рынка EBA опубликовала окончательную версию стандарта 23 февраля 2017 года, с задержкой более чем на 1,5 месяца относительно запланированной даты.

Стандарт был направлен в Европарламент и Совет Европы, где после утверждения он будет опубликован в официальном журнале1 Европейского союза. Через 18 месяцев после публикации документ вступает в силу, что предположительно приведет стандарт в действие на территории ЕС не раньше ноября 2018 года.

Базовые требования к системам строгой аутентификации клиентов

Статья 97 PSD2 требует от платежных операторов (Payment Service Providers) обеспечивать строгую аутентификацию клиентов в тех случаях, если пользователь получает доступ к платежному счету, производит перевод денежных средств или выполняет любую другую операцию с использованием системы дистанционного доступа, если данная операция может привести к выполнению мошеннических действий.

Базовое определение «строгой аутентификации клиентов» приводится в статье 4 (30) директивы PSD2. В соответствии с данной статьей определяется, что аутентификация должна базироваться на использовании двух и более возможных аутентификационных факторов. В качестве аутентификационных факторов могут использоваться:

  • Фактор знания – то, что известно только пользователю (пароль, ПИН-код)
  • Фактор владения – то, что имеется только у пользователя (ИД смарт-карта, например, электронное удостоверение личности), платежная карта, токен)
  • Биометрический фактор – то, что присуще пользователю от рождения (отпечаток пальца, рисунок радужной оболочки глаза, лицо)

В случае совершения платежной транзакции создаваемый код подтверждения должен быть однозначно связан как минимум со следующими данными: суммой транзакции и получателем платежа.

Это означает, что любое изменение этих параметров транзакции должно изменять значение создаваемого кода подтверждения.

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

Важным требованием является и приведенное в статье 2 RTS положение о том, что данные платежной транзакции должны быть защищены на всех этапах аутентификации:

1. Платежные операторы должны принять меры по обеспечению конфиденциальности, целостности и аутентичности нижеперечисленных данных:

  • сумма транзакции
  • получатель платежа

2. Платежные операторы должны предоставить плательщику информацию о сумме и получателе платежа на всех этапах аутентификации

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

Особое внимание необходимо проявлять в том случае, когда инициализация транзакции и формирование кода подтверждения происходят на одном и том же устройстве, но используют разные приложения. В этом случае должен быть обеспечен защищенный обмен сообщениями между приложениями с выполнением указанного условия «подписываю то, что вижу». При этом аутентификационное приложение должно иметь средства, препятствующие вмешательству в его работу. Естественно, что аналогичные средства, исключающие вмешательство в работу единого приложения (банковское/ аутентификационное), должны применяться в обязательном порядке.

Очевидно, что применение требований статьи 2 RTS для случая использования механизма аутентификации «Out-Of-Band» (в случае использования канала SMS) приводит к необходимости передавать защищаемые параметры транзакции, но требование обеспечить конфиденциальность этих данных одновременно подразумевает шифрование используемого канала, что может вступать в противоречие с законодательством о связи.

Защита от клонирования «фактора владения»

Статья 7 RTS определяет требования к защите от клонирования аутентификационного фактора, связанного с владением (ИД смарт-карта, платежная карта, токен). Если для аппаратных устройств, например генераторов одноразовых паролей и платежных карт, данное требование выполняется сравнительно легко, то для программных решений, особенно для мобильных устройств, клонирование остается серьезной угрозой, поскольку легко осуществимо. Для того чтобы избежать появления копий, регулятор требует применения в обязательном порядке специальных мер.

Простейшим вариантом считается включение параметров мобильного устройства, например идентификатора IMEI или других признаков устройства, в процесс формирования кодов подтверждения. Более продвинутые меры используют защиту аутентификационного приложения с помощью шифрования данных, используемых для генерации кодов подтверждения, с помощью ПИН-кода (пароля). Наиболее безопасным методом защиты следует считать размещение криптографических параметров аутентификационного приложения в элементе безопасности (secure element) мобильного телефона – последнее предполагает наличие в телефоне поддержки технологии NFC.

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

Необходимо отметить, что если в начальной версии стандарта требовалась аппаратная реализация доверенной среды в мобильном устройстве (trusted execution environment), то его окончательная версия допускает использование защищенной программной среды (secure execution environment), реализуемой в наиболее популярных операционных системах Android и iOS с помощью программных механизмов (sandbox). Но использование «песочниц» требует мер по контролю того, что операционная система телефона свободна от root/jailbreak2. Для дальнейшего повышения защищенности мобильных платформ предлагается использовать технологию RASP (runtime application self protection), которая позволяет определить, что приложение запущено на виртуальной машине или эмуляторе мобильного телефона.

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

В стандарте также предусмотрено использование в обязательном порядке механизма оценки риска транзакций (Transaction Risk Analysis – TRA) и прописаны зоны ответственности участников платежного рынка за возможные финансовые потери. При этом механизмы оценки риска используются не только для сокращения потерь, но и для исключения необходимости подтверждения определенных типов операций.

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

Поскольку стандарт является технологически нейтральным и не предполагает какой-либо бизнес-модели, то такой стандарт не потребует внесения частых корректив.

В результате европейский банковский рынок получит в ближайшее время обязательный для исполнения стандарт, который на ближайшие несколько лет определит механизмы аутентификации пользователей в системах дистанционного управления счетом. Причем определит их не только для банков, но и для новых игроков платежного рынка: операторов информационных услуг (Account Information Service Provider – AISP) и операторов инициализации платежей (Payment Initiation Service Provider – PISP), что существенно увеличит возможности для новых игроков на банковском рынке.

1 «Official Journal of the European Union»

2 Root и jailbreak – получение полных административных прав на устройстве путем установки специально написанных программ, после чего сторонние программы могут выполнять манипуляции, изначально для них недоступные благодаря ограничениям производителя, – например, управлять частотой процессора или переписывать системные файлы, а также устанавливать полномасштабное шпионское ПО.