HMAC

Geração HMAC-SHA1

Na criptografia, um HMAC (às vezes expandido como código de autenticação de mensagem hash com chave ou código de autenticação de mensagem baseado em hash) é um tipo específico de código de autenticação de mensagem (MAC) envolvendo uma função hash criptográfica e uma chave criptográfica secreta. Assim como qualquer MAC, ele pode ser usado para verificar simultaneamente a integridade dos dados e a autenticidade de uma mensagem.

HMAC pode fornecer autenticação usando um segredo compartilhado em vez de usar assinaturas digitais com criptografia assimétrica. Ele compensa a necessidade de uma infra-estrutura de chave pública complexa delegando a troca de chaves às partes comunicantes, que são responsáveis por estabelecer e usar um canal confiável para concordar com a chave antes da comunicação.

Detalhes

Qualquer função hash criptográfica, como SHA-2 ou SHA-3, pode ser usada no cálculo de um HMAC; o algoritmo MAC resultante é denominado HMAC-X, onde X é a função hash usada (por exemplo, HMAC-SHA256 ou HMAC-SHA3-512). A força criptográfica do HMAC depende da força criptográfica da função de hash subjacente, do tamanho de sua saída de hash e do tamanho e qualidade da chave.

HMAC usa duas passagens de computação de hash. Antes de qualquer passagem, a chave secreta é usada para derivar duas chaves – interna e externa. Em seguida, a primeira passagem do algoritmo hash produz um hash interno derivado da mensagem e da chave interna. A segunda passagem produz o código HMAC final derivado do resultado do hash interno e da chave externa. Assim, o algoritmo fornece melhor imunidade contra ataques de extensão de comprimento.

Uma função hash iterativa (uma que usa a construção Merkle–Damgård) divide uma mensagem em blocos de tamanho fixo e itera sobre eles com uma função de compactação. Por exemplo, SHA-256 opera em blocos de 512 bits. O tamanho da saída do HMAC é o mesmo da função hash subjacente (por exemplo, 256 e 512 bits no caso de SHA-256 e SHA3-512, respectivamente), embora possa ser truncado, se desejado.

HMAC não criptografa a mensagem. Em vez disso, a mensagem (criptografada ou não) deve ser enviada juntamente com o hash HMAC. As partes com a chave secreta farão o hash da mensagem novamente e, se for autêntica, os hashes recebidos e calculados serão correspondentes.

A definição e análise da construção HMAC foi publicada pela primeira vez em 1996 em um artigo de Mihir Bellare, Ran Canetti e Hugo Krawczyk, e eles também escreveram RFC 2104 em 1997. O artigo de 1996 também definiu uma variante aninhada chamada NMAC (MAC aninhado). FIPS PUB 198 generaliza e padroniza o uso de HMACs. O HMAC é usado nos protocolos IPsec, SSH e TLS e para JSON Web Tokens.

Definição

Esta definição foi retirada da RFC 2104:

HMAC⁡ ⁡ (KK,m)= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =H. H. H.⁡ ⁡ ((KK?⊕ ⊕ opumD)∥ ∥ H. H. H.⁡ ⁡ ((KK?⊕ ⊕ Eu...pumD)∥ ∥ m))KK?= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =(H. H. H.⁡ ⁡ (KK)seKKé maior do que o tamanho do blocoKKcaso contrário{displaystyle {begin{aligned}operatorname} {HMAC} (K,m)&=operatorname {H} {Bigl (}{bigl (}K'oplus opad{bigr)}parallel operatorname {H} {bigl} (left(K'oplus ipadright)parallel m{bigr)}{Bigr)}\K'&={begin{cases}operatorname {H} left(Kright)&{text{if}} K{text{ é maior que o tamanho do bloco}}K&{text{otherwise}}end{cases}}end{aligned}}}

onde

H. H. H.{displaystyle operatorname {H} } é uma função hash criptográfica.

mNão. é a mensagem a ser autenticada.

KKNão. é a chave secreta.

KK?Não. é uma chave de tamanho de bloco derivada da chave secreta, KK; ou pelo estofamento à direita com 0s até o tamanho do bloco, ou pelo hash para baixo a menos ou igual ao tamanho do bloco primeiro e, em seguida, padding à direita com zeros.

∥ ∥ - Sim. denota concatenação.

⊕ ⊕ - Sim. denotes bitwise exclusivo ou (XOR).

opumD- Sim. é o bloco de tamanho exterior padding, consistindo de bytes repetidos avaliado 0x5c.

Eu...pumD- Sim. é o bloco de tamanho interno padding, consistindo de bytes repetidos avaliado 0x36.

Implementação

O pseudocódigo a seguir demonstra como o HMAC pode ser implementado. O tamanho do bloco é de 512 bits (64 bytes) ao usar uma das seguintes funções de hash: SHA-1, MD5, RIPEMD-128.

função Hmac o entrada:chave: Bytes // Array of bytesmensagem: Atos // Array de bytes a ser hashedhash: Função // A função hash para usar (por exemplo, SHA-1)bloco Tamanho: Integer // O tamanho do bloco da função hash (por exemplo, 64 bytes para SHA-1)saída Tamanho: Integer // O tamanho da saída da função hash (por exemplo, 20 bytes para SHA-1) // Compute a chave tamanho blocoblock_sized_key = computeBlockSizedKey (chave, hash, blockSize)

← block_sized_key xor [0x5c blockSize] // Chave acolchoada externa← Block_sized_key xor [0x36 blockSize] // Chave acolchoada interna retorno hash(o_key_pad) hash(i_key_pad) message))

função computa Blocksized Chaveiro o entrada:chave: Bytes // Array of byteshash: Função // A função hash para usar (por exemplo, SHA-1)bloco Tamanho: Integer // O tamanho do bloco da função hash (por exemplo, 64 bytes para SHA-1) // Chaves mais longas do que tamanho do bloco são encurtados por hashing-los se (comprimento (chave) > blockSize) entãochave = hash (chave)

 // Chaves mais curtas do que tamanho do bloco são acolchoados para tamanho do bloco por preenchimento com zeros à direita se (comprimento (chave) < blockSize) então retorno Pad (key, blockSize) // Chave de almofada com zeros para torná-lo tamanho do bloco bytes longos retorno chave chave

Princípios de design

O design da especificação HMAC foi motivado pela existência de ataques a mecanismos mais triviais para combinar uma chave com uma função hash. Por exemplo, pode-se assumir que a mesma segurança fornecida pelo HMAC pode ser obtida com MAC = H(chave ∥ mensagem). No entanto, esse método sofre de uma falha grave: com a maioria das funções de hash, é fácil anexar dados à mensagem sem conhecer a chave e obter outro MAC válido ("ataque de extensão de comprimento"). A alternativa, anexar a chave usando MAC = H(mensagem ∥ chave), sofre do problema de um invasor que pode encontrar uma colisão em a função hash (sem chave) tem uma colisão no MAC (como duas mensagens m1 e m2 produzindo o mesmo hash fornecerão a mesma condição inicial para a função hash antes que a chave anexada seja hash, portanto, o hash final será o mesmo). Usar MAC = H(chave ∥ mensagem ∥ chave) é melhor, mas vários documentos de segurança sugeriram vulnerabilidades com essa abordagem, mesmo quando duas chaves diferentes são usadas.

Nenhum ataque de extensão conhecido foi encontrado contra a especificação HMAC atual, que é definida como H(chave ∥ H(chave ∥ mensagem)) porque a aplicação externa da função hash mascara o resultado intermediário do hash interno. Os valores de ipad e opad não são críticos para a segurança do algoritmo, mas foram definidos de forma a ter uma grande distância de Hamming um do outro e, portanto, o e as chaves externas terão menos bits em comum. A redução de segurança do HMAC exige que eles sejam diferentes em pelo menos um bit.

A função de hash Keccak, que foi selecionada pelo NIST como vencedora da competição SHA-3, não precisa dessa abordagem aninhada e pode ser usada para gerar um MAC simplesmente anexando a chave à mensagem, pois é não suscetível a ataques de extensão de comprimento.

Segurança

A força criptográfica do HMAC depende do tamanho da chave secreta usada e da segurança da função de hash subjacente usada. Foi comprovado que a segurança de uma construção HMAC está diretamente relacionada às propriedades de segurança da função hash utilizada. O ataque mais comum contra HMACs é a força bruta para descobrir a chave secreta. Os HMACs são substancialmente menos afetados por colisões do que seus algoritmos de hash subjacentes sozinhos. Em particular, Mihir Bellare provou que HMAC é um PRF sob a única suposição de que a função de compressão é um PRF. Portanto, o HMAC-MD5 não sofre das mesmas deficiências encontradas no MD5.

RFC 2104 requer que "chaves com mais de B bytes sejam primeiro hash usando H" o que leva a uma pseudo-colisão confusa: se a chave for maior que o tamanho do bloco de hash (por exemplo, 64 bytes para SHA-1), então HMAC(k, m) é computado como HMAC (H(k), m).Esta propriedade às vezes é levantada como uma possível fraqueza do HMAC em cenários de hashing de senha: foi demonstrado que é possível encontrar uma string ASCII longa e um aleatório valor cujo hash também será uma string ASCII e ambos os valores produzirão a mesma saída HMAC.

Em 2006, Jongsung Kim, Alex Biryukov, Bart Preneel e Seokhie Hong mostraram como distinguir HMAC com versões reduzidas de MD5 e SHA-1 ou versões completas de HAVAL, MD4 e SHA-0 de uma função aleatória ou HMAC com uma função aleatória. Distintores diferenciais permitem que um invasor planeje um ataque de falsificação no HMAC. Além disso, diferenciadores diferenciais e retangulares podem levar a ataques de segunda pré-imagem. O HMAC com a versão completa do MD4 pode ser forjado com esse conhecimento. Esses ataques não contradizem a prova de segurança do HMAC, mas fornecem informações sobre o HMAC com base nas funções hash criptográficas existentes.

Em 2009, Xiaoyun Wang et al. apresentou um ataque distinto em HMAC-MD5 sem usar chaves relacionadas. Ele pode distinguir uma instanciação de HMAC com MD5 de uma instanciação com uma função aleatória com 2⁹⁷ consultas com probabilidade 0,87.

Em 2011, um informativo RFC 6151 foi publicado para resumir as considerações de segurança em MD5 e HMAC-MD5. Para HMAC-MD5, a RFC resume que – embora a segurança da própria função de hash MD5 esteja severamente comprometida – os ataques " atualmente conhecidos em HMAC-MD5 não parecem indicar uma vulnerabilidade prática quando usados como uma mensagem código de autenticação", mas também acrescenta que "para um novo design de protocolo, um ciphersuite com HMAC-MD5 não deve ser incluído".

Em maio de 2011, o RFC 6234 foi publicado detalhando a teoria abstrata e o código-fonte para HMACs baseados em SHA.

Exemplos

Aqui estão alguns valores HMAC, assumindo a codificação ASCII de 8 bits:

HMAC_MD5("key", "A raposa marrom rápida salta sobre o cão preguiçoso") = 80070713463e7749b90c2dc24911e275

HMAC_SHA1("key", "A raposa marrom rápida salta sobre o cão preguiçoso") = de7c9b8b8b78a6bc8a7a36f70a90707c9db4d9

HMAC_SHA256("key", "The quick brown fox jumps over the lazy dog") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

HMAC_SHA512("key", "The quick brown fox jumps over the lazy dog") = b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec39357e