Intercambio de claves autenticado por contraseña mediante malabarismo

El Intercambio de Claves Autenticado por Contraseña mediante Juggling (o J-PAKE) es un protocolo de acuerdo de claves autenticado por contraseña , propuesto por Feng Hao y Peter Ryan. ^{[ 1 ]} Este protocolo permite que dos partes establezcan una comunicación privada y autenticada basándose únicamente en su contraseña compartida (de baja entropía) sin necesidad de una Infraestructura de Clave Pública . Proporciona autenticación mutua para el intercambio de claves, una característica de la que carece el protocolo de intercambio de claves Diffie-Hellman .

Dos partes, Alice y Bob , se ponen de acuerdo en un grupo.${\displaystyle G}$con generador${\displaystyle g}$de orden primo${\displaystyle q}$en el que el problema del 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 .${\displaystyle s}$ser su secreto compartido (de baja entropía), que puede ser una contraseña o un hash de una contraseña (${\displaystyle s\neq 0}$). El protocolo se ejecuta en dos rondas.

Ronda 1

Alice selecciona${\displaystyle x_{1}\in _{R}[0,q-1]}$,${\displaystyle x_{2}\in _{R}[1,q-1]}$y envía${\displaystyle g^{x_{1}}}$,${\displaystyle g^{x_{2}}}$junto con las pruebas de conocimiento cero (utilizando, por ejemplo, la prueba de conocimiento cero no interactiva de Schnorr como se especifica en RFC 8235) para la prueba de los exponentes${\displaystyle x_{1}}$y${\displaystyle x_{2}}$. De manera similar, Bob selecciona${\displaystyle x_{3}\in _{R}[0,q-1]}$,${\displaystyle x_{4}\in _{R}[1,q-1]}$y envía${\displaystyle g^{x_{3}}}$,${\displaystyle g^{x_{4}}}$junto con las pruebas de conocimiento cero para la demostración de los exponentes${\displaystyle x_{3}}$y${\displaystyle x_{4}}$La comunicación anterior puede completarse 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 g^{x_{2}},g^{x_{4}}\neq 1}$.

Ronda 2

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

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

El protocolo J-PAKE de dos rondas es completamente simétrico. Esto simplifica considerablemente el análisis de seguridad. Por ejemplo, la prueba de que una de las partes no filtra información de contraseñas durante el intercambio de datos debe ser válida para la otra parte, gracias a la simetría. Esto reduce a la mitad el número de pruebas de seguridad necesarias.

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

Dependiendo de los requisitos de la aplicación, Alice y Bob pueden realizar un paso opcional de confirmación de clave. Hay varias maneras de hacerlo. Un método sencillo descrito en SPEKE funciona de la siguiente manera: Alice envía a Bob${\displaystyle H(H(\kappa ))}$y luego Bob responde con${\displaystyle H(\kappa )}$. ^{[ 2 ]} Alternativamente, Alice y Bob pueden realizar una confirmación explícita de la clave 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 explícita de la clave mediante este método.

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

1. Resistencia a ataques de diccionario sin conexión : no filtra ninguna información de verificación de contraseñas a un atacante pasivo o activo.
2. Secreto hacia adelante : genera claves de sesión que permanecen seguras incluso cuando la contraseña se revela posteriormente.
3. Seguridad de clave conocida: impide que una clave de sesión revelada afecte a 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 llevaron a cabo un análisis formal independiente de J-PAKE para demostrar su seguridad en un modelo de oráculo aleatorio asumiendo adversarios algebraicos. ^{[ 4 ]}

El protocolo J-PAKE está diseñado combinando claves públicas aleatorias de forma estructurada para lograr un efecto de desaparición si ambas partes proporcionan exactamente las mismas contraseñas. Esto es 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 original Dining Cryptographers de David Chaum ^{[ 5 ]} , donde los bits binarios se combinan de forma estructurada para lograr un efecto de desaparición.

J-PAKE se implementó en OpenSSL y OpenSSH como un protocolo de autenticación experimental . Se eliminó del código fuente de OpenSSH a finales de enero de 2014. ^{[ 6 ]} También se implementó en Smoke Crypto Chat Messenger, ^{[ 7 ]} en NSS y fue utilizado por Firefox Sync versión 1.1, pero se descontinuó en la versión 1.5, que utiliza un método diferente de intercambio y almacenamiento de claves. ^{[ 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 ha añadido a la API ligera en Bouncycastle (1.48 y posteriores). J-PAKE también se utiliza en Thread (protocolo de red) ^{[ 11 ]}

J-PAKE se incluyó en ISO/IEC 11770-4 (2017) como norma internacional. ^{[ 12 ]} También se publica en RFC 8236.

• J-PAKE RFC 8236
• 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 AC de J-PAKE de curva elíptica en ARM mbed
• Implementación en Java de J-PAKE en Bouncycastle
• J-PAKE: De criptógrafos gastronómicos a malabaristas