SSL／TLS（Part.1）：不正アクセスを防止するSSL/TLS（2）（3/3 ページ）
暗号化パラメータと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の中でも暗号化技術に深く関わる部分を取り上げる。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。