HMAC - HMAC

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

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

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

Подробности

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

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

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

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

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

Определение

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

куда

H - криптографическая хеш-функция
m - это сообщение, которое нужно аутентифицировать
K - секретный ключ
K ' - это ключ размером с блок, полученный из секретного ключа K ; либо путем заполнения справа нулями до размера блока, либо путем хеширования до значения, меньшего или равного размеру блока, а затем заполнения справа нулями
‖ Обозначает конкатенацию
⊕ означает побитовое исключающее ИЛИ (XOR)
opad - внешнее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x5c
ipad - это внутреннее заполнение размером с блок, состоящее из повторяющихся байтов со значением 0x36.

Реализация

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

function hmac is
    input:
        key:        Bytes    // Array of bytes
        message:    Bytes    // Array of bytes to be hashed
        hash:       Function // The hash function to use (e.g. SHA-1)
        blockSize:  Integer  // The block size of the hash function (e.g. 64 bytes for SHA-1)
        outputSize: Integer  // The output size of the hash function (e.g. 20 bytes for SHA-1)
 
    // Keys longer than blockSize are shortened by hashing them
    if (length(key) > blockSize) then
        key ← hash(key) // key is outputSize bytes long

    // Keys shorter than blockSize are padded to blockSize by padding with zeros on the right
    if (length(key) < blockSize) then
        key ← Pad(key, blockSize) // Pad key with zeros to make it blockSize bytes long

    o_key_pad ← key xor [0x5c  blockSize]   // Outer padded key
    i_key_pad ← key xor [0x36  blockSize]   // Inner padded key

    return  hash(o_key_pad ∥ hash(i_key_pad ∥ message))

Принципы дизайна

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

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

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

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

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

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

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

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

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

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

Примеры

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

HMAC_MD5("key", "The quick brown fox jumps over the lazy dog")    = 80070713463e7749b90c2dc24911e275
HMAC_SHA1("key", "The quick brown fox jumps over the lazy dog")   = de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC_SHA256("key", "The quick brown fox jumps over the lazy dog") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

использованная литература

Примечания
  • Михир Белларе, Ран Канетти и Хьюго Кравчик, Ключ хеш-функций для аутентификации сообщений, CRYPTO 1996, стр. 1–15 (PS или PDF) .
  • Михир Белларе, Ран Канетти и Хьюго Кравчик, Аутентификация сообщений с использованием хэш-функций: конструкция HMAC, CryptoBytes 2 (1), Spring 1996 (PS или PDF) .

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