Решение называется CrontoSign и работает оно следующим образом (судя по информации, опубликованной на официальном сайте):
- Клиент заполняет форму платежного документа в системе интернет-банкинга и нажимает кнопку типа "Запрос кода подтверждения";
- Платежный документ передается приложению интернет-банкинга, которое на основании реквизитов документа готовит некую криптограмму, которая отображается в браузере клиента в виде, отдаленно напоминающем QR-код.
- Клиент берет считыватель (которым может быть как специальное устройство, так и почти любой смартфон с камерой) и с помощью камеры считывает эту криптограмму.
- Программное обеспечение считывателя извлекает из криптограммы информацию платежа и показывает ее клиенту на экране считывателя (например, счет получателя и сумму платежа).
- Одновременно с этим, считыватель на основе реквизитов платежного документа формирует одноразовый пароль, который клиент (если, конечно, реквизиты платежного документа правильные) вводит в соответствующее поле ввода в браузере и нажимает кнопку "Подписать и отправить в банк".
- Банк проверяет одноразовый пароль и, если все правильно, проводит платеж.
Защищенность решения напрямую зависит от стойкости используемой криптографии. Если для формирования и проверки криптограммы используются надежные асимметричные алгоритмы (типа RSA или ГОСТ), такое решение обеспечит более чем достаточную защиту, чтобы на время забыть о мошенничестве в системах ДБО (разве что за исключением внутреннего). Кстати, решение идеально вписывается в требования п.2 ст.12 63-ФЗ. Причем, помимо одноразового пароля, ничто не мешает для подписи платежных документов, отправляемых в Банк на первом этапе процесса, использовать традиционную ЭЦП (или усиленную ЭП).
Для физ.лиц, на мой взгляд, решение почти идеально - дополнительные телодвижения минимальны, а само решение может быть бесплатно для клиента (если используется уже имеющийся у него смартфон). Для юр.лиц (крупных) пока вижу только одну проблему, но серьезную. Они часто загружают в систему ДБО сразу пакет платежных документов, подписывают и отправляют их все скопом. При использовании такого решения, каждый платежный документ им придется подписывать и отправлять по отдельности... Хотя и тут возможны варианты - например, формировать криптограмму на каждый платежный документ в отдельности (для проверки клиентом) и одну криптограмму на общую сумму. И именно на последнюю криптограмму формировать одноразовый пароль. Если при создании криптограммы используется закрытый ключ банка, подделать ее не удастся все равно.
Кстати, решение CrontoSign уже внедрил у себя немецкий Commerzbank AG.
Хорошо бы заинтересовать им российских разработчиков систем ДБО... Думаю, что они могли бы договориться с Cronto. Тем более, что ген.директор и основатель Cronto - русский, Игорь Дроков, выпускник МГТУ им.Баумана :-). Ну в крайнем случае, они наверняка смогут разработать свое аналогичное решение.
View more presentations from cronto
6 комментариев:
AES - асимметричный алгоритм? 0_о
Если исходить из описания, то бросается в глаза такой изъян:
либо предварительно в "считыватель" необходимо загружать ключи шифрования (сразу встает вопрос с доверенной загрузкой и вообще с управлением ключами), либо никакого ключа нет, а одноразовый пароль генерируется только исходя из данных о счете, тогда вообще никакой защиты нет, т.к. в этом случае пароль можно сгенерировать без участия пользователя.
С AES ошибочка вышла, исправил. Спасибо за внимательность, Алексей! :-)
В считыватель, конечно, должны загружаться ключи. Не знаю, как это реализовано в оригинальном решении Cronto - не нашел у них таких подробностей. Но, в принципе, загружать ключи должен банк. Если одноразовый пароль используется в качестве дополнения к ЭЦП, тогда вообще проблем нет.
Если использовать отдельный считыватель (не телефон), в нем можно реализовать функционал аппаратного криптопровайдера, типа того же etoken'а. Такой вариант может подойти для юриков.
C APT вопрос достаточно серьезный. Если такой лидер RSA так проколся, то что ждать от этого производителя.
Хотя риски снижаются радикально, что делать при компрометации продукта - нужно продумать заранее!
Отправить комментарий