Ipfs: 権限

さらに調査すると、欠落しているのはblobの所有権（おそらくなし）と、所有者が制御するリスト（またはいくつか）に基づく読み取り権限（ない場合）だけだと思います。 これは、基盤となるfsを変更せずにIPFS上に構築できます。

代わりに機能を使用する方がよいでしょう。 素朴な例：ファイルを秘密で暗号化し、「読み取り権限」を持つ人々と秘密を共有します。

その通り。 キャップ。 e-rightsとTahoe-LAFSを参照してください

—
メールボックスから送信

2015年9月4日金曜日午後4時46分、Mourad [email protected]
書きました：

代わりに機能を使用する方がよいでしょう。 素朴な例：ファイルを秘密で暗号化し、「読み取り権限」を持つ人々と秘密を共有します。

このメールに直接返信するか、GitHubで表示してください。
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

許可を管理するための暗号化は非常に悪い考えです。 楽観的なシナリオではうまく機能しますが、実際にはあまりうまく機能しません。

たとえば、暗号化されたファイルが複数のノードに分散され、悪意のある人物に到達すると仮定すると、ファイルの復号化にいくらかの努力を払う可能性があります。 楽観的な世界では、彼らは失敗し、誰もが幸せです。 うん！

現実の世界では、ファイルがしばらく前に作成されている場合、それ以降に暗号化アルゴリズムの欠陥が見つかった可能性があります。 または、新しい特別な復号化ハードウェアが広く利用可能になる可能性があります。 これにより、復号化プロセスの複雑さが大幅に軽減されます。 誰もファイルを本当に所有していないため、既存のファイルをプルして、新しいより安全なアルゴリズムで暗号化された新しいバージョンに置き換える方法はありません。 このようなことができたとしても、悪意のあるノードが以前のバージョンのファイルを保持することはありません。

結局のところ、セキュリティとプライバシーに関しては、ファイルがネットワークを離れることを妨げるものはありません。

ファイルパーミッションの代わりに、ノードレベルでそれを行う方が意味があると思います。 基本的に、ノードは、ホワイトリスト/ブラックリストのパラダイムに基づいて、他のノードからの接続を拒否できる必要があります。 これにより、悪意のあるノードへの漏洩を回避しながら、機密データを共有するために、プライベートビットトレントトラッカーに少し似たプライベートIPFSネットワークを作成できるようになります。

おそらく、IPFS自体に保存されている、グローバルに分散されたノードのブラックリストを検討して、既知の悪意のあるノードを自動的にブロックすることもできます。 ただし、ノードIDを新しいキーペアで簡単に再生成できることを考えると、これがどれほど役立つかはわかりません。

また、暗号化がこれを行う最も簡単な方法であることに同意します。
暗号化スキームはハッキングされる可能性がありますが、ノードもハッキングされる可能性があります。 ユーザーは単に必要です
アクセス制御を提供しようとするときにこれらの可能性を認識すること
ブロブに。
2015年9月9日午後6時48分、「EtienneMaheu」 [email protected]は次のように書いています。

許可を管理するための暗号化は非常に悪い考えです。 それはでうまく機能します
楽観的なシナリオですが、実際にはあまりうまくいきません。

たとえば、暗号化されたファイルが全体に分散されると仮定します
複数のノードがあり、悪意のある人に到達すると、
ファイルの復号化に少し力を入れてください。 楽観的な世界では、彼らは
失敗し、誰もが幸せです。 うん！

現実の世界では、ファイルがしばらく前に作成されている場合、それは
それ以降、暗号化アルゴリズムに欠陥が見つかった可能性があります。
または、新しい特殊な復号化ハードウェアが広くなる可能性があります
利用可能。 これにより、復号化の複雑さが大幅に軽減されます
処理する。 誰もファイルを本当に所有していないので、ファイルをプルする方法はありません
既存のファイルを、で暗号化された新しいバージョンに置き換えます
新しい、より安全なアルゴリズム。 このようなことができたとしても、
悪意のあるノードが以前のバージョンのファイルを保持しないことを通知します
とりあえず。

結局、ファイルがネットワークを離れることを妨げるものは何もありません
セキュリティとプライバシーに関しては。

ファイルのパーミッションの代わりに、それを行う方が意味があると思います
ノードレベルで。 基本的に、ノードは接続を拒否できる必要があります
ホワイトリスト/ブラックリストパラダイムに基づく他のノードから。 これにより
人々はプライベートビットトレントのようにプライベートIPFSネットワークを作成します
トラッカー、悪意のあるユーザーへの漏洩を回避しながら機密データを共有する
ノード。

たぶん、グローバルに分散されたノードのブラックリストを検討することもできます。
既知の悪意のあるノードを自動的にブロックするために、IPFS自体に保存されます。
ただし、これがノードIDを検討するのにどれほど役立つかはわかりません。
新しいキーペアを使用して簡単に再生成できます。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/ipfs/ipfs/issues/86#issuecomment-138988589 。

@ekg違いは、ノードの保護方法、またはホワイトリストシステム自体に欠陥がある場合、ネットワーク内の影響を受けるすべてのノードを「制御している」ため、ノードを更新できることです。 ノードを信頼することを選択した場合、それが安全であることを確認するのはあなた次第です。 欠陥が表示された場合、それはデータが漏洩したことを意味するのではなく、できるだけ早く修正する必要があるということです。 分散ファイルシステムでの暗号化に関しては、これを行うことはできません。 ファイルが壊れた暗号化を使用している場合、その2度目のチャンスはありません。

@kawazoe機能モデルを読んでください。 すべての許可スキームは機能システムで表すことができるため、それは_厳密に優れた_システムです。 論文はたくさんあります。

ノードは、ホワイトリスト/ブラックリストのパラダイムに基づいて、他のノードからの接続を拒否できる必要があります。 これにより、悪意のあるノードへの漏洩を回避しながら、機密データを共有するために、プライベートビットトレントトラッカーに少し似たプライベートIPFSネットワークを作成できるようになります。

これはすでに計画されていますが、直交しています。

@jbenet機能が悪いと言っているのではありません。 このモデルの使用を計画しているのは素晴らしいことです。 私が言っているのは、アクセス機能と読み取り機能には明確な違いがあり（どのレベルで、またはどのように実装されているかに関係なく）、データを暗号化するだけでは2つを区別するのに十分ではないということです。

どのノードが特定のファイルを取得できるかを制御するノードを持つことは重要です。 一部のシナリオでは、ファイルの暗号化は適切ではありません。 いくつかの例：
人々がコンテンツにアクセスするためにお金を払わなければならないメディアサービスを持っている。 帯域幅を節約するために、IPFSを使用することは、少なくとも自分のノードと正直なユーザーのノードを介して、支払いをした人だけがファイルにアクセスできるようにすることができれば意味があります。 ファイルが暗号化のみで保護されている場合は、メディアごとにキーを抽出する1人のユーザーが必要であり、海賊はIPFSを介してコンテンツを盗む可能性があります。 非同期暗号化がないと、どのユーザーがキーを配布したかさえわかりません。非同期暗号化を使用すると、IPFSの利点を得ることができません。 これを再考してください。

これを実装する方法は、ファイルを要求されたノードが何らかの権限を要求し、ファイルにアクセスしようとしているノードがアクセスを許可されているかどうかを確認し、それに基づいて動作することです。 それを行うのもそれほど難しいことではなく、間違いなくユーザーがいるでしょう。

@jcgruenhageネットワークのすべてのユーザーを同じプライベートネットワーク上に置くことができます。 （プライベートネットワークの詳細については、https：//github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649を参照してください）

それとは別に、これを特別なビットスワップ拡張機能として実装することもできますが、プライマリネットワークに接続したまま、暗号化されていない「プライベート」コンテンツを作成しようとすると、いくつかの奇妙な問題が発生します。 '許可されたグループ'の外部の誰かが他の手段でファイルを取得し（そしてそれが同じハッシュを持っている）、許可されたグループのノードがそれを取得した場合（おそらくダウンロードした他のアーカイブの一部）はどうなりますか？ 次に、保護されていないソースからのファイルであるため、ファイルを要求した他のピアにファイルを提供する必要がありますか？

プライベートネットワーク機能は面白そうに見えますが、このコンテンツにアクセスするために完全に独立したノードが必要になるため、ほとんどの人がそれを望んでいるとは思えません。 また、ファイルの取得者を制御する中央機関ではなく、侵害する必要のある単一のキーがあります。

ノードが他の場所からファイルを取得した場合にファイルを共有する必要があるかどうかについて、ファイルのアクセスが制限されていることをノードがどのように知る必要がありますか？ 私が確認しようとしているのは、誰かがファイルを「盗んだ」場合、ファイルを固定したサーバーノード、および正直なユーザーのノードがダウンロードを行わないことだけなので、それを共有することは問題ないと思います。それらのすべてのノードからもダウンロードできるため、超高速ですが、それほど正直でないユーザーからのみダウンロードできます。

@jcgruenhage私はプライベートネットワークを必要とする不便さについて同意します。

また、データを復号化すると、不正なユーザーがこのデータをすぐにパブリックネットワークにアップロードする可能性があるため、プライベートネットワークがどの程度役立つかは明らかではありません。 何かがこれを妨げるならば、私を訂正してください。

プライベートネットワークに最大2つのノードがある場合、正直なノードは、他のノードが不正にデータをリークしていることを認識します。 プライベートネットワークで3つ以上のノードを許可すると、リークの決定論が失われます。

2ノードのプライベートネットワークでも、正直なノードはデータがリークしていることをすぐには知りません。 時間は経過し、その時点までにデータは銀河の半分にあるかもしれません。

考えられる解決策は、ファイルの復号化中に暗号化されたノードID /トレーサーIDを追加することです。 これにより、各ユーザーは、自分に固有のトレーサー/ノードIDを含む各ファイルのわずかに変更されたコピーを取得します。 復号化されたファイルは常に元のファイルとは異なりますが、元のファイルは不変で検証可能なままです。

プライベートネットワークに関連するセンチネルノードは、これらのトレーサー値についてパブリックネットワークを監視できます。 このようにして、漏れの原因をタイムリーに検出することが可能になります。

これは、あるプライベートネットワーク上のノードが別のプライベートネットワークにデータをリークすることを防ぐことはできません。

ユーザーがファイルを共有するのを防ぐことはできませんが、ユーザーがそのためのインフラストラクチャを使用するのを防ぐことはできますが、現在、これを行う分散ファイル配布システムはまだありません。

@jcgruenhage hrm ...これは興味深いユースケースです。 それぞれが参加しますか
ノードは、要求されている各ブロックについてサーバーに問い合わせますか？ または認証
サーバーは、許可されたピアの大きなリストとそれらがどのようなコンテンツであるかを送信します
使用を許可しますか？

2017年6月2日金曜日、09： 19JanChristianGrü[email protected]
書きました：

ユーザーがファイルを共有するのを防ぐことはできませんが、できるはずです
そのためにインフラストラクチャを使用することを防ぎますが、現在はありません
まだこれを行う分散ファイル配布システム。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
。

プライベートネットワーク機能は、PNetピアの完全な信頼という概念に基づいて構築されました。

次のステップは、いくつかのノードがいくつかのファイルにアクセスできるようにする機能システムである可能性があります。 そのスキーマの悪意のあるアクターは、特定のファイルに対する機能を備えた他のノードが適切に動作していることを考えると、機能を備えたデータのみをリークする可能性があります。

@jcgruenhageが言ったように、 @ nueverestは、ユーザーがファイルにアクセスして復号化できるようになると、それをUSBスティックにコピーして、別の場所に公開することができます。

私にとってより重要なのは所有権です---ファイルが信頼できる誰かによって変更されたことを確認したいと思います。 これを行う1つの方法は、ファイルを暗号化し、ファイル名の一部として復号化キーを使用することです。したがって、復号化されたファイルのハッシュサムが計算されると、暗号化キーを知っている人だけがそれを実行できることがわかります。 。

おそらくそれは最善の方法ではありませんが、どこかに実装されていますか？

/ipfsパス（例：/ ipfs / QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF）で名前が付けられたファイルは不変であるため、これは問題にはなりません。 /ipns/...パスで名前が付けられたファイルは変更可能ですが、作成者（IPNS名の所有者）によって署名されています。

ただし、帯域外で/ipfs/...パスを取得していて、オーサーシップを確認したい場合は、データに署名する必要があります（たとえば、gnupgを使用して行うことができます）。

注：最終的には、SUNDRのような可変ファイルシステムを構築する可能性があります。 そのファイルシステムには、著者情報が含まれている可能性があります。 将来的には任意のメタデータも許可される可能性があります（理論的には、作成者情報を保持する可能性があります）。

@risen @jbenet IPFSノード上の許可されたファイルが許可されたリクエスター以外にそのノードを離れるのを防ぐために機能モデルをどのように使用できるかを説明（または説明へのリンク）できますか？ IPFSに明示的な機能モデル機能はありますか？ 私はこれに関するドキュメントを探し回っていますが、明確なものは何も見つかりませんでした。

こんにちは@ vdods-このリポジトリの問題は参照用に開いたままにしておきますが、フォローアップディスカッションがhttps://discuss.ipfs.io/ （アクティブに監視されています）で行われるように要求します。 そこに投稿してください-ありがとう！