RFC: 2246
Оригинал: The TLS Protocol Version 1.0
Другие версии: RFC 4346
Категория: Предложенный стандарт
Дата публикации:
Авторы: ,
Перевод: Семенов Юрий Алексеевич

RFC 2246, Страница 33 из 49

8. Криптографические вычисления

Для того чтобы начать защиту соединения, протоколу записей TLS необходима спецификация набора алгоритмов, мастерный секретный код и случайные коды клиента и сервера. Алгоритмы аутентификации, шифрования и MAC определяются cipher_suite, выбранным сервером и указанным в сообщении server hello. Алгоритм сжатия согласуется в сообщениях hello, а случайные коды пересылаются в сообщениях hello. Все что остается — это вычислить мастерный секретный код.

8.1. Вычисление мастерного секретного кода

Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret.

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
[0..47];

Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена.

8.1.1. RSA

Когда для аутентификации сервера и ключевого обмена используется RSA, 48- байтовый pre_master_secret генерируется клиентом, шифруется с помощью общедоступного ключа сервера и посылается серверу. Сервер использует свой секретный ключ для дешифрования pre_master_secret. Оба партнера преобразуют затем pre_master_secret в master_secret, как это специфицировано выше.

Цифровые подписи RSA реализуются с помощью PKCS #1 [PKCS1] с типом блока 1. Шифрование RSA с использованием общедоступного ключа выполняется с помощью PKCS #1 с типом блока 2.

8.1.2. Diffie-Hellman

Выполняются обычные вычисления по алгоритму Diffie-Hellman. В качестве pre_master_secret используется согласованный ключ (Z), преобразование его в master_secret, описано выше.

Параметры Diffie-Hellman специфицируются сервером и могут быть одноразовыми или взятыми из сертификата сервера.

В отсутствии стандарта на прикладной профайл приложение TLS должно использовать шифровой набор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

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

9. Mandatory Cipher Suites

In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

10. Application data protocol

Application data messages are carried by the Record Layer and are fragmented, compressed and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.

Страница 33 из 49

2007 - 2022 © Русские переводы RFC, IETF, ISOC.