13.2.3.2. Установление защищенной связи
На рис. 13.10 показана схема обмена сообщениями при установлении защищенной связи SA между клиентом и сервером. В сетях WiFi и WiMAX клиентом является беспроводный пользователь, а сервером аутентификации RADIUS-сервер. Процесс установления защищенной связи можно представить состоящим из следующих четырех этапов, составляющим протокол квитирования [9].
Этап 1. Определение характеристики защиты
На этом этапе производится инициализация соединения, и определяются связанные с ним характеристики защиты. Процесс инициализируется клиентом, который отправляет серверу сообщение «client hello» с параметрами: версия, случайные значения, идентификатор сеанса, комплект шифров, метод сжатия.
Приведём подробное описание двух из этих параметров – идентификатор сеанса и комплект шифров. Случайные значения используются для защиты от угрозы «повтор».
Идентификатор сеанса.
Работа TLS описывается в двух важных понятиях – сеанс и соединение. Сеанс определяет набор параметров защиты, которые могут использоваться несколькими соединениями. Идентификатор сеанса говорит о намерении клиента создать новый сеанс или создать новое соединение в рамках того же сеанса.
Комплект шифров.
Каждый комплект шифров определяет алгоритм обмена ключей и список, состоящий из следующих полей:
алгоритм шифрования (RC4, тройной DEA, IDEA и др.);
алгоритм хеш-функции (SHA-1, MD5);
тип шифра (поточный, блочный);
длина хеш-кода;
длина вектора инициализации (IV) режима блочных кодов и др.
Протокол TLS поддерживает следующие методы обмена ключей для шифрования с общим ключом и для вычислений значений по протоколу HMAC. При этом могут быть использованы как протокол с открытым ключом (приложение В), так и протокол по методу Диффи-Хеллмана (приложение Д).
Рис. 13.10. Схема обмена сообщениями при
установлении защищенного соединения
RSA. Секретный ключ шифруется с помощью открытого ключа RSA получателя. Для этого отправителю должен быть доступен сертификат открытого ключа получателя и цепочка сертификатов для проверки достоверности этого ключа (приложение В). Более подробное изложение этого метода приводится в главе 17 (раздел 17.5) при изложении аутентификации и обмена ключами в сети ISDN.
Метод Диффи-Хеллмана с фиксированными параметрами (Fixed Diffie-Hellman). Метод обмена ключами по схеме Диффи-Хеллмана, при котором сертификат сервера содержит открытые параметры алгоритма Диффи-Хеллмана, подписанные центром сертификации. Клиент сообщает свои параметры алгоритма Диффи-Хеллмана либо в сертификате, если требуется аутентификация клиента, либо в сообщении обмена ключами. Это обеспечивает защиту от угрозы «человек посередине» (приложение Д).
Метод Диффи-Хеллмана с одноразовыми параметрами (Ephemeral Diffie-Hellman). Этот метод применяется для создания временных (одноразовых) секретных ключей. В этом случае стороны обмениваются открытыми ключами Диффи-Хеллмана, подписанными закрытым ключом RSA отправителя. Получатель для проверки подписи может использовать соответствующий открытый ключ. Для аутентификации открытых ключей применяются сертификаты. Это обеспечивает защиту от угрозы «человек посередине» (приложение Д).
Анонимный метод Диффи-Хеллмана (Anonymous Diffie-Hellman). Предполагает использование базового алгоритма Диффи-Хеллмана, но аутентификация не выполняется. Иными словами, каждая из сторон отправляет свои открытые параметры для алгоритма Диффи-Хеллмана другой стороне без аутентификации. Данный подход оказывается уязвимым к атакам «человек-посередине», когда с обеими сторонами по анонимному методу Диффи-Хеллмана обмен ключами проводит злоумышленник.
После отправления сообщения «client hello» (приветствие клиента), клиент ожидает от сервера сообщения «server hello» (приветствие сервера), которое содержит согласованные алгоритмы шифра, алгоритмы обмена ключами и другие параметры, что и в сообщении «client hello».
Этап 2. Аутентификация и обмен ключами сервера
Данный этап начинается с отправки сервером его сертификата, если требуется аутентификация сервера. Отправляемое сообщение содержит сертификат X.509 или цепочку таких сертификатов. Сообщение certificate (сертификат) требуется для любого из предлагаемых методов обмена ключами, кроме анонимного метода Диффи-Хеллмана. Обратите внимание на то, что при использовании метода Диффи-Хеллмана с фиксированными параметрами сообщение сертификата играет роль сообщения обмена ключами, поскольку в нем содержатся предлагаемые сервером открытые параметры алгоритма Диффи-Хеллмана.
Затем может быть отправлено сообщение «server_key_exchange» (обмен ключами сервера). Отправка такого сообщения не требуется в двух случаях: (1) когда сервер отправил сертификат для метода Диффи-Хеллмана с фиксированными параметрами, и (2) когда предлагается использовать схему обмена ключами RSA. Сообщение «server_key_exchange» необходимо тогда, когда используются следующие схемы.
Анонимный метод Диффи-Хеллмана. Сообщение содержит два глобальных значения, необходимых для использования метода Диффи-Хеллмана (некоторое простое число и его первообразный корень), а также открытый ключ сервера для алгоритма Диффи-Хеллмана.
Метод Диффи-Хеллмана с одноразовыми параметрами. Сообщение содержит такие же три параметра, как и в анонимном методе Диффи-Хеллмана, а кроме того, подпись для этих параметров.
Обычно подпись создается с помощью вычисления хеш-кода сообщения с последующим ее шифрованием закрытым ключом отправителя.
Функция хеширования вычисляется для аргумента, включающего не только параметры Диффи-Хеллмана или RSA, но и оба сообщения приветствия на этапе 1 (рис. 13.10). Это обеспечивает защиту от атак воспроизведения сообщений и атак фальсификации ответа.
После этого неанонимный сервер (т.е. сервер, не использующий анонимный метод Диффи-Хеллмана) может запросить сертификат клиента. Сообщение «certificate_request» (запрос сертификата) включает два параметра: «certificate_type» (тип сертификата) и «certificate_authorities» (центры сертификации). Тип сертификата указывает применяемый алгоритм шифрования с открытым ключом и может быть следующим.
RSA, только для подписи.
RSA для метода Диффи-Хеллмана с одноразовыми параметрами.
Вторым параметром сообщения «certificate_request» является список имен допустимых центров сертификации.
Последним (и единственным обязательным) сообщением второго этапа является сообщение «server_done», свидетельствующее о завершении фазы приветствия сервера. Это сообщение не имеет параметров. После отправки этого сообщения сервер переходит в режим ожидания ответа клиента.
Этап 3. Аутентификация и обмен ключами клиента
Получив сообщение «server_done», клиент должен убедиться в том, что сервер предоставил действительный сертификат (если это требуется), и что параметры сообщения «server_hello» являются приемлемыми. Если проверка завершается успешно, клиент отправляет серверу одно или несколько сообщений, речь о которых пойдет ниже.
Если сервер запросил сертификат, клиент начинает данный этап с отправки серверу сообщения «certificate».
Следующим идет сообщение «client_key_exchange» (обмен ключами клиента), которое для этого этапа является обязательным. Содержимое этого сообщения зависит от выбранного метода обмена ключами и может быть следующим:
RSA. Клиент генерирует 48-байтовый предварительный ключ и шифрует его с помощью открытого ключа из сертификата сервера. Этот предварительный ключ позволяет вычислить главный ключ, как будет показано ниже.
Метод Диффи-Хеллмана с одноразовыми параметрами, или анонимный метод Диффи-Хеллмана. Отправляются открытые параметры клиента для метода Диффи-Хеллмана.
Для метода Диффи-Хеллмана так же, как для RSA предусмотрено создание предварительного ключа у клиента и сервера. На основании предварительного ключа клиент и сервер по специальному алгоритму с использованием хеширования создают главный ключ. При этом используются случайные значения (нонсы, оказии) в сообщениях этапа 1 (рис. 13.10). Из главного ключа создается набор ключей различного назначения. Процедура их создания аналогична процедуре создания главного ключа из предварительного ключа. Приведем список этих ключей.
Ключ симметричного шифрования, используемый сервером для шифрования данных и расшифрования их клиентом.
Ключ симметричного шифрования, используемый клиентом для шифрования данных и расшифрования их сервером.
Секретный ключ, применяемый клиентом для вычисления кода аутентичности, используемого по протоколу HMAC для аутентификации сообщений в части целостности данных и неотказуемости.
Секретный ключ, применяемый сервером для вычисления кода аутентичности, используемого по протоколу HMAC для аутентификации сообщений в части целостности данных и неотказуемости.
Вектор инициализации IV, используемый в режиме блочного шифрования (Приложение Б, разд. Б.2.2.). . Используются два вектора инициализации – один при передаче сообщений клиентом, другой – сервером.
Этап 4. Завершение
Этот этап завершает создание защищенной связи SA. Клиент отправляет сообщение «change_cipher_spec» (изменение параметров шифрования), копирует параметры состояния ожидания в поле текущего состояния. В ответ клиент немедленно отправляет сообщение «finished», зашифрованное новым алгоритмом с новыми ключами и секретными значениями. Сообщение «finished» подтверждает, что процессы обмена ключами и аутентификация завершились успешно.
В ответ на эти два сообщения сервер посылает свое сообщение «change_cipher_spec», переводит параметры состояния ожидания в текущее состояние и посылает свое сообщение «finished». Теперь клиент и сервер могут начать обмен данными на уровне приложения.