openpgpを使用したsnsセキュリティ
TRANSCRIPT
OpenPGPを使用した SNSセキュリティ
何を実現するためのものか
安全なコミュニケーション（暗号化）
情報秘匿
受信者秘匿
発信事象の秘匿
コミュニケーションの保証（署名）
発信者の担保
連続性の保証
ある時点での情報の保持を内容を秘匿したまま証明。
情報秘匿
所謂普通の暗号化。
情報の中身を秘匿。
受信者秘匿
受信者が誰であるかを秘匿。
日記などに貼り付ける場合、誰に宛てられたのかは第三者が推測できない。
複数のアクセスがある場合、 SNSシステム側からでさえ、誰に宛てられたメッセージかを推測するのは困難。
単一のアクセスでもその人が本当に受信者かは推測できない。
発信事象の秘匿
木を隠すなら森の中に
中には意味のない通信が含まれているかもしれない。
（もちろん節度を持って意味のない通信を発生させるべきである。）－スパムはいけない。
発信者の担保
発信された情報が発信者から発せられたものかを判断する材料。
署名。
連続性の担保
発信者の担保を行わない（＝信用設定がない鍵を連続で使用する）ことによっては一連の通信が同じ出所であるということを保証できる。
もちろんその鍵が盗まれていない場合のみ･･････なので特殊な事例。
ある時点での情報の保持を内容を秘匿したまま証明
ある秘密の情報を保持しているとする。
自分が現時点でその情報を持っていることを証明したい、でも内容はまだ明かせない。
対称暗号を使用して暗号化、それを配布する。
時が来た時にパスフレーズを公開。
他の人はそのパスフレーズを使用してすでに手に入れているデータを復号化。
動機
SNSシステムはその性質上中心権威型システムである。
従って、ユーザーのプライバシー・データの安全性はSNSの腹づもり次第で変わる。
SNSシステムにとってユーザーは顧客ではなく、顧客（広告主、コンテンツプロバイダー）に対する「商品」である。
ユーザーへの利便性、安全性が SNSシステムにとって優先度は高くないかもしれない。
ただ、 SNSは便利なのは確か。
これを解決するべく、分散型の SNSは模索はされているがまだ実用段階ではない。
OpenPGP
OpenPGPは PKI（公開鍵基盤）を構成するシステムである。
複数の実装が存在。
PGP (Pretty Good Privacy)－商用ソフトhttp://www.pgp.com/
GnuPG (GNU Privacy Guard)－フリーの実装http://www.gnupg.org/
http://www.gpg4win.org/
OpenPGPと SNSの親和性
OpenPGPはテキストベースで運用できる。
OpenPGPは信用の輪を構築できる。
OpenPGPは他のシステムに比べて要件が緩い。
OpenPGPはテキストベースで運用できる
OpenPGPはアスキーアーマーが可能。
既存の日記、ノートシステムで変更なしに運用できる。
コピペでも十分いける。
OpenPGPは信用の輪を構築できる
信用モデルは SNSの友達モデルにオーバーレイする形で構築できる。
SNS内での知り合いは SNS用の公開鍵で、実際に検証済みの人に関しては本運用鍵で署名するといったマルチティアーな運用がシームレスに可能。
既存の信用モデルもそのまま参照できる。
OpenPGPは他のシステムに比べて要件が緩い
柔軟。
認証局不要。 SNSの相互認証はアドホックなためこれは重要。
SNSにおけるOpenPGPの重要機能
暗号化機能
署名機能
秘匿受信者機能
暗号化機能
OpenPGPでは強力な暗号が使用可能。
公開鍵暗号方式。
相手の公開鍵に対して暗号化。
パスフレーズの受け渡しはなし。
公開鍵を交換するだけ。
対称暗号
共通のパスフレーズを使用。
署名機能
通信の内容を発信者の公開鍵を使用して担保。
署名だけすることもできる。通常の署名の場合、読むのにOpenPGPシステムが必要。（ただしパスフレーズ等の入力は必要なし。）
クリア署名－OpenPGPをシステムなしでも内容を読むことが可能。
暗号化と組み合わせることができる。
秘匿受信者機能
受信者を秘匿できる。
暗号の対称のユーザーになっているかがわかるのは発信者と、対応する受信者のみ。
受信者でさえ復号に成功するまで自分が対象になっているかわからない。
メッセージは全て Key ID 0x00000000に宛てられたものとなる。
これを理解するシステムは保持する全ての鍵で試行する。
作成にはGnuPGが必要。復号は PGP 10以降でも可能。
SNSでの応用
発信者は Aliceとする。
受信者は BobとCharlesとする。
「流し台」（ Sink1 ~ Sink n）は公開鍵ペアを作成した後、その秘密鍵を消去した状態のユーザー。
発信者が作成。
秘密鍵が削除されているため、暗号化したものを解読できる人はいない。
つまり流し台。
Davidは第三者。（通信に参加しない）
全員 Alice、 Bob、Charlesの公開鍵を保持
普通の通信の場合
Alice Bob
Aliceは暗号化したデータを Bobに送信Bobはそれを復号。
メッセージ自体は Aliceが自分の日記などに貼り付けたと仮定。
Bobの公開鍵を持つものは Aliceが Bobに対してメッセージを送ったのがわかる。
David
Alice → Bob
秘匿受信者機能の通信の場合
Alice Bob
Aliceは暗号化したデータを Bobに送信Bobはそれを復号。
Davidから見ると Aliceが誰に宛てているのかはわからない。
Bobも復号化を試してみて成功して初めて自分宛であるとわかる。
David
???
複数人への秘匿通信の場合
Alice Bob
複数人への秘匿通信も可能。
この場合Davidがわかるのはメッセージが誰か二人に宛てられているという事実。
Charles、 Bobそれぞれは自分に宛てられたという事実の他、誰かもう一人に宛てられている、という事実。
David
2人宛て
Charles
秘匿通信を使用しても解決しない問題が･･････
通信の人数によってその通信の性質が推測されてしまう可能性がある。
受信者はその通信が自分のみに宛てられたのか、それとも同報で他にも宛てられているのかがわかる。
場合によっては同報に宛てられていることを悪用して通信内容を漏洩する可能性も？
そこで登場する Sink（流し台）
Sinkで受信者数を水増しする。
Sink + メッセージ受信者の数を常に同じに近づける。
各受信者は何人への同報かはわからない。
受信者は当該の通信が同報ではないのでないかという疑いを持つ。
それが同報でない場合、漏洩者が判明する。
時には Sinkのみに通信を流すことにより、「空トラフィック」を作成。
第三者による経路分析を遮断。
Sinkを介入させた通信１
Alice
Sink 1 Sink 2 Sink 3
Bob Charles
David
５人Bob、Charlesは自分以外に４人に宛てられていることを認識。
Sinkを介入させた通信２
Alice
Sink 1 Sink 2 Sink 3
Bob Sink 4
David
５人Bobは自分の他に４人に宛てられていることを認識。
Sinkを介入させた通信３
Alice
Sink 1 Sink 2 Sink 3
Sink 5 Sink 4
David
５人この場合、メッセージは実質的に破棄。（全員が Sinkなので誰も読めない。）
Davidから見た人数が全て同じ５人なのに注意。
現状解決できていない問題
メッセージ自体の秘匿。
ステガノグラフィー
SNSシステム、第三者にメッセージ自体が存在することを悟られないようにする。
行間やスペーシングによるエンコード？