Прочитал интересную новость. Эта информация выявляет в очередной раз очень интересную проблему безопасности систем клиент-банк, о которой так много рассуждают разного рода специалисты. Рассуждают, в основном, в своем кругу, поэтому широкому кругу пользователей систем клиент-банк результаты этих бесед неизвестны. Совершенно очевидно, что с помощью классической криптографии защититься от этих атак невозможно. Ни GUI клиент (если это толстый клиент), ни криптопровайдер, ни драйвер устройства (речь идет о токене) никак не защищены от исследования. Да, используются протоколы классической криптографии, но они никак не рассчитаны на то, что приложение, их использующее, будет выполняться на недоверенной платформе. Использование токенов с ЭЦП на борту также не дает гарантий безопасности, т.к. на подпись такому токену, как правило, отправляется хеш-сумма подписываемого документа. Таким образом, остаются способы подсунуть на подпись хеш-сумму другого документа. Чтобы создать программу, производящую такие зловредные действия для конкретной клиентской части, достаточно произвести ее тщательный анализ с помощью IDA. Т.к. клиентская часть ничем не защищена и одинакова для многих тысяч пользователей, исследования принесут море удовольствия и не займут много времени, а атака может стать достаточно массовой. Хорошо документированные сервисы MS Crypto API еще более упрощают задачу :)
Один из технических выходов из ситуации - рандомизация каждой конкретной клиентской части. Т.е. ее структура должна стать совсем другой! Это означает отказ от стандартизации, которая считается догмой. В частности, имеет смысл подумать от использовании обфускации и White-Box криптографии, применяя эти механизмы, пусть и в автоматическом режиме, но уникально для каждой клиентской части. Однако, не смотря на техническую возможность, если не обезопасить полностью, то сильно снизить риски, существуют еще и административные вопросы, связанные, например, с сертификацией. Пока все участники процесса не осознают давно уже назревшую необходимость перемен, вряд ли мы увидим какой-то великий прогрессивный сдвиг в направлении улучшения защиты. Способы решения проблем будут, скорее всего, локальными и уже сейчас представлены - одноразовые пароли, SMS-уведомления и т.д. У них есть свои недостатки, связанные с недостаточной гибкостью. Например, SMS - это сервис, не гарантирующий доставку сообщений. С большой вероятностью антивирусные компании будут создавать свои механизмы противодействия атакам на клиентскую часть, что уже радует.
PS. Техническое описание атаки: http://habrahabr.ru/company/eset/blog/107520/
Красиво :)
SMS-уведомления, кстати, не защищены от двойников.
ReplyDeleteИ то верно. Но здесь телефон надо знать еще. Дополнительные проблемы атакующему. Да и не гибко это. Если у меня частые операции, то какой-то sms-спам получится :)
ReplyDeleteв моей практике кражи ключа или подлога при использовании КриптоПро не встречались...
ReplyDeleteчаще физически токен крадут и пробуют его, а еще делают через RDP, когда клиент оставляет токен в ПК
Вот интересный ответ, http://forum.rutoken.ru/topic/939/
ReplyDelete> в моей практике кражи ключа или подлога при использовании КриптоПро не встречались...
ReplyDeleteВсе впереди :) Как только у определенного круга людей появится ощущение, что на этом можно хорошо поживиться без особых дополнительных усилий, имея на руках уже готовый к использованию инструментарий, начнется его использования для клиент-банк систем, что мы и видим на примере Зевса.
> Вот интересный ответ, http://forum.rutoken.ru/topic/939
Я не имею морального права перед некоторыми из моих бывших коллег отзываться плохо о Рутокене и, тем более, делиться какой-либо технической информацией об особенностях функционирования железки и сопутствующего ПО. Представьте себе, что Вы купили Lada Kalina. Вы же не будете от нее хотеть того же, что и от Volkswagen Golf, например :) Думаю, никого из читающих не обидел и ничего секретного не рассказал.
По 1му и 2му: понимаю и согласен
ReplyDeleteНу раз уж такая тема пошла, то уточню для ясности. На форуме имелась в виду возможность использования кеширования пин-кода. Но ведь дело в чем? В том, что его можно и не кешировать, а требовать его введения при выполнении каждой операции, требующей пин-код.
ReplyDeleteТак что дело не в ладе-калине (пример не шибко корректный в принципе), а в том, что есть разные требования у пользователей и есть возможность эти требования удовлетворять за счет настроек.
По поводу Лады Калины, смысл был в том, что Rutoken предыдущих поколений - самое дешевое решение из представленных на рынке. Не сказать, что это самое быстрое и безопасное решение, но, видимо, денег своих стоит, равно как и вышеупомянутая модель Жигулей, которая, как ни странно, ездит, и даже неплохо. Сам видел :) Есть люди, которые ее хвалят, и таких, как ни странно, достаточно много - достаточно за МКАД выехать. Да и настроек в ней куча - только возьмись :)
ReplyDeleteЗакрытый ключ покидает железку и участвует в вычислениях на машине клиента, что неприятно. Понятно, что "так сделано у многих", но это не прибавляет безопасности.
Смарт-карточные чипы, по вполне объективным для нашей Родины соображениям, в Rutoken, даже в ЭЦП, тоже не используются.
К сопутствующему ПО тоже были свои вопросы, которые я и разработчикам, и техподдержке озвучивал. Не сказать, что это критично, но, тем не менее, некоторые вещи смущали. VoV, полагаю, помнит.
Хотя, железка работает, и достаточно стабильно, что-то с ее участием подписывается, какая-то подпись проверяется. Работает она относительно шустренько. Фенечек и мулечек в виде настроек хватает, опять же. Так что все нормально. Откровенно говоря, не хотел никого обидеть. Продукт стоит своих денег - вот что я хотел сказать.
Тут вкралось либо недопонимание, либо я не знаю что :)
ReplyDeleteКеширование пин-кода может наличествовать и при использовании устройства с извлекаемыми ключами, и с неизвлекаемыми. Пин в данном случае разрешает доступ к некому security объекту. Если пин закеширован на время всей сессии, то и имеем как раз ситуацию, о которой шла речь на форуме. Если не закеширован - его спрашивают на каждой операции. Вот и все. А извлекаемость ключей тут вовсе ни при чем. :)
> Кеширование пин-кода может наличествовать и при использовании устройства с извлекаемыми ключами, и с неизвлекаемыми.
ReplyDeleteВ предыдущем комменте я не про кеширование говорил, а про продукт в целом.
> А извлекаемость ключей тут вовсе ни при чем. :)
Извлекаемость ключей всегда при чем.