Технология защиты от угрозы подмены биометрического сканера

Технология защиты от угрозы подмены биометрического сканера

(Продолжение. Начало в №1/2019)

ИСПОЛЬЗОВАНИЕ БИОМЕТРИЧЕСКИХ ДАННЫХ В МОБИЛЬНОМ КАНАЛЕ

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

При использовании биометрии в банке в рамках мобильного приложения алгоритм действий таков. Камера телефона снимает видео клиента и отсылает в мобильное приложение (например, Сбербанк Онлайн). Мобильное приложение осуществляет предобработку изображения, в том числе контроль качества и проверку liveness detection[1], то есть контролирует, что камера снимает живого человека, а не манекен, фотографию или видеозапись. Затем оно выбирает наилучший кадр, полученный из видеопотока, и отправляет его на сервер для осуществления сравнения с хранящимся в базе данных шаблоном (Рис. 1).

Рисунок 1. Биометрический процесс в мобильном приложении

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

ПРОБЛЕМЫ БИОМЕТРИЧЕСКОГО ПРОЦЕССА

Сценарии атак можно разделить на две категории. Первая — это целенаправленная атака на клиента посредством предоставления биометрических данных без присутствия самого клиента. Для неё достаточно найти хорошую фотографию атакуемого в Интернете и отправить её в открытое API серверной части в обход проверок на liveness detection: например, такими средствами, как SoapUI[2] или Postman[3]. В случае регистрации мобильного приложения только по биометрии злоумышленник может зарегистрироваться от имени человека, изображённого на той самой фотографии, со всеми вытекающими из этого последствиями в виде несанкционированных переводов денежных средств.

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

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

Замечу, что в данной статье мы не будем рассматривать такую атаку, как модификация уже установленного мобильного приложения, например, при помощи вируса. Такая возможность обычно возникает при работе пользователя на устройстве под правами суперпользователя (root/jailbreak-устройство). Так может работать бот-сеть, которая выискивает рутованные устройства, модифицирует их, например, сохраняя на устройстве или в бот-сервере аутентификаторы пользователя и использует их с этого же устройства для вывода денег, но без интерактива с пользователем. Такую операцию можно провести и с паролем, и

с ПИН-кодом, и с биометрией, то есть любыми аутентификаторами, которые вводятся пользователем в мобильное приложение. Зарутовав устройство, пользователь принимает риски кражи денег на себя.

ОДИН МЕТОД АУТЕНТИФИКАЦИИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

При решении задачи аутентификации мобильного приложения необходимо создать механизм не только эффективный с точки зрения кибербезопасности, но и достаточно удобный для клиента. В качестве такого механизма было выбрано распределение ключей аутентификации приложения при помощи механизма отправки push-уведомлений, реализуемых соответствующими сервисами производителей мобильных операционных систем (Apple Push Notification Service (APNS), Google/Firebase Cloud Messaging (GCM, FCM)).

Вначале немного о технологии push-уведомления для мобильных устройств (Рис. 2).

Рисунок 2. Push-уведомления

Мобильное приложение вызывает функции операционной системы устройства для регистрации в push-сервисе. ОС транслирует этот запрос в push-сервис, предоставляя информацию о приложении (например, идентификатор, профайл) и устройстве. На основе этой информации push-сервис генерирует push-идентификатор — уникальный идентификатор, привязанный именно к данному экземпляру нашего мобильного приложения. Push-идентификатор получается мобильным приложением и передаётся на наш сервер для того, чтобы сервер мог отправить push-уведомление в любое время в адрес нашего приложения.

Что в этом процессе для нас существенно? Злоумышленнику сложно вклиниться в процесс push-уведомления. Генерация push-идентификатора — нативный процесс мобильной операционной системы и push-сервиса. Это взаимодействие защищено криптографически, а генерация push-уведомления происходит, как минимум, на основе идентификатора мобильной ОС (идентифицируется криптографически при помощи её закрытого ключа) и сущностей, идентифицирующих приложение. Получается, что сфальсифицировать push-идентификатор практически невозможно. А если его подменить? Дело в том, что push-идентификатор передаётся на серверную часть. Если его подменить в этот момент, например, на push-идентификатор другого приложения, push-уведомление облаком не будет отправлено. Дело в том, что при отправке push-уведомления в push-сервис наш сервер должен аутентифицироваться. В случае APNS — это криптографическая аутентификация при помощи закрытого/открытого ключей, а в случае GCM/FCM — обычный API-ключ, передающийся в каждом вызове. Самое главное в этой конструкции, что эти аутентификаторы могут быть выданы только разработчику приложения и привязаны к этому приложению. А это означает, что даже если push-идентификатор был подменён push-идентификатором другого приложения, то при отправке push-уведомления на адрес подменённого push-идентификатора push-сервис обнаружит, что push-идентификатор выдавался для другого приложения, и сообщит нашему серверу об ошибке несоответствия push-идентификатора и аутентификатора нашего сервера. Поэтому можно сделать вывод, что при помощи push-нотификации можно однозначно определить наше приложение. Для этого предлагается следующая схема взаимодействия (Рис. 3).

Рисунок 3. Схема создания аутентификатора мобильного приложения

По предлагаемой схеме вначале мобильное приложение получает push-идентификатор и генерирует пару — закрытый и открытый ключ (используемый алгоритм ассиметричной криптографии неважен). Далее открытый ключ передаётся приложением на сервер (по стандартному каналу взаимодействия приложения с сервером, обычно HTTP/HTTPS). Сервер генерирует случайное число и отсылает его в приложение в качестве push-уведомления. Приложение, получив push-уведомление, подписывает полученное значение своим закрытым ключом, подтверждая тем самым факт владения им, и отправляет его на сервер. Сервер вначале удостоверяется в корректности подписи пакета, используя открытый ключ приложения, а затем в совпадении случайного числа. Если проверки проходят успешно, то можно считать, что на клиентской стороне работает именно наше мобильное приложение, которое и владеет закрытым ключом. Собственно, закрытый ключ и является аутентификатором нашего мобильного приложения. Поэтому в дальнейшем все биометрические данные (фотографии) могут и должны подписываться на закрытом ключе мобильного приложения для подтверждения того, что они действительно сформированы нашим приложением Рис. 4).

Рисунок 4. Подтверждение биометрических данных закрытым ключом мобильного приложения

Размер push-уведомления в нашем случае небольшой, случайное число всегда меньше, чем максимальный размер полезной нагрузки (для APNS и FCM на текущий момент это 4 Кб[4]). Push-уведомление в данном случае является технологическим, и желательно, чтобы оно не отображалось пользователю.

В каждом из сервисов есть возможность сделать скрытое push-уведомление (silent push). Один из вариантов — убрать из полезной нагрузки push-уведомления тэг, сигнализирующий о необходимости отображения нотификации (для iOS это alert, а в Android — notification). Также нужно отметить, что для работы данной схемы необходимо разрешение пользователя на приём push-уведомлений. Причём необходимо такое разрешение только на время обмена ключами: как только произошло подтверждение закрытого ключа (аутентификатора), push-уведомления для приложения можно отключить (пользователь при желании может сделать это самостоятельно в настройках мобильной ОС). Заметим, что ни один из рассматриваемых сервисов push-уведомлений не предоставляет гарантию доставки нотификации в мобильное приложение. Например, недоставка может быть связана с отсутствием Интернета на мобильном устройстве, что приводит
к невозможности держать соединение с push-сервисом. Однако в данном случае наш процесс по подтверждению аутентификатора мобильного приложения предлагается запускать при соединении приложения с нашим сервером, а это означает, что доступ в Интернет у него есть. Как показывает практика, в этом случае доставляются практически все push-уведомления.

(Окончание в следующем номере)

[1] Описание некоторых методов liveness detection для лица можно посмотреть, например, здесь: https://arxiv.org/ftp/arxiv/papers/1405/1405.2227.pdf

[2] https://www.soapui.org/

[3] https://www.getpostman.com/

[4] https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html

https://firebase.google.com/docs/cloud-messaging/concept-options