Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Протокол изменения параметров шифрования

Протокол изменения параметров шифрования (Change Cipher Spec Protocol) генерирует однобайтовое со­общение, содержащее значение 1. Единственной задачей этого со­общения является указание начать копирование параметров состояния ожидания в текущее состояние, что приводит к обновлению комплекта шифров, исполь­зуемых для данного соединения.

 

Протокол извещения

Протокол извещения (Alert Protocol) предназначен для передачи другой уча­ствующей в обмене данными стороне извещений, касающихся работы SSL. Как и данные любого другого приложения, использующего SSL, сообщения протокола извещения точно так же сжимаются и шифруются в соответствии с параметрами текущего состояния.

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

В протоколе извещения существует 5 извещений, указывающих на неустранимую ошибку и 7 извещений не указывающих на неустранимую ошибку.

 

Протокол квитирования.

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

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

• Тип (1 байт). Указывает один из 10 допустимых типов сообщения.

• Длина (3 байта). Длина сообщения в байтах.

• Содержимое (> 1 байта). Параметры, связываемые с сообщением данного типа.

В содержимом может находится несколько полей, в каждом из которых находятся элементы.

Этапы установления сеанса (session) между клиентом и сервером.

№ этапа Типы сообщений Характеристика этапа
1 Определяется характеристика защиты, включая номер версии протокола, идентификатор сеанса, комплект шифров, метод сжатия и исходные случайные числа.
2     Сервер может передать сертификат, сообщение обмена ключами и запрос сертификата. Сервер сигнализирует об окончании фазы приветственного сообщения.
3   Клиент передаёт сертификат, если он был запрошен. Клиент передает сообщение обмена ключами. Клиент может передать сообщение верификации сертификата.
4     Смена комплекта шифров и завершение работы протокола квитирования

1-ый этап – определение характеристик защиты.

Процесс инициируется клиентом, который передаёт сообщение серверу client_hello, сервер отвечает сообщением server_hello с выбранными параметрами, которые доступны клиенту.

Тип сообщения: client-hello.

Название поля Характеристика поля
Версия Наивысший номер версии SSL, поддерживаемый клиентом.
Случайное значение Генерируемая клиентом случайная структура, содер­жащая 32-битовую метку даты/времени и 28 байтов, полученных с помо­щью защищенного генератора случайных чисел. Эти значения используют­ся в качестве оказий во время обмена ключами с целью защиты от атак воспроизведения.
Комплект шифров Список, содержащий наборы криптографических алго­ритмов, поддерживаемых клиентом, перечисленные в порядке убывания их приоритета. Каждый элемент списка (каждый комплект шифров) опре­деляет алгоритм обмена ключами для схем традиционного шифрования, вычислений значений MAC и другие параметры шифрования. Сервер в server_hello должен определить какой-либо комплект шифров.
Метод сжатия Список методов сжатия, поддерживаемых клиентом. Сервер в server_hello должен определить метод сжатии из доступных по списку.
Идентификатор сеанса Идентификатор переменной длины для данного се­анса. Ненулевое значение говорит о намерении клиента обновить парамет­ры имеющегося соединения или создать новое соединение в рамках того же сеанса. Нулевое значение вводится тогда, когда клиент намерен создать новое соединение в новом сеансе.

 

2-й этап – Аутентификация сервера и обмен ключами сервера.

Данный этап начинается с отправки сервером его сертификата, если требуется аутентификация сервера. Сообщение certificate (сертификат) требуется для любого из предлагаемых методов обмена ключами, кроме анонимного мето­да Диффи-Хеллмана. При использовании метода Диффи-Хеллмана с фиксированными параметрами это сообщение сертификации (certificate) выполняет функции сообщения обмена ключами (server_key_exchange), поскольку в нем содержатся предлагаемые сервером открытые параметры алгоритма Диффи-Хеллмана.

Затем при необходимости может быть отправлено сообщение server_key_exchange (обмен ключами сервера). Отправка такого сообщения не требуется в двух случаях: (1) когда сервер отправил сертификат для метода Диффи-Хеллмана с фиксированными параметрами или (2) когда предлагается использовать схему обмена ключами RSA. Сообщение server_key_exchange необ­ходимо в случаях, когда используются следующие схемы.

• Анонимный метод Диффи-Хеллмана.

• Метод Диффи-Хеллмана с одноразовыми параметрами. Сообщение содер­жит такие же три параметра, как и в случае анонимного метода Диффи-Хеллмана, и еще подпись для этих параметров.

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

• Fortezza.

       После этого неанонимный сервер (т.е. сервер, не использующий анонимный метод Диффи-Хеллмана) может запросить сертификат клиента. Сообщение certificate_request (запрос сертификата) включает два параметра: certificate_type (тип сертификата, указывающий на применяемый алгоритм шифрования с открытым ключом) и certificate_authorities (центры сертификации). Центры сертификации - список имен до­пустимых центров сертификации.

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

 

3-й этап - Аутентификация клиента и обмен ключами клиента.

Получив сообщение server_done, клиент должен убедиться в том, что сервер предоставил действительный сертификат (если это требуется) и что параметры сообщения server_hello являются приемлемыми. Если проверка завершается ус­пешно, клиент оправляет серверу следующие сообщения.

1. Если сервер запросил сертификат, клиент начинает данный этап с отправки серверу сообщения certificate. Если у клиента подходящего сертификата нет, клиент отправляет вместо него уведомление no_certificate (нет сертификата).

2. Следующим идет сообщение client_key_exchange (обмен ключами клиента), Содержимое этого сообщения зависит от выбранного метода обмена ключами и может быть следующим.

• RSA. Клиент генерирует 48-байтовый предварительный главный ключ и шифрует его с помощью открытого ключа из сертификата сервера или с помощью временного ключа RSA из сообщения server_key_exchange. Этот предварительный ключ позволяет вычислить главный ключ.

• Метод Диффи-Хеллмана с одноразовыми параметрами, или анонимный метод Диффи-Хеллмана. Отправляются открытые параметры клиента для метода Диффи-Хеллмана.

• Метод Диффи-Хеллмана с фиксированными параметрами. В данном слу­чае открытые параметры клиента для метода Диффи-Хеллмана уже были отправлены в сообщении certificate, поэтому содержимое данного сообще­ния оказывается пустым.

• Fortezza. Отправляются параметры клиента для алгоритма Fortezza.

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

 

4-ый этап – завершение создания защищённого соединения.

Клиент отправляет сообщение change_cipher_spec (изменение параметров шифрования) и копирует параметры шифрования из поля "комплект шифров" состояния ожидания в поле текущего состоя­ния. Обратите внимание на то, что это сообщение не считается частью протокола квитирования, а отсылается в рамках протокола изменения параметров шифро­вания (Change Cipher Spec Protocol). В ответ клиент немедленно отправляет со­общение finished, шифрованное новым алгоритмом с новыми ключами и секрет­ными значениями. Сообщение finished подтверждает, что процессы обмена клю­чами и аутентификации завершились успешно. Содержимое сообщения finished представляет собой результат конкатенации следующих двух значений хэш-кода.

MD5 (master_secret || pad_2 || MD5 (handshake_messages || Sender || master_secret || pad_l)),

SHA (master_secret || pad_2 || SHA (handshake_messages || Sender || master_secret || pad_l)),

где Sender - код, указывающий на то, что отправителем является кли­ент,

handshake_messages - все данные сообщений квитирования, за исключением данного сообщения.

 master_secret – совместно применяемый главный секретный ключ, представляет собой однократно используемое 48-байтовое занчение (384 бита), генерируемое для данного сеанса в ходе защищённого обмена данными.

       В ответ на эти два сообщения сервер посылает свое сообщение change_cipher_spec, переводит параметры шифрования состояния ожидания в те­кущее состояние и посылает свое сообщение finished. На этом процесс квитиро­вания завершается, и теперь клиент и сервер могут начать обмен данными на уровне приложения.

 

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...