身近なPKI〜SSLを理解する：PKI基礎講座（3）

　インターネットの利用が普及した現在、その利用方法で最も一般的なものとして挙げられるのはWebとメールだろう。言い換えれば、インターネットを利用するアプリケーションの中で、最も普及しているのはWebブラウザとメーラである。Internet Explorer（以下、IE）やNetscape Navigator（以下、NN）などのメジャーなWebブラウザのほとんどが「SSL対応」という形で、また、OutlookやNetscape Messengerといった主要なメーラは「S/MIME対応」という形でPKIの実装がなされている。

　今回は、この最も身近なPKIの実装ともいえるSSLについて見ていきたい。

“セキュア”な通信を実現するSSLとは？

　SSLとはSecure Sockets Layerの略で、Netscape Communications社が提唱しているプロトコルだ。現在その仕様はVersion 3.0となっており、Netscape Communications社のWebサイトで公開されている。

　もともとSSLは、その名が示すとおりプロセス間のソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではない。しかし、現状はWebにおける認証および通信の暗号化に最も多く使用されている。

図1　SSLの位置付け

　SSLは実際にTCP/IPの上で実現され、その上でHTTPやLDAPなどのアプリケーションプロトコルが動く形になる（図1）。

　SSLで実現できる機能としては、以下の3つがある。

　(1)、(3)を実現するためにはサーバ側に秘密鍵と公開鍵のキーペアおよびそれに対する証明書が、(2)を実現するためには、さらにクライアント側にもキーペアおよびそれに対する証明書がそれぞれ必要になる。

　実際にはそれぞれを独立して実装することはできず、(1)と(3)の組み合わせか、(1)から(3)のすべてを実装するか、どちらかの選択を行うことになる。業務的なニーズとしてはHTTPセッションを暗号化したいというニーズが圧倒的に多く、それを実現するために(1)と(3)の組み合わせを取っているパターンが一番多いようだ。

SSLの実現〜サーバ認証

　先ほども書いたように、SSLのサーバ認証は文字どおりサーバの認証を行う機能と、セッションの暗号化機能がある。Webの環境でこれを行うためには、Webサーバ側に秘密鍵と公開鍵のペア、およびそれに対応する証明書が必要になる。MicrosoftのInternet Information Server（IIS）を例にとって、キーペアの生成から証明書のインポート、SSLの設定までを見てみよう。

　IISではインターネットサービスマネージャを使って設定を行う。

　これでキーペアの生成が完成し、証明書要求の準備ができたことになる。

画面1　キーマネージャを起動したところ（画面をクリックすると拡大表示します）

　なお、ボルチモアテクノロジーが提供するWebサーバ用証明書「SureServer」では、30日間の無料トライアル版を発行している。Webページに上記で作成したCSRをコピー＆ペーストして送信するだけなので、ぜひ試していただきたい。詳細はボルチモアテクノロジーのホームページを参照してほしい。

　さて、証明書の入手ができたらそれをIISにインポートする必要がある。証明書のインポートの手順は以下のとおりだ。

　また、上記の証明書を発行した認証局の証明書もインポートする必要がある。以下が認証局の証明書のインポート手順だ。

　さて、証明書のインポートが終了したら最後はSSLの設定を行う。SSLの設定はインターネットサービスマネージャの「セキュリティで保護された通信」ダイアログボックスで「このリソースにアクセスするときに、セキュリティで保護されたチャネルを必要とする」にチェックを入れるだけだ。サーバ認証であれば「クライアント証明書の認証」は「クライアント証明書を受諾しない」にチェックを入れておけばよいだろう（画面2）。

画面2　「セキュリティで保護された通信」ダイアログボックスでは、「クライアント証明書を受諾しない」の項目にチェックを入れておく（画面をクリックすると拡大表示します）

　これで、SSLサーバ認証の準備は完了だ。あとはクライアントのWebブラウザからそのサイトにアクセス（その際はURLの入力を「https://」で始めなければならない）して、実際にSSLで通信が行われていることを確認する。

　また、この際、画面3のようなメッセージが現れることがある。これは、Webブラウザがサーバの証明書を発行した認証局が信頼できるかどうか判断できないために表示されるものだ。独自に立てた認証局など、Webブラウザにあらかじめ設定されている以外の認証局（先のSureServerトライアル版も同様）からサーバ証明書を発行している場合、その認証局を「信頼できる証明機関」のリストに追加する必要がある。以下がその手順だ。

画面3　このような警告が表示された場合には、上記の手順に沿って認証局を「信頼できる証明期間」のリストに追加する必要がある（画面をクリックすうと拡大表示します）

画面4（左：IE）・5（右：Netscape）　Webブラウザに表示されるマークが、それぞれ上記の状態になっていれば、セッションが張られている状態であることがわかる

　SSLのセッションが張られたかどうかは、IEなら右下に鍵マーク（画面4）が現れること、NNなら左下の鍵マーク（画面5）が閉じた状態になっていることで確認できる。ちなみに、この鍵マークをダブルクリック（NNならシングルクリック）することによって、サーバ側の証明書の内容を確認することが可能だ（画面6・7）。

画面6（左：IE）・7（右：Netscape）　それそれWebブラウザでサーバ側の証明書の内容を確認したところ（画面をクリックすると拡大表示します）

SSLの実現〜クライアント認証

　さて、今度はクライアント認証まで行う場合について見てみよう。

　まず、サーバ側でクライアント認証を行う旨の設定をする。設定の方法は、サーバ認証のときに使用したインターネットサービスマネージャの「セキュリティで保護された通信」画面で「このリソースにアクセスするときに、セキュリティで保護されたチャネルを必要とする」にチェックを入れ、さらに「クライアント証明書の認証」の「クライアント証明書を要求」にチェックを入れる必要がある。このような設定がされたサイトにアクセスすると、IEであれば証明書を選択するための画面が表示される。この選択画面に表示される証明書は、クライアント側にインストールされている証明書のうち、サーバ側で「信頼する認証機関」として登録している認証局から発行されたものだけである。もし該当する証明書が1枚もクライアントにインストールされていない場合、証明書選択画面は表示されるが候補の証明書が1つもないという画面が表示されることになる。

　すなわち、サーバ側が信頼していない認証局から発行された証明書を持っていても、そのサーバにはアクセスできないということだ。

　SSLのクライアント認証の一番基本的な部分は、このように「クライアントがサーバの信頼する認証局から発行した証明書を持っているか否か」のチェックを行うものである。ただし、（旧Netscapeの）iPlanetのWebサーバとディレクトリサーバの組み合わせでは、ディレクトリサーバ上に格納されている証明書とクライアントの提示してきた証明書が一致しているかどうかまでのチェックを行うことができる。

　また、IISであればASP（Active Server Pages）を使ったサーバサイドのスクリプトによって、またiPlanetのWebサーバであればNSAPIを使用することによって、それぞれ証明書の情報を取得することができる（図2）。上記のWebサーバの下で動くアプリケーションがユーザーの情報を取得し、後続の処理を振り分けたいなどのニーズは多いだろうから、このような形で証明書の内容を取得できることは非常に重要だろう。

図2　Webサーバから証明書の情報を取得することができる

SSLの仕組み

　ここでSSLのプロトコル仕様のすべてを紹介することは不可能なので、セッションを確立するためのHandshake Protocolについてのみに触れることにする。

　Handshake Protocolとは、SSLの中でセッションを開始あるいは再開するために用いられるプロトコルで、認証に必要な証明書情報や、セッションで使用する暗号化のアルゴリズムなどをクライアントとサーバの間でやりとりするためのプロトコルだ。

　具体的には、以下のメッセージがやりとりされる（図3）。

図3　Handshake Protocolでのメッセージシーケンスのイメージ

(1) Helloメッセージ

　このメッセージでは、クライアントとサーバの間で使用する暗号化アルゴリズムなどの情報を交換する。具体的には以下のメッセージがある

• Hello Request
  サーバからクライアントに送信される。Client Helloを要求するメッセージで、受け取ったクライアントは直ちにClient Helloメッセージを送信しなければならない
• Client Hello
  クライアント側が、最初にサーバに接続するとき／上記のHello Requestをサーバ側から受け取ったとき／既存のコネクションにおいて暗号化パラメータなどを変更するときにサーバ側へ送信する。内容は使用される暗号化方式やデータの圧縮方式に関する、候補のリストが格納された形になっている
• Server Hello
  Client Helloに対するサーバ側の応答メッセージ。Client Helloのメッセージで示された暗号化方式と圧縮方式のリストから、どれを使用するかを指定する

(2)Server Certificateメッセージ

　サーバからクライアント側に送られるメッセージ。サーバ側は自分の証明書をこのメッセージを使用してクライアント側に送付する。また、ここにはその証明書を発行した認証局の証明書や、さらに上位の認証局があればその証明書といった形で、ルート認証局までの証明書チェーンをすべて含んだリスト形式で送信される

(3)Server Key Exchange

　サーバが証明書を持っていない場合、あるいは持っていても署名にしか使用できない場合に、サーバ側からクライアント側に送信されるメッセージ

(4)Certificate Request

　クライアント認証を行う際に、サーバ側からクライアントの証明書の提示を要求するためのメッセージ。このメッセージに、サーバ側が信頼する認証局のリストが付加されている

(5)Server Hello Done

　サーバ側からクライアントに向けた一連のメッセージが送信されたことをクライアント側に通知するためのメッセージ

(6) Client Certificate

　クライアント認証を行う場合にクライアント側が自分の証明書をサーバに送信するためのメッセージ。データの形式はServer Certificateと同様

(7) Client Key Exchange

　セッションで暗号化のために使用される鍵（セッションキー）を生成するときに使用されるマスタシークレットを生成するもとになる、プリマスタシークレットデータを、クライアント側から送信するためのメッセージ。RSAの場合、プリマスタシークレットデータはサーバの公開鍵で暗号化される

(8) Certificate Verify

　クライアントからサーバに送信される。サーバ側がクライアントの認証を行うために必要なデータを送信する。具体的には双方が既知のデータのハッシュ値をとり（SHAとMD5双方のアルゴリズムが用いられる）、クライアント側の秘密鍵で暗号化したもの。サーバ側でこれをクライアントの公開鍵で復号し、同じように取得したハッシュ値と比較することで検証を行う

(9) Finished

　クライアント側、サーバ側双方とも、相手の認証が正常に行われたことを相手に知らせるためのメッセージ

　このような形で相互の認証が行われた後、双方でプリマスタシークレットデータから最終的にセッションキーが生成され、暗号化が施されたセッションが開始されるという手順になっている。

　冒頭にも書いたが、おそらくSSLが今最も広く使用されているPKIの実装形態であると思う。そのような意味で、SSLはPKIを「実感」するためのよい教材となるであろう。今後、ブラウザの「鍵マーク」が閉じられたサイトがあったら、ぜひマークをクリックして、サーバ証明書の内容をのぞいてみてほしい。