Протокол «Протока»

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

Протокол «Протока» создавался в рамках реализации дорожной карты по развитию «Квантовых коммуникаций» в Российской Федерации до 2024 года, согласно которой нужно было разработать защищенный протокол взаимодействия квантово-криптографической аппаратуры выработки и распределения ключей и средства криптографической защиты информации. Описание этого протокола требовалось представить в виде рекомендаций по стандартизации согласно национальной системе стандартизации в России, что полезно по двум причинам.

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

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

На первый взгляд решение задачи не должно было потребовать разработки чего-то кардинально нового, доставка секретного ключа между двумя абонентами хорошо изученная задача, существует множество способов ее решения, такие как документы ISO/IEC серии 11770 «Information technology — Security techniques — Key management», NIST «Key magement» [14], но важно было учесть «квантовую специфику» и сделать удобный для индустрии протокол. Формирование полной картины требований происходило с учетом международного опыта и при непосредственном взаимодействии с отечественными производителями СКЗИ, использующими технологию КРК в своих продуктах.

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

Изучение доступных материалов условно можно разделить на три направления:

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

Изучение международных документов в области стандартизации по квантовым технологиям позволило выделить два ближайших аналога к разрабатываемому протоколу: стандарты ETSI GS QKD 004 «Application Interface» [12] и ETSI GS QKD 014 «Protocol and data format of REST-based key delivery API» [13]. В документе ETSI GS QKD 004 присутствует описание интерфейса, возможное деление квантовой сети на уровни и определены несколько мест использования этого интерфейса в квантовой сети. Использование этого интерфейса подразумевает открытие сеанса между взаимодействующими субъектами, сама передача ключей осуществляется в виде «потока бит». Описываются параметры, которые позволяют определить/согласовать эксплуатационные качества сеанса: скорость передачи ключа, допустимые задержки, размер буфера, приоритет запросов и т.д. В документе ETSI GS QKD 014 описан компактный запросно-ответный протокол, согласно которому СКЗИ запрашивает ключ, а аппаратура КРК формирует ответ, содержащий ключ. Забегая вперед, отметим, что идеи этого протокола использовались при создании «Протоки». В обоих документах можно выделить два сценария взаимодействия квантовой аппаратуры и СКЗИ: передача ключа и передача служебной информации. В обоих документах поверхностно затронуты вопросы безопасности, указано на использование для защиты протоколов TLS/HTTPS. Отметим, что в некоторых моделях безопасности допускается наличие квантового компьютера у нарушителя, поэтому предлагаемой защиты может оказаться недостаточно, кроме того, эксплуатационная эффективность такого решения сомнительна.

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

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

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

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

Область применения и сценарии использования протокола

В результате проведенного обзора было выявлено что исторически востребованной областью применения технологии КРК являлась сеть с элементарной топологией точка-точка, а наиболее перспективным местом применения технологии КРК являются разветвлённые сети, состоящие из связанных между собой доверенных промежуточных узлов (ДПУ) [19, 18, 17]. Упрощенно, принцип работы сети ДПУ можно описать следующим образом. ДПУ представляют собой СКЗИ с комплектом квантового оборудования (не путать с СКЗИ, которому нужно передать ключ). Пара ДПУ, соединенных оптическим каналом, способна выработать квантовые ключи. Как известно, у технологии КРК есть техническое ограничение на предельную дальность между устройствами, вырабатывающими квантовые ключи, чтобы преодолеть этот предел можно использовать промежуточные узлы, размещенные физически на расстоянии, не превышающем предел, и вырабатывать квантовые ключи по цепочке. При помощи квантовых ключей можно вычислить общий ключ между узлами на разных концах цепочки. Все узлы в этой цепочке должны быть доверенными. Идея естественным образом обобщается с цепочек до сети с произвольной топологией. Таким образом строится сеть из ДПУ (см. рисунок 1).

Основной сценарий взаимодействия СКЗИ с сетью ДПУ – это получение от сети ДПУ секретного ключа, предназначенного паре СКЗИ. Приведем пример возможной реализации такого сценария в соответствии с документом ETSI GS QKD 014. Пара СКЗИ-потребителей (СКЗИ1 и СКЗИ2) подключается по «классическому» каналу к разным ДПУ (ДПУ1 и ДПУ2) с целью получить общий секретный ключ, см. рис 2. Предположим, что СКЗИ1 подключено к ДПУ1, а СКЗИ2 подключено к ДПУ2, (ДПУ1 и ДПУ2 не обязательно соседние узлы сети), тогда процесс получения общего ключа для СКЗИ1 и СКЗИ2 от сети ДПУ может происходить согласно следующей схеме:

1. СКЗИ1 запрашивает у ДПУ1 ключ (для себя и СКЗИ2).
2. Сеть ДПУ вырабатывает общий ключ между ДПУ1 и ДПУ2. Если нужно, для этого задействуются ДПУ, отличные от ДПУ1 и ДПУ2.
3. ДПУ1 передает общий ключ СКЗИ1.
4. СКЗИ2 запрашивает этот же ключ у ДПУ2
5. ДПУ2 передает общий ключ СКЗИ2.

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

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

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

Для дальнейшего обозначения взаимодействующих субъектов СКЗИ будем называть СКЗИ-потребитель; а квантовую аппаратуру или узел ДПУ будем называть узел СВРК (узел системы выработки и распределения ключей). Такие обозначения соответствуют обозначениям из описания протокола «Протока». Запрашиваемый ключ будем называть целевым ключом (цель взаимодействия – получить ключ).

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

Общие тезисы о модели нарушителя

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

1. Рассматривается активный нарушитель, который может прослушивать общедоступные каналы связи, а также может модифицировать, удалять и добавлять любую информацию, которую он способен получить/сгенерировать.
2. Нарушитель помимо классического вычислителя может обладать квантовым компьютером. То есть, в частности, он способен эффективно решать некоторые задачи, на которых строятся основные криптосистемы с открытым ключом (А. Рыбкин, А. Моисеевский. Квантовый компьютинг в области ИБ. CONNECT | № 9–10, 2021.
3. Тезис, относящийся не к протоколу напрямую, а к области его применения. Из соображений целесообразности возможности нарушителя на канале между СКЗИ-потребителем и узлом СВРК должны быть меньше возможностей нарушителя на канале между двумя СКЗИ-потребителями. В противном случае выгода от применения ключей, полученных от узлов СВРК, в СКЗИ-потребителях сомнительна, так как можно организовать выработку и распределение ключей непосредственно между двумя СКЗИ-потребителями без участия узлов СВРК. Понизить возможности нарушителя на канале между СКЗИ-потребителем и узлом СВРК можно организационно техническими мерами, например, поместить оба устройства в одну контролируемую зону.  Акцентируем внимание на том, что допускаются ситуации, в которых возможности нарушителя на канале между СКЗИ-потребителем и узлом СВРК такие же, как и на каналах общего пользования. Протокол обеспечит безопасность и в этом случае, но основные преимущества система, реализующая протокол, приобретает тогда, когда возможности нарушителя на канале между СКЗИ-потребителем и узлом СВРК ниже его возможностей на канале между СКЗИ-потребителями.

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

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

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

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

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

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

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

С учетом описанных криптографических требований было решено использовать протокол CRISP [7, 8, 15, 16], который является протоколом защищенной передачи данных и разрабатывался для применения в индустриальных системах. В нём используются только механизмы защиты с секретным ключом, при этом обеспечиваются требуемые свойства безопасности: защиты конфиденциальности и целостности передаваемых данных, а также защиты от навязывания ранее принятых сообщений. Формат сообщений имеет компактный размер служебных данных и простой алгоритм формирования и разбора сообщений. В дополнение к протоколу CRISP для дополнительной защиты при передаче ключей было решено использовать экспортное представление ключа: ключ передается внутри криптографически защищенного ключевого контейнера, использование такого контейнера для передачи случайных чисел сделали опциональным. Идентификаторы отправителя и получателя сообщения передаются внутри сообщений CRISP.

В итоге, с учетом всех упомянутых соображений был спроектирован следующий протокол, получивший название «ProtoQa» или «Протока» [6].

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

Общее описание

«Протока» – протокол прикладного уровня, использующий в качестве внешнего контура защиты протокол CRISP [7, 8, 15, 16]. Протокол организован в виде обмена прикладными сообщениями: запросов и ответов на них, пара запрос и ответ на него называется сеансом.

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

Номер поля	Наименование поля	Длина поля в битах
1	ExternalKeyIdFlag	1
2	Version	15
3	CS	8
4	KeyId	328
5	SeqNum	48
6	PayloadData	(15856)
7	ICV	Зависит от значения CS

Таблица 1. Структура CRISP-сообщения в протоколе «Протока»

Поля имеют следующий смысл:

1. ExternalKeyIdFlag: в текущем описании протокола устанавливается значение «0», флаг означает, что значения поля KeyId достаточно для правильного определения базового ключа.
2. Version: поле версии протокола, в текущем описании значение «0».
3. CS: Идентификатор криптографического набора. В Протоке предусмотрено два криптонабора, подробнее смотри пункт Механизмы защиты. Алгоритмы из обоих наборов обеспечивают конфиденциальность и имитозащиту сообщения.
4. KeyId: Идентификатор базового ключа. Первый байт поля равен , это означает, что идентификатор базового ключа задается в последующих 40-а байтах. Идентификатор каждого базового ключа состоит из идентификатора отправителя и получателя CRISP-сообщения по 16 байт каждый, а также порядковый номер ключа по направлению, еще 8 байт.    
5. SeqNum: Порядковый номер сообщения между участниками задается независимо для каждого направления: от узла СВРК к СКЗИ-потребителю и от СКЗИ-потребителя к узлу СВРК разные SeqNum.
6. PayloadData: Зашифрованное прикладное сообщение. О прикладных сообщениях будет рассказано далее.
7. ICV: Имитовставка, рассчитанная для полей № 1 – 6.

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

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

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

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

Таблица 2. Cтруктура заголовка прикладного сообщения

Принцип формирования значений поля HeaderFlags.

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

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

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

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

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

Сценарии взаимодействия

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

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

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

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

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

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

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

Если ответ содержит целевой ключ, то он придет в экспортном представлении, полученном при помощи алгоритма KExp15, подробнее смотри раздел Механизмы защиты. Ключу будут соответствовать следующие атрибуты: размер (в зависимости от криптонабора до 1858 или до 1862 байт), идентификатор ключа (40 байт), размер метки (1 байт), опциональный атрибут метка (до 255 байт).

Можно заметить, что сценарию запроса ключа соответствуют три типа прикладных сообщений 02, 03 и 04.

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

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

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

На первый взгляд такое разнообразие запросов ключа может показаться избыточным: достаточно ограничиться реализацией только сообщений типа 04, но использование пары сообщений 02, 03 может оказаться удобнее. Приведем пример: пусть изготовление ключей платное, а выдача уже готового ключа бесплатная. Тогда СКЗИ-потребитель должен точно знать будет ли в результате его запроса изготовлен ключ или нет. Кроме того, использование пары запросов 02 и 03 может быть удобно для синхронизации ключей на паре СКЗИ-потребителей. Предположим, что для защиты трафика в разных направлениях должны использоваться разные ключи, тогда СКЗИ-потребители могут быть точно уверены, что они не начнут шифровать трафик на ключе, который был запрошен другим СКЗИ для шифрования трафика в противоположном направлении. Отметим, что подход с сообщениями типа 02, 03 соответствует документу ETSI 014. Использование запроса типа 04, позволяет реализовывать не два, а один вид запроса, что удобнее, если алгоритму взаимодействия между СКЗИ-потребителями достаточно только наличия одинаковых ключей у обоих СКЗИ-потребителей, а все вопросы, связанные с синхронизацией ключей, он решает самостоятельно.

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

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

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

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

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

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

Все эти ключи должны быть статистически независимыми.

Существуют ограничение на ресурс ключа, то есть определяется максимальный объем данных, который может быть обработан на одном ключе. По достижении указанной границы ключ должен быть заменен на новый. При интенсивном использовании протокола ресурс ключа может заканчиваться довольно быстро. Мы специально избегаем конкретных чисел, поскольку некоторые теоретические оценки известны Р 1323565.1.005–2017 [11], а практические ограничения на объем материала, который может быть обработан на одном ключе, «должны быть получены в рамках тематических исследований конкретных СКЗИ, реализующих описанный протокол, при оценке соответствия данных СКЗИ требованиям по безопасности информации, предъявляемых к СКЗИ, в соответствии с Р 1323565.1.012–2017 [5]». Это означает, что нужно иметь возможность оперативно заменять ключи, а для этого их нужно иметь в достаточном количестве на устройстве. Самый распространенный прием для этого – использование ключевых деревьев.

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

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

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

В качестве ТКК предлагается использовать PFX контейнер, который формируется в соответствии с P 1323565.1.041–2022 (раздел 8) [10] и Р 1323565.1.025–2019 [9]. В качестве функций вычисления производных ключей предполагается использовать функцию KDF_TREE_GOSTR3411_2012_256, в которой HMAC заменили на CMAC (блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015). Из корневого ключа вычисляются производные ключи, которые используются для вычисления еще одних производных ключей, которые и используются для защиты данных в протоколе «Протока». 

Механизмы защиты

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

1. CRISP:
   a. Шифрование прикладных сообщений алгоритмом MAGMA-CTR (Блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 в режиме гаммирования согласно ГОСТ Р 34.13-2015).
   b. Вычисление имитовставки для полей 1-6, см. рис. 3, алгоритмом MAGMA-CMAC/ MAGMA-CMAC8 [3] (блочный шифр «Магма» согласно ГОСТ Р 34.12-2015 в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015, выходное значение может усекаться до 32 бит, может оставаться 64 бита).
   c. Вычисление производных ключей алгоритмом, описанным в [7], раздел 7.1.4 с использованием блочного шифра «Магма» в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015.
   d. Механизм скользящего окна. Суть механизма следующая, у участника установлен размер окна size, участник хранит наибольший номер CRISP-сообщения SeqNum_max, который он принял ранее (имитовставка к сообщению была верная), и информацию о ранее принятых сообщениях с номерами в диапазоне от SeqNum_max – size + 1 до SeqNum_max. Если приходит сообщение из отслеживаемого диапазона, то осуществляется проверка, поступало ли сообщение с таким номером ранее, если поступало, то сообщение отбрасывается, если нет, то проверяется имитовставка, в случае успеха информация о получении фиксируется. Если приходит сообщение с номером меньшим чем SeqNum_max – size + 1, то оно отбрасывается. Если приходит сообщение с большим номером, то проверяется имитовставка, в случае успеха в значение SeqNum_max меняется на номер принятого сообщения, тем самым диапазон отслеживаемых значений сдвигается. Протокол устроен так, что при корректной работе максимальный номер SeqNum не превысит допустимый диапазон значений, так как значение SeqNum обнуляется при смене базового ключа.
2. Ключевой контейнер
   a. Для формирования ключевого контейнера и его разбора используются алгоритмы KExp15-КImp15 с блочными шифрами Магма или Кузнечик, сам алгоритм описан в [2].
   b. Значение идентификаторов ключей, которые используются в алгоритмах KExp15-КImp15, применяются в порядке возрастания идентификаторов этих ключей. Точный порядок назначения идентификаторов не зафиксирован, но в проекте документа [6] дан пример возможной идентификации этих ключей. 
3. Прикладное сообщение
   a. Механизм скользящего окна для поля SessionID. Два отличия от механизма для поля SeqNum:
   i. SessionID не обнуляется при смене ключей, а отсчитывается циклично, то есть после 2³²‑1 идет 0, 1, 2, и т.д.
   ii. Переместить отслеживаемое окно значений вправо (в сторону увеличения) за один раз можно не более чем на зафиксированное число. То есть если придет сообщение с номером сеанса, который значительно превышает положение текущего окна, то сообщение будет отброшено. Такое решение было принято, потому что при корректной работе протокола больших разрывов в номерах сеансов случаться не должно. Обнаружение этого факта может свидетельствовать о сбое.

Заключение

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

Хотелось бы выразить благодарность всем экспертам из ТК 26 и смежных ТК, принимавших участие в совещаниях и обсуждениях, посвященных протоколу, и присылавших замечания и уточнения к тексту документа.