JP2013536651A - 属性ベースのデジタル署名 - Google Patents

Abstract

属性ベースのデジタル署名システムが開示されている。第１の署名生成ユニット１は、第１の署名鍵１２及びドキュメント１１に基づいて、前記ドキュメント１１に対する第１の署名１０を生成するため使用される。再署名ユニット２は、第１の署名１０及び再署名鍵１４に基づいて、前記ドキュメント１１に対する第２の署名１３を生成し、前記再署名ユニット２は第１の署名１０及び／又は第２の署名１３と関連した属性１５、１６を扱う。第２の署名１３は、前記再署名鍵１４により決定される属性１６、１６’’’の第２のセットと関連し、属性１６の第２のセットは、複数の属性を有する。第１の署名１０は、属性１５の第１のセットと関連し、属性１５の第１のセットは、複数の属性を有し、前記再署名ユニット２は、属性１５の第１のセットが状況１７、１７’のセットを満足する場合だけ、第２の署名１３を生成する。

Description

本発明は属性ベースのデジタル署名に関する。

在宅看護を介した従来のヘルスケアからヘルスサービスまでの範囲にわたる看護サイクルに関わる種々異なるパーティー間のデータ交換のために増大しているニーズは、ヘルスデータの安全な管理に対して大きな論点を生じさせている。必要な物理的及び管理の手順で補足される従来のセキュリティメカニズムに基づく今日のアプローチは、ヘルス情報の利用可能性を制限し、ヘルス記録の交換を扱いにくくしている。デジタル方針管理及び施行技術は、これらの従来のアプローチより性能が優れていて、（１）データが行き交うインフラストラクチャ又は組織境界と独立してデータを保護する、異機種間接続ネットワークのエンドツーエンドのプライバシー及びセキュリティ（２）適当な属性（例えば役割）を持つユーザだけが、彼／彼女の属性と関連した秘密鍵に基づいて、メッセージを解読するか又は署名できる、ヘルスケアアプリケーションにおいて非常に重要である役割ベース又は属性ベースのアクセス制御メカニズムの暗号の施行を実現するための可能性を提供している。

ヘルスケアのワークフローの重要な観点の１つは、発信元の否認防止であり、これは、データの受取人がデータ発信元を検証できることを意味する。日常生活において、デジタル署名は、否認防止特性を実行するために用いられる。従来の署名スキームでは、個人的及び公的な鍵ペアが各ユーザに対して生成され、当該ペアの秘密鍵がメッセージに署名するために使用される一方、公開鍵がメッセージの署名を認証するために用いられる。しかしながら、ヘルスケア組織では、属性は、通常、ユーザの役割及び同一性を記述するために用いられ、データへのアクセスはユーザ属性に基づいて付与されている。よって、ユーザは、ユーザが正しいセットの属性を持つ場合に限り、そのデータを作るか修正して、その後署名してもよい。この目的のために、例えば、Dalia Khader, "Attribute Based Group Signatures", International Association for Cryptologic Research (IACR), 2007, 241に記載されているように、属性ベースの署名が使われている。よって、ヘルスケアでは、属性は、データ発信元を証明する主要なソースであるとみなされる。これらの属性は、また、特定のドメイン（例えば名前又は識別子）の個人に固有である個々の属性を有する。例えば、処方箋が特定の役割を持つ特定のユーザ（例えば医師ジョンスミス）により署名された場合、薬局は、処方箋を受理するだろう。匿名が重要である医学調査に関係する他の使用の場合、患者は、（患者は３０―４０歳の男性であるような）患者の非固有の属性だけを使用して患者のヘルス記録に署名できる。よって、ヘルスデータの保護に対する属性ベースの暗号化（ＡＢＥ）システムの重要なコンポーネントは、属性ベースの署名（ＡＢＳ）スキームである。

属性ベースの署名（ＡＢＳ）において、データは、ユーザにより所有される属性セットωと関連した暗号鍵ＳＫ_ωを使用して署名される。メッセージに署名可能にするために、ユーザは、認証機関から、ユーザが持つ認定された属性のセットに対応する特定の私有鍵を得る。既述されたように、ユーザは、ユーザが特定の署名動作のために使用を望む属性のサブセットに関係する秘密鍵のサブセットを選択するための柔軟性も有する。

改良された属性ベースのデジタル署名システムを持つことは、有利であろう。この懸念に良好に対処するために、第１の観点では、本発明は、第１の署名鍵及びドキュメントに基づいて、前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと、第１の署名及び再署名鍵に基づいて、前記ドキュメントに対する第２の署名を生成するための再署名ユニットとを有し、前記再署名ユニットは第１の署名及び／又は第２の署名と関連した属性を扱う、属性ベースのデジタル署名システムを提供する。

このシステムは、署名と関連する属性に基づいて、再署名機能を構成可能にする。再署名ユニットのため、署名のための権限は、受任者に委託者の署名鍵を与えることなく、委託される。代わりに、受任者は、半信頼されたユニット、すなわちプロキシ（代理）である再署名ユニットを使用して、受任者の署名を委託者の署名へ変換可能にされる。署名と関連する属性を扱うための再署名ユニットを構成することにより、再署名機能は、よりフレキシブルになる。鍵の属性は、例えば、第１の署名と関連したどんな属性が再署名ユニットを使用するために必要とされるか、及び／又は、どんな属性が第２の署名と関連するかを特定するために使用できるので、委任作業はユーザごとに遂行される必要はない。結果的に、委託者は、委託者の属性に基づいて、作業をユーザのグループへ委任できる。第１の署名を第２の署名へ変換するための再署名ユニットが設けられ、ここで、第２の署名はドキュメントに対する第１の署名と置き換わり、第２の署名は第１の署名と独立して検証できる。

第２の署名は、前記再署名鍵により決定される属性の第２のセットと関連し、属性の第２のセットは、複数の属性を有する。再署名ユニットは、第１の署名を属性の第２のセットと関連する署名へ変換可能にする。これは、既存の属性ベースのデジタル署名システムで実行できない幾つかの使用シナリオを実行可能にする。例えば、システムは、属性のそのセットと関連する署名鍵をユーザに与えることなしに、属性の特定のセットを持つドキュメントに署名する権限をユーザに委任可能にする。代わりに、ユーザは、第１の署名鍵だけを与えられ、第１の署名鍵で生成される署名を、属性の第２のセットと関連する所望の第２の署名へ変換するために、再署名ユニットを起動する必要があるだけである。再署名ユニットは、半信頼されたプロキシ（代理）として実行される。

代替的に又は追加的に、第１の署名は、属性の第１のセットと関連し、属性の第１のセットは複数の属性を有し、前記再署名ユニットは、属性の第１のセットが条件のセットを満足する場合だけ、第２の署名を生成する。これは、受任者の特定のユーザＩＤを特定することなしに、委託者がユーザのグループに権限付与（認可）可能にする。代わりに、認可は、第１の署名鍵で表されるユーザの属性（例えば、役割）に基づいて実施できる。

当該システムは、属性の第２のセットと関連した第２の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し、前記再署名鍵は、前記再署名ユニットが、第１の署名を属性の第２のセットと関連する第２の署名へ変換可能にし、第２の署名鍵は、第２の署名生成ユニットが前記ドキュメント自体に基づいて属性の第２のセットと関連する署名を生成可能にする。通常は、第２の署名鍵の制御は、属性の第２のセットでドキュメントに署名する権限を持つ人に委任される。説明されているように再署名鍵生成器を使用して、その人は、第２の署名鍵を再署名鍵生成器へ供給することにより、再署名鍵を作ることができる。属性ベースの署名システムの何れのマスター鍵も必要ではない。これは、署名するための権限を委任することを比較的容易にする。

前記再署名鍵生成器は、更に、第２の署名鍵に基づいて第１の署名鍵を生成し、第１の署名鍵及び前記再署名鍵は、鍵のペアとして生成され、第１の署名鍵は第１の署名鍵生成ユニットへ供給され、前記再署名鍵は前記再署名ユニットへ供給される。このスキームは、何れの鍵も持たないユーザが属性の第２のセットでドキュメントに署名可能にすることを可能にする。専用の第１の署名鍵が、第１の署名を準備するためにユーザに与えられ、この第１の署名は、その後、再署名ユニット及び再署名鍵により属性の第２のセットと関連する署名へ変換される。このように、受任者が再署名鍵生成器から新規な第１の署名鍵を得て、この第１の署名鍵が委託者に代わってメッセージに署名するための再署名鍵及び再署名ユニットと連動して用いられるので、再署名鍵生成器は、受任者ユーザが所有している何れの既存の鍵についても知る必要はない。

当該システムは、条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し、前記再署名鍵は、前記再署名ユニットが、条件のセットを満足させる属性の任意のセットと関連する第１の署名を第２の署名へ変換可能にさせる。これは各ユーザのために再署名鍵を作る必要がないので、システムをよりフレキシブルにし、代わりに、条件のセットを満足する属性のそれぞれのセットと関連する第１の署名鍵を持つ既存のユーザが、ユーザの署名を、属性の第２のセットと関連する署名へ変換できる。条件のセットは、方針（ポリシー）と呼ばれる。

前記再署名ユニットは、第１の署名が条件のセットを満足する属性の第１のセットと関連するかどうかを検証するため公開鍵を使用し、第１の署名が条件のセットを満足する属性のセットと関連する場合だけ第２の署名を生成する。これは、意図された署名だけが変換されるので、システムの安全性を改善し、及び／又は誤った署名が生成されるのを防止する。

当該システムは、属性の第２のセットを所有するユーザが、前記再署名ユニットに前記再署名鍵を供給することにより、属性の第２のセットと関連する署名でドキュメントに署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを有する。これは、署名する権限の委任を容易にする。ユーザにより制御される委任プロセスは、更に、受任者が、再署名ユニットにより、再署名鍵を用いて第１の署名を対応する第２の署名へ変換可能にさせるステップを有する。委任ユニットは、更に、ユーザが、再署名鍵を無効にするか、又は再署名ユニットから取り外し可能にする。これは、署名する権限を取り上げることを容易にする。

別の観点において、本発明は、上述のシステムを有するワークステーションを提供する。

更に他の観点では、本発明は、第１の署名及びドキュメントに基づいて前記ドキュメントに対する第１の署名を生成するステップと、第１の署名及び再署名鍵に基づいて前記ドキュメントに対する第２の署名を生成するステップとを有し、第１及び／又は第２の署名と関連する属性を扱うステップを含む、属性ベースのデジタル署名生成の方法を提供する。

別の観点においては、本発明は、プロセッサシステムが上述の方法を実施させるための命令を有する、コンピュータプログラムを提供する。

米国特許出願公報２００９／０３２７７３５Ａ１は、メッセージｍの受任者の署名を同じメッセージｍの委託者の署名へ変えるための代理再署名システムを開示する。このドキュメントは、属性ベースの署名システムを開示していない。

本発明のこれら及び他の観点は、以下に説明される実施例を参照して明らかに説明されるだろう。

図１は、属性ベースのデジタル再署名システムの図である。 図２は、属性ベースのデジタル再署名方法の流れ図である。 図３は、属性ベースの代理再署名スキームの機能的図である。

この明細書において、属性ベースの代理再署名スキーム（ＰｒｏｘｙＲｅ―ＳｉｇｎａｔｕｒｅＳｃｈｅｍｅ（ＡＢＰＲＳＳ））が開示される。スキームの幾つかのバリエーションが、例として説明されるだろう。しかしながら、当業者は、これらの例のバリエーションを実行できるし、異なる例で説明される特徴を組み合わせることもできる。属性ベースの署名は、グループ署名の形式としてみなされる。これは、認証装置が署名者の属性（例えば役割）を決定可能にする。しかしながら、実際には、１つのエンティティからの署名が他のエンティティの署名へ変換されるシナリオがある。例の１つは、委任シナリオであるが、これは、限定するわけではない。これらのシナリオは、ここで提案されるスキームの種々異なるバリエーションに言及される。スキームは、半信頼されたプロキシ（代理）、又は更に一般的には再署名ユニットを配置し、これは、委託者により与えられる再署名鍵を用いて、署名をエンティティＡ（受任者）からエンティティＢ（委託者）の署名へ変換する。

属性ベースの署名が日常生活の多くのシナリオで有用であり、ヘルスケアの実施は、既存の属性ベースの署名スキームでは利用不可能な多くの付加的な望ましい特徴を提案する。ヘルスケアにおいて、ユーザは、ユーザの同僚（又は従属者）の一人へ署名機能を委任することを頻繁に望む。例えば、医師は、看護士が医師に代わって処方に署名することを望む。この単純なアプローチは、医師が、従来のＡＢＳスキームを使用して、医師に代わって署名するであろう看護士に、医師の秘密鍵を与えることである。明白なように、主要な欠点は、看護士が医師の秘密鍵を学習し、医師の許可のなしに、秘密鍵を使用し続けられるということである。代理再署名スキームは、ある程度安全且つ効率的である態様で、委任機能を提供する代替例を提供する。ここで使用される「安全」という用語は、受任者が委託者の秘密鍵を学習できないことを意味し、「効率的」という用語は、概して鍵記憶等に関する受任者の負担も最小限であることを意味する。

よって、医師のための署名が受任者及び半信頼されたプロキシ（代理）によりできるＡＢＰＲＳＳが提案される。例えば、医師（委託者）は、属性セットω_{ｄｅｌｅｇａｔｏｒ}と関連する医師の秘密鍵ＳＫ_{ωｄｅｌｅｇａｔｏｒ}（第２の署名鍵の例）から、再署名鍵を生成する。その後、再署名鍵は、看護士が看護士の署名を医師（委託者）の署名へ変えるための半信頼された代理を望む場合だけ、（看護士自身の秘密鍵ＳＫ_{ωｄｅｌｅｇａｔｅｅ}（第１の署名鍵の例）を使用して生成される）看護士の署名を医師（委託者）の署名へ変えるための半信頼されたプロキシ（代理）により用いられる。斯様なシステムに対する望ましい特性の１つは、その人自身（看護士又は代理）以外の誰も、医師に代わって署名を作ることが可能であってはならないということである。加えて、看護士と半信頼されたプロキシ（代理）との間の共謀でさえ、彼らにより医師（委託者）の秘密鍵ＳＫ_{ωｄｅｌｅｇａｔｏｒ}を回復可能にしてはならない。

斯様なスキームの適用性は、もちろん委任シナリオだけに限られない。他の例では、ＡＢＰＲＳＳは、従業員の公開鍵の下で検証できる従業員署名を、部門又は会社の公開鍵の下で検証できる部門又は会社署名へ変換するために使用できる。これは、内部監査を依然可能にしながら、会社の事業形態又は従業員プロフィールに関する情報漏えいを防止するのを助ける。

ＡＢＰＲＳＳの他のアプリケーションは、ドキュメントがワークフローチェーンの複数のエンティティにより署名され、各エンティティが属性の異なるセットを持つシナリオである。このように、ドキュメントと共に１つの署名だけが格納される必要があり、提案されたスキームを用いて、検証の際、有効な署名鍵を使用する正しいエンティティにより署名されたことを検証するであろう。

図１を参照して、ＡＢＰＲＳＳの実施例が説明されるだろう。図１は、属性ベースのデジタル署名システムの態様を例示している図を示す。例えば、当該システムは、分散型コンピュータシステム上にロードされる適切なソフトウェアを持つ当該分散型コンピュータシステム上で実行されてもよい。

システムは、公開鍵及びマスター鍵を生成するためのセットアップユニット（図示せず）を有する。その上、システムは、必要に応じてマスター鍵に基づいて、第１の署名鍵１２及び／又は第２の署名鍵１８を生成するための鍵生成ユニット（図示せず）を有する。システムのこの部分は、明快さのために示されていない。

システムは、第１の署名鍵１２及びドキュメント１１に基づいて、ドキュメント１１に対する第１の署名１０を生成するための第１の署名生成ユニット１を有する。この第１の署名鍵１２は、属性ベースの署名スキームに従って、属性１５’のセットと関連してもよく、これは、第１の署名生成ユニット１が属性１５のそのセットと関連する署名１０を生成可能にする。しかしながら、これは、限定的ではない。第１の署名鍵１２及び第１の署名１０が，これらと関連する属性１５’、１５を持たないことも可能である。再署名ユニットによる変換の後、第２の署名１３は、再署名鍵１４により決定される属性１６、１６’’’のセットと関連している。反対に、第２の署名１３及び再署名鍵１４がこれらと関連する属性１６、１６’’’を持たない一方、どのユーザがユーザの第１の署名を第２の署名へ変換できるかを制御するための条件１７、１７’のセットを有するポリシーに対して、第１の署名鍵１２及び第１の署名１０が、再署名ユニット２によりチェックされる属性１５’、１５のセットと関連している場合もある。図１に示されるように、第１の署名鍵１２及び第１の署名１０が、条件１７、１７’のセットに対してチェックされる属性１５’、１５の第１のセットと関連し、再署名鍵１４及び第２の署名１３が、属性１６’’’、１６の異なる第２のセットと関連している場合も可能である。

システムは、更に、第１の署名１０及び再署名鍵１４に基づいて、ドキュメント１１に対する第２の署名１３を生成するために設けられる再署名ユニット２を有する。再署名ユニットは、第１の署名１０と関連する属性１５及び／又は再署名鍵１４と関連する属性１６’’’を処理する。また再署名ユニットは、例えば、この第２の署名１３を属性１６のセットと関連付けることにより、第２の署名１３の任意の属性１６を処理する。通常は、属性１６のこのセットは、再署名鍵１４と関連する属性１６’’’のセットに対応する。結果的に、第２の署名１３と関連する属性１６のセットは、第１の署名１０と関連する属性１５と（あるとしても）異なる。

前述されたように、第１の署名１０は、属性１５の第１のセットと関連し、ここで、属性１５の第１のセットは複数の属性を有する。再署名ユニット２は、第１の署名１０が第２の署名１３へ変換されることが可能であるかどうか検証するために第１の署名１０と関連する属性１５のセットを評価するために設けられる。この検証は属性上の条件１７’のセットを有するポリシーに対して属性１５のセットの遵守を検証するために、公開鍵２０と組み合わせて属性ベースの署名スキームの検証アルゴリズムを使用して、明確になされる。代わりに、検証は、暗になされてもよい。後者の場合、第１の署名１０を第２の署名１３へ変換するため再署名鍵１４を使用するアルゴリズムは、属性１５の第１のセットが条件１７のセットにマッチしない場合、有効な第２の署名１３を作れないような態様で、条件１７のセットは、暗号によって再署名鍵１４へ組み込まれる。更に一般的には、再署名ユニット２は、属性１５の第１のセットが条件１７又は１７’のセットを満たす場合だけ、第２の署名１３を生成するように設けられる。

システムは、ドキュメント１１及び第２の署名鍵１８に基づいて、属性１６’’の第２のセットと関連する署名１９を生成するために、第２の署名生成ユニット４を有する。属性１６’’のこの第２のセットは、第２の署名１３と関連する属性１６の第２のセットに対応し、再署名鍵１４と関連する属性１６’’’の第２のセットと対応する。

典型的なシナリオにおいて、第２の署名生成ユニット４及び第２の署名鍵１８は、属性１６’の第２のセットを所有するユーザにより用いられる。第１の署名生成ユニット１及び再署名ユニット２は、ユーザの代わりに署名するための属性を備えるユーザにより認可されたユーザにより用いられる。再署名鍵生成器３は、特定のユーザ又はユーザのグループがユーザの代わりに署名することを認可するための再署名鍵１４を生成するための属性を備えるユーザにより制御される。

システムは、属性１６’の第２のセットと関連する第２の署名鍵１８に基づいて、再署名鍵１４を生成するための再署名鍵生成器３を有する。この場合、再署名鍵１４は、再署名ユニット２が、第１の署名１０を属性１６の第２のセットと関連する第２の署名１３へ変換可能にする。

再署名鍵生成器３は、また、再署名鍵１４により規定された条件１７のセットを満たしている属性１５のセットと関連する第１の署名１０を変換できる再署名鍵１４を生成するために設けられる。このように再署名鍵は、属性上のポリシー又は条件１７のセットと関連している。再署名ユニット２による変換の処理の際に、第１の署名１０によりデジタル的に表される属性１５は、第２の署名１３を形成するため、再署名鍵１４によりデジタル的に表される条件１７のセットと暗号によって組み合わされる。再署名鍵１４が属性１６’’’の第２のセットと関連するとき、再署名プロセスは、再署名鍵１４と関連する属性１６、１６’’’により、第１の署名１０と関連する属性１５を効果的に置き換える。

再署名鍵生成器３は、第２の署名鍵１８に基づいて、第１の署名鍵１２を更に生成するために設けられる。前記第１の署名鍵１２及び再署名鍵１４は、上述の態様で共に用いられるべく設計された鍵ペアとして生成され、例えば、第１の署名生成ユニット１は、第１の署名鍵１２に基づいて、第１の署名１０を生成し、再署名ユニット２は、再署名している鍵１４を用いて、第１の署名１０を第２の署名１３へ変換する。このために、第１の署名鍵１２は第１の署名生成ユニット１へ供給され、再署名鍵１４は再署名ユニット２へ供給される。

再署名鍵生成器３は、条件１７’’のセットに依存して再署名鍵１４を生成するために設けられる。条件１７’’のこのセットは、以下に説明される委任ユニット５の一部であるユーザ入力デバイスによって、ユーザにより示されてもよい。再署名鍵１４により、再署名ユニット２は、条件１７’’のセットを満たしている属性１５の任意のセットと関連する第１の署名１０を第２の署名１３へ変換可能にする。

代替的に又は追加的に、再署名ユニット２は、第１の署名１０が、条件１７’のセットを満たしている属性１５の第１のセットと関連するかどうかを検証するため公開鍵２０を使用するように設けられる。従って、再署名ユニット２は、第１の署名１０が条件１７’のセットを満たしている属性１５のセットと関連する場合だけ、第２の署名１３を生成するように設けられる。この振る舞いを実施するために、再署名ユニット２は、従来から知られたデジタルセキュリティ技術を使用して、不正使用できなくされている。

第１の署名１０及び第２の署名１３両方が属性のセットと関連するとき、ここで説明されるシステムは、属性の第２のセットと関連する第２の署名１３により、属性１５の第１のセットと関連する第１の署名１０を置き換えるために用いられる。

システムは、再署名ユニット２に再署名鍵１４を供給することにより、属性１６’の第２のセットを所有するユーザが、属性１６の第２のセットと関連する署名でドキュメント１１を署名するユーザの権限を他のユーザへ委任可能にするための委任ユニット５を有する。委任ユニット５は、更に、再署名鍵生成器３及び／又は再署名ユニット２により使用される条件１７、１７’、１７’’のセットをユーザが決定可能にするように設けられる。委任ユニットは、ユーザに適当な委任オプションを提供するユーザインタフェースを有する。

（オプションで属性１６の第２のセットと関連する）第２の署名１３の検証は、検証ユニット（図示せず）を使用して行われる。この検証ユニットは、第２の署名の真正を検証する。この検証は、第２の署名１３がドキュメント１１の有効な署名であるかどうかを検証する。第２の署名が属性１６の第２のセットと関連するとき、検証ユニットは、更に、属性上の条件のセットに対して属性１６の第２の署名の第２のセットを検証する。これらの検証は、署名検証アルゴリズムを使用して実施され、このアルゴリズムの例は以下に説明される。

システムは、ワークステーションで実行されてもよい。代わりに、システムは、分散システムで実行されてもよい。例えば、第１の署名生成ユニット１、再署名ユニット２及び再署名鍵生成器３は、別々のコンピュータ装置でホストされてもよい。再署名鍵生成器３は、第２の署名生成ユニット４と同じコンピュータ装置でホストされてもよい。種々異なる物理的マシンを使用するよりはむしろ、ユーザログインシステムに基づいて、適当なユニット及び鍵への各ユーザアクセスを与えることも可能である。

図２は、属性ベースのデジタル署名生成の例示的方法を図示する。上記システムは、以下の方法又はその変形を実施するような態様で実行される。ステップ２００において、公開鍵パラメータ及びマスター鍵を得るセットアップアルゴリズムが実行される。ステップ２０１において、鍵生成アルゴリズムを用いて、第１のユーザのための第１の署名鍵が生成される。ステップ２０２において、同じ又は異なる鍵生成アルゴリズムを用いて、第２のユーザのための第２の署名鍵が生成される。ステップ２０３において、再署名鍵が、第２の署名鍵に基づいて、再鍵生成アルゴリズムを使用して生成される。この再署名鍵は、再署名ユニット、例えば半信頼されたサーバに格納される。ステップ２０４において、メッセージ又はドキュメントは第１の署名鍵を使用している第１のユーザにより署名され、第１の署名が得られる。ステップ２０５において、第１の署名が変換されるべきかどうかが決定される。変換されるべきでない場合には、プロセスはステップ２０４に戻る。変換されるべき場合、ステップ２０６において、第１の署名は、変換のため再署名ユニットへ送信される。ステップ２０７において、再署名ユニットは、第１の署名を受信して、例えばデータベースルックアップによって、その格納手段内の再署名鍵を識別する。再署名ユニットは、更に、第１の署名と再署名鍵とが合うかどうか、すなわち、第１の署名が再署名鍵を使用して第２の署名へ変換可能であるかどうかを検証し、また、良好に形成された（又は、構築された）署名であることを確認するために第１の署名を検証する。ステップ２０８において、第１の署名が変換可能でない場合、又は、良好に形成された（又は、構築された）署名でない場合、プロセスは、エラーメッセージを作って、ステップ２０４に戻るか、そうではなく可能である場合、ステップ２０９に進む。ステップ２０９において、再署名ユニットは、再署名アルゴリズムを用いて第１の署名を第２の署名へ変換する。ステップ２１０において、第２の署名は第１のユーザのシステムへ送り戻され、第１のユーザは、第２の署名を公的な格納領域に格納するか、又は、例えば、特定の目的ユーザへ第２の署名を送信する。ステップ２１１において、他のユーザ又は目的ユーザは、第２の署名を受信し、第２の署名を検証するために検証アルゴリズムを実行する。この検証は、第２の署名が表すと期待される属性上の条件のセットに対して実施される。

当該方法は、プロセッサシステムに方法を実施させるための命令を有するコンピュータプログラムとして、ソフトウェアで、完全に又は部分的に実行されてもよい。

属性ベースの代理再署名スキーム（ＡＢＰＲＳＳ）は、代理（プロキシ）により、署名σ_{ｄｅｌｅｇａｔｅｅ}を秘密鍵ＳＫ_{ωｄｅｌｅｇａｔｅｅ}を使用して署名されるエンティティＢ（受任者）から、再署名鍵を使用してエンティティＡ（委託者）の署名σ_{ｄｅｌｅｇａｔｏｒ}へ変換可能にさせる。

この説明において、「代理（プロキシ（ｐｒｏｘｙ））」は、再署名生成のための計算を実施できるユニットを指す。このユニット、すなわちプロキシは、再署名鍵の濫用のような悪意のある使用から当該ユニットを保護するために、デジタルセキュリティ機能を具備する。例示的スキームが委託者、受任者鍵及び署名を参照して説明されるだろうが、ここで説明される変換及びアルゴリズムが、一の署名を他の署名への変換を含み、属性ベースの署名スキームを含む種々異なるシナリオでも用いられてもよいことは理解されるだろう。

属性ベースの署名スキーム（ＡＢＳＳ）は、以下のアルゴリズム：１）セットアップ（Ｓｅｔｕｐ）、２）鍵生成、３）署名、４）検証を有する。属性ベースの代理再署名スキーム（ＡＢＰＲＳＳ）は、２つのアルゴリズム：1)再鍵生成、及び２）再署名を加えることにより、機能を拡張する。
これらのアルゴリズムの各々の簡単な説明が、以下に与えられる。
セットアップ：
セットアップアルゴリズムは、初期化フェーズの間に、システムパラメータを設定し、公開パラメータＰＫ及びマスター鍵ＭＫを出力する。
鍵生成（ＭＫ、ω）：
鍵生成アルゴリズムは、入力としてユーザが所有する属性ω及びマスターシークレット鍵ＭＫを採用し、ユーザシークレット鍵ＳＫ_ωを出力する。
再鍵生成（ＳＫ_ω）：
再鍵生成アルゴリズムは、例えば、入力として属性セットωと関連するユーザのシークレット鍵ＳＫωを採用し、エンティティ「Ａ」からの署名をエンティティ「Ｂ」の署名へ変換するために使用できる再署名鍵を出力する。
署名（ＳＫ_{ωｄｅｌｅｇａｔｅｅ}、ＲＳＫ_{ｄｅｌｅｇａｔｅｅ}、ｍ）：
このアルゴリズムは、署名の第１のレベルを作るために、受任者により実行される。このアルゴリズムは、入力として属性セットω_{ｄｅｌｅｇａｔｅｅ}と関連するＳＫ_{ωｄｅｌｅｇａｔｅｅ}、オプションで再署名鍵ＲＳＫ及びメッセージｍを採用する。
再署名（ＲＳＫ_{ｐｒｏｘｙ}、σ_{ｄｅｌｅｇａｔｅｅ}）：
これは、半信頼されたプロキシにより実行される。これは、入力として属性セットω_{ｄｅｌｅｇａｔｏｒ}と関連する再署名鍵及び受任者の署名、すなわちσ_{ｄｅｌｅｇａｔｅｅ}を採用する。これは、委託者のための署名、すなわちσ_{ｄｅｌｅｇａｔｏｒ}を出力する。
検証（σ_{ｄｅｌｅｇａｔｏｒ}、ＰＫ）：
このアルゴリズムは、検証器により実行される。アルゴリズムは、入力としてメッセージｍ、公開鍵ＰＫ及び署名σ_{ｄｅｌｅｇａｔｏｒ}を採用する。アルゴリズムは、署名σ_{ｄｅｌｅｇａｔｏｒ}が有効な署名である場合、１を返し、そうでない場合、エラーシンボル（Ｔ）を返す。

以下に、「第１のスキーム」及び「第２のスキーム」と呼ばれる２つの実施例が、説明される。これらの実施例は、ＡＢＰＲＳＳの２つの異なるスキームを使用する。第１のスキームにおいて、属性セット「ω（委託者により所有される）」と関連する再署名鍵は、２つのコンポーネント、一方は受任者に対して、他方は半信頼されたプロキシ（代理）に対してのコンポーネントに分けられ、これらは何れも単独では委託者に対する署名を生成できない。第２のスキームにおいて、再署名鍵は半信頼されたプロキシだけに与えられる一方、受任者は、属性セット「ω（受任者により所有される）」と関連する自身の秘密鍵を使用して署名する。第２のスキームにおいて、受任者と委託者との間でインタラクションは必要とされず、受任者は委託者に代わって署名するための余分の再署名鍵を格納する必要はない。受任者の署名が委託者（エンティティ「Ａ」）の署名へ変換されることを受任者（エンティティ「Ｂ」）が望む場合、エンティティ「Ｂ」は、半信頼されたプロキシにより変換できるように第１のレベルの署名を作る。

第１のスキーム及び第２のスキームが、ここで説明される種類のシステム及び方法の可能な実行の単なる例を表すことは、理解されるだろう。これらのスキームの変更は可能である。以下に説明されるアルゴリズムは、例えば、図１を参照して説明されるシステムの種々異なるユニットを実行するか、又は、図２を参照して説明される方法のステップを更に定めるために当業者により用いられる。

第１のスキームにおいて、再署名鍵ＲＳＫの第１の部分は、エンティティＡ（受任者）に与えられ、再署名鍵ＲＳＫの第２の部分はプロキシに与えられる。エンティティＡ（受任者）が最初にメッセージに署名する場合だけ、有効な署名が半信頼されたプロキシにより作られる。この場合、受任者は、余分の秘密鍵、すなわち再署名鍵ＲＳＫの部分を格納しなければならない。

第２のスキームにおいて、受任者は、受任者により所有される属性セットω_{ｄｅｌｅｇａｔｅｅ}と関連する秘密鍵ＳＫ_{ωｄｅｌｅｇａｔｅｅ}を使用して、第１のレベルの署名σ_{ｄｅｌｅｇａｔｅｅ}を作る。受任者と委託者との間のインタラクションのための必要性はない。受任者の署名をエンティティＡ（委託者）の署名へ変換することを受任者が望む場合、受任者の署名は、２、３の余分のコンポーネントを有する。これらの余分のコンポーネントにより、プロキシが、署名σ_{ｄｅｌｅｇａｔｅｅ}をエンティティＡ（委託者）の署名σ_{ｄｅｌｅｇａｔｏｒ}へ変換可能にする。

図３は、属性ベースの代理再署名スキームの機能的図を提供する。ステップ３０１において、エンティティ「Ａ」は、再生成アルゴリズムを用いて、再署名鍵ＲＳＫを生成する。ＲＳＫは、２つのコンポーネント：プロキシに対するコンポーネント及びエンティティ「Ｂ」に対するコンポーネントを有する。これは、第１のデザインされたスキームの場合である。上記で紹介された第２のスキームにおいて、これは、プロキシに対する１つのコンポーネントを有する。ステップ３０２及び３０３において、再署名鍵、すなわちＲＳＫ_{ｐｒｏｘｙ}及びＲＳＫ_{ｄｅｌｅｇａｔｅｅ}が、プロキシ「Ｐ」及びエンティティ「Ｂ」それぞれに送られる。ステップ３０４において、エンティティ「Ｂ」は、ＲＳＫ_{ｄｅｌｅｇａｔｅｅ}（第１のスキームで）又はＳＫ_{ｄｅｌｅｇａｔｅｅ}（第２のスキームで）を使用して、エンティティ「Ｂ」の署名を生成する。ステップ３０５において、エンティティ「Ｂ」は、プロキシ「Ｐ」にステップ４の出力を送る。ステップ３０６において、半信頼されたプロキシは、エンティティ「Ｂ」から受信された署名をエンティティ「Ａ」の署名へ変換する。ステップ３０７において、プロキシ「Ｐ」は、エンティティ「Ａ」を代表して作られた署名を検証器「Ｖ」（又は、署名されたメッセージの受信器）へ送る。ステップ３０８において、検証器「Ｖ」は、署名がエンティティ「Ａ」からであるかどうか、属性の正しいセットに関係のある秘密鍵により署名されているかどうかを検証する。

第１のスキームにおいて、ユーザ属性はＺ_ｐの要素であり、最大ｋ個の属性があるとみなされている。実際上、属性ストリングをＺ_ｐの要素へマップするための対立耐性のあるハッシュ関数を使用できる。当該スキームは、４つのアルゴリズムを有する。
セットアップ
セットアップアルゴリズムは、主要なオーダーｐ並びにランダムジェネレータｇ及びｈの双一次グループＧ_０を選択する。また、双一次マップｅ：Ｇ_０ｘＧ_０→Ｇ_１を選び、ここで、Ｇ_１はターゲットグループである。加えて、セットアップは、無作為に

を取り上げ、属性のセット

のために、

及び

を（１≦ｊ≦ｋ）に対してセットする。公開鍵ＰＫ及びマスター鍵ＭＫは、以下のコンポーネントを有する。

鍵生成（ＭＫ、ω）
鍵生成アルゴリズムは、属性セットωと関連するユーザ秘密鍵を出力する。当該アルゴリズムは、ランダムな要素

を取り上げる（ここで、ｘは各ユーザに対して固有である）。秘密鍵ＳＫ_ωは、以下のコンポーネントを有する。

再鍵生成（ＳＫ_ω）
このアルゴリズムは、委託者により実行される。再鍵生成アルゴリズムは、委託者に代わって署名するためプロキシ及び受任者により用いられる再署名鍵を出力する。当該アルゴリズムは、ランダムな要素

を取り上げて、これらをｄ＝ｄ_１＋ｄ_２となるような２つの部分ｄ_１、ｄ_２へ分割する。再署名鍵ＲＳＫ_ωは、一方が受任者に対するコンポーネント、他方がプロキシに対するコンポーネントである、以下の２つのコンポーネントを有する。

署名（ＲＳＫ_{ｄｅｌｅｇａｔｅｅ}、ｍ）
このアルゴリズムは、メッセージ

に署名するため受任者により実行される。当該アルゴリズムは、ランダムな要素

を選んで、以下のコンポーネントを有する署名σ_{ｄｅｌｅｇａｔｅｅ}を計算する。

再署名（ＲＳＫ_{ｐｒｏｘｙ}、σ_{ｄｅｌｅｇａｔｅｅ}、ｍ）
このアルゴリズムは、プロキシにより実行される。第２のレベル（又は、最終的な署名）を作る前に、プロキシは、以下の態様で受任者により作られる署名を検証する。

ここで、Ｉ^（１）＝Ｉ^（２）の場合、プロキシは第２のレベルの（又は、最終的な）署名を作るため受任者により作られる署名を変換する。当該アルゴリズムは、ランダムな要素

を選んで、第２のレベルの署名を作る。

検証（σ_{ｐｒｏｘｙ}、ＰＫ）
以下の式が成り立つ場合、署名が受け入れられる。

以下に、属性ベースの代理再署名システムの第２実施例の説明が与えられる。当該システムは、以下のアルゴリズムの実行を有する。

セットアップ
セットアップアルゴリズムは、主要なオーダーｐ並びにランダムジェネレータｇ及びｈの双一次グループＧ_０を選択する。当該アルゴリズムは、双一次マップｅ：Ｇ_０ｘＧ_０→Ｇ_１を選ぶ。これ（の選択）に加えて、セットアップは、無作為に

を取り上げ、属性のセット

のために、

及び

を（１≦ｊ≦ｋ）に対してセットする。公開鍵ＰＫ及びマスター鍵ＭＫは、以下のコンポーネントを有する。

鍵生成（ＭＫ、ω）
鍵生成アルゴリズムは、属性セットωと関連するユーザ秘密鍵を出力する。アルゴリズムは、ｘ＝ｔｑとなるように、ランダムな要素

を取り上げる（ここで、ｘ、ｔ及びｑは各ユーザに対して固有である）。秘密鍵ＳＫ_ωは、以下のコンポーネントを有する。

再鍵生成（ＳＫ_{ωｄｅｌｅｇａｔｏｒ}）
再鍵生成アルゴリズムは、受任者からの署名を委託者の署名に変換するためにプロキシにより用いられる再署名鍵を出力する。当該アルゴリズムは、ランダムな要素

を取り上げる。再署名鍵ＲＳＫ_ωは、以下の２つのコンポーネントを有する。

署名（ＳＫ_{ωｄｅｌｅｇａｔｅｅ}、ｍ）
このアルゴリズムは、メッセージ

に署名するために受任者により実行される。当該アルゴリズムは、ランダムな要素

を選んで、自分自身の秘密鍵を使用して署名σ_{ｄｅｌｅｇａｔｅｅ}を計算する。σ_ｄｅｅとも呼ばれる署名σ_{ｄｅｌｅｇａｔｅｅ}は、以下のコンポーネントを有する。

再署名（ＲＳＫ、σ_{ｄｅｌｅｇａｔｅｅ}、ｍ）
このアルゴリズムは、プロキシにより実行される。当該アルゴリズムは、ランダムな要素

を選んで、受任者の署名を委託者の署名へ変換する。署名を変換する前に、プロキシは、署名が対応する受任者からの実際有効な署名であるかどうかを検証する。検証は、以下のように進む。

ここで、Ｉ^（１）＝Ｉ^（２）の場合、検証は成功し、プロキシは、第２のレベルの（又は、最終的な）署名を生成する。第２のレベルの署名の生成は、以下のステップを有する。
第１のステップにおいて、プロキシは、以下を計算する。

第２のステップにおいて、プロキシは、以下を計算する。

第３のステップにおいて、プロキシは、以下を計算する。

ここで、「Ｈ」は、ハッシュ関数である。
第４のステップにおいて、プロキシは、以下を計算する。

最終ステップにおいて、プロキシは、署名を出力する。

検証（σ_{ｐｒｏｘｙ}、ＰＫ）
変換された署名を検証するために、検証器は、以下のステップを実施する。
第１ステップにおいて、検証器は、以下を計算する。

第２ステップにおいて、以下の式が成り立つ場合、検証器は、署名を受け入れる。

第１及び第２の実施例における上述のアルゴリズムは、図１を参照して説明されるシステムの実施例及び図２を参照して説明される方法の実施例に適用できることは、理解されるだろう。

本発明は、また、本発明を実行するために適応された、コンピュータプログラム、特にキャリア上又はミャリア内のコンピュータプログラムにも適用することは、理解されるだろう。プログラムは、ソースコード、オブジェクトコードの形式でもよく、部分的にコンパイルされた形式でのようなソース及びオブジェクトコードの中間コード、又は本発明による方法の実行の使用に適している他の任意の形式でもよい。斯様なプログラムは、多くの異なるアーキテクチャデザインを持つとも理解されるだろう。例えば、本発明による方法又はシステムの機能を実行するプログラムコードは、一つ以上のサブルーチンに副分割されてもよい。これらのサブルーチンに機能を分散させる多くの種々異なる態様は、当業者に明らかであろう。サブルーチンは、自己充足的なプログラムを形成するために、１つの実行可能ファイルに一緒に格納されてもよい。斯様な実行可能ファイルは、コンピュータ実行可能な命令、例えば、プロセッサ命令及び／又はインタプリタ命令（例えばＪａｖａ（登録商標）インタプリタ命令）を有する。代わりに、サブルーチンの一つ以上又は全ては、少なくとも一つの外部ライブラリファイルに格納され、静的に又は動的に、例えば実行時に、メインプログラムとリンクされてもよい。メインプログラムは、サブルーチンの少なくとも１つへの少なくとも一つのコールを含む。サブルーチンは、また、互いへのファンクションコールを有してもよい。コンピュータプログラムに関係する実施例は、ここで説明された方法の少なくとも１つの各処理ステップに対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに副分割され、及び／又は静的若しくは動的にリンクされる一つ以上のファイルに格納されてもよい。コンピュータプログラムに関係する他の実施例は、ここで説明されたシステム及び／又はプロダクトの少なくとも１つの各手段に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに副分割され、及び／又は静的若しくは動的にリンクされる一つ以上のファイルに格納されてもよい。

コンピュータプログラムのキャリアは、プログラムを坦持できる任意のエンティティ又は装置でもよい。例えば、キャリアは、ＲＯＭ、例えば、ＣＤ―ＲＯＭ若しくは半導体ＲＯＭ、又は磁気記録媒体、例えば、ハードディスクのような記憶媒体を含む。更にまた、キャリアは、電気ケーブル若しくは光ケーブルを介して、又は無線若しくは他の手段により伝達される電気的信号又は光信号のような送信可能なキャリアである。プログラムが斯様な信号で具現化されるとき、キャリアは、斯様なケーブル又は他の装置若しくは手段により構成されてもよい。代わりに、キャリアは、プログラムが埋め込まれている集積回路でもよく、当該集積回路は、関連した方法を実施するために、又は関連した方法のパフォーマンスで使用されるのに適している。

上述の実施例は、本発明を制限するよりはむしろ例示するものであり、当業者は、添付の請求の範囲の要旨を逸脱しない範囲で多くの代替の実施例をデザイン可能であることは、留意されたい。請求項において、括弧に配置された何れの参照符号も、請求項を制限するものとして解釈されない。動詞「有する」及びその関連語の使用は、請求項に述べられたもの以外の要素又はステップの存在を除外しない。要素に先立つ冠詞「ａ」又は「ａｎ」は、複数の要素の存在を除外しない。本発明は、幾つかの異なった要素を有するハードウェアによって、また、最適にプログラムされたコンピュータによって実行されてもよい。幾つかの手段を列挙している装置の請求項において、これらの手段の幾つかは、ハードウェアの全く同一の部材により具現化されてもよい。特定の方策が相互に異なる従属請求項において引用されているという単なる事実は、これらの方策の組合せが効果的に使用できないことを示すわけではない。

Claims (11)

1. 第１の署名鍵及びドキュメントに基づいて、前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと、第１の署名及び再署名鍵に基づいて、前記ドキュメントに対する第２の署名を生成するための再署名ユニットとを有し、前記再署名ユニットは第１の署名及び／又は第２の署名と関連した属性を扱う、属性ベースのデジタル署名システム。
2. 第２の署名は前記再署名鍵により決定される属性の第２のセットと関連し、属性の第２のセットは、複数の属性を有する、請求項１に記載のシステム。
3. 第１の署名は属性の第１のセットと関連し、属性の第１のセットは複数の属性を有し、前記再署名ユニットは、属性の第１のセットが条件のセットを満足する場合だけ、第２の署名を生成する、請求項１又は２に記載のシステム。
4. 属性の第２のセットと関連した第２の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し、前記再署名鍵は、前記再署名ユニットが、第１の署名を属性の第２のセットと関連する第２の署名へ変換可能にし、第２の署名鍵は、第２の署名生成ユニットが前記ドキュメントに基づいて属性の第２のセットと関連する署名を生成可能にする、請求項２に記載のシステム。
5. 前記再署名鍵生成器は、更に、第２の署名鍵に基づいて第１の署名鍵を生成し、第１の署名鍵及び前記再署名鍵は、鍵のペアとして生成され、第１の署名鍵は第１の署名生成ユニットへ供給され、前記再署名鍵は前記再署名ユニットへ供給される、請求項４に記載のシステム。
6. 条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し、前記再署名鍵は、前記再署名ユニットが、条件のセットを満足させる属性の任意のセットと関連する第１の署名を第２の署名へ変換可能にさせる、請求項３に記載のシステム。
7. 前記再署名ユニットは、第１の署名が条件のセットを満足する属性の第１のセットと関連するかどうかを検証するため公開鍵を使用し、第１の署名が条件のセットを満足する属性のセットと関連する場合だけ第２の署名を生成する、請求項３に記載のシステム。
8. 属性の第２のセットを所有するユーザが、前記再署名ユニットに前記再署名鍵を供給することにより、属性の第２のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する、請求項１に記載のシステム。
9. 請求項１に記載のシステムを有するワークステーション。
10. 第１の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第１の署名を生成するステップと、第１及び／又は第２の署名と関連する属性を扱うステップを含んで、第１の署名及び再署名鍵に基づいて、前記ドキュメントに対する第２の署名を生成するステップとを有する、方法。
11. プロセッサシステムが請求項１０に記載の方法を実施させるための命令を有する、コンピュータプログラム。

Images