Страница не найдена

Что такое tls с гост?

В процессе работы над задачей разработки протокола TLS с поддержкой российских криптонаборов при активном участии специалистов КриптоПро было создано два ключевых документа, регламентирующих порядок работы протоколов TLS 1.2 и TLS 1.3 с ГОСТ Р 34.

12-2022 (с использованием алгоритмов Магма и Кузнечик) – рекомендации по стандартизации Р 1323565.1.020-2022 для TLS 1.2 и рекомендации по стандартизации Р 1323565.1.030-2020 для TLS 1.3. Документы определяют криптонаборы с российскими алгоритмами хэширования, шифрования и электронной подписи с учетом наиболее современных и безопасных практик использования криптоалгоритмов.

Для регламентации работы протокола с использованием криптонаборов на базе ГОСТ 28147-89 ранее были разработаны методические рекомендации МР 26.2.001-2022. Отметим, что сами российские режимы и криптонаборы стандартизованы в международных организациях ISO и IETF, пройдя экспертизу ведущих мировых специалистов.

Введение

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

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

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

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

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

.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.

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

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

Tls-клиент с гост

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

Внедрить tls c гост? легко!

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

Также на данной странице представлена информацию об услугах нашего удостоверяющего центра CryptoPro TLS-CA по выдаче сертификатов TLS →

Документация

Онлайн-версия руководства программиста доступна на нашем сайте.

Другие решения

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

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

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

Как настроить доверие к сертификату?

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

Классические пассивные usb-токены и смарт-карты

Большинство пользователей предпочитает быстрые, дешевые и удобные решения для хранения ключей. Как правило, предпочтение отдаётся токенам и смарт-картам без криптографических сопроцессоров. Как и в предыдущих версиях провайдера, в КриптоПро CSP 5.0 сохранена поддержка всех совместимых носителей производства компаний Актив, Аладдин Р.Д., Gemalto/SafeNet, Multisoft, NovaCard, Rosan, Alioth, MorphoKST и СмартПарк.

Кроме того, конечно, как и раньше поддерживаются способы хранения ключей в реестре Windows, на жестком диске, на флеш-накопителях на всех платформах.

Носители с неизвлекаемыми ключами и защищенным обменом сообщениями

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

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

Компании Актив, ИнфоКрипт и СмартПарк разработали новые защищенные токены, которые поддерживают данный протокол.

Поддерживаемые алгоритмы

В КриптоПро CSP 5.0 наряду с российскими реализованы зарубежные криптографические алгоритмы. Теперь пользователи имеют возможность использовать привычные носители ключей для хранения секретных ключей RSA и ECDSA.

Таблица алгоритмов, поддерживаемых разными версиями КриптоПро CSP.

Поддерживаемые технологии хранения ключей

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

Протокол tls: краткая справка

Протокол TLS (Transport Layer Security) является одним из наиболее популярных протоколов, предназначенных для установления защищенного канала связи в сети Интернет. Он основан на спецификации протокола SSL (Secure Sockets Layer) версии 3.0, но за время своего существования претерпел довольно много изменений.

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

Решения для мобильных устройств

КриптоПро предоставляет возможность встраивания поддержки отечественных криптоалгоритмов в ваше мобильное приложение при помощи КриптоПро CSP для операционных систем iOS и Android.

Кратко о решении:

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

В случае использования КриптоПро CSP версии 5.0 R2 встраивание не требует проведения тематических исследований. Для CSP 5.0 и более ранних версий требуются тематические исследования.

Решения для стационарных устройств

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

Кратко о решении:

Ниже представлена сравнительная таблица характеристик поддерживаемых браузеров. Прочерк в колонке «Cертификация» означает необходимость проведения тематических исследований.

Страница не найдена

Тестирование гост tls

КриптоПро TLS входит в состав КриптоПро CSP на всех ОС и не требует отдельной установки.

Для использования протокола TLS предварительно получите сертификат по шаблону «Сертификат пользователя УЦ». Это можно сделать на тестовом Удостоверяющем центре КриптоПро.

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

Дополнительные стенды для тестирования TLS.