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

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

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

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

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

Настоящие рекомендации описывают ключевую систему ISTOQ-A - Integral STandard Of Quantum keysystem - stAr, - определяющую процесс создания целевых ключей квантовой криптографической системы (далее - сети КРК) в топологии "звезда". Такая сеть рассматривается как упрощенная квантовая сеть, состоящая из доверенных промежуточных узлов (ДПУ), с выделенным центральным узлом (далее - ДПУ сервер), осуществляющим создание целевых ключей и дальнейшее их распределение на пары периферийных узлов "звезды" (далее - ДПУ клиенты). Каждый ДПУ представляет комплекс, состоящий из экземпляров квантово-оптической аппаратуры и служебного средства криптографической защиты информации (СКЗИ) для преобразования обрабатываемой ключевой информации. К периферийным узлам подключаются СКЗИ-потребители, которым передаются созданные целевые ключи (ЦК).

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

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

Примечания

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

2 Под классическим каналом понимается логический канал, соединяющий два ДПУ. Физическая реализация канала может быть различной.

3 Настоящие рекомендации дополнены приложениями А, Б и В.

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

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

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

ГОСТ Р 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.022-2018 Информационная технология. Криптографическая защита информации. Функции выработки производного ключа

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

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

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

3.1.1 доверенный промежуточный узел; ДПУ: Доверенный узел сети квантового распределения ключей, вырабатывающий в паре с другими доверенными промежуточными узлами квантовые и/или целевые ключи.

3.1.2 доверенный промежуточный узел сервер; ДПУ сервер: Доверенный промежуточный узел, являющийся центральным узлом в топологии "звезда"; соединен квантовыми и классическими маршрутами со множеством доверенных промежуточных узлов клиентов.

3.1.3 доверенный промежуточный узел клиент; ДПУ клиент: Доверенный промежуточный узел, являющийся периферийным узлом в топологии "звезда"; соединен квантовым и классическим маршрутом с доверенным промежуточным узлом сервером.

3.1.4 квантовый ключ; КК: Ключ, полученный двумя соседними доверенными промежуточными узлами в результате выполнения протокола квантового распределения ключей.

3.1.5 квантовый канал: Канал связи, предназначенный для передачи квантовых состояний протокола квантового распределения ключей.

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

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

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

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

3.1.10 компонента: Блок исходной ключевой информации, участвующий в формировании целевого ключа.

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

3.1.12 набор целевых ключей; набор ЦК: Множество целевых ключей, объединенных общим идентификатором набора целевых ключей.

3.1.13 протокол квантового распределения ключей; протокол КРК: Протокол, который включает способ приготовления и преобразования квантовых состояний, способ передачи их по квантовому каналу, способ их детектирования и последующей обработки.

Примечание - Целью протокола квантового распределения ключей является получение квантового ключа, идентичного на обеих сторонах квантового канала.

3.1.14 прямой маршрут (передачи компоненты): Маршрут передачи компоненты, состоящий из двух доверенных промежуточных узлов.

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

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

3.1.16 сегмент маршрута: Два доверенных промежуточных узла, указанные в маршруте подряд.

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

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

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

3.1.19 сопряженные доверенные промежуточные узлы; сопряженные ДПУ: Пара доверенных промежуточных узлов, соединенных классическим каналом.

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

3.1.21 составной маршрут (передачи компоненты): Маршрут передачи компоненты, состоящий из трех и более доверенных промежуточных узлов.

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

3.1.23 целевой ключ; ЦК: Секретный ключ, вырабатываемый и распределяемый между целевыми доверенными промежуточными узлами.

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

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

V_s - множество всех двоичных строк длины s, где s - натуральное число. Нумерация подстрок и элементов строки осуществляется справа налево, начиная с нуля;

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

|A| - размерность (число элементов) вектора , если A - пустая строка, то |A| = 0;

A||B - конкатенация векторов A, , т.е. вектор из V_|A|+|B|, в котором левый подвектор из V_|A| совпадает с вектором A, а правый подвектор из V_|B| совпадает с вектором B;

Aⁿ - конкатенация n экземпляров строки A;

byte(X) - представление натурального числа X в виде байтовой строки длиной , при котором соответствующая итоговой байтовой строке двоичная строка x_8l-1||...||x₁||x₀, , i = 0, 1, ..., 8l - 1, есть бинарное представление числа X, т.е. X = x₀ + x₁·2 + ... + x_8l-1·2^8l-1 (представление BigEndian);

CMAC(K, M) - функция выработки имитовставки на ключе K от данных M, определенная в ГОСТ Р 34.13-2015 (подраздел 5.6). Длина значения определяется используемым блочным шифром;

KDF_{TREE_256}(K, label, seed, R) - функция диверсификации ключа KDF_TREE_GOSTR3411_2012_256, определенная в Р 50.1.113-2016 (подраздел 4.5). Длина значения равна 32 байта;

HMAC₂₅₆(K, T) - ключевая функция хэширования HMAC_GOSTR3411_2012_256, описанная в Р 50.1.113-2016 (пункт 4.1.1). Длина значения равна 32 байта;

Path_p,t - маршрут от ДПУ с идентификатором Node_p до ДПУ с идентификатором Node_t;

NPath_p,t - число ДПУ в маршруте Path_p,t;

- j-й квантовый ключ между ДПУ с идентификатором Node_t до ДПУ с идентификатором Node_p. Длина значения равна 32 байта;

- j-й ключ защиты компоненты между ДПУ с идентификатором Node_t до ДПУ с идентификатором Node_p. Длина значения равна 32 байта;

- набор ЦК с идентификатором m между ДПУ с идентификатором Node_t и ДПУ с идентификатором Node_p. Состоит из M целевых ключей , y = 1 ... M - порядковый номер целевого ключа в наборе;

- j-й ключ генерации ключей защиты компоненты между ДПУ с идентификатором Node_t до ДПУ с идентификатором Node_p. Длина значения равна 32 байта;

- компонента, созданная для ДПУ клиентов с идентификатором Node_t и с идентификатором Node_p для формирования набора ЦК с идентификатором m. Длина значения равна 32 байта. Передается по прямому маршруту от ДПУ сервера;

- компонента, созданная для ДПУ клиентов с идентификатором Node_t и с идентификатором Node_p для формирования набора ЦК с идентификатором m. Длина значения равна 32 байтам. Передается по квантовому маршруту от ДПУ сервера.

Примечание - Обозначение ключа без индекса (например, QK) относится к любому ключу данного вида. Обозначение ключа с нижним индексом (например, QK_j) относится к конкретному ключу из множества ключей. Обозначение ключа с верхним индексом (например, QK^t,p) относится к множеству ключей, общих для двух ДПУ, указанных в верхнем индексе. Обозначение ключа с верхними и нижним индексами относится к конкретному ключу, общему для указанной пары ДПУ.

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

а) квантовые ключи ;

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

1) компоненты ,

2) компоненты ;

в) ключи защиты компонент ;

г) ключи генерации ключей защиты компонент ;

д) ЦК .

ЦК двух ДПУ клиентов формируется путем объединения с помощью функции гибридизации (см. 5.2) компонент Rand и QRand, созданных на выделенном ДПУ сервере. Исходная ключевая информация делится на блоки заданной длины, называемые компонентами. Каждая компонента передается от ДПУ сервера на каждый из ДПУ клиентов по некоторому маршруту - упорядоченной последовательности ДПУ, первым в которой является ДПУ сервер, а последним ДПУ клиент. Маршруты передачи различных компонент могут различаться. Порядок определения маршрута передачи компоненты не рассматривается в настоящих рекомендациях. При передаче компоненты на каждом сегменте каждого маршрута должны быть необходимые ключи для защиты компоненты: ключи KQPK для защиты компоненты Rand и ключи QK для защиты компоненты QRand.

Взаимосвязь множеств ключей приведена на рисунке 1. Под RNG понимается источник компонент Rand, QRand, соответствующих требованиям к компонентам (см. 4.3). Ключи множества QK вырабатываются в результате выполнения протокола КРК между соседними ДПУ. Ключ KGenQPK предварительно распределяется на пары ДПУ клиент - ДПУ сервер.

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

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

Формирование ключевых контейнеров с использованием квантовых ключей проводится согласно 5.3.

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

Если Max_QK = 1, то каждый новый ключевой контейнер должен формироваться с применением нового QK.

Текущему квантовому ключу соответствует счетчик Counter_QK числа использований данного ключа. Размер счетчика зависит от используемого криптонабора для экспортного представления компоненты (см. 5.3). Каждому квантовому ключу перед началом использования устанавливается значение счетчика использования ключа Counter_QK = 0.

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

ДПУ сервер формирует одну компоненту QRand и одну компоненту Rand.

Компонента формируется на ДПУ сервере с идентификатором Node_Ser для ДПУ клиентов с идентификаторами Node_t, Node_p, где Node_t < Node_p. Совместно с компонентой используется для создания набора ЦК с помощью функции гибридизации KDFG согласно 5.2 на ДПУ клиентах.

Компонента передается от ДПУ сервера на ДПУ клиент с идентификатором Node_t с защитой на ключе защиты компоненты , а на ДПУ клиент с идентификатором Node_p с защитой на ключе защиты компоненты .

Компонента формируется на ДПУ сервере с идентификатором Node_Ser для ДПУ клиентов с идентификаторами Node_t, Node_p, где Node_t < Node_p. Совместно с компонентой используется для создания набора ЦК с помощью функции гибридизации KDFG согласно 5.2 на ДПУ клиентах.

Компонента передается от ДПУ сервера на ДПУ клиент с идентификатором Node_t с защитой на квантовом ключе , а на ДПУ клиент с идентификатором Node_p с защитой на квантовом ключе .

Ключи защиты компонент KQPK^t,Ser являются секретными ключами между ДПУ сервером и ДПУ клиентом с идентификатором Node_t и используются для защиты компонент Rand при передаче от ДПУ сервера до соответствующего ДПУ клиента. Идентификаторы ключей защиты компонент для конкретной пары ДПУ должны быть уникальными. Размер идентификаторов ключей защиты компонент составляет 16 байт, . Способ формирования идентификаторов определяет разработчик системы.

Разработчик системы определяет Max_KQPK - максимальное число использований одного ключа защиты компоненты KQPK. Значение Max_KQPK не должно превышать 2¹⁵.

Если Max_KQPK = 1, то каждый ключевой контейнер должен формироваться с применением нового KQPK.

Текущему ключу защиты компоненты соответствует счетчик Counter_KQPK числа использований данного ключа. Перед началом использования каждого ключа защиты компоненты ему в соответствие ставится значение счетчика использования ключа Counter_KQPK = 0. Размер счетчика использований ключа зависит от используемого криптонабора для экспортного представления компоненты (см. 5.3).

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

Ключи генерации ключей защиты компонент KGenQPK^t,Ser = KGenQPK^Ser,t являются секретными ключами между ДПУ сервером и ДПУ клиентом с идентификатором Node_t. Идентификаторы ключей генерации ключей защиты компонент для конкретной пары ДПУ должны быть уникальными. Размер идентификаторов ключей генерации ключей защиты компонент составляет 16 байт, . Способ формирования идентификаторов определяется разработчиком системы. Источник ключей и способ доставки на ДПУ находится за рамками настоящих рекомендаций. Первый ключ является предварительно распределяемым. Последующие ключи генерации формируются при создании новых ключей защиты компоненты согласно 5.1:

Примечание - Под ключом понимается некоторый текущий (j-й) ключ, под ключом - следующий ключ.

Целевые ключи , 0 < y <= M, являются секретными ключами одного набора с идентификатором m, формируемыми на каждом из ДПУ клиентов с идентификаторами Node_t, Node_p, где Node_t < Node_p из двух компонент с помощью функции гибридизации KDFG (см. 5.2). Одна пара компонент позволяет создать набор из M ЦК:

Максимально допустимое число ключей одного набора M должно быть получено в рамках тематических исследований конкретных СКЗИ, составляющих сеть КРК, при оценке соответствия данных СКЗИ требованиям безопасности защищаемой информации в соответствии с Р 1323565.1.012-2017 (разделы 4 - 6). Максимально допустимое значение M не может превышать 2¹⁶ - 1 ключей.

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

- ключ защиты компоненты ;

- новый ключ генерации ключей защиты компоненты .

В качестве функции диверсификации используется алгоритм KDF_TREE_GOSTR3411_2012_256 согласно Р 50.1.113-2016 (подраздел 4.5):

где label - назначение вырабатываемых ключей, размер поля 32 байта.

label = 0x0000000000000000000000004b51504b0000000000000000004b47656e51504b;

seed - порядковый номер ключа, подаваемого на вход, размер поля 16 байт, seed = byte(j);

;

.

Функция гибридизации объединяет компоненты Rand_m и QRand_m в набор из M целевых ключей .

Для создания набора ЦК применяется функция диверсификации KDF согласно Р 1323565.1.022-2018 (раздел 5):

где - исходная ключевая информация. ;

- суммарная длина (в двоичной записи) целевых ключей формируемого набора ЦК;

- соль. ;

- метка использования, назначение ключа - ЦК (QPK). P = 0x000000000051504b;

- идентификаторы пары ДПУ клиентов. U = Node_t||Node_p;

- дополнительная информация. В качестве дополнительной информации используется идентификатор формируемого набора ЦК m.

Согласно Р 1323565.1.022-2018 (раздел 5) на первом этапе вычисляется промежуточный ключ:

На втором этапе из промежуточного ключа создается выходная последовательность длины L:

где z_l = CMAC(K⁽¹⁾, m||C_l||P||U||L);

- битовое представление номера блока l длиной 32 бита;

- идентификатор формируемого набора ЦК;

CMAC(K, x) - функция выработки имитовставки, определенная в ГОСТ Р 34.13-2015 (подраздел 5.6) с применением блочного шифра "Кузнечик", определенного в ГОСТ Р 34.12-2015 (раздел 4).

Выходная последовательность Z разбивается на блоки длиной 256 бит, каждый из которых является ЦК из формируемого набора ЦК:

где 0 < y <= M, - порядковый номер ЦК в наборе ЦК.

Компонента передается по сегментам маршрута в экспортном представлении. Контейнер с компонентой формируется из экспортного представления и дополнительной информации.

Экспортное представление компоненты формируется согласно Р 1323565.1.017-2018 (раздел 5).

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

- KExp15-KImp15-Kuzn, соответствует параметру в контейнере с компонентой CS_KW = 0;

- KExp15-KImp15-Magma, соответствует параметру в контейнере с компонентой CS_KW = 1.

Для формирования экспортного представления и ключевого контейнера используются производные ключи K_enc и K_mac, вырабатываемые из ключа K_j, и счетчик использования ключа . В качестве ключа K_j используются ключи QK_j или KQPK_j.

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

- для криптонабора KExp15-KImp15-Kuzn;

- для криптонабора KExp15-KImp15-Magma.

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

- ключ шифрования K_enc;

- ключ вычисления имитовставки K_mac;

- вектор инициализации IV. Важно, чтобы вектор IV был уникален для пары K_enc и K_mac. В качестве вектора инициализации IV используется значение счетчика ;

- передаваемое значение X.

Из ключа K_j с применением алгоритма диверсификации KDF_TREE_GOSTR3411_2012_256, определенного в Р 50.1.113-2016 (подраздел 4.5), формируются два ключа:

- ключ шифрования K_enc;

- ключ вычисления имитовставки K_mac.

где K_j - ключ, используемый для диверсификации;

label - назначение вырабатываемых ключей, размер поля 10 байт. label = 0x000000454e43204d4143;

seed - синхропосылка, которая используется при формировании ключевого контейнера. ;

L = num*256 - необходимая битовая длина вырабатываемого ключевого материала, num - количество ключей. В данном случае num = 2;

K_mac = HMAC₂₅₆(K_j, 0x01||label||0x00||seed||byte(L));

K_enc = HMAC₂₅₆(K_j, 0x02||label||0x00||seed||byte(L)).

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

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

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

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

- ключ шифрования ;

- ключ вычисления имитовставки ;

- вектор инициализации . Важно, чтобы вектор IV был уникален для пары K_enc и K_mac. В качестве вектора инициализации IV используется значение счетчика ;

- передаваемое значение .

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

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

- на первом шаге вычисляется значение имитовставки KEYMAC длиной 128 бит с помощью функции выработки имитовставки согласно ГОСТ Р 34.13-2015 (подраздел 5.6) с применением блочного шифра "Кузнечик", определенного в ГОСТ Р 34.12-2015 (раздел 4):

- на втором шаге вычисляется значение KEXP с помощью функции шифрования в режиме гаммирования с длиной блока гаммы s = n = 128 согласно ГОСТ Р 34.13-2015 (подраздел 5.2) с применением блочного шифра "Кузнечик", определенного в ГОСТ Р 34.12-2015 (раздел 4):

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

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

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

- ключ шифрования ;

- ключ вычисления имитовставки ;

- вектор инициализации . Важно, чтобы вектор IV был уникален для пары K_enc и K_mac. В качестве вектора инициализации IV используется значение счетчика ;

- передаваемое значение .

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

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

- на первом шаге вычисляется значение имитовставки KEYMAC длиной 64 бит с помощью функции выработки имитовставки согласно ГОСТ Р 34.13-2015 (подраздел 5.6) с применением блочного шифра "Магма", определенного в ГОСТ Р 34.12-2015 (раздел 5):

- на втором шаге вычисляется значение KEXP с помощью функции шифрования в режиме гаммирования с длиной блока гаммы s = n = 64 согласно ГОСТ Р 34.13-2015 (подраздел 5.2) с применением блочного шифра "Магма", определенного в ГОСТ Р 34.12-2015 (раздел 5):

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

где - метка, обозначающая тип используемого ключа для формирования экспортного представления 'QK' или 'KQPK' соответственно. Для квантовых ключей указывается label = 'QK' = 0x000000000000514b. Для ключей защиты компоненты указывается label = 'KQPK' = 0x000000004b51504b;

- идентификатор набора ЦК, компонента которого передается в экспортном представлении. Способ формирования идентификатора должен быть согласован всеми участниками информационного обмена;

- используемый криптонабор для экспортного представления компоненты;

- идентификатор используемого ключа для формирования экспортного представления;

- счетчик использования ключа, используемый в качестве IV;

- идентификатор ДПУ клиента, для которого сформирована компонента;

- идентификатор парного ДПУ клиента, которому будет передана та же компонента, содержащаяся в экспортном представлении. С данным узлом узел Node_t будет вырабатывать ЦК;

- идентификатор узла, на котором сформирован ключевой контейнер;

- идентификатор узла, в адрес которого сформирован ключевой контейнер;

KEXP - экспортное представление передаваемой компоненты.

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

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

ЦК формируется между ДПУ клиентами с идентификаторами Node_t и Node_p (далее - ДПУ-К1 и ДПУ-К2 соответственно). Инициатором создания ЦК является ДПУ сервер с идентификатором Node_Ser (далее - ДПУ-С).

Известен квантовый маршрут , , состоящий из NPath_Ser,t >= 2 узлов и квантовый маршрут , , состоящий из NPath_Ser,p >= 2 узлов.

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

На рисунке 2 приведена диаграмма последовательности выполнения протокола для четырех ДПУ с идентификаторами Node₁, Node₂, Node₃, Node_Ser. На диаграмме ключевой контейнер, сформированный согласно 5.3.4, содержащий компоненту Rand, защищенную на ключе KQPK, обозначен Container_KQPK^1,Ser(Rand^1,3).

Примечания

1 Способ информирования ДПУ сервера о необходимости создания нового набора ЦК для конкретной пары ДПУ клиентов не рассматривается в настоящих рекомендациях.

2 Если ДПУ сервер и ДПУ клиент являются соседними, то квантовый маршрут состоит ровно из двух узлов.

Формирование ЦК происходит по следующему алгоритму:

- ДПУ-С формирует компоненту ;

- ДПУ-С передает компоненту по прямому маршруту на ДПУ-К1 согласно 6.3;

- ДПУ-С передает компоненту по прямому маршруту на ДПУ-К2 согласно 6.3;

- ДПУ-С формирует компоненту ;

- ДПУ-С передает компоненту по квантовому маршруту Path_Ser,t на ДПУ-К1 согласно 6.2;

- ДПУ-С передает компоненту по квантовому маршруту Path_Ser,p на ДПУ-К2 согласно 6.2;

- ДПУ-К1 и ДПУ-К2 формируют общий набор ЦК на основе полученных компонент:

Для k = 2 .. NPath_Ser,t передача компоненты по квантовому маршруту Path_Ser,t выполняется по следующему алгоритму:

а) счетчик использования текущего квантового ключа ;

б) ДПУ из квантового маршрута с идентификатором упаковывает компоненту в ключевой контейнер на текущем квантовом ключе согласно 5.3 и отправляет на ДПУ с идентификатором ;

в) если значение счетчика , то:

1) текущим квантовым ключом назначается новый квантовый ключ ,

2) счетчик использования текущего квантового ключа обнуляется ;

г) ДПУ с идентификатором извлекает компоненту из полученного ключевого контейнера;

д) значение k увеличивается на 1, k = k + 1.

Передача компоненты по квантовому маршруту Path_Ser,p проводится аналогично.

Передача компоненты по прямому маршруту между ДПУ-С и ДПУ-К1 выполняется по следующему алгоритму:

а) счетчик использования текущего ключа защиты компоненты ;

б) ДПУ-С упаковывает компоненту в ключевой контейнер с защитой на текущем ключе защиты компоненты согласно 5.3 и передает ДПУ-К1;

в) если счетчик , то:

1) формируют новый ключ защиты компоненты из текущего ключа генерации ключей защиты компоненты согласно 5.1,

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

г) ДПУ-К1 извлекает компоненту из полученного ключевого контейнера.

Передача компоненты по прямому маршруту между ДПУ-С и ДПУ-К2 проводится аналогично.

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

- сеть КРК состоит из ДПУ сервера с идентификатором Node_Ser и множества ДПУ клиентов Nodes, |Nodes| = N. Каждому ДПУ клиенту сопоставлен уникальный идентификатор Node_i, где i = 1 .. N;

- известны квантовые маршруты, соединяющие каждый из пары целевых ДПУ с ДПУ сервером. Порядок определения квантового маршрута не рассматривается в настоящих рекомендациях;

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

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

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

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

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

Данное приложение уточняет применение протокола выработки ЦК двух ДПУ клиентов для сетей КРК, в которых не используются компоненты Rand, ключи генерации ключей защиты компоненты и ключи защиты компоненты.

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

Передача компонент QRand происходит без изменений.

Функция гибридизации KDFG для всех наборов ЦК использует фиксированную соль T = 0xff991bca8fab60c081dc4ed8c7420e3a2e5821a56d4c7e89021a32eb648b4e2f.

где Rand1=0x00000000000000000000000000000000000000000000000000000052616e6 431 - константа, представляющая собой бинарное представление строки 'Rand1';

Rand2=0x00000000000000000000000000000000000000000000000000000052616e6432 - константа, представляющая собой бинарное представление строки 'Rand2';

HASH₂₅₆(X): - алгоритм вычисления хэш-функции с длиной хэш-кода n = 256 бит от данных X, определенный в ГОСТ Р 34.11-2012 (раздел 8).

В данном приложении представлен вариант подключения сети КРК топологии "звезда", реализованной согласно настоящим рекомендациям, к сети КРК произвольной топологии, реализованной согласно Р 1323565.1.061-2024 (разделы 4 - 7).

Реализована некоторая сеть КРК топологии "звезда" (далее - подсеть "звезда"), состоящая из ДПУ сервера с идентификатором Node_Ser и N ДПУ клиентов с идентификаторами Node_{cl_n}, где n = 1 .. N.

Также реализована некоторая сеть КРК произвольной топологии (далее - основная сеть), состоящая из M ДПУ с идентификаторами Node_m, где m = 1 .. M.

Для подключения подсети "звезда" к основной сети необходимо ДПУ сервер Node_Ser подключить к основной сети, т.е. назначить узлу идентификатор в рамках основной сети, загрузить необходимые ключи, осуществить подключение квантовым каналом к одному и более существующим ДПУ основной сети, а также классическими каналами в соответствии с требуемыми связями для выработки ЦК, считая, что для любой пары целевых ДПУ, состоящей из Node_{cl_n} и Node_m, ЦК создается как для пары целевых ДПУ Node_Ser и Node_m.

ДПУ Node_Ser назначен идентификатор основной сети Node_M+1. Тогда создание ЦК между некоторым Node_{cl_n} и ДПУ Node_m происходит по следующему алгоритму:

- выполняют шаги протокола выработки ЦК парной связи между клиентами квантовой криптографической сети произвольной топологии в части формирования и передачи компонент набора ЦК согласно Р 1323565.1.061-2024 (раздел 6), считая целевыми ДПУ пару Node_m и Node_M+1;

- ДПУ Node_m вычисляет целевой ключ с использованием функции гибридизации KDFG согласно Р 1323565.1.061-2024 (подраздел 5.2);

- ДПУ Node_M+1 вычисляет значения исходной ключевой информации S и соли T согласно Р 1323565.1.061-2024 (подраздел 5.2);

- ДПУ Node_M+1, выступая сервером подсети "звезда", выполняет протокол выработки ЦК парной связи между клиентами квантовой криптографической сети в топологии "звезда" согласно 6.1, полагая вычисленную на предыдущем шаге ключевую информацию S компонентой QRand, а соль T компонентой Rand, при этом компоненты доставляются только на ДПУ-К1, соответствующий ДПУ Node_{cl_n}, пропуская шаги протокола для ДПУ-К2;

- ДПУ Node_{cl_n} вычисляет ЦК с использованием функций гибридизации KDFG согласно 5.2.

Представленный вариант сопряжения требует корректного составления таблицы соответствия ДПУ и подключенных к ним СКЗИ-потребителей, а также сопровождения запросов ключей корректной идентификационной информацией целевых ДПУ. Основная сеть может учитывать все СКЗИ-потребители, подключенные к ДПУ Node_{cl_n}, как если они подключены к ДПУ Node_M+1, а подсеть "звезда" все СКЗИ-потребители, подключенные к ДПУ Node_m, как если они подключены к некоторому виртуальному ДПУ клиенту с идентификатором Node_{cl_N+1}.

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

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

В настоящем приложении двоичные строки из V^*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации ("||") опускается, т.е. строка будет представлена в виде a_r-1a_r-2 ... a₀, где , i = 0, 1, ..., r - 1.

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

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

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

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

Сеть КРК состоит из трех ДПУ, имеющих идентификаторы:

Node₁ = 0000000000000000000000000000000a₁₆

Node₂ = 0000000000000000000000000000000b₁₆

Node_Ser = ab0000000000000000000000000000cd₁₆

ЦК создаются для ДПУ Node₁ и ДПУ Node₂.

Ключ генерации ключей защиты компоненты между ДПУ Node₁ и ДПУ Node_Ser:

Ключ генерации ключей защиты компоненты между ДПУ Node₂ и ДПУ Node_Ser:

Квантовый ключ между ДПУ Node₁ и ДПУ Node_Ser:

Квантовый ключ между ДПУ Node₂ и ДПУ Node_Ser:

Компонента Rand:

Компонента QRand:

Шаг 1. Из ключа генерации ключей защиты компоненты вычисляются ключ защиты компоненты новый ключ генерации ключей защиты компоненты согласно 5.1:

Шаг 2. Формируется ключевой контейнер с компонентой .

Из ключа защиты компоненты вычисляются ключ шифрования и ключ имитозащиты согласно 5.3.1:

Вычисляется экспортное представление компоненты на ключах , с IV = 0000000000000001₁₆ согласно 5.3.2:

Вычисляется следующий ключевой контейнер:

Ключевой контейнер передается от ДПУ Node_Ser до ДПУ Node₁.

Шаг 3. Из ключа генерации ключей защиты компоненты вычисляются ключ защиты компоненты и новый ключ генерации ключей защиты компоненты согласно 5.1:

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

Из ключа защиты компоненты вычисляются ключ шифрования и ключ имитозащиты согласно 5.3.1:

Вычисляется экспортное представление компоненты на ключах , с IV = 0000000000000001₁₆ согласно 5.3.2:

Вычисляется следующий ключевой контейнер:

Ключевой контейнер передается от ДПУ Node_Ser до ДПУ Node₂.

Шаг 1. Из ключа защиты вычисляются ключ шифрования и ключ имитозащиты согласно 5.3.1:

Вычисляется экспортное представление компоненты на ключах , с IV = 0000000000000001₁₆ согласно 5.3.2:

Вычисляется следующий ключевой контейнер:

Ключевой контейнер передается от ДПУ Node_Ser до ДПУ Node1.

Шаг 2. Из ключа вычисляются ключ шифрования и ключ имитозащиты согласно 5.3.1:

Вычисляется экспортное представление компоненты на ключах , с IV = 0000000000000001₁₆ согласно 5.3.2:

Вычисляется следующий ключевой контейнер:

Ключевой контейнер передается от ДПУ Node_Ser до ДПУ Node₁.

Имеется две компоненты:

Вычисляется набор из двух целевых ключей согласно 5.2.

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

Задается соль, подаваемая на вход функции KDF:

Шаг 1. Вычисляется промежуточный ключ :

Шаг 2. Вычисляется целевой ключ из набора ЦК:

Вычисляется второй целевой ключ из набора: