Безопасный on-line

Безопасный on-line

Защита информации в системах дистанционного банковского обслуживания

А. И. Кулешов, ведущий специалист ИТ-департамента безопасности
Управления безопасности ОАО АКБ "РОСБАНК"

Высокий уровень конкуренции диктует отечественным банкам необходимость предоставления клиентам разнообразных сервисов дистанционного банковского обслуживания (ДБО). Наиболее совершенные системы позволяют клиенту получать в режиме on-line практически весь комплекс банковских услуг, включая кредитование, операции с ценными бумагами и управление личными финансами. Очевидно, что с расширением возможностей и функционала систем ДБО растут и риски, связанные с их использованием

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

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

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

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

Использование электронно-цифровой подписи

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

Применение симметричных ключевых схем

Альтернативный механизм подтверждения целостности и авторства основан на применении симметричных ключевых схем (как правило, различные варианты Hash based Message Authentication Code-функций). При этом используются одноразовые ключи, часто называемые "аналогами собственноручной подписи" (АСП). Реализации этого подхода отличаются друг от друга прежде всего процедурами генерации, передачи клиенту кодов АСП и верификации АСП. Проанализируем указанные процессы с точки зрения их влияния на обеспечение информационной безопасности системы.

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

"Шифрблокноты" или вычисления АСП?

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

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

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

Обеспечение конфиденциальности

Следующим немаловажным аспектом информационной безопасности систем ДБО является защита от угроз, связанных с нарушением конфиденциальности передаваемой информации. Наиболее распространенным средством обеспечения конфиденциальности передаваемой между клиентом и банком информации является протокол SSL с односторонней (серверной) аутентификацией. Казалось бы, достаточно выпустить один сертификат для сервера, и все данные, передаваемые внутри устанавливаемых с ним соединений, будут надежно зашифрованы и недоступны для посторонних глаз.

К сожалению, разработчики подобных систем недооценивают пресловутый "человеческий фактор", что недопустимо при проектировании систем типа "Интернет-Банк". В случае использования "одностороннего" протокола SSL ответственность за аутентификацию соединения целиком и полностью ложится на клиента. В типовой конфигурации Web-браузеров именно пользователь принимает окончательное решение о продолжении либо прекращении работы с серверами, неудачно прошедшими процедуру аутентификации на основании представленных сертификатов.

В этих условиях достаточно легко осуществима атака "человек посередине" (в Интернете в свободном доступе имеется большое количество утилит, позволяющих автоматизировать процесс атаки). Для реализации атаки нужно заставить пользователя ошибиться, приняв сфальсифицированный сертификат за истинный. Общая схема атаки может быть следующей: при попытке клиента установить соединение с системой злоумышленник перехватывает этот запрос и отсылает клиенту специально сформированный фальшивый сертификат. Одновременно с этим злоумышленник от своего имени устанавливает защищенное соединение с сервером банка. Можно предположить, что клиент, являясь обычным пользователем ПК, чрезвычайно далек от проблем информационной безопасности, и когда при работе в Интернет (особенно в условиях временного прессинга) на мониторе высветится окошко, в котором будет "что-то написано про какие-то сертификаты", он, не раздумывая, привычно кликнет "Yes", после чего работа с системой будет уже проходить под контролем злоумышленника.

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

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