JP2007036834A - 暗号装置、プログラム、記録媒体、および方法 - Google Patents

Abstract

【課題】 既に暗号化されているかを判定する手段がなく、多重に暗号化を行っていた。
【解決手段】 既に暗号化されたデータを送信する際に、パケットのヘッダに暗号化を意味するデータを付加する。送信側端末はヘッダに該データが付加されていた場合、暗号処理を行わない。同様に、受信側端末もヘッダに該データが付加されていた場合、復号処理を行わない。トンネルの入り口にあたるセキュリティゲートウェイは受信したパケットのヘッダに該データが付加していた場合、受信したパケットのヘッダ部分のみを暗号処理対象とする。同様に出口にあたるセキュリティゲートウェイは受信したパケットのヘッダ部分のみを復号処理対象とする。
【選択図】 図４

Description

本発明は、通信時にデータを暗号化する方法に関する。詳細には、既に暗号化されたデータを送信する際に暗号化済を意味するデータを添付し、既に暗号化されているか否か判定可能にすることにより、再度暗号処理を行うことを避ける、もしくは暗号処理していない部分のみを暗号処理することを可能にし、もって暗号化に要する計算負荷の削減、通信速度の向上を行う、暗号装置、プログラム、記録媒体、および方法に関する。

インターネット上で安全に通信を行う仕様の１つに、IPsec（IP security）という技術がある。IPsecは、RFC2401（Security Architecture for the Internet Protocol）を中心に、複数のRFCにより規定されている。IPsecは、IP層で認証・暗号化処理を行う。そのため、IP層よりも上位にある、アプリケーション層やTCP/UDP層などで認証・暗号化処理を行わなくとも、安全な通信を行うことが可能となる。

以下、IPsecについて説明する。

IPsecで実現できる機能として、以下のことが挙げられる。
・アクセス制御：接続元のアドレスなどに基づいて接続の許可・不許可を行う。
・通信データの完全性の保証：通信データが通信経路の途中で改竄されていないことを保証する。
・通信内容の秘匿：通信データを暗号化して、通信経路上で通信データを傍受されても通信データの内容が容易に判別できないようにする。

IPsecは、上記機能を実現するために、複数の技術から構成されている。

IPsecではAH（Authentication Header）とESP（Encapsulating Security Payload）というセキュリティプロトコルを用いる。AHは認証（通信データの完全性の保証）に用い、ESPは暗号化（通信内容の秘匿）に用いる。AHはRFC2402、ESPはRFC2406で規定されている。AH、ESPには、それぞれトランスポートモードとトンネルモードの２つのモードがある。トランスポートモードはIPパケットのペイロード部分をセキュリティプロトコルの処理対象にし、トンネルモードはIPパケット全体を処理対象とする。

トランスポートモード、トンネルモードにおいて、IPv4、IPv6それぞれに、AH、ESPを適用した場合の図を、図１９、図２０、図２１、図２２、図２３、図２４に挙げる。ここで、図中にあるTCPヘッダはトランスポートコントロールプロトコルのみを示すものではなく、トランスポート層で用いられるプロトコルのヘッダを意味するものである。よって、図中のTCPヘッダの位置には、UDPヘッダやICMPヘッダが入ってもよい。AHではIPパケット全体が認証の対象となる。ESPでは暗号化される範囲はESPヘッダの直後からESPトレイラーまで、認証される範囲はESPヘッダからESPトレイラーまで、となる。図示しないが、AH、ESPの両方を適用することも可能である。その場合、送信時はESP、AHの順で、受信時はAH、ESPの順で処理が行われる。

IPsecでは鍵、暗号アルゴリズムなどを管理するために、SA（Security Association）というパラメータのセットを用いる。SAを管理するデータベースをSAD（Security Association Database）と呼ぶ。SAのパラメータとして、通信する2点間の識別子、SPI（Security Parameter Index）、セキュリティプロトコルの種類、暗号アルゴリズムとその鍵、SAの生存時間、暗号化アルゴリズムで用いるIVの値、カウンタがある。SAには方向があり、一組の双方向通信を行うためには２つのSAが必要となる。

セキュリティポリシーとは、一般には「何を」「何から」「どのように」守るかを示す行動指針を指すが、IPsecにおけるSP（Security Policy）は、どのようなIPパケットに対してIPsecを適用するか否か（アクセス制御）を示す。SPのパラメータとしては、IP層プロトコル番号、IPアドレス、ネットワークアドレス、トランスポート層プロトコル、ポート番号、ユーザの識別子がある。SPを管理するデータベースをSPD（Security Parameter Database）と呼ぶ。

一例として、FreeBSDというオペレーティングシステムで動作する、KAMEプロトコルスタックにおけるSPの設定方法について説明する。KAMEでSPを設定する方法は、setkeyコマンドを用いる方法と、スクリプトを用いてマシン起動時に設定する方法の２つがある。

setkeyコマンドを用いて設定する場合、対話形式でSPを管理者が入力する方法と、あらかじめSPを記述したファイルを用意し、それをsetkeyコマンドに読み込ませて設定する方法がある。図２５の環境を例に説明する。図２５では、ルータAの外側（WAN側）のネットワークインタフェースには２００１：３４０：２：：１のアドレスが割り当てられ、内側（LAN側）のネットワークインタフェースには２００１：３４０：２：１００：：１が割り当てられているとする。ルータAは、２００１：３４０：２：１００：：/６４のプレフィックスを管理している。ルータAのサブネット内には、ホストAがあり、２００１：３４０：２：１００：：２のアドレスを持つものとする。同様に、ルータBは外側のネットワークインタフェースに２００１：３４０：２：：２、内側のネットワークインタフェースに２００１：３４０：２：２００：：１のアドレスが割り当てられ、２００１：３４０：２：２００：：/６４のプレフィックスを管理し、２００１：３４０：２：２００：：２のアドレスを持つホストBがあるものとする。図２５において、ホストAとホストB間で通信を行い、ルータAとルータB間でIPsecトンネルモードを双方向に行う場合を説明する。ルータAに図２６に示すファイルを、ルータBに図２７に示すファイルを用意し、setkeyコマンドを用いて読み込ませ、設定する。その後、後述するIKEプログラムを用いてSAを設定することにより、ルータAとルータB間では、ホストAとホストB間の通信についてIPsecトンネルモードが実施される。ここで、設定ファイルの「spdadd」はSPDにSPを追加することを示すコマンドであり、他に削除を示す「spddelete」などがある。次のアドレスは送信元、さらにその次のアドレスは送信先アドレスを示し、処理対象となるアドレスは何か、ということを示す。図２６、図２７に示したようなアドレス指定だけでなく、図２８、図２９で示すようにプレフィックスで指定することも可能である。図２８のSPをルータAに、図２９のSPをルータBに設定した場合、ルータAとルータB間では、２００１：３４０：２：１００：：/６４と２００１：３４０：２：２００：：/６４のプレフィックスを持つ通信全てにIPsecトンネルモードが適用される。次の「any」の個所でトランスポート層プロトコルを指定する。「any」は全てのトランスポート層プロトコルが対象となることを示す。他に、「icmp」といった指定などが可能である。次の「-P in」「-P out」で、SPを適用する方向を指定する。次の「ipsec」は、条件に適合したパケットにIPsec処理を行うことを示す。他に、条件に適合したパケットに何も処理しないことを示す「none」や、パケットを廃棄する「discard」などの指定が可能である。次に、セキュリティプロトコル、モード、処理を行うノード、レベルを指定する。セキュリティプロトコル「esp」は暗号処理を行うことを示し、「ah」は認証を行うことを示す。次の項で、モードを指定する。「transport」でトランスポートモード、「tunnel」でトンネルモードとして動作させることを示す。次のスラッシュ（/）とスラッシュの間には、処理を実際に行う機器のアドレスを示す。トランスポートモードの時は省略できる。トンネルモードの場合は、セキュリティゲートウェイのアドレスを（２箇所のセキュリティゲートウェイ間で処理を行うため）２つ指定する。最後のレベルは、条件に一致したパケットに対し、どれぐらいの厳しさで処理を行うかを示す。例えば「require」は、条件に一致したパケットには必ず処理を行うことを強制し、行えなければパケットを破棄する。「use」の場合、条件に一致したパケットに処理を行うようにするが、処理が行えなくとも、通信を許可する。図２５、図２６、図２７、図２８、図２９ではIPv6アドレスを用いた例を図示したが、IPv4アドレスでもIPsec通信は可能であり、SPの設定も可能である。

機器起動時にSPを設定するには、/etc/rc.confファイルにipsec_enable="YES"と記述し、SPを記述した（例えば図２６、図２７で示したような）ファイルをipsec_fileという項目で指定しておくことにより、FreeBSD起動後、自動的にSPを設定することが可能である。

なお、このSPの記述方法はあくまでKAMEにおける例であり、別の記述方法も存在する。

IPsecを行うために、IPsec通信する２点間でSAのパラメータを共有する必要がある。また、暗号アルゴリズムで用いる鍵も共有する必要がある。IPsecでは、その管理方法として、手動鍵管理と自動鍵管理を定義している。手動鍵管理とは、管理者が通信以外の方法を用いて2点間でパラメータを共有する方法である。例えば鍵データを郵送で送る、電話で鍵データを教えあう、といった方法により、離れた２点間でパラメータを共有する。しかし、SAの確立と消滅が頻繁に発生する環境などでは事実上管理が不可能となる。そのため、通信を用いて自動でパラメータを交換する方法が望まれ、自動鍵管理が考案された。自動鍵管理の方法として、IPsecではIKE（Internet Key Exchange）を用いる。IKEはRFC2409で規定されている。IKEはIKE自身のSAを交換するフェーズ１と、フェーズ１により確立された（IKEの）SA下で安全にIPsecのSAのパラメータを交換するフェーズ２という２つのフェーズから成る。フェーズ１では、認証方式として電子署名、公開鍵暗号、Pre-shared Keyの３つが定義されており、IKEを実行するプログラム同士がどれか１つを合意して用いる。IKEを用いてIPsecのSAが設定されることにより、IPsec通信が可能となる。

又、従来例としては、例えば特許文献１と特許文献２と非特許文献１から非特許文献６をあげることが出来る。
特開平10-327193（出願人：日本電気株式会社） 特開2002-077242（出願人：株式会社エヌ・ティ・ティ・ドコモ） RFC２４０１、Kent, S.、and R. Atkinson、「インターネットプロトコルのためのセキュリティアーキテクチャ（Security Architecture for the Internet Protocol）」、http://www.ietf.org/rfc/rfc2401.txt、1998年 11月。 RFC２４０２、Kent, S.、and R. Atkinson、「IP 認証ヘッダ（IP Authentication Header）」、http://www.ietf.org/rfc/rfc2402.txt、1998年 11月。 RFC２４０６、Kent, S.、and R. Atkinson、「IP 暗号ペイロード（ESP）（IP Encapsulating Security Payload (ESP)）」、http://www.ietf.org/rfc/rfc2406.txt、1998年 11月。 STD-2、Reynolds, J.、and J. Postel、"Assigned Numbers"、STD 2、 http://www.ietf.org/rfc/rfc1700.txt、1994年 10月. See also: http://www.iana.org/numbers.html RFC791、Postel, J., 「Internet Protocol」, STD 5、http://www.ietf.org/rfc/rfc791.txt、1981年9月。

RFC2460、Deering, S. and R. Hinden, 「Internet Protocol, Version 6 (IPv6) Specification」, http://www.ietf.org/rfc/rfc2460.txt、 1998年12月。

以上説明したように、IPsecは、IP層で認証・暗号化処理を行い、IP層よりも上位にある、アプリケーション層やTCP/UDP層などで認証・暗号化処理を行わなくとも、安全な通信を行うことが可能となる。

しかし、例えば複写機内のデータや、サーバ上のコンテンツなど、あらかじめデータが暗号化されている場合が増えつつある。これは、万一、複写機やサーバがセキュリティ上の攻撃を受けデータを奪われても、暗号化してあれば被害を抑えることが可能なためである。

一方、説明したように、既存の暗号プロトコル（IPsecなど）は、暗号化対象のデータがすでに暗号化されているか否かは関知せず、送信先アドレス、送信元アドレス、ポート番号などから構成されるセキュリティポリシーに合致した全てのデータを暗号化の対象としていた。言い換えると、既にデータが暗号化されていてもセキュリティポリシーに合致した場合、暗号化されたデータをさらに暗号化していた。既に暗号化されたデータの暗号強度が弱い場合や、何らかの理由で多重に暗号化を行う必要があるなら問題ないが、既に十分な暗号強度でデータが暗号化されている場合、さらに暗号化を行うのは冗長であると言える。暗号化処理は一般に計算負荷が高い処理であり、行う必要がない暗号化処理を行わないほうがよいことは言うまでもない。そのためには、何らかの手段でデータが暗号化されているか否かを判定し、多重に暗号化を行うことを回避する手段が必要となるが、そのような技術はなかった。

以上のような課題を解決する先行技術はないが、関連技術を挙げる。

特開平10-327193（出願人：日本電気株式会社）では、暗号ゲートウェイにおいて固定的に暗号化アルゴリズムが用いられる点を改良し、データパケットごとに暗号化アルゴリズムを変更して適用する方法を提案している。特開平10-327193では、該方法を実現するフローの一部として、機密性が低い情報に対しては暗号化作業が排除される手段を用いている。この手段では、パケット受信時に、パケットデータのIPヘッダ中のプロトコルフィールドから上位のプロトコルを判別し、暗号化/復号化を行う上位プロトコルかを判別しているが、IPsecに関するヘッダ（認証ヘッダ）をチェックして該ヘッダがある場合に暗号化/復号化処理を省略するのみであり、本提案で挙げた課題を解決していない。

特開2002-077242（出願人：株式会社エヌ・ティ・ティ・ドコモ）では、トランスポート層に対応したヘッダまたはヘッダを圧縮した圧縮ヘッダをオプションとして含むネットワーク層に対応したヘッダを生成し、このヘッダを圧縮されたペイロードに付加したパケットを伝送している。特開2002-077242は圧縮を、より広範囲に適用してデータ量の削減を図ったものであり、暗号化していない部分のみ暗号化する、という課題に対処していない。

本発明は上記の問題に鑑みてなされるものであり、既に暗号化されたデータを送信する際に暗号化済を意味するデータを添付し、既に暗号化されているか否か判定可能にすることにより、再度暗号処理を行うことを避ける、もしくは暗号処理していない部分のみを暗号処理することを可能にし、暗号化に要する計算負荷の削減し通信速度の向上を行う、暗号装置、プログラム、記録媒体、および方法を提供することを目的とする。

そして、本発明は上記目的を達成するために、送信側暗号装置は、セキュリティポリシーを設定する手段と、データが暗号化済であるかのデータを記録する手段と、該記録されたデータを読み出し暗号化済を意味するデータをパケットのヘッダに追加する手段と、該設定されたセキュリティポリシーを読み出す手段と、該ヘッダを検出する手段と、セキュリティポリシーに従い暗号処理を制御する手段と、該ヘッダが検出された場合に暗号処理を行わない手段とを備え、受信側暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に復号処理を行わない手段と、データが暗号化済であるかのデータを記録する手段と、を備えたものである。

また、第２の課題解決手段は、トンネル入り口にあたる暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを暗号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを付加する手段とを備え、トンネル出口にあたる暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを復号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを削除する手段とを備えたものである。

また、第３の課題解決手段は、該第２の課題解決手段の暗号装置に暗号処理を行う暗号ハードウェアを備え、該暗号化を意味するヘッダが付加していた場合にソフトウェアで暗号処理を行い、付加していない場合に暗号ハードウェアで処理する手段を備えたものである。

上述したように本発明の暗号装置は、既に暗号化されたデータを送受信する際、そのデータに対する再度の暗号処理を省略できるので、暗号化に要する計算負荷を削減できるという効果が得られ、よって暗号化による計算に要した時間を削減することとなり通信速度が向上した暗号装置を提供できる。

以下、本発明の実施の形態を、図面を参照しながら説明する。実施例ではIPv4、IPv6を特に区別して説明しないが、本発明は両方に適用可能である。また、IPv4、IPv6に適用する場合に異なる処理が必要な場合ついては適宜説明を加える。

なお、暗号化、という単語を用いた場合、暗号アルゴリズム（例えば3DESなど）を用いて平文データを解読困難なデータにすることを意味する場合と、いわゆる暗号処理全般を適用することを示す場合があるが、本実施例では、前者の意味で用いることとする。

また、本発明で、暗号化済データ、という用語を用いる。これは、IP層以外の層、例えば別のアプリケーションプログラムなどで、あらかじめ暗号化・認証データの作成などを行われたデータを指すものとする。例えば、サーバに暗号化して記録されているコンテンツデータや、複写機に暗号化して保存されている文書データなどが、暗号化済データである。

（第１の実施形態）
＜トランスポートモード時＞
図１は第１の実施形態を実施する環境の例を示す図である。端末２と端末３があり、両端末はインターネット１をはさんで通信を行う。ここで、端末２と端末３間に、ルータ、ハブなどの通信を中継する機器があってもよい。インターネット１の物理層の種類は特に種類は問わない。IEEE802.11、無線LANなど、物理層の上位でインターネットプロトコルによる通信ができれば問題ない。本実施の形態では、物理層は特に問わない。ここで必要なのは、端末１と端末２がインターネットプロトコルを用いて通信可能であることである。

図２および図３は、端末２および端末３の一般的な構成を示す図である。端末２および端末３の構成は基本的に同等で問題ないため、図２を用いて端末２についてのみ構成について説明する。CPU２０１が端末２の全体の動作を制御する。RAM２０２は一時記憶装置（Random Access Memory）であり、ROM２０３はプログラムなど、消去不可能なデータが組み込まれている不揮発性メモリ（Read Only Memory）である。バス２０４は、各モジュールを接続する内部バスである。ネットワークインタフェース２０５は、端末２が外部機器とデータ送受信を行う際に使用するインタフェースである。記録装置２０６は、例えばハードディスクなどであり、読み書きが可能で、電源を落としても記録された内容は消えないものとする。記録装置２０６には、文書データやコンテンツデータなどが記録されているものとする。さらに、ディスプレイやキーボード、マウス、プリントアウト部といった入出力機器用のインタフェースなどを備えていてもよい。

端末２および端末３では、両端末起動時に、記録装置２０６にファイルに記録されたセキュリティポリシーを読み込み、RAM２０２にセキュリティポリシーを記録し、セキュリティポリシーに従いパケットを処理するようになっているものとする。本実施例では、セキュリティポリシーが設定されている場合、トランスポートモードで設定されているとする。

では、図１の環境で、端末２から端末３にデータを送信する場合について、図２、図３、図４、図５を主に用いて説明する。図４は、本発明において端末間で通信する際の送信側端末の動作フローを示す図であり、本実施例では端末２の動作を意味するものとする。同様に、図５は、本発明において端末間で通信する際の受信側端末の動作フローを示す図であり、本実施例では端末３の動作を意味するものとする。

端末２において、CPU２０１は記録装置２０６からデータを読み出し、RAM２０２を用いてパケットを生成する。ここで、記録装置２０６で保存してあるデータは、暗号化されているデータである場合は暗号化されていることを意味するフラグがあり、CPU２０１がデータを暗号化されているか否か判別可能とする。判別した結果を、RAM２０２に保存する。フラグのほかに、例えば、暗号化されていることを意味する文字列であるなど、別のデータ形式で保管されていても問題ない。また、フラグなどの補助データを用いた手段以外に、該データが暗号化されているか否かを判別する手段は一般にはない。暗号化されているか不明なデータを一旦復号化してみて、あるパターンに一致すれば元のデータは暗号化されていると判別することは可能であるが、その手段は公知である。将来、補助データを用いずとも手段が発見された場合にはそれを用いてもよい。

ここから、図４を参照しながら説明する。

S４０１においてスタート後、S４０２において、CPU２０１はRAM２０２に保存した暗号化されているかのフラグを参照し、データが暗号化されているか否かを判別する。データが暗号化されていない場合NOとなり、S４０４に遷移する。データが暗号化されていた場合、YESとなり、S４０３に遷移する。

S４０３では、RAM２０２において生成されたパケットに、暗号化済を意味する内容をヘッダに追加する。これを、暗号化済ヘッダを追加する、と表現することにする。

ここで、IPv4の場合は、暗号化済を意味するデータをヘッダに付加する方法として、IPv4にあるプロトコルフィールドを用いる方法、0から40バイトまでのサイズを許すオプションフィールドを用いる方法、（AHヘッダやESPヘッダで行われているように）新たなヘッダを定義し、これをIPヘッダの後に挿入する方法の３つがある。

プロトコルフィールドを用いる場合、暗号化済を意味する番号を設定する。この番号は、IANAが割り当てている番号（STD-2）で割り当てられていない数（１０１から２５４のどれか）を用いるものとする。番号の数値自体は重要ではなく、暗号化済、ということが表現できればよい。この方法で暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、プロトコルフィールドの番号が、暗号化済を意味する番号かを比較して判定すればよい。

オプションフィールドを用いる場合、RFC７９１で10種類のオプションが定義されているため、新しいオプションを定義することとなる。オプションは、１バイトから成る単一バイトのものと、複数バイトから成るものがある。暗号化済を意味するオプションを定義する上で、暗号化済か否かを表現できればよいので、単一バイトで表現可能である。よって、RFC７９１で定義されていないTypeを用いて定義可能である。たとえば、Typeとして１３５（2進数表現で、１００００１１１、つまり、Copiedフラグ０、Classは０、Numberは７）などが望ましい。複数バイトでも表現可能であるが、本実施例では例示しない。この方法で暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、該オプションフィールドをチェックし、Typeが暗号化済ヘッダを意味する番号か比較して判定すればよい。

新たなヘッダを定義する方法は、例えば、32ビットからなる新しいヘッダを定義する。32ビットのうち、最初の8ビットはプロトコルの種類を示し、先のプロトコルフィールドの場合と同じように、STD-2で割り当てられていない番号を割当て、暗号化済ヘッダを示すとする。次の8ビットはこの新しいヘッダのバイト長とし、プロトコルの種類を含めて、4（４バイト、つまり３２ビット）とする。残る16ビットは、特に定義しない。この新しいヘッダがあることが、ペイロードデータが暗号化済のデータであることを示すからである。ただ、例えば、該16ビットで表現されるフィールドで、0なら暗号化されてない、1なら暗号化済である、というふうに定義してもよい。この方法で暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、該ヘッダの最初のフィールドを参照し、最初の8ビットで示されるプロトコルの種類が暗号化済ヘッダかどうかを比較して判定すればよい。

本実施例では、先のプロトコルフィールドを用いる方法を用いて説明する。番号は、１０１とする。以上、IPv4の場合を説明した。

IPv6の場合、IPv6のヘッダにはオプションフィールドはないので、かわりに拡張ヘッダを利用する。拡張ヘッダは、RFC２４６０の4章で定義されている。拡張ヘッダは、8ビットの次ヘッダフィールドと、8ビットのヘッダ拡張長フィールドを必ず有す。次ヘッダフィールドには、今の拡張ヘッダの次にある拡張ヘッダのタイプを記録する。本実施例では、先のIPv4の場合と同様に、STD-2で割り当てられていない番号を使用するものとする。本実施例では、番号を１０１とする。ヘッダ拡張長フィールドの値は、値ゼロが８バイトの拡張ヘッダサイズを示すと定義されており、8バイトで十分であるため、ゼロとする。もちろん、ゼロ以上でもかまわない。オプションデータに含まれる値は、特に問わない。それは、次ヘッダフィールドが１０１で示される拡張ヘッダの存在自体が、ペイロードが暗号化済であることを示すからである。次ヘッダフィールドの値が１０１の拡張ヘッダがない場合、暗号化済データはパケットに格納されていないことを示すとする。もちろん、オプションデータに含まれる値が１なら暗号化済データあり、0なら暗号化済データなし、のように定義しても問題ない。IPv6において暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、拡張ヘッダを１つづつチェックしていき、該拡張ヘッダの次ヘッダフィールドが暗号化済ヘッダを示す番号であるかを比較して判定すればよい。次ヘッダフィールドが暗号化済ヘッダの番号であった場合、次の拡張ヘッダが暗号化済ヘッダであることは、IPv6の拡張ヘッダの定義よりいうまでもない。以上、IPv6の場合について説明した。

以上のようにして、IPv4もしくはIPv6の場合でも、暗号化済を意味する内容を、ヘッダに付加した後、S４０４に遷移する。

S４０４において、CPU２０１は、RAM２０２に記録されているセキュリティポリシーを参照し、パケットがセキュリティポリシーで規定された条件に一致するか判別する。セキュリティポリシーが設定されていない場合や、条件に一致しなかった場合、NOとなり、S４１１に遷移する。セキュリティポリシーで規定された条件に一致した場合、YESとなり、S４０５に遷移する。

S４０５において、セキュリティポリシーとして暗号処理ポリシー、つまりESPを行うよう設定されているか判別する。設定されていない場合、暗号処理を行う必要はないので、NOとなり、S４０８に遷移する。設定されている場合、S４０６に遷移する。

S４０６において、CPU２０１はRAM２０２に記録されたパケットを参照し、暗号化済ヘッダが設定されているか判別する。本実施例では、IPv4の場合、プロトコルフィールドに値１０１が設定されているか比較し判別する。IPv6の場合、拡張ヘッダを順に参照し、次ヘッダフィールドに値１０１が設定されているか判別する。暗号化済ヘッダが設定されていた場合、YESとなり、S４１０に遷移する。されていない場合、NOとなり、S４０７に遷移する。

S４０７において、暗号処理（ESP）を行う。これは、S４０６における判断で該データは暗号化されていない平文データと判別されていると解釈でき、また暗号処理を行うべきとセキュリティポリシーも設定されている（S４０５）ことの2点から、実行される。ここで、ESP処理であるので、ESPヘッダがパケットに追加されるのはいうまでもない。なお、本実施例では上記説明したように、セキュリティポリシーが設定され、かつ、平文データの際の際に暗号処理を行うとしたが、暗号処理を行わないようにするのも可能ではある。ただし、セキュリティを高める観点からは、本実施例で説明したようにしたほうがよい。暗号処理が終了したら、S４１０に遷移する。

S４０８において、セキュリティポリシーとして認証処理ポリシー、つまりAHを行うよう設定されているか判別する。設定されていない場合、NOとなり、S４１０に遷移する。設定されている場合、YESとなり、S４０９に遷移する。

S４０９において、認証処理、つまり認証データを生成しAHヘッダを追加する。

S４１０において、次に処理するセキュリティ関連のポリシーがあるか判定する。セキュリティポリシー関連のポリシーとは、本発明では、１つのセキュリティポリシー内で行う暗号処理もしくは認証処理をさすこととする。S４１０において、次に処理するセキュリティ関連ポリシーがない場合、NOとなり、S４１３に遷移する。ある場合、YESとなり、S４０５に遷移する。

S４０５からS４１０において、本発明に関わるセキュリティ関連ポリシーがある場合の処理について述べた。途中で、セキュリティ以外のヘッダを作成することがあるかもしれないが、それは各RFCに記述された通りに処理されるものとする。

一方、S４１１において、セキュリティポリシーに一致しない場合、パケットを廃棄する設定になっているかを判定する。廃棄しない設定の場合、NOとなり、S４１３に遷移する。廃棄する設定の場合YESとなり、S４１２に遷移し、パケットを廃棄し、S４１４に遷移して終了となる。

S４１３において、セキュリティ以外のパケット生成に関する処理がなされ、生成されたパケットが送信され、S４１３に遷移して終了となる。

最終的に送信されるパケットは、例えば、暗号化済データを送信する場合で、認証関連のポリシーが設定されていない場合、図６のようなる。認証関連のポリシーが設定されている場合、暗号関連を先に処理したとすると、暗号化済ヘッダと認証データが付加されたパケットの場合は、図７のような構成となる。S４０２において、データが暗号化されていない（平文データ）、かつ、S４０４においてセキュリティポリシーがあり、暗号処理関連ポリシーがある場合は、平文データはESPに従い暗号化される。これは、平文データを処理する場合は、本発明では通常のIPsec処理となるを意味する。

次に、端末３において、受信時にどのように処理されるかを、図３と図５を参照しながら説明する。

端末３において、S５０１においてスタート後、パケットは、ネットワークインタフェース３０５を通じて受信される（S５０２）。受信されたパケットはRAM３０２に一時記録される。

S５０３において、CPU３０１は、RAM３０２に記録されているセキュリティポリシーを参照し、パケットがセキュリティポリシーで設定された条件に一致するか判別する。セキュリティポリシーが設定されていない場合や、条件に一致しなかった場合、NOとなり、S５１１に遷移する。セキュリティポリシーで規定された条件に一致した場合、YESとなり、S５０４に遷移する。

S５０４において、受信したパケットのヘッダが認証ヘッダ（AHヘッダ）であるかチェックする。ある場合、YESとなり、S５０５に遷移する。ない場合NOとなり、S５０６に遷移する。

S５０５において、認証ヘッダに含まれる認証データを確認し、正しいかどうかチェックする。正しい場合YESとなり、S５０９に遷移する。不正な場合、S５１４に遷移する。S５１４においてパケットを廃棄し、S５１５に遷移して終了となる。

S５０６において、受信したパケットのヘッダが暗号化済ヘッダかチェックする。暗号化済ヘッダである場合、YESとなり、S５１０に遷移する。暗号化済ヘッダでない場合NOとなり、S５０７に遷移する。S５１０では、受信したペイロードのデータが（ESP外で）暗号化済データであると判断し、RAM３０２に、該データが暗号化済であることを意味するデータ（例えば、フラグなど）を記録する。この暗号化済であることを意味するデータは、該暗号化済データと組としてテーブルで管理してもよいし、記録装置３０６に記録してもよい。

S５０７において、受信したパケットのヘッダが暗号ヘッダ（ESPヘッダ）かチェックする。暗号ヘッダである場合、YESとなり、S５０８に遷移する。そうでない場合NOとなり、S５０９に遷移する。図５ではNOの場合、S５０９に遷移し、処理を継続するようにしたが、ここで、認証・暗号化済・暗号ヘッダ以外の定義されていないヘッダが含まれていると判断し、S５１３に遷移してパケットを廃棄してもよい。

S５０８において、復号処理を行う。これは、通常のESPにおける復号処理である。終了後、S５０９に遷移する。

S５０９において、次のセキュリティ関連ヘッダがあるか判定する。ある場合、YESとなり、S５０４に戻る。ない場合、NOとなり、S５１５に遷移する。

S５０４からS５１０において、本発明に関わるセキュリティ関連ヘッダがある場合の処理を述べたが、この途中で、他のヘッダのオプションが発見される場合がある。この場合、各RFCに従って処理されるものとする。

一方、S５１１において、セキュリティポリシーに一致しない場合、パケットを廃棄する設定になっているかを判定する。廃棄しない設定の場合、NOとなり、S５１２に遷移する。廃棄する設定の場合、S５１４に遷移し、パケットを廃棄し、S５１５に遷移して終了となる。

S５１２において、受信したパケットに、暗号化済ヘッダがあるか判定する。ない場合NOとなり、S５１５に遷移する。ある場合、YESとなり、S５１３に遷移する。

S５１３において、受信したペイロードのデータが（ESP外で）暗号化済データであると判断し、RAM３０２に、該データが暗号化済であることを意味するデータ（例えば、フラグなど）を記録する。S５１０で行った処理と同様に、この暗号化済であることを意味するデータは、該暗号化済データと組としてテーブルで管理してもよいし、記録装置３０６に記録してもよい。

S５１５において、受信に関する処理が終了する。この後、受信したデータを記録装置３０６に記録したりすることとなると思われるが、それは本発明の範囲外である。

このようにして、IPsecの枠外で暗号化されてあるデータは、IPsecの処理過程において、暗号化されることなく、送受信が行われる。さらに、暗号化済ヘッダがない場合は、通常どおりの暗号化処理が行われるようにすることも可能である。

（第２の実施形態）
＜トンネルモード時＞
本実施例では、２つのサブネット（ローカルネットワーク）があり、それぞれ、セキュリティゲートウェイ（SG）とホストが１つづつある状況を例とする。ここで、SGはルータとしての機能を持つものとする。

図８は、本実施例を適用する環境を示す図である。SG９はローカルネットワーク４とインターネット１を介し、ローカルネットワーク４には端末２が接続されている。同様に、SG１０はローカルネットワーク5とインターネット１を介し、ローカルネットワーク５には端末３が接続されている。ローカルネットワーク４および５、インターネット3の物理層の種類は特に種類は問わない。

図９はSG９の構成を、図１０はSG１０の構成を示す図である。

図９において、CPU９０１がSG９の全体の動作を制御する。RAM９０２は一時記録装置（Random Access Memory）であり、ROM９０３はプログラムなど、消去不可能なデータが組み込まれている不揮発性メモリ（Read Only Memory）である。バス９０４は、各モジュールを接続する内部バスである。ネットワークインタフェース９０５および９０６は、SG９が外部機器とネットワークを介してデータ送受信を行う際に使用するインタフェースである。ネットワークインタフェース９０５と９０６には機能の違いはないが、説明の都合上、ネットワークインタフェース９０５をローカルネットワーク４に、ネットワークインタフェース９０６をインターネット１に接続しているものとする。また、セキュリティポリシーは、ROM９０３に記録されているものとするが、例えば、ハードディスクドライブなどの大容量記録装置やCompactFlashカードなどに記録され、それを読み込むようにしてもよい。

SG１０も構成はSG９とほぼ同じである。異なる点として、ネットワークインタフェース１００５をローカルネットワーク５に、ネットワークインタフェース１００６をインターネット１に接続しているものとする。

図８において、SG９、SG１０は基本的にIPsecトンネルモードで動作するセキュリティゲートウェイとして機能する。例えば、SG９、SG１０において、ローカルネットワーク４とローカルネットワーク５以下の端末からの通信をIPsecトンネルモード（ESPを行う）で処理するようにセキュリティポリシーが設定された場合、端末２が平文データを送信して端末3で受信するとすると、SG９およびSG１０間ではIPsecトンネルモードで、ESPにより暗号化されたパケットがやりとりされることとなる。ここで、もし、端末２が（実施例１で説明した）暗号化済ヘッダがない暗号化されたデータを端末３に送信した場合、SG９では、IPsecトンネルモード（ESP処理）で行うこととなっているので、暗号化されたデータをさらに暗号化することとなる。

そこで、本実施例では、端末２と端末３は実施例１で使用した端末であるとする。つまり、暗号化済ヘッダをパケットに付与する機能があるとして、説明する。

では、図８、９、１０、１１、１２を主に参照しながら説明する。図１１は、SG９、つまりトンネルの入り口に相当するセキュリティゲートウェイの動作フローを示す図であり、図１２は、SG１０、トンネルの出口に相当するセキュリティゲートウェイの動作フローを示す図である。

図１１において、S１１０１からスタートする。

S１１０２において、SG９は、ネットワークインタフェース９０５、つまりローカルネットワーク４より、パケットを受信する。

S１１０３において、受信したパケットが、SG９に設定されているセキュリティポリシーに一致するか比較する。一致した場合、S１１０４に遷移する。一致しない場合、S１１１２に遷移する。

S１１０４において、セキュリティポリシーとして暗号処理ポリシー、つまりESPを行うよう設定されているか判別する。設定されていない場合、暗号処理を行う必要はないので、NOとなり、S１１０９に遷移する。設定されている場合、S１１０５に遷移する。

S１１０５において、CPU９０１は受信したパケットのヘッダを参照し、暗号化済ヘッダが設定されているか判別する。本実施例では、IPv4の場合、プロトコルフィールドに値１０１が設定されているか比較し判別する。IPv6の場合、拡張ヘッダを順に参照し、次ヘッダフィールドに値１０１が設定されているか判別する。されていない場合、NOとなり、S１１０６に遷移する。暗号化済ヘッダが設定されていた場合、YESとなり、S１１０７に遷移する。

S１１０６において、受信したパケットのヘッダとペイロードを対象として、暗号処理（ESP）を行う。つまり、S１１０５で暗号化済ヘッダが検出されない場合は、通常のIPsecに基づいた暗号処理を行うこととなる。

S１１０７において、受信したパケットのヘッダのみを対象として、暗号処理を行う。つまり、S１１０５において、暗号化済ヘッダが検出されたということは、受信したパケットのペイロード部分は暗号化されていると判断される。よって、ヘッダ部分のみを暗号化すればよいこととなる。本実施例では、このヘッダを暗号化する際の暗号アルゴリズムは、IPsecのESP用に設定された方式を用いるものとするが、別の暗号アルゴリズムを用いても構わない。ただし、セキュリティゲートウェイで構成されるトンネルの入り口と出口で共有暗号鍵を共有する必要がある。一例としては、手動鍵設定を用いて共有暗号鍵を設定する方法がある。この共有手段については、本発明の範疇外である。暗号処理終了後、S１１０８に遷移する。

S１１０８において、トンネル用の暗号化済ヘッダを追加する。

該トンネル用暗号化ヘッダのあと、他の方法で暗号化されないほうが望ましい。ただし、これはセキュリティポリシーに依存するため、本発明では規定できない。

ここで、トンネル用暗号化済ヘッダについて説明する。

IPv4の場合、先にトランスポートモードの場合の説明で、３種類の方法を挙げた。しかし、トンネルモードでは、外側のIPヘッダのプロトコルフィールドの値は「4」（IP in IP、カプセル化されたIPであることを示す）でなければならないため、プロトコルフィールドを使用する方法は使用できない。よって、２種類の方法について説明する。

オプションフィールドを用いる場合、RFC７９１で10種類のオプションが定義されているため、新しいオプションを定義することとなる。オプションは、１バイトから成る単一バイトのものと、複数バイトから成るものがある。本発明では、元のIPヘッダのみを暗号化するため、暗号化したIPヘッダの長さを記録する必要がある。よって、トンネル用暗号化済ヘッダとして、複数バイトからなる方法を採用する。複数バイトのオプションフィールドは、先頭から、8ビットから成るType、このオプションフィールドのバイト長を示すLen、何らかのデータが入るDataより成る。場合により、Dataフィールドの先頭にOffsetが入ることもあるが、本実施例では使用しないため無視する。本実施例では、Typeとして１３５を用いる。また、Dataには暗号化するIPヘッダの長さを記録する。ここでは、Dataフィールドの長さを2バイト（16ビット）とする。よって、Lenに入る（本オプションの）長さは、１＋１＋２＝４バイトとなり、4とする。Dataフィールドに入る、暗号化したIPヘッダの長さはバイト長で表現するものとする。この方法で暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、該オプションフィールドをチェックし、Typeが暗号化済ヘッダを意味する番号か比較して判定すればよい。また、Typeをチェックし、暗号化済ヘッダであった場合、次にLenを参照する。Lenを参照することにより、後続のDataのバイト長が判明する。これより、Dataフィールドが特定でき、Dataフィールドから暗号化したIPヘッダの長さを取得することができる。

新たなヘッダを定義する方法は、例えば、32ビットからなる新しいヘッダを定義する。32ビットのうち、最初の8ビットはプロトコルの種類を示し、先のプロトコルフィールドの場合と同じように、STD-2で割り当てられていない番号を割当て、暗号化済ヘッダを示すとする。次の8ビットはこの新しいヘッダのバイト長とし、プロトコルの種類を含めて、4（４バイト、つまり３２ビット）とする。残る16ビットには、暗号化したIPヘッダのバイト長が入るものとする。この方法で暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、該ヘッダの最初のフィールドを参照し、最初の8ビットで示されるプロトコルの種類が暗号化済ヘッダかどうかを比較して判定すればよい。その後、次のフィールドを参照して、この新しいヘッダの全体の長さを取得し、そこから、暗号化されたIPヘッダの長さが記述されているフィールドのバイト長を計算する。その後、該IPヘッダの長さが記述されているフィールドから、該IPヘッダの長さを取得することが可能である。以上、IPv4におけるトンネル用暗号化済ヘッダの追加方法、ならびにチェック方法について説明した。

IPv6の場合、拡張ヘッダを利用する。実施例１と同様の方法で作成するものとするが、オプションデータに含まれる値は、暗号化したIPヘッダのバイト長とする。IPv6において暗号化済ヘッダが追加された場合、暗号化済ヘッダかどうかチェックするには、拡張ヘッダを１つづつチェックしていき、該拡張ヘッダの次ヘッダフィールドが暗号化済ヘッダを示す番号であるかを比較して判定すればよい。次ヘッダフィールドが暗号化済ヘッダの番号であった場合、次の拡張ヘッダが暗号化済ヘッダであることは、IPv6の拡張ヘッダの定義よりいうまでもない。以上のようにしてトンネル用暗号化済ヘッダ（厳密には拡張ヘッダ）を発見後、オプションデータの部分から、暗号化したIPヘッダのバイト長を取得可能である。以上、IPv6におけるトンネル用暗号化済ヘッダの追加方法、ならびにチェック方法について説明した。

以上のようにして、IPv4もしくはIPv6の場合でも、暗号化済を意味する内容を、外側のヘッダ（トンネル用に新しく作成した、IPヘッダ）に付加した後、S１１１１に遷移する。

さて、S１１０４にて暗号処理ポリシーではなかった場合、S１１０９に遷移している。S１１０９において、セキュリティポリシーとして認証処理ポリシー、つまりAHを行うよう設定されているか判別する。設定されていない場合、NOとなり、S１１１１に遷移する。設定されている場合、YESとなり、S１１１０に遷移する。

S１１１０において、認証処理、つまり認証データを生成しAHヘッダを追加する。これは、トンネルモード用のAHであることはいうまでもない。

S１１１１において、次に処理するセキュリティ関連のポリシーがあるか判定する。セキュリティポリシー関連のポリシーとは、本発明では、１つのセキュリティポリシー内で行う暗号処理もしくは認証処理をさすこととする。S１１１１において、次に処理するセキュリティ関連ポリシーがない場合、NOとなり、S１１１４に遷移する。ある場合、YESとなり、S１１０４に遷移する。

S１１０４からS１１１１において、本発明に関わるセキュリティ関連ポリシーがある場合の処理について述べた。途中で、セキュリティ以外のヘッダを作成することがあるかもしれないが、それは各RFCに記述された通りに処理されるものとする。

一方、S１１１２において、セキュリティポリシーに一致しない場合、パケットを廃棄する設定になっているかを判定する。廃棄しない設定の場合、NOとなり、S１１１４に遷移する。廃棄する設定の場合YESとなり、S１１１３に遷移し、パケットを廃棄し、S１１１５に遷移して終了となる。

S１１１４において、セキュリティ以外のパケットに関する処理がなされ、トンネルモードとして処理されたパケットが送信され、S１１１５に遷移して終了となる。

以上のようにして、暗号化済ヘッダが付加したパケットが受信された場合は、ESP処理を行うことなく、トンネルモードに対応した処理がなされ、トンネル用暗号化済ヘッダが付加され、転送される。

最終的に送信されるパケットは、例えば、暗号化済ヘッダ付きのパケットを受信してトンネルモードとして処理して送信する場合で、セキュリティゲートウェイに暗号関連のポリシーが設定されており認証関連のポリシーが設定されていない場合、図１３のようなる。同様に、認証ヘッダおよび暗号化済ヘッダ付きのパケットを受信し、トンネルモードとして処理して送信する場合で、セキュリティゲートウェイに暗号関連および認証関連のポリシーが設定されている場合、暗号関連を先に処理したとすると、暗号化済ヘッダと認証データが付加されたパケットの場合は、図１４のような構成となる。このように、暗号化済ヘッダがあり、セキュリティゲートウェイに暗号関連のポリシーが設定されている場合、受信したパケットのヘッダ部分のみがセキュリティゲートウェイで暗号化される。

次に、SG１０において、トンネルの出口においてどのように処理されるかを、図１０と図１２を参照しながら説明する。

図１２において、S１２０１からスタートする。

S１２０２において、SG１０は、ネットワークインタフェース１００６、つまりインターネット１より、パケットを受信する。

S１２０３において、受信したパケットが、SG１０に設定されているセキュリティポリシーに一致するか比較する。一致した場合、S１２０４に遷移する。一致しない場合、S１２１２に遷移する。

S１２０４において、セキュリティポリシーとして認証処理ポリシー、つまりAHを行うよう設定されているか判別し、受信したパケットのヘッダが認証ヘッダ（AHヘッダ）であるかチェックする。設定されていない場合、NOとなり、S１２０６に遷移する。設定されており、認証ヘッダがある場合、YESとなり、S１２０５に遷移する。

S１２０５において、認証ヘッダに含まれる認証データを確認し、正しいかどうかチェックする。正しい場合YESとなり、S１２１１に遷移する。不正な場合、S１２１３に遷移する。S１２１３においてパケットを廃棄し、S１２１５に遷移して終了となる。

S１２０６において、セキュリティポリシーとして復号処理ポリシー、つまりESPを復号化するよう設定されているか判別する。設定されていない場合、復号処理を行う必要はないので、NOとなり、S１２１１に遷移する。設定されている場合、S１２０７に遷移する。

S１２０７において、CPU１００１は受信したパケットのヘッダを参照し、トンネル用暗号化済ヘッダが設定されているか判別する。されていない場合、NOとなり、S１２０８に遷移する。トンネル用暗号化済ヘッダが設定されていた場合、YESとなり、S１２０９に遷移する。

S１２０８において、受信したパケットのヘッダとペイロードを対象として、復号処理（ESP）を行う。つまり、S１２０７でトンネル用暗号化済ヘッダが検出されない場合は、通常のIPsecに基づいた暗号処理を行うこととなる。

S１２０９において、受信したパケットのヘッダのみを対象として、復号処理を行う。つまり、S１２０７において、トンネル用暗号化済ヘッダが検出されたということは、受信したパケットのペイロード部分は（IPsec外で）暗号化されていると判断される。よって、ヘッダ部分のみを復号化すればよいこととなる。本実施例では、このヘッダを復号化する際の暗号アルゴリズムは、IPsecのESP用に設定された方式を用いるものとする。復号処理終了後、S１２１０に遷移する。

S１２１０において、トンネル用暗号化済ヘッダを削除し、S１２１１に遷移する。

S１２１１において、次のセキュリティ関連ヘッダがあるか判定する。ある場合、YESとなり、S１２０４に戻る。ない場合、NOとなり、S１２１４に遷移する。

S１２０４からS１２１１において、本発明に関わるセキュリティ関連ヘッダがある場合の処理を述べたが、この途中で、他のヘッダのオプションが発見される場合がある。この場合、各RFCに従って処理されるものとする。

一方、S１２１２において、セキュリティポリシーに一致しない場合、パケットを廃棄する設定になっているかを判定する。廃棄しない設定の場合、NOとなり、S１２１４に遷移する。廃棄する設定の場合、S１２１３に遷移し、パケットを廃棄し、S１２１５に遷移して終了となる。

S１２１４において、残った他のトンネルの出口としてのパケット処理を行い、その後、パケットを送信する。S１２１５に遷移して終了となる。

このようにして、IPsecの枠外で暗号化されて、暗号化済ヘッダが付加されたパケット中のデータは、トンネルモードの処理過程において、暗号化されることなく、送受信が行われる。さらに、ペイロード部分のみが暗号化され、暗号化済ヘッダがあり、セキュリティゲートウェイにて暗号処理するようセキュリティポリシーが設定されていた場合は、ペイロードの部分は暗号化することなく、ヘッダ部分のみを暗号化することにより、暗号処理の負荷を低減している。また、ヘッダ、ペイロード部分とも暗号化されておらず、暗号済ヘッダがなく、セキュリティゲートウェイにて暗号処理するようセキュリティポリシーが設定されていた場合は、通常どおり、ヘッダとペイロード部分の両方を暗号処理する。

（第３の実施形態）
＜暗号ハードウェア利用時＞
暗号処理は一般に計算負荷が重い処理であるため、暗号処理を専門に行う暗号ハードウェアが存在する。暗号ハードウェアは、単独のチップで構成され他のモジュール（CPUやRAMなど）とバス接続される形態や、CPUの中に回路として組み込まれる形態など、いくつかの形態で提供される。単独のチップで提供される場合には、チップの初期化処理や、データをバスを通してチップとやり取りする際に発生する時間などがかかるので、処理するデータ量が少ない場合はソフトウェアで暗号処理を行ったほうが早いケースがあり、これは公知である。

本実施例では、前記第２の実施形態で述べた環境（図８）において、SG９とSG１０に、それぞれ暗号ハードウェアがある場合（図１５、図１６）に、前記した暗号処理をハードウェアとソフトウェアで適宜処理し、スループットが高くなる方法について説明する。本実施例でのSG９とSG１０の動作フローは、ほぼ前記第２の実施形態で説明した動作フロー（図１１、図１２）と同じであるので、差分についてのみ説明する。

SG９、SG１０には、それぞれ暗号ハードウェア１５０１および１６０１が備わる。そのような場合、SG９およびSG１０の動作フローは、図１７および図１８となる。図１７は図１１とほぼ同等であるが、S１１０６がS１７０１に、S１１０７がS１７０２になる点が異なる。同様に、図１８は図１２と、S１２０８がS１８０１に、S１２０９がS１８０２になる点が異なる。ここで、S１７０１およびS１８０１、つまりヘッダとペイロードを処理する場合は、暗号ハードウェアを用いて暗号処理を行う。S１７０２およびS１８０２、つまりヘッダのみを処理する場合は、ソフトウェアで暗号処理を行う。このようにすれば、前記したデータ量が少ない場合（ヘッダのみの場合）はソフトウェアで、データ量が多い場合（ヘッダ＋ペイロードの場合）は暗号ハードウェアで処理することが可能となり、スループットの向上が図れる。

さらに、図１５、図１６で示したセキュリティゲートウェイにおいて、あらかじめソフトウェアで処理したほうが速い場合、ハードウェアで処理したほうが速い場合の暗号処理対象のデータ量を計測しておき、そのデータ量によってソフトウェアと暗号ハードウェアによる処理を切り替えてもよい。

以上、本発明の実施形態について説明した。

なお、本発明の一実施例による説明では、IPsecおよびIPsecのセキュリティポリシーを参照したが、他のIP層で暗号化・認証を行うシステム、および他のセキュリティポリシーを参照してもよい。つまり、暗号化済を意味するデータをヘッダに付加し、その暗号化済ヘッダを参照して再度の暗号化を行わない仕組みが組み込めるならば、本発明の一実施例に制限されることはない。

本発明（トランスポートモード時）を実施する環境の例を示す図である。 本発明（トランスポートモード時）の送信側の端末の構成例を示す図である。 本発明（トランスポートモード時）の受信側の端末の構成例を示す図である。 本発明（トランスポートモード時）の送信側の端末の動作を示すフローチャート図である。 本発明（トランスポートモード時）の受信側の端末の動作を示すフローチャート図である。 本発明（トランスポートモード時）を適用後のパケットの例を示す図である。 本発明（トランスポートモード時）を認証ヘッダがあるパケットに適用した後のパケットの例を示す図である。 本発明（トンネルモード時）を実施する環境の例を示す図である。 本発明（トンネルモード時）のトンネル入り口にあたるセキュリティゲートウェイの構成例を示す図である。 本発明（トンネルモード時）のトンネル出口にあたるセキュリティゲートウェイの構成例を示す図である。 本発明（トンネルモード時）のトンネル入り口にあたるセキュリティゲートウェイの動作を示すフローチャート図である。 本発明（トンネルモード時）のトンネル出口にあたるセキュリティゲートウェイの動作を示すフローチャート図である。 本発明（トランスポート時）を適用したパケットに、本発明（トンネルモード時）を適用した前後のパケットの例を示す図である。 本発明（トランスポート時）を適用したパケット（AHヘッダつき）に、本発明（トンネルモード時）を適用した前後のパケットの例を示す図である。 本発明（トンネルモード時）のトンネル入り口にあたるセキュリティゲートウェイに暗号ハードウェアがある場合の構成例を示す図である。 本発明（トンネルモード時）のトンネル出口にあたるセキュリティゲートウェイに暗号ハードウェアがある場合の構成例を示す図である。 本発明（トンネルモード時）のトンネル入り口にあたるセキュリティゲートウェイに暗号ハードウェアがある場合の動作を示すフローチャート図である。 本発明（トンネルモード時）のトンネル出口にあたるセキュリティゲートウェイに暗号ハードウェアがある場合の動作を示すフローチャート図である。 IPv4パケットにIPsecトランスポートモードで認証処理（AH）を適用する前後のパケットを示す図である。 IPv6パケットにIPsecトランスポートモードで認証処理（AH）を適用する前後のパケットを示す図である。 IPv4およびIPv6パケットにIPsecトンネルモードで認証処理（AH）を適用した後のパケットを示す図である。 IPv4パケットにIPsecトランスポートモードで暗号処理（ESP）を適用する前後のパケットを示す図である。 IPv6パケットにIPsecトランスポートモードで暗号処理（ESP）を適用する前後のパケットを示す図である。 IPv4およびIPv6パケットにIPsecトンネルモードで暗号処理（ESP）を適用した後のパケットを示す図である。 セキュリティポリシー設定を説明する際に用いる環境を示す図である。 図２５のホストAに設定する、セキュリティポリシーを記述したファイルの一例を示す図である。 図２５のホストBに設定する、セキュリティポリシーを記述したファイルの一例を示す図である。 図２５のホストAに設定する、プレフィックスを用いたセキュリティポリシーを記述したファイルの一例を示す図である。 図２５のホストBに設定する、プレフィックスを用いたセキュリティポリシーを記述したファイルの一例を示す図である。

符号の説明

1 インターネット
2 端末（送信側）
3 端末（受信側）
4、5 ローカルネットワーク
9 セキュリティゲートウェイ（トンネル入り口）
10 セキュリティゲートウェイ（トンネル出口）
201、301、901、1001 CPU
202、302、902、1002 RAM
203、303、903、1003 ROM
204、304、904、1004 バス
205、305、905、906、1005、1006 ネットワークインタフェース
206、306 記録装置
1501、1502 暗号ハードウェア

Claims (10)

1. 送信側暗号装置は、セキュリティポリシーを設定する手段と、データが暗号化済であるかのデータを記録する手段と、該記録されたデータを読み出し暗号化済を意味するデータをパケットのヘッダに追加する手段と、該設定されたセキュリティポリシーを読み出す手段と、該ヘッダを検出する手段と、セキュリティポリシーに従い暗号処理を制御する手段と、該ヘッダが検出された場合に暗号処理を行わない手段とを備え、
   受信側暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に復号処理を行わない手段と、データが暗号化済であるかのデータを記録する手段とを備え、
   送受信するデータがすでに暗号化されているかを検出し、暗号化されていた場合には、再度の暗号処理および復号処理を行わないことを特徴とする、暗号装置。
2. トンネル入り口にあたる暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを暗号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを付加する手段とを備え、
   トンネル出口にあたる暗号装置は、セキュリティポリシーを設定する手段と、該設定されたセキュリティポリシーを読み出す手段と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手段と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを復号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを削除する手段とを備え、
   トンネル処理対象のパケットのペイロード部分がすでに暗号化されているかを検出し、暗号化されていた場合には、ヘッダ部分のみを暗号処理および復号処理の対象とすることを特徴とする、暗号装置。
3. 請求項２の暗号装置は暗号ハードウェアを備え、暗号ハードウェアもしくはソフトウェアによる暗号処理を適用する手段を備え、処理速度が速い暗号処理手段を適用することを特徴とする、暗号装置。
4. 送信側では、セキュリティポリシーを設定する手順と、データが暗号化済であるかのデータを記録する手順と、該記録されたデータを読み出し暗号化済を意味するデータをパケットのヘッダに追加する手順と、該設定されたセキュリティポリシーを読み出す手順と、該ヘッダを検出する手段と、セキュリティポリシーに従い暗号処理を制御する手順と、該ヘッダが検出された場合に暗号処理を行わない手順とを備え、
   受信側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に復号処理を行わない手順と、データが暗号化済であるかのデータを記録する手順とを備え、
   送受信するデータがすでに暗号化されているかを検出し、暗号化されていた場合には、再度の暗号処理および復号処理を行わないことを特徴とする、暗号プログラム。
5. パケットをカプセル化する側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを暗号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを付加する手順とを備え、
   パケットのカプセル化を解除する側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを復号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを削除する手順とを備え、
   トンネル処理対象のパケットのペイロード部分がすでに暗号化されているかを検出し、暗号化されていた場合には、ヘッダ部分のみを暗号処理および復号処理の対象とすることを特徴とする、暗号プログラム。
6. 請求項５の暗号プログラムにおいて、暗号ハードウェアもしくはソフトウェアによる暗号処理を適用する手順を備え、処理速度が速い暗号処理手順を適用することを特徴とする、暗号プログラム。
7. 請求項４から６の何れか一項に記載のプログラムが記録されたコンピュータ読み取り可能な記録媒体。
8. 送信側では、セキュリティポリシーを設定する手順と、データが暗号化済であるかのデータを記録する手順と、該記録されたデータを読み出し暗号化済を意味するデータをパケットのヘッダに追加する手順と、該設定されたセキュリティポリシーを読み出す手順と、該ヘッダを検出する手段と、セキュリティポリシーに従い暗号処理を制御する手順と、該ヘッダが検出された場合に暗号処理を行わない手順とを備え、
   受信側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に復号処理を行わない手順と、データが暗号化済であるかのデータを記録する手順とを備え、
   送受信するデータがすでに暗号化されているかを検出し、暗号化されていた場合には、再度の暗号処理および復号処理を行わないことを特徴とする、暗号方法。
9. パケットをカプセル化する側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを暗号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを付加する手順とを備え、
   パケットのカプセル化を解除する側では、セキュリティポリシーを設定する手順と、該設定されたセキュリティポリシーを読み出す手順と、受信したパケットに暗号化済を意味するヘッダが付加しているか検出する手順と、該暗号化済を意味するヘッダが付加していた場合に受信したパケットのヘッダ部分のみを復号処理し新たに作成されるIPヘッダに暗号化済を意味するデータを削除する手順とを備え、
   トンネル処理対象のパケットのペイロード部分がすでに暗号化されているかを検出し、暗号化されていた場合には、ヘッダ部分のみを暗号処理および復号処理の対象とすることを特徴とする、暗号方法。
10. 請求項８の暗号方法において、暗号ハードウェアもしくはソフトウェアによる暗号処理を適用する手順を備え、処理速度が速い暗号処理手順を適用することを特徴とする、暗号方法。

Images