Р 1323565.1.046-2023. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Защищенный протокол взаимодействия квантово-криптографической аппаратуры выработки и распределения ключей и средства криптографической защиты информации

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

Утверждены и введены в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2023 г. № 1510-ст

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

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

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

ЗАЩИЩЕННЫЙ ПРОТОКОЛ ВЗАИМОДЕЙСТВИЯ КВАНТОВО-КРИПТОГРАФИЧЕСКОЙ АППАРАТУРЫ ВЫРАБОТКИ И РАСПРЕДЕЛЕНИЯ КЛЮЧЕЙ И СРЕДСТВА КРИПТОГРАФИЧЕСКОЙ ЗАЩИТЫ ИНФОРМАЦИИ

Information technology. Cryptographic data security. Secure interaction protocol of quantum-cryptographic device for key generation and distribution and cryptographic device

Р 1323565.1.046-2023

ОКС 35.040

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

Предисловие

1 РАЗРАБОТАНЫ Акционерным обществом «Информационные технологии и коммуникационные системы» (АО «ИнфоТеКС»)

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

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

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

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

Введение

Настоящие рекомендации содержат описание протокола Протока (ProtoQa) — защищенного протокола взаимодействия узла системы выработки и распределения ключей (узел СВРК) и средства криптографической защиты информации (СКЗИ-потребитель).

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

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

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

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

Примечание — Настоящие рекомендации дополнены приложениями А и Б.

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

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

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

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

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

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

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

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

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

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

Р 1323565.1.025-2019 Информационная технология. Криптографическая защита информации. Форматы сообщений, защищенных криптографическими методами

Р 1323565.1.029-2019 Информационная технология. Криптографическая защита информации. Протокол защищенного обмена для индустриальных систем

Р 1323565.1.040-2022 Информационная технология. Криптографическая защита информации. Парольная защита ключевой информации

Р 1323565.1.041-2022 Информационная технология. Криптографическая защита информации. Транспортный ключевой контейнер

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

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

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

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

3.1.1 CRISP: Неинтерактивный протокол защищенной передачи данных.

Примечание — Описание протокола CRISP приведено в Р 1323565.1.029-2019 (разделы 3 - 7).

3.1.2 CRISP-сообщение: Прикладное сообщение, защищенное с помощью протокола CRISP.

3.1.3 базовый ключ: Секретный ключ, известный только отправителю и получателю CRISP-сообщения.

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

3.1.5 идентификатор ключа: Информация, использующаяся при определении ключа.

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

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

3.1.8 исходный ключ: Секретный ключ, предназначенный для выработки по определенным правилам производных секретных ключей.

3.1.9 корректный запрос: Запрос, разбор которого закончился успешно.

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

Примечание — Определение криптографически опасной информации приведено в Р 1323565.1.012-2017 (раздел 3).

3.1.11 криптографический набор CRISP: Совокупность криптографических алгоритмов и параметров, используемых в протоколе CRISP.

3.1.12 метка: Атрибут ключа, который может быть задан СКЗИ-потребителем.

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

Примечание - Отсутствие значения обязательного поля означает нарушение структуры прикладного сообщения.

3.1.14 окно принятых сообщений: Диапазон допустимых порядковых номеров CRISP-сообщений, в котором помечены порядковые номера принятых CRISP-сообщений.

Примечание - Максимальным номером окна принятых сообщений является максимальный номер среди принятых CRISP-сообщений; минимальный номер окна принятых сообщений определяется максимальным номером окна принятых сообщений и размером окна принятых сообщений.

3.1.15 опциональное поле: Поле прикладного сообщения, которое может отсутствовать в сообщении.

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

3.1.17 отправитель: Участник протокола, создающий прикладное сообщение и формирующий из него CRISP-сообщение.

3.1.18 парные СКЗИ-потребители (в рамках одного конкретного сеанса): СКЗИ-потребители, идентификаторы которых используются в прикладных сообщениях одного конкретного сеанса.

3.1.19 получатель: Участник протокола, восстанавливающий прикладное сообщение из полученного CRISP-сообщения.

3.1.20 прикладное сообщение: Данные, представленные в определенной структуре и предназначенные для пересылки между участниками протокола до их инкапсуляции в протокол CRISP.

3.1.21 произвольные данные: Данные, структура которых не регламентируется в протоколе.

3.1.22 сеанс: Упорядоченная совокупность двух прикладных сообщений: первое сообщение — это запрос, второе сообщение — это ответ; при этом тип ответа совпадает с типом запроса, а содержимое ответа зависит от результатов обработки запроса.

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

3.1.24 система выработки и распределения ключей; СВРК: Совокупность связанных между собой участников, которая предназначена для выработки и распределения между ними секретных ключей.

3.1.25 сопряженные узлы СВРК: Пара узлов СВРК, способная вырабатывать и распределять между собой секретные ключи.

3.1.26 средства криптографической защиты информации; СКЗИ: Аппаратные, программные и аппаратно-программные средства, системы и комплексы, реализующие криптографическую систему.

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

3.1.27 СКЗИ-потребитель: СКЗИ, подключаемые к узлам СВРК с целью получения целевых ключей и/или случайных чисел.

3.1.28 тип сообщения: Атрибут прикладного сообщения, идентифицирующий структуру прикладного сообщения и определяющий порядок его разбора.

3.1.29 узел СВРК: Оконечное оборудование участника СВРК, способное вырабатывать и распределять секретные ключи совместно с другими участниками СВРК.

3.1.30 участник протокола: Одна из взаимодействующих сторон в протоколе: узел СВРК или СКЗИ-потребитель.

3.1.31 целевой ключ: Секретный ключ, вырабатываемый и распределяемый между сопряженными узлами СВРК с целью передачи его СКЗИ-потребителю или паре СКЗИ-потребителей.

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

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

V* — множество всех двоичных строк конечной длины, включая пустую строку;

Vs — множество всех двоичных строк длины s, где s — целое неотрицательное число; нумерация подстрок и компонент строки осуществляется справа налево, начиная с нуля;

LSBs(x) — усечение двоичной строки x длины m, m >= s до двоичной строки длины s, выполняющееся по правилу LSBs(xm-1||...||x1||x0) = xs-1||...||x1||x0, x_{i} \in V_{1} , i = 0,1,...,m — 1;

MSBs(x) — усечение двоичной строки x длины m, m >= s, до двоичной строки длины s, выполняющееся по правилу MSBs(xm-1||...||x1||x0) = xm-1||...||xm-s+1||xm-s, x_{i} \in V_{1} , i = 0,1,...,m — 1;

Binary(string) — отображение, ставящее в соответствие символьной строке string, состоящей из m символов, байтовую строку длины m в соответствии с кодировкой UTF-8;

X2 — число X, записанное в двоичной системе счисления;

X16 — число X, записанное в шестнадцатеричной системе счисления. Для записи чисел используется сетевой порядок бит и байтов (Big-endian);

K_{MAC}^{Exp} — ключ вычисления имитовставки, использующийся в алгоритмах экспорта и импорта ключа KExp15 и KImp15, определенных в Р 1323565.1.017-2018 (раздел 5). Длина значения равна 256 бит;

K_{ENC}^{Exp} — ключ шифрования, использующийся в алгоритмах экспорта и импорта ключа KExp15 и KImp15, определенных в Р 1323565.1.017-2018 (раздел 5). Длина значения равна 256 бит.

4 Взаимодействие между системой выработки и распределения ключей и СКЗИ-потребителями

4.1 Общее описание СВРК и подключенных к ней СКЗИ-потребителей

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

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

Для использования описываемого протокола необходимо, чтобы между СКЗИ-потребителем и узлом СВРК, к которому этот СКЗИ-потребитель подключен, были распределены необходимые секретные ключи (см. раздел 8). Допускается подключение нескольких СКЗИ-потребителей к одному узлу СВРК, а также одного СКЗИ-потребителя к нескольким узлам СВРК.

В протокол Протока заложен вспомогательный механизм, позволяющий отправить узлу СВРК сообщение, содержащее уведомление об успешной доставке целевого ключа на СКЗИ-потребитель. Даже с учетом этого механизма протокол Протока не гарантирует доставку ключа и прочих сообщений, что накладывает на разработчика конкретной системы необходимость предусмотреть возможность формирования повторных запросов по истечении отведенного времени ожидания на получение ответа; подробнее ограничения и условия описаны в разделе 8.

Пример СВРК и подключенных к ней СКЗИ-потребителей представлен на рисунке 1. В примере рассматривается СВРК, состоящая из трех связанных между собой узлов, к которым подключены четыре СКЗИ-потребителя. Связи между СКЗИ-потребителями на рисунке обозначены пунктирной линией. Передача данных между СКЗИ-потребителями и узлами СВРК происходит по протоколу Протока.

Рисунок 1 — Пример системы выработки и распределения ключей и подключенных к ней СКЗИ-потребителей

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

4.2 Сценарии взаимодействия между узлом СВРК и СКЗИ-потребителем

Протокол Протока предусматривает пять сценариев взаимодействия между узлом СВРК и СКЗИ-потребителем:

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

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

Опционально СКЗИ-потребитель может оповещать узел СВРК о факте своего подключения к нему или отключения от него, используя сценарий «обмен сервисной информацией» (см. 4.2.4).

Все сценарии выполняются по схеме «запрос — ответ», иллюстрация которой приведена на рисунке 2.

Рисунок 2 — Схема «запрос — ответ»

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

Рисунок 3 — Схема сценария передачи ключа с подтверждением факта получения СКЗИ-потребителем целевого ключа

4.2.1 Получение информации о параметрах работы узла

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

Формирование и разбор запроса параметров работы узла выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.2; разбор — согласно 9.4.2.2.

Формирование и разбор ответа с параметрами работы узла выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.3; разбор — согласно 9.4.2.3.

4.2.2 Передача ключа

Передача ключа происходит по схеме «запрос — ответ». Этот сценарий взаимодействия следует использовать в тех случаях, когда СКЗИ-потребителю необходимо получить целевой ключ от узла СВРК. Протокол поддерживает три разных запроса ключа от СКЗИ-потребителя:

• получение нового ключа. Целью этого запроса является получение СКЗИ-потребителем нового целевого ключа, инициатором создания которого он выступил;
• получение ранее запрошенного ключа. Целью этого запроса является получение СКЗИ-потребителем целевого ключа, который был создан в результате ранее поступившего в СВРК запроса;
• получение нового или ранее запрошенного ключа. Целью этого запроса является получение СКЗИ-потребителем целевого ключа, который удовлетворяет параметрам, указанным в запросе.

Обработка запросов зависит от настроек узла СВРК и параметров запроса, упрощенная схема обработки запросов приведена ниже, подробно порядок разбора запросов описан в 9.4.2.4 - 9.4.2.6.

Порядок разбора запросов в схематичном виде представлен на рисунках 4, 5 и 6.

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

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

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

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

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

Формирование и разбор запроса ключа выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.4 - 9.3.2.6; разбор — согласно 9.4.2.4 - 9.4.2.6.

Формирование и разбор ответа на запрос ключа выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.7; разбор — согласно 9.4.2.7.

4.2.3 Передача случайных чисел

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

Формирование и разбор запроса случайного числа выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.8; разбор — согласно 9.4.2.8.

Формирование и разбор ответа на запрос случайного числа выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.9; разбор — согласно 9.4.2.9.

4.2.4 Обмен сервисной информацией

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

• сообщить СКЗИ-потребителю об изготовлении для него целевого ключа;
• сообщить узлу СВРК о том, что СКЗИ-потребитель получил целевой ключ;
• запросить у другого участника протокола информацию о наличии ошибок;
• сообщить узлу СВРК о том, что СКЗИ-потребитель подключился к нему или отключился от него.

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

Формирование и разбор запроса на передачу сервисной информации выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.11; разбор — согласно 9.4.2.11.

Формирование и разбор ответа с кодом отчета выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.1; разбор — согласно 9.4.2.1.

4.2.5 Передача произвольных данных

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

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

Формирование и разбор запроса передачи произвольных данных выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.10; разбор — согласно 9.4.2.10.

Формирование и разбор ответа с кодом отчета выполняются в соответствии с разделом 9: формирование — согласно 9.3.2.1; разбор — согласно 9.4.2.1.

5 Состав и структура сообщений протокола

Защита передаваемых сообщений между узлами обеспечивается с помощью протокола CRISP согласно Р 1323565.1.029-2019 (разделы 3 - 7). Параметры использования протокола CRISP представлены в 5.1.

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

5.1 Структура CRISP-сообщения

Структура используемого CRISP-сообщения представлена в таблице 1.

Таблица 1

Структура используемого CRISP-сообщения

Номер поля	Наименование поля		Длина поля в битах
1	Заголовок	ExternalKeyIdFlag	1
2		Version	15
3		CS	8
4		KeyId	328
5		SeqNum	48
6	PayloadData		Переменная длина. Размер поля не превышает 1982 байт
7	ICV		32 или 64, что определяется значением поля CS

5.1.1 ExternalKeyIdFlag

Признак необходимости использования внешней по отношению к входящему CRISP-сообщению информации для однозначного определения ключа обработки этого сообщения — согласно Р 1323565.1.029-2019 (подраздел 4.1).

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

ExternalKeyIdFlag = 0.

5.1.2 Version

Версия CRISP-сообщения. Беззнаковое целое число. Согласно Р 1323565.1.029-2019 (подраздел 4.2) в настоящих рекомендациях приведено описание CRISP-сообщения, для которого Version = 0.

5.1.3 CS

Идентификатор криптографического набора CRISP, обеспечивающего конфиденциальность и имитозащиту сообщения. Беззнаковое целое число.

Таким криптографическим набором является MAGMA-CTR-CMAC: CS = 1, согласно Р 1323565.1.029-2019 (подраздел 7.1), либо MAGMA-CTR-CMAC8: CS = 3 согласно Р 1323565.1.029-2019 (Изменение № 1).

5.1.4 KeyId

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

MSB₈(KeyId) = 101010002. Согласно Р 1323565.1.029-2019 (подраздел 4.4) информация, позволяющая однозначно определить базовый ключ, содержится в LSB320(KeyId).

С каждым базовым ключом ассоциированы идентификаторы отправителя CRISP-сообщения SenderID и получателя CRISP-сообщения RecipientID, которые являются частью KeyId и имеют размер 16 байт каждый.

SenderID задает значение LSB₁₂₈(MSB₁₃₆(KeyId)). RecipientID задает значение LSB128(MSB264(KeyId)).

Идентификаторы отправителя и получателя CRISP-сообщения являются уникальными в рамках СВРК. Для каждого направления передачи данных используется собственный базовый ключ.

С каждым базовым ключом ассоциирован идентификатор ключа по направлению KeyCounter, который является частью KeyId. KeyCounter задает значение LSB64(KeyId) и имеет размер 8 байт.

Идентификатор ключа по направлению является уникальным в рамках конкретной пары SenderID и RecipientID, т.е. у разных базовых ключей для пары отправитель и получатель значения KeyCounter различные.

5.1.5 SeqNum

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

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

В описываемом протоколе значение SeqNum в соответствии с описанием Р 1323565.1.029-2019 (подраздел 4.5) также используется для формирования синхропосылки алгоритма шифрования прикладного сообщения.

5.1.6 PayloadData

Зашифрованное прикладное сообщение. Шифрование производится согласно алгоритму, определенному криптографическим набором, задаваемым полем CS.

Состав и структура прикладного сообщения определены в 5.2.

5.1.7 ICV

Имитовставка, рассчитанная для полей 1 — 6 CRISP-сообщения. Имитовставка вычисляется согласно алгоритму, определенному криптографическим набором, задаваемым полем CS.

5.2 Структура прикладных сообщений

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

5.2.1 Структура заголовка прикладного сообщения

Общий размер заголовка составляет 47 байт. Перечень полей заголовка представлен в таблице 2.

Таблица 2

Структура заголовка прикладных сообщений

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
1	Ver	0	Версия сообщения	1 байт
2	SenderID	Определяется разработчиком	Идентификатор отправителя прикладного сообщения, позволяющий однозначно определить отправителя в системе. Порядок адресации узлов сети выходит за рамки настоящих рекомендаций	16 байт
3	RecipientID	Определяется разработчиком	Идентификатор получателя прикладного сообщения, позволяющий однозначно определить получателя сообщения в системе. Порядок адресации узлов сети выходит за рамки настоящих рекомендаций	16 байт
4	SessionID	От 0 до 232 — 1	Идентификатор пары сообщений «запрос — ответ» используется для идентификации сеанса. Правила формирования описаны в 9.1	4 байта
5	MsgType	Зарезервированные значения указаны в 5.2.1.3	Тип сообщения. Определяет структуру тела сообщения	1 байт
6	HeaderFlags	Битовая строка. Конкретные значения задаются согласно принципам, описанным в 5.2.1.1	Флаги	1 байт
7	TimeStamp	Поле содержит значение времени формирования сообщения по часам узла-отправителя в POSIX-формате времени	Время формирования сообщения. Если отправитель не использует метку времени, то в поле записывается нулевое значение. Подробнее описано в 5.2.1.2	8 байт

5.2.1.1 HeaderFlags

MSB6(HeaderFlags) = 0000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(HeaderFlags) = 02 означает, что сообщение не является сообщением об ошибке;
• LSB1(HeaderFlags) = 12 означает, что сообщение является ответом, содержащим сообщение об ошибке;
• MSB1(LSB2(HeaderFlags)) = 02 означает, что сообщение является запросом;
• MSB1(LSB2(HeaderFlags)) = 12 означает, что сообщение является ответом.

Примечание - Значение LSB2(HeaderFlags) = 012 является недопустимым.

5.2.1.2 TimeStamp

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

Порядок формирования этого поля описан в перечислении е) 9.3.1, порядок разбора поля — в шаге 7) 9.4.1.

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

5.2.1.3 Типы сообщений

Зарезервированные типы прикладных сообщений представлены в таблице 3.

Таблица 3

Зарезервированные типы прикладных сообщений

Значение	Описание
0116	Запрос/ответ параметров работы узла
0216	Запрос/ответ на получение нового ключа
0316	Запрос/ответ на получение ранее запрошенного ключа
0416	Запрос/ответ на получение нового или ранее запрошенного ключа
0516	Запрос/ответ на получение случайного числа
0616	Запрос/ответ на передачу произвольных данных
0716	Запрос/ответ на передачу сервисной информации
Примечание — Значения, имеющие номер более или равный 8016, могут использоваться разработчиками по своему усмотрению.

5.2.2 Структура тела прикладных сообщений

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

5.2.2.1 Тело ответа с кодом отчета

В заголовке сообщений этого типа в поле MsgType указывается значение, содержащееся в запросе, в ответ на который формируется данное сообщение. Если ответное сообщение является сообщением об ошибке, то в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 112; если ответное сообщение не является сообщением об ошибке и MsgType = 0616 или MsgType = 0716, то LSB2(HeaderFlags) = 102.

Структура тела такого сообщения представлена в таблице 4.

Таблица 4

Структура тела ответа с кодом отчета

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	RepCodesCount	Беззнаковое целое число от 1 до 255	Количество кодов отчета в сообщении	1 байт
9	RepCodesList	Зарезервированные значения поля приведены в таблице 5	Список кодов отчета. В зависимости от значений определяется наличие и суммарный размер поля AddData	2*RepCodesCount байт
10	AddData	Битовая строка	Дополнительные данные. Опциональное поле, наличие определяется значением поля RepCodesList	Определяется значением поля RepCodesList
Примечание — Значение поля AddData может использоваться разработчиками по своему усмотрению с ограничением на размер тела прикладного сообщения, он должен быть не более 1935 байт.

Таблица 5

Зарезервированные значения кодов отчета

Значение	Описание
000016	Ошибок не было
000116	Невозможно удовлетворить запрос
010116	Неизвестный тип сообщения (MsgType)
010216	Отсутствует TimeStamp
010316	Неверное значение TimeStamp
020116	Неверная структура тела сообщения
020216	Криптографический набор не поддерживается (CS_KW)
020316	Указанный размер метки не поддерживается
020416	Указанный размер ключа не поддерживается
020516	Необходимо использовать ключевой контейнер
020616	Размер случайного числа слишком большой
020716	Указанные параметры не поддерживаются
030116	Парный СКЗИ-потребитель не найден (PairConID)
030216	Запрашиваемый ключ отсутствует
030316	Повторное использование метки (KeyLabel)
030416	Повторный запрос ключа
030516	Для указанной пары СКЗИ-потребителей ключ сформировать нельзя
030616	Данные не могут быть доставлены
040116	Запрашиваемый ключ изготавливается
Примечание — Значения, имеющие номер больше или равный 800016, могут использоваться разработчиками по своему усмотрению.

5.2.2.2 Тело запроса параметров работы узла (MsgType = 0116)

В заголовке запроса согласования параметров в поле MsgType должно быть указано значение 0116; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Отправителем запроса может выступать как СКЗИ-потребитель, так и узел СВРК.

Структура тела запроса согласования параметров представлена в таблице 6.

Таблица 6

Структура тела запроса согласования параметров

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
9	AddDataSize	Беззнаковое целое число от 1 до 1932	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	2 байта
10	AddData	Битовая строка	Дополнительные данные. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	Определяется значением поля AddDataSize и не превышает 1932 байт

MSB7(Flags) = 00000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что запрос не содержит дополнительные данные;
• LSB1(Flags) = 12 означает, что запрос содержит дополнительные данные.

5.2.2.3 Тело ответа с параметрами работы узла

В заголовке ответа с параметрами работы узла в поле MsgType должно быть указано значение 0116; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 102. Сообщение такого типа посылается только в ответ на запрос типа 0116.

Структура тела ответа на запрос согласования параметров представлена в таблице 7.

Таблица 7

Структура тела ответа на запрос согласования параметров

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
9	KeyLabelMinSize	От 0 до 255	Наименьший размер (в байтах) метки целевого ключа, поддерживаемый узлом	1 байт
10	KeyLabelMaxSize	От KeyLabelMinSize до 255	Наибольший размер (в байтах) метки целевого ключа, поддерживаемый узлом	1 байт
11	CS_KW_List	Возможные значения {0}, {1}, {2}, {3}	Список идентификаторов поддерживаемых криптографических наборов для ключевого контейнера; {0} — ключевой контейнер не поддерживается; {1} — поддерживается CS_KW = 1; {2} — поддерживается CS_KW = 2; {3} — поддерживается CS_KW = 1 и CS_KW = 2 (см. раздел 7)	1 байт
12	KeyMinSize	Беззнаковое целое число от 1 до 1855	Наименьший байтовый размер целевого ключа, поддерживаемый узлом	2 байта
13	KeyMaxSize	Беззнаковое целое число от KeyMinSize до 1855	Наибольший байтовый размер целевого ключа, поддерживаемый узлом	2 байта
14	AddDataSize	Беззнаковое целое число от 1 до 1925	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если MSB1(LSB7(Flags)) = 12	2 байта
15	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если MSB1(LSB7(Flags)) = 12	Определяется значением поля AddDataSize и не превышает 1925 байт

MSB1(Flags) = 02.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что узел не передает случайные числа;
• LSB1(Flags) = 12 означает, что узел передает случайные числа;
• MSB1(LSB2(Flags)) = 02 означает, что узел не поддерживает передачу произвольных данных;
• MSB1(LSB2(Flags)) = 12 означает, что узел поддерживает передачу произвольных данных;
• MSB2(LSB4(Flags)) = 002 означает, что узел не поддерживает механизм подтверждения доставки ключа;
• MSB2(LSB4(Flags)) = 012 означает, что механизм подтверждения доставки ключа используется только при необходимости для второго участника;
• MSB2(LSB4(Flags)) = 102 означает, что механизм подтверждения доставки ключа обязательно должен быть реализован у второго участника;
• MSB2(LSB6(Flags)) = 002 означает, что механизм уведомления об изготовлении ключей на узле не поддерживается;
• MSB2(LSB6(Flags)) = 012 означает, что механизм уведомления об изготовлении ключей используется только при необходимости для второго участника;
• MSB2(LSB6(Flags)) = 102 означает, что механизм уведомления об изготовлении ключей должен быть реализован у второго участника;
• MSB1(LSB7(Flags)) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• MSB1(LSB7(Flags)) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

5.2.2.4 Тело запроса на получение нового ключа (MsgType = 0216)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0216; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Запрос может быть отправлен только СКЗИ-потребителем.

Структура тела запроса нового ключа представлена в таблице 8.

Таблица 8

Структура тела запроса нового ключа

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	PairConID	Определяется разработчиком	Идентификатор парного СКЗИ-потребителя, использующийся в прикладных сообщениях	16 байт
9	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
10	Timer	Беззнаковое целое число от 0 до 232 — 1	Таймер ожидания ответа, задается в миллисекундах. Если отправитель не использует таймер, то в поле записывается нулевое значение	4 байта
11	KeySize	Беззнаковое целое число, верхняя граница определена в 7.1 и 7.2	Размер ключа в байтах	2 байта
12	CS_KW	1 или 2	Идентификатор криптонабора для ключевого контейнера (см. раздел 7)	1 байт
13	KeyLabelSize	Беззнаковое целое число от 0 до 255	Размер метки ключа в байтах. Если значение поля 0, то метка отсутствует	1 байт
14	KeyLabel	Значение из диапазона (битовая строка), определяемого полем KeyLabelSize	Метка ключа, которую нужно записать в атрибуты ключа. Опциональное поле, присутствует в сообщении, если KeyLabelSize > 0	Определяется полем KeyLabelSize и не превышает 255 байт
15	AddDataSize	Беззнаковое целое число от 1 до 1908	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	2 байта
16	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	Определяется значением поля AddDataSize и не превышает 1908 байт

MSB7(Flags) = 00000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• LSB1(Flags) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

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

5.2.2.5 Тело запроса на получение ранее запрошенного ключа (MsgType = 0316)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0316; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Запрос может быть отправлен только СКЗИ-потребителем.

Структура тела запроса ранее запрошенного ключа представлена в таблице 9.

Таблица 9

Структура тела запроса на получение ранее запрошенного ключа

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	PairConID	Определяется разработчиком	Идентификатор парного СКЗИ-потребителя, использующийся в прикладных сообщениях	16 байт
9	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
10	Timer	Беззнаковое целое число от 0 до 232 — 1	Таймер ожидания ответа, задается в миллисекундах. Если отправитель не использует таймер, то в поле записывается нулевое значение	4 байта
11	CS_KW	1 или 2	Идентификатор криптонабора для ключевого контейнера (см. раздел 7)	1 байт
12	KeyLabelSize	Беззнаковое целое число от 0 до 255	Размер метки ключа в байтах. Если значение поля 0, то метка отсутствует	1 байт
13	KeyLabel	Значение из диапазона (битовая строка), определяемого полем KeyLabelSize	Метка ключа, которую нужно записать в атрибуты ключа. Опциональное поле, присутствует в сообщении, если KeyLabelSize > 0	Определяется полем KeyLabelSize и не превышает 255 байт
14	TargetKeyID	Беззнаковое целое число	Идентификатор ключа. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	40 байт
15	AddDataSize	Беззнаковое целое число от 1 до 1871	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если MSB1(LSB2(Flags)) = 12	2 байта
16	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если MSB1(LSB2(Flags)) = 12	Определяется значением поля AddDataSize и не превышает 1871 байт

MSB6(Flags) = 0000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что запрос не содержит поля TargetKeyID;
• LSB1(Flags) = 12 означает, что запрос содержит поле TargetKeyID;
• MSB1(LSB2(Flags)) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• MSB1(LSB2(Flags)) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

5.2.2.6 Тело запроса на получение нового или ранее запрошенного ключа (MsgType = 0416)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0416; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Запрос может быть отправлен только СКЗИ-потребителем. Структура тела запроса на получение нового или ранее запрошенного ключа полностью совпадает со структурой запроса нового ключа (MsgType = 0216).

5.2.2.7 Тело ответа на запрос получения ключа

В заголовке сообщений, которые являются ответом на запрос получения ключа, в поле MsgType указывается значение, которое было указано в запросе, в ответ на который формируется данное сообщение; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 102. Сообщение такого типа посылается в ответ на сообщения следующих типов: 0216, 0316, 0416. Отправителем ответа может выступать только узел СВРК.

Структура тела ответа на запросы типов 0216, 0316, 0416 представлена в таблице 10.

Таблица 10

Структура тела ответа на запрос получения ключа

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	PairConID	Определяется разработчиком	Идентификатор парного СКЗИ-потребителя, использующийся в прикладных сообщениях	16 байт
9	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
10	TargetKeyID	Беззнаковое целое число	Идентификатор ключа	40 байт
11	KeySize	Беззнаковое целое число, верхняя граница определена в 7.1 и 7.2	Размер ключа в байтах	2 байта
12	CS_KW	1 или 2	Идентификатор криптонабора для ключевого контейнера (см. раздел 7)	1 байт
13	KeyLabelSize	Беззнаковое целое число от 0 до 255	Размер метки ключа в байтах. Если значение поля 0, то метка отсутствует	1 байт
14	KeyLabel	Значение из диапазона (битовая строка), определяемого полем KeyLabelSize	Метка ключа, которую нужно записать в атрибуты ключа. Опциональное поле, присутствует в сообщении, если KeyLabelSize > 0	Определяется полем KeyLabelSize и не превышает 255 байт
15	KeyContainer	Битовая строка. Структура ключевого контейнера описана в разделе 7	Контейнер с ключом	Зависит от KeySize и CS_KW
16	AddDataSize	Беззнаковое целое число, зависит от размеров KeyContainer	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если MSB1(LSB3(Flags)) = 12	2 байта
17	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если MSB1(LSB3(Flags)) = 12	Определяется значением поля AddDataSize

MSB5(Flags) = 000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что ключ был создан в результате ранее поступившего запроса от парного СКЗИ-потребителя;
• LSB1(Flags) = 12 означает, что ключ был создан в результате запроса получателя;
• MSB1(LSB2(Flags)) = 02 означает, что узел СВРК не ожидает подтверждения от СКЗИ-потребителя о факте получения ключа;
• MSB1(LSB2(Flags)) = 12 означает, что узел СВРК ожидает подтверждения от СКЗИ-потребителя о факте получения ключа;
• MSB1(LSB3(Flags)) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• MSB1(LSB3(Flags)) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

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

5.2.2.8 Тело запроса на получение случайного числа (MsgType = 0516)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0516; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Отправителем сообщения может выступать как СКЗИ-потребитель, так и узел СВРК.

Структура тела запроса на получение случайного числа представлена в таблице 11.

Таблица 11

Структура тела запроса на получение случайного числа

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
9	CS_KW	0, 1 или 2	Идентификатор криптонабора для ключевого контейнера; {0} — ключевой контейнер отсутствует; {1} — поддерживается CS_KW = 1; {2} — поддерживается CS_KW = 2 (см. раздел 7)	1 байт
10	RNSize	Беззнаковое целое число от 1 до 1931	Размер случайного числа в байтах	2 байта
11	AddDataSize	Беззнаковое целое число, зависит от RNSize	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	2 байта
12	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	Определяется значением поля AddDataSize

MSB7(Flags) = 00000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• LSB1(Flags) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

5.2.2.9 Тело ответа на запрос получения случайного числа

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0516; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 102. Сообщение такого типа посылается только в ответ на запрос типа 0516.

Структура тела ответа на запрос получения случайного числа представлена в таблице 12.

Таблица 12

Структура тела ответа на запрос получения случайного числа

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	Flags	Битовая строка. Конкретные значения задаются согласно принципам, описанным ниже	Флаги	1 байт
9	CS_KW	0, 1 или 2	Идентификатор криптонабора для ключевого контейнера; {0} — ключевой контейнер отсутствует; {1} — поддерживается CS_KW = 1; {2} — поддерживается CS_KW = 2 (см. раздел 7)	1 байт
10	RNSize	Беззнаковое целое число от 1 до 1931	Размер случайного числа в байтах. Совпадает со значением поля RNSize из запроса	2 байта
11	RandomNumber	Битовая строка или ключевой контейнер, структура которого описана в разделе 7	Случайное число или ключевой контейнер со случайным числом	Длина зависит от поля RNSize и не превышает 1931 байт
12	AddDataSize	Беззнаковое целое число, зависит от RNSize	Размер поля AddData в байтах. Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	2 байта
13	AddData	Битовая строка	Опциональное поле, присутствует в сообщении, если LSB1(Flags) = 12	Определяется значением поля AddDataSize

MSB7(Flags) = 00000002.

Остальные биты поля задаются согласно следующим принципам:

• LSB1(Flags) = 02 означает, что поля AddDataSize и AddData отсутствуют в сообщении;
• LSB1(Flags) = 12 означает, что поля AddDataSize и AddData присутствуют в сообщении.

5.2.2.10 Тело запроса передачи произвольных данных (MsgType = 0616)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0616; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Отправителем сообщения может выступать как СКЗИ-потребитель, так и узел СВРК.

Структура тела запроса передачи произвольных данных представлена в таблице 13.

Таблица 13

Структура тела запроса передачи произвольных данных

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	DataSize	Беззнаковое целое число от 1 до 1933	Размер поля Data в байтах	2 байта
9	Data	Битовая строка	Произвольные данные	Определяется значением поля DataSize

5.2.2.11 Тело запроса на передачу сервисной информации (MsgType = 0716)

В заголовке сообщений этого типа в поле MsgType должно быть указано значение 0716; в поле HeaderFlags устанавливаются биты LSB2(HeaderFlags) = 002. Отправителем сообщения может выступать как СКЗИ-потребитель, так и узел СВРК.

Структура тела такого сообщения представлена в таблице 14.

Таблица 14

Структура тела запроса на передачу сервисной информации

Номер поля	Наименование поля	Значения (диапазон значений)	Описание	Размер
8	StatusType	Беззнаковое целое число. Зарезервированные значения приведены в таблице 15	Код статуса. В зависимости от значений этого поля определяется наличие и размер поля AddData	2 байта
9	AddData	Битовая строка	Опциональное поле, наличие которого зависит от значения поля StatusType	Определяется значением поля StatusType и не превышает 1933 байта

Таблица 15

Зарезервированные коды статусов

Значение	Описание	Наличие дополнительных данных
000016	Запрос наличия ошибок (ping)	Нет
010116	Оповестить узел СВРК об отключении СКЗИ-потребителя	Нет
010216	Оповестить узел СВРК о подключении СКЗИ-потребителя	Нет
010316	Оповестить СКЗИ-потребителя об отключении узла СВРК	Нет
010416	Оповестить СКЗИ-потребителя о подключении узла СВРК	Нет
020116	Оповестить узел СВРК о получении ключа. В дополнительных данных передается идентификатор полученного ключа	40 байт
020216	Оповестить СКЗИ-потребителя об изготовлении для него целевого ключа. Дополнительные данные имеют следующую структуру и состоят из следующих значений: идентификатор парного СКЗИ-потребителя, для которого предназначен этот ключ (16 байт); размер ключа (2 байта); идентификатор ключа (40 байт)	58 байт
Примечание — Значения, имеющие номер больший или равный 800016, могут использоваться разработчиками по своему усмотрению.

6 Атрибуты целевых ключей

Предусмотренный в настоящих рекомендациях состав атрибутов целевых ключей представлен в таблице 16.

Таблица 16

Атрибуты целевых ключей

Обозначение	Наименование атрибута	Описание	Размер
KeySize	Размер ключа	Обязательный атрибут	2 байта
TargetKeyID	Идентификатор ключа	Обязательный атрибут	40 байт
KeyLabelSize	Размер метки	Обязательный атрибут	1 байт
KeyLabel	Метка	Опциональный атрибут (отсутствует при KeyLabelSize = 0)	Зависит от KeyLabelSize
AddData	Дополнительный атрибут	Опциональный атрибут	Ограничен размером прикладного сообщения «ответ на запрос получения ключа»

6.1 KeySize

Атрибут KeySize определяет байтовый размер целевого ключа. Размер ключа определяется исходя из поля KeySize в запросах типа MsgType = 0216 или MsgType = 0416.

6.2 TargetKeyID

Атрибут TargetKeyID определяет уникальный в СВРК идентификатор целевого ключа. Идентификатор формируется на узле СВРК и становится атрибутом целевого ключа после сопоставления атрибутов ключа паре СКЗИ-потребителей.

Размер идентификатора равен 40 байтам.

Примечание - После сопоставления атрибутов ключа паре СКЗИ-потребителей, идентификаторы СКЗИ-потребителей или идентификатор пары СКЗИ-потребителей (если такой используется на узле СВРК), является техническим атрибутом целевого ключа. Этот атрибут не передается вместе с ключом в СКЗИ-потребитель, а используется на узле СВРК при анализе запросов получения ключа (0216, 0316, 0416). Еще один технический атрибут ключа — указание на идентификатор СКЗИ-потребителя, который является инициатором создания этого ключа.

6.3 KeyLabelSize

Атрибут KeyLabelSize определяет байтовый размер метки целевого ключа. Размер атрибута — 1 байт, возможные значения — от 0 до 255 (0 — метка отсутствует). Точное значение зависит от параметров работы узла СВРК и может зависеть от значения поля KeyLabelSize, полученного в запросе от СКЗИ-потребителя.

6.4 KeyLabel

Опциональный атрибут KeyLabel может использоваться для альтернативной идентификации ключа между СКЗИ-потребителями. Размер метки зависит от значения атрибута KeyLabelSize.

Метки целевых ключей должны быть уникальными в рамках двух СКЗИ-потребителей в течение установленного в системе временного интервала. СКЗИ-потребитель должен обеспечивать уникальность меток. Узел СВРК осуществляет контроль уникальности меток в рамках хранения у себя ключей с их атрибутами. Процедуры, которые выполняются на узле СВРК в случае обнаружения повтора меток, описаны в 9.4.2.4 и 9.4.2.6.

После удаления ключей из узла СВРК атрибуты целевых ключей будут храниться на узле СВРК заданное разработчиком время. Точное значение времени хранения выходит за рамки настоящих рекомендаций.

6.5 AddData

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

7 Описание ключевого контейнера

Общая структура ключевого контейнера, использующегося для транспортирования ключей от узла СВРК к СКЗИ-потребителю или случайных чисел между участниками протокола (в любом направлении), представлена в таблице 17.

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

• KExp15-KImp15-Kuzn;
• KExp15-KImp15-Magma.

Таблица 17

Структура ключевого контейнера

Номер поля	Наименование поля	Описание
1	KeyWrapID	Информация, позволяющая однозначно определить ключи K_{MAC}^{Exp} и K_{ENC}^{Exp} , использующиеся в алгоритмах экспорта и импорта ключа
2	IV	Синхропосылка, использующаяся в алгоритмах экспорта и импорта ключа
3	Key_Exp	Экспортное представление ключа. Формируется согласно алгоритму экспорта ключа

7.1 Криптонабор для ключевого контейнера KExp15-KImp15-Kuzn

Данный криптографический набор используется, если CS_KW = 1.

Размер поля KeyWrapID — 8 байт.

Размер поля IV — 8 байт.

Размер поля Key_Exp зависит от экспортируемого ключа — от 17 до 1858 байт. Если контейнер используется для передачи случайного числа, то размер поля Key_Exp составляет от 17 до 1915 байт.

Алгоритмами экспорта и импорта ключа являются алгоритмы KExp15 и KImp15, соответственно, определенные в Р 1323565.1.017-2018 (раздел 5), на основе блочного шифра ГОСТ Р 34.12-2015 («Кузнечик»).

Входными параметрами алгоритма экспорта ключа являются:

• экспортируемый ключ K \in V_{8 \cdot s} , где 1 <= s <= 1842;
• ключ вычисления имитовставки K_{MAC}^{Exp} \in V_{256} ;
• ключ шифрования K_{ENC}^{Exp} \in V_{256} ;
• значение IV \in V_{64} .

Входные значения для алгоритма импорта ключа однозначно определяются входными значениями алгоритма экспорта ключа. В рамках применения одной и той же пары ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} значение IV должно быть уникальным.

7.2 Криптонабор для ключевого контейнера KExp15-KImp15-Magma

Данный криптографический набор используется, если CS_KW = 2.

Размер поля KeyWrapID — 8 байт.

Размер поля IV — 4 байта.

Размер поля Key_Exp зависит от экспортируемого ключа — от 9 до 1862 байт. Если контейнер используется для передачи случайного числа, то размер поля Key_Exp составляет от 9 до 1919 байт.

Алгоритмами экспорта и импорта ключа являются алгоритмы KExp15 и KImp15, соответственно, определенные в Р 1323565.1.017-2018 (раздел 5), на основе блочного шифра ГОСТ Р 34.12-2015 («Магма»).

Входными параметрами алгоритма экспорта ключа являются:

• экспортируемый ключ K \in V_{8 \cdot s} , где 1 <= s <= 1842;
• ключ вычисления имитовставки K_{MAC}^{Exp} \in V_{256} ;
• ключ шифрования K_{ENC}^{Exp} \in V_{256} ;
• значение IV \in V_{32} .

Входные значения для алгоритма импорта ключа однозначно определяются входными значениями алгоритма экспорта ключа. В рамках применения одной и той же пары ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} значение IV должно быть уникальным.

7.3 Порядок формирования и проверки значения KeyWrapID

Ключи K_{MAC}^{Exp} и K_{ENC}^{Exp} , использующиеся в алгоритмах KExp15 и KImp15, применяются в порядке возрастания идентификаторов этих ключей. Это означает, что значение KeyWrapID должно увеличиваться при переходе к новым ключам, причем рост значения на разных шагах может осуществляться на разную величину в соответствии с правилами идентификации ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} .

Смена ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} определяется логикой отправителя сообщений с учетом максимально допустимой нагрузки на ключи. Допускается использовать ключи K_{MAC}^{Exp} и K_{ENC}^{Exp} для формирования нескольких ключевых контейнеров при условии, что используются различные IV. В первый раз и при последующей смене ключа IV устанавливается равной 1.

Для проверки значения KeyWrapID у получателя контейнера должен храниться наибольший из всех идентификаторов ранее использованных пар ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} . Далее этот идентификатор будет обозначаться IDcur. До первого использования значение IDcur устанавливается как наименьший из возможных идентификаторов пары ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} . Кроме того, между участниками протокола должны быть согласованы правила определения допустимых идентификаторов для ключей защиты контейнера на основе значения IDcur, с учетом правил идентификации пар ключей. Если полученное значение KeyWrapID удовлетворяет правилам определения допустимых идентификаторов, то для пары ключей, соответствующей значению KeyWrapID, осуществляется контроль максимально допустимой нагрузки на ключ, иначе необходимо прекратить разбор сообщения. Если контроль максимально допустимой нагрузки успешно пройден, то пара ключей с идентификатором KeyWrapID используется в алгоритме KImp15, иначе необходимо прекратить разбор сообщения.

Пример идентификации ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} , а также правил формирования и проверки значений KeyWrapID описан в приложении Б.

8 Ограничения и условия

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

8.1 Каждый участник протокола имеет два идентификатора: первый — для CRISP-сообщений (используется при формировании поля KeyId согласно 5.1.4), второй идентификатор для прикладных сообщений (используется при формировании заголовка прикладного сообщения согласно 5.2.1). В общем случае первый и второй идентификаторы могут не совпадать.

8.2 Отправителем и получателем сообщений могут являться как СКЗИ-потребитель, так и узел СВРК. При этом:

а) отправителю и получателю известны идентификаторы друг друга; идентификаторы отправителя и получателя являются уникальными в рамках СВРК;

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

в) сопряженным узлам СВРК известны идентификаторы друг друга. При этом:

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

2. вопросы передачи информации между взаимодействующими узлами СВРК выходят за рамки настоящих рекомендаций;

г) узлу СВРК известны идентификаторы обслуживаемых им СКЗИ-потребителей.

8.3 При формировании CRISP-сообщения в системе выполняются следующие условия:

а) у участников протокола имеется общий базовый ключ для каждого направления; для разных криптографических наборов CRISP используются разные статистически независимые базовые ключи; для разных направлений базовые ключи являются статистически независимыми. Один из возможных способов получения базовых ключей — их вычисление при помощи функции выработки производных ключей с использованием исходного ключа, загружаемого обоим участникам протокола. Для реализации такой функции выработки рекомендуется применять алгоритм диверсификации KDF_TREE_GOSTR3411_2012_256, приведенный в Р 50.1.113-2016 (подраздел 4.5) с псевдослучайной функцией HMAC_GOSTR3411_2012_256, приведенной в Р 50.1.113-2016 (пункт 4.1.1). Также в рамках настоящих рекомендаций может использоваться схема выработки производных ключей, описанная в Б.5.1, с псевдослучайной функцией, определенной по ГОСТ Р 34.13-2015 (подраздел 5.6). Входные значения для псевдослучайной функции при одном и том же ключе должны быть уникальными; при задании входных параметров и выхода для функций выработки производных ключей используются общие принципы, изложенные в Р 50.1.113-2016 (подраздел 4.4 и 4.5) и учитывается максимально допустимая нагрузка на один ключ. Пример загружаемых участнику протокола исходных ключей и вычисления из них необходимых базовых ключей описан в приложении Б;

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

1. первое поле — это идентификатор отправителя сообщения, имеющий размер 16 байт,

2. второе поле — это идентификатор получателя сообщения, имеющий размер 16 байт,

3. третье поле — это идентификатор ключа по направлению, имеющий размер 8 байт. Значение этого идентификатора должно быть уникальным для упорядоченной пары отправитель — получатель; общие требования к идентификатору описаны в 9.2.3, пример формирования и проверки идентификатора ключа по направлению описан в приложении Б;

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

г) отправитель и получатель поддерживают не менее одного общего криптографического набора для протокола CRISP;

д) у отправителя и получателя одинаково настроен размер окна принятых CRISP-сообщений (параметр Size), который должен быть в пределах от 1 до 256 (включительно) сообщений; способ установки на отправителе и получателе одинакового размера окна принятых CRISP-сообщений (параметр Size) выходит за рамки настоящих рекомендаций.

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

• однозначно определены правила хранения и удаления целевых ключей и их атрибутов на узле СВРК;
• до начала эксплуатации в настройках СВРК должно быть установлено, разрешается ли передавать один и тот же целевой ключ в разных ключевых контейнерах. Для одного целевого ключа разными считаются такие ключевые контейнеры, в которых отличается хотя бы один из двух параметров: синхропосылка IV или ключи K_{ENC}^{Exp} и K_{MAC}^{Exp} , использующиеся при формировании экспортного и импортного представления целевого ключа;
• если в настройках узла СВРК разрешено передавать один и тот же целевой ключ в разных ключевых контейнерах, то допускается повторно запрашивать целевой ключ у узла СВРК; при этом данная возможность не может гарантировать, что у парных СКЗИ-потребителей множество целевых ключей будет совпадать. Поэтому вне зависимости от установленных настроек порядок работы СКЗИ-потребителей должен предусматривать такую ситуацию, при которой один из парных СКЗИ-потребителей обладает целевым ключом, а другой СКЗИ-потребитель не способен получить именно этот целевой ключ от узла СВРК. В данном случае следует вывести этот целевой ключ из эксплуатации на СКЗИ-потребителе и использовать следующий целевой ключ, при необходимости запросив его у узлов СВРК;
• уникальность метки целевого ключа проверяется в рамках временного интервала, который устанавливается в настройках узла СВРК и согласуется с правилами хранения целевых ключей и их атрибутов на узле СВРК;
• у участников протокола имеются одинаковые статистически независимые ключи K_{ENC}^{Exp} и K_{MAC}^{Exp} , использующиеся в экспорте и импорте целевого ключа; для разных направлений ключи экспорта и импорта ключа также являются статистически независимыми; для разных криптографических наборов ключевых контейнеров (см. 7.1 и 7.2) применяются разные статистически независимые ключи экспорта и импорта ключа. Ключи, использующиеся в экспорте и импорте целевого ключа, могут вычисляться при помощи функции выработки производных ключей с использованием исходного ключа, загружаемого обоим участникам протокола. Исходные ключи для вычисления базовых ключей и ключей защиты ключевого контейнера должны быть статистически независимыми. Требования к функции выработки производных ключей и к правилам задания входных параметров для вычисления ключей, использующиеся в экспорте и импорте целевого ключа, аналогичны требованиям к функции выработки производных ключей и правилам задания входных параметров для вычисления базовых ключей. Пример загружаемой участнику протокола первичной ключевой информации и вычисления из нее ключей, использующихся в алгоритмах экспорта целевых ключей, а также порядок формирования необходимых идентификаторов, описан в приложении Б.

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

8.6 Для любого ключа, используемого в протоколе, должен производиться учет объема обработанного материала с использованием этого ключа. В том числе должен производиться учет объема обработанного материала для исходного ключа, если он применяется для вычисления базовых ключей, для базовых ключей и для ключей K_{MAC}^{Exp} и K_{ENC}^{Exp} . При достижении максимально допустимого объема обработанного материала для ключа дальнейшее использование этого ключа должно быть невозможно.

8.7 Во всех сообщениях, имеющих опциональное поле AddData, структура этого поля может быть определена разработчиком и выходит за рамки настоящих рекомендаций. В поле AddData запрещено передавать криптографически опасную информацию без обеспечения ее дополнительной защиты; полнота используемых мер защиты определяется в рамках тематических исследований конкретных СКЗИ, реализующих описанный протокол, при оценке соответствия данных СКЗИ требованиям по безопасности информации, предъявляемых к СКЗИ, в соответствии с Р 1323565.1.012-2017 (разделы 4 - 6).

8.8 В запросах передачи произвольных данных (MsgType = 0616) структура поля Data может быть определена разработчиком и выходит за рамки настоящих рекомендаций. В поле Data запрещено передавать криптографически опасную информацию без обеспечения ее дополнительной защиты; полнота используемых мер защиты определяется в рамках тематических исследований конкретных СКЗИ, реализующих описанный протокол, при оценке соответствия данных СКЗИ требованиям по безопасности информации, предъявляемых к СКЗИ, в соответствии с Р 1323565.1.012-2017 (разделы 4 - 6).

8.9 Необходимость использования меток времени (поле TimeStamp из заголовка прикладного сообщения согласно 5.2.1) определяется разработчиком.

8.10 Для обеспечения защиты от навязывания ложных сообщений разработчику необходимо ограничить максимальное количество обрабатываемых сообщений с неправильной имитовставкой в рамках использования одного ключа. Максимальное количество определяется разработчиком с учетом класса защиты конкретных СКЗИ, реализующих протокол Протока, и эксплуатационных характеристик конечной системы, в которой предполагается использовать указанные СКЗИ.

8.11 Максимальный объем материала, который может быть обработан на одном ключе, должен определяться с учетом теоретических ограничений, возникающих при использовании конкретных криптографических алгоритмов, и практических ограничений, возникающих при реализации протокола Протока. Теоретические ограничения на объем материала, который может быть обработан на одном ключе при использовании некоторых вариантов режимов работы блочных шифров согласно ГОСТ Р 34.13-2015 (раздел 5), приведены в Р 1323565.1.005-2017 (раздел 4). Практические ограничения на объем материала, который может быть обработан на одном ключе, должны быть получены в рамках тематических исследований конкретных СКЗИ, реализующих описанный протокол, при оценке соответствия данных СКЗИ требованиям по безопасности информации, предъявляемых к СКЗИ, в соответствии с Р 1323565.1.012-2017 (разделы 4 - 6).

9 Порядок обработки сообщений

Взаимодействие между СКЗИ-потребителем и узлом СВРК строится по схеме запрос — ответ, т.е. сообщение типа ответ отправляется только после того, как было получено соответствующее ему сообщение типа запрос. Для начала взаимодействия необходимо, чтобы все ограничения и условия, изложенные в разделе 8, были удовлетворены и выполнены.

Разрешается формировать очередной запрос, даже если ответ на предыдущий запрос еще не получен.

9.1 Счетчик идентификатора сеанса (SessionID)

9.1.1 Общие положения

До начала взаимодействия оба участника должны установить размер диапазона отслеживаемых значений для идентификаторов сеансов SessionIDWinSize. Областью значений для SessionIDWinSize является диапазон от 1 до 256.

В начале взаимодействия каждый участник инициализирует счетчик идентификатора сеансов, инициатором которых он является, устанавливая его значение в «0», SendSessionID = 0. При формировании запросов в качестве идентификатора сеанса записывается текущее значение счетчика идентификатора сеансов. Счетчик идентификатора сеансов может принимать значения из диапазона от 0 до 232 — 1. Кроме того, каждый участник устанавливает нижнюю и верхнюю границы диапазона отслеживаемых значений для идентификаторов сеансов, инициатором которых является другой участник протокола, RecipSessionIDMin = 0, RecipSessionIDMax = SessionIDWinSize, соответственно.

Значения SendSessionID, RecipSessionIDMin и RecipSessionIDMax соответствуют паре участников, т.е. для связи с разными получателями отправитель должен иметь разные счетчики идентификаторов сеанса.

9.1.2 Правила формирования и проверки счетчиков на узлах отправителя и получателя

Каждый новый запрос отправителя циклически увеличивает значение счетчика идентификатора сеансов SendSessionID на единицу, т.е. при достижении счетчиком SendSessionID значения 232 — 1 следующим значением для счетчика является 0. Значение идентификатора сеансов в ответе должно совпадать со значением идентификатора сеанса из запроса.

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

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

• если с учетом цикличности счетчиков SessionID принадлежит диапазону значений от RecipSessionIDMin до (RecipSessionIDMax + 1024), то руководствуются следующим:

а) если с учетом цикличности счетчиков SessionID больше RecipSessionIDMax, то значение признается корректным и в случае успешного разбора запроса:

1. верхней границе диапазона отслеживаемых значений RecipSessionIDMax присваивается значение SessionID,

2. значение SessionID отмечается как принятое,

3. нижняя граница диапазона отслеживаемых значений RecipSessionIDMin пересчитывается с учетом цикличности счетчика сеансов;

б) иначе

1. если значение SessionID отмечено как непринятое ранее, то значение SessionID признается корректным и в случае успешного разбора запроса отмечается как принятое,

2. если значение SessionID отмечено как принятое ранее, то значение SessionID признается некорректным;

• иначе значение SessionID признается некорректным.

Получатель ответа на запрос проверяет, что значение SessionID в ответе совпадает со значением SessionID в запросе. В случае несовпадения значение SessionID в ответе признается некорректным.

Примечание - С учетом цикличности счетчиков при достижении счетчиком RecipSessionIDMax значения 232 — 1024 + i, где 0 <= i <= 1023, считается, что значения счетчика SessionID от 0 до i являются допустимыми. Нижняя граница диапазона отслеживаемых значений сеансов пересчитывается с учетом цикличности счетчика.

9.2 Порядок формирования и разбора CRISP-сообщения

9.2.1 Порядок формирования CRISP-сообщения

Формирование CRISP-сообщения происходит согласно порядку, описанному в Р 1323565.1.029-2019 (разделы 4, 5), структура CRISP-сообщения и размеры полей определены в 5.1, при этом:

• значения полей ExternalKeyIdFlag, Version, CS и ICV задаются в соответствии с 5.1;
• структура поля KeyID определена в 5.1.4. В качестве значений SenderID и RecipientID используются идентификаторы отправителя и получателя CRISP-сообщения, при этом отправитель и получатель CRISP-сообщения определяются на основе идентификаторов отправителя и получателя прикладного сообщения, указанных в полях SenderID и RecipientID прикладного сообщения;
• правила формирования значения KeyCounter определяются между СКЗИ-потребителем и узлом СВРК заранее, общие правила описаны в 9.2.3, пример формирования значений KeyCounter представлен в приложении Б;
• значение поля SeqNum задается в соответствии с описанием Р 1323565.1.029-2019 (подраздел 4.5) и указанием согласно 5.1.5. При реализации может использоваться строго возрастающий счетчик;
• поле PayloadData формируется путем зашифрования прикладного сообщения в соответствии с Р 1323565.1.029-2019 (подраздел 4.6) и 5.1.

9.2.2 Порядок разбора CRISP-сообщения

Порядок разбора CRISP-сообщения осуществляется согласно Р 1323565.1.029-2019 (подраздел 6), при этом проверяется, что параметры CRISP-сообщения соответствуют 5.1. При разборе CRISP-сообщения выполняется следующая последовательность действий:

• выполняется действие, описанное в перечислении а) подраздела 6.3 Р 1323565.1.029-2019;
• осуществляется проверка идентификатора криптографического набора CRISP, указанного в поле CS согласно 5.1.3; если указанный криптографический набор CRISP не поддерживается получателем, то разбор сообщения прекращается и сообщение отбрасывается, иначе разбор сообщения продолжается;
• осуществляется проверка идентификатора базового ключа, указанного в поле KeyID (KeyCounter), в соответствии с 9.2.3;
• дальнейший порядок действий соответствует перечислениям б) - ж) подраздела 6.3 Р 1323565.1.029-2019.

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

9.2.3 Порядок формирования и проверки значения KeyCounter

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

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

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

Пример идентификации базовых ключей, а также правил формирования и проверки значений KeyCounter описан в приложении Б.

9.3 Порядок формирования прикладного сообщения

Формирование прикладного сообщения происходит в соответствии с 5.2 и осуществляется в два этапа.

На первом этапе формируется заголовок прикладного сообщения, на втором этапе — тело прикладного сообщения.

9.3.1 Порядок формирования заголовка прикладного сообщения

Формирование заголовка прикладного сообщения происходит одинаково для прикладных сообщений всех типов в соответствии со структурой, описанной в 5.2.1, при этом:

а) в поле SenderID указывается идентификатор отправителя прикладного сообщения;

б) в поле RecipientID указывается идентификатор получателя прикладного сообщения;

в) в поле SessionID указывается:

1. если сообщение является запросом, то значение счетчика SendSessionID, который используется для нумерации сеансов отправителя сообщения согласно 9.1,

2. если сообщение является ответом, то значение SessionID, которое указано в запросе;

г) в поле MsgType указывается тип формируемого прикладного сообщения согласно 5.2.1.3;

д) в поле HeaderFlags указывается значение, сформированное в соответствии с 5.2.1.1, следующим образом:

1. указывается, является ли формируемое сообщение сообщением об ошибке или не является,

2. указывается, является формируемое сообщение запросом или ответом;

е) если отправитель поддерживает передачу метки времени, то в поле TimeStamp записывается значение времени формирования сообщения по часам узла-отправителя в POSIX-формате времени; иначе в поле TimeStamp записывается нулевое значение.

В случае формирования запроса значение счетчика SendSessionID циклически увеличивается на единицу согласно 9.1.2.

9.3.2 Порядок формирования тела прикладного сообщения

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

9.3.2.1 Формирование тела ответа с кодом отчета

Формирование данного тела сообщения происходит в соответствии со структурой, указанной в 5.2.2.1.

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

• если в процессе обработки запроса любого типа возникла ошибка. Тогда в поле RepCodesCount записывается общее количество кодов отчета, а в поле RepCodesList — список кодов отчета соответствующих ошибок. Коды отчетов представлены в таблице 5;
• если получен корректный запрос с типом сообщения (0616) (см. 5.2.2.10), то формируется ответ (MsgType = 0616, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»;
• если получен корректный запрос с типом сообщения (0716) (см. 5.2.2.11), то формируется ответ с кодом отчета, в котором в поле RepCodesCount записывается общее количество кодов отчета, а в поле RepCodesList — список кодов отчета, соответствующих ответу на полученный запрос.

Если значение поля RepCodesList предусматривает использование дополнительных данных, то они записываются в поле AddData.

9.3.2.2 Формирование тела запроса параметров работы узла (MsgType = 0116)

Этот запрос может быть сформирован как СКЗИ-потребителем, так и узлом СВРК. Формирование запроса происходит в том случае, если отправителю требуется узнать, какие параметры работы доступны получателю. Полученные в ответном сообщении параметры могут учитываться при формировании последующих сообщений в адрес этого получателя.

Значения полей тела запроса формируются в соответствии с 5.2.2.2.

9.3.2.3 Формирование тела ответа с параметрами работы узла (MsgType = 0116)

В случае успешного разбора запроса параметров работы узла формируется ответ с параметрами работы узла.

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

9.3.2.4 Формирование тела запроса на получение нового ключа (MsgType = 0216)

Запрос на получение нового ключа формируется в СКЗИ-потребителе с целью получения нового ключа, инициатором создания которого является этот СКЗИ-потребитель, а не парный СКЗИ-потребитель. Новый ключ предназначается для указанных в запросе СКЗИ-потребителей. При этом запросу мог предшествовать запрос от СКЗИ-потребителя типа {}_{MsgType \in}{_{02_{16},04_{16}}} , в ответ на который был получен ответ ( {}_{MsgType \in}{_{02_{16},04_{16}}} , LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается».

На СКЗИ-потребителе формирование тела запроса на получение нового ключа происходит согласно 5.2.2.4, и процесс формирования состоит из следующих шагов:

а) в поле PairConID записывается идентификатор парного СКЗИ-потребителя, которому предназначен запрашиваемый ключ;

б) формируется значение поля Flags, для чего указывается наличие или отсутствие дополнительных данных — полей AddDataSize и AddData;

в) если отправитель использует поле Timer, то в нем указывается допустимое время на формирование ответного сообщения, измеряемое в миллисекундах. По истечении этого времени отправитель ожидает или ответное сообщение с ключом, или сообщение (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается»; если отправитель не использует таймер, то в поле Timer записывается нулевое значение;

г) в поле KeySize записывается байтовый размер запрашиваемого ключа;

д) в поле CS_KW записывается идентификатор криптонабора для ключевого контейнера;

е) в поле KeyLabelSize записывается байтовый размер метки ключа:

1. если метка отсутствует, то KeyLabelSize = 0,

2. если KeyLabelSize > 0, то в поле KeyLabel записывается метка ключа. Порядок формирования метки ключа, а также ее точный размер выходят за рамки настоящих рекомендаций;

ж) если в поле Flags указано, что дополнительные данные присутствуют, то поля AddDataSize и AddData заполняются в соответствии с порядком работы СКЗИ-потребителя. Порядок формирования дополнительных данных, а также их точный размер выходят за рамки настоящих рекомендаций;

и) процесс формирования тела запроса считается успешно завершенным.

Заголовок запроса формируется согласно 9.3.1, при этом в поле MsgType записывается значение 0216, а в LSB2(HeaderFlags) — значение 002.

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

9.3.2.5 Формирование тела запроса на получение ранее запрошенного ключа (MsgType = 0316)

Этот запрос формируется в том случае, если СКЗИ-потребителю необходимо получить ключ, который ранее был запрошен у узла СВРК. При этом запросу мог предшествовать запрос типа {}_{MsgType \in}{_{03_{16},04_{16}}} , в ответ на который был получен ответ ( {}_{MsgType \in}{_{03_{16},04_{16}}} , LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается».

На СКЗИ-потребителе формирование тела запроса на получение ранее запрошенного ключа происходит согласно 5.2.2.5, и процесс формирования состоит из следующих шагов:

а) в поле PairConID записывается идентификатор парного СКЗИ-потребителя, которому предназначен запрашиваемый ключ;

б) значение поля Flags формируется следующим образом:

1. указывается наличие или отсутствие поля TargetKeyID,

2. указывается наличие или отсутствие дополнительных данных — полей AddDataSize и AddData;

в) если отправитель использует поле Timer, то в нем указывается допустимое время на формирование ответного сообщения, измеряемое в миллисекундах. По истечении этого времени отправитель ожидает или ответное сообщение с ключом, или сообщение (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается»; если отправитель не использует таймер, то в поле Timer записывается нулевое значение;

г) в поле CS_KW записывается идентификатор криптонабора для ключевого контейнера;

д) в поле KeyLabelSize записывается байтовый размер метки ключа:

1. если метка отсутствует, то KeyLabelSize = 0,

2. если KeyLabelSize > 0, то в поле KeyLabel записывается метка ключа. Порядок формирования метки ключа, а также ее точный размер выходят за рамки настоящих рекомендаций;

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

ж) если в поле Flags указано, что дополнительные данные присутствуют, то поля AddDataSize и AddData заполняются в соответствии с порядком работы СКЗИ-потребителя. Порядок формирования дополнительных данных, а также их точный размер выходят за рамки настоящих рекомендаций;

и) процесс формирования тела запроса считается успешно завершенным.

Заголовок запроса формируется согласно 9.3.1, при этом в поле MsgType записывается значение 0316, а в LSB2(HeaderFlags) — значение 002.

9.3.2.6 Формирование тела запроса на получение нового или ранее запрошенного ключа (MsgType = 0416)

Этот запрос формируется в том случае, если СКЗИ-потребителю необходимо получить ключ, предназначенный для него и парного СКЗИ-потребителя, и идентификатор которого указывается в запросе. При этом не имеет значения, в результате запроса какого СКЗИ-потребителя этот ключ создан. Если соответствующий ключ еще не создан, то его необходимо создать. При этом запросу мог предшествовать запрос от СКЗИ-потребителя типа {}_{MsgType \in}{_{02_{16},04_{16}}} , в ответ на который был получен ответ ( {}_{MsgType \in}{_{02_{16},04_{16}}} , LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается».

На СКЗИ-потребителе формирование тела запроса на получение нового или ранее запрошенного ключа происходит согласно 5.2.2.6, и процесс формирования совпадает с процессом формирования запроса на получение нового ключа, описанным в 9.3.2.4, с единственным отличием в типе ответного сообщения: если поле Timer использовалось в запросе и отведенное время на ожидание ответа истекает, то отправитель ожидает или ответное сообщение с ключом, или сообщение (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается».

Заголовок запроса формируется согласно 9.3.1, при этом в поле MsgType записывается значение 0416, а в LSB2(HeaderFlags) — значение 002.

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

9.3.2.7 Формирование тела ответа на запрос получения ключа

Ответ на запрос получения ключа формируется узлом СВРК в ответ на запрос получения ключа (типы сообщения 0216, 0316, 0416) в случае наличия ключа с атрибутами, которые удовлетворяют значениям, указанным в запросе.

На узле СВРК формирование тела ответа на запрос получения ключа происходит согласно 5.2.2.7, и процесс формирования состоит из следующих шагов:

а) в поле PairConID записывается идентификатор парного СКЗИ-потребителя, которому предназначен запрашиваемый ключ;

б) значение поля Flags формируется следующим образом:

1. указывается, является ли запросивший СКЗИ-потребитель инициатором создания ключа или не является,

2. указывается, ожидается ли подтверждение факта доставки ключа до СКЗИ-потребителя или не ожидается,

3. указывается наличие или отсутствие дополнительных данных — полей AddDataSize и AddData;

в) в поле TargetKeyID записывается идентификатор запрашиваемого ключа;

г) в поле KeySize записывается байтовый размер запрашиваемого ключа;

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

е) в поле KeyLabelSize записывается байтовый размер метки ключа:

1. если метка отсутствует, то KeyLabelSize = 0,

2. если KeyLabelSize > 0, то в поле KeyLabel записывается метка ключа. Порядок формирования метки ключа, а также ее точный размер выходят за рамки настоящих рекомендаций;

ж) в поле KeyContainer записывается ключевой контейнер, соответствующий описанию из раздела 7, для этого:

1. с помощью ключевой информации для формирования ключей, использующихся в алгоритме экспорта и импорта ключа, и текущего значения идентификатора KeyWrapID формируются ключи, применяемые в алгоритме экспорта и импорта ключей K_{MAC}^{Exp} , K_{ENC}^{Exp} ,

2. с использованием ключей K_{MAC}^{Exp} , K_{ENC}^{Exp} и текущего значения синхропосылки IV формируется экспортное представление запрашиваемого ключа Key_Exp с использованием алгоритма, который указан в поле CS_KW,

3. значения KeyWrapID, IV и Key_Exp, записываются в поле KeyContainer,

4. значения KeyWrapID и IV обновляются в соответствии с правилами обновления идентификаторов и синхропосылки; пример формирования этих значений описан в приложении Б;

и) если в поле Flags указано, что дополнительные данные присутствуют, то поля AddDataSize и AddData заполняются в соответствии с порядком работы узла СВРК. Порядок формирования дополнительных данных, а также их точный размер выходят за рамки настоящих рекомендаций;

к) процесс формирования тела ответа считается успешно завершенным.

Заголовок ответа формируется согласно 9.3.1, при этом в поле MsgType записывается значение, соответствующее значению из запроса, а в LSB2(HeaderFlags) — значение 102.

9.3.2.8 Формирование тела запроса на получение случайного числа (MsgType = 0516)

Отправителем этого запроса может выступать как узел СВРК, так и СКЗИ-потребитель в зависимости от параметров работы узлов. Запрос формируется, если отправителю запроса необходимо получить случайное число от получателя запроса. Запрос формируется в соответствии со структурой, описанной в 5.2.2.8.

9.3.2.9 Формирование тела ответа на запрос получения случайного числа

В случае успешного выполнения запроса на получение случайного числа (MsgType = 0516) формируется ответ. Структура ответа соответствует структуре, описанной в 5.2.2.9.

Если для передачи случайного числа используется ключевой контейнер, то он формируется в соответствии с разделом 7. Пример порядка формирования значений поля KeyWrapID описан в приложении Б.

9.3.2.10 Формирование тела запроса передачи произвольных данных (MsgType = 0616)

Отправителем этого запроса может выступать как узел СВРК, так и СКЗИ-потребитель. Запрос такого типа может формироваться, если отправителю запроса необходимо передать произвольные данные. Запрос формируется в соответствии со структурой, описанной в 5.2.2.10.

9.3.2.11 Формирование тела запроса на передачу сервисной информации (MsgType = 0716)

Формирование тела запроса на передачу сервисной информации происходит в соответствии со структурой, указанной в 5.2.2.11.

Запрос на передачу сервисной информации посылается в следующих случаях:

• если отправителю необходимо запросить статус получателя, например для проверки связи. Тогда в поле StatusType записывается код 000016 «Запрос наличия ошибок (ping)»;
• если в порядок работы СКЗИ-потребителя входят оповещения узла СВРК о факте своего отключения и/или подключения к этому узлу СВРК. Тогда на СКЗИ-потребителе формируется сообщение, в котором в поле StatusType записывается код 010116 «Оповестить узел СВРК об отключении СКЗИ-потребителя» или код 010216 «Оповестить узел СВРК о подключении СКЗИ-потребителя». В ответ ожидается сообщение (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»;
• если в порядок работы узла СВРК входят оповещения СКЗИ-потребителя о факте отключения и/или подключения к этому СКЗИ-потребителю. Тогда на узле СВРК формируется сообщение, в котором в поле StatusType записывает код 010316 «Оповестить СКЗИ-потребителя об отключении узла СВРК» или код 010416 «Оповестить СКЗИ-потребителя о подключении узла СВРК». В ответ ожидается сообщение (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»;
• если порядок работы участников протокола предусматривает подтверждение факта доставки ключа до СКЗИ-потребителя. Тогда в случае получения целевых ключей СКЗИ-потребитель в поле StatusType записывает код 020116 «Оповестить узел СВРК о получении ключа», дополнительные данные формирует в соответствии с таблицей 15. В ответ ожидается сообщение (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»;
• если порядок работы участников протокола предусматривает отправку извещений СКЗИ-потребителю о факте изготовления для него целевого ключа. Тогда в случае успешного изготовления целевого ключа узел СВРК в поле StatusType записывает код 020216 «Оповестить СКЗИ-потребителя о изготовлении для него целевого ключа», дополнительные данные формирует в соответствии с таблицей 15. В ответ ожидается сообщение (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было».

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

9.4 Порядок разбора прикладного сообщения

Разбор прикладного сообщения происходит после успешного разбора CRISP-сообщения.

Разбор прикладного сообщения происходит в соответствии с 5.2 и осуществляется в два этапа. На первом этапе выделяется и разбирается заголовок прикладного сообщения, на втором этапе — тело прикладного сообщения.

9.4.1 Порядок разбора заголовка прикладного сообщения

Разбор заголовка прикладного сообщения выполняется одинаково для сообщений всех типов. Разбор состоит из описанных ниже шагов.

Шаг 1 Проверяется значение поля Ver:

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

Шаг 2 Проверяется, что значение поля SenderID (RecipientID) прикладного сообщения указывает на того же участника протокола, что и значение SenderID (RecipientID), переданные в составе CRISP-сообщения в поле KeyID:

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

Шаг 3 Проверяется значение поля MsgType:

а) если у получателя не реализована обработка сообщений указанного типа, то:

1. в случае успешного разбора заголовка будет сформирован ответ с кодом отчета 010116 — «Неизвестный тип сообщения (MsgType)» в соответствии с 5.2.2.1, при этом разбор тела сообщения не осуществляется,

2. если разобрать заголовок не удастся, то разбор заголовка и всего сообщения прекращается;

б) иначе разбор заголовка сообщения продолжается.

Шаг 4 Проверяется значение поля HeaderFlags:

• если значение соответствует структуре 5.2.1.1, то разбор сообщения продолжается;
• иначе разбор заголовка и всего сообщения прекращается.

Шаг 5 Проверяется корректность значения поля SessionID в соответствии с 9.1.2:

• если значение корректно, то осуществляется переход к шагу 6;
• если значение некорректно, то разбор заголовка и всего сообщения прекращается. Сообщение блокируется.

Шаг 6 В зависимости от значения LSB2(HeaderFlags):

• если значение равно 012, то разбор заголовка и всего сообщения прекращается;
• иначе разбор заголовка продолжается.

Шаг 7 Проверяется значение TimeStamp:

а) если режим работы получателя не предусматривает проверку метки времени, то разбор заголовка прикладного сообщения успешно заканчивается;

б) если режим работы получателя предусматривает проверку метки времени, то проверяется, что значение TimeStamp попадает в допустимый временной интервал. Точное значение допустимого временного интервала относительно текущего времени на узле определяется разработчиком. В зависимости от результатов проверки:

1. если проверка пройдена успешно, то разбор заголовка прикладного сообщения успешно заканчивается,

2. если проверка не пройдена, то разбор заголовка и всего сообщения прекращается и далее:

3. если сообщение является запросом, то

• если значение TimeStamp равно нулю, то формируется ответ (LSB2(HeaderFlags) = 112) с кодом отчета 010216 «Отсутствует TimeStamp» в соответствии с 5.2.2.1,
• если значение TimeStamp отлично от нуля, то формируется ответ (LSB2(HeaderFlags) = 112) с кодом отчета 010316 «Неверное значение TimeStamp», в соответствии с 5.2.2.1;

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

В случае успешного разбора заголовка сообщения и отсутствия ошибок начинается разбор тела сообщения в соответствии со значением MsgType. В случае наличия ошибок формируется сообщение с кодом отчета согласно 5.2.2.1, в котором передаются коды отчетов, соответствующие выявленным ошибкам.

9.4.2 Порядок разбора тела прикладного сообщения

Порядок разбора тела сообщения зависит от типа прикладного сообщения (поле MsgType) и значения флагов (поле HeaderFlags). Разбор тела сообщения осуществляется только после успешного разбора заголовка сообщения.

9.4.2.1 Порядок разбора тела ответа с кодом отчета

Это сообщение является ответом. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Извлекается значение из поля RepCodesCount.

Шаг 2 Фиксируются коды отчета из поля RepCodesList в соответствии со значением, указанным в поле RepCodesCount.

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

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

Дальнейшее поведение получателя может зависеть от типа запроса, в ответ на который пришел этот ответ, от значения поля RepCodesList и поля AddData, если они имеются в ответе. Описание дальнейших действий получателя выходит за рамки настоящих рекомендаций.

9.4.2.2 Порядок разбора тела запроса параметров работы узла (MsgType = 0116)

Это сообщение является запросом, который может быть сформирован как СКЗИ-потребителем, так и узлом СВРК.

Разбор тела запроса происходит в соответствии со структурой 5.2.2.2 нижеприведенным образом.

Проверяется значение поля Flags, если соответствующий бит поля Flags указывает на использование опционального поля, то проводят и его. В случае успешного разбора формируется ответ с параметрами работы узла. В случае ошибок в структуре тела сообщения разбор сообщения прекращается, формируется ответ (MsgType = 0116, LSB2(HeaderFlags) = 112) с кодом отчета 020116 «Неверная структура тела сообщения» и отправляется отправителю запроса.

9.4.2.3 Порядок разбора тела ответа с параметрами работы узла (MsgType = 0116)

Разбор тела ответа происходит в соответствии со структурой 5.2.2.3 следующим образом:

а) в соответствии со значением поля Flags фиксируется:

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

2. поддержка отправителем передачи произвольных данных;

3. порядок поддержки отправителем механизма подтверждения доставки ключа,

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

5. наличие или отсутствие в ответе дополнительных данных;

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

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

г) в соответствии со значениями полей KeyMinSize и KeyMaxSize фиксируется поддерживаемый отправителем размер целевых ключей;

д) если в поле Flags указано, что дополнительные данные присутствуют, то происходит разбор полей AddDataSize и AddData. Порядок разбора этих полей выходит за рамки настоящих рекомендаций.

В случае возникновения ошибки разбор ответа прекращается. Если в процессе разбора тела ответа ошибок не возникло, то разбор успешно завершается.

9.4.2.4 Порядок разбора тела запроса на получение нового ключа (MsgType = 0216)

Сообщение является запросом, отправляемым от СКЗИ-потребителя к узлу СВРК. Значения полей извлекаются в соответствии со структурой, описанной в 5.2.2.4. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Проверяется возможность выдать общий ключ на пару СКЗИ-потребителей, указанных в запросе. Пара определяется полями SenderID из заголовка и PairConID из тела запроса. Описание порядка проверки выходит за рамки настоящих рекомендаций. Дальнейший порядок определяется по результатам проверки:

а) если для указанной пары СКЗИ-потребителей ключ создать нельзя, то разбор сообщения прекращается. Формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 030516 «Для указанной пары СКЗИ-потребителей ключ сформировать нельзя» и отправляется отправителю запроса;

б) если ключ создать можно, то происходит проверка значений полей Flags, KeySize, CS_KW, KeyLabelSize на совместимость с режимом работы узла СВРК:

1. если присланные значения несовместимы с режимом работы узла СВРК, то формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета, указывающего на неподходящие значения (020216, 020316, 020416), и отправляется отправителю запроса,

2. если присланные значения совместимы с режимом работы узла СВРК, то выполняется шаг 2.

Шаг 2 Проверяется соответствие атрибутов, имеющихся на узле СВРК ключей (существующих и находящихся в процессе создания), со значениями из запроса, с этой целью сверяются метка ключа (при наличии), указанная в запросе в поле KeyLabel, и инициатор изготовления ключа:

• если ключ с указанной меткой выдавался отправителю запроса ранее, или инициатором создания ключа с такой меткой является не отправитель запроса, или указанная в запросе метка соответствует ключу с атрибутами, отличными от указанных в запросе, то формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 030316 «Повторное использование метки (KeyLabel)» и отправляется отправителю запроса, дальнейший разбор сообщения не производится;
• иначе выполняется шаг 3.

Шаг 3 Проверяется статус ключа на узле СВРК. Дальнейшие действия определяются в зависимости от статуса ключа:

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

б) если ключ, атрибуты которого соответствуют значениям из запроса, создается во время разбора запроса, то при значении Timer > 0 запускается таймер отведенного времени на формирование ответного сообщения в соответствии со значением поля Timer. Иначе (Timer = 0), узел СВРК определяет значение таймера. Параллельно продолжается создание ключа и происходит ожидание, которое прерывается одним из следующих событий:

1. срабатывает таймер отведенного времени на формирование ответного сообщения. В этом случае формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» и отправляется отправителю запроса. Создание ключа продолжается, разбор запроса считается завершенным. Описание дальнейших действий узла СВРК выходит за рамки настоящих рекомендаций,

2. в процессе создания ключа возникает ошибка. В этом случае формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета, который соответствует ошибке и отправляется отправителю запроса. Сохраненные атрибуты ключа удаляются из сопряженных СВРК, описание дальнейших действий выходит за рамки настоящих рекомендаций,

3. ключ создан. В этом случае таймер отведенного времени на формирование ответного сообщения останавливается. Далее выполняется шаг 4;

в) иначе (ключ нужно создать):

1. если Timer > 0, то запускается таймер отведенного времени на формирование ответного сообщения в соответствии со значением поля Timer, иначе (Timer = 0), узел СВРК определяет значение таймера,

2. запускается процесс создания нового ключа, для чего формируются атрибуты будущего целевого ключа (см. раздел 6), в которые записываются значения полей, переданных в запросе, в том числе ключу, сопоставляются идентификаторы СКЗИ-потребителей, для которых этот ключ предназначен, с пометкой, что инициатором создания ключа является отправитель запроса. Создается общий ключ между сопряженными узлами СВРК. Описание порядка создания ключа и синхронизации его атрибутов между двумя узлами СВРК выходят за рамки настоящих рекомендаций,

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

• срабатывает таймер отведенного времени на формирование ответного сообщения. В этом случае формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» и отправляется отправителю запроса. Создание ключа продолжается, разбор запроса считается завершенным. Описание дальнейших действий узла СВРК выходит за рамки настоящих рекомендаций,
• в процессе создания ключа возникает ошибка. В этом случае формируется ответ (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета, который соответствует ошибке, и отправляется отправителю запроса. Сохраненные атрибуты ключа удаляются из сопряженных СВРК, описание дальнейших действий выходит за рамки настоящих рекомендаций,
• ключ создан. В этом случае таймер отведенного времени на формирование ответного сообщения останавливается. Далее выполняется шаг 4.

Шаг 4 Формируется ключевой контейнер для запрашиваемого ключа согласно разделу 7.

Шаг 5 Формируется ответ в соответствии со структурой, описанной в 5.2.2.7. Ключ считается выданным запросившему СКЗИ-потребителю.

Шаг 6 Сопряженный узел СВРК информируется о факте выдачи ключа. Описание процесса информирования выходит за рамки настоящих рекомендаций.

Шаг 7 Процесс разбора запроса успешно завершается.

Если после формирования и отправки ответа (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» в процессе изготовления ключа возникнет ошибка, в результате которой ключ создать не удастся, то сохраненные атрибуты целевого ключа необходимо удалить из сопряженных СВРК. Это необходимо для того, чтобы повторный запрос нового ключа с такими же атрибутами запустил повторную попытку его изготовления.

Примечания

1 Допускается детализировать причину, по которой ключ для указанной в запросе пары СКЗИ-потребителей не может быть сформирован. Для этого вместо ответа (MsgType = 0216, LSB2(HeaderFlags) = 112) с кодом отчета 030516 «Для указанной пары СКЗИ-потребителей ключ сформировать нельзя», может быть отправлен ответ с кодом отчета 030116 «Парный СКЗИ-потребитель не найден (PairConID)» и т.п.

2 Опционально в порядок функционирования узла СВРК может быть заложено, что после создания запрошенного целевого ключа на сопряженных узлах СВРК формируется запрос на передачу сервисной информации (MsgType = 0716) с кодом отчета 020216 «Оповестить СКЗИ-потребителя о изготовлении для него целевого ключа». Этот запрос высылается в адрес СКЗИ-потребителей, для которых предназначен изготовленный ключ и которые не получали этот ключ ранее.

9.4.2.5 Порядок разбора тела запроса на получение ранее запрошенного ключа (MsgType = 0316)

Сообщение является запросом, отправляемым от СКЗИ-потребителя к узлу СВРК. Значения полей извлекаются в соответствии со структурой, описанной в 5.2.2.5. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Проверяется возможность выдать общий ключ на пару СКЗИ-потребителей, указанных в запросе. Пара определяется полями SenderID из заголовка и PairConID из тела запроса. Описание порядка проверки выходит за рамки настоящих рекомендаций. Дальнейший порядок определяется по результатам проверки:

а) если для указанной пары СКЗИ-потребителей ключ выдать нельзя, то разбор сообщения прекращается. Формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета 030516 «Для указанной пары СКЗИ-потребителей ключ сформировать нельзя» и отправляется отправителю запроса;

б) если ключ выдать можно, то происходит проверка значений полей Flags, CS_KW, KeyLabelSize на совместимость с режимом работы узла СВРК:

1. если присланные значения несовместимы с режимом работы узла СВРК, то формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета, указывающего на неподходящие значения (020216, 020316), и отправляется отправителю запроса,

2. если присланные значения совместимы с режимом работы узла СВРК, то проверяется наличие запрашиваемого ключа на узле СВРК следующим образом:

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

Шаг 2 По результатам поиска:

а) если запрашиваемый ключ отсутствует, то дальнейший разбор тела сообщения прекращается. Формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета 030216 «Запрашиваемый ключ отсутствует» и отправляется отправителю запроса;

б) если ключ, атрибуты которого соответствуют значениям из запроса, создан, то в зависимости от настроек СВРК повторная выдача ключа может быть запрещена или разрешена:

1. если настройки узла СВРК позволяют передавать один и тот же целевой ключ в разных ключевых контейнерах, то тогда выполняется шаг 3,

2. если настройки узла СВРК запрещают передавать один и тот же целевой ключ в разных ключевых контейнерах и в запросе указаны метка или идентификатор ключа, то тогда осуществляется проверка, не выдавался ли данному СКЗИ-потребителю этот ключ ранее, следующим образом:

• если ключ выдавался, то дальнейший разбор тела сообщения прекращается. Формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета 030416 «Повторный запрос ключа» и отправляется отправителю запроса,
• если ключ ранее не выдавался данному СКЗИ-потребителю, то тогда выполняется шаг 3;

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

1. если Timer > 0, то запускается таймер отведенного времени на формирование ответного сообщения в соответствии со значением поля Timer; иначе (Timer = 0) узел СВРК определяет значение таймера,

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

• срабатывает таймер отведенного времени на формирование ответного сообщения. В этом случае формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» и отправляется отправителю запроса. Создание ключа продолжается, разбор запроса считается завершенным. Описание дальнейших действий узла СВРК выходит за рамки настоящих рекомендаций,
• в процессе создания ключа возникает ошибка. В этом случае формируется ответ (MsgType = 0316, LSB2(HeaderFlags) = 112) с кодом отчета, который соответствует ошибке, и отправляется отправителю запроса. Сохраненные атрибуты ключа удаляются из сопряженных СВРК, описание дальнейших действий выходит за рамки настоящих рекомендаций,
• ключ создан. В этом случае таймер отведенного времени на формирование ответного сообщения останавливается, далее выполняется шаг 3.

Шаг 3 Формируется ключевой контейнер для запрашиваемого ключа согласно разделу 7.

Шаг 4 Формируется ответ в соответствии со структурой, описанной в 5.2.2.7. Ключ считается выданным запросившему СКЗИ-потребителю.

Шаг 5 Сопряженный узел СВРК информируется о факте выдачи ключа. Описание процесса информирования выходит за рамки настоящих рекомендаций.

Шаг 6 Процесс разбора запроса успешно завершается.

До начала эксплуатации в настройках СВРК должно быть установлено, разрешается или запрещается передавать один и тот же целевой ключ в разных ключевых контейнерах.

Согласно порядку обработки запроса, если в запросе не используется ни метка ключа, ни идентификатор ключа, то в ответ нельзя получить целевой ключ, который был выдан запросившему СКЗИ-потребителю ранее.

9.4.2.6 Порядок разбора тела запроса на получение нового или ранее запрошенного ключа (MsgType = 0416)

Это сообщение является запросом, отправляемым от СКЗИ-потребителя к узлу СВРК. Значения полей извлекаются в соответствии со структурой, описанной в 5.2.2.6. Порядок разбора тела сообщения состоит из описанных ниже шагов.

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

Дальнейший порядок определяется по результатам следующей проверки:

а) если для указанной пары СКЗИ-потребителей ключ выдать нельзя, то разбор сообщения прекращается. Формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 030516 «Для указанной пары СКЗИ-потребителей ключ сформировать нельзя» и отправляется отправителю запроса;

б) если ключ выдать можно, то происходит проверка значений полей Flags, KeySize, CS_KW, KeyLabelSize на совместимость с режимом работы узла СВРК следующим образом:

1. если присланные значения несовместимы с режимом работы узла СВРК, то формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета, указывающего на неподходящие значения (020216, 020316, 020416), и отправляется отправителю запроса,

2. если присланные значения совместимы с режимом работы узла СВРК, то проверяется наличие запрашиваемого ключа на узле СВРК:

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

Шаг 2 По результатам поиска:

а) если ключ, атрибуты которого соответствуют значениям из запроса, создан, то дальнейшие действия зависят от того, выдавался ли запросившему СКЗИ-потребителю ключ ранее:

1. если ключ не выдавался, то выполняется шаг 3,

2. иначе в зависимости от настроек узла СВРК повторная выдача ключа может быть запрещена или разрешена:

• если настройки узла СВРК позволяют передавать один и тот же целевой ключ в разных ключевых контейнерах, то выполняется шаг 3,
• если настройки узла СВРК запрещают передавать один и тот же целевой ключ в разных ключевых контейнерах, то дальнейший разбор тела сообщения прекращается. Формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 030416 «Повторный запрос ключа» и отправляется отправителю запроса;

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

1. если Timer > 0, то запускается таймер отведенного времени на формирование ответного сообщения, в соответствии со значением поля Timer, иначе (Timer = 0), узел СВРК определяет значение таймера,

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

• срабатывает таймер отведенного времени на формирование ответного сообщения. В этом случае формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» и отправляется отправителю запроса. Создание ключа продолжается, разбор запроса считается завершенным. Описание дальнейших действий узла СВРК выходит за рамки настоящих рекомендаций,
• в процессе создания ключа возникает ошибка. В этом случае формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета, который соответствует ошибке, и отправляется отправителю запроса. Сохраненные атрибуты ключа удаляются из сопряженных СВРК, описание дальнейших действий выходит за рамки настоящих рекомендаций,
• ключ создан. В этом случае таймер отведенного времени на формирование ответного сообщения останавливается, далее выполняется шаг 3;

в) при отсутствии ключа, атрибуты которого соответствуют значениям из запроса:

1. если в запросе не указана метка или приведенная метка уникальна в рамках атрибутов ключей для указанной в запросе пары СКЗИ-потребителей, то:

• если Timer > 0, то запускается таймер отведенного времени на формирование ответного сообщения в соответствии со значением поля Timer, иначе (Timer = 0), узел СВРК сам определяет значение таймера,
• запускается процесс создания нового ключа, для чего формируются атрибуты будущего целевого ключа (см. раздел 6), в которые записываются значения полей, переданных в запросе, в том числе ключу сопоставляются идентификаторы СКЗИ-потребителей, для которых этот ключ предназначен, с пометкой, что инициатором создания ключа является отправитель запроса. Создается общий ключ между сопряженными узлами СВРК. Описание порядка создания ключа и синхронизации его атрибутов между двумя узлами СВРК выходят за рамки настоящих рекомендаций,
• параллельно с предыдущими действиями происходит ожидание, которое прерывается одним из следующих событий: - срабатывает таймер отведенного времени на формирование ответного сообщения. В этом случае формируется ответ ( MsgType = 04_{16} , LSB_{2}(HeaderFlags) = 11_{2} ) с кодом отчета 0401_{16} «Запрашиваемый ключ изготавливается» и отправляется отправителю запроса. Создание ключа

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

    рекомендаций,
  - <a id="p101224"></a>в  процессе  создания  ключа  возникает  ошибка.  В   этом   случае

формируется ответ ( MsgType = 04_{16} , LSB_{2}(HeaderFlags) = 11_{2} ) с кодом

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

    рекомендаций,
  - <a id="p101225"></a>ключ  создан.  В  этом  случае  таймер   отведенного   времени   на
    формирование ответного сообщения останавливается. Далее выполняется

шаг 3;

2. иначе разбор тела сообщения прекращается. Формируется ответ (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 030316 «Повторное использование метки (KeyLabel)».

Шаг 3 Формируется ключевой контейнер для запрашиваемого ключа согласно разделу 7.

Шаг 4 Формируется ответ в соответствии со структурой, описанной в 5.2.2.7. Ключ считается выданным запросившему СКЗИ-потребителю.

Шаг 5 Сопряженный узел СВРК информируется о факте выдачи ключа. Описание процесса информирования выходит за рамки настоящих рекомендаций.

Шаг 6 Процесс разбора запроса успешно завершается.

До начала эксплуатации в настройках СВРК должно быть установлено, разрешается или запрещается передавать один и тот же целевой ключ в разных ключевых контейнерах.

Если после формирования и отправки ответа (MsgType = 0416, LSB2(HeaderFlags) = 112) с кодом отчета 040116 «Запрашиваемый ключ изготавливается» в процессе изготовления ключа возникнет ошибка, в результате которой ключ создать не удастся, то сохраненные атрибуты целевого ключа следует удалить из сопряженных СВРК. Это необходимо для того, чтобы повторный запрос нового ключа с такими же атрибутами запустил повторную попытку его изготовления.

Согласно порядку обработки запроса, если в запросе не используется метка ключа, то в ответ нельзя получить целевой ключ, который был выдан запросившему СКЗИ-потребителю ранее.

Примечание - Опционально в порядок функционирования узла СВРК может быть заложено, что после создания запрошенного целевого ключа на сопряженных узлах СВРК формируется запрос на передачу сервисной информации (MsgType = 0716) с кодом отчета 020216 «Оповестить СКЗИ-потребителя о изготовлении для него целевого ключа». Этот запрос высылается в адрес СКЗИ-потребителей, для которых предназначен изготовленный ключ и которые не получали этот ключ ранее.

9.4.2.7 Порядок разбора тела ответа на запрос получения ключа

Это сообщение является ответом, отправляемым от узла СВРК к СКЗИ-потребителю. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Сравниваются значения из запроса и ответа:

• если значения совпадают, то разбор продолжается;
• если хотя бы одна пара значений отличается, то разбор прекращается. Описание дальнейшей работы СКЗИ-потребителя выходит за рамки настоящих рекомендаций.

Шаг 2 Используя алгоритм импорта ключа, описанный в разделе 7, извлекается целевой ключ:

• если алгоритм выполнен успешно, то считается, что запрос ключа завершился успешно. Целевой ключ и его атрибуты сохраняются;
• если алгоритм выполнен с ошибкой (например, не сошлась имитовставка), то считается, что запрос ключа завершился ошибкой. Описание дальнейшей работы СКЗИ-потребителя выходит за рамки настоящих рекомендаций.

Если порядок работы участников протокола предусматривает отправку подтверждения получения СКЗИ-потребителем целевых ключей, то в случае успешного получения целевых ключей СКЗИ-потребитель должен сформировать запрос на передачу сервисной информации (MsgType = 0716, LSB2(HeaderFlags) = 002) с кодом отчета 020116 «Оповестить узел СВРК о получении ключа», дополнительные данные в котором формируются в соответствии с данными таблицы 15. В ответ ожидается ответ (MsgType = 0716 LSB2(HeaderFlags) = 102) с кодом статуса 000016 «Ошибок не было».

9.4.2.8 Порядок разбора тела запроса случайного числа (MsgType = 0516)

Это сообщение является запросом. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Проверяется структура сообщения на соответствие описанию по 5.2.2.8:

• если параметры не соответствуют, то формируется ответ (MsgType = 0516, LSB2(HeaderFlags) = 112) с кодом отчета 020116 «Неверная структура тела сообщения» и отправляется отправителю запроса;
• если параметры соответствуют, то разбор сообщения продолжается.

Шаг 2 В зависимости от значения CS_KW:

а) если CS_KW > 0, то проверяется значение поля CS_KW на совместимость с режимом работы получателя запроса. В зависимости от результатов проверки:

1. если значение подходит, то разбор продолжается,

2. если значение не подходит, то формируется ответ (MsgType = 0516, LSB2(HeaderFlags) = 112) с кодом отчета 020416 «Криптографический набор не поддерживается (CS_KW)» и отправляется отправителю запроса;

б) если CS_KW = 0, то:

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

2. иначе формируется ответ (MsgType = 0516, LSB2(HeaderFlags) = 112) с кодом отчета 020516 «Необходимо использовать ключевой контейнер» и отправляется отправителю запроса.

Шаг 3 Проверяется, что размер случайного числа соответствует структуре сообщения, описанной в 5.2.2.8:

• если параметры соответствуют, то разбор сообщения продолжается;
• если размер не соответствует, то разбор сообщения прекращается. Формируется ответ (MsgType = 0516, LSB2(HeaderFlags) = 112) с кодом отчета 020616 «Размер случайного числа слишком большой» и отправляется отправителю запроса.

Шаг 4 В зависимости от значения поля Flags:

• если LSB1(Flags) = 0, то выполняется шаг 5;
• если LSB1(Flags) = 1, то в запросе должны присутствовать дополнительные данные. Порядок разбора дополнительных данных выходит за рамки настоящих рекомендаций.

Шаг 5 Формируется случайное число указанного в запросе размера. Порядок формирования случайного числа выходит за рамки настоящих рекомендаций.

Шаг 6 Если в запросе указано, что для передачи случайного числа должен использоваться ключевой контейнер, то формируется ключевой контейнер для передачи случайного числа согласно разделу 7.

Шаг 7 Формируется ответ в соответствии со структурой, описанной в 5.2.2.9.

Шаг 8 Процесс разбора запроса успешно завершается.

9.4.2.9 Порядок разбора тела ответа на запрос случайного числа (MsgType = 0516)

Это сообщение является ответом. Порядок разбора тела сообщения состоит из описанных ниже шагов.

Шаг 1 Сравниваются значения полей CS_KW и RNSize из запроса и ответа:

• если значения совпадают, то разбор продолжается;
• если хотя бы одна пара значений отличается, то разбор прекращается. Описание дальнейшей работы СКЗИ-потребителя выходит за рамки настоящих рекомендаций.

Шаг 2 В зависимости от значения CS_KW:

а) если CS_KW = 0, то ключевой контейнер не используется. Случайное число, записанное в поле RandomNumber, сохраняется и считается, что запрос случайного числа завершился успешно;

б) если CS_KW > 0, то к значению поля RandomNumber применяется алгоритм импорта ключа согласно описанию из раздела 7. Извлекается случайное число:

1. если алгоритм выполнен успешно, то считается, что запрос случайного числа завершился успешно. Случайное число сохраняется,

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

9.4.2.10 Порядок разбора запроса передачи произвольных данных (MsgType = 0616)

Это сообщение является запросом. При разборе тела сообщения проверяется, что значение поля DataSize удовлетворяет ограничениям, перечисленным в 5.2.2.10:

• если указанное значение превышает установленное ограничение или по другим причинам данные не могут быть доставлены, то разбор сообщения прекращается. Формируется ответ (MsgType = 0616, LSB2(HeaderFlags) = 112) с кодом отчета 030616 «Данные не могут быть доставлены» и отправляется отправителю запроса;
• если указанное значение не превышает установленное ограничение, то разбор сообщения продолжается. Дальнейшее описание разбора сообщения зависит от специфики использования сообщений этого типа конкретным разработчиком и выходит за рамки настоящих рекомендаций.

9.4.2.11 Порядок разбора тела запроса на передачу сервисной информации (MsgType = 0716)

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

а) если StatusType = 000016, то в зависимости от внутреннего состояния получателя:

1. если в процессе работы получателя ошибки отсутствуют, на которые он хочет указать, то формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было» и отправляется отправителю сообщения,

2. если в процессе работы получателя возникли ошибки, то формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодами отчетов, указывающими на ошибку, и отправляется отправителю запроса;

б) если StatusType = 010116, то:

1. если получателем является узел СВРК, то после осуществления внутренних операций, выходящих за рамки настоящих рекомендаций, формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»;

в) если StatusType = 010216, то:

1. если получателем является узел СВРК и он готов взаимодействовать с СКЗИ-потребителем, отправившим запрос, то после осуществления внутренних операций, выходящих за рамки настоящих рекомендаций, формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос».

г) если StatusType = 010316, то:

1. если получателем является СКЗИ-потребитель, то после осуществления внутренних операций, выходящих за рамки настоящих рекомендаций, формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»;

д) если StatusType = 010416, то:

1. если получателем является СКЗИ-потребитель, то после осуществления внутренних операций, выходящих за рамки настоящих рекомендаций, формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»;

е) если StatusType = 020116, то:

1. если получателем является узел СВРК, то на нем может быть опционально реализован функционал, позволяющий использовать данное сообщение для контроля доставки целевого ключа до СКЗИ-потребителя. Описание конкретного механизма контроля выходит за рамки настоящих рекомендаций. В случае успешного выполнения контроля ожидается, что узел СВРК отправит ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было», иначе ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»;

ж) если StatusType = 020216, то:

1. если получателем является СКЗИ-потребитель, то на нем может быть опционально реализован функционал, позволяющий использовать данное сообщение как его оповещение о подготовке для него целевого ключа. Описание дальнейшего поведения СКЗИ-потребителя выходит за рамки настоящих рекомендаций. Ожидается, что если разбор данного сообщения не приведет к ошибкам, то СКЗИ-потребитель отправит ответ (MsgType = 0716, LSB2(HeaderFlags) = 102) с кодом отчета 000016 «Ошибок не было», иначе ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос»,

2. в остальных случаях формируется ответ (MsgType = 0716, LSB2(HeaderFlags) = 112) с кодом отчета 000116 «Невозможно удовлетворить запрос».

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

КОНТРОЛЬНЫЕ ПРИМЕРЫ

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

Нижний индекс в записи числа обозначает основание системы счисления.

В настоящем приложении двоичные строки из V*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации («||») опускается, т.е. строка a \in V_{4r} будет представлена в виде ar-1 ar-2... a0, где {}_{a_{i} \in}{_{0,1,...,9,a,b,c,d,e,f}} , i = 0,1,...,r — 1. Соответствие между двоичными строками длины 4 и шестнадцатеричными строками длины 1 задается естественным образом (см. таблицу А.1).

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

Преобразование, ставящее в соответствие двоичной строке длины 4r шестнадцатеричную строку длины r, и соответствующее обратное преобразование для простоты записи опускается.

Соответствие между двоичными и шестнадцатеричными строками приведено в таблице А.1.

Примечание - Далее по тексту символ «\» обозначает перенос числа на новую строку.

Таблица А.1

Соответствие между двоичными и шестнадцатеричными строками

Двоичная строка	Шестнадцатеричная строка
0000	0
0001	1
0010	2
0011	3
0100	4
0101	5
0110	6
0111	7
1000	8
1001	9
1010	a
1011	b
1100	c
1101	d
1110	e
1111	f

А.1 Общие параметры

ID СКЗИ1 = 0000000000000000000000000000000a16

ID узла СВРК1 = 0000000000000000000000000000000b16

ID СКЗИ2 = 0000000000000000000000000000000c16

ID узла СВРК2 = 0000000000000000000000000000000d16

Идентификатор базового ключа по направлению от СКЗИ1 к узлу СВРК1:

KeyIdAB = a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000110000100000116

Базовый ключ шифрования CRISP-сообщения, соответствующий идентификатору KeyId от СКЗИ1 к узлу СВРК1:

KAB = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef16

Идентификатор базового ключа по направлению от узла СВРК1 к СКЗИ1:

KeyIdBA = a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000100000100000116

Базовый ключ шифрования CRISP-сообщения, соответствующий идентификатору KeyId от узла СВРК1 к СКЗИ1:

KBA = ffeeddccbbaa99887766554433221100\ f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff16

Идентификатор базового ключа по направлению от СКЗИ2 к узлу СВРК2:

KeyIdCD = a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d000110000100000116

Базовый ключ шифрования CRISP-сообщения, соответствующий идентификатору KeyId от СКЗИ2 к узлу СВРК2:

KCD = 00cd01cd02cd03cd04cd05cd06cd07cd\ 08cd09cd0acd0bcd0ccd0dcd0ecd0fcd16

Идентификатор базового ключа по направлению от узла СВРК2 к СКЗИ2:

KeyIdDC = a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c000100000100000116

Базовый ключ шифрования CRISP-сообщения, соответствующий идентификатору KeyId от узла СВРК2 к СКЗИ2:

KDC = 00dc01dc02dc03dc04dc05dc06dc07dc\ 08dc09dc0adc0bdc0cdc0ddc0edc0fdc16

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

ExternalKeyIdFlag = 02

Version = 0000000000000002

CS = 0116

Поля KeyId и SeqNum задаются текущим состоянием системы СКЗИ-потребитель — узел СВРК. Поля PayloadData и ICV вычисляются после криптографической обработки прикладного сообщения.

А.2 Подключение СКЗИ

Рассматривается сценарий, в котором СКЗИ1 извещает узел СВРК1 о своем подключении к нему.

Для запроса от СКЗИ1 к узлу СВРК1 SessionID = 0000000016.

Шаг 1

В СКЗИ1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000110000100000116

Значение поля SeqNum = 00000000000016

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016;

SenderID = 0000000000000000000000000000000a16

RecipientID = 0000000000000000000000000000000b16

SessionID = 0000000016

MsgType = 0716

HeaderFlags = 0016

TimeStamp = 0000000062782F5016

Поля прикладного сообщения (тело) имеют следующие значения:

StatusType = 010216

Прикладное сообщение = 00000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000000000700\ 0000000062782F50\ 010216

Используя базовый ключ KAB, вычислить ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = ca8963ef815b9efb35b38999c4450789\ 89ac46549c1b3e54cf8fe707753dce3316 KMAC = 480cc9acfc1ac7ee73bf190e9d26dd94\ d29f393f9a1fab6e65bc3f1ea8e7ff7216

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000016 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 564651ce35717a43\ cfde429cb68a9228\ 68c071ced6e6fa21\ 2766b4654bb8b094\ 18ac4662ae372883\ 411a8f8e67263c47\ 1816

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000000\ 564651ce35717a43cfde429cb68a9228\ 68c071ced6e6fa212766b4654bb8b094\ 18ac4662ae372883411a8f8e67263c47\ 1816

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = ebc87f9316.

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000000\ 564651ce35717a43cfde429cb68a9228\ 68c071ced6e6fa212766b4654bb8b094\ 18ac4662ae372883411a8f8e67263c47\ 18\ ebc87f9316

Шаг 2

В СВРК1 формируется CRISP-сообщение с нижеприведенными параметрами:

Значение поля KeyId = a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000100000100000116

Значение поля SeqNum = 00000000000016

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016;

SenderID = 0000000000000000000000000000000b16

RecipientID = 0000000000000000000000000000000a16

SessionID = 0000000016

MsgType = 0716

HeaderFlags = 0216

TimeStamp = 0000000062782F5116

Поля прикладного сообщения (тело) имеют следующие значения:

RepCodesCount = 0116

RepCodesList = 000016

Прикладное сообщение = 00000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000000000702\ 0000000062782F51\ 01000016

Используя базовый ключ KBA, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = d1cb208bf88779f9aa65a589d80c9174\ cc1a74817735c05c6cf0e036f0994b4416 KMAC = bf7b5cdeb7bbff774d5b18180d9e0617\ d9835ccfd75da02d7d5db58a25acd04e16

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000016 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = c66f01339dad962dc44369482f8a5a9b\ 1408130128a0424b2b12616e4017e655\ cb8845311552bd1c16d2055968c50b21\ 5b9216

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000000\ c66f01339dad962dc44369482f8a5a9b\ 1408130128a0424b2b12616e4017e655\ cb8845311552bd1c16d2055968c50b21\ 5b9216

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 40be1c9a16

В итоге следующее CRISP-сообщение отправляется от узла СВРК1 к СКЗИ1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000000\ c66f01339dad962dc44369482f8a5a9b\ 1408130128a0424b2b12616e4017e655\ cb8845311552bd1c16d2055968c50b21\ 5b92\ 40be1c9a16

А.3 Запрос параметров работы у СВРК

Рассматривается сценарий, в котором СКЗИ1 запрашивает у узла СВРК1 параметры его работы. СВРК1 формирует ответ, в котором указывает: при взаимодействии с СКЗИ1 у СВРК1 могут быть запрошены случайные числа; передача произвольных данных не поддерживается; обязательно должны использоваться механизм подтверждения доставки ключа и механизм уведомления об изготовлении ключа; дополнительные данные отсутствуют; размер метки — от 0 до 16 байт; ключевой контейнер использует криптонабор с блочным шифром «Кузнечик», размер целевых ключей от 16 до 64 байт.

Для запроса от СКЗИ1 к узлу СВРК1 SessionID = 0000000116. SessionID для запроса от узла СВРК1 к СКЗИ1 не используется.

Шаг 1

В СКЗИ1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000110000100000116

Значение поля SeqNum = 00000000000116

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000a16

RecipientID = 0000000000000000000000000000000b16

SessionID = 0000000116

MsgType = 0116

HeaderFlags = 0016

TimeStamp = 0000000062782F5216

Поля прикладного сообщения (тело) имеют следующие значения:

Flags = 0016

Прикладное сообщение = 00000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000000010100\ 0000000062782F52\ 0016

Используя базовый ключ KAB, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = ca8963ef815b9efb35b38999c4450789\ 89ac46549c1b3e54cf8fe707753dce3316 KMAC = 480cc9acfc1ac7ee73bf190e9d26dd94\ d29f393f9a1fab6e65bc3f1ea8e7ff7216

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000116 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = f844c3672e64da9b1469c4b9ce45c54f\ 9abebbbc93ded49721177d6de1d719dd\ 3a565c9295b1de9db9fffd65b66a63fd16

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000001\ f844c3672e64da9b1469c4b9ce45c54f\ 9abebbbc93ded49721177d6de1d719dd\ 3a565c9295b1de9db9fffd65b66a63fd16

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 5026bdaa16

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000001\ f844c3672e64da9b1469c4b9ce45c54f\ 9abebbbc93ded49721177d6de1d719dd\ 3a565c9295b1de9db9fffd65b66a63fd\ 5026bdaa16

Шаг 2

В СВРК1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000100000100000116

Значение поля SeqNum = 00000000000116

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000b16

RecipientID = 0000000000000000000000000000000a16

SessionID = 0000000116

MsgType = 0116

HeaderFlags = 0216

TimeStamp = 0000000062782F5316

Поля прикладного сообщения (тело) имеют следующие значения:

Flags = 2916

KeyLabelMinSize = 0016

KeyLabelMaxSize = 1016

CS_KW_List = 0116

KeyMinSize = 001016

KeyMaxSize = 004016

Прикладное сообщение = 00000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000000010102\ 0000000062782F53\ 290010010010004016

Используя базовый ключ KBA, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = d1cb208bf88779f9aa65a589d80c9174\ cc1a74817735c05c6cf0e036f0994b4416 KMAC = bf7b5cdeb7bbff774d5b18180d9e0617\ d9835ccfd75da02d7d5db58a25acd04e16

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000116 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 4b77636f8b4b92176e9b0d366abd7c62\ defc3b635f7d0d6764f2d8b44b3b4adf\ 4fd9e73846fc736864376176be031ab1\ 390616d935f5e916

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000001\ 4b77636f8b4b92176e9b0d366abd7c62\ defc3b635f7d0d6764f2d8b44b3b4adf\ 4fd9e73846fc736864376176be031ab1\ 390616d935f5e916

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = b337fa0216

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000001\ 4b77636f8b4b92176e9b0d366abd7c62\ defc3b635f7d0d6764f2d8b44b3b4adf\ 4fd9e73846fc736864376176be031ab1\ 390616d935f5e9\ b337fa0216

А.4 Получение нового ключа с подтверждением доставки

Рассматривается сценарий, в котором СКЗИ1 запрашивает у узла СВРК1 новый ключ. СВРК1 формирует ответ с ключевым контейнером, в ответе указывается обязательность подтверждения доставки ключа; СКЗИ1 подтверждает доставку, СВРК1 отвечает сообщением со статусом «Ошибок не было».

Для ключевого контейнера используется криптонабор CS_KW=1 (KExp15-KImp15-Kuzn).

Для запроса от СКЗИ1 к узлу СВРК1 SessionID = 0000000216.

Шаг 1

В СКЗИ1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000110000100000116

Значение поля SeqNum = 00000000000216

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000a16

RecipientID = 0000000000000000000000000000000b16

SessionID = 0000000216

MsgType = 0216

HeaderFlags = 0016

TimeStamp = 0000000062782F5416

Поля прикладного сообщения (тело) имеют следующие значения:

PairConID = 0000000000000000000000000000000c16

Flags = 0016

Timer = 0000080016

KeySize = 002016

CS_KW = 0116

KeyLabelSize = 0416

KeyLabel = 00ac000116

Прикладное сообщение = 00000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000000020200\ 0000000062782F54\ 0000000000000000000000000000000c\ 0000000800002001\ 0400ac000116

Используя базовый ключ KAB, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = ca8963ef815b9efb35b38999c4450789\ 89ac46549c1b3e54cf8fe707753dce3316 KMAC = 480cc9acfc1ac7ee73bf190e9d26dd94\ d29f393f9a1fab6e65bc3f1ea8e7ff7216

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000216 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = cee25fe111ad5460624745beaeb72c7d\ 793335e6b084ced7c15ea55b169298bf\ 8ae2cfb158f294d6cff0509ea2649a00\ f603cbc37aa2e5b45e0dfef589d4f64b\ a79b0d69ee5ed385ad416c1716

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000002\ cee25fe111ad5460624745beaeb72c7d\ 793335e6b084ced7c15ea55b169298bf\ 8ae2cfb158f294d6cff0509ea2649a00\ f603cbc37aa2e5b45e0dfef589d4f64b\ a79b0d69ee5ed385ad416c1716

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = f8c37fa116

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000002\ cee25fe111ad5460624745beaeb72c7d\ 793335e6b084ced7c15ea55b169298bf\ 8ae2cfb158f294d6cff0509ea2649a00\ f603cbc37aa2e5b45e0dfef589d4f64b\ a79b0d69ee5ed385ad416c17\ f8c37fa116

Шаг 2

Ключ имитозащиты ключевого контейнера между СКЗИ1 и узлом СВРК1:

Key_{Cont_AB}^{MAC} = 0134123423453456456756786789789a\\ 89ab9abcabcdbcdecdefdef0ef01f01216

Ключ шифрования ключевого контейнера между СКЗИ1 и узлом СВРК1:

Key_{Cont_AB}^{ENC} = 0f1e2d3c4b5a69788796a5b4c3d2e1f0\\ fedcba98765432100123456789abcdef16

KeyWrapID = 000100000100000116

В результате выполнения запроса на СВРК1 сформирован целевой ключ:

KeyA-C = 11112222333344445555666677778888\ 99990000aaaabbbbccccddddeeeeffff16 TargetKeyID = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

В СВРК1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000100000100000116

Значение поля SeqNum = 00000000000216

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000b16

RecipientID = 0000000000000000000000000000000a16

SessionID = 0000000216

MsgType = 0216

HeaderFlags = 0216

TimeStamp = 0000000062782F5516

Поля прикладного сообщения (тело) имеют следующие значения:

PairConID = 0000000000000000000000000000000c16

Flags = 0316

TargetKeyID = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

KeySize = 002016

CS_KW = 0116

KeyLabelSize = 0416

KeyLabel = 00ac000116

KeyContainer = 00010000010000010000000000000001\ 96a170d19e363a8a37c901f9f500330b\ 45c7dff29aed69cc91f84f0143e79bca\ e1de92eff89f511828390d26e89932ea16

KeyContainer состоит из полей, имеющих следующие значения:

KeyWrapID = 000100000100000116

IV = 000000000000000116

Используя ключи Key_{Cont_AB}^{MAC} , Key_{Cont_AB}^{ENC} и IV = 000000000000000116, вычисляется экспортное представление ключа KeyA-C согласно KExp15, определенного в Р 1323565.1.017-2018 (раздел 5), на основе блочного шифра ГОСТ Р 34.12-2015 («Кузнечик»):

Key_Exp = 96a170d19e363a8a37c901f9f500330b\ 45c7dff29aed69cc91f84f0143e79bca\ e1de92eff89f511828390d26e89932ea16 Тогда прикладное сообщение = 00000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000000020202\ 0000000062782F55\ 0000000000000000000000000000000c03\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 0000000000000001\ 0020010400ac0001\ 00010000010000010000000000000001\ 96a170d19e363a8a37c901f9f500330b\ 45c7dff29aed69cc91f84f0143e79bca\ e1de92eff89f511828390d26e89932ea16

Используя базовый ключ KBA, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KMAC = bf7b5cdeb7bbff774d5b18180d9e0617\ d9835ccfd75da02d7d5db58a25acd04e16 KEnc = d1cb208bf88779f9aa65a589d80c9174\ cc1a74817735c05c6cf0e036f0994b4416

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000216 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 9defd483f435c832614220d9460af019\ b769183cff668bf264581c49ec5b9dfd\ bb1cd425d68802e7802ae6d5f3fbfa30\ d4a44b62ca5df58d677608ca271ef344\ 2f3cf2fbf9054ad1c145aacd93c8884c\ b97c7d9b82f82fee4c1bf7267367738a\ 400c6b9e99ef069719b0ef78eb8fe503\ e59b4bbcd8c97606d282aac2f00fd6fb\ 71d2bdc16912bd84aa430317b59583ab\ 42c78994988a772d10e60f603fae53dd\ 19b2f8ab6bbed94686975c233922a89d16

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000002\ 9defd483f435c832614220d9460af019\ b769183cff668bf264581c49ec5b9dfd\ bb1cd425d68802e7802ae6d5f3fbfa30\ d4a44b62ca5df58d677608ca271ef344\ 2f3cf2fbf9054ad1c145aacd93c8884c\ b97c7d9b82f82fee4c1bf7267367738a\ 400c6b9e99ef069719b0ef78eb8fe503\ e59b4bbcd8c97606d282aac2f00fd6fb\ 71d2bdc16912bd84aa430317b59583ab\ 42c78994988a772d10e60f603fae53dd\ 19b2f8ab6bbed94686975c233922a89d16

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = c9d57d3f16

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000002\ 9defd483f435c832614220d9460af019\ b769183cff668bf264581c49ec5b9dfd\ bb1cd425d68802e7802ae6d5f3fbfa30\ d4a44b62ca5df58d677608ca271ef344\ 2f3cf2fbf9054ad1c145aacd93c8884c\ b97c7d9b82f82fee4c1bf7267367738a\ 400c6b9e99ef069719b0ef78eb8fe503\ e59b4bbcd8c97606d282aac2f00fd6fb\ 71d2bdc16912bd84aa430317b59583ab\ 42c78994988a772d10e60f603fae53dd\ 19b2f8ab6bbed94686975c233922a89d\ c9d57d3f16

Шаг 3

Для запроса от СКЗИ1 к узлу СВРК1 SessionID = 0000000316.

В СКЗИ1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000110000100000116

Значение поля SeqNum = 00000000000316

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000a16

RecipientID = 0000000000000000000000000000000b16

SessionID = 0000000316

MsgType = 0716

HeaderFlags = 0016

TimeStamp = 0000000062782F5616

Поля прикладного сообщения (тело) имеют следующие значения:

StatusType = 020116

AddData = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116 Прикладное сообщение = 00000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b000000030700\ 0000000062782F56\ 0201\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

Используя базовый ключ KAB, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = ca8963ef815b9efb35b38999c4450789\ 89ac46549c1b3e54cf8fe707753dce3316 KMAC = 480cc9acfc1ac7ee73bf190e9d26dd94\ d29f393f9a1fab6e65bc3f1ea8e7ff7216

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000316 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 61891624136efefaf0a5032e535138ce\ 64037886e842ab8f9debd3a9241b4070\ 7e8d6f245d6e168f54659c156520cd20\ b6523ffd65012284f4b7b94e51d062ae\ dfa1193cff5f3b00b54233fc14ffe6b5\ 419c66c72084f4523516

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000003\ 61891624136efefaf0a5032e535138ce\ 64037886e842ab8f9debd3a9241b4070\ 7e8d6f245d6e168f54659c156520cd20\ b6523ffd65012284f4b7b94e51d062ae\ dfa1193cff5f3b00b54233fc14ffe6b5\ 419c66c72084f4523516

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 0644953c16

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0a000000000000000000000000000000\ 0b0001100001000001\ 000000000003\ 61891624136efefaf0a5032e535138ce\ 64037886e842ab8f9debd3a9241b4070\ 7e8d6f245d6e168f54659c156520cd20\ b6523ffd65012284f4b7b94e51d062ae\ dfa1193cff5f3b00b54233fc14ffe6b5\ 419c66c72084f45235\ 0644953c16

Шаг 4

В СВРК1 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000100000100000116

Значение поля SeqNum = 00000000000316

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000b16

RecipientID = 0000000000000000000000000000000a16

SessionID = 0000000316

MsgType = 0716

HeaderFlags = 0216

TimeStamp = 0000000062782F5716

Поля прикладного сообщения (тело) имеют следующие значения:

RepCodesCount = 0116

RepCodesList = 000016

Прикладное сообщение = 00000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a000000030702\ 0000000062782F57\ 01000016

Используя базовый ключ KBA, вычислить ключ шифрования KEnc и ключ имитовставки KMAC:

KMAC = bf7b5cdeb7bbff774d5b18180d9e0617\ d9835ccfd75da02d7d5db58a25acd04e16 KEnc = d1cb208bf88779f9aa65a589d80c9174\ cc1a74817735c05c6cf0e036f0994b4416

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000316 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 90b5af37e45ebc480b525c5d71357480\ e9738e25d73e98c6c1c06eb88d17dfa2\ 11a4ebc3dfd2e815fc7e406670745fc1\ 83ff16

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000003\ 90b5af37e45ebc480b525c5d71357480\ e9738e25d73e98c6c1c06eb88d17dfa2\ 11a4ebc3dfd2e815fc7e406670745fc1\ 83ff16

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = c188190616

В итоге следующее CRISP-сообщение отправляется от узла СВРК1 к СКЗИ1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0b000000000000000000000000000000\ 0a0001000001000001\ 000000000003\ 90b5af37e45ebc480b525c5d71357480\ e9738e25d73e98c6c1c06eb88d17dfa2\ 11a4ebc3dfd2e815fc7e406670745fc1\ 83ff\ c188190616

А.5 Оповещение об изготовлении ключа и получение ранее запрошенного ключа

Рассматривается сценарий, в котором СВРК2 оповещает СКЗИ2 о том, что изготовлен новый ключ. СКЗИ2 подтверждает получение сообщения; СКЗИ2 запрашивает изготовленный ключ у СВРК2, СВРК2 формирует ответ с ключевым контейнером, в ответе указывается, что доставку подтверждать необязательно.

Для ключевого контейнера используется криптонабор CS_KW=1 (KExp15-KImp15-Kuzn).

Шаг 1

Для запроса от узла СВРК2 к СКЗИ2 SessionID = 0000000216.

В СВРК2 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c000100000100000116

Значение поля SeqNum = 00000000000216

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000d16

RecipientID = 0000000000000000000000000000000c16

SessionID = 0000000216

MsgType = 0716

HeaderFlags = 0016

TimeStamp = 0000000062782F6016

Поля прикладного сообщения (тело) имеют следующие значения:

StatusType = 020216

AddData = 0000000000000000000000000000000a\ 0020\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116 Прикладное сообщение = 00000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c000000020700\ 0000000062782F60\ 0202\ 0000000000000000000000000000000a\ 0020\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

Используя базовый ключ KDC, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KMAC = dada11eeab98b188ae2c4d82cdf80bd2\ 223a760692cdc0d58a565f75b0388c6916 KEnc = aa8efaf1aaf0b4bab1d8ec2884a3ade5\ f0f350e1abbcd8d159fe1d16119ac1b616

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000216 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = f63ac05d0979ee357ae7d23cf3656f98\ a9d67d0e951d12ececba7115a3126649\ 223e89749cb5f177686e9d289faab681\ 11f5367e606bd946cd2d1485d7a35fdd\ afb4a575d65621bd81e12238bcc73f38\ ced9368748a9e5b231a8547b5378ca94\ 88d9b820599be7ccd9a5d316

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c0001000001000001\ 000000000002\ f63ac05d0979ee357ae7d23cf3656f98\ a9d67d0e951d12ececba7115a3126649\ 223e89749cb5f177686e9d289faab681\ 11f5367e606bd946cd2d1485d7a35fdd\ afb4a575d65621bd81e12238bcc73f38\ ced9368748a9e5b231a8547b5378ca94\ 88d9b820599be7ccd9a5d316

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 4ea77bdc16

В итоге следующее CRISP-сообщение отправляется от узла СВРК2 к СКЗИ2:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c0001000001000001\ 000000000002\ f63ac05d0979ee357ae7d23cf3656f98\ a9d67d0e951d12ececba7115a3126649\ 223e89749cb5f177686e9d289faab681\ 11f5367e606bd946cd2d1485d7a35fdd\ afb4a575d65621bd81e12238bcc73f38\ ced9368748a9e5b231a8547b5378ca94\ 88d9b820599be7ccd9a5d3\ 4ea77bdc16

Шаг 2

В СКЗИ2 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d000110000100000116

Значение поля SeqNum = 00000000000216

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000c16

RecipientID = 0000000000000000000000000000000d16

SessionID = 0000000216

MsgType = 0716

HeaderFlags = 0216

TimeStamp = 0000000062782F6116

Поля прикладного сообщения (тело) имеют следующие значения:

RepCodesCount = 0116

RepCodesList = 000016

Прикладное сообщение = 00000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d000000020702\ 0000000062782F61\ 01000016

Используя базовый ключ KCD, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = 092825d33633b481e38c4cc5bb95a359\ 94c2a50a2d75dc49ca19c631b1bf162516 KMAC = b465ba1687df794973daffd372e29355\ ed2e1e456d176ce3641a410220ae373616

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000216 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 30c0ec9c3c945c806bdbe74cc7408833\ c49cd8087871aeb4f87cb05d8910adf8\ a9951f641541317e27c4c15799b9fb2b\ fd2b16

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d0001100001000001\ 000000000002\ 30c0ec9c3c945c806bdbe74cc7408833\ c49cd8087871aeb4f87cb05d8910adf8\ a9951f641541317e27c4c15799b9fb2b\ fd2b16

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 5f81245716

В итоге следующее CRISP-сообщение отправляется от СКЗИ2 к узлу СВРК2:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d0001100001000001\ 000000000002\ 30c0ec9c3c945c806bdbe74cc7408833\ c49cd8087871aeb4f87cb05d8910adf8\ a9951f641541317e27c4c15799b9fb2b\ fd2b\ 5f81245716

Шаг 3

Для запроса от СКЗИ2 к СВРК2 SessionID = 0000000316.

В СКЗИ2 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d000110000100000116

Значение поля SeqNum = 00000000000316

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000c16

RecipientID = 0000000000000000000000000000000d16

SessionID = 0000000316

MsgType = 0316

HeaderFlags = 0016

TimeStamp = 0000000062782F6216

Поля прикладного сообщения (тело) имеют следующие значения:

PairConID = 0000000000000000000000000000000a16

Flags = 0116

Timer = 0000080016

CS_KW = 0116

KeyLabelSize = 0016

TargetKeyID = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116 Прикладное сообщение = 00000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d000000030300\ 0000000062782F62\ 0000000000000000000000000000000a\ 01000008000100\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

Используя базовый ключ KCD, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = 092825d33633b481e38c4cc5bb95a359\ 94c2a50a2d75dc49ca19c631b1bf162516 KMAC = b465ba1687df794973daffd372e29355\ ed2e1e456d176ce3641a410220ae373616

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования по ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000316 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = 8131abadc9f3d30e2a1cef5b695c3bdf\ fca87f1861813b75e9c7868dda5493f1\ 18203b79129079b7caeb6206d611a09d\ dd051cfeabc6573f5b42a55151f5c570\ 417f30750a8661bb2e6e6efd6687451e\ 54a9de370bb5f466fd79aa18177ea1c7\ 541f3d8ddc2737f337290633dd2016

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d0001100001000001\ 000000000003\ 8131abadc9f3d30e2a1cef5b695c3bdf\ fca87f1861813b75e9c7868dda5493f1\ 18203b79129079b7caeb6206d611a09d\ dd051cfeabc6573f5b42a55151f5c570\ 417f30750a8661bb2e6e6efd6687451e\ 54a9de370bb5f466fd79aa18177ea1c7\ 541f3d8ddc2737f337290633dd2016

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = 061f7d7816

В итоге следующее CRISP-сообщение отправляется от СКЗИ2 к узлу СВРК2:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0c000000000000000000000000000000\ 0d0001100001000001\ 000000000003\ 8131abadc9f3d30e2a1cef5b695c3bdf\ fca87f1861813b75e9c7868dda5493f1\ 18203b79129079b7caeb6206d611a09d\ dd051cfeabc6573f5b42a55151f5c570\ 417f30750a8661bb2e6e6efd6687451e\ 54a9de370bb5f466fd79aa18177ea1c7\ 541f3d8ddc2737f337290633dd20\ 061f7d7816

Шаг 4

Ключ имитозащиты ключевого контейнера между СКЗИ2 и узлом СВРК2:

Key_{Cont_DC}^{MAC} = 00000000111111112222222233333333\\ 4444444455555555666666667777777716

Ключ шифрования ключевого контейнера между СКЗИ1 и узлом СВРК1:

Key_{Cont_DC}^{ENC} = 8888888899999999aaaaaaaabbbbbbbb\\ ccccccccddddddddeeeeeeeeffffffff16

KeyWrapID = 000100000100000116.

На СВРК2 сформирован целевой ключ:

KeyA-C = 11112222333344445555666677778888\ 99990000aaaabbbbccccddddeeeeffff16 TargetKeyID = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

KeyLabel = 00ac000116

В СВРК2 формируется CRISP-сообщение с нижеприведенными параметрами.

Значение поля KeyId = a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c000100000100000116

Значение поля SeqNum = 00000000000316

Поля прикладного сообщения (заголовок) имеют следующие значения:

Ver = 0016

SenderID = 0000000000000000000000000000000d16

RecipientID = 0000000000000000000000000000000c16

SessionID = 0000000316

MsgType = 0316

HeaderFlags = 0216

TimeStamp = 0000000062782F6316

Поля прикладного сообщения (тело) имеют следующие значения:

PairConID = 0000000000000000000000000000000a16

Flags = 0016

TargetKeyID = 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 000000000000000116

KeySize = 002016

CS_KW = 0116

KeyLabelSize = 0416

KeyLabel = 00ac000116

KeyContainer = 00010000010000010000000000000001\ 2c46049a859158eb26b346521bae6c60\ 1851454ad2b3c7754f12cc1b1678169f\ 43f0bdf94bdfee46c3ff2777a6285cd416.

KeyContainer состоит из полей, имеющих следующие значения:

KeyWrapID = 000100000100000116

IV = 000000000000000116

Используя ключи Key_{Cont_DC}^{MAC} , Key_{Cont_DC}^{ENC} и IV = 000000000000000116, вычисляется экспортное представление ключа KeyA-C согласно KExp15, определенного в Р 1323565.1.017-2018 (раздел 5), на основе блочного шифра ГОСТ Р 34.12-2015 («Кузнечик»):

Key_Exp = 2c46049a859158eb26b346521bae6c60\ 1851454ad2b3c7754f12cc1b1678169f\ 43f0bdf94bdfee46c3ff2777a6285cd416 тогда прикладное сообщение = 00000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c000000030302\ 0000000062782F63\ 0000000000000000000000000000000a00\ 0000000000000000000000000000000b\ 0000000000000000000000000000000d\ 0000000000000001\ 0020010400ac0001\ 00010000010000010000000000000001\ 2c46049a859158eb26b346521bae6c60\ 1851454ad2b3c7754f12cc1b1678169f\ 43f0bdf94bdfee46c3ff2777a6285cd416

Используя базовый ключ KDC, вычисляется ключ шифрования KEnc и ключ имитовставки KMAC:

KEnc = aa8efaf1aaf0b4bab1d8ec2884a3ade5\ f0f350e1abbcd8d159fe1d16119ac1b616 KMAC = dada11eeab98b188ae2c4d82cdf80bd2\ 223a760692cdc0d58a565f75b0388c6916

Используя блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 (раздел 5) в режиме гаммирования согласно ГОСТ Р 34.13-2015 (подраздел 5.2), IV = 0000000316 и ключ шифрования KEnc, вычисляется значение поля PayloadData:

PayloadData = dbef7bf8ad677760e914243a1cce2f8e\ e78b1f095d0cab01ec23446d687942b6\ 2760bd2628dcf32425f482cdb666e5a3\ 00c0875be077b8b37c5ad8af5c35f58a\ 5a04c9e35a5caad9e4a755afdcefe85d\ 6501d3156ebdcd2b59200d267adf43c7\ 513ad2ba03cde80abd87563dde1e9d3e\ 48bf71c0e1fe98ff3da4d7cc178ab2f3\ 5271c84f7ed335a52ba50b271f751981\ aa2ac559cdc1a94cd900ab682d17a720\ 8841cc991bc0f243c5e73e664c690afe16

В итоге получается следующее сообщение M:

M = 000001\ a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c0001000001000001\ 000000000003\ dbef7bf8ad677760e914243a1cce2f8e\ e78b1f095d0cab01ec23446d687942b6\ 2760bd2628dcf32425f482cdb666e5a3\ 00c0875be077b8b37c5ad8af5c35f58a\ 5a04c9e35a5caad9e4a755afdcefe85d\ 6501d3156ebdcd2b59200d267adf43c7\ 513ad2ba03cde80abd87563dde1e9d3e\ 48bf71c0e1fe98ff3da4d7cc178ab2f3\ 5271c84f7ed335a52ba50b271f751981\ aa2ac559cdc1a94cd900ab682d17a720\ 8841cc991bc0f243c5e73e664c690afe16

Используя ключ имитовставки KMAC, вычисляется имитовставка ICV для сообщения M согласно ГОСТ Р 34.13-2015 («Магма»):

ICV = a77aee8b16

В итоге следующее CRISP-сообщение отправляется от СКЗИ1 к узлу СВРК1:

CRISP-сообщение = 000001\ a8000000000000000000000000000000\ 0d000000000000000000000000000000\ 0c0001000001000001\ 000000000003\ dbef7bf8ad677760e914243a1cce2f8e\ e78b1f095d0cab01ec23446d687942b6\ 2760bd2628dcf32425f482cdb666e5a3\ 00c0875be077b8b37c5ad8af5c35f58a\ 5a04c9e35a5caad9e4a755afdcefe85d\ 6501d3156ebdcd2b59200d267adf43c7\ 513ad2ba03cde80abd87563dde1e9d3e\ 48bf71c0e1fe98ff3da4d7cc178ab2f3\ 5271c84f7ed335a52ba50b271f751981\ aa2ac559cdc1a94cd900ab682d17a720\ 8841cc991bc0f243c5e73e664c690afe\ a77aee8b16

А.6 Пример вычисления производных ключей

Рассматривается пример вычисления производных ключей при помощи способа, описанного в Б.5 (приложение Б). В качестве блочного шифра используется шифр согласно ГОСТ Р 34.12-2015 («Кузнечик»). Количество производных ключей определяется выбранным значением параметра Z, в примере выбрано Z = 219, тем самым число ключей равно 240. Схематично вычисление производных ключей из ключа MK при помощи способа, описанного в Б.5 (приложении Б), изображено на рисунке А.1.

Рисунок А.1 — Вычисление производных ключей

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

Ниже приведены значения параметров и вычисленные производные ключи, предназначенные для защиты CRISP-сообщений, передаваемых между СКЗИ1 и СВРК1 с идентификаторами IDСКЗИ и IDСВРК соответственно. Обозначение CMAC(K,P(i)) соответствует функции ГОСТ Р 34.12-2015 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015 (подраздел 5.6) с длиной имитовставки 128 бит, с ключом K и исходным сообщением P(i).

А.6.1 Общие параметры

MK = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef16; Label = name | IDСВРК | IDСКЗИ | IDMK; name = Binary(«cr»); IDСВРК = 0000000000000000000000000000000b16; IDСКЗИ = 0000000000000000000000000000000a16; IDMK = 000016; R = 4.

А.6.2 Вычисление ключей K_{i}^{0} , i = 1,...,220.

seed0 = 0000000016; KDF(Kin,label,seed0,R) = K(1) || K(2) || K(3) || ...; K(i) = CMAC(MK,P(i)); K_{1}^{0} = K(1)\|\|K(2) ; P(1) = 00000001\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(1) = d89c9617a313e842fd252be1dc6e046f16; P(2) = 00000002\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(2) = f48ec17885bd11610d12102c47d2c5e916; K_{1}^{0} = d89c9617a313e842fd252be1dc6e046f\\ f48ec17885bd11610d12102c47d2c5e916.
K_{2}^{0} = K(3)\|\|K(4) ; P(3) = 00000003\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(3) = f61f628b484a99ea9d545d6cac44f73016; P(4) = 00000004\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(4) = 8ed660b4b1209edb67bd95f8d7c06ee616; K_{2}^{0} = f61f628b484a99ea9d545d6cac44f730\\ 8ed660b4b1209edb67bd95f8d7c06ee616. ... K_{2^{20}}^{0} = K(2^{21} - 1)\|\|K(2^{21}) ;
P(221 — 1) = 001fffff\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(221 — 1) = b94067e4f5cf7e9eca3c31052ea4ced016; P(221) = 00200000\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000000\ 1000000016; K(221) = c79e8ed44b023d189205cbf27aa44e8216; K_{2^{20}}^{0} = b94067e4f5cf7e9eca3c31052ea4ced0\\ c79e8ed44b023d189205cbf27aa44e8216.

А.6.3 Вычисление ключей K_{t}^{j} , j = 1,...,220, t = 1,...,220.

seedj = j, j = 1,...,220; KDF( K_{j}^{0} ,label,seedj,R) = Kj(1) || Kj(2) || Kj(3) || ...; Kj(i) = CMAC( K_{j}^{0} ,Pj(i)); K_{1}^{1} = K^{1}(1)\|\|K^{1}(2) ; seed1 = 0000000116; P1(1) = 00000001\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000001\ 1000000016; K1(1) = 028c9c5072e33b33ff612abddb5340d116; P1(2) = 00000002\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000001\ 1000000016; K1(2) = 272b9260fc5745284ccfea6ad7a9235c16;
K_{1}^{1} = 028c9c5072e33b33ff612abddb5340d1\\ 272b9260fc5745284ccfea6ad7a9235c16. ... K_{2^{20}}^{1} = K^{1}(2^{21} - 1)\|\|K^{1}(2^{21}) ; P1(221 — 1) = 001fffff\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000001\ 1000000016; K1(221 — 1) = e1cd50910956c1ba460790fa9161313916; P1(221) = 00200000\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00000001\ 1000000016; K1(221) = 7ad3b231a5ab5f3b23960cae23d1b27716; K_{2^{20}}^{1} = e1cd50910956c1ba460790fa91613139\\ 7ad3b231a5ab5f3b23960cae23d1b27716.
... seed_{2^{20}} = 00100000_{16} ; K_{1}^{2^{20}} = K^{2^{20}}(1)\|\|K^{2^{20}}(2) ; P^{2^{20}}(1) = 00000001\\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00100000\ 1000000016; K^{2^{20}}(1) = d01977f68c37fbb6393c7c2c22436705_{16} ; P^{2^{20}}(2) = 00000002\\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00100000\ 1000000016; K^{2^{20}}(2) = 645829965d5d3158a5408906ac077465_{16} ;
K_{1}^{2^{20}} = d01977f68c37fbb6393c7c2c22436705\\ 645829965d5d3158a5408906ac07746516. ... K_{2^{20}}^{2^{20}} = K^{2^{20}}(2^{21} - 1)\|\|K^{2^{20}}(2^{21}) ; P^{2^{20}}(2^{21} - 1) = 001fffff\\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00100000\ 1000000016; K^{2^{20}}(2^{21} - 1) = 813b6da6c46824e733d0ef40efaab058_{16} ; P^{2^{20}}(2^{21}) = 00200000\\ 6372\ 0000000000000000000000000000000b\ 0000000000000000000000000000000a\ 0000\ 00\ 00100000\ 1000000016; K^{2^{20}}(2^{21}) = 65de422573b7b9fd18457fbe32e18ad4_{16} ; K_{2^{20}}^{2^{20}} = 813b6da6c46824e733d0ef40efaab058\\ 65de422573b7b9fd18457fbe32e18ad416.

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

ПРИМЕР КЛЮЧЕВОЙ СИСТЕМЫ

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

• два симметричных ключа вместе со своими атрибутами в составе транспортного ключевого контейнера доверенным способом доставляются на узел СВРК и на подключенный к нему СКЗИ-потребитель. Дополнительно защита транспортного ключевого контейнера обеспечивается при помощи низкоэнтропийного секрета (пароля);
• при помощи первого ключа вычисляются производные ключи, которые предназначены для защиты CRISP-сообщений, формируемых как СКЗИ-потребителем, так и узлом СВРК;
• при помощи второго ключа вычисляются производные ключи, предназначенные для формирования экспортного представления ключей и случайных чисел, которые могут пересылаться между СКЗИ-потребителем и узлом СВРК.

Детальное описание используемых в схеме механизмов представлено в разделах Б.1 - Б.7.

Б.1 Условия и ограничения

Максимальное количество производных ключей, которое может быть выработано из одного ключа, зависит от многих факторов: конкретной функции выработки ключей, класса защиты СКЗИ, в котором реализуется выработка производных ключей, условий эксплуатации этого СКЗИ и т.д. В связи с этим в данном примере максимальное количество производных ключей задается параметрически, т.е. зависит от настраиваемого параметра, который обозначается по тексту символом Z, при этом Z — целое положительное число, с учетом предполагаемого размера полей Z <= 223 — 1.

Б.2 Состав транспортного ключевого контейнера

В качестве транспортного ключевого контейнера используется PFX-контейнер, который формируется в соответствии с Р 1323565.1.041-2022 (раздел 8) и Р 1323565.1.025-2019 (разделы 4 - 14). Ключи защиты контейнера вычисляются из пароля при помощи функции PBKDF2, описанной в Р 1323565.1.040-2022 (подраздел 7.1). Структура транспортного ключевого контейнера описана в Б.3. Целостность данных, передаваемых в транспортном ключевом контейнере, обеспечивается в соответствии с Б.4.4. Зашифрование и расшифрование защищенных разделов происходит в соответствии с Б.4.2 и Б.4.3. В совокупности в транспортном ключевом контейнере передаются следующие значения:

• идентификатор блочного шифра, который используется при вычислении производных ключей (см. Б.5), обозначается ID_{cipher} \in V_{8} . При этом IDcipher = 1 соответствует ГОСТ Р 34.12-2015 («Магма») с OID = «1.2.643.7.1.1.5.1» (id-tc26-cipher-gostr3412-2015-magma), а IDcipher = 2 - ГОСТ Р 34.12-2015 («Кузнечик») с OID = «1.2.643.7.1.1.5.2» (id-tc26-cipher-gostr3412-2015-kuznyechik);
• симметричные ключи, предназначенные для выработки производных ключей, обозначаются MK1 и MK2, при этом MK1, MK_{2} \in V_{256} . В контейнере передаются не сами ключи MK1, MK2, а их защищенное представление;
• ключам MK1 и MK2 соответствуют идентификаторы: ID_{MK_{1}} идентификатор MK1, ID_{MK_{2}} идентификатор MK2, при этом ID_{MK_{1}} , ID_{MK_{2}} \in V_{16} . Предполагается, что идентификаторы в системе будут задаваться циклическим возрастающим счетчиком;
• случайные значения S1, S2, S3, которые используются в качестве параметра функции PBKDF2, при этом S1, S2, S_{3} \in V_{256} ;
• синхропосылки IV1 и IV2, которые используются при шифровании ключей в составе контейнера, при этом размер значений зависит от блочного шифра, которым осуществляется шифрование: для шифрования по ГОСТ Р 34.12-2015 («Кузнечик») IV1, IV_{2} \in V_{64} , а для шифрования по ГОСТ Р 34.12-2015 («Магма») IV1, IV_{2} \in V_{32} ;
• счетчик числа итераций c, который используется в качестве параметра функции PBKDF2. Конкретные значения параметра c должны определяться в зависимости от условий эксплуатации и длины пароля (рекомендуемые значения приведены в Р 1323565.1.040-2022 приложение А);
• требуемая длина выходной последовательности в байтах dkLen, которая определяет размер ключа, получаемого из пароля. В данном примере dkLen = 32;
• случайные значения ukm1 и ukm2, которые используются для вычисления производных ключей из парольного ключа, при этом ukm1, ukm_{2} \in V_{64} ;
• идентификаторы узлов: IDСВРК и IDСКЗИ, при этом IDСВРК, ID_{\text{СКЗИ}} \in V_{128} .

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

Б.3 Структура транспортного ключевого контейнера

Описанный в примере транспортный ключевой контейнер разделен на три части: раздел с открытыми данными и два раздела с защищенными данными. В разделе с открытыми данными содержатся атрибуты, которые используются при вычислении ключей из пароля, и атрибуты, которые используются при шифровании защищенных разделов. В защищенных разделах в зашифрованном виде находятся пересылаемые симметричные ключи и их идентификаторы. Поля транспортного ключевого контейнера, не описанные в данном разделе, заполняются в соответствии с Р 1323565.1.041-2022 (разделы 4 - 11) и Р 1323565.1.025-2019 (разделы 4 - 14).

Процесс создания транспортного ключевого контейнера состоит из следующих шагов:

а) формируются три экземпляра структуры SafeContents SC1, SC2, SC3 следующим способом:

1. структура SC1 содержит структуру SafeBag SB1 типа secretBag (значение {bagtypes 5}), поле bagAttributes отсутствует; поле bagValue структуры SB1 содержит поле secretTypeId со значением id-data, поле bagValue структуры SB1 содержит поле secretValue, в которое записываются открытые атрибуты, определенные в Б.2, в следующем порядке:

IDcipher, S1, S2, S3, IV1, IV2, ID_{MK_{1}} , ID_{MK_{2}} , c, dkLen, ukm1, ukm2, IDСВРК, IDСКЗИ,

2. структура SC2 содержит структуру SafeBag SB2 типа secretBag (значение {bagtypes 5}), поле bagAttributes отсутствует; поле bagValue структуры SB2 содержит поле secretTypeId со значением id-data, поле bagValue структуры SB2 содержит поле secretValue, в которое записывается ключевой контейнер со значением MK1,

3. структура SC3 формируется аналогично структуре SC2, в нее записывается ключевой контейнер со значением MK2;

б) для SC1 создается структура ContentInfo CI1 типа «простые данные» (id-data). Поле content в составе структуры CI1 представляет собой OCTET STRING и содержит BER-закодированное значение структуры SC1 (включая тег, длину и значения октетов);

в) для SC2 создается структура ContentInfo CI2 типа «зашифрованные данные» (EncryptedData). Поле encryptedContentInfo структуры CI2 содержит поле contentType со значением id-data, а поле encryptedContent содержит зашифрованное BER-закодированное значение структуры SC2 (включая тег, длину и значения октетов). В структуре contentEncryptionAlgorithm структуры encryptedContentInfo в соответствующем поле указывается идентификатор одного из следующих алгоритмов id-gostr3412-2015-magma-ctracpkm-omac или id-gostr3412-2015-kuznyechik-ctracpkm-omac (см. Р 1323565.1.025-2019, раздел 8). Зашифрование производится в соответствии с Б.4.2;

г) для SC3 создается структура ContentInfo CI3, аналогичная структуре CI1, которая содержит зашифрованное BER-закодированное значение структуры SC3;

д) создается структура AuthenticatedSafe путем соединения CI1, CI2 и CI3 в последовательность SEQUENCE;

е) создается структура ContentInfo T типа «простые данные» (id-data). Поле content в составе структуры T представляет собой OCTET STRING и содержит BER-закодированное значение структуры AuthenticatedSafe (включая тег, длину и значения октетов);

ж) создается структура ContentInfo D типа «простые данные» (id-data). Значение MAC вычисляется в соответствии с Б.4.4 от содержимого структуры T, не включая тег OCTET STRING и байты длины, и записывается в поле macData.mac.digest. В поле macData.mac.digestAlgorithm.algorithm записывается идентификатор алгоритма хэширования: id-tc26-gost3411-12-512 :: = {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms (1) digest(2) gost3411-2012-512(3)}.

Поле contentInfo в составе структуры D содержит значение структуры T. Структура D в структуре транспортного ключевого контейнера является структурой верхнего уровня.

Примечание — Наименования структур, полей, идентификаторов объектов и типов приведены в Р 1323565.1.041-2022 (разделы 4 - 11) и Р 1323565.1.025-2019 (разделы 4 - 14).

Б.4 Механизмы защиты транспортного ключевого контейнера

Б.4.1 Выработка ключа из пароля

Выработка ключа из пароля происходит по алгоритму PBKDF2 в соответствии с Р 1323565.1.₀₄₀-2022 (подраздел 7.1). Параметрами алгоритма являются следующие значения:

• P — пароль, является символьной строкой в кодировке Unicode UTF-8;
• S — случайное значение, выбираемое по схеме равновероятного выбора без возвращения из множества V256, S \in V_{256} ;
• c — число итераций алгоритма;
• dkLen — требуемая длина выходной последовательности (в байтах), в примере dkLen = 32.

При формировании или разборе транспортного ключевого контейнера ключ из пароля формируется по алгоритму PBKDF2 в соответствии с Р 1323565.1.040-2022 (подраздел 7.1) и указанными параметрами. Для каждого защищенного раздела транспортного ключевого контейнера вычисляется собственный ключ, при этом используется один и тот же пароль P, одинаковое число итераций алгоритма c, одинаковая требуемая длина dkLen и разные случайные значения: S1, S2 и S3. Значения параметров c, dkLen, S1, S2 и S3 формируются на этапе формирования транспортного ключевого контейнера и записываются в раздел транспортного ключевого контейнера с открытыми данными; значение P загружается на узел отдельно от транспортного ключевого контейнера.

Б.4.2 Зашифрование защищенного раздела транспортного ключевого контейнера

Процесс зашифрования защищенных разделов транспортного ключевого контейнера происходит по схеме PBES2 в соответствии с Р 1323565.1.040-2022 (подраздел 7.2) и выглядит следующим образом:

а) генерируются параметры, удовлетворяющие описанию в Б.2: S1, S2, c, dkLen, IV1, IV2, MK1, MK2, ID_{MK_{1}} , ID_{MK_{2}} ;

б) из пароля P в соответствии с Б.4.1 вычисляются два ключа K1 и K2:

1. K1 = PBKDF2(P, S1, c, dkLen),

2. K2 = PBKDF2(P, S2, c, dkLen);

в) генерируются значения ukmi, где ukm_{i} \in V_{64} , где i = 1,2;

г) каждый защищенный раздел транспортного ключевого контейнера зашифровывается выбранным алгоритмом (id-gostr3412-2015-magma-ctracpkm-omac или id-gostr3412-2015-kuznyechik-ctracpkm-omac):

1. из ключа Ki с использованием алгоритма KDF_TREE_GOSTR3411_2012_256, описанного в Р 50.1.113-2016 (подраздел 4.5), вырабатывается два ключа: ключ шифрования сообщения Ki(1) и ключ имитозащиты Ki(2). Входные параметры для алгоритма KDF_TREE_GOSTR3411_2012_256 принимают следующие значения: Kin = Ki, label = «kdf tree», seed = ukmi, R = 1,

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

3. полученная строка байт, включая имитовставку, зашифровывается с использованием ключа шифрования Ki(1) и синхропосылки IVi согласно выбранному алгоритму шифрования;

д) параметры S1, S2, c, dkLen, IV1, IV2, ID_{MK_{1}} , ID_{MK_{2}} , ukm1 и ukm2 сохраняют в разделе транспортного ключевого контейнера с открытыми данными.

Б.4.3 Расшифрование защищенного раздела транспортного ключевого контейнера

Процесс расшифрования защищенных разделов транспортного ключевого контейнера происходит по схеме PBES2 в соответствии с Р 1323565.1.040-2022 (подраздел 7.2) и выглядит следующим образом:

а) из части транспортного ключевого контейнера с открытыми данными извлекаются значения S1, S2, c, dkLen, IV1, IV2, ID_{MK_{1}} , ID_{MK_{2}} , ukm1 и ukm2;

б) из пароля P в соответствии с Б.4.1 вычисляются два ключа K1 и K2:

1. K1 = PBKDF2(P, S1, c, dkLen),

2. K2 = PBKDF2(P, S2, c, dkLen);

в) каждый защищенный раздел транспортного ключевого контейнера расшифровывается выбранным алгоритмом (id-gostr3412-2015-magma-ctracpkm-omac или id-gostr3412-2015-kuznyechik-ctracpkm-omac):

1. из ключа Ki с использованием алгоритма KDF_TREE_GOSTR3411_2012_256, описанного в Р 50.1.113-2016 (подраздел 4.5), вырабатывается два ключа: ключ шифрования Ki(1) и ключ имитозащиты Ki(2). Входные параметры для алгоритма KDF_TREE_GOSTR3411_2012_256 принимают следующие значения: Kin = Ki, label = «kdf tree», seed = ukmi, R = 1,

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

3. для полученного расшифрованного текста без имитовставки с помощью ключа имитозащиты Ki(2) вычисляется имитовставка mac'i.

г) вычисленное значение имитовставки mac'i сравнивается с полученным значением maci. При несовпадении размеров или значений транспортный ключевой контейнер считается искаженным, и все данные из него не принимаются. При совпадении значений mac'i, и maci переданные ключи MK1 и MK2 вместе со своими идентификаторами сохраняются на устройстве.

Б.4.4 Вычисление контрольной суммы

Контрольная сумма передаваемых в транспортном ключевом контейнере данных вычисляется после шифрования защищенных разделов транспортного ключевого контейнера в соответствии со схемой PBMAC1 согласно Р 1323565.1.040-2022 (подраздел 7.3) следующим образом:

• генерируется параметр S3, удовлетворяющий описанию в Б.2. Значения параметров c, dkLen выбираются из соответствующих значений раздела транспортного ключевого контейнера с открытыми данными;
• из пароля P в соответствии с Б.4.1 вычисляется ключ K для получения контрольной суммы: K = PBKFD2(P, S3, c, dkLen);
• параметр S3 сохраняется в разделе транспортного ключевого контейнера с открытыми данными;
• вычисляется контрольная сумма по алгоритму HMAC_GOSTR3411 на ключе K для всех данных, передаваемых в транспортном ключевом контейнере (структуры T, определенной в Б.3, не включая тег OCTET STRING и байты длины). В результате формируется значение MAC, которое записывается в специальное поле транспортного ключевого контейнера, предназначенное для хранения контрольной суммы и подробнее описанное в Б.3.

Б.4.5 Проверка контрольной суммы

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

• из части транспортного ключевого контейнера с открытыми данными извлекаются значения S3, c, dkLen;
• из пароля P в соответствии с Б.4.1 вычисляется ключ K: K = PBKFD2(P, S3, c, dkLen);
• вычисляется контрольная сумма по алгоритму HMAC_GOSTR3411 на ключе K для всех данных, передаваемых в транспортном ключевом контейнере (структуры T, определенной в Б.3, не включая тег OCTET STRING и байты длины). В результате вычисляется контрольная сумма MAC'.

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

Б.5 Вычисление производных ключей

Вычисление производных ключей осуществляется по схеме, описанной в Б.5.1. Схема позволяет вычислить 4Z2 ключей, где Z — это положительное целое число, значение которого определено в Б.1. Каждому производному ключу сопоставляется его полный идентификатор, который является уникальным в системе при условии, что полный идентификатор ключа, из которого вычисляются производные ключи, является уникальным в системе. Под полным идентификатором ключа MK1 подразумевается строка Binary("cr")||ID_{\text{СВРК}}||ID_{\text{СКЗИ}}||ID_{MK_{1}} ; под полным идентификатором ключа MK2 — строка Binary("qk")||ID_{\text{СВРК}}||ID_{\text{СКЗИ}}||ID_{MK_{2}} . Если в процессе работы узлу СВРК и СКЗИ-потребителю понадобится меньшее количество производных ключей, то неиспользуемые ключи можно не вычислять.

Вычисление 4Z2 производных ключей из ключа MK1 происходит по схеме, описанной в Б.5.1, со следующими параметрами: MK = MK1, ID_{MK} = ID_{MK_{1}} , name = Binary(«cr»), R = 4.

Выработка 4Z2 производных ключей из ключа MK2 происходит по схеме, описанной в Б.5.1, со следующими параметрами: MK = MK1, ID_{MK} = ID_{MK_{2}} , name = Binary(«qk»), R = 4.

Б.5.1 Схема выработки производных ключей

Процесс формирования производных ключей с использованием ключа MK и необходимых атрибутов описан ниже. Этот процесс не является универсальной схемой выработки производных ключей и не предполагает использования вне рамок протокола Протока. Ключи могут формироваться с применением блочных шифров ГОСТ Р 34.12-2015 («Кузнечик») или ГОСТ Р 34.12-2015 («Магма»). Если используется блочный шифр «Кузнечик», то M = 4Z, если блочный шифр «Магма», то M = 8Z.

Из ключа MK с использованием функции KDF, описанной в Б.5.2, вырабатывается последовательность значений K(i), где i = 1,...,M. Входные параметры для функции KDF принимают следующие значения:

Kin = MK,

label = name || IDСВРК || IDСКЗИ || IDMK,

seed = 0x00000000,

R = 4.

Из последовательности значений K(i), где i = 1,...,M, формируются ключи K_{j}^{0} , где j = 1,...,2Z, по следующему правилу:

• для блочного шифра «Кузнечик» K_{j}^{0} = K(2j - 1)||K(2j) , где j = 1,...,2Z;
• для блочного шифра «Магма» K_{j}^{0} = K(4j - 3)||K(4j - 2)||K(4j - 1)||K(4j) , где j = 1,...,2Z.

Из ключей K_{j}^{0} , для j = 1,...,2Z, с использованием функции KDF, описанной в Б.5.2, вырабатывается последовательность значений Kj(i), где i = 1,...,M. Входные параметры для функции KDF принимают следующие значения:

K_{in} = K_{j}^{0} ,

label = name || IDСВРК || IDСКЗИ || IDMK,

seed = j,

R = 4.

Из последовательности Kj(i), где i = 1,...,M, j = 1,...,2Z, формируются ключи Ktj, где j = 1,...,2Z, t = 1,...,2Z, по следующему правилу:

• для блочного шифра «Кузнечик» Ktj = Kj(2t-1) || Kj(2t), где j = 1,...,2Z, t = 1,...,2Z;
• для блочного шифра «Магма» Ktj = Kj(4t-3) || Kj (4t-2) || Kj(4t-1) || Kj (4t), где j = 1,...,2Z, t = 1,...,2Z.

Полным идентификатором ключа Kt j, где j = 1,...,2Z, t = 1,...,2Z является строка name || IDСВРК || IDСКЗИ || IDMK || j || t, сокращенным идентификатором этого ключа является строка IDMK || j || t. Значения j и t представляются трехбайтовыми строками.

Б.5.2 Описание функции KDF

Функция KDF допускает использование блочных шифров ГОСТ Р 34.12-2015 («Кузнечик») или ГОСТ Р 34.12-2015 («Магма») в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015 (подраздел 5.6) с длиной имитовставки, равной длине блока используемого блочного шифра. Выработка производных ключей осуществляется при помощи функции KDF, аргументами которой являются байтовые строки Kin, label, seed и R.

KDF(Kin, label, seed, R) = K(1) || K(2) || K(3) || ...;

K(i) = CMAC(Kin, [i]b || label || 0x00 || seed || [L]b),

где Kin — ключ блочного шифра, K_{in} \in V_{256} ;

label, seed — битовые строки, длина и значения которых определяются переданными параметрами;

i — счетчик числа итераций, для блочного шифра «Кузнечик» i = 1, 2,...,4Z; для блочного шифра «Магма» i = 1, 2,...,8Z;

L — битовая длина вырабатываемого ключевого материала;

[L]b — байтовая запись L записывается в сетевом порядке минимально необходимого числа байт.

Примечание — Параметры функции KDF сформированы по аналогии с Р 50.1.113-2016 (подраздел 4.5). При этом параметры L и R используется для соответствия с параметрами Р 50.1.113-2016 (подраздел 4.5), их значения в протоколе фиксированы R = 4, L = 256·2Z.

Б.6 Использование производных ключей при формировании сообщений

Производные ключи формируются в соответствии с Б.5.1, при этом каждый ключ имеет сокращенный и полный идентификаторы. Порядок использования этих ключей в системе определяется на основе значений их идентификаторов следующим образом: ключи с сокращенным идентификатором IDMK || j || t, у которых 1 <= j <= Z, 1 <= t <= 2Z используются для защиты информации, передаваемой от узла СВРК к СКЗИ-потребителю; ключи с сокращенным идентификатором IDMK || j || t, у которых Z + 1 <= j <= 2Z, 1 <= t <= 2Z — для защиты информации, передаваемой от СКЗИ-потребителя к узлу СВРК. При этом ключи используются в порядке возрастания значений их сокращенных идентификаторов. Значения j и t представляются трехбайтовыми строками. В процессе использования каждого ключа учитывается количество обработанного с его участием материала, если это значение достигает критической отметки, то применение ключа прекращается.

Порядок использования производных ключей для защиты CRISP-сообщений описан в Б.6.1.

Порядок использования производных ключей для формирования экспортного представления ключей или случайных чисел описан в Б.6.2.

Б.6.1 Порядок использования производных ключей для защиты CRISP-сообщений

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

Идентификатор базового ключа пересылается в составе поля KeyID в значении счетчика KeyCounter (см. 5.₁.4), KeyCounter = ID_{MK_{1}}||j||t . Значения j и t представляются трехбайтовыми строками. С учетом указания идентификаторов отправителя и получателя сообщения в составе поля KeyID получатель имеет все необходимые данные для однозначного определения базового ключа, как и предписано протоколом.

При формировании CRISP-сообщения, которое защищается при помощи базового ключа с идентификатором ID_{MK_{1}}||j||t , заполнение поля KeyID зависит от типа участника протокола.

На узле СВРК с идентификатором IDСВРК в адрес СКЗИ-потребителя с идентификатором IDСКЗИ поле KeyID формируется следующим образом:

KeyID = 101010002||ID_{\text{СВРК}}||ID_{\text{СКЗИ}}||ID_{MK_{1}}||j||t , при этом 1 <= j <= Z, 1 <= t <= 2Z.

На СКЗИ-потребителе с идентификатором IDСКЗИ в адрес узла СВРК с идентификатором IDСВРК поле KeyID формируется следующим образом:

KeyID = 10101000_{2}||ID_{\text{СКЗИ}}||ID_{\text{СВРК}}||ID_{MK_{1}}||j||t , при этом Z + 1 <= j <= 2Z, 1 <= t <= 2Z.

Б.6.2 Порядок использования производных ключей для экспортного представления

Производные ключи, выработанные из ключа MK2, используются для вычисления ключей K_{ENC}^{EXP} и K_{MAC}^{EXP} (см. 7.1 и 7.2), которые участвуют в формировании экспортного представления ключей и случайных чисел, пересылаемых между участниками протокола.

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

KeyWrapID = ID_{MK_{2}}||j||t ,

где значения j и t представляются трехбайтовыми строками.

Ключи K_{ENC}^{EXP} и K_{MAC}^{EXP} вычисляются из производного ключа K с сокращенным идентификатором IDK с использованием блочных шифров согласно ГОСТ Р 34.12-2015 («Кузнечик») или ГОСТ Р 34.12-2015 («Магма»). Если используется блочный шифр «Кузнечик», то M = 4, если блочный шифр «Магма», то M = 8. Вычисление осуществляется следующим образом.

Из ключа K с использованием функции KDF, описанной в Б.5.2, вырабатывается последовательность значений K(i), где i = 1,...,M. Входные параметры для функции KDF принимают следующие значения:

Kin = K,

label = Binary(«encmac») || IDK,

seed = 0x0002,

R = 1.

Из последовательности значений K(i), где i = 1,...,M, формируются ключи K_{ENC}^{EXP} и K_{MAC}^{EXP} по следующему правилу:

• для блочного шифра «Кузнечик» K_{ENC}^{EXP} = K(1)||K(2) , K_{MAC}^{EXP} = K(3)||K(4) ;
• для блочного шифра «Магма» K_{ENC}^{EXP} = K(1)||K(2)||K(3)||K(4) , K_{MAC}^{EXP} = K(5)||K(6)||K(7)||K(8) .

Б.7 Использование производных ключей при разборе сообщений

Порядок разбора поля KeyID при обработке полученного CRISP-сообщения описан в Б.7.1; порядок разбора поля KeyWrapID при обработке полученного ключевого контейнера — в Б.7.2; порядок разбора поля IV, извлекаемого из ключевого контейнера полученного сообщения — в Б.7.3.

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

Б.7.1 Порядок разбора поля KeyID

Значение J выставляется в зависимости от типа получателя:

• если получателем является узел СВРК, то J = Z + 1;
• если получателем является СКЗИ-потребитель, то J = 1.

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

ID_{old} = ID_{MK_{1}}||J||0 ; ID_{cur} = ID_{MK_{1}}||J||1 ,

где ID_{MK_{1}} — наименьший идентификатор ключей типа MK1, имеющийся у участника.

Порядок разбора KeyID состоит из трех шагов.

Б.7.1.1 Первым шагом проверяется соответствие значения KeyID структуре, описанной в 5.1.4, для чего выполняются следующие действия:

а) проверяется, что первый байт KeyID равен 101010002:

1. если проверка пройдена успешно, то разбор продолжается,

2. иначе KeyID признается некорректным;

б) извлекаются идентификаторы отправителя и получателя сообщения: значения LSB128(MSB136(KeyId)) и LSB128(MSB264(KeyId)) соответственно:

1. если идентификаторы корректные, то разбор продолжается,

2. иначе KeyID признается некорректным.

Б.7.1.2 Вторым шагом проверяется соответствие значения KeyCounter = LSB64(KeyId) допустимым диапазонам идентификаторов ключей, для чего выполняются следующие действия:

• извлекается значение t = LSB24(KeyCounter), если условие 1 <= t <= 2Z не выполнено, то значение KeyID признается некорректным и сообщение отбрасывается;
• извлекается значение j = MSB24(LSB48(KeyCounter)), если условие J <= j <= (J + Z — 1) не выполнено, то значение KeyID признается некорректным и сообщение отбрасывается;
• извлекается значение A = MSB16(KeyCounter), если значение A не соответствует ни одному идентификатору ключа, имеющемуся на узле, то значение KeyID признается некорректным и сообщение отбрасывается.

Третий шаг зависит от значения KeyCounter.

Если KeyCounter < IDold, то значение KeyID признается некорректным и сообщение отбрасывается.

Если KeyCounter = IDold, то проверяется, не превысил ли ресурс максимального значения нагрузки на ключ с идентификатором IDold:

• если превысил, то значение KeyID признается некорректным и сообщение отбрасывается;
• иначе значение KeyID признается корректным; при использовании ключа с идентификатором IDold продолжается подсчет оставшегося ресурса ключа.

Если IDold < KeyCounter < IDcur, то:

• значение KeyID признается корректным;
• счетчику IDold присваивается KeyCounter;
• при использовании ключа с идентификатором IDold происходит подсчет оставшегося ресурса ключа.

Если IDcur = KeyCounter, то проверяется, не превысил ли максимального значения ресурс нагрузки на ключ с идентификатором IDcur:

• если превысил, то значение KeyID признается некорректным и сообщение отбрасывается;
• иначе значение KeyID признается корректным.

Если IDcur < KeyCounter, то в зависимости от значения A:

а) если MSB16(IDcur) < A, то:

1. если ((MSB16(IDcur) + 1) = A) и (j = J) и (t <= 2):

• если ключ с идентификатором MSB16(IDcur) + 1 имеется у получателя, тогда значение KeyID признается корректным, счетчику IDold присваивается IDcur, счетчику IDcur — KeyCounter, при использовании ключа с идентификатором IDcur осуществляется подсчет оставшегося ресурса ключа,
• иначе KeyID признается некорректным и сообщение отбрасывается;

2. иначе KeyID признается некорректным и сообщение отбрасывается;

б) если MSB16(IDcur) = A, то:

1. если ((j = MSB24(LSB48(IDcur)) + 1) и (t <= 2)) или ((j = MSB24(LSB48(IDcur))) и ((LSB48(IDcur) < t <= LSB48(IDcur) + 2))), то:

• значение KeyID признается корректным,
• счетчику IDold присваивается IDcur, счетчику IDcur присваивается KeyCounter,
• при использовании ключа с идентификатором IDcur осуществляется подсчет оставшегося ресурса ключа;

2. иначе KeyID признается некорректным и сообщение отбрасывается;

в) иначе KeyID признается некорректным и сообщение отбрасывается.

Б.7.2 Порядок обработки KeyWrapID

Порядок формирования начальных значений J, IDold, IDcur для разбора поля KeyWrapID аналогичен порядку при разборе поля KeyID (см. Б.7.1). Последовательность шагов разбора KeyWrapID аналогична последовательности шагов разбора KeyID (KeyCounter) с единственным отличием: шаг 1 не выполняется.

Б.7.3 Порядок обработки IV в KExp15

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

Перед первым использованием каждой пары ключей K_{ENC}^{EXP} и K_{MAC}^{EXP} производится начальная инициализация значения IVcur = SizeWinIV.

В случае успешного разбора поля KeyWrapID согласно Б.7.2 (приложение Б), порядок обработки присланного IV зависит от его значения.

Б.7.3.1 Если верно условие (IVcur — SizeWinIV) < IV <= IVcur, то выполняются следующие шаги:

а) если ранее IV не использовалось:

1. IV считается корректным,

2. вычисляется импортное представление переданного ключа (или случайного числа):

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

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

Б.7.3.2 Если верно условие IVcur < IV < IVcur + SizeWinIV, то выполняются следующие шаги:

а) если IV не превышает установленного максимального значения для синхропосылки:

1. значение IV признается корректным,

2. вычисляется импортное представление переданного значения:

• в случае успешного вычисления импортного представления ключа (или случайного числа) счетчику IVcur присваивается значение IV, окно отслеживаемых значений сдвигается, значение IVcur помечается как использованное,
• в случае возникновения ошибки при вычислении импортного представления ключевой контейнер отбрасывается;

б) иначе IV признается некорректным, и разбор ключевого контейнера заканчивается ошибкой.

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

УДК 681.3.06:006.354	ОКС 35.040
Ключевые слова: криптографические протоколы, аутентификация, пароль, ключ, CRISP, шифрование

---