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

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

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["Р 1323565.1.020-2018"]:::rst
  click n0 "https://bukva.ai/docs/r-1323565-1-020-2018" "Р 1323565.1.020-2018. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в... (ут"
  n1["Р 1323565.1.020-2020"]:::doc
  click n1 "https://bukva.ai/docs/r-1323565-1-020-2020" "Р 1323565.1.020-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в... (ут"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

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 г. № 1327-ст

4 ВЗАМЕН Р 1323565.1.020-2018

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. № 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

3.1.4

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

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

Примечания

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

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

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

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

Примечания

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):

• строкой со случайными байтами rC, задаваемой клиентом;
• строкой со случайными байтами rS, задаваемой сервером;
• ключом клиента для вычисления имитовставки сообщения K_{MAC,C}^{write} ;
• ключом клиента для проверки имитовставки сообщения K_{MAC,C}^{read} ;
• ключом сервера для вычисления имитовставки сообщения K_{MAC,S}^{write} ;
• ключом сервера для проверки имитовставки сообщения K_{MAC,S}^{read} ;
• ключом клиента для зашифрования данных K_{ENC,C}^{write} ;
• ключом клиента для расшифрования данных K_{ENC,C}^{read} ;
• ключом сервера для зашифрования данных K_{ENC,S}^{write} ;
• ключом сервера для расшифрования данных K_{ENC,S}^{read} ;
• вектором инициализации клиента для зашифрования данных IV_{C}^{write} ;
• вектором инициализации клиента для расшифрования данных IV_{C}^{read} ;
• вектором инициализации сервера для зашифрования данных IV_{S}^{write} ;
• вектором инициализации сервера для расшифрования данных IV_{S}^{read} .

Примечания

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

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

5 Протокол Record

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

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

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

В настоящем разделе все действия будут описаны для одной фиксированной стороны взаимодействия (клиента или сервера), которая обладает ключом шифрования K_{ENC}^{write} , ключом вычисления имитовставки сообщения K_{MAC}^{write} , вектором инициализации IVwrite для формирования записей и ключом расшифрования K_{ENC}^{read} , ключом проверки имитовставки сообщения K_{MAC}^{read} , вектором инициализации IVread для чтения записей.

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 не должно превышать 214 (то есть размер поля TLSPlaintext.fragment не должен превышать 16 Кбайт).

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

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

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

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

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

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 Имитовставка сообщения

В настоящем подпункте предполагается, что ключ KMAC соответствует ключу K_{MAC}^{write} для состояния записи и ключу K_{MAC}^{read} для состояния чтения.

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

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

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

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

MACData = STR8(seqnum) |Rec.type|Rec.version|Rec.length|Rec.fragment. (3)

5.2.3.2 Шифрование

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

В настоящем подпункте предполагается, что ключ KENC соответствует ключу K_{ENC}^{write} для состояния записи и ключу K_{ENC}^{read} для состояния чтения, вектор инициализации IV — вектору инициализации IVwrite для состояния записи и вектору инициализации IVread для состояния чтения.

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

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

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

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

ENCData = Rec.fragment|RecMAC. (5)

6 Протокол Handshake

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

Протокол 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
Выработка случайного значения rC
		Выработка случайного значения rS
Этап выработки общего секрета
Выработка общего секрета PS (выбирается случайно из B32)
Формирование эфемерного ключа на кривой, соответствующей QS: QEPH = kEPHP, где kEPH выбирается случайно из Z_{q}^{*}
H = HASH(rC|rS); K_{MAC}^{Exp}|K_{ENC}^{Exp} = KEG(k_{EPH},Q_{S},H)
Формирование экспортного представления общего секрета PS: IV = H[25..24 + n/2]; PSExp = KExp15(PS,K_{MAC}^{Exp},K_{ENC}^{Exp},IV)		H = HASH(rC|rS); K_{MAC}^{Exp}|K_{ENC}^{Exp} = KEG(k_{S},Q_{EPH},H)
		Извлечение общего секрета из экспортного представления: IV = H[25..24 + n/2]; PS = Klmp15(PSExp,K_{MAC}^{Exp},K_{ENC}^{Exp},IV)
sgnC = SIGN(kC, HM1)		Проверка sgnC
Этап выработки ключей из значения PS
Выработка общего сессионного секретного значения: MS = PRF(PS, «extended master secret», HASH(HM1))		Выработка общего сессионного секретного значения: MS = PRF(PS, «extended master secret», HASH(HM1))
Генерация ключевого материала соединения:
Генерация ключевого материала соединения:		Этап подтверждения ключа
	client_verify_data = PRF(MS, «client finished», HASH(HM2))
server_verify_data = PRF(MS, «server finished», HASH(HM3))		Примечания

1 Переменные HM1, HM2 и HM3 заданы в соответствии с 6.2.1.

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

Таблица 2

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

Формирование параметров и действия со стороны клиента C	Передаваемые сообщения	Формирование параметров и действия со стороны сервера S
Выработка случайного значения rC
		Выработка случайного значения rS
Этап выработки ключей из значения MS
Генерация ключевого материала соединения:		Генерация ключевого материала соединения:
Этап подтверждения ключа
		server_verify_data = PRF(MS, «server finished», HASH(HM3))
client_verify_data = PRF(MS, «client finished», HASH(HM2))

Примечание — Переменные HM2 и HM3 заданы в соответствии с 6.2.1.

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

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

6.2.1 Задание переменных HM1, HM2, HM3

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

Таблица 3

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

Примечания

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, не включаются в переменные HM1, HM2 и HM3.

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

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

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

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

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

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

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

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

• клиент впервые подключается к серверу;
• как ответ на сообщение запроса приветствия HelloRequest;
• с целью пересогласования параметров сессии.

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

Сообщение 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 при условии, что среди параметров, переданных клиентом в сообщении приветствия, присутствует поддерживаемый сервером набор параметров установления соединения.

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

Сообщение 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

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

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

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

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 и эфемерный ключ QEPH.

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

• вырабатывает секретное значение PS, выбирая его случайно из множества B32;
• выбирает случайное значение kEPH из множества {1,...,q-1};
• формирует эфемерный ключ QEPH = kEPH·P;
• с помощью алгоритма KEG, описанного в 6.4.5.1, формирует ключи экспорта K_{MAC}^{Exp} и K_{ENC}^{Exp} следующим образом:

(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) и содержит информацию о параметре QEPH, а поле ukm должно быть проигнорировано сервером.

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

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

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

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

3 q·QEPH = 0;

• формирует ключи экспорта K_{MAC}^{Exp} и K_{ENC}^{Exp} :

(8)

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

(9)

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

Алгоритм выработки ключей экспорта KEG принимает на вход закрытый ключ d, открытый ключ Q и строку h \in B_{32} . Результатом работы данного алгоритма является строка длины 64 байта или сообщение об ошибке.

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

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

KEG(d, Q, h) = VKO512(d, Q, UKM), (10)

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

(11)

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

KEG(d, Q, h) = KDFTREE256(KEXP, «kdf tree», seed, 1), (12)

где в качестве функции KDFTREE256 использован алгоритм диверсификации KDF_TREE_GOSTR3411_2012_256, определенный в Р 50.1.113-2016 (4.5), результатом работы которого является строка K(1)|K(2) \in B_{64} , а параметры KEXP и seed заданы следующим образом:

(13)

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

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

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

sgnC = SIGN(kC, HM1), (14)

где:

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

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

struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } CertificateVerify;

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

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

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

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

MS = LMB48(PRF(PS, «extended master secret»,

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

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

(16)

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

(17)

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

client_verify_data = = LMB32(PRF(MS, «client finished», HASH(HM2))), (18)

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

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

server_verify_data = = LMB32(PRF(MS, «server finished», HASH(HM3))), (19)

где параметр HM3 задан в соответствии с 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

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

Таблица 5

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

Таблица 6

Общие оповещения об ошибке, которые могут возникать в процессе работы протокола TLS 1.2 в соответствии с криптонаборами, описанными в настоящих рекомендациях

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 1.2 и задающий криптографические параметры в соответствии с 10.1.1 - 10.1.5.

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

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

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

Таблица 8

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

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

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

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

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

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

- K \in B_{k} , ключ вычисления имитовставки;

- P \in B_{t} , t >= 0, открытый текст.

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

- T, где T \in B_{n} — имитовставка.

Функция 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 задана нижеприведенным образом.

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

- K \in B_{k} , ключ шифрования;

- IV \in B_{n/2} , уникальный вектор;

- P \in B_{t} , t >= 0, открытый текст.

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

- C, где C \in B_{|P|} — шифртекст.

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

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

где

(23)

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

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

- Ksegnum — начальный ключ;

- IVseqnum — уникальный вектор;

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

Таблица 9

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

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

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

В настоящем разделе описывается алгоритм TLSTREE, используемый для порождения ключей защиты записей из корневого ключа K_{root} \in B_{32} .

TLSTREE(Kroot, i) = Divers3(Divers2(Divers1(Kroot, STR8(i&C1)), STR8(i&C2)), STR8(i&C3)), (24)

где

- число i \in {0,1,...,2^{64} - 1} ;

- Divers_{j}(K,D),j \in {1,2,3} — алгоритм диверсификации ключа K \in B_{32} по данным диверсификации D \in B_{8} , который задан с помощью функции KDF256, определяемой алгоритмом KDF_GOSTR3411_2012_256, описанным в Р 50.1.113-2016 (4.4):

(25)

- константы C_{1},C_{2},C_{3} \in {0,1,...,2^{64} - 1} определены используемым криптонабором в соответствии с таблицей 10.

Таблица 10

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

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

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

Таблица 11

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

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 < kC < qC — ключ подписи клиента, где qC — порядок подгруппы группы точек эллиптической кривой, соответствующей ключу проверки подписи QC;

- M \in B^{*} — произвольная байтовая строка.

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

- sgn_{C} \in B_{2l} , где l \in {32,64} .

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

(26)

где:

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

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

Примечание — В формуле (26) значение подписи sgnC представляется в виде конкатенации двух строк, являющихся байтовыми представлениями чисел 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 обращение к функции Diversj, j \in {1,2,3} , необходимо проводить только в тех случаях, когда номер записи seqnum достигает такого значения, что seqrum\&C_{j} \neq (seqnum - 1)\&C_{j} ; в противном случае необходимо применять значение, выработанное ранее. Данный подход позволяет также противодействовать атакам по побочным каналам.

Приложение А (справочное)

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

А.1 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC

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

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-го уровня, являющийся результатом работы функции Divers1:

F3 55 89 F₀ 9B F8 01 B₁ CA 11 42 73 B₉ 5F D6 C1

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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

53 CB BB FD 03 12 82 B₀ 26 21 4A B₂ E0 77 58 FF.

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

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

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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;

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

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

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;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

17 B₀ 3E 09 76 BB 28 EA 98 24 C3 B₇ 0F 28 CB D8;

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

6C C2 8E B₀ 93 24 72 12 5C 7A D3 F8 09 73 B₃ C8

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

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

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

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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 B₉ 3F 20 7B B₄;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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

6D 33 B₆ 0F 74 65 DD 42 B₅ 11 2C F3 A6 B₁ AB 66;

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

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-го уровня, являющийся результатом работы функции Divers1:

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

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

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

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

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

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

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-го уровня, являющийся результатом работы функции Divers1:

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-го уровня, являющийся результатом работы функции Divers2:

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;

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

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 стороной взаимодействия выработаны следующие параметры:

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

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;

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

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.

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

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

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

000000: 19 A7 6E D3 ₀F 4D ₆D 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.

Ключ K_{ENC}^{0} зашифрования для записи с номером 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 B₃ CC 74 46 B₃ 63 57 71 13 F0 FB 56.

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

000000: 00 00 00 00.

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

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

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

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

Защищенная запись PRec0, представленная в виде структуры 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.

Незащищенная запись Rec4095, представленная в виде структуры 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.

Ключ K_{MAC}^{4095} вычисления имитовставки для записи с номером seqnum = 4095 равен ключу K_{MAC}^{0} :

000000: 19 A7 6E D3 0F 4D ₆D 1F ₅B 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.

Ключ K_{ENC}^{4095} зашифрования для записи с номером seqnum = 4095 равен ключу K_{ENC}^{0} :

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

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

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

000000: 00 00 0F FF.

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

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

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

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

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

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.

Защищенная запись PRec4095, представленная в виде структуры 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 B₈ B₁ 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.

Незащищенная запись Rec4096, представленная в виде структуры 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.

Ключ K_{MAC}^{4096} вычисления имитовставки для записи с номером 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 B₀ 26 21 4A B₂ E0 77 58 FF.

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

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

Ключ K_{ENC}^{4096} зашифрования для записи с номером 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.

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

000000: 00 00 10 00.

Данные ENCData разбиты на три секции, зашифрование проведено на трех секционных ключах K1, K2 и K3.

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

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.

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

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.

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

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.

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

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

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

000020: FB B₇ A8 94 80 62 08 8A F3 2C AE B₆ 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 сообщений, при этом значения контрольных примеров приведены для трех из них, демонстрирующих наиболее важные особенности работы протокола.

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

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

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;

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

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.

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

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

000010: 00 00 00 00.

Ключ K_{MAC}^{0} вычисления имитовставки для записи с номером 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.

Ключ K_{ENC}^{0} зашифрования для записи с номером 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 B₃ CC 74 46 B₃ 63 57 71 13 F0 FB 56.

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

000000: 00 00 00 00 00 00 00 00.

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

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

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

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

Защищенная запись PRec0, представленная в виде структуры 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.

Незащищенная запись Rec63, представленная в виде структуры 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.

Ключ K_{MAC}^{63} вычисления имитовставки для записи с номером seqnum = 63 равен ключу K_{MAC}^{0} :

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.

Ключ K_{ENC}^{63} зашифрования для записи с номером seqnum = 63 равен ключу K_{ENC}^{0} :

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

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

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

000000: 00 00 00 00 00 00 00 3F.

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

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

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

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

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

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.

Защищенная запись PRec63, представленная в виде структуры 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 B₆ E2 C6 1F A4 06 D9 B₈ 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.

Незащищенная запись Rec64, представленная в виде структуры 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.

Ключ K_{MAC}^{64} вычисления имитовставки для записи с номером 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.

Ключ K_{ENC}^{64} зашифрования для записи с номером 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.

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

000000: 00 00 00 00 00 00 00 40.

Данные ENCData разбиты на три секции, зашифрование проведено на трех секционных ключах K1, K2 и K3.

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

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.

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

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.

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

000000: CE 33 35 AB 82 0F 2C 20 88 96 C9 81 51 34 35 47

000010: A3 63 FA 9B B₁ 7D B₀ 23 3E 1F 7D CB 5C 82 65 B₉.

Защищенная запись PRec64, представленная в виде структуры 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».

Открытый ключ сервера QS:

x = 0xC03ED6E3604CCB026E_56E91272454707 94E0508A1FE1602371F443DC20E313FD;

y = 0_x994D579491A2DBB720E78E0AFAC8479C 8D1A852989A4_6D496_9C799E39A1025EC.

Закрытый ключ сервера kS:

0x0880FD1E94C7656CA143A310553A04B5

5583E16ABF56D91336AB271B7396E0E4.

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