SSL／TLS（Part.1）：不正アクセスを防止するSSL/TLS（2）（3/3 ページ）

暗号化パラメータとHandshake Protocol

　もう少し具体的に各プロトコルの関係を見ておこう。各プロトコルの具備している機能と、それぞれの相関を大まかに表したのが図5だ。

　まず、目立つのは下半分に横たわるReocord Protocolである。Record Protocolより上位にある各プロトコルは、Record Protocolを介して対向する通信相手とデータをやり取りする。Record Protocolは前述のように圧縮／暗号化を行っているので、これら上位プロトコルでの通信内容は原則として暗号化されることになる。

　その際、Record Protocolでは、図中の「利用中の暗号化パラメータ」と書かれている情報に基づいて暗号化の処理を行っている。この「利用中の暗号化パラメータ」には、具体的に言えば、使用する圧縮アルゴリズムや暗号アルゴリズム、また暗号化／復号で使うキーなどが含まれる。いわば「圧縮／暗号化のルール」とでも考えれば分かりやすいだろう。

　では、この「利用中の暗号化パラメータ」は、どうやって取り決めるのだろうか。「圧縮／暗号化のルール」である以上、通信相手も同じルールを使用する必要が出てくるはずだ。実は、それを行っているのがHandshake Protocolである。

　Handshake Protocolでは、最初に相手の認証を行った後に、自分と通信相手の間で手持ちの圧縮／暗号化アルゴリズムを突き合わせる。そしてその中から両者共通して利用できるアルゴリズムを探し、そのうちで最適なアルゴリズムの利用を決定する。また、利用決定したアルゴリズムに必要な付随する情報も同時に決定し、それぞれの合意内容を両者で保存しておく、という手順をとる。

　こうしてHandshake Protocolで決定した内容が、図中で「新しい暗号化パラメータ」と書かれている部分だ。ここで注意しなければならないのは、この時点ではまだ「新しい暗号化パラメータ」はRecord Protocolの動作に反映されない点だ。図中でもあえて別要素として記している。

　「新しい暗号化パラメータ」を「利用中の暗号化パラメータ」化して、Record Protocolの動作を切り替える契機となるのは、Change Cipher Spec Protocolだ。Chage Cipher Spec Protocolは、自分自身が利用する暗号化パラメータを変更すると同時に、その変更を通信相手にも通知する働きをもつ。つまり、利用する暗号化パラメータが決定した後、改めて両者が同期して暗号化パラメータの切り替えが行われているのだ。これは、通信を途絶えことなく、自由に暗号化パラメータの切り替えを可能とするための工夫の1つである。

　ちなみに、初期状態にあるRecord Protocolの「利用中の暗号化パラメータ」は、「圧縮なし、暗号化なし」に設定すると規定されている。そのため、もっとも初期の段階での暗号化パラメータ決定プロセスは、「圧縮なし、暗号化なし」で行われることになる。

　また、Application Data Protocolは、Record Protocolの機能を使ってユーザーアプリケーションにデータを引き渡すためのプロトコルである。だがこのプロトコル自身に働きはなく、実際にはRecord Protocolの内容が、そのままアプリケーションに引き渡されている。SSL/TLSのプロトコルを規定する上での概念上の存在と考えられる。

　表2には、Handshake Protocol、Change Cipher Spec Protocol、Application Data Protocolの各プロトコルのメッセージ種別と、その意味を示しておいた。現時点でこれらメッセージの意味を理解する必要はない。どういったメッセージがあるのかなど、SSL/TLSの全体像を俯瞰する程度のつもりで眺めておいていただくといいだろう。同様の意味で図6〜8には、各プロトコルのメッセージフォーマットも示しておく。

図6　Handshake Protocolのメッセージフォーマット

図7　Change Cipher Spec Protocolのメッセージフォーマット

図8　Application Data Protocolのメッセージフォーマット

Alert Protocolによる各種の通知

　SSL/TLSを構成するプロトコルのなかでも、ちょっと雰囲気が違うのがAlert Protocolだろう。Alert Protocol自身は、圧縮／暗号化機能、ネゴシエーション機能など、SSL/TLSのコアとなる機能は持っていない。その代わりにSSL/TLS機能の信頼性を向上させる重要な役割を担っている。

　Alert Protocolは、他のプロトコルの処理中に何らかのイベント（多くはエラーや異常）が発生した場合に、その発生を通信相手に通知するのが主な役割である。例えば、Handshake Protocolでは、最初に相手の認証を行う。大部分の場合、この認証に証明書を利用するわけだが、その証明書が壊れていたことを発見したとしよう。証明書が壊れていることを発見したマシンは、その事実をAlert Protocolのbad_certificateメッセージを使って相手に通知する。通知を受け取ったマシンは、自分が送った証明書が壊れていることを知ることができ、例えば証明書のチェックをユーザーに促すなどの、必要なアクションをとることができる。このほか、Alert Protocolは、SSL/TLSを使った通信の終了を通知する目的でも利用される。この場合にはclose_notifyメッセージが使われている。

　さらに細かく見ていくと、Alert Protocolには、Warning（警告）とFatal（致命的）の2つのレベルが存在する。Warningは比較的軽微なイベントの通知に、Fatalは重大なイベントの通知に利用する。動作でみると、Warningでは単に情報の通知だけが行われる。一方、Fatalでは、そのメッセージを送信したマシン、およびそれを受け取ったマシンは、直ちにその接続を終了する。つまり、Fatalは安全な通信を行う環境が崩れたことを通知するメッセージという位置付けとなっている。

　SSL/TLSはどんな場合に安全な通信を行う環境が崩れたと見なすのか、またどんなイベントが通信相手に通知されるのだろうか。表3のAlert Protocolのメッセージ一覧はそれを教えてくれる。各メッセージの意味をパーフェクトに意味を把握できなくとも、SSL/TLSの異常処理の像がはっきり浮かび上がってくるはずである。なお、メッセージによっては、送信者が自らの裁量でWarningかFatalかを決定してよいものもある。また図9はAlert Protocolのメッセージフォーマットである。プロトコルのイメージを膨らませるのに役立たせてほしい。

図9　Alert Protocolのメッセージフォーマット

　このように、SSL/TLSの各レイヤでは安全な通信を行うために必要な機能が上手に分担されており、シンプルで効果的なプロトコルを実現していることがわかる。こういった予備知識をベースにして、次回は、本格的にSSL/TLSの真髄に迫ってゆくことにしよう。おもな内容は、Record P　rotocolの具体的な処理内容、Handshake Protocolでの圧縮／暗号化アルゴリズムの選択など、SSL/TLSの中でも暗号化技術に深く関わる部分を取り上げる。