JP2011223385A - 暗号化通信装置 - Google Patents

Abstract

【課題】情報転送を伴わないパディングフィールドの付与を可能な限り行なわずして、暗号化処理を施す。
【解決手段】ＥＳＰペイロードデータフィールドの調整を以下のように行なうことで、暗号アルゴリズムが要求するブロック長の整数倍にすることで課題を解決する。まず、ＩＰパケットの優先度をＩＰヘッダのＴＯＳフィールドにより分別し、高優先ＩＰパケットからＥＳＰペイロードデータフィールドに格納し、暗号化処理を施すサイズが暗号化アルゴリズムの要求するブロック長の整数倍になっていない場合、その不足分は低優先ＩＰパケットを分割し、格納する。
【選択図】図３Ｃ

Description

本発明は、暗号化通信装置に係り、特に、ＥＳＰパケットの生成、送受信する際、暗号化および復号化処理効率の向上、および転送効率の向上を図った暗号化通信装置に関する。

ＩＰ（Internet Protocol）通信をセキュアに行なうために、ＩＰパケットの認証、および暗号化、復号化を行なうＩＰｓｅｃ（Security Architecture for Internet Protocol）が使用されている。

ＩＰｓｅｃで使用するセキュリティプロトコルは、ＡＨ（Authentication Header）とＥＳＰ（Encapsulating Security Payload）がある。ＡＨは、認証のみを行なう。ＥＳＰは、認証および暗号化、復号化を行なう。ＩＰｓｅｃの処理においてＥＳＰを適用する際は、トランスポートモードまたはトンネルモードを選択する。トランスポートモードとトンネルモードは、保護対象をデータグラムのデータ部だけとするか（トランスポートモード）、データグラム全体とするか（トンネルモード）との違いである。

ＥＳＰをトンネルモードで適用し、送信データの暗号化を施す際、ＥＳＰは、元のＩＰパケット全体の前にＥＳＰヘッダを付与する。ＥＳＰは、さらにＳｅｃｕｒｉｔｙ−ＧＷ（Security Gateway）間で使用するＩＰヘッダをＥＳＰヘッダの前に新たに付与する。ＥＳＰは、元のＩＰパケット全体の後ろにＥＳＰトレイラおよびＩＣＶ（Integrity Check Value）を付与する。ＥＳＰトレイラは、ＰＡＤ長と次ヘッダからなる。ＩＣＶは、ＥＳＰ認証データである。

ＩＰｓｅｃにおけるデータの暗号化は、ブロック暗号が使用される。ブロック暗号は、平文（元のデータ）を一定の大きさのブロックに分割し、ブロック毎に暗号化処理を施す。ブロック長は、使用する暗号化アルゴリズム毎にＲＦＣによって決められている。ＤＥＳ（Data Encryption Standard）のブロック長は、６４ビットである。一方、ＡＥＳ（Advanced Encryption Standard）のブロック長は、１２８ビットである。例えば、ＡＥＳは、１２８ビットの平文のブロックから１２８ビットの暗号文を生成する。

暗号化処理を行ないたいＩＰパケットの大きさは、必ずしも使用する暗号化アルゴリズムで定められたブロック長の整数倍になっているとは限らない。そのため、ＥＳＰは、ＥＳＰトレイラ部に含まれるパディングフィールドを使用し、暗号化処理を施すデータを暗号化アルゴリズムで定められたブロック長の整数倍になるようにサイズの調整を行なう。パディングフィールドは、０〜２５５バイトの可変長である。パディングフィールドは、暗号化アルゴリズムがパディングフィールドの中身を指定しない限り、符号なし、１バイトの連続した整数値を１、２、３…と１バイトずつ埋めていく。また、ＲＦＣは、この方法をデフォルトとしている。

特許文献１は、入力データ長が所定ワードより少ないとき、乱数で発生させた乱数データを追加する技術を開示している。特許文献２は、パディング部に暗号化されるデータの座標データを格納する技術を開示している。特許文献３は、パディング部に暗号化されるデータの座標データとパリティデータとを格納する技術を開示している。特許文献４は、ブロック単位で暗号化する際に所定のサイズに満たないブロックは盗聴者に予想困難なデータを埋め込むことを開示する。

非特許文献１は、デフォルト方法以外のパディング処理を行なう際の暗号化アルゴリズムに関するＲＦＣである。非特許文献１は、ＥＳＰパケットの使用方法を定義するよう規定している。

また現在、ＥＳＰ暗号化でよく用いられる暗号化アルゴリズムＤＥＳおよびＡＥＳのＲＦＣ（ＤＥＳ：非特許文献２、ＡＥＳ：非特許文献３）においてもパディングフィールドの使用方法はデフォルトのパディングパターンを採用することとしている。しかし、そもそもデフォルトのパディングパターンは、送信するデータとは無関係であり、データとしては無効である。

特開２００７−２５１４８３号公報 特開２００６−２２０７４８号公報 特開２００６−２２０７４７号公報 特開平１０−３０３８６４号公報

S. Kent、外１名、"IP Encapsulating Security Payload (ESP)"、[online]、１９８８年１１月、ＩＥＴＦ、平成２２年３月１５日検索、インターネット、＜ＵＲＬ:http://www.rfc-editor.org/rfc/rfc2406.txt＞ C. Madson、外１名、"The ESP DES-CBC Cipher Algorithm With Explicit IV"、[online]、１９８８年１１月、ＩＥＴＦ、平成２２年３月１５日検索、インターネット、＜ＵＲＬ:http://www.rfc-editor.org/rfc/rfc2405.txt＞ S. Frankel、外２名、"The AES-CBC Cipher Algorithm and Its Use with IPsec"、[online]、２００３年９月、ＩＥＴＦ、平成２２年３月１５日検索、インターネット、＜ＵＲＬ:http://www.rfc-editor.org/rfc/rfc3602.txt＞

ＥＳＰパケットの復号化処理を行なった後、ブロック暗号化処理にて付与されたパディングフィールドは、検査されずに破棄される。これは、パディンングフィールドは、単に送信データをブロック長の整数倍にするために付与されたに過ぎないからである。したがって、パディングフィールドは、実効的な情報の伝達には寄与せず、冗長である。またスループット性能を少しでも多く確保するために、情報伝達を伴わないパディングフィールドは、小さければ小さいほど性能は向上する。

本発明は、送信データがブロック長の整数倍になるという条件を確保しつつもパディングフィールドを使用せずにブロック暗号化処理を施し、ＩＰｓｅｃ通信を可能とする方法を提供する。

本発明は、暗号化処理を施すデータ部（ＥＳＰペイロードデータフィールド）を暗号化アルゴリズムが要求するブロック長の整数倍に調整することで、ＥＳＰパケットにおけるパディングフィールドをなくす。

まず、暗号化を施そうとするＩＰパケットのＩＰヘッダのＴＯＳ（Type Of Service）フィールドにより優先度の高低によってＩＰパケットを分別し、それぞれ指定のバッファに格納する。次に、高優先ＩＰパケット格納バッファより高優先ＩＰパケットをＥＳＰペイロードデータフィールドに格納する。

ここで、高優先ＩＰパケットをブロック暗号化処理するにあたってブロック長に満たない場合の不足サイズ分は、低優先ＩＰパケットを分割し、ＥＳＰペイロードデータフィールドに続けて格納する。これによって、ＥＳＰのペイロードデータフィールドがブロック長の整数倍になるよう調整を行なう。

上述した課題は、第１のＩＰパケットを受信して、この第１のＩＰパケットを暗号化した第１の暗号パケットを送信し、第２の暗号パケットを受信して、こと第２の暗号パケットを復号化した第２のＩＰパケットを送信する暗号化通信装置において、ペイロードデータフィールドに複数の第１のＩＰパケットを格納して暗号化アルゴリズムの要求するサイズに調整し、複数の第２のＩＰパケットを結合するデータ処理部と、第１のＩＰパケットの優先度をＩＰヘッダのＴＯＳフィールドにて判別し、優先度の高い第１のＩＰパケットと優先度の低い第１のＩＰパケットに分けてバッファリングを行なうバッファ管理部とを有する暗号化通信装置により、達成できる。

本発明によれば、暗号化および復号化処理の効率が向上する。

ネットワーク構成を説明するブロック図である。 暗号通信装置のブロック図である。 暗号パケット生成過程を説明する図（その１）である。 暗号パケット生成過程を説明する図（その２）である。 暗号パケット生成過程を説明する図（その３）である。 暗号化処理範囲の構成とパターンを説明する図である。 暗号パケットの生成処理を説明するフローチャート（その１）である。 暗号パケットの生成処理を説明するフローチャート（その２）である。 暗号パケットの復号化処理説明するフローチャート（その１）である。 暗号パケットの復号化処理説明するフローチャート（その２）である。

以下、本発明の実施形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には、同じ参照番号を振り、説明は繰り返さない。

図１を参照して、暗号通信ネットワークの構成を説明する。図１において、暗号通信ネットワーク５００は、インターネット４５０と、インターネット４５０に接続された３台の暗号化通信装置１００と、暗号化通信装置１００−１に接続された２台のホスト２００−１、２００−２と、暗号化通信装置１００−２に接続された２台のホスト２００−３、２００−４と、暗号化通信装置１００−３に接続された２台のホスト２００−５、２００−６とから構成されている。暗号化通信装置１００と、暗号化通信装置１００に接続された２台のホスト２００は、ネットワーク４００を構成する。

暗号化通信装置１００は、異なるネットワーク４００間においてＩＰｓｅｃ通信を用いてＶＰＮ（Virtual Private Network）を構築する。暗号化通信装置１００は、異なるネットワーク４００に属するホスト１１０間でのＩＰｓｅｃ通信を可能とする。

図２を参照して、暗号通信装置１００の構成を説明する。図２において、暗号通信装置１００は、ＣＰＵ１１０と、メモリ１２０と、外部インタフェース部１３０とから構成される。メモリ１２０は、バッファ１２１と、バッファ管理部１２２と、データ処理部１２３と、暗号化／復号化処理部１２４とから構成される。バッファ管理部１２２、データ処理部１２３、暗号化／復号化処理部１２４は、いずれもプログラムである。ＣＰＵ１１０は、これらのプログラムを実行して、バッファ管理部１２２、データ処理部１２３、暗号化／復号化処理部１２４の機能を実現する。

外部インタフェース部１３０は、暗号化を施したＩＰパケットの送受信を行なう。暗号化／復号化処理部１２４は、送受信するＩＰパケットの暗号化／復号化処理を施す。データ処理部１２３は、暗号化を施す前のＩＰパケットおよび復号化を施したＩＰパケットの解析、分解、および結合を行なう。バッファ管理部１２２は、暗号化処理を施そうとするＩＰパケットの優先度をＩＰヘッダのＴＯＳ（Type of Service）フィールドにて判別する。バッファ管理部１２２は、バッファ１２１を優先度の高いＩＰパケット保持域１２１ａ、優先度の低いＩＰパケット保持域１２１ｂ、分割したＩＰパケット保持域１２１ｃに分けてバッファリングを行なう。バッファ管理部１２２は、分割されて送信されてきたＩＰパケットを受信バッファ１２１ｄ（図示せず）に一時記憶する。バッファ１２１は、ＩＰパケットを優先度の高低で分けて格納する。バッファ１２１は、また分割されたＩＰパケットを保持する。バッファ１２１は、分割されて送信されてきたＩＰパケットを保持する。

図３を参照して、暗号化処理を施す処理について説明する。図３Ａないし図３Ｃにおいて、（ａ）はバッファ１２１である。バッファ１２１は、高優先ＩＰパケット格納バッファ１２１ａと、低優先ＩＰパケット格納バッファ１２１ｂと、分割ＩＰパケット格納バッファ１２１ｃとで構成される。

図３Ａないし図３Ｃにおいて、（ｂ）は、暗号化前のＥＳＰトンネルモードパケットである。暗号化前のＥＳＰトンネルモードパケットは、ＩＰヘッダ３１、ＥＳＰヘッダ３２、ＩＶ（Initial Vector）３３、ＩＰパケット格納フィールド３４、ＰＡＤ長３５、次ヘッダ３６、ＩＣＶ３７から構成される。

ＩＰヘッダ３１は、対向する暗号化通信装置との通信に用いる。ＥＳＰヘッダ３２は、セキュリティヘッダである。ＩＶ３３は、先頭の平文を暗号化するのに用いるデータである。ＩＰパケット格納フィールド３４は、ＩＰパケットを格納する。ＰＡＤ長３５は、パディングしたときの長さであり、ここでは「０」である。次ヘッダ３６は、暗号化されたデータの先頭を保持する。ＩＣＶ３７は、認証フィールドである。

図３Ａないし図３Ｃにおいて、（ｃ）は、暗号化後のＥＳＰトンネルモードパケットである。暗号化後のＥＳＰトンネルモードパケットは、ＩＰヘッダ３１、ＥＳＰヘッダ３２、ＩＶ３３、ＥＳＰペイロード３８、ＰＡＤ長３５Ａ、次ヘッダ３６Ａ、ＩＣＶ３７から構成される。ＥＳＰペイロード３８、ＰＡＤ長３５Ａ、次ヘッダ３６Ａが暗号化範囲である。

図３Ａにおいて、ここでは高優先ＩＰパケット格納バッファ１２１ａに格納されたＩＰパケット１とＰＡＤ長３５と次ヘッダ３６の合計がブロック長の整数倍とする。このとき、暗号化通信装置１００は、ＩＰパケット格納フィールド３４に、ＩＰパケット１のみを格納する。

一方、図３Ｂにおいて、ここでは高優先ＩＰパケット格納バッファ１２１ａに格納されたＩＰパケット２とＰＡＤ長３５と次ヘッダ３６の合計がブロック長の整数倍以外とする。このとき、暗号化通信装置１００は、ＩＰパケット格納フィールド３４に、ＩＰパケット２を格納する。暗号化通信装置１００は、低優先ＩＰパケット格納バッファ１２１ｂに格納されたＩＰパケット３をＩＰパケット３−１とＩＰパケット３−２に分割する。暗号化通信装置１００は、合計がブロック長の整数倍となるＩＰパケット３−１をＩＰパケット格納フィールド３４に格納する。暗号化通信装置１００は、残りのＩＰパケット３−２を分割ＩＰパケット格納バッファ１２１ｃに格納する。

次に、図３Ｃにおいて、ここでは高優先ＩＰパケット格納バッファ１２１ａに格納されたＩＰパケット４とＰＡＤ長３５と次ヘッダ３６の合計がブロック長の整数倍以外とする。このとき、暗号化通信装置１００は、ＩＰパケット格納フィールド３４に、ＩＰパケット４を格納する。暗号化通信装置１００は、分割ＩＰパケット格納バッファ１２１ｃに格納されたＩＰパケット３−２をＩＰパケット格納フィールド３４に格納する。暗号化通信装置１００は、低優先ＩＰパケット格納バッファ１２１ｂに格納されたＩＰパケット５をＩＰパケット５−１とＩＰパケット５−２に分割する。暗号化通信装置１００は、合計がブロック長の整数倍となるＩＰパケット５−１をＩＰパケット格納フィールド３４に格納する。暗号化通信装置１００は、残りのＩＰパケット５−２を分割ＩＰパケット格納バッファ１２１ｃに格納する。
図３Ｃから明らかなように、暗号化通信装置１００の送信優先度は、高優先ＩＰパケット＞分割ＩＰパケット＞対優先ＩＰパケットの順である。

図４を参照して、図３Ａないし図３Ｃの暗号化前のＥＳＰトンネルモードパケットの暗号化範囲を説明する。図４において、（ａ）は図３Ａの暗号化前のＥＳＰトンネルモードパケット３０５の暗号化範囲である。図４（ｂ）は図３Ｂの暗号化前のＥＳＰトンネルモードパケット３０８の暗号化範囲である。図４（ｃ）は図３Ｃの暗号化前のＥＳＰトンネルモードパケット３１１の暗号化範囲である。ＥＳＰトレイラは、図３のＰＡＤ長３５と次ヘッダ３６である。

暗号化前のＥＳＰトンネルモードパケット３０５の暗号化範囲は、高優先ＩＰパケットとＥＳＰトレイラである。暗号化前のＥＳＰトンネルモードパケット３０８の暗号化範囲は、高優先ＩＰパケット、分割されたＩＰパケット、ＥＳＰトレイラである。暗号化前のＥＳＰトンネルモードパケット３１１の暗号化範囲は、高優先ＩＰパケット、分割された残りのＩＰパケット、新たに分割されたＩＰパケット、ＥＳＰトレイラである。

ＥＳＰトンネルモードパケット３０５の暗号化範囲、ＥＳＰトンネルモードパケット３０８の暗号化範囲、ＥＳＰトンネルモードパケット３１１の暗号化範囲の長さは、いずれも等しく、ブロック長の整数倍である。

なお、ＥＳＰトンネルモードパケット３０５の暗号化範囲、ＥＳＰトンネルモードパケット３０８の暗号化範囲、ＥＳＰトンネルモードパケット３１１の暗号化範囲の長さは、ブロック長の整数倍であれば、互いに等しい必要はない。しかし、ＭＴＵ（Maximum Transmission Unit）のサイズ以下とする。なぜなら、ＭＴＵを上回るサイズのパケットはＭＴＵ以下に分割されるからである。

図５を参照して、暗号化通信装置１００の暗号化処理を説明する。図５Ａにおいて、暗号化通信装置１００は、各バッファ１２１ａ〜１２１ｃチェック処理を実行する（Ｓ７００）。暗号化通信装置１００は、高優先ＩＰパケットがあるか判定する（Ｓ７０１）。ＹＥＳのとき、暗号化通信装置１００は、暗号化サイズがＭＴＵ以下か判定する（Ｓ７０２）。ＹＥＳのとき、暗号化通信装置１００は、ＥＳＰペイロード格納処理を実行する（Ｓ７０３）。暗号化通信装置１００は、暗号化範囲をブロック長で割った残余が０か判定する（Ｓ７０４）。ＹＥＳのとき、暗号化通信装置１００は、暗号化処理を実行して（Ｓ７０６）、終了する。

ステップ７０４でＮＯのとき、暗号化通信装置１００は、図５Ｂのステップ７０９に遷移する。ステップ７０２でＮＯのとき、暗号化通信装置１００は、フラグメント処理を実行して（Ｓ７０７）、ステップ７０３に遷移する。ここで、フラグメント処理は、ＭＴＵを上回るサイズのパケットをＭＴＵ以下に分割する処理である。

ステップ７０１でＮＯのとき、暗号化通信装置１００は、分割または低優先ＩＰパケットがあるか判定する（Ｓ７０８）。ＹＥＳのとき、暗号化通信装置１００は、ステップ７０２に遷移する。ステップ７０８でＮＯのとき、暗号化通信装置１００は、ステップ７００に遷移する。

図５Ｂにおいて、暗号化通信装置１００は、不足サイズ計算処理を実行する（Ｓ７０９）。暗号化通信装置１００は、各バッファ１２１ａ〜１２１ｃのチェック処理を実行する（Ｓ７１１）。暗号化通信装置１００は、不足サイズ以下の高優先ＩＰパケットがあるか判定する（Ｓ７１２）。ＹＥＳのとき、暗号化通信装置１００は、図５Ａのステップ７０３に遷移する。ステップ７１２でＮＯのとき、暗号化通信装置１００は、分割または低優先ＩＰパケットがあるか判定する（Ｓ７１３）。ＹＥＳのとき、暗号化通信装置１００は、分割または低優先ＩＰパケットのサイズが、不足サイズを超えているか判定する（Ｓ７１４）。ＹＥＳのとき、分割処理を実行して（Ｓ７１６）、図５Ａのステップ７０３に遷移する。ステップ７１４でＮＯのとき、暗号化通信装置１００は、そのままステップ７０３に遷移する。ステップ７１３でＮＯのとき、暗号化通信装置１００は、パディング処理を実行して（Ｓ７１７）、図５Ａのステップ７０６に遷移する。

図６参照して、暗号化通信装置１００の復号化処理を説明する。図６Ａにおいて、暗号化通信装置１００は、復号化処理を実行する（Ｓ９０１）。暗号化通信装置１００は、ＥＳＰのＰＡＤ長が０か判定する（Ｓ９０２）。ＹＥＳのとき、暗号化通信装置１００は、データの先頭は完全なＩＰパケットか判定する（Ｓ９０３）。ＹＥＳのとき、暗号化通信装置１００は、ＩＰパケット抽出処理を実行する（Ｓ９０６）。暗号化通信装置１００は、残りデータサイズが０か判定する（Ｓ９０７）。ＹＥＳのとき、暗号化通信装置１００は、終了する。

ステップ９０７でＮＯのとき、暗号化通信装置１００は、ステップ９０３に遷移する。ステップ９０３でＮＯのとき、暗号化通信装置１００は、図６Ｂのステップ９０９に遷移する。ステップ９０２でＮＯのとき、暗号化通信装置１００は、パディング廃棄処理を実行して（Ｓ９０８）、ステップ９０３に遷移する。

図６Ｂにおいて、暗号化通信装置１００は、受信バッファ１２１ｄの参照処理を実行する（Ｓ９０９）。暗号化通信装置１００は、ＩＰパケットの結合対象データがあるか判定する（Ｓ９１１）。ＹＥＳのとき、暗号化通信装置１００は、データ結合処理を実行して（Ｓ９１２）、図６Ａのステップ９０６に遷移する。ステップ暗号化通信装置１００は、受信バッファ１２１ｄへの格納処理を実行して（Ｓ９１３）、図６Ａのステップ９０７に遷移する。
上述した実施例に拠れば、パディングフィールドの使用を最小限に抑え、暗号化および復号化処理の効率が向上した暗号化通信装置を提供できる。

１００…暗号化通信装置、１１０…中央演算装置（ＣＰＵ）、１２０…メモリ、１２１…バッファ、１２２…バッファ管理部、１２３…データ処理部、１２４…暗号化／復号化処理部、１３０…外部インタフェース、２００…ホスト、４００…ネットワーク、４５０…インターネット、５００…暗号通信ネットワーク。

Claims (4)

1. 第１のＩＰパケットを受信して、この第１のＩＰパケットを暗号化した第１の暗号パケットを送信し、第２の暗号パケットを受信して、こと第２の暗号パケットを復号化した第２のＩＰパケットを送信する暗号化通信装置において、
   ペイロードデータフィールドに複数の前記第１のＩＰパケットを格納して暗号化アルゴリズムの要求するサイズに調整し、複数の前記第２のＩＰパケットを結合するデータ処理部と、
   前記第１のＩＰパケットの優先度をＩＰヘッダのＴＯＳフィールドにて判別し、優先度の高い第１のＩＰパケットと優先度の低い第１のＩＰパケットに分けてバッファリングを行なうバッファ管理部とを有することを特徴とする暗号化通信装置。
2. 請求項１に記載の暗号化通信装置であって、
   さらに、高優先度ＩＰパケット格納バッファと、低優先度ＩＰパケット格納バッファと、分割ＩＰパケット格納バッファと、前記第２のＩＰパケット格納バッファとを記憶するバッファを有することを特徴とする暗号化通信装置。
3. 請求項２に記載の暗号化通信装置であって、
   前記データ処理部は、前記高優先度ＩＰパケット格納バッファに格納された前記第１のＩＰパケットを最優先して、暗号化アルゴリズムの要求するサイズに調整することを特徴とする暗号化通信装置。
4. 請求項３に記載の暗号化通信装置であって、
   前記データ処理部は、前記分割ＩＰパケット格納バッファに格納された分割された第１のＩＰパケットを次に優先して、暗号化アルゴリズムの要求するサイズに調整することを特徴とする暗号化通信装置。

Images