- •Содержание
- •Введение
- •Глоссарий
- •Glossary
- •Глава 1. Общая структурная схема каналов передачи данных в системе "ДБО BS-Client"
- •Глава 3. Защита передаваемых данных в подсистеме «толстый» клиент ДБО (шифрация, подпись, транспорт)
- •3.1. Решаемые задачи
- •3.3. Организация транспортной подсистемы
- •4.3. Сравнение различных способов защиты канала
- •Глава 6. Защита от внешних атак
- •6.1. Фильтрация неподписанных пакетов в ядре транспорта классического клиента
- •6.2. Аутентификация пользователей в подсистеме Интернет-Клиент
- •6.2.1. Подпись трафика BS-Defender’a
- •6.2.3. Аутентификация при работе с односторонним SSL (парольная и криптографическая)
- •6.2.3.1. Парольная аутентификация
- •6.2.3.2. Криптографическая аутентификация
- •6.2.5. Использование сеансовых ключей при работе с подсистемой Телефон-Клиент
- •Глава 7. Защита от внутренних атак
- •7.1. Аутентификация и авторизация внутренних пользователей
- •7.2. Права пользователей в системе
- •7.2.1. Общее описание системы прав
- •7.2.2. Система прав доступа к СУБД и серверу ДБО
- •7.2.3. Система прав разграничения доступа по документам
- •7.3. Ограничение доступа к БД через внешние средства
- •7.4. Аудит действий пользователей
- •7.5.1. Фиксация смены статусов документов
- •7.5.2. Системные журналы
- •7.5.2.1. Системные журналы «толстого» клиента и сервера ДБО
- •7.5.3. Журналы макроязыка
- •Глава 8. Обеспечение целостности и аутентичности информации передаваемой от клиентов в банк и обратно
- •8.1. Использование подписи под документами
- •8.1.1. Общие сведения
- •8.1.2. Подпись документов и квитанций
- •8.1.3. Возможность разбора конфликтных ситуаций
- •8.2. Использование подписи при передаче транспортного трафика
- •8.3. Использование подписи при передаче трафика BS-Defender
- •8.4. Использование механизмов аутентичности двустороннего SSL (TLS)
- •8.4.1. Общие сведения
- •8.4.2. Исходные требования
- •8.4.3. Технология связи клиента и банка по каналу «Двусторонний SSL / TLS»
- •8.6. Аутентичность выписок, остатков и другой информации выдаваемой банком в подсистеме Телефон-Клиент
- •Глава 9. Работа с криптографическими ключами и сертификатами
- •9.1. Описание особенностей СКЗИ
- •9.2. Основные понятия
- •9.2.1. Записи о ключах
- •9.2.5. Право защиты канала («Интернет-Клиент»)
- •9.3. Менеджмент ключей. Права на криптографические операции. Привязка к пользователю
- •9.4. Начальное заведение ключей, Технологический ключ
- •9.5. Перегенерация клиентского ключа (в толстом и тонком клиенте)
- •9.5.1. Удаленная перегенерация ключей толстого и тонкого клиента
- •9.6. Перегенерация банковского ключа
- •9.7. Использование списков отозванных сертификатов. Компрометация ключа
- •9.8. Использование списков отозванных сертификатов (СОС)
- •9.9. Использование USB-токенов
- •Глава 10. Конфликтные ситуации и способы их решения
- •10.1. Общие положения, типы конфликтных ситуаций
- •10.2. Разбор конфликтов в случае «толстого клиента»
- •10.3. Разбор конфликтов в «BS-Defender»
- •10.4. Разбор конфликтов в одностороннем и двустороннем SSL (сохраняемые подписи под документами)
- •Глава 11. Соответствие системы "ДБО BS-Client" стандартам ЦБР
- •Глава 12. Список рекомендуемой литературы
- •Приложение A. Криптографические справочники, используемые в системе "ДБО BS-Client"
- •A.1. Справочник количества подписей в документах (CryptoNumOfSigns)
- •A.2. Справочник сертификатов (CryptoUID)
- •A.3. Справочник криптографических профилей (CryptoProfile)
- •A.4. Справочник рабочих мест абонентов СКЗИ (CryptoWorkPlace)
- •A.5. Справочник пользователей абонентов СКЗИ (CryptoLogin)
- •A.7. Общие справочники
- •A.7.1. Справочник клиентов (PostClnt)
- •A.7.2. Справочник организаций (Customer)
- •B.1. 1. Общий порядок разбора конфликтной ситуации
- •B.2. 2. Действия по общему анализу конфликтного документа
- •B.3. 3. Разбор конфликта вида «Отказ любой из сторон от ЭЦП под созданным этой стороной документом»
- •B.4. Разбор конфликта вида «Отказ любой из сторон от сформированной ею квитанции на документ»
Работа с криптографическими ключами и сертификатами
3.На банковской стороне из удостоверяющего центра получен новый сертификат клиента, сформированный на основе запроса на сертификат, полученного от клиента.
4.На банковской стороне полученный открытый ключ (сертификат) включается в список сертификатов, пригодных к использованию для соответствующего клиента.
5.На банковской стороне открытый ключ (сертификат) помещается в специальную структуру, защищенную от искажения ЭЦП, выработанной на текущих ключах банка.
6.Полученная на шаге 5 структура переправляется клиенту.
7.Клиент, получив сформированную в банке структуру, проверяет ЭЦП банка под ней, далее полученный в структуре открытый ключ / сертификат проверяется на соответствие новому секретному ключу клиента. В случае их соответствия происходит замена рабочих ключей клиента на новые.
8.После завершения замены ключей клиент сообщает банку о завершении процедуры смены ключей. Для этого служит первый пришедший от клиента документ, подписанный новыми ключами.
9.На банковской стороне старый сертификат клиента исключается из списка сертификатов, пригодных для использования клиентом.
Для пользователя все указанные выше операции скрыты. В общем случае, для смены ключей пользователю необходимо совершить только два действия:
1.Инициализировать смену ключа (через прикладной интерфейс клиентского места);
2.Завершить процедуру смены ключа, когда из банка придет новый сертификат клиента (также через прикладной интерфейс).
Примечание
Подробное описание алгоритмов удаленной перегенерации выходит за рамки настоящего документа и подробно изложено в документе «Техническое задание на реализацию сервиса управления ключевой информацией в системе "ДБО BS-Client"».
9.6.Перегенерация банковского ключа
Впредыдущем разделе дано краткое описание алгоритма удаленной перегенерации клиентских ключей. Но необходимость в смене ключей может возникнуть и у банковского администратора. В этом случае процесс смены ключей происходит иначе, чем для ключей клиента.
Смена ключей банковского администратора состоит из следующих основных этапов:
1.Генерация новых банковских ключей.
2.Рассылка нового банковского сертификата всем клиентам, связанным с банковским администратором, ключи которого подлежат замене.
3.Смена текущих банковских ключей на новые.
Как и при смене клиентских ключей, новый открытый ключ банка высылается в специальной структуре, заверенной подписью, выработанной на текущих ключах банковского админи-
47
Работа с криптографическими ключами и сертификатами
стратора. При использовании такого подхода пользователь застрахован от регистрации открытых ключей (сертификатов), произведенных третьими лицами.
9.7. Использование списков отозванных сертификатов. Компрометация ключа
В предыдущих двух пунктах кратко описаны алгоритмы плановой смены клиентских и банковских ключей. Данные операции могут быть произведены без ущерба для стойкости защиты только в том случае, если на период выполнения описанных процедур старый ключ пригоден к использованию. Но при работе с криптографическими ключами также возможны внештатные ситуации, в результате которых использование тех или иных ключей становится недопустимым с точки зрения защиты информации.
Классическим примером такой ситуации является утеря пользователем своего секретного ключа (вместе с носителем). В этом случае ключ считается скомпрометированным и непригодным к дальнейшему использованию.
В случае компрометации клиентского ключа, клиенту необходимо как можно раньше сообщить в банк об этом. Банковский администратор, сразу после поступления подобного заявления от клиента, должен заблокировать соответствующий сертификат на банковской стороне (пометить его, как скомпрометированный (поставить признак «запрещен») в соответствующем криптопрофиле клиента).
После этого ключ клиента становится непригодным к использованию в рамках системы "ДБО BS-Client". Это справедливо как для криптографий с открытыми ключами, так и для криптографий, использующих сертификаты. Отсутствие отличий между этими двумя видами криптографий объясняется схемой передачи данных между клиентской и банковской частью "ДБО BS-Client". Дело в том, что прямую связь между клиентами с помощью рабочих мест "ДБО BS-Client" установить невозможно. В любом случае, данные пересылаются через банковскую часть, на которой происходит контроль ЭЦП клиента.
Таким образом, в случае исключения скомпрометированного открытого ключа (сертификата) из списка допустимых к использованию клиентских ключей, в момент приема информации банковской стороной, она будет забракована, как подписанная недопустимыми для использования ключами.
После блокирования скомпрометированных ключей на банковской стороне необходимо сгенерировать новый комплект ключей для клиента и зарегистрировать их на банковской стороне, как допустимые к использованию данным клиентом. После этого новый комплект ключей необходимо выдать клиенту.
Т.к. комплект содержит обе части ключевой пары (открытый и секретный ключ) пересылка комплекта по открытым каналам связи не допускается. Новый комплект должен быть выдан клиенту в банке лично, с выполнением всех необходимых формальностей, определенных службой безопасности банка. После получения нового комплекта клиент получит возможность воспользоваться описанным выше механизмом перегенерации ключей для смены ключей, полученных в банке на сгенерированные самостоятельно.
48
Работа с криптографическими ключами и сертификатами
9.8. Использование списков отозванных сертификатов (СОС)
Списки отозванных сертификатов (СОС, CRL), применяются в СКЗИ, использующих сертификаты. Данные списки формируются на уровне центров сертификации (ЦС) и служат для блокирования скомпрометированных по тем или иным причинам сертификатов, срок действия которых еще не истек.
При проверке действительности сертификата (такая операция производится каждый раз при проверке ЭЦП, и при шифровании), при наличии актуального на момент проверки СОС, осуществляется поиск сертификата в СОС. В случае обнаружения проверяемого сертификата в СОС, сертификат признается недействительным.
Как было отмечено ранее в системе "ДБО BS-Client" для блокирования клиентского сертификата в рамках системы "ДБО BS-Client" нет необходимости обязательно оповещать об этом всех клиентов. Достаточно заблокировать скомпрометированный клиентский сертификат на стороне банка. Для выполнения указанной блокировки можно воспользоваться механизмом, предоставляемым СОС. Для блокирования сертификатов, включенных в СОС, при каждом выпуске СОС в удостоверяющем центре, необходимо обновить используемый список для всех банковских ключей.
9.9. Использование USB-токенов
Для безопасного хранения ключевой информации в системе "ДБО BS-Client" могут быть использованы USB-токены: eToken и Rutoken. Недопустимо одновременное использование токенов различного типа.
Для обеспечения поддержки использования токенов необходимо выполнить настройку банковской части системы (см. разд. 4.7.2.6 «Использование USB-токенов для хранения ключе-
вой информации» док. Полное руководство пользователя).
Для большинства токенов возможность их использования пользователями клиентской части системы доступна после установки соответствующих драйверов. Перечень СКЗИ и драйвера, необходимые для работы с USB-токенами, отражены в разд. A.1.1 «Общий перечень поддер-
живаемого ПО» док. Инструкция по установке и начальной настройке системы.
49