OpenPGPを使用したSNSセキュリティ

1,487 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,487
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OpenPGPを使用したSNSセキュリティ

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

×