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

Transcript

1. 1.

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

2. 2.

   Who am I @shim0mura Work at

3. 3.

   Evil people anywhere

4. 4.

   webにおける危険性 • 盗聴 • 改ざん • なりすまし

5. 5.

   SSLというソリューション SSLの提供するセキュリティ機能 • 認証 →サーバー・クライアントの認証でなりすましを防ぐ • 守秘性 →暗号化による情報の漏洩防止 • 完全性

   →データが送信されたままの状態であることの担保
6. 6.

   超大雑把なSSL説明 • 通信相手が本物か確認する • 通信内容を暗号化 • 通信したデータが正しいか確認する

7. 7.

   SSLの流れ http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/2.html

8. 8.

   SSLの流れ ① クライアントがSSLでのアクセスをサーバーに要求 • 通信要求とともにいろいろ送る 利用可能なSSLのバージョン サーバ・クライアントで使える共通鍵暗号の一覧 サーバ・クライアントで使えるハッシュ

9. 9.

   SSLの流れ ② サーバの電子証明書をクライアントに送信 • 電子証明書は認証局の秘密鍵で暗号化されている • サーバの公開鍵を含む • ルートCAまでの証明書のリスト（証明書チェーン） を含めて送信

10. 10.

    What the hell?? ？ ？ 電子証明書？ 証明書チェーン？ 秘密鍵？ ？

11. 11.

    共通鍵暗号とは 暗号化と復号に同一の鍵を用いる暗号方式 • 鍵さえ手に入れれば誰でも復号化可能 • もし鍵を受け渡す時に盗聴などされていたら… • 鍵の受け渡しをどうするかが問題

12. 12.

    公開鍵暗号とは 暗号化と復号に別の鍵を用いる暗号方式 • 共通鍵暗号の鍵の受け渡し危ないよ問題を解決 • 公開鍵と秘密鍵のキーペアを生成 • 公開鍵で暗号文を作成、それを復号出来るのは秘密鍵を持つ選 ばれし者だけ •

    公開鍵はその名の通り誰にでも見えるように公開してる • 秘密鍵は受け渡すことが無いのでお漏らしの心配なし 公開鍵暗号を使えばデータが漏れることはない？
13. 13.

    第三者機関というソリューション 第三者（Trent）がAliceの公開鍵かどうかを保証する

14. 14.

    電子証明書とは 印鑑と印鑑証明のメタファー • 公開鍵が所有者のものであることを第三者が保証 • 第三者機関(CAまたは認証局)が所有者の公開鍵と同 定情報に対し電子署名を行う • CAが署名をするということは公開鍵と同定情報の繋 がり証明される⇨身元の保証！

    • フォーマットはX.509という規格に沿ったものが利用 される
15. 15.

    電子証明書に含まれるもの • 所有者（先の例だとAlice）の同定情報 • 所有者の公開鍵 （公開鍵のアルゴリズムも含む） • 上記に対する電子署名 電子証明書自体の偽造を見抜くための電子署名

16. 16.

    電子署名とは データが本人によって作成されたこと、改ざんされ ていないことを証明するもの ⇨電子署名をつけてその検証がうまくいけば 電子証明書が改ざんされていない事が確認できる • ハッシュ関数を使って送信データからハッシュ値 （メッ セージダイジェスト）を算出する •

    そのハッシュ値を暗号化 • 送信されたデータを元に受信側がハッシュ値を検証（受信 側でもハッシュ値を再作成など） • 正直自分でもよくわかってません....
17. 17.

    電子署名に関するよくある間違い 鍵Aで暗号化した暗号文は鍵Ｂでのみ複号できる ⇨ＡとＢどちらを公開するかが公開鍵暗号方式と 電子署名の違い A君はメッセージダイジェストを自分の秘密鍵で暗号化します。 これが電子署名になります。 A君が電子署名したデータを受け取ったBさんは、A君の公開鍵を 使って暗号化されたメッセージダイジェストの復号化を試みま す｡成功すれば元データの所有者が確かにA君だと分かります｡ https://www.verisign.co.jp/basic/pki/function/index_4.html

    ではない
18. 18.

    電子署名よく分からん • 秘密鍵を暗号化に使えるのはRSAの事 • RSAは公開鍵暗号方式の１つだけど、全ての公開鍵暗 号方式が秘密鍵を暗号化に使えるわけじゃない 参考： http://takagi-hiromitsu.jp/diary/20080229.html http://www.machu.jp/diary/20080302.html •

    2008年には問題が指摘されてたのに、未だに誤った情報が...
19. 19.

    CAの保証は誰がする？ • 電子証明書にはCAが電子署名を施す • そのCAの電子署名をクライアントが検証するにはCA の公開鍵が必要 • CAの公開鍵は本当に偽造されてないの？ • CAを証明するCAが必要！

    • CAを証明するCAを証明するCAも必要なんじゃ…？ …
20. 20.

    CAの階層構造 • 電子証明書の公開鍵自体も上位のCAの電子証明書に よって配布される • その階層構造の頂点に立つのがルートCA • ルートCA以下の証明局が中間CA

21. 21.

    証明書チェーンの必要性 • 末端の証明書に問題はない • でもルートCAまでのどこかに問題があれば、 そこより下の証明書の信頼構造は崩れる • 結局末端の証明書も信用できないことに... • クライアントでそこらへん都度確認してもら

    うために、証明書チェーンを全て送信する • でもなんで中間証明書なんて必要なの… （それもよくわかりません…）
22. 22.

    SSLの流れ ③ クライアントが証明書から公開鍵取り出し • 認証局にアクセスしてその公開鍵を取得 • 公開鍵を使って証明書チェーンの検証を行う • ルートCAなどの公開鍵はブラウザに元から入ってる •

    検証が問題なければ、証明書からサーバの公開鍵を 取り出す ⇨通信相手が正しい事を確認
23. 23.

    SSLの流れ ④ クライアントがプレマスタシークレットをサーバ に送信 • その通信において使用する一時的な共通鍵が欲しい • プレマスタシークレットと呼ばれるバイト値をクライア ント側で生成 •

    それを元にサーバ・クライアント双方で共通鍵を生成 (正確にはマスタシークレットから共通鍵生成) • もちろんプレマスタシークレットはサーバの公開鍵で暗 号化してから送信する
24. 24.

    SSLの流れ ⑤ サーバ側で共通鍵の生成 • ④で送られたプレマスタシークレットを秘密鍵で復号する • プレマスタシークレットからマスタシークレット生成 • マスタシークレットを元にクライアントと同じ共通鍵を作成 •

    ついでにMAC（メッセージ認証コード）も生成
25. 25.

    MAC（メッセージ認証コード）とは ハッシュ関数みたいなもの • 共通鍵と元データからMAC値が算出出来る • 送信側は元データとMAC値を送信 • 受信側は元データと共通鍵からMAC値を算出 • 送られて来たMAC値と受信側で生成したMAC値を比較

    • 同一であれば元データは改ざんされていない！ ⇨完全性の保証 電子署名は公開鍵、MACは共通鍵と言われるけど...
26. 26.

    SSLの流れ ⑥ 共通鍵を使って暗号通信の開始 • 公開鍵で共通鍵を送るので配送問題は解決 • 公開鍵よりも処理の軽い共通鍵で一番送りたいデー タを暗号化 ⇨守秘性の保証 •

    もちろんMAC値を取ることで改ざんされてないことも 確認