(57)【要約】【課題】ハードウエアの変更や、ヘッダの各フィールドに対する専用の処理も不要としながら、通信データ単位毎の認証を行う際の認証強度の強化を図る。【解決手段】ＩＰパケットを送信する際に、通常の手順でチェックサムを計算して、その値をHeader Checksumのフィールドに記憶させ、そうして得られたヘッダ情報に対して予め設定した送受信側で同一となるハッシュ鍵を利用してハッシュ計算を行い、計算して得られたハッシュ値のうちの２バイトを取り出して、認証情報として、Header Checksumのフィールドに適用して送信し、受信側では、送信時と同一の手順を同じハッシュ鍵を用いて実施し、受信したＩＰパケットのHeader Checksumのフィールドの値が、受信側で計算して得られたハッシュ値のうちの送信時に取り出した位置と同じ位置の２バイトと一致するかどうかを確認する。【選択図】図３
2010283612.tif 000002
【特許請求の範囲】
【請求項１】
１以上の端末とそれらの端末を接続するネットワークとからなるネットワークシステムで用いるネットワーク通信方法であって、
送信側端末が、
通信データに対して通信データ単位毎に付加されるヘッダを対象として、当該通信データ単位毎に、通常の手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対してあらかじめ設定した送受信側端末で同一となるハッシュ鍵を用いてハッシュ計算を行う送信側第１ステップと、
前記通信データ単位毎に、前記ハッシュ計算により得られたハッシュ値のうちの一部を、認証情報として、前記ヘッダ内に存在する１つまたは複数のフィールドに記憶させる送信側第２ステップと、
前記認証情報が記憶された前記通信データを通信データ単位毎に送信する送信側第３ステップと
を行い、
受信側端末が、
前記送信側端末から送信されてきた前記通信データを通信データ単位毎に受信する受信側第１ステップと、
受信した前記通信データに対し、前記通信データ単位毎に、前記送信側第２ステップで記憶させた前記ヘッダ内の１つまたは複数のフィールド内の前記認証情報を保存する受信側第２ステップと、
受信した前記通信データに対し、前記通信データ単位毎に、前記ヘッダ部分を対象として、前記送信側第１ステップで行った前記通常の手順と同じ手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対して前記送信側第１ステップで行った前記ハッシュ計算と同一の演算処理を行う受信側第３ステップと、
当該演算処理により得られたハッシュ値のうちの一部を、前記受信側第２ステップで保存した前記認証情報と比較する受信側第４ステップと、
前記比較により、それらが一致した通信データ単位のデータについては受け入れ、それらが一致しなかった場合には当該通信データ単位のデータを廃棄する受信側第５ステップと
を行う
ことを特徴とするネットワーク通信方法。
【請求項２】
前記通信のプロトコルがインターネットプロトコル（ＩＰ）であり、前記通信データ単位はパケットであって、前記送信側第２ステップにおいて前記認証情報を記憶させる前記フィールドはチェックサムであることを特徴とする請求項１に記載のネットワーク通信方法。
【請求項３】
前記通信のプロトコルがユーザデータグラムプロトコル（ＵＤＰ）であり、前記通信データ単位はパケットであって、前記送信側第２ステップにおいて前記認証情報を記憶させる前記フィールドはＵＤＰチェックサムであることを特徴とする請求項１に記載のネットワーク通信方法。
【請求項４】
前記通信のプロトコルがトランスポートコントロールプロトコル（ＴＣＰ）であり、前記通信データ単位はパケットであって、前記送信側第２ステップにおいて前記認証情報を記憶させる前記フィールドはＴＣＰチェックサムであることを特徴とする請求項１に記載のネットワーク通信方法。
【請求項５】
１以上の端末とそれらの端末を接続するネットワークとからなるネットワークシステムで用いるネットワーク通信方法であって、
前記通信のプロトコルがインターネットプロトコル（ＩＰ）であり、通信データ単位はパケットであって、
送信側端末が、
通信データに対してパケット毎に付加されるＩＰヘッダを対象として、送信する前記パケットがフラグメントされていないで、かつ、途中でフラグメントされない場合に、パケットＩＤ、チェックサム、および、ＴＴＬの各フィールドの値を０として、あらかじめ設定した送受信側端末で同一となるハッシュ鍵を用いて、前記ＩＰヘッダのハッシュ計算を行う送信側第１ステップと、
前記ハッシュ計算により得られたハッシュ値の一部を取り出して、前記認証情報として、パケットＩＤフィールドに記憶させるとともに、ＴＴＬ値、および、通常の手順で計算したチェックサム計算結果を、ＴＴＬフィールドおよびチェックサムフィールドにそれぞれ記憶させる送信側第２ステップと、
前記認証情報が記憶された前記通信データを前記パケット毎に送信する送信側第３ステップと
を行い、
受信側端末が、
前記送信側端末から送信されてきた前記通信データを前記パケット毎に受信し、前記チェックサムフィールド内のチェックサムの値によって、前記ＩＰヘッダのエラーチェックを行う受信側第１ステップと、
受信した前記パケットに対し、前記送信側第２ステップで記憶させた前記パケットＩＤフィールド内の前記認証情報を保存する受信側第２ステップと、
受信したパケットのパケットＩＤ、チェックサム、および、ＴＴＬの各フィールドの値を０として、送信側と同一のハッシュ鍵を用いて、ＩＰヘッダのハッシュ計算を行う受信側第３ステップと、
前記ハッシュ計算により得られたハッシュ値のうち一部が、前記受信側第２ステップで保存した前記パケットＩＤフィールド内の前記認証情報の値に一致するかどうかを比較する受信側第４ステップと、
前記比較により、それらが一致した場合には、当該パケットのデータについては受け入れ、それらが一致しなかった場合には当該パケットのデータを廃棄する受信側第５ステップと
を行う
ことを特徴とするネットワーク通信方法。
【請求項６】
１以上の端末とそれらの端末を接続するネットワークとからなるネットワークシステムで用いるネットワーク通信方法であって、
前記通信のプロトコルがメディアアクセスコントロール（ＭＡＣ）であり、通信データ単位はフレームであり、
送信側端末が、
通信データに対してフレーム毎に付加されるトレイラを対象として、フレーム毎に、通常の手順でＣＲＣを計算して、前記トレイラのＣＲＣフィールドに適用し、そうして得られたフレームに対して、あらかじめ設定した送受信装置で同一となるハッシュ鍵を利用してハッシュ計算を行う送信側第１ステップと、
前記ハッシュ計算により得られたハッシュ値の一部を取り出して、前記認証情報として、前記トレイラのＣＲＣフィールドに記憶させる送信側第２ステップと、
前記認証情報が記憶された前記通信データをフレーム毎に送信する送信側第３ステップと
を行い、
受信側端末が、
前記送信側端末から送信されてきた前記通信データをフレーム毎に受信する受信側第１ステップと、
受信した前記通信データに対し、前記フレーム毎に、前記送信側第２ステップで記憶させた前記トレイラ内のＣＲＣフィールド内の前記認証情報を保存する受信側第２ステップと、
受信したフレームに対して、送信側と同一のハッシュ鍵を用いてハッシュ計算を行う受信側第３ステップと、
受信したフレームの前記ＣＲＣフィールドの値が、受信側で計算して得られたハッシュ値の一部の値と一致するかどうかを確認する前記受信側第４ステップと
を行う
ことを特徴とするネットワーク通信方法。
【請求項７】
前記ハッシュ鍵は、前記送信側端末を示す送信元情報毎に管理されることを特徴とする請求項１ないし６のいずれか１項に記載のネットワーク通信方法。
【請求項８】
前記送受信側端末間で同一のハッシュ鍵を持つための手段として、ＤＨ法に基づく鍵交換手順を利用することを特徴とする請求項１ないし７のいずれか１項に記載のネットワーク通信方法。
【請求項９】
前記ハッシュ計算を行う際、前記通信データ単位に含まれるデータフィールドの一部あるいは全体もハッシュ計算の対象として含めることを特徴とする請求項１ないし８のいずれか１項に記載のネットワーク通信方法。
【請求項１０】
前記ハッシュ値の一部は、乱数を用いて、当該ハッシュ値のうちのいずれのバイトを前記認証情報として用いるかを選択することを特徴とする請求項１ないし９のいずれか１項に記載のネットワーク通信方法。
【請求項１１】
請求項１ないし１０のいずれか１項に記載のネットワーク通信方法を用いて通信を行うことを特徴とする通信端末装置。
【請求項１２】
請求項１ないし１０のいずれか１項に記載のネットワーク通信方法を用いて通信を行うことを特徴とする通信中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク通信方法に関し、特に、ＬＡＮ等のユーザネットワークとそれに接続された広域ネットワークとからなるネットワーク構成において通信を行うためのネットワーク通信方法、並びに、それを用いた通信端末装置、および、通信中継装置に関する。
【背景技術】
【０００２】
現在、通信システムにおいて認証システムは広く取り入れられ、必須の機能となっている。通信のデータ単位であるパケット毎、あるいは、フレーム毎の認証も行われていて、各通信レイヤで適用されている。最も代表的なものがＡＨ（Authentication Header：RFC2402）やＥＳＰ（Encapsulating Security Payload：RFC 2406）であり、これらのフィールドを適用して、その認証情報によりハッシュ値を計算したり、暗号化を行って、ユーザを確認して認証を行うものである。これらはＩＰ（ＩＰ：インターネットプロトコル）パケットのペイロード、または、ＵＤＰ／ＴＣＰ（ＵＤＰ：ユーザデータグラムプロトコル、ＴＣＰ：トランスポートコントロールプロトコル）のペイロードに適用されることが多い。
【０００３】
しかしながら、いずれにしてもヘッダフィールドを追加することになり、ソフトウエアとして、例えばＯＳ（Operating System）に実装する場合などにおいて、レイヤ２のＭＴＵの制限から、図らずして、ＩＰフラグメントを発生させる原因となるなど、データを生成する上位のアプリケーションがこれらのヘッダを適用することを意識したつくりとなっていなければならないことが多い。
【０００４】
こうした問題を解決するために、現在広く利用されているＩＰプロトコルやＭＡＣ（メディアアクセスコントロール）プロトコルのフォーマットを変更することなく、パケット単位の認証を行う方式が提案されている。これらは、特にレイヤ３で認証が終端されるような場合に有効である。各家庭のホームネットワークなど、閉じた環境において適用して侵入者が接続した端末のネットワークへの参加を拒絶する効果がある。
【０００５】
このための方式として、例えば、特許文献１に記載のような提案が成されている。
【０００６】
特許文献１に記載の方法は、無線ＬＡＮシステムにおいて有効な手段で、ＭＡＣフレームのＣＲＣ計算において、ＭＡＣフレームのデータペイロードに認証のためのセッションキーを付加したものをＣＲＣ計算の対象とすることで、そのセッションキーがないとＣＲＣエラーなしにパケットを受信することができない、すなわち、通信できないことになり、パケット単位の認証を実現するものである。
【０００７】
また、この他に、非特許文献１に記載の方法がある。
【０００８】
特許文献２に記載の方法は、初期認証においては通常のＳＳＬなどを利用するが、その後は、ＩＰパケットに一定のフィールドの変換を適用して、それを受信側でも無事に受信して認識できなければ廃棄することによって、パケット単位の簡易的な認証を行うものである。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００２−１２４９５２号公報
【非特許文献】
【００１０】
【非特許文献１】安井浩之、他著、「ＩＰパケット認証ゲートウエイシステムＡＩＰＳ」、情報処理学会論文誌、Vol. 49, No. 7, pp. 2614-2622、２００８年７月
【発明の概要】
【発明が解決しようとする課題】
【００１１】
特許文献１においては、以下の問題点があった。
【００１２】
（１）ＭＡＣレイヤへの適用であり、近年の一般的な実装ではハードウエアへの変更を余儀なくされること
（２）結果的にＣＲＣが認証のためのハッシュ値の役割を果たしており、一般的なハッシュ値の長さが１６バイトであれば、その１６バイトに当該ＣＲＣ計算を施した結果の逆算は困難ではなく、容易に行えてしまうこと
【００１３】
特に（２）の問題は簡易認証であり、通信セッション単位にハッシュ鍵が変化するとはいうものの、認証手段として十分なものではないという問題がある。
【００１４】
次に、特許文献２についてであるが、特許文献２の方法は、認証の秘匿性強度など、認証の観点においては特に問題はなく、また、パケット長を変化させないという点においても課題を満たしており、ＯＳに対するソフトウエア上の変更で適用が可能である。しかしながら、フォーマットは変わっていなくてもその中身を大きく変えており、以下の問題点がある。
【００１５】
（１）ＩＰヘッダのプロトコルとしてＩＡＮＡ（Internet Assigned Numbers Authority）で本来規定されるべき専用のプロトコル番号を割り当てている。
（２）ＩＰパケットのクラスＣ、並びに、それ以上のマスク長のネットワークを前提としている。ただし多くの場合、これで事足りることも確かである。
【００１６】
このように、特許文献２では、中身を変更しているが、結局、認証情報の長さは１６ビットとなっていて、パケット単位で見た認証強度は特に強いものではない。また、アプリケーションやＯＳの作りによっては、ここまで送信元ＩＰアドレスを変更してしまうことが基本的なＩＰ通信そのものに悪影響を及ぼす可能性を否定できない。
【００１７】
また、特許文献２の方法においては、ネットワーク障害が発生した場合などで、チェックサムエラーが表示されたりすると、ツールによる解析は困難になってしまうという問題点もあった。
【００１８】
本発明はかかる問題点を解決するためになされたものであり、ハードウエアの変更や、ヘッダの各フィールドに対する専用の処理も不要としながら、通信データ単位毎の認証を行う際の認証強度の強化を図ることが可能なネットワーク通信方法、並びに、それを用いた通信端末装置、および、通信中継装置を得ることを目的とする。
【課題を解決するための手段】
【００１９】
本発明は、１以上の端末とそれらの端末を接続するネットワークとからなるネットワークシステムで用いるネットワーク通信方法であって、送信側端末が、通信データに対して通信データ単位毎に付加されるヘッダを対象として、当該通信データ単位毎に、通常の手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対してあらかじめ設定した送受信側端末で同一となるハッシュ鍵を用いてハッシュ計算を行う送信側第１ステップと、前記通信データ単位毎に、前記ハッシュ計算により得られたハッシュ値のうちの一部を、認証情報として、前記ヘッダ内に存在する１つまたは複数のフィールドに記憶させる送信側第２ステップと、前記認証情報が記憶された前記通信データを通信データ単位毎に送信する送信側第３ステップとを行い、受信側端末が、前記送信側端末から送信されてきた前記通信データを通信データ単位毎に受信する受信側第１ステップと、受信した前記通信データに対し、前記通信データ単位毎に、前記送信側第２ステップで記憶させた前記ヘッダ内の１つまたは複数のフィールド内の前記認証情報を保存する受信側第２ステップと、受信した前記通信データに対し、前記通信データ単位毎に、前記ヘッダ部分を対象として、前記送信側第１ステップで行った前記通常の手順と同じ手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対して前記送信側第１ステップで行った前記ハッシュ計算と同一の演算処理を行う受信側第３ステップと、当該演算処理により得られたハッシュ値のうちの一部を、前記受信側第２ステップで保存した前記認証情報と比較する受信側第４ステップと、前記比較により、それらが一致した通信データ単位のデータについては受け入れ、それらが一致しなかった場合には当該通信データ単位のデータを廃棄する受信側第５ステップとを行うことを特徴とするネットワーク通信方法である。
【発明の効果】
【００２０】
本発明は、１以上の端末とそれらの端末を接続するネットワークとからなるネットワークシステムで用いるネットワーク通信方法であって、送信側端末が、通信データに対して通信データ単位毎に付加されるヘッダを対象として、当該通信データ単位毎に、通常の手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対してあらかじめ設定した送受信側端末で同一となるハッシュ鍵を用いてハッシュ計算を行う送信側第１ステップと、前記通信データ単位毎に、前記ハッシュ計算により得られたハッシュ値のうちの一部を、認証情報として、前記ヘッダ内に存在する１つまたは複数のフィールドに記憶させる送信側第２ステップと、前記認証情報が記憶された前記通信データを通信データ単位毎に送信する送信側第３ステップとを行い、受信側端末が、前記送信側端末から送信されてきた前記通信データを通信データ単位毎に受信する受信側第１ステップと、受信した前記通信データに対し、前記通信データ単位毎に、前記送信側第２ステップで記憶させた前記ヘッダ内の１つまたは複数のフィールド内の前記認証情報を保存する受信側第２ステップと、受信した前記通信データに対し、前記通信データ単位毎に、前記ヘッダ部分を対象として、前記送信側第１ステップで行った前記通常の手順と同じ手順でチェックサムを計算してフィールドに適用し、そうして得られたヘッダ情報に対して前記送信側第１ステップで行った前記ハッシュ計算と同一の演算処理を行う受信側第３ステップと、当該演算処理により得られたハッシュ値のうちの一部を、前記受信側第２ステップで保存した前記認証情報と比較する受信側第４ステップと、前記比較により、それらが一致した通信データ単位のデータについては受け入れ、それらが一致しなかった場合には当該通信データ単位のデータを廃棄する受信側第５ステップとを行うことを特徴とするネットワーク通信方法であるので、ハードウエアの変更や、ヘッダの各フィールドに対する専用の処理も不要としながら、通信データ単位毎の認証を行う際の認証強度の強化を図ることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明のネットワーク通信方法を適用する一般的なネットワーク構成の一例を示した構成図である。
【図２】本発明のネットワーク通信方法を適用する通信装置の構成の一例を示した構成図である。
【図３】一般的なＩＰヘッダの構成を示した説明図である。
【図４】一般的なＴＣＰヘッダの構成を示した説明図である。
【図５】一般的なＵＤＰヘッダの構成を示した説明図である。
【発明を実施するための形態】
【００２２】
実施の形態１．
図１は、本発明のネットワーク通信方法を適用する一般的なネットワークシステムの一例を示した構成図である。図１において、ユーザネットワーク１０１，１０２は、ホームネットワークや企業ネットワークの一部または全部などであり、例えばＬＡＮ等で構成される。ユーザネットワーク１０１には、１以上のユーザ端末９１１，９１２が含まれており、同様に、ユーザネットワーク１０２にも、１以上のユーザ端末９２１，９２２が含まれている。また、これらのユーザネットワーク１０１，１０２には、それらを結ぶ広域ネットワーク２０１が、ゲートウエイ装置１１，１２を介して接続されている。また、広域ネットワーク２０１には中継装置４０１が設けられており、当該中継装置４０１を介して、他の広域ネットワーク２０２に設けられた中継装置４０２に接続される。
【００２３】
ユーザ端末装置９１１，９１２、中継装置４０１，４０２、および、ゲートウエイ装置１１，１２は、本発明のネットワーク通信方法を実現するために必要なハードウエアおよび／またはソフトウエアを搭載した、通信端末装置および通信中継装置である。
【００２４】
本発明のネットワーク通信方法による認証方式は、特に、図１に示すような一般的なネットワーク構成におけるユーザネットワーク１０１，１０２において適用されることを想定している。本発明による認証方式は、今後、無線ＬＡＮが広く普及されつつあるホームネットワーク等のユーザネットワークにおいては重要な機能となる。無線ＬＡＮが元々持つ認証機能に加え、本発明による認証方式をさらに適用することで、ユーザネットワークへの侵入をより強固に防ぐことが可能となる。
【００２５】
また、上記以外に、広域ネットワーク同士（図１中の２０１，２０２）を結ぶ境界部分においても、本発明による認証方式が適用可能である。図１には示していないが、通常ここにはＬＡＮに相当するネットワークが存在する場合が多い。従って、広域ネットワーク同士の境界のような箇所には、侵入者が端末を接続するなどの物理的なアクセスが可能な場合が考えられる。そこで、本方式による簡易認証を適用しておくことは極めて有効である。
【００２６】
次に、本発明に係るユーザ端末装置９１１，９１２、中継装置４０１，４０２、および、ゲートウエイ装置１１，１２の最も基本的な例を以下に説明する。対象となる通信プロトコルは、最も広く適用されているＩＰ（インターネットプロトコル）とする。図２に、本発明を適用する一般的な通信装置またはＯＳの構成の一例を示す。図２に示すように、一般的な通信装置またはＯＳには、下位処理部７０１とＩＰ処理部（ＩＰレイヤ）７０２とが設けられている。また、必要に応じて、ＵＤＰ／ＴＣＰ処理部７０３やアプリケーション７０４が備えられている。なお、下位処理部７０１は、ＰＨＹ処理部（ＰＨＹレイヤ）７０１ａおよびＭＡＣ処理部（ＭＡＣレイヤ）７０１ｂから構成されている。このような図２に示すプロトコルスタック構成によって、通常のＩＰ通信が行われる。本発明のネットワーク通信方法による認証方式の適用先は、図２において符号８０１で示す部分（以下、部分８０１とする）である。すなわち、本発明のネットワーク通信方法による認証方式は、ＩＰ処理部（ＩＰレイヤ）７０２とＭＡＣ処理部（ＭＡＣレイヤ）７０１ｂとの間にインタフェースとして適用され、そこを通過するＩＰパケットに対して一定の処理を施すことによって実現する。従って、一般的なＯＳであれば、この部分はドライバ適用のためのインタフェースとして公開されているので、ここにソフトウエアを別途製作して適用することは容易である。
【００２７】
図３は、一般的なＩＰパケットのヘッダ部分（以下、ＩＰヘッダとする）のフォーマットを示したものである。図３に示すように、通常のＩＰヘッダは、ヘッダフィールドとデータフィールド（Payload（ペイロード））とから構成されている。ヘッダフィールドには、以下の各フィールドが含まれる。
【００２８】
Ｖｅｒ（バージョン）：ＩＰプロトコルのバージョン番号を示す。
Ｌｅｎ（インターネット・ヘッダ長）：ＩＰヘッダフィールドの大きさを３２ビット（４バイト）単位で示す。
ＴＯＳ（サービスタイプ）：送信したＩＰパケットが要求するサービス品質を示す。優先度の指定、遅延の少ない経路の要求、信頼性の高い経路の要求などがある。
Packet Length（トータル長）：ヘッダフィールドとデータフィールドを合わせたＩＰパケットの全体長をバイト単位で表す。
Packet ID（識別子）：上位層から各ＩＰパケットを見分けるための識別番号を示す。
flg（フラグ）：ＩＰパケットのフラグメント（分割）に関する情報を示す。すなわち、フラグメント可能か否か、および、フラグメントされている場合は、それが途中のフラグメントか、最後のフラグメントかを示す。
Fragment Offset（フラグメントオフセット）：各フラグメントのオリジナル・データにおける位置をバイト単位で示す。
ＴＴＬ（生存時間）：通過可能なルータの残り数を示す。ＩＰパケットがルータを通過するたびに１ずつ減らされていき、この値が“０”になった時点でルータはこのＩＰパケットを中継せずに廃棄する。
Protocol（プロトコル・タイプ）：データフィールド（Payload（ペイロード）に含むＩＰの上位プロトコルを識別するためのプロトコル種別コード（番号）を示す。
Header Checksum（ヘッダチェックサム）：ヘッダフィールドにおけるエラー検出のためのチェックサムを表す。
Source Address（送信元アドレス）：送信元のＩＰアドレスを示す。
Destination Address（宛先アドレス）：宛先のＩＰアドレスを示す。
【００２９】
次に、本発明のネットワーク通信方法の処理内容を示す。まず、送信する場合について説明する。送信する場合には、ＩＰヘッダに関する全ての処理が行われた後のＩＰパケットが、図２に示す部分８０１を通過しようとする。このとき、部分８０１において、以下の処理を行う。
【００３０】
（ａ）ＩＰ処理部（ＩＰレイヤ）７０２から渡されたＩＰパケットに関し、通常の手順でチェックサムを計算して、Header Checksum（ヘッダチェックサム）のフィールドに適用し、そうして得られたＩＰヘッダ部分を対象として、予め設定されたハッシュ鍵を用いて、ハッシュ値を計算する。なお、ハッシュ計算においては、ＩＰヘッダの予め決められた対象範囲（すなわち、ＩＰヘッダの一部、あるいは、全体、さらには、データの一部または全体）に対してハッシュ計算を行う。
（ｂ）こうして計算して得られたハッシュ値のうち、最後の２バイトをチェックサムとしてHeader Checksum（ヘッダチェックサム）のフィールドに上書きして、ＭＡＣ処理部（ＭＡＣレイヤ）７０１ｂに渡す。
【００３１】
次に、受信した場合について説明する。受信したＩＰパケットは、図２に示す部分８０１を通過しようとする。このとき、部分８０１において、以下の処理を行う。
【００３２】
（ａ）受信したＩＰパケットのHeader Checksum（ヘッダチェックサム）のフィールドに記憶されたチェックサムの値を保存し、Header Checksum（ヘッダチェックサム）のフィールドに“０”を適用して、送信側で行ったのと同じ方法でチェックサムを計算し、当該値を、Header Checksum（ヘッダチェックサム）のフィールドに適用する。
（ｂ）続いて、送信時に用いたハッシュ鍵と同一のハッシュ鍵を用いて、ＩＰヘッダ部分の予め決められた対象範囲（すなわち、送信側と同じ、ＩＰヘッダの一部、あるいは、全体、さらには、データの一部または全体）を対象にハッシュ値を計算する。
（ｃ）計算して得られたハッシュ値のうち、最後の２バイトを、受信したときに保存したHeader Checksum（ヘッダチェックサム）のフィールドのチェックサムの値と比較し、一致していれば、認証された正しいパケットしてＩＰ処理部（ＩＰレイヤ）７０２に渡す。一方、一致しなければ、そのＩＰパケットを廃棄する。
【００３３】
以上のように、本発明のネットワーク通信方法においては、ＩＰパケットを送信する際に、通常の手順でチェックサムを計算して、その値をHeader Checksum（ヘッダチェックサム）のフィールドに適用し、そうして得られたヘッダ情報に対して（ヘッダの一部、あるいは、ヘッダの全体、さらには、データの一部、または、データの全体に対して）あらかじめ設定した送受信装置で同一となるハッシュ鍵を利用してハッシュ計算を行い、計算して得られたハッシュ値のうち２バイト（チェックサムフィールド長に一致）を取り出して、Header Checksum（ヘッダチェックサム）のフィールドに適用して送信し、受信側では、送信側で行ったのと同じ方法でチェックサムを計算し（このとき、受信パケットのHeader Checksum（ヘッダチェックサム）のフィールド値は別途保存し、チェックサム計算時は０を適用）、計算して得られたチェックサムをチェックサムフィールドに適用し、そうして得られたヘッダ情報の予め決められた対象範囲（ヘッダの一部、あるいは、ヘッダの全体、さらには、データの一部、または、データの全体）に対して、送信時と同一の手順を同じハッシュ鍵を用いてハッシュ計算を行い、受信パケットのHeader Checksum（ヘッダチェックサム）のフィールドの値が、受信側で計算して得られたハッシュ値における、送信時に取り出した位置と同じ位置にある２バイトと一致するかどうかを確認することによって、各プロトコルのヘッダフォーマットを変更することなく、パケット毎の簡易認証を実現する。
【００３４】
なお、上記の説明においては、フィールドに認証機能を持たせる対象がＩＰ（インターネットプロトコル）であり、対象のフィールドがHeader Checksum（ヘッダチェックサム）である例について説明したが、その場合に限らず、対象のフィールドは、Packet ID（パケットＩＤ）であってもよい。その場合について以下に説明する。
【００３５】
対象のフィールドをPacket ID（パケットＩＤ）とするときは、ＩＰヘッダにおいて、送信するＩＰパケットがフラグメントされておらず、かつ、途中でフラグメントされない場合に、Packet ID（パケットＩＤ）、チェックサム、並びに、ＴＴＬの各フィールドを“０”として、あらかじめ送受信装置で設定された同一のハッシュ鍵に従ってＩＰヘッダのハッシュ値を計算して、そのうちの２バイトをPacket ID（パケットＩＤ）フィールドに適用し、その後、ＴＴＬ値と、通常の手順で計算したチェックサム計算結果を、それぞれ、ＴＴＬフィールドおよびチェックサムフィールドに適用して送信する。受信側では、まず、チェックサムによってＩＰヘッダのエラーチェックを行い、受信したPacket ID（パケットＩＤ）フィールドの値を保存し、続いて、Packet ID（パケットＩＤ）フィールド、ＴＴＬフィールド、および、チェックサムフィールドに“０”を適用して、送信側と同一のハッシュ鍵を用いてＩＰヘッダのハッシュ値を計算し、そのうちの送信時に適用したのと同じ位置にある２バイトの値が、受信したＩＰパケットのPacket ID（パケットＩＤ）のフィールドに適用された２バイトの値に一致するかどうかを確認することによって、通常のＩＰ中継装置を跨いだ、ＩＰ中継装置またはＩＰ端末間のパケット毎の簡易認証を行う。
【００３６】
このように、本実施の形態においては、ＩＰパケット毎に付加されるＩＰヘッダの一部として存在している１つ（または複数）のフィールドを、そのフィールドの機能を失わせることなく処理した認証情報に置き換えて送信し、受信側で当該フィールドの目的の処理を果たすと同時にそれを認証情報としても取り扱うことで、ＩＰパケット毎に認証を行うことが可能である。
【００３７】
本発明によれば、わずかこれだけのことで、パケット単位の簡易的な認証を実現することが可能である。もちろん、ホームゲートウエイなどの簡単な通信装置にも適用することで、ゲートウエイ装置の先に接続される広域ネットワークに出ていく際のパケット認証を行うことが可能になり、侵入者が勝手に広域ネットワークへアクセスして広域接続線の帯域を食いつぶすなどの妨害を防ぐことができ、セキュリティが強化されることになる。端末側への適用は、前記のようにＯＳに当該ソフトウエアを付加するだけであるので、ホームゲートウエイ装置以上に容易である。
【００３８】
なお、上記の説明においては、フィールドに認証機能を持たせる対象としてＩＰに適用する場合について示したが、その場合に限らず、例えば、ＵＤＰや、ＴＣＰ、ならびに、ＭＡＣ処理部（ＭＡＣレイヤ）７０１ｂのＣＲＣに適用しても同様のことが可能である。ただし、それぞれ以下の点がＩＰに適用した場合と異なる。
【００３９】
（１）ＵＤＰ／ＴＣＰ
ソフトウエア処理であることはＩＰの場合と同一で、チェックサムに同様に適用することが可能であるが、中継装置においては必ずしも見ない場合がある。ただし、一般のホームゲートウエイ装置では、広域ネットワークに出ていく際に、ＩＰアドレスとＴＣＰ／ＵＤＰのポート番号を変換することが広く行われているので（ＮＡＰＴ機能：Network Address Port Translation)、そこで認証処理をする場合において、多くの場合適用可能である。なお、図２の部分８０１の適用位置は、ＩＰ処理部（ＩＰレイヤ）７０２とＵＤＰ／ＴＣＰ処理部（ＵＤＰ／ＴＣＰレイヤ）７０３との間となる。
【００４０】
図４に、一般的なＴＣＰパケットのヘッダ部分（以下、ＴＣＰヘッダとする）のフォーマットを示す。図４に示すように、通常のＴＣＰヘッダは、ヘッダフィールドとデータフィールド（Payload（ペイロード））とから構成されている。ヘッダフィールドには、以下の各フィールドが含まれる。
【００４１】
Source Port（送信ポート番号）：ＴＣＰを使用するアプリケーションに対してそのシステム内で一意に設定されるサービスの番号で、これによって、送信システム内でのアプリケーションが特定できる。
Destination Port（受信ポート番号）：ＴＣＰを使用するアプリケーションに対してそのシステム内で一意に設定されるサービスの番号で、これによって、受信システム内でのアプリケーションが特定できる。
Sequence Number（順序（シーケンス）番号）：送信データストリームの中の、このデータ・セグメントの「バイト位置」を示す。
Acknowledge Number（確認応答番号）：受信した最上位のバイトの「次の」バイト位置を示す。
DtOf（データ・オフセット）：セグメント内でのデータの開始位置を示す。
Rsvd（予約）：０を指定。未使用である。
CtrlBits（コントロール・ビット）：セグメントのタイプ（緊急、確認、転送強制、リセット、同期、転送終了）がセットされる。
Window（ウインドウ）：セグメント転送中の送受信バッファ・サイズを指定するために使用する。
Checksum（チェックサム）：チェックサムは、１６ビットの“１”の補数和の“１”の補数によるセグメントのチェック・コードである。
Urgent Pointer（緊急ポインタ）：緊急データのストリーム上の終了バイト位置を示す。
Options（オプション）：オプションには、最大セグメント長などのオプションを指定する。
Padding（パディング）：ヘッダ長を４の倍数に補正する。
【００４２】
また、図５に、一般的なＵＤＰパケットのヘッダ部分（以下、ＵＤＰヘッダとする）のフォーマットを示す。図５に示すように、通常のＵＤＰヘッダは、ヘッダフィールドとデータフィールド（Payload（ペイロード））とから構成されている。ヘッダフィールドには、以下の各フィールドが含まれる。
【００４３】
Source Port（送信元ポート番号）：ＵＤＰを使用するアプリケーションに対してそのシステム内で一意に設定されるサービスの番号で、これによって、送信システム内でのアプリケーションが特定できる。
Destination Port（宛先ポート番号）ＵＤＰを使用するアプリケーションに対してそのシステム内で一意に設定されるサービスの番号で、これによって、受信システム内でのアプリケーションが特定できる。
Payload length（データ長）：データフィールド（ペイロード）の全体長をバイト単位で表す。
Checksum（チェックサム）：チェックサムは、１６ビットの“１”の補数和の“１”の補数によるセグメントのチェック・コードである。
【００４４】
（２）ＭＡＣ処理部（ＭＡＣレイヤ）のＣＲＣ
ハードウエアへの適用が必要になることが一般的であるので、本発明の特徴の一部を実現することができない。ただし、適用自体は可能である。また、図２の部分８０１の適用位置は、ＭＡＣ処理部（ＭＡＣレイヤ）７０１ｂとＰＨＹ処理部（ＰＨＹレイヤ）７０１ａとの間となる。なお、通信プロトコルがＩＰ、ＵＤＰ、および、ＴＣＰの場合は、通信データ単位がパケットであるが、通信プロトコルがＭＡＣの場合は、通信データ単位はフレームとなる。また、通信プロトコルがＩＰ、ＵＤＰ、および、ＴＣＰの場合は、認証情報を適用する対象をヘッダの一部のフィールドとしたが、通信プロトコルがＭＡＣの場合は、認証情報を適用する対象を、トレイラの一部（たとえば、ＣＲＣフィールド）とする。なお、トレイラのＣＲＣフィールドに対して実施する以外は、基本的な処理は前記と同様であるが、念のため、以下に説明する。
【００４５】
ＭＡＣフレームを送信する際、通常の手順でＣＲＣを計算してＣＲＣフィールドに適用し、そうして得られたフレームに対してあらかじめ設定した送受信装置で同一となるハッシュ鍵を利用してハッシュ計算を行い、計算して得られたハッシュ値のうちの４バイトを取り出してＣＲＣフィールドに適用して送信し、受信側では送信時と同一の手順を同じハッシュ鍵を用いて実施し、受信したＣＲＣフィールドの値（４バイト）が、受信側で計算して得られたハッシュ値における（送信時のものと同じ位置にある）４バイトと一致するかどうかを確認する。これにより、各プロトコルのヘッダフォーマットを変更することなく、パケット毎の簡易認証が実現できる。
【００４６】
なお、ハッシュを計算する際、ヘッダだけでもよいが、ヘッダだけなくデータフィールド（ペイロード）も含めることは重要である。すなわち、ヘッダだけでなく、データフィールド（ペイロード）の一部あるいは全部まで拡張させて、ハッシュ値を計算する。ＵＤＰの場合はセッションが変わらなければヘッダに変化が生じない。このように、データフィールド（ペイロード）のデータをハッシュ計算に含めることで、ハッシュ計算対象がパケット毎に変化し、認証強度をより高めることができる。
【００４７】
また、ハッシュ計算結果は、適用フィールド長である２バイトないし４バイトを越える１６バイトであるのが一般的であるので、その１６バイトのうちの一部を選択して適用することで、覗き見によるハッシュ鍵の解析時間を大きく延長させることができる。送受信時、特に受信時にソフトウエア負荷がさほど大きくないやり方としては以下がある。以下の方法により、簡易認証の強度が強化される。
【００４８】
（１）送信側においては、送信時に、例えば乱数等を元に、ハッシュ計算結果として得られた１６バイトのうちのどこ（任意の連続する２バイトまたは４バイト）を選択するかを決定し、それを選択してハッシュ値として適用する。
（２）受信側においては、パケットの受信時に、同様にして得られたハッシュ計算結果から連続する２バイトないし４バイトを順次取り出して、送信側で適用された値と順次比較していき、一致するものがあるかどうかを探索し、見つかれば、その受信パケットを受け入れる。一方、一致するものが見つからなかった場合は、そのパケットは廃棄される。
【００４９】
この他、ハッシュ鍵を使い分けることによって強度を高めることも可能である。以下のレベルがある。
【００５０】
（１）１つのユーザネットワーク（ＬＡＮなどのホームネットワーク等）で１つのパスワード（ハッシュ鍵はこのパスワードを元に生成）とする。
（２）端末毎に１つのパスワードとする。
（３）通信セッション毎に１つのパスワードとする。
【００５１】
ホームネットワークなどのユーザネットワークでは、（１）の場合であれば、手作業による設定でもさほど負担にはならない。しかしながら、（２）および（３）については、鍵交換プロトコルによってソフトウエアが自動的にハッシュ鍵を生成するのが望ましい。ただし、前記のように、ホームネットワークなどのユーザネットワークでは、全てが個人の管理であるので、（１）および（２）であれば十分に対応可能である。この場合、各通信レイヤにおける送信元アドレス毎にハッシュ鍵を管理することになる。また、ＭＡＣであれば送信元ＭＡＣアドレス、ＩＰであれば送信元ＩＰアドレスである。ＵＤＰ／ＴＣＰの場合は、送信元ＩＰアドレスとすることが妥当であり、（２）においてポート番号による管理は実質不可能である。このように、ハッシュ鍵は、送信元情報（ＭＡＣの場合はＭＡＣアドレス、ＩＰの場合はＩＰアドレス、ＵＤＰ／ＴＣＰの場合はＩＰアドレスあるいはポート番号）毎に管理して適用する。
【００５２】
なお、鍵交換プロトコルを適用する場合は、例えば、ＤＨ（Deffie Hellman）法などの既存の方法を利用して行えばよく、本発明のために特別な手順を必要としないので、ここでは特に詳しく説明しない。
【００５３】
以上のように、本発明においては、従来の通信方法の問題点を解決するために、以下の方式を行っている。
（１）ヘッダの各フィールドは、そのまま通常の処理を行う。
（２）認証のための計算をその上で行って、フィールドそのものを認証情報で置き換える。
（３）認証強度を増すため、認証のためのハッシュ値の計算結果のうち、任意の連続する“フィールド長”バイトを取り出して適用する。
【００５４】
上記の（１）によって、各通信プロトコル処理部に対しての変更は不要となり、新たに認証のための処理を付加するだけである。また、レイヤを特に限定しないため、ＯＳに処理プログラムを付加するだけで実装が可能である。
また、上記の（２）によって、パケットの見た目のフォーマットおよび内容は、ほとんど変更がない。もちろんネットワーク障害が発生した場合など、チェックサムエラーが表示されることになるが、無視して解析させることは可能である。この点に関しては、特に前記非特許文献２ではツールによる解析は困難となる。
また、上記の（３）によって、これも簡単な実装で認証強度を高めることが可能である。ワンタイムパスワードを適用する効果と、その実装の複雑さを比較した場合、（３）による認証強度の効果と実装の容易さが勝るとも劣らない。
【符号の説明】
【００５５】
１１，１２  ゲートウエイ装置、１０１，１０２  ユーザネットワーク、２０１，２０２  広域ネットワーク、４０１，４０２  中継装置、７０１  下位処理部、７０１ａ  ＰＨＹ処理部（ＰＨＹレイヤ）、７０１ｂ  ＭＡＣ処理部（ＭＡＣレイヤ）、７０２  ＩＰ処理部（ＩＰレイヤ）、７０３  ＵＤＰ／ＴＣＰ処理部（ＵＤＰ／ＴＣＰレイヤ）、７０４  アプリケーション、９１１，９１２，９２１，９２２  ユーザ端末。
【図１】
2010283612.tif 000003
【図２】
2010283612.tif 000004
【図３】
2010283612.tif 000005
【図４】
2010283612.tif 000006
【図５】
2010283612.tif 000007