分散式の委任および検証のための方法、装置、およびシステム
分散式の委任および検証のための方法であって;サービス提供者が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、第1のサービス・ノードとの委任関係を確立すること;第1のサービス・ノードが、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス要求者との委任関係を確立すること;サービス要求者へと発行された委任情報を含んでいるサービス要求をサービス要求者から受信したときに、サービス提供者が、第1のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請すること;第1のサービス・ノードが、検証を実行すること;および第1のサービス・ノードによる検証が成功したときに、サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾すること;を含んでいる方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、委任(delegation)および検証(verification)のための方法、装置、およびシステムに関し、さらに詳しくは分散式の委任および検証のための方法、装置、およびシステムに関する。
【背景技術】
【0002】
ネットワークがますます普及するにつれて、サービス要求者は、ネットワークを介して無数のサービス提供者によって提供されるサービスを使用することができる。デバイスが他のデバイスと安全なサービスの共有を実行できるように、サービス提供者として機能するデバイスが、いくつかの他のデバイスに対して委任を実行し、次にこれらのデバイスが、別のデバイスに対して委任を実行でき、結果として、委任を受けたすべてのデバイスが、サービス要求者となって、サービス提供者によって提供されるサービスを使用することができる。この場合、すべてのデバイスの間の委任の関係を、中央のサーバによって集中的なやり方で直接的に管理することが可能である。
【0003】
しかしながら、特定の状況(例えば、制限されたネットワーク環境)のもとでは、必ずしもすべてのデバイスが中央のサーバへとアクセスできるわけではないため、このサービス共有を実行することができない。したがって、そのような状況のもとでは、分散的な管理を使用する必要がある。
【0004】
図1を参照すると、米国特許出願公開第20020073308号が、属性証明書を管理するための方法を開示している。この方法は、サービス提供者11、サービス要求者12、およびデータベース13を含むシステムにおいて使用するために適している。サービス提供者11が、委任元である。サービス要求者12が、委任先であり、属性証明書16を有している。データベース13が、サービス要求者12の公開鍵証明書17、および属性証明書16を発行しているオーソリティ(authority)の公開鍵証明書18を保存している。
【0005】
サービス提供者11が、サービス要求者12から属性証明書16を受信し、属性証明書16から公開鍵証明書ロケータ161を抽出する。公開鍵証明書ロケータ161は、サービス要求者12の公開鍵証明書17ならびに属性証明書16を発行しているオーソリティの公開鍵証明書18の位置を特定している。サービス提供者11は、公開鍵証明書ロケータ161を使用して、サービス要求者12の公開鍵証明書17ならびに属性証明書16を発行しているオーソリティの公開鍵証明書18をデータベース13から抽出し、抽出した公開鍵証明書17、18を使用して属性証明書16の検証を行う。検証に成功すると、サービス提供者11は、サービス要求者12に対し、管理されているリソースへのアクセスを属性証明書16に保存された権限属性に従って許可する。
【0006】
システムが、属性証明書を有する少なくとも1つのサービス・ノード(図示されていない)をさらに含んでいる場合、サービス提供者11が、おおもとの委任元であり、サービス要求者12が、最終的な委任先であり、サービス・ノードが、最初に中間の委任先として機能し、次いで、委任を受けた後に中間の委任元として機能する。委任の際に、サービス提供者11は、サービス・ノードおよびサービス要求者12の属性証明書を受信し、検証しなければならない。しかしながら、サービス・ノードの数が多くなると、サービス提供者11が、かなりの量の演算リソースを検証に費やさなければならない。
【0007】
図2を参照すると、米国特許出願公開第20040073801号が、縦列状の委任のための方法を開示している。この方法を、この方法がサービス提供者21、2つのサービス・ノード22、23、およびサービス要求者24を含むシステムにおいて使用される例を用いて、以下で説明する。この方法は、以下のステップ、すなわち
・サービス提供者21が、第1の委任トークンをサービス・ノード22へと送信するステップ、
・サービス・ノード22が、サービス提供者21へと応答を送信するステップ、
・サービス提供者21が、第1の委任トークンの署名(signature)を含んでいる第1の署名をサービス・ノード22へと送信するステップ、
・サービス・ノード22が、第2の委任トークンをサービス・ノード23へと送信するステップ、
・サービス・ノード23が、サービス・ノード22へと応答を送信するステップ、
・サービス・ノード22が、サービス・ノード22からの第2の委任トークンの署名と、サービス提供者21からの第1の委任トークンと、第1の委任トークンの署名とを含んでいる第2の署名を、サービス・ノード23へと送信するステップ、
・サービス・ノード23が、第3の委任トークンをサービス要求者24へと送信するステップ、
・サービス要求者24が、サービス・ノード23へと応答を送信するステップ、および
・サービス・ノード23が、サービス・ノード23からの第3の委任トークンの署名と、サービス・ノード22からの第2の委任トークンと、第2の委任トークンの署名と、サービス提供者21からの第1の委任トークンと、第1の委任トークンの署名とを含んでいる第3の署名を、サービス要求者24へと送信するステップ
を含んでいる。
【0008】
サービス要求者24は、サービス提供者21によって提供されるサービスの使用を望む場合、第3の署名を、検証のためにサービス提供者21へと送信しなければならない。
【0009】
この縦列状の委任方法においては、サービス提供者21およびサービス・ノード22、23の委任トークンならびに委任トークンの署名が、サービス要求者24への署名を生成すべく数珠繋ぎにされるため、サービス・ノードの数が多いと、結果として生成される署名がきわめて長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者21が、かなりの量の演算リソースを検証に費やさなければならない。
【0010】
米国特許出願公開第20040117623号が、セキュアな通信リンクの初期化の方法を開示している。この特許文献は、考え方において上述の特許出願公開第20040073801号に類似しているため、説明の目的のために、同じ図2および同じ参照番号を利用することにする。この方法を、この方法がサービス提供者21、2つのサービス・ノード22、23、およびサービス要求者24を含むシステムにおいて使用される例を用いて、説明する。この方法は、以下のステップ、すなわち
・サービス提供者21が、第1の鍵および関連の第1の要求データを含んでいる第1のトークンと、サービス提供者21の秘密鍵を第1の鍵および第1の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第1の認証データと、を含んでいる第1のメッセージを生成するステップ、
・サービス提供者21が、サービス・ノード22との共有の公知鍵を使用して第1のメッセージを暗号化するステップ、
・サービス提供者21が、セキュアな通信リンクを初期化すべく、暗号化した第1のメッセージをサービス・ノード22へと送信するステップ、
・サービス・ノード22が、サービス提供者21との共有の公知鍵を使用して、暗号化されている第1のメッセージを復号化するステップ、
・サービス・ノード22が、第2の鍵および関連の第2の要求データを含んでいる第2のトークンと、サービス・ノード22の秘密鍵を第2の鍵および第2の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第2の認証データと、第1のトークンと、第1の認証データと、を含んでいる第2のメッセージを生成するステップ、
・サービス・ノード22が、サービス・ノード23との共有の公知鍵を使用して第2のメッセージを暗号化するステップ、
・サービス・ノード22が、セキュアな通信リンクを初期化すべく、暗号化した第2のメッセージをサービス・ノード23へと送信するステップ、
・サービス・ノード23が、サービス・ノード22との共有の公知鍵を使用して、暗号化されている第2のメッセージを復号化するステップ、
・サービス・ノード23が、第3の鍵および関連の第3の要求データを含んでいる第3のトークンと、サービス・ノード23の秘密鍵を第3の鍵および第3の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第3の認証データと、第2のトークンと、第2の認証データと、第1のトークンと、第1の認証データと、を含んでいる第3のメッセージを生成するステップ、
・サービス・ノード23が、サービス要求者24との共有の公知鍵を使用して第3のメッセージを暗号化するステップ、
・サービス・ノード23が、セキュアな通信リンクを初期化すべく、暗号化した第3のメッセージをサービス要求者24へと送信するステップ、および
・サービス要求者24が、サービス・ノード23との共有の公知鍵を使用して、暗号化されている第3のメッセージを復号化するステップ
を含んでいる。
【0011】
サービス要求者24は、サービス提供者21によって提供されるサービスを使用する必要がある場合、第3のメッセージを、検証のためにサービス提供者21へと送信しなければならない。
【0012】
このセキュアな通信リンクの初期化の方法は、サービス提供者21およびサービス・ノード22、23のトークンならびに認証データを数珠繋ぎにしてサービス要求者24へのメッセージを生成するため、サービス・ノードの数が多いと、結果として生成されるメッセージが過剰に長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者21が、かなりの量の演算リソースを検証に費やさなければならない。
【発明の開示】
【0013】
したがって、本発明の目的は、分散式の委任および検証のための方法であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる方法を提供することにある。
【0014】
本発明の別の目的は、分散式の委任および検証のためのシステムであって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできるシステムを提供することにある。
【0015】
本発明のさらなる目的は、分散式の委任および検証のための装置であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる装置を提供することにある。
【0016】
したがって、本発明の分散式の委任および検証のための方法は、サービス提供者、第1のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、以下のステップ、すなわち
(A)サービス提供者が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、第1のサービス・ノードとの委任関係を確立するステップ、
(B)第1のサービス・ノードが、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス要求者との委任関係を確立するステップ、
(C)サービス要求者へと発行された委任情報を含んでいるサービス要求をサービス要求者から受信したときに、サービス提供者が、第1のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
(D)第1のサービス・ノードが、検証を実行するステップ、および
(E)第1のサービス・ノードによる検証が成功したときに、サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ
を含んでいる。
【0017】
本発明の分散式の委任および検証のためのシステムは、おおもとの委任元、中間の委任元および委任先、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも1つのサービス・ノード、ならびにサービス要求者を含んでいる。
【0018】
サービス提供者は、自身の認証信任状および自署名信任状を含む第1の委任情報を生成して、自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する。
【0019】
それぞれのサービス・ノードは、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成して、自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第2の委任情報内の自署名信任状の検証を、自身の委任元に対して要請する。
【0020】
サービス要求者は、自身へと発行された委任情報を含むサービス要求を、サービス提供者へと提出する。
【0021】
本発明の分散式の委任および検証のための装置は、サービス提供者、少なくとも1つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、委任ユニットおよび検証ユニットを備えている。
【0022】
委任ユニットは、自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む委任情報を生成して、自身の委任先との委任関係を確立する。
【0023】
検証ユニットは、検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する。
【0024】
本発明の他の特徴および利点が、添付の図面を参照して、好ましい実施形態についての以下の詳細な説明において明らかになるであろう。
【発明を実施するための最良の形態】
【0025】
図3および4を参照すると、分散式の委任および検証のための本発明による方法の好ましい実施形態が、サービス提供者36、サービス要求者39、および少なくとも1つのサービス・ノードを含む委任の連鎖において使用されるように構成されている。サービス提供者36が、おおもとの委任元である。サービス要求者39が、最終的な委任先である。サービス・ノードは、最初は中間の委任先として機能し、委任元によって委任された後に、中間の委任元として機能する。サービス要求者39が、サービス提供者36にサービスの提供を要求するとき、サービス提供者36が、サービス要求者39への委任の検証を助けるようにサービス・ノードに要請する。この方法は、以下で2つのサービス・ノード37、38を含む委任の連鎖の手段を例にして説明される委任の手順および検証の手順を含む。
【0026】
委任の手順は、以下のステップを含んでいる。
【0027】
ステップ301において、サービス提供者36が、第1の委任情報を生成する。
【0028】
この実施形態においては、委任情報は、委任元の自署名信任状および許可されるサービスに関する認証信任状を含んでいる。認証信任状は、おおもとの委任元によって生成される。したがって、ステップ301において、第1の委任情報は、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含んでいる。
【0029】
ステップ302において、サービス提供者36は、自身の対外委任テーブルに記録されている委任関係を更新する。
【0030】
この実施形態においては、対外委任テーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ302において、対外委任テーブルは、サービス提供者36の識別子、サービス・ノード37の識別子、サービス提供者36の識別子、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0031】
ステップ303において、サービス提供者36は、上述のように生成された第1の委任情報を、サービス・ノード37(この時点においては、中間の委任先として働く)へと送信する。
【0032】
ステップ304において、サービス・ノード37は、自身の委任受け付けテーブルに記録されている委任関係を更新する。
【0033】
この実施形態においては、委任受け付けテーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ304において、委任受け付けテーブルは、サービス提供者36の識別子、サービス・ノード37の識別子、サービス提供者36の識別子、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0034】
サービス提供者36は、上述のステップ301〜304によって、サービス・ノード37との委任関係を確立する。
【0035】
ステップ305において、サービス・ノード37(この時点においては、中間の委任元として働く)が、第2の委任情報を生成する。このステップにおいて、第2の委任情報は、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0036】
ステップ306において、サービス・ノード37は、自身の対外委任テーブルに保存されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード37の識別子、サービス・ノード38の識別子、サービス提供者36の識別子、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0037】
ステップ307において、サービス・ノード37は、上述のように生成された第2の委任情報を、サービス・ノード38(この時点においては、中間の委任先として働く)へと送信する。
【0038】
ステップ308において、サービス・ノード38が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード37の識別子、サービス・ノード38の識別子、サービス提供者36の識別子、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0039】
サービス・ノード37は、上述のステップ305〜308によって、サービス・ノード38との委任関係を確立する。
【0040】
ステップ309において、サービス・ノード38(この時点においては、中間の委任元として働く)が、第3の委任情報を生成する。このステップにおいて、第3の委任情報は、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0041】
ステップ310において、サービス・ノード38は、自身の対外委任テーブルに記録されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード38の識別子、サービス要求者39の識別子、サービス提供者36の識別子、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0042】
ステップ311において、サービス・ノード38は、上述のように生成された第3の委任情報を、サービス要求者39へと送信する。
【0043】
ステップ312において、サービス要求者39が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード38の識別子、サービス要求者39の識別子、サービス提供者36の識別子、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0044】
サービス・ノード38は、上述のステップ309〜312によって、サービス要求者39との委任関係を確立する。
【0045】
検証の手順は、以下のステップを含んでいる。
【0046】
ステップ401において、サービス要求者39が、サービス要求者39へと発行された委任情報を含んでいるサービス要求を、サービス提供者36へと提出する。このステップにおいて、委任情報は、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含んでいる。
【0047】
ステップ402において、サービス提供者36は、自身の対外委任テーブルに保存されている委任関係によれば、サービス要求者39が委任を受けていないと判断する(すなわち、対外委任テーブルにある委任先の識別子が、サービス要求者39の識別子とは異なるとの判断)。
【0048】
ステップ403において、サービス提供者36は、サービス・ノード38に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。このステップにおいて、自署名信任状は、サービス・ノード38の自署名信任状CBである。
【0049】
ステップ404において、サービス・ノード38は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0050】
この実施形態においては、サービス・ノード38は、検証するように要請された自署名信任状が、自身の対外委任テーブルに保存されている自署名信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する)とともに、対外委任テーブル内の委任先の識別子が、サービス要求者39の識別子と同じであるか否かを判断する(すなわち、サービス要求者39と自身との間に委任関係が存在するか否かを判断する)。
【0051】
ステップ405において、サービス・ノード38は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス・ノード37による委任を受けていると判断する。
【0052】
ステップ406において、サービス・ノード38は、自身へと発行された第2の委任情報内の自署名信任状を検証するよう、サービス・ノード37に対して要請する。このステップにおいて、自署名信任状は、サービス・ノード37の自署名信任状CAである。
【0053】
ステップ407において、サービス・ノード37は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0054】
この実施形態においては、サービス・ノード37は、検証するように要請された自署名信任状が、自身の対外委任テーブル内の自署名信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する)とともに、対外委任テーブル内の委任先の識別子が、サービス・ノード38の識別子と同じであるか否かを判断する(すなわち、サービス・ノード38と自身との間に委任関係が存在するか否かを判断する)。
【0055】
ステップ408において、サービス・ノード37は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス提供者36による委任を受けていると判断する。
【0056】
ステップ409において、サービス・ノード37は、自身へと発行された第1の委任情報内の自署名信任状を検証するよう、サービス提供者36に対して要請する。このステップにおいて、自署名信任状は、サービス提供者36の自署名信任状C_providerである。
【0057】
ステップ410において、サービス提供者36は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0058】
この実施形態においては、サービス提供者36は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状が、自身の対外委任テーブル内の自署名信任状および認証信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断し、サービス要求内の委任情報の認証信任状が、上述のように生成した認証信任状と同じであるか否かを判断する)とともに、自身の対外委任テーブル内の委任先の識別子が、サービス・ノード37の識別子と同じであるか否かを判断する(すなわち、サービス・ノード37と自身との間に委任関係が存在するか否かを判断する)。
【0059】
ステップ411において、サービス提供者36は、サービス要求者39によって提出されたサービス要求を許可する。
【0060】
この本発明による分散式の委任および検証のための方法は、サービス提供者36、サービス要求者39、および少なくとも1つのサービス・ノードを含む委任の連鎖において使用されるように構成されているが、1つのサービス提供者および1つのサービス要求者だけしか存在しない筋書きにおける使用に合わせて構成することも可能である。
【0061】
上述の説明は、サービス提供者36、サービス・ノード37、38、およびサービス要求者39がお互いに対してどのように動作するかに向けられている。次に、サービス提供者36およびサービス・ノード37、38によって使用される装置、ならびにそれらの動作の流れを、以下で詳しく説明する。
【0062】
図5を参照すると、サービス提供者36およびサービス・ノード37、38のそれぞれによって使用される分散式の委任および検証のための装置は、通信ユニット501、委任データベース502、鍵データベース503、アドレス・データベース504、アドレス決定ユニット505、委任ユニット506、および検証ユニット507を含んでいる。
【0063】
通信ユニット501は、外部へのデータの送信および外部からのデータの受信に使用される。
【0064】
委任データベース502は、委任関係を記録するために、対外委任テーブルおよび委任受け付けテーブルの少なくとも一方を保存する。
【0065】
鍵データベース503は、少なくとも1つの鍵を保存する。
【0066】
アドレス・データベース504は、当該装置と直接的な委任または被委任の関係を有している委任の連鎖における他の装置のアドレス情報を保存する。
【0067】
アドレス決定ユニット505は、アドレス・データベース504を更新するために使用され、アドレス・データベース504から検証ユニット507が求めるアドレス情報を割り出すために使用される。
【0068】
図5および6を参照すると、分散式の委任および検証のための装置がサービス提供者36に設置される場合、委任の手順の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0069】
ステップ611において、認証信任状が生成される。
【0070】
ステップ612において、サービス提供者36の自署名信任状が、対称または非対称暗号技法を使用し、鍵データベース503に保存されている鍵に従って生成される。
【0071】
ステップ613において、委任データベース502に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0072】
ステップ614において、認証信任状および自署名信任状が、通信ユニット501によってサービス提供者36の委任先へと送信される。
【0073】
図5および7を参照すると、分散式の委任および検証のための装置が、サービス提供者36に設置される場合、検証ユニット507の動作の流れは、以下のステップを含む。
【0074】
ステップ621において、サービス要求者39から送信されたサービス要求(発行済みの自署名信任状および認証信任状を含んでいる)が、通信ユニット501によって受信される。次いで、流れはステップ622へと進む。
【0075】
ステップ622において、サービス要求者39がサービス提供者36による委任を受けているか否かが、委任データベース502に保存されている対外委任テーブルに従って判断される。判断の結果が肯定である場合、流れはステップ627へと進む。判断の結果が否である場合には、流れはステップ623へと進む。
【0076】
ステップ623において、通信ユニット501を介して、サービス要求者39の委任元に対して、サービス要求内の自署名信任状を検証するように要請が行われる。このとき、アドレス決定ユニット505が、サービス要求者39の委任元のアドレス情報を割り出す。次いで、流れはステップ624へと進む。
【0077】
ステップ624において、信号(検証失敗の信号、または委任を受けたサービス・ノードによって受信された自署名信任状でありうる)が、通信ユニット501を介してサービス・ノードから受信される。次いで、流れはステップ625へと進む。
【0078】
ステップ625において、検証失敗の信号が受信されたか否かが判断される。判断の結果が肯定である場合、流れはステップ629へと進む。判断の結果が否である場合には、流れはステップ626へと進む。
【0079】
ステップ626において、ステップ624において受信された自署名信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ627へと進む。検証の結果が否である場合には、流れはステップ629へと進む。
【0080】
ステップ627において、ステップ621において受信された認証信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ628へと進む。検証の結果が否である場合には、流れはステップ629へと進む。
【0081】
ステップ628において、許可信号が、通信ユニット501を介してサービス要求者39へと送信される。
【0082】
ステップ629においては、拒絶信号が、通信ユニット501を介してサービス要求者39へと送信される。
【0083】
図5および8を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、委任を受ける動作の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0084】
ステップ701において、自身の委任元から送信された認証信任状および自署名信任状が、通信ユニット501を介して受信される。
【0085】
ステップ702において、委任データベース502に保存されている委任受け付けテーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0086】
図5および9を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、委任の手順の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0087】
ステップ711において、サービス提供者36によって生成された認証信任状が用意される。
【0088】
ステップ712において、当該サービス・ノードの自署名信任状が、対称または非対称暗号の技術を使用し、鍵データベース503に保存されている鍵に従って生成される。
【0089】
ステップ713において、委任データベース502に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0090】
ステップ714において、認証信任状および自署名信任状が、通信ユニット501によって当該サービス・ノードの委任先へと送信される。
【0091】
図5および10を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、検証ユニット507の動作の流れは、以下のステップを含む。
【0092】
ステップ721において、当該サービス・ノードにおける検証が要請された自署名信任状が、通信ユニット501によって受信される。流れはステップ722へと進む。
【0093】
ステップ722において、ステップ721において受信された自署名信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ723へと進む。検証の結果が否である場合には、流れはステップ725へと進む。
【0094】
ステップ723において、当該サービス・ノードの委任元が、委任データベース502に保存されている委任受け付けテーブルに従って割り出される。流れはステップ724へと進む。
【0095】
ステップ724において、当該サービス・ノードの委任元に対して、当該サービス・ノードへと発行された自署名信任状を検証するように、通信ユニット501を介して要請が行われる。このとき、アドレス決定ユニット505が、当該サービス・ノードの委任元のアドレス情報を割り出す。
【0096】
ステップ725においては、検証失敗信号が、通信ユニット501によってサービス提供者36へと送信される。このとき、アドレス決定ユニット505が、サービス提供者36のアドレス情報を割り出す。
【0097】
ステップ403および623において、サービス提供者36が、サービス要求内の委任情報がサービス・ノード38によって発行されたものであることを、ポイント‐トゥ‐ポイントの照会サービスによって判断できることに注意すべきである。次いで、サービス提供者36は、サービス・ノード38に対して、サービス要求内の自署名信任状の検証を要請する。あるいは、サービス提供者36は、サービス・ノード37との間に確立された委任関係にもとづき、サービス・ノード37に対して、サービス要求内の自署名信任状の検証を要請できる。サービス・ノード37が検証を進め、検証が不可能である場合には、サービス・ノード38との間に確立された委任関係にもとづき、サービス・ノード38に対して、サービス要求内の自署名信任状の検証を要請する。
【0098】
ステップ725において、サービス・ノード37、38は、ポイント‐トゥ‐ポイントの照会サービスによってサービス提供者36のアドレス情報を発見することができ、次いで検証失敗信号をサービス提供者36へと送信することができる。あるいは、サービス・ノード37、38は、自身の委任元との間に確立された委任関係にもとづき、自身の委任元へと検証失敗信号を送信することができる。次いで、この委任元が、この委任元の委任元との間に確立された委任関係にもとづき、委任元の委任元へと検証失敗信号を送信する。このプロセスが、検証失敗信号をサービス提供者36へと送信すべく繰り返される。例えば、サービス・ノード38が、サービス・ノード37との間に確立された委任関係にもとづき、サービス・ノード37へと検証失敗信号を送信し、次にサービス・ノード37が、サービス提供者36との間に確立された委任関係にもとづき、サービス提供者36へと検証失敗信号を送信する。
【0099】
本発明による分散式の委任および検証のためのシステムは、上述のサービス提供者36、サービス・ノード37、38、およびサービス要求者39を含んでいる。
【0100】
本発明においてセキュアなサービス共有をどのように実現できるのかを説明するために、簡単な例を以下に提示する。
【0101】
図11を参照すると、サービス提供者91が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、サービス・ノード92との委任関係を確立する。サービス・ノード93が、この第1の委任情報を盗み、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス・ノード94との委任関係を確立する。サービス・ノード94が、第2の委任情報内の認証信任状および自身の自署名信任状を含む第3の委任情報を生成し、サービス要求者95との委任関係を確立する。
【0102】
図12を参照すると、サービス要求者95が、自身へと発行された委任情報(すなわち、第3の委任情報)を含むサービス要求を、サービス提供者91へと提出する。サービス提供者91が、サービス・ノード94に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。サービス・ノード94は、検証を実行し、検証に成功すると、サービス・ノード93に対して、第2の委任情報内の自署名信任状を検証するように要請する。サービス・ノード93が、検証を実行し、検証に成功すると、サービス提供者91に対して第1の委任情報内の自署名信任状を検証するように要請する。サービス提供者91が、自身の対外委任テーブルに従って検証を実行し、自身とサービス・ノード93との間に委任の関係が存在しないことを確認する(サービス・ノード93の識別子が、サービス提供者91の対外委任テーブルに記録されていないため)。したがって、サービス提供者91は、サービス要求者95によって提出されたサービス要求を拒絶する。
【0103】
要約すると、それぞれの委任情報がいずれも、委任元の自署名信任状および許可されるサービスに関する認証信任状だけしか含まず、サービス・ノードの数が増えても長くなることがないため、送信されるデータの量を少なくすることができる。さらに、それぞれの委任情報内の自署名信任状が、当該委任情報の生成者によって検証されるため、サービス提供者に大きな演算負荷が加わることを防止することができる。したがって、従来技術と比べて、本発明は、確かに意図される目的を達成することができる。
【0104】
以上、本発明を最も現実的かつ好ましい実施形態であると考えられる内容に関して説明したが、本発明が、本明細書に開示された実施形態に限定されず、最も広い解釈の精神および範囲に含まれる種々の構成を包含し、そのような変形および均等な構成を網羅することを理解すべきである。
【産業上の利用可能性】
【0105】
本発明は、分散式の委任および検証のための方法、装置、およびシステムに適用可能である。
【図面の簡単な説明】
【0106】
【図1】属性証明書の管理に使用される従来からの方法を説明するための概略図である。
【図2】従来からの縦列状の委任の方法およびセキュアな通信リンクの従来からの初期化方法を説明するための概略図である。
【図3】本発明による分散式の委任および検証のための方法の好ましい実施形態について、委任の手順を説明するための流れ図である。
【図4】好ましい実施形態の方法における検証の手順を説明するための流れ図である。
【図5】本発明による分散式の委任および検証のための装置の好ましい実施形態を説明するためのブロック図である。
【図6】上記装置がサービス提供者に設置されたときの委任の動作を説明するための流れ図である。
【図7】上記装置がサービス提供者に設置されたときの検証の動作を説明するための流れ図である。
【図8】上記装置がサービス・ノードに設置されたときの委任の受け付けの動作を説明するための流れ図である。
【図9】上記装置がサービス・ノードに設置されたときの委任の動作を説明するための流れ図である。
【図10】上記装置がサービス・ノードに設置されたときの検証の動作を説明するための流れ図である。
【図11】本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任手順を説明するための概略図である。
【図12】本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任を防止するための検証手順を説明するための概略図である。
【技術分野】
【0001】
本発明は、委任(delegation)および検証(verification)のための方法、装置、およびシステムに関し、さらに詳しくは分散式の委任および検証のための方法、装置、およびシステムに関する。
【背景技術】
【0002】
ネットワークがますます普及するにつれて、サービス要求者は、ネットワークを介して無数のサービス提供者によって提供されるサービスを使用することができる。デバイスが他のデバイスと安全なサービスの共有を実行できるように、サービス提供者として機能するデバイスが、いくつかの他のデバイスに対して委任を実行し、次にこれらのデバイスが、別のデバイスに対して委任を実行でき、結果として、委任を受けたすべてのデバイスが、サービス要求者となって、サービス提供者によって提供されるサービスを使用することができる。この場合、すべてのデバイスの間の委任の関係を、中央のサーバによって集中的なやり方で直接的に管理することが可能である。
【0003】
しかしながら、特定の状況(例えば、制限されたネットワーク環境)のもとでは、必ずしもすべてのデバイスが中央のサーバへとアクセスできるわけではないため、このサービス共有を実行することができない。したがって、そのような状況のもとでは、分散的な管理を使用する必要がある。
【0004】
図1を参照すると、米国特許出願公開第20020073308号が、属性証明書を管理するための方法を開示している。この方法は、サービス提供者11、サービス要求者12、およびデータベース13を含むシステムにおいて使用するために適している。サービス提供者11が、委任元である。サービス要求者12が、委任先であり、属性証明書16を有している。データベース13が、サービス要求者12の公開鍵証明書17、および属性証明書16を発行しているオーソリティ(authority)の公開鍵証明書18を保存している。
【0005】
サービス提供者11が、サービス要求者12から属性証明書16を受信し、属性証明書16から公開鍵証明書ロケータ161を抽出する。公開鍵証明書ロケータ161は、サービス要求者12の公開鍵証明書17ならびに属性証明書16を発行しているオーソリティの公開鍵証明書18の位置を特定している。サービス提供者11は、公開鍵証明書ロケータ161を使用して、サービス要求者12の公開鍵証明書17ならびに属性証明書16を発行しているオーソリティの公開鍵証明書18をデータベース13から抽出し、抽出した公開鍵証明書17、18を使用して属性証明書16の検証を行う。検証に成功すると、サービス提供者11は、サービス要求者12に対し、管理されているリソースへのアクセスを属性証明書16に保存された権限属性に従って許可する。
【0006】
システムが、属性証明書を有する少なくとも1つのサービス・ノード(図示されていない)をさらに含んでいる場合、サービス提供者11が、おおもとの委任元であり、サービス要求者12が、最終的な委任先であり、サービス・ノードが、最初に中間の委任先として機能し、次いで、委任を受けた後に中間の委任元として機能する。委任の際に、サービス提供者11は、サービス・ノードおよびサービス要求者12の属性証明書を受信し、検証しなければならない。しかしながら、サービス・ノードの数が多くなると、サービス提供者11が、かなりの量の演算リソースを検証に費やさなければならない。
【0007】
図2を参照すると、米国特許出願公開第20040073801号が、縦列状の委任のための方法を開示している。この方法を、この方法がサービス提供者21、2つのサービス・ノード22、23、およびサービス要求者24を含むシステムにおいて使用される例を用いて、以下で説明する。この方法は、以下のステップ、すなわち
・サービス提供者21が、第1の委任トークンをサービス・ノード22へと送信するステップ、
・サービス・ノード22が、サービス提供者21へと応答を送信するステップ、
・サービス提供者21が、第1の委任トークンの署名(signature)を含んでいる第1の署名をサービス・ノード22へと送信するステップ、
・サービス・ノード22が、第2の委任トークンをサービス・ノード23へと送信するステップ、
・サービス・ノード23が、サービス・ノード22へと応答を送信するステップ、
・サービス・ノード22が、サービス・ノード22からの第2の委任トークンの署名と、サービス提供者21からの第1の委任トークンと、第1の委任トークンの署名とを含んでいる第2の署名を、サービス・ノード23へと送信するステップ、
・サービス・ノード23が、第3の委任トークンをサービス要求者24へと送信するステップ、
・サービス要求者24が、サービス・ノード23へと応答を送信するステップ、および
・サービス・ノード23が、サービス・ノード23からの第3の委任トークンの署名と、サービス・ノード22からの第2の委任トークンと、第2の委任トークンの署名と、サービス提供者21からの第1の委任トークンと、第1の委任トークンの署名とを含んでいる第3の署名を、サービス要求者24へと送信するステップ
を含んでいる。
【0008】
サービス要求者24は、サービス提供者21によって提供されるサービスの使用を望む場合、第3の署名を、検証のためにサービス提供者21へと送信しなければならない。
【0009】
この縦列状の委任方法においては、サービス提供者21およびサービス・ノード22、23の委任トークンならびに委任トークンの署名が、サービス要求者24への署名を生成すべく数珠繋ぎにされるため、サービス・ノードの数が多いと、結果として生成される署名がきわめて長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者21が、かなりの量の演算リソースを検証に費やさなければならない。
【0010】
米国特許出願公開第20040117623号が、セキュアな通信リンクの初期化の方法を開示している。この特許文献は、考え方において上述の特許出願公開第20040073801号に類似しているため、説明の目的のために、同じ図2および同じ参照番号を利用することにする。この方法を、この方法がサービス提供者21、2つのサービス・ノード22、23、およびサービス要求者24を含むシステムにおいて使用される例を用いて、説明する。この方法は、以下のステップ、すなわち
・サービス提供者21が、第1の鍵および関連の第1の要求データを含んでいる第1のトークンと、サービス提供者21の秘密鍵を第1の鍵および第1の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第1の認証データと、を含んでいる第1のメッセージを生成するステップ、
・サービス提供者21が、サービス・ノード22との共有の公知鍵を使用して第1のメッセージを暗号化するステップ、
・サービス提供者21が、セキュアな通信リンクを初期化すべく、暗号化した第1のメッセージをサービス・ノード22へと送信するステップ、
・サービス・ノード22が、サービス提供者21との共有の公知鍵を使用して、暗号化されている第1のメッセージを復号化するステップ、
・サービス・ノード22が、第2の鍵および関連の第2の要求データを含んでいる第2のトークンと、サービス・ノード22の秘密鍵を第2の鍵および第2の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第2の認証データと、第1のトークンと、第1の認証データと、を含んでいる第2のメッセージを生成するステップ、
・サービス・ノード22が、サービス・ノード23との共有の公知鍵を使用して第2のメッセージを暗号化するステップ、
・サービス・ノード22が、セキュアな通信リンクを初期化すべく、暗号化した第2のメッセージをサービス・ノード23へと送信するステップ、
・サービス・ノード23が、サービス・ノード22との共有の公知鍵を使用して、暗号化されている第2のメッセージを復号化するステップ、
・サービス・ノード23が、第3の鍵および関連の第3の要求データを含んでいる第3のトークンと、サービス・ノード23の秘密鍵を第3の鍵および第3の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第3の認証データと、第2のトークンと、第2の認証データと、第1のトークンと、第1の認証データと、を含んでいる第3のメッセージを生成するステップ、
・サービス・ノード23が、サービス要求者24との共有の公知鍵を使用して第3のメッセージを暗号化するステップ、
・サービス・ノード23が、セキュアな通信リンクを初期化すべく、暗号化した第3のメッセージをサービス要求者24へと送信するステップ、および
・サービス要求者24が、サービス・ノード23との共有の公知鍵を使用して、暗号化されている第3のメッセージを復号化するステップ
を含んでいる。
【0011】
サービス要求者24は、サービス提供者21によって提供されるサービスを使用する必要がある場合、第3のメッセージを、検証のためにサービス提供者21へと送信しなければならない。
【0012】
このセキュアな通信リンクの初期化の方法は、サービス提供者21およびサービス・ノード22、23のトークンならびに認証データを数珠繋ぎにしてサービス要求者24へのメッセージを生成するため、サービス・ノードの数が多いと、結果として生成されるメッセージが過剰に長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者21が、かなりの量の演算リソースを検証に費やさなければならない。
【発明の開示】
【0013】
したがって、本発明の目的は、分散式の委任および検証のための方法であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる方法を提供することにある。
【0014】
本発明の別の目的は、分散式の委任および検証のためのシステムであって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできるシステムを提供することにある。
【0015】
本発明のさらなる目的は、分散式の委任および検証のための装置であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる装置を提供することにある。
【0016】
したがって、本発明の分散式の委任および検証のための方法は、サービス提供者、第1のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、以下のステップ、すなわち
(A)サービス提供者が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、第1のサービス・ノードとの委任関係を確立するステップ、
(B)第1のサービス・ノードが、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス要求者との委任関係を確立するステップ、
(C)サービス要求者へと発行された委任情報を含んでいるサービス要求をサービス要求者から受信したときに、サービス提供者が、第1のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
(D)第1のサービス・ノードが、検証を実行するステップ、および
(E)第1のサービス・ノードによる検証が成功したときに、サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ
を含んでいる。
【0017】
本発明の分散式の委任および検証のためのシステムは、おおもとの委任元、中間の委任元および委任先、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも1つのサービス・ノード、ならびにサービス要求者を含んでいる。
【0018】
サービス提供者は、自身の認証信任状および自署名信任状を含む第1の委任情報を生成して、自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する。
【0019】
それぞれのサービス・ノードは、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成して、自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第2の委任情報内の自署名信任状の検証を、自身の委任元に対して要請する。
【0020】
サービス要求者は、自身へと発行された委任情報を含むサービス要求を、サービス提供者へと提出する。
【0021】
本発明の分散式の委任および検証のための装置は、サービス提供者、少なくとも1つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、委任ユニットおよび検証ユニットを備えている。
【0022】
委任ユニットは、自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む委任情報を生成して、自身の委任先との委任関係を確立する。
【0023】
検証ユニットは、検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する。
【0024】
本発明の他の特徴および利点が、添付の図面を参照して、好ましい実施形態についての以下の詳細な説明において明らかになるであろう。
【発明を実施するための最良の形態】
【0025】
図3および4を参照すると、分散式の委任および検証のための本発明による方法の好ましい実施形態が、サービス提供者36、サービス要求者39、および少なくとも1つのサービス・ノードを含む委任の連鎖において使用されるように構成されている。サービス提供者36が、おおもとの委任元である。サービス要求者39が、最終的な委任先である。サービス・ノードは、最初は中間の委任先として機能し、委任元によって委任された後に、中間の委任元として機能する。サービス要求者39が、サービス提供者36にサービスの提供を要求するとき、サービス提供者36が、サービス要求者39への委任の検証を助けるようにサービス・ノードに要請する。この方法は、以下で2つのサービス・ノード37、38を含む委任の連鎖の手段を例にして説明される委任の手順および検証の手順を含む。
【0026】
委任の手順は、以下のステップを含んでいる。
【0027】
ステップ301において、サービス提供者36が、第1の委任情報を生成する。
【0028】
この実施形態においては、委任情報は、委任元の自署名信任状および許可されるサービスに関する認証信任状を含んでいる。認証信任状は、おおもとの委任元によって生成される。したがって、ステップ301において、第1の委任情報は、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含んでいる。
【0029】
ステップ302において、サービス提供者36は、自身の対外委任テーブルに記録されている委任関係を更新する。
【0030】
この実施形態においては、対外委任テーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ302において、対外委任テーブルは、サービス提供者36の識別子、サービス・ノード37の識別子、サービス提供者36の識別子、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0031】
ステップ303において、サービス提供者36は、上述のように生成された第1の委任情報を、サービス・ノード37(この時点においては、中間の委任先として働く)へと送信する。
【0032】
ステップ304において、サービス・ノード37は、自身の委任受け付けテーブルに記録されている委任関係を更新する。
【0033】
この実施形態においては、委任受け付けテーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ304において、委任受け付けテーブルは、サービス提供者36の識別子、サービス・ノード37の識別子、サービス提供者36の識別子、サービス提供者36の自署名信任状C_provider、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0034】
サービス提供者36は、上述のステップ301〜304によって、サービス・ノード37との委任関係を確立する。
【0035】
ステップ305において、サービス・ノード37(この時点においては、中間の委任元として働く)が、第2の委任情報を生成する。このステップにおいて、第2の委任情報は、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0036】
ステップ306において、サービス・ノード37は、自身の対外委任テーブルに保存されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード37の識別子、サービス・ノード38の識別子、サービス提供者36の識別子、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0037】
ステップ307において、サービス・ノード37は、上述のように生成された第2の委任情報を、サービス・ノード38(この時点においては、中間の委任先として働く)へと送信する。
【0038】
ステップ308において、サービス・ノード38が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード37の識別子、サービス・ノード38の識別子、サービス提供者36の識別子、サービス・ノード37の自署名信任状CA、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0039】
サービス・ノード37は、上述のステップ305〜308によって、サービス・ノード38との委任関係を確立する。
【0040】
ステップ309において、サービス・ノード38(この時点においては、中間の委任元として働く)が、第3の委任情報を生成する。このステップにおいて、第3の委任情報は、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0041】
ステップ310において、サービス・ノード38は、自身の対外委任テーブルに記録されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード38の識別子、サービス要求者39の識別子、サービス提供者36の識別子、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0042】
ステップ311において、サービス・ノード38は、上述のように生成された第3の委任情報を、サービス要求者39へと送信する。
【0043】
ステップ312において、サービス要求者39が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード38の識別子、サービス要求者39の識別子、サービス提供者36の識別子、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含む。
【0044】
サービス・ノード38は、上述のステップ309〜312によって、サービス要求者39との委任関係を確立する。
【0045】
検証の手順は、以下のステップを含んでいる。
【0046】
ステップ401において、サービス要求者39が、サービス要求者39へと発行された委任情報を含んでいるサービス要求を、サービス提供者36へと提出する。このステップにおいて、委任情報は、サービス・ノード38の自署名信任状CB、およびサービス提供者36によって生成された認証信任状A_providerを含んでいる。
【0047】
ステップ402において、サービス提供者36は、自身の対外委任テーブルに保存されている委任関係によれば、サービス要求者39が委任を受けていないと判断する(すなわち、対外委任テーブルにある委任先の識別子が、サービス要求者39の識別子とは異なるとの判断)。
【0048】
ステップ403において、サービス提供者36は、サービス・ノード38に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。このステップにおいて、自署名信任状は、サービス・ノード38の自署名信任状CBである。
【0049】
ステップ404において、サービス・ノード38は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0050】
この実施形態においては、サービス・ノード38は、検証するように要請された自署名信任状が、自身の対外委任テーブルに保存されている自署名信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する)とともに、対外委任テーブル内の委任先の識別子が、サービス要求者39の識別子と同じであるか否かを判断する(すなわち、サービス要求者39と自身との間に委任関係が存在するか否かを判断する)。
【0051】
ステップ405において、サービス・ノード38は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス・ノード37による委任を受けていると判断する。
【0052】
ステップ406において、サービス・ノード38は、自身へと発行された第2の委任情報内の自署名信任状を検証するよう、サービス・ノード37に対して要請する。このステップにおいて、自署名信任状は、サービス・ノード37の自署名信任状CAである。
【0053】
ステップ407において、サービス・ノード37は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0054】
この実施形態においては、サービス・ノード37は、検証するように要請された自署名信任状が、自身の対外委任テーブル内の自署名信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する)とともに、対外委任テーブル内の委任先の識別子が、サービス・ノード38の識別子と同じであるか否かを判断する(すなわち、サービス・ノード38と自身との間に委任関係が存在するか否かを判断する)。
【0055】
ステップ408において、サービス・ノード37は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス提供者36による委任を受けていると判断する。
【0056】
ステップ409において、サービス・ノード37は、自身へと発行された第1の委任情報内の自署名信任状を検証するよう、サービス提供者36に対して要請する。このステップにおいて、自署名信任状は、サービス提供者36の自署名信任状C_providerである。
【0057】
ステップ410において、サービス提供者36は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。
【0058】
この実施形態においては、サービス提供者36は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状が、自身の対外委任テーブル内の自署名信任状および認証信任状と同じであるか否かを判断する(すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断し、サービス要求内の委任情報の認証信任状が、上述のように生成した認証信任状と同じであるか否かを判断する)とともに、自身の対外委任テーブル内の委任先の識別子が、サービス・ノード37の識別子と同じであるか否かを判断する(すなわち、サービス・ノード37と自身との間に委任関係が存在するか否かを判断する)。
【0059】
ステップ411において、サービス提供者36は、サービス要求者39によって提出されたサービス要求を許可する。
【0060】
この本発明による分散式の委任および検証のための方法は、サービス提供者36、サービス要求者39、および少なくとも1つのサービス・ノードを含む委任の連鎖において使用されるように構成されているが、1つのサービス提供者および1つのサービス要求者だけしか存在しない筋書きにおける使用に合わせて構成することも可能である。
【0061】
上述の説明は、サービス提供者36、サービス・ノード37、38、およびサービス要求者39がお互いに対してどのように動作するかに向けられている。次に、サービス提供者36およびサービス・ノード37、38によって使用される装置、ならびにそれらの動作の流れを、以下で詳しく説明する。
【0062】
図5を参照すると、サービス提供者36およびサービス・ノード37、38のそれぞれによって使用される分散式の委任および検証のための装置は、通信ユニット501、委任データベース502、鍵データベース503、アドレス・データベース504、アドレス決定ユニット505、委任ユニット506、および検証ユニット507を含んでいる。
【0063】
通信ユニット501は、外部へのデータの送信および外部からのデータの受信に使用される。
【0064】
委任データベース502は、委任関係を記録するために、対外委任テーブルおよび委任受け付けテーブルの少なくとも一方を保存する。
【0065】
鍵データベース503は、少なくとも1つの鍵を保存する。
【0066】
アドレス・データベース504は、当該装置と直接的な委任または被委任の関係を有している委任の連鎖における他の装置のアドレス情報を保存する。
【0067】
アドレス決定ユニット505は、アドレス・データベース504を更新するために使用され、アドレス・データベース504から検証ユニット507が求めるアドレス情報を割り出すために使用される。
【0068】
図5および6を参照すると、分散式の委任および検証のための装置がサービス提供者36に設置される場合、委任の手順の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0069】
ステップ611において、認証信任状が生成される。
【0070】
ステップ612において、サービス提供者36の自署名信任状が、対称または非対称暗号技法を使用し、鍵データベース503に保存されている鍵に従って生成される。
【0071】
ステップ613において、委任データベース502に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0072】
ステップ614において、認証信任状および自署名信任状が、通信ユニット501によってサービス提供者36の委任先へと送信される。
【0073】
図5および7を参照すると、分散式の委任および検証のための装置が、サービス提供者36に設置される場合、検証ユニット507の動作の流れは、以下のステップを含む。
【0074】
ステップ621において、サービス要求者39から送信されたサービス要求(発行済みの自署名信任状および認証信任状を含んでいる)が、通信ユニット501によって受信される。次いで、流れはステップ622へと進む。
【0075】
ステップ622において、サービス要求者39がサービス提供者36による委任を受けているか否かが、委任データベース502に保存されている対外委任テーブルに従って判断される。判断の結果が肯定である場合、流れはステップ627へと進む。判断の結果が否である場合には、流れはステップ623へと進む。
【0076】
ステップ623において、通信ユニット501を介して、サービス要求者39の委任元に対して、サービス要求内の自署名信任状を検証するように要請が行われる。このとき、アドレス決定ユニット505が、サービス要求者39の委任元のアドレス情報を割り出す。次いで、流れはステップ624へと進む。
【0077】
ステップ624において、信号(検証失敗の信号、または委任を受けたサービス・ノードによって受信された自署名信任状でありうる)が、通信ユニット501を介してサービス・ノードから受信される。次いで、流れはステップ625へと進む。
【0078】
ステップ625において、検証失敗の信号が受信されたか否かが判断される。判断の結果が肯定である場合、流れはステップ629へと進む。判断の結果が否である場合には、流れはステップ626へと進む。
【0079】
ステップ626において、ステップ624において受信された自署名信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ627へと進む。検証の結果が否である場合には、流れはステップ629へと進む。
【0080】
ステップ627において、ステップ621において受信された認証信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ628へと進む。検証の結果が否である場合には、流れはステップ629へと進む。
【0081】
ステップ628において、許可信号が、通信ユニット501を介してサービス要求者39へと送信される。
【0082】
ステップ629においては、拒絶信号が、通信ユニット501を介してサービス要求者39へと送信される。
【0083】
図5および8を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、委任を受ける動作の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0084】
ステップ701において、自身の委任元から送信された認証信任状および自署名信任状が、通信ユニット501を介して受信される。
【0085】
ステップ702において、委任データベース502に保存されている委任受け付けテーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0086】
図5および9を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、委任の手順の際の委任ユニット506の動作の流れは、以下のステップを含む。
【0087】
ステップ711において、サービス提供者36によって生成された認証信任状が用意される。
【0088】
ステップ712において、当該サービス・ノードの自署名信任状が、対称または非対称暗号の技術を使用し、鍵データベース503に保存されている鍵に従って生成される。
【0089】
ステップ713において、委任データベース502に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット505が、アドレス・データベース504を更新する。
【0090】
ステップ714において、認証信任状および自署名信任状が、通信ユニット501によって当該サービス・ノードの委任先へと送信される。
【0091】
図5および10を参照すると、分散式の委任および検証のための装置がサービス・ノード37、38に設置される場合、検証ユニット507の動作の流れは、以下のステップを含む。
【0092】
ステップ721において、当該サービス・ノードにおける検証が要請された自署名信任状が、通信ユニット501によって受信される。流れはステップ722へと進む。
【0093】
ステップ722において、ステップ721において受信された自署名信任状が正しいか否かが、委任データベース502に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ723へと進む。検証の結果が否である場合には、流れはステップ725へと進む。
【0094】
ステップ723において、当該サービス・ノードの委任元が、委任データベース502に保存されている委任受け付けテーブルに従って割り出される。流れはステップ724へと進む。
【0095】
ステップ724において、当該サービス・ノードの委任元に対して、当該サービス・ノードへと発行された自署名信任状を検証するように、通信ユニット501を介して要請が行われる。このとき、アドレス決定ユニット505が、当該サービス・ノードの委任元のアドレス情報を割り出す。
【0096】
ステップ725においては、検証失敗信号が、通信ユニット501によってサービス提供者36へと送信される。このとき、アドレス決定ユニット505が、サービス提供者36のアドレス情報を割り出す。
【0097】
ステップ403および623において、サービス提供者36が、サービス要求内の委任情報がサービス・ノード38によって発行されたものであることを、ポイント‐トゥ‐ポイントの照会サービスによって判断できることに注意すべきである。次いで、サービス提供者36は、サービス・ノード38に対して、サービス要求内の自署名信任状の検証を要請する。あるいは、サービス提供者36は、サービス・ノード37との間に確立された委任関係にもとづき、サービス・ノード37に対して、サービス要求内の自署名信任状の検証を要請できる。サービス・ノード37が検証を進め、検証が不可能である場合には、サービス・ノード38との間に確立された委任関係にもとづき、サービス・ノード38に対して、サービス要求内の自署名信任状の検証を要請する。
【0098】
ステップ725において、サービス・ノード37、38は、ポイント‐トゥ‐ポイントの照会サービスによってサービス提供者36のアドレス情報を発見することができ、次いで検証失敗信号をサービス提供者36へと送信することができる。あるいは、サービス・ノード37、38は、自身の委任元との間に確立された委任関係にもとづき、自身の委任元へと検証失敗信号を送信することができる。次いで、この委任元が、この委任元の委任元との間に確立された委任関係にもとづき、委任元の委任元へと検証失敗信号を送信する。このプロセスが、検証失敗信号をサービス提供者36へと送信すべく繰り返される。例えば、サービス・ノード38が、サービス・ノード37との間に確立された委任関係にもとづき、サービス・ノード37へと検証失敗信号を送信し、次にサービス・ノード37が、サービス提供者36との間に確立された委任関係にもとづき、サービス提供者36へと検証失敗信号を送信する。
【0099】
本発明による分散式の委任および検証のためのシステムは、上述のサービス提供者36、サービス・ノード37、38、およびサービス要求者39を含んでいる。
【0100】
本発明においてセキュアなサービス共有をどのように実現できるのかを説明するために、簡単な例を以下に提示する。
【0101】
図11を参照すると、サービス提供者91が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、サービス・ノード92との委任関係を確立する。サービス・ノード93が、この第1の委任情報を盗み、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス・ノード94との委任関係を確立する。サービス・ノード94が、第2の委任情報内の認証信任状および自身の自署名信任状を含む第3の委任情報を生成し、サービス要求者95との委任関係を確立する。
【0102】
図12を参照すると、サービス要求者95が、自身へと発行された委任情報(すなわち、第3の委任情報)を含むサービス要求を、サービス提供者91へと提出する。サービス提供者91が、サービス・ノード94に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。サービス・ノード94は、検証を実行し、検証に成功すると、サービス・ノード93に対して、第2の委任情報内の自署名信任状を検証するように要請する。サービス・ノード93が、検証を実行し、検証に成功すると、サービス提供者91に対して第1の委任情報内の自署名信任状を検証するように要請する。サービス提供者91が、自身の対外委任テーブルに従って検証を実行し、自身とサービス・ノード93との間に委任の関係が存在しないことを確認する(サービス・ノード93の識別子が、サービス提供者91の対外委任テーブルに記録されていないため)。したがって、サービス提供者91は、サービス要求者95によって提出されたサービス要求を拒絶する。
【0103】
要約すると、それぞれの委任情報がいずれも、委任元の自署名信任状および許可されるサービスに関する認証信任状だけしか含まず、サービス・ノードの数が増えても長くなることがないため、送信されるデータの量を少なくすることができる。さらに、それぞれの委任情報内の自署名信任状が、当該委任情報の生成者によって検証されるため、サービス提供者に大きな演算負荷が加わることを防止することができる。したがって、従来技術と比べて、本発明は、確かに意図される目的を達成することができる。
【0104】
以上、本発明を最も現実的かつ好ましい実施形態であると考えられる内容に関して説明したが、本発明が、本明細書に開示された実施形態に限定されず、最も広い解釈の精神および範囲に含まれる種々の構成を包含し、そのような変形および均等な構成を網羅することを理解すべきである。
【産業上の利用可能性】
【0105】
本発明は、分散式の委任および検証のための方法、装置、およびシステムに適用可能である。
【図面の簡単な説明】
【0106】
【図1】属性証明書の管理に使用される従来からの方法を説明するための概略図である。
【図2】従来からの縦列状の委任の方法およびセキュアな通信リンクの従来からの初期化方法を説明するための概略図である。
【図3】本発明による分散式の委任および検証のための方法の好ましい実施形態について、委任の手順を説明するための流れ図である。
【図4】好ましい実施形態の方法における検証の手順を説明するための流れ図である。
【図5】本発明による分散式の委任および検証のための装置の好ましい実施形態を説明するためのブロック図である。
【図6】上記装置がサービス提供者に設置されたときの委任の動作を説明するための流れ図である。
【図7】上記装置がサービス提供者に設置されたときの検証の動作を説明するための流れ図である。
【図8】上記装置がサービス・ノードに設置されたときの委任の受け付けの動作を説明するための流れ図である。
【図9】上記装置がサービス・ノードに設置されたときの委任の動作を説明するための流れ図である。
【図10】上記装置がサービス・ノードに設置されたときの検証の動作を説明するための流れ図である。
【図11】本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任手順を説明するための概略図である。
【図12】本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任を防止するための検証手順を説明するための概略図である。
【特許請求の範囲】
【請求項1】
サービス提供者、第1のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成された分散式の委任および検証のための方法であって、
(A)サービス提供者が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、第1のサービス・ノードとの委任関係を確立するステップ、
(B)第1のサービス・ノードが、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス要求者との委任関係を確立するステップ、
(C)サービス要求者へと発行された委任情報を含んでいるサービス要求をサービス要求者から受信したときに、サービス提供者が、第1のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
(D)第1のサービス・ノードが、検証を実行するステップ、および
(E)第1のサービス・ノードによる検証が成功したときに、サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ
を含んでいる方法。
【請求項2】
第1のサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項1に記載の分散式の委任および検証のための方法。
【請求項3】
ステップ(D)において、検証が成功したときに、第1のサービス・ノードが、サービス提供者に対し、第1の委任情報内の自署名信任状を検証するように要請し、ステップ(E)において、サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項2に記載の分散式の委任および検証のための方法。
【請求項4】
委任の連鎖が、第2のサービス・ノードをさらに含んでおり、
ステップ(B)において、第1のサービス・ノードが、最初に第2の委任情報を使用して第2のサービス・ノードとの委任関係を確立し、さらに第2のサービス・ノードが、第2の委任情報内の認証信任状および自身の自署名信任状を含む第3の委任情報を生成して、サービス要求者との委任関係を確立し、
ステップ(C)において、サービス提供者が、最初に第2のサービス・ノードに対してサービス要求内の委任情報の自署名信任状の検証を要請し、第2のサービス・ノードが、検証を実行し、検証が成功したときに第1のサービス・ノードに対して第2の委任情報内の自署名信任状の検証を要請する請求項1に記載の分散式の委任および検証のための方法。
【請求項5】
ステップ(C)において、サービス提供者が、第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、最初に第1のサービス・ノードに対して、サービス提供者との確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請し、第1のサービス・ノードが、検証を実行し、検証が不可能であるときに、第2のサービス・ノードに対して、第1のサービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請する請求項4に記載の分散式の委任および検証のための方法。
【請求項6】
ステップ(C)において、サービス提供者が、第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、最初にポイント‐トゥ‐ポイントの照会サービスを使用して、サービス要求内の委任情報が第2のサービス・ノードによって署名および発行されたことを発見し、次いで第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請する請求項4に記載の分散式の委任および検証のための方法。
【請求項7】
それぞれのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項4に記載の分散式の委任および検証のための方法。
【請求項8】
分散式の委任および検証のためのシステムであって、
おおもとの委任元、中間の委任先および委任元、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも1つのサービス・ノード、ならびにサービス要求者を含んでおり、
前記サービス提供者は、自身の認証信任状および自署名信任状を含む第1の委任情報を生成して、自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾し、
前記少なくとも1つのサービス・ノードは、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成して、自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第2の委任情報内の自署名信任状の検証を、自身の委任元に対して要請し、
前記サービス要求者は、自身へと発行された委任情報を含むサービス要求を、サービス提供者へと提出するシステム。
【請求項9】
前記少なくとも1つのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項10】
サービス提供者の委任先が、検証に成功したときに、第1の委任情報内の自署名信任状を検証するようにサービス提供者に対してさらに要請し、サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項9に記載の分散式の委任および検証のためのシステム。
【請求項11】
サービス提供者が、サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、自身の委任先に対して、サービス提供者との確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請し、前記少なくとも1つのサービス・ノードが、サービス要求内の自署名信任状を検証し、検証が不可能であるときに、自身の委任先に対して、当該サービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項12】
サービス提供者が、サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項13】
サービス提供者、少なくとも1つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成された分散式の委任および検証のための装置であって、
・自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む委任情報を生成して、自身の委任先との委任関係を確立する委任ユニット、および
・検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する検証ユニット
を備えている装置。
【請求項14】
少なくとも1の鍵を保存する鍵データベースをさらに備えており、
前記委任ユニットが、前記鍵データベースの前記鍵に従って、対称および非対称暗号技法の1つを使用して自署名信任状を生成する請求項13に記載の分散式の委任および検証のための装置。
【請求項15】
対外委任テーブルおよび委任受け付けテーブルの少なくとも一方を保存する委任データベースをさらに備えており、
前記対外委任テーブルが、自身の委任先との委任関係を記録するために使用され、前記委任受け付けテーブルが、自身の委任元との委任関係を記録するために使用される請求項13に記載の分散式の委任および検証のための装置。
【請求項16】
アドレス決定ユニットをさらに備えており、
該アドレス決定ユニットが、前記委任ユニットによって確立された委任関係にもとづいて、自身の委任先および自身の委任元のアドレス情報の保存および割り出しを行う請求項13に記載の分散式の委任および検証のための装置。
【請求項17】
サービス提供者に設置されたときに、
前記委任ユニットが、当該サービス提供者の認証信任状および自署名信任状を含む第1の委任情報を生成して、当該サービス提供者の委任先との委任関係を確立し、
前記検証ユニットが、サービス要求者の委任元に対して、サービス要求者へと発行された委任情報を含んでいるサービス要求内の自署名信任状を検証するように要請し、当該サービス提供者の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する請求項13に記載の分散式の委任および検証のための装置。
【請求項18】
前記検証ユニットが、当該サービス提供者の委任先によって検証するように要請された自署名信任状をさらに検証する請求項17に記載の分散式の委任および検証のための装置。
【請求項19】
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス提供者の自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項18に記載の分散式の委任および検証のための装置。
【請求項20】
前記サービス提供者の検証ユニットが、サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわち当該検証ユニットが、当該サービス提供者の委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項17に記載の分散式の委任および検証のための装置。
【請求項21】
前記サービス提供者の検証ユニットが、サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項17に記載の分散式の委任および検証のための装置。
【請求項22】
前記サービス・ノードに設置されたときに、
前記委任ユニットが、サービス提供者の認証信任状および自署名信任状を含んでいる第1の委任情報のうちの認証信任状と、当該サービス・ノードの自署名信任状とを含む第2の委任情報を生成して、当該サービス・ノードの委任先との委任関係を確立し、
前記検証ユニットが、当該サービス・ノードの委任先によって検証するように要請された自署名信任状を検証し、検証に成功したときに、当該サービス・ノードの委任元に対して、当該サービス・ノードの委任元によって発行された第2の委任情報内の自署名信任状を検証するように要請する請求項13に記載の分散式の委任および検証のための装置。
【請求項23】
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス・ノードの自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項22に記載の分散式の委任および検証のための装置。
【請求項24】
サービス提供者の委任先に設置されたときに、
前記検証ユニットが、検証に成功したときに、第1の委任情報内の自署名信任状を検証するようにサービス提供者に対してさらに要請する請求項22に記載の分散式の委任および検証のための装置。
【請求項25】
前記検証ユニットが、当該サービス・ノードの委任元によって検証するように要請されたサービス要求内の自署名信任状をさらに検証し、検証が不可能であるときに、当該サービス・ノードの委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項22に記載の分散式の委任および検証のための装置。
【請求項1】
サービス提供者、第1のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成された分散式の委任および検証のための方法であって、
(A)サービス提供者が、自身の認証信任状および自署名信任状を含む第1の委任情報を生成し、第1のサービス・ノードとの委任関係を確立するステップ、
(B)第1のサービス・ノードが、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成し、サービス要求者との委任関係を確立するステップ、
(C)サービス要求者へと発行された委任情報を含んでいるサービス要求をサービス要求者から受信したときに、サービス提供者が、第1のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
(D)第1のサービス・ノードが、検証を実行するステップ、および
(E)第1のサービス・ノードによる検証が成功したときに、サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ
を含んでいる方法。
【請求項2】
第1のサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項1に記載の分散式の委任および検証のための方法。
【請求項3】
ステップ(D)において、検証が成功したときに、第1のサービス・ノードが、サービス提供者に対し、第1の委任情報内の自署名信任状を検証するように要請し、ステップ(E)において、サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項2に記載の分散式の委任および検証のための方法。
【請求項4】
委任の連鎖が、第2のサービス・ノードをさらに含んでおり、
ステップ(B)において、第1のサービス・ノードが、最初に第2の委任情報を使用して第2のサービス・ノードとの委任関係を確立し、さらに第2のサービス・ノードが、第2の委任情報内の認証信任状および自身の自署名信任状を含む第3の委任情報を生成して、サービス要求者との委任関係を確立し、
ステップ(C)において、サービス提供者が、最初に第2のサービス・ノードに対してサービス要求内の委任情報の自署名信任状の検証を要請し、第2のサービス・ノードが、検証を実行し、検証が成功したときに第1のサービス・ノードに対して第2の委任情報内の自署名信任状の検証を要請する請求項1に記載の分散式の委任および検証のための方法。
【請求項5】
ステップ(C)において、サービス提供者が、第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、最初に第1のサービス・ノードに対して、サービス提供者との確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請し、第1のサービス・ノードが、検証を実行し、検証が不可能であるときに、第2のサービス・ノードに対して、第1のサービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請する請求項4に記載の分散式の委任および検証のための方法。
【請求項6】
ステップ(C)において、サービス提供者が、第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、最初にポイント‐トゥ‐ポイントの照会サービスを使用して、サービス要求内の委任情報が第2のサービス・ノードによって署名および発行されたことを発見し、次いで第2のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請する請求項4に記載の分散式の委任および検証のための方法。
【請求項7】
それぞれのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項4に記載の分散式の委任および検証のための方法。
【請求項8】
分散式の委任および検証のためのシステムであって、
おおもとの委任元、中間の委任先および委任元、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも1つのサービス・ノード、ならびにサービス要求者を含んでおり、
前記サービス提供者は、自身の認証信任状および自署名信任状を含む第1の委任情報を生成して、自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾し、
前記少なくとも1つのサービス・ノードは、第1の委任情報内の認証信任状および自身の自署名信任状を含む第2の委任情報を生成して、自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第2の委任情報内の自署名信任状の検証を、自身の委任元に対して要請し、
前記サービス要求者は、自身へと発行された委任情報を含むサービス要求を、サービス提供者へと提出するシステム。
【請求項9】
前記少なくとも1つのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項10】
サービス提供者の委任先が、検証に成功したときに、第1の委任情報内の自署名信任状を検証するようにサービス提供者に対してさらに要請し、サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項9に記載の分散式の委任および検証のためのシステム。
【請求項11】
サービス提供者が、サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、自身の委任先に対して、サービス提供者との確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請し、前記少なくとも1つのサービス・ノードが、サービス要求内の自署名信任状を検証し、検証が不可能であるときに、自身の委任先に対して、当該サービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項12】
サービス提供者が、サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項8に記載の分散式の委任および検証のためのシステム。
【請求項13】
サービス提供者、少なくとも1つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成された分散式の委任および検証のための装置であって、
・自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む委任情報を生成して、自身の委任先との委任関係を確立する委任ユニット、および
・検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する検証ユニット
を備えている装置。
【請求項14】
少なくとも1の鍵を保存する鍵データベースをさらに備えており、
前記委任ユニットが、前記鍵データベースの前記鍵に従って、対称および非対称暗号技法の1つを使用して自署名信任状を生成する請求項13に記載の分散式の委任および検証のための装置。
【請求項15】
対外委任テーブルおよび委任受け付けテーブルの少なくとも一方を保存する委任データベースをさらに備えており、
前記対外委任テーブルが、自身の委任先との委任関係を記録するために使用され、前記委任受け付けテーブルが、自身の委任元との委任関係を記録するために使用される請求項13に記載の分散式の委任および検証のための装置。
【請求項16】
アドレス決定ユニットをさらに備えており、
該アドレス決定ユニットが、前記委任ユニットによって確立された委任関係にもとづいて、自身の委任先および自身の委任元のアドレス情報の保存および割り出しを行う請求項13に記載の分散式の委任および検証のための装置。
【請求項17】
サービス提供者に設置されたときに、
前記委任ユニットが、当該サービス提供者の認証信任状および自署名信任状を含む第1の委任情報を生成して、当該サービス提供者の委任先との委任関係を確立し、
前記検証ユニットが、サービス要求者の委任元に対して、サービス要求者へと発行された委任情報を含んでいるサービス要求内の自署名信任状を検証するように要請し、当該サービス提供者の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する請求項13に記載の分散式の委任および検証のための装置。
【請求項18】
前記検証ユニットが、当該サービス提供者の委任先によって検証するように要請された自署名信任状をさらに検証する請求項17に記載の分散式の委任および検証のための装置。
【請求項19】
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス提供者の自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項18に記載の分散式の委任および検証のための装置。
【請求項20】
前記サービス提供者の検証ユニットが、サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわち当該検証ユニットが、当該サービス提供者の委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項17に記載の分散式の委任および検証のための装置。
【請求項21】
前記サービス提供者の検証ユニットが、サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項17に記載の分散式の委任および検証のための装置。
【請求項22】
前記サービス・ノードに設置されたときに、
前記委任ユニットが、サービス提供者の認証信任状および自署名信任状を含んでいる第1の委任情報のうちの認証信任状と、当該サービス・ノードの自署名信任状とを含む第2の委任情報を生成して、当該サービス・ノードの委任先との委任関係を確立し、
前記検証ユニットが、当該サービス・ノードの委任先によって検証するように要請された自署名信任状を検証し、検証に成功したときに、当該サービス・ノードの委任元に対して、当該サービス・ノードの委任元によって発行された第2の委任情報内の自署名信任状を検証するように要請する請求項13に記載の分散式の委任および検証のための装置。
【請求項23】
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス・ノードの自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項22に記載の分散式の委任および検証のための装置。
【請求項24】
サービス提供者の委任先に設置されたときに、
前記検証ユニットが、検証に成功したときに、第1の委任情報内の自署名信任状を検証するようにサービス提供者に対してさらに要請する請求項22に記載の分散式の委任および検証のための装置。
【請求項25】
前記検証ユニットが、当該サービス・ノードの委任元によって検証するように要請されたサービス要求内の自署名信任状をさらに検証し、検証が不可能であるときに、当該サービス・ノードの委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項22に記載の分散式の委任および検証のための装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公表番号】特表2010−520518(P2010−520518A)
【公表日】平成22年6月10日(2010.6.10)
【国際特許分類】
【出願番号】特願2009−504924(P2009−504924)
【出願日】平成20年2月29日(2008.2.29)
【国際出願番号】PCT/JP2008/054103
【国際公開番号】WO2008/111494
【国際公開日】平成20年9月18日(2008.9.18)
【出願人】(000005821)パナソニック株式会社 (73,050)
【Fターム(参考)】
【公表日】平成22年6月10日(2010.6.10)
【国際特許分類】
【出願日】平成20年2月29日(2008.2.29)
【国際出願番号】PCT/JP2008/054103
【国際公開番号】WO2008/111494
【国際公開日】平成20年9月18日(2008.9.18)
【出願人】(000005821)パナソニック株式会社 (73,050)
【Fターム(参考)】
[ Back to top ]