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

» 2000年07月15日 00時00分公開

[福永勇二，インタラクティブリサーチ]

暗号化パラメータとHandshake Protocol

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


プロトコル名	役割
Record Protocol	上位レイヤからのデータを圧縮／暗号化して、対向する通信相手に送信する。また通信相手から受信したデータを復号／伸張して、上位レイヤに引き渡す
Handshake Protocol	暗号化アルゴリズム、キー、証明書など、暗号化された通信を開始するために必要なパラメータを、通信相手とネゴシエーションして決定する
Change Cipher Spec Protocol	Handsake Protocolで決めた、新しい暗号化通信パラメータの利用開始を通信相手に通知し、自らも利用を開始する
Application Data Protocol	現在有効な暗号化通信パラメータに従って、アプリケーションデータを透過的に送受信する
Alert Protocol	通信中に発生したイベントやエラーを通信相手に通知する
図5　SSL/TLS内部プロトコルの機能と相関

　まず、目立つのは下半分に横たわる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には、各プロトコルのメッセージフォーマットも示しておく。


プロトコル名	メッセージタイプ	説明
Handshake Protocol	hello_request	暗号化しようを決定するためネゴシエーションを開始するようサーバがクライアントに要求する
	client_hello	クライアントが最初にサーバヘ送るメッセージ。プロトコルバージョン、セッションID、暗号化アルゴリズム等の候補を指定する
	server_hello	サーバからクライアントに返送するメッセージ。利用が決定したプロトコルバージョン、セッションID、暗号化アルゴリズム等を指定する
	certificate	サーバからクライアントへ、またはクライアントからサーバへ、自身が所有するルートまでのX.509v3証明書一式を引き渡す
	server_key_exchange	RSA公開鍵またはDiffie&Hellman公開情報をクライアントに渡す。おもに証明書が利用できない場合に使用する
	certificate_request	サーバがクライアントの持っている証明書を要求する
	server_hello_done	サーバによる必要なネゴシエーションが終了したことをクライアントに知らせる
	client_key_exchange	クライアントが生成した48バイトの乱数をサーバの公開鍵で暗号化してサーバへ送る。両社はこの値をもとにマスタシークレットを生成する
	certificate_verify	クライアント証明書の正しさを確認するため、ここまでのメッセージのダイジェストを、クライアントの秘密鍵で暗号化してサーバへ送る
	finished	Handshake Protocolの終了を表す。ここまでに決めた暗号化仕様でこのメッセージは暗号化されている。身元確認用のダイジェストも含む
Change Cipher Spec Protocol	change_cipher_spec	Handshake Protocolで決定した暗号化仕様やキーの利用開始を相手に知らせる
Application Data Protocol	—	アプリケーション間でやりとりするデータを透過的に引き渡す
表2　Handshake Protocol、Change Cipher Spec Protocol、Application Data Protocolのメッセージ一覧

図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のメッセージフォーマットである。プロトコルのイメージを膨らませるのに役立たせてほしい。


メッセージタイプ	レベル	説明
close_notify	warning	コネクションの終了を通知する
unexpected_message	fatal	不適切なメッセージを受信したことを通知する
bad_record_mac	fatal	受信したメッセージのMACが不正であることを通知する
decryption_failed	fatal	メッセージサイズがブロック数と異なるなど復号時に問題が発生したことを通知する
record_overflow	fatal	上限を超えたサイズのメッセージを受信したことを通知する
decompression_failure	fatal	伸張したデータが大きすぎるなど、データ伸張時に問題が発生したことを通知する
handshake_failure	fatal	指定されたセキュリティパラメータのセットに、利用できるものがないことを通知する
bad_certificate	＊1	壊れた証明書、署名の正当性が確認できない、などを通知する
unsupported_certificate	＊1	サポートされていない証明書であることを通知する
certificate_revoked	＊1	署名者によって無効化された証明書であることを通知する
certificate_expired	＊1	期限切れの証明書である、または現在無効な証明書であることを通知する
certificate_unknown	＊1	証明書の処理中に何らかの問題が発生して、証明書を受理できないことを通知する
illegal_parameter	fatal	ハンドシェイク中のパラメータが範囲外、または他フィールドと矛盾していることを通知する
unknown_ca	fatal	有効な証明書チェーンを受信したが、CA証明書がないか、信頼できるCAでないため受け付けられなかったことを通知する
access_denied	fatal	有効な証明書を受信したが、アクセスコントロールを適用したときに、送信者がネゴシエーション継続の中止を決定したことを通知する
decode_error	fatal	フィールド値が範囲外であったり、メッセージの長さに異常があり、メッセージのデコードができないことを通知する
decrypt_error	＊1	ハンドシェイク暗号化に失敗したことを通知する。署名の検証、鍵交換の復号、終了メッセージの検証に失敗したことも含まれる
export_restriction	fatal	輸入規制に従わないネゴシエーションが行われたことを通知する
protocol_version	fatal	指定されたプロトコルバージョンはサポート対象外であることを通知する
insufficient_security	fatal	クライアントで利用可能な暗号化アルゴリズムよりもより安全なアルゴリズムが必要であることを通知する
internal_error	fatal	メモリアロケーション失敗など、ハンドシェイクとは無関係な理由でネゴシエーションが継続できなくなったことを通知する
user_canceled	warning	ハンドシェイク中にユーザーが処理中止を要求したことを通知する
no_renegotiation	warning	再ネゴシエーションによるセキュリティパラメータの変更ができないことを通知する
表3　Alert Protocolのメッセージ一覧＊1 メッセージ送信者の裁量でwarningかfatalかが決定される≫

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

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

「次回」へ

「不正アクセスを防止するSSL/TLS」バックナンバー