Almacene la clave privada en el servidor, luego use k1 para iniciar sesión, k2 para verificar HMAC y k3 para descifrar la clave privada

Question

Almacene la clave privada en el servidor, luego use k1 para iniciar sesión, k2 para verificar HMAC y k3 para descifrar la clave privada

#1 de bethlakshmi (2 votos)
#2 de KeithS (1 votos)

3

Estoy trabajando en un programa de prueba de concepto para cifrar el correo electrónico con menos dificultad para los usuarios finales con un proceso como:

Para crear una cuenta:

Genere un salt aleatorio y IV, y obtenga una contraseña del usuario.
Genere una clave de 384 bits con PBDKF2-HMAC-SHA512 (o quizás scrypt?).
Dividir eso en tres claves de 128 bits (k1, k2, k3).
Genere un par de claves RSA (para GPG ).
Encripta la clave privada con k3.
Genere un HMAC de la clave privada cifrada, utilizando k2.
Envíe la sal, IV, k1, número de iteraciones, clave pública, HMAC y clave privada encriptada al servidor.

Para iniciar sesión:

Solicite nuestra sal y la cantidad de iteraciones del servidor (tal vez haga algo aquí para evitar la pérdida de direcciones de correo electrónico).
Regenera k1, k2, k3 con PBKDF2.
Envíe k1 al servidor, que lo compara con su versión almacenada. Esto se utiliza para evitar que la clave cifrada sea pública. En teoría, esto no debería importar, pero parece mejor proteger los datos cifrados por si acaso.
Si k1 coincide, el servidor devuelve una clave privada cifrada AES-128 y una IV, con un HMAC-SHA-1 MAC.
Use k2 para verificar el HMAC.
Use k3 para descifrar la clave privada.

Para futuros inicios de sesión, podemos simplificar las cosas ya que el servidor tiene la clave pública y nosotros tenemos la clave privada.

La idea es que incluso si el servidor está comprometido, la única información que tiene es k1, la sal, la IV y la clave privada cifrada, pero para alterar la clave, necesita k2 y descifrar la clave necesita k3.

Dado que el cliente solo necesita descifrar la clave una vez (y luego puede almacenarla en el conjunto de claves de su sistema operativo), el número de iteraciones podría ser realmente alto.

¿Tengo razón al suponer que esto protegería a los clientes contra un servidor comprometido? Creo que los únicos vectores de ataque restantes serían piratear al cliente, forzar brutalmente la contraseña (lo que debería ser increíblemente difícil, ya que podemos usar muchas iteraciones de PBKDF2) y el criptoanálisis de la manguera de goma.

EDITAR: Más específicamente, esto está destinado a proteger la contraseña de un usuario, la clave privada y los correos electrónicos cifrados de un atacante, incluso si ese atacante está trabajando con el propietario del servidor. Los correos electrónicos no cifrados son básicamente imposibles de proteger, ya que un atacante que controla el servidor podría simplemente salvarlos a medida que ingresan. La ingeniería social y el criptoanálisis de manguera de goma son relevantes, pero mi objetivo fue principalmente reducir los posibles ataques a los que pueden No te mantengas en secreto.

authentication encryption pbkdf2

pregunta Brendan Long 22.06.2013 - 23:00

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication encryption pbkdf2

¿Existen implementaciones de algoritmos de hashing de contraseña para los marcos principales que utilizan hardware especializado como GPU / FPGA? Usando la clase Apple NSKeyedArchiver sin cifrado para guardar los datos de puntuación localmente

score 2 · Answer 1

Hay un par de problemas:

1 - En la secuencia de inicio de sesión - paso # 4 - está enviando k1 para verificación en el servidor. El servidor no tiene una copia de k1. De acuerdo con el hilo de creación de la cuenta, el paso 3 (generar k1, k2, k3) ocurrió presumiblemente del lado del cliente y no formó parte de la transmisión del servidor (paso 7)

2: si almacena k1, entonces es efectivamente una contraseña: la repetición del valor de k1 es todo lo que se necesita para iniciar sesión en el paso 4.

3 - Lo que está entre el atacante y la capacidad de imitar al usuario es el cifrado AES de 128 bits de la clave privada. Se almacena en el servidor y, por lo tanto, si el servidor está descifrado, se puede obtener la clave cifrada. Si también ofrece k1, podría ofrecer la posibilidad de obtener datos adicionales. Hay básicamente dos cálculos posibles que el atacante puede calcular hasta que encuentre un combo ganador:

AES descifrar (test-k3, clave privada cifrada) = crea una clave que puede descifrar cualquier correo electrónico cifrado.
gen clave con PBDKF2-HMAC-SHA512 (sal, # interaciones, prueba-contraseña) = k1 (conocido), k2 (desconocido), k3 (desconocido)

Ahora estamos en el reino donde la pregunta es "¿qué tan fáciles son esas cosas?" y realmente no lo se Esa es una buena pregunta para crypto.SE: estamos en el mundo de la dificultad de la criptografía, que no es mi fuerte.

4: no niega el valor de ver las transmisiones y la colocación de servidores. Si el atacante ha pirateado la cuenta / el servidor de inicio de sesión, ¿qué más se encuentra en ese servidor? Si también sirve el servicio de correo electrónico o las transacciones de usuarios con privilegios posteriores a la autenticación: su problema no se encuentra en los pasos anteriores, son los otros activos de alto valor. Además, observar cuando un usuario inicia sesión y su patrón general de comportamiento, pruebas y errores proporcionará suficiente información de ingeniería social que la parte molesta matemática de la piratería criptográfica es irrelevante. Si puedo romper el servidor, llame al usuario y pido disculpas, y pídale que me diga su contraseña por teléfono, el trabajo de pirateo de la criptografía está obsoleto.

score 1 · Answer 2

Algunas cosas para pensar:

¿Cuáles son tus vectores de ataque identificados? Dicho de otra forma, ¿qué tipos específicos de compromiso para la seguridad de su información está tratando de evitar?
Tu esquema es muy complejo. Cuanto más complejo es un esquema, más partes móviles tiene, más posibles debilidades tiene y más fácil es pegar las obras. ¿Existe una forma más fácil de protegerse de los vectores de ataque identificados?
El factor limitante aquí es la fortaleza de la contraseña de su usuario y su susceptibilidad a la ingeniería social (no tiene que ser una criptografía de manguera de goma). Estas cosas son el eslabón débil de la cadena, por lo que todo lo que puedes hacer es asegurarte de que sea el único eslabón débil (por lo que no es tu culpa que haya entrado un atacante).

Más específicamente a los aspectos técnicos de este esquema:

Tener un MAC separado es una debilidad; Debido a que verificarlo no está integrado con el descifrado de la clave privada, dependiendo de su modo de cifrado, un atacante podría posiblemente secuestrar su software cliente como un oráculo de descifrado para recuperar la clave privada. Considere usar un modo de cifrado autenticado que integre la verificación del HMAC con el descifrado del mensaje.
Como corolario de lo anterior, hay poco valor en usar una clave diferente para calcular el HMAC del que usó para cifrar el texto cifrado que está digiriendo. Un atacante que puede cambiar los datos en su base de datos puede malgastar el inicio de sesión (habilitando la ingeniería social haciéndose pasar por "recuperar" la cuenta) al codificar el HMAC o la clave, no se necesitan secretos. A alguien que intenta obtener la clave privada no le importará el HMAC, ya que no es necesario descifrar el HMAC para descifrar la clave cifrada. Entonces, considere la posibilidad de combinar k2 y k3 en una única clave de 256 bits que cifrará la clave RSA privada mediante un modo autenticado.
El servidor no funciona en este esquema más allá de los datos coincidentes, y no mencionó la protección del tráfico entre el cliente y el servidor. Por lo tanto, el esquema es explotable para obtener un volcado de datos al observar las solicitudes de inicio de sesión entrantes y reproducirlas, sin tener que conocer ningún secreto utilizado para generar el hash de contraseña (k1) que se está transmitiendo. Considere requerir una conexión segura entre el cliente y el servidor para mitigar esto.