平成16年（わ）第726号の第十六回公判の傍聴の続き。

Note Winny



ダウンロードの仕組みについてからです。


Keyの中にはBodyを持っているノードのIPアドレスとポート番号があるので、そこからダウンロードする。
QueryによりKeyを取得し、そのKeyに入っているノードに対してRequestすることで、そのノードが対象となるファイルをPullする。
基本的には直接転送しており、転送はすべて中継して行っているという報道などは間違っている。
弁15号証のP62-63にこの仕組みが記載されている。
Bodyはキャッシュ化されており、OriginalFileをブロック化して、ブロックごとに暗号化してHashをつけてキャッシュ化する。
ファイルの情報を持つHeaderにもHashがあり、それにブロックごとのCache＋Hashを加えて、全体でキャッシュとしている。
Hashとは要約情報で、元の大きなデータから小さなHash値を得ておき、別のデータからもHash値を求め、その小さなHash値が一致することで大きなデータが同じであるかどうかを判断する。
Hash値が一致すれば、データが同じである確率が非常に高い。
KeyにもHash値が入っており、KeyのHash値によってBodyが同じであるかを判断できる。
これは、弁15号証のP74-75、114-115、127-128に載っている。
Block化によって、転送の途中で失敗しても再送する時に、ファイルの先頭ではなく、受信できていないブロックから再送すればよくなるため、効率がよくなる。
また、同じファイルをブロックごとに複数のノードからダウンロードできるため効率がよくなる。
これを多重ダウンロードと言い、複数のノードが持つファイルがHashで同じファイルであることが保証されている時に発生する。
開発当時、多重ダウンロードは他のファイル共有ソフトでも存在していた。
弁15号証のP75、125-127に記載されている。
Cache化しないと、多ノードからダウンロードされた時に送信者に負荷がかかる。
Cacheがあると、そのCacheをダウンロードしたノードがそれを他ノードに送信できるようになり、負荷分散につながる。
弁15号証のP64に記載されている。
キャッシュ化することで、データが存在していても、そのデータの第1送信者は匿名になる。
しかし、どのようなデータがやり取りされているかは分かる。


全く関係のないノードがファイルのキャッシュを持つことがあり、これを中継機能と呼ぶ。
Proxyサーバの代理機能を応用しており、SenderがRelayノードに対してを一度Cacheを送り、そこからReceiverにCacheを送る。
キャッシング機能によって効率が上がり、匿名性も確保できる。
あるノード（Relayノード）がBodyを持っていなくても、そのノードが確率的にKey内にあるBodyを持つノードの情報を自ノードの情報にRewriteしてKeyを転送し、ReceiverがそのKeyをもってダウンロードを試みると、Bodyを持たないRelayノードがSenderからCacheを受信し、Relayノードが受け取ったCacheをReceiverに送ることで、中継ダウンロードが行われる。
Keyの中の元ファイルのIPアドレスとポート番号がRelayするノードの情報に書き換わることによって中継されるようになる。
この中継機能は、KeyとBodyを分けたファイル共有の1応用である。
そもそもKeyというものを使うことがなかったので、この考え方は世界初である。
中継すればするほど匿名性が上がるが、無駄なコピーが増えると指数関数的に転送量が増え、Freenet的になってしまう。
＜中継発生率が0である時の効率を基準として、低発生率で効率が極大となり、それ以上の発生率では効率が0に収束していくグラフを表示しながら＞中継発生率と全体の転送効率との関係については、転送効率が最大となるのは低中継発生時である。
弁15号証のP65-67、111-112、117-119、149-151に記載されている。
Winnyの転送効率と匿名性についてのポリシーは、転送効率を優先させることである。
匿名性を上げるために転送効率を犠牲にしているようなことはしていない。
ファイルを持っていない人、つまりキャッシュを全く持っていない人が中継する確率は、動的だが4%である。
この確率は、匿名性の観点からすれば低いかもしれない。


Winnyで使っているキャッシュを暗号化しているのは、ユーザが見る必要がないためであり、セキュリティ的に中を見れない方がよいと考えているからである。
暗号化している程度は必要最小限である。
共通鍵暗号方式を使用しており、キャッシュの暗号化の鍵管理はプログラム本体中に固定鍵が埋め込まれているため、解析すれば暗号化の鍵が分かってしまう。
共通鍵暗号とは暗号化と復号化の鍵が共通である暗号方式で、鍵が分かれば復号化できる。
暗号をかけるのは、無いよりマシと言える程度である。
複雑な暗号方式をかけると効率が下がる。
公開鍵暗号方式という、2つの鍵を使い分ける、より強力で複雑な暗号方式がある。
その使い方は2通りあり、1つ目は、PublicKeyでは暗号化できるが復号化できないとき、SecretKeyでのみ復号化ができるため、鍵管理が楽となる。
2つ目は、PublicKeyでは復号化できるが暗号化できないとき、SecretKeyでのみ暗号化ができるため、デジタル認証に用いられる。
Winnyでは他にも暗号化している部分があり、暗号化しているのは、キャッシュ、通信部分、Node情報、プログラム本体、Winny2のデジタル認証の部分である。
通信部分の暗号化については、暗号方式は共通鍵暗号方式であり、鍵は通信の始めに乱数で発生させて送っている。
これは世間では金庫の上に鍵を置いているようなものであるが、無いよりマシなので暗号化している。
ノード情報の暗号化については、IPアドレスとポート番号をセットにして暗号化している。
IPアドレスなどは一般的には見えない方が良いため、暗号化している。
暗号方式は共通鍵暗号方式であり、固定の鍵がプログラム本体中にある。
通信内容を監視するソフトを使えば、通信相手のIPアドレスとポート番号は容易に分かる。
プログラム本体の暗号化はクラッキング対策のために行っており、ユーザのネットワーク全体に対する攻撃を防いで、ネットワークの効率を下げないようにするためである。
プログラム本体にはネットワークの効率を操作するコードが含まれており、そのコードが操作されないようにするためである。
例えば、自分に都合のいいようにダウンロードのみをする等の改造したWinnyを使うユーザが出てくると、ネットワークの効率が下がるためである。
これらは、弁15号証の（？）に記述されている。
ここまでがWinnyについての技術的な被告人質問でした。
被告人が、他にも応用がききそうな技術を考案して、Winnyに詰め込んでいることが分かりますね。
わたしが書いた論文の手法の一部にWinnyの技術の一部を取り入れると、さらに効率が上がりそうな感じなので、1年くらい前に知っておきたかったところ。


続いて、京都府警が作成した調書へのツッコミコーナーです。
先に復習しておくと、甲34号証と甲68号証は同じ日に行われた、それぞれ愛媛と群馬の正犯宅からの送信実験の検分調書であり、甲68号証では50MBのファイルの受信は失敗したが8MBでは成功していたというもの。
甲67号証は別の日に行われた、群馬の正犯宅からの送信実験の調書。

甲（17？）号証の写真番号20、および甲57号証の写真番号3に、TCP Monitor Plusについての図がある。
TCP Monitor Plusを用いてTCP/IP解析をするにはソフトを起動するだけなので、使うには特に技術はいらない。
京都府警のダウンロードについての検証がいくつかあったが、甲68号証の正犯宅からのダウンロード実験では大きなファイルはダウンロードできていなかった。
この原因は分かり、京都府警側のポートが開いてないと考えられる。
検索かダウンロードかの接続によらず、接続があった場合には逆接続によってポートが開いているかを確かめている。
そのポートチェックで弾かれれば、接続は30秒で切断される。
30秒間しか転送できないので小さなファイルしかダウンロードできなかったと考えられる。
このような場合、経路を設定する装置であるルータで、適切な設定する必要がある。
京都府警の実験では、ポートの開放をするための設定が必要であった。
ポートの開放とは、ルータの特定のポートをLAN内のPCにつながるようにすることである。
Winnyでは、ポートが開いていないと通信が行えなくなって全体の効率が下がるために、ポートの開放が必要となる。
ポートが実際には開いていないのに開いていると申告しているとき、アップロードできないノードが増えて効率が下がるために、逆接続のポートチェックを行っている。
ルータの種類によって、ポートの開放の設定方法は異なる。
ポートの開け方を自身のホームページに記すようなことはしていない。
Winnyはβ版であるため、ポートを開けられない人が使うようなソフトではない。
β版とはテスト版であり、技術的に知識がある人にテストをやってもらうためのものである。
ポートを開けられない人には、Winnyは使ってほしくない。


甲34号証のネットワーク構成図の備考欄に、群馬実況見分用、愛媛実況見分用ともに211.18.147.35という同じIPアドレスが記述されている。
このIPアドレスの設定はLAN内では使わない。
プライベートネットワークで使えるIPアドレスは決まっている。
プライベートIPアドレスは3種類で、10.から始まるクラスA、172.0.から始まるクラスBと、192.168から始まるものがある。
211.18.147.35はDIONのアドレスで、プロバイダのIPアドレスである。
ルータを介したPCに内部IPアドレスとして設定すれば、インターネットへの接続はできない。
（弁？号証は）プライベートアドレスに関する報告書であり、壇弁護士がわたしの隣で作成した。
プライベートに使っていいIPアドレスは決まっており、211.18.147.35は使ってはいけない。
ルータが192.168.1.1の場合、内部のPCは192.168.1.で始まるIPアドレスでないと外には繋がらない。
甲34号証のネットワーク構成図の設定を見てでは、この設定はできない。
甲68号証のネットワーク構成図の備考欄も同様に、群馬実況見分用、愛媛実況見分用ともに211.18.147.35という同じIPアドレスが記述されている。
このIPアドレスの設定は間違っている。
ルータのIPアドレスは192.168.1.1と書いてあり、192.168.1.xにならないといけない。
ルータによっては設定できるかもしれないが、インターネットに繋がることはないと言える。


（甲？号証の）写真番号7には、Winnyに32181のポートの設定がされている様子がある（？）。
群馬の正犯はPCを買ってからポートの設定をしたことがないと言っている（？）。
甲67号証の写真番号24から、平成15年11月27日の通信実験のポート番号が32181であることが分かる（わたしの記録では甲67号証は平成15年12月2日、甲68号証は平成15年11月27日の実験となっているので、どちらかが間違い？）。
このポート番号は通信可能な設定である。
甲55号証は京都府警側のダウンロードの調書であり、写真番号4から通信相手のポート番号が22330であると分かる。
送信側の設定しているポート番号と受信側が接続するポート番号が違うと、その間では通信はできない。
ダウンロード実験で、ポート番号22181をWinnyで使っているのに、ポート番号22330に対して繋げようとしたのは矛盾している。


内部IPアドレスが、設定できないIPアドレスと書いてあることについては、ダウンロードする側もポートを開ける必要があるということを分かっておらず、いい加減な調書となったのではないかと思う。
ポート番号の相違については、どちらかが間違えているか、書類が間違っているかであると思う。
前者の問題では、調書の全体の話を信じると仮定すると、LAN内のPCに設定したIPアドレスの記述が間違っていて、単にポートが開いていなかっただけかもしれませんね。
後者の方も、調書の全体の話を信じると仮定すると、書類が間違っていただけと言えます。
どちらも仮定しないといけなく、そのような調書を証拠として扱うのはどうかと思いますね。

Winny2は、ファイル共有機能を応用した掲示板機能を主としている。
開発するにあたり、Winny1のファイル共有機能からBBSができるのではないかと思った。
ファイル共有ソフトを使った掲示板はいろいろな試みがあったが、まともに動くものはなかったのではないかと思う。
サーバによるBBSであれば、すべての情報がサーバに集まるため、誰がどの順で書き込んだかが分かるため同期が取れ、削除するときもサーバのデータを削除するだけなので簡単に管理できる。
一方、P2Pでは、各ノードが持っている情報が異なるので、誰がどの順で書き込んだかの同期を取ることが難しく、削除するにも情報が各ノードに存在するため管理が難しい。
Winny2では、スレッドをたてた人がそれを管理するIPアドレスが固定であるので、そのIPアドレスは比較的容易に分かる。
弁15号証のP171-172に載っている。
Winny2β7.1では、スレッドをたてた人と書き込んだ人を特定するために、デジタル認証を用いている。
書き込みを消したり、スレッドを消したりする管理ができるようにしようと思ってやり出した試みであり、まだ途中である。
デジタル認証がなければ誰がスレッドをたてたり書き込んだりしたかを特定できないため、デジタル認証を用いている。
この機能が開発途中であるのは、警察が開発を止めているためである。
これをファイル共有に応用することは可能である。
（この機能は作らないのか という質問に対して？）作っていいんですか？（？）
BBSの機能をそのままファイル共有に持ってこれるはずであり、ファイル共有で問題なファイルが流れると、それを消す機能が実現できる可能性がある。
最後の質疑から、Winnyの開発を続ける気がないのではなく、警察に申述書を書かされたために開発を中止したという感じであることが読み取れました。


今回は以上で終わりです。
弁護側のスライドの配布等はないのでしょうか。
今回のスライドは、Cacheと書くべきところがCashになっている点が多数あったので、次回以降に再利用する際には修正すべきでしょう。
次回以降、村井純氏がいつ来るのかが気になるところ。