(57)【要約】【課題】ユーザ・データグラム・プロトコルなどの信頼性のない通信プロトコルを利用してデータを確実に送信するための方法および装置を提供する。【解決手段】この方法および装置により従来のセキュア・ソケット・レイヤ（ＳＳＬ）プロトコルおよびＳＯＣＫＳプロトコルとの互換性を維持し、従来のＳＯＣＫＳ処理と同様の方法により、プロキシサーバ２０２とクライアントコンピュータ２０１との間で確実なＵＤＰデータグラムを送信できる。ＴＣＰなどの保証配信サービスに依存し、以前に送信されたデータレコードを参照して連続的なデータレコードを暗号化する従来のＳＳＬ処理とは対照的に、暗号化は、各送信データレコードに埋め込まれたノンスを用いて実行される。このノンスは、レコードの暗号化／暗号解読のための初期化ベクトルおよび一意的な識別子としての役割を果たし、レコードの認証を行う。
2004529531.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータネットワークを介して確実にデータを送信する方法であって、
（１）  第１のコンピュータと第２のコンピュータとの間に通信経路を確立するステップと、
（２）  信頼性のない通信プロトコルを利用して、前記第１のコンピュータと前記第２のコンピュータとの間で、データレコードを暗号化して送信するステップであって、以前に送信されたデータレコードを参照することなく、各データレコードを暗号化するステップと、
（３）  前記第２のコンピュータにおいて、以前に受信されたデータレコードを参照することなく、前記ステップ（２）で送信された前記データレコードを受信して暗号解読するステップとを含む方法。
【請求項２】
前記ステップ（１）の前に、前記第１のコンピュータと前記第２のコンピュータとの間に信頼性のある通信経路を確立し、前記信頼性のある通信経路を介してセキュリティ信任情報を交換するステップを更に含む請求項１の方法。
【請求項３】
前記セキュリティ信任情報を交換するステップが、前記ステップ（２）において前記データレコードの暗号化に使用された暗号化キーを交換するステップを含む請求項２の方法。
【請求項４】
前記ステップ（２）が、前記ステップ（３）において前記各データレコードを暗号解読するために、前記第２のコンピュータが以前の共有暗号化キーと共に使用するノンスを、各データレコードに組み込むステップを含む請求項１の方法。
【請求項５】
前記ノンスが、ランダム数を含む請求項４の方法。
【請求項６】
前記第２のコンピュータにおいて、以前に送信されたデータレコード内に、前記ノンスが前もって受信されていないことを確認するステップを更に含む請求項４の方法。
【請求項７】
前記ステップ（２）が、以前に送信されたデータレコードを参照せずにレコードを暗号化する暗号化方式に従って、前記データレコードが暗号化されたことを示す指標を前記各データレコード内に埋め込むステップを含み、
前記ステップ（３）が、各レコードに前記指標が存在するか否かを決定し、前記指標が存在しないことの決定に応答して、前記指標が設定されている場合とは異なる方法で、各レコードを処理するステップを含む請求項１の方法。
【請求項８】
前記ステップ（１）が、トランスミッション・コントロール・プロトコルを利用して実行され、前記ステップ（２）が、ユーザ・データグラム・プロトコルを利用して実行される請求項１の方法。
【請求項９】
前記ステップ（２）が、別のサーバから受信されたデータレコードを暗号化するプロキシサーバにより実行される請求項１の方法。
【請求項１０】
信頼性のない通信プロトコルを利用して、クライアントコンピュータとプロキシサーバとの間で複数のデータレコードを確実に送信する方法であって、
（１）  前記クライアントコンピュータと前記プロキシサーバとの間に信頼性のある接続を確立するステップと、
（２）  前記信頼性のある接続を介して前記クライアントコンピュータと前記プロキシサーバとの間で暗号化信任情報を交換するステップと、
（３）  複数のデータレコードのそれぞれのためにノンスを生成するステップであって、各ノンスが、前記複数のデータレコードの内の対応する１つを暗号解読するために必要な初期化ベクトルを含むステップと、
（４）  前記ノンスを用いて、前記複数のデータレコードのそれぞれを暗号化し、前記複数のデータレコードのそれぞれに前記ノンスを付加するステップと、
（５）  信頼性のない通信プロトコルを利用して、前記ステップ（４）において暗号化された前記複数のデータレコードを、前記クライアントコンピュータから前記プロキシサーバに送信するステップと、
（６）  前記プロキシサーバにおいて、各データレコードから抽出された対応するノンスと、以前に共有された暗号化キーとを用いて、前記複数の暗号化データレコードのそれぞれを暗号解読するステップとを含む方法。
【請求項１１】
前記ステップ（６）が、信頼性のない確実な送信フォーマットに従って、前記クライアントコンピュータから受信された各データレコードがフォーマットされているか否かを決定するためにチェックし、ある特定のレコードが信頼性のない確実な送信フォーマットに従ってフォーマットされていない場合には、前記対応するノンスを用いた前記暗号解読を回避するステップを含む請求項１０の方法。
【請求項１２】
前記ステップ（３）が、ランダム数を各ノンスとして生成するステップを含む請求項１０の方法。
【請求項１３】
前記ステップ（１）が、トランスミッション・コントロール・プロトコルを利用して実行され、前記ステップ（５）が、ユーザ・データグラム・プロトコルを利用して実行される請求項１０の方法。
【請求項１４】
前記ステップ（６）が、信頼性のある通信プロトコルを利用して以前に共有された暗号化キーを用いて実行される請求項１０の方法。
【請求項１５】
前記信頼性のある通信プロトコルが、トランスミッション・コントロール・プロトコルである請求項１４の方法。
【請求項１６】
信頼性のないプロトコルを利用して確実にデータを送信するシステムであって、
信頼性のないプロトコルを利用してデータレコードを確実に送信するために、アプリケーションプログラムと共に動作可能な通信プロトコルクライアント機能を備えた第１のコンピュータと、
前記第１のコンピュータと連結され、前記信頼性のない通信プロトコルを利用して確実にデータレコードを受信するために、前記通信プロトコルクライアント機能と共に動作可能な通信プロトコルサーバ機能を備えた第２のコンピュータとを備え、
前記通信プロトコルクライアント機能が、ノンスおよび暗号化キーを用いて各データレコードを暗号化し、前記暗号化データレコードのそれぞれに前記ノンスを付加し、
前記通信プロトコルサーバ機能が、前記付加されたノンスおよび前記暗号化キーを用いてデータレコードのそれぞれを暗号解読するシステム。
【請求項１７】
前記通信プロトコルクライアント機能が、信頼性のある通信プロトコルを利用して、前記通信プロトコルサーバ機能と暗号化信任情報を交換する請求項１６のシステム。
【請求項１８】
前記信頼性のない通信プロトコルが、ユーザ・データグラム・プロトコルを含み、前記信頼性のある通信プロトコルが、トランスミッション・コントロール・プロトコルを含む請求項１７のシステム。
【請求項１９】
前記通信プロトコルクライアント機能および前記通信プロトコルサーバ機能が、ＳＯＣＫＳ通信プロトコルと互換性がある請求項１６のシステム。
【請求項２０】
前記通信プロトコルクライアント機能および前記通信プロトコルサーバ機能が、ＳＳＬ／ＴＬＳ通信プロトコルと互換性がある請求項１６のシステム。
【請求項２１】
前記第２のコンピュータが、前記第１のコンピュータから受信された暗号化レコードをサーバコンピュータに転送するプロキシサーバを含む請求項１６のシステム。
【請求項２２】
前記第２のコンピュータが、前記第１のコンピュータから受信された各データレコードに指標が設定されているか否かを決定するレコード検出器を備え、前記指標が設定されていなければ、前記サーバコンピュータでの暗号解読を回避する請求項１６のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、データ送信方式およびプロトコルに関する。特に、本発明は、ユーザ・データグラム・プロトコル（ＵＤＰ）などの信頼性のないプロトコルを利用して、２つ以上のコンピュータノード間で確実にデータを送信するための方法および装置を提供する。
【背景技術】
【０００２】
周知のトランスミッション・コントロール・プロトコル／インタネット・プロトコル（ＴＣＰ／ＩＰ）は、コンピュータ間でデータパケットを送信するために長年使用されてきた。ＴＣＰは、データパケットの保証配信／配列方式を提供し、ＴＣＰを使用する２以上のコンピュータは、このプロトコルに依存して、任意のパケットが、送信された順序でその宛先に到達することを保証する。インタネット・プロトコル（ＩＰ）は、一般的に、保証配信なしにポイント間パケット送信サービスを提供する。図１Ａは、従来のプロトコルスタックに従ってＴＣＰ／ＩＰ上にアプリケーションプログラムを積み上げる方法を示す。一般的なハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）は、ウェブページの取出しおよび表示のために、クライアントのブラウザとサーバコンピュータとの間のＴＣＰ接続の存在に依存している。
【０００３】
ＴＣＰは、内蔵メカニズムを利用して保証配信機能を提供する（すなわち、各アプリケーションは、信頼性の詳細に関わる必要がない）が、ＴＣＰの使用の欠点は、データストリームを送信するときに遅延などの副作用を招く可能性があることである。例えば、２つのコンピュータが、ＴＣＰを使用してパケット化されたビデオストリームを送信すると、パケットを受信パケットストリームへと再配列する前に、喪失または脱落したパケットを再送信しなければならないので、受信パケットが「ギクシャク」して見える。結果的に、ＴＣＰは、ビデオ会議アプリケーションなどのデータストリーミングにとって良い候補とはならない。
【０００４】
周知のユーザ・データグラム・プロトコル（ＵＤＰ）は、２つのコンピュータ間で通信するためのパケット志向型の送信サービスを提供する。ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰを使用して送信されたパケットは、宛先のコンピュータに到達することが保証されない。さらに、特定の順序で送信されたパケットが、宛先のコンピュータに順不同で到達する場合もある。したがって、ＵＤＰは、「信頼性のない」転送プロトコルと称されている。しかし、ＴＣＰなどの保証配信プロトコルとは対照的に、ＵＤＰは、時間重視の配信方式を提供し、ビデオデータなどのストリーミングメディアにとってより好適である。
【０００５】
ビデオ会議などのアプリケーションにより、ストリーミングメディアの重要性が高まり、確実なストリーミング送信機能を提供する必要性がある。例えば、数多くの企業において、本社設備と１以上の遠隔地オフィスとの間でストリーミングビデオを送信する必要性がある。送信には、会社が意図しない受信者や盗聴から保護する必要のある機密情報が含まれている場合がある。ＴＣＰもＵＤＰもこの様なセキュリティを提供しないので、この様な送信には不十分である。
【０００６】
近年、保証配信プロトコルを暗号手法で強化することによって確実な送信機能を提供するために、様々な試みがなされてきた。例えば、セキュア・ソケット・レイヤ（ＳＳＬ）は、２つの装置間の確実なチャネルを提供するプロトコルである。この様な確実なチャネルは、透過性があり（トランスペアレントであり）、かつ、クライアントとサーバとの間で暗号化され、ＴＣＰ上で実行可能な殆ど全てのプロトコルが、最小限の修正によりＳＳＬ上で実行可能となっている。確かに、ＳＳＬ／ＴＬＳセキュリティおよび障害検出は、ＴＣＰ（または同様の保証配信プロトコル）に依存して、パケットの配列と保証配信とを行っている。様々な修正を経て、ＳＳＬは、トランスポート・レイヤ・セキュリティ（ＴＬＳ）と改名され、ＲＦＣ２２４６に反映されているように、インタネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）に採用されている。（ＳＳＬ／ＴＬＳという用語は、これら２つの緊密に関係するプロトコルを一括して称するために使用される。）ＳＳＬ／ＴＬＳの主なアプリケーションは、オンラインショッピングであり、オンラインショッピングでは、消費者は、ＨＴＴＰプロトコルやウェブブラウザを安全に利用してクレジットカード機密情報を送信する。
【０００７】
大抵のインタネットプロトコルはＴＣＰ接続上で動作するので、ＳＳＬ／ＴＬＳは、２つ以上のコンピュータ間で確実にデータを送信する便利な方式を提供する。図１Ｂは、アプリケーションが、ＳＳＬ／ＴＬＳを使用してＴＣＰなどの信頼性のある接続上で確実なデータを送信する方法を構造的に示している。従来どおり、ＳＳＬ／ＴＬＳを利用して確実にデータを送信するステップは、一般的に以下のステップを含んでいる。
（１）  クライアントが、サーバコンピュータとのＴＣＰ接続を確立する。
（２）  クライアントおよびサーバが、ＳＳＬ／ＴＬＳプロトコルを使用して、信任情報（ＳＳＬ／ＴＬＳハンドシェイク、プロトコルメカニズムの取り決め、接続毎のキーの確立などを含む）を交換する。
（３）  各ＨＴＴＰ要求（例えば、ＧＥＴ）が、暗号内容を有するＳＳＬ／ＴＬＳレコードに変換される。
【０００８】
図１Ｃは、サンプルのＳＳＬ／ＴＬＳレコードを示し、これは、ヘッダ（ＨＤＲ）と、暗号化データまたは暗号テキストと、ＭＡＣ（メッセージ認証チェック）とを含んでいる。ＭＡＣは、強力なチェックサムと同様のキー付きハッシュによりメッセージの完全性を保証し、一般的に、関数ＭＡＣ＝ｈ（キー，プレインテキスト，連番）として演算される。ここで、連番は、連続レコード用の１増分カウンターである。連番は、ハッカーがＴＬＳ使用のコンピュータ間の確実な通信を暗号解読または破壊しようとしてパケットの傍受や再配列を試みた場合に発生するいわゆる「スプライシング攻撃」を防止するので、ＴＬＳにより演算されたＭＡＣの重要な側面を構成する。受信側ＴＬＳが受信レコードに不正確な連番を検出した場合、故意の侵害としてそのレコードを拒絶し、接続を終了する。これにより、送信側および受信側は、別のＴＣＰ接続を再確立しなければならず、結果的に時間およびリソースの浪費となる。
【０００９】
透過性のある性質上、ＴＣＰベースのプロトコル（例えば、ＨＴＴＰ、ＦＴＰなど）あるいは同様の保証配信プロトコルは、ＴＬＳ上で動作可能である。ＳＳＬおよびＴＬＳの更なる詳細については、下記非特許文献１に記載されている。
しかし、ＴＣＰなどの保証配信プロトコルに依存することにより、ＳＳＬ／ＴＬＳは、ＴＣＰと同様の性能問題の影響を受けやすい。例えば、ＳＳＬ／ＴＬＳを用いてストリーミングビデオデータを送信すると、その基礎となっているＴＣＰと同様の犠牲および不利益を招く（例えば、「ギクシャク」したビデオとなることがある）。ＳＳＬ／ＴＬＳは、パケットが脱落したり順不同に受信された場合に接続を終了するので、その性質上、ＴＣＰにより提供されるような信頼性のある接続の利用が必要である。
【００１０】
近年、プライベート・コミュニケーション・テクノロジー（ＰＣＴ）として知られているプロトコルが提案されているが、商業的な成功を収めていない。ＰＣＴは、（いわゆる「ストリーム暗号」を用いた）確実なデータグラムトラフィックへとＳＳＬを拡張する試みである。例えば、ＰＣＴは、ＳＳＬ（５バイト、１レコードタイプ、２バージョン番号、２レングス）とは異なるヘッダフォーマット（４バイト、２レングス、２レコードタイプ）を使用していた。また、ハンドシェークメッセージ本体には、異なる開始フォーマットが含まれていた。すなわち、ＳＳＬは、１バイト（ハンドシェークタイプ）しか使用しないが、ＰＣＴは、４バイト（２ハンドシェークタイプ、２レコードフラグ）を使用している。ＰＣＴデータグラムサポートは、以下のフォーマットを使用している。
【００１１】
2 bytes of key_length
(key_length) bytes of key data
(data_length) bytes of encrypted data
(mac_length) bytes of MAC data
一方、ＳＳＬのデータグラムサポートは以下のようなフォーマットである。
【００１２】
(data_length) bytes of encrypted data
(mac_length) bytes of MAC
(padding_length) bytes of padding
1 byte of padding_length
(nonce_length) bytes of nonce
ＰＣＴは、各データグラムが、ENCRYPTED_KEY_1_DATA（DK_ENCRYPTED_KEY_DATAの一部である各レコードにランダム値が割り当てられる）によりマスタキーをハッシュすることによって生成された新たな暗号化キーを有するメカニズムを指定する。
【００１３】
提案されたＰＣＴメカニズムは、様々な性能的な犠牲を強いる。例えば、ＰＣＴメカニズムは、ストリーム暗号と共に使用可能であるが、各レコードを処理するための更なるハッシュとキースケジュール生成とにより、処理速度がかなり遅くなる。すなわち、データグラム毎に異なるキーを使用するので、演算上の犠牲が大きい。キースケジュール設定は、ブロック暗号にとって高価である。さらに、ＰＣＴは、ＳＯＣＫＳなどのマルチプロトコルプロキシとの総合メカニズムを提供していなかった。
【００１４】
従来、ＵＤＰが確実な通信には不適切であるといわれてきた。例えば、下記非特許文献１のレスコーラの著書は、特に、「ＵＤＰは、（信頼性のある伝送を提供しないので）レコードの喪失や再配列が自由に起こり、まるでＳＳＬに対する積極的な攻撃のようであるので、ＳＳＬをＵＤＰ上でうまく実行することができない。」と記述している。結局、先行技術は、確実なデータ送信のためにＳＳＬと共にＵＤＰを使用することを避けるように提言している。それでも、ＵＤＰは、数々のストリーミングメディアアプリケーションにとって適合性が良く、時折発生するデータパケットの脱落を許容するが、ＴＣＰで発生する遅延を許容することはない。例えば、リアルタイムで放映されるビデオ会議は、時折失われるビデオフレームを許容するが、失われたパケットの再送信や再配列のときに発生する「ギクシャクした動き」を許容しない。さらに、標準ＳＳＬ上で送られる標準ＵＤＰでは、ユーザセッションの終了が頻繁に起こる。
【００１５】
プロトコルの中には、ビデオまたはオーディオストリーミングなどの高性能データを送信するために、ＴＣＰおよびＵＤＰの両方に依存するものもある。例えば、ＲＥＡＬＡＵＤＩＯは、ＴＣＰおよびＵＤＰの両方を使用していると考えられており、ＴＣＰを使用して信号発信（例えば、開始／停止）を行う一方、ＵＤＰを使用してストリーミング内容のデータパケットを送信するようになっている。しかし、ＵＤＰデータグラムは、自由に送信されるので、傍受や攻撃を受けやすい。
【００１６】
ＫＥＲＢＥＲＯＳとして知られているプロトコルは、主にアカデミックサークルで使用されているが、ＵＤＰデータグラムの暗号化によりセキュリティを提供する。ＫＥＲＢＥＲＯＳがデータグラムセキュリティ提供のために使用するメカニズムは、ＲＦＣ１９６４に記載されている。しかし、これは、ＳＳＬ／ＴＬＳプロトコルと互換性がないので、広く普及していない。ＫＥＲＢＥＲＯＳが商業的な成功を収めていない主要な理由の１つに、動作が複雑で、ネットワーク処理に広く使用できるほど合理化されていないことが挙げられる。特に、ネットワークベースのセキュリティソフトウェアは、ユーザのアクセスの制御と保護のためにウェブサーバおよびプロキシサーバと効率よく相互動作しなければならない。一般的に、単純なプロトコルは、高速処理／分散システムに有利である。
【００１７】
また、ＫＥＲＢＥＲＯＳは、確実なＵＤＰ／ＴＣＰトラフィックを通信するために、別個の暗号化メカニズム、すなわち、キー確立ハンドシェイクを使用する。しかし、ＳＯＣＫＳなどのマルチプロトコルプロキシサーバ標準上で実行されるＳＳＬなどの単一標準セキュリティプロトコルの下でこれらを統合することによって、演算／ネットワークトラフィックのオーバヘッドを低減することが望ましい。さらに、ＫＥＲＢＥＲＯＳは、暗号化アルゴリズムを初期化する目的で、データレコードを従来の方法で拡張するために、パケット識別のためのランダムキーフィールドを追加している。しかし、ＫＥＲＢＥＲＯＳがデータレコード内に個別の連番を有するので、これにより、更なる演算／ネットワークトラフィックが必要となる。あるシステムにとっては、両方の目的を果たす単一のフィールドを有することが好適である。
【００１８】
ＵＤＰおよびＳＳＬは、ソフトウェア産業では標準となっている。ＵＤＰは、データグラム処理に使用され、ＳＳＬは、確実な通信を提供する。同時に、一般的なＳＯＣＫＳプロトコルを実行するものなど、マルチプロトコルプロキシサーバの採用は、システム内でＴＣＰやＵＤＰなどの産業用標準通信プロトコルを組み合わせる手段を提供する。ＵＤＰとＳＳＬとの互換性がないので、最近までこれは不可能であった。ＳＯＣＫＳなどの単一のプロキシサーバプロトコルの下でネットワーク通信を管理するために発生したこの問題と制約とを理解するためには、先ず、ＳＯＣＫＳの情報処理方法を理解する必要がある。
【００１９】
ＳＯＣＫＳプロトコルは、ファイアウォルなどの境界を設定するための一般的なプロキシプロトコルを提供する。ＩＥＴＦ  ＲＦＣ１９２８に記載されているこのプロトコルのバージョン５は、認証、ＵＤＰサポートなどの機能を提供する。図２は、プロキシサーバおよびＳＯＣＫＳプロトコルによりファイアウォルを介してサーバと接続するための従来の方策を示している。図２に示すように、クライアントコンピュータ２０１は、プロキシサーバ２０２を介してアプリケーションサーバ２０３と通信する。このシステムは、ネットワーク間のアプリケーションレイヤゲートウェイの役割を果たすファイアウォル（図示せず）を備えている場合もある。アプリケーションサーバ２０３は、通常、ＴＥＬＮＥＴ、ＦＴＰ、ＳＭＴＰ、ＨＴＴＰアクセスを提供する。クライアントコンピュータ２０１は、アプリケーション２０１Ａ（例えば、ウェブブラウザ）と、ＳＯＣＫＳクライアント２０１Ｂとを備えている。プロキシサーバ２０２は、ＳＯＣＫＳサーバ２０２Ａと、プロキシ機能２０２Ｂとを備えている。セキュリティ機能を提供するＳＯＣＫＳバージョン５によれば、クライアントアプリケーション２０１Ａは、以下のようにサーバ２０３からのサービスを得ることができる
先ず、クライアントアプリケーション２０１Ａは、サーバ２０３Ｂへの接続要求をする。次に、ＳＯＣＫＳクライアント２０１Ｂは、要求された接続を検出し、プロキシサーバ２０２を介してサーバ２０３との通信に対処すべきことを認識する。結果的に、ＳＯＣＫＳクライアント２０１Ｂは、ＴＣＰ接続を確立するためにＳＯＣＫＳサーバ２０２Ａに要求を送信する。プロキシ機能２０２Ｂは、サーバ２０３との接続を確立し、クライアントアプリケーション２０１Ａとサーバ機能２０３との間の以降の通信は、ＳＯＣＫＳサーバ２０２Ａおよびプロキシ機能２０２Ｂを介して行われる。従来と同様に、ＳＯＣＫＳは、クライアント２０１との確実な接続を確立するためにＳＳＬ／ＴＬＳを使用し、接続確立を許容する前にパスワードを要求する。図２のアーキテクチャは、１つのポイント（例えば、プロキシサーバ２０２）でサーバ機能２０３へのアクセスを制限し、ファイアウォルを貫通するような方法でサーバ２０３との通信負荷の一部を負担する。セキュリティを提供するためにＳＳＬ／ＴＬＳに依存しているので、図２の接続は、必ずＴＣＰ（または同様の保証配信プロトコル）に依存する。
【００２０】
図２のアーキテクチャは、不確実なＵＤＰデータグラムの送信のためにも利用可能である。この方式には、ポートを介して不確実なＵＤＰデータグラムを送信する一方、確実なＳＳＬ／ＴＬＳ／ＴＣＰ接続を介して確実なコマンドを送信するように、クライアント２０１とプロキシサーバ２０２との間のＵＤＰポート「接続」を取り決めることが含まれている。この様な方式は、ＵＤＰデータグラムが不確実であると言うことを反映して「無防備なＵＤＰ」モードと称されることもある。この手法を採用しているシステムは、数年にわたり、ワシントン、シアトルのアベンテイル社から市販されてきた。一般的に、ＳＯＣＫＳクライアント２０１Ｂは、クライアント２０１から送信される各レコードにＳＯＣＫＳヘッダを付与し、ＳＯＣＫＳヘッダは、サーバ２０３に送信される前にＳＯＣＫＳサーバ２０２Ａにより取り除かれる。
【００２１】
上述のように、ＳＳＬ／ＴＬＳは信頼性のある接続サービスを提供するためにＴＣＰに依存しているので、ＳＳＬ／ＴＬＳのコンテキストでＵＤＰデータグラムを確実に送信することは不可能である。しかし、図２の方式で確実なＵＤＰサービスを提供することは有利であり、データセキュリティを犠牲にすることなく、クライアント２０１とサーバ２０３との間の高性能ビデオストリーミングを円滑にできる。
【非特許文献１】
アディソン・ウェスレイ(Addison Wesley)発行、エリック・レスコーラ(Eric Rescorla)による著書「ＳＳＬとＴＬＳ：確実なシステムの設計と構築(SSL and TLS: Designing and Building Secure Systems)」ISBN0-201-61598-3
【発明の開示】
【発明が解決しようとする課題】
【００２２】
結局、課題は、好ましくは、ＳＳＬをセキュリティレイヤとして使用し、ＳＯＣＫＳをマルチプロトコルプロキシサーバとして使用して、プロキシサーバ２０２を介して確実なＴＣＰおよび確実なＵＤＰを実施するための方法を見出すことである。一般的には、ＴＣＰに対する依存によるオーバヘッドおよび不都合を招くことなく、ＳＳＬ／ＴＬＳ標準との互換性を維持する方法を見出すことが望まれる。
【００２３】
信頼性のある通信プロトコルに本質的に伴う不都合およびオーバヘッドを招くことなく確実なデータ送信機能を提供するための従来の試みの失敗を鑑み、確実なビデオ会議など、高帯域のアプリケーションをサポートするために、この様な機能を提供する必要性がある。さらに、ＳＳＬ／ＴＬＳとの互換性を維持しながら、確実なデータ送信サービスを提供する必要性がある。
【課題を解決するための手段】
【００２４】
本発明は、ＵＤＰなどの信頼性のないプロトコル上で暗号化データを送信するための方法および装置を提供することによって前述の問題を克服する。ある変形態様においては、特殊ビットがデータレコード内に設定され、プロキシサーバで受信されたときに、そのレコードは特殊な処理に回される。この特殊な処理には、繰り返しレコードの存在を検出するためのノンスの使用や、他のレコードのデータを参照することなくプロキシサーバにレコードを暗号解読させる初期化ベクトルの使用が含まれる。特殊なビットセットを有さないデータレコードは、従来のＳＳＬ／ＴＬＳ処理に従って処理される。
【発明を実施するための最良の形態】
【００２５】
図３Ａは、本発明の一つの変形態様に係る、送出方向の（例えば、クライアントからアプリケーションサーバへの）改良ＳＯＣＫＳプロトコルを用いたシステムを示す。図３Ａに示すように、クライアントコンピュータ３０１は、プロキシサーバ３０２を介してアプリケーションサーバ３０３と通信する。図２の従来のシステムと同様に、クライアントコンピュータは、ＳＯＣＫＳクライアント３０１Ｂと交信するクライアントアプリケーション３０１Ａを備えている。しかし、図２の従来のシステムとは対照的に、ＳＯＣＫＳ処理は、以下に詳述するように、図２のシステムとは異なる追加の機能を実行するように改良されている。アプリケーションサーバ３０３は、図２を参照して説明した方法と同じ方法で動作する。
【００２６】
図２のシステムとは対照的に、プロキシサーバ３０２は、２つのタイプのＳＯＣＫＳ処理機能、すなわち、従来のＳＯＣＫＳ処理機能３０２Ｂおよび改良ＳＯＣＫＳ処理機能３０２Ｃを備えている。レコード検出器３０２Ａは、ＳＯＣＫＳクライアント３０１Ｂからのサーバ向けのレコードを受信し、レコードが「確実なＵＤＰ」レコードであることを示す特定のビットが設定されているか否かにより、ソフトウェアスイッチを介して従来のＳＯＣＫＳ処理機能３０２Ｂまたは改良ＳＯＣＫＳ処理機能３０２Ｃにレコードをルーティングする。以下、改良ＳＯＣＫＳ処理機能３０２Ｃの詳細について説明する。
【００２７】
図３Ａに示すアーキテクチャによって、プロキシサーバ３０２は、図２のＳＯＣＫＳクライアント２０１Ｂなどの従来のＳＯＣＫＳクライアント、または、暗号化データの送信のためにＵＤＰなどの信頼性のないプロトコルを用いる本発明の原則に従って動作するように改良されたＳＯＣＫＳクライアント（改良ＳＯＣＫＳクライアント３０１Ｂ）と共に動作することができる。さらに、両タイプのクライアントを同時に収容することができる。ある実施形態において、ＵＤＰプロトコルおよびＴＣＰプロトコルは、同一のプロキシサーバ上で動作可能である。以下、改良処理を更に詳述する。プロキシ機能３０２Ｄは、図２のプロキシ機能２０２Ｂとほぼ同じ方法で動作する。
【００２８】
図３Ａのアーキテクチャに関して、本発明の原則の範囲内に属する数々の変形態様がある。１例として、レコード検出器３０２Ａは、任意とすることができる。また、別の例として、クライアント３０１およびプロキシサーバ３０２が、初期化シーケンス中に、ここに記載されている改良暗号化方式に従って以降の全てのＵＤＰデータグラムを両者間で送信することに同意すると、何れのプロトコルに準拠しているかを決定するために、各レコードにフラグを立てたり評価したりする必要はない。もちろん、他のフィールドによりレコードタイプを暗に指定して、レコードタイプ（そして、結果的な処理）が他のフィールドから明確となるようにすることも可能である。もちろん、「無防備なＵＤＰ」と同様に、確実なＵＤＰをサポートするキーやその他の暗号化レコードを含めるために、確実なＴＣＰメッセージを本発明と組み合わせることもできる。さらに、プロキシサーバ３０２の機能をサーバ３０３や他のコンピュータに組み込むことができ、これらの機能を実行するための別個のプロキシサーバは必要ない。結局、双方向の確実な通信経路が確立されるように、暗号化レコードをクライアントコンピュータ３０１からプロキシサーバ３０２へと、または、その逆に送信可能であることは明白である。
【００２９】
図３Ｂは、送入（サーバからクライアントへの）フロー方向に関する図３Ａのシステムを示す。プロキシ３０２Ｄを介して受信されるレコードは、ＳＯＣＫＳ処理機能３０２Ｅに転送され、クライアント側レコード検出器機能３０１Ｅに転送される。レコード検出器３０１Ｅは、確実なＵＤＰビットセットを有するレコードを検出すれば、それに応答して、この様なレコードを改良ＳＯＣＫＳ処理機能３０１Ｄへとルーティングし、そうでなければ、従来のＳＯＣＫＳ処理機能３０１Ｃに送信する。なお、本発明の原則から逸脱しない限り、クライアント３０１、プロキシサーバ３０２、または、別のコンピュータに様々なＳＯＣＫＳ処理機能を配置可能であると解釈される。
【００３０】
図４Ａは、暗号を使用するＳＳＬ／ＴＬＳレコードを生成するための従来の手法を示す。本発明の暗号化原理の適用方法を説明する前に、先ず、ＳＳＬ／ＴＬＳによる暗号化および暗号解読の実行方法について簡単に概説する必要がある。
図４Ａに示すように、従来のデータ・エンクリプション・スタンダード（ＤＥＳ）などの暗号化機能４０４を使用して、プレインテキスト４０１の最初のバイトを暗号化する。送信側および受信側（例えば、ＳＯＣＫＳクライアント２０１ＢおよびＳＯＣＫＳサーバ２０２Ａ）で共有されるセッション暗号化キー４０２ならびに初期化ベクトル（ＩＶ）４０３が、暗号化機能４０４に入力され、結果的に暗号化暗号テキスト４０５が生成される。ＳＳＬ／ＴＬＳ標準によれば、この暗号テキストは、キー４０７、プレインテキスト、レコード毎に増分される連番の関数としてのハッシュ機能４１１により生成されるＭＡＣと、ヘッダとを含むレコード４１０に埋め込まれる。得られたレコード４１０は、クライアント２０１とプロキシサーバ２０２との最初のハンドシェイクの一部として以前に確立されたＴＣＰ接続を介して、プロキシサーバ２０２に送信される。最初の初期化ベクトル４０３は、初期化中に送信側と受信側との間で合意される。
【００３１】
ＳＳＬ／ＴＬＳ標準によれば、同一のキー４０２を使用して、以前に送信されたレコードから生成された暗号テキスト４０５を２番目の初期化ベクトルとして使用して、次のプレインテキスト４０６を暗号化する。これによって、連続するレコード間の「リンク」が形成されるが、リンクが壊れた場合（パケットの喪失や破壊があった場合）には、この方式は機能しなくなる。
【００３２】
図４Ｂは、受信側での逆のプロセスを示す。受信側（例えば、プロキシサーバ２０２）において、第１のレコード４１０が以下のように暗号解読される。暗号テキストは、以前に共有されたセッションキー４１４と以前に共有された初期化ベクトル４１５とを使用して、暗号解読機能４１３において暗号解読される。ハッシュ機能４１７において、プレインテキストをキー４２０および（受信側で独立して増分される）１増分連番と組み合わせて使用し、送入レコードのＭＡＣに一致すべきＭＡＣを生成する。ＭＡＣが一致しない場合、そのレコードは廃棄される。
【００３３】
第２の（次の）送入レコード４１１は、セッションキー４１４を使用して暗号解読されるが、初期化ベクトル４１５の代わりに暗号テキスト４１０Ａを初期化ベクトルとして使用する。これは、図４Ａに示す対応する暗号化方式に適合する。上記のように、受信側がレコード４１０を受信しなかった場合（または、順不同に受信された場合）、暗号解読は、暗号解読に必要な「連結」初期化ベクトルに依存しているため、適切に行われない。暗号解読されたプレインテキスト４２１は、送入レコードのＭＡＣに一致するＭＡＣを生成しないので、ＭＡＣ比較機能４２３によりエラーが検出される。
【００３４】
上述のように、以前に送信されたデータレコードに対する従来のＳＳＬ／ＴＬＳの依存により、その基礎となるパケット送信メカニズムが完璧な信頼性を有することが必要となる。これは、「暗号ブロック連結」と称され、連続する各データレコードが、以前に生成されたレコードに依存して暗号化されるので、信頼性のあるレコード送信が必要となる（ＤＥＳに関しては、暗号ブロック連結はＦＩＰＳ８１により定義される）。結果的に、レコードが順不同に受信された場合や、データレコードが脱落した場合には、暗号化方式は失敗し、連番は一致しなくなる。この様なことが発生すれば、従来のＳＳＬ／ＴＬＳ方式では、ＴＣＰ接続は終了し、データ送信を再確立するために新たな接続が必要となる。このセキュリティ機能は、ハッカーが、クライアントとプロキシサーバとの間でのデータレコードの挿入や操作により確実な送信方式を妨害できないようにする意図がある。上述のように、図４Ａおよび図４Ｂの方式によりＵＤＰなどの信頼性のないプロトコルを用いてデータを送信した場合には、レコードの喪失や順不同によって直ちに接続が失われる。単純化の目的で、図４Ａおよび図４Ｂのレコード４１０には、暗号テキストの１ブロックしか示していない。実際には、１つのレコードに多数のブロックが含まれており、「暗号ブロック連結」は、１つのレコード内の連続するブロックの間で行われる。
【００３５】
図５Ａおよび図５Ｂは、本発明のある変形態様に従って使用可能な改良暗号化／暗号解読方式を示す。この変形態様によると、若干改良されたＳＳＬ／ＴＬＳレコードのフォーマット５０７を使用する。特殊ビット（ＵＤＰ）は、従来のヘッダに埋め込まれ、これは、レコードが暗号化ＵＤＰデータを含み、改良ＳＯＣＫＳ処理機能３０２Ｃに従って処理されるべきであることを示す。レコード検出器３０２Ａまたは３０１Ｅは、このビットを使用して、任意のＳＳＬ／ＴＬＳレコードを従来のＳＯＣＫＳ処理機能３０２Ｂまたは３０１Ｃにルーティングすべきか、それとも、改良ＳＯＣＫＳ処理機能３０２Ｃまたは３０１Ｄにルーティングすべきかを決定することができる。この機能により、既存のＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに準拠するシステムと共に本発明の原則を適用できる一方、ＵＤＰデータグラムを送信するときに強化セキュリティ条件を使用できる。
【００３６】
図５Ａに示すように、プレインテキスト５０１は、従来のＤＥＳ暗号化アルゴリズムなどの暗号化機能５０８を使用して暗号化される。暗号化は、共有セッションキー５０２と第１の初期化ベクトル５０３とを用いて実行され、その結果、暗号テキスト５０５が得られ、これを用いて改良ＳＳＬ／ＴＬＳレコード５０７を生成する。また、プレインテキスト５０１を別のキー５３０および第１のノンス値５０４と共に使用し、ハッシュ機能５０６を用いてＭＡＣ５０９を生成する。図４Ａの暗号化方式とは対照的に、レコード５０７には、ノンス値５０４および初期化ベクトル５０３が含まれており、初期化ベクトル５０３は、好ましくは一意的な値（例えば、ランダム数）からなる。ある実施形態によれば、複合ノンス／ＩＶ値は、強力なランダム数生成装置（例えば、Ｘ９．６２標準により定義され、市販のＲＳＡ  ＢＳＡＦＥ  ＣＲＹＰＴＯ−Ｃ機能により生成されるもの）を使用して生成される。
【００３７】
従来のＳＳＬ／ＴＬＳ方式とは対照的に、ノンス／ＩＶ値は、明示的に各レコードの一部として含まれるので、以前に送信されたレコードに依存せずに、レコードを暗号解読することができる。ある実施形態において、連番および初期化ベクトルは、単一の値（ノンス）に統合可能であり、この値は、任意の数値またはランダムに生成された数値である。ある実施形態において、ノンスは、ＳＳＬにおける連番と同じサイズ（例えば、８バイト）であり、各値は一意的なものである（すなわち、受信側が、以前に受信されたレコードのリストと照合することができる）。初期化ベクトルは、暗号のブロックと同じサイズ（例えば、８バイト）を有し、各値は一意的なものとすることができる。ある変形態様において、異なる初期化ベクトル間のハミング距離が大きいこと（例えば、各ビットが５０％の変化の確率を有するランダム数であること）が好ましい。別個のノンスや初期化ベクトルを付加する代わりに、複合ノンス／ＩＶ値を使用することができる。ＲＳＡセキュリティ社から販売されているＲＳＡ  ＢＳＡＦＥ  ＣＲＹＰＴＯ−Ｃ製品など、暗号的に強力なランダム数生成装置を用いて、この様な数値を生成することができる。
【００３８】
図５Ａの右側において、プレインテキスト５１０は、同様の方法で暗号化され、別のノンス５１３および初期化ベクトル５１４を用いて、データレコード５１６が生成される。
図５Ｂを参照して、次に、レコード５０７、５１６の暗号解読について説明する。レコード５０７からの暗号テキストは、共有セッションキー５０２とデータレコードから抽出された初期化ベクトル５０８とを用いて暗号解読され、プレインテキスト５０１を生成する。プレインテキストは、キー５１８およびデータレコードから抽出されたノンス５０８と共に、ハッシュ機能を介して供給され、レコードから抽出されたＭＡＣ５０９と比較可能なＭＡＣを生成する。
【００３９】
第２のレコード５１６は、暗号解読を実行するために以前に送信されたレコード５０７中の値に依存しないことを除き、同様の方法で暗号解読される。この様に、脱落または順不同のレコードでも対処可能である。
図５Ｃに示す本発明の変形態様によれば、複数の暗号ブロック５２１を１つのレコードに含めることができ、前の暗号ブロックを参照して、各ブロックの暗号テキストを暗号解読することができる。暗号解読機能５２６において初期化ベクトル５２４を用いて第１の暗号テキストを暗号解読する一方、前のブロックの暗号テキストを用いて一連の暗号テキストブロックを暗号解読する（一般的に、暗号化は逆の方法で実行される）。連結されたプレインテキストブロック５３１、５３２、５３３に基づいて、単一のＭＡＣ値を演算することができる。
【００４０】
上述のように、ノンスおよびＩＶを１つの値に統合できるので、同一の値をＩＶおよびＭＡＣ演算の一意的な識別子として使用する。
ある変形態様においては、明示的に送信されたノンスを使用して、以前に送信されたレコードが２度目に受信されたかどうかを決定する。もし、そうであれば、この様な状況は、いわゆる「再生パケット」によるハッカー攻撃を意味するので、プロトコルは、選択的に、接続を終了するか、または、警告を発する。なお、後者は、連番が順不同に受信された場合に接続を終了する従来のＳＳＬ／ＴＬＳとは異なる。さらに、ある実施形態において、連番チェックは、無効にされるか、または、使用されない。
【００４１】
従来のＳＳＬ／ＴＬＳとは対照的に、本発明のある側面によれば、初期化ベクトルはレコードにまたがって連結されることはない。各レコードは、一意的な初期化ベクトルを含み、暗号テキストブロックは、従来のようにレコード内で連結される。
特殊ＵＤＰビットの使用は、レコードを従来のＳＳＬ／ＴＬＳレコードまたは改良ＳＳＬ／ＴＬＳレコードとして識別するための一手法にすぎない。ある実施形態においては、ビットは全く必要とされず、ここに記述されているように全てのレコードが改良ＳＳＬ／ＴＬＳプロトコルに準拠するものと仮定されている。他の実施形態において、特定のレコードを上記の改良方式に従って処理すべきであることを示すために、異なるフラグまたは方法を用いることができる。一例として、クライアントとプロキシサーバとの間に起こる最初のハンドシェイクの間に、メッセージを送信して、以降のレコードが前記のプロトコルに従って受信されることを示すことができる。別の実施形態においては、確実なＴＣＰを使用して、データレコードの比較および識別のためにノンスと同等のＭＡＣ値またはＩＶ値の集合を交換することができる。
【００４２】
ＵＤＰ以外の信頼性のないプロトコルを利用して、本発明の原則を実施することもでき、本発明がＵＤＰデータグラムに限定されないことを認識すべきである。さらに、ＤＥＳ以外の他の暗号化アルゴリズム（例えば、ＡＥＳ）を使用することもでき、本発明がこの点において限定されないことを理解すべきである。
図６は、本発明の原則を実施するために使用可能な方法の各ステップを示す。なお、プロキシサーバ３０２の使用は、総じて任意であり、図示の機能は、もちろんクライアントコンピュータ３０１、サーバコンピュータ３０３、その他のコンピュータで実施することができる。または、ＳＯＣＫＳプロトコルの制約がなくても、信頼性のないパケット送信を提供するプロトコル（例えば、インタネットプロトコル）を利用して、本発明の原則を実施することもできる。上記の例では、クライアント３０１からサーバ３０３への確実なＵＤＰデータの送信を反映しているが、図６の例では、サーバ３０３がプロキシサーバ３０２にＵＤＰデータグラムを送信し、プロキシサーバ３０２がＵＤＰデータグラムを暗号化してクライアント３０１に送信すると仮定している。
【００４３】
クライアントは、図３Ｂに示すアーキテクチャを利用してアプリケーションサーバから確実なビデオデータを受信することを所望していると仮定する。つまり、サーバ３０３は、ＵＤＰを用いて信頼性なく送信されたデータストリームを、プロキシサーバ３０２を介してクライアント３０１に送信し、これにより、レコードを暗号化した状態でクライアント３０１に確実に送信する。先ず、ステップ６０１において、クライアントとプロキシサーバが、ＴＣＰ接続を確立する。このステップは、従来のものであり、ＳＯＣＫＳプロトコルに準拠している。ステップ６０２において、クライアントとプロキシサーバとは、従来のＳＳＬ方式に従って、信任情報を交換する（例えば、セキュリティパラメータを取り決める）。本発明のある変形態様において、クライアント３０１とプロキシサーバ３０２とは、上記の原則に従ってＵＤＰデータグラムを暗号化した状態で送信することにも同意する。これは、（新たな）ＴＣＰパケットを送信することにより実現でき、特定のポートを利用して確実なＵＤＰデータグラムを送信できることを示している。また、クライアントは、目的のアプリケーションサーバに関するサーバ情報（例えば、ＩＰアドレスやポート）を送信することもできる。なお、ステップ６０１、６０２は、信頼性のあるプロトコルを用いて実行されるものとして説明したが、もちろん、暗号化ステップに必要な情報を何らかの方法でコンピュータ間で共有または通信できる限り、信頼性のないプロトコルを用いて実行することができる。
【００４４】
ステップ６０３において、例えば、ランダム数発生装置を用いて、ノンス／ＩＶを生成する。ステップ６０４において、ノンスを使用して、サーバ３０３から受信されたＵＤＰデータグラムを暗号化し、必要に応じて、図５Ａ、図５Ｂ、および図５Ｃに示すその他のフィールドを生成する。例えば、前のバイトからのプレインテキストを初期化ベクトルとして用いて、暗号テキストの各ブロックを連結ブロック暗号化し、ＭＡＣを従来通り生成することができる。さらに、図５Ａ、図５Ｂ、および図５Ｃに示すように、ノンスをレコードに付加することができる。
【００４５】
ステップ６０５において、改良ＳＳＬ／ＴＬＳ／ＳＯＣＫＳプロトコルに従ってレコードを暗号化したことを示すために、「確実ＵＤＰ」ビットをレコードヘッダに設定する。上述のように、暗号化情報はその他様々な方法で示すことができるので、このビットは任意である。最後に、ステップ６０６において、レコードをプロキシサーバ３０２からクライアント３０１に送信する。ステップ６０７において、レコードをレコード検出器３０１Ｅにおいて受信し、確実ＵＤＰビットが設定されていれば、ステップ６０９において、改良ＳＯＣＫＳ処理に従ってレコードを暗号解読する。そうでなければ、ステップ６０８において、従来のＳＯＣＫＳ処理に従ってレコードを暗号解読する。
【００４６】
以上、ＵＤＰなどの信頼性のないプロトコルを用いて確実にデータを送信するためのシステムおよび方法について説明してきた。本発明は、ビデオ会議、ストリーミングメディア（オーディオ、ビデオ、または、その両方）、ファイルのバルク転送、インタネットを介したコンピュータゲーム（準リアルタイムゲームシステムなど）、インタネットテレフォニ、携帯電話送信、無線ＬＡＮなどのシステムを含む広範なシステムおよびアプリケーションに利用可能である。本質的に複雑でない信頼性のない通信プロトコル（例えば、ＵＤＰ、ＩＰなど）の使用により、データを確実に送信するために必要なオーバヘッドや処理が低減されるので、本発明は、低電力消費や低コンピュータ処理という形で利点を提供する。本発明は、インタネットを介した通信だけでなく、ローカルエリアネットワーク（例えば、イーサネット(登録商標)）、ピアツーピアネットワークなど、その他のコンピュータネットワークにおける用途にも利用可能である。また、本発明の主な用途は、ストリーミングメディアのためにＵＤＰトラフィックと共に用いられるものであるが、非ストリーミングメディアなど、様々なデータタイプを保護するためにも適している。
【００４７】
以上、本発明の特定の実施形態について説明してきたが、様々な変形態様、変更態様、代替構成、均等物も本発明の範囲に包含される。上記の発明は、ある特定のデータ処理環境内での運用に限定されるものではなく、分散コンピュータネットワーク環境、単一の独立型コンピュータシステム環境などのコンピュータ環境等、複数のデータ処理環境内で自由に運用できる。さらに、特定の一連のトランザクションやステップを用いて本発明を説明してきたが、当業者にとっては、本発明の範囲が前記の一連のトランザクションやステップに限定されるものではないことが明らかであろう。
【００４８】
本発明をプログラミングするために使用されるロジック、システムフロー、テーブル、データ構成の生成には、本質的な自由度がある。演算を行うデータ構成やデータ値は、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、明示的なものでも、他のデータから導出されたものでも、他のソースから取り込まれたものでも、プログラム演算またはロジック演算の結果でもよい。この特許における索引付け、検索、データ処理のためのアルゴリズムは、本発明の趣旨を逸脱するもの、または、本発明の範囲を制限するものでない限り、様々な性能／システムインテグレーション要件をサポートするために、置換または変更されてもよい。
【００４９】
さらに、本発明について、ハードウェアとソフトウェアとの特定の組み合わせを用いて説明したが、ハードウェアとソフトウェアとのその他の組み合わせも、本発明の範囲内であると認識すべきである。本発明は、ハードウェアのみ、もしくは、ソフトウェアのみ、または、その組み合わせを用いて実施してもよい。
したがって、この明細書および図面は、限定的ではなく例示的な意味合いと見なされるものとする。しかし、請求項に記載されている本発明のより広範な趣旨および範囲から逸脱することなく、本発明に対して、追加、除去、削除、その他の改良や変更が可能であることは明白である。
【００５０】
添付の方法に関する請求項において、ステップを識別する参照番号は、単に便宜上のものであり、ステップの必須の順序を暗示するためのものではない。したがって、本発明は、添付の特許請求の範囲内において、上記以外の方法で実施してもよいと理解される。いずれの請求項も、「ミーンズ・プラス・ファンクション」形式であると解釈してはならない。
【図面の簡単な説明】
【００５１】
【図１Ａ】ＴＣＰまたはＵＤＰをＩＰと共に利用してデータパケットを送信するための従来の方策を示す。
【図１Ｂ】ＳＳＬ／ＴＬＳをＴＣＰ／ＩＰと共に利用して確実なデータを送信するための従来の方策を示す。
【図１Ｃ】ヘッダフィールドと、暗号化暗号テキストフィールドと、メッセージ認証チェック（ＭＡＣ）とを含むＳＳＬ／ＴＬＳレコードのための従来のレコードフォーマットを示す。
【図２】ＳＯＣＫＳプロトコルを利用して、プロキシサーバ２０２を介してクライアントコンピュータ２０１をサーバコンピュータ２０３にインタフェースするための従来の方策を示す。
【図３Ａ】本発明の一つの変形態様に係る、送出フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図３Ｂ】本発明のある変形態様に係る、送入フロー方向の改良ＳＯＣＫＳプロトコルを用いたシステムを示す。
【図４Ａ】暗号化を用いてＳＳＬ／ＴＬＳレコードを生成する従来の手法を示す。
【図４Ｂ】以前に暗号解読されたレコードに依存してＳＳＬ／ＴＬＳレコードを暗号解読する従来の手法を示す。
【図５Ａ】以前に送信されたレコードとは独立して各レコードを暗号化する本発明のある変形態様に係る改良暗号化方式を示す。
【図５Ｂ】以前に受信されたレコードとは独立して各レコードを暗号解読する本発明のある変形態様に係る改良暗号解読方式を示す。
【図５Ｃ】単一のレコード内に多数の暗号ブロックを含む改良暗号解読方式を示す。
【図６】本発明の様々な原則に従って、暗号化レコードの生成と送信に使用可能な方法の各ステップを示す。
【図１Ａ】
2004529531.tif 000003
【図１Ｂ】
2004529531.tif 000004
【図１Ｃ】
2004529531.tif 000005
【図２】
2004529531.tif 000006
【図３Ａ】
2004529531.tif 000007
【図３Ｂ】
2004529531.tif 000008
【図４Ａ】
2004529531.tif 000009
【図４Ｂ】
2004529531.tif 000010
【図５Ａ】
2004529531.tif 000011
【図５Ｂ】
2004529531.tif 000012
【図５Ｃ】
2004529531.tif 000013
【図６】
2004529531.tif 000014
【国際公開パンフレット】
2004529531.tif 000015
2004529531.tif 000016
2004529531.tif 000017
2004529531.tif 000018
2004529531.tif 000019
2004529531.tif 000020
2004529531.tif 000021
2004529531.tif 000022
2004529531.tif 000023
2004529531.tif 000024
2004529531.tif 000025
2004529531.tif 000026
2004529531.tif 000027
2004529531.tif 000028
2004529531.tif 000029
2004529531.tif 000030
2004529531.tif 000031
2004529531.tif 000032
2004529531.tif 000033
2004529531.tif 000034
2004529531.tif 000035
2004529531.tif 000036
2004529531.tif 000037
2004529531.tif 000038
2004529531.tif 000039
2004529531.tif 000040
2004529531.tif 000041
2004529531.tif 000042
【国際調査報告】
2004529531.tif 000043
2004529531.tif 000044