JP5215289B2

JP5215289B2 - 分散式の委任および検証のための方法、装置、およびシステム

Info

Publication number: JP5215289B2
Application number: JP2009504924A
Authority: JP
Inventors: チウ・チュアン−フェン
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2007-03-05
Filing date: 2008-02-29
Publication date: 2013-06-19
Anticipated expiration: 2028-02-29
Also published as: CN101262342A; JP2010520518A; US20100154040A1; WO2008111494A1

Description

本発明は、委任（ｄｅｌｅｇａｔｉｏｎ）および検証（ｖｅｒｉｆｉｃａｔｉｏｎ）のための方法、装置、およびシステムに関し、さらに詳しくは分散式の委任および検証のための方法、装置、およびシステムに関する。

ネットワークがますます普及するにつれて、サービス要求者は、ネットワークを介して無数のサービス提供者によって提供されるサービスを使用することができる。デバイスが他のデバイスと安全なサービスの共有を実行できるように、サービス提供者として機能するデバイスが、いくつかの他のデバイスに対して委任を実行し、次にこれらのデバイスが、別のデバイスに対して委任を実行でき、結果として、委任を受けたすべてのデバイスが、サービス要求者となって、サービス提供者によって提供されるサービスを使用することができる。この場合、すべてのデバイスの間の委任の関係を、中央のサーバによって集中的なやり方で直接的に管理することが可能である。

しかしながら、特定の状況（例えば、制限されたネットワーク環境）のもとでは、必ずしもすべてのデバイスが中央のサーバへとアクセスできるわけではないため、このサービス共有を実行することができない。したがって、そのような状況のもとでは、分散的な管理を使用する必要がある。

図１を参照すると、米国特許出願公開第２００２００７３３０８号が、属性証明書を管理するための方法を開示している。この方法は、サービス提供者１１、サービス要求者１２、およびデータベース１３を含むシステムにおいて使用するために適している。サービス提供者１１が、委任元である。サービス要求者１２が、委任先であり、属性証明書１６を有している。データベース１３が、サービス要求者１２の公開鍵証明書１７、および属性証明書１６を発行しているオーソリティ（ａｕｔｈｏｒｉｔｙ）の公開鍵証明書１８を保存している。

サービス提供者１１が、サービス要求者１２から属性証明書１６を受信し、属性証明書１６から公開鍵証明書ロケータ１６１を抽出する。公開鍵証明書ロケータ１６１は、サービス要求者１２の公開鍵証明書１７ならびに属性証明書１６を発行しているオーソリティの公開鍵証明書１８の位置を特定している。サービス提供者１１は、公開鍵証明書ロケータ１６１を使用して、サービス要求者１２の公開鍵証明書１７ならびに属性証明書１６を発行しているオーソリティの公開鍵証明書１８をデータベース１３から抽出し、抽出した公開鍵証明書１７、１８を使用して属性証明書１６の検証を行う。検証に成功すると、サービス提供者１１は、サービス要求者１２に対し、管理されているリソースへのアクセスを属性証明書１６に保存された権限属性に従って許可する。

システムが、属性証明書を有する少なくとも１つのサービス・ノード（図示されていない）をさらに含んでいる場合、サービス提供者１１が、おおもとの委任元であり、サービス要求者１２が、最終的な委任先であり、サービス・ノードが、最初に中間の委任先として機能し、次いで、委任を受けた後に中間の委任元として機能する。委任の際に、サービス提供者１１は、サービス・ノードおよびサービス要求者１２の属性証明書を受信し、検証しなければならない。しかしながら、サービス・ノードの数が多くなると、サービス提供者１１が、かなりの量の演算リソースを検証に費やさなければならない。

図２を参照すると、米国特許出願公開第２００４００７３８０１号が、縦列状の委任のための方法を開示している。この方法を、この方法がサービス提供者２１、２つのサービス・ノード２２、２３、およびサービス要求者２４を含むシステムにおいて使用される例を用いて、以下で説明する。この方法は、以下のステップ、すなわち
・サービス提供者２１が、第１の委任トークンをサービス・ノード２２へと送信するステップ、
・サービス・ノード２２が、サービス提供者２１へと応答を送信するステップ、
・サービス提供者２１が、第１の委任トークンの署名（ｓｉｇｎａｔｕｒｅ）を含んでいる第１の署名をサービス・ノード２２へと送信するステップ、
・サービス・ノード２２が、第２の委任トークンをサービス・ノード２３へと送信するステップ、
・サービス・ノード２３が、サービス・ノード２２へと応答を送信するステップ、
・サービス・ノード２２が、サービス・ノード２２からの第２の委任トークンの署名と、サービス提供者２１からの第１の委任トークンと、第１の委任トークンの署名とを含んでいる第２の署名を、サービス・ノード２３へと送信するステップ、
・サービス・ノード２３が、第３の委任トークンをサービス要求者２４へと送信するステップ、
・サービス要求者２４が、サービス・ノード２３へと応答を送信するステップ、および
・サービス・ノード２３が、サービス・ノード２３からの第３の委任トークンの署名と、サービス・ノード２２からの第２の委任トークンと、第２の委任トークンの署名と、サービス提供者２１からの第１の委任トークンと、第１の委任トークンの署名とを含んでいる第３の署名を、サービス要求者２４へと送信するステップ
を含んでいる。

サービス要求者２４は、サービス提供者２１によって提供されるサービスの使用を望む場合、第３の署名を、検証のためにサービス提供者２１へと送信しなければならない。

この縦列状の委任方法においては、サービス提供者２１およびサービス・ノード２２、２３の委任トークンならびに委任トークンの署名が、サービス要求者２４への署名を生成すべく数珠繋ぎにされるため、サービス・ノードの数が多いと、結果として生成される署名がきわめて長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者２１が、かなりの量の演算リソースを検証に費やさなければならない。

米国特許出願公開第２００４０１１７６２３号が、セキュアな通信リンクの初期化の方法を開示している。この特許文献は、考え方において上述の特許出願公開第２００４００７３８０１号に類似しているため、説明の目的のために、同じ図２および同じ参照番号を利用することにする。この方法を、この方法がサービス提供者２１、２つのサービス・ノード２２、２３、およびサービス要求者２４を含むシステムにおいて使用される例を用いて、説明する。この方法は、以下のステップ、すなわち
・サービス提供者２１が、第１の鍵および関連の第１の要求データを含んでいる第１のトークンと、サービス提供者２１の秘密鍵を第１の鍵および第１の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第１の認証データと、を含んでいる第１のメッセージを生成するステップ、
・サービス提供者２１が、サービス・ノード２２との共有の公知鍵を使用して第１のメッセージを暗号化するステップ、
・サービス提供者２１が、セキュアな通信リンクを初期化すべく、暗号化した第１のメッセージをサービス・ノード２２へと送信するステップ、
・サービス・ノード２２が、サービス提供者２１との共有の公知鍵を使用して、暗号化されている第１のメッセージを復号化するステップ、
・サービス・ノード２２が、第２の鍵および関連の第２の要求データを含んでいる第２のトークンと、サービス・ノード２２の秘密鍵を第２の鍵および第２の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第２の認証データと、第１のトークンと、第１の認証データと、を含んでいる第２のメッセージを生成するステップ、
・サービス・ノード２２が、サービス・ノード２３との共有の公知鍵を使用して第２のメッセージを暗号化するステップ、
・サービス・ノード２２が、セキュアな通信リンクを初期化すべく、暗号化した第２のメッセージをサービス・ノード２３へと送信するステップ、
・サービス・ノード２３が、サービス・ノード２２との共有の公知鍵を使用して、暗号化されている第２のメッセージを復号化するステップ、
・サービス・ノード２３が、第３の鍵および関連の第３の要求データを含んでいる第３のトークンと、サービス・ノード２３の秘密鍵を第３の鍵および第３の要求データの少なくとも一方を操作するように使用して生成されたデータを含んでいる第３の認証データと、第２のトークンと、第２の認証データと、第１のトークンと、第１の認証データと、を含んでいる第３のメッセージを生成するステップ、
・サービス・ノード２３が、サービス要求者２４との共有の公知鍵を使用して第３のメッセージを暗号化するステップ、
・サービス・ノード２３が、セキュアな通信リンクを初期化すべく、暗号化した第３のメッセージをサービス要求者２４へと送信するステップ、および
・サービス要求者２４が、サービス・ノード２３との共有の公知鍵を使用して、暗号化されている第３のメッセージを復号化するステップ
を含んでいる。

サービス要求者２４は、サービス提供者２１によって提供されるサービスを使用する必要がある場合、第３のメッセージを、検証のためにサービス提供者２１へと送信しなければならない。

このセキュアな通信リンクの初期化の方法は、サービス提供者２１およびサービス・ノード２２、２３のトークンならびに認証データを数珠繋ぎにしてサービス要求者２４へのメッセージを生成するため、サービス・ノードの数が多いと、結果として生成されるメッセージが過剰に長くなり、多量のネットワーク通信リソースを無駄に使用するだけでなく、サービス提供者２１が、かなりの量の演算リソースを検証に費やさなければならない。

したがって、本発明の目的は、分散式の委任および検証のための方法であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる方法を提供することにある。

本発明の別の目的は、分散式の委任および検証のためのシステムであって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできるシステムを提供することにある。

本発明のさらなる目的は、分散式の委任および検証のための装置であって、データの伝送の量を少なくすることができ、過大に大きな演算量が一点に集中することがないようにできる装置を提供することにある。

したがって、本発明の分散式の委任および検証のための方法は、サービス提供者、第１のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、しかもそれぞれが委託元識別子、委託先識別子、おおもとの委託元識別子および委任情報を含むテーブルを有し、以下のステップ、すなわち
（Ａ）前記サービス提供者が、前記委任情報であって自身の認証信任状および自署名信任状を含む第１の委任情報を生成し、前記第１のサービス・ノードのテーブルに、生成した前記第１の委任情報が送り込まれ、前記第１のサービス・ノードのテーブルを更新することにより、前記サービス要求者と前記第１のサービス・ノードとの委任関係を確立するステップ、
（Ｂ）前記第１のサービス・ノードが、前記第１の委任情報内の認証信任状および自身の自署名信任状を含む第２の委任情報を生成し、前記サービス要求者のテーブルに、生成した前記第２の委任情報が送り込まれ、前記サービス要求者のテーブルを更新することにより、前記第１のサービス・ノードと前記サービス要求者との委任関係を確立するステップ、
（Ｃ）前記サービス要求者へと発行された委任情報を含んでいるサービス要求を前記サービス要求者から受信したときに、前記サービス提供者が、前記第１のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
（Ｄ）前記第１のサービス・ノードが、検証を実行するステップ、および
（Ｅ）前記第１のサービス・ノードによる検証が成功したときに、前記サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ
を含んでいる。

本発明の分散式の委任および検証のためのシステムは、おおもとの委任元、中間の委任元および委任先、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも１つのサービス・ノード、ならびにサービス要求者を含んでいる。

サービス提供者は、自身の認証信任状および自署名信任状を含む第１の委任情報を生成して、自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する。

それぞれのサービス・ノードは、第１の委任情報内の認証信任状および自身の自署名信任状を含む第２の委任情報を生成して、自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第２の委任情報内の自署名信任状の検証を、自身の委任元に対して要請する。

サービス要求者は、自身へと発行された委任情報を含むサービス要求を、サービス提供者へと提出する。

本発明の分散式の委任および検証のための装置は、サービス提供者、少なくとも１つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、委任ユニットおよび検証ユニットを備えている。

委任ユニットは、自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む委任情報を生成して、自身の委任先との委任関係を確立する。

検証ユニットは、検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する。

本発明の他の特徴および利点が、添付の図面を参照して、好ましい実施形態についての以下の詳細な説明において明らかになるであろう。

図３および４を参照すると、分散式の委任および検証のための本発明による方法の好ましい実施形態が、サービス提供者３６、サービス要求者３９、および少なくとも１つのサービス・ノードを含む委任の連鎖において使用されるように構成されている。サービス提供者３６が、おおもとの委任元である。サービス要求者３９が、最終的な委任先である。サービス・ノードは、最初は中間の委任先として機能し、委任元によって委任された後に、中間の委任元として機能する。サービス要求者３９が、サービス提供者３６にサービスの提供を要求するとき、サービス提供者３６が、サービス要求者３９への委任の検証を助けるようにサービス・ノードに要請する。この方法は、以下で２つのサービス・ノード３７、３８を含む委任の連鎖の手段を例にして説明される委任の手順および検証の手順を含む。

委任の手順は、以下のステップを含んでいる。

ステップ３０１において、サービス提供者３６が、第１の委任情報を生成する。

この実施形態においては、委任情報は、委任元の自署名信任状および許可されるサービスに関する認証信任状を含んでいる。認証信任状は、おおもとの委任元によって生成される。したがって、ステップ３０１において、第１の委任情報は、サービス提供者３６の自署名信任状Ｃ＿ｐｒｏｖｉｄｅｒ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含んでいる。

ステップ３０２において、サービス提供者３６は、自身の対外委任テーブルに記録されている委任関係を更新する。

この実施形態においては、対外委任テーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ３０２において、対外委任テーブルは、サービス提供者３６の識別子、サービス・ノード３７の識別子、サービス提供者３６の識別子、サービス提供者３６の自署名信任状Ｃ＿ｐｒｏｖｉｄｅｒ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

ステップ３０３において、サービス提供者３６は、上述のように生成された第１の委任情報を、サービス・ノード３７（この時点においては、中間の委任先として働く）へと送信する。

ステップ３０４において、サービス・ノード３７は、自身の委任受け付けテーブルに記録されている委任関係を更新する。

この実施形態においては、委任受け付けテーブルは、委任元の識別子、委任先の識別子、おおもとの委任元の識別子、および委任元によって生成された委任情報を含んでいる。したがって、ステップ３０４において、委任受け付けテーブルは、サービス提供者３６の識別子、サービス・ノード３７の識別子、サービス提供者３６の識別子、サービス提供者３６の自署名信任状Ｃ＿ｐｒｏｖｉｄｅｒ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

サービス提供者３６は、上述のステップ３０１〜３０４によって、サービス・ノード３７との委任関係を確立する。

ステップ３０５において、サービス・ノード３７（この時点においては、中間の委任元として働く）が、第２の委任情報を生成する。このステップにおいて、第２の委任情報は、サービス・ノード３７の自署名信任状ＣＡ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

ステップ３０６において、サービス・ノード３７は、自身の対外委任テーブルに保存されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード３７の識別子、サービス・ノード３８の識別子、サービス提供者３６の識別子、サービス・ノード３７の自署名信任状ＣＡ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

ステップ３０７において、サービス・ノード３７は、上述のように生成された第２の委任情報を、サービス・ノード３８（この時点においては、中間の委任先として働く）へと送信する。

ステップ３０８において、サービス・ノード３８が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード３７の識別子、サービス・ノード３８の識別子、サービス提供者３６の識別子、サービス・ノード３７の自署名信任状ＣＡ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

サービス・ノード３７は、上述のステップ３０５〜３０８によって、サービス・ノード３８との委任関係を確立する。

ステップ３０９において、サービス・ノード３８（この時点においては、中間の委任元として働く）が、第３の委任情報を生成する。このステップにおいて、第３の委任情報は、サービス・ノード３８の自署名信任状ＣＢ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

ステップ３１０において、サービス・ノード３８は、自身の対外委任テーブルに記録されている委任関係を更新する。このステップにおいて、対外委任テーブルは、サービス・ノード３８の識別子、サービス要求者３９の識別子、サービス提供者３６の識別子、サービス・ノード３８の自署名信任状ＣＢ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

ステップ３１１において、サービス・ノード３８は、上述のように生成された第３の委任情報を、サービス要求者３９へと送信する。

ステップ３１２において、サービス要求者３９が、自身の委任受け付けテーブルに記録されている委任関係を更新する。このステップにおいて、委任受け付けテーブルは、サービス・ノード３８の識別子、サービス要求者３９の識別子、サービス提供者３６の識別子、サービス・ノード３８の自署名信任状ＣＢ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含む。

サービス・ノード３８は、上述のステップ３０９〜３１２によって、サービス要求者３９との委任関係を確立する。

検証の手順は、以下のステップを含んでいる。

ステップ４０１において、サービス要求者３９が、サービス要求者３９へと発行された委任情報を含んでいるサービス要求を、サービス提供者３６へと提出する。このステップにおいて、委任情報は、サービス・ノード３８の自署名信任状ＣＢ、およびサービス提供者３６によって生成された認証信任状Ａ＿ｐｒｏｖｉｄｅｒを含んでいる。

ステップ４０２において、サービス提供者３６は、自身の対外委任テーブルに保存されている委任関係によれば、サービス要求者３９が委任を受けていないと判断する（すなわち、対外委任テーブルにある委任先の識別子が、サービス要求者３９の識別子とは異なるとの判断）。

ステップ４０３において、サービス提供者３６は、サービス・ノード３８に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。このステップにおいて、自署名信任状は、サービス・ノード３８の自署名信任状ＣＢである。

ステップ４０４において、サービス・ノード３８は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。

この実施形態においては、サービス・ノード３８は、検証するように要請された自署名信任状が、自身の対外委任テーブルに保存されている自署名信任状と同じであるか否かを判断する（すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する）とともに、対外委任テーブル内の委任先の識別子が、サービス要求者３９の識別子と同じであるか否かを判断する（すなわち、サービス要求者３９と自身との間に委任関係が存在するか否かを判断する）。

ステップ４０５において、サービス・ノード３８は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス・ノード３７による委任を受けていると判断する。

ステップ４０６において、サービス・ノード３８は、自身へと発行された第２の委任情報内の自署名信任状を検証するよう、サービス・ノード３７に対して要請する。このステップにおいて、自署名信任状は、サービス・ノード３７の自署名信任状ＣＡである。

ステップ４０７において、サービス・ノード３７は、検証するように要請された自署名信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。

この実施形態においては、サービス・ノード３７は、検証するように要請された自署名信任状が、自身の対外委任テーブル内の自署名信任状と同じであるか否かを判断する（すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断する）とともに、対外委任テーブル内の委任先の識別子が、サービス・ノード３８の識別子と同じであるか否かを判断する（すなわち、サービス・ノード３８と自身との間に委任関係が存在するか否かを判断する）。

ステップ４０８において、サービス・ノード３７は、自身の委任受け付けテーブルに保存されている委任関係を利用して、自身がサービス提供者３６による委任を受けていると判断する。

ステップ４０９において、サービス・ノード３７は、自身へと発行された第１の委任情報内の自署名信任状を検証するよう、サービス提供者３６に対して要請する。このステップにおいて、自署名信任状は、サービス提供者３６の自署名信任状Ｃ＿ｐｒｏｖｉｄｅｒである。

ステップ４１０において、サービス提供者３６は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状を検証するために、自身の対外委任テーブルに保存されている委任関係を利用する。

この実施形態においては、サービス提供者３６は、検証するように要請された自署名信任状、ならびにサービス要求内の委任情報の認証信任状が、自身の対外委任テーブル内の自署名信任状および認証信任状と同じであるか否かを判断する（すなわち、検証するように要請された自署名信任状が、自身の自署名信任状と同じであるか否かを判断し、サービス要求内の委任情報の認証信任状が、上述のように生成した認証信任状と同じであるか否かを判断する）とともに、自身の対外委任テーブル内の委任先の識別子が、サービス・ノード３７の識別子と同じであるか否かを判断する（すなわち、サービス・ノード３７と自身との間に委任関係が存在するか否かを判断する）。

ステップ４１１において、サービス提供者３６は、サービス要求者３９によって提出されたサービス要求を許可する。

この本発明による分散式の委任および検証のための方法は、サービス提供者３６、サービス要求者３９、および少なくとも１つのサービス・ノードを含む委任の連鎖において使用されるように構成されているが、１つのサービス提供者および１つのサービス要求者だけしか存在しない筋書きにおける使用に合わせて構成することも可能である。

上述の説明は、サービス提供者３６、サービス・ノード３７、３８、およびサービス要求者３９がお互いに対してどのように動作するかに向けられている。次に、サービス提供者３６およびサービス・ノード３７、３８によって使用される装置、ならびにそれらの動作の流れを、以下で詳しく説明する。

図５を参照すると、サービス提供者３６およびサービス・ノード３７、３８のそれぞれによって使用される分散式の委任および検証のための装置は、通信ユニット５０１、委任データベース５０２、鍵データベース５０３、アドレス・データベース５０４、アドレス決定ユニット５０５、委任ユニット５０６、および検証ユニット５０７を含んでいる。

通信ユニット５０１は、外部へのデータの送信および外部からのデータの受信に使用される。

委任データベース５０２は、委任関係を記録するために、対外委任テーブルおよび委任受け付けテーブルの少なくとも一方を保存する。

鍵データベース５０３は、少なくとも１つの鍵を保存する。

アドレス・データベース５０４は、当該装置と直接的な委任または被委任の関係を有している委任の連鎖における他の装置のアドレス情報を保存する。

アドレス決定ユニット５０５は、アドレス・データベース５０４を更新するために使用され、アドレス・データベース５０４から検証ユニット５０７が求めるアドレス情報を割り出すために使用される。

図５および６を参照すると、分散式の委任および検証のための装置がサービス提供者３６に設置される場合、委任の手順の際の委任ユニット５０６の動作の流れは、以下のステップを含む。

ステップ６１１において、認証信任状が生成される。

ステップ６１２において、サービス提供者３６の自署名信任状が、対称または非対称暗号技法を使用し、鍵データベース５０３に保存されている鍵に従って生成される。

ステップ６１３において、委任データベース５０２に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット５０５が、アドレス・データベース５０４を更新する。

ステップ６１４において、認証信任状および自署名信任状が、通信ユニット５０１によってサービス提供者３６の委任先へと送信される。

図５および７を参照すると、分散式の委任および検証のための装置が、サービス提供者３６に設置される場合、検証ユニット５０７の動作の流れは、以下のステップを含む。

ステップ６２１において、サービス要求者３９から送信されたサービス要求（発行済みの自署名信任状および認証信任状を含んでいる）が、通信ユニット５０１によって受信される。次いで、流れはステップ６２２へと進む。

ステップ６２２において、サービス要求者３９がサービス提供者３６による委任を受けているか否かが、委任データベース５０２に保存されている対外委任テーブルに従って判断される。判断の結果が肯定である場合、流れはステップ６２７へと進む。判断の結果が否である場合には、流れはステップ６２３へと進む。

ステップ６２３において、通信ユニット５０１を介して、サービス要求者３９の委任元に対して、サービス要求内の自署名信任状を検証するように要請が行われる。このとき、アドレス決定ユニット５０５が、サービス要求者３９の委任元のアドレス情報を割り出す。次いで、流れはステップ６２４へと進む。

ステップ６２４において、信号（検証失敗の信号、または委任を受けたサービス・ノードによって受信された自署名信任状でありうる）が、通信ユニット５０１を介してサービス・ノードから受信される。次いで、流れはステップ６２５へと進む。

ステップ６２５において、検証失敗の信号が受信されたか否かが判断される。判断の結果が肯定である場合、流れはステップ６２９へと進む。判断の結果が否である場合には、流れはステップ６２６へと進む。

ステップ６２６において、ステップ６２４において受信された自署名信任状が正しいか否かが、委任データベース５０２に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ６２７へと進む。検証の結果が否である場合には、流れはステップ６２９へと進む。

ステップ６２７において、ステップ６２１において受信された認証信任状が正しいか否かが、委任データベース５０２に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ６２８へと進む。検証の結果が否である場合には、流れはステップ６２９へと進む。

ステップ６２８において、許可信号が、通信ユニット５０１を介してサービス要求者３９へと送信される。

ステップ６２９においては、拒絶信号が、通信ユニット５０１を介してサービス要求者３９へと送信される。

図５および８を参照すると、分散式の委任および検証のための装置がサービス・ノード３７、３８に設置される場合、委任を受ける動作の際の委任ユニット５０６の動作の流れは、以下のステップを含む。

ステップ７０１において、自身の委任元から送信された認証信任状および自署名信任状が、通信ユニット５０１を介して受信される。

ステップ７０２において、委任データベース５０２に保存されている委任受け付けテーブルが更新される。このとき、アドレス決定ユニット５０５が、アドレス・データベース５０４を更新する。

図５および９を参照すると、分散式の委任および検証のための装置がサービス・ノード３７、３８に設置される場合、委任の手順の際の委任ユニット５０６の動作の流れは、以下のステップを含む。

ステップ７１１において、サービス提供者３６によって生成された認証信任状が用意される。

ステップ７１２において、当該サービス・ノードの自署名信任状が、対称または非対称暗号の技術を使用し、鍵データベース５０３に保存されている鍵に従って生成される。

ステップ７１３において、委任データベース５０２に保存されている対外委任テーブルが更新される。このとき、アドレス決定ユニット５０５が、アドレス・データベース５０４を更新する。

ステップ７１４において、認証信任状および自署名信任状が、通信ユニット５０１によって当該サービス・ノードの委任先へと送信される。

図５および１０を参照すると、分散式の委任および検証のための装置がサービス・ノード３７、３８に設置される場合、検証ユニット５０７の動作の流れは、以下のステップを含む。

ステップ７２１において、当該サービス・ノードにおける検証が要請された自署名信任状が、通信ユニット５０１によって受信される。流れはステップ７２２へと進む。

ステップ７２２において、ステップ７２１において受信された自署名信任状が正しいか否かが、委任データベース５０２に保存されている対外委任テーブルに従って検証される。検証の結果が肯定である場合、流れはステップ７２３へと進む。検証の結果が否である場合には、流れはステップ７２５へと進む。

ステップ７２３において、当該サービス・ノードの委任元が、委任データベース５０２に保存されている委任受け付けテーブルに従って割り出される。流れはステップ７２４へと進む。

ステップ７２４において、当該サービス・ノードの委任元に対して、当該サービス・ノードへと発行された自署名信任状を検証するように、通信ユニット５０１を介して要請が行われる。このとき、アドレス決定ユニット５０５が、当該サービス・ノードの委任元のアドレス情報を割り出す。

ステップ７２５においては、検証失敗信号が、通信ユニット５０１によってサービス提供者３６へと送信される。このとき、アドレス決定ユニット５０５が、サービス提供者３６のアドレス情報を割り出す。

ステップ４０３および６２３において、サービス提供者３６が、サービス要求内の委任情報がサービス・ノード３８によって発行されたものであることを、ポイント‐トゥ‐ポイントの照会サービスによって判断できることに注意すべきである。次いで、サービス提供者３６は、サービス・ノード３８に対して、サービス要求内の自署名信任状の検証を要請する。あるいは、サービス提供者３６は、サービス・ノード３７との間に確立された委任関係にもとづき、サービス・ノード３７に対して、サービス要求内の自署名信任状の検証を要請できる。サービス・ノード３７が検証を進め、検証が不可能である場合には、サービス・ノード３８との間に確立された委任関係にもとづき、サービス・ノード３８に対して、サービス要求内の自署名信任状の検証を要請する。

ステップ７２５において、サービス・ノード３７、３８は、ポイント‐トゥ‐ポイントの照会サービスによってサービス提供者３６のアドレス情報を発見することができ、次いで検証失敗信号をサービス提供者３６へと送信することができる。あるいは、サービス・ノード３７、３８は、自身の委任元との間に確立された委任関係にもとづき、自身の委任元へと検証失敗信号を送信することができる。次いで、この委任元が、この委任元の委任元との間に確立された委任関係にもとづき、委任元の委任元へと検証失敗信号を送信する。このプロセスが、検証失敗信号をサービス提供者３６へと送信すべく繰り返される。例えば、サービス・ノード３８が、サービス・ノード３７との間に確立された委任関係にもとづき、サービス・ノード３７へと検証失敗信号を送信し、次にサービス・ノード３７が、サービス提供者３６との間に確立された委任関係にもとづき、サービス提供者３６へと検証失敗信号を送信する。

本発明による分散式の委任および検証のためのシステムは、上述のサービス提供者３６、サービス・ノード３７、３８、およびサービス要求者３９を含んでいる。

本発明においてセキュアなサービス共有をどのように実現できるのかを説明するために、簡単な例を以下に提示する。

図１１を参照すると、サービス提供者９１が、自身の認証信任状および自署名信任状を含む第１の委任情報を生成し、サービス・ノード９２との委任関係を確立する。サービス・ノード９３が、この第１の委任情報を盗み、第１の委任情報内の認証信任状および自身の自署名信任状を含む第２の委任情報を生成し、サービス・ノード９４との委任関係を確立する。サービス・ノード９４が、第２の委任情報内の認証信任状および自身の自署名信任状を含む第３の委任情報を生成し、サービス要求者９５との委任関係を確立する。

図１２を参照すると、サービス要求者９５が、自身へと発行された委任情報（すなわち、第３の委任情報）を含むサービス要求を、サービス提供者９１へと提出する。サービス提供者９１が、サービス・ノード９４に対し、サービス要求内の委任情報の自署名信任状を検証するように要請する。サービス・ノード９４は、検証を実行し、検証に成功すると、サービス・ノード９３に対して、第２の委任情報内の自署名信任状を検証するように要請する。サービス・ノード９３が、検証を実行し、検証に成功すると、サービス提供者９１に対して第１の委任情報内の自署名信任状を検証するように要請する。サービス提供者９１が、自身の対外委任テーブルに従って検証を実行し、自身とサービス・ノード９３との間に委任の関係が存在しないことを確認する（サービス・ノード９３の識別子が、サービス提供者９１の対外委任テーブルに記録されていないため）。したがって、サービス提供者９１は、サービス要求者９５によって提出されたサービス要求を拒絶する。

要約すると、それぞれの委任情報がいずれも、委任元の自署名信任状および許可されるサービスに関する認証信任状だけしか含まず、サービス・ノードの数が増えても長くなることがないため、送信されるデータの量を少なくすることができる。さらに、それぞれの委任情報内の自署名信任状が、当該委任情報の生成者によって検証されるため、サービス提供者に大きな演算負荷が加わることを防止することができる。したがって、従来技術と比べて、本発明は、確かに意図される目的を達成することができる。

以上、本発明を最も現実的かつ好ましい実施形態であると考えられる内容に関して説明したが、本発明が、本明細書に開示された実施形態に限定されず、最も広い解釈の精神および範囲に含まれる種々の構成を包含し、そのような変形および均等な構成を網羅することを理解すべきである。

本発明は、分散式の委任および検証のための方法、装置、およびシステムに適用可能である。

属性証明書の管理に使用される従来からの方法を説明するための概略図である。従来からの縦列状の委任の方法およびセキュアな通信リンクの従来からの初期化方法を説明するための概略図である。本発明による分散式の委任および検証のための方法の好ましい実施形態について、委任の手順を説明するための流れ図である。好ましい実施形態の方法における検証の手順を説明するための流れ図である。本発明による分散式の委任および検証のための装置の好ましい実施形態を説明するためのブロック図である。上記装置がサービス提供者に設置されたときの委任の動作を説明するための流れ図である。上記装置がサービス提供者に設置されたときの検証の動作を説明するための流れ図である。上記装置がサービス・ノードに設置されたときの委任の受け付けの動作を説明するための流れ図である。上記装置がサービス・ノードに設置されたときの委任の動作を説明するための流れ図である。上記装置がサービス・ノードに設置されたときの検証の動作を説明するための流れ図である。本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任手順を説明するための概略図である。本発明による分散式の委任および検証のための方法の好ましい実施形態について、異常な委任を防止するための検証手順を説明するための概略図である。

Claims

サービス提供者、第１のサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、しかもそれぞれが委託元識別子、委託先識別子、おおもとの委託元識別子および委任情報を含むテーブルを有した、分散式の委任および検証のための方法であって、
（Ａ）前記サービス提供者が、前記委任情報であって自身の認証信任状および自署名信任状を含む第１の委任情報を生成し、前記第１のサービス・ノードのテーブルに、生成した前記第１の委任情報が送り込まれ、前記第１のサービス・ノードのテーブルを更新することにより、前記サービス提供者と前記第１のサービス・ノードとの委任関係を確立するステップ、
（Ｂ）前記第１のサービス・ノードが、前記第１の委任情報内の認証信任状および自身の自署名信任状を含む第２の委任情報を生成し、前記サービス要求者のテーブルに、生成した前記第２の委任情報が送り込まれ、前記サービス要求者のテーブルを更新することにより、前記第１のサービス・ノードと前記サービス要求者との委任関係を確立するステップ、
（Ｃ）前記サービス要求者へと発行された委任情報を含んでいるサービス要求を前記サービス要求者から受信したときに、前記サービス提供者が、前記第１のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請するステップ、
（Ｄ）前記第１のサービス・ノードが、検証を実行するステップ、および
（Ｅ）前記第１のサービス・ノードによる検証が成功したときに、前記サービス提供者が、サービス要求内の委任情報の認証信任状を検証し、検証が成功したときにサービス要求を承諾するステップ、
を含んでいる方法。
前記第１のサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項１に記載の分散式の委任および検証のための方法。
ステップ（Ｄ）において、検証が成功したときに、前記第１のサービス・ノードが、前記サービス提供者に対し、前記第１の委任情報内の自署名信任状を検証するように要請し、ステップ（Ｅ）において、前記サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項２に記載の分散式の委任および検証のための方法。
委任の連鎖が、第２のサービス・ノードをさらに含んでおり、
ステップ（Ｂ）において、前記第１のサービス・ノードが、最初に第２の委任情報を使用して前記第２のサービス・ノードとの委任関係を確立し、さらに前記第２のサービス・ノードが、前記第２の委任情報内の認証信任状および自身の自署名信任状を含む第３の委任情報を生成して、前記サービス要求者との委任関係を確立し、
ステップ（Ｃ）において、前記サービス提供者が、最初に前記第２のサービス・ノードに対してサービス要求内の委任情報の自署名信任状の検証を要請し、前記第２のサービス・ノードが、検証を実行し、検証が成功したときに前記第１のサービス・ノードに対して前記第２の委任情報内の自署名信任状の検証を要請する請求項１に記載の分散式の委任および検証のための方法。
ステップ（Ｃ）において、サービス提供者が、前記第２のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわち前記サービス提供者が、最初に前記第１のサービス・ノードに対して、前記サービス提供者との確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請し、前記第１のサービス・ノードが、検証を実行し、検証が不可能であるときに、前記第２のサービス・ノードに対して、前記第１のサービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の委任情報の自署名信任状を検証するように要請する請求項４に記載の分散式の委任および検証のための方法。
ステップ（Ｃ）において、前記サービス提供者が、前記第２のサービス・ノードに対して、前記サービス要求内の委任情報の自署名信任状の検証を以下のやり方で要請し、
すなわちサービス提供者が、最初にポイント‐トゥ‐ポイントの照会サービスを使用して、サービス要求内の委任情報が前記第２のサービス・ノードによって署名および発行されたことを発見し、次いで前記第２のサービス・ノードに対して、サービス要求内の委任情報の自署名信任状の検証を要請する請求項４に記載の分散式の委任および検証のための方法。
前記第１、第２それぞれのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項４に記載の分散式の委任および検証のための方法。
分散式の委任および検証のためのシステムであって、
おおもとの委任元、中間の委任先および委任元、ならびに最終の委任先としてそれぞれ働くサービス提供者、少なくとも１つのサービス・ノード、ならびにサービス要求者を含んでおり、しかも、それぞれが委託元識別子、委託先識別子、おおもとの委託元識別子および委任情報を含むテーブルを有したシステムであって、
前記サービス提供者は、前記委任情報であって自身の認証信任状および自署名信任状を含む第１の委任情報を生成して、前記サービス・ノードのテーブルに、生成した前記第１の委任情報が送り込まれ、前記サービス・ノードのテーブルを更新することにより、前記サービス提供者と自身の委任先との委任関係を確立し、サービス要求内の自署名信任状の検証を、前記サービス要求者の委任元に対して要請し、自身の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾し、
前記少なくとも１つのサービス・ノードは、第１の委任情報内の認証信任状および自身の自署名信任状を含む第２の委任情報を生成して、前記サービス要求者のテーブルに、生成した前記第２の委任情報が送り込まれ、前記サービス要求者のテーブルを更新することにより、前記少なくとも１つのサービス・ノードと自身の委任先との委任関係を確立し、検証するように要請された自署名信任状を検証し、検証に成功したときに、自身へと発行された第２の委任情報内の自署名信任状の検証を、自身の委任元に対して要請し、
前記サービス要求者は、自身へと発行された委任情報を含むサービス要求を、前記サービス提供者へと提出するシステム。
前記少なくとも１つのサービス・ノードが、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいて判断する請求項８に記載の分散式の委任および検証のためのシステム。
前記サービス提供者の委任先が、検証に成功したときに、第１の委任情報内の自署名信任状を検証するように前記サービス提供者に対してさらに要請し、前記サービス提供者が、検証するように要請された自署名信任状が自身の自署名信任状と同じであるか否かを、確立済みの委任関係にもとづいてさらに判断する請求項９に記載の分散式の委任および検証のためのシステム。
前記サービス提供者が、前記サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわち前記サービス提供者が、自身の委任先に対して、前記サービス提供者との確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請し、前記少なくとも１つのサービス・ノードが、サービス要求内の自署名信任状を検証し、検証が不可能であるときに、自身の委任先に対して、前記サービス・ノードとの確立済みの委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項８に記載の分散式の委任および検証のためのシステム。
前記サービス提供者が、前記サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項８に記載の分散式の委任および検証のためのシステム。
サービス提供者、少なくとも１つのサービス・ノード、およびサービス要求者を含む委任の連鎖において使用されるように構成され、しかもそれぞれが委託元識別子、委託先識別子、おおもとの委託元識別子および委任情報を含むテーブルを有した、分散式の委任および検証のための装置であって、
・自身の認証信任状および自署名信任状を含む第１の委任情報を生成して、前記第１の委任情報を含むテーブルを更新することにより、自身と自身の委任元との委任関係を確立し、さらに認証信任状および自署名信任状を含む第２の委任情報を生成して、前記第２の委任情報を含むテーブルを更新することにより、自身と自身の委任先との委任関係を確立する委任ユニット、および
・検証するように要請された自署名信任状を、前記委任ユニットによって確立した委任関係にもとづいて検証する検証ユニット
を備えている装置。
少なくとも１の鍵を保存する鍵データベースをさらに備えており、
前記委任ユニットが、前記鍵データベースの前記鍵に従って、対称および非対称暗号技法の１つを使用して自署名信任状を生成する請求項１３に記載の分散式の委任および検証のための装置。
前記第１の委任情報を含むテーブルは、委任受け付けテーブルであり、前記第２の委任情報を含むテーブルは対外委任テーブルである、請求項１３に記載の分散式の委任および検証のための装置。
アドレス決定ユニットをさらに備えており、
該アドレス決定ユニットが、前記委任ユニットによって確立された委任関係にもとづいて、自身の委任先および自身の委任元のアドレス情報の保存および割り出しを行う請求項１３に記載の分散式の委任および検証のための装置。
サービス提供者に設置されたときに、
前記委任ユニットが、当該サービス提供者の認証信任状および自署名信任状を含む第１の委任情報を生成して、当該サービス提供者の委任先との委任関係を確立し、
前記検証ユニットが、前記サービス要求者の委任元に対して、前記サービス要求者へと発行された委任情報を含んでいるサービス要求内の自署名信任状を検証するように要請し、当該サービス提供者の委任先による検証が成功したときに、サービス要求内の認証信任状を検証し、認証信任状の検証に成功したときにサービス要求を承諾する請求項１３に記載の分散式の委任および検証のための装置。
前記検証ユニットが、当該サービス提供者の委任先によって検証するように要請された自署名信任状をさらに検証する請求項１７に記載の分散式の委任および検証のための装置。
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス提供者の自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項１８に記載の分散式の委任および検証のための装置。
前記サービス提供者の検証ユニットが、前記サービス要求者の委任元に対して、サービス要求内の自署名信任状の検証を以下のやり方で要請し、
すなわち当該検証ユニットが、当該サービス提供者の委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項１７に記載の分散式の委任および検証のための装置。
前記サービス提供者の検証ユニットが、前記サービス要求者の委任元を、ポイント‐トゥ‐ポイントの照会サービスを使用して発見する請求項１７に記載の分散式の委任および検証のための装置。
前記サービス・ノードに設置されたときに、
前記委任ユニットが、サービス提供者の認証信任状および自署名信任状を含んでいる第１の委任情報のうちの認証信任状と、当該サービス・ノードの自署名信任状とを含む第２の委任情報を生成して、当該サービス・ノードの委任先との委任関係を確立し、
前記検証ユニットが、当該サービス・ノードの委任先によって検証するように要請された自署名信任状を検証し、検証に成功したときに、当該サービス・ノードの委任元に対して、当該サービス・ノードの委任元によって発行された第２の委任情報内の自署名信任状を検証するように要請する請求項１３に記載の分散式の委任および検証のための装置。
前記検証ユニットが、検証するように要請された自署名信任状が当該サービス・ノードの自署名信任状と同じであるか否かを、前記委任ユニットによって確立された委任関係にもとづいて判断する請求項２２に記載の分散式の委任および検証のための装置。
前記サービス提供者の委任先に設置されたときに、
前記検証ユニットが、検証に成功したときに、第１の委任情報内の自署名信任状を検証するように前記サービス提供者に対してさらに要請する請求項２２に記載の分散式の委任および検証のための装置。
前記検証ユニットが、当該サービス・ノードの委任元によって検証するように要請されたサービス要求内の自署名信任状をさらに検証し、検証が不可能であるときに、当該サービス・ノードの委任先に対して、前記委任ユニットによって確立された委任関係にもとづいてサービス要求内の自署名信任状を検証するように要請する請求項２２に記載の分散式の委任および検証のための装置。