В статье рассмотрены вопросы внедрения технологии доверенных устройств подтверждения в ДБО юридических лиц.
Автор: Максим Федотенко
В настоящее время существует достаточно большое количество классификаций атак на интернет-банки с различными подходами и исходя из различных целей. В качестве примера можно привести классификацию, данную в [1]:
Рисунок 1. Классификация атак на интернет-банки
Основное кол-во случаев мошенничества в системах интернет-банкинга приходится на мошенничество при помощи вредоносного программного обеспечения, социальной инженерии и фишинговых атак. Причем если по прогнозу [2] масштабы использование программного обеспечения (троянов) на компьютерах в России постепенно будут уменьшаться, то использование троянов на платформе Android будет только расти. Одновременно российские вирусописатели для компьютеров будут все больше ориентироваться на западные банки [2], а фишинговые атаки будут автоматизироваться [2].
Что же касается социальной инженерии и фишинговых атак – атак, когда злоумышленники пытаются заставить клиента неосознанно разгласить основные реквизиты, позволяющие аутентифицировать мошенническую операцию, то такие атаки являются трендом в интернет-банке для физических лиц.
В большинстве случаев перечисленные атаки являются направленными (Advanced Persistent Threat, APT), т.е. атаками, целью которых становится конкретный интернет-банк, а иногда и конкретные клиенты. Злоумышленники при помощи различных методов устанавливают на компьютер клиента троян, который вместо клиента формирует платежные поручения или подменяет в нем реквизиты платежа.
Обычно трояны имеет несколько функциональных возможностей (см. Рисунок 2):
Рисунок 2 . Функциональные возможности троянов
Далее приводится несколько примеров программ-троянов для осуществления таких атак. Согласно отчету [3] их активно использовали различные преступные группировки для осуществления атак в 2016 году.
Троян ProxyAdder осуществляет изменение настроек браузеров для перенаправления соединений браузера на определенный proxy-сервер. Он также устанавливает свой сертификат безопасности на компьютере жертвы в доверенные корневые. В начале 2016 года была зафиксирована атака на клиентов Сбербанка, а позже – ВТБ24 и Русский Стандарт.
Троян RTM появился в конце 2015 года. Для распространения трояна используются связки эксплойтов Beps, Angler, RIG. Он нацелен на такие банки как Сбербанк, ВТБ24, Райфайзен и некоторые другие. Троян является модульным, его модули подменяют реквизиты, считывают нажатия клавиатуры, подменяют DNS-сервера и сертификаты безопасности, осуществляют снимки экрана и т.п.
Также в 2016 году были зафиксированы [3] инциденты с троянами для компьютеров Jupiter (aka Bolek), Buhtrap, Ranbyus. А совсем недавно была ликвидирована преступная группировка Lurk, использующая одноименный троян для хищений в интернет-банках [4]. Этот троян также использовал модули, которые осуществляли “автозалив” (внедрение инжектов в браузере пользователя), подмену java-классов оригинального java-апплета, а также удаленное управление компьютером на базе VNC. Все эти методы использовались в том числе для подмены реквизитов платежных документов клиента. Более подробно с работой Lurk можно ознакомиться в [5].
Защитить клиента, например, от подмены реквизитов платежа, банк может при помощи аутентификации транзакции по другому (out-of-band) каналу. Обычно такая защита осуществляется банками при помощи SMS-сообщений, отправляемых на мобильный телефон клиента. При этом на телефон клиента высылается SMS-сообщение с деталями транзакциями и одноразовым кодом для ее подтверждения.
Также банки могут применять системы антифрода, которые также имеют возможности по борьбе с таким видом мошенничества.
Как говорилось выше, в случае использования дополнительного подтверждения реквизитов платежной транзакции с использованием SMS-сообщений банк отправляет через сотового оператора, а возможно, и агрегаторов на мобильный телефон клиента SMS-сообщение с реквизитами платежа. Клиент должен их проверить и ввести одноразовый код, находящийся в этом же сообщении, в интерфейсе интернет-банка для подтверждения транзакции.
Однако при таком подтверждении возникают следующие проблемы и угрозы:
Рисунок 3. APT-атака на интернет-банк с модификацией SMS (Красным цветом выделены мошеннические операции)
Рисунок 4. APT-атака на интернет-банк с заменой SIM-карты (Красным цветом выделены мошеннические операции)
Использование SMS-сообщений признано не вполне безопасным даже на уровне Правительства РФ [8]. Однако методы предлагаемые Минкомсвязи – использование аппаратных или программных генераторов одноразовых паролей на основе времени (Time-based One-time Password Algorithm - RFC 6238 https://tools.ietf.org/html/rfc6238), не могут в полной мере защитить от атак с подменой реквизитов, т.к. в них отсутствует возможность подтвердить реквизиты платежа. Данный способ подтверждает только личность пользователя при аутентификации и может применяться для аутентификации пользователей в таких системах как ЕСИА (Единая система идентификации и аутентификации. https://esia.gosuslugi.ru/).
Многие банки применяют системы антифрода для защиты клиентов от мошенничества. В этом случае банк на основании некоторых знаниях о предыдущих операциях клиента, в целом клиентской массы, черных списков и т.п. пытается понять насколько велик риск мошенничества по данной операции.
Обычно системы антифрода предоставляют решения по аналитике конкретно от атак на клиента при помощи троянов. Например, система антифрода RSA Adaptive Authentication для контроля троянов в браузере клиента предоставляет javascript “rsa.js”, который запускается на странице интернет-банка в браузере пользователя и контролирует его работу. Скрипт собирает и передает в систему антифрода следующую информацию:
5 .Схемы работы скрипта системы антифрода RSA Adaptive Authentication
Далее система антифрода RSA Adaptive Authentication на основе своей статистики и черных списков пытается определить вероятность наличия трояна на компьютере клиента. К сожалению, на данный момент даже сам вендор признал неэфективность большинства перечисленных механизмов для определения троянов на компьютере клиента интернет-банка.
Существуют и другие системы защиты от троянов, например, Group-IB Bot-Trek Secure Bank, IBM Trusteer, Kaspersky Fraud Prevention, эффективность которых возможно выше вследствие большей направленности именно на подобный сегмент атак, однако они также не являются полной панацеей.
На данный момент можно заметить намечающийся тренд в обеспечении безопасности платежей в интернет-банке – это использование доверенных сред. Под доверенным средами понимается:
Первый путь предполагает использование, например, мобильного антивируса, виртуальных машин или использование элементов безопасности (Secure Element). Очевидно, что использование мобильного антивируса не может организовать полностью доверенного окружения, хотя бы даже на примере использования антивирусов на персональных компьютерах, которые уже давно не дают высокой степени уверенности, что компьютер не заражен. Zero-day атаки антивирусы в основном не распознают даже с использованием эвристических механизмов. Работа виртуальных машин внутри мобильного устройства сильно нагружает само устройство, да и также не дает уверенности в защите. Использование элементов безопасности в мобильном устройстве или на SIM-карте в целом достаточно перспективное направление. К сожалению, доступ к элементам безопасности для стороннего программного обеспечения в платформе Apple iOS закрыт, поэтому в таких решениях используются устройства с операционной системой Android. При этом в элементе безопасности может храниться ключ аутентификации клиента и он будет подтверждать при помощи него операции. Такую технологию постепенно внедряется, например, Мегафон [9]. Однако в среде Android данная технология имеет свои уязвимости, которые может свести на нет использование элементов безопасности.
Поэтому для клиентов интернет-банка – юридических лиц, интересной выглядит тенденция использования специализированных защищенных устройств, которые вначале могут использоваться только для аутентификации пользователя и подтверждения операций в интернет-банке, а затем расширить свою функциональность.
В настоящий момент многие банки в интернет-банке юридических лиц используют доверенные устройства – токены. Под термином “токены” мы понимаем программно-аппаратные устройства для неизвлекаемого хранения криптографических ключей пользователей и осуществлений криптографических операций при помощи ключей пользователей после их аутентификации.
При работе с токенами необходимо понимать, что они используются для криптографической защиты операций (возможно, и шифрования канала от пользователя до интернет-банка), но никак не защищают от перечисленных выше атак на клиента при помощи троянов. Очевидно, что без использования дополнительного канала подтверждения, данные, передаваемые на токен для подписания, могут быть подменены трояном, внедренным на компьютер клиента злоумышленником (см. Рисунок 6).
6 . Атака на интернет-банк с токеном при помощи трояна
Таким образом, для защиты клиентов, которые работают с токеном, все равно приходится осуществлять подтверждение платежных операций по другому каналу (например, теми же самыми SMS-сообщениями). Общепринятая практика при этом – использование списка доверенных контрагентов или списка шаблонов. Т.е. клиент один раз подтверждает при помощи SMS-сообщения реквизиты контрагента или шаблон в качестве доверенного, а затем все платежные поручения, созданные в адрес подтвержденного контрагента или с использованием доверенного шаблона, принимаются интернет-банком подписанные токеном без использования дополнительного подтверждения.
При использовании описанной выше схеме мы все равно создаем неудобства для клиента, заставляя его работать по другому каналу. Поэтому для того, чтобы легко и быстро подписывать платежные поручения в интернет-банке и быть защищенным от атак злоумышленника уже достаточно давно был предложен на рынке токен с экраном, реализующий концепцию доверенного устройства.
Концепция токена с экраном сводится к тому, что токен является устройством с доверенной средой и непосредственно при каждом подписании визуализирует подписываемый документ. Документ отображается на экране и при подтверждении клиентом корректности реквизитов осуществляется подпись непосредственно на самом устройстве.
Токены с экраном в настоящий момент производятся такими фирмами как, например, Рутокен (Рутокен PINPad), SafeTech (SafeTouch), Инфокрипт. Все они имеют USB-интерфейс для получения документов на подпись. Кроме этого, можно сказать еще, например, об устройствах, использующих оптический интерфейс, например, SafeNet eToken 3500 или AGSES-карты. Все он реализуют концепцию доверенного устройства, но с разными каналами взаимодействия.
Устройства обеспечивают двухфакторную аутентификацию – пользователю необходимо обладать устройством и знать PIN-код. Ввод PIN-кода происходит на сенсорном экране устройства в доверенной среде, что обеспечивает дополнительную защиту от мошенничества.
Токен с экраном также используется для удовлетворения требованиям 63-ФЗ “Об электронной подписи” в части необходимости подтверждения платежей с отображением подписываемой платежной информации.
Далее в статье будет описан один из вариантов встраивания токенов с экраном в Интернет-банк юридических лиц.
Как сказано выше, встраивание в интернет-банк токена с экраном обусловлено повышением удобства пользователя и существенным снижением рисков мошенничества уменьшением затрат банка на работу с сотовыми операторами (как по отправке SMS-сообщений, так и по проверке IMSI и т.п.). При этом нужно осознавать, что стоимость токена с экраном существенно выше, и далеко не каждый клиент захочет его приобретать и использовать, поэтому банк должен давать возможность клиенту использовать данное устройство, но не ограничивает клиента в выборе обычных токенов или SMS-сообщений для аутентификации.
При внедрении токенов с экраном стоит задача интеграции его с уже существующей инфраструктурой Интернет-банка. При этом желательно исходить из принципа минимальных изменений системы и неизменности текущей логики работы системы.
В Интернет-банке на токен подается некоторая форматированная структура – набор информации о документе, который будет подписываться. Токен с экраном должен понимать каким именно образом визуализировать подписываемый документ. Очевидно, что хранить логику визуализации в самом токене бессмысленно. Токену не хватит ресурсов, а с появлением нового типа документа придется его перепрошивать. Поэтому логика визуализации должна быть или отражена в самой подписываемой структуре документа или подаваться на токен при подписании вместе с этой структурой.
Первый случай, например, реализуется Рутокен PINPad, который предлагает в структуре документа, подаваемого на токен, указывать дополнительные атрибуты визуализации. Параметры визуализации при этом примитивны – указывается является ли отображаемая сущность полем или значением и в зависимости от этого сущность визуализируется в левом или правом столбце. Также возможно пометить сущность как неотображаемую.
<!PINPADFILE RU>
<!>невидимый текст
<N>ФИО:<V>Петров Петр Петрович Москва, Пионерская ул, д. 3, кв. 72
<N>Перевод со счета:<V>42301810001000075212
<N>Сумма:<V>150000
<N>Валюта:<V>RUR
<N>Наименование получателя:<V>Иванова Елена Ивановна
<N>Номер счета получателя:<V>40817810338295201618
<N>БИК банка получателя:<V>044525225
<N>Наименование банка получателя:<V>ОАО 'БАНК ДЕМО' Г. МОСКВА
<N>Номер счета банка получателя:<V>30101810400000000225
<N>Назначение платежа:<V>перевод личных средств
Обычно намного сложнее изменять структуру подаваемых на токен документов, нежели ввести дополнительную сущность – шаблоны обработки, которые подаются на токен вместе с документом. К тому же в случае указания атрибутов визуализации в структуре документа троян может их изменить до подписания и критические поля документа не будут выведены на экран устройства. (Очевидно, что существуют механизмы проверки правильности атрибутов визуализации, но не на токене, а уже на серверной стороне интернет-банка.)
По сути, шаблон обработки является некоторым набором команд токену, как обработать пришедший к нему документ. В том числе использовать ли визуализацию, надо ли подтверждать нажатием кнопки и т.п. Если в шаблоне эти действия не отражены или шаблон отсутствует, то токен осуществляет подписание с действиями, заданными по умолчанию.
Например, в нашем случае структура документа выглядит следующим образом:
ATTRIBUTES:
GlobalID=b5b509cd-7ff0-4599-b2dd-15083828d0f4
DocType=PayDocRu
DocTypeVersion=2.0
FIELDS:
DocInfo.DocDate=2016-06-06 00:00:00.0
DocInfo.DocNumber=7
DocInfo.DocSum=654.00
PaymentInfo.Destination=ВтомчислеНДС 18 % - 99.76
PaymentInfo.NDS=99.76
PaymentInfo.OperationType=01
PaymentInfo.Payer.BankAccount=30101810100000000716
PaymentInfo.Payer.BankBIC=044525716
PaymentInfo.Payer.BankName=ПАО "ВТБ 24"
PaymentInfo.Payer.OrgINN=2323121234
PaymentInfo.Payer.OrgName=ОООТестКлиент
PaymentInfo.Receiver.BankAccount=30101810400000000225
PaymentInfo.Receiver.BankBIC=044525225
PaymentInfo.Receiver.BankName=ПАО "СБЕРБАНКРОССИИ"
PaymentInfo.Receiver.OrgAccount=40702810200000000001
PaymentInfo.Receiver.OrgINN=1212121212
PaymentInfo.Receiver.OrgName=ООО "ООПРР"
В заголовке (ATTRIBUTES) присутствуют такие поля как тип документа (DocType), версия структуры документа и т.п. В полях (FIELDS) записываются такие данные о документе, как его название, номер, счет плательщика, счет получателя, сумма и т.п.
Для каждого типа документа в Интернет-банке хранится шаблон обработки. Шаблон обработки представляет собой XML-структуру, которая определяет атрибуты, связанные с обработкой и подписанием документа, а именно:
Рассмотрим пример шаблона.
<?xml version='1.0' encoding='UTF-8'?>
<Template name="PayDocRu.for_pay" version='1.0' date="06.06.2016">
<Header>
<ObjType>Document</ObjType>
<DocType>PayDocRu</DocType>
<Sign>
<Channel>Token</Channel>
<SubChannel>HTTP</SubChannel>
<Type>Single</Type>
<Confirm>Default</Confirm>
</Sign>
</Header>
<Body>
<Style1 ForeColor="F08020" Font="Sans" Width='40' XBefore='8' XAfter='4' YBefore='2' YAfter='120' Wrap='Off' />
<Origin ForeColor='F08020' BgColor='A0B0C0' Font='Serif' FontSize='5' Style='1'/>
<Single Style='1'>
<Field Order="1">"РПП №"</Field>
<Field Order="1" Col="2">DocInfo.DocNumber</Field>
<Field Order="2">"Получатель"</Field>
<Field Order="2" Col="2">PaymentInfo.Receiver.OrgName</Field>
<Field Order="3">"Счет"</Field>
<Field Order="3" Col="2">PaymentInfo.Receiver.OrgAccount</Field>
</Single>
</Body>
</Template>
Шаблон имеет атрибуты – название, версия и дата шаблона, и состоит из обязательных разделов – “Header” и “Body”.
В заголовке шаблона указывается информация о том, для чего предназначен шаблон:
Задавая значения данных параметров, можно указать токену в каком случае можно использовать данный шаблон. Например, только если значение DocType в шаблоне соответствует типу подаваемого на токен документа (поле DocType документа). Также можно определить для какого типа визуализировать документ, а для какого нет (если подписание документа не несет рисков мошенничества, то визуализировать его и не нужно).
В теле шаблона указывается какие атрибуты документа отображать пользователю на экране и каким образом. Любые сущности могут быть отражены в любом из столбцов, причем столбцов может быть не 2, а три или четыре, главное, чтобы все они могли быть адекватно отражены на экране токена. В формате шаблона предусмотрены подразделы, отвечающие за отображение атрибутов единичного документа (Single) и атрибутов в случае пакетного подписания (Packet). При помощи отдельных атрибутов тегов в каждом из этих подразделов мы можем настроить используемые типы и размеры шрифтов, а также цвета.
Технология шаблонов предусматривает возможность использования пакетной подписи для массового подписания документов. Мошенничество с некоторыми видами платежных документов происходит очень редко или вообще не происходит, поэтому их подтверждение можно осуществлять совокупно. При пакетном подтверждении на экране токена выводится некоторая агрегированная информация о подписываемых документах и одним нажатием пользователь может подписать сразу все документы пакета.
Агрегированная информация, отображаемая пользователю на экране токена, не получается токеном из интернет-банка, а рассчитывается им самостоятельно исходя из содержимого подписываемых документов пакета. В шаблонах присутствуют функции вычисления количества платежных документов, общей суммы и среднего. Для этого в них введен специальный раздел Packet. Пример такого шаблона показан ниже.
<?xml version='1.0' encoding='UTF-8'?>
<Template name="PayDocRu.for_pay.Packet" version='1.0' date="06.06.2016">
<Header>
<ObjType>Document</ObjType>
<DocType>PayDocRu</DocType>
<Sign>
<Channel>Token</Channel>
<SubChannel>HTTP</SubChannel>
<Type>Packet</Type>
<Confirm>Default</Confirm>
</Sign>
</Header>
<Body>
<Style1 ForeColor="F08020" Font="Sans" Width='40' XBefore='8' XAfter='4' YBefore='2' YAfter='120' Wrap='Off' />
<Origin ForeColor='F08020' BgColor='A0B0C0' Font='Serif' FontSize='5' Style='1'/>
<Single Style='1'>
<Field Order=1>”№ ”</Field>
<Field Order=1 Col=2>DocNumber</Field>
<Field Order=2>”Сумма”</Field>
<Field Order=2 Col=2>DocSum</Field>
</Single>
<Packet>
<Field Order=1>”Платежные поручения”</Field>
<Field Order=2>”Кол-во: ”$num</Field>
<Field Order=3>”Сумма: ”$sum</Field>
</Packet>
</Body>
</Template>
В приведенном примере на экране токена отразится агрегированная информация обо всех подписываемых платежных поручениях – общее количество и общая сумма, а далее будет выведена усеченная (относительно предыдущего примера) информация о каждом из документов – номер документа и его сумма. Пользователь может прокрутить выведенную информацию и нажать на кнопку подтверждения или отмены, если не согласен. При этом если при пакетном подписании не использовать подраздел Single, то на экран токена будет выведена только агрегированная информация по пакету документов без подробной информации по каждому документу.
Как говорилось выше для формирования подписи на токен с экраном необходимо подать не только структуру документа, но и шаблон. В некоторых случаях шаблон может быть не подан, тогда токен осуществляет действия по умолчанию, т.е. выводит информацию о платеже на экран в “сыром” формате и просит подтвердить подписание нажатием соответствующей кнопки.
Для того чтобы злоумышленник не мог использовать свой шаблон, который, например, не выводит реквизита документа, который он подменил, все шаблоны должны подписываться банковской подписью. Подпись под шаблоном токен в обязательном порядке должен проверять. Актуальность же используемого шаблона должен контролировать сам интернет-банк на основе версий шаблонов.
При подписании интернет-банк ищет в своем хранилище подписанный шаблон, соответствующий условиям подписания, т.е. типу подписываемого документа, устройству подписания и виду подписания (единичный документ или пакет. Здесь опускаются другие подробности, например, поиск последней версии шаблона, проверку подписи, активность и историчность шаблонов и т.п.). Вне зависимости от того шаблон найден или нет, интернет-банк вызывает функцию токена, на вход которой подается шаблон (при наличии), кол-во подписываемых документов и, собственно, сами документы. При этом сам Интернет-банк должен контролировать, что шаблон подходит для всех документов, поданных на подписание, иначе токен вернет ошибку.
Для корректной работы экранной технологии подпись документа должна включать дополнительные атрибуты, содержащие информацию о том, как подписывался документ. При этом используется технология Cryptographic Message Syntax (CMS) или PKCS7. Подпись формируется в формате отсоединенного CMS с набором подписанных атрибутов. Однако можно использовать, например, и XML Signature.
При подписании документа токен анализирует поданный на него шаблон и выводит на экран документ в соответствии с правилами, о которых говорилось в предыдущем разделе. В случае пакетного подписания агрегацию документов токен производит самостоятельно. Т.е. такие данные как сумму всех поданных в пакете документов, кол-во или среднее значение он умеет высчитывать самостоятельно. Таким образом, даже при пакетной подписи агрегированную информацию троян подменить не может.
При подписании токен проверяет, что полученный шаблон соответствует типу подписываемых документов, что он предназначен для подписи при помощи именно токена, а также что в случае единичного подписания используется шаблон предназначенный для единичного подписания, а в случае пакетного подписания – для пакетного.
Токен проверяет подпись шаблона (в соответствии со стандартом X.509) и, тот факт, что шаблон подписан сертификатом банка. Далее если в шаблоне указана необходимость (тег Confirm) токен визуализирует документ или пакет документов. Если же в шаблоне явно указано, что визуализировать не нужно, то токен с экраном не будет визуализировать документ и без подтверждения подписывает документ. Такая логика реализована специально, чтобы показывать на экране только документы, подверженные высокому риску мошенничества.
Если же шаблон не подан, то токен с экраном производит действие по умолчанию, т.е. визуализацию. При этом пакетная подпись не осуществляется, а все документы подписываются по очереди.
При подписании пакета документов возникает проблема, связанная с ограниченностью памяти токена. Очевидно, что токен перед тем как ответить CMS-конвертами подписей, должен накопить информацию о них у себя в памяти. Память токена естественно конечна. При подаче большого количества документов возникнет ошибка. Рассчитать сразу примерное количество документов, которые может подписать токен, невозможно хотя бы по той причине, что все документы разного размера. В процессе обсуждения был выбран следующий вариант: при подписании токен в случае превышения размера памяти возвращает ошибку и количество документов, которые он готов принять из всех подписываемых. После этого интернет-банк делит пакет на два и снова пытается подписать как отдельные пакеты.
Как указывалось ранее токен подписывает документы, формируя CMS-конверты отсоединенной подписи. При этом в конверте содержится вся необходимая информация, определяемая стандартом RFC 5652 (указание на сертификат, при помощи которого подписывался документ, или сам сертификат/цепочка сертификатов, алгоритм и значение подписи, стандартные подписываемые атрибуты). Также в CMS-конверт введены дополнительные подписываемые атрибуты:
Эти атрибуты проверяются в интернет-банке при получении банком подписанного документа и отправки его на исполнение.
Самое интересное начинается при проверке подписи документа в Интернет-банке. Необходимо кроме стандартной проверки математического совпадения подписи, проверки по CRL и т.п. (в соответствии со стандартом X.509), проверить, что документ подписывался нужным шаблоном и именно так как написано в шаблоне. Логика такой проверки приведена на следующем рисунке. Эта логика предполагает, что мы уже проверили подпись в соответствии с X.509 и она является верной.
Рисунок 7. Процесс проверки подписи документа
В начале интернет-банк должен проверить на основе данных подписанных атрибутов, что документ подписан токеном и этот токен принадлежит именно клиенту, от имени которого установлена сессия с интернет-банком. Далее он смотрит на значение хеш-функции шаблона, которое находится в подписанных атрибутах CMS-конверта подписи. Если значение не присутствует, то интернет-банк проверяет по своей базе данных необходимость использования шаблона для данного документа. В случае если шаблон не нужен, то проверяет был ли при подтверждении задействован тот тип подтверждения документа, который установлен по умолчанию для токена с экраном (это визуализация и нажатие на кнопку). Если да, то подпись верна. Если же нет или необходимо использовать шаблон, то считает, что данное действие выполнял мошенник и отвергает такое подписание.
Если же значение хеш-функции присутствует в подписанных атрибутах, то интернет-банк пытается в своей базе данных по хеш-функции шаблона найти активный шаблон для этого типа документа. Если шаблон не найден, то подпись неверна, т.к. подпись осуществлялась при помощи несанкционированного или устаревшего шаблона. Если же шаблон найден, то интернет-банк определяет является ли используемый при подписании шаблон актуальным для данного типа документа. Очевидно, что в таких каналах интернет-банка, как Толстый клиент, синхронизация используемых шаблонов может производиться с некоторой задержкой, поэтому используется не только активный шаблон, но и предыдущий шаблон, но только определенное время.
Далее проверяется тип подтверждения, указанный в подписываемых атрибутах. Если он соответствует запрашиваемому шаблоном подтверждению, то подпись может считаться верной после прохождения проверки на пакетное подписание.
В конце осуществляется проверка на возможность пакетного подписания. Если в подписываемых атрибутах было заявлено, что документ подписывался пакетно, а активный шаблон запрещает это делать, то подпись также считается недействительной.
Так в общем чертах выглядит процесс проверки подписи токеном с экраном интернет-банком.
В заключении раздела, посвященному интеграции токена с экраном с системой интернет-банка, рассмотрим общий процесс его работы с интернет-банком (см. Рисунок 8 ).
Рисунок 8 . Процесс подписания документа в Интернет-банке токеном с экраном с использованием браузера
(1) Клиент формирует в интернет-банке платежный документ, (2) документ отправляется в банк. Затем (3) банк формирует дайджест документа и вместе с ним передает шаблон, привязанный к данному типу документа, и (4) отправляет их на токен клиента. (5) Токен визуализирует клиенту на экране документ и запрашивает подтверждение. (6) После акцепта токен (7) подписывает документ и (8) отсылает подпись в формате CMS-конверта в интернет-банк на банк. (9) После этого происходит процесс проверки подписи и соответствия подписываемых атрибутов, описанный чуть выше.
Как говорилось в разделе 2.2 банки используют системы антифрода для выявления мошеннических действий. В случае использования токена с экраном, как и любых доверенных сред, риск мошеннических действий от имени пользователя становится минимальным.
При использовании подписи документов в CMS-конверте с подписанными атрибутами, определяющими в том числе тип токена, который использовался для подписи, можно однозначно сказать, что использовался токен с экраном. В этом случае информация об этом может передаваться в антифрод вместе с транзакцией и для нее могут использоваться более мягкие правила. Такие операции очень редко нуждаются в дополнительном контроле.
Дополнительный контроль в системах антифрода обычно реализуется звонком клиенту (или клиент должен перезвонить) для уточнения банком, что данную операцию проводил именно клиент, а не мошенник. В случае использования токена с экраном у антифрода появляется новый путь осуществления дополнительного контроля. Например, если в организации-клиенте ДБО несколько обычных пользователей (с обычными токенами или подписывающие операции при помощи SMS-сообщений) и один, обладающий токен с экраном, то платежные поручения, подписанные обычными пользователями и по каким-то причинам признанными антифродом подозрительными, могут отправляться на дополнительный контроль пользователю, имеющему токен с экраном. Таким образом, не нужно будет производить отзвоны клиенту с множеством дополнительных контролей, например, актуальности номера телефона, контроля замены SIM-карты, роуминга клиента и т.п., и можно ограничиться дополнительной подписью подозрительных документов в интернет-банке при помощи токена с экраном.
Исходя из того, что было написано выше, можно констатировать тот факт, что использовать токен с экраном для клиентов выгодно – он повышает как удобство так и безопасность платежей клиента в интернет-банке.
Что касается безопасности платежей, то:
Если рассматривать удобство работы пользователей с интернет-банком, то необходимо отметить следующие факты.
В разделе 3.2 говорилось, что общепринятой практикой для интернет-банка является использование списка доверенных контрагентов, которые подтверждаются клиентом по альтернативному каналу, например, при помощи SMS-сообщений. Такое подтверждение очень неудобно для клиентов в особенности при большом количестве платежей и использовании Толстого клиента интернет-банка. В этом случае клиентом формируется и подписывается большое количество платежных документов в режиме офлайн, а потом одним скопом они отправляются в банк. При этом если получатели не находятся в списке доверенных, то эти платежи не будут приняты банком и клиенту нужно отдельно заполнять список и подтверждать каждую новую запись при помощи ввода одноразового пароля из SMS-сообщения. Причем при подтверждении записей контрагентов необходимо будет каждый раз “выводить на связь с банком” Толстого клиента. В случае же использования токена с экраном платеж, подписанный им, не будет проверяться по списку контрагентов и будет исполняться банком без каких-либо дополнительных условий по защите от мошенничества.
Для того же Толстого клиента и большого количества подписываемых документов удобство использования токена с экраном обусловлено возможностью обработки документов пакетом как было сказано в разделе 3.4.2 с визуализацией агрегированной информации. Это значительно увеличивает скорость обработки клиентом платежных документов. Причем не нужно забывать, что токен с экраном в принципе является более производительным устройством, которое может осуществлять подписание документов примерно на порядок быстрее, чем обычный токен.
Также необходимо обратить внимание, что при использовании шаблонов интернет-банк далеко не всегда отображает на экране токена реквизиты документов. Отображение зависит от степени рискованности документа, тем самым снижается нагрузка на пользователей клиента.
Если смотреть в ближайшее будущее, то можно предположить развитие технологии доверенных устройств от токенов с экраном к многофункциональным доверенным устройствам.
Такое устройство должно иметь возможность работать с интернет-банком в разных режимах и по различным каналам. Если токен с экраном использовал только USB канал, то доверенное устройство должно использовать все современные каналы, такие как: USB, Wi-Fi, Bluetooth, NFC, GPRS/3G/4G, камера и, возможно, другие. Причем неоспоримым преимуществом такого устройства может быть схожесть по форм-фактору с мобильными телефонами – флагманами известных производителей, например, Apple iPhone.
Внешний вид может быть, например, таким.
Рисунок 9. Пример внешнего вида доверенного устройства
При этом устройство должно позволять использовать различные SIM-карты и элементы безопасности для хранения ключей. Например, ключи подписи пользователей могут храниться не только в устройстве, а в элементе безопасности, расположенном на SIM-карте. Причем устройство может разделяться между несколькими пользователями путем перестановки SIM-карт. Также ключи пользователя могут храниться на чиповой карте платежной системы и использоваться при помощи NFC-интерфейса для аутентификации.
Что касается аутентификации, то такое устройство может также для аутентификации использовать отпечатки пальцев, изображение пользователя и подобные модные сейчас методы биометрической аутентификации.
Ниже приводятся простые сценарии использования подобных доверенных устройств в системах интернет-банка.
Наиболее легким для внедрения сценарием является подписание и подтверждение платежа при помощи SMS-канала или PUSH-уведомлений.
В случае использования SMS-канала (см. Рисунок 10 ) клиент формирует платежный документ на компьютере. Далее интернет-банк также как и в случае клиента, использующего SMS-подтверждение, формирует SMS-сообщение, которое отправляется на доверенное устройство клиента. Документ визуализируется клиенту и он подтверждает его. После этого устройство подписывает документ при помощи криптографических ключей пользователя, а возможно и ключей самого устройства, и отсылает в ответном сообщении в банк. Интернет-банк проверяет подпись клиента и исполняет операцию.
Рисунок 10 . Сценарий подтверждения платежа по SMS-каналу без ввода одноразового пароля
В данном случае для работы не обязательно подключение устройства к сети Интернет, однако ответные SMS-сообщения могут быть дороги для клиента. Тогда клиент может использовать SIM-карты, которые в скором времени будут выпускаться банками в качестве виртуальных операторов связи [10]. Наверняка тарифы для операций “своих” интернет-банков будут дешевыми или даже бесплатными.
В случае же использования PUSH-уведомлений (см. Рисунок 11 ) используется подключение к сети Интернет доверенного устройства. Сценарий идентичен до момента отправки документа на доверенное устройство. Отправка осуществляется при помощи PUSH-сервиса, а после подтверждения клиентом, ответное сообщение подписывается и отправляется по сети Интернет через, например, шлюз который используют мобильные приложения в интернет-банк.
Рисунок 11 . Сценарий подтверждения платежа при помощи PUSH-уведомления без ввода одноразового пароля
Другим возможным сценарием является подписание платежных документов на рабочем месте клиента с использованием беспроводных протоколов, таких как Bluetooth или NFC. Сценарий работы аналогичен использованию токена с экраном с подключением по USB к компьютеру клиента. Однако такое соединение удобнее, а соединение по Bluetooth с использованием NFC устанавливается за секунды.
Использование Bluetooth-канала (см. Рисунок 12 ) особенно интересно для Толстого (офлайн) клиента интернет-банка. В этом случае до передачи документов в банк взаимодействие с банком не требуется, а доверенное устройство может быть одновременно подключено к нескольким компьютерам.
Рисунок 12 . Сценарий подписания платежей по Bluetooth-каналу
В случае если спроектированное таким образом доверенное устройство покажет себя перспективным возможно уже портирование мобильных приложений банка на эту доверенную платформу (см. Рисунок 13 ).
Рисунок 13 . Сценарий использования доверенных устройств для мобильных приложений интернет-банка
Таким образом, возможно исключить появление на устройстве пользователя, с которым он работает с интернет-банком, троянов, подменяющих реквизиты платежных документов и другие угрозы. При работе с такого мобильного приложения, работающего на доверенной платформе, банк не будет строить такие стандартные эшелоны защиты как лимиты, списки контрагентов и т.п. А если учесть тенденцию последнего времени – переход клиентов на мобильные платформы для работы с интернет-банком, то такое решение может быть востребовано у клиентов.
И наконец, как уже не раз говорилось выше, возможно подтверждение платежей сделанных другими пользователями организации, но которые по каким то причинам определены системой антифрода в качестве подозрительных. Возможный сценарий в этом случае таков. Система антифрода отправляет PUSH-уведомление на подтверждение подозрительного платежа на доверенное устройство, пользователь его подтверждает и устройство отправляет подписанный ответ обратно в антифрод (см. Рисунок 14 ).
Рисунок 14 . Сценарий подтверждения подозрительных платежей, выявленных системой антифрода
Выше были приведены некоторые сценарии работы с доверенным устройством в интернет-банке. Однако область его применения не ограничивается только этими методами использования и системой интернет-банка. Например, подобное устройство можно использовать для аутентификации как юридических так и физических лиц в государственных системах, доступ к которым осуществляется через сеть Интернет, для подписания документов усиленной квалифицированной электронной подписью и во многих других процессах.
И мы тоже не спим, чтобы держать вас в курсе всех угроз