Copia de seguridad en línea: ¿cómo podrían ser compatibles el cifrado y la deduplicación?

No he pensado en los detalles, pero si se utilizara un hash seguro del contenido del archivo como la clave, entonces (y solo) los clientes que "sabían el hash" podrían acceder al contenido.

Esencialmente, el almacenamiento en la nube actuaría como una tabla de arco iris parcial (muy escasa, de hecho) colectiva para la función de hashing, permitiendo que se "invierta".

Del artículo: "Incluso si la RIAA y la MPAA tocaran las puertas de Bitcasa, citaciones en mano, todo lo que tendría Bitcasa es una colección de bits encriptados sin medios para descifrarlos". - true porque bitcasa no contiene la asignación de objectid / filename-to-hash / key; solo sus clientes lo hacen (lado del cliente). Si la RIAA / MPAA conociera los hashes de los archivos en cuestión (bien conocidos por ejemplo, los MP3 de canciones específicas) podrían descifrar y probar que tenía una copia, pero primero necesitarían saber qué objeto de almacenamiento en la nube / archivo guardado qué canción.

Los clientes deberían mantener el hash para cada objeto almacenado en la nube, y su nombre local, por supuesto, para poder acceder y descifrarlo.

Con respecto a algunas de las otras características reivindicadas en el artículo:

• "compresión": no funcionaría en el lado del servidor (el contenido cifrado no se comprimirá bien), pero podría aplicarse en el lado del cliente antes del cifrado
• "accesible desde cualquier lugar": si el mapeo de objid-to-filename-and-hash / key está solo en el cliente, entonces los archivos son inútiles desde otros dispositivos, lo que limita la utilidad del almacenamiento en la nube. Podría ser resuelto por ej. también almacena la colección de tuplas objid-to-filename-and-hash / key, del lado del cliente cifrada con una frase de contraseña.
• "algoritmos de deduplicación patentados": debe haber más cosas que las anteriores para justificar una patente, ¿posiblemente la deduplicación en un bloque, en lugar del nivel de archivo?
• la RIAA / MPAA podría venir con una citación y una copia cifrada con su propio hash de cualquier canción / película de la que sospechan que la gente tiene copias. Bitcasa podría entonces confirmar si ese archivo ha sido almacenado o no. No podrían descifrarlo (sin RIAA / MPAA dándoles el hash / clave), y (especialmente si no están aplicando cuotas por usuario porque ofrecen "almacenamiento infinito") no podrían haber guardado registros de Qué usuarios lo subieron / bajaron. Sin embargo, sospecho que se les puede solicitar que eliminen el archivo (según las reglas de seguridad del puerto de DMCA) o posiblemente retengan el contenido, pero luego registren cualquier cuenta que lo cargue o descargue en el futuro.

El anuncio comercial al que se vincula, y el sitio web de la compañía, son realmente escasos de información; y agitar "20 patentes" como prueba de competencia es extraño: las patentes no prueban que la tecnología sea buena , solo que hay algunas personas que apostaron unos pocos miles de dólares con la idea de que la tecnología vende bien .

Veamos si hay una forma de hacer realidad estas promesas.

Si los datos están cifrados en el lado del cliente, debe haber una clave secreta K_f para ese archivo. La cuestión es que Bitcasa no sabe K_f . Para implementar la deduplicación y el almacenamiento en caché y, lo que es más importante, compartir, es necesario que cada usuario cifre un archivo dado f termine usando el mismo K < sub> f . Hay un truco ingenioso que consiste en usar el hash del archivo en sí, con una función de hash adecuada (por ejemplo, SHA-256), como K_f . Con este truco, el mismo archivo siempre terminará en el mismo formato cifrado, que luego se puede cargar y desduplicar a voluntad.

Luego, un usuario tendría una tienda local (en su computadora) de todos los K_f para todos sus archivos, junto con un ID de archivo. Cuando el usuario A desea compartir el archivo con el usuario B, el usuario A "hace clic derecho para obtener la URL de uso compartido" y lo envía a B. Presumiblemente, la URL contiene el ID de archivo y K _f . El texto dice que tanto los usuarios A como B deben ser usuarios registrados para que la compartición funcione, por lo que la "URL" probablemente sea interceptada, en la máquina de B, por algún software que extrae la ID y K _f de esa "URL", descarga el archivo del servidor y lo desencripta localmente con el conocimiento recientemente adquirido de K_f .

Para obtener una mayor capacidad de recuperación y facilidad de uso, el conjunto de claves conocidas K_f para algunos usuarios también se puede almacenar en los servidores, por lo que solo debe " recuerde "una sola tecla K_f , que puede transferir de una computadora a otra.

Por eso digo que lo que Bitcasa promete es posible, ya que sabría cómo hacerlo y no hay nada realmente nuevo o tecnológicamente avanzado aquí. No puedo afirmar que esto es lo que hace Bitcasa , solo que así es como lo haría. La parte "difícil" es la integración de eso en los sistemas operativos existentes (de modo que "guardar un archivo" desencadena el proceso de encriptación / carga): algunos trabajos, pero apenas valen una patente, y mucho menos 20 patentes.

Tenga en cuenta que usar K _f = h (f) significa que puede intentar una búsqueda exhaustiva en el contenido del archivo . De todos modos, esto es inevitable en un servicio con desduplicación: al "cargar" un nuevo archivo y simplemente sincronizar la operación, puede saber si el archivo ya era conocido del servidor o no.

Bruce Schneier abordó el tema en mayo enlace relacionado con el problema de Dropbox en esa semana. TechRepublic ofrece un excelente documento técnico de 7 páginas sobre el tema por el precio de un correo electrónico inscríbase en enlace .

El documento se centra en el canal lateral y los ataques de canal secreto disponibles en la deduplicación en la nube. Los ataques aprovechan la deduplicación entre usuarios. Por ejemplo, si sabía que Bob estaba usando el servicio y su contrato de salario de plantilla estaba allí arriba, podría crear versiones del mismo hasta que alcanzara su salario. Éxito indicado por el tiempo que tardó en cargarse el archivo.

Por supuesto, su protección es cifrar antes de utilizar el servicio. Sin embargo, eso evitará el ahorro de costos para el servicio que lo hace económicamente viable, ya que eliminaría casi todas las oportunidades de deduplicación. Por lo tanto, el servicio no fomentará la elección.

Además de las otras buenas respuestas aquí, me gustaría señalarle los siguientes dos trabajos académicos, que se publicaron recientemente:

• Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber y Edgar Weippl, Dark Clouds on the Horizon: uso de Cloud Storage como Attack Vector y Online Slack Space , Usenix Security 2011.

  Este documento describe cómo Dropbox elimina la duplicación e identifica los ataques al mecanismo. Proponen una forma novedosa de defenderse contra algunos, pero no todos, de estos ataques, en base a requerir que el cliente demuestre que conoce el contenido del archivo (no solo su hash) antes de que se les permita acceder al archivo.

• Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Canales laterales en servicios en la nube, el caso de la deduplicación en el almacenamiento en la nube , IEEE Security & Revista de privacidad.

  Este documento analiza tres servicios de almacenamiento en la nube que realizan la eliminación de duplicados (Dropbox, Mozy y Memopal), y señala los riesgos de seguridad y privacidad que se derivan. Proponen una defensa novedosa contra estos riesgos, basada en garantizar que un archivo se duplique solo si hay muchas copias, lo que reduce la fuga de información.

Estos documentos parecen directamente relevantes para su pregunta. También demuestran que hay espacio para la innovación en mitigaciones no triviales para los riesgos de la deduplicación ingenua.

El cifrado y la desduplicación entre usuarios arbitrarios no son compatibles si le preocupa distinguir ciertos plaintexts. Si no está preocupado por este tipo de ataques, puede ser seguro.

Si los datos solo se desduplican para un determinado usuario, el servidor no sabe nada sobre la equivalencia de plaintexts y los ataques que quedan son realmente menores.

Si los datos se desduplican entre un círculo de amigos que comparten algo que no es conocido por el proveedor de servicios (se puede hacer automáticamente), solo las personas de ese círculo de amigos pueden distinguir plaintexts (a través del tiempo, etc.).

Pero si los datos se desduplican entre todos los usuarios, todo el atacante hipotético, que desea saber a qué plaintexts se accede, debe hacerlo es almacenar el archivo en la nube y luego monitorear qué cuentas de usuario están accediendo a la nube. mismos datos Claro, el servicio puede simplemente "no registrar" las cuentas de usuario / direcciones IP que acceden a los datos, pero eso no tiene nada que ver con el cifrado y la misma "protección" permanecería incluso si los archivos fueran de texto simple.

Ninguna de las otras respuestas dadas aquí parece proponer algo que detenga el ataque de este y creo que Bitcasa tampoco lo hace. Sin embargo, me encantaría que me demostraran que estoy equivocado.

(Nota: hay algunas formas de lograr algo parecido a esto: se han publicado algunos artículos sobre el almacenamiento seguro en la nube que utilizan todo tipo de técnicas innovadoras, pero estas son investigaciones y estudios nuevos. es probable que la mayoría de ellos se rompan o se muestren poco factibles bastante rápido. No confiaría mis datos en ninguno de ellos todavía.)

La misma pregunta se hizo en el intercambio de pila de criptografía. Por favor vea mi respuesta allí, ya que hay una sutileza que es fácil de pasar por alto y que ha sido cuidadosamente analizada por el proyecto de código abierto Tahoe-LAFS: enlace

Aparte de la gran respuesta @Misha que acaba de publicar en el 'hash conocido', el cifrado del lado del cliente elimina de manera efectiva cualquier otra forma de desduplicar a menos que haya una clave de custodia, lo que potencialmente podría causar otros problemas logísticos de todos modos.

tienes toda la razón! Utilizar solo el cifrado convergente no es una buena opción, incluso para archivos no originales enlace Afortunadamente, parece que hay una solución para combinar el cifrado y la deduplicación. Se llama ClouDedup: enlace