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


Протокол TLS


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


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


Новые криптонаборы: кто они такие и зачем нужны?


В 2015 году вышли новые стандарты ГОСТ Р 34.12–2015 и ГОСТ Р 34.13–2015, которые описывают два алгоритма блочного шифрования Кузнечик и Магма, а также режимы их работы. Вследствие этого возникла необходимость интеграции данных алгоритмов в новые криптонаборы, которые бы соответствовали версии протокола TLS 1.2. Также одной из важных задач, стоявших перед авторами документа, являлось создание русскоязычного полного и самодостаточного описания одного из самых больших и сложных для понимания современных сетевых протоколов. И эту задачу решить удалось.


Разрабатываемый проект рекомендаций определяет два новых криптонабора:


  • TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC;
  • TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC.

Первый базируется на использовании блочного шифра Кузнечик, второй — на использовании
блочного шифра Магма.


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


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


Основные принципы работы протокола Рукопожатия в новых криптонаборах почти не изменились по сравнению с предыдущей версией отечественных криптонаборов. Коротко, основной секретный параметр — premaster secret (PMS) — вырабатывается клиентом и передается серверу зашифрованным с помощью его открытого ключа. Аутентификация сервера осуществляется за счет факта корректного извлечения сервером секретного значения PMS с помощью своего закрытого ключа. Клиент, если это требуется, аутентифицируется с помощью подписи.


Основные криптографические нововведения в протокол Рукопожатия состоят в следующем:


  • используется новый алгоритм шифрования PMS, так называемый алгоритм экспорта ключа, основанный на новых шифрах и режимах их работы (определяется в рамках другого нового документа);
  • сессионный секрет — master secret (MS) — теперь привязывается не только к случайным значениям сторон, передаваемым в сообщениях приветствия, но и ко всем сообщениям, переданным до момента его генерации. Главное здесь то, что значение MS теперь зависит от сертификата сервера, что позволяет противостоять атаке Triple Handshake. Данное нововведение соответствует рекомендациям RFC 7627.

В противовес протоколу Рукопожатия протокол Записей не похож ни на свой аналог из предыдущей версии отечественных рекомендаций, ни на зарубежные версии. В нем реализованы все передовые достижения, касающиеся задач обеспечения защищенного канала связи и минимизации нагрузки на ключ (то есть количества данных, обрабатываемых на одном ключе). Ключи, участвующие в защите данных, образуют иерархию (корневой ключ, ключи промежуточных уровней, ключи обработки сообщений и секционные ключи), которая позволяет увеличивать количество обрабатываемых сообщений, оставаясь в рамках безопасной нагрузки на ключ. Создание такой иерархии достигается за счет использования механизмов внешнего и внутреннего преобразования ключей (external и internal re-keying), положительные свойства которых доказаны в ряде работ как зарубежных (см. работу Абдалы и Беллара), так и отечественных криптографов (см. здесь и здесь). Эти механизмы реализуются посредством применения режима шифрования CTR-ACPKM и функции диверсификации ключей TLSTREE. Упомянутые подходы к уменьшению нагрузки на ключ описаны в драфте RFC, также разрабатываемого сейчас под руководством отечественных специалистов.


Заключение


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


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


Стоит также отметить, что ближайшими планами экспертов рабочей группы технического комитета 26 (ТК26) является начало разработки следующего проекта рекомендаций, посвящённого криптонаборам, соответствующим версии TLS 1.3. Работа над данным документом начнется сразу после утверждения в TK26 текущего проекта для TLS 1.2, а также после выхода нового RFC для TLS 1.3.

Комментарии (6)


  1. chemtech
    01.11.2017 13:51

    Может знаете, планируется ли какие-нибудь компаниями добавление ГОСТ Р 34.12–2015 и ГОСТ Р 34.13–2015 в OpenSSL?


    1. vektory79
      01.11.2017 15:53

      Поддерживаю вопрос и хочу уточнить. Не в какой-нибудь форк, а в основную ветку OpenSSL. Ну и стандартные, не форкнутые, браузеры тоже интересуют. И под Linux тоже.


    1. deemru
      01.11.2017 18:43

      Планируется. Как только, так сразу.


      Однако это станет возможным только по завершению всех согласований на уровне ТК26 и определению номеров сюит, например 0xFF88 и 0xFF89 для Магмы и Кузнечика соответственно.


      Тогда можно начать вносить необходимые изменения в основную ветку OpenSSL: https://github.com/openssl/openssl/blob/26a7d938c9bf932a55cb5e4e02abb48fe395c5cd/ssl/s3_lib.c#L2660


      Как только в OpenSSL появятся все необходимые идентификаторы, сразу выкатим обновлённую engine: https://www.cryptopro.ru/forum2/default.aspx?g=posts&m=84584#post84584


      1. VasiliyKudryavtsev
        01.11.2017 19:27

        А скажите, пожалуйста, доработка в NSS планируется?


        1. deemru
          02.11.2017 10:46

          NSS завязан на PKCS11, а рабочая группа по этому стандарту в ТК26 гораздо менее активна, да и NSS всё менее актуален, поэтому доработки в любом случае планируются, но с минимальным приоритетом. Даже так: если нас не пинать, вряд ли будет выхлоп.


  1. newpavlov
    02.11.2017 00:50

    Немного не в тему, но планируется ли патчить Стрибог? А то вот этой статье уже 3 года, но об обновлении стандарта ничего не слышно.