暗号化通信システム
【課題】上位アプリケーションのプログラムを変更することなく、データの漏洩、改竄、なりすまし、進入、攻撃の防止機能をさらに強化できるプロトコルスタックを提供する。
【解決手段】出入力又は送受信するパケット等の情報単位のうち、少なくともＴＣＰ又はＵＤＰに該当するプロトコルのペイロードを所定の暗号化ロジックに従って暗号化して出力又は送信するプロトコル暗号化手段と、入力又は受信した該暗号化されたプロトコルを所定の復号化ロジックに従って復号化するプロトコル復号化手段と、を少なくとも備えた通信システムを提供する。
【解決手段】出入力又は送受信するパケット等の情報単位のうち、少なくともＴＣＰ又はＵＤＰに該当するプロトコルのペイロードを所定の暗号化ロジックに従って暗号化して出力又は送信するプロトコル暗号化手段と、入力又は受信した該暗号化されたプロトコルを所定の復号化ロジックに従って復号化するプロトコル復号化手段と、を少なくとも備えた通信システムを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信における暗号化通信システム、特に、インターネット上でのデータの「漏洩」及び「改竄」さらには「なりすまし」、「進入」ないし「攻撃」を防ぐための暗号化通信システムに関する。
【背景技術】
【０００２】
近年、インターネットを利用した通信は、Ｗｉｎｄｏｗｓパソコンさえあれば、それをネットワークに接続するだけで、誰でもネットワーク上のコンピュータにアクセスできるため、社会の中で急速に普及拡大している。一方、このインターネット通信の普及拡大に伴って、ハッカー（hacker）やクラッカー（Cracker）が他人のコンピュータシステムに侵入して、ソフトウエアやデータを盗み見たり、改竄や破壊を行ったりするという社会問題も大きくなっている。
【０００３】
具体的な不正妨害のケースとしては、まず第１に、中心的なシステムが使えなくなるように、ネットワークから大量のメッセージを送りつけコンピュータシステムの運用を妨害するシステム妨害がある。この妨害によってホストが過負荷になるとシステムダウンに陥ってしまうことも起こりうる。
【０００４】
また、ホストのパスワードを入手し、機密情報を盗んだり、情報の改竄や破壊を行ったりする「不正アクセスとなりすまし」の不正妨害がある。この妨害にはコンピュータが保有する情報を勝手に書き換え、人を陥れる卑劣のものもある。また、特定のパソコンに忍び込み、メールアドレスやパスワードなど個人の機密データを搾取するスパイウエアといわれる不正行為も発生している。このようにネットワークに接続したコンピュータが持つデータベースの内容を不正に盗み見る、いわゆる盗聴行為も頻繁に行われている可能性も否定できない。
【０００５】
また、サイト若しくはサーバの運営元で、意図的に個人情報を盗むといった行為や、社内に潜むスパイなどによるサイバーテロ（Cyber terrorism）といった危機も全くないとはいえない状況である。
さらに、他人のコンピュータにコンピュータ障害をもたらすプログラムである「ウイルス」を送り込むという不正妨害が最近多くなっている。この送り込まれたウイルスに、メールなどを自宅で使用したパソコンが感染し、それを社内に接続した瞬間に社内のパソコン全体が感染したり、ウイルスがコンピュータの中のファイルを破壊させたり、更には、ネットワーク全体をダウンさせたりするといった問題も生じている。
【０００６】
このため、従来のＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）やＵＤＰ（User Datagram Protocol）を利用したインターネット上での通信において、データの「漏洩」「改竄」等を防ぐ機能として、ＩＰｓｅｃ（アイピーセック：Security Architecture for Internet Protocol）やＳＳＬ（Secure Socket Layer）といわれる暗号化通信が利用されている。一般に、暗号化通信には、共通鍵（秘密鍵ともいう）暗号方式と公開鍵暗号方式があるが、ＩＰｓｅｃは共通鍵暗号方式を用いたものが多い。共通鍵暗号方式の方が公開鍵暗号方式より暗号化・復号化の速度が速いという特徴がある。このＩＰｓｅｃに用いられる共通鍵暗号方式は、暗号化と復号化を同じ鍵で行う方式であり、鍵の生成は送信側又は受信側のいずれで生成してもよいが、受信側と送信側とで共通鍵を使うために、鍵の交換時に内容が外部に漏れないよう細心の注意を払わなければならない。
【０００７】
共通鍵暗号方式に用いられるアルゴリズムはＤＥＳ（Data Encryption Standard:米国ＩＢＭ社が開発した共通鍵（秘密鍵）暗号化アルゴリズム）が代表的である。ＩＰｓｅｃもこのＤＥＳを暗号アルゴリズムの１つに採用している。ＩＰｓｅｃの特徴は、単に特定のアプリケーションだけを暗号化するのではなく、ホストから送信されるあらゆる通信をＩＰレベルで暗号化する点にある。これによりユーザはアプリケーションを意識することなく安全な通信を可能とすることができる。また、ＩＰｓｅｃは、将来にわたって使えるように、それ自体の仕組みを変えることなく使用する暗号アルゴリズムを変更することを可能としている。
【０００８】
ＩＰｓｅｃで用いられる共通暗号鍵としては、ＳＰＩ（Security Pointer Index）と呼ばれる３２ビット符合が用いられ、鍵交換プロトコルとしては、ＩＫＥ（Internet Key Exchange）が用いられる。さらに、ＩＰｓｅｃには、完全性認証のためのプロトコルＡＨ（Authentication Header）が用意されている。
【０００９】
また、ＳＳＬは、米ネットスケープ社（現在ＡＯＬに吸収合併）の開発したセキュリティ機能付ＨＴＴＰプロトコルであり、これを利用することによりクライアントとサーバがネットワーク上でお互いを認証できるようになり、クレジットカード情報などの機密性の高い情報を暗号化してやり取りすることが可能となる。これにより、データの盗聴、再送攻撃（ネットワーク上に流れたデータを盗聴して何度も繰り返して送ってくる攻撃）、なりすまし（本人の振りをして通信する）、データの改竄などを防止することができる。
【００１０】
上述したＩＰｓｅｃは、ＩＰのパケットを暗号化して送受信するものであり、したがって、ＴＣＰやＵＤＰなどの上位のプロトコルを利用するアプリケーションソフトはＩＰｓｅｃが使われていることを意識する必要がない。
一方、ＳＳＬでは、互いの認証レベルではＲＳＡ（Rivest Shamir Adleman：公開鍵暗号方式を開発者３人の頭文字）公開鍵暗号技術を用いたデジタル証明書が用いられ、データの暗号化ではＤＥＳなどの共通鍵暗号技術が用いられている。このＳＳＬは第５層のセッション層にあるため、特定のアプリケーションに依存することになる。
【非特許文献１】R.Atkinson, 1995年8月、「Security Architecture for the Internet Protocol」、RFC 1825
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、ＳＳＬはアプリケーションに対する互換性を持たない点において問題がある。アプリケーションは、インターネット通信を行う際にソケット（第５層）をプログラムインターフェースとして使用する。このため、アプリケーションがＳＳＬ（第５層）を使用する場合には、このソケットインターフェースをＳＳＬインターフェースに変更しなければならない。従って、ＳＳＬにアプリケーションの互換性はない。これに対し、ＩＰｓｅｃは、ソケット（第５層）の下に位置しているため、アプリケーションは、ソケット（第５層）をプログラムインターフェースとしてそのまま使用することができるのでアプリケーションの互換性がある。
【００１２】
一方、ＩＰｓｅｃは最大セグメントサイズが小さくなるという問題がある。すなわち、ＩＰｓｅｃでは、ＥＳＰヘッダ、ＥＳＰトレーラを使用するため、ペイロードが小さくなるため、フラグメント（パケットの分割）が発生し、スループットが低下する。また、ＴＣＰパケットでは、フラグメントが禁止であるため、エンドエンドで、ＩＰｓｅｃの通過する環境を把握し、フラグメントが発生しない最大セグメントサイズを設定する必要がある。これに対し、ＳＳＬは、通過する環境を把握する必要がないため、最大セグメントサイズを設定する必要はない。
【００１３】
本発明は、上述のような問題に鑑みてなされたものであり、コンピュータ端末への不正侵入を防ぐための「暗号化の機能」をアプリケーション・プログラムそれぞれに実装する必要がなく、したがって、アプリケーション・プログラム自体を再作成する必要もなく、かつ上記暗号化機能に対応していない通信相手とも従来の平文による通信でき、さらにはＩＰｓｅｃが利用できない環境（あるいは利用したくない状況）でも暗号化や認証の恩恵を受けることができる通信システム、特にプロトコルスタック、並びに関連する通信装置、通信方法、及びこれらを実現するための通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決し、本発明の目的を達成するため、本発明の暗号化通信システムは、トランスポート層に位置するＴＣＰ又はＵＤＰプロトコルに暗号化機能を追加して複数のホスト間で通信を行う暗号化通信システムであって、通信相手との接続を行うための接続シーケンス手段と、ＴＣＰ２固有情報を交換して通信相手が正当な権限を有する通信相手であるかどうかを判断し、暗号化通信に必要な鍵交換を行うためのＴＣＰｓｅｃ接続シーケンス手段と、通信路の両端で対応する暗号化及び復号化ロジックを取り決める取決め手段と、この取決め手段により取り決めた暗号化ロジックに従って、複数のホスト間で送受信する情報のパケットを暗号化して送信するプロトコル暗号化手段と、取決め手段により取り決めた復号化ロジックに従って複数のホスト間で送受信する情報のパケットを復号化するプロトコル復号化手段と、を備え、前記接続シーケンス手段は、一切のイレギュラーパターンを排除するネットワーク環境にも対応できるように、第１のホストから第２のホストへの接続要求と、第２のホストから第１のホストへの接続応答と、第１のホストから第２のホストに肯定応答を送信するという標準の接続を行い、ＴＣＰｓｅｃ接続シーケンス手段は、相手方ホストとＴＣＰ２固有情報の交換を行うことにより、相手方ホストが前記暗号化通信を行う権限を有することを確認し、暗号化通信に必要な鍵交換を行い、取決め手段は、接続シーケンス手段が正当な権限を有すると判断して接続した通信相手とのみ前記トランスポート層の前記ＴＣＰ又はＵＤＰプロトコルを用いて前記暗号化及び復号化ロジックに基づいた通信を行い、プロトコル暗号化手段は、送受信される情報のパケットのうち前記ＴＣＰ又はＵＤＰプロトコルのペイロードを暗号化して送信し、プロトコル復号化手段は、送受信される情報のパケットのうち前記暗号化されたプロトコルのペイロードを復号化することを特徴とする暗号化通信システムである。
【発明を実施するための最良の形態】
【００１５】
以下、図１〜図２４を参照しながら本発明の実施の形態の例を説明する。
図１は、本発明の暗号化通信システムの一実施の形態に用いられるプロトコルスタックを示すものである。
【００１６】
本発明に用いられるプロトコルスタックは、図１に示すように、ＯＳＩ７階層の物理層（第１層）とデータリンク層（第２層）に相当する階層に、ＮＩＣ（Network Interface Card）のDriver１１が配列される。このドライバは、既に述べたように、コンピュータなどのハードウエアをネットワークに接続するためのインターフェースカードのドライバであり、その内容はデータ送受信制御ソフトウエアである。例えばEthernetに接続するためのＬＡＮボードまたはＬＡＮカードがこれに相当するものである。
【００１７】
第３層のネットワーク層には、一部がトランスポート層（第４層）まで伸びたＩＰエミュレータ（emulator）３が存在している。上記延びた部分には、トランスポートとしての機能は実装していない。セッション層に、ネットワーク層の機能を提供しているだけある。このＩＰエミュレータ３は、暗号化通信を行うプロトコルである「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂと、「ＩＰ ｏｎ ＣＰ」１３ａを用途に応じて切り換えて使う働きをするものである。ここで、「ｏｎ ＣＰ」とは、クラッキング・プロテクタ（ＣＰ）による、「進入」「攻撃」の監視、破棄、切断ないし通過制限の対象となっていること、又は、設定によりなりうることを示している。
【００１８】
また、ネットワーク層にはＡＲＰ ｏｎ ＣＰ（Address Resolution Protocol on Cracking Protector）が配列されている。このＡＲＰ ｏｎ ＣＰは、クラッカー（Cracker）への保護対策を具備したＩＰアドレスからEthernetの物理アドレスであるＭＡＣ（Media Access Control）アドレスを求めるのに使われるプロトコルである。ＭＡＣは、媒体アクセス制御と呼ばれる、ＬＡＮなどで利用される伝送制御技術であり、データの送受信単位であるフレームの送受信方法やフレームの形式、誤り訂正などを規定する技術として利用されている。
【００１９】
ここで、ＩＰエミュレータ１３は、本発明による各種のセキュリティ機能を、従来のＩＰ周辺のスタックに整合させるためのソフトウエア又はファームウエアである。すなわち、ＩＰのエラーメッセージや制御メッセージを転送するプロトコルであるＩＣＭＰ（Internet Control Message Protocol）１４ａ、同一のデータを複数のホストに効率よく配送するための又は配送を受けるために構成されるホストのグループを制御するためのプロトコルであるＩＧＭＰ（Internet Group Management Protocol）１４ｂ、ＴＣＰ１５、ＵＤＰ１６さらにソケット（Socket）インターフェース１７に整合させるためのソフトウエア、又はファームウエア、ないしはハードウエア（電子回路、電子部品）である。このＩＰエミュレータ１３により、ＩＰｓｅｃの暗号化・復号化及び必要な認証情報付加・認証等の前後の適合処理を行うことができる。
【００２０】
このＩＰエミュレータ１３の上層のトランスポート層（第４層）には、ＴＣＰエミュレータ１５とＵＤＰエミュレータ１６が配置されている。ＴＣＰエミュレータ１５は、暗号化通信を行うプロトコルである「ＴＣＰｓｅｃ ｏｎ ＣＰ」１５ｂと、通常の通信プロトコルである「ＴＣＰ ｏｎ ＣＰ」１５ａを用途に応じて切り換えて使う働きをする。同様に、ＵＤＰエミュレータ１６は、暗号化通信を行うプロトコルである「ＵＤＰｓｅｃ ｏｎ ＣＰ」１６ｂと、通常の通信プロトコルである「ＵＤＰ ｏｎ ＣＰ」１６ａを用途に応じて切り換えて使う働きをする。
【００２１】
本発明の最も特徴とするべき点は、このトランスポート層（第４層）に、ＴＣＰｓｅｃ１５ｂと、ＵＤＰｓｅｃ１６ｂの暗号化通信プロトコルを搭載したことである。ＴＣＰｓｅｃ１５ｂとＵＤＰｓｅｃ１６ｂについては後述する。
このトランスポート層（第４層）の上層のセッション層（第５層）には、ＴＣＰ及びＵＤＰ等のプロトコルとデータのやりとりを行うソケット（socket）インターフェース１７が設けられている。このソケットの意味は、既に述べたようにコンピュータが持つネットワーク内の住所に当たるＩＰアドレスと、ＩＰアドレスのサブアドレスであるポート番号を組み合わせたネットワークアドレスを意味しており、実際には、一連のヘッダの追加ないし削除をまとめて行う、単一のソフトウエアプログラムモジュール（実行プログラム等）あるいは単一のハードウエアモジュール（電子回路、電子部品等）からなっている。
【００２２】
このソケットインターフェース１７は、さらに上位のアプリケーション（図２で示すＥＣアプリケーション及び図３で示す放送アプリケーション等）からの統一的なアクセス方式を提供するものであり、引数の種類や型など従来と同様のインターフェースを保つようにしている。
ＴＣＰエミュレータ１５は、トランスポート層において、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つＴＣＰｓｅｃ１５ｂと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルＴＣＰ１５ａのいずれかにパケットを振り分ける働きをもっている。また、ＴＣＰｓｅｃ１５ｂ及びＴＣＰ１５ａのいずれもクラッキング・プロテクタ（ＣＰ）を備えているため、そのいずれを選択した場合でも、クラッカーによる「進入」「攻撃」に対して防御する機能を実現することができる。ＴＣＰエミュレータ１５は上位層であるソケットとのインターフェースの役割も果たしている。
【００２３】
また、既に述べたようにＴＣＰがエラー補償機能を有するのに対して、ＵＤＰはエラー補償機能を持たないが、その分転送速度が速く、かつブロードキャスト機能を備えているという特徴がある。ＵＤＰエミュレータ１６は、ＴＣＰエミュレータ１５と同様に、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つＵＤＰｓｅｃ１６ｂと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルＵＤＰ１６ａのいずれかにパケットを振り分ける働きを持っている。
【００２４】
図１に示すように、ソケット１７、ＴＣＰエミュレータ１５、ＵＤＰエミュレータ１６、「ＴＣＰｓｅｃ ｏｎ ＣＰ」１５ｂ、「ＵＤＰｓｅｃ ｏｎ ＣＰ」１６ｂ、「ＴＣＰ ｏｎ ＣＰ」１５ａ、「ＵＤＰ ｏｎ ＣＰ」１６ａ、「ＩＣＭＰ ｏｎ ＣＰ」１４ａ、「ＩＧＭＰ ｏｎ ＣＰ」１４ｂ、ＩＰエミュレータ１３、「ＩＰ ｏｎ ＣＰ」１３ａ、及び「ＡＲＰｏｎＣＰ」１２からなるプロトコルスタックが本発明の暗号化処理を行うためのプロトコルスタックであり、以下、このプロトコルスタックを総称してＴＣＰ２（登録商標出願中）と呼ぶことにする。なお、ＴＣＰ２には「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂは必須のものとして含まれていないが、「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂを含めてＴＣＰ２とすることもできる。
【００２５】
本発明のＴＣＰ２は、ＴＣＰ、ＵＤＰ、ＩＰ、ＩＰｓｅｃ、ＩＣＭＰ、ＩＧＭＰ、ＡＲＰの標準プロトコルにＣＰ（クラッキング・プロテクト）を実装し、各プロトコルスタックに対する通信からの攻撃、及び、アプリケーション・プログラムからの攻撃（トロイの木馬、プログラムの改竄、正規ユーザの不正使用）を防御することができる。また、ＴＣＰ２では、ＴＣＰエミュレータ１５を実装し、このＴＣＰエミュレータ１５は、セッション層にあるソケット（Socket）１７、及びネットワーク層にあるＩＰエミュレータ１３から見て、互換性を保つため、外向きには標準ＴＣＰと同じに見せることができる。実際は、ＴＣＰ２の機能として、ＴＣＰとＴＣＰｓｅｃを切り替えて実行する。ＴＣＰｓｅｃは、本発明であるトランスポート層での暗号化及び認証機能である。
【００２６】
また、同様に、ＴＣＰ２では、ＵＤＰエミュレータ１６を実装しており、ＵＤＰエミュレータ１６は、セッション層であるソケット（Socket）１７、及び、ネットワーク層であるＩＰエミュレータ１３から見て、互換性を保つため、外部からは標準ＵＤＰとして見せることができる。実際は、ＴＣＰ２の機能として、ＵＤＰ、ＵＤＰｓｅｃを切り替えて実行する。ＵＤＰｓｅｃは、本発明であるトランスポート層での暗号化及び認証機能である。
【００２７】
次に、ＴＣＰ２において、特に重要な機能である「データ漏洩」を防ぐ機能であるＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂについて説明する。
ＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂのための暗号化・復号化の方法（アルゴリズム、ロジック（論理））としては、公知の秘密鍵（共通鍵）暗号アルゴリズムが用いられる。例えば、１９６０年代にＩＢＭ社によって開発された秘密鍵暗号アルゴリズムであるＤＥＳ（Data Encryption Standard）や、その改良版としての３ＤＥＳが用いられる。また、その他の暗号アルゴリズムとしては、１９９２年にスイス工科大学のJames L.Massey氏とXuejia Lai氏によって発表されたＩＤＥＡ（International Data Encryption Algorithm）も用いられる。この暗号アルゴリズムは、データを６４ビットのブロックに区切って暗号化するもので暗号鍵の長さは１２８ビットである。秘密鍵暗号を効率よく解読する線形解読法や差分解読法に対しても十分な強度を持つように設計されている。
【００２８】
また、本発明に用いられるＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂの暗号方式として、ＦＥＡＬ（Fast data Encipherment Algorithm）、ＭＩＳＴＹ、ＡＥＳ（Advanced Encryption Standard）といった暗号方式も利用されるほか、また、独自に作成した秘密の暗号化・復号化アルゴリズムを利用することもできる。ここで、ＦＥＡＬは、日本電信電話株式会社（当時）が開発した暗号方式で、暗号化と復号化に同じ鍵をもちいる秘密鍵型の暗号方式である。このＦＥＡＬは、ＤＥＳに比べて高速に暗号化と復号化ができるという利点がある。
【００２９】
次に、同じく本発明に利用される暗号方式であるＭＩＳＴＹは、三菱電機株式会社が開発した秘密鍵型の暗号方式であり、ＩＤＥＡと同様にデータを６４ビットのブロックに区切って暗号化する。鍵の長さは１２８ビットである。暗号化と復号化には同じプログラムが使われる点はＤＥＳなどと同じである。この方式も秘密鍵暗号を効率よく解読する線形解読法や差分解読法に対しても十分な強度を持つように設計されている。
【００３０】
また、ＡＥＳは、米国商務省標準技術局によって選定作業が行われている、米国政府の次世代標準暗号化方式であり、現在の標準的な暗号方式であるＤＥＳに代わる次世代の暗号標準として開発が進められたものである。世界に公募して集められて幾つかの暗号方式の中から、２０００年１０月に、ベルギーの暗号開発者Joan Daemen氏とVincent Rijmen氏が開発したRijndaelという方式が採用された。
【００３１】
このように、本発明のＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂの暗号方式としては、既に知られているさまざまな秘密鍵の暗号アルゴリズムを採用することができるほか、ユーザが独自に開発した秘密鍵（共通鍵）暗号方式も利用することが可能である。
【００３２】
さらに、いわゆる「なりすまし」及び「データの改竄」などを防ぐための「相手認証」及び「完全性認証」の方法として、公開鍵や事前秘密共有（Pre-shared）を利用したアルゴリズム、例えば、ＭＤ５（Message Digest ５）、ＳＨＡ１（Secure Hash Algorithm １）などの認証アルゴリズムが用いられる。また、このような公知の認証アルゴリズムに代えて独自の一方向関数を利用したアルゴリズムを採用することもできる。
【００３３】
このＭＤ５は、認証やデジタル署名に用いられるハッシュ関数（一方向要約関数）の一つであり、原文を元に固定長のハッシュ値を発生し、これを通信経路の両端で比較することにより、通信途中で原文が改竄されていないかを検出することができるものである。このハッシュ値は擬似的な乱数のような値をとり、これを基にしては原文を再生できないようになっている。また、同じハッシュ値を生成する別のメッセージを作成することも困難になっている。
【００３４】
ＳＨＡ１も、認証やデジタル署名などに使われるハッシュ関数の一つであり、２の６４乗ビット以下の原文から１６０ビットのハッシュ値を生成し、通信経路の両端で比較することにより、通信途上の原文の改竄を検出するものである。この認証アルゴリズムは従来のインターネットの暗号化通信の代表的なものであるＩＰｓｅｃにも採用されている。
【００３５】
なお、これらの認証アルゴリズムについては、ＤＨ（Diffie-Hellman）公開鍵配送法や、ＩＰｓｅｃと同様のＩＫＥ（Internet Key Exchange）プロトコル（ＵＤＰの５００番）などにより安全な鍵交換ができるように設計され、しかも、定期的に暗号化／完全性認証アルゴリズム（論理）自体やそのための鍵の集合／定義域が変更されるように、プロトコルドライバープログラム（ＴＣＰｓｅｃ１５ｂ、ＵＤＰｓｅｃ１６ｂなど）によりスケジュールされている。
【００３６】
次に、図２に基づいて、本発明の第１の実施の形態である暗号化方式ＴＣＰ２（特に、ＴＣＰｓｅｃ）を用いた暗号化通信について説明する。図２は、特に、ＥＣ（Electronic Commerce：電子商取引）アプリケーションに応用した通信に適用する例である。
【００３７】
図２は、ネットワーク２０に接続されたＥＣアプリケーション用のクライアント端末３ａ、３ｂ、３ｃが、いわゆるルータ又はゲートウエイのようなネットワーク制御機器２を介して他のネットワーク３０に接続されたホストコンピュータ（いわゆるサーバとして機能する通信装置）に接続された場合の全体構成を示す図である。
【００３８】
ネットワーク２０に接続されるクライアント端末３ａ、クライアント端末３ｂ及びクライアント端末３ｃのうち、クライアント端末３ｂと３ｃは、本発明のＴＣＰ２を実装していない。つまりクライアント端末３ｂと３ｃには、本発明の暗号化方式のためのプロトコルであるＴＣＰｓｅｃもＵＤＰｓｅｃも実装されていない。ＴＣＰ２をサポートしているクライアント端末は３ａのみである。そして、クライアント端末３ｂについては、不図示のネットワークポリシー設定により通常のプロトコル処理による接続、すなわち、ＴＣＰレベルについては、「データ漏洩」を防ぐ暗号化機能、「データ改竄」を防ぐ完全性認証機能、及び「なりすまし」を防ぐ相手認証機能は伴わない接続を行うようにしている。
【００３９】
何れのクライアント端末３ａ〜３ｃにおいても、ソケット（socket）の上層には、ＥＣ用のアプリケーションソフトウエアが実装されている。また、ネットワーク３０に接続されたホストコンピュータ１は、ＴＣＰ２を搭載しており、そのソケット１７の上層にＥＣアプリケーションソフトウエア１８が実装されている。図２ではＵＤＰｓｅｃなどの不使用のプロトコルを省略しているが、このホストコンピュータ１のプロトコルスタックの構造は図１のプロトコルスタックの構造であるＴＣＰ２を構成するソフトウエアは全て搭載されている。
【００４０】
すなわち、まず第１層（物理層）と第２層（データリンク層）にまたがってＮＩＣドライバ（NIC Driver）１１が配置され、その上層（第３層）のネットワーク層にはＡＲＰ（Address Resolution Protocol）１２とＩＰエミュレータ１３が配置されている。そして、第４層のトランスポート層にＴＣＰエミュレータ１５とＵＤＰ１６が配置される。図２にＵＤＰエミュレータ（ＵＤＰｓｅｃとＵＤＰを含む）の記載がないのは、第１の実施形態のＥＣアプリケーションに対する暗号化通信としては速度よりも誤り補償に重点をおくＴＣＰｓｅｃが使用されるからである。このことは、ホストコンピュータがＵＤＰｓｅｃを搭載していないことを意味するものではない。ＴＣＰ２を搭載することは、既に説明したようにＵＤＰｓｅｃとＴＣＰｓｅｃの両方を搭載していることを意味している。
【００４１】
ネットワーク２０に接続されたクライアント端末３ａ、３ｂ、３ｃとネットワーク３０に接続されるホストコンピュータ１を介在するネットワーク制御機器２のプロトコルスタックは、ＮＩＣドライバ、ＡＲＰ、ＩＰがスタックとして積み上げられたファームウエア（不揮発メモリ付電子回路）により構成されている。
また、クライアント端末３ａは、本発明のＴＣＰ２をサポートする端末であるが、ここではＴＣＰｓｅｃにのみ対応した通信装置を備えた端末としてプロトコルスタックが示されている。クライアント端末３ｂと３ｃは本発明のＴＣＰ２をサポートしていない。
【００４２】
クライアント端末３ａには、ネットワークを通して又はＣＤ−ＲＯＭのような記録媒体を介して事前に配布されるプロトコルドライバソフトウエアが実装されている。また、クライアント端末３ｂ、クライアント端末３ｃに対しても同様にプロトコルドライバソフトウエアが事前に配布され、実装される。
【００４３】
特に、クライアント端末３ｃについては、従来の暗号化方式であるＩＰｓｅｃを実装しているが、ネットワーク制御機器（ルータ）２がＴＣＰポート番号を参照したＩＰマスカレードを行っているためＩＰｓｅｃが有効に使えないようになっている。更にクライアント端末３ｃについては、不図示のネットワークポリシー設定により接続要求を破棄するようにしている。なお、このようなネットワークポリシーの設定ないしプロトコルを実装しているかどうかの確認（受信パケット解析等）自体については当業者に周知の事項であるのため、本明細書では説明を省略する。
【００４４】
ホストコンピュータ１がクライアント端末３ａと通信するときは、本発明のＴＣＰ２、特にＴＣＰｓｅｃに基づいた暗号化及び復号化取決めにより、通信を行うことになるが、ホストコンピュータ１がクライアント端末３ｂ又は３ｃと通信するときは、本発明のＴＣＰ２（特に、ＴＣＰｓｅｃ）による暗号化及び復号化の取決めがされない状態、つまり通常のＴＣＰプロトコルによる通信が行われることになる。もちろん、ホストコンピュータ１がＩＰｓｅｃをサポートしているクライアント端末３ｃと通信する場合には、ＩＰｓｅｃによる暗号化通信をすることができることは当然である。なお、ホストコンピュータ１が、ＴＣＰ２が搭載されていないクライアント端末３ｂ又は３ｃと通信しようとしてもホストコンピュータ１の有するＴＣＰ２の働きで、通信をストップさせることも可能である。
【００４５】
また、この実施の形態では、ネットワークを介してホストコンピュータ１とクライアント端末３ａとが暗号化及び復号化ロジックの交換を行うようにしているが、ＦＤやＣＤ、ＵＤＢメモリ等のリムーバブルメディアを用いて予め通信相手同士で暗号化及び復号化のための取決めロジックを交換しておくこともできることは言うまでもない。
【００４６】
次に、図３に基づいて、本発明の第２の実施形態であるＴＣＰ２の中のＵＤＰｓｅｃの暗号化方式を用いた暗号化通信について説明する。図３は、ネットワーク２０に接続された放送アプリケーション用のクライアント端末４ａ、４ｂ、４ｃが、いわゆるルータ又はゲートウエイのようなネットワーク制御機器２を介して別のネットワーク３０に接続されたホストコンピュータ（いわゆるサーバとして機能する通信装置）１と通信する通信システムの全体構成を示す図である。
【００４７】
図３は、クライアント端末４ａ、４ｂ、４ｃ及びホストコンピュータ１のプロトコルスタックを示しているが、ＴＣＰ２をサポートしているクライアント端末は４ａと４ｂである。つまり端末４ａと４ｂだけがＵＤＰｓｅｃを備えている。各クライアント端末のソケット（socket）の上層には、放送用のアプリケーションソフトウエアが実装されている。また、ネットワーク３０に接続されたホストコンピュータ１もＴＣＰ２を搭載しており、そのソケット１７の上層に放送アプリケーションソフトウエア１９が実装されている。図３のホストコンピュータ１も図２のホストコンピュータ１と同様に、図１のプロトコルスタックの構造であるＴＣＰ２を構成するソフトウエアは全て搭載している。
【００４８】
ホストコンピュータ１が保有するプロトコルスタックは、図２のホストコンピュータ１のプロトコルスタックと略同じであるが、図２のホストコンピュータ１のプロトコルスタックと異なる点は、ＴＣＰエミュレータの代わりにＵＤＰエミュレータ１６がある点である。これは放送アプリケーションソフトでは画像等の大量のデータが取り扱われるため、データ伝送のような誤り補償よりも、高速性が重視されるためである。
【００４９】
ネットワーク２０に接続されたクライアント端末４ａ、４ｂ、４ｃとネットワーク３０に接続されるホストコンピュータ１を介在するネットワーク制御機器２のプロトコルスタックは、ＮＩＣドライバ、ＡＲＰ、ＩＰがスタックとして積み上げられたファームウエア（不揮発メモリ付電子回路）により構成されている。
【００５０】
また、クライアント端末４ａは、本発明のＴＣＰ２をサポートする端末であるが、ここではＵＤＰｓｅｃにのみ対応した通信装置を備えた端末であり、クライアント端末４ｂは、本発明のＵＤＰｓｅｃ及び公知のＩＰｓｅｃに対応した通信装置であり、クライアント端末４ｃは公知のＩＰｓｅｃにのみ対応した通信装置である。このクライアント端末４ｃは本発明のＴＣＰ２をサポートしていない。これらのクライアント端末４ａ〜４ｃには、図２のクライアント端末３ａ〜３ｃと同様に、ネットワークを通して又はＣＤ−ＲＯＭのような記録媒体を介して事前に配布されるプロトコルドライバソフトウエアが実装されている。
【００５１】
また、特に「データ漏洩」防止のための暗号化・復号化ロジック及び「データ改竄」防止のための認証情報付加・認証ロジックについては、ホストコンピュータ１とクライアント端末４ａ、４ｂ、４ｃの間で対応している必要がある。公知のいわゆるＩＰｓｅｃと同様のポリシーで取決めを行うこともできるが、本発明の第２の実施形態においては、事前にプロトコルドライバソフトウエア自体を配布しているので、より簡潔な独自のプロトコルにより秘密鍵等を取り決めたり、より簡易な構造のパケットを使用したりすることもできる。また、公知の暗号化・復号化及び認証アルゴリズムでなく、独自で作成した暗号化・復号化及び認証アルゴリズム（ロジック）自体をプロトコルドライバのソフトウエアモジュール等として組み込むこともできる。
【００５２】
なお、クライアント端末４ｃは、ＴＣＰ２を実装していないが、インターネットで利用される公知のＩＰｓｅｃを実装しているため、これによってある程度セキュアな通信をすることができる。しかし、クライアント４ａと４ｂは、対象とする放送アプリケーションのパフォーマンスないしセキュリティポリシーの都合上、ＩＰｓｅｃではなく本発明によるＴＣＰ２の構成要素であるＵＤＰｓｅｃを実装して使用している。ＩＰｓｅｃではなくＵＤＰｓｅｃを利用する理由は、例えば、ＵＤＰポート番号部分（ＩＰペイロードに属する）をＩＰｓｅｃで暗号化することによるパフォーマンスの低下など、ＩＰｓｅｃ自体に脆弱さがあるからである。
【００５３】
また、通信相手が正しいものかどうかを判断する相手認証プロトコルを、本発明のＴＣＰ２のＴＣＰ又はＵＤＰプロトコルスタック、つまりＴＣＰｓｅｃ又はＵＤＰｓｅｃに埋め込むことにより、通信相手相互間で上位アプリケーションを意識することなく、通信相手認証機能を実施することができる。この場合、コスト増にならない範囲で実質的に通信パケット数やパケット長等を増やすこともできる。
【００５４】
また、特に、ネットワーク内で不特定多数の相手に向かってデータを送信するブロードキャスト機能を実施するに際して、本発明による暗号化方式であるＵＤＰｓｅｃを利用する場合には、ブロードキャストを受けるクライアント端末３ａ、３ｂがネゴシエーション（取り決め）を開始し、通信相手認証や通信用秘密鍵を得る。そして、クライアント端末３ａや３ｂは、通信相手の認証を行って通信用の秘密鍵を取得するまでは、ホストコンピュータ１からのＵＤＰｓｅｃによる配信データを復号化することができない。
【００５５】
次に、図４に基づいて、本発明の第１及び第２の実施形態の通信で送受信されるパケット構造と、その暗号化範囲及び完全性認証の適用範囲について説明する。
図４（ａ）はＴＣＰｓｅｃ／ＩＰｓｅｃのパケット構造と各暗号化範囲と完全性認証の適応範囲を示し、図４（ｂ）（ｃ）はそれぞれＴＣＰｓｅｃ／ＩＰ、ＵＤＰｓｅｃ／ＩＰのパケット構造と各暗号化範囲及び完全性認証の適用範囲を示したものである。
【００５６】
図４（ａ）に示すように、ＴＣＰｓｅｃ／ＩＰｓｅｃのパケット構造は、ＩＰヘッダ４１のすぐ後に、ＩＰｓｅｃのＥＳＰヘッダ４２が続いている。続いてＴＣＰヘッダ４３とＴＣＰｓｅｃの付加情報４４が設けられ、その後にアプリケーションデータ４５が続く構造になっている。そして、アプリケーションデータ４５の後には、ブロック暗号で発生するデータのブランクやそのブランクの長さ、次のヘッダの番号などの暗号データをサポートする情報であるＴＣＰｓｅｃ付加トレーラ４６が配列され、その後にＴＣＰｓｅｃの付加認証データ４７が配列される。そして、さらにその後にＩＰのためのＥＳＰトレーラ４８とＥＳＰ認証データ４９が配列されるパケット構造になっている。
【００５７】
このうち番号４１、４２、４８、４９で示される部分はＩＰｓｅｃ用の情報であり、番号４３、４４、４６、４７が本発明によるＴＣＰ２の中心的な役割を果たすＴＣＰｓｅｃに関連する情報である。なお、ここではＴＣＰｓｅｃもＩＰｓｅｃに準じた配列としたが、採用する暗号化や認証のアルゴリズムによっては、ＴＣＰｓｅｃの付加情報４４と付加トレーラ４６を省略したり、ＴＣＰｓｅｃの付加認証データ４７を削減したりしても利用可能である。
【００５８】
図４（ａ）に示すＴＣＰ２のパケット構造においては、ＴＣＰｓｅｃとＩＰｓｅｃの二つの方式で暗号化が行われる。この場合、まず送信側では、ＴＣＰｓｅｃ側を最初に暗号化して、ＴＣＰｓｅｃ認証データを付加する。次に、ＩＰｓｅｃを暗号化し、ＩＰｓｅｃ認証データを付加している。そして、受信側では、まず、ＩＰｓｅｃを復号化して、ＩＰｓｅｃ認証データにより受信パケットのデータを検証し、続いてＴＣＰｓｅｃ側を復号化して、ＴＣＰｓｅｃ認証データで受信パケットのデータを検証する。
【００５９】
このように、図４（ａ）に示すようなパケット構造を有するデータでは、ＩＰｓｅｃとＴＣＰｓｅｃの二種類の暗号アルゴリズムを用いて暗号化し、さらに完全性認証を行うので、ＩＰｓｅｃのみと比べて外部からの侵入等にたいして格段に強固な暗号化通信システムを確立することができる。ＴＣＰｓｅｃにより暗号化される範囲は、アプリケーションデータ４５、ＴＣＰｓｅｃ付加トレーラ４６の部分であり、ＴＣＰｓｅｃによる認証範囲としては上記暗号化範囲にさらにＴＣＰｓｅｃ付加情報４４が加えられる。なお、従来のＩＰｓｅｃで暗号化される暗号化範囲は、ＴＣＰヘッダ４３からＥＳＰトレーラ４８までの部分であり、その認証範囲は、ＥＳＰヘッダ４２からＥＳＰトレーラ４８までの範囲となる。
【００６０】
図４（ｂ）は、ＴＣＰｓｅｃ／ＩＰのパケット構造を示しており、図４（ａ）と異なり、ＩＰヘッダ４１のすぐ後に、ＴＣＰヘッダ４３及びＴＣＰｓｅｃ付加情報４４が続き、更にアプリケーションデータ４５が続く構造になっている。そして、アプリケーションデータ４５の後には、ブロック暗号で発生するデータのブランクやそのブランクの長さ、次のヘッダの番号などの暗号データをサポートする情報であるＴＣＰｓｅｃの付加トレーラ４６とＴＣＰｓｅｃの付加認証データ４７が配列される構造となっている。
【００６１】
ここで、番号４３、４４、４６、４７がＴＣＰｓｅｃに特徴的な情報となる。ただし、上述したようにこれらの情報は、採用する暗号化／認証アルゴリズムによっては、ＴＣＰｓｅｃ／ＩＰの使用していないヘッダフィールド部分などに分散したり、個々のパケットからは逆算・推測できない独立した事前取決め（ネゴシエーション）により省略したりできるものである。また、ＩＰ層の上層に当たるＴＣＰ及びＩＰを使用していないプロトコルフィールドを用いて、図４（ｂ）に示すようなＴＣＰｓｅｃ／ＩＰパケットを構成することにより、より下層のＩＰのみに着目したＩＰｓｅｃパケットよりもパケット長を簡単に削減することができるようになる。なお、ここで暗号化範囲は、図示の通り、アプリケーションデータ４５、ＴＣＰｓｅｃ付加トレーラ４６であり、認証範囲は上記暗号化範囲の他に、ＴＣＰｓｅｃの付加情報４４が加えられる。
【００６２】
図４（ｃ）は、本発明におけるＵＤＰｓｅｃ／ＩＰのパケット構造を示すものであり、ＵＤＰｓｅｃ付加情報４４ａ、ＵＤＰｓｅｃ付加トレーラ４６ａ及びＵＤＰｓｅｃ付加認証データ４７ａがＵＤＰｓｅｃをサポートするために必要な情報となる。この暗号化範囲は、図示の通り、アプリケーションデータ４５ａ、ＵＤＰｓｅｃ付加トレーラ４６ａであり、認証範囲は上記暗号化範囲の他に、ＵＤＰｓｅｃ付加情報４４ａが加えられる。
【００６３】
次に、本発明の第１の実施の形態であるＴＣＰｓｅｃを用いた暗号化処理システムの動作を図５〜図６、図８〜図１４に示す流れ図、及び図７に示すシーケンス図に基づいて説明する。
【００６４】
図５は、ＴＣＰ、並びに、ＴＣＰｓｅｃのパッシブオープン（図７のホストＢに相当する接続待ちのオープンであり、例えば、Ｗｅｂサーバが、この状態でオープンする。）における処理の流れ図であり、上位アプリケーション・プログラムで、接続待ちオープンした場合に、このＴＣＰ／ＴＣＰｓｅｃパッシブオープン処理がスタートする（ステップＳ１）。なお、この部分は、図７でいうとホストＢ側の処理がこれに相当する。
【００６５】
まず、最初に、オープンするポート番号の解析が行われる（ステップＳ２）。この解析では、例えば、Ｗｅｂサーバの場合は、ＴＣＰポートの８０番を使用して、その定義状態を確認する。そして次にこのポート番号８０が、ＴＣＰｓｅｃのパッシブオープンが許可されているかどうかを判定する（ステップＳ３）。ステップＳ３においてＴＣＰｓｅｃのパッシブオープンが許可されていない場合は、今度はＴＣＰパッシブオープンが許可されているかどうかが判断される（ステップＳ４）。判断ステップＳ４でＴＣＰパッシブオープンも許可されていない場合は、ＴＣＰｓｅｃもＴＣＰも許可されていないことになり、ＴＣＰ／ＴＣＰｓｅｃパッシブオープンは失敗となり、処理を中断する（ステップＳ７）。
【００６６】
判断ステップＳ４でＴＣＰパッシブオープンが許可されている場合、すなわちＴＣＰｓｅｃパッシブオープンは許可されていないがＴＣＰパッシブオープンは許可されているときは、後述する図８に示すＴＣＰパッシブオープン処理が実行される（ステップＳ５）。
判断ステップＳ３で、ＴＣＰｓｅｃのパッシブオープンの許可状態が確認された場合は、同じく後述する図９に示すＴＣＰｓｅｃのパッシブオープン処理が実行される（ステップＳ６）。
【００６７】
ステップＳ５又はステップＳ６におけるＴＣＰパッシブオープン処理又はＴＣＰｓｅｃのパッシブオープン処理が終了するとＴＣＰ／ＴＣＰｓｅｃパッシブオープン処理を終了する（ステップＳ７）。このように、本例では、上位であるアプリケーションからは、ＴＣＰでパッシブオープンを行っているが、ＴＣＰ２の判断により、ＴＣＰｓｅｃがサポートされていればＴＣＰｓｅｃで通信を行い、ＴＣＰｓｅｃがサポートされていなければＴＣＰで通信することとなる。
【００６８】
次に、図６に基づいて本発明のＴＣＰ並びにＴＣＰｓｅｃのアクティブオープン処理について説明する。ＴＣＰ／ＴＣＰｓｅｃのアクティブオープンとは、接続要求のオープンであり、例えば、Ｗｅｂブラウザを実装するクライアント端末が、この状態でオープンすることになる。図７でいうとホストＡ側の処理がこれに相当する。図６は、このアクティブオープンにおける処理の流れ図であり、上位アプリケーション・プログラムにおいて接続要求オープンがなされた場合に、このＴＣＰ／ＴＣＰｓｅｃのアクティブオープン処理が開始される（ステップＳ８）。
【００６９】
まず、最初に、オープンするポート番号の解析がなされる（ステップＳ９）。この解析は、例えば、Ｗｅｂブラウザを実装するクライアント端末アプリケーションが、ＴＣＰポートの３０００番を使おうとした場合は、ＴＣＰポートの３０００番の定義状態を確認する。
【００７０】
次にこのポート番号３０００に対してＴＣＰｓｅｃのアクティブオープンが許可されているかどうかが判断される（ステップＳ１０）。ステップＳ１０においてＴＣＰｓｅｃのアクティブオープンが許可されていないと判定された場合は、続いてＴＣＰアクティブオープンが許可されているかどうかが判断される（ステップＳ１１）。判断ステップＳ１１でＴＣＰアクティブオープンも許可されていない場合は、ＴＣＰｓｅｃ、ＴＣＰのいずれのアクティブオープンも許可されていないことになり、ＴＣＰ／ＴＣＰｓｅｃアクティブは失敗となり、接続処理は中断される（ステップＳ１４）。
【００７１】
判断ステップＳ１１でＴＣＰアクティブオープンが許可されている場合、すなわちＴＣＰｓｅｃアクティブオープンは許可されていないがＴＣＰアクティブオープンは許可されているときは、後述する図１０に示すＴＣＰアクティブオープン処理が実行される（ステップＳ１２）。
【００７２】
判断ステップＳ１０で、ＴＣＰｓｅｃのアクティブオープンの許可状態が確認された場合は、後述する図１１に示すＴＣＰｓｅｃのアクティブオープン処理が実行される（ステップＳ１３）。ステップＳ１２又はステップＳ１３におけるＴＣＰｓｅｃアクティブオープン処理又はＴＣＰｓｅｃのアクティブオープン処理が終了するとＴＣＰ／ＴＣＰｓｅｃアクティブオープン処理が終わる（ステップＳ１４）。ＴＣＰ／ＴＣＰｓｅｃアクティブオープンの場合も、ＴＣＰ／ＴＣＰｓｅｃパッシブオープン（図５）の場合と同様に、上位であるアプリケーションからは、ＴＣＰでアクティブブオープンを行っているが、ＴＣＰ２の判断により、ＴＣＰｓｅｃがサポートされていればＴＣＰｓｅｃで通信を行い、ＴＣＰｓｅｃがサポートされていなければＴＣＰで通信することとなる。
【００７３】
次に、図７に基づいてアクティブオープン側のホストＡとパッシブオープン側のホストＢ間のシーケンス処理について、本発明のＴＣＰｓｅｃを使った通信の処理を説明する。
【００７４】
図７は、本発明の暗号処理プロトコルであるＴＣＰｓｅｃを用いたときの接続シーケンス、データ通信シーケンス及び切断シーケンスを、標準のＴＣＰと比較して示したものである。図７（ａ）は標準ＴＣＰ，図７（ｂ）は本発明のＴＣＰｓｅｃを用いた時の通信のシーケンスを示した図である。
図７（ａ）に示すように、標準のＴＣＰは、ホストＢのアプリケーションがＴＣＰパッシブオープンし、ホストＡのアプリケーションがＴＣＰアクティブオープンしている。
【００７５】
ホストＢのアプリケーションがＴＣＰパッシブオープンをすると、ＴＣＰパッシブオープン処理（図５のステップ５及び図８参照）を開始し、後述する図８のステップＳ１５に示すように受信待ちとなる。ホストＡのアプリケーションがＴＣＰアクティブオープンをすると、ＴＣＰアクティブオープン処理（図６のステップＳ１２及び図１０参照）を開始し、後述する図１０のステップＳ５２に示すようにホストＡからホストＢに対して接続要求（ＳＹＮ）が送信される。これにより、標準ＴＣＰの接続シーケンスが開始状態となる。
【００７６】
ホストＢ側では、この接続要求（ＳＹＮ）を受信するとこの接続要求の受信パケットの解析を終了し、ホストＡ側に接続応答（ＳＹＮ・ＡＣＫ）を送信する。ここでＡＣＫとは、Acknowledgementの略であり、データ転送が正常に終了したときなどに送信されるものである。ホストＡ側は、この接続応答（ＳＹＮ・ＡＣＫ）を受信すると、接続が完了した旨のＡＣＫ（肯定応答）を送信し、標準ＴＣＰの接続シーケンスを終了する。
【００７７】
この標準ＴＣＰの接続シーケンスを終了すると、標準ＴＣＰによるデータ通信シーケンスが有効となり、ホストＡ側、又は、ホストＢ側の何れかがデータを送信後、データを受信した側からＡＣＫ（肯定応答）を返すという基本パターンを繰り返してデータの送受信が行われる。
【００７８】
この標準ＴＣＰのデータ通信シーケンスでは、ホストＡ又はホストＢの何れかが、相手に対して切断要求をすることができる。
図７（ａ）では、アクティブオープン側のホストＡからパッシブオープン側のホストＢに対して切断要求が送信された場合を示している。ホストＡのアプリケーションから切断要求があると、ホストＡは、切断要求（ＦＩＮ）を送信する。ホストＢは、この切断要求（ＦＩＮ）を受信すると、後述する図８のステップＳ２３に示すように切断応答（ＦＩＮ・ＡＣＫ）を送信する。ホストＡは、この切断応答（ＦＩＮ・ＡＣＫ）を受信すると、ＡＣＫ（肯定応答）を送信し、標準ＴＣＰの切断シーケンスを終了する。
【００７９】
次に、本発明のＴＣＰｓｅｃによる通信のシーケンスを図７（ｂ）に基づいて説明する。図７（ｂ）では、ホストＢのアプリケーションがＴＣＰｓｅｃパッシブオープンし、ホストＡのアプリケーションがＴＣＰｓｅｃアクティブオープンしている。
ホストＢのアプリケーションがＴＣＰｓｅｃパッシブオープンをすると、ＴＣＰｓｅｃパッシブオープン処理（図５のステップＳ６及び図９を参照）を開始し、後述する図９のステップＳ３１に示すように受信待ちとなる。ホストＡのアプリケーションがＴＣＰｓｅｃアクティブオープンをすると、ＴＣＰｓｅｃアクティブオープン処理（図６のステップＳ１３及び図１１を参照）を開始し、図１１のステップＳ７０に示すようにホストＡからホストＢに対して接続要求（ＳＹＮ）が送信される。これにより、ＴＣＰｓｅｃの接続シーケンスが開始状態となる。
【００８０】
ホストＢ側では、ホストＡから送信された接続要求（ＳＹＮ）を受信すると、この接続要求の受信パケットの解析を終了し、ホストＡに対して接続応答（ＳＹＮ・ＡＣＫ）を送信する。そして、ホストＡ側は、このホストＢからの接続応答（ＳＹＮ・ＡＣＫ）を受信するとＡＣＫ（肯定応答）を送信し、ＴＣＰｓｅｃの接続シーケンスを終了する。
【００８１】
この接続シーケンスが終了すると、ＴＣＰｓｅｃ接続シーケンスが有効となり、ホストＡとホストＢの間で、ＴＣＰｓｅｃネゴシエーションデータに含まれているＴＣＰ２の固有情報を交換し、正しい相手であることを相手に通知する。すなわち、ホストＡとホストＢの間で、次のＴＣＰｓｅｃネゴシエーションデータを交換する以前に相手方端末がＴＣＰ２をサポートする端末であるか、言い換えると通信する正しい相手であるか否かを確認することができる。続いて、ホストＡとホストＢの間でＴＣＰｓｅｃネゴシエーションデータを交換し、ＴＣＰｓｅｃ接続シーケンスを終了する。
【００８２】
このＴＣＰｓｅｃのＴＣＰｓｅｃ接続シーケンスが終了すると、ＴＣＰｓｅｃのデータ通信シーケンスが有効となり、ホストＡ側又はホストＢ側の何れかがデータを送信後、データを受信した側からＡＣＫ（肯定応答）を返す基本パターンを繰り返してデータの送受信が行われる。なお、このデータは、すべて暗号データであることは言うまでもない。
【００８３】
なお、ＴＣＰｓｅｃのデータ通信シーケンスでは、ホストＡ又はホストＢの何れかが相手方に対して切断要求をすることができる。図７（ｂ）では、アクティブオープン側のホストＡから切断を開始している。ホストＡのアプリケーションから切断要求があると、ホストＡは切断要求（ＦＩＮ）を送信する。ホストＢは、この切断要求（ＦＩＮ）を受信すると、後述する図９のステップＳ４２に示すように切断応答（ＦＩＮ・ＡＣＫ）を送信する。ホストＡは、この切断応答（ＦＩＮ・ＡＣＫ）を受信すると、ＡＣＫ（肯定応答）を送信し、ＴＣＰｓｅｃの切断シーケンスを終了する。
【００８４】
以上、図７に基づいて、標準ＴＣＰと本発明のＴＣＰ２のひとつであるＴＣＰｓｅｃについて通信の接続から切断までのシーケンスを説明したが、以下、ＴＣＰ及びＴＣＰｓｅｃのパッシブオープン処理、及びアクティブオープン処理について流れ図に従って順に説明する。
【００８５】
まず、図５の流れ図のステップＳ５において、ＴＣＰパッシブオープン処理がスタートした場合の詳細について図８の流れ図に基づいて説明する。
図５のステップＳ５で処理するプロトコルがＴＣＰと決定した場合に、この図８のＴＣＰパッシブオープン処理がスタートする。最初に、受信待ちをして、受信した受信パケットの解析を行う（ステップＳ１５）。続いてこの受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンであるかどうかを判断する（ステップＳ１６）。そしてステップＳ１６の判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ１７）、次のパケットの受信を待つ。
【００８６】
判断ステップＳ１６において、受信パケットが正しいＴＣＰパケットであると判断された場合は、続いて接続中か否か、つまり図７のホストＡとホストＢの接続シーケンスが完了しているかどうかが判断される（ステップＳ１８）。判断ステップＳ１８において、接続中であると判定された場合は、次にパケットが切断要求（図７（ａ）のＦＩＮ）であるか否かが判断される（ステップＳ１９）。切断要求でなければ、続いて切断応答（図７（ａ）のＦＩＮ／ＡＣＫ）であるか否かが判断される（ステップＳ２０）。切断要求でもなく、切断応答でもない場合には、ＴＣＰデータの送受信処理が行われ（ステップＳ２１）、受信パケットが切断応答である場合は、図７のホストＡからＡＣＫが送信され、ＴＣＰ接続が切断される（ステップＳ２５）。判断ステップＳ１９でホストＡからの切断要求であると判断されると、これに対する切断応答がホストＢから送信される（ステップＳ２３）。
【００８７】
ステップＳ２３で切断応答が送信された場合には、最終のＡＣＫを待つ（ステップＳ２４）。そして、最終ＡＣＫを受信した後にＴＣＰを切断状態にして（ステップＳ２５）、ＴＣＰパッシブオープンを終了する（ステップＳ２６）。
判断ステップＳ１８において、受信ポートが接続中でないとされた場合には、受信したパケットがパッシブオープン許可ポートであるか否かが判定される（ステップＳ２７）。そして受信パケットが許可されていない場合は、受信パケットを廃棄して（ステップＳ２８）次のパケットを待つ。また、判断ステップＳ２７において、受信パケットがパッシブオープン許可になっているとされた場合は、次にパケットが接続要求であるか否かが判断され（ステップＳ２９）、接続要求でない場合は、パケットを廃棄して（ステップＳ２８）次のパケットを待つ。また、判断ステップＳ２９で接続要求であると判断された場合には、接続応答を送信し、ＴＣＰを接続状態とする（ステップＳ３０）。
【００８８】
次に、図５のＴＣＰｓｅｃのパッシブオープンにおける処理ステップＳ６の詳細について、図９の流れ図に基づいて説明する。この処理は、図５のステップＳ６に示されるように、受信パケットの処理がＴＣＰｓｅｃの処理であると決定された場合の処理である。最初に、受信待ちをして、受信した受信パケットの解析がなされる（ステップＳ３１）。続いてこの受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかが判断される（ステップＳ３２）。このステップＳ３２の判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ３３）、ステップＳ３１に戻り、次のパケットの受信を待つ。
【００８９】
判断ステップＳ３２において、受信パケットが正しいパケットであると判断された場合は、続いてホストＡとホストＢの接続が完了しているかどうか（接続中かどうか）が判断される（ステップＳ３４）。判断ステップＳ３４において、ホストＡとホストＢが接続中であると判定された場合は、次に受信したパケットが切断要求（ＦＩＮ）であるのか否かが判断される（ステップＳ３５）。切断要求でなければ、今度は受信したパケットが切断応答（ＦＩＮ・ＡＣＫ）であるか否かが判断される（ステップＳ３６）。そして、受信したパケットが切断要求でもなく、切断応答でもないということであれば、後述する図１２に示されるＴＣＰｓｅｃデータの送受信処理が行われ（ステップＳ３７）、ステップＳ４９に進む。次に、判断ステップＳ３６で切断応答があった場合には、ＡＣＫを送信して（ステップＳ３８）、ホストＡとホストＢ間のＴＣＰｓｅｃを切断する（ステップＳ４１）。また、判断ステップＳ３５において、受信パケットが切断要求（ＦＩＮ）であると判断された場合は、切断応答（ＦＩＮ・ＡＣＫ）の送信が行われる（ステップＳ３９）。ステップＳ３９で切断応答が送信された場合には、相手方からの最終のＡＣＫを待ち（ステップＳ４０）、この最終ＡＣＫを受信するとＴＣＰｓｅｃを切断状態にして（ステップＳ４１）、ＴＣＰｓｅｃパッシブオープンを終了する（ステップＳ４２）。
【００９０】
判断ステップＳ３４において、ホストＡとホストＢが接続中でないと判断された場合には、受信したパケットがパッシブオープンの許可ポートであるか否かが判断される（ステップＳ４３）。そして受信パケットがパッシブオープンの許可ポートではない場合は、受信パケットを廃棄して（ステップＳ４４）、ステップＳ３１に戻り次のパケットを待つ。また、判断ステップＳ４３おいて、受信パケットがパッシブオープン許可ポートになっているとされた場合は、後述する図１３に示すＴＣＰｓｅｃパッシブ接続処理が実行される（ステップＳ４５）。
【００９１】
続いて、共通鍵と認証データに基づいて通信相手が正常、つまり正当な権限を持った相手であるか否かが判断される（ステップＳ４６）。正常な相手であると判断されれば、ステップＳ３１に戻り、次の受信パケットを待つが、通信相手が正常の相手ではないと判断されると、ＴＣＰｓｅｃの接続を強制切断し（ステップＳ４７）、ＴＣＰｓｅｃのパッシブオープンの処理を終了する（ステップＳ４８）。
【００９２】
次に、図６のステップＳ１２に示す、ＴＣＰアクティブオープンの処理について図１０の流れ図に基づいて説明する。
図１０は、図６における処理するプロトコルがＴＣＰであると決定した場合の処理を示す図であり、最初に、送信側ホストＡから受信側ホストＢに対して接続要求（ＳＹＮ）が送信される（ステップＳ５０）。この接続要求に対して受信側ホストＢから接続応答（ＳＹＮ・ＡＣＫ）が送信されると、次に受信待ちをし、受信したパケットの解析が行われる（ステップＳ５１）。次に、この受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ５２）。このステップＳ５２における判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ５３）、ステップＳ５１に戻り、次のパケットの受信を待つ。
【００９３】
判断ステップＳ５２において、受信パケットが正しいパケットであると判断された場合は、続いて送信側（アクティブ側）ホストＡと受信側（パッシブ側）ホストＢが、接続中かどうかが判断される（ステップＳ５４）。この判断ステップＳ５４において、接続中であると判定された場合は、次に受信パケットが送信側ホストＡから受信側ホストＢに対しての切断要求であるか否かが判断される（ステップＳ５５）。これが切断要求でなければ、今度は受信側ホストＢから送信側ホストＡに対する切断応答（ＦＩＮ・ＡＣＫ）であるか否かが判断される（ステップＳ５６）。切断要求でもなく切断応答でもないということになれば、ＴＣＰデータの送受信処理が行われ（ステップＳ５７）、次の受信パケットを待つ。判断ステップＳ５６でホストＢからホストＡへの切断応答であると判断されると、ホストＡは切断を肯定するＡＣＫを送信し（ステップＳ５８）、ＴＣＰを切断する（ステップＳ６１）。
【００９４】
判断ステップＳ５５において、受信したパケットが切断要求である場合は、ホストＢからホストＡに対して切断応答が送信され（ステップＳ５９）、ホストＢはホストＡからの最終のＡＣＫの受信を待つ（ステップＳ６０）。そして、ホストＢがホストＡから最終ＡＣＫを受信した後にＴＣＰを切断状態にして（ステップＳ６１）、ＴＣＰアクティブオープンを終了する（ステップＳ６２）。
判断ステップＳ５４において、送信側ホストＡと受信側ホストＢが接続中でないとされた場合には、受信したパケットがアクティブオープン許可ポートであるか否かが判定される（ステップＳ６３）。そして受信パケットが許可されていない場合は、受信パケットを廃棄して（ステップＳ６４）次のパケットを待つ。また、判断ステップＳ６３において、受信パケットがアクティブオープン許可になっているとされた場合は、次に受信側ホストＢからの接続応答があったか否かが判断され（ステップＳ６５）、接続応答がなければ、パケットを廃棄して（ステップＳ６４）次のパケットを待ち、受信側ホストＢから接続応答がなされた場合には、ＴＣＰの接続状態として（ステップＳ６６）、ステップＳ５１に戻り、次の受信パケットを待つ。
【００９５】
次に、図６のステップＳ１３のＴＣＰｓｅｃアクティブオープンが開始された場合の詳細な処理について図１１の流れ図に基づいて説明する。
図１１の流れ図に示す処理は、図６のステップＳ１３で処理するプロトコルがＴＣＰｓｅｃであると決定した場合に開始されるものである。最初に、送信側ホストＡから受信側ホストＢに対して接続要求（ＳＹＮ）が送信される（ステップＳ７０）。これに対して、受信側ホストＢから接続応答（ＳＹＮ・ＡＣＫ）があってパケットの受信が開始され、受信したパケットの解析が行われる（ステップＳ７１）。
【００９６】
次に、受信パケットの解析の結果、受信したパケットが正しいＴＣＰのパケットであるか否か、すなわち、ＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないか否かが判断される（ステップＳ７２）。この結果、不正パケットであると判定された場合には、そのパケットを廃棄（ステップＳ７３）し、ステップＳ７１に戻り次のパケットを待つ。
【００９７】
判断ステップＳ７２において、受信したパケットが正しいＴＣＰパケットであると判定された場合は、次に送信側ホストＡと受信側ホストＢの接続が完了しているかどうか（接続中かどうか）が判断される（ステップＳ７４）。そしてホストＡとホストＢが接続中であれば、今度は受信したパケットが切断要求（ＦＩＮ）であるか否かが判断される（ステップＳ７５）。受信したパケットが切断要求ではないときは、次に受信側ホストＢから切断応答があるかどうかが判断される（ステップＳ７６）。切断要求もなく切断応答もない場合は、図１２に示すＴＣＰｓｅｃデータの送受信処理が行われ（ステップＳ７７）、その後ステップＳ８７に進む。
【００９８】
判断ステップＳ７６で切断応答があった場合には、送信側ホストＡから受信側ホストＢに対してＡＣＫを送信して（ステップＳ７８）、ホストＡとホストＢ間のＴＣＰｓｅｃを切断する（ステップＳ８１）。また、判断ステップＳ７５において、受信パケットが切断要求（ＦＩＮ）であると判断された場合は、切断応答（ＦＩＮ・ＡＣＫ）の送信が行われる（ステップＳ７９）。ステップＳ７９で切断応答が送信された場合には、相手方からの最終のＡＣＫを待ち（ステップＳ８０）、この最終ＡＣＫを受信するとＴＣＰｓｅｃを切断状態にして（ステップＳ８１）、ＴＣＰｓｅｃアクティブオープンを終了する（ステップＳ８２）。
【００９９】
判断ステップＳ７４において、送信側ホストＡと受信側ホストＢの接続が完了していない、つまり接続中でないとされた場合には、受信したパケットがアクティブオープン許可ポートであるか否かが判定される（ステップＳ８３）。そして受信されたパケットが許可されていない場合は、その受信パケットを廃棄して（ステップＳ８５）ステップＳ７１に戻り、次のパケットを待つ。また、判断ステップＳ８３において、受信パケットがアクティブオープン許可になっているとされた場合は、受信されるパケットが受信側ホストＢからの接続応答（ＳＹＮ・ＡＣＫ）のパケットであるか否かが判断され（ステップＳ８４）、接続応答のパケットでない場合は、パケットを廃棄して（ステップＳ８５）次のパケットを待ち、判断ステップＳ８４で接続応答のパケットであると判断された場合には、図１４でその詳細を示すＴＣＰｓｅｃアクティブ接続処理が行われる（ステップＳ８６）。
【０１００】
ステップＳ８６でＴＣＰｓｅｃのアクティブ接続処理がなされると、次に受信側のホストＢが正常な相手か否か、つまり接続を許可されている相手であるか否かが判断される（ステップＳ８７）。そして、接続が許されている相手であると判断されれば、ステップＳ７１に戻って次のパケットの受信を待ち、ステップＳ８７で接続が許可されていない相手であると判断されると、ＴＣＰｓｅｃによる送受信を強制的に切断して（ステップＳ８８）、ＴＣＰｓｅｃのアクティブオープンを終了する（ステップＳ８９）。
【０１０１】
次に、上述した図９ステップＳ３７及び図１１のステップＳ７６が選択された場合のＴＣＰｓｅｃデータの送受信処理の詳細について図１２の流れ図に基づいて説明する。
【０１０２】
まず、図９のステップＳ３７及び図１１のステップＳ７７でＴＣＰｓｅｃデータの送受信処理が開始すると、最初に、ホストＡの上位アプリケーションからの送信要求があるか否かが判断される（ステップＳ９０）。そして、ホストＡの上位アプリケーションから送信要求があった場合は、送信側ホストＡで送信データが暗号化され（ステップＳ９１）、それに認証データが付加されて（ステップＳ９２）、受信側ホストＢに暗号化され認証データが付加されたパケットが送信される（ステップＳ９３）。
【０１０３】
次に、受信側ホストＢで、受信データがあるか否かが判断され（ステップＳ９４）、受信データがある場合には、受信データの復号化が行われる（ステップＳ９５）。次に、この受信され復号化されたデータが正しいデータであるかどうかが判断される（ステップＳ９６）。この判断は、復号化したデータと受信された認証データとを確認することによって行われるが、復号データを確認した結果、正しいデータでないと判定された場合には、ＴＣＰ／ＴＣＰｓｅｃを強制的に切断する（ステップＳ９７）。この強制切断は、受信したデータを廃棄するとともに、送信側に切断要求をすることによって行われる。判断ステップＳ９６で、復号化したデータが正しいデータであると判定された場合には、受信データの取り込み、すなわち上位プロトコルスタックへのデータの配達が行われ（ステップＳ９８）、ＴＣＰｓｅｃのデータ送受信処理が完了する（ステップＳ９９）。
【０１０４】
次に、図９のステップＳ４５でＴＣＰｓｅｃパッシブ接続処理が開始された場合の詳細の処理を図１３の流れ図に基づいて説明する。
最初に、相手が正しい相手、つまり自コンピュータに接続する権限を持つコンピュータであるか否かを判断し（ステップＳ１００）、正しい相手でない場合にはＴＣＰｓｅｃの強制切断のための処理を実施する（ステップＳ１０１）。判断ステップＳ１００において接続相手が正しい相手であると判断されれば、受信側ホストＢから接続応答を送信する（ステップＳ１０２）。
【０１０５】
そして、接続応答を送信してきた相手の情報が自コンピュータ内にあるかどうかを確認する（ステップＳ１０３）。相手情報がコンピュータ内にない場合は、本システム、すなわちＴＣＰ２をインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１０４）。または、第三者認証のサーバから相手情報を取得してステップＳ１０５に進む。この取得する情報としては、相手側のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数を使用することができる。なお、サーバからの取得情報を既に自コンピュータが保有している場合であっても、有効期限若しくは有効使用回数を超えているような場合には、改めて取得動作を行う必要がある。
【０１０６】
次に、相手情報が正しい相手であるか否か、つまり、自分のコンピュータにアクセスすることを許容されている相手であるかどうかが判断される（ステップＳ１０５）。ここで、接続する相手が正しい相手であれば、ＴＣＰｓｅｃのパッシブ接続を完了する（ステップＳ１０６）が、正しい相手でない場合にはＴＣＰｓｅｃの強制切断を行って接続を中止する（ステップＳ１０１）。
【０１０７】
次に、図１１のステップＳ８６でＴＣＰｓｅｃのアクティブ接続処理が開始された場合の詳細の処理を図１４の流れ図に基づいて説明する。
図１３のパッシブ接続処理の場合と同様に、最初に、接続要求をしてきた相手が正しい相手であるどうか、つまり自コンピュータにアクセス権限を持っている相手からの通信であるかどうかを判断する（ステップＳ１１０）。正当なアクセス権限を持たない相手からの通信であれば、ＴＣＰｓｅｃのアクティブ接続を強制切断して終了する（ステップＳ１１１）。
【０１０８】
判断ステップＳ１１０で正しい相手であると判定されれば、送信側ホストから受信側ホストＢに対して肯定的な接続応答（ＡＣＫ）を送信する（ステップＳ１１２）。
次に、自コンピュータが相手側の情報を保有しているかどうかが判断される（ステップＳ１１３）。相手情報がコンピュータ内にない場合は、本システム、すなわちＴＣＰ２をインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１１４）。または、第三者認証のサーバから相手情報を取得してステップＳ１１５に進む。ここで、この取得する情報は、図１３ステップＳ１０４と同様に、相手側のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数とすることができる。なお、サーバからの取得情報を既に自コンピュータが保有していたとしても、有効期限若しくは有効使用回数を超えている場合には、改めて取得動作を行う必要がある。
【０１０９】
次に、相手情報が正しい相手であるか否か、つまり、自分のコンピュータにアクセスすることを許容されている相手であるかどうかが判断される（ステップＳ１１５）。接続する相手が正しい相手であれば、ＴＣＰｓｅｃのアクティブ接続を完了する（ステップＳ１１６）が、正しい相手でない場合にはＴＣＰｓｅｃの強制切断を行って接続を中止する（ステップＳ１１１）。
【０１１０】
以上、本発明のＴＣＰ２のうち、ＴＣＰ／ＴＣＰｓｅｃを用いたパッシブオープン及びアクティブオープンの通信処理について説明した。
次に、図３で示すような、本発明の第２の実施形態であるＵＤＰ／ＵＤＰｓｅｃを用いた通信システム及び通信方法について説明する。
【０１１１】
図１５は、本発明の第２の実施の形態に用いられるＵＤＰ／ＵＤＰｓｅｃのパッシブオープン処理について説明するための流れ図である。
この処理は、上位アプリケーション・プログラムにより開始される（ステップ１２０）。最初に、オープンするポート番号の解析、すなわちポート番号の定義状態が確認される（ステップ１２１）。次に、このポート番号がＵＤＰｓｅｃオープンになっているか否かが判断される（ステップＳ１２２）。ＵＤＰｓｅｃがオープンになっていない場合はＵＤＰがオープンになっているかどうかが判断される（ステップ１２３）。そして、ＵＤＰｓｅｃ、ＵＤＰが両方ともオープン許可になっていない場合は、ＵＤＰ／ＵＤＰｓｅｃは終了する（ステップＳ１２６）。判断ステップＳ１２３で、ＵＤＰがオープン許可になっている場合、つまりＵＤＰｓｅｃはオープン許可になっていないけれどもＵＤＰがオープン許可になっている場合は、図１８に示すＵＤＰオープン処理が実施される（ステップＳ１２４）また、判断ステップＳ１２２においてＵＤＰｓｅｃがオープンである場合は、ＵＤＰがオープンであるか否かにかかわらず、ＵＤＰｓｅｃのオープン処理が実施されて（ステップＳ１２５）、ＵＤＰ／ＵＤＰｓｅｃオープン処理は終了する（ステップＳ１２６）。なお、上位であるアプリケーションからは、ＵＤＰでオープンを行っていたとしても、ＴＣＰ２の判断により、ＵＤＰｓｅｃ若しくは、ＵＤＰで通信することも可能である。
【０１１２】
次に、本発明の第２実施の形態の１つであるＵＤＰ／ＵＤＰｓｅｃを用いたユニキャスト通信におけるシーケンス処理について図１６に基づいて説明する。
図１６は、標準のＵＤＰ、及び、本発明のＴＣＰ２の中のＵＤＰｓｅｃにおけるユニキャスト通信の開始シーケンス、データ通信シーケンスのパケット（ヘッダと、ペイロードで構成する）及び、その流れを説明した図である。
【０１１３】
図１６（ａ）が標準のＵＤＰを用いた通信シーケンスを示し、図１６（ｂ）は、ＵＤＰｓｅｃによる暗号化通信のシーケンスを示す。
図１６（ａ）の標準のＵＤＰは、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンしている例を示している。ホストＢのアプリケーションがＵＤＰオープンをすると、ＵＤＰオープン処理（図１５のステップＳ１２４及び図１８参照）を開始する。また、同様にホストＡのアプリケーションがＵＤＰオープンした場合も上記のＵＤＰオープン処理を開始する。これにより、ＵＤＰのデータ通信を行うことが可能となる。ここで図１６（ａ）に示すユニキャスト通信では、ホストＡ、ホストＢの何れからもデータの送信が可能である。
【０１１４】
次に、本発明のＴＣＰ２の暗号化方式の１つであるＵＤＰｓｅｃによる通信処理のシーケンスを説明する。
図１６（ｂ）は、本発明のＴＣＰ２が持つＵＤＰｓｅｃにより暗号化通信する場合の例であるが、この例は、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンし、ＴＣＰ２がＵＤＰｓｅｃでオープンと判断したケースである。
ホストＢがＵＤＰｓｅｃオープンをすると、ＵＤＰｓｅｃオープン処理（図１５のステップＳ１２５及び図１９を参照）が開始される。また、ホストＡがＵＤＰｓｅｃオープンした場合も同様にＵＤＰｓｅｃオープン処理が開始される。そして、ＵＤＰｓｅｃのデータ通信が実現可能となる。
【０１１５】
この図１６（ｂ）に示したＵＤＰｓｅｃを用いたユニキャスト通信においても、ＵＤＰのときと同様に、ホストＡ側又はホストＢ側の何れからもデータを送信することができる。図１６（ｂ）の場合、まず、ホストＡのアプリケーションからＵＤＰデータの送信要求があったとして説明する。アプリケーションからＵＤＰデータの送信要求を受け取ると、ホストＢは、ＵＤＰｓｅｃユニキャスト受信開始処理を開始し、ネゴシエーションを開始する。ネゴシエーションをして、相手が正しい相手であれば、ネゴシエーションを完了して、アプリケーションからＵＤＰデータの送信要求をＵＤＰｓｅｃデータ（暗号データ）として送信する。このＵＤＰｓｅｃユニキャスト通信では、データを受信した側からＡＣＫ（肯定応答）を返さない。このため、送達確認とデータの保証をする機能はないが、その分データの通信が高速になり、大容量の画像データなどの通信に適している。
【０１１６】
図１７は、標準ＵＤＰと本発明のＴＣＰ２の暗号化方式であるＵＤＰｓｅｃを用いたブロードキャスト通信の開始シーケンス、データ通信シーケンスのパケット（ヘッダと、ペイロードで構成する）及び、その流れを説明した図である。
図１７（ａ）が、標準のＵＤＰ、図１７（ｂ）が本発明のＴＣＰ２のＵＤＰｓｅｃによる通信のシーケンス図である。
【０１１７】
図１７（ａ）の標準のＵＤＰは、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンしている。そして、ホストＢのアプリケーションがＵＤＰオープンをすると、ＵＤＰオープン処理（図１５のステップＳ１２４及び図１８参照）を開始する。また、ホストＡのアプリケーションがＵＤＰオープンした場合も、同様にＵＤＰオープン処理を開始する。これにより、ＵＤＰのデータ通信を行うことができる状態となる。
【０１１８】
また、データはホストＡ、ホストＢの何れも発生することはできるが、図１７（ａ）では、ブロードキャスト通信ということもあって、ホストＡ側からホストＢ側に一方向的にデータが流れる図としている。データを受信したホストＢ側からＡＣＫ（肯定応答）を返さないため、送達確認とデータの保証をする機能は持たない。なお、データをブロードキャストする場合には、ＩＰアドレスのサブネットアドレスをオール１にすることで、データをブロードキャストすることが可能となる。
【０１１９】
次に、図１７（ｂ）のＵＤＰｓｅｃによる暗号化通信について説明する。この場合も、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンし、ＴＣＰ２がＵＤＰｓｅｃでオープンとしている。
ホストＢがＵＤＰｓｅｃオープンをすると、ＵＤＰｓｅｃオープン処理（図１５のステップＳ１２５及び図１９）を開始する。また、ホストＡがＵＤＰｓｅｃオープンしても同様に、ＵＤＰｓｅｃオープン処理を開始する。これにより、ＵＤＰｓｅｃのデータ通信を行うことができる状態となる。
【０１２０】
図１７（ｂ）示すように、ホストＡのアプリケーションからＵＤＰのブロードキャストデータ（ＩＰアドレスがブロードキャストを示しているデータ）の送信要求があった場合を説明する。アプリケーションからＵＤＰのブロードキャストデータの送信要求を受け取ると、ネゴをしないで、ＵＤＰｓｅｃで暗号データとして不特定ホストに配信する。ホストＢは、ブロードキャストデータを受け取ると、後述する図１９のステップＳ１４１のＵＤＰｓｅｃブロードキャスト受信開始処理を開始する。ホストＡとホストＢ間でネゴシエーションを開始し、相手が正しい相手であれば、ネゴシエーションを完了して、ブロードキャストデータを復号化して、アプリケーションへ送る。このとき、データを受信した側からＡＣＫ（肯定応答）を返さないため、送達確認とデータの保証をする機能はない。
【０１２１】
次に、図１８に基づいて、図１５のステップＳ１２４の標準ＵＤＰのオープン処理について説明する。
図１８は、ＵＤＰのオープン処理の流れ図であり、この処理は図１５のステップＳ１２４で、処理するプロトコルがＵＤＰと決定した場合に開始される処理である。
【０１２２】
最初に、アプリケーションからの送信要求、又は受信パケットを待ち、送信要求又はパケットを受信したときに、パケットの解析を行う（ステップＳ１３０）。ここで、受信パケットだけでなく送信要求も解析するのは、悪意を持った第三者が送信するホストＡ踏み台にして、ホストＡを加害者として不特定多数に通信することを防ぐためである。この送受信パケットの解析を行った後に、正しいパケットであるかどうか、つまりＤｏＳ攻撃におけるＵＤＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ１３１）。この判断ステップＳ１３１において、不正パケットであると判定された場合には、パケットを廃棄し（ステップＳ１３２）、次のパケットを待つ。
【０１２３】
判断ステップＳ１３１で正しいパケットであると判定された場合は、ＵＤＰデータの送受信処理が行われ（ステップＳ１３３）、続いて上位アプリケーションからＵＤＰのクローズ要求があったかどうかが判断される（ステップＳ１３４）。上位アプリケーションよりＵＤＰクローズ要求があった場合には、ＵＤＰオープン処理を終了する（ステップＳ１３５）。
【０１２４】
次に、図１９に基づいて、図１５のステップＳ１２５のＵＤＰｓｅｃのオープン処理について説明する。図１９は、ＵＤＰｓｅｃのオープンにおける処理の流れ図であり、図１５のステップＳ１２５に示すように、処理するプロトコルがＵＤＰｓｅｃと決定した場合にこの処理が開始される。
【０１２５】
最初に、アプリケーションからの送信要求又は受信パケットを待ち、送信要求又は受信したパケットの解析が行われる（ステップＳ１４０）。次に、上位アプリケーションからの送信要求あるいは送受信パケットが正しいＵＤＰパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ１４１）。判断ステップＳ１３４において正しいＵＤＰパケットではないと判断された場合は、パケットを廃棄し（ステップＳ１４２）、次のパケットを待つ。
【０１２６】
判断ステップＳ１４１において、正しいＵＤＰパケットであると判定された場合は、次にＵＤＰｓｅｃネゴシエーションがなされた受信パケットであるか否かが判断される（ステップＳ１４３）。
【０１２７】
そして、この結果、ＵＤＰｓｅｃのネゴシエーションパケットであると判断された場合は、後述する図２３で示すＵＤＰｓｅｃユニキャスト受信開始処理が行われ（ステップＳ１４４）、ステップＳ１５４へ進む。
また、判断ステップＳ１４３において、ＵＤＰｓｅｃのネゴシエーションパケットではないと判断されると、続いてブロードキャスト通信であるか否かを判断する（ステップＳ１４５）。そして、ブロードキャスト通信であると判定された場合は、通信の開始パケットであるか、つまりオープン後の最初の通信パケットであるか否かを判断し（ステップＳ１４６）、開始パケットでない場合は図２２で説明するＵＤＰｓｅｃデータ送受信処理を行う（ステップＳ１５１）。判断ステップＳ１４６において通信の開始パケットであると判定された場合は、次に送信パケットであるか否かが判断される（ステップＳ１４７）。そして、この結果、送信パケットであれば、上述したＵＤＰｓｅｃデータ送受信処理が行われる（ステップＳ１５１）が、送信パケットではないと判定された場合は、後述する図２０のＵＤＰｓｅｃブロードキャスト受信開始処理が実施される（ステップＳ１４８）。この受信開始処理の後で、送信されたパケットが正しい相手からのものであるかどうかを判断する（ステップＳ１４９）。そして、判断ステップＳ１４９で、送信されたパケットが正しい相手からのものではないと判断されると、パケットを廃棄し（ステップＳ１５０）、次のパケットを待つ。判断ステップＳ１４９で、正しい相手であると判定された場合には、図２２で示すＵＤＰｓｅｃデータ送受信処理が行われる（ステップＳ１５１）。
【０１２８】
また、判断ステップＳ１４５において、ブロードキャスト通信でない、すなわちユニキャスト通信であると判定された場合は、通信の開始パケット、すなわちオープン後の最初の通信パケットであるか否かが判断される（ステップＳ１５２）。この結果、開始パケットではないと判断された場合には、図２２で詳述するＵＤＰｓｅｃデータ送受信処理がなされる（ステップＳ１５１）。
【０１２９】
また、判断ステップＳ１５２で、オープン後の最初の通信パケットであると判断された場合は、図２１で後述するＵＤＰｓｅｃユニキャスト送信開始処理が行われる（ステップＳ１５３）。その後、通信の相手が、正しい相手であるかを判断し（ステップＳ１５４）、正しい相手である場合には、引き続きＵＤＰｓｅｃデータ送受信処理がなされ（ステップＳ１５１）、正しい相手ではないと判定された場合には、受信したパケットを廃棄し（ステップＳ１５５）、ステップＳ１４０に戻って次のパケットを待つ。
【０１３０】
次に、図１９のステップＳ１４８のＵＤＰｓｅｃブロードキャスト受信の開始における処理について、図２０に示す流れ図に基づいて説明する。
最初に、ブロードキャストを配信してきた相手の情報を自コンピュータが保有しているか否かを判断する（ステップＳ１６０）。そして、情報を保有していない場合には、本システムをインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１６１）。または、第三者認証のサーバから情報を取得する。この取得する情報は、相手のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数を使用する。次に、ブロードキャストを配信してきた相手が正しい相手であるかどうかを判断する（ステップＳ１６２）。そして、正しい相手であると判断されれば、ＵＤＰｓｅｃでの受信が可能であることになり、ＵＤＰｓｅｃブロードキャストの通信開始処理を終了し（ステップＳ１６４）、受信可能であることを図１９のステップＳ１４９へ指示する。判断ステップＳ１６２で正しい相手ではないとされた場合には、通信の拒否を行い（ステップＳ１６３）、データを取得しない旨を同じく図１９のステップＳ１４９へ指示する。なお、ステップＳ１６０で仮に相手方に関する取得情報があったとしても有効期限、若しくは、有効使用回数を超えている場合には、改めてステップＳ１６１で相手情報の取得動作を行ったほうがよい。
【０１３１】
次に、図１９のステップＳ１５３のＵＤＰｓｅｃユニキャスト送信開始処理について、図２１に示す流れ図に基づいて説明する。
最初に、送信する相手の情報を自コンピュータが保有しているか否かを確認する（ステップＳ１７０）。そして、情報を保有していない場合には、図２０のステップＳ１６１と同様な方法で相手情報を取得する（ステップＳ１７１）。この取得する情報も図２０の場合と同じである。
【０１３２】
次に、送信する相手が正しい相手であるかどうかを判断する（ステップＳ１７２）。そして、正しい相手であると判断されれば、ＵＤＰｓｅｃでの送信が可能であることになり、ＵＤＰｓｅｃユニキャストの通信開始処理を終了し（ステップＳ１７４）、送信可能であることを図１９のステップＳ１５４へ指示する。判断ステップＳ１７２で正しい相手ではないとされた場合には、通信の拒否を行い（ステップＳ１７３）、データを取得しない旨を図１９のステップＳ１５４へ指示する。
【０１３３】
次に、図２２に基づいて、図１９のステップＳ１５１に示すＵＤＰｓｅｃデータの送受信処理について説明する。
最初に、ホストＡのアプリケーションから送信要求があったか否かを判断する（ステップＳ１８０）。送信要求があれば送信側ホストＡにおいてデータを暗号化し（ステップＳ１８１）、この暗号化したデータに認証データを付加して（ステップＳ１８２）、受信側ホストＢに認証データが付加されたパケットを送信する（ステップＳ１８３）。
【０１３４】
次に、受信側ホストＢで、受信データがあるか否かが判断され（ステップＳ１８４）、受信データがある場合には、受信データの復号化が行われる（ステップＳ１８５）。次に、この受信され復号化されたデータが正しいデータであるかどうかが判断される（ステップＳ１８６）。この判断は、復号化したデータと受信された認証データとを確認することによって行われるが、復号データを確認した結果、正しいデータでないと判定された場合には、ＵＤＰ／ＵＤＰｓｅｃを強制的に切断する（ステップＳ１８７）。判断ステップＳ１８６で、復号化したデータが正しいデータであると判定された場合には、受信データの取り込み、すなわち上位プロトコルスタックへのデータの配達が行われ（ステップＳ１８８）、ＵＤＰｓｅｃのデータ送受信処理が完了する（ステップＳ１８９）。
【０１３５】
次に、図２３の流れ図に基づいて、図１９のステップＳ１４４に示すＵＤＰｓｅｃユニキャスト受信の開始処理について説明する。
最初に、ユニキャストで受信したパケットの相手情報を自コンピュータが保有しているか否かを判断する（ステップＳ１９０）。相手情報を持っていない場合には、本システムをインストールする際に使用した、インストールサーバあるいは第三者認証のサーバから相手情報を取得する（ステップＳ１９１）。取得する情報としては、図２０のステップＳ１６１あるいは図２１のステップＳ１７１と同じであり、相手のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数がこれに相当する。
【０１３６】
次に、ユニキャストを送信してきた相手が正しい相手であるか否かを判断する（ステップＳ１９２）。正しい相手であると判定されれば、ＵＤＰｓｅｃでの受信が可能であることを図１９のステップＳ１５４へ伝えてＵＤＰｓｅｃブロードキャスト通信開始処理を終了する（ステップＳ１９４）。判断ステップＳ１９２で正しい相手ではないと判断された場合には、データを取得しない旨を図１９のステップＳ１５４へ伝え、通信を拒否する（ステップＳ１９３）。
【０１３７】
以上、本発明の第１の実施形態であるＴＣＰｓｅｃを用いた暗号化処理及び本発明の第２の実施形態であるＵＤＰｓｅｃを用いた暗号化処理について流れ図及びシーケンス図に基づいて詳しく説明した。
【０１３８】
次に、本発明のＴＣＰ２が、従来のＩＰｓｅｃあるいはＳＳＬと比べて如何に優位であるかという点について、図２４に基づいて説明する。
例えば、ＳＳＬでは対応が困難であった、クライアント−クライアント間の通信、ＴＣＰ／ＩＰプロトコルへのＤｏＳ攻撃、全てのＵＤＰポートあるいはＴＣＰポートのセキュアな通信、ソケットプログラムを変更しなければならなかったアプリケーションでの制限などに、ＴＣＰ２は完全に対応している。
【０１３９】
また、ＩＰｓｅｃでは対応が困難であった、エラーが多発する劣悪な環境下での通信、異なったＬＡＮ間での通信、複数キャリア経由の接続、ＰＰＰモバイル環境、ＡＤＳＬ環境での通信に対しても、ＴＣＰ２は完全にサポートしている。
さらに、モバイル環境下やＡＤＳＬ環境下でＶｏＩＰ（Voice over Internet Protocol）を使ったインターネットに対しても、本発明のＴＣＰ２により対応可能である。
【０１４０】
また、異なったＬＡＮ間や複数キャリアにまたがったＬＡＮ間でＶｏＩＰを使ったインターネット電話に対しても、ＩＰｓｅｃとＳＳＬでは対応不可能であったが、本発明のＴＣＰ２によれば完全に対応することができる。
【０１４１】
図２４は、ＴＣＰ２の優位性を説明するための図であるが、セキュリティのないプロトコルスタック（ａ）に、従来のＳＳＬを適用したケース（ｂ）と、ＩＰｓｅｃを適用したケース（ｃ）と、本発明のＴＣＰ２（ＴＣＰｓｅｃ／ＵＤＰｓｅｃ）を適用したケース（ｄ）を比較して示している。図２４（ｂ）のＳＳＬは既に述べたように、セッション層（第５層）のソケットに設けられているので、上位のアプリケーションに対する互換性がないのである。このため、ＳＳＬ自体、上述のような問題を抱えることになっている。また図２４（ｃ）のＩＰｓｅｃは、ネットワーク層（第３層）にあり、ＩＰ層での互換性がないため、ネットワークを構成する上で上述したような様々な制約を受けることになる。これに対して、図２４（ｄ）のＴＣＰ２（ＴＣＰｓｅｃ／ＵＤＰｓｅｃ）は、トランスポート層（第４層）に導入する暗号化技術であり、このためアプリケーションから見るとソケットをそのまま利用することができ、またネットワークから見るとＩＰもそのまま利用できるのでネットワークを構成する上での制約は受けない。
【０１４２】
以上のように、本発明のＴＣＰ２を用いた暗号化通信システム、暗号化通信方法は、既存の暗号化処理システムに比べても、特にデータの漏洩、改ざん、なりすまし、進入そして攻撃に対して極めて高いセキュリティ機能を有するものである。
なお、本発明は、以上説明した実施の形態に限定されるものではなく、特許請求項に記載した本発明の要旨を逸脱しない範囲において、さらに多くの実施形態を含むものであることは言うまでもない。
【図面の簡単な説明】
【０１４３】
【図１】本発明の通信システムに用いられるＴＣＰ２のプロトコルスタックを示す図である。
【図２】本発明のＴＣＰ２を用いた通信システムの第１の実施形態（ＴＣＰｓｅｃによるＥＣアプリケーション）におけるシステムの全体構成図である。
【図３】本発明のＴＣＰ２を用いた通信システムの第２の実施形態（ＵＤＰｓｅｃによる放送アプリケーション）におけるシステムの全体構成図である。
【図４】本発明のＴＣＰ２の中の３つのプロトコルスタックのパケット構造とその暗号化範囲及び認証範囲を示す図である。（ａ）、（ｂ）（ｃ）は、それぞれＴＣＰｓｅｃ／ＩＰｓｅｃ、ＴＣＰｓｅｃ／ＩＰ、ＵＤＰｓｅｃ／ＩＰのパケット構造、及び各暗号化範囲、完全性認証の適用範囲を示す図である。
【図５】本発明のＴＣＰ２の実施形態であるＴＣＰ／ＴＣＰｓｅｃパッシブオープンの処理を示す流れ図である。
【図６】本発明のＴＣＰ２の実施形態であるＴＣＰ／ＴＣＰｓｅｃアクティブオープンの処理を示す流れ図である。
【図７】標準ＴＣＰと本発明のＴＣＰｓｅｃのホストＡ（アクティブオープン）とホストＢ（パッシブオープン）間の通信のやり取りを示すシーケンス図である。
【図８】図５のＴＣＰパッシブオープン処理Ｓ５の詳細を示す流れ図である。
【図９】図５のＴＣＰｓｅｃパッシブオープン処理Ｓ６の詳細を示す流れ図である。
【図１０】図６のＴＣＰアクティブオープン処理Ｓ１２の詳細を示す流れ図である。
【図１１】図６のＴＣＰｓｅｃアクティブオープン処理Ｓ１３の詳細を示す流れ図である。
【図１２】図９のＴＣＰｓｅｃ送受信処理Ｓ３７及び図１１のＴＣＰｓｅｃ送受信処理Ｓ７６の詳細を示す流れ図である。
【図１３】図９のＴＣＰｓｅｃパッシブ接続処理Ｓ４８の詳細を示す流れ図である。
【図１４】図１１のＴＣＰｓｅｃアクティブ接続処理Ｓ８８の詳細を示す流れ図である。
【図１５】本発明のＴＣＰ２の実施形態であるＵＤＰ／ＵＤＰｓｅｃオープンの処理を示す流れ図である。
【図１６】本発明のＴＣＰ２を用いたＵＤＰ／ＵＤＰｓｅｃユニキャスト通信のシーケンス図である。
【図１７】本発明のＴＣＰ２を用いたＵＤＰ／ＵＤＰｓｅｃブロードキャスト通信のシーケンス図である。
【図１８】図１５のＵＤＰオープン処理Ｓ１２４の詳細を示す流れ図である。
【図１９】図１５のＵＤＰｓｅｃオープン処理Ｓ１２５の詳細を示す流れ図である。
【図２０】図１９のＵＤＰｓｅｃブロードキャスト受信開始処理Ｓ１４１の詳細を示す流れ図である。
【図２１】図１９のＵＤＰｓｅｃユニキャスト送信開始処理Ｓ１４６の詳細を示す流れ図である。
【図２２】図１９のＵＤＰｓｅｃデータ送受信処理Ｓ１４４の詳細を示す流れ図である。
【図２３】図１９のＵＤＰｓｅｃユニキャスト受信開始処理Ｓ１３７の詳細を示す流れ図である。
【図２４】本発明のＴＣＰ２を従来のＩＰｓｅｃ又はＳＳＬを適用した場合と比較したメリットを説明するための図である。
【符号の説明】
【０１４４】
１・・・ホストコンピュータ、
２・・・ネットワーク制御機器（ルータ）
３ａ、３ｂ、３ｃ・・・クライアント端末
４ａ、４ｂ、４ｃ・・・クライアント端末
１１・・・ＮＩＣドライバ
１２・・・ＡＲＰ 又は ＡＲＰ ｏｎ ＣＰ
１３・・・ＩＰエミュレータ
１３ｂ・・・ＩＰｓｅｃ ｏｎ ＣＰ
１５・・・ＴＣＰエミュレータ
１５ｂ・・・ＴＣＰｓｅｃ ｏｎ ＣＰ
１６・・・ＵＤＰエミュレータ
１６ｂ・・・ＵＤＰｓｅｃ ｏｎ ＣＰ
１７・・・ソケット（Ｓｏｃｋｅｔ）
４１・・・ＩＰヘッダ
４２・・・ＥＳＰヘッダ
４３・・・ＴＣＰヘッダ
４４・・・ＴＣＰｓｅｃ付加情報
４５・・・データ（ペイロード）
４６・・・ＴＣＰｓｅｃ付加トレーラ
４７・・・ＴＣＰｓｅｃ付加認証データ
４８・・・ＥＳＰトレーラ
４９・・・ＥＳＰ認証データ
【技術分野】
【０００１】
本発明は、通信における暗号化通信システム、特に、インターネット上でのデータの「漏洩」及び「改竄」さらには「なりすまし」、「進入」ないし「攻撃」を防ぐための暗号化通信システムに関する。
【背景技術】
【０００２】
近年、インターネットを利用した通信は、Ｗｉｎｄｏｗｓパソコンさえあれば、それをネットワークに接続するだけで、誰でもネットワーク上のコンピュータにアクセスできるため、社会の中で急速に普及拡大している。一方、このインターネット通信の普及拡大に伴って、ハッカー（hacker）やクラッカー（Cracker）が他人のコンピュータシステムに侵入して、ソフトウエアやデータを盗み見たり、改竄や破壊を行ったりするという社会問題も大きくなっている。
【０００３】
具体的な不正妨害のケースとしては、まず第１に、中心的なシステムが使えなくなるように、ネットワークから大量のメッセージを送りつけコンピュータシステムの運用を妨害するシステム妨害がある。この妨害によってホストが過負荷になるとシステムダウンに陥ってしまうことも起こりうる。
【０００４】
また、ホストのパスワードを入手し、機密情報を盗んだり、情報の改竄や破壊を行ったりする「不正アクセスとなりすまし」の不正妨害がある。この妨害にはコンピュータが保有する情報を勝手に書き換え、人を陥れる卑劣のものもある。また、特定のパソコンに忍び込み、メールアドレスやパスワードなど個人の機密データを搾取するスパイウエアといわれる不正行為も発生している。このようにネットワークに接続したコンピュータが持つデータベースの内容を不正に盗み見る、いわゆる盗聴行為も頻繁に行われている可能性も否定できない。
【０００５】
また、サイト若しくはサーバの運営元で、意図的に個人情報を盗むといった行為や、社内に潜むスパイなどによるサイバーテロ（Cyber terrorism）といった危機も全くないとはいえない状況である。
さらに、他人のコンピュータにコンピュータ障害をもたらすプログラムである「ウイルス」を送り込むという不正妨害が最近多くなっている。この送り込まれたウイルスに、メールなどを自宅で使用したパソコンが感染し、それを社内に接続した瞬間に社内のパソコン全体が感染したり、ウイルスがコンピュータの中のファイルを破壊させたり、更には、ネットワーク全体をダウンさせたりするといった問題も生じている。
【０００６】
このため、従来のＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）やＵＤＰ（User Datagram Protocol）を利用したインターネット上での通信において、データの「漏洩」「改竄」等を防ぐ機能として、ＩＰｓｅｃ（アイピーセック：Security Architecture for Internet Protocol）やＳＳＬ（Secure Socket Layer）といわれる暗号化通信が利用されている。一般に、暗号化通信には、共通鍵（秘密鍵ともいう）暗号方式と公開鍵暗号方式があるが、ＩＰｓｅｃは共通鍵暗号方式を用いたものが多い。共通鍵暗号方式の方が公開鍵暗号方式より暗号化・復号化の速度が速いという特徴がある。このＩＰｓｅｃに用いられる共通鍵暗号方式は、暗号化と復号化を同じ鍵で行う方式であり、鍵の生成は送信側又は受信側のいずれで生成してもよいが、受信側と送信側とで共通鍵を使うために、鍵の交換時に内容が外部に漏れないよう細心の注意を払わなければならない。
【０００７】
共通鍵暗号方式に用いられるアルゴリズムはＤＥＳ（Data Encryption Standard:米国ＩＢＭ社が開発した共通鍵（秘密鍵）暗号化アルゴリズム）が代表的である。ＩＰｓｅｃもこのＤＥＳを暗号アルゴリズムの１つに採用している。ＩＰｓｅｃの特徴は、単に特定のアプリケーションだけを暗号化するのではなく、ホストから送信されるあらゆる通信をＩＰレベルで暗号化する点にある。これによりユーザはアプリケーションを意識することなく安全な通信を可能とすることができる。また、ＩＰｓｅｃは、将来にわたって使えるように、それ自体の仕組みを変えることなく使用する暗号アルゴリズムを変更することを可能としている。
【０００８】
ＩＰｓｅｃで用いられる共通暗号鍵としては、ＳＰＩ（Security Pointer Index）と呼ばれる３２ビット符合が用いられ、鍵交換プロトコルとしては、ＩＫＥ（Internet Key Exchange）が用いられる。さらに、ＩＰｓｅｃには、完全性認証のためのプロトコルＡＨ（Authentication Header）が用意されている。
【０００９】
また、ＳＳＬは、米ネットスケープ社（現在ＡＯＬに吸収合併）の開発したセキュリティ機能付ＨＴＴＰプロトコルであり、これを利用することによりクライアントとサーバがネットワーク上でお互いを認証できるようになり、クレジットカード情報などの機密性の高い情報を暗号化してやり取りすることが可能となる。これにより、データの盗聴、再送攻撃（ネットワーク上に流れたデータを盗聴して何度も繰り返して送ってくる攻撃）、なりすまし（本人の振りをして通信する）、データの改竄などを防止することができる。
【００１０】
上述したＩＰｓｅｃは、ＩＰのパケットを暗号化して送受信するものであり、したがって、ＴＣＰやＵＤＰなどの上位のプロトコルを利用するアプリケーションソフトはＩＰｓｅｃが使われていることを意識する必要がない。
一方、ＳＳＬでは、互いの認証レベルではＲＳＡ（Rivest Shamir Adleman：公開鍵暗号方式を開発者３人の頭文字）公開鍵暗号技術を用いたデジタル証明書が用いられ、データの暗号化ではＤＥＳなどの共通鍵暗号技術が用いられている。このＳＳＬは第５層のセッション層にあるため、特定のアプリケーションに依存することになる。
【非特許文献１】R.Atkinson, 1995年8月、「Security Architecture for the Internet Protocol」、RFC 1825
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、ＳＳＬはアプリケーションに対する互換性を持たない点において問題がある。アプリケーションは、インターネット通信を行う際にソケット（第５層）をプログラムインターフェースとして使用する。このため、アプリケーションがＳＳＬ（第５層）を使用する場合には、このソケットインターフェースをＳＳＬインターフェースに変更しなければならない。従って、ＳＳＬにアプリケーションの互換性はない。これに対し、ＩＰｓｅｃは、ソケット（第５層）の下に位置しているため、アプリケーションは、ソケット（第５層）をプログラムインターフェースとしてそのまま使用することができるのでアプリケーションの互換性がある。
【００１２】
一方、ＩＰｓｅｃは最大セグメントサイズが小さくなるという問題がある。すなわち、ＩＰｓｅｃでは、ＥＳＰヘッダ、ＥＳＰトレーラを使用するため、ペイロードが小さくなるため、フラグメント（パケットの分割）が発生し、スループットが低下する。また、ＴＣＰパケットでは、フラグメントが禁止であるため、エンドエンドで、ＩＰｓｅｃの通過する環境を把握し、フラグメントが発生しない最大セグメントサイズを設定する必要がある。これに対し、ＳＳＬは、通過する環境を把握する必要がないため、最大セグメントサイズを設定する必要はない。
【００１３】
本発明は、上述のような問題に鑑みてなされたものであり、コンピュータ端末への不正侵入を防ぐための「暗号化の機能」をアプリケーション・プログラムそれぞれに実装する必要がなく、したがって、アプリケーション・プログラム自体を再作成する必要もなく、かつ上記暗号化機能に対応していない通信相手とも従来の平文による通信でき、さらにはＩＰｓｅｃが利用できない環境（あるいは利用したくない状況）でも暗号化や認証の恩恵を受けることができる通信システム、特にプロトコルスタック、並びに関連する通信装置、通信方法、及びこれらを実現するための通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決し、本発明の目的を達成するため、本発明の暗号化通信システムは、トランスポート層に位置するＴＣＰ又はＵＤＰプロトコルに暗号化機能を追加して複数のホスト間で通信を行う暗号化通信システムであって、通信相手との接続を行うための接続シーケンス手段と、ＴＣＰ２固有情報を交換して通信相手が正当な権限を有する通信相手であるかどうかを判断し、暗号化通信に必要な鍵交換を行うためのＴＣＰｓｅｃ接続シーケンス手段と、通信路の両端で対応する暗号化及び復号化ロジックを取り決める取決め手段と、この取決め手段により取り決めた暗号化ロジックに従って、複数のホスト間で送受信する情報のパケットを暗号化して送信するプロトコル暗号化手段と、取決め手段により取り決めた復号化ロジックに従って複数のホスト間で送受信する情報のパケットを復号化するプロトコル復号化手段と、を備え、前記接続シーケンス手段は、一切のイレギュラーパターンを排除するネットワーク環境にも対応できるように、第１のホストから第２のホストへの接続要求と、第２のホストから第１のホストへの接続応答と、第１のホストから第２のホストに肯定応答を送信するという標準の接続を行い、ＴＣＰｓｅｃ接続シーケンス手段は、相手方ホストとＴＣＰ２固有情報の交換を行うことにより、相手方ホストが前記暗号化通信を行う権限を有することを確認し、暗号化通信に必要な鍵交換を行い、取決め手段は、接続シーケンス手段が正当な権限を有すると判断して接続した通信相手とのみ前記トランスポート層の前記ＴＣＰ又はＵＤＰプロトコルを用いて前記暗号化及び復号化ロジックに基づいた通信を行い、プロトコル暗号化手段は、送受信される情報のパケットのうち前記ＴＣＰ又はＵＤＰプロトコルのペイロードを暗号化して送信し、プロトコル復号化手段は、送受信される情報のパケットのうち前記暗号化されたプロトコルのペイロードを復号化することを特徴とする暗号化通信システムである。
【発明を実施するための最良の形態】
【００１５】
以下、図１〜図２４を参照しながら本発明の実施の形態の例を説明する。
図１は、本発明の暗号化通信システムの一実施の形態に用いられるプロトコルスタックを示すものである。
【００１６】
本発明に用いられるプロトコルスタックは、図１に示すように、ＯＳＩ７階層の物理層（第１層）とデータリンク層（第２層）に相当する階層に、ＮＩＣ（Network Interface Card）のDriver１１が配列される。このドライバは、既に述べたように、コンピュータなどのハードウエアをネットワークに接続するためのインターフェースカードのドライバであり、その内容はデータ送受信制御ソフトウエアである。例えばEthernetに接続するためのＬＡＮボードまたはＬＡＮカードがこれに相当するものである。
【００１７】
第３層のネットワーク層には、一部がトランスポート層（第４層）まで伸びたＩＰエミュレータ（emulator）３が存在している。上記延びた部分には、トランスポートとしての機能は実装していない。セッション層に、ネットワーク層の機能を提供しているだけある。このＩＰエミュレータ３は、暗号化通信を行うプロトコルである「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂと、「ＩＰ ｏｎ ＣＰ」１３ａを用途に応じて切り換えて使う働きをするものである。ここで、「ｏｎ ＣＰ」とは、クラッキング・プロテクタ（ＣＰ）による、「進入」「攻撃」の監視、破棄、切断ないし通過制限の対象となっていること、又は、設定によりなりうることを示している。
【００１８】
また、ネットワーク層にはＡＲＰ ｏｎ ＣＰ（Address Resolution Protocol on Cracking Protector）が配列されている。このＡＲＰ ｏｎ ＣＰは、クラッカー（Cracker）への保護対策を具備したＩＰアドレスからEthernetの物理アドレスであるＭＡＣ（Media Access Control）アドレスを求めるのに使われるプロトコルである。ＭＡＣは、媒体アクセス制御と呼ばれる、ＬＡＮなどで利用される伝送制御技術であり、データの送受信単位であるフレームの送受信方法やフレームの形式、誤り訂正などを規定する技術として利用されている。
【００１９】
ここで、ＩＰエミュレータ１３は、本発明による各種のセキュリティ機能を、従来のＩＰ周辺のスタックに整合させるためのソフトウエア又はファームウエアである。すなわち、ＩＰのエラーメッセージや制御メッセージを転送するプロトコルであるＩＣＭＰ（Internet Control Message Protocol）１４ａ、同一のデータを複数のホストに効率よく配送するための又は配送を受けるために構成されるホストのグループを制御するためのプロトコルであるＩＧＭＰ（Internet Group Management Protocol）１４ｂ、ＴＣＰ１５、ＵＤＰ１６さらにソケット（Socket）インターフェース１７に整合させるためのソフトウエア、又はファームウエア、ないしはハードウエア（電子回路、電子部品）である。このＩＰエミュレータ１３により、ＩＰｓｅｃの暗号化・復号化及び必要な認証情報付加・認証等の前後の適合処理を行うことができる。
【００２０】
このＩＰエミュレータ１３の上層のトランスポート層（第４層）には、ＴＣＰエミュレータ１５とＵＤＰエミュレータ１６が配置されている。ＴＣＰエミュレータ１５は、暗号化通信を行うプロトコルである「ＴＣＰｓｅｃ ｏｎ ＣＰ」１５ｂと、通常の通信プロトコルである「ＴＣＰ ｏｎ ＣＰ」１５ａを用途に応じて切り換えて使う働きをする。同様に、ＵＤＰエミュレータ１６は、暗号化通信を行うプロトコルである「ＵＤＰｓｅｃ ｏｎ ＣＰ」１６ｂと、通常の通信プロトコルである「ＵＤＰ ｏｎ ＣＰ」１６ａを用途に応じて切り換えて使う働きをする。
【００２１】
本発明の最も特徴とするべき点は、このトランスポート層（第４層）に、ＴＣＰｓｅｃ１５ｂと、ＵＤＰｓｅｃ１６ｂの暗号化通信プロトコルを搭載したことである。ＴＣＰｓｅｃ１５ｂとＵＤＰｓｅｃ１６ｂについては後述する。
このトランスポート層（第４層）の上層のセッション層（第５層）には、ＴＣＰ及びＵＤＰ等のプロトコルとデータのやりとりを行うソケット（socket）インターフェース１７が設けられている。このソケットの意味は、既に述べたようにコンピュータが持つネットワーク内の住所に当たるＩＰアドレスと、ＩＰアドレスのサブアドレスであるポート番号を組み合わせたネットワークアドレスを意味しており、実際には、一連のヘッダの追加ないし削除をまとめて行う、単一のソフトウエアプログラムモジュール（実行プログラム等）あるいは単一のハードウエアモジュール（電子回路、電子部品等）からなっている。
【００２２】
このソケットインターフェース１７は、さらに上位のアプリケーション（図２で示すＥＣアプリケーション及び図３で示す放送アプリケーション等）からの統一的なアクセス方式を提供するものであり、引数の種類や型など従来と同様のインターフェースを保つようにしている。
ＴＣＰエミュレータ１５は、トランスポート層において、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つＴＣＰｓｅｃ１５ｂと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルＴＣＰ１５ａのいずれかにパケットを振り分ける働きをもっている。また、ＴＣＰｓｅｃ１５ｂ及びＴＣＰ１５ａのいずれもクラッキング・プロテクタ（ＣＰ）を備えているため、そのいずれを選択した場合でも、クラッカーによる「進入」「攻撃」に対して防御する機能を実現することができる。ＴＣＰエミュレータ１５は上位層であるソケットとのインターフェースの役割も果たしている。
【００２３】
また、既に述べたようにＴＣＰがエラー補償機能を有するのに対して、ＵＤＰはエラー補償機能を持たないが、その分転送速度が速く、かつブロードキャスト機能を備えているという特徴がある。ＵＤＰエミュレータ１６は、ＴＣＰエミュレータ１５と同様に、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つＵＤＰｓｅｃ１６ｂと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルＵＤＰ１６ａのいずれかにパケットを振り分ける働きを持っている。
【００２４】
図１に示すように、ソケット１７、ＴＣＰエミュレータ１５、ＵＤＰエミュレータ１６、「ＴＣＰｓｅｃ ｏｎ ＣＰ」１５ｂ、「ＵＤＰｓｅｃ ｏｎ ＣＰ」１６ｂ、「ＴＣＰ ｏｎ ＣＰ」１５ａ、「ＵＤＰ ｏｎ ＣＰ」１６ａ、「ＩＣＭＰ ｏｎ ＣＰ」１４ａ、「ＩＧＭＰ ｏｎ ＣＰ」１４ｂ、ＩＰエミュレータ１３、「ＩＰ ｏｎ ＣＰ」１３ａ、及び「ＡＲＰｏｎＣＰ」１２からなるプロトコルスタックが本発明の暗号化処理を行うためのプロトコルスタックであり、以下、このプロトコルスタックを総称してＴＣＰ２（登録商標出願中）と呼ぶことにする。なお、ＴＣＰ２には「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂは必須のものとして含まれていないが、「ＩＰｓｅｃ ｏｎ ＣＰ」１３ｂを含めてＴＣＰ２とすることもできる。
【００２５】
本発明のＴＣＰ２は、ＴＣＰ、ＵＤＰ、ＩＰ、ＩＰｓｅｃ、ＩＣＭＰ、ＩＧＭＰ、ＡＲＰの標準プロトコルにＣＰ（クラッキング・プロテクト）を実装し、各プロトコルスタックに対する通信からの攻撃、及び、アプリケーション・プログラムからの攻撃（トロイの木馬、プログラムの改竄、正規ユーザの不正使用）を防御することができる。また、ＴＣＰ２では、ＴＣＰエミュレータ１５を実装し、このＴＣＰエミュレータ１５は、セッション層にあるソケット（Socket）１７、及びネットワーク層にあるＩＰエミュレータ１３から見て、互換性を保つため、外向きには標準ＴＣＰと同じに見せることができる。実際は、ＴＣＰ２の機能として、ＴＣＰとＴＣＰｓｅｃを切り替えて実行する。ＴＣＰｓｅｃは、本発明であるトランスポート層での暗号化及び認証機能である。
【００２６】
また、同様に、ＴＣＰ２では、ＵＤＰエミュレータ１６を実装しており、ＵＤＰエミュレータ１６は、セッション層であるソケット（Socket）１７、及び、ネットワーク層であるＩＰエミュレータ１３から見て、互換性を保つため、外部からは標準ＵＤＰとして見せることができる。実際は、ＴＣＰ２の機能として、ＵＤＰ、ＵＤＰｓｅｃを切り替えて実行する。ＵＤＰｓｅｃは、本発明であるトランスポート層での暗号化及び認証機能である。
【００２７】
次に、ＴＣＰ２において、特に重要な機能である「データ漏洩」を防ぐ機能であるＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂについて説明する。
ＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂのための暗号化・復号化の方法（アルゴリズム、ロジック（論理））としては、公知の秘密鍵（共通鍵）暗号アルゴリズムが用いられる。例えば、１９６０年代にＩＢＭ社によって開発された秘密鍵暗号アルゴリズムであるＤＥＳ（Data Encryption Standard）や、その改良版としての３ＤＥＳが用いられる。また、その他の暗号アルゴリズムとしては、１９９２年にスイス工科大学のJames L.Massey氏とXuejia Lai氏によって発表されたＩＤＥＡ（International Data Encryption Algorithm）も用いられる。この暗号アルゴリズムは、データを６４ビットのブロックに区切って暗号化するもので暗号鍵の長さは１２８ビットである。秘密鍵暗号を効率よく解読する線形解読法や差分解読法に対しても十分な強度を持つように設計されている。
【００２８】
また、本発明に用いられるＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂの暗号方式として、ＦＥＡＬ（Fast data Encipherment Algorithm）、ＭＩＳＴＹ、ＡＥＳ（Advanced Encryption Standard）といった暗号方式も利用されるほか、また、独自に作成した秘密の暗号化・復号化アルゴリズムを利用することもできる。ここで、ＦＥＡＬは、日本電信電話株式会社（当時）が開発した暗号方式で、暗号化と復号化に同じ鍵をもちいる秘密鍵型の暗号方式である。このＦＥＡＬは、ＤＥＳに比べて高速に暗号化と復号化ができるという利点がある。
【００２９】
次に、同じく本発明に利用される暗号方式であるＭＩＳＴＹは、三菱電機株式会社が開発した秘密鍵型の暗号方式であり、ＩＤＥＡと同様にデータを６４ビットのブロックに区切って暗号化する。鍵の長さは１２８ビットである。暗号化と復号化には同じプログラムが使われる点はＤＥＳなどと同じである。この方式も秘密鍵暗号を効率よく解読する線形解読法や差分解読法に対しても十分な強度を持つように設計されている。
【００３０】
また、ＡＥＳは、米国商務省標準技術局によって選定作業が行われている、米国政府の次世代標準暗号化方式であり、現在の標準的な暗号方式であるＤＥＳに代わる次世代の暗号標準として開発が進められたものである。世界に公募して集められて幾つかの暗号方式の中から、２０００年１０月に、ベルギーの暗号開発者Joan Daemen氏とVincent Rijmen氏が開発したRijndaelという方式が採用された。
【００３１】
このように、本発明のＴＣＰｓｅｃ１５ｂ及びＵＤＰｓｅｃ１６ｂの暗号方式としては、既に知られているさまざまな秘密鍵の暗号アルゴリズムを採用することができるほか、ユーザが独自に開発した秘密鍵（共通鍵）暗号方式も利用することが可能である。
【００３２】
さらに、いわゆる「なりすまし」及び「データの改竄」などを防ぐための「相手認証」及び「完全性認証」の方法として、公開鍵や事前秘密共有（Pre-shared）を利用したアルゴリズム、例えば、ＭＤ５（Message Digest ５）、ＳＨＡ１（Secure Hash Algorithm １）などの認証アルゴリズムが用いられる。また、このような公知の認証アルゴリズムに代えて独自の一方向関数を利用したアルゴリズムを採用することもできる。
【００３３】
このＭＤ５は、認証やデジタル署名に用いられるハッシュ関数（一方向要約関数）の一つであり、原文を元に固定長のハッシュ値を発生し、これを通信経路の両端で比較することにより、通信途中で原文が改竄されていないかを検出することができるものである。このハッシュ値は擬似的な乱数のような値をとり、これを基にしては原文を再生できないようになっている。また、同じハッシュ値を生成する別のメッセージを作成することも困難になっている。
【００３４】
ＳＨＡ１も、認証やデジタル署名などに使われるハッシュ関数の一つであり、２の６４乗ビット以下の原文から１６０ビットのハッシュ値を生成し、通信経路の両端で比較することにより、通信途上の原文の改竄を検出するものである。この認証アルゴリズムは従来のインターネットの暗号化通信の代表的なものであるＩＰｓｅｃにも採用されている。
【００３５】
なお、これらの認証アルゴリズムについては、ＤＨ（Diffie-Hellman）公開鍵配送法や、ＩＰｓｅｃと同様のＩＫＥ（Internet Key Exchange）プロトコル（ＵＤＰの５００番）などにより安全な鍵交換ができるように設計され、しかも、定期的に暗号化／完全性認証アルゴリズム（論理）自体やそのための鍵の集合／定義域が変更されるように、プロトコルドライバープログラム（ＴＣＰｓｅｃ１５ｂ、ＵＤＰｓｅｃ１６ｂなど）によりスケジュールされている。
【００３６】
次に、図２に基づいて、本発明の第１の実施の形態である暗号化方式ＴＣＰ２（特に、ＴＣＰｓｅｃ）を用いた暗号化通信について説明する。図２は、特に、ＥＣ（Electronic Commerce：電子商取引）アプリケーションに応用した通信に適用する例である。
【００３７】
図２は、ネットワーク２０に接続されたＥＣアプリケーション用のクライアント端末３ａ、３ｂ、３ｃが、いわゆるルータ又はゲートウエイのようなネットワーク制御機器２を介して他のネットワーク３０に接続されたホストコンピュータ（いわゆるサーバとして機能する通信装置）に接続された場合の全体構成を示す図である。
【００３８】
ネットワーク２０に接続されるクライアント端末３ａ、クライアント端末３ｂ及びクライアント端末３ｃのうち、クライアント端末３ｂと３ｃは、本発明のＴＣＰ２を実装していない。つまりクライアント端末３ｂと３ｃには、本発明の暗号化方式のためのプロトコルであるＴＣＰｓｅｃもＵＤＰｓｅｃも実装されていない。ＴＣＰ２をサポートしているクライアント端末は３ａのみである。そして、クライアント端末３ｂについては、不図示のネットワークポリシー設定により通常のプロトコル処理による接続、すなわち、ＴＣＰレベルについては、「データ漏洩」を防ぐ暗号化機能、「データ改竄」を防ぐ完全性認証機能、及び「なりすまし」を防ぐ相手認証機能は伴わない接続を行うようにしている。
【００３９】
何れのクライアント端末３ａ〜３ｃにおいても、ソケット（socket）の上層には、ＥＣ用のアプリケーションソフトウエアが実装されている。また、ネットワーク３０に接続されたホストコンピュータ１は、ＴＣＰ２を搭載しており、そのソケット１７の上層にＥＣアプリケーションソフトウエア１８が実装されている。図２ではＵＤＰｓｅｃなどの不使用のプロトコルを省略しているが、このホストコンピュータ１のプロトコルスタックの構造は図１のプロトコルスタックの構造であるＴＣＰ２を構成するソフトウエアは全て搭載されている。
【００４０】
すなわち、まず第１層（物理層）と第２層（データリンク層）にまたがってＮＩＣドライバ（NIC Driver）１１が配置され、その上層（第３層）のネットワーク層にはＡＲＰ（Address Resolution Protocol）１２とＩＰエミュレータ１３が配置されている。そして、第４層のトランスポート層にＴＣＰエミュレータ１５とＵＤＰ１６が配置される。図２にＵＤＰエミュレータ（ＵＤＰｓｅｃとＵＤＰを含む）の記載がないのは、第１の実施形態のＥＣアプリケーションに対する暗号化通信としては速度よりも誤り補償に重点をおくＴＣＰｓｅｃが使用されるからである。このことは、ホストコンピュータがＵＤＰｓｅｃを搭載していないことを意味するものではない。ＴＣＰ２を搭載することは、既に説明したようにＵＤＰｓｅｃとＴＣＰｓｅｃの両方を搭載していることを意味している。
【００４１】
ネットワーク２０に接続されたクライアント端末３ａ、３ｂ、３ｃとネットワーク３０に接続されるホストコンピュータ１を介在するネットワーク制御機器２のプロトコルスタックは、ＮＩＣドライバ、ＡＲＰ、ＩＰがスタックとして積み上げられたファームウエア（不揮発メモリ付電子回路）により構成されている。
また、クライアント端末３ａは、本発明のＴＣＰ２をサポートする端末であるが、ここではＴＣＰｓｅｃにのみ対応した通信装置を備えた端末としてプロトコルスタックが示されている。クライアント端末３ｂと３ｃは本発明のＴＣＰ２をサポートしていない。
【００４２】
クライアント端末３ａには、ネットワークを通して又はＣＤ−ＲＯＭのような記録媒体を介して事前に配布されるプロトコルドライバソフトウエアが実装されている。また、クライアント端末３ｂ、クライアント端末３ｃに対しても同様にプロトコルドライバソフトウエアが事前に配布され、実装される。
【００４３】
特に、クライアント端末３ｃについては、従来の暗号化方式であるＩＰｓｅｃを実装しているが、ネットワーク制御機器（ルータ）２がＴＣＰポート番号を参照したＩＰマスカレードを行っているためＩＰｓｅｃが有効に使えないようになっている。更にクライアント端末３ｃについては、不図示のネットワークポリシー設定により接続要求を破棄するようにしている。なお、このようなネットワークポリシーの設定ないしプロトコルを実装しているかどうかの確認（受信パケット解析等）自体については当業者に周知の事項であるのため、本明細書では説明を省略する。
【００４４】
ホストコンピュータ１がクライアント端末３ａと通信するときは、本発明のＴＣＰ２、特にＴＣＰｓｅｃに基づいた暗号化及び復号化取決めにより、通信を行うことになるが、ホストコンピュータ１がクライアント端末３ｂ又は３ｃと通信するときは、本発明のＴＣＰ２（特に、ＴＣＰｓｅｃ）による暗号化及び復号化の取決めがされない状態、つまり通常のＴＣＰプロトコルによる通信が行われることになる。もちろん、ホストコンピュータ１がＩＰｓｅｃをサポートしているクライアント端末３ｃと通信する場合には、ＩＰｓｅｃによる暗号化通信をすることができることは当然である。なお、ホストコンピュータ１が、ＴＣＰ２が搭載されていないクライアント端末３ｂ又は３ｃと通信しようとしてもホストコンピュータ１の有するＴＣＰ２の働きで、通信をストップさせることも可能である。
【００４５】
また、この実施の形態では、ネットワークを介してホストコンピュータ１とクライアント端末３ａとが暗号化及び復号化ロジックの交換を行うようにしているが、ＦＤやＣＤ、ＵＤＢメモリ等のリムーバブルメディアを用いて予め通信相手同士で暗号化及び復号化のための取決めロジックを交換しておくこともできることは言うまでもない。
【００４６】
次に、図３に基づいて、本発明の第２の実施形態であるＴＣＰ２の中のＵＤＰｓｅｃの暗号化方式を用いた暗号化通信について説明する。図３は、ネットワーク２０に接続された放送アプリケーション用のクライアント端末４ａ、４ｂ、４ｃが、いわゆるルータ又はゲートウエイのようなネットワーク制御機器２を介して別のネットワーク３０に接続されたホストコンピュータ（いわゆるサーバとして機能する通信装置）１と通信する通信システムの全体構成を示す図である。
【００４７】
図３は、クライアント端末４ａ、４ｂ、４ｃ及びホストコンピュータ１のプロトコルスタックを示しているが、ＴＣＰ２をサポートしているクライアント端末は４ａと４ｂである。つまり端末４ａと４ｂだけがＵＤＰｓｅｃを備えている。各クライアント端末のソケット（socket）の上層には、放送用のアプリケーションソフトウエアが実装されている。また、ネットワーク３０に接続されたホストコンピュータ１もＴＣＰ２を搭載しており、そのソケット１７の上層に放送アプリケーションソフトウエア１９が実装されている。図３のホストコンピュータ１も図２のホストコンピュータ１と同様に、図１のプロトコルスタックの構造であるＴＣＰ２を構成するソフトウエアは全て搭載している。
【００４８】
ホストコンピュータ１が保有するプロトコルスタックは、図２のホストコンピュータ１のプロトコルスタックと略同じであるが、図２のホストコンピュータ１のプロトコルスタックと異なる点は、ＴＣＰエミュレータの代わりにＵＤＰエミュレータ１６がある点である。これは放送アプリケーションソフトでは画像等の大量のデータが取り扱われるため、データ伝送のような誤り補償よりも、高速性が重視されるためである。
【００４９】
ネットワーク２０に接続されたクライアント端末４ａ、４ｂ、４ｃとネットワーク３０に接続されるホストコンピュータ１を介在するネットワーク制御機器２のプロトコルスタックは、ＮＩＣドライバ、ＡＲＰ、ＩＰがスタックとして積み上げられたファームウエア（不揮発メモリ付電子回路）により構成されている。
【００５０】
また、クライアント端末４ａは、本発明のＴＣＰ２をサポートする端末であるが、ここではＵＤＰｓｅｃにのみ対応した通信装置を備えた端末であり、クライアント端末４ｂは、本発明のＵＤＰｓｅｃ及び公知のＩＰｓｅｃに対応した通信装置であり、クライアント端末４ｃは公知のＩＰｓｅｃにのみ対応した通信装置である。このクライアント端末４ｃは本発明のＴＣＰ２をサポートしていない。これらのクライアント端末４ａ〜４ｃには、図２のクライアント端末３ａ〜３ｃと同様に、ネットワークを通して又はＣＤ−ＲＯＭのような記録媒体を介して事前に配布されるプロトコルドライバソフトウエアが実装されている。
【００５１】
また、特に「データ漏洩」防止のための暗号化・復号化ロジック及び「データ改竄」防止のための認証情報付加・認証ロジックについては、ホストコンピュータ１とクライアント端末４ａ、４ｂ、４ｃの間で対応している必要がある。公知のいわゆるＩＰｓｅｃと同様のポリシーで取決めを行うこともできるが、本発明の第２の実施形態においては、事前にプロトコルドライバソフトウエア自体を配布しているので、より簡潔な独自のプロトコルにより秘密鍵等を取り決めたり、より簡易な構造のパケットを使用したりすることもできる。また、公知の暗号化・復号化及び認証アルゴリズムでなく、独自で作成した暗号化・復号化及び認証アルゴリズム（ロジック）自体をプロトコルドライバのソフトウエアモジュール等として組み込むこともできる。
【００５２】
なお、クライアント端末４ｃは、ＴＣＰ２を実装していないが、インターネットで利用される公知のＩＰｓｅｃを実装しているため、これによってある程度セキュアな通信をすることができる。しかし、クライアント４ａと４ｂは、対象とする放送アプリケーションのパフォーマンスないしセキュリティポリシーの都合上、ＩＰｓｅｃではなく本発明によるＴＣＰ２の構成要素であるＵＤＰｓｅｃを実装して使用している。ＩＰｓｅｃではなくＵＤＰｓｅｃを利用する理由は、例えば、ＵＤＰポート番号部分（ＩＰペイロードに属する）をＩＰｓｅｃで暗号化することによるパフォーマンスの低下など、ＩＰｓｅｃ自体に脆弱さがあるからである。
【００５３】
また、通信相手が正しいものかどうかを判断する相手認証プロトコルを、本発明のＴＣＰ２のＴＣＰ又はＵＤＰプロトコルスタック、つまりＴＣＰｓｅｃ又はＵＤＰｓｅｃに埋め込むことにより、通信相手相互間で上位アプリケーションを意識することなく、通信相手認証機能を実施することができる。この場合、コスト増にならない範囲で実質的に通信パケット数やパケット長等を増やすこともできる。
【００５４】
また、特に、ネットワーク内で不特定多数の相手に向かってデータを送信するブロードキャスト機能を実施するに際して、本発明による暗号化方式であるＵＤＰｓｅｃを利用する場合には、ブロードキャストを受けるクライアント端末３ａ、３ｂがネゴシエーション（取り決め）を開始し、通信相手認証や通信用秘密鍵を得る。そして、クライアント端末３ａや３ｂは、通信相手の認証を行って通信用の秘密鍵を取得するまでは、ホストコンピュータ１からのＵＤＰｓｅｃによる配信データを復号化することができない。
【００５５】
次に、図４に基づいて、本発明の第１及び第２の実施形態の通信で送受信されるパケット構造と、その暗号化範囲及び完全性認証の適用範囲について説明する。
図４（ａ）はＴＣＰｓｅｃ／ＩＰｓｅｃのパケット構造と各暗号化範囲と完全性認証の適応範囲を示し、図４（ｂ）（ｃ）はそれぞれＴＣＰｓｅｃ／ＩＰ、ＵＤＰｓｅｃ／ＩＰのパケット構造と各暗号化範囲及び完全性認証の適用範囲を示したものである。
【００５６】
図４（ａ）に示すように、ＴＣＰｓｅｃ／ＩＰｓｅｃのパケット構造は、ＩＰヘッダ４１のすぐ後に、ＩＰｓｅｃのＥＳＰヘッダ４２が続いている。続いてＴＣＰヘッダ４３とＴＣＰｓｅｃの付加情報４４が設けられ、その後にアプリケーションデータ４５が続く構造になっている。そして、アプリケーションデータ４５の後には、ブロック暗号で発生するデータのブランクやそのブランクの長さ、次のヘッダの番号などの暗号データをサポートする情報であるＴＣＰｓｅｃ付加トレーラ４６が配列され、その後にＴＣＰｓｅｃの付加認証データ４７が配列される。そして、さらにその後にＩＰのためのＥＳＰトレーラ４８とＥＳＰ認証データ４９が配列されるパケット構造になっている。
【００５７】
このうち番号４１、４２、４８、４９で示される部分はＩＰｓｅｃ用の情報であり、番号４３、４４、４６、４７が本発明によるＴＣＰ２の中心的な役割を果たすＴＣＰｓｅｃに関連する情報である。なお、ここではＴＣＰｓｅｃもＩＰｓｅｃに準じた配列としたが、採用する暗号化や認証のアルゴリズムによっては、ＴＣＰｓｅｃの付加情報４４と付加トレーラ４６を省略したり、ＴＣＰｓｅｃの付加認証データ４７を削減したりしても利用可能である。
【００５８】
図４（ａ）に示すＴＣＰ２のパケット構造においては、ＴＣＰｓｅｃとＩＰｓｅｃの二つの方式で暗号化が行われる。この場合、まず送信側では、ＴＣＰｓｅｃ側を最初に暗号化して、ＴＣＰｓｅｃ認証データを付加する。次に、ＩＰｓｅｃを暗号化し、ＩＰｓｅｃ認証データを付加している。そして、受信側では、まず、ＩＰｓｅｃを復号化して、ＩＰｓｅｃ認証データにより受信パケットのデータを検証し、続いてＴＣＰｓｅｃ側を復号化して、ＴＣＰｓｅｃ認証データで受信パケットのデータを検証する。
【００５９】
このように、図４（ａ）に示すようなパケット構造を有するデータでは、ＩＰｓｅｃとＴＣＰｓｅｃの二種類の暗号アルゴリズムを用いて暗号化し、さらに完全性認証を行うので、ＩＰｓｅｃのみと比べて外部からの侵入等にたいして格段に強固な暗号化通信システムを確立することができる。ＴＣＰｓｅｃにより暗号化される範囲は、アプリケーションデータ４５、ＴＣＰｓｅｃ付加トレーラ４６の部分であり、ＴＣＰｓｅｃによる認証範囲としては上記暗号化範囲にさらにＴＣＰｓｅｃ付加情報４４が加えられる。なお、従来のＩＰｓｅｃで暗号化される暗号化範囲は、ＴＣＰヘッダ４３からＥＳＰトレーラ４８までの部分であり、その認証範囲は、ＥＳＰヘッダ４２からＥＳＰトレーラ４８までの範囲となる。
【００６０】
図４（ｂ）は、ＴＣＰｓｅｃ／ＩＰのパケット構造を示しており、図４（ａ）と異なり、ＩＰヘッダ４１のすぐ後に、ＴＣＰヘッダ４３及びＴＣＰｓｅｃ付加情報４４が続き、更にアプリケーションデータ４５が続く構造になっている。そして、アプリケーションデータ４５の後には、ブロック暗号で発生するデータのブランクやそのブランクの長さ、次のヘッダの番号などの暗号データをサポートする情報であるＴＣＰｓｅｃの付加トレーラ４６とＴＣＰｓｅｃの付加認証データ４７が配列される構造となっている。
【００６１】
ここで、番号４３、４４、４６、４７がＴＣＰｓｅｃに特徴的な情報となる。ただし、上述したようにこれらの情報は、採用する暗号化／認証アルゴリズムによっては、ＴＣＰｓｅｃ／ＩＰの使用していないヘッダフィールド部分などに分散したり、個々のパケットからは逆算・推測できない独立した事前取決め（ネゴシエーション）により省略したりできるものである。また、ＩＰ層の上層に当たるＴＣＰ及びＩＰを使用していないプロトコルフィールドを用いて、図４（ｂ）に示すようなＴＣＰｓｅｃ／ＩＰパケットを構成することにより、より下層のＩＰのみに着目したＩＰｓｅｃパケットよりもパケット長を簡単に削減することができるようになる。なお、ここで暗号化範囲は、図示の通り、アプリケーションデータ４５、ＴＣＰｓｅｃ付加トレーラ４６であり、認証範囲は上記暗号化範囲の他に、ＴＣＰｓｅｃの付加情報４４が加えられる。
【００６２】
図４（ｃ）は、本発明におけるＵＤＰｓｅｃ／ＩＰのパケット構造を示すものであり、ＵＤＰｓｅｃ付加情報４４ａ、ＵＤＰｓｅｃ付加トレーラ４６ａ及びＵＤＰｓｅｃ付加認証データ４７ａがＵＤＰｓｅｃをサポートするために必要な情報となる。この暗号化範囲は、図示の通り、アプリケーションデータ４５ａ、ＵＤＰｓｅｃ付加トレーラ４６ａであり、認証範囲は上記暗号化範囲の他に、ＵＤＰｓｅｃ付加情報４４ａが加えられる。
【００６３】
次に、本発明の第１の実施の形態であるＴＣＰｓｅｃを用いた暗号化処理システムの動作を図５〜図６、図８〜図１４に示す流れ図、及び図７に示すシーケンス図に基づいて説明する。
【００６４】
図５は、ＴＣＰ、並びに、ＴＣＰｓｅｃのパッシブオープン（図７のホストＢに相当する接続待ちのオープンであり、例えば、Ｗｅｂサーバが、この状態でオープンする。）における処理の流れ図であり、上位アプリケーション・プログラムで、接続待ちオープンした場合に、このＴＣＰ／ＴＣＰｓｅｃパッシブオープン処理がスタートする（ステップＳ１）。なお、この部分は、図７でいうとホストＢ側の処理がこれに相当する。
【００６５】
まず、最初に、オープンするポート番号の解析が行われる（ステップＳ２）。この解析では、例えば、Ｗｅｂサーバの場合は、ＴＣＰポートの８０番を使用して、その定義状態を確認する。そして次にこのポート番号８０が、ＴＣＰｓｅｃのパッシブオープンが許可されているかどうかを判定する（ステップＳ３）。ステップＳ３においてＴＣＰｓｅｃのパッシブオープンが許可されていない場合は、今度はＴＣＰパッシブオープンが許可されているかどうかが判断される（ステップＳ４）。判断ステップＳ４でＴＣＰパッシブオープンも許可されていない場合は、ＴＣＰｓｅｃもＴＣＰも許可されていないことになり、ＴＣＰ／ＴＣＰｓｅｃパッシブオープンは失敗となり、処理を中断する（ステップＳ７）。
【００６６】
判断ステップＳ４でＴＣＰパッシブオープンが許可されている場合、すなわちＴＣＰｓｅｃパッシブオープンは許可されていないがＴＣＰパッシブオープンは許可されているときは、後述する図８に示すＴＣＰパッシブオープン処理が実行される（ステップＳ５）。
判断ステップＳ３で、ＴＣＰｓｅｃのパッシブオープンの許可状態が確認された場合は、同じく後述する図９に示すＴＣＰｓｅｃのパッシブオープン処理が実行される（ステップＳ６）。
【００６７】
ステップＳ５又はステップＳ６におけるＴＣＰパッシブオープン処理又はＴＣＰｓｅｃのパッシブオープン処理が終了するとＴＣＰ／ＴＣＰｓｅｃパッシブオープン処理を終了する（ステップＳ７）。このように、本例では、上位であるアプリケーションからは、ＴＣＰでパッシブオープンを行っているが、ＴＣＰ２の判断により、ＴＣＰｓｅｃがサポートされていればＴＣＰｓｅｃで通信を行い、ＴＣＰｓｅｃがサポートされていなければＴＣＰで通信することとなる。
【００６８】
次に、図６に基づいて本発明のＴＣＰ並びにＴＣＰｓｅｃのアクティブオープン処理について説明する。ＴＣＰ／ＴＣＰｓｅｃのアクティブオープンとは、接続要求のオープンであり、例えば、Ｗｅｂブラウザを実装するクライアント端末が、この状態でオープンすることになる。図７でいうとホストＡ側の処理がこれに相当する。図６は、このアクティブオープンにおける処理の流れ図であり、上位アプリケーション・プログラムにおいて接続要求オープンがなされた場合に、このＴＣＰ／ＴＣＰｓｅｃのアクティブオープン処理が開始される（ステップＳ８）。
【００６９】
まず、最初に、オープンするポート番号の解析がなされる（ステップＳ９）。この解析は、例えば、Ｗｅｂブラウザを実装するクライアント端末アプリケーションが、ＴＣＰポートの３０００番を使おうとした場合は、ＴＣＰポートの３０００番の定義状態を確認する。
【００７０】
次にこのポート番号３０００に対してＴＣＰｓｅｃのアクティブオープンが許可されているかどうかが判断される（ステップＳ１０）。ステップＳ１０においてＴＣＰｓｅｃのアクティブオープンが許可されていないと判定された場合は、続いてＴＣＰアクティブオープンが許可されているかどうかが判断される（ステップＳ１１）。判断ステップＳ１１でＴＣＰアクティブオープンも許可されていない場合は、ＴＣＰｓｅｃ、ＴＣＰのいずれのアクティブオープンも許可されていないことになり、ＴＣＰ／ＴＣＰｓｅｃアクティブは失敗となり、接続処理は中断される（ステップＳ１４）。
【００７１】
判断ステップＳ１１でＴＣＰアクティブオープンが許可されている場合、すなわちＴＣＰｓｅｃアクティブオープンは許可されていないがＴＣＰアクティブオープンは許可されているときは、後述する図１０に示すＴＣＰアクティブオープン処理が実行される（ステップＳ１２）。
【００７２】
判断ステップＳ１０で、ＴＣＰｓｅｃのアクティブオープンの許可状態が確認された場合は、後述する図１１に示すＴＣＰｓｅｃのアクティブオープン処理が実行される（ステップＳ１３）。ステップＳ１２又はステップＳ１３におけるＴＣＰｓｅｃアクティブオープン処理又はＴＣＰｓｅｃのアクティブオープン処理が終了するとＴＣＰ／ＴＣＰｓｅｃアクティブオープン処理が終わる（ステップＳ１４）。ＴＣＰ／ＴＣＰｓｅｃアクティブオープンの場合も、ＴＣＰ／ＴＣＰｓｅｃパッシブオープン（図５）の場合と同様に、上位であるアプリケーションからは、ＴＣＰでアクティブブオープンを行っているが、ＴＣＰ２の判断により、ＴＣＰｓｅｃがサポートされていればＴＣＰｓｅｃで通信を行い、ＴＣＰｓｅｃがサポートされていなければＴＣＰで通信することとなる。
【００７３】
次に、図７に基づいてアクティブオープン側のホストＡとパッシブオープン側のホストＢ間のシーケンス処理について、本発明のＴＣＰｓｅｃを使った通信の処理を説明する。
【００７４】
図７は、本発明の暗号処理プロトコルであるＴＣＰｓｅｃを用いたときの接続シーケンス、データ通信シーケンス及び切断シーケンスを、標準のＴＣＰと比較して示したものである。図７（ａ）は標準ＴＣＰ，図７（ｂ）は本発明のＴＣＰｓｅｃを用いた時の通信のシーケンスを示した図である。
図７（ａ）に示すように、標準のＴＣＰは、ホストＢのアプリケーションがＴＣＰパッシブオープンし、ホストＡのアプリケーションがＴＣＰアクティブオープンしている。
【００７５】
ホストＢのアプリケーションがＴＣＰパッシブオープンをすると、ＴＣＰパッシブオープン処理（図５のステップ５及び図８参照）を開始し、後述する図８のステップＳ１５に示すように受信待ちとなる。ホストＡのアプリケーションがＴＣＰアクティブオープンをすると、ＴＣＰアクティブオープン処理（図６のステップＳ１２及び図１０参照）を開始し、後述する図１０のステップＳ５２に示すようにホストＡからホストＢに対して接続要求（ＳＹＮ）が送信される。これにより、標準ＴＣＰの接続シーケンスが開始状態となる。
【００７６】
ホストＢ側では、この接続要求（ＳＹＮ）を受信するとこの接続要求の受信パケットの解析を終了し、ホストＡ側に接続応答（ＳＹＮ・ＡＣＫ）を送信する。ここでＡＣＫとは、Acknowledgementの略であり、データ転送が正常に終了したときなどに送信されるものである。ホストＡ側は、この接続応答（ＳＹＮ・ＡＣＫ）を受信すると、接続が完了した旨のＡＣＫ（肯定応答）を送信し、標準ＴＣＰの接続シーケンスを終了する。
【００７７】
この標準ＴＣＰの接続シーケンスを終了すると、標準ＴＣＰによるデータ通信シーケンスが有効となり、ホストＡ側、又は、ホストＢ側の何れかがデータを送信後、データを受信した側からＡＣＫ（肯定応答）を返すという基本パターンを繰り返してデータの送受信が行われる。
【００７８】
この標準ＴＣＰのデータ通信シーケンスでは、ホストＡ又はホストＢの何れかが、相手に対して切断要求をすることができる。
図７（ａ）では、アクティブオープン側のホストＡからパッシブオープン側のホストＢに対して切断要求が送信された場合を示している。ホストＡのアプリケーションから切断要求があると、ホストＡは、切断要求（ＦＩＮ）を送信する。ホストＢは、この切断要求（ＦＩＮ）を受信すると、後述する図８のステップＳ２３に示すように切断応答（ＦＩＮ・ＡＣＫ）を送信する。ホストＡは、この切断応答（ＦＩＮ・ＡＣＫ）を受信すると、ＡＣＫ（肯定応答）を送信し、標準ＴＣＰの切断シーケンスを終了する。
【００７９】
次に、本発明のＴＣＰｓｅｃによる通信のシーケンスを図７（ｂ）に基づいて説明する。図７（ｂ）では、ホストＢのアプリケーションがＴＣＰｓｅｃパッシブオープンし、ホストＡのアプリケーションがＴＣＰｓｅｃアクティブオープンしている。
ホストＢのアプリケーションがＴＣＰｓｅｃパッシブオープンをすると、ＴＣＰｓｅｃパッシブオープン処理（図５のステップＳ６及び図９を参照）を開始し、後述する図９のステップＳ３１に示すように受信待ちとなる。ホストＡのアプリケーションがＴＣＰｓｅｃアクティブオープンをすると、ＴＣＰｓｅｃアクティブオープン処理（図６のステップＳ１３及び図１１を参照）を開始し、図１１のステップＳ７０に示すようにホストＡからホストＢに対して接続要求（ＳＹＮ）が送信される。これにより、ＴＣＰｓｅｃの接続シーケンスが開始状態となる。
【００８０】
ホストＢ側では、ホストＡから送信された接続要求（ＳＹＮ）を受信すると、この接続要求の受信パケットの解析を終了し、ホストＡに対して接続応答（ＳＹＮ・ＡＣＫ）を送信する。そして、ホストＡ側は、このホストＢからの接続応答（ＳＹＮ・ＡＣＫ）を受信するとＡＣＫ（肯定応答）を送信し、ＴＣＰｓｅｃの接続シーケンスを終了する。
【００８１】
この接続シーケンスが終了すると、ＴＣＰｓｅｃ接続シーケンスが有効となり、ホストＡとホストＢの間で、ＴＣＰｓｅｃネゴシエーションデータに含まれているＴＣＰ２の固有情報を交換し、正しい相手であることを相手に通知する。すなわち、ホストＡとホストＢの間で、次のＴＣＰｓｅｃネゴシエーションデータを交換する以前に相手方端末がＴＣＰ２をサポートする端末であるか、言い換えると通信する正しい相手であるか否かを確認することができる。続いて、ホストＡとホストＢの間でＴＣＰｓｅｃネゴシエーションデータを交換し、ＴＣＰｓｅｃ接続シーケンスを終了する。
【００８２】
このＴＣＰｓｅｃのＴＣＰｓｅｃ接続シーケンスが終了すると、ＴＣＰｓｅｃのデータ通信シーケンスが有効となり、ホストＡ側又はホストＢ側の何れかがデータを送信後、データを受信した側からＡＣＫ（肯定応答）を返す基本パターンを繰り返してデータの送受信が行われる。なお、このデータは、すべて暗号データであることは言うまでもない。
【００８３】
なお、ＴＣＰｓｅｃのデータ通信シーケンスでは、ホストＡ又はホストＢの何れかが相手方に対して切断要求をすることができる。図７（ｂ）では、アクティブオープン側のホストＡから切断を開始している。ホストＡのアプリケーションから切断要求があると、ホストＡは切断要求（ＦＩＮ）を送信する。ホストＢは、この切断要求（ＦＩＮ）を受信すると、後述する図９のステップＳ４２に示すように切断応答（ＦＩＮ・ＡＣＫ）を送信する。ホストＡは、この切断応答（ＦＩＮ・ＡＣＫ）を受信すると、ＡＣＫ（肯定応答）を送信し、ＴＣＰｓｅｃの切断シーケンスを終了する。
【００８４】
以上、図７に基づいて、標準ＴＣＰと本発明のＴＣＰ２のひとつであるＴＣＰｓｅｃについて通信の接続から切断までのシーケンスを説明したが、以下、ＴＣＰ及びＴＣＰｓｅｃのパッシブオープン処理、及びアクティブオープン処理について流れ図に従って順に説明する。
【００８５】
まず、図５の流れ図のステップＳ５において、ＴＣＰパッシブオープン処理がスタートした場合の詳細について図８の流れ図に基づいて説明する。
図５のステップＳ５で処理するプロトコルがＴＣＰと決定した場合に、この図８のＴＣＰパッシブオープン処理がスタートする。最初に、受信待ちをして、受信した受信パケットの解析を行う（ステップＳ１５）。続いてこの受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンであるかどうかを判断する（ステップＳ１６）。そしてステップＳ１６の判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ１７）、次のパケットの受信を待つ。
【００８６】
判断ステップＳ１６において、受信パケットが正しいＴＣＰパケットであると判断された場合は、続いて接続中か否か、つまり図７のホストＡとホストＢの接続シーケンスが完了しているかどうかが判断される（ステップＳ１８）。判断ステップＳ１８において、接続中であると判定された場合は、次にパケットが切断要求（図７（ａ）のＦＩＮ）であるか否かが判断される（ステップＳ１９）。切断要求でなければ、続いて切断応答（図７（ａ）のＦＩＮ／ＡＣＫ）であるか否かが判断される（ステップＳ２０）。切断要求でもなく、切断応答でもない場合には、ＴＣＰデータの送受信処理が行われ（ステップＳ２１）、受信パケットが切断応答である場合は、図７のホストＡからＡＣＫが送信され、ＴＣＰ接続が切断される（ステップＳ２５）。判断ステップＳ１９でホストＡからの切断要求であると判断されると、これに対する切断応答がホストＢから送信される（ステップＳ２３）。
【００８７】
ステップＳ２３で切断応答が送信された場合には、最終のＡＣＫを待つ（ステップＳ２４）。そして、最終ＡＣＫを受信した後にＴＣＰを切断状態にして（ステップＳ２５）、ＴＣＰパッシブオープンを終了する（ステップＳ２６）。
判断ステップＳ１８において、受信ポートが接続中でないとされた場合には、受信したパケットがパッシブオープン許可ポートであるか否かが判定される（ステップＳ２７）。そして受信パケットが許可されていない場合は、受信パケットを廃棄して（ステップＳ２８）次のパケットを待つ。また、判断ステップＳ２７において、受信パケットがパッシブオープン許可になっているとされた場合は、次にパケットが接続要求であるか否かが判断され（ステップＳ２９）、接続要求でない場合は、パケットを廃棄して（ステップＳ２８）次のパケットを待つ。また、判断ステップＳ２９で接続要求であると判断された場合には、接続応答を送信し、ＴＣＰを接続状態とする（ステップＳ３０）。
【００８８】
次に、図５のＴＣＰｓｅｃのパッシブオープンにおける処理ステップＳ６の詳細について、図９の流れ図に基づいて説明する。この処理は、図５のステップＳ６に示されるように、受信パケットの処理がＴＣＰｓｅｃの処理であると決定された場合の処理である。最初に、受信待ちをして、受信した受信パケットの解析がなされる（ステップＳ３１）。続いてこの受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかが判断される（ステップＳ３２）。このステップＳ３２の判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ３３）、ステップＳ３１に戻り、次のパケットの受信を待つ。
【００８９】
判断ステップＳ３２において、受信パケットが正しいパケットであると判断された場合は、続いてホストＡとホストＢの接続が完了しているかどうか（接続中かどうか）が判断される（ステップＳ３４）。判断ステップＳ３４において、ホストＡとホストＢが接続中であると判定された場合は、次に受信したパケットが切断要求（ＦＩＮ）であるのか否かが判断される（ステップＳ３５）。切断要求でなければ、今度は受信したパケットが切断応答（ＦＩＮ・ＡＣＫ）であるか否かが判断される（ステップＳ３６）。そして、受信したパケットが切断要求でもなく、切断応答でもないということであれば、後述する図１２に示されるＴＣＰｓｅｃデータの送受信処理が行われ（ステップＳ３７）、ステップＳ４９に進む。次に、判断ステップＳ３６で切断応答があった場合には、ＡＣＫを送信して（ステップＳ３８）、ホストＡとホストＢ間のＴＣＰｓｅｃを切断する（ステップＳ４１）。また、判断ステップＳ３５において、受信パケットが切断要求（ＦＩＮ）であると判断された場合は、切断応答（ＦＩＮ・ＡＣＫ）の送信が行われる（ステップＳ３９）。ステップＳ３９で切断応答が送信された場合には、相手方からの最終のＡＣＫを待ち（ステップＳ４０）、この最終ＡＣＫを受信するとＴＣＰｓｅｃを切断状態にして（ステップＳ４１）、ＴＣＰｓｅｃパッシブオープンを終了する（ステップＳ４２）。
【００９０】
判断ステップＳ３４において、ホストＡとホストＢが接続中でないと判断された場合には、受信したパケットがパッシブオープンの許可ポートであるか否かが判断される（ステップＳ４３）。そして受信パケットがパッシブオープンの許可ポートではない場合は、受信パケットを廃棄して（ステップＳ４４）、ステップＳ３１に戻り次のパケットを待つ。また、判断ステップＳ４３おいて、受信パケットがパッシブオープン許可ポートになっているとされた場合は、後述する図１３に示すＴＣＰｓｅｃパッシブ接続処理が実行される（ステップＳ４５）。
【００９１】
続いて、共通鍵と認証データに基づいて通信相手が正常、つまり正当な権限を持った相手であるか否かが判断される（ステップＳ４６）。正常な相手であると判断されれば、ステップＳ３１に戻り、次の受信パケットを待つが、通信相手が正常の相手ではないと判断されると、ＴＣＰｓｅｃの接続を強制切断し（ステップＳ４７）、ＴＣＰｓｅｃのパッシブオープンの処理を終了する（ステップＳ４８）。
【００９２】
次に、図６のステップＳ１２に示す、ＴＣＰアクティブオープンの処理について図１０の流れ図に基づいて説明する。
図１０は、図６における処理するプロトコルがＴＣＰであると決定した場合の処理を示す図であり、最初に、送信側ホストＡから受信側ホストＢに対して接続要求（ＳＹＮ）が送信される（ステップＳ５０）。この接続要求に対して受信側ホストＢから接続応答（ＳＹＮ・ＡＣＫ）が送信されると、次に受信待ちをし、受信したパケットの解析が行われる（ステップＳ５１）。次に、この受信したパケットが正しいパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ５２）。このステップＳ５２における判断の結果、不正パケットであると判定された場合にはその受信パケットを廃棄し（ステップＳ５３）、ステップＳ５１に戻り、次のパケットの受信を待つ。
【００９３】
判断ステップＳ５２において、受信パケットが正しいパケットであると判断された場合は、続いて送信側（アクティブ側）ホストＡと受信側（パッシブ側）ホストＢが、接続中かどうかが判断される（ステップＳ５４）。この判断ステップＳ５４において、接続中であると判定された場合は、次に受信パケットが送信側ホストＡから受信側ホストＢに対しての切断要求であるか否かが判断される（ステップＳ５５）。これが切断要求でなければ、今度は受信側ホストＢから送信側ホストＡに対する切断応答（ＦＩＮ・ＡＣＫ）であるか否かが判断される（ステップＳ５６）。切断要求でもなく切断応答でもないということになれば、ＴＣＰデータの送受信処理が行われ（ステップＳ５７）、次の受信パケットを待つ。判断ステップＳ５６でホストＢからホストＡへの切断応答であると判断されると、ホストＡは切断を肯定するＡＣＫを送信し（ステップＳ５８）、ＴＣＰを切断する（ステップＳ６１）。
【００９４】
判断ステップＳ５５において、受信したパケットが切断要求である場合は、ホストＢからホストＡに対して切断応答が送信され（ステップＳ５９）、ホストＢはホストＡからの最終のＡＣＫの受信を待つ（ステップＳ６０）。そして、ホストＢがホストＡから最終ＡＣＫを受信した後にＴＣＰを切断状態にして（ステップＳ６１）、ＴＣＰアクティブオープンを終了する（ステップＳ６２）。
判断ステップＳ５４において、送信側ホストＡと受信側ホストＢが接続中でないとされた場合には、受信したパケットがアクティブオープン許可ポートであるか否かが判定される（ステップＳ６３）。そして受信パケットが許可されていない場合は、受信パケットを廃棄して（ステップＳ６４）次のパケットを待つ。また、判断ステップＳ６３において、受信パケットがアクティブオープン許可になっているとされた場合は、次に受信側ホストＢからの接続応答があったか否かが判断され（ステップＳ６５）、接続応答がなければ、パケットを廃棄して（ステップＳ６４）次のパケットを待ち、受信側ホストＢから接続応答がなされた場合には、ＴＣＰの接続状態として（ステップＳ６６）、ステップＳ５１に戻り、次の受信パケットを待つ。
【００９５】
次に、図６のステップＳ１３のＴＣＰｓｅｃアクティブオープンが開始された場合の詳細な処理について図１１の流れ図に基づいて説明する。
図１１の流れ図に示す処理は、図６のステップＳ１３で処理するプロトコルがＴＣＰｓｅｃであると決定した場合に開始されるものである。最初に、送信側ホストＡから受信側ホストＢに対して接続要求（ＳＹＮ）が送信される（ステップＳ７０）。これに対して、受信側ホストＢから接続応答（ＳＹＮ・ＡＣＫ）があってパケットの受信が開始され、受信したパケットの解析が行われる（ステップＳ７１）。
【００９６】
次に、受信パケットの解析の結果、受信したパケットが正しいＴＣＰのパケットであるか否か、すなわち、ＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないか否かが判断される（ステップＳ７２）。この結果、不正パケットであると判定された場合には、そのパケットを廃棄（ステップＳ７３）し、ステップＳ７１に戻り次のパケットを待つ。
【００９７】
判断ステップＳ７２において、受信したパケットが正しいＴＣＰパケットであると判定された場合は、次に送信側ホストＡと受信側ホストＢの接続が完了しているかどうか（接続中かどうか）が判断される（ステップＳ７４）。そしてホストＡとホストＢが接続中であれば、今度は受信したパケットが切断要求（ＦＩＮ）であるか否かが判断される（ステップＳ７５）。受信したパケットが切断要求ではないときは、次に受信側ホストＢから切断応答があるかどうかが判断される（ステップＳ７６）。切断要求もなく切断応答もない場合は、図１２に示すＴＣＰｓｅｃデータの送受信処理が行われ（ステップＳ７７）、その後ステップＳ８７に進む。
【００９８】
判断ステップＳ７６で切断応答があった場合には、送信側ホストＡから受信側ホストＢに対してＡＣＫを送信して（ステップＳ７８）、ホストＡとホストＢ間のＴＣＰｓｅｃを切断する（ステップＳ８１）。また、判断ステップＳ７５において、受信パケットが切断要求（ＦＩＮ）であると判断された場合は、切断応答（ＦＩＮ・ＡＣＫ）の送信が行われる（ステップＳ７９）。ステップＳ７９で切断応答が送信された場合には、相手方からの最終のＡＣＫを待ち（ステップＳ８０）、この最終ＡＣＫを受信するとＴＣＰｓｅｃを切断状態にして（ステップＳ８１）、ＴＣＰｓｅｃアクティブオープンを終了する（ステップＳ８２）。
【００９９】
判断ステップＳ７４において、送信側ホストＡと受信側ホストＢの接続が完了していない、つまり接続中でないとされた場合には、受信したパケットがアクティブオープン許可ポートであるか否かが判定される（ステップＳ８３）。そして受信されたパケットが許可されていない場合は、その受信パケットを廃棄して（ステップＳ８５）ステップＳ７１に戻り、次のパケットを待つ。また、判断ステップＳ８３において、受信パケットがアクティブオープン許可になっているとされた場合は、受信されるパケットが受信側ホストＢからの接続応答（ＳＹＮ・ＡＣＫ）のパケットであるか否かが判断され（ステップＳ８４）、接続応答のパケットでない場合は、パケットを廃棄して（ステップＳ８５）次のパケットを待ち、判断ステップＳ８４で接続応答のパケットであると判断された場合には、図１４でその詳細を示すＴＣＰｓｅｃアクティブ接続処理が行われる（ステップＳ８６）。
【０１００】
ステップＳ８６でＴＣＰｓｅｃのアクティブ接続処理がなされると、次に受信側のホストＢが正常な相手か否か、つまり接続を許可されている相手であるか否かが判断される（ステップＳ８７）。そして、接続が許されている相手であると判断されれば、ステップＳ７１に戻って次のパケットの受信を待ち、ステップＳ８７で接続が許可されていない相手であると判断されると、ＴＣＰｓｅｃによる送受信を強制的に切断して（ステップＳ８８）、ＴＣＰｓｅｃのアクティブオープンを終了する（ステップＳ８９）。
【０１０１】
次に、上述した図９ステップＳ３７及び図１１のステップＳ７６が選択された場合のＴＣＰｓｅｃデータの送受信処理の詳細について図１２の流れ図に基づいて説明する。
【０１０２】
まず、図９のステップＳ３７及び図１１のステップＳ７７でＴＣＰｓｅｃデータの送受信処理が開始すると、最初に、ホストＡの上位アプリケーションからの送信要求があるか否かが判断される（ステップＳ９０）。そして、ホストＡの上位アプリケーションから送信要求があった場合は、送信側ホストＡで送信データが暗号化され（ステップＳ９１）、それに認証データが付加されて（ステップＳ９２）、受信側ホストＢに暗号化され認証データが付加されたパケットが送信される（ステップＳ９３）。
【０１０３】
次に、受信側ホストＢで、受信データがあるか否かが判断され（ステップＳ９４）、受信データがある場合には、受信データの復号化が行われる（ステップＳ９５）。次に、この受信され復号化されたデータが正しいデータであるかどうかが判断される（ステップＳ９６）。この判断は、復号化したデータと受信された認証データとを確認することによって行われるが、復号データを確認した結果、正しいデータでないと判定された場合には、ＴＣＰ／ＴＣＰｓｅｃを強制的に切断する（ステップＳ９７）。この強制切断は、受信したデータを廃棄するとともに、送信側に切断要求をすることによって行われる。判断ステップＳ９６で、復号化したデータが正しいデータであると判定された場合には、受信データの取り込み、すなわち上位プロトコルスタックへのデータの配達が行われ（ステップＳ９８）、ＴＣＰｓｅｃのデータ送受信処理が完了する（ステップＳ９９）。
【０１０４】
次に、図９のステップＳ４５でＴＣＰｓｅｃパッシブ接続処理が開始された場合の詳細の処理を図１３の流れ図に基づいて説明する。
最初に、相手が正しい相手、つまり自コンピュータに接続する権限を持つコンピュータであるか否かを判断し（ステップＳ１００）、正しい相手でない場合にはＴＣＰｓｅｃの強制切断のための処理を実施する（ステップＳ１０１）。判断ステップＳ１００において接続相手が正しい相手であると判断されれば、受信側ホストＢから接続応答を送信する（ステップＳ１０２）。
【０１０５】
そして、接続応答を送信してきた相手の情報が自コンピュータ内にあるかどうかを確認する（ステップＳ１０３）。相手情報がコンピュータ内にない場合は、本システム、すなわちＴＣＰ２をインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１０４）。または、第三者認証のサーバから相手情報を取得してステップＳ１０５に進む。この取得する情報としては、相手側のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数を使用することができる。なお、サーバからの取得情報を既に自コンピュータが保有している場合であっても、有効期限若しくは有効使用回数を超えているような場合には、改めて取得動作を行う必要がある。
【０１０６】
次に、相手情報が正しい相手であるか否か、つまり、自分のコンピュータにアクセスすることを許容されている相手であるかどうかが判断される（ステップＳ１０５）。ここで、接続する相手が正しい相手であれば、ＴＣＰｓｅｃのパッシブ接続を完了する（ステップＳ１０６）が、正しい相手でない場合にはＴＣＰｓｅｃの強制切断を行って接続を中止する（ステップＳ１０１）。
【０１０７】
次に、図１１のステップＳ８６でＴＣＰｓｅｃのアクティブ接続処理が開始された場合の詳細の処理を図１４の流れ図に基づいて説明する。
図１３のパッシブ接続処理の場合と同様に、最初に、接続要求をしてきた相手が正しい相手であるどうか、つまり自コンピュータにアクセス権限を持っている相手からの通信であるかどうかを判断する（ステップＳ１１０）。正当なアクセス権限を持たない相手からの通信であれば、ＴＣＰｓｅｃのアクティブ接続を強制切断して終了する（ステップＳ１１１）。
【０１０８】
判断ステップＳ１１０で正しい相手であると判定されれば、送信側ホストから受信側ホストＢに対して肯定的な接続応答（ＡＣＫ）を送信する（ステップＳ１１２）。
次に、自コンピュータが相手側の情報を保有しているかどうかが判断される（ステップＳ１１３）。相手情報がコンピュータ内にない場合は、本システム、すなわちＴＣＰ２をインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１１４）。または、第三者認証のサーバから相手情報を取得してステップＳ１１５に進む。ここで、この取得する情報は、図１３ステップＳ１０４と同様に、相手側のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数とすることができる。なお、サーバからの取得情報を既に自コンピュータが保有していたとしても、有効期限若しくは有効使用回数を超えている場合には、改めて取得動作を行う必要がある。
【０１０９】
次に、相手情報が正しい相手であるか否か、つまり、自分のコンピュータにアクセスすることを許容されている相手であるかどうかが判断される（ステップＳ１１５）。接続する相手が正しい相手であれば、ＴＣＰｓｅｃのアクティブ接続を完了する（ステップＳ１１６）が、正しい相手でない場合にはＴＣＰｓｅｃの強制切断を行って接続を中止する（ステップＳ１１１）。
【０１１０】
以上、本発明のＴＣＰ２のうち、ＴＣＰ／ＴＣＰｓｅｃを用いたパッシブオープン及びアクティブオープンの通信処理について説明した。
次に、図３で示すような、本発明の第２の実施形態であるＵＤＰ／ＵＤＰｓｅｃを用いた通信システム及び通信方法について説明する。
【０１１１】
図１５は、本発明の第２の実施の形態に用いられるＵＤＰ／ＵＤＰｓｅｃのパッシブオープン処理について説明するための流れ図である。
この処理は、上位アプリケーション・プログラムにより開始される（ステップ１２０）。最初に、オープンするポート番号の解析、すなわちポート番号の定義状態が確認される（ステップ１２１）。次に、このポート番号がＵＤＰｓｅｃオープンになっているか否かが判断される（ステップＳ１２２）。ＵＤＰｓｅｃがオープンになっていない場合はＵＤＰがオープンになっているかどうかが判断される（ステップ１２３）。そして、ＵＤＰｓｅｃ、ＵＤＰが両方ともオープン許可になっていない場合は、ＵＤＰ／ＵＤＰｓｅｃは終了する（ステップＳ１２６）。判断ステップＳ１２３で、ＵＤＰがオープン許可になっている場合、つまりＵＤＰｓｅｃはオープン許可になっていないけれどもＵＤＰがオープン許可になっている場合は、図１８に示すＵＤＰオープン処理が実施される（ステップＳ１２４）また、判断ステップＳ１２２においてＵＤＰｓｅｃがオープンである場合は、ＵＤＰがオープンであるか否かにかかわらず、ＵＤＰｓｅｃのオープン処理が実施されて（ステップＳ１２５）、ＵＤＰ／ＵＤＰｓｅｃオープン処理は終了する（ステップＳ１２６）。なお、上位であるアプリケーションからは、ＵＤＰでオープンを行っていたとしても、ＴＣＰ２の判断により、ＵＤＰｓｅｃ若しくは、ＵＤＰで通信することも可能である。
【０１１２】
次に、本発明の第２実施の形態の１つであるＵＤＰ／ＵＤＰｓｅｃを用いたユニキャスト通信におけるシーケンス処理について図１６に基づいて説明する。
図１６は、標準のＵＤＰ、及び、本発明のＴＣＰ２の中のＵＤＰｓｅｃにおけるユニキャスト通信の開始シーケンス、データ通信シーケンスのパケット（ヘッダと、ペイロードで構成する）及び、その流れを説明した図である。
【０１１３】
図１６（ａ）が標準のＵＤＰを用いた通信シーケンスを示し、図１６（ｂ）は、ＵＤＰｓｅｃによる暗号化通信のシーケンスを示す。
図１６（ａ）の標準のＵＤＰは、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンしている例を示している。ホストＢのアプリケーションがＵＤＰオープンをすると、ＵＤＰオープン処理（図１５のステップＳ１２４及び図１８参照）を開始する。また、同様にホストＡのアプリケーションがＵＤＰオープンした場合も上記のＵＤＰオープン処理を開始する。これにより、ＵＤＰのデータ通信を行うことが可能となる。ここで図１６（ａ）に示すユニキャスト通信では、ホストＡ、ホストＢの何れからもデータの送信が可能である。
【０１１４】
次に、本発明のＴＣＰ２の暗号化方式の１つであるＵＤＰｓｅｃによる通信処理のシーケンスを説明する。
図１６（ｂ）は、本発明のＴＣＰ２が持つＵＤＰｓｅｃにより暗号化通信する場合の例であるが、この例は、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンし、ＴＣＰ２がＵＤＰｓｅｃでオープンと判断したケースである。
ホストＢがＵＤＰｓｅｃオープンをすると、ＵＤＰｓｅｃオープン処理（図１５のステップＳ１２５及び図１９を参照）が開始される。また、ホストＡがＵＤＰｓｅｃオープンした場合も同様にＵＤＰｓｅｃオープン処理が開始される。そして、ＵＤＰｓｅｃのデータ通信が実現可能となる。
【０１１５】
この図１６（ｂ）に示したＵＤＰｓｅｃを用いたユニキャスト通信においても、ＵＤＰのときと同様に、ホストＡ側又はホストＢ側の何れからもデータを送信することができる。図１６（ｂ）の場合、まず、ホストＡのアプリケーションからＵＤＰデータの送信要求があったとして説明する。アプリケーションからＵＤＰデータの送信要求を受け取ると、ホストＢは、ＵＤＰｓｅｃユニキャスト受信開始処理を開始し、ネゴシエーションを開始する。ネゴシエーションをして、相手が正しい相手であれば、ネゴシエーションを完了して、アプリケーションからＵＤＰデータの送信要求をＵＤＰｓｅｃデータ（暗号データ）として送信する。このＵＤＰｓｅｃユニキャスト通信では、データを受信した側からＡＣＫ（肯定応答）を返さない。このため、送達確認とデータの保証をする機能はないが、その分データの通信が高速になり、大容量の画像データなどの通信に適している。
【０１１６】
図１７は、標準ＵＤＰと本発明のＴＣＰ２の暗号化方式であるＵＤＰｓｅｃを用いたブロードキャスト通信の開始シーケンス、データ通信シーケンスのパケット（ヘッダと、ペイロードで構成する）及び、その流れを説明した図である。
図１７（ａ）が、標準のＵＤＰ、図１７（ｂ）が本発明のＴＣＰ２のＵＤＰｓｅｃによる通信のシーケンス図である。
【０１１７】
図１７（ａ）の標準のＵＤＰは、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンしている。そして、ホストＢのアプリケーションがＵＤＰオープンをすると、ＵＤＰオープン処理（図１５のステップＳ１２４及び図１８参照）を開始する。また、ホストＡのアプリケーションがＵＤＰオープンした場合も、同様にＵＤＰオープン処理を開始する。これにより、ＵＤＰのデータ通信を行うことができる状態となる。
【０１１８】
また、データはホストＡ、ホストＢの何れも発生することはできるが、図１７（ａ）では、ブロードキャスト通信ということもあって、ホストＡ側からホストＢ側に一方向的にデータが流れる図としている。データを受信したホストＢ側からＡＣＫ（肯定応答）を返さないため、送達確認とデータの保証をする機能は持たない。なお、データをブロードキャストする場合には、ＩＰアドレスのサブネットアドレスをオール１にすることで、データをブロードキャストすることが可能となる。
【０１１９】
次に、図１７（ｂ）のＵＤＰｓｅｃによる暗号化通信について説明する。この場合も、ホストＡ、ホストＢともにアプリケーションがＵＤＰオープンし、ＴＣＰ２がＵＤＰｓｅｃでオープンとしている。
ホストＢがＵＤＰｓｅｃオープンをすると、ＵＤＰｓｅｃオープン処理（図１５のステップＳ１２５及び図１９）を開始する。また、ホストＡがＵＤＰｓｅｃオープンしても同様に、ＵＤＰｓｅｃオープン処理を開始する。これにより、ＵＤＰｓｅｃのデータ通信を行うことができる状態となる。
【０１２０】
図１７（ｂ）示すように、ホストＡのアプリケーションからＵＤＰのブロードキャストデータ（ＩＰアドレスがブロードキャストを示しているデータ）の送信要求があった場合を説明する。アプリケーションからＵＤＰのブロードキャストデータの送信要求を受け取ると、ネゴをしないで、ＵＤＰｓｅｃで暗号データとして不特定ホストに配信する。ホストＢは、ブロードキャストデータを受け取ると、後述する図１９のステップＳ１４１のＵＤＰｓｅｃブロードキャスト受信開始処理を開始する。ホストＡとホストＢ間でネゴシエーションを開始し、相手が正しい相手であれば、ネゴシエーションを完了して、ブロードキャストデータを復号化して、アプリケーションへ送る。このとき、データを受信した側からＡＣＫ（肯定応答）を返さないため、送達確認とデータの保証をする機能はない。
【０１２１】
次に、図１８に基づいて、図１５のステップＳ１２４の標準ＵＤＰのオープン処理について説明する。
図１８は、ＵＤＰのオープン処理の流れ図であり、この処理は図１５のステップＳ１２４で、処理するプロトコルがＵＤＰと決定した場合に開始される処理である。
【０１２２】
最初に、アプリケーションからの送信要求、又は受信パケットを待ち、送信要求又はパケットを受信したときに、パケットの解析を行う（ステップＳ１３０）。ここで、受信パケットだけでなく送信要求も解析するのは、悪意を持った第三者が送信するホストＡ踏み台にして、ホストＡを加害者として不特定多数に通信することを防ぐためである。この送受信パケットの解析を行った後に、正しいパケットであるかどうか、つまりＤｏＳ攻撃におけるＵＤＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ１３１）。この判断ステップＳ１３１において、不正パケットであると判定された場合には、パケットを廃棄し（ステップＳ１３２）、次のパケットを待つ。
【０１２３】
判断ステップＳ１３１で正しいパケットであると判定された場合は、ＵＤＰデータの送受信処理が行われ（ステップＳ１３３）、続いて上位アプリケーションからＵＤＰのクローズ要求があったかどうかが判断される（ステップＳ１３４）。上位アプリケーションよりＵＤＰクローズ要求があった場合には、ＵＤＰオープン処理を終了する（ステップＳ１３５）。
【０１２４】
次に、図１９に基づいて、図１５のステップＳ１２５のＵＤＰｓｅｃのオープン処理について説明する。図１９は、ＵＤＰｓｅｃのオープンにおける処理の流れ図であり、図１５のステップＳ１２５に示すように、処理するプロトコルがＵＤＰｓｅｃと決定した場合にこの処理が開始される。
【０１２５】
最初に、アプリケーションからの送信要求又は受信パケットを待ち、送信要求又は受信したパケットの解析が行われる（ステップＳ１４０）。次に、上位アプリケーションからの送信要求あるいは送受信パケットが正しいＵＤＰパケットであるか否か、つまりＤｏＳ攻撃におけるＴＣＰプロトコル攻撃パターンでないかどうかを判断する（ステップＳ１４１）。判断ステップＳ１３４において正しいＵＤＰパケットではないと判断された場合は、パケットを廃棄し（ステップＳ１４２）、次のパケットを待つ。
【０１２６】
判断ステップＳ１４１において、正しいＵＤＰパケットであると判定された場合は、次にＵＤＰｓｅｃネゴシエーションがなされた受信パケットであるか否かが判断される（ステップＳ１４３）。
【０１２７】
そして、この結果、ＵＤＰｓｅｃのネゴシエーションパケットであると判断された場合は、後述する図２３で示すＵＤＰｓｅｃユニキャスト受信開始処理が行われ（ステップＳ１４４）、ステップＳ１５４へ進む。
また、判断ステップＳ１４３において、ＵＤＰｓｅｃのネゴシエーションパケットではないと判断されると、続いてブロードキャスト通信であるか否かを判断する（ステップＳ１４５）。そして、ブロードキャスト通信であると判定された場合は、通信の開始パケットであるか、つまりオープン後の最初の通信パケットであるか否かを判断し（ステップＳ１４６）、開始パケットでない場合は図２２で説明するＵＤＰｓｅｃデータ送受信処理を行う（ステップＳ１５１）。判断ステップＳ１４６において通信の開始パケットであると判定された場合は、次に送信パケットであるか否かが判断される（ステップＳ１４７）。そして、この結果、送信パケットであれば、上述したＵＤＰｓｅｃデータ送受信処理が行われる（ステップＳ１５１）が、送信パケットではないと判定された場合は、後述する図２０のＵＤＰｓｅｃブロードキャスト受信開始処理が実施される（ステップＳ１４８）。この受信開始処理の後で、送信されたパケットが正しい相手からのものであるかどうかを判断する（ステップＳ１４９）。そして、判断ステップＳ１４９で、送信されたパケットが正しい相手からのものではないと判断されると、パケットを廃棄し（ステップＳ１５０）、次のパケットを待つ。判断ステップＳ１４９で、正しい相手であると判定された場合には、図２２で示すＵＤＰｓｅｃデータ送受信処理が行われる（ステップＳ１５１）。
【０１２８】
また、判断ステップＳ１４５において、ブロードキャスト通信でない、すなわちユニキャスト通信であると判定された場合は、通信の開始パケット、すなわちオープン後の最初の通信パケットであるか否かが判断される（ステップＳ１５２）。この結果、開始パケットではないと判断された場合には、図２２で詳述するＵＤＰｓｅｃデータ送受信処理がなされる（ステップＳ１５１）。
【０１２９】
また、判断ステップＳ１５２で、オープン後の最初の通信パケットであると判断された場合は、図２１で後述するＵＤＰｓｅｃユニキャスト送信開始処理が行われる（ステップＳ１５３）。その後、通信の相手が、正しい相手であるかを判断し（ステップＳ１５４）、正しい相手である場合には、引き続きＵＤＰｓｅｃデータ送受信処理がなされ（ステップＳ１５１）、正しい相手ではないと判定された場合には、受信したパケットを廃棄し（ステップＳ１５５）、ステップＳ１４０に戻って次のパケットを待つ。
【０１３０】
次に、図１９のステップＳ１４８のＵＤＰｓｅｃブロードキャスト受信の開始における処理について、図２０に示す流れ図に基づいて説明する。
最初に、ブロードキャストを配信してきた相手の情報を自コンピュータが保有しているか否かを判断する（ステップＳ１６０）。そして、情報を保有していない場合には、本システムをインストールする際に使用した、インストールサーバから相手情報を取得する（ステップＳ１６１）。または、第三者認証のサーバから情報を取得する。この取得する情報は、相手のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数を使用する。次に、ブロードキャストを配信してきた相手が正しい相手であるかどうかを判断する（ステップＳ１６２）。そして、正しい相手であると判断されれば、ＵＤＰｓｅｃでの受信が可能であることになり、ＵＤＰｓｅｃブロードキャストの通信開始処理を終了し（ステップＳ１６４）、受信可能であることを図１９のステップＳ１４９へ指示する。判断ステップＳ１６２で正しい相手ではないとされた場合には、通信の拒否を行い（ステップＳ１６３）、データを取得しない旨を同じく図１９のステップＳ１４９へ指示する。なお、ステップＳ１６０で仮に相手方に関する取得情報があったとしても有効期限、若しくは、有効使用回数を超えている場合には、改めてステップＳ１６１で相手情報の取得動作を行ったほうがよい。
【０１３１】
次に、図１９のステップＳ１５３のＵＤＰｓｅｃユニキャスト送信開始処理について、図２１に示す流れ図に基づいて説明する。
最初に、送信する相手の情報を自コンピュータが保有しているか否かを確認する（ステップＳ１７０）。そして、情報を保有していない場合には、図２０のステップＳ１６１と同様な方法で相手情報を取得する（ステップＳ１７１）。この取得する情報も図２０の場合と同じである。
【０１３２】
次に、送信する相手が正しい相手であるかどうかを判断する（ステップＳ１７２）。そして、正しい相手であると判断されれば、ＵＤＰｓｅｃでの送信が可能であることになり、ＵＤＰｓｅｃユニキャストの通信開始処理を終了し（ステップＳ１７４）、送信可能であることを図１９のステップＳ１５４へ指示する。判断ステップＳ１７２で正しい相手ではないとされた場合には、通信の拒否を行い（ステップＳ１７３）、データを取得しない旨を図１９のステップＳ１５４へ指示する。
【０１３３】
次に、図２２に基づいて、図１９のステップＳ１５１に示すＵＤＰｓｅｃデータの送受信処理について説明する。
最初に、ホストＡのアプリケーションから送信要求があったか否かを判断する（ステップＳ１８０）。送信要求があれば送信側ホストＡにおいてデータを暗号化し（ステップＳ１８１）、この暗号化したデータに認証データを付加して（ステップＳ１８２）、受信側ホストＢに認証データが付加されたパケットを送信する（ステップＳ１８３）。
【０１３４】
次に、受信側ホストＢで、受信データがあるか否かが判断され（ステップＳ１８４）、受信データがある場合には、受信データの復号化が行われる（ステップＳ１８５）。次に、この受信され復号化されたデータが正しいデータであるかどうかが判断される（ステップＳ１８６）。この判断は、復号化したデータと受信された認証データとを確認することによって行われるが、復号データを確認した結果、正しいデータでないと判定された場合には、ＵＤＰ／ＵＤＰｓｅｃを強制的に切断する（ステップＳ１８７）。判断ステップＳ１８６で、復号化したデータが正しいデータであると判定された場合には、受信データの取り込み、すなわち上位プロトコルスタックへのデータの配達が行われ（ステップＳ１８８）、ＵＤＰｓｅｃのデータ送受信処理が完了する（ステップＳ１８９）。
【０１３５】
次に、図２３の流れ図に基づいて、図１９のステップＳ１４４に示すＵＤＰｓｅｃユニキャスト受信の開始処理について説明する。
最初に、ユニキャストで受信したパケットの相手情報を自コンピュータが保有しているか否かを判断する（ステップＳ１９０）。相手情報を持っていない場合には、本システムをインストールする際に使用した、インストールサーバあるいは第三者認証のサーバから相手情報を取得する（ステップＳ１９１）。取得する情報としては、図２０のステップＳ１６１あるいは図２１のステップＳ１７１と同じであり、相手のＴＣＰ２のＩＤ、ユーザＩＤ、パスワード、バイオメトリックス情報、機器固有情報、ＬＡＮ接続機器情報等の内、１つ、若しくは、複数がこれに相当する。
【０１３６】
次に、ユニキャストを送信してきた相手が正しい相手であるか否かを判断する（ステップＳ１９２）。正しい相手であると判定されれば、ＵＤＰｓｅｃでの受信が可能であることを図１９のステップＳ１５４へ伝えてＵＤＰｓｅｃブロードキャスト通信開始処理を終了する（ステップＳ１９４）。判断ステップＳ１９２で正しい相手ではないと判断された場合には、データを取得しない旨を図１９のステップＳ１５４へ伝え、通信を拒否する（ステップＳ１９３）。
【０１３７】
以上、本発明の第１の実施形態であるＴＣＰｓｅｃを用いた暗号化処理及び本発明の第２の実施形態であるＵＤＰｓｅｃを用いた暗号化処理について流れ図及びシーケンス図に基づいて詳しく説明した。
【０１３８】
次に、本発明のＴＣＰ２が、従来のＩＰｓｅｃあるいはＳＳＬと比べて如何に優位であるかという点について、図２４に基づいて説明する。
例えば、ＳＳＬでは対応が困難であった、クライアント−クライアント間の通信、ＴＣＰ／ＩＰプロトコルへのＤｏＳ攻撃、全てのＵＤＰポートあるいはＴＣＰポートのセキュアな通信、ソケットプログラムを変更しなければならなかったアプリケーションでの制限などに、ＴＣＰ２は完全に対応している。
【０１３９】
また、ＩＰｓｅｃでは対応が困難であった、エラーが多発する劣悪な環境下での通信、異なったＬＡＮ間での通信、複数キャリア経由の接続、ＰＰＰモバイル環境、ＡＤＳＬ環境での通信に対しても、ＴＣＰ２は完全にサポートしている。
さらに、モバイル環境下やＡＤＳＬ環境下でＶｏＩＰ（Voice over Internet Protocol）を使ったインターネットに対しても、本発明のＴＣＰ２により対応可能である。
【０１４０】
また、異なったＬＡＮ間や複数キャリアにまたがったＬＡＮ間でＶｏＩＰを使ったインターネット電話に対しても、ＩＰｓｅｃとＳＳＬでは対応不可能であったが、本発明のＴＣＰ２によれば完全に対応することができる。
【０１４１】
図２４は、ＴＣＰ２の優位性を説明するための図であるが、セキュリティのないプロトコルスタック（ａ）に、従来のＳＳＬを適用したケース（ｂ）と、ＩＰｓｅｃを適用したケース（ｃ）と、本発明のＴＣＰ２（ＴＣＰｓｅｃ／ＵＤＰｓｅｃ）を適用したケース（ｄ）を比較して示している。図２４（ｂ）のＳＳＬは既に述べたように、セッション層（第５層）のソケットに設けられているので、上位のアプリケーションに対する互換性がないのである。このため、ＳＳＬ自体、上述のような問題を抱えることになっている。また図２４（ｃ）のＩＰｓｅｃは、ネットワーク層（第３層）にあり、ＩＰ層での互換性がないため、ネットワークを構成する上で上述したような様々な制約を受けることになる。これに対して、図２４（ｄ）のＴＣＰ２（ＴＣＰｓｅｃ／ＵＤＰｓｅｃ）は、トランスポート層（第４層）に導入する暗号化技術であり、このためアプリケーションから見るとソケットをそのまま利用することができ、またネットワークから見るとＩＰもそのまま利用できるのでネットワークを構成する上での制約は受けない。
【０１４２】
以上のように、本発明のＴＣＰ２を用いた暗号化通信システム、暗号化通信方法は、既存の暗号化処理システムに比べても、特にデータの漏洩、改ざん、なりすまし、進入そして攻撃に対して極めて高いセキュリティ機能を有するものである。
なお、本発明は、以上説明した実施の形態に限定されるものではなく、特許請求項に記載した本発明の要旨を逸脱しない範囲において、さらに多くの実施形態を含むものであることは言うまでもない。
【図面の簡単な説明】
【０１４３】
【図１】本発明の通信システムに用いられるＴＣＰ２のプロトコルスタックを示す図である。
【図２】本発明のＴＣＰ２を用いた通信システムの第１の実施形態（ＴＣＰｓｅｃによるＥＣアプリケーション）におけるシステムの全体構成図である。
【図３】本発明のＴＣＰ２を用いた通信システムの第２の実施形態（ＵＤＰｓｅｃによる放送アプリケーション）におけるシステムの全体構成図である。
【図４】本発明のＴＣＰ２の中の３つのプロトコルスタックのパケット構造とその暗号化範囲及び認証範囲を示す図である。（ａ）、（ｂ）（ｃ）は、それぞれＴＣＰｓｅｃ／ＩＰｓｅｃ、ＴＣＰｓｅｃ／ＩＰ、ＵＤＰｓｅｃ／ＩＰのパケット構造、及び各暗号化範囲、完全性認証の適用範囲を示す図である。
【図５】本発明のＴＣＰ２の実施形態であるＴＣＰ／ＴＣＰｓｅｃパッシブオープンの処理を示す流れ図である。
【図６】本発明のＴＣＰ２の実施形態であるＴＣＰ／ＴＣＰｓｅｃアクティブオープンの処理を示す流れ図である。
【図７】標準ＴＣＰと本発明のＴＣＰｓｅｃのホストＡ（アクティブオープン）とホストＢ（パッシブオープン）間の通信のやり取りを示すシーケンス図である。
【図８】図５のＴＣＰパッシブオープン処理Ｓ５の詳細を示す流れ図である。
【図９】図５のＴＣＰｓｅｃパッシブオープン処理Ｓ６の詳細を示す流れ図である。
【図１０】図６のＴＣＰアクティブオープン処理Ｓ１２の詳細を示す流れ図である。
【図１１】図６のＴＣＰｓｅｃアクティブオープン処理Ｓ１３の詳細を示す流れ図である。
【図１２】図９のＴＣＰｓｅｃ送受信処理Ｓ３７及び図１１のＴＣＰｓｅｃ送受信処理Ｓ７６の詳細を示す流れ図である。
【図１３】図９のＴＣＰｓｅｃパッシブ接続処理Ｓ４８の詳細を示す流れ図である。
【図１４】図１１のＴＣＰｓｅｃアクティブ接続処理Ｓ８８の詳細を示す流れ図である。
【図１５】本発明のＴＣＰ２の実施形態であるＵＤＰ／ＵＤＰｓｅｃオープンの処理を示す流れ図である。
【図１６】本発明のＴＣＰ２を用いたＵＤＰ／ＵＤＰｓｅｃユニキャスト通信のシーケンス図である。
【図１７】本発明のＴＣＰ２を用いたＵＤＰ／ＵＤＰｓｅｃブロードキャスト通信のシーケンス図である。
【図１８】図１５のＵＤＰオープン処理Ｓ１２４の詳細を示す流れ図である。
【図１９】図１５のＵＤＰｓｅｃオープン処理Ｓ１２５の詳細を示す流れ図である。
【図２０】図１９のＵＤＰｓｅｃブロードキャスト受信開始処理Ｓ１４１の詳細を示す流れ図である。
【図２１】図１９のＵＤＰｓｅｃユニキャスト送信開始処理Ｓ１４６の詳細を示す流れ図である。
【図２２】図１９のＵＤＰｓｅｃデータ送受信処理Ｓ１４４の詳細を示す流れ図である。
【図２３】図１９のＵＤＰｓｅｃユニキャスト受信開始処理Ｓ１３７の詳細を示す流れ図である。
【図２４】本発明のＴＣＰ２を従来のＩＰｓｅｃ又はＳＳＬを適用した場合と比較したメリットを説明するための図である。
【符号の説明】
【０１４４】
１・・・ホストコンピュータ、
２・・・ネットワーク制御機器（ルータ）
３ａ、３ｂ、３ｃ・・・クライアント端末
４ａ、４ｂ、４ｃ・・・クライアント端末
１１・・・ＮＩＣドライバ
１２・・・ＡＲＰ 又は ＡＲＰ ｏｎ ＣＰ
１３・・・ＩＰエミュレータ
１３ｂ・・・ＩＰｓｅｃ ｏｎ ＣＰ
１５・・・ＴＣＰエミュレータ
１５ｂ・・・ＴＣＰｓｅｃ ｏｎ ＣＰ
１６・・・ＵＤＰエミュレータ
１６ｂ・・・ＵＤＰｓｅｃ ｏｎ ＣＰ
１７・・・ソケット（Ｓｏｃｋｅｔ）
４１・・・ＩＰヘッダ
４２・・・ＥＳＰヘッダ
４３・・・ＴＣＰヘッダ
４４・・・ＴＣＰｓｅｃ付加情報
４５・・・データ（ペイロード）
４６・・・ＴＣＰｓｅｃ付加トレーラ
４７・・・ＴＣＰｓｅｃ付加認証データ
４８・・・ＥＳＰトレーラ
４９・・・ＥＳＰ認証データ
【特許請求の範囲】
【請求項１】
トランスポート層に位置するＴＣＰ又はＵＤＰプロトコルに暗号化機能を追加して複数のホスト間で通信を行う暗号化通信システムであって、
通信相手との接続を行うための接続シーケンス手段と、
ＴＣＰ２固有情報を交換して通信相手が正当な権限を有する通信相手であるかどうかを判断し、暗号化通信に必要な鍵交換を行うためのＴＣＰｓｅｃ接続シーケンス手段と、
通信路の両端で対応する暗号化及び復号化ロジックを取り決める取決め手段と、
前記取決め手段により取り決めた暗号化ロジックに従って、前記複数のホスト間で送受信する情報のパケットを暗号化して送信するプロトコル暗号化手段と、
前記取決め手段により取り決めた復号化ロジックに従って前記複数のホスト間で送受信する情報のパケットを復号化するプロトコル復号化手段と、を備え、
前記接続シーケンス手段は、一切のイレギュラーパターンを排除するネットワーク環境にも対応できるように、第１のホストから第２のホストへの接続要求と、第２のホストから第１のホストへの接続応答と、第１のホストから第２のホストに肯定応答を送信するという標準の接続を行い、
前記ＴＣＰｓｅｃ接続シーケンス手段は、相手方ホストとＴＣＰ２固有情報の交換を行うことにより、相手方ホストが前記暗号化通信を行う権限を有することを確認し、暗号化通信に必要な鍵交換を行い、
前記取決め手段は、前記ＴＣＰｓｅｃ接続シーケンス手段が正当な権限を有すると判断して接続した通信相手とのみ前記トランスポート層の前記ＴＣＰ又はＵＤＰプロトコルを用いて前記暗号化及び復号化ロジックに基づいた通信を行い、
前記プロトコル暗号化手段は、前記送受信される情報のパケットのうち前記ＴＣＰ又はＵＤＰプロトコルのペイロードを暗号化して送信し、
前記プロトコル復号化手段は、前記送受信される情報のパケットのうち前記暗号化されたプロトコルのペイロードを復号化する
ことを特徴とする暗号化通信システム。
【請求項１】
トランスポート層に位置するＴＣＰ又はＵＤＰプロトコルに暗号化機能を追加して複数のホスト間で通信を行う暗号化通信システムであって、
通信相手との接続を行うための接続シーケンス手段と、
ＴＣＰ２固有情報を交換して通信相手が正当な権限を有する通信相手であるかどうかを判断し、暗号化通信に必要な鍵交換を行うためのＴＣＰｓｅｃ接続シーケンス手段と、
通信路の両端で対応する暗号化及び復号化ロジックを取り決める取決め手段と、
前記取決め手段により取り決めた暗号化ロジックに従って、前記複数のホスト間で送受信する情報のパケットを暗号化して送信するプロトコル暗号化手段と、
前記取決め手段により取り決めた復号化ロジックに従って前記複数のホスト間で送受信する情報のパケットを復号化するプロトコル復号化手段と、を備え、
前記接続シーケンス手段は、一切のイレギュラーパターンを排除するネットワーク環境にも対応できるように、第１のホストから第２のホストへの接続要求と、第２のホストから第１のホストへの接続応答と、第１のホストから第２のホストに肯定応答を送信するという標準の接続を行い、
前記ＴＣＰｓｅｃ接続シーケンス手段は、相手方ホストとＴＣＰ２固有情報の交換を行うことにより、相手方ホストが前記暗号化通信を行う権限を有することを確認し、暗号化通信に必要な鍵交換を行い、
前記取決め手段は、前記ＴＣＰｓｅｃ接続シーケンス手段が正当な権限を有すると判断して接続した通信相手とのみ前記トランスポート層の前記ＴＣＰ又はＵＤＰプロトコルを用いて前記暗号化及び復号化ロジックに基づいた通信を行い、
前記プロトコル暗号化手段は、前記送受信される情報のパケットのうち前記ＴＣＰ又はＵＤＰプロトコルのペイロードを暗号化して送信し、
前記プロトコル復号化手段は、前記送受信される情報のパケットのうち前記暗号化されたプロトコルのペイロードを復号化する
ことを特徴とする暗号化通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２００７−３２９７５０（Ｐ２００７−３２９７５０Ａ）
【公開日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願番号】特願２００６−１５９９８３（Ｐ２００６−１５９９８３）
【出願日】平成１８年６月８日（２００６．６．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．ＥＴＨＥＲＮＥＴ
【出願人】（５０３２８７７６４）ティー・ティー・ティー株式会社 (18)
【Ｆターム（参考）】
【公開日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願日】平成１８年６月８日（２００６．６．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．ＥＴＨＥＲＮＥＴ
【出願人】（５０３２８７７６４）ティー・ティー・ティー株式会社 (18)
【Ｆターム（参考）】
[ Back to top ]