En criptografía , un HMAC (a veces expandido como código de autenticación de mensaje con clave hash o código de autenticación de mensaje basado en hash ) es un tipo específico de código de autenticación de mensaje (MAC) que involucra una función de hash criptográfica y una clave criptográfica secreta. Al igual que con cualquier MAC, se puede utilizar para verificar simultáneamente tanto la integridad de los datos como la autenticidad de un mensaje.
HMAC puede proporcionar autenticación de mensajes utilizando un secreto compartido en lugar de utilizar firmas digitales con criptografía asimétrica . Negocia la necesidad de una infraestructura de clave pública compleja al delegar el intercambio de claves a las partes comunicantes, quienes son responsables de establecer y utilizar un canal confiable para acordar la clave antes de la comunicación. [1]
Detalles
Cualquier función hash criptográfica, como SHA-2 o SHA-3 , puede usarse en el cálculo de un HMAC; el algoritmo MAC resultante se denomina HMAC-X, donde X es la función hash utilizada (por ejemplo, HMAC-SHA256 o HMAC-SHA3-512). La fuerza criptográfica del HMAC depende de la fuerza criptográfica de la función hash subyacente, el tamaño de su salida de hash y el tamaño y la calidad de la clave.
HMAC utiliza dos pasos de cálculo hash. La clave secreta se usa primero para derivar dos claves: interna y externa. El primer paso del algoritmo produce un hash interno derivado del mensaje y la clave interna. La segunda pasada produce el código HMAC final derivado del resultado del hash interno y la clave externa. Por tanto, el algoritmo proporciona una mejor inmunidad contra los ataques de extensión de longitud .
Una función hash iterativa divide un mensaje en bloques de un tamaño fijo y los recorre con una función de compresión . Por ejemplo, SHA-256 opera en bloques de 512 bits. El tamaño de la salida de HMAC es el mismo que el de la función hash subyacente (por ejemplo, 256 y 512 bits en el caso de SHA-256 y SHA3-512, respectivamente), aunque se puede truncar si se desea.
HMAC no cifra el mensaje. En cambio, el mensaje (cifrado o no) debe enviarse junto con el hash HMAC. Las partes con la clave secreta volverán a hacer hash en el mensaje y, si es auténtico, los hashes recibidos y calculados coincidirán.
La definición y análisis de la construcción HMAC se publicó por primera vez en 1996 en un artículo de Mihir Bellare , Ran Canetti y Hugo Krawczyk, [2] y también escribieron RFC 2104 en 1997. El artículo de 1996 también definió una variante anidada llamada NMAC. FIPS PUB 198 generaliza y estandariza el uso de HMAC. HMAC se utiliza dentro de los protocolos IPsec , SSH y TLS y para los tokens web JSON .
Definición
Esta definición está tomada de RFC 2104:
dónde
- H es una función hash criptográfica
- m es el mensaje a autenticar
- K es la clave secreta
- K ' es una clave del tamaño de un bloque derivada de la clave secreta, K ; ya sea rellenando a la derecha con ceros hasta el tamaño del bloque, o haciendo un hash a menor o igual que el tamaño del bloque primero y luego rellenando a la derecha con ceros
- ‖ Denota concatenación
- ⊕ denota bit a bit exclusivo o (XOR)
- opad es el relleno externo del tamaño de un bloque, que consta de bytes repetidos con un valor de 0x5c
- ipad es el relleno interno del tamaño de un bloque, que consta de bytes repetidos valorados en 0x36
Implementación
El siguiente pseudocódigo demuestra cómo se puede implementar HMAC. El tamaño del bloque es de 512 bits (64 bytes) cuando se utiliza una de las siguientes funciones hash: SHA-1, MD5, RIPEMD-128. [3]
La función hmac es input: key: Bytes // Matriz de bytes mensaje: Bytes // Matriz de bytes a ser hash hash: Función // La función hash a usar (por ejemplo, SHA-1) blockSize: Integer // El tamaño de bloque del función hash (por ejemplo, 64 bytes para SHA-1) outputSize: Integer // El tamaño de salida de la función hash (por ejemplo, 20 bytes para SHA-1) // Las claves más largas que blockSize se acortan mediante hash if (length (key)> blockSize) then key ← hash (key) // key is outputSize bytes long // Las claves más cortas que blockSize se rellenan para blockSize rellenando con ceros a la derecha if (length (key))>then key ← Pad (key, blockSize) // Tecla de relleno con ceros para que sea blockSize bytes de longitud o_key_pad ← tecla xor [0x5c blockSize] // Tecla exterior acolchada i_key_pad ← tecla xor [0x36 blockSize] // Tecla interior acolchada return hash (o_key_pad ∥ hash (i_key_pad ∥ mensaje))
Criterios de diseño
El diseño de la especificación HMAC estuvo motivado por la existencia de ataques a mecanismos más triviales para combinar una clave con una función hash. Por ejemplo, se podría suponer que la misma seguridad que proporciona HMAC podría lograrse con MAC = H ( mensaje clave ∥ ). Sin embargo, este método adolece de un grave defecto: con la mayoría de las funciones hash, es fácil añadir datos al mensaje sin conocer la clave y obtener otro MAC válido (" ataque de extensión de longitud "). La alternativa, agregar la clave usando MAC = H ( mensaje ∥ clave ), tiene el problema de que un atacante que puede encontrar una colisión en la función hash (sin clave) tiene una colisión en el MAC (como dos mensajes m1 y m2 que producen el mismo hash proporcionará la misma condición de inicio a la función hash antes de que la clave agregada sea hash, por lo tanto, el hash final será el mismo). Usar MAC = H ( clave ∥ mensaje ∥ clave ) es mejor, pero varios documentos de seguridad han sugerido vulnerabilidades con este enfoque, incluso cuando se usan dos claves diferentes. [2] [4] [5]
No se han encontrado ataques de extensión conocidos contra la especificación HMAC actual, que se define como H ( clave ∥ H ( clave ∥ mensaje )) porque la aplicación externa de la función hash enmascara el resultado intermedio del hash interno. Los valores de ipad y opad no son críticos para la seguridad del algoritmo, pero se definieron de tal manera que tengan una gran distancia de Hamming entre sí y, por lo tanto, las claves internas y externas tendrán menos bits en común. La reducción de seguridad de HMAC requiere que sean diferentes en al menos un bit. [ cita requerida ]
La función hash de Keccak , que fue seleccionada por NIST como la ganadora de la competencia SHA-3 , no necesita este enfoque anidado y se puede usar para generar un MAC simplemente anteponiendo la clave al mensaje, ya que no es susceptible de extensión. ataques de extensión. [6]
Seguridad
La fuerza criptográfica del HMAC depende del tamaño de la clave secreta que se utiliza. El ataque más común contra los HMAC es la fuerza bruta para descubrir la clave secreta. Los HMAC se ven sustancialmente menos afectados por las colisiones que sus algoritmos de hash subyacentes por sí solos. [7] [8] En particular, en 2006 Mihir Bellare demostró que HMAC es un PRF bajo el único supuesto de que la función de compresión es un PRF. [9] Por lo tanto, HMAC-MD5 no sufre las mismas debilidades que se han encontrado en MD5.
RFC 2104 requiere que "las claves de más de B bytes se sometan primero a hash utilizando H ", lo que conduce a una pseudocolisión confusa: si la clave es más larga que el tamaño del bloque hash (por ejemplo, 64 bytes para SHA-1), entonces HMAC(k, m)
se calcula como HMAC(H(k), m).
This La propiedad a veces se plantea como una posible debilidad de HMAC en escenarios de hash de contraseña: se ha demostrado que es posible encontrar una cadena ASCII larga y un valor aleatorio cuyo hash también será una cadena ASCII, y ambos valores producirán el mismo HMAC producción. [10] [11]
En 2006, Jongsung Kim , Alex Biryukov , Bart Preneel y Seokhie Hong mostraron cómo distinguir HMAC con versiones reducidas de MD5 y SHA-1 o versiones completas de HAVAL , MD4 y SHA-0 a partir de una función aleatoria o HMAC con una función aleatoria. función. Los distintivos diferenciales permiten a un atacante idear un ataque de falsificación en HMAC. Además, los diferenciadores diferenciales y rectangulares pueden provocar ataques de segunda preimagen . Con este conocimiento se puede forjar HMAC con la versión completa de MD4 . Estos ataques no contradicen la prueba de seguridad de HMAC, pero brindan información sobre HMAC basada en funciones de hash criptográficas existentes. [12]
En 2009, Xiaoyun Wang et al. presentó un ataque distintivo en HMAC-MD5 sin usar claves relacionadas. Puede distinguir una instanciación de HMAC con MD5 de una instanciación con una función aleatoria con 2 97 consultas con probabilidad de 0,87. [13]
En 2011 se publicó un RFC 6151 [14] informativo para resumir las consideraciones de seguridad en MD5 y HMAC-MD5. Para HMAC-MD5, la RFC resume que, aunque la seguridad de la función hash MD5 en sí está gravemente comprometida, los "ataques a HMAC-MD5 actualmente conocidos no parecen indicar una vulnerabilidad práctica cuando se utilizan como código de autenticación de mensajes" , pero También agrega que "para un nuevo diseño de protocolo, no se debe incluir una suite de cifrado con HMAC-MD5" .
En mayo de 2011, se publicó RFC 6234 detallando la teoría abstracta y el código fuente de los HMAC basados en SHA.
Ejemplos de
A continuación, se muestran algunos valores HMAC no vacíos, asumiendo codificación ASCII o UTF-8 de 8 bits :
HMAC_MD5 ("clave", "El rápido zorro marrón salta sobre el perro perezoso") = 80070713463e7749b90c2dc24911e275HMAC_SHA1 ("clave", "El rápido zorro marrón salta sobre el perro perezoso") = de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9HMAC_SHA256 ("clave", "El rápido zorro marrón salta sobre el perro perezoso") = f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
Referencias
- ^ "¿Cómo y cuándo uso HMAC?" . Intercambio de pila de seguridad. Abril de 2015 . Consultado el 25 de noviembre de 2020 .
- ^ a b Bellare, Mihir ; Canetti, Ran; Krawczyk, Hugo (1996). "Funciones de codificación hash para la autenticación de mensajes": 1–15. CiteSeerX 10.1.1.134.8430 . Cite journal requiere
|journal=
( ayuda ) - ^ "Definición de HMAC" . HMAC: Hashing con clave para autenticación de mensajes . segundo. 2. doi : 10.17487 / RFC2104 . RFC 2104 .
- ^ Preneel, Bart ; van Oorschot, Paul C. (1995). "MDx-MAC y creación de MAC rápidos a partir de funciones hash". CiteSeerX 10.1.1.34.3855 . Cite journal requiere
|journal=
( ayuda ) - ^ Preneel, Bart ; van Oorschot, Paul C. (1995). "Sobre la seguridad de dos algoritmos MAC". CiteSeerX 10.1.1.42.8908 . Cite journal requiere
|journal=
( ayuda ) - ^ Equipo de Keccak. "Equipo Keccak - Diseño y seguridad" . Consultado el 31 de octubre de 2019 .
A diferencia de SHA-1 y SHA-2, Keccak no tiene la debilidad de extensión de longitud, por lo que no necesita la construcción anidada HMAC. En cambio, el cálculo de MAC se puede realizar simplemente anteponiendo la clave al mensaje.
- ^ Bruce Schneier (agosto de 2005). "SHA-1 roto" . Consultado el 9 de enero de 2009 .
aunque no afecta aplicaciones como HMAC donde las colisiones no son importantes
- ^ IETF (febrero de 1997). "Seguridad" . HMAC: Hashing con clave para autenticación de mensajes . segundo. 6. doi : 10.17487 / RFC2104 . RFC 2104 . Consultado el 3 de diciembre de 2009 .
El ataque más fuerte conocido contra HMAC se basa en la frecuencia de colisiones para la función hash H ("ataque de cumpleaños") [PV, BCK2], y es totalmente impráctico para funciones hash mínimamente razonables.
- ^ Bellare, Mihir (junio de 2006). "Nuevas pruebas para NMAC y HMAC: seguridad sin resistencia a colisiones" . En Dwork, Cynthia (ed.). Avances en criptología - Actas de Crypto 2006 . Lecture Notes in Computer Science 4117. Springer-Verlag . Consultado el 25 de mayo de 2010 .
Este artículo prueba que HMAC es un PRF bajo el único supuesto de que la función de compresión es un PRF. Esto recupera una garantía basada en pruebas ya que ningún ataque conocido compromete la pseudoaleatoriedad de la función de compresión, y también ayuda a explicar la resistencia al ataque que ha mostrado HMAC incluso cuando se implementa con funciones hash cuya (débil) resistencia a colisiones está comprometida.
- ^ "Explicación de las colisiones hash PBKDF2 + HMAC · Mathias Bynens" . mathiasbynens.be . Consultado el 7 de agosto de 2019 .
- ^ "Aaron Toponce: Rompiendo HMAC" . Consultado el 7 de agosto de 2019 .
- ^ Jongsung, Kim; Biryukov, Alex; Preneel, Bart; Hong, Seokhie (2006). "Sobre la seguridad de HMAC y NMAC basado en HAVAL, MD4, MD5, SHA-0 y SHA-1" (PDF) . Cite journal requiere
|journal=
( ayuda ) - ^ Wang, Xiaoyun; Yu, Hongbo; Wang, Wei; Zhang, Haina; Zhan, Tao (2009). "Criptoanálisis en HMAC / NMAC-MD5 y MD5-MAC" (PDF) . Consultado el 15 de junio de 2015 . Cite journal requiere
|journal=
( ayuda ) - ^ "RFC 6151 - Consideraciones de seguridad actualizadas para MD5 Message-Digest y los algoritmos HMAC-MD5" . Grupo de Trabajo de Ingeniería de Internet. Marzo de 2011 . Consultado el 15 de junio de 2015 .
- Notas
- Mihir Bellare, Ran Canetti y Hugo Krawczyk, Keying Hash Functions for Message Authentication, CRYPTO 1996, págs. 1-15 (PS o PDF) .
- Mihir Bellare, Ran Canetti y Hugo Krawczyk, Autenticación de mensajes mediante funciones hash: La construcción HMAC, CryptoBytes 2 (1), primavera de 1996 (PS o PDF) .
enlaces externos
- RFC2104
- Herramienta de prueba / generador de HMAC en línea
- FIPS PUB 198-1, el código de autenticación de mensajes hash con clave (HMAC)
- Implementación de C HMAC
- Implementación de Python HMAC
- Implementación de Java