Долгий путь от RFC 4357 к RFC 8645 или как управлять ключами шифрования
Как известно, управление ключами является одной из самых сложных задач в криптографии. Буквально на днях в качестве RFC 8645 опубликован документ «Re-keying Mechanisms for Symmetric Keys» («Механизмы смены симметричных ключей»). Он является результатом двух с половиной лет работы исследовательской группы CFRG, определяющей развитие и использование криптографии в IETF, а в его основу легли многолетние исследования и опыт работы российских специалистов. Далее мы кратко расскажем в чем суть этого RFC и почему он получился именно таким.
Немного напугаем…
В 2016 г. двое французских исследователей из института Inria публикуют описание атаки Sweet32. Использованная ими идея до неприличия проста и основана на так называемой «задаче о днях рождения»: если мы будем вычислять значения случайного отображения 
, то примерно через 
испытаний в получившейся последовательности хотя бы два значения совпадут. С точки зрения криптографии это означает, что блочным шифром с длиной блока 
бит нельзя шифровать на одном ключе больше блоков открытого текста.
Подробно данная атака уже рассматривалась на Хабре, здесь мы отметим лишь то, что авторы воспользовались тем, что некоторые широко используемые криптографические библиотеки не производили смену ключа сессии вовремя. Это позволило накапливать много данных и просто воспользоваться указанным вероятностным свойством в случае, если в соединении использовался блочный шифр с длиной блока 64 бита. Это сразу породило в околокриптографической среде серьезную истерику на тему необходимости срочнейшего отказа от таких шифров.
А в длине ли блока дело?
Действительно, стоит ли подвергать остракизму шифр только из-за того, что у него короткая длина блока:, а что если периодически менять ключ? Это можно сделать с помощью так называемых функций выработки производного ключа (KDF, Key derivation function). Такие функции позволяют получить новые ключи на основе старых, сохраняя при этом свойство случайности ключей (см. например, вот эту статью). Такие функции, например, определяются российскими рекомендациями по стандартизации P 1323565.1.022–2018 и Р 50.1.113–2016. Однако есть одно «но»: это достаточно сложные и не очень быстрые преобразования, построенные на основе хэш-функций, которые существенно замедлят скорость шифрования.
Можно ли сделать что-то быстрее?
Такая попытка была предпринята в 2006 году в RFC 4357, где был предложен механизм CryptoPro Key Meshing, вырабатывающий производный ключ за счет шифрования фиксированной константы блочным шифром в режиме простой замены.
Это был очень быстрый алгоритм, практически не оказывающий влияния на скорость шифрования и защищающий от таких нелепых ситуаций, как использованная в Sweet32, и также, например, от атак по побочным каналам. Однако в 2015 году на конференции Рускрипто было показано, что такое преобразование уменьшает мощность ключевого множества, т.е. с каждым новой сменой ключа число его возможных вариантов выбора ключа уменьшается. Автор отмечал, что это не оказывало сколь-нибудь значимого влияния на безопасность, но тем не менее стало интересно, можно ли сделать ещё лучше.
Оказалось, не все так просто
К сожалению, чудес не бывает, и предложить быстрый механизм, сравнимый с обычными KDF не удается, однако мы можем доказать безопасность несколько модифицированных схем типа указанного Key Meshing для каждого конкретного режима шифрования. Именно такие механизмы были предложены и »>обоснованы для широко используемого режима гаммирования CTR (CTR-ACPKM, Advance Cryptographic Prolongation of Key Material) и выработки имитовставки ОМАС (OMAC-ACPKM) из отечественного стандарта ГОСТ Р 34.13–2015.
Оценки безопасности для этих режимов получены с использованием аппарата т.н. «доказуемой стойкости».
Эти режимы были приняты в России в качестве рекомендаций по стандартизации Р 1323565.1.017–2018 .
Именно этот способ работы с ключами позволяет криптосредствам, реализующим российские криптонаборы TLS 1.2 (определенные в рекомендациях по стандартизации Р 1323565.1.020–2018), соответствовать российским требованиям по криптографической защите для высоких классов.
Работа в IETF
Разработанные механизмы как нельзя лучше пришлись в качестве ответа на упомянутую в начале заметки дискуссию о том, быть ли шифрам с короткой длиной блока или нет.
Разработка соответствующего документа, который впоследствии стал RFC 8645, по поручению председателей CFRG Кенни Патерсона и Алексея Мельникова проведена международной группой экспертов, возглавляемой Станиславом Смышляевым. Вклад в разработку итогового документа внесли Евгений Алексеев, Екатерина Смышляева и Лилия Ахметзянова (КриптоПро), Шэй Гуерон (Университет Хайфы), Дэниэл Фокс Франке (Akamai Technologies), а также экс-руководитель IETF Расс Хаусли (Vigil Security); на различных этапах к работе подключались такие крупные специалисты как Михир Белларе (Университет Калифорнии), Скотт Флюрер (Cisco), Йоав Нир (Checkpoint), Дмитрий Белявский (Криптоком) и Пол Хоффман (ICANN).
По сравнению с российскими рекомендациями в этот RFC добавлены ACPKM-механизмы для таких режимов как CBC, CFB и GCM, что, как вы уже наверное поняли, потребовало проведения отдельных доказательств.
Резюме
Как уже было отмечено, не смотря на то, что предложенный подход в некотором смысле не универсален и требует проведения отдельных обоснований безопасности для каждого отдельного режима, в награду мы получаем высокую скорость, безопасность от атак типа Sweet32 и, что не маловажно, от атак по побочным каналам.
