Alojamiento de código de conocimiento cero? [cerrado]

28

A la luz de las recientes revelaciones sobre el monitoreo generalizado del gobierno de los datos almacenados por los proveedores de servicios en línea, los servicios de conocimiento cero están de moda.

Un servicio de conocimiento cero es aquel en el que todos los datos se almacenan cifrados con una clave que no se almacena en el servidor. El cifrado y el descifrado se realizan completamente en el lado del cliente, y el servidor nunca ve ni los datos de texto sin formato ni la clave. Como resultado, el proveedor de servicios no puede descifrar y proporcionar los datos a un tercero, incluso si así lo desea.

Para dar un ejemplo: SpiderOak se puede ver como una versión de Dropbox con conocimiento cero.

Como programadores, confiamos en gran medida y confiamos en algunos de nuestros datos más confidenciales, nuestro código, a una clase particular de proveedores de servicios en línea: proveedores de alojamiento de código (como Bitbucket, Assembla, etc.). Por supuesto, estoy hablando de repositorios privados aquí: el concepto de conocimiento cero no tiene sentido para los repositorios públicos.

Mis preguntas son:

¿Existen barreras tecnológicas para crear un servicio de alojamiento de código de conocimiento cero? Por ejemplo, ¿hay algo en los protocolos de red utilizados por los sistemas de control de versiones populares como SVN, Mercurial o Git que dificultaría (o imposibilitaría) implementar un esquema en el que los datos que se comunican entre el cliente y el servidor se cifran con una clave que el servidor no conoce?
¿Existe algún servicio de alojamiento de código de conocimiento cero en la actualidad?

— HC4 - reinstalar a Monica
fuente

1

Sin el cifrado homomórfico , no veo cómo un sitio de alojamiento de código de conocimiento cero podría proporcionar algún tipo de beneficio sobre una versión de conocimiento cero de drop-box. No creo que nadie haya creado un esquema que sea seguro (es decir, lo suficientemente seguro como para que los expertos confíen en él) y lo suficientemente rápido como para ser utilizable.

— Brian

2

@AndresF. Solo puedo suponer que SpiderOak significa que la generación de diferencias se produce en el cliente, el servidor almacena las diferencias cifradas, y luego la aplicación de diferencia a base ocurre nuevamente en el cliente cuando las diferencias y la base se cifran. Estoy de acuerdo en que su lenguaje es muy poco claro.

— apsillers

2

@apsillers: O podría insertar deliberadamente dicho contenido en un archivo y usarlo para identificar el archivo en sí (por ejemplo, si alguien intentara usar el cifrado para ocultar la piratería).

— Brian

44

No es algo en lo que tenga experiencia, pero puedo imaginar una posible barrera tecnológica para tener un servicio de alojamiento de código de conocimiento cero: ¿no necesitarán todos los usuarios saber / usar exactamente la misma clave? Y si ese es el caso, ¿cuál será el mecanismo de autenticación que garantice los diferentes niveles de acceso de los usuarios?

— CB

2

@gnat: no estoy pidiendo una recomendación. Simplemente estoy preguntando si existe un servicio del tipo que describí. La existencia de dicho servicio proporcionaría evidencia de que las barreras tecnológicas sobre las que pregunto anteriormente en la pregunta son superables.

— HC4 - reinstalar a Mónica el

3

Puede encriptar cada línea por separado. Si puede permitirse filtrar los nombres de sus archivos y las longitudes de línea aproximadas y los números de línea en los que ocurren los cambios de línea, puede usar algo como esto:

https://github.com/ysangkok/line-encryptor

Como cada línea se encripta por separado (pero con la misma clave), los cambios cargados (como generalmente) solo involucrarán las líneas relevantes.

Si actualmente no es lo suficientemente conveniente, puede hacer dos repositorios de Git, uno con texto sin formato y otro con texto cifrado. Cuando se compromete en el repositorio de texto sin formato (que es local), un enlace de compromiso podría tomar el diff y ejecutarlo a través del encriptador de línea mencionado anteriormente, que lo aplicaría al repositorio de texto cifrado. Los cambios en el repositorio de texto cifrado serían confirmados y cargados.

El cifrador de línea anterior es independiente de SCM, pero puede leer archivos diff unificados (de texto sin formato) y cifrar los cambios y aplicarlos al texto cifrado. Esto lo hace utilizable en cualquier SCM que generará un diff unificado (como Git).

— Janus Troelsen
fuente

¿No podrías usar git's smudge-clean para esto?

— svick

@svick: Podría, pero de esa manera, no veo cómo permitiría evitar volver a cifrar todo el archivo. Pero, por supuesto, no importaría mucho el código, ya que los tamaños de los archivos son pequeños. Pero no hay necesidad de un "encriptador de línea", entonces, puede usar cualquier herramienta de encriptación.

— Janus Troelsen

¿No serían muchas muestras de texto (con una estructura conocida) algo que facilitaría atacar la clave? Cada línea en blanco encriptaría lo mismo. Cada inicio y final de un javadoc sería lo mismo. Ahora ya conoce el texto claro y el texto cifrado para algún segmento del código que puede usarse. Es probable que esto no sea útil contra nadie más que para los aficionados (cualquier persona con tipos criptográficos entrenados o suficiente potencia informática podría romperlo con suficiente esfuerzo).

@MichaelT: No, debido a las vías intravenosas. Pruébelo usted mismo :) Usando la implementación vinculada, las líneas se cifran en <IV>,<ciphertext>.

— Janus Troelsen

1

@svick: las líneas se cifran individualmente. Si cambia una línea, toda la línea se volvería a cifrar, pero con un nuevo IV (como siempre). ¡Pero el resto del archivo no será tocado! El cifrado es determinista, pero los IV también son entradas, y se eligen de forma seudoaleatoria.

— Janus Troelsen

1

No creo que haya barreras: considere SVN, lo que se envía al servidor para su almacenamiento es el delta entre la versión anterior y la actual de su código, por lo que cambia 1 línea, solo esa línea se envía al servidor. El servidor lo almacena "a ciegas" sin hacer ninguna inspección de los datos en sí. Si encriptaste el delta y lo enviaste, no habría ningún impacto en el servidor, de hecho, ni siquiera necesitarías modificar el servidor.

Hay otros bits que pueden ser importantes, como las propiedades de metadatos que no se pueden cifrar fácilmente, como el tipo mime, pero otros se pueden cifrar, por ejemplo, comentarios en el registro del historial, siempre y cuando sepa que debe descifrarlos en el cliente para ver. No estoy seguro de si la estructura del directorio sería visible, creo que no sería visible debido a la forma en que SVN almacena los directorios, pero es posible que esté equivocado. Sin embargo, esto podría no importarle si el contenido es seguro.

Esto significaría que no podría tener un sitio web con las diversas funciones de vista de código, sin navegador del repositorio del lado del servidor o visor de registros. Sin diferencias de código, sin herramientas de revisión de código en línea.

Algo así ya existe, hasta cierto punto, Mozy almacena sus datos encriptados con su clave privada (puede usar los suyos, y hacen ruidos sobre "si pierde su propia clave, demasiado malo, no podemos restaurar sus datos para usted ", pero eso está más dirigido al usuario común). Mozy también almacena un historial de sus archivos, para que pueda recuperar versiones anteriores. Donde se cae es que la carga se realiza de forma regular, no se registra cuando lo desea, y creo que descarta las versiones antiguas cuando se queda sin espacio de almacenamiento. Pero el concepto está ahí, podrían modificarlo para proporcionar un control de fuente seguro utilizando su sistema existente.

— gbjbaanb
fuente

Re: "Esto significaría que no podría tener un sitio web con las diversas funciones de vista de código, sin navegador de repositorio del lado del servidor o visor de registro. Sin diferencias de código, sin herramientas de revisión de código en línea". - Aún podría tener estos si la lógica de la aplicación estaba en JS del lado del cliente y le hizo ingresar su contraseña / clave (pero no enviarla al servidor), ¿verdad?

— HC4 - reinstalar a Mónica el

Sí, podría ... Cualquier cosa, siempre y cuando supiera que estaba recibiendo datos cifrados a través de la red. Es solo una limitación obvia del servidor que no puede descifrar los datos.

— gbjbaanb

1

Odio hacer una de esas respuestas "esto no va a responder a tu pregunta" ... pero ...

Puedo pensar en dos soluciones listas que deberían abordar estas preocupaciones.

Hospede un servidor Git privado por su cuenta. Luego, coloque ese servidor en una VPN a la que le da acceso a los miembros de su equipo. Toda la comunicación hacia y desde el servidor estaría encriptada y, por supuesto, podría encriptar el servidor a nivel del sistema operativo.
BitSync también debería hacer el truco. Todo estaría encriptado y en una red enorme que estaría disponible desde cualquier lugar. En realidad, podría ser una muy buena aplicación de toda esta tecnología BitCoin / BitMessage / BitSync.

Por último, la gente de https://security.stackexchange.com/ podría tener más información.

— Pato de goma
fuente

Con respecto a BitSync: ¿sugiere que se use como reemplazo de un sistema de control de versiones, o de alguna manera junto con un sistema de control de versiones? Si es lo primero, entonces seguro, pero eso no es muy interesante. También podría compartir los archivos a través de SpiderOak y sería centralizado, pero sin conocimiento. Si es lo último, ¿cómo?

— HC4 - reinstalar a Mónica el

1

@ HighCommander4 No lo he probado, pero no debería haber ninguna razón para que no funcione ... ¿No podría configurar la sincronización para compartir su carpeta git inicializada, luego simplemente hacer lo normal 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? También podría hacer permisos de nivel git, etc. ¡alguien debería intentar esto!

— Patito de goma

1

Según tengo entendido, la forma en que git pullfunciona es que el servidor le envía un archivo de paquete que contiene todos los objetos que desea, pero que no tiene actualmente. Y viceversa para git push.

Creo que no podría hacerlo así directamente (porque esto significa que el servidor tiene que entender los objetos). Lo que podría hacer en su lugar es dejar que el servidor funcione solo con una serie de archivos de paquetes cifrados.

Para hacerlo pull, descargue todos los archivos de paquete que se agregaron desde la última vez pull, los descifra y los aplica a su repositorio de git. Para hacerlo push, primero tiene que hacerlo pull, para conocer el estado del servidor. Si no hay conflictos, puede crear un archivo de paquete con sus cambios, cifrarlo y cargarlo.

Con este enfoque, terminaría con una gran cantidad de archivos de paquetes pequeños, lo que sería bastante ineficiente. Para solucionarlo, puede descargar una serie de archivos de paquete, descifrarlos, combinarlos en un archivo de paquete, cifrarlos y cargarlos en el servidor, marcándolos como un reemplazo para esa serie.

— svick
fuente