HMAC

Алгоритм аутентификации компьютерных коммуникаций

Генерация HMAC-SHA1

В криптографии HMAC (иногда расширяемый как keyed-hash message authentication code или hash -based message authentication code ) — это особый тип кода аутентификации сообщений (MAC), включающий криптографическую хэш-функцию и секретный криптографический ключ. Как и любой MAC, он может использоваться для одновременной проверки как целостности данных , так и подлинности сообщения. HMAC — это тип keyed hash function, который также может использоваться в схеме вывода ключа или схеме растяжения ключа.

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

Подробности

Любая криптографическая хэш-функция, например SHA-2 или SHA-3 , может использоваться при вычислении HMAC; полученный алгоритм MAC называется HMAC- x , где x — используемая хэш-функция (например, HMAC-SHA256 или HMAC-SHA3-512). Криптографическая стойкость HMAC зависит от криптографической стойкости базовой хэш-функции, размера ее хэш-вывода, а также размера и качества ключа. ^[1]

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

Итеративная хэш-функция (использующая конструкцию Меркла–Дамгарда ) разбивает сообщение на блоки фиксированного размера и перебирает их с помощью функции сжатия . Например, SHA-256 работает с 512-битными блоками. Размер выходных данных HMAC такой же, как и у базовой хэш-функции (например, 256 и 512 бит в случае SHA-256 и SHA3-512 соответственно), хотя при желании его можно усечь.

HMAC не шифрует сообщение. Вместо этого сообщение (зашифрованное или нет) должно быть отправлено вместе с хешем HMAC. Стороны с секретным ключом снова хешируют сообщение, и если оно подлинное, полученные и вычисленные хеши будут совпадать.

Определение и анализ конструкции HMAC были впервые опубликованы в 1996 году в статье Михира Белларе , Рана Канетти и Хьюго Кравчика , ^{[1] [2]} , а также они написали RFC 2104 в 1997 году. ^{[3] : §2} В статье 1996 года также определен вложенный вариант, называемый NMAC (Nested MAC). FIPS PUB 198 обобщает и стандартизирует использование HMAC. ^[4] HMAC используется в протоколах IPsec , ^[2] SSH и TLS , а также для JSON Web Tokens .

Определение

Это определение взято из RFC 2104:

${\displaystyle {\begin{aligned}\operatorname {HMAC} (K,m)&=\operatorname {H} {\Bigl (}{\bigl (}K'\oplus opad{\bigr )}\parallel \operatorname {H} {\bigl (}\left(K'\oplus ipad\right)\parallel m{\bigr )}{\Bigr )}\\K'&={\begin{cases}\operatorname {H} \left(K\right)&{\text{if}}\ K{\text{ is larger than block size}}\\K&{\text{otherwise}}\end{cases}}\end{aligned}}}$

где

${\displaystyle \operatorname {H} }$представляет собой криптографическую хеш-функцию.

${\displaystyle m}$сообщение, которое должно быть аутентифицировано.

${\displaystyle K}$это секретный ключ.

${\displaystyle K'}$представляет собой ключ размером с блок, полученный из секретного ключа K ; либо путем дополнения справа нулями до размера блока, либо путем хеширования до значения, меньшего или равного размеру блока, а затем путем дополнения справа нулями.

${\displaystyle \parallel }$обозначает конкатенацию .

${\displaystyle \oplus }$обозначает побитовое исключающее ИЛИ (XOR).

${\displaystyle opad}$представляет собой внешнее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x5c.

${\displaystyle ipad}$представляет собой внутреннее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x36. ^{[3] : §2}

Выполнение

Следующий псевдокод демонстрирует, как может быть реализован HMAC. Размер блока составляет 512 бит (64 байта) при использовании одной из следующих хэш-функций: SHA-1, MD5, RIPEMD-128. ^{[3] : §2}

function hmac is  input: key: Байты  // Массив байтов message: Байты  // Массив байтов для хэширования hash: Функция // Используемая хэш-функция (например, SHA-1) blockSize: Целое число  // Размер блока хэш-функции (например, 64 байта для SHA-1) outputSize: Целое число  // Выходной размер хэш-функции (например, 20 байтов для SHA-1) // Вычислить ключ размера блока block_sized_key = computeBlockSizedKey(ключ, хэш, blockSize) o_key_pad ← block_sized_key xor [0x5c blockSize] // Внешняя клавиша с подкладкой i_key_pad ← block_sized_key xor [0x36 blockSize] // Внутренняя клавиша с подкладкой вернуть хэш(o_key_pad ∥ хэш(i_key_pad ∥ сообщение))Функция computeBlockSizedKey имеет  следующие входные данные: key: Байты  // Массив байтов hash: Функция // Используемая хэш-функция (например, SHA-1) blockSize: Целое число  // Размер блока хэш-функции (например, 64 байта для SHA-1)  // Ключи длиннее blockSize укорачиваются путем их хеширования  if (length(key) > blockSize) then ключ = хэш(ключ) // Ключи короче blockSize дополняются до blockSize нулями справа  if (length(key) < blockSize) then  return Pad(key, blockSize) // Дополняем ключ нулями, чтобы сделать его длиной blockSize байт возврат ключа

Принципы проектирования

Разработка спецификации HMAC была мотивирована существованием атак на более тривиальные механизмы объединения ключа с хэш-функцией. Например, можно предположить, что та же безопасность, которую обеспечивает HMAC, может быть достигнута с помощью MAC = H ( ключ ∥ сообщение ). Однако этот метод страдает от серьезного недостатка: с большинством хэш-функций легко добавить данные к сообщению, не зная ключа, и получить другой действительный MAC (« атака с удлинением длины »). Альтернатива, добавление ключа с помощью MAC = H ( сообщение ∥ ключ ), страдает от проблемы, что злоумышленник, который может найти коллизию в (неключевой) хэш-функции, имеет коллизию в MAC (поскольку два сообщения m1 и m2, дающие один и тот же хэш, предоставят одно и то же начальное условие хэш-функции до того, как добавленный ключ будет хэширован, следовательно, конечный хэш будет таким же). Использование MAC = H ( ключ ∥ сообщение ∥ ключ ) является более предпочтительным, однако различные документы по безопасности указывают на уязвимости при таком подходе, даже при использовании двух разных ключей. ^{[1] [7] [8]}

Не было обнаружено известных атак расширения против текущей спецификации HMAC, которая определяется как H ( key ∥ H ( key ∥ message )), поскольку внешнее применение хэш-функции маскирует промежуточный результат внутреннего хэша. Значения ipad и opad не являются критическими для безопасности алгоритма, но были определены таким образом, чтобы иметь большое расстояние Хэмминга друг от друга, и поэтому внутренние и внешние ключи будут иметь меньше общих битов. Снижение безопасности HMAC требует, чтобы они отличались хотя бы в одном бите. ^{[ необходима цитата ]}

Функция хэширования Keccak , выбранная NIST в качестве победителя конкурса SHA-3 , не нуждается в этом вложенном подходе и может использоваться для генерации MAC путем простого добавления ключа к сообщению, поскольку она не подвержена атакам с удлинением длины. ^[9]

Безопасность

Криптографическая стойкость HMAC зависит от размера секретного ключа, который используется, и безопасности базовой хэш-функции. Было доказано, что безопасность конструкции HMAC напрямую связана со свойствами безопасности используемой хэш-функции. Наиболее распространенной атакой на HMAC является грубая сила для раскрытия секретного ключа. HMAC значительно меньше подвержены коллизиям, чем их базовые алгоритмы хэширования. ^{[2] [10] [11]} В частности, Михир Беллар доказал, что HMAC является псевдослучайной функцией (PRF) при единственном предположении, что функция сжатия является PRF. ^[12] Следовательно, HMAC-MD5 не страдает от тех же недостатков, которые были обнаружены в MD5. ^[13]

RFC 2104 требует, чтобы «ключи длиннее B байтов сначала хэшировались с использованием H », что приводит к запутанной псевдоколлизии: если ключ длиннее размера хэш-блока (например, 64 байта для SHA-1), то HMAC(k, m)вычисляется как HMAC(H(k), m). Это свойство иногда упоминается как возможная слабость HMAC в сценариях хэширования паролей: было продемонстрировано, что можно найти длинную строку ASCII и случайное значение, хэш которого также будет строкой ASCII, и оба значения дадут одинаковый вывод HMAC. ^{[14] [15] [16]}

В 2006 году Чонсон Ким, Алекс Бирюков , Барт Пренил и Сокхи Хонг показали, как отличить HMAC с сокращенными версиями MD5 и SHA-1 или полными версиями HAVAL , MD4 и SHA-0 от случайной функции или HMAC со случайной функцией. Дифференциальные отличительные признаки позволяют злоумышленнику разработать атаку подделки на HMAC. Кроме того, дифференциальные и прямоугольные отличительные признаки могут привести к атакам второго прообраза . HMAC с полной версией MD4 можно подделать с помощью этих знаний. Эти атаки не противоречат доказательству безопасности HMAC, но дают представление о HMAC на основе существующих криптографических хэш-функций. ^[17]

В 2009 году Сяоюнь Ван и др. представили различающую атаку на HMAC-MD5 без использования связанных ключей. Она может отличить экземпляр HMAC с MD5 от экземпляра со случайной функцией с 2 ^​​97 запросами с вероятностью 0,87. ^[18]

В 2011 году был опубликован информационный RFC 6151, обобщающий соображения по безопасности в MD5 и HMAC-MD5. Для HMAC-MD5 RFC резюмирует, что – хотя безопасность самой хэш-функции MD5 серьезно скомпрометирована – известные в настоящее время «атаки на HMAC-MD5, похоже, не указывают на практическую уязвимость при использовании в качестве кода аутентификации сообщений» , но также добавляет, что «для новой разработки протокола набор шифров с HMAC-MD5 не должен быть включен» . ^[13]

В мае 2011 года был опубликован RFC 6234, в котором подробно описана абстрактная теория и исходный код для HMAC на основе SHA. ^[19]

Примеры

Вот некоторые значения HMAC, предполагающие 8-битный ASCII для входных данных и шестнадцатеричное кодирование для выходных данных:

HMAC_MD5("key", "Быстрая коричневая лиса перепрыгивает через ленивую собаку") = 80070713463e7749b90c2dc24911e275HMAC_SHA1("ключ", "Быстрая коричневая лиса перепрыгивает через ленивую собаку") = de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9HMAC_SHA256("ключ", "Быстрая коричневая лиса перепрыгивает через ленивую собаку") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8HMAC_SHA512("ключ", "Быстрая коричневая лиса перепрыгивает через ленивую собаку") = b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a

Смотрите также

• Одноразовый пароль на основе HMAC

Ссылки

1. Белларе, Михир ; Канетти, Ран; Кравчик, Хьюго (1996). «Ключевые хэш-функции для аутентификации сообщений» (PDF) . стр. 1–15. CiteSeerX  10.1.1.134.8430 .
2. Белларе, Михир; Канетти, Ран; Кравчик, Хьюго (весна 1996 г.). «Аутентификация сообщений с использованием хеш-функций — конструкция HMAC» (PDF) . Криптобайты . 2 (1).
3. H. Krawczyk; M. Bellare; R. Canetti (февраль 1997 г.). HMAC: Keyed-Hashing for Message Authentication. Сетевая рабочая группа. doi : 10.17487/RFC2104 . RFC 2104. Информационное. Обновлено RFC 6151.
4. "FIPS 198-1: Код аутентификации сообщений с хэш-ключом (HMAC)". Федеральные стандарты обработки информации . 16 июля 2008 г.
5. «FIPS 180-2 с уведомлением об изменении 1» (PDF) . csrc.nist.gov .
6. Дворкин, Моррис (4 августа 2015 г.). «Стандарт SHA-3: хэш на основе перестановок и расширяемые выходные функции». Федеральные стандарты обработки информации – через публикации NIST.
7. Preneel, Bart ; van Oorschot, Paul C. (1995). "MDx-MAC и построение быстрых MAC из хэш-функций". CiteSeerX 10.1.1.34.3855 .  {{cite journal}}: Цитировать журнал требует |journal=( помощь )
8. Пренил, Барт ; ван Оршот, Пол К. (1995). «О безопасности двух MAC-алгоритмов». CiteSeerX 10.1.1.42.8908 .  {{cite journal}}: Цитировать журнал требует |journal=( помощь )
9. Команда Keccak. "Keccak Team – Design and security" . Получено 31 октября 2019 г. В отличие от SHA-1 и SHA-2, Keccak не имеет слабости расширения длины, поэтому не нуждается во вложенной конструкции HMAC. Вместо этого вычисление MAC можно выполнить, просто добавив ключ к сообщению.
10. Шнайер, Брюс (август 2005 г.). "SHA-1 Broken" . Получено 9 января 2009 г. . хотя это не влияет на приложения, такие как HMAC, где коллизии не важны
11. H. Krawczyk; M. Bellare; R. Canetti (февраль 1997 г.). HMAC: Keyed-Hashing for Message Authentication. Сетевая рабочая группа. doi : 10.17487/RFC2104 . RFC 2104. Информационный. раздел 6. Обновлено RFC 6151. Самая сильная известная атака против HMAC основана на частоте коллизий для хэш-функции H («атака дня рождения») [PV,BCK2] и совершенно непрактична для минимально разумных хэш-функций.
12. Белларе, Михир. "Новые доказательства для NMAC и HMAC: безопасность без устойчивости к коллизиям" (PDF) . Журнал криптологии . Получено 15 декабря 2021 г. . В этой статье доказывается, что HMAC является PRF при единственном предположении, что функция сжатия является PRF. Это восстанавливает гарантию на основе доказательства, поскольку никакие известные атаки не ставят под угрозу псевдослучайность функции сжатия, а также помогает объяснить устойчивость к атакам, которую HMAC показал даже при реализации с хэш-функциями, чья (слабая) устойчивость к коллизиям скомпрометирована.
13. S. Turner; L. Chen (март 2011 г.). Обновленные соображения по безопасности для алгоритмов MD5 Message-Digest и HMAC-MD5. IETF . doi : 10.17487/RFC6151 . RFC 6151. Информационное. Обновления RFC 2104 и 1321.
14. "Объяснение коллизий хэшей PBKDF2+HMAC · Матиас Байнен". mathiasbynens.be . Получено 7 августа 2019 г. .
15. "Aaron Toponce: Breaking HMAC" . Получено 7 августа 2019 г.
16. "RFC 2104 Errata Held for Document Update · Erdem Memisyazici". www.rfc-editor.org . Получено 23 сентября 2016 г. .
17. Чонсон, Ким; Бирюков, Алекс; Пренил, Барт; Хонг, Сеохи (2006). «О безопасности HMAC и NMAC на основе HAVAL, MD4, MD5, SHA-0 и SHA-1» (PDF) . SCN 2006. Springer-Verlag.
18. Ван, Сяоюнь; Ю, Хунбо; Ван, Вэй; Чжан, Хайна; Жан, Тао (2009). «Криптоанализ HMAC/NMAC-MD5 и MD5-MAC» (PDF) . Проверено 15 июня 2015 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
19. Eastlake 3rd, D.; Hansen, T. (май 2011 г.). Безопасные алгоритмы хэширования в США (SHA и HMAC и HKDF на основе SHA). Internet Engineering Task Force . doi : 10.17487/RFC6234 . ISSN  2070-1721. RFC 6234.{{citation}}: CS1 maint: numeric names: authors list (link) Информационный. Устаревший RFC  4634. Обновление RFC  3174

Внешние ссылки

• Онлайн-генератор HMAC/инструмент для тестирования
• FIPS PUB 198-1, Код аутентификации сообщений с хэш-ключом (HMAC)
• Реализация C HMAC
• Реализация Python HMAC
• Реализация Java
• Реализация Rust HMAC