"第1の署名鍵及びドキュメントに基づいて、前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと、第1の署名及び再署名鍵に基づいて、前記ドキュメントに対する第2の署名を生成するための再署名ユニットとを有し、前記再署名ユニットは第1の署名及び/又は第2の署名と関連した属性を扱う、属性ベースのデジタル署名システム。第2の署名は前記再署名鍵により決定される属性の第2のセットと関連し、属性の第2のセットは、複数の属性を有する、請求項1に記載のシステム。第1の署名は属性の第1のセットと関連し、属性の第1のセットは複数の属性を有し、前記再署名ユニットは、属性の第1のセットが条件のセットを満足する場合だけ、第2の署名を生成する、請求項1又は2に記載のシステム。属性の第2のセットと関連した第2の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し、前記再署名鍵は、前記再署名ユニットが、第1の署名を属性の第2のセットと関連する第2の署名へ変換可能にし、第2の署名鍵は、第2の署名生成ユニットが前記ドキュメントに基づいて属性の第2のセットと関連する署名を生成可能にする、請求項2に記載のシステム。前記再署名鍵生成器は、更に、第2の署名鍵に基づいて第1の署名鍵を生成し、第1の署名鍵及び前記再署名鍵は、鍵のペアとして生成され、第1の署名鍵は第1の署名生成ユニットへ供給され、前記再署名鍵は前記再署名ユニットへ供給される、請求項4に記載のシステム。条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し、前記再署名鍵は、前記再署名ユニットが、条件のセットを満足させる属性の任意のセットと関連する第1の署名を第2の署名へ変換可能にさせる、請求項3に記載のシステム。前記再署名ユニットは、第1の署名が条件のセットを満足する属性の第1のセットと関連するかどうかを検証するため公開鍵を使用し、第1の署名が条件のセットを満足する属性のセットと関連する場合だけ第2の署名を生成する、請求項3に記載のシステム。属性の第2のセットを所有するユーザが、前記再署名ユニットに前記再署名鍵を供給することにより、属性の第2のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する、請求項1に記載のシステム。請求項1に記載のシステムを有するワークステーション。第1の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第1の署名を生成するステップと、第1及び/又は第2の署名と関連する属性を扱うステップを含んで、第1の署名及び再署名鍵に基づいて、前記ドキュメントに対する第2の署名を生成するステップとを有する、方法。プロセッサシステムが請求項10に記載の方法を実施させるための命令を有する、コンピュータプログラム。ヘルスケアのワークフローの重要な観点の1つは、発信元の否認防止であり、これは、データの受取人がデータ発信元を検証できることを意味する。日常生活において、デジタル署名は、否認防止特性を実行するために用いられる。従来の署名スキームでは、個人的及び公的な鍵ペアが各ユーザに対して生成され、当該ペアの秘密鍵がメッセージに署名するために使用される一方、公開鍵がメッセージの署名を認証するために用いられる。しかしながら、ヘルスケア組織では、属性は、通常、ユーザの役割及び同一性を記述するために用いられ、データへのアクセスはユーザ属性に基づいて付与されている。よって、ユーザは、ユーザが正しいセットの属性を持つ場合に限り、そのデータを作るか修正して、その後署名してもよい。この目的のために、例えば、DaliaKhaderAttributeBasedGroupSignaturesInternationalAssociationforCryptologicResearch2007241に記載されているように、属性ベースの署名が使われている。よって、ヘルスケアでは、属性は、データ発信元を証明する主要なソースであるとみなされる。これらの属性は、また、特定のドメイン例えば名前又は識別子の個人に固有である個々の属性を有する。例えば、処方箋が特定の役割を持つ特定のユーザ例えば医師ジョンスミスにより署名された場合、薬局は、処方箋を受理するだろう。匿名が重要である医学調査に関係する他の使用の場合、患者は、患者は30―40歳の男性であるような患者の非固有の属性だけを使用して患者のヘルス記録に署名できる。よって、ヘルスデータの保護に対する属性ベースの暗号化ABEシステムの重要なコンポーネントは、属性ベースの署名ABSスキームである。属性ベースの署名ABSにおいて、データは、ユーザにより所有される属性セットωと関連した暗号鍵SKωを使用して署名される。メッセージに署名可能にするために、ユーザは、認証機関から、ユーザが持つ認定された属性のセットに対応する特定の私有鍵を得る。既述されたように、ユーザは、ユーザが特定の署名動作のために使用を望む属性のサブセットに関係する秘密鍵のサブセットを選択するための柔軟性も有する。改良された属性ベースのデジタル署名システムを持つことは、有利であろう。この懸念に良好に対処するために、第1の観点では、本発明は、第1の署名鍵及びドキュメントに基づいて、前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと、第1の署名及び再署名鍵に基づいて、前記ドキュメントに対する第2の署名を生成するための再署名ユニットとを有し、前記再署名ユニットは第1の署名及び/又は第2の署名と関連した属性を扱う、属性ベースのデジタル署名システムを提供する。このシステムは、署名と関連する属性に基づいて、再署名機能を構成可能にする。再署名ユニットのため、署名のための権限は、受任者に委託者の署名鍵を与えることなく、委託される。代わりに、受任者は、半信頼されたユニット、すなわちプロキシ代理である再署名ユニットを使用して、受任者の署名を委託者の署名へ変換可能にされる。署名と関連する属性を扱うための再署名ユニットを構成することにより、再署名機能は、よりフレキシブルになる。鍵の属性は、例えば、第1の署名と関連したどんな属性が再署名ユニットを使用するために必要とされるか、及び/又は、どんな属性が第2の署名と関連するかを特定するために使用できるので、委任作業はユーザごとに遂行される必要はない。結果的に、委託者は、委託者の属性に基づいて、作業をユーザのグループへ委任できる。第1の署名を第2の署名へ変換するための再署名ユニットが設けられ、ここで、第2の署名はドキュメントに対する第1の署名と置き換わり、第2の署名は第1の署名と独立して検証できる。第2の署名は、前記再署名鍵により決定される属性の第2のセットと関連し、属性の第2のセットは、複数の属性を有する。再署名ユニットは、第1の署名を属性の第2のセットと関連する署名へ変換可能にする。これは、既存の属性ベースのデジタル署名システムで実行できない幾つかの使用シナリオを実行可能にする。例えば、システムは、属性のそのセットと関連する署名鍵をユーザに与えることなしに、属性の特定のセットを持つドキュメントに署名する権限をユーザに委任可能にする。代わりに、ユーザは、第1の署名鍵だけを与えられ、第1の署名鍵で生成される署名を、属性の第2のセットと関連する所望の第2の署名へ変換するために、再署名ユニットを起動する必要があるだけである。再署名ユニットは、半信頼されたプロキシ代理として実行される。代替的に又は追加的に、第1の署名は、属性の第1のセットと関連し、属性の第1のセットは複数の属性を有し、前記再署名ユニットは、属性の第1のセットが条件のセットを満足する場合だけ、第2の署名を生成する。これは、受任者の特定のユーザIDを特定することなしに、委託者がユーザのグループに権限付与認可可能にする。代わりに、認可は、第1の署名鍵で表されるユーザの属性例えば、役割に基づいて実施できる。当該システムは、属性の第2のセットと関連した第2の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し、前記再署名鍵は、前記再署名ユニットが、第1の署名を属性の第2のセットと関連する第2の署名へ変換可能にし、第2の署名鍵は、第2の署名生成ユニットが前記ドキュメント自体に基づいて属性の第2のセットと関連する署名を生成可能にする。通常は、第2の署名鍵の制御は、属性の第2のセットでドキュメントに署名する権限を持つ人に委任される。説明されているように再署名鍵生成器を使用して、その人は、第2の署名鍵を再署名鍵生成器へ供給することにより、再署名鍵を作ることができる。属性ベースの署名システムの何れのマスター鍵も必要ではない。これは、署名するための権限を委任することを比較的容易にする。前記再署名鍵生成器は、更に、第2の署名鍵に基づいて第1の署名鍵を生成し、第1の署名鍵及び前記再署名鍵は、鍵のペアとして生成され、第1の署名鍵は第1の署名鍵生成ユニットへ供給され、前記再署名鍵は前記再署名ユニットへ供給される。このスキームは、何れの鍵も持たないユーザが属性の第2のセットでドキュメントに署名可能にすることを可能にする。専用の第1の署名鍵が、第1の署名を準備するためにユーザに与えられ、この第1の署名は、その後、再署名ユニット及び再署名鍵により属性の第2のセットと関連する署名へ変換される。このように、受任者が再署名鍵生成器から新規な第1の署名鍵を得て、この第1の署名鍵が委託者に代わってメッセージに署名するための再署名鍵及び再署名ユニットと連動して用いられるので、再署名鍵生成器は、受任者ユーザが所有している何れの既存の鍵についても知る必要はない。当該システムは、条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し、前記再署名鍵は、前記再署名ユニットが、条件のセットを満足させる属性の任意のセットと関連する第1の署名を第2の署名へ変換可能にさせる。これは各ユーザのために再署名鍵を作る必要がないので、システムをよりフレキシブルにし、代わりに、条件のセットを満足する属性のそれぞれのセットと関連する第1の署名鍵を持つ既存のユーザが、ユーザの署名を、属性の第2のセットと関連する署名へ変換できる。条件のセットは、方針ポリシーと呼ばれる。前記再署名ユニットは、第1の署名が条件のセットを満足する属性の第1のセットと関連するかどうかを検証するため公開鍵を使用し、第1の署名が条件のセットを満足する属性のセットと関連する場合だけ第2の署名を生成する。これは、意図された署名だけが変換されるので、システムの安全性を改善し、及び/又は誤った署名が生成されるのを防止する。当該システムは、属性の第2のセットを所有するユーザが、前記再署名ユニットに前記再署名鍵を供給することにより、属性の第2のセットと関連する署名でドキュメントに署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを有する。これは、署名する権限の委任を容易にする。ユーザにより制御される委任プロセスは、更に、受任者が、再署名ユニットにより、再署名鍵を用いて第1の署名を対応する第2の署名へ変換可能にさせるステップを有する。委任ユニットは、更に、ユーザが、再署名鍵を無効にするか、又は再署名ユニットから取り外し可能にする。これは、署名する権限を取り上げることを容易にする。別の観点において、本発明は、上述のシステムを有するワークステーションを提供する。更に他の観点では、本発明は、第1の署名及びドキュメントに基づいて前記ドキュメントに対する第1の署名を生成するステップと、第1の署名及び再署名鍵に基づいて前記ドキュメントに対する第2の署名を生成するステップとを有し、第1及び/又は第2の署名と関連する属性を扱うステップを含む、属性ベースのデジタル署名生成の方法を提供する。別の観点においては、本発明は、プロセッサシステムが上述の方法を実施させるための命令を有する、コンピュータプログラムを提供する。米国特許出願公報2009/0327735A1は、メッセージmの受任者の署名を同じメッセージmの委託者の署名へ変えるための代理再署名システムを開示する。このドキュメントは、属性ベースの署名システムを開示していない。本発明のこれら及び他の観点は、以下に説明される実施例を参照して明らかに説明されるだろう。この明細書において、属性ベースの代理再署名スキームProxyRe―SignatureSchemeABPRSSが開示される。スキームの幾つかのバリエーションが、例として説明されるだろう。しかしながら、当業者は、これらの例のバリエーションを実行できるし、異なる例で説明される特徴を組み合わせることもできる。属性ベースの署名は、グループ署名の形式としてみなされる。これは、認証装置が署名者の属性例えば役割を決定可能にする。しかしながら、実際には、1つのエンティティからの署名が他のエンティティの署名へ変換されるシナリオがある。例の1つは、委任シナリオであるが、これは、限定するわけではない。これらのシナリオは、ここで提案されるスキームの種々異なるバリエーションに言及される。スキームは、半信頼されたプロキシ代理、又は更に一般的には再署名ユニットを配置し、これは、委託者により与えられる再署名鍵を用いて、署名をエンティティA受任者からエンティティB委託者の署名へ変換する。属性ベースの署名が日常生活の多くのシナリオで有用であり、ヘルスケアの実施は、既存の属性ベースの署名スキームでは利用不可能な多くの付加的な望ましい特徴を提案する。ヘルスケアにおいて、ユーザは、ユーザの同僚又は従属者の一人へ署名機能を委任することを頻繁に望む。例えば、医師は、看護士が医師に代わって処方に署名することを望む。この単純なアプローチは、医師が、従来のABSスキームを使用して、医師に代わって署名するであろう看護士に、医師の秘密鍵を与えることである。明白なように、主要な欠点は、看護士が医師の秘密鍵を学習し、医師の許可のなしに、秘密鍵を使用し続けられるということである。代理再署名スキームは、ある程度安全且つ効率的である態様で、委任機能を提供する代替例を提供する。ここで使用される安全という用語は、受任者が委託者の秘密鍵を学習できないことを意味し、効率的という用語は、概して鍵記憶等に関する受任者の負担も最小限であることを意味する。よって、医師のための署名が受任者及び半信頼されたプロキシ代理によりできるABPRSSが提案される。例えば、医師委託者は、属性セットωdelegatorと関連する医師の秘密鍵SKωdelegator第2の署名鍵の例から、再署名鍵を生成する。その後、再署名鍵は、看護士が看護士の署名を医師委託者の署名へ変えるための半信頼された代理を望む場合だけ、看護士自身の秘密鍵SKωdelegatee第1の署名鍵の例を使用して生成される看護士の署名を医師委託者の署名へ変えるための半信頼されたプロキシ代理により用いられる。斯様なシステムに対する望ましい特性の1つは、その人自身看護士又は代理以外の誰も、医師に代わって署名を作ることが可能であってはならないということである。加えて、看護士と半信頼されたプロキシ代理との間の共謀でさえ、彼らにより医師委託者の秘密鍵SKωdelegatorを回復可能にしてはならない。斯様なスキームの適用性は、もちろん委任シナリオだけに限られない。他の例では、ABPRSSは、従業員の公開鍵の下で検証できる従業員署名を、部門又は会社の公開鍵の下で検証できる部門又は会社署名へ変換するために使用できる。これは、内部監査を依然可能にしながら、会社の事業形態又は従業員プロフィールに関する情報漏えいを防止するのを助ける。ABPRSSの他のアプリケーションは、ドキュメントがワークフローチェーンの複数のエンティティにより署名され、各エンティティが属性の異なるセットを持つシナリオである。このように、ドキュメントと共に1つの署名だけが格納される必要があり、提案されたスキームを用いて、検証の際、有効な署名鍵を使用する正しいエンティティにより署名されたことを検証するであろう。図1を参照して、ABPRSSの実施例が説明されるだろう。図1は、属性ベースのデジタル署名システムの態様を例示している図を示す。例えば、当該システムは、分散型コンピュータシステム上にロードされる適切なソフトウェアを持つ当該分散型コンピュータシステム上で実行されてもよい。システムは、公開鍵及びマスター鍵を生成するためのセットアップユニット図示せずを有する。その上、システムは、必要に応じてマスター鍵に基づいて、第1の署名鍵12及び/又は第2の署名鍵18を生成するための鍵生成ユニット図示せずを有する。システムのこの部分は、明快さのために示されていない。システムは、第1の署名鍵12及びドキュメント11に基づいて、ドキュメント11に対する第1の署名10を生成するための第1の署名生成ユニット1を有する。この第1の署名鍵12は、属性ベースの署名スキームに従って、属性15’のセットと関連してもよく、これは、第1の署名生成ユニット1が属性15のそのセットと関連する署名10を生成可能にする。しかしながら、これは、限定的ではない。第1の署名鍵12及び第1の署名10が,これらと関連する属性15’、15を持たないことも可能である。再署名ユニットによる変換の後、第2の署名13は、再署名鍵14により決定される属性16、16’’’のセットと関連している。反対に、第2の署名13及び再署名鍵14がこれらと関連する属性16、16’’’を持たない一方、どのユーザがユーザの第1の署名を第2の署名へ変換できるかを制御するための条件17、17’のセットを有するポリシーに対して、第1の署名鍵12及び第1の署名10が、再署名ユニット2によりチェックされる属性15’、15のセットと関連している場合もある。図1に示されるように、第1の署名鍵12及び第1の署名10が、条件17、17’のセットに対してチェックされる属性15’、15の第1のセットと関連し、再署名鍵14及び第2の署名13が、属性16’’’、16の異なる第2のセットと関連している場合も可能である。システムは、更に、第1の署名10及び再署名鍵14に基づいて、ドキュメント11に対する第2の署名13を生成するために設けられる再署名ユニット2を有する。再署名ユニットは、第1の署名10と関連する属性15及び/又は再署名鍵14と関連する属性16’’’を処理する。また再署名ユニットは、例えば、この第2の署名13を属性16のセットと関連付けることにより、第2の署名13の任意の属性16を処理する。通常は、属性16のこのセットは、再署名鍵14と関連する属性16’’’のセットに対応する。結果的に、第2の署名13と関連する属性16のセットは、第1の署名10と関連する属性15とあるとしても異なる。前述されたように、第1の署名10は、属性15の第1のセットと関連し、ここで、属性15の第1のセットは複数の属性を有する。再署名ユニット2は、第1の署名10が第2の署名13へ変換されることが可能であるかどうか検証するために第1の署名10と関連する属性15のセットを評価するために設けられる。この検証は属性上の条件17’のセットを有するポリシーに対して属性15のセットの遵守を検証するために、公開鍵20と組み合わせて属性ベースの署名スキームの検証アルゴリズムを使用して、明確になされる。代わりに、検証は、暗になされてもよい。後者の場合、第1の署名10を第2の署名13へ変換するため再署名鍵14を使用するアルゴリズムは、属性15の第1のセットが条件17のセットにマッチしない場合、有効な第2の署名13を作れないような態様で、条件17のセットは、暗号によって再署名鍵14へ組み込まれる。更に一般的には、再署名ユニット2は、属性15の第1のセットが条件17又は17’のセットを満たす場合だけ、第2の署名13を生成するように設けられる。システムは、ドキュメント11及び第2の署名鍵18に基づいて、属性16’’の第2のセットと関連する署名19を生成するために、第2の署名生成ユニット4を有する。属性16’’のこの第2のセットは、第2の署名13と関連する属性16の第2のセットに対応し、再署名鍵14と関連する属性16’’’の第2のセットと対応する。典型的なシナリオにおいて、第2の署名生成ユニット4及び第2の署名鍵18は、属性16’の第2のセットを所有するユーザにより用いられる。第1の署名生成ユニット1及び再署名ユニット2は、ユーザの代わりに署名するための属性を備えるユーザにより認可されたユーザにより用いられる。再署名鍵生成器3は、特定のユーザ又はユーザのグループがユーザの代わりに署名することを認可するための再署名鍵14を生成するための属性を備えるユーザにより制御される。システムは、属性16’の第2のセットと関連する第2の署名鍵18に基づいて、再署名鍵14を生成するための再署名鍵生成器3を有する。この場合、再署名鍵14は、再署名ユニット2が、第1の署名10を属性16の第2のセットと関連する第2の署名13へ変換可能にする。再署名鍵生成器3は、また、再署名鍵14により規定された条件17のセットを満たしている属性15のセットと関連する第1の署名10を変換できる再署名鍵14を生成するために設けられる。このように再署名鍵は、属性上のポリシー又は条件17のセットと関連している。再署名ユニット2による変換の処理の際に、第1の署名10によりデジタル的に表される属性15は、第2の署名13を形成するため、再署名鍵14によりデジタル的に表される条件17のセットと暗号によって組み合わされる。再署名鍵14が属性16’’’の第2のセットと関連するとき、再署名プロセスは、再署名鍵14と関連する属性16、16’’’により、第1の署名10と関連する属性15を効果的に置き換える。再署名鍵生成器3は、第2の署名鍵18に基づいて、第1の署名鍵12を更に生成するために設けられる。前記第1の署名鍵12及び再署名鍵14は、上述の態様で共に用いられるべく設計された鍵ペアとして生成され、例えば、第1の署名生成ユニット1は、第1の署名鍵12に基づいて、第1の署名10を生成し、再署名ユニット2は、再署名している鍵14を用いて、第1の署名10を第2の署名13へ変換する。このために、第1の署名鍵12は第1の署名生成ユニット1へ供給され、再署名鍵14は再署名ユニット2へ供給される。再署名鍵生成器3は、条件17’’のセットに依存して再署名鍵14を生成するために設けられる。条件17’’のこのセットは、以下に説明される委任ユニット5の一部であるユーザ入力デバイスによって、ユーザにより示されてもよい。再署名鍵14により、再署名ユニット2は、条件17’’のセットを満たしている属性15の任意のセットと関連する第1の署名10を第2の署名13へ変換可能にする。代替的に又は追加的に、再署名ユニット2は、第1の署名10が、条件17’のセットを満たしている属性15の第1のセットと関連するかどうかを検証するため公開鍵20を使用するように設けられる。従って、再署名ユニット2は、第1の署名10が条件17’のセットを満たしている属性15のセットと関連する場合だけ、第2の署名13を生成するように設けられる。この振る舞いを実施するために、再署名ユニット2は、従来から知られたデジタルセキュリティ技術を使用して、不正使用できなくされている。第1の署名10及び第2の署名13両方が属性のセットと関連するとき、ここで説明されるシステムは、属性の第2のセットと関連する第2の署名13により、属性15の第1のセットと関連する第1の署名10を置き換えるために用いられる。システムは、再署名ユニット2に再署名鍵14を供給することにより、属性16’の第2のセットを所有するユーザが、属性16の第2のセットと関連する署名でドキュメント11を署名するユーザの権限を他のユーザへ委任可能にするための委任ユニット5を有する。委任ユニット5は、更に、再署名鍵生成器3及び/又は再署名ユニット2により使用される条件17、17’、17’’のセットをユーザが決定可能にするように設けられる。委任ユニットは、ユーザに適当な委任オプションを提供するユーザインタフェースを有する。オプションで属性16の第2のセットと関連する第2の署名13の検証は、検証ユニット図示せずを使用して行われる。この検証ユニットは、第2の署名の真正を検証する。この検証は、第2の署名13がドキュメント11の有効な署名であるかどうかを検証する。第2の署名が属性16の第2のセットと関連するとき、検証ユニットは、更に、属性上の条件のセットに対して属性16の第2の署名の第2のセットを検証する。これらの検証は、署名検証アルゴリズムを使用して実施され、このアルゴリズムの例は以下に説明される。システムは、ワークステーションで実行されてもよい。代わりに、システムは、分散システムで実行されてもよい。例えば、第1の署名生成ユニット1、再署名ユニット2及び再署名鍵生成器3は、別々のコンピュータ装置でホストされてもよい。再署名鍵生成器3は、第2の署名生成ユニット4と同じコンピュータ装置でホストされてもよい。種々異なる物理的マシンを使用するよりはむしろ、ユーザログインシステムに基づいて、適当なユニット及び鍵への各ユーザアクセスを与えることも可能である。図2は、属性ベースのデジタル署名生成の例示的方法を図示する。上記システムは、以下の方法又はその変形を実施するような態様で実行される。ステップ200において、公開鍵パラメータ及びマスター鍵を得るセットアップアルゴリズムが実行される。ステップ201において、鍵生成アルゴリズムを用いて、第1のユーザのための第1の署名鍵が生成される。ステップ202において、同じ又は異なる鍵生成アルゴリズムを用いて、第2のユーザのための第2の署名鍵が生成される。ステップ203において、再署名鍵が、第2の署名鍵に基づいて、再鍵生成アルゴリズムを使用して生成される。この再署名鍵は、再署名ユニット、例えば半信頼されたサーバに格納される。ステップ204において、メッセージ又はドキュメントは第1の署名鍵を使用している第1のユーザにより署名され、第1の署名が得られる。ステップ205において、第1の署名が変換されるべきかどうかが決定される。変換されるべきでない場合には、プロセスはステップ204に戻る。変換されるべき場合、ステップ206において、第1の署名は、変換のため再署名ユニットへ送信される。ステップ207において、再署名ユニットは、第1の署名を受信して、例えばデータベースルックアップによって、その格納手段内の再署名鍵を識別する。再署名ユニットは、更に、第1の署名と再署名鍵とが合うかどうか、すなわち、第1の署名が再署名鍵を使用して第2の署名へ変換可能であるかどうかを検証し、また、良好に形成された又は、構築された署名であることを確認するために第1の署名を検証する。ステップ208において、第1の署名が変換可能でない場合、又は、良好に形成された又は、構築された署名でない場合、プロセスは、エラーメッセージを作って、ステップ204に戻るか、そうではなく可能である場合、ステップ209に進む。ステップ209において、再署名ユニットは、再署名アルゴリズムを用いて第1の署名を第2の署名へ変換する。ステップ210において、第2の署名は第1のユーザのシステムへ送り戻され、第1のユーザは、第2の署名を公的な格納領域に格納するか、又は、例えば、特定の目的ユーザへ第2の署名を送信する。ステップ211において、他のユーザ又は目的ユーザは、第2の署名を受信し、第2の署名を検証するために検証アルゴリズムを実行する。この検証は、第2の署名が表すと期待される属性上の条件のセットに対して実施される。当該方法は、プロセッサシステムに方法を実施させるための命令を有するコンピュータプログラムとして、ソフトウェアで、完全に又は部分的に実行されてもよい。属性ベースの代理再署名スキームABPRSSは、代理プロキシにより、署名σdelegateeを秘密鍵SKωdelegateeを使用して署名されるエンティティB受任者から、再署名鍵を使用してエンティティA委託者の署名σdelegatorへ変換可能にさせる。この説明において、代理プロキシproxyは、再署名生成のための計算を実施できるユニットを指す。このユニット、すなわちプロキシは、再署名鍵の濫用のような悪意のある使用から当該ユニットを保護するために、デジタルセキュリティ機能を具備する。例示的スキームが委託者、受任者鍵及び署名を参照して説明されるだろうが、ここで説明される変換及びアルゴリズムが、一の署名を他の署名への変換を含み、属性ベースの署名スキームを含む種々異なるシナリオでも用いられてもよいことは理解されるだろう。属性ベースの署名スキームABSSは、以下のアルゴリズム:1セットアップSetup、2鍵生成、3署名、4検証を有する。属性ベースの代理再署名スキームABPRSSは、2つのアルゴリズム:1再鍵生成、及び2再署名を加えることにより、機能を拡張する。これらのアルゴリズムの各々の簡単な説明が、以下に与えられる。セットアップ:セットアップアルゴリズムは、初期化フェーズの間に、システムパラメータを設定し、公開パラメータPK及びマスター鍵MKを出力する。鍵生成MK、ω:鍵生成アルゴリズムは、入力としてユーザが所有する属性ω及びマスターシークレット鍵MKを採用し、ユーザシークレット鍵SKωを出力する。再鍵生成SKω:再鍵生成アルゴリズムは、例えば、入力として属性セットωと関連するユーザのシークレット鍵SKωを採用し、エンティティAからの署名をエンティティBの署名へ変換するために使用できる再署名鍵を出力する。署名SKωdelegatee、RSKdelegatee、m:このアルゴリズムは、署名の第1のレベルを作るために、受任者により実行される。このアルゴリズムは、入力として属性セットωdelegateeと関連するSKωdelegatee、オプションで再署名鍵RSK及びメッセージmを採用する。再署名RSKproxy、σdelegatee:これは、半信頼されたプロキシにより実行される。これは、入力として属性セットωdelegatorと関連する再署名鍵及び受任者の署名、すなわちσdelegateeを採用する。これは、委託者のための署名、すなわちσdelegatorを出力する。検証σdelegator、PK:このアルゴリズムは、検証器により実行される。アルゴリズムは、入力としてメッセージm、公開鍵PK及び署名σdelegatorを採用する。アルゴリズムは、署名σdelegatorが有効な署名である場合、1を返し、そうでない場合、エラーシンボルTを返す。以下に、第1のスキーム及び第2のスキームと呼ばれる2つの実施例が、説明される。これらの実施例は、ABPRSSの2つの異なるスキームを使用する。第1のスキームにおいて、属性セットω委託者により所有されると関連する再署名鍵は、2つのコンポーネント、一方は受任者に対して、他方は半信頼されたプロキシ代理に対してのコンポーネントに分けられ、これらは何れも単独では委託者に対する署名を生成できない。第2のスキームにおいて、再署名鍵は半信頼されたプロキシだけに与えられる一方、受任者は、属性セットω受任者により所有されると関連する自身の秘密鍵を使用して署名する。第2のスキームにおいて、受任者と委託者との間でインタラクションは必要とされず、受任者は委託者に代わって署名するための余分の再署名鍵を格納する必要はない。受任者の署名が委託者エンティティAの署名へ変換されることを受任者エンティティBが望む場合、エンティティBは、半信頼されたプロキシにより変換できるように第1のレベルの署名を作る。第1のスキーム及び第2のスキームが、ここで説明される種類のシステム及び方法の可能な実行の単なる例を表すことは、理解されるだろう。これらのスキームの変更は可能である。以下に説明されるアルゴリズムは、例えば、図1を参照して説明されるシステムの種々異なるユニットを実行するか、又は、図2を参照して説明される方法のステップを更に定めるために当業者により用いられる。第1のスキームにおいて、再署名鍵RSKの第1の部分は、エンティティA受任者に与えられ、再署名鍵RSKの第2の部分はプロキシに与えられる。エンティティA受任者が最初にメッセージに署名する場合だけ、有効な署名が半信頼されたプロキシにより作られる。この場合、受任者は、余分の秘密鍵、すなわち再署名鍵RSKの部分を格納しなければならない。第2のスキームにおいて、受任者は、受任者により所有される属性セットωdelegateeと関連する秘密鍵SKωdelegateeを使用して、第1のレベルの署名σdelegateeを作る。受任者と委託者との間のインタラクションのための必要性はない。受任者の署名をエンティティA委託者の署名へ変換することを受任者が望む場合、受任者の署名は、2、3の余分のコンポーネントを有する。これらの余分のコンポーネントにより、プロキシが、署名σdelegateeをエンティティA委託者の署名σdelegatorへ変換可能にする。図3は、属性ベースの代理再署名スキームの機能的図を提供する。ステップ301において、エンティティAは、再生成アルゴリズムを用いて、再署名鍵RSKを生成する。RSKは、2つのコンポーネント:プロキシに対するコンポーネント及びエンティティBに対するコンポーネントを有する。これは、第1のデザインされたスキームの場合である。上記で紹介された第2のスキームにおいて、これは、プロキシに対する1つのコンポーネントを有する。ステップ302及び303において、再署名鍵、すなわちRSKproxy及びRSKdelegateeが、プロキシP及びエンティティBそれぞれに送られる。ステップ304において、エンティティBは、RSKdelegatee第1のスキームで又はSKdelegatee第2のスキームでを使用して、エンティティBの署名を生成する。ステップ305において、エンティティBは、プロキシPにステップ4の出力を送る。ステップ306において、半信頼されたプロキシは、エンティティBから受信された署名をエンティティAの署名へ変換する。ステップ307において、プロキシPは、エンティティAを代表して作られた署名を検証器V又は、署名されたメッセージの受信器へ送る。ステップ308において、検証器Vは、署名がエンティティAからであるかどうか、属性の正しいセットに関係のある秘密鍵により署名されているかどうかを検証する。第1のスキームにおいて、ユーザ属性はZpの要素であり、最大k個の属性があるとみなされている。実際上、属性ストリングをZpの要素へマップするための対立耐性のあるハッシュ関数を使用できる。当該スキームは、4つのアルゴリズムを有する。セットアップセットアップアルゴリズムは、主要なオーダーp並びにランダムジェネレータg及びhの双一次グループG0を選択する。また、双一次マップe:G0xG0→G1を選び、ここで、G1はターゲットグループである。加えて、セットアップは、無作為にを取り上げ、属性のセットのために、及びを1≦j≦kに対してセットする。公開鍵PK及びマスター鍵MKは、以下のコンポーネントを有する。鍵生成MK、ω鍵生成アルゴリズムは、属性セットωと関連するユーザ秘密鍵を出力する。当該アルゴリズムは、ランダムな要素を取り上げるここで、xは各ユーザに対して固有である。秘密鍵SKωは、以下のコンポーネントを有する。再鍵生成SKωこのアルゴリズムは、委託者により実行される。再鍵生成アルゴリズムは、委託者に代わって署名するためプロキシ及び受任者により用いられる再署名鍵を出力する。当該アルゴリズムは、ランダムな要素を取り上げて、これらをd=d1d2となるような2つの部分d1、d2へ分割する。再署名鍵RSKωは、一方が受任者に対するコンポーネント、他方がプロキシに対するコンポーネントである、以下の2つのコンポーネントを有する。署名RSKdelegatee、mこのアルゴリズムは、メッセージに署名するため受任者により実行される。当該アルゴリズムは、ランダムな要素を選んで、以下のコンポーネントを有する署名σdelegateeを計算する。再署名RSKproxy、σdelegatee、mこのアルゴリズムは、プロキシにより実行される。第2のレベル又は、最終的な署名を作る前に、プロキシは、以下の態様で受任者により作られる署名を検証する。ここで、I1=I2の場合、プロキシは第2のレベルの又は、最終的な署名を作るため受任者により作られる署名を変換する。当該アルゴリズムは、ランダムな要素を選んで、第2のレベルの署名を作る。検証σproxy、PK以下の式が成り立つ場合、署名が受け入れられる。以下に、属性ベースの代理再署名システムの第2実施例の説明が与えられる。当該システムは、以下のアルゴリズムの実行を有する。セットアップセットアップアルゴリズムは、主要なオーダーp並びにランダムジェネレータg及びhの双一次グループG0を選択する。当該アルゴリズムは、双一次マップe:G0xG0→G1を選ぶ。これの選択に加えて、セットアップは、無作為にを取り上げ、属性のセットのために、及びを1≦j≦kに対してセットする。公開鍵PK及びマスター鍵MKは、以下のコンポーネントを有する。鍵生成MK、ω鍵生成アルゴリズムは、属性セットωと関連するユーザ秘密鍵を出力する。アルゴリズムは、x=tqとなるように、ランダムな要素を取り上げるここで、x、t及びqは各ユーザに対して固有である。秘密鍵SKωは、以下のコンポーネントを有する。再鍵生成SKωdelegator再鍵生成アルゴリズムは、受任者からの署名を委託者の署名に変換するためにプロキシにより用いられる再署名鍵を出力する。当該アルゴリズムは、ランダムな要素を取り上げる。再署名鍵RSKωは、以下の2つのコンポーネントを有する。署名SKωdelegatee、mこのアルゴリズムは、メッセージに署名するために受任者により実行される。当該アルゴリズムは、ランダムな要素を選んで、自分自身の秘密鍵を使用して署名σdelegateeを計算する。σdeeとも呼ばれる署名σdelegateeは、以下のコンポーネントを有する。再署名RSK、σdelegatee、mこのアルゴリズムは、プロキシにより実行される。当該アルゴリズムは、ランダムな要素を選んで、受任者の署名を委託者の署名へ変換する。署名を変換する前に、プロキシは、署名が対応する受任者からの実際有効な署名であるかどうかを検証する。検証は、以下のように進む。ここで、I1=I2の場合、検証は成功し、プロキシは、第2のレベルの又は、最終的な署名を生成する。第2のレベルの署名の生成は、以下のステップを有する。第1のステップにおいて、プロキシは、以下を計算する。第2のステップにおいて、プロキシは、以下を計算する。第3のステップにおいて、プロキシは、以下を計算する。ここで、Hは、ハッシュ関数である。第4のステップにおいて、プロキシは、以下を計算する。最終ステップにおいて、プロキシは、署名を出力する。検証σproxy、PK変換された署名を検証するために、検証器は、以下のステップを実施する。第1ステップにおいて、検証器は、以下を計算する。第2ステップにおいて、以下の式が成り立つ場合、検証器は、署名を受け入れる。第1及び第2の実施例における上述のアルゴリズムは、図1を参照して説明されるシステムの実施例及び図2を参照して説明される方法の実施例に適用できることは、理解されるだろう。本発明は、また、本発明を実行するために適応された、コンピュータプログラム、特にキャリア上又はミャリア内のコンピュータプログラムにも適用することは、理解されるだろう。プログラムは、ソースコード、オブジェクトコードの形式でもよく、部分的にコンパイルされた形式でのようなソース及びオブジェクトコードの中間コード、又は本発明による方法の実行の使用に適している他の任意の形式でもよい。斯様なプログラムは、多くの異なるアーキテクチャデザインを持つとも理解されるだろう。例えば、本発明による方法又はシステムの機能を実行するプログラムコードは、一つ以上のサブルーチンに副分割されてもよい。これらのサブルーチンに機能を分散させる多くの種々異なる態様は、当業者に明らかであろう。サブルーチンは、自己充足的なプログラムを形成するために、1つの実行可能ファイルに一緒に格納されてもよい。斯様な実行可能ファイルは、コンピュータ実行可能な命令、例えば、プロセッサ命令及び/又はインタプリタ命令例えばJava登録商標インタプリタ命令を有する。代わりに、サブルーチンの一つ以上又は全ては、少なくとも一つの外部ライブラリファイルに格納され、静的に又は動的に、例えば実行時に、メインプログラムとリンクされてもよい。メインプログラムは、サブルーチンの少なくとも1つへの少なくとも一つのコールを含む。サブルーチンは、また、互いへのファンクションコールを有してもよい。コンピュータプログラムに関係する実施例は、ここで説明された方法の少なくとも1つの各処理ステップに対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに副分割され、及び/又は静的若しくは動的にリンクされる一つ以上のファイルに格納されてもよい。コンピュータプログラムに関係する他の実施例は、ここで説明されたシステム及び/又はプロダクトの少なくとも1つの各手段に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに副分割され、及び/又は静的若しくは動的にリンクされる一つ以上のファイルに格納されてもよい。コンピュータプログラムのキャリアは、プログラムを坦持できる任意のエンティティ又は装置でもよい。例えば、キャリアは、ROM、例えば、CD―ROM若しくは半導体ROM、又は磁気記録媒体、例えば、ハードディスクのような記憶媒体を含む。更にまた、キャリアは、電気ケーブル若しくは光ケーブルを介して、又は無線若しくは他の手段により伝達される電気的信号又は光信号のような送信可能なキャリアである。プログラムが斯様な信号で具現化されるとき、キャリアは、斯様なケーブル又は他の装置若しくは手段により構成されてもよい。代わりに、キャリアは、プログラムが埋め込まれている集積回路でもよく、当該集積回路は、関連した方法を実施するために、又は関連した方法のパフォーマンスで使用されるのに適している。上述の実施例は、本発明を制限するよりはむしろ例示するものであり、当業者は、添付の請求の範囲の要旨を逸脱しない範囲で多くの代替の実施例をデザイン可能であることは、留意されたい。請求項において、括弧に配置された何れの参照符号も、請求項を制限するものとして解釈されない。動詞有する及びその関連語の使用は、請求項に述べられたもの以外の要素又はステップの存在を除外しない。要素に先立つ冠詞a又はanは、複数の要素の存在を除外しない。本発明は、幾つかの異なった要素を有するハードウェアによって、また、最適にプログラムされたコンピュータによって実行されてもよい。幾つかの手段を列挙している装置の請求項において、これらの手段の幾つかは、ハードウェアの全く同一の部材により具現化されてもよい。特定の方策が相互に異なる従属請求項において引用されているという単なる事実は、これらの方策の組合せが効果的に使用できないことを示すわけではない。"