HMAC

Поколение HMAC-SHA1

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

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

Подробности [ править ]

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

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

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

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

Определение и анализ конструкции HMAC были впервые опубликованы в 1996 году в статье Михира Белларе , Рана Канетти и Хьюго Кравчика ^[2], а также они написали RFC 2104 в 1997 году. В статье 1996 года также был определен вложенный вариант, названный NMAC. FIPS PUB 198 обобщает и стандартизирует использование HMAC. HMAC используется в протоколах IPsec , SSH и TLS , а также для веб-токенов JSON .

Определение [ править ]

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

${\ displaystyle {\ begin {align} \ 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) & K {\ text {больше, чем размер блока}} \\ K & {\ text {в противном случае}} \ end {case}} \ end {align}}}$

куда

H - криптографическая хеш-функция

m - это сообщение, которое нужно аутентифицировать

K - секретный ключ

K ' - это ключ размером с блок, полученный из секретного ключа K ; либо путем заполнения справа нулями до размера блока, либо путем хеширования до значения, меньшего или равного размеру блока, а затем заполнения справа нулями

‖ Обозначает конкатенацию

⊕ означает побитовое исключающее ИЛИ (XOR)

opad - внешнее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x5c

ipad - это внутреннее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x36.

Реализация [ править ]

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

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

Принципы дизайна [ править ]

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

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

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

Безопасность [ править ]

Криптографическая стойкость HMAC зависит от размера используемого секретного ключа. Самая распространенная атака на HMAC - это грубая сила для раскрытия секретного ключа. HMAC значительно меньше подвержены коллизиям, чем только их базовые алгоритмы хеширования. ^{[7] [8]} В частности, в 2006 году Михир Белларе доказал, что HMAC является PRF при единственном предположении, что функция сжатия является PRF. ^[9] Следовательно, HMAC-MD5 не страдает теми же недостатками, которые были обнаружены в MD5.

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

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

В 2009 году Xiaoyun Wang et al. представили отличительную атаку на HMAC-MD5 без использования связанных ключей. Он может отличить создание HMAC с MD5 от экземпляра со случайной функцией с ²⁹⁷ запросами с вероятностью 0,87. ^[13]

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

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

Примеры [ править ]

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

HMAC_MD5 («ключ», «Быстрая коричневая лиса перепрыгивает через ленивого пса») = 80070713463e7749b90c2dc24911e275HMAC_SHA1 ("ключ", "Быстрая коричневая лиса перепрыгивает через ленивого пса") = de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9HMAC_SHA256 ("ключ", "Быстрая коричневая лиса перепрыгивает через ленивого пса") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

Ссылки [ править ]

Примечания

Внешние ссылки [ править ]

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