送信装置及び送信方法
【課題】 受信側の復号処理に影響を与えることなく、送信処理の負荷を軽減できる送信装置を提供する。
【解決手段】 ｎ個のデータブロックのうち（ａ）１番目のデータブロックについては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成し、（ｂ）前記ｎ個のデータブロックに基づくヘッダ情報を生成し、（ｃ）前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成し、（ｄ）前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する。
【解決手段】 ｎ個のデータブロックのうち（ａ）１番目のデータブロックについては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成し、（ｂ）前記ｎ個のデータブロックに基づくヘッダ情報を生成し、（ｃ）前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成し、（ｄ）前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データをブロック暗号のＣＢＣモードで暗号化して送信する送信装置に関する。
【背景技術】
【０００２】
近年暗号通信が一般的に使用されつつあり、ネットワークシステムのさまざまな層で暗号処理が実施されている。非特許文献１乃至３に記載されているように、ＩＰパケットの暗号化を行うＩＰｓｅｃ（Security Architecture for Internet Protocol）におけるＥＳＰ（Encapsulated Security Payload）パケットのペイロードには、トランスポートプロトコルヘッダ及びアプリケーションデータからなるパケットを一定の長さ単位のブロック毎に暗号化して挿入される。
【０００３】
このようなブロック暗号に、ＣＢＣ（Cipher Block Chaining）モードがある。ＣＢＣモードでは、最初のブロックを暗号化する場合は、イニシャルベクトル（initial vector）を当該最初のブロックに排他的論理和（ＸＯＲ）演算によって重ね合わせ、その結果に対し暗号演算を行う。２番目以降のブロックでは、当該ブロックに、前のブロックを暗号化した結果を排他的論理和（ＸＯＲ）演算によって重ね合わせ、その結果に対し暗号演算を行う。この結果得られる複数の暗号ブロックは、その先頭に上記イニシャルベクトルが付加されて、上記ペイロードに挿入される。このように、ＣＢＣ暗号化は、送信するブロック列の先頭から順次暗号化する必要がある。
【０００４】
一方、受信側では、ＣＢＣモードで暗号化されたペイロードは、その先頭のイニシャルベクトルを用いて、上記複数の暗号ブロックを順に復号する。すなわち、１番目の暗号ブロックは、当該暗号ブロックに対し上記暗号演算に対応する復号演算を行い、その結果と上記イニシャルベクトルとの排他的論理和を求めることで復号する。２番目以降の暗号ブロックは、当該暗号ブロック対し上記復号演算を行い、その結果と１つ前の暗号ブロックとの排他的論理和を求めることで復号する。復号の際には、どの暗号ブロックからでも（その１つ前の暗号ブロックがあれば）復号可能である。
【非特許文献１】IETF RFC 2451 : The ESP CBC-Mode Cipher Algorithms
【非特許文献２】IETF RFC 4303 : IP Encapsulating Security Payload (ESP)
【非特許文献３】IETF RFC 4835 : Cryptographic Algorithm Implementation
【発明の開示】
【発明が解決しようとする課題】
【０００５】
トランスポートプロトコルヘッダが、それに続くアプリケーションデータが全て揃った時点で生成される場合、従来のＣＢＣモードでは、トランスポートプロトコルヘッダが生成されないと、すなわち、トランスポートプロトコルヘッダ、及びそれに続くアプリケーションデータを含む複数のブロックが全て揃った時点（すなわち、ＥＳＰパケット構築の際）でないと暗号化を開始することができなかった。
【０００６】
従って、送信すべき上記複数のブロックが揃ってから、これを送信するまでの送信処理において、この複数のブロックの暗号化処理の分、負荷が増大し、遅延時間が生ずるという問題点があった。
【０００７】
この送信処理における負荷を軽減し、遅延時間を短縮するためには、上記暗号化処理は、ヘッダ情報を含む暗号化すべき複数のブロックが全て揃う前から、すなわち、ヘッダ情報が生成される前の（ヘッダ情報を含まない）途中のブロックから開始することが望ましい。
【０００８】
そこで、本発明は上記問題点に鑑みなされたもので、ＣＢＣモード（Cipher Block Mode）において、受信側の復号処理に影響を与えることなく（受信側の復号処理に変更を加えることなく）、送信処理の負荷を軽減できる送信装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロック（例えば、１番目からｎ−１番目のデータブロックはアプリケーションデータ、ｎ番目のデータブロックは、（残りのアプリケーションデータがあればそれと）ＥＳＰトレイラ）と、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置は、
（ａ）１番目のデータブロックについては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成し、
（ｂ）少なくともｎ−１番目のデータブロックが得られたときに、前記ヘッダ情報を生成し、
（ｃ）前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成し、
（ｄ）前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成し、
（ｅ）前記暗号パケットを送信する。
【発明の効果】
【００１０】
受信側の復号処理に影響を与えることなく（受信側の復号処理に変更を加えることなく）、送信処理の負荷を軽減できる。
【発明を実施するための最良の形態】
【００１１】
ＩＰｓｅｃはネットワーク層でセキュリティ機能を提供する技術であり、暗号化技術や認証技術を用いて安全な通信を提供する。
【００１２】
ＩＰｓｅｃの暗号通信ではパケットごとに暗号化を施すことで実現され、平文のパケットと暗号文のパケットの変換はＥＳＰ(Encapsulating Security Payload)と呼ばれる規定に従って行われる。暗号化処理に使用されるアルゴリズムの選択は通信者間に設定されたセキュリティアソシエーション（ＳＡ）の内容から行われる。
【００１３】
ＩＰｓｅｃのトランスポートモードの場合、パケットの暗号化処理はデータの送信者自身が行う。ＩＰｓｅｃのトランスポートモードにおける暗号化処理では、トランスポートプロトコルヘッダ（例えばＴＣＰ（Transport Control Protocol）ヘッダ）からアプリケーションデータ、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）までが暗号化される。
【００１４】
ＩＰｖ６の場合は終点オプションの拡張ヘッダも暗号化される。通常、パケットの暗号化処理はパケットの送信処理内で行われる。これは、パケットの暗号化処理に必要なトランスポートヘッダやＥＳＰトレイラがパケットの送信処理中に生成されるためである。
【００１５】
一般的に暗号化処理の処理負荷は大きいため、ＩＰｓｅｃトランスポートモードでＥＳＰを実施した場合、パケットの送信処理負荷が大きくなり、パケットの送信処理時間が長くなってしまう。これによりデータ送信者のシステム全体の安定性やハードウェア選定に影響を与える可能性がある。そこで、パケット送信処理時の暗号化処理負荷を軽減するため、パケット送信処理に先だってアプリケーションデータの暗号化を実施する方法が考えられる。
【００１６】
たとえば、音声通信のように、マイクデバイスから取得した音声データを複数個まとめて１つのパケットとして送信する場合、音声データを取得する度に暗号化処理を実施することにより、パケット送信処理時に暗号化を行うデータを小さくすることができる。このようにパケット送信処理に先だってアプリケーションデータの暗号化処理を行うことにより、パケット送信処理負荷を下げることができる。
【００１７】
しかし、パケットの暗号化にブロック暗号のＣＢＣ(Cipher Block Chaining)モードを利用している場合には、パケット送信処理に先だってアプリケーションデータを暗号化することができない。これは、ＣＢＣモードでアプリケーションデータの暗号化を行うためにはトランスポートプロトコルヘッダが必要なためである。トランスポートプロトコルヘッダはアプリケーションデータが揃わなければ生成されないため、パケットの送信処理時にトランスポートプロトコルヘッダが生成されるまでアプリケーションデータの暗号化処理は実施できないことになる。
【００１８】
このように、従来はＩＰｓｅｃトランスポートモードでブロック暗号のＣＢＣモードによるパケット暗号化を行う際に、データの送信者がアプリケーションデータの暗号化をパケット送信処理に先だって実施することができなかった。
【００１９】
本実施形態によれば、トランスポートプロトコルヘッダが生成されなければアプリケーションデータの暗号化を実施できないという制限を回避し、アプリケーションデータの暗号化をパケット送信処理に先だって実施できるようにする。
【００２０】
これにより、パケット送信時の処理負荷を低減することができる。
【００２１】
以下、本発明の実施形態について図面を参照して説明する。
【００２２】
以下の実施形態では図１に示したネットワーク構成を仮定する。送信ノード１１はネットワーク１３を介して、受信ノード１２に対しデータを送信する。データの送信に際して、送信ノード１１はトランスポートモードで ＩＰｓｅｃ ＥＳＰ を用い、ブロック暗号のＣＢＣモードで送信パケットを暗号化する。パケットの暗号化で使用されるアルゴリズムや鍵情報は送信ノード１１と受信ノード１２の間で事前に設定されているものとする。
【００２３】
図１では送信ノード１１と受信ノード１２の間にネットワーク１３が存在しているが、送信ノード１１と受信ノード１２が同一ネットワークに接続していても構わない。
【００２４】
また、本実施形態では図２に示したような構成のデータに対して送信ノード１１がＩＰｓｅｃ ＥＳＰ処理を実施すると仮定する。送信ノード１１が送信するデータのうち、データ２２、２３，及び２４がアプリケーションデータにあたる。ヘッダ２１はトランスポートプロトコルヘッダに相当する。
【００２５】
本実施形態では、アプリケーションデータが、データ２２〜２４の順にそれぞれ異なる時刻に発生し、データ２４が発生した後にアプリケーションデータ全体の送信処理が開始されるものとする。
【００２６】
ここで、本実施形態について説明する前に、図３を参照して、従来方式によるデータの送信処理手順を表す。従来方式では、アプリケーションデータが発生すると、ステップＳ３１でアプリケーションデータを取得し、ステップＳ３２でアプリケーションデータをアプリケーションバッファに記憶する。つまり、このアプリケーションバッファ内にデータ２２〜２４がこの順に格納されていく。
【００２７】
ステップＳ３３では、受信ノード１２へ送信すべきすべてのデータがアプリケーションバッファ内に揃ったかを判定する。すなわち、データ２２〜２４まですべてがバッファに格納されているかを判定する。ステップＳ３３の判定の結果、必要なデータが揃っていない場合、処理が終了する。ステップＳ３３の判定の結果、必要なデータが揃っている場合は、ステップＳ３４においてアプリケーションバッファの内容を用いてトランスポートプロトコルヘッダを生成する。この時点で図２に示したデータが完成する。
【００２８】
次に、ステップＳ３５でＩＰｓｅｃ ＥＳＰの暗号化処理を行うための前処理を実施する。具体的にはパケットの暗号化に必要なＩＶ(イニシャルベクトルinitial vector)の生成やＥＳＰトレイラ（パディング、パディング長、次ヘッダ）の生成を行う。次に、ステップＳ３６でトランスポートプロトコルヘッダおよびアプリケーションデータ、ＥＳＰトレイラの暗号化処理を行う。ＩＰｖ６の場合、宛先オプションの拡張ヘッダも暗号化の対象となる。暗号化処理が完了すると、ステップＳ３７でパケットの構築を行い、パケットの送信を実施する。ステップＳ３７のパケットの構築では、ＥＳＰヘッダやＩＰヘッダの生成などが行われる。
【００２９】
従来方式の送信処理手順では、ステップＳ３６でアプリケーションデータ全体の暗号化が行われる。アプリケーションデータが大きくなればなるほど、ステップＳ３６の処理時間が長くなる。これにより、アプリケーションデータがすべて揃ってから実際にパケットが送信されるまでの遅延が大きくなってしまう。
【００３０】
従来方式においてデータ２２〜２４を取得する時点で暗号化すれば、アプリケーションデータが揃ってから実際にパケットが送信されるまでの時間を短縮することができる。しかし、データの暗号化にブロック暗号のＣＢＣモードを利用している場合は、個々のデータを取得した時点でそれぞれのデータを暗号化することできない。その理由は、アプリケーションデータの先頭ブロック、つまりデータ２２の先頭のブロックを暗号化するためにトランスポートプロトコルヘッダが必要になるが、データ２２を取得した時点ではトランスポートプロトコルヘッダが生成されていないためである。
【００３１】
図４は、ブロック暗号Ｅｋ（ ）を用いた従来のＣＢＣモードの暗号化演算方法を説明するためのものである。ｍｎは、暗号化を行うデータを規定の長さで区切ったときのｎ番目のブロックを示し、ＣｎはｍｎをＣＢＣモードで暗号化演算した結果の暗号文を示す。
【００３２】
図４に示すように、ＣＢＣモードでは、ｎ−１番目の暗号化演算の結果とn番目のブロックの排他的論理和演算(ＸＯＲ演算)を行い、その結果に対し予め定められたアルゴリズムの暗号演算（Ｅｋ（ ））を施すことで、ｎ番目のブロックの暗号文が得られる。１番目のブロックを暗号化するためには、イニシャルベクトルＣ０を使用する。イニシャルベクトルは生成された乱数または直前に送信したＩＰｓｅｃＥＳＰパケットの最後の暗号ブロックである。イニシャルベクトルの生成はＣＢＣモードの演算に先だって行われる。ブロックに区切る長さとトランスポートプロトコルヘッダの長さが等しい場合、図２のデータでは、トランスポートプロトコルヘッダ全体がＣ１になり、データ２２の先頭のブロックがＣ２になる。このため、データ２２の暗号化を行うためにはトランスポートプロトコルヘッダが必要となる。しかし、トランスポートプロトコルヘッダは、図２においてデータ２２〜２４までのアプリケーションデータが全て揃わないと生成できない。従って、データ２２を取得した段階では、トランスポートプロトコルヘッダがまだ生成されていないがため、図４に示した従来のＣＢＣモードの暗号化演算方法では、データ２２を取得した段階で、データ２２の暗号化を行うことはできない。
【００３３】
そこで、本実施形態では、ＣＢＣモードの暗号化演算方法を図５に示すように変更する。従来はパケットの先頭にある１番目のブロック（トランスポートプロトコルヘッダ）の暗号化演算に使用していたイニシャルベクトルＣ０を、本実施形態では、パケットの先頭から２番目のブロックであり、しかも最初に取得されるブロックの暗号化演算に使用し、１番目のブロックがまだ生成されていない状態で２番目の暗号化演算を実施する。これにより、トランスポートプロトコルヘッダが生成されていない時点で、図２のデータ２２に対し暗号化演算を実施することができ、データ２２、データ２３、そしてデータ２４それぞれのデータが取得された時点で個々のデータの暗号化演算を実施することができる。
【００３４】
データ２４が取得され、１番目のブロックとなるトランスポートプロトコルヘッダ（例えば、図５ではｍ１）が生成されたとき、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と先頭のブロック、すなわち、トランスポートプロトコルヘッダ （ｍ１）の排他的論理和演算（ＸＯＲ演算）を実施する。これにより得られたＣ０´が従来のＣＢＣモード演算方式で用いられるイニシャルベクトルに相当する値になる。
【００３５】
送信時は、Ｃ０´、Ｃ０、２番目以降のブロックの暗号結果である暗号ブロックＣ２、Ｃ３、…、Ｃｎの順で送信される。
【００３６】
次に、図６及び図７を参照して、図５に示したＣＢＣモードの暗号化演算方式を適用した図１の送信ノード（送信装置）１１の構成及び送信処理動作について説明する。
【００３７】
図６は、送信ノード１１の構成例を示したものである。
【００３８】
アプリケーションデータ取得部１０１は、上位層で発生したアプリケーションデータを取得する。
【００３９】
ヘッダ情報抽出部１０２は、アプリケーションデータ取得部１０１で取得されたアプリケーションデータからトランスポートプロトコルヘッダを生成するために必要な情報を抽出し、ヘッダ情報バッファ１０３へ格納する。トランスポートプロトコルヘッダを生成するために必要な情報には、アプリケーションデータのチェックサム値やアプリケーションデータのデータ長などの情報が含まれる。ヘッダ情報抽出部１０２では、このような値を計算するために必要な情報を、アプリケーションデータ取得部１０１でアプリケーションンデータが取得される度に、当該アプリケーションデータから抽出する。
【００４０】
先頭ブロック判定手段１０４は、アプリケーションデータ取得部１０１が取得したアプリケーションデータが送信すべきデータの先頭部分にあたるかどうかの判定を行う。
【００４１】
イニシャルベクトル生成部１０５は乱数を発生させるなどして暗号化演算に必要なイニシャルベクトル（図５のＣ０）の生成を行い、生成したイニシャルベクトルをイニシャルベクトルバッファ１０６へ格納する。
【００４２】
暗号化部１０７は、図５に示した排他的論理和演算と暗号化演算を行い、予め定められた一定の長さ（α）のブロック単位でＣＢＣモードの暗号化演算処理を行う。暗号化演算処理の結果はアプリケーションバッファ１０８へ格納する。暗号化部１０７はＣＢＣモードの暗号化処理を行うために、イニシャルベクトルＣ０や、暗号化対象のブロックの直前のブロックの暗号化処理結果を取得するためにイニシャルベクトルバッファ１０６やアプリケーションバッファ１０８にアクセスする。
【００４３】
パケット送信判定部１０９は、受信ノード１２へ送信すべきデータがすべて揃ったかどうかを判定する。受信ノード１２へ送信すべきデータの長さが固定長で規定されている場合は、アプリケーションバッファ１０８を参照するなどして取得されているアプリケーションデータの長さが規定の長さに到達しているか否かで、受信ノード１２へ送信すべきデータがすべて揃ったかどうかの判定を行うことができる。
【００４４】
ヘッダ生成部１１０は、パケット送信判定部１０９で、受信ノード１２へ送信すべきデータがすべて揃ったと判定されたときに、ヘッダ情報バッファ１０３の情報を利用して、トランスポートプロトコルヘッダを生成する。生成されたトランスポートプロトコルヘッダはヘッダバッファ7１１に格納する。
【００４５】
暗号化後処理部１１３は、まず、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）を生成する。なお、ＥＳＰトレイラはパディング長が「０」の場合でも必要である。このＥＳＰトレイラは、（まだ暗号化されていないアプリケーションデータがあれば、それと合わせて）暗号処理単位のブロック長αの最後のブロック（図５のブロックｍｎ）として、図５のｎ−１番目の暗号処理行い、最後の暗号ブロック（図５では、Ｃｎ）を生成する。
【００４６】
また、暗号化後処理部１１３は、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αに一致する場合には、当該トランスポートプロトコルヘッダとイニシャルベクトル（図５のＣ０）とからＣＢＣモードにおける本来のイニシャルベクトルになるべき値（図５のＣ０´）を図５に示した方法で計算する。
【００４７】
すなわち、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とトランスポートプロトコルヘッダの排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００４８】
この結果、図８に示すように、トランスポートプロトコルヘッダ、アプリケーションデータ、及びＥＳＰトレイラ（図８（ａ）参照）に対し、図５に示したＣＢＣモードの暗号化演算処理を用いることにより、図８（ｂ）に示すような暗号ブロック列Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００４９】
また、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αの整数倍である場合には、暗号化後処理部１１３は、当該トランスポートプロトコルヘッダの長さα毎の複数のブロックに分割し、そのうちの最後のブロックから順に、図５のｎ番目の暗号処理を繰り返す。
【００５０】
図９には、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αの２倍である場合を示している。トランスポートプロトコルヘッダの長さがαの２倍である場合、トランスポートプロトコルヘッダを長さαの２つのブロック（ｍ１−１、ｍ１−２）に分割する。まず、後半のブロックｍ１−２の暗号化を行う（図９のｎ番目の暗号処理）。このｎ番目の暗号処理では、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と後半のブロックｍ１−２との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００５１】
次に、前半のブロックｍ１−１の暗号化を行う（図９のｎ＋１番目の暗号処理）。このｎ＋１番目の暗号処理では、上記ｎ番目の暗号処理で求めたＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−１との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´´を求める。このＣ０´´がＣＢＣモードにおける本来のイニシャルベクトルになるべき値である。
【００５２】
この結果、図８に示すように、トランスポートプロトコルヘッダ、アプリケーションデータ、及びＥＳＰトレイラ（図８（ａ）参照）に対し、図９に示したＣＢＣモードの暗号化演算処理を用いることにより、図８（ｃ）に示すような暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００５３】
トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αに一致する場合も、αの整数倍である場合も、得られる暗号ブロック列の先頭（図８（ｂ）のＣ０´、図８（ｃ）のＣ０´´）は、受信ノード１２における復号処理では従来のＣＢＣモードにおけるイニシャルベクトルとして用いられる。
【００５４】
以下、説明の簡単のため、トランスポートプロトコルヘッダの長さがαであり、暗号ブロック列の先頭が図８（ｂ）のＣ０´の場合を例にとり説明する。
【００５５】
パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた暗号ブロックＣ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号化処理結果の暗号ブロック列Ｃ１、Ｃ２、…Ｃｎ、をこの順に並べて、ＩＰｓｅｃのＥＳＰパケットを構築する。その際、必要ならばＩＰｖ６の宛先オプションの拡張ヘッダの生成などを行う。例えば、図８（ｄ）に示すように、ＳＰＩ、シーケンス番号、認証データなどを生成する。
【００５６】
なお、ここで、ＳＰＩ（Security parameter Index）は、宛先ＩＰアドレスとセキュリティプロトコル（ＥＳＰ）とを組み合わせることにより、そのデータグラムに対するセキュリティアソシエーションを一意に識別する３２ビットの値である。シーケンス番号はパケットにつける通し番号、次ヘッダは上位層プロトコルの識別子、認証データは、ＥＳＰパケットから認証データを抜いたものから計算された値である。また、パディングは必要に応じて付加され、パディング長は、付加されたパディングの長さを示す。
【００５７】
パケット構築部１１４は、図８（ｅ）に示すように、図８（ｄ）のＥＳＰパケットに、さらにＩＰヘッダを付加してＩＰパケットを生成する。
【００５８】
パケット構築部１１４が構築したパケットはパケット用バッファ１１５に格納される。
【００５９】
パケット送信部１１６は、パケット用バッファ7１１５に格納されたパケットを受信ノード１２に対して送信する。
【００６０】
図７は、図６に示した送信ノード１１の送信処理動作を説明するためのフローチャートである。なお、図７に示す送信処理動作は、アプリケーションデータ取得部１０１が上位層からアプリケーションデータを取得する度に実行される。
【００６１】
まず、トランスポートプロトコルヘッダの長さがブロック暗号処理単位のブロック長αに等しい場合を例により説明する。
【００６２】
アプリケーションデータ取得部１０１が、上位層で生成されたアプリケーションデータを取得すると（ステップＳ１）、ヘッダ情報抽出部１０２が当該アプリケーションデータからトランスポートプロトコルヘッダを生成するために必要な情報（例えば、チェックサムやデータ長など）を抽出し、これをヘッダ情報バッファ１０３に記憶する（ステップＳ２）。
【００６３】
次に、先頭ブロック判定部１０４は、アプリケーションバッファ１０８に記憶されている、既に取得されているが暗号化されていない暗号処理待ち状態のアプリケーションデータ、及び、既に取得され暗号化されて送信待ち状態のアプリケーションデータの暗号データの量から、ステップＳ１０１でアプリケーションデータ取得部１０１で取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたるかどうかの判定を行う（ステップＳ３）。例えば、上記暗号処理待ち及び上記送信待ち状態の暗号データが存在しないとき（空のとき）、当該取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたると判定する。
【００６４】
当該取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたるとき、ステップＳ３からステップＳ４へ進む。
【００６５】
ステップＳ４では、イニシャルベクトル生成部１０５が、イニシャルベクトル（図５のＣ０）を生成し、生成したイニシャルベクトルをイニシャルベクトルバッファ１０６へ格納する。その後、ステップＳ５へ進み、最初の暗号化を行う。すなわち、図５の１番目の暗号処理を行う。ここでは、ステップＳ１で取得したアプリケーションデータの先頭から予め定められた長さαのデータをブロックｍ２とする。そして、このブロックｍ２と、イニシャルベクトルバッファ１０６に記憶されたイニシャルベクトルＣ０との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍ２の暗号ブロックＣ２が得られる。得られた暗号ブロックＣ２は、アプリケーションバッファ１０８に記憶される（ステップＳ６）。また、ステップＳ１で取得したアプリケーションデータがαより長いとき、その残りの部分は、次に発生するアプリケーションデータと合わせて暗号化する。そのため、当該残りの部分は上記暗号処理待ち状態のアプリケーションデータとしてアプリケーションバッファ１０８に記憶しておく。
【００６６】
一方、ステップＳ３において、アプリケーションバッファ１０８に上記暗号処理待ち状態または上記送信待ち状態のアプリケーションデータまたはその暗号データ（暗号ブロック）が存在する場合には、ステップＳ３からステップＳ５へ進む。
【００６７】
この場合、ステップＳ５では、図５の２番目から（ｎ−２）番目のいずれかの暗号処理を行う。例えば、２番目の暗号処理の場合、アプリケーションバッファ１０８に記憶されている暗号処理待ちのアプリケーションデータに、データ長がαとなるように、今回取得したアプリケーションデータの先頭から追加し、ブロックｍ３を得る。このとき今回取得したアプリケーションデータの余った部分は、上記同様アプリケーションバッファ１０８に記憶する。このブロックｍ３と、アプリケーションバッファ１０８に記憶されている１つ前の暗号処理で得られた暗号ブロック、すなわち暗号ブロックＣ２との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍ３の暗号ブロックＣ３が得られる。得られた暗号ブロックＣ３は、アプリケーションバッファ１０８に記憶される（ステップＳ６）。
【００６８】
３番目以降ｎ−２番目までの暗号処理も上記同様である。
【００６９】
次に、ステップＳ７に進み、パケット送信判定部１０９が、アプリケーションバッファ１０８に格納されている送信待ち状態の暗号ブロックのデータ量が、受信ノード１２へ送信すべきデータ長を満たす場合（例えば、暗号ブロックＣ２〜Ｃｎ−１がアプリケーションバッファ１０８に記憶されているとき）、ステップＳ７からステップＳ８へ進み、そうでない場合、処理を終了する。
【００７０】
ステップＳ８では、ヘッダ生成部１１０が、ヘッダ情報バッファ１０３に記憶されている情報を利用して、トランスポートプロトコルヘッダを生成する。生成されたトランスポートプロトコルヘッダはヘッダバッファ7１１に格納される。
【００７１】
次に、ステップＳ９へ進み、暗号化後処理部１１３は、まず、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）を生成する。例えば、アプリケーションバッファ１０８に上記暗号処理待ちのアプリケーションデータが記憶されている場合には、この暗号処理待ちのアプリケーションデータに、データ長がαとなるように、パディング、パディング長、及び次ヘッダを追加して、ブロックｍｎを得る。そして、図５のｎ−１番目の暗号処理を行う。すなわち、このブロックｍｎと、アプリケーションバッファ１０８に記憶されている１つ前の暗号処理で得られた暗号ブロック、すなわち、暗号ブロックＣｎ−１との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍｎの暗号ブロックＣｎが得られる。得られた暗号ブロックＣｎは、アプリケーションバッファ１０８に記憶する。
【００７２】
次に、図５のｎ番目の暗号処理を行う。すなわち、ヘッダバッファ７１１に記憶されたトランスポートプロトコルヘッダ（これをｍ１とする）と、ステップＳ４でイニシャルベクトルバッファ１０６に記憶されたイニシャルベクトル（Ｃ０）とからＣＢＣモードにおける本来のイニシャルベクトルになるべき値（Ｃ０´）を図５に示した方法で計算する。
【００７３】
すなわち、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とトランスポートプロトコルヘッダの排他的論理和演算（ＸＯＲ演算）を実施することにより、暗号ブロックＣ０´を求める。
【００７４】
次に、ステップＳ１０において、パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた値暗号ブロックＣ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号処理結果の暗号ブロック列Ｃ１、Ｃ２、…Ｃｎ、をこの順に並べて、図８（ｄ）のＥＳＰパケットを生成する。その際、例えば、図８（ｄ）に示すように、ＳＰＩ、シーケンス番号、認証データなどを生成する。また、パケット構築部１１４は、図８（ｄ）のＥＳＰパケットに、さらにＩＰヘッダを付加して、図８（ｅ）に示すようなＩＰパケットを生成する。
【００７５】
以上のようにして生成されたＩＰパケットはパケット送信部１１６から送信される。
【００７６】
次に、トランスポートプロトコルヘッダの長さがブロック暗号処理単位のブロック長αの整数倍である場合を例により説明する。この場合、図７のステップＳ９の処理が、上述のトランスポートプロトコルヘッダの長さがαに等しい場合と異なる。
【００７７】
ステップＳ８で生成されるトランスポートプロトコルヘッダの長さがαの２倍である場合を例にとり、図９を参照して説明する。なお、図９において、図５と同一部分は同一符号を付している。
【００７８】
この場合、まず、ステップＳ９において、暗号化後処理部１１３は、トランスポートプロトコルヘッダを長さαの２つのブロック（ｍ１−１、ｍ１−２）に分割する。まず、後半のブロックｍ１−２の暗号化を行う（図９のｎ番目の暗号処理）。このｎ番目の暗号処理では、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−１との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００７９】
次に、前半のブロックｍ１−１の暗号化を行う（図９のｎ＋１番目の暗号処理）。このｎ＋１番目の暗号処理では、上記ｎ番目の暗号処理で求めたＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−２との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´´を求める。このＣ０´´がＣＢＣモードにおける本来のイニシャルベクトルになるべき値である。
【００８０】
この結果、図８に示すように、トランスポートプロトコルヘッダ及びアプリケーションデータ（図２、図８（ａ）参照）に対し、図９に示したＣＢＣモードの暗号化演算方式を用いることにより、図８（ｃ）に示すような暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００８１】
ステップＳ１０では、パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた暗号ブロックＣ０´´、Ｃ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号処理結果の暗号ブロックＣ１、Ｃ２、…Ｃｎ、をこの順に並べて、さらにＩＰヘッダを付加して、図８（ｅ）に示すようなＩＰパケットを生成する。
【００８２】
以上のようにして生成されたＩＰパケットはパケット送信部１１６から送信される。
【００８３】
受信ノード１２では、上述のようにして送信ノード１１から送信されたＩＰパケットを受信すると、その中のＥＳＰパケットのペイロードから図８（ｂ）または図８（ｃ）に示すような暗号ブロック列を取り出す。この暗号ブロック列の先頭（例えば、Ｃ０´またはＣ０´´）は、従来のＣＢＣモードにおけるイニシャルベクトルと同じ扱いをすればよく、この暗号ブロック列は、従来のＣＢＣモードにおける復号処理と全く同じ手順で復号することができる。
【００８４】
すなわち、図５に示すように暗号化した結果得られる暗号ブロック列Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎに対しては、図１０に示すように、まず、Ｃ０´をイニシャルベクトルとみなし、２番目の暗号ブロックＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とＣ０´との排他的論理和演算（ＸＯＲ演算）を実施することにより、最初のブロックｍ１が得られる。次に、３番目の暗号データＣ２に対し復号演算（Ｅｋ−１（ ））を行い、その結果と２番目の暗号ブロックＣ０との排他的論理和演算（ＸＯＲ演算）を実施することにより、２番目のブロックｍ２が得られる。以下同様に復号して、ｍ１〜ｍｎまでのブロックを復号する。
【００８５】
また、図９に示すように暗号化した結果得られる暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎに対しては、図１１に示すように、まず、Ｃ０´´をイニシャルベクトルとみなし、２番目の暗号ブロックＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とＣ０´´との排他的論理和演算（ＸＯＲ演算）を実施することにより、最初のブロックｍ１−１が得られる。次に、３番目の暗号ブロックＣ０に対し復号演算（Ｅｋ−１（ ））を行い、その結果と２番目の暗号ブロックＣ０´との排他的論理和演算（ＸＯＲ演算）を実施することにより、２番目のブロックｍ１−２が得られる。以下同様に復号して、ｍ２〜ｍ３までのブロックも復号する。
【００８６】
この復号処理手順は、従来のＣＢＣモードにおける復号処理手順と全く同じであり、受信側の構成及び処理動作を変更する必要がない。
【００８７】
以上説明したように、上記実施形態によれば、１番目からＮ（Ｎは、２以上の整数）番目までの連続する複数の平文データブロック（例えば、１番目のデータブロックはヘッダ情報を含み、２番目からｎ−１番目のデータブロックはアプリケーションデータを含み、最後のｎ番目のデータブロックは、（残りのアプリケーションデータがあればそれと）ＥＳＰトレイラを含む）を暗号化して送信する際に、最初に得られた途中の（例えば２番目の）平文データブロックについては、該平文データブロックとイニシャルベクトルＣ０との排他的論理和に対し暗号演算を行うことにより暗号化し、３番目以降の平文データブロックは、該平文データブロックとその前の平文データブロックを暗号化した結果との排他的論理和に対し暗号演算を行うことにより暗号化し、２番目からＮ番目の暗号データブロックを生成する。
【００８８】
一方、１番目の平文データブロックは、例えば送信すべきアプリケーションデータがそろったときに得られるヘッダ情報であり、この１番目の平文データブロックについては、上記イニシャルベクトルＣ０に対し上記暗号演算に対応する復号演算を行い、その結果と１番目の平文データブロックとの排他的論理和を計算することにより、１番目の暗号データブロックを生成する。
【００８９】
そして、１番目の暗号データブロック、イニシャルベクトルＣ０、及び２番目からＮ番目の暗号データブロックをこの順に含むパケットを生成して、送信する。
【００９０】
このような構成により、トランスポートプロトコルヘッダ及びアプリケーションデータをブロック暗号ＣＢＣモードで暗号化して送信する処理において、復号処理に変更を加えることなく、アプリケーションデータの暗号化処理をトランスポートプロトコルヘッダ生成前の途中のブロックから実施することが可能となり、送信遅延を短縮することができる。
【００９１】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【００９２】
例えば、図６に示した各構成部の機能は、コンピュータに搭載されたプロセッサにプログラムを実行させることにより実現することができる。
【００９３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００９４】
【図１】本実施形態に係るネットワークの構成例を示した図。
【図２】ＣＢＣモードで暗号化されるデータの構成例を示した図。
【図３】従来のブロック暗号ＣＢＣモードの暗号化手順を用いたデータの送信処理を説明するためのフローチャート。
【図４】従来のブロック暗号ＣＢＣモードの暗号化手順を説明するための図。
【図５】本実施形態に係る暗号化手順（トランスポートプロトコルヘッダ長とブロック長とが等しい場合）を説明するための図。
【図６】図１の送信ノード（送信装置）の構成例を示した図。
【図７】図６の送信ノードにおけるデータの送信処理を説明するためのフローチャート。
【図８】図７の送信処理により送信ノードで生成される暗号ブロック列、この暗号ブロック列を含むＥＳＰ（Encapsulating Security Payload）パケットの構成例を示した図。
【図９】本実施形態に係る他の暗号化手順（トランスポートプロトコルヘッダ長がブロック長より長い場合）を説明するための図。
【図１０】図５の暗号化手順に対応する復号手順を説明するための図。
【図１１】図９の暗号化手順に対応する復号手順を説明するための図。
【符号の説明】
【００９５】
１１…送信ノード
１２…受信ノード
１３…ネットワーク
１０１…アプリケーションデータ取得部
１０２…ヘッダ情報抽出部
１０３…ヘッダ情報バッファ
１０４…先頭ブロック判定部
１０５…イニシャルベクトル生成部
１０６…イニシャルベクトルバッファ
１０７…暗号化部
１０８…アプリケーションバッファ
１０９…パケット送信判定部
１１０…ヘッダ生成部
１１１…ヘッダバッファ
１１３…暗号化後処理部
１１４…パケット構築部
１１５…パケット用バッファ
１１６…パケット送信部
【技術分野】
【０００１】
本発明は、データをブロック暗号のＣＢＣモードで暗号化して送信する送信装置に関する。
【背景技術】
【０００２】
近年暗号通信が一般的に使用されつつあり、ネットワークシステムのさまざまな層で暗号処理が実施されている。非特許文献１乃至３に記載されているように、ＩＰパケットの暗号化を行うＩＰｓｅｃ（Security Architecture for Internet Protocol）におけるＥＳＰ（Encapsulated Security Payload）パケットのペイロードには、トランスポートプロトコルヘッダ及びアプリケーションデータからなるパケットを一定の長さ単位のブロック毎に暗号化して挿入される。
【０００３】
このようなブロック暗号に、ＣＢＣ（Cipher Block Chaining）モードがある。ＣＢＣモードでは、最初のブロックを暗号化する場合は、イニシャルベクトル（initial vector）を当該最初のブロックに排他的論理和（ＸＯＲ）演算によって重ね合わせ、その結果に対し暗号演算を行う。２番目以降のブロックでは、当該ブロックに、前のブロックを暗号化した結果を排他的論理和（ＸＯＲ）演算によって重ね合わせ、その結果に対し暗号演算を行う。この結果得られる複数の暗号ブロックは、その先頭に上記イニシャルベクトルが付加されて、上記ペイロードに挿入される。このように、ＣＢＣ暗号化は、送信するブロック列の先頭から順次暗号化する必要がある。
【０００４】
一方、受信側では、ＣＢＣモードで暗号化されたペイロードは、その先頭のイニシャルベクトルを用いて、上記複数の暗号ブロックを順に復号する。すなわち、１番目の暗号ブロックは、当該暗号ブロックに対し上記暗号演算に対応する復号演算を行い、その結果と上記イニシャルベクトルとの排他的論理和を求めることで復号する。２番目以降の暗号ブロックは、当該暗号ブロック対し上記復号演算を行い、その結果と１つ前の暗号ブロックとの排他的論理和を求めることで復号する。復号の際には、どの暗号ブロックからでも（その１つ前の暗号ブロックがあれば）復号可能である。
【非特許文献１】IETF RFC 2451 : The ESP CBC-Mode Cipher Algorithms
【非特許文献２】IETF RFC 4303 : IP Encapsulating Security Payload (ESP)
【非特許文献３】IETF RFC 4835 : Cryptographic Algorithm Implementation
【発明の開示】
【発明が解決しようとする課題】
【０００５】
トランスポートプロトコルヘッダが、それに続くアプリケーションデータが全て揃った時点で生成される場合、従来のＣＢＣモードでは、トランスポートプロトコルヘッダが生成されないと、すなわち、トランスポートプロトコルヘッダ、及びそれに続くアプリケーションデータを含む複数のブロックが全て揃った時点（すなわち、ＥＳＰパケット構築の際）でないと暗号化を開始することができなかった。
【０００６】
従って、送信すべき上記複数のブロックが揃ってから、これを送信するまでの送信処理において、この複数のブロックの暗号化処理の分、負荷が増大し、遅延時間が生ずるという問題点があった。
【０００７】
この送信処理における負荷を軽減し、遅延時間を短縮するためには、上記暗号化処理は、ヘッダ情報を含む暗号化すべき複数のブロックが全て揃う前から、すなわち、ヘッダ情報が生成される前の（ヘッダ情報を含まない）途中のブロックから開始することが望ましい。
【０００８】
そこで、本発明は上記問題点に鑑みなされたもので、ＣＢＣモード（Cipher Block Mode）において、受信側の復号処理に影響を与えることなく（受信側の復号処理に変更を加えることなく）、送信処理の負荷を軽減できる送信装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロック（例えば、１番目からｎ−１番目のデータブロックはアプリケーションデータ、ｎ番目のデータブロックは、（残りのアプリケーションデータがあればそれと）ＥＳＰトレイラ）と、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置は、
（ａ）１番目のデータブロックについては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成し、
（ｂ）少なくともｎ−１番目のデータブロックが得られたときに、前記ヘッダ情報を生成し、
（ｃ）前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成し、
（ｄ）前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成し、
（ｅ）前記暗号パケットを送信する。
【発明の効果】
【００１０】
受信側の復号処理に影響を与えることなく（受信側の復号処理に変更を加えることなく）、送信処理の負荷を軽減できる。
【発明を実施するための最良の形態】
【００１１】
ＩＰｓｅｃはネットワーク層でセキュリティ機能を提供する技術であり、暗号化技術や認証技術を用いて安全な通信を提供する。
【００１２】
ＩＰｓｅｃの暗号通信ではパケットごとに暗号化を施すことで実現され、平文のパケットと暗号文のパケットの変換はＥＳＰ(Encapsulating Security Payload)と呼ばれる規定に従って行われる。暗号化処理に使用されるアルゴリズムの選択は通信者間に設定されたセキュリティアソシエーション（ＳＡ）の内容から行われる。
【００１３】
ＩＰｓｅｃのトランスポートモードの場合、パケットの暗号化処理はデータの送信者自身が行う。ＩＰｓｅｃのトランスポートモードにおける暗号化処理では、トランスポートプロトコルヘッダ（例えばＴＣＰ（Transport Control Protocol）ヘッダ）からアプリケーションデータ、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）までが暗号化される。
【００１４】
ＩＰｖ６の場合は終点オプションの拡張ヘッダも暗号化される。通常、パケットの暗号化処理はパケットの送信処理内で行われる。これは、パケットの暗号化処理に必要なトランスポートヘッダやＥＳＰトレイラがパケットの送信処理中に生成されるためである。
【００１５】
一般的に暗号化処理の処理負荷は大きいため、ＩＰｓｅｃトランスポートモードでＥＳＰを実施した場合、パケットの送信処理負荷が大きくなり、パケットの送信処理時間が長くなってしまう。これによりデータ送信者のシステム全体の安定性やハードウェア選定に影響を与える可能性がある。そこで、パケット送信処理時の暗号化処理負荷を軽減するため、パケット送信処理に先だってアプリケーションデータの暗号化を実施する方法が考えられる。
【００１６】
たとえば、音声通信のように、マイクデバイスから取得した音声データを複数個まとめて１つのパケットとして送信する場合、音声データを取得する度に暗号化処理を実施することにより、パケット送信処理時に暗号化を行うデータを小さくすることができる。このようにパケット送信処理に先だってアプリケーションデータの暗号化処理を行うことにより、パケット送信処理負荷を下げることができる。
【００１７】
しかし、パケットの暗号化にブロック暗号のＣＢＣ(Cipher Block Chaining)モードを利用している場合には、パケット送信処理に先だってアプリケーションデータを暗号化することができない。これは、ＣＢＣモードでアプリケーションデータの暗号化を行うためにはトランスポートプロトコルヘッダが必要なためである。トランスポートプロトコルヘッダはアプリケーションデータが揃わなければ生成されないため、パケットの送信処理時にトランスポートプロトコルヘッダが生成されるまでアプリケーションデータの暗号化処理は実施できないことになる。
【００１８】
このように、従来はＩＰｓｅｃトランスポートモードでブロック暗号のＣＢＣモードによるパケット暗号化を行う際に、データの送信者がアプリケーションデータの暗号化をパケット送信処理に先だって実施することができなかった。
【００１９】
本実施形態によれば、トランスポートプロトコルヘッダが生成されなければアプリケーションデータの暗号化を実施できないという制限を回避し、アプリケーションデータの暗号化をパケット送信処理に先だって実施できるようにする。
【００２０】
これにより、パケット送信時の処理負荷を低減することができる。
【００２１】
以下、本発明の実施形態について図面を参照して説明する。
【００２２】
以下の実施形態では図１に示したネットワーク構成を仮定する。送信ノード１１はネットワーク１３を介して、受信ノード１２に対しデータを送信する。データの送信に際して、送信ノード１１はトランスポートモードで ＩＰｓｅｃ ＥＳＰ を用い、ブロック暗号のＣＢＣモードで送信パケットを暗号化する。パケットの暗号化で使用されるアルゴリズムや鍵情報は送信ノード１１と受信ノード１２の間で事前に設定されているものとする。
【００２３】
図１では送信ノード１１と受信ノード１２の間にネットワーク１３が存在しているが、送信ノード１１と受信ノード１２が同一ネットワークに接続していても構わない。
【００２４】
また、本実施形態では図２に示したような構成のデータに対して送信ノード１１がＩＰｓｅｃ ＥＳＰ処理を実施すると仮定する。送信ノード１１が送信するデータのうち、データ２２、２３，及び２４がアプリケーションデータにあたる。ヘッダ２１はトランスポートプロトコルヘッダに相当する。
【００２５】
本実施形態では、アプリケーションデータが、データ２２〜２４の順にそれぞれ異なる時刻に発生し、データ２４が発生した後にアプリケーションデータ全体の送信処理が開始されるものとする。
【００２６】
ここで、本実施形態について説明する前に、図３を参照して、従来方式によるデータの送信処理手順を表す。従来方式では、アプリケーションデータが発生すると、ステップＳ３１でアプリケーションデータを取得し、ステップＳ３２でアプリケーションデータをアプリケーションバッファに記憶する。つまり、このアプリケーションバッファ内にデータ２２〜２４がこの順に格納されていく。
【００２７】
ステップＳ３３では、受信ノード１２へ送信すべきすべてのデータがアプリケーションバッファ内に揃ったかを判定する。すなわち、データ２２〜２４まですべてがバッファに格納されているかを判定する。ステップＳ３３の判定の結果、必要なデータが揃っていない場合、処理が終了する。ステップＳ３３の判定の結果、必要なデータが揃っている場合は、ステップＳ３４においてアプリケーションバッファの内容を用いてトランスポートプロトコルヘッダを生成する。この時点で図２に示したデータが完成する。
【００２８】
次に、ステップＳ３５でＩＰｓｅｃ ＥＳＰの暗号化処理を行うための前処理を実施する。具体的にはパケットの暗号化に必要なＩＶ(イニシャルベクトルinitial vector)の生成やＥＳＰトレイラ（パディング、パディング長、次ヘッダ）の生成を行う。次に、ステップＳ３６でトランスポートプロトコルヘッダおよびアプリケーションデータ、ＥＳＰトレイラの暗号化処理を行う。ＩＰｖ６の場合、宛先オプションの拡張ヘッダも暗号化の対象となる。暗号化処理が完了すると、ステップＳ３７でパケットの構築を行い、パケットの送信を実施する。ステップＳ３７のパケットの構築では、ＥＳＰヘッダやＩＰヘッダの生成などが行われる。
【００２９】
従来方式の送信処理手順では、ステップＳ３６でアプリケーションデータ全体の暗号化が行われる。アプリケーションデータが大きくなればなるほど、ステップＳ３６の処理時間が長くなる。これにより、アプリケーションデータがすべて揃ってから実際にパケットが送信されるまでの遅延が大きくなってしまう。
【００３０】
従来方式においてデータ２２〜２４を取得する時点で暗号化すれば、アプリケーションデータが揃ってから実際にパケットが送信されるまでの時間を短縮することができる。しかし、データの暗号化にブロック暗号のＣＢＣモードを利用している場合は、個々のデータを取得した時点でそれぞれのデータを暗号化することできない。その理由は、アプリケーションデータの先頭ブロック、つまりデータ２２の先頭のブロックを暗号化するためにトランスポートプロトコルヘッダが必要になるが、データ２２を取得した時点ではトランスポートプロトコルヘッダが生成されていないためである。
【００３１】
図４は、ブロック暗号Ｅｋ（ ）を用いた従来のＣＢＣモードの暗号化演算方法を説明するためのものである。ｍｎは、暗号化を行うデータを規定の長さで区切ったときのｎ番目のブロックを示し、ＣｎはｍｎをＣＢＣモードで暗号化演算した結果の暗号文を示す。
【００３２】
図４に示すように、ＣＢＣモードでは、ｎ−１番目の暗号化演算の結果とn番目のブロックの排他的論理和演算(ＸＯＲ演算)を行い、その結果に対し予め定められたアルゴリズムの暗号演算（Ｅｋ（ ））を施すことで、ｎ番目のブロックの暗号文が得られる。１番目のブロックを暗号化するためには、イニシャルベクトルＣ０を使用する。イニシャルベクトルは生成された乱数または直前に送信したＩＰｓｅｃＥＳＰパケットの最後の暗号ブロックである。イニシャルベクトルの生成はＣＢＣモードの演算に先だって行われる。ブロックに区切る長さとトランスポートプロトコルヘッダの長さが等しい場合、図２のデータでは、トランスポートプロトコルヘッダ全体がＣ１になり、データ２２の先頭のブロックがＣ２になる。このため、データ２２の暗号化を行うためにはトランスポートプロトコルヘッダが必要となる。しかし、トランスポートプロトコルヘッダは、図２においてデータ２２〜２４までのアプリケーションデータが全て揃わないと生成できない。従って、データ２２を取得した段階では、トランスポートプロトコルヘッダがまだ生成されていないがため、図４に示した従来のＣＢＣモードの暗号化演算方法では、データ２２を取得した段階で、データ２２の暗号化を行うことはできない。
【００３３】
そこで、本実施形態では、ＣＢＣモードの暗号化演算方法を図５に示すように変更する。従来はパケットの先頭にある１番目のブロック（トランスポートプロトコルヘッダ）の暗号化演算に使用していたイニシャルベクトルＣ０を、本実施形態では、パケットの先頭から２番目のブロックであり、しかも最初に取得されるブロックの暗号化演算に使用し、１番目のブロックがまだ生成されていない状態で２番目の暗号化演算を実施する。これにより、トランスポートプロトコルヘッダが生成されていない時点で、図２のデータ２２に対し暗号化演算を実施することができ、データ２２、データ２３、そしてデータ２４それぞれのデータが取得された時点で個々のデータの暗号化演算を実施することができる。
【００３４】
データ２４が取得され、１番目のブロックとなるトランスポートプロトコルヘッダ（例えば、図５ではｍ１）が生成されたとき、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と先頭のブロック、すなわち、トランスポートプロトコルヘッダ （ｍ１）の排他的論理和演算（ＸＯＲ演算）を実施する。これにより得られたＣ０´が従来のＣＢＣモード演算方式で用いられるイニシャルベクトルに相当する値になる。
【００３５】
送信時は、Ｃ０´、Ｃ０、２番目以降のブロックの暗号結果である暗号ブロックＣ２、Ｃ３、…、Ｃｎの順で送信される。
【００３６】
次に、図６及び図７を参照して、図５に示したＣＢＣモードの暗号化演算方式を適用した図１の送信ノード（送信装置）１１の構成及び送信処理動作について説明する。
【００３７】
図６は、送信ノード１１の構成例を示したものである。
【００３８】
アプリケーションデータ取得部１０１は、上位層で発生したアプリケーションデータを取得する。
【００３９】
ヘッダ情報抽出部１０２は、アプリケーションデータ取得部１０１で取得されたアプリケーションデータからトランスポートプロトコルヘッダを生成するために必要な情報を抽出し、ヘッダ情報バッファ１０３へ格納する。トランスポートプロトコルヘッダを生成するために必要な情報には、アプリケーションデータのチェックサム値やアプリケーションデータのデータ長などの情報が含まれる。ヘッダ情報抽出部１０２では、このような値を計算するために必要な情報を、アプリケーションデータ取得部１０１でアプリケーションンデータが取得される度に、当該アプリケーションデータから抽出する。
【００４０】
先頭ブロック判定手段１０４は、アプリケーションデータ取得部１０１が取得したアプリケーションデータが送信すべきデータの先頭部分にあたるかどうかの判定を行う。
【００４１】
イニシャルベクトル生成部１０５は乱数を発生させるなどして暗号化演算に必要なイニシャルベクトル（図５のＣ０）の生成を行い、生成したイニシャルベクトルをイニシャルベクトルバッファ１０６へ格納する。
【００４２】
暗号化部１０７は、図５に示した排他的論理和演算と暗号化演算を行い、予め定められた一定の長さ（α）のブロック単位でＣＢＣモードの暗号化演算処理を行う。暗号化演算処理の結果はアプリケーションバッファ１０８へ格納する。暗号化部１０７はＣＢＣモードの暗号化処理を行うために、イニシャルベクトルＣ０や、暗号化対象のブロックの直前のブロックの暗号化処理結果を取得するためにイニシャルベクトルバッファ１０６やアプリケーションバッファ１０８にアクセスする。
【００４３】
パケット送信判定部１０９は、受信ノード１２へ送信すべきデータがすべて揃ったかどうかを判定する。受信ノード１２へ送信すべきデータの長さが固定長で規定されている場合は、アプリケーションバッファ１０８を参照するなどして取得されているアプリケーションデータの長さが規定の長さに到達しているか否かで、受信ノード１２へ送信すべきデータがすべて揃ったかどうかの判定を行うことができる。
【００４４】
ヘッダ生成部１１０は、パケット送信判定部１０９で、受信ノード１２へ送信すべきデータがすべて揃ったと判定されたときに、ヘッダ情報バッファ１０３の情報を利用して、トランスポートプロトコルヘッダを生成する。生成されたトランスポートプロトコルヘッダはヘッダバッファ7１１に格納する。
【００４５】
暗号化後処理部１１３は、まず、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）を生成する。なお、ＥＳＰトレイラはパディング長が「０」の場合でも必要である。このＥＳＰトレイラは、（まだ暗号化されていないアプリケーションデータがあれば、それと合わせて）暗号処理単位のブロック長αの最後のブロック（図５のブロックｍｎ）として、図５のｎ−１番目の暗号処理行い、最後の暗号ブロック（図５では、Ｃｎ）を生成する。
【００４６】
また、暗号化後処理部１１３は、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αに一致する場合には、当該トランスポートプロトコルヘッダとイニシャルベクトル（図５のＣ０）とからＣＢＣモードにおける本来のイニシャルベクトルになるべき値（図５のＣ０´）を図５に示した方法で計算する。
【００４７】
すなわち、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とトランスポートプロトコルヘッダの排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００４８】
この結果、図８に示すように、トランスポートプロトコルヘッダ、アプリケーションデータ、及びＥＳＰトレイラ（図８（ａ）参照）に対し、図５に示したＣＢＣモードの暗号化演算処理を用いることにより、図８（ｂ）に示すような暗号ブロック列Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００４９】
また、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αの整数倍である場合には、暗号化後処理部１１３は、当該トランスポートプロトコルヘッダの長さα毎の複数のブロックに分割し、そのうちの最後のブロックから順に、図５のｎ番目の暗号処理を繰り返す。
【００５０】
図９には、トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αの２倍である場合を示している。トランスポートプロトコルヘッダの長さがαの２倍である場合、トランスポートプロトコルヘッダを長さαの２つのブロック（ｍ１−１、ｍ１−２）に分割する。まず、後半のブロックｍ１−２の暗号化を行う（図９のｎ番目の暗号処理）。このｎ番目の暗号処理では、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と後半のブロックｍ１−２との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００５１】
次に、前半のブロックｍ１−１の暗号化を行う（図９のｎ＋１番目の暗号処理）。このｎ＋１番目の暗号処理では、上記ｎ番目の暗号処理で求めたＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−１との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´´を求める。このＣ０´´がＣＢＣモードにおける本来のイニシャルベクトルになるべき値である。
【００５２】
この結果、図８に示すように、トランスポートプロトコルヘッダ、アプリケーションデータ、及びＥＳＰトレイラ（図８（ａ）参照）に対し、図９に示したＣＢＣモードの暗号化演算処理を用いることにより、図８（ｃ）に示すような暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００５３】
トランスポートプロトコルヘッダの長さが、暗号処理単位のブロック長αに一致する場合も、αの整数倍である場合も、得られる暗号ブロック列の先頭（図８（ｂ）のＣ０´、図８（ｃ）のＣ０´´）は、受信ノード１２における復号処理では従来のＣＢＣモードにおけるイニシャルベクトルとして用いられる。
【００５４】
以下、説明の簡単のため、トランスポートプロトコルヘッダの長さがαであり、暗号ブロック列の先頭が図８（ｂ）のＣ０´の場合を例にとり説明する。
【００５５】
パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた暗号ブロックＣ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号化処理結果の暗号ブロック列Ｃ１、Ｃ２、…Ｃｎ、をこの順に並べて、ＩＰｓｅｃのＥＳＰパケットを構築する。その際、必要ならばＩＰｖ６の宛先オプションの拡張ヘッダの生成などを行う。例えば、図８（ｄ）に示すように、ＳＰＩ、シーケンス番号、認証データなどを生成する。
【００５６】
なお、ここで、ＳＰＩ（Security parameter Index）は、宛先ＩＰアドレスとセキュリティプロトコル（ＥＳＰ）とを組み合わせることにより、そのデータグラムに対するセキュリティアソシエーションを一意に識別する３２ビットの値である。シーケンス番号はパケットにつける通し番号、次ヘッダは上位層プロトコルの識別子、認証データは、ＥＳＰパケットから認証データを抜いたものから計算された値である。また、パディングは必要に応じて付加され、パディング長は、付加されたパディングの長さを示す。
【００５７】
パケット構築部１１４は、図８（ｅ）に示すように、図８（ｄ）のＥＳＰパケットに、さらにＩＰヘッダを付加してＩＰパケットを生成する。
【００５８】
パケット構築部１１４が構築したパケットはパケット用バッファ１１５に格納される。
【００５９】
パケット送信部１１６は、パケット用バッファ7１１５に格納されたパケットを受信ノード１２に対して送信する。
【００６０】
図７は、図６に示した送信ノード１１の送信処理動作を説明するためのフローチャートである。なお、図７に示す送信処理動作は、アプリケーションデータ取得部１０１が上位層からアプリケーションデータを取得する度に実行される。
【００６１】
まず、トランスポートプロトコルヘッダの長さがブロック暗号処理単位のブロック長αに等しい場合を例により説明する。
【００６２】
アプリケーションデータ取得部１０１が、上位層で生成されたアプリケーションデータを取得すると（ステップＳ１）、ヘッダ情報抽出部１０２が当該アプリケーションデータからトランスポートプロトコルヘッダを生成するために必要な情報（例えば、チェックサムやデータ長など）を抽出し、これをヘッダ情報バッファ１０３に記憶する（ステップＳ２）。
【００６３】
次に、先頭ブロック判定部１０４は、アプリケーションバッファ１０８に記憶されている、既に取得されているが暗号化されていない暗号処理待ち状態のアプリケーションデータ、及び、既に取得され暗号化されて送信待ち状態のアプリケーションデータの暗号データの量から、ステップＳ１０１でアプリケーションデータ取得部１０１で取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたるかどうかの判定を行う（ステップＳ３）。例えば、上記暗号処理待ち及び上記送信待ち状態の暗号データが存在しないとき（空のとき）、当該取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたると判定する。
【００６４】
当該取得されたアプリケーションデータが、送信すべきデータの先頭部分にあたるとき、ステップＳ３からステップＳ４へ進む。
【００６５】
ステップＳ４では、イニシャルベクトル生成部１０５が、イニシャルベクトル（図５のＣ０）を生成し、生成したイニシャルベクトルをイニシャルベクトルバッファ１０６へ格納する。その後、ステップＳ５へ進み、最初の暗号化を行う。すなわち、図５の１番目の暗号処理を行う。ここでは、ステップＳ１で取得したアプリケーションデータの先頭から予め定められた長さαのデータをブロックｍ２とする。そして、このブロックｍ２と、イニシャルベクトルバッファ１０６に記憶されたイニシャルベクトルＣ０との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍ２の暗号ブロックＣ２が得られる。得られた暗号ブロックＣ２は、アプリケーションバッファ１０８に記憶される（ステップＳ６）。また、ステップＳ１で取得したアプリケーションデータがαより長いとき、その残りの部分は、次に発生するアプリケーションデータと合わせて暗号化する。そのため、当該残りの部分は上記暗号処理待ち状態のアプリケーションデータとしてアプリケーションバッファ１０８に記憶しておく。
【００６６】
一方、ステップＳ３において、アプリケーションバッファ１０８に上記暗号処理待ち状態または上記送信待ち状態のアプリケーションデータまたはその暗号データ（暗号ブロック）が存在する場合には、ステップＳ３からステップＳ５へ進む。
【００６７】
この場合、ステップＳ５では、図５の２番目から（ｎ−２）番目のいずれかの暗号処理を行う。例えば、２番目の暗号処理の場合、アプリケーションバッファ１０８に記憶されている暗号処理待ちのアプリケーションデータに、データ長がαとなるように、今回取得したアプリケーションデータの先頭から追加し、ブロックｍ３を得る。このとき今回取得したアプリケーションデータの余った部分は、上記同様アプリケーションバッファ１０８に記憶する。このブロックｍ３と、アプリケーションバッファ１０８に記憶されている１つ前の暗号処理で得られた暗号ブロック、すなわち暗号ブロックＣ２との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍ３の暗号ブロックＣ３が得られる。得られた暗号ブロックＣ３は、アプリケーションバッファ１０８に記憶される（ステップＳ６）。
【００６８】
３番目以降ｎ−２番目までの暗号処理も上記同様である。
【００６９】
次に、ステップＳ７に進み、パケット送信判定部１０９が、アプリケーションバッファ１０８に格納されている送信待ち状態の暗号ブロックのデータ量が、受信ノード１２へ送信すべきデータ長を満たす場合（例えば、暗号ブロックＣ２〜Ｃｎ−１がアプリケーションバッファ１０８に記憶されているとき）、ステップＳ７からステップＳ８へ進み、そうでない場合、処理を終了する。
【００７０】
ステップＳ８では、ヘッダ生成部１１０が、ヘッダ情報バッファ１０３に記憶されている情報を利用して、トランスポートプロトコルヘッダを生成する。生成されたトランスポートプロトコルヘッダはヘッダバッファ7１１に格納される。
【００７１】
次に、ステップＳ９へ進み、暗号化後処理部１１３は、まず、ＥＳＰトレイラ（パディング、パディング長、次ヘッダ）を生成する。例えば、アプリケーションバッファ１０８に上記暗号処理待ちのアプリケーションデータが記憶されている場合には、この暗号処理待ちのアプリケーションデータに、データ長がαとなるように、パディング、パディング長、及び次ヘッダを追加して、ブロックｍｎを得る。そして、図５のｎ−１番目の暗号処理を行う。すなわち、このブロックｍｎと、アプリケーションバッファ１０８に記憶されている１つ前の暗号処理で得られた暗号ブロック、すなわち、暗号ブロックＣｎ−１との排他的論理和演算(ＸＯＲ演算)を行い、この結果に対し暗号演算（Ｅｋ（ ））を施すことで、ブロックｍｎの暗号ブロックＣｎが得られる。得られた暗号ブロックＣｎは、アプリケーションバッファ１０８に記憶する。
【００７２】
次に、図５のｎ番目の暗号処理を行う。すなわち、ヘッダバッファ７１１に記憶されたトランスポートプロトコルヘッダ（これをｍ１とする）と、ステップＳ４でイニシャルベクトルバッファ１０６に記憶されたイニシャルベクトル（Ｃ０）とからＣＢＣモードにおける本来のイニシャルベクトルになるべき値（Ｃ０´）を図５に示した方法で計算する。
【００７３】
すなわち、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とトランスポートプロトコルヘッダの排他的論理和演算（ＸＯＲ演算）を実施することにより、暗号ブロックＣ０´を求める。
【００７４】
次に、ステップＳ１０において、パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた値暗号ブロックＣ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号処理結果の暗号ブロック列Ｃ１、Ｃ２、…Ｃｎ、をこの順に並べて、図８（ｄ）のＥＳＰパケットを生成する。その際、例えば、図８（ｄ）に示すように、ＳＰＩ、シーケンス番号、認証データなどを生成する。また、パケット構築部１１４は、図８（ｄ）のＥＳＰパケットに、さらにＩＰヘッダを付加して、図８（ｅ）に示すようなＩＰパケットを生成する。
【００７５】
以上のようにして生成されたＩＰパケットはパケット送信部１１６から送信される。
【００７６】
次に、トランスポートプロトコルヘッダの長さがブロック暗号処理単位のブロック長αの整数倍である場合を例により説明する。この場合、図７のステップＳ９の処理が、上述のトランスポートプロトコルヘッダの長さがαに等しい場合と異なる。
【００７７】
ステップＳ８で生成されるトランスポートプロトコルヘッダの長さがαの２倍である場合を例にとり、図９を参照して説明する。なお、図９において、図５と同一部分は同一符号を付している。
【００７８】
この場合、まず、ステップＳ９において、暗号化後処理部１１３は、トランスポートプロトコルヘッダを長さαの２つのブロック（ｍ１−１、ｍ１−２）に分割する。まず、後半のブロックｍ１−２の暗号化を行う（図９のｎ番目の暗号処理）。このｎ番目の暗号処理では、イニシャルベクトルＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−１との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´を求める。
【００７９】
次に、前半のブロックｍ１−１の暗号化を行う（図９のｎ＋１番目の暗号処理）。このｎ＋１番目の暗号処理では、上記ｎ番目の暗号処理で求めたＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果と前半のブロックｍ１−２との排他的論理和演算（ＸＯＲ演算）を実施することにより、Ｃ０´´を求める。このＣ０´´がＣＢＣモードにおける本来のイニシャルベクトルになるべき値である。
【００８０】
この結果、図８に示すように、トランスポートプロトコルヘッダ及びアプリケーションデータ（図２、図８（ａ）参照）に対し、図９に示したＣＢＣモードの暗号化演算方式を用いることにより、図８（ｃ）に示すような暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎが得られる。
【００８１】
ステップＳ１０では、パケット構築部１１４は、暗号化部１０７及び暗号化後処理部１１３で求めた暗号ブロックＣ０´´、Ｃ０´、イニシャルベクトルＣ０、アプリケーションデータ及びＥＳＰトレイラの暗号処理結果の暗号ブロックＣ１、Ｃ２、…Ｃｎ、をこの順に並べて、さらにＩＰヘッダを付加して、図８（ｅ）に示すようなＩＰパケットを生成する。
【００８２】
以上のようにして生成されたＩＰパケットはパケット送信部１１６から送信される。
【００８３】
受信ノード１２では、上述のようにして送信ノード１１から送信されたＩＰパケットを受信すると、その中のＥＳＰパケットのペイロードから図８（ｂ）または図８（ｃ）に示すような暗号ブロック列を取り出す。この暗号ブロック列の先頭（例えば、Ｃ０´またはＣ０´´）は、従来のＣＢＣモードにおけるイニシャルベクトルと同じ扱いをすればよく、この暗号ブロック列は、従来のＣＢＣモードにおける復号処理と全く同じ手順で復号することができる。
【００８４】
すなわち、図５に示すように暗号化した結果得られる暗号ブロック列Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎに対しては、図１０に示すように、まず、Ｃ０´をイニシャルベクトルとみなし、２番目の暗号ブロックＣ０に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とＣ０´との排他的論理和演算（ＸＯＲ演算）を実施することにより、最初のブロックｍ１が得られる。次に、３番目の暗号データＣ２に対し復号演算（Ｅｋ−１（ ））を行い、その結果と２番目の暗号ブロックＣ０との排他的論理和演算（ＸＯＲ演算）を実施することにより、２番目のブロックｍ２が得られる。以下同様に復号して、ｍ１〜ｍｎまでのブロックを復号する。
【００８５】
また、図９に示すように暗号化した結果得られる暗号ブロック列Ｃ０´´、Ｃ０´、Ｃ０、Ｃ１、Ｃ２、…Ｃｎに対しては、図１１に示すように、まず、Ｃ０´´をイニシャルベクトルとみなし、２番目の暗号ブロックＣ０´に対し、ブロック暗号演算Ｅｋ（ ）に対応する復号演算（Ｅｋ−１（ ））を行い、その結果とＣ０´´との排他的論理和演算（ＸＯＲ演算）を実施することにより、最初のブロックｍ１−１が得られる。次に、３番目の暗号ブロックＣ０に対し復号演算（Ｅｋ−１（ ））を行い、その結果と２番目の暗号ブロックＣ０´との排他的論理和演算（ＸＯＲ演算）を実施することにより、２番目のブロックｍ１−２が得られる。以下同様に復号して、ｍ２〜ｍ３までのブロックも復号する。
【００８６】
この復号処理手順は、従来のＣＢＣモードにおける復号処理手順と全く同じであり、受信側の構成及び処理動作を変更する必要がない。
【００８７】
以上説明したように、上記実施形態によれば、１番目からＮ（Ｎは、２以上の整数）番目までの連続する複数の平文データブロック（例えば、１番目のデータブロックはヘッダ情報を含み、２番目からｎ−１番目のデータブロックはアプリケーションデータを含み、最後のｎ番目のデータブロックは、（残りのアプリケーションデータがあればそれと）ＥＳＰトレイラを含む）を暗号化して送信する際に、最初に得られた途中の（例えば２番目の）平文データブロックについては、該平文データブロックとイニシャルベクトルＣ０との排他的論理和に対し暗号演算を行うことにより暗号化し、３番目以降の平文データブロックは、該平文データブロックとその前の平文データブロックを暗号化した結果との排他的論理和に対し暗号演算を行うことにより暗号化し、２番目からＮ番目の暗号データブロックを生成する。
【００８８】
一方、１番目の平文データブロックは、例えば送信すべきアプリケーションデータがそろったときに得られるヘッダ情報であり、この１番目の平文データブロックについては、上記イニシャルベクトルＣ０に対し上記暗号演算に対応する復号演算を行い、その結果と１番目の平文データブロックとの排他的論理和を計算することにより、１番目の暗号データブロックを生成する。
【００８９】
そして、１番目の暗号データブロック、イニシャルベクトルＣ０、及び２番目からＮ番目の暗号データブロックをこの順に含むパケットを生成して、送信する。
【００９０】
このような構成により、トランスポートプロトコルヘッダ及びアプリケーションデータをブロック暗号ＣＢＣモードで暗号化して送信する処理において、復号処理に変更を加えることなく、アプリケーションデータの暗号化処理をトランスポートプロトコルヘッダ生成前の途中のブロックから実施することが可能となり、送信遅延を短縮することができる。
【００９１】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【００９２】
例えば、図６に示した各構成部の機能は、コンピュータに搭載されたプロセッサにプログラムを実行させることにより実現することができる。
【００９３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００９４】
【図１】本実施形態に係るネットワークの構成例を示した図。
【図２】ＣＢＣモードで暗号化されるデータの構成例を示した図。
【図３】従来のブロック暗号ＣＢＣモードの暗号化手順を用いたデータの送信処理を説明するためのフローチャート。
【図４】従来のブロック暗号ＣＢＣモードの暗号化手順を説明するための図。
【図５】本実施形態に係る暗号化手順（トランスポートプロトコルヘッダ長とブロック長とが等しい場合）を説明するための図。
【図６】図１の送信ノード（送信装置）の構成例を示した図。
【図７】図６の送信ノードにおけるデータの送信処理を説明するためのフローチャート。
【図８】図７の送信処理により送信ノードで生成される暗号ブロック列、この暗号ブロック列を含むＥＳＰ（Encapsulating Security Payload）パケットの構成例を示した図。
【図９】本実施形態に係る他の暗号化手順（トランスポートプロトコルヘッダ長がブロック長より長い場合）を説明するための図。
【図１０】図５の暗号化手順に対応する復号手順を説明するための図。
【図１１】図９の暗号化手順に対応する復号手順を説明するための図。
【符号の説明】
【００９５】
１１…送信ノード
１２…受信ノード
１３…ネットワーク
１０１…アプリケーションデータ取得部
１０２…ヘッダ情報抽出部
１０３…ヘッダ情報バッファ
１０４…先頭ブロック判定部
１０５…イニシャルベクトル生成部
１０６…イニシャルベクトルバッファ
１０７…暗号化部
１０８…アプリケーションバッファ
１０９…パケット送信判定部
１１０…ヘッダ生成部
１１１…ヘッダバッファ
１１３…暗号化後処理部
１１４…パケット構築部
１１５…パケット用バッファ
１１６…パケット送信部
【特許請求の範囲】
【請求項１】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置であって、
１番目のデータブロックについては、イニシャルベクトルと該１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化手段と、
前記ヘッダ情報を生成するヘッダ生成手段と、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化手段と、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成手段と、
前記暗号パケットを送信する送信手段と、
を含む送信装置。
【請求項２】
前記第２暗号化手段は、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成手段は、
前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル、及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項１記載の送信装置。
【請求項３】
前記送信手段は、前記暗号パケットを、ＩＰｓｅｃ（Security Architecture for Internet Protocol）におけるＥＳＰ（Encapsulated Security Payload）パケット中のペイロードとして送信する請求項１記載の送信装置。
【請求項４】
前記第１暗号化手段は、各データブロックが得られた度に、該データブロックを暗号化し、
前記ヘッダ生成手段は、前記ｎ個のヘッダブロックが全て得られたときに、前記ヘッダ情報を生成する請求項１記載の送信装置。
【請求項５】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信方法であって、
１番目のデータブロックに対しては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化ステップと、
前記ヘッダ情報を生成するヘッダ生成ステップと、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化ステップと、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成ステップと、
前記暗号パケットを送信する送信ステップと、
を含む送信方法。
【請求項６】
前記第２暗号化ステップは、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成ステップは、前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項５記載の送信方法。
【請求項７】
コンピュータを、
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置として機能させるためのプログラムであって、
前記コンピュータを、
１番目のデータブロックについては、イニシャルベクトルと該１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックは、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化手段、
前記ヘッダ情報を生成するヘッダ生成手段、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化手段、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成手段、
前記暗号パケットを送信する送信手段、
として機能させるためのプログラム。
【請求項８】
前記第２暗号化手段は、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成手段は、
前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル、及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項７記載のプログラム。
【請求項１】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置であって、
１番目のデータブロックについては、イニシャルベクトルと該１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化手段と、
前記ヘッダ情報を生成するヘッダ生成手段と、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化手段と、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成手段と、
前記暗号パケットを送信する送信手段と、
を含む送信装置。
【請求項２】
前記第２暗号化手段は、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成手段は、
前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル、及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項１記載の送信装置。
【請求項３】
前記送信手段は、前記暗号パケットを、ＩＰｓｅｃ（Security Architecture for Internet Protocol）におけるＥＳＰ（Encapsulated Security Payload）パケット中のペイロードとして送信する請求項１記載の送信装置。
【請求項４】
前記第１暗号化手段は、各データブロックが得られた度に、該データブロックを暗号化し、
前記ヘッダ生成手段は、前記ｎ個のヘッダブロックが全て得られたときに、前記ヘッダ情報を生成する請求項１記載の送信装置。
【請求項５】
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信方法であって、
１番目のデータブロックに対しては、イニシャルベクトルと１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックについては、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し前記暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化ステップと、
前記ヘッダ情報を生成するヘッダ生成ステップと、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化ステップと、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成ステップと、
前記暗号パケットを送信する送信ステップと、
を含む送信方法。
【請求項６】
前記第２暗号化ステップは、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成ステップは、前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項５記載の送信方法。
【請求項７】
コンピュータを、
１番目からｎ（ｎは、２以上の整数）番目までのｎ個のデータブロックと、当該ｎ個のデータブロックのヘッダ情報とを暗号化して送信する送信装置として機能させるためのプログラムであって、
前記コンピュータを、
１番目のデータブロックについては、イニシャルベクトルと該１番目のデータブロックとの排他的論理和に対し暗号演算を行うことにより暗号化し、２番目以降のデータブロックは、該データブロックとその前のデータブロックを暗号化した結果との排他的論理和に対し暗号演算を行うことにより暗号化して、ｎ個の暗号データブロックを生成する第１暗号化手段、
前記ヘッダ情報を生成するヘッダ生成手段、
前記イニシャルベクトルに対し前記暗号演算に対応する復号演算を行い、その結果と前記ヘッダ情報との排他的論理和を計算することにより、暗号ヘッダブロックを生成する第２暗号化手段、
前記暗号ヘッダブロック、前記イニシャルベクトル及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成するパケット生成手段、
前記暗号パケットを送信する送信手段、
として機能させるためのプログラム。
【請求項８】
前記第２暗号化手段は、
前記ヘッダ情報をＭ（Ｍは２以上の整数）個のヘッダブロックに分割することにより、１番目からＭ番目までのＭ個のヘッダブロックを生成し、
（ａ）Ｍ番目のヘッダブロックについては、前記イニシャルベクトルに対し前記復号演算を行い、その結果と前記Ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第Ｍ暗号ヘッダブロックを生成する処理と、（ｂ）前記Ｍ個のヘッダブロックのうちｍ（ｍはＭ−１以下１以上の任意の整数）番目のヘッダブロックについては、第ｍ＋１番目の暗号ヘッダブロックに対し前記復号演算を行い、その結果と前記ｍ番目のヘッダブロックとの排他的論理和を計算することにより暗号化して、第ｍ暗号ヘッダブロックを生成する処理と、を実行することにより、第１暗号ヘッダブロック乃至第Ｍ暗号ヘッダブロックを生成し、
前記パケット生成手段は、
前記第１暗号ヘッダブロック乃至前記第Ｍ暗号ヘッダブロック、前記イニシャルベクトル、及び前記ｎ個の暗号データブロックをこの順に含む暗号パケットを生成する請求項７記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−２３９６４１（Ｐ２００９−２３９６４１Ａ）
【公開日】平成２１年１０月１５日（２００９．１０．１５）
【国際特許分類】
【出願番号】特願２００８−８３４３３（Ｐ２００８−８３４３３）
【出願日】平成２０年３月２７日（２００８．３．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２１年１０月１５日（２００９．１０．１５）
【国際特許分類】
【出願日】平成２０年３月２７日（２００８．３．２７）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]