Перейти к содержанию

Key derivation function

Материал из BitcoinWiki

Функция выработки ключа (KDF) — это криптографический алгоритм, который извлекает один или несколько наборов ключевого материала из существующего секрета, такого как общий ключ, результат согласования ключей или пароль, вместе с контекстной информацией и другими параметрами.[1] KDF позволяют протоколу превращать один секрет в ключи необходимой длины и назначать отдельные ключи для разных целей.

Этот термин охватывает два родственных, но различных класса. А KDF на основе ключей начинается с входных данных, которые уже обладают значительной криптографической стойкостью. А KDF на основе пароля начинается с пароля или кодовой фразы, выбранного человеком, и намеренно увеличивает стоимость проверки предположений. Их путаница может привести к небезопасной конструкции: быстрый общий KDF не делает слабый пароль устойчивым к подбору в автономном режиме.

Схема функции выработки ключа

Вывод на основе ключей

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

NIST SP 800-108 определяет конструкции счетчика, обратной связи и двухконвейера, основанные на псевдослучайных функциях, включая HMAC, CMAC и KMAC.[2] Точная конструкция и ее входные данные являются частью спецификации протокола; простое хеширование секрета без разделения доменов может не обеспечить требуемых свойств.

Извлечь и расширить

HKDF — это KDF на основе HMAC, стандартизированный в RFC 5869. Он соответствует извлечь-затем-развернуть дизайн. На этапе извлечения потенциально неоднородный входной ключевой материал преобразуется в псевдослучайный ключ фиксированной длины. На этапе расширения выводятся один или несколько выходных данных, привязывая дополнительную контекстную информацию.[3]

HKDF предназначен для материалов криптографического ключа, таких как результат Диффи-Хеллмана. Это намеренно эффективно и не является заменой схемы хеширования паролей, когда входные данные можно угадать из небольшого словаря.

Деривация на основе пароля

KDF на основе пароля объединяет пароль с параметрами соли и стоимости. Соль обычно хранится вместе с результатом и не обязательно должна быть секретной. Его цель — заставить одинаковые пароли выдавать разные выходные данные и предотвратить повторное использование одной предварительно вычисленной таблицы во многих записях. Фактор работы делает каждую догадку более дорогостоящей как для легальной системы, так и для злоумышленника.[4]

PBKDF2 многократно применяет псевдослучайную функцию и определяется стандартами PKCS #5 и NIST. Его основная регулируемая стоимость — это количество итераций. Этот параметр должен быть выбран для приложения и оборудования и со временем должен увеличиваться, если позволяет совместимость; не существует постоянного количества итераций, подходящего для каждой системы.

Современные схемы хеширования паролей также могут требовать настраиваемого расхода памяти. Функции, ориентированные на память, направлены на то, чтобы сделать крупномасштабное угадывание дорогостоящим не только для операций процессора, но также для памяти и пропускной способности. scrypt, Argon2 и Lyra2 являются примерами конструкций этого семейства. В RFC 9106 указан Argon2 и рекомендуется гибридный вариант Argon2id для общего хеширования паролей с профилями, выбранными в соответствии с доступной памятью и задержкой.[5]

Использование

KDF используются для:

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

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

Соображения безопасности

Безопасность KDF зависит от силы его входных данных, конструкции, выбора параметров и привязки контекста. KDF не может создать энтропию, отсутствующую в угадываемом пароле. Соли предотвращают предварительные вычисления перекрестных записей, но их не нужно угадывать, и они сами по себе не замедляют целевую атаку.

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

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

Стандарты и историческое развитие

Раннее хранилище паролей Unix было важным предшественником современных KDF на основе паролей. В отчете Роберта Морриса и Кена Томпсона 1979 года описывается склеп дизайн, который использовал первые восемь символов пароля в качестве ключа, применял модифицированное вычисление DES 25 раз и выбирал один из 4096 вариантов с 12-битной солью.[6] Соль препятствовала повторному использованию одного предварительно вычисленного словаря для всех учетных записей, в то время как повторные вычисления увеличивали стоимость каждого предположения на современном оборудовании. Фиксированные ограничения и увеличение вычислительной мощности в конечном итоге сделали эту схему непригодной для современной защиты паролем.

Позже в хэшах паролей появились регулируемые параметры стоимости и более сильные примитивы. Bcrypt добавил адаптируемый рабочий фактор в 1990-х годах; в scrypt добавлена ​​настраиваемая стоимость памяти; и Конкурс хеширования паролей выбрал Argon2, уделив особое внимание Catena, Lyra2, Makwa и Yescrypt.[7] Эти функции не являются взаимозаменяемыми только потому, что каждая из них может обрабатывать пароль: приложения должны следовать правилам кодирования, параметров и миграции выбранной функции.

NIST SP 800-132 определяет разработку на основе PBKDF2 для защиты хранимых данных и содержит уведомление о том, что NIST планирует пересмотреть публикацию.[8] Текущее руководство NIST по цифровой идентификации требует хеширования соленого пароля с помощью подходящей схемы и рекомендует функцию жесткой памяти. Эти требования применяются к средствам проверки паролей; их не следует обобщать до утверждения, что каждый криптографический KDF должен быть медленным или требовательным к памяти.[9]

Ссылки