Библиотека
Скачать PDF

Р 1323565.1.035-2021. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе защиты информации ESP

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

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

Примечание

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

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

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

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

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

ИСПОЛЬЗОВАНИЕ РОССИЙСКИХ КРИПТОГРАФИЧЕСКИХ АЛГОРИТМОВ В ПРОТОКОЛЕ ЗАЩИТЫ ИНФОРМАЦИИ ESP

Information technology. Cryptographic data security. Using Russian cryptographic algorithms in data security protocol ESP

Р 1323565.1.035-2021

ОКС 35.040

Дата введения 1 июня 2021 года

Предисловие

1 РАЗРАБОТАНЫ Акционерным обществом «ЭЛВИС-ПЛЮС» (АО «ЭЛВИС-ПЛЮС») при участии специалистов Общества с ограниченной ответственностью «Фактор-ТС» (ООО «Фактор-ТС»), Общества с ограниченной ответственностью «КРИПТО-ПРО» (ООО «КРИПТО-ПРО») и Общества с ограниченной ответственностью «С-Терра СиЭсПи» (ООО «С-Терра СиЭсПи»)

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

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

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

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

Введение

Настоящие рекомендации содержат описание протокола защиты информации ESP (Encapsulating Security Payload) при использовании в нем российских криптографических алгоритмов, определенных в ГОСТ Р 34.12-2015, Р 50.1.113-2016 и Р 1323565.1.026-2019.

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

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

Протокол ESP (Encapsulating Security Payload) входит в семейство протоколов IPsec и предназначен для защиты информации в сетях TCP/IP. Данные рекомендации описывают применение ESP при использовании в нем криптографических алгоритмов, определяемых документами национальной системы стандартизации Российской Федерации. Протокол позволяет обеспечить такие свойства безопасности, как конфиденциальность и имитозащита передаваемых данных, а также защита от атак повторной передачи пакетов. Протокол может применяться при защите информации, не содержащей сведений, составляющих государственную тайну, в частности, для построения виртуальных частных сетей (Virtual Private Network).

Настоящие рекомендации базируются на [1] и расширяют их в плане применения российских криптографических алгоритмов.

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

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

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

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

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

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

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

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

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

3.1.1 трансформ (transform): Набор правил, в соответствии с которыми происходит обработка пакета в протоколе ESP; трансформ характеризуется типом, определяющим вид обработки (например, трансформ типа ENCR определяет алгоритм шифрования, режим его использования, способ формирования вектора инициализации и т.д.) и уникальным идентификатором, используемым в протоколе IKEv2 при согласовании трансформов в процессе создания защищенного соединения.

3.1.2 защищенное соединение (Security Association; SA): Логическое объединение используемых трансформов, а также сеансовых ключей, позволяющее осуществлять защиту трафика.

3.1.3 селектор трафика (traffic selector): Совокупность сетевых характеристик, позволяющих выделить некоторое подмножество IP-пакетов; в общем случае является списком элементов, каждый из которых включает диапазон IP-адресов назначения и источника, сетевой протокол (или «любой» протокол) и диапазон портов назначения и источника (для протоколов TCP и UDP).

3.1.4 инкапсуляция (encapsulation): Упаковка сообщений протокола в сообщения другого протокола.

3.1.5 декапсуляция (decapsulation): Извлечение сообщений протокола из сообщений другого протокола.

3.1.6 соль (salt): Непредугадываемая величина, используемая при построении одноразового вектора для трансформов шифрования, описываемых в настоящих рекомендациях.

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

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

Bs - множество байтовых строк длины s, s >= 0. Строка b = b1, ..., bs) принадлежит множеству Bs, если b_{1},...,b_{s} \in {0,...,255} . При s = 0 множество Bs состоит из единственной пустой строки длиной 0;
B* - множество всех байтовых строк произвольной конечной длины;
|b| - длина байтовой строки b \in B^{*} (если b — пустая строка, то |b| = 0);
b[i..j] - строка b[i..j] = (b_{i},b_{i + 1},...,b_{j}) \in B_{j - i + 1} , где 1 <= i <= j <= s и b = (b_{1},...,b_{s}) \in B_{s} ;
STRs(r) - строка STR_{s}(r) = (b_{1},...,b_{s}) \in B_{s} , соответствующая числу r = 256s-1·b1 + ... + 256 x bs-1 + bs <= 256s — 1;
формула - конкатенация двух байтовых строк; для двух строк a = (a_{1},...,a_{s1}) \in B_{s1} , b = (b_{1},...,b_{s2}) \in B_{s2} их конкатенацией a | b называется строка c = (a_{1},...,a_{s1},b_{1},...,b_{s2}) \in B_{s1 + s2} ;
& - операция побитовой конъюнкции (побитовое «И»);
ENCR - тип трансформа, основанного на алгоритме шифрования или AEAD-алгоритме (см. 0); как правило, трансформ типа ENCR обеспечивает свойство конфиденциальности, однако если он основывается на AEAD-алгоритме, то обеспечивает либо конфиденциальность и имитозащиту, либо только имитозащиту (при вырожденном шифровании);
INTEG - тип трансформа, основанного на алгоритме имитозащиты, обеспечивает свойство имитозащиты; использование данного типа трансформа в протоколе ESP является опциональным, а в случае, если трансформ типа ENCR базируется на AEAD-алгоритме, то трансформ типа INTEG не должен использоваться;
ESN - тип трансформа, указывающего на использование расширенных номеров пакетов.

3.3 Сокращения

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

AAD - дополнительные имитозащищаемые данные (Additional Authenticated Data);
AEAD - шифрование с имитозащитой и ассоциированными данными (Authenticated Encryption with Associated Data);
ESN - расширенный порядковый номер пакета (Extended Sequence Number);
ESP - протокол защиты информации в IPsec (Encapsulating Security Payload);
ICV - имитовставка (Integrity Check Value);
IKEv2 - протокол обмена ключами в сети Интернет версии 2 (Internet Key Exchange version 2);
IPsec - семейство протоколов защиты информации на уровне IP-пакетов (IP Security);
IV - вектор инициализации (Initialization Vector);
NAT - транслятор сетевых адресов (Network Address Translator);
SA - защищенное соединение (Security Association);
SAD - список активных защищенных соединений (Security Association Database);
SN - порядковый номер пакета (Sequence Number);
SPD - политика безопасности (Security Policy Database);
SPI - идентификатор защищенного соединения (Security Parameter Index);
TFC - конфиденциальность потока данных (Traffic Flow Confidentiality).

Примечания

1 Если это не оговаривается отдельно, в настоящих рекомендациях предполагается, что при передаче по каналу связи все числа представляются в виде строк в формате big-endian (сетевой порядок байт).

2 В настоящих рекомендациях предполагается, что все приведенные строковые константы представляются в кодировке ASCII.

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

4 Краткое описание протокола ESP

Семейство протоколов IPsec предназначено для обеспечения безопасной передачи IP-пакетов между узлами IP-сети. Оно включает в себя два основных протокола:

  • протокол ESP, обеспечивающий непосредственную защиту IP-пакетов;
  • протокол IKEv2, обеспечивающий обмен ключами, взаимную аутентификацию сторон и создание/удаление защищенных соединений; создание защищенного соединения ESP включает в себя согласование его параметров (включая используемые трансформы), выбор SPI и вычисление сеансовых ключей.

Примечание - Протокол IKEv2 используется только для создания защищенных соединений между двумя участниками (unicast).

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

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

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

4.1 Формат ESP-пакета

ESP-пакет состоит из набора полей, содержащих полезную нагрузку (исходный пакет) в защищенном виде, а также служебную информацию для корректного восстановления исходного пакета на приемной стороне. ESP-пакет формируется из исходного IP-пакета в соответствии с параметрами конкретного защищенного соединения ESP (ESP SA).

Формат ESP-пакета приведен на рисунке 1. Заголовок протокола, непосредственно предшествующего заголовку ESP в IP-пакете (например, IPv4, IPv6 и т.п.), должен содержать значение 50 в поле, идентифицирующем следующий протокол (то есть ESP).

4.1 Формат ESP-пакета

Рисунок 1 — Формат ESP-пакета

В состав ESP-пакета входят следующие поля:

Security Parameter Index - идентификатор защищенного соединения (4 байта), см. 4.1.1;
Sequence Number - порядковый номер пакета, представленный в сетевом порядке байт (4 байта), см. 4.1.2;
Initialization Vector - вектор инициализации (размер поля зависит от используемого трансформа типа ENCR и для установленного защищенного соединения является фиксированным);
Payload Data - поле данных переменной длины, может быть разбито на две части:
- защищаемые данные;
- TFC Padding (Traffic Flow Confidentiality Padding) — опциональное заполнение для сокрытия истинной длины передаваемых данных (см. 4.1.3);
Padding - заполнение (опциональное поле переменной длины: от 0 до 255 байт); должно иметь такую длину, чтобы суммарный размер полей Payload Data, Padding, Pad Length и Next Header был кратен размеру блока используемого трансформа ENCR и одновременно кратен четырем байтам;
Pad Length - длина поля Padding (1 байт); посылающей стороне рекомендуется выбирать минимальное значение, удовлетворяющее требованию длины Padding (см. описание поля Padding), но получатель должен принимать любое значение, которое обеспечивает надлежащее выравнивание;
Next Header - идентификатор протокола, данные которого содержатся в поле Payload Data (1 байт);
Integrity Check Value - имитовставка (размер поля зависит от используемого трансформа, обеспечивающего имитозащиту, и для установленного защищенного соединения является фиксированным).

Поля ESP-пакета (см. рисунок 1) сгруппированы в четыре группы: заголовок (ESP Header), тело (ESP Payload), завершающая часть (ESP Trailer) и имитовставка (ESP ICV). Если используемый трансформ типа ENCR обеспечивает конфиденциальность, то поля Payload Data, Padding, Pad Length и Next Header передаются в зашифрованном виде и в таком виде совокупно обозначаются как ESP Data.

Математически ESP-пакет представляется следующим образом:

ESP Packet = = ESP Header | ESP Payload | ESP Trailer | ESP ICV. (1)

Примечание - Далее считается, что строки ESP Header, ..., ESP ICV являются байтовыми представлениями значений групп полей ESP Header, ..., ESP ICV соответственно. Строки SPI, SN, ..., ICV являются байтовыми представлениями значений полей SPI, SN, ..., ICV соответственно.

4.1.1 Идентификатор защищенного соединения (SPI)

Идентификатор защищенного соединения SPI служит уникальным идентификатором SA на стороне получателя ESP-пакета. Поле содержит произвольное 32-битное значение. Значения SPI в диапазоне 1 — 255 (при представлении этого поля в виде 32-битного числа в сетевом порядке байт) зарезервированы для специальных целей и не должны использоваться в IPsec. Кроме того, значение 0 является запрещенным для SPI и не должно использоваться.

Значение SPI выбирается на этапе создания SA таким образом, чтобы получатель ESP-пакета мог однозначно определить, к какому защищенному соединению относится полученный пакет. Рекомендуется, чтобы значения SPI выбирались непредугадываемо для внешнего наблюдателя. При создании пары ESP SA протоколом IKEv2 каждый из участников выбирает SPI для того защищенного соединения, в котором он будет являться получателем пакетов, и делает это таким образом, чтобы при получении ESP-пакета он всегда мог однозначно найти ESP SA по SPI.

4.1.2 Порядковый номер пакета (SN)

Порядковый номер пакета (Sequence Number) представляет собой беззнаковое 32-битное число в сетевом порядке байт. Первый пакет, посланный по вновь созданному защищенному соединению SA, должен иметь номер 1, каждый последующий пакет — на 1 (единицу) больше. Порядковый номер пакета не должен переполняться, то есть если не согласован расширенный порядковый номер, то после отсылки (232 — 1) пакетов данное защищенное соединение не должно далее использоваться.

4.1.2.1 Расширенный порядковый номер пакета (ESN)

При необходимости передачи в рамках одного защищенного соединения более (232 — 1) пакетов может быть использован расширенный порядковый номер пакета (Extended Sequence Number). Использование расширенного номера согласовывается абонентами на этапе создания SA. Расширенный порядковый номер представляет собой 64-битное беззнаковое число. Только младшие 32 бита передаются в пакете (в поле Sequence Number), старшие 32 бита хранятся абонентами как часть состояния SA, при этом они включаются в вычисление имитовставки. При использовании расширенного порядкового номера после отсылки (264 — 1) пакетов данное защищенное соединение не должно далее использоваться.

4.1.2.2 Обработка порядкового номера пакета на приемной стороне

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

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

В процессе передачи по сети пакеты могут перемешиваться, исчезать и множиться. Для корректной обработки порядкового номера пакета приемная сторона должна поддерживать «скользящее окно», содержащее информацию о порядковых номерах последних успешно обработанных пакетов. Минимальный размер окна — 32. Правая граница окна отражает самое большое значение порядкового номера пакета из полученных и успешно обработанных ESP-пакетов. Левая граница окна определяется таким образом: правая граница окна минус размер окна плюс один. При создании SA окно инициализируется таким образом, что левая граница устанавливается равной единице, правая — размеру окна, а окно заполняется элементами, указывающими, что соответствующий пакет еще не обработан. Пакеты с номерами меньшими, чем значение левой границы окна, отбрасываются. Пакеты с номерами, попадающими в границы окна, отбрасываются, если в соответствующем элементе окна стоит отметка, что такой пакет уже был обработан, в противном случае — обрабатываются. После успешной обработки такого пакета соответствующий элемент окна помечается как обработанный. Пакеты с номерами большими, чем значение правой границы окна, обрабатываются. В случае если они обработаны успешно, правая граница окна устанавливается равной номеру полученного пакета, соответственно сдвигается и левая граница.

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

4.1.2.3 Особенности обработки расширенного порядкового номера пакета на приемной стороне

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

Wsz - размер скользящего окна в виде 32-битного числа (< 231),
R - правая граница окна (64 бита),
Rl - младшие 32 бита R, то есть Rl = R & (232 — 1),
Rh - старшие 32 бита R, то есть R_{h} = (\frac{R}{2^{32}})\&(2^{32} - 1) ,
L - левая граница окна (64 бита),
Ll - младшие 32 бита L, то есть Ll = L & (232 — 1),
Lh - старшие 32 бита L, то есть L_{h} = (\frac{L}{2^{32}})\&(2^{32} - 1) ,
S - расширенный номер входящего пакета (64 бита),
Sl - младшие 32 бита S (из поля Sequence Number входящего пакета),
Sh - старшие 32 бита S (восстанавливаются на приемной стороне).

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

(1) Rl >= Wsz — 1,

(2) Rl < Wsz — 1.

Для ситуации (1): если Sl >= Ll, где Ll = Rl — Wsz + 1, то Sh = Rh, иначе Sh = Rh + 1.

Для ситуации (2): если Sl >= Ll, где Ll = Rl — Wsz + 1, то Sh = Rh — 1, иначе Sh = Rh.

Данный алгоритм позволяет восстановить расширенный номер пакета S (путем комбинации Sl из пакета и полученного Sh), после чего должен использоваться алгоритм, описанный в 4.1.2.2 с поправкой на то, что все величины являются 64-битными. Приложение В содержит формализованное описание алгоритма обработки расширенного номера пакета на приемной стороне.

Примечания

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

2 Описанный алгоритм восстановления старших 32 бита расширенного номера пакета обладает следующей особенностью: любой входящий пакет, не попадающий в окно, считается новым, а не отставшим пакетом. Иными словами, пакет, отправленный с расширенным номером S и задержавшийся в канале настолько, что в момент его получения на приемной стороне справедливо условие R — S > Wsz, в результате применения описанного алгоритма будет воспринят на приемной стороне как пакет с расширенным номером S' = S + 232. В результате такой пакет будет отброшен не на этапе проверки на повторный пакет, а на этапе проверки имитовставки.

3 Описанный алгоритм восстановления старших 32 бита расширенного номера пакета не будет работать в ситуации, когда происходит потеря 232 и более последовательных пакетов. Хотя такое событие является маловероятным, если оно все же произойдет, то все последующие входящие пакеты данного защищенного соединения будут отбрасываться из-за неверного восстановления Sh, и, соответственно, нарушения имитозащиты. Если приемная сторона обнаружит, что в течение определенного времени все входящие пакеты с ESN были отброшены по причине нарушения имитозащиты, то она может попытаться провести ресинхронизацию следующим образом: берется произвольный отброшенный входной пакет, для него восстанавливается Sh описанным выше способом и далее инкрементируется в цикле с попыткой каждый раз проверить имитовставку пакета, используя очередное значение Sh. Количество итераций цикла должно быть ограничено. После исчерпания итераций цикла при отсутствии положительного результата можно повторить всю процедуру, используя другой отброшенный пакет. Если в какой-то момент имитовставка пакета успешно проверится, то параметры окна необходимо обновить, используя полученное значение S. Кроме того, если в процессе выполнения ресинхронизации придет пакет, который будет успешно обработан, процесс ресинхронизации следует прекратить.

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

4.1.3 Дополнительное заполнение (TFC Padding)

В протоколе ESP может использоваться дополнительное заполнение, называемое TFC Padding (Traffic Flow Confidentiality Padding) и входящее в состав поля Payload Data. Оно применяется с целью сокрытия истинной длины передаваемых данных для усложнения задачи анализа сетевого трафика. Использование TFC Padding является опциональным и согласуется на этапе создания ESP SA. Опция не должна использоваться, если она не была согласована.

Технически TFC Padding осуществляется путем увеличения размеров поля Payload Data за счет добавления к нему на передающей стороне до шифрования произвольных данных таким образом, чтобы по результирующей длине пакета невозможно было определить длину передаваемых данных (как правило, все пакеты формируются одинаковой длины). На приемной стороне после расшифрования пакета эти данные отбрасываются. Содержимое добавляемых данных не регламентируется.

Поскольку длина TFC Padding в ESP-пакете не передается, то принимающая сторона должна определить, где заканчиваются исходные данные и начинается заполнение, которое надо отбросить. Это можно сделать, только если в самих исходных данных в явном виде присутствует их длина. В частности, TFC Padding можно использовать:

  • в туннельном режиме;
  • в транспортном режиме при условии, что транспортным протоколом является UDP или ICMP (или другой протокол, явно содержащий длину передаваемых данных).

Использование заполнения TFC Padding является опциональным в протоколе ESP. Другим опциональным способом достижения свойства TFC является периодическая отсылка «пустых» (dummy) пакетов, не несущих полезной информации, но, с точки зрения стороннего наблюдателя, неотличимых от других ESP-пакетов. Такие пакеты должны иметь корректные значения всех полей, кроме поля Payload Data, которое может содержать произвольные данные. Поле Next Header для таких пакетов должно иметь значение 59. На приемной стороне ESP-пакеты, которые после расшифрования содержат значение 59 в поле Next Header, должны отбрасываться без дальнейшей обработки.

4.2 Режимы протокола ESP

Протокол ESP может быть использован в двух режимах — туннельном и транспортном. Конкретный режим является параметром ESP SA.

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

В туннельном режиме ESP защищает весь исходный пакет, включая его заголовок. Для этого исходный (защищаемый) IP-пакет целиком помещается в поле Payload Data ESP-пакета вместе со своим IP-заголовком (см. рисунок 2). После этого формируется новый IP-пакет с новым IP-заголовком, включающим новые значения IP-адресов, обычно другие, чем в исходном IP-заголовке. Полезной нагрузкой нового IP-пакета становится ESP-пакет. В туннельном режиме поле Next Header в ESP-пакете должно иметь значение 4 для протокола IPv4 или значение 41 для протокола IPv6, указывая, что полезной нагрузкой ESP-пакета является IP-пакет. На приемной стороне после обработки ESP-пакета внешний IP-заголовок отбрасывается.

4.2 Режимы протокола ESP

Рисунок 2 — Туннельный режим (исходный и защищенный пакеты)

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

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

В транспортном режиме ESP защищает только полезную нагрузку исходного IP-пакета, то есть только она помещается в поле Payload Data протокола ESP (см. рисунок 3). При этом в результирующем пакете используется исходный IP-заголовок с исходными адресами, но со скорректированной длиной, с указанием на ESP как на следующий протокол и с пересчитанной контрольной суммой. В этом случае поле Next Header в ESP-пакете должно иметь значение, скопированное из соответствующего поля исходного IP-заголовка. В транспортном режиме протокол ESP защищает только данные исходного пакета, но не его IP-заголовок.

4.2 Режимы протокола ESP

Рисунок 3 — Транспортный режим (исходный и защищенный пакеты)

При использовании транспортного режима ESP с протоколом IPv6 расширенные заголовки IPv6 типа «hop-by-hop», «routing» и «fragmentation» не должны защищаться протоколом ESP (то есть должны размещаться в IP-пакете до заголовка ESP). Расширенные заголовки типа «destination options» в зависимости от желаемой семантики могут как защищаться протоколом ESP (то есть помещаться внутри ESP-пакета), так и нет. В общем случае предпочтительно помещать расширенные заголовки типа «destination options» в ESP-пакет, обеспечивая тем самым их защиту.

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

4.3 Дополнительное инкапсулирование ESP-пакетов

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

4.3.1 Инкапсулирование ESP-пакетов в UDP

При инкапсулировании ESP-пакета в UDP заголовок UDP помещается между внешним IP-заголовком и заголовком ESP. При этом поле в IP-заголовке, идентифицирующее следующий протокол, имеет значение 17 (UDP), а порт назначения UDP заголовка должен быть равен 4500. При этом ESP-пакеты приходят на тот же порт, что и IKEv2-пакеты. Принимающая сторона может различить их, проанализировав первые 4 байта: IKEv2-пакеты, приходящие на порт 4500, всегда начинаются с четырех байт нулей, в то время как первые 4 байта ESP-заголовка содержат SPI, значение которого никогда не равно нулю. Заголовок UDP никак не защищен и отбрасывается на принимающей стороне после успешной обработки полученного пакета. На рисунке 4 показан формат ESP при инкапсулировании его в UDP.

4.3 Дополнительное инкапсулирование ESP-пакетов

Рисунок 4 — Инкапсулирование ESP в UDP в туннельном и транспортном режимах

При использовании транспортного режима совместно с UDP-инкапсуляцией и при наличии NAT на пути следования пакета в пришедшем пакете значения IP-адресов будут отличаться от исходных вследствие трансляции сетевых адресов. Поскольку поле контрольной суммы в транспортных заголовках TCP и UDP включает в себя значения сетевых адресов из IP-заголовка, то после успешной декапсуляции на приемной стороне необходимо пересчитать значение контрольной суммы транспортных заголовков таким образом, чтобы она была корректной. Исходные значения IP-адресов для пересчета контрольной суммы приемная сторона получает в момент создания SA посредством протокола IKEv2.

Инкапсулирование ESP в UDP согласовывается абонентами посредством протокола IKEv2 при создании ESP SA.

4.3.2 Инкапсулирование ESP-пакетов в TCP

Инкапсулирование ESP-пакетов в TCP может быть использовано как альтернатива инкапсулированию в UDP в тех случаях, когда протокол UDP заблокирован на промежуточных межсетевых экранах. По сравнению с инкапсулированием в UDP инкапсулирование в TCP может иметь ряд побочных эффектов; в частности, может наблюдаться существенное снижение скорости передачи данных в тех случаях, когда защищаемым протоколом тоже является TCP. В связи с этим инкапсулирование ESP в TCP должно быть использовано только в тех случаях, когда использование UDP является невозможным. Инкапсулирование ESP в TCP согласовывается абонентами посредством протокола IKEv2 при создании ESP SA.

Инкапсулирование ESP в TCP выполняется аналогично инкапсулированию в UDP: заголовок TCP помещается между внешним IP-заголовком и заголовком ESP. При этом поле в IP-заголовке, идентифицирующее следующий протокол, имеет значение 6 (TCP), а порт назначения TCP заголовка должен быть равен 4500. Заметим, что в этом случае ESP-пакеты приходят на тот же порт, что и IKEv2-пакеты. Принимающая сторона может различить их, проанализировав первые 4 байта: IKEv2-пакеты, приходящие на порт 4500, всегда начинаются с четырех нулевых байт, в то время как первые 4 байта ESP-заголовка содержат SPI, значение которого никогда не равно нулю. Заголовок TCP никак не защищен и отбрасывается на принимающей стороне после успешной обработки полученного пакета. Для разделения отдельных ESP-пакетов и IKEv2-пакетов в потоке TCP перед каждым пакетом добавляется поле LEN размером в 2 байта, которое содержит в сетевом порядке байт длину следующего за ним ESP-пакета или IKEv2-пакета плюс размер самого поля (2 байта). На рисунке 5 показан формат ESP при инкапсулировании его в TCP.

4.3 Дополнительное инкапсулирование ESP-пакетов

Рисунок 5 — Инкапсулирование ESP в TCP в туннельном и транспортном режимах

Примечание — На рисунках 2 - 5 для упрощения показано, что поле IV явно включается в данные, защищаемые имитовставкой. В реальности это зависит от используемого трансформа. В частности, для AEAD-трансформов, реализующих шифрование, поле IV не включается в данные, защищаемые имитовставкой, его защита от искажения осуществляется неявным образом. Для AEAD-трансформов, реализующих только имитозащиту, поле IV явно включается в данные, защищаемые имитовставкой. См. также 6.2.8.

Как и в случае с инкапсулированием в UDP, при использовании TCP-инкапсуляции в транспортном режиме на приемной стороне необходимо корректировать контрольную сумму в заголовках TCP и UDP, подробнее см. 5.4.

5 Обработка пакетов

5.1 Политика безопасности

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

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

Такой список называется Security Policy Database (SPD).

5.2 Защищенное соединение (SA)

Каждый пакет обрабатывается в некотором контексте, называемом защищенным соединением (Security Association, SA). В данном документе рассматриваются только защищенные соединения, связанные с протоколом ESP — ESP SA. Защищенные соединения создаются и удаляются динамически протоколом согласования ключей и содержат такие данные, как:

  • идентификатор защищенного соединения (SPI);
  • используемые трансформы: - трансформ шифрования или AEAD-алгоритма (типа ENCR); - опционально трансформ имитозащиты (типа INTEG);

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому трансформ типа INTEG не используется.

  -  <a id="p100271"></a>трансформ  типа   ESN,   определяющий  использование  расширенного

порядкового номера пакета (принимает значение ESN, если использование ESN согласовано и noESN в противном случае);

  • ключ для трансформа шифрования (Kencr);
  • опционально ключ для трансформа имитозащиты;

Примечание - В данном документе описывается использование только AEAD-трансформов шифрования, поэтому ключ для трансформа имитозащиты отсутствует.

  • селектор трафика (определяет, какой трафик должен защищаться данным защищенным соединением);
  • порядковый номер следующего исходящего пакета (SN или ESN);
  • скользящее окно номеров пакетов (на приемной стороне);
  • режим инкапсуляции (туннельный/транспортный);
  • туннельный IP-адрес (для туннельного режима);
  • иные параметры, не относящиеся к безопасности (например, уровень журналирования и т.п.).

Протокол ESP является однонаправленным, то есть одно защищенное соединение обеспечивает защиту трафика, идущего только в одном направлении. Для защиты двунаправленного трафика (типичного в сети Интернет) абонентам необходимо создать два защищенных соединения. Протокол IKEv2 всегда создает ESP SA попарно, вне зависимости от того, будет ли защищаться однонаправленный трафик или двунаправленный.

Защищенное соединение идентифицируется значением SPI (Security Parameter Index) в заголовке ESP (см. 4.1.1).

Каждая из сторон хранит динамическую таблицу активных защищенных соединений, называемую SAD (Security Association Database).

5.3 Обработка исходящего пакета

На вход протокола ESP поступает IP-пакет. Правила SPD просматриваются от первого к последнему с целью поиска такого из них, селектор трафика которого включает сетевые параметры пакета. Если правило не найдено или содержит действие «отбросить», пакет уничтожается. Если найденное правило содержит действие «пропустить», пакет пропускается.

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

Примечание - В данном документе предполагается использование протокола управления ключами IKEv2 для создания однонаправленных (unicast) ESP SA.

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

а) осуществляется инкапсуляция пакета в соответствии с указанным в ESP SA режимом; при этом происходит формирование и добавление необходимых заголовков — ESP и, опционально, нового IP-заголовка;

б) данные пакета дополняются опциональным (TFC Padding) и обязательным (Padding) заполнениями, заполняются поля Pad Length и Next Header;

в) вычисляется номер (или расширенный номер) для данного пакета (путем увеличения на единицу его значения по отношению к номеру предыдущего отправленного пакета);

г) заполняются поля ESP-заголовка SPI и SN;

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

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

ж) пакет зашифровывается и имитозащищается с использованием трансформа ENCR, указанного в ESP SA, ключа защиты пакета и вычисленного вектора инициализации; значение ESP ICV добавляется к пакету.

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому имитозащита данных пакета осуществляется вместе с их шифрованием;

и) опционально пакет инкапсулируется в UDP или TCP в соответствии с параметрами ESP SA;

к) происходит обновление динамических полей ESP SA, таких как:

  • порядковый номер (или расширенный номер) данного пакета как последнего отправленного;
  • количество защищенных пакетов;
  • объем защищенных данных;
  • IV (при необходимости);
  • прочие динамические поля SA.

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

На рисунке 6 показана обработка исходящего пакета в случае использования туннельного режима, а на рисунке 7 - в случае использования транспортного режима.

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

5.3 Обработка исходящего пакета

* - в зависимости от использования дополнительного заполнения (TFC Padding) поле Payload Data либо в точности равно IP Packet, либо представляет собой конкатенацию IP Data | TFC Padding;
5.3 Обработка исходящего пакета - имитозащищенные данные;
5.3 Обработка исходящего пакета - имитозащищенные и зашифрованные данные;
5.3 Обработка исходящего пакета - значение имитовставки

Рисунок 6 — Обработка исходящего пакета в случае использования туннельного режима

Примечания

1 Функции getKey и getNonce зависят от используемого трансформа ENCR.

2 Формирование AAD в общем случае зависит от используемого трансформа ENCR.

5.3 Обработка исходящего пакета

* - в зависимости от использования дополнительного заполнения (TFC Padding) поле Payload Data либо в точности равно IP Data, либо представляет собой конкатенацию IP Data | TFC Padding;
** - в транспортном режиме работы протокола IP-заголовок пакета остается неизменным с точностью до изменения параметра, содержащего длину пакета, с указанием на ESP как на следующий протокол и с пересчитанной контрольной суммой;
5.3 Обработка исходящего пакета - имитозащищенные данные;
5.3 Обработка исходящего пакета - имитозащищенные и зашифрованные данные;
5.3 Обработка исходящего пакета - значение имитовставки

Рисунок 7 — Обработка исходящего пакета в случае использования транспортного режима

5.3.1 Математическое описание процесса формирования ESP-пакета
5.3.1.1 Исходный пакет IP Packet представляется в виде

IP Packet = IP Header | IP Data, (2)

где IP Header — заголовок исходного IP-пакета,

IP Data — полезная нагрузка исходного IP-пакета.

5.3.1.2 Формируется ESP Header.

ESP Header = SPI | SN, (3)

где SPI — полагается равным значению SPI данного защищенного соединения,

SN — вычисляется путем увеличения на единицу номера предыдущего пакета, отправленного по данному защищенному соединению.

5.3.1.3 Формируется IV.

Если ESP SA подразумевает использование вектора инициализации, то значение IV вычисляется в соответствии с требованиями трансформа типа ENCR, согласованного в ходе создания ESP SA (см. подробнее 6.2.5).

5.3.1.4 Формируется ESP Data и ESP ICV.

а) Формируются поля Payload Data и ESP Trailer.

Если в ESP SA определен туннельный режим работы протокола ESP, то Payload Data формируется следующим образом:

Payload Data = IP Header | IP Data | TFC Padding, (4)

где TFCPadding \in B_{s} , s >= 0.

Если в ESP SA определен транспортный режим работы протокола ESP, то Payload Data формируется следующим образом

Payload Data = IP Data | TFC Padding, (5)

где TFCPadding \in B_{s} , s >= 0.

б) ESP Trailer формируется следующим образом

ESP Trailer = Padding | Pad Length | Next Header, (6)

где Padding формируется следующим образом: первый байт имеет значение 1, каждый последующий — на 1 (единицу) больше. Длина заполнения выбирается таким образом, чтобы суммарная длина Payload Data, Padding, Pad Length и Next Header была кратна четырем байтам и была одновременно кратной размеру блока используемого трансформа типа ENCR (если трансформ накладывает такие ограничения); рекомендуется выбирать минимальный размер дополнения, удовлетворяющий этому условию;

Примечание — Данный алгоритм является рекомендуемым способом заполнения поля Padding, однако [1] допускает использование других способов формирования дополнения; приемная сторона не должна отбрасывать пакет, если дополнение сформировано иным способом.

Pad Length содержит длину Padding;

Next Header в случае использования туннельного режима полагается равным 4 в случае IPv4 или 41 в случае IPv6; для транспортного режима значение копируется из поля для транспортного протокола исходного IP-заголовка; при формировании пустого (dummy) пакета Next Header полагается равным 59.

в) Пакет защищается с использованием параметров, указанных в ESP SA, в результате чего получаются значения Ciphertext и ESP ICV

Ciphertext | ESP ICV = = AEAD-Encrypt(Kmsg, nonce, AAD, Plaintext), (7)

где алгоритм аутентифицированного шифрования AEAD-Encrypt задается согласованным трансформом ENCR (см. 6.2.2).

Примечание - В рамках данного документа предполагается, что в ходе выработки параметров ESP SA для трансформа ENCR согласован AEAD-алгоритм;

значения Kmsg и vonce вырабатываются из ключа Kencr и вектора инициализации IV в соответствии с алгоритмами, определенными в трансформе ENCR (см. 6.2.6 и 6.2.7);

значение AAD формируется в зависимости от согласованного трансформа ESN и от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 5);

значение Plaintext формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 1).

Таблица 1

Формат Plaintext

Шифрование Plaintext
Есть шифрование Payload Data | ESP Trailer
Нет шифрования Ø

г) Результирующее значение ESP Data формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 2).

Таблица 2

Формат ESP Data

Шифрование ESP Data
Есть шифрование Ciphertext
Нет шифрования Payload Data | ESP Trailer
5.3.1.5 Результирующий пакет IP' Packet формируется следующим образом:

IP' Packet = = IP' Header | ESP Header | IV | ESP Data | ESP ICV, (8)

где IP' Header — либо новый IP-заголовок с новыми значениями IP-адресов (обычно другими, чем в исходном IP-заголовке IP Header), если в ESP SA определен туннельный режим работы протокола, либо исходный заголовок IP Header со скорректированной длиной, с указанием на ESP как на следующий протокол и с пересчитанной контрольной суммой, если в ESP SA определен транспортный режим работы протокола;

ESP Header, IV, ESP Data, ESP ICV — поля ESP-пакета (см. 4.1), формирование которых описано в 5.3.1.2 - 5.3.1.4.

5.4 Обработка входящего пакета

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

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

а) Если пакет был инкапсулирован в UDP или в TCP, то осуществляется его декапсуляция с отбрасыванием этих заголовков.

б) Из полученного IP пакета выделяется ESP-пакет и выполняется поиск SA в SAD по значению SPI из ESP-заголовка; если защищенное соединение не найдено, пакет отбрасывается.

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

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

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

д) Проводится проверка ICV пакета; если она прошла успешно, то выполняется расшифрование пакета с использованием трансформа ENCR, указанного в ESP SA, ключа защиты пакета и вектора инициализации из пакета, иначе пакет отбрасывается.

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому расшифрование данных происходит параллельно с проверкой ICV-пакета.

е) Отбрасываются обязательное (Padding) и опциональное (TFC Padding) дополнения.

ж) Исходный пакет реконструируется в соответствии с режимом инкапсуляции, прописанным в ESP SA, с использованием значения поля Next Header; если режим инкапсуляции пакета не совпадает с режимом инкапсуляции, указанным в ESP SA, пакет отбрасывается, как нарушающий политику безопасности.

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

к) Происходит обновление динамических полей SA, таких как:

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

л) Если полученный пакет был инкапсулирован в UDP или TCP и адрес или порт источника не совпадают с указанными в SA значениями и SA допускает обновление туннельного адреса, то туннельный адрес и порт TCP/UDP инкапсуляции обновляются значениями адреса и порта источника из пакета.

Полученный пакет отправляется в TCP/IP стек системы.

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

5.4.1 Математическое описание процесса извлечения данных из ESP-пакета

5.4.1.1 Проводится проверка ICV полученного пакета и его расшифрование. Если проверка ICV не прошла, то пакет отбрасывается.

Plaintext = AEAD-Decrypt(Kmsg, nonce, AAD, Ciphertext, ICV), (9)

где алгоритм расшифрования и проверки имитовставки AEAD-Decrypt задается согласованным трансформом ENCR (см. 6.2.2);

значения Kmsg и nonce вырабатываются из ключа Kencr и вектора инициализации IV в соответствии с алгоритмами, согласованными трансформом ENCR (см. 6.2.6 и 6.2.7);

значение AAD формируется в зависимости от согласованного трансформа ESN и от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 5);

значение Ciphertext формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 3).

Таблица 3

Формат Ciphertext

Шифрование Ciphertext
Есть шифрование ESP Data
Нет шифрования Ø

5.4.1.2 Если поле Next Header в ESP Trailer содержит значение 59, пакет отбрасывается.

5.4.1.3 От полученного значения Plaintext (при отсутствии шифрования — от ESP Data) отбрасывается ESP Trailer, получая значение Payload Data.

5.4.1.4 От значения Payload Data отбрасывается TFC Padding (при его наличии).

5.4.1.5 Полученная величина интерпретируется как IP Data; при этом:

а) если ESP SA использует туннельный режим, то IP Data интерпретируется как IP Packet;

б) если ESP SA использует транспортный режим, то IP Packet формируется следующим образом:

IP Packet = IP Header | IP Data, (10)

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

6 Использование российских криптографических алгоритмов в протоколе ESP

6.1 Согласование параметров ESP SA

В соответствии с настоящими рекомендациями в процессе согласования параметров ESP SA в протоколе IKEv2 для трансформа типа ENCR следует использовать только параметры, представленные в 6.3. Поскольку для трансформов типа ENCR используются AEAD-алгоритмы, при согласовании параметров SA трансформ типа INTEG не должен использоваться. Данные рекомендации не накладывают ограничений на согласование прочих параметров ESP SA.

6.2 Трансформы

Настоящие рекомендации определяют четыре трансформа типа ENCR:

ENCR_KUZNYECHIK_MGM_KTREE

ENCR_MAGMA_MGM_KTREE

ENCR_KUZNYECHIK_MGM_MAC_KTREE

ENCR_MAGMA_MGM_MAC_KTREE

Все описанные трансформы представляют собой AEAD-алгоритмы с диверсификацией ключей. Трансформы базируются на алгоритмах «Кузнечик» (ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE) и «Магма» (ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE), описанных в ГОСТ Р 34.12-2015 (разделы 4 и 5). Алгоритмы используются в режиме MGM, описанном в Р 1323565.1.026-2019.

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

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

В протоколе IKEv2 при согласовании параметров SA трансформы ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE представлены как AEAD-алгоритмы с длиной ключа Kencr 352 бита, из которых первые 256 бит используются как корневой ключ SA (K), а последующие 96 бит — в качестве соли (salt). В свою очередь, трансформы ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE представлены как AEAD-алгоритмы с длиной ключа 288 бит, из которых первые 256 бит используются как корневой ключ SA (K), а последующие 32 бита — в качестве соли (salt). Для всех трансформов длины ключей являются фиксированными, поэтому при их согласовании в IKEv2 атрибут Key Length не должен использоваться.

Данные трансформы не накладывают требований на выравнивание длины защищаемых данных (см. 4.1).

6.2.1 Блочный шифр

Определенные в настоящих рекомендациях трансформы ENCR в качестве блочного шифра используют шифры «Магма» и «Кузнечик», определенные в ГОСТ Р 34.12-2015 (см. таблицу 4). Длина блока составляет 128 бит для шифра «Кузнечик» и 64 бита для шифра «Магма», длина ключа K в обоих случаях составляет 256 бит.

Таблица 4

Алгоритмы блочного шифрования

Трансформ ENCR Блочный шифр
ENCR_KUZNYECHIK_MGM_KTREE «Кузнечик», ГОСТ Р 34.12-2015 (раздел 4)
ENCR_MAGMA_MGM_KTREE «Магма», ГОСТ Р 34.12-2015 (раздел 5)
ENCR_KUZNYECHIK_MGM_MAC_KTREE «Кузнечик», ГОСТ Р 34.12-2015 (раздел 4)
ENCR_MAGMA_MGM_MAC_KTREE «Магма», ГОСТ Р 34.12-2015 (раздел 5)
6.2.2 AEAD-алгоритм

Определенные в настоящих рекомендациях трансформы ENCR в качестве AEAD-алгоритма используют блочный шифр в режиме MGM, описанном в Р 1323565.1.026-2019. Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE длина имитовставки S полагается равной 96 битам, для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE используется полная имитовставка, т.е. S = 64.

Функция зашифрования AEAD-Encrypt задается в соответствии со следующей формулой:

AEAD-Encrypt(Kmsg, nonce, AAD, Plaintext) = = Ciphertext | ICV, (11)

где

(MGMnonce, AAD, Ciphertext, ICV) = = MGM-Encrypt(Kmsg, MGMnonce, AAD, Plaintext), MGMnonce = = nonce[1..1]&0x7f | nonce[2..|nonce|]. (12)

Функция расшифрования AEAD-Decrypt задается в соответствии со следующей формулой:

AEAD-Decrypt(Kmsg, nonce, AAD, Ciphertext) = res, (13)

где

res' = MGM-Decrypt(Kmsg, MGMnonce, AAD, Ciphertext, ICV),

MGMnonce = nonce[1..1]&0x7f | nonce[2..|nonce|], (14)

формула

6.2.3 Формат ключа трансформа

Длина ключа трансформа Kencr составляет 352 бита (klen = 44) для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE и 288 бит (klen = 36) для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE.

Настоящие рекомендации предполагают, что из ключа трансформа Kencr формируется корневой ключ K \in B_{32} и строка salt \in B_{klen - 32} :

K | salt = Kencr. (15)

6.2.4 Алгоритм диверсификации ключа

Ключ защиты сообщения Kmsg вычисляется на основании корневого ключа K и величин i1, i2 и i3, передаваемых в векторе инициализации, следующим образом:

ESPTREE(K, i1, i2, i3) = = Divers (Divers (Divers(K, l1, 0x00 | i1), l2, STR2(i2)), l3, STR2(i3)), (16)

где i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа;

l1, l2, l3 — константные ASCII строки длиной 6 байт (без нулевого байта в конце строки): l1 = «level1», l2 = «level2», l3 = «level3»;

Divers(K, L, D) — алгоритм диверсификации ключа K \in B_{32} по данным диверсификации D \in B_{2} и метке L \in B_{6} , который задается с помощью алгоритма KDF_GOSTR3411_2012_256, описанного в Р 50.1.113-2016 (подраздел 4.4): Divers(K, L, D) = KDF256(Kin, label, seed).

6.2.5 Формат вектора инициализации сообщения

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

IV = i1 | l2 | l3 | PNUM,

l2 = STR2(i2), (17)

l3 = STR2(i3),

PNUM = STR3(pnum),

где i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа;

pnum \in B_{3} — порядковый номер сообщения, зашифрованного на данном ключе.

l2, l3 и PNUM являются представлением в сетевом порядке байт величин i2, i3 и pnum соответственно (см. рисунок 8). Суммарная длина вектора инициализации — 8 байт.

6.2 Трансформы

Рисунок 8 — Формат вектора инициализации

Значение вектора инициализации должно быть уникальным для каждого ESP-пакета в рамках защищенного соединения. То есть для данного ключа K должно быть обеспечено различие векторов инициализации IV = i1 | l2 | l3 | PNUM для всех передаваемых пакетов.

6.2.6 Ключ защиты сообщения

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

Kmsg = ESPTREE(K, i1, i2, i3), (18)

где K — корневой ключ трансформа ENCR;

i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа, передаваемые в векторе инициализации (см. 6.2.5).

6.2.7 Одноразовый вектор nonce

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

Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 128 бит и формируется, как показано на рисунке 9.

6.2 Трансформы

Рисунок 9 — Формат одноразового вектора для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE

где zero — 8 бит нулей ( zero \in B_{1} , zero \equiv 0 );

PNUM — порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 8);

salt — соль (96 бит), берется из ключа трансформа Kencr (см. 6.2.3).

Для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 64 бита и формируется, как показано на рисунке 10.

6.2 Трансформы

Рисунок 10 — Формат одноразового вектора для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE

где zero — 8 бит нулей ( zero \in B_{1} , zero \equiv 0 );

PNUM — порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 8);

salt — соль (32 бита), берется из ключа трансформа Kencr (см. 6.2.3).

Иными словами, одноразовый вектор nonce вычисляется на основании строки salt \in B_{klen - 32} и порядкового номера пакета PNUM \in B_{3} следующим образом:

nonce = zero | PNUM | salt. (19)

Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 128 бит, для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 64 бита.

6.2.8 Формат AAD

Формат AAD (дополнительных имитозащищаемых данных) зависит от применяемого трансформа шифрования и от того, используется ли ESN (расширенный номер пакета) или нет. В случае применения трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE без использования ESN AAD формируется, как показано на рисунке 11.

6.2 Трансформы

Рисунок 11 — Формат AAD для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE без ESN

Для этих же трансформов в случае использования ESN AAD формируется, как показано на рисунке 12.

6.2 Трансформы

Рисунок 12 — Формат AAD для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE с ESN

В случае применения трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE без использования ESN AAD формируется, как показано на рисунке 13.

6.2 Трансформы

Рисунок 13 — Формат AAD для трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE без ESN

Для этих же трансформов в случае использования ESN AAD формируется, как показано на рисунке 14.

6.2 Трансформы

Рисунок 14 — Формат AAD для трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE с ESN

Таблица 5 описывает формирование AAD в зависимости от заданных параметров защищенного соединения.

Таблица 5

Формат AAD

Трансформ ENCR Трансформ ESN AAD
ENCR_KUZNYECHIK_MGM_KTREE
ENCR_MAGMA_MGM_KTREE		 noESN SPI | SN
ENCR_KUZNYECHIK_MGM_KTREE
ENCR_MAGMA_MGM_KTREE		 ESN SPI | ESN
ENCR_KUZNYECHIK MGM_MAC_KTREE
ENCR_MAGMA_MGM_MAC_KTREE		 noESN SPI | SN | IV | Payload Data | ESP Trailer
ENCR_KUZNYECHIK_MGM_MAC_KTREE
ENCR_MAGMA_MGM_MAC_KTREE		 ESN SPI | ESN | IV | Payload Data | ESP Trailer

В случае использования расширенных номеров пакетов в AAD включаются все 64 бита номера пакета, однако поле SN в составе ESP-пакета включает только 32 младших бита ESN, а старшие 32 бита не передаются.

Примечание - Заметим, что для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE AAD не включает в себя IV, так как имитозащита IV происходит неявным образом: значение IV определяет конкретный ключ защиты сообщения и одноразовый вектор, при их несоответствии исходным значениям пакет не будет успешно проверен на приемной стороне. Однако для трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE AAD включает в себя IV, чтобы AAD представлял собой один неразрывный блок данных.

6.2.9 Выбор параметров диверсификации ключа

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

6.2.10 Нагрузка на криптографические ключи

Предполагается, что передающая сторона ведет учет объема данных, защищенных на одном ключе Kmsg (ключ определяется значениями i1, i2, i3). Если при обработке очередного IP-пакета объем трафика будет превышен либо произойдет переполнение счетчика pnum, то до обработки данного пакета вырабатывается новый ключ Kmsg путем увеличения параметра i3 на единицу, pnum при этом обнуляется. При возможном превышении нагрузки на ключ второго уровня или при переполнении i3 параметр i2 увеличивается на единицу, а при возможном превышении нагрузки на ключ первого уровня или при переполнении i2 параметр i1 увеличивается на единицу. При превышении i1 своего максимального значения данное защищенное соединение удаляется и взамен него создается новое с новым ключом Kencr.

формула (20)

где значения i_{1}^{max} , i_{2}^{max} и i_{3}^{max} определяются политикой безопасности, но в любом случае ограничены величинами: i_{1}^{max} \leq 255 , i_{2}^{max} \leq 65535 и i_{3}^{max} \leq 65535 .

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

Предполагается, что на приемной стороне также ведется учет объема данных, защищенных на одном ключе Kmsg (ключ определяется значениями i1, i2, i3). Если при приходе очередного ESP-пакета объем трафика, защищенного на данном ключе Kmsg, достигнет максимально допустимого для абонента значения нагрузки на ключ или произойдет превышение нагрузки на промежуточные ключи дерева, то обработка пакета продолжается как обычно, но при этом инициируется создание нового защищенного соединения с новым ключом Kencr, которое должно использоваться взамен текущего.

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

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

Если на приемной стороне фиксируется получение значительного числа искаженных пакетов за короткий промежуток времени в контексте какого-то защищенного соединения, то это может служить признаком проведения атаки, особенно если при этом наблюдается хаотичное изменение значений i1, i2, i3 и pnum в получаемых пакетах. В этом случае приемная сторона может удалить данное защищенное соединение и создать идентичное ему, но с новым значением SPI и с новым ключом Kencr.

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

6.3 Идентификаторы алгоритмов

Ниже приведены идентификаторы российских алгоритмов, используемых в настоящих спецификациях. Эти идентификаторы используются в протоколе IKEv2 при согласовании параметров ESP SA.

Идентификаторы для трансформа типа ENCR приведены в таблице 6.

Таблица 6

Идентификаторы российских алгоритмов

Трансформ ENCR Идентификатор
ENCR_KUZNYECHIK_MGM_KTREE 32
ENCR_MAGMA_MGM_KTREE 33
ENCR_KUZNYECHIK_MGM_MAC_KTREE 34
ENCR_MAGMA_MGM_MAC_KTREE 35

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

МАКСИМАЛЬНЫЙ ОБЪЕМ ОБРАБАТЫВАЕМОГО ТРАФИКА

Таблица А.1 содержит рекомендуемые значения максимально допустимого суммарного объема трафика, который обрабатывается на одном ключе Kmsg. При достижении максимального объема должен вырабатываться новый ключ Kmsg из дерева ключей по процедуре, описанной в 6.2.10.

Таблица А.1

Максимально допустимый объем трафика, обрабатываемого на одном ключе Kmsg

Трансформ ENCR Максимальный объем трафика
ENCR_KUZMYECHIK_MGM_KTREE
ENCR_KUZNYECHIK_MGM_MAC_KTREE		 241 байт
ENCR_MAGMA_MGM_KTREE
ENCR_MAGMA_MGM_MAC_KTREE		 228 байт

Примечания

1 Указанные значения носят рекомендательный характер.

2 Учитывая то, что максимальное число пакетов, защищаемых на одном ключе Kmsg, не может превысить 224, а максимальный размер IP-пакета не превышает 216 байт (это ограничение действует как на защищаемый пакет, так и на IP-пакет, получающийся в результате применения к защищаемому пакету протокола ESP), суммарный объем трафика, защищаемого на одном ключе Kmsg, не может превысить 240 байт. Таким образом, ограничение 241 байт для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZMYECHIK_MGM_MAC_KTREE является недостижимым.

При использовании трансформов, базирующихся на шифре «Магма» (ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE), рекомендуется ограничивать количество допустимых ключей Kmsg для каждого корневого ключа K значением меньшим, чем размер дерева ключей при полном переборе i1, i2, i3 (например, путем введения ограничений на максимальные значения этих счетчиков).

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

ТЕСТОВЫЕ ВЕКТОРЫ

Данное приложение содержит тестовые векторы. Значения тестовых векторов приведены в шестнадцатеричном виде.

Б.1 Трансформ ENCR_K0ZNYECHIK_MGM_KTREE, пример 1

K:
b6180c145c512dbd69d9cea92cac1b5c
e1bcfa73792d61af0b440d84b522cc38
i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000
Kmsg:
2ff1c90ede786e061e17b374d782af7b
d880bd527c66a2badc3e569aab271da4
salt [12]:
7b67e6f244f97f0678952e45
nonce [16]:
000000007b67e6f244f97f0678952e45
IV [8]:
0000000000000000
AAD [8]:
5146536b00000001
plaintext [64]:
4500003c233500007f01eecc0a6f0ac5
0a6f0a1d0800f35b0200580061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
ciphertext [64]:
189d1288b718f9eabe554b239bee6596
c6d4eafd316496ef901cac316005aa07
6297b224bf6d2be35fd6f67e7b9deb31
85ffe9179ca9bf0bdbafc23eae4da56f
ESP ICV [12]:
50b070a15a2bd9738689f8ed
ESP packet [112]:
45000070004d0000ff32914f0a6f0ac5
0a6f0a1d5146536b0000000100000000
00000000189d1288b718f9eabe554b23
9bee6596c6d4eafd316496ef901cac31
6005aa076297b224bf6d2be35fd6f67e
7b9deb3185ffe9179ca9bf0bdbafc23e
ae4da56f50b070a15a2bd9738689f8ed

Б.2 Трансформ ENCR_KUZNYECHIK_MGM_KTREE, пример 2

K:
b6180c145c512dbd69d9cea92cac1b5c
e1bcfa73792d61af0b440d84b522cc38
i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000
Kmsg:
9abac65778180e6f2af61fb8d5716236
66c2f5130d54e2116c7d530e6e7d48bc
salt [12]:
7b67e6f244f97f0678952e45
nonce [16]:
000000007b67e6f244f97f0678952e45
IV [8]:
0000010001000000
AAD [8]:
5146536b00000010
plaintext [64]:
4500003c234800007f01eeb90a6f0ac5
0a6f0a1d0800e45b0200670061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
ciphertext [64]:
780a2c626232157bfe017632f32db4d0
a4fa612f66c2bf79d5e2149bac1dfc4b
154b69034dc21def20906d596281127c
ff7256abf00ba122bb5e6c71a4d49a4d
ESP ICV [12]:
c22f8740838e3dface91ccb8
ESP packet [112]:
45000070005c0000ff3291400a6f0ac5
0a6f0a1d5146536b0000001000000100
01000000780a2c626232157bfe017632
f32db4d0a4fa612f66c2bf79d5e2149b
ac1dfc4b154b69034dc21def20906d59
6281127cff7256abf00ba122bb5e6c71
a4d49a4dc22f8740838e3dface91ccb8

Б.3 Трансформ ENCR_MAGMA_MGM_KTREE, пример 1

K:
5b50bf3378870238f3ca740fd124ba6c
2283ef589be6f46a894aa35d5f06b203
i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000
Kmsg:
256521e270b74a164dfc26e6bf0cca76
5e9d41027d4b7b19762b1cc901dcde7f
salt [4]:
cf366312
nonce [8]:
00000000cf366312
IV [8]:
0000000000000000
AAD [8]:
c8c2b28d00000001
plaintext [64]:
4500003c242d00007f01edd40a6f0ac5
0a6f0a1d0800de5b02006d0061626364
65666768696a6b6c6d6e6f7071727374
757 67761626364656667686901020204
ciphertext [64]:
fa0840332c4f3fc9644d8c2c4a917e0c
d86f8e61040387646bb9dfbd91503f4a
f5d2426949d35a229e1e0efc99acee9e
3243e23ba4d11e845c91a7191552cce8
ESP ICV [8]:
5f4 afa8b02940f5c
ESP packet [108]:
4500006c00620000ff32913e0a6f0ac5
0a6f0a1dc8c2b28d0000000100000000
00000000fa0840332c4f3fc9644d8c2c
4a917e0cd86f8e61040387646bb9dfbd
91503f4af5d2426949d35a229e1e0efc
99acее9e3243e23ba4d11e845c91a719
1552cce85f4afa8b02940f5c

Б.4 Трансформ ENCR_MAGMA_MGM_KTREE, пример 2

K:
5 b50bf3378870238f3ca740fd124ba6c
2283ef589be6f46a894aa35d5f06b203
i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000
Kmsg:
20e046d409839b23f066a50a7a065b4a
39244f0e29ef1e6f2e5d2e1355f5da08
salt [4]:
cf366312
nonce [8]:
00000000cf366312
IV [8]:
0000010001000000
AAD [8]:
c8c2b28d00000010
plaintext [64]:
4500003c244000007f01edc10a6f0ac5
0a6f0a1d0800cf5b02007c0061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
ciphertext [64]:
7a714841a534b758936a8eab269140a8
25a7f35db9e4371fe76c999c9b88db72
1dc759f656b5b3eab6b14d6bd77a071d
4b9378bd08976c33ed9a0191bffea1dd
ESP ICV [8]:
dd5d509afdb80998
ESP packet [108]:
4500006c00710000ff32912f0a6f0ac5
0a6f0a1dc8c2b28d0000001000000100
010000007a714841a534b758936a8eab
269140a825a7f35db9e4371fe76c999c
9b88db721dc759f656b5b3eab6b14d6b
d77a071d4b9378bd08976c33ed9a0191
bffea1dddd5d509afdb80998

Б.5 Трансформ ENCR_KUZNYECHIK_MGM_MAC_KTREE, пример 1

K:
98bd34ce3be19a3465e487c0064883f4
88cc239263dc3204919b643fe757b2be
i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000
Kmsg:
98f10301810a041cdadde1bd85a08f21
8bacb57e0035e222c831e3e4f0a20c8f
salt [12]:
6c51cbac93c45bea9962791d
nonce [16]:
000000006c51cbac93c45bea9962791d
IV [8]:
0000000000000000
AAD [80]:
3dac926a000000010000000000000000
4500003c0cf100007f0105110a6f0ac5
0a6f0a1d0800485c0200030061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
plaintext [0]:
ciphertext [0]:
ESP ICV [12]:
cac58ce5e88b4bf32d6cf04d
ESP packet [112]:
4500007 000010000ff32919b0a6f0ac5
0a6f0a1d3dac926a0000000100000000
000000004500003c0cf100007f010511
0a6f0ac50a6f0a1d0800485c02000300
6162636465666768696a6b6c6d6e6f70
71727374757677616263646566676869
01020204cac58ce5e88b4bf32d6cf04d

Б.6 Трансформ ENCR_KUZNYECHIK_MGM_MAC_KTREE, пример 2

K:
98bd34ce3be19a3465e487c0064883f4
88cc239263dc3204919b643fe757b2be
i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000
Kmsg:
02c541877cc623f3f135919a7513b6f8
a8a18cb26399862f50814f5291016784
salt [12]:
6c51cbac93c45bea9962791d
nonce [16]:
000000006c51cbac93c45bea9962791d
IV [8]:
0000000001000000
AAD [80]:
3dac926a000000060000000001000000
4500003c0cfb00007f0105070a6f0ac5
0a6f0a1d0800435c0200080061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
plaintext [0]:
ciphertext [0]:
ESP ICV [12]:
babc67ec72a8c31a89b40e91
ESP packet [112]:
4500007000060000ff3291960a6f0ac5
0a6f0a1d3dac926a0000000600000000
010000004500003c0cfb00007f010507
0a6f0ac50a6f0a1d0800435c02000800
6162636465666768696a6b6c6d6e6f70
71727374757677616263646566676869
01020204babc67ec72a8c31a89b40e91

Б.7 Трансформ ENCR_MAGMA_MGM_MAC_KTREE, пример 1

K:
d065b530fa20b824c7570c1d862ae339
2c1c076dfada6975744a07a8857dbd30
i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000
Kmsg:
4c614599a0a067f19487240ae100e1b7
eaf23edaf87e387350861c683ba40446
salt [4]:
88798f29
nonce [8]:
0000000088798f29
IV [8]:
0000000000000000
AAD [80]:
3e40699c000000010000000000000000
4500003c0e0800007f0103fa0a6f0ac5
0a6f0a1d0800365c0200150061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
plaintext [0]:
ciphertext [0]:
ESP ICV [8]:
4dd4258a253595df
ESP packet [108]:
4500006c00130000ff32918d0a6f0ac5
0a6f0a1d3e40699c0000000100000000
000000004500003c0e0800007f0103fa
0a6f0ac50a6f0a1d0800365c02001500
6162636465666768696a6b6c6d6e6f70
71727374757677616263646566676869
010202044dd4258a253595df

Б.8 Трансформ ENCR_MAGMA_MGM_MAC_KTREE, пример 2

K:
d065b530fa20b824c7570c1d862ae339
2с1c076dfada6975744a07a8857dbd30
i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000
Kmsg:
b4f3f90dc487fab8c4afd0eb4549f2f0
e43632b67919372e1e9609eaf0b8e228
salt [4]:
88798f29
nonce [8]:
0000000088798f29
IV [8]:
0000000001000000
AAD [80]:
3e40699c000000060000000001000000
4500003c0e1300007f0103ef0a6f0ac5
0a6f0a1d0800315c02001a0061626364
65666768696a6b6c6d6e6f7071727374
75767761626364656667686901020204
plaintext [0]:
ciphertext [0]:
ESP ICV [8]:
8484a92330a0b196
ESP packet [108]:
4500006c00180000ff3291880a6f0ac5
0a6f0a1d3e40699c0000000600000000
010000004500003c0e1300007f0103ef
0a6f0ac50a6f0a1d0800315c02001a00
6162636465666768696a6b6c6d6e6f70
71727374757677616263646566676869
010202048484a92330a0b196

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

АЛГОРИТМ ОБРАБОТКИ РАСШИРЕННОГО НОМЕРА ПАКЕТА

Алгоритм обработки расширенного номера пакета на приемной стороне. Все используемые переменные представляют собой беззнаковые целые 32-битные числа, все вычисления делаются по модулю 232. Используемые переменные описаны в 4.1.2.3.

If (Rl >= Wsz — 1) If (Sl >= Rl — Wsz + 1) Sh = Rh If (Sl <= Rl) If (соответствующий Sl бит сброшен) If (имитовставка корректная) Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет Else Отбросить пакет Else If (имитовставка корректная) Rl = Sl (сдвинуть окно) Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет Else Sh = Rh + 1 If (имитовставка корректная) Rl = Sl (сдвинуть окно) Rh = Rh + 1 Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет Else If (Sl >= Rl — Wsz + 1) Sh = Rh — 1 If (соответствующий Sl бит сброшен) If (имитовставка корректная) Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет Else Отбросить пакет Else Sh = Rh If (Sl <= Rl) If (соответствующий Sl бит сброшен) If (имитовставка корректная) Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет Else Отбросить пакет Else If (имитовставка корректная) Rl = Sl (сдвинуть окно) Установить соответствующий Sl бит Продолжить обработку пакета Else Отбросить пакет

БИБЛИОГРАФИЯ

[1] IETF RFC 4303 С. Кент. Защищенное вложение IP (ESP) (Kent S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, http://www.rfc-editor.org/info/rfc4303)
УДК 681.3.06:006.354ОКС 35.040
Ключевые слова: криптографические протоколы, режимы, шифрование, имитовставка, ключ