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

Федеральное агентство по техническому регулированию и метрологии · № Р 1323565.1.034-2020Действующий акт

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

Примечание

Документ введен в действие с 01.04.2021.

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

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

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

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

ПРОТОКОЛ БЕЗОПАСНОСТИ СЕТЕВОГО УРОВНЯ

Information technology. Cryptographic data security. Network layer security protocol

Р 1323565.1.034-2020

ОКС 35.040

Дата введения 1 апреля 2021 года

Предисловие

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

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

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

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

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

Введение

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

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

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

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

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

Протокол IPlir может применяться для создания виртуальных частных сетей (Virtual Private Network) на 3-м (сетевом) уровне базовой эталонной модели ISO OSI. Защита данных осуществляется при передаче IP-пакетов между любой парой узлов, поддерживающих протокол IPlir, включая варианты взаимодействия двух оконечных узлов, оконечного узла и шлюза безопасности и двух шлюзов безопасности. Все механизмы защиты реализуются в режиме без установления соединения (в сетевом смысле) между двумя взаимодействующими узлами.

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

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

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

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

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

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

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

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

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

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

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

3.1.1 AEAD (Authenticated Encryption with Associated Data): Шифрование с имитозащитой и ассоциированными данными.

3.1.2 IP-пакет (сетевой пакет): Логически неделимый блок данных на сетевом уровне базовой эталонной модели ISO OSI, относящийся к протоколу IP.

3.1.3 IPlir-пакет: IP-пакет, защищенный с использованием IPlir-протокола.

3.1.4 IPlir-сообщение: Данные, передаваемые в теле IPlir-пакета.

3.1.5 гаммирование: Процесс наложения по определенному закону гаммы шифра на открытые данные.

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

3.1.7 исходный IP-пакет: IP-пакет до его защиты протоколом IPlir.

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

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

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

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

3.1.12 контекст сетевого узла: Информация, необходимая для обработки/создания IPlir-пакетов от/для сетевого узла, логически связанного с данным.

3.1.13 маршрутизация IPlir-пакетов: Функция пересылки IPlir-пакетов, выполняемая сетевым узлом при приеме IPlir-пакетов, которые адресованы данному сетевому узлу с точки зрения IP-протокола, но для которых он не является узлом-получателем.

3.1.14 политика приема IPlir-пакетов: Совокупность правил обработки входящих IPlir-пакетов.

3.1.15 политика безопасности: Совокупность правил обработки IP-трафика сетевым узлом.

3.1.16 производный ключ: Ключ, выработанный из исходного ключа и открытых случайных и/или фиксированных данных.

3.1.17 режим работы протокола IPlir: Один из трех режимов работы протокола IPlir: транспортный, «легкий туннель» и туннель.

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

3.1.19 синхропосылка: Комбинация знаков, передаваемая по каналу связи и предназначенная для инициализации криптографических алгоритмов.

3.1.20 сквозная имитозащита: Имитозащита, осуществляемая между узлом-отправителем и узлом-получателем.

3.1.21 транзитная имитозащита: Имитозащита, осуществляемая между парами соседних узлов в цепочке передачи пакета.

3.1.22 транзитный узел: Узел, выполняющий функцию маршрутизации IPlir-пакетов.

3.1.23 узел (сетевой узел): Сетевое устройство, имеющее уникальный идентификатор и поддерживающее протокол IPlir.

3.1.24 узел-отправитель: Узел, создающий IPlir-пакет из исходного IP-пакета.

3.1.25 узел-получатель: Узел, восстанавливающий исходный IP-пакет из IPlir-пакета.

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

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

V*	- множество всех двоичных строк конечной длины, включая пустую строку;
\|x\|	- длина (число компонент) строки x \in V^{*} ;
Vs	- множество всех двоичных строк длины s, где s — целое неотрицательное число; нумерация подстрок и компонент строки осуществляется справа налево, начиная с нуля;
x \|\| y	- конкатенация двоичных строк x и y из V*, т.е. строка из V\|x\|+\|y\|, в которой левая подстрока из V\|x\| совпадает со строкой x, а правая подстрока из V\|y\| совпадает со строкой y;
0r	- двоичная строка, состоящая из r нулей;
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;
IntToVecs(x)	- представление элемента кольца x \in \mathbb{Z}_{2^{s}} в виде двоичной строки длины s: для x = x₀ + 2·x₁ + ... + 2s-1·xs-1, где x_{i} \in V_{1} , i = 0, 1, ..., s — 1, выполнено равенство IntToVecs(x) = xs-1 \|\| ... \|\| x1 \|\| x0;
CharToByte(c)	- представление символа c в виде двоичной строки длины 8, выполняющееся по следующему правилу: CharToByte(c) = 0 \|\| IntToVec7(ASCII(c)), где ASCII(c) \in \mathbb{Z}_{2^{7}} — ASCII-представление символа c;
StrToVecs(string)	- представление символьной строки string = 'cm-1cm-2...c0', состоящей из m символов, в виде двоичной строки длины s, s >= 8·m, выполняющееся по правилу: StrToVecs('cm-1cm-2...c0') = 0s-8·m \|\| CharToByte(cm-1) \|\| CharToByte(cm-2) \|\| ... \|\| CharToByte(c0);
KENC	- ключ шифрования пакета. Длина значения определяется использованным криптографическим набором;
KMAC	- ключ сквозной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;
KAEAD	- ключ шифрования и сквозной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;
KTMAC	- ключ транзитной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;
Version	- версия IPlir-заголовка. Текущий документ описывает IPlir-заголовок, для которого Version = 1. Длина поля равна 8 бит;
CS	- идентификатор криптографического набора, определяющий состав криптографических механизмов и их параметров, используемых при создании IPlir-пакета. Длина поля равна 8 бит;
T	- флаг наличия полей для транзитной имитозащиты. Если T = 1, то в IPlir-заголовке присутствуют поля TransitIdentifier, TransitIntegrityCheckValue и TransitInitValue, иначе поля отсутствуют. При вычислении и проверке сквозной имитовставки (ICV) в поле T необходимо подставить 0. Длина поля равна 1 бит;
D	- флаг наличия поля DestinationIdentifier. Если D = 1, то в заголовке присутствует поле DestinationIdentifier, иначе поле отсутствует. Идентификатор узла-получателя необходим при маршрутизации IPlir-пакетов. Длина поля равна 1 бит;
ExtID	- флаг расширенных идентификаторов сетевых узлов. Если ExtID = 0, то все идентификаторы сетевых узлов (поле SourceIdentifier и, при наличии, поля DestinationIdentifier и TransitIdentifier) имеют длину 32 бита. Если ExtID = 1, то все идентификаторы сетевых узлов имеют длину 64 бита. Длина поля равна 1 бит;
ExtSN	- флаг расширенного порядкового номера пакета. Если ExtSN = 0, то поле порядкового номера пакета SequenceNumber имеет длину 32 бита. Если ExtSN = 1, то поле SequenceNumber имеет длину 64 бита. Длина поля равна 1 бит;
DAR	- флаг отключения механизма предотвращения повторов. Использование флага регулируется политиками безопасности. Длина поля равна 1 бит;
R1	- поле, зарезервированное для будущих применений. При формировании IPlir-заголовка поле должно быть заполнено нулями. Принимающая сторона не должна анализировать содержимое поля. Длина поля равна 3 бита;
KN	- номер ключа обмена, используемого для шифрования и вычисления сквозной имитовставки, но не для вычисления транзитной имитовставки. Длина поля равна 4 бита;
TKN	- номер ключа обмена, который использовался для вычисления транзитной имитовставки. Если транзитная имитозащита не используется, т.е. T = 0, то поле должно иметь значение 0. При вычислении и проверке сквозной имитовставки (ICV) вместо конкретного значения в поле TKN необходимо подставить 0. Длина поля равна 4 бита;
Timestamp	- время отправки пакета. Поле содержит значение времени отправки по астрономическим часам узла-отправителя в POSIX-формате времени, уменьшенное на 0x40000000 с. Время переполнения поля оценивается 2140 годом. Длина поля равна 32 бита;
SourceIdentifier	- идентификатор сетевого узла-отправителя, с помощью которого узел-получатель определяет отправителя IPlir-пакета и связанный с ним контекст узла-отправителя для обработки пакета. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;
DestinationIdentifier	- идентификатор сетевого узла-получателя, необходимый при маршрутизации IPlir-пакетов. Поле присутствует, если D = 1. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;
SequenceNumber	- порядковый номер пакета; беззнаковое целое. Длина поля равна 32 бита при ExtSN = 0 или 64 бита при ExtSN = 1;
InitValue (IV)	- сквозная синхропосылка, которая может использоваться при выполнении операций шифрования и выработки сквозной имитовставки, а также для формирования производных ключей для этих операций. Длина поля определяется использованным криптографическим набором;
Type, Length, Value	- кортежи полей (тип, длина, значение), позволяющие передавать дополнительную информацию в составе IPlir-пакета. Type — тип значения, содержащегося в поле Value. Длина поля равна 8 бит. Length — байтовая длина поля Value. Длина поля равна 8 бит. Value — произвольные данные типа Type;
PayloadData	- поле переменной длины, содержащее исходный IP-пакет или его часть, в зависимости от режима работы IPlir-протокола;
Staffing	- сетевое дополнение IPlir-пакета, позволяющее обеспечить необходимую длину IPlir-сообщения для его более эффективной обработки. Поле Staffing заполняется последовательностью целых чисел, представленных в двоичном виде: в первый байт помещается цифра 1, во второй — 2 и т.д. Длина значения определяется значением поля SL, если SL отсутствует (S = 0) или имеет значение 0, то поле Staffing отсутствует;
SL	- число байт сетевого дополнения Staffing. Поле присутствует, если S = 1. Длина поля равна 8 бит;
Mode	- режим, в котором сформирован IPlir-пакет. Длина поля равна 2 бита;
TLV	- флаг наличия полей Type, Length и Value. Если TLV = 1, то IPlir-тело начинается с кортежей (Type, Length, Value), в противном случае кортежи отсутствуют. Длина поля равна 1 бит;
S	- флаг наличия поля SL. Если S = 1, то в IPlir-теле присутствует поле SL, иначе поле отсутствует. Длина поля равна 1 бит;
R2	- поле, зарезервированное для будущих применений. При формировании IPlir-сообщения поле должно быть заполнено нулями. Принимающая сторона не должна анализировать содержимое поля. Длина поля равна 4 бита;
NextHeader	- номер протокола исходного IP-пакета. Длина поля равна 8 бит;
IntegrityCheckValue (ICV)	- сквозная имитовставка, вычисляемая для данных от начала IPlir-сообщения и до поля NextHeader включительно. Длина поля определяется использованным криптографическим набором;
TransitIdentifier	- идентификатор транзитного узла, последним маршрутизировавшего данный IPlir-пакет. Каждый транзитный узел обновляет значение этого поля, записывая в него свой идентификатор. Поле присутствует, если T = 1. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;
TransitInitValue (TIV)	- транзитная синхропосылка, которая используется при выработке транзитной имитовставки, а также для формирования производных ключей транзитной имитозащиты пакета. Поле присутствует, если T = 1. Длина поля определяется использованным криптографическим набором;
TransitIntegrityCheckValue (TICV)	- транзитная имитовставка, вычисляемая для данных от начала IPlir-сообщения и до поля TransitInitValue включительно. Поле присутствует, если T = 1. Длина поля определяется использованным криптографическим набором.

4 Состав и структура IPlir-пакета

4.1 Состав IPlir-пакета

Структура IPlir-пакета приведена на рисунке 1.

IP-заголовок	UDP-заголовок	IPlir-сообщение

Рисунок 1 — Структура IPlir-пакета

IP-заголовок представляет собой заголовок стандартного IP-пакета, в котором для IPv4 поле Protocol и для IPv6 поле NextHeader содержит значение 241 или, в случае дополнительной инкапсуляции в UDP протокол, значение 17.

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

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

4.2 Состав IPlir-сообщения

IPlir-сообщение состоит:

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

Структура IPlir-сообщения приведена на рисунке 2.

Поля IPlir-сообщения имеют сетевой (big-endian) порядок следования байт. Нумерация байтов ведется слева направо, и старшие байты имеют меньшие номера. Нумерация бит внутри байт ведется справа налево, и старшие биты имеют большие номера.

Байты	0								1								2								3
Биты	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
IPlir-заголовок	Version								CS								T	D	ExtID	ExtSN	DAR	R1			KN				TKN
	Timestamp																																Защищено ICV	Защищено TICV
	SourceIdentifier
	DestinationIdentifier
	SequenceNumber
	InitValue
IPlir-тело	T_ype1								Length1								Value1(Lenght1байт)
	...
	Typen								Lengthn								Valuen(Lengthnбайт)
	PayloadData
	Staffing
									SL								Mode		TLV	S	R2				NextHeader
IPlir-трейлер	IntegrityCheckValue (ICV)
	TransitIdentifier
	TransitInitValue
	TransitIntegrityCheckValue (TICV)

Рисунок 2 — Структура IPlir-сообщения

4.3 Кортежи (Type, Length, Value)

Кортежи (Type, Length, Value) позволяют передавать в составе IPlir-сообщения дополнительную информацию. На наличие кортежей указывает значение поля TLV. Если его значение равно 1, то в начале IPlir-тела расположен один кортеж или более.

Поле Value любого кортежа должно иметь длину, кратную 8 битам. Поле Length указывает на длину поля Value в байтах.

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

Таблица 1

Значения поля Type для кортежей

Значение Type	Описание
0	Последний кортеж в IPlir-сообщении; может использоваться производителем для собственных нужд
1	Пара IPv4 адресов
2	Пара IPv6 адресов
3 — 126	Могут использоваться для будущих нужд по согласованию с ТК 26
127	Не используется
128	Не используется
129 — 254	Могут использоваться производителем для собственных нужд
255	Не используется

Последний присутствующий в сообщении кортеж всегда имеет тип 0. Длину этого кортежа рекомендуется устанавливать из соображений эффективности обработки IPlir-сообщения.

4.3.1 Пара IPv4 адресов

В поле Value кортежа данного типа передается пара IPv4 адресов. Первым следует адрес отправителя, вторым — адрес получателя. Адреса передаются в сетевом порядке следования байт.

Основное назначение кортежа данного типа — сохранение IPv4 адресов из исходного IP-пакета при использовании режима «легкий туннель».

Структура такого кортежа приведена на рисунке 3.

Байты	0	1	2	3
Область TLV	Type=1	Length=8	IPv4 адрес отправителя, байт № 1 (старший)	..
	..	IPv4 адрес отправителя, байт № 4 (младший)	IPv4 адрес получателя, байт № 1 (старший)	..
	..	IPv4 адрес получателя, байт № 4 (младший)	Не используется	Не используется

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

Рисунок 3 — Структура кортежа Type = 1

4.3.2 Пара IPv6 адресов

В поле Value кортежа данного типа передается пара IPv6 адресов. Первым следует адрес отправителя, вторым — адрес получателя. Адреса передаются в сетевом порядке следования байт.

Основное назначение кортежа данного типа — сохранение IPv6 адресов из исходного IP-пакета при использовании режима «легкий туннель».

Структура кортежа приведена на рисунке 4.

Байты	0	1	2	3
Область TLV	Type=2	Length=32	IPv6 адрес отправителя, байт № 1 (старший)	..
	..
	..	IPv6 адрес отправителя, байт № 16 (младший)	IPv6 адрес получателя, байт № 1 (старший)	..
	..
	..	IPv6 адрес получателя, байт № 16 (младший)	Не используется	Не используется

Рисунок 4 — Структура кортежа Type = 2

4.4 Структура IPlir-пакета и расположение IPlir-заголовка

IPlir-протокол может работать в трех режимах: транспортном, туннельном и режиме «легкого туннеля». Транспортный режим и режим легкого туннеля обеспечивают защиту данных, сформированных протоколами, расположенными выше уровня IP в базовой эталонной модели ISO OSI, в частности транспортным уровнем. Туннельный режим обеспечивает защиту всего исходного IP-пакета.

Принимающая сторона определяет, в каком режиме отправлен пакет исходя из значения поля Mode. Возможные значения поля приведены в таблице 2.

Таблица 2

Значения поля Mode

Значение поля Mode	Описание режима
0	Транспортный
1	Режим легкого туннеля («легкий туннель»)
2	Туннельный (режим «туннель»)
3	Зарезервировано для будущих нужд

4.4.1 Транспортный режим

В транспортном режиме IPlir-заголовок и кортежи (Type, Length, Value) помещаются после заголовка IP и перед заголовком следующего уровня (например, TCP, UDP, ICMP и т.п.). В контексте IPv4 это означает размещение IPlir-заголовка после заголовка IP, включая все опции в исходном IP-пакете, но перед заголовком протокола следующего уровня.

На рисунке 5 показан пример защиты IP-пакета с помощью протокола IPlir в транспортном режиме.

рис. 5

Рисунок 5 — Защита IP-пакета с помощью протокола IPlir в транспортном режиме

В контексте IPv6 заголовок IPlir предназначен оконечному адресату. Таким образом, его следует размещать после заголовков-расширений Hop-by-hop, Routing и Fragmentation. Заголовки расширения опций назначения Destination Options могут размещаться до, после и по обе стороны от заголовка IPlir, в зависимости от требуемой семантики. Однако, поскольку протокол IPlir может обеспечить конфиденциальность только полей, расположенных после IPlir-заголовка, рекомендуется помещать опции адресата после IPlir-заголовка.

4.4.2 «Легкий туннель»

Расположение IPlir-заголовка и кортежей (Type, Length, Value) в режиме легкого туннеля совпадает с транспортным режимом, за исключением того, что набор кортежей, находящийся в IPlir-теле, должен включать либо кортеж типа 1 (пара IPv4 адресов), либо кортеж типа 2 (пара IPv6 адресов), в котором сохраняются адреса отправителя и получателя из IP-заголовка исходного IP-пакета. Тип кортежа диктуется версией IP-заголовка исходного IP-пакета.

Узел-получатель может восстанавливать исходные IP-адреса из поля Value доступного кортежа.

Режим легкого туннеля, в отличие от транспортного режима, дает возможность менять адреса в IP-заголовке IPlir-пакета.

На рисунке 6 показан пример защиты IP-пакета с помощью протокола IPlir в режиме «легкий туннель».

рис. 6

Рисунок 6 — Защита IP-пакета с помощью протокола IPlir в режиме «легкий туннель»

4.4.3 Туннельный режим

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

рис. 7

Рисунок 7 — Защита IP-пакета с помощью протокола IPlir в туннельном режиме

В туннельном режиме формируется новый IP-заголовок, заполняемый на основании контекста узла-получателя и таблицы IP маршрутизации узла-отправителя, за которым следует IPlir-заголовок и кортежи (Type, Length, Value). Далее размещается исходный IP-пакет.

Допускается различие версий исходного и нового IP-заголовков, т.е. возможна передача пакетов IPv6 по протоколу IPv4 и пакетов IPv4 по протоколу IPv6.

5 Обработка IPlir-пакета

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

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

В зависимости от политик безопасности и иных требований может потребоваться защита узла-получателя или транзитного узла от навязывания ранее передававшихся IPlir-пакетов для повторной обработки. Протокол IPlir обеспечивает возможность организации такой защиты за счет использования значений счетчиков и/или меток времени, а также за счет слежения за историей изменения этих значений на транзитных узлах и узле-получателе. В качестве значений счетчиков могут использоваться, к примеру, значения полей SequenceNumber, InitValue, TransitInitValue, в качестве меток времени — значения поля Timestamp. Описание конкретных механизмов, предназначенных для обеспечения защиты от навязывания ранее передававшихся IPlir-пакетов для повторной обработки, не является предметом данного документа.

5.1 Фрагментация IP- и IPlir-пакетов

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

IPlir-протокол в транспортном режиме и режиме легкого туннеля должен применяться только к целым (нефрагментированным) IP-пакетам, но не к IP-фрагментам. В туннельном режиме IPlir-протокол может применяться как к целым IP-пакетам, так и к IP-фрагментам.

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

5.2 Защита исходного IP-пакета узлом-отправителем

Если в отношении конкретного IP-пакета узлом-отправителем принято решение о его защите, то IPlir-пакет создается нижеприведенным образом.

5.2.1 Согласно контекстам узла-получателя и транзитного узла, а также используемой политике безопасности определяются:

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

5.2.2 Согласно контекстам узла-получателя и транзитного узла, а также криптографическому набору:

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

5.2.3 С учетом данных из исходного IP-пакета и выработанных ранее данных заполняются поля IPlir-пакета.

5.2.4 Выполняются зашифрование IPlir-тела (если этого требует политика безопасности) и вычисление значения сквозной имитовставки в порядке, установленном криптографическим набором. Значение сквозной имитовставки помещается в соответствующее поле IPlir-трейлера.

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

5.2.6 Формируется IPlir-пакет, в котором части исходного IP-пакета размещаются в соответствии с правилами, определенными в подразделе 4.4.

5.3 Обработка IPlir-пакета на транзитном узле

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

5.3.1 Полученный IPlir-пакет проверяется на соответствие политике приема IPlir-пакетов. Если пакет не соответствует политике, то дальнейшая обработка пакета прекращается.

5.3.2 Если версия IPlir-протокола, указанная в IPlir-заголовке, не поддерживается узлом, то дальнейшая обработка пакета прекращается.

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

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

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

5.3.6 Согласно контексту узла-получателя на транзитном узле определяется следующий транзитный узел (либо выясняется, что IPlir-пакет может быть доставлен узлу-получателю напрямую). Если контекст следующего транзитного узла (либо узла-получателя) не найден, то дальнейшая обработка пакета прекращается.

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

5.3.8 На основе контекста следующего транзитного узла, IPlir-заголовка и IPlir-трейлера вырабатываются ключ транзитной имитозащиты пакета и транзитная синхропосылка. В IPlir-сообщении устанавливаются необходимый номер ключей транзитной имитозащиты пакета и идентификатор транзитного узла. Транзитная синхропосылка размещается в поле TransitInitValue.

5.3.9 Вычисляется значение транзитной имитовставки и помещается в соответствующее поле IPlir-трейлера.

5.3.10 Формируется IPlir-пакет, в котором части исходного IP-пакета размещаются в соответствии с правилами, определенными в подразделе 4.4.

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

при отсутствии необходимости проверять целостность полученного транзитного IPlir-пакета шаги 5.3.3 - 5.3.5 приведенного алгоритма не выполняются;
при отсутствии необходимости в вычислении транзитной имитовставки шаги 5.3.7 - 5.3.9 приведенного выше алгоритма не выполняются;
при отсутствии требования по транзитной защите шаги 5.3.3 - 5.3.5, 5.3.7 - 5.3.9 приведенного выше алгоритма не выполняются.

5.4 Восстановление исходного IP-пакета узлом-получателем

Узел-получатель, получив IPlir-пакет, выполняет следующие шаги по восстановлению исходного IP-пакета.

5.4.1 Полученный IPlir-пакет проверяется на соответствие политике приема IPlir-пакетов. Если пакет не соответствует политике, то дальнейшая обработка пакета прекращается.

5.4.2 Если версия IPlir-протокола, указанная в IPlir-заголовке, не поддерживается узлом, то дальнейшая обработка пакета прекращается.

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

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

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

5.4.6 На основе контекста узла-отправителя и IPlir-заголовка вырабатываются ключ шифрования пакета и ключ сквозной имитозащиты пакета.

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

5.4.8 Восстанавливается IP-пакет в соответствии с правилами подраздела 4.4.

Возможны сценарии, когда в соответствии с политиками безопасности не требуется проверять транзитную имитовставку узлом-получателем. В таком случае шаги 5.4.3, 5.4.4 приведенного алгоритма не выполняются.

6 Описание криптографических алгоритмов

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

6.1 Шифрование и имитозащита

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

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

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

6.2 Криптографические ключи

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

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

Для корректного функционирования протокола IPlir подразумевается наличие системы нумерации узлов, в которой каждому узлу присваивается уникальный идентификатор. При этом заданной паре узлов и заданному криптографическому набору соответствует отдельный ключ обмена, индексируемый парой идентификаторов этих узлов и номером криптографического набора. Допускается использование ключевых систем, в которых для заданной пары узлов и заданного криптографического набора предусмотрено существование нескольких ключей обмена одновременно (не более 16). Для обеспечения данной возможности каждый ключ обмена в протоколе IPlir дополнительно индексируется целочисленным значением от 0 до 15, размещаемым в поле KN или поле TKN IPlir-сообщения и позволяющим однозначно определить ключ обмена для заданной пары узлов и заданного криптографического набора.

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

Ключ обмена, на основе которого вырабатываются ключи шифрования пакета и сквозной имитозащиты пакета (или ключ шифрования и сквозной имитозащиты пакета), определяется значением поля KN IPlir-сообщения, идентификаторами узла-отправителя и узла-получателя и номером криптографического набора. Ключ обмена, на основе которого вырабатывается ключ транзитной имитозащиты пакета, определяется значением поля TKN IPlir-сообщения, идентификаторами взаимодействующих (транзитных) узлов и номером криптографического набора.

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

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

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

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

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

6.3 Криптографические наборы

Совокупность используемых в протоколе IPlir криптографических алгоритмов и параметров составляет криптонабор, который задается своим номером CS, размещаемым в поле CS каждого IPlir-сообщения. Всего может существовать не более 256 различных криптонаборов.

Допустимые значения поля CS представлены в таблице 3.

Таблица 3

Значения поля CS

Значение CS	Описание
0	Не используется
1	Криптонабор MAGMA-MGM
2	Криптонабор KUZN-CTR-CMAC
3 — 126	Могут использоваться для будущих нужд по согласованию с ТК 26
127	Не используется
128	Не используется
129 — 254	Могут использоваться производителем для собственных нужд
255	Не используется

Список основных механизмов и параметров, определяемых и/или описываемых в криптонаборе, приведен в таблице 4.

Таблица 4

Состав криптонабора

Параметр	Описание	Правила задания	Назначение
EncAlg	Алгоритм шифрования	Описание алгоритма (или ссылка на такое описание), включая задание всех необходимых параметров	Алгоритм используется для шифрования пакета
MACAlg	Алгоритм сквозной имитозащиты		Алгоритм используется для сквозной имитозащиты пакета
TMACAlg	Алгоритм транзитной имитозащиты		Алгоритм используется для транзитной имитозащиты пакета
MACLen	Длина сквозной имитовставки	Задается в битах	-
TMACLen	Длина транзитной имитовставки		-
IVLen	Длина сквозной синхропосылки		Сквозная синхропосылка может использоваться при шифровании пакета, сквозной имитозащите пакета, а также при формировании ключей шифрования пакета и ключей сквозной имитозащиты пакета (или ключей шифрования и сквозной имитозащиты пакета)
TIVLen	Длина транзитной синхропосылки		Транзитная синхропосылка может использоваться при транзитной имитозащите пакета, а также при формировании ключей транзитной имитозащиты пакета
KDAlg	Алгоритмы выработки ключей защиты пакета из ключей обмена	Описание алгоритмов (или ссылки на такое описание), включая задание всех необходимых параметров	Алгоритмы используются для формирования ключей шифрования пакета и ключей сквозной имитозащиты пакета (или ключей шифрования и сквозной имитозащиты пакета), а также для формирования ключей транзитной имитозащиты пакета

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

6.3.1 Криптографический набор MAGMA-MGM: CS = 1

Описание данного криптонабора приведено в таблице 5.

Таблица 5

Описание криптонабора MAGMA-MGM

Параметр	Значение
EncAlg	ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019
MACAlg	ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019
TMACAlg	ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019
MACLen	32 бита
TMACLen	32 бита
IVLen	64 бита
TIVLen	64 бита
KDAlg	См. описание далее

6.3.1.1 Ключи обмена

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

Допускается наличие нескольких единых ключей обмена для пары взаимодействующих узлов. Для определения конкретного единого ключа обмена используется значение поля KN IPlir-сообщения (в случае выработки ключей шифрования и сквозной имитозащиты пакета) или значение поля TKN IPlir-сообщения (в случае выработки ключей транзитной имитозащиты пакета).

6.3.1.2 Требования к синхропосылкам

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

Транзитная синхропосылка TransitInitValue, размещаемая в поле TransitInitValue IPlir-сообщения, должна иметь длину 64 бита и быть уникальной для каждого IPlir-пакета, защищаемого посредством транзитной имитозащиты одним и тем же (транзитным) узлом с использованием одного и того же единого ключа обмена.

6.3.1.3 Алгоритмы вычисления производных ключей

Ключ шифрования и сквозной имитозащиты пакета KAEAD длины 256 бит вычисляется следующим образом:

KAEAD = K1 || K2 || K3 || K4,

где каждое значение K_{i} \in V_{64} , i = 1, 2, 3, 4 вычисляется в соответствии с ГОСТ 34.12-2018 («Магма») в режиме выработки имитовставки согласно ГОСТ 34.13-2018, причем:

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

IntToVec8(i) || Label || aL || IVKDF || || SN || Node || cL || oL,

где

- Label = StrToVec48('AEAD');
- aL = IntToVec8(LabelByteLenght), где LabelByteLength = 6;
- IVKDF = InitValue, где InitValue инициализируется значением поля InitValue IPlir-сообщения;
- SN = SequenceNumber, где SequenceNumber инициализируется значением поля SequenceNumber IPlir-сообщения;
- Node = SourceIdentifier, где SourceIdentifier инициализируется значением поля SourceIdentifier IPlir-сообщения;
- cL = IntToVec16(ContextByteLenght), где ContextByteLength — сумма байтовых длин полей InitValue, SequenceNumber и SourceIdentifier IPlir-сообщения;
- oL = IntToVec16(OutputBitLenght), где OutputBitLength = 256;

длина имитовставки s равна 64 бита.

Ключ транзитной имитозащиты пакета KTMAC длины 256 бит вычисляется следующим образом:

KTMAC = K1 || K2 || K3 || K4,

в качестве ключа используется единый ключ обмена, соответствующий заданным (транзитным) узлам, через которые проходит IPlir-пакет, а также значению поля TKN IPlir-сообщения;
в качестве данных используется двоичная строка вида

IntToVec8(i) || Label || aL || TIVKDF || || SN || Node || cL || oL,

где

- Label = StrToVec48('TMAC');
- aL = IntToVec8(LabelByteLenght), где LabelByteLength = 6;
- TIVKDF = TransitInitValue, где TransitInitValue инициализируется значением поля TransitInitValue IPlir-сообщения;
- SN = SequenceNumber, где SequenceNumber инициализируется значением поля SequenceNumber IPlir-сообщения;
- Node = TransitIdentifier, где TransitIdentifier инициализируется значением поля TransitIdentifier IPlir-сообщения;
- cL = IntToVec16(ContextByteLenght), где ContextByteLength — сумма байтовых длин полей TransitInitValue, SequenceNumber и TransitIdentifier IPlir-сообщения;
- oL = IntToVec16(OutputBitLenght), где OutputBitLength = 256;

длина имитовставки s равна 64 бита.

6.3.1.4 Алгоритмы шифрования и имитозащиты

Шифрование IPlir-тела и вычисление сквозной имитовставки ICV, размещаемой в поле IntegrityCheckValue IPlir-сообщения, происходит в соответствии с алгоритмом ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019, причем:

в качестве ключа используется ключ шифрования и сквозной имитозащиты пакета KAEAD;
в качестве дополнительных имитозащищаемых данных используются данные полей IPlir-заголовка в порядке, совпадающем с порядком их следования в IPlir-сообщении;
в качестве открытого текста используются данные полей IPlir-тела в порядке, совпадающем с порядком их следования в IPlir-сообщении;
в качестве уникального вектора используется величина IV_{AEAD} \in V_{63} :

IVAEAD = LSB63(InitValue),

где InitValue инициализируется значением поля InitValue IPlir-сообщения;

длина имитовставки s равна 32 бита.

Схема выполнения шифрования и сквозной имитозащиты приведена на рисунке 8.

рис. 8

Рисунок 8 — Схема выполнения шифрования и сквозной имитозащиты при использовании криптонабора MAGMA-MGM

Вычисление транзитной имитовставки TICV, размещаемой в поле TransitIntegrityCheckValue IPlir-сообщения, происходит в соответствии с алгоритмом ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019, причем:

в качестве ключа используется ключ транзитной имитозащиты пакета KTMAC;
в качестве дополнительных имитозащищаемых данных используются данные полей IPlir-заголовка, зашифрованное IPlir-тело и данные полей IntegrityCheckValue, TransitIdentifier, TransitInitValue в порядке, совпадающем с порядком их следования в IPlir-сообщении;
открытый текст представляет собой пустую строку;
в качестве уникального вектора используется величина TIV_{AEAD} \in V_{63} :

TIVAEAD = LSB63(TransitInitValue),

где TransitInitValue инициализируется значением поля TransitInitValue IPlir-сообщения;

длина имитовставки s равна 32 бита.

Схема выполнения транзитной имитозащиты приведена на рисунке 9. Под значением «null» подразумевается пустая двоичная строка.

рис. 9

Рисунок 9 — Схема выполнения транзитной имитозащиты при использовании криптонабора MAGMA-MGM

6.3.2 Криптографический набор KUZN-CTR-CMAC: CS=2

Описание данного криптонабора приведено в таблице 6.

Таблица 6

Описание криптонабора KUZN-CTR-CMAC

Параметр	Значение
EncAlg	ГОСТ 34.12-2018 («Кузнечик») в режиме гаммирования согласно ГОСТ 34.13-2018
MACAlg	ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018
TMACAlg	ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018
MACLen	64 бита
TMACLen	64 бита
IVLen	64 бита
TIVLen	64 бита
KDAlg	См. описание далее

6.3.2.1 Ключи обмена

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

Допускается наличие нескольких единых ключей обмена для пары взаимодействующих узлов. Для определения конкретного единого ключа обмена используется значение поля KN IPlir-сообщения (в случае выработки ключей шифрования пакета и ключей сквозной имитозащиты пакета) или значение поля TKN IPlir-сообщения (в случае выработки ключей транзитной имитозащиты пакета).

6.3.2.2 Требования к синхропосылкам

6.3.2.3 Алгоритмы вычисления производных ключей

Ключ шифрования пакета KENC длины 256 бит и ключ сквозной имитозащиты пакета KMAC длины 256 бит вычисляются следующим образом:

KENC = K1 || K2,

KMAC = K3 || K4,

где каждое значение K_{i} \in V_{128} , i = 1, 2, 3, 4 вычисляется в соответствии с ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018, причем:

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

IntToVec8(i) || Label || aL || IVKDF || || SN || Node || cL || oL,

где

- Label = StrToVec48('ENCMAC');
- aL = IntToVec8(LabelByteLenght), где LabelByteLength = 6;
- IVKDF = InitValue, где InitValue инициализируется значением поля InitValue IPlir-сообщения;
- SN = SequenceNumber, где SequenceNumber инициализируется значением поля SequenceNumber IPlir-сообщения;
- Node = SourceIdentifier, где SourceIdentifier инициализируется значением поля SourceIdentifier IPlir-сообщения;
- cL = IntToVec16(ContextByteLenght), где ContextByteLength — сумма байтовых длин полей InitValue, SequenceNumber и SourceIdentifier IPlir-сообщения;
- oL = IntToVec16(OutputBitLenght), где OutputBitLength = 512;

длина имитовставки s равна 128 бит.

Ключ транзитной имитозащиты пакета KTMAC длины 256 бит вычисляется следующим образом:

KTMAC = K1 || K2,

где каждое значение K_{i} \in V_{128} , i = 1, 2 вычисляется в соответствии с ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018, причем:

в качестве ключа используется единый ключ обмена, соответствующий заданным (транзитным) узлам, через которые проходит IPlir-пакет, а также значению поля TKN IPlir-сообщения;
в качестве данных используется строка вида

IntToVec8(i) || Label || aL || TIVKDF || || SN || Node || cL || oL,

где

длина имитовставки s равна 128 бит.

6.3.2.4 Алгоритмы шифрования и имитозащиты

Шифрование IPlir-тела происходит в соответствии с алгоритмом ГОСТ 34.12-2018 («Кузнечик») в режиме гаммирования согласно ГОСТ 34.13-2018, причем:

в качестве ключа используется ключ шифрования пакета KENC;
в качестве открытого текста используются данные полей IPlir-тела в порядке, совпадающем с порядком их следования в IPlir-сообщении;
в качестве синхропосылки используется величина IV_{ENC} \in V_{64} :

IVENC = InitValue,

где InitValue инициализируется значением поля InitValue IPlir-сообщения;

длина блоков гаммы s равна 128 бит.

Вычисление сквозной имитовставки ICV, размещаемой в поле IntegrityCheckValue IPlir-сообщения, происходит в соответствии с алгоритмом ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018, причем:

в качестве ключа используется ключ сквозной имитозащиты пакета KMAC;
в качестве данных используются данные полей IPlir-заголовка и зашифрованное IPlir-тело в порядке, совпадающем с порядком их следования в IPlir-сообщении;
длина имитовставки s равна 64 бита.

Схема выполнения шифрования и сквозной имитозащиты приведена на рисунке 10.

рис. 10

Рисунок 10 — Схема выполнения шифрования и сквозной имитозащиты при использовании криптонабора KUZN-CTR-CMAC

Вычисление транзитной имитовставки TICV, размещаемой в поле TransitIntegrityCheckValue IPlir-сообщения, происходит в соответствии с алгоритмом ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018, причем:

в качестве ключа используется ключ транзитной имитозащиты пакета KTMAC;
в качестве данных используются данные полей IPlir-заголовка, зашифрованное IPlir-тело и данные полей IntegrityCheckValue, TransitIdentifier, TransitInitValue в порядке, совпадающем с порядком их следования в IPlir-сообщении;
длина имитовставки s равна 64 бита.

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

рис. 11

Рисунок 11 — Схема выполнения транзитной имитозащиты при использовании криптонабора KUZN-CTR-CMAC

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

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

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

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

В настоящем приложении двоичные строки из V*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации («||») опускается, т.е. строка a \in V_{4r} будет представлена в виде ar-1ar-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

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

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 Ключи обмена

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

Kmaster = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef16

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

K'master = ffeeddccbbaa99887766554433221100\ f0f1f₂f3f4f5f₆f7f8f9fafbfcfdfeff16

А.2 Криптографический набор MAGMA-MGM

А.2.1 Сообщение M1

Пусть IPlir-сообщение M1, подлежащее криптографической защите, имеет следующий вид:

M1 = 0101c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6778\ 5b77468ea1236c71\ 0800769313e3008a5bad5a5d00000000\ e_d210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f3031323334353637\ 0001\ 00000000\ 00000000\ 0000000000000000\ 0000000016

Тогда поля IPlir-сообщения M1 содержат следующие значения:

Version = 0116

CS = 0116

T = 1

D = 1

ExtID = 0

ExtSN = 0

DAR = 0

R1 = 000

KN = 116

TKN = 116

Timestamp = 1c2aadbc16

SourceIdentifier = 4321000116

DestinationIdentifier = 4321000216

SequenceNumber = 56ee677816

InitValue = 5b77468ea1236c7116

PayloadData = 0800769313e3008a5bad5a5d00000000\ e_d210b00000000001011121314151617\ 18_191a1b1c1d_1e1f2021222324252627\ 282_92a2b2c2d2_e2f303132333435363716

Mode = 00

TLV = 0

S = 0

R2 = 016

NextHeader = 0116

IntegrityCheckValue = 0000000016

TransitIdentifier = 0000000016

TransitInitValue = 000000000000000016

TransitIntegrityCheckValue = 0000000016

Идентификатор криптонабора в IPlir-сообщении M1 имеет значение CS = 1, поэтому криптографическая защита сообщения выполняется согласно описанию криптографического набора MAGMA-MGM.

А.2.1.1 Выполнение шифрования и сквозной имитозащиты

А.2.1.1.1 Вычисление производного ключа

Для вычисления производного ключа KAEAD на вход алгоритму ГОСТ 34.12-2018 («Магма») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

ключ (ключ обмена)

Kmaster = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef16

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 000041454144\ 06\ 5_b77468ea1236c71\ 56ee6778\ 43210001\ 0010\ 010016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 000041454144\ 06\ 5_b77468ea1236c71\ 56ee6778\ 43210001\ 0010\ 010016 - при вычислении части ключа K3 IntToVec8(3) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 03\ 000041454144\ 06\ 5_b77468ea1236c71\ 56ee6778\ 43210001\ 0010\ 010016
- при вычислении части ключа K4 IntToVec8(4) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 04\ 000041454144\ 06\ 5b77468ea1236c71\ 56ee6778\ 43210001\ 0010\ 010016

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || IVKDF || SN || Node || cL || oL =
= 01\
000041454144\
06\
5_b77468ea1236c71\
56ee6778\
43210001\
0010\
010016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || IVKDF || SN || Node || cL || oL =
= 02\
000041454144\
06\
5_b77468ea1236c71\
56ee6778\
43210001\
0010\
010016
- при вычислении части ключа K3
IntToVec8(3) || Label || aL || IVKDF || SN || Node || cL || oL =
= 03\
000041454144\
06\
5_b77468ea1236c71\
56ee6778\
43210001\
0010\
010016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || IVKDF || SN || Node || cL || oL =
= 04\
000041454144\
06\
5b77468ea1236c71\
56ee6778\
43210001\
0010\
010016

Выходным значением алгоритма ГОСТ 34.12-2018 («Магма») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 является соответствующая часть ключа:

K1 = b037a3cde12fd3fd16

K2 = d17f96fbd94696c216

K3 = 56c6afe9742db87116

K4 = 81662454def36de316

Итоговое значение ключа KAEAD равно

KAEAD = b037a3cde12fd3fdd17f96fbd94696c2\ 5_6c6afe9742db87181662454def36de316

А.2.1.1.2 Шифрование и сквозная имитозащита

Для выполнения шифрования и сквозной имитозащиты пакета на вход алгоритму ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019 подаются:

- ключ (ключ шифрования и сквозной имитозащиты пакета)
KAEAD = b037a3cde12fd3fdd17f96fbd94696c2\
56_c6afe9742db87181662454def36de316
- дополнительные имитозащищаемые данные (IPlir-заголовок):
Version || CS || 0 || D || ExtID || ExtSN || DAR || R1 || KN || 016 || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue =
= 01014010\
1c2aadbc\
43210001\
43210002\
56ee6778\
5b77468e_a1236c7116
- открытый текст (IPlir-тело):
PayloadData || Mode || TLV || S || R2 || NextHeader =
= 0800769313_e3008a5bad5a5d00000000\
ed210b00000000001011121314151617\
18191a1b1c1d1e1f2021222324252627\
28292a2b2c2d2e2f3031323334353637\
000116
- уникальный вектор:
IVAEAD = 5b77468ea1236c7116

Выходными значениями алгоритма ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019, являются:

- шифртекст (зашифрованное IPlir-тело): EncryptedIPlirBody = = 4f90_9d101fd3c7d759_2b51e₆₈_d742253\ 0b58b5797a5294a250f79fca28b2820a\ 580b6fdcc6406c2c7c63c9891c6b2119\ 60d187095f2bc151ed7e62466ee55d62\ 13cc16 - имитовставка (сквозная): IntegrityCheckValue = d9b70c2516

Тогда после шифрования и сквозной имитозащиты IPlir-сообщение принимает следующий вид:

M'1 = 0101c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6778\ 5b77468ea1236c71\ 4f909d101fd3c7d7592b51e68d742253\ 0b58b5797a5294a250f79fca28b2820a\ 580b6fdcc6406c2c7c63c9891c6b2119\ 60d187095f2bc151ed7e62466ee55d62\ 13cc\ d9b70c25\ 00000000\ 0000000000000000\ 0000000016

А.2.1.2 Выполнение транзитной имитозащиты

Флаг наличия полей для транзитной имитозащиты в IPlir-сообщении M1 имеет значение T = 1, поэтому для сообщения требуется выполнение транзитной имитозащиты.

Пусть идентификатор транзитного узла равен

TransitIdentifier = 4321000316

и транзитная синхропосылка равна

TransitInitValue = 55735cb2bd57287b16

А.2.1.2.1 Вычисление производного ключа

Для вычисления производного ключа транзитной имитозащиты пакета KTMAC на вход алгоритму ГОСТ 34.12-2018 («Магма») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

- ключ (ключ обмена) K'master = ffeeddccbbaa99887766554433221100\ f_0f1f2f3f4f5f6f7f8f9fafbfcfdfeff₁₆

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6778\ 43210003\ 0010\ 010016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6778\ 43210003\ 0010\ 010016 - при вычислении части ключа K3 IntToVec8(3) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 03\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6778\ 43210003\ 0010\ 010016
- при вычислении части ключа K4 IntToVec8(4) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 04\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6778\ 43210003\ 0010\ 010016

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 01\
0000544d4143\
06\
55735cb2bd57287b\
56ee6778\
43210003\
0010\
010016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 02\
0000544d4143\
06\
55735cb2bd57287b\
56ee6778\
43210003\
0010\
010016
- при вычислении части ключа K3
IntToVec8(3) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 03\
0000544d4143\
06\
55735cb2bd57287b\
56ee6778\
43210003\
0010\
010016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 04\
0000544d4143\
06\
55735cb2bd57287b\
56ee6778\
43210003\
0010\
010016

K1 = 3de55f45f19a181a16

K2 = 4b8d8899263e465216

K3 = a713aaf64546e4a016

K4 = bb6fa8323ea2289816

Итоговое значение ключа KTMAC равно

KTMAC = 3de55f45f19a181a4_b8d8899263e4652\ a_713aaf64546e4a0bb6fa8323ea2289816

А.2.1.2.2 Транзитная имитозащита

Для выполнения транзитной имитозащиты на вход алгоритму ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019 подаются:

- ключ (ключ транзитной имитозащиты пакета) KTMAC = 3de55f45f19a181a4b8d8899263e4652\ a_713aaf64546e4a0bb6fa8323ea2289816

дополнительные имитозащищаемые данные (IPlir-заголовок, зашифрованное IPlir-тело, значения полей IntegrityCheckValue, TransitIdentifier, TransitInitValue):

Version || CS || T || D || ExtID || ExtSN || DAR || R1 || KN || TKN || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody || IntegrityCheckValue || TransitIdentifier || TransitInitValue =
= 0101c011\
1c2aadbc\
43210001\
43210002\
56ee6778\
5b77468ea1236c71\
4f_909d101fd3c7d7592b51e68_d742253\
0b58b579_7a5294a250f79fca28b2820a\
580b6fdcc6406c2c7c63c9891c6b2119\
60d187095f2bc151ed7e62466ee55d62\
13cc\
d9b70c25\
43210003\
55735cb2bd57287b16
- открытый текст (IPlir-тело):
null0VÎ

- уникальный вектор:
IVTMAC = 55735cb2bd57287b16

Выходными значениями алгоритма ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019 являются:

- шифртекст: - имитовставка (транзитная): TransitIntegrityCheckValue = b56_0d68416

Тогда после транзитной имитозащиты IPlir-сообщение принимает следующий вид:

M«1 = 0101c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6778\ 5b77468ea1236c71\ 4f909d101fd3c7d7592b5_1e68_d742253\ 0b58b5797a5294a250f79fca28b2820a\ 580b6fdcc6406c2c7c63c9891c6b2119\ 60d187095f2bc151ed7e62466ee55d62\ 13cc\ d9b70c25\ 43210003\ 55735cb2bd57287b\ b560d68416»

А.2.2 Сообщение M2

Пусть IPlir-сообщение M2, подлежащее криптографической защите, имеет следующий вид:

M2 = 0101f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677a\ 5b77468ea1236c71\ 0800769313e3008a5bad5a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f3031323334353637\ 0001\ 00000000\ 0000000000000000\ 0000000000000000\ 0000000016

Тогда поля IPlir-сообщения M2 содержат следующие значения:

Version = 0116

CS = 0116

T = 1

D = 1

ExtID = 1

ExtSN = 1

DAR = 0

R1 = 000

KN = 116

TKN = 116

Timestamp = 1c2aadbc16

SourceIdentifier = 432100000000000116

DestinationIdentifier = 432100000000000216

SequenceNumber = 0000000056ee677_a16

InitValue = 5b77468ea1236c7116

PayloadData = 0800769313e3008a5bad5a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f303132333435363716

Mode = 00

TLV = 0

S = 0

R2 = 016

NextHeader = 0116

IntegrityCheckValue = 0000000016

TransitIdentifier = 000000000000000016

TransitInitValue = 000000000000000016

TransitIntegrityCheckValue = 0000000016

Идентификатор криптонабора в IPlir-сообщении M2 имеет значение CS = 1, поэтому криптографическая защита сообщения выполняется согласно описанию криптографического набора MAGMA-MGM.

А.2.2.1 Выполнение шифрования и сквозной имитозащиты

А.2.2.1.1 Вычисление производного ключа

ключ (ключ обмена)

Kmaster = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef₁₆

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 000041454144\ 06\ 5b77468ea1236c71\ 0000000056ee677a\ 4321000000000001\ 0018\ 010016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 000041454144\ 06\ 5b77468ea1236c71\ 0000000056ee677a\ 4321000000000001\ 0018\ 010016 - при вычислении части ключа K3 intToVec8(3) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 03\ 000041454144\ 06\ 5b77468ea1236c71\ 0000000056ee677a\ 4321000000000001\ 0018\ 010016
- при вычислении части ключа K4 IntToVec8(4) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 04\ 000041454144\ 06\ 5b77468ea1236c71\ 0000000056ee677a\ 4321000000000001\ 0018\ 010016

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || IVKDF || SN || Node || cL || oL =
= 01\
000041454144\
06\
5b77468ea1236c71\
0000000056ee677a\
4321000000000001\
0018\
010016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || IVKDF || SN || Node || cL || oL =
= 02\
000041454144\
06\
5b77468ea1236c71\
0000000056ee677a\
4321000000000001\
0018\
010016
- при вычислении части ключа K3
intToVec8(3) || Label || aL || IVKDF || SN || Node || cL || oL =
= 03\
000041454144\
06\
5b77468ea1236c71\
0000000056ee677a\
4321000000000001\
0018\
010016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || IVKDF || SN || Node || cL || oL =
= 04\
000041454144\
06\
5b77468ea1236c71\
0000000056ee677a\
4321000000000001\
0018\
010016

K1 = b7152dfdee9ede3816

K2 = 2fbd9c707f92690016

K3 = b8f8b8819dc44b5d16

K4 = f8574653b15d10ce16

Итоговое значение ключа KAEAD равно

KAEAD = b7152dfdee9ede382fbd9c707f926900\ b8_f8b8819dc44b5df8574653b₁₅d10ce16

А.2.2.1.2 Шифрование и сквозная имитозащита

- ключ (ключ шифрования и сквозной имитозащиты пакета)
KAEAD = _b7152dfdee9ede382fbd9c707f926900\
b₈f8b881_9dc44b5df8574653b15d10ce16
- дополнительные имитозащищаемые данные (IPlir-заголовок):
Version || CS || 0 || D || ExtID || ExtSN || DAR || R1 || KN || 016 || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue =
= 01017010\
1c2aadbc\
4321000000000001\
4321000000000002\
0000000056ee677a \
5b77468ea1236c7116
- открытый текст (IPlir-тело):
PayloadData || Mode || TLV || S || R2 || NextHeader =
= 0800769313_e3008a5bad5a5d00000000\
ed210b00000000001011121314151617\
18191a1b1c1d1e1f2021222324252627\
28292a2b2c2d2e2f3031323334353637\
000116
- уникальный вектор:
IVAEAD = 5b77468ea1236c7116

Выходными значениями алгоритма ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019 являются:

- шифртекст (зашифрованное IPlir-тело): EncryptedIPlirBody = = d1ffca665d505fcbcae2c5f6ef54c732\ 67c41b028efb75cbedd70f5b753c1539\ 00179f998b9f58a41d2d2499c3ef6956\ 6d5a09a14afb208efff8cc13abe2a188\ 125a16 - имитовставка (сквозная): IntegrityCheckValue = efee055a16

Тогда после шифрования и сквозной имитозащиты IPlir-сообщение принимает следующий вид:

M'2 = 0101f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677a\ 5b77468ea1236c71\ d1ffca665d505fcbcae2c5f6ef54c732\ 67c41b028efb75cbedd70f5b753c1539\ 00179f998b9f58a41d2d2499c3ef6956\ 6d5a09a14afb208efff8cc13abe2a188\ 125a\ efee055a\ 0000000000000000\ 0000000000000000\ 0000000016

А.2.2.2 Выполнение транзитной имитозащиты

Флаг наличия полей для транзитной имитозащиты в IPlir-сообщении M2 имеет значение T = 1, поэтому для сообщения требуется выполнение транзитной имитозащиты.

Пусть идентификатор транзитного узла равен

TransitIdentifier = 432100000000000316

и транзитная синхропосылка равна

TransitInitValue = 55735cb2bd57287b16

А.2.2.2.1 Вычисление производного ключа

ключ (ключ обмена)

K'master = ffeeddccbbaa99887766554433221100\ f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff16

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 0000544d4143\ 06\ 55735cb2bd57287b\ 0000000056ee677a\ 4321000000000003\ 0018\ 010016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 0000544d4143\ 06\ 55735cb2bd57287b\ 0000000056ee677a\ 4321000000000003\ 0018\ 010016 - при вычислении части ключа K3 IntToVec8(3) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 03\ 0000544d4143\ 06\ 55735cb2bd57287b\ 0000000056ee677a\ 4321000000000003\ 0018\ 010016
- при вычислении части ключа K4 IntToVec8(4) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 04\ 0000544d4143\ 06\ 55735cb2bd57287b\ 0000000056ee677a\ 4321000000000003\ 0018\ 010016

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 01\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677a\
4321000000000003\
0018\
010016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 02\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677a\
4321000000000003\
0018\
010016
- при вычислении части ключа K3
IntToVec8(3) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 03\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677a\
4321000000000003\
0018\
010016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 04\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677a\
4321000000000003\
0018\
010016

K1 = 291dbdfc51cfeee116

K2 = a58d580028e9f16716

K3 = 393fb14579d18e5a16

K4 = f03f7ac4349ea3b516

Итоговое значение ключа KTMAC равно

KTMAC = 291dbdfc51cfeee1a58d580028e9f167\ 393fb14579d18e5af03f7ac4349ea3b516

А.2.2.2.2 Транзитная имитозащита

- ключ (ключ транзитной имитозащиты пакета)
KTMAC = 291dbdfc51cfeee1a58d580028e9f167\
393fb14579d18e5af03f7ac4349ea3b516
- дополнительные имитозащищаемые данные (IPlir-заголовок, зашифрованное IPlir-тело, значения полей IntegrityCheckValue, TransitIdentifier, TransitInitValue):
Version || CS || T || D || ExtID || ExtSN || DAR || R1 || KN || TKN || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody || IntegrityCheckValue || TransitIdentifier ||
TransitInitValue =
= 0101f011\
1c2aadbc\
4321000000000001\
4321000000000002\
0000000056ee677a\
5b77468ea1236c71\
d1ffca665d505fcbcae2c5f6ef54c732\
67c41b028efb75cbedd70f5b753c1539\
00179f998b9f58a41d2d2499c3ef6956\
6d5a09a14afb208efff8cc13abe2a188\
125a\
efee055a\
4321000000000003\
55735cb2bd57287b16

открытый текст (IPlir-тело):

null0VÎ

уникальный вектор:

IVTMAC = 55735cb2bd57287b16

Выходными значениями алгоритма ГОСТ 34.12-2018 («Магма») в режиме MGM согласно Р 1323565.1.026-2019 являются:

шифртекст:

null0VÎ

имитовставка (транзитная):

TransitIntegrityCheckValue = bcdf4bf316

Тогда после транзитной имитозащиты IPlir-сообщение принимает следующий вид:

M«2 = 0101f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677a\ 5b77468ea1236c71\ d1ffca665d505fcbcae2c5f6ef54c732\ 67c41b028efb75cbedd70f5b753c1539\ 00179f998b9f58a41d2d2499c3ef6956\ 6d5a09a14afb208efff8cc13abe2a188\ 125a\ efee055a\ 4321000000000003\ 55735cb2bd57287b\ bcdf4bf316»

А.3 Криптографический набор KUZN-CTR-CMAC

А.3.1 Сообщение M3

Пусть IPlir-сообщение M3, подлежащее криптографической защите, имеет следующий вид:

M3 = 0102c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6779\ 5b77468ea1236c71\ 0800769313e3008a5bad5a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f3031323334353637\ 0001\ 0000000000000000\ 00000000\ 0000000000000000\ 000000000000000016

Тогда поля IPlir-сообщения M3 содержат следующие значения:

Version = 0116

CS = 0216

T = 1

D = 1

ExtID = 0

ExtSN = 0

DAR = 0

R1 = 000

KN = 116

TKN = 116

Timestamp = 1c2aadbc16

SourceIdentifier = 4321000116

DestinationIdentifier = 4321000216

SequenceNumber = 56ee677916

InitValue = 5b77468ea1236c7116

PayloadData = 0800769313e300_8a5ba_d5_a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f303132333435363716

Mode = 00

TLV = 0

S = 0

R2 = 016

NextHeader = 0116

IntegrityCheckValue = 000000000000000016

TransitIdentifier = 0000000016

TransitInitValue = 000000000000000016

TransitIntegrityCheckValue = 000000000000000016

Идентификатор криптонабора в IPlir-сообщении M3 имеет значение CS = 2, поэтому криптографическая защита сообщения выполняется согласно описанию криптографического набора KUZN-CTR-CMAC.

А.3.1.1 Выполнение шифрования и сквозной имитозащиты

А.3.1.1.1 Вычисление производных ключей

Для вычисления производных ключей KENC и KMAC на вход алгоритму ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

ключ (ключ обмена)

Kmaster = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef16

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 454e434d4143\ 06\ 5b77468ea1236c71\ 56ee6779\ 43210001\ 0010\ 020016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 454e434d4143\ 06\ 5b77468ea1236c71\ 56ee6779\ 43210001\ 0010\ 020016 - при вычислении части ключа K3 IntToVec8(3) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 03\ 454e434d4143\ 06\ 5b77468ea1236c71\ 56ee6779\ 43210001\ 0010\ 020016
- при вычислении части ключа K4 IntToVec8(4) \|\| Label \|\| aL \|\| IVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 04\ 454e434d4143\ 06\ 5b77468ea1236c71\ 56ee6779\ 43210001\ 0010\ 020016

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || IVKDF || SN || Node || cL || oL =
= 01\
454e434d4143\
06\
5b77468ea1236c71\
56ee6779\
43210001\
0010\
020016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || IVKDF || SN || Node || cL || oL =
= 02\
454e434d4143\
06\
5b77468ea1236c71\
56ee6779\
43210001\
0010\
020016
- при вычислении части ключа K3
IntToVec8(3) || Label || aL || IVKDF || SN || Node || cL || oL =
= 03\
454e434d4143\
06\
5b77468ea1236c71\
56ee6779\
43210001\
0010\
020016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || IVKDF || SN || Node || cL || oL =
= 04\
454e434d4143\
06\
5b77468ea1236c71\
56ee6779\
43210001\
0010\
020016

Выходным значением алгоритма ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 является соответствующая часть ключа:

K1 = 8b6d117a33a1830e414878ac9b18738d16

K2 = 2b883274a8bda076e10198f7d21799e516

K3 = 06fc0e2199fd4b65570113427878b49d16

K4 = 9387d06a938509e31bccac292bd3e08e16

Итоговые значения ключей KENC и KMAC равны

KENC = 8b6d117a33a1830e414878ac9b18738d\ 2b883274a8bda076e10198f7d21799e516 KMAC = 06fc0e2199fd4b65570113427878b49d\ 9387d06a938509e31bccac292bd3e08e16

А.3.1.1.2 Шифрование и сквозная имитозащита

Для выполнения шифрования пакета на вход алгоритму ГОСТ 34.12-2018 («Кузнечик») в режиме гаммирования согласно ГОСТ 34.13-2018 подаются:

- ключ (ключ шифрования пакета):
KENC = 8b6d117a33a1830e414878ac9b18738d\
2b883274a8bda076e10198f7d21799e516
- открытый текст (IPlir-тело):
PayloadData || Mode || TLV || S || R2 || NextHeader =
= 0800769313e3008a5bad5a5d00000000\
ed210b00000000001011121314151617\
18191a1b1c1d1e1f2021222324252627\
28292a2b2c2d2e2f3031323334353637\
000116
- синхропосылка:
IVENC = 5b77468ea1236c7116

Выходным значением алгоритма ГОСТ 34.12-2018 («Кузнечик») в режиме гаммирования согласно ГОСТ 34.13-2018 является:

- шифртекст (зашифрованное IPlir-тело): EncryptedIPlirBody = = 717079c6e29742a2c52ca79dc8595053\ 56ee6f997c4a01301a168e3b85042f42\ 157e4fc18182768b27812ea3ce76d855\ 0129113c5c7580d08c9c7a1d0490f033\ 7d8b16

Для выполнения сквозной имитозащиты пакета на вход алгоритму ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

- ключ (ключ сквозной имитозащиты пакета)
KMAC = 06fc0e2199fd4b65570113427878b49d\
9387d06a938509e31bccac292bd3e08e16
- данные (IPlir-заголовок, зашифрованное IPlir-тело):
Version || CS || 0 || D || ExtID || ExtSN || DAR || R1 || KN || 016 || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody =
= 01024010\
1c2aadbc\
43210001\
43210002\
56ee6779\
5b77468ea1236c71\
717079c6e29742a2c52ca79dc8595053\
56ee6f997c4a01301a168e3b85042f42\
157e4fc18182768b27812ea3ce76d855\
0129113c5c7580d08c9c7a1d0490f033\
7d8b16

Выходным значением алгоритма ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 является:

имитовставка (сквозная):

IntegrityCheckValue = 8ee7840ee70f7e9d16

Тогда после шифрования и сквозной имитозащиты IPlir-сообщение принимает следующий вид:

M'3 = 0102c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6779\ 5b77468ea1236c71\ 717079c6e29742a2c52ca79dc8595053\ 56ee6f997c4a01301a168e3b85042f42\ 157e4fc18182768b27812ea3ce76d855\ 0129113c5c7580d08c9c7a1d0490f033\ 7d8b\ 8ee7840ee70f7e9d\ 00000000\ 0000000000000000\ 000000000000000016

А.3.1.2 Выполнение транзитной имитозащиты

Флаг наличия полей для транзитной имитозащиты в IPlir-сообщении M3 имеет значение T = 1, поэтому для сообщения требуется выполнение транзитной имитозащиты.

Пусть идентификатор транзитного узла равен

TransitIdentifier = 4321000316

и транзитная синхропосылка равна

TransitInitValue = 55735cb2bd57287b16

А.3.1.2.1 Вычисление производного ключа

Для вычисления производного ключа транзитной имитозащиты пакета KTMAC на вход алгоритму ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

ключ (ключ обмена)

K'master = ffeeddccbbaa99887766554433221100\ f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff16

данные

- при вычислении части ключа K1 IntToVec8(1) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 01\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6779\ 43210003\ 0010\ 010016 - при вычислении части ключа K2 IntToVec8(2) \|\| Label \|\| aL \|\| TIVKDF \|\| SN \|\| Node \|\| cL \|\| oL = = 02\ 0000544d4143\ 06\ 55735cb2bd57287b\ 56ee6779\ 43210003\ 0010\ 010016

K1 = ea643907e8d92fdc2f6f9dfa049b06cb16

K2 = 53699b79cca70358c019459544367f4e16

Итоговое значение ключа KTMAC равно

KTMAC = ea643907e8d92fdc2f6f9dfa049b06cb\ 53699b79cca70358c019459544367f4e16

А.3.1.2.2 Транзитная имитозащита

Для выполнения транзитной имитозащиты на вход алгоритму ГОСТ 34.12-2018 («Кузнечик») в режиме выработки имитовставки согласно ГОСТ 34.13-2018 подаются:

- ключ (ключ транзитной имитозащиты пакета)
KTMAC = ea643907e8d92fdc2f6f9dfa049b06cb\
53699b79cca70358c019459544367f4e16
- данные (IPlir-заголовок, зашифрованное IPlir-тело, значения полей IntegrityCheckValue, TransitIdentifier, TransitInitValue):
Version || CS || T || D || ExtID || ExtSN || DAR || R1 || KN || TKN || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody || IntegrityCheckValue || TransitIdentifier || TransitInitValue =
= 0102c011\
1c2aadbc\
43210001\
43210002\
56ee6779\
5b77468ea1236c71\
717079c6e29742a2c52ca79dc8595053\
56ee6f997c4a01301a168e3b85042f42\
157e4fc18182768b27812ea3ce76d855\
0129113c5c7580d08c9c7a1d0490f033\
7d8b\
8ee7840ee70f7e9d\
43210003\
55735cb2bd57287b16

имитовставка (транзитная):

TransitIntegrityCheckValue = 92897fb_e72bcf4cb16

Тогда после транзитной имитозащиты IPlir-сообщение принимает следующий вид:

M«3 = 0102c011\ 1c2aadbc\ 43210001\ 43210002\ 56ee6779\ 5b77468ea1236c71\ 717079c6e29742a2c52ca79dc8595053\ 56ee6f997c4a01301a168e3b85042f42\ 157e4fc18182768b27812ea3ce76d855\ 0129113c5c7580d08c9c7a1d0490f033\ 7d8b\ 8ee7840ee70f7e9d\ 43210003\ 55735cb2bd57287b\ 92897fbe72bcf4cb16»

А.3.2 Сообщение M4

Пусть IPlir-сообщение M4, подлежащее криптографической защите, имеет следующий вид:

M4 = 0102f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677b\ 5b77468ea1236c71\ 0800769313e3008a5bad5a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f3031323334353637\ 0001\ 0000000000000000\ 0000000000000000\ 0000000000000000\ 000000000000000016

Тогда поля IPlir-сообщения M4 содержат следующие значения:

Version = 0116

CS = 0216

T = 1

D = 1

ExtID = 1

ExtSN = 1

DAR = 0

R1 = 000

KN = 116

TKN = 116

Timestamp = 1c2aadbc16

SourceIdentifier = 432100000000000116

DestinationIdentifier = 432100000000000216

SequenceNumber = 0000000056ee677_b16

InitValue = 5b77468ea1236_c7116

PayloadData = 0800769313e3008a5bad5a5d00000000\ ed210b00000000001011121314151617\ 18191a1b1c1d1e1f2021222324252627\ 28292a2b2c2d2e2f303132333435363716

Mode = 00

TLV = 0

S = 0

R2 = 016

NextHeader = 0116

IntegrityCheckValue = 000000000000000016

TransitIdentifier = 000000000000000016

TransitInitValue = 000000000000000016

TransitIntegrityCheckValue = 000000000000000016

Идентификатор криптонабора в IPlir-сообщении M4 имеет значение CS = 2, поэтому криптографическая защита сообщения выполняется согласно описанию криптографического набора KUZN-CTR-CMAC.

А.3.2.1 Выполнение шифрования и сквозной имитозащиты

А.3.2.1.1 Вычисление производных ключей

ключ (ключ обмена)

Kmaster = 8899aabbccddeeff0011223344556677\ fedcba98765432100123456789abcdef₁₆

данные

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || IVKDF || SN || Node || cL || oL =
= 01\
454e434d4143\
06\
5b77468ea1236c71\
0000000056ee677b\
4321000000000001\
0018\
020016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || IVKDF || SN || Node || cL || oL =
= 02\
454e434d4143\
06\
5b77468ea1236c71\
0000000056ee677b\
4321000000000001\
0018\
020016
- при вычислении части ключа K3
IntToVec8(3) || Label || aL || IVKDF || SN || Node || cL || oL =
= 03\
454e434d4143\
06\
5b77468ea1236c71\
0000000056ee677b\
4321000000000001\
0018\
020016

- при вычислении части ключа K4
IntToVec8(4) || Label || aL || IVKDF || SN || Node || cL || oL =
= 04\
454e434d4143\
06\
5b77468ea1236c71\
0000000056ee677b\
4321000000000001\
0018\
020016

K1 = b04a700c48694da819279608b3188f7316

K2 = fb18e7641fe9a356b68451a965917a8016

K3 = 23a6ca4df25b92fcb5fa7b4678fa53e516

K4 = d139426512d74b65969e8e11167cad4316

Итоговые значения ключей KENC и KMAC равны

KENC = b04a700c48694da819279608b3188f73\ f_b18e7641fe9a356b68451a965917a8016 KMAC = 23a6ca4df25b92fcb5fa7b4678fa53e5\ d139426512d74b65969e8e11167cad4316

А.3.2.1.2 Шифрование и сквозная имитозащита

- ключ (ключ шифрования пакета)
KENC = b04a700c48694da819279608b3188f73\
fb_18e7641fe9a356b68451a965917a8016
- открытый текст (IPlir-тело):
PayloadData || Mode || TLV || S || R2 || NextHeader =
= 0800769313e3008a5bad5a5d00000000\
ed210b00000000001011121314151617\
18191a1b_1c1d1e1f2021222324252627\
28292a2b2c2d2e2f3031323334353637\
000116
- синхропосылка:
IVENC = 5b77468ea1236c7116

Выходным значением алгоритма ГОСТ 34.12-2018 («Кузнечик») в режиме гаммирования согласно ГОСТ 34.13-2018 является:

- шифртекст (зашифрованное IPlir-тело): EncryptedIPlirBody = = ₉₀₆₈₃₉bcbceed3a5cc6017a7c0ba1940\ 30c4adc9cb47bf425b37e608b_50e93ed\ a85d4d8acf89c3403bb26a6b71fedc27\ 9e19ffa446d9c4aa9b2901696c3e3e48\ eeb816

- ключ (ключ сквозной имитозащиты пакета)
KMAC = 23a6ca4df25b92fcb5fa7b4678fa53e5\
d139426512d74b65969e8e11167cad4316
- данные (IPlir-заголовок, зашифрованное IPlir-тело):
Version || CS || 0 || D || ExtID || ExtSN || DAR || R1 || KN || 016 || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody =
= 01027010\
1c2aadbc\
4321000000000001\
4321000000000002\
0000000056ee677b\
5b77468ea1236c71\
906839bcbceed3a5cc6017a7c0ba1940\
30c4adc9cb47bf425b37e608b50e93ed\
a85d4d8acf89c3403bb26a6b71fedc27\
9e19ffa446d9c4aa9b2901696c3e3e48\
eeb816

имитовставка (сквозная):

IntegrityCheckValue = 57890a4ce449147716

Тогда после шифрования и сквозной имитозащиты IPlir-сообщение принимает следующий вид:

M'4 = 0102f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677b\ 5b77468ea1236c71\ 906839bcbceed3a5cc6017a7c0ba1940\ 30c4adc9cb47bf425b37e608b50e93ed\ a85d4d8acf89c3403bb26a6b71fedc27\ 9e19ffa446d9c4aa9b2901696c3e3e48\ eeb8\ 57890a4ce4491477\ 0000000000000000\ 0000000000000000\ 000000000000000016

А.3.2.2 Выполнение транзитной имитозащиты

Флаг наличия полей для транзитной имитозащиты в IPlir-сообщении M4 имеет значение T = 1, поэтому для сообщения требуется выполнение транзитной имитозащиты.

Пусть идентификатор транзитного узла равен

TransitIdentifier = 432100000000000316

и транзитная синхропосылка равна

TransitInitValue = 55735cb2bd57287b16

А.3.2.2.1 Вычисление производного ключа

ключ (ключ обмена)

K'master = ffeeddccbbaa99887766554433221100\ f_0f1f2f3f4f5f6f7f8f9fafbfcfdfeff₁₆

данные

- при вычислении части ключа K1
IntToVec8(1) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 01\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677b\
4321000000000003\
0018\
010016
- при вычислении части ключа K2
IntToVec8(2) || Label || aL || TIVKDF || SN || Node || cL || oL =
= 02\
0000544d4143\
06\
55735cb2bd57287b\
0000000056ee677b\
4321000000000003\
0018\
010016

K1 = f5caa07667e24f19485fe515767a5f9516

K2 = 02a3fdd462a59331dee778fe9d80e0e116

Итоговое значение ключа KTMAC равно

KTMAC = f5caa07667e24f19485fe515767a5f95\ 0_2a3fdd462a59331dee778fe9d80e0e116

А.3.2.2.2 Транзитная имитозащита

- ключ (ключ транзитной имитозащиты пакета)
KTMAC = _f5caa07667e24f19485fe515767a5f95\
02a3fdd462a59331dee778fe9d80e0e116
- данные (IPlir-заголовок, зашифрованное IPlir-тело, значения полей IntegrityCheckValue, TransitIdentifier, TransitInitValue):
Version || CS || T || D || ExtID || ExtSN || DAR || R1 || KN || TKN || Timestamp || SourceIdentifier || DestinationIdentifier || SequenceNumber || InitValue || EncryptedIPlirBody || IntegrityCheckValue || TransitIdentifier || TransitInitValue =
= 0102f011\
1c2aadbc\
4321000000000001\
4321000000000002\
0000000056ee677b\
5b77468ea1236c71\
906839bcbceed3a5cc6017a7c0ba1940\
30c4adc9cb47bf42_5b37e608b50e93ed\
a85d4d8acf89_c3403bb26a6b71fedc27\
9e19ffa446d9c4aa9b2901696c3e3e48\
eeb8\
57890a4ce4491477\
4321000000000003\
55735cb2bd57287b16

имитовставка (транзитная):

TransitIntegrityCheckValue = d4054f_6db5911_79e16

Тогда после транзитной имитозащиты IPlir-сообщение принимает следующий вид:

M«4 = 0102f011\ 1c2aadbc\ 4321000000000001\ 4321000000000002\ 0000000056ee677b\ 5b77468ea1236c71\ 906839bcbceed3a5cc6017a7_c0ba1940\ 30c4adc9cb47bf42_5b37e608b50e93ed\ a85d4d8acf89c340_3bb26a6b71fedc27\ 9e19ffa446d9c4aa_9b2901696c3e3e48\ eeb8\ 57890a4ce4491477\ 4321000000000003\ 55735cb2bd57287b\ d4054f6db591179e₁₆»

УДК 681.3.06:006.354	ОКС 35.040
Ключевые слова: криптографические протоколы, протокол сетевого уровня, шифрование, ключ, маршрутизация, VPN, IP-пакет, туннель