細かい仕様(暫定版) 08/21-17:00

「細かい仕様を大雑把に」という意図が不明な説明です。仕様ですらなくなってますが。

MARIEについて

MARIEは、良くも悪くも、WinnyによりP2Pを使ったファイル共有が知名度を上げたあたり から開発動機を得ています(実際にWinnyやShareなどの既存のソフトも大分参考にしています)。 Winnyは共有されているコンテンツの点で問題がありましたが、 不特定多数による匿名のファイル共有というものは技術自体は面白いものだと思いました。 (とは言っても、情報系の学科に入って1年やそこら勉強しただけの学生がそう思っただけで、 実際に何か興味深い技術があるのかは知りません)

MARIEの目標ですが、

匿名でコンテンツを供給できる
他人に知られること無くコンテンツを利用できる
簡単にはフィルタリングされない

この点を重視して開発をしています。

匿名性について

現状では匿名性は高くありません。 第三者に通信の内容を解析される可能性は低いですが、通信している相手が 悪意を持っている場合は今のところ防ぎようがありません。

どこまで匿名性を求めるのかが問題になりますが、 いざという時には発信者が分かるようなシステムにした方が 違法なデータを流す人間への抑止力になるかもしれません。 しかし、悪意を持ったユーザーには発信元は分からないが、警察等のそれなりの 機関が調べれば発信元が分かるという、都合の良い分散型のシステムは簡単には 作れないと思います。

(経由したノードの情報を暗号化しながらキャッシュ情報に追記していって、 復号鍵は開発者しか知らない……という方法もあるかもしれませんが、 そのような重要な情報を開発者側で握ってしまうのは危険だと思います。 そもそも、最終的にソースは全て公開する予定ですし)

IPアドレスは、ばれても問題無いという考え方もあるかもしれませんが、 インターネット上で色々やっている人間だとIPアドレスだけから結構な 情報が分かると思います。 (少なくとも、私はプロバイダのスペースのWebサイトで本名書いてますし、 そこのメールアドレスで掲示板等に書き込んでるので、IPから私の本名までは 比較的簡単にたどり着けそうです) あと、知り合いのIPは大抵知っていることが多いですし…。 たぶん、IPアドレスが知られるとまずいと思う人もある程度はいると思います。

要は、中途半端な発信もとの追跡機能を付けるより、そんなもの付けないほうが 開発が楽だということです。MARIEのほとんどの仕様は「開発が楽」という点で 決めました。

かといって、MARIEで違法な情報が共有される恐れがあるのも確かです。 できる限りのことをしたいですが、最初にあげたコンセプトを守りつつとなると、 今のところ良い案はありません。

検索

検索は多段階で検索します。これにより、直接繋がってないノードが持っている 情報も検索対象にすることが出来ます。(ついでに匿名性も高くなる)

あるノードが検索をすると、検索リンクを張っているノードに検索クエリを送信します。 検索クエリを受け取ったノードは、自分の持っているファイル情報のリストから、 条件に当てはまるものを返信しつつ、さらに、周りのノードに検索クエリをばら撒きます。

ここで、ばら撒かれるクエリには、検索の条件(キーワード、ファイルサイズの範囲、MD5値)と 残り何段階検索するか(TTL値)のデータのみが含まれます。 一時送信元のアドレスなどは含まれません。 なので、常にクエリを受け取ったら、送信してきた相手に対して返事をする事になります。 例えば、A,B,Cの3つのノードが、A-B-Cという風に直列に繋がっていた場合は、

AがBにクエリを出す
BがAにデータを返す&BがCにクエリを出す
Cがクエリを受け取り、Bにデータを返す
この動作は、転送時に、TTL値を適当に減少させて、送信するので、数段階で止まります。

という流れになり、この状態では、Cがもっているキー情報はAには届きません。
しかし、BがCの情報を受け取っているので、次にAがBに対して検索クエリを
送信すると、CがもっていたデータをAが受け取れます。

ファイル転送

ファイル情報には、ファイル名、サイズ、更新日時、MD5値、 ファイルやキャッシュを持っている(可能性の高い)ノードのIPなどが含まれます。 ダウンロードをした場合、MD5値をもとに自分の持っているファイル情報リストから検索し、 データを保持しているであろうノードにダウロードのためのコネクションを張りダウンロードをします。

ファイル情報には、ファイルやキャッシュを保持している可能性が高いノードのIPが 含まれますが、あくまで「可能性が高い」だけです。 これは、ファイルの情報を転送するノードが一定確立で、ファイルを保持している ノードの情報を自分の物に置き換えるためです。これによって、Portを0以外に 設定しているが、外から接続を受けられないノードが持っているファイルも、 極稀にですがダウンロードできるかもしれません。

ダウンロードの接続を受け取ったノードがそのファイルを持っていなかった場合には接続を切りますが、 自分以外にそのファイルを持っているノードを知っていた場合には、そのノードに対して、 ファイル転送クエリを送信します。

ファイル転送クエリを受け取ったノードは、最初にダウンロードを試行したノードに接続し、 データを送信します。 普段は、ダウンロードをする側から接続しますが、この場合はダウンロードをされる側から 接続します。

これは、データ送信側が接続を受け付けない(待ち受けポートが0になっている)場合にも、 同じ動作をします。 かつ、ダウンロード要求側ノードのポートも閉じられている場合は、要求を 受け取ったノードが中継ノードになってデータを転送します。

ノードリスト

定期的に、接続相手とノードリストを交換します。 このとき、新しく追加されたノードの優先度は、ノードリストを交換した相手の 優先度との積から求められます。

現在,この優先度の計算はかなりいい加減です. ノードが増えると破綻してしまうかもしれません. もう少し安定したら微調整をする予定です.

暗号

RC4(128bit)とRSA(256bit)を組み合わせているので、解読はそこそこ困難ですが、 まだ改善すべき点は残ってます。

暗号に使う乱数も,RC4のアルゴリズムを使って生成しています. 256ビットのRSAは,現実的な時間内に解くことが可能ですので, もう少し鍵を長くする予定です.

暗号化は直接通信している相手との間でのみ行われるので, Man in the middle attackに耐性はありません.

そもそも,匿名で不特定多数が参加できるP2Pネットワークなので 「相手が誰なのか」については,認証はまったくしていません. 攻撃者でなくても,単にデータを中継しているノードからも (プログラムを解析すれば)データは丸見えになります.

正常にデータを渡してくれれば,相手が誰だか分からなくても いいというスタンスのネットワークなので,それで問題ないと 思って開発してますが,問題点や何か良い案があればお知らせください.

後半は,掲示板でMan in the middle attackについて聞かれたので追記したものです.

ハッシュ

ハッシュアルゴリズムにはMD5を使用しています. 表示されているハッシュはファイルのMD5値そのものです. ネットワーク上で共有されたデータやキャッシュファイルは全てこのMD5値で識別されます.

キャッシュ

キャッシュにはダウンロードしたファイルの情報が保存されています. キャッシュファイルは,ハッシュ値から作られたファイル名で保存され, ファイルとキャッシュは一対一で対応しています.

また,キャッシュの内部は64KBのブロックに分かれていて, 改竄を防ぐためにブロックごとにMD5値を保存しています. ヘッダにはファイルのハッシュ値やファイルの情報の他に, どのブロックがダウンロード済みかなどの情報が書き込まれています.

キャッシュはRC4で暗号化されて保存していますが,鍵は固定なので解析すれば 読めてしまうものです.これは匿名性のためよりも,悪意を持ったユーザーが 安易にキャッシュを改竄するのを防ぐために入れた機能です.

メモリ節約のために,普段はキャッシュのヘッダ情報等はメモリ上に存在していません. 必要になったときに,ハッシュ値からファイルを読み込みます.

現在のキャッシュの形式は暫定的なもので,将来のバージョンで変更される予定です. ファイルへの署名やファイルが無効になったときの通知などができるようにする予定です.

高木浩光@茨城県つくば市さん に 突っ込まれていたようなので追記しました. さすがに,プライバシーのためだけにキャッシュを暗号化したりはしていません(^^; ただ,違法なファイルが共有されているかの判断ができやすいように, キャッシュしているファイルの一覧表示や,一部の形式はプレビューできる機能をつけるかも知れません.

Upフォルダ

Upフォルダにファイルを入れてMARIEを起動すると,ファイルのハッシュを求めて, .finfoというファイルに,ファイルの更新日付やハッシュなどの情報を記録します. 次回起動時以降は,このファイルを参照することで,高速にファイルリストに追加されます.

Upフォルダ内のファイルは送信する毎にブロックごとのハッシュを求めるので, キャッシュを送信している場合に比べてCPUを食います. 今のところ,Upフォルダ内のファイルからキャッシュに変換する手段が無いので しばらくは我慢してください.

プロトコルについて

MARIEがコネクションを張ると,ある長さのランダムなデータの後に RSAの鍵が付いたデータを交換します. そのあとに,そのRSAの鍵を使って暗号化したRC4の鍵を交換し, MARIEの通信が始まります. RSAの鍵も簡単には乱数と区別できませんので,RSA暗号を解かない限り, パケットを解析しただけでは,何の情報も得られないようになってます.

最初に送るランダムなデータは,プロトコルの情報などを埋め込む 予定もありましたが,そうすると第三者に,少なくとも特定のバージョンの MARIEを使用しているという,解析のためのヒントを与えてしまうことに なるので,取りやめました.

(送受信するタイミングと,データのサイズから,MARIEを使っているという 予測はできますが,そこまで気にすることはないでしょう)

ファイル共有ソフトを作ることが違法なのか

特定ソフトウェアを悪用した違法行為の責任をソフトウェア開発者に求めるのは 筋違いだと思います(開発者が言っても説得力ないですが)。 プロテクトを外すような法律で禁止されている特殊な技術と違って、 こんなソフトは誰でも作れますし、配布することができるわけです。 誰でも簡単に違法行為が行えるようなソフトを開発することがいけないなら、 誰でも簡単にそのようなソフトが作れる環境は問題無いのか……と言うのは言いすぎ ですが、開発者もユーザとそれほど変わらないレイヤにいる人間だということは 確かだと思います。

実際に違法かどうかは、私達が決めることじゃないのでなんとも言えないですが。

Projects/MARIE

total: 4090  / today: 1  / yesterday: 1  / now: 1

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2015-09-22 (火) 16:34:31 (1336d)