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

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

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

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

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

Предисловие

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

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

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

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

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

©Стандартинформ, оформление, 2020

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

а)    ключевая информация SHTS e В⁶⁴, предназначенная для зашифрования и контроля целостности сообщений, передаваемых от сервера к клиенту Данная ключевая информация используется клиентом для расшифрования и проверки целостности получаемых от сервера сообщений Ключевая информация SHTS позволяет определить следующие ключи:

-    eSHTK t В³² — ключ, предназначенный для зашифрования сообщений, направляемых сервером клиенту. Данный ключ используется клиентом для расшифрования полученных от сервера сообщений;

-    iSHTK е В³² — ключ, предназначенный для выработки имитовставки сообщений, направляемых сервером клиенту Данный ключ используется клиентом для проверки целостности полученных от сервера сообщений

Указанные ключи определяются равенствами

eSHTK = SHTS[0, ,31], iSHTK = SHTS[32,.... 63);

б)    ключевая информация CUTS е В⁶⁴, предназначенная для зашифрования и контроля целостности сообщений, передаваемых от клиента к серверу. Данная ключевая информация используется сервером для расшифрования и проверки целостности получаемых от клиента сообщений

Ключевая информация CHTS позволяет определить следующие ключи

-    еСНТК <„ В³² — ключ, предназначенный для зашифрования сообщений, направляемых клиентом серверу Данный ключ используется сервером для расшифрования полученных от клиента сообщений;

-    ЮНТК е В³² — ключ, предназначенный для выработки имитовставки сообщений, направляемых клиентом серверу Данный ключ используется сервером для проверки целостности полученных от клиента сообщений

Указанные ключи определяются равенствами

еСНТК = CHTS[0, ,31], ЮНТК = CHTS(32, .... 63]

Определенная выше ключевая информация вырабатывается клиентом и сервером в ходе выполнения протокола выработки ключей Для выработки используется общая ключевая информация Q, ключи аутентификации iPSK и/или ePSK, а также сообщения передаваемые в ходе выполнения протокола Алгоритм выработки указанной ключевой информации описывается в 5.6 1

5.2.4 Ключевая информация для протокола передачи прикладных данных

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

а)    ключевая информация SATS < В⁶⁴, предназначенная для выработки производных ключей, используемых для зашифрования и контроля целостности сообщений, передаваемых в ходе выполнения протокола передачи прикладных данных от сервера к клиенту Ключевая информация используется клиентом для расшифрования и проверки целостности получаемых от сервера сообщений;

б)    ключевая информация CATS .н В⁶⁴, предназначенная для выработки производных ключей, используемых для зашифрования и контроля целостности сообщений, передаваемых в ходе выполнения протокола передачи прикладных данных от клиента к серверу Ключевая информация используется сервером для расшифрования и проверки целостности получаемых от клиента сообщений

Определенная выше ключевая информация вырабатывается клиентом и сервером в ходе выполнения протокола выработки ключей Для выработки ключей используется общая ключевая информация Q, ключи аутентификации iPSK и/или ePSK, а также сообщения, передаваемые в ходе выполнения протокола Алгоритм выработки указанной ключевой информации описывается в 5 6 2

5.3 Идентификация абонентов

Сервер и опционально клиент должны обладать собственными идентификаторами — последовательностями октетов произвольной длины, обозначаемыми, соответственно ID_S и Ю_с.

Длины идентификаторов должны быть отличны от нуля и могут принимать произвольные натуральные значения Рекомендуется определять идентификаторы последовательностями октетов длиной не менее восьми

5.3.1 Определение идентификаторов

Идентификаторы клиента и сервера могут быть определены следующими способами:

а) при помощи сертификатов ключей проверки электронной подписи, обеспечивающих однозначное связывание идентификатора абонента с его ключом проверки электронной подписи; в этом случае в качестве идентификатора абонента выступает значение поля owner сертификата ключа проверки электронной подписи, представленное в ber-кодировке, см Р1323565 1 023—2018;

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

5.3.2 Обмен идентификаторами

Идентификаторы могут быть переданы от одного абонента к другому при помощи следующих механизмов

а)    путем направления расширения CertificateExtension, содержащего сертификат ключа проверки электронной подписи абонента, см. 5.7.2 и 5.7.3;

б)    путем направления расширения RequestldentifierExtension, содержащего идентификатор абонента, см. 5.8.5;

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

5.4 Аутентификация абонентов

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

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

а)    механизма ключей проверки электронной подписи; данный механизм позволяет реализовать как одностороннюю, так и взаимную аутентификацию

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

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

Механизм аутентификации выбирается клиентом при инициализации протокола выработки общих ключей см 5.7.1.

5.4.1 Аутентификация с использованием ключей электронной подписи

В данном криптографическом механизме аутентификация сервера (клиента) производится путем проверки клиентом (сервером) истинности следующих утверждений

а)    сервер (клиент) обладает действительным сертификатом ключа проверки электронной подписи, позволяющим однозначно связать уникальный идентификатор сервера (клиента) с ключом проверки электронной подписи; алгоритм подтверждения того, что сертификат ключа проверки электронной подписи является действительным, описывается в 5 8 4.

б)    сервер (клиент) обладает ключом электронной подписи однозначно связанным с ключом проверки электронной подписи, для сертификата которого была проверена действительность

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

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

а)    обмен сертификатами может производиться в ходе выполнения протокола выработки общих ключей;

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

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

Входе выполнения протокола выработки ключей клиент (сервер) может

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

Примечание — Запрос сертификата должен производиться с помощью расширения RequestCertifcateExtension в ходе первого или второго этапов протокола выработки общих ключей, см 5.7.1 и см. 57 2. В ответ на запрос клиента (сервера) сервер (клиент) должен направить сертификат ключа проверки электронной подписи, используя для этого расширение CertificateExtension;

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

Примечание — Указание об использовании сертификата должно направляться с помощью расширения SetCertficateExtension в ходе первого или второго этапов протокола выработки общих ключей, см 5.7.1 и 57 2 В случае указания об использовании сертификата с заданным удостоверяющим центром сервер (клиент) должен направить клиенту (серверу) сертификат ключа проверки электронной подписи, используя для этого расширение CertificateExtension,

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

Примечание — Указание номера используемого сертификата должно направляться с помощью расширения InformCertificateExtenson в ходе первого или второго этапов протокола выработки общих ключей, см 5 7 1 и 5 7 2 Направление данного расширения не подразумевает ответа от сервера (клиента)

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

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

В данном криптографическом механизме выполняется взаимная аутентификация клиента и сервера Аутентификация производится путем проверки истинности следующего утверждения

а) сервер (клиент) обладает секретным предварительно распределенным ключом аутентификации, значение которого совпадает со значением предварительно распределенного ключа аутентификации которым обладает клиент (сервер);

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

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

5.5 Формирование последовательностей октетов

Для выработки ключей шифрования и ключей выработки имитовставки, используемых в ходе выполнения протокола выработки ключей, а также ключевой информации для протокола передачи прикладных данных, используются последовательности октетов R,. R₂ и Н,. Н₂, Н₃, Н₄ и Н₅

Формирование последовательностей октетов R, и R₂ происходит в соответствии со следующими правилами

а)    последовательность октетов R, полагается равной Ser(x(Q)) способ преобразования определен в В 3.10;

б)    последовательность октетов R₂ полагается равной ID_S. где ID_S — идентификатор сервера.

в)    если сервером после формировании сообщения ServerHelloMessage был запрошен сертификат ключа проверки подписи клиента Cert_c или идентификатор клиента Ю_с. см. 5.7.2, то текущее значение последовательности октетов R₂ конкатенируется со значением ГО_С, т. е

R₂ = R₂||ID_c;

г)    если при создании сообщения ClientHelloMessage клиентом был использован идентификатор Ю|Р8К ключа аутентификации iPSK, см 5.7.1, то текущее значение последовательности октетов R, и текущее значение последовательности октетов R₂ конкатенируются со значением ключа iPSK, т е

R, = RJliPSK, R₂ = R₂||iPSK;

д)    если при создании сообщения ClientHelloMessage клиентом был использован идентификатор ID_ePSK ключа аутентификации ePSK, см 5.7.1, то текущее значение последовательности октетов R, и текущее значение последовательности октетов R₂ конкатенируются со значением ключа ePSK, т. е.

R, = R,||ePSK, R₂ = R₂||ePSK.

Примечание — В краткой форме последовательности октетов R, и R₂ могут быть записаны в виде

R_t = Ser(x(Q))||iPSK*||ePSK*. R₂ = ID_t||ID_c||iPSK*||ePSK*.

где знак «*» означает, что данная последовательность октетов является опциональной и ее включение в состав последовательностей октетов R, и/или R₂ зависит от действий клиента и сервера при создании сообщений CtientHeUoMessage и ServerHelloMessage

Формирование последовательностей октетов Н,, Н₂, Н₃, Н₄ и Н₅ происходит по следующим правилам

1    Последовательность октетов Н, формируется следующим образом

-    последовательность октетов Н, полагается равной сообщению ClientHelloMessage

-если клиентом после отправки сообщения ClientHelloMessage отправлялись расширения ExtensionMessagel.    , ExtensionMessageNc то текущее значение последовательности октетов Н, кон

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

Н, = H,||ExtensionMessage1|| ||ExtensionMessageNc

-текущее значение последовательности октетов Н, объединяется с сообщением ServerHelloMessage, то есть Н, = H^IServerHelloMessage

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

2    Последовательность октетов Н₂ формируется следующим образом

-    последовательность октетов Н₂ определяется равенством Нг = Н,;

-если сервером после сообщения ClientHelloMessage отправлялись расширения ExtensionMessagel.    ,    ExtensionMessageNs то текущее значение последовательности октетов Н₂ кон

катенируется с указанными расширениями в незашифрованном воде в порядке их отправления, т е

Н₂ = H₂||ExtensionMessage1|| ||ExtensionMessageNs

3    Последовательность октетов Н₃ формируется следующим образом

-    последовательность октетов Н₃ определяется равенством Н₃ = Н₂:

-    текущее значение последовательности октетов Н₃ конкатенируется с отправленным сервером клиенту сообщением Verify Message в незашифрованном (расшифрованном) виде, т е

Нз = H₃||VerifyMessage

4    Последовательность октетов Н₄ формируется следующим образом

-    последовательность октетов Н₄ определяется равенством Н₄ = Н₃;

-если клиентом в ответ на сообщение ServerHelloMessage отправлялись расширения Extension Messaged,    , ExtensionMessageCc, то текущее значение последовательности октетов Н₄

конкатенируется с указанными расширениями в незашифрованном виде в порядке их отправления, т е

Н₄ = H₄||ExtensionMessageC1||...||ExtensionMessageCc

5    Последовательность октетов Н₅ формируется следующим образом

-    последовательность октетов Н₅ определяется равенством Н₅ = Н₄,

-    текущее значение последовательности октетов Н₅ конкатенируется с отправленным клиентом серверу сообщением VerifyMessage в незашифрованном (расшифрованном) виде. т. е.

^н5 ⁼ H₅||VenfyMessage

Примечания

1    Последовательности октетов Н,. ... Н₅ представляют собой конкатенации сообщений и расширений, последовательно передаваемых в ходе выполнения протокола выработки ключей. Схема процесса выработки последовательностей октетов Н,.... Н₅ изображена на рисунке 3.

2    Поскольку отправка расширений является опциональной, то последовательности октетов Н, и Н₂. а также Н₃ и Н₄, могут совпадать

ClientHel loMessage Extension Message 1

ExtensK>oMessageNc ServerHeBoMessage ExtensiooMessage 1

ExtensionMessageNs VerifyMessage ExtensionMessageC 1

Extens»onMessageCc

VerifyMessage

Рисунок 3 — Схема формирования последовательностей октетов

5.6 Формирование ключевой информации

В этом подразделе описываются алгоритмы формирования ключевой информации, определенной в 5.2.

5.6.1 Формирование ключей шифрования и ключей выработки имитовставки

Ключи шифрования eSHTK, еСНТК и ключи выработки имитовставки iSHTK, iCHTK вырабатываются клиентом и сервером в ходе выполнения протокола выработки ключей

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

При формировании ключей eSHTK, еСНТК и iSHTK, iCHTK используется общая ключевая информация Q_; а также определенные в 5.5 последовательности октетов R, и Н,. Н₃

Для формирования ключей необходимо выполнить последовательность действий

а)    вычислить последовательность октетов К с В⁶⁴, определяемую равенством

К = Streebog^R,);

б)    вычислить последовательность октетов SHTS ^ В⁶⁴ удовлетворяющую равенству

SHTS = НМАС₅₁₂(К, Streebog₅₁₂(H₁))₁ и определить ключи eSHTS и iSHTS равенствами

eSHTK = SHTS(0. .. . 31]. iSHTK = SHTS[32, ... , 63];

в)    вычислить последовательность октетов CHTS е В⁶⁴, удовлетворяющую равенству

CHTS = НМАС₅₁₂(К, Streebog5₁₂(H₃)); и определить ключи eCHTS и tCHTS равенствами

еСНТК = CHTS(0, ... 31]. iCHTK = CHTS[32. ... 63].

Описанная выше последовательность действий схематично изображена на рисунке 4

Рисунок 4 — Схема выработки ключей для шифрования сообщений в ходе выполнения протокола формирования общей ключевой информации

5.6.2 Формирование ключей шифрования и ключей выработки имитовставки протокола передачи прикладных данных

Ключевая информация CATS, SATS является целью выполнения протокола выработки ключей При формировании указанной ключевой информации используется алгоритм PRF_TLS_ GOSTR3411_2012_512, регламентируемый Р 50.1.113—2016, а также общая ключевая информация Q и последовательности октетов R₂, Н₅, определенные в 5.5.

Для формирования ключевой информации CATS, SATS необходимо выполнить последовательность действий:

а)    вычислить последовательность октетов Те В⁶⁴, определяемую равенством

Т = НМАС₅₁₂ (Ser(x(Q)), R₂);

б)    вычислить последовательность октетов А₀ < В⁶⁴ определяемую равенством

Aq = Streebog₅₁₂ (Н₅);

в)    вычислить последовательность октетов А, е В⁶⁴, определяемую равенством

А, = НМАС₅₁₂ (Т, Аф);

г)    определить последовательность октетов CATS с В⁶⁴равенством

CATS = НМАС₅₁₂(Т, AJIAq).

в котором операция сжатия применяется последовательно сначала к последовательности октетов А,, а потом к последовательности А^

д)    вычислить последовательность октетов А₂ е В⁶⁴, определяемую равенством

А₂ = НМАС₅₁₂ (Т, А,);

е)    определить последовательность октетов SATS е В⁶⁴ равенством

SATS = НМАС₅₁₂ (Т, AjHAo),

в котором операция сжатия применяется последовательно сначала к последовательности октетов А,, а потом к последовательности Aq

Описанная выше последовательность действий схематично изображена на рисунке 5

5.7 Описание протокола

В этом подразделе дается детальное описание последовательности действий, производимых клиентом и сервером в ходе выполнения протокола выработки ключей

Действия, описываемые в 5.7.1 и 5 7 3. выполняются клиентом, действия, описываемые в 5 7 2 и 5.7.4, выполняются сервером

5.7.1 Формирование сообщения ClientHelloMessage

На первом этапе протокола выработки ключей клиентом выполняется процедура инициализации, в ходе которой клиент формирует сообщение ClientHelloMessage. см В 5.1, а также, при необходимости, дополнительные расширения

Для формирования сообщения ClientHelloMessage клиент выполняет последовательность действий

а)    клиент вырабатывает случайную последовательность октетов длиной 32 октета и помещает ее в поле ClientHelloMessage random,

б)    клиент выбирает идентификатор ID_e одной из эллиптических кривых, определяемых типом данных EllipticCurvelD, см В 3.9;

Рисунок 5 — Схема выработки ключей для протокола передачи прикладных данных

в)    клиент вырабатывает случайное целое число к_с, удовлетворяющее неравенствам 0 < к_с < q, где q порядок точки Р, определяемой параметрами эллиптической кривой выбранной клиентом на предыдущем шаге

Примечания

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

2    Использование одного и того же генератора случайных чисел для выработки значения к_с и случайной последовательности октетов длиной 32 октета может быть потенциально опасным — нарушитель может использовать передаваемые в открытом виде элементы последовательности для определения секретного значения к<. В связи с этим рекомендуется использование различных генераторов случайных чисел для генерации значения к_с и случайной последовательности октетов длиной 32 октета В случае невозможности применения различных генераторов. рекомендуется использовать генератор удовлетворяющий Р 1323565 1 012—2017,

г)    клиент вычисляет точку кривой Р_с = к_сР и помещает координаты вычисленной точки в поля структуры ClientHelloMessage EllipticCurvePoint, т е

ClientHelloMessage point id = Ю_Е;

ClientHelloMessage point х = Ser(x(P_c));

ClientHelloMessage pointy = Ser(y(P_c));

д)    если клиент хочет использовать для аутентификации сервера предварительно распределенный ключ аутентификации ePSK_; то клиент определяет

ClientHelloMessage idpsk present = isPresent;

ClientHelloMessage idpsk type = ePSKKey

ClientHelloMessage idpsk length = Len(ID_ePSK),

ClientHelloMessage idpsk id = ID_ePSK,

где ID_ePSK — идентификатор ключа ePSK, а значения isPresent и notPresent определены в В 3.2, В противном случае клиент определяет

ClientHelloMessage idpsk present = notPresent

Примечания

1    В случае аутентификации по ключу ePSK аутентификация сервера с использованием ключа аутентификации iPSK или сертификата ключа проверки электронной подписи, см 5.21, может не проводиться

2    Если клиент хочет выполнить аутентификацию сервера как с использованием ключа аутентификации ePSK так и с использованием сертификата ключа проверки подписи, то после отправки сообщения ClientHelloMessage клиент должен сформировать и направить серверу расширение RequestCertificateExtens«on;

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

ChentHe По Message idpsk present = isPresent;

ClientHelloMessage idpsk type = iPSKKey ClientHelloMessage idpsk length = Len( ID_lPSK);

ClientHelloMessage idpsk id = ID_|PSK,

где ID,_PSK — идентификатор ключа iPSK, а значения isPresent и notPresent определены в В 3 2 В противном случае клиент определяет

ClientHelloMessage idpsk present = notPresent

Примечания

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

2    В случае аутентификации по ключу PSK аутентификация сервера с использованием ключа аутентификации ePSK или сертификата ключа проверки электронной подписи, см 5.2.1, может не проводиться

3    Если клиент хочет выполнить аутентификацию сервера как с использованием ключа аутентификации iPSK так и с использованием сертификата ключа проверки подписи, то после отправки сообщения ClientHelloMessage клиент должен сформировать и направить серверу расширение RequeslCertrficateExtension.

4    Если клиент не указал ни одного идентификатора предварительно распределенного ключа, то клиент обязан выполнить аутентификацию сервера с использованием сертификата ключа проверки подписи;

ж)    клиент определяет количество расширений N_c, которые будут направлены им серверу, и помещает это число в поле ClientHelloMessage countOfExtensions;

з)    клиент выбирает криптограф^еский механизм контроля целостности сообщений и расширений, которые будут передаваться в незашифрованном виде, идентификатор выбранного криптографического механизма должен определяться перечислением CryptoMechamsm и помещаться клиентом в поле ClientHelloMessage algorithm

Примечания

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

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

3    Клиент может поместить в попе ClientHelloMessage algorithm значение идентификатора с указанием параметров криптографических механизмов, используемых для обеспечения конфиденциальности и целостности сообщений и расширений, передаваемых в зашифрованном виде; данные значения могут быть учтены сервером при выборе значения идентификатора криптографических механизмов, выбираемого сервером в ходе формирования сообщения ServerHelloMessage см 5 7.2,

и)    в соответствии с описанным в В.5.1 методом созданное сообщение ClientHelloMessage представляется в виде последовательности октетов и передается транспортному протоколу для отправки серверу в незашифрованном виде.

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

RequestCertificateExtension или SetCertificateExtension;

RequestldentifierExtension,

KeyMechamsm Extension

Для обеспечения целостности формируемых клиентом расширений используется алгоритм контроля целостности, установленный клиентом в поле ClientHelloMessage algonthm После формирования расширения передаются транспортному протоколу для отправки серверу в незашироваином виде

Примечание — Выбранный клиентом способ аутентификации сервера влияет на содержимое обязательного сообщения VenfyMessage, отправляемого сервером клиенту, см. 5 7 2 В случае, когда клиентом выбрана аутентификация по предварительно распределенному ключу iPSK или ePSK. отправляемое сервером сообщение VenfyMessage всегда содержит код целостности и выполнено

VenfyMessage mac present = isPresent

В случае, когда идентификаторы предварительно распределенных ключей в сообщении CJientHelloMessage не указаны, либо клиентом добавлено расширение RequestCertificateExtension, отправляемое сервером сообщение VerifyMessage содержит значение электронной подписи и

VerifyMessage sign present = isPresent.

5.7.2 Формирование сообщения ServerHelloMessage

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

При получении от клиента сообщения ClientHelloMessage сервер выполняет следующие проверки

а)    сервер проверяет что значение поля ClientHelloMessage algorithm содержит константу определяемую типом данных CryptoMechamsm Если это не так, то сервер отправляет клиенту сообщение AlertMessage со значением unsupportedCryptoMechanism и завершает сеанс защищенного взаимодействия

Примечание — Сообщение AlertMessage со значением ошибки unsupportedCryptoMechanism может отправляться клиенту также в том случае, когда сервер не поддерживает реализацию указанного алгоритма.

б)    если значение поля ClientHelloMessage idpsk present содержит константу isPresent, то выполняются следующие проверки

1)    сервер определяет тип переданного идентификатора ключа аутентификации, содержащийся в поле ClientHelloMessage idpsk type

2)    если идентификатор ключа, содержащийся в поле ClientHelloMessage idpsk id, отвергается сервером, то сервер отправляет клиенту сообщение AlertMessage со значением wrongPreSharedKey и завершает сеанс защищенного взаимодействия;

Примечание — Причины, по которым сервер может отвергнуть ключ аутентификации ePSK или iPSK настоящими рекомендациями не регулируются В качестве примеров таких причин могут выступать неизвестное значение идентификатора ключа, исчерпание временного интервала использования ключа, превышение числа допустимых использований ключа, компрометация ключа и т. п ;

3)    если значение поля ClientHel to Message algorithm содержит в себе значение алгоритма выработки имитовставки то сервер выполняет контроль целостности сообщения ClientHelloMessage с использованием указанного алгоритма и ключа аутентификации ePSK или iPSK; в случае нарушения целостности сервер отправляет клиенту сообщение AlertMessage со значением wrongIntegntyCode и завершает сеанс защищенного взаимодействия, в случае успешной проверки целостности сервер переходит к перечислению г);

в)    сервер выполняет контроль целостности сообщения ClientHelloMessage с использованием алгоритма бесключевого хеширования; в случае нарушения целостности сервер отправляет клиенту сообщение AlertMessage со значением wronglntegrityCode и завершает сеанс защищенного взаимодействия,

г)    сервер проверяет корректность идентификатора эллиптической кривой, содержащегося в поле ClientMessageHello point id, если значение данного идентификатора не является допустимым, то сервер отправляет клиенту сообщение AlertMessage со значением unsupportedEllipticCurvelD и завершает сеанс защищенного взаимодействия:

д)    используя алгоритм из 5.9 1, сервер проверяет корректностьтсмки эллиптической кривой Р_с, содержащейся в структуре ClientHelloMessage point, в случае нарушения корректности точки эллиптической кривой сервер отправляет клиенту сообщение AlertMessage со значением wrongEllipticCurvePoint и завершает сеанс защищенного взаимодействия;

е)    в случае если поле ClientHelloMessage countOfExtensions содержит отличное от нуля значение, то сервер переходит к получению из канала связи и проверке целостности полученных от клиента расширений, используя при этом алгоритм, определенный значением поля ClientHelloMessage algorithm В случае, если целостность хотя бы одного расширения нарушена, сервер отправляет клиенту сообщение AlertMessage со значением wronglntegrityCode и завершает сеанс защищенного взаимодействия,

ж)    для каждого из полученных расширений сервер проверяет корректность содержащегося в расширении запроса; в случае неверного запроса или отсутствии возможности удовлетворить запрос клиента, сервер отправляет клиенту сообщение AlertMessage с информацией об ошибке и завершает сеанс защищенного взаимодействия Коды возможных ошибок приводятся в 5 8

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

После успешного прохождения всех перечисленных выше проверок сервер формирует сообщение ServerHelloMessage и, в случае необходимости, расширения, см 5.8

Для этого сервер выполняет следующие действия

з)    сервер вырабатывает случайную последовательность октетов длиной 32 октета и помещает ее в поле ServerHelloMessage random;

и)    сервер вырабатывает случайное целое число к_s, удовлетворяющее неравенствам 0 < к* < q, где q порядок точки Р определяемой параметрами эллиптической кривой, идентификатор которой выбран клиентом и содержится в поле ClientHelloMessage point,id.

Примечание — Высказанные ранее при формировании сообщения ClientHelloMessage положения, см 5 71. примечание к перечислению в), о необходимости использования различных генераторов случайных чисел для выработки значения к. и случайной последовательности октетов длиной 32 октета, также должны применяться при формировании сообщения ServerHelloMessage;

к)    сервер вычисляет точку кривой P_s = 1цР и помещает координаты вычисленной точки в поля структуры ServerHelloMessage EllipticCurvePoint, т е

ServerHelloMessage point id = ClientHelloMessage point id,

ServerHelloMessage point x = Ser(x(P_s)),

ServerHelloMessage point у = Ser(y(P_s));

л)    сервер определяет количество расширений N_s, которые будут направлены им клиенту и помещает это число в поле ServerHelloMessage countOfExtensions.

м)    сервер выбирает криптографические механизмы, используемые для шифрования и контроля целостности передаваемых далее сообщений и расширений; идентификатор выбранных криптографических механизмов помещается сервером в поле ServerHelloMessage algorithm

Примечания

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

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

н)    сервер передает сформированное сообщение Serve rHelloMessage транспортному протоколу для отправки клиенту в незашифрованном виде Для контроля целостности сообщения ServerHelloMessage используется алгоритм, указанный в поле ClientHelloMessage algorithm,

о)    согласно 5 2 2 сервер вырабатывает общую ключевую информацию Q. определяемую равенством Q = ck_sP_c, где значение кофактора с определяется параметрами используемой эллиптической кривой,

п)    сервер вырабатывает ключевую информацию SHTS — для этого сервер формирует определенную в 5 5 последовательность октетов Н, и применяет определенный в 5.6.1 алгоритм формирования ключевой информации,

р)    если поле idpsk present сообщения ClientHelloMessage не содержит значение isPresent или клиентом направлено одно из расширений RequestCertificateExtension или SetCertificateExtension, то сервер выполняет следующие действия:

1)    сервер выбирает ключ проверки электронной подписи Q_s, который будет использован клиентом для аутентификации сервера, если клиентом направлено расширение RequestCertificateExtension или SetCertificateExtension, то выбор ключа Qj проводится с учетом значений, помещенных клиентом в соответствующее расширение В случае отсутствия у сервера ключ проверки электронной подписи Q_$l удовлетворяющего запрашиваемым клиентом требованиям, то сервер отправляет клиенту сообщение AlertMessage с информацией об ошибке, см. В 3.15, и завершает сеанс защищенного взаимодействия

Примечание — Факт того, что значения, указанные клиентом в расширении, являются корректными, проверен сервером ранее в перечислении ж);

2)    за исключением случая, когда выполнено равенство SetCertificateExtension certproctype = number, сервер формирует

либо расширение CertificateExtension, содержащее сертификат ключа проверки электронной подписи О,.

либо расширение informCertificateExtension, содержащее номер предварительно распределенного сертификата ключа проверки электронной подписи О*;

Содержание

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

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

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

4    Обозначения...............................................................................................................................................

5    Протокол выработки ключей......................................................................................................................

51 Общие сведения..................................................................................................................................

5 2 Ключевая система ..............................................................................................................................

5 3 Идентификация абонентов.................................................................................................................

5 4 Аутентификация абонентов.................................................................................................................

5 5 Формирование последовательностей октетов...................................................................................

5.6    Формирование ключевой информации.............................................................................................

5.7    Описание протокола.............................................................................................................................

5 8 Формирование и проверка корректности расширений ...................................................................

5    9 Вспомогательный алгоритм проверки точки эллиптической кривой................................................

6    Протокол передачи прикладных данных .................................................................................................

61 Основные задачи ..............................................................................................................................

6    2 Ключевая система ..............................................................................................................................

6 3 Параметры протокола..........................................................................................................................

6 4 Алгоритм преобразования ключевой информации ........................................................................

6 5 Алгоритмы выработки производных ключей......................................................................................

6    6 Протокол выработки ключа аутентификации iPSK............................................................................

7    Протокол транспортного уровня................................................................................................................

7.1    Основные сведения..............................................................................................................................

7.2    Параметры протокола .........................................................................................................................

7.3    Алгоритм формирования уникальных номеров фреймов ..............................................................

7    4 Алгоритм формирования фрейма......................................................................................................

7.5 Алгоритм расшифрования фрейма....................................................................................................

Приложение А (справочное) Типовые схемы реализации протокола выработки ключей

с аутентификацией абонентов.........................................................................................

А1 Схема аутентификации на основе предварительно распределенного ключа ...............................

А 2 Схема аутентификации на основе ключа проверки электронной подписи...................................

АЗ Схема аутентификации на основе предварительно распределенных ключей

проверки электронной подписи..........................................................................................................

Приложение Б (справочное) Механизмы формирования предварительно распределенных ключей

Б 1 Основные положения...........................................................................................................................

Б 2 Идентификация участников защищенного взаимодействия ..........................................................

Б.З Операции в конечном поле Р₂ш.......................................................................................................

Б 4 Ключевая система ..............................................................................................................................

Приложение В (обязательное) Форматы передаваемых данных..............................................................

В1 Основные положения...........................................................................................................................

В 2 Базовые типы данных..........................................................................................................................

В З Перечислимые и служебные типы......................................................................................................

В 4 Формат сообщений транспортного протокола...................................................................................

В.5 Формат сообщений протоколов сеансового уровня..........................................................................

В 6 Формат расширений ...........................................................................................................................

Приложение Г (справочное) Рекомендуемые значения параметров защищенного взаимодействия Библиография...............................................................................................................................................

после этого сервер передает сформированное расширение транспортному протоколу для отправки клиенту в зашифрованном виде, для шифрования и контроля целостности сформированного расширения используются криптографические механизмы, указанные в поле ServerHelloMessage algorithm, и выработанная ранее ключевая информация SHTS.

Примечание — Случай равенства SetCertificateExtension certproctype = number означает, что клиент обладает сертификатом ключа проверки электронной подписи сервера и в явном виде указывает его номер. В этом случае передача сертификата от сервера к клиенту является избыточной.

с)    если сервер хочет аутентифицировать клиента с помощью механизма электронной подписи, сервер формирует расширение RequestCertificateExtension или SetCertificateExtension. содержащее запрос сертификата ключа проверки электронной подписи клиента и передает сформированное расширение транспортному протоколу для отправки клиенту в зашифрованном виде, для шифрования и контроля целостности передаваемого расширения используются криптографические механизмы, указанные в поле ServerHelloMessage algorithm, и выработанная ранее ключевая информация SHTS;

т)    в случае необходимости, в соответствии с 5.8, сервером могут быть сформированы расширения

RequestldentifierExtension;

KeyMechamsmExtensron

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

у)    сервер формирует сообщение VerifyMessage Для этого он выполняет следующие действия

1)    если ранее, см перечисление р). сервером определен ключ проверки электронной подписи Q_s, то сервер формирует электронную подпись под последовательностью октетов Н₂, см. 5.5. и помещает электронную подпись в сообщение VerifyMessage, т е.

VerifyMessage sign present = isPresent;

VerifyMessage sign length = len;

VerifyMessage sign code = Sign(d_s, Streetxjg^ (H₂)),

где d_$ — ключ электронной подписи сервера, соответствующий ключу проверки подписи Q,, а len — размер электронной подписи определяемый ключом проверки подписи Q* В противном случае сервер определяет значение

VerifyMessage sign present = notPresent;

2)    если клиентом в составе сообщения ClientHelloMessage был использован идентификатор предварительно распределенного ключа iPSK или ePSK то сервер формирует код целостности под последовательностью октетов Н₂, см 5 5, и помещает код целостности в сообщение VerifyMessage, т е.:

VenfyMessagemac present = isPresent;

VerifyMessage mac length = 16,

VerifyMessage mac code = Streebog₅₁₂ (H₂)[0, ... ,15].

В противном случае сервер определяет значение

VenfyMessagemac present = notPresent,

ф)    после формирования сообщения VerifyMessage сервер передает его транспортному протоколу для отправки клиенту в зашифрованном виде, для шифрования и контроля целостности передаваемого сообщения VerifyMessage используются криптографические механизмы, указанные в поле ServerHelloMessage algorithm, и выработанная ранее ключевая информация SHTS

5.7.3 Завершающие действия клиента

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

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

а) в случае получения сообщения AlertMessage клиент завершает сеанс защищенного взаимодействия, в противном случае клиент переходит к анализу полученного сообщения ServerHelloMessage

Введение

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

Определяемые механизмы могут быть отнесены к сеансовому и транспортному уровням модели взаимосвязи открытых систем (далее — ВОС) согласно ГОСТ Р ИСО/МЭК 7498-1 и предназначены для аутентификации взаимодействующих абонентов, а также обеспечения целостности и, при необходимости, конфиденциальности передаваемой информации

Механизмы формирования и обработки информации на прикладном уровне модели ВОС в настоящем документе не рассматриваются Защищенное взаимодействие на сеансовом уровне осуществляется путем выполнения сеансов связи В ходе каждого сеанса связи происходит последовательное выполнение двух криптографических протоколов

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

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

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

Рисунок 1 — Схема информационного обмена

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

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

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

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

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

Information technology Cryptographic data security Cryptographic mechanisms of secure interactions of control and

measuring devices

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

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

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

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

Описываемые в настоящем документе механизмы могут применяться в средствах криптографической защиты информации (далее — СКЗИ) всех классов, определяемых Р 1323565 1.012—2017.

Соответствие изложенным в Р1323565 1 012—2017 принципам позволяет реализовать механизм регулярного изменения ключевой информации используемой для обеспечения целостности и, при необходимости, конфиденциальности передаваемой информации

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология Взаимосвязь открытых систем Базовая эталонная модель Часть 1 Базовая модель

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

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

Р 1323565 1 004—2017 Информационная технология Криптографическая защита информации Схемы выработки общего ключа с аутентификацией на основе открытого ключа

Р 1323565 1 005—2017 Информационная технология Криптографическая защита информации Допустимые объемы материала для обработки на одном ключе при использовании некоторых вариантов режимов работы блочных шифров в соответствии с ГОСТ Р 34 13—2015

Р 13235651.012—2017 Информационная технология Криптографическая защита информации Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации Р 1323565 1 017—2018 Информационная технология Криптографическая защита информации Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования

Р 1323565 1 019—2018 Информационная технология Криптографическая защита информации Криптографические механизмы аутентификации и выработки ключа фискального признака для применения в средствах формирования и проверки фискальных признаков обеспечивающих работу контрольно-кассовой техники, операторов и уполномоченных органов обработки фискальных данных

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

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

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

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

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

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

3.1 абонент: Участник информационного, в том числе защищенного криптографическими методами сетевого взаимодействия

3 2 действительный сертификат открытого ключа; СОК: Сертификат ключа проверки электронной подписи, срок действия которого не истек, электронная подпись которого проверяется корректно, а сфера применения сертификата допускает его использование для аутентификации и выработки общего ключа,

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

3 4 ключ проверки электронной подписи: Уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи.

3 5 ключ электронной подписи: Уникальная последовательность символов, предназначенная для создания электронной подписи

3 6 октет: Символ, который может быть представлен 8 виде двоичной последовательности длины восемь

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

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

3    9 сервер: Абонент, являющийся источником установления соединения в информационном взаимодействии, отвечающий на запрос клиента

310 сериализация: Процесс перевода структуры данных в последовательность октетов конечной длины

3.11    сертификат ключа проверки электронной подписи: Электронный документ или документ на бумажном носителе, выданный удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающий принадлежность ключа проверки электронной подписи владельцу сертификата ключа проверки электронной подписи

3.12    удостоверяющий центр: Юридическое лицо или индивидуальный предприниматель, осуществляющий функции по созданию и выдаче сертификатов ключей проверки электронной подписи, а также иные функции предусмотренные [1]

313    электронная подпись: Информация в электронной форме которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица подписывающего информацию

314    эллиптическая кривая: Множество решений уравнения специального вида, образующее конечную группу, в которой реализуется протокол выработки общих ключей

3.15 фрейм: Последовательность октетов имеющая внутреннюю логическую структуру и являющаяся единицей обмена информацией между абонентами

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

В настоящих рекомендациях использованы следующие обозначения V*    — множество всех двоичных последовательностей конечной длины, включая последо

вательность нулевой длины;

V^s    — множество всех двоичных последовательностей, состоящих в точности из s элементов

В*    — множество всех последовательностей октетов конечной длины, включая последова

тельность нулевой длины,

B^s    — множество всех последовательностей октетов, состоящих в точности из s октетов, последовательность октетов о е В⁵ записывается в виде о = (о₀.....о_$ - ,). где каждая

из координат о₀.....o_s - , принадлежит множеству V⁸;

Len(s)    — функция, возвращающая в качестве значения длину последовательности октетов

о е B^s, т. е для о = (о₀,.... о₅ - ,) выполнено равенство Len(o) = s; о[п]    — операция выбора из последовательности октетов о с B^s заданного октета с индексом

л. т е для о = (о₀...., о₅ - где 0 s n < s, выполнено равенство о[п] = о_п, о[п,.., т] — для целых чисел 0 s n s т операция выбора из последовательности октетов о «= В* подпоследовательности начинающейся с индекса п и заканчивающейся индексом m, т е

для о = (о₀,... ,о_п! ... , о_т,... ,о₅- ,) выполнено равенство о[п.....т] = (о_п,..., о_т);

Msb_n(o)    — функция, возвращающая подпоследовательность октетов, состоящую из п октетов со

старшими номерами последовательности октетов о < В⁵, т. е для о = (о₀, .... o_s - ,) выполнено равенство Msb_n(o) = o(s - n,... , s - 1J;

Ser(t)    — последовательность октетов конечной длины, являющаяся результатом сериализа

ции одной из структур данных определяемых в приложении В, р, q    —простыечисла.

Fp"    — для натурального числа п и простого числа р конечное поле из р^п элементов:

F₂"[x]    — кольцо многочленов от одной переменной с коэффициентами из конечного поля F₂«;

F₂*»[^x. у]    — кольцо многочленов от двух переменных х и у с коэффициентами из конечного поля

F₂n;

Е    — эллиптическая кривая, определенная над полем F_p в канонической форме Вейерш-

трасса либо в форме скрученной кривой Эдвардса см Р 1323565 1 024—2019; а. b    — элементы поля F_p, являющиеся коэффициентами эллиптической кривой, заданной в

канонической форме Вейерштрасса сравнением у² = х³ + ах + b (modp); е, d    — элементы поля F_p, являющиеся коэффициентами эллиптической кривой, заданной в

форме скрученной кривой Эдвардса сравнением eu² + v² = 1 + di^v² (modp);

—    нейтральный элемент группы точек эллиптической кривой Е (бесконечно удаленная точка);

—    точки эллиптической кривой Е, определяемые парой координат (элементов поля Fp), либо парой (х,у) в случае кривой, заданной в канонической форме Вейерштрасса. либо парой (u,v) в случае кривой, заданной в форме скрученной кривой Эдвардса:

—    функция, возвращающая в качестве значения первый элемент пары координат, определяющей точку Q эллиптической кривой, либо х, для тсмки принадлежащей кривой, заданной в канонической форме Вейерштрасса либо и, для точки принадлежащей кривой, заданной в форме скрученной кривой Эдвардса,

—    функция, возвращающая в качестве значения второй элемент пары координат, определяющей точку Q эллиптической кривой либо у. для точки принадлежащей кривой заданной в канонической форме Вейерштрасса либо v, для точки принадлежащей кривой, заданной в форме скрученной кривой Эдвардса.

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

—    последовательности октетов, определяющие идентификаторы, соответственно, клиента и сервера

—    идентификаторы предварительно распределенных ключей аутентификации см 5.2;

—    алгоритм зашифрования одного блока информации М на ключе К с помощью алгоритма блочного шифрования; перечень допустимых алгоритмов блочного шифрования определяется в В 3.8;

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

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

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

—    регламентируемая ГОСТ Р 34.11-2012 бесключевая функции хэширования «Стри-бог» с длиной блока п бит, где величина п принимает значение 256 либо 512;

—    обозначение результата применения произвольной бесключевой функции хэширования к сообщению М, используемое на содержащихся в настоящих рекомендациях рисунках,

—    алгоритм выработки имитовставки НМАС с длиной кода п бит, регламентируемый рекомендациями Р 50.1.113—-2016;

—    алгоритм выработки имитовставки под сообщением М на ключе К с использованием синхропосылки I (использование синхропосылки является опциональным); перечень допустимых алгоритмов выработки имитовставки определяется в В 3 8,

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

—    сертификат ключа проверки электронной подписи клиента и, соответственно, сервера,

—    алгоритм выработки электронной подписи под сообщением М с помощью ключа электронной подписи d, перечень допустимых алгоритмов выработки электронной подписи определяется в В.3.8;

—    алгоритм проверки электронной подписи s под сообщением М с помощью ключа проверки электронной подписи Q, перечень допустимых алгоритмов проверки электронной подписи определяется в В.3.8;

—    булевы переменные, принимающее значения соответственно, «истина» и «ложь», и являющиеся результатом проверки электронной подписи и/или проверки совпадения имитовставки:

—    функция проверяющая действительность сертификата х ключа проверки электронной подписи и возвращающая «истину» в случае действительности сертификата и «ложь» в противном случае

5 Протокол выработки ключей

5.1 Общие сведения

Цель протокола выработки ключей заключается в установлении соединения и выработке клиентом и сервером общей ключевой информации, предназначенной для зашифрования, расшифрования и контроля целостности передаваемой на прикладном уровне информации В основу протокола положена схема выработки общего ключа с аутентификацией на основе открытого ключа «Эхинацея-З», описываемая Р 1323565 1 004—2017.

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

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

Кливн!    Сервер

формирует CbentltelloMessage ExtensionMessage •

ExtensionMessage*

отправляет    —¥    получает и проверяет

формирует

ServorHelloMossago

{ExtensionMessage}*

... *

{ExtensionMessage}*

{VerifyMossage} получает и проверяет <—    отправляет

формирует {ExtensionMessage}*

{Extension Message}*

(VenfyMessage)

отправляет    —*    получает и проверяет

Рисунок 2 — Обмен сообщениями в ходе выполнения протокола выработки ключей

Примечание — На рисунке 2 сообщения которые являются опциональными, отмечены знаком «*»; сообщения, которые передаются в зашифрованном виде, заключены в фигурные скобки, ExtensionMessage обозначает одно из расширений, определяемых в В 6

В случае возникновения ошибки абонент (клиент или сервер), обнаруживший ошибку, отправляет сообщение AlertMessage, после чего следует реакция определяемая порядком поведения абонента при получении сообщения об ошибке, см В 5 5.

Протокол выработки ключей реализуется с использованием арифметических операций в группе точек эллиптической кривой Е. удовлетворяющей требованиям, предъявляемым к эллиптическим кривым в ГОСТ Р 34 10—2012, раздел 5, и являющейся параметром протокола Для реализации протокола выработки ключей рекомендуется использование эллиптических кривых, определяемых как в канонической форме, так и в форме скрученных кривых Эдвардса см В 3 9.

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

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

Описываемый протокол выработки ключей представляет собой объединение нескольких подходов к выработке общей ключевой информации, основанных на различных принципах аутентификации абонентов Различные типы контрольных и измерительных устройств, в силу своих технических и эксплуатационных особенностей, могут следовать рекомендуемой последовательности действий но реализовывать при этом только один из возможных принципов аутентификации В приложении А приводятся типовые схемы реализации протокола выработки ключей

5.2 Ключевая система

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

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

5.2.1    Ключи аутентификации

В протоколе выработки ключей могут быть использованы следующие ключи аутентификации d_c с F_q— ключ электронной подписи клиента, удовлетворяющий ГОСТ Р 34 10—2012, раздел 5, Qg е Е — ключ проверки электронной подписи клиента, математически связанный с ключом электронной подписи d_c и удовлетворяющий ГОСТ Р 34 10—2012, раздел 5. корректность ключа проверки электронной подписи клиента и его однозначное соответствие идентификатору клиента Ю_с должны гарантироваться сертификатом Cert_c ключа проверки электронной подписи;

d_s е F_q — ключ электронной подписи сервера удовлетворяющий ГОСТ Р 34.10-2012, раздел 5;

< Е — ключ проверки электронной подписи сервера математически связанный с ключом электронной подписи сервера d_s и удовлетворяющий ГОСТ Р 34 10—2012, раздел 5; корректность ключа проверки электронной подписи сервера и его однозначное соответствие идентификатору сервера ID_S должны гарантироваться сертификатом Cert^ ключа проверки электронной подписи,

ePSK t В^$ — предварительно распределенный общий для клиента и сервера ключ аутентификации длиной s октетов, где s е {32, ... , 64}, ключ ePSK является опциональным;

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

Алгоритм выработки ключа аутентификации IPSK и связывания данного ключа с идентификатором ID_jPSK описывается в 6 6. Рекомендации по выработке предварительно распределенных ключей приводятся в приложении Б

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

5.2.2    Общая ключевая информация

Входе выполнения протокола клиентом выбирается эллиптическая кривая Е из множества эллиптических кривых, идентификаторы которых определены в В 3 9 Данная кривая характеризуется следующими параметрами:

выделенной течкой эллиптической кривой Р, простым числом q — порядком точки Р;

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

Общая ключевая информация вырабатывается в ходе выполнения каждой сессии протокола и представляет собой точку Q принадлежащую эллиптической кривой Е и удовлетворяющую равенству

Q = кР

где к = kgk^c (mod q), а величины к_с> к, с F_q — случайные вычеты, вырабатываемые, соответственно, клиентом и сервером независимо друг от друга, см 5.7.1 и 5 7.2 Требования к механизмам генерации случайных значений к_с, к, определяются в Р 1323565 1 012—2017, см раздел 5

5.2.3    Ключи шифрования и ключи выработки имитовставки

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