¿Por qué se puede forzar bruscamente una clave privada cifrada?

El texto sin formato que consiste en una clave privada RSA se puede reconocer fácilmente, ya que satisface ciertas propiedades matemáticas. En particular:

d = e^-1 mod (p-1)(q-1)

Esto significa que, dada la clave pública y un candidato d , puede calcular

d . e mod (p-1)(q-1)

Si el resultado es 1 , entonces ha encontrado la clave correcta.

La solución es usar una contraseña segura para proteger sus claves privadas.

Esa es una idea que vale la pena investigar.

Como muestra @caf, una clave privada RSA tiene una gran cantidad de estructura interna, que es fácilmente reconocible. Sería muy difícil diseñar un esquema de cifrado basado en contraseñas, de modo que el descifrado de una clave RSA cifrada con la contraseña incorrecta aún produzca algo que parece una clave privada RSA válida.

Sin embargo, esto es relativamente fácil de hacer con las teclas DSA (y también con la variante de curva elíptica ECDSA ). Una clave privada de DSA utiliza parámetros clave (llamados p , q y g ) que no deben ser secretas (También están presentes en la clave pública correspondiente); la única parte realmente privada en la clave es x , un módulo de enteros q . Cualquier módulo entero q es una clave privada válida de DSA. Así que puedes hacer un cifrado basado en contraseña de x de esa manera:

• Elija q para que sea un número de 256 bits (es decir, 2 ²⁵⁵ < q < 2 ²⁵⁶ ).
• Use un cifrado de bloque con bloques de 256 bits (por ejemplo, Rijndael : el AES es Rijndael con bloques de 128 bits y claves de 128 bits, 192 bits o 256 bits, pero el Rijndael original también tiene un modo con bloques de 256 bits).
• Para cifrar x con una contraseña, primero derive una clave de la contraseña (use bcrypt !) y luego encripta x (como una cadena de 256 bits) con Rijndael. Si la cadena resultante no está (cuando se interpreta como un número) en el rango [0..q-1] , encripta nuevamente, y nuevamente, hasta que regreses al rango esperado. En promedio, deberás llamar a Rijndael menos de dos veces, por lo que no es difícil computacionalmente.
• Para descifrar x , simplemente derive una clave de la contraseña escrita y aplique el descifrado de Rijndael. De nuevo, hazlo de forma recursiva hasta que vuelvas al rango [0..q-1] .

Así que esto es factible. Es una buena idea ? La ventaja de este cifrado es que la contraseña ya no puede ser impuesta por un atacante que obtuvo una copia de la clave privada cifrada. Por otro lado, si el atacante también tiene una copia de la clave pública, entonces puede verificar fácilmente que se ha descifrado con la contraseña correcta. Dado que la clave pública debe ser pública, no necesariamente se mantiene tan confidencial como la clave privada. El servidor de destino lo tiene. En realidad, los servidores todos para los que se utiliza la clave privada para iniciar sesión tienen una copia de la clave pública. Así que la clave pública es moderadamente confidencial, en el mejor de los casos. Por lo tanto, la ventaja proporcionada por el "cifrado de contraseña no verificable" como se describe anteriormente, parece tenue. Por otro lado, tiene el siguiente inconveniente: si el usuario escribe mal su contraseña, el servidor sigue siendo interrogado, y SSH ya no puede distinguir entre "usuario hurgó con su teclado" y "hay algo mal en el servidor".

Entonces, mientras que lo que solicita es factible para al menos algunos tipos clave, es comprensible que aún no se haya implementado. No es una victoria indiscutible; es una compensación entre usabilidad y seguridad (perderías un poco de usabilidad para obtener un poco de seguridad).

El archivo de "clave privada" almacena tanto la clave pública como la privada.

El archivo está cifrado con un algoritmo simétrico.

Si robo un pendrive con el archivo, puedo forzar sin conexión la frase de paso, al igual que puedo forzar cualquier otro archivo cifrado. Una vez que descifre el archivo, tengo las claves pública y privada.

Rara vez se usan claves para la autenticación. Normalmente, se utilizan para establecer un canal seguro y confiable, después de lo cual debe autenticarse con un nombre de usuario / contraseña. Robar tu pendrive y descifrar las claves no me dará acceso al servidor, pero me permitirá administrar tu conexión.

No estoy seguro de lo que estaba preguntando, pero espero que esto ayude.

Tenga en cuenta que siempre puede generar la clave pública a partir de la clave privada, por lo que si el atacante tiene la clave pública (que es verosímil, es pública), verificar la respuesta siempre es trivial. Me imagino que esto es fundamental para todos los algoritmos de cifrado asimétrico.

Básicamente, es imposible construir un sistema que haga lo que usted quiere.

Debemos asumir que el atacante tiene su clave pública (la clave pública es pública y está almacenada en muchas máquinas). Dado un candidato para la clave privada, el atacante puede usar la clave pública para probar si este candidato es correcto (por ejemplo, verificando si la clave privada del candidato descifra las cosas que fueron cifradas bajo la clave pública). Por lo tanto, dado un candidato para la contraseña, el atacante siempre podrá verificar su validez recuperando el candidato de clave privada correspondiente y luego comparándolo con la clave pública. Esto no es específico del algoritmo particular de clave pública utilizado, o del formato para almacenar y encriptar la clave privada. Es una limitación fundamental que estará presente en casi cualquier método imaginable para almacenar su clave privada SSH.

En resumen, la razón por la cual SSH tiene este riesgo es porque no hay una manera factible de evitar el riesgo.

Por lo tanto, le corresponde elegir una frase de contraseña segura para proteger su clave privada SSH.

SSH no deriva la frase de contraseña, garantiza que la persona en el otro extremo tenga acceso a alguna información secreta. Si no puede entender las matemáticas directamente, aquí hay un resumen que puede confiar:

I can verify that you know something, without knowing the something myself.

Para obtener una descripción más detallada de lo que ocurre con los intercambios de claves Diffie-Hellman, consulte wikipedia . Básicamente, puede ver que realizar una determinada operación en algunos números da el resultado que esperaría si tuviera la parte secreta de la clave, pero no tiene una manera fácil de derivar el bit secreto. Las claves públicas (en RSA) en realidad contienen toda la información en las claves privadas, pero es difícil de encontrar.

Su pregunta: no entiendo por qué es fácil distinguir el resultado del descifrado correcto del resultado de un descifrado incorrecto.

Supongo que está hablando de un cliente que proporciona una contraseña cifrada al servidor. En la mayoría de los sistemas, si proporciona la contraseña incorrecta 3 veces, el sistema lo bloqueará. En cierto modo, esto es un ataque de denegación de servicio. Por lo tanto, no puede seguir intentando autenticarse hasta que tenga éxito.

Mientras que el cliente y el servidor utilizan el intercambio de claves Diffie-Hellman, que por sí solo está sujeto a ataques de intermediario cuando se usa solo, para calcular la clave de la sesión, cada uno realiza la autenticación. parte demostrando a la otra que tiene la clave privada correspondiente a su clave pública. Pero no se puede autenticar sin la clave privada. No es que la frase de contraseña se use para descifrar la clave privada y puede seguir probando varias frases de contraseña y obtener diferentes claves 'privadas' y puede probarlas una por una hasta que 'funcione'. La frase de contraseña protege la clave privada, análogamente al almacenamiento de un papel con clave privada en un casillero; a menos que pueda abrir el casillero con la llave correcta, no podrá acceder al papel.

Finalmente, incluso si el servidor le permite al cliente la libertad de seguir intentando autenticarse mediante fuerza bruta, es computacionalmente imposible de hacer, ya sea la clave AES de 128 bits (criptografía simétrica) o el RSA de 1024 bits (criptografía de clave pública ). Si los ataques de fuerza bruta fueran factibles, tal esquema criptográfico difícilmente será útil.