Intercambio de claves autenticadas con contraseña mediante Juggling

El intercambio de claves autenticado por contraseña mediante malabarismo (o J-PAKE) es un protocolo de acuerdo de claves autenticadas por contraseña , propuesto por Feng Hao y Peter Ryan. ^[1] Este protocolo permite que dos partes establezcan una comunicación privada y autenticada únicamente en función de su contraseña compartida (de baja entropía) sin necesidad de una infraestructura de clave pública . Proporciona autenticación mutua al intercambio de claves, una característica que falta en el protocolo de intercambio de claves Diffie-Hellman .

Descripción

Dos partes, Alice y Bob, acuerdan un grupo con generador de orden primo en el que el problema de logaritmo discreto es difícil. Normalmente se utiliza un grupo de Schnorr . En general, J-PAKE puede utilizar cualquier grupo de orden primo que sea adecuado para la criptografía de clave pública, incluida la criptografía de curva elíptica . Sea su secreto compartido (de baja entropía), que puede ser una contraseña o un hash de una contraseña ( ). El protocolo se ejecuta en dos rondas. ${\displaystyle G}$ ${\displaystyle g}$ ${\displaystyle q}$ ${\displaystyle s}$ ${\displaystyle s\neq 0}$

Ronda 1

Alice selecciona y envía junto con las pruebas de conocimiento cero (usando, por ejemplo, la prueba de conocimiento cero no interactiva de Schnorr, como se especifica en RFC 8235) para la prueba de los exponentes y . De manera similar, Bob selecciona y envía junto con las pruebas de conocimiento cero para la prueba de los exponentes y . La comunicación anterior se puede completar en una ronda, ya que ninguna de las partes depende de la otra. Cuando termina, Alice y Bob verifican las pruebas de conocimiento cero recibidas y también comprueban . ${\displaystyle x_{1}\in _{R}[0,q-1]}$ ${\displaystyle x_{2}\in _{R}[1,q-1]}$ ${\displaystyle g^{x_{1}}}$ ${\displaystyle g^{x_{2}}}$ ${\displaystyle x_{1}}$ ${\displaystyle x_{2}}$ ${\displaystyle x_{3}\in _{R}[0,q-1]}$ ${\displaystyle x_{4}\in _{R}[1,q-1]}$ ${\displaystyle g^{x_{3}}}$ ${\displaystyle g^{x_{4}}}$ ${\displaystyle x_{3}}$ ${\displaystyle x_{4}}$ ${\displaystyle g^{x_{2}},g^{x_{4}}\neq 1}$

Ronda 2

Alice envía y una prueba de conocimiento cero para la prueba del exponente . (Nota: Alice en realidad deriva una nueva clave pública usando como generador). De manera similar, Bob envía y una prueba de conocimiento cero para la prueba del exponente . ${\displaystyle A=g^{(x_{1}+x_{3}+x_{4})x_{2}s}}$ ${\displaystyle x_{2}s}$ ${\displaystyle g^{x_{1}+x_{3}+x_{4}}}$ ${\displaystyle B=g^{(x_{1}+x_{2}+x_{3})x_{4}s}}$ ${\displaystyle x_{4}s}$

Después de la ronda 2, Alice calcula . De manera similar, Bob calcula . Con el mismo material de claves , Alice y Bob pueden derivar una clave de sesión utilizando una función hash criptográfica : . ${\displaystyle K=(B/g^{x_{2}x_{4}s})^{x_{2}}=g^{(x_{1}+x_{3})x_{2}x_{4}s}}$ ${\displaystyle K=(A/g^{x_{2}x_{4}s})^{x_{4}}=g^{(x_{1}+x_{3})x_{2}x_{4}s}}$ ${\displaystyle K}$ ${\displaystyle \kappa =H(K)}$

El protocolo J-PAKE de dos rondas es completamente simétrico, lo que ayuda a simplificar significativamente el análisis de seguridad. Por ejemplo, la prueba de que una de las partes no filtra ninguna información de contraseña en el intercambio de datos debe ser válida para la otra parte en función de la simetría. Esto reduce a la mitad la cantidad de pruebas de seguridad necesarias.

En la práctica, es más probable implementar J-PAKE en tres flujos, ya que una de las partes normalmente tomará la iniciativa. Esto se puede hacer de manera trivial sin pérdida de seguridad. Supongamos que Alice inicia la comunicación enviando a Bob: y pruebas de conocimiento cero. Luego, Bob responde con: y pruebas de conocimiento cero. Finalmente, Alice envía a Bob: y una prueba de conocimiento cero. Ambas partes ahora pueden derivar la misma clave de sesión. ${\displaystyle g^{x_{1}},g^{x_{2}}}$ ${\displaystyle g^{x_{3}},g^{x_{4}},B=g^{(x_{1}+x_{2}+x_{3})x_{4}s}}$ ${\displaystyle A=g^{(x_{1}+x_{3}+x_{4})x_{2}s}}$

Dependiendo del requisito de la aplicación, Alice y Bob pueden realizar un paso de confirmación de clave opcional. Hay varias formas de hacerlo. Un método simple descrito en SPEKE funciona de la siguiente manera: Alice envía a Bob y luego Bob responde con . ^[2] Alternativamente, Alice y Bob pueden realizar una confirmación de clave explícita utilizando la clave de sesión recién construida para cifrar un valor conocido (o un desafío aleatorio). EKE , Kerberos y Needham-Schroeder intentan proporcionar una confirmación de clave explícita exactamente mediante este método. ${\displaystyle H(H(\kappa ))}$ ${\displaystyle H(\kappa )}$

Propiedades de seguridad

Dado que la prueba de conocimiento cero no interactiva subyacente de Schnorr es segura, se demuestra que el protocolo J-PAKE satisface las siguientes propiedades: ^[3]

1. Resistencia a ataques de diccionario fuera de línea: no filtra ninguna información de verificación de contraseña a un atacante pasivo/activo.
2. Secreto de reenvío : produce claves de sesión que permanecen seguras incluso cuando la contraseña se revela posteriormente.
3. Seguridad de clave conocida: evita que una clave de sesión revelada afecte la seguridad de otras sesiones.
4. Resistencia a ataques de diccionario en línea: limita a un atacante activo a probar solo una contraseña por ejecución de protocolo.

En 2015, Abdalla, Benhamouda y MacKenzie realizaron un análisis formal independiente de J-PAKE para demostrar su seguridad en un modelo de oráculo aleatorio asumiendo adversarios algebraicos. ^[4]

El diseño del protocolo

El protocolo J-PAKE está diseñado combinando claves públicas aleatorias de una manera estructurada para lograr un efecto de desaparición si ambas partes proporcionan exactamente las mismas contraseñas. Esto es de alguna manera similar al diseño del protocolo de red de veto anónimo . Sin embargo, la esencia de la idea se remonta al protocolo de red Dining Cryptographers original de David Chaum , ^[5] donde los bits binarios se combinan de una manera estructurada para lograr un efecto de desaparición.

La implementación

J-PAKE se ha implementado en OpenSSL y OpenSSH como un protocolo de autenticación experimental. Fue eliminado del código fuente de OpenSSH a fines de enero de 2014. ^[6] También se ha implementado en Smoke Crypto Chat Messenger, ^[7] en NSS y fue utilizado por Firefox Sync versión 1.1 pero se discontinuó en 1.5 que utiliza un método de intercambio y almacenamiento de claves diferente. ^[8] El servidor J-PAKE de Mozilla se cerró junto con los servidores de almacenamiento de Sync 1.1 el 30 de septiembre de 2015. ^[9] Pale Moon continúa utilizando J-PAKE como parte de su servicio Sync. ^[10] Desde febrero de 2013, J-PAKE se agregó a la API liviana en Bouncycastle (1.48 y posteriores). J-PAKE también se utiliza en Thread (protocolo de red) ^[11]

Normalización

J-PAKE se incluyó en ISO/IEC 11770-4 (2017) como estándar internacional. ^[12] También está publicado en RFC 8236.

Referencias

1. F. Hao, P. Ryan. Intercambio de claves autenticadas mediante contraseñas mediante malabarismo. Actas del 16.º Taller internacional sobre protocolos de seguridad, 2008.
2. Jablon, David (octubre de 1996). "Intercambio de claves autenticado mediante contraseñas seguras". ACM SIGCOMM Computer Communication Review . 26 (5): 5–26. CiteSeerX  10.1.1.57.4798 . doi :10.1145/242896.242897. S2CID  2870433.
3. F. Hao, P. Ryan. J-PAKE: intercambio de claves autenticadas sin PKI. Springer Transactions on Computational Science XI , número especial sobre seguridad informática, parte II, vol. 6480, págs. 192-206, 2010.
4. M. Abdalla, F. Benhamouda, P. MacKenzie Seguridad del protocolo de intercambio de claves autenticadas por contraseña J-PAKE.
5. Chaum, David (1988). "El problema de los criptógrafos que cenan: Imposibilidad de rastrear incondicionalmente a los remitentes y destinatarios". Journal of Cryptology . 1 : 65–75. doi :10.1007/BF00206326. S2CID  2664614.
6. "Registro CVS para src/usr.bin/ssh/Attic/jpake.c". cvsweb.openbsd.org . Consultado el 17 de noviembre de 2023 .
7. Moonlander, Casio (2020). Smoke: una aplicación de software de chat de Echo para Android:: Mensajero de chat personal / Documentación de referencia técnica de sitio web de código abierto . Norderstedt: BOD. p. 44. ISBN 9783752691993.
8. "El nuevo modelo de seguridad de Firefox Sync". 30 de abril de 2014.
9. "Cerrar el servicio de sincronización heredado". 31 de julio de 2015.
10. "¡Pale Moon actualizado a 25.7.3! - Foro de Pale Moon".
11. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 2015-09-11 . Consultado el 2015-09-15 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
12. "ISO/IEC 11770-4:2017 (es)". iso.org . Consultado el 17 de noviembre de 2023 .

Enlaces externos

• RFC 8236 del paquete japonés
• Un prototipo Java de J-PAKE que utiliza el campo finito
• Un prototipo Java de J-PAKE que utiliza la curva elíptica
• Implementación de CA de J-PAKE de curva elíptica en ARM mbed
• Una implementación Java de J-PAKE en Bouncycastle
• J-PAKE: De criptógrafos gastronómicos a malabaristas