SSL（Secure Socket Layer）

　SSL（Secure Socket Layer）とは、インターネット上でデータを暗号化して送受信する方法のひとつです。

　通常、インターネットでは、暗号化されずにデータが送信されています。そのため、通信途中でデータを傍受されると、情報が第三者に漏れてしまう可能性があります。また、相手のなりすましに気付かずに通信すると、データがなりすましの相手に取得されてしまう可能性があります。

　現在、クレジットカード番号や個人情報を扱う多くのホームページでは、通信途中での傍受やなりすましによる情報漏洩を防ぐ目的で、SSLを利用しています。

　利用者がSSLを利用できるサーバーとデータをやり取りする場合には、Webサーバーと利用者のコンピュータが相互に確認を行いながらデータを送受信するようになるため、インターネットにおける通信内容の暗号化及びなりすましの防止が実現されます。

　IE（Internet Explorer）やNetscapeなどのSSLに対応したWebブラウザを利用して、SSLで保護されたサイトに接続すると、通信相手の認証が行われ、通信データが自動的に暗号化されるようになります。このとき、主なWebブラウザでは、ステータス欄に鍵のマークが表示されます。たとえば、IEでは、SSL接続を行っている場合には、右下のステータス欄に鍵のマークが表示されるようになっています。なお、この鍵のマークをダブルクリックすると、サーバー証明書の詳細情報を確認することができます。

ストリーム暗号利用時のTLSCiphertext

では、ストリーム暗号利用時のTLSCiphertext構造体から見ていこう（図14）。type、versionの各フィールドは、そのサイズや意味いずれもTLSPlaintext、TLSCompressedと変わりない。またlengthフィールドは、この構造体のfragmentフィールドの長さを示している。

図14　ストリーム暗号利用時のTLSCiphertext構造体のフォーマット

　異なるのはfragmentフィールドだ。TLSCompressed構造体では、fragmentフィールドに圧縮済みデータが含まれていた。TLSCiphertext構造体では、圧縮済みデータ（図ではcontentと表示）に続いて、さらにMACデータが付加されたものになる。

　このMACとはMessage Authentication Codeを省略したものだ。日本語にすれば「メッセージ認証コード」とでもなり、単純な認証情報のようにも見えるが、実際には、データ本体の内容を要約した情報と、通信相手と自分だけが知っている秘密の情報が含まれている。そのため、1つの情報で、通信相手の認証と、メッセージの改ざん検出の、両方が行えるようになっている。前編で登場した「メッセージダイジェスト」はこのMACを指したものだ。MACの具体的な生成アルゴリズムについては、後ほど詳しく説明しよう。

　TLSCiphertext構造体のfragmentフィールドに格納されるデータサイズは、最大で2の14乗＋2048バイトと定義されている。TLSCompressedのfragmentフィールドサイズが最大2の14乗＋1024バイトなので、これはそれより1024バイト大きいことになる。

　ここで気を付けたいのは、このフィールドに含まれるのが「圧縮済みデータにMACをつなげたものを『暗号化した』データ」である点だ。TLSCiphertext構造体に格納された時点で、すでにfragmentフィールドに含まれているデータは暗号化されている。そのため、図ではfragment内部にフィールドの区切りがあるように表現しているが、論理的にはこの区切りは表面から見えないものと考える必要がある。一方、type、version、lengthの各フィールドは、TLSCiphertext構造体であっても、暗号化されないままで格納されている。TLSCiphertext構造体を見るにあたってはこの点に留意しておこう。

　暗号化を行うのであれば、フィールドサイズに問題はないのだろうか。確認しておこう。まず、圧縮済みデータは最大で2の14乗＋1024バイトである。また、MACは使用するハッシュアルゴリズム（ダイジェスト生成アルゴリズム）によってサイズが異なり、通常は16バイト（MD5使用時）または20バイト（SHA-1使用時）になる。これらをつなげたデータ（最大2の14乗＋1024＋最大20）に暗号化操作を施して、そのサイズが2の14乗＋2048バイトを超えなければよい。

　たとえば暗号化アルゴリズムにDESを使用した場合、暗号化前と暗号化後でデータサイズは変わらない。ゆえに暗号化後のデータは十分2の14乗＋2048バイトに収まることになる。なお、lengthフィールドに含まれる値は、この暗号化後データのサイズである。

ブロック暗号利用時のTLSCiphertext

　次にブロック暗号利用時のTLSCiphertext構造体を説明しよう（図15）。基本的な構造やフィールドの意味はストリーム暗号利用時とほぼ同じだ。異なるのは、paddingフィールド、padding_lengthフィールドが追加されている点である。

図15　ブロック暗号利用時のTLSCiphertext構造体のフォーマット

　暗号化アルゴリズムにブロック暗号を利用する場合、fragmentフィールドのサイズは、そのアルゴリズムで規定するブロックサイズの整数倍に調整しなければならない。paddingフィールドとpadding_lengthフィールドは、その調整のために利用されるものだ。

　paddingフィールドのサイズは0から255までのいずれかの長さを取る。padding_lengthのフィールドのサイズは1バイトで、paddingフィールドのサイズとして0から255までの整数を格納する。paddingフィールド、そして、このpadding_lengthフィールド分の1バイトも含めて、fragmentフィールド全体がブロックサイズの整数倍になるよう調整を行うことになる。

図16　paddingフィールドのサイズ計算方法。SSLとTLSでは若干の違いがある

　padding_lengthの値を決めるには、まずcontentのバイトサイズとMACのバイトサイズに1（padding_lengthのバイトサイズ）を加え、それを暗号化アルゴリズムのブロックサイズで割る。その余りをブロックサイズから引くことで、padding_lengthの値（＝パディングフィールドのサイズ）が得られる。具体的に計算をしてみると、contentが61バイト、MACが20バイト、ブロックサイズが8のとき、paddingフィールドのサイズは8－(61＋20＋1) mod 8 ＝ 6バイトになる（図16）。

　この6バイトのpaddingフィールドはどんな値で埋めるのだろうか。それにはpadding_legnthフィールドの値を使用するよう定義されている。つまり、前出の例では、paddingとpadding_lengthに相当する部分の値は、0x06 0x06 0x06 0x06 0x06 0x06 0x06 となるわけだ。これはパディング処理を容易にするための配慮と考えられる。

　ところで、この例ではpadding_lengthを6としたが、ブロックサイズの整数倍化という意味では、14、22、30など、6に8の倍数を加えた値でも条件は成り立つ。こういう指定は可能なのだろうか。

　これに関して、SSLの仕様書では、padding_lengthはブロックサイズより小さくなると書かれている。そのためSSLではこういった指定は許容されない。一方、TLSの仕様書によると、パディングはブロックサイズの整数倍になることは求められているが、ブロックサイズより小さくする必要はない。そのため、こういった値を使ったパディングをしてよいことになる。

　このような許容が行われたのには、仕様を寛容にしたという面もあるのだろうが、それよりも攻撃への耐性を向上させるという意味が強い。TLSCiphertext構造体のlengthフィールドは暗号化されておらず、この解析によって攻撃への足がかりを与えてしまう可能性がある。ブロック数の整数倍パディングを許容すれば、メッセージ長の解析を多少なりともやりづらくする効果があると考えられる。

TLSPlaintext

□TLSPlaintext

　上位プロトコルが通信相手とやりとりするメッセージは、TLSPlaintext構造体としてRecordレイヤに引き渡される。図12にTLSPlaintext構造体の内容を示した。構造体の各フィールドには次のようなものがある。

図12　TLSPlaintext構造体のフォーマット

　まず最初のtypeフィールド（1バイト）には上位プロトコルの種別を表す値が入る。具体的な値は、Change Cipher Spec Protocolが0x14、Alert Protocolが0x15、Handshake Protocolが0x16、Application Data Protocolが0x17である。これによって、この構造体に含まれるメッセージが、どの上位プロトコルのものかを表している。

　次のversionフィールド（2バイト）には、メジャーバージョン番号（1バイト）とマイナーバージョン（1バイト）番号が、連続して格納される。例えばTLSならメジャーバージョン3、マイナーバージョン1となる。SSL 3.0ならメジャーバージョン3、マイナーバージョン0だ。

　その後のlengthフィールド（2バイト）は、続くfragmentフィールドの長さをバイト単位で表した値を格納するフィールドである。fragmentフィールドの長さは一定ではない。そこで、lengthフィールドにその長さが指定されている。2バイトのフィールド中には、長さを表す値の上位バイト、下位バイトの順に格納されてゆく。

　最後のfragmentフィールドは上位プロトコルからのデータを収容する部分だ。Recordレイヤで取り扱う上位プロトコルには複数の種類が存在しており、それらのメッセージの中には可変長のものもある。そのため、fragmentフィールドは可変長として定義されている。フィールド長は前出のlengthフィールドに指定する。最大サイズは2の14乗バイトである。

　TLSPlaintext構造体では、fragmentフィールドに含まれるデータは、非圧縮・非暗号化のままである。この構造体はRecordレイヤと上位レイヤのインターフェイスに用いられるため、当然といえば当然のことである。Recordレイヤ内部において、このTLSPlaintext構造体を基にして、さまざまな必要な処理を施してゆき、最終的な圧縮・暗号化されたデータを含むTLSCiphertext構造体を生成していくことになる。

■TLSCompressed

　Recordレイヤ内部では、まず最初にTLSPlaintextに対してデータの圧縮が施される。そしてその際に使用する圧縮アルゴリズムは、上位レイヤでのネゴシエーションによって決定される。

　ここでちょっと混乱してしまいそうなのは、そのネゴシエーションにもRecordレイヤが利用される点だ。卵が先か鶏が先かの問題ではないが、圧縮アルゴリズムを決める際の圧縮アルゴリズムには何が使われるのか、これだけでははっきりしない。そこでSSL/TLSでは、何もネゴシエーションが行われていないまったくの初期状態で使用する圧縮アルゴリズムは、「圧縮アルゴリズムなし（CompressionMethod.null）」と定義している。つまりまったくの初期状態では圧縮を行わずにネゴシエーションを行うのである。そしてその後に、合意した圧縮アルゴリズムの利用が開始されることになる。

　こうして決定したアルゴリズムにより、圧縮したデータを格納するのが、図13に示すTLSCompressed構造体だ。

図13　TLSCompressed構造体のフォーマット

　このTLSCompressed構造体の生成は次のように行われる。まずTLSPlaintext構造体の各フィールドは、fragmentを除いてそのままTLSCompressedに写される。また、fragmentフィールドに関しては、TLSPlaintextの内容をネゴシエーションで合意した圧縮アルゴリズムによって圧縮し、それをTLSCompressedのfragmentフィールドに格納する。

　この手順からも分かるように、fragmentフィールドを除けば、ほかのフィールドはそのままTLSPlaintextから写されるため、TLSCompressed構造体そのものはTLSPlaintext構造体と大変よく似ていることが見て取れると思う。

　唯一異なるframgentフィールドについては、格納可能な最大サイズが2の14乗＋1024バイトになるよう定義されている点が異なる。ここで不思議に思われる人もいるだろう。非圧縮データを含むTLSPlaintextのfragmentフィールドの最大サイズが2の14乗なのに、圧縮データを含むTLSCompressedのfragmentフィールドの最大サイズが2の14乗＋1024バイトと増えているのはなぜか。

　その答えはファイルアーカイバの動作から推測できる。zipでもlhaでもいいのだが、適当なアーカイバを使ってテキストファイルを圧縮して、出来上がったzipファイルなどをさらに圧縮したとする。そこで、圧縮済みファイルと、それを再圧縮したファイルのサイズを比較してみると、圧縮前よりも圧縮後ファイルサイズが大きくなるという、逆転現象が観察されることがある。

　これは、情報の圧縮に論理的な限界があるため発生する現象だ。すでに圧縮され、論理的な圧縮限界に達した情報は、それ以上の圧縮ができない。それにもかかわらず再圧縮を行うと、圧縮に関する管理情報や圧縮のための辞書情報（下記の脚注を参照）が付加された分だけ、全体のサイズが再圧縮前より大きくなってしまうのである。

　TLSCompressedのfragmentフィールドでも、これと同様のことが考慮されているものと考えればよい。TLSPlaintextのfragmentフィールドは、Application Data Protocolでも利用されている。Application Data Protocolは、アプリケーションがやりとりするデータを透過的に含むため、結果としてfragmentフィールドに圧縮済みデータが含まれることが考えられる。

　もし、そこにRecordレイヤでの圧縮処理を適用すると、fragmentフィールドのデータはどうなるだろうか。そう、データの圧縮は行われず、管理情報や辞書情報の分だけサイズが大きくなる可能性が大きいのである。こういったケースを考慮して、TLSCompressedのfragmentフィールドには1024バイト分の余分なフィールドが見込まれているものと考えられる。

　なお、ここまで説明しておいて話をひっくり返すようで恐縮だが、SSL/TLSの基本的な仕様の範囲には、データ圧縮の具体的なアルゴリズムは定義されていない。現段階では、データ圧縮を利用する枠組みだけが用意されていて、その実装については行われていないのが実情である。使用する圧縮アルゴリズムを含め、詳細は今後の仕様拡張として定義されるものと思われる。

●圧縮のための辞書情報● 　圧縮アルゴリズムの中には、頻出する値の並びを辞書に登録しておき、値の並びを辞書のエントリ番号で置き換えることで、全体のデータサイズを小さくするというアプローチを行うものがある。LZ77符号、LZ78符号などはその代表例だ。 　これらのアルゴリズムでは、その結果出力には、本来の圧縮済みデータと共に、使用した辞書が添付される。もし、圧縮対象データの圧縮率がゼロに近いと、添付した辞書のサイズ分によって、圧縮後データの方がサイズが大きくなることがある。

■TLSCiphertext

　データ圧縮機能により圧縮されたデータはTLSCompressed構造体に格納されている。そこに格納されたデータと、そのデータから算出したダイジェスト値、そして暗号アルゴリズムによってはパディングを加え、それら全体に暗号化を施したデータは、次にTLSCiphertext構造体に格納される。

　TLSCiphertext構造体には2つのパターンが存在する。その違いは、使用する暗号化アルゴリズムの性質、具体的には暗号化対象データの取り扱い単位に起因するものだ。このうちの1つは、暗号化対象データを一連のストリームとしてみなして、バイトまたはビット単位で暗号化処理を行うものだ。このタイプの暗号はストリーム暗号と呼ばれる。もう1つのタイプは、暗号化対象データを一定サイズのブロックに区切って、そのブロック単位で暗号化処理を行うものだ。こちらはブロック暗号と呼ばれている。

　ストリーム暗号は、それを適用する対象データのサイズに制約がない。そのため、暗号操作を行う前処理は不要である。一方、ブロック暗号では、暗号化対象データは特定のブロックサイズ（暗号アルゴリズムによって異なる）でなければならない。ブロックサイズに満たない場合に、パディングと呼ばれる詰め物をして、あらかじめブロックサイズとなるよう調整した上で、暗号操作を適用する必要がある。このための構造がブロック暗号使用時には必要となるため、TLSCiphertext構造体の構成には2パターンが存在しているという事情なのである。

　なお、具体的な暗号アルゴリズムとしては、ストリーム暗号の代表例としてはRC4、またブロック暗号の代表的なものとしてはDESやFEALなどがある。また、IPAのWebページ「暗号アルゴリズムの登録状況」（http://www.ipa.go.jp/security/enc/regist-3.htm）には、国際的に登録されている暗号アルゴリズムの一覧があり、ストリーム暗号、ブロック暗号の区別が記してあるので参照してみるとよい。

Recordレイヤ内部で起きていること

　前編では、SSL/TLSプロトコルを規定する基本コンセプトと、そこに含まれる各構成要素の機能概要を見てきた。難解なイメージのあるSSL/TLSだが、その根底に流れるアイデアは、理解が容易なシンプルなものであることは感じていただけたと思う。そうやって全体的な構造が把握できたところで、いよいよこの後編でSSL/TLSの核心部分である暗号化技術に関する内容に踏み込んでゆく。前回同様、可能な限り噛み砕いて分かりやすい説明を心がけてゆくので、最後までじっくりお付き合い願いたい。

Recordレイヤ内部で起きていること

　前回の「暗号化パラメータとHandshake Protocol」のセクションでは、通信に先立ってHandshake Protocolで暗号化パラメータを決定し、そのパラメータに従ってRecord Protocolが機能する様子を説明した。Record Protocolは、主にデータの圧縮と暗号化をつかさどっていて、ほかのプロトコルはRecord Protocolを利用して通信相手とデータをやりとりする。いってみれば、SSL/TLSにおける通信基盤のような位置付けである。

　Record Protocolを使って、実際に圧縮・暗号化が提供される部分は、Recordレイヤと呼ばれている。後編のはじめは、まずこのRecordレイヤ内部で行われていることを調べてゆき、そこからSSL/TLSで行われるデータ圧縮・暗号化の具体的な姿を追いかけてみよう。

　ここで1つ留意しておいていただきたい点がある。それは、ここでのRecordレイヤの説明が、あくまでもRecordレイヤ内部の話を取り扱っているという点だ。

　説明では、ブラックボックスであるはずのレイヤ内部をさらに複数の構成要素に分けて、各構成要素間で行き交うデータを構造体（特定のフォーマットに整形されたデータ群）として明示的に記述している。このようにデータ構造が明示されると、なんらかの形で観察できると誤解しがちだ。しかし、これらの構造体はあくまでもレイヤ内部データであって、一部を除いて、外部とやりとりされることはない。説明を読み進めるにあたっては、この点を誤解しないよう注意を払っておいていただくといい。

　また実際の通信では、上位プロトコルからのメッセージが、Recordレイヤを介してネットワークに送出されるデータのほかに、ネットワークからのデータが、Recordレイヤを介して上位プロトコルに届けられるデータが存在する。だが、ここでは主に上位プロトコルからのデータをRecordレイヤで取り扱うケースで説明してゆくことにする。

図10　Recordレイヤでの圧縮／暗号化処理フロー

　では本題に移ろう。図10はRecordレイヤの動作を模式的に表したものだ。ここでは上位レイヤのメッセージを通信相手に送出するときの動作を示している。

　ひとまず大雑把に見ていこう。上位レイヤから受け取ったデータ（TLSPlaintext）は、最初に圧縮されて、圧縮済みデータ（TLSCompressed）が生成される。次に、そのデータに加えて、データのハッシュ値（またはメッセージダイジェスト値）、また暗号アルゴリズムによってはパディング（Padding：穴埋め）がミックスされる。そしてそのデータに暗号化処理を施して、最終的な形である圧縮・暗号化されたデータ（TLSCiphertext）が生成される。ここまでがRecordレイヤの機能である。

　こうして生成したデータは、さらにRecordレイヤから下位レイヤ（TCP/IP）に引き渡され、TCPパケット／IPパケットとなってネットワークに送出されてゆく。このときに送出されたパケットをネットワークモニタで観察すると、TCPパケットのデータ部分に、この圧縮・暗号化されたデータ(TLSCiphertext)が含まれていることが観察できる（図11）。図では1TCPパケットに1TLSCiphertext構造体が含まれるように描かれているが、場合によっては1つのTCPパケットに複数のTLSCiphertext構造体が含まれる場合もある。

図11　プロトコルレイヤとパケット構造の関係

　また、このRecord Protocolは、その上位に位置するHandshake Protocol、Alert Protocol、Change Cipher Spec Protocol、Application Data Protocolの各プロトコルが通信基盤として利用している。そのため、TLSPlaintext～TLSCiphertextの各データには、これら上位プロトコルが取り扱うデータがそれぞれ含まれることになる。具体的に言えば、Handshake Protocolなどによるネゴシエーション情報はもちろん、Application Data Protocolによるアプリケーションデータにいたるまで、いずれも暗号化の対象である。

　画面1は実際のやりとりをモニタした様子だ。このTCPパケットには、Change Cipher Spec Protocolのデータと、Handshake Protocolのデータが、それぞれ含まれている。各プロトコルのフォーマットは前編に説明があるので、併せてご覧いただくと内容が把握できると思う。

画面1　TLS 1.0での通信をモニタしたところ。Change Cipher Spec ProtocolとHandshake Protocolの各データが観察できる

　なお、このモニタ結果では、Change Cipher Spec Protocolのfragment部分はまだ暗号化されていない。これはSSL/TLS通信の初期状態にあり、まだ暗号化パラメータが決定していないためだ。このChange Cipher Spec Protocolメッセージによって暗号化パラメータが確定し、その後のHandshake Protocolからはfragment部分の暗号化が始まっている。読み取る際にはこの点に注意しておこう。

　ではここでTLS～と表されている各構造体の形を詳しく見ておこう。冒頭でも触れたとおり、TLS～はRecordレイヤ内部でやりとりされるデータの塊である。構造体という言葉は、主にプログラミング言語で使われるもので、単純な型のデータが複数集まって、複雑な情報を構成しているものを指す。ここではデータフォーマットと同意と考えて構わない。

Alert 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 証明書の処理中に何らかの問題が発生して，証明書を受理できないことを通知する access_denied fatal ハンドシェイク中のパラメータが範囲外、または他フィールドと矛盾していることを通知する decode_error fatal 有効な証明書チェーンを受信したが，CA証明書がないか，信頼できるCAでないため受け付けられなかったことを通知する decrypt_error ＊1 フィールド値が範囲外であったり，メッセージの長さに異常があり，メッセージのデコードができないことを通知する export_restriction fatal 輸入規制に従わないネゴシエーションが行われたことを通知する protocol_version fatal 指定されたプロトコルバージョンはサポート対象外であることを通知する insufficient_security fatal クライアントで利用可能な暗号化アルゴリズムよりもより安全なアルゴリズムが必要であることを通知する internal_error fatal メモリアロケーション失敗など，ハンドシェイクとは無関係な理由でネゴシエーションが継続できなくなったことを通知する user_canceled warning ハンドシェイク中にユーザーが処理中止を要求したことを通知する no_renegotiation warning 再ネゴシエーションによるセキュリティパラメータの変更ができないことを通知する ＊1 メッセージ送信者の裁量でwarningかfatalかが決定される

表3　Alert Protocolのメッセージ一覧

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

---

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

暗号化パラメータとHandshake Protocol

暗号化パラメータと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のメッセージフォーマット

SSLとTLSの関係 １

SSLとTLSの関係

　もともとSSLはNetscape Communicatinos社が提唱してきたもので、暗号技術を有効に活用して、インターネットを安全に利用することを目的としたプロトコルだ。SSL 3.0まで同社で開発されたが、インターネット標準とするべく検討の場がIETFに移された。その後、1999年には標準化案がまとまり、TLS 1.0という名称により、RFC2246として公開されることとなった。本稿の執筆現段階でもこのTLS 1.0が最新バージョンである。

　TLS 1.0とSSL 3.0との間に正確な互換性はないが、その仕様の違いはごくわずかなものになっている。実質的にはSSL 3.0のマイナーバージョンアップを行って、RFC化したものがTLS 1.0と考えてよい。実際、TLS 1.0プロトコル中でのバージョン表記は“3.1”となっているくらいである。

　もっとも、インターネットの実情を見ると、TLS 1.0の利用はまだこれからという段階のようである。IE5ではすでにTLS 1.0のコードが入っているが、デフォルトでは利用しない設定になっている。また、Netscape Communicatorは、いまのところTLS 1.0は利用できない。これらから想像する限り、多くのWebアクセスではまだSSL 3.0が利用されているはずである。

　そうは言っても、IEでTLS 1.0を利用できるような設定にして、いくつかのSSLサイトにアクセスしてみると、いずれもTLS 1.0のヘッダが返ってきた。これはWebサーバのTLS化がかなり進んでいることを示していると考えられる。ならばWebブラウザの対応が進むことで、いずれTLS 1.0が標準的に利用されることになる可能性は高い。

　そういった状況を踏まえて、本稿では特に断りがない限りTLS 1.0の仕様（RFC2246）をベースに話を進めてゆく。前述のとおり、TLS 1.0とSSL 3.0とは非常によく似ているので、コンセプトや大部分のパケットフォーマットについては、概ねSSL 3.0にも共通すると考えて構わない。また、言うまでもないが、SSL 3.0の正確な定義が必要な方はSSL 3.0の定義ドキュメントを参照していただきたい。

TCP/IPスタックにおけるSSL/TLS

　まず最初に図2でSSL/TLSのプロトコル的な位置づけを確認しておこう。SSL/TLSを利用しているとき、それらはTCPやUDPなどトランスポート層の直上で、アプリケーション層の直下、つまりトランスポート層とアプリケーション層にサンドイッチされた部分に位置することがわかる。この位置付けから想像できるとおり、SSL/TLSはTCPやUDPが提供する機能（具体的にはソケット）を使用し、そこから得られたデータに何らかのセキュリティ処理を施して、その結果をアプリケーションに引き渡す、という動作を行う。そのため、利用できるアプリケーションが限定されないという特長を備える。図にはアプリケーションを3種類しか描いていないが、本質的にあらゆるアプリケーションでSSL/TLSの機能を利用可能である。

図2　TCP/IP中でのSSL/TLSのポジション

　ここでは、SSL/TLS利用の代表例であるWebブラウザの実装を見てみよう。現在、SSL/TLSに対応する機能は「Webブラウザに組み込む」のが普通となっている。SSL/TLSの位置付けから考えると、OS機能として備えるのが自然なはずだが、SSL/TLSを利用するサービスがWebサービス中心という事情もあって、こういった形の実装になっているようだ。Internet Explorer、Netscape Communicatorいずれもこの考え方は同じである。

　SSL/TLS機能の利用有無の判別は、ユーザーがWebブラウザに指定するURLによって行われる（図3）。「http://～」と書いた場合、SSL/TLS機能は利用せず、OSのTCP/IP機能を直接利用してWebサーバと通信する。また、「https://～」と書いた場合、Webブラウザ機能は、自身が備えているSSL/TLS層機能を介してOSのTCP/IP機能を利用する。そのため通信内容は暗号化され安全な通信を実現するという仕組みである。なお、こうして発生したリクエストをWebサーバ側で容易に判定できるよう、それぞれのリクエストでは異なったTCPのポート番号を利用している。具体的には、前者はhttp本来のポート番号80番、後者は新たに割り当てられた443番をそれぞれ用いる。

図3　WebブラウザにおけるURLとSSL/TLSの関係

　繰り返しになるが、SSL/TLSはWebサービスに限らず多彩なアプリケーションに適用可能である。SSL/TLSが有用なプロトコルとして生き残っているのには、その柔軟性に対する評価も大きいようである。ちなみに、既存サービスをSSL/TLS化したときのポート番号は、現在、表1のようなものが定義されている。

プロトコル名 ポート番号 （TCP/UDP） 説明 https 443 http protocol over TLS/SSL nntps 563 nntp protocol over TLS/SSL（旧snntp） ldaps 636 ldap protocol over TLS/SSL（旧sldap） ftps-data 989 ftp protocol, data, over TLS/SSL ftps 990 ftp protocol, control, over TLS/SSL telnets 992 telnet protocol over TLS/SSL imaps 993 imap4 protocol over TLS/SSL ircs 994 irc protocol over TLS/SSL pop3s 995 pop3 protocol over TLS/SSL（旧spop3）

表1　SSL/TLS化プロトコルとポート番号。Internet Assigned Numbers Authority（IANA）ポート割当リストから、SSL/TLS 化に関するものを抜粋

SSL/TLSのレイヤ構成

　ではSSL/TLS層の内容を更に詳しく見ていこう。図4はSSL/TLS層の内部構造、各レイヤのプロトコル、そして提供する機能を表したものだ。

図4　SSL/TLSのレイヤ構造

　この図を見て最初に気づくことは、SSL/TLS層の中身は大きく2つに分かれているという点かと思う。何気なく眺めていれば、単なる二分割のようにも思えなくもない。だが、機能面の理解が進んでゆくと、この位置がなかなか絶妙な機能境界を提供していることに気づくことになるはずだ。もっとも、この段階ではピンとこないと思うので、どこか頭の隅にでも入れておいていただくとよいだろう。

　SSL/TLS層のうち、下位レイヤで使用されるプロトコルはRecord Protocolと呼ばれている。このプロトコルはSSLの中でも比較的単純かつ基本的な機能を提供するものだ。冒頭で述べた3つのポイントで言えば、「盗聴」と「改ざん」を防止する役割を担っている。

　「盗聴」を防止する機能とは何か。これは「暗号化」機能である。Record Protocolでは、上位レイヤから引き渡されたデータを暗号化し、第三者では内容を理解できない形にしてから、下位にあるTCP/UDP層に引き渡す。逆に、TCP/UDP層から到着したデータは、まず最初にRecord Protocolの中で復号化し、誰もが意味を理解できる形に戻してから、上位レイヤに引き渡す、といった動作をする。

　このような動作を行うことにより、「Record Protocolより下位にあるプロトコル、つまりTCP/IPレベルで運ばれているデータは基本的にすべて暗号化されている」という状況ができあがる。このとき、もしネットワーク上でデータを盗聴されたとしても、残念ながら盗聴内容は第三者に理解できない。つまり、盗聴という行為を実質的に無効化することが可能となるわけである。

　では、もうひとつ「改ざん」の防止はどうだろうか。こちらを実現するには「メッセージダイジェスト」と呼ばれる機能を利用する。メッセージダイジェストは、暗号化に関連した技術の一つで、一言でいえば、文章を機械的に要約したような一連の情報を指す。もし、通信途中で文章が改ざんされれば、その要約値は変わってしまうため、改ざんを検出可能という理屈だ。メッセージダイジェストの正確な説明にはページが必要なので、後ほど詳しく触れることにしよう。

【コラム】 「メッセージダイジェスト」を簡単に説明すると…… 　「そうはいっても、具体的なイメージが湧かないよなぁ」という方のために、ここであえて大胆なたとえをさせていただこう。メッセージダイジェストは、「文章」といっしょに「文章に出現する全文字の画数の合計数」を送るようなもの、という説明だ。総画数だけでは誰でも計算できてしまうので、送り主と受信者だけが知っている「秘密のキーワード」を決めておいて、それも含めた総画数を計算することにしておく。 　文章の送り主は、文章といっしょにその総画数を相手に送る。文章を受信した者は、受信した文章から自分で総画数を計算し、その結果と送信者の送ってきた総画数を比較する。もし、この両者が一致すれば、文章は第三者に改ざんされることなく、安全に届いたと見なすことができる。反対に一致しなければ、文章は通信途中で改ざんされていると考えられる。こんなイメージである。 　実際には、画数の増減を他の部分で相殺可能であったり、秘密のキーワードが逆計算できたりするので、総画数はメッセージダイジェストとしては役立たない。本物のメッセージダイジェストでは、文章本体とダイジェストから、改ざん内容の相殺方法や、秘密のキーワードが想像できない（逆計算困難な）、特別な関数が用いられている。

　一方、SSL/TLS層の上位レイヤには、Handshake Protocol、Alert Protocol、Change Cipher Spec Protocol、Application Data Protocolの4つのプロトコルが含まれる。こちらのレイヤが提供する機能は、「なりすまし」の防止、そして各機能の利用準備を整える機能だ。

　このうち、「なりすまし」の防止には「認証」機能が必要となる。この「認証」とは何か。端的に言えば、あるサーバが本当にそのサーバであることを確認することだ。

　こういったケースは実世界でもよく起こる。役所等に重要な届け出や申請をするときに、運転免許証等の提示を求められた経験をもつ方は多いだろう。これは申請者が本人かどうかを確認するために行われているものだ。ではなぜ、運転免許証を提示すれば本人と認めることができるのか。それは「運転免許証や保険証の発行機関は十分に信用できる」→「そこに書かれている内容は十分に信用できる」→「免許証の写真と実物の顔、免許証の名前と申請者の名前が一致するなら、それは本人に間違いない」というロジックが成り立つからである。つまりこの役所では、自らが苦労して身元調査をしなくても、十分に信頼できる機関での証明を根拠に、本人性の確認ができたと見なすことが可能となるわけだ。

　SSL/TLSでの認証にはいくつかの方法が規定されているが、そのうちもっとも基本的なスタイルがこれと大変よく似たものになっている。つまり、あるサーバが本当にその名前どおりのサーバかどうかの確認は、「十分に信頼できる機関が発行した証明書」を使って行われるのである。具体的には、SSL/TLS通信を開始する最初の段階で、サーバは本人性を証明する証明書をクライアントに提示する。クライアントは、受け取った証明書がニセの証明書でないか、信頼できる証明機関が発行したものかを確認。問題なければそのサーバを信用して暗号化通信の準備を継続実行し、実際のアプリケーション間の通信を開始する、という流れとなってゆく。ご覧のとおり、実世界の出来事によく似ていることがお分かりいただけるだろう。

　上位レイヤのもう1つの機能は「ネゴシエーション」機能である。これは、通信に先立って、通信相手を確認したり、双方が利用できる暗号化アルゴリズムを確認するなど、いわゆる暗号化通信のお膳立てを行う働きを備えている。前出の認証機能も、見方を変えればこのネゴシエーション機能の一部と見なせなくもない。SSL/TLSでの通信を開始するにあたっては、まず最初にこのネゴシエーション機能が働き、必要な合意が交わされた後に、実際のアプリケーション間の通信が始まる。外国人とミーティングをする前に、「何語でミーティングをしましょうか」と、英語メールで相談するようなもの、と見れば理解しやすいかもしれない。

ＳＳＬの安全性

お客様のカード情報入力時には、業界標準の暗号技術であるSSLによって通信が保護されて安全に送信されますので、第三者にその情報が盗み見られる心配はありません。 ゼウス決済サーバーは、第三者機関の日本ベリサイン株式会社により、「サイトの運営主体の実在証明」及び「SSL暗号化通信による情報の保護」が証明されています

オンラインショッピングの安全性を高めるSSLの仕組

【技術分類】

SA75  SSL

NA11  暗号化

PA01  商機能

SA76  SET

【技術の名称】

オンラインショッピングの安全性を高めるSSLの仕組

【技術内容】

ネット広告などを閲覧しインターネット上でショッピングする、所謂オンラインショッピングなどに於いて、電子決済に伴う金銭のやりとりや信用情報の確認方法には認証局が発行する電子証明書がある。しかしながらオンラインショッピングなどで購買者、オンラインサイト、クレジット会社間で購買者の個人情報が送受信される時、電子証明書を購買者が持っているとは限らない。そこで、オンラインショッピングなどを想定したとき、購買者自身が電子証明書を持たないケースを考えた安全性の高いオンラインセキュリティ方法の一つがSSL (注１)である。SSLでは、電子証明書を持っていない購買者は、オンラインショッピングに電子証明書を要求し、その電子証明書を認証局で確認した上で、オンラインショッピングの公開鍵を入手し、注文情報やクレジット番号、個人情報などをオンラインショップの公開鍵で暗号化して送信する。オンラインショップとクレジット会社は、ともに電子証明書の認証を行い、購買者の情報を電子証明書を使って暗号化してやり取りを行なう。但し、このSSL方式では、オンラインショップ側で、購買者の個人情報がすべて見えてしまい、オンラインショッピングでの不正行為の可能性を否定できない。そこで、クレジット情報とオンラインショプで必要とする情報を分けて暗号化したセキュリティシステムが考えられ、それがSET(注２)である。SETによってオンラインショッピングの不正行為の可能性をさらに低くする事が可能となった。以上のように、ネット広告と連動してオンラインショッピングが出来るようなシステムにおいては、SSL或いはSETなどの仕組でオンラインセキュリティを確保する必要がある。下図にSSLの仕組とSETの仕組を示す。

(注1)SSL；Security Socket Layer)

(注2)SET；Secure Electronic Transaction)

【図】

図１  SSL/SSLのしくみ

出典；「SETとSSLのしくみ」、「図解雑学インターネットセキュリティー」、（2001年11月21日）、（株）ユニゾン著、（株）ナツメ発行、SSL/SSLのしくみ

【応用分野】

ネット広告、電子広告、バナー広告

【出典／参考資料】

「図解雑学インターネットセキュリティー」、（2001年11月21日）、（株）ユニゾン著、（株）ナツメ発行、114頁～115頁

●インターネット上暗号方式のSSLとＳＥＴで安全性に差は有るのか

• 使用している暗号。
  • SSL、SETとも現状ベリサインで使用されている暗号はRSAの公開鍵であり、今後よりよい暗号ができ、実用化になれば使用する暗号を変更できるので、暗号の差はない。
• 復号を誰が行うか。
  
  
  • これが、一般的にSETは万全でSSLは安全性に不安がある、といった理由になっている。

SSLの方式

• ｓｓｌはWEB上クライアント（決済利用会員）が入力した情報を現状RSA公開鍵で暗号化されサーバー（加盟店、または決済会社）で復号される。
• この場合、復号された情報が、サーバー上で外部から見る、またはデータを盗まれるといった可能性がある。
• したがって、復号されたデータがちゃんとしたファイアーウォールの内側にあり、かつデータ管理された状態で保管される必要がある。
• 一般的にクレジットカードNO.をSSLでインターネット上流す場合には、復号は加盟店でされることになるためサーバーの技術的プロテクトがなされない場合が多いことと、データ管理がきっちりされていないケースが考えられ,危険性があるといわれる理由となっている。技術的な面はインターネット上、今後加盟店においても、個々にファイアウォール等普及してゆくと考えられるので、加盟店でカード番号等のデータ管理が残された問題となろう。ただし、この問題は、インターネットの問題ではなく、クレジットカードのご利用控えが店に残るというクレジットカード自体の問題点である。
• 復号化、復号後のデータを技術的、人的管理面でも安心できる決済会社のサーバーで行っているのが、電子クレジット、サードパーティー方式、プリペイド方式といった電子決済各社の方式である。
• したがって、これら電子決済はまず万全といってよい。むしろ、リアルのクレジットカードの場合のように加盟店に会員番号が残るといったことがないだけ、より安全といってよい。

SETの方式

setの安全性は基本的に、電子決済各社がSSLで実施しているセキュリティーと同等である。

• 会員のパソコンからＳＳＬと全く同じRSA等の公開鍵で暗号化された個人情報（この場合カードナンバーではなくSETの登録ナンバー）が最終的に技術的、人的管理のなされている、カード発行会社のサーバーで復号化される。
• ただし、SETの場合は、情報がいくつかの中間のルート（加盟店、認証機関、加盟店管理会社）を経た上で、会員から発行会社まで流れる。このため各電子決済方式より中間ルートで復号されない処置や、データ盗難の防止を図る必要がある。
• 加盟店、加盟店管理会社、認証機関で必要な情報だけを復号するといったために、単なる暗号署名でなく、２重の暗号署名が必要であったり、ＷＡＬＬＥＴへの登録内容についても、項目や、処理の仕方が複雑になっており、その場その場での、セキュリティー確保と復号化されたデータの保全策が数多く必要になってきている。

--------------------------------------------------------------------------

連載　携帯通信技術トレンド

第2回　SSL／TLS（Part.1-1）

福永勇二
インタラクティブリサーチ
2000/07/15

「盗聴」「改ざん」「なりすまし」

　インターネットが我々の生活基盤として浸透するにつれて、多くの人がその安全性を重要視するようになってきた。いわゆる電子商取引（EC）はもちろんのこと、個人間での私的な情報のやりとりにおいても、その重要性は日増しに高まっている。

　インターネットの安全性とは何だろうか。それは大きく3つのポイントに絞られる。

1. 通信相手は本人に間違いないか
2. 通信内容が他人に盗み読まれないか
3. 通信中に内容が改ざんされていないか

である。これらのポイントが、インターネットの安全性を考える上で重要となる訳は、話を電話にたとえてみると分かりやすい。

　次の図1では、左の女性が通信販売会社「AtMark通販」に電話をして、お気に入りの赤ワインを1本、クレジットカードで購入しようとしている。日常的にもよくあるシチュエーションだ。この図の中には、前出の3つの観点から安全性を損なう要素が盛り込んである。

図1　「盗聴」「改ざん」「なりすまし」の例

　まず左下の男。この男は通話内容を「盗聴」しており、ここでは通話から男性のカード番号を知ることができる。たとえば、この男が盗聴によって知り得たカード番号を使って、通信販売で商品を購入すれば、カードの不正利用は簡単に成立してしまう。AtMark通販にしてみれば、誠実にカードの処理を行っているにもかかわらず、いらぬ嫌疑が掛けられ信用を落としかねない。

　次が中央上の男。この男は、電話回線の通話の一部を差し替えることで、左の女性の通話内容を「改ざん」している。もし、赤ワインの注文個数が1本から100本に改ざんされたら、女性のうちにはワイン100本が届き、カードから100本分の代金が引き落とされる。女性は二度とこの通信販売会社を利用しないだろうし、通信販売会社は代金を回収できないリスクを背負うことになる。

　そして最後が右下の男だ。この男は「悪徳商事」の社員であるにもかかわらず、あたかも「AtMark通販」であるかのように名乗っている。「なりすまし」である。男性は何の疑いもなく注文商品とカード番号を伝え、何事もなく注文を終えるが、残念ながら頼んだワインは届かない。そして、伝えたカード番号は不正に利用されてしまう。これもやはり女性と通販会社の両者にとって不幸な出来事になってしまう。

　もし、こういった悪事を未然に防ぐことができれば、その通信システムは安全性が高い、ということは容易に理解できるだろう。同様な考え方はインターネットについても当てはまり、その結果、冒頭に挙げた3つのポイントが重要となってくるわけである。

不正アクセスを 　どうやって未然に防ぐか？

　こんな話を聞くと、現存の電話システムが危険に思えてくる人もいるだろう。事実、これらが技術的に実現可能かとの問いには「可能である」という答えが正しい。だが、現実にこういったことはまず起きない。その理由の1つは、悪事を実行し得る大掛かりな仕掛けや体制を準備して、無署名で使える範囲のクレジットカード番号を手に入れても、一向に割が合わないという極めて現実的な点にある。大企業間の産業スパイや、政党間の謀略等はともかく、一般市民が普通に電話を利用して、こんなトラブルに巻き込まれる可能性は極めてまれだろう。

　だが、インターネットに関して言えば、一般市民がこういったトラブルに巻き込まれる可能性は少なからずある。たとえば、さまざまな情報が大量に集中するISPの周辺は、悪事を働くものにとっての絶好のウィークポイントである。ISPを狙った悪事は、必要な仕掛けが比較的簡単なもので済むことから、コストや体制は十分な抑止力になりにくい。現在のISP数は、日本国内に4000以上、全インターネットでは膨大な数に昇る。大部分のISPは誠実かつ慎重にサービスを提供していると信じたいが、それを持ってウィークポイントが多いという事実を覆すには至らない。こういった事情をはじめとして、インターネットのオープン性の高さを考えると、電話システムでは縁のなかったトラブルに、一般市民が現実に遭遇する可能性が生じると考えるのが賢明と言える。

　そこで脚光を浴びるのが、これから解説するSSL（Secure Socket Layer）とTLS（Transport Layer Security）である。これらは、インターネットで発生する「盗聴」「改竄」「なりすまし」といったトラブルを、利用者サイドで回避しようとする技術だ。EC（Electronic Commerce）を実現する基盤技術としても、ここのところ注目度は相当に高い。ただ、その中核をなすものが比較的なじみの薄い「暗号化技術」ということもあり、一般的に、その壁は低いものではなかった。そこで本稿では、暗号技術が分かる方はしっかりと、そうでない方もそれなりに理解できるよう、平易かつ詳細にSSL/TSLを解説することを試みる。

●本記事をお読みいただく前に● 　誰もが自分のレベルに応じてSSL/TLSを理解していただくため、本稿はSSL/TLSの実像を概ね2つの部分に分けて説明する方針をとっている。前半はおもにSSL/TLSの全体構成に関わる説明、そして後半がSSL/TLSで利用する暗号化アルゴリズムやその選択に関する説明である。スパゲッティのように暗号化技術の話しが絡み合い、なんだか難しそうに見えるSSL/TLSだが、よくドラフトを読んでみると、全般が複雑怪奇なわけではない。ややこしい部分とそうでない部分が混在しているだけである。それらを分類／整理することで、大雑把ながら全体を2部構成にまとめてみた。 　前半部分を理解するのに暗号技術に関する知識はあまり必要ない。だが、この部分がSSL/TLSの屋台骨の説明である点には変わりなく、前半部分を読むだけでSSL/TLSのカタチが浮かび上がってくるはずである。一方、後半部分を読み進めるには、暗号技術に関する知識がそれなりに必要となる。こちらでは、前半部分の知識をベースにしつつ、暗号技術の種類やその特性に関する知識も加えながら、SSL/TLSの深い部分を明らかにしてゆく。

「連載　携帯通信技術トレンド」