¿Cuáles son las alternativas a ECDSA para un protocolo de autenticación?

Question

¿Cuáles son las alternativas a ECDSA para un protocolo de autenticación?

#1 de abaj (1 votos)
#2 de Tom Leek (0 votos)

1

En un protocolo de autenticación , S tiene un par de claves públicas / privadas conocidas por C, y S y C han establecido un canal seguro (por ejemplo, utilizando DH o ECDH, o cualquier otro intercambio de claves). protocolo). C desea determinar si el interlocutor de este canal seguro posee la clave privada.

En ECDSA, el par de claves es un par de claves de curva elíptica, y el algoritmo de firma utiliza el esquema DSA (DSA) con la curva elíptica. Se sabe que el esquema DSA tiene algunas propiedades indeseables: las debilidades en el RNG son una preocupación real, considerando que un atacante puede obtener un millón de firmas.

Si solo se requiere autenticación, no necesitamos un esquema de firmas completo (es decir, no se requiere la capacidad de firmar mensajes arbitrarios). ¿Qué esquemas alternativos podrían usarse que eviten la propiedad aterradora que reutiliza la reutilización de la clave de identificación en varias firmas?

Sigue un esquema simple:

C usa IES para cifrar un nonce N1 y lo envía a S (este es el esquema de cifrado integrado de curva elíptica).
S luego envía HMAC(key=Z, N1) a la C, donde Z es un secreto compartido obtenido a través de la fase de intercambio de claves (recuerde, ya hemos establecido un canal compartido utilizando DH o algún otro método).

Esto demuestra la posesión de la clave privada: la clave privada es necesaria para que S obtenga N1 de EIS(N1) . El servidor no es un oráculo de descifrado, no descifra mensajes arbitrarios en nombre de C, sino que responde al HMAC del valor descifrado. Finalmente, debido a que el secreto compartido Z se mezcló, lo que fue determinado conjuntamente por C y S, la firma no se puede usar para realizar un ataque de hombre en el centro: alguien que desea hacerse pasar por S to C es enviado por C, el% cifrado N1 , pero no puede reenviarlo a S para firmar, porque la firma está vinculada al Z del canal.

Pregunta

¿Mi esquema de muerto simple tiene un nombre? ¿Es débil? Parece evitar el problema de la DSA donde varias firmas pueden revelar la clave, ¡pero no he hecho todo el álgebra para estar seguro!
¿Cuáles son las soluciones estándar populares para el problema? FHMQV está patentado, lamentablemente, pero está diseñado exactamente para esta situación, ¿no es así? Supongo que la solución popular parece ser ECDSA (utilizada en TLS, SSH), que espero evitar.

Observaciones

El artículo de Menezes "esquemas de firma de curva elíptica" en la "Enciclopedia de criptografía y seguridad" enumera DSA, Schnorr, Nyberg-Rueppel como los diversos esquemas de firma de curva elíptica conocidos. DSA es el que no me gusta, y Nyberg-Rueppel aparentemente tiene exactamente la misma debilidad que DSA (dos firmas que usan nonces con cualquier bit conocido en la información de clave privada de fuga común). Las firmas Schnorr se ven bien, pero no parecen ser ampliamente utilizadas.
El HCR de Hugo Krawczyk (Hashed Challenge-Response, basado en XCR, Exponential Challenge-Response) también se ve muy prometedor, es una versión reforzada de Schnorr que se supone que es más robusta. Sin embargo, creo que está cubierto por la Patente EP1847062B1 , que expira alrededor de 2025 aparentemente.

authentication cryptography man-in-the-middle key-exchange protocols

pregunta Nicholas Wilson 10.07.2014 - 13:49

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication cryptography man-in-the-middle key-exchange protocols

¿Es seguro almacenar una contraseña pública encriptada en el dispositivo móvil para fines de autenticación? Simplificando SMIME reutilizando la clave pública y privada en las cuentas de correo electrónico

score 1 · Answer 1

1

En la respuesta a la pregunta 2, podría usar RSA en lugar del algoritmo de firma. Mientras que las personas se están moviendo a ECDSA debido a que es más rápido, no hay nada intrínsecamente malo en RSA.

respondido por el abaj 10.07.2014 - 15:26

fuente

score 0 · Answer 2

Aunque un RNG débil es un problema para ECDSA, esto se puede solucionar de dos maneras:

Al usar un RNG no débil (no es tan difícil, en las computadoras modernas; es un sistema integrado barato que puede tener problemas para obtener una fuente de aleatoriedad decente).
Al usar la eliminación aleatoria, como se describe en RFC 6979 . Esto es compatible con ECDSA (usa los mismos pares de claves públicas y privadas; los verificadores no cambian) pero elimina la necesidad de una fuente aleatoria (débil o fuerte) o cualquier estado.

No está claro lo que su protocolo está tratando de lograr; Sospecho que no hace lo que realmente quieres que haga. Al considerar una situación similar a SSH, desea que el cliente y el servidor establezcan un secreto compartido de modo que el cliente (respectivamente el servidor) tenga alguna garantía razonable de que habla con el servidor original (respectivamente el cliente original). En su protocolo, usted asumirá que el cliente y el servidor ya obtuvieron un secreto compartido como Z , con cierta garantía de que Z se produjo con un DH entre el cliente y el servidor, no entre el cliente y el atacante que se hace pasar por el servidor. En otras palabras, usted resuelve el problema asumiendo que ya está resuelto ...

En general, autenticación se trata de asegurarse de que el par en algún protocolo sea realmente el propietario de algún valor secreto específico V . Tomemos el punto de vista del servidor. El servidor quiere saber si un supuesto cliente realmente conoce el valor de V . Los detalles entonces dependen de que V :

Si el valor secreto es conocido por el cliente only , no por el servidor, estamos en el ámbito de la criptografía asimétrica. V debe ser la parte privada de un par de claves privada / pública, y una firma es la herramienta adecuada para eso.
Si tanto el cliente como el servidor conocen el valor secreto, esto se puede hacer con criptografía simétrica.

Con una conexión SSH:

El servidor siempre tiene un par de claves pública / privada; el servidor calcula una firma que el cliente verifica. El cliente autentica el servidor mediante la validación de esa firma con respecto a la clave pública del servidor conocido (los clientes SSH recuerdan las claves del servidor, en el archivo .ssh/known_hosts ).
El servidor puede querer autenticar al cliente con una contraseña. En ese caso, la contraseña es un secreto compartido entre el cliente y el servidor; o el servidor puede almacenar solo una versión con hash de la contraseña. El cliente simplemente envía la contraseña al servidor, y puede hacerlo de manera segura porque en ese momento, el cliente ya ha autenticado el servidor y puede usar la clave DH negociada para cifrar los datos.

Si el servidor prefiere la autenticación de cliente basada en clave, entonces el cliente tiene un par de claves pública / privada, el servidor conoce la clave pública (el archivo .ssh/authorized_keys ) y el cliente calcula una firma.

En SSL / TLS, el "recordatorio de claves públicas" se reemplaza con los certificados X.509. Sin embargo, el concepto central sigue siendo el mismo, y se utilizan firmas.

TLS también es compatible con algunos protocolos de intercambio de claves menos utilizados para ser utilizados cuando el cliente y el servidor desean autenticar entre sí a partir de un secreto compartido, sin utilizar ningún par de claves pública / privada; estos son los PSK conjuntos de cifrado, y SRP (este último es más complejo pero mucho más fuerte cuando el secreto compartido tiene una baja entropía, es decir, es una contraseña ).