コンピュータシステム間でメッセージを通信するための安全なコンテキストの確立
クライアントとサーバとの間でメッセージを通信するための安全なコンテキストを確立するための、ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（ＧＳＳ‐ＡＰＩ）に対応した方法を提供する。クライアントは、クライアントによって生成された第１の対称秘密鍵と、認証トークンとを含む第１のメッセージをサーバへ送り、第１のメッセージは、サーバの公開鍵証明書からの公開鍵で保護される（５１６）。認証トークンに基づいてサーバがクライアントを認証した後（５１８）、クライアントは、第１の対称秘密鍵で保護されておりかつ第２の対称秘密鍵を含む第２のメッセージをサーバから受信する（５２２）。クライアントおよびサーバは、第２の対称秘密鍵を使用して、クライアントとサーバとの間で送られる後続のメッセージを保護する。認証トークンは、クライアントに関連した公開鍵証明書、ユーザ名‐パスワードの対、またはセキュアチケットであってもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、特定的には、マルチコンピュータデータ転送のための方法および装置に関する。さらにより特定的には、本発明は、暗号化技術を使用したマルチコンピュータ通信のための方法および装置を提供する。
【背景技術】
【０００２】
電子商取引のウェブサイトおよび他の形式のアプリケーションは、ユーザおよびクライアントのためにコンピュータネットワーク上で取引を行う。要求された動作をクライアントのために行うに先立ち、クライアントは、クライアントの身元がセキュリティ目的のための適切な確実性レベルにあることを証明するために、認証手続きを通過しなければならない。
【０００３】
数多くのデータ処理システムは、ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（ＧＳＳ‐ＡＰＩ）を通じたクライアント認証動作に対応している。ＧＳＳ‐ＡＰＩは、リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ」、インターネット技術標準化委員会（ＩＥＴＦ）、コメント要求（ＲＦＣ） １５０８、１９９３年９月に記載されており、これは、リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｒｕｔｉｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ，Ｖｅｒｓｉｏｎ ２」、ＩＥＴＦ ＲＦＣ ２０７８、１９９７年１月によって廃止されている。これらの文書に記載されているように、ＧＳＳ‐ＡＰＩは、規定のサービスおよび基本要素を通じて基礎となる機構および技術の範囲に対応しており、これによって、互いに異なる動作およびプログラミング言語環境に対するアプリケーションのソースレベルの携帯性を認めるものである。
【０００４】
代わりとなる既存のＧＳＳ‐ＡＰＩ機構については、アダムス（Ａｄａｍｓ）著、「Ｔｈｅ Ｓｉｍｐｌｅ Ｐｕｂｌｉｃ‐Ｋｅｙ ＧＳＳ‐ＡＰＩ Ｍｅｃｈａｎｉｓｍ（ＳＰＫＭ）」、ＩＥＴＦ ＲＦＣ ２０２５、１９９６年１０月、およびアイズラー（Ｅｉｓｌｅｒ）著、「ＬＩＰＫＥＹ‐‐Ａ Ｌｏｗ Ｉｎｆｒａｎｓｔｒｕｃｔｕｒｅ Ｐｕｂｌｉｃ Ｋｅｙ Ｍｅｃｈａｎｉｓｍ Ｕｓｉｎｇ ＳＰＫＭ」、ＩＥＴＦ ＲＦＣ ２８４７、２０００年６月に紹介されている。これらの文書に記載されているように、ＳＰＫＭは、公開鍵インフラストラクチャを使用して、オンライン分散型アプリケーション環境における、認証、鍵の確立、データの完全性、およびデータの機密性を提供する。ＧＳＳ‐ＡＰＩに準拠することによって、ＳＰＫＭは、セキュリティサービスをアクセスするためのＧＳＳ‐ＡＰＩ呼び出しを使用するどのアプリケーションによっても使用することができる。代わりに、ＬＩＰＫＥＹは、クライアントとサーバとの間の安全なチャンネルを供給するための方法も提供する。ＬＩＰＫＥＹは、トランスポート層セキュリティ（ＴＬＳ）の通常の低インフラストラクチャ使用と多少類似しており、認証、データの完全性、およびデータの秘密のようなセキュリティ機能を実施するためのＧＳＳ‐ＡＰＩに対する代替方法である。ＴＬＳは、ディアークス（Ｄｉｅｒｋｓ）他著、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ １．０」、ＩＥＴＦ ＲＦＣ ２２４６、１９９９年１月に記載されている。ＬＩＰＫＥＹは、ＳＰＫＭの上に階層化された別個のＧＳＳ‐ＡＰＩ機構として、ＳＰＫＭを活用する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
使用中のサーバシステムの計算上の要求から、柔軟かつ軽量なセキュリティ動作に対する必要性がある。したがって、数多くの形式のクライアント認証を扱うＧＳＳ‐ＡＰＩ対応の機構があれば有利であろう。
【非特許文献１】リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ」、インターネット技術標準化委員会（ＩＥＴＦ）、コメント要求（ＲＦＣ） １５０８、１９９３年９月
【非特許文献２】リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｒｕｔｉｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ，Ｖｅｒｓｉｏｎ ２」、ＩＥＴＦ ＲＦＣ ２０７８、１９９７年１月
【非特許文献３】アダムス（Ａｄａｍｓ）著、「Ｔｈｅ Ｓｉｍｐｌｅ Ｐｕｂｌｉｃ‐Ｋｅｙ ＧＳＳ‐ＡＰＩ Ｍｅｃｈａｎｉｓｍ（ＳＰＫＭ）」、ＩＥＴＦ ＲＦＣ ２０２５、１９９６年１０月
【非特許文献４】アイズラー（Ｅｉｓｌｅｒ）著、「ＬＩＰＫＥＹ‐‐Ａ Ｌｏｗ Ｉｎｆｒａｎｓｔｒｕｃｔｕｒｅ Ｐｕｂｌｉｃ Ｋｅｙ Ｍｅｃｈａｎｉｓｍ Ｕｓｉｎｇ ＳＰＫＭ」、ＩＥＴＦ ＲＦＣ ２８４７、２０００年６月
【非特許文献５】ディアークス（Ｄｉｅｒｋｓ）他著、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ １．０」、ＩＥＴＦ ＲＦＣ ２２４６、１９９９年１月
【課題を解決するための手段】
【０００６】
クライアントとサーバとの間でメッセージを通信するための安全なコンテキストを確立するための、ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（ＧＳＳ‐ＡＰＩ）に対応した方法、データ処理システム、装置、およびコンピュータプログラム製品を提供する。クライアントは、クライアントによって生成された第１の対称秘密鍵と、認証トークンとを含む第１のメッセージをサーバへ送り、第１のメッセージは、サーバに関連した公開鍵証明書からの公開鍵で保護される。認証トークンに基づいてサーバがクライアントを認証できるとすると、クライアントは、第１の対称秘密鍵で保護されておりかつ第２の対称秘密鍵を含む第２のメッセージをサーバから受信する。クライアントおよびサーバは、第２の対称秘密鍵を使用して、クライアントとサーバとの間で送られる後続のメッセージを保護する。認証トークンは、クライアントに関連した公開鍵証明書、ユーザ名‐パスワードの対、またはセキュアチケットであってもよい。
【発明を実施するための最良の形態】
【０００７】
以下の図面を一例としてのみ参照して、本発明の好ましい一実施形態を詳細に説明する。
【０００８】
一般的に、本発明の好ましい実施形態を備えうる、またはそれに関連しうる装置は、多種多様なデータ処理技術を含む。したがって、本発明の好ましい実施形態をより詳細に説明するに先立ち、背景として、分散型データ処理システム内のハードウェアおよびソフトウェア構成要素の典型的な編成を説明する。
【０００９】
図面を参照すると、図１（Ａ）は、データ処理システムの典型的なネットワークを示し、それぞれは、本発明の好ましい実施形態の一部を実施しうる。分散型データ処理システム１００は、ネットワーク１０１を含み、ネットワーク１０１は、分散型データ処理システム１００内において互いに接続される様々な装置とコンピュータとの間の通信リンクを提供するために使用されてもよい媒体である。ネットワーク１０１は、有線または光ファイバケーブルなどの常時接続、もしくは、電話または無線通信を通じて行われる一時接続を含んでもよい。図示の例において、サーバ１０２およびサーバ１０３は、記憶部１０４と共にネットワーク１０１に接続される。加えて、クライアント１０５〜１０７もネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）などといった様々なコンピューティング装置によって表わされてもよい。分散型データ処理システム１００は、図示しない追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピアアーキテクチャを含んでもよい。
【００１０】
図示の例において、分散型データ処理システム１００は、軽量ディレクトリアクセスプロトコル（ＬＤＡＰ）、トランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）、無線アプリケーションプロトコル（ＷＡＰ）などといった様々なプロトコルを使用して互いに通信するネットワークおよびゲートウェイの世界規模の集合体を表わすネットワーク１０１を有するインターネットを含んでもよい。もちろん、分散型データ処理システム１００は、例えば、イントラネット、構内情報通信網（ＬＡＮ）、または広域通信網（ＷＡＮ）のような数多くの互いに異なる種類のネットワークも含んでもよい。例えば、サーバ１０２は、クライアント１０９、および無線通信リンクを実装するネットワーク１１０に直接対応する。ネットワークな使用可能な電話１１１は、無線リンク１１２を通じてネットワーク１１０に接続し、ＰＤＡ１１３は、無線リンク１１４を通じてネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、ブルートゥース（Ｒ）無線技術のような適切な技術を使用して、無線リンク１１５を渡って互いの間でデータを直接転送して、いわゆるパーソナルエリアネットワーク（ＰＡＮ）または個別の特定ネットワークを作成することもできる。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７へデータを転送することができる。
【００１１】
本発明の好ましい実施形態は、様々なハードウェアプラットフォーム上で実施することができよう。図１（Ａ）は、異機種コンピューティング環境の一例として意図されたものであり、本発明の好ましい実施形態に対するアーキテクチャの制限として意図されたものではない。
【００１２】
今度は図１（Ｂ）を参照すると、図１（Ａ）が示すような、本発明の好ましい実施形態が実施されうるデータ処理システムの典型的なコンピュータアーキテクチャを示す図である。データ処理システム１２０は、内部システムバス１２３に接続された１つ以上の中央処理装置（ＣＰＵ）１２２を含み、内部システムバス１２３は、ランダムアクセスメモリ（ＲＡＭ）１２４、読み出し専用メモリ１２６、および入出力アダプタ１２８を相互接続し、入出力アダプタ１２８は、プリンタ１３０、ディスク装置１３２、または音声出力システムなどの図示しない他の装置に対応している。システムバス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４をも接続する。ユーザインターフェイスアダプタ１４８は、キーボード１４０およびマウス１４２のような様々なユーザ装置、または、タッチスクリーン、スタイラス、マイクなどのような図示しない他の装置を接続する。ディスプレイアダプタ１４４は、システムバス１２３をディスプレイ装置１４６に接続する。
【００１３】
図１（Ｂ）におけるハードウェアはシステムの実施によって異なりうることを、当業者は理解するだろう。例えば、システムは、インテル（Ｒ）のペンティアム（Ｒ）搭載のプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）のように、１つ以上のプロセッサを有してもよく、１つ以上の種類の揮発性および不揮発性メモリを有してもよい。図１（Ｂ）に示すハードウェアに加えてまたはそれに代えて、他の周辺機器を使用してもよい。図示の例は、本発明の好ましい実施形態に対するアーキテクチャ上の制限を示唆するものではない。
【００１４】
様々なハードウェア上で実施可能であることに加えて、本発明の好ましい実施形態は、様々なソフトウェアにおいて実施されてもよい。典型的なオペレーティングシステムを使用して、各データ処理システム内のプログラムの実行を制御してもよい。例えば、ある装置はＵｎｉｘ（Ｒ）オペレーティングシステムを実行してもよく、他の装置は単純なＪａｖａ（Ｒ）実行時環境を含んでもよい。代表的なコンピュータプラットフォームは、ブラウザを含んでもよく、ブラウザとは、グラフィックファイル、ワード処理ファイル、拡張可能なマークアップ言語（ＸＭＬ）、ハイパーテキストマークアップ言語（ＨＴＭＬ）、ハンドヘルド装置マークアップ言語（ＨＤＭＬ）、無線マークアップ言語（ＷＭＬ）、ならびに様々な他のフォーマットおよび種類のファイルなどの、様々なフォーマットのハイパーテキスト文書をアクセスするための周知のソフトウェアアプリケーションである。
【００１５】
本明細書における図面の説明は、クライアント装置またはクライアント装置のユーザのいずれかによる何らかの操作を伴う。クライアントへの応答、またはクライアントからの要求あるいはその両方は、ユーザによって始まる場合もあるし、しばしばクライアントのユーザに代わってクライアントによって自動的に始まる場合もあることを、当業者は理解するだろう。よって、図面の説明においてクライアントまたはクライアントのユーザについて言及した場合には、「クライアント」および「ユーザ」という用語は、記載の処理の意味に対して実質的に影響を与えずに交換可能に使用できることが理解されるべきである。
【００１６】
本発明の好ましい実施形態は、図１（Ａ）および図１（Ｂ）に関して上述したように、様々なハードウェアおよびソフトウェアプラットフォーム上で実施されてもよい。しかしながら、より特定的には、ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（ＧＳＳ‐ＡＰＩ）に対応した、クライアントとサーバとの間の通信のための安全なコンテキストを確立するための公開鍵に基づく改良された機構に向けられており、安全なコンテキストは、複数の安全なメッセージが通信エンティティ間で交換されるであろう通信セッションの期間に２つ以上の通信エンティティ間で共有される情報を備える。しかしながら、本発明の好ましい実施形態をより詳細に説明する前に、本発明の好ましい実施形態の動作効率および他の利点を評価するために、デジタル証明書についての背景情報を若干提供する。
【００１７】
デジタル証明書は、通信またはトランザクションに関わる各当事者が公開鍵および秘密鍵と称される鍵の対を有する、公開鍵暗号法に対応している。各当事者の公開鍵は公開さているが、秘密鍵は秘密を確保される。公開鍵は、特定のエンティティに関連した数字であって、当該エンティティと信頼性のある対話をする必要のあるすべての人にとって既知であるようになっている。秘密鍵は、特定のエンティティにのみ既知であることになっている、すなわち秘密を確保される、数字である。典型的な非対称暗号システムにおいては、秘密鍵は、ちょうど１つの公開鍵に対応する。
【００１８】
公開鍵暗号システム内においては、すべての通信は公開鍵のみを伴い、秘密鍵は送信も共有も全くされないので、機密メッセージは公開情報のみを使用して生成でき、所期の受領者が単独に所有する秘密鍵のみを使用して復号化できる。さらに、認証、すなわちデジタル署名とともに、プライバシー、すなわち暗号化のために、公開鍵暗号法を使用することができる。
【００１９】
暗号化は、秘密復号鍵のない人なら誰でも読み取ることができない形式にデータを変換することであり、暗号化は、たとえ暗号化されたデータを見ることができる人であっても、予定外の人であれば、そのような人から情報内容を隠しておくことによって、プライバシーを確保する。認証は、デジタルメッセージの受信者が送信者の身元、またはメッセージの完全性あるいはその両方について確信できるようになる処理である。
【００２０】
例えば、送信者がメッセージを暗号化する場合に、受信者の公開鍵を使用して、元のメッセージ内のデータを暗号化されたメッセージの内容に変換する。送信者は、予定の受領者の公開鍵を使用してデータを暗号化し、受信者は、その秘密鍵を使用して、暗号化されたメッセージを復号化する。
【００２１】
データを認証する場合に、署名者の秘密鍵を使用してデータからデジタル署名を計算することによって、データを署名できる。いったんデータがデジタル署名されると、データは、署名者の身元と、データが署名者から生じたものであることを証明する署名と共に記憶できる。署名者は、その秘密鍵を使用してデータを署名し、受信者は、署名者の公開鍵を使用して書名を確認する。
【００２２】
証明書とは、個人、コンピュータシステム、当該システム上で動作する特定のサーバなどのエンティティの身元および鍵の所有を保証するデジタル文書である。証明書は、認証局によって発行される。認証局（ＣＡ）は、エンティティであって、通常、他の人またはエンティティに対して証明書を署名または発行することを委託された、トランザクションに対する第三者機関である。ＣＡは、通常、証明書に署名したエンティティに対して信頼してもよいという、公開鍵とその所有者との間の結びつきを保証するための何らかの法的な役割を担っている。数多くの民間の認証局があり、これらの局は、証明書を発行する際に、エンティティの身元と鍵の所有とを検証する役割を担っている。
【００２３】
認証局がエンティティに対して証明書を発行する場合に、当該エンティティは、公開鍵と、エンティティについての何らかの情報とを提供しなければならない。特別に装備されたウェブブラウザなどのソフトウェアツールが、この情報にデジタル署名して、認証局へ送ってもよい。認証局は、第三者機関の証明認証サービスを提供する民間会社の場合もあろう。その後、認証局は、証明書を生成して、それを返す。証明書は、通し番号および証明書が有効である日付などの他の情報を含んでもよい。認証局によって提供された値の一部は、認証サービス業務（ＣＳＰ）において公に公開された検証要件に部分的に基づいて、中立的で信頼できる紹介サービスとしての役割を果たすためのものである。
【００２４】
ＣＡは、要求エンティティの公開鍵を他の識別情報と共に埋め込んで、ＣＡの秘密鍵でデジタル証明書に署名することによって、新たなデジタル証明書を作成する。その後、トランザクションまたは通信中にデジタル証明書を受信する人であれば誰でも、ＣＡの公開鍵を使用して、証明書内の署名済み公開鍵を検証することができる。これは、ＣＡの署名はデジタル証明書に対する改ざん防止印としての役割を果たすという意味であり、これによって、証明書内のデータの完全性を保証する。
【００２５】
証明書処理の他の局面も標準化されている。証明書要求メッセージフォーマット（ＲＦＣ ２５１１）は、信用当事者がＣＡからの証明書を要求している場合にはいつも使用することが推奨されているフォーマットを規定している。証明書を転送するための証明書管理プロトコルも発表されている。本発明の好ましい一実施形態は、デジタル証明書を使用する分散型データ処理システムにある。図２〜３の説明は、デジタル証明書に関わる典型的な動作についての背景情報を提供する。
【００２６】
図２を今度は参照すると、個人がデジタル証明書を取得する典型的なやり方を示すブロック図である。何らかの種類のクライアントコンピュータ上で動作するユーザ２０２は、例えばユーザ公開鍵２０４およびユーザ秘密鍵２０６などの公開／秘密鍵の対を予め取得または生成している。ユーザ２０２は、ユーザ公開鍵２０４を含む証明書に対する要求２０８を生成して、当該要求を、ＣＡ公開鍵２１２とＣＡ秘密鍵２１４とを有する認証局２１０へ送る。認証局２１０は、ユーザ２０２に身元を何らかのやり方で検証して、ユーザ公開鍵２１８を含むＸ．５０９デジタル証明書２１６を生成する。証明書全体は、ＣＡ秘密鍵２１４で署名される。証明書は、ユーザの公開鍵、ユーザに関連した名前、および他の属性を含む。ユーザ２０２は、新たに生成されたデジタル証明書２１６を受信し、その後、ユーザ２０２は、必要に応じてデジタル証明書２１６を提示して、信頼できるトランザクションまたは信頼できる通信に関与してもよい。デジタル証明書２１６をユーザ２０２から受信するエンティティは、検証エンティティに対して発行されて使用可能なＣＡ公開鍵２１２を使用することによって、ＣＡの署名を検証してもよい。
【００２７】
図３を今度は参照すると、データ処理システムに対して認証すべきデジタル証明書をエンティティが使用するような典型的なやり方を示すブロック図である。ユーザ３０２は、Ｘ．５０９デジタル証明書３０４を所有しており、これは、ホストシステム３０８上のインターネットまたはイントラネットアプリケーション３０６へ送信される。アプリケーション３０６は、デジタル証明書を所有および使用するためのＸ．５０９機能を備える。ユーザ３０２は、アプリケーション３０６へ送るデータをその秘密鍵で署名または暗号化する。
【００２８】
証明書３０４を受信するエンティティは、アプリケーション、システム、サブシステムなどであってもよい。証明書３０４は、アプリケーション３０６に対してユーザ３０２を識別する件名または案件識別子を含み、アプリケーション３０６は、ユーザ３０２のために何らかの種類のサービスを行ってもよい。証明書３０４を使用するエンティティは、ユーザ３０２からの署名済みまたは暗号化済みデータに関する証明書を使用する前に、証明書の信憑性を検証する。
【００２９】
ホストシステム３０８は、システム３０８内のサービスおよびリソースをアクセスするためにユーザに権限を付与する、すなわち、ユーザの身元をユーザの特権と照合するために使用されるシステムレジストリ３１０を含んでもよい。例えば、システム管理者は、あるセキュリティグループにユーザの身元が所属するように構成しておいてもよく、ユーザは、全体的に見てセキュリティグループに利用可能であるように構成されたリソースのみをアクセスことができるように制限される。権限を付与するための様々な既知の方法をシステム内で使用してもよい。
【００３０】
デジタル証明書を適切に確認または検証するために、アプリケーションは、証明書が取り消されたかどうかを確認しなければならない。認証局が証明書を発行する場合に、認証局は、証明書が識別されることとなる固有の通し番号を生成し、この通し番号は、Ｘ．５０９証明書内の「通し番号」フィールド内に記憶される。典型的には、取り消されたＸ．５０９証明書は、ＣＲＬ内で証明書の通し番号によって識別される。取り消された証明書の通し番号は、ＣＲＬ内の通し番号リスト内に現れる。
【００３１】
証明書３０４がまだ有効かどうかを決定するために、アプリケーション３０６は、証明書失効リスト（ＣＲＬ）をＣＲＬリポジトリ３１２から取得して、ＣＲＬを確認する。アプリケーション３０６は、証明書３０４内の通し番号を、受信したＣＲＬ内の通し番号リストと比較して、一致する通し番号がなければ、アプリケーション３０６は証明書３０４を確認する。ＣＲＬが一致する通し番号を有していれば、証明書３０４は拒絶されるべきであり、アプリケーション３０６は、適切な措置を講じて、制御されたあらゆるリソースへのアクセスに対するユーザの要求を拒絶することができる。
【００３２】
図３は、ユーザがサーバをアクセスするためにデジタル証明書を使用するための一般的な方法を示しているのに対して、図４は、安全な通信コンテキストを確立するための、クライアントとサーバとの間の情報の転送の詳細を示しており、これは、図３に関して説明しなかったことである。
【００３３】
図４を今度は参照すると、クライアントとサーバとの間で安全な通信コンテンキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。処理は、サーバの公開鍵証明書の要求をクライアント４０２がサーバ４０４へ送ることで開始する（ステップ４０６）。サーバは当該要求を処理して、サーバの公開鍵証明書のコピーを含むまたは伴う応答を作成し（ステップ４０８）、これは要求クライアントへ返される（ステップ４１０）。
【００３４】
クライアントは、サーバの公開鍵証明書を確認して、セッションキーを生成する（ステップ４１２）。セッションキーは、好ましくは対称秘密鍵である。その後、クライアントは、セッションキーをサーバへ安全に送信する（ステップ４１４）。例えば、クライアントは、サーバの公開鍵証明書から予め抽出されたサーバの公開鍵でセッションキーを暗号化してもよい。その後、暗号化されたセッションキーは、クライアントの秘密鍵でデジタル署名されるメッセージに配置される。サーバは、メッセージ上のデジタル署名をクライアントの公開鍵で検証して、メッセージがクライアントによって作成および署名されていることを保証することが可能で、セッションキーは、サーバのみによって復号化されてもよい。デジタル封筒およびデジタル署名についての適用可能なフォーマットについての説明に関しては、「ＰＫＣＳ ＃７： Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｅｓｓａｇｅ Ｓｙｎｔａｘ Ｓｔａｎｄａｒｄ」、Ｖｅｒｓｉｏｎ １．５、ＲＳＡラボラトリーズ テクニカルノート、１９９３年１１月１日を参照のこと。
【００３５】
続いて、サーバは、クライアントのデジタル署名を検証してセッションキーを復号化した後にセッションキーを受け付けて、その後、安全な応答を生成し（ステップ４１６）、これはクライアントへ返される（ステップ４１８）。その後、クライアントは、クライアント認証トークンを生成および暗号化して（ステップ４２０）、クライアント認証トークンをサーバへ安全に送信する（ステップ４２２）。受信したメッセージからクライアント認証トークンを抽出した後に、サーバは、クライアントを認証して、応答を生成し（ステップ４２４）、これはクライアントへ返される（ステップ４２６）。その後、クライアントは、応答を分析して、クライアントがサーバによって確かに認証されているか、またはサーバはクライアントの認証要求を拒絶しているかを判断し（ステップ４２８）、処理を終える。
【００３６】
上記のように、図４は、既知のＧＳＳ‐ＡＰＩ対応の機構に係る安全な通信コンテキストを確立するための典型的な一方法を示している。対照的に、本明細書における取り組みは、残りの図面に関して本明細書において以下に説明するように、安全な通信コンテキストを確立するための改良された公開鍵に基づくＧＳＳ‐ＡＰＩ対応の機構に向けられている。
【００３７】
図５を今度は参照すると、本発明の一実施形態に係るクライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。処理は、例えば、クライアントがサーバアプリケーションに結びつこうとする場合など、サーバの公開鍵証明書を取得するための要求をクライアント５０２がサーバ５０４へ送ることで開始する（ステップ５０６）。当該要求を受信すると、サーバは、当該要求を処理して、サーバの公開鍵証明書のコピーを含むまたは伴う応答を作成し（ステップ５０８）、これは要求クライアントへ返される（ステップ５１０）。
【００３８】
サーバのデジタル証明書を受信後、クライアントは、サーバの公開鍵証明書を確認して、信頼できる認証局によって署名されていることを保証する（ステップ５１２）。注意すべきなのは、クライアントは、このサーバの公開鍵証明書のコピーを予め確認および記憶してることを認識してもよく、これによって、クライアントは、ローカルキャッシュから検索してサーバの証明書を取得することができる。代わりに、例えば、ディレクトリまたは同様のデータ記憶部からサーバの公開鍵証明書を検索することを通じてといった何らかの他のやり方で、サーバの公開鍵証明書をクライアントへ提供してもよい。
【００３９】
サーバの証明書が確かに検証されているとすると、クライアントは、サーバの公開鍵を証明書から抽出して、それをキャッシュする。その後、クライアントは、ランダム対称秘密鍵を認証トークンと共に生成する（ステップ５１４）。この特定の秘密鍵を、本明細書においてはトランスポートキーと称する。認証トークンは、ユーザ名‐パスワードの対、主要認証者からのタイムスタンプが記録されたセキュアチケット、クライアントに関連した公開鍵証明書、または他の認証情報を備えてもよい。クライアントは、適時、セキュアチケットなどのデータ項目を単にコピーすることによって認証トークンを生成してもよい。
【００４０】
その後、クライアントは、トランスポートキーと認証トークンとをサーバへ送信する（ステップ５１６）。クライアントからサーバへのトランスポートキーおよび認証トークンの送信は、サーバの公開鍵を使用する暗号化を通じた何らかのやり方で保護される。例えば、トランスポートキーおよび認証トークンは、サーバの公開鍵を使用して暗号化されて、サーバへ送られるメッセージ上でデジタル封筒を形成してもよい。代わりに、トランスポートキーおよび認証トークンは、個別に暗号化されて、サーバへのメッセージに含まれてもよい。
【００４１】
安全なメッセージをクライアントから受信すると、サーバは、デジタル封筒をサーバの秘密鍵で復号化する。その後、サーバは、サーバへ送られている認証トークンの種類にとって適切な処理を使用して、すなわち、クライアントによってサーバへ送られている認証トークンの種類に基づいて、クライアントまたはクライアントのユーザを認証する（ステップ５１８）。例えば、サーバは、ユーザ名‐パスワードの対に対してＬＤＡＰルックアップを行ってもよく、または、例えばカーベロスチケットなどのセキュアチケットを確認してもよい。認証トークンがクライアント証明書である場合には、本物のクライアントのみがクライアント証明書内の公開鍵に関連した秘密鍵で復号化できるクライアント公開鍵（デジタル封筒）で暗号化されたランダムセッションキーでサーバが応答すると、認証は達成される。デジタル封筒は、攻撃中の人物を阻止するためにクライアントがサーバへ送るトランスポートキーで暗号化されたまま、送られる。クライアントが認証されたとすると、サーバは、クライアントとサーバとの間で作成されている通信コンテキスト内のメッセージを保護するために使用されるであろうランダム対称秘密鍵を生成する（ステップ５２０）。この特定の秘密鍵を、本明細書においてはセッションキーと称する。
【００４２】
その後、サーバは、セッションキーをクライアントへ安全に送信する（ステップ５２２）。クライアントからサーバへのセッションキーの送信は、トランスポートキーを使用する暗号化を通じた何らかのやり方で保護される。例えば、サーバは、セッションキーを、サーバがトランスポートキーで暗号化するセッショントークンに配置してもよい。その後、サーバは、暗号化されたセッショントークンを、サーバがクライアントの公開鍵で捺印するメッセージに配置してもよく、その後、結果生じた封筒をトランスポートキーで暗号化する。代わりに、サーバは、クライアントに送るべきメッセージに暗号化されたセッションキーを配置する前に、トランスポートキーを使用してセッションキーを個別に暗号化してもよい。安全なメッセージを生成する他の例として、サーバは、トランスポートキーを使用して、セッションキーを含むメッセージ上にデジタル封筒を生成してもよい。
【００４３】
メッセージを受信後、クライアントは、トランスポートキーを使用してメッセージの適切な部分を復号化してセッションキーを抽出し（ステップ５２４）、これによって処理を終わらせる。使用された認証機構によっては、サーバは、互いに異なる形式のメッセージを生成している場合もある。よって、クライアントは、セッショントークンから直接セッションキーを取得することがあり、または、サーバがクライアントの公開鍵も使用してセッションキーを暗号化した場合またはセッションキーを含むメッセージの一部を暗号化した場合には、クライアントは、セッションキーをクライアントの秘密鍵で復号化する必要がある場合もある。加えて、クライアントとサーバとの間のメッセージは、再生攻撃に対する保護のために、通し番号を含んでもよい。
【００４４】
処理が終わった後、クライアントおよびサーバは共に、クライアントとサーバとの間のメッセージを保護するために後に使用できるセッションキーのコピーを所有し、これによって、クライアントとサーバとの間の通信コンテキストに対して、データの機密性およびデータの完全性を安全に保証する。例えば、クライアントは、セッションキーを使用して、サーバによって制御されるリソースをアクセスする要求をサーバに安全に送ってもよい。クライアントとサーバとの間の所定の通信セッションに対してセッションキーを使用してもよいこと、クライアントとサーバとの間の所定の通信セッションは、クライアントとサーバとの間、または、本発明の好ましい一実施形態であるＧＳＳ‐ＡＰＩ対応の機構によって提供される安全なコンテキスト内または何らかの他の機構によって提供される安全なコンテキスト内の他のサーバ間、あるいはその両方である、他の安全な通信セッションと同時並行であってもよいこと、および、所定の通信セッションはこれらの同時並行セッションの継続が許可されている間に終了されてもよいことが、当業者によって理解されるべきである。
【００４５】
本取り組みの利点は、上述の詳細な説明の観点から明確であるはずである。安全な通信コンテキストを確立するための従来技術であるＧＳＳ‐ＡＰＩ対応の機構と比較して、本発明の好ましい実施形態は、従来実施されてきたユーザ名‐パスワード型のソリューションとしての同一のＧＳＳ‐ＡＰＩ対応の機構を使用し続けながら、必要に応じて、ユーザ名‐パスワード型のクライアント‐サーバ認証動作から完全な公開鍵インフラストラクチャ（ＰＫＩ）によるソリューションへ拡張する機能を提供する。加えて、本発明の好ましい実施形態によって、クライアントは、ＬＩＰＫＥＹでは許可されていない、公開鍵証明書の使用による認証を行うことができる。さらに、本発明の好ましい実施形態によって、ＳＰＫＭでは対応していない、ユーザ名‐パスワード、セキュアチケット、または公開鍵証明書などの様々なクライアント認証機構が可能となる。さらに、本発明の好ましい実施形態は、ＬＩＰＫＥＹと比較して、ネットワークトラフィックおよび暗号化動作を最小限にする。例えば、ＬＩＰＫＥＹでは６つのメッセージが交換されるのに対して、４つのメッセージがクライアントとサーバとの間で交換される。
【００４６】
完全に機能するデータ処理システムのコンテキストにおいて本発明の好ましい実施形態を説明してきたが、本発明の好ましい実施形態の処理は、分散を実行するために実際に使用される特定の種類の信号記録媒体に関係なく、コンピュータ読み取り可能な媒体および様々な他の形式における命令の形式で分散されうることが、当業者にとっては当然であることに注意するのが重要である。コンピュータ読み取り可能な媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピー（Ｒ）ディスク、ハードディスクドライブ、ＲＡＭ、およびＣＤ−ＲＯＭ、ならびに、デジタルおよびアナログ通信リンクなどの送信型媒体が含まれる。
【００４７】
方法とは、一般的に、自己矛盾のない、所望の結果を導く一連のステップであると考えられる。これらのステップは、物理量の物理的な操作を必要とする。通常、必ずしもそうではないものの、これらの量は、記憶、転送、結合、比較、およびそうでなければ操作可能な電気的または磁気的信号の形式を取る。主に一般的な使用上の理由から、このような信号をビット、値、パラメータ、項目、要素、オブジェクト、記号、文字、期間、または数値などと称するのが時には便利である。しかしながら、これらの用語または類似の用語は、適切な物理量に関連付けられるべきものであり、これらの量に対して適用した便利なラベルに過ぎないことに注意すべきである。
【００４８】
本発明の好ましい実施形態の説明を例示の目的で提示してきたが、網羅的なものでも、開示された実施形態に限定しようとするものでもない。数多くの修正および変形が当業者にとっては明らかだろう。
【図面の簡単な説明】
【００４９】
【図１】それぞれ本発明の好ましい実施形態を実施しうるデータ処理システムの典型的なネットワーク、当該データ処理システム内で使用されうる典型的なコンピュータアーキテクチャを示す。
【図２】個人がデジタル証明書を取得する典型的なやり方を示すブロック図である。
【図３】データ処理システムに対して認証すべきデジタル証明書をエンティティが使用しうる典型的なやり方を示すブロック図である。
【図４】クライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。
【図５】本発明の一実施形態に係るクライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、特定的には、マルチコンピュータデータ転送のための方法および装置に関する。さらにより特定的には、本発明は、暗号化技術を使用したマルチコンピュータ通信のための方法および装置を提供する。
【背景技術】
【０００２】
電子商取引のウェブサイトおよび他の形式のアプリケーションは、ユーザおよびクライアントのためにコンピュータネットワーク上で取引を行う。要求された動作をクライアントのために行うに先立ち、クライアントは、クライアントの身元がセキュリティ目的のための適切な確実性レベルにあることを証明するために、認証手続きを通過しなければならない。
【０００３】
数多くのデータ処理システムは、ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（ＧＳＳ‐ＡＰＩ）を通じたクライアント認証動作に対応している。ＧＳＳ‐ＡＰＩは、リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ」、インターネット技術標準化委員会（ＩＥＴＦ）、コメント要求（ＲＦＣ） １５０８、１９９３年９月に記載されており、これは、リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｒｕｔｉｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ，Ｖｅｒｓｉｏｎ ２」、ＩＥＴＦ ＲＦＣ ２０７８、１９９７年１月によって廃止されている。これらの文書に記載されているように、ＧＳＳ‐ＡＰＩは、規定のサービスおよび基本要素を通じて基礎となる機構および技術の範囲に対応しており、これによって、互いに異なる動作およびプログラミング言語環境に対するアプリケーションのソースレベルの携帯性を認めるものである。
【０００４】
代わりとなる既存のＧＳＳ‐ＡＰＩ機構については、アダムス（Ａｄａｍｓ）著、「Ｔｈｅ Ｓｉｍｐｌｅ Ｐｕｂｌｉｃ‐Ｋｅｙ ＧＳＳ‐ＡＰＩ Ｍｅｃｈａｎｉｓｍ（ＳＰＫＭ）」、ＩＥＴＦ ＲＦＣ ２０２５、１９９６年１０月、およびアイズラー（Ｅｉｓｌｅｒ）著、「ＬＩＰＫＥＹ‐‐Ａ Ｌｏｗ Ｉｎｆｒａｎｓｔｒｕｃｔｕｒｅ Ｐｕｂｌｉｃ Ｋｅｙ Ｍｅｃｈａｎｉｓｍ Ｕｓｉｎｇ ＳＰＫＭ」、ＩＥＴＦ ＲＦＣ ２８４７、２０００年６月に紹介されている。これらの文書に記載されているように、ＳＰＫＭは、公開鍵インフラストラクチャを使用して、オンライン分散型アプリケーション環境における、認証、鍵の確立、データの完全性、およびデータの機密性を提供する。ＧＳＳ‐ＡＰＩに準拠することによって、ＳＰＫＭは、セキュリティサービスをアクセスするためのＧＳＳ‐ＡＰＩ呼び出しを使用するどのアプリケーションによっても使用することができる。代わりに、ＬＩＰＫＥＹは、クライアントとサーバとの間の安全なチャンネルを供給するための方法も提供する。ＬＩＰＫＥＹは、トランスポート層セキュリティ（ＴＬＳ）の通常の低インフラストラクチャ使用と多少類似しており、認証、データの完全性、およびデータの秘密のようなセキュリティ機能を実施するためのＧＳＳ‐ＡＰＩに対する代替方法である。ＴＬＳは、ディアークス（Ｄｉｅｒｋｓ）他著、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ １．０」、ＩＥＴＦ ＲＦＣ ２２４６、１９９９年１月に記載されている。ＬＩＰＫＥＹは、ＳＰＫＭの上に階層化された別個のＧＳＳ‐ＡＰＩ機構として、ＳＰＫＭを活用する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
使用中のサーバシステムの計算上の要求から、柔軟かつ軽量なセキュリティ動作に対する必要性がある。したがって、数多くの形式のクライアント認証を扱うＧＳＳ‐ＡＰＩ対応の機構があれば有利であろう。
【非特許文献１】リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ」、インターネット技術標準化委員会（ＩＥＴＦ）、コメント要求（ＲＦＣ） １５０８、１９９３年９月
【非特許文献２】リン（Ｌｉｎｎ）著、「Ｇｅｎｅｒｉｃ Ｓｅｃｒｕｔｉｙ Ｓｅｒｖｉｃｅｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ，Ｖｅｒｓｉｏｎ ２」、ＩＥＴＦ ＲＦＣ ２０７８、１９９７年１月
【非特許文献３】アダムス（Ａｄａｍｓ）著、「Ｔｈｅ Ｓｉｍｐｌｅ Ｐｕｂｌｉｃ‐Ｋｅｙ ＧＳＳ‐ＡＰＩ Ｍｅｃｈａｎｉｓｍ（ＳＰＫＭ）」、ＩＥＴＦ ＲＦＣ ２０２５、１９９６年１０月
【非特許文献４】アイズラー（Ｅｉｓｌｅｒ）著、「ＬＩＰＫＥＹ‐‐Ａ Ｌｏｗ Ｉｎｆｒａｎｓｔｒｕｃｔｕｒｅ Ｐｕｂｌｉｃ Ｋｅｙ Ｍｅｃｈａｎｉｓｍ Ｕｓｉｎｇ ＳＰＫＭ」、ＩＥＴＦ ＲＦＣ ２８４７、２０００年６月
【非特許文献５】ディアークス（Ｄｉｅｒｋｓ）他著、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ １．０」、ＩＥＴＦ ＲＦＣ ２２４６、１９９９年１月
【課題を解決するための手段】
【０００６】
クライアントとサーバとの間でメッセージを通信するための安全なコンテキストを確立するための、ジェネリックセキュリティサービスアプリケーションプログラミングインターフェイス（ＧＳＳ‐ＡＰＩ）に対応した方法、データ処理システム、装置、およびコンピュータプログラム製品を提供する。クライアントは、クライアントによって生成された第１の対称秘密鍵と、認証トークンとを含む第１のメッセージをサーバへ送り、第１のメッセージは、サーバに関連した公開鍵証明書からの公開鍵で保護される。認証トークンに基づいてサーバがクライアントを認証できるとすると、クライアントは、第１の対称秘密鍵で保護されておりかつ第２の対称秘密鍵を含む第２のメッセージをサーバから受信する。クライアントおよびサーバは、第２の対称秘密鍵を使用して、クライアントとサーバとの間で送られる後続のメッセージを保護する。認証トークンは、クライアントに関連した公開鍵証明書、ユーザ名‐パスワードの対、またはセキュアチケットであってもよい。
【発明を実施するための最良の形態】
【０００７】
以下の図面を一例としてのみ参照して、本発明の好ましい一実施形態を詳細に説明する。
【０００８】
一般的に、本発明の好ましい実施形態を備えうる、またはそれに関連しうる装置は、多種多様なデータ処理技術を含む。したがって、本発明の好ましい実施形態をより詳細に説明するに先立ち、背景として、分散型データ処理システム内のハードウェアおよびソフトウェア構成要素の典型的な編成を説明する。
【０００９】
図面を参照すると、図１（Ａ）は、データ処理システムの典型的なネットワークを示し、それぞれは、本発明の好ましい実施形態の一部を実施しうる。分散型データ処理システム１００は、ネットワーク１０１を含み、ネットワーク１０１は、分散型データ処理システム１００内において互いに接続される様々な装置とコンピュータとの間の通信リンクを提供するために使用されてもよい媒体である。ネットワーク１０１は、有線または光ファイバケーブルなどの常時接続、もしくは、電話または無線通信を通じて行われる一時接続を含んでもよい。図示の例において、サーバ１０２およびサーバ１０３は、記憶部１０４と共にネットワーク１０１に接続される。加えて、クライアント１０５〜１０７もネットワーク１０１に接続される。クライアント１０５〜１０７およびサーバ１０２〜１０３は、メインフレーム、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）などといった様々なコンピューティング装置によって表わされてもよい。分散型データ処理システム１００は、図示しない追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピアアーキテクチャを含んでもよい。
【００１０】
図示の例において、分散型データ処理システム１００は、軽量ディレクトリアクセスプロトコル（ＬＤＡＰ）、トランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）、無線アプリケーションプロトコル（ＷＡＰ）などといった様々なプロトコルを使用して互いに通信するネットワークおよびゲートウェイの世界規模の集合体を表わすネットワーク１０１を有するインターネットを含んでもよい。もちろん、分散型データ処理システム１００は、例えば、イントラネット、構内情報通信網（ＬＡＮ）、または広域通信網（ＷＡＮ）のような数多くの互いに異なる種類のネットワークも含んでもよい。例えば、サーバ１０２は、クライアント１０９、および無線通信リンクを実装するネットワーク１１０に直接対応する。ネットワークな使用可能な電話１１１は、無線リンク１１２を通じてネットワーク１１０に接続し、ＰＤＡ１１３は、無線リンク１１４を通じてネットワーク１１０に接続する。電話１１１およびＰＤＡ１１３は、ブルートゥース（Ｒ）無線技術のような適切な技術を使用して、無線リンク１１５を渡って互いの間でデータを直接転送して、いわゆるパーソナルエリアネットワーク（ＰＡＮ）または個別の特定ネットワークを作成することもできる。同様に、ＰＤＡ１１３は、無線通信リンク１１６を介してＰＤＡ１０７へデータを転送することができる。
【００１１】
本発明の好ましい実施形態は、様々なハードウェアプラットフォーム上で実施することができよう。図１（Ａ）は、異機種コンピューティング環境の一例として意図されたものであり、本発明の好ましい実施形態に対するアーキテクチャの制限として意図されたものではない。
【００１２】
今度は図１（Ｂ）を参照すると、図１（Ａ）が示すような、本発明の好ましい実施形態が実施されうるデータ処理システムの典型的なコンピュータアーキテクチャを示す図である。データ処理システム１２０は、内部システムバス１２３に接続された１つ以上の中央処理装置（ＣＰＵ）１２２を含み、内部システムバス１２３は、ランダムアクセスメモリ（ＲＡＭ）１２４、読み出し専用メモリ１２６、および入出力アダプタ１２８を相互接続し、入出力アダプタ１２８は、プリンタ１３０、ディスク装置１３２、または音声出力システムなどの図示しない他の装置に対応している。システムバス１２３は、通信リンク１３６へのアクセスを提供する通信アダプタ１３４をも接続する。ユーザインターフェイスアダプタ１４８は、キーボード１４０およびマウス１４２のような様々なユーザ装置、または、タッチスクリーン、スタイラス、マイクなどのような図示しない他の装置を接続する。ディスプレイアダプタ１４４は、システムバス１２３をディスプレイ装置１４６に接続する。
【００１３】
図１（Ｂ）におけるハードウェアはシステムの実施によって異なりうることを、当業者は理解するだろう。例えば、システムは、インテル（Ｒ）のペンティアム（Ｒ）搭載のプロセッサおよびデジタル信号プロセッサ（ＤＳＰ）のように、１つ以上のプロセッサを有してもよく、１つ以上の種類の揮発性および不揮発性メモリを有してもよい。図１（Ｂ）に示すハードウェアに加えてまたはそれに代えて、他の周辺機器を使用してもよい。図示の例は、本発明の好ましい実施形態に対するアーキテクチャ上の制限を示唆するものではない。
【００１４】
様々なハードウェア上で実施可能であることに加えて、本発明の好ましい実施形態は、様々なソフトウェアにおいて実施されてもよい。典型的なオペレーティングシステムを使用して、各データ処理システム内のプログラムの実行を制御してもよい。例えば、ある装置はＵｎｉｘ（Ｒ）オペレーティングシステムを実行してもよく、他の装置は単純なＪａｖａ（Ｒ）実行時環境を含んでもよい。代表的なコンピュータプラットフォームは、ブラウザを含んでもよく、ブラウザとは、グラフィックファイル、ワード処理ファイル、拡張可能なマークアップ言語（ＸＭＬ）、ハイパーテキストマークアップ言語（ＨＴＭＬ）、ハンドヘルド装置マークアップ言語（ＨＤＭＬ）、無線マークアップ言語（ＷＭＬ）、ならびに様々な他のフォーマットおよび種類のファイルなどの、様々なフォーマットのハイパーテキスト文書をアクセスするための周知のソフトウェアアプリケーションである。
【００１５】
本明細書における図面の説明は、クライアント装置またはクライアント装置のユーザのいずれかによる何らかの操作を伴う。クライアントへの応答、またはクライアントからの要求あるいはその両方は、ユーザによって始まる場合もあるし、しばしばクライアントのユーザに代わってクライアントによって自動的に始まる場合もあることを、当業者は理解するだろう。よって、図面の説明においてクライアントまたはクライアントのユーザについて言及した場合には、「クライアント」および「ユーザ」という用語は、記載の処理の意味に対して実質的に影響を与えずに交換可能に使用できることが理解されるべきである。
【００１６】
本発明の好ましい実施形態は、図１（Ａ）および図１（Ｂ）に関して上述したように、様々なハードウェアおよびソフトウェアプラットフォーム上で実施されてもよい。しかしながら、より特定的には、ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（ＧＳＳ‐ＡＰＩ）に対応した、クライアントとサーバとの間の通信のための安全なコンテキストを確立するための公開鍵に基づく改良された機構に向けられており、安全なコンテキストは、複数の安全なメッセージが通信エンティティ間で交換されるであろう通信セッションの期間に２つ以上の通信エンティティ間で共有される情報を備える。しかしながら、本発明の好ましい実施形態をより詳細に説明する前に、本発明の好ましい実施形態の動作効率および他の利点を評価するために、デジタル証明書についての背景情報を若干提供する。
【００１７】
デジタル証明書は、通信またはトランザクションに関わる各当事者が公開鍵および秘密鍵と称される鍵の対を有する、公開鍵暗号法に対応している。各当事者の公開鍵は公開さているが、秘密鍵は秘密を確保される。公開鍵は、特定のエンティティに関連した数字であって、当該エンティティと信頼性のある対話をする必要のあるすべての人にとって既知であるようになっている。秘密鍵は、特定のエンティティにのみ既知であることになっている、すなわち秘密を確保される、数字である。典型的な非対称暗号システムにおいては、秘密鍵は、ちょうど１つの公開鍵に対応する。
【００１８】
公開鍵暗号システム内においては、すべての通信は公開鍵のみを伴い、秘密鍵は送信も共有も全くされないので、機密メッセージは公開情報のみを使用して生成でき、所期の受領者が単独に所有する秘密鍵のみを使用して復号化できる。さらに、認証、すなわちデジタル署名とともに、プライバシー、すなわち暗号化のために、公開鍵暗号法を使用することができる。
【００１９】
暗号化は、秘密復号鍵のない人なら誰でも読み取ることができない形式にデータを変換することであり、暗号化は、たとえ暗号化されたデータを見ることができる人であっても、予定外の人であれば、そのような人から情報内容を隠しておくことによって、プライバシーを確保する。認証は、デジタルメッセージの受信者が送信者の身元、またはメッセージの完全性あるいはその両方について確信できるようになる処理である。
【００２０】
例えば、送信者がメッセージを暗号化する場合に、受信者の公開鍵を使用して、元のメッセージ内のデータを暗号化されたメッセージの内容に変換する。送信者は、予定の受領者の公開鍵を使用してデータを暗号化し、受信者は、その秘密鍵を使用して、暗号化されたメッセージを復号化する。
【００２１】
データを認証する場合に、署名者の秘密鍵を使用してデータからデジタル署名を計算することによって、データを署名できる。いったんデータがデジタル署名されると、データは、署名者の身元と、データが署名者から生じたものであることを証明する署名と共に記憶できる。署名者は、その秘密鍵を使用してデータを署名し、受信者は、署名者の公開鍵を使用して書名を確認する。
【００２２】
証明書とは、個人、コンピュータシステム、当該システム上で動作する特定のサーバなどのエンティティの身元および鍵の所有を保証するデジタル文書である。証明書は、認証局によって発行される。認証局（ＣＡ）は、エンティティであって、通常、他の人またはエンティティに対して証明書を署名または発行することを委託された、トランザクションに対する第三者機関である。ＣＡは、通常、証明書に署名したエンティティに対して信頼してもよいという、公開鍵とその所有者との間の結びつきを保証するための何らかの法的な役割を担っている。数多くの民間の認証局があり、これらの局は、証明書を発行する際に、エンティティの身元と鍵の所有とを検証する役割を担っている。
【００２３】
認証局がエンティティに対して証明書を発行する場合に、当該エンティティは、公開鍵と、エンティティについての何らかの情報とを提供しなければならない。特別に装備されたウェブブラウザなどのソフトウェアツールが、この情報にデジタル署名して、認証局へ送ってもよい。認証局は、第三者機関の証明認証サービスを提供する民間会社の場合もあろう。その後、認証局は、証明書を生成して、それを返す。証明書は、通し番号および証明書が有効である日付などの他の情報を含んでもよい。認証局によって提供された値の一部は、認証サービス業務（ＣＳＰ）において公に公開された検証要件に部分的に基づいて、中立的で信頼できる紹介サービスとしての役割を果たすためのものである。
【００２４】
ＣＡは、要求エンティティの公開鍵を他の識別情報と共に埋め込んで、ＣＡの秘密鍵でデジタル証明書に署名することによって、新たなデジタル証明書を作成する。その後、トランザクションまたは通信中にデジタル証明書を受信する人であれば誰でも、ＣＡの公開鍵を使用して、証明書内の署名済み公開鍵を検証することができる。これは、ＣＡの署名はデジタル証明書に対する改ざん防止印としての役割を果たすという意味であり、これによって、証明書内のデータの完全性を保証する。
【００２５】
証明書処理の他の局面も標準化されている。証明書要求メッセージフォーマット（ＲＦＣ ２５１１）は、信用当事者がＣＡからの証明書を要求している場合にはいつも使用することが推奨されているフォーマットを規定している。証明書を転送するための証明書管理プロトコルも発表されている。本発明の好ましい一実施形態は、デジタル証明書を使用する分散型データ処理システムにある。図２〜３の説明は、デジタル証明書に関わる典型的な動作についての背景情報を提供する。
【００２６】
図２を今度は参照すると、個人がデジタル証明書を取得する典型的なやり方を示すブロック図である。何らかの種類のクライアントコンピュータ上で動作するユーザ２０２は、例えばユーザ公開鍵２０４およびユーザ秘密鍵２０６などの公開／秘密鍵の対を予め取得または生成している。ユーザ２０２は、ユーザ公開鍵２０４を含む証明書に対する要求２０８を生成して、当該要求を、ＣＡ公開鍵２１２とＣＡ秘密鍵２１４とを有する認証局２１０へ送る。認証局２１０は、ユーザ２０２に身元を何らかのやり方で検証して、ユーザ公開鍵２１８を含むＸ．５０９デジタル証明書２１６を生成する。証明書全体は、ＣＡ秘密鍵２１４で署名される。証明書は、ユーザの公開鍵、ユーザに関連した名前、および他の属性を含む。ユーザ２０２は、新たに生成されたデジタル証明書２１６を受信し、その後、ユーザ２０２は、必要に応じてデジタル証明書２１６を提示して、信頼できるトランザクションまたは信頼できる通信に関与してもよい。デジタル証明書２１６をユーザ２０２から受信するエンティティは、検証エンティティに対して発行されて使用可能なＣＡ公開鍵２１２を使用することによって、ＣＡの署名を検証してもよい。
【００２７】
図３を今度は参照すると、データ処理システムに対して認証すべきデジタル証明書をエンティティが使用するような典型的なやり方を示すブロック図である。ユーザ３０２は、Ｘ．５０９デジタル証明書３０４を所有しており、これは、ホストシステム３０８上のインターネットまたはイントラネットアプリケーション３０６へ送信される。アプリケーション３０６は、デジタル証明書を所有および使用するためのＸ．５０９機能を備える。ユーザ３０２は、アプリケーション３０６へ送るデータをその秘密鍵で署名または暗号化する。
【００２８】
証明書３０４を受信するエンティティは、アプリケーション、システム、サブシステムなどであってもよい。証明書３０４は、アプリケーション３０６に対してユーザ３０２を識別する件名または案件識別子を含み、アプリケーション３０６は、ユーザ３０２のために何らかの種類のサービスを行ってもよい。証明書３０４を使用するエンティティは、ユーザ３０２からの署名済みまたは暗号化済みデータに関する証明書を使用する前に、証明書の信憑性を検証する。
【００２９】
ホストシステム３０８は、システム３０８内のサービスおよびリソースをアクセスするためにユーザに権限を付与する、すなわち、ユーザの身元をユーザの特権と照合するために使用されるシステムレジストリ３１０を含んでもよい。例えば、システム管理者は、あるセキュリティグループにユーザの身元が所属するように構成しておいてもよく、ユーザは、全体的に見てセキュリティグループに利用可能であるように構成されたリソースのみをアクセスことができるように制限される。権限を付与するための様々な既知の方法をシステム内で使用してもよい。
【００３０】
デジタル証明書を適切に確認または検証するために、アプリケーションは、証明書が取り消されたかどうかを確認しなければならない。認証局が証明書を発行する場合に、認証局は、証明書が識別されることとなる固有の通し番号を生成し、この通し番号は、Ｘ．５０９証明書内の「通し番号」フィールド内に記憶される。典型的には、取り消されたＸ．５０９証明書は、ＣＲＬ内で証明書の通し番号によって識別される。取り消された証明書の通し番号は、ＣＲＬ内の通し番号リスト内に現れる。
【００３１】
証明書３０４がまだ有効かどうかを決定するために、アプリケーション３０６は、証明書失効リスト（ＣＲＬ）をＣＲＬリポジトリ３１２から取得して、ＣＲＬを確認する。アプリケーション３０６は、証明書３０４内の通し番号を、受信したＣＲＬ内の通し番号リストと比較して、一致する通し番号がなければ、アプリケーション３０６は証明書３０４を確認する。ＣＲＬが一致する通し番号を有していれば、証明書３０４は拒絶されるべきであり、アプリケーション３０６は、適切な措置を講じて、制御されたあらゆるリソースへのアクセスに対するユーザの要求を拒絶することができる。
【００３２】
図３は、ユーザがサーバをアクセスするためにデジタル証明書を使用するための一般的な方法を示しているのに対して、図４は、安全な通信コンテキストを確立するための、クライアントとサーバとの間の情報の転送の詳細を示しており、これは、図３に関して説明しなかったことである。
【００３３】
図４を今度は参照すると、クライアントとサーバとの間で安全な通信コンテンキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。処理は、サーバの公開鍵証明書の要求をクライアント４０２がサーバ４０４へ送ることで開始する（ステップ４０６）。サーバは当該要求を処理して、サーバの公開鍵証明書のコピーを含むまたは伴う応答を作成し（ステップ４０８）、これは要求クライアントへ返される（ステップ４１０）。
【００３４】
クライアントは、サーバの公開鍵証明書を確認して、セッションキーを生成する（ステップ４１２）。セッションキーは、好ましくは対称秘密鍵である。その後、クライアントは、セッションキーをサーバへ安全に送信する（ステップ４１４）。例えば、クライアントは、サーバの公開鍵証明書から予め抽出されたサーバの公開鍵でセッションキーを暗号化してもよい。その後、暗号化されたセッションキーは、クライアントの秘密鍵でデジタル署名されるメッセージに配置される。サーバは、メッセージ上のデジタル署名をクライアントの公開鍵で検証して、メッセージがクライアントによって作成および署名されていることを保証することが可能で、セッションキーは、サーバのみによって復号化されてもよい。デジタル封筒およびデジタル署名についての適用可能なフォーマットについての説明に関しては、「ＰＫＣＳ ＃７： Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｅｓｓａｇｅ Ｓｙｎｔａｘ Ｓｔａｎｄａｒｄ」、Ｖｅｒｓｉｏｎ １．５、ＲＳＡラボラトリーズ テクニカルノート、１９９３年１１月１日を参照のこと。
【００３５】
続いて、サーバは、クライアントのデジタル署名を検証してセッションキーを復号化した後にセッションキーを受け付けて、その後、安全な応答を生成し（ステップ４１６）、これはクライアントへ返される（ステップ４１８）。その後、クライアントは、クライアント認証トークンを生成および暗号化して（ステップ４２０）、クライアント認証トークンをサーバへ安全に送信する（ステップ４２２）。受信したメッセージからクライアント認証トークンを抽出した後に、サーバは、クライアントを認証して、応答を生成し（ステップ４２４）、これはクライアントへ返される（ステップ４２６）。その後、クライアントは、応答を分析して、クライアントがサーバによって確かに認証されているか、またはサーバはクライアントの認証要求を拒絶しているかを判断し（ステップ４２８）、処理を終える。
【００３６】
上記のように、図４は、既知のＧＳＳ‐ＡＰＩ対応の機構に係る安全な通信コンテキストを確立するための典型的な一方法を示している。対照的に、本明細書における取り組みは、残りの図面に関して本明細書において以下に説明するように、安全な通信コンテキストを確立するための改良された公開鍵に基づくＧＳＳ‐ＡＰＩ対応の機構に向けられている。
【００３７】
図５を今度は参照すると、本発明の一実施形態に係るクライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。処理は、例えば、クライアントがサーバアプリケーションに結びつこうとする場合など、サーバの公開鍵証明書を取得するための要求をクライアント５０２がサーバ５０４へ送ることで開始する（ステップ５０６）。当該要求を受信すると、サーバは、当該要求を処理して、サーバの公開鍵証明書のコピーを含むまたは伴う応答を作成し（ステップ５０８）、これは要求クライアントへ返される（ステップ５１０）。
【００３８】
サーバのデジタル証明書を受信後、クライアントは、サーバの公開鍵証明書を確認して、信頼できる認証局によって署名されていることを保証する（ステップ５１２）。注意すべきなのは、クライアントは、このサーバの公開鍵証明書のコピーを予め確認および記憶してることを認識してもよく、これによって、クライアントは、ローカルキャッシュから検索してサーバの証明書を取得することができる。代わりに、例えば、ディレクトリまたは同様のデータ記憶部からサーバの公開鍵証明書を検索することを通じてといった何らかの他のやり方で、サーバの公開鍵証明書をクライアントへ提供してもよい。
【００３９】
サーバの証明書が確かに検証されているとすると、クライアントは、サーバの公開鍵を証明書から抽出して、それをキャッシュする。その後、クライアントは、ランダム対称秘密鍵を認証トークンと共に生成する（ステップ５１４）。この特定の秘密鍵を、本明細書においてはトランスポートキーと称する。認証トークンは、ユーザ名‐パスワードの対、主要認証者からのタイムスタンプが記録されたセキュアチケット、クライアントに関連した公開鍵証明書、または他の認証情報を備えてもよい。クライアントは、適時、セキュアチケットなどのデータ項目を単にコピーすることによって認証トークンを生成してもよい。
【００４０】
その後、クライアントは、トランスポートキーと認証トークンとをサーバへ送信する（ステップ５１６）。クライアントからサーバへのトランスポートキーおよび認証トークンの送信は、サーバの公開鍵を使用する暗号化を通じた何らかのやり方で保護される。例えば、トランスポートキーおよび認証トークンは、サーバの公開鍵を使用して暗号化されて、サーバへ送られるメッセージ上でデジタル封筒を形成してもよい。代わりに、トランスポートキーおよび認証トークンは、個別に暗号化されて、サーバへのメッセージに含まれてもよい。
【００４１】
安全なメッセージをクライアントから受信すると、サーバは、デジタル封筒をサーバの秘密鍵で復号化する。その後、サーバは、サーバへ送られている認証トークンの種類にとって適切な処理を使用して、すなわち、クライアントによってサーバへ送られている認証トークンの種類に基づいて、クライアントまたはクライアントのユーザを認証する（ステップ５１８）。例えば、サーバは、ユーザ名‐パスワードの対に対してＬＤＡＰルックアップを行ってもよく、または、例えばカーベロスチケットなどのセキュアチケットを確認してもよい。認証トークンがクライアント証明書である場合には、本物のクライアントのみがクライアント証明書内の公開鍵に関連した秘密鍵で復号化できるクライアント公開鍵（デジタル封筒）で暗号化されたランダムセッションキーでサーバが応答すると、認証は達成される。デジタル封筒は、攻撃中の人物を阻止するためにクライアントがサーバへ送るトランスポートキーで暗号化されたまま、送られる。クライアントが認証されたとすると、サーバは、クライアントとサーバとの間で作成されている通信コンテキスト内のメッセージを保護するために使用されるであろうランダム対称秘密鍵を生成する（ステップ５２０）。この特定の秘密鍵を、本明細書においてはセッションキーと称する。
【００４２】
その後、サーバは、セッションキーをクライアントへ安全に送信する（ステップ５２２）。クライアントからサーバへのセッションキーの送信は、トランスポートキーを使用する暗号化を通じた何らかのやり方で保護される。例えば、サーバは、セッションキーを、サーバがトランスポートキーで暗号化するセッショントークンに配置してもよい。その後、サーバは、暗号化されたセッショントークンを、サーバがクライアントの公開鍵で捺印するメッセージに配置してもよく、その後、結果生じた封筒をトランスポートキーで暗号化する。代わりに、サーバは、クライアントに送るべきメッセージに暗号化されたセッションキーを配置する前に、トランスポートキーを使用してセッションキーを個別に暗号化してもよい。安全なメッセージを生成する他の例として、サーバは、トランスポートキーを使用して、セッションキーを含むメッセージ上にデジタル封筒を生成してもよい。
【００４３】
メッセージを受信後、クライアントは、トランスポートキーを使用してメッセージの適切な部分を復号化してセッションキーを抽出し（ステップ５２４）、これによって処理を終わらせる。使用された認証機構によっては、サーバは、互いに異なる形式のメッセージを生成している場合もある。よって、クライアントは、セッショントークンから直接セッションキーを取得することがあり、または、サーバがクライアントの公開鍵も使用してセッションキーを暗号化した場合またはセッションキーを含むメッセージの一部を暗号化した場合には、クライアントは、セッションキーをクライアントの秘密鍵で復号化する必要がある場合もある。加えて、クライアントとサーバとの間のメッセージは、再生攻撃に対する保護のために、通し番号を含んでもよい。
【００４４】
処理が終わった後、クライアントおよびサーバは共に、クライアントとサーバとの間のメッセージを保護するために後に使用できるセッションキーのコピーを所有し、これによって、クライアントとサーバとの間の通信コンテキストに対して、データの機密性およびデータの完全性を安全に保証する。例えば、クライアントは、セッションキーを使用して、サーバによって制御されるリソースをアクセスする要求をサーバに安全に送ってもよい。クライアントとサーバとの間の所定の通信セッションに対してセッションキーを使用してもよいこと、クライアントとサーバとの間の所定の通信セッションは、クライアントとサーバとの間、または、本発明の好ましい一実施形態であるＧＳＳ‐ＡＰＩ対応の機構によって提供される安全なコンテキスト内または何らかの他の機構によって提供される安全なコンテキスト内の他のサーバ間、あるいはその両方である、他の安全な通信セッションと同時並行であってもよいこと、および、所定の通信セッションはこれらの同時並行セッションの継続が許可されている間に終了されてもよいことが、当業者によって理解されるべきである。
【００４５】
本取り組みの利点は、上述の詳細な説明の観点から明確であるはずである。安全な通信コンテキストを確立するための従来技術であるＧＳＳ‐ＡＰＩ対応の機構と比較して、本発明の好ましい実施形態は、従来実施されてきたユーザ名‐パスワード型のソリューションとしての同一のＧＳＳ‐ＡＰＩ対応の機構を使用し続けながら、必要に応じて、ユーザ名‐パスワード型のクライアント‐サーバ認証動作から完全な公開鍵インフラストラクチャ（ＰＫＩ）によるソリューションへ拡張する機能を提供する。加えて、本発明の好ましい実施形態によって、クライアントは、ＬＩＰＫＥＹでは許可されていない、公開鍵証明書の使用による認証を行うことができる。さらに、本発明の好ましい実施形態によって、ＳＰＫＭでは対応していない、ユーザ名‐パスワード、セキュアチケット、または公開鍵証明書などの様々なクライアント認証機構が可能となる。さらに、本発明の好ましい実施形態は、ＬＩＰＫＥＹと比較して、ネットワークトラフィックおよび暗号化動作を最小限にする。例えば、ＬＩＰＫＥＹでは６つのメッセージが交換されるのに対して、４つのメッセージがクライアントとサーバとの間で交換される。
【００４６】
完全に機能するデータ処理システムのコンテキストにおいて本発明の好ましい実施形態を説明してきたが、本発明の好ましい実施形態の処理は、分散を実行するために実際に使用される特定の種類の信号記録媒体に関係なく、コンピュータ読み取り可能な媒体および様々な他の形式における命令の形式で分散されうることが、当業者にとっては当然であることに注意するのが重要である。コンピュータ読み取り可能な媒体の例には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピー（Ｒ）ディスク、ハードディスクドライブ、ＲＡＭ、およびＣＤ−ＲＯＭ、ならびに、デジタルおよびアナログ通信リンクなどの送信型媒体が含まれる。
【００４７】
方法とは、一般的に、自己矛盾のない、所望の結果を導く一連のステップであると考えられる。これらのステップは、物理量の物理的な操作を必要とする。通常、必ずしもそうではないものの、これらの量は、記憶、転送、結合、比較、およびそうでなければ操作可能な電気的または磁気的信号の形式を取る。主に一般的な使用上の理由から、このような信号をビット、値、パラメータ、項目、要素、オブジェクト、記号、文字、期間、または数値などと称するのが時には便利である。しかしながら、これらの用語または類似の用語は、適切な物理量に関連付けられるべきものであり、これらの量に対して適用した便利なラベルに過ぎないことに注意すべきである。
【００４８】
本発明の好ましい実施形態の説明を例示の目的で提示してきたが、網羅的なものでも、開示された実施形態に限定しようとするものでもない。数多くの修正および変形が当業者にとっては明らかだろう。
【図面の簡単な説明】
【００４９】
【図１】それぞれ本発明の好ましい実施形態を実施しうるデータ処理システムの典型的なネットワーク、当該データ処理システム内で使用されうる典型的なコンピュータアーキテクチャを示す。
【図２】個人がデジタル証明書を取得する典型的なやり方を示すブロック図である。
【図３】データ処理システムに対して認証すべきデジタル証明書をエンティティが使用しうる典型的なやり方を示すブロック図である。
【図４】クライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。
【図５】本発明の一実施形態に係るクライアントとサーバとの間で安全な通信コンテキストを確立するための典型的なＧＳＳ‐ＡＰＩ対応の機構を示すデータフロー図である。
【特許請求の範囲】
【請求項１】
第１のシステムと第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立するために前記第２のシステムによって実行される方法であって、
前記第１のシステムは、第２の公開鍵証明書を確認することが可能であり、
前記第２のシステムは、公開鍵を含む第１の公開鍵証明書を確認することが可能であり、前記第２の公開鍵証明書に関連した秘密鍵を使用し、
前記方法は、
前記第１の公開鍵証明書を取得するステップと、
非対称鍵であるトランスポートキーを生成するステップと、
前記トランスポートキーと前記第２の公開鍵証明書を備える認証トークンとを前記公開鍵で保護された第１のメッセージに配置するステップと、
前記第１のメッセージを前記第２のシステムから前記第１のシステムへ送るステップと、
前記第１のメッセージを前記第１のシステムへ送信することに応答して、前記トランスポートキーで保護された第２のメッセージを前記第１のシステムから受信するステップと、
非対称鍵であるセッションキーを前記第２のメッセージから抽出するステップと、
前記第１のシステムへ送られる後続のメッセージを保護するために前記セッションキーを使用するステップと、
前記第２の公開鍵証明書に含まれる公開鍵を用いて前記第１のシステムにより作成され、前記セッションキーを含む前記第２のメッセージ内のデジタル封筒を復号化するステップと
を含む方法。
【請求項２】
第１のシステムと第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立するために前記第１のシステムによって実行される方法であって、
前記第２のシステムは、公開鍵証明書を確認することが可能であり、
前記方法は、
前記第１のシステムに関連した公開鍵証明書を提供するステップと、
前記第１のシステムに関連した前記公開鍵証明書からの公開鍵で保護されており、対称秘密鍵であるトランスポートキーと前記第２のシステムに関連した第２の公開鍵証明書を備える認証トークンとを含む第１のメッセージを前記第２のシステムから受信するステップと、
前記認証トークンに基づいて前記第２のシステムを認証するステップと、
対称秘密鍵であるセッションキーを生成するステップと、
前記セッションキーを前記トランスポートキーで保護された第２のメッセージに配置するステップと、
前記第１のメッセージを受信したことに応答して、前記第２のメッセージを前記第２のシステムへ送るステップと、
前記セッションキーで保護された後続のメッセージを前記第２のシステムから受信するステップと、
前記第２のシステムに関連した前記公開鍵証明書に含まれる公開鍵を使用するによって、前記セッションキーを含む前記第２のメッセージ内にデジタル封筒を作成するステップと
を含む方法。
【請求項３】
コンピュータに請求項１に記載の方法を実行させるコンピュータ・プログラム。
【請求項４】
コンピュータに請求項２に記載の方法を実行させるコンピュータ・プログラム。
【請求項５】
第１のシステムとの間でメッセージを通信するための安全なコンテキストを確立する第２のシステムであって、
前記第１のシステムは、第２の公開鍵証明書を確認することが可能であり、
前記第２のシステムは、公開鍵を含む第１の公開鍵証明書を確認することが可能であり、前記第２の公開鍵証明書に関連した秘密鍵を使用し、
前記第２のシステムは、さらに、
前記第１の公開鍵証明書を取得する手段と、
非対称鍵であるトランスポートキーを生成する手段と、
前記トランスポートキーと前記第２の公開鍵証明書を備える認証トークンとを前記公開鍵で保護された第１のメッセージに配置する手段と、
前記第１のメッセージを前記第２のシステムから前記第１のシステムへ送る手段と、
前記第１のメッセージを前記第１のシステムへ送信することに応答して、前記トランスポートキーで保護された第２のメッセージを前記第１のシステムから受信する手段と、
非対称鍵であるセッションキーを前記第２のメッセージから抽出する手段と、
前記第１のシステムへ送られる後続のメッセージを保護するために前記セッションキーを使用する手段と、
前記第２の公開鍵証明書に含まれる公開鍵を用いて前記第１のシステムにより作成され、前記セッションキーを含む前記第２のメッセージ内のデジタル封筒を復号化する手段と
を含むシステム。
【請求項６】
第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立する第１のシステムであって、
前記第２のシステムは、公開鍵証明書を確認することが可能であり、
前記第１のシステムは、さらに、
前記第１のシステムに関連した公開鍵証明書を提供する手段と、
前記第１のシステムに関連した前記公開鍵証明書からの公開鍵で保護されており、対称秘密鍵であるトランスポートキーと前記第２のシステムに関連した第２の公開鍵証明書を備える認証トークンとを含む第１のメッセージを前記第２のシステムから受信する手段と、
前記認証トークンに基づいて前記第２のシステムを認証する手段と、
対称秘密鍵であるセッションキーを生成する手段と、
前記セッションキーを前記トランスポートキーで保護された第２のメッセージに配置する手段と、
前記第１のメッセージを受信したことに応答して、前記第２のメッセージを前記第２のシステムへ送る手段と、
前記セッションキーで保護された後続のメッセージを前記第２のシステムから受信する手段と、
前記第２のシステムに関連した前記公開鍵証明書に含まれる公開鍵を使用するによって、前記セッションキーを含む前記第２のメッセージ内にデジタル封筒を作成する手段と
を含む方法。
【請求項１】
第１のシステムと第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立するために前記第２のシステムによって実行される方法であって、
前記第１のシステムは、第２の公開鍵証明書を確認することが可能であり、
前記第２のシステムは、公開鍵を含む第１の公開鍵証明書を確認することが可能であり、前記第２の公開鍵証明書に関連した秘密鍵を使用し、
前記方法は、
前記第１の公開鍵証明書を取得するステップと、
非対称鍵であるトランスポートキーを生成するステップと、
前記トランスポートキーと前記第２の公開鍵証明書を備える認証トークンとを前記公開鍵で保護された第１のメッセージに配置するステップと、
前記第１のメッセージを前記第２のシステムから前記第１のシステムへ送るステップと、
前記第１のメッセージを前記第１のシステムへ送信することに応答して、前記トランスポートキーで保護された第２のメッセージを前記第１のシステムから受信するステップと、
非対称鍵であるセッションキーを前記第２のメッセージから抽出するステップと、
前記第１のシステムへ送られる後続のメッセージを保護するために前記セッションキーを使用するステップと、
前記第２の公開鍵証明書に含まれる公開鍵を用いて前記第１のシステムにより作成され、前記セッションキーを含む前記第２のメッセージ内のデジタル封筒を復号化するステップと
を含む方法。
【請求項２】
第１のシステムと第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立するために前記第１のシステムによって実行される方法であって、
前記第２のシステムは、公開鍵証明書を確認することが可能であり、
前記方法は、
前記第１のシステムに関連した公開鍵証明書を提供するステップと、
前記第１のシステムに関連した前記公開鍵証明書からの公開鍵で保護されており、対称秘密鍵であるトランスポートキーと前記第２のシステムに関連した第２の公開鍵証明書を備える認証トークンとを含む第１のメッセージを前記第２のシステムから受信するステップと、
前記認証トークンに基づいて前記第２のシステムを認証するステップと、
対称秘密鍵であるセッションキーを生成するステップと、
前記セッションキーを前記トランスポートキーで保護された第２のメッセージに配置するステップと、
前記第１のメッセージを受信したことに応答して、前記第２のメッセージを前記第２のシステムへ送るステップと、
前記セッションキーで保護された後続のメッセージを前記第２のシステムから受信するステップと、
前記第２のシステムに関連した前記公開鍵証明書に含まれる公開鍵を使用するによって、前記セッションキーを含む前記第２のメッセージ内にデジタル封筒を作成するステップと
を含む方法。
【請求項３】
コンピュータに請求項１に記載の方法を実行させるコンピュータ・プログラム。
【請求項４】
コンピュータに請求項２に記載の方法を実行させるコンピュータ・プログラム。
【請求項５】
第１のシステムとの間でメッセージを通信するための安全なコンテキストを確立する第２のシステムであって、
前記第１のシステムは、第２の公開鍵証明書を確認することが可能であり、
前記第２のシステムは、公開鍵を含む第１の公開鍵証明書を確認することが可能であり、前記第２の公開鍵証明書に関連した秘密鍵を使用し、
前記第２のシステムは、さらに、
前記第１の公開鍵証明書を取得する手段と、
非対称鍵であるトランスポートキーを生成する手段と、
前記トランスポートキーと前記第２の公開鍵証明書を備える認証トークンとを前記公開鍵で保護された第１のメッセージに配置する手段と、
前記第１のメッセージを前記第２のシステムから前記第１のシステムへ送る手段と、
前記第１のメッセージを前記第１のシステムへ送信することに応答して、前記トランスポートキーで保護された第２のメッセージを前記第１のシステムから受信する手段と、
非対称鍵であるセッションキーを前記第２のメッセージから抽出する手段と、
前記第１のシステムへ送られる後続のメッセージを保護するために前記セッションキーを使用する手段と、
前記第２の公開鍵証明書に含まれる公開鍵を用いて前記第１のシステムにより作成され、前記セッションキーを含む前記第２のメッセージ内のデジタル封筒を復号化する手段と
を含むシステム。
【請求項６】
第２のシステムとの間でメッセージを通信するための安全なコンテキストを確立する第１のシステムであって、
前記第２のシステムは、公開鍵証明書を確認することが可能であり、
前記第１のシステムは、さらに、
前記第１のシステムに関連した公開鍵証明書を提供する手段と、
前記第１のシステムに関連した前記公開鍵証明書からの公開鍵で保護されており、対称秘密鍵であるトランスポートキーと前記第２のシステムに関連した第２の公開鍵証明書を備える認証トークンとを含む第１のメッセージを前記第２のシステムから受信する手段と、
前記認証トークンに基づいて前記第２のシステムを認証する手段と、
対称秘密鍵であるセッションキーを生成する手段と、
前記セッションキーを前記トランスポートキーで保護された第２のメッセージに配置する手段と、
前記第１のメッセージを受信したことに応答して、前記第２のメッセージを前記第２のシステムへ送る手段と、
前記セッションキーで保護された後続のメッセージを前記第２のシステムから受信する手段と、
前記第２のシステムに関連した前記公開鍵証明書に含まれる公開鍵を使用するによって、前記セッションキーを含む前記第２のメッセージ内にデジタル封筒を作成する手段と
を含む方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００７−５１８３２４（Ｐ２００７−５１８３２４Ａ）
【公表日】平成１９年７月５日（２００７．７．５）
【国際特許分類】
【出願番号】特願２００６−５４８３００（Ｐ２００６−５４８３００）
【出願日】平成１７年１月５日（２００５．１．５）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５００３２
【国際公開番号】ＷＯ２００５／０６９５３１
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成１９年７月５日（２００７．７．５）
【国際特許分類】
【出願日】平成１７年１月５日（２００５．１．５）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５００３２
【国際公開番号】ＷＯ２００５／０６９５３１
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]