JP2007018082A - コンピュータに認証機能を備えた通信システム、通信方法、通信プログラム及びプログラムを記憶した記録媒体 - Google Patents

コンピュータに認証機能を備えた通信システム、通信方法、通信プログラム及びプログラムを記憶した記録媒体 Download PDF

Info

Publication number
JP2007018082A
JP2007018082A JP2005196501A JP2005196501A JP2007018082A JP 2007018082 A JP2007018082 A JP 2007018082A JP 2005196501 A JP2005196501 A JP 2005196501A JP 2005196501 A JP2005196501 A JP 2005196501A JP 2007018082 A JP2007018082 A JP 2007018082A
Authority
JP
Japan
Prior art keywords
computer
code
connection
communication
identification address
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
Application number
JP2005196501A
Other languages
English (en)
Other versions
JP4696204B2 (ja
Inventor
Hirotsugu Ozaki
博嗣 尾崎
Keiko Ogawa
恵子 小川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
TTT KK
Original Assignee
TTT KK
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by TTT KK filed Critical TTT KK
Priority to JP2005196501A priority Critical patent/JP4696204B2/ja
Publication of JP2007018082A publication Critical patent/JP2007018082A/ja
Application granted granted Critical
Publication of JP4696204B2 publication Critical patent/JP4696204B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】特定のグループに属するクライアント端末のみの間で、相互にアクセスすることができるようにするため、クライアント端末間で相互認証するための通信システム、通信方法および通信プログラムを提供する。
【解決手段】接続要求するコンピュータは、TCPパケット又はUDPパケットに固有の識別アドレスを付加する手段を有し、接続要求を受け付けるコンピュータは、TCPパケット又はUDPパケットから識別アドレスを判別して識別アドレスを認証する手段を有し、識別アドレスが予め設定された範囲で一致する場合には接続を許可し、識別アドレスが予め設定された範囲で一致しない場合には接続を拒否する。ここで、コンピュータとは、クライアント端末、およびサーバの双方を含む機器の総称である。
【選択図】図10

Description

本発明は、例えばTCP/IP等の特定のプロトコルによってコンピュータ間で相互に通信を行うに際して、それぞれの端末間で相互認証を行なうための通信システム、通信方法及び通信プログラムに関する。
TCP/IP等の特定のプロトコルを利用したクライアントサーバシステムでは、サーバがクライアント端末の認証を行なう方法として、例えば、ユーザIDやパスワード、バイオメトリクスを利用することが行なわれている(例えば、特許文献1を参照)。
また、クライアント端末がサービスを提供するサーバにアクセスする際、事前に認証サーバにアクセスして、電子証明書を取得した後、サービスを提供するサーバにアクセスすることも提案されている。
特開2004−30070号公報
しかしながら、一般に、クライアントサーバシステムでは、クライアント端末のアクセス権限をサーバ側で認証するようにしており、その認証処理に常にサーバを仲介させているため、クライアント端末間の接続に時間がかかる等の問題が生じる。このため、特定のクライアント端末のグループ間で相互に迅速で安全な通信接続ができるようにすることは極めて重要な課題となっている。そこで、それぞれのクライアント端末に認証機能を持たせ、各クライアント端末自体が、なりすまし、不正進入、攻撃から防御できるようにするシステムが必要とされている。つまり、クライアント端末自体が接続要求のあった他のクライアント端末との接続を許可するか、あるいは接続を拒否するかを決定するための認証システムを備えていることが望まれている。
しかし、特定の機関、例えば、LAN(Local Area Network)を構築した会社内で複数のクライアント端末が稼働している場合や、共通の目的をもった機関、例えば、VPN(Virtual Private Network)でネットワークを構築した自治体内等で複数のクライアント端末が稼働している場合には、それぞれのクライアント端末自体に認証システムを具備させることは現実的ではない。また、上述したように、認証サーバを利用して接続要求のたびに認証を行うことも、応答性の低下を招くという点で問題がある。
また、特定のLANにおいては、複数のクライアント端末の利用者が、同じグループに属する者同士で通信を行い、他のグループの者からの通信を受け付けないようにしたいという要求もある。例えば、会社組織であれば、取締役だけというような特定の職制の者だけがアクセスできる権限を持っている情報や、経理部門だけというような特定の部署の者だけがアクセスできる権限を持っている情報がある。このような場合は、当然のことながら、クライアント端末同士の接続を一定の範囲のものに限っておきたいという要求がある。
本発明の目的は、特定のグループに属するクライアント端末のみの間で、相互のアクセスすることができるようするため、クライアント端末間で相互認証するための通信システム、通信方法及び通信プログラムを提供することにある。
また、本発明は、特定のグループの中でそれぞれのクライアント端末にアクセス権限を付与し、上位のアクセス権限を付与されたクライアント端末から下位のアクセス権限を付与されたクライアント端末への接続を許可し、下位のアクセス権限を付与されたクライアント端末から上位のアクセス権限を付与されたクライアント端末への接続を拒否することにより、情報の漏洩を防止することも目的としている。
上記課題を解決し、本発明の目的を達成するため、本発明の通信システムは、接続要求するコンピュータと該接続要求を受け付けるコンピュータとの間において、TCP又はUDPに該当するプロトコルを取り扱う通信システムであって、接続要求するコンピュータは、TCPパケット又はUDPパケットにコンピュータ及び/又は該コンピュータを使用するユーザに固有の識別アドレスを付加する手段を有し、接続要求を受け付けるコンピュータは、TCPパケット又はUDPパケットから識別アドレスを判別して識別アドレスを認証する手段を有し、この接続要求を受け付けるコンピュータにおける識別アドレスを認証する手段は、識別アドレスが予め設定された範囲で一致する場合には接続を許可し、識別アドレスが予め設定された範囲で一致しない場合には接続を拒否することを特徴とする。なお、ここで「コンピュータ」とは、「クライアント端末」と「サーバ」の双方を含んだ機器を総称して呼ぶ用語として定義するものとする。
また、本発明の通信方法は、接続要求するコンピュータと該接続要求を受け付けるコンピュータとの間において、TCP又はUDPに該当するプロトコルを取り扱う通信方法であって、接続要求するコンピュータにおいて、TCPパケット又はUDPパケットにコンピュータ及び/又は該コンピュータを使用するユーザに固有の識別アドレスを付加するとともに、接続要求を受け付けるコンピュータにおいて、このTCPパケット又はUDPパケットから識別アドレスを判別して認証し、この接続要求を受け付けるコンピュータにおける識別アドレスの認証の際に、識別アドレスのうちの予め設定された範囲が一致する場合には接続を許可し、識別アドレスのうちの予め設定された範囲が一致しない場合には接続を拒否することを特徴としている。このコンピュータに付加される識別アドレスは、例えば、IPペイロードに搭載されている。そして、特にそのIPペイロードの一部を構成するTCPヘッダに搭載されることが望ましい。
さらに、本発明の通信システム及び通信方法の好ましい形態においては、クライアント端末における識別アドレスのビット列がセキュリティレベルに対応して階層化した構造となっており、このセキュリティレベルに対応して識別アドレスの認証を行い、クライアント端末間の接続を許可するか、あるいは接続を拒否するかを判断するようにしている。また、この場合、クライアント端末のセキュリティレベルに応じて、受信した識別アドレスのビット列を部分的にマスクすることにより、上位又は同位のセキュリティレベルのコンピュータからの接続要求に対して接続を許可し、下位のセキュリティレベルのコンピュータからの接続要求に対して接続を拒否するようにしている。
本発明の通信システム及び通信方法によれば、TCP又はUDPのようなトランスポート層のプロトコル自体に相互認証できる機能を追加し、この相互認証機能を備えたトランスポート層のプロトコルをサーバと各クライアント端末に採用しているので、クライアント端末自体で接続要求のあった他のクライアント端末との接続許可又は接続拒否のための処理が可能である。このため、従来のように、接続要求の度に特定のサーバによって認証を行なう必要がなくなる。したがって、それぞれのクライアント端末が、上述のトランスポート層のプロトコルを利用する限り、他の認証手段・認証方法を用いることなく高度のセキュリティでクライアント端末間の通信を実現することが可能となる。
以下、図面を参照して本発明による通信システム及び通信方法の実施の形態例を説明する。
図1は、本発明による通信システム及び通信方法を利用したネットワークの適用例を示すブロック図である。グループA〜Cは1つのLAN(Local Area Network:LAN(1)とする。)に収容されているクライアント端末群を示している。グループDのクライアント端末は「LAN(1)とは異なるLAN(2)に収容されているクライアント端末である。
LAN(1)20とLAN(2)30とは、外部ネットワーク40を介して接続されている。
LAN(1)に収容されているグループAに属するクライアント端末A1,A2,A3,・・・は、例えば会社の取締役クラスが使用するクライアント端末としてのセキュリティレベルが設定されている。また、LAN(1)に収容されているクライアント端末の中で、グループBに属するクライアント端末B1,B2,B3・・・は、例えば部長や課長などの管理職クラスのセキュリティレベルが設定されているクライアント端末である。そして、同じくグループCに属するクライアント端末C1、C2、C3・・・は、例えば担当者レベルのセキュリティレベルが設定されているクライアント端末である。当然のことながら、グループAに属するクライアント端末のセキュリティレベルが最も高く設定され、グループCに属するクライアント端末のセキュリティレベルが最も低く設定されることになる。
LAN(1)とは異なるLAN(2)に収容されるグループDに属するクライアント端末D1,D2,D3・・・は、例えば会社の支所や支店に存在しているクライアント端末であり、グループCに属するクライアント端末C1〜C3と同レベルのセキュリティレベルが設定されているものとする。
本実施の形態例では、それぞれのLAN(1)あるいはLAN(2)に接続された同じLANに収容されているクライアント端末間の接続許可あるいは拒否を実現するための通信システム及び通信方法を例として説明するが、異なるLAN間に収容されているクライアント端末間の通信、すなわち、LAN(1)に収容されたクライアント端末、例えばクライアント端末A1と、LAN(2)に収容されているクライアント端末、例えばクライアント端末D1とが通信を行う場合においても、本発明の通信システム及び通信システムを利用することができることは言うまでもない。
上述したように、LAN(1)に収容されているクライアント端末は、それぞれのグループ毎に異なるセキュリティレベルが設定されているが、各グループに属するクライアント端末には、そのセキュリティレベルに応じてアクセス権限が設定されることになる。すなわち、取締役クラスのセキュリティレベルが設定されるクライアント端末A1、A2、A3・・・には、グループA、グループB、グループCの何れに属するクライアント端末に対してもアクセスできるアクセス権限が設定されている。
また、管理職クラス(部課長クラス)のセキュリティレベルを有するグループBに属するクライアント端末B1,B2,B3・・・には、そのセキュリティレベルに応じたアクセス権限が設定されている。そして、グループCに属する担当者レベルのクライアント端末C1,C2,C3・・・は、そのセキュリティレベルのアクセス権限が設定されている。このように、LAN(1)が収容する各グループに属するクライアント端末には、インストールサーバISが通信プロトコルをインストールする際に、そのセキュリティレベルに応じたアクセス権限が設定されるようになっている。
また、LAN(2)は、例えば、会社の支所や支店が保有するLANであり、このLAN(2)に収容されているクライアント端末D1、D2、D3・・・は、例えばLAN(1)のグループCに属するクライアント端末C1、C2、C3・・・と同一のセキュリティレベルのクライアント端末と考えてよい。LAN(2)に収容されている各クライアント端末にも、インストールサーバISが通信プロトコルをインストールする際に、そのセキュリティレベルに応じたアクセス権限が設定されるようになっている。
また、LAN(1)又はLAN(2)に収容されるそれぞれのクライアント端末は、通信インターフェース100、記憶手段200、及び認証手段300を備えている。図1では、LAN(1)のグループCに属する担当者レベルのセキュリティレベルが設定されるクライアント端末C1だけに上述の通信インターフェース100、記憶手段200、認証手段300が記載されているが、これらの手段はLAN(1)とLAN(2)に収容される全てのクライアント端末及び不図示のサーバも具備しているものである。
通信インターフェース100は、LAN(1)あるいはLAN(2)に収容されるそれぞれのクライアント端末間で通信を行う際に、その接続部となるインターフェースを構成する部分である。記憶手段200には、各クライアント端末の識別アドレスが記憶されている。認証手段300は、それぞれのクライアント端末のセキュリティレベルに応じて設けられるマスクされた識別アドレスを用いて接続要求の許可あるいは接続要求の拒否を判別する手段である。この認証手続については後で詳細に説明する。
上述したように、LAN(1)及びLAN(2)に収容される各クライアント端末には、インストールサーバISによって、TCP/IP、UDP/IP等の通信プロトコルのアプリケーションプログラムがインストール(ダウンロード)される。なお、TCP/IP、UDP/IP等の通信プロトコルのアプリケーションプログラムは、CD−ROMやPCカードのような記録媒体から各クライアント端末のハードディスクにダウンロードすることもできるが、PCカードやCD−ROMを各クライアント端末に挿入して通信プロトコルを利用可能にしてもよい。
また、外部ネットワーク40に接続されているインストールサーバISには、アプリケーションプログラムのシリアル番号、CPUのID等の端末の機器情報、氏名等のユーザ情報、MACアドレス(Media Access Control:通信を行うコンピュータやルータなどのハードウエアが独自に持つアドレス、「物理アドレス」ともいう。)、ルータのIPアドレス等のLANに接続された周辺機器情報が保存されている。そして、インストールサーバISが、通信プロトコルのアプリケーションプログラムを各クライアント端末にイストールする際に、インストールサーバISから、LAN(1)とLAN(2)に収容される各クライアント端末に対して、後述するTCP2に係る識別アドレス(以下、「TCP2アドレス」という。)が付与され、各クライアント端末の記憶手段200に保存される。このTCP2アドレスが、各クライアント端末間の通信における端末間の相互認証に利用されることになる。
LAN(1)とLAN(2)に収容されるクライアント端末間の通信は、それぞれのクライアント端末にインストールされるTCP2アドレスがインストールサーバに登録されていること、TCP/IP、UDP/IP等の通信プロトコルのアプリケーションプログラムがそれぞれのクライアント端末及びサーバにイストールされていること、及び、それぞれのクライアント端末の記憶手段200に各クライアント端末及びサーバに対応するTCP2アドレスが保存されていることの3つを条件として、それぞれのクライアント端末間あるいはクライアント端末とサーバ間の接続が行われ、相互に通信することができるように構成される。ここで、それぞれのクライアント端末にインストールされるのは、TCP/IP、UDP/IP等の通信プロトコルと各クライアント端末のTCP2アドレスである。
図2は、それぞれのクライアント端末にインストールされるTCP/IP、UDP/IP、及びTCPsec/IP、UDPsec/IP等の通信プロトコルスタックを示す図である。
まず、図2に示すように、本発明に用いられるプロトコルスタックは、最下層に相当する物理層(第1層)とデータリンク層(第2層)にNIC(Network Interface Card)のDriver11が配列されている。このドライバは、コンピュータなどのハードウエアをネットワークに接続するためのインターフェースカードのドライバであり、データ送受信制御のためのソフトウエアである。例えばEthernetに接続するためのLANボードまたはLANカードがこれに相当する。
第3層のネットワーク層には、一部がトランスポート層(第4層)まで延びたIPエミュレータ(emulator)13が存在している。このトランスポート層まで延びた部分には、トランスポート層の機能は実装しておらず、セッション層に、ネットワーク層の機能を提供しているだけある。このIPエミュレータ13は、暗号化通信を行うプロトコルである「IPsec on CP」13bと、「IP on CP」13aを用途に応じて切り換えて使う働きをするものである。ここで、「on CP」とは、クラッキング・プロテクタ(CP)による、「進入」「攻撃」の監視、破棄、切断ないし通過制限の対象となっていること、又は、設定によりなりうることを示している。
また、ネットワーク層にはARP on CP(Address Resolution Protocol on Cracking Protector)が配列されている。このARP on CPは、クラッカー(Cracker)への保護対策を具備したIPアドレスからEthernetの物理アドレスであるMACアドレスを求めるのに使われるプロトコルである。
ここで、IPエミュレータ13は、本発明による各種のセキュリティ機能を、従来のIP周辺のスタックに整合させるためのソフトウエア又はファームウエアである。すなわち、IPのエラーメッセージや制御メッセージを転送するプロトコルであるICMP(Internet Control Message Protocol)14a、同一のデータを複数のホストに効率よく配送するための又は配送を受けるために構成されるホストのグループを制御するためのプロトコルであるIGMP(Internet Group Management Protocol)14b、TCP15、UDP16さらにソケット(Socket)インターフェース17に整合させるためのソフトウエア、又はファームウエア、ないしはハードウエア(電子回路、電子部品)である。このIPエミュレータ13により、IPsecの暗号化・復号化及び必要な認証情報付加・認証等の前後の適合処理を行うことができる。
このIPエミュレータ13の上層のトランスポート層(第4層)には、TCPエミュレータ15とUDPエミュレータ16が配置されている。TCPエミュレータ15は、暗号化通信を行うプロトコルである「TCPsec on CP」15bと、通常の通信プロトコルである「TCP on CP」15aを用途に応じて切り換えて使う働きをする。同様に、UDPエミュレータ16は、暗号化通信を行うプロトコルである「UDPsec on CP」16bと、通常の通信プロトコルである「UDP on CP」16aを用途に応じて切り換えて使う働きをする。
トランスポート層(第4層)の上層のセッション層(第5層)には、TCP及びUDP等のプロトコルとデータのやりとりを行うソケット(socket)インターフェース17が設けられている。このソケットの意味は、既に述べたようにコンピュータが持つネットワーク内の住所に当たるIPアドレスと、IPアドレスのサブアドレスであるポート番号を組み合わせたネットワークアドレスを意味しており、実際には、一連のヘッダの追加ないし削除をまとめて行う、単一のソフトウエアプログラムモジュール(実行プログラム等)あるいは単一のハードウエアモジュール(電子回路、電子部品等)からなっている。このソケットインターフェース17は、さらに上位のアプリケーションからの統一的なアクセス方式を提供するものであり、引数の種類や型など従来と同様のインターフェースを保つようにしている。
TCPエミュレータ15は、トランスポート層において、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つTCPsec15bと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルTCP15aのいずれかにパケットを振り分ける働きをもっている。また、TCPsec15b及びTCP15aのいずれもクラッキング・プロテクタ(CP)を備えているため、そのいずれを選択した場合でも、クラッカーによる「進入」「攻撃」に対して防御する機能を実現することができる。TCPエミュレータ15は上位層であるソケットとのインターフェースの役割も果たしている。
UDPエミュレータ16は、TCPエミュレータ15と同様に、データの漏洩・改竄の防止の機能、すなわち暗号化、完全性認証及び相手認証等の機能を持つUDPsec16bと、このような暗号化、完全性認証、及び相手認証等の機能を持たない通常のプロトコルUDP16aのいずれかにパケットを振り分ける働きを持っている。TCPがエラー補償機能を有するのに対して、UDPはエラー補償機能を持たないが、その分転送速度が速く、かつブロードキャスト機能を備えているという特徴がある。
図2に示すような、ソケット17、TCPエミュレータ15、UDPエミュレータ16、「TCPsec on CP」15b、「UDPsec on CP」16b、「TCP on CP」15a、「UDP on CP」16a、「ICMP on CP」14a、「IGMP on CP」14b、IPエミュレータ13、「IP on CP」13a、及び「ARPonCP」12からなるプロトコルスタックは、すでに出願人が提案した暗号化通信システムを実現するためのプロトコルスタックである。これらのプロトコルスタックを総称してTCP2と呼ぶこととする。なお、TCP2には「IPsec on CP」13bは必須のものとして含まれていないが、「IPsec on CP」13bを含めてTCP2としてもよい。
また、上述のプロトコルスタックには、TCP、UDP、IP、IPsec、ICMP、IGMP、ARPの標準プロトコルにCP(クラッキング・プロテクト)を実装しているので、各プロトコルスタックに対する通信からの攻撃、及び、アプリケーションからの攻撃(トロイの木馬、プログラムの改竄、正規ユーザの不正使用)を防御することができる。また、TCPエミュレータ15を実装しているので、セッション層にあるソケット(Socket)17、及びネットワーク層にあるIPエミュレータ13から見て、互換性を保つことができ、外向きには標準TCPと同じに見せることができる。実際は、TCP2の機能として、TCPとTCPsecを切り替えて実行するようにする。
また、同様に、TCP2では、UDPエミュレータ16を実装しており、UDPエミュレータ16は、セッション層であるソケット(Socket)17、及び、ネットワーク層であるIPエミュレータ13から見て、互換性を保つため、外部からは標準UDPとして見せることができる。実際は、TCP2の機能として、UDP、UDPsecを切り替えて実行する。UDPsecは、本発明であるトランスポート層での暗号化及び認証機能である。
次に、TCP2において、特に重要な機能である「データ漏洩」を防ぐ機能であるTCPsec15b及びUDPsec16bについて説明する。
TCPsec15b及びUDPsec16bのための暗号化・復号化の方法(アルゴリズム、ロジック(論理))としては、公知の秘密鍵(共通鍵)暗号アルゴリズムが用いられる。例えば、秘密鍵暗号アルゴリズムであるDES(Data Encryption Standard)や、その改良版としての3DESが用いられる。また、その他の暗号アルゴリズムとしては、IDEA(International Data Encryption Algorithm)も用いられる。この暗号アルゴリズムは、データを64ビットのブロックに区切って暗号化するもので、暗号鍵の長さは128ビットである。
また、TCPsec15b及びUDPsec16bの暗号方式として、FEAL(Fast data Encipherment Algorithm)、MISTY、AES(Advanced Encryption Standard)といった暗号方式も利用されるほか、また、独自に作成した秘密の暗号化・復号化アルゴリズムを利用することもできる。ここで、FEALは、暗号化と復号化に同じ鍵を用いる秘密鍵型の暗号方式である。このFEALは、DESに比べて高速に暗号化と復号化ができるという利点がある。
図3は、本発明の実施の形態に用いられるTCP2アドレスの例を示している。このTCP2アドレスは、80bit(2進数80桁)からなり、図3に示すように、[分類コード][企業団体コード][ホストコード][ユーザコード][予備コード]の4つに分類したコードから構成される。[分類コード]は2bit、[ユーザコード]は32bit、[分類コード]は3bitと固定で割り付けられている。[分類コード]は、企業団体コードとホストコードに配分されるビット数43bitの配分割合を決定するコードであり、2ビットで4種類(図3(A)〜(D))に分けて定義することを可能としている。
例えば、分類コード「00」は、図1(A)に示すように、43bitの内、企業団体コードに7ビットを割り付け、ホストコードに36bitを割り付けるようにしている。この結果、この分類コード「00」は、企業団体を最大2の7乗(128)団体定義することができ、1団体当りのホスト割り当て数は、2の36乗台となる。つまり、この分類コード「00」では、割り付けられる企業団体が少なくなる反面、ホスト数が多く割り付けることができる。したがって、この分類コード「00」は、団体数としては少ないが、多くのクライアントを持っている通信業者(通信キャリア)のような企業団体向けとして好適なものとなる。
次に、分類コード「01」は、図1(B)に示すように、43bitの内、[企業団体コード]に15bitを割り付け、[ホストコード]に28bitを割り付けている。この分類コード「01」は、企業団体を最大2の15乗(32768)団体定義することができる。その反面、1団体当りのホスト割り当て数は2の28乗台となるのである。この分類コード「01」で分類される団体は、支店や支所を国内あるいは海外に多く抱える大企業向きの分類コードである。
分類コード「10」は、図1(C)に示すように、43bitの内、[企業団体コード]に25bitを割り付け、[ホストコード]に18bitを割り付けている。これにより、分類コード「10」は、企業団体を最大2の25乗団体定義することができるが、1団体当りのホスト割り当て数は、2の18乗(262144)台となる。この分類コードは大企業より支店や支所の多くない中堅企業に好適である。
最後の分類コード「11」は、図1(D)に示すように、43bitの内、[企業団体コード]に31bitを割り付け、[ホストコード]に12bitを割り付けている。これにより、分類コード「11」は、企業団体を最大2の31乗団体定義することができる。ただし、1団体当りのホスト割り当て数は、2の12乗で、4096台しか割り当てることができない。この分類コード「11」は、分類コード「00」とは正反対で、割り付けられる企業団体が多くなる反面、ホスト数の割付が小さくなる。例えば、中小の企業団体のような、企業数が多く、一つ一つの企業ではそれほどホスト数を増やす必要がない企業団体向けの分類コードとなる。
上述した[企業団体コード]は、TCP2を使用する企業団体に対して、TCP2アドレスの割付管理部門が、ユニークに割り当てを行うコードである。これを行うことで、全てのTCP2使用団体に、ユニークなTCP2アドレスを割り当てることが可能となる。
また、[ホストコード]は、ネットワークに接続した、TCP2を実装するコンピュータ機器の固体を示すコードであり、企業団体内のTCP2管理部門が、企業団体内のTCP2アドレスをユニークに割り当てるコードである。これら分類コード、企業団体コード、ホストコードの3つのコードで、TCP2を実装するネットワークに接続したコンピュータ機器全てにユニークなTCP2アドレスを割り付けることができ、これらのコードによりネットワークに接続したTCP2を実装したコンピュータ機器を全て識別することができるようになる。なお、[ホストコード]は、企業内での組織などにしたがってグループ分けされるコードである。
次に、[ユーザコード]について説明する。「ユーザコード」は、ネットワークに接続され、TCP2が実装された各コンピュータ機器を使用するユーザを識別するコードである。1つのコンピュータ機器を複数の人が使用する場合には、1つのコンピュータ機器に対応して複数のユーザコードが存在することになる。特定のユーザが、TCP2を使用する際には、その個人にユニークなユーザID、パスワード、更には、生態認証情報等を必要とするのであるが、これらの情報を32bitのユーザコードとして決定しておく必要がある。なお、[予備コード]は、今後、TCP2アドレスを拡張する際に使用するコードであり、現時点で必要とするものではない。
図4は、図3(C)に示す分類コード「10」の例、すなわち、18bitのホストコードの例を、会社の組織にしたがって分割して示した図である。図4では、18bitを割り付けている[ホストコード]を4階層にグループ化し、図4(C)に示すように「事業部コード」、「部コード」、「課コード」、「機器コード」としている。
TCP2が実装されるクライアント端末及びサーバ等のコンピュータ機器は、ネットワークを介しての通信開始に際して、通信すべき相手であるかを判断する情報として、上記TCP2アドレスの他に、「通信許可情報」と「通信禁止情報」を各コンピュータ機器が備えている記憶手段200(図1参照)の設定データベースに保存している。ここで、「通信許可情報」は、通信許可コードと通信許可マスク情報をペアで持ち、「通信禁止情報」は、通信禁止コードと通信禁止マスク情報をペアで持っている。これらの通信許可コード、通信許可マスク情報、通信禁止コード、通信禁止マスク情報は、TCP2アドレスと同じフォーマットで80bitの割付けをおこなうことにより形成される。
次に、図5と図6に基づいて、サーバとクライアント端末の間、あるいはクライアント端末同士の通信とユーザ認証の仕組みを説明する。
図5は、実際のコンピュータ機器(サーバあるいはクライアント端末)のグルーピング制御を説明する上のシステム構成例を示す図である。図5に示す例は、分類コードが2(2進数の「10」)で、企業団体コードが23の例である。図5に示すように、サーバには「ホストコード」として、事業部コード3、部コード4、機器コード1が割り当てられている。図6(1)は、上記サーバの持つコードを、TCP2アドレスとして2進数で示したものである。ここで課コード及びユーザコードは“0”となっていることから、このサーバは、この部に所属するすべてのユーザが共同で利用するサーバであることがわかる。
図5に示すクライアント端末Bとクライアント端末CXは同一の課であるX課に属するクライアント端末であり、クライアント端末Bは、例えば、図1のLAN(1)のグループ(B)に属する管理職(課長)クラスのセキュリティを持つクライアント端末B1〜B3の1つを示している。このクライアント端末Bは、例えば、事業部コード3、部コード4、課コード5、機器コード6、ユーザコード1を有している。このユーザコードが1であることは、一人のユーザ(課長)がクライアント端末Bを独占して使用することを示している。
クライアント端末CXは、図1のグループ(C)に属する担当者クラスのセキュリティを持つクライアント端末C1〜C3のいずれか1つの端末でクライアント端末Bと同じX課に属するクライアント端末を例示したものである。事業部コード3、部コード4、課コード5までは、クライアント端末Bのコードと同じであるが、機器コードには“7”が割り当てられ、クライアント端末Bの機器コード“6”と異なっている。そして、図6(3)のTCP2アドレスに示されるユーザコードの最後から3bitに「???」が付されているが、これはユーザコード2〜7(「010」〜「111」)の6人のユーザがこの端末を共同で利用することを意味している。理論的には、ユーザが最大で8人まで利用可能である。
クライアント端末CYは、事業部コード3、部コード4で、クライアント端末B、CXと一致しているが、課コードが“6”となっている。つまりクライアント端末CYはクライアント端末B、CXの属するX課と異なるY課に属する端末である。また、図6(4)のTCP2アドレスから分かるように、クライアント端末CYの機器コードは“7”であり、ユーザコードの下4桁は「????」である。例えば、このクライアント端末CYは、ユーザコード8〜15(2進数で「1000」〜「1111」)までのコードが割り当てられ、8人のユーザが共同利用するクライアント端末であるといえる。なお、4桁の「?」は最大で16人のユーザがこのクライアント端末CYを利用することができることを意味している。
次に、図6を用いて、それぞれのクライアント端末間あるいはクライアント端末とサーバ間の通信接続の可能性について説明する。
図6(1)のサーバは、部内からのホストコンピュータ全てからの接続要求を許可にするため、図6(1)に示す「通信許可コード」をその記憶手段200の設定データベースに保存している。すなわち、この「通信許可コード」は、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「予備コード」をTCP2アドレスと同じに設定し、「課コード」、「機器コード」、「ユーザコード」を未設定「0」としている。また、「通信許可マスク情報」としては、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「予備コード」の全てのビットを「1」に設定し、「課コード」、「機器コード」、「ユーザコード」をすべて「0」に設定している。
また、図5のサーバは、図6(1)に示すように、「通信禁止コード」と「通信禁止マスク情報」をその記憶手段200(図1参照)内の設定データベースに具備している。これは、クライアント端末CYの特定のユーザのアクセスを拒否するために設けられたものである。すなわち、「通信禁止コード」としては、接続を禁止するユーザが使用するクライアント端末が属するTCP2アドレスである「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「機器コード」、「ユーザコード」、「予備コード」を全て設定する。そして、「通信禁止マスク情報」として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「機器コード」、「ユーザコード」、「予備コード」の全ビットを「1」に設定する。
図5のクライアント端末CXは、図6(2)に示すように、そのTCP2設定データベースに、通信許可コードと通信許可マスク情報を持っている。これは、X課内からのクライアント端末からの接続要求を許可にするために設けられるものであり、通信許可コードとしては、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、X課の「課コード」、「予備コード」をTCP2アドレスと同じに設定する。そして、「機器コード」、「ユーザコード」を未設定「0」とする。また、「通信許可マスク情報」として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」の全てのビットを「1」に設定し、「機器コード」、「ユーザコード」を全て「0」に設定する。
これにより、X課のクライアント端末Bは、クライアント端末CXに接続することが可能となる。同様に、クライアント端末Bは、クライアント端末CXと同等なセキュリティレベルを有するX課に属する全てのクライアント端末にアクセスすることができる。
一方、クライアント端末Bは、例えば課長の占有する端末であり、X課に属するクライアント端末であっても、例えば特別なクライアント端末CXからの接続要求を拒否することができるように設定される。このため、クライアント端末Bは、「通信禁止コード」として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「機器コード」、「予備コード」に禁止するクライアント端末CXが使用するTCP2アドレスのコードと同じコードを設定している。そして、「通信禁止マスク情報」として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「機器コード」、「予備コード」の全てのビットを「1」とし、「ユーザコード」の全ビットを「0」に設定する。この、「通信禁止コード」、「通信禁止マスク情報」は、「通信許可コード」、「通信許可マスク情報」に優先するため、クライアント端末CX(担当者)からクライアント端末B(課長)への接続は拒否されることになる。
以上説明したように、図5に示すクライアント端末CXは、X課内にある全てのクライアント端末からの接続要求を許可にするように設定されように、そのための情報がクライアント端末CXの記憶手段200の設定データベースに保存されている。すなわち、図6(3)に示すように、「通信許可コード1」として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、X課の「課コード」及び「予備コード」をX課に属するクライアント端末、例えばクライアント端末BのTCP2アドレスと同じに設定し、「機器コード」、「ユーザコード」を未設定“0”とする。そして、通信許可マスク情報1として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」の全てのビットを“1”に設定する。
また、クライアント端末CXは、「通信禁止コード」及び「通信禁止マスク情報」をその記憶手段200の設定データベース内に保有しない。更に、クライアント端末CXは、例外的に他の課であるだいY課のクライアント端末Cからの接続要求だけを許可にするため、通信許可コード2として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「機器コード」、「予備コード」をY課のクライアント端末CのTCPアドレスと同じに設定し、「ユーザコード」を未設定“0”とする。そして、通信許可マスク情報2として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」を全てのビットを“1”に設定し、「機器コード」、「ユーザコード」を全て“0”に設定する。これにより、クライアント端末CYからクライアント端末CXへの接続が許可されることになる。
次に、図5のクライアント端末CYは、Y課内の全てのクライアント端末からの接続要求を許可にするため、通信許可コード1として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」を設定し、「機器コード」、「ユーザコード」を未設定“0”とする。そして、通信許可マスク情報1として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」の全てのビットを“1”に設定し、「機器コード」、「ユーザコード」を全て“0”に設定する。
更に、クライアント端末CYは、例外的に他の課であるX課のクライアント端末Bからの接続要求だけを許可にするため、通信許可コード2として、「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」をX課のクライアント端末CXのTCP2アドレスと同じに設定し、「機器コード」と「ユーザコード」を未設定“0”とする。そして、通信許可マスク情報2の「分類コード」、「企業団体コード」、「事業部コード」、「部コード」、「課コード」、「予備コード」の全てのビットを“1”に設定し、「機器コード」、「ユーザコード」を全て“0”に設定する。これにより、クライアント端末CYは、クライアント端末CXからの接続要求を許可することができる。
次に、図7に基づいて、本発明のTCP2、特にTCPsecを用いた端末間の接続シーケンスについて説明する。図7では、コンピュータBのアプリケーションがTCPsecパッシブオープンし、コンピュータAのアプリケーションがTCPsecアクティブオープンしていることが前提である。
コンピュータBのアプリケーションがTCPsecパッシブオープンをすると、TCPsecパッシブオープン処理を開始し、コンピュータBは受信待ちとなる。コンピュータAのアプリケーションがTCPsecアクティブオープンをすると、TCPsecアクティブオープン処理を開始し、コンピュータAからコンピュータBに対して接続要求(SYN)が送信される。これにより、TCPsecの接続シーケンスが開始状態となる。なお、接続要求(SYN)には、オプションで、TCP2の固有情報を暗号化して付加し、正しい相手であることを相手に通知するようにしている。すなわち、コンピュータAとコンピュータBの間で次のTCPsecネゴシエーションデータを交換する以前に相手方端末がTCP2をサポートする端末であるか否か、言い換えると通信する正しい相手であるか否かを確認することができる。
コンピュータB側では、コンピュータAから送信された接続要求(SYN)を受信すると、正しい相手であれば、コンピュータAに対して接続応答(SYN・ACK)を送信する。そして、コンピュータA側は、このコンピュータBからの接続応答(SYN・ACK)を受信するとACK(肯定応答)を送信する。続いてコンピュータAとコンピュータBの間でTCPsecネゴシエーションデータを交換し、正しい相手であれば、TCPsecの接続シーケンスを終了する。
この接続シーケンスが終了すると、TCPsecのデータ通信シーケンスが有効となり、コンピュータA側又はコンピュータB側の何れかがデータを送信後、データを受信した側からACK(肯定応答)を返す基本パターンを繰り返してデータの送受信が行われる。なお、このデータは、すべて暗号データである。
図8は、標準UDPとTCP2の暗号化方式の一つであるUDPsecを用いたブロードキャスト通信の開始シーケンス、データ通信シーケンスの流れを説明した図である。
図8(a)が、標準のUDP、図8(b)がTCP2に設けられるUDPsecによる通信のシーケンス図である。
図8(a)の標準のUDPは、コンピュータA、コンピュータBともにアプリケーションがUDPオープンしている。そして、コンピュータBのアプリケーションがUDPオープンをすると、UDPオープン処理を開始する。また、コンピュータAのアプリケーションがUDPオープンした場合も、同様にUDPオープン処理を開始する。これにより、UDPのデータ通信を行うことができる状態となる。
また、データはコンピュータA、コンピュータBの何れからも発信することはできるが、図8(a)では、ブロードキャスト通信ということもあって、コンピュータA側からコンピュータB側に一方向的にデータが流れようにしている。TCPのように、データを受信したコンピュータB側からACK(肯定応答)を返さないため、送達確認とデータの保証をする機能は持たない。なお、データのブロードキャストは、IPアドレスのサブネットアドレスを全て“1”に設定することで、実現することができる。
次に、図8(b)のUDPsecによる暗号化通信について説明する。この場合も、コンピュータA、コンピュータBともにアプリケーションがUDPオープンし、TCP2がUDPsecでオープンとしている。
コンピュータBがUDPsecオープンをすると、UDPsecオープン処理を開始する。また、コンピュータAがUDPsecオープンしても同様に、UDPsecオープン処理を開始する。これにより、UDPsecのデータ通信を行うことができる状態となる。
まず、図8(b)に基づいて、コンピュータAのアプリケーションからUDPのブロードキャストデータ(IPアドレスがブロードキャストを示しているデータ)の送信要求があった場合を説明する。コンピュータAは、アプリケーションからUDPのブロードキャストデータの送信要求を受け取ると、UDPsecで暗号データとして不特定コンピュータに配信する。コンピュータBは、コンピュータAからのブロードキャストデータを受け取ると、UDPsecブロードキャスト受信開始処理を開始する。コンピュータAとコンピュータB間でネゴシエーションを開始し、相手が正しい相手であれば、ネゴシエーションを完了して、ブロードキャストデータを復号化して、アプリケーションへ送る。このとき、データを受信したコンピュータB側からACK(肯定応答)を返さないため、送達確認とデータの保証をする機能はない。
図9(a)と図9(b)は、標準UDPとTCP2の暗号化方式であるUDPsecを用いたユニキャスト通信の開始シーケンス、データ通信シーケンスの流れを説明した図である。図8(a)、(b)と異なるところは、送信側のコンピュータAから受信側のコンピュータBに対してネゴシエーションを開始することと、コンピュータAとコンピュータBとの間で、1対1で双方向にデータのやり取りが行われることである。それ以外の点は、上述したブロードキャスト通信と同じであるため説明は省略する。
次に、図10と図11に基づいて、本発明の実施の形態例の動作について説明する。
まず、図10に基づいて、クライアント端末間の一般的な通信動作について説明し、続いて、図11を用いて具体的な端末間の動作について説明する。
図10に示すように、まず、通信要求パケットを受信したクライアント端末は、受信したパケットからTCP2アドレス(図6を参照。)を取り込む(ステップS1)。
次に、クライアント端末の記憶手段200(図1参照。)に通信禁止コード(図6(3)のクライアント端末Bを参照。)が記憶されているかどうかが判断される(ステップS2)。判断ステップS2で、クライアント端末の記憶手段200の中に通信禁止コードが記憶されていると判断された場合は、続いて通信禁止マスク情報と受信したTCP2アドレスとの論理積(AND)が演算され(ステップS3)、この演算結果と記憶手段200に記憶されている通信禁止コードとが一致するかどうかが判断される(ステップS4)。
そして、この判断ステップS4の判断の結果、両者が一致していれば、当該クライアント端末が通信許可をしてはいけない相手方端末からの通信要求パケットであるとして、接続不可となって通信を終了させる(ステップS9)。
判断ステップS2で通信禁止コードがないと判定された場合、あるいは判断ステップS4において、ステップS3の演算結果が通信禁止コードと一致しないと判定された場合は、クライアント端末の記憶手段200に通信許可コードが記憶されているか否かが判断される(ステップS5)。そして判断ステップS5で通信許可コードがあると判定された場合には、今度は記憶手段200から通信許可マスク情報を取り出し、このマスク情報と受信したTCP2アドレスとの論理積(AND)を演算する(ステップS6)。そして、この演算結果が記憶手段200に記憶されている通信許可コードと一致するかどうかが判断される(ステップS7)。
判断ステップS7において、記憶手段200に記憶されている通信許可コードと受信したTCP2アドレスが一致したと判断された場合のみ、端末間の接続が完了し、通信開始がなされる(ステップS8)。判断ステップS5で通信許可コードがないと判定された場合、あるいは判断ステップS7において、通信許可コードと受信したTCP2アドレスが一致しないと判定された場合は、端末間の接続をすることなく通信を終了する(ステップS9)。
以上、図10に基づいて説明した通信開始処理を、図5に示す具体的な端末間でやり取りする場合について、図11を用いて説明する。
まず、クライアント端末Bのユーザコード1の者が、クライアント端末CXに通信要求する場合(図11(1)の場合)について説明する。クライアント端末CXは、クライアント端末BからTCP2の通信開始要求が来ると、通信開始要求内にあるクライアント端末BのTCP2アドレスを取り込み、通信可能な相手であるか否かを判断する。このTCP2アドレスには、機器コードと機器の使用者のコードであるユーザコードが含まれているため、認証精度が高い。
図11(1)の演算結果は、クライアント端末Bの使用者であるユーザコード1の者が、クライアント端末CXに通信要求したとき、クライアント端末CXの記憶手段200に記憶されている通信許可マスク情報とクライアント端末BのTCP2アドレスとの論理積(AND)結果を示したものである。この演算処理は図10のステップS6の処理に相当する。そして、この演算結果はクライアント端末CXの通信許可コードと比較され(図10のステップS7)、その比較の結果、両者が一致しているため、クライアント端末CXはクライアント端末Bからの通信要求を受け入れることになる。
次に、クライアント端末CXのユーザコード5の者が、クライアント端末Bに通信要求する場合(図11(2)の場合)について説明する。
図11(1)の場合と同様に、クライアント端末Bは、クライアント端末CXからTCP2の通信開始要求が来ると、通信開始要求内にあるクライアント端末CXのTCP2アドレスを取り込み、通信可能な相手であるのかを判断する。ここで、図6(3)に示すように、クライアント端末Bは、その記憶手段200に、「通信禁止コード」と「通信禁止マスク情報」を持っている。
図11(2)に示されるように、まず、クライアント端末Bで受信したクライアント端末CXのTCP2アドレスが、クライアント端末Bが保有する「通信禁止マスク情報」との論理積(AND)が演算される。この演算処理は、図10のステップS3で行われる。次に、この演算結果とクライアント端末Bが保有する「通信禁止コード」とが比較され(図10のステップS4)、これが一致するため、クライアント端末Bはクライアント端末CXからの通信を許可しない通信と判断し、通信を終了する。
次に、図11(3)に基づいて、図6に示されるY課に属するクライアント端末CYの使用者であるユーザコード8の者が、サーバに接続要求した場合について説明する。
サーバは、図6(1)に示すように、「通信禁止コード」と「通信禁止マスク情報」をその記憶手段200にTCP2設定データベースとして保存している。
そこで、サーバの記憶手段200に保存されている「通信禁止マスク情報」と「クライアント端末CのTCP2アドレス」とが演算され、その論理積(AND)出力が演算結果として出力される。この処理は、図10のステップS3の処理に相当する。
続いて、この演算結果と同じくサーバの記憶手段200に保存されている「通信禁止コード」とが比較される(図10のステップS4)。図11(3)のケースでは、演算結果と「通信禁止コード」とが一致していないため、サーバはクライアント端末CYのユーザコード8の者からの接続要求を許可しない通信とは判断しない。そして、次の許可情報の演算処理を行うことになる。
すなわち、サーバで受信した「クライアント端末CYのTCP2アドレス」とサーバの記憶手段200(TCP2設定データベース)に保存している「通信許可マスク情報」との論理積(AND)を演算する(図10のステップS6)。そして、この演算結果を同じくサーバの記憶手段200に保存している「通信許可コード」と比較する(図10のステップS7)。図11(3)のケースでは、両者が一致しているため許可してもよい通信要求と判断されるので、クライアント端末CYはサーバに接続することが許される。なお、クライアント端末CYの使用者で、例えば、同じY課に属していてもサーバへのアクセス権限のないユーザコード12の者がサーバに対して通信要求を行った場合に、そのユーザコード12の者からの接続を拒否するように設定できることは言うまでもない。
以上説明したように、TCP2を用いたサーバとクライアント端末間、あるいはクライアント端末同士の通信では、それぞれのクライアント端末あるいはサーバに接続許可を与えるクライアント端末あるいは接続を禁止するクライアント端末を自由に設定できるので、情報の漏洩や盗難を防ぐことができ、より確実にクライアント端末間及びクライアント端末とサーバ間通信のセキュリティを保つことができる。
なお、本発明は上述した実施の形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の多くの実施の形態が含まれることは言うまでもない。
本発明による通信システム及び通信方法を利用したネットワークの適用例を示すブロック図である。 本発明で用いるプロトコルスタックの例を示す図である。 本発明で用いられるTCP2アドレスのビット数を企業団体の形態に応じて分類した例である。 本発明に用いられるホストコードの具体的内容を示す図である。 本発明のTCP2アドレス、通信許可コード、通信許可マスク情報、通信禁止コード及び通信禁止マスク情報の具体例を示す図である。 本発明の実施の形態に用いられるセキュリティレベルの異なるクライアント端末間、あるいはクライアント端末とサーバ間の通信を説明するための図である。 TCP2の中のTCPsecを用いた通信の接続処理を示すシーケンス図である。 TCP2の中のUDPsecを用いたブロードキャスト通信の接続処理を示すシーケンス図である。 TCP2の中のUDPsecを用いたユニキャスト通信の接続処理を示すシーケンス図である。 本発明のクライアント端末間の接続処理の動作を示すプローチャートである。 本発明のクライアント端末間の接続処理、及びクライアント端末とサーバ間の接続処理の具体例を説明するための図である。
符号の説明
20、30・・・LAN(Local Area Network)、40・・・外部ネットワーク、A1〜A3・・・セキュリティレベル上位のコンピュータ(端末)、B1〜B3・・・セキュリティレベル中位のコンピュータ(端末)、C1〜C3・・・セキュリティレベル下位のコンピュータ(端末)、D1〜D3 異なるLANに接続されたセキュリティレベル下位のコンピュータ(端末)、IS インストールサーバ、15・・・TCPエミュレータ、16・・・UDPエミュレータ

Claims (12)

  1. 接続要求するコンピュータと該接続要求を受け付けるコンピュータとの間において、TCP又はUDPに該当するプロトコルを取り扱う通信システムであって、
    前記接続要求するコンピュータは、前記TCPパケット又はUDPパケットにコンピュータ及び/又は該コンピュータを使用する者に固有の識別アドレスを付加する手段を有し、
    前記接続要求を受け付けるコンピュータは、前記TCPパケット又はUDPパケットから前記識別アドレスを判別して前記識別アドレスを認証する手段を有し、
    前記接続要求を受け付けるコンピュータにおける前記識別アドレスを認証する手段は、前記識別アドレスが予め設定された範囲で一致する場合には接続を許可し、前記識別アドレスが予め設定された範囲で一致しない場合には接続を拒否することを特徴とする、通信システム。
  2. 前記識別アドレスのビット列は、前記コンピュータのセキュリティレベルに対応して階層化した構造であり、前記認証手段は前記セキュリティレベルに対応して接続を許可又は拒否することを特徴とする、請求項1に記載の通信システム。
  3. 前記識別アドレスを認証する手段は、前記コンピュータのセキュリティレベルに応じて、受信した前記識別アドレスのビット列を部分的にマスクし、上位又は同位のセキュリティレベルのコンピュータからの接続要求に対して接続を許可し、下位のセキュリティレベルのコンピュータからの接続要求に対して接続を拒否することを特徴とする、請求項1又は2に記載の通信システム。
  4. 前記識別アドレスは、IPペイロードに搭載されていることを特徴とする、請求項1〜3のいずれかに記載の通信システム。
  5. 前記IPペイロードは、TCPヘッダであることを特徴とする、請求項4に記載の通信システム。
  6. 接続要求するコンピュータと該接続要求を受け付けるコンピュータとの間において、TCP又はUDPに該当するプロトコルを取り扱う通信方法であって、
    前記接続要求するコンピュータにおいて、前記TCPパケット又はUDPパケットにコンピュータ及び/又は該コンピュータを使用する者に固有の識別アドレスを付加するとともに、
    前記接続要求を受け付けるコンピュータにおいて、前記TCPパケット又はUDPパケットから前記識別アドレスを判別して前記識別アドレスを認証し、
    前記接続要求を受け付けるコンピュータにおける前記識別アドレスの認証の際に、前記識別アドレスのうちの予め設定された範囲が一致する場合には接続を許可し、前記識別アドレスのうちの予め設定された範囲が一致しない場合には接続を拒否することを特徴とする、通信方法。
  7. 前記識別アドレスのビット列は、セキュリティレベルに対応して階層化した構造となっており、前記認証においては前記セキュリティレベルに対応して接続を許可又は拒否することを特徴とする、請求項6に記載の通信方法。
  8. 前記識別アドレスの認証の範囲は、コンピュータのセキュリティレベルに応じて決定されるものであり、前記接続要求を受け付けたコンピュータは、前記受信した識別アドレスのビット列を部分的にマスクすることにより、上位又は同位のセキュリティレベルのコンピュータからの接続要求に対して接続を許可し、下位のセキュリティレベルのコンピュータからの接続要求に対して接続を拒否する、請求項6又は7に記載の通信方法。
  9. 前記識別アドレスの付加は、前記識別アドレスをIPペイロードに搭載することによって行われるものである、請求項6〜8のいずれかに記載の通信方法。
  10. 前記IPペイロードは、TCPヘッダであることを特徴とする請求項9に記載の通信方法。
  11. 接続要求するコンピュータと該接続要求を受け付けるコンピュータとの間において、TCP又はUDPに該当するプロトコルを用いた通信を実行するための通信プログラムであって、
    前記接続要求するコンピュータに搭載される通信プログラムは、少なくともTCPパケット又はUDPパケットにコンピュータ及び/又は該コンピュータを使用する者に固有の識別アドレスを付加する機能を有し、
    前記接続要求を受け付けるコンピュータに搭載される通信プログラムは、少なくともTCPパケット又はUDPパケットから前記識別アドレスを判別して前記識別アドレスを認証する機能を有し、
    前記接続要求を受け付けるコンピュータの前記識別アドレスを認証する機能は、前記識別アドレスが予め設定された範囲で一致する場合には接続を許可し、前記識別アドレスが予め設定された範囲で一致しない場合には接続を拒否する機能であることを特徴とする通信プログラム。
  12. 請求項11に記載の通信プログラムを記憶した、コンピュータ読み取り可能な記録媒体。
JP2005196501A 2005-07-05 2005-07-05 通信方法 Expired - Fee Related JP4696204B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005196501A JP4696204B2 (ja) 2005-07-05 2005-07-05 通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005196501A JP4696204B2 (ja) 2005-07-05 2005-07-05 通信方法

Publications (2)

Publication Number Publication Date
JP2007018082A true JP2007018082A (ja) 2007-01-25
JP4696204B2 JP4696204B2 (ja) 2011-06-08

Family

ID=37755222

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005196501A Expired - Fee Related JP4696204B2 (ja) 2005-07-05 2005-07-05 通信方法

Country Status (1)

Country Link
JP (1) JP4696204B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013102454A (ja) * 2009-01-28 2013-05-23 Meidensha Corp Tcp通信方式
US9769289B2 (en) 2009-01-28 2017-09-19 Meidensha Corporation TCP communication scheme

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1028144A (ja) * 1996-07-12 1998-01-27 Hitachi Ltd アクセス制御機能付きネットワーク構成方式
JP2002007346A (ja) * 2000-06-21 2002-01-11 Hewlett Packard Japan Ltd 通信システム
JP2003223420A (ja) * 2002-01-31 2003-08-08 Fujitsu Ltd アクセス制御方法、記憶装置及び情報処理装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1028144A (ja) * 1996-07-12 1998-01-27 Hitachi Ltd アクセス制御機能付きネットワーク構成方式
JP2002007346A (ja) * 2000-06-21 2002-01-11 Hewlett Packard Japan Ltd 通信システム
JP2003223420A (ja) * 2002-01-31 2003-08-08 Fujitsu Ltd アクセス制御方法、記憶装置及び情報処理装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013102454A (ja) * 2009-01-28 2013-05-23 Meidensha Corp Tcp通信方式
US9769289B2 (en) 2009-01-28 2017-09-19 Meidensha Corporation TCP communication scheme

Also Published As

Publication number Publication date
JP4696204B2 (ja) 2011-06-08

Similar Documents

Publication Publication Date Title
KR101585936B1 (ko) 가상 사설 망 관리 시스템 및 그 방법
JP3783142B2 (ja) 通信システム、通信装置、通信方法、及びそれを実現するための通信プログラム
US6212636B1 (en) Method for establishing trust in a computer network via association
US6993582B2 (en) Mixed enclave operation in a computer network
US7039713B1 (en) System and method of user authentication for network communication through a policy agent
US6067620A (en) Stand alone security device for computer networks
US6643698B2 (en) Mixed enclave operation in a computer network
US7853783B2 (en) Method and apparatus for secure communication between user equipment and private network
US7792993B1 (en) Apparatus and methods for allocating addresses in a network
JP4033868B2 (ja) IPv6ネットワークで認証を処理する方法及びその装置
US20030217148A1 (en) Method and apparatus for LAN authentication on switch
US20020162026A1 (en) Apparatus and method for providing secure network communication
US20110119305A1 (en) Apparatus and Method for Resolving Security Association Database Update Coherency in High-Speed Systems Having Multiple Security Channels
JP2009514072A (ja) コンピュータ資源への安全なアクセスを提供する方法
US6272639B1 (en) Mixed enclave operation in a computer network
AU2003294304B2 (en) Systems and apparatuses using identification data in network communication
CN104620556A (zh) 用于将客户端注册到服务器的方法和设备
CN1523808A (zh) 接入虚拟专用网(vpn)的数据加密方法
JP2004062417A (ja) 認証サーバ装置、サーバ装置、およびゲートウェイ装置
JP4696204B2 (ja) 通信方法
JPH11331181A (ja) ネットワーク端末認証装置
EP1480406A1 (en) Confinement of data transfers to a local area network
JP2005202970A (ja) ファイアウォールのためのセキュリティシステムおよびセキュリティ方法ならびにコンピュータプログラム製品
JP4785654B2 (ja) 通信システム、アドレス解決方法、通信プログラム及び記録媒体
KR20040088137A (ko) 전송 암호화키 값 생성방법과 이를 적용한 상호인증보안방법

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20080313

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080702

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20090507

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20090515

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100916

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100921

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101122

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: 20101214

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20101216

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110107

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110106

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110203

R150 Certificate of patent or registration of utility model

Ref document number: 4696204

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees