CryptoPro | КриптоПро IPsec API: масштабируемость и производительность

Основные характеристики

• IKE — Использование ГОСТ 28147-89, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001 при управлении ключами IKE и ISAKMP;
• ESP — Комбинированный алгоритм шифрования вложений IPsec (ESP) на основе ГОСТ 28147-89;
• AH — Алгоритмы обеспечения целостности IPsec (ESP, AH) на основе ГОСТ Р 34.11-94;
• TLS — GOST 28147-89 Cipher Suites for Transport Layer Security (TLS).

Обеспечивает защиту пакетов в канале (ESP) на базе ГОСТ 28147-89, включая шифрование и имитозащиту.

Аутентификация (IKE) в сети/на сетевом уровне осуществляется:

• на ключах подписи, в соответствии с ГОСТ Р 34.10-2001(ЭЦП), ГОСТ Р 34.11-94(Хэш);
• PSK в соответствии с IKE;
• с использованием аутентификации TLS (или иного сертифицированного средства аутентификации). Шифрование и имитозащита пакетов аутентификации осуществляется на базе ГОСТ 28147-89.

Введение

Данный документ определяет следующие преобразования [ESP]:

• комбинированный алгоритм ESP_GOST-SIMPLE-IMIT;
• комбинированный алгоритм ESP_GOST-4M-IMIT;
• комбинированный алгоритм ESP_GOST-1K-IMIT.

Протокол [ESP] используется в архитектуре IPsec [ARCH] для обеспечения конфиденциальности, целостности и аутентичности содержимого IP пакетов.

Этот документ описывает использование ГОСТ 28147-89 [GOST28147], но не определяет сам криптографический алгоритм и форматы представления криптографических типов данных.

Алгоритмы описываются соответствующими национальными стандартами, а представление данных и параметров соответствует следующими документам IETF [DOI]. Этот документ описывает так же дополнительные идентификаторы расширяющие [DOI].

Введение

IPsec — набор протоколов защиты сетевого трафика. ESP — протокол защиты конечных пакетов. Наше IPsec API полностью соответствует техническим спецификациям ТК26 по использованию отечественной криптографии, которые определяют обеспечение ESP конфиденциальности, целостности и аутентичности данных при использовании алгоритмов ГОСТ.

Существует два режима работы ESP ГОСТ: режим 4M, который соответствует классам защиты с КС1 по КС3, и режим 1K, соответствующий классу KB2. В основе работы данных режимов лежит дерево ключей, в корне которого находится базовый ключ полученный в процессе согласования ключей, ветви — ключи диверсификации основного ключа, ведущие к ключам, которые будут использованы для конкретного пакета в зависимости от его номера.

Для режима 4M определено использование одного ключа на 64 пакета (произведение 64 пакетов на максимальный размер пакета в 64 килобайта даёт 4 мегабайта, отсюда название режима). Для режима 1K определено использование одного ключа на один пакет в сочетании с усложнением ключа каждые 1024 байта (отсюда название 1K).

Проясним, какой же всё-таки практический смысл от работы одной сессии в многопоточном режиме. В настоящий момент наш сертифицированный вариант IPsec API позволяет работать каждой сессии ESP в своём потоке. На практике, имея большое количество клиентских сессий, мы можем равномерно загрузить все ядра процессора, так что каждая сессия будет обрабатываться на своём ядре — в итоге мы получим хорошую суммарную производительность и, в идеальных условиях, можем загрузить все ядра по максимуму.

Всё меняется, когда задача заключается в соединении небольшого количества точек высокопроизводительными туннелями: в этом случае принципиальным моментом будет максимальная скорость каждого конкретного туннеля. Как уже было сказано выше, при отсутствии возможности распараллеливания сессии ESP мы не сможем загрузить более одного ядра процессора для каждого туннеля, и поэтому наша максимальная производительность туннеля всегда будет упираться в производительность одного логического процессора. А остальные ядра при этом будут простаивать без работы.

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

На стороне криптопровайдера задача была решена внедрением поддержки дочернего контекста провайдера для работы в нити (PP_CREATE_THREAD_CSP): он аналогичен родителю, но живёт в своей независимой памяти, что позволяет ему выполнять некоторые операции с ключом, не блокируя ключ на запись (CP_CRYPT_NOKEYWLOCK).

Эта разработка была использована для реализации возможности распараллеливания ESP. При инициализации нашего IPsec API пользователь может задать максимальное количество потоков, на которые он рассчитывает распараллеливать сессии. Как правило, это число соответствует количеству доступных логических процессоров.

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

.2 Информативные ссылки

.3 Библиотека ссылок

Терминология

Термины «ДОЛЖНО», «ДОЛЖНА», «ДОЛЖНЫ», «ДОЛЖЕН» (MUST, REQUIRED, SHALL), «НЕ ДОЛЖЕН», «НЕ ДОЛЖНЫ» (MUST NOT, SHALL NOT), «РЕКОМЕНДОВАНО» (SHOULD, RECOMMENDED), «НЕ РЕКОМЕНДОВАНО» (SHOULD NOT, NOT RECOMMENDED)

В документе используются термины и определения стандартов IPsec [ARCH] и [ESP], ниже приводятся только дополнительные определения.

encryptCNT(IV, K, D):

шифрование ГОСТ 28147-89 в режиме «гаммирования» на ключе K данных D с начальным вектором IV ( Section 1.1 of [CPALGS], [GOST28147], [Schneier95]). Узел замены определяется Section 5.1;

decryptCNT(IV, K, D):

расшифрование ГОСТ 28147-89 в режиме «гаммирования» на ключе K данных D с начальным вектором IV ( Section 1.1 of [CPALGS], [GOST28147], [Schneier95]). Узел замены определяется Section 5.1;

Divers(K,D):

алгоритм диверсификации ключа K по данным D ( Section 7 of [CPALGS]). Узел замены определяется Section 5.1. В целях настоящего документа, аргументом D является 64-битное целое число, представленное в сетевом порядке байт;

gost28147IMIT(IV, K, D):

выработка имитовставки ГОСТ 28147-89 на ключе K от данных D, с внутренним выравниванием нулями до границы блока 8 байт (Section 1.1 of [CPALGS], [GOST28147], описание и пример сетевого представления результата приведён [CPCMS], Section 9.2, 9.3). Узел замены согласуется Section 5.1;

Seq#:

64-битный номер пакета, если [ESN] не согласован, то значение Seq# всегда принадлежит диапазону 1..2^32-1;

IV(Seq#):

синхропосылка пакета Seq#;

Kc_e(Seq#):

ключ комбинированного алгоритма шифрования пакета Seq#;

Kc_i(Seq#):

ключ комбинированного алгоритма имитозащиты пакета Seq#;

Kr_e:

корневой ключ шифрования SA;

Kr_i:

корневой ключ имитозащиты SA;

KeyMeshing:

Используемый алгоритмы усложнения ключа, описан в Section 2.3 of [CPALGS];

Seq#h:

старшая часть Seq#;

Seq#l:

младшая часть Seq#;

SPIcookie:

величина, вычисляемая в рамках ISAKMP SA или иной не-IPsec SA, например в «Quick Mode» фазы 2 протокола [draft.CPIKE].

substr(s..f, bytes):

последовательность байт с байта s, по байт f, выбранная из представленной в сетевом порядке последовательности bytes;

bits[s..f]:

последовательность бит с бита s, по бит f, выбранная из представленной в сетевом порядке последовательности bits;

пакет с искажённым Seq#:

ESP вложение или AH пакет, для которого не прошёл предварительный контроль SPI и Seq#;

искажённый пакет:

ESP вложение или AH пакет, для которого вычисленное значение ICV не совпало с переданным значением;

В рамках ISAKMP SA [draft.CPIKE] или иной не-IPsec SA согласуются для данной IPsec SA, как минимум, следующие компоненты:

• 256-бит симметричный ключ Kr_e;
• 256-бит симметричный ключ Kr_i;
• 32-х битная случайная величина SPIcookie ;
• параметры ГОСТ 28147-89;
• максимальный объём данных SA в байтах (Lifetime SA, Kbytes);
• максимальное время жизни SA в секундах (Lifetime SA, sec);
• максимальное значение счётчика искажённых пакетов.

Вложение ESP пакета должно соответствовать Section 2 of [ESP] для комбинированного алгоритма со следующими параметрами:

• IV передаётся в пакете и имеет размер 8 байт;
• ESP вложение выравнивается на границу 8 байт;
• Если согласовано ESN, то Seq#h в пакете не передаётся;
• Явного выравнивания ICV не производится ;
• ICV передаётся в пакете, имеет размер 4 или 8 байт .

Для SA ДОЛЖНА быть включена услуга обеспечения защиты от навязывания повторных пакетов (anti-replay).

Порядок обработки исходящих пакетов ДОЛЖЕН соответствовать Section 3.3 of [ESP] со следующими уточнениями:

Порядок обработки входящих пакетов ДОЛЖЕН соответствовать Section 3.4 of [ESP] со следующими уточнениями:

• Дополнительно к проверкам Section 3.4.2 of [ESP], РЕКОМЕНДОВАНО проверить длину ESP вложения на соответствие параметрам SA;
• Дополнительно к проверкам Section 3.4.3 of [ESP], для преобразований ESP_GOST-4M-IMIT и ESP_GOST-1K-IMIT ДОЛЖНА быть выполнена проверка IV (IV.IVCounter). Для ESP_GOST-SIMPLE-IMIT МОЖЕТ быть выполнена проверка IV на уникальность;
• Получателю РЕКОМЕНДОВАНО увеличить счётчик текущего объём данных SA в байтах (Lifetime SA, Kbytes) и сравнить его с максимальным. SA в байтах (Lifetime SA, Kbytes) и сравнить его с максимальным. При его превышении РЕКОМЕНДОВАНО заблокировать дальнейшую работу SA;
• Расшифрование в преобразованиях осуществляется в режиме усложнения ключа KeyMeshing, который определяется конкретным преобразованием, по формуле:

  decryptCNT(IV(Seq#), Kc_e(Seq#), Payload data|…|Next Header);

• Имитовставка в преобразованиях проверяется по формуле:

  ICVchk = gost28147IMIT(0, Kc_i(Seq#), SPI|Seq#l|IV|..|Next Header[|Seq#h]);

• Если ICV != ICVchk, то получателю РЕКОМЕНДОВАНО увеличить счётчик искажённых пакетов SA и сравнить его с максимальным. При его превышении РЕКОМЕНДОВАНО заблокировать дальнейшую работу SA;

При вычислении MTU следует руководствоваться правилами выравнивания Section 2 of [ESP] со значением модуля 8 байт, и с учётом фиксированного добавленного размера 12 байт для IV (8 байт) и ICV (4 байта).

В преобразовании ESP_GOST-SIMPLE-IMIT используются:

IV(Seq#l) — случайные и уникальные 8 байт, получатель МОЖЕТ проверять их уникальность;

KeyMeshing = id-Gost28147-89-None-KeyMeshing;

Kc_e(Seq#) = Kr_e;

Kc_i(Seq#) = Kr_i;

Согласованный объём данных SA НЕ ДОЛЖЕН превышать 4 Мбайт.

Согласованный размер ESP вложений НЕ ДОЛЖЕН превышать 4 Мбайт.

В преобразовании ESP_GOST-4M-IMIT используются:

Значение IV(Seq#l) имеет следующий вид:

                  
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|                           IVRandom                            |
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|                           IVCounter                           |
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
                  
                

Figure 1: IV для ESP_GOST-4M-IMIT и ESP_GOST-1K-IMIT

где:

IVRandom — случайные 4 байта;

IVCounter = SPIcookie SPI Seq#l IVRandom (mod 2^32);

Получатель ДОЛЖЕН контролировать IVCounter на фазе предварительного контроля Seq# и НЕ ДОЛЖЕН выполнять криптографических преобразований при ошибке. Если реализация ESP ведёт протоколы аудита, то эта ошибка МОЖЕТ классифицироваться, как ошибка контроля Seq#. В частности, пакеты с ошибочным IVCounter НЕ ДОЛЖНЫ вызывать увеличения счётчика искажённых пакетов и уменьшения объёма данных SA.

KeyMeshing = id-Gost28147-89-None-KeyMeshing;

Kc_e(Seq#) = Divers(Divers(Divers(Kr_e, Seq#&0xffffffff00000000),
Seq#&0xffffffffffff0000),
Seq#&0xffffffffffffffc0);

Kc_i(Seq#) = Kc_e(Seq#);

НЕ РЕКОМЕНДОВАНО согласовывать размеры ESP вложений более чем 64 Кбайт.

В преобразовании ESP_GOST-1K-IMIT используются:

IV(Seq#l) получается так же, как в Section 4.5;

KeyMeshing = id-Gost28147-89-CryptoPro-KeyMeshing;

Kc_e(Seq#) = Divers(Divers(Divers(Kr_e, Seq#&0xffffffff00000000),
Seq#&0xffffffffffff0000),
Seq#);

Kc_i(Seq#) = Kc_e(Seq#);

Для согласования атрибутов преобразований Section 4 на фазе II протокола [IKE] обе стороны ДОЛЖНЫ послать ESP_GOST vendor ID. Формат ESP_GOST vendor ID следующий:

            
0                   1            
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
 - - - - - - - - - - - - - - - - 
|                           |M|M|
|     ESP_GOST_VENDOR_ID    |J|N|
|                           |R|R|
 - - - - - - - - - - - - - - - - 
                  
          

Figure 2: ESP_GOST-VENDOR-ID

, где ESP_GOST_VENDOR_ID = { ‘x03’, ‘x10’, ‘x17’, ‘xE0’, ‘x7F’, ‘x7A’, ‘x82’, ‘xE3’, ‘xAA’, ‘x69’, ‘x50’, ‘xC9’, ‘x99’, ‘x99’ } (первые 14 байт ГОСТ Р 34.11-94 хэш от char строки «IKE/GOST»), а MJR и MNR соответствуют текущей major и minor версии преобразований ESP_GOST (т.е. 1 и 0).

При согласовании SA РЕКОМЕНДОВАНО согласовать параметры ГОСТ 28147-89

Реализация ESP МОЖЕТ иметь предопределённые настройки конфигурации данного значения.

В случае применения ESP для [JUMBO] пакетов IPv6, приложение РЕКОМЕНДОВАНО согласовать этот параметр.

Авторы документа благодарят российское представительство CISCO, российское представительство CheckPoint и ГАЗПРОМ, которые инициировали процесс обеспечения совместимости продуктов IPsec.

Выражаем благодарность Чмора Андрею Львовичу, ОАО «Инфотекс», за дискуссию по определению понятия DoS.

Выражаем особую благодарность Смыслову Валерию Анатольевичу, ОАО «ЭЛВИС-ПЛЮС», за большое количество ценных замечаний и улучшений, как в сам протокол, так и в его описание.

Выражаем благодарность Тимакову Виктору Михайловичу, ЗАО «Сигнал-КОМ», за дискуссию по поводу криптографически стойкого режима выработки имитовставки ГОСТ 28147-89.

Благодарности рецензентам…

Адреса авторов

Дополнительные материалы

Если вы хотите оценить производительность IPsec API самостоятельно, то для вас доступен наш самодостаточный IPsecPerfTest (для ОС Windows). Все текущие замеры были приведены с его помощью на основе скриптов которые также доступны в архиве.

IPsecPerfTest_20221109.zip

Для ознакомления с версией КриптоПро IPsec API версии 4.0 мы подготовили файл chm с документацией нашего API для разработчиков.

ikespah_ipsec40_20221013.zip

Криптопро | криптопро ipsec

Криптопро ipsec — купить лицензию криптопро ipsec по выгодной цене в ростове-на-дону на официальном сайте

Масштабируемость: мультипакеты

Мультипакет — это специальным образом сформированная структура данных, предназначенная для обработки более одного пакета за одну операцию. За 100% примем производительность обработки пакета в привычном режиме (один пакет за операцию) и оценим эффективность мультипакетного режима как соотношение производительности между вариантом с обработкой нескольких пакетов в мультипакете и привычной работы «по одному пакету за операцию».

Как видно из графиков, во всех режимах работы 4M, кроме случая малых пакетов, наблюдается заметное снижение производительности при использовании менее 4 пакетов в мультипакете. Это объясняется тем, что скорость шифрования уступает скорости расчёта имитовставки, которая не распараллеливается операциями в SSSE3 и AVX в рамках одного пакета, тем самым снижая общую производительность.

Также можно заметить, что оптимальным числом пакетов в мультипакете является 16: время расчёта имитовставки в 16 пакетах в среднем близко с шифрованием этих пакетов. Дальнейшее увеличение пакетов в мультипакетном режиме приводит, в зависимости от параметров, к незначительному росту или падению производительности.

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

Масштабируемость с использованием мультипакетного режима в режиме 1К соответствует ожиданию того, что данный режим работы ESP принципиально не ускоряется при использовании мультипакета, по причине обработки каждого пакета на своём ключе. Наблюдается незначительный рост производительности во всех режимах, что свидетельствует о снижении накладных расходов на вызов при отсутствии каких-либо других преимуществ.

Масштабируемость: потоки

Продемонстрируем текущие возможности масштабирования IPsec API. Ключевым моментом масштабирования является изменение эффективности работы потоков при добавлении нового потока. За «эффективный поток» примем производительность IPsec API в однопоточном режиме и измерим производительность в многопоточных режимах.

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

Назначение

КриптоПро IPsec (Internet Protocol Security) обеспечивает прозрачную для приложений и пользователей защищенную передачу данных в IP-сетях с использованием служб шифрования, а также защиту сетевого доступа в окружении Windows 2003, Windows 2008.

Настройка vpn криптопро ipsec с гостовым шифрованием

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

• Защита соединения узлов корпоративной вычислительной сети (Site-to-Site VPN);
• Защита подключения удалённых пользователей или малых офисов;
• Защита передачи конфиденциальной информации в ЛВС от нарушителей не являющимися пользователями автоматизированных систем, но имеющим доступ к ЛВС и/или нарушителей являющихся пользователями, но не имеющих необходимых полномочий.

Поддерживаемые платформы:

КриптоПро IPSec функционирует в следующих операционных системах (ОС):

• Windows XP;
• Windows 7 (32/64);
• Windows 2003(32);
• Windows 2008 R2.

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

Чтобы оценить максимально возможные скорости работы, мы измерили работу IPsec API только при оптимальных параметрах тестов (согласно полученным ранее результатам), которыми являются 16 пакетов в мультипакете и, ограниченное числом 32, максимально доступное количество реальных потоков.

Хорошо заметно, что текущим пределом являются скорости порядка 12.5 Гбит/с для режима 4M. В режиме 1К скорость растёт пропорционально размеру пакета и для больших пакетов (более 60000 байт) достигает значений более 8 Гбит/с.

Оценка производительности одного потока

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

По полученным результатам можно сделать несколько замечаний. Даже самый слабый из представленных процессоров, Intel Atom N450, при оптимальной нагрузке способен выдать скорость более 100 Мбит/с. С другой стороны, даже тривиальная реализация в один поток без использования мультипакета на хорошем процессоре способна выдать скорость более 500 Мбит/с, а оптимальная загрузка всех возможностей процессора позволяет достичь скоростей порядка 1 Гбит/с, даже на таких процессорах как Intel Celeron J1900.

Совместимые мэ и оборудование

КриптоПро IPSec совместим с любыми МЭ и сетевым оборудованием поддерживающим протоколы IPSec GOST.

МЭ:

• Check Point Firewall-1/VPN-1 версии R65 HFA50 GOST;
• MS ISA (2004/2006);
• Forefront TMG 2022;
• Другие поддерживающие IPsec и/или L2TP/IPsec.