暗号化パケット処理システム
【課題】暗号化フラグメントパケットを簡易に送受信する。
【解決手段】装置は、平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加する処理部と、トンネルモードで受信した複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、トンネル用ヘッダからそれぞれ抽出した上記識別子を書き込んだ平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部とを備える。
【解決手段】装置は、平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加する処理部と、トンネルモードで受信した複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、トンネル用ヘッダからそれぞれ抽出した上記識別子を書き込んだ平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化パケット処理システムに関し、特にトンネルモードで送受信される複数分割の暗号化フラグメントパケットの処理技術に関する。
【背景技術】
【０００２】
インターネットなどのＩＰ（Internet Protocol）ネットワークを通して、第１及び第
２のローカルネットワーク間でパケットを送受信するパケット通信システムにおいては、セキュリティ保証のために、トンネルモードで暗号化パケットを送受信する。
【０００３】
トンネルモードで暗号化パケットを送受信する場合、暗号（認証を含む）処理及びカプセル処理に起因し、暗号化パケットのパケット長が平文パケットと比較して増大するので、ＩＰネットワークで規定された最大転送バイト長（最大伝送単位ＭＴＵ：Maximum Transfer Unit）を超えることがある。
【０００４】
これに対処するために、ＩＰネットワークの送信側に存在するパケット処理装置（例えば、ゲートウェイ装置）は、暗号化パケットをＭＴＵ値内に収まるようにフラグメント処理（分割または断片化処理）して送信する。一方、ＩＰネットワークの受信側に存在するパケット処理装置は、フラグメント処理された複数の暗号化パケット（暗号化フラグメントパケット）をリアセンブルした後、デカプセル処理及び復号（認証を含む）処理を施した平文パケットを第２のローカルネットワークに転送している。
【０００５】
しかし、この対処方法では、受信側パケット処理装置は、フラグメントパケットをリアセンブルした後に暗号化パケットを復号化するので、全ての複数のフラグメントパケットを受信するまで各パケットをバッファメモリに蓄積して待機する必要があり、パケット伝送遅延の増大を招くことを避けられない。
【０００６】
このような受信側パケット処理装置における問題を回避する関連技術が、例えば特開２００２−４４１３５号公報（特許文献１）に開示されている。
【０００７】
この特許文献１記載の技術においては、送信側の暗号装置は、受信した平文パケットを暗号処理する前に暗号処理後のパケット長を計算・判断し、ＭＴＵ値を超えるパケットについて暗号処理する前に平文のままフラグメントし、フラグメントしたパケット毎に暗号処理して送信する。一方、受信側の復号装置は、暗号化フラグメントパケット毎に復号処理し、暗号処理前の平文フラグメントパケットを得た後、受信側端末に送信している。
【０００８】
しかし、このように暗号処理の前に平文パケットをフラグメント処理してから暗号処理する技術では、ＩＰｓｅｃ（IP Security Protocol）のプロトコル種別、暗号アルゴリズム、及び認証アルゴリズムだけでなく、暗号ブロック単位及び認証ブロック単位にペイロードデータを合わせるためのパディング長によってもパケット長の増加分が異なり、フラグメント判断処理が煩雑になる。また、簡易にフラグメント判断を行うと、不必要なパケットまでもフラグメント処理する可能性がある。さらに、フラグメント処理後に暗号処理すると、暗号処理後にフラグメント処理する場合に比較して、オーバヘッドの増大を免れない。
【特許文献１】特開２００２−４４１３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
課題は、伝送遅延を招くことなく、かつ簡易な処理により、トンネルモードで複数分割の暗号化フラグメントパケットを送受信可能にする技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、パケット処理装置は、ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するフラグメント処理部と、前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部とを備える。ここで、前記ペイロードデータの後部所定数は、前記暗号対象領域の開始位置と前記認証対象領域の開始位置との差分のバイト数に対応する。
【発明の効果】
【００１１】
開示したパケット処理装置によれば、暗号処理前にフラグメント要否判断を行ってフラグメント処理を行うことなく、通常に認証及び暗号処理した後、フラグメント要否判断を行い、かつフラグメント処理された全ての暗号化フラグメントパケットが受信されるまで待機しておくことなく、複数の平文フラグメントパケットの状態で受信端に向けて送信することができる。
【００１２】
他の課題、特徴及び利点は、図面及び特許請求の範囲とともに取り上げられる際に、以下に記載される発明を実施するための最良の形態を読むことにより明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して、さらに詳細に説明する。図面には好ましい実施形態が示されている。しかし、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されると解釈されてはならない。
【００１４】
［システム構成］
一実施の形態における暗号化パケット処理システムの構成を示す図１を参照すると、この暗号化パケット処理システムＳＹＳにおいては、インターネットなどのＩＰ（Internet
Protocol）ネットワーク１を通して、対向する第１のローカルネットワーク２及び第２
のローカルネットワーク３間で（厳密には、これらのローカルネットワークにそれぞれ収容されている端末などの通信装置間で）ＩＰパケットを送受信する場合、セキュリティ保証のために、ＩＰトンネル４を通してトンネルモードで暗号化パケットを送受信する。
【００１５】
トンネルモードで暗号化パケットを送受信する場合、暗号（認証を含む）処理及びカプセル処理に起因し、暗号化パケットのパケット長が元のＩＰパケット（平文パケット）と比較して増大するので、ＩＰネットワーク１のＩＰトンネル４で規定された最大転送バイト長（最大伝送単位ＭＴＵ：Maximum Transfer Unit）を超えることがある。
【００１６】
このために、ＩＰネットワーク１の送信側に存在するパケット処理装置（例えば、ゲートウェイ装置）１０は、暗号化パケットをＭＴＵ値内に収まるようにフラグメント処理（分割または断片化処理）して送信する。一方、ＩＰネットワーク１の受信側に存在するパ
ケット処理装置２０は、フラグメント処理された暗号化パケット（暗号化フラグメントパケット）にデカプセル処理及び復号（認証を含む）処理を施した複数の（少なくとも２つの）平文フラグメントパケットを第２のローカルネットワーク３に転送する。
【００１７】
［パケット処理装置の構成］
図２は、図１に示す一実施の形態の暗号化パケット処理システムＳＹＳにおける送信側及び受信側パケット処理装置１０，２０の構成を示すブロック図である。
【００１８】
送信側パケット処理装置１０においては、暗号（認証を含む）処理及びカプセル処理後の暗号化パケットに対してＭＴＵ値オーバによるフラグメント処理の必要が発生した場合、各フラグメントパケット内で暗号ブロック単位及び認証ブロック単位がクローズ（完結）するように、つまり暗号及び認証処理が各フラグメント内で実行できるように、フラグメント処理を実行する。
【００１９】
そのために、各フラグメントパケットのデータ長が暗号ブロック単位及び認証ブロック単位のバイト数の公倍数となるように、及び認証範囲（認証対象領域）の開始位置と暗号範囲（暗号対象領域）の開始位置とのずれによる認証ブロックと暗号ブロックとの差分を次のフラグメントパケットの先頭に（ペイロードデータの前に）重複して挿入するように、並びにトレイラ全体を認証データと共に最終フラグメントパケット内に収めるように、フラグメント処理を実行する。
【００２０】
また、受信側パケット処理装置２０においては、受信した暗号化フラグメントパケット毎にデカプセル処理、復号処理、及び認証処理を行い、全ての暗号化フラグメントパケットの受信を待つことなく、各平文フラグメントパケットとしてそのまま第２のローカルネットワーク３に送信する。
【００２１】
一層詳述すると、送信側パケット処理装置１０においては、受信部１１で受信した第１のローカルネットワーク１からの平文のＩＰパケット（平文パケット）に対して、暗号・認証・カプセル処理部１２は暗号処理、認証処理及びカプセル処理を施して、暗号化パケットを生成する。フラグメント判定部１３は、生成された暗号化パケットのパケット長とＭＴＵ値との比較を行い、ＭＴＵ値を超えているときは（フラグメント要のときは）、フラグメント処理部１４に暗号化パケットを入力する。また、フラグメント判定部１３は、暗号化パケットのパケット長がＭＴＵ値を超えていないときは（フラグメント不要のときは）、暗号化パケットをそのまま送信部１５に入力する。
【００２２】
フラグメント処理部１４は、暗号化パケットに対して、フラグメント処理を行う。フラグメント処理を施された複数の暗号化フラグメントパケット及びフラグメント判定部１３からの暗号化パケットは、送信部１５からＩＰネットワーク１のＩＰトンネル４を通して、受信側パケット処理装置２０に送信される。
【００２３】
受信側パケット処理装置２０において、受信部２１は送信側パケット処理装置１０から送信された暗号化パケット（暗号化フラグメントパケットを含む）をＩＰネットワーク１のＩＰトンネル４を通して受信する。フラグメント判定部２２は受信された暗号化パケットのフラグメント有無をトンネル用ＩＰヘッダ内のフラグメント制御情報に基づいて判定する。
【００２４】
順序補正部２３は、複数の暗号化フラグメントパケットの受信順が逆転していた場合、対象のフラグメントパケットを一時的にバッファメモリに待機して順序を補正するが、順序逆転の確率は非常に小さい。送信側パケット処理装置１０における送信制御により、フラグメントパケットの順序逆転が発生しない場合は、順序補正部２３は不必要となる。第
１の復号・認証・デカプセル制御部２４は、フラグメント処理されていない暗号化パケットに対して、通常の復号処理、認証処理、及びデカプセル処理を施すための制御を行う。
【００２５】
クラシファイテーブル２５Ａ及びＳＡＤＢ（Security Association Data Base）テーブル２５Ｂは、ＩＰｓｅｃ処理すべきパケットの処理アルゴリズム及びキー情報などを確定するために使用される。クラシファイテーブル２５Ａは、トンネル用ＩＰヘッダ内の送信元（ソース）アドレス（Source Address）及び宛先アドレス（Destination Address）と
、暗号ヘッダとしてのＥＳＰ（Encapsulating Security Payload）ヘッダ内のＳＰＩ（Security Parameters Index）情報などにより、ＳＡＤＢテーブル２５Ｂのエントリー番号
ＳＡ−ＩＤを抽出する。このエントリー番号ＳＡ−ＩＤに基づき、ＳＡＤＢテーブル２５Ｂ内からそのパケットに適用すべきＩＰｓｅｃのアルゴリズム及びキー情報などが選択できる。
【００２６】
ここで、ＳＰＩ情報は、ＥＳＰトンネルモードで接続される第１及び第２のローカルネットワーク２，３間の安全なＩＰトンネル４に対応するＳＡ（Security Association）を識別するための識別情報である。
【００２７】
復号・認証アルゴリズム実行部２６は、暗号アルゴリズム及び認証アルゴリズムに従って、復号ブロック単位及び認証ブロック単位に復号処理及び認証処理（認証演算処理と記載することもある）を行う。第２の復号・認証・デカプセル制御部２７は、フラグメント処理された暗号化フラグメントパケットに対して、後に詳述する復号処理、認証処理、及びデカプセル処理を施すための制御を行う。
【００２８】
継続制御用テーブル２８は、複数の暗号化フラグメントパケットについて、デカプセル処理及び復号処理を施して複数の平文フラグメントパケットを作成するための継続（引継）情報を格納するテーブルである。この継続制御用テーブル２８には、受信中の暗号化フラグメントパケットのフラグメント識別子ＦＩＤ及び送信元ＩＰアドレスに基づいて他の暗号化フラグメントパケットと区別された番号毎にエントリー番号ＳＡ−ＩＤなどの各種情報が格納される（図３参照）。
【００２９】
送信部２９は、第１及び第２の復号・認証・デカプセル制御部２４，２７からの平文パケット及び平文フラグメントパケットを第２のローカルネットワーク３に送信する。
【００３０】
上述した暗号化パケット処理システムＳＹＳにおけるパケット処理装置１０，２０は、送信側及び受信側のパケット処理機能だけをそれぞれ有する構成として説明したが、実際の運用では、各パケット処理装置１０，２０が双方のパケット処理機能を有する構成であることは、当業者が容易に理解できることである。
【００３１】
［送信側パケット処理装置における処理］
次に、図１、図２及び図３に示す送信側パケット処理装置１０におけるパケット処理について、図４及び図６を併せ参照して説明する。
【００３２】
図４は暗号化プロトコルをＥＳＰ（暗号ペイロード）トンネルモードとした場合の送信側パケット処理装置１０における暗号化フラグメントパケットの生成処理例を説明するための図である。また、図６は送信側パケット処理装置１０におけるパケット生成処理の概要手順を示すフローチャートである。
【００３３】
送信側パケット処理装置１０においてＥＳＰトンネルモードで暗号化パケットを送信するとき、図４に示すように、ＩＰｖ４（Internet Protocol Version 4）の暗号化パケッ
トは、元のＩＰパケット（平文パケット）に対して、暗号範囲（暗号対象領域）を暗号単
位（例えば、８／１６／３２バイト）に合わせ、かつ認証範囲（認証対象領域）を４バイトアライメントに合わせるために、パディング、パディング長、及び次ヘッダからなるＥＳＰトレイラを平文パケットのペイロードデータの最後に付加した全領域に対応するＥＳＰペイロードが暗号処理される。
【００３４】
また、暗号化パケットには、ＥＳＰペイロードの前に、暗号アルゴリズム及び認証アルゴリズムの判定のためのＳＰＩ情報を含むＥＳＰヘッダ（８バイト）が付加されると共に、ＥＳＰペイロードの後に、ＥＳＰ認証データが付加される。さらに、暗号化パケットには、ＥＳＰヘッダ、ＥＳＰペイロード、及びＥＳＰ認証データをカプセル処理するためのトンネル用ＩＰヘッダ（２０バイトのＯｕｔ＿ＩＰヘッダ）が付加される。
【００３５】
ここで、暗号範囲はＥＳＰペイロードの領域に対応し、認証範囲はＥＳＰヘッダ及びＥＳＰペイロードの双方の領域に対応する。
【００３６】
上述したような平文パケットから暗号化パケットを生成する処理は、送信側パケット処理装置１０における暗号・認証・カプセル処理部１２によって実施される（図６中のＴ１１）。
【００３７】
この暗号化パケットの生成処理において、オリジナルＩＰヘッダ（２０バイトのＯｒｉ＿ＩＰヘッダ）及び複数のペイロードａ，ｂ，ｃから構成される平文パケットに付加された領域部分に応じて、暗号化パケットのパケット長がＭＴＵ値を超えたことをフラグメント判定部１３が判定した場合（図６中のＴ１２）、フラグメント処理部１４は次の条件でフラグメント処理を実行する（図６中のＴ１３）。
【００３８】
条件１：各フラグメントパケットにおいては、暗号ブロック単位及び認証ブロック単位で暗号範囲及び認証範囲が分割できるので、暗号化パケットのＬ１及びＬ２の値を暗号単位及び暗号ブロック単位に合わせる。例えば、暗号単位として、８／１６／３２バイトが用いられ、かつ認証単位として６４バイトが用いられる場合は、８，１６，３２，６４の最小公倍数である６４の倍数を暗号ブロック単位及び認証ブロック単位に選ぶことができる。
【００３９】
条件２：暗号化パケットにおいて、認証範囲の開始位置と暗号範囲の開始位置とが異なるので、先の（先頭または中間の）フラグメントパケットの最終データ（ペイロードデータ）を認証範囲の開始位置と暗号範囲の開始位置とのずれ分（つまり、ＥＳＰトンネルモードでは８バイト分）を、次の（中間または最終の）フラグメントパケットの先頭データとして重複して挿入する。
【００４０】
条件３：「パディング長」のデータが「パディング」のデータの後に送信され、「パディング長」を受信しないときは、「パディング」の削除ができないので、ＥＳＰトレイラをＥＳＰ認証データと共に一つのフラグメントパケット（最終フラグメントパケット）に取り込む。ここで、パディング長は１−２５５バイトの範囲と規定されている（ＲＦＣ２４０６）。また、ＥＳＰ認証データは、暗号化し終わったパケットと暗号鍵とから算出したハッシュ値であり、１２／１６／２０バイト（ＨＭＡＣ−ＳＨＡ−１＝２０バイト、ＨＭＡＣ−ＭＤ５＝１６バイト、ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６＝１２バイト）が用いられるとすると、最終フラグメントパケットのデータ長Ｌ３を、パディング（１−２５５バイト）＋パディグ長（１バイト）＋次ヘッダ（１バイト）＋ＥＳＰ認証データ（２０バイト）に基づいて、２７７バイトまたは２７８バイト以上とすればよい。
【００４１】
上述した条件１−３に従ってフラグメント処理された先頭、中間、及び最終の暗号化フラグメントパケットの各フラグメントオフセット値は、「０，Ｌ１，及びＬ１＋Ｌ２」で
あり、フラグメント処理部１４によって各トンネル用ＩＰヘッダ内に格納されて送信される。
【００４２】
［受信側パケット処理装置における処理］
次に、図１、図２及び図３に示す受信側パケット処理装置２０におけるパケット処理について、図５、図７Ａ、図７Ｂ及び図７Ｃを併せ参照して説明する。
【００４３】
図５は暗号化プロトコルをＥＳＰトンネルモードとした場合の受信側パケット処理装置２０における暗号化フラグメントパケット処理例を説明するための図である。また、図７Ａ、図７Ｂ及び図７Ｃは受信側パケット処理装置２０におけるパケット処理手順を示すフローチャートである。
【００４４】
なお、以下に説明するパケット処理において、受信した暗号化パケットが暗号化フラグメントパケットであることは、トンネル用ＩＰヘッダ内のプロトコル及びフラグメント制御情報（ＩＰｖ４の場合、Ｄ＝Ｄｏｎ’ｔ Ｆｒａｇｍｅｎｔ、Ｍ＝Ｍｏｒｅ Ｆｒａｇｍｅｎｔ、Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ、ＦＩＤ＝フラグメント識別子）に基づいて識別できる。例えば、Ｐｒｏｔｏｃｏｌ＝５０の場合がＥＳＰ暗号化パケットである。また、Ｄ＝１の場合、フラグメントパケットであり、同一パケットからフラグメントされたパケットは、同一ＦＩＤが付与される。Ｄ＝１，Ｍ＝１，Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ＝０の場合、先頭フラグメントパケット、Ｄ＝１，Ｍ＝１，Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ≠０の場合、中間フラグメントパケット、またＤ＝１，Ｍ＝０の場合、最終フラグメントパケットと識別できる（図７Ａ，図７Ｂ中のＲ１，Ｒ２，Ｒ３）。
【００４５】
まず、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した先頭のフラグメント処理された暗号化パケット（先頭の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ先頭の平文フラグメントパケットとして送信する。
【００４６】
Ｒ１１：制御部２７は、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ１）内のフラグメント識別子ＦＩＤ、送信元ＩＰアドレス及び宛先ＩＰアドレスと、ＥＳＰヘッダ内のＳＰＩ情報などとにより、クラシファイテーブル２５Ａを検索して、ＳＡＤＢテーブル２５Ｂ内の対応のエントリー番号ＳＡ−ＩＤを得て、フラグメント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された（縮退して付与された）番号対応に継続制御用テーブル２８にそのエントリー番号ＳＡ−ＩＤを格納する。
【００４７】
Ｒ１２：実行部２６は、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納された認証アルゴリズム及び認証用キー情報などに従い、認証ブロック単位に認証演算を行う。また、制御部２７は、最終ブロックの認証演算引継情報を上記処理Ｒ１１と同様に継続制御用テーブル２８に格納する。
【００４８】
Ｒ１３：さらに、実行部２６は、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納された暗号アルゴリズム及び暗号キー情報などに従って、暗号ブロック単位に復号処理を実行する。また、制御部２７は、最終ブロックの復号演算引継情報を上記処理Ｒ１１と同様に継続制御用テーブル２５Ｂに格納する。
【００４９】
Ｒ１４：制御部２７は、実行部２６によって復号化されたデータからオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ）を抽出すると共に、ペイロードを作成する。
【００５０】
Ｒ１５：制御部２７は、抽出したオリジナルＩＰヘッダに対して、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ１）よりフラグメント情報としてのオフセット値「０」を抽
出して挿入する。また、制御部２７は、ＴＴＬ（Time to Live）、パケット長、及びヘッダチェックサムを算出して挿入し、先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を作成し、後の処理Ｒ１７において上記処理Ｒ１１と同様に継続制御用テーブル２８に格納する。
【００５１】
Ｒ１６：制御部２７は、上記処理Ｒ１４及びＲ１５で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）及び復号データ（ペイロードａ）より、先頭の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００５２】
また、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した中間（ここでは、１つ）のフラグメント処理された暗号化パケット（中間の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ中間の平文フラグメントパケットとして送信する。
【００５３】
Ｒ２１：制御部２７は、先頭の暗号化フラグメントパケットの受信時に格納されたフラグメント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された番号対応のエントリー番号ＳＡ−ＩＤを継続制御用テーブル２８から取り出す。
【００５４】
Ｒ２２：制御部２７は、継続制御用テーブル２８に格納された認証演算引継情報を認証演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている認証アルゴリズム及び認証キー情報などに従い、実行部２６よって認証ブロック単位に認証演算を行わせる。また、制御部２７は、最終ブロックの認証演算引継情報を継続制御用テーブル２８の同一領域に上書きして格納する。
【００５５】
Ｒ２３：さらに、制御部２７は、継続制御用テーブル２８に格納された復号演算引継情報を復号演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている暗号アルゴリズム及び暗号キー情報などに従って、実行部２６によって暗号ブロック単位（先頭８バイトを除く）に復号処理を実行させる。制御部２７は、最終ブロックの復号演算引継情報を継続制御用テーブル２８の同一領域に上書きして格納する。制御部２７は、実行部２６によって復号化されたデータからオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ）を抽出すると共に、ペイロードを作成する。
【００５６】
Ｒ２４：制御部２７は、継続制御用テーブル２８に格納された先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を取り出し、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ２）よりオフセット値「Ｌ１」を抽出して挿入する。また、制御部２７は、ＴＴＬ、パケット長、及びヘッダチェックサムを算出して挿入し、中間の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ２）を作成する。
【００５７】
Ｒ２５：制御部２７は、上記処理Ｒ２３及びＲ２４で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ２）及び復号データ（ペイロードｂ）に基づいて、中間の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００５８】
さらに、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した最終のフラグメント処理された暗号化パケット（最終の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ最終の平文フラグメントパケットとして送信する。
【００５９】
Ｒ３１：制御部２７は、先頭の平文フラグメントパケットの受信時に格納されたフラグ
メント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された番号対応のエントリー番号ＳＡ−ＩＤを継続制御用テーブル２８から取り出す。
【００６０】
Ｒ３２：制御部２７は、継続制御用テーブル２８に格納された認証演算引継情報を認証演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている認証アルゴリズム及び認証キー情報などに従い、実行部２６によって認証ブロック単位に認証演算を行わせ、最後のデータのＥＳＰ認証データと演算照合して認証判定を行う。
【００６１】
Ｒ３３：さらに、制御部２７は、継続制御用テーブル２８に格納された復号演算引継情報を復号演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている暗号アルゴリズム及び暗号キー情報などに従って、実行部２６によって暗号ブロック単位（先頭８バイトを除く）に復号処理を実行させる。
【００６２】
Ｒ３４：制御部２７は、復号処理後のデータからペイロードを作成すると共に、トレイラ及び認証データを削除する。
【００６３】
Ｒ３５：制御部２７は、継続制御用テーブル２８に格納された先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を取り出し、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ３）よりオフセット値「Ｌ１＋Ｌ２」を抽出して挿入する。また、制御部２７は、ＴＴＬ、パケット長、及びヘッダチェックサムを算出して挿入し、最終の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）を作成する。
【００６４】
Ｒ３６：制御部２７は、上記処理Ｒ３４及びＲ３５で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）及び復号データ（ペイロードｃ）に基づいて、最終の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００６５】
Ｒ３７：ただし、上記処理Ｒ３２に続く認証判定が異常「ＮＧ」となった場合は、オリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）の情報、例えばオフセット値「Ｌ１＋Ｌ２」を「０」に改ざんして送信することにより、受信先でフラグメントエラーとして廃棄させる。
【００６６】
上述した受信側パケット処理装置２０のパケット処理において、受信した先頭、中間、及び最終の暗号化フラグメントパケットに順序逆転が発生した場合は、順序補正部２３によって、受信したパケットをバッファメモリに一時的に待機して順序を補正した後、上記各処理を実行すればよい。ただし、現状のネットワーク構成装置としてのゲートウェイ装置などは、パケットの順序保証を行っているものが多く存在し、また送信側のフラグメント処理で各フラグメントパケット長を操作（ほぼ同等または後のフラグメント長を大きくになるようにフラグメント処理）すれば、順序逆転の確率は非常に小さくなる。したがって、受信するパケットの順序逆転が発生しないことを前提すれば、順序補正部２３は不要となる。
【００６７】
［一実施の形態の効果］
上述した一実施の形態によれば、暗号・認証・カプセル処理に起因するパケット長の増大によりＭＴＵ値超えが発生した暗号化パケットを簡易にフラグメント処理し、トンネルモードで送信した場合、受信側パケット処理装置においてリアセンブル処理のためにフラグメント処理された全ての暗号化パケットが受信されるまで待機する必要がなく、パケット処理装置内の伝送遅延の削減が図れ、ネットワークの伝送性能を向上させることができる。
【００６８】
［変形例］
上述した一実施の形態における処理はコンピュータで実行可能なプログラムとして提供され、ＣＤ−ＲＯＭやフレキシブルディスクなどの記録媒体、さらには通信回線を経て提供可能である。
【００６９】
また、上述した一実施の形態における各処理はその任意の複数または全てを選択し組合せて実施することもできる。
【図面の簡単な説明】
【００７０】
【図１】一実施の形態の暗号化パケット処理システムの構成を示すブロック図である。
【図２】図１におけるパケット処理装置の構成を示すブロック図である。
【図３】継続制御用テーブルの構成を示す図である。
【図４】送信側パケット処理装置におけるパケット生成処理を説明するための図である。
【図５】受信側パケット処理装置におけるパケット処理を説明するための図である。
【図６】送信側パケット処理装置におけるパケット生成処理手順を説明するためのフローチャート図である。
【図７Ａ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【図７Ｂ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【図７Ｃ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【符号の説明】
【００７１】
ＳＹＳ 暗号化パケット処理システム
１ ＩＰネットワーク
２ ローカルネットワーク
３ ローカルネットワーク
４ ＩＰトンネル
１０ 送信側パケット処理装置
２０ 受信側パケット処理装置
１１ 受信部
１２ 暗号・認証・カプセル処理部
１３ フラグメント判定部
１４ フラグメント処理部
１５ 送信部
２１ 受信部
２２ フラグメント判定部
２３ 順序補正部
２４ 第１の復号・認証・デカプセル制御部
２５Ａ クラシファイテーブル
２５Ｂ ＳＡＤＢテーブル
２６ 復号・認証アルゴリズム実行部
２７ 第２の復号・認証・デカプセル制御部
２８ 継続制御用テーブル
２９ 送信部
【技術分野】
【０００１】
本発明は、暗号化パケット処理システムに関し、特にトンネルモードで送受信される複数分割の暗号化フラグメントパケットの処理技術に関する。
【背景技術】
【０００２】
インターネットなどのＩＰ（Internet Protocol）ネットワークを通して、第１及び第
２のローカルネットワーク間でパケットを送受信するパケット通信システムにおいては、セキュリティ保証のために、トンネルモードで暗号化パケットを送受信する。
【０００３】
トンネルモードで暗号化パケットを送受信する場合、暗号（認証を含む）処理及びカプセル処理に起因し、暗号化パケットのパケット長が平文パケットと比較して増大するので、ＩＰネットワークで規定された最大転送バイト長（最大伝送単位ＭＴＵ：Maximum Transfer Unit）を超えることがある。
【０００４】
これに対処するために、ＩＰネットワークの送信側に存在するパケット処理装置（例えば、ゲートウェイ装置）は、暗号化パケットをＭＴＵ値内に収まるようにフラグメント処理（分割または断片化処理）して送信する。一方、ＩＰネットワークの受信側に存在するパケット処理装置は、フラグメント処理された複数の暗号化パケット（暗号化フラグメントパケット）をリアセンブルした後、デカプセル処理及び復号（認証を含む）処理を施した平文パケットを第２のローカルネットワークに転送している。
【０００５】
しかし、この対処方法では、受信側パケット処理装置は、フラグメントパケットをリアセンブルした後に暗号化パケットを復号化するので、全ての複数のフラグメントパケットを受信するまで各パケットをバッファメモリに蓄積して待機する必要があり、パケット伝送遅延の増大を招くことを避けられない。
【０００６】
このような受信側パケット処理装置における問題を回避する関連技術が、例えば特開２００２−４４１３５号公報（特許文献１）に開示されている。
【０００７】
この特許文献１記載の技術においては、送信側の暗号装置は、受信した平文パケットを暗号処理する前に暗号処理後のパケット長を計算・判断し、ＭＴＵ値を超えるパケットについて暗号処理する前に平文のままフラグメントし、フラグメントしたパケット毎に暗号処理して送信する。一方、受信側の復号装置は、暗号化フラグメントパケット毎に復号処理し、暗号処理前の平文フラグメントパケットを得た後、受信側端末に送信している。
【０００８】
しかし、このように暗号処理の前に平文パケットをフラグメント処理してから暗号処理する技術では、ＩＰｓｅｃ（IP Security Protocol）のプロトコル種別、暗号アルゴリズム、及び認証アルゴリズムだけでなく、暗号ブロック単位及び認証ブロック単位にペイロードデータを合わせるためのパディング長によってもパケット長の増加分が異なり、フラグメント判断処理が煩雑になる。また、簡易にフラグメント判断を行うと、不必要なパケットまでもフラグメント処理する可能性がある。さらに、フラグメント処理後に暗号処理すると、暗号処理後にフラグメント処理する場合に比較して、オーバヘッドの増大を免れない。
【特許文献１】特開２００２−４４１３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
課題は、伝送遅延を招くことなく、かつ簡易な処理により、トンネルモードで複数分割の暗号化フラグメントパケットを送受信可能にする技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、パケット処理装置は、ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するフラグメント処理部と、前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部とを備える。ここで、前記ペイロードデータの後部所定数は、前記暗号対象領域の開始位置と前記認証対象領域の開始位置との差分のバイト数に対応する。
【発明の効果】
【００１１】
開示したパケット処理装置によれば、暗号処理前にフラグメント要否判断を行ってフラグメント処理を行うことなく、通常に認証及び暗号処理した後、フラグメント要否判断を行い、かつフラグメント処理された全ての暗号化フラグメントパケットが受信されるまで待機しておくことなく、複数の平文フラグメントパケットの状態で受信端に向けて送信することができる。
【００１２】
他の課題、特徴及び利点は、図面及び特許請求の範囲とともに取り上げられる際に、以下に記載される発明を実施するための最良の形態を読むことにより明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して、さらに詳細に説明する。図面には好ましい実施形態が示されている。しかし、多くの異なる形態で実施されることが可能であり、本明細書に記載される実施形態に限定されると解釈されてはならない。
【００１４】
［システム構成］
一実施の形態における暗号化パケット処理システムの構成を示す図１を参照すると、この暗号化パケット処理システムＳＹＳにおいては、インターネットなどのＩＰ（Internet
Protocol）ネットワーク１を通して、対向する第１のローカルネットワーク２及び第２
のローカルネットワーク３間で（厳密には、これらのローカルネットワークにそれぞれ収容されている端末などの通信装置間で）ＩＰパケットを送受信する場合、セキュリティ保証のために、ＩＰトンネル４を通してトンネルモードで暗号化パケットを送受信する。
【００１５】
トンネルモードで暗号化パケットを送受信する場合、暗号（認証を含む）処理及びカプセル処理に起因し、暗号化パケットのパケット長が元のＩＰパケット（平文パケット）と比較して増大するので、ＩＰネットワーク１のＩＰトンネル４で規定された最大転送バイト長（最大伝送単位ＭＴＵ：Maximum Transfer Unit）を超えることがある。
【００１６】
このために、ＩＰネットワーク１の送信側に存在するパケット処理装置（例えば、ゲートウェイ装置）１０は、暗号化パケットをＭＴＵ値内に収まるようにフラグメント処理（分割または断片化処理）して送信する。一方、ＩＰネットワーク１の受信側に存在するパ
ケット処理装置２０は、フラグメント処理された暗号化パケット（暗号化フラグメントパケット）にデカプセル処理及び復号（認証を含む）処理を施した複数の（少なくとも２つの）平文フラグメントパケットを第２のローカルネットワーク３に転送する。
【００１７】
［パケット処理装置の構成］
図２は、図１に示す一実施の形態の暗号化パケット処理システムＳＹＳにおける送信側及び受信側パケット処理装置１０，２０の構成を示すブロック図である。
【００１８】
送信側パケット処理装置１０においては、暗号（認証を含む）処理及びカプセル処理後の暗号化パケットに対してＭＴＵ値オーバによるフラグメント処理の必要が発生した場合、各フラグメントパケット内で暗号ブロック単位及び認証ブロック単位がクローズ（完結）するように、つまり暗号及び認証処理が各フラグメント内で実行できるように、フラグメント処理を実行する。
【００１９】
そのために、各フラグメントパケットのデータ長が暗号ブロック単位及び認証ブロック単位のバイト数の公倍数となるように、及び認証範囲（認証対象領域）の開始位置と暗号範囲（暗号対象領域）の開始位置とのずれによる認証ブロックと暗号ブロックとの差分を次のフラグメントパケットの先頭に（ペイロードデータの前に）重複して挿入するように、並びにトレイラ全体を認証データと共に最終フラグメントパケット内に収めるように、フラグメント処理を実行する。
【００２０】
また、受信側パケット処理装置２０においては、受信した暗号化フラグメントパケット毎にデカプセル処理、復号処理、及び認証処理を行い、全ての暗号化フラグメントパケットの受信を待つことなく、各平文フラグメントパケットとしてそのまま第２のローカルネットワーク３に送信する。
【００２１】
一層詳述すると、送信側パケット処理装置１０においては、受信部１１で受信した第１のローカルネットワーク１からの平文のＩＰパケット（平文パケット）に対して、暗号・認証・カプセル処理部１２は暗号処理、認証処理及びカプセル処理を施して、暗号化パケットを生成する。フラグメント判定部１３は、生成された暗号化パケットのパケット長とＭＴＵ値との比較を行い、ＭＴＵ値を超えているときは（フラグメント要のときは）、フラグメント処理部１４に暗号化パケットを入力する。また、フラグメント判定部１３は、暗号化パケットのパケット長がＭＴＵ値を超えていないときは（フラグメント不要のときは）、暗号化パケットをそのまま送信部１５に入力する。
【００２２】
フラグメント処理部１４は、暗号化パケットに対して、フラグメント処理を行う。フラグメント処理を施された複数の暗号化フラグメントパケット及びフラグメント判定部１３からの暗号化パケットは、送信部１５からＩＰネットワーク１のＩＰトンネル４を通して、受信側パケット処理装置２０に送信される。
【００２３】
受信側パケット処理装置２０において、受信部２１は送信側パケット処理装置１０から送信された暗号化パケット（暗号化フラグメントパケットを含む）をＩＰネットワーク１のＩＰトンネル４を通して受信する。フラグメント判定部２２は受信された暗号化パケットのフラグメント有無をトンネル用ＩＰヘッダ内のフラグメント制御情報に基づいて判定する。
【００２４】
順序補正部２３は、複数の暗号化フラグメントパケットの受信順が逆転していた場合、対象のフラグメントパケットを一時的にバッファメモリに待機して順序を補正するが、順序逆転の確率は非常に小さい。送信側パケット処理装置１０における送信制御により、フラグメントパケットの順序逆転が発生しない場合は、順序補正部２３は不必要となる。第
１の復号・認証・デカプセル制御部２４は、フラグメント処理されていない暗号化パケットに対して、通常の復号処理、認証処理、及びデカプセル処理を施すための制御を行う。
【００２５】
クラシファイテーブル２５Ａ及びＳＡＤＢ（Security Association Data Base）テーブル２５Ｂは、ＩＰｓｅｃ処理すべきパケットの処理アルゴリズム及びキー情報などを確定するために使用される。クラシファイテーブル２５Ａは、トンネル用ＩＰヘッダ内の送信元（ソース）アドレス（Source Address）及び宛先アドレス（Destination Address）と
、暗号ヘッダとしてのＥＳＰ（Encapsulating Security Payload）ヘッダ内のＳＰＩ（Security Parameters Index）情報などにより、ＳＡＤＢテーブル２５Ｂのエントリー番号
ＳＡ−ＩＤを抽出する。このエントリー番号ＳＡ−ＩＤに基づき、ＳＡＤＢテーブル２５Ｂ内からそのパケットに適用すべきＩＰｓｅｃのアルゴリズム及びキー情報などが選択できる。
【００２６】
ここで、ＳＰＩ情報は、ＥＳＰトンネルモードで接続される第１及び第２のローカルネットワーク２，３間の安全なＩＰトンネル４に対応するＳＡ（Security Association）を識別するための識別情報である。
【００２７】
復号・認証アルゴリズム実行部２６は、暗号アルゴリズム及び認証アルゴリズムに従って、復号ブロック単位及び認証ブロック単位に復号処理及び認証処理（認証演算処理と記載することもある）を行う。第２の復号・認証・デカプセル制御部２７は、フラグメント処理された暗号化フラグメントパケットに対して、後に詳述する復号処理、認証処理、及びデカプセル処理を施すための制御を行う。
【００２８】
継続制御用テーブル２８は、複数の暗号化フラグメントパケットについて、デカプセル処理及び復号処理を施して複数の平文フラグメントパケットを作成するための継続（引継）情報を格納するテーブルである。この継続制御用テーブル２８には、受信中の暗号化フラグメントパケットのフラグメント識別子ＦＩＤ及び送信元ＩＰアドレスに基づいて他の暗号化フラグメントパケットと区別された番号毎にエントリー番号ＳＡ−ＩＤなどの各種情報が格納される（図３参照）。
【００２９】
送信部２９は、第１及び第２の復号・認証・デカプセル制御部２４，２７からの平文パケット及び平文フラグメントパケットを第２のローカルネットワーク３に送信する。
【００３０】
上述した暗号化パケット処理システムＳＹＳにおけるパケット処理装置１０，２０は、送信側及び受信側のパケット処理機能だけをそれぞれ有する構成として説明したが、実際の運用では、各パケット処理装置１０，２０が双方のパケット処理機能を有する構成であることは、当業者が容易に理解できることである。
【００３１】
［送信側パケット処理装置における処理］
次に、図１、図２及び図３に示す送信側パケット処理装置１０におけるパケット処理について、図４及び図６を併せ参照して説明する。
【００３２】
図４は暗号化プロトコルをＥＳＰ（暗号ペイロード）トンネルモードとした場合の送信側パケット処理装置１０における暗号化フラグメントパケットの生成処理例を説明するための図である。また、図６は送信側パケット処理装置１０におけるパケット生成処理の概要手順を示すフローチャートである。
【００３３】
送信側パケット処理装置１０においてＥＳＰトンネルモードで暗号化パケットを送信するとき、図４に示すように、ＩＰｖ４（Internet Protocol Version 4）の暗号化パケッ
トは、元のＩＰパケット（平文パケット）に対して、暗号範囲（暗号対象領域）を暗号単
位（例えば、８／１６／３２バイト）に合わせ、かつ認証範囲（認証対象領域）を４バイトアライメントに合わせるために、パディング、パディング長、及び次ヘッダからなるＥＳＰトレイラを平文パケットのペイロードデータの最後に付加した全領域に対応するＥＳＰペイロードが暗号処理される。
【００３４】
また、暗号化パケットには、ＥＳＰペイロードの前に、暗号アルゴリズム及び認証アルゴリズムの判定のためのＳＰＩ情報を含むＥＳＰヘッダ（８バイト）が付加されると共に、ＥＳＰペイロードの後に、ＥＳＰ認証データが付加される。さらに、暗号化パケットには、ＥＳＰヘッダ、ＥＳＰペイロード、及びＥＳＰ認証データをカプセル処理するためのトンネル用ＩＰヘッダ（２０バイトのＯｕｔ＿ＩＰヘッダ）が付加される。
【００３５】
ここで、暗号範囲はＥＳＰペイロードの領域に対応し、認証範囲はＥＳＰヘッダ及びＥＳＰペイロードの双方の領域に対応する。
【００３６】
上述したような平文パケットから暗号化パケットを生成する処理は、送信側パケット処理装置１０における暗号・認証・カプセル処理部１２によって実施される（図６中のＴ１１）。
【００３７】
この暗号化パケットの生成処理において、オリジナルＩＰヘッダ（２０バイトのＯｒｉ＿ＩＰヘッダ）及び複数のペイロードａ，ｂ，ｃから構成される平文パケットに付加された領域部分に応じて、暗号化パケットのパケット長がＭＴＵ値を超えたことをフラグメント判定部１３が判定した場合（図６中のＴ１２）、フラグメント処理部１４は次の条件でフラグメント処理を実行する（図６中のＴ１３）。
【００３８】
条件１：各フラグメントパケットにおいては、暗号ブロック単位及び認証ブロック単位で暗号範囲及び認証範囲が分割できるので、暗号化パケットのＬ１及びＬ２の値を暗号単位及び暗号ブロック単位に合わせる。例えば、暗号単位として、８／１６／３２バイトが用いられ、かつ認証単位として６４バイトが用いられる場合は、８，１６，３２，６４の最小公倍数である６４の倍数を暗号ブロック単位及び認証ブロック単位に選ぶことができる。
【００３９】
条件２：暗号化パケットにおいて、認証範囲の開始位置と暗号範囲の開始位置とが異なるので、先の（先頭または中間の）フラグメントパケットの最終データ（ペイロードデータ）を認証範囲の開始位置と暗号範囲の開始位置とのずれ分（つまり、ＥＳＰトンネルモードでは８バイト分）を、次の（中間または最終の）フラグメントパケットの先頭データとして重複して挿入する。
【００４０】
条件３：「パディング長」のデータが「パディング」のデータの後に送信され、「パディング長」を受信しないときは、「パディング」の削除ができないので、ＥＳＰトレイラをＥＳＰ認証データと共に一つのフラグメントパケット（最終フラグメントパケット）に取り込む。ここで、パディング長は１−２５５バイトの範囲と規定されている（ＲＦＣ２４０６）。また、ＥＳＰ認証データは、暗号化し終わったパケットと暗号鍵とから算出したハッシュ値であり、１２／１６／２０バイト（ＨＭＡＣ−ＳＨＡ−１＝２０バイト、ＨＭＡＣ−ＭＤ５＝１６バイト、ＡＥＳ−ＸＣＢＣ−ＭＡＣ−９６＝１２バイト）が用いられるとすると、最終フラグメントパケットのデータ長Ｌ３を、パディング（１−２５５バイト）＋パディグ長（１バイト）＋次ヘッダ（１バイト）＋ＥＳＰ認証データ（２０バイト）に基づいて、２７７バイトまたは２７８バイト以上とすればよい。
【００４１】
上述した条件１−３に従ってフラグメント処理された先頭、中間、及び最終の暗号化フラグメントパケットの各フラグメントオフセット値は、「０，Ｌ１，及びＬ１＋Ｌ２」で
あり、フラグメント処理部１４によって各トンネル用ＩＰヘッダ内に格納されて送信される。
【００４２】
［受信側パケット処理装置における処理］
次に、図１、図２及び図３に示す受信側パケット処理装置２０におけるパケット処理について、図５、図７Ａ、図７Ｂ及び図７Ｃを併せ参照して説明する。
【００４３】
図５は暗号化プロトコルをＥＳＰトンネルモードとした場合の受信側パケット処理装置２０における暗号化フラグメントパケット処理例を説明するための図である。また、図７Ａ、図７Ｂ及び図７Ｃは受信側パケット処理装置２０におけるパケット処理手順を示すフローチャートである。
【００４４】
なお、以下に説明するパケット処理において、受信した暗号化パケットが暗号化フラグメントパケットであることは、トンネル用ＩＰヘッダ内のプロトコル及びフラグメント制御情報（ＩＰｖ４の場合、Ｄ＝Ｄｏｎ’ｔ Ｆｒａｇｍｅｎｔ、Ｍ＝Ｍｏｒｅ Ｆｒａｇｍｅｎｔ、Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ、ＦＩＤ＝フラグメント識別子）に基づいて識別できる。例えば、Ｐｒｏｔｏｃｏｌ＝５０の場合がＥＳＰ暗号化パケットである。また、Ｄ＝１の場合、フラグメントパケットであり、同一パケットからフラグメントされたパケットは、同一ＦＩＤが付与される。Ｄ＝１，Ｍ＝１，Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ＝０の場合、先頭フラグメントパケット、Ｄ＝１，Ｍ＝１，Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ≠０の場合、中間フラグメントパケット、またＤ＝１，Ｍ＝０の場合、最終フラグメントパケットと識別できる（図７Ａ，図７Ｂ中のＲ１，Ｒ２，Ｒ３）。
【００４５】
まず、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した先頭のフラグメント処理された暗号化パケット（先頭の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ先頭の平文フラグメントパケットとして送信する。
【００４６】
Ｒ１１：制御部２７は、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ１）内のフラグメント識別子ＦＩＤ、送信元ＩＰアドレス及び宛先ＩＰアドレスと、ＥＳＰヘッダ内のＳＰＩ情報などとにより、クラシファイテーブル２５Ａを検索して、ＳＡＤＢテーブル２５Ｂ内の対応のエントリー番号ＳＡ−ＩＤを得て、フラグメント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された（縮退して付与された）番号対応に継続制御用テーブル２８にそのエントリー番号ＳＡ−ＩＤを格納する。
【００４７】
Ｒ１２：実行部２６は、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納された認証アルゴリズム及び認証用キー情報などに従い、認証ブロック単位に認証演算を行う。また、制御部２７は、最終ブロックの認証演算引継情報を上記処理Ｒ１１と同様に継続制御用テーブル２８に格納する。
【００４８】
Ｒ１３：さらに、実行部２６は、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納された暗号アルゴリズム及び暗号キー情報などに従って、暗号ブロック単位に復号処理を実行する。また、制御部２７は、最終ブロックの復号演算引継情報を上記処理Ｒ１１と同様に継続制御用テーブル２５Ｂに格納する。
【００４９】
Ｒ１４：制御部２７は、実行部２６によって復号化されたデータからオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ）を抽出すると共に、ペイロードを作成する。
【００５０】
Ｒ１５：制御部２７は、抽出したオリジナルＩＰヘッダに対して、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ１）よりフラグメント情報としてのオフセット値「０」を抽
出して挿入する。また、制御部２７は、ＴＴＬ（Time to Live）、パケット長、及びヘッダチェックサムを算出して挿入し、先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を作成し、後の処理Ｒ１７において上記処理Ｒ１１と同様に継続制御用テーブル２８に格納する。
【００５１】
Ｒ１６：制御部２７は、上記処理Ｒ１４及びＲ１５で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）及び復号データ（ペイロードａ）より、先頭の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００５２】
また、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した中間（ここでは、１つ）のフラグメント処理された暗号化パケット（中間の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ中間の平文フラグメントパケットとして送信する。
【００５３】
Ｒ２１：制御部２７は、先頭の暗号化フラグメントパケットの受信時に格納されたフラグメント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された番号対応のエントリー番号ＳＡ−ＩＤを継続制御用テーブル２８から取り出す。
【００５４】
Ｒ２２：制御部２７は、継続制御用テーブル２８に格納された認証演算引継情報を認証演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている認証アルゴリズム及び認証キー情報などに従い、実行部２６よって認証ブロック単位に認証演算を行わせる。また、制御部２７は、最終ブロックの認証演算引継情報を継続制御用テーブル２８の同一領域に上書きして格納する。
【００５５】
Ｒ２３：さらに、制御部２７は、継続制御用テーブル２８に格納された復号演算引継情報を復号演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている暗号アルゴリズム及び暗号キー情報などに従って、実行部２６によって暗号ブロック単位（先頭８バイトを除く）に復号処理を実行させる。制御部２７は、最終ブロックの復号演算引継情報を継続制御用テーブル２８の同一領域に上書きして格納する。制御部２７は、実行部２６によって復号化されたデータからオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ）を抽出すると共に、ペイロードを作成する。
【００５６】
Ｒ２４：制御部２７は、継続制御用テーブル２８に格納された先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を取り出し、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ２）よりオフセット値「Ｌ１」を抽出して挿入する。また、制御部２７は、ＴＴＬ、パケット長、及びヘッダチェックサムを算出して挿入し、中間の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ２）を作成する。
【００５７】
Ｒ２５：制御部２７は、上記処理Ｒ２３及びＲ２４で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ２）及び復号データ（ペイロードｂ）に基づいて、中間の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００５８】
さらに、受信側パケット処理装置２０においては、復号・認証アルゴリズム実行部２６及び復号・認証・デカプセル制御部２７は、受信部２１で受信した最終のフラグメント処理された暗号化パケット（最終の暗号化フラグメントパケット）に対して、次の処理を実施した後、ローカルネットワーク３へ最終の平文フラグメントパケットとして送信する。
【００５９】
Ｒ３１：制御部２７は、先頭の平文フラグメントパケットの受信時に格納されたフラグ
メント識別子ＦＩＤ及び送信元ＩＰアドレスで区別された番号対応のエントリー番号ＳＡ−ＩＤを継続制御用テーブル２８から取り出す。
【００６０】
Ｒ３２：制御部２７は、継続制御用テーブル２８に格納された認証演算引継情報を認証演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている認証アルゴリズム及び認証キー情報などに従い、実行部２６によって認証ブロック単位に認証演算を行わせ、最後のデータのＥＳＰ認証データと演算照合して認証判定を行う。
【００６１】
Ｒ３３：さらに、制御部２７は、継続制御用テーブル２８に格納された復号演算引継情報を復号演算初期情報に設定後、エントリー番号ＳＡ−ＩＤ対応のＳＡＤＢテーブル２５Ｂ内に格納されている暗号アルゴリズム及び暗号キー情報などに従って、実行部２６によって暗号ブロック単位（先頭８バイトを除く）に復号処理を実行させる。
【００６２】
Ｒ３４：制御部２７は、復号処理後のデータからペイロードを作成すると共に、トレイラ及び認証データを削除する。
【００６３】
Ｒ３５：制御部２７は、継続制御用テーブル２８に格納された先頭の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ１）を取り出し、トンネル用ＩＰヘッダ（Ｏｕｔ＿ＩＰヘッダ＿Ｆ３）よりオフセット値「Ｌ１＋Ｌ２」を抽出して挿入する。また、制御部２７は、ＴＴＬ、パケット長、及びヘッダチェックサムを算出して挿入し、最終の平文フラグメントパケットのオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）を作成する。
【００６４】
Ｒ３６：制御部２７は、上記処理Ｒ３４及びＲ３５で作成したオリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）及び復号データ（ペイロードｃ）に基づいて、最終の平文フラグメントパケットを作成し、送信部２９を通してローカルネットワーク３に送信する。
【００６５】
Ｒ３７：ただし、上記処理Ｒ３２に続く認証判定が異常「ＮＧ」となった場合は、オリジナルＩＰヘッダ（Ｏｒｉ＿ＩＰヘッダ＿Ｆ３）の情報、例えばオフセット値「Ｌ１＋Ｌ２」を「０」に改ざんして送信することにより、受信先でフラグメントエラーとして廃棄させる。
【００６６】
上述した受信側パケット処理装置２０のパケット処理において、受信した先頭、中間、及び最終の暗号化フラグメントパケットに順序逆転が発生した場合は、順序補正部２３によって、受信したパケットをバッファメモリに一時的に待機して順序を補正した後、上記各処理を実行すればよい。ただし、現状のネットワーク構成装置としてのゲートウェイ装置などは、パケットの順序保証を行っているものが多く存在し、また送信側のフラグメント処理で各フラグメントパケット長を操作（ほぼ同等または後のフラグメント長を大きくになるようにフラグメント処理）すれば、順序逆転の確率は非常に小さくなる。したがって、受信するパケットの順序逆転が発生しないことを前提すれば、順序補正部２３は不要となる。
【００６７】
［一実施の形態の効果］
上述した一実施の形態によれば、暗号・認証・カプセル処理に起因するパケット長の増大によりＭＴＵ値超えが発生した暗号化パケットを簡易にフラグメント処理し、トンネルモードで送信した場合、受信側パケット処理装置においてリアセンブル処理のためにフラグメント処理された全ての暗号化パケットが受信されるまで待機する必要がなく、パケット処理装置内の伝送遅延の削減が図れ、ネットワークの伝送性能を向上させることができる。
【００６８】
［変形例］
上述した一実施の形態における処理はコンピュータで実行可能なプログラムとして提供され、ＣＤ−ＲＯＭやフレキシブルディスクなどの記録媒体、さらには通信回線を経て提供可能である。
【００６９】
また、上述した一実施の形態における各処理はその任意の複数または全てを選択し組合せて実施することもできる。
【図面の簡単な説明】
【００７０】
【図１】一実施の形態の暗号化パケット処理システムの構成を示すブロック図である。
【図２】図１におけるパケット処理装置の構成を示すブロック図である。
【図３】継続制御用テーブルの構成を示す図である。
【図４】送信側パケット処理装置におけるパケット生成処理を説明するための図である。
【図５】受信側パケット処理装置におけるパケット処理を説明するための図である。
【図６】送信側パケット処理装置におけるパケット生成処理手順を説明するためのフローチャート図である。
【図７Ａ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【図７Ｂ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【図７Ｃ】受信側パケット処理装置におけるパケット処理手順を説明するためのフローチャートである。
【符号の説明】
【００７１】
ＳＹＳ 暗号化パケット処理システム
１ ＩＰネットワーク
２ ローカルネットワーク
３ ローカルネットワーク
４ ＩＰトンネル
１０ 送信側パケット処理装置
２０ 受信側パケット処理装置
１１ 受信部
１２ 暗号・認証・カプセル処理部
１３ フラグメント判定部
１４ フラグメント処理部
１５ 送信部
２１ 受信部
２２ フラグメント判定部
２３ 順序補正部
２４ 第１の復号・認証・デカプセル制御部
２５Ａ クラシファイテーブル
２５Ｂ ＳＡＤＢテーブル
２６ 復号・認証アルゴリズム実行部
２７ 第２の復号・認証・デカプセル制御部
２８ 継続制御用テーブル
２９ 送信部
【特許請求の範囲】
【請求項１】
ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するフラグメント処理部と、
前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部と、
を備えるパケット処理装置。
【請求項２】
前記ペイロードデータの後部所定数は、前記暗号対象領域の開始位置と前記認証対象領域の開始位置との差分のバイト数に対応する請求項１記載のパケット処理装置。
【請求項３】
前記複数の暗号化フラグメントパケット数がｎ（２＜ｎ、ｎは自然数）であるとき、
１番目（先頭）の暗号化フラグメントパケットは、暗号ヘッダ、オリジナルヘッダ、及び第１ペイロードデータを有し、前記暗号ヘッダは暗号アルゴリズム及び認証アルゴリズムの判定のための識別情報を含み、
ｍ番目（１＜ｍ＜ｎ、ｍは自然数）の暗号化フラグメントパケットは、第（ｍ−１）重複付加データを有し、前記第（ｍ−１）重複付加データは（ｍ−１）番目の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応し、
ｎ番目（最終）の暗号化フラグメントパケットは、第（ｎ−１）重複付加データ、第ｎペイロードデータ、及び認証データを有し、前記第（ｎ−１）重複付加データは（ｎ−１）番目の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応する請求項１記載のパケット処理装置。
【請求項４】
前記複数の暗号化フラグメントパケットが少なくとも２つであるとき、
先頭の暗号化フラグメントパケットは、暗号ヘッダ、オリジナルヘッダ、及び第１ペイロードデータを有し、前記暗号ヘッダは暗号アルゴリズム及び認証アルゴリズムの判定のための識別情報を含み、
最終の暗号化フラグメントパケットは、重複付加データ、第２ペイロードデータ、及び認証データを有し、前記重複付加データは前記先頭の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応する請求項１記載のパケット処理装置。
【請求項５】
前記制御部は、前記最終の暗号化フラグメントパケットの前記認証データを用いて認証演算結果を判定し、判定結果が異常であるときは、最終の平文フラグメントパケットにおけるオリジナルヘッダを改ざんする請求項３または４記載のパケット処理装置。
【請求項６】
ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するステップと、
前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・
デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させるステップと、
を備えるパケット処理方法。
【請求項１】
ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するフラグメント処理部と、
前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させる制御部と、
を備えるパケット処理装置。
【請求項２】
前記ペイロードデータの後部所定数は、前記暗号対象領域の開始位置と前記認証対象領域の開始位置との差分のバイト数に対応する請求項１記載のパケット処理装置。
【請求項３】
前記複数の暗号化フラグメントパケット数がｎ（２＜ｎ、ｎは自然数）であるとき、
１番目（先頭）の暗号化フラグメントパケットは、暗号ヘッダ、オリジナルヘッダ、及び第１ペイロードデータを有し、前記暗号ヘッダは暗号アルゴリズム及び認証アルゴリズムの判定のための識別情報を含み、
ｍ番目（１＜ｍ＜ｎ、ｍは自然数）の暗号化フラグメントパケットは、第（ｍ−１）重複付加データを有し、前記第（ｍ−１）重複付加データは（ｍ−１）番目の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応し、
ｎ番目（最終）の暗号化フラグメントパケットは、第（ｎ−１）重複付加データ、第ｎペイロードデータ、及び認証データを有し、前記第（ｎ−１）重複付加データは（ｎ−１）番目の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応する請求項１記載のパケット処理装置。
【請求項４】
前記複数の暗号化フラグメントパケットが少なくとも２つであるとき、
先頭の暗号化フラグメントパケットは、暗号ヘッダ、オリジナルヘッダ、及び第１ペイロードデータを有し、前記暗号ヘッダは暗号アルゴリズム及び認証アルゴリズムの判定のための識別情報を含み、
最終の暗号化フラグメントパケットは、重複付加データ、第２ペイロードデータ、及び認証データを有し、前記重複付加データは前記先頭の暗号化フラグメントパケットにおけるペイロードデータの後部所定数に対応する請求項１記載のパケット処理装置。
【請求項５】
前記制御部は、前記最終の暗号化フラグメントパケットの前記認証データを用いて認証演算結果を判定し、判定結果が異常であるときは、最終の平文フラグメントパケットにおけるオリジナルヘッダを改ざんする請求項３または４記載のパケット処理装置。
【請求項６】
ペイロードデータを含む平文パケットに暗号・認証・カプセル処理を施した暗号化パケットをトンネルモードで送信するとき、前記暗号化パケットの暗号対象領域及び認証対象領域を複数に分割して複数の暗号化フラグメントパケットを作成し、前記複数の暗号化フラグメントパケットに順番を識別するための識別子を含むトンネル用ヘッダをそれぞれ付加するとともに、先の暗号化フラグメントパケットにおけるペイロードデータの後部所定数を次の暗号化フラグメントパケットにおけるペイロードデータの前に重複して付加するステップと、
前記トンネルモードで受信した前記複数の暗号化フラグメントパケットに復号・認証・
デカプセル処理を施し、前記トンネル用ヘッダからそれぞれ抽出した前記識別子を書き込んだ前記平文パケット対応のペイロードデータをそれぞれ有する複数の平文フラグメントパケットを生成して受信端に向けて送信させるステップと、
を備えるパケット処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【公開番号】特開２０１０−１１１２２（Ｐ２０１０−１１１２２Ａ）
【公開日】平成２２年１月１４日（２０１０．１．１４）
【国際特許分類】
【出願番号】特願２００８−１６８４５６（Ｐ２００８−１６８４５６）
【出願日】平成２０年６月２７日（２００８．６．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年１月１４日（２０１０．１．１４）
【国際特許分類】
【出願日】平成２０年６月２７日（２００８．６．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]