(57)【要約】  本発明の基本概念は、信頼性のあるトランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行することである。好ましくは、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、データセキュリティ処理が、２つのメッセージシーケンス空間で別々に実行される。
2008535080.tif 000002
【特許請求の範囲】
【請求項１】
データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供する方法であって、
前記トランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、
前記セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行する
ことを特徴とする方法。
【請求項２】
前記信頼性のあるトンラスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）である
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュリティプロトコルは、非順序化配信用のセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記信頼性のあるトランスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）であり、
前記セキュリティプロトコルは、ＳＣＴＰ順序化配信用の基本セキュリティ処理と非順序化配信用のＳＣＴＰセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記セキュリティ処理拡張の使用は、セッションセットアップ中にネゴシエートされる
ことを特徴とする請求項４に記載の方法。
【請求項６】
セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージとは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、
データセキュリティ処理が、前記２つのメッセージシーケンス空間で別々に実行される
ことを特徴とする請求項１に記載の方法。
【請求項７】
非順序化配信メッセージ用の前記セキュリティ処理は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている
ことを特徴とする請求項６に記載の方法。
【請求項８】
非順序化配信メッセージは、非順序化メッセージに向けられている専用メッセージタイプの導入によって識別され、
前記非順序化メッセージのそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から割り当てられる明確なシーケンス番号を有している
ことを特徴とする請求項６に記載の方法。
【請求項９】
受信されている前記非順序化メッセージの概念リスト、あるいは受信されていない前記非順序化メッセージのその概念リストの代替リストが、非順序化配信メッセージに対する再生保護を実行するために保持される
ことを特徴とする請求項７または８に記載の方法。
【請求項１０】
セキュリティプロトコル接続の切断用の切断メッセージは、送信済の非順序化データメッセージの最終シーケンス番号を含み、
非順序化レコード空間内の送信済のすべてのレコードの信頼性のある受信は、前記切断メッセージの最終シーケンス番号に基づいて検出される
ことを特徴とする請求項７または８に記載の方法。
【請求項１１】
データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供するシステムであって、
前記トランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離する手段と、
前記セキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行する手段と
を備えることを特徴とするシステム。
【請求項１２】
前記信頼性のあるトランスポートプロトコルは、ＳＣＴＰ（ストリーム制御送信プロトコル）であり、
前記セキュリティプロトコルは、ＳＣＴＰ順序化配信用の基本セキュリティ処理とＳＣＴＰ非順序化配信用のセキュリティ処理拡張を有するＴＬＳ（トランスポートレイヤセキュリティ）に基づいている
ことを特徴とする請求項１１に記載のシステム。
【請求項１３】
データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている受信機であって、
前記トランスポートプロトコルの上位において、セキュリティプロトコルで順序化配信データと非順序化配信データとを分離する手段と、
順序化配信データ用の前記セキュリティプロトコルで、第１タイプのセキュリティ処理を実行する手段と、
非順序化配信データ用の前記セキュリティプロトコルで、第２タイプのセキュリティ処理を実行する手段と
を備えることを特徴とする受信機。
【請求項１４】
前記受信機は、ＳＣＴＰ（ストリーム制御送信プロトコル）に基づいて動作するように構成され、
前記受信機は、ＳＣＴＰ順序化配信用の基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理とＳＣＴＰ非順序化配信用のＴＬＳセキュリティ処理拡張を実行するように構成されている
ことを特徴とする請求項１３に記載の受信機。
【請求項１５】
前記分離する手段は、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージとを、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離するように構成されている
ことを特徴とする請求項１３に記載の受信機。
【請求項１６】
前記分離する手段は、非順序化メッセージに向けられている専用メッセージタイプの検出に基づいて非順序化配信メッセージを識別するように構成されていて、
前記非順序化メッセージのそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から割り当てられる明確なシーケンス番号を有している
ことを特徴とする請求項１５に記載の受信機。
【請求項１７】
非順序化配信メッセージ用のセキュリティ処理は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている
ことを特徴とする請求項１５または１６に記載の受信機。
【請求項１８】
非順序化配信メッセージに対する再生保護を実行するための、受信されている前記非順序化メッセージの概念リスト、あるいは受信されていない前記非順序化メッセージのその概念リストの代替リストを保持する手段を更に備える
ことを特徴とする請求項１７に記載の受信機。
【請求項１９】
データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている送信機であって、
前記トランスポートプロトコルの上位において、セキュリティプロトコルで順序化配信用に意図されているデータと非順序化配信用に意図されているデータとを分離する手段と、
データの順序化配信用の前記セキュリティプロトコルで、第１タイプのセキュリティ処理を実行する手段と、
データの非順序化配信用の前記セキュリティプロトコルで、第２タイプのセキュリティ処理を実行する手段と
を備えることを特徴とする送信機。
【請求項２０】
前記送信機は、ＳＣＴＰ（ストリーム制御送信プロトコル）に基づいて動作するように構成され、
前記送信機は、ＳＣＴＰ順序化配信用の基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理とＳＣＴＰ非順序化配信用のＴＬＳセキュリティ処理拡張を実行するように構成されている
ことを特徴とする請求項１９に記載の送信機。
【請求項２１】
前記第２タイプのセキュリティ処理を実行する手段は、非順序化データメッセージだけに明確なシーケンス番号を割り当てるように構成されている
ことを特徴とする請求項１９または２０に記載の送信機。
【請求項２２】
データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルとともに動作するように構成されているセキュリティプロトコルディスパッチャであって、
指示されている配信のタイプに従って、順序化配信用の第１タイプのセキュリティプロトコル処理へ、あるいは非順序化配信用の第２タイプのセキュリティプロトコル処理へディスパッチする手段を備える
ことを特徴とするセキュリティプロトコルディスパッチャ。
【請求項２３】
前記ディスパッチする手段は、順序化配信用のデータを基本ＴＬＳ（トンラスポートレイヤセキュリティ）セキュリティ処理へディスパッチし、また、非順序化配信用のデータをＴＬＳセキュリティ処理拡張へディスパッチするように構成されている
ことを特徴とする請求項２２に記載のセキュリティプロトコルディスパッチャ。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、信頼性のある転送プロトコル（reliable transport protocol）のセキュリティに関するものであり、詳しくは、順不同で配信されるデータの保護に関するものである。
【０００２】
発明の背景
一般的には、本発明は、順序付けされた（ordered：順序化）データの配信及び順序付けされていない（unordered：非順序化）データの配信をサポートする信頼性のある転送プロトコルに関係する。ストリーム制御送信プロトコル（ＳＣＴＰ）文献［１］は、このような転送プロトコルの例であり、これは、ＩＥＴＦのＳＩＧＴＲＡＮワーキンググループで開発されている。これは、当初は、ＰＳＴＮテレフォニーシグナリングメッセージを搬送するために設計されていた。これは、ＴＣＰでは利用できないが、いくつかの有用な特徴を有しているので、今日では、汎用転送プロトコルとされていて、また、ＴＣＰに代るものとされている。
【０００３】
通常は、ＳＣＴＰストリーム内では、データメッセージは、それらのストリームシーケンス番号に従う順序で配信される。データメッセージが順不同で受信エンドポイントに到達する場合（即ち、以前から）、そのデータメッセージの前にあるデータメッセージのすべてが受信され、かつ上位レイヤに配信されるまで、そのデータメッセージの上位レイヤへの配信は保留されなければならない。ＳＣＴＰエンドポイントは、順序化配信が、ストリーム内で送信される特定のＤＡＴＡチャンク（chunk：塊）に対して必要とされないことを示すことができる。エンドポイントが非順序化配信で示されるＤＡＴＡチャンクを受信する場合、ＳＣＴＰ非順序化配信を示す図１で示されるように、これは、順序化メカニズムをバイパスして、直ちにそのデータを上位レイヤに配信することができる。
【０００４】
非順序化配信は、アプリケーションが大量の独立トランザクションを処理する場合でのヘッドオブライン（ＨＯＬ）ブロッキングの回避に有用である。ＨＯＬブロッキングは、複数の独立トランザクションが順序通りにシングルデータストリームで搬送され（例えば、ＴＣＰ接続）、かつそれらの独立トランザクションの内の１つでいくつかのデータが遅延する場合に発生する。そのデータ到達が遅延する独立トランザクションと、それ以外の独立トランザクションとが相関してないとしても、その遅延データが到達するまで、その独立トランザクションの後に続く他のトランザクションのすべては、上位レイヤへの配信がブロックされ、かつ待機しなければならない。
【０００５】
この種のアプリケーションの例は、転送プロトコルとしてＳＣＴＰを使用してシグナリングメッセージを交換するＳＩＰプロキシ群を示す図２で示されるように、複数のＳＩＰエージェント２０−Ａ及び２０−Ｂに対する、２つのＳＩＰプロキシ１０−Ａ及び１０−Ｂ間のＳＩＰシグナリングメッセージ（例えば、呼セットアップ／メッセージ分解、課金情報及び転送クエリーメッセージ）の転送がある。これらのＳＩＰシグナリングメッセージは、互いに独立していて、これらのシグナリングメッセージの到達順序は重要ではない。しかしながら、それらが適時に到達することは重要である。ＳＩＰプロキシ間のＳＩＰシグナリングメッセージを搬送するためにＳＣＴＰの非順序化配信を使用することは、ＴＣＰで存在するＨＯＬブロッキングを回避し、また、ＳＣＴＰの非順序化配信を用いることで、ＳＩＰトランザクションのＳＩＰメッセージの損失が、他のトランザクションのＳＩＰメッセージの適時配信に逆影響を与えることはない。ＨＯＬブロッキングは、ＳＣＴＰのマルチストリーミング特性を使用することによっても回避することができる（即ち、各ＳＩＰトランザクションを、自身が所有するＳＣＴＰストリームに割り当てる）。しかしながら、このことは、より多くのストリームリソースを必要とし、実現可能でない可能性がある。文献［２］では、ＳＩＰシグナリングメッセージを搬送するためにＳＣＴＰが使用される場合、非順序化配信を用いて、ＳＩＰエンティティは、各ＳＩＰメッセージをゼロストリームを介して送信すべきであることを明確に示している。
【０００６】
別の例には、ＡＡＡ（認証、認可及びアカウンティング）メッセージの転送がある。ユーザが、ネットワーク内のセキュリティゲートウェイあるいは他のエンティティを認証する場合、そのエンティティはそのユーザを認証するために必要な不可欠な情報を通常は含んでない。一方、ＤＩＡＭＥＴＥＲプロトコルは、ＤＩＡＭＥＴＲサーバを用いる典型的な認証を使用する場合を示す図３で示されるように、ＡＡＡサーバからセッション認証情報を取得するために使用される。ＡＡＡサーバ３０とアクセスゲートウェイ４０間のインタフェースのＨＯＬブロッキングを回避するために、ＳＣＴＰの非順序化配信方法を使用することができる、あるいは各ユーザ５０に対して別々の信頼性のあるストリームを確立することができる。このインタフェースは通常保護されていて、また、ＴＬＳ（トランスポートレイヤセキュリティ）プロトコルが広く選択されている。ＴＬＳは非順序化配信（以下で説明するように）を用いて使用することができないので、上述のようなより多くのストリームリソースを必要とするマルチストリーミングが頻繁に使用される。このシステムセットアップが使用される例には、文献［３］で定義される汎用ブートストラップアーキテクチャがある。
【０００７】
ＳＣＴＰアソシエーションのデータセキュリティが、ネットワークレイヤのＩＰ認証ヘッダ（ＡＨ）文献［４］あるいはＩＰカプセル化ヘッダ（ＥＳＰ）文献［５］を使用することによって達成することができることが文献［１］で説明されている。しかしながら、ＡＨ及びＥＳＰは、ミドルボックスのようなデバイスと互換性がない。ＳＣＴＰアソシエーションのデータセキュリティも、トランスポートレイヤの上位のトランスポートレイヤセキュリティ（ＴＬＳ）プロトコル文献［６］を使用することによって達成することができるが、これは、順序化配信に対してのみである。順序化配信に対し、ＳＣＴＰを介するＴＬＳを使用することが、文献［７］に記載されている。文献［８］は、ＤＴＬＳ（データグラムトランスポートレイヤセキュリティ）プロトコルを記載していて、これは、すべてのＤＴＬＳレコードに対してシーケンス番号に基づく処理を使用する、ＴＬＳのデータグラム互換改良型である。
【０００８】
発明の要約
本発明は、従来技術の構成の上記の欠点及び他の欠点を解消する。
【０００９】
本発明の一般的な目的は、データの順序化配信とデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するセキュリティを改善することである。
【００１０】
特に、後述するように、非順序化配信機能を使用するデータに対して、トランスポートレイヤの上位でのセキュリティソリューションを提供することが望ましい。
【００１１】
また、有用なストリームリソースを無駄にすることなく、必要とされるセキュリティを提供することが望ましい。
【００１２】
特別な目的は、データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに対するデータセキュリティを提供する方法及びシステムを提供することである。
【００１３】
本発明の別の目的は、データの順序化配信及びデータの非順序化配信をサポートする信頼性のあるトランスポートプロトコルに基づいて動作するように構成されている受信機及び送信機を提供することである。
【００１４】
更なる目的は、そのようなトランスポートプロトコルとともに動作するように構成されているディスパッチャを提供することである。
【００１５】
これらの目的及び他の目的は、添付の特許請求の範囲によって定義される発明によって達成される。
【００１６】
本発明の基本概念は、信頼性のあるトランスポートプロトコルの上位で動作するセキュリティプロトコルで順序化配信データと非順序化配信データとを分離し、そのセキュリティプロトコルで、順序化配信データ用の第１タイプのセキュリティ処理と、非順序化配信データ用の第２タイプのセキュリティ処理を実行することである。好ましくは、セキュアデータストリーム内の順序化配信を使用するデータメッセージと非順序化配信を使用するデータメッセージは、セキュリティプロトコルレイヤ上で２つのメッセージシーケンス空間に分離され、データセキュリティ処理が、２つのメッセージシーケンス空間で別々に実行される。
【００１７】
本発明は、特に、ＳＣＴＰ（ストリーム制御送信プロトコル）のような信頼性のあるトランスポートプロトコルに対して適している。このトランスポートプロトコルの上位で動作するセキュリティプロトコルは、ＴＬＳ（トランスポートレイヤセキュリティ）、あるいは非順序化配信用のセキュリティ処理拡張を有するＴＬＳのようなプロトコルに基づいていることが好ましい。しかしながら、セキュリティプロトコルとトランスポートプロトコルの他の組み合わせを用いることもができることが理解されるべきである。
【００１８】
非順序化メッセージの識別を可能にするために、非順序化メッセージに向けられている専用メッセージタイプを導入することは有効である。送信側では、新規のメッセージタイプのメッセージそれぞれは、非順序化メッセージに向けられている専用シーケンス番号空間から明確なシーケンス番号が割り当てられることが好ましい。受信側では、非順序化配信メッセージ用のセキュリティ処理は、通常は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づいている。
【００１９】
効率的な方法で、非順序化配信メッセージ用の再生保護を実行するために、受信されている非順序化メッセージの概念リスト、あるいは受信されていない非順序化メッセージのその概念リストの代替リストを保持することが有益である。
【００２０】
データ損失保護に対しては、セキュリティプロトコル接続の切断用の切断メッセージは、一般的には、送信済の非順序化配信メッセージの最終シーケンス番号を含んでいて、非順序化レコード空間内の送信済のすべてのレコードの信頼性のある受信は、切断メッセージの最終シーケンス番号に基づいて検出することができる。
【００２１】
本発明は、ＵＤＰ、ＤＣＣＰ及びＰＲ−ＳＣＴＰのような既存プロトコルと高い互換性があり、かつ完全に動作可能である。
【００２２】
本発明は、以下の効果を提供する。
【００２３】
データセキュリティの改善
非順序化配信機能を使用するトランスポートレイヤの上位での耐性がありかつ有効なセキュリティソリューション
有用なストリームリソースの効率的な利用を伴うデータセキュリティ
既存のトランスポートプロトコルとの高い互換性
本発明によって提供される他の効果は、以下の本発明の実施形態の説明を読むことによって理解されるであろう。
【００２４】
実施形態の詳細説明
図面全体を通して、同一の参照文字は、対応するあるいは同様の要素のために使用するものである。
【００２５】
特定の例示的な環境で、問題解析を開始することは有用であろう。非順序化配信機能を使用するＳＣＴＰアソシエーションは、ＡＨ及びＥＳＰによって保護することができる。しかしながら、ＡＨ及びＥＳＰはミドルボックス（例えば、ミドルボックスは、ＴＣＰパフォーマンス最適化、ヘッダ圧縮、アプリケーションゲートウェイの構築、ファイヤウォールの構築、ＮＡＴの実行等を行う）のようなデバイスとの互換性はない。これは、これらのミドルボックスが、トランスポートヘッダへアクセスあるいは操作することさえ必要とする場合があるからである。それゆえ、本発明は、ＳＣＴＰのようなプロトコルの非順序化配信機能を使用するデータ用トランスポートレイヤの上位におけるセキュリティソリューションの必要性を認識している。
【００２６】
ＴＬＳは、トランスポートレイヤの上位で動作するセキュリティプロトコルの例である。ＴＬＳは、本来、ＴＣＰ接続を介するデータを保護するために設計されている。ＴＬＳは、データストリームをセグメントに分割し、各セグメントに対して、暗号化及び認証を含むセキュリティ処理を実行し、その処理されたセグメントをデータレコードにカプセル化する。ＴＬＳでは、データチャンクあるいはデータメッセージは、通常、レコードとして参照される。従来のＴＬＳデータレコードのフォーマットが図４に示され、ここでは、レコードヘッダ、暗号化データ、及びＭＡＣ（メッセージ認証コード）を含んでいる。レコードヘッダは、通常は、レコードタイプフィールド、バージョン番号及びレコード長における情報を含んでいる。
【００２７】
ＴＬＳは、すべてのデータレコードが順番に到来するものと想定し、この想定に基づいてセキュリティ処理を実行する。それゆえ、データが順番に配信される場合に、ＴＬＳがＳＣＴＰをサポートするとしても、ＴＬＳは、非順序化配信を使用するデータを処理することができない。文献［７］では、ＳＣＴＰサービスの現在のＴＬＳサポートを示す図５で示されるように、ＳＣＴＰの非順序化配信機能はＴＬＳとともに使用されてはならないことが明確に記載されている。図５のプロトコルスタックでは、ＴＬＳはＳＣＴＰの非順序化配信に対して使用されないかわりに、ＳＣＴＰ順序化配信に対して使用されることが確認できる。
【００２８】
一般的には、本発明の基本概念は、図６のフロー図で示されるように、セキュリティプロトコルレイヤ上で、順序化配信用のデータメッセージと、非順序化配信用のデータメッセージを、２つのメッセージシーケンス空間に分離（Ｓ１）し、これらの２つの空間に異なるデータセキュリティ処理を実行する（Ｓ２）ことである。今日の従来技術のセキュリティプロトコル、例えば、ＴＬＳは、この識別を行うことができない。本発明の概念は、トランスポートレイヤの上位で、セキュリティプロトコルを設計／拡張し、そのセキュリティプロトコルレイヤで、順序化配信データと非順序化配信データとの分離を可能にし、そして、配信のタイプに依存して異なるタイプのセキュリティ処理を実行することである。
【００２９】
文献［８］は、ＤＴＬＳプロトコルを記載している。これは、実際には、非順序化配信を提供するものである。しかしながら、ＤＴＬＳでは、すべてのレコードは、明確なシーケンス番号を含んでいて、また、すべてのパケットが、そのシーケンス番号に基づく同一の方法でセキュリティ処理される。
【００３０】
本発明は、ＤＴＬＳとは区別されるものであり、本発明に従えば、順序化配信レコードと非順序化配信レコードが、２つ異なるレコードシーケンス空間に分離され、データセキュリティ処理が、順序化配信用と非順序化配信用とで別々に実行される。特に、本発明を用いると、シーケンス番号は、順不同のパケットに対してのみ挿入される。これに対して、ＤＴＬＳは、各レコードに対してそのような番号を挿入している。これによって、本発明のソリューションは、帯域幅を節約し、また、レガシーのＴＬＳとの互換性を持たせることができる。
【００３１】
更なる違いは、ＤＴＬＳが固定サイズの再生ウィンドウを提供するのに対し、本発明に従えば、別の方法が、順不同のレコードの追跡を維持するために使用され、この方法は、欠落しているシーケンス番号の間のサイズを考慮している。
【００３２】
本発明は、一般的には、信頼性のあるトランスポートプロトコルと、そのトランスポートレイヤの上位で動作するように設計されているセキュリティプロトコルとに適用可能である。但し、本発明は、特に、ＳＣＴＰ順序化配信用の基本セキュリティ処理とＳＣＴＰ非順序化配信用のセキュリティ処理拡張とを伴うＴＬＳ（トランスポートレイヤセキュリティ）に基づくセキュリティプロトコルと組み合わせた、ＳＣＴＰ（ストリーム制御送信プロトコル）に対して適している。このような状況では、このセキュリティ処理拡張の使用は、典型的には、セッションセットアップ中に、例えば、ハンドシェーク処理のような帯域内処理によってあるいは帯域外シグナリングによってネゴシエートされる。
【００３３】
送信側では、非順序化配信用のセキュリティ処理は、各非順序化データメッセージに、明確なシーケンス番号を、非順序化メッセージ専用のシーケンス番号空間から割り当てるように構成されていることが好ましい。受信側では、非順序化配信メッセージ用のセキュリティ処理は、通常は、非順序化配信メッセージによって搬送される明確なシーケンス番号の処理に基づくことになる。
【００３４】
以下では、本発明は、主に、特定のプロトコル例として、ＳＣＴＰとＴＬＳを参照して説明する。上述のように、本発明は、通常はこれに限定されるものではなく、他のセキュリティプロトコルとトランスポートプロトコルの組み合わせを用いることができることが理解されるべきである。
【００３５】
本発明の実施形態に従えば、図７に示されるように、セキュアストリーム内の順序化配信レコードと非順序化配信レコードとを２つのレコードシーケンス空間に分離し、これらの２つの異なる空間でデータセキュリティ処理を実行する。図７は、本発明の実施形態に従う、非順序化配信レコードに対するシーケンス空間の例を示している。非順序化配信シーケンス空間内には、対応するパケットに明示的に含まれるシーケンス番号だけとなっている。順序化配信シーケンス空間は、単に、セキュリティプロトコルによって内部的に処理され、また、ここでは、順序化パケットに存在する明確なシーケンス番号は存在しない。シーケンス空間の分離は、非順序化配信レコードに対して追加のレコードタイプを導入することによって達成されることが好ましい。例えば、ＴＬＳは、レコードヘッダ内に「タイプ」フィールド（図４参照）を持っていて、これは、異なるレコードタイプ（例えば、ハンドシェークメッセージ、アラートメッセージ及びアプリケーションデータ）を識別するために使用される。本発明に従えば、このフィールドは、レコードが非順序化レコードであることを特定するために使用することもできる（ここでは、すべての既存のタイプの非順序化バージョンとすることができる、あるいは完全に異なるものを定義することができる）。非順序化レコードの処理は、例えば、ＴＬＳのようなセキュリティプロトコルの拡張として実現することができ、また、この拡張の使用は、（ＴＬＳ）ハンドシェーク（順序化配信シーケンス空間で実行される）中の帯域内でネゴシエートを行うことで、レガシーの（ＴＬＳ）実装との後方互換性を持たせることができる。レガシーの（ＴＬＳ）実装が未知のレコードタイプに直面する場合、接続は切断されることになる。これは、レガシー（ＴＬＳ）実装は、新規のタイプのレコードを取得する場合には、簡単にクラッシュしないことを意味している。選択的には、非順序化配信レコード用のセキュリティ処理拡張の使用は、帯域外シグナリング（例えば、ＳＩＰシグナリング）によってネゴシエートされても良い。
【００３６】
このようなソリューションの可能なデータフロー例を、特に、ＴＬＳ及びＳＣＴＰを参照する図９に示す。送信側１００では、アプリケーション（Ｓ１１）がデータのチャンクをＴＬＳへ送信する場合（Ｓ１２）、配信のタイプ（即ち、順序化配信あるいは非順序化配信）を特定しないければならない。例えば、専用フラグ（０／１）がアプリケーションによって、例えば、順序化配信に対しては「０」、また、非順序化配信に対しては「１」を設定することができる。ＴＬＳ実装では、ディスパッチャが拡張されることが好ましい。ディスパッチャは、配信のタイプを識別し（Ｓ１３）、そして、アプリケーションによって特定される配信のタイプに従って、データをレガシーのＴＬＳプロトコルスタックへディスパッチする（Ｓ１４）、あるいはＳＣＴＰ非順序化配信用のＴＬＳ拡張へディスパッチする（Ｓ１５）。非順序化配信に対しては（Ｓ１５）、各レコードには、シーケンス番号（ＳＱＮ）アサイナーによって明確なシーケンス番号が割り当てられることが好ましい。各レコードは、続いて、受信機へ送信される（Ｓ１６）。
【００３７】
受信側２００では、ＴＬＳが、ＳＣＴＰの受信機能からＳＣＴＰメッセージを受信する場合（Ｓ１７）、レコードヘッダのタイプフィールドに従って、レコードのディスパッチャ（Ｓ１８）は、データレコードを、レガシーのＴＬＳプロトコルスタックへディスパッチする（Ｓ１９）、あるいはＳＣＴＰ非順序化配信用のＴＬＳ拡張へディスパッチする（Ｓ２０）。非順序化配信レコード（Ｓ２０）に対しては、シーケンス番号は、ＳＱＮ抽出部によって抽出され、セキュリティ処理がＳＱＮセキュリティ処理モジュールによって実行される。このＳＱＮ処理モジュールは、例えば、再生保護、完全性保護及びデータ損失保護の少なくとも１つを含むセキュリティ機能を含んでいることが好ましい。続いて、レコードがアプリケーションへ与えられる（Ｓ２１）。
【００３８】
順序化配信シーケンス空間では、データレコードは、それらが送信される順序と同一の順序で到来するので、そのデータレコードは、明確なシーケンス番号スキームを使用する通常のＴＬＳ接続によって適切に処理することができる。
【００３９】
ＳＣＴＰ非順序化配信用のＴＬＳ拡張を参照すると、レコード到来は、通常は、信頼性がある。しかしながら、非順序化レコードについては、それらが送信される順序と同一の順序で到来する必要はない。非順序化配信レコードに対して完全保護を実行するためには、ＴＬＳレコードのフォーマットは変更されるべきであり、そうすることで、これは、明確なシーケンス番号を含められる（これは、レコード単位でシーケンス番号が単調増加する順序化配信シーケンスと比較して、ここでは、そのシーケンス番号は、通信エンドポイントで確認可能な状態で維持することができる）。２つのタイプのレコードのヘッダ間で要求される違いは、非順序化レコードは、明示的なシーケンス番号を搬送することである。
【００４０】
再生保護は、再生保護チェックを実行するために受け入れられている処理を使用して、シーケンス番号情報に基づいて実行されることが好ましい。単純なサービス拒否攻撃を回避するために、好ましくは、再生保護情報に完全性保護が含められるべきである。ＭＡＣ（図８参照）がシーケンス番号を介して算出される場合、通常キー化ＭＡＣ検証（ordinary keyed MAC verification）を使用することによって、この情報に対する完全性保護がなされる。攻撃者がシーケンス番号（再生保護情報）を変更する場合、ＭＡＣを検証することはできないが、プロトコルは適切な動作を行うことになる。
【００４１】
非順序化シーケンス内のシーケンス番号間のギャップは大きいので、固定サイズの再生ウィンドウ（例、ＥＳＰ）を維持することは実現不可能な場合がある。概念リストに代えて、例えば、リンク化リストの形式では、受信レコードにギャップを含めることで、より効果的なメモリ利用を維持することができる。この概念リストは、信頼性のある再生保護を実行するために使用される。再生保護実装を使用すべきかの決定は、例えば、ストリーム内の非順序化レコードと順序化レコードの分布に依存して行うことができる。この決定は、この分布の事前知識に基づくことが好ましく、これは、アプリケーション行動の知識から推定することができる。
【００４２】
図１０は、本発明の実施形態に従って、受信しているレコードの間隔のリストを受信機がどのようにして維持しているかを示している（ペア（対）の１つ目の番号は、間隔の下限を示していて、ペアの２つ目の番号は間隔の上限を示している）。また、それらが完了する場合に、その間隔をどのようにしてマージすることができるかを示している（レコード３とレコード２が到達する場合になにが発生しているかがわかる）。換言すれば、図１０は、どのレコードが確認されるかの経過を受信機が追跡する、非順序化配信に対する再生リストの例を示している。
【００４３】
別の構成は、受信機が受信していないレコードのリストを保持することである。これは、受信機がどのレコードをまだ確認していないかを示す、再生リストの例を示す図１１で示される。図１１では、ＩＮＦは、概念的な無限大、あるいは最大許容シーケンス番号を示している。最大シーケンス番号は、モジューロ方法で説明することができる。例えば、シーケンス番号が０ｘｆｆｆｅで開始し、かつシーケンス番号フィールドが１６ビット幅である場合、「最大」シーケンス番号は、例えば、０ｘｆｆｆｄ、即ち、モジューロ２＾１６周辺の数となる。
【００４４】
データ損失保護に対して、セキュリティプロトコル接続の切断用の切断メッセージは、一般的には、送信する非順序化データメッセージの最終シーケンス番号を含んでいて、また、非順序化レコード空間で送信されるすべてのレコードの信頼性のある受信は、その切断メッセージの最終シーケンス番号に基づいて検出することができる。このシーケンス番号のセットは、一般的には順序化セット（順序付けされたセット）であり、また、この最終シーケンス番号は、その順序における「最大」要素であることが理解されるべきである。
【００４５】
ＴＬＳでは、切断メッセージは、典型的には、終了アラートメッセージとして参照される。「ＴＬＳ」コンテキストにおいてデータ損失の検出を実行するために、「ＴＬＳ」接続が終了される直前に、各通信エンドポイントから送信される終了アラートメッセージは、図１２に示されるように、送信された非順序化配信メッセージの「最大」シーケンス番号を含んでいるべきである。ここで、図１２は、非順序化空間の最大シーケンス番号を含む順序化空間で、終了アラートメッセージを送信する例を示している。これは、エンドポイントに到達していない非順序化パケットが存在しないことを確認させることを、エンドポイントに対して要求される。例えば、エンドポイントＡが、エンドポイントＢ（図の５）によって送信される最大非順序化シーケンス番号を含む終了アラートを受信する場合、これは、非順序化シーケンスで１から５へすべてのレコードを受信するまで、接続を切断すべきでないことを知ることになる。
【００４６】
図１３は、本発明の実施形態に従う、受信機の関連部分を示すブロック図である。この例では、受信機２００は、基本的には、メッセージ受信部２１０、ディスパッチャ２２０、順序化配信保護用モジュール２３０、非順序化配信保護用モジュール２４０及びアプリケーションモジュール２５０を備えている。メッセージ受信部２１０は、ＳＣＴＰのようなトランスポートプロトコルのメッセージ受信機能を含み、また、データメッセージあるいはレコードのバッファリングを可能にする。メッセージ受信部は、メッセージタイプをチェックするディスパッチャ２２０へデータメッセージを転送する。ディスパッチャは、好ましくは、データメッセージのヘッダのタイプフィールドに従って、データメッセージを、順序化配信（非）保護用モジュール２３０あるいは非順序化配信（非）保護用モジュール２４０へディスパッチする。例えば、順序化配信モジュール２３０は、レガシーのＴＬＳプロトコルスタックを実現することができ、また、非順序化配信モジュール２４０は、非順序化配信のためのＴＬＳ拡張を実現することができる。好ましくは、モジュール２４０は、シーケンス番号抽出部２４２、完全性チェッカ２４４（例えば、ＭＡＣ検証）、再生チェック２４６及び関係再生リスト記憶部２４８を含んでいる。データメッセージが一旦処理されると、それらは、アプリケーション２５０へ転送される。
【００４７】
まとめると、トランスポートプロトコルの状態は、非順序化配信と順序化配信とに分離される。しかしながら、今日の現在のセキュリティプロトコルは、この分離を実行することができない。それゆえ、本発明の基本概念は、図１４に示されるように、セキュリティプロトコルを拡張して、この分離を上位レイヤでも可能にすることである。図１４は、ＴＬＳセキュリティプロトコルとＳＣＴＰトランスポートプロトコルの組み合わせ例に対して、セキュリティプロトコルとトランスポートプロトコルの両方での順序化配信と非順序化配信との分離を示している。重要な点は、セキュリティプロトコルレイヤへアクセスするために１つ以上のエントリポイントが使用されるかどうかに関わらず、順序化配信を使用するデータメッセージと、非順序化配信を使用するデータメッセージとを別々に処理することである。これは、２つの異なるメッセージタイプが、少なくともセキュリティ処理中に、セキュリティプロトコルレイヤ上で分離されなければならない、あるいは分離が維持されなければならないことを示すものである。また、セキュリティプロトコルと信頼性のあるトランスポートプロトコルの他の組み合わせを用いることができることは容易に理解される。
【００４８】
非順序化配信に対するＴＬＳ拡張ようなセキュリティプロトコル拡張と、レガシーのＴＬＳのような対応するレガシーセキュリティプロトコル間の違いは、非順序化配信用のセキュリティプロトコル拡張（図９及び図１４参照）が、非順序化配信を取り扱うために必要とされるセキュリティ処理を実行することである。例示のように、セキュリティプロトコル拡張は、以下のように、
・レコードで搬送される明確なシーケンス番号を処理し、
・このシーケンス番号に基づいて再生保護を実行する（潜在的には、例えば、レガシーのＴＬＳにおけるスキームとは異なる、ハンドシェーク中にスキームを決定することができるスキームを使用して）
ように構成されることが好ましい。
【００４９】
上述の実施形態は単なる例示であり、本発明がそれに限定されるべきものでないことが理解されるべきである。本明細書で開示され、かつ定義される原理の基礎となる構成を維持する、更なる変形、変更及び改善は、本発明の範囲内である。
【００５０】
文献
［１］アール．スチュアート等、「ストリーム制御送信プロトコル」、ＲＦＣ２９６０、ＩＥＴＦ、２０００年１０月
［２］ジェイ．ローゼンバルグ等、「トランスポート用セッション開始プロトコル（ＳＩＰ）としてのストリーム制御送信プロトコル（ＳＣＴＰ）」、インターネット草稿、ＩＥＴＦ、２００５年１月
［３］３ＧＰＰ  ＴＳ．３３．２２０：「汎用認証アーキテクチャ（ＧＡＡ）；汎用ブートストラップアーキテクチャ（リリース６）」、２００４年７月
［４］エス．ケント及びアール．アトキンソン、「ＩＰ認証ヘッダ」、ＲＦＣ２４０２、ＩＥＴＦ、１９９８年１１月
［５］エス．ケント及びアール．アトキンソン、「ＩＰカプセル化セキュリティペイロード（ＥＳＰ）」、ＲＦＣ２４０６、ＩＥＴＦ、１９９８年１１月
［６］ティー．ディレクス及びシー．アレン、「ＴＬＳプロトコル−バージョン１．０」、ＲＦＣ２２４６、ＩＥＴＦ、１９９９年１月
［７］エイ．ジュンマイヤ等、「トランスポートレイヤセキュリティオーバストリーム制御送信プロトコル」、ＲＦＣ３４３６、ＩＥＴＦ、２００２年１２月
［８］イー．レスコラ、エヌ．モダドゥグ、「データグラムトランスポートレイヤセキュリティ」、インターネット草稿、２００４年６月
【図面の簡単な説明】
【００５１】
【図１】ＳＣＴＰ非順序化配信を示す図である。
【図２】トランスポートプロトコルとしてＳＣＴＰを使用して、シグナリングメッセージを交換するＳＩＰプロキシを示す図である。
【図３】ＤＩＡＭＥＴＥＲサーバを使用する場合の典型的な認証を示す図である。
【図４】従来のＴＬＳデータレコードのフォーマットを示す図である。
【図５】従来技術のＳＣＴＰサービスのＴＬＳサポートを示す図である。
【図６】本発明の実施形態に従う信頼性のあるトランスポートプロトコル用のデータセキュリティを改善する方法のフロー図である。
【図７】本発明の実施形態に従う非順序化配信レコード用のシーケンス空間の例を示す図である。
【図８】本発明の実施形態に従う（ＳＣＴＰ）非順序化配信用の新規のレコードヘッダの例を示す図である。
【図９】ＴＬＳとＳＣＴＰを参照する本発明の実施形態に従うデータフロー例を示す図である。
【図１０】本発明の実施形態に従う、受信しているレコードの間隔のリストを受信機がどのようにして保持するかを示す図である。
【図１１】本発明の実施形態に従う、受信機がどのレコードをまだ確認していないかを示す再生リストの例を示す図である。
【図１２】非順序化空間の最大シーケンス番号を含む順序化空間で、終了アラートメッセージを送信する例を示す図である。
【図１３】本発明の実施形態に従う受信機の関連部分を示すブロック図である。
【図１４】ＴＬＳセキュリティプロトコルとＳＣＴＰトランスポートプロトコルの組み合わせ例に対し、セキュリティプロトコルとトランスポートプロトコルの両方における、順序化配信と非順序化配信との分離を示す図である。
【図１】
2008535080.tif 000003
【図２】
2008535080.tif 000004
【図３】
2008535080.tif 000005
【図４】
2008535080.tif 000006
【図５】
2008535080.tif 000007
【図６】
2008535080.tif 000008
【図７】
2008535080.tif 000009
【図８】
2008535080.tif 000010
【図９】
2008535080.tif 000011
【図１０】
2008535080.tif 000012
【図１１】
2008535080.tif 000013
【図１２】
2008535080.tif 000014
【図１３】
2008535080.tif 000015
【図１４】
2008535080.tif 000016
【国際調査報告】
2008535080.tif 000017
2008535080.tif 000018