JP4183664B2 - 認証方法、サーバ計算機、クライアント計算機、および、プログラム - Google Patents

認証方法、サーバ計算機、クライアント計算機、および、プログラム Download PDF

Info

Publication number
JP4183664B2
JP4183664B2 JP2004223137A JP2004223137A JP4183664B2 JP 4183664 B2 JP4183664 B2 JP 4183664B2 JP 2004223137 A JP2004223137 A JP 2004223137A JP 2004223137 A JP2004223137 A JP 2004223137A JP 4183664 B2 JP4183664 B2 JP 4183664B2
Authority
JP
Japan
Prior art keywords
connection request
authentication
information
authentication information
encryption key
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.)
Expired - Fee Related
Application number
JP2004223137A
Other languages
English (en)
Other versions
JP2005122695A (ja
Inventor
健太郎 梅澤
俊成 高橋
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004223137A priority Critical patent/JP4183664B2/ja
Priority to US10/948,699 priority patent/US7366170B2/en
Publication of JP2005122695A publication Critical patent/JP2005122695A/ja
Priority to US12/003,924 priority patent/US7940761B2/en
Application granted granted Critical
Publication of JP4183664B2 publication Critical patent/JP4183664B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、ネットワーク上のクライアント計算機とサーバ計算機との間で通信を行うための認証方法、サーバ計算機、クライアント計算機、および、プログラムに関する。
近年、インターネット等を利用し、不特定多数あるいは特定多数のクライアント計算機をパケット交換ネットワーク経由でサーバ計算機に接続し、クライアント計算機からの要求に応じてサーバ計算機からデータを供給することを目的とするクライアントサーバシステムが広く使われている。
ここで、パケットとは、ネットワーク上を流れるひとかたまりのデータをいい、大まかに分けると、ヘッダとデータ本体で構成されている。さらに、ヘッダ内には、始点IP(Internet Protocol)アドレス、終点IPアドレス等から構成されている。このようなTCP/IP(Transmission Control Protocol/IP)プロトコルにおける正当なアクセス要求の一例としては、(1)クライアント計算機はサーバ計算機へ接続要求パケット(SYN(SYNchronize)パケット)を送信し、(2)サーバ計算機はクライアント計算機へ接続要求確認パケット(SYN+ACK(ACKnowledgement)パケット)を送信し、(3)クライアント計算機はサーバ計算機へ確認応答パケット(ACK)パケットを送ることによって、論理的な通信路(コネクション)を確立し、そのコネクション確立(Established)状態で上位アプリケーションでのデータの送受信をおこなう。このアクセス要求を、3 way handshake 方式と呼ぶ。
上述したクライアント計算機とサーバ計算機とからなるクライアントサーバシステムにおいて、サーバ計算機がクライアント計算機に対してサービスを提供する際に、サーバ計算機が接続要求元(クライアント計算機の利用者あるいはクライアント計算機自体を指す)の識別を行い、識別した相手の権限に応じてサービスを提供する場合がある。
このような識別作業(認証)と権限の決定および権限に応じたサービスの提供(以後、識別作業・権限の決定・サービスの提供をまとめてアクセス制御と呼ぶ)は、サーバ計算機がクライアント計算機との通信用リソースを割り当てた後で一般的に次のように行われる場合が多い。
(1)クライアント計算機からの接続要求に従いクライアント計算機とサーバ計算機の間にコネクションが確立され、
(2)サーバ計算機のサーバアプリケーションプログラムがクライアント計算機のクライアントアプリケーションプログラムに対してパスワードなどの認証情報(共通鍵暗号や公開鍵暗号を利用した方式、さらには様々な暗号プロトコルを利用したものもある)の送信を促すデータを送信し、
(3)クライアントアプリケーションはそのデータを受信し、次にそのデータに従って認証情報を取得し、サーバ計算機に送信し(ここで認証情報は利用者の入力もしくはアプリケーションによって自動的に取得される)、
(4)サーバアプリケーションプログラムは取得した認証情報の正当性を検証し、正当と判断された接続要求元に対して権限を決定し、その権限に応じたサービスを提供する。
上述したアプリケーションレベルでのアクセス制御方式を用いることで、不特定多数のクライアントから正当な接続要求元を選別し、その権限に見合ったサービスを提供できる。
しかしながら、上述のアクセス制御方式はコネクションの確立を前提とした方式であるため、コネクションの確立自体を制御することは出来ない。そのため、不正なクライアントがコネクションを大量に確立することでサーバ計算機のコネクション処理用リソースを使い切るタイプのDoS攻撃(Denial of Service attack)及びDDoS攻撃(Distributed Denial of Service attack)を防ぐことはできない。ここで、DoS攻撃とは、正当なクライアントが使用するはずのリソースを、不正なクライアントが使い切る、もしくはリソースを使えない状態にすることで、正当な使用者によるリソース使用を妨げるハッキング行為である。そして、DDoS攻撃は複数のクライアント計算機によって行われるDoS攻撃を指す。
また、上述のアクセス制御はアプリケーションでの処理を前提とした方式であるため、攻撃者によるソフトウェア脆弱性に対する攻撃を防ぐことはできない。ソフトウェア脆弱性に対する攻撃とは、アプリケーションソフトウェアに潜在するバグに対する攻撃であり、攻撃者はバグを利用することで、攻撃対象の計算機の認証処理を迂回したり、その計算機での特権を得たりすることが可能となる。例えば、インターネット越しに計算機の安全な遠隔操作を実現するプロトコルであるSSH(Secure Shell)の認証部分にソフトウェア脆弱性が存在した場合、攻撃者は正当な認証情報の代わりに攻撃コードを送信することでその計算機を利用することが可能となる。
このようなアプリケーションでのアクセス制御だけでは必ずしも防ぎきれない問題はTCP/IPのTCP層、IP層でクライアント計算機に対するアクセス制御を行うことで解決することができ、それによりサーバ計算機のセキュリティをより一層向上させることが可能である。このような方式の従来技術として、サーバ計算機に接続を許可/不許可とする始点IPアドレス、終点ポート番号などを記載したリストを保持させ、受信したパケットに対してその情報に基づいた検査を実施することで接続の可否を決定する方法がある。
この始点IPアドレス、終点ポート番号にもとづいたアクセス制御には次のような問題点がある。
(1)IPアドレス偽造に弱い:一般的にIPアドレスの偽造は容易であり、ポート番号は自由に指定可能である。そのため不正なクライアント計算機が始点IPアドレスを偽造したパケットを送信することで容易に迂回されてしまう。
(2)利用者の識別は不可能:始点IPアドレスによりクライアント計算機を識別することは可能であるが、そのクライアント計算機が複数の利用者によって利用されている場合に、それらの利用者の区別を行うことは出来ない。
(3)動的IPアドレスに対応不可能:IPアドレスによるアクセス制御方式では、予めアクセス制御をおこなうクライアント計算機のIPアドレスを登録しておく必要がある。しかし、モバイル環境やDHCP(Dynamic Host Configuration Protocol)環境では、クライアント計算機のIPアドレスは動的に変化するため、このアクセス制御方式は利用できない。
これらIPアドレス、ポート番号を利用したアクセス制御方式の問題点を解決する従来技術として、ポートアクセスを利用した認証方法がある(例えば、特許文献1参照)。
この方法は、(1)クライアント計算機はサーバ計算機の複数の認証用ポートに対してパケットを送信し、(2)サーバ計算機はクライアント計算機が全ての認証用ポート(具体的なポート番号は秘匿されている)にアクセスしたことの確認を行い、(3)全ての認証用ポートにアクセスされたサーバ計算機は、通信用ポート(具体的なポート番号は公開されている)をオープンし、(4)クライアント計算機はサーバ計算機の通信用ポートにアクセスし通信を行う、ようにする。この方法は、クライアント計算機のサーバ計算機に対するアクセスパターンを接続要求元の識別情報として利用したものであるといえる。
この方法によれば、不正なクライアントは複数の認証用ポートを知らないため、サーバ計算機とコネクションの確立ができない。そのため、従来のIP層、TCP層でのアクセス制御と同様にアプリケーションでの認証方法の問題点を解決できる。そして、アクセスパターン(ここでは認証用ポート番号の組)を利用者と対応付けておくことで、同一のクライアント計算機を利用している利用者の識別も可能となる。また、この方法では、同一IPアドレスからの認証用ポートに対するアクセスを考えればよく、あらかじめ許可/不許可のIPアドレスを定めておく必要はない。
このように、この方法を利用することによってアプリケーションのアクセス制御の問題を解決しつつ、「利用者の識別が不可能」、「動的IPアドレスに対応不可能」という2点に関しては従来のTCP層、IP層でのアクセス制御の問題点が解決できた。
特開2003−91503公報
TCP層でのアクセスパターンを利用した認証方式により、従来のTCP層、IP層でのアクセス制御方式における問題の一部は解決できた。しかしながら、この認証方法ではIPアドレスの偽造による攻撃を完全には防ぐことはできない。この方法では、サーバ計算機はクライアント計算機が全ての認証用ポート(ポート番号は非公開)にアクセスしたことを確認後、通信用ポート(ポート番号は公開)をオープンし、そこへ接続してくるクライアント計算機を正当な接続要求元と判断する。しかし、通信用ポートに接続してきたクライアント計算機と認証用ポートをアクセスしたクライアント計算機が、同一の接続要求元であるか否かの判定を行わないため、例えば、正当な接続要求元が認証用ポートにアクセスし通信用ポートがオープンされたタイミングを見計らって、不正クライアントがオープンされた状態の通信用ポートにアクセスするのを防ぐことは出来ない。このように、従来方法ではIPアドレス偽造を用いることで、認証用ポートを知らない不正クライアントでもコネクションを確立することが可能であるといった問題があった。
本発明は、上記問題点に鑑みなされたものであり、IPアドレス偽造による不正アクセスにも耐性を備えた、認証方法、サーバ計算機、クライアント計算機、および、プログラムを提供することを目的とする。
本発明の一実施形態に係る認証方法は、ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で、通信を開始するようにしたサーバ計算機の認証方法であって、前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納しておき、前記ネットワークから複数の接続要求パケットを受信し、該受信した前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証し、該認証の結果、正しく認証された場合に、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを生成し、該生成した接続要求確認パケットをネットワークへ送出するようにするものであって、前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、前記認証は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって行われることを特徴とする。
本発明の一実施形態に係るサーバ計算機は、ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で、通信を開始するようにしたサーバ計算機であって、前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納する格納手段と、前記ネットワークから複数の接続要求パケットを受信する受信手段と、前記受信手段で受信した前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証する認証手段と、前記認証手段での認証の結果、正しく認証された場合に、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを生成する生成手段と、前記生成手段で生成された接続要求確認パケットをネットワークへ送出する送出手段とを備え、前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、前記認証手段は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって認証することを特徴とする
本発明の一実施形態に係るプログラムは、ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で通信を開始する、サーバ計算機で実行されるプログラムであって、前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納させる第1のコードと、前記ネットワークから複数の接続要求パケットを受信させる第2のコードと、該受信された前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証させる第3のコードと、該認証の結果、正しく認証された場合に、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを生成させる第4のコードと、前記生成手段で生成された接続要求確認パケットをネットワークへ送出させる第5のコードとを備え、前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、前記認証は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって行われることを特徴とする、サーバ計算機で実行されるプログラム。
本発明の一実施形態に係るクライアント計算機は、ネットワークを介して接続されるサーバ計算機と通信するための接続要求を行うクライアント装置であって、前記サーバ計算機によって保持される第2暗号鍵と対応する第1暗号鍵を、秘密裏に格納する格納手段と、前記第1暗号鍵による暗号処理によって生成される認証情報を分割し、前記分割した分割認証情報を複数の接続要求パケットに付加する手段と、前記複数の接続要求パケットを前記サーバ計算機へ送信する送信手段と、前記サーバ計算機から、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを受信する受信手段とを備え、前記付加手段は、前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットに、複数の前記分割認証情報を前記認証情報へ復元するための復元情報を付加し、前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しい場合に、前記受信手段は、前記接続要求確認パケットを受信し、前記接続要求確認パケットに応じて、前記サーバ計算機との通信を開始することを特徴とする。
本発明によれば、不正なクライアント計算機では、IPアドレスを偽造した不正な接続要求パケットをサーバ計算機へ送信しても、コネクションを確立するための接続要求確認パケットを得ることができないから、IPアドレスの偽造による攻撃に強く、アプリケーションでのアクセス制御、IPアドレスでのアクセス制御の問題が解決できる認証方法が実現でき、それにより当該サーバ計算機のセキュリティをより一層向上させることができる。
以下、本発明の実施の形態につき図面を参照して説明する。
図1は、本実施の形態が適用される通信システムを示すものであり、サーバ計算機1とクライアント計算機2とは、インターネットなどのオープンなネットワークおよびそれに接続された専用線などを含む各種通信ネットワーク3で接続される。
一般に、サーバ計算機1とクライアント計算機2との間の通信は、TCP/IPで行われる。TCP/IPは、下位層から上位層へ順にネットワークアクセス層、ネットワーク層、トランスポート層、アプリケーション層に分離される。
ネットワークアクセス層は、OSI(Open Systems Interconnection)参照モデルの物理層、データリンク層を合わせたものに相当し、電気信号や光信号によるデータの送受信と、隣接ノードとの間で情報のフローを調整するために必要な制御を可能とする処理層である。
ネットワーク(インターネット)層は、OSI参照モデルのネットワーク層に相当し、ネットワーク間でのデータのルーティングと通信目的の計算機へのデータ配信に責任を負う処理層である。
トランスポート層は、OSI参照モデルのトランスポート層にほぼ相当し、指定されたアプリケーション層ポートへの配信サービスとデータのエラーチェック機能を提供する処理層である。トランスポート層では、TCP(Transmission Control Protocol)とUDP(User Datagram Protocol)の2つのプロトコルが利用可能である。後述するようにTCPではコネクション型環境を提供し、データの到達性を保証する。それに対して、UDPはコネクションレス型環境を提供し、データの到達性を保証しない。
アプリケーション層は、OSI参照モデルのアプリケーションに相当し、アプリケーションがデータ送受信を行うための通信処理制御や、アプリケーション固有の処理を行う処理層である。
ネットワーク層より上位層での通信は、IPパケットで行われる。図2に一般的なIPパケットの構成を示す、IPパケットは、IPヘッダ部とデータ部とから構成される。
IPヘッダ部は、IPのバージョン(IPv4、IPv6等)を示すバージョン、IPヘッダ部のヘッダ長を示すヘッダ長、通信サービスの品質をルータに指示するためのサービスタイプ、IPパケット全体の長さを示すパケット長、フラグメントを復元する際の識別子である識別子、分割処理を制御するためのフラグ、分割された場合の位置を示すためのフラグメントオフセット、通過できるルータの個数を示す生存時間、上位層のプロトコルを示すプロトコル番号(ICMPは1、TCPは6、UDPは17)、データが破損していないことを保証するためのヘッダチェックサム、送信元のアドレスを示す始点IPアドレス、送信先のアドレスを示す終点IPアドレス、種々のオプション機能に利用するためのオプション、IPヘッダのヘッダ長が32ビットの整数倍になるよう調整するパディングの各情報からなる。
データ部は、TCP、UDP、または、ICMPのセグメントが含まれる。
図3は、一般的なTCPセグメントの構成を示している。TCPセグメントは、TCPヘッダとデータ部分から構成される。TCPヘッダは、送信元のポート番号を示す始点ポート番号、送信先のポート番号を示す終点ポート番号、送信したデータの位置を示すシーケンス番号、受信したデータの位置を示す確認応答番号、TCPが運んでいるデータの開始位置を示すデータオフセット、拡張用の予約ビット、TCPセグメントの処理方法や種別を示すコントロールフラグ、フロー制御に用いられ、受信可能なデータ長を示すウィンドウサイズ、TCPのヘッダ、データが損傷していないことを保証するためのチェックサム、緊急に処理すべきデータの位置を示す緊急ポインタ、TCPによる通信性能の向上に用いるオプション、および、パディングの各情報からなる。
図4は、一般的なUDPセグメントの構成を示している。UDPセグメントは、UDPヘッダとデータ部分とから構成される。UDPヘッダは、送信元のポート番号を示す始点ポート番号、送信先のポート番号を示す終点ポート番号、このUDPセグメントの長さを示すパケット長、UDPのヘッダ、IPアドレス、プロトコル番号が損傷していないことを保証するためのチェックサム、の各情報からなる。
TCPは、一般的に1)クライアント計算機がサーバ計算機へ接続要求パケット(SYN(SYNchronize)パケット)を送信し、2)サーバ計算機がクライアント計算機へ接続要求確認パケット(SYN+ACK(ACKnowledgement)パケット)を送信し、3)クライアント計算機がサーバ計算機へ確認応答パケット(ACK)パケットを送る、という手順の3 way handshake方式により機器同士で論理的なポート間で通信路(コネクション)を確立し、その上で上位アプリケーションでのデータの送受信を行う。なお、論理的なポートは、65535番まで利用することが許可されている。
これに対して、UDP、ICMPは、コネクションレスの通信であるため、このようなコネクション確立の処理は行われず、データの送受信が行われる。
(第1の実施の形態)
以下に、第1の実施の形態を詳細に説明する。
図5は、クライアント計算機2のうち、第1の実施の形態に係る部分の機能ブロックを示したものである。
接続要求パケット生成部21は、サーバ計算機1への接続要求を行う旨の指示を受けた際に、接続要求パケットを生成するものである。接続要求パケット生成部21は、コネクション確立テーブル100を参照し、サーバ計算機1との接続の際に使用する複数の認証用ポートの番号を取得し、順次、各認証用ポート番号毎に接続要求パケットを作成する。
コネクション確立テーブル100には少なくとも認証用のポート番号を記憶しており、その認証用のポート番号は、クライアント計算機2とサーバ計算機1との間で秘密に共有されている。このポート番号の共有は、暗号プロトコルを用いて確保されたセキュアチャネル(このような既存技術としてはSSL(Secure Socket Layer)などがある)を利用してオンラインで行ったり、郵送などのオフラインで行ったりするなどして第三者に秘匿して共有される。なお、接続要求元は複数のサーバに応じて異なる判定基準の情報を保持していてもよい。
送信部22は、IPパケットをネットワーク3へ送出するものであり、接続要求パケット生成部21によって順次生成された各接続要求パケットをネットワーク3へ順次送出する。
受信部23は、ネットワークからIPパケットを受信するものである。この受信したIPパケットは、接続要求確認パケット判定部24へ送られ、このIPパケットが、送信部22より送信した各接続要求パケットの何れかに対して応答された接続要求確認パケットであるか否かを判定する。これにより接続要求確認パケットであると判定された場合には、クライアント計算機2はサーバ計算機1とのコネクションを確立するための処理を行なう。
図6は、サーバ計算機1のうち、第1の実施の形態に係る部分の機能ブロックを示したものである。
受信部11は、ネットワーク3からの自サーバ計算機2宛てのIPパケットを受信するものである。判断部12は、受信部11で受信したIPパケットが接続要求パケットであるとき、少なくとも認証用のポート番号を複数含むアクセスパターン情報を記憶した判定用テーブル110を参照し、正当な接続要求元であるか否かを判断する。これら認証用のポート番号は、先に示したように、クライアント計算機2とサーバ1との間で秘密に共有されたものである。判定用テーブル110、クライアント計算機2ごとに、認証用ポートの個数や認証用ポートが個別に定められている場合には、クライアント計算機2ごとにそれぞれエントリを持つようにすればよい。
正当な接続要求元であると判断されたとき、受信管理部13は、受信した接続要求パケットをパケット記憶部17に一時格納するとともに、コネクション制御テーブル120へ接続要求パケットを送信したクライアント計算機2を識別可能な情報(例えば始点IPアドレス)と終点ポート番号、すなわちクライアント計算機2で指定された自サーバ計算機1で使用したポート番号(=認証用のポート番号)を含む情報を登録する。このとき、既にコネクション制御テーブル120にこのクライアント計算機1の識別可能な情報がある場合には、そのエントリに終点ポート番号を追加すればよく、一方、該情報がない場合には、新たなエントリを作成すればよい。
監視部14は、コネクション制御テーブル120に登録される各エントリが、コネクションの確立の条件が満たされることを監視する。コネクションの確立の条件は、ここでは、判定用テーブル110に記憶されるクライアント計算機2のアクセスパターン情報をすべて満たすことである。監視部14は、コネクションの確立の条件が満たされたとき、接続要求確認パケット生成部15へその旨通知する。
接続要求確認パケット生成部15は、コネクションの確立の条件が満たされた旨の通知を受けたとき、パケット記憶部17に記憶される、応答するクライアント計算機2からの複数の接続要求パケットのうち所定の一つのパケットのみを参照し、応答のための接続要求確認パケットを生成する。また、接続要求確認パケット生成部15は、接続要求確認パケットの生成後、そのクライアント計算機2からの接続要求パケットの全てをパケット記憶部17から削除する。
送信部16は、接続要求確認パケット生成部15で生成された接続要求確認パケットをネットワーク3へ送出する。なお、この送出された接続要求確認パケットは、先に説明したクライアント計算機2の受信部13で受信される。
ところで、クライアント計算機2とサーバ計算機1との間で共有する複数の認証用のポート番号は、単独、あるいは他の情報と組み合わせた、様々な認証方法を用いることが可能である。
以下で、各認証方法を例示し、その際の、クライアント計算機2とサーバ計算機1との動作について説明する。
(第1の実施の形態の第1実施例)
まず、複数の認証用のポート番号のみを利用して認証する場合について説明する。
図7は、この際の、コネクション確立テーブル101、判定用テーブル111、コネクション制御テーブル121を示したものである。
コネクション確立テーブル101は、認証が必要なサーバ計算機1を識別するためのサーバ名と、それら各サーバ計算機1のそれぞれと認証するために必要な複数のポート番号の組とを対応付けて記憶している。なお、上記で説明したように、それぞれの認証用のポート番号は、クライアント計算機2と各サーバ計算機1との間でそれぞれ秘密に共有されたものである。
判定用テーブル111は、クライアント計算機2が、このサーバ計算機1へ接続するための認証用として必要な複数のポート番号の組を記憶したものである。それぞれの認証用のポート番号は、クライアント計算機2とサーバ計算機1との間でそれぞれ秘密に共有されたものである。なお、ここでは、全てのクライアント計算機2に対し共通に、認証用のポート番号の組を用いているが、クライアント計算機2ごとにそれぞれ異なるポート番号の組を決めておき、それらを各クライアント計算機2を識別する識別情報と対応づけて格納するようにしても良い。
コネクション制御テーブル121は、現在、サーバ計算機1へコネクションを確立するためにアクセス処理を行っている各クライアント計算機2の進捗状況を示すものであり、クライアント計算機2から正当なポート番号でアクセスを受けるごとに、そのクライアント計算機2を識別するための識別情報に対応付けて、受けたアクセスのポート番号を記憶するものである。
図8は、クライアント計算機2の処理手順を示すフローチャートであり、図9はサーバ計算機1の処理手順を示すフローチャートである。まず、クライアント計算機2の処理手順について説明する。
クライアント計算機2は、サーバ計算機1とコネクションを確立しようとする場合、まず、接続要求パケット生成部21がコネクション確立テーブル101を参照して複数の認証用ポートのいずれか一つに接続要求パケットを生成し、送信部22によって送信する(ステップC101)。
次に、接続要求パケット生成部21は、再度コネクション確立テーブル101を参照して、まだ接続要求パケットを送信していない認証用ポートに対して接続要求パケットを送信する(ステップC102)。そして、接続要求パケット生成部201は、コネクション確立テーブル101を参照して全ての認証用ポートに接続要求パケットを送信したか否かを確認する(ステップC103)。
まだ、接続要求パケットを送信していない認証用ポートが存在する場合には、まだ接続要求パケットを送信していない認証用ポートに対して接続要求パケットを送信する(ステップC102)。一方、全ての認証用ポートに接続要求パケットを送信したことを確認すると、サーバ計算機1からの接続要求確認パケットを待ち受ける(ステップC104)。
クライアント計算機2は、サーバ計算機1からの応答があったかを判断し(ステップC105)、応答がない場合には認証に失敗したものとして処理を終了する。サーバ計算機1から複数の接続要求パケットのいずれかに対する接続要求確認パケットを受信した場合には、それに対して応答確認パケットを送信する(ステップC106)。これにより、クライアント計算機とサーバ計算機の間にはコネクションが確立される。
次に、サーバ計算機1の処理手順について説明する。
サーバ計算機1は、受信部11で接続要求パケットを受け付ける(ステップS101)と、判定用テーブル111を参照し、接続要求パケットの終点ポート番号が複数の認証用ポート番号のいずれかであるか否かを判定する(ステップS102)。なお、クライアント計算機2ごとに異なる認証用のポート番号の組を用いる場合には、接続要求パケットの例えば始点IPアドレスに基づいてクライアント計算機2を特定して、判定用テーブル111のそのクライアント計算機2のエントリを参照し、判定すれば良い。
もし、接続要求パケットの宛先が認証用のポート番号でない場合、接続要求パケットを破棄し、次の接続要求パケットを待ち受ける(ステップS107)。
接続要求パケットの宛先ポートが認証用ポートの一つであると判断された場合、この接続要求パケットをパケット記憶部17に一時的に記憶し、コネクション制御テーブル121を参照し、接続要求元のエントリの有無を調べる(ステップS103)。ここで、本実施形態では、コネクション制御テーブル121において接続要求元を識別するための情報をクライアント計算機のIPアドレスとしているが、MACアドレスやその他の識別子であってよい。つまり、この認証処理の間に接続要求元を識別するために利用可能な情報であれば良い。そして、コネクション制御テーブル121に、接続要求元がエントリされていない場合は、接続要求元用のエントリを追加する(ステップS104)。
次に、コネクション制御テーブル121の、そのクライアント計算機2のエントリに今回接続要求パケットが送信された認証用のポート番号を記憶する(ステップS105)。
監視部104は、コネクション制御テーブル121と判定用テーブル111とを参照し、全ての認証用のポート番号へ、接続要求パケットが送信されたか、否かを確認する(ステップS106)。
まだ、接続要求パケットが送信されていない認証用のポート番号が存在する場合には、さらに接続要求パケットを待ち受ける(ステップS101)。一方、全ての認証用のポート番号に接続要求パケットが送信されたと判断された場合には、応答パケット生成部15で、クライアント計算機2からの複数の接続要求パケットのいずれか一つに対して接続要求確認パケットを生成し、送信部106によって接続要求確認パケットをネットワーク3へ送出する(S108)。
ここで、複数の接続要求パケットの何れに対し、接続要求確認パケットを返信するかについては、次のような方法が考えられる。
1)最後の接続要求パケットに対して返信する。
2)複数の認証用のポート番号を予め定めておき、これに対し返信する
3)接続要求パケットの到着順位を予め定めておき、その到着順位の接続要求パケットに対し返信する。
以上の何れかの方法を予め定めておけば、ステップS103で接続要求パケットをパケット記憶部113で全て記憶することとして説明したが、これを、対象となる一つの接続要求パケットだけを記憶するように変更すれば、パケット記憶部113を小さくできる。
また、接続要求確認パケットを返信する方法をクライアント計算機2とあらかじめ共有しておくようにすれば、クライアント計算機2は送信したうちの特定の1つの接続要求パケットに対して接続要求確認パケットを待ち受ければよくなる。それによりクライアント計算機2の処理用リソースが減少するという効果が期待できる。
サーバ計算機1の処理手順の説明に戻る。
ステップS108で、接続要求確認パケットを送出した後、パケット記憶部17、および、コネクション制御テーブル112に記憶される、その接続要求元の接続要求パケット、および、エントリを削除する(ステップS109)。
この後、接続要求元からの応答確認パケットを受信しコネクションを確立することによって、クライアント計算機2とサーバ計算機1との各アプリケーション間で、通信を行うことができる。
この実施形態によれば、認証用ポートを知らない不正クライアントが、認証に成功したクライアント計算機のIPアドレスを偽造して接続するという攻撃を防ぐことができる。このことにより従来よりも安全性の向上した認証を行うことが可能となる。
なお、本実施形態では、複数の接続要求パケットに含まれる認証用ポートのポート番号を秘密情報として扱ったが、各ポート番号を秘密情報とせず、ポート番号以外のヘッダのフィールドで通常の通信に問題を引き起こさないフィールドのデータを秘密情報として利用する方法も考えられる。例えば、TCPヘッダのシーケンス番号、確認応答番号、予約ビット、ウィンドウサイズなどその他のフィールドの値を秘密情報として利用すれば良い。
(第1の実施の形態の第2実施例)
次に、複数の認証用のポート番号およびそれらのアクセス順を利用して認証する場合について説明する。
図10は、この際の、コネクション確立テーブル102、判定用テーブル112、コネクション制御テーブル122、および、受信部11に接続され、新たに追加した順序設定テーブルを132示したものである。
コネクション確立テーブル102は、認証が必要なサーバ計算機1を識別するためのサーバ名と、それら各サーバ計算機1のそれぞれと認証するために必要な複数のポート番号の組と、これらポート番号へのアクセス順序とを対応付けて記憶している。なお、上記で説明したように、それぞれの認証用のポート番号は、クライアント計算機2と各サーバ計算機1との間でそれぞれ秘密に共有されたものである。
判定用テーブル112は、クライアント計算機2が、このサーバ計算機1へ接続するための認証用として必要な複数のポート番号の組と、これらポート番号へのアクセス順序を記憶したものである。それぞれの認証用のポート番号は、クライアント計算機2とサーバ計算機1との間でそれぞれ秘密に共有されたものである。なお、ここでは、全てのクライアント計算機2に対し共通に、認証用のポート番号の組およびアクセス順序を用いているが、クライアント計算機2ごとにそれぞれ異なるポート番号の組を決めておき、それらを各クライアント計算機2を識別する識別情報と対応づけて格納するようにしても良い。
コネクション制御テーブル122は、現在、サーバ計算機1へコネクションを確立するためにアクセス処理を行っている各クライアント計算機2の進捗状況を示すものであり、クライアント計算機2から正当なポート番号およびアクセス順序でアクセスを受けるごとに、そのクライアント計算機2を識別するための識別情報に対応付けて、受けたアクセスのポート番号を追記式で記憶するものである。
順序設定テーブル132は、各クライアント計算機2からの何回目の接続要求パケットを受信したかを管理するものであり、各クライアント計算機2から1回目の接続要求パケットを受信した時、各クライアント計算機2を識別する識別情報(例えばIPアドレス)と受信回数を示す情報“1”とを対応付けて記録し、2回目以降はこの識別番号に対応する受信回数を示す情報を1ずつインクリメントさせて更新される。
図11は、クライアント計算機2の処理手順を示すフローチャートであり、図12はサーバ計算機1の処理手順を示すフローチャートである。まず、クライアント計算機2の処理手順について説明する。
クライアント計算機2がサーバ3にコネクションを確立しようとする場合、まずコネクション確立テーブル102を参照して(i=)1番目に規定された認証用ポートに接続要求パケットを送信する(ステップC21、C22)。次に、iの値をインクリメントし、再度コネクション確立テーブル102を参照して、(i=)2番目に規定された認証用ポートに対して接続要求パケットを送信する(ステップC23、C24)。そして、コネクション確立テーブル102を参照してN番目までの全ての認証用ポートに接続要求パケットを送信したかどうか確認する(ステップC25)。
まだ、接続要求パケットを送信していない認証用ポートが存在する場合には、iの値をインクリメントして、i番目の認証用ポートに対して接続要求パケットを送信する(ステップC23、C24)。
一方、全ての認証用ポートに規定の順番で接続要求パケットを送信したことを確認すると、サーバ計算機1からの接続要求確認パケットを待ち受ける(ステップC26)。
サーバ計算機1からの応答があったかを判断し(ステップC27)、応答がない場合には認証に失敗したものとして処理を終了する。
一方、サーバ計算機1から複数の接続要求パケットのいずれかに対する接続要求確認パケットを受信した場合には、それに対して応答確認パケットを送信する(ステップC28)。これにより、クライアントとサーバの間にはコネクションが確立される。
次に、サーバ計算機1の処理手順について説明する。
受信部11は、順序設定テーブルに基づいて、クライアント計算機2からの接続要求パケットの順番を示す変数iに1を設定して(ステップS201)、i番目の接続要求パケットを受け付ける(ステップS202)と、判定用テーブル112を参照して接続要求パケットの宛先ポートがi番目の認証用ポートであるかどうか判定する(ステップS203)。
もし、接続要求パケットの宛先がi番目の認証用ポートでない場合、接続要求パケットを破棄し、次の接続要求パケットを待ち受ける(ステップS204)。接続要求パケットの宛先ポートがi番目の認証用ポートであると判断された場合、コネクション制御テーブル122を参照し、接続要求元のエントリの有無を調べる(ステップS205)。コネクション制御テーブル122に接続要求元のエントリが存在しない場合は、エントリを追加する(ステップS206)。
次に、接続要求パケットの順番を示す変数iをインクリメントする(ステップS207)。そして、サーバはコネクション制御テーブル122と判定用テーブル112をあわせて参照し、接続要求パケットが順番どおりに全ての認証用ポートに送信されているか確認する(ステップS208)。送信されていない場合は、クライアント計算機2からのi番目の接続要求パケットを受け付ける(ステップS202)。
接続要求パケットが順番どおり全ての認証用ポートで受信できた場合には、クライアント計算機からの複数の接続要求パケットのいずれか一つに対して接続要求確認パケットを送信する(ステップS209)。そして、コネクション制御テーブル122に存在する接続要求元のエントリを削除する(ステップS210)。
この後は、接続要求元からの応答確認パケットを受信しコネクションを確立した上でアプリケーション間での通信を行うことができる。
この例では、不正アクセスを行うためには認証用ポートのポート番号だけではなく、そのアクセス順番も推測する必要があるため、サーバのセキュリティがより一層向上する。
(第1の実施の形態の第3実施例)
次に、複数の認証用のポート番号およびそれらをアクセスする際の制限時間を規定して認証する場合について説明する。
図13は、この際の、コネクション確立テーブル103、判定用テーブル113、コネクション制御テーブル123を示したものである。
コネクション確立テーブル103は、認証が必要なサーバ計算機1を識別するためのサーバ名と、それら各サーバ計算機1のそれぞれと認証するために必要な複数のポート番号の組と、これらポート番号へアクセス可能な期間とを対応付けて記憶している。このアクセス可能期間とは、クライアント計算機2が最初にサーバ計算機へのアクセスを開始してからの期間を示す。なお、上記で説明したように、それぞれの認証用のポート番号は、クライアント計算機2と各サーバ計算機1との間でそれぞれ秘密に共有されたものである。
判定用テーブル113は、クライアント計算機2が、このサーバ計算機1へ接続するための認証用として必要な複数のポート番号の組と、これらポート番号へのアクセス可能な期間を記憶したものである。それぞれの認証用のポート番号は、クライアント計算機2とサーバ計算機1との間でそれぞれ秘密に共有されたものである。なお、ここでは、全てのクライアント計算機2に対し共通に、認証用のポート番号の組およびアクセス期間を用いているが、クライアント計算機2ごとにそれぞれ異なるポート番号の組、および/またはアクセス期間を決めておき、それらを各クライアント計算機2を識別する識別情報と対応づけて格納するようにしても良い。
コネクション制御テーブル122は、現在、サーバ計算機1へコネクションを確立するためにアクセス処理を行っている各クライアント計算機2の進捗状況を示すものであり、クライアント計算機2から正当なポート番号でアクセスを受けるごとに、そのクライアント計算機2を識別するための識別情報に対応付けて、受けたアクセスのポート番号を記憶するものである。
図14は、サーバ計算機1の処理手順を示すフローチャートである。なお、クライアント計算機2の処理手順は図7のフローチャートに従う。クライアント計算機2が、サーバ計算機3にコネクションを確立しようとする場合の処理フローは、図7の説明と同様である。ただし、処理効率の向上の為に、制限時間と比較して接続要求パケット送信に時間がかかった場合などはサーバ計算機1からの接続要求パケットの待ち受け作業を行わずに処理を終了するなどといった変形は考えられる。
サーバ計算機1は、接続要求パケットを受け付ける(ステップS301)と、判定用テーブル113を参照して接続要求パケットに含まれる終点ポート番号が、複数の認証用ポートのいずれかであるかどうか判定する(ステップS302)。もし、接続要求パケットの宛先が認証用ポートでない場合、接続要求パケットを破棄し、コネクション制御テーブルにエントリがあればそれを削除し、次の接続要求パケットを待ち受ける(ステップS303)。
一方、接続要求パケットに含まれる終点ポート番号が認証用ポートの一つであると判断された場合、コネクション制御テーブル123を参照し、接続要求元のエントリの有無を調べる(ステップS304)。コネクション制御テーブル123に接続要求元がエントリされていない場合は、接続要求元のエントリ(接続要求元の識別子、ここではクライアント計算機2のIPアドレス)を追加する(ステップS305)。
次に、クライアント計算機2の認証開始からの時間を計るタイマー(図示しない)を起動する(ステップS306)。
次に、コネクション制御テーブル123の接続要求元のエントリに接続要求パケットが送信された認証用ポートを記憶する(ステップS307)。
サーバ計算機1は、タイマーの時間が認証処理の制限時間をオーバーしていないことをコネクション制御テーブル123と判定用テーブル113をあわせて参照することで確認する(ステップS308)。オーバーしていた場合には、接続要求パケットを破棄し、コネクション制御テーブル123からこのクライアント計算機2のエントリを削除する(ステップS303)。
一方、制限時間内であることが確認された場合には、コネクション制御テーブル123と判定用テーブル113とをあわせて参照し、全ての認証用ポートに接続要求パケットが送信されているか確認する(ステップS309)。まだ、接続要求パケットが送信されていない認証用ポートが存在する場合には、さらに接続要求パケットを待ち受ける(ステップS301)。
一方、接続要求パケットが全ての認証用ポートに送信された場合には、応答パケット生成部105は、クライアント計算機2からの複数の接続要求パケットのいずれか一つに対して接続要求確認パケットを送信する(S310)。そして、コネクション制御テーブル123に存在する接続要求元のエントリを削除する(ステップS311)。
この後は、接続要求元からの応答確認パケットを受信し、コネクションを確立した上でアプリケーション間での通信を行うことができる。
この例では、認証用ポートへの接続要求パケットの送信を時間内に行う必要があるため、不正クライアントが攻撃を仕掛ける機会が減少し、サーバのセキュリティがより一層向上する。また、サーバ計算機がクライアント計算機の情報を保持する時間も制限できるため、サーバ計算機の処理用リソースの無駄も防ぐことが出来る。
(第1の実施の形態の第4実施例)
次に、複数の認証用のポート番号へ接続要求パケットを送信する時間間隔を予め定めて認証する場合について説明する。
図15は、この際の、コネクション確立テーブル104、判定用テーブル114、コネクション制御テーブル124を示したものである。
コネクション確立テーブル104は、認証が必要なサーバ計算機1を識別するためのサーバ名と、それら各サーバ計算機1のそれぞれと認証するために必要な複数のポート番号の組と、これらポート番号への接続要求パケットを送信する時間間隔とを対応付けて記憶している。この接続要求パケットを送信する時間間隔とは、クライアント計算機2がサーバ計算機1への複数の接続要求パケットを送る、各接続要求パケットの送信し時間間隔を示す。なお、上記で説明したように、それぞれの認証用のポート番号、及び/または時間間隔は、クライアント計算機2と各サーバ計算機1との間でそれぞれ秘密に共有されたものである。
判定用テーブル114は、クライアント計算機2が、このサーバ計算機1へ接続するための認証用として必要な複数のポート番号の組と、これらポート番号への接続要求パケットを送信する時間間隔とを対応付けて記憶している。それぞれの認証用のポート番号及び/または時間間隔は、クライアント計算機2とサーバ計算機1との間でそれぞれ秘密に共有されたものである。なお、ここでは、全てのクライアント計算機2に対し共通に、認証用のポート番号の組、及び/または時間間隔を用いているが、クライアント計算機2ごとにそれぞれ異なるポート番号の組、および/または及び/または時間間隔を決めておき、それらを各クライアント計算機2を識別する識別情報と対応づけて格納するようにしても良い。
コネクション制御テーブル124は、現在、サーバ計算機1へコネクションを確立するためにアクセス処理を行っている各クライアント計算機2の進捗状況を示すものであり、クライアント計算機2から正当なポート番号および時間間隔でアクセスを受けるごとに、そのクライアント計算機2を識別するための識別情報に対応付けて、受けたアクセスのポート番号を記憶するものである。
図16はサーバ計算機1の処理手順を示すフローチャートである。
クライアント計算機2がサーバ計算機1にコネクションを確立しようとする場合、クライアント計算機2は、コネクション確立テーブル104を参照して複数の認証用ポートに接続要求パケットを送信するが、i番目の接続要求パケットを送信する際には、コネクション確立テーブルに記載されたi-1番目とi番目を送信する際の規定の時間間隔に従う。
サーバ計算機1は、タイマーを起動し(ステップS401)、クライアント計算機2からのi番目の接続要求パケットを受け付ける(ステップS402)と、タイマーをストップする(ステップS403)。そして判定用テーブル114を参照して接続要求パケットの宛先ポートが複数の認証用ポートのいずれかであるかどうか判定する(ステップS404)。もし、接続要求パケットの宛先が認証用ポートでない場合、接続要求パケットを破棄し(ステップS405)、タイマーを起動させ(ステップS401)、次の接続要求パケットを待ち受ける(ステップS402)。
i番目の接続要求パケットの終点ポート番号が認証用のポート番号であると判断された場合、コネクション制御テーブル124を参照し、接続要求元のエントリの有無を調べる(ステップS406)。コネクション制御テーブル124に接続要求元のエントリが存在しない場合は、エントリを追加し(ステップS407)、アクセスポートの記憶処理(ステップS409)に移る。
一方、コネクション制御テーブル124に接続要求元のエントリが存在する場合には、判定用テーブル114を参照して、タイマーで測定されたi-1番目とi番目の接続要求パケットの到着間隔が予め規定された時間間隔であるか判定し(S408)、規定どおりの場合はアクセスポートの記憶処理(ステップS409)に移る。規定に反する場合は接続要求パケットを破棄し(ステップS405)、タイマーを起動させ(ステップS401)、次の接続要求パケットを待ち受ける(ステップS402)。
アクセスポートの記憶処理後、全ての認証用ポートに接続要求パケットが送信されているか確認する(ステップS410)。まだ接続要求パケットが送信されていない認証用ポートが存在する場合には、図示しないタイマーを起動させ(ステップS402)、さらに接続要求パケットを待ち受ける(ステップS402)。
全ての認証用のポート番号に、接続要求パケットが送信されたと判断された場合には、接続要求元からの複数の接続要求パケットのいずれか一つに対して接続要求確認パケットを送信する(S411)。そして、コネクション制御テーブル124に存在する接続要求元のエントリを削除する(ステップS412)。
この後は、クライアント計算機2からの応答確認パケットを受信しコネクションを確立した上でアプリケーション間での通信を行うことができる。
また、アクセスの時間間隔のみを認証情報とすることも可能である。すなわち、認証にもちいるポートは特に規定されておらず、ポート番号に関わらず(規定の一つの認証用ポートでも良い)規定のアクセス時間間隔で接続要求パケットを送信する方法である。
本例では、不正アクセスを行うためには認証用ポートのポート番号だけではなく、そのアクセス時間間隔も推測する必要があるため、サーバ計算機1のセキュリティがより一層向上する。
以上様々な例を詳細に説明してきたが、この他に、例えば、複数の認証用のポート番号と、これら認証用のポート番号に対する接続要求パケットのパケット種別とで認証を行う方法も考えられる。
この場合、クライアント計算機2からサーバ計算機1の複数の認証用のポート番号へ送信されるパケットとして、通常の接続要求パケットであるTCPの接続要求パケットの他に、ICMPパケット、UDPパケットが利用可能である。そこで本例では、クライアント計算機2とサーバ計算機1との間では、認証用のポート番号だけではなく、それらポート番号へ送信されるパケット種別も予め定めておき、一方、コネクション確立テーブル105および判定用テーブル115にはポート番号とそのポート番号で受信するパケットの種別(UDP、TCP、ICMP)とを記憶(ただし、ICMPに関してはポート番号が存在しない。そのため、ICMPであるというパケット種別の判定のみを行うか、取り得る値の範囲は狭いがICMPパケットのtypeフィールドの値を代用する)しておく(図17参照)。そして、サーバ計算機1は、i番目の到着パケットのパケット種別も判定する。これによって認証を行うものである。
ただし、UDPやICMPはコネクションレス型のパケットを用いるから、認証が成功した際にサーバ計算機1から送出される接続要求確認パケットは、TCPの接続要求パケット(SYNパケット)に対して送出するTCPのSYN/ACKパケットである。
また、上記各例で示した認証情報は、接続要求前に既に固定的に定められたものであるが、これらを、例えば、ワンタイムパスワード技術で都度変更させるようにすることも可能である。こうすることにより、認証情報を再利用した不正クライアントのアクセスを防御できるため、サーバのセキュリティがより一層向上する。
また、サーバ計算機はクライアント計算機から受信した複数の接続要求パケットの一つに対して接続要求確認パケットを送信する構成を説明したが、サーバ計算機は受信した複数の接続要求パケットの複数個に対して接続要求確認パケットを送信する構成も考えられる。
(第2の実施の形態)
次に、第2の実施の形態について、詳細に説明する。
第2の実施の形態は、サーバ計算機1とクライアント計算機2との双方で共有した暗号鍵を利用した暗号処理を行うことでコネクションの確立をおこなう形態である。ここでは、暗号鍵として共通鍵を利用し、暗号処理としては共通鍵を利用したハッシュ関数によるメッセージ認証子生成処理を行う。暗号鍵と暗号処理は、他にも、共通鍵を利用した共通鍵暗号、公開鍵を利用した公開鍵暗号などであってもよく、基本的に、通信相手が暗号鍵を利用することでのみ情報から暗号化情報を導くことができ、その暗号鍵を保持していない主体には暗号化情報を生成・検証できないような暗号鍵および暗号処理であればよい。
また、暗号鍵として共通鍵を暗号処理として共通鍵暗号を利用した場合には、以下の実施の形態におけるメッセージ認証子作成部分で暗号化・復号化の処理を行えばよく、公開鍵暗号を利用した暗号化処理の場合は、クライアント計算機2は自身の秘密鍵を利用して電子署名を生成してメッセージ認証子の代わりとすればよく、サーバ計算機1は接続要求パケットを認証する際にメッセージ認証子の代わりに電子署名をクライアント計算機2の公開鍵を用いて認証するとすればよい。
図18は、クライアント計算機2のうち、第2の実施の形態に係る部分の機能ブロックを示したものである。
接続要求パケット生成部210は、サーバ計算機1への接続要求を行う旨の指示を受けた際に、接続要求パケットを生成するものである。接続要求パケット生成部210は、コネクション確立テーブル1000を参照し、サーバ計算機1との接続の際に使用する共通鍵を取得する。ここで、この共通鍵は、クライアント計算機2とサーバ計算機1との間で秘密に共有されている。この共通鍵の共有は、暗号プロトコルを用いて確保されたセキュアチャネル(このような既存技術としてはSSL(Secure Socket Layer)などがある)を利用してオンラインで行ったり、郵送などのオフラインで行ったりするなどして第三者に秘匿して共有される。なお、接続要求元は複数のサーバに応じて異なる共通鍵を保持していてもよい。
接続要求パケット生成部210は、ランダムに発生させたデータrndに対して共通鍵を用いて所定のハッシュ関数によってメッセージ認証子Aを作成し、データrndとメッセージ認証子Aとを認証情報とする。そして、この認証情報を接続要求パケットのシーケンス番号フィールドに格納可能なサイズに調整するために、一つの接続要求パケットで送信できるサイズに分割し(以降、分割された認証情報を分割認証情報と呼ぶ)、更に、分割認証情報を復元するための復元情報を付加する。
次に、分割認証情報及び復元情報を全て格納できる個数の接続要求パケットを作成し、分割認証情報及び復元情報をシーケンス番号フィールドに格納してサーバ計算機1へ送信する。この例では、分割認証情報及び復元情報をシーケンス番号フィールドに格納したが、シーケンス番号以外のヘッダのフィールドで通常の通信に問題を引き起こさないフィールドにデータを格納しても良い。また、送信される複数の接続要求パケットが同一の認証セッションに属することを識別するために、それらの接続要求パケットの共通な値をもつフィールド値(例えば、始点IPアドレス)を利用したり、接続要求パケットの特定のフィールド値(始点ポート番号、ウィンドウサイズ、など)に共通の値を設定したり、認証情報を格納するフィールドの一部を利用したりする。より大きなサイズの情報を利用することで、認証セッションを識別する際に精度を上げることができる。
送信部220は、IPパケットをネットワーク3へ送出するものであり、接続要求パケット生成部210によって生成された各接続要求パケットをネットワーク3へ順次送出する。
受信部230は、ネットワークからIPパケットを受信するものである。この受信したIPパケットは、接続要求確認パケット判定部240へ送られ、このIPパケットが、送信部220より送信した各接続要求パケットの何れかに対して応答された接続要求確認パケットであるか否かを判定する。これにより接続要求確認パケットであると判定された場合には、クライアント計算機2はサーバ計算機1とのコネクションを確立するための処理を行なう。
図19は、サーバ計算機1のうち、本実施の形態に係る部分の機能ブロックを示したものである。
受信部310は、ネットワーク3からの自サーバ計算機2宛てのIPパケットを受信するものである。判断部320は、受信部310で受信したIPパケットが接続要求パケットであるかの判断を行い、そうである場合のみパケットを受信管理部330へ送る。
受信管理部330は、受信した接続要求パケットをパケット記憶部370へ一時的に格納すると共に、次の(1)から(3)の情報をコネクション制御テーブル1200へ格納する。
(1)接続要求パケットを送信した接続要求元の認証セッションを識別可能な情報(以下、認証セッション識別情報とよぶ。具体例としては始点IPアドレス、始点ポート番号、ウィンドウサイズ、MACアドレスなどのフィールド値またはそれらの組など。この認証処理の間に接続要求元を識別するために利用可能な情報であれば良い。)
(2)接続要求パケットにそれぞれ格納された分割認証情報及び復元情報
(3)パケット記憶部におけるそれぞれの接続要求パケットの識別情報(以下、パケット識別情報)
コネクション制御テーブル1200に、このクライアント計算機1からの認証セッション識別情報をもつエントリが既にある場合には、取得した認証情報をそのエントリに追加すればよい。一方、該識別情報がない場合には、新たなエントリを作成すればよい。
監視部340は、コネクション制御テーブル1200に登録される各エントリ(認証セッション識別情報で区別される)が保持する分割認証情報及び復元情報が、認証情報を復元できる個数に達していないか監視する。復元可能な個数の接続要求パケットに達したものがある場合には、鍵テーブル1300から共通鍵を取得し、コネクション制御テーブル1200に記載された情報をもとにして認証処理を行う。具体的には、分割認証情報を復元情報に基づいて認証情報に復元し、クライアント計算機2がランダムに生成し接続要求パケットに格納して送信してきたデータrndと鍵テーブル1300から取得した共通鍵とからクライアント計算機2と同様な所定のハッシュ関数を用いた方法でメッセージ認証子Bを生成し、作成されたメッセージ認証子Bとクライアント計算機2から送信された接続要求パケットに含まれていたメッセージ認証子Aと等しいかを確認する。
等しいことが確認された場合、監視部340は、接続要求確認パケット生成部350へその旨通知する。等しくない場合には、その認証セッションに含まれる接続要求パケットのパケット識別子をコネクション制御テーブル1200を参照して決定し、それら接続要求パケットの全てをパケット記憶部370から削除し、さらに、コネクション制御テーブル1200の当該エントリも削除する。
接続要求確認パケット生成部350は、メッセージ認証子Aとメッセージ認証子Bとが等しいことが確認された旨を通知された際に、その認証セッションを構成している接続要求パケットから返答を行うパケットを少なくとも一つ以上決定し、コネクション制御テーブル1200から取得したパケット識別情報をもとにパケット記憶部370を参照して、当該接続要求パケットのデータを参照の上で応答のための接続要求確認パケットを生成する。また、接続要求確認パケット生成部350は、接続要求確認パケットの生成後、その認証セッションの接続要求パケットの全てをパケット記憶部370から削除し、さらに、コネクション制御テーブル1200の当該エントリも削除する。
送信部360は、接続要求確認パケット生成部350で生成された接続要求確認パケットをネットワーク3へ送出する。なお、この送出された接続要求確認パケットは、先に説明したクライアント計算機2の受信部230で受信される。
ところで、第2の実施の形態においても、クライアント計算機2とサーバ計算機1との間でやりとりされる認証情報によっては様々な認証方法を用いることが可能である。
以下で、2つの認証方法を例示し、その際の、クライアント計算機2とサーバ計算機1との動作について説明する。
(第2の実施の形態の第1実施例)
図20は、第2の実施の形態の第1実施例のコネクション確立テーブル1060、コネクション制御テーブル1260、鍵テーブル1360を示したものである。
コネクション確立テーブル1060には、認証が必要なサーバ計算機1を識別するためのサーバ名と、それら各サーバ計算機1のそれぞれのサービスと認証するために予め共有した共通鍵とを対応付けて記憶している。なお、上記で説明したように、それぞれの共通鍵は、クライアント計算機2と各サーバ計算機1との間でそれぞれ秘密に共有されたものである。
コネクション制御テーブル1260には、クライアント計算機2からの接続要求パケットの認証処理に必要な情報が格納されている。認証セッション識別子、パケット識別子、分割認証情報である。本実施例では、認証セッション識別子としてIPアドレスと始点ポート番号を用いており、また、分割認証情報はシーケンス番号フィールドの値である。
鍵テーブル1360には、クライアント計算機2からの接続要求パケットに含まれる認証情報を検証するための共通鍵が記載されている。なお、ここでは全てのクライアントに対して共通の共通鍵を利用するとしているが、接続要求元に応じた共通鍵を利用するとしてもよい。この場合、接続要求元が送信する認証情報の一部として鍵番号も格納しておき、サーバが利用する共通鍵を判断すればよい。
図21は、クライアント計算機2の処理手順を示すフローチャートであり、図22はサーバ計算機1の処理手順を示すフローチャートである。まず、クライアント計算機2の処理手順について説明する。
クライアント計算機2がサーバ計算機1とコネクションを確立しようとする場合、接続要求パケット生成部210は、コネクション確立テーブル1060を参照し、サーバ計算機1との接続の際に使用する共通鍵を取得する(ステップC501)。そして、サーバ計算機1宛ての通常のSYNパケットを生成する(ステップC502)。
次に、接続要求パケット生成部210は、生成されたSYNパケットのシーケンス番号フィールドの値SQに対して共通鍵を用いたハッシュ関数を適用してメッセージ認証子Aを生成する(ステップC503)。なお、サーバ計算機1が接続要求元に応じて共通鍵を使い分けている場合には、利用した共通鍵を識別するための鍵番号をコネクション確立テーブル1060に含めておき、この情報も併せてメッセージ認証子Aを生成すれば、鍵番号の正当性も保証できる。ここで一般に接続要求パケット生成部で生成される接続要求パケットのシーケンス番号の値は乱数であることから、その値を入力としてメッセージ認証子を作成している。
次に、SQを接続要求パケットのシーケンス番号フィールドに格納する(以後、この接続要求パケットをSYN0とよぶ)。次に、メッセージ認証子Aを分割する(C504)。この際、分割したメッセージ認証子Aを復元するための順序情報をつけたものがシーケンス番号フィールドに格納できるような大きさにメッセージ認証子Aを分割する。そして、分割したメッセージ認証子Aに順序情報を付加した複数のデータが格納できる個数分のサーバ計算機1をあて先とするSYNパケットを生成し、シーケンス番号フィールドにその情報を格納して、それらの接続要求パケットを全て送信する(ステップC505)。なお、サーバ計算機1が鍵番号により接続要求元を識別している場合には、鍵番号を認証情報の一部として送信してもよい。なお、順序情報は通信路中や送受信キューにおける接続要求パケットの順番の入れ替わりに対処するために必要であり、その決定方法は、認証情報全体の大きさやその中のメッセージ認証子Aの大きさによって変化する。分割方法・格納方法は、サーバ計算機1とクライアント計算機2との間で予め共有されていて、それによって受信した接続要求パケットのシーケンス番号フィールドに格納された分割認証情報から認証情報を復元できればどのような方法でもよい。
以上の処理を経て、クライアント計算機2は、サーバ計算機1からの接続要求確認パケットを待ち受ける(ステップC506)。クライアント計算機2は、サーバ計算機1からの応答があったかを判断し(ステップC507)、所定時間応答がない場合には認証に失敗したものとして処理を終了する。クライアント計算機2は、サーバ計算機1から複数の接続要求パケットのいずれかに対する接続要求確認パケットを受信した場合には、それに対して確認応答パケットを送信する(ステップC508)。これにより、クライアント計算機2とサーバ計算機1の間にはコネクションが確立される。
次に、サーバ計算機1の処理手順について説明する。
サーバ計算機1は、接続要求パケットを受信する(S501)。この接続要求パケットの受信は、受信部310で受信したネットワーク3からの自サーバ計算機2宛てのIPパケットを判断部320で接続要求パケットであることを確認することによって実現できる。
サーバ計算機1の受信管理部330は、受信した接続要求パケットをパケット記憶部370へ一時記憶すると共に、この接続要求パケットの識別情報(パケット識別情報)、接続要求パケットに格納された始点IPアドレスと始点ポート番号の組(認証セッション識別情報)、シーケンス番号フィールド値(分割認証情報)、の3つの情報を取得する(S502)。ここでは、コネクション制御テーブル1260において接続要求元を識別するための認証セッション識別情報をクライアント計算機2の始点IPアドレスと始点ポート番号の組としているが、MACアドレスやその他の識別子であってよい。つまり、この認証処理の間に接続要求元を識別するために利用可能な情報であれば良い。
次に、受信管理部330は、取得した認証セッション識別情報をもとにコネクション制御テーブル1260を参照し、該認証セッション識別情報をもつエントリの有無を確認する(S503)。すでにエントリがある場合には、パケット識別情報、認証情報をそのエントリ内に追加記録し(S504)、エントリが存在しない場合には、新たなエントリを設け、認証セッション識別情報、パケット識別情報、認証情報をコネクション制御テーブル1260に記録する(S505)。
監視部340は、コネクション制御テーブル1260を参照し、認証情報の復元に必要な個数の接続要求パケットを受信したか、否かを確認する(S506)。まだ必要な分だけの接続要求パケットを受信できていない場合には、S501へ戻り次の接続要求パケットを待ち受ける。一方、認証情報の復元に必要な個数(=全て)の接続要求パケットを受信したと判断した場合には、まず、受信した分割認証情報をコネクション制御テーブル1260から取得して復元する(S507)。次に、共通鍵を鍵テーブル1360から取得する(S508)。ここで、接続要求元に応じて利用される共通鍵が異なるような構成の場合には、再構成した認証情報に含まれる鍵番号を取得して、その鍵番号をもとに鍵テーブルから利用する鍵を取得すればよい。
次に、サーバ計算機1は、復元した認証情報から、SYN0に含まれるシーケンス番号値SQを取り出し、共通鍵を利用したメッセージ認証子Bを生成し、その値と認証情報に含まれるメッセージ認証子Aとを比較することで認証を行う(S509)。ここで、認証情報として鍵番号も含まれており、接続要求元でのメッセージ認証子作成時に引数となる情報として含まれていた場合には、鍵番号も取得し、メッセージ認証子作成用のハッシュ関数の引数に追加する。認証が失敗した場合、その認証セッションに属する全ての接続要求パケットをパケット記憶部370から削除し、また、コネクション制御テーブル1260からそのエントリを削除する(S510)。そして、S501へ戻り、次の接続要求パケットを受ける。認証が成功した場合、接続要求確認パケット生成部350にその旨を通知する。
接続要求確認パケット生成部350は、認証作業が成功した旨の通知を受けると、その認証セッションを構成している接続要求パケットのうち、返答を行うパケットを少なくとも一つ以上決定する(S511)。
コネクション制御テーブル1260から取得したパケット識別情報をもとにパケット記憶部370を参照し、応答のための接続要求確認パケット(応答パケット)を生成する(S512)。その後、接続要求確認パケット生成部350は、その認証セッションの接続要求パケットの全てをパケット記憶部370から削除し、さらに、その認証セッションのエントリをコネクション制御テーブル1260から削除する(S513)。なお、複数の接続要求パケットの何れに対し、接続要求確認パケットを返信するかについては、次のような方法が考えられる。
1)最後に受信した接続要求パケットに対して返信する。
2)予め定めた到着番号の接続要求パケットに対し返信する。
3)認証情報のうち特定の情報を格納している接続要求パケットに対し返信する。
以上のように何れかの方法を予め定めておけば、返答の必要がない接続要求パケットをパケット記憶部から削除する、または、保持しない、ことでパケット記憶部370の容量を小さくできる。また、このようにすることで、クライアント計算機2は、送信したうちの特定の接続要求パケットに対する接続要求確認パケットを待ち受ければよくなる。それによりクライアント計算機2の処理用リソースが減少するという効果が期待できる。
そして、送信部360を利用して接続要求確認パケット生成部350で生成された接続要求確認パケットをネットワーク3へ送出する(S514)。なお、この送出された接続要求確認パケットは、先に説明したクライアント計算機2の受信部230で受信される。
この後、サーバ計算機1は、接続要求元からの応答確認パケットを受信し、コネクションを確立することによって、クライアント計算機2とサーバ計算機1との各アプリケーション間で、通信を行うことができる。
この実施例によれば、共通鍵を知らない不正クライアントが、認証に成功したクライアント計算機のIPアドレスを偽造して接続するという攻撃を防ぐことができる。このことにより従来よりも安全性の向上した認証を行うことが可能となる。
(第2の実施の形態の第2実施例)
接続要求元が送信する認証情報として時刻情報も含めておき、その時刻情報もハッシュ関数の引数としてメッセージ認証子を作成する場合について説明する。
図23は、この際のコネクション制御テーブル1270、及び、監視部340に新たに接続されたリプレイ防止テーブル1470を示したものである。
コネクション制御テーブル1270には、コネクション制御テーブル1260の内容に加えて、受信管理部330に接続され時刻情報を提示する(図示しない)時刻提供部から取得された認証セッション開始時刻が記載されている。
リプレイ防止テーブル1470には、インデックスと接続要求パケットに含まれる時刻情報TCとが対応して記録されている。ここで、サーバ計算機1の処理用リソースを少なくする場合は、時刻情報は適切な精度の情報のみ記録すればよい。なお、ここでインデックスは、メッセージ認証子Aで参照されるため、最大値はメッセージ認証子Aを格納するシーケンス番号の最大値である。また、サーバ計算機1が利用するメモリを少なくするためには、ハッシュテーブルの利用といった一般的なメモリ節約方法を利用すればよい。
本実施例でクライアント計算機2がサーバ計算機1とコネクションを確立しようとする場合、実施例1での接続要求パケット生成処理において次のような処理も行う。この場合、接続要求パケット生成部210に新しく接続され時刻情報を提示する(図示しない)時刻提供部から取得した時刻情報TCも認証情報とする。クライアント計算機2は、メッセージ認証子Aの生成作業において、TCもハッシュ関数への引数に追加するとともに、時刻情報TCも認証情報として送信する。なお、サーバ計算機1の時刻提供部とクライアント計算機の時刻提供部は、あらかじめ定められた許容時間以上のずれが生じないように時刻同期サーバなどの手段をもちいて同期されているとする。
本実施例では、サーバ計算機1は接続要求パケットの検査処理において実施例1での処理に加えて次のような処理も行う。まず、時刻提供部から取得した現在時刻をコネクション制御テーブル1270に記載された認証セッション開始時刻と比較して、それが時刻のずれの許容範囲を超えるものでないことを確認する。そして、リプレイ防止テーブル1470をメッセージ認証子Aの値をキーとして確認し、その時刻情報の値とTCが同一でないことを確認する。この処理によりリプレイでないことが確認され、接続要求パケットに格納された時刻情報TCによりリプレイ防止テーブルの時刻情報の値を上書きする。これらの確認が成功した場合、接続要求確認パケット生成部350にその旨を通知する。なお、ここでメッセージ認証子Aは比較的長い乱数周期をもち、許容時間内において同一値が算出されることはないと仮定している。
この実施例によれば、クライアント計算機2からサーバ計算機1へ送信された接続要求パケットを盗聴し、その情報を再度送信することによって接続を試みる攻撃を防御することができ安全性がさらに向上する。
以上、詳細に説明してきた本実施の形態によれば、この実施例によれば、共通鍵を知らない不正クライアントが、認証に成功したクライアント計算機のIPアドレスを偽造して接続するという攻撃を防ぐことができる。このことにより従来よりも安全性の向上した認証を行うことが可能となる。
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
本発明の各実施の形態が適用される通信システムを示す図。 IPパケットを示す図。 TCPセグメントを示す図。 UDPセグメントを示す図。 第1の実施の形態のクライアント計算機2のうち、本実施の形態に係る部分の機能ブロックを示した図。 第1の実施の形態のサーバ計算機1のうち、本実施の形態に係る部分の機能ブロックを示した図。 第1の実施の形態の第1実施例のコネクション確立テーブル101、判定用テーブル111、コネクション制御テーブル121を示した図。 第1の実施の形態の第1実施例のクライアント計算機2の処理手順を示すフローチャート。 第1の実施の形態の第1実施例のサーバ計算機3の処理手順を示すフローチャート。 第1の実施の形態の第2実施例のコネクション確立テーブル102、判定用テーブル112、コネクション制御テーブル122、順序設定テーブル132を示した図。 第1の実施の形態の第2実施例のクライアント計算機2の処理手順を示すフローチャート。 第1の実施の形態の第2実施例のサーバ計算機3の処理手順を示すフローチャート。 第1の実施の形態の第3実施例のコネクション確立テーブル103、判定用テーブル113、コネクション制御テーブル123を示した図。 第1の実施の形態の第3実施例のサーバ計算機3の処理手順を示すフローチャート。 第1の実施の形態の第4実施例のコネクション確立テーブル104、判定用テーブル114、コネクション制御テーブル124を示した図。 第1の実施の形態の第4実施例のサーバ計算機1の処理手順を示すフローチャート。 第1の実施の形態のその他の1例のコネクション確立テーブル105、判定用テーブル115、コネクション制御テーブル125を示した図。 第2の実施の形態のクライアント計算機2のうち、本実施の形態に係る部分の機能ブロックを示した図。 第2の実施の形態のサーバ計算機1のうち、本実施の形態に係る部分の機能ブロックを示した図。 第2の実施の形態の第1実施例のコネクション確立テーブル1000、鍵テーブル1300、コネクション制御テーブル1200を示した図。 第2の実施の形態の第1実施例のクライアント計算機2の処理手順を示すフローチャート。 第2の実施の形態の第1実施例のサーバ計算機3の処理手順を示すフローチャート。 第2の実施の形態の第2実施例のコネクション確立テーブル1270、リプレイ防止テーブル1470を示した図。
符号の説明
1…サーバ計算機
2…クライアント計算機
3…ネットワーク
11、23、230、310…受信部
12、320…判断部
13、330…受信管理部
14、340…監視部
15、350…接続要求確認パケット生成部
16、22、220、360…送信部
17、370…パケット記憶部
100〜105、1000、1060…コネクション確立テーブル
110〜115…判定用テーブル
120〜125、1200、1260…コネクション制御テーブル
132…順序設定テーブル
1300、1360…鍵テーブル
1470…リプレイ防止テーブル

Claims (7)

  1. ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で、通信を開始するようにしたサーバ計算機の認証方法であって、
    前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納しておき、
    前記ネットワークから複数の接続要求パケットを受信し、
    該受信した前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証し、
    該認証の結果、正しく認証された場合に、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを生成し、
    該生成した接続要求確認パケットをネットワークへ送出するようにするものであって、
    前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、
    前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、
    前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、
    前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、
    前記認証は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって行われることを特徴とする認証方法。
  2. 前記第1暗号鍵は、共通鍵暗号方式における共通鍵であり、
    前記第2暗号鍵は、前記共通鍵と同じ共通鍵であることを特徴とする請求項1に記載の認証方法。
  3. 前記第1暗号鍵は、公開鍵暗号方式における秘密鍵であり、
    前記第2暗号鍵は、前記公開鍵暗号方式において、前記秘密鍵に対応する公開鍵であることを特徴とする請求項1に記載の認証方法。
  4. 前記認証情報は、前記第1暗号鍵を利用することでのみ導かれる情報であることを特徴とする請求項1乃至請求項3のいずれか1項に記載の認証方法。
  5. ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で、通信を開始するようにしたサーバ計算機であって、
    前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納する格納手段と、
    前記ネットワークから複数の接続要求パケットを受信する受信手段と、
    前記受信手段で受信した前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証する認証手段と、
    前記認証手段での認証の結果、正しく認証された場合に、前記複数の接続要求パケット
    の少なくとも何れか1つに対する応答として接続要求確認パケットを生成する生成手段と、
    前記生成手段で生成された接続要求確認パケットをネットワークへ送出する送出手段と
    を備え
    前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、
    前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、
    前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、
    前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、
    前記認証手段は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって認証することを特徴とするサーバ計算機。
  6. ネットワークを介して接続されるクライアント計算機が正当であることを確認した上で
    通信を開始する、サーバ計算機で実行されるプログラムであって、
    前記クライアント計算機によって秘密裏に保持される第1暗号鍵と対応する第2暗号鍵を、予め格納させる第1のコードと、
    前記ネットワークから複数の接続要求パケットを受信させる第2のコードと、
    該受信された前記複数の接続要求パケットから取得される情報であって、前記第1暗号鍵による暗号処理によって得られる認証情報と、前記第2暗号鍵とから、前記複数の接続要求パケットを送信した送信元を認証させる第3のコードと、
    該認証の結果、正しく認証された場合に、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを生成させる第4のコードと、
    前記生成手段で生成された接続要求確認パケットをネットワークへ送出させる第5のコードとを備え
    前記複数の接続要求パケットのそれぞれには、前記認証情報が分割された分割認証情報が付加されており、
    前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットには、複数の前記分割認証情報を前記認証情報へ復元するための復元情報が付加されており、
    前記認証情報は、前記複数の接続要求パケットのそれぞれに付加された前記分割認証情報を、前記復元情報に従い復元することによって取得され、
    前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、
    前記認証は、前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しいか否かによって行われることを特徴とする、サーバ計算機で実行されるプログラム。
  7. ネットワークを介して接続されるサーバ計算機と通信するための接続要求を行うクライ
    アント装置であって、
    前記サーバ計算機によって保持される第2暗号鍵と対応する第1暗号鍵を、秘密裏に格納する格納手段と、
    前記第1暗号鍵による暗号処理によって生成される認証情報を分割し、前記分割した分割認証情報を複数の接続要求パケットに付加する手段と、
    前記複数の接続要求パケットを前記サーバ計算機へ送信する送信手段と、
    前記サーバ計算機から、前記複数の接続要求パケットの少なくとも何れか1つに対する応答として接続要求確認パケットを受信する受信手段とを備え、
    前記付加手段は、前記複数の接続要求パケットのうち少なくとも1つの前記接続要求パケットに、複数の前記分割認証情報を前記認証情報へ復元するための復元情報を付加し、
    前記認証情報は、ある第1情報と、当該第1情報に対して前記第1暗号鍵を利用した暗号処理を施して得られる第1暗号化情報とを含み、
    前記第1暗号化情報に対して前記第2暗号鍵を利用した暗号処理を施して得られる結果と、前記認証情報に含まれる前記第1情報とが、等しい場合に、前記受信手段は、前記接続要求確認パケットを受信し、
    前記接続要求確認パケットに応じて、前記サーバ計算機との通信を開始することを特徴とするクライアント計算機。
JP2004223137A 2003-09-25 2004-07-30 認証方法、サーバ計算機、クライアント計算機、および、プログラム Expired - Fee Related JP4183664B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004223137A JP4183664B2 (ja) 2003-09-25 2004-07-30 認証方法、サーバ計算機、クライアント計算機、および、プログラム
US10/948,699 US7366170B2 (en) 2003-09-25 2004-09-24 Communication connection method, authentication method, server computer, client computer and program
US12/003,924 US7940761B2 (en) 2003-09-25 2008-01-03 Communication connection method, authentication method, server computer, client computer and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003332822 2003-09-25
JP2004223137A JP4183664B2 (ja) 2003-09-25 2004-07-30 認証方法、サーバ計算機、クライアント計算機、および、プログラム

Publications (2)

Publication Number Publication Date
JP2005122695A JP2005122695A (ja) 2005-05-12
JP4183664B2 true JP4183664B2 (ja) 2008-11-19

Family

ID=34621989

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004223137A Expired - Fee Related JP4183664B2 (ja) 2003-09-25 2004-07-30 認証方法、サーバ計算機、クライアント計算機、および、プログラム

Country Status (1)

Country Link
JP (1) JP4183664B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100890996B1 (ko) 2006-12-26 2009-03-31 주식회사 타오네트웍스 분산 흐름 제어 시스템
JP5011574B2 (ja) * 2008-07-03 2012-08-29 Necインフロンティア株式会社 情報処理装置、使用制限方法およびプログラム
JP2010057034A (ja) * 2008-08-29 2010-03-11 Nec Infrontia Corp ルータにおけるアクセス制御方法、ルータ、およびアクセス制御プログラム
JP5381504B2 (ja) * 2009-08-26 2014-01-08 富士通株式会社 情報装置及び認証プログラム
JP5048105B2 (ja) * 2010-06-29 2012-10-17 レノボ・シンガポール・プライベート・リミテッド コンピュータへのアクセス方法およびコンピュータ
WO2016154946A1 (en) * 2015-03-31 2016-10-06 SZ DJI Technology Co., Ltd. Systems and methods for uav mutual authentication
EP3152089A4 (en) 2015-03-31 2017-08-02 SZ DJI Technology Co., Ltd. Systems and methods for geo-fencing device communications
CN107409051B (zh) 2015-03-31 2021-02-26 深圳市大疆创新科技有限公司 用于生成飞行管制的认证系统和方法
CN110178339B (zh) * 2017-01-11 2022-04-01 甲贺电子株式会社 数据通信方法
WO2018131176A1 (ja) * 2017-01-11 2018-07-19 甲賀電子株式会社 データ通信方法
JP6472550B1 (ja) 2018-01-23 2019-02-20 甲賀電子株式会社 Ip網における通信回線の相互認証システム

Also Published As

Publication number Publication date
JP2005122695A (ja) 2005-05-12

Similar Documents

Publication Publication Date Title
US7940761B2 (en) Communication connection method, authentication method, server computer, client computer and program
Rescorla et al. Guidelines for writing RFC text on security considerations
US7823194B2 (en) System and methods for identification and tracking of user and/or source initiating communication in a computer network
US9438592B1 (en) System and method for providing unified transport and security protocols
KR101055861B1 (ko) 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램
US8984268B2 (en) Encrypted record transmission
EP3711274B1 (en) Message queuing telemetry transport (mqtt) data transmission method, apparatus, and system
US20060161667A1 (en) Server apparatus, communication control method and program
JP2005027312A (ja) 透過仮想プライベートネットワークを用いたネットワーク構成の複雑さの低減
US20090327730A1 (en) Apparatus and method for encrypted communication processing
US20180115520A1 (en) Dark virtual private networks and secure services
JP2006254444A (ja) サーバと通信相手が互換性のある安全な電子メールを有することを立証するためのシステムおよび方法
CA2506418C (en) Systems and apparatuses using identification data in network communication
US20080267395A1 (en) Apparatus and method for encrypted communication processing
JP4183664B2 (ja) 認証方法、サーバ計算機、クライアント計算機、および、プログラム
Reddy et al. Traversal using relays around NAT (TURN): Relay extensions to session traversal utilities for NAT (STUN)
Vigna A topological characterization of TCP/IP security
EP1836559B1 (en) Apparatus and method for traversing gateway device using a plurality of batons
Biagioni Preventing udp flooding amplification attacks with weak authentication
US10079857B2 (en) Method of slowing down a communication in a network
JP3841417B2 (ja) 通信接続方法、サーバ計算機、および、プログラム
EP3907967A1 (en) Method for preventing sip device from being attacked, calling device, and called device
Rescorla et al. RFC3552: Guidelines for Writing RFC Text on Security Considerations
Feng et al. A Reliable Lightweight Communication Method via Chain Verification
Chen et al. Oscur0: One-Shot Circumvention without Registration

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20050418

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20050606

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050831

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080509

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080620

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080711

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080808

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080902

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110912

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110912

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110912

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120912

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120912

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130912

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees