Обеспечение целостности и аутентичности информации передаваемой от клиентов в банк и обратно

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

8.3. Использование подписи при передаче трафика BS-Defender

Каждый запрос и ответ, передаваемые от клиентского BS-Defender к банковскому и обратно, шифруются и подписываются (см. разд. 4.1 «Защита данных при использовании BSDefender» [стр. 15]). Аутентичность пакетов гарантируется криптостойкостью используемой СКЗИ.

8.4. Использование механизмов аутентичности двустороннего SSL (TLS)

В данном разделе приведено общее описание способа соединения с Интернет-Клиент по каналу, защищаемому двусторонним SSL (TLS). Однако, данная глава не содержит руководства по настройке SSL / TLS в Интернет-Клиент, а также технических подробностей, касающиеся параметров и настроек.

8.4.1. Общие сведения

Аутентификация при защите соединения двусторонним SSL (TLS) — аналогична применяемой в типе соединения «BS-Defender». Канал защищается как со стороны клиента, так и со стороны сервера персональными криптографическими ключами. Криптографические операции выполняются на клиентской стороне — WEB-браузером, на серверной стороне — WEBсервером.

8.4.2. Исходные требования

Ниже перечислены основные требования:

1.Компьютер клиента: Персональный справочник текущего пользователя содержит сертификат клиента с установленной на уровне ОС связкой с контейнером секретных ключей. Область расширенного применения ключа данного сертификата должна допускать применение сертификата для аутентификации клиента (Client authentification).

Кроме этого в справочник доверенных сертификатов корневых центров сертифика-

ции (Trusted Root Certification Authorities) текущего пользователя должен быть устано-

влен сертификат корневого центра сертификации.

2.Компьютер банковского WEB-сервера: Банковский WEB-сервер должен быть настроен на использование защищенного соединения (https) с контролем клиентского сертификата. Сертификат банковского WEB-сервера должен содержаться в персональном справочнике локального компьютера с установленной на уровне ОС связкой с контейнером секретных ключей. Область расширенного применения ключа данного сертификата должна допускать применение сертификата для аутентификации сервера (Server authentification). Кроме этого в справочник доверенных сертификатов корневых центров

35

Обеспечение целостности и аутентичности информации передаваемой от клиентов в банк и обратно

сертификации (Trusted Root Certification Authorities) локального компьютера должен быть установлен сертификат корневого центра сертификации.

Примечание

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

Установленный в открытом ключе, как клиента, так и банка параметр, ссылающийся на ресурс хранящий списки отозванных сертификатов — доступен.

8.4.3. Технология связи клиента и банка по каналу «Двусторонний SSL / TLS»

Клиент инициирует соединение, вписывая в строку браузера ссылку на WEB-сайт банка (или открывает иным способом в браузере сайт банка). В строке запроса явным образом указывается, что соединение будет происходить по защищенному каналу — применяется именование протокола "https://" вместо "http://" (например, "https:// www.bank.ru").

Протоколы TLS подразумевают, что в качестве транспортного протокола используется протокол с установлением логических соединений (например, TCP) и состоят из двух слоев. Первый слой включает в себя прикладной протокол и три так называемых handshake-прото- кола: протокол установления SSL-сессии (Handshake Protocol), протокол смены специфика-

ции шифра (Change Cipher Spec Protocol) и протокол сигнальных сообщений (Alert Protocol).

Второй слой — это т.н. Record Protocol, схематически это можно изобразить так:

Рис. 8.1. Технология связи клиента и банка по каналу «Двусторонний SSL / TLS»

Handshake-протоколы отвечают за установление или возобновление защищенных сессий.

Record protocol выполняет следующие функции:

•Разбивает данные, получаемые от прикладного уровня на блоки и собирает входящие блоки для передачи на прикладной уровень.

•Компрессирует исходящие данные и декомпрессирует входящие.

•Прикрепляет MAC или хэш к исходящим блокам данных и использует прикрепленный MAC для проверки целостности входящих.

36

Обеспечение целостности и аутентичности информации передаваемой от клиентов

вбанк и обратно

•Шифрует исходящие и расшифровывает входящие блоки данных.

В момент обработки первого запроса на соединение с WEB-сервером происходит так называемый HandShake. В этой процедуре происходит следующее:

•WEB-сервер определяет, что для работы с данным WEB-сайтом необходимо шифровать соединение от имени серверного сертификата (выполняется процедура установления действительности собственного сертификата путем обращения к узлу с перечнем отозванных сертификатов).

•Если серверный сертификат признан годным, сервер определяет по настройке, нужно ли требовать от клиента предоставить свой клиентский сертификат.

•Сертификат банка передается в WEB-браузер клиента, также, если это обусловлено настройкой, передается сигнал о предоставлении сертификата клиента Web-серверу.

•Получив от WEB-сервера ответ, содержащий сертификат банка и требование о передаче клиентского сертификата, браузер выполняет два действия:

1.устанавливает действительность банковского сертификата;

2.обращается за информацией к справочнику сертификатов, и предлагает клиенту диалоговое окно с перечнем сертификатов, которые могут быть использованы клиентом для защиты соединения.

•Удостоверившись в сертификате банка и получив указатель на клиентский сертификат, сертификат клиента передается на WEB-сервер, где уже сервер выполняет процедуру удостоверения в достоверности клиентского сертификата.

После того как процедура HandShake выполнена, начинается штатная шифрация трафика.

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

Таким образом, на каждой стороне есть комплект из двух ключей (одинаковый для обоих сторон), используемый для шифрации принимаемых / передаваемых данных, и комплект из двух ключей, используемый для формирования MAC (HMAC).

37

Обеспечение целостности и аутентичности информации передаваемой от клиентов в банк и обратно

Рис. 8.2. Схема взаимодействия клиента, сервера и приложений при организации соединения «двусторонний SSL / TLS».

8.5. Сеансовые ключи при заведении клиентом документов в подсистеме

Телефон-Клиент

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

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

8.6. Аутентичность выписок, остатков и другой информации выдаваемой банком в подсистеме Телефон-Клиент

Аутентичность информации, передаваемой в канале Банк ↔ Телефон-клиент обеспечивается на уровне системных библиотек, поскольку приложение Телефон-клиент расположено в ЛВС банка и работает напрямую с сервером приложений системы "ДБО BS-Client".

Потеря аутентичности возможна лишь на уровне Телефон-клиент ↔ Клиент, при наличии искажений сигнала в канале связи (телефонной линии).

38

Обеспечение целостности и аутентичности информации передаваемой от клиентов в банк и обратно

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

39