Submit Search
OpenPGPを使用したSNSセキュリティ
0 likes
938 views
Hideki Saito
1 of 28
Download now
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
More Related Content
PDF
潜入 Deep Web 犯罪者の思考を探る
Noriaki Hayashi
ODP
安全なデータ公開のために
Tsugio Wakamatsu
PDF
YAPC::Europe 2009 Lisbon Report @ Yapc::Asia Pre-conf Meeting
Yusuke Kawasaki
PDF
Cloud era -『クラウド時代』マッシュアップ技術による地方からの世界発信
Yusuke Kawasaki
PDF
Week 3 - Voortgangspres Sonsbeek 2008
DMEC
PDF
如果您来自企业市场部门
Phil Ren
PDF
MR Weathercaster - The Obaka Appli Championship 3
Yusuke Kawasaki
PPT
Uba development of indigenous cattle thru integrated strategy
Jag Rawat
潜入 Deep Web 犯罪者の思考を探る
Noriaki Hayashi
安全なデータ公開のために
Tsugio Wakamatsu
YAPC::Europe 2009 Lisbon Report @ Yapc::Asia Pre-conf Meeting
Yusuke Kawasaki
Cloud era -『クラウド時代』マッシュアップ技術による地方からの世界発信
Yusuke Kawasaki
Week 3 - Voortgangspres Sonsbeek 2008
DMEC
如果您来自企业市场部门
Phil Ren
MR Weathercaster - The Obaka Appli Championship 3
Yusuke Kawasaki
Uba development of indigenous cattle thru integrated strategy
Jag Rawat
More from Hideki Saito
(6)
PDF
Analyzing NDVI Imagery Using Blender
Hideki Saito
PDF
I did not write “a computerized method for detection of acute cerebral infarc...
Hideki Saito
ODP
Project GData
Hideki Saito
ODP
Transports on XMPP network
Hideki Saito
ODP
Message delivery over XMPP network
Hideki Saito
ODP
Microsoft OOXML / ECMA376 Get The Facts
Hideki Saito
Analyzing NDVI Imagery Using Blender
Hideki Saito
I did not write “a computerized method for detection of acute cerebral infarc...
Hideki Saito
Project GData
Hideki Saito
Transports on XMPP network
Hideki Saito
Message delivery over XMPP network
Hideki Saito
Microsoft OOXML / ECMA376 Get The Facts
Hideki Saito
Ad
OpenPGPを使用したSNSセキュリティ
1.
OpenPGPを使用したSNSセキュリティ
2.
何を実現するためのものか 安全なコミュニケーション(暗号化) 情報秘匿
3.
受信者秘匿
4.
発信事象の秘匿 コミュニケーションの保証(署名) 発信者の担保
5.
連続性の保証 ある時点での情報の保持を内容を秘匿したまま証明。
6.
情報秘匿 所謂普通の暗号化。
7.
情報の中身を秘匿。
8.
受信者秘匿 受信者が誰であるかを秘匿。
9.
日記などに貼り付ける場合、誰に宛てられたのかは第三者が推測できない。
10.
複数のアクセスがある場合、SNSシステム側からでさえ、誰に宛てられたメッセージかを推測するのは困難。
11.
単一のアクセスでもその人が本当に受信者かは推測できない。
12.
発信事象の秘匿 木を隠すなら森の中に
13.
中には意味のない通信が含まれているかもしれない。
14.
(もちろん節度を持って意味のない通信を発生させるべきである。)-スパムはいけない。
15.
発信者の担保 発信された情報が発信者から発せられたものかを判断する材料。
16.
署名。
17.
連続性の担保 発信者の担保を行わない(=信用設定がない鍵を連続で使用する)ことによっては一連の通信が同じ出所であるということを保証できる。
18.
もちろんその鍵が盗まれていない場合のみ・・・・・・なので特殊な事例。
19.
ある時点での情報の保持を内容を秘匿したまま証明 ある秘密の情報を保持しているとする。
20.
自分が現時点でその情報を持っていることを証明したい、でも内容はまだ明かせない。
21.
対称暗号を使用して暗号化、それを配布する。
22.
時が来た時にパスフレーズを公開。
23.
他の人はそのパスフレーズを使用してすでに手に入れているデータを復号化。
24.
動機 SNSシステムはその性質上中心権威型システムである。 従って、ユーザーのプライバシー・データの安全性はSNSの腹づもり次第で変わる。
25.
SNSシステムにとってユーザーは顧客ではなく、顧客(広告主、コンテンツプロバイダー)に対する「商品」である。 ユーザーへの利便性、安全性がSNSシステムにとって優先度は高くないかもしれない。
26.
ただ、SNSは便利なのは確か。 これを解決するべく、分散型のSNSは模索はされているがまだ実用段階ではない。
27.
OpenPGP OpenPGPはPKI(公開鍵基盤)を構成するシステムである。
28.
複数の実装が存在。 PGP (Pretty
Good Privacy)-商用ソフト http://www.pgp.com/ GnuPG (GNU Privacy Guard)-フリーの実装 http://www.gnupg.org/
29.
http://www.gpg4win.org/
30.
OpenPGPとSNSの親和性 OpenPGPはテキストベースで運用できる。
31.
OpenPGPは信用の輪を構築できる。
32.
OpenPGPは他のシステムに比べて要件が緩い。
33.
OpenPGPはテキストベースで運用できる OpenPGPはアスキーアーマーが可能。
34.
既存の日記、ノートシステムで変更なしに運用できる。
35.
コピペでも十分いける。
36.
OpenPGPは信用の輪を構築できる 信用モデルはSNSの友達モデルにオーバーレイする形で構築できる。
37.
SNS内での知り合いはSNS用の公開鍵で、実際に検証済みの人に関しては本運用鍵で署名するといったマルチティアーな運用がシームレスに可能。
38.
既存の信用モデルもそのまま参照できる。
39.
OpenPGPは他のシステムに比べて要件が緩い 柔軟。
40.
認証局不要 。 SNS
の相互認証はアドホックなためこれは重要。
41.
SNSにおけるOpenPGPの重要機能 暗号化機能
42.
署名機能
43.
秘匿受信者機能
44.
暗号化機能 OpenPGPでは強力な暗号が使用可能。
45.
公開鍵暗号方式。 相手の公開鍵に対して暗号化。
46.
パスフレーズの受け渡しはなし。
47.
公開鍵を交換するだけ。 対称暗号 共通のパスフレーズを使用。
48.
署名機能 通信の内容を発信者の公開鍵を使用して担保。
49.
署名だけすることもできる。通常の署名の場合、読むのにOpenPGPシステムが必要。(ただしパスフレーズ等の入力は必要なし。) クリア署名-OpenPGPをシステムなしでも内容を読むことが可能。 暗号化と組み合わせることができる。
50.
秘匿受信者機能 受信者を秘匿できる。
51.
暗号の対称のユーザーになっているかがわかるのは発信者と、対応する受信者のみ。 受信者でさえ復号に成功するまで自分が対象になっているかわからない。 メッセージは全てKey
ID 0x00000000に宛てられたものとなる。 これを理解するシステムは保持する全ての鍵で試行する。 作成にはGnuPGが必要。復号はPGP 10以降でも可能。
52.
SNSでの応用 発信者はAliceとする。
53.
受信者はBobとCharlesとする。
54.
「流し台」(Sink1 ~ Sink
n)は公開鍵ペアを作成した後、その秘密鍵を消去した状態のユーザー。 発信者が作成。
55.
秘密鍵が削除されているため、暗号化したものを解読できる人はいない。
56.
つまり流し台。 Davidは第三者。(通信に参加しない)
57.
全員Alice、Bob、Charlesの公開鍵を保持
58.
普通の通信の場合 Aliceは暗号化したデータをBobに送信 Bobはそれを復号。
メッセージ自体はAliceが自分の日記などに貼り付けたと仮定。 Bobの公開鍵を持つものはAliceがBobに対してメッセージを送ったのがわかる。 Alice -> Bob
59.
秘匿受信者機能の通信の場合 Aliceは暗号化したデータをBobに送信 Bobはそれを復号。
Davidから見るとAliceが誰に宛てているのかはわからない。 Bobも復号化を試してみて成功して初めて自分宛であるとわかる。 ???
60.
複数人への秘匿通信の場合 複数人への秘匿通信も可能。 この場合Davidがわかるのはメッセージが誰か二人に宛てられているという事実。
Charles、Bobそれぞれは自分に宛てられたという事実の他、誰かもう一人に宛てられている、という事実。 2人宛て
61.
秘匿通信を使用しても解決しない問題が・・・・・・ 通信の人数によってその通信の性質が推測されてしまう可能性がある。
62.
受信者はその通信が自分のみに宛てられたのか、それとも同報で他にも宛てられているのかがわかる。 場合によっては同報に宛てられていることを悪用して通信内容を漏洩する可能性も?
63.
そこで登場するSink(流し台) Sinkで受信者数を水増しする。 Sink
+ メッセージ受信者の数を常に同じに近づける。 各受信者は何人への同報かはわからない。
64.
受信者は当該の通信が同報ではないのでないかという疑いを持つ。 それが同報でない場合、漏洩者が判明する。 時にはSinkのみに通信を流すことにより、「空トラフィック」を作成。
第三者による経路分析を遮断。
65.
Sinkを介入させた通信1 Bob、Charlesは自分以外に4人に宛てられていることを認識。 5人
66.
Sinkを介入させた通信2 Bobは自分の他に4人に宛てられていることを認識。 5人
67.
Sinkを介入させた通信3 この場合、メッセージは実質的に破棄。(全員がSinkなので誰も読めない。) Davidから見た人数が全て同じ5人なのに注意。
5人
68.
現状解決できていない問題 メッセージ自体の秘匿。 ステガノグラフィー
69.
SNSシステム、第三者にメッセージ自体が存在することを悟られないようにする。
70.
行間やスペーシングによるエンコード?
Download