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

Who am I @shim0mura Work at

Evil people anywhere

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

SSLというソリューション SSLの提供するセキュリティ機能 ● 認証 →サーバー・クライアントの認証でなりすましを防ぐ ● 守秘性 →暗号化による情報の漏洩防止 ● 完全性 →データが送信されたままの状態であることの担保

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

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

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

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

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

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

公開鍵暗号とは 暗号化と復号に別の鍵を用いる暗号方式 ● 共通鍵暗号の鍵の受け渡し危ないよ問題を解決 ● 公開鍵と秘密鍵のキーペアを生成 ● 公開鍵で暗号文を作成、それを復号出来るのは秘密鍵を持つ選 ばれし者だけ ● 公開鍵はその名の通り誰にでも見えるように公開してる ● 秘密鍵は受け渡すことが無いのでお漏らしの心配なし 公開鍵暗号を使えばデータが漏れることはない？

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

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

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

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

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

電子署名よく分からん ● 秘密鍵を暗号化に使えるのはRSAの事 ● RSAは公開鍵暗号方式の１つだけど、全ての公開鍵暗 号方式が秘密鍵を暗号化に使えるわけじゃない 参考： http://takagi-hiromitsu.jp/diary/20080229.html http://www.machu.jp/diary/20080302.html ● 2008年には問題が指摘されてたのに、未だに誤った情報が...

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

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

証明書チェーンの必要性 ● 末端の証明書に問題はない ● でもルートCAまでのどこかに問題があれば、 そこより下の証明書の信頼構造は崩れる ● 結局末端の証明書も信用できないことに... ● クライアントでそこらへん都度確認してもら うために、証明書チェーンを全て送信する ● でもなんで中間証明書なんて必要なの… （それもよくわかりません…）

SSLの流れ ③ クライアントが証明書から公開鍵取り出し ● 認証局にアクセスしてその公開鍵を取得 ● 公開鍵を使って証明書チェーンの検証を行う ● ルートCAなどの公開鍵はブラウザに元から入ってる ● 検証が問題なければ、証明書からサーバの公開鍵を 取り出す ⇨通信相手が正しい事を確認

SSLの流れ ④ クライアントがプレマスタシークレットをサーバ に送信 ● その通信において使用する一時的な共通鍵が欲しい ● プレマスタシークレットと呼ばれるバイト値をクライア ント側で生成 ● それを元にサーバ・クライアント双方で共通鍵を生成 (正確にはマスタシークレットから共通鍵生成) ● もちろんプレマスタシークレットはサーバの公開鍵で暗 号化してから送信する

SSLの流れ ⑤ サーバ側で共通鍵の生成 ● ④で送られたプレマスタシークレットを秘密鍵で復号する ● プレマスタシークレットからマスタシークレット生成 ● マスタシークレットを元にクライアントと同じ共通鍵を作成 ● ついでにMAC（メッセージ認証コード）も生成

MAC（メッセージ認証コード）とは ハッシュ関数みたいなもの ● 共通鍵と元データからMAC値が算出出来る ● 送信側は元データとMAC値を送信 ● 受信側は元データと共通鍵からMAC値を算出 ● 送られて来たMAC値と受信側で生成したMAC値を比較 ● 同一であれば元データは改ざんされていない！ ⇨完全性の保証 電子署名は公開鍵、MACは共通鍵と言われるけど...

SSLの流れ ⑥ 共通鍵を使って暗号通信の開始 ● 公開鍵で共通鍵を送るので配送問題は解決 ● 公開鍵よりも処理の軽い共通鍵で一番送りたいデー タを暗号化 ⇨守秘性の保証 ● もちろんMAC値を取ることで改ざんされてないことも 確認