Transcript 電子投票の定義
ユーザ間通信における Entityの匿名について ねこ 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) APOP: Challenge & Response ユーザが登録した パスワード 乱数を発生 ① challenge(乱数） クライアント サーバ 結果 ②暗号化 ③ response 結果 ユーザが登録した パスワード 結果 サーバ側から送ってきた「Challenge」と内部 に保管したパスワードから「Reponse」を生成 ④サーバが暗号化した ものと照合 +OK QPOP (version 2.53-APOP-SFC) at mail starting. <13860.1010186867@mail> USER taro チャレンジ文字列 +OK Password required for taro APOP taro 577b4d0f677850ef61fdcd981779294f +OK taro has XXX messages (YYY octets) レスポンス文字列 事例[2]：電子投票を実現するためには 有権者であることを確認 ひとり一票 匿名性の確保 送信者を特定できない 電子投票の流れ 投票者は投票内容を作成する 投票者は投票内容に対して、選挙管理委員会 からブラインド署名による署名を受け取る 投票者は匿名通信路を用いて投票を行う 集計者は選挙管理委員の署名を確認し た上で、集計を行う 電子投票に用いられる技術 ブラインド署名 投票内容を見る事なく有権者確認を行う 匿名通信路 送信者を特定できないネットワーク ブラインド署名 署名者に文書内容を知られずに署名を受ける 投票者 X 乱数R Z 選挙管理委員会 署名付 X 署名付 乱数R Mは、Xを直接署名してもらった 場合と同じものになる。 Z 中身の分からないZに対して 署名をして返す。 これによって、投票者は投票内容を知られる事なく、 選挙管理委員会に正当な投票用紙であることを 認めてもらうことができる。 匿名通信路 受信者はどの送信者から受け取ったのか把握で きない これによって、投票者は誰に投票したかを知られることなく 投票を行うことができる。 →投票箱をかき混ぜるようなイメージ 事例[3]：ファイル共有における匿名性 目的 自分のファイルを他の人に配りたい！ 誰がファイルを公開したのか知られたくない！ ポエムを公開 したいけど、 ちょっと恥ずか しい…… 中継とキャッシュ 他の人に配るのを手伝ってもらおう！ 転送するときに、他の人に中継してもらう。 中継してくれた人にも配ってもらう。 副次的なメリットも！ 公開する人が増えるのでボトルネックが無くなる。 余談：Winny利用者から逮捕 情報が錯綜してますが…… Winnyでは、匿名性より効率を重視してます。 中継は0回～1回がほとんど 利用者の視点ではそれなりの匿名性 真面目にやれば送信者を特定するのは困難じゃない キャッシュの管理責任は？ 自分で落としたファイルは公衆送信状態になる。 キャッシュの中身は調べれば分かる。 ちなみに、BBSの匿名性はほとんどありません。 書き込む人からスレ主、スレ主から書き込んだ人をほ ぼ確実に特定できます。 まぁ、割と捕まってもおかしくない状態です。 事例[4]：cookie HTTP Cookieの恐怖 個人の行動履歴を把握できる。 他の認証手段とあわさることで、その人の行動が 全て筒抜けになってしまう。 一例：SFC Antenna 2000年秋学期PIE KG発表資料より抜粋 参考：当時はksteというツールがあった。 閲覧するだけで、それが誰のアクセスか分かった。 今は共有ホストを皆使わないのでデータ取れません。 http://sfcantenna.net/ パーソナライズ機能 cookieを利用して、表示対象を限定 アンテナが知ることのできる情報(1) 誰がどの日記をいつ読んだか 以下は村井研OB、Cさんの例 1600 1400 1344 1200 1000 930 883 800 737 600 400 531 384 283 225 109 200 0 1 330 283 226 664 616 522 117 2 699 775 826 252 361 255 184 185 131 90 70 3 4 読まれた回数 5 6 読んだ回数 7 アクセス 8 9 アンテナが知ることのできる情報(2) 時系列による変化とかも分かっちゃう 企画「連日記」の参加者同士の、日記の閲覧回数 「人間関係」が数字として見える！ 読む人 大黒武寿 折田明子 上野陽子 天野恵 青柳直樹 津川洋一 神谷慶 工藤雄玄 田中大訓 徳久真也 吉村知夏 江木啓訓 読まれる日記 大黒武寿 折田明子 上野陽子 天野恵 青柳直樹 津川洋一 神谷慶 工藤雄玄 田中大訓 徳久真也 吉村知夏 江木啓訓 -4 0 -2 1 31 4 0 7 -4 -2 13 1 45 0 0 0 0 1 0 0 1 0 0 0 0 2 0 0 2 -4 26 1 -1 6 -2 -5 18 3 44 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 15 17 26 -1 0 -1 2 0 -1 3 68 -1 0 1 0 1 1 -1 -2 4 0 -5 0 -2 -2 0 -5 0 3 0 1 -6 0 0 1 1 -7 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 -1 0 -1 -1 0 -6 0 -2 -1 -12 0 0 1 -1 0 0 0 0 0 0 0 0 0 13 0 11 0 5 1 0 12 6 2 9 0 59 1 0 0 0 1 0 0 0 0 1 3 0 6 16 0 23 12 94 5 -2 17 0 -4 36 7 204 行動履歴を渡すことによるメリット 「おすすめ」 似た購入傾向 をもつ商品を 一覧表示 購入商品に 関連する情報 を提示 同ジャンルの 新作の紹介 事例[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