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

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

cryptographic algorithms in the Transport Layer Security protocol (TLS 1.3)

Р 1323565.1.043-2022

ОКС 35.030

Дата введения 1 января 2023 года

Предисловие

1 РАЗРАБОТАНЫ Обществом с ограниченной ответственностью «Код Безопасности» (ООО «Код Безопасности») с участием Общества с ограниченной ответственностью «КРИПТО-ПРО» (ООО «КРИПТО-ПРО»), Федерального государственного унитарного предприятия «Научно-технический центр „Атлас“ (ФГУП „НТЦ „Атлас“), Пензенского филиала ФГУП „НТЦ „Атлас“ и Акционерного общества „Информационные технологии и коммуникационные системы“ (АО „ИнфоТеКС“)»

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

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

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

Введение

Настоящие рекомендации разработаны в дополнение к Р 1323565.1.030 и содержат контрольные примеры использования криптоалгоритмов протокола безопасности транспортного уровня, описанного в них.

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

Настоящие рекомендации разработаны ООО «Код Безопасности» по сценариям работы протокола TLS 1.3, предоставленным ООО «КРИПТО-ПРО». Основу документа составляют контрольные значения, полученные специалистами ФГУП «НТЦ „Атлас“ и независимо верифицированные разработчиками следующих организаций: ПФ ФГУП „НТЦ „Атлас“, АО „ИнфоТеКС“ и ООО „КРИПТО-ПРО“. Эталонная реализация контрольных примеров разработана ООО „Код Безопасности“ с использованием материалов ФГУП „НТЦ „Атлас“ и АО „ИнфоТеКС“ и на основе эталонной реализации протокола TLS 1.3, предоставленной ТК 26.»

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

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

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

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

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

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

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

Р 1323565.1.030 «Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3)»

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

3 Описание сценариев работы протокола TLS 1.3

При обозначении сценариев работы протокола TLS 1.3 используется следующий шаблон:

Криптонабор_Тип хэндшейка_Схема выработки ключа_ [Кривая для ECDHE]Тип аутентификации [Кривые при использовании сертификатов]_ [Доп сообщения]_[Есть ли Record],

где [ ] обозначает опциональные блоки.

3.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD. Сценарий 1

В работе протокола TLS 1.3 по Сценарию 1 используется полная (Full Handshake) схема работы протокола Handshake со следующими настройками:

1. схема аутентифицированной выработки общего ключевого материала — ecdhe_ke (режим ECDHE-only);

2. односторонняя аутентификация сервера с использованием сертификата открытого ключа (алгоритм подписи ГОСТ Р 34.10-2012_256, эллиптическая кривая с параметрами id-tc26-gost-3410-2012-256-paramSetB);

3. для выработки общего секретного значения ECDHE согласование эллиптической кривой с параметрами id-tc26-gost-3410-2012-512-paramSetC осуществляется без передачи сообщения HelloRetryRequest;

4. согласование сторонами взаимодействия криптонабора с номером {0xC1, 0x05} TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S;

5. прикладные данные Application Data пересылаются со стороны сервера до получения первого сообщения Finished со стороны клиента.

После успешного установления защищенного соединения:

1. сервер посылает клиенту сообщение NewSessionTicket;

2. в рамках протокола Record пересылаются записи, содержащие прикладные данные типа Application Data, состоящие из нулевых данных размера 210 байт с дополнением нулями каждой до максимальной длины записи. Номера записей выбираются исходя из выбранного криптонабора для демонстрации работы алгоритма TLSTREE;

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

3.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE. Сценарий 2

В работе протокола TLS 1.3 по Сценарию 2 используется схема «Возобновление соединения» (Resumption) работы протокола Handshake со следующими настройками:

1. восстановление сессии осуществляется на базе соединения «TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S. Сценарий 1» (см. 3.1);

2. восстановление параметров соединения с помощью внутреннего предварительно распределенного секрета iPSK (выработанного в рамках предыдущего соединения через NST);

3. схема аутентифицированной выработки общего ключевого материала — psk_ke (режим iPSK-only);

4. согласование сторонами взаимодействия криптонабора с номером {0xC1, 0x05} TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S;

5. использование расширения post_handshake_auth для поддержки механизма post-handshake аутентификации.

После успешного установления защищенного соединения:

1. осуществление post-handshake аутентификации клиента с использованием сертификата открытого ключа (алгоритм подписи ГОСТ Р 34.10-2012_512, эллиптическая кривая с параметрами id-tc26-gost-3410-12-512-paramSetA);

2. передача сообщения KeyUpdate с запросом смены ключа у принимающей стороны.

3.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD. Сценарий 3

В работе протокола TLS 1.3 по Сценарию 3 используется полная (Full Handshake) схема работы протокола Handshake со следующими настройками:

1. схема аутентифицированной выработки общего ключевого материала — psk_ecdhe_ke (режим ePSK-ECDHE);

2. для установления защищенного соединения между клиентом и сервером используется общий секрет ePSK, предварительно распределенный вне протокола TLS 1.3;

3. согласование сторонами взаимодействия криптонабора с номером {0xC1, 0x04} TLS_GOSTR341112_256_WITH_MAGMA_MGM_L;

4. для выработки общего секретного значения ECDHE согласование эллиптической кривой с параметрами id-tc26-gost-3410-2012-256-paramSetB осуществляется с помощью передачи сообщения HelloRetryRequest. В расширении supported_groups дополнительно пересылаются параметры эллиптической кривой id-tc26-gost-3410-2012-512-paramSetC, расширение key_share пересылается пустым.

После успешного установления защищенного соединения:

1. в рамках протокола Record пересылаются 4 (четыре) записи, содержащие прикладные данные типа Application Data, состоящие из нулевых данных размера 210 байт без дополнения нулями каждой до максимальной длины записи. Номера записей выбираются исходя из выбранного криптонабора для демонстрации работы алгоритма TLSTREE;

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

3.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512. Сценарий 4

В работе протокола TLS 1.3 по Сценарию 4 используется полная (Full Handshake) схема работы протокола Handshake со следующими настройками:

1. схема аутентифицированной выработки общего ключевого материала — ecdhe_ke (режим ECDHE-only);

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

а) сервер — алгоритм подписи ГОСТ Р 34.10-2012_512, эллиптическая кривая с параметрами id-tc26-gost-3410-12-512-paramSetA,

б) клиент — алгоритм подписи ГОСТ Р 34.10-2012_256, эллиптическая кривая с параметрами — id-tc26-gost-3410-2012-256-paramSetB;

3. для выработки общего ECDHE секретного значения согласование эллиптической кривой с параметрами id-tc26-gost-3410-2012-256-paramSetA осуществляется без передачи сообщения HelloRetryRequest;

4. согласование сторонами взаимодействия криптонабора с номером {0xC1, 0x03} TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L.

4 Контрольные примеры работы алгоритма хэширования Transcript-Hash()

4.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD

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

Значения элементов байтовой строки HM приведены в следующих соответствующих пунктах:

• ClientHello в 8.1.2;
• ServerHello в 8.1.3;
• EncryptedExtensions в 8.1.5;
• Certificate в 8.1.6;
• CertificateVerify в 8.1.7;
• Server Finished в 8.1.8;
• Client Finished в 8.1.9.

4.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE

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

Значения элементов байтовой строки HM приведены в следующих соответствующих пунктах:

• ClientHello в 8.2.2;
• ServerHello в 8.2.3;
• EncryptedExtensions в 8.2.4;
• Server Finished в 8.2.5;
• Client Finished в 8.2.6;
• CertificateRequest в 8.2.8;
• Certificate в 8.2.10;
• CertificateVerify в 8.2.11.

4.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD

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

Значения элементов байтовой строки HM приведены в следующих соответствующих пунктах:

• ClientHello1 в 8.3.1;
• HelloRetryRequest в 8.3.2;
• ClientHello2 в 8.3.3;
• ServerHello в 8.3.4;
• EncryptedExtensions в 8.3.6;
• Server Finished в 8.3.7;
• Client Finished в 8.3.8.

4.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512

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

Значения элементов байтовой строки HM приведены в следующих соответствующих пунктах:

• ClientHello в 8.4.3;
• ServerHello в 8.4.4;
• EncryptedExtensions в 8.4.6;
• CertificateRequest в 8.4.7;
• Server Certificate в 8.4.8;
• Server CertificateVerify в 8.4.9;
• Server Finished в 8.4.10;
• Client Certificate в 8.4.11;
• Client CertificateVerify в 8.4.12.

5 Контрольные примеры формирования ключевого материала

5.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD

5.1.1 Выработка предварительного ключевого материала

В рамках Сценария 1 протокола TLS 1.3 значения HandshakeSecret и MasterSecret вырабатываются с помощью энтропийных данных ECDHE (см. 8.1.4):

EarlySecret =

HKDF-Extract(Salt: 0^Hlen, IKM: 0^Hlen) =

FB DE FB E5 27 FE EA 66 5A AB 92 77 A2 16 3B 83

43 08 4F D1 91 C4 60 66 26 0F AC 6F D1 43 6C 72

Derived #0 = Derive-Secret(EarlySecret, «derived», «») =

HKDF-Expand-Label(EarlySecret, «derived», Transcript-Hash(«»), 32) =

DB C3 C8 26 D8 77 A3 B7 D2 D2 45 3D BF DC 6C FB

FB 11 51 B3 E8 4F 0C 8F 26 01 1D 8D 5B F3 ED F7

HandshakeSecret =

HKDF-Extract(Salt: Derived #0, IKM: ECDHE) =

44 24 5E 2C 43 32 D1 F7 8B 0F 8D 16 F4 03 EB 69

ED 2A 40 53 84 7C DC 39 FA 8B 3D 29 74 F7 45 E7

Выработка ключевого материала MasterSecret с использованием HandshakeSecret:

Derived #1 = Derive-Secret(HandshakeSecret, «derived», «») =

HKDF-Expand-Label(HandshakeSecret, «derived», Transcript-Hash(«»), 32) =

EA 3C 54 BB D1 4E F9 D7 50 77 6F AB E3 95 BE 2A

BD DB BB B7 1C 13 C2 BD 60 9E 35 15 79 4A FA 02

MasterSecret =

HKDF-Extract(Salt: Derived #1, IKM: 0^Hlen) =

5.1.2 Выработка секретных значений на этапе согласования параметров соединения и аутентификации

На этапе выработки параметров соединения и аутентификации вырабатываются секретные значения на основе HandshakeSecret и HM1 (см. 5.1.1 и 4.1):

• client_handshake_traffic_secret клиента (обозначение — CHTS):

CHTS =

Derive-Secret(HandshakeSecret, «c hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «c hs traffic», Transcript-Hash(HM1), 32) =

B3 F7 11 3D 35 26 55 4F E6 55 E5 6F AB 79 B1 A0

3D E3 35 96 E3 30 88 C7 78 37 19 A9 A4 B0 DC CD

• server_handshake_traffic_secret сервера (обозначение — SHTS):

SHTS =

Derive-Secret(HandshakeSecret, «s hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «s hs traffic», Transcript-Hash(HM1), 32) =

70 A5 F2 46 3D F6 0D BA A2 36 8B 67 FD 45 AE FF

7C 1A 0B A4 2D 8A BD 72 41 5E CD 1D 94 E9 EF 54

5.1.3 Выработка ключевого материала трафика для защиты записей Handshake в протоколе Record

Вычисляется ключевой материал трафика Handshake:

• client_write_key_hs клиента с использованием CHTS (см. 5.1.2):

client_write_key_hs =

HKDF-Expand-Label(CHTS, «key», «», 32) =

58 16 88 D7 6E FE 12 2B B5 5F 62 B3 8E F0 1B CC

8C 88 DB 83 E9 EA 4D 55 D3 89 8C 53 72 1F C3 84

client_write_iv_hs =

HKDF-Expand-Label(CHTS, «iv», «», 16) =

43 9A 07 45 3D 0B EA 0C 1D 1B EB 73 8E B5 B8 DD

• server_write_key_hs сервера с использованием SHTS (см. 5.1.2):

server_write_key_hs =

HKDF-Expand-Label(SHTS, «key», «», 32) =

C2 89 A3 96 AB 6C 5B 52 4B BB 9C 06 F3 9F EF 01

server_write_iv_hs =

HKDF-Expand-Label(SHTS, «iv», «», 16) =

69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0E

Примечание — Векторы инициализации client_write_iv_hs на стороне клиента и server_write_iv_hs на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.5 - 8.1.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.1.4 Выработка ключей для формирования данных verify_data сообщения Finished

Ключи вычисления кода аутентификации:

• client_finished_key клиента с использованием CHTS (см. 5.1.2):

client_finished_key = HKDF-Expand-Label(CHTS, «finished», «», 32) =

2F 21 54 8C F5 27 78 69 AE 49 0D E7 BC 15 AC E6

39 F6 57 E3 58 2A 5A 63 4B 0A 91 56 95 D5 4C 42

• server_finished_key сервера с использованием SHTS (см. 5.1.2):

server_finished_key = HKDF-Expand-Label(SHTS, «finished», «», 32) =

53 F1 C0 38 8F 8A 70 C0 BC A0 DD 21 A0 30 F2 38

1C 34 37 CD 0E 7E C9 3D 0A 96 5E 25 63 2D D7 9A

5.1.5 Выработка ключевого материала трафика прикладных данных Application Data и post-handshake сообщений

Вычисляется ключевой материал трафика прикладных данных Application Data с использованием MasterSecret и HM2 (см. 5.1.1 и 4.1):

• client_application_traffic_secret клиента (обозначение — CATS):

CATS =

Derive-Secret(MasterSecret, «c ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «c ap traffic», Transcript-Hash(HM2), 32) =

8A CF 74 6B EC 31 17 6C BD 14 2C 75 80 6C 27 0A

0A EF 6F C3 8E 0D 8F DC B5 A8 85 25 36 3A DE 81

• server_application_traffic_secret сервера (обозначение — SATS):

Derive-Secret(MasterSecret, «s ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «s ap traffic», Transcript-Hash(HM2), 32) =

87 73 4F 4B 4C FD 17 B9 7B 83 4D 82 2D 9D 73 79

F6 F5 E0 3B 80 B5 2A EB 2A FF 51 0E DD 83 DB D2

5.1.6 Выработка ключевого материала возобновления соединения в рамках NewSession-Ticket

Выработка ключевого материала resumption_master_secret для возобновления соединения (обозначение — RMS) с использованием MasterSecret и HM3 (см. 4.1 и 5.1.1):

RMS =

Derive-Secret(MasterSecret, «res master», HM3) =

HKDF-Expand-Label(MasterSecret, «res master», Transcript-Hash(HM3), 32) =

26 02 F9 6F 63 5C C8 B8 6C EA ED 79 20 89 20 66

4C 76 19 E9 B1 4A CF 24 87 C5 B9 94 E0 4B 0A 59

Выработка значения внутреннего предварительно распределенного секрета iPSK, который ассоциируется с тикетом, пересылаемым в сообщении NewSessionTicket (см. 8.1.10), с использованием RMS:

Nonce = 00 00 00 00 00 00 00 00

iPSK =

HKDF-Expand-Label(RMS, «resumption», Nonce, 32) =

94 E3 EA 30 04 B3 39 ED FE FB F1 69 6F 1A 58 7D

17 0B 92 BC F1 40 F3 16 7A A1 51 5F DF B0 85 6E

5.1.7 Выработка ключевого материала трафика для защиты записей Application Data в протоколе Record

Вычисляется ключевой материал трафика Application Data:

• client_write_key_ap клиента с использованием CATS (см. 5.1.5):

client_write_key_ap =

HKDF-Expand-Label(CATS, «key», «», 32) =

7B E6 4E 2C 12 78 7B 5B 8C 87 56 C4 3D 92 FA EF

64 F1 5A 3A 3C 10 81 AD 34 BC A5 06 F0 32 24 15

client_write_iv_ap =

HKDF-Expand-Label(CATS, «iv, „“, 16) =»

31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 54

• server_write_key_ap клиента с использованием SATS (см. 5.1.5):

server_write_key_ap =

HKDF-Expand-Label(SATS, «key», «», 32) =

47 5E 4C 51 4C C6 31 8C 3A 5F 00 0F 12 65 BD 1A

B5 F0 DE 1A F3 57 ED 00 79 EC 5F F0 AF BD 03 0C

server_write_iv_ap =

HKDF-Expand-Label(SATS, «iv», «», 16) =

AF E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B8

Примечание — Векторы инициализации client_write_iv_ap на стороне клиента и server_write_iv_ap на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.10 - 8.1.12) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE

5.2.1 Начальный ключевой материал возобновления сессии

В рамках Сценария 1 (см. 3.1) протокола TLS 1.3 выработано значение ключевого материала resumption_master_secret для возобновления соединения (обозначение — RMS) (см. 5.1.6):

RMS =

26 02 F9 6F 63 5C C8 B8 6C EA ED 79 20 89 20 66

4C 76 19 E9 B1 4A CF 24 87 C5 B9 94 E0 4B 0A 59

Также выработано значение внутреннего предварительно распределенного секрета iPSK с использованием RMS:

Nonce = 00 00 00 00 00 00 00 00

iPSK =

HKDF-Expand-Label(RMS, «resumption», Nonce, 32) =

94 E3 EA 30 04 B3 39 ED FE FB F1 69 6F 1A 58 7D

17 0B 92 BC F1 40 F3 16 7A A1 51 5F DF B0 85 6E

5.2.2 Выработка предварительного ключевого материала

В рамках Сценария 2 протокола TLS 1.3 значения EarlySecret, HandshakeSecret и MasterSecret вырабатываются с помощью энтропийных данных iPSK (см. 5.2.1):

EarlySecret =

HKDF-Extract(Salt: 0^Hlen, IKM: PSK) =

87 39 5F F2 D2 BB 8A EE BC B4 19 88 4E DC 9E 6C

0E 38 48 2C 5A 8E 20 F3 5D 07 C2 B4 0E 85 19 3E

Derived #0 = Derive-Secret(EarlySecret, «derived», «») =

HKDF-Expand-Label(EarlySecret, «derived», Transcript-Hash(«»), 32) =

BE DB B6 BF E9 9D 1E 9D 30 FD AA 05 C7 DD 0F 74

68 AB 4D EB D7 80 FF 01 94 7E 58 C2 57 4A 32 8A

HandshakeSecret =

HKDF-Extract(Salt: Derived #0, IKM: 0^Hlen) =

94 1A E2 2F 05 12 4A 56 DC 6A E8 D5 1E 42 D3 2B

93 98 DE 40 6F B0 18 35 51 A0 8C 8E 37 63 95 4A

Выработка ключевого материала MasterSecret с использованием HandshakeSecret:

Derived #1 = Derive-Secret(HandshakeSecret, «derived», «») =

HKDF-Expand-Label(HandshakeSecret, «derived», Transcript-Hash(«»), 32) =

02 89 97 3A F2 D7 FA B1 A6 C2 9C 52 6C F4 EA 83

D4 F5 4B 8D 74 59 88 B1 BB 79 4A E5 7C 02 2E FD

MasterSecret =

HKDF-Extract(Salt: Derived #1, IKM: 0^Hlen) =

96 76 EF 79 C9 34 70 94 AD 21 AD 2D 18 94 D3 1D

D0 05 BC DB A6 92 97 92 DE FA A4 36 7A BB DD 96

5.2.3 Выработка секретного значения связи инициализирующего соединения с текущим соединением

Вырабатывается секретное значение binder_secret (обозначение — BS) с использованием значения EarlySecret (см. 5.2.2):

BS =

Derive-Secret(EarlySecret, «res binder», «») =

HKDF-Expand-Label(EarlySecret, «res binder», Transcript-Hash(«»), 32) =

B2 5B 4F 99 E5 C9 DE 89 07 D7 30 D4 31 B0 78 83

FE B6 48 1A 09 43 48 22 5C BD D6 9D 2B 81 44 37

5.2.4 Выработка контрольного значения проверки предварительно распределенного секрета

Ключевой материал HMAC_binder_key вырабатывается с использованием секретного значения BS (см. 5.2.3) для формирования binder-значений, содержащих контрольные данные, сформированные с помощью функции HMAC и предназначенные для проверки корректности значения iPSK, соответствующего данному binder-значению:

HMAC_binder_key =

HKDF-Expand-Label(BS, «finished», «», 32) =

5A 54 28 AE 4D E9 B9 D1 8A 04 0B 16 27 B0 E6 DA

FD F5 19 61 08 C5 74 B2 76 2B 1F 45 1B 4C B4 C5

5.2.5 Выработка секретных значений на этапе согласования параметров соединения и аутентификации

На этапе выработки параметров соединения и аутентификации вырабатываются секретные значения на основе HandshakeSecret и HM1 (см. 4.2 и 5.2.2):

• client_handshake_traffic_secret клиента (обозначение — CHTS):

CHTS =

Derive-Secret(HandshakeSecret, «c hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «c hs traffic», Transcript-Hash(HM1), 32 ) =

21 E8 3E CF 6A F5 39 F2 DA 1A 8F F1 E0 D1 E6 F1

4F DC 47 14 DD E4 F4 38 11 CE 8E 56 3C FA DA CD

• server_handshake_traffic_secret сервера (обозначение — SHTS):

SHTS =

Derive-Secret(HandshakeSecret, «s hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «s hs traffic», Transcript-Hash(HM1), 32 ) =

C5 EC 21 B3 16 32 B0 3C D9 AB 50 71 20 3D EF FB

0C A0 BF A0 28 D8 72 63 17 EF 0A FB 5E CC DF 35

5.2.6 Выработка ключевого материала трафика для защиты записей Handshake в протоколе Record

Вычисляется ключевой материал трафика Handshake:

• client_write_key_hs клиента с использованием CHTS (см. 5.2.5):

client_write_key_hs =

HKDF-Expand-Label(CHTS, «key», «», 32) =

FD 65 E3 D3 44 B0 D6 82 35 7B 85 13 DF 9F 4C 7D

93 B8 B6 5C 04 6F B1 66 B7 C3 F5 41 63 49 2D 10

client_write_iv_hs =

HKDF-Expand-Label(CHTS, «iv», «», 16) =

CC 3A 6C 73 E1 AD 4E 14 7E F2 42 22 C4 0E 90 3C

• server_write_key_hs сервера с использованием SHTS (см. 5.2.5):

server_write_key_hs =

HKDF-Expand-Label(SHTS, «key», «», 32) =

ED 50 70 10 31 33 4D C1 BC E2 43 72 90 F3 4A A6

38 A0 31 13 24 C2 E9 A7 AD 83 2C A1 AE 0A FD 22

server_write_iv_hs =

HKDF-Expand-Label(SHTS, «iv», «», 16) =

7A CF F0 C8 FD FA F3 06 84 18 15 A1 34 A7 75 20

Примечание — Векторы инициализации client_write_iv_hs на стороне клиента и server_write_iv_hs на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.5 - 8.1.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.2.7 Выработка ключей для формирования данных verify_data main-сообщения Finished

Ключи вычисления кода аутентификации:

• client_finished_key клиента с использованием CHTS (см. 5.2.5):

client_finished_key = HKDF-Expand-Label(CHTS, «finished», «», 32) =

9C A7 A4 E3 39 7C 96 B7 5E F5 D4 DD 32 D3 45 23

B9 CA BE 85 A7 DF A4 FD 89 C6 DA EB 1B 4D 62 03

• server_finished_key сервера с использованием SHTS (см. 5.2.5):

server_finished_key = HKDF-Expand-Label(SHTS, «finished», «», 32) =

A6 38 96 22 C0 24 A6 EE A0 21 B9 4B 0D 5E 45 C8

F6 D1 B4 BC 6B 9C 5B 3A DB A5 D1 98 37 C6 63 FC

5.2.8 Выработка ключевого материала трафика прикладных данных Application Data и post-handshake сообщений

Вычисляется ключевой материал трафика прикладных данных Application Data с использованием MasterSecret и HM2 (см. 5.2.2 и 4.2):

• client_application_traffic_secret клиента (обозначение — CATS):

CATS =

Derive-Secret(MasterSecret, «c ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «c ap traffic», Transcript-Hash(HM2), 32) =

3E 0E B0 F7 F8 D3 80 02 03 54 A7 66 2F 4F DD B3

4E 8F 17 E0 1A 62 18 5A 34 9F 73 D2 D7 FA A9 19

• server_application_traffic_secret сервера (обозначение — SATS):

SATS =

Derive-Secret(MasterSecret, «s ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «s ap traffic», Transcript-Hash(HM2), 32) =

67 64 28 D3 8A DC 25 D1 F0 D6 D0 0A F5 F7 5C 8A

C5 7B EA 9E E2 42 E6 60 32 90 A0 3F 90 5E AC F2

5.2.9 Выработка ключевого материала трафика для защиты записей Application Data в протоколе Record

Вычисляется ключевой материал трафика Application Data:

• client_write_key_ap клиента с использованием CATS (см. 5.2.8):

client_write_key_ap =

HKDF-Expand-Label(CATS, «key», «», 32) =

8E 1D FA 06 71 F2 4A 2C 27 21 AB 3E EC 07 77 CF

4B 24 D2 03 53 97 36 DE 5C 42 3F D6 16 3B 64 88

client_write_iv_ap =

HKDF-Expand-Label(CATS, «iv», «», 16) =

18 DA F6 CE A6 F5 A9 F4 98 44 AC A1 01 0B DB BD

• server_write_key_ap клиента с использованием SATS (см. 5.2.8):

server_write_key_ap =

HKDF-Expand-Label(SATS, «key», «», 32) =

62 74 1D 20 92 51 56 CF 05 96 42 64 58 74 0E EB

E2 95 9F 65 76 3A 9A 85 F6 C4 11 7E FD 87 FE A5

server_write_iv_ap =

HKDF-Expand-Label(SATS, «iv», «», 16) =

96 E1 4D 6F 63 41 91 37 7C 56 71 A4 6B 8E 25 40

Примечание — Векторы инициализации client_write_iv_ap на стороне клиента и server_write_iv_ap на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.2.7, 8.2.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.2.10 Обновление секретных значений и ключевого материала в рамках KeyUpdate

После завершения работы протокола main-Handshake инициализируется обновление текущих секретных значений трафика (см. 5.2.8) прикладных данных Application Data:

• client_application_traffic_secret_2 клиента (обозначение — CATS2):

CATS2 =

HKDF-Expand-Label(CATS, «traffic upd», «», 32) =

5B E8 FD 79 81 0A 0E 3E 73 4C EC 5F 17 A5 30 6C

29 B7 D6 76 F7 FB B1 5C E6 CE ED 90 15 EE 01 54

• server_application_traffic_secret_2 клиента (обозначение — SATS2):

SATS2 =

HKDF-Expand-Label(SATS, «traffic upd», «», 32) =

C5 45 9A 98 83 21 97 45 A7 6C 0F BF D8 E8 B1 87

83 72 31 2A 98 12 08 E6 E4 19 30 66 AB 4C 28 6A

Инициализируется обновление ключа client_finished_key (см. 5.2.9) с использованием CATS2 для формирования данных verify_data (см. 5.2.7) в рамках post-handshake сообщения Finished (см. 8.2.12):

client_finished_key2 = HKDF-Expand-Label(CATS2, «finished», «», 32) =

D3 F3 B9 95 D4 A3 5E 3A 00 6D F1 A9 3F 41 5F 0C

B1 DA FC 6F C6 25 F6 18 17 5D DF 8A 67 A3 AA AB

А также инициализируется обновление ключевого материала трафика для защиты записей Application Data:

• client_write_key_ap2 клиента с использованием CATS2:

client_write_key_ap2 =

HKDF-Expand-Label(CATS2, «key», «», 32) =

BE 7A 51 36 C3 6F CE 85 BE A3 C1 4E 4F FC 46 FD

CF 39 CF BA 81 81 6D FD 62 B8 27 3E 1F A4 BE 70

client_write_iv_ap2 =

HKDF-Expand-Label(CATS2, «iv», «», 16) =

88 98 11 AD 22 A5 94 06 A4 4F 7B 3D B4 75 C8 37

• server_write_key_ap2 клиента с использованием SATS2:

server_write_key_ap2 =

HKDF-Expand-Label(SATS2, «key», «», 32) =

16 25 33 E3 6E 2D AB B7 BE D9 D4 3D 46 1F 7B 64

48 54 C2 80 D7 66 45 E7 A5 9F 24 E2 30 77 17 0E

server_write_iv_ap2 =

HKDF-Expand-Label(SATS2, «iv», «», 16) =

D2 0F 58 1D C3 40 B1 B8 CD 58 22 EA 5C 58 2E 76

Примечание — Векторы инициализации client_write_iv_hs на стороне клиента и server_write_iv_hs на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.5 - 8.1.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD

5.3.1 Начальный ключевой материал

В рамках Сценария 3 (см. 3.3) протокола TLS 1.3 используется общий секрет ePSK, предварительно распределенный вне протокола TLS 1.3:

ePSK =

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

5.3.2 Выработка предварительного ключевого материала

В рамках Сценария 3 протокола TLS 1.3 значения EarlySecret, HandshakeSecret и MasterSecret вырабатываются с помощью энтропийных данных ePSK (см. 5.3.1) и ECDHE (см. 8.3.5):

EarlySecret =

HKDF-Extract(Salt: 0^Hlen, IKM: ePSK) =

42 30 7A 99 68 18 34 0D D0 56 2F 7F EB E6 2A B5

70 F3 BC 88 9C A9 29 3A 89 0D F2 09 B9 1B BB F3

Derived #0 = Derive-Secret(EarlySecret, «derived», «») =

HKDF-Expand-Label (EarlySecret, «derived», Transcript-Hash («»), 32) =

6B 4E 9C 49 C5 C6 F1 7F 60 B2 B8 4B 55 0A 16 38

14 09 5B 80 88 8E C0 B0 CA 52 E4 09 0C B3 F8 BE

HandshakeSecret =

HKDF-Extract(Salt: Derived #0, IKM: ECDHE) =

A9 CB E6 58 50 2F 3F D1 18 66 51 5F D6 15 E9 88

0D 1E 61 B5 28 34 BB FD 5F 19 C2 4C 53 C8 79 7F

Выработка ключевого материала MasterSecret с использованием HandshakeSecret:

Derived #1 = Derive-Secret(HandshakeSecret, «derived», «») =

HKDF-Expand-Label(HandshakeSecret, «derived», Transcript-Hash(«»), 32) =

BC 4D 6F E3 D9 43 78 21 1D 3D 64 1C 75 92 EB AA

7A A2 96 47 9C 57 BD D1 E1 4C 7B 04 9F 6D F1 CD

MasterSecret =

HKDF-Extract(Salt: Derived #1, IKM: 0^Hlen) =

DB FF 82 86 2E 54 A1 41 3E 6C 2E D8 2C 6D A5 AF

FD BF DE 12 30 2E 49 75 5B 61 F2 06 32 E1 0A 42

5.3.3 Выработка секретного значения связки начального ключевого материала с текущим соединением

Секретное значение связки binder_secret (обозначение — BS) начального ключевого материала ePSK (см. 5.3.1) с протоколом Handshake текущего соединения с использованием EarlySecret (см. 5.3.2).

BS =

Derive-Secret(EarlySecret, «ext binder», «») =

HKDF-Expand-Label(EarlySecret, «ext binder», Transcript-Hash(«»), 32) =

A4 37 62 C3 5E 75 54 1A 15 58 A0 8D 15 50 D3 29

4C C3 F9 0C 73 99 EC C0 50 B9 15 37 A2 4C D5 E4

5.3.4 Выработка ключевого материала для формирования binder-значения

Ключевой материал HMAC_binder_key вырабатывается с использованием секретного значения BS (см. 5.3.3) для формирования binder-значений, содержащих контрольные данные, сформированные с помощью функции HMAC и предназначенные для проверки корректности значения ePSK, соответствующего данному binder-значению.

HMAC_binder_key =

HKDF-Expand-Label(BS, «finished», «», 32) =

F5 6F 59 C2 E2 F8 E7 7C 69 80 1F B1 7D B4 C1 8B

ED 96 EB 32 FC D7 AB 95 AD D6 B1 CF F1 73 E6 65

5.3.5 Выработка секретных значений на этапе согласования параметров соединения и аутентификации

На этапе выработки параметров соединения и аутентификации вырабатываются секретные значения на основе HandshakeSecret и HM1 (см. 5.3.2 и 4.3):

• client_handshake_traffic_secret клиента (обозначение — CHTS):

CHTS =

Derive-Secret(HandshakeSecret, «c hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «c hs traffic», Transcript-Hash(HM1), 32 ) =

DF 00 4B 79 A1 D3 51 55 97 1B 0E 84 C8 91 99 7F

FE E6 D0 1B 27 04 23 CC 74 64 4B 25 47 3E 78 60

• server_handshake_traffic_secret сервера (обозначение — SHTS):

SHTS =

Derive-Secret(HandshakeSecret, «s hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «s hs traffic», Transcript-Hash(HM1), 32 ) =

4E F8 68 E5 5B 27 F8 88 8A 6F 82 DA A7 0B 01 1B

DA B1 77 95 10 F0 88 78 A0 22 2B 3E 2C 76 E6 83

5.3.6 Выработка ключевого материала трафика для защиты записей Handshake в протоколе Record

Вычисляется ключевой материал трафика Handshake:

• client_write_key_hs клиента с использованием CHTS (см. 5.3.5):

client_write_key_hs =

HKDF-Expand-Label(CHTS, «key», «», 32) =

DF 66 60 1E DD D6 4E 96 1D FC 7D D0 21 2E F2 25

C0 05 33 E6 DA A4 AD 24 18 5E BE B2 24 B5 46 B8

client_write_iv_hs =

HKDF-Expand-Label(CHTS, «iv», «», 8) =

E8 94 3c 9f A2 88 56 A1

• server_write_key_hs сервера с использованием SHTS (см. 5.3.5):

server_write_key_hs =

HKDF-Expand-Label(SHTS, «key», «», 32) =

DB 61 9B 58 F4 41 1E 33 4F 07 EA C7 7C EF EF CA

78 41 F5 40 88 B8 D0 D5 CE 6A 62 C9 82 85 C6 81

server_write_iv_hs =

HKDF-Expand-Label(SHTS, «iv», «», 8) =

FC 9E 2A C6 63 04 C2 5B

Примечание — Векторы инициализации client_write_iv_hs на стороне клиента и server_write_iv_hs на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.5 - 8.1.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.3.7 Выработка ключей для формирования данных verify_data сообщения Finished

Ключи вычисления кода аутентификации в рамках main-сообщений:

• client_finished_key клиента с использованием CHTS (см. 5.3.5):

client_finished_key = HKDF-Expand-Label(CHTS, «finished», «», 32) =

1F A6 7D 28 9F F2 A6 85 C7 BE 13 FD F5 60 A6 D5

A9 F5 EA 85 63 AD 6C C7 B4 85 30 76 59 A5 55 81

• server_finished_key сервера с использованием SHTS (см. 5.3.5):

server_finished_key = HKDF-Expand-Label(SHTS, «finished», «», 32) =

AF 41 F7 7A CB 18 B4 C5 9D E0 F7 8D 46 D5 AE 95

7A A4 92 A7 D8 D8 2A 36 F4 B2 09 B8 20 7C 79 03

5.3.8 Выработка ключевого материала трафика прикладных данных Application Data и post-handshake сообщений

Вычисляется ключевой материал трафика прикладных данных Application Data с использованием MasterSecret и HM2 (см. 5.3.2 и 4.3):

• client_application_traffic_secret клиента (обозначение — CATS):

CATS =

Derive-Secret(MasterSecret, «c ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «c ap traffic», Transcript-Hash(HM2), 32) =

20 D9 85 D5 B8 4D 9D 8D 4E 5E CF CD BC DD 67 41

55 F1 82 F7 28 7B 18 4D A5 53 42 5C 6C 64 57 83

• server_application_traffic_secret сервера (обозначение — SATS):

SATS =

Derive-Secret(MasterSecret, «s ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «s ap traffic», Transcript-Hash(HM2), 32) =

52 91 26 2B EC B5 22 69 34 3A E8 27 9B 43 54 B1

89 22 D5 15 04 60 8B A7 21 C4 72 46 7E EE E8 78

5.3.9 Выработка ключевого материала трафика для защиты записей Application Data в протоколе Record

Вычисляется ключевой материал трафика Application Data:

• client_write_key_ap клиента с использованием CATS (см. 5.3.8):

client_write_key_ap =

HKDF-Expand-Label(CATS, «key», «», 32) =

EB D2 71 DE 19 FE E1 8B B1 99 8F 69 AF 5B 6A E1

89 58 E8 D3 70 2F 12 FB B5 B0 3F 6F D6 91 FE FA

client_write_iv_ap =

HKDF-Expand-Label(CATS, «iv», «», 8) =

18 Fb 03 8d Bf 72 41 E6

• server_write_key_ap клиента с использованием SATS (см. 5.3.8):

server_write_key_ap =

HKDF-Expand-Label(SATS, «key», «», 32) =

15 D9 2C 51 47 B2 13 10 ED ED F5 5B 3D 7A B7 76

81 7D 6F E2 FC F2 30 D7 E3 F2 92 75 F6 E2 41 EC

server_write_iv_ap =

HKDF-Expand-Label(SATS, «iv», «», 8) =

71 2E 2F 11 CD 50 6E B9

Примечание — Векторы инициализации client_write_iv_ap на стороне клиента и server_write_iv_ap на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.3.9 - 8.3.10) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512

5.4.1 Выработка предварительного ключевого материала

В рамках Сценария 4 протокола TLS 1.3 значения HandshakeSecret и MasterSecret вырабатываются с помощью энтропийных данных ECDHE (см. 8.4.5):

EarlySecret =

HKDF-Extract(Salt: 0^Hlen, IKM: 0^Hlen) =

FB DE FB E5 27 FE EA 66 5A AB 92 77 A2 16 3B 83

43 08 4F D1 91 C4 60 66 26 0F AC 6F D1 43 6C 72

Derived #0 = Derive-Secret(EarlySecret, «derived», «») =

HandshakeSecret =

HKDF-Extract(Salt: Derived #0, IKM: ECDHE) =

75 7E 65 53 DB 28 4F 2F 52 5C EF 5F 26 E4 F3 D0

Выработка ключевого материала MasterSecret с использованием HandshakeSecret:

Derived #1 = Derive-Secret(HandshakeSecret, «derived», «») =

HKDF-Expand-Label(HandshakeSecret, «derived», Transcript-Hash(«»), 32) =

3A 16 EC 04 A8 F3 A8 EB 69 EC 48 2C B7 06 1E 91

MasterSecret =

HKDF-Extract(Salt: Derived #1, IKM: 0^Hlen) =

5.4.2 Выработка секретных значений на этапе согласования параметров соединения и аутентификации

На этапе выработки параметров соединения и аутентификации вырабатываются секретные значения на основе HandshakeSecret и HM1 (см. 5.4.1 и 4.4):

• client_handshake_traffic_secret клиента (обозначение — CHTS):

Derive-Secret(HandshakeSecret, «c hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «c hs traffic», Transcript-Hash(HM1), 32 ) =

Derive-Secret(HandshakeSecret, «s hs traffic», HM1) =

HKDF-Expand-Label(HandshakeSecret, «s hs traffic», Transcript-Hash(HM1), 32 ) =

C2 97 B6 7A 84 8C C8 72 3C C8 75 17 66 E2 45 2F

5.4.3 Выработка ключевого материала трафика для защиты записей Handshake в протоколе Record

Вычисляется ключевой материал трафика Handshake:

• client_write_key_hs клиента с использованием CHTS (см. 5.4.2):

client_write_key_hs =

HKDF-Expand-Label(CHTS, «key», «», 32) =

6C D6 F4 0C 66 E6 C5 D9 24 FB A7 FA 99 8E FB 88

client_write_iv_hs =

HKDF-Expand-Label(CHTS, «iv», «», 16) =

• server_write_key_hs сервера с использованием SHTS (см. 5.4.2):

server_write_key_hs =

HKDF-Expand-Label(SHTS, «key», «», 32) =

18 69 76 70 CD 38 C5 00 66 53 85 F1 0F C3 87 60

server_write_iv_hs =

HKDF-Expand-Label(SHTS, «iv», «», 16) =

Примечание — Векторы инициализации client_write_iv_hs на стороне клиента и server_write_iv_hs на стороне сервера, полученные после преобразования HKDF-Expand-Label, перед использованием в режиме MGM для формирования Nonce XORed (см. 8.1.5 - 8.1.9) модифицируются путем обнуления старшего бита. Более подробно см. Р 1323565.1.026.

5.4.4 Выработка ключей для формирования данных verify_data сообщения Finished

Ключи вычисления кода аутентификации:

• client_finished_key клиента с использованием CHTS (см. 5.4.2):

• server_finished_key сервера с использованием SHTS (см. 5.4.2):

server_finished_key = HKDF-Expand-Label(SHTS, «finished», «», 32) =

D8 B3 24 87 71 91 05 7E F2 10 8D A0 53 63 35 65

5.4.5 Выработка ключевого материала трафика прикладных данных Application Data и post-handshake сообщений

Вычисляется ключевой материал трафика прикладных данных Application Data с использованием MasterSecret и HM2 (см. 5.4.1 и 4.4):

• client_application_traffic_secret клиента (обозначение — CATS):

Derive-Secret(MasterSecret, «c ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «c ap traffic», Transcript-Hash(HM2), 32) =

8F 0A 63 FE 09 33 DE 9E 28 A8 EF BB 3D 2C CB E7

• server_application_traffic_secret сервера (обозначение — SATS):

SATS =

Derive-Secret(MasterSecret, «s ap traffic», HM2) =

HKDF-Expand-Label(MasterSecret, «s ap traffic», Transcript-Hash(HM2), 32) =

5.4.6 Выработка ключевого материала трафика для защиты записей Application Data в протоколе Record

Вычисляется ключевой материал трафика Application Data:

- client_write_key_ap клиента с использованием CATS (см. 5.4.5):

client_write_key_ap =

client_write_iv_ap =

HKDF-Expand-Label(CATS, «iv», «», 16) =

• server_write_key_ap клиента с использованием SATS (см. 5.4.5):

server_write_key_ap =

HKDF-Expand-Label(SATS, «key», «», 32) =

1F BB 33 F5 1A 17 84 BD C3 7E A0 4D 97 68 BC F7

server_write_iv_ap =

HKDF-Expand-Label(SATS, «iv», «», 16) =

6 Контрольные примеры работы алгоритма TLSTREE() выработки ключей защиты записей

Алгоритм TLSTREE() порождает из корневого ключа Kroot ключи защиты записей Handshake (на основе [sender]_write_key_hs) и Application Data (на основе [sender]_write_key_ap).

6.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD

В таблице ниже приведены значения ключевых последовательностей, используемые в рамках работы протокола TLS 1.3 в соответствии со Сценарием 1 (см. 3.1).

6.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE

В таблице ниже приведены значения ключевых последовательностей, используемые в рамках работы протокола TLS 1.3 в соответствии со Сценарием 2 (см. 3.2).

6.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD

В таблице ниже приведены значения ключевых последовательностей, используемые в рамках работы протокола TLS 1.3 в соответствии со Сценарием 3 (см. 3.3).

6.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512

В таблице ниже приведены значения ключевых последовательностей, используемые в рамках работы протокола TLS 1.3 в соответствии со Сценарием 4 (см. 3.4).

7 Контрольные примеры для работы протокола Record

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

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

Для наглядности данные, которыми оперируют клиент и сервер, представлены слева и справа от вертикальной черты соответственно. При этом обозначения «------->» и «<-------» используются для указания на данные, пересылаемые по каналу связи клиентом и сервером соответственно.

7.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD

7.1.1 Формирование защищенного Pre-handshake Application Data на стороне сервера

Отсылаются данные (23 байта) до ожидания Finished сообщения от клиента: «HELO gost.example.com\r\n».

7.1.2 Формирование защищенной записи Application data с номером 2 на стороне сервера

Сервером отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.3 Формирование защищенной записи Application data с номером 3 на стороне сервера

Сервером отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.4 Формирование защищенной записи Application data с номером 8 на стороне сервера

Сервером отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.5 Формирование защищенной записи Application data с номером 9 на стороне сервера

Сервером отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.6 Формирование защищенной записи Application data с номером 0 на стороне клиента

Клиентом отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.7 Формирование защищенной записи Application data с номером 1 на стороне клиента

Клиентом отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.8 Формирование защищенной записи Application data с номером 8 на стороне клиента

Клиентом отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.1.9 Формирование защищенной записи Application data с номером 9 на стороне клиента

Клиентом отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext дополнено до (214 + 1) байт.

7.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE

Контрольные примеры для работы протокола Record в рамках соединения "KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE по Сценарию 2" в настоящем документе не приводятся по причине специфики Сценария 2: "возобновление соединения" осуществляется на базе соединения "KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD. Сценарий 1" (см. 3.1).

7.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD

Сервером отсылаются сообщения размером 1 Кбайт, состоящие из нулевых данных. Поле TLSInnerPlaintext нулями не дополняется.

7.3.1 Формирование защищенной записи Application data с номером 0 на стороне сервера

7.3.2 Формирование защищенной записи Application data с номером 1 на стороне сервера

7.3.3 Формирование защищенной записи Application data с номером 128 на стороне сервера

7.3.4 Формирование защищенной записи Application data с номером 129 на стороне сервера

7.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512

Контрольные примеры для работы протокола Record в рамках соединения "KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512 по Сценарию 4" в настоящих рекомендациях не приводятся.

8 Контрольные примеры для работы протокола TLS 1.3

Для наглядности данные, которыми оперируют клиент и сервер, представлены слева и справа от вертикальной черты соответственно. При этом обозначения "------->" и "<-------" используются для указания на данные, пересылаемые по каналу связи клиентом и сервером соответственно.

8.1 KUZN_S_FULL_ECDHE_ED512_1AUTH_W256_NST_RECORD

8.1.1 Сертификат сервера

Алгоритм проверки электронной цифровой подписи - в соответствии с ГОСТ Р 34.10-2012 и длиной ключа - 256 бит.

Идентификатор кривой сертификата сервера:

id-tc26-gost-3410-2012-256-paramSetB, OID "1.2.643.7.1.2.1.1.2".

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

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

Certificate SEQUENCE

tbsCertificate: TBSCertificate SEQUENCE

version: [0] EXPLICIT Version INTEGER v3 (02) OPTIONAL

serialNumber: CertificateSerialNumber INTEGER 12345 (30:39)

signature: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.2 (id_tc26_signwithdigest_ gost3410_2012_256)

issuer: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13:10:67:6F:73:74:2E:65:78:61:6D:70:6C:65:2E:63

6F:6D

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString gost.example.com

validity: Validity SEQUENCE

notBefore: Time CHOICE utcTime

utcTime: UTCTime 2020-02-28T11:08:37

notAfter: Time CHOICE utcTime

utcTime: UTCTime 2030-02-25T11:08:37

subject: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13:10:67:6F:73:74:2E:65:78:61:6D:70:6C:65:2E:63

6F:6D

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString gost.example.com

subjectPublicKeyInfo: SubjectPublicKeyInfo SEQUENCE

algorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.1.1 (id_tc26_gost3410_2012_256)

parameters: [UNIV 16] ANY OPTIONAL

30:0B:06:09:2A:85:03:07:01:02:01:01:02

DEFINED BY id_tc26_gost3410_2012_256: GostR34102012PublicKeyParameters SEQUENCE

publicKeyParamSet: OBJECT IDENTIFIER 1.2.643.7.1.2.1.1.2 (id_tc26_ gost3410_2012_256_paramSetB)

subjectPublicKey: BIT STRING 528 bits

04:40:F3:83:CE:E8:30:48:B4:EB:14:C7:1A:7F:6D:E4

4A:37:CE:11:A6:AC:17:50:F1:CF:B8:DA:D8:A3:8C:CD

D8:FD:06:65:6F:7C:FC:07:5F:40:83:C3:71:62:21:47

8F:1E:E2:4C:6B:1B:70:CC:E3:C7:2A:FD:2A:CE:65:C7

75:BC

extensions: [3] EXPLICIT Extensions SEQUENCE OF OPTIONAL

0: Extension SEQUENCE

extnID: OBJECT IDENTIFIER 2.5.29.14 (id_ce_subjectKeyIdentifier)

extnValue: OCTET STRING 22 bytes

04:14:F3:30:FA:71:66:DF:09:5A:F3:A0:73:BC:3B:8E

A3:56:D7:DF:AC:71

DEFINED BY id_ce_subjectKeyIdentifier: SubjectKeyIdentifier OCTET STRING 20 bytes

F3:30:FA:71:66:DF:09:5A:F3:A0:73:BC:3B:8E:A3:56

D7:DF:AC:71

signatureAlgorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.2 (id_tc26_signwithdigest_ gost3410_2012_256)

signatureValue: BIT STRING 512 bits

AB:2E:DA:23:F4:9B:48:62:3B:0C:FF:59:06:B7:DD:3C

23:B4:73:57:0B:29:6A:08:71:DD:15:EF:9A:33:20:1B

97:90:4A:5C:FA:6C:93:1C:54:73:DC:0C:5A:5F:2F:BB

2E:50:CF:58:7A:E2:7C:4D:8E:52:EB:80:18:9D:D0:8B

Итоговое представление данных:

30 82 01 44 30 81 F2 A0 03 02 01 02 02 02 30 39

30 0A 06 08 2A 85 03 07 01 01 03 02 30 1B 31 19

30 17 06 03 55 04 03 13 10 67 6F 73 74 2E 65 78  |0...U....gost.ex|
61 6D 70 6C 65 2E 63 6F 6D 30 1E 17 0D 32 30 30  |ample.com0...200|
32 32 38 31 31 30 38 33 37 5A 17 0D 33 30 30 32  |228110837Z..3002|
32 35 31 31 30 38 33 37 5A 30 1B 31 19 30 17 06  |25110837Z0.1.0..|
03 55 04 03 13 10 67 6F 73 74 2E 65 78 61 6D 70  |.U....gost.examp|
6C 65 2E 63 6F 6D 30 5E 30 17 06 08 2A 85 03 07  |le.com0^0...*...|

01 01 01 01 30 0B 06 09 2A 85 03 07 01 02 01 01

02 03 43 00 04 40 F3 83 CE E8 30 48 B4 EB 14 C7

1A 7F 6D E4 4A 37 CE 11 A6 AC 17 50 F1 CF B8 DA

D8 A3 8C CD D8 FD 06 65 6F 7C FC 07 5F 40 83 C3

71 62 21 47 8F 1E E2 4C 6B 1B 70 CC E3 C7 2A FD

2A CE 65 C7 75 BC A3 21 30 1F 30 1D 06 03 55 1D

0E 04 16 04 14 F3 30 FA 71 66 DF 09 5A F3 A0 73

BC 3B 8E A3 56 D7 DF AC 71 30 0A 06 08 2A 85 03

07 01 01 03 02 03 41 00 AB 2E DA 23 F4 9B 48 62

3B 0C FF 59 06 B7 DD 3C 23 B4 73 57 0B 29 6A 08

71 DD 15 EF 9A 33 20 1B 97 90 4A 5C FA 6C 93 1C

54 73 DC 0C 5A 5F 2F BB 2E 50 CF 58 7A E2 7C 4D

8E 52 EB 80 18 9D D0 8B

8.1.2 Формирование сообщения ClientHello на стороне клиента

8.1.3 Формирование сообщения ServerHello на стороне сервера

8.1.4 Формирование общего ECDHE-значения

ECDHE-ключ клиента и сервера формируется в соответствии с id-tc26-gost-3410-2012-512-paramSetC.

Закрытый ключ клиента для формирования ECDHE:

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

Открытый ключ клиента для формирования ECDHE (см. 8.1.2):

05 EE BD F3 DD C1 D2 F5 F3 82 24 33 24 12 84 E7

76 41 48 79 38 EA 88 72 1F 26 20 3E 97 92 B5 CB

97 EB 70 EF 02 E8 F7 2B 74 91 D4 F2 CF DC 33 2A

DF 7F 17 78 E8 54 A8 8D DC 21 13 FE C5 27 A1 51

71 A0 4C B0 C5 73 79 3A 7А EF 9B BC A4 86 B6 B0

46 B2 14 9B 46 F4 33 29 03 E5 B7 C4 38 AD D0 5E

18 5E FB F4 55 57 47 5A 8C CB F6 AC ED 1A 2E B4

16 F9 16 72 9D 7C EF 9C BD 83 34 98 93 04 AF AE

Закрытый ключ сервера для формирования ECDHE:

AA 3C A4 F4 A5 0A C0 5B 37 42 B1 35 B5 30 A9 F2

2A E4 F5 E1 85 30 1D EC 83 2E 77 BA 3B CD 6A F1

84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84

84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 04

Открытый ключ сервера для формирования ECDHE (см. 8.1.3):

2F 3C 66 3F E7 47 35 A1 C4 21 16 0D F0 F4 32 66

18 5F D3 0B 6E 5D 6E 88 FC 40 61 FA EA CA B3 38

B1 0A 1B D2 0C B0 B4 EE 75 7E 74 A0 02 7D 40 9F

E9 37 F0 16 33 A1 E3 F9 A5 51 8D EF D0 F8 9F 9D

3D 9F 6C C6 51 41 3D EC 2C 74 36 6D 83 C4 7E E1

DE 4E 42 1F 65 CD 11 63 E9 4E A0 C2 E1 9E D4 5D

35 55 8B 93 7D 9B FD C5 EC C2 B2 A2 1B 4E C3 D5

3B 29 57 9A 8F D5 E0 74 81 10 28 FB CF 17 99 4F

Выработанный общий ECDHE-ключ: на стороне клиента - на основе закрытого ключа клиента и открытого ключа сервера, на стороне сервера - на основе закрытого ключа сервера и открытого ключа клиента:

ECDHE =

4D E6 0D 21 EA 8F В9 22 0D 14 64 23 B4 90 DA 40

CC EB C4 3B C5 89 DB 79 B8 31 A4 7D 6B 06 30 07

DD 03 40 5A 1B 79 76 B6 23 DC AA 69 B0 11 AE 10

6E 7E 41 74 38 5F 86 26 E1 21 B5 99 43 63 C9 9F

8.1.5 Формирование защищенного сообщения EncryptedExtensions на стороне сервера

Далее на стороне сервера формируются сообщения, защищенные на ключах, выработанных из секретного значения server_handshake_traffic_secret (см. 5.1.2 и 5.1.3).

8.1.6 Формирование защищенного сообщения Certificate на стороне сервера

8.1.7 Формирование защищенного сообщения CertificateVerify на стороне сервера

8.1.8 Формирование защищенного сообщения Finished на стороне сервера

8.1.9 Формирование защищенного сообщения Finished на стороне клиента

8.1.10 Формирование защищенного сообщения NewSessionTicket на стороне сервера

8.1.11 Формирование оповещения Alert на стороне сервера

8.2 KUZN_S_RESUMP_POSTHANDSHAKE_W512_KEYUPDATE

8.2.1 Сертификат клиента

Алгоритм проверки электронной цифровой подписи - в соответствии с ГОСТ Р 34.10-2012 и длиной ключа - 512 бит.

Идентификатор кривой сертификата клиента:

id-tc26-gost-3410-12-512-paramSetA, OID "1.2.643.7.1.2.1.2.1".

Закрытый ключ клиента:

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

Certificate SEQUENCE

. tbsCertificate: TBSCertificate SEQUENCE

. . version: [0] EXPLICIT Version INTEGER v3 (02) OPTIONAL

. . serialNumber: CertificateSerialNumber INTEGER 12345 (30:39)

. . signature: AlgorithmIdentifier SEQUENCE

. . . algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.3 (id_tc26_signwithdigest_ gost3410_2012_512)

. . issuer: Name CHOICE rdnSequence

. . . rdnSequence: RDNSequence SEQUENCE OF

. . . . 0: RelativeDistinguishedName SET OF

. . . . . 0: AttributeTypeAndValue SEQUENCE

. . . . . . type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

. . . . . . value: [UNIV 19] AttributeValue ANY

. . . . . . . 13:06:63:6C:69:65:6E:74

. . . . . . . DEFINED BY id_at_commonName: CommonName CHOICE printableString

. . . . . . . . printableString: PrintableString client

. . validity: Validity SEQUENCE

. . . notBefore: Time CHOICE utcTime

. . . . utcTime: UTCTime 2020-02-28T11:08:37

. . . notAfter: Time CHOICE utcTime

. . . . utcTime: UTCTime 2030-02-25T11:08:37

. . subject: Name CHOICE rdnSequence

. . . rdnSequence: RDNSequence SEQUENCE OF

. . . . 0: RelativeDistinguishedName SET OF

. . . . . 0: AttributeTypeAndValue SEQUENCE

. . . . . . type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

. . . . . . value: [UNIV 19] AttributeValue ANY

. . . . . . . 13:06:63:6C:69:65:6E:74

. . . . . . . DEFINED BY id_at_commonName: CommonName CHOICE printableString

. . . . . . . . printableString: PrintableString client

. . subjectPublicKeyInfo: SubjectPublicKeyInfo SEQUENCE

. . . algorithm: AlgorithmIdentifier SEQUENCE

. . . . algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.1.2 (id_tc26_gost3410_2012_512_signature)

. . . . parameters: [UNIV 16] ANY OPTIONAL

. . . . . 30:0B:06:09:2A:85:03:07:01:02:01:02:01

. . . . . DEFINED BY id_tc26_gost3410_2012_512_signature: GostR34102012PublicKe yParameters SEQUENCE

. . . . . . publicKeyParamSet: OBJECT IDENTIFIER 1.2.643.7.1.2.1.2.1 (id_tc26_ gost3410_12_512_paramSetA)

. . . subjectPublicKey: BIT STRING 1048 bits

. . . . 04:81:80:20:A8:58:87:29:BF:24:72:F6:42:A8:6B:22

. . . . 40:85:E3:79:A5:75:35:FF:08:AF:74:2D:0A:80:C0:86

. . . . 30:2E:88:22:78:21:FA:34:D1:48:6E:DE:1B:89:4D:52

. . . . 69:1E:12:07:A2:DF:E0:C9:7B:CF:73:1B:36:89:3C:83

. . . . 2A:04:27:F6:B6:AA:EC:09:AC:1A:05:5C:62:FD:D3:FE

. . . . 04:DF:19:EA:89:92:44:D6:38:40:26:50:2F:11:8E:A4

. . . . F9:7E:A4:28:2E:15:CF:43:9E:0E:44:65:5F:39:BE:E1

. . . . 93:97:46:29:84:FA:15:8B:3D:7B:E5:E5:D5:FB:71:73

. . . . 9D:4B:C9

. . extensions: [3] EXPLICIT Extensions SEQUENCE OF OPTIONAL

. . . 0: Extension SEQUENCE

. . . . extnID: OBJECT IDENTIFIER 2.5.29.14 (id_ce_subjectKeyIdentifier)

. . . . extnValue: OCTET STRING 22 bytes

. . . . . 04:14:85:30:D9:D8:B6:8B:FC:24:88:4F:5F:5A:A0:8A

. . . . . D3:A5:41:37:6A:C4

. . . . . DEFINED BY id_ce_subjectKeyIdentifier: SubjectKeyIdentifier OCTET STRING 20 bytes

. . . . . . 85:30:D9:D8:B6:8B:FC:24:88:4F:5F:5A:A0:8A:D3:A5

. . . . . . 41:37:6A:C4

. signatureAlgorithm: AlgorithmIdentifier SEQUENCE

. . algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.3 (id_tc26_signwithdigest_ gost3410_2012_512)

. signatureValue: BIT STRING 1024 bits

. . 69:63:DB:E9:97:43:6B:48:08:1B:44:7B:DD:7A:65:C4

. . 43:92:DD:1A:CE:66:06:63:AB:E3:79:CF:6A:02:4D:4C

. . DE:CE:95:5B:89:82:5A:16:C4:55:11:2E:CF:22:D2:54

. . EF:8D:59:7D:DC:9B:C8:74:70:C9:D6:86:C4:06:EA:74

. . 3A:47:0C:E7:F6:FA:56:C0:FA:03:3B:CE:EF:E7:17:BB

. . 49:CE:0B:94:17:5D:53:4C:60:6A:9F:0E:1A:B3:81:BE

. . 3B:9B:51:6E:FC:57:1A:66:DD:46:45:35:4D:89:F4:91

. . 70:C6:1B:6E:CF:7F:8A:08:32:61:8E:FE:20:D8:C8:0D

Итоговое представление данных:

30 82 01 B5 30 82 01 21 A0 03 02 01 02 02 02 30

39 30 0A 06 08 2A 85 03 07 01 01 03 03 30 11 31

0F 30 0D 06 03 55 04 03 13 06 63 6C 69 65 6E 74  |.0...U....client|
30 1E 17 0D 32 30 30 32 32 38 31 31 30 38 33 37  |0...200228110837
5A 17 0D 33 30 30 32 32 35 31 31 30 38 33 37 5A  |Z..300225110837Z|
30 11 31 0F 30 0D 06 03 55 04 03 13 06 63 6C 69  |Z..300225110837Z|
65 6E 74 30 81 A0 30 17 06 08 2A 85 03 07 01 01  |0.1.0...U....cli|
01 02 30 0B 06 09 2A 85 03 07 01 02 01 02 01 03  |ent0..0...*.....|

81 84 00 04 81 80 20 A8 58 87 29 BF 24 72 F6 42

A8 6B 22 40 85 E3 79 A5 75 35 FF 08 AF 74 2D 0A

80 C0 86 30 2E 88 22 78 21 FA 34 D1 48 6E DE 1B

89 4D 52 69 1E 12 07 A2 DF E0 C9 7B CF 73 1B 36

89 3C 83 2A 04 27 F6 B6 AA EC 09 AC 1A 05 5C 62

FD D3 FE 04 DF 19 EA 89 92 44 D6 38 40 26 50 2F

11 8E А4 F9 7E A4 28 2E 15 CF 43 9E 0E 44 65 5F

39 BE E1 93 97 46 29 84 FA 15 8B 3D 7B E5 E5 D5

FB 71 73 9D 4B C9 A3 21 30 1F 30 1D 06 03 55 1D

0E 04 16 04 14 85 30 D9 D8 B6 8B FC 24 88 4F 5F

5A A0 8A D3 A5 41 37 6A C4 30 0A 06 08 2A 85 03

07 01 01 03 03 03 81 81 00 69 63 DB E9 97 43 6B

48 08 1B 44 7B DD 7A 65 C4 43 92 DD 1A CE 66 06

63 AB E3 79 CF 6A 02 4D 4C DE CE 95 5B 89 82 5A

16 C4 55 11 2E CF 22 D2 54 EF 8D 59 7D DC 9B C8

74 70 C9 D6 86 C4 06 EA 74 3A 47 0C E7 F6 FA 56

C0 FA 03 3B CE EF E7 17 BB 49 CE 0B 94 17 5D 53

4C 60 6A 9F 0E 1A B3 81 BE 3B 9B 51 6E FC 57 1A

66 DD 46 45 35 4D 89 F4 91 70 C6 1B 6E CF 7F 8A

08 32 61 8E FE 20 D8 C8 0D

8.2.2 Формирование сообщения ClientHello на стороне клиента

8.2.3 Формирование сообщения ServerHello на стороне сервера

8.2.4 Формирование защищенного сообщения EncryptedExtensions на стороне сервера

Далее на стороне сервера формируются сообщения, защищенные на ключах, выработанных из секретного значения server_handshake_traffic_secret.

8.2.5 Формирование защищенного main-сообщения Finished на стороне сервера

8.2.6 Формирование защищенного main-сообщения Finished на стороне клиента

8.2.7 Формирование защищенного сообщения KeyUpdate на стороне сервера

8.2.8 Формирование защищенного сообщения CertificateRequest на стороне сервера

8.2.9 Формирование защищенного сообщения KeyUpdate на стороне клиента

8.2.10 Формирование защищенного сообщения Certificate на стороне клиента

8.2.11 Формирование защищенного сообщения CertificateVerify на стороне клиента

8.2.12 Формирование защищенного posthandshake-сообщения Finished на стороне клиента

8.3 MAGMA_L_FULL_PSKECDHE_W256_EPSK_HRR_RECORD

8.3.1 Формирование сообщения ClientHello1 на стороне клиента

8.3.2 Формирование сообщения HelloRetryRequest на стороне сервера

8.3.3 Формирование сообщения ClientHello2 на стороне клиента

8.3.4 Формирование сообщения ServerHello на стороне сервера

8.3.5 Формирование общего ECDHE-значения

ECDHE-ключ клиента и сервера формируется в соответствии с id-tc26-gost-3410-2012-256-paramSetB.

Закрытый ключ клиента для формирования ECDHE:

02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02

02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02

Открытый ключ клиента для формирования ECDHE (см. 8.3.3):

D3 5A A7 95 C4 52 45 09 49 59 1D 60 E7 D5 C0 76

05 6D 66 46 F3 B8 07 08 CD C2 E7 03 4D E8 5F 68

D1 12 2D C3 2A 3B 98 6D 40 FF 91 06 22 A0 6C 12

26 D9 EC 3A 7D 3A 52 E0 A3 7C 28 2C 47 60 2A 43

Закрытый ключ сервера для формирования ECDHE:

83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83

83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83

Открытый ключ сервера для формирования ECDHE (см. 8.3.4):

3D 2F B0 67 E1 06 CC 99 80 FB 88 42 81 11 64 BA

70 8B BB 50 38 D5 ED FB EE 1D 5E 5D FB E6 F7 4F

19 31 21 7C 67 C2 BD F4 62 53 DB 9C E3 48 72 41

F2 DB D8 4E 2D AB DF 65 45 58 51 B0 B1 9A EF EC

Выработанный общий ECDHE-ключ: на стороне клиента - на основе закрытого ключа клиента и открытого ключа сервера, на стороне сервера - на основе закрытого ключа сервера и открытого ключа клиента:

ECDHE =

98 5A 86 59 D5 5A 8D 48 E0 E6 77 13 96 58 0B 2C

DC DA 37 E9 2A EE 18 14 D1 0E 1B F2 A4 4F 0D 24

8.3.6 Формирование защищенного сообщения EncryptedExtensions на стороне сервера

Далее на стороне сервера формируются сообщения, защищенные на ключах, выработанных из секретного значения server_handshake_traffic_secret (см. 5.3.5).

8.3.7 Формирование защищенного сообщения Finished на стороне сервера

8.3.8 Формирование защищенного сообщения Finished на стороне клиента

8.3.9 Формирование оповещения Alert на стороне сервера

Перед формированием оповещения Alert на стороне сервера осуществляется формирование записей Application Data (см. 7.3).

8.3.10 Формирование оповещения Alert на стороне клиента

8.4 KUZN_L_FULL_ECDHE_ED256_2AUTH_W256_W512

8.4.1 Сертификат сервера

Алгоритм проверки электронной цифровой подписи - в соответствии с ГОСТ Р 34.10-2012 и длиной ключа - 512 бит.

Идентификатор кривой сертификата сервера:

id-tc26-gost-3410-12-512-paramSetA, OID "1.2.643.7.1.2.1.2.1".

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

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80

Certificate SEQUENCE

tbsCertificate: TBSCertificate SEQUENCE

version: [0] EXPLICIT Version INTEGER v3 (02) OPTIONAL

serialNumber: CertificateSerialNumber INTEGER 12345 (30:39)

signature: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.3 (id_tc26_signwithdigest_ gost3410_2012_512)

issuer: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 2E 63

6F 6D

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString gost.example.com

validity: Validity SEQUENCE

notBefore: Time CHOICE utcTime

utcTime: UTCTime 2020-02-28T11:08:37

notAfter: Time CHOICE utcTime

utcTime: UTCTime 2030-02-25T11:08:37

subject: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 2E 63

6F 6D

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString gost.example.com

subjectPublicKeyInfo: SubjectPublicKeyInfo SEQUENCE

algorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.1.2 (id_tc26_ gost3410_2012_512)

parameters: [UNIV 16] ANY OPTIONAL

30 0B 06 09 2A 85 03 07 01 02 01 02 01

DEFINED BY id_tc26_gost3410_2012_512: GostR34102012PublicKeyParameter s SEQUENCE

publicKeyParamSet: OBJECT IDENTIFIER 1.2.643.7.1.2.1.2.1 (id_tc26_ gost3410_12_512 paramSetA)

subjectPublicKey: BIT STRING 1048 bits

04 81 80 36 43 9F 06 F3 3D 0D 0A 1F 56 E1 C1 5F

E9 3A 7C 41 E6 09 10 AE 0F A2 96 D2 97 6E E0 FA

F9 89 00 73 5F B5 21 DD 95 60 4D 09 25 BB 59 D8

ED 09 E2 54 4B 46 6A CC 24 5D 87 7E 05 BA 82 66

39 E5 4F 12 3E EF F3 E2 A5 CC C6 1C BE 2C FA A7

2B C6 A9 6C F5 A2 F7 BB C4 E3 E1 9F 5F 26 30 DC

BF 3E 92 95 78 F5 BC 1B ED 44 0F E5 F8 9A EA 7A

F9 AE 9B 28 0E 90 CF D1 C0 57 28 C4 97 E4 D0 1A

C2 0D 5A

extensions: [3] EXPLICIT Extensions SEQUENCE OF OPTIONAL

0: Extension SEQUENCE

extnID: OBJECT IDENTIFIER 2.5.29.14 (id_ce_subjectKeyIdentifier)

extnValue: OCTET STRING 22 bytes

04 14 6E BC B2 41 82 69 A5 28 58 70 58 F9 0E 06

EB 37 94 88 09 80

DEFINED BY id_ce_subjectKeyIdentifier: SubjectKeyIdentifier OCTET STRING 20 bytes

6E BC B2 41 82 69 A5 28 58 70 58 F9 0E 06 EB 37

94 88 09 80

signatureAlgorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.3 (id_tc26_signwithdigest_ gost3410_2012_512)

signatureValue: BIT STRING 1024 bits

03 AE 44 AE 32 C1 54 74 5B 4A 51 A9 91 86 29 DE

A8 E8 A4 1F 20 B1 D2 BB F7 53 58 6C 49 D7 14 E5

DB A5 1A 94 1E EB 34 E2 16 5B 2E 43 86 12 53 4C

23 1B E0 65 A3 A1 37 AF 8C 4C 72 86 1A E6 7C B0

ED 49 2C 43 D5 09 2B B7 1E 16 0C C8 C9 C0 93 0B

A8 77 A8 DD 38 B3 26 22 89 04 E8 AB 76 63 6D 80

85 EF 6B 7D DE 26 9B 51 54 3A C1 BD C1 86 32 59

07 FC 86 A0 34 4B 0E 57 3D DD 1D 73 FF 70 5F 58

Итоговое представление данных:

30 82 01 C9 30 82 01 35 A0 03 02 01 02 02 02 30

39 30 0A 06 08 2A 85 03 07 01 01 03 03 30 1B 31

19 30 17 06 03 55 04 03 13 10 67 6F 73 74 2E 65  |.0...U....gost.e|
78 61 6D 70 6C 65 2E 63 6F 6D 30 1E 17 0D 32 30  |xample.com0...20|
30 32 32 38 31 31 30 38 33 37 5A 17 0D 33 30 30  |0228110837Z..300|
32 32 35 31 31 30 38 33 37 5A 30 1B 31 19 30 17  |225110837Z0.1.0.|
06 03 55 04 03 13 10 67 6F 73 74 2E 65 78 61 6D  |..U....gost.exam|
70 6C 65 2E 63 6F 6D 30 81 A0 30 17 06 08 2A 85  |ple.com0..0...*.|

03 07 01 01 01 02 30 0B 06 09 2A 85 03 07 01 02

01 02 01 03 81 84 00 04 81 80 36 43 9F 06 F3 3D

0D 0A 1F 56 E1 C1 5F E9 3A 7C 41 E6 09 10 AE 0F

A2 96 D2 97 6E E0 FA F9 89 00 73 5F B5 21 DD 95

60 4D 09 25 BB 59 D8 ED 09 E2 54 4B 46 6A CC 24

5D 87 7E 05 BA 82 66 39 E5 4F 12 3E EF F3 E2 A5

CC C6 1C BE 2C FA A7 2B C6 A9 6C F5 A2 F7 BB C4

E3 E1 9F 5F 26 30 DC BF 3E 92 95 78 F5 BC 1B ED

44 0F E5 F8 9A EA 7A F9 AE 9B 28 0E 90 CF D1 C0

57 28 C4 97 E4 D0 1A C2 0D 5A A3 21 30 1F 30 1D

06 03 55 1D 0E 04 16 04 14 6E BC B2 41 82 69 A5

28 58 70 58 F9 0E 06 EB 37 94 88 09 80 30 0A 06

08 2A 85 03 07 01 01 03 03 03 81 81 00 03 AE 44

AE 32 C1 54 74 5B 4A 51 A9 91 86 29 DE A8 E8 A4

1F 20 B1 D2 BB F7 53 58 6C 49 D7 14 E5 DB A5 1A

94 1E EB 34 E2 16 5B 2E 43 86 12 53 4C 23 1B E0

65 A3 A1 37 AF 8C 4C 72 86 1A E6 7C B0 ED 49 2C

43 D5 09 2B B7 1E 16 0C C8 C9 C0 93 0B A8 77 A8

DD 38 B3 26 22 89 04 E8 AB 76 63 6D 80 85 EF 6B

7D DE 26 9B 51 54 3A C1 BD C1 86 32 59 07 FC 86

A0 34 4B 0E 57 3D DD 1D 73 FF 70 5F 58

8.4.2 Сертификат клиента

Алгоритм проверки электронной цифровой подписи — в соответствии с ГОСТ Р 34.10-2012 и длиной ключа — 512 бит.

Идентификатор кривой сертификата клиента:

id-tc26-gost-3410-2012-256-paramSetB, OID «1.2.643.7.1.2.1.1.2».

Закрытый ключ клиента:

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

Certificate SEQUENCE

tbsCertificate: TBSCertificate SEQUENCE

version: [0] EXPLICIT Version INTEGER v3 (02) OPTIONAL

serialNumber: CertificateSerialNumber INTEGER 12345 (30:39)

signature: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.2 (id_tc26_signwithdigest_ gost3410_2012_256)

issuer: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13 06 63 6C 69 65 6E 74

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString client

validity: Validity SEQUENCE

notBefore: Time CHOICE utcTime

utcTime: UTCTime 2020-02-28T11:08:37

notAfter: Time CHOICE utcTime

utcTime: UTCTime 2030-02-25T11:08:37

subject: Name CHOICE rdnSequence

rdnSequence: RDNSequence SEQUENCE OF

0: RelativeDistinguishedName SET OF

0: AttributeTypeAndValue SEQUENCE

type: AttributeType OBJECT IDENTIFIER 2.5.4.3 (id_at_commonName)

value: [UNIV 19] AttributeValue ANY

13 06 63 6C 69 65 6E 74

DEFINED BY id_at_commonName: CommonName CHOICE printableString

printableString: PrintableString client

subjectPublicKeyInfo: SubjectPublicKeyInfo SEQUENCE

algorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.1.1 (id_tc26_gost3410_2012_256)

parameters: [UNIV 16] ANY OPTIONAL

30 0B 06 09 2A 85 03 07 01 02 01 01 02

DEFINED BY id_tc26_gost3410_2012_256: GostR34102012PublicKeyParameter s SEQUENCE

publicKeyParamSet: OBJECT IDENTIFIER 1.2.643.7.1.2.1.1.2 (id_tc26_ gost3410_2012_256_paramSetB)

subjectPublicKey: BIT STRING 528 bits

04 40 D4 03 81 1A 23 5A 5B CE B6 8F 89 B0 B5 BD

67 D1 FF B8 7B C7 75 A6 83 80 B4 8F EE D9 91 83

EF AC 01 FD 8D 98 2E B6 4A 0B 2E 89 DB D3 68 9F

05 B6 93 E3 05 09 B4 B2 2D AC 89 1F C0 6C D9 8E

B4:2A

extensions: [3] EXPLICIT Extensions SEQUENCE OF OPTIONAL

0: Extension SEQUENCE

extnID: OBJECT IDENTIFIER 2.5.29.14 (id_ce_subjectKeyIdentifier)

extnValue: OCTET STRING 22 bytes

04 14 BC 5A 21 B6 1F 83 D2 07 98 9F 3D 3E 4D 72

F0 70 3D B4 2A 98

DEFINED BY id_ce_subjectKeyIdentifier: SubjectKeyIdentifier OCTET STRING 20 bytes

BC 5A 21 B6 1F 83 D2 07 98 9F 3D 3E 4D 72 F0 70

3D B4 2A 98

signatureAlgorithm: AlgorithmIdentifier SEQUENCE

algorithm: OBJECT IDENTIFIER 1.2.643.7.1.1.3.2 (id_tc26_signwithdigest_ gost3410_2012_256)

signatureValue: BIT STRING 512 bits

5B 94 DE E2 FC EA 63 66 6F C0 E7 B9 9F B1 65 FA

78 3F 84 7C 1E 8E A6 11 29 C4 34 33 22 D5 88 D7

68 5F E8 4D 03 E7 C2 CD 08 07 B8 F3 46 66 6D 05

76 C0 D5 E7 60 1D 59 49 09 45 52 C4 95 A7 5A D3

Итоговое представление данных:

30 82 01 30 30 81 DE A0 03 02 01 02 02 02 30 39

30 0A 06 08 2A 85 03 07 01 01 03 02 30 11 31 0F

30 0D 06 03 55 04 03 13 06 63 6C 69 65 6E 74 30  |0...U....client0|
1E 17 0D 32 30 30 32 32 38 31 31 30 38 33 37 5A  |...200228110837Z|
17 0D 33 30 30 32 32 35 31 31 30 38 33 37 5A 30  |..300225110837Z0|
11 31 0F 30 0D 06 03 55 04 03 13 06 63 6C 69 65  |.1.0...U....clie|
6E 74 30 5E 30 17 06 08 2A 85 03 07 01 01 01 01  |nt0^0...*.......|

30 0B 06 09 2A 85 03 07 01 02 01 01 02 03 43 00

04 40 D4 03 81 1A 23 5A 5B CE B6 8F 89 B0 B5 BD

67 D1 FF B8 7B C7 75 A6 83 80 B4 8F EE D9 91 83

EF AC 01 FD 8D 98 2E B6 4A 0B 2E 89 DB D3 68 9F

05 B6 93 E3 05 09 B4 B2 2D AC 89 1F C0 6C D9 8E

B4 2A A3 21 30 1F 30 1D 06 03 55 1D 0E 04 16 04

14 BC 5A 21 B6 1F 83 D2 07 98 9F 3D 3E 4D 72 F0

70 3D B4 2A 98 30 0A 06 08 2A 85 03 07 01 01 03

02 03 41 00 5B 94 DE E2 FC EA 63 66 6F C0 E7 B9

9F B1 65 FA 78 3F 84 7C 1E 8E A6 11 29 C4 34 33

22 D5 88 D7 68 5F E8 4D 03 E7 C2 CD 08 07 B8 F3

46 66 6D 05 76 C0 D5 E7 60 1D 59 49 09 45 52 C4

95 A7 5A D3

8.4.3 Формирование сообщения ClientHello на стороне клиента

8.4.4 Формирование сообщения ServerHello на стороне сервера

8.4.5 Формирование общего ECDHE-значения

ECDHE-ключ клиента и сервера формируется в соответствии с id-tc26-gost-3410-2012-256-paramSetA.

Закрытый ключ клиента для формирования ECDHE:

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04

Открытый ключ клиента для формирования ECDHE (см. 8.4.3):

9E 44 41 7A 31 6B 95 C5 4B C0 04 63 05 FA 60 9C

85 E5 05 78 2D 26 1B A9 87 BF F8 C7 4B EE 51 D8

3B F9 E8 35 B9 33 18 2C 70 F4 DE 50 04 75 B1 36

BC E4 D3 48 C3 05 19 0A 60 8E C1 B1 28 70 56 EB

Закрытый ключ сервера для формирования ECDHE:

B6 6B 18 AC D9 25 59 02 19 B8 8D F3 C4 E8 D2 64

84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 04

Открытый ключ сервера для формирования ECDHE (см. 8.4.4):

F8 55 F9 3A E4 0B C3 DD 2B CF DB AC 99 D4 C3 F9

D6 CF 16 ED B8 1F 87 C6 84 68 B6 1B AF 2E F6 B2

0C 18 4E D5 EC B5 46 2B 1E 18 7C 7E CB 84 40 AF

41 D7 28 AA 45 84 2F C7 DB D2 C4 74 74 85 9F D2

Выработанный общий ECDHE-ключ: на стороне клиента — на основе закрытого ключа клиента и открытого ключа сервера, на стороне сервера — на основе закрытого ключа сервера и открытого ключа клиента:

ECDHE =

D5 56 B0 BC 8F 86 E1 46 6C F1 30 D9 E7 DB 80 69

73 C1 8E E0 73 8C 33 C6 73 E0 16 17 70 E3 6B 80

8.4.6 Формирование защищенного сообщения EncryptedExtensions на стороне сервера

Далее на стороне сервера формируются сообщения, защищенные на ключах, выработанных из секретного значения server_handshake_traffic_secret (см. 5.4.2 и 5.4.3).

8.4.7 Формирование защищенного сообщения CertificateRequest на стороне сервера

8.4.8 Формирование защищенного сообщения Certificate на стороне сервера

8.4.9 Формирование защищенного сообщения CertificateVerify на стороне сервера