(57)【要約】本発明は、オ−プン・システムでの情報のセキュリティ確保に関し、より具体的には任意の通信サ−ビスの認証、機密性及び完全性の保護を提供する方法及びシステムに関する。特定のサ−ビスとの通信を望むクライアントは、認証がなされた鍵交換をそのサ−ヒ゛スと行うために必要なコ−ドを含む署名されたプログラム・コ−ドをそのサ−ビスからダウンロ−ドする。クライアントは、公開鍵アルゴリズムを一方向性のハッシュ関数と共に用いることにより任意のデ−タに署名をする機能と任意のデ−タの公開鍵署名を検証する機能の、２つの基本的な暗号に関する機能だけをサポ−トするものとする。鍵交換とデ−タ通信の保護に必要なセキュリティ・プロトコルをダウンロ−ドできるようにすることにより、クライアントないしサ−バがサポ−トする必要のある予め定義されたセキュリティ機能の数が制限される。これにより、サ−バのプログラムだけがアップデ−トを必要とするので、通信の保護をアップデ−トすることがより一層容易にもなる。【選択図】図２
2004507156.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとサーバの間にセキュア通信チャネルを設定する方法であって、任意のデータの電子署名及び検証をサポートする共通コンピューティング・プラットフォームを前記クライアントと前記サーバが有し、
認証がなされた鍵交換を前記サーバと行うための手順を含む電子署名がなされたデータ・パッケージを前記サーバから前記クライアントにダウンロードし、
前記クライアントにおいてダウンロードしたデータ・パッケージの前記電子署名の検証を行い、
当該検証が正当であったときに前記共通コンピューティング・プラットフォーム上で前記ダウンロードしたデータ・パッケージを実行する
ことを特徴とする方法。
【請求項２】
相互認証のために、入力としていくつか任意のデータを有すると共に出力として当該データ及び前記クライアントが付加するラベルの電子署名を有するセキュリティ機能の実施を前記ダウンロードしたデータ・パッケージが前記クライアントに求める、ことをさらに特徴とする請求項１記載の方法。
【請求項３】
前記ラベルが要求されるサービス及びタイム・スタンプを識別するテキストである、ことを特徴とする請求項２記載の方法。
【請求項４】
前記共通コンピューティング・プラットフォームがＪａｖａ仮想マシン及びＪａｖａバイト・コード・コンピューティング言語である、ことを特徴とする請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記サーバがいくつかのサービスとの通信を保護するためのグループ・マスタ・キーを提供する鍵交換サーバである、ことを特徴とする請求項１ないし４のいずれかに記載の方法。
【請求項６】
クライアントとサーバの間にセキュア通信チャネルを設定するシステムであって、任意のデータの電子署名及び検証をサポートする共通コンピューティング・プラットフォームを前記クライアントと前記サーバが有し、
認証がなされた鍵交換を前記サーバと行うための手順を含む電子署名がなされたデータ・パッケージを前記サーバから前記クライアントにダウンロードする手段と、
前記クライアントにおいてダウンロードしたデータ・パッケージの前記電子署名の検証を行う手段と、
当該検証が正当であったときに前記共通コンピューティング・プラットフォーム上で前記データ・パッケージを実行する手段と
を有することを特徴とするシステム。
【請求項７】
相互認証のために、入力としていくつか任意のデータを有すると共に出力として当該データ及び前記クライアントが付加するラベルの電子署名を有するセキュリティ機能の実施を前記クライアントに求める手段を前記ダウンロードしたデータ・パッケージが有する、ことをさらに特徴とする請求項６記載のシステム。
【請求項８】
前記ラベルが要求されるサービス及びタイム・スタンプを識別するテキストである、ことを特徴とする請求項７記載のシステム。
【請求項９】
前記共通コンピューティング・プラットフォームがＪａｖａ仮想マシン及びＪａｖａバイト・コード・コンピューティング言語である、ことを特徴とする請求項６ないし８のいずれかに記載のシステム。
【請求項１０】
前記サーバが、いくつかのサービスとの通信を保護するグループ・マスタ・キーを提供する手段を有する鍵交換サーバである、ことを特徴とする請求項６ないし９のいずれかに記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、概してオープン通信システムにおける情報の保護ないし保全をするセキュリティ確保に関する。また、本発明は、より具体的には任意の通信サービスの認証、機密性及び完全性の保護を提供する方法及びシステムに関する。
【０００２】
（関連技術の説明）
オープン通信システムでは、情報のセキュリティを確保する必要性がある。これには、通信ピアの認証並びにデータの機密性及び完全性の保護が含まれる。認証とは、各エンティティが自ら主張する者であることを保証し、あるいは、伝送された情報が権限のない者によって改竄されていないことを保証するために、何等かの手段が提供されることを意味する。機密性とは、基本的には権限のないエンティティは誰も我々のメッセージを読み取ることができないということを意味し、また、データの完全性とは、我々のメッセージが変更されていないことと、メッセージ・ストリーム全体が同じ供給源から来ることと、メッセージ・ストリーム全体が同じ宛先へ行くこととを確保することである。
【０００３】
これらの類の問題に対する解決策は、暗号の研究から得られる。暗号のアルゴリズムは、秘密に保ちないしは保護する必要がある入力としての１つの値ともう１つ別の入力としての秘密の値とを有する機能ないし写像であるのが典型的である。その秘密の値は、よくアルゴリズムの秘密鍵（シークレット・キー）と呼ばれている。現代のセキュア通信システムは、周知の暗号アルゴリズムを利用しているものが多く、セキュリティをアルゴリズム自体ではなくて秘密鍵に基づいて確保するようにしている。実際の鍵だけを敵対する者から秘密に保つという前提は、Ｋｅｒｋｈｏｆｆの前提と呼ばれる。多くの異なるベンダーに製造された多くの異なる場所にある機器ないし装置が相互に動作する必要のあるインターネットのようなオープン通信システムにおいては、このＫｅｒｋｈｏｆｆの前提が重要になる。どのようにデータを処理するかの方法が公然と知られていれば、通信の作業を行うことはより一層容易となる。このため、すべてのインターネット通信のセキュリティ技術は、Ｋｅｒｋｈｏｆｆの前提を基盤として、すなわち、秘密鍵の値に基づくセキュリティを伴った周知の暗号アルゴリズムを基盤として、構築されている。
【０００４】
セキュア通信チャネルを設定するためには、どのメッセージを通信ピアの間で交換すべきかを示す予め定義された何等かのプロトコルがなければならない。通信システムのセキュリティ確保においては、認証がなされた鍵交換ないし認証付きの鍵交換を提供することが必要な段階として挙げられる。鍵交換は、例えばＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）アルゴリズムやＲｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ（ＲＳＡ）アルゴリズム等の公開鍵アルゴリズムを用いることによって行われるのが典型的である。ＤＨアルゴリズムは、例えばインターネット鍵交換プロトコル（ＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ））、トランスポート・レイヤ・セキュリティ・プロトコル（ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ ｐｒｏｔｏｃｏｌ））及びセキュア・シェル・プロトコル（ＳＳＨ（Ｓｅｃｕｒｅ Ｓｈｅｌｌ Ｐｒｏｔｏｃｏｌ））等で用いられ、ＲＳＡアルゴリズムは、例えばＴＬＳ等で用いられる。
【０００５】
ＳＳＨ、ＴＬＳ及びインターネット・プロトコル・セキュリティ（ＩＰｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ））／ＩＫＥのようなオープン・セキュリティ・プロトコルにおいて、公開鍵アルゴリズムは、データにデジタル形式での電子的な署名をしたり鍵交換をしたりするのに用いられる。鍵交換方法に加えて、それぞれの異なる公開鍵署名方法が用いられることもある。それらのプロトコルにおいては、ペイロード・データの暗号化と完全性チェック・タグの付加に用いられる基本的なプロトコルは非常に類似している。しかし、認証手順、鍵交換及び各プロトコルがサポートする様々な対称アルゴリズムはかなり異なっている。このため、予め定義されたセキュアな関係を持たない２つのユニットがセキュアに相互動作できるようにする必要がある場合には、通信ピアのうちの少なくとも１つが非常に多数の異なる暗号アルゴリズム及びセキュリティ・オプションをサポートしなければならないという問題がある。さらに、異なるオプションが多数あるということは、鍵のネゴシエーション・プロトコルを極めて大規模で複雑なものにし、かつ、明らかに実現が困難なものにする。
【０００６】
ＵＳ ５，８９２，９０４には、コンピュータ・ネットワーク（例えばインターネット）を通じて受信されるコンピュータ・プログラム、実行可能ファイル若しくはコードの真正性及び完全性を保証する方法が記載されている。その方法の一実施形態は、実行可能ファイルの暗号ダイジェストないし「ハッシュ」を決定することと、その暗号ダイジェストによって発行者署名を形成することとを含んでいる。発行者署名は、この技術分野ではよく知られているように、ＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）公開鍵アルゴリズム等の公開−秘密鍵署名アルゴリズムを用いて形成される。発行者署名には、発行者署名を発給した発行者の本人認証をするために発行者の電子証明書が添付される。その電子証明書には、ソフトウェアの発行者名、発行者がファイルに署名をするのに用いた秘密鍵（プライベート・キー）に対応する公開鍵、証明書の有効期限、及び認証機関へのリンクないしハイパーリンクが含まれる。
【０００７】
ＷＯ ９９／５６４２８では、プロセッサ内にプログラムを当該プロセッサの外部にある装置からダウンロードする別のセキュアな方法が記載されている。そのプログラムは、暗号化され得るものとなっており、かつ、それに対して付加される認証情報を有し得るものとなっている。当該プロセッサは、そのプログラムを当該プロセッサで実行することを許可する前に、そのプログラムの復号及び認証を行う。
【０００８】
ＷＯ ９９／３３２２４は、例えば画像や音声のデータを含むデータ・ストリームが認可された受信者だけにしか受信できないことを保証する方法及びシステムを開示している。その受信者は、受信した画像や音声のデータ・パケットの数を証明することもできる。これは、データ・ストリーム中で送られるすべてのデータ・パケットを暗号化すると共に受信者において復号したパケットの数をログとして記録することによってなされる。
【０００９】
予め定義されたセキュリティ関係を有していない２つの通信ピアの間でどのようにしてセキュア通信チャネルを確立するかについては、これらの文献のいずれにおいても記載されていない。かかる状況は、例えばアド・ホック・ネットワーク（ａｄ ｈｏｃ ｎｅｔｗｏｒｋｓ）、すなわち、ＢｌｕｅｔｏｏｔｈＴＭ、ＳａｌｕｔａｔｉｏｎＴＭ、ＪｉｎｉＴＭ等において、共通する状況である。したがって、クライアントと任意の通信サービスとの間でどのようにしてセキュアな通信を確立するかを示した方法及びシステムが求められるところである。
【００１０】
（発明の要約）
本発明は、予め定義されたセキュアな関係を有していない２つの通信ピアの間の通信チャネルにセキュリティを確保するという課題に対しての解決策を提供する。
【００１１】
最新の技術におけるプロトコルでは、２つのユニットが相互動作できるようにする必要がある場合に通信ピアのうちの少なくとも１つが非常に多数の異なる暗号アルゴリズム及びセキュリティ・オプションをサポートしなければならず、鍵のネゴシエーション・プロトコルが大規模で複雑なものになる。
【００１２】
そこで、本発明は、必要とされる予め定義された暗号アルゴリズムの数を可能な限り少なくした解決策を提供することを目的の１つとしている。
【００１３】
また、本発明の他の目的は、サポートされるオプション及び暗号アルゴリズムの数によって決まる鍵のネゴシエーション・プロトコルの複雑さを低減することである。
【００１４】
さらに他の目的は、輸出制限の問題を軽減した解決策を提供することである。
【００１５】
上述の目的は、基本的に、通信クライアントが通信をすることを望む特定のサービスから、認証がなされた鍵交換をサーバと行うための必要なアルゴリズムを含む署名されたコンピュータ・プログラム（例えばＪｉｎｉＴＭプロキシ）をダウンロードすることによって達成される。さらに、前記コンピュータ・プログラムは、セキュアなサービスのセッションにおいて前記クライアントと前記サービスの間で送られるすべてのデータの暗号化及び保護をするのに必要とされる必須のアルゴリズムを含んでいる。
【００１６】
より具体的には、本発明は、通信クライアントが特定のサービスとの通信を望む場合のセキュリティ通信状況に関する。前記サービスに対しては、前記クライアントがインターネット等のグローバル・ネットワークを利用して到達することができ、あるいは、前記クライアントがローカル・ネットワークを利用して到達することもでき、さらには、前記クライアントがアド・ホック・ネットワーク、すなわち、たまたま物理的に同じ場所に存在することとなったエンティティ間で急に新設されるネットワークを利用してでも到達することができる。また、前記サービスを利用するすべてのユニットは、共通コンピューティング・プラットフォームを使用するものとする。すなわち、すべてのユニットは、共通の言語で書かれたプログラムのダウンロードと実行をすることができるものとする。かかるコンピューティング・プラットフォーム及びコンピューティング言語で一般的に広く使用態勢が整っているものの一例としては、ＪａｖａＴＭ仮想マシン及びＪａｖａＴＭバイト・コード・コンピューティング言語が挙げられる。前記クライアントについては、任意のデータに電子署名をすることができるという能力と任意のデータの電子署名を検証することができるという能力の、予め定義された暗号に関する能力を２つだけ有するものであることを前提とする。
【００１７】
セキュア通信サービスの提供を望むサーバは、公開鍵の対における自身の秘密鍵（プライベート・キー）を用いて、前記サーバとの認証がなされた鍵交換のための必要なアルゴリズムを含むコンピュータ・プログラムに電子署名をする。前記サーバは、署名したコードを、前記署名と共にまとめ（パッケージにし）、さらにオプションとして前記サーバの公開鍵を証明する１つ又はいくつかの証明書も共にしてまとめる。前記サーバの公開鍵は、その後、前記サーバが署名したコードを検証するのに利用することができる。
【００１８】
サービスとの通信を望むクライアントは、ネットワークを通じて、署名されたコードと含めることが可能な証明書とを伴うパッケージをダウンロードし、そして、ダウンロードしたパッケージの署名をチェックする。その署名に対応する信用のある公開鍵を前記クライアントが保持しているとき、あるいは、含められた証明書の中に含まれる公開鍵のいくつかを前記クライアントが信用するときには、前記クライアントは、ダウンロードしたコードを信用のあるセキュリティ・コードとして取り扱う。
【００１９】
前記セキュリティ・コードは、その後、前記クライアントの共通コンピューティング・プラットフォーム上で実行され、また、相互認証が望まれる場合に１つのセキュリティ機能の実施をクライアントに求めることもできる。その機能は、入力としていくつか任意のデータを有すると共に、出力として前記クライアントが付加した特定のラベルを加えた前記データの電子署名を有する。さらに、前記クライアントは、自身がした署名を検証するのに前記サービスが用いることのできる公開鍵を含んだ証明書を返送するものとしてもよい。サービス・コードは、その出所であるサーバと認証がなされた鍵交換を実施する。それが成功したときには、それが前記サーバとのセキュアな通信リンクを設定する。
【００２０】
本発明の第１の実施形態では、鍵交換のコード自体が署名されていることを利用し、それによって公開鍵の署名生成を１回分節約し、かつ、公開鍵の署名検証を１回分節約し、かつ、クライアントとサーバの間での伝送を１回分節約することにより、認証がなされた鍵交換をより効率的なものとしている。
【００２１】
本発明の第２の実施形態では、鍵交換が通信の保護からは分離されている。このアプローチによる利点は、それぞれのサービスが負担の大きい公開鍵交換を実施する必要がなく、１つのマスタ・キーを用いていくつかの異なるサービスを保護することができる点である。
【００２２】
鍵交換とデータ通信の保護に必要なセキュリティ・プロトコルのコードをダウンロードできるようにすることにより、クライアントないしサーバがサポートする必要のある予め定義された必要なセキュリティ機能の数は制限される。その代わりに、セキュリティ・コード自体に署名をすることによってセキュリティが保証される。これにより、プロトコルにおけるセキュリティの欠点が明らかになってきてプロトコルの全部若しくは一部を改訂しなければならない場合にアップデートする必要があるのはサーバのプログラムだけなので、新たなアルゴリズムによって通信の保護をアップデートすることがより一層容易にもなる。
【００２３】
クライアントが必要とする暗号に関する必須の機能は署名と署名の検証だけなので、これらの機能が制約されることも一般的にはないことから、通常は輸出の規定に関する問題も全くない。
【００２４】
（図面の簡単な説明）
これら及び他の本発明の目的及び利点ないし有利な効果は、添付図面を参照しつつ以下の詳細な説明を読むことによって、より十分に明らかとなるであろう。添付図面では、対応する部分を示すのに同様の参照符号を用いている。添付図面において、
図１は、基本的な通信の概要を示したものであり、
図２は、本発明の一実施形態のフローチャートを示したものであり、
図３は、鍵交換サーバを用いる採用可能な通信の概要を例示したものである。
【００２５】
（詳細な説明）
次に、図１を参照し、セキュリティ通信状況１００において本発明の説明をする。セキュリティ通信状況１００では、通信クライアント１１０が特定のサービスを提供するサーバ１２０との通信を望んでいる。サーバ１２０に対しては、クライアント１１０が通信網１３０を利用して到達することができ、通信網１３０は、例えばインターネット等のグローバル・ネットワーク、若しくはローカル通信網、又は場合によってはアド・ホック・ネットワークでもあり得る通信網となっている。さらに、それらのサービスを利用するすべてのユニットは、共通コンピューティング・プラットフォーム１４０を使用するものとする。すなわち、すべてのユニットは、共通の言語で書かれたコンピューティング・プログラムのダウンロードと実行をすることができるものとする。かかるコンピューティング・プラットフォーム及びコンピューティング言語で一般的に広く使用態勢が整っているものの一例としては、ＪａｖａＴＭ仮想マシン及びＪａｖａＴＭバイト・コード・コンピューティング言語が挙げられる。サービスを提供するユニット、すなわち、サーバ１２０は、ネットワーク内のそれぞれ異なるクライアント１１０が使用する言語及び共通コンピューティング・プラットフォームを十分認識する情報を有している。
【００２６】
次に、通信サービスへの接続を望む通信クライアントの一例としてＪａｖａＴＭのＪｉｎｉＴＭ技術を用いる場合について本発明の説明をする。ＪａｖａＴＭのＪｉｎｉＴＭ技術は、如何なるプランニング、インストレーションないし人間の介入をも要せずにコンピュータと機器が素早くアド・ホック・ネットワークを形成することを可能にする。それぞれの機器は、ネットワークにおける他の機器が利用することのできるサービスを提供する。また、それらの機器は、それぞれ自身のインタフェースも提供し、それらのインタフェースが信頼性と互換性を確保する。それぞれの機器及びサービスは検索サービスに登録され、そして、新たな機器がネットワークに入るときには、それらがディスカバリ・アンド・ジョイン（ｄｉｓｃｏｖｅｒｙ ａｎｄ ｊｏｉｎ）と呼ばれるアド−イン・プロトコル（ａｄｄ−ｉｎ ｐｒｏｔｏｃｏｌ）の手順を執る。サービスを利用するためには、人若しくはプログラムが検索サービスを利用してサービスの場所を探し出す。そのサービスのインタフェースは、検索サービスから要求をしている機器へとコピーされ、それがその機器において使用されることになる。このように、検索サービスは、サービスを探し求めるクライアントをそのサービスと接続する交換台のような働きをする。ダウンロード可能なＪｉｎｉＴＭプロキシにおいて各サービスが当該各サービスとの対話をするのに必要なすべてのものを提供することから互換性は確保されるので、サービスはどこで実施されても構わない。
【００２７】
無線アド・ホック・ネットワークでは、信用が中心的な問題の１つになる。媒体を信用することはできないので、暗号を用いることが唯一の選択肢となる。主な問題の１つとして、アド・ホックの各ノード間でセキュリティ関係のコンフィギュレーションが予めなされることは想定できないという点がある。アド・ホック・ネットワークにおけるすべてのノードが公開鍵の対を持っており、かつ、すべてのノードが他のノードの公開鍵をアド・ホック・ネットワーク内でセキュアな接続を実現するのに良好なものとみなすとすれば、任意の公開鍵を用いる認証を利用することはできる。
【００２８】
標準的なアプローチとは異なり、本発明においては、それぞれ異なる対称鍵暗号化ないしメッセージ認証子（ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ））のアルゴリズムの多数の組を必ずしもクライアントとサーバが共有することは前提としない。その代わりに、クライアントは、予め定義された暗号に関する能力を２つだけ有するものとする。すなわち、
−クライアントは、公開鍵アルゴリズムを一方向性のハッシュ関数と共に用いる　ことによって任意のデータに電子署名をすることができ、かつ、
−クライアントは、任意のデータの公開鍵署名の正当性を検証することができる。データに署名をするのに用いるアルゴリズムは、非常に少ない総数の採用可　能なアルゴリズムのうちから選択する。
【００２９】
任意のデータの署名ないし署名の検証に用いるソフトウェア・プログラムないしハードウェアは、物理的にクライアントに設置し、敵意を持つ者がそれを変更したり操作したりすることができないようにする。署名ないし署名の検証に用いるソフトウェアないしハードウェアは、すべて一貫して共通コンピューティング・プラットフォームを使用する必要があるわけではなく、例えば、代わりにコンピューティング・プラットフォームにおいて定義されたＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅｓ）を使用することもできる。
【００３０】
上述した暗号に関する能力を利用し、クライアントは、ＪｉｎｉＴＭプロキシをセキュアにダウンロードすることができ、かつ、そのＪｉｎｉＴＭプロキシを利用して自身のために認証及び鍵管理プロトコルを実行することができる。これにより、サービスに従属するセキュリティの解決策を利用する全面的な自由が与えられる。次に、図２のフローチャートを参照しつつ本発明の第１の実施形態について説明する。
【００３１】
あらゆる通信の開始に先立ち、サーバは、クライアントがダウンロードすることができるＪｉｎｉＴＭプロキシを用意する。また、サーバは、そのＪｉｎｉＴＭプロキシへの署名も行い、それによってクライアントが当該ＪｉｎｉＴＭプロキシの実行前に当該ＪｉｎｉＴＭプロキシの完全性及び出所を検証できるようにする。典型的な形態としては、ＪｉｎｉＴＭプロキシのコードには、サーバが保持する秘密鍵（プライベート・キー）に対応する公開鍵と、認証がなされた鍵交換をサーバと行うために必要な方法とが含まれる。
【００３２】
１．セキュア通信の提供を望むサーバは、共通プラットフォームのコンピュータ言語で書かれたコンピュータ・プログラム、すなわち、Ｊａｖａで書かれたコンピュータ・プログラムを保持する。ＪｉｎｉＴＭの項目として、前記サーバは、ＪｉｎｉＴＭプロキシを保持する。前記ＪｉｎｉＴＭプロキシは、認証がなされた鍵交換を前記サーバと行うために必要とされる必須のアルゴリズム及び方法を含んでいる。さらに、そのプロキシは、セキュアなサービスのセッションにおいてクライアントとサーバの間で送られるすべてのデータの暗号化及び保護をするのに必要とされる必須のアルゴリズムを含んでいる。ただし、そのプロキシは、暗号に関する演算処理を実施するのに必要なコードを必ずしもすべて含んでいるわけではない。その代わりに、そのプロキシは、（実現可能ないし好適であれば）共通プラットフォームにおいて定義されたＡＰＩを使用するものとしてもよい。
【００３３】
２．前記サーバは、自身の秘密鍵を用いて前記ＪｉｎｉＴＭプロキシに電子署名をする。その署名は、上述の予め定義されたアルゴリズム及びフォーマットを用いた演算処理によって生成する。これにより、その署名をクライアントが検証できることを確保する。
【００３４】
３．前記サーバは、署名したコードを前記署名と共にまとめ（パッケージにし）、さらにオプションとして前記サーバの公開鍵を証明する１つ又は２つ以上の証明書も含める。前記サーバの公開鍵は、前記サーバの真正性を検証するのに利用することができる。
【００３５】
ＪｉｎｉＴＭやこれに類似する環境においては、サービスを探し求めるクライアントが通信を開始する。サービスが見つかり次第、クライアントは、実行のためのサービス・プロキシをダウンロードし、その実行を開始する前にサービス・プロキシの真正性が検証される相違も共にダウンロードする。
【００３６】
４．クライアントは、Ｊｉｎｉ検索サービスを利用してサービスを探索する（２００）。
【００３７】
５．前記クライアントは、サービスを見つけ、かつ、そのサービスの利用を望む場合、そのサービスに対応するプロキシを署名及びオプションの証明書と共にダウンロードする（２１０）。
【００３８】
６．前記クライアントは、ダウンロードしたデータ・パッケージの署名を検証する。その署名に対応する信用のある公開鍵を前記クライアントが保持しているとき、あるいは、含められた証明書の中に含まれる公開鍵のいくつかを前記クライアントが信用するときには、前記クライアントは、ダウンロードしたコードを信用のあるコードとして取り扱う（２２０）。
【００３９】
７．前記プロキシの検証が正当であったときには、前記クライアントは、共通コンピューティング・プラットフォームを使用してダウンロードしたコードを実行する。実行時制約を適宜付加するものとしてもよく、特に、ダウンロードされるコードは、指定された以外の任意の他のサーバと通信ができるものである必要はない（２３０）。
【００４０】
ダウンロードされるコードは、相互認証が必要とされる場合に署名したチケットの生成をクライアントに求めるものとすることもできる。クライアントは、暗号に関する他の如何なる機能ないし写像を実施することをも拒否するものとしてもよい。チケットを生成する機能ないし写像は、いくつかの任意のデータを取ってチケットを出力し、そのチケットが基本的にはクライアントが付加した特定のラベルを加えたデータの電子署名となる。このラベルは、結果としてできる項目が常にチケットと認識されることを確保するために必要とされるものである。さらに、クライアントは、自身がした署名を検証するのに用いることができる公開鍵を含んだ証明書を返送するものとしてもよい。チケットのラベルは、クライアントがプロキシに要求したサービスを指定し、かつ、タイム・スタンプを示すのが典型的な形態である。ラベルは、クライアント・マシンがデータ及びラベルに電子署名をする前に、クライアント・マシンのユーザに対して表示する必要がある。ユーザは、その時にチケットへの署名を拒否することにしてもよい。このようにして、前記ＪｉｎｉＴＭプロキシと前記サーバは、以下のように互いに認証をすることが可能となる。
【００４１】
８．前記プロキシは、その出所であるサーバと認証がなされた鍵交換を実施する（２４０）。実際に用いるプロトコルは、基本的に任意の標準的な認証及び鍵交換プロトコルとすることができ、例えば、ＤＨやＲＳＡとすることもできる。前記ＪｉｎｉＴＭプロキシは、上述したチケットの署名を検証するための公開鍵を証明するクライアントからの証明書を要求するものとしてもよい。認証が成功したときには、前記プロキシが前記サーバとのセキュアな通信リンクを設定する（２５０）。
【００４２】
セキュリティ・コードを書き込むサービス・プロバイダは、自身が望む通りに鍵交換のアルゴリズムを実現することができるが、良好な暗号の原理に従うのが望ましい。セキュリティ・レベルは、そのようにしてサーバが用いるアルゴリズムに応じて決まる。
【００４３】
本発明の第１の実施形態では、鍵交換のコード自体がサーバによって署名されているということを利用して、公開鍵の署名生成を１回分節約し、かつ、公開鍵の署名検証を１回分節約し、かつ、クライアントとサーバの間での伝送を１回分節約している。これは、実際の鍵交換よりも前に鍵交換のコードの署名をチェックしていることから可能になっている。したがって、クライアントに対しては、サーバの公開鍵についての認証された情報が既に利用可能ないし入手可能になっている。例えば、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎを用いる場合では、サーバの公開鍵交換の値をサービス・コード中に含めることもできる。したがって、クライアントからサーバへのたった１度の送信によって鍵交換を実施することもでき、伝送を１回分節約することができる。
【００４４】
図３においては、本発明の第２の実施形態が例示してある。この第２の実施形態では、鍵交換が純粋な通信の保護からは分離されている。このアプローチによる利点は、それぞれのサービスが負担の大きい公開鍵交換を実施する必要がなく、１つのグループ・マスタ・キーを用いていくつかの異なるサービスを保護することができる点である。これにより、クライアント３００は、サービスを探索するのではなくて鍵交換サーバ３１０を探索するものとなっている。クライアント３００は、鍵交換サーバ３１０からグループ・マスタ・キーとそのキーについての識別子を受信する。その後、鍵交換サーバが設置されていた（鍵交換サーバの場所を探し出した）のと同じドメインにあるサービスの利用をクライアント３００が望む場合には、クライアントは、サービスを提供するサーバ３２０を探索し、サーバ３２０からパッケージをダウンロードし、そして、そのパッケージを共通コンピューティング・プラットフォーム３３０上で実行する。ダウンロードされるセキュリティ・コードでは、クライアント３００に対し、グループ・マスタ・キーの識別子を入力として有すると共にグループ・マスタ・キーを出力として有する１つのセキュリティ機能の実施を求めることもできる。鍵交換を行うときには、ダウンロードされたサービス・コードがグループ・マスタ・キーを使用する。
【００４５】
ここでは一例としてＪｉｎｉＴＭ技術を用いる場合について本発明の説明をしたが、各ノードに対して要求されることは、それらが共通コンピューティング・プラットフォームをサポートすること、すなわち、アド・ホック・ネットワークにおけるすべてのノードが共通の言語で書かれたプログラムのダウンロード及び実行をすることができるということと、署名の生成及び検証が可能であるということだけである。さらに、本発明は、例えば、セキュアＷＡＰ（Ｗｉｒｅｌｅｓｓ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ）−サービスを設定する場合、すなわち、セキュリティ・アルゴリズムを定義するプログラム・コードをダウンロードすることによる場合にも、利用することができる。
【００４６】
以上のように本発明の説明をしたが、本発明が多くの形態に変更ないし変形し得るのは明白であろう。かかる変更ないし変形は、本発明の範囲から逸脱しているとみなされるものではなく、さらに、当業者にとって自明であるようなかかる変形ないし修正のすべては、特許請求の範囲が及ぶ範囲内に含まれるものと解釈される。
【図面の簡単な説明】
【図１】基本的な通信の概要を示したものである。
【図２】本発明の一実施形態のフローチャートを示したものである。
【図３】鍵交換サーバを用いる採用可能な通信の概要を例示したものである。
【図１】
2004507156.tif 000003
【図２】
2004507156.tif 000004
【図３】
2004507156.tif 000005
【国際公開パンフレット】
2004507156.tif 000006
2004507156.tif 000007
2004507156.tif 000008
2004507156.tif 000009
2004507156.tif 000010
2004507156.tif 000011
2004507156.tif 000012
2004507156.tif 000013
2004507156.tif 000014
2004507156.tif 000015
2004507156.tif 000016
2004507156.tif 000017
2004507156.tif 000018
2004507156.tif 000019
2004507156.tif 000020
2004507156.tif 000021
2004507156.tif 000022
2004507156.tif 000023
2004507156.tif 000024
2004507156.tif 000025
2004507156.tif 000026
【国際調査報告】
2004507156.tif 000027
2004507156.tif 000028
2004507156.tif 000029