Долгий путь от RFC 4357 к RFC 8645 или как управлять ключами шифрования

Как известно, управление ключами является одной из самых сложных задач в криптографии. Буквально на днях в качестве RFC 8645 ^[1] опубликован документ “Re-keying Mechanisms for Symmetric Keys” («Механизмы смены симметричных ключей»). Он является результатом двух с половиной лет работы исследовательской группы CFRG, определяющей развитие и использование криптографии в IETF, а в его основу легли многолетние исследования и опыт работы российских специалистов. Далее мы кратко расскажем в чем суть этого RFC и почему он получился именно таким.

Немного напугаем...

В 2016 г. двое французских исследователей из института Inria публикуют описание атаки Sweet32 ^[2]. Использованная ими идея до неприличия проста и основана на так называемой «задаче о днях рождения» ^[3]: если мы будем вычислять значения случайного отображения , то примерно через испытаний в получившейся последовательности хотя бы два значения совпадут. С точки зрения криптографии это означает, что блочным шифром с длиной блока бит нельзя шифровать на одном ключе больше блоков открытого текста.

Подробно данная атака уже рассматривалась на Хабре ^[4], здесь мы отметим лишь то, что авторы воспользовались тем, что некоторые широко используемые криптографические библиотеки не производили смену ключа сессии вовремя. Это позволило накапливать много данных и просто воспользоваться указанным вероятностным свойством в случае, если в соединении использовался блочный шифр с длиной блока 64 бита. Это сразу породило в околокриптографической среде серьезную истерику на тему необходимости срочнейшего отказа от таких шифров.

А в длине ли блока дело?

Действительно, стоит ли подвергать остракизму шифр только из-за того, что у него короткая длина блока: а что если периодически менять ключ? Это можно сделать с помощью так называемых функций выработки производного ключа (KDF ^[5], Key derivation function). Такие функции позволяют получить новые ключи на основе старых, сохраняя при этом свойство случайности ключей (см. например, вот эту статью ^[6]). Такие функции, например, определяются российскими рекомендациями по стандартизации P 1323565.1.022-2018 ^[7] и Р 50.1.113-2016 ^[8]. Однако есть одно «но»: это достаточно сложные и не очень быстрые преобразования, построенные на основе хэш-функций, которые существенно замедлят скорость шифрования.

Можно ли сделать что-то быстрее?

Такая попытка была предпринята в 2006 году в RFC 4357 ^[9], где был предложен механизм CryptoPro Key Meshing, вырабатывающий производный ключ за счет шифрования фиксированной константы блочным шифром в режиме простой замены.

Это был очень быстрый алгоритм, практически не оказывающий влияния на скорость шифрования и защищающий от таких нелепых ситуаций, как использованная в Sweet32, и также, например, от атак по побочным каналам. Однако в 2015 году на конференции Рускрипто было показано ^[10], что такое преобразование уменьшает мощность ключевого множества, т.е. с каждым новой сменой ключа число его возможных вариантов выбора ключа уменьшается. Автор отмечал, что это не оказывало сколь-нибудь значимого влияния на безопасность, но тем не менее стало интересно, можно ли сделать ещё лучше.

Оказалось, не все так просто

К сожалению, чудес не бывает, и предложить быстрый механизм, сравнимый с обычными KDF не удается, однако мы можем доказать безопасность ^[11] несколько модифицированных схем типа указанного Key Meshing для каждого конкретного режима шифрования. Именно такие механизмы были предложены и ">обоснованы ^[11] для широко используемого режима гаммирования CTR (CTR-ACPKM, Advance Cryptographic Prolongation of Key Material) и выработки имитовставки ОМАС (OMAC-ACPKM) из отечественного стандарта ГОСТ Р 34.13-2015.

Оценки безопасности для этих режимов получены с использованием аппарата т.н. «доказуемой стойкости» ^[12].

Эти режимы были приняты в России в качестве рекомендаций по стандартизации Р 1323565.1.017-2018 ^[13].

Именно этот способ работы с ключами позволяет криптосредствам, реализующим российские криптонаборы TLS 1.2 (определенные в рекомендациях по стандартизации Р 1323565.1.020-2018 ^[14]), соответствовать российским требованиям по криптографической защите для высоких классов.

Работа в IETF

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

Разработка соответствующего документа, который впоследствии стал RFC 8645, по поручению председателей CFRG Кенни Патерсона и Алексея Мельникова проведена международной группой экспертов, возглавляемой Станиславом Смышляевым. Вклад в разработку итогового документа внесли Евгений Алексеев, Екатерина Смышляева и Лилия Ахметзянова (КриптоПро), Шэй Гуерон (Университет Хайфы), Дэниэл Фокс Франке (Akamai Technologies), а также экс-руководитель IETF Расс Хаусли (Vigil Security); на различных этапах к работе подключались такие крупные специалисты как Михир Белларе (Университет Калифорнии), Скотт Флюрер (Cisco), Йоав Нир (Checkpoint), Дмитрий Белявский (Криптоком) и Пол Хоффман (ICANN).

По сравнению с российскими рекомендациями в этот RFC добавлены ACPKM-механизмы для таких режимов как CBC, CFB и GCM, что, как вы уже наверное поняли, потребовало проведения отдельных доказательств. ^[15]

Резюме

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

Автор: ru_crypt

Источник ^[16]