以前書いた無線LANのセキュリティの記事で「SSLについて書きます」と宣言したので、今回はSSLの仕組みと、「EV SSL証明書」についてできるだけ分かりやすく解説してみます。
その前に前提知識について解説
SSLの説明をする前に、いくつか押さえておかないといけない知識があるので、まずそれらを説明したいと思います。
共通鍵暗号方式
これは直感的に分かると思いますが、事前にお互いが同じ鍵を用意しておいて、通信の際はその鍵を使って暗号化・復号化する方式です。特に説明の必要は無いでしょう。
公開鍵暗号方式
こちらは説明が必要ですね。
ある数学的なルールに従って、1ペアの鍵を生成します。これらを鍵1、鍵2としますと、以下が成り立つような仕組みになっています。（理論はとても難しいので省きます）
ある数学的なルールに従って、1ペアの鍵を生成します。これらを鍵1、鍵2としますと、以下が成り立つような仕組みになっています。（理論はとても難しいので省きます）
- 鍵1で暗号化した物は鍵2でしか復号化できない
- 鍵2で暗号化した物は鍵1でしか復号化できない
そこで、片方を公開鍵、もう片方を秘密鍵とします。公開鍵はその名の通り、公開してかまわない鍵です。
通信する際には、まず送ってもらう側が何らかの方法で公開鍵を相手に渡します。
送る側は、もらった公開鍵で暗号化して相手に送信します。
受け取った側は秘密鍵で復号化します。
ハッシュ関数とメッセージダイジェスト
ハッシュ関数（暗号通信で使う物は暗号学的ハッシュ関数と言うようです）は、与えられたデータに対して固定長のビット列（ハッシュ値、メッセージダイジェストとも言う）を生成するものです。
ハッシュ関数はいくつかの特徴を持ちます。
- 与えられたデータに対してメッセージダイジェストが容易に計算できる
- 逆にメッセージダイジェストから元のメッセージを得ることは不可能
- メッセージダイジェストを変えずに元のデータを改ざんすることは不可能
- 同じメッセージダイジェストを持つ2つのデータを求めることは不可能
電子署名
元文書のメッセージダイジェストを求めたら秘密鍵で暗号化します。これを元文書に添付しておきます。
元文書が改ざんされると、メッセージダイジェストの値が変わるため、改ざんが分かります。
また、メッセージダイジェストは秘密鍵で暗号化されているため、公開鍵で中身を見る事はできても、その内容を差し替えることができません（できるのは秘密鍵を持っている人のみ）。
SSLの仕組み
さて、ここからが本題です。
「じゃあショッピングサイトは秘密鍵と公開鍵を用意して、公開鍵を配って暗号化してもらえばいいんでしょ」と思われるかもしれません。これは2つの危険があります。
- そのサイトが本当にユーザーが求めるサイトかどうかが分からない
- 全員が同じ公開鍵で暗号化しているだけだと、なりすましができてしまう
仮に本物そっくりの偽サイトが公開鍵をばらまいていたら、そのまま信じて暗号化通信を始めてしまっても気づかずに決済してしまうかもしれません。また、ユーザーが使う鍵が同じだと他人がなりすましてしまうかもしれません。
そのため、SSLでは「第三者機関」が登場します。
※現在ではSSL（Secure Sockets Layer）の後継となるTLS（Transport Layer Security）が使われていますが、そのままSSLという呼び方をすることが多いようです。
サイト運営側の準備：サーバー証明書を作成する
サイト運営組織は、まず自身を証明するための「証明書」を作成します。これは決められた形式（興味のある方はX.509を参照してください）で組織の情報を記述し、公開鍵を含めて「認証局（CA=Certification Authority）」へ提出します。
CAは証明書の発行を行う機関です。有名どころではVeriSign（現在はSymantecが取得）があります。
CAは運営組織を審査した後、受け取った証明書に対してメッセージダイジェストを求めて自身の秘密鍵で暗号化し、証明書に添付します。これでサーバー証明書の完成です。
CAの公開鍵はどうやって配布するの？と思われた方、鋭いです。
CAも自身で署名した自身のサーバー証明書を作成してあり、これらはブラウザに最初から組み込まれています。
CAも自身で署名した自身のサーバー証明書を作成してあり、これらはブラウザに最初から組み込まれています。
SSLの仕組み
やっとSSLの仕組みに入ります。ここまで読んでいただけたら、この図で大体分かると思います。
・・・だけだとあんまりなので、説明を加えます。
クライアント（ブラウザ）はサーバーに対してSSLの要求を出すと、サーバーは証明書を送ってきます（③）。
ブラウザは受け取った証明書の電子署名をCAの公開鍵で復号し、証明書を検証します（④）。
検証の結果、偽の証明書だと分かる（もしくは自己証明書の場合：CAに依頼せず自身で署名を付けただけの物）と、ブラウザは警告を出します。
画像は警告を回避！Parallels Panelのコントロールパネル全体をSSL化する方法 | 株式会社LIGより
もし目的のサイトにアクセスしているはずなのにこの画面が出た場合、そのサイトは偽物の可能性があります。
※SEの方はテスト用に立てているサーバーでこの画面をよく目にすることがあるかもしれません。
証明書が正しいと分かったら、証明書からサーバーの公開鍵を取り出します。そしてランダムなデータを生成して、サーバーの公開鍵で暗号化してサーバーへ送ります（⑥）。
サーバーはデータを自身の秘密鍵で復号し、予め決められたアルゴリズムで共通鍵を2つ生成します（⑦）。
並行して、クライアント側でもランダムデータから共通鍵を2つ生成します（⑤）。鍵生成にどんなアルゴリズムを使うかは、事前にお互いがやりとりしている段階で決めます。同じアルゴリズムでお互いに鍵を生成するので、できた鍵は双方で同じになるはずです。
できた鍵を使って、共通鍵暗号方式で暗号通信を開始します（⑧）。
この鍵はSSL接続を開始するたびに異なるので、他社が介在する余地はありません。
・・・だけだとあんまりなので、説明を加えます。
クライアント（ブラウザ）はサーバーに対してSSLの要求を出すと、サーバーは証明書を送ってきます（③）。
ブラウザは受け取った証明書の電子署名をCAの公開鍵で復号し、証明書を検証します（④）。
検証の結果、偽の証明書だと分かる（もしくは自己証明書の場合：CAに依頼せず自身で署名を付けただけの物）と、ブラウザは警告を出します。
もし目的のサイトにアクセスしているはずなのにこの画面が出た場合、そのサイトは偽物の可能性があります。
※SEの方はテスト用に立てているサーバーでこの画面をよく目にすることがあるかもしれません。
証明書が正しいと分かったら、証明書からサーバーの公開鍵を取り出します。そしてランダムなデータを生成して、サーバーの公開鍵で暗号化してサーバーへ送ります（⑥）。
サーバーはデータを自身の秘密鍵で復号し、予め決められたアルゴリズムで共通鍵を2つ生成します（⑦）。
並行して、クライアント側でもランダムデータから共通鍵を2つ生成します（⑤）。鍵生成にどんなアルゴリズムを使うかは、事前にお互いがやりとりしている段階で決めます。同じアルゴリズムでお互いに鍵を生成するので、できた鍵は双方で同じになるはずです。
できた鍵を使って、共通鍵暗号方式で暗号通信を開始します（⑧）。
この鍵はSSL接続を開始するたびに異なるので、他社が介在する余地はありません。
EV SSL証明書とは
「これだけやってれば何も問題無いじゃない」と思われるかも知れません。
本来、SSLはCAの審査を受けさせることによって暗号通信に信頼性を持たせるのが目的でした。
しかし、CAにも色々あり、中にはそれほど厳密な審査を行わない（ドメインの登録情報を確認するのみ）で発行される証明書も存在します。
これを悪用して、SSL接続をしている（https://～で始まり、鍵マークが表示される）にもかかわらず、実際は偽サイトへ誘導されているというフィッシング詐欺に使われてしまうという問題が生まれてきました。
そこで、証明書の発行においてより厳格な審査を行い、クライアント（ユーザー）が通常の物と区別できるようにしましょうということで定められたのがEV（Extended Validation） SSL証明書です。
サイト管理組織側の話は、この記事を読んでいる方にはほとんど関係無いと思いますので省略します。簡単に言えば、銀行などフィッシング詐欺の標的になりやすいサイトについて、EV SSL証明書を導入することによって被害やサポートコストの削減に繋がります。
さて、クライアント（ユーザー、つまり我々）はどうやってEV SSL証明書かどうかを判断すれば良いのでしょうか。
答えは簡単です。ブラウザのアドレスバーを見れば分かります。
通常の証明書では単に「鍵マーク＋https://～」となっていますが、EV SSL証明書の場合は「緑色のバーで『鍵マーク＋運営者名』＋https://～」となります（画像はChromeの場合）。
ブラウザによって多少異なりますが、アドレスバーが緑色になって運営者名まで表示されるというのは共通です。
既にメガバンク3行にりそな、楽天銀行のようなネット銀行でも、オンラインバンキングの画面ではEV SSL証明書が使われています。
ですので、銀行などを騙った怪しいメールが来たとき、表示されたサイトがEV SSL証明書でない場合は要注意です。また、運営者名が異なっていたらこれも注意です。
逆に言えば、直接お金が絡むようなサイトを利用するときは、EV SSL証明書が導入されていて、運営者名が正しいかどうかを必ずチェックしましょう。
スマートフォンではどう見えるか
Android版のChromeで、スマホ版三菱東京UFJダイレクトと楽天市場のユーザー情報の画面を表示させました。どちらもアドレスバーは同じになっています。鍵マークをタップして出てくる詳細では、三菱東京UFJダイレクトの方は「VeriSign Class 3 Extended Validation SSL」と書かれており、EV SSL証明書であることが分かります。
Android版のFirefoxだと鍵マークの色で分かるそうです。
現状ではスマートフォンでブラウザを使ってオンラインバンキングを利用するのはやめておいた方が無難だと思います。どうしても利用する場合は、きちんと証明書を確認するか、あれば専用アプリを使う方が安全です。
EV SSLでは無いからといって危険ではない
勘違いしてはいけないのですが、EV SSL証明書を使ってないサイトだからといって危険というわけではありません。SSLの暗号化通信については全く同じ（おそらく。現時点では。）ですし、心配な場合はURLの確認と、鍵マークをクリックして証明書の内容を確認してみてください。よく似たURLだけど微妙に違うとか、証明書の各項目に！マークがたくさんあるとかでなければ大丈夫と思います。
（というか、楽天市場のお気に入り画面だと鍵マークに！が表示されます。理由はリソースの一部がSSL接続でないためのようです(；´∀｀) と言っても楽天のような大きいところはURLを確認しておけば大丈夫でしょう。
最近ではやたら値段の安い、独立したオンラインストアの方が危ないと思います。）
まとめ：正しい知識と普段からセキュリティ意識を持とう
SSLの仕組みとEV SSL証明書について、一通り覚えておくべき知識は説明したつもりです。EV SSL証明書は存在自体知らなかった方も多いのではないでしょうか。
ぜひ覚えておいて、今後オンラインバンキング等重要なサイトを利用する際には気をつけて見てみてください。
それではみなさまよきガジェットライフを(´∀`)ノ
【参考】
猫とガジェットが好きなJava屋さんです。うつ病で休職後退職し、1年半の休養後に社会復帰。・・・が、いろいろあって再び退職。さらに1年休職の後に復帰して、なんとかSE続けてます。茶トラのすずと一緒に生活していましたが、2014年9月4日に亡くなって1人に。
