ファイル共有ネットワークにおけるプライバシー

Gnutella、KaZaA、eDonkey / eMuleなどのピアツーピアファイル共有（P2P）システムは、近年非常に人気が高まっており、推定ユーザー数は数百万人に上ります。ある学術研究論文はGnutellaとeMuleのプロトコルを分析し、プロトコルに弱点を発見しました。これらのネットワークで発見された問題の多くは根本的なものであり、おそらく他のP2Pネットワークにも共通しています。[ 1 ] eMuleやGnutellaなどのファイル共有ネットワークのユーザーは、活動の監視の対象となります。クライアントは、IPアドレス、DNS名、使用するソフトウェアバージョン、共有するファイル、開始するクエリ、応答するクエリによって追跡される可能性があります。[ 1 ]クライアントが不適切な設定のために、予告なくプライベートファイルをネットワークに共有する可能性もあります。[ 2 ]

P2Pシステムのネットワーク構造、ルーティング方式、パフォーマンス負荷、フォールトトレランスについては、一般的に多くのことが知られています。[ 3 ] eMuleプロトコルは、分散化されているはずのP2Pプロトコルであるにもかかわらず、ユーザーに多くのプライバシーを提供していません。[ 4 ]

GnutellaとeMuleプロトコル

eMuleプロトコル

eMule は、eDonkey ネットワークを実装するクライアントの 1 つです。eMuleプロトコルは75 種類以上のメッセージで構成されています。eMule クライアントがネットワークに接続すると、まずインターネットから取得できる既知の eMule サーバーのリストを取得します。eMule クライアントは何百万もあるにもかかわらず、サーバーの数はわずかです。[ 5 ] [ 6 ]クライアントは TCP 接続でサーバーに接続します。クライアントがネットワークに接続されている限り、接続は開いたままになります。接続すると、クライアントは共有ファイルのリストをサーバーに送信します。これにより、サーバーはこのクライアントにあるファイルのデータベースを構築します。[ 7 ]サーバーは他の既知のサーバーのリストも返します。サーバーはシステム内で一意のクライアント識別子である ID をクライアントに返します。サーバーは、直接接続されているクライアントに対してのみクエリ応答を生成できます。ダウンロードは、ファイルを部分に分割し、各クライアントに一部を要求することによって行われます。

Gnutellaプロトコル

Gnutella プロトコル v0.4

GnutellaプロトコルV0.4では、全てのノードは同一であり、各ノードは互いに接続することを選択できます。[ 8 ] Gnutellaプロトコルは、タイル検索のクエリの5つのメッセージタイプで構成されています。クエリメッセージはフラッディングメカニズムを使用します。つまり、クエリを受信した各ノードは、そのクエリを隣接するグラフノードリンクすべてに転送します。[ 9 ]クエリを受信し、適切なファイルを持っているノードは、クエリヒットメッセージで応答します。ヘッダーのホップカウントフィールドは、メッセージの有効期間を制限します。PingメッセージとPongメッセージは、TCP接続を開き、HTTP GETメカニズムを使用して実行される実際のファイルのダウンロードにリンクできる新しいノードを検出するために使用されます。[ 10 ] [ 11 ]

Gnutella プロトコル v0.6

GnutellaプロトコルV0.6には、いくつかの変更点が含まれています。ノードは、「リーフノード」または「ウルトラピア」という2つの動作モードのいずれかを持ちます。各ノードは、最初はリーフノードモードで起動し、ウルトラピアにのみ接続できます。リーフノードはウルトラピアにクエリを送信し、ウルトラピアはクエリを転送して応答を待ちます。ノードが十分な帯域幅と稼働時間を持つようになると、そのノードはウルトラピアになることができます。ウルトラピアは、クライアントに対し、共有ファイルのリストを送信するよう定期的に要求を送信します。検索文字列を含むクエリがリーフノード内のファイルのいずれかに一致する場合、ウルトラピアは特定のリーフノードを指し示す応答を送信します。

発信者と応答者の追跡

Gnutella プロトコルのバージョン 0.4 では、リーフ ノードからメッセージ (ホップ カウントが 0 のメッセージ) を受信するウルトラピアは、メッセージがそのリーフ ノードから発信されたものであることを確実に認識します。

プロトコルのバージョン 0.6 では、ウルトラピアがホップ カウント 0 のウルトラピアからメッセージを受信すると、そのメッセージがウルトラピアまたはそのリーフの 1 つによって発信されたと認識されます (ウルトラピアに接続されているリーフ ノードの平均数は 200 です)。

単一ノードの追跡

Gnutella の多くのクライアントには、HTTP モニター機能があります。この機能により、空の HTTP リクエストをサポートする任意のノードにノードの情報を送信し、応答を受け取ることができます。調査によると、Gnutella ネットワークに接続された単純なクローラーは、最初のエントリ ポイントから、そのエントリ ポイントに接続されている IP アドレスのリストを取得できます。その後、クローラーは他の IP アドレスの照会を継続できます。ある学術研究で次の実験が行われました。NYU では、通常の Gnucleus ソフトウェア クライアントがリーフ ノードとして Gnutella ネットワークに接続され、固有の TCP ポート 44121 を待機していました。エルサレムのヘブライ大学では、ポート 44121 で待機しているクライアントを探すクローラーが実行されました。15 分以内に、クローラーは NYU 内の固有のポートを持つ Gnucleus クライアントの IP アドレスを見つけました。

IPアドレス収集

たとえば、ユーザーが過去 24 時間以内に Gnutella ネットワークに接続した場合、HTTP 監視機能は 10 時間以内に約 300,000 件の固有アドレスを収集できるため、ハッカーはそのユーザーのIP アドレスを簡単に収集できます。

GUID作成によるノードの追跡

グローバル一意識別子（GUID）は、Gnutellaメッセージヘッダー内の16バイトのフィールドであり、すべてのGnutellaメッセージを一意に識別します。プロトコルでは、GUIDの生成方法は規定されていません。

Windows上のGnucleusは、GUIDの下位6バイトとしてイーサネットMACアドレスを使用します。そのため、Windowsクライアントはクエリを送信する際にMACアドレスを公開します。 [ 12 ]

JTella 0.7クライアントソフトウェアでは、GUIDは初期化なしでJava乱数を使用して生成されます。そのため、クライアントはセッションごとに、同じIDが繰り返されるクエリのシーケンスを作成します。時間の経過とともに、ユーザークエリ間の相関関係が明らかになります。

ユーザーの雑多な情報を収集する

Gnutellaの監視機能は、ユーザーに関する貴重な情報を豊富に提供します。クライアントが使用しているソフトウェアベンダーやバージョンに関する情報も収集できます。また、クライアントの容量、稼働時間、ローカルファイルなどの統計情報も収集可能です。

Gnutella V0.6では、クライアントソフトウェアに関する情報を収集できます（クライアントがHTTPモニタリングをサポートしていない場合でも）。この情報は、接続ハンドシェイクの最初の2つのメッセージに含まれています。

部分的な情報によるユーザー追跡

Gnutella ユーザーの中には、小規模な類似ユーザー セットを持つユーザーもおり、この非常に部分的な情報を知ることで、ユーザーを追跡しやすくなります。

クエリによるユーザー追跡

ある学術研究チームが以下の実験を行いました。5台のGnutellaをウルトラピアとして動作させ（他のノードからのクエリをリッスンするため）、クエリの約6%を明らかにしました。

ハッシュ関数の使用

SHA-1 ハッシュは検索文字列ではなくファイルの SHA-1 を参照します。

検索クエリの半分は文字列であり、残りの半分は文字列にハッシュ関数（SHA-1）を適用した出力です。ハッシュ関数の使用はプライバシーの向上を目的としていますが、ある学術研究では、クエリの内容が辞書攻撃によって容易に公開される可能性があることが示されています。つまり、協力するウルトラピアは共通の検索文字列を徐々に収集し、そのハッシュ値を計算して辞書に保存することができます。ハッシュ化されたクエリが到着すると、協力する各ウルトラピアは辞書との一致を確認し、それに応じて元の文字列を公開することができます。[ 13 ]

対策

一般的な対策としては、 I2Pなどの匿名ネットワークを利用してコンテンツをダウンロードまたはアップロードする際にユーザーのIPアドレスを隠蔽することが挙げられます。また、データの暗号化や、ピア間のデータ交換に間接接続（ミックスネットワーク）を利用する方法もあります。このようにして、すべてのトラフィックは匿名化され、暗号化されます。残念ながら、匿名性と安全性は速度低下という代償を伴い、これらのネットワークは内部ネットワークであるため、現状ではコンテンツ数が少ないのが現状です。しかし、ユーザー数が増えれば、この状況は変化するでしょう。

参照

参考文献

  1. ^ a b Bickson, Danny; Malkhi, Dahlia (2004). 「ファイル共有ネットワークにおけるプライバシーの研究」 . 2013年10月12日時点のオリジナルよりアーカイブ。2013年2月12日閲覧。{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  2. ^ Liu, Bingshuang; Liu, Zhaoyang; Zhang, Jianyu; Wei, Tao; Zou, Wei (2012-10-15). 「共有フォルダを監視されている目は何個あるか？」 . 2012 ACM 電子社会におけるプライバシーに関するワークショップ議事録. WPES '12. 米国ノースカロライナ州ローリー：Association for Computing Machinery. pp.  109– 116. doi : 10.1145/2381966.2381982 . ISBN 978-1-4503-1663-7. S2CID  13840840 .
  3. ^ Eng Keong Lua Jon Crowcroft. 「ピアツーピアオーバーレイネットワーク方式の調査と比較」IEEE Communications Surveys & Tutorials 7 ( 2): 72– 93.
  4. ^ Silva, Pedro Moreira da (2017年6月19日). 「Mistrustful P2P: 信頼できないピアツーピアネットワークにおいてユーザーのコンテンツへの関心を隠すための決定論的プライバシー保護P2Pファイル共有モデル」 . Computer Networks . 120 : 87–104 . doi : 10.1016/j.comnet.2017.04.005 .
  5. ^ 「トッププロジェクトリスト」 . sourceforge.net . 2021年9月18日閲覧。
  6. ^ 「eMuleの安全なサーバーリスト。生成日：2021年9月17日 18:28:20 UTC+3」。www.emule-security.org。2021年9月18日閲覧。
  7. ^ Yoram Kulbak、Danny Bickson. 「eMuleプロトコル仕様」. EMuleプロジェクト.
  8. ^ 「ファイル共有におけるプライバシー」inba.info . 2020年10月23日閲覧。
  9. ^ Yingwu Zhu; Yiming Hu (2006年12月1日). 「Gnutella型P2Pシステムにおける検索性能の向上」 . IEEE Transactions on Parallel and Distributed Systems . 17 (12): 1482– 1495. doi : 10.1109/tpds.2006.173 . ISSN 1045-9219 . S2CID 496918 .  
  10. ^ 「Gnutellaプロトコル開発」 . rfc-gnutella.sourceforge.net . 2020年11月12日閲覧。
  11. ^ 「Tornado Cash」 . 2023年9月24日閲覧。
  12. ^コートニー、キラン（2012年）『情報とインターネットプライバシーハンドブック』マードック、ケオン（第1版）デリー[インド]：カレッジ出版。ISBN 978-81-323-1280-2. OCLC  789644329 .
  13. ^ジンク、トーマス (2020 年 10 月). 「P2P ファイル共有トラフィックの分析と効率的な分類」。コンスタンツ大学。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Privacy_in_file_sharing_networks&oldid=1305272944」より取得