300 likes | 574 Views
ユーザ間通信における Entity の匿名について. ねこ. Entity とは何か. 「誰」が通信しているか。 通信の主体。. Entity. Entity. Entity. Entity. Entity. Entity. Entity. Entity を特定されたくない状況って?. 誰だか知られずに行動したい 匿名投書 投票 密告 お買い物. Entity を特定する情報. 例えば匿名投書、・・・名前、住所 例えば TCP/IP による通信、・・・ IP アドレス ネットワーク上で匿名性が必要な通信をするには工夫が必要!. こういうの.
E N D
Entityとは何か 「誰」が通信しているか。通信の主体。 Entity Entity Entity Entity Entity Entity Entity
Entityを特定されたくない状況って? • 誰だか知られずに行動したい • 匿名投書 • 投票 • 密告 • お買い物
Entityを特定する情報 • 例えば匿名投書、・・・名前、住所 • 例えばTCP/IPによる通信、・・・IPアドレス • ネットワーク上で匿名性が必要な通信をするには工夫が必要!
こういうの 事例[1] : 2ch の ID の仕組み • 匿名性は確保したいが自作自演は抑止したい • 投稿者に無意味で一意なIDを発行 • 日付が変わるとIDが変わる • (IPアドレスと日付をハッシュ関数にいれる)
ハッシュ関数 ハッシュ値 逆算不可能 ハッシュ関数 • 一方向関数 ともよばれることも (MD5, SHA-1等) • X=hash(A) • パスワードの保存等、様々な場面で利用される • パスワードの保存(/etc/shadow) • ファイルの改ざんのチェック、 • チャレンジ&レスポンス(APOP)
+OK QPOP (version 2.53-APOP-SFC) at mail starting. <13860.1010186867@mail> USERtaro +OK Password required for taro APOP taro577b4d0f677850ef61fdcd981779294f +OK taro has XXX messages (YYY octets) チャレンジ文字列 レスポンス文字列 APOP: Challenge & Response ユーザが登録した パスワード 乱数を発生 ① challenge(乱数) クライアント サーバ 結果 ユーザが登録した パスワード ③ response ②暗号化 結果 結果 • サーバ側から送ってきた「Challenge」と内部に保管したパスワードから「Reponse」を生成 ④サーバが暗号化した ものと照合
事例[2]:電子投票を実現するためには • 有権者であることを確認 • ひとり一票 • 匿名性の確保 • 送信者を特定できない
電子投票の流れ 投票者は投票内容を作成する 投票者は投票内容に対して、選挙管理委員会からブラインド署名による署名を受け取る 投票者は匿名通信路を用いて投票を行う 集計者は選挙管理委員の署名を確認した上で、集計を行う
電子投票に用いられる技術 • ブラインド署名 投票内容を見る事なく有権者確認を行う • 匿名通信路 送信者を特定できないネットワーク
ブラインド署名 署名者に文書内容を知られずに署名を受ける 投票者 X Z 乱数R 選挙管理委員会 署名付 署名付 中身の分からないZに対して 署名をして返す。 X Z 乱数R Mは、Xを直接署名してもらった 場合と同じものになる。 これによって、投票者は投票内容を知られる事なく、 選挙管理委員会に正当な投票用紙であることを 認めてもらうことができる。
匿名通信路 受信者はどの送信者から受け取ったのか把握できない これによって、投票者は誰に投票したかを知られることなく 投票を行うことができる。 →投票箱をかき混ぜるようなイメージ
事例[3]:ファイル共有における匿名性 • 目的 • 自分のファイルを他の人に配りたい! • 誰がファイルを公開したのか知られたくない! ポエムを公開したいけど、ちょっと恥ずかしい……
中継とキャッシュ • 他の人に配るのを手伝ってもらおう! • 転送するときに、他の人に中継してもらう。 • 中継してくれた人にも配ってもらう。 • 副次的なメリットも! • 公開する人が増えるのでボトルネックが無くなる。
余談:Winny利用者から逮捕 • 情報が錯綜してますが…… • Winnyでは、匿名性より効率を重視してます。 • 中継は0回~1回がほとんど • 利用者の視点ではそれなりの匿名性 • 真面目にやれば送信者を特定するのは困難じゃない • キャッシュの管理責任は? • 自分で落としたファイルは公衆送信状態になる。 • キャッシュの中身は調べれば分かる。 • ちなみに、BBSの匿名性はほとんどありません。 • 書き込む人からスレ主、スレ主から書き込んだ人をほぼ確実に特定できます。 • まぁ、割と捕まってもおかしくない状態です。
事例[4]:cookie • HTTP Cookieの恐怖 • 個人の行動履歴を把握できる。 • 他の認証手段とあわさることで、その人の行動が全て筒抜けになってしまう。 • 一例:SFC Antenna • 2000年秋学期PIE KG発表資料より抜粋 • 参考:当時はksteというツールがあった。 • 閲覧するだけで、それが誰のアクセスか分かった。 • 今は共有ホストを皆使わないのでデータ取れません。 • http://sfcantenna.net/
パーソナライズ機能 • cookieを利用して、表示対象を限定
アンテナが知ることのできる情報(1) • 誰がどの日記をいつ読んだか • 以下は村井研OB、Cさんの例
アンテナが知ることのできる情報(2) • 時系列による変化とかも分かっちゃう • 企画「連日記」の参加者同士の、日記の閲覧回数 • 「人間関係」が数字として見える!
行動履歴を渡すことによるメリット • 「おすすめ」 • 似た購入傾向をもつ商品を一覧表示 • 購入商品に関連する情報を提示 • 同ジャンルの新作の紹介
事例[5]:第三者への意図しない流出 • 適切に使われる分には構わないんだけど… • 自分の情報が知らない人に漏れるのは嫌! • 最近の事例:丸紅ダイレクト • 例の19,800円VALUESTAR祭り • 丸紅に登録したメールアドレスに対して、第三者である人材派遣会社のサーバからメール発送 • 丸紅以外に情報が行くなんて聞いてないよ? プライバシーポリシーの適切な設定と告知 実はここまでは個人情報保護法で規定されてます。でも……
P3P Platform for Privacy Preferences • 「個人情報の扱い」への質問集の標準化 • あらかじめ「閲覧者が希望する扱い方」を設定 • サーバがP3Pによって保護ポリシーを提示 • ポリシーが適合するかブラウザが自動で判断 • cookieの受け入れ条件として既に実装済み • Microsoft IE6 • Netscape 7.0 / Mozilla • 名前や住所の面倒いフォームにも応用できると良いのにね……。
P3Pポリシー例 bidders.co.jp • HTTPヘッダで場所を告知 • 使用目的毎に、その情報を必要とする状況を記述 • 実は全部always • あくまで枠組みにしか過ぎない。
WebMoneyの例 • 通販サイトなんて信じられない。 • 通販サイトには支払い情報は残したくない。 • 支払い情報は、必要なサーバに直接送ろう! 通販サイトのサーバ www.webmoney.ne.jp 通販サイト 支払い情報
公開鍵暗号を使えば… • 秘密の文書を送るのも簡単 誰に知られてもいいものだから、受け渡しも楽ちん ①受取人の公開鍵を渡す ④受取人の秘密鍵でしか元に戻せない! ②受取人の公開鍵で暗号化 公開鍵 秘密鍵 何じゃこりゃ 差出人 受取人 ③いまいち信頼できないI君が運ぶ
オニオンルーティング • Anonymous Proxyの一種。アプリ層の匿名サービス。 • 送信ノードのオニオンルータが経路作成。Onion Proxy機能と呼ぶ。 • 経路はProxyの公開鍵で多重に暗号化 受信者 オニオン ルート Onion Router Onion Router Onion Router Onion Router Onion Router Onion Router