« 2006年7月 | トップページ | 2006年9月 »

2006年8月の6件の投稿

2006.08.26

[DHT]第2回DHT勉強会講演概要&タイムスケジュール

お待たせしました、第2回DHT勉強会講演概要をお知らせします。

講演概要
===

◇日時:9/18(月、祝) 
開場:9:30
講演時間:10:00~16:30

◇場所:金沢工業大学東京虎ノ門キャンパス1F (93.101)
アクセス方法:
http://www.kanazawa-it.ac.jp/tokyo/map.htm
◇定員:60人
◇参加費:1000円程度(調整中)
◇参加申込フォーム(お手数ですがMixi経由でお願いします)
http://mixi.jp/view_event.pl?id=8168327

講演タイムスケジュール、講演概要

9:00~ 開場準備開始

9:30~ 開場

10:00~ 開会の挨拶

10:10~
加藤 大志 氏:NEC
「世界規模情報共有プラットフォームの実現に向けて」
(概要)
ユーザが主体となって形成する情報共有プラットフォーム構想を紹介する。これを実現するための一つの技術としてDHTに着目し、低通信量を達成するためにconstant-degree DHTと呼ばれる方式を説明する。
また、DHT実装をエミュレートする基盤を使って複数の既存DHTを比較する実験およびその結果を紹介する。

11:10~
西谷 智広:Tomo's Hotline
「DHTにおけるセキュリティ対策」
(概要)
DHT におけるセキュリティ対策が近年注目を浴びている。本講演はルーティングテーブル及び登録データの改ざん、登録データの意図的ロスト、PKIを用いた認証、運用管理性の向上、システム可用性等について議論を行う。また上記対策を用いたアプリケーション構築方法についても提案を行う。

12:00~13:10 ランチタイム

13:10~
吉田 幹 氏:(株)BBR 取締役CTO
「P2Pエージェントプラットフォーム PIAX の理念と実装」
(概要)
ユビキタスサービスに狙いを置いた P2Pエージェントプラットフォーム PIAXについて、理念と実装の面からお話します。PIAXの特徴は、マルチオーバレイのサポートと分散エージェント機構にあり、とりわけ地理的情報探索のためのオーバレイ(LL-Net)を持つ点に特色があります。今回はPIAX技術に加え、実装で用いたSkip Graphと呼ばれる技術の紹介をします。

14:10~
池嶋 俊 氏:筑波大
「AsagumoWeb Web over P2Pシステムの設計と実装」
(概要)
AsagumoWebはP2P技術を利用したWebシステムである。AsagumoWebは既存のWebシステムにある負荷が集中するという問題を解決する事ができる、分散型Webシステムである。
今回は、何故分散型Webシステムが必要である背景から、Webシステムの実装の概略、P2PおよびDHT技術がAsagumoWeb内でどのように使われているかを説明する。

14:50~
藤田 昭人 氏:大阪市立大学
「Chord プロトコルを活用したシステム開発の実際」
(概要)
構造化オーバーレイの研究領域では著名な研究成果が発表されている Chord プロトコルだが、それを活用したシステム事例が増えない一因には Chord の開発元である MIT が実装コードを文字通りの AS-IS (リリースエンジニアリングしていない)で公開していることによる。本発表では主に構造化オーバーレイの研究を目指す学部学生およびその指導教官のみなさま、および構造化オーバーレイの実験を計画している一般プログラマーのみなさまへの参考情報の提供を目的として、MIT が公開している Chord 実装の概要、その代替として活用できる実装
事例、そして発表者自身の手で進めている i3 Chord を活用したシステム開発の実際について文献を含めて紹介する。

15:40~
首藤 一幸 氏:ウタゴエ(株) 取締役 最高技術責任者
「オーバレイ構築ツールキット Overlay Weaver 」
(概要)
Overlay Weaver はオーバレイ構築ツールキットです。
アプリケーション開発に加えて、オーバレイのアルゴリズム設計もサポートします。

アプリケーション開発者に対しては、分散ハッシュ表 (DHT) やマルチキャストといった高レベルサービスに対する共通 API を提供します。この API を用いることで、特定のトランスポートプロトコル、データベース、ルーティングアルゴリズムに依存しないアプリケーションを開発できます。

Overlay Weaver は、ルーティングアルゴリズムとして Chord、Kademlia、Koorde、Pastry、Tapestry の実装を提供しています。ルーティング層の分割によって、これらのアルゴリズムをたかだか数百ステップで実装することが可能となりました。ルーティング層は高レベルサービスの下位に位置し、ルーティングドライバ、ルーティングアルゴリズム、およびメッセージングサービスから構成されます。この分割によって、新規アルゴリズムの実装も容易になっています。

Overlay Weaver はまた、新たに実装したアルゴリズムを試験、評価、比較するためのエミュレータも提供しています。このエミュレータは数千の (仮想) ノードを扱うことができ、大規模エミュレーションによるアルゴリズム間の公正な比較を可能にします。

16:30 閉会の挨拶

17:00 後片付け終了

====

皆様のご参加を心よりお待ちしています。

| | コメント (2) | トラックバック (1)

2006.08.17

[P2P]P2P納涼会のお知らせ(8/25[金]開催:新宿)

P2Pコミュニティにおいて新年会に引き続き、納涼会を開きます。
P2Pに関心がある方であれば誰でも参加OKです!
奮ってご参加願います。
なお、応募はMixi経由でお願い致します。

□日時:2006年8月25日(金)19:00~
□場所:北海道 新宿三越前店(場所が変更になりました!ご注意願います)
http://r.gnavi.co.jp/g306019/
□会費:4000円程度を想定(出来高制)

申込みは以下のページからお願い致します。
http://mixi.jp/view_event.pl?id=7924684&comm_id=6936

皆様の参加を心よりお待ちしています!

| | コメント (0) | トラックバック (0)

2006.08.10

DHTのセキュリティ考察~その5 ノードIDの偽装対策

今回はDHTのNodeIDの偽装対策について検討しよう。

□Chordの実装
ChordはNodeIDとして、IPアドレスのハッシュ値を取っている。
IPアドレスは(グローバルなら)一意だし、また通信ノードのIPアドレスが分かれば、NodeIDとIPアドレスからノードの正当性が簡単に確認できる。

しかしこの方法は次のような課題点がある

[課題点]プライベートアドレスのノードが存在すると、NodeIDが衝突する恐れがある
[課題点1-1]NAT-FW、プロキシがある場合、仮にグローバルアドレスをノードが
取得しても
NodeIDが衝突してしまう。
[課題点1-1-1]グローバルアドレスをノードが自動的に取得する方法がない場合
がある
[課題点1-2]固定IP払い出しサービスでない限り、IPアドレスは変動する

ではどのようにすれば良いのか?

□Chord実装の拡張

ひとつの方法はIPアドレスとポートを組み合わせた数値のハッシュ値をNodeIDとする方法である。これにより課題点1-1はクリアする。ただし、やはり[課題点1-1-1]を検討する必要がある。

課題点1-1-1,1-2の解決方法としてはSTUNやTURNサーバを使って、ノードがインターネットで通信する際のグローバルアドレスとポートを定期的に取得することが必要だろう。もちろんUPnPを利用する方法もある。

□電子証明書による正当性確認

もうひとつの正当性確認方法は電子証明書を利用する方法である。
各ノードに配布した電子証明書のシリアル番号と名前の組み合わせを数値化し、そのハッシュ値をNodeIDとする。検証する際には電子証明書を参照し、検証するノードとチャレンジレスポンスをすればよい。
(チャレンジレスポンスをする理由は電子証明書を持っている人が本当に発行元のノードであることを確認するため)上記方法はノードがプライベートアドレスでもグローバルアドレスでもまったく関係なく正当性が確認できる利点がある。

ただし、この方法はノードに負担かかることは言うまでもないだろう。

| | コメント (0) | トラックバック (0)

2006.08.09

[DHT]DHTのセキュリティ考察~その4

DHTのセキュリティにおいて、少し見方を変えてみよう。

P2Pシステム代表例であるWinnyではキャッシュが管理者等によって削除されな
かったのが問題であった。DHTで掲示板等を作成すると管理者によってコメン
ト変更あるいは削除することが必要であろう。

ここでは管理者(スーパーユーザ)によるP2Pシステムを管理を提案する。

まず、管理者は付与された電子証明書に管理権限があることを明記される。
これは第三者に管理権限があることを確認させるためである。

今、管理権限があるユーザをスーパーユーザと呼ぶことにする。
スーパーユーザは、データの削除、変更が可能である。

データを削除する際には、該当データを保有する登録ノードに削除依頼をする。
登録ノードは管理者の電子証明書を参照して管理権限があることを確認し、デー
タを削除する。

□スーパーユーザの分散管理

上記のような仕組みの場合、悪意のあるスーパーユーザはデータを簡単に削除、
改ざんできる。このような悪意のユーザがいる場合でもシステムが保持できる仕
組みを提案する。

先ほど、管理者は登録ノードにデータ削除依頼ができるとした。ここで、管理者
から登録ノードにはXMLベースでメッセージを投げるとする。
このとき、XMLに複数の管理者の多重電子署名がない限り登録ノードは削除を
実行しないようにすることもできる。つまり、複数のスーパーユーザの同意が取
れない限りデータの削除はできない。

□スーパーユーザの権限剥奪

スーパーユーザに対して権限の剥奪も可能だ。トラストと考えられるユーザを
トップユーザとして、スーパーユーザの権限の付与を与える。
スーパーユーザの権限を剥奪する場合には、該当ユーザの電子証明書を失効する
手続きを行う。CAはCRLをDHTに配布する。

□まとめ
PKIをうまく使うことにより、複数の管理者によってP2Pシステム管理が可
能であることがわかる。多重電子署名を使えば、管理者による権限逸脱を防止す
ることも可能だ。

| | コメント (0) | トラックバック (0)

2006.08.08

[DHT]DHTのセキュリティ考察~その3

前回はDHTにおける完全性について議論を行った。
ここで残課題であった、

[脅威1]登録ノードによって登録データが消去される

について議論しよう。

ひとつの簡単な対策として、同じデータを複数ノードに登録することが挙げられる。

つまり、Xという情報については通常Node_ID=Hash(X)となるノードに登録する
(これを登録ノード1としよう)が、これ以外にも

[登録ノード2]Node_ID=Hash(X+Z)
[登録ノード3]Node_ID=Hash(X+2Z)

に登録する方法である。(Zはシステムが設定した数字)

つまり、登録ノード1~3を参照することによって、登録ノード1~3がXに対する情報を削除しな
い限り、Xという情報を参照できるということになる。

ただし、登録するデータ量はシステム全体で見ると膨らむし、参照する際のパケット数も増えるとい
うデメリットがある。
脅威1に対する上記対策はシステム負荷とトレードオフの関係にある。

| | コメント (0) | トラックバック (0)

2006.08.04

[DHT]DHTのセキュリティ考察~その2

今回はDHTにおける完全性対策について提案を行ってみたい。

□完全性に対する脅威
DHTにおいて、情報XはNode_ID=hash(X)というノードに登録される。(これを登録ノードと呼ぶことにしよう)
この方法だけではざっと検討しただけでも以下のような脅威が考えられる。
[脅威1]登録ノードによって登録データが消去される
[脅威2]登録ノードによって登録データが改ざんされる
[脅威3]登録ノード以外の第三者によって登録データが消去される
[脅威4]登録ノード以外の第三者によって登録データが改ざんされる

今回は脅威2~脅威4の対策を説明する。

□電子証明書のノードへの配布

セキュリティ対策の基本的テクニックとして電子証明書を利用することが挙げられる。
例えばDHTの各ノードに電子証明書を配布することにしよう。CRLについてもDHT各ノードに配布、あるいは取得できるようにする。なお、証明書発行ノードがDHTノードとは別途必要である。

電子証明書には氏名(あるいはニックネーム)や発行日等が記載される。ここで提案として各ノードのノードIDを電子証明書に掲載することが考えられる。そうすれば、各ノードは自らのノードIDの正当性証明することができる。もちろんノードIDは証明書発行ノードが払い出しを行う。ノードIDはハッシュ空間を均一に埋めるように発行しなければならない。(ノードIDを電子証明書に格納するメリットは次回以降詳細に説明します。)

各ノードの電子証明書はあるサーバに対して参照できるようにしても良いし、せっかくDHTがあるので、DHTに電子証明書を分散させて格納するのも良いだろう。

□登録ノードへの情報登録

いま、ノードAがXという情報をNode_ID=hash(X)となる登録ノードBに格納したい。
すると次のような手順を行う。

[手順1]ノードAはノードBに電子証明書を提示する。ノードBは電子証明書が有効であることを確認すると同時にノードAが本当に電子証明書所持者と同一か確認する。
確認方法としてチャレンジレスポンス等が挙げられる。
[手順2]ノードAはノードAの秘密鍵S_Keyでhash(X)を暗号化する。これをS_hash(X)としよう。
[手順3]ノードAはX、S_hash(X)をノードBに登録依頼する。
[手順4]ノードBはノードAのノードID、X,S_hash(X)を格納する。

S_hash(X)はXに対する一種の電子署名と考えてもらっても良い。
Xが改ざんされているかどうかはノードAの電子証明書を取得して、その公開鍵を使ってS_hash(X)からhash(X)を復号すればよい。

なお、データの削除手順は以下の通りである。

[手順1]ノードAはノードBに電子証明書を提示する。ノードBは電子証明書が有効であることを確認すると同時にノードAが本当に電子証明書所持者と同一か確認する。
確認方法としてチャレンジレスポンス等が挙げられる。
[手順2]ノードAはX、S_hash(X)をノードBに削除要求をする。

上記手続きにより脅威2~4は防止できる。脅威1については、データを隣接ノードでレプリケーションするので、この部分を工夫すればある程度防止できるかもしれない。今後は脅威1の対策を検討したい。

| | コメント (3) | トラックバック (0)

« 2006年7月 | トップページ | 2006年9月 »