ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

РЕКОМЕНДАЦИИ Р 1323565.1.020—

ПО СТАНДАРТИЗАЦИИ 2018

Информационная технология

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

Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Издание официальное

Москва

Стандартмнформ

2018

Предисловие

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

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

3    УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 августа 2018 г. № 511-ст

4    ВВЕДЕНЫ ВПЕРВЫЕ

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

©Стандартинформ. оформление. 2018

Настоящие рекомендации не могут быть полностью или частично воспроизведены, тиражированы и распространены в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии II

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

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

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

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

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

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

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

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

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

Записи состоят из заголовка, описывающего передаваемые данные, и самого фрагмента данных. Каждая запись передается в открытом (TLSPIaintext-структура) или защищенном (TLSCiphertext-структура) виде в зависимости от текущего состояния соединения. В каждом из двух случаев заголовок передается в открытом виде, имеет длину 5 байт и состоит из следующих полей: fype — тип сообщения (1 байт). Всего определено четыре типа сообщений: сообщения протокола Change Cipher Spec (тип 20). сообщения протокола Alert (тип 21). сообщения протокола Handshake (тип 22). сообщения протокола Application Data (тип 23);

version — версия протокола (2 байта). Данный параметр содержит внутренний идентификатор версии протокола TLS. Внутренний идентификатор версии протокола TLS 1.2. описанного в настоящих рекомендациях, равен (3. 3); length — длина фрагмента данных в байтах (2 байта). Данный параметр определяет количество байтов, передаваемых в записи после ее заголовка. Значения полей TLSPIaintext.length и TLSCiphertext.length должны удовлетворять ограничениям, определенным в 5.2.1.

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

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

TLSPIaintext Rec;

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

TLSCiphertext PRec;

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

PRec fragment = RecENC,    (1)

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

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

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

TLSTREE{K_rool.i) = Divers₃ [Divers₂ (D/vers,(K_f00l.STR_e (/& C,)),STR_Q (i & C₂)).S7R₈ (/ & C₃)).    (2)

где

-    число / e [0Л ...2⁶⁴ -ij;

-    константы C_v C₂, C₃ e определяются конкретным криптонабором;

-    DiverSj(K.D), ye{1,2.3} —алгоритм диверсификации ключа КеВ₃₂ по данным диверсификации D е Bq. который задается с помощью функции KDF_25&, определяемой алгоритмом KDF_GOSTR3411_2012_256. описанным в Р 50.1.113—2016 (подраздел 4.4):

Divers^ (K.D) = KDF₂₅₆ (KrtevelV.D)-,

Divers₂ {K.D) = KDF₂₅₆ (K.'/ei/e/2".D);    (3)

Dh/ers₃(K,D) = KDF₂₅₆ (K."/eve/3",D).

5.2.3.2    Код аутентификации сообщения

В настоящем разделе предполагается, что ключ К_шс соответствует ключу K'fijfc для состояния записи и ключу KfijfiL для состояния чтения.

Для записи Rec с номером seqnum код аутентификации вычисляется от следующих данных:

MACData = STR_e (seqnum) \ Reclype \ Rec.version | Rec length \ Rec.fragment.    (4)

Значение ключа Кмд£^ит. соответствующего конкретному номеру seqnum, получается из ключа ^кмас ^с помощью алгоритма TLSTREE. описанного в 5.2.3.1. в соответствии с формулой

^кшс^ит = TLSTREEiK^.seqnum).    (5)

Параметры алгоритма вычисления кода аутентификации сообщения MAC определяются согласованными криптонаборами в соответствии с 10.3.

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

RecMAC = МАС[К%$£^ит .MACData).    (6)

5.2.3.3 Шифрование

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

В настоящем разделе предполагается, что ключ K_ENC соответствует ключу для состояния записи и ключу Kgjg для состояния чтения. Также полагаем, что вектор инициализации IV соответствует вектору инициализации IV^wnte для состояния записи и вектору инициализации iv^mad для состояния чтения.

Для записи Rec с номером seqnum зашифровываются следующие данные:

ENCData = Recfragment \ RecMAC.    (7)

Значение ключа К^£^ит, соответствующее конкретному номеру записи seqnum, получается из ключа K_ENC с помощью алгоритма TLSTREE, описанного в 5.2.3.1, в соответствии с формулой

К*$^ит = TLSTREE (K_ENC, seqnum).    (8)

Значение вектора инициализации IV_soqnum. соответствующее конкретному номеру записи seqnum, определяется следующим образом

= STR„,₂((/Nr(yV)_+Se₄n_Um)mod2»«'2).    (9)

Параметры алгоритма шифрования ENC определяются согласованным криптонабором. Значение RecENC вычисляется в соответствии с формулой

RecENC = ENC(K^.IV_safmn,ENCData).    (10)

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

6 Протокол Handshake

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

идентификатор сессии — произвольная последовательность байтов, выработанная сервером для идентификации активной или возобновляемой сессии; сертификат стороны — сертификат в формате Х.509. формирующийся в соответствии с (2). Аутентификация опционально может быть односторонней (аутентификация сервера клиентом, сертификат предоставляет только сервер) или взаимной (взаимная аутентификация сервера и клиента, клиент и сервер обмениваются сертификатами);

—    идентификатор, определяющий набор алгоритмов и их параметров, использующихся в рамках данной сессии:

—    общее секретное значение длиной 48 байт, которое вырабатывается сторонами с помощью протокола выработки и подтверждения ключа (см. 6.4);

—    флаг, разрешающий/запрещающий повторные соединения в рамках данной сессии.

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

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

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

Client

ClientHello

ServerHello

Certificate

{CertificateRequest}

*    ServerHelloDone

{Certificate}

ClientKeyExchange

{CertificateVerify)

ChangeCIpherSpec

Finished    *

ChangeCipherSpec

*    Finished

Application Data    *    *    Application    Data

Рисунок 3 — Полная схема обмена сообщениями в протоколе Handshake

Примечание 1 — Фигурными скобками отмечены те сообщения, которые являются опциональными

Примечание 2 — Сообщение ChangeCipherSpec формально относится не к протоколу Handshake, а к протоколу Change Cipher Spec

Примечание 3 — В соответствии с (1) протокол TLS 1 2 допускает возможность установления анонимного соединения без обмена сертификатами, однако в протоколе, соответствующем криптонаборам, описанным в данных рекомендациях, данная опция использоваться не должна

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

Client    Server

ClientHello    »

ServerHello ChangeCipherSpec *    Finished

ChangeCi pherSpec

Finished     —

Application Data    —---------♦    Application    Data

Рисунок 4 — Упрощенная схема обмена сообщениями в протоколе Handshake

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

6.1 Схема взаимодействия сторон

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

Таблица 611 —Схема взаимодействия сторон в протоколе Handshake

Формирование параметров и действия со стороны клиента С Передаваемые сообщения Формирование параметров и действия со стороны сервера S Выработка случайного значения гс ClientHello гс

Продолжение таблицы 6 11

Формирование параметров и действия со стороны клиента С Передаваемые сообщения Формирование параметров и действия со стороны сервера S ServerHello rJ Выработка случайного значения rs Этап выработки общего секрета Certificate Certs (содержит ключ Q$ CortiflcatoRoquost ServerHelloDone Certificate Certc (содержит ключ Qc) Выработка общего секрета PS, (выбирается случайно из Вз2) Формирование эфемерного ключа на кривой, соответствующей Qs: ®ЕРН - кЕРНР- где кЕРН выбирается случайно из Z* H = HASH(rc\rs)-К%с\«1& = К^(кЕРН°8Н) Формирование экспортного представления общего секрета PS IV = Н[25..24 + л/2); PSExp = KExpl 5 (PS. Kf$c. к|*£ .IV) ClientKeyEx change Qeph- PSExp H=HASH{rc\rs); KMAc\KENC ~ KEG\ks.QEpH.H) Извлечение общего секрета из экспортного представления IV = Н[25..24 +л/2|. PS = Klmpl 5 (PSExp. К^с. K%fe.iv) sgnc = SIGNkc (HM) CertificateVerify «"c Проверка sgnc Этап выработки ключей из значения PS Выработка общего сессионного секретного значения MS = PRF (PS. ” extended master secret'. HASH(HM))', Выработка общего сессионного секретного значения: MS - PRF (PS.' extended master secret', HASH(HM))\ Генерация ключевого материала соединения: K®.ctec|«.c = PRF {MS.M key expansion Vs \rc) Генерация ключевого материала соединения: «xsSs - PRF (MS." key expansion ",rs |rc)

Скончание таблицы 6 11

Формирование параметров и действия со стороны клиента С Передаваемые сообщения Формирование параметров и действия со стороны сервера S Этап подтверждения ключа ChangeCipherSpec client _ verify _ data = Finished PRF {MS' client finished ~.HASH{HM)); client_\tnfy_daia ChangeCipherSpec Finished server _ verify _ data = server_ verify_data PRF {MS. ’ sorvor finished '.HASH |HM)).

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

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

епшп {

hello_request(0), client_hello(1), server_hello<2), cert ificate(11), certificate_request(13), server hello done(14), certificate. verify(15), client_key .exchange(16), finished(20), (255)

) HandshakeType;

struct {

HandshakeType msg_type;    /*

uint24 length;    /*

select (HandshakeType) { case hello_request: case client_hello: case servcr„hello: case certificate: case cert ificate_request: case server_hello_done: case certificate_veri fy : case client_key_exchange: case finished:

) body;

) Handshake;

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

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

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

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

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

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

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

Данное сообщение не должно входить в переменную НМ.

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

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

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

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

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

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

—    максимальная версия протокола из тех. которые готов поддерживать клиент [настоящие рекомендации описывают криптонаборы для протокола TLS 1.2. для которого значение версии равняется (3. 3));

—    строка данных длины 32 байта, выработанная клиентом, в которой первые 4 байта занимает значение текущего времени в 32-битном формате UNIX [количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года), а остальные 28 байт занимает строка, выработанная случайным образом;

—    идентификатор сессии, выбранный клиентом. Если данное поле пусто, значит клиент хочет согласовать параметры новой сессии;

—    список криптонаборов, которые поддерживает клиент. Порядок криптонаборов в списке отражает их степень предпочтения (предпочтительные идут первыми). Если поле ClientHello.sessionjd не пустое, поле ClientHello.cipher_suites должно содержать идентификатор криптонабора, согласованного во время установления параметров сессии, имеющей идентификатор ClientHello. sessionjd;

список методов сжатия —данная версия протокола не поддерживает методы сжатия, и поле должно содержать один метод с идентификатором null (0);

—    криптонаборы, описанные в настоящем документе, предполагают наличие трех обязательных расширений со стороны клиента: signature_algorithms, extended_master_secret и renegotiationjnfo.

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

struct {

FrotocolVersion client version;

Random random;

SessionID session_id;

CipherSuite c ipher_suites<2..2^Л16 2>;

CompressionMethod compression_met.hods<l . .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];

строка данных длины 32 байта, выработанная сервером, в которой первые 4 байта занимает значение текущего времени в 32-битном формате UNIX [количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года], а остальные 28 байт занимает строка, выработанная случайным образом;

идентификатор сессии, в рамках которой осуществляется соединение. Если поле ClientHello.sessionJd не было пустым, тогда в кэше сессий сервер ищет параметры сессии, соответствующей данному идентификатору. В случае если такая сессия существует и сервер готов создать соединение в рамках данной сессии, он присваивает то же значение идентификатора сессии полю ServerHello.sessionJd. Если поле ClientHello.sessionJd было пустым либо если сервер не нашел параметры сессии, соответствующей данному идентификатору, сервер задает новое значение идентификатора, указывающего на создаваемую сессию. Сервер может послать пустое значение идентификатора, это будет означать, что параметры данной сессии не будут храниться в кэше сервера и повторное создание соединения в рамках данной сессии будет невозможно;

криптонабор, который сервер выбирает из списка ClientHello.cipher_surtes. Если значение ClientHello.sessionJd не нулевое, данный параметр должен содержать идентификатор криптонабора, согласованного в сессии ClientHello.sessionJd;

данная версия протокола не поддерживает методы сжатия, и поле должно (compression_method) содержать один метод с идентификатором null (0);

расширения    —    криптонаборы, описанные в настоящем документе, предполагают наличие

(extensions)    двух обязательных расширений со стороны сервера: extended_master_secret

и renegotiationjnfo.

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

struct {

ProtocolVers ion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

Compress ionMethod compress ion jnethod;

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

) ServerHello;

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

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

struct {

F.xtens ionType extens ion_type; opaque extension_data<0..2^A16-1>;

) Extension; enum {

signature_algoriLhms(13), extended_master_secret(23), renegotiation info(65281),(65535)

) ExtensionType;

6.3.4.1 Расширение signature_a)gorithms

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

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

Signatu reAndHashA 1 gor i t. hm

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

struct {

HashAlgorithm hash;

SiynaturcAlgorittun signature;

} Signatu reAndHashA Igor i thin;

Множество поддерживаемых алгоритмов хэширования задается следующим образом:

enum {

gostr34112012_256(238), gostr34112012_512(239), (255)

} HashAlgorithm;

При этом значения gostr34112012_256 и gostг34112012_512 соответствуют алгоритму хэширования. определенному в ГОСТ Р 34.11-2012. с длиной выхода 256 и 512 бит соответственно.

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

enum {

gostr34102012_256(238), gostr34102012_512(239), (255)

) SignatureAlgorithm;

При этом значения gostr34102012_256 и gostr34102012_512 соответствуют алгоритму подписи, определенному в ГОСТ Р 34.10-2012, с длиной ключа 256 и 512 бит соответственно.

В протоколе, соответствующем криптонаборам, описанным в данных рекомендациях, допускается использование следующих пар алгоритмов подписи и хэширования: (gostr34112012_256. gostr34102012_256) и (gostr34112012_512. gostr34102012_512).

Примечание — В рамках протокола, соответствующего криптонаборам, описанным в данных рекомендациях, указание поддерживаемого алгоритма хэширования является избыточным и используется для обеспечения совместимости с форматом расширения signature_algorrthms. описанным в [1]

6.3.4 2 Расширение extended_master_secret

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

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

Примечание — Описание расширения extended_master_secret соответствует (З).

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

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

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

struct {

opaque renegotiated_.connection<0. .2S5>;

} Renegotiationlnfo;

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

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

Примечание — Описание расширения renegotiationjnfo соответствует [4]

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

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

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

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

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

opaque ASN. ICertcl. .2^Л24-Instruct {

ASN.lCert cert ificato_list<0..2^A24-1>; ) Certificate;

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

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

—    настоящие рекомендации определяют два типа сертификатов: gostr34102012_256, gostr34102012_512. Данные типы указывают на то. что сервер принимает сертификаты клиента с ключами проверки подписи, соответствующими алгоритму ГОСТ Р 34.10-2012 с длиной ключа 256 и 512 бит соответственно;

—    пары алгоритмов подписи и хэширования, указывающие на то. с помощью каких алгоритмов могут быть подписаны сертификаты из цепочки сертификатов клиента. Ключ проверки подписи, хранящийся в сертификате клиента. должен также соответствовать одному из алгоритмов подписи (не обязательно тому же. которым подписан сертификат), перечисленных в поле support ed_signature_algorithms;

—    список допустимых удостоверяющих центров (УЦ). представленных в формате кодирования DER. Данный список может задавать допустимые имена для корневых УЦ или для подчиненных УЦ. Если данное поле остается пустым. то клиент может посылать любой сертификат, соответствующий полю certificatejypes.

Содержание

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

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

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

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

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

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

5    Протокол Record.....................................................................5

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

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

6    Протокол Handshake..................................................................9

6.1    Схема взаимодействия сторон.....................................................10

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

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

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

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

8    Протокол Alert.......................................................................20

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

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

9    Протокол Application Data.............................................................23

10    Криптонаборы.....................................................................23

10.1    Сертификаты сторон............................................................24

10.2    Блочный шифр.................................................................24

10.3    Алгоритм выработки кода аутентификации сообщения................................24

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

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

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

11    Вопросы безопасности..............................................................25

Приложение А (справочное) Контрольные примеры работы алгоритма TLSTREE................26

А.1 TLS_G OSTR341112_256_ W1Т H_MAG МА_С TR_0 MAC..................................26

A. 2 TLS_GOSTR341112_256_WlTH_KUZNYECHIK_CTR_OMAC.............................27

Приложение Б (справочное) Контрольные примеры для работы протокола Record...............30

Б.1 TLS_GOSTR341112_256_WlTH_MAGMA_CTR_OMAC..................................30

Б.2 TLS_GOSTR341112_256_WtTH_KUZNYECHIK_CTR_OMAC.............................32

Приложение В (справочное) Контрольные примеры для работы протокола TLS..................36

B. 1 TLS_GOSTR341112_256_W1TH_MAGMA_CTR_0MAC..................................36

В.2 TLS_GOSTR341112_256_WlTH_KUZNYECHIK_CTR_OMAC.............................47

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

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

struct {

ClientCerti £icateType certi f icate_types<l..2^Л8-1>; SignatureAndHashAlgorithm

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

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

) CertificateRequest;

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

епшп {

gostr34102012_256(238), gostr34102012_512(239), (255)

} ClientCertificateType;

Структура SignatureAndHashAlgorithm задается в 6.3.4.1.

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

opaque DistinguishedNamecl..2^Л16-1>;

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

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

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

struct { ) ServerHelloDone;

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

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

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

Ключ проверки подписи в сертификате клиента должен соответствовать алгоритму подписи, указанному в расширении CertificateRequest.certificatejypes.

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

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

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

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

-    выбирает случайное значение к_ЕРН из множества Z‘_q\

-    формирует эфемерный ключ Q_EPH = к_ЕРН Р,

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

Н =

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

IV = HI25..24 +л/2|;

(12)

PSExp = КЕхрЛ 5 (PS, К^_с. К** . /V).

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

enum { vko_kdf_gost ) KeyExchangeAlgorithm; struct (

select (KeyExchangeAlgorithm) {

Введение

Настоящие рекомендации содержат описание протокола безопасности транспортного уровня версии 1.2 (TLS 1.2). с криптонаборами на основе алгоритмов блочного шифрования «Магма» и «Кузнечик». описанных в ГОСТ Р 34.12-2015.

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

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

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

Информационная технология

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

Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Information technology Cryptographic data security The use of the russian cryptographic algorithms in the transport layer security protocol (TLS 12)

Дата введения — 2019—02—01

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

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

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

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

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

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

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

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

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

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

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

Примечание — При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год Если заменен

Издание официальное

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

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

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

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

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

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

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

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

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

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

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

B_s    — множество байтовых строк длины s. s>0. Строка /> = (6, b_s) принадлежит

множеству В_$, если Ь,.....b_s е {0.....255}. При s = 0 множество B_s состоит из

единственной пустой строки длины 0.

—    конкатенация двух байтовых строк: для двух строк з = (з,.....a_sy)eB_sV

^{b =     b}s2)    е    B_s2    их конкатенацией а | b называется строка

^с ~ (^а1 ^asV^b1 ^bs2)^eBsUs2’

—    строка b\Lj\ = (b_itb_M.....Ь_у)е8_у__/+1. где 1 ZiZjZs и b = (b,.....b_s)eB_s;

—    число INT(b) = 256^s’¹ -b^ + ••• + 256 b_s_^ + b_g, где b = (b_t.....b_s)eB_s;

—    строка STR_s(r) = (b^.....b_s)e8_s> соответствующая числу г = 256^s'¹ b₁+- +

4 256 b_s-1 + b₅ £ 256^s -1;

—    строка str_s(r) = (b_s.....b,)eB_s. соответствующая числу г = 256^s'¹ •b₁+ —+

+ 256 Ь_5И + b, £ 256^s -1;

— строка LMB_t(b) = (b, b_t)eB_t, соответствующая строке b = (b, b_s)e8_s,

151 < s.

n    — параметр алгоритма блочного шифрования, называемый длиной блока: в рам

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

ках данного документа измеряется в байтах;

ENC(K.IV.M) —алгоритм шифрования сообщения Мна ключе К с помощью вектора инициализации IV. который задается выбранным криптонабором;

МАС(К.М) —алгоритм вычисления кода аутентификации сообщения М на ключе К. который задается выбранным криптонабором;

—    порядок подгруппы группы точек элпиптической кривой, соответствующей открытому ключу сервера:

—    точка эллиптической кривой порядка q. соответствующей открытому ключу сервера;

—    нулевая точка эллиптической кривой;

—    ключ проверки подписи, хранящийся в сертификате клиента;

—    ключ подписи клиента, соответствующий ключу О_с;

—    открытый ключ сервера;

—    закрытый ключ сервера;

—    байтовая строка со случайными данными, соответствующая полю ClientHello.random, описанному в 6.3.2;

—    байтовая строка со случайными данными, соответствующая полю ServerHello. random, описанному в 6.3.3;

—    алгоритм подписи на ключе К. описанный в 6.4.6;

—    хэш-функция ГОСТ Р 34.11-2012 с длиной выхода 32 байта (256 бит);

—    алгоритм генерации ключей экспорта, описанный в 6 4 5.1;

—    псевдослучайная функция PRF_TLS_GOSTR3411_2012_256. описанная в Р 50.1.113—2016;

—    алгоритм экспорта ключей, описанный в Р 1323565.1.017—2018. использующий блочных шифр, задающийся выбранным криптонабором;

—    алгоритм импорта ключей, описанный в Р 1323565.1.017—2018. использующий блочных шифр, задающийся выбранным криптонабором;

—    операция побитовой конъюнкции (побитовое «И»);

—    переменная, хранящая конкатенацию всех пересланных и полученных сообщений протокола Handshake, начиная с сообщения приветствия ClientHello и заканчивая сообщением (но не включая его), при формировании которого эта переменная используется; при этом сообщение запроса приветствия HelloRequest. сообщения протокола Change Cipher Spec и сообщения протокола Alert не включаются в переменную НМ.

Примечание 1 — Для описания протокола в настоящих рекомендациях используется общепринятый язык представления (далее — язык представления TLS). описанный в (1)

Примечание 2 — В настоящих рекомендациях все строковые константы приводятся в кавычках и представляются в кодировке ASCII.

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

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

Примечание 5 — В настоящих рекомендациях используются обозначения параметров эллиптических кривых в соответствии с ГОСТ Р 34 10—2012 (раздел 5).

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_s, задаваемая сервером;

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

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

-    ключ сервера для вычисления кода аутентификации сообщения K^acS'

-    ключ сервера для проверки кода аутентификации сообщения К^г$$.₅\

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

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

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

-    ключ сервера для расшифрования данных K^r$j£_s\

-    вектор инициализации клиента для зашифрования данных /у*⁷*®;

-    вектор инициализации клиента для расшифрования данных IVg³¹"*:

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

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

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

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

5 Протокол Record

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

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

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

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

циализации iv^road для чтения записей.

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, переводится в TLSPIaintext-структуру. которая задается следующим образом:

struct {

ContentType type;

ProtocolVersion version ■ {3, 3); /*TLS vl.2 */ uint.16 length;

opaque fragment ITLSPlaintext.length];

} TLSPlaintext;

enum {

change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255)

) ContenLType;

struct {

uint8 major; uint8 minor;

) ProtocolVers ion

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

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

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

struct {

ContentType type;

ProtocolVers ion version = (3, 3); /*TLS vl.2 */ uintl6 length;

opaque fragment(TLSCiphertext.length 1;

) TLSCiphertext;

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

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

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

2)    вычисление кода аутентификации в соответствии с 5.2.3.2 от конкатенации номера записи, заголовка незащищенной записи и данных незащищенной записи:

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

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