IPFS-Zugriffskontrolle durch Ethereum Smart Contracts

Bei dieser Frage geht es darum, IPFS mit Ethereum Smart Contracts zu kombinieren, um Bedingungen und Verschlüsselung zu überprüfen, um den Zugriff einzuschränken.

Eins-zu-eins-Dateifreigabe mit einem bekannten Empfänger ist kein Problem. Der 'Sender' würde die Datei mit dem Pubkey des Empfängers verschlüsseln, sie auf IPFS hochladen und den Hash an den Empfänger senden. Der Empfänger könnte die Datei dann mit seinem Privkey entschlüsseln.

Mein Problem tritt auf, wenn ich mit (mehreren) unbekannten Parteien zu tun habe. Wenn wir IPFS-Hashes mit Ethereum kombinieren, könnten wir beispielsweise den IPFS-Hash an einen Empfänger übertragen, der darauf zugreifen und ihn entschlüsseln möchte, sobald bestimmte Bedingungen erfüllt sind, z. eine Zahlung erfolgt ist. Diese Empfänger sind also vorher nicht bekannt, wir können die Datei nicht mit dem Pubkey des Empfängers verschlüsseln.

Wir können den Entschlüsselungsschlüssel nicht einfach auf der Ethereum-Blockchain speichern, dieser Schlüssel wäre für jeden sichtbar und somit könnten die Leute auf die verschlüsselte Datei auf IPFS zugreifen, ohne z. Zahlung.

Eine Lösung besteht darin, die zu ihren Assets gehörenden Entschlüsselungsschlüssel in einem separaten zentralen Datenspeicher zu speichern, wodurch ein Single Point of Failure für unsere dApp wieder möglich wird.

Ich frage mich also, ob es Lösungen gibt, um dieses Problem zu lösen, z. B. das sichere Speichern der Entschlüsselungsschlüssel in der Kette.

Danke vielmals.

Das Problem ist also: Alice will eine Datei von Bob kaufen. Bob speichert das IPFS-Verzeichnis in der Blockchain (irgendwie verschlüsselt) und wenn Alice dann den Smart Contract bezahlt, bekommt sie das Verzeichnis der IPFS-Adresse für die Datei?
Ich unterstütze die Bitte von @davinci26. Können Sie den "Zustand" näher erläutern? Was genau soll der Smart Contract regeln? Was sind die Bedingungen für die Offenlegung oder Freigabe der Informationen?
Bedingung: Ein boolesches True oder False. zB hasPaid true / hasPaid false Das Problem ist, dass zufällige Leute eine Datei von Bob kaufen wollen. Bob speichert die Datei auf IPFS (verschlüsselt), wenn jemand Zugriff kauft, erhält er einen Entschlüsselungsschlüssel und die Client-App entschlüsselt und zeigt die Datei an. Ich habe über attributbasierte Verschlüsselung gelesen, bin mir aber nicht sicher, ob ich das brauche.
In diesem Fall könnte jede Zahlung eine eindeutige Kennung generieren. Eine Backend-Komponente nimmt dann diese Kennung und hasht sie zusammen mit einem zufällig erzeugten Wert. Dieser Zufallswert wird dann mit der öffentlichen Ethereum-Adresse des Zahlers verschlüsselt, und diese Daten werden dann in eine Transaktion an den Empfänger aufgenommen, wobei der verschlüsselte Wert in das Datenfeld einer Transaktion codiert wird. Der Empfänger kann diese Daten dann sicher entschlüsseln. Um die verschlüsselte Datei zu entschlüsseln, muss der Empfänger die richtigen Werte angeben, um den verschlüsselten Hash zu reproduzieren und die Datei erfolgreich herunterzuladen.
@hextet Ich glaube nicht, dass das OP offen für die Verwendung einer Backend-Komponente ist, die nicht nur das System zentralisiert und im Allgemeinen braucht man dann keine Blockchain.
@niksmac Wer sagt, dass Backends nicht dezentralisiert werden können? Ihr Backend könnten Masternodes sein, die für das Routing und die Bereitstellung von Entschlüsselungsschlüsseln verantwortlich sind. github.com/nucypher/nucypher-kms ist eine Lösung dafür, aber für KMS. Auch wenn es etwas vom Thema abweicht, können Blockchain und vor allem DLT zentralisierten Systemen absolut Vorteile bieten, es ist nicht NUR für dezentralisierte Systeme.
@hextet denkt zur Klarstellung, macht Sinn.

Antworten (5)

Haben Sie sich Shamirs Secret-Sharing-Algorithmus angesehen? Sie könnten IPFS verwenden, um die Geheimnisse zwischen allen Parteien zu teilen, und die öffentlichen Ethereum-Schlüssel der anderen verwenden, um verschlüsselte Kommunikation miteinander zu senden.

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

Wenn Sie nicht unbedingt die Ethereum-Hauptkette verwenden müssen, können Sie unter Verwendung geheimer Verträge eine private Quorum-Blockchain zwischen den Parteien aufbauen https://www.jpmorgan.com/global/Quorum .

Sie sollten sich Proxy- Neuverschlüsselung und Nucypher ansehen .

Im Wesentlichen funktioniert das so, dass Sie einen zufälligen Schlüssel erstellen und Ihre Daten mit diesem Schlüssel verschlüsseln. Anschließend verschlüsseln Sie den Schlüssel mit Ihrem öffentlichen Schlüssel. und stellen Sie diesen verschlüsselten Schlüssel Ihren Daten voran. Wenn Sie Bob dann Zugriff auf die Daten gewähren möchten, erstellen Sie einen Neuverschlüsselungsschlüssel mit seinem öffentlichen Schlüssel und Ihrem privaten Schlüssel. Anschließend senden Sie diesen Neuverschlüsselungsschlüssel an einen Proxy-Dienst. Bob kann dann den verschlüsselten Entschlüsselungsschlüssel, den er vom Anfang der Datei erhalten hat, an den Proxy-Dienst senden. Der Proxy verschlüsselt den Schlüssel mit dem Neuverschlüsselungsschlüssel neu. Dieser neu verschlüsselte Schlüssel erlaubt Bob und nur Bob, den Schlüssel zu entschlüsseln. Sobald der Schlüssel entschlüsselt ist, kann Bob den entschlüsselten Schlüssel verwenden, um die Daten der Datei zu entschlüsseln.

Das sieht nach einer ordentlichen Lösung aus, danke fürs Posten. Ich werde mich ziemlich bald damit befassen, wenn wir einen PoC aufbauen. Danke schön !

Ich würde wetten, dass es extrem schwierig wäre, das mit Ethereum zu tun. Vor diesem Hintergrund gibt es die folgenden Optionen, die Sie ausprobieren können:

  1. Filecoin, eine Blockchain auf IPFS, implementiert diese Art von Dienst und unterstützt auch Smart Contracts. Soweit mir bekannt ist, gibt es noch keine Implementierung, aber das Whitepaper ist draußen. Quelle
  2. Sie können die Openbazzar-Lösung sehen, die Vertrauensdiagramme verwendet, um diese Art von Problem zu lösen. Quelle

Weder 1 noch 2 ist eine genaue Lösung für Ihr Problem, aber es könnte ein Ausgangspunkt für eine Diskussion sein.

Bob kann den mit seinem öffentlichen Schlüssel verschlüsselten Entschlüsselungsschlüssel in der Blockchain speichern. Wenn Alice mit der Bedingung kommt, dass sie bezahlt hat, liest Bob den verschlüsselten Entschlüsselungsschlüssel aus der Blockchain, entschlüsselt ihn und verschlüsselt ihn erneut mit Alices öffentlichem Schlüssel, um ihn in der Blockchain zu speichern. Was Alice bei Bedarf mit ihrem privaten Schlüssel entschlüsseln kann.

Dies scheint die bisher einfachste Lösung zu sein, ich werde versuchen, sie in den kommenden Tagen zu testen.
Also zur Verdeutlichung: 1. Bob speichert auf dem BC den Verschlüsselungsschlüssel der Datei (mit k bezeichnet) als enc(k, pk_bob). 2. Alice zahlt, sendet die Zahlung 3. Der Smart Contract hält die Zahlung, bis Bob enc(k, pk_alice) an die Blockchain sendet. Wenn dies der Algorithmus ist, kann Bob im dritten Schritt schummeln und den Entschlüsselungsschlüssel nicht senden. Gibt es einen Mechanismus, der die Beziehung zwischen enc(m, pk_bob) und enc(m, pk_alice) in einem asymmetrischen Verschlüsselungsschema sicherstellt?
Da dies davon abhängt, wie er Smart Contract gestaltet hat, sollte es ein Treuhandkonto geben, falls jemand betrügt. Selbst wenn bob enc(k, pk_alice) verschlüsselt, was ist, wenn der von bob bereitgestellte Verschlüsselungsschlüssel falsch ist oder sogar der Dateiinhalt nicht wie von alice gewünscht ist? @Nico könnte diese inneren Abläufe beantworten.

Das Verschlüsseln von Mediendateien nimmt im Allgemeinen viel Rechenleistung und Speicherplatz sowie insgesamt Zeit und Gas in Anspruch. Aber in Anbetracht dessen, was @Kherwa gesagt hat; Sie können den öffentlichen Schlüssel von Alice verwenden, um die Datei zu verschlüsseln und auf IPFS zu speichern. Dies wird die Medien jedoch auf eine einzige Brieftasche beschränken, die Verwendung von nicht fungiblen ERC721-Token könnte dasselbe für Sie tun, jedoch mit zusätzlicher Flexibilität.

In der ersten Situation müssen Sie wissen, wann der Medienverschlüsselungsprozess abgeschlossen ist, und möchten vorzugsweise, dass die IPFS-URL irgendwo mit dem Smart Contract und dem zugehörigen Wallet für einen späteren Abruf gespeichert wird. Ich empfehle Ihnen, eine aktionsbasierte Multi-Contract-Architektur zu verwenden, die nach der Zahlung darauf wartet, dass Ihr Etherium-Orakel nach Abschluss des Verschlüsselungsprozesses zurückruft und Ihnen die Details des IPFS-Standorts sendet. Sie können diese Daten dann in der Vertragstransaktion speichern, sodass Alice ihre Medien jederzeit und überall abrufen kann. Ich glaube, dass dies eine normale sichere Methode sein soll, da die Leute nicht dazu neigen, ihre privaten Schlüssel, auch bekannt als ihre Brieftasche, preiszugeben. Das mögliche Risiko bei dieser Methode könnte darin bestehen, dass jemand seinen privaten Schlüssel veröffentlicht und jeder auf die Inhalte zugreifen kann.

Bei einem nicht fungiblen Token ist die Situation anders. Ein ERC721-Token könnte ein Produkt mit einer eindeutigen ID darstellen. Diese eindeutige ID stellt ein gemeinsames Geheimnis für den Inhalt dar, um zu verhindern, dass das gesamte Geheimnis bekannt wird und damit Missbrauch. Der Vorteil bei all dem besteht darin, dass das Produkt auf eine andere Brieftasche übertragen werden kann, sodass der neue Besitzer auf die Inhalte zugreifen kann. Dies wäre sehr nützlich für viele verschiedene Anwendungen, einschließlich Hardware aller Art. Ich bin mir nicht sicher, wie dies im Moment auf IPFS implementiert werden könnte und ob es irgendeine Art von Zeugen braucht, damit das gemeinsame Geheimnis funktioniert. Obwohl ich immer noch darüber nachdenke, wie man ein solches System implementiert, sehe ich viel Potenzial. Nimm es aber nicht zu ernst.

In beiden Fällen liegt das eigentliche Problem im Endknoten, wenn die Daten der Mediendatei oder des Produkts, wenn Sie so wollen, entschlüsselt und für die Wiedergabe zwischengespeichert werden. Jeder Client, der mit dieser Art der Verschlüsselung umzugehen weiß und den privaten Schlüssel verwenden darf, ist in gewissem Sinne in der Lage, die Medien zu kopieren und sie außerhalb der Kette zu verteilen und zu sehen, wo immer er möchte. Ich glaube daher, dass die vernünftigste Option Live-Streaming-Medien mit einer Art Abonnementstruktur sind oder Leute, die nach privaten Inhalten suchen.

IPFS-Zugriffskontrolle durch Ethereum Smart Contracts
AntwortenHierDatenschutz-Bestimmungen1y, 0v