Ipfs: permisos

En una investigación más profunda, creo que lo único que falta es la propiedad de un blob (posiblemente ninguno) y los permisos de lectura basados ​​en una lista (o varias) controladas por el propietario (si no ninguno). Esto se puede construir sobre IPFS sin modificar el fs subyacente.

Sería mejor usar capacidades en su lugar. Ejemplo ingenuo: cifre el archivo con algún secreto y comparta el secreto con las personas que tienen "permiso de lectura".

Exactamente. Tapas. Ver e-rights y Tahoe-LAFS

—
Enviado desde buzón

El viernes 4 de septiembre de 2015 a las 16:46, Mourad De Clerck [email protected]
escribió:

Sería mejor usar capacidades en su lugar. Ejemplo ingenuo: cifre el archivo con algún secreto y comparta el secreto con las personas que tienen "permiso de lectura".

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/ipfs/ipfs/issues/86#issuecomment-137755902

El cifrado para administrar los permisos es una muy mala idea. Funciona bien en escenarios optimistas pero no se sostiene muy bien en la realidad.

Por ejemplo, suponiendo que un archivo cifrado se distribuya a través de varios nodos y llegue a alguien con intenciones maliciosas, entonces podrían esforzarse en descifrar el archivo. En un mundo optimista, fallan y todos son felices. ¡Sí!

En el mundo real, si el archivo se creó hace un tiempo, es posible que se haya encontrado una falla en el algoritmo de cifrado desde entonces. O bien, es posible que el nuevo hardware de descifrado especial esté ampliamente disponible. Esto reduciría drásticamente la complejidad del proceso de descifrado. Debido a que nadie es realmente el propietario del archivo, no hay forma de extraer el archivo existente y reemplazarlo con una nueva versión cifrada con un algoritmo nuevo y más seguro. Incluso si pudiera hacer algo como esto, lo que le dice que el nodo malicioso no mantendrá la versión anterior del archivo de todos modos.

Al final, nada mejor que evitar que el archivo salga de la red cuando se trata de seguridad y privacidad.

En lugar de permisos de archivo, creo que sería más significativo hacerlo a nivel de nodo. Básicamente, un nodo debería poder rechazar conexiones de otros nodos en función de un paradigma de lista blanca/lista negra. Esto permitiría a las personas crear una red IPFS privada, un poco como rastreadores privados de bit torrent, para compartir datos confidenciales y evitar filtraciones a un nodo malicioso.

Tal vez incluso podríamos considerar una lista negra de nodos distribuida globalmente, almacenada en el mismo IPFS, para bloquear automáticamente los nodos maliciosos conocidos. Sin embargo, no sé qué tan útil sería esto considerando que una identidad de nodo puede ser simplemente regenerada a través de un nuevo par de claves.

También estoy de acuerdo en que el cifrado es la forma más sencilla de hacer esto.
Los esquemas de cifrado se pueden piratear, pero también los nodos. Los usuarios simplemente necesitan
ser consciente de estas potencialidades cuando se trata de proporcionar control de acceso
a las gotas.
El 9 de septiembre de 2015 a las 18:48, "Etienne Maheu" [email protected] escribió:

El cifrado para administrar los permisos es una muy mala idea. funciona bien en
escenarios optimistas, pero no se sostiene muy bien en la realidad.

Por ejemplo, asumiendo que un archivo encriptado se distribuye a través
múltiples nodos y llegar a alguien con intenciones maliciosas, entonces podrían
poner un poco de esfuerzo en descifrar el archivo. En un mundo optimista, ellos
falla, y todos son felices. ¡Sí!

En el mundo real, si el archivo se creó hace un tiempo, es
posible que se haya encontrado una falla en el algoritmo de encriptación desde entonces.
O bien, es posible que el nuevo hardware de descifrado especial se vuelva ampliamente
disponible. Esto reduciría drásticamente la complejidad del descifrado.
proceso. Debido a que nadie es realmente el propietario del archivo, no hay forma de extraer el
archivo existente y reemplácelo con una nueva versión cifrada con un
Algoritmo nuevo y más seguro. Incluso si pudieras hacer algo como esto, ¿qué
le dice que el nodo malicioso no mantendrá la versión anterior del archivo
de todos modos.

Al final, nada mejor que evitar que el archivo salga de la red
cuando se trata de seguridad y privacidad.

En lugar de permisos de archivo, creo que sería más significativo hacerlo
a nivel de nodo. Básicamente, un nodo debería poder rechazar conexiones
de otros nodos basados ​​en un paradigma de lista blanca/lista negra. Esto permitiría
la gente crea una red IPFS privada, un poco como un bit torrent privado
rastreadores, para compartir datos confidenciales y evitar filtraciones a un malicioso
nodo.

Tal vez incluso podríamos considerar una lista negra de nodos distribuida globalmente,
almacenado en el propio IPFS, para bloquear automáticamente los nodos maliciosos conocidos.
Sin embargo, no sé qué tan útil sería esto considerando una identidad de nodo
se puede volver a generar simplemente a través de un nuevo par de claves.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment-138988589 .

@ekg La diferencia es que si hay una falla en la forma en que se asegura un nodo, o en el propio sistema de lista blanca, entonces se puede actualizar porque "usted tiene el control" de todos los nodos afectados en su red. Si elige confiar en un nodo, depende de usted asegurarse de que sea seguro. Si aparece una falla, no significa que haya filtrado datos, solo que debe solucionarlo lo antes posible. No puede hacer esto cuando se trata de cifrado en un sistema de archivos distribuido. Si un archivo usa un cifrado roto, no tiene esa segunda oportunidad.

@kawazoe , lea los modelos de capacidad . cada esquema de permisos puede representarse en un sistema de capacidad, por lo que es un sistema _estrictamente superior_. abundan los papeles.

un nodo debería poder rechazar conexiones de otros nodos en función de un paradigma de lista blanca/lista negra. Esto permitiría a las personas crear una red IPFS privada, un poco como rastreadores privados de bit torrent, para compartir datos confidenciales y evitar filtraciones a un nodo malicioso.

esto ya está planeado, pero ortogonal.

@jbenet No estoy diciendo que las capacidades sean malas. Es genial que planees usar este modelo. Lo que digo es que hay una diferencia distintiva entre una capacidad de acceso y una capacidad de lectura (sin importar en qué nivel o cómo se implemente) y que cifrar los datos por sí solo no es suficiente para distinguir los dos.

Tener un nodo que controle qué nodos pueden recuperar un determinado archivo debería ser una cosa. Encriptar los archivos no es bueno en algunos escenarios. Algún ejemplo:
Tenga algún servicio de medios, donde la gente tenga que pagar para acceder al contenido. Para ahorrar ancho de banda, el uso de IPFS tendría sentido, si pudieran garantizar que solo aquellos que pagaron pudieran acceder a los archivos, al menos a través de sus nodos y los nodos de los usuarios honestos. Si los archivos estuvieran protegidos solo por encriptación, solo requeriría un solo usuario que extrajera la clave por medio, y los piratas podrían robar el contenido a través de IPFS. Sin el cifrado asíncrono, ni siquiera podría saber qué usuarios distribuyeron la clave, y con el cifrado asíncrono, no obtiene las ventajas de IPFS. Por favor, reconsidere esto.

Una forma de implementar eso sería que el nodo al que se le solicita el archivo solicite alguna autoridad, si el nodo que intenta acceder al archivo tiene permiso para hacerlo, y actuar en base a eso. Tampoco debería ser demasiado difícil hacer eso, y definitivamente habría usuarios.

@jcgruenhage Podría hacer que todos los usuarios de la red estén en la misma red privada. (consulte https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 para obtener más información sobre redes privadas)

Aparte de eso, posiblemente podría implementar esto como una extensión especial de intercambio de bits, pero luego se encuentra con un par de problemas extraños, tratando de tener contenido 'privado' sin cifrar mientras aún está conectado a la red principal. ¿Qué pasa si alguien fuera del 'grupo permitido' obtiene el archivo a través de algún otro medio (y tiene el mismo hash) y luego un nodo en el grupo permitido lo toma (tal vez sea parte de algún otro archivo que descargaron). ¿Deberían luego entregar los archivos a otros pares que los solicitaron, ya que provienen de una fuente no protegida?

La función de red privada parece interesante, pero obligaría a las personas a tener un nodo completamente separado para acceder a este contenido, y dudo que eso sea lo que la mayoría de la gente querría. Además, ahí tenemos nuevamente una única clave que tendría que ser comprometida, en lugar de una autoridad central que tiene control sobre quién obtiene el archivo.

Acerca de si un nodo debe compartir el archivo si lo obtuvo de otro lugar, ¿cómo deberían saber que el archivo tiene acceso restringido entonces? Supongo que compartirlo entonces está bien, porque lo que estoy tratando de asegurar es solo que si alguien "roba" el archivo, los nodos del servidor que han anclado los archivos y los nodos de los usuarios honestos no hacen sus descargas. súper rápido, porque también pueden descargarlo de todos esos nodos, pero solo de aquellos usuarios no tan honestos.

@jcgruenhage Estoy de acuerdo con la inconveniencia de requerir una red privada.

Además, no está claro cuánto ayuda la red privada porque, al descifrar los datos, un usuario deshonesto podría cargar inmediatamente estos datos en la red pública. Por favor, corrígeme si algo impide esto.

Si la red privada tuviera un máximo de dos nodos, el nodo honesto sabría que el otro nodo está filtrando datos de manera deshonesta. Permita más de dos nodos en la red privada y se perderá el determinismo de fugas.

Incluso en la red privada de dos nodos, el nodo honesto no sabría de inmediato que los datos se están filtrando. Pasaría el tiempo, y en ese momento los datos pueden estar a la mitad de la galaxia.

Una posible solución es agregar una identificación de nodo encriptada/identificación de rastreador durante el descifrado de archivos. Por lo tanto, cada usuario obtiene una copia ligeramente modificada de cada archivo que contiene una identificación de rastreador/nodo única para ellos. Los archivos descifrados siempre serían diferentes del original, pero el original permanecería inmutable y verificable.

Los nodos centinela relacionados con la red privada podrían monitorear la red pública en busca de estos valores de seguimiento. De esta forma, sería posible detectar oportunamente el origen de la fuga.

Esto no evitaría que un nodo en una red privada filtre datos a otra red privada.

No puede evitar que los usuarios compartan los archivos, pero debería poder evitar que usen su infraestructura para eso, pero actualmente no hay ningún sistema de distribución de archivos distribuidos que haga esto todavía.

@jcgruenhage hrm... Ese es un caso de uso interesante. ¿Cada participante
¿El nodo pregunta al servidor sobre cada bloque que se solicita? ¿O la autoridad
servidor envía una gran lista de pares permitidos y qué contenido son
permitido usar?

El viernes 2 de junio de 2017 a las 09:19 ene Christian Grünhage [email protected]
escribió:

No puede evitar que los usuarios compartan los archivos, pero debería poder
evitar que usen su infraestructura para eso, pero actualmente no hay
sistema de distribución de archivos distribuidos que hace esto todavía.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

La característica de redes privadas se basó en un concepto de confianza total de sus pares de PNet.

El siguiente paso podría ser un sistema de capacidad donde puede permitir que algunos nodos accedan a algunos archivos. El actor malicioso en ese esquema podría filtrar solo los datos para los que tiene capacidad, dado que otros nodos que tienen capacidad para un archivo determinado se comportan bien.

@nueverest como dijo @jcgruenhage , una vez que el usuario tiene acceso a un archivo y puede descifrarlo, puede copiarlo en una memoria USB y simplemente publicarlo en otro lugar.

Para mí, lo más importante es la propiedad --- Quiero asegurarme de que el archivo fue modificado por alguien en quien confío. Una forma de hacer esto es encriptar el archivo y usar la clave de descifrado como parte del nombre del archivo --- así que una vez que se calcule la suma hash para el archivo descifrado, sabré que solo alguien que conozca la clave de encriptación podría hacerlo .

Probablemente no sea la mejor manera, pero ¿está implementado en alguna parte?

Los archivos nombrados por /ipfs rutas (por ejemplo, /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) son inmutables, por lo que esto no debería ser un problema. Los archivos nombrados por una ruta /ipns/... son mutables pero están firmados por el autor (el propietario del nombre IPNS).

Sin embargo, si está obteniendo /ipfs/... rutas fuera de banda y desea determinar la autoría, es probable que deba firmar los datos (se puede hacer, por ejemplo, con gnupg).

Nota: Es probable que eventualmente construyamos un sistema de archivos mutable como SUNDR. Es probable que ese sistema de archivos contenga información de autoría. Es probable que también permitamos metadatos arbitrarios en el futuro (que, en teoría, podrían contener información de autoría).

@risen @jbenet ¿Puede describir (o vincular a la descripción) cómo se pueden usar los modelos de capacidad para evitar que los archivos autorizados en un nodo IPFS dejen ese nodo, excepto a un solicitante autorizado? ¿Existe una función de modelo de capacidad explícita en IPFS? He buscado documentación sobre esto pero no he encontrado nada explícito.

Hola, @vdods : dejamos los problemas en este repositorio abiertos como referencia, pero solicitamos que se realice un debate de seguimiento en https://discuss.ipfs.io/ (que se supervisa activamente). Por favor publique allí, ¡gracias!