<前の日記(2009年08月30日) 次の日記(2009年09月23日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1688   昨日: 1737

2009年09月19日

ドワンゴ勉強会でお話ししたこと

8月28日の夕刻、ドワンゴ主催の「技術勉強会」にお招き頂き、少しお話をしてきた。テーマは「P2Pネットワーク」。もしもニコニコ動画をP2P方式で配信する(回線コスト軽減のため)としたらというテーマが暗に想定されているようだったので、それに沿ってお話しした。講演者は他に、金子勇氏と、NTTの亀井聡氏、P2P型掲示板「新月」の開発者でドワンゴ社研究開発部の福冨諭氏ほか。

私からお話ししたのは主に以下の2点。

  1. そもそもなぜP2Pにするのか。手段が目的になってしまってはいけない。
  2. 利用者のプライバシーを確保する設計の必要性と可能性。

1点目は、以前からあちこちで話してきたことで、そもそも「P2P」とは何かというときに、peer-to-peer方式のネットワークという元来の意味に立ち返れば、decentralizedな構成にできて、ad hocに構成できるといった性質が技術的特長となるわけだけども、そういうのは昔からあったわけで、この10年「P2P」と呼ばれるようになったものの新しい性質はといえば、ピアの管理主体が個人であることであって、その結果として出てきた特徴が、管理不能性の実現が可能となったことと、トラフィックの分散が商業的な運営主体を介さずに実現可能ということである。

ニコニコ動画の配信にあたっては、管理不能性は無用であるから、P2P化することの意義はトラフィックの分散という点に尽きる。トラフィックの分散化が本当に効率的に実現可能なのかというテーマについては、亀井さんから興味深い解説があった。私も質問したのだけども、日本の現状のISPの構造では、物理的な通信回線と論理的なインターネット回線が別事業者により提供されていることが多い関係上、行って戻ってくるという無駄なトラフィックが多く発生し、P2Pに向かない傾向があって、将来に向けて何か対策が求められるところと理解した。

2点目は、適切なプロトコルを設計すべしという話と、ポート番号を所定の番号にした方がよいという話をした。

金子さんの講演で、彼が現在開発に関わっているというコンテンツ配信システムで、通信プロトコルを暗号化しているとの話があったので、その暗号化は何のためのものかと質問したところ、難読化のためなのであまり意味はないがいちおう暗号化しているというような説明*1があった。

たしかに、Winny等の不特定多数向けのP2P型ファイル共有ソフトでは、通信の部分をいくら複雑な暗号アルゴリズムで処理しても、リバースエンジニアリングによってアルゴリズムと埋め込み鍵が判明してしまえば、その意味は無くなる。このことは金子勇著「Winnyの技術」p.151に書かれている通り*2である。しかし、それはすべてのP2P型システムに言えることではない。たとえば、Skypeでは適切な方式で暗号化して秘匿性や完全性が確保されているだろう。

管理サーバが存在する場合には、ピアのプログラムがリバースエンジニアリングされても破られないような制御方式を設計することが可能なはずである。ニコニコ動画の配信にあたっては、管理不能性は無用であるから、管理サーバをなくすことはもとより追求しないのであろうし、利用者は基本的にニコニコ動画のアカウントでユーザ認証した状態で使用するのであるから、管理サーバが持つ秘密情報に基づいて個々のピア間の通信を制御することで、プロトコルについての防御はさほど複雑な方法でなくとも可能だろう。

尤も、隣のピアが要求するファイルを自身のcacheから送信するという単純な仕組みにする場合、どのファイルが持って行かれているかは判別できてしまう。それをわかりにくくする工夫はいろいろあり得るだろうけども、効率は下がるだろうから、実際問題どこまでやる必要があるのかということになる。

隣のピアが自分と嗜好が近い人だということがある程度バレてしまうのはやむを得ないとするあたりが現実的な落とし所だとしても、クローラーのようなものが作られてピアが観測されてしまうようなプロトコルは避けておきたいところだろう。ニコニコ動画の場合では、コンテンツの転送以外の要求(検索やコメントの書き込み等)は直接サーバで処理すればよく、その部分をP2P方式にする必要性はないだろうし、ピア間通信のための制御情報も直接サーバからもらうようにすることもできるので、その懸念は簡単な方法で回避できるのではないか。

もし本当にニコニコ動画のP2P配信化が実現されるなら、ぜひこうした観点を踏まえて開発してほしい旨を伝えた。

ポート番号の話は、Winny等のように初期設定時にランダムに決定(し、ほぼ固定化)するポート番号を使うのではなく、決められたポート番号を全員が使うようにした方がよいという話をした。(外部からの接続待ち受けポートを必要とする設計とする場合には。)

Winnyでも初期のころは7743番で均一だった(金子氏から「最初は80番だった」というツッコミがあった)が、後にランダムに初期設定されるようになった。その目的が何だったのかは知らないが、ネットワーク上で勝手にポート単位で規制されるのを嫌がってのことであれば、ニコニコ動画の配信においては、あえて管理しにくくする必要がないはずだ*3。ポート番号が利用者ごとにバラバラになっていると、IPアドレスとポート番号の組によって個人が追跡される可能性が生じてくるので、そういうのは避けた方がよいという話をした。

適切なプロトコル設計によって秘匿性が実現されたとしても、IPアドレスとポート番号については、接続先のピアに知られてしまう。図1は、Skeype使用中の様子であるが、「netstat」コマンド等によって、自分のコンピュータの現在の接続先のIPアドレスとポート番号を知ることは誰にでもできる。

画面キャプチャ
図1: Skype使用中に「netstat」コマンドを実行した様子

これを繰り返して記録すれば、ある時刻におけるIPアドレスとポート番号の組を各個人が蓄積できるようになる。それぞれの人が蓄積できる量は少ないかもしれないが、もしニコニコ動画がP2P配信化されて、何百万人もの人々に常時使われるようになったとすると、集められる量はそれなりの量になるかもしれないし、各ユーザから蓄積データを買い取ってデータベース化する業者が現れることも考えられる*4

IPアドレスは時々変化するものであるから、ある時刻にAさんの家のものだったIPアドレスが、別の時刻にAさんの家のものだとは限らないわけで、本来、追跡性はブツブツに分断されたものとなるはずである。しかし、ポート番号が人それぞれに異なって設定されているようなP2P型通信プログラムが常時稼働するような状況では、IPアドレスとポート番号の組によって、分断されたものが1つに縫合されてしまう可能性が出てくる。

ポート番号の多様性は高々数万程度であるから、大きなISPでは同じISPで同じポートを使う人が数人程度いるかもしれないが、小さなISPだったり、あるいは、大きなISPでも地域毎にアドレス範囲が分けられていたりすると、ポート番号で個人が識別されることが起き得る。

こうした事態を避けるよう、P2P型のシステムの開発においては、ポート番号に配慮するべきだと思う。所定のポート番号に固定する方法の他にも、適当なタイミングで使用ポート番号を変える設計にすることが考えられるが、その場合は、NATのポートフォワーディング設定を利用者に変更させる手間をかけさせない方法にする必要があるだろう。Skypeでは、NATのポートフォワーディング設定を必要としない方式が採用されていて、ポート番号はおそらく毎回変えられているのだろう。

勉強会では言いそびれたが、適切なプロトコル設計で秘匿性を確保し、ポート番号にも配慮して追跡性を遮断したとしても、プロトコル設計が十分に適切でないと、通信を観測する(通信当事者が自分の通信を観測する)ことで、通信相手を識別できる何らかの固定値を得られてしまう事態も考えられる。その点にも配慮したプロトコル設計が求められると思うし、それは実現可能だと思う。

参考文献

*1 ただ、開発の詳細をすべて把握しているわけではないとの発言もあったので、本当にそうかは確認するまでわからないと考えた方がよさそう。

*2 次のように書かれている。

しかしWinnyの場合、通信相手は不特定であり、Winnyプロトコルを使う誰もが通信相手になれます。たとえば、Winnyプロトコルを真似てWinnyノードに接続するようなプログラムの作成ができれば、接続相手のキャッシュファイルを観察することも可能です。このため、たとえどんなに強い暗号方式で通信内容を暗号化したとしても、通信相手は解読可能であり、通信内容は隠しようがありません。

また、Winnyのキャッシュファイルは、そもそも公開されているデータと考えるべきです。

Winnyの技術, 金子勇, アスキー, 2005年

*3 むしろ企業内ネットワーク等で簡単に規制できる余地を残すためにも、ポート番号は決め打ちにして広く知らせた方がよいという面もあるだろう。

*4 現行の個人情報保護法では、IPアドレスや、IPアドレスとポート番号の組、さらには時刻と組み合わせた情報のいずれも、それら単体では同法の「個人情報」に該当しない。

検索

<前の日記(2009年08月30日) 次の日記(2009年09月23日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|
<前の日記(2009年08月30日) 次の日記(2009年09月23日)> 最新 編集