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

Механизмы защиты в системе «iBank 2»

iBank 2 относится к классу систем защищенного электронного документооборота. Обмен электронными документами в PC-Банкинге, Internet-Банкинге, и Mobile-Банкинге происходит между банком и клиентом.

Электронный документ, отправленный клиентом и полученный банком, является основанием для совершения банком финансовых операций.

Конечной целью всех атак на систему является:

- Подмена (навязывание) злоумышленником электронного документа от имени одной из сторон
- Нарушение конфиденциальности документа (ознакомление с документом)

Для обеспечения аутентичности (доказательство авторства) и целостности документа в Internet-Банкинге, PC-Банкинге и Mobile-Банкинге, а также в дополнительных сервисах системы «iBank 2» используется механизм электронной цифровой подписи (ЭЦП) под электронными документами.

Именно электронный документ с ЭЦП является основанием для совершения финансовых операций и доказательной базой при разрешении конфликтной ситуации. В системе реализованы алгоритмы в соответствии с ГОСТ Р34.10-94, ГОСТ Р34.10-2001 и ГОСТ Р34.11-94.

Для обеспечения конфиденциальности в Internet-Банкинге, PC-Банкинге и Mobile-Банкинге, а также в дополнительных сервисах системы «iBank 2» используется механизм шифрования данных. При взаимодействии через Интернет осуществляется шифрование и контроль целостности передаваемой информации, проводится криптографическая аутентификация сторон. В системе реализованы алгоритмы в соответствии с ГОСТ 28147-89.

В WAP-Банкинге для шифрования данных и аутентификации банка используются стандартные криптографические протоколы WTLS и SSL, для аутентификации клиента — идентификатор (логин) и пароль.

В SMS-Банкинге защита информации осуществляется стандартными для мобильной связи средствами. Для аутентификации клиента используются номер мобильного телефона, идентификатор и пароль.

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

Для проведения частными клиентами операций по списанию средств со счетов и карт в WAP-Банкинге и Phone-Банкинге в качества аналога собственноручной подписи (АСП) клиента могут использоваться индивидуальные таблицы одноразовых паролей или аппаратные средства аутентификации — OTP-токены (One-Time Password) компаний Aladdin Knowledge Systems и VASCO Data Security International.

Для корпоративных клиентов операции по списанию средств с использованием механизма АСП запрещены.

Для криптографической защиты информации в систему «iBank 2» встроены три сертифицированные ФСБ РФ многоплатформенные криптобиблиотеки:
- «Крипто-КОМ 3.1»
- «Агава-С»
- «Крипто-Си»

Для разрешения конфликтных ситуаций в системе «iBank 2» ведутся контрольные архивы, в которых хранятся все электронные документы с ЭЦП. Контрольные архивы хранятся в банке в Сервере БД системы.

Далее будут подробно рассмотрены механизмы защиты информации, используемые в модулях «Internet-Банкинг», «PC-Банкинг», «Mobile-Банкинг» и дополнительных сервисах системы «iBank 2».

Для организации безопасной работы в указанных модулях используются штатные средства защиты Web-браузеров, виртуальной Java-машины и встроенные в систему «iBank 2» дополнительные механизмы защиты информации.

В Internet-Банкинге работа клиента происходит в два этапа. На первом этапе клиент подключается к сайту банка и загружает в Web-браузер Java-апплет. Второй этап — работа клиента в Java-апплете и взаимодействие клиентского Java-апплета с банковским Сервером Приложения через защищенное соединение.

Работа в PC-Банкинге и Mobile-Банкинге начинается сразу со второго этапа — с взаимодействия Java-приложения с банковским Сервером Приложения.

Этап 1 — Подключение клиента к банку

Клиент в Web-браузере указывает полный URL банковского Web-сервера, включая тип используемого протокола HTTPS. Например, https://ibank.bankname.ru

Загружаемые в Web-браузер HTML-страницы, конфигурационные XML-файлы, Java-апплеты и другие данные являются открытыми. Никаких идентификаторов и паролей для аутентификации клиент не вводит, никакие секретные параметры клиент не загружает, поэтому шифровать трафик на этапе подключения к Internet-Банкингу необязательно.

Атаки злоумышленника на этапе подключения могут быть направлены:

- На подмену банковского Web-сервера
- На модификацию загружаемых в Web-браузер клиента стартовых HTML-страниц
- На модификацию загружаемых в Web-браузер клиента конфигурационных XML-файлов
- На модификацию загружаемых в Web-браузер клиента Java-апплетов

Конечная цель атак — подмена загружаемого к клиенту Java-апплета с последующим похищением секретного ключа ЭЦП клиента.

Для предотвращения указанных атак на этапе подключения используется встроенный в Web-браузеры протокол SSL. В результате обеспечивается:

- Гарантированное подключение клиента к банковскому Web-серверу
- Целостность информации, загружаемой клиенту с банковского Web-сервера (HTML-страницы, конфигурационные XML-файлы, Java-апплеты и пр.)

При работе через протокол SSL Web-браузер клиента обеспечивает аутентификацию банковского Web-сервера, сравнивая доменное имя в введенном клиентом URL с доменным именем, указанным в сертификате. Также SSL обеспечивает целостность всех загружаемых в Web-браузер данных.

Наличие или отсутствие экспортных ограничений в реализации криптографического протокола SSL в ранних версиях Web-браузеров никак не сказывается на уровне безопасности.

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

Банковский вспомогательный Web-сервер

К надежности и защищенности банковского Web-сервера, к его администрированию предъявляются исключительно высокие требования.

В связи с этим в Сервер Приложения «iBank 2» встроен вспомогательный защищенный Web-сервер с необходимыми функциональными ограничениями с целью исключения даже потенциальных атак на модификацию HTML-страниц, Java-апплетов и других ресурсов.

В Web-сервере используется реализация криптографического протокола SSL компании Sun Microsystems.

В составе системы «iBank 2» поставляются утилиты для генерации секретного и открытого ключей (SSL) вспомогательного Web-сервера, формирования запроса на получение Сертификата X.509, импортирования сертификата, выданного Сертификационным Центром.

Сертификат X.509 для вспомогательного Web-сервера банка необходимо получать у одного из мировых Удостоверяющих Центров — VeriSign, Thawte и др.

SoftUpdate и ЭЦП разработчика под Java-апплетами

Во все распространенные Web-браузеры встроены механизмы ускорения загрузки Java-апплетов при повторном подключении пользователя. В Microsoft Internet Explorer этот механизм называется SoftUpdate, в Netscape — SmartUpdate. Механизмы ускорения загрузки (далее для краткости — SoftUpdate) различаются в деталях, но решают единую задачу.

Для использования механизма SoftUpdate в HTML-страницы встраивается несколько строк кода на JavaScript.

При самом первом подключении Web-браузер загружает с Web-сервера Java-апплет (в виде CAB-архива для MS IE или JAR-архива для остальных типов браузеров) и сохраняет его на локальном диске пользователя в одном из служебных подкаталогов Web-браузера.

При последующих повторных подключениях Web-браузер сравнивает ранее загруженную версию Java-апплета, сохраненную в служебном подкаталоге, с текущей версией на Web-сервере.

Если версии совпадают, то используется ранее загруженная версия Java-апплета.. Если на Web-сервере более новая версия Java-апплета, то Web-браузер автоматически загружает, сохраняет в служебном подкаталоге и в дальнейшем использует более новую версию.

Механизм SoftUpdate используется в системе «iBank 2» по умолчанию. В составе системы также есть стартовые HTML-страницы для загрузки Java-апплетов без использования SoftUpdate.

В системе «iBank 2» все загружаемые к клиенту Java-апплеты подписаны ЭЦП компании-разработчика. Механизм проверки ЭЦП разработчика под Java-апплетами стандартный и встроен во все распространенные Web-браузеры.

Проверка ЭЦП разработчика (компании «БИФИТ») осуществляется на основании Сертификата X.509 разработчика, выданного мировым Удостоверяющим Центром Thawte Consulting. Корневые Сертификаты мировых Удостоверяющих Центров идут в составе дистрибутивов всех типов и версий Web-браузеров.

ЭЦП разработчика под Java-апплетами используется:

- Для обеспечения целостности и аутентичности Java-апплетов, загруженных и хранимых в служебном подкаталоге Web-браузера при использовании механизма SoftUpdate (защита от атак по модификации файлов с Java-апплетами, хранимых на компьютере клиента)
- Для предоставления виртуальной Java-машиной Web-браузера Java-апплету расширенных привилегий — работа с локальными дисками клиента (для доступа к дискете/диску с Хранилищем секретных ключей ЭЦП клиента), печать на принтере, взаимодействие с хостами, IP-адреса которых отличны от IP-адреса вспомогательного Web-сервера.

Этап 2 — Защищенное взаимодействие

В Internet-Банкинге инициатором защищенного взаимодействия между клиентским Java-апплетом (в PC-Банкинге и Mobile-Банкинге — Java-приложение) и банковским Сервером Приложения всегда является клиент. Появляется необходимость передать в банк документ или получить информацию — клиентский Java-апплет осуществляет защищенное взаимодействие с банковским Сервером Приложения.

Защищенное взаимодействие разбито на два уровня: верхний уровень — Прикладной Протокол, и нижний уровень — Защищенный Сетевой Протокол.

Уровень | Функция
Прикладной Протокол | Аутентификация клиента
Механизм ЭЦП
Прикладные запросы и ответы
Защищенный Сетевой Протокол | Шифрование данных
Обеспечение целостности данных
Аутентификация банка

Прикладной протокол

Механизмы аутентификации пользователя и ЭЦП реализованы в прикладном протоколе. Транзакция выглядит следующим образом:

1. Java-апплет открывает соединение с Сервером Приложения.
2. Java-апплет формирует прикладной запрос и отсылает его Серверу Приложения.
3. Сервер Приложения принимает прикладной запрос и обрабатывает его.
4. Сервер Приложения формирует прикладной ответ и отсылает Java-апплету.
5. Java-апплет принимает прикладной ответ и обрабатывает его.
6. Java-апплет закрывает соединение с Сервером Приложения.

Прикладной запрос состоит из заголовка и области данных. В области данных передаются значения параметров прикладного запроса. ЭЦП клиента является таким же параметром в области данных прикладного запроса, как и номер документа, дата документа и пр.

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

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

Прикладной ответ также состоит из заголовка и области данных. В заголовке возвращаются код ошибки прикладного ответа и длина области данных. В области данных возвращаются значения параметров прикладного ответа.

Защищенный сетевой протокол

Защищенный сетевой протокол выполняет следующие функции:

- Обеспечивает шифрование данных, передаваемых между Java-апплетом и Сервером Приложения
- Обеспечивает целостность данных, передаваемых между Java-апплетом и Сервером Приложения
- Обеспечивает аутентификацию Сервера Приложения Java-апплетом

Защищенный сетевой протокол является модернизированным протоколом SSL v.3 с упрощенной процедурой согласования сеансовых ключей и с заранее определенными используемыми криптографическими алгоритмами, режимами работы, длинами ключей и другими параметрами.

При необходимости защищенный сетевой протокол позволяет клиенту работать и через HTTP Proxy-сервер (MS Proxy, WinGate, Win Proxy, Squid и др.). Используется тот же механизм туннелирования, что и при работе протокола SSL. Поддерживаются режимы работы через Proxy-сервер с базовой аутентификацией и без аутентификации клиента.

Главные достоинства защищенного сетевого протокола — чрезвычайно низкий объем служебных данных, передаваемых в процедуре согласования сеансовых ключей, а также невысокая нагрузка на процессоры банковского сервера, возникающая в процессе защищенного взаимодействия Java-апплетов или Java-приложения с банковским Сервером Приложения.

При передаче данных вся информация шифруется на сеансовых ключах по ГОСТ 28147-89. Для обеспечения целостности данных также используется ГОСТ 28147-89 (имитовставка).

Ограничение доступа но IP-адресам

В систему «iBank 2» встроен механизм ограничения доступа клиентов с заданных IP-адресов.

В АРМе «Администратор банка/филиала» системы «iBank 2» ответственный сотрудник банка может настроить индивидуальный список IP-адресов, с который разрешено работать заданному клиенту. Доступ с любых других IP-адресов будет запрещен.

Данный механизм ограничения доступа по IP-адресам является индивидуальным для каждого клиента и включается банком по письменному требованию клиента.

Журналы событий

Для полного восстановления действий клиентов и произошедших событий в систему «iBank 2» встроен механизм журнализации. Журналы событий не являются доказательными материалами при разрешении конфликтных ситуаций, но позволяют максимально подробно восстановить весь ход произошедших событий.

В системе «iBank 2» ведется история документов — журнализируется информация о создании документа, об изменении статуса документа. В истории документов сохраняется информация о субъекте, породившем событие, о времени и дате события.

В системе «iBank 2» ведутся журналы учета доступа клиентов по всем сервисам. В журналах хранится информация об IP-адресе клиента, времени доступа, идентификаторе используемого ключа ЭЦП, проводимых операциях.

Администратор системы имеет возможность настраивать уровень подробности журналов, частоту ротации, глубину архивирования.

IP-безопасность

При внедрении системы «iBank 2» всегда проводятся изменения текущей политики IP-безопасности банка.

Серверы системы «iBank 2» размещаются в отдельном сетевом сегменте с контролируемым на межсетевом экране доступом из Интернета и внутренней защищенной сети банка.

При внедрении системы «iBank 2» всегда проводится тщательная настройка операционных систем на серверах системы «iBank 2» — исключается поддержка неиспользуемых протоколов, сетевых сервисов и служб. На серверах системы «iBank 2» запрещается сетевой доступ к файловой системе, задействуются встроенные в ОС механизмы аудита.

Правильно спроектированная и четко реализованная политика IP-безопасности, постоянный IP-мониторинг позволяют обеспечить гарантированный уровень защиты системы «iBank 2» и внутренней
сети банка.

подробнее ...