JP5062870B2

JP5062870B2 - 任意通信サービスのセキュリティ確保

Info

Publication number: JP5062870B2
Application number: JP2002520469A
Authority: JP
Inventors: クリスティアンイェールマン，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2000-08-11
Filing date: 2001-07-05
Publication date: 2012-10-31
Anticipated expiration: 2021-07-05
Also published as: CN1446418A; SE0002962D0; US20040103316A1; SE0002962L; SE517116C2; CN100342684C; WO2002015466A1; JP2004507156A; AU2001271177A1; US7457956B2

Description

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

Claims

定義済みのセキュアな関係を有していない、クライアントと希望サービスを提供するサーバとの間にセキュア通信を確立する方法であって、
前記クライアントと前記サーバは、任意のデータの電子署名及び検証をサポートする共通コンピューティング・プラットフォームを有し、
第１の伝送で、認証された鍵交換を前記サーバと行うためのアルゴリズム・プロキシと、前記サーバの公開鍵を証明する証明書を含むデータ・パッケージであって、電子署名がなされた前記データ・パッケージを前記サーバから前記クライアントにダウンロードし、
前記クライアントは、前記電子署名に対応する前記クライアントが信用する前記サーバの公開鍵に基づいて、ダウンロードした前記データ・パッケージの前記電子署名を検証し、
第２の伝送で、前記クライアントは、前記クライアントの公開鍵を含む証明書を前記サーバに返信し、
前記クライアント及び前記サーバは、共有鍵を生成し、
前記クライアントは、前記アルゴリズム・プロキシを実行することにより、前記共有鍵を生成し、
前記共有鍵を用いて、前記クライアントと前記サーバとの間の通信を暗号化する、
ことを特徴とする方法。
相互認証のために、入力としていくつか任意のデータを有すると共に出力として当該データ及び前記クライアントが付加するラベルの電子署名を有するセキュリティ機能の実施を前記ダウンロードしたデータ・パッケージが前記クライアントに求める、ことをさらに特徴とする請求項１記載の方法。
前記ラベルが、要求されるサービス及びタイム・スタンプを識別するテキストである、ことを特徴とする請求項２記載の方法。
前記共通コンピューティング・プラットフォームが、Ｊａｖａ仮想マシン及びＪａｖａバイト・コード・コンピューティング言語である、ことを特徴とする請求項１ないし３のいずれかに記載の方法。
前記サーバの公開鍵として、鍵交換サーバから提供される、いくつかのサービスとの通信を保護するためのグループ・マスタ・キーが用いられることを特徴とする請求項１ないし４のいずれかに記載の方法。
定義済みのセキュアな関係を有していない、クライアントと希望サービスを提供するサーバとの間にセキュア通信を確立するシステムであって、
前記クライアントと前記サーバは、任意のデータの電子署名及び検証をサポートする共通コンピューティング・プラットフォームを有し、
第１の伝送で、認証された鍵交換を前記サーバと行うためのアルゴリズム・プロキシと、前記サーバの公開鍵を証明する証明書を含むデータ・パッケージであって、電子署名がなされた前記データ・パッケージを前記サーバから前記クライアントにダウンロードする手段と、
前記クライアントは、前記電子署名に対応する前記クライアントが信用する前記サーバの公開鍵に基づいて、ダウンロードした前記データ・パッケージの前記電子署名を検証する手段と、
第２の伝送で、前記クライアントは、前記クライアントの公開鍵を含む証明書を前記サーバに返信する手段と、
前記クライアント及び前記サーバは、共有鍵を生成する手段と、
前記クライアントにおける前記生成する手段は、前記アルゴリズム・プロキシを実行することにより、前記共有鍵を生成し、
前記共有鍵を用いて、前記クライアントと前記サーバとの間の通信を暗号化する手段と、
を有することを特徴とするシステム。
相互認証のために、いくつか任意のデータを有すると共に出力として当該データ及び前記クライアントが付加するラベルの電子署名を有するセキュリティ機能の実施を前記クライアントに求める手段を前記ダウンロードしたデータ・パッケージが有する、ことをさらに特徴とする請求項６記載のシステム。
前記ラベルが、要求されるサービス及びタイム・スタンプを識別するテキストである、ことを特徴とする請求項７記載のシステム。
前記共通コンピューティング・プラットフォームが、Ｊａｖａ仮想マシン及びＪａｖａバイト・コード・コンピューティング言語である、ことを特徴とする請求項６ないし８のいずれかに記載のシステム。
前記サーバの公開鍵として、鍵交換サーバから提供される、いくつかのサービスとの通信を保護するためのグループ・マスタ・キーが用いられることを特徴とする請求項６ないし９のいずれかに記載のシステム。