"Р 1323565.1.020-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)" (утв. и введены в действие Приказом Росстандарта от 18.12.2020 N 1327-ст)

Главная // Актуальные документы // Приказ

СПРАВКА

Источник публикации

М.: Стандартинформ, 2021

Примечание к документу

Документ введен в действие с 01.04.2021.

Взамен Р 1323565.1.020-2018.

Название документа

"Р 1323565.1.020-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)"

(утв. и введены в действие Приказом Росстандарта от 18.12.2020 N 1327-ст)

Содержание

Р 1323565.1.020-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

3 Термины, определения и обозначения

3.1 Термины и определения

3.2 Обозначения

4 Иерархия информационного обмена в протоколе TLS

5 Протокол Record

5.1 Состояние соединения

5.2 Формирование записи

6 Протокол Handshake

6.1 Формат сообщений протокола Handshake

6.2 Процедуры взаимодействия сторон

6.3 Сообщения приветствия

6.4 Выработка и подтверждение ключа

7 Протокол Change Cipher Spec

8 Протокол Alert

8.1 Оповещения закрытия соединения

8.2 Оповещения об ошибках

9 Протокол Application Data

10 Использование российских криптографических алгоритмов

10.1 Идентификаторы криптонаборов из реестра "TLS Cipher Suites"

10.2 Идентификаторы алгоритмов подписи из реестра "TLS SignatureAlgorithm"

10.3 Идентификаторы типов сертификатов из реестра "TLS ClientCertificateType Identifiers"

11 Вопросы реализации и безопасности

Приложение А. Контрольные примеры работы алгоритма TLSTREE

Приложение Б. Контрольные примеры для работы протокола Record

Приложение В. Контрольные примеры для работы протокола TLS 1.2

Приложение Г. Язык представления данных в протоколе TLS

Библиография

Утверждены и введены в действие

Приказом Федерального

агентства по техническому

регулированию и метрологии

от 18 декабря 2020 г. N 1327-ст

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

ИСПОЛЬЗОВАНИЕ РОССИЙСКИХ КРИПТОГРАФИЧЕСКИХ АЛГОРИТМОВ

В ПРОТОКОЛЕ БЕЗОПАСНОСТИ ТРАНСПОРТНОГО УРОВНЯ (TLS 1.2)

Information technology. Cryptographic data security.

The use of the Russian cryptographic algorithms

in the Transport Layer Security protocol (TLS 1.2)

Р 1323565.1.020-2020

ОКС 35.040

Дата введения

1 апреля 2021 года

Предисловие

1 РАЗРАБОТАНЫ Обществом с ограниченной ответственностью "КРИПТО-ПРО" (ООО "КРИПТО-ПРО")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 026 "Криптографическая защита информации"

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2020 г. N 1327-ст

4 ВЗАМЕН Р 1323565.1.020-2018

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Настоящие рекомендации содержат описание порядка использования российских криптографических алгоритмов в рамках криптонаборов протокола безопасности транспортного уровня (TLS 1.2).

Необходимость разработки настоящих рекомендаций вызвана потребностью в обеспечении совместимости реализаций протокола TLS 1.2 с использованием российских государственных криптографических стандартов.

Примечание - Основная часть настоящих рекомендаций дополнена приложениями А - Г.

1 Область применения

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

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

2 Нормативные ссылки

В настоящих рекомендациях использованы нормативные ссылки на следующие документы:

ГОСТ Р 34.10-2012 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р 34.12-2015 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ Р 34.13-2015 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

ГОСТ Р ИСО/МЭК 9594-8-98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации

Р 50.1.113-2016 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования

Р 1323565.1.017-2018 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования

Р 1323565.1.023 Информационная технология. Криптографическая защита информации. Использование алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в сертификате, списке аннулированных сертификатов (CRL) и запросе на сертификат PKCS #10 инфраструктуры открытых ключей X.509

Р 1323565.1.024 Информационная технология. Криптографическая защита информации. Параметры эллиптических кривых для криптографических алгоритмов и протоколов

Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных документов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины, определения и обозначения

В рамках настоящих рекомендаций термин "TLS" использован без уточнения версии протокола в том случае, если сопутствующее описание от нее не зависит.

3.1 Термины и определения

В настоящих рекомендациях применены следующие термины с соответствующими определениями:

3.1.1 криптонабор (cipher suite): Набор криптографических алгоритмов и их параметров, определяющий работу протокола TLS в рамках соответствующей данному криптонабору сессии.

3.1.2 согласованный криптонабор: Криптонабор, соответствующий идентификатору криптонабора, согласованному сторонами взаимодействия в процессе выполнения протокола Handshake.

Примечание - Описание протокола Handshake приведено в разделе 6.

3.1.3

ключ подписи: Элемент секретных данных, специфичный для субъекта и используемый только данным субъектом в процессе формирования цифровой подписи.

[ГОСТ Р 34.10-2012, статья 3.1.2]

3.1.4

ключ проверки подписи: Элемент данных, математически связанный с ключом подписи и используемый проверяющей стороной в процессе проверки цифровой подписи.

[ГОСТ Р 34.10-2012, статья 3.1.3]

3.1.5 открытый ключ сервера: Ключ, равный ключу проверки подписи, хранящемуся в сертификате сервера.

3.1.6 закрытый ключ сервера: Ключ, равный ключу подписи сервера, с которым математически связан ключ проверки подписи, хранящийся в сертификате сервера.

Примечания

1 В настоящих рекомендациях в целях сохранения терминологической преемственности с действующими отечественными нормативными документами и опубликованными научно-техническими изданиями установлено, что термины "электронная подпись", "цифровая подпись", "электронная цифровая подпись" и "подпись" являются синонимами.

2 В настоящих рекомендациях термины "открытый ключ сервера", "закрытый ключ сервера" использованы вместо терминов "ключ проверки подписи сервера", "ключ подписи сервера" в целях конкретизации способа их употребления и указывают на то, что данные ключи не предназначены в протоколе TLS 1.2 для формирования подписи, а задействованы в выработке общего ключа при работе протокола Handshake (см. раздел 6).

3.2 Обозначения

В настоящих рекомендациях применены следующие обозначения:

x mod y	-	остаток от деления целого числа x на целое число y;
&	-	операция побитовой конъюнкции (побитовое "И");
B^*	-	множество всех байтовых строк произвольной конечной длины;
B_s	-	множество байтовых строк длины s, s >= 0. Строка b = (b₁, ..., b_s) принадлежит множеству B_s, если . При s = 0 множество B_s состоит из единственной пустой строки длины 0;
\|	-	конкатенация двух байтовых строк; для двух строк , их конкатенацией a\|b именуют строку ;
b[i..j]	-	строка , где 1 <= i <= j <= s и ;
INT(b)	-	число INT(b) = 256^s^-1·b₁) + ... + 256·b_s_-1 + b_s, где ;
STR_s(r)	-	строка , соответствующая числу r = 256^s^-1·b₁ + ... + 256·b_s_-1 + b_s <= 256^s - 1;
str_s(r)	-	строка , соответствующая числу r = 256^s^-1·b₁ + ... + 256·b_s_-1 + b_s <= 256^s - 1;
LMB_t(b)	-	строка , соответствующая строке , 1 <= t <= s;
n	-	параметр алгоритма блочного шифрования, именуемый длиной блока и задаваемый согласованным криптонабором (см. 10.1.1); в рамках настоящих рекомендаций измеряемый в байтах;
k	-	параметр алгоритма блочного шифрования, именуемый длиной ключа и задаваемый согласованным криптонабором (см. 10.1.1); в рамках настоящих рекомендаций измеряемый в байтах;
q	-	порядок подгруппы группы точек эллиптической кривой, соответствующей открытому ключу сервера;
P	-	точка эллиптической кривой порядка q, соответствующей открытому ключу сервера;
	-	нулевая точка эллиптической кривой;
Q_C	-	ключ проверки подписи, хранящийся в сертификате клиента;
k_C	-	ключ подписи клиента, соответствующий ключу Q_C;
Q_S	-	открытый ключ сервера;
k_S	-	закрытый ключ сервера;
r_C	-	байтовая строка со случайными данными, соответствующая полю ClientHello.random, описанному в 6.3.2;
r_S	-	байтовая строка со случайными данными, соответствующая полю ServerHello.random, описанному в 6.3.3;
ENC	-	функция зашифрования, задаваемая согласно 10.1.2.2;
MAC	-	функция вычисления имитовставки, задаваемая согласно 10.1.2.1;
SIGN	-	функция формирования подписи, задаваемая согласно 10.2;
HASH	-	хэш-функция, задаваемая согласно 10.1.4;
KEG	-	алгоритм генерации ключей экспорта, описанный в 6.4.5.1;
PRF	-	псевдослучайная функция, задаваемая согласно 10.1.5;
KExp15	-	алгоритм экспорта ключей, описанный в Р 1323565.1.017-2018 (раздел 5), использующий блочный шифр, задающийся согласованным криптонабором;
Klmp15	-	алгоритм импорта ключей, описанный в Р 1323565.1.017-2018 (раздел 5), использующий блочный шифр, задающийся согласованным криптонабором.

Примечания

1 Для описания протокола в настоящих рекомендациях использован общепринятый язык представления данных в протоколе TLS (далее - язык представления TLS), описанный в приложении Г.

2 В настоящих рекомендациях все строковые константы приведены в кавычках и представлены в кодировке ASCII без терминирующего нуль-символа.

3 В настоящих рекомендациях в целях сохранения терминологической преемственности с действующими отечественными нормативными документами и опубликованными научно-техническими изданиями установлено, что термины "хэш-функция", "криптографическая хэш-функция", "функция хэширования" и "криптографическая функция хэширования" являются синонимами.

4 В настоящих рекомендациях использованы обозначения параметров эллиптических кривых в соответствии с ГОСТ Р 34.10-2012 (раздел 5).

5 В настоящих рекомендациях установлен следующий порядок перевода чисел в строки, если иное не указано: все числовые значения, имеющие тип uint8, uint16, uint24, uint32, uint64, представляются в виде строк в формате big-endian, например десятичное число 16909060 с типом uint32 - в виде байтовой строки 01 02 03 04 в шестнадцатеричном виде.

6 В настоящих рекомендациях установлено, что весь трафик, пересылаемый в канале связи, имеет байтовое представление.

7 Байтовое представление данных, соответствующих определенной структуре, задано конкатенацией байтовых представлений значений полей структуры в порядке их объявления (сверху вниз). Байтовое представление значения поля, являющегося вектором элементов некоторого типа, задано конкатенацией байтовых представлений элементов данного вектора в порядке их нумерации (слева направо). Все числовые значения представлены в виде байтовых строк в соответствии с примечанием 6.

4 Иерархия информационного обмена в протоколе TLS

Протокол TLS состоит из двух уровней: нижнего и верхнего. На нижнем уровне находится протокол Record, работающий поверх некоторого транспортного протокола (например, TCP) с гарантированной доставкой пакетов данных, который обеспечивает доставку сообщений с сохранением их очередности, отсутствием потерь и дублирований. Поверх протокола Record, в свою очередь, работают следующие протоколы: Handshake, Alert, Change Cipher Spec и Application Data.

Схема обмена данными в протоколе TLS изображена на рисунке 1.

Рисунок 1 - Схема обмена данными в протоколе TLS

Основное назначение протокола TLS - создание защищенного канала связи между двумя взаимодействующими сторонами, обладающего следующими свойствами:

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

- конфиденциальностью: обеспечивается за счет шифрования передаваемой информации;

- целостностью: обеспечивается за счет использования имитовставок передаваемых сообщений.

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

Каждая сессия характеризуется следующими параметрами безопасности, которые согласовываются в ходе работы протокола Handshake (см. раздел 6) и остаются неизменными для каждого соединения в рамках данной сессии:

- идентификатором сессии;

- сертификатом сервера;

- сертификатом клиента (в случае двусторонней аутентификации);

- криптонабором;

- общим сессионным секретным значением MS (формируется клиентом и сервером в ходе работы протокола Handshake, соответствующего полной схеме обмена сообщениями).

Каждое соединение характеризуется следующими параметрами безопасности, которые согласовываются в ходе протокола Handshake (см. раздел 6):

- строкой со случайными байтами r_C, задаваемой клиентом;

- строкой со случайными байтами r_S, задаваемой сервером;

- ключом клиента для вычисления имитовставки сообщения

;

- ключом клиента для проверки имитовставки сообщения

;

- ключом сервера для вычисления имитовставки сообщения

;

- ключом сервера для проверки имитовставки сообщения

;

- ключом клиента для зашифрования данных

;

- ключом клиента для расшифрования данных

;

- ключом сервера для зашифрования данных

;

- ключом сервера для расшифрования данных

;

- вектором инициализации клиента для зашифрования данных

;

- вектором инициализации клиента для расшифрования данных

;

- вектором инициализации сервера для зашифрования данных

;

- вектором инициализации сервера для расшифрования данных

Примечания

1 При первичном открытии сессии во время выполнения протокола Handshake вырабатываются как параметры сессии, так и параметры соединения.

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

5 Протокол Record

Получив данные от протоколов более высокого уровня, протокол Record формирует из них последовательность структур, именуемых записями. Затем сформированные записи передаются транспортному протоколу.

Записи состоят из заголовка, описывающего передаваемые данные, и самих данных, которые передаются в открытом или защищенном виде в зависимости от текущего состояния соединения. Передача заголовка всегда происходит в открытом виде.

Данные, полученные от протокола транспортного уровня, протокол Record интерпретирует как записи и формирует из них сообщения для протоколов верхнего уровня, опираясь на заголовки записей.

В настоящем разделе все действия будут описаны для одной фиксированной стороны взаимодействия (клиента или сервера), которая обладает ключом шифрования

, ключом вычисления имитовставки сообщения

, вектором инициализации IV^write для формирования записей и ключом расшифрования

, ключом проверки имитовставки сообщения

, вектором инициализации IV^read для чтения записей.

5.1 Состояние соединения

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

В каждый момент времени все записи обрабатываются в соответствии с текущим состоянием соединения. Установка и смена состояния соединения производятся после взаимного обмена сообщениями ChangeCipherSpec в рамках протокола Change Cipher Spec. Данное сообщение сигнализирует сторонам взаимодействия о том, что текущее состояние чтения/записи меняется на новое состояние, которое согласовано в результате выполнения протокола Handshake.

Состояния чтения/записи характеризуются следующими значениями: параметрами сессии, параметрами соединения, номером получаемой/пересылаемой записи seqnum (числом от 0 до SNMAX, где параметр SNMAX задается выбранным криптонабором), который увеличивается на единицу после каждой полученной/отправленной записи. При смене состояния чтения/записи номеру пересылаемой записи должно быть присвоено нулевое значение.

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

При создании нового соединения в рамках текущего соединения все сообщения протокола Handshake передаются в защищенном виде согласно состоянию чтения/записи, соответствующему текущему соединению, до тех пор, пока стороны не обменяются сообщениями ChangeCipherSpec и не сменят состояния чтения/записи.

5.2 Формирование записи

Каждая запись содержит следующие параметры: type, version, length, fragment. Первые три параметра type, version, length образуют заголовок записи, описанный в 5.2.2, и указывают на тип сообщения, версию протокола и длину передаваемых данных соответственно, а параметр fragment содержит фрагмент данных, передаваемых в открытом или защищенном виде. При этом с каждой записью неявно ассоциируется ее порядковый номер seqnum.

Часть данных, полученных от протоколов более высокого уровня и выделенных при фрагментации в соответствии с 5.2.1, переводится в структуру TLSPlaintext, которая задана следующим образом:

struct {

ContentType type;

ProtocolVersion version = {3, 3}; /*TLS v1.2 */

uint16 length;

opaque fragment[TLSPlaintext.length];

} TLSPlaintext;

enum {

change_cipher_spec(20), alert(21), handshake(22),

application_data(23), (255)

} ContentType;

struct {

uint8 major;

uint8 minor;

} ProtocolVersion;

Поле TLSPlaintext.fragment содержит фрагмент передаваемых данных в открытом виде.

При инициализации соединения до обмена сторонами сообщениями ChangeCipherSpec протокол Record оперирует незащищенными записями, которые формируются непосредственно в виде структур TLSPlaintext.

После обмена сообщениями ChangeCipherSpec все данные пересылаются в защищенном виде. При установлении сторонами защищенного режима пересылки данных протокол Record переводит данные структуры TLSPlaintext в защищенный вид, формируя из них структуру TLSCiphertext (формат структуры полностью совпадает с форматом структуры TLSPlaintext), которой затем оперирует при информационном обмене:

struct {

ContentType type;

ProtocolVersion version = {3, 3}; /*TLS v1.2 */

uint16 length;

opaque fragment[TLSCiphertext.length];

} TLSCiphertext;

Поле TLSCiphertext.fragment содержит фрагмент передаваемых данных в защищенном виде и формируется из поля TLSPlaintext.fragment в соответствии с согласованным криптонабором. Процесс формирования этого поля описан в 5.2.3.

Формирование защищенной записи из фрагмента данных, выделенного при фрагментации в соответствии с 5.2.1, выполняется в соответствии со следующими этапами, схематично отраженными на рисунке 2:

1 формирование незащищенной записи, имеющей структуру TLSPlaintext;

2 вычисление имитовставки в соответствии с 5.2.3.1 от конкатенации номера записи, заголовка незащищенной записи и данных незащищенной записи;

3 зашифрование данных незащищенной записи и имитовставки, полученной на предыдущем шаге;

4 формирование защищенной записи, имеющей структуру TLSCiphertext.

Примечания

1 На рисунке 2 под HDR и HDR' подразумеваются заголовки незащищенной и защищенной записей соответственно.

2 В соответствии с [1] процесс формирования записи протокола TLS 1.2 допускает наличие этапа сжатия данных, однако при работе протокола в соответствии с криптонаборами, описанными в настоящих рекомендациях, данный этап отсутствует. В связи с этим структура TLSCompressed, описанная в [1], считается идентичной структуре TLSPlaintext и в тексте настоящих рекомендаций не используется.

Рисунок 2 - Формирование защищенной записи

5.2.1 Фрагментация

Принятые с верхнего уровня данные разбиваются протоколом Record на фрагменты, помещаемые в поля TLSPlaintext.fragment. Значение поля TLSPlaintext.length не должно превышать 2¹⁴ (то есть размер поля TLSPlaintext.fragment не должен превышать 16 Кбайт).

Если состояние соединения подразумевает защиту данных, то структура TLSPlaintext используется для формирования структуры TLSCiphertext. При этом размер поля fragment структуры TLSCiphertext может оказаться больше размера соответствующего поля структуры TLSPlaintext из-за добавления имитовставки сообщения (это приводит к тому, что значение поля TLSCiphertext.length становится больше значения поля TLSPlaintext.length). При работе протокола в соответствии с криптонаборами, описанными в настоящих рекомендациях, значение поля TLSCiphertext.length не должно превышать 2¹⁴ + 16.

Одно сообщение протокола, работающего над протоколом Record, может быть разбито на несколько фрагментов. Одному фрагменту могут принадлежать данные нескольких сообщений одного типа, то есть сообщений одного протокола верхнего уровня. Запрещается посылать фрагменты нулевой длины для сообщений протокола Handshake и Change Cipher Spec, а также фрагментировать сообщения протокола Alert.

Способы фрагментации не влияют на корректность работы всего протокола TLS 1.2 и должны быть определены на этапе его реализации.

5.2.2 Формирование заголовка записи

Записи состоят из заголовка, описывающего передаваемые данные, и самого фрагмента данных. Каждая запись передается в открытом (структура TLSPlaintext) или защищенном (структура TLSCiphertext) виде в зависимости от текущего состояния соединения. В каждом из двух случаев заголовок передается в открытом виде, имеет длину 5 байтов и состоит из следующих полей:

type	-	тип сообщения (1 байт). Всего определено четыре типа сообщений: сообщения протокола Change Cipher Spec (тип 20), сообщения протокола Alert (тип 21), сообщения протокола Handshake (тип 22), сообщения протокола Application Data (тип 23);
version	-	версия протокола (2 байта). Данный параметр содержит внутренний идентификатор версии протокола TLS. Внутренний идентификатор версии протокола TLS 1.2, описанного в настоящих рекомендациях, равен (3, 3);
length	-	длина фрагмента данных в байтах (2 байта). Данный параметр определяет количество байтов, передаваемых в записи после ее заголовка. Значения полей TLSPlaintext.length и TLSCiphertext.length должны удовлетворять ограничениям, определенным в 5.2.1.

5.2.3 Защита данных

В настоящем пункте предполагается, что незащищенная запись с номером seqnum обозначается далее через Rec:

TLSPlaintext Rec.

В настоящем пункте предполагается, что защищенная запись с номером seqnum обозначается далее через PRec:

TLSCiphertext PRec.

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

PRec.fragment = RecENC, (1)

где значение RecENC вычисляется согласно 5.2.3.2.

5.2.3.1 Имитовставка сообщения

В настоящем подпункте предполагается, что ключ K_MAC соответствует ключу

для состояния записи и ключу

для состояния чтения.

Функция вычисления имитовставки сообщения MAC задается согласованным криптонабором в соответствии с 10.1.2.1.

Для записи Rec с номером seqnum имитовставка сообщения RecMAC вычисляется по формуле

RecMAC = MAC(K_MAC, MACData), (2)

где значение MACData определяется по формуле:

MACData = STR₈(seqnum)

|Rec.type|Rec.version|Rec.length|Rec.fragment. (3)

5.2.3.2 Шифрование

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

В настоящем подпункте предполагается, что ключ K_ENC соответствует ключу

для состояния записи и ключу

для состояния чтения, вектор инициализации IV - вектору инициализации IV^write для состояния записи и вектору инициализации IV^read для состояния чтения.

Функция зашифрования ENC задается согласованным криптонабором в соответствии с 10.1.2.2.

Для записи Rec с номером seqnum значение RecENC вычисляется по формуле

RecENC = ENC(K_ENC, IV, ENCData), (4)

где значение ENCData определяется по формуле

ENCData = Rec.fragment|RecMAC. (5)

6 Протокол Handshake

Протокол Handshake работает поверх протокола Record и используется для согласования нижеприведенных параметров сессии.

Идентификатор сессии	-	произвольная последовательность байтов, выработанная сервером для идентификации активной или возобновляемой сессии.
Сертификат стороны	-	сертификат в формате X.509, формирующийся в соответствии с Р 1323565.1.023. Аутентификация опционально может быть односторонней (аутентификация сервера клиентом, сертификат предоставляет только сервер) или двусторонней (двусторонняя аутентификация сервера и клиента, клиент и сервер обмениваются сертификатами).
Идентификатор криптонабора	-	идентификатор, определяющий набор алгоритмов и их параметров, использующихся в рамках данной сессии.
Значение MS (master secret)	-	общее секретное значение длиной 48 байтов, которое вырабатывается сторонами с помощью протокола выработки и подтверждения ключа (см. 6.4).
Значение флага возобновления	-	флаг, разрешающий/запрещающий повторные соединения в рамках данной сессии.

Протокол Handshake начинает свою работу с сообщения ClientHello, которое может быть послано клиентом по его собственной инициативе либо в качестве ответа на сообщение сервера HelloRequest.

Схема обмена сообщениями Handshake может быть полной или упрощенной.

Полная схема обмена сообщениями (см. рисунок 3) используется, если клиент в сообщении приветствия ClientHello в качестве идентификатора сессии указал пустую строку, либо в том случае, если сервер не смог найти в кэше сессий параметры сессии, соответствующей данному идентификатору. Более подробно процедура взаимодействия сторон в рамках полной схемы обмена сообщениями описана в 6.2.

Рисунок 3 - Полная схема обмена

сообщениями в протоколе Handshake

Примечания

1 На рисунке 3 символом "*" отмечены опциональные сообщения, которые передаются в случае двусторонней аутентификации.

2 Сообщение ChangeCipherSpec и сообщение Application Data формально относятся не к сообщениям протокола Handshake, а к протоколам Change Cipher Spec и Application Data соответственно (см. подробнее раздел 7 и раздел 9).

3 В соответствии с [1] протокол TLS 1.2 допускает возможность установления анонимного соединения без обмена сертификатами, однако в протоколе, соответствующем криптонаборам, описанным в настоящих рекомендациях, данная опция не должна быть использована.

4 В [1] определено также сообщение ServerKeyExchange, которое посылается сервером только в том случае, если в сообщении Certificate сервер указал недостаточно данных для формирования клиентом сообщения ClientKeyExchange (см. 6.4.5). Однако в рамках протокола, соответствующего криптонаборам, описанным в настоящих рекомендациях, сертификат сервера содержит достаточно данных для формирования сообщения ClientKeyExchange, поэтому сообщение ServerKeyExchange пересылаться не должно.

Если клиент хочет создать соединение в рамках существующей сессии, то в сообщении приветствия ClientHello он должен указать идентификатор этой сессии. Если сервер смог найти в кэше сессий параметры сессии, соответствующей данному идентификатору, процесс обмена сообщениями протокола Handshake происходит по упрощенной схеме (см. рисунок 4). Более подробно процедура взаимодействия сторон в рамках упрощенной схемы обмена сообщениями в протоколе Handshake описана в 6.2.

Рисунок 4 - Упрощенная схема обмена

сообщениями в протоколе Handshake

Примечание - Сообщение ChangeCipherSpec и сообщение Application Data формально относятся не к сообщениям протокола Handshake, а к протоколам Change Cipher Spec и Application Data соответственно (см. подробнее раздел 7 и раздел 9).

Во время упрощенной схемы работы протокола Handshake стороны не вырабатывают новое общее сессионное секретное значение MS. Для выработки ключевого материала, необходимого для работы протокола Record в рамках устанавливаемого соединения, используется значение MS, выработанное при выполнении полной схемы протокола Handshake, в ходе которой были установлены параметры сессии с данным идентификатором.

6.1 Формат сообщений протокола Handshake

Каждое сообщение протокола Handshake содержит специальный заголовок, состоящий из 4 байтов. Первый байт содержит код типа сообщения, три следующих байта - длину сообщения:

enum {

hello_request(0), client_hello(1), server_hello(2),

certificate(11), certificate_request(13),

server_hello_done(14), certificate_verify(15),

client_key_exchange(16), finished(20), (255)

} HandshakeType;

struct {

HandshakeType msg_type; /* handshake type */

uint24 length; /* bytes in message */

select (HandshakeType) {

case hello_request: HelloRequest;

case client_hello: ClientHello;

case server_hello: ServerHello;

case certificate: Certificate;

case certificate_request: CertificateRequest;

case server_hello_done: ServerHelloDone;

case certificate_verify: CertificateVerify;

case client_key_exchange: ClientKeyExchange;

case finished: Finished;

} body;

} Handshake;

Далее по тексту установлено, что под терминами "сообщение HelloRequest", "сообщение ClientHello", ..., "сообщение Finished" подразумевается набор данных, определяемых структурой Handshake (в частности, имеющий поля Handshake.msg_type и Handshake.length), описанной выше, для которых поле Handshake.msg_type содержит значения hello_request (0), client_hello (1), ..., finished(20) соответственно.

В настоящих рекомендациях определено, что строки HelloRequest, ClientHello, ..., Finished являются байтовыми представлениями сообщений HelloRequest, ClientHello, ..., Finished соответственно (см. 3.2).

6.2 Процедуры взаимодействия сторон

В настоящем разделе представлены две процедуры взаимодействия сторон:

а) процедура взаимодействия сторон в рамках полной схемы обмена сообщениями в протоколе Handshake (см. таблицу 1);

б) процедура взаимодействия сторон в рамках упрощенной схемы обмена сообщениями в протоколе Handshake (см. таблицу 2).

Таблица 1

Процедура взаимодействия сторон в рамках полной

схемы обмена сообщениями в протоколе Handshake

Формирование параметров и действия со стороны клиента C

Передаваемые сообщения

Формирование параметров и действия со стороны сервера S

Выработка случайного значения r_C

Выработка случайного значения r_S

Этап выработки общего секрета

Выработка общего секрета PS (выбирается случайно из B₃₂)

Формирование эфемерного ключа на кривой, соответствующей Q_S:

Q_EPH = k_EPHP,

где k_EPH выбирается случайно из

H = HASH(r_C|r_S);

Формирование экспортного представления общего секрета PS:

IV = H[25..24 + n/2];

H = HASH(r_C|r_S);

Извлечение общего секрета из экспортного представления:

IV = H[25..24 + n/2];

sgn_C = SIGN(k_C, HM₁)

Проверка sgn_C

Этап выработки ключей из значения PS

Выработка общего сессионного секретного значения:

MS = PRF(PS, "extended master secret", HASH(HM₁))

Выработка общего сессионного секретного значения:

MS = PRF(PS, "extended master secret", HASH(HM₁))

ИС МЕГАНОРМ: примечание.

Текст в графе "Формирование параметров и действия со стороны клиента C" дан в соответствии с официальным текстом документа.

Генерация ключевого материала соединения:

Этап подтверждения ключа

client_verify_data = PRF(MS, "client finished", HASH(HM₂))

server_verify_data = PRF(MS, "server finished", HASH(HM₃))

Примечания

1 Переменные HM₁, HM₂ и HM₃ заданы в соответствии с 6.2.1.

2 В таблице 1 символом "*" отмечены опциональные сообщения, которые передаются в случае двусторонней аутентификации.

Таблица 2

Процедура взаимодействия сторон в рамках упрощенной схемы

обмена сообщениями в протоколе Handshake

Формирование параметров и действия со стороны клиента C	Передаваемые сообщения	Формирование параметров и действия со стороны сервера S
Выработка случайного значения r_C
		Выработка случайного значения r_S
Этап выработки ключей из значения MS
Генерация ключевого материала соединения:		Генерация ключевого материала соединения:
Этап подтверждения ключа

		server_verify_data = PRF(MS, "server finished", HASH(HM₃))

client_verify_data = PRF(MS, "client finished", HASH(HM₂))

Примечание - Переменные HM₂ и HM₃ заданы в соответствии с 6.2.1.

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

Подробное описание каждого из сообщений приведено в 6.3, 6.4.

6.2.1 Задание переменных HM₁, HM₂, HM₃

Переменные HM_i, 1 <= i <= 3 определены в соответствии с таблицей 3.

Таблица 3

Задание переменных HM_i

Переменная	Полная схема (односторонняя аутентификация)	Полная схема (двусторонняя аутентификация)	Упрощенная схема
HM₁	CH\|SH\|SCT\|SHD\|CKE	CH\|SH\|SCT\|CR\|SHD\|CCT\|CKE	Не используется
HM₂	CH\|SH\|SCT\|SHD\|CKE	CH\|SH\|SCT\|CR\|SHD\|CCT\|CKE\|CV	CH\|SH\|SF
HM₃	CH\|SH\|SCT\|SHD\|CKE\|CF	CH\|SH\|SCT\|CR\|SHD\|CCT\|CKE\|CV\|CF	CH\|SH

Примечания

1 В таблице 3 использованы следующие обозначения для строк, соответствующих байтовым представлениям сообщений протокола Handshake: CH - ClientHello, SH - ServerHello, SCT - Certificate со стороны сервера, CR - CertificateRequest, SHD - ServerHelloDone, CCT - Certificate со стороны клиента, CKE - ClientKeyExchange, CV - CertificateVerify, CF - Finished со стороны клиента, SF - Finished со стороны сервера.

2 Данные, пересылаемые в сообщении запроса приветствия HelloRequest, сообщении протокола Change Cipher Spec и сообщениях протокола Alert, не включаются в переменные HM₁, HM₂ и HM₃.

6.3 Сообщения приветствия

6.3.1 Сообщение запроса приветствия HelloRequest

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

Данное сообщение должно быть проигнорировано клиентом, если в этот момент он уже участвует в процессе согласования параметров сессии. Если клиент отказывается пересогласовать параметры сессии, то он может проигнорировать это сообщение либо послать в ответ оповещение no_renegotiation (см. раздел 8).

Если сервер послал сообщение запроса приветствия HelloRequest, но не дождался сообщения ClientHello в качестве ответа со стороны клиента, он может закрыть соединение, передав оповещение об ошибке с уровнем fatal (см. раздел 8).

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

6.3.2 Сообщение приветствия клиента ClientHello

Клиент посылает сообщение приветствия ClientHello в одном из следующих случаев:

- клиент впервые подключается к серверу;

- как ответ на сообщение запроса приветствия HelloRequest;

- с целью пересогласования параметров сессии.

Сообщение ClientHello содержит следующие параметры:

версия протокола (client_version)	-	максимальная версия протокола из тех, которые готов поддерживать клиент [настоящие рекомендации описывают криптонаборы для протокола TLS 1.2, для которого значение версии равняется (3, 3)];
строка со случайными данными (random)	-	строка данных длины 32 байта, выработанная клиентом, в которой первые 4 байта занимает значение текущего времени в 32-битном формате UNIX [количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года], а остальные 28 байтов занимает строка, выработанная случайным образом;
идентификатор сессии (session_id)	-	идентификатор сессии, выбранный клиентом. Если данное поле пусто, значит, клиент хочет согласовать параметры новой сессии;
список криптонаборов (cipher_suites)	-	список криптонаборов, которые поддерживает клиент. Порядок криптонаборов в списке отражает их степень предпочтения (предпочтительные идут первыми). Если поле ClientHello.session_id не пустое, поле ClientHello.cipher_suites должно содержать идентификатор криптонабора, согласованного во время установления параметров сессии, имеющей идентификатор ClientHello.session_id;
список методов сжатия (compression_methods)	-	данная версия протокола не поддерживает методы сжатия, и поле должно содержать 1 байт со значением 0, соответствующим методу с идентификатором null;
расширения (extensions)	-	криптонаборы, описанные в настоящих рекомендациях, предполагают наличие трех обязательных расширений со стороны клиента: signature_algorithms, extended_master_secret и renegotiation_info.

Сообщение ClientHello имеет следующую структуру:

struct {

ProtocolVersion client_version;

Random random;

SessionID session_id;

CipherSuite cipher_suites<2..2^16-2>;

CompressionMethod compression_methods<1..2^8-1>;

Extension extensions<0..2^16-1>;

} ClientHello;

После отправки сообщения ClientHello клиент ожидает от сервера сообщения ServerHello. В ответ на любое другое сообщение протокола Handshake (за исключением сообщения запроса приветствия HelloRequest) клиент должен ответить оповещением об ошибке с уровнем fatal (см. раздел 8).

6.3.3 Сообщение приветствия сервера ServerHello

Данное сообщение отправляется сервером после получения им сообщения ClientHello при условии, что среди параметров, переданных клиентом в сообщении приветствия, присутствует поддерживаемый сервером набор параметров установления соединения.

Сообщение приветствия содержит следующие параметры:

версия протокола (server_version)	-	максимальная поддерживаемая сервером версия протокола, не превосходящая версии клиента client_version. Примечание - Организация обратной совместимости проводится в соответствии с приложением Е [1];
строка со случайными данными (random)	-	строка данных длины 32 байта, выработанная сервером, в которой первые 4 байта занимает значение текущего времени в 32-битном формате UNIX [количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года], а остальные 28 байтов занимает строка, выработанная случайным образом;
идентификатор сессии (session_id)	-	идентификатор сессии, в рамках которой осуществляется соединение. Если поле ClientHello.session_id не было пустым, тогда в кэше сессий сервер ищет параметры сессии, соответствующей данному идентификатору. Если такая сессия существует и сервер готов создать соединение в рамках данной сессии, он присваивает то же значение идентификатора сессии полю ServerHello.session_id. Если поле ClientHello.session_id было пустым либо если сервер не нашел параметры сессии, соответствующей данному идентификатору, сервер задает новое значение идентификатора, указывающего на создаваемую сессию. Сервер может послать пустое значение идентификатора. Это будет означать, что параметры данной сессии не будут храниться в кэше сервера и повторное создание соединения в рамках данной сессии будет невозможно;
криптонабор (cipher_suite)	-	криптонабор, который сервер выбирает из списка ClientHello.cipher_suites. Если значение ClientHello.session_id не нулевое, данный параметр должен содержать идентификатор криптонабора, согласованного в сессии ClientHello.session_id;
метод сжатия (compression_method)	-	данная версия протокола не поддерживает методы сжатия, и поле должно содержать 1 байт со значением 0, соответствующим методу с идентификатором null;
расширения (extensions)	-	криптонаборы, описанные в настоящих рекомендациях, предполагают наличие двух обязательных расширений со стороны сервера: extended_master_secret и renegotiation_info.

Сообщение ServerHello имеет следующую структуру:

struct {

ProtocolVersion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

CompressionMethod compression_method;

Extension extensions<0..2^16-1>;

} ServerHello;

6.3.4 Расширения (extensions)

Каждое расширение, посылаемое клиентом и сервером, имеет следующую структуру:

struct {

ExtensionType extension_type;

opaque extension_data<0..2^16-1>;

} Extension;

enum {

signature_algorithms(13),

extended_master_secret (23),

renegotiation_info(65281), (65535)

} ExtensionType;

6.3.4.1 Расширение signature_algorithms

Расширение signature_algorithms является обязательным только для клиента и не пересылается сервером. Данное расширение содержит список пар алгоритмов подписи и хэширования, поддерживаемых клиентом.

Данное расширение имеет тип 13. Поле extension_data расширения signature_algorithms, пересылаемого клиентом, содержит параметр supported_signature_algorithms, который задан следующим способом:

SignatureAndHashAlgorithm

supported_signature_algorithms<2..2^16-2>;

struct {

HashAlgorithm hash;

SignatureAlgorithm signature;

} SignatureAndHashAlgorithm;

Значения элементов списка supported_signature_algorithms, допустимые к использованию в рамках настоящих рекомендаций, заданы в 10.2.

Примечание - Если при согласовании одного из криптонаборов, определенных в разделе 10, клиент не может сформировать расширение signature_algorithms, содержащее допустимые для данных криптонаборов значения, перечисленные в 10.2, сервер должен либо завершить соединение с оповещением handshake_failure (см. раздел 8), либо проигнорировать информацию, указанную в данном расширении, и продолжить работу в соответствии со сценарием, в котором данное расширение содержит значения {0x08, 0x40} и {0x08, 0x41}.

6.3.4.2 Расширение extended_master_secret

Данное расширение всегда посылается клиентом и сервером и сигнализирует о том, что клиент и сервер используют расширенный вариант генерации значения общего секретного значения MS в соответствии с 6.4.7.

Данное расширение пересылается пустым и имеет тип 23.

Примечание - Описание расширения extended_master_secret соответствует [2].

6.3.4.3 Расширение renegotiation_info

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

Данное расширение имеет тип 65281. Поле extension_data расширения renegotiation_info, пересылаемого клиентом, содержит структуру RenegotiationInfo, которая задана следующим образом:

struct {

opaque renegotiated_connection<0..255>;

} RenegotiationInfo;

Если сообщения протокола Handshake посылаются впервые, то есть не в рамках ранее созданного соединения, поле renegotiated_connection должно оставаться пустым как в сообщении ClientHello, так и в сообщении ServerHello.

Если сообщение приветствия клиента ClientHello передается в рамках ранее созданного соединения, поле renegotiated_connection должно содержать данные client_verify_data, которые пересылались клиентом в поле verify_data сообщения Finished во время выполнения протокола Handshake, в результате которого создано текущее соединение.

Если сообщение приветствия сервера ServerHello передается в рамках ранее созданного соединения, поле renegotiated_connection должно содержать конкатенацию данных client_verify_data и server_verify_data, которые пересылались клиентом и сервером соответственно в поле verify_data сообщения Finished во время выполнения протокола Handshake, в результате которого создано текущее соединение.

При отсутствии корректно сформированного расширения renegotiation_info в сообщениях ClientHello или ServerHello проверяющая данное сообщение сторона должна ответить оповещением об ошибке с уровнем fatal (см. раздел 8).

Примечание - Описание расширения renegotiation_info соответствует [3].

6.4 Выработка и подтверждение ключа

6.4.1 Сообщение с сертификатом сервера Certificate

Данное сообщение посылается сервером и содержит цепочку сертификатов. Сертификат сервера следует первым в данной цепочке и содержит открытый ключ сервера.

Каждый сертификат из цепочки сертификатов сервера должен быть подписан в соответствии с одной из пар алгоритмов из расширения signature_algorithms.

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

Структура данного сообщения выглядит следующим образом:

opaque ASN.1Cert<1..2^24-1>;

struct {

ASN.1Cert certificate_list<0..2^24-1>;

} Certificate;

6.4.2 Сообщение запроса сертификата CertificateRequest

Данное сообщение посылается сервером в случае двусторонней аутентификации.

Сообщение запроса сертификата содержит следующие параметры:

типы сертификатов (certificate_types)	-	список типов сертификатов, поддерживаемых сервером. Значения элементов списка certificate_types, допустимые к использованию в рамках настоящих рекомендаций, заданы в 10.3;
поддерживаемые алгоритмы подписи и хэширования (supported_signature_algorithms)	-	пары алгоритмов подписи и хэширования, указывающие на то, с помощью каких алгоритмов могут быть подписаны сертификаты из цепочки сертификатов клиента. Ключ проверки подписи, хранящийся в сертификате клиента, должен также соответствовать одному из алгоритмов подписи (не обязательно тому же, которым подписан сертификат), перечисленных в поле supported_signature_algorithms;
удостоверяющие центры (certificate_authorities)	-	список допустимых удостоверяющих центров (УЦ), представленных в формате кодирования DER. Данный список может задавать допустимые имена для корневых УЦ или для подчиненных УЦ. Если данное поле остается пустым, то клиент может посылать любой сертификат, соответствующий полю certificate_types.

Структура данного сообщения выглядит следующим образом:

struct {

ClientCertificateType certificate_types<1..2^8-1>;

SignatureAndHashAlgorithm

supported_signature_algorithms<2..2^16-2>;

DistinguishedName certificate_authorities<0..2^16-1>;

} CertificateRequest;

Структура SignatureAndHashAlgorithm задана в 6.3.4.1.

Тип DistinguishedName определен следующим образом:

opaque DistinguishedName<1..2^16-1>;

6.4.3 Сообщение о завершении приветствия ServerHelloDone

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

Структура данного сообщения выглядит следующим образом:

struct { } ServerHelloDone;

6.4.4 Сообщение с сертификатом клиента Certificate

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

Каждый из сертификатов цепочки сертификата клиента должен быть подписан в соответствии с одной из пар алгоритмов из списка CertificateRequest.supported_signature_algorithms.

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

Структура данного сообщения идентична структуре, приведенной в 6.4.1.

6.4.5 Сообщение с ключом обмена клиента ClientKeyExchange

Данное сообщение посылается клиентом и содержит экспортное представление PSExp секретного значения PS и эфемерный ключ Q_EPH.

Для формирования сообщения ClientKeyExchange клиент выполняет следующие шаги:

- вырабатывает секретное значение PS, выбирая его случайно из множества B₃₂;

- выбирает случайное значение k_EPH из множества {1,...,q-1};

- формирует эфемерный ключ Q_EPH = k_EPH·P;

- с помощью алгоритма KEG, описанного в 6.4.5.1, формирует ключи экспорта

следующим образом:

(6)

- формирует экспортное представление общего секрета PS:

(7)

Структура данного сообщения выглядит следующим образом:

enum { vko_kdf_gost } KeyExchangeAlgorithm;

struct {

select (KeyExchangeAlgorithm) {

case vko_kdf_gost: GostKeyTransport;

} exchange_keys;

} ClientKeyExchange;

Структура GostKeyTransport определена следующим образом:

GostKeyTransport ::= SEQUENCE {

keyExp OCTET STRING,

ephemeralPublicKey SubjectPublicKeyInfo

ukm OCTET STRING OPTIONAL

}

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING

}

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY OPTIONAL

}

Здесь в поле keyExp передается экспортное представление ключа PSExp, поле ephemeralPublicKey задано структурой SubjectPublicKeyInfo (см. ГОСТ Р ИСО/МЭК 9594-8-98, раздел 8) и содержит информацию о параметре Q_EPH, а поле ukm должно быть проигнорировано сервером.

Получив сообщение ClientKeyExchange, сервер выполняет следующие шаги:

- проверяет выполнение следующих трех условий и в случае невыполнения одного из них прекращает взаимодействие, посылая оповещение об ошибке с уровнем fatal (см. раздел 8):

1 точка Q_EPH принадлежит кривой, соответствующей открытому ключу сервера;

2 точка Q_EPH не равна нулевой точке O;

3 q·Q_EPH = 0;

- формирует ключи экспорта

(8)

- извлекает общий секрет PS из экспортного представления PSExp:

(9)

6.4.5.1 Алгоритм выработки ключей экспорта KEG

Алгоритм выработки ключей экспорта KEG принимает на вход закрытый ключ d, открытый ключ Q и строку

. Результатом работы данного алгоритма является строка длины 64 байта или сообщение об ошибке.

Если точка Q не принадлежит циклической подгруппе порядка q группы точек эллиптической кривой, содержащей открытый ключ, соответствующий закрытому ключу d, алгоритм KEG завершается сообщением об ошибке. Иначе алгоритм выработки ключей экспорта задается одним из двух способов в зависимости от длины закрытого ключа.

Если длина закрытого ключа d равна 64 байта (512 битов), алгоритм KEG определен следующим образом:

KEG(d, Q, h) = VKO₅₁₂(d, Q, UKM), (10)

где в качестве функции VKO_5]2 использован алгоритм VKO_GOSTR3410_2012_512, определенный в Р 50.1.113-2016 (4.3.2), а параметр UKM задан следующим образом:

(11)

Если длина закрытого ключа d равна 32 байта (256 битов), алгоритм KEG определен следующим образом:

KEG(d, Q, h) = KDFTREE₂₅₆(K_EXP, "kdf tree", seed, 1), (12)

где в качестве функции KDFTREE₂₅₆ использован алгоритм диверсификации KDF_TREE_GOSTR3411_2012_256, определенный в Р 50.1.113-2016 (4.5), результатом работы которого является строка

, а параметры K_EXP и seed заданы следующим образом:

(13)

где в качестве функции VKO₂₅₆ использован алгоритм VKO_GOSTR3410_2012_256, определенный в Р 50.1.113-2016 (4.3.1).

6.4.6 Сообщение проверки сертификата CertificateVerify

Если сервером послано сообщение запроса сертификата CertificateRequest, клиентом пересылается сообщение проверки сертификата CertificateVerify, которое содержит значение

sgn_C = SIGN(k_C, HM₁), (14)

где:

- SIGN - функция формирования подписи, задаваемая согласованным алгоритмом подписи (см. 10.2);

- параметр HM₁ задан в соответствии с 6.2.1.

Структура данного сообщения выглядит следующим образом:

struct {

SignatureAndHashAlgorithm algorithm;

opaque signature<0..2^16-1>;

} CertificateVerify;

При этом поле CertificateVerify.signature содержит значение sgn_C.

Получив сообщение CertificateVerify, сервер проверяет значение подписи с помощью ключа проверки подписи Q_C, полученного из сертификата клиента.

6.4.7 Сообщение завершения протокола Handshake Finished

Клиент и сервер вырабатывают общее секретное значение MS длины 48 байтов:

MS = LMB₄₈(PRF(PS, "extended master secret",

HASH(HM₁))), (15)

где параметр HM₁ задан в соответствии с 6.2.1.

Клиент вырабатывает ключи вычисления имитовставки, ключи шифрования и векторы инициализации для каждого из состояний чтения/записи:

(16)

Сервер вырабатывает ключи вычисления имитовставки, ключи шифрования и векторы инициализации для каждого из состояний чтения/записи:

(17)

Непосредственно после отправки сообщения изменения состояния ChangeCipherSpec клиент посылает сообщение Finished, которое содержит в себе данные client_verify_data, сформированные следующим образом:

client_verify_data =

= LMB₃₂(PRF(MS, "client finished", HASH(HM₂))), (18)

где параметр HM₂ задан в соответствии с 6.2.1.

Непосредственно после отправки сообщения изменения состояния ChangeCipherSpec сервер посылает сообщение Finished, которое содержит в себе данные server_verify_data, сформированные следующим образом:

server_verify_data =

= LMB₃₂(PRF(MS, "server finished", HASH(HM₃))), (19)

где параметр HM₃ задан в соответствии с 6.2.1.

Структура данного сообщения выглядит следующим образом:

struct {

opaque verify_data[verify_data_length];

} Finished;

где параметр verify_data_length принимает значение 32.

При получении сообщения Finished клиент и сервер должны проверить корректность данных, пересылаемых в поле verify_data.

7 Протокол Change Cipher Spec

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

Сообщение протокола Change Cipher Spec состоит из 1 байта, принимающего значение 1.

struct {

enum { change_cipher_spec(1), (255) } type;

} ChangeCipherSpec;

8 Протокол Alert

Каждое сообщение протокола Alert содержит информацию о пересылаемом оповещении:

struct {

AlertLevel level;

AlertDescription description;

} Alert;

Поле level (уровень оповещения) задается 1 байтом и может принимать следующие значения:

- warning: оповещения с таким уровнем не требуют немедленного прекращения соединения в общем случае. При получении данного оповещения сторона взаимодействия может принять решение о продолжении работы или о закрытии соединения. В последнем случае она должна послать ответное оповещение с уровнем fatal;

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

enum {

warning(1),

fatal(2), (255)

} AlertLevel;

Поле description (описание оповещения) задается 1 байтом, соответствующим определенному типу оповещения, описанному в структуре AlertDescription:

enum {

close_notify(0),

unexpected_message(10),

bad_record_mac(20),

record_overflow(22),

handshake_failure(40),

bad_certificate(42),

unsupported_certificate(43),

certificate_revoked(44),

certificate_expired(45),

certificate_unknown(46),

illegal_parameter(47),

unknown_ca(48),

access_denied(49),

decode_error(50),

decrypt_error(51),

protocol_version(70),

insufficient_security(71),

internal_error(80),

user_canceled(90),

no_renegotiation(100),

unsupported_extension(110), (255)

} AlertDescription;

Примечание - В протоколе, соответствующем криптонаборам, описанным в настоящих рекомендациях, оповещения decryption_failed_RESERVED (21), decompression_failure (30), no_certificate_RESERVED (41) и export_restriction_RESERVED (60), описанные в [1], пересылаться не должны.

Стороны взаимодействия посылают оповещения в двух случаях:

- стороны хотят корректно завершить соединение (см. 8.1);

- в процессе выполнения протокола произошла ошибка (см. 8.2).

8.1 Оповещения закрытия соединения

Клиент и сервер должны всегда обмениваться друг с другом информацией о завершении соединения. Если в процессе работы протокола TLS 1.2 не возникло ни одного оповещения с уровнем fatal, при окончании взаимодействия каждая сторона обязана послать сообщение закрытия соединения close_notify, которое предназначено для осуществления корректного завершения соединения.

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

Рекомендуется присваивать оповещению закрытия соединения close_notify уровень warning.

8.2 Оповещения об ошибках

В случае возникновения ошибки в процессе работы протокола TLS 1.2 сторона взаимодействия посылает оповещение об ошибке.

Настоящие рекомендации определяют оповещения об ошибке в соответствии с таблицами 4 - 6.

Таблица 4

Оповещения об ошибке, которые могут возникнуть

в процессе работы протокола Handshake

Наименование оповещения	Условия и порядок использования оповещения
handshake_failure	Отправитель не смог согласовать необходимые параметры безопасности. Данное оповещение всегда должно иметь уровень fatal
illegal_parameter	Поле сообщения протокола Handshake некорректно либо не согласуется с другими полями. Данное оповещение всегда должно иметь уровень fatal
unknown_ca	Сертификат УЦ не был найден или не совпал ни с одним из известных сертификатов доверенных УЦ. Данное оповещение всегда должно иметь уровень fatal
access_denied	Получен корректный сертификат, однако при применении политики контроля доступа отправитель решил не продолжать согласование соединения. Данное оповещение всегда должно иметь уровень fatal
decrypt_error	При выполнении криптографической операции (например, при проверке подписи, проверке сообщения завершения Finished) во время работы протокола Handshake возникла ошибка. Данное оповещение всегда должно иметь уровень fatal
protocol_version	Версия протокола, указанная клиентом, распознана корректно, однако не поддерживается сервером. Данное оповещение всегда должно иметь уровень fatal
insufficient_security	Посылается вместо оповещения handshake_failure в том случае, если сервер требует криптонаборы, обеспечивающие более высокий уровень стойкости, чем те, которые поддерживает клиент. Данное оповещение всегда должно иметь уровень fatal
unsupported_extension	Данное оповещение посылается клиентом и сигнализирует о том, что в сообщении ServerHello содержалось расширение, которое не послано клиентом в сообщении ClientHello. Данное оповещение всегда должно иметь уровень fatal
bad_certificate	Сертификат поврежден, содержит некорректную подпись и т.п. Рекомендуется присваивать данному оповещению уровень fatal
unsupported_certificate	Получен сертификат неподдерживаемого типа. Рекомендуется присваивать данному оповещению уровень fatal
certificate_revoked	Сертификат отозван подписывающей стороной. Рекомендуется присваивать данному оповещению уровень fatal
certificate_expired	Срок действия сертификата истек или сертификат не действует в настоящее время. Рекомендуется присваивать данному оповещению уровень fatal
certificate_unknown	При обработке сертификата возникла некоторая ошибка, не соответствующая никаким из случаев, перечисленных выше. Рекомендуется присваивать данному оповещению уровень fatal
user_canceled	Работа протокола Handshake остановлена по некоторым причинам, не связанным с ошибками в работе протокола. Данное оповещение должно сопровождаться оповещением close_notify. Рекомендуется присваивать данному оповещению уровень warning
no_renegotiation	Данное оповещение посылается клиентом в ответ на сообщение HelloRequest или сервером в ответ на сообщение ClientHello при взаимодействии в рамках ранее установленного соединения с целью оповещения получателя о том, что отправитель данного оповещения не поддерживает пересогласование параметров сессии. При получении данного оповещения вторая сторона должна принять решение о продолжении взаимодействия. Данное оповещение всегда должно иметь уровень warning

Если оповещения bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown были посланы с уровнем warning, непосредственно после их получения принимающая сторона должна закрыть соединение либо с оповещением close_notify, либо с оповещением об ошибке, имеющим уровень fatal.

Таблица 5

Оповещения об ошибке, которые могут возникнуть

в процессе работы протокола Record

Наименование оповещения	Условия и порядок использования оповещения
bad_record_mac	Данное оповещение посылается в том случае, если при обработке полученной записи возникла ошибка при проверке значения имитовставки. Данное оповещение всегда должно иметь уровень fatal
record_overflow	Данное оповещение посылается в том случае, если длина полученной записи превышает максимально допустимое значение. Данное оповещение всегда должно иметь уровень fatal

Таблица 6

Общие оповещения об ошибке, которые могут возникать

в процессе работы протокола TLS 1.2 в соответствии

с криптонаборами, описанными в настоящих рекомендациях

Наименование оповещения	Условия и порядок использования оповещения
unexpected_message	Получено некорректное сообщение. Данное оповещение всегда должно иметь уровень fatal
decode_error	Сообщение не может быть обработано, так как содержит одно или несколько некорректных полей. Данное оповещение всегда должно иметь уровень fatal
internal_error	Произошла внутренняя ошибка, не связанная с работой протокола (например, ошибка выделения памяти), которая делает невозможным продолжение дальнейшей работы протокола. Данное оповещение всегда должно иметь уровень fatal

9 Протокол Application Data

Прикладные данные передаются после отправки стороной взаимодействия сообщения Finished. Прикладные данные защищаются в соответствии с текущим состоянием соединения, которое установлено при выполнении протокола Handshake. Сообщения протокола Application Data содержат фрагмент данных, принятых от протокола верхнего уровня, и передаются протоколу Record без дополнительного форматирования.

10 Использование российских криптографических алгоритмов

10.1 Идентификаторы криптонаборов из реестра "TLS Cipher Suites"

Настоящие рекомендации определяют следующие новые идентификаторы IANA из реестра "TLS Cipher Suites", указываемые в сообщениях ClientHello и ServerHello (см. таблицу 7).

Таблица 7

Идентификаторы криптонаборов реестра "TLS Cipher Suites"

Наименование криптонабора	Номер криптонабора
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC	{0xC1, 0x00}
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC	{0xC1, 0x01}

Каждый из вышеперечисленных идентификаторов определяет криптонабор, предназначенный для использования в протоколе TLS 1.2 и задающий криптографические параметры в соответствии с 10.1.1 - 10.1.5.

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

10.1.1 Блочный шифр

Определенные в настоящих рекомендациях криптонаборы (см. таблицу 8) в качестве блочного шифра используют шифр "Магма" или шифр "Кузнечик", определенные в ГОСТ Р 34.12. Длина блока составляет 16 байтов (n = 16) для шифра "Кузнечик" и 8 байтов (n = 8) для шифра "Магма", длина ключей в обоих случаях составляет 32 байта (k = 32).

Таблица 8

Используемые блочные шифры

Криптонабор	Блочный шифр
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC	"Магма" по ГОСТ Р 34.12-2015 (раздел 5)
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC	"Кузнечик" по ГОСТ Р 34.12-2015 (раздел 4)

10.1.2 Формирование защищенной записи

10.1.2.1 Алгоритм вычисления имитовставки сообщения

Определенные в настоящих рекомендациях криптонаборы в качестве алгоритма вычисления имитовставки сообщения используют режим выработки имитовставки, описанный в ГОСТ Р 34.13-2015 (5.6), с длиной имитовставки [параметром s, введенным в ГОСТ Р 34.13-2015 (5.6) для режима выработки имитовставки], равной n.

При этом для каждой формируемой записи с номером seqnum функция MAC задана нижеприведенным образом.

Входные аргументы:

, ключ вычисления имитовставки;

, t >= 0, открытый текст.

Результат работы:

- T, где

- имитовставка.

Функция MAC задана в соответствии со следующей формулой:

MAC(K, P) = T, (20)

где

(21)

В качестве функции OMAC(K, M) использована функция выработки имитовставки на ключе K от данных M, описанная в ГОСТ Р 34.13-2015 (5.6). Алгоритм TLSTREE выработки ключей защиты записей определен в соответствии с 10.1.2.3.

10.1.2.2 Алгоритм шифрования сообщений

Определенные в настоящих рекомендациях криптонаборы в качестве алгоритма шифрования записей используют режим CTR-ACPKM работы блочного шифра, описанный в Р 1323565.1.017-2018 (4.1).

При этом для каждой формируемой записи с номером seqnum функция зашифрования ENC задана нижеприведенным образом.

Входные аргументы:

, ключ шифрования;

, уникальный вектор;

, t >= 0, открытый текст.

Результат работы:

- C, где

- шифртекст.

Функция зашифрования ENC задана в соответствии со следующей формулой:

ENC(K, IV, P) = C, (22)

где

(23)

В качестве функции CTR-ACPKM-Encrypt(N, K^segnum, IV^segnum, P) использован блочный шифр, задающийся в соответствии с 10.1.1, в режиме CTR-ACPKM, определенном в Р 1323565.1.017-2018 (4.1), с длиной блока гаммы [параметром s, введенным в Р 1323565.1.017-2018 (4.1)], равной n, где:

- N - размер секции, определенный в соответствии с таблицей 9;

- K^segnum - начальный ключ;

- IV^seqnum - уникальный вектор;

- P - открытый текст.

Таблица 9

Размер секции N

Криптонабор	Размер секции N, Кбайт
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC	1
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC	4

Алгоритм TLSTREE выработки ключей защиты записей определен в соответствии с 10.1.2.3.

10.1.2.3 Алгоритм TLSTREE выработки ключей защиты записей

В настоящем разделе описывается алгоритм TLSTREE, используемый для порождения ключей защиты записей из корневого ключа

TLSTREE(K_root, i) = Divers₃(Divers₂(Divers₁(K_root,

STR₈(i&C₁)), STR₈(i&C₂)), STR₈(i&C₃)), (24)

где

- число

;

- алгоритм диверсификации ключа

по данным диверсификации

, который задан с помощью функции KDF₂₅₆, определяемой алгоритмом KDF_GOSTR3411_2012_256, описанным в Р 50.1.113-2016 (4.4):

(25)

- константы

определены используемым криптонабором в соответствии с таблицей 10.

Таблица 10

Параметры ключевого дерева

Криптонабор	Константы C₁, C₂, C₃
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC	C₁ = 0xFFFFFFC000000000, C₂ = 0xFFFFFFFFFE000000, C₃ = 0xFFFFFFFFFFFFF000
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC	C₁ = 0xFFFFFFFF00000000, C₂ = 0xFFFFFFFFFFF80000, C₃ = 0xFFFFFFFFFFFFFFC0

10.1.3 Максимальное количество записей в соединении

Параметр SNMAX задает максимальное количество записей, которые могут передаваться в рамках одного соединения (номер записи seqnum может принимать значения от 0 до SNMAX включительно), и определяется в соответствии с таблицей 11.

Таблица 11

Максимальное количество записей в соединении

Криптонабор	SNMAX
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC	2³² - 1
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC	2⁶⁴ - 1

10.1.4 Хэш-функция

Определенные в настоящих рекомендациях криптонаборы в качестве хэш-функции HASH используют хэш-функцию, описанную в ГОСТ Р 34.11, с длиной выхода 32 байта (256 битов).

10.1.5 Функция PRF

Определенные в настоящих рекомендациях криптонаборы в качестве функции PRF используют псевдослучайную функцию PRF_TLS_GOSTR3411_2012_256, описанную в Р 50.1.113-2016 (4.2.1.1).

10.2 Идентификаторы алгоритмов подписи из реестра "TLS SignatureAlgorithm"

Настоящие рекомендации вводят следующие новые идентификаторы IANA из реестра "TLS SignatureAlgorithm", указываемые в расширении signature_algorithms сообщения ClientHello и в поле supported_signature_algorithms сообщения CertificateRequest:

enum {

gostr34102012_256(0x40),

gostr34102012_512(0x41),

(0xFF)

} SignatureAlgorithm;

Вышеперечисленные идентификаторы 0x40 и 0x41 соответствуют алгоритму подписи, определенному в ГОСТ Р 34.10, с длиной ключа 32 байта (256 битов) и 64 байта (512 битов) соответственно.

В соответствии с [4] алгоритм подписи, определенный в ГОСТ Р 34.10, с длиной ключа 32 байта (256 битов) или 64 байта (512 битов) использует алгоритм хэширования, определенный в ГОСТ Р 34.11, с длиной выхода 32 байта (256 битов) или 64 байта (512 битов) соответственно. Таким образом, если поле SignatureAndHashAlgorithm.signature одной из пар алгоритмов подписи и хэширования содержит значение 0x40 (gostr34102012_256) или 0x41 (gostr34102012_512), поле SignatureAndHashAlgorithm.hash указанной пары должно содержать значение 0x08 (Intrinsic).

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

Входные аргументы:

- 0 < k_C < q_C - ключ подписи клиента, где q_C - порядок подгруппы группы точек эллиптической кривой, соответствующей ключу проверки подписи Q_C;

- произвольная байтовая строка.

Результат работы:

, где

Функция SIGN задана в соответствии со следующей формулой:

(26)

где:

- SIGNGOST(k_C, M) - алгоритм подписи, выдающий в качестве результата своей работы пару чисел (r, s), выработанных в результате вычисления значения подписи сообщения M на ключе подписи k_C в соответствии с алгоритмом подписи, определенным в ГОСТ Р 34.10, с параметрами, соответствующими кривой, которой принадлежит ключ проверки подписи Q_C;

- l = 32 для алгоритма подписи SIGNGOST, соответствующего алгоритму подписи, определенному в ГОСТ Р 34.10, с длиной ключа 256 битов, и l = 64 для алгоритма подписи SIGNGOST, соответствующего алгоритму подписи, определенному в ГОСТ Р 34.10, с длиной ключа 512 битов.

Примечание - В формуле (26) значение подписи sgn_C представляется в виде конкатенации двух строк, являющихся байтовыми представлениями чисел r и s в формате little-endian.

10.3 Идентификаторы типов сертификатов из реестра "TLS ClientCertificateType Identifiers"

Настоящие рекомендации определяют следующие новые идентификаторы IANA из реестра "TLS ClientCertificateType Identifiers", указываемые в поле certificate_types сообщения CertificateRequest:

enum {

gost_sign256(0x43),

gost_sign512(0x44),

(0xFF)

} ClientCertificateType;

Вышеперечисленные идентификаторы 0x43 и 0x44 определяют тип сертификата, указывающий на то, что сервер принимает сертификаты клиента с ключами проверки подписи, соответствующими алгоритму ГОСТ Р 34.10 с длиной ключа 32 байта (256 битов) и 64 байта (512 битов) соответственно.

11 Вопросы реализации и безопасности

В целях создания эффективной реализации при использовании алгоритма TLSTREE обращение к функции Divers_j,

, необходимо проводить только в тех случаях, когда номер записи seqnum достигает такого значения, что

; в противном случае необходимо применять значение, выработанное ранее. Данный подход позволяет также противодействовать атакам по побочным каналам.

Приложение А

(справочное)

КОНТРОЛЬНЫЕ ПРИМЕРЫ РАБОТЫ АЛГОРИТМА TLSTREE

Данное приложение носит справочный характер и не является частью настоящих рекомендаций.

А.1 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC

Значения корневого ключа K_root:

00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A

11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00.

Выработка ключа защиты записи с номером 0:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Выработка ключа защиты записи с номером 4095:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Выработка ключа защиты записи с номером 4096:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B

53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF.

Выработка ключа защиты записи с номером 33554431:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

B8 5B 36 DC 22 82 32 6B C0 35 C5 72 DC 93 F1 8D

83 AA 01 74 F3 94 20 9A 51 3B B3 74 DC 09 35 AE.

Выработка ключа защиты записи с номером 33554432:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

3F EA 59 38 DA 2B F8 DD C4 7E C1 DC 55 61 89 66

79 02 BE 42 0D F4 C3 7D AF 21 75 3B CB 1D C7 F3;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

0F D7 C0 9E FD F8 E8 15 73 EE CC F8 6E 4B 95 E3

AF 7F 34 DA B1 17 7C FD 7D B9 7B 6D A9 06 40 8A.

Выработка ключа защиты записи с номером 274877906943:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

AB F3 A5 37 98 3A 1B 98 40 06 6D E6 8A 49 BF 25

97 7E E5 C3 F5 2D 33 3E 3C 22 0F 1D 15 C5 08 93;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

48 0F 99 72 BA F2 5D 4C 36 9A 96 AF 91 BC A4 55

3F 79 D8 F0 C5 61 8B 19 FD 44 CF DC 57 FA 37 33.

Выработка ключа защиты записи с номером 274877906944:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

15 60 0D 9E 8F A6 85 54 CF 15 2D C7 4F BC 42 51

17 B0 3E 09 76 BB 28 EA 98 24 C3 B7 0F 28 CB D8;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

6C C2 8E B0 93 24 72 12 5C 7A D3 F8 09 73 B3 C8

C4 13 7D A5 73 BC 17 1A 24 ED D4 A3 71 F1 F8 73;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

25 28 C1 C6 A8 F0 92 7B F2 BE 27 BB 78 D2 7F 21

46 D6 55 93 B0 C7 17 3A 06 CB 9D 88 DF 92 32 65.

А.2 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC

Значения корневого ключа K_root:

00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A

11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00.

Выработка ключа защиты записи с номером 0:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Выработка ключа защиты записи с номером 63:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Выработка ключа защиты записи с номером 64:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37

FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B.

Выработка ключа защиты записи с номером 524287:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F

08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

6F 18 D4 00 3E A2 CB 30 F5 FE C1 93 A2 34 F0 7D

7C 43 94 98 7F 50 75 8D E2 2B 22 0D 8A 10 51 06.

Выработка ключа защиты записи с номером 524288:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

F6 59 EB 85 EE BD 2A 8D CC 1B B3 F7 C6 00 57 FF

6D 33 B6 0F 74 65 DD 42 B5 11 2C F3 A6 B1 AB 66;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

E5 4B 16 41 5B 3B 66 3E 78 0B 06 2D 24 F7 36 C4

49 54 63 C3 A8 91 E1 FA 46 F7 AE 99 FF F9 F3 78.

Выработка ключа защиты записи с номером 4294967295:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1

39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

F4 BC 10 1A BB 68 86 2A 8C E3 1E A0 0D DF A7 FE

B8 29 10 F1 24 F4 B1 E2 9E A8 3B E0 06 C2 26 8D;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

CF 60 09 04 C7 1E 7B 88 A4 9A C8 E2 45 77 4B 3D

BE ED FB 81 DE 9A 0E 2F 4E 46 C3 56 07 BC 2F 04.

Выработка ключа защиты записи с номером 4294967296:

- ключ 1-го уровня, являющийся результатом работы функции Divers₁:

55 CC 95 E0 D1 FB 54 85 AF 8E F6 9A CD 72 B2 32

79 7C D2 E8 5D 86 CD FD 1D E5 5B D1 FA 14 37 78;

- ключ 2-го уровня, являющийся результатом работы функции Divers₂:

72 16 91 E1 01 C4 28 96 A6 40 AE 18 3F BB 44 5B

76 37 9C 57 E1 FD 8A 7D 49 A6 23 E4 23 8C 0E 1D;

- итоговое значение ключа, являющееся результатом работы функции Divers₃:

16 18 0B 24 64 54 00 B8 36 14 38 37 D8 6A AC 93

95 2A E3 EB 82 44 D5 EC 2A B0 2C FF 30 78 11 38.

Приложение Б

(справочное)

КОНТРОЛЬНЫЕ ПРИМЕРЫ ДЛЯ РАБОТЫ ПРОТОКОЛА RECORD

Данное приложение носит справочный характер и не является частью настоящих рекомендаций.

Так как процесс обработки данных во время работы протокола Record одинаков для сервера и клиента, все действия описаны для одной фиксированной стороны взаимодействия. Способ фрагментации данных, длина данных и количество записей выбраны из условий удобства и наглядности.

Для наглядности байтовые строки разделены на подстроки (не более 16 байтов в подстроке) с указанием смещения текущей подстроки относительно начала строки. Смещение указано слева от подстроки в шестнадцатеричном виде и отделено от соответствующей подстроки двоеточием.

Б.1 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC

В настоящем разделе приведен тестовый пример работы протокола Record для криптонабора TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC. Рассмотрен случай обработки 4097 сообщений, при этом значения контрольных примеров приведены для трех из них, демонстрирующих наиболее важные особенности работы протокола.

Предполагается, что в результате выполнения протокола Handshake стороной взаимодействия выработаны следующие параметры:

- ключ вычисления имитовставки сообщения K_MAC:

000000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A

000010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00;

- ключ зашифрования данных K_ENC:

000000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11

000010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22;

- вектор инициализации для зашифрования данных IV:

000000: 00 00 00 00.

Б.1.1 Формирование защищенной записи с номером 0

Фрагмент данных длины 7 байтов, передающийся в рамках протокола Application Data в записи с номером seqnum = 0:

000000: 00 00 00 00 00 00 00.

Незащищенная запись Rec⁰, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 00 07 00 00 00 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 0, выработанный в результате работы алгоритма TLSTREE:

000000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

000010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Значение RecMAC для записи с номером seqnum = 0:

000000: F3 3E B6 89 6F EC E2 86.

Ключ

зашифрования для записи с номером seqnum = 0, выработанный в результате работы алгоритма TLSTREE:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Вектор инициализации IV⁰ для записи с номером seqnum = 0:

000000: 00 00 00 00.

Зашифрование данных ENCData проведено на одном секционном ключе K¹.

Секционный ключ K¹:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Защищенная запись PRec⁰, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 00 0F 9B 42 0D A8 6F AF 36 7F 05 14 43

000010: CE 9C 10 72.

Б.1.2 Формирование защищенной записи с номером 4095

Фрагмент данных длины 1024 байта (1 Кбайт), передающийся в рамках протокола Application Data в записи с номером seqnum = 4095:

000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0003D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0003E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Незащищенная запись Rec⁴⁰⁹⁵, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 04 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0003D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0003E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000400: 00 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 4095 равен ключу

000000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

000010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Значение RecMAC для записи с номером seqnum = 4095:

000000: 58 D3 BB 60 8F BC 98 B8.

Ключ

зашифрования для записи с номером seqnum = 4095 равен ключу

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Вектор инициализации IV⁴⁰⁹⁵ для записи с номером seqnum = 4095:

000000: 00 00 0F FF.

Данные ENCData разбиты на две секции, зашифрование проведено на двух секционных ключах K¹ и K².

Секционный ключ K¹:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Секционный ключ K²:

000000: ED AA 32 AE C1 05 B6 F1 86 14 C9 03 48 25 CD 89

000010: 94 1F B3 A1 2E 48 19 10 F6 42 FE 8C 7A A6 EC FC.

Защищенная запись PRec⁴⁰⁹⁵, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 04 08 B7 11 43 8B 16 20 1F 3C 49 33 95

000010: 21 C9 C8 CA 75 66 D4 C2 0F D3 3E 58 1F 80 07 DC

000020: 76 04 3E 2B 35 C8 E8 4B B2 55 08 27 66 13 59 6F

...

0003D0: E7 77 70 BF 45 17 E1 F8 DD 1B 2C 05 64 AD 68 FC

0003E0: 4A 88 9A 48 B8 B1 FF 0E A4 E1 BB 70 4D 56 A4 75

0003F0: 2F 51 A5 82 CC 54 1A 80 8F 8C 8B 62 97 68 88 C8

000400: 10 59 DE 41 27 63 A3 E0 99 9A CD DA 77.

Б.1.3 Формирование защищенной записи с номером 4096

Фрагмент данных длины 2048 байтов (2 Кбайт), передающийся в рамках протокола Application Data в записи с номером seqnum = 4096:

000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0007D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0007E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0007F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Незащищенная запись Rec⁴⁰⁹⁶, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 08 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

0007D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0007E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0007F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000800: 00 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 4096, выработанный в результате работы алгоритма TLSTREE:

000000: FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B

000010: 53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF.

Значение RecMAC для записи с номером seqnum = 4096:

000000: 50 55 A2 6A BE 19 63 81.

Ключ

зашифрования для записи с номером seqnum = 4096, выработанный в результате работы алгоритма TLSTREE:

000000: ED F2 FD 02 47 71 60 23 83 09 00 2D 1D 57 DF 9F

000010: D2 ED 18 D6 45 66 C7 6F 4B F0 3D 3A BF 7B BB 1E.

Вектор инициализации IV⁴⁰⁹⁶ для записи с номером seqnum = 4096:

000000: 00 00 10 00.

Данные ENCData разбиты на три секции, зашифрование проведено на трех секционных ключах K¹, K² и K³.

Секционный ключ K¹:

000000: ED F2 FD 02 47 71 60 23 83 09 00 2D 1D 57 DF 9F

000010: D2 ED 18 D6 45 66 C7 6F 4B F0 3D 3A BF 7B BB 1E.

Секционный ключ K²:

000000: 13 46 CB BC 3E B5 88 48 BE 4F 73 DE 46 1F A7 8C

000010: 33 6F B7 7B 89 E2 A7 5A E2 34 D7 DE 73 40 28 73.

Секционный ключ K³:

000000: A4 D9 9E 7B A5 57 32 B9 DC 53 6E 40 C9 26 9A 1A

000010: ED DD 66 23 96 90 0B 89 E9 9D 40 FA 48 F7 EF 5E.

Защищенная запись PRec⁴⁰⁹⁶, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 08 08 99 95 26 07 03 47 1D ED A2 E6 55

000010: B6 B3 93 83 5E 33 8B 1E D0 0E DD 22 47 A2 FB 88

000020: FB B7 A8 94 80 62 08 8A F3 2C AE B6 AA 2C 4F 2A

...

0007D0: 7F 0B 24 61 E7 5F E1 06 34 B8 4D C5 70 35 72 5A

0007E0: CA 4F 0C BC A9 B0 6C B9 F7 6F BD 2F 80 46 2B 8D

0007F0: 77 5E BD 41 6F 63 41 39 AC 89 C2 ED 3D F1 9F E2

000800: 4E F8 C0 5A A8 90 93 1B 01 86 FD 7D DF.

Б.2 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC

В настоящем разделе приведен тестовый пример работы протокола Record для криптонабора TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC. Рассмотрен случай обработки 65 сообщений, при этом значения контрольных примеров приведены для трех из них, демонстрирующих наиболее важные особенности работы протокола.

- ключ вычисления имитовставки сообщения K_MAC:

000000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A

000010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00;

- ключ зашифрования данных K_ENC:

000000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11

000010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22;

- вектор инициализации для зашифрования данных IV:

000000: 00 00 00 00 00 00 00 00.

Б.2.1 Формирование защищенной записи с номером 0

Фрагмент данных длины 15 байтов, передающийся в рамках протокола Application Data в записи с номером seqnum = 0:

000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Незащищенная запись Rec⁰, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 00 0F 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 0, выработанный в результате работы алгоритма TLSTREE:

000000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

000010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Значение RecMAC для записи с номером seqnum = 0:

000000: FD 17 19 DD 95 08 37 EB 7C 7B B8 F5 00 37 99 81.

Ключ

зашифрования для записи с номером seqnum = 0, выработанный в результате работы алгоритма TLSTREE:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Вектор инициализации IV⁰ для записи с номером seqnum = 0:

000000: 00 00 00 00 00 00 00 00.

Зашифрование данных ENCData проведено на одном секционном ключе K¹.

Секционный ключ K¹:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Защищенная запись PRec⁰, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 00 1F 4D 1A 30 52 36 57 3B FF C1 4E 46

000010: DC BE 74 6D B6 C9 9A 17 5A 81 C4 71 1E 2F 84 C3

000020: 92 C5 40 7C.

Б.2.2 Формирование защищенной записи с номером 63

Фрагмент данных длины 4096 байтов (4 Кбайт), передающийся в рамках протокола Application Data в записи с номером seqnum = 63:

000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

000FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Незащищенная запись Rec⁶³, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 10 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

000FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

001000: 00 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 63 равен ключу

000000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38

000010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D.

Значение RecMAC для записи с номером seqnum = 63:

000000: 98 46 27 61 D0 26 24 4A 2C 0B 7D 1B CC CB E7 B0.

Ключ

зашифрования для записи с номером seqnum = 63 равен ключу

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Вектор инициализации IV⁶³ для записи с номером seqnum = 63:

000000: 00 00 00 00 00 00 00 3F.

Данные ENCData разбиты на две секции, зашифрование проведено на двух секционных ключах K¹ и K².

Секционный ключ K¹:

000000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79

000010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56.

Секционный ключ K²:

000000: CE 53 6E 83 BD 4E 5D 6F D6 DB AE 8E 74 A2 C6 AA

000010: C8 9D 1D EE 77 50 0B 5C 50 5C C6 58 4D D7 FA D1.

Защищенная запись PRec⁶³, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 10 10 12 93 51 D2 6E 14 07 13 A2 1B 37

000010: 68 24 A2 23 17 CD C0 D8 8E 01 CF A3 FE 21 41 5F

000020: 5C 5E 05 86 9C CF 38 A5 1B C2 E0 ED 68 94 46 A8

...

000FE0: 19 AD 99 8C 06 25 21 E6 7B 63 59 A4 F5 C8 16 F9

000FF0: 47 6B A7 13 26 82 BB A8 CE 0B ED AD 65 E4 20 A2

001000: 97 B6 E2 C6 1F A4 06 D9 B8 CA 36 FD 9F CD 3A EE

001010: 24 78 F4 D1 96.

Б.2.3 Формирование защищенной записи с номером 64

Фрагмент данных длины 8192 байта (8 Кбайт), передающийся в рамках протокола Application Data в записи с номером seqnum = 64:

000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

001FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

001FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

001FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Незащищенная запись Rec⁶⁴, представленная в виде структуры TLSPlaintext:

000000: 17 03 03 20 00 00 00 00 00 00 00 00 00 00 00 00

000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

...

001FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

001FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

001FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

002000: 00 00 00 00 00.

Ключ

вычисления имитовставки для записи с номером seqnum = 64, выработанный в результате работы алгоритма TLSTREE:

000000: AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37

000010: FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B.

Значение RecMAC для записи с номером seqnum = 64:

000000: EA C3 97 87 84 2B 1D BD 60 80 CC 3F BF AE 5C 2F.

Ключ

зашифрования для записи с номером seqnum = 64, выработанный в результате работы алгоритма TLSTREE:

000000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A

000010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96.

Вектор инициализации IV⁶⁴ для записи с номером seqnum = 64:

000000: 00 00 00 00 00 00 00 40.

Данные ENCData разбиты на три секции, зашифрование проведено на трех секционных ключах K¹, K² и K³.

Секционный ключ K¹:

000000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A

000010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96.

Секционный ключ K²:

000000: 78 6B 61 DE BB C5 03 11 C2 90 4C 21 53 43 AB 2D

000010: 86 9E 16 45 77 9C 91 B6 07 75 C7 E5 19 9E 6D 56.

Секционный ключ K³:

000000: CE 33 35 AB 82 0F 2C 20 88 96 C9 81 51 34 35 47

000010: A3 63 FA 9B B1 7D B0 23 3E 1F 7D CB 5C 82 65 B9.

Защищенная запись PRec⁶⁴, представленная в виде структуры TLSCiphertext:

000000: 17 03 03 20 10 E6 66 BB 98 AC 5B 0F 39 31 D8 55

000010: 1B 93 36 85 96 EE F0 EB A8 26 9C B8 BD AA E7 EB

000020: 80 C8 30 D7 5A B7 D4 6C 25 06 DC 8B 83 E1 F2 D3

...

001FE0: B3 02 67 2C CB 02 86 CD 40 48 FB D5 38 1A 65 55

001FF0: 26 11 25 51 01 4F A8 ED F5 C2 1B 7D 1D B3 9D 6B

002000: AD EC 0D 7C 07 05 34 8B 5C 55 6C 4D 50 81 69 1A

002010: A9 EC 36 F8 B5.

Приложение В

(справочное)

КОНТРОЛЬНЫЕ ПРИМЕРЫ ДЛЯ РАБОТЫ ПРОТОКОЛА TLS 1.2

Данное приложение носит справочный характер и не является частью настоящих рекомендаций.

Для наглядности данные, которыми оперируют клиент и сервер, представлены слева и справа от вертикальной черты соответственно. При этом обозначения "---->" и "<----" использованы для указания на данные, пересылаемые по каналу связи клиентом и сервером соответственно.

В.1 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC

В настоящем разделе приведен тестовый пример сценария работы протокола TLS 1.2 для криптонабора TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC, при котором использована полная схема работы протокола Handshake с односторонней аутентификацией. Открытый и закрытый ключи сервера заданы нижеприведенным образом.

Идентификатор кривой сертификата сервера:

id-tc26-gost-3410-2012-256-paramSetA, "1.2.643.7.1.2.1.1.1".

Открытый ключ сервера Q_S:

x = 0xC03ED6E3604CCB026E56E91272454707

94E0508A1FE1602371F443DC20E313FD;

y = 0x994D579491A2DBB720E78E0AFAC8479C

8D1A852989A46D4969C799E39A1025EC.

Закрытый ключ сервера k_S:

0x0880FD1E94C7656CA143A310553A04B5

5583E16ABF56D91336AB271B7396E0E4.

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

Формирование сообщения ClientHello на стороне клиента:
msg_type:						01
length:						000040
body:
client_version:
major:						03
minor:						03
random:						933EA21EC3802A561550EC78D6ED51AC
						2439D7E749C31BC3A3456165889684CA
session_id:
length:						00
vector:						--
cipher_suites:
length:						0004
vector:
CipherSuite:						C100
CipherSuite:						C101
compression_methods:
length:						01
vector:
CompressionMethod:						00
extensions:
length:						0013
vector:
Extension: /* signature_algorithms */
extension_type:						000D
extension_data:
length:						0006
vector:
supported_signature_algorithms:
length:						0004
vector:
/* Первая пара алгоритмов */
hash:						08
signature:
						40
/* Вторая пара алгоритмов */
hash:						08
signature:
						41
Extension: /* renegotiation_info */
extension_type:						FF01
extension_data:
length:						0001
vector:
renegotiated_connection:
length:						00
vector:						--
Extension: /* extended_master_secret */
extension_type:						0017
extension_data:
length:						0000
vector:						--
Итоговое сообщение ClientHello:
000000:	01	00	00	40	03	03	93	3E	A2	1E	C3	80	2A	56	15	50
000010:	EC	78	D6	ED	51	AC	24	39	D7	E7	49	C3	1B	C3	A3	45
000020:	61	65	88	96	84	CA	00	00	04	C1	00	C1	01	01	00	00
000030:	13	00	0D	00	06	00	04	08	40	08	41	FF	01	00	01	00
000040:	00	17	00	00
Формирование незащищенной записи с номером 0 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						0044
fragment:						010000400303933EA21EC3802A561550
						EC78D6ED51AC2439D7E749C31BC3A345
						6165889684CA000004C100C101010000
						13000D0006000408400841FF01000100
						00170000
Итоговая запись с номером 0 на стороне клиента:
000000:	16	03	03	00	44	01	00	00	40	03	03	93	3E	A2	1E	C3	---->
000010:	80	2A	56	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	49
000020:	C3	1B	C3	A3	45	61	65	88	96	84	CA	00	00	04	C1	00
000030:	C1	01	01	00	00	13	00	0D	00	06	00	04	08	40	08	41
000040:	FF	01	00	01	00	00	17	00	00

	Формирование сообщения ServerHello на стороне сервера:
	msg_type:						02
	length:						000041
	body:
	server_version:
	major:						03
	minor:						03
	random:						933EA21E49C31BC3A3456165889684CA
							A5576CE7924A24F58113808DBD9EF856
	session_id:
	length:						10
	vector:						C3802A561550EC78D6ED51AC2439D7E7
	cipher_suite:
	CipherSuite:						C101
	compression_method:
	CompressionMethod:						00
	extensions:
	length:						0009
	vector:
	Extension: /* renegotiation_info */
	extension_type:						FF01
	extension_data:
	length:						0001
	vector:
	renegotiated_connection:
	length:						00
	vector:						-
	Extension: /* extended_master_secret */
	extension_type:						0017
	extension_data:
	length:						0000
	vector:						--
	Итоговое сообщение ServerHello:
	000000:	02	00	00	41	03	03	93	3E	A2	1E	49	C3	1B	C3	A3	45
	000010:	61	65	88	96	84	CA	A5	57	6C	E7	92	4A	24	F5	81	13
	000020:	80	8D	BD	9E	F8	56	10	C3	80	2A	56	15	50	EC	78	D6
	000030:	ED	51	AC	24	39	D7	E7	C1	01	00	00	09	FF	01	00	01
	000040:	00	00	17	00	00
	Формирование незащищенной записи с номером 0 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						0045
	fragment:						020000410303933EA21E49C31BC3A345
							6165889684CAA5576CE7924A24F58113
							808DBD9EF85610C3802A561550EC78D6
							ED51AC2439D7E7C101000009FF010001
							0000170000
	Итоговая запись с номером 0 на стороне сервера:
<----	000000:	16	03	03	00	45	02	00	00	41	03	03	93	3E	A2	1E	49
	000010:	C3	1B	C3	A3	45	61	65	88	96	84	CA	A5	57	6C	E7	92
	000020:	4A	24	F5	81	13	80	8D	BD	9E	F8	56	10	C3	80	2A	56
	000030:	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	C1	01	00	00
	000040:	09	FF	01	00	01	00	00	17	00	00

	Формирование сообщения Certificate на стороне сервера:
	msg_type:						0B
	length:						0002BC
	body:
	certificate_list:
	length:						0002B9
	vector:
	ASN.1Cert:
	length:						0002B6
	vector:						308202B230820261A003020102020A28
							A290E3000000D8D142300806062A8503
							020203303A31123010060A0992268993
							...
							1D996A750AC8DA2C3EF228475ED3FBC7
							9A3EA1C7D580AE08D081F314B48809BD
							2CD4B58FA84CB2B66611FD6C0A84BE59
							253D1887CC02
	Итоговое сообщение Certificate:
	000000:	0B	00	02	BC	00	02	B9	00	02	B6	30	82	02	B2	30	82
	000010:	02	61	A0	03	02	01	02	02	0A	28	A2	90	E3	00	00	00
	000020:	D8	D1	42	30	08	06	06	2A	85	03	02	02	03	30	3A	31
	000030:	12	30	10	06	0A	09	92	26	89	93	F2	2C	64	01	19	16
	000040:	02	72	75	31	12	30	10	06	0A	09	92	26	89	93	F2	2C
	000050:	64	01	19	16	02	63	70	31	10	30	0E	06	03	55	04	03
	000060:	13	07	74	65	73	74	2D	63	61	30	1E	17	0D	31	37	31
	000070:	30	32	34	30	32	35	30	35	36	5A	17	0D	32	37	31	30
	000080:	32	34	30	39	33	30	35	36	5A	30	21	31	1F	30	1D	06
	000090:	03	55	04	03	13	16	53	65	72	76	65	72	54	4C	53	31
	0000A0:	32	54	65	73	74	53	61	6D	70	6C	65	73	30	68	30	21
	0000B0:	06	08	2A	85	03	07	01	01	01	01	30	15	06	09	2A	85
	0000C0:	03	07	01	02	01	01	01	06	08	2A	85	03	07	01	01	02
	0000D0:	02	03	43	00	04	40	FD	13	E3	20	DC	43	F4	71	23	60
	0000E0:	E1	1F	8A	50	E0	94	07	47	45	72	12	E9	56	6E	02	CB
	0000F0:	4C	60	E3	D6	3E	C0	EC	25	10	9A	E3	99	C7	69	49	6D
	000100:	A4	89	29	85	1A	8D	9C	47	C8	FA	0A	8E	E7	20	B7	DB
	000110:	A2	91	94	57	4D	99	A3	82	01	59	30	82	01	55	30	13
	000120:	06	03	55	1D	25	04	0C	30	0A	06	08	2B	06	01	05	05
	000130:	07	03	01	30	0E	06	03	55	1D	0F	01	01	FF	04	04	03
	000140:	02	04	F0	30	1D	06	03	55	1D	0E	04	16	04	14	B0	90
	000150:	04	86	FC	71	C5	91	5A	CA	9B	6B	36	1C	18	A8	37	14
	000160:	35	1B	30	1F	06	03	55	1D	23	04	18	30	16	80	14	9E
	000170:	03	F0	B8	9C	FC	60	DC	8A	18	1E	E8	00	DF	A8	5B	32
	000180:	CD	73	76	30	3F	06	03	55	1D	1F	04	38	30	36	30	34
	000190:	A0	32	A0	30	86	2E	68	74	74	70	3A	2F	2F	76	6D	2D
	0001A0:	74	65	73	74	2D	63	61	2E	63	70	2E	72	75	2F	43	65
	0001B0:	72	74	45	6E	72	6F	6C	6C	2F	74	65	73	74	2D	63	61
	0001C0:	2E	63	72	6C	30	81	AC	06	08	2B	06	01	05	05	07	01
	0001D0:	01	04	81	9F	30	81	9C	30	4B	06	08	2B	06	01	05	05
	0001E0:	07	30	02	86	3F	68	74	74	70	3A	2F	2F	76	6D	2D	74
	0001F0:	65	73	74	2D	63	61	2E	63	70	2E	72	75	2F	43	65	72
	000200:	74	45	6E	72	6F	6C	6C	2F	76	6D	2D	74	65	73	74	2D
	000210:	63	61	2E	63	70	2E	72	75	5F	74	65	73	74	2D	63	61
	000220:	2E	63	72	74	30	4D	06	08	2B	06	01	05	05	07	30	02
	000230:	86	41	66	69	6C	65	3A	2F	2F	5C	5C	76	6D	2D	74	65
	000240:	73	74	2D	63	61	2E	63	70	2E	72	75	5C	43	65	72	74
	000250:	45	6E	72	6F	6C	6C	5C	76	6D	2D	74	65	73	74	2D	63
	000260:	61	2E	63	70	2E	72	75	5F	74	65	73	74	2D	63	61	2E
	000270:	63	72	74	30	08	06	06	2A	85	03	02	02	03	03	41	00
	000280:	93	30	50	11	50	42	80	3B	6F	DD	1D	99	6A	75	0A	C8
	000290:	DA	2C	3E	F2	28	47	5E	D3	FB	C7	9A	3E	A1	C7	D5	80
	0002A0:	AE	08	D0	81	F3	14	B4	88	09	BD	2C	D4	B5	8F	A8	4C
	0002B0:	B2	B6	66	11	FD	6C	0A	84	BE	59	25	3D	18	87	CC	02
	Формирование незащищенной записи с номером 1 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						02C0
	fragment:						0B0002BC0002B90002B6308202B23082
							0261A003020102020A28A290E3000000
							D8D142300806062A8503020203303A31
							...
							DA2C3EF228475ED3FBC79A3EA1C7D580
							AE08D081F314B48809BD2CD4B58FA84C
							B2B66611FD6C0A84BE59253D1887CC02
	Итоговая запись с номером 1 на стороне сервера:
	000000:	16	03	03	02	C0	0B	00	02	BC	00	02	B9	00	02	B6	30
	000010:	82	02	B2	30	82	02	61	A0	03	02	01	02	02	0A	28	A2
	000020:	90	E3	00	00	00	D8	D1	42	30	08	06	06	2A	85	03	02
	000030:	02	03	30	3A	31	12	30	10	06	0A	09	92	26	89	93	F2
	000040:	2C	64	01	19	16	02	72	75	31	12	30	10	06	0A	09	92
	000050:	26	89	93	F2	2C	64	01	19	16	02	63	70	31	10	30	0E
	000060:	06	03	55	04	03	13	07	74	65	73	74	2D	63	61	30	1E
	000070:	17	0D	31	37	31	30	32	34	30	32	35	30	35	36	5A	17
	000080:	0D	32	37	31	30	32	34	30	39	33	30	35	36	5A	30	21
	000090:	31	1F	30	1D	06	03	55	04	03	13	16	53	65	72	76	65
	0000A0:	72	54	4C	53	31	32	54	65	73	74	53	61	6D	70	6C	65
	0000B0:	73	30	68	30	21	06	08	2A	85	03	07	01	01	01	01	30
	0000C0:	15	06	09	2A	85	03	07	01	02	01	01	01	06	08	2A	85
	0000D0:	03	07	01	01	02	02	03	43	00	04	40	FD	13	E3	20	DC
	0000E0:	43	F4	71	23	60	E1	1F	8A	50	E0	94	07	47	45	72	12
	0000F0:	E9	56	6E	02	CB	4C	60	E3	D6	3E	C0	EC	25	10	9A	E3
	000100:	99	C7	69	49	6D	A4	89	29	85	1A	8D	9C	47	C8	FA	0A
	000110:	8E	E7	20	B7	DB	A2	91	94	57	4D	99	A3	82	01	59	30
	000120:	82	01	55	30	13	06	03	55	1D	25	04	0C	30	0A	06	08
	000130:	2B	06	01	05	05	07	03	01	30	0E	06	03	55	1D	0F	01
	000140:	01	FF	04	04	03	02	04	F0	30	1D	06	03	55	1D	0E	04
	000150:	16	04	14	B0	90	04	86	FC	71	C5	91	5A	CA	9B	6B	36
<----	000160:	1C	18	A8	37	14	35	1B	30	1F	06	03	55	1D	23	04	18
	000170:	30	16	80	14	9E	03	F0	B8	9C	FC	60	DC	8A	18	1E	E8
	000180:	00	DF	A8	5B	32	CD	73	76	30	3F	06	03	55	1D	1F	04
	000190:	38	30	36	30	34	A0	32	A0	30	86	2E	68	74	74	70	3A
	0001A0:	2F	2F	76	6D	2D	74	65	73	74	2D	63	61	2E	63	70	2E
	0001B0:	72	75	2F	43	65	72	74	45	6E	72	6F	6C	6C	2F	74	65
	0001C0:	73	74	2D	63	61	2E	63	72	6C	30	81	AC	06	08	2B	06
	0001D0:	01	05	05	07	01	01	04	81	9F	30	81	9C	30	4B	06	08
	0001E0:	2B	06	01	05	05	07	30	02	86	3F	68	74	74	70	3A	2F
	0001F0:	2F	76	6D	2D	74	65	73	74	2D	63	61	2E	63	70	2E	72
	000200:	75	2F	43	65	72	74	45	6E	72	6F	6C	6C	2F	76	6D	2D
	000210:	74	65	73	74	2D	63	61	2E	63	70	2E	72	75	5F	74	65
	000220:	73	74	2D	63	61	2E	63	72	74	30	4D	06	08	2B	06	01
	000230:	05	05	07	30	02	86	41	66	69	6C	65	3A	2F	2F	5C	5C
	000240:	76	6D	2D	74	65	73	74	2D	63	61	2E	63	70	2E	72	75
	000250:	5C	43	65	72	74	45	6E	72	6F	6C	6C	5C	76	6D	2D	74
	000260:	65	73	74	2D	63	61	2E	63	70	2E	72	75	5F	74	65	73
	000270:	74	2D	63	61	2E	63	72	74	30	08	06	06	2A	85	03	02
	000280:	02	03	03	41	00	93	30	50	11	50	42	80	3B	6F	DD	1D
	000290:	99	6A	75	0A	C8	DA	2C	3E	F2	28	47	5E	D3	FB	C7	9A
	0002A0:	3E	A1	C7	D5	80	AE	08	D0	81	F3	14	B4	88	09	BD	2C
	0002B0:	D4	B5	8F	A8	4C	B2	B6	66	11	FD	6C	0A	84	BE	59	25
	0002C0:	3D	18	87	CC	02

	Формирование сообщения ServerHelloDone на стороне сервера:
	msg_type:								0E
	length:								000000
	body:								--
	Итоговое сообщение ServerHelloDone:
	000000:	0E	00	00	00
	Формирование незащищенной записи с номером 2 на стороне сервера:
	type:								16
	version:
	major:								03
	minor:								03
	length:								0004
	fragment:								0E000000
	Итоговая запись с номером 2 на стороне сервера:
<----	000000:	16	03	03	00	04	0E	00	00	00

Значение PS, сгенерированное на стороне клиента:
000000:	A5	57	6C	E7	92	4A	24	F5	81	13	80	8D	BD	9E	F8	56
000010:	F5	BD	C3	B1	83	CE	5D	AD	CA	36	A5	3A	A0	77	65	1D
Случайное значение k_EPH, выбранное на стороне клиента:
0x25C77C7482373DE16CE4A6F73CCE7F78
2762F83F9B103D4D34DB6B3DC9F25350
Эфемерный ключ Q_EPH:
x = 0x86D9192A6C85737E2AF5CC7C3761F3D9
BE127378C218E27439E230B04C0F498D,
y = 0x71190E76B8E48FD9F172D9610A4E6CEC
2D5E088CCDA71B245B40C636B8C1CE00
Хэш-значение H от конкатенации случайных строк клиента и сервера:
000000:	C3	EF	04	28	D4	B7	A1	F4	C5	02	5F	2E	65	DD	2B	2E
000010:	A5	83	AE	EF	DB	67	C7	F4	21	4A	6A	29	8E	99	E3	25
Генерация ключей экспорта. Значение r.
0xC3EF0428D4B7A1F4C5025F2E65DD2B2E
Алгоритм генерации ключей экспорта. Значение UKM:
0xC3EF0428D4B7A1F4C5025F2E65DD2B2E
Генерация ключей экспорта. Значение seed:
000000:	A5	83	AE	EF	DB	67	C7	F4
Генерация ключей экспорта. Значение K_EXP:
000000:	36	16	2B	AF	72	70	C5	D0	8A	02	1B	C1	24	1C	A9	4A
000010:	45	0D	56	1B	90	31	61	71	EF	15	5F	D5	55	A9	75	51
Ключи и экспорта вычисления имитовставки и шифрования:
000000:	30	95	48	96	6C	4A	84	A8	A7	7C	1B	FF	99	63	CD	E7
000010:	AF	76	DB	9C	F1	D1	40	01	97	13	6F	23	99	89	20	02
000020:	C1	17	69	2B	8C	F5	E7	89	75	D4	21	C4	7E	6D	36	BB
000030:	D0	03	76	8F	93	4E	BB	6C	98	A2	CD	C9	57	6B	5C	67
Значение вектора инициализации IV:
000000:	21 4A 6A 29
Экспортное представление PSExp значения PS:
000000:	34	06	20	BB	60	81	01	EF	2A	61	DD	4A	9E	57	7B	DC
000010:	5D	99	39	09	B1	CD	EF	E6	09	2C	53	B7	63	A8	C6	E8
000020:	C7	85	7D	04	F4	B4	64	C9
Формирование сообщения ClientKeyExchange на стороне клиента:
msg_type:							10
length:							000097
body:
exchange_keys:							3081940428340620BB608101EF2A61DD
							4A9E577BDC5D993909B1CDEFE6092C53
							B763A8C6E8C7857D04F4B464C9306830
							...
							E218C2787312BED9F361377CCCF52A7E
							73856C2A19D98600CEC1B836C6405B24
							1BA7CD8C085E2DEC6C4E0A61D972F1D9
							8FE4B8760E1971
Итоговое сообщение ClientKeyExchange:
000000:	10	00	00	97	30	81	94	04	28	34	06	20	BB	60	81	01
000010:	EF	2A	61	DD	4A	9E	57	7B	DC	5D	99	39	09	B1	CD	EF
000020:	E6	09	2C	53	B7	63	A8	C6	E8	C7	85	7D	04	F4	B4	64
000030:	C9	30	68	30	21	06	08	2A	85	03	07	01	01	01	01	30
000040:	15	06	09	2A	85	03	07	01	02	01	01	01	06	08	2A	85
000050:	03	07	01	01	02	02	03	43	00	04	40	8D	49	0F	4C	B0
000060:	30	E2	39	74	E2	18	C2	78	73	12	BE	D9	F3	61	37	7C
000070:	CC	F5	2A	7E	73	85	6C	2A	19	D9	86	00	CE	C1	B8	36
000080:	C6	40	5B	24	1B	A7	CD	8C	08	5E	2D	EC	6C	4E	0A	61
000090:	D9	72	F1	D9	8F	E4	B8	76	0E	19	71
Формирование незащищенной записи с номером 1 на стороне клиента
type:							16
version:
major:							03
minor:							03
length:							009B
fragment:							100000973081940428340620BB608101
							EF2A61DD4A9E577BDC5D993909B1CDEF
							E6092C53B763A8C6E8C7857D04F4B464
							...
							30E23974E218C2787312BED9F361377C
							CCF52A7E73856C2A19D98600CEC1B836
							C6405B241BA7CD8C085E2DEC6C4E0A61
							D972F1D98FE4B8760E1971
Итоговая запись с номером 1 на стороне клиента:
000000:	16	03	03	00	9B	10	00	00	97	30	81	94	04	28	34	06	---->
000010:	20	BB	60	81	01	EF	2A	61	DD	4A	9E	57	7B	DC	5D	99
000020:	39	09	B1	CD	EF	E6	09	2C	53	B7	63	A8	C6	E8	C7	85
000030:	7D	04	F4	B4	64	C9	30	68	30	21	06	08	2A	85	03	07
000040:	01	01	01	01	30	15	06	09	2A	85	03	07	01	02	01	01
000050:	01	06	08	2A	85	03	07	01	01	02	02	03	43	00	04	40
000060:	8D	49	0F	4C	B0	30	E2	39	74	E2	18	C2	78	73	12	BE
000070:	D9	F3	61	37	7C	CC	F5	2A	7E	73	85	6C	2A	19	D9	86
000080:	00	CE	C1	B8	36	C6	40	5B	24	1B	A7	CD	8C	08	5E	2D
000090:	EC	6C	4E	0A	61	D9	72	F1	D9	8F	E4	B8	76	0E	19	71

Извлечение экспортного представления PSExp:

000000:

000010:

000020:

Хэш-значение H от конкатенации случайных строк клиента и сервера:

000000:

000010:

Генерация ключей экспорта. Значение r:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение UKM:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение seed:

000000:

Генерация ключей экспорта. Значение K_EXP:

000000:

000010:

Ключи экспорта

для вычисления имитовставки и шифрования:

000000:

000010:

000020:

000030:

Значение вектора инициализации IV:

000000:

21 4A 6A 29

Извлеченный общий секрет PS:

000000:

000010:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне клиента:

000000:

000010:

000020:

Ключи вычисления имитовставки, ключи шифрования и векторы инициализации для каждого из состояний чтения и записи

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне сервера:

000000:

000010:

000020:

Ключи вычисления имитовставки, ключи шифрования и векторы инициализации для каждого из состояний записи и чтения

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Формирование сообщения ChangeCipherSpec на стороне клиента
type:						01
Итоговое сообщение ChangeCipherSpec:
000000:		01
Формирование незащищенной записи с номером 2 на стороне клиента:							---->
type:						14
version:
major:						03
minor:						03
length:						0001
fragment:						01
Итоговая запись с номером 2 на стороне клиента:
000000:	14	03	03	00	01	01

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования client_verify_data:

000000:

000010:

Данные client_verify_data:

000000:

000010:

Формирование сообщения Finished на стороне клиента:

msg_type:

length:

000020

body:

verify_data:

8F5AB0F43C2A4A3D85DCFC787337043B

1370F60E26518E36722458BCD3354AEB

Итоговое сообщение Finished:

000000:

000010:

000020:

Формирование защищенной записи с номером 0 на стороне клиента:

type:

version:

major:

minor:

length:

002C

fragment:

6A45199CE3FB78C93D3A4F4AA448E78F

A3D4041872923AD22FFFB08E8F0EA1FC

3CE4CC00DE67928A46213E89

Итоговая защищенная запись с номером 0 на стороне клиента:

000000:

---->

000010:

000020:

000030:

	Формирование сообщения ChangeCipherSpec на стороне сервера
	type:							01
	Итоговое сообщение ChangeCipherSpec:
	000000:	01
	Формирование незащищенной записи с номером 3 на стороне сервера:
	type:							14
	version:
	major:							03
	minor:							03
	length:							0001
	fragment:							01
	Итоговая запись с номером 3 на стороне сервера:
<----	000000:	14	03	03	00	01	01

	Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования server_verify_data:
	000000:	10	A6	82	58	BD	48	F8	88	99	7A	95	39	A3	B6	3E	F8
	000010:	62	63	60	C7	24	28	92	B0	E2	D9	63	C8	D1	5E	44	90
	Данные server_verify_data:
	000000:	C4	F3	C3	67	97	68	26	0F	C5	41	2C	E5	1D	90	32	1F
	000010:	F0	8E	AE	63	E8	40	BD	99	9F	A2	60	5A	B2	11	80	47
	Формирование сообщения Finished на стороне сервера:
	msg_type:						14
	length:						000020
	body:
	verify_data:						C4F3C3679768260FC5412CE51D90321F
							F08EAE63E840BD999FA2605AB2118047
	Итоговое сообщение Finished:
	000000:	14	00	00	20	C4	F3	C3	67	97	68	26	0F	C5	41	2C	E5
	000010:	1D	90	32	1F	F0	8E	AE	63	E8	40	BD	99	9F	A2	60	5A
	000020:	B2	11	80	47
	Формирование защищенной записи с номером 0 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						002C
	fragment:						AB42306AAD25FDF1B32627ACF746AE8A
							317A22C50EE19719CD766A8F0E54A467
							988119806F42AD96F4A4318D
	Итоговая защищенная запись с номером 0 на стороне сервера:
<----	000000:	16	03	03	00	2C	AB	42	30	6A	AD	25	FD	F1	B3	26	27
	000010:	AC	F7	46	AE	8A	31	7A	22	C5	0E	E1	97	19	CD	76	6A
	000020:	8F	0E	54	A4	67	98	81	19	80	6F	42	AD	96	F4	A4	31
	000030:	8D

Данные, передающиеся в первом сообщении протокола Application Data, посылаемом клиентом после завершения протокола Handshake:
000000:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
000010:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
Формирование защищенной записи с номером 1 на стороне клиента:
type:						17
version:
major:						03
minor:						03
length:						0028
fragment:						C45BD99F35FD5C07ACA60911974C1158
						BB469C84943606E0C48A8DC898844A36
						8A86E8AA073A1570
Итоговая защищенная запись с номером 1 на стороне клиента:
000000:	17	03	03	00	28	C4	5B	D9	9F	35	FD	5C	07	AC	A6	09	---->
000010:	11	97	4C	11	58	BB	46	9C	84	94	36	06	E0	C4	8A	8D
000020:	C8	98	84	4A	36	8A	86	E8	AA	07	3A	15	70

Данные, передающиеся в первом сообщении протокола Application Data, посылаемом сервером после завершения протокола Handshake:

000000:

000010:

Формирование защищенной записи с номером 1 на стороне сервера:

type:

version:

major:

minor:

length:

0028

fragment:

3B37E8D18F5746CBA2139A711CE9910B

0714623F88FE4FF4878C79DF7D6F33E2

6CD20F6482B95D03

Итоговая защищенная запись с номером 1 на стороне сервера:

<----

000000:

000010:

000020:

Формирование оповещения close_notify на стороне клиента:

---->

Alert:

level:

description:

Итоговое оповещение на стороне клиента:

000000:

Формирование защищенной записи с номером 2 на стороне клиента:

type:

version:

major:

minor:

length:

000A

fragment:

B046248BD9DB782B9DE5

Итоговая защищенная запись с номером 2 на стороне клиента:

000000:

<----

Формирование оповещения close_notify на стороне сервера:

Alert:

level:

description:

Итоговое оповещение на стороне клиента:

000000:

Формирование защищенной записи с номером 2 на стороне сервера:

type:

version:

major:

minor:

length:

000A

fragment:

476B782FF6E71A1E1876

Итоговая защищенная запись с номером 2 на стороне сервера:

000000:

В.2 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC

В настоящем разделе приведен тестовый пример сценария работы протокола TLS 1.2 для криптонабора TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC, при котором использована полная схема работы протокола Handshake с двусторонней аутентификацией. Открытый и закрытый ключи сервера заданы нижеприведенным образом.

Идентификатор кривой сертификата сервера:

id-tc26-gost-3410-2012-512-paramSetC, "1.2.643.7.1.2.1.2.3".

Открытый ключ сервера Q_S:

x = 0xF14589DA479AD972C66563669B3FF580

92E6A30A288BF447CD9FF6C3133E9724

7A9706B267703C9B4E239F0D7C7E3310

C22D2752B35BD2E4FD39B8F11DEB833A;

y = 0xF305E95B36502D4E60A1059FB20AB30B

FC7C95727F3A2C04B1DFDDB53B0413F2

99F2DFE66A5E1CCB4101A7A01D612BE6

BD78E1E3B3D567EBB16ABE587A11F4EA.

Закрытый ключ сервера k_S:

0x12FD7A70067479A0F66C59F9A25534AD

FBC7ABFD3CC72D79806F8B402601644B

3005ED365A2D8989A8CCAE640D5FC08D

D27DFBBFE137CF528E1AC6D445192E01.

Ключ проверки подписи и ключ подписи клиента заданы нижеприведенным образом.

Идентификатор кривой сертификата клиента:

id-tc26-gost-3410-2012-256-paramSetA, "1.2.643.7.1.2.1.1.1".

Ключ проверки подписи клиента Q_C:

x = 0x0F5DB18A9E15F324B778676025BFD7B5

DF066566EABAA1C51CD879F87B0B4975;

y = 0x9EE5BBF18361F842D3F087DEC2943939

E0FA2BFB4EDEC25A8D10ABB22C48F386.

Ключ подписи клиента k_C:

0x0918AD3F7D209ABF89F1E8505DA894CE

E10DA09D32E72E815D9C0ADA30B5A103.

Формирование сообщения ClientHello на стороне клиента:
msg_type:						01
length:						000040
body:
client_version:
major:						03
minor:						03
random:						933EA21EC3802A5 61550EC78D6ED51AC
						2439D7E749C31BC3A3456165889684CA
session_id:
length:						00
vector:						--
cipher_suites:
length:						0004
vector:
CipherSuite:						C100
CipherSuite:						C101
compression_methods:
length:						01
vector:
CompressionMethod:						00
extensions:
length:						0013
vector:
Extension: /* signature_algorithms */
extension_type:						000D
extension_data:
length:						0006
vector:
supported_signature_algorithms:
length:						0004
vector:
/* Первая пара алгоритмов */
hash:						08
signature:
						40
/* Вторая пара алгоритмов */
hash:						08
signature:
						41
Extension: /* renegotiation_info */
extension_type:						FF01
extension_data:
length:						0001
vector:
renegotiated_connection:
length:						00
vector:						--
Extension: /* extended_master_secret */
extension_type:						0017
extension_data:
length:						0000
vector:						--
Итоговое сообщение ClientHello:
000000:	01	00	00	40	03	03	93	3E	A2	1E	C3	80	2A	56	15	50
000010:	EC	78	D6	ED	51	AC	24	39	D7	E7	49	C3	1B	C3	A3	45
000020:	61	65	88	96	84	CA	00	00	04	C1	00	C1	01	01	00	00
000030:	13	00	0D	00	06	00	04	08	40	08	41	FF	01	00	01	00
000040:	00	17	00	00
Формирование незащищенной записи с номером 0 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						0044
fragment:						010000400303933EA21EC3802A561550
						EC78D6ED51AC2439D7E749C31BC3A345
						6165889684CA000004C100C101010000
						13000D0006000408400841FF01000100
						00170000
Итоговая запись с номером 0 на стороне клиента:
000000:	16	03	03	00	44	01	00	00	40	03	03	93	3E	A2	1E	C3	---->
000010:	80	2A	56	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	49
000020:	C3	1B	C3	A3	45	61	65	88	96	84	CA	00	00	04	C1	00
000030:	C1	01	01	00	00	13	00	0D	00	06	00	04	08	40	08	41
000040:	FF	01	00	01	00	00	17	00	00

	Формирование сообщения ServerHello на стороне сервера:
	msg_type:						02
	length:						000041
	body:
	server_version:
	major:						03
	minor:						03
	random:						933EA21E49C31BC3A3456165889684CA
							A5576CE7924A24F58113808DBD9EF856
	session_id:
	length:						10
	vector:						C3802A561550EC78D6ED51AC2439D7E7
	cipher_suite:
	CipherSuite:						C100
	compression_method:
	CompressionMethod:						00
	extensions:
	length:						0009
	vector:
	Extension: /* renegotiation_info */
	extension_type:						FF01
	extension_data:
	length:						0001
	vector:
	renegotiated_connection:
	length:						00
	vector:						--
	Extension: /* extended_master_secret */
	extension_type:						0017
	extension_data:
	length:						0000
	vector:						--
	Итоговое сообщение ServerHello:
	000000:	02	00	00	41	03	03	93	3E	A2	1E	49	C3	1B	C3	A3	45
	000010:	61	65	88	96	84	CA	A5	57	6C	E7	92	4A	24	F5	81	13
	000020:	80	8D	BD	9E	F8	56	10	C3	80	2A	56	15	50	EC	78	D6
	000030:	ED	51	AC	24	39	D7	E7	C1	00	00	00	09	FF	01	00	01
	000040:	00	00	17	00	00
	Формирование незащищенной записи с номером 0 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						0045
	fragment:						020000410303933EA21E49C31BC3A345
							6165889684CAA5576CE7924A24F58113
							808DBD9EF85610C3802A561550EC78D6
							ED51AC2439D7E7C100000009FF010001
							0000170000
	Итоговая запись с номером 0 на стороне сервера:
<----	000000:	16	03	03	00	45	02	00	00	41	03	03	93	3E	A2	1E	49
	000010:	C3	1B	C3	A3	45	61	65	88	96	84	CA	A5	57	6C	E7	92
	000020:	4A	24	F5	81	13	80	8D	BD	9E	F8	56	10	C3	80	2A	56
	000030:	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	C1	00	00	00
	000040:	09	FF	01	00	01	00	00	17	00	00

	Формирование сообщения Certificate на стороне сервера:
	msg_type:							0B
	length:							00024C
	body:
	certificate_list:
	length:							000249
	vector:
	ASN.1Cert:
	length:							000246
	vector:							30820242308201AEA003020102020101
								300A06082A850307010103033042312C
								302A06092A864886F70D010901161D74
								...
								371AF83C5BC58B366DFEFA7345D50317
								867C177AC84AC07EE8612164629AB7BD
								C48AA0F64A741FE7298E82C5BFCE8672
								029F875391F7
	Итоговое сообщение Certificate:
	000000:	0B	00	02	4C	00	02	49	00	02	46	30	82	02	42	30	82
	000010:	01	AE	A0	03	02	01	02	02	01	01	30	0A	06	08	2A	85
	000020:	03	07	01	01	03	03	30	42	31	2C	30	2A	06	09	2A	86
	000030:	48	86	F7	0D	01	09	01	16	1D	74	6C	73	31	32	5F	73
	000040:	65	72	76	65	72	35	31	32	43	40	63	72	79	70	74	6F
	000050:	70	72	6F	2E	72	75	31	12	30	10	06	03	55	04	03	13
	000060:	09	53	65	72	76	65	72	35	31	32	30	1E	17	0D	31	37
	000070:	30	35	32	35	30	39	32	35	31	38	5A	17	0D	33	30	30
	000080:	35	30	31	30	39	32	35	31	38	5A	30	42	31	2C	30	2A
	000090:	06	09	2A	86	48	86	F7	0D	01	09	01	16	1D	74	6C	73
	0000A0:	31	32	5F	73	65	72	76	65	72	35	31	32	43	40	63	72
	0000B0:	79	70	74	6F	70	72	6F	2E	72	75	31	12	30	10	06	03
	0000C0:	55	04	03	13	09	53	65	72	76	65	72	35	31	32	30	81
	0000D0:	AA	30	21	06	08	2A	85	03	07	01	01	01	02	30	15	06
	0000E0:	09	2A	85	03	07	01	02	01	02	03	06	08	2A	85	03	07
	0000F0:	01	01	02	03	03	81	84	00	04	81	80	3A	83	EB	1D	F1
	000100:	B8	39	FD	E4	D2	5B	B3	52	27	2D	C2	10	33	7E	7C	0D
	000110:	9F	23	4E	9B	3C	70	67	B2	06	97	7A	24	97	3E	13	C3
	000120:	F6	9F	CD	47	F4	8B	28	0A	A3	E6	92	80	F5	3F	9B	66
	000130:	63	65	C6	72	D9	9A	47	DA	89	45	F1	EA	F4	11	7A	58
	000140:	BE	6A	B1	EB	67	D5	B3	E3	E1	78	BD	E6	2B	61	1D	A0
	000150:	A7	01	41	CB	1C	5E	6A	E6	DF	F2	99	F2	13	04	3B	B5
	000160:	DD	DF	B1	04	2C	3A	7F	72	95	7C	FC	0B	B3	0A	B2	9F
	000170:	05	A1	60	4E	2D	50	36	5B	E9	05	F3	A3	43	30	41	30
	000180:	1D	06	03	55	1D	0E	04	16	04	14	87	9C	C6	5A	0F	4A
	000190:	89	CB	4A	58	49	DF	05	61	56	9B	AA	DC	11	69	30	0B
	0001A0:	06	03	55	1D	0F	04	04	03	02	03	28	30	13	06	03	55
	0001B0:	1D	25	04	0C	30	0A	06	08	2B	06	01	05	05	07	03	01
	0001C0:	30	0A	06	08	2A	85	03	07	01	01	03	03	03	81	81	00
	0001D0:	35	BE	38	51	EC	B6	E9	2D	32	40	01	81	0F	8C	89	03
	0001E0:	52	42	F4	05	46	9F	4C	4E	CB	05	02	7C	57	E2	71	52
	0001F0:	12	AF	D7	CD	BB	0C	ED	7A	8B	4D	33	42	CC	50	1A	BD
	000200:	99	99	75	A5	8A	DE	0E	58	4F	CA	35	F5	2E	45	58	B7
	000210:	31	1D	49	D0	A0	51	32	79	F7	39	37	1A	F8	3C	5B	C5
	000220:	8B	36	6D	FE	FA	73	45	D5	03	17	86	7C	17	7A	C8	4A
	000230:	C0	7E	E8	61	21	64	62	9A	B7	BD	C4	8A	A0	F6	4A	74
	000240:	1F	E7	29	8E	82	C5	BF	CE	86	72	02	9F	87	53	91	F7
	Формирование незащищенной записи с номером 1 на стороне сервера:
	type:							16
	version:
	major:							03
	minor:							03
	length:							0250
	fragment:							0B00024C000249000246308202423082
								01AEA003020102020101300A06082A85
								0307010103033042312C302A06092A86
								...
								8B366DFEFA7345D50317867C177AC84A
								C07EE8612164629AB7BDC48AA0F64A74
								1FE7298E82C5BFCE8672029F875391F7
	Итоговая запись с номером 1 на стороне сервера:
<----	000000:	16	03	03	02	50	0B	00	02	4C	00	02	49	00	02	46	30
	000010:	82	02	42	30	82	01	AE	A0	03	02	01	02	02	01	01	30
	000020:	0A	06	08	2A	85	03	07	01	01	03	03	30	42	31	2C	30
	000030:	2A	06	09	2A	86	48	86	F7	0D	01	09	01	16	1D	74	6C
	000040:	73	31	32	5F	73	65	72	76	65	72	35	31	32	43	40	63
	000050:	72	79	70	74	6F	70	72	6F	2E	72	75	31	12	30	10	06
	000060:	03	55	04	03	13	09	53	65	72	76	65	72	35	31	32	30
	000070:	1E	17	0D	31	37	30	35	32	35	30	39	32	35	31	38	5A
	000080:	17	0D	33	30	30	35	30	31	30	39	32	35	31	38	5A	30
	000090:	42	31	2C	30	2A	06	09	2A	86	48	86	F7	0D	01	09	01
	0000A0:	16	1D	74	6C	73	31	32	5F	73	65	72	76	65	72	35	31
	0000B0:	32	43	40	63	72	79	70	74	6F	70	72	6F	2E	72	75	31
	0000C0:	12	30	10	06	03	55	04	03	13	09	53	65	72	76	65	72
	0000D0:	35	31	32	30	81	AA	30	21	06	08	2A	85	03	07	01	01
	0000E0:	01	02	30	15	06	09	2A	85	03	07	01	02	01	02	03	06
	0000F0:	08	2A	85	03	07	01	01	02	03	03	81	84	00	04	81	80
	000100:	3A	83	EB	1D	F1	B8	39	FD	E4	D2	5B	B3	52	27	2D	C2
	000110:	10	33	7E	7C	0D	9F	23	4E	9B	3C	70	67	B2	06	97	7A
	000120:	24	97	3E	13	C3	F6	9F	CD	47	F4	8B	28	0A	A3	E6	92
	000130:	80	F5	3F	9B	66	63	65	C6	72	D9	9A	47	DA	89	45	F1
	000140:	EA	F4	11	7A	58	BE	6A	B1	EB	67	D5	B3	E3	E1	78	BD
	000150:	E6	2B	61	1D	A0	A7	01	41	CB	1C	5E	6A	E6	DF	F2	99
	000160:	F2	13	04	3B	B5	DD	DF	B1	04	2C	3A	7F	72	95	7C	FC
	000170:	0B	B3	0A	B2	9F	05	A1	60	4E	2D	50	36	5B	E9	05	F3
	000180:	A3	43	30	41	30	1D	06	03	55	1D	0E	04	16	04	14	87
	000190:	9C	C6	5A	0F	4A	89	CB	4A	58	49	DF	05	61	56	9B	AA
	0001A0:	DC	11	69	30	0B	06	03	55	1D	0F	04	04	03	02	03	28
	0001B0:	30	13	06	03	55	1D	25	04	0C	30	0A	06	08	2B	06	01
	0001C0:	05	05	07	03	01	30	0A	06	08	2A	85	03	07	01	01	03
	0001D0:	03	03	81	81	00	35	BE	38	51	EC	B6	E9	2D	32	40	01
	0001E0:	81	0F	8C	89	03	52	42	F4	05	46	9F	4C	4E	CB	05	02
	0001F0:	7C	57	E2	71	52	12	AF	D7	CD	BB	0C	ED	7A	8B	4D	33
	000200:	42	CC	50	1A	BD	99	99	75	A5	8A	DE	0E	58	4F	CA	35
	000210:	F5	2E	45	58	B7	31	1D	49	D0	A0	51	32	79	F7	39	37
	000220:	1A	F8	3C	5B	C5	8B	36	6D	FE	FA	73	45	D5	03	17	86
	000230:	7C	17	7A	C8	4A	C0	7E	E8	61	21	64	62	9A	B7	BD	C4
	000240:	8A	A0	F6	4A	74	1F	E7	29	8E	82	C5	BF	CE	86	72	02
	000250:	9F	87	53	91	F7

Формирование сообщения CertificateRequest на стороне сервера:
msg_type:							0D
length:							00000B
body:
certificate_types:
length:							02
vector:
/* gost_sign256 */
							43
/* gost_sign512 */
							44
supported_signature_algorithms:
length:							0004
vector:
/* Первая пара алгоритмов */
hash:							08
signature:							40
/* Вторая пара алгоритмов */
hash:							08
signature:							41
certificate_authorities:
length:							0000
vector:							--
Итоговое сообщение CertificateRequest:
000000:	0D	00	00	0B	02	43	44	00	04	08	40	08	41	00	00

	Формирование незащищенной записи с номером 2 на стороне сервера:
	type:						16
	version
	major:						03
	minor:						03
	length:						000F
	fragment:						0D00000B0243440004084008410000
	Итоговая запись с номером 2 на стороне сервера:
<----	000000:	16	03	03	00	0F	0D	00	00	0B	02	43	44	00	04	08	40
	000010:	08	41	00	00

	Формирование сообщения ServerHelloDone на стороне сервера:
	msg_type:						0E
	length:						000000
	body:						--
	Итоговое сообщение ServerHelloDone:
	000000:	0E	00	00	00
	Формирование незащищенной записи с номером 3 на стороне сервера:
	type:						16
	version
	major						03
	minor						03
	length:						0004
	fragment:						0E000000
	Итоговая запись с номером 3 на стороне сервера:
<----	000000:	16	03	03	00	04	0E	00	00	00

Формирование сообщения Certificate на стороне клиента:
msg_type:						0B
length:						0001EA
body:
certificate_list:
length:						0001E7
vector:
ASN.1Cert:
length:						0001E4
vector:						308201E03082018DA003020102020101
						300A06082A850307010103023053312E
						302C06092A864886F70D010901161F74
						...
						C1CAB43AC01AFB0F3451BDC2DB188BBC
						B77884251CDF6037BA830F4B31D5E96F
						DC9BC1C95ABE658266C48402E070DE1F
						292724E8
Итоговое сообщение Certificate:
000000:	0B	00	01	EA	00	01	E7	00	01	E4	30	82	01	E0	30	82
000010:	01	8D	A0	03	02	01	02	02	01	01	30	0A	06	08	2A	85
000020:	03	07	01	01	03	02	30	53	31	2E	30	2C	06	09	2A	86
000030:	48	86	F7	0D	01	09	01	16	1F	74	6C	73	31	32	5F	63
000040:	6C	69	65	6E	74	32	35	36	41	5F	45	40	63	72	79	70
000050:	74	6F	70	72	6F	2E	72	75	31	21	30	1F	06	03	55	04
000060:	03	1E	18	00	43	00	6C	00	69	00	65	00	6E	00	74	00
000070:	32	00	35	00	36	00	41	00	5F	00	45	30	1E	17	0D	31
000080:	37	30	35	32	35	30	39	33	31	31	38	5A	17	0D	33	30
000090:	30	35	30	31	30	39	33	31	31	38	5A	30	53	31	2E	30
0000A0:	2C	06	09	2A	86	48	86	F7	0D	01	09	01	16	1F	74	6C
0000B0:	73	31	32	5F	63	6C	69	65	6E	74	32	35	36	41	5F	45
0000C0:	40	63	72	79	70	74	6F	70	72	6F	2E	72	75	31	21	30
0000D0:	1F	06	03	55	04	03	1E	18	00	43	00	6C	00	69	00	65
0000E0:	00	6E	00	74	00	32	00	35	00	36	00	41	00	5F	00	45
0000F0:	30	68	30	21	06	08	2A	85	03	07	01	01	01	01	30	15
000100:	06	09	2A	85	03	07	01	02	01	01	01	06	08	2A	85	03
000110:	07	01	01	02	02	03	43	00	04	40	75	49	0B	7B	F8	79
000120:	D8	1C	C5	A1	BA	EA	66	65	06	DF	B5	D7	BF	25	60	67
000130:	78	B7	24	F3	15	9E	8A	B1	5D	0F	86	F3	48	2C	B2	AB
000140:	10	8D	5A	C2	DE	4E	FB	2B	FA	E0	39	39	94	C2	DE	87
000150:	F0	D3	42	F8	61	83	F1	BB	E5	9E	A3	43	30	41	30	1D
000160:	06	03	55	1D	0E	04	16	04	14	74	49	1E	77	30	D3	42
000170:	A6	28	0E	72	A1	13	9D	D9	90	8B	FA	F1	03	30	0B	06
000180:	03	55	1D	0F	04	04	03	02	07	80	30	13	06	03	55	1D
000190:	25	04	0C	30	0A	06	08	2B	06	01	05	05	07	03	02	30
0001A0:	0A	06	08	2A	85	03	07	01	01	03	02	03	41	00	1C	2D
0001B0:	35	22	B4	11	02	D6	20	1F	23	50	C1	CA	B4	3A	C0	1A
0001C0:	FB	0F	34	51	BD	C2	DB	18	8B	BC	B7	78	84	25	1C	DF
0001D0:	60	37	BA	83	0F	4B	31	D5	E9	6F	DC	9B	C1	C9	5A	BE
0001E0:	65	82	66	C4	84	02	E0	70	DE	1F	29	27	24	E8
Формирование незащищенной записи с номером 1 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						01EE
fragment:						0B0001EA0001E70001E4308201E03082
						018DA003020102020101300A06082A85
						0307010103023053312E302C06092A86
						...
						3522B41102D6201F2350C1CAB43AC01A
						FB0F3451BDC2DB188BBCB77884251CDF
						6037BA830F4B31D5E96FDC9BC1C95ABE
						658266C48402E070DE1F292724E8
Итоговая запись с номером 1 на стороне клиента:
000000:	16	03	03	01	EE	0B	00	01	EA	00	01	E7	00	01	E4	30	---->
000010:	82	01	E0	30	82	01	8D	A0	03	02	01	02	02	01	01	30
000020:	0A	06	08	2A	85	03	07	01	01	03	02	30	53	31	2E	30
000030:	2C	06	09	2A	86	48	86	F7	0D	01	09	01	16	1F	74	6C
000040:	73	31	32	5F	63	6C	69	65	6E	74	32	35	36	41	5F	45
000050:	40	63	72	79	70	74	6F	70	72	6F	2E	72	75	31	21	30
000060:	1F	06	03	55	04	03	1E	18	00	43	00	6C	00	69	00	65
000070:	00	6E	00	74	00	32	00	35	00	36	00	41	00	5F	00	45
000080:	30	1E	17	0D	31	37	30	35	32	35	30	39	33	31	31	38
000090:	5A	17	0D	33	30	30	35	30	31	30	39	33	31	31	38	5A
0000A0:	30	53	31	2E	30	2C	06	09	2A	86	48	86	F7	0D	01	09
0000B0:	01	16	1F	74	6C	73	31	32	5F	63	6C	69	65	6E	74	32
0000C0:	35	36	41	5F	45	40	63	72	79	70	74	6F	70	72	6F	2E
0000D0:	72	75	31	21	30	1F	06	03	55	04	03	1E	18	00	43	00
0000E0:	6C	00	69	00	65	00	6E	00	74	00	32	00	35	00	36	00
0000F0:	41	00	5F	00	45	30	68	30	21	06	08	2A	85	03	07	01
000100:	01	01	01	30	15	06	09	2A	85	03	07	01	02	01	01	01
000110:	06	08	2A	85	03	07	01	01	02	02	03	43	00	04	40	75
000120:	49	0B	7B	F8	79	D8	1C	C5	A1	BA	EA	66	65	06	DF	B5
000130:	D7	BF	25	60	67	78	B7	24	F3	15	9E	8A	B1	5D	0F	86
000140:	F3	48	2C	B2	AB	10	8D	5A	C2	DE	4E	FB	2B	FA	E0	39
000150:	39	94	C2	DE	87	F0	D3	42	F8	61	83	F1	BB	E5	9E	A3
000160:	43	30	41	30	1D	06	03	55	1D	0E	04	16	04	14	74	49
000170:	1E	77	30	D3	42	A6	28	0E	72	A1	13	9D	D9	90	8B	FA
000180:	F1	03	30	0B	06	03	55	1D	0F	04	04	03	02	07	80	30
000190:	13	06	03	55	1D	25	04	0C	30	0A	06	08	2B	06	01	05
0001A0:	05	07	03	02	30	0A	06	08	2A	85	03	07	01	01	03	02
0001B0:	03	41	00	1C	2D	35	22	B4	11	02	D6	20	1F	23	50	C1
0001C0:	CA	B4	3A	C0	1A	FB	0F	34	51	BD	C2	DB	18	8B	BC	B7
0001D0:	78	84	25	1C	DF	60	37	BA	83	0F	4B	31	D5	E9	6F	DC
0001E0:	9B	C1	C9	5A	BE	65	82	66	C4	84	02	E0	70	DE	1F	29
0001F0:	27	24	E8

Значение PS, сгенерированное на стороне клиента:
000000:	A5	57	6C	E7	92	4A	24	F5	81	13	80	8D	BD	9E	F8	56
000010:	F5	BD	C3	B1	83	CE	5D	AD	CA	36	A5	3A	A0	77	65	1D
Случайное значение k_EPH, выбранное на стороне клиента:
0x150ACD11B66DD695AD18418FA7A2DC63
6B7E29DCA24536AABC826EE3175BB1FA
DC3AA0D01D3092E120B0FCF7EB872F4B
7E26EA17849D689222A48CF95A6E4831
Эфемерный ключ Q_EPH:
x = 0xC941BE5193189B476D5A0334114A3E04
BBE5B37C738AE40F150B334135288664
FEBFC5622818894A07B1F7AD60E28480
B4B637B90EA7D4BA980186B605D75BC6,
y = 0xA154F7B93E8148652011F4FD52C9A06A
6471ADB28D0A949AE26BC786DE874153
ABC00B35164F3214A8A83C00ECE27831
B093528456234EFE766224FC2A7E9ABE
Хэш-значение H от конкатенации случайных строк клиента и сервера:
000000:	C3	EF	04	28	D4	B7	A1	F4	C5	02	5F	2E	65	DD	2B	2E
000010:	A5	83	AE	EF	DB	67	C7	F4	21	4A	6A	29	8E	99	E3	25
Генерация ключей экспорта. Значение r:
0xC3EF0428D4B7A1F4C5025F2E65DD2B2E
Алгоритм генерации ключей экспорта. Значение UKM:
0xC3EF0428D4B7A1F4C5025F2E65DD2B2E
Ключи экспорта для вычисления имитовставки и шифрования, являющиеся результатом работы функции VKO₅₁₂:
000000:	7D	AC	56	E4	8A	4D	C1	70	FA	A8	FC	BA	E2	0D	B8	45
000010:	45	0C	CC	C4	C6	32	8B	DC	8D	01	15	7C	EF	A2	A5	F1
000020:	1F	1C	BA	D8	86	61	66	F0	1F	FA	AB	01	52	E2	4B	F4
000030:	60	9D	5F	46	A5	C8	99	C7	87	90	0D	08	B9	FC	AD	24
Значение вектора инициализации IV:
000000:	21	4A	6A	29	8E	99	E3	25
Экспортное представление PSExp значения PS:
000000:	25	0D	1B	67	A2	70	AB	04	D3	F6	54	18	E1	D3	80	B4
000010:	CB	94	5F	0A	3D	CA	51	50	0C	F3	A1	BE	F3	7F	76	C0
000020:	73	41	A9	83	9C	CF	6C	BA	71	89	DA	61	EB	67	17	6C
Формирование сообщения ClientKeyExchange на стороне клиента:
msg_type:						10
length:						0000E2
body:
exchange_keys:						3081DF0430250D1B67A270AB04D3F654
						18E1D380B4CB945F0A3DCA51500CF3A1
						BEF37F76C07341A9839CCF6CBA7189DA
						...
						93B03178E2EC003CA8A814324F16350B
						C0AB534187DE86C76BE29A940A8DB2AD
						71646AA0C952FDF411206548813EB9F7
						54A1
Итоговое сообщение ClientKeyExchange:
000000:	10	00	00	E2	30	81	DF	04	30	25	0D	1B	67	A2	70	AB
000010:	04	D3	F6	54	18	E1	D3	80	B4	CB	94	5F	0A	3D	CA	51
000020:	50	0C	F3	A1	BE	F3	7F	76	C0	73	41	A9	83	9C	CF	6C
000030:	BA	71	89	DA	61	EB	67	17	6C	30	81	AA	30	21	06	08
000040:	2A	85	03	07	01	01	01	02	30	15	06	09	2A	85	03	07
000050:	01	02	01	02	03	06	08	2A	85	03	07	01	01	02	03	03
000060:	81	84	00	04	81	80	C6	5B	D7	05	B6	86	01	98	BA	D4
000070:	A7	0E	B9	37	B6	B4	80	84	E2	60	AD	F7	B1	07	4A	89
000080:	18	28	62	C5	BF	FE	64	86	28	35	41	33	0B	15	0F	E4
000090:	8A	73	7C	B3	E5	BB	04	3E	4A	11	34	03	5A	6D	47	9B
0000A0:	18	93	51	BE	41	C9	BE	9A	7E	2A	FC	24	62	76	FE	4E
0000B0:	23	56	84	52	93	B0	31	78	E2	EC	00	3C	A8	A8	14	32
0000C0:	4F	16	35	0B	C0	AB	53	41	87	DE	86	C7	6B	E2	9A	94
0000D0:	0A	8D	B2	AD	71	64	6A	A0	C9	52	FD	F4	11	20	65	48
0000E0:	81	3E	B9	F7	54	A1
Формирование незащищенной записи с номером 2 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						00E6
fragment:						100000E23081DF0430250D1B67A270AB
						04D3F65418E1D380B4CB945F0A3DCA51
						500CF3A1BEF37F76C07341A9839CCF6C
						...
						2356845293B03178E2EC003CA8A81432
						4F16350BC0AB534187DE86C76BE29A94
						0A8DB2AD71646AA0C952FDF411206548
						813EB9F754A1
Итоговая запись с номером 2 на стороне клиента:
000000:	16	03	03	00	E6	10	00	00	E2	30	81	DF	04	30	25	0D	---->
000010:	1B	67	A2	70	AB	04	D3	F6	54	18	E1	D3	80	B4	CB	94
000020:	5F	0A	3D	CA	51	50	0C	F3	A1	BE	F3	7F	76	C0	73	41
000030:	A9	83	9C	CF	6C	BA	71	89	DA	61	EB	67	17	6C	30	81
000040:	AA	30	21	06	08	2A	85	03	07	01	01	01	02	30	15	06
000050:	09	2A	85	03	07	01	02	01	02	03	06	08	2A	85	03	07
000060:	01	01	02	03	03	81	84	00	04	81	80	C6	5B	D7	05	B6
000070:	86	01	98	BA	D4	A7	0E	B9	37	B6	B4	80	84	E2	60	AD
000080:	F7	B1	07	4A	89	18	28	62	C5	BF	FE	64	86	28	35	41
000090:	33	0B	15	0F	E4	8A	73	7C	B3	E5	BB	04	3E	4A	11	34
0000A0:	03	5A	6D	47	9B	18	93	51	BE	41	C9	BE	9A	7E	2A	FC
0000B0:	24	62	76	FE	4E	23	56	84	52	93	B0	31	78	E2	EC	00
0000C0:	3C	A8	A8	14	32	4F	16	35	0B	C0	AB	53	41	87	DE	86
0000D0:	C7	6B	E2	9A	94	0A	8D	B2	AD	71	64	6A	A0	C9	52	FD
0000E0:	F4	11	20	65	48	81	3E	B9	F7	54	A1

Извлечение экспортного представления PSExp:

000000:

000010:

000020:

Хэш-значение H от конкатенации случайных строк клиента и сервера:

000000:

000010:

Генерация ключей экспорта. Значение r:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение UKM:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Ключи экспорта

для вычисления имитовставки и шифрования, являющиеся результатом работы функции VKO₅₁₂:

000000:

000010:

000020:

000030:

Значение вектора инициализации IV:

000000:

Извлеченный общий секрет PS:

000000:

000010:

Случайное значение k, использующееся клиентом при формировании подписи:
0x163962EEA268203E7C6B3F70BF8D4A36
34CE6E2CFC424687951D70ACE0B4292A
Значение подписи sgn_C = SIGN_{k c}(HM):
000000:	F7	1F	43	62	45	5B	C5	5B	A8	9A	8F	AF	01	82	88	EC
000010:	00	B3	27	17	48	2E	76	24	B2	57	D9	79	7C	8F	F6	02
000020:	E3	15	FD	BD	8D	E5	6D	08	54	18	04	0E	1B	61	BB	F6
000030:	B3	01	AC	26	3D	50	03	8B	30	31	13	DB	36	17	50	3A
Формирование сообщения CertificateVerify на стороне клиента:
type:						0F
length:						000044
body:
algorithm:
hash:						08
signature:						40
signature:
length:						0040
vector:						F71F4362455BC55BA89A8FAF018288EC
						00B32717482E7624B257D9797C8FF602
						E315FDBD8DE56D085418040E1B61BBF6
						B301AC263D50038B303113DB3617503A
Итоговое сообщение CertificateVerify:
000000:	0F	00	00	44	08	40	00	40	F7	1F	43	62	45	5B	C5	5B
000010:	A8	9A	8F	AF	01	82	88	EC	00	B3	27	17	48	2E	76	24
000020:	B2	57	D9	79	7C	8F	F6	02	E3	15	FD	BD	8D	E5	6D	08
000030:	54	18	04	0E	1B	61	BB	F6	B3	01	AC	26	3D	50	03	8B
000040:	30	31	13	DB	36	17	50	3A
Формирование незащищенной записи с номером 3 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						0048
fragment:						0F00004408400040F71F4362455BC55B
						A89A8FAF018288EC00B32717482E7624
						B257D9797C8FF602E315FDBD8DE56D08
						5418040E1B61BBF6B301AC263D50038B
						303113DB3617503A
Итоговая запись с номером 3 на стороне клиента:
000000:	16	03	03	00	48	0F	00	00	44	08	40	00	40	F7	1F	43	---->
000010:	62	45	5B	C5	5B	A8	9A	8F	AF	01	82	88	EC	00	B3	27
000020:	17	48	2E	76	24	B2	57	D9	79	7C	8F	F6	02	E3	15	FD
000030:	BD	8D	E5	6D	08	54	18	04	0E	1B	61	BB	F6	B3	01	AC
000040:	26	3D	50	03	8B	30	31	13	DB	36	17	50	3A

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне клиента:

000000:

000010:

000020:

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне сервера:

000000:

000010:

000020:

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Формирование сообщения ChangeCipherSpec на стороне клиента:
type:						01
Итоговое сообщение ChangeCipherSpec:
000000:						01
Формирование незащищенной записи с номером 4 на стороне клиента:
type:						14
version:
major:						03
minor:						03
length:						0001
fragment:						01
Итоговая запись с номером 4 на стороне клиента:
000000:	14	03	03	00	01	01	---->

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования client_verify_data:

000000:

000010:

Данные client_verify_data:

000000:

000010:

Формирование сообщения Finished на стороне клиента:

msg_type:

length:

000020

body:

verify_data:

987C13E6FA16F3D510AE830023587227

3290094C8FC7B5F0C7D747C42735F8F1

Итоговое сообщение Finished:

000000:

000010:

000020:

Формирование защищенной записи с номером 0 на стороне клиента:

type:

version:

major:

minor:

length:

0034

fragment:

4DC53D655EDFD1843AF69ADBDE989C0B

1F0C0A1A0FD1B3F458029D8F9989FBF9

6C5C42971063A9B70714F412E4F6280F

7C21601B

Итоговая защищенная запись с номером 0 на стороне клиента:

000000:

---->

000010:

000020:

000030:

Формирование сообщения ChangeCipherSpec на стороне сервера:

type:

Итоговое сообщение ChangeCipherSpec:

000000:

Формирование незащищенной записи с номером 4 на стороне сервера:

type:

version:

major:

minor:

length:

0001

fragment:

Итоговая запись с номером 4 на стороне сервера:

<----

000000:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования server_verify_data:

000000:

000010:

Данные server_verify_data:

000000:

000010:

Формирование сообщения Finished на стороне сервера:

msg_type:

length:

000020

body:

verify data:

1E937DA477EE1F230A41D6E9D41446B7

F21CA1B2E2324A552D52B3255EB43DDF

Итоговое сообщение Finishied:

000000:

000010:

000020:

Формирование защищенной записи с номером 0 на стороне сервера:

type:

version:

major:

minor:

length:

0034

fragment:

F9887C3654B6CCC6AE7D7B18A46C663F

3D1DAF30C9A853A9871077FDD5CA063B

2C81BCC9D59FA6E3F5FAD9B2599BB586

854A2D76

Итоговая защищенная запись с номером 0 на стороне сервера:

<----

000000:

000010:

000020:

000030:

Данные, передающиеся в первом сообщении протокола Application Data, посылаемом клиентом после завершения протокола Handshake:
000000:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
000010:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
Формирование защищенной записи с номером 1 на стороне клиента:
type:					17
version:
major:					03
minor:					03
length:					0030
fragment:					F14F06FB8557408846080690E7A5525D
					1C6E9C901D24025486AB79728BF63D06
					5C09C27233006D65CFF0B5BA87504969
Итоговая защищенная запись с номером 1 на стороне клиента:
000000:	17	03	03	00	30	F1	4F	06	FB	85	57	40	88	46	08	06	---->
000010:	90	E7	A5	52	5D	1C	6E	9C	90	1D	24	02	54	86	AB	79
000020:	72	8B	F6	3D	06	5C	09	C2	72	33	00	6D	65	CF	F0	B5
000030:	BA	87	50	49	69

000000:

000010:

Формирование защищенной записи с номером 1 на стороне сервера:

type:

version

major

minor

length:

0030

fragment:

1561E52A8B6DB258746FFE18F3CDCB11

1D0173AF2E5C13741C99BFF13B47CD32

B3CED856A9506E706A2340D5841AB114

Итоговая защищенная запись с номером 1 на стороне сервера:

<----

000000:

000010:

000020:

000030:

Формирование оповещения close_notify на стороне клиента:

Alert:

level:

description:

Итоговое оповещение на стороне клиента:

000000:

Формирование защищенной записи с номером 2 на стороне клиента:

type:

version:

major:

minor:

length:

0012

fragment:

E530C164642A078CEF528CB465E9DA7E

AD4D

Итоговая защищенная запись с номером 2 на стороне клиента:

000000:

---->

000010:

	Формирование оповещения close_notify на стороне сервера:
	Alert:
	level:						01
	description:						00
	Итоговое оповещение на стороне клиента:
	000000:	01	00
	Формирование защищенной записи с номером 2 на стороне сервера:
	type:						15
	version:
	major:						03
	minor:						03
	length:						0012
	fragment:						EB62E5AB78BF2A4B678920A11027EC43
							0C3F
	Итоговая защищенная запись с номером 2 на стороне сервера:
<----	000000:	15	03	03	00	12	EB	62	E5	AB	78	BF	2A	4B	67	89	20
	000010:	A1	10	27	EC	43	0C	3F

В.3 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC

Идентификатор кривой сертификата сервера:

id-tc26-gost-3410-2012-256-paramSetB, "1.2.643.7.1.2.1.1.2".

Открытый ключ сервера Q_S:

x = 0xD203A4E98EA6C1B85C0A3918824D3E11

4B2DFF87E4A550CF3F6142D7BD13B1B8;

y = 0x234E0E38DC60DF61433426CB3BC04764

5EA7630E3A4B783C12E2E23C59864B2D.

Закрытый ключ сервера k_S:

0xFD89B8B534FB9E1F1DC628E8F454B35F

ECD3E3C17CD1F8AD6C2D309322551AE2.

Формирование сообщения ClientHello на стороне клиента:
msg_type:								01
length:								000040
body:
client_version:
major:								03
minor:								03
random:								933EA21EC3802A561550EC78D6ED51AC
								2439D7E749C31BC3A3456165889684CA
session_id:
length:								00
vector:								--
cipher_suites:
length:								0004
vector:
CipherSuite:								C100
CipherSuite:								C101
compression_methods:
length:								01
vector:
CompressionMethod:								00
extensions:
length:								0013
vector:
Extension: /* signature_algorithms */
extension_type:								000D
extension_data:
length:								0006
vector:
supported_signature_algorithms:
length:								0004
vector:
/* Первая пара алгоритмов */
hash:								08
signature:
								40
/* Вторая пара алгоритмов */
hash:								08
signature:
								41
Extension: /* renegotiation_info */
extension_type:								FF01
extension_data:
length:								0001
vector:
renegotiated_connection:
length:								00
vector:								--
Extension: /* extended_master_secret */
extension_type:								0017
extension_data:
length:								0000
vector:								--
Итоговое сообщение ClientHello:
000000:	01	00	00	40	03	03	93	3E	A2	1E	C3	80	2A	56	15	50
000010:	EC	78	D6	ED	51	AC	24	39	D7	E7	49	C3	1B	C3	A3	45
000020:	61	65	88	96	84	CA	00	00	04	C1	00	C1	01	01	00	00
000030:	13	00	0D	00	06	00	04	08	40	08	41	FF	01	00	01	00
000040:	00	17	00	00
Формирование незащищенной записи с номером 0 на стороне клиента:
type:						16
version:
major:						03
minor:						03
length:						0044
fragment:						010000400303933EA21EC3802A561550
						EC78D6ED51AC2439D7E749C31BC3A345
						6165889684CA000004C100C101010000
						13000D0006000408400841FF01000100
						00170000
Итоговая запись с номером 0 на стороне клиента:
000000:	16	03	03	00	44	01	00	00	40	03	03	93	3E	A2	1E	C3	---->
000010:	80	2A	56	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	49
000020:	C3	1B	C3	A3	45	61	65	88	96	84	CA	00	00	04	C1	00
000030:	C1	01	01	00	00	13	00	0D	00	06	00	04	08	40	08	41
000040:	FF	01	00	01	00	00	17	00	00

	Формирование сообщения ServerHello на стороне сервера:
	msg_type:						02
	length:						000041
	body:
	server_version:
	major:						03
	minor:						03
	random:						933EA21E49C31BC3A3456165889684CA
							A5576CE7924A24F58113808DBD9EF856
	session_id:
	length:						10
	vector:						C3802A561550EC78D6ED51AC2439D7E7
	cipher_suite:
	CipherSuite:						C101
	compression_method:
	CompressionMethod:						00
	extensions:
	length:						0009
	vector:
	Extension: /* renegotiation_info */
	extension_type:						FF01
	extension_data:
	length:						0001
	vector:
	renegotiated_connection:
	length:						00
	vector:						--
	Extension: /* extended_master_secret */
	extension_type:						0017
	extension_data:
	length:						0000
	vector:						--
	Итоговое сообщение ServerHello:
	000000:	02	00	00	41	03	03	93	3E	A2	1E	49	C3	1B	C3	A3	45
	000010:	61	65	88	96	84	CA	A5	57	6C	E7	92	4A	24	F5	81	13
	000020:	80	8D	BD	9E	F8	56	10	C3	80	2A	56	15	50	EC	78	D6
	000030:	ED	51	AC	24	39	D7	E7	C1	01	00	00	09	FF	01	00	01
	000040:	00	00	17	00	00
	Формирование незащищенной записи с номером 0 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						0045
	fragment:						020000410303933EA21E49C31BC3A345
							6165889684CAA5576CE7924A24F58113
							808DBD9EF85610C3802A561550EC78D6
							ED51AC2439D7E7C101000009FF010001
							0000170000
	Итоговая запись с номером 0 на стороне сервера:
<----	000000:	16	03	03	00	45	02	00	00	41	03	03	93	3E	A2	1E	49
	000010:	C3	1B	C3	A3	45	61	65	88	96	84	CA	A5	57	6C	E7	92
	000020:	4A	24	F5	81	13	80	8D	BD	9E	F8	56	10	C3	80	2A	56
	000030:	15	50	EC	78	D6	ED	51	AC	24	39	D7	E7	C1	01	00	00
	000040:	09	FF	01	00	01	00	00	17	00	00

	Формирование сообщения Certificate на стороне сервера:
	msg_type:						0B
	length:						000310
	body:
	certificate_list:
	length:						00030D
	vector:
	ASN.1Cert:
	length:						00030A
	vector:						30820306308202B5A003020102021312
							004093577006EC0AA47986C400010040
							9357300806062A8503020203307F3123
							...
							493E2A737A925011968515E3A4D5D332
							B8DB3257F4E561C0B399770AC85B6A38
							F98BEC3B0D8EBBD2CB8B7347F3FBE397
							1E2FCEA937CB9E86CECA
	Итоговое сообщение Certificate:
	000000:	0B	00	03	10	00	03	0D	00	03	0A	30	82	03	06	30	82
	000010:	02	B5	A0	03	02	01	02	02	13	12	00	40	93	57	70	06
	000020:	EC	0A	A4	79	86	C4	00	01	00	40	93	57	30	08	06	06
	000030:	2A	85	03	02	02	03	30	7F	31	23	30	21	06	09	2A	86
	000040:	48	86	F7	0D	01	09	01	16	14	73	75	70	70	6F	72	74
	000050:	40	63	72	79	70	74	6F	70	72	6F	2E	72	75	31	0B	30
	000060:	09	06	03	55	04	06	13	02	52	55	31	0F	30	0D	06	03
	000070:	55	04	07	13	06	4D	6F	73	63	6F	77	31	17	30	15	06
	000080:	03	55	04	0A	13	0E	43	52	59	50	54	4F	2D	50	52	4F
	000090:	20	4C	4C	43	31	21	30	1F	06	03	55	04	03	13	18	43
	0000A0:	52	59	50	54	4F	2D	50	52	4F	20	54	65	73	74	20	43
	0000B0:	65	6E	74	65	72	20	32	30	1E	17	0D	32	30	30	32	30
	0000C0:	37	31	36	32	35	33	36	5A	17	0D	32	30	30	35	30	37
	0000D0:	31	36	33	35	33	36	5A	30	14	31	12	30	10	06	03	55
	0000E0:	04	03	0C	09	74	65	73	74	5F	32	35	36	42	30	5E	30
	0000F0:	17	06	08	2A	85	03	07	01	01	01	01	30	0B	06	09	2A
	000100:	85	03	07	01	02	01	01	02	03	43	00	04	40	B8	B1	13
	000110:	BD	D7	42	61	3F	CF	50	A5	E4	87	FF	2D	4B	11	3E	4D
	000120:	82	18	39	0A	5C	B8	C1	A6	8E	E9	A4	03	D2	2D	4B	86
	000130:	59	3C	E2	E2	12	3C	78	4B	3A	0E	63	A7	5E	64	47	C0
	000140:	3B	CB	26	34	43	61	DF	60	DC	38	0E	4E	23	A3	82	01
	000150:	76	30	82	01	72	30	13	06	03	55	1D	25	04	0C	30	0A
	000160:	06	08	2B	06	01	05	05	07	03	04	30	0E	06	03	55	1D
	000170:	0F	01	01	FF	04	04	03	02	04	F0	30	1D	06	03	55	1D
	000180:	0E	04	16	04	14	10	ED	F5	C9	D3	74	2E	A9	4B	65	D4
	000190:	87	4C	09	9E	9C	3A	15	25	A3	30	1F	06	03	55	1D	23
	0001A0:	04	18	30	16	80	14	4E	83	3E	14	69	EF	EC	5D	7A	95
	0001B0:	2B	5F	11	FE	37	32	16	49	55	2B	30	5C	06	03	55	1D
	0001C0:	1F	04	55	30	53	30	51	A0	4F	A0	4D	86	4B	68	74	74
	0001D0:	70	3A	2F	2F	74	65	73	74	63	61	2E	63	72	79	70	74
	0001E0:	6F	70	72	6F	2E	72	75	2F	43	65	72	74	45	6E	72	6F
	0001F0:	6C	6C	2F	43	52	59	50	54	4F	2D	50	52	4F	25	32	30
	000200:	54	65	73	74	25	32	30	43	65	6E	74	65	72	25	32	30
	000210:	32	28	31	29	2E	63	72	6C	30	81	AC	06	08	2B	06	01
	000220:	05	05	07	01	01	04	81	9F	30	81	9C	30	64	06	08	2B
	000230:	06	01	05	05	07	30	02	86	58	68	74	74	70	3A	2F	2F
	000240:	74	65	73	74	63	61	2E	63	72	79	70	74	6F	70	72	6F
	000250:	2E	72	75	2F	43	65	72	74	45	6E	72	6F	6C	6C	2F	74
	000260:	65	73	74	2D	63	61	2D	32	30	31	34	5F	43	52	59	50
	000270:	54	4F	2D	50	52	4F	25	32	30	54	65	73	74	25	32	30
	000280:	43	65	6E	74	65	72	25	32	30	32	28	31	29	2E	63	72
	000290:	74	30	34	06	08	2B	06	01	05	05	07	30	01	86	28	68
	0002A0:	74	74	70	3A	2F	2F	74	65	73	74	63	61	2E	63	72	79
	0002B0:	70	74	6F	70	72	6F	2E	72	75	2F	6F	63	73	70	2F	6F
	0002C0:	63	73	70	2E	73	72	66	30	08	06	06	2A	85	03	02	02
	0002D0:	03	03	41	00	D5	A1	24	50	71	DB	49	3E	2A	73	7A	92
	0002E0:	50	11	96	85	15	E3	A4	D5	D3	32	B8	DB	32	57	F4	E5
	0002F0:	61	C0	B3	99	77	0A	C8	5B	6A	38	F9	8B	EC	3B	0D	8E
	000300:	BB	D2	CB	8B	73	47	F3	FB	E3	97	1E	2F	CE	A9	37	CB
	000310:	9E	86	CE	CA
	Формирование незащищенной записи с номером 1 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						0314
	fragment:						0B00031000030D00030A308203063082
							02B5A003020102021312004093577006
							EC0AA47986C400010040935730080606
							...
							5011968515E3A4D5D332B8DB3257F4E5
							61C0B399770AC85B6A38F98BEC3B0D8E
							BBD2CB8B7347F3FBE3971E2FCEA937CB
							9E86CECA
	Итоговая запись с номером 1 на стороне сервера:
<---	000000:	16	03	03	03	14	0B	00	03	10	00	03	0D	00	03	0A	30
	000010:	82	03	06	30	82	02	B5	A0	03	02	01	02	02	13	12	00
	000020:	40	93	57	70	06	EC	0A	A4	79	86	C4	00	01	00	40	93
	000030:	57	30	08	06	06	2A	85	03	02	02	03	30	7F	31	23	30
	000040:	21	06	09	2A	86	48	86	F7	0D	01	09	01	16	14	73	75
	000050:	70	70	6F	72	74	40	63	72	79	70	74	6F	70	72	6F	2E
	000060:	72	75	31	0B	30	09	06	03	55	04	06	13	02	52	55	31
	000070:	0F	30	0D	06	03	55	04	07	13	06	4D	6F	73	63	6F	77
	000080:	31	17	30	15	06	03	55	04	0A	13	0E	43	52	59	50	54
	000090:	4F	2D	50	52	4F	20	4C	4C	43	31	21	30	1F	06	03	55
	0000A0:	04	03	13	18	43	52	59	50	54	4F	2D	50	52	4F	20	54
	0000B0:	65	73	74	20	43	65	6E	74	65	72	20	32	30	1E	17	0D
	0000C0:	32	30	30	32	30	37	31	36	32	35	33	36	5A	17	0D	32
	0000D0:	30	30	35	30	37	31	36	33	35	33	36	5A	30	14	31	12
	0000E0:	30	10	06	03	55	04	03	0C	09	74	65	73	74	5F	32	35
	0000F0:	36	42	30	5E	30	17	06	08	2A	85	03	07	01	01	01	01
	000100:	30	0B	06	09	2A	85	03	07	01	02	01	01	02	03	43	00
	000110:	04	40	B8	B1	13	BD	D7	42	61	3F	CF	50	A5	A4	87	FF
	000120:	2D	4B	11	3E	4D	82	18	39	0A	5C	B8	C1	A6	8E	E9	A4
	000130:	03	D2	2D	4B	86	59	3C	E2	E2	12	3C	78	4B	3A	0E	63
	000140:	A7	5E	64	47	C0	3B	CB	26	34	43	61	DF	60	DC	38	0E
	000150:	4E	23	A3	82	01	76	30	82	01	72	30	13	06	03	55	1D
	000160:	25	04	0C	30	0A	06	08	2B	06	01	05	05	07	03	04	30
	000170:	0E	06	03	55	1D	0F	01	01	FF	04	04	03	02	04	F0	30
	000180:	1D	06	03	55	1D	0E	04	16	04	14	10	ED	F5	C9	D3	74
	000190:	2E	A9	4B	65	D4	87	4C	09	9E	9C	3A	15	25	A3	30	1F
	0001A0:	06	03	55	1D	23	04	18	30	16	80	14	4E	83	3E	14	69
	0001B0:	EF	EC	5D	7A	95	2B	5F	11	FE	37	32	16	49	55	2B	30
	0001C0:	5C	06	03	55	1D	1F	04	55	30	53	30	51	A0	4F	A0	4D
	0001D0:	86	4B	68	74	74	70	3A	2F	2F	74	65	73	74	63	61	2E
	0001E0:	63	72	79	70	74	6F	70	72	6F	2E	72	75	2F	43	65	72
	0001F0:	74	45	6E	72	6F	6C	6C	2F	43	52	59	50	54	4F	2D	50
	000200:	52	4F	25	32	30	54	65	73	74	25	32	30	43	65	6E	74
	000210:	65	72	25	32	30	32	28	31	29	2E	63	72	6C	30	81	AC
	000220:	06	08	2B	06	01	05	05	07	01	01	04	81	9F	30	81	9C
	000230:	30	64	06	08	2B	06	01	05	05	07	30	02	86	58	68	74
	000240:	74	70	3A	2F	2F	74	65	73	74	63	61	2E	63	72	79	70
	000250:	74	6F	70	72	6F	2E	72	75	2F	43	65	72	74	45	6E	72
	000260:	6F	6C	6C	2F	74	65	73	74	2D	63	61	2D	32	30	31	34
	000270:	5F	43	52	59	50	54	4F	2D	50	52	4F	25	32	30	54	65
	000280:	73	74	25	32	30	43	65	6E	74	65	72	25	32	30	32	28
	000290:	31	29	2E	63	72	74	30	34	06	08	2B	06	01	05	05	07
	0002A0:	30	01	86	28	68	74	74	70	3A	2F	2F	74	65	73	74	63
	0002B0:	61	2E	63	72	79	70	74	6F	70	72	6F	2E	72	75	2F	6F
	0002C0:	63	73	70	2F	6F	63	73	70	2E	73	72	66	30	08	06	06
	0002D0:	2A	85	03	02	02	03	03	41	00	D5	A1	24	50	71	DB	49
	0002E0:	3E	2A	73	7A	92	50	11	96	85	15	E3	A4	D5	D3	32	B8
	0002F0:	DB	32	57	F4	E5	61	C0	B3	99	77	0A	C8	5B	6A	38	F9
	000300:	8B	EC	3B	0D	8E	BB	D2	CB	8B	73	47	F3	FB	E3	97	1E
	000310:	2F	CE	A9	37	CB	9E	86	CE	CA
	Формирование сообщения ServerHelloDone на стороне сервера:
	msg_type:						0E
	length:						000000
	body:						--
	Итоговое сообщение ServerHelloDone:
	000000:	0E	00	00	00
	Формирование незащищенной записи с номером 2 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						0004
	fragment:						0E000000
	Итоговая запись с номером 2 стороне сервера:
<----	000000:	16	03	03	00	04	0E	00	00	00

Значение PS, сгенерированное на стороне клиента:

000000:

000010:

Случайное значение k_EPH, выбранное на стороне клиента:

0xA5C77C7482373DE16CE4A6F73CCE7F78

471493FF2C0709B8B706C9E8A25E6C1E

Эфемерный ключ Q_EPH:

x = 0xA8F36D63D262A203978F1B3B6795CDBB

F1AE7FB8EF7F47F1F18871C198E00793,

y = 0x34CA5D6B4485640EA195435993BEB1F8

B016ED610496B5CC175AC2EA1F14F887

Хэш-значение H от конкатенации случайных строк клиента и сервера:

000000:

000010:

Генерация ключей экспорта. Значение r:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Алгоритм генерации ключей экспорта. Значение UKM:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение seed:

000000:

Генерация ключей экспорта. Значение K_EXP:

000000:

000010:

Ключи экспорта

для вычисления имитовставки и шифрования:

000000:

000010:

000020:

000030:

Значение вектора инициализации IV:

000000:

Экспортное представление PSExp значения PS:

000000:

000010:

000020:

Формирование сообщения ClientKeyExchange на стороне клиента:

msg_type:

length:

00008D

body:

exchange_keys:

30818A0428272DFF4F3D9562D14A570C

3562FED40B035B8EF7E543AB3EDDC929

A8C678A5F78E1FC42CABDE0CC8305E30

...

98C17188F1F1477FEFB87FAEF1BBCD95

673B1B8F9703A262D2636DF3A887F814

1FEAC25A17CCB5960461ED16B0F8B1BE

93594395A10E6485446B5DCA34

Итоговое сообщение ClientKeyExchange:

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

000090:

Формирование незащищенной записи с номером 1 на стороне клиента:

type:

version:

major:

minor:

length:

0091

fragment:

1000008D30818A0428272DFF4F3D9562

D14A570C3562FED40B035B8EF7E543AB

3EDDC929A8C678A5F78E1FC42CABDE0C

...

F1BBCD95673B1B8F9703A262D2636DF3

A887F8141FEAC25A17CCB5960461ED16

B0F8B1BE93594395A10E6485446B5DCA

Итоговая запись с номером 1 на стороне клиента:

000000:

---->

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

000090:

Извлечение экспортного представления PSExp:

000000:

000010:

000020:

Хэш-значение H от конкатенации случайных строк клиента и сервера:

000000:

000010:

Генерация ключей экспорта. Значение r:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение UKM:

0xC3EF0428D4B7A1F4C5025F2E65DD2B2E

Генерация ключей экспорта. Значение seed:

000000:

Генерация ключей экспорта. Значение K_EXP:

000000:

000010:

Ключи экспорта

для вычисления имитовставки и шифрования:

000000:

000010:

000020:

000030:

Значение вектора инициализации IV:

000000:

Извлеченный общий секрет PS:

000000:

000010:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне клиента:

000000:

000010:

000020:

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования MS:

000000:

000010:

Общее секретное значение MS, выработанное на стороне сервера:

000000:

000010:

000020:

000000:

000010:

000020:

000030:

000040:

000050:

000060:

000070:

000080:

Формирование сообщения ChangeCipherSpec на стороне клиента:
type:							01
Итоговое сообщение ChangeCipherSpec:
000000:	01
Формирование незащищенной записи с номером 2 на стороне клиента:
type:						14
version:
major:						03
minor:						03
length:						0001
fragment:						01
Итоговая запись с номером 2 на стороне клиента:
000000:	14	03	03	00	01	01		---->

Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования client_verify_data:

000000:

000010:

Данные client_verify_data:

000000:

000010:

Формирование сообщения Finished на стороне клиента:

msg_type:

length:

000020

body:

verify_data:

1E49CC6D60751E39F1DAC4148DAF26DA

BE428BB3874448C84746F55B46C36B38

Итоговое сообщение Finished:

000000:

000010:

000020:

Формирование защищенной записи с номером 0 на стороне клиента:

type:

version:

major:

minor:

length:

002C

fragment:

193DB303FCC3A4329F5306A574516719

F6CA3FA78D51F809044B4B4311BFD835

A1D0AE74269E419A63F38136

Итоговая защищенная запись с номером 0 на стороне клиента:

000000:

---->

000010:

000020:

000030:

	Формирование сообщения ChangeCipherSpec на стороне сервера:
	type:						01
	Итоговое сообщение ChangeCipherSpec:
	000000:	01
	Формирование незащищенной записи с номером 3 на стороне сервера:
	type:						14
	version:
	major:						03
	minor:						03
	length:						0001
	fragment:						01
	Итоговая запись с номером 3 на стороне сервера:
<----	000000:	14	03	03	00	01	01

	Хэш-значение HASH(HM) конкатенации всех сообщений протокола Handshake для формирования server _verify_ data:
	000000:	6F	22	98	D8	87	B1	B8	25	1F	26	5F	95	58	98	59	77
	000010:	2C	CE	56	C2	97	04	FD	96	A7	26	E2	75	EC	A5	DE	F9
	Данные server_verify_data:
	000000:	95	B1	97	CD	1E	DF	64	15	2D	48	91	6D	33	6F	95	17
	000010:	46	49	F5	C8	78	1C	E1	71	BD	4D	71	4A	AD	58	69	97
	Формирование сообщения Finished на стороне сервера:
	msg_type:						14
	length:						000020
	body:
	verify_data:						95B197CD1EDF64152D48916D336F9517
	verify_data:						4649F5C8781CE171BD4D714AAD586997
	Итоговое сообщение Finished:
	000000:	14	00	00	20	95	B1	97	CD	1E	DF	64	15	2D	48	91	6D
	000010:	33	6F	95	17	46	49	F5	C8	78	1C	E1	71	BD	4D	71	4A
	000020:	AD	58	69	97
	Формирование защищенной записи с номером 0 на стороне сервера:
	type:						16
	version:
	major:						03
	minor:						03
	length:						002C
	fragment:						90EEE04799BCEA157A022CCCA6D99203
							33A1C871B9717F562A2063766C7B814B
							F4DAD8180F31D912B4C88DD1
	Итоговая защищенная запись с номером 0 на стороне сервера:
<----	000000:	16	03	03	00	2C	90	EE	E0	47	99	BC	EA	15	7A	02	2C
	000010:	CC	A6	D9	92	03	33	A1	C8	71	B9	71	7F	56	2A	20	63
	000020:	76	6C	7B	81	4B	F4	DA	D8	18	0F	31	D9	12	B4	C8	8D
	000030:	D1

Данные, передающиеся в первом сообщении протокола Application Data, посылаемом клиентом после завершения протокола Handshake:
000000:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
000010:	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
Формирование защищенной записи с номером 1 на стороне клиента:
type:						17
version:
major:						03
minor:						03
length:						0028
fragment:						4B5EAFDEDEFCFBB733D0D3FFE92866B6
						DFFEC7D1AA75C4EE921B64EA3176467F
						E4CA5C2562AC2063
Итоговая защищенная запись с номером 1 на стороне клиента:
000000:	17	03	03	00	28	4B	5E	AF	DE	DE	FC	FB	B7	33	D0	D3	---->
000010:	FF	E9	28	66	B6	DF	FE	C7	D1	AA	75	C4	EE	92	1B	64
000020:	EA	31	76	46	7F	E4	CA	5C	25	62	AC	20	63

000000:

000010:

Формирование защищенной записи с номером 1 на стороне сервера:

type:

version:

major:

minor:

length:

0028

fragment:

53F13CC4BC14773D886CA26C710BC5D1

7912DF0022527E41096E6A8D20ABE3A8

01EEAEB07E193216

Итоговая защищенная запись с номером 1 на стороне сервера:

<----

000000:

000010:

000020:

Формирование оповещения close_notify на стороне клиента:

Alert:

level:

description:

Итоговое оповещение на стороне клиента:

000000:

Формирование защищенной записи с номером 2 на стороне клиента:

type:

version:

major:

minor:

length:

000A

fragment:

8C07B2025AF02FF4DC8B

Итоговая защищенная запись с номером 2 на стороне клиента:

000000:

---->

	Формирование оповещения close_notify на стороне сервера:
	Alert:
	level:						01
	description:						00
	Итоговое оповещение на стороне клиента:
	000000:	01	00
	Формирование защищенной записи с номером 2 на стороне сервера:
	type:						15
	version:
	major:						03
	minor:						03
	length:						000A
	fragment:						77F6524EF4ED966D1081
	Итоговая защищенная запись с номером 2 на стороне сервера:
<----	000000:	15	03	03	00	0A	77	F6	52	4E	F4	ED	96	6D	10	81

Приложение Г

(справочное)

ЯЗЫК ПРЕДСТАВЛЕНИЯ ДАННЫХ В ПРОТОКОЛЕ TLS

В настоящем приложении приведено описание общепринятого языка представления данных в протоколе TLS 1.2.

Г.1 Размер базового блока данных

Представление всех элементов данных указывается в явном виде. Размер базового блока данных, передаваемых в рамках работы протокола TLS 1.2, составляет 1 байт (8 битов). Многобайтовые элементы данных являются конкатенацией (объединением) байтов слева направо, сверху вниз и представляются в виде байтовых строк в формате big-endian.

Г.2 Разное

Текст комментария начинается с символов "/*" и заканчивается символами "*/".

Необязательные (опциональные) компоненты выделяются с помощью двойных квадратных скобок "[[ ]]".

Тип элементов размером в 1 байт, содержащих не интерпретируемые в рамках работы протокола TLS данные, обозначается типом opaque.

Г.3 Числа

Базовым типом числовых данных является беззнаковый байт (uint8). В настоящих рекомендациях использованы следующие предопределенные типы числовых данных:

uint8 uint16[2];

uint8 uint24[3];

uint8 uint32[4];

uint8 uint64[8].

Все числовые значения указанных типов представляются в виде байтовых строк в формате big-endian.

Г.4 Векторы

Вектор (одномерный массив) представляет собой поток элементов данных одного и того же типа. Длина вектора задается в байтах и может быть указана во время объявления или оставаться неопределенной вплоть до начала работы протокола TLS.

Вектор T' фиксированной длины, содержащий данные типа T, задается следующим образом:

T T' [n];

где значение n является длиной вектора T' в байтах и кратно размеру T. При этом длина вектора не включается в кодированный поток данных.

Байтовое представление значения, являющегося вектором, задается конкатенацией байтовых представлений элементов данного вектора в порядке их нумерации (слева направо).

В приведенном ниже примере вектор Datum определен как три последовательных байта, не интерпретируемых протоколом, в то же время вектор Data определен как три последовательных вектора Datum, состоящих в общей сложности из 9 байтов:

opaque Datum[3]; /* три неинтерпретируемых байта */

Datum Data[9]; /* три последовательных 3-байтовых вектора */

Векторы переменной длины определяются с указанием допустимого поддиапазона размеров (включая крайние значения) в формате <floor..ceiling>. При кодировании в поток данных перед содержимым вектора помещается его фактическая длина. Значение длины данного вектора представляется в виде байтовой строки длиной, равной длине строки, требуемой для хранения максимального значения длины вектора ceiling. Вектор переменной длины, имеющий фактическую нулевую длину, представляется в виде байтовой строки, соответствующей нулевому значению.

Вектор T' переменной длины, содержащий данные типа T, задается следующим образом:

T T' <floor..ceiling>;

При этом длина кодированного вектора должна быть в точности кратна размеру одиночного элемента (например, 17-байтовый вектор типа uint16 будет недопустимым).

В следующем примере первый вектор mandatory имеет тип opaque и размер от 300 до 400 байтов (такой вектор никогда не может быть пустым). Поле фактической длины вектора занимает 2 байта (uint16), которых достаточно для записи максимальной длины вектора, равной 400. Второй вектор longer может содержать не более 800 байтов данных или не более 400 элементов uint16 и может быть вектором нулевой длины. Его кодирование будет включать поле размером 2 байта, соответствующее длине вектора и предшествующее его элементам:

opaque mandatory<300..400>;

/* поле длины занимает 2 байта, не может быть пустым */

uint16 longer<0..800>;

/* от 0 до 400 16-битовых целых чисел без знака */

Г.5 Перечисления enum

В рамках работы протокола TLS 1.2 используется дополнительный тип разреженных данных - перечисление enum. Каждое определение перечисления задает новый тип. Операции присваивания и сравнения могут использовать только элементы перечисления одного и того же типа.

Перечисление задано следующим образом:

enum { e1(v1), e2(v2), ..., en(vn) [[, (n)]] } Te;

где v1, v2, ..., vn - значения элементов e1, e2, ..., en соответственно;

(n) - опциональный элемент, содержащий максимальное возможное значение, которое может принимать элемент данного перечисления, и предназначенный для определения байтового размера каждого элемента перечисления.

Так как элементы перечисления не упорядочены, им может быть присвоено любое уникальное значение в любом порядке.

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

В следующем примере элементы перечисления Color будут занимать в потоке по 1 байту:

enum { red(3), blue(5), white(7) } Color;

Для того чтобы задать байтовый размер элементов перечисления без определения лишнего элемента, можно дополнительно задать значение без сопоставления с ним соответствующего наименования. В следующем примере элемент перечисления Taste будет занимать 2 байта в потоке данных, но в текущей версии протокола может принимать значения только 1, 2 или 4:

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Наименования элементов перечисления допустимы в пределах заданного типа. В первом примере полностью корректное обращение ко второму элементу перечисления будет иметь вид Color.blue. Подобное уточнение не требуется, если цель присвоения точно задана:

Color color = Color.blue; /* переопределение, допустимо */

Color color = blue; /* корректно, тип задан неявно */

Если предполагается, что элементы перечисления не будут использованы в качестве числовых значений, допускается следующее определение перечисления:

enum { low, medium, high } Amount;

Г.6 Структуры

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

Структура задана следующим образом:

struct {

T1 f1;

T2 f2;

...

Tn fn;

} [[T]];

где f1, f2, ..., fn являются полями структуры T, значения которых имеют типы T1, T2, ..., Tn соответственно.

Байтовое представление данных, соответствующих определенной структуре, задается конкатенацией байтовых представлений значений полей структуры в порядке их объявления (сверху вниз).

Векторы допустимы в качестве полей структуры, имеющих фиксированную или переменную длину, и формируются в соответствии с разделом Г.4. Примерами структур, содержащих вектор в качестве своего поля, являются структуры V1 и V2, описанные в разделе Г.8.

Обращение к полям внутри структуры может быть осуществлено с использованием наименований элементов с применением такого же синтаксиса, который описан для перечислений. Например, обращение T.f2 будет указывать на второе поле определенной выше структуры T. Определения структур могут быть вложенными.

Г.7 Константы

Типизированные константы можно определить с помощью объявления переменной желаемого типа и присваивания ей соответствующего значения.

Переменным недоопределенных типов (таких, как opaque, векторы переменной длины и структуры, содержащие элементы типа opaque) присваивать значения не допускается. Поля многоэлементной структуры или вектора не могут быть проигнорированы.

Например:

struct {

uint8 f1;

uint8 f2;

} Example1;

Example1 ex1 = {1, 4}; /* присваивает f1 = 1, f2 = 4 */

Г.8 Оператор выбора select

Определяемые структуры могут содержать варианты формирования, выбор между которыми производится при помощи оператора select и основывается на доступной в среде информации. Переключатель (селектор) вариантов должен быть перечислением (см. Г.5), которое определяет возможные варианты формирования структуры данных и задается следующим образом:

enum { e1(v1), e2(v2), ..., en (vn) [[, (n)]] } E;

struct {

T1 f1;

T2 f2;

....

Tn fn;

select (E) {

case e1: Te1;

case e2: Te2;

case e3: case e4: Te3;

....

case en: Ten;

} [ [fv]];

} [[Tv]];

Для каждого элемента, объявленного в перечислении, должна быть определена соответствующая ветка оператора select. Если две ветки следуют непосредственно друг за другом без промежуточных полей, то они содержат одинаковый тип поля. Так, в примере ниже значения orange и banana соответствуют типу V2.

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

Ниже приведен следующий пример формирования структуры на основе использования оператора select:

enum { apple, orange, banana } VariantTag;

struct {

uint16 number;

opaque string<0..10>; /* вектор переменной длины */

} V1;

struct {

uint32 number;

opaque string[10]; /* вектор фиксированной длины */

} V2;

struct {

select (VariantTag) { /* значение селектора задается неявно */

case apple:

V1; /* VariantBody, tag = apple */

case orange:

case banana:

V2; /* VariantBody, tag = orange или banana */

} variant_body; /* опциональное наименование варианта */

} VariantRecord;

БИБЛИОГРАФИЯ

[1]	IETF RFC 5246	T. Dierks and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, IETF RFC 5246, August 2008
[2]	IETF RFC 7627	K. Bhargavan, A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray, Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension, IETF 7627, September 2015
[3]	IETF RFC 5746	E. Rescorla, M. Ray, S. Dispensa, N. Oskov, Transport Layer Security (TLS) Renegotiation Indication Extension, IETF 5746, February 2010
[4]	IETF RFC 7091	V. Dolmatov, A. Degtyarev, GOST R 34.10-2012: Digital Signature Algorithm, IETF 7091, December 2013

УДК 681.3.06:006.354	ОКС 35.040
Ключевые слова: криптографические протоколы, аутентификация, пароль, ключ