Hablar sobre PAKE

Ahora hablemos de la seguridad de la información. Esta publicación está dedicada al lanzamiento del curso "Seguridad de la información criptográfica" , que comenzará el 30 de mayo. Vamos

Primera regla de PAKE: nunca hables de PAKE. La segunda regla de PAKE establece que la primera regla no tiene sentido, ya que PAKE o Password Exchange Authenticated Key Exchange (intercambio de claves con autenticación de contraseña) es una de las tecnologías más útiles que prácticamente nunca se usa en ningún lado. Debe implementarse siempre que sea posible, pero no tan simple.




Para entender por qué estamos hablando de tonterías, veamos un problema real.

Supongamos que trabajo con un servidor que almacena las contraseñas de los usuarios. Hay una forma tradicional de almacenar: cifrar la contraseña de cada usuario y almacenar el resultado en una base de datos de contraseñas. Hay muchas ideas sobre cómo manejar el proceso de hash. La recomendación más común hoy en día es usar una función de hash de contraseña de memoria rígida (como scrypt o argon2 (con una sal única ) para cada contraseña), y luego almacenar el resultado hash. Hay diferentes opiniones sobre qué función hash usar y si puede usar algún valor secreto (llamado "pimienta" ), pero por ahora no hablaremos de eso.

Independientemente del enfoque que elija, todas estas soluciones tienen un talón de Aquiles:
Cuando el usuario regrese para ingresar al sitio, deberá enviar su contraseña (abierta) al servidor para que realice la verificación .

Esta necesidad puede tener consecuencias desagradables si su servidor se ve comprometido o si sus desarrolladores cometen algún error estúpido. Por ejemplo, a principios del año pasado, Twitter pidió a todos sus usuarios (¡y esto a 330 millones!) Que cambiaran las contraseñas , porque resultó que la compañía almacenaba contraseñas textuales (no hash).

Por el momento, el problema de iniciar sesión no contradice de ninguna manera los beneficios del hashing de contraseñas. Sin embargo, debe encontrar una solución mejor: una en la que la contraseña nunca se envíe al servidor en texto claro. La herramienta criptográfica que nos ayudará a lograr esto es PAKE, y en particular, un nuevo protocolo llamado OPAQUE, que cubriremos al final de este artículo.

¿Qué es PAKE?

El protocolo PAKE, propuesto por primera vez por Bellovin y Merritt , es un tipo específico de protocolo de intercambio de claves . Los protocolos de intercambio de claves (o "acuerdos de clave") están diseñados para ayudar a las dos partes (llamémoslas cliente y servidor) a acordar una clave compartida mediante criptografía de clave pública. Los primeros protocolos de intercambio de claves (como el clásico Diffie-Hellman ) no estaban autorizados, lo que los hacía vulnerables a ataques como el hombre en el medio . Una característica distintiva de los protocolos PAKE es que el cliente se autentica en el servidor con una contraseña. Por razones obvias, se supone que el servidor ya conoce la contraseña o el hash, lo que permite la verificación.

Si eso fuera todo lo que necesitara, los protocolos PAKE serían fáciles de construir. Pero lo que hace que PAKE sea realmente útil es que también proporciona protección con contraseña del cliente. Se puede formular una garantía más seria de la siguiente manera: después de un intento de ingresar al sistema (exitoso o no), el cliente y el servidor solo deben saber si la contraseña del cliente coincide con el valor esperado por el servidor, y no más información adicional. Esta es una muy buena defensa. De hecho, esto no es diferente de lo que requerimos de una prueba de divulgación cero .

Una representación idealizada del protocolo PAKE. La entrada de ambos lados incluye cierta aleatoriedad, que no se muestra aquí. El espía no necesita encontrar la clave secreta compartida K, que es aleatoria y no es una función de la contraseña.

Por supuesto, el problema obvio con PAKE es que muchos desarrolladores no quieren ejecutar el protocolo de "intercambio de claves" en primer lugar. Solo quieren asegurarse de que el usuario conozca la contraseña.

Lo mejor de PAKE es que el caso de uso "solo inicio de sesión" es bastante fácil de ejecutar. Supongamos que tengo un protocolo PAKE estándar que permite que el cliente y el servidor acuerden una clave común K. Si conoce la contraseña correcta (y solo en este caso), todo lo que necesitamos implementar es un simple control que ambas partes recibieron La misma llave. (Esto se puede hacer, por ejemplo, si las partes calculan con él alguna función criptográfica y verifican los resultados). Por lo tanto, PAKE puede ser útil incluso si solo desea verificar la contraseña.

SRP: PAKE, sobre qué tiempo se ha olvidado

El concepto PAKE parece proporcionar una ventaja de seguridad obvia sobre el enfoque ingenuo que usamos hoy para ingresar al servidor. ¡Y los métodos en sí mismos son antiguos, en el sentido de que PAKE se conoce desde 1992! A pesar de esto, la luz nunca lo vio. ¿Por qué está pasando esto?

Hay varias razones obvias. Lo más obvio está relacionado con las limitaciones de Internet: es mucho más fácil poner un formulario de contraseña en una página web que implementar una criptografía elegante en un navegador. Sin embargo, esta explicación no es suficiente. Incluso las aplicaciones nativas rara vez implementan PAKE para las operaciones de inicio de sesión. Otra posible explicación está relacionada con las patentes , aunque la mayoría de ellas ya han expirado. Para mí, hay dos razones probables para no tener PAKE:

• Falta de implementaciones PAKE de alta calidad en lenguajes populares, lo que hace que su uso sea problemático;
• Los especialistas en criptografía no transmiten mal la esencia y el valor de su trabajo, por lo que la mayoría de las personas ni siquiera saben que PAKE existe en absoluto.

A pesar de que dije que PAKE no se usa ahora, todavía hay excepciones a las reglas.

Hay un gran protocolo desarrollado en 1998 por Tom Wu (que no debe confundirse con Tim Wu), que se llama "SRP" (abreviatura de "Contraseña remota segura"). De hecho, es solo un PAKE de tres etapas con algunas funciones adicionales que no se implementaron en los primeros trabajos. Hasta donde yo sé, SRP difiere en que es el protocolo PAKE más común en el mundo. Daré dos pruebas de esta declaración:

1. SRP fue estandarizado como TLS ciphersuite e implementado en bibliotecas como, por ejemplo, OpenSSL , aunque nadie parece usarlo especialmente.
2. Apple hace un amplio uso de SRP en su iCloud Key Vault

El segundo hecho en sí mismo podría hacer que SRP sea uno de los protocolos criptográficos más utilizados en el mundo, la cantidad de dispositivos que Apple estampa es tan grande. Y no hay nada gracioso.

El hecho de que la industria haya aceptado el SRP es ciertamente bueno, pero por otro lado, y no muy. Principalmente porque, aunque cualquier respaldo de PAKE es bueno, SRP por sí solo no es la mejor implementación de PAKE. Pensé en adentrarme en la jungla de discusiones sobre SRP, pero este discurso ya se estaba prolongando, y me desvío de la historia sobre un protocolo realmente bueno, del que hablaremos a continuación. Si todavía está interesado en la discusión sobre SRP, lo traje aquí .

En lugar de estos detalles innecesarios, permítanme escribir un breve resumen de mis pensamientos sobre SRP:

1. SRP hace algunas cosas bien. Primero, a diferencia de las versiones anteriores de PAKE, no necesita almacenar la contraseña sin procesar en el servidor (o, de manera equivalente, un hash que podría ser utilizado por un atacante en lugar de una contraseña). En cambio, el servidor almacena un "verificador", que es una función unidireccional del hash de contraseña. Esto significa que una fuga de la base de datos de contraseñas no permite que un atacante reemplace inmediatamente a un usuario solo si no realiza más costosos ataques de diccionario. (El nombre técnico para esto es PAKE "asimétrico").
2. Hay mejores noticias, ¡la versión actual de SRP (v4 v6a) aún no ha sido hackeada!
3. Sin embargo (no se ofenda por los desarrolladores), la arquitectura del protocolo SRP es completamente loca, y sus versiones anteriores fueron pirateadas varias veces, por lo que ahora tenemos la versión 6a. Además, la "prueba de seguridad" en el artículo de investigación original en realidad no prueba nada .
4. SRP se basa actualmente en aritmética de enteros (final), y por varias razones (véase la cláusula 3 anterior) su arquitectura claramente no puede transferirse a una curva elíptica. Esto requiere más ancho de banda y cómputo, por lo que SRP no puede aprovechar las muchas mejoras de rendimiento que hemos desarrollado en complementos como Curve25519 .
5. SRP es vulnerable a ataques previos a la computación porque pasa la sal del usuario a cualquier atacante que pueda iniciar una sesión de SRP. Esto significa que puedo pedirle sal a su servidor y construir un diccionario de posibles hashes de contraseña antes de que el servidor se vea comprometido.
6. A pesar de todas estas deficiencias, SRP es extremadamente simple y también viene con código de trabajo. Además, OpenSSL tiene un código de trabajo que incluso se integra con TLS, lo que lo hace relativamente fácil de implementar.

De todos estos puntos, este último es casi seguramente responsable del (relativamente) alto grado de éxito comercial que SRP logró sobre otros protocolos PAKE. No es perfecto, sino real. Esto es lo que quería transmitir a los expertos en seguridad criptográfica.

OPAQUE: PAKE nueva generación

Cuando comencé a pensar en PAKE hace unos meses, no pude evitar notar que la mayoría de las implementaciones existentes funcionaban bastante mal. O tenían problemas, como en SRP, o requerían que el usuario almacenara la contraseña (o contraseña efectiva) en el servidor, o se mostraba la "sal" al atacante, dando la oportunidad de llevar a cabo el ataque antes de calcular.

Luego, a principios del año pasado, Jarecki, Kravczyk y Xu revelaron al mundo un nuevo protocolo llamado OPAQUE . Tiene una serie de ventajas significativas:

1. Se puede implementar incluso si hay problemas de Diffie-Hellman y logaritmos discretos. Esto significa que, a diferencia de SRP, se puede instanciar fácilmente utilizando curvas elípticas efectivas.
2. Aún mejor: OPAQUE no revela sal a un atacante. Él resuelve este problema usando "PRF olvidadizo" para combinar la sal con la contraseña para que el cliente no reciba la sal y el servidor no reciba la contraseña.
3. OPAQUE funciona con cualquier función de hash de contraseña. Dado que todo el trabajo de hash se realiza en el cliente, OPAQUE puede quitar la carga del servidor, liberando el servicio en línea, por ejemplo, para usar configuraciones de seguridad extremadamente voluminosas, por ejemplo, configurar scrypt con mucha RAM .
4. En términos de recuento de mensajes y exponente, OPAQUE no es muy diferente de SRP. Pero dado que se puede implementar con parámetros más eficientes, es probable que funcione de manera mucho más eficiente.
5. A diferencia de SRP, OPAQUE tiene evidencia de seguridad razonable (en un modelo muy fuerte).

Incluso hay una propuesta de borrador de Internet para OPAQUE, que puede leer aquí. Desafortunadamente, por el momento no sé nada sobre la calidad de la implementación del código, excepto que ya hay varias implementaciones potenciales. Espero que este problema se resuelva pronto.
El protocolo OPAQUE completo se enumera a continuación. En el resto de esta sección, voy a hablar sobre cómo funciona.

Problema 1: Mantener la sal en secreto. Como mencioné anteriormente, el principal problema con las versiones anteriores de PAKE es la necesidad de transferir sal del servidor al cliente (aún no autenticado). Esto permite que un atacante realice ataques antes de calcular dónde puede generar un diccionario basado en los datos recibidos.

El problema aquí es que la sal generalmente se pasa a una función hash (por ejemplo, scrypt) junto con la contraseña. Intuitivamente, alguien necesita calcular esta función. Si es un servidor, entonces el servidor debería ver una contraseña, que mata cualquier significado. Si este es un cliente, entonces necesita sal.

Teóricamente, puede solucionar este problema calculando la función de hash de contraseña utilizando el protocolo seguro de cómputo bipartito (2PC) . En la práctica, es casi seguro que tales soluciones serán ineficaces, principalmente porque las funciones de hashing de contraseñas son complejas y requieren mucho tiempo. Esto aumentará increíblemente la complejidad de cualquier sistema 2PC.

OPAQUE trata esto de la siguiente manera. Deja un hash de contraseña en el lado del cliente, pero no muestra sal. En cambio, utiliza un protocolo especial de dos vías llamado PRF olvidadizo para calcular otra sal (llamémosle salt2) para que el cliente pueda usar salt2 en la función hash pero no pueda acceder a la sal original.

Funciona algo como esto:

El servidor almacena "sal", y el cliente tiene contraseña.salt2 = PRF (sal, contraseña), esto se calcula entre el cliente y el servidor utilizando un protocolo en el que el cliente nunca reconocerá la sal y el servidor sabrá la contraseña. El cliente recibe salt2K = PasswordHash (salt2, contraseña), y todo esto se considera en el cliente.

La implementación real de PRF olvidadizo se puede hacer usando varios elementos de grupo y exponentes. Aún mejor, si el cliente ingresa la contraseña incorrecta, entonces el protocolo recibe un valor ficticio "salt2", que no dice nada sobre el valor real de la sal.

Problema 2: Prueba de que el cliente recibió la clave K correcta. Por supuesto, en este momento el cliente recibió la clave K, pero el servidor no tiene idea de qué es. El servidor tampoco sabe si esta es la clave correcta.

La solución OPAQUE se basa en la vieja idea de Gentry, Mackenzie y Ramzan . Cuando un usuario inicia sesión por primera vez en el servidor, el servidor genera una clave pública y privada confiable para el protocolo de acuerdo seguro (por ejemplo, HMQV) y cifra la clave privada recibida bajo K junto con la clave pública del servidor. El cifrado autenticado resultante (y la clave pública) se almacena en la base de datos de contraseñas.

C = Cifrar (K, clave secreta del cliente | clave pública del servidor)


Versión completa del protocolo OPAQUE, extracto del artículo .

Cuando el cliente quiere autenticarse utilizando el protocolo OPAQUE, el servidor le envía el código C almacenado. Si el cliente ingresó la contraseña correcta en la primera fase, puede obtener K y descifrar este cifrado. De lo contrario, es inútil. Usando una clave secreta cableada, ahora puede ejecutar un protocolo de acuerdo estándar con una clave autenticada para completar el protocolo de enlace. (El servidor verifica la entrada de los clientes al compararlos con su copia de la clave pública del cliente, y el cliente hace lo mismo).

Ahora pongamos todo junto. Todos estos pasos se pueden combinar en un protocolo, que tiene el mismo número de pasos que SRP. Si no presta atención a los pasos de verificación, se verá como el protocolo anterior. En principio, la idea es solo en dos mensajes: uno del cliente y el segundo se envía de vuelta al servidor.

El último aspecto del trabajo de OPAQUE es que tiene buena evidencia de seguridad que nos dice que el protocolo resultante puede considerarse seguro si tomamos uno o más logaritmos discretos en un modelo de oráculo aleatorio, que es una suposición estándar, que aparentemente , tiene lugar en la configuración con la que trabajamos.

Conclusión

En resumen, tenemos una tecnología confiable que puede hacer que el proceso de usar contraseñas sea mucho más fácil, y también puede permitirnos manejarlas de manera más eficiente, con muchos parámetros de hash y mucha carga de trabajo en el lado del cliente. ¿Por qué esto no se usa en todas partes? Quizás en los próximos años todo cambie. El tiempo lo dirá.

De acuerdo con la tradición establecida, estamos esperando sus comentarios y los invitamos a visitar el día de puertas abiertas , que se llevará a cabo el 27 de mayo por nuestra maestra, la criptoanalista Elena Kirshanova .