¿Es posible la criptografía del lado del servidor con acceso de solo usuario para los servicios de correo electrónico?

1

Encontré el Escritura de alta escalabilidad de Lavabit y sentí curiosidad.

  

¿Utiliza tecnologías o algoritmos especialmente interesantes?

     

La forma en que ciframos los mensajes antes de almacenarlos es relativamente única.   Solo conocemos un servicio comercial y un producto comercial.   Eso asegurará los datos del usuario utilizando un cifrado asimétrico antes de escribir   a disco. Básicamente generamos claves públicas y privadas para el usuario.   y luego encriptar la clave privada usando un derivado del texto plano   contraseña. A continuación, ciframos los mensajes de usuario utilizando su clave pública antes   escribiéndolos en el disco.

Por lo que sé, Lavabit también ofreció un cliente de correo web. ¿Es posible la criptografía del lado del servidor donde solo el usuario puede descifrar los mensajes pero se ofrece un acceso de correo web al mismo tiempo? Lavabit afirmó que no podría recuperar la contraseña si se perdería, lo que significa que tampoco se pudo restablecer, ¿verdad?

Esto significaría que las credenciales del usuario deben almacenarse en la base de datos para autenticarlo. Esta misma contraseña se usa para generar el derivado, que luego se usa nuevamente para descifrar la clave privada, que luego se puede usar para descifrar los correos electrónicos cifrados de clave pública.

¿Eso no significa que Lavabit esté / estuviera en posesión de las contraseñas? En mi opinión, esto solo tendría sentido si se requieren dos contraseñas. Una contraseña para autenticar al usuario y una frase de contraseña para desbloquear la clave privada. Donde la frase de contraseña, a diferencia de la contraseña, no se almacena en la base de datos, pero el usuario la ingresa cada vez sin guardarla en alguna parte.

Similar que encontré en las Preguntas frecuentes de MyKolab.com :

  

Algunos otros proveedores afirman usar la criptografía del lado del servidor para almacenar mi   Datos encriptados para que no puedan acceder a ellos. ¿También haces eso?

     

Actualmente no tenemos planes para hacer eso. La razón es simple.   Con el cifrado del lado del servidor, el proveedor retiene los datos cifrados,   la clave y la frase de contraseña, ya que los tres necesitan pasar por la web   Interfaz y estar disponible en el servidor. Así que el proveedor tiene   Acceso a todos los datos a pesar del cifrado.

     

No creemos en engañar a nuestros usuarios de esta manera.

     

La única solución sería el cifrado del lado del cliente de todo, pero   eso es muy difícil de implementar y hay todo un conjunto de estándares   falta en el lado del navegador para hacer esto correctamente y de forma segura, también   teniendo en cuenta que el boxeo de arena en los navegadores no funciona desde una   Perspectiva de seguridad. Por lo tanto, sugerimos utilizar clientes nativos tales   como Kontact y use GnuPG para el cifrado de extremo a extremo.

Entonces, ¿qué quiso decir Lavabit cuando dijeron que recuperar los mensajes no hubiera sido posible? ¿Cómo puede funcionar esto de manera segura, respectivamente, solo como lo ha declarado MyKolab.com?

    
pregunta platzhirsch 14.08.2013 - 12:22
fuente

1 respuesta

5

El "Relato de alta escalabilidad de Lavabit", al que se vincula, incluye este pasaje, que es esclarecedor:

  

Debido a que necesitamos la contraseña de texto sin formato para descifrar la clave privada de un usuario, no admitimos la autenticación de contraseña segura. Decidimos admitir SSL en su lugar (que encripta todo, no solo la contraseña).

Así que aquí está lo que hacen:

  • Cuando el usuario se registra, elige una contraseña y la envía al servidor.
  • Se genera un par de claves asimétricas (aparentemente ECDH ) en el servidor.
  • El servidor almacena la clave pública de ECDH y también la clave privada, pero la clave privada se cifra simétricamente con una clave derivada de la contraseña del usuario. La contraseña del usuario en sí está no almacenada.
  • Cuando se recibe un correo electrónico (a través de SMTP ), lo cifran con el usuario Clave pública ECDH (con cifrado híbrido , posiblemente ECIES o una variante de las mismas). Pueden hacerlo porque tienen la clave pública.
  • Cuando un usuario se conecta, a través de POP , IMAP o el correo web, se usa autenticación simple: el usuario muestra su contraseña. El servidor luego usa la contraseña para descifrar la clave privada de ECDH almacenada; Si la clave privada se obtiene y coincide con la clave pública almacenada, el usuario se considerará autenticado.
  • Mientras el usuario esté conectado, la clave privada de ECDH se mantiene en la memoria RAM del servidor, y el servidor la utiliza para descifrar los correos electrónicos del usuario para él.

Por lo tanto, el servidor nunca almacena en su disco la contraseña del usuario o la clave privada ECDH del usuario en forma clara. Sin embargo, obtienen ambos en algún momento, pero mantienen estas cosas en la memoria RAM, a salvo de fugas a través de cintas de copia de seguridad robadas o ataques de inyección de SQL.

"Autenticación de contraseña segura" es un tipo de sistema de desafío-respuesta donde el cliente no muestra la contraseña, pero calcula una respuesta a un desafío, la respuesta utilizando tanto el valor de desafío (enviado por el servidor) como la contraseña. Este tipo de protocolo es una protección parcial contra la revelación de contraseñas cuando la identidad del servidor no está garantizada (desde el punto de vista del cliente) o la conexión entre el cliente y el servidor podría interceptarse. Dado que Lavabit usa la contraseña del usuario tanto para la autenticación como para el descifrado del lado del servidor de la clave privada ECDH, no pueden admitir la "autenticación de contraseña segura". Sin embargo, la "autenticación de contraseña segura" implica el almacenamiento de texto simple de la contraseña en el servidor, por lo que no es realmente seguro; Una solución más completa y segura es envolver todo el diálogo en SSL, que es lo que hace Lavabit.

Si Lavabit quiere robar los correos electrónicos del usuario, pueden hacerlo, ya que tienen la clave privada del usuario en la RAM en varios puntos (al generar y cada vez que el usuario se conecta). Sin embargo, deben también tienen los correos electrónicos de texto simple, porque así es como funciona el protocolo SMTP: el servidor necesariamente tiene acceso a los correos electrónicos de texto simple cuando se reciben y cuando se envían. En ese sentido, el uso de la criptografía del lado del servidor en Lavabit no debilita el modelo.

Si desea que el correo electrónico esté protegido de los servidores (todos los servidores involucrados), debe tener criptografía del lado del cliente con el software que no se obtiene dinámicamente del servidor, ya que de lo contrario el servidor todavía podría alimentar Usted software malicioso. Entonces, instale algo como GnuPG . Esto, por supuesto, no funcionará bien con el correo web (el correo web le permitirá leer ... correos electrónicos encriptados) a menos que también instale un complemento de navegador ingenioso como FireGPG , excepto que este complemento está descontinuado y no es compatible.

Sin la criptografía del lado del cliente, diría que lo que Lavabit hace está bien y es lo mejor que se puede hacer. (No comento sobre la implementación , que no he revisado de ninguna manera; estoy describiendo el diseño conceptual .)

    
respondido por el Thomas Pornin 14.08.2013 - 13:14
fuente

Lea otras preguntas en las etiquetas