[P2P]Mixi-P2Pオフ会講演資料案

昨日（土曜日）深夜まで作業だったので大変疲れています。

ようやく今週末行われるP2Pオフ会の講演プレゼン資料を完成しました。今後は見た目などは整えるかもしれませんが、内容的にはほぼ変わらないはずです。

下記のURLから閲覧可能です。（パワーポイントです）
Mixi　P2Pオフ会資料案

コメント等ありましたらご連絡をお願い致します。

さて、もうちょっと寝て疲れを取るか。。。

[P2P]Mixiオフ会資料案

11/7（日）のMixiオフ会の資料案を半分程度作りましたので公開します。
講演時間は講演25分＋質問５分の予定？かな。

資料の置き場。

皆様のコメントお待ちしています！

[P2P]ホームページの次の章は。。

P2Pのホームページの方ですが暫くの間更新されていませんでした。。すみません。
まだ時間の余裕がないのですが、次回はDHTを使ったVoIPのシステムの構築方法の提案について説明する予定です。
現在のSkypeを越える？方法をまとめる事です。

具体的には

・DHTを使ったNAT越え手法
・PKI or PGPによる認証とセキュアな通信
・プレゼンス情報等の付加機能との連携
・匿名性の確保
・SIPとの親和性

について噛み砕きながら書く予定です。
ご期待下さい。

[P2P]P2Pソフトによる新たなDDoS攻撃の可能性について

mixiのオフ会でセキュリティの話でもしようかと思い、色々考えていたのだがP2Pソフト、特にファイル共有ソフトは場合によってはとんでもない事態を起こす可能性があるのでは、と思ったので書いてみる。ここではファイル共有ソフトに限ってみよう。

そもそもP2Pソフトはネットワーク経由でのアタックにおける脆弱性対策を考えなければいけない。というのはP2Pソフトはポートに穴を開ける場合があるので、そのポートがセキュリティ的に甘くなるからである。P2Pソフトの通信ポート経由でP2Pソフトの脆弱性を突くワームが発生したらどうだろうか？たちまちP2Pネットワークを辿って迅速かつ広範囲に被害が拡散することが考えられる。

パーソナルファイアウォールを使えば良いのでは、と言う考えもあるがそれは甘い。というのはポートの穴あけをすると、そのポート通信についてアタックを検知しない場合があるのだ。（これはルータも同様。）また仮に穴あけをしたポートに対してアタックを検知・遮断をしたとしても、そのパターンファイルの供給は遅くなるはずだ。
なぜならパターンファイルについてはユーザ申告に基づいて作成するが、各ソフトの脆弱性をついたワームに関するパターンファイルを実際作るかどうかはファイアウォール会社の本社にゆだねられるからである。これが日本発のP2Pソフトであれば対応は非常に遅くなるだろう。また、ファイル共有ソフトは一般的に長時間立ち上げっぱなしの人が多いのも被害を大きくしてしまう理由となるだろう。

まとめると、P2Pソフトでは、その脆弱性をついたワームが出現すると広範囲に短時間に広がる可能性がある。

ここで、より深刻なケースを考えてみよう。
例えば、このワームが無差別にある相手と大量にファイル共有するものだとする。これはとんでもないことになるのが容易に想像できるだろう。
P2Pネットワークは広範囲に感染したワームによる無差別ファイル共有のため、とてつもないトラフィックを生み出すであろう。これは現在のインターネットインフラを破壊する可能性がある。すなわち、無差別ファイル共有によるトラフィックのため、通常のWEBやメールなどの通信ができなくなる可能性があるのである。P2Pソフトは通信ポート番号を変えられるので、単なるポートフィルタリングではこのP2Pネットワークのトラフィックを抑えることができない。このような事態になれば症状は簡単には解消できないはずだ。

今回の攻撃は一つのサーバを多くのユーザ（ゾンビと呼ばれる）がアタックする一般的なDDoS（分散サービス拒否攻撃）とは違い、ネットワークに狙いを定め、それを多数のユーザにより発生する巨大なトラフィックによってダウンしてしまう新たなタイプのDDoS攻撃だ。下手をすると国家レベルでネットワークがダウンしてしまうかもしれない。

こんなことが起きない事を祈りたいものだが。。

[P2P]mixiのP2Pオフ会の講演テーマ

mixiのP2Pコミュニティのオフ会で講演を頼まれている件で、文系の人が多いようなのでテーマをどうしようか迷っている。P2P勉強会は正直言って理系バリバリの人が多かったのでDHTの話をつっこんで講演しても良かったのだが、文系の方がそれなりにいるとなるとそれは無理っぽい。

やっぱりセキュリティの話になるかなぁ～。
こんな感じ？

・P2Pでこんなセキュリティ事故がありました。（情報漏えいなど。）
・セキュリティポリシーは大切だよね。（どんなスタンダート、プロシージャになる？）
・P2Pだからこそ匿名性が必要なわけ。（技術：プロキシ、MIX-net、秘密分散法）
・P2Pでも認証が必要なわけ。（技術：PKIとPGP、鍵の預託とか？）
・おまけ：DHTのご紹介。（時間があったら）

セキュリティに限らず、こんな話が聞きたいというのがあればご連絡をお願いします。

[mixi]オイスターバー

皆様の熱い要請に応え、オイスターバーのコミュニティを作りました。
オイスターバーに行こう！皆様、ぜひ参加を。

P.S. MixiのP2Pオフ会での講師の要請を受けました。おそらくDHTかセキュリティの講演をする予定です。
オフ会は11/7(日）に渋谷近辺の予定なので、興味のある方は下記のmixiのコミュニティをウォッチ＆参加してください。
P2P（mixi)

[mixi]VoIPコミュニティ作りました。

ということで、mixiでVoIPのコミュニティがなかったので作ってしまいました。皆様是非参加を。

VoIP
http://mixi.jp/view_community.pl?id=43848

ちなみに「放送と通信の融合」というコミュニティも作っていますのでこちらも是非。

※クラシック曲や民謡をモダンにアレンジして人気を博している女声アカペラ・グループ「アンサンブル・プラネタ」のコミュニティが私以外誰もいません。。誰か入って～！

うーん、このまま行くとセキュリティポリシとかPKI、DHTのコミュニティなど作りそうだなぁ。ますます仕事に近くなっていく。

[RSS]Headlines.jp

すでにご存知かもしれないが、最近あるWEBベースのRSSリーダがリリースされている。
Headlines.jp

今まで専用ソフトでRSSを読んでいた人にとってはこのようなWEBベースのRSSリーダはありがたいかもしれない。現在ベータ版なので、まだ使い勝手がそれほど良くはないのだが、一度試して欲しい。
なお、携帯でも利用できるようだ。

個人的に改良してもらいたい点は以下のとおり。

１）カテゴライズや順序の並び替えをしたい
利用開始後、デフォルトで入っているニュース等が現われるだが、これらは全くカテゴライズされてない。ユーザはニュース/ブログの追加/削除はできるが、カテゴリの追加/削除、並びの順序などはできない。カテゴライズ機能は多くのRSSを登録する人にとってはmustの機能だろう。

2)最新更新日時がわからない
プレビューを見ると各項目の更新日時がわかるのだが、トップページからはわからない。

3)他人のリストが見られない
これは賛否両論あると思うが、他人のRSSリストを見ると自分も面白いと思って登録することがよくある。またそのようなRSSのリストを公開することによって一種のコミュニティが形成されるだろう。もちろん、RSSリストは公開/非公開をユーザ自身で選択する機能は必要だ。

RSSをキーとして、「はてな」のようにユニークなコミュニティができると良いですね。

[P2P]DHTにおけるアタックの可能性について

ファイル交換ソフト等でDHTの導入が相次いで発表されている。Jxtaでも一部ではあるがDHTの機能が具備されるようになったことから、P2PネットワークにおいてDHTは欠かせないものとなるに違いない。

ところで、DHTは本当に万能な存在なのだろうか？ここでは簡単な例を作ってアタックの可能性について考えてみる。DHTとしてChordを使う事にしよう。

例えばファイル共有を行うとする。DHTにはそのファイル名及びそのハッシュ値、ファイルを保持しているノードのIPアドレスが書かれているとする。このときに明らかにそのハッシュ値を保持しているノードはファイルを保持しているノードを知ることになる。ただし、ファイル名を書かなければこのリスクを下げる事はできるだろう。（なぜならファイル名のハッシュ値からファイル名を計算するのは困難だから。）いずれにせよ、ノードはあるノードがXというIPアドレスから繋がっているということはわかってしまう。

次に考えられるのは、ノードが自分の保持しているDHTのメタデータを強制的に削除してしまうことである。これは深刻な問題かもしれない。DHTの場合、お互いの保持しているメタデータを同期して、ノードが離脱してもNW全体としてメタデータが保持されていることとなる。そこで、あるメタデータAをメインで管理しているノードAがあるとすれば、そのノードAと同期しているノードBはノードAがメタデータAを削除すると、ノードBもメタデータAが削除されるという風に伝播される可能性がある。これを防止するにはソフトウェア的にメタデータ領域をユーザから隠蔽させるなど一捻りする必要があるかもしれない。

DOSアタックはどうだろう？DHTではメタデータを分散して保持してるために全体としては機能はほぼ停止しないと思われるのだが本当だろうか？
今、あるハッシュ値Aを管理するノードAに対してDOSアタック元のノードXが参照を行うとしよう。
すると、ノードAはDOSアタックによって当然ノードが落ちる。すると、ノードAと同期しているノードBにもDOSアタックの被害が及ぶ。この連鎖反応はおそらくハッシュ値Aが他のノードに引き継がれる速度よりもノードが落ちる速度が速ければある一定時間でDOS攻撃は終了し、ハッシュ値Aに対して全てのユーザはアクセスできないということは続くだろう。逆にまたDOSアタック元のノードのハッシュ値Aの参照のためのルーティングのためにP2Pネットワーク全体の負荷は上がるが、参加ノード数が非常に大きければこれは分散され、それほど大きなウェイトは占めないだろう。
DHTのDOSアタックについての論文はまだ見たことが無いので、この辺を研究すると面白いかもしれない。

[P2P]ファイル交換ソフトによるインシデント対応：対処編３

先日想定したファイル交換インシデントの対処編３である。対処編２では応急対処について述べたが、本編では再発防止策を考える。

まず、社内からファイル交換ソフトの利用を制限しなければならない。方法としてはファイアウォールの直下にP2Pの通信を制御する装置を入れることも考えられるが、既存システムとの整合性などをチェックする必要もあり、簡単にはいかないだろう。このような装置を入れる前にやるべきことは全社員に対するセキュリティ教育である。

今回の件で教育をしなければいけない点として

・管理者が許諾した以外のソフトウェアのインストールは情報部の許可が必要である
・社内の機密情報を部門の許可無く持ち出さない

ことだろう。また、P2Pファイル交換ソフトを使用した際のリスクも教える必要があるかもしれない。
A社ではセキュリティ技術に長けている人材が少ないため、まずは外部コンサルティングに頼み全社員に情報セキュリティ教育を受けさせた。またこの際、私用のパソコンで仕事をすることを原則禁止にすることも通知した。

次にデータはデーターベースサーバから流失したと見られるが、アクセス権が多くの人に与えられた事が問題としてある。そこで、情報資産について分類し、どの社員がどこまでアクセスできるか検討する必要がある。その検討後、データのアクセスの制御を設定する。

セキュリティポリシについても見直しをする必要がある。特にA社では個人情報を扱っているため、その保護について強調できるようなものにする事が必要だ。C氏は外部コンサルティングと連携を取りながらセキュリティポリシを策定した。

また、どのような対策をしてもリスクは顕在化する可能性がある。そこで、C氏はコンティンジェンシープランを作成した。コンティンジェンシープランとは、インシデントが起きた場合どのように対処するかマニュアル化することである。検討の際にセキュリティ委員会を設けることと、インシデント発生時の連絡体制についても見直しを図った。セキュリティ監査についてはシステム構築毎に内部監査を行い、定期的に外部監査をすることにした。

C氏はこのような対策案を社長に提出した。社長も今回の件でセキュリティに関しては深い関心を示し、ISMSの認証、プライバシーマークの取得を目指すようにC氏に指示した。

＝＝＝＝

大切な事は技術論ではなく、セキュリティポリシの制定、コンティンジェンシープランの策定、セキュリティ教育、監査の実施などPDCAローテーションをきちんと回す事である。インシデントはいつか起きるということも忘れてはならない。

[P2P]MorpheusがDHTを導入

Ringoch経由で情報GET!
ファイル検索機能強化の「Morpheus 4.5」リリース

新版MorpheusはDHT（分散ハッシュテーブル）を使っているようだ。
CNET　Download.com
Morpheus FAQ

日本でもDHTの実装研究が進めばいいのですが。。。。DHTはP2Pの汎用基盤だけに研究・開発において日本が遅れをとるのはマズイと思います。

[P2P]ファイル交換ソフトによるインシデント対応：対処編2

先日想定したファイル交換インシデントの対処編２である。対処編１では現状把握と関連部署への連絡について書いたが、今度はそれに続く応急処置である。

まず、P2Pネットワークで流失したデータがA社のデータベースから流失した事が分かった。
ここで、A社のデータベースにアクセスできるのは、A社の関連部員、委託先のB社の社員である。また外部から不正にアクセスしたり、トラッシング等で外部に流失した可能性もある。

ここで、外部から流出した可能性が少なくともあることから、まず社内システムと外部回線（インターネット等）とのアクセスを一時中断し、IDSやファイアウォール、RAS、WEBサーバ、データーベースサーバのログを調べることが必要である。ここでこれらのログ解析から外部からの不正アクセスはなかったことがわかったとする。またB社にも外部流出への調査を依頼することを忘れてはならない。

次に内部から外部へ流出したことが考えられる。その理由として、
・社内の誰かがP2Pソフトを利用してコンテンツをアップした
ことが考えられるからである。
ファイアウォールのログからは80番や25番、443番など業務等で使われる送信先ポート以外をチェックする。その結果、不審な通信は見られなかった。もちろんP2Pソフトで80番等のポートを使う事も考えられる。
そこで、全社員に社長達で

[1]クライアントにP2Pファイル交換ソフトをインストールしているかどうか緊急にチェックを行い、情報部に連絡を行う
[2]クライアントにウィルス対策ソフトが入っていて、パターンファイルのバージョンが最新になっていることを確認するとともに、クライアント全システムに対して手動でウィルスチェックをすること

上記2点を行った。後者はC氏がWソフトがウィルスによってユーザの意思に反して情報をP2Pネットワークにアップしていることを知っていたためである。この結果、A社が保有するパソコン内にP2Pファイル交換ソフトはなく、ウィルス対策ソフトは稼動しており、パターンファイルのバージョンも最新である事が分かった。当然、B社にも同様な処置を依頼する必要がある。この結果、社内システムを通じてP2Pソフトを使って機密情報が漏洩した可能性は低い事がわかった。

さて、処置はそれだけでは終わらない。掲示板にA社から機密情報が漏れているという記事が書かれている事をどうにかしなければならない。そこで、

・掲示板管理人に書かれている記事の内容について報告し、それについてのA社の事情を説明し、被害拡大を防ぐために掲示板から当該内容を削除するように依頼する

ことが賢明だろう。またメールは必ず受諾しことを返答するように掲示板管理者に要請する事も大切である。もし必要であれば、郵送（ここでは緊急性のインシデントなのでバイク便や直接渡す事がベターだろう）などを使い文書によって確認、サインをしてもらう事が良いだろう。P2Pネットワークの機密情報については削除することが誰にも出来ないので、打つ手がなかった。

では一体どうやって機密情報は漏洩したのだろうか？C氏を中心にP2Pネットワークにアップした情報を解析すると、文面の特徴から新たに発生したウィルスXによって、Wソフトがクライアントのあるホルダーから情報をアップしたことがわかった。このXは最近発生したもので、A社で全社的にウィルスチェックをした際にはパターンファイルは既に対応していた。ということは社外のパソコンに機密情報を入れいていて、それがウィルスに感染しP2Pネットワークにアップロードされてことが推測される。

A社が流出した機密情報は多くの人がアクセスできるもので、データーベースサーバのアクセスログから誰が情報を流出したが絞るところまでは至らなかった。またWソフトは極めて匿名性が強いので、最初のアップロードをしたクライアントを特定することは難しかった。

ここで、C氏は現在までの経緯、流出した情報の被害範囲・被害額、原因を経営陣に報告し、早急に恒久的対処策を検討することを伝えた。また、A社の機密情報はアクセス権によって守られていたものであるから、その流出は不正競争禁止法に反する事だとC氏は考えた。広報部と相談し、警察に事実を報告した。

さて、考えてみると社員が機密情報を上司の断りをなしに自分の私的PCに入れたことが問題のようだ。そこで、再発防止策及び恒久的対処としてこのことを踏まえて検討することが大切である。それは後日述べよう。

[MIXI]コミュニティを作りました。

ようやくというか、初めてmixiでコミュニティを作りました。mixiにすでに入っている方はチェックしてみて下さいね。

「放送と通信の融合」
http://mixi.jp/view_community.pl?id=41929
デジタル放送によっていよいよ本格化した放送と通信の融合について、様々な視点から意見交換をします。

「アンサブル・プラネタ」
http://mixi.jp/view_community.pl?id=41942
美しく伸びやかな声で注目されている女声アカペラグループ「アンサンブル・プラネタ」についてのコミュニティです。

[P2P]ファイル交換ソフトによるインシデント対応：対処編１

先日想定したファイル交換インシデントの対処の方法について考えてみる。今回記述している対策・処置はあくまで一般論であり、組織等によってはもっとベターな方法があるかもしれない。

まず、セキュリティインシデントが起きた場合、どうすれば良いのだろうか？
一般的には初期行動として有効なのは現状把握と担当部署への報告と言われている。

現状把握をするためには、次の部分を考慮する必要がある。
===
１）P2PネットワークにA社が管理している事が特定できるユーザの個人情報がアップロードされているという情報が広報部に複数寄せられた。

２）ある掲示板にP2PネットワークにA社の個人情報がアップロードされている、と書いてあるとの情報が広報部から知らされた。
===

まず掲示板でどのようなことが書いてあるのか、掲示板の検索機能等をもちいて、どの範囲で書かれているのかチェックする必要がある。また、掲示板の表示画面等を証拠として残す事も忘れてはならない。賠償責任等の裁判になった際の証拠や幹部への最終報告への参考資料として必要となるからである。また、掲示板での情報を元に実際にP2Pネットワークに入り、どのような情報がアップされているかチェックする。この情報についても証拠としてログ等を残すことを忘れてはならない。

次に漏洩した情報や掲示板の書き込み内容等の被害の大きさの規模が分かり次第、経営陣（できれば社長）に対して速やかに報告する必要がある。今回の場合には、幸いにも個人を特定するまでの情報は漏れなかったにしろ、A社のデータベースの一部が流出したのは情報から明らかであったことがわかったとしよう。この時点でC部長は社長の名前で把握している被害についてWEBページ等で利用者にお知らせ、陳謝する事が良いとアドバイスすべきだろう。（もちろん、そのページでは原因究明と再発防止に全力を尽くすと書くべきである。）適切かつ迅速な対応が利用者のセキュリティ不安を一掃させ、企業のブランドイメージの低下を最小限に抑えるのである。

関連部署に対しても状況を周知させ、特に広報部及びユーザ対応部署については早急に問い合わせ対応についての想定問答集を作る必要がある。これは社員の個人的な見解により、会社からの回答・コメントがバラバラな方向に行くのを防ぐ目的がある。

初期行動が終わった時点で今度は応急措置と原因について考える必要がある。それについては次回述べてみる。

[P2P]ファイル交換ソフトによるインシデント対応

さて、前回はファイル交換ソフトについても通常のセキュリティポリシを遵守すれば対応できる事を書いた。今回は実際にあり得るケースを設定し、どのようなインシデント対応をすれば良いのか考えてみよう。Blogを見ている方も是非コメントや意見をお伺いしたい。

[想定：インシデントのケースと状況について]
A社は食品加工をメインとしている中堅会社である。A社では自社製品の販路を拡大するためにWEBによる販売を始めた。ユーザはA社の情報部が管理・構築したWEBサーバにアクセスし、クレジットカードや住所、氏名を入力する必要がある。なお、A社がWEBサーバ等の配信システムを構築する上で外部コンサルタントからアドバイスを受けていて、ファイアウォールとIDSを設置している。ただし導入したIDS、ファイアウォールはP2Pソフト通信の検出、遮断はできない。A社は製品の発送をB社に委託しており、個人情報についてはB社の限られた社員のみがアクセスすることができる。なお、A社とB社には秘密保持契約を結んでいるが、それ以外のセキュリティ対策についての契約は結んでいない。

A社では個人情報保護法の注目を受けてセキュリティポリシを作成すべく情報部長のC氏をセキュリティ担当を選び、セキュリティポリシの策定をすることを決定した。また、セキュリティポリシが完成するまではセキュリティインシデント対応についてもC氏が責任を負うこととなっている。なお、C氏はA社経営陣の一人である。

C氏を中心にセキュリティポリシの策定をしてから間もなく、個人情報漏えいのインシデントが発生した。状況は以下の通りである。

１）P2PネットワークにA社が管理している事が特定できるユーザの個人情報がアップロードされているという情報が広報部に複数寄せられた。

２）ある掲示板にP2PネットワークにA社の個人情報がアップロードされている、と書いてあるとの情報が広報部から知らされた。

３）上記P2PネットワークはWというP2Pアプリケーションで構成されており、アップロードをした人は特定が困難であり、P2Pアプリケーションから削除する事も難しいということを既にC氏は知っていた。

４）一報を受けた社長からは緊急対処をする事及び再発防止の対策を早急に報告するように言われている。ただし、再発防止対策は費用対効果を考慮することと言われている。

C氏はこのインシデントに対してどのような対応をすればよいだろうか？初期対応から恒久的な対処まで考えて欲しい。皆様の対応アイデアについてはトラックバックまたはコメントでお待ちしております。

P.S.５万アクセスありがとうございました。

[P2P]P2Pソフトとセキュリティポリシ

P2Pソフトの代表例ファイル交換ソフトで多くのセキュリティ被害が発生している。特にP2Pソフトならではのセキュリティインシデントとして、自分の情報を掲示板やP2Pネットワークにアップロードすることが挙げられる。Winnyではアップロードされた情報が消去できないことから事態を深刻化させている。ファイル交換ユーザはウィルスソフトを利用する事が当たり前のことになっているだろう。もっともウィルスソフトを使用するのはPCユーザとしては当然のことでないといけないのだが。。。

ところで、企業ではセキュリティに対する関心の高さからセキュリティポリシを作成しているところが大分多くなっていると思う。P2Pソフト利用等においてセキュリティポリシは変化するのだろうか？ここではセキュリティポリシでも特に下位レベルのセキュリティスタンダートやプロシージャについて注目してみよう。

１）ソフトウェア利用の許諾
P2Pソフトは何もファイル交換だけでない。IMやSkypeなど有益なソフトも含まれる。このような利用についてはシステム管理者の許諾を必要とすべきである。P2Pソフトの利用をシステム管理者が把握することにより、そのソフトが重大なバクがあったり、不正利用が検知された場合利用者に伝える目的もある。ただし、この条文自体はP2Pソフト以外でも当てはめるべきである。また、現時点で承諾されていないP2Pソフトをやむ得ず使いたい場合には、費用対効果など客観的なデータを出して、管理者に申請する方がよいだろう。（管理者はそのアプリに対するリスクを検討する必要がある。）

２）ウィルス対策ソフトのインストールの義務及びパターンファイルの更新
もはや言う事は無いだろう。P2Pソフトを利用するに関わらず周知・実行を徹底すべき事項である。例えばメールについてウィルスGW（ゲートウェイ）で駆除してもP2PのIMを使ってファイルを交換し、それで感染してしまう可能性がある。ウィルスGWを過信せず、クライアント毎にウィルスソフトをインストールすべきだ。また定期的にパターンファイルのバージョンが最新かチェックする必要がある。

３）アプリケーションソフトのパッチ等適用、バージョンのチェック
古いアプリケーションの場合、重大なセキュリティホールが存在する場合がある。その場合には速やかにパッチを適用すべきである。また定期的に公式ホームページを訪れ最新（安定）バージョンのチェックをし、使用に障害が無ければバージョンの新しいものに更新する。

４）トラフィック、ログの監視
システム・ネットワーク管理者は許諾されていないP2Pアプリケーションの利用によるリスクを抑えるために、トラフィック、プロキシのログを監視し、許諾していないP2Pアプリケーションについてはその利用者に注意喚起、あるいはプロキシ、ファイアウォールなどで通信をブロックする。

５）最新セキュリティ情報の把握
システム・ネットワーク管理者はセキュリティに対する最新情報について収集・分析をする。場合によってはシステムの変更・ユーザへの周知を行う。

６）ユーザへの教育・啓蒙
P2Pソフトを使った場合のリスク・責任について定期的に行う。

７）罰則の規程
これはセキュリティポリシに書く文面であるが、上記に書いたセキュリティスタンダート、セキュリティプロシージャに違反した場合には社内規定により処罰される。

ざっと挙げただけでもこんなものである。ところで、良く見るとこのような文面はP2Pアプリケーションに特化したものでなく、セキュリティポリシとしては一般的なものである。現時点で私が考えてみると、P2Pアプリに特化してセキュリティ事項を文面に書く必要はないと思っているのだが、皆様はどのように考えているだろうか？

逆にセキュリティポリシ等でP2Pアプリについて規定すべきだと考えている方はコメントを頂きたい。

[P2P]分散ハッシュとPGPの親和性

さて、前回はDHTとPKIの関連について書いてみた。せっかくP2Pを考えているのだからCAのようなサーバが必要なシステムはあまり好きでない、という人が多いかもしれないが、P2P勉強会のアリエル岩田氏が説明したように、サーバ＝クライアント型とP2P型モデルはお互い補完しあうべきだと思うし、それを全否定するのは現実的ではないと思う。（もちろん、すべてPure-P2Pで考える事は技術的、研究的には意義があることである。）

PKIでなく、PGPであればサーバレスでDHTと親和性が良いと思う人が多いと思う。確かにそれは否定できない。ただし、DHTを使っても使わなくてもPGPとPKIのメリット・デメリットが残る事は気をつけないといけない。PGPは信頼の環によってお互いを保障しあうわけであり、これによって課金や重要な認証を行うには無理があることは言わざるを得ない。気の知れたコミュニティ内やあまり課金や認証を意識しないシステムであればPGPは非常に有効だ。

ところで、PGPでは自分の公開鍵を登録する登録サーバというのがある。ところが、この公開鍵登録サーバの負荷が重く、レスポンスが悪い事があるらしい。そこで思ったのが、公開鍵の登録についてはDHTによってP2Pネットワークに分散したノードに所有させることである。ノードの参加数が多ければ大量の公開鍵の登録があっても問題ないし、レスポンス・負荷分散も優れている。

もうひとつDHTで面白いことができるとすれば秘密鍵の回復である。秘密鍵が失われた場合、ある手順を踏めば秘密鍵を取り戻せる事である。

以下の手順をすれば安全に秘密鍵を取り戻せるだろう。

１）秘密鍵をs_kyeとする。Rをあるフレーズとする。Rとs_kyeは別々の場所に保存すると仮定する。
（Rは記憶しているとしても良い,長めの覚えやすいフレーズが良いだろう）func()はある整数を返す関数。

２）s_kye_1=s_kye-func(R)とする。s_kye_1を秘密分散法によって、閾値ｙ、x個の情報を生成する。
つまり、info_1,info_2.....info_xがあり、その中をｙ個を集めればs_kye_1は回復できる。

３）infoをDHTを使って分散させたノードに保存する。（Node_ID=func2[R , z],z=1,2,3...x)info_iは自分の秘密鍵で署名してある。

４）秘密鍵を失ったノードはRを使って、まずinfoを持っているノードを探し、その一部の情報を得る。それを基にs_kye_1を計算し、最終的にはs_kyeすなわち秘密鍵を回復する。Rを知らない人はs_kye_1までは得られる可能性はあるが（これもRがわかないので困難だが、ノードの登録情報を全て調べればなんとかなる。ノードがあるオーダー以上になるとこのアタックは非現実的だろう。もちろんfunc2()は注意深く検討する必要がある）、s_kyeまで計算するのは難しいだろう。

こんな感じだろうか。鍵のリカバリーだけでなく鍵の預託も面白い話でこれも秘密分散法を使うテクニックがあるのだが、興味があればDHTと組み合わせて興味深いモデルを考えて欲しい。