暗号化通信制御装置
【課題】サーバから受信したパケットを暗号化通信制御装置が暗号化する際に、パケットを溜め込まずに暗号に関する処理を行う。
【解決手段】サーバ（５）からのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加した暗号化を行い、その暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段（３）を備え、暗号化送信手段（３）は、サーバ（５）と相手先との間のコネクション確立時にサーバ（５）と相手先との間で転送されるデータのサイズをサーバ（５）からのパケットをブロック暗号化して相手先にひとつのパケットで送信できるサイズに設定し、その後、サーバ（５）から転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで相手先に送信する。
【解決手段】サーバ（５）からのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加した暗号化を行い、その暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段（３）を備え、暗号化送信手段（３）は、サーバ（５）と相手先との間のコネクション確立時にサーバ（５）と相手先との間で転送されるデータのサイズをサーバ（５）からのパケットをブロック暗号化して相手先にひとつのパケットで送信できるサイズに設定し、その後、サーバ（５）から転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで相手先に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサーバへのセキュリティを確保したアクセス方法として用いられているセキュリティプロトコルであるＳＳＬ（セキュア・ソケット・レイヤ）の処理に関する。
【背景技術】
【０００２】
ＳＳＬでは、アプリケーション層のデータを暗号化し、それをトランスポート層であるＴＣＰ（トランスミッション・コントロール・プロトコル）のパケットに分割して転送する。受信側では、複数のＴＣＰパケットから暗号化データを組み立て、復号化し、ＭＡＣ（メッセージ認証コード）を計算して改竄されていないことを確認する。
【０００３】
ＳＳＬあるいは暗号化通信技術としては、以下の文献があるが、これらは本願発明にとって一般的な背景技術である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−０７７１５０号公報
【特許文献２】特開２００３−０２２３２１号公報
【特許文献３】特開２００３−０９２６０４号公報
【特許文献４】特開２００３−５０４７１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のＳＳＬでは、暗号化データがＴＣＰに分割されて転送されるため、受信側では、分割された全てのパケットを受信してからでないと、ＳＳＬの処理ができない。このため、遅延が発生してしまう。特にＷｅｂサイトのようにアクセスが集中するサーバでは、組み立てに伴う遅延やバッファメモリの消費によってパフォーマンスが低下してしまう。また、中継点でＳＳＬを処理する場合には、その処理の後に再び分割して転送する必要がある。
【０００６】
本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、サーバからのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加したブロック暗号化を行い、そのブロック暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段を備えた暗号化通信制御装置において、暗号化送信手段は、サーバと相手先との間のコネクション確立時にサーバと相手先との間で転送されるデータのサイズをサーバからのパケットをブロック暗号化して相手先にひとつのパケットで送信できるサイズに設定し、その後、サーバから転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで相手先に送信することを特徴とする。
【発明の効果】
【０００８】
本発明によると、サーバから受信したパケットを暗号化通信制御装置が暗号化する際に、パケットを溜め込まずに暗号に関する処理を行うことができ、組み立てに伴う遅延やバッファメモリの消費によるパフォーマンスの低下を低減できる効果がある。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態を示すブロック構成図である。
【図２】この実施の形態で用いられる暗号化および復号化を説明する図である。
【図３】ＳＳＬフォーマットを示す図である。
【図４】従来の組み立て、復号化およびハッシュ計算の処理手順を説明する図である。
【図５】暗号化されたデータを溜め込むことなく復号化する処理手順を説明する図である。
【図６】送信時のＴＣＰフォーマットを説明する図である。
【図７】復号回路の詳細を示すブロック構成図である。
【図８】暗号回路の詳細を示すブロック構成図である。
【図９】ＳＳＬ受信バッファの処理のフローチャートである。
【図１０】復号化スケジューラの処理のフローチャートである。
【図１１】平文メモリの処理のフローチャートである。
【図１２】ハッシュスケジューラの処理のフローチャートである。
【図１３】コネクション確立のシーケンスを示す図である。
【図１４】平文受信バッファの処理のフローチャートである。
【図１５】暗号化／ハッシュスケジューラの処理のフローチャートである。
【発明を実施するための形態】
【００１０】
図１は本発明の実施の形態を示すブロック構成図である。本発明は、図１に示すような、インターネット４からサーバ５に向かうＳＳＬトラフィックを復号化し、サーバ５からインターネット４へ出て行くトラフィックを暗号化するＳＳＬ通信装置１で実施される。このＳＳＬ通信装置１は、インターネット４からサーバ５への受信プロセスを担当する復号回路２と、サーバ５からインターネット４への送信プロセスを担当する暗号回路３とからなる。本発明は、特に、サーバからインターネット４へのトラフィックの暗号化に関するものである。
【００１１】
図２はこの実施の形態で用いられる暗号化および復号化を説明する図である。ＳＳＬ通信装置１とインターネット４との間の通信はＳＳＬで行なわれ、暗号ブロックと呼ばれるまとまりごとに暗号化を行なうブロック暗号が用いられる。このとき、前のブロックの暗号結果を用いて、次のブロックの暗号化を行なう。復号化の時には、送信した順にパケットを受け取れば、順次復号することができる。
【００１２】
図３はＳＳＬフォーマットを示す。ＳＳＬブロックは、ＳＳＬヘッダ、ペイロード、ＭＡＣ（メッセージ認証コード）、パディングおよびパディング長により構成される。データ部分（ペイロード）は最大１８ＫＢまで許容されており、このデータ全体にわたってハッシュ値を計算して、ＳＳＬ内のＭＡＣと比較することで改竄の有無を調べる。このＳＳＬのデータ長に比べてＴＣＰパケットのデータ長は短いので、ひとつのＳＳＬデータが複数のパケットに分割されて転送されることになる。このため、受信側ではそれらのすべてのパケットを受信しないと、そのデータの信頼性を確認できないことになる。
【００１３】
図４は従来の組み立て、復号化およびハッシュ計算の処理手順を説明する図であり、図５は暗号化されたデータを溜め込むことなく復号化する処理手順を説明する図である。ＳＳＬはＴＣＰに分割されて転送されるため、受信側ではそれを組み立ててから処理する必要があった。すなわち、まず、ＴＣＰにセグメント分けされた暗号文を組み立て、復号化し、ハッシュ計算を行なって改竄がないかどうかを確認していた。これに対して本実施の形態では、暗号アルゴリズムは受信次第復号化が可能であることに着眼し、パケットの組み立てを行いながら、復号化およびハッシュ計算のうち可能な処理を先行して実施する。これにより、遅延が低減される。
【００１４】
図６は本実施の形態における送信時のＴＣＰフォーマットを説明する図である。自分が受信側であるときには、送り手のデータ長が制御できないことから、上述した処理により高速化を図る。一方、送信時には、データ長の制御が可能である。そこで、アプリケーション層のデータを暗号化してからＴＣＰで送るのではなく、データを分割してからＳＳＬで暗号化し、ＩＰヘッダおよびＴＣＰヘッダを付加してひとつのＴＣＰパケットにする。これにより受信側では、パケット毎の復号および検証が可能となる。
【００１５】
図７は復号回路２の詳細を示すブロック構成図である。この復号回路２は、識別部２０１、ＳＳＬ受信バッファ２０２、復号化スケジューラ２０３、復号化処理部２０４、平文メモリ２０５、ハッシュスケジューラ２０６、ハッシュ計算処理部２０７、ハッシュメモリ２０８、平文送信処理部２０９およびセッションテーブル２１０を備える。
【００１６】
識別部２０１は受信したトラフィックがどこからきたものであるかを判別する。この識別されたトラフィックをフローと呼ぶ。識別部２０１で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはＳＳＬ受信バッファ２０２に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ２０３でスケジュールされ、復号化処理部２０４で復号化処理される。ここまではパケットが到着しだい実行されるが、回線状態が悪くパケット順序が入れ替わってしまった場合は、次に来るべきパケットが来るまで復号化は実行されない。復号化処理部２０４による復号化処理を終えたデータは平文メモリ２０５に格納される。ハッシュアルゴリズムで決められた長さが復号化されると、平文メモリ２０５からその長さのデータがハッシュスケジューラ２０６によってスケジューリングされ、ハッシュ計算処理部２０７によりハッシュ処理される。ハッシュ計算の結果は、次のハッシュ処理のときに使うためにハッシュメモリ２０８に保存される。すべての処理が終わったときにハッシュメモリ２０８に残っている値がハッシュの計算結果である。ＳＳＬブロック（図３参照）がすべて復号化され、ハッシュ計算とＭＡＣ値が一致すれば改竄されていないことになり、平文送信処理部２０９によりサーバ５への送信処理が行われる。この際、ＳＳＬのために付加されたＭＡＣやパディングは取り除かれる。
【００１７】
セッションテーブル２１０は、ＳＳＬの通信で使われるセッション／コネクションの情報を保持し、計算の際に各部に情報を渡す。この情報に変更があるとセッションテーブル２１０に反映される。
【００１８】
図８は暗号回路３の詳細を示すブロック構成図である。この暗号回路３は、識別部３０１、平文受信バッファ３０２、暗号化／ハッシュスケジューラ３０３、ハッシュ計算処理部３０４、暗号化処理部３０５、ハッシュメモリ３０６、暗号文メモリ３０７、暗号文送信処理部３０８およびセッションテーブル３０９を備える。
【００１９】
識別部３０１はサーバからのフローを判定する。識別されたフローは平文受信バッファ３０２に格納される。本実施例において暗号化側は単一パケットでＭＡＣの付加および暗号化が完結するように調整を行うため、復号回路２とは違って各フローにバイト単位でのスケジューリングは行わず、暗号化可能なパケットが入力されると、そのパケットの暗号化を最後まで行う。もし、パケットの順序が入れ替わった場合は正しいパケットが来るまで待つことになる。正しいパケットが来た段階で暗号化を行う。フロー毎に１パケットずつ暗号化が順に行われる。暗号化／ハッシュスケジューラ３０３は、平文の最後の部分にＭＡＣを付加する必要があるので、その手前まではハッシュ計算処理部３０４によるハッシュ計算と暗号化処理部３０５による暗号化と同時に進め、最後の部分で待ち合わせをするように調節し、暗号化を完了させる。ハッシュ計算処理部３０４およびハッシュメモリ３０６の処理はハッシュ計算処理部２０７およびハッシュメモリ２０８の処理と同等である。暗号化処理部３０５は、暗号化／ハッシュスケジューラ３０３に調節されながら暗号処理を行い、完了すると暗号文送信処理部３０８にデータを渡し、インターネット４へ転送される。
【００２０】
セッションテーブル３０９は、ＳＳＬの通信で使われるセッション／コネクションの情報を保持し、計算の際に各部に情報を渡す。この情報に変更があるとセッションテーブル３０９に反映される。
【００２１】
図７に示した復号回路２の動作についてさらに詳しく説明する。
【００２２】
図９はＳＳＬ受信バッファ２０２の処理のフローチャートを示し、図１０は復号化スケジューラ２０３の処理のフローチャートを示す。これらの処理は復号化処理部２０４の処理に連動する。
【００２３】
ＳＳＬ受信バッファ２０２では、ＴＣＰで運ばれてきた図３に示したようなＳＳＬブロックを格納する。このとき、ＳＳＬヘッダから読み取れられＳＳＬブロックの長さをＳＳＬ＿Ｌｅｎｇｔｈ、先頭から入れ替わることなく連続受信できているバイト数をＤｃ、復号化スケジューラ２０３にすでに要求を完了している復号バイト数をＤｐ、暗号アルゴリズムによって決まる復号化の単位となるバイト数をＤｄｅｃとする。
【００２４】
ＳＳＬ受信バッファ２０２は、受信開始後、ＳＳＬ暗号データをネットワークより受信し（ステップＡ１）、それがＳＳＬブロックの先頭であれば（ステップＡ２）そのブロック用の領域を確保し、ＳＳＬ＿Ｌｅｎｇｔｈ、Ｄｃ、Ｄｐ、Ｄｄｅｃの初期値を設定する（ステップＡ３）。連続受信できているバイト数から既に処理要求を完了しているバイト数を差し引いた値が処理単位のバイト数よりも大きければ（ステップＡ４）、復号化スケジューラ２０３に復号化処理要求を行う（ステップＡ５）。パケットの入れ替えなどで間があいた後でその間のデータを受信すると、連続受信バイト数が急に増えるため処理単位の数倍が一度に復号処理要求される。ＳＳＬブロックがちょうど処理単位の整数倍とは限らないため、最後の領域は連続受信バイト数がＳＳＬブロック長と一致したところで（ステップＡ６）復号処理要求を行う（ステップＡ７）。以降、この処理を繰り返す。
【００２５】
フローには番号を付けて区別する。これをフロー識別子Ｆｌｏｗ＿Ｎｏとする。復号化スケジューラ２０３が復号処理要求を受けているバイト数をＱ（Ｆｌｏｗ＿Ｎｏ）、フローに割り当てられている一回あたりの復号化バイト数をＵｎｉｔ（Ｆｌｏｗ＿Ｎｏ）、今回復号化するバイト数をＤｅｃ＿ｓｉｚｅ、ＳＳＬ通信装置１がサポートしている最大フロー数をＦｌｏｗ＿ｍａｘとする。
【００２６】
図１０に示すように、復号化スケジューラ２０３が処理要求の受付を開始すると、まずＦｌｏｗ＿Ｎｏの１から（ステップＢ１）Ｆｌｏｗ＿ｍａｘまでを順に調べていく。復号要求があれば（ステップＢ２）、処理すべきバイト数を決定し（ステップＢ３）、ＳＳＬ暗号文のうちこのバイト数分を復号する（ステップＢ４）。ＳＳＬブロック全体を復号化し終えたら（ステップＢ５）該当ＳＳＬブロックのバッファを開放する（ステップＢ６）。復号処理を終えるか、または処理要求が無かった場合は次のフローについて処理要求が無いか調べる（ステップＢ７）。これを全てのフローについて行い、以降、繰り返す。
【００２７】
復号化処理部２０４は、復号化スケジューラ２０３のトリガを受けて動作し、復号した平文を平文メモリ２０５に送る。
【００２８】
図１１は平文メモリ２０５の処理のフローチャートを示し、図１２はハッシュスケジューラ２０６の処理のフローチャートを示す。これの処理は、ハッシュ計算処理部２０７、ハッシュメモリ２０８の処理に連動する。
【００２９】
平文メモリ２０５は、復号化処理部２０４で復号された平文を格納する。平文ブロックの長さをＰｌａｉｎ＿Ｌｅｎｇｔｈ、復号化処理部２０４から受信済みのバイト数をＤ＿ｐｌａｉｎ、ハッシュスケジューラ２０６にすでに要求を完了しているバイト数をＤ＿ｈａｓｈ、ハッシュアルゴリズムによって決定されるハッシュ計算処理の単位となるバイト数をＤｃａｌとする。
【００３０】
平文メモリ２０５では、平文を復号化処理部２０４より受信すると（ステップＣ１）、それがその平文ブロックで先頭であるときは（ステップＣ２）、Ｐｌａｉｎ＿Ｌｅｎｇｔｈ、Ｄ＿ｐｌａｉｎ、Ｄ＿ｈａｓｈ、Ｄｃａｌの初期値を設定する（ステップＣ３）。
現在の仕様ではＳＳＬに圧縮アルゴリズムが規定されていないため、Ｐｌａｉｎ＿Ｌｅｎｇｔｈ＝ＳＳＬ＿Ｌｅｎｇｔｈとなる。ハッシュを計算するバイト数が蓄積していれば（ステップＣ４）、ハッシュスケジューラ２０６に計算処理要求を出す（ステップＣ５）。平文ブロックの最後は、必ずしも計算単位となるバイト数になるとは限らないため、ブロック長分受信したところで（ステップＣ６）処理要求を出す（ステップＣ７）。平文はＭＡＣ検査後にサーバと送達確認を行うため、この段階ではバッファを開放しない。以降、受信、ハッシュ処理要求を繰り返す。
【００３１】
ハッシュスケジューラ２０６は、復号化スケジューラ２０３と同様の動きをする。スケジューリングの受付を開始すると、各フローのハッシュ処理要求を順に確認する（ステップＤ１）。ハッシュ計算処理要求バイト数をＱｈ（Ｆｌｏｗ＿Ｎｏ）とし、フローに割り当てられた一回当たりのハッシュ計算バイト数を Ｕｎｉｔｈ（Ｆｌｏｗ＿Ｎｏ）、今回ハッシュ計算を行うバイト数をＣａｌ＿ｓｉｚｅとする。ハッシュ計算要求があるかを調べ（ステップＤ２）、ある場合は処理バイト数を決定する（ステップＤ３）。フローに該当する情報をセッションテーブル２１０やハッシュメモリ２０８から得て、Ｃａｌ＿ｓｉｚｅの平文でハッシュを計算するようにハッシュ計算処理部２０７を制御し（ステップＤ４）、ハッシュメモリ２０８に記録する。ハッシュの計算が終了しているかを調べ（ステップＤ５）、終了していればＭＡＣとの比較を行い、改竄の有無について検証を行うよう制御する（ステップＤ６）。これが終了したら次のフローについて調べ、全てのフローを見終わると、再び１番目のフローから調べていく。
【００３２】
ハッシュ計算処理部２０７はハッシュメモリ２０８に計算結果を書き込み、これが次のハッシュ計算の際の入力となる。最後にハッシュメモリ２０８内に残るのがハッシュ計算の結果となる。改竄されていないことが確認されたら、平文送信処理部２０９が平文をサーバ５に向かって転送する。
【００３３】
次に、図８に示した暗号回路３の動作について詳しく説明する。
【００３４】
暗号回路３ではサーバ５からインターネット４向けの通信を暗号化するが、暗号化した後も、図３に示したようなＳＳＬブロックが図６に示したようにＩＰ（インターネット・プロトコル）ヘッダおよびＴＣＰヘッダを付加した上で１パケットに収まるように、あらかじめ調節を行う。暗号化する際に付加されるのはＳＳＬヘッダとパディングであるので、サーバ５が送り出すパケットをあらかじめこの長さだけ短くしておけばよい。このためには、ＴＣＰコネクション確立の過程で図１３に示すシーケンスを用いる。
【００３５】
図１３はインターネット４を経由してサーバ５へアクセスしてくるユーザとのコネクション確立のシーケンスを示す。ユーザからＴＣＰのＳＹＮパケットが送られてくると、ＳＳＬ通信装置１は、ユーザとサーバ５との間にＴＣＰコネクションを確立するために、次のように動作する。まず、ユーザとサーバそれぞれに対し、ＩＰヘッダのＤＦ（フラグメント禁止）ビットを立てて送信し、パスＭＴＵ（最大転送ユニット）を求める。ＳＳＬ通信装置１はユーザ側とサーバ５側でＳＳＬで暗号化してもパスＭＴＵを越えないように、ＴＣＰのハンドシェークでＭＳＳ（最大セグメントサイズ）を適切な値に設定する。この値を通知しながらＴＣＰコネクションの確立を行う。
【００３６】
図１４は平文受信バッファ３０２の処理のフローチャートを示す。サーバ５から平文の受信を開始すると、該当フローのバッファに格納する（ステップＥ１）。次に暗号化するべきパケットを受信できていれば（ステップＥ２）、ハッシュ計算と暗号化処理を暗号化／ハッシュスケジューラ３０３に要求する（ステップＥ４）。パケット順序が正しくなければ、バッファに入れて次のパケットを待つ（ステップＥ３）。暗号化／ハッシュスケジューラ３０３には、バッファの開始位置と、データサイズ、フロー番号などを伝える。そして、次のパケットを待つ。
【００３７】
図１５は暗号化／ハッシュスケジューラ３０３の処理のフローチャートを示す。暗号化／ハッシュスケジューラ３０３はデータサイズからＭＡＣ無しで可能な暗号化範囲を求め、ハッシュ計算とＭＡＣ付加前の暗号化を並列に実行するように制御する（ステップＦ１）。双方の終了を受けて、ハッシュ値をＭＡＣとして平文の残りに付加し、残りの暗号化を行うよう制御する（ステップＦ２）。そして、次の要求が無いかを調べる。暗号化／ハッシュスケジューラ３０３は受け取ったパケットについては一度に処理を済ませてしまう。復号化時のようにあるバイト分処理したところで処理を中断するということは無い。また、フローを順に調べることもない。来た順番に処理することで高速化を図る。ＴＣＰのフロー制御で送信データ量を制御する。これらはパケット単位で処理を完結できることから可能になっている。
【００３８】
ハッシュ計算においてはハッシュメモリ３０６に、暗号化においては暗号文メモリ３０７にデータが格納される。暗号化が終了すると、暗号文メモリ３０７から該当パケットがインターネット４に転送される。
【００３９】
以上説明した実施の形態では、復号回路２は、改竄を調べるためにＭＡＣの検証が終わるまでは受信パケットを平文メモリ２０５に保持し、検証が終わるのを待たないといけない。この点について、少し工夫を加えることで、さらに高速に動作できる可能性がある。
【００４０】
すなわち、ハッシュ計算の終了した平文について、平文メモリ２０５でのバッファをせずにすぐにサーバ５に送信する。ハッシュの計算は順次実施することが可能なため、先に来たものから順に転送することができる。この方法だと、平文ブロックをバッファリングしないため、パケット毎に処理したときと同じくらい高速化できる。この際、最後のパケットのハッシュ検証中に改竄が発見された場合、平文送信処理部２０９はこのパケットを廃棄し、サーバ５への再送も行わずにタイムアウトを待つ。タイムアウトは比較的長い時間を要するが、あまり改竄の頻度が高くない状況においては有用である。ただし、最後のパケットを廃棄しても、先に届いてしまったパケットについては順次読み込んでしまうようなサーバ実装の場合は問題になる可能性もあり、機種依存性が存在する。
【００４１】
平文ブロックのバッファリングを行なわないことで、改竄の発生しないほとんどの場合には従来よりも大幅に高スループット、低遅延が得られ、改竄の発生したときのみタイムアウト待ちに伴う性能低下が起こる。図７に示した構成では、改竄のあったパケットがサーバ５に届くことは無く、セキュリティ強度は高いといえる。それに対し、平文ブロックのバッファリングを行なわない場合には、改竄のあったパケットが一部サーバ５に届いてしまうためやや危険があるが、高速な通信が可能となる。
【００４２】
本実施の形態によれば、受信復号化時に、ＳＳＬブロックを構成する全てのパケットの到着を待たずに処理を開始できる。これにより、プロセッサなどの非稼動時間を減らし、その性能を充分に活用できる。また、パケット順序の入れ替わりなどで復号処理が出来なかったフローの分の空いている処理リソースを別のフローが利用することができるため、処理部の動作率は向上し、性能を無駄なく使うことが出来る。
【００４３】
また、暗号化送信時には、ユーザからサーバまで一貫してパスＭＴＵを越えず、ＳＳＬ化しても１パケットに収まるパケットのやり取りが可能となる。パスＭＴＵを越えないパケットを扱うことで、ＳＳＬ化に伴うフラグメントを防止し、それにともなう性能低下が他の性能まで犠牲にすることを防ぐことができる。これにより、暗号化処理部の性能を生かすことが可能になる。
【００４４】
また、単一パケットで暗号化／復号化を完結すると、組み立てや分解の処理負荷や遅延が生じない。ＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）をＳＳＬに渡して暗号化し、それをＴＣＰが分割すると、復号化の段階で組み立て処理が必要となるが、ＨＴＴＰをあらかじめ分割した上でＳＳＬ化し、ＴＣＰで転送すると、組み立て無しにＳＳＬ復号化ができ、ＨＴＴＰでデータの終了位置を検出する、あるいはＴＣＰコネクションの切断でデータの終了とみなすことで、もとのデータが得られる。
【００４５】
さらに、ＳＳＬ通信装置がＨＴＴＰを分割したＴＣＰパケットをサーバから受け、ＨＴＴＰの組み立てを行わずに送信データとみなしてＳＳＬ処理を行う場合には、あらかじめセグメントサイズを最適にしてサーバから受けるため、ＳＳＬ通信装置で分割するよりもデータの収容効率が良いという利点もある。
【００４６】
さらに本実施の形態では、暗号処理部の動作率の向上を図るとともに、双方向に遅延と処理負荷の低減を図っており、バッファに必要なメモリ量を削減することができる。これにより、余裕の出たメモリでより多くのセッション情報を保持することも可能となる。
【符号の説明】
【００４７】
１ ＳＳＬ通信装置
２ 復号回路
３ 暗号回路
４ インターネット
５ サーバ
２０１、３０１ 識別部
２０２ ＳＳＬ受信バッファ
２０３ 復号化スケジューラ
２０４ 復号化処理部
２０５ 平文メモリ
２０６ ハッシュスケジューラ
２０７、３０４ ハッシュ計算処理部
２０８、３０６ ハッシュメモリ
２０９ 平文送信処理部
２１０、３０９ セッションテーブル
３０２ 平文受信バッファ
３０３ 暗号化／ハッシュスケジューラ
３０５ 暗号化処理部
３０７ 暗号文メモリ
３０８ 暗号文送信処理部
【技術分野】
【０００１】
本発明は、Ｗｅｂサーバへのセキュリティを確保したアクセス方法として用いられているセキュリティプロトコルであるＳＳＬ（セキュア・ソケット・レイヤ）の処理に関する。
【背景技術】
【０００２】
ＳＳＬでは、アプリケーション層のデータを暗号化し、それをトランスポート層であるＴＣＰ（トランスミッション・コントロール・プロトコル）のパケットに分割して転送する。受信側では、複数のＴＣＰパケットから暗号化データを組み立て、復号化し、ＭＡＣ（メッセージ認証コード）を計算して改竄されていないことを確認する。
【０００３】
ＳＳＬあるいは暗号化通信技術としては、以下の文献があるが、これらは本願発明にとって一般的な背景技術である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−０７７１５０号公報
【特許文献２】特開２００３−０２２３２１号公報
【特許文献３】特開２００３−０９２６０４号公報
【特許文献４】特開２００３−５０４７１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のＳＳＬでは、暗号化データがＴＣＰに分割されて転送されるため、受信側では、分割された全てのパケットを受信してからでないと、ＳＳＬの処理ができない。このため、遅延が発生してしまう。特にＷｅｂサイトのようにアクセスが集中するサーバでは、組み立てに伴う遅延やバッファメモリの消費によってパフォーマンスが低下してしまう。また、中継点でＳＳＬを処理する場合には、その処理の後に再び分割して転送する必要がある。
【０００６】
本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、サーバからのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加したブロック暗号化を行い、そのブロック暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段を備えた暗号化通信制御装置において、暗号化送信手段は、サーバと相手先との間のコネクション確立時にサーバと相手先との間で転送されるデータのサイズをサーバからのパケットをブロック暗号化して相手先にひとつのパケットで送信できるサイズに設定し、その後、サーバから転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで相手先に送信することを特徴とする。
【発明の効果】
【０００８】
本発明によると、サーバから受信したパケットを暗号化通信制御装置が暗号化する際に、パケットを溜め込まずに暗号に関する処理を行うことができ、組み立てに伴う遅延やバッファメモリの消費によるパフォーマンスの低下を低減できる効果がある。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態を示すブロック構成図である。
【図２】この実施の形態で用いられる暗号化および復号化を説明する図である。
【図３】ＳＳＬフォーマットを示す図である。
【図４】従来の組み立て、復号化およびハッシュ計算の処理手順を説明する図である。
【図５】暗号化されたデータを溜め込むことなく復号化する処理手順を説明する図である。
【図６】送信時のＴＣＰフォーマットを説明する図である。
【図７】復号回路の詳細を示すブロック構成図である。
【図８】暗号回路の詳細を示すブロック構成図である。
【図９】ＳＳＬ受信バッファの処理のフローチャートである。
【図１０】復号化スケジューラの処理のフローチャートである。
【図１１】平文メモリの処理のフローチャートである。
【図１２】ハッシュスケジューラの処理のフローチャートである。
【図１３】コネクション確立のシーケンスを示す図である。
【図１４】平文受信バッファの処理のフローチャートである。
【図１５】暗号化／ハッシュスケジューラの処理のフローチャートである。
【発明を実施するための形態】
【００１０】
図１は本発明の実施の形態を示すブロック構成図である。本発明は、図１に示すような、インターネット４からサーバ５に向かうＳＳＬトラフィックを復号化し、サーバ５からインターネット４へ出て行くトラフィックを暗号化するＳＳＬ通信装置１で実施される。このＳＳＬ通信装置１は、インターネット４からサーバ５への受信プロセスを担当する復号回路２と、サーバ５からインターネット４への送信プロセスを担当する暗号回路３とからなる。本発明は、特に、サーバからインターネット４へのトラフィックの暗号化に関するものである。
【００１１】
図２はこの実施の形態で用いられる暗号化および復号化を説明する図である。ＳＳＬ通信装置１とインターネット４との間の通信はＳＳＬで行なわれ、暗号ブロックと呼ばれるまとまりごとに暗号化を行なうブロック暗号が用いられる。このとき、前のブロックの暗号結果を用いて、次のブロックの暗号化を行なう。復号化の時には、送信した順にパケットを受け取れば、順次復号することができる。
【００１２】
図３はＳＳＬフォーマットを示す。ＳＳＬブロックは、ＳＳＬヘッダ、ペイロード、ＭＡＣ（メッセージ認証コード）、パディングおよびパディング長により構成される。データ部分（ペイロード）は最大１８ＫＢまで許容されており、このデータ全体にわたってハッシュ値を計算して、ＳＳＬ内のＭＡＣと比較することで改竄の有無を調べる。このＳＳＬのデータ長に比べてＴＣＰパケットのデータ長は短いので、ひとつのＳＳＬデータが複数のパケットに分割されて転送されることになる。このため、受信側ではそれらのすべてのパケットを受信しないと、そのデータの信頼性を確認できないことになる。
【００１３】
図４は従来の組み立て、復号化およびハッシュ計算の処理手順を説明する図であり、図５は暗号化されたデータを溜め込むことなく復号化する処理手順を説明する図である。ＳＳＬはＴＣＰに分割されて転送されるため、受信側ではそれを組み立ててから処理する必要があった。すなわち、まず、ＴＣＰにセグメント分けされた暗号文を組み立て、復号化し、ハッシュ計算を行なって改竄がないかどうかを確認していた。これに対して本実施の形態では、暗号アルゴリズムは受信次第復号化が可能であることに着眼し、パケットの組み立てを行いながら、復号化およびハッシュ計算のうち可能な処理を先行して実施する。これにより、遅延が低減される。
【００１４】
図６は本実施の形態における送信時のＴＣＰフォーマットを説明する図である。自分が受信側であるときには、送り手のデータ長が制御できないことから、上述した処理により高速化を図る。一方、送信時には、データ長の制御が可能である。そこで、アプリケーション層のデータを暗号化してからＴＣＰで送るのではなく、データを分割してからＳＳＬで暗号化し、ＩＰヘッダおよびＴＣＰヘッダを付加してひとつのＴＣＰパケットにする。これにより受信側では、パケット毎の復号および検証が可能となる。
【００１５】
図７は復号回路２の詳細を示すブロック構成図である。この復号回路２は、識別部２０１、ＳＳＬ受信バッファ２０２、復号化スケジューラ２０３、復号化処理部２０４、平文メモリ２０５、ハッシュスケジューラ２０６、ハッシュ計算処理部２０７、ハッシュメモリ２０８、平文送信処理部２０９およびセッションテーブル２１０を備える。
【００１６】
識別部２０１は受信したトラフィックがどこからきたものであるかを判別する。この識別されたトラフィックをフローと呼ぶ。識別部２０１で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはＳＳＬ受信バッファ２０２に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ２０３でスケジュールされ、復号化処理部２０４で復号化処理される。ここまではパケットが到着しだい実行されるが、回線状態が悪くパケット順序が入れ替わってしまった場合は、次に来るべきパケットが来るまで復号化は実行されない。復号化処理部２０４による復号化処理を終えたデータは平文メモリ２０５に格納される。ハッシュアルゴリズムで決められた長さが復号化されると、平文メモリ２０５からその長さのデータがハッシュスケジューラ２０６によってスケジューリングされ、ハッシュ計算処理部２０７によりハッシュ処理される。ハッシュ計算の結果は、次のハッシュ処理のときに使うためにハッシュメモリ２０８に保存される。すべての処理が終わったときにハッシュメモリ２０８に残っている値がハッシュの計算結果である。ＳＳＬブロック（図３参照）がすべて復号化され、ハッシュ計算とＭＡＣ値が一致すれば改竄されていないことになり、平文送信処理部２０９によりサーバ５への送信処理が行われる。この際、ＳＳＬのために付加されたＭＡＣやパディングは取り除かれる。
【００１７】
セッションテーブル２１０は、ＳＳＬの通信で使われるセッション／コネクションの情報を保持し、計算の際に各部に情報を渡す。この情報に変更があるとセッションテーブル２１０に反映される。
【００１８】
図８は暗号回路３の詳細を示すブロック構成図である。この暗号回路３は、識別部３０１、平文受信バッファ３０２、暗号化／ハッシュスケジューラ３０３、ハッシュ計算処理部３０４、暗号化処理部３０５、ハッシュメモリ３０６、暗号文メモリ３０７、暗号文送信処理部３０８およびセッションテーブル３０９を備える。
【００１９】
識別部３０１はサーバからのフローを判定する。識別されたフローは平文受信バッファ３０２に格納される。本実施例において暗号化側は単一パケットでＭＡＣの付加および暗号化が完結するように調整を行うため、復号回路２とは違って各フローにバイト単位でのスケジューリングは行わず、暗号化可能なパケットが入力されると、そのパケットの暗号化を最後まで行う。もし、パケットの順序が入れ替わった場合は正しいパケットが来るまで待つことになる。正しいパケットが来た段階で暗号化を行う。フロー毎に１パケットずつ暗号化が順に行われる。暗号化／ハッシュスケジューラ３０３は、平文の最後の部分にＭＡＣを付加する必要があるので、その手前まではハッシュ計算処理部３０４によるハッシュ計算と暗号化処理部３０５による暗号化と同時に進め、最後の部分で待ち合わせをするように調節し、暗号化を完了させる。ハッシュ計算処理部３０４およびハッシュメモリ３０６の処理はハッシュ計算処理部２０７およびハッシュメモリ２０８の処理と同等である。暗号化処理部３０５は、暗号化／ハッシュスケジューラ３０３に調節されながら暗号処理を行い、完了すると暗号文送信処理部３０８にデータを渡し、インターネット４へ転送される。
【００２０】
セッションテーブル３０９は、ＳＳＬの通信で使われるセッション／コネクションの情報を保持し、計算の際に各部に情報を渡す。この情報に変更があるとセッションテーブル３０９に反映される。
【００２１】
図７に示した復号回路２の動作についてさらに詳しく説明する。
【００２２】
図９はＳＳＬ受信バッファ２０２の処理のフローチャートを示し、図１０は復号化スケジューラ２０３の処理のフローチャートを示す。これらの処理は復号化処理部２０４の処理に連動する。
【００２３】
ＳＳＬ受信バッファ２０２では、ＴＣＰで運ばれてきた図３に示したようなＳＳＬブロックを格納する。このとき、ＳＳＬヘッダから読み取れられＳＳＬブロックの長さをＳＳＬ＿Ｌｅｎｇｔｈ、先頭から入れ替わることなく連続受信できているバイト数をＤｃ、復号化スケジューラ２０３にすでに要求を完了している復号バイト数をＤｐ、暗号アルゴリズムによって決まる復号化の単位となるバイト数をＤｄｅｃとする。
【００２４】
ＳＳＬ受信バッファ２０２は、受信開始後、ＳＳＬ暗号データをネットワークより受信し（ステップＡ１）、それがＳＳＬブロックの先頭であれば（ステップＡ２）そのブロック用の領域を確保し、ＳＳＬ＿Ｌｅｎｇｔｈ、Ｄｃ、Ｄｐ、Ｄｄｅｃの初期値を設定する（ステップＡ３）。連続受信できているバイト数から既に処理要求を完了しているバイト数を差し引いた値が処理単位のバイト数よりも大きければ（ステップＡ４）、復号化スケジューラ２０３に復号化処理要求を行う（ステップＡ５）。パケットの入れ替えなどで間があいた後でその間のデータを受信すると、連続受信バイト数が急に増えるため処理単位の数倍が一度に復号処理要求される。ＳＳＬブロックがちょうど処理単位の整数倍とは限らないため、最後の領域は連続受信バイト数がＳＳＬブロック長と一致したところで（ステップＡ６）復号処理要求を行う（ステップＡ７）。以降、この処理を繰り返す。
【００２５】
フローには番号を付けて区別する。これをフロー識別子Ｆｌｏｗ＿Ｎｏとする。復号化スケジューラ２０３が復号処理要求を受けているバイト数をＱ（Ｆｌｏｗ＿Ｎｏ）、フローに割り当てられている一回あたりの復号化バイト数をＵｎｉｔ（Ｆｌｏｗ＿Ｎｏ）、今回復号化するバイト数をＤｅｃ＿ｓｉｚｅ、ＳＳＬ通信装置１がサポートしている最大フロー数をＦｌｏｗ＿ｍａｘとする。
【００２６】
図１０に示すように、復号化スケジューラ２０３が処理要求の受付を開始すると、まずＦｌｏｗ＿Ｎｏの１から（ステップＢ１）Ｆｌｏｗ＿ｍａｘまでを順に調べていく。復号要求があれば（ステップＢ２）、処理すべきバイト数を決定し（ステップＢ３）、ＳＳＬ暗号文のうちこのバイト数分を復号する（ステップＢ４）。ＳＳＬブロック全体を復号化し終えたら（ステップＢ５）該当ＳＳＬブロックのバッファを開放する（ステップＢ６）。復号処理を終えるか、または処理要求が無かった場合は次のフローについて処理要求が無いか調べる（ステップＢ７）。これを全てのフローについて行い、以降、繰り返す。
【００２７】
復号化処理部２０４は、復号化スケジューラ２０３のトリガを受けて動作し、復号した平文を平文メモリ２０５に送る。
【００２８】
図１１は平文メモリ２０５の処理のフローチャートを示し、図１２はハッシュスケジューラ２０６の処理のフローチャートを示す。これの処理は、ハッシュ計算処理部２０７、ハッシュメモリ２０８の処理に連動する。
【００２９】
平文メモリ２０５は、復号化処理部２０４で復号された平文を格納する。平文ブロックの長さをＰｌａｉｎ＿Ｌｅｎｇｔｈ、復号化処理部２０４から受信済みのバイト数をＤ＿ｐｌａｉｎ、ハッシュスケジューラ２０６にすでに要求を完了しているバイト数をＤ＿ｈａｓｈ、ハッシュアルゴリズムによって決定されるハッシュ計算処理の単位となるバイト数をＤｃａｌとする。
【００３０】
平文メモリ２０５では、平文を復号化処理部２０４より受信すると（ステップＣ１）、それがその平文ブロックで先頭であるときは（ステップＣ２）、Ｐｌａｉｎ＿Ｌｅｎｇｔｈ、Ｄ＿ｐｌａｉｎ、Ｄ＿ｈａｓｈ、Ｄｃａｌの初期値を設定する（ステップＣ３）。
現在の仕様ではＳＳＬに圧縮アルゴリズムが規定されていないため、Ｐｌａｉｎ＿Ｌｅｎｇｔｈ＝ＳＳＬ＿Ｌｅｎｇｔｈとなる。ハッシュを計算するバイト数が蓄積していれば（ステップＣ４）、ハッシュスケジューラ２０６に計算処理要求を出す（ステップＣ５）。平文ブロックの最後は、必ずしも計算単位となるバイト数になるとは限らないため、ブロック長分受信したところで（ステップＣ６）処理要求を出す（ステップＣ７）。平文はＭＡＣ検査後にサーバと送達確認を行うため、この段階ではバッファを開放しない。以降、受信、ハッシュ処理要求を繰り返す。
【００３１】
ハッシュスケジューラ２０６は、復号化スケジューラ２０３と同様の動きをする。スケジューリングの受付を開始すると、各フローのハッシュ処理要求を順に確認する（ステップＤ１）。ハッシュ計算処理要求バイト数をＱｈ（Ｆｌｏｗ＿Ｎｏ）とし、フローに割り当てられた一回当たりのハッシュ計算バイト数を Ｕｎｉｔｈ（Ｆｌｏｗ＿Ｎｏ）、今回ハッシュ計算を行うバイト数をＣａｌ＿ｓｉｚｅとする。ハッシュ計算要求があるかを調べ（ステップＤ２）、ある場合は処理バイト数を決定する（ステップＤ３）。フローに該当する情報をセッションテーブル２１０やハッシュメモリ２０８から得て、Ｃａｌ＿ｓｉｚｅの平文でハッシュを計算するようにハッシュ計算処理部２０７を制御し（ステップＤ４）、ハッシュメモリ２０８に記録する。ハッシュの計算が終了しているかを調べ（ステップＤ５）、終了していればＭＡＣとの比較を行い、改竄の有無について検証を行うよう制御する（ステップＤ６）。これが終了したら次のフローについて調べ、全てのフローを見終わると、再び１番目のフローから調べていく。
【００３２】
ハッシュ計算処理部２０７はハッシュメモリ２０８に計算結果を書き込み、これが次のハッシュ計算の際の入力となる。最後にハッシュメモリ２０８内に残るのがハッシュ計算の結果となる。改竄されていないことが確認されたら、平文送信処理部２０９が平文をサーバ５に向かって転送する。
【００３３】
次に、図８に示した暗号回路３の動作について詳しく説明する。
【００３４】
暗号回路３ではサーバ５からインターネット４向けの通信を暗号化するが、暗号化した後も、図３に示したようなＳＳＬブロックが図６に示したようにＩＰ（インターネット・プロトコル）ヘッダおよびＴＣＰヘッダを付加した上で１パケットに収まるように、あらかじめ調節を行う。暗号化する際に付加されるのはＳＳＬヘッダとパディングであるので、サーバ５が送り出すパケットをあらかじめこの長さだけ短くしておけばよい。このためには、ＴＣＰコネクション確立の過程で図１３に示すシーケンスを用いる。
【００３５】
図１３はインターネット４を経由してサーバ５へアクセスしてくるユーザとのコネクション確立のシーケンスを示す。ユーザからＴＣＰのＳＹＮパケットが送られてくると、ＳＳＬ通信装置１は、ユーザとサーバ５との間にＴＣＰコネクションを確立するために、次のように動作する。まず、ユーザとサーバそれぞれに対し、ＩＰヘッダのＤＦ（フラグメント禁止）ビットを立てて送信し、パスＭＴＵ（最大転送ユニット）を求める。ＳＳＬ通信装置１はユーザ側とサーバ５側でＳＳＬで暗号化してもパスＭＴＵを越えないように、ＴＣＰのハンドシェークでＭＳＳ（最大セグメントサイズ）を適切な値に設定する。この値を通知しながらＴＣＰコネクションの確立を行う。
【００３６】
図１４は平文受信バッファ３０２の処理のフローチャートを示す。サーバ５から平文の受信を開始すると、該当フローのバッファに格納する（ステップＥ１）。次に暗号化するべきパケットを受信できていれば（ステップＥ２）、ハッシュ計算と暗号化処理を暗号化／ハッシュスケジューラ３０３に要求する（ステップＥ４）。パケット順序が正しくなければ、バッファに入れて次のパケットを待つ（ステップＥ３）。暗号化／ハッシュスケジューラ３０３には、バッファの開始位置と、データサイズ、フロー番号などを伝える。そして、次のパケットを待つ。
【００３７】
図１５は暗号化／ハッシュスケジューラ３０３の処理のフローチャートを示す。暗号化／ハッシュスケジューラ３０３はデータサイズからＭＡＣ無しで可能な暗号化範囲を求め、ハッシュ計算とＭＡＣ付加前の暗号化を並列に実行するように制御する（ステップＦ１）。双方の終了を受けて、ハッシュ値をＭＡＣとして平文の残りに付加し、残りの暗号化を行うよう制御する（ステップＦ２）。そして、次の要求が無いかを調べる。暗号化／ハッシュスケジューラ３０３は受け取ったパケットについては一度に処理を済ませてしまう。復号化時のようにあるバイト分処理したところで処理を中断するということは無い。また、フローを順に調べることもない。来た順番に処理することで高速化を図る。ＴＣＰのフロー制御で送信データ量を制御する。これらはパケット単位で処理を完結できることから可能になっている。
【００３８】
ハッシュ計算においてはハッシュメモリ３０６に、暗号化においては暗号文メモリ３０７にデータが格納される。暗号化が終了すると、暗号文メモリ３０７から該当パケットがインターネット４に転送される。
【００３９】
以上説明した実施の形態では、復号回路２は、改竄を調べるためにＭＡＣの検証が終わるまでは受信パケットを平文メモリ２０５に保持し、検証が終わるのを待たないといけない。この点について、少し工夫を加えることで、さらに高速に動作できる可能性がある。
【００４０】
すなわち、ハッシュ計算の終了した平文について、平文メモリ２０５でのバッファをせずにすぐにサーバ５に送信する。ハッシュの計算は順次実施することが可能なため、先に来たものから順に転送することができる。この方法だと、平文ブロックをバッファリングしないため、パケット毎に処理したときと同じくらい高速化できる。この際、最後のパケットのハッシュ検証中に改竄が発見された場合、平文送信処理部２０９はこのパケットを廃棄し、サーバ５への再送も行わずにタイムアウトを待つ。タイムアウトは比較的長い時間を要するが、あまり改竄の頻度が高くない状況においては有用である。ただし、最後のパケットを廃棄しても、先に届いてしまったパケットについては順次読み込んでしまうようなサーバ実装の場合は問題になる可能性もあり、機種依存性が存在する。
【００４１】
平文ブロックのバッファリングを行なわないことで、改竄の発生しないほとんどの場合には従来よりも大幅に高スループット、低遅延が得られ、改竄の発生したときのみタイムアウト待ちに伴う性能低下が起こる。図７に示した構成では、改竄のあったパケットがサーバ５に届くことは無く、セキュリティ強度は高いといえる。それに対し、平文ブロックのバッファリングを行なわない場合には、改竄のあったパケットが一部サーバ５に届いてしまうためやや危険があるが、高速な通信が可能となる。
【００４２】
本実施の形態によれば、受信復号化時に、ＳＳＬブロックを構成する全てのパケットの到着を待たずに処理を開始できる。これにより、プロセッサなどの非稼動時間を減らし、その性能を充分に活用できる。また、パケット順序の入れ替わりなどで復号処理が出来なかったフローの分の空いている処理リソースを別のフローが利用することができるため、処理部の動作率は向上し、性能を無駄なく使うことが出来る。
【００４３】
また、暗号化送信時には、ユーザからサーバまで一貫してパスＭＴＵを越えず、ＳＳＬ化しても１パケットに収まるパケットのやり取りが可能となる。パスＭＴＵを越えないパケットを扱うことで、ＳＳＬ化に伴うフラグメントを防止し、それにともなう性能低下が他の性能まで犠牲にすることを防ぐことができる。これにより、暗号化処理部の性能を生かすことが可能になる。
【００４４】
また、単一パケットで暗号化／復号化を完結すると、組み立てや分解の処理負荷や遅延が生じない。ＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）をＳＳＬに渡して暗号化し、それをＴＣＰが分割すると、復号化の段階で組み立て処理が必要となるが、ＨＴＴＰをあらかじめ分割した上でＳＳＬ化し、ＴＣＰで転送すると、組み立て無しにＳＳＬ復号化ができ、ＨＴＴＰでデータの終了位置を検出する、あるいはＴＣＰコネクションの切断でデータの終了とみなすことで、もとのデータが得られる。
【００４５】
さらに、ＳＳＬ通信装置がＨＴＴＰを分割したＴＣＰパケットをサーバから受け、ＨＴＴＰの組み立てを行わずに送信データとみなしてＳＳＬ処理を行う場合には、あらかじめセグメントサイズを最適にしてサーバから受けるため、ＳＳＬ通信装置で分割するよりもデータの収容効率が良いという利点もある。
【００４６】
さらに本実施の形態では、暗号処理部の動作率の向上を図るとともに、双方向に遅延と処理負荷の低減を図っており、バッファに必要なメモリ量を削減することができる。これにより、余裕の出たメモリでより多くのセッション情報を保持することも可能となる。
【符号の説明】
【００４７】
１ ＳＳＬ通信装置
２ 復号回路
３ 暗号回路
４ インターネット
５ サーバ
２０１、３０１ 識別部
２０２ ＳＳＬ受信バッファ
２０３ 復号化スケジューラ
２０４ 復号化処理部
２０５ 平文メモリ
２０６ ハッシュスケジューラ
２０７、３０４ ハッシュ計算処理部
２０８、３０６ ハッシュメモリ
２０９ 平文送信処理部
２１０、３０９ セッションテーブル
３０２ 平文受信バッファ
３０３ 暗号化／ハッシュスケジューラ
３０５ 暗号化処理部
３０７ 暗号文メモリ
３０８ 暗号文送信処理部
【特許請求の範囲】
【請求項１】
サーバからのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加したブロック暗号化を行い、そのブロック暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段を備えた暗号化通信制御装置において、
前記暗号化送信手段は、前記サーバと前記相手先との間のコネクション確立時に前記サーバと前記相手先との間で転送されるデータのサイズを前記サーバからのパケットをブロック暗号化して前記相手先にひとつのパケットで送信できるサイズに設定し、その後、前記サーバから転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで前記相手先に送信する
ことを特徴とする暗号化通信制御装置。
【請求項１】
サーバからのアプリケーション層のデータに対して改竄の有無を調べるためのデータを付加したブロック暗号化を行い、そのブロック暗号化されたデータをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットで相手先に送信する暗号化送信手段を備えた暗号化通信制御装置において、
前記暗号化送信手段は、前記サーバと前記相手先との間のコネクション確立時に前記サーバと前記相手先との間で転送されるデータのサイズを前記サーバからのパケットをブロック暗号化して前記相手先にひとつのパケットで送信できるサイズに設定し、その後、前記サーバから転送されてくるパケット毎にそれぞれブロック暗号化を行い、そのブロック暗号化されたデータをひとつのパケットで前記相手先に送信する
ことを特徴とする暗号化通信制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−１８２９９１（Ｐ２００９−１８２９９１Ａ）
【公開日】平成２１年８月１３日（２００９．８．１３）
【国際特許分類】
【出願番号】特願２００９−１１９６５８（Ｐ２００９−１１９６５８）
【出願日】平成２１年５月１８日（２００９．５．１８）
【分割の表示】特願２００３−１６０８６２（Ｐ２００３−１６０８６２）の分割
【原出願日】平成１５年６月５日（２００３．６．５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２１年８月１３日（２００９．８．１３）
【国際特許分類】
【出願日】平成２１年５月１８日（２００９．５．１８）
【分割の表示】特願２００３−１６０８６２（Ｐ２００３−１６０８６２）の分割
【原出願日】平成１５年６月５日（２００３．６．５）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]