JP5507462B2 - 異なる組織に属する複数のユーザのためのクレデンシャルの複製を行わない認証方法 - Google Patents

Description

本発明は、ユーザがインターネットにアクセスできるようにするための方法であって、ユーザは、第１の組織のゲートウェイを介してインターネットアクセス要求を送信し、上記要求は、認証クレデンシャルを上記第１の組織に供給することにより上記ユーザが認証処理を開始することを要求し、上記アクセス要求の後で、上記ゲートウェイは上記ユーザを上記第２の組織のウェブページにリダイレクトして上記認証処理を完了する方法に関する。特に、本発明は、ユーザがインターネットにアクセスする可能性を増大させることを目的とする。

インターネットは、現在では、多くの人々にとって必要不可欠な仕事道具となり、さらに、無線ネットワーク（例えばＷＬＡＮ）のおかげで、ユーザはオフィスの外からでもインターネットにアクセスすることができる。例えば、空港、駅、及び図書館は、ホットスポット、すなわちユーザがゲートウェイを介してインターネットに接続できるアクセスポイントを有している。所与の組織のホットスポット内において、このサービスへのアクセスは、通常、当該組織に登録された有効なアカウントを有するユーザにのみ許可される。従って、所与の組織のユーザは、関心が持たれていないか又はインフラストラクチャに障害が発生していることに起因してその組織によってカバーされていないエリアでは、インターネットにアクセスすることができない。

米国特許第５，８９８，７８０号明細書。

これらの問題を克服するために、第１の組織のユーザが第２の組織のアクセスポイントを介してインターネットにアクセスできるようにする、いくつかの解決方法が考えられている。使用されるプラットホームに関連して、これらの解決方法のうちの一部は、ずっと複雑な構成のユーザクライアントを必要とすることがある。使いやすさ及びクライアントの構成に関して好ましい他の解決方法は、許可されたユーザのリストに含まれていないユーザを異なる組織の認証サーバにリダイレクトすることによって、ゲートウェイレベルのみで動作する。

後者の解決方法のうちの１つが特許文献１で知られている。ここでは、ユーザがアカウントを持たないローカルなインターネットサービスプロバイダ（ＩＳＰ）を用いることで、当該ユーザが遠隔の場所からインターネットにアクセスできるようにするための方法及び装置を開示している。ユーザは、遠隔のＩＳＰに対する彼／彼女のアカウントのクレデンシャル（credentials；認証情報又は視覚情報。例えば、ユーザ名及びパスワード）を用いて、ローカルなＩＳＰのシステムに署名する。ローカルなＩＳＰのサーバは、ローカルなＩＳＰのサーバを識別できるようにする情報をユーザによって入力されたクレデンシャルが含んでいることを認識し、ユーザがローカルなＩＳＰを介してインターネットにアクセスすることを許可するための質問を後者に送信する。

しかしながら、この解決方法には、ユーザの機密データ（ユーザ名及びパスワード）がローカルなＩＳＰのサーバに供給され、よってこのデータが盗聴（sniffing）攻撃にさらされるかもしれないという欠点が存在する。

特許文献１から知られるものとは正反対の哲学に存する解決方法が、トレント大学によって用いられ、Ｕｎｉ−ｆｙの名前で公に提供されている。この解決方法によれば、ユーザクライアントが大学のゲートウェイにＤＨＣＰ要求を送信し、次いでゲートウェイがユーザクライアントにＩＰアドレスを割り当てることが想定される。ゲートウェイは、いくつかのファイアーウォールルールを有し、ファイアーウォールルールのそれぞれは、データパケットを送信しているユーザが許可されたユーザのリストに含まれているか否かに依存する２つの可能なアクションを有する。ユーザが許可されたユーザのリストに含まれていない場合には、データパケットは、許可を行うゲートキーパーに向けてルーティングされる。「キャプティブポータル（captive portal）」型の方法によれば、許可されていないユーザは、ローカルなウェブページにリダイレクトされ、ここで、彼／彼女は、彼／彼女が許可を受けようとする組織を選択することができる。この時点で、ユーザクライアントは、選択された組織と通信状態にされ、その組織によって要求されるプロトコルに従って認証手順が実行される。この解決方法によれば、トレント大学のネットワーク機器は、いかなる意味でも、ユーザの機密データを知ることはできず、かつ知る必要もなく、ユーザの機密データはすべて、選択された組織に直接送られる。認証に成功すると、選択された組織は、許可要求を大学のゲートキーパーに送信し、ゲートキーパーは、ユーザの状態を不許可から許可に変更し、これにより、彼／彼女がインターネットにアクセスできるようにする。

この解決方法には、（例えば安全又は課金の目的で）接続されたユーザを認識することが容易ではなく、ユーザの仮名（pseudonym）と遠隔の認証組織に登録されたユーザの身元情報との関連付けを必要とするという欠点がある。さらに、ユーザが認証を受けようとする組織が手動で選択されるということは、大学のゲートウェイがすべての既存の認証組織を認識していることを想定し、さらに、すべての各認証組織の認証手順におけるすべての変化について常に更新されることを想定しているので、この解決方法では、システムのスケーラビリティが大幅に制限される。認証組織の個数が増大すると、大学のシステム管理の複雑さも大幅に増大する。

本発明の主な目的は、ユーザが初めから認証（accredit）を得ているのではない組織のゲートウェイを介して当該ユーザがインターネットにアクセスできるようにするための代替の方法を提供することにより、従来技術の欠点を克服することにある。

この目的は、添付の請求の範囲に示した技術的特徴を含む方法を用いて達成される。添付の請求の範囲を、本願の主要部であるものとする。

本発明は、認証クレデンシャルが供給される瞬間（及び受領者）を分離するという着想に基づいている。特に、この着想は、ユーザが第１の組織のゲートウェイに接続してインターネットアクセス要求を送信するときに、このゲートウェイが、ユーザを第２の組織に対して認証するために必要とされるクレデンシャルの一部を供給するというものである。例えば、ユーザは、ユーザ名と第２の組織の識別子とを提供してもよい。このような要求を受信したゲートウェイが、そのユーザを認証されたユーザとして認識しなかった場合には、そのユーザを、彼／彼女の認証のために第２の組織のウェブページにリダイレクトする。この時点で、ユーザは、上記ウェブページを介して、彼／彼女の識別のために必要とされるさらなるクレデンシャルを第２の組織に供給し、これにより、第２の組織は、ユーザの身元情報を検証し、彼／彼女がインターネットをナビゲートできるようにする。

この解決方法は、いくつかの利点をもたらす。

まず第１に、ユーザは、インターネットアクセス要求において提供されるクレデンシャルを用いて第１の組織によって識別されることが可能であり、よって、公の安全又は課金の理由でユーザを識別することを簡単化することができる。それにもかかわらず、第１の組織には、ユーザのクレデンシャルのすべてが与えられるわけではなく、このことにより、本解決方法は盗聴攻撃に対してずっと頑健になる。

第２に、本発明の方法に係る機能を実行可能なコンピュータシステム（特にネットワークノード及びサーバ）を単に追加することによって組織の集合体に新たな組織を追加することができるので、本解決方法はスケーラブルな構築が容易である。

ユーザから第１の組織に供給されるクレデンシャルは、ウェルカムウェブページにおいて入力され、ユーザ名を「名前＠レルム」の形式で含むことが有利である。ここで、レルム（realm）は、第２の組織のドメイン名を表す。指定されたレルムに基づいて、各ゲートウェイは、ＤＮＳに送られた要求によって、又は、集合体に属する組織の認証サーバのすべてを含み、ゲートウェイレベルで格納されたリストとの比較によって、ユーザが属する組織の認証サーバを発見することができる。

異なる組織のゲートウェイ及び認証サーバ間の通信が認証されることを保証するために、シグナリングメッセージは、公開鍵及び秘密鍵の両方を用いるＰＧＰ（Pretty Good Privacy）（登録商標）によって用いられるもののような非対称暗号アルゴリズムを用いて、署名されることが有利であり、また、符号化されることが好ましい。

新たな組織が追加された（又は除去された）ときの鍵交換の管理を簡単化する目的で、アーキテクチャには鍵管理サーバが含まれることが有利である。新たな組織が追加される毎に、関連付けられた認証サーバの公開鍵が、このサーバ上で公開される。複数の組織のゲートウェイが、各自の鍵リストを更新するために、安全な通信プロトコル（例えばＨＴＴＰＳ）を用いて定期的にそれにコンタクトをとる。鍵リストをゲートウェイレベルで格納することは、鍵管理サーバにおいていかなる障害が生じようともサービスが脅かされることがないということを保証する。最悪の場合でも、新たな認証サーバは数時間の遅れの後でシステムに追加される。鍵管理サーバは、複数の組織のゲートウェイのすべてによって、それらゲートウェイのすべてに存在する鍵管理サーバ自体の公開鍵を用いて認証され、外部のユーザに、許可なく彼／彼女自身の組織への入力をさせることはない。

複数の組織のうちの任意のものに属するユーザがインターネットにアクセスできるようにする組織の集合体を示す。 第１の組織に属するユーザが第２の組織のアクセスポイントを介してインターネットにアクセスできるようにする手順の概略図である。

本発明のさらなる目的及び利点は、限定的ではない実施例として示し以下の詳細な説明及び添付の図面から明らかになるであろう。

ここで図１を参照すると、インターネット１に接続された組織（Ｅ１、Ｅ２、Ｅ３）の集合体を示している。ここでの説明の目的で、用語「組織（Organization）」は、ユーザによるインターネットへのアクセスを許可することができる任意のエンティティ、又は構造化されたユーザ管理システムを取り扱う任意のエンティティを示す。

図１の例では、組織Ｅ１及びＥ２は、コンピュータシステムを備え、特に、ゲートウェイＧＷを含むネットワークノードと、認証サーバＡＳと、組織のユーザを認証するために必要とされる情報を含むデータベースＤＢとを備える。ゲートウェイＧＷは、すべてのファイヤーウォール機能を実行し、許可されていないすべてのトラフィックをフィルタリングし、その一方、認証サーバＡＳは、ユーザのクレデンシャルを、データベースＤＢ（ＭｙＳＱＬもしくはＬＤＡＰデータベース、又はパスワードファイル）において、又は例えばＲＡＤＩＵＳ等の標準的なプロトコルを用いて検証する。図１の例では、組織Ｅ２はアクセスポイント３を備え、このアクセスポイント３を介してユーザに無線アクセスを提供する。組織Ｅ１はスイッチ４を備え、スイッチ４は、ゲートウェイＧＷに接続され、ユーザに有線アクセスを提供する。

組織Ｅ３は、それ自体のアクセスネットワークを持たないがそれ自体のユーザを有するインターネットサービスプロバイダ（ＩＳＰ）である。この組織は、組織Ｅ１及びＥ２と同様に認証サーバＡＳ及びデータベースＤＢを備え、認証サーバＡＳは、ルータＲＴを介してインターネットに接続される。ルータＲＴは、組織Ｅ１及びＥ２のゲートウェイＧＷとは異なり、上述のようなユーザリダイレクト機能を実行することはできない。当然ながら、ルータＲＴはゲートウェイＧＷで置き換えられてもよいが、このような場合、ゲートウェイＧＷの機能の一部は未使用にされる。

図１及び図２の例をさらに参照すると、ユーザ２は、組織Ｅ１の許可されたユーザ（すなわち、ドメインに属するユーザ）であり、彼／彼女が認証されていない組織Ｅ２に対してウェブ要求を送信する。この状況は、例えば、組織Ｅ１のユーザ（例えば会社ＡＬＦＡの従業員）が空港又は他の組織（例えば会社ＢＥＴＡ）の近くに存在して、空港又は会社ＢＥＴＡのインフラストラクチャを用いてインターネットにアクセスしようとする場合に生じる可能性がある。ユーザ２が組織Ｅ２のホットスポットの存在を確かめると、彼／彼女はＤＨＣＰ要求を送信し、この後、彼／彼女にはＩＰアドレスが割り当てられる。この時点で、ユーザ２はインターネットアクセス要求を送信することができる。ゲートウェイＧＷは、この要求を受けてクライアントをウェルカムページにリダイレクトし、このウェルカムページにおいて、ユーザは、組織Ｅ１に対する彼／彼女の認証のために必要とされる彼／彼女のクレデンシャルの一部を入力する。本発明によれば、組織Ｅ２に供給されるクレデンシャルは、ユーザが認証を受けようとする組織、すなわちここで説明する例では組織Ｅ１についての情報を少なくとも含む。好ましくは、これらのクレデンシャルは、ユーザ２のユーザ名と、ユーザ２を認証しなければならない組織Ｅ１のドメイン名とからなる。ユーザ名及びドメイン名は、別個のフィールドにそれぞれ入力されてもよく、又は、ユーザ２がアカウントを「名前＠レルム」の形式で入力するように要求される場合には、ユーザ名及びドメイン名は、ゲートウェイによって自動的に取得されることが可能である。ここで、「名前」はユーザ２のユーザ名であり、「レルム」は組織Ｅ１のドメイン名を表す。ユーザによって供給されたクレデンシャルを用いることで、組織Ｅ２は、ユーザ２を認証させるために組織Ｅ１とコンタクトをとることができる。

組織Ｅ１の認証サーバのＩＰアドレスは、以下の階層的なルールによって決定される。

まず第１に、組織Ｅ２のゲートウェイＧＷは、予め決められた名前（例えばauthserv）をレルムの前に配置して、ユーザの本来の認証サーバＡＳ（すなわち組織１の認証サーバ）のＩＰアドレスを知るための要求をＤＮＳに送信する。例えば、ユーザ「mario.rossi@organization1.it」の場合、ゲートウェイＧＷは、ＤＮＳにおいて「authserv.organization1.it」のＩＰアドレスを検索する。レルムの前に配置される名前は、同じ組織の集合体に属する各組織のすべての認証サーバについて同じであり、よって、ゲートウェイによってＤＮＳに送信される質問は、簡単な方法で定式化可能である。ＤＮＳから肯定的な応答が受信されたとき、ゲートウェイＧＷは、ユーザ２を組織Ｅ２の認証サーバにリダイレクトし、検索に失敗したときには、処理は次のルールに進む。

次のルールによれば、組織Ｅ１の認証サーバＡＳのＩＰアドレスが、組織Ｅ２のローカルデータベースにおいて検索される。本発明によれば、複数の組織のゲートウェイＧＷのすべては、ドメインと、対応する認証サーバのＩＰアドレスとのリストを、ローカルデータベースに格納している。このリストは、予め定義された中央サーバによって定期的に更新される。この中央サーバは、好ましくは、組織の集合体の全体にわたって共通である。

データベースにおける検索に失敗した場合には、ウェブ要求を受信したゲートウェイは最後のルールに切り換え、この最後のルールにより、ユーザは、ゲートウェイをインストールしたときにすでにセットアップされたデフォルトの認証サーバにリダイレクトされる。この最後のルールは、本質的には、インターネットアクセス要求においてユーザにより明示的に指定されたいかなる情報も存在しないことを、予め定義された組織に関する情報として認識させる。言い換えると、ユーザ２が、彼／彼女が認証を受けようとする組織１のドメインを指定することなく、彼／彼女の名前のみをゲートウェイＧＷに供給した場合には、ゲートウェイは、この情報を、デフォルトの組織に対して認証を受けようとしているものとして解釈する。

いったん認証サーバが発見されると、ゲートウェイはクライアントを認証サーバにリダイレクトし、ユーザは彼／彼女自身のパスワードを入力することによって認証され、よって、ＮｏＣａｔシステムのような「キャプティブポータル」システムによって提供されるもののような標準的な認証手順に戻る。ユーザ名及びパスワードの検証に成功した場合、認証サーバは許可メッセージをユーザ２のクライアントに送信し、このメッセージは次いで、ゲートウェイＧＷにリダイレクトされる。ゲートウェイＧＷは、ユーザのプロファイルに含まれたサービスを提供するように必要なファイヤーウォールルールを実施し、次いで、ユーザを、最初に要求されたウェブページにリダイレクトする。

上述の手順は図２に例示され、ここでは、ユーザ２のクライアントと、組織Ｅ２のゲートウェイと、組織Ｅ１の認証サーバと、組織Ｅ１によって許可されたすべてのユーザの身元情報を格納する組織Ｅ１のデータベースとの間の通信を示す。

図２を参照すると：
・ クライアントは、ウェブ要求、例えば「http://www.google.it」を送信する（シーケンスｃ１）。
・ ゲートウェイは上記要求を受けてクライアントを認証ポータルにリダイレクトする（シーケンスｃ２）。
・ クライアントは、そのクレデンシャル、例えばユーザ名を送信する（シーケンスｃ３）。
・ ゲートウェイはクライアントを認証サーバのポータルにリダイレクトする（シーケンスｃ４）。
・ ユーザはパスワードを入力する（シーケンスｃ５）。
・ 認証サーバは、ユーザのクレデンシャル（ユーザ名及びパスワード）をデータベースに含まれたものと比較することによって、例えばＲＡＤＩＵＳプロトコルを用いて、ユーザのクレデンシャルを検証する（シーケンスｃ６）。
・ ユーザが許可される（シーケンスｃ７）。
・ 認証サーバは、認証の確認として、ファイヤーウォール開メッセージをクライアントに送信する（シーケンスｃ８）。
・ クライアントは、ファイヤーウォールを開くために、受信されたメッセージをゲートウェイに転送する（シーケンスｃ９）。
・ ゲートウェイは、クライアントを、要求されたサイト「http://www.google.it」にリダイレクトする（シーケンスｃ１０）。
・ クライアントは、インターネットの要求したサイト「http://www.google.it」にアクセスする（シーケンスｃ１１）。

このタイプのアーキテクチャは、絶対的なシステムスケーラビリティをもたらす。実際、このシステムは、新たな組織ＥＸにおいてゲートウェイＧＷを設けることと、新たなドメイン（例えば「organizationX.it」）に属するユーザを管理する認証サーバをＤＮＳに登録することとによって、容易に拡張可能である。上述の理由に起因して、ＤＮＳへの登録は、上述の形式、例えば「authserv.organizationX.it」で行われなければならない。

他のいかなるシステムも認証サーバに成り代わって未登録のユーザを認証しようとすることがないように、認証サーバとゲートウェイとの間の通信は署名されることが有利である。特に、通信は、公開鍵／秘密鍵のタイプの非対称暗号法を用いて署名され、好ましくは符号化される。好ましくは、メッセージの署名のみが行われるとき、メッセージはクリアのままであるが、秘密鍵を用いて計算されたハッシュがそれに添付され、これにより、いったん公開鍵を用いて検証されると、メッセージが秘密鍵の所有者によって作成されたオリジナルであることを保証する。このように交換されるメッセージは、例えばＰＧＰソフトウェアを用いて得られる鍵（署名のための秘密鍵、符号化のための公開鍵）を用いて署名され、好ましくは符号化される。

各ゲートウェイＧＷは、組織の集合体の認証サーバＡＳの公開鍵のリストを含み、よって、各ゲートウェイＧＷは、認証を盗聴しようとしている偽の認証サーバが存在しないことを検証することができる。スケーラビリティの制限なしにシステムを更新し続けるために、システムによって認識される認証サーバに属する公開鍵のレポジトリ（例えばＰＧＰ）を含む鍵管理サーバ（図１のＫＳ）が使用される。従って、新たな組織を追加することは、新たなドメインを管理する認証サーバＡＳの鍵をこのリストに入力することを含む。各ゲートウェイは鍵リストの複製を含む。システムを更新し続けるために、本発明の方法によれば、ゲートウェイは定期的に、鍵管理サーバＫＳを調べて鍵リストをダウンロードする。システムに新たな認証サーバが追加されたとき、新たな組織のユーザが当該ユーザのクレデンシャルをシステムの他のドメインとのローミングモードでは使用することができない最初の一時的期間が存在する。この期間は、すべてのゲートウェイにおいてローカルな鍵の複製が更新されるまで継続する。従って、この使用不可状態は、新たな組織の導入のみに関連し、かつ限定され、ネットワークの保守には無関係である。各ゲートウェイがすべての組織の認証サーバの公開鍵のリストの複製を含むので、システムは、鍵管理サーバＫＳが不調又は故障の際であっても動作し続ける。

インターネットアクセスに関与するすべてのゲートウェイが、各ユーザの接続時間に関する情報を含み、それを特別なログに保持しなければならないので、このように考えられたシステムは、異なる組織のユーザのトラフィックの課金を管理できるようになる。上記情報は、ユーザ名と各組織との両方を含み、よってトラフィックは正しく課金されるようになる。

上述のメカニズムは、複数の組織にわたって信頼ポリシーが存在することを想定している。制御メカニズムが必要とされる場合には、ユーザの接続に関する情報を他のすべてのサーバから受信する中央サーバを使用し、よって各ゲートウェイに格納された接続を検証できるようにすることが好ましい。

上述の実施形態が本発明の非限定的な例として理解されるべきであること、また、添付の請求の範囲において特定された本発明の保護範囲から離れることなくシステムに多数の変更を実施可能であるということは明らかである。例えば、ゲートウェイと、認証サーバと、認証データベース（例えばＳＱＬデータベース）とは、１つのマシンとして実装されてもよく、または多数のマシンにわたって分散型で構成されてもよい。さらに、認証サーバとゲートウェイとの間の通信又は認証サーバとクライアントとの間の通信を符号化するために使用される方法は、従来技術で知られた任意のタイプのものであってもよい。

Claims (15)

1. 第１のコンピュータシステム及び第２のコンピュータシステムを含む複数のコンピュータシステムを用いてユーザがインターネットにアクセスできるようにするための方法であって、
   上記第１のコンピュータシステムは上記インターネットにアクセス可能であり、上記第１のコンピュータシステムは、上記ユーザの認証先ではないゲートウェイを備え、
   上記第２のコンピュータシステムは上記ユーザを認証し、上記第２のコンピュータシステムは、ユーザ入力のためのウェブページを提供し、
   上記ユーザは、上記ユーザが認証処理を開始することを要求するインターネットアクセス要求を上記ゲートウェイを介して送信し、
   上記ユーザは、上記ユーザを上記第２のコンピュータシステムに対して認証するために必要とされる認証クレデンシャルの第１の部分を上記ゲートウェイに供給し、
   上記ゲートウェイは、上記ユーザを上記第２のコンピュータシステムの上記ウェブページにリダイレクトし、
   上記ユーザは、上記ユーザを上記第２のコンピュータシステムに対して識別させるために必要な上記認証クレデンシャルの第２の部分を、上記ウェブページを介して上記第２のコンピュータシステムに供給し、
   上記第２のコンピュータシステムは、上記ユーザが認証されたことを上記ゲートウェイに通知し、
   上記ゲートウェイは、上記アクセス要求の後で、上記インターネットにアクセスする許可を上記ユーザに付与し、
   上記認証クレデンシャルの第１の部分は、上記ユーザを識別する「名前」と上記第２のコンピュータシステムを識別する「レルム」とを含むユーザ名を含み、
   上記認証クレデンシャルの第２の部分はパスワードを含むことを特徴とする方法。
2. 上記ユーザ名は「名前＠レルム」の形式で表された請求項１記載の方法。
3. 上記インターネットアクセス要求を送信することは、
   上記ユーザにＩＰアドレスを割り当てる第１のステップと、
   上記ゲートウェイにより、上記ユーザが上記認証クレデンシャルの第１の部分を入力しなければならないローカルなウェルカムウェブページに上記ユーザをリダイレクトする第２のステップとを含む請求項１又は２記載の方法。
4. 上記第２のコンピュータシステムは認証サーバを備え、
   上記ゲートウェイが上記認証サーバを発見できない場合、上記ゲートウェイは上記認証クレデンシャルの第１の部分を認証用デフォルトサーバに送信する請求項１〜３のうちのいずれか１つに記載の方法。
5. 上記第２のコンピュータシステムは認証サーバを備え、
   上記ゲートウェイは上記認証クレデンシャルの第１の部分を上記認証サーバに送信する請求項１〜３のうちのいずれか１つに記載の方法。
6. 上記ゲートウェイは、ＤＮＳに送信された質問を用いて上記認証サーバのアドレスを決定する請求項５記載の方法。
7. 上記ゲートウェイは、上記複数のコンピュータシステムのリストに対するアクセスを有し、上記リストを上記認証クレデンシャルの第１の部分と比較することにより上記認証サーバのアドレスを決定する請求項５又は６記載の方法。
8. 上記ゲートウェイと上記認証サーバとの間の通信は署名される請求項４〜７のうちのいずれか１つに記載の方法。
9. 上記ゲートウェイと上記認証サーバとの間の通信は符号化される請求項４〜８のうちのいずれか１つに記載の方法。
10. 上記ゲートウェイと上記認証サーバとの間の通信は、公開鍵／秘密鍵符号化を用いて符号化される請求項９記載の方法。
11. 対応する上記複数のコンピュータシステムの複数の認証サーバの公開鍵のリストを鍵管理サーバが保持する請求項１０記載の方法。
12. 上記複数のコンピュータシステムのゲートウェイは、上記鍵管理サーバに定期的に接続し、上記公開鍵のリストをローカルに格納する請求項１１記載の方法。
13. 請求項１〜１２のうちのいずれか１つに記載の方法を実施するように適応された、上記複数のコンピュータシステムを含むシステム。
14. コンピュータのメモリエリアに格納されるように適応されたコンピュータプログラムであって、上記コンピュータによって実行されたとき、請求項１〜１２のうちのいずれか１つに記載の方法に係るゲートウェイに関連付けられたステップを実施するように適応されたコード部分を含むコンピュータプログラム。
15. コンピュータのメモリエリアに格納されるように適応されたコンピュータプログラムであって、上記コンピュータによって実行されたとき、請求項４〜１２のうちのいずれか１つに記載の方法に係る認証サーバに関連付けられたステップを実施するように適応されたコード部分を含むコンピュータプログラム。

Images