Современная криптография - Венбо Мао
ISBN 5-8459-0847-7
Скачать (прямая ссылка):
Протокол SSL основан на протоколе TLS и не очень сильно отличается от него. Однако, поскольку протокол TLS является преемником протокола SSL и стандартом безопасности в World Wide Web, в дальнейшем при описании протокола защиты данных в Internet мы будем иметь в виду именно протокол TLS.
12.5.1 Архитектура протокола TLS
Протокол TLS состоит из двух протоколов: протокола записи TLS (TLS Record Protocol) и протокола квитирования TLS (TLS Handshake Protocol). Второй протокол выполняется поверх первого.
Протокол записи TLS обеспечивает безопасную инкапсуляцию канала связи для применения в рамках протокола более высокого уровня приложений. Этот протокол запускается поверх протоколов TCP и IP и обеспечивает надежный сеанс связи. Он распределяет данные по блокам, сжимает их при необходимости, применяет код аутентификации сообщения (НМАС, см. раздел 10.3.2) для защиты целостности данных, шифрует сообщение с помощью симметричного алгоритма и передает результат адресату. Адресат получает зашифрованные блоки данных, расшифровывает их, верифицирует код MAC, разархивирует их при необходимости, собирает блоки в одно целое и доставляет результат на более высокий уровень приложений.
Ключи для симметричного шифрования и код НМАС генерируются для каждого сеанса связи отдельно и основаны на секрете, согласованном с протоколом квитирования TLS.
Протокол квитирования TLS позволяет серверу и клиенту аутентифицировать друг друга, согласовывать криптографические алгоритмы и ключи, устанавливая таким образом безопасный сеанс связи с протоколом записи TLS для защиты соединений на более высоком уровне приложений.
Из этого описания ясно, что протокол записи TLS не является протоколом аутентификации, хотя он и обеспечивает секретное соединение. Следовательно, достаточно описать протокол квитирования TLS.
12.5.2 Протокол квитирования TLS
Протокол квитирования TLS изменяет параметры своего состояния в процессе выполнения на клиентской машине и сервере. Такое соединение называется сеансом (session), в котором участники выполняют следующие шаги.
470
Часть IV. Аутентификация
• Обмениваются приветствиями, согласовывая алгоритм, пересылают друг другу случайные числа и проверяют возможность возобновления сеанса.
• Обмениваются необходимыми криптографическими параметрами, позволяющими клиенту и серверу согласовать секрет (так называемый "главный секрет").
• Обмениваются сертификатами и криптографической информацией, позволяющей клиенту и серверу аутентифицировать друг друга.
• Генерируют сеансовые секреты на основе главного секрета, обмениваясь случайными числами.
• Убеждаются, что их партнер вычислил те же самые параметры безопасно- j сти, и квитирование выполнено успешно и не подверглось атаке.
• Установленный защищенный канал передается протоколу записи TSL для] обработки на более высоком уровне приложений.
Эти этапы реализуются с помощью четырех обменов, описанных ниже. Для того чтобы лучше изложить основную идею протокола, мы остановимся на упрощенной версии протокола квитирования TLS, опуская необязательные элементы.] В описании протокола символ С обозначает клиента (т.е. клиентскую сторон>1 Web-браузера), а символ S — Web-сервер. Необязательные сообщения сопровож-1 даются звездочкой.
1. С —> S: ClientHello;
2. S -> С: ServerHello,
ServerSertification*, ServerKeyExchange*, CertificateRequest*, ServerHelloDone;
3. С -у S: ClientCetificate;
ClientKeyExchange, Certificate Verify*, ClientFinished;
4. S —у C: ServerFinished.
Этот протокол можно выполнять, опуская все необязательные сообщения, а также сообщение ClientKeyExchange. В этом случае клиент может возобновите существующий сеанс.
Рассмотрим обмен сообщениями, возникающий при выполнен™ протокола квитирования TLS.
12.5.2.1 Обмен приветствиями
Сеанс начинается с того момента, когда клиент посылает сообщение ClientHello, на которое сервер должен ответить сообщением ServerHello. В противном
Глава 12. Протоколы аутентификации —
реальный мир
471
случае связь прерывается. Эти два сообщения заполняют следующие поля: рго-tocolversion ("версияпротокола"), random ("случайныечисла"), sessionid ("но-мерсеанса"), ciphersuites ("элементышифра") и compressionmessage ("мето-ды_сжатия").
Поле protocolversion обладает свойством обратной совместимости: сервер и клиент могут использовать это поле для того, чтобы информировать своего партнера о версии используемого протокола.
Поле random содержит одноразовые случайные числа (идентификаторы "свежести"). Партнеры генерируют эти числа для последующего обмена. Кроме того, это поле содержит локальное время установления связи каждой из сторон.
Поле sessionid идентифицирует текущее сеансовое соединение. В начале нового сеанса связи поле ClientHello.session_id должно оставаться пустым. В этом случае сервер генерирует новый номер сеанса, записывает его в поле ServerHel-lo.sessionid и сохраняет в локальной кэш-памяти. Если поле ClientHello.sessionid содержит какое-то число (например, когда клиент желает возобновить текущий сеанс), сервер должен попытаться найти номер сеанса в локальной кэш-памяти и возобновить указанный сеанс.
