JP2008182649A - 暗号化パケット通信システム - Google Patents
暗号化パケット通信システム Download PDFInfo
- Publication number
- JP2008182649A JP2008182649A JP2007016242A JP2007016242A JP2008182649A JP 2008182649 A JP2008182649 A JP 2008182649A JP 2007016242 A JP2007016242 A JP 2007016242A JP 2007016242 A JP2007016242 A JP 2007016242A JP 2008182649 A JP2008182649 A JP 2008182649A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- encrypted
- key
- common key
- header
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 端末同士の通信を暗号化し、且つ、暗号化された通信をゲートウェイ装置でも解析可能とし、情報漏洩を防ぐため検閲を行えるようにすること。
【解決手段】 ゲートウェイ装置３は公開鍵暗号方式による、公開鍵と秘密鍵のペアを用意し、ゲートウェイ装置３が管理する端末２ａ〜２ｃへ公開鍵を配布しておく。端末２ａ〜２ｃは、通信パケットを従来の共通鍵暗号化をした後に、共通鍵を公開鍵で暗号化し、パケットに付与する。ゲートウェイ装置３は、秘密鍵を使い共通鍵を復号化し、パケットを検閲し、従来の暗号化パケットフォーマットに戻した後、相手端末２ｄ〜２ｆがいるネットワーク１ｃへ転送する。
【選択図】 図１
【解決手段】 ゲートウェイ装置３は公開鍵暗号方式による、公開鍵と秘密鍵のペアを用意し、ゲートウェイ装置３が管理する端末２ａ〜２ｃへ公開鍵を配布しておく。端末２ａ〜２ｃは、通信パケットを従来の共通鍵暗号化をした後に、共通鍵を公開鍵で暗号化し、パケットに付与する。ゲートウェイ装置３は、秘密鍵を使い共通鍵を復号化し、パケットを検閲し、従来の暗号化パケットフォーマットに戻した後、相手端末２ｄ〜２ｆがいるネットワーク１ｃへ転送する。
【選択図】 図１
Description
本発明は、暗号化パケット通信システムに係り、特に、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等を通信プロトコルとするネットワーク上の暗号化通信において、暗号化されたパケットを検閲するための暗号化パケット通信システムに関する。
近年、通信ネットワークのＩＰ化が進む中、インターネットを中心にＩＰ通信ネットワークは広く社会基盤として利用されている。そして、インターネット上での個人情報や商取引情報等を含むパケット通信において、盗聴や改竄を防御するため通信経路のセキュリティを確保することが不可欠となっている。
インターネット上での通信セキュリティに関する技術として、インターネット標準化委員会ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で議論されている技術である、Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（インターネットプロトコルのためのセキュリティアーキテクチャ）が広く知られている（非特許文献１参照）。
なお、今後広く普及が見込まれる、ＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒ．６）ではＩＰｓｅｃ（ＩＰ ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）を標準装備することが規定されており、現在ＩＰｖ６に対応した製品ではＩＰｓｅｃ機能が実装されている。さらに、通信ネットワークのオールＩＰ化が進むにつれ、接続端末数や利用者数の増加およびアクセス形態が複雑化していくことが予測される。
通常、ＩＰｓｅｃでは送信者と受信者間で送受信パケットに対して共通鍵による暗号化処理を行うことにより安全な通信を実現している。このため、あらかじめ送信者と受信者との間でＩＰｓｅｃを適用するために必要な認証・暗号アルゴリズム情報等や共通鍵を決めておく必要がある。ＩＰｓｅｃ処理装置間で通信開始前に折衝を行い、上述の共通鍵を自動的に生成する技術に関して、Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅが知られている（非特許文献２参照）。
インターネット上での通信セキュリティに関する技術として、インターネット標準化委員会ＩＥＴＦ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で議論されている技術である、Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（インターネットプロトコルのためのセキュリティアーキテクチャ）が広く知られている（非特許文献１参照）。
なお、今後広く普及が見込まれる、ＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒ．６）ではＩＰｓｅｃ（ＩＰ ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）を標準装備することが規定されており、現在ＩＰｖ６に対応した製品ではＩＰｓｅｃ機能が実装されている。さらに、通信ネットワークのオールＩＰ化が進むにつれ、接続端末数や利用者数の増加およびアクセス形態が複雑化していくことが予測される。
通常、ＩＰｓｅｃでは送信者と受信者間で送受信パケットに対して共通鍵による暗号化処理を行うことにより安全な通信を実現している。このため、あらかじめ送信者と受信者との間でＩＰｓｅｃを適用するために必要な認証・暗号アルゴリズム情報等や共通鍵を決めておく必要がある。ＩＰｓｅｃ処理装置間で通信開始前に折衝を行い、上述の共通鍵を自動的に生成する技術に関して、Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅが知られている（非特許文献２参照）。
一方、企業等の組織から意図していない情報が外部へ出てしまうことにより起こる、情報漏洩が目立つようになってきた。このため、組織内部のネットワークから外部へ情報を出すことがないよう、パケットの内容を確認し、転送してはいけないパケットを廃棄するための検閲装置が使われるようになった。この装置は組織ネットワークの出口になるゲートウェイに組み込まれることが多い。
S.Kent、 R. Atkinson、 「Security Architecture for the Internet Protocol」 RFC2401、 1998年11月 D. Harkins、 D. Carrel 、 「The Internet Key Exchange (IKE)」 RFC2409、 1998年11月
S.Kent、 R. Atkinson、 「Security Architecture for the Internet Protocol」 RFC2401、 1998年11月 D. Harkins、 D. Carrel 、 「The Internet Key Exchange (IKE)」 RFC2409、 1998年11月
上述のようなＩＰｓｅｃ技術等で暗号化されているパケットに対しては、ゲートウェイ装置は、共通鍵を保持していないため、そのパケットを復号化することができず、パケットのデータ部を見ることができないという課題があった。
このような課題を解決するため、ＩＰｓｅｃトンネルモードを使用し、ゲートウェイが端末の代わりに暗号化を実施する方法がある。これにより、ゲートウェイ装置には暗号化されていない平文のパケットが届き、パケットの内容をゲートウェイ装置が見ることができるようになった。しかし、これを実施することにより、以下に示すような課題が生じた。
・組織内ネットワークに配置されている端末の、暗号化通信先が複数の場合、その複数の相手先すべての共通鍵情報を保持しなければならず、ゲートウェイ装置の必要メモリ量が増大する。
・ゲートウェイ装置は複数の共通鍵を取り出すための検索に時間がかかり、ゲートウェイ装置の必要ＣＰＵ時間が増大する。
・組織内ネットワークでは、暗号化されていない平文のパケットが転送されることになるので、組織内での盗聴が可能になり、端末間のセキュリティを完全に確保できていない。
このような課題を解決するため、ＩＰｓｅｃトンネルモードを使用し、ゲートウェイが端末の代わりに暗号化を実施する方法がある。これにより、ゲートウェイ装置には暗号化されていない平文のパケットが届き、パケットの内容をゲートウェイ装置が見ることができるようになった。しかし、これを実施することにより、以下に示すような課題が生じた。
・組織内ネットワークに配置されている端末の、暗号化通信先が複数の場合、その複数の相手先すべての共通鍵情報を保持しなければならず、ゲートウェイ装置の必要メモリ量が増大する。
・ゲートウェイ装置は複数の共通鍵を取り出すための検索に時間がかかり、ゲートウェイ装置の必要ＣＰＵ時間が増大する。
・組織内ネットワークでは、暗号化されていない平文のパケットが転送されることになるので、組織内での盗聴が可能になり、端末間のセキュリティを完全に確保できていない。
以上が従来の課題の例である。
本発明は、以上の点に鑑み、メモリ量及び／又はＣＰＵ処理等を増やすことなく、組織網内の端末間のセキュリティを確保しつつ、ゲートウェイ装置で転送するパケットの検閲をできるようにすることを目的とする。
本発明は、以上の点に鑑み、メモリ量及び／又はＣＰＵ処理等を増やすことなく、組織網内の端末間のセキュリティを確保しつつ、ゲートウェイ装置で転送するパケットの検閲をできるようにすることを目的とする。
上述の課題を解決するため、本発明は、共通鍵暗号方式と公開鍵暗号方式の両方式を用いるようにした。ここで、共通鍵暗号方式とは、暗号化した鍵と同一の鍵でのみ復号化が可能な鍵を用いる暗号化方式である。また、公開鍵暗号方式とは、二つの鍵ペア、例えば鍵Ａと鍵Ｂが存在し、鍵Ａで暗号化したデータは鍵Ｂでのみ復号化でき、鍵Ｂで暗号化としたデータは、鍵Ａでのみ復号化することができる方式である。この特徴を利用し、鍵Ａを公開鍵として使用し、もう一方の鍵Ｂを秘密鍵として使用する。
本発明は、主に、共通鍵でパケットを暗号化する手段と、公開鍵で前記共通鍵を暗号化する手段と、共通鍵で暗号化されたパケットの情報を欠落させることなく、暗号化した共通鍵を、暗号化されたパケットと同時に送信する手段とを具備する。また、本発明は、公開鍵に対応する秘密鍵を格納する手段と、前記パケットと同時に受け取った暗号化された共通鍵を秘密鍵で復号化して共通鍵を取り出す手段と、パケットを取り出した共通鍵で復号化する手段と、パケット検閲手段に平文でパケットを渡す手段とを具備する。さらに、本発明は、従来の暗号化パケットフォーマットに戻して、パケットを転送する手段を具備することができる。
本発明は、主に、共通鍵でパケットを暗号化する手段と、公開鍵で前記共通鍵を暗号化する手段と、共通鍵で暗号化されたパケットの情報を欠落させることなく、暗号化した共通鍵を、暗号化されたパケットと同時に送信する手段とを具備する。また、本発明は、公開鍵に対応する秘密鍵を格納する手段と、前記パケットと同時に受け取った暗号化された共通鍵を秘密鍵で復号化して共通鍵を取り出す手段と、パケットを取り出した共通鍵で復号化する手段と、パケット検閲手段に平文でパケットを渡す手段とを具備する。さらに、本発明は、従来の暗号化パケットフォーマットに戻して、パケットを転送する手段を具備することができる。
本発明の解決手段によると、パケット送信装置から、パケット送信装置を含むネットワークのパケット転送装置を介して、他のネットワーク内のパケット受信装置へパケットを送信するための暗号化パケット通信システムであって、
前記パケット送信装置は、
前記パケットのパケットデータ部を共通鍵で暗号化して暗号化データ部を作成し、前記パケット送信装置と前記パケット受信装置との間で暗号化するための共通鍵を検索するための共通鍵識別情報を含む第１暗号化ヘッダを作成する手段と、
前記共通鍵を公開鍵で暗号化して暗号化共通鍵を作成し、前記暗号化共通鍵及び前記公開鍵の識別情報を含む第２暗号化ヘッダを作成する手段と、
前記第１暗号化ヘッダと前記第２暗号化ヘッダと前記暗号化データ部とを含む暗号化パケットを前記パケット転送装置へ送信するための手段と、
を備え、
前記パケット転送装置は、
前記暗号化パケットを前記パケット送信装置から受信し、受信したパケットが前記第２暗号化ヘッダを含む場合、前記第２暗号化ヘッダ中の公開鍵の識別情報に基づき、前記公開鍵に対応する秘密鍵を求め、前記第２暗号化ヘッダに含まれる前記暗号化共通鍵を前記秘密鍵で復号化して前記共通鍵を求め、前記暗号化パケットから前記第２暗号化ヘッダを削除する手段と、
求めた前記共通鍵で前記暗号化パケットの前記暗号化データ部を復号化して前記パケットデータ部を求め、前記暗号化パケットから前記第１暗号化ヘッダをさらに削除する手段と、
前記パケットデータ部を検閲し、前記パケットデータ部を含むパケットを転送してもよいか判断する手段と、
前記パケットデータ部を含むパケットを転送してもよいと判断された場合、前記パケットデータ部を前記共通鍵で暗号化して前記暗号化データ部を作成し、前記暗号化データ部と、前記共通鍵識別情報を含む第１暗号化ヘッダを含む第１暗号化ヘッダ付き暗号化パケットを作成する手段と、
前記第１暗号化ヘッダ付き暗号化パケットを前記他のネットワークへ送信するための手段と、
を備えた前記暗号化パケット通信システムが提供される。
前記パケット送信装置は、
前記パケットのパケットデータ部を共通鍵で暗号化して暗号化データ部を作成し、前記パケット送信装置と前記パケット受信装置との間で暗号化するための共通鍵を検索するための共通鍵識別情報を含む第１暗号化ヘッダを作成する手段と、
前記共通鍵を公開鍵で暗号化して暗号化共通鍵を作成し、前記暗号化共通鍵及び前記公開鍵の識別情報を含む第２暗号化ヘッダを作成する手段と、
前記第１暗号化ヘッダと前記第２暗号化ヘッダと前記暗号化データ部とを含む暗号化パケットを前記パケット転送装置へ送信するための手段と、
を備え、
前記パケット転送装置は、
前記暗号化パケットを前記パケット送信装置から受信し、受信したパケットが前記第２暗号化ヘッダを含む場合、前記第２暗号化ヘッダ中の公開鍵の識別情報に基づき、前記公開鍵に対応する秘密鍵を求め、前記第２暗号化ヘッダに含まれる前記暗号化共通鍵を前記秘密鍵で復号化して前記共通鍵を求め、前記暗号化パケットから前記第２暗号化ヘッダを削除する手段と、
求めた前記共通鍵で前記暗号化パケットの前記暗号化データ部を復号化して前記パケットデータ部を求め、前記暗号化パケットから前記第１暗号化ヘッダをさらに削除する手段と、
前記パケットデータ部を検閲し、前記パケットデータ部を含むパケットを転送してもよいか判断する手段と、
前記パケットデータ部を含むパケットを転送してもよいと判断された場合、前記パケットデータ部を前記共通鍵で暗号化して前記暗号化データ部を作成し、前記暗号化データ部と、前記共通鍵識別情報を含む第１暗号化ヘッダを含む第１暗号化ヘッダ付き暗号化パケットを作成する手段と、
前記第１暗号化ヘッダ付き暗号化パケットを前記他のネットワークへ送信するための手段と、
を備えた前記暗号化パケット通信システムが提供される。
本発明によって、ゲートウェイ装置で転送するパケットの検閲ができるようになり、かつ、以下のような効果を奏する。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、ゲートウェイは複雑な事前鍵交換プロトコルを具備する必要がなくなる。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、共通鍵を保持するメモリが不要となる。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、従来ではパケットが届く度に実施していた共通鍵の検索が不要となる。よって、使用するＣＰＵリソースを減らすことができる。
・ゲートウェイ装置が管理する組織網内で転送されるパケットも暗号化が施されているため、組織網内でパケットを盗聴されない。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、ゲートウェイは複雑な事前鍵交換プロトコルを具備する必要がなくなる。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、共通鍵を保持するメモリが不要となる。
・ゲートウェイ装置は暗号化されたパケットを復号化する為の、端末毎の共通鍵を保持する必要がないので、従来ではパケットが届く度に実施していた共通鍵の検索が不要となる。よって、使用するＣＰＵリソースを減らすことができる。
・ゲートウェイ装置が管理する組織網内で転送されるパケットも暗号化が施されているため、組織網内でパケットを盗聴されない。
本発明の実施の形態について図面を用いて説明する。
１．暗号化パケット検閲システム
図１に、暗号化パケット検閲システムのネットワーク構成図を示す。
以下、本発明の実施の形態の説明では、パケットデータを暗号化する方法に、ＩＰｓｅｃを用いることを例にして説明するが、パケットデータを暗号化するにあたり、他のパケット暗号化方法を採用した場合でも、同様に本発明を実施することが可能である。
この図は一般的なインターネット接続構成を示しており、企業網などのＩＰネットワーク１ａと、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）等が個人ユーザへ提供するＩＰネットワーク１ｃとの間に、インターネット等のＩＰネットワーク１ｂが中継ネットワークとして存在する構成である。
ＩＰネットワーク１ａとＩＰネットワーク１ｃを中継するためにＳＧＷ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ）３が設置されている。ＩＰネットワーク１ｂとＩＰネットワーク１ｃを中継するためにＩＳＰ−ＧＷ（Ｉｎｔｅｒｎｓｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｇａｔｅｗａｙ）４がある。ＩＰネットワーク１ａには、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）２ａ、ＰＣ２ｂ、ＰＣ２ｃがあり、それぞれＳＧＷ３へ接続されている。ＩＰネットワーク１ｂには、ＰＣ２ｄ、ＰＣ２ｅ、ＰＣ２ｆがあり、それぞれＩＳＰ−ＧＷ４に接続されている。
また、図１１に、各ＩＰネットワークで伝送されるパケットのフォーマットについての説明図を示す。
図示のように、ＰＣ２ａは、ＰＫヘッダ付き暗号化パケット１０１を送信し、ＳＧＷ３はＰＫヘッダ付き暗号化パケット１０１をデカプセル化し（例、ＰＫヘッダの除去）、ＩＰｓｅｃ暗号化パケット１０２を生成し、ＩＰネットワーク１ｂへ転送する。ここで、ＩＰｓｅｃ暗号化パケット１０２は、従来のＩＰｓｅｃパケットと互換性があり、ＩＰｓｅｃ暗号化パケット１０２を受信する装置は、本発明又は本実施の形態を実施するための特別な変更をしなくて済む効果がある。一方、ＩＳＰ−ＧＷ４は、ＩＰｓｅｃ暗号化パケット１０２を受信すると、デカプセル化および復号化をし（例、ＥＳＰヘッダの除去）、ＴＣＰ／ＩＰパケット１０３を生成し、ＩＰネットワーク１ｃへ転送する。
１．暗号化パケット検閲システム
図１に、暗号化パケット検閲システムのネットワーク構成図を示す。
以下、本発明の実施の形態の説明では、パケットデータを暗号化する方法に、ＩＰｓｅｃを用いることを例にして説明するが、パケットデータを暗号化するにあたり、他のパケット暗号化方法を採用した場合でも、同様に本発明を実施することが可能である。
この図は一般的なインターネット接続構成を示しており、企業網などのＩＰネットワーク１ａと、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）等が個人ユーザへ提供するＩＰネットワーク１ｃとの間に、インターネット等のＩＰネットワーク１ｂが中継ネットワークとして存在する構成である。
ＩＰネットワーク１ａとＩＰネットワーク１ｃを中継するためにＳＧＷ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ）３が設置されている。ＩＰネットワーク１ｂとＩＰネットワーク１ｃを中継するためにＩＳＰ−ＧＷ（Ｉｎｔｅｒｎｓｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｇａｔｅｗａｙ）４がある。ＩＰネットワーク１ａには、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）２ａ、ＰＣ２ｂ、ＰＣ２ｃがあり、それぞれＳＧＷ３へ接続されている。ＩＰネットワーク１ｂには、ＰＣ２ｄ、ＰＣ２ｅ、ＰＣ２ｆがあり、それぞれＩＳＰ−ＧＷ４に接続されている。
また、図１１に、各ＩＰネットワークで伝送されるパケットのフォーマットについての説明図を示す。
図示のように、ＰＣ２ａは、ＰＫヘッダ付き暗号化パケット１０１を送信し、ＳＧＷ３はＰＫヘッダ付き暗号化パケット１０１をデカプセル化し（例、ＰＫヘッダの除去）、ＩＰｓｅｃ暗号化パケット１０２を生成し、ＩＰネットワーク１ｂへ転送する。ここで、ＩＰｓｅｃ暗号化パケット１０２は、従来のＩＰｓｅｃパケットと互換性があり、ＩＰｓｅｃ暗号化パケット１０２を受信する装置は、本発明又は本実施の形態を実施するための特別な変更をしなくて済む効果がある。一方、ＩＳＰ−ＧＷ４は、ＩＰｓｅｃ暗号化パケット１０２を受信すると、デカプセル化および復号化をし（例、ＥＳＰヘッダの除去）、ＴＣＰ／ＩＰパケット１０３を生成し、ＩＰネットワーク１ｃへ転送する。
以下、図１に示す構成において、ＰＣ２ａがＰＣ２ｄへＩＰｓｅｃで暗号化したＩＰパケットを送信する場合について説明する。
２．ユーザ端末装置（ＰＣ）
図２は、ユーザ端末装置の装置構成図である。なお、ユーザ端末装置ＰＣａ、ＰＣ２ｂ、ＰＣ２ｃは、それぞれ同様の構成である。
ＰＣ２ａは少なくとも、４つのハードウェアブロックを備える。以下に各ハードウェアブロックについて説明する。
・ソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク２００。
・本装置の制御を司るＣＰＵ２０１。
・ソフトウェアを実行に際して一時的に利用する領域であるメモリ２０２。
・ＩＰパケットを送信するネットワークインターフェイス２０３。
上述のハードウェアブロックは、全てバス２０４で接続される。
図２は、ユーザ端末装置の装置構成図である。なお、ユーザ端末装置ＰＣａ、ＰＣ２ｂ、ＰＣ２ｃは、それぞれ同様の構成である。
ＰＣ２ａは少なくとも、４つのハードウェアブロックを備える。以下に各ハードウェアブロックについて説明する。
・ソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク２００。
・本装置の制御を司るＣＰＵ２０１。
・ソフトウェアを実行に際して一時的に利用する領域であるメモリ２０２。
・ＩＰパケットを送信するネットワークインターフェイス２０３。
上述のハードウェアブロックは、全てバス２０４で接続される。
図３は、ユーザ端末装置のソフトウェア構成を示した説明図である。なお、ユーザ端末装置ＰＣａ、ＰＣ２ｂ、ＰＣ２ｃは、それぞれ同様の構成である。
ユーザ端末装置は、アプリケーションプログラム３０１ａ、３０１ｂを含む。ソケットインターフェイス３０２ａ、３０２ｂ、３０２ｃは、ユーザ空間からカーネル空間へデータパケットを送信する。ＴＣＰ制御部３０４は、ＴＣＰヘッダをデータパケットに追加し、また、コネクション管理をする。ＵＤＰ制御部３０５は、ＵＤＰヘッダをデータパケットに追加する。ＳＣＴＰ制御部３０６は、ＳＣＴＰヘッダをデータパケットに追加し、また、コネクション管理をする。ＩＰｖ４制御部３０７は、ＩＰｖ４ヘッダをＴＣＰ、ＵＤＰ、ＳＣＴＰ等の上位レイヤからのパケットに付与する。ＩＰｖ６制御部３０８は、ＩＰｖ４制御部３０７と同様に、ＩＰｖ６ヘッダを付与する。
ＩＰｓｅｃ制御部３０９は、ＩＰパケットに対し、暗号化やＩＰｓｅｃヘッダを付与する。セキュリティポリシデータベース３１０では、ＩＰｓｅｃ制御部３０９が、ＩＰｖ４制御部３０７やＩＰｖ６制御部３０８が構築したパケットに対して、ＩＰｓｅｃを適用するべきか判断する。共通鍵データベース３１１は、前記パケットをＩＰｓｅｃ暗号化するための共通鍵を保持する。公開鍵データベース３１２は、前記共通鍵を暗号化するための公開鍵を保持する。暗号化共通鍵制御部３１３は、ＩＰｓｅｃ制御部３０９が構築した前記パケットに、前記共通鍵を前記公開鍵で暗号化した結果を付与する。
リンクレイヤ制御部３１４は、暗号化共通鍵制御部３１３や、ＩＰｓｅｃ制御部３０９が構築したパケットに対して、ＭＡＣアドレスを付与する。ＮＩＦ制御部３１５はネットワークインターフェイスデバイスを制御する。
プロセス管理部３２１は、単位時間内に、どのプロセスをＣＰＵ２０１で実行させるかを制御する。プロセス情報データベース３２２には、プロセス管理部３２１が、すべての実行中プロセス情報を格納しておく。
ユーザ端末装置は、アプリケーションプログラム３０１ａ、３０１ｂを含む。ソケットインターフェイス３０２ａ、３０２ｂ、３０２ｃは、ユーザ空間からカーネル空間へデータパケットを送信する。ＴＣＰ制御部３０４は、ＴＣＰヘッダをデータパケットに追加し、また、コネクション管理をする。ＵＤＰ制御部３０５は、ＵＤＰヘッダをデータパケットに追加する。ＳＣＴＰ制御部３０６は、ＳＣＴＰヘッダをデータパケットに追加し、また、コネクション管理をする。ＩＰｖ４制御部３０７は、ＩＰｖ４ヘッダをＴＣＰ、ＵＤＰ、ＳＣＴＰ等の上位レイヤからのパケットに付与する。ＩＰｖ６制御部３０８は、ＩＰｖ４制御部３０７と同様に、ＩＰｖ６ヘッダを付与する。
ＩＰｓｅｃ制御部３０９は、ＩＰパケットに対し、暗号化やＩＰｓｅｃヘッダを付与する。セキュリティポリシデータベース３１０では、ＩＰｓｅｃ制御部３０９が、ＩＰｖ４制御部３０７やＩＰｖ６制御部３０８が構築したパケットに対して、ＩＰｓｅｃを適用するべきか判断する。共通鍵データベース３１１は、前記パケットをＩＰｓｅｃ暗号化するための共通鍵を保持する。公開鍵データベース３１２は、前記共通鍵を暗号化するための公開鍵を保持する。暗号化共通鍵制御部３１３は、ＩＰｓｅｃ制御部３０９が構築した前記パケットに、前記共通鍵を前記公開鍵で暗号化した結果を付与する。
リンクレイヤ制御部３１４は、暗号化共通鍵制御部３１３や、ＩＰｓｅｃ制御部３０９が構築したパケットに対して、ＭＡＣアドレスを付与する。ＮＩＦ制御部３１５はネットワークインターフェイスデバイスを制御する。
プロセス管理部３２１は、単位時間内に、どのプロセスをＣＰＵ２０１で実行させるかを制御する。プロセス情報データベース３２２には、プロセス管理部３２１が、すべての実行中プロセス情報を格納しておく。
図４は、セキュリティポリシデータベース３１０と共通鍵データベース３１１と公開鍵データベース３１２の構造と関係を示した説明図である。
セキュリティポリシデータベース４００は、図３のセキュリティポリシデータベース３１０に対応する。セキュリティポリシ４０１は、セキュリティポリシデータベース４００からポイントされている。セキュリティポリシデータベース４００はセキュリティポリシ４０１を複数格納することができる。
セキュリティポリシ４０１には、セレクタ４１０、共通鍵ポインタ４１７、公開鍵ポインタ４１８が含まれる。セキュリティポリシデータベース４００は、ＩＰｖ４制御部３０７またはＩＰｖ６制御部３０８が構築したパケットに含まれる情報である、セレクタ４１０に含まれる発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３、発ポート番号４１４、宛先ポート番号４１５をそれぞれ比較し、すべて一致するものを検索して取得することができる。ただし、発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３、発ポート番号４１４、宛先ポート番号４１５の１つまたは複数に「ａｎｙ」と指定した場合は、「ａｎｙ」と指定した項目についての検索は行わない。なお、例えば、発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３は、ＩＰヘッダに含まれ、発ポート番号４１４、宛先ポート番号４１５はＴＣＰヘッダに含まれる。
または、セキュリティポリシデータベース４００は、パケットを送出したアプリケーション名と、アプリケーション名４１６を比較し、一致したものを取得することができる。ただし、アプリケーション名４１６に「ａｎｙ」と指定した場合は、アプリケーション名による検索は行わない。さらに、セキュリティポリシデータベース４００は、発ＩＰアドレス４１１〜アプリケーション名４１６の全ての情報を比較してもよい。
アプリケーション名による検索は、ＯＳ（オペレーティングシステム）のプロセス管理部３２１が管理しているプロセス情報と比較して行うことができる。プロセスとは、ＯＳで実行中のプログラムのことである。プロセス管理部３２１が、現在ＣＰＵ２０１で実行しているプロセスを「実行中である」とプロセス情報データベース３２２に記録している。よって、どの機能部であっても、プロセス情報データベース３２２を検索することにより、現在ＣＰＵ２０１を実行しているプロセス情報を知ることができる。このプロセス情報の中には、アプリケーション名も含まれているので、ＩＰｓｅｃ制御部３０９は、プロセス情報データベース３２２を検索し、アプリケーション名４１６と文字列比較するためのアプリケーション名を取得する。この手段によれば、アプリケーション３０１ａやアプリケーション３０１ｂは、ＩＰｓｅｃ制御部３０９に、自身のアプリケーション名を伝える必要はなく、そのためのインターフェイスを作成しなくても良いという利点がある。
セキュリティポリシデータベース４００は、図３のセキュリティポリシデータベース３１０に対応する。セキュリティポリシ４０１は、セキュリティポリシデータベース４００からポイントされている。セキュリティポリシデータベース４００はセキュリティポリシ４０１を複数格納することができる。
セキュリティポリシ４０１には、セレクタ４１０、共通鍵ポインタ４１７、公開鍵ポインタ４１８が含まれる。セキュリティポリシデータベース４００は、ＩＰｖ４制御部３０７またはＩＰｖ６制御部３０８が構築したパケットに含まれる情報である、セレクタ４１０に含まれる発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３、発ポート番号４１４、宛先ポート番号４１５をそれぞれ比較し、すべて一致するものを検索して取得することができる。ただし、発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３、発ポート番号４１４、宛先ポート番号４１５の１つまたは複数に「ａｎｙ」と指定した場合は、「ａｎｙ」と指定した項目についての検索は行わない。なお、例えば、発ＩＰアドレス４１１、宛先ＩＰアドレス４１２、Ｌ４プロトコル番号４１３は、ＩＰヘッダに含まれ、発ポート番号４１４、宛先ポート番号４１５はＴＣＰヘッダに含まれる。
または、セキュリティポリシデータベース４００は、パケットを送出したアプリケーション名と、アプリケーション名４１６を比較し、一致したものを取得することができる。ただし、アプリケーション名４１６に「ａｎｙ」と指定した場合は、アプリケーション名による検索は行わない。さらに、セキュリティポリシデータベース４００は、発ＩＰアドレス４１１〜アプリケーション名４１６の全ての情報を比較してもよい。
アプリケーション名による検索は、ＯＳ（オペレーティングシステム）のプロセス管理部３２１が管理しているプロセス情報と比較して行うことができる。プロセスとは、ＯＳで実行中のプログラムのことである。プロセス管理部３２１が、現在ＣＰＵ２０１で実行しているプロセスを「実行中である」とプロセス情報データベース３２２に記録している。よって、どの機能部であっても、プロセス情報データベース３２２を検索することにより、現在ＣＰＵ２０１を実行しているプロセス情報を知ることができる。このプロセス情報の中には、アプリケーション名も含まれているので、ＩＰｓｅｃ制御部３０９は、プロセス情報データベース３２２を検索し、アプリケーション名４１６と文字列比較するためのアプリケーション名を取得する。この手段によれば、アプリケーション３０１ａやアプリケーション３０１ｂは、ＩＰｓｅｃ制御部３０９に、自身のアプリケーション名を伝える必要はなく、そのためのインターフェイスを作成しなくても良いという利点がある。
共通鍵データベース４０２は、図３の共通鍵データベース３１１に相当し、複数の共通鍵を保持する。前記共通鍵は、ＩＰｓｅｃ暗号化に使用するものである。セキュリティポリシ４０１は、前記共通鍵への共通鍵ポインタ４１７を保持しているので、セキュリティポリシ４０１を取得することにより、前記共通鍵にアクセスすることが可能である。
公開鍵データベース４０３は、図３の公開鍵データベース３１２に相当し、複数の公開鍵を保持する。前記公開鍵は、前記共通鍵の暗号化にしようするものである。セキュリティポリシ４０１は、前記共通鍵への公開鍵ポインタ４１８を保持しているので、セキュリティポリシ４０１を取得することにより、前記公開鍵にアクセスすることが可能である。公開鍵ポインタ４１８には、空ポインタ指定することもできる。空ポインタが指定されていた場合は、前記共通鍵を前記パケットに付与しない。
公開鍵データベース４０３は、図３の公開鍵データベース３１２に相当し、複数の公開鍵を保持する。前記公開鍵は、前記共通鍵の暗号化にしようするものである。セキュリティポリシ４０１は、前記共通鍵への公開鍵ポインタ４１８を保持しているので、セキュリティポリシ４０１を取得することにより、前記公開鍵にアクセスすることが可能である。公開鍵ポインタ４１８には、空ポインタ指定することもできる。空ポインタが指定されていた場合は、前記共通鍵を前記パケットに付与しない。
図５は、ユーザ端末装置のパケット送信処理フローを示した説明図である。また図６は、ユーザ端末装置が送受信するパケットフォーマットを示した説明図である。次に、ユーザ端末装置ＰＣａにおいて、パケット暗号化を行うＩＰｓｅｃ制御部３０９の動作と暗号化共通鍵制御部の動作について、図５および図６を使いさらに具体的に説明する。
ＩＰｓｅｃ制御部３０９は、ＩＰｖ４制御部３０７またはＩＰｖ６制御部３０８よりパケットを受け取ると、ＩＰヘッダ６０１およびＴＣＰヘッダ６０２、または、プロセスデータベース情報データベース３２２より取得した送信元アプリケーション情報から、セキュリティポリシデータベース３１０を検索し、セレクタ４１０に該当するセキュリティポリシ４０１を取得する（ステップＳ５０１）。
該当するセキュリティポリシ４０１が存在しない場合は、ＩＰｓｅｃ制御部３０９は、ＩＰｓｅｃ処理を行わない（ステップＳ５０２）。一方、該当するセキュリティポリシ４０１が存在した場合は、ＩＰｓｅｃ制御部３０９は、共通鍵ポインタ４１７から共通鍵データベース４０２に格納されている共通鍵で、前記パケットのＴＣＰヘッダ部６０２とデータ部６０３を暗号化する（ステップＳ５０３）。また、ＩＰｓｅｃ制御部３０９は、受信側であるＰＣ２ｄで復号するための共通鍵を検索できるように、ＩＰｓｅｃの共通鍵ＩＤが含まれているＥＳＰヘッダ６１３を作成し、暗号化したパケットには、そのＥＳＰヘッダ６１３を付与する（ステップＳ５０４）。共通鍵ＩＤとは、任意のデータを暗号化した共通鍵を識別するためのＩＤであり、ＩＰｓｅｃ方式ではＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ）とも呼ばれている。
つぎに、ステップＳ５０１で検索したセキュリティポリシ４０１に含まれている、公開鍵ポインタ４１８が空だった場合は（ステップＳ５０５）、ＩＰｓｅｃ制御部３０９は、前記共通鍵で暗号化したパケットをリンクレイヤ制御部３１４へ渡し、リンクレイヤ制御部３１４は、送信要求する。
一方、ステップＳ５０１で検索したセキュリティポリシ４０１に含まれている、公開鍵ポインタ４１８が、公開鍵データベース４０３に含まれる公開鍵のアドレスを指していた場合は（ステップＳ５０５）、ＩＰｓｅｃ制御部３０９は暗号化共通鍵制御部３１３へ共通鍵でデータ部６１５及びＴＣＰヘッダ６１４を暗号化したパケットを渡し、暗号化共通鍵制御部３１３は、該当する公開鍵で前記共通鍵を暗号化する（ステップＳ５０６）。暗号化共通鍵制御部３１３は、共通鍵を暗号化した公開鍵ＩＤ６２３と暗号化した共通鍵（暗号化共通鍵）６２２とを含むＰＫヘッダ６１２を前記パケットへ付与する（ステップＳ５０７）。暗号化共通鍵制御部３１３は、上述の処理を施したパケット（図１１、ＰＫヘッダ付き暗号化パケット）をリンクレイヤ制御部３１４に渡し、リンクレイヤ制御部３１４はデバイスへ送信要求する（ステップＳ５０８）。
ＩＰｓｅｃ制御部３０９は、ＩＰｖ４制御部３０７またはＩＰｖ６制御部３０８よりパケットを受け取ると、ＩＰヘッダ６０１およびＴＣＰヘッダ６０２、または、プロセスデータベース情報データベース３２２より取得した送信元アプリケーション情報から、セキュリティポリシデータベース３１０を検索し、セレクタ４１０に該当するセキュリティポリシ４０１を取得する（ステップＳ５０１）。
該当するセキュリティポリシ４０１が存在しない場合は、ＩＰｓｅｃ制御部３０９は、ＩＰｓｅｃ処理を行わない（ステップＳ５０２）。一方、該当するセキュリティポリシ４０１が存在した場合は、ＩＰｓｅｃ制御部３０９は、共通鍵ポインタ４１７から共通鍵データベース４０２に格納されている共通鍵で、前記パケットのＴＣＰヘッダ部６０２とデータ部６０３を暗号化する（ステップＳ５０３）。また、ＩＰｓｅｃ制御部３０９は、受信側であるＰＣ２ｄで復号するための共通鍵を検索できるように、ＩＰｓｅｃの共通鍵ＩＤが含まれているＥＳＰヘッダ６１３を作成し、暗号化したパケットには、そのＥＳＰヘッダ６１３を付与する（ステップＳ５０４）。共通鍵ＩＤとは、任意のデータを暗号化した共通鍵を識別するためのＩＤであり、ＩＰｓｅｃ方式ではＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ）とも呼ばれている。
つぎに、ステップＳ５０１で検索したセキュリティポリシ４０１に含まれている、公開鍵ポインタ４１８が空だった場合は（ステップＳ５０５）、ＩＰｓｅｃ制御部３０９は、前記共通鍵で暗号化したパケットをリンクレイヤ制御部３１４へ渡し、リンクレイヤ制御部３１４は、送信要求する。
一方、ステップＳ５０１で検索したセキュリティポリシ４０１に含まれている、公開鍵ポインタ４１８が、公開鍵データベース４０３に含まれる公開鍵のアドレスを指していた場合は（ステップＳ５０５）、ＩＰｓｅｃ制御部３０９は暗号化共通鍵制御部３１３へ共通鍵でデータ部６１５及びＴＣＰヘッダ６１４を暗号化したパケットを渡し、暗号化共通鍵制御部３１３は、該当する公開鍵で前記共通鍵を暗号化する（ステップＳ５０６）。暗号化共通鍵制御部３１３は、共通鍵を暗号化した公開鍵ＩＤ６２３と暗号化した共通鍵（暗号化共通鍵）６２２とを含むＰＫヘッダ６１２を前記パケットへ付与する（ステップＳ５０７）。暗号化共通鍵制御部３１３は、上述の処理を施したパケット（図１１、ＰＫヘッダ付き暗号化パケット）をリンクレイヤ制御部３１４に渡し、リンクレイヤ制御部３１４はデバイスへ送信要求する（ステップＳ５０８）。
３．セキュリティゲートウェイ（ＳＧＷ）
次に、パケットを検閲するＳＧＷ３について説明する。
図７は、ＳＧＷ３の装置構成図である。ＳＧＷ３は少なくとも、５つのハードウェアブロックを備える。以下に各ハードウェアブロックについて説明する。
・ソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク７００。
・本装置の制御を司るＣＰＵ７０１。
・ソフトウェアを実行に際して一時的に利用する領域であるメモリ７０２。
・ＩＰパケットを送信するネットワークインターフェイス７０３ａ、ネットワークインターフェイス７０３ｂ。
上述のハードウェアブロックは、全てバス７０４で接続される。
次に、パケットを検閲するＳＧＷ３について説明する。
図７は、ＳＧＷ３の装置構成図である。ＳＧＷ３は少なくとも、５つのハードウェアブロックを備える。以下に各ハードウェアブロックについて説明する。
・ソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク７００。
・本装置の制御を司るＣＰＵ７０１。
・ソフトウェアを実行に際して一時的に利用する領域であるメモリ７０２。
・ＩＰパケットを送信するネットワークインターフェイス７０３ａ、ネットワークインターフェイス７０３ｂ。
上述のハードウェアブロックは、全てバス７０４で接続される。
図８は、ＳＧＷ３のソフトウェア構成を示した説明図である。ＳＧＷ３は、パケットを検閲するためのアプリケーションプログラム８０１を含む。ソケットインターフェイス８０２は、カーネル空間からユーザ空間へまたはその逆へパケットを渡す。ＲＡＷ制御部８０３は、ソケット８０２へ、ＩＰヘッダ６１０を含んだパケットを渡す。また、ＲＡＷ制御部８０３は、ソケット８０２からＩＰｖ４制御部８０４又はＩＰｖ６制御部８０５へパケットを渡す。ＩＰｖ４制御部８０４は、ＩＰｖ４パケットを別インターフェイスに転送するための制御を行い、また、パケットのコピーを作成し、ＲＡＷ制御部８０３へ、前記コピーしたパケット渡す。ＩＰｖ６制御部８０５は、ＩＰｖ６パケットを別インターフェイスに転送するための制御を行い、また、パケットのコピーを作成し、ＲＡＷ制御部８０３へ、前記コピーしたパケット渡す。また、ＩＰｖ４制御部８０４、ＩＰｖ６制御部８０５は、ＲＡＷ制御部８０３から受けたパケットをＩＰｓｅｃ制御部８０６へ渡す。
ＩＰｓｅｃ制御部８０６は、受信したパケットの暗号化されたデータ部６１５及びＴＣＰヘッダ６１４を共通鍵で復号化し、ＥＳＰヘッダ６１３を取り除き、その後、ＩＰｖ４制御部８０４およびＩＰｖ６制御部８０５へ前記パケットを送信する。なお、ＩＰｓｅｃ制御部８０６は、復号化した共通鍵を保持しておいてもよい。また、ＩＰｓｅｃ制御部８０６は、ＩＰｖ４制御部８０４又はＩＰｖ６制御部８０５から受けたパケットにＥＳＰヘッダを付与する。暗号化共通鍵制御部８０７は、受信したパケットのＰＫヘッダ６１２に暗号化されている共通鍵６２２を復号化し、ＰＫヘッダを取り除き、その後、復号化した前記共通鍵とＰＫヘッダを取り除いた前記パケットをＩＰｓｅｃ制御部８０６に渡す。公開鍵・秘密鍵データベース８０８は、ＰＣ２ａに送付した公開鍵と、前記公開鍵とペアになる秘密鍵を格納しておく。ペアとなる公開鍵と秘密鍵のＩＤは同一のものである。
リンクレイヤ制御部８０９は、受信したパケットをＩＰｖ４制御部８０４で処理させるべきか、ＩＰｖ６制御部８０５で処理させるべきかを判断し、暗号化共通鍵制御部８０７またはＩＰｓｅｃ制御部８０６に通知する。また、リンクレイヤ制御部８０９は、ＩＰｓｅｃ制御部８０６からＮＩＦ制御部８１０へパケットを渡す。ＮＩＦ制御部８１０は、ネットワークインターフェイス７０３ａ、７０３ｂから、受信したパケット情報を取り出し、ソフトウェアで扱えるようにメモリ７０２へ移し変える。また、ＮＩＦ制御部８１０は、リンクレイヤ制御部８０９からのパケットをネットワークインターフェイス７０３ａ、７０３ｂを介してリンクレイヤへ送信する。
ＩＰｓｅｃ制御部８０６は、受信したパケットの暗号化されたデータ部６１５及びＴＣＰヘッダ６１４を共通鍵で復号化し、ＥＳＰヘッダ６１３を取り除き、その後、ＩＰｖ４制御部８０４およびＩＰｖ６制御部８０５へ前記パケットを送信する。なお、ＩＰｓｅｃ制御部８０６は、復号化した共通鍵を保持しておいてもよい。また、ＩＰｓｅｃ制御部８０６は、ＩＰｖ４制御部８０４又はＩＰｖ６制御部８０５から受けたパケットにＥＳＰヘッダを付与する。暗号化共通鍵制御部８０７は、受信したパケットのＰＫヘッダ６１２に暗号化されている共通鍵６２２を復号化し、ＰＫヘッダを取り除き、その後、復号化した前記共通鍵とＰＫヘッダを取り除いた前記パケットをＩＰｓｅｃ制御部８０６に渡す。公開鍵・秘密鍵データベース８０８は、ＰＣ２ａに送付した公開鍵と、前記公開鍵とペアになる秘密鍵を格納しておく。ペアとなる公開鍵と秘密鍵のＩＤは同一のものである。
リンクレイヤ制御部８０９は、受信したパケットをＩＰｖ４制御部８０４で処理させるべきか、ＩＰｖ６制御部８０５で処理させるべきかを判断し、暗号化共通鍵制御部８０７またはＩＰｓｅｃ制御部８０６に通知する。また、リンクレイヤ制御部８０９は、ＩＰｓｅｃ制御部８０６からＮＩＦ制御部８１０へパケットを渡す。ＮＩＦ制御部８１０は、ネットワークインターフェイス７０３ａ、７０３ｂから、受信したパケット情報を取り出し、ソフトウェアで扱えるようにメモリ７０２へ移し変える。また、ＮＩＦ制御部８１０は、リンクレイヤ制御部８０９からのパケットをネットワークインターフェイス７０３ａ、７０３ｂを介してリンクレイヤへ送信する。
図９は、セキュリティゲートウェイのパケット検閲と転送フローチャートを示した説明図である。また図１０は、公開鍵および秘密鍵を格納しておくデータベース８０８の構成を示した説明図である。次に、ＰＣ２ａから受信した暗号化パケット６１０をＩＰｓｅｃ暗号化パケットとして転送する方法について、図９および図１０を使い、さらに具体的に説明する。
ＮＩＦ制御部８１０は、ネットワークインターフェイス７０３ａ、７０３ｂから受信したパケット（図１１、ＰＫヘッダ付き暗号化パケット）を予めメモリ７０２へ記憶している。リンクレイヤ制御部８０９は、メモリ７０２から受信したパケットを読み出し、暗号化共通鍵制御部８０７は、リンクレイヤ制御部８０９からそのパケットを受信する（ステップＳ９００）。リンクレイヤ制御部８０９は、受信したパケットにＰＫヘッダ６１２があるかどうか調べる。ＰＫヘッダが無い場合は、暗号化共通鍵制御部８０７は、パケットを検閲アプリケーション８０１に渡す（ステップＳ９０１）。一方、ＰＫヘッダ６１２がある場合、暗号化共通鍵制御部８０７は、ＰＫヘッダ６１２に含まれている公開鍵ＩＤ６２３と同一のＩＤを持つ秘密鍵を検索するため、公開鍵・秘密鍵データベース８０８を検索する（ステップＳ９０２）。
ここで、図１０に、公開鍵・秘密鍵データベース構造の説明図を示す。前記秘密鍵を取得するには、公開鍵・秘密鍵データベース１００１（図８中、公開鍵・秘密鍵データベースに相当）に含まれる公開鍵・秘密鍵エントリ１００２を順に検索する。前記検索した公開鍵・秘密鍵エントリ１００２に含まれる秘密鍵データ１０１３が、公開鍵ＩＤ６２３と同一ＩＤを持つ秘密鍵である。
ステップＳ９０２において、暗号化共通鍵制御部８０７は、秘密鍵が見つからなかった場合は（ステップＳ９０３）、パケットを廃棄する（ステップ９１５）。一方、暗号化共通鍵制御部８０７は、秘密鍵が見つかった場合（ステップＳ９０３）、ステップ９０２で取得した秘密鍵を使い、ＰＫヘッダ６１２に含まれている暗号化共通鍵６２２を復号化し、ＰＫヘッダを取り除き、復号化された共通鍵と、ＰＫヘッダを取り除いたパケットとをＩＰｓｅｃ制御部８０６に渡す（ステップＳ９０４）。次にＩＰｓｅｃ制御部８０６は、ステップＳ９０４で復号化された共通鍵を使い、暗号化パケット６１０のデータ部６１５及びＴＣＰヘッダ６１４を復号化する（ステップＳ９０７）。ＩＰｓｅｃ制御部８０６は、ステップＳ９０７で復号化したパケットからＥＳＰヘッダを取り除き、そのパケットと、ステップＳ９０６で復号化した共通鍵とを、ＩＰｖ４制御部８０４またはＩＰｖ６制御部８０５および、ＲＡＷ制御部８０３および、ソケット８０２を経由して、検閲アプリケーション８０１へ渡す（ステップＳ９０８）。
検閲アプリケーション８０１は、パケットのデータ部の内容を確認し、機密情報のキーワードが含まれている等、転送してはいけないと判断した場合は、パケットを廃棄する（ステップＳ９１５）。検閲アプリケーションが受け取るパケットデータは、復号化されており、パケットデータ部分を検閲できるという効果がある。一方、検閲アプリケーション８０１は、ステップＳ９０９にて、転送しても良いと判断した場合は、ステップＳ９０７で復号化したパケットおよび、ステップＳ９０６で復号化した共通鍵を、ソケット８０２および、ＲＡＷ制御部８０３および、ＩＰｖ４制御部８０４またはＩＰｖ６制御部８０５を経由して、ＩＰｓｅｃ制御部８０６へ渡す。ＩＰｓｅｃ制御部８０６は、前記共通鍵を用いて、データ部６１５及びＴＣＰヘッダ６１４を再び暗号化する（ステップＳ９１０）。なお、ＩＰｓｅｃ制御部８０６は、復号化した共通鍵を保持しておき、データ部の暗号化のとき、それを用いてもよい。この場合、検閲アプリケーション８０１はＩＰｓｅｃ制御部８０６に共通鍵を渡さないように構成してもよい。なお、ＩＰｓｅｃ制御部８０６は、前記暗号化を行う代わりに、ステップＳ９０７実施前の暗号化パケット６１０を一時的に保存しておき、代用することが可能である。次に、ＩＰｓｅｃ制御部８０６は、暗号化したパケットにＥＳＰヘッダ６１３を付与する（図１１、ＩＰｓｅｃ暗号化パケット１０２）（ステップＳ９１１）。この処理によって、通常のＩＰｓｅｃパケットと同様のフォーマットになる。よって、ＰＣ２ｄは、通常のＩＰｓｅｃ処理を行うことにより、パケットを正常に受信できるようになる。
ＮＩＦ制御部８１０は、ネットワークインターフェイス７０３ａ、７０３ｂから受信したパケット（図１１、ＰＫヘッダ付き暗号化パケット）を予めメモリ７０２へ記憶している。リンクレイヤ制御部８０９は、メモリ７０２から受信したパケットを読み出し、暗号化共通鍵制御部８０７は、リンクレイヤ制御部８０９からそのパケットを受信する（ステップＳ９００）。リンクレイヤ制御部８０９は、受信したパケットにＰＫヘッダ６１２があるかどうか調べる。ＰＫヘッダが無い場合は、暗号化共通鍵制御部８０７は、パケットを検閲アプリケーション８０１に渡す（ステップＳ９０１）。一方、ＰＫヘッダ６１２がある場合、暗号化共通鍵制御部８０７は、ＰＫヘッダ６１２に含まれている公開鍵ＩＤ６２３と同一のＩＤを持つ秘密鍵を検索するため、公開鍵・秘密鍵データベース８０８を検索する（ステップＳ９０２）。
ここで、図１０に、公開鍵・秘密鍵データベース構造の説明図を示す。前記秘密鍵を取得するには、公開鍵・秘密鍵データベース１００１（図８中、公開鍵・秘密鍵データベースに相当）に含まれる公開鍵・秘密鍵エントリ１００２を順に検索する。前記検索した公開鍵・秘密鍵エントリ１００２に含まれる秘密鍵データ１０１３が、公開鍵ＩＤ６２３と同一ＩＤを持つ秘密鍵である。
ステップＳ９０２において、暗号化共通鍵制御部８０７は、秘密鍵が見つからなかった場合は（ステップＳ９０３）、パケットを廃棄する（ステップ９１５）。一方、暗号化共通鍵制御部８０７は、秘密鍵が見つかった場合（ステップＳ９０３）、ステップ９０２で取得した秘密鍵を使い、ＰＫヘッダ６１２に含まれている暗号化共通鍵６２２を復号化し、ＰＫヘッダを取り除き、復号化された共通鍵と、ＰＫヘッダを取り除いたパケットとをＩＰｓｅｃ制御部８０６に渡す（ステップＳ９０４）。次にＩＰｓｅｃ制御部８０６は、ステップＳ９０４で復号化された共通鍵を使い、暗号化パケット６１０のデータ部６１５及びＴＣＰヘッダ６１４を復号化する（ステップＳ９０７）。ＩＰｓｅｃ制御部８０６は、ステップＳ９０７で復号化したパケットからＥＳＰヘッダを取り除き、そのパケットと、ステップＳ９０６で復号化した共通鍵とを、ＩＰｖ４制御部８０４またはＩＰｖ６制御部８０５および、ＲＡＷ制御部８０３および、ソケット８０２を経由して、検閲アプリケーション８０１へ渡す（ステップＳ９０８）。
検閲アプリケーション８０１は、パケットのデータ部の内容を確認し、機密情報のキーワードが含まれている等、転送してはいけないと判断した場合は、パケットを廃棄する（ステップＳ９１５）。検閲アプリケーションが受け取るパケットデータは、復号化されており、パケットデータ部分を検閲できるという効果がある。一方、検閲アプリケーション８０１は、ステップＳ９０９にて、転送しても良いと判断した場合は、ステップＳ９０７で復号化したパケットおよび、ステップＳ９０６で復号化した共通鍵を、ソケット８０２および、ＲＡＷ制御部８０３および、ＩＰｖ４制御部８０４またはＩＰｖ６制御部８０５を経由して、ＩＰｓｅｃ制御部８０６へ渡す。ＩＰｓｅｃ制御部８０６は、前記共通鍵を用いて、データ部６１５及びＴＣＰヘッダ６１４を再び暗号化する（ステップＳ９１０）。なお、ＩＰｓｅｃ制御部８０６は、復号化した共通鍵を保持しておき、データ部の暗号化のとき、それを用いてもよい。この場合、検閲アプリケーション８０１はＩＰｓｅｃ制御部８０６に共通鍵を渡さないように構成してもよい。なお、ＩＰｓｅｃ制御部８０６は、前記暗号化を行う代わりに、ステップＳ９０７実施前の暗号化パケット６１０を一時的に保存しておき、代用することが可能である。次に、ＩＰｓｅｃ制御部８０６は、暗号化したパケットにＥＳＰヘッダ６１３を付与する（図１１、ＩＰｓｅｃ暗号化パケット１０２）（ステップＳ９１１）。この処理によって、通常のＩＰｓｅｃパケットと同様のフォーマットになる。よって、ＰＣ２ｄは、通常のＩＰｓｅｃ処理を行うことにより、パケットを正常に受信できるようになる。
ＩＰｓｅｃ制御部８０６は、以上の処理を行った前記パケットをリンクレイヤ制御部８０９に渡し、リンクレイヤ制御部８０９はＮＩＦ制御部８１０を介して前記パケットをリンクレイヤへ送信し、ネットワークインターフェイス７０３ａまたは７０３ｂより、ＩＳＰ−ＧＷ４へ前記パケットを送信する（ステップＳ９１３）。なお、ＩＳＰ−ＧＷ４は、ＳＧＷ３からＩＰネットワーク１ｂを介して受信したパケット（図１１、ＩＰｓｅｃ暗号化パケット）をデカプセル化及び復号して、ＴＣＰ／ＩＰパケット（図１１参照）を得ることができる。
以上の実施の形態から明らかなように、本発明によると、暗号化しているにも関わらず、ゲートウェイ装置において、パケットの内容を検閲し、情報漏洩を防止することができる。また、ゲートウェイに保持する情報量は、ゲートウェイに接続されている端末数に依存しないので、本発明は、大規模なネットワークにも適用することができる。
１ ＩＰ網
２ パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ：ＰＣ）
３ セキュリティゲートウェイ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ：ＳＧＷ）
４ ＩＳＰゲートウェイ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｇａｔｅｗａｙ：ＩＳＰ−ＧＷ）
２ パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ：ＰＣ）
３ セキュリティゲートウェイ（Ｓｅｃｕｒｉｔｙ Ｇａｔｅｗａｙ：ＳＧＷ）
４ ＩＳＰゲートウェイ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ Ｇａｔｅｗａｙ：ＩＳＰ−ＧＷ）
Claims (6)
- パケット送信装置から、パケット送信装置を含むネットワークのパケット転送装置を介して、他のネットワーク内のパケット受信装置へパケットを送信するための暗号化パケット通信システムであって、
前記パケット送信装置は、
前記パケットのパケットデータ部を共通鍵で暗号化して暗号化データ部を作成し、前記パケット送信装置と前記パケット受信装置との間で暗号化するための共通鍵を検索するための共通鍵識別情報を含む第１暗号化ヘッダを作成する手段と、
前記共通鍵を公開鍵で暗号化して暗号化共通鍵を作成し、前記暗号化共通鍵及び前記公開鍵の識別情報を含む第２暗号化ヘッダを作成する手段と、
前記第１暗号化ヘッダと前記第２暗号化ヘッダと前記暗号化データ部とを含む暗号化パケットを前記パケット転送装置へ送信するための手段と、
を備え、
前記パケット転送装置は、
前記暗号化パケットを前記パケット送信装置から受信し、受信したパケットが前記第２暗号化ヘッダを含む場合、前記第２暗号化ヘッダ中の公開鍵の識別情報に基づき、前記公開鍵に対応する秘密鍵を求め、前記第２暗号化ヘッダに含まれる前記暗号化共通鍵を前記秘密鍵で復号化して前記共通鍵を求め、前記暗号化パケットから前記第２暗号化ヘッダを削除する手段と、
求めた前記共通鍵で前記暗号化パケットの前記暗号化データ部を復号化して前記パケットデータ部を求め、前記暗号化パケットから前記第１暗号化ヘッダをさらに削除する手段と、
前記パケットデータ部を検閲し、前記パケットデータ部を含むパケットを転送してもよいか判断する手段と、
前記パケットデータ部を含むパケットを転送してもよいと判断された場合、前記パケットデータ部を前記共通鍵で暗号化して前記暗号化データ部を作成し、前記暗号化データ部と、前記共通鍵識別情報を含む第１暗号化ヘッダを含む第１暗号化ヘッダ付き暗号化パケットを作成する手段と、
前記第１暗号化ヘッダ付き暗号化パケットを前記他のネットワークへ送信するための手段と、
を備えた前記暗号化パケット通信システム。 - 請求項１に記載の暗号化パケット通信システムにおいて、
前記パケット送信装置は、
発信元識別情報及び／又は宛先識別情報を含む少なくとも１つ以上のセキュリティポリシを格納したセキュリティポリシデータベースを備え、
送信すべきパケットの発信元識別情報及び／又は宛先識別情報に基づき前記セキュリティポリシデータベースを検索し、前記パケットが前記セキュリティポリシに該当するとき、前記第１暗号化ヘッダ及び／または第２暗号化ヘッダを前記パケットに付与するようにした前記暗号化パケット通信システム。 - 請求項１に記載の暗号化パケット通信システムにおいて、
前記パケット送信装置は、
アプリケーション名を含む少なくとも１つ以上のセキュリティポリシを格納したセキュリティポリシデータベースを備え、
送信すべきパケットについて、ＯＳが管理するプロセス情報に含まれるアプリケーション名を検索し、前記パケットを送信又は作成したアプリケーション名を用いて前記セキュリティデータベースから前記セキュリティポリシを検索し、前記パケットが前記セキュリティポリシに該当するとき、前記第１暗号化ヘッダ及び／または前記第２暗号化ヘッダを前記パケットに付与するようにした前記暗号化パケット通信システム。 - 請求項１に記載の暗号化パケット通信システムにおいて、
少なくとも１つ以上の共通鍵を格納できる共通鍵データベースをさらに備え、
前記セキュリティポリシは前記共通鍵を識別するポインタを含み、前記セキュリティポリシから前記共通鍵をポインタ経由で取得し、前記第１暗号化ヘッダを付与する手段を備えた前記暗号化パケット通信システム。 - 請求項１に記載の暗号化パケット通信システムにおいて、
少なくとも１つ以上の公開鍵を格納できる公開鍵データベースをさらに備え、
前記セキュリティポリシは前記共通鍵を識別するポインタを含み、前記セキュリティポリシから前記公開鍵をポインタ経由で取得し、前記第２暗号化ヘッダを付与する手段を備えた前記暗号化パケット通信システム。 - 請求項１に記載の暗号化パケット通信システムにおいて、
前記パケット転送装置は、公開鍵識別情報に対応して、少なくとも１つ以上の公開鍵及び秘密鍵を格納した公開鍵秘密鍵データベースをさらに備え、
前記パケット送信装置から送信されるパケットに付与されている公開鍵の識別情報に基づき、前記公開鍵秘密鍵データベースから前記秘密鍵を取得する手段をさらに備えたようにした前記暗号化パケット通信システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007016242A JP4933286B2 (ja) | 2007-01-26 | 2007-01-26 | 暗号化パケット通信システム |
| US11/965,839 US8670565B2 (en) | 2007-01-26 | 2007-12-28 | Encrypted packet communication system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007016242A JP4933286B2 (ja) | 2007-01-26 | 2007-01-26 | 暗号化パケット通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008182649A true JP2008182649A (ja) | 2008-08-07 |
| JP4933286B2 JP4933286B2 (ja) | 2012-05-16 |
Family
ID=39668003
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007016242A Expired - Fee Related JP4933286B2 (ja) | 2007-01-26 | 2007-01-26 | 暗号化パケット通信システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8670565B2 (ja) |
| JP (1) | JP4933286B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2009326848B2 (en) * | 2008-12-08 | 2015-03-12 | FnF Group Pty Ltd | System and method for adapting an internet and intranet filtering system |
| GB2471282B (en) * | 2009-06-22 | 2015-02-18 | Barclays Bank Plc | Method and system for provision of cryptographic services |
| US9445095B1 (en) * | 2011-10-06 | 2016-09-13 | Arris Enterprises, Inc. | Compression of modified data captures for packets with encrypted or non-interesting content |
| CN112105016A (zh) | 2014-07-03 | 2020-12-18 | 华为技术有限公司 | 无线网络接入保护和安全架构的系统和方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0946330A (ja) * | 1995-07-28 | 1997-02-14 | Toshiba Corp | 電子メール暗号化装置及び電子メール転送装置 |
| JPH11203222A (ja) * | 1998-01-19 | 1999-07-30 | Mitsubishi Electric Corp | 暗号通信方法 |
| WO2002067512A1 (fr) * | 2001-02-19 | 2002-08-29 | Fujitsu Limited | Technique de filtrage de paquets et systeme securise de communication de paquets |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3688830B2 (ja) * | 1995-11-30 | 2005-08-31 | 株式会社東芝 | パケット転送方法及びパケット処理装置 |
| JP3431745B2 (ja) | 1996-01-08 | 2003-07-28 | 富士通株式会社 | ゲートウェイシステム |
| US5812671A (en) * | 1996-07-17 | 1998-09-22 | Xante Corporation | Cryptographic communication system |
| JP3651721B2 (ja) * | 1996-11-01 | 2005-05-25 | 株式会社東芝 | 移動計算機装置、パケット処理装置及び通信制御方法 |
| US6084969A (en) * | 1997-12-31 | 2000-07-04 | V-One Corporation | Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network |
| CA2228687A1 (en) * | 1998-02-04 | 1999-08-04 | Brett Howard | Secured virtual private networks |
| JP2001111612A (ja) | 1999-10-05 | 2001-04-20 | Nippon Telegr & Teleph Corp <Ntt> | 情報漏洩防止方法およびシステム並びに情報漏洩防止プログラムを記録した記録媒体 |
| US7983419B2 (en) * | 2001-08-09 | 2011-07-19 | Trimble Navigation Limited | Wireless device to network server encryption |
| JP4099039B2 (ja) * | 2002-11-15 | 2008-06-11 | 松下電器産業株式会社 | プログラム更新方法 |
-
2007
- 2007-01-26 JP JP2007016242A patent/JP4933286B2/ja not_active Expired - Fee Related
- 2007-12-28 US US11/965,839 patent/US8670565B2/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0946330A (ja) * | 1995-07-28 | 1997-02-14 | Toshiba Corp | 電子メール暗号化装置及び電子メール転送装置 |
| JPH11203222A (ja) * | 1998-01-19 | 1999-07-30 | Mitsubishi Electric Corp | 暗号通信方法 |
| WO2002067512A1 (fr) * | 2001-02-19 | 2002-08-29 | Fujitsu Limited | Technique de filtrage de paquets et systeme securise de communication de paquets |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4933286B2 (ja) | 2012-05-16 |
| US20080181404A1 (en) | 2008-07-31 |
| US8670565B2 (en) | 2014-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220038440A1 (en) | Secure end-to-end transport through intermediary nodes | |
| JP4707992B2 (ja) | 暗号化通信システム | |
| JP4081724B1 (ja) | クライアント端末、中継サーバ、通信システム、及び通信方法 | |
| US6944762B1 (en) | System and method for encrypting data messages | |
| JP4933286B2 (ja) | 暗号化パケット通信システム | |
| JP6396831B2 (ja) | 暗号通信システム、暗号通信方法、暗号通信装置及び暗号通信装置登録サーバ | |
| JP3796496B2 (ja) | セキュリティ管理装置、方法、及び、プログラム | |
| Alhoaimel | Performance Evaluation of IPv6 and the Role of IPsec in Encrypting Data | |
| CN114268499A (zh) | 数据传输方法、装置、系统、设备和存储介质 | |
| JP2001103096A (ja) | ネットワークの構築方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090512 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20100122 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120214 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120216 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150224 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |