2.4.2. Сервер ключей, шифрование и цифровая подпись

Для того, чтобы воспользоваться возможностями шифрования и цифровой подписи сообщений, в составе организации должен быть настроен сервер управления ключами, Key Management (KM) Server.

Установка сервера управления ключами является отдельной процедурой, выполняемой отдельно от установки ядра Exchange. Кроме того, сервер ключей рассчитан исключительно на ручной запуск. В процессе установки создается специальный секретный ключ, необходимый в дальнейшем для запуска сервера. Этот ключ может быть сохранен на дискете. При каждом старте KM будет требовать либо ввода секретного ключа, либо наличия дискеты в дисководе A:. Дополнительно существует возможность указать ключ в качестве параметра при старте сервиса из контрольной панели или удаленно из программы Server Manager. Описанная практика старта сервера ключей является общепринятой во всех силовых структурах. Она позволяет иметь в составе организации менеджера безопасности, в чьи функции будет входить запуск сервера управления ключами.

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

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

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

Для того, чтобы открытые ключи пользователя могли трактоваться как истинные, KM ассоциирует с каждым открытым ключом сертификат, содержащий уникальный серийный номер, характерное имя сервера ключей (distinguished name), характерное имя пользователя и дату истечения срока сертификата. Создаваемые сертификаты действуют в течение двух лет со дня создания и продлеваются автоматически.

В ряде случаев может потребоваться отозвать сертификат пользователя. Операция отзыва сертификата является необратимой. Единожды отозванный сертификат помещается в список отозванных сертификатов (revocation list), который распространяется вместе с адресной книгой. Он хранится там до срока истечения сертификата, после чего удаляется. Если пользовательский сертификат оказывается отозванным, при попытке прочесть зашифрованное сообщение или проверить цифровую подпись на сообщении, созданном пользователем, чей сертификат был отозван, принимающая сторона получает предупреждение о невозможности подтвердить истинность личности отправителя. Однако сообщение будет открыто, и проверка на отсутствие модификации выполнена. Администратор всегда может создать для пользователя новый сертификат вместо отозванного, однако все почтовые сообщения, зашифрованные старым сертификатом, будут утеряны.

Рис. 2.21. Процесс шифрования сообщения

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

На первом этапе при помощи секретного ключа создается ключ массового кодирования (bulk encryption key), которым, собственно, и выполняется кодирование тела сообщения. Затем, в свою очередь, ключ массового кодирования шифруется открытым ключом адресата и отправляется вместе с зашифрованным сообщением (рисунок 2.21). Вместе зашифрованное тело сообщения и зашифрованный ключ в терминологии Microsoft образуют китайскую шкатулку (lockbox).

Принимающая сторона использует свой секретный ключ для получения ее ключа массовой дешифрации и расшифровывает им сообщение. Затем дешифруется само сообщение (рисунок 2.22).

Рис. 2.22. Чтение зашифрованного сообщения

Процесс создания цифровой подписи на сообщении и процесс ее верификации отражены на рисунках 2.23 и 2.24. На первом этапе создается цифровая характеристика сообщения (собственно подпись или хэш), затем она шифруется секретным ключом пользователя. Текст сообщения, цифровая подпись и сертификат пользователя отправляются адресату.

Рис. 2.23. Отправка сообщения, содержащего цифровую подпись

Рис. 2.24. Проверка цифровой подписи

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

Для версии, экспортируемой за пределы США, длина ключа шифрования равна 40 битам, для цифровой подписи - 512 битам. Используемый при шифрации алгоритм называется CAST-40. В текущей версии сервера Exchange не предусмотрено возможности замены сервера ключей и подстановки другого алгоритма шифрации. В последующих версиях такие возможности заявлены.

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

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

Шифрование трафика

Для увеличения степени защищенности данных может использоваться шифрование всего трафика между сервером и клиентом. Для этого в конфигурации клиентской части устанавливается специальный флаг. Шифрование выполняется средствами Secure RPC сетевых служб Microsoft. Используется алгоритм Stream-Cheaper фирмы RSA и ключи шифрования длиной 40 бит. Шифрование трафика поддерживаются для клиентских частей семейства Windows.

Назад | Содержание | Вперед