入門! SSL 〜とりあえずそれっぽい単語たくさん調べてみました〜

Transcript

1. 入門! SSL 〜とりあえずそれっぽい単語たくさん調べてみました〜 @shim0mura
2. Who am I @shim0mura Work at
3. Evil people anywhere
4. webにおける危険性 • 盗聴 • 改ざん • なりすまし
5. SSLというソリューション SSLの提供するセキュリティ機能 • 認証 →サーバー・クライアントの認証でなりすましを防ぐ • 守秘性 →暗号化による情報の漏洩防止 • 完全性 →データが送信されたままの状態であることの担保
6. 超大雑把なSSL説明 • 通信相手が本物か確認する • 通信内容を暗号化 • 通信したデータが正しいか確認する
7. SSLの流れ http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/2.html
8. SSLの流れ ① クライアントがSSLでのアクセスをサーバーに要求 • 通信要求とともにいろいろ送る 利用可能なSSLのバージョン サーバ・クライアントで使える共通鍵暗号の一覧 サーバ・クライアントで使えるハッシュ
9. SSLの流れ ② サーバの電子証明書をクライアントに送信 • 電子証明書は認証局の秘密鍵で暗号化されている • サーバの公開鍵を含む • ルートCAまでの証明書のリスト（証明書チェーン） を含めて送信
10. What the hell?? ？ ？ 電子証明書？ 証明書チェーン？ 秘密鍵？ ？
11. 共通鍵暗号とは 暗号化と復号に同一の鍵を用いる暗号方式 • 鍵さえ手に入れれば誰でも復号化可能 • もし鍵を受け渡す時に盗聴などされていたら… • 鍵の受け渡しをどうするかが問題
12. 公開鍵暗号とは 暗号化と復号に別の鍵を用いる暗号方式 • 共通鍵暗号の鍵の受け渡し危ないよ問題を解決 • 公開鍵と秘密鍵のキーペアを生成 • 公開鍵で暗号文を作成、それを復号出来るのは秘密鍵を持つ選 ばれし者だけ • 公開鍵はその名の通り誰にでも見えるように公開してる • 秘密鍵は受け渡すことが無いのでお漏らしの心配なし 公開鍵暗号を使えばデータが漏れることはない？
13. 第三者機関というソリューション 第三者（Trent）がAliceの公開鍵かどうかを保証する
14. 電子証明書とは 印鑑と印鑑証明のメタファー • 公開鍵が所有者のものであることを第三者が保証 • 第三者機関(CAまたは認証局)が所有者の公開鍵と同 定情報に対し電子署名を行う • CAが署名をするということは公開鍵と同定情報の繋 がり証明される⇨身元の保証！ • フォーマットはX.509という規格に沿ったものが利用 される
15. 電子証明書に含まれるもの • 所有者（先の例だとAlice）の同定情報 • 所有者の公開鍵 （公開鍵のアルゴリズムも含む） • 上記に対する電子署名 電子証明書自体の偽造を見抜くための電子署名
16. 電子署名とは データが本人によって作成されたこと、改ざんされ ていないことを証明するもの ⇨電子署名をつけてその検証がうまくいけば 電子証明書が改ざんされていない事が確認できる • ハッシュ関数を使って送信データからハッシュ値 （メッ セージダイジェスト）を算出する • そのハッシュ値を暗号化 • 送信されたデータを元に受信側がハッシュ値を検証（受信 側でもハッシュ値を再作成など） • 正直自分でもよくわかってません....
17. 電子署名に関するよくある間違い 鍵Aで暗号化した暗号文は鍵Ｂでのみ複号できる ⇨ＡとＢどちらを公開するかが公開鍵暗号方式と 電子署名の違い A君はメッセージダイジェストを自分の秘密鍵で暗号化します。 これが電子署名になります。 A君が電子署名したデータを受け取ったBさんは、A君の公開鍵を 使って暗号化されたメッセージダイジェストの復号化を試みま す｡成功すれば元データの所有者が確かにA君だと分かります｡ https://www.verisign.co.jp/basic/pki/function/index_4.html ではない
18. 電子署名よく分からん • 秘密鍵を暗号化に使えるのはRSAの事 • RSAは公開鍵暗号方式の１つだけど、全ての公開鍵暗 号方式が秘密鍵を暗号化に使えるわけじゃない 参考： http://takagi-hiromitsu.jp/diary/20080229.html http://www.machu.jp/diary/20080302.html • 2008年には問題が指摘されてたのに、未だに誤った情報が...
19. CAの保証は誰がする？ • 電子証明書にはCAが電子署名を施す • そのCAの電子署名をクライアントが検証するにはCA の公開鍵が必要 • CAの公開鍵は本当に偽造されてないの？ • CAを証明するCAが必要！ • CAを証明するCAを証明するCAも必要なんじゃ…？ …
20. CAの階層構造 • 電子証明書の公開鍵自体も上位のCAの電子証明書に よって配布される • その階層構造の頂点に立つのがルートCA • ルートCA以下の証明局が中間CA
21. 証明書チェーンの必要性 • 末端の証明書に問題はない • でもルートCAまでのどこかに問題があれば、 そこより下の証明書の信頼構造は崩れる • 結局末端の証明書も信用できないことに... • クライアントでそこらへん都度確認してもら うために、証明書チェーンを全て送信する • でもなんで中間証明書なんて必要なの… （それもよくわかりません…）
22. SSLの流れ ③ クライアントが証明書から公開鍵取り出し • 認証局にアクセスしてその公開鍵を取得 • 公開鍵を使って証明書チェーンの検証を行う • ルートCAなどの公開鍵はブラウザに元から入ってる • 検証が問題なければ、証明書からサーバの公開鍵を 取り出す ⇨通信相手が正しい事を確認
23. SSLの流れ ④ クライアントがプレマスタシークレットをサーバ に送信 • その通信において使用する一時的な共通鍵が欲しい • プレマスタシークレットと呼ばれるバイト値をクライア ント側で生成 • それを元にサーバ・クライアント双方で共通鍵を生成 (正確にはマスタシークレットから共通鍵生成) • もちろんプレマスタシークレットはサーバの公開鍵で暗 号化してから送信する
24. SSLの流れ ⑤ サーバ側で共通鍵の生成 • ④で送られたプレマスタシークレットを秘密鍵で復号する • プレマスタシークレットからマスタシークレット生成 • マスタシークレットを元にクライアントと同じ共通鍵を作成 • ついでにMAC（メッセージ認証コード）も生成
25. MAC（メッセージ認証コード）とは ハッシュ関数みたいなもの • 共通鍵と元データからMAC値が算出出来る • 送信側は元データとMAC値を送信 • 受信側は元データと共通鍵からMAC値を算出 • 送られて来たMAC値と受信側で生成したMAC値を比較 • 同一であれば元データは改ざんされていない！ ⇨完全性の保証 電子署名は公開鍵、MACは共通鍵と言われるけど...
26. SSLの流れ ⑥ 共通鍵を使って暗号通信の開始 • 公開鍵で共通鍵を送るので配送問題は解決 • 公開鍵よりも処理の軽い共通鍵で一番送りたいデー タを暗号化 ⇨守秘性の保証 • もちろんMAC値を取ることで改ざんされてないことも 確認