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

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

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

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

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

Москва

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

2020

Предисловие

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

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

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

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

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

© ISO. 2014 — Все права сохраняются © Стандартинформ, оформление. 2020

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

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

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

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

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

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

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

-    ключевой материал трафика: [sender\_\mte_key, [sender[_write_iv (см 8.4).

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

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

-    этап ключевого обмена: сообщения ClientHello. HelloRetryRequest. ServerHello протокола Handshake (см. 5.5), всегда пересылаемые сторонами в открытом виде;

-    этап выработки параметров соединения и аутентификации: все сообщения протокола Handshake, начиная с сообщения EncryptedExtensions и заканчивая сообщением Finished со стороны клиента, всегда передаются в защищенном виде с помощью ключей, выработанных на основе секретного значения [sender]_handshake_traffic_secret (см. 8.2):

-    этап пересылки прикладных данных (см. раздел 9) и post-handshake сообщений (см. 5.9): все данные, посылаемые в рамках этого этапа, передаются в защищенном виде. Для их защиты используются ключи, выработанные на основе секретного значения [sender\_application_traff}c_secret_N(см. 8.2).

Примечания

1    Прикладные данные, пересылаемые в защищенном на ключах [sender\_apphcation_traffic_secret_N виде, могут быть посланы сервером до получения сообщения Finished со стороны клиента в случае односторонней аутентификации (см подробнее раздел 9).

2    В рамках этапа пересылки прикладных данных может проходить смена состояния соединения путем смены ключевого материала трафика с помощью механизма сообщений KeyUpdate (см 5 9 3)

5 Протокол Handshake

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

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

TLSCiphertext структур (см. раздел 6). которые обрабатываются и передаются в канале связи в соответствии с текущим состоянием соединения (см. 4.2).

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

enum {

cJient_hello(0x01).

server_hello(0x02).

new_session_ticket(0x04),

end_of_ear1y_data(0x05),

encrypted_extensions(0x08),

certificate(OxOB),

certificate_request(OxOD),

certificate_verify(OxOF),

fmished(0x14),

key_update(0x18),

message_hash(OxFE),

(OxFF)

} HandshakeType;

struct {

HandshakeType msgjype; f handshake type */ uint24 length; Г remaining bytes in message •/ select (Handshake.msgjype) {

case clientjiello:	ClientHello:
case serverjiello:	ServerHello;
case end_of_early_data:	EndOfEarlyData;
case encrypted_extensions:	EncryptedExtensions;
case certificatejequest:	CertificateRequest;
case certificate:	Certificate;
case certificate_verify:	CertificateVerify;
case finished:	Finished;
case new_sessionJicket:	NewSessionTicket;
case keyjjpdate:	KeyUpdate;

}:

} Handshake;

Далее no тексту установлено, что под терминами «сообщение ClientHello», «сообщение

ServerHello».....«сообщение KeyUpdate» подразумевается набор данных, соответствующих структуре

Handshake (в частности, имеющий поля Handshake.msgjype и Handshake.length), описанной выше,

для которых поле Handshake.msgjype содержит значения clientJiello(OxOI), server_hello(0x02).....key_

update(0x18) соответственно.

Далее по тексту установлено, что строки ClientHello. ServerHello.....KeyUpdate являются байтовыми представлениями сообщений ClientHello.....KeyUpdate соответственно (см. 3.2).

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

Далее no тексту установлено, что под термином «main-handshake сообщения» подразумеваются сообщения, посылаемые сторонами взаимодействия в рамках работы протокола Handshake, начиная с исходного сообщения ClientHello и заканчивая первым сообщением Finished со стороны клиента, при этом сообщения NewSessionTicket и KeyUpdate. которые могут быть посланы сервером до получения первого сообщения Finished со стороны клиента в случае односторонней аутентификации (см. подробнее 5.9.1 и 5.9.3), не включаются в множество main-handshake сообщений.

Далее по тексту установлено, что под термином «post-handshake сообщения» подразумеваются все сообщения, посылаемые сторонами взаимодействия в рамках работы протокола Handshake, которые не являются main-handshake сообщениями.

Сообщения протокола Handshake должны пересылаться в строгом фиксированном порядке, который определяется следующим образом: ClientHello/(ClientHello1. HelloRetryRequest, ClientHello2), ServerHello. EncryptedExtensions. CertificateRequest, Certificate со стороны сервера. CertificateVerify со стороны сервера, Finished со стороны сервера. Certificate со стороны клиента, CertificateVerify со стороны клиента. Finished со стороны клиента, post-handshake сообщения (см. 5.9). При этом опциональные сообщения из данного списка могут опускаться. Сторона взаимодействия, получившая сообщение протокола Handshake, которое не соответствует данному порядку, должна прервать работу протокола с оповещением об ошибке unexpected_message (см. 7.2).

Примечание — В настоящих рекомендациях не описывается сообщение EndOfEartyData. указанное в (1J. так как в версии протокола TLS 1.3, соответствующей настоящим рекомендациям, пересылка 0-RTT данных запрещена

5.2 Базовые принципы работы протокола Handshake

В рамках протокола TLS 1.3 существует два типа энтропийных данных, которые могут быть использованы для выработки общих секретных значений в соответствии с иерархией ключей (см. 8.2):

а)    общее секретное значение ECDHE, вырабатываемое при использовании протокола Диффи-Хеллмана на основе эллиптических кривых¹) в соответствии с 8.5. Для выработки данного значения стороны взаимодействия обмениваются открытыми эфемерными ключами в рамках сообщений ключевого обмена;

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

1)    выработан в рамках работы протокола Handshake — внутренний предварительно распределенный секрет iPSK;

2)    распределен между сторонами вне протокола TLS 1.3 — внешний предварительно распределенный секрет ePSK. Настоящие рекомендации не фиксируют механизм формирования и распределения значения ePSR. При необходимости использования данного типа предварительно распределенного секрета описание данного механизма, исследование предоставляемого посредством использования данного значения ePSK функционала, а также анализ стойкости протокола должны проводиться отдельно.

В рамках протокола TLS 1.3 существует два способа аутентификации сторон:

а)    аутентификация за счет использования сертификатов и подписи. При этом аутентификация сервера является обязательной и происходит только в рамках пересылки соответствующих main-handshake сообщений, а аутентификация клиента является опциональной, выполняется по запросу от сервера и проходит в рамках пересылки как main-handshake, так и post-handshake сообщений (см. 5.9.2);

б)    аутентификация за счет подтверждения (неявного) факта обладания предварительно распределенным секретом. При этом тип аутентификации (двусторонняя или односторонняя) либо определяется типом аутентификации сторон в соединении на момент пересылки сообщения NewSessionTicket, ассоциированного с используемым внутренним предварительно распределенным секретом iPSK. либо всегда является двусторонней²) в случае использования внешнего предварительно распределенного секрета ePSK.

') В соответствии с (1) протокол TLS 1.3 допускает возможность работы протокола Handshake на основе использования протокола Диффи-Хеллмана в мультипликативной группе конечного поля, однако этот способ в настоящих рекомендациях не поддерживается

²¹ Данное требование отсутствует в (1) и является дополнительным условием, накладываемым на внешний предварительно распределенный секрет в рамках настоящих рекомендаций 8

Примечания

1    Далее по тексту под «сертификатом сервера, ассоциированным со значением iPSK». подразумевается сертификат, который был использован сервером для успешной аутентификации при установлении первоначального соединения из цепочки соединений, в рамках которой было выработано данное значение iPSK Под «сертификатом клиента, ассоциированным со знамением iPSK», подразумевается сертификат, который был использован клиентом для успешной аутентификации при установлении некоторого соединения из цепочки соединений, в рамках которой было выработано данное значение iPSK, и который определяет состояние аутентификации клиента в соединении на момент пересылки сообщения NewSessionTcket, ассоциированного с данным значением iPSK

2    Далее по тексту установлено, что под термином «значение ePSK. абонированное со значением iPSK», подразумевается значение ePSK. согласованное в рамках первоначального соединения из цепочки соединений, в результате которой было выработано данное значение iPSK

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

а)    ecdhe_ke (см. подробнее 5.3.1). В качестве энтропийных данных для выработки общего ключевого материала соединения используется общее секретное значение ECDHE, вырабатываемое сторонами на этапе пересылки сообщений ключевого обмена (см. 8.5). Аутентификация сторон осуществляется за счет использования сертификатов и подписи:

б)    psk_ke (см. подробнее 5.3.2.1). В качестве энтропийных данных для выработки общего ключевого материала соединения используется общее секретное PSK-значение. вырабатываемое в соответствии с 8.6 (в рамках настоящих рекомендаций допускается использование только внутреннего предварительно распределенного секрета iPSK). Аутентификация сторон осуществляется за счет подтверждения (неявного) факта обладания PSK-значением;

в)    psk_ecdhe_ke (см. подробнее 5.3.2.2): на основе использования двух подходов, перечисленных выше. В качестве энтропийных данных для выработки общего ключевого материала соединения используется предварительно распределенный секрет PSK, вырабатываемый в соответствии с 8 6. который может быть как внутренним (iPSK). так и внешним (ePSK). и общее секретное значение ECDHE. вырабатываемое сторонами на этапе пересылки сообщений ключевого обмена (см. 8.5). Аутентификация сторон осуществляется за счет подтверждения (неявного) факта обладания значением PSK.

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

а)    полная схема обмена сообщениями (Full Handshake): к данному типу относятся ECDHE-only и ePSK-ECDHE режимы;

б)    возобновление соединения (Resumption): к данному типу относятся iPSK-only и iPSK-ECDHE режимы. Данные режимы работы являются аналогами механизма возобновления соединения за счет использования идентификаторов сессии, применяемого в более ранних версиях протокола TLS (см. Р 1323565.1.020). и используются для быстрого восстановления параметров с помощью внутреннего предварительно распределенного секрета iPSK.

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

Таблица 1 — Соответствие режимов работы протокола Handshake схемам аутентифицированной выработки общего клкмевого материала

Режим работы протокола Handshake Схема аутентифицированной выработки общего ключевого материала Используемые энтропийные данные ECDHE-only ecdhe_ke ECDHE ePSK-ECDHE psk_ecdhe_ke ePSK и ECDHE iPSK-only psk_ke iPSK iPSK-ECDHE psk_ecdhe_ke iPSK и ECDHE

Соотношение режимов работы протокола Handshake приведено на рисунке 2. Основной принцип заключается в следующем: внешне распределенный секрет ePSK может быть использован только в рамках ePSK-ECDHE режима.

Клиент | Сервер
ClientHello: •    support ed_versions •    s*gnature_algonthnvs •    s»gnature_al90fithms_cert* •    support ed_groups •    key_share	-►
		Serve rHello support ed_versions • key_share •
		Encrypt edExtensions: supported_groups* •
		CertificateRequesf: signature_algonthms • signature_algorithms_cert**
		Certificate
		CertificateVerify
		Finished
	◄-	Application Data*
		NewSessionTicket *
oenmcate
CertificateVerify*
Finished
Application Data	◄-►	Application Data
	◄-	NewSessionTicket*
KeyUpdate*	◄-►	KeyUpdate*

Используемая система обозначений

• - расширения, посылаемые в рамках сообщения, под которым они указаны. • - опциональные данные; - сообщения. защищенные на ключах. выработанных из [aentkr\_hancbhake traffic secret (см подробнее 8 4); секретного значения -сообщения. защищенные на ключах. выработанных из | sender) _ a/>/tlicteioti _ traffic _ secret _ X (см подробнее 8.4) секретного значения

Рисунок 3 — Схема обмена сообщениями в ECDHE-only режиме работы протокола Handshake Примечания

1    На рисунке 3 прикладные данные Application Data не относятся к сообщениям протокола Handshake

2    Прикладные данные (Application Data), пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (см подробнее раздел 9)

3    Сообщения NewSessionTicket и KeyUpdate, пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (см подробнее 5.9.1, 5 9 3).

Для установления соединения в рамках ecdhe_ke схемы в сообщении ClientHello необходимо указать следующий минимальный набор расширений:

а) обязательное расширение supported_versions, используемое для согласования версии протокола TLS (см. 5.6.1);

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

в)    обязательные расширения supported_groups (см. 5.6.3) и key_share (см. 5.6.4). отвечающие за выработку общего секретного значения ECDHE, где;

1)    расширение supported_groups содержит информацию об эллиптических кривых, поддерживаемых клиентом и указываемых в порядке убывания предпочтения;

2)    расширение key_share содержит информацию об открытых эфемерных ключах Q¹^ Ср_с.....

предлагаемых клиентом и указываемых в порядке убывания предпочтения.

Для установления соединения в рамках ecdhe_ke схемы в сообщении ServerHello необходимо указать следующий минимальный набор расширений;

а)    обязательное расширение supported_versions. используемое для согласования версии протокола TLS (см. 5.6.1);

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

Примечания

1    Расширение supported_groups является опциональным для сервера и содержит информацию об эллиптических кривых, поддерживаемых сервером.

2    Расширение signature_algorithms является обязательным для сервера в случае двусторонней аутентификации и должно пересылаться в сообщении CertificateRequest

3    Расширение signature_algorrthms_cert является опциональным для клиента и сервера (см подробнее

5.6.2).

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

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

В случае необходимости смены ключевого материала трафика любая из сторон может послать сообщение KeyUpdate (см. 5.9.3).

5.3.2 Схемы, использующие предварительно распределенный секрет

Для установления защищенного соединения между клиентом и сервером может быть использовано PSK-значение. известное обеим сторонам до начала работы текущего соединения и выработанное в соответствии с одним из следующих способов:

а)    выработано в рамках работы протокола Handshake в соединении, предшествующем текущему (инициализирующем соединении), в соответствии с 8.6: внутренний предварительно распределенный секрет iPSK. При этом значение iPSK может быть использовано в рамках работы iPSK-only и iPSK-ECDHE режимов;

б)    распределено между сторонами вне протокола TLS 1.3: внешний предварительно распределенный секрет ePSK. При этом значение ePSK должно обеспечивать двустороннюю аутентификацию сторон и может быть использовано только в рамках работы ePSK-ECDHE режима.

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

Примечания

1 Требование двусторонней аутентификации отсутствует в (1) и является дополнительным условием, накладываемым на внешний предварительно распределенный секрет ePSK в рамках настоящих рекомендаций

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

Для выработки значения iPSK в рамках работы инициализирующего соединения сервер может послать сообщение NewSessionTicket (см. подробнее 5.9.1), содержащее данные, однозначно ассоциированные с секретным значением iPSK (см. подробнее 8.6).

Аутентификация сторон в рамках psk_ke и psk_ecdhe_ke схем аутентифицированной выработки общего ключевого материала всегда происходит за счет подтверждения (неявного) факта обладания PSK-значением, при этом сообщения CertificateRequest, Certificate и CertificateVerify посылаться не должны.

Для установления соединения в рамках psk_ke или psk_ecdhe_ke схем в сообщении ClientHello необходимо указать следующий минимальный набор расширений:

а)    обязательное расширение supported_versions. используемое для согласования версии протокола TLS (см. 5.6.1);

б)    обязательные для каждой из двух схем (psk_ke или psk_ecdhe_ke) расширения pre_shared_key (см. 5.6.5) и psk_key_exchange_modes (см. 5.6.6), отвечающие за согласование PSK-значения и режима его использования:

1)    расширение pre_shared_key содержит список данных, связанных со значениями предварительно распределенных секретов, которые клиент готов использовать в качестве энтропийных данных;

2)    расширение psk_key_exchange_modes. содержащее информацию о схемах аутентифицированной выработки общего ключевого материала, поддерживаемых клиентом;

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

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

Для установления соединения в рамках psk_ke или psk_ecdhe_ke схем в сообщении ServerHello необходимо указать следующий минимальный набор расширений:

а)    обязательное расширение supported_versions. используемое для согласования версии протокола TLS (см. 5.6.1);

б)    обязательное для каждой из двух схем (psk_ke или psk_ecdhe_ke) расширение pre_shared_key, содержащее информацию о выбранном сервером значении PSK и посылаемое в случае, если сервер готов работать с данными, переданными в расширениях pre_shared_key и psk_key_exchange_modes со стороны клиента;

в)    обязательное для psk_ecdhe_ke схемы расширение key_share. отвечающее за выработку общего секретного значения ECDHE. В случае psk_ke схемы данное расширение посылаться не должно.

Примечание — Расширение supported_groups является опциональным для сервера и содержит информацию об эллиптических кривых, поддерживаемых сервером

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

Если какая-либо из сторон не может работать на параметрах, предложенных второй стороной, то она должна завершить соединение либо с оповещением handshake_failure, либо с оповещением insufficient_security (см. 7.2).

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

В случае необходимости смены ключевого материала трафика любая из сторон может послать сообщение KeyUpdate (см. 5.9.3).

Подробная схема режимов работы протокола Handshake в рамках psk_ke и psk_ecdhe_ke схем аутентифицированной выработки общего ключевого материала приводится в 5.3.2.1 и 5.3.2.2 соответственно.

Примечание —В соответствии с [1] протокол TLS 1.3 допускает использование 0-RTT данных, однако при работе протокола в соответствии с настоящими рекомендациями данный функционал запрещен

5.3.2.1 Схема psk_ke

Схема psk_ke используется в рамках iPSK-only режима работы протокола Handshake, схема работы которого приведена на рисунке 4.

Клиент I Сервер Client Hello •    support ed_versions •    (signature_algonthms)* •    (key_share)* •    [ support ed_groups]‘ •    pre_shared_key •    psk_key_exchange_modes -► ServerHello supported_vers*ons • pre_shared_key • EncryptedExtens»ons Finished ◄- Application Data* NewSessionTicket* -KeyUpdate* Finished -► Application Data ◄-► Application Data ◄- NewSessionTicket* KeyUpdate* ◄-► KeyUpdate*

Используемая система обозначений

• - расширения, посылаемые в рамках сообщения, под которым они указаны; * - опциональные данные; D - расширение, посыпаемое клиентом в режиме возобновления возможности перехода к полной схеме обмена сообщениями соединения для обеспечения -сообщения, защищенные на ключах, выработанных [serkkr\ J*nktsUike !гфс_secret {см подробнее 8 4); из секретного значения ■■1 -сообщения. защищенные на ключах. выработанных (мчнк г | application traffic mxtvI _ Л (см подробнее 8 4). из секретного значения

Рисунок 4 — Схема обмена сообщениями в iPSK-only режиме работы протокола Handshake

Примечания

1    Прикладные данные Application Data не относятся к сообщениям протокола Handshake

2    На рисунке 4 прикладные данные Application Data, пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (подробнее раздел 9).

3    Сообщения NewSessionTicket и KeyUpdate, пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (см подробнее 5 91.593).

5.3.2.2 Схема psk_ecdhe_ke

Схема psk_ecdhe_ke используется в рамках ePSK-ECDHE или iPSK-ECDHE режимов работы протокола Handshake, схема работы которых приведена на рисунке 5.

Клиент		Сервер
ClientHetk) •    support ed_versions •    [s»gnature_al9onthms]* •    key_share •    supported_groups •    pre_shared_key •    psk_key_exchange_modes	-►
			ServerHelto: supported_versions • key_share • pre_shared_key •
			Encrypt edExtensions supported_groups* •
			Finished
	◄-
			NewSessionTicket*
			KeyUpdate*
Finished	-►
Application Data	◄-►		Application Data
	◄-		NewSessionTicket*
KevUodate*	◄-►		KeyUpdate*

Используемая система обозначений

• - расширения, посылаемые в рамках сообщения, под которым они указаны; * - опциональные данные. D - расширение, посылаемое клиентом в режиме возобновления возможности перехода к полной схеме обмена сообщениями; соединения для обеспечение - сообщения. защищенные на ключах. выработанных [sender]_handshake traffic_secret (см подробнее 8 4); из секретного значения -сообщения. защищенные на ключах, выработанных |s*ndtr\_(цурИса/ion_secret _Лг (см подробнее 8.4) из секретного значения

Рисунок 5 — Схема обмена сообщениями в ePSK-ECDHE и iPSK-ECDHE режимах работы протокола Handshake

Примечания

1    Прикладные данные Application Data не относятся к сообщениям протокола Handshake

2    На рисунке 5 прикладные данные Application Data, пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (подробнее раздел 9).

3    Сообщения NewSessionTicket и KeyUpdate, пересылаемые сервером до получения первого сообщения Finished со стороны клиента, могут быть посланы только в случае односторонней аутентификации (см. подробнее 5.9.1, 5.9.3).

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

5.4 Пересогласование открытых эфемерных ключей

Если в рамках режимов на основе ecdhe_ke и psk_ecdhe_ke схем аутентифицированной выработки общего ключевого материала данные, переданные клиентом в расширении key_share сообщения ClientHellol, не могут быть согласованы сервером (например, соответствуют параметрам эллилтиче-

Содержание

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

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

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

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

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

3.3    Сокращения.....................................................................5

4    Обзор протокола TLS.................................................................5

4.1    Иерархия информационного обмена................................................5

4.2    Состояние соединения............................................................6

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

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

5.2    Базовые принципы работы протокола Handshake......................................8

5.3    Схемы аутентифицированной выработки общего ключевого материала..................10

5.4    Пересогласование открытых эфемерных ключей.....................................15

5.5    Сообщения ключевого обмена....................................................16

5.6    Расширения....................................................................20

5.7    Параметры сервера.............................................................31

5.8    Сообщения аутентификации......................................................32

5.9    Post-handshake сообщения.......................................................35

6    Протокол Record...................................................................39

6.1    Фрагментация..................................................................40

6.2    Формирование записи...........................................................40

6.3    Защита данных.................................................................42

6.4    Счетчик полученных/отправленных записей.........................................43

6.5    Дополнение данных.............................................................44

7    Протокол Alert......................................................................44

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

7.2    Оповещения об ошибках.........................................................46

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

8.1    Функции, используемые при выработке ключей......................................48

8.2    Иерархия ключей...............................................................49

8.3    Обновление секретных значений..................................................52

8.4    Ключевой материал трафика......................................................53

8.5    Выработка общего секретного значения ECDHE......................................53

8.6    Выработка предварительно распределенного секрета PSK.............................54

8.7    Экспорт ключевого материала.....................................................55

8.8    Функция Transcript-Hash..........................................................55

8.9    Значения Handshake Context и Finished Secret.......................................55

9    Прикладные данные................................................................56

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

10.1    Идентификаторы криптонаборов из реестра «TLSCipherSuites»........................56

10.2    Идентификаторы схем подписи из реестра «TLSSignatureScheme».....................59

10.3    Идентификаторы кривых из реестра «TLSSupportedGroups»...........................60

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

При получении сообщения HelloRetryRequest клиенту необходимо послать модифицированное сообщение ClientHello2, содержащее расширение key_share с параметрами, скорректированными в соответствии с полученным ранее сообщением HelloRetryRequest.

Примечание — Обозначения «ClientHellol». «ClientHello2*. используемые в настоящем разделе, подробно обьясняются в 5 5.1.

5.5 Сообщения ключевого обмена

5.5.1 ClientHello

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

-    клиент впервые подключается к серверу (исходное сообщение ClientHello);

-    в ответ на сообщение HelloRetryRequest. посланное сервером (повторное сообщение ClientHello).

Примечание —Далее по тексту установлено, что под терминами «сообщение ClientHellol», «сообщение ClientHello2» подразумеваются исходное и повторное сообщение соответственно, а строки ClientHellol. ClientHello2 являются байтовыми представлениями сообщений ClientHellol. ClientHello2 соответственно

При получении сообщения ClientHello в любом другом случае, не перечисленном выше, сервер должен завершить соединение оповещением unexpected_message(CM. 7.2). поскольку версия протокола, описанная в настоящих рекомендациях, не поддерживает процедуру пересогпасования соединения (renegotiation), определенную в Р 1323565.1.020.

В случае если сервер устанавливает соединение в рамках протокола TLS версии ниже 1.3 и получает в рамках процедуры пересогпасования соединения (renegotiation) сообщение ClientHello. сформированное в соответствии с протоколом TLS 1.3, он должен сохранить предыдущую версию протокола TLS. В частности, сервер не должен согласовывать протокол TLS версии 1.3 в указанном случае.

В случае получения сообщения HelloRetryRequest клиент должен отправить сообщение ClientHello2, содержащее следующие изменения по сравнению с сообщением ClientHellol:

-    если расширение key_share было указано в сообщении HelloRetryRequest, список эфемерных ключей KeyShareClientHello должен содержать один элемент KeyShareEntry. соответствующий группе эллиптической кривой, указанной в расширении key_share сообщения HelloRetryRequest (см. 5.6 4 2);

-    если расширение cookie(CM. 5.6.8) было указано в сообщении HelloRetryRequest. оно должно присутствовать в сообщении ClientHello2:

-    расширение pre_shared_key, если оно присутствовало в сообщении ClientHellol, должно быть обновлено в сообщении ClientHello2 путем перевычисления поля obfuscated_ticket_age структуры Pskldentity в структуре PreSharedKeyExtension, описанной в 5.6.5, и binder-значений, описанных в 5.6.5.3; а также путем (опционального) удаления тикетов (и всей связанной с данными тикетами информации), несовместимых с криптонабором, указанным сервером.

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

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

uint16 ProtocolVersion;

opaque Random[32);

uint8 CipherSuite(2]; Г Cryptographic suite selector */

struct {

ProtocolVersion legacy_version = 0x0303; Г TLS vl .2 */

Random random;

opaque legacy_session_id<0..32>;

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

opaque legacy_compression_methods< 1.2^A8-1 >;

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

} ClientHello;

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

11.1    Механизмы защиты от атак по побочным каналам...................................61

11.2    Механизмы защиты от downgrade-атак.............................................61

Приложение А (справочное) Рекомендации по использованию TLS 1.3 криптонаборов в СКЗИ____63

Приложение Б (справочное) Язык представления данных в протоколе TLS.................... 64

Введение

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

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

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

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

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

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

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

Information technology Cryptographic data security The use of the Russian cryptographic algorithms in the Transport Layer Security protocol (TLS 1.3)

Дата введения — 2020—06—01

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

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

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

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

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

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

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

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

Р 1323565.1.012 Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации

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

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

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

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

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

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

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

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

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

3.1.1    клиент (client): Сторона взаимодействия, инициирующая установление TLS-соединения.

3.1.2    сервер (server): Сторона взаимодействия, не инициирующая установлениеТЕЭ-соединения.

3.1.3    TLS-соединение (connection): Соединение транспортного уровня мееду сторонами взаимодействия. возникающее в момент отправки клиентом сообщения приветствия ClientHello (далее — исходное сообщение ClientHellol для данного соединения) и перестающее существовать при закрытии соединения с помощью пересылки оповещений (см. раздел 7) либо при внештатном обрыве связи.

Примечания

1    В настоящих рекомендациях установлено, что термины «соединение» и «TLS соединение» являются синонимами, если не оговорено иное

2    При повторной отправке сообщения ClientHello (далее — повторное сообщение ClientHelk>2) в ответ на сообщение HeBoRetryRequest (см 5 5 3) новое соединение не создается

3    В версии протокола TLS 1 3. описанной в текущих рекомендациях, термин «сессия», существовавший в предыдущих версиях протокола (см Р 1323565 1 020), не используется, так как механизм возобновления соединения в настоящих рекомендациях заменен механизмом использования предварительно распределенного секрета

3.1.4    текущее соединение: TLS-соединение, для которого исходное сообщение ClientHellol было отправлено до текущего момента времени, но закрытия соединения еще не произошло.

3.1.5    соединение, предшествующее текущему соединению: TLScoeflHHemie. возникшее до момента пересылки исходного сообщения ClientHellol для текущего соединения.

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

3.1.7    трафик (traffic): Поток данных, передающийся в соединении.

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

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

3.1.10    TLS 1.3 сервер/клиент: Сервер/клиент. поддерживающий протокол TLS 1.3.

3.1.11    режим совместимости: Режим работы протокола TLS 1.3. в рамках которого TLS 1.3 сервер/клиент допускает возможность работы с клиентом/сервером в рамках версии протокола TLS, предшествующей версии TLS 1.3.

3.1.12    downgrade атака: Атака, в результате которой клиент и сервер устанавливают соединения в рамках версии протокола, предшествующей максимальной версии, поддерживающейся клиентом и сервером.

3.1.13_

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

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

3.1.14_

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

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

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

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

3.1.17    прикладные данные (application data): Данные прикладного уровня, пересылаемые в рамках работы протокола TLS (см. подробнее раздел 9).

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

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

3.1.19    внешний предварительно распределенный секрет: предварительно распределенный секрет, выработанный сторонами вне протокола TLS.

3.1.20    внутренний предварительно распределенный секрет: предварительно распределенный секрет, выработанный сторонами в рамках протокола TLS.

Примечания

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

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

3    В настоящих рекомендациях под обозначениями «[sender)» и «[receiver)» подразумевается переменная, принимающая значения из множества («сЛепГ». «server»} Например, под обозначением [sender\_wnte_key подразумевается переменная принимающая значения из множества {(±вп1_\лтпв_кву₁ server_wnte_key)

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

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

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

8_S, если Ь,.....b_s е {0, ... 255). При s = 0 множество B_s состоит из единственной пустой

строки длины 0;

В* — множество всех байтовых строк произвольной конечной длины:

|Ь| — длина байтовой строки be В' (если b — пустая строка, то |Ь| = 0);

| — конкатенация двух байтовых строк: для двух строк а = (а,.....a_s1) eB_s1, b = (b,.....b_s2)

g B_s2 их конкатенацией a|b называется строка с = (a_1t... . a_svb_v ... btf) e B_s1

6^s — байтовая строка длины s вида b* = (b, b.....b) eS_s, где be B,;

s

b[i..j) — строка b\i..j) = (b_r b_/+1.....fy e где 1 </'<; < s и b = (Ь,.....bj) е B_s;

LMB,(b) — строка LMB,(b) = (b,.....b_f) € 8_f. соответствующая строке b = (b,.....b^ e 8_S.    1 < f S s;

STR_s(r) — строка STR_s(r) = (b,.....b^eB_s. соответствующая числу r = 256^s-1 -b, +... + 256-b_s_₁ + b_sS

< 256^s - 1 (представление числа л в виде байтовой строки в формате big-endian);

s(r_s(r) — строка str_$(r) - (b,.....b_s)e B_$. соответствующая числу г = 256^s “ ¹ b_s + ... + 256    b₂+

+ b, s 256^s - 1 (представление числа г в виде байтовой строки в формате little-endian);

& — операция побитовой коньюнкции (побитовое “И");

Г г — наименьшее целое число, большее или равное г; п — параметр алгоритма блочного шифрования, называемый длиной блока, задаваемый согласованным криптонабором (см. 10.1.1); в рамках данного документа измеряется в байтах;

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

IVLen — длина вектора инициализации в байтах, задаваемая согласованным криптонабором (см. 10.1.2);

О_с — открытый эфемерный ключ клиента; d_c — закрытый эфемерный ключ клиента;

Q_s — открытый эфемерный ключ сервера; d_s — закрытый эфемерный ключ сервера;

эллиптическая кривая, указанная клиентом в расширении supported_groups; порядок группы точек эллиптической кривой Е,; д, — порядок циклической подгруппы группы точек эллиптической кривой Е{,

Р, — точка эллиптической кривой Е, порядка q,\

h, — кофактор циклической подгруппы порядка д, группы точек эллиптической кривой Е_г значение которого равно

(d'_s. Q'_s) — эфемерная ключевая пара сервера: закрытый и открытый ключи, соответствующие кривой (d'_c. Q'_c) — эфемерная ключевая пара клиента: закрытый и открытый ключи, соответствующие кривой

О, — нулевая точка эллиптической кривой Е-,

Q_venty — ключ проверки подписи, хранящийся в сертификате стороны взаимодействия; ^dsgn ~ ^ключ подписи, соответствующий ключу Q_venfy:

SIGN— функция формирования подписи, принимающая на вход произвольную байтовую строку М е В* и ключ подписи с/ и выдающая в качестве результата своей работы строку sgn (см. 10.2);

0 — операция покомпонентного сложения по модулю 2 двух байтовых строк одинаковой длины;

HASH — хэш-функция, задаваемая согласованным криптонабором (см. 10.1.4);

HLen — длина выхода хэш-функции HASH в байтах (см. 10.1.4);

НМАС — функция вычисления кода аутентификации сообщения, определяемая алгоритмом НМАС, описанным в Р 50.1.113—2016 (подраздел 4.1) и задающимся в соответствии с хэш-функцией. задаваемой согласованным криптонабором (см. 10.1.4).

Примечания

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

2    В настоящих рекомендациях установлен следующий порядок перевода чисел в строки, если иное не оговаривается все числовые значения, имеющие тип umt8, umt16. umt24, uint32, umt64, представляются в виде строк в

формате big-endian Например, десятичное число 16909060 с типом uint32 представляется в виде байтовой строки 01 02 03 04 в шестнадцатеричном виде

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

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

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

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

3.3 Сокращения

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

СКЗИ — средство криптографической защиты информации;

AEAD — (Authenticated Encryption with Associated Data) шифрование с имитозащитой и ассоциированными данными;

TCP — (Transmission Control Protocol) протокол управления передачей.

4 Обзор протокола TLS

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

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

-    конфиденциальность и целостность: обеспечивается за счет использования AEAD алгоритма.

Протокол TLS содержит два основных подпротокола, отвечающих за обеспечение свойств, перечисленных выше:

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

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

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

4.1 Иерархия информационного обмена

Протокол TLS 1.3 работает поверх транспортного протокола (например, TCP) с гарантированной доставкой пакетов данных, который обеспечивает доставку сообщений с сохранением их очередности, отсутствием потерь и дублирований. Поверх протокола TLS 1.3, в свою очередь, работают протоколы прикладного уровня

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