Ipfs: Berechtigungen

Bei weiteren Untersuchungen denke ich, dass das einzige, was fehlt, der Besitz eines Blobs (möglicherweise keine) und Leseberechtigungen basierend auf einer Liste (oder mehreren) sind, die vom Eigentümer kontrolliert werden (wenn nicht keine). Dies kann auf IPFS aufgebaut werden, ohne das zugrunde liegende fs zu ändern.

Sie sollten stattdessen besser Fähigkeiten verwenden. Naives Beispiel: Verschlüsseln Sie die Datei mit einem Geheimnis und teilen Sie das Geheimnis mit den Personen, die "Leseberechtigung" haben.

Exakt. Kappen. Siehe E-Rechte und Tahoe-LAFS

—
Von Postfach gesendet

Am Freitag, 4. September 2015 um 16:46 Uhr, Mourad De Clerck [email protected]
schrieb:

Sie sollten stattdessen besser Fähigkeiten verwenden. Naives Beispiel: Verschlüsseln Sie die Datei mit einem Geheimnis und teilen Sie das Geheimnis mit den Personen, die "Leseberechtigung" haben.

Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

Verschlüsselung zum Verwalten von Berechtigungen ist eine sehr schlechte Idee. Es funktioniert gut in optimistischen Szenarien, hält sich aber in der Realität nicht sehr gut.

Angenommen, eine verschlüsselte Datei wird beispielsweise über mehrere Knoten verteilt und erreicht jemanden mit böswilligen Absichten, dann könnten sie einige Anstrengungen unternehmen, um die Datei zu entschlüsseln. In einer optimistischen Welt scheitern sie und alle sind glücklich. Ja!

Wenn die Datei in der realen Welt vor einiger Zeit erstellt wurde, ist es möglich, dass seitdem ein Fehler im Verschlüsselungsalgorithmus gefunden wurde. Oder es ist möglich, dass neue spezielle Entschlüsselungshardware allgemein verfügbar wird. Dies würde die Komplexität des Entschlüsselungsprozesses drastisch reduzieren. Da die Datei niemandem wirklich gehört, gibt es keine Möglichkeit, die vorhandene Datei abzurufen und durch eine neue Version zu ersetzen, die mit einem neuen und sichereren Algorithmus verschlüsselt ist. Selbst wenn Sie so etwas tun könnten, was Ihnen sagt, dass der bösartige Knoten die vorherige Version der Datei sowieso nicht behalten wird.

Letztendlich gibt es nichts Besseres, als zu verhindern, dass die Datei das Netzwerk verlässt, wenn es um Sicherheit und Datenschutz geht.

Anstelle von Dateiberechtigungen halte ich es für sinnvoller, dies auf Knotenebene zu tun. Grundsätzlich sollte ein Knoten in der Lage sein, Verbindungen von anderen Knoten basierend auf einem Whitelist/Blacklist-Paradigma abzulehnen. Dies würde es Menschen ermöglichen, ein privates IPFS-Netzwerk zu erstellen, ein bisschen wie private Bit-Torrent-Tracker, um vertrauliche Daten zu teilen und gleichzeitig zu vermeiden, dass sie an einen bösartigen Knoten gelangen.

Vielleicht könnten wir sogar eine global verteilte schwarze Liste von Knoten in Betracht ziehen, die auf IPFS selbst gespeichert ist, um bekannte bösartige Knoten automatisch zu blockieren. Ich weiß jedoch nicht, wie nützlich dies wäre, wenn man bedenkt, dass eine Knotenidentität einfach durch ein neues Schlüsselpaar neu generiert werden kann.

Ich stimme auch zu, dass Verschlüsselung der einfachste Weg ist, dies zu tun.
Verschlüsselungsschemata können gehackt werden, aber auch die Knoten. Benutzer müssen einfach
sich dieser Möglichkeiten bewusst zu sein, wenn versucht wird, eine Zugangskontrolle bereitzustellen
zu Klecksen.
Am 9. September 2015 um 18:48 Uhr schrieb „Etienne Maheu“ [email protected] :

Verschlüsselung zum Verwalten von Berechtigungen ist eine sehr schlechte Idee. Es funktioniert gut darin
optimistische Szenarien, hält sich aber in der Realität nicht sehr gut.

Angenommen, eine verschlüsselte Datei wird verteilt
mehrere Knoten erreichen und jemanden mit böswilligen Absichten erreichen, dann könnten sie es
Geben Sie sich Mühe, die Datei zu entschlüsseln. In einer optimistischen Welt, sie
scheitern, und alle sind glücklich. Ja!

In der realen Welt ist dies der Fall, wenn die Datei vor einiger Zeit erstellt wurde
möglich, dass seitdem ein Fehler im Verschlüsselungsalgorithmus gefunden wurde.
Oder es ist möglich, dass neue spezielle Entschlüsselungshardware weit verbreitet ist
erhältlich. Dies würde die Komplexität der Entschlüsselung drastisch reduzieren
Prozess. Da niemand die Datei wirklich besitzt, gibt es keine Möglichkeit, die Datei zu ziehen
vorhandene Datei und ersetzen Sie sie durch eine neue Version, die mit a verschlüsselt ist
neuer und sicherer Algorithmus. Selbst wenn Sie so etwas tun könnten, was
teilt Ihnen mit, dass der bösartige Knoten die vorherige Version der Datei nicht behalten wird
ohnehin.

Am Ende gibt es nichts Besseres, als zu verhindern, dass die Datei das Netzwerk verlässt
wenn es um Sicherheit und Privatsphäre geht.

Anstelle von Dateiberechtigungen halte ich es für sinnvoller, dies zu tun
auf Knotenebene. Grundsätzlich sollte ein Knoten in der Lage sein, Verbindungen abzulehnen
von anderen Knoten basierend auf einem Whitelist/Blacklist-Paradigma. Dies würde lassen
Die Leute erstellen ein privates IPFS-Netzwerk, ein bisschen wie ein privater Bit-Torrent
Tracker, um vertrauliche Daten zu teilen und gleichzeitig zu vermeiden, dass sie an einen Böswilligen weitergegeben werden
Knoten.

Vielleicht könnten wir sogar eine global verteilte schwarze Liste von Knoten in Betracht ziehen,
auf IPFS selbst gespeichert, um bekannte bösartige Knoten automatisch zu blockieren.
Ich weiß jedoch nicht, wie nützlich dies in Anbetracht einer Knotenidentität wäre
kann einfach durch ein neues Schlüsselpaar neu generiert werden.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589.

@ekg Der Unterschied besteht darin, dass ein Fehler bei der Sicherung eines Knotens oder im Whitelist-System selbst aktualisiert werden kann, da "Sie die Kontrolle über alle betroffenen Knoten in Ihrem Netzwerk haben". Wenn Sie sich dafür entscheiden, einem Knoten zu vertrauen, müssen Sie sicherstellen, dass er sicher ist. Wenn ein Fehler auftritt, bedeutet dies nicht, dass Sie Daten verloren haben, sondern dass Sie ihn so schnell wie möglich beheben sollten. Dies ist bei der Verschlüsselung in einem verteilten Dateisystem nicht möglich. Wenn eine Datei eine fehlerhafte Verschlüsselung verwendet, haben Sie diese zweite Chance nicht.

@kawazoe bitte lesen Sie in Fähigkeitsmodelle . jedes einzelne Berechtigungsschema kann in einem Capability-System dargestellt werden, ist also ein _streng überlegenes_ System. Papiere gibt es zuhauf.

Ein Knoten sollte in der Lage sein, Verbindungen von anderen Knoten basierend auf einem Whitelist/Blacklist-Paradigma abzulehnen. Dies würde es Menschen ermöglichen, ein privates IPFS-Netzwerk zu erstellen, ein bisschen wie private Bit-Torrent-Tracker, um vertrauliche Daten zu teilen und gleichzeitig zu vermeiden, dass sie an einen bösartigen Knoten gelangen.

dies ist bereits geplant, aber orthogonal.

@jbenet Ich sage nicht, dass Fähigkeiten schlecht sind. Es ist großartig, dass Sie dieses Modell verwenden möchten. Was ich sagen will, ist, dass es einen deutlichen Unterschied zwischen einer Zugriffsfunktion und einer Lesefunktion gibt (egal auf welcher Ebene oder wie sie implementiert ist) und dass die Verschlüsselung der Daten allein nicht ausreicht, um die beiden zu unterscheiden.

Einen Knoten zu haben, der steuert, welche Knoten eine bestimmte Datei abrufen dürfen, sollte eine Sache sein. Das Verschlüsseln der Dateien ist in einigen Szenarien nicht gut. Einige Beispiele:
Haben Sie einen Mediendienst, bei dem die Leute bezahlen müssen, um auf die Inhalte zuzugreifen. Um Bandbreite zu sparen, wäre die Verwendung von IPFS sinnvoll, wenn sie sicherstellen könnten, dass nur diejenigen, die bezahlt haben, auf die Dateien zugreifen könnten, zumindest über ihre Knoten und die Knoten der ehrlichen Benutzer. Wenn die Dateien nur durch Verschlüsselung geschützt wären, wäre nur ein einziger Benutzer erforderlich, der den Schlüssel pro Medium extrahiert, und Piraten könnten den Inhalt über IPFS stehlen. Ohne asynchrone Verschlüsselung könnten Sie nicht einmal wissen, welche Benutzer den Schlüssel verteilt haben, und mit asynchroner Verschlüsselung erhalten Sie nicht die Vorteile von IPFS. Bitte überdenken Sie dies noch einmal.

Eine Möglichkeit, dies zu implementieren, wäre, dass der Knoten, der nach der Datei gefragt wird, eine Autorität fragen würde, ob der Knoten, der versucht, auf die Datei zuzugreifen, dies tun durfte, und auf dieser Grundlage handeln würde. Es sollte auch nicht zu schwer sein, das zu tun, und es würde definitiv Benutzer geben.

@jcgruenhage Sie könnten jeden Benutzer des Netzwerks im selben privaten Netzwerk haben. (Weitere Informationen zu privaten Netzwerken finden Sie unter https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649)

Abgesehen davon könnten Sie dies möglicherweise als spezielle Bitswap-Erweiterung implementieren, aber dann stoßen Sie auf ein paar seltsame Probleme, wenn Sie versuchen, unverschlüsselte „private“ Inhalte zu haben, während Sie noch mit dem primären Netzwerk verbunden sind. Was ist, wenn jemand außerhalb der "erlaubten Gruppe" die Datei auf andere Weise erhält (und sie den gleichen Hash hat) und dann ein Knoten in der erlaubten Gruppe sie abgreift (vielleicht ist sie Teil eines anderen Archivs, das sie heruntergeladen haben). Sollten sie die Dateien dann anderen Peers bereitstellen, die sie angefordert haben, da sie aus einer nicht geschützten Quelle stammen?

Die Funktion für private Netzwerke sieht interessant aus, aber sie würde die Leute dazu zwingen, einen völlig separaten Knoten für den Zugriff auf diese Inhalte zu haben, und ich bezweifle, dass die meisten Leute das wollen. Auch hier haben wir wieder einen einzigen Schlüssel, der kompromittiert werden müsste, anstatt einer zentralen Autorität, die die Kontrolle darüber hat, wer die Datei erhält.

Darüber, ob ein Knoten die Datei teilen sollte, wenn er sie von woanders bekommen hat, woher sollte er überhaupt wissen, dass die Datei dann eingeschränkten Zugriff hat? Ich denke, das Teilen ist dann in Ordnung, denn ich versuche nur sicherzustellen, dass, wenn jemand die Datei "stiehlt", die Serverknoten, die die Dateien gepinnt haben, und die Knoten der ehrlichen Benutzer ihre Downloads nicht durchführen superschnell, weil sie es auch von all diesen Knoten herunterladen können, aber nur von diesen nicht so ehrlichen Benutzern.

@jcgruenhage Ich stimme der Unannehmlichkeit zu, ein privates Netzwerk zu benötigen.

Es ist auch nicht klar, wie sehr das private Netzwerk hilft, da ein unehrlicher Benutzer diese Daten beim Entschlüsseln von Daten sofort in das öffentliche Netzwerk hochladen könnte. Bitte korrigieren Sie mich, wenn etwas dies verhindert.

Wenn das private Netzwerk maximal zwei Knoten hätte, würde der ehrliche Knoten wissen, dass der andere Knoten unehrlicherweise Daten preisgibt. Wenn Sie mehr als zwei Knoten im privaten Netzwerk zulassen, geht der Leak-Determinismus verloren.

Selbst im privaten Netzwerk mit zwei Knoten würde der ehrliche Knoten nicht sofort erkennen, dass die Daten lecken. Die Zeit würde vergehen, und zu diesem Zeitpunkt könnten die Daten auf halbem Weg durch die Galaxie sein.

Eine mögliche Lösung besteht darin, während der Dateientschlüsselung eine verschlüsselte Knoten-ID / Tracer-ID hinzuzufügen. Dadurch erhält jeder Benutzer eine leicht modifizierte Kopie jeder Datei, die eine für ihn eindeutige Tracer-/Knoten-ID enthält. Die entschlüsselten Dateien würden sich immer vom Original unterscheiden, aber das Original würde unveränderlich und überprüfbar bleiben.

Mit dem privaten Netzwerk verbundene Sentinel-Knoten könnten das öffentliche Netzwerk auf diese Tracer-Werte überwachen. Auf diese Weise wäre es möglich, die Leckursache rechtzeitig zu erkennen.

Dies würde nicht verhindern, dass ein Knoten in einem privaten Netzwerk Daten an ein anderes privates Netzwerk weiterleitet.

Sie können Benutzer nicht daran hindern, die Dateien freizugeben, aber Sie sollten verhindern können, dass sie Ihre Infrastruktur dafür verwenden, aber derzeit gibt es noch kein verteiltes Dateiverteilungssystem, das dies tut.

@jcgruenhage hrm ... Das ist ein interessanter Anwendungsfall. Würde jeder mitmachen
Knoten den Server nach jedem angeforderten Block fragen? Oder würde die auth
Server senden eine große Liste erlaubter Peers und deren Inhalt
benutzen dürfen?

Am Fr, 2. Juni 2017, 09:19 Jan Christian Grünhage [email protected]
schrieb:

Sie können Benutzer nicht daran hindern, die Dateien freizugeben, aber Sie sollten dazu in der Lage sein
verhindern, dass sie Ihre Infrastruktur dafür verwenden, aber derzeit gibt es keine
verteiltes Dateiverteilungssystem, das dies noch tut.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 , oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

Die Funktion „Private Netzwerke“ basiert auf einem Konzept des vollständigen Vertrauens Ihrer PNet-Peers.

Der nächste Schritt könnte ein Capability-System sein, bei dem Sie einigen Knoten den Zugriff auf einige Dateien gewähren können. Ein böswilliger Akteur in diesem Schema könnte nur Daten preisgeben, für die er die Fähigkeit hat, vorausgesetzt, dass andere Knoten, die die Fähigkeit für eine bestimmte Datei haben, sich gut verhalten.

@nueverest Wie @jcgruenhage sagte, sobald der Benutzer Zugriff auf eine Datei hat und sie entschlüsseln kann, kann er sie auf einen USB-Stick kopieren und sie einfach woanders veröffentlichen.

Für mich ist das Eigentum wichtiger – ich möchte sicherstellen, dass die Datei von jemandem geändert wurde, dem ich vertraue. Eine Möglichkeit, dies zu tun, besteht darin, die Datei zu verschlüsseln und den Entschlüsselungsschlüssel als Teil des Dateinamens zu verwenden – sobald also die Hash-Summe für die entschlüsselte Datei berechnet ist, weiß ich, dass nur jemand, der den Verschlüsselungsschlüssel kennt, dies tun kann .

Wahrscheinlich ist es nicht der beste Weg, aber wird es irgendwo implementiert?

Dateien, die durch /ipfs -Pfade benannt sind (z. B. /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) sind unveränderlich, daher sollte dies kein Problem darstellen. Dateien, die mit einem /ipns/... -Pfad benannt sind, sind veränderlich, werden aber vom Autor (dem Eigentümer des IPNS-Namens) signiert.

Wenn Sie jedoch /ipfs/... -Pfade außerhalb des Bandes erhalten und die Urheberschaft bestimmen möchten, müssen Sie die Daten wahrscheinlich signieren (kann beispielsweise mit gnupg durchgeführt werden).

Hinweis: Wir werden wahrscheinlich irgendwann ein veränderliches Dateisystem wie SUNDR bauen. Dieses Dateisystem wird wahrscheinlich Urheberinformationen enthalten. Wir werden in Zukunft wahrscheinlich auch willkürliche Metadaten zulassen (die theoretisch Informationen über die Urheberschaft enthalten könnten).

@risen @jbenet Können Sie beschreiben (oder auf eine Beschreibung verlinken), wie Funktionsmodelle verwendet werden könnten, um zu verhindern, dass berechtigte Dateien auf einem IPFS-Knoten diesen Knoten verlassen, außer an einen autorisierten Anforderer? Gibt es eine explizite Fähigkeitsmodellfunktion in IPFS? Ich habe nach Dokumentation dazu gesucht, aber nichts Explizites gefunden.

Hallo @vdods – wir lassen Probleme in diesem Repo zu Referenzzwecken offen, bitten aber um eine Folgediskussion unter https://discuss.ipfs.io/ (das aktiv überwacht wird). Bitte dort posten - danke!