JP2004295891A - パケットペイロードを認証する方法 - Google Patents

Abstract

【課題】 ＤｏＳ攻撃のような第三者の不正なデータ注入によるセッション破壊等に対して、ＴＬＳやＴＣＰ等の現存するプロトコルを最大限利用した効果的なネットワークセキュリティを得る。
【解決手段】 パケット受信を実行できる入力部３２２、少なくとも１つの送信、セッション及びプレゼンテーションヘッダ部からなるパケット、並びに、少なくとも１つの送信、セッション、及びプレゼンテーションヘッダ部において、パケットを認証するために少なくともいくつかのパケットのコンテンツに基づいて第１のメッセージ認証コードを算定し、第１のメッセージ認証コードを第２のメッセージ認証コードを比較することを実行できる伝送エージェント３１２を含むパケット認証のためのアーキテクチャが提供される。
【選択図】 図３

Description

本発明は、認証、特にパケットペイロードの認証に関する。

効果的なネットワークセキュリティの必要性は、コンピュータハッキング、ウイルス、その他のネットワーク犯罪の増加と巧妙化のため、年毎にその重要度を増している。電子商取引は、Denial-of-Service即ちＤｏＳ攻撃として知られる新しいタイプのネットワーク犯罪をもたらしている。ＤｏＳ攻撃において、２つの端末間において連続した伝送を行う標準のTransmission Control Protocol 即ちＴＣＰを使用する場合、悪質な第三者がパケットストリームに不正なパケットを注入し、あるいは「混ぜ込む」ことができる。ＴＣＰ上に備えられたプロトコルによる探知を免れるため、正しいアドレスのペア及びシーケンス番号を含むが（そのため、パケットは有効に見える）不純なデータを含む偽のパケットが作られる。後に正しいパケットが到着した時、そのパケットは再送信された複製として廃棄される。その不正なパケットが認証に失敗するので、備えられたプロトコルは、エラーメッセージを送信元ノードに送ることによってセッションを終わらせてしまう。備えられたプロトコルは廃棄された(正しい)データを選択的に再送信することを要求することができない。結果として、ＤｏＳ攻撃は、時間のかかる暗号折衝セッションを経るＴＬＳ接続の再確立を余儀なくし、これは莫大な処理リソースを必要とする。ＤｏＳ攻撃は、処理リソースを無駄に消費するだけでなく、電子商取引事業に多額の費用を歳入損失として費やさせてしまう。

ＤｏＳ攻撃に対抗するために用いられる一つの方法は、ＩＰセキュリティやＩＰＳｅｃプロトコルを各ＩＰパケット認証のためのトランスポートモードに使用することである。ＩＰＳｅｃは、実際のユーザーのデータだけでなく、テクニカルセッション攻撃プロファイルにおいて顧客サイトの機能を低下させるために使用されるプロトコルスタック情報の項目の多くも暗号化できる。ＩＰｓｅｃは、Open System Interconnect即ちＯＳＩアーキテクチャのレイヤー３(Internet Protocol即ちＩＰ)とレイヤー４(ＴＣＰ又はＵＤＰ)の間に「シム」として働き、Authentication Header(ＡＨ)、Encapsulating Security Payload(ＥＳＰ)及びInternet Key Exchange(ＩＫＥ)を正しく行う一組のプロトコルを含む。ＩＰＳｅｃは、ＡＨを介した認証、ＥＳＰを介したデータ暗号化、及び、ＩＫＥを用いた送信者と受信者ノード間の自動化された鍵交換を行う。

図２Ａは、認証ヘッダ２０４を持つＩＰｖ４パケット２００を示す。認証ヘッダ２０４は、(長さ１バイトで、ＡＨの後に来る上位のプロトコルを特定する)次ヘッダ領域２０８を含み、(長さ１バイトで、認証データ領域２１６の長さを指定する)ペイロード長領域２１２、(今後の使用のため予約された長さ２バイトの領域である)予約領域２２０、(長さ４バイトで、パケットに使用されているセキュリティプロトコルを特定する)Security Parameters Index即ちＳＰＩ領域２２４、(長さ４バイトで、同じ宛先とＳＰＩデータを担う既に受信されたＩＰ・ＡＨパケット数を識別するカウンタとして動作する)シーケンス番号領域２２８、及び、(長さが可変で、(例えばＤＥＳ、ＭＤ５又はSecure Hash Algorithm(ＳＨＡ-１)を使用して作られたパケットのデジタル署名である)Integrity Check Value 即ちＩＣＶである)認証データ領域２１６を含む。

図２Ｂは、Encapsulating Security Payload即ちＥＳＰ２５４を持つＩＰｖ４パケット２５０を示す。カプセル化セキュリティペイロードは、上述のＳＰＩ及びシーケンス番号領域２２４及び２２８を含み、ＴＣＰ又はUser Datagram Protocol(ＵＤＰ)ヘッダ２３０、(ユーザーのオリジナルデータを暗号化された形式で含む)ペイロードデータ領域２５８、(暗号化アルゴリズムの必要なパディング要求又はバイト境界配列を行う)パディング領域２６２、(パディング領域で使用される必要パディング要求を指定する)パッド長領域２６６、(ペイロードデータ領域に含まれるデータの種類を特定することによってペイロードデータを参照する)次ヘッダ領域２７０、及び、(ＥＳＰヘッダ全体に適用されるデジタル著名である)認証データ２７４を含む。

しかしながら、ＩＰＳｅｃは、ファイヤーウォール、特にネットワークアドレスの伝送又はネットワークアドレス及びポートの伝送を行うプロキシサーバファイヤーウォールを通過することができない。この問題は図１を参照して説明される。図１に関して、ファイヤーウォール（又はプロキシサーバ）１００は、ネットワーク１０４と各種ファイヤーウォールで保護されたネットワークノード１０８a-nとの間に配置される。各ノード１０８a-nは、対応するＩＰアドレスとポート番号を持つ。ノード１０８a-nがパケットをネットワークに送信したとき、ファイヤーウォールはＩＰアドレスだけ、又は、ＩＰアドレス及びポート番号を変更する。新しいＩＰアドレスは、通常、プロキシサーバのＩＰアドレスである。ＩＰＳｅｃはレイヤー３とレイヤー４で動作し、ＩＰＳｅｃはポート特定のための機能を持たないため、プロキシサーバによるポート変更の試みは失敗し、パケットは伝送されない。ＥＳＰヘッダ２５４は通常、ＩＰアドレスが変更されるのを許可するが、ポート番号の変更は許可しない。一方、ＡＨ２０４は通常、ＩＰアドレスもポート番号も変更されるのを許可しない。

これらの、また、他の要望は、本発明の様々な具体例及び形態によって取り組まれる。本発明は、ＯＳＩ転送及びＴＣＰ/ＩＰホスト−ホストトランスポート層のようなアプリケーション層において、パケットを認証する方法へ導かれるものである。
本発明の一具体例において、
（ａ）パケットを受信するステップであって、パケットはヘッダとペイロードからなり、ヘッダは送信ヘッダ部からなるステップ、
（ｂ）パケットの少なくともいくつかのコンテンツに基づいた最初のメッセージの認証コードを算定するステップ、及び、
（ｃ）パケットを認証するための送信ヘッダ部における最初のメッセージの認証コードと第２のメッセージの認証コードとを比較するステップ、からなるパケット認証方法が提供される。
送信ヘッダ部は、ＯＳＩトランスポート層及びＴＣＰ/ＩＰホスト-ホストトランスポート層のような適合可能なソフトウェアモデルによって定義される。
メッセージ認証コードは、(安全な)ハッシュアルゴリズムのような適合可能なアルゴリズムを用いて算定される。第１及び第２の認証コードは、通常、予め決められたビット数に間引かれる。
第１及び第２の認証コードは、ヘッダの全て又は選択された部分、及び/又は、ペイロードの全て又は選択された部分が基礎となり得る。第１及び第２のメッセージ認証コードは、通常、少なくとも送信ヘッダ部を基礎として決定される。
１つの形態において、第１及び第２の認証コードは、送信元及び/又は宛先ポート領域がヘッダ内で対応する送信元又は宛先ポート領域と異なる値に設定された擬似ヘッダに基づいて算定される。言い換えれば、送信元及び/又は宛先領域は、ヘッダ内で対応する送信元及び宛先領域からは独立した値を持つことになる。例えば、送信元及び/又は宛先領域はゼロに設定される。ファイヤーウォールによって操作されないパケット内領域は、異なる値に正常に設定されないか、あるいは、擬似ヘッダにおいて無視される。

前述の具体例とともに使用される他の具体例において、本発明は、
（ａ）第１のモードにおいて、第２のメッセージ認証コードを含むヘッダが有効な認証部分を有しない場合はパケットを廃棄するステップ、及び、
（ｂ）第２の異なるモードにおいて、ヘッダが認証部分を含む場合はパケットを廃棄するステップ、からなる受信パケットの認証方法へ向けられる。前述の具体例の算定及び比較するステップは第１のモードでのみ起こる。動作モードは、通常、アプリケーション層若しくはセッション層といった上位層又はトランスポート層自体によって決められる。

前述の具体例とともに使用される他の具体例において、本発明は、
（ａ）送信ヘッダ部を含むヘッダとペイロードからなるパケットをアセンブルするステップであって、
（ｂ）第１のモードにおいて、送信ヘッダ部に有効な認証オプション領域を含み、
（ｃ）第２の異なるモードにおいて、送信ヘッダ部に有効な認証オプション領域を含まず、
（ｄ）その後、パケットを送信するステップ、からなる送信パケットの認証方法へ向けられる。

様々な具体例が従来技術と比較して多くの利点を持ち得る。例えば、ヘッダの送信部に認証オプションを含むことは、伝送中のデータの承認されない操作を阻止し、ＤｏＳ攻撃の場合のような第三者の認証されないデータの注入によるセッション破壊に対する強化された耐性を与えるのに効果的である。パケットが生成されると、メッセージ認証コードが算定され、ヘッダに挿入される。認許が失敗した場合、パケットは明らかに改ざんされていて（又はストリームに虚偽的に注入されていて）、それゆえ承認されずに廃棄される。認証又は非承認パケットは送信者によって再送信される。メッセージ認証コードは、パケットがパケット内の秘密情報をファイヤーウォールに公開する必要なくアドレス及び/又はポート翻訳ファイヤーウォールを通過するような方法で定義される。１つのそのような定義によると、送信元及び/又は宛先ポート領域、及び、プロキシサーバ型のファイヤーウォールによって操作又は変更された他の領域は、ゼロのようなヘッダ内の値以外の値に設定され、又は、メッセージ認証コードに基づいた擬似ヘッダとともに無視される。メッセージ認証コードを算定するために使用された公開秘密情報又は秘密鍵は、トランスポート層の上位のプロトコル層によって供給される。これゆえ、そのような公開された秘密を折衝するため、認証されていないモードにおいてトランスポート層の使用を許可することへの準備がされる。折衝が完了すると、トランスポート層認証がその後に続くパケット情報の全てが認証されるように働く。このように、本発明は、ＴＬＳやＴＣＰといった現存するプロトコルを、代替の解決手段に費用を費やしたり新しいプロトコルを創ったりせずに最大限利用するものである。

これらの及び他の利点は、ここに含まれる発明の開示から明らかである。
上記に記載された具体例及び形態は、完結したものではなく網羅されたわけでもない。推察されるように、本発明の他の具体例は、単独であれ複合的であれ、１つかそれ以上の上述記載の又は下記に詳細に説明される特徴を利用することで可能となる。

図３は、本発明の第１の具体例によるアーキテクチャを示すものである。アーキテクチャは、少なくとも第１及び第２の終端、即ちノード３００ａ、ｂ及びファイヤーウォール３０４並びにノード３００ａ、ｂ間に位置するネットワーク３０８を含む。
第１及び第２のノード３００ａ、ｂは、パソコン又はＰＣ、サーバ、ラップトップ、パーソナルデジタルアシスタント又はＰＤＡ、ＩＰ電話、ＶｏＩＰメディアゲートウェイ、Ｈ.３２３ゲートキーパー等のコンピュータ機器である。各ノードは、伝送エージェント３１２及び暗号エージェント３１６並びに入力部又はインターフェイス３２２を含む。

伝送エージェント３１２は、（ａ）データのエラーのない配送を行い、（ｂ）セッション層、即ちＯＳＩのレイヤー５又はＴＣＰ/ＩＰのアプリケーション層のような隣接する上位の層からのデータを受け入れ、必要に応じてデータを小さいパケットに分け、パケットを、ネットワーク層、即ちＯＳＩのレイヤー３又はＴＣＰ/ＩＰのインターネット層のような隣接する下位のレイヤーに送り、パケットが完全に正しく宛先に着いたことを照合し、（ｃ）パケットの選択されたコンテンツを認証する。
暗号エージェント３１６は、(セキュリティ用の)Secure Socket Layer 即ちＳＳＬ及び/又は(セキュリティ用の)Transport Layer Security 即ちＴＬＳ(集合的に、ＳＳＬ/ＴＬＳとする場合もある)、(ネットワーク管理用の)Common Management Protocol 即ちＣＭＩＰ、(遠隔ファイル操作用の)File Transfer, Access及びManagement、(e-mail用の)Ｘ.４００、並びに/又は、特定のユーザー仕様のアプリケーションサービス及び手続きを定義するＳＡＳＬのようなプロトコルを含む。暗号エージェント３１６はＯＳＩサービスからの層（レイヤー５、６及び/又は７）又はＴＣＰ/ＩＰのアプリケーション層内で稼動できる。
ソケット３２０は、認証と伝送エージェント間のインターフェイスとなる。

推察されるように、ＯＳＩでレイヤー処理する工程は、アプリケーションプログラムによってメッセージが作られる送信元アプリケーション層、即ちレイヤー７で始まる。メッセージは、レイヤー１に到達するまで層間を下位へ移動する。レイヤー１は実際の物理通信媒体である。そして、パケット化されたデータは、この媒体を通じて受信ホスト端末に伝送され、ここでは情報はレイヤー１からレイヤー７まで層間をその処理とともに上位に移動していく。メッセージが送信元の端末で層間を下位へ移動するにつれ、メッセージは、特定の層に関係するＩＰヘッダ２３２、ＡＨ２０４、ＴＣＰ若しくはＵＤＰヘッダ２３６又はＥＳＰＨ２５４（図２Ａ及び２Ｂ）のようなヘッダでカプセル化される。ＴＣＰ/ＩＰ層は同様に動作する。
ファイヤーウォール３０４は適合するファイヤーウォールであればよい。例えば、フレーム・フィルタリングファイヤーウォール、パケット・フィルタリングファイヤーウォール、回路ゲートウェイファイヤーウォール、ステートフルファイヤーウォール又はアプリケーションゲートウェイ若しくはプロキシサーバファイヤーウォールがファイヤーウォールとなる。
ネットワーク３０８は、インターネットのようにデジタルであれアナログであれ分散処理ネットワークであればよい。

伝送エージェント３１２による認証に使用されるＴＣＰヘッダは図４から６を参照して説明される。図４はＴＣＰヘッダ４００の従来技術フォーマットを示す。ＴＣＰヘッダ４００は、送信元ポート４０４、宛先ポート４０８、(上記の)パケットシーケンス番号４１２、(通知が送られる前に受信され受け入られた最後のバイト番号を示す)バイト通知番号４１６、(パケットの最初のデータ位置を示す)データオフセット４２０、フラグ領域４２２、予約４２４、(受信され蓄えられ得るバイト数を示す)ウインドウ４２８、チェックサム４３２、(パケット中の緊急データの存在を示す)緊急ポインタ４３６、(プロトコルに関連した種々のオプションを含む)オプション４４０、及び(ヘッダが所望の長さであることを確認するのに充分な、ゼロビットでオプションフィールドを埋める長さ可変の領域である)パディング４４４に対する領域を含む。本発明によれば、ＴＣＰパケットデータユニット(ＰＤＵ)又はパケットの認証は、オプションフィールド４４０内に認証オプションを含むことによって可能となる。推察されるように、オプションフィールド内のオプションは、２つの形式、即ち、(オプションの長さが２)オクテットのオプションデータの前に位置し、１オクテットのオプション長の前に位置する単オクテット値のオプション種又は１オクテットのオプション種のいずれか１つの形式を取ることができる。１つの形態において、認証オプションは２番目の形式である。

図５は第２の形式の認証オプションを示す。認証オプション５００は次に挙げる領域、即ちオプションインジケータ５０４、長さ５０８及びメッセージ認証コード５１２を含む。オプションインジケータ領域５０４は、指定されたオプション番号ビット、即ちパケット認証オプションに対する値であり、長さ領域５０８は、メッセージ認証コード、即ちＭＡＣの長さであり、メッセージ認証コード５１２領域はメッセージ認証コード自身を含む。ＭＡＣは、ＨＭＡＣ-ＳＨＡ１-Ｎ及びＨＭＡＣ-ＭＤ５-ＮをそれぞれＮビットへ間引いたＨＭＡＣ-ＭＤ５及びＨＭＡＣ-ＳＨＡ１アルゴリズムのような錠をかけられたハッシュドメッセージ認証コードを含むあらゆる技術で算定され得る。他のサポートされるメッセージ認証コードは、サイファフィードバック暗号化に基づいた暗号的に安全なあらゆる鍵をかけられたＭＡＣを含む。これらのコードはまた、好ましくはＮビットに間引く。ハッシュドメッセージの認証コードの間引きによって、侵入者がハッシング鍵の情報を解読するのを防ぐものである。コード生成のために使用される鍵は、暗号エージェントから受け取る。

ＭＡＣの算定は図６を参照して説明される。ＭＡＣの算定は、ＴＣＰヘッダ及びペイロードの全部又は一部で、選択された領域をゼロ（即ちゼロビット）に設定することで実行される。図６において、ＭＡＣは、ＴＣＰヘッダ及びペイロード全域に存在する擬似ヘッダ６００で、擬似ヘッダ内の各ゼロ（即ちゼロビット）にセットされた送信元ポート領域６０４、宛先ポート領域６０８及びチェックサム６１２並びにパケットのボディをもって実行される。これゆえ、これらを担う送信元及び宛先ポート並びにチェックサムは、あるタイプのファイヤーウォールによって操作されうるが、ＭＡＣの算定から除外される。これは、アドレス伝送又はアドレス-ポート伝送ファイヤーウォールを通過する際の認証に影響を与えずに、ＴＣＰヘッダが従来のやり方で操作されるのを可能とする。
(緊急ポインタ領域が充分であることを示す)緊急ポインタフラグ、(データが使用層に押し込まれるべきことを示す)ＰＳＨフラグ、終了フラグ、通知フラグ、(同期したシーケンス番号が送られるべきことを示す)“ｓｙｎ”フラグ、ＲＳＴフラグ（リセット接続）、シーケンス番号、通知番号、データオフセット、ウインドウ、オプション、パディングといったファイヤーウォールに操作されないパケット内の領域は、異なる値に設定されない。一般に、通知領域及びＡＣＫ領域は他のフラグとともに認証で保護されるはずである。

推察されるように、擬似ヘッダ６００内の１又はそれ以上の送信元ポート領域６０４、宛先ポート領域６０８及びチェックサム領域６１２は、アプリケーションに従ってゼロでない値にセットされ得る。ＭＡＣの算定において、送信元及び宛先ポート領域６０４及び６０８は、ＭＡＣの判定において不一致を避けるためファイヤーウォールの両側の各ノードによって一定に保たれる。通常、各領域の値はファイヤーウォール３０４並びに第１及び第２のノード３００ａ、ｂのアドレスとは異なり、かつ、独立したものとなる。例えば、第１のノードから第２のノードへ伝送されるパケットは、送信元ポート領域を擬似ヘッダ６００内で一定値にセットしなければならない。一方、第２のノードから第１のノードへ伝送されるパケットは、ファイヤーウォールによるポート変換からの混乱を避けるために宛先ポート領域を擬似ヘッダ６００内で一定値にセットしなければならない。
認証オプション５００（図５）は、擬似ヘッダのオプション領域に含まれる。ファイヤーウォールによって変更されないようにする要求はないが、オプションデータ領域は適切な長さであり、通常、全てゼロ（即ちゼロビット）にセットされる。標準のＴＣＰチェックサムは実際のヘッダを使用して算定される。

暗号エージェント３１６は、アルゴリズムの選択と施錠のデータをアルゴリズムに提供することによってＴＣＰ接続のどちらの方向においても認証を稼働する。一度送信側暗号エージェント３１６によって稼働されると、全ての送信されたパケットは有効な認証オプション５００を含むはずであり、送信側暗号エージェントによって稼働されない場合は、生成されたＴＣＰヘッダのいずれも認証オプションを含まないことになる。認証が暗号エージェント３１６を受け取ることによって稼働されると、全ての受信したパケットは有効な認証オプション５００を含むはずであり、上記のように、ここに含まれるＭＡＣは受信したパケットに一致するはずであるが、そうでない場合はパケットが伝送エージェント３１２によって無効であるとみなされる。認証が受信側暗号エージェント３１６によって稼働されると、認証を通過できないか又は有効な認証オプション５００を含まないパケットは、伝送エージェント３１２によって同様に無効なチェックサムのパケットとして扱われる。認証エラーは伝送エージェント３１２によってログ又はカウントされ、ログ/カウントは伝送エージェント３１２から暗号エージェント３１６によって利用可能となり、又は要求に応じて層を使うことになる。伝送エージェント３１２から暗号エージェント３１６によって報告されない受信データは、暗号エージェント３１６が稼働を連係したであろう、それゆえ、このデータは侵入者に注入されたか、伝送中に危害を受けたに違いないという推測の下、廃棄される（そして、受信シーケンス番号も同様に進められない）。認証が受信側暗号エージェント３１６によって稼働されないとき、認証オプション５００を持つ全てのパケットは廃棄される。これは、送信側暗号エージェント３１６が認証されたパケットを期待しているが、受信側暗号エージェント３１２は、まだそうするために必要な認証パラメータを供給されていないことによる。

伝送及び暗号エージェント３１２及び３１６の動作は図７及び図８を参照して説明される。
図７は、各ノードにおける暗号エージェントによって実行される動作を示すものである。図７のステップ７００において、第１のノード３００ａ及び第２のノード３００ｂの暗号エージェント３１６は、従来の技術を用いた安全でないチャネル上のプロトコルパラメータを通過する。通常、折衝は、鍵、場合によってはデジタル証明書を交換する双方の当事者を関与させる。公開されるマスター鍵は交換された鍵から算定される。第１及び第２のノードによって交換された終了したメッセージにおいてハッシュが一致すると、折衝は完了する。通常、交換はデジタル著名を通じて暗号エージェントレベルで有効にされる。

折衝が完了すると、大量のメッセージが第１及び第２のノード間で交換される。ステップ７０４において、第１及び第２のノードは、スタートサイファ又は変更サイファスペックの命令を第２のノードに送り、逆もまた同様である。第１及び第２のノード内の暗号エージェント３１６がスタートサイファ命令を送ると、ステップ７０８においてエージェント３１６は対応する伝送エージェント３１２に送信認証を起動するように命令を出し、他のノードに伝送されるパケットの認証動作を実行するためにエージェント３１２に必要な情報（通常は送信鍵及びメッセージ認証コードアルゴリズムの識別のような公開秘密情報）を提供する。ステップ７１２において、第１及び第２のノード内の暗号エージェント３１６が他のノードからスタートサイファ命令を受け取ると、ステップ７１６において、エージェント３１６は対応する伝送エージェント３１２に送信認証を起動するように命令を出し、受信されたパケットの認証動作を実行するためにエージェント３１２に必要な情報（通常、(送信鍵とは異なる)受信鍵及びメッセージ認証コードアルゴリズムの識別のような公開秘密情報）を提供する。ステップ７０８が第１及び第２のノードによって実行された後、ステップ７２０において他のノードへ伝送するため、認証されるデータが対応する伝送エージェント３１２に提供される。ステップ７２０又は７１６が実行された後、ステップ７２４における暗号エージェント３１６は他のノードからのデータの受信を待つ。

図８Ａ及びＢは、各ノードにおいて伝送エージェントによって実行される動作を説明するものである。
図８Ａに示すステップ８００において、伝送エージェント３１２は送信認証命令及び認証情報を受け取る。応答において、伝送エージェント３１２は、認証オプション５００が第２のノードに送信された各パケットのオプション領域４４０に含まれる送信認証モード（第１のモード）を起動する。ステップ８０８において、伝送エージェント３１２は、パケットヘッダのオプション領域４４０内に含まれる認証オプション５００を生成することによってデータを認証する。前述のように、オプション５００の構築において、伝送エージェント３１２は、図６の擬似ヘッダ及び公開秘密情報に基づいて、Ｎビットへの間引きをもって、メッセージ認証コードを算定する。ステップ８１２において、伝送エージェント３１２は、パケットをフォーマットし、他のノードの伝送エージェントに送る。ステップ３１２を実行した後、ステップ８１６において送信側伝送エージェント３１２は暗号エージェント３１６からの更なるデータを待つ。

図８Ｂに示すステップ８２０において、伝送エージェント３１２は受信認証命令及び認証情報を受け取る。応答において、伝送エージェント３１２は、認証オプション５００が第２のノードに受信される各パケットのオプション領域４４０に含まれるはずの受信認証モードを起動する。推察されるように、このモードは受信された全パケット又は第２のノードから受信したパケットだけのために起動される。ステップ８２４において、伝送エージェントは他のノードの送信側伝送エージェントからパケットを受信する。分岐処理８２８において、受信側伝送エージェント３１２は受信したパケットが認証オプションを含んでいるか否か判断する。パケットが認証オプションを含んでいる場合、ステップ８３２において、伝送エージェント３１２は、Ｎビットに間引かれ、パケット擬似ヘッダ及び他のコンテンツ並びに公開された秘密に基づいたメッセージ認証コードを算定し、算定されたメッセージ認証コードと認証オプションの領域５１２のメッセージ認証コードを比較することによってパケットを認証する。分岐処理８３６において、伝送エージェント３１２はパケット認証が成功したか否か判断する。メッセージ認証コードが識別できない場合、パケット認証は失敗であり、エージェント３１２は後述のステップ８４０へ進む。メッセージ認証コードが識別できる場合、パケット認証は成功であり、エージェント３１２はステップ８４４へ進む。ステップ８４４において、パケットに含まれるデータは対応する受信側ノードの暗号エージェント３１６に転送される。分岐処理８２８においてパケットが認証オプション５００を含んでいない場合、又は、分岐処理８３６において認証が成功でない場合、ステップ８４０で伝送エージェント３１２はパケットを廃棄し、ステップ８４８において認証エラーをログ及びカウントし、ステップ８５２においてシーケンス番号を進めないようにする。パケットが廃棄された場合、廃棄されたパケットの受信成功の通知を受けないので、送信側ノードはパケットを再送信し、これによりＤｏＳ攻撃した者の能力を大きく低下、減退させる。エージェント３１２は、その後、ステップ８５６に進み、受信される次のパケットを待つ。

プロキシサーバに操作される送信元及びアドレス領域並びにチェックサム領域が、メッセージ認証コードに基づいた擬似ヘッダ６００内でゼロ（即ちゼロビット）にセットされているので、ファイヤーウォールアドレス及び/又はポート翻訳は、暗号エージェント３１６において、ＳＳＬ及びＴＳＬのようなセキュリティプロトコルの動作を干渉しない。
推察されるように、伝送エージェント３１２は、暗号エージェント３１６によって受信される停止サイファ命令（例えば、次の変更サイファスペック命令又は終了命令）への応答において、第１又は認証モードに戻るようにリセットされる。認証停止命令は、その後受信側暗号エージェントによって対応する暗号エージェントに送信される。

送信認証モードにおいて送信され、及び、受信認証モードにおいて受信された全パケットは、認証オプションを含むはずなので、それらのモードにおいて送信/受信された通知パケットはそれらのヘッダ内に認証オプションを含むはずである。これが、ＤｏＳ攻撃する者が偽の通知を送信側ノードに送ることによってセッションを妨げたり終了させたりするのを防ぐ。

この発明の多くの展開例や変更例が使用され得る。他の物を付加せずにこの発明の特徴を満足することは可能であろう。
例えば、他の変更例において、伝送エージェント３１２は上記で構成されたプロトコル以外のプロトコルとともに実現され得る。例えば、伝送エージェントのそのような他のプロトコルは、他のバージョンのＴＣＰ、ＵＤＰ、インターネット制御メッセージプロトコル、即ちＩＣＫＰ、又はセッション制御トランスポートプロトコル、即ちＳＣＴＰを含む。ＳＣＴＰはデータ伝送及び通知にまとまって配置される。ＳＣＴＰの１つの改作は、２つの新しいペイロードタイプを定義し、まとまったコンテンツを制限するものである。１つのペイロードタイプは認証ストリームのためのものとなり、他はそのストリームの通知のためのものとなるであろう。

同様に、他の具体例において、暗号エージェントはＩＰＳｅｃやそれに類するもののような多くの適合する保護プロトコルを使用し得る。

他の代替例において、トランスポート層ヘッダだけでなくＢｕｍｐとしてＯＳＩレイヤー３と４間のStack又はBITSの実現において、認証オプションの実現があり得る。

また、他の代替例において、認証オプションはＯＳＩトランスポート層に相当するＴＣＰ/ＩＰ層に存在する。例えば、認証オプションはＴＣＰ/ＩＰのホスト-ホストトランスポート層となり得る。

また、さらなる代替例として、ＯＳＩレイヤー３、４、５、６及び/又は７で定義される又はされない擬似ヘッダが、ヘッダ及び/又はペイロードの一部分のみを意味し、図６におけるそれらに対する１又はそれ以上の異なる領域を含む場合もある。

他の代替例において、伝送エージェント及び/若しくは暗号エージェント又はコンポーネントが、ソフトウェアに加えて、又は、その代わりに、ユーザー専用ＩＣのようなロジック回路として具現化される。

本発明は、種々の具体化、部分的な組み合わせ及び部分的集合をここに含みながら、様々な具体例において、コンポーネント、方法、工程、システム及び/又は機器をここで描かれ記述されたように実質的に含むものである。当業者であれば、この開示を理解した後に、いかにして本発明を準備し使用するかを理解できるであろう。本発明は、様々な具体例において、ここに又はこれに関する種々の具体例において描かれ及び/又は記述されていない要素がなくても、前述の装置又は工程で使用されたような要素がない場合も含めて、例えば、性能向上、簡素化及び/又は実現コスト低減のための装置及び工程も含むものである。

発明に関する前述のディスカションは例示と説明の目的で示されたものである。前述のものは発明をここに開示された形に制限するものではない。前述の詳細な説明において、発明の様々な特徴は、開示を合理的なものとする目的で１又はそれ以上の具体例にまとめられている。この開示の方法は、主張される発明が各請求項で明確に列挙される以上の特徴を必要とする意図を反映するように解釈されるべきものではない。むしろ、特許請求の範囲が反映するように、発明の特徴は前述の開示された一具体例の全特徴を超えないところにある。これゆえ、特許請求の範囲は、各請求項が本発明の別個の好適な具体例として単独で成り立つ状態で詳細な説明に組み入れられる。
さらに、発明の説明は１又はそれ以上の具体例並びにある展開例及び変更例の説明を含んだものであるが、例えば、この開示を理解した後に当業者の技術や知識の範囲内となるような他の展開例及び変更例も本発明の範囲に入る。本願は、交換可能な及び/又は同等の構成、機能、範囲又は工程がここに開示されたか否かにかかわらず、請求項に記されたものに対してそのような代替の、交換可能な及び/又は同等の構成、機能、範囲又は工程を含み、許可される限りの代替の具体例を含む権利を得ることを意図するものである。

従来のプロキシサーバ型ファイヤーウォールを示すブロック図である。 従来のパケット及び認証ヘッダを示す図である。 従来のパケット及びカプセル化セキュリティヘッダを示す図である。 本発明の具体例によるプロキシサーバ型ファイヤーウォールを示すブロック図である。 従来のＴＣＰによるトランスポート層ヘッダを示す図である。 本発明による認証ＴＣＰオプション領域を示す図である。 メッセージ認証コードを算定するための擬似ヘッダを示す図である。 暗号エージェントの動作を示すフローチャートである。 追跡エージェントの動作を示すフローチャートである。 追跡エージェントの動作を示すフローチャートである。

符号の説明

３００ａ、ｂ ノード
３０４ ファイヤーウォール
３０８ ネットワーク
３１２ 伝送エージェント
３１６ 暗号エージェント
３２０ ソケット
３２２ インターフェイス

Claims (21)

1. パケットを認証する方法であって、
   ヘッダ及びペイロードからなるパケットを受信し、
   該パケットの少なくともいくつかから生成される少なくとも１つの送信元及び宛先ポート領域が該パケットヘッダにおいて対応する該送信元及び宛先ポート領域とは異なる値を有する擬似ヘッダに少なくともある程度基づいた第１のメッセージ認証コードを算定し、
   該パケットを認証するために該ヘッダにおいて該第１のメッセージ認証コードを第２のメッセージ認証コードと比較することからなる方法。
2. 請求項１記載の方法であって、該ヘッダが送信ヘッダ部からなり、該第２の認証コードが該送信ヘッダ部にある方法。
3. 請求項１記載の方法であって、少なくとも１つの該送信元及び宛先ポート領域が該ヘッダにおいて対応する送信元又は宛先ポート領域と異なる値にセットされた擬似ヘッダに基づいて第２の認証コードが算定される方法。
4. 請求項３記載の方法であって、該擬似ヘッダにおいて、少なくとも１つの該送信元及び宛先領域が該ヘッダにおいて該送信元及び宛先領域から独立した値を有する方法。
5. 請求項４記載の方法であって、少なくとも１つの該送信元及び宛先がゼロにセットされ、該送信ヘッダ部がＯＳＩトランスポート層及びＴＣＰ/ＩＰホスト-ホストトランスポート層の１つで定義される方法。
6. 請求項１記載の方法であって、
   該第１及び該第２の認証コードがハッシュドメッセージ認証コードであり、
   該第１及び該第２の認証コードが予め定められたビット数に間引かれ、
   該第１及び該第２のメッセージ認証コードが該送信ヘッダ部を使用して決定され、
   該比較する工程において該第１及び該第２のメッセージ認証コードが識別できない場合に該パケットが無効とみなされ、
   さらに、パケット無効の場合を表示するカウンタを増加させることからなる方法。
7. 請求項１記載の方法であって、さらに、該受信する工程の後に、
   第１のモードにおいて、該ヘッダが有効な該第２のメッセージ認証コードからなる認証オプションを含まない場合に該パケットを廃棄し、
   第２の異なるモードにおいて、該第１のモードにおいてのみ起きる工程を算定及び比較して、該ヘッダが認証オプションを含む場合は該パケットを廃棄することからなる方法。
8. 請求項７記載の方法であって、該第２のモードの稼働中に、さらに、
   該第２のモードを切断して該第１のモードを起動するために上位層から命令を受け取り、
   該命令への応答において該第２のモードを切断して該第１のモードを起動することからなり、
   該命令が該アプリケーション層によって発せられるとともに送信認証命令及び受信認証命令の１つである方法。
9. 請求項７記載の方法であって、さらに、該第１のモードにおいて、
   該パケットの少なくともいくつかのコンテンツに基づいた第１のメッセージ認証コードを算定し、
   該パケットを認証するために該送信ヘッダ部において該第１のメッセージ認証コードを第２のメッセージ認証コードと比較することからなり、
   該第２の認証コードは該送信ヘッダ部にあることからなる方法。
10. 請求項１記載の方法であって、さらに、
    送信ヘッダ部を含む該パケットをアセンブルし、
    第１のモードにおいて該送信ヘッダ部において有効な認証オプション領域を含み、
    第２の異なるモードにおいて該送信ヘッダ部において有効な認証オプション領域を含まず、
    前記の後に該パケットを送信することからなる方法。
11. パケットであって、
    トランスポート層ヘッダ部であって、該トランスポート層ヘッダ部が、
    送信元ポート領域、宛先ポート領域、シーケンス番号領域及びオプション領域からなり、該オプション領域が認証オプションからなり、該認証オプションがメッセージ認証コードからなるトランスポート層ヘッダ部、及び、
    ペイロードからなるパケット。
12. 請求項１１記載のパケットであって、該メッセージ認証コードが、少なくとも１つの該送信元及び宛先ポートの領域が該パケットのヘッダにおいて対応する送信元及び宛先ポート領域とは異なる値にセットされる擬似ヘッダに基づいて算定されるパケット。
13. パケットを認証するアーキテクチャであって、
    ヘッダ及びペイロードからなるパケットを受信する入力手段、
    少なくともいくつかの該パケットヘッダから生成される少なくとも１つの送信元及び宛先ポート領域が該パケットヘッダにおいて対応する該送信元及び宛先ポート領域とは異なる値を有する擬似ヘッダに少なくともある程度基づいた第１のメッセージ認証コードを算定する算定手段、及び、
    パケットを認証するため該ヘッダにおいて該第１のメッセージ認証コードを第２のメッセージ認証コードと比較する比較手段からなるアーキテクチャ。
14. 請求項１３記載のアーキテクチャであって、該ヘッダが送信ヘッダ部からなり、
    該第２の認証コードが該送信ヘッダ部にあり、
    該第２の認証コードが少なくとも１つの該送信元及び宛先ポート領域が該ヘッダにおいて対応する送信元及び宛先ポート領域とは異なる値を有する擬似ヘッダに基づいて算定されるアーキテクチャ。
15. 請求項１４記載のアーキテクチャであって、該擬似ヘッダにおいて、少なくとも１つの該送信元及び宛先領域が該ヘッダにおいて該送信元及び宛先領域から独立した値を有するアーキテクチャ。
16. 請求項１５記載のアーキテクチャであって、少なくとも１つの該送信元及び宛先がゼロにセットされ、該送信ヘッダ部がＯＳＩトランスポート層及びＴＣＰ/ＩＰホスト-ホストトランスポート層の１つで定義されるアーキテクチャ。
17. 請求項１３記載のアーキテクチャであって、
    該第１及び該第２の認証コードがハッシュドメッセージ認証コードであり、
    該第１及び該第２の認証コードが予め定められたビット数に間引かれ、
    該第１及び該第２のメッセージ認証コードが該送信ヘッダ部を使用して決定され、
    該比較ステップにおいて、該第１及び該第２のメッセージ認証コードが識別できない場合に該比較手段が該パケットを無効とみなし、
    さらに、パケット無効の場合を表示するカウンタを増加させるカウンタ手段からなるアーキテクチャ。
18. 請求項１３記載のアーキテクチャであって、さらに、第１のモードにおいて該ヘッダが該第２のメッセージ認証オプションからなる有効な認証オプションを含まない場合に該パケットを廃棄し、第２の異なるモードにおいて該ヘッダが認証オプションを含む場合に該パケットを廃棄するパケット廃棄手段からなり、
    該算定及び比較手段の稼働が該第１のモードにおいてのみ起こり、該パケットが受信された後に該廃棄動作が行われるアーキテクチャ。
19. 請求項１８記載のアーキテクチャであって、該第２のモードの稼働中に、
    該廃棄手段が該第２のモードを切断して該第１のモードを起動するための上位層からの命令を受け取ると、該命令への応答において該第２のモードを切断して該第１のモードを起動し、
    該命令が該アプリケーション層によって発せられ、送信認証命令及び受信認証命令の１つであるアーキテクチャ。
20. 請求項１８記載のアーキテクチャであって、該廃棄手段が、該第１のモードにおいて、該パケットのコンテンツの少なくともいくつかに基づいた第１のメッセージ認証コードを算定し、該パケットを認証するため該送信ヘッダ部において該第１のメッセージ認証コードを該送信ヘッダ部にある第２のメッセージ認証コードと比較するアーキテクチャ。
21. 請求項１３記載のアーキテクチャであって、さらに、
    パケットをアセンブルする手段であって、該パケットヘッダが送信ヘッダ部を含む手段、
    第１のモードにおいて該送信ヘッダ部に有効な認証オプション領域を含むための、及び、第２の異なるモードにおいて該送信ヘッダ部に有効なオプション領域を除外するための手段、並びに、
    上記の後に該パケットを送信するための手段からなるアーキテクチャ。
    

Images