¿Patrón para permitir que varias personas descifren un documento, sin compartir la clave de cifrado?

60

Configuración actual

Tenemos un servicio que permite a los usuarios cargar documentos a través de un sitio web y almacenar los documentos cargados encriptados en el disco.

Los documentos en el disco se cifran con una clave por usuario, que se genera aleatoriamente al crear la cuenta. Esta clave de documento se almacena en un campo de base de datos que se cifra con la contraseña del usuario como clave. Cuando el usuario (propietario) desea descargar un documento, debe proporcionar su contraseña, que se utiliza para descifrar la clave del documento que, a su vez, se usa para descifrar el documento.

Hemos elegido este patrón para negar la necesidad de volver a cifrar todos los documentos cifrados cuando el usuario elige cambiar su contraseña: solo necesitamos volver a cifrar la clave del documento.

Esta configuración funciona bien (y creemos que es un patrón seguro 1 ).


Cambios requeridos

Desafortunadamente, tenemos dos nuevos requisitos para implementar.

  1. Por ley, estamos obligados a poder descifrar cualquier documento que tengamos en el disco, a solicitud del gobierno;
  2. Alguien ha decidido que el propietario de un documento debería poder compartir el documento cargado con otros usuarios.

No sé cómo implementar esos requisitos mientras mantengo los documentos almacenados con cifrado por usuario.

Entonces, mi pregunta es:

¿Existe un patrón conocido que permita el cifrado de documentos para que una o más partes los puedan descifrar, donde las partes en cuestión se determinarán al cifrar el documento?


Actualizar :

Algunos antecedentes sobre la ley mencionada anteriormente:
De hecho, la ley no establece que estamos obligados a construir una puerta trasera. La ley tipifica como delito el hecho de no entregar la clave a cualquier dato cifrado que tenga 2 si la policía solicita la clave 3 . El resultado de esto es que nosotros, los que alojamos los datos, debemos tener una puerta trasera o enfrentar un proceso judicial en caso de que no podamos descifrar los datos cuando se nos solicite. Sin embargo, aparte de en otros países, tenemos la libertad de comunicar el hecho de que recibimos una orden para descifrar documentos. Lamentablemente, estas leyes no son infrecuentes .

Informar a nuestros clientes y al público:
Como indiqué en un comentario antes, tengo la intención de esforzarme al máximo para asegurarme de que esta política se comunique claramente a nuestros clientes. Las declaraciones de privacidad deben cambiarse y los TOS deben actualizarse.
La conciencia pública por un lado y asegurarme de que las 'malas leyes cuestan dinero' por el otro, son el mejor método que tengo disponible para protestar contra tales leyes.
Sin embargo, al mismo tiempo soy un poco escéptico sobre el impacto de dicha declaración. La mayoría de las personas simplemente no les importa. Al mismo tiempo, muchas personas usan su correo electrónico y bandeja de entrada para almacenar y compartir documentos. Por lo tanto, desde esa perspectiva, nuestro servicio es (aún) una gran mejora (y es la razón por la que algunos de nuestros clientes requieren que sus empleados lo utilicen).


1. Si hay un agujero deslumbrante en este método, no dude en comentarlo.
2. Los abogados han pensado que 'los datos que usted tiene' están destinados a incluir todos los datos almacenados en los dispositivos físicos que posee (no soy un abogado, por lo que esta es mi traducción de lo que concluyeron). 3. Sí, no una oficina de seguridad elegante, pero la policía. Hay algunas medidas de seguridad cuando pueden solicitar una contraseña, pero eso no cambia las implicaciones de esta ley. La gran pregunta es qué sucede cuando realmente olvidó la contraseña de algunos datos. El ministro ha indicado que es responsabilidad del propietario de dichos datos encriptados eliminarlos luego. Pero ningún caso de este tipo ha sido juzgado (a mi entender) en la corte.

    
pregunta Monika 29.10.2014 - 16:31
fuente

6 respuestas

70

Necesita una clave por documento, no una clave por usuario. Bueno, también necesitas claves por usuario, pero eso es otro asunto.

Es decir, cada documento D está cifrado con una clave KD . Esa clave se genera aleatoriamente la primera vez que se importa el documento en el sistema. Cada documento tiene su propia clave. La clave para un documento no se puede inferir de la clave en ningún otro documento.

Cada usuario U también tiene una clave KU . Por lo tanto, si necesita que el documento D sea accesible para los usuarios U , V y W , entonces almacena < em> E K D (D) (cifrado de D con la clave del documento), junto con E < sub> K U (K D ) , E K V (K D ) y EKW (K D ) (cifrado de la clave KD con las claves del usuario U , V y W ). Estas "claves cifradas" tienen un tamaño pequeño (unas pocas docenas de bytes, independientemente del tamaño del documento), por lo que se amplía.

Para hacer las cosas más prácticas, es posible que deba usar cifrado asimétrico para las claves de usuario: cifrado de D utiliza un sistema simétrico conveniente (por ejemplo, AES), pero las "claves de usuario" serán del tipo RSA (u otro algoritmo similar como ElGamal). De esa manera, si el usuario U quiere compartir el documento D con el usuario V , entonces él:

  1. recupera EKU (K D ) del servidor;
  2. utiliza su propia clave privada para descifrarla y recuperar KD ;
  3. cifra KD con V clave pública de V E K V (K D ) .

La belleza de este esquema es que V no necesita estar presente para este procedimiento, ya que solo se usa la clave pública de V .

En ese momento, lo que realmente tiene es OpenPGP , un formato destinado principalmente para correos electrónicos seguros. Los correos electrónicos tienen esta "propiedad compartida" (un correo electrónico puede enviarse a varios destinatarios) y son asíncronos (cuando envía el correo electrónico, el destinatario no está necesariamente disponible de inmediato). Le recomendamos que reutilice OpenPGP, un formato que ha sido revisado por muchos criptógrafos y para el cual ya existen implementaciones.

Cuando tiene un mecanismo para compartir, simplemente puede ponerse como destinatario implícito para cada documento y puede leer todo. Independientemente de los requisitos legales, asegúrese de notificar a los usuarios a través de las "condiciones de uso" que puede leer todo técnicamente; de lo contrario, pueden demandarlo por falta de advertencia.

    
respondido por el Tom Leek 29.10.2014 - 16:48
fuente
19
  

PERO, tenemos dos nuevos requisitos para implementar:

     

Por ley, estamos obligados a poder descifrar cualquier documento que tengamos en el disco, a solicitud del gobierno;

Wow. realmente espero que esté planeando informar a sus usuarios de que va a hacer retroceder su servicio para la aplicación de la ley para que tengan tiempo suficiente para eliminar sus datos de su servicio antes de que eso suceda. Eso sería lo más ético y honorable de hacer.

Si estás siendo forzado a hacer esto, por ejemplo. por carta de seguridad nacional y no se le permite hablar sobre ello debido a una orden de mordaza, entonces sus opciones son limitadas:

  1. Haga que alguien de la compañía filtre esta información de forma anónima a la prensa gratuita (para que en el futuro su servicio sea de puerta trasera).
  2. Cierre el servicio por razones no especificadas. Deles a sus usuarios unas semanas para descargar sus datos antes de que se eliminen para siempre.
  3. Reubique a su compañía, servicio en línea y personal a un país donde no existen leyes de vigilancia draconianas.

Parece que ya tiene un servicio seguro y ha atraído a algunos usuarios orientados a la privacidad. Cualquier cosa sería mejor que instalar intencionalmente una puerta trasera para hacer cumplir la ley y arruinar a sus usuarios. Por lo que sabe, tan pronto como su sistema propuesto esté en vigor para el cumplimiento de la ley, le enviarán una orden para todos los datos de los usuarios.

Sería mejor que cierres la empresa, tomes tu dinero y empieces una nueva empresa, pero esta vez si lo haces correctamente. Aquí están mis sugerencias:

  • Comience su empresa en un país sin estas leyes. Aloje sus servidores y los datos de usuario allí también.
  • Use un cliente de código abierto para que los usuarios confíen en el software que se ejecuta en su computadora / dispositivo. Será muy difícil ocultar una puerta trasera en el futuro si las autoridades lo obligan a hacerlo porque alguien se dará cuenta.
  • Todas las claves privadas de cifrado de datos se almacenan en el lado cliente , nunca en el servidor. Sólo los datos cifrados se almacenan en el servidor. Todo el cifrado y descifrado se realiza en el cliente. El servidor solo guarda datos encriptados. Los usuarios tienen la responsabilidad de hacer una copia de seguridad de sus propias claves privadas. Entonces, su compañía literalmente no puede responder a futuras solicitudes de NSL porque no tiene las claves.
  • Para la autenticación con el servidor y permitir que el usuario almacene y descargue datos cifrados de su cuenta, configure algún tipo de protocolo de autenticación de clave pública por usuario. Quizás el servidor tenga la clave pública de cada usuario. El usuario mantiene la clave privada, luego firma cada carga y solicitud de datos al servidor. Cada cliente puede tener la clave pública del servidor incorporada (fijada) en ella para verificar las respuestas y los datos cifrados descargados desde el servidor.
  • Para compartir archivos con otros usuarios, el usuario puede volver a cifrar su archivo con una nueva clave simétrica y compartir esa clave mediante el intercambio de claves públicas con otros usuarios del sistema. Su servicio podría manejar el intercambio de la clave pública para ellos. Sin embargo, esto es peligroso si los usuarios no pueden confiar completamente en el servidor y si el servidor está en un país con leyes de vigilancia hostiles. Los usuarios no saben si el servidor les está dando una clave pública falsa o real para el otro usuario, por lo que serían vulnerables a los ataques MITM. Esta sería una forma en que la policía podría utilizar para acceder a los datos sin cifrar para los archivos compartidos entre otros usuarios. En este caso, sería más seguro si los usuarios conocieran sus propias claves públicas y pudieran compartirlas en privado con otros usuarios cuando deseen compartir datos con ellos.
  • Use nuevos algoritmos de clave pública que no sean vulnerables a las computadoras cuánticas. No RSA, DSA o curvas elípticas.
  • Utilice la clave simétrica más nueva y los algoritmos hash de autores que se preocupan por la privacidad y no les gusta la vigilancia masiva. Por ejemplo, Bruce Schneier & Daniel J. Bernstein.
respondido por el antispy 30.10.2014 - 01:44
fuente
7

La solución descrita por Tom Leek anteriormente ha sido implementada por el almacén de documentos en la nube de código abierto ownCloud . El modelo de cifrado es descrito aquí .

Como también se señaló en otras respuestas, puede hacer lo mismo con OpenPGP / GPG que describí en una respuesta a una pregunta relacionada . Para repetir brevemente el enfoque estándar:

  1. Cada usuario tiene un par de claves pública / privada
  2. A cada documento se le asigna una clave simétrica única con la cual el documento se cifra y se carga en el contenedor de almacenamiento de respaldo. Esto se llama la clave de archivo
  3. Cada vez que un usuario tiene acceso al archivo, la clave de archivo está cifrada con la clave pública de los usuarios

Específicamente, usted desea poder proporcionar la clave de archivo cuando sea obligado por ley. Esa es una característica de opt-in de ownCloud donde cada clave de archivo también se cifra con la clave pública del administrador del sistema. Con ownCloud, la intención de la función es que el usuario haya olvidado la frase de contraseña de su clave privada y pueda solicitar a la administración que le otorgue acceso al archivo nuevamente.

Una cosa a tener en cuenta es que ownCloud utiliza una base de datos regular para los datos del usuario / grupo y los metadatos del archivo. Los blobs de archivos reales se pueden almacenar localmente o en un proveedor externo como Amazon S3 o Google Drive. Puedes tomar el mismo enfoque; haga que el cliente primero cifre y escriba en un almacén de blob externo fuera de la jurisdicción cifrado con sus propias claves, luego escriba solo la URL (normalmente un GUID de 128 bits) en su sistema. Si bien esto dista mucho de ser ideal en términos de complejidad del sistema, es muy posible que no tenga que cumplir con una ley peligrosa y opresiva; Como solo se pueden ceder punteros a los datos.

Creo que al menos un país que está implementando tales leyes totalitarias está obligando a todos los proveedores de nube offshore a mover sus servidores al país para los usuarios domiciliados en ese país. En cuyo caso, su último recurso es permitir que los usuarios del sistema cifren y escriban en sus propias unidades de red locales y almacenen una ruta de archivo en su sistema. Luego, es responsabilidad del cliente realizar copias de seguridad externas de dichos datos.

    
respondido por el simbo1905 11.01.2015 - 14:21
fuente
4

Como respuesta directa a su pregunta, la respuesta de Tom Leek es acertada.

Sin embargo, te recomiendo que adoptes un enfoque diferente: abandonar el cifrado por usuario.

Seguirá utilizando el cifrado de red (HTTPS), el cifrado de contraseñas y, si lo desea, el cifrado de disco completo en el servidor. Sin embargo, no utilice ningún cifrado más allá de eso. Su aplicación aún decide quién puede ver un documento en particular: el usuario que cargó por primera vez, su administrador con fines legales y cualquier usuario que haya compartido el documento con ellos. En este arreglo, es muy fácil cumplir con todos sus requisitos.

Entonces, ¿por qué sugiero abandonar el cifrado por usuario? Debido a que es complejo y difícil de implementar, y en realidad no agrega mucha seguridad. Realmente no ha explicado qué beneficio quería para el cifrado por usuario, pero supongo que es para mantener los documentos seguros en caso de que el servidor esté comprometido electrónica o físicamente. Ambos deben ser eventos extremos: debe tomar precauciones estándar como el firewall para evitar que esto suceda. Pero si ocurre un evento tan extremo, en realidad un atacante avanzado puede obtener los documentos de sus usuarios de todos modos. Esperan en silencio, a la espera de que sus usuarios inicien sesión, luego capturan la contraseña y descifran los documentos.

    
respondido por el paj28 30.10.2014 - 09:50
fuente
3

Sé que esto ya ha sido respondido, pero ...

Tengo que hacer algo muy similar en mi sitio web.

Los documentos están encriptados pero pueden compartirse con otros usuarios.

Al estar en el Reino Unido, debo compartir los detalles de seguridad con los servicios de seguridad si es necesario, pero solo si los tengo. No tengo acceso a ellos, así que esto no es un problema. (Tampoco se me permite notificar a los usuarios que se han solicitado detalles, ¡el precio de la libertad!)

Cada usuario tiene un par de claves asimétricas que se utiliza para proteger sus documentos. Las claves públicas se almacenan en texto sin formato, pero las claves privadas se cifran utilizando blowfish, con una clave de 128 bits derivada de la contraseña de los usuarios.

Cuando un usuario desea compartir un documento, se lo descifra y se realiza una copia y se cifra mediante la clave pública del usuario objetivo, que es fácil de hacer en texto sin formato. Cuando el usuario de destino inicia sesión, pueden descifrar el documento con su clave privada segura.

Obviamente, si se comparte con varios usuarios, debe haber una copia para cada uno.

    
respondido por el CompanyDroneFromSector7G 31.10.2014 - 12:09
fuente
1

Como los requisitos establecidos obligan a que el cifrado sea esencialmente para "show" (¿teatro de seguridad?) y protección básica contra robos, no protección segura a nivel de documento, recomendaría el cifrado básico de disco completo con LUKS o similar. De esa manera, tendrá la clave maestra para todo el archivo y podrá usar esquemas no basados en encriptación para controlar el acceso por usuario a los diversos documentos. El cifrado por documento realmente no le compra nada a excepción del problema # 1.

También, me gustaría secundar la respuesta de antispy anterior. Como mínimo, el servicio propuesto es muy poco ético y en algunas jurisdicciones incluso se consideraría fraude según los términos del servicio / lo que reveló a sus usuarios.

    
respondido por el madscientist159 30.10.2014 - 03:25
fuente

Lea otras preguntas en las etiquetas