О документе
Internet Engineering Task Force (IETF) H. Krawczyk
Request for Comments: 5869 IBM Research
Category: Informational P. Eronen
ISSN: 2070-1721 Nokia
May 2010
HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
1. Введение
Функция выведения ключей (KDF) является базовым и существенным
компонентом криптографических систем. Её цель — взять некоторый
источник исходного ключевого материала и вывести из него один или
несколько криптографически стойких секретных ключей.
Этот документ определяет простую KDF на основе HMAC [HMAC] с именем
HKDF, которую можно использовать как строительный блок в различных
протоколах и приложениях и которая уже используется в нескольких
протоколах IETF, включая [IKEv2], [PANA] и [EAP-AKA]. Цель состоит в
том, чтобы документировать эту KDF общим образом для облегчения её
внедрения в будущих протоколах и приложениях, а также препятствовать
распространению множества механизмов KDF. Этот документ не
предназначен как призыв изменять существующие протоколы и не изменяет
и не обновляет существующие спецификации, использующие эту KDF.
HKDF следует парадигме «извлечение, затем расширение», в которой KDF
логически состоит из двух модулей. Первый этап принимает входной
ключевой материал и «извлекает» из него псевдослучайный ключ K
фиксированной длины. Второй этап «расширяет» ключ K в несколько
дополнительных псевдослучайных ключей (выход KDF).
Во многих приложениях входной ключевой материал не обязательно
распределён равномерно, и атакующий может иметь некоторое частичное
знание о нём (например, значение Diffie-Hellman, вычисленное
протоколом обмена ключами) или даже частичный контроль над ним (как
в некоторых приложениях сбора энтропии). Поэтому цель этапа
«извлечения» состоит в том, чтобы «сконцентрировать» возможно
рассеянную энтропию входного ключевого материала в короткий, но
криптографически стойкий псевдослучайный ключ. В некоторых
приложениях вход уже может быть хорошим псевдослучайным ключом; в
таких случаях этап «извлечения» не нужен, и можно использовать одну
только часть «расширения».
Второй этап «расширяет» псевдослучайный ключ до требуемой длины;
количество и длины выходных ключей зависят от конкретных
криптографических алгоритмов, для которых требуются ключи.
Обратите внимание, что некоторые существующие спецификации KDF, такие
как NIST Special Publication 800-56A [800-56A], NIST Special
Publication 800-108 [800-108] и IEEE Standard 1363a-2004 [1363a],
либо рассматривают только второй этап (расширение псевдослучайного
ключа), либо явно не различают этапы «извлечения» и «расширения»,
что часто приводит к недостаткам проектирования. Цель этой
спецификации — удовлетворить широкий диапазон требований к KDF при
минимизации предположений о базовой хеш-функции. Парадигма
«извлечение, затем расширение» хорошо поддерживает эту цель (более
подробную информацию об обосновании проектирования см. в
[HKDF-paper]).
2. Функция выведения ключей на основе HMAC (HKDF)
2.1. Обозначения
HMAC-Hash обозначает функцию HMAC [HMAC], инстанцированную с
хеш-функцией 'Hash'. HMAC всегда имеет два аргумента: первый является
ключом, а второй — входом (или сообщением). (Обратите внимание, что
на этапе извлечения 'IKM' используется как вход HMAC, а не как ключ
HMAC.)
Когда сообщение состоит из нескольких элементов, мы используем
конкатенацию (обозначаемую |) во втором аргументе; например,
HMAC(K, elem1 | elem2 | elem3).
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «ТРЕБУЕТСЯ
(REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)», «СЛЕДУЕТ
(SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «РЕКОМЕНДУЕТСЯ (RECOMMENDED)»,
«МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО (OPTIONAL)» в этом документе следует
толковать так, как описано в [KEYWORDS].
2.2. Шаг 1: Извлечение
HKDF-Extract(salt, IKM) -> PRK
Параметры:
Hash хеш-функция; HashLen обозначает длину выхода
хеш-функции в октетах
Входы:
salt необязательное значение соли (несекретное случайное
значение); если оно не предоставлено, ему присваивается
строка из HashLen нулей.
IKM входной ключевой материал
Выход:
PRK псевдослучайный ключ (из HashLen октетов)
Выход PRK вычисляется следующим образом:
PRK = HMAC-Hash(salt, IKM)
2.3. Шаг 2: Расширение
HKDF-Expand(PRK, info, L) -> OKM
Параметры:
Hash хеш-функция; HashLen обозначает длину выхода
хеш-функции в октетах
Входы:
PRK псевдослучайный ключ длиной не менее HashLen октетов
(обычно выход этапа извлечения)
info необязательная контекстная и специфичная для приложения
информация (может быть строкой нулевой длины)
L длина выходного ключевого материала в октетах
(<= 255*HashLen)
Выход:
OKM выходной ключевой материал (из L октетов)
Выход OKM вычисляется следующим образом:
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
где:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...
(где константа, конкатенируемая с концом каждого T(n), является
одним октетом.)
3. Примечания для пользователей HKDF
Этот раздел содержит набор руководящих принципов относительно
использования HKDF. Значительно более подробное изложение таких
принципов и обоснования проектирования можно найти в [HKDF-paper].
3.1. Использовать соль или не использовать соль
HKDF определена для работы как со случайной солью, так и без неё. Это
сделано для учёта приложений, в которых значение соли недоступно. Мы,
однако, подчёркиваем, что использование соли значительно усиливает
HKDF, обеспечивая независимость между различными применениями
хеш-функции, поддерживая извлечение, «независимое от источника», и
усиливая аналитические результаты, на которых основана конструкция
HKDF.
Случайная соль принципиально отличается от исходного ключевого
материала в двух отношениях: она не является секретной и может
повторно использоваться. Поэтому значения соли доступны многим
приложениям. Например, генератор псевдослучайных чисел (PRNG),
непрерывно производящий выходы путём применения HKDF к обновляемым
пулам энтропии (например, выборкам системных событий), может
зафиксировать значение соли и использовать его для нескольких
применений
HKDF, не защищая секретность соли. В другой области применения
протокол согласования ключей, выводящий криптографические ключи из
обмена Diffie-Hellman, может вывести значение соли из открытых
одноразовых чисел, которыми обмениваются и которые аутентифицируют
взаимодействующие стороны как часть согласования ключей (этот подход
принят в [IKEv2]).
В идеале значение соли является случайной (или псевдослучайной)
строкой длины HashLen. Однако даже значение соли более низкого
качества (меньшего размера или с ограниченной энтропией) всё ещё
может вносить значительный вклад в безопасность выходного ключевого
материала; поэтому разработчикам приложений рекомендуется
предоставлять HKDF значения соли, если приложение может получить
такие значения.
Следует отметить, что, хотя это и не типичный случай, некоторые
приложения могут даже иметь доступное для использования секретное
значение соли; в таком случае HKDF предоставляет ещё более сильную
гарантию безопасности. Примером такого приложения является IKEv1 в
его «режиме шифрования с открытым ключом», где «соль» для экстрактора
вычисляется из секретных одноразовых чисел; аналогично, режим с
предварительно распределённым ключом IKEv1 использует секретную соль,
выведенную из предварительно распределённого ключа.
3.2. Вход 'info' в HKDF
Хотя значение 'info' является необязательным в определении HKDF, оно
часто имеет большое значение в приложениях. Его главная цель —
привязать выведенный ключевой материал к специфичной для приложения
и контекста информации. Например, 'info' может содержать номер
протокола, идентификаторы алгоритмов, идентификаторы пользователей и
т. д. В частности, оно может предотвратить выведение одного и того
же ключевого материала для разных контекстов (когда в таких разных
контекстах используется один и тот же входной ключевой материал
(IKM)). Оно также может включать дополнительные входы в часть
расширения ключа, если это желательно (например, приложение может
захотеть привязать ключевой материал к его длине L, тем самым сделав
L частью поля 'info'). К 'info' предъявляется одно техническое
требование: оно должно быть независимо от значения входного ключевого
материала IKM.
3.3. Пропускать или не пропускать
В некоторых приложениях входной ключевой материал IKM уже может
присутствовать в виде криптографически стойкого ключа (например,
предварительный главный секрет в наборах шифров TLS RSA был бы
псевдослучайной строкой, за исключением первых двух октетов). В этом
случае можно пропустить часть извлечения и использовать IKM напрямую
как ключ HMAC на этапе расширения. С другой стороны, приложения всё
ещё могут использовать часть извлечения ради совместимости с общим
случаем. В частности, если IKM случаен (или псевдослучаен), но длиннее
ключа HMAC, этап извлечения может служить для вывода подходящего ключа
HMAC (в случае HMAC
это сокращение посредством экстрактора не является строго
необходимым, поскольку HMAC также определён для работы с длинными
ключами). Однако обратите внимание: если IKM является значением
Diffie-Hellman, как в случае TLS с Diffie-Hellman, то часть извлечения
НЕ СЛЕДУЕТ (SHOULD NOT) пропускать. В противном случае само значение
Diffie-Hellman g^{xy} (которое НЕ является равномерно случайной или
псевдослучайной строкой) использовалось бы как ключ PRK для HMAC.
Вместо этого HKDF следует применить этап извлечения к g^{xy}
(предпочтительно со значением соли) и использовать полученный PRK как
ключ для HMAC в части расширения.
В случае, когда количество требуемых битов ключа L не превышает
HashLen, можно было бы использовать PRK напрямую как OKM. Однако это
НЕ СЛЕДУЕТ (NOT RECOMMENDED) делать, особенно потому, что при этом
исключалось бы использование 'info' как части процесса выведения (а
добавлять 'info' как вход на этапе извлечения не рекомендуется — см.
[HKDF-paper]).
3.4. Роль независимости
Анализ функций выведения ключей предполагает, что входной ключевой
материал (IKM) поступает из некоторого источника, моделируемого как
вероятностное распределение по битовым потокам определённой длины
(например, потоки, создаваемые пулом энтропии, значения, выведенные
из случайно выбранных показателей Diffie-Hellman, и т. д.); каждый
экземпляр IKM является выборкой из этого распределения. Главная цель
функций выведения ключей состоит в том, чтобы гарантировать, что при
применении KDF к любым двум значениям IKM и IKM', выбранным из
(одинакового) распределения источника, получающиеся ключи OKM и OKM'
по существу независимы друг от друга (в статистическом или
вычислительном смысле). Для достижения этой цели важно, чтобы входы
KDF выбирались из подходящих входных распределений, а также чтобы
входы выбирались независимо друг от друга (технически необходимо,
чтобы каждая выборка имела достаточную энтропию даже при
обусловливании другими входами KDF).
Независимость также является важным свойством значения salt,
предоставляемого KDF. Хотя значение salt не требуется держать в секрете
и одно и то же значение salt может использоваться с несколькими
значениями IKM, предполагается, что значения salt независимы от входного
ключевого материала. В частности, приложению необходимо обеспечить,
чтобы значения salt не выбирались атакующим и не подвергались им
манипуляциям. В качестве примера рассмотрим случай (как в IKE), когда
salt выводится из nonce, предоставленных сторонами в протоколе обмена
ключами. Прежде чем протокол сможет использовать такой salt для выведения
ключей, ему необходимо удостовериться, что эти nonce аутентифицированы
как поступившие от законных сторон, а не выбранные атакующим (например,
в IKE эта аутентификация является неотъемлемой частью
аутентифицированного обмена Diffie-Hellman).
4. Применения HKDF
HKDF предназначена для использования в широком разнообразии применений
KDF. К ним относятся построение псевдослучайных генераторов из
несовершенных источников случайности (таких как физический генератор
случайных чисел (RNG)); получение псевдослучайности из слабых источников
случайности, таких как энтропия, собранная из системных событий, нажатий
клавиш пользователя и т. д.; выведение криптографических ключей из
общего значения Diffie-Hellman в протоколе согласования ключей; выведение
симметричных ключей из гибридной схемы шифрования с открытым ключом;
выведение ключей для механизмов обёртывания ключей; и другое. Все эти
применения могут извлечь пользу из простоты и многоцелевого характера
HKDF, а также из её аналитического обоснования.
С другой стороны, предполагается, что некоторые приложения не смогут
использовать HKDF «как есть» из-за особых эксплуатационных требований
либо смогут её использовать, но без всех преимуществ схемы. Один
существенный пример — выведение криптографических ключей из источника с
низкой энтропией, такого как пароль пользователя. Шаг извлечения в HKDF
может концентрировать имеющуюся энтропию, но не может усиливать
энтропию. В случае KDF на основе паролей основная цель состоит в
замедлении словарных атак с помощью двух составляющих: значения salt и
преднамеренного замедления вычисления вывода ключа. HKDF естественным
образом поддерживает использование salt; однако механизм замедления не
является частью этой спецификации. Приложениям, заинтересованным в KDF
на основе пароля, следует рассмотреть, удовлетворяет ли, например,
[PKCS5] их потребностям лучше, чем HKDF.
5. Вопросы безопасности
Несмотря на простоту HKDF, при проектировании и анализе этой конструкции
были учтены многие соображения безопасности. Изложение всех этих аспектов
выходит за рамки данного документа. Подробную информацию, включая
обоснование проектирования и рекомендаций, представленных в разделе 3,
см. в [HKDF-paper].
В указанной выше работе [HKDF-paper] были приложены значительные усилия,
чтобы представить криптографический анализ HKDF как многоцелевой KDF,
при использовании которой криптографические хеш-функции применяются с
большой осторожностью. Это особенно важно из-за ограниченной уверенности
в стойкости современных хеш-функций. Однако этот анализ не подразумевает
абсолютную безопасность какой-либо схемы и в значительной степени зависит
от стойкости базовой хеш-функции и выбранных моделей. Тем не менее он
служит веским указанием на правильность структуры конструкции HKDF и её
преимущества перед другими распространёнными схемами KDF.
6. Благодарности
Авторы хотели бы поблагодарить участников списка CFRG (Crypto Forum
Research Group) за их полезные замечания, а также Дэна Harkins за
предоставление тестовых векторов.
7.1. Нормативные ссылки
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-3, October 2008.
7.2. Справочные ссылки
[1363a] Institute of Electrical and Electronics Engineers, "IEEE
Standard Specifications for Public-Key Cryptography -
Amendment 1: Additional Techniques", IEEE Std
1363a-2004, 2004.
[800-108] National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom
Functions", NIST Special Publication 800-108,
November 2008.
[800-56A] National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised)", NIST
Special Publication 800-56A, March 2007.
[EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, May 2009.
[HKDF-paper] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010
(to appear), 2010, <http://eprint.iacr.org/2010/264>.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, May 2008.
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
Приложение A. Тестовые векторы
В этом приложении приведены тестовые векторы для хеш-функций SHA-256 и
SHA-1 [SHS].
A.1. Тестовый случай 1
Базовый тестовый случай с SHA-256
Hash = SHA-256
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = 0x000102030405060708090a0b0c (13 octets)
info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
L = 42
PRK = 0x077709362c2e32df0ddc3f0dc47bba63
90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets)
OKM = 0x3cb25f25faacd57a90434f64d0362f2a
2d2d0a90cf1a5a4c5db02d56ecc4c5bf
34007208d5b887185865 (42 octets)
A.2. Тестовый случай 2
Тест с SHA-256 и более длинными входными/выходными данными
Hash = SHA-256
IKM = 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f
303132333435363738393a3b3c3d3e3f
404142434445464748494a4b4c4d4e4f (80 octets)
salt = 0x606162636465666768696a6b6c6d6e6f
707172737475767778797a7b7c7d7e7f
808182838485868788898a8b8c8d8e8f
909192939495969798999a9b9c9d9e9f
a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
e0e1e2e3e4e5e6e7e8e9eaebecedeeef
f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
L = 82
PRK = 0x06a6b88c5853361a06104c9ceb35b45c
ef760014904671014a193f40c15fc244 (32 octets)
OKM = 0xb11e398dc80327a1c8e7f78c596a4934
4f012eda2d4efad8a050cc4c19afa97c
59045a99cac7827271cb41c65e590e09
da3275600c2f09b8367793a9aca3db71
cc30c58179ec3e87c14c01d5c1f3434f
1d87 (82 octets)
A.3. Тестовый случай 3
Тест с SHA-256 и salt/info нулевой длины
Hash = SHA-256
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
PRK = 0x19ef24a32c717b167f33a91d6f648bdf
96596776afdb6377ac434c1c293ccb04 (32 octets)
OKM = 0x8da4e775a563c18f715f802a063c5a31
b8a11f5c5ee1879ec3454e5f3c738d2d
9d201395faa4b61a96c8 (42 octets)
A.4. Тестовый случай 4
Базовый тестовый случай с SHA-1
Hash = SHA-1
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets)
salt = 0x000102030405060708090a0b0c (13 octets)
info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets)
L = 42
PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets)
OKM = 0x085a01ea1b10f36933068b56efa5ad81
a4f14b822f5b091568a9cdd4f155fda2
c22e422478d305f3f896 (42 octets)
A.5. Тестовый случай 5
Тест с SHA-1 и более длинными входными/выходными данными
Hash = SHA-1
IKM = 0x000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f
202122232425262728292a2b2c2d2e2f
303132333435363738393a3b3c3d3e3f
404142434445464748494a4b4c4d4e4f (80 octets)
salt = 0x606162636465666768696a6b6c6d6e6f
707172737475767778797a7b7c7d7e7f
808182838485868788898a8b8c8d8e8f
909192939495969798999a9b9c9d9e9f
a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets)
info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9dadbdcdddedf
e0e1e2e3e4e5e6e7e8e9eaebecedeeef
f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets)
L = 82
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets)
OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb
ff6adcae899d92191fe4305673ba2ffe
8fa3f1a4e5ad79f3f334b3b202b2173c
486ea37ce3d397ed034c7f9dfeb15c5e
927336d0441f4c4300e2cff0d0900b52
d3b4 (82 octets)
A.6. Тестовый случай 6
Тест с SHA-1 и salt/info нулевой длины
Hash = SHA-1
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets)
OKM = 0x0ac1af7002b3d761d1e55298da9d0506
b9ae52057220a306e07b6b87e8df21d0
ea00033de03984d34918 (42 octets)
A.7. Тестовый случай 7
Тест с SHA-1, salt не предоставлен (по умолчанию HashLen нулевых
октетов), info нулевой длины
Hash = SHA-1
IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)
salt = not provided (defaults to HashLen zero octets)
info = (0 octets)
L = 42
PRK = 0x2adccada18779e7c2077ad2eb19d3f3e731385dd (20 octets)
OKM = 0x2c91117204d745f3500d636a62f64f0a
b3bae548aa53d423b0d1f27ebba6f5e5
673a081d70cce7acfc48 (42 octets)