Control de acceso condicional de IPFS a través de contratos inteligentes de ethereum

Esta pregunta se trata de combinar IPFS con contratos inteligentes de Ethereum para verificar las condiciones y el cifrado para restringir el acceso.

Compartir archivos uno a uno con un destinatario conocido no es un problema. El 'remitente' encriptaría el archivo con la clave pública del destinatario, lo cargaría en IPFS y enviaría el hash al destinatario. El destinatario podría descifrar el archivo con su clave privada.

Mi problema ocurre cuando trato con (múltiples) partes desconocidas. Si combinamos hash de IPFS con Ethereum, podríamos, por ejemplo, transferir el hash de IPFS a un destinatario que quiera acceder a él y descifrarlo una vez que se hayan cumplido ciertas condiciones, por ejemplo. se ha realizado un pago. Por lo tanto, estos destinatarios no se conocen de antemano, no podemos cifrar el archivo con la clave pública del destinatario.

No podemos simplemente almacenar la clave de descifrado en la cadena de bloques de ethereum, esta clave sería visible para cualquier persona y, por lo tanto, las personas podrían acceder al archivo cifrado en IPFS sin, por ejemplo. pago.

Una solución es guardar las claves de descifrado que pertenecen a sus activos en un almacén de datos centralizado separado, haciendo posible una vez más un único punto de falla para nuestra dApp.

Así que me pregunto si hay alguna solución para resolver este problema, como almacenar de forma segura las claves de descifrado en la cadena.

Muchas gracias.

Entonces el problema es: Alice quiere comprarle un archivo a Bob. Bob almacena el directorio IPFS en la cadena de bloques (de alguna manera encriptada) y luego, cuando Alice paga el contrato inteligente, ¿obtiene el directorio de la dirección IPFS para el archivo?
Secundo la solicitud de @davinci26. ¿Puedes dar más detalles sobre la "condición"? Precisamente, ¿qué quieres que rija el contrato inteligente? ¿Cuáles son las condiciones para la divulgación o divulgación de la información?
Condición: un valor booleano verdadero o falso. por ejemplo, hasPaid true / hasPaid false El problema es que la gente aleatoria quiere comprar un archivo de Bob. Bob almacena el archivo en IPFS (cifrado), cada vez que alguien compra el acceso, obtiene una clave de descifrado y la aplicación del cliente descifra y muestra el archivo. He leído sobre el cifrado basado en atributos, pero no estoy seguro de que sea lo que necesito.
En ese caso, cada pago podría generar un identificador único. Luego, un componente de back-end toma ese identificador y lo combina con un valor producido aleatoriamente. Ese valor aleatorio luego se cifra con la dirección pública de Ethereum del pagador, y esos datos luego se incluyen en una transacción para el destinatario, codificando el valor cifrado en el campo de datos de una transacción. El destinatario puede descifrar esos datos de forma segura. Para descifrar el archivo cifrado, el destinatario debe proporcionar los valores adecuados para reproducir el hash cifrado y descargar correctamente el archivo.
@hextet No creo que el OP esté abierto para usar un componente de back-end, eso no solo hace que el sistema esté centralizado y, en general, no necesita Blockchain en ese momento.
@niksmac, ¿quién dice que los backends no se pueden descentralizar? Su backend podría ser masternodes que son responsables del enrutamiento y el servicio de claves de descifrado. github.com/nucypher/nucypher-kms es una solución para hacer esto pero para KMS. Además, aunque un poco fuera de tema, Blockchain y, lo que es más importante, DLT pueden proporcionar absolutamente beneficios a los sistemas centralizados, no es SOLO para los sistemas descentralizados.
@hextet piensa en la aclaración, tiene sentido.

Respuestas (5)

¿Has revisado el algoritmo de Shamir's Secret Sharing? Puede usar IPFS para compartir los secretos entre todas las partes y usar las claves públicas de ethereum de cada uno para enviarse comunicaciones encriptadas entre sí.

https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

Si no necesita absolutamente usar la cadena principal de ethereum, puede construir una cadena de bloques de quórum privada entre las partes https://www.jpmorgan.com/global/Quorum usando contratos secretos.

Debería mirar el recifrado de proxy y Nucypher .

Básicamente, cómo funciona esto es crear una clave aleatoria y cifrar sus datos con esa clave. A continuación, cifra la clave con su clave pública. y anteponga esta clave cifrada a sus datos. Si luego desea darle a Bob acceso a los datos, cree una clave de recifrado utilizando su clave pública y su clave privada. Luego envía esta clave de recifrado a algún servicio de proxy. Luego, Bob puede enviar la clave de descifrado encriptada que obtuvo desde el principio del archivo al servicio proxy. El proxy volverá a cifrar la clave utilizando la clave de nuevo cifrado. Esta clave encriptada permitirá a Bob y solo a Bob descifrar la clave. Una vez que se descifra la clave, Bob puede usar la clave descifrada para descifrar los datos del archivo.

Esto parece una buena solución, gracias por publicar. Lo investigaré bastante pronto, ya que estamos construyendo un PoC. Gracias !

Apuesto a que sería extremadamente difícil hacer eso con Ethereum. Dicho esto, hay las siguientes opciones que puede consultar:

  1. Filecoin, que es una cadena de bloques sobre IPFS, implementa este tipo de servicio y también admite contratos inteligentes. Hasta donde yo sé, aún no hay implementación, pero el documento técnico ya está disponible. Fuente
  2. Puede ver la solución openbazzar que usa gráficos de confianza para resolver este tipo de problema. Fuente

Ni el 1 ni el 2 son una solución exacta a su problema, pero podrían ser un punto de partida para la discusión.

Bob puede almacenar la clave de descifrado cifrada con su clave pública en la cadena de bloques, por lo que cuando Alice llega con la condición de que ha pagado, Bob lee la clave de descifrado cifrada de la cadena de bloques, la descifra y la vuelve a cifrar con la clave pública de Alice para almacenarla en la cadena de bloques. Que siempre que Alice lo requiera puede descifrarlo con su clave privada.

esta parece ser la solución más fácil propuesta hasta ahora, intentaré probarla uno de los próximos días.
Entonces, para aclarar: 1. Bob almacena en el BC la clave de cifrado del archivo (indicada como k) como enc(k, pk_bob). 2. Alice paga envía el pago 3. El contrato inteligente retiene el pago hasta que Bob envía enc(k, pk_alice) a la cadena de bloques. Si este es el algoritmo, Bob puede hacer trampa y no enviar la clave de descifrado en el tercer paso. ¿Existe algún mecanismo que asegure la relación entre enc(m, pk_bob) y enc(m, pk_alice) en un esquema de cifrado asimétrico?
Como esto depende de cómo haya diseñado el contrato inteligente, debería haber alguna cuenta de depósito en garantía, si alguien hace trampa. Incluso si bob encripta enc(k, pk_alice) , ¿qué pasa si la clave de cifrado proporcionada por bob es incorrecta, o incluso si el contenido del archivo no es el deseado por alice? @Nico podría responder a este funcionamiento interno.

El cifrado de archivos multimedia en general requiere mucho procesamiento y almacenamiento, además de tiempo y energía en general. Pero, de hecho, a la luz de lo que dijo @Kherwa; puede usar la clave pública de Alice para cifrar el archivo y almacenarlo en IPFS. Sin embargo, esto limitará los medios a una sola billetera, el uso de tokens no fungibles ERC721 podría hacer lo mismo por usted, pero con mayor flexibilidad.

En la primera situación, necesita saber cuándo se realiza el proceso de cifrado de medios y, preferiblemente, desea que la URL de IPFS se almacene en algún lugar con el contrato inteligente y la billetera asociada para su posterior recuperación. Le recomiendo que utilice una arquitectura multicontrato basada en acciones que espera después de que se realiza el pago para que su oráculo de etherium le devuelva la llamada cuando finalice el proceso de encriptación y le envíe los detalles de la ubicación de IPFS. Luego puede almacenar esos datos en la transacción de contratos para que Alice pueda recuperar sus medios en cualquier momento y lugar. Creo que este es un método seguro regular, ya que las personas no tienden a regalar sus claves privadas, es decir, su billetera. El posible riesgo de este método podría ser que alguien publique su clave privada y todos puedan acceder al contenido.

En el caso de un token no fungible, la situación es diferente. Un token ERC721 podría representar un producto con una identificación única. Esa identificación única representa un secreto compartido del contenido para evitar que se conozca todo el secreto y, con él, se abuse de él. El beneficio de todo esto es que el producto se puede transferir a otra billetera, lo que permite que el nuevo propietario acceda al contenido. Esto sería muy útil para muchas aplicaciones diferentes, incluido hardware de todo tipo. No estoy seguro de cómo podría implementarse esto en IPFS en este momento y si se necesita algún tipo de testigo para que el secreto compartido funcione. Aunque todavía estoy pensando en cómo implementar dicho sistema, veo mucho potencial. Sin embargo, no te lo tomes en serio.

En ambos casos, el problema real radica en el nodo final cuando los datos del archivo multimedia o del producto, por así decirlo, se descifran y se almacenan en caché para su reproducción. Cualquier cliente que sepa cómo lidiar con este tipo de encriptación y se le permita usar la clave privada es, en cierto sentido, capaz de copiar los medios y distribuirlos fuera de la cadena y verlos en cualquier lugar que desee. Por lo tanto, creo que la opción más razonable es la transmisión en vivo de medios con una especie de estructura de suscripción adjunta o personas que buscan algún tipo de contenido privado.

Control de acceso condicional de IPFS a través de contratos inteligentes de ethereum
RespuestasAquíPolítica de privacidad1y, 1v