"属性ベースのデジタル署名システムであって、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき署名を生成することによりメッセージに署名する署名生成ユニットを有し、前記署名生成ユニットが、前記署名の少なくとも一部を形成するよう無効データと前記ユーザ秘密鍵とを結合するよう構成され、前記無効データは、複数の有効なユーザ秘密鍵の個別の1つを補足し、前記無効データが、前記ユーザ属性のセットを用いてメッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する、システム。更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の少なくとも一部を選択的に除去する無効ユニットを更に有し、前記更新された無効データが、前記無効にされるユーザ秘密鍵の少なくとも一部に基づかれる、請求項1に記載のシステム。前記無効ユニットが更に、前記更新された無効データに対応する無効検証要素を提供するよう構成され、前記システムは、前記無効検証要素に基づき、前記署名を検証する署名検証ユニットを有する、請求項2に記載のシステム。前記無効ユニットが、前記無効データを用いて、前記ユーザ秘密鍵の少なくとも1つのユーザ属性に関連付けられる前記署名能力を選択的に除去するよう構成される、請求項2に記載のシステム。前記無効データ及び前記ユーザ秘密鍵が、共有された秘密スキームに基づかれる、請求項1に記載のシステム。前記ユーザ秘密鍵が、秘密の共有物を有する、請求項5に記載のシステム。前記無効データが、前記無効にされたユーザ秘密鍵における前記共有物を除き、前記ユーザ秘密鍵における個別の共有物を補足する、請求項6に記載のシステム。複数の属性認証局であって、一の属性認証局が、他の属性認証局と独立してユーザに暗号鍵を発行するよう構成され、前記暗号鍵が、属性のセットに関連付けられる、複数の属性認証局と、署名生成ユニットであって、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信する受信ユニットと、メッセージに関する暗号署名を生成するため、前記同じユーザに関する前記複数の暗号鍵を結合する結合ユニットであって、前記暗号署名が、前記複数の暗号鍵からの属性に関連付けられる、結合ユニットとを含む、署名生成ユニットとを有する、請求項1に記載の属性ベースのデジタル署名システム。前記複数の属性認証局が、公開パラメータを用いて、自身の公開及びマスター秘密鍵を生成するよう構成される、請求項8に記載のシステム。個別のユーザが、ユーザ識別子を用いて前記複数の属性認証局にわたり特定され、前記複数の属性認証局が、前記対応するユーザ識別子に基づきユーザに関する前記暗号鍵を生成するよう構成される、請求項8に記載のシステム。請求項1に記載のシステムを有するワークステーション。請求項1に記載のシステムを有する医療画像取得装置。属性ベースのデジタル署名処理の方法において、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき、署名を生成することにより、メッセージに署名するステップを有し、前記生成が、無効データと前記ユーザ秘密鍵とを結合することを含み、前記無効データが、複数の有効なユーザ秘密鍵の個別の1つを補足し、前記無効データは、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する、方法。複数の属性認証局により、属性のセットに関連付けられる暗号鍵をユーザに独立して発行するステップと、署名生成ユニットにより、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信するステップと、前記署名生成ユニットにより、メッセージに関する暗号署名を生成するため、前記同じユーザに関する前記複数の暗号鍵を結合するステップであって、前記暗号署名が、前記複数の暗号鍵からの属性に関連付けられる、ステップとを有する、請求項13に記載の方法。請求項13又は14に記載の方法をプロセッサに実行させる命令を有するコンピュータプログラム。データ保護の別の側面は、起源originの否認防止を提供することである。その結果、データの消費者は、データ起源を検証することができる。日常生活では、否認防止を提供するため、デジタル署名が用いられる。これらのデジタル署名方式において、プライベート又は秘密及び公開鍵ペアがユーザごとに生成される。この場合、秘密鍵が、メッセージに署名するために用いられることができ、公開鍵が、メッセージにおける署名を検証するために用いられることができる。しかしながら、ヘルスケア組織において、ユーザの役割及び識別を決定するため、通常は属性が用いられ、データに対するアクセス及びメッセージに署名する権限は、ユーザ属性に基づき認可される。斯かる組織のために構築されるコンピュータシステムにおいて、ユーザは、自分が適切な属性のセットを持つ場合にのみ、データを作成又は修正及びデータに署名することができる。したがって、ヘルスケア組織において、属性は、データ起源の重要な側面であるとみなされる。例えば、特殊な役割又は属性を持つユーザ例えば医師により署名された場合、薬局は処方オーダーを受け入れる。特殊な属性のセットを持つユーザとしてメッセージ又はコンテンツに署名することを可能にするデジタル署名方式は、属性ベースの署名ABS方式である。斯かる属性ベースの署名方式は、DaliaKhaderによるAttributeBasedGroupSignaturewithRevocation、CryptologyePrintArchive、Report2007241、2007、httpeprintiacrorgに記載される。引用されたレポートは、属性ベースのグループ署名ABGS方式を開示する。そこでは、ユーザが無効にされる場合、検証者が、無効にされたユーザを特定し、及び従って、署名を拒絶する能力を持つ。ユーザが無効にされるかどうかをチェックする又は検証する処理は、無効にされたユーザのリストを介して1対1で行われることで、検証認証局によりローカルで行われる。属性ベースの署名ABS方式において、データは、アクセス構造に基づき署名される。その結果、正しい属性を持つユーザだけがデータに署名することができる。メッセージに署名することが可能であるよう、ユーザは、そのユーザが持つ認証された属性のセットに対応する特殊な秘密鍵を信頼された認証局から得る。しかしながら、開示された属性ベースの署名方式は、ユーザの無効に関して、制限されたサポートしか提供しない。一般に、例えばユーザの秘密鍵が危殆化されるとき、又は、ユーザの状態が変化するとき、ユーザの無効化が望ましい。例えば、ユーザが、別の仕事に変わり、その仕事に関連付けられる他の属性に変化することがある。改良された属性ベースのデジタル署名システムを持つことが有利である。この懸念により好適に対処するため、本発明の第1の側面は、あるシステムを提供する。このシステムは、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づきメッセージに署名する署名生成ユニットを有し、上記署名生成ユニットが、上記署名の少なくとも一部を形成するよう無効データと上記ユーザ秘密鍵とを結合するよう構成され、上記無効データは、複数の有効なユーザ秘密鍵の個別の1つを補足し、上記無効データが、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する。このシステムは、無効データを提供することにより、ユーザ秘密鍵が選択的に無効にされることを可能にする。ユーザを無効にするには、無効データだけが更新されることを必要とする。なぜなら、無効データは、無効にされたユーザ秘密鍵が用いられることを防止し、有効なユーザ秘密鍵を補足するからである。結果として、署名生成ユニットは、新しいユーザ秘密鍵を具備する必要がない。更に、無効データは、無効にされたユーザ秘密鍵でなく、有効なユーザ秘密鍵だけを補足するので、メッセージに署名するために無効にされたユーザ秘密鍵が用いられることが防止される。結果的に、無効にされたユーザ秘密鍵を用いて署名が作られたかどうか見るために、検証ユニットが無効にされたユーザのリストを調べる必要がない。署名生成ユニットは、無効データの最新版を用いるよう構成されることができる。このシステムは、更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の少なくとも一部を選択的に除去する無効ユニットを有することができる。この場合、上記更新された無効データが、上記無効にされるユーザ秘密鍵の少なくとも一部に基づかれる。署名生成ユニットにより用いられる更新された無効データは、以前は署名することが許可されていたユーザを無効にする。更新された無効データは、署名生成ユニットに分散されることができる。上記無効ユニットは、上記更新された無効データに対応する無効検証要素を提供するよう構成され、上記システムは、上記無効検証要素に基づき、上記署名を検証する署名検証ユニットを有することができる。無効検証要素は、例えば数といったデータ要素を有することができる。無効検証要素は、最新の無効データの使用が署名生成ユニットによりどのように実施されるかの例である。上記無効ユニットが、上記無効データを用いて、上記ユーザ秘密鍵の少なくとも1つのユーザ属性に関連付けられる署名能力を選択的に除去するよう構成されることができる。これは、完全なユーザ秘密鍵の代わりに、ユーザ秘密鍵に関連付けられる属性の1つだけ又はいくつかを無効にすることを可能にする。無効データ及びユーザ秘密鍵は、共有秘密スキームに基づかれることができる。これは、システムの無効部分を実現する効率的なスキームである。ユーザ秘密鍵は、秘密の共有物を有することができる。これは、共有秘密のスキームを実現する効率的な態様である。上記無効データが、上記無効にされたユーザ秘密鍵における上記共有物を除く、上記ユーザ秘密鍵における個別の共有物を補足する。これは、無効を実現する効率的な態様である。無効にされたユーザの共有物は、無効にされていないユーザによる使用のため無効データに含まれることができる。本発明の別の側面は、属性ベースのデジタル署名システムを提供する。このシステムは、複数の属性認証局であって、一の属性認証局が、他の属性認証局と独立してユーザに暗号鍵を発行するよう構成され、上記暗号鍵が、属性のセットに関連付けられる、複数の属性認証局と、署名生成ユニットであって、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信する受信ユニットと、メッセージに関する暗号署名を生成するため、上記同じユーザに関する上記複数の暗号鍵を結合する結合ユニットであって、上記暗号署名が、上記複数の暗号鍵からの属性に関連付けられる、結合ユニットとを含む、署名生成ユニットとを有する。これは、異なる独立認証局により許可される属性をサポートすることをより容易にする。なぜなら、認証局は、ユーザに発行される属性を調整するために中央認証局に依存する必要なしに、ユーザに鍵を発行することができるからである。署名生成ユニットは、中央又は媒介認証局に依存することなしに、鍵を受信し、これらを結合することもできる。属性認証局に特有な秘密情報を発行する中央認証局を持つ必要がなくなる。複数の属性認証局は、自身の公開及びマスター秘密鍵を生成するよう構成されることができる。公開及びマスター秘密鍵は、公開パラメータに基づかれることができる。公開パラメータは、すべての属性認証局に関して同じとすることができる。こうして、属性認証局は、秘密鍵を得るのに中央認証局に依存しない。これは、属性認証局が独立して作動することを可能にするのを助ける。複数の属性認証局は、メッセージのサイズを含む公開パラメータのセットに基づき、暗号鍵を生成するよう構成されることができる。これは、メッセージが、異なる属性認証局からの暗号鍵を用いて容易に処理されることを可能にする。代替的に、複数の属性認証局は、共通のオーダーpの共通のグループGに基づき、暗号鍵を生成するよう構成されることができ、署名生成ユニットは、グループGのメンバーであるメッセージmに関する署名を生成するよう構成される。これは、独立認証局からの暗号鍵を結合することをより容易にする。なぜなら、それらの全ては、グループGのメンバーであるメッセージに関して用いられることができるからである。結果的に、1つのグループから他のグループに対しメッセージを変換する必要がない。同様に、属性認証局は、同じハッシュ関数を用いるよう構成されることができる。個別のユーザは、ユーザ識別子を用いて複数の属性認証局にわたり特定されることができる。更に、複数の属性認証局は、対応するユーザ識別子に基づきユーザに関する暗号鍵を生成するよう構成されることができる。異なる独立認証局における同じユーザ識別子を用いて、組み合わされたデジタル署名を形成するために暗号鍵を結合することはより容易である。更に、異なるユーザに関して生成される暗号鍵が、複数のユーザからの属性を用いて署名を生成するために署名生成ユニットにより結合されることが、防止されることができる。本発明の別の側面は、上述されたシステムを有する医療ワークステーションを提供する。これは、このシステムが都合よく作動することを可能にする。本発明の別の側面は、上述されたシステムを有する医療画像取得装置を提供する。これは、一体化された機能の提供を可能にする。例えば、それは、取得した画像データの署名を生成することを容易にする。本発明の別の側面は、属性ベースのデジタル署名処理の方法を提供し、この方法は、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき、メッセージに署名するステップを有し、上記生成が、無効データと上記ユーザ秘密鍵とを結合することを含み、上記無効データが、有効なユーザ秘密鍵を補足し、上記無効データは、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する。本発明の別の側面は、プロセッサシステムに上述された方法を実行させる命令を有するコンピュータプログラムを提供する。本発明のこれら及び他の側面が、以下に説明される実施形態を参照して明らかとなり、これらの実施形態を参照して説明されることになる。属性ベースの署名方式において、署名者は、属性のセットに関連付けられる秘密鍵を持つ。彼は、メッセージにおける署名を作成するのにこの秘密鍵を使用することができる。署名が正しい属性のセットと関連付けられる秘密鍵により生成される場合にだけ、この署名が受け入れられる。属性ベースの署名は、グループ署名の一形式とみなされることができる。大きな差異は、それが検証者が署名者の属性例えば役割を決定することを可能にする点にある。しかしながら、実際には、特殊な属性のセットを持つユーザが特殊なメッセージに署名することが許されない場合があるシナリオが存在する例えば、ユーザは、自分自身の出張リクエストを承認するため署名することは許されない。また、このユーザの秘密鍵が無効にされれば、将来いかなるメッセージに署名することも許されない。。本書では、特殊なユーザを無効にする能力を持つ属性ベースの署名方式が記載される。こうして、無効にされたユーザがメッセージに署名する場合、それが検証者によって受け入れられることはない。属性ベースの署名ABSにおいて、データは、アクセス構造又は属性のセットに基づき署名される。その結果、正しい属性を持つユーザだけがデータに署名することができる。メッセージに署名することが可能であるよう、ユーザは、そのユーザが持つ認証された属性のセットに対応する特殊な秘密鍵を信頼された認証局から得る。ユーザの状態は変化することができる例えば、ユーザは、仕事を変える。。また、ユーザの秘密鍵は、危殆化されるかもしれない。そのような場合、理想的には、システムは、最初からもう一度システム及び他のユーザのすべての秘密鍵をセットアップすることなしに、ユーザを無効にすることが可能であるべきである。上述したニーズに対処するため、ABSは、無効能力を持つよう拡張されることができる。これは、例えば、秘密共有に基づき実行されることができる。各ユーザは、個人化された共有物を、例えばベキ指数において得る。この個人化された共有物は、例えば鍵認証局から秘密鍵を要求するとき得られることができ、その後更新されることができる。各ユーザは、秘密を回復するため、無効にされたユーザの共有物を自分の共有物と結合する。これは、署名者が、有効な署名を生成するのを助ける。無効は、署名者ローカルである。なぜなら、署名者が、共有物の組合せを実行するからであり、この組み合わせは、無効でないユーザにとってのみ可能だからである。結果的に、無効は、署名を生成する時すでに明らかになる。こうして、ユーザが無効にされずメッセージに署名することが許される、正しい属性のセットを所有する場合、彼は有効な署名を生成することが可能である。そうでなければ、彼は、有効な署名を生成することができない。図1は、属性ベースのデジタル署名システムのブロック図を示す。このシステムは、電子回路において、又は、ソフトウェアを用いて実現されることができる。通常、システム要素は、示されたデータ要素を通信することにより互いに相互作用する複数のデバイスにわたり分散される。システムは、ユーザ属性のセットωと関連付けられるユーザ秘密鍵SKに基づき署名σを生成することにより、メッセージmに署名する署名生成ユニット1を有する。署名生成ユニット1は、秘密鍵SKを用いて属性セットωに基づきメッセージmに署名するよう構成されることができる。異なるユーザに対して複数のユーザ秘密鍵SKが存在することができる。複数の署名生成ユニット1が存在することもできる。各署名生成ユニット1は、ユーザ秘密鍵SKの1つを用いるよう構成されることができる。署名生成ユニット1は、無効ユニット2から無効データRを得るよう構成されることができる。このために、無効ユニット2は、無効データRをネットワーク位置で利用可能にするよう構成されることができる。斯かるネットワーク位置及び無効データRは、複数の署名生成ユニット1に対して利用可能とされることができる。署名生成ユニット1は、署名σの少なくとも一部を形成するため、無効データRとユーザ秘密鍵SKとを結合するよう構成されることができる。このために、無効データRは、複数の有効なユーザ秘密鍵の個別の1つを補う。本書において、有効なユーザ秘密鍵は、無効にされていないユーザの秘密鍵を参照する。無効データRは有効なユーザの秘密鍵だけを補うので、無効データRは、ユーザ秘密鍵SKと関連付けられる属性のセットωを持つメッセージmに有効に署名するために無効にされたユーザ秘密鍵SKが用いられることを防止する。結果的に、ユーザ秘密鍵SKは、秘密鍵SKを用いて属性のセットωに基づきメッセージmに署名するために用いられることができない。このシステムは、更新された無効データRを提供することにより、無効にされるユーザ秘密鍵SKの署名能力の少なくとも一部を選択的に除去する無効ユニット2を有することができる。この場合、更新された無効データRは、無効にされるユーザ秘密鍵SKの少なくとも一部に基づかれる。無効ユニット2は更に、更新された無効データRに対応する無効検証要素RVCを提供するよう構成されることができる。この無効検証要素RVCは、署名σの有効性を検証するために用いられることができる。システムは、無効検証要素RVCに基づき署名σを検証する署名確認ユニット3を有することができる。検証ユニット3の出力vは、署名σの有効性を示すことができる。例えば、署名σ及び無効検証要素RVCを含む暗号処理の結果は、署名σの有効性を示す。署名確認ユニット3は更に、検証のため公開鍵PKを使用することができる。無効ユニット2は、無効データRを用いて、ユーザ秘密鍵SKの少なくとも1つのユーザ属性に関連付けられる署名能力を選択的に除去するよう構成されることができる。例えば、ユーザ属性を表すユーザ秘密鍵SKの一部は、無効データにより補われることができる。署名生成ユニット1は、無効データRとユーザ属性を表す部分とを結合するよう構成されることができる。こうして、全部のユーザの秘密鍵SKではなく、ユーザ秘密鍵SKに関連付けられる属性だけを無効にすることが可能である。結果的に、署名生成ユニットは、無効にされた属性を必要としないポリシーに対する署名を生成するためにまだ使用されることができる。無効データR及びユーザ秘密鍵SKは、共有秘密方式に基づかれることができる。例えば、ユーザ秘密鍵SKは、秘密の共有物を有する。無効データRは、無効にされたユーザ秘密鍵SKにおける共有物を除き、ユーザ秘密鍵における個別の共有物を補う。例えば、n個の異なる共有物の最小数が、秘密を再構築するために必要とされることができる。無効データは、n-1個の共有物を有することができる。ユーザ秘密鍵SKは、1つの共有物を有することができる。この場合、各ユーザ秘密鍵SKは、異なる共有物を有する。無効データのn-1個の共有物は、n個の共有物の最小数を形成するため、ユーザ秘密鍵の共有物の個別の1つを補う。ユーザ秘密鍵を無効にするため、無効にされたユーザの共有物は、n-2個の他の共有物と共に、無効データRに含まれることができる。無効にされていないユーザ秘密鍵は、n個の共有物を形成するため無効データRと組み合わせられるので、それらは秘密を再構築することができる。しかしながら、無効にされたユーザ秘密鍵の共有物は、無効データRにおける共有物の1つと同じである。従って、無効データRと結合される無効にされたユーザ秘密鍵は、n-1個の共有物を形成するだけである。これは、秘密を再構築するには不十分である。結果的に、無効にされたユーザ秘密鍵は、秘密を再構築するために用いられることができない。システムは更に、鍵生成ユニット4を有することができる。鍵生成ユニット4は、例えばマスター秘密鍵MKに基づき、署名生成ユニット1により使用されるユーザ秘密鍵SKを生成することができる。無効に対するサポートを実現するため、秘密鍵SKは、秘密の共有物を有することができる。マスター秘密鍵MKは、セットアップユニット5により生成されることができる。また、セットアップユニット5は、1つ又は複数の公開鍵PK、無効データR及び/又は無効検証要素RVCを生成するよう構成されることができる。後者は、無効ユニット2により検証ユニット3に提供されることができる。公開鍵PKは、署名確認ユニット3により使用されることができる。鍵生成ユニット4及びセットアップユニット5は、信頼された認証局6の一部であるか、又はこれにより制御されることができる。図において無効ユニット2は、信頼された認証局6とは分離しているが、無効ユニット2も、信頼された認証局6の一部であるか、又はこれにより制御されることができる。ユーザを無効にするため、セットアップユニット5は、無効にされたユーザの共有物を含むよう無効データRを更新し、及び無効検証データRVCを更新することができる。これは、検証ユニット3が、更新された無効データRに基づき、署名生成ユニット1により生成される署名σを検証することを可能にする。このシステムは、例えば放射線学ワークステーションといった医療ワークステーションに組み込まれることができる。署名生成ユニット1、無効ユニット2、署名検証ユニット3及び/又は鍵生成ユニット4の1つ又は複数の機能を提供するため、このワークステーションは、プロセッサ及び適切なソフトウェアがロードされるメモリだけでなく、ワークステーションを作動させるためのモニタ、キーボード及び/又はマウスを有することができる。このシステムは、例えばX線装置又はMRIスキャナといった医療画像取得装置に組み込まれることができる。例えば、ユーザインタフェースは、医療画像取得装置により提供されることができる。これは、ユーザが、ユーザ秘密鍵SKを用いて画像データを認証することを可能にする。システムは、例えば病院情報システム又は画像アーカイブシステムといった医療情報システムに組み込まれることもできる。斯かるシステムにおいて、図1により表される機能は、1つ又は複数の中央サーバを用いて実現されることができる。実装においては、図示される機能が、例えばユニット、処理又はサブルーチンへと多くの異なる態様で分けられることができる点を理解されたい。この点で、図1のブロック図は、単なる例示を提供するにすぎない。更に、機能は、複数のハードウェア装置にわたり分散されることができる。図1の異なるブロックが、異なるデバイス上で実行されるように設計されることができるが、これは限定でない。図2は、属性ベースのデジタル署名処理の方法を示す。この方法は、ユーザ属性のセットに関連付けられるユーザ秘密鍵SKに基づき、署名σを生成するステップ202を有する。ステップ202は、無効データRとユーザ秘密鍵SKとを結合するサブステップ203を有することができる。本書において、無効データRは、複数の有効なユーザ秘密鍵の個別の1つを補足する。ここで、無効データRは、上述された態様で、メッセージmに有効に署名するために無効にされたユーザ秘密鍵SKが用いられることを防止する。ステップ204において、署名σは、検証されることができる。ステップ205において、ユーザ秘密鍵が無効にされるべきかが決定される。無効にされるべきでない場合、処理は、ステップ202に戻る。ユーザ秘密鍵を無効にするため、処理は、更新された無効データR及び更新された無効検証要素RVCを生成するため、ステップ206へ進む。更新された無効データRは、ステップ202の次の実行において用いられ、無効検証要素RVCは、ステップ204の次の実行において用いられる。この方法は、コンピュータプログラムとして実現されることができる。以下に、より詳細な例示的な実施形態が説明される。ユーザ無効能力を持つ例示的な属性ベースの署名スキームにおいて、ユーザがデータに署名するとき、ユーザは、信頼された認証局から無効にされたユーザ共有物のリストを受け取ることができる代替的に、署名者は、例えば、無効ユニット2により維持される公開データベースにおいてを探すことができる。有効な署名を生成するため、ユーザは、ユーザが所有する属性セットωに関連付けられる秘密鍵を必要とする。ユーザの共有物は、の中にあるべきではない。ユーザの共有物がの中にある場合、ユーザは、有効な署名を生成することが可能であるべきでない。署名スキームに関係するアルゴリズムは、セットアップ、鍵生成、署名、検証及び無効を含むことができる。これらが、以下に説明されることができる。:セットアップアルゴリズムは、初期化フェーズの間、システムパラメータを構成し、公開パラメータ又は公開鍵及びマスターキーを出力する。無効アルゴリズムは、セットアップアルゴリズムのサブアルゴリズムとして実現されることができ、セットアップユニット5又は信頼された認証局6により実行されることができる。しかしながら、無効サブアルゴリズムは、初期セットアップの間に実行される残りのステップとは独立して実行されることができる。無効データは、無効ユニット2により、署名生成ユニット1及び/又は署名検証ユニット3へと分散されることができる。無効サブアルゴリズムは、入力として、既存の無効データ及び無効にされたユーザのユーザ識別を取り、更新された無効データを出力する。この更新されたデータにおいて、識別を持つユーザが無効にされる。また、無効アルゴリズムは、無効検証要素を生成することができる。:鍵生成ユニット4により実行され、鍵生成アルゴリズムは、入力として、ユーザが所有する属性セット、ユーザ識別及びマスター秘密鍵を取り、ユーザ秘密鍵を出力する。:署名生成ユニット1により実行され、このアルゴリズムは、入力として、メッセージm、ユーザ秘密鍵、公開鍵、及び、例えば無効にされたユーザの共有物を含む共有物のセットの形で、無効データを取る。アルゴリズムは、メッセージの署名σωを戻す。署名は、特定のポリシーを満たす署名として検証可能でありえる。代替的に、署名が、ユーザ秘密鍵に関連付けられる属性で署名された署名として検証可能でありえる。:このアルゴリズムは、署名検証ユニット3により実行されることができる。このアルゴリズムは、入力として、メッセージ、公開鍵、署名σω及び無効検証要素を取る。アルゴリズムは、署名σωが有効な署名であるかどうかを示すデータ値を戻す。アルゴリズムは、無効にされたユーザの数に線形依存する複雑さを持つことができる。署名スキームの計算の複雑性及びサイズは更に、ユーザの総数ではなく、アクセス構造における属性の数に線形依存することができる。このアクセス構造に基づき、署名が署名される。例えば、ユーザは、セットアップフェーズの間秘密鍵生成PKG認証局から秘密鍵を得るとき、個人化された共有物を指数において得ることができる。その後、各無効にされていないユーザは、PKGにより又は無効ユニットによりブロードキャストされる無効にされたユーザの共有物又はダミー共有物と指数における個人化された共有物とを結合することができる。これは、署名の有効な要素の回復を生じさせる。ユーザの無効化を支持するため、検証認証局は、署名検証をするため、無効リストからの1つのグループ要素を具備することができる。検証のとき、ユーザが無効にされるかどうかを検証するため、無効にされたユーザの全体のリストを調べる必要がない。ユーザが無効にされる場合、署名は、共有された秘密のスキームに基づかれる無効な要素を含み、署名が、無効であることが検証される。提案されたスキームは、例えば、共謀抵抗、非可鍛性、ユーザ匿名及び非リンク性といった署名スキームの望ましい特性を満たすことができる。ある実施形態は、セットアップ、鍵生成、署名、検証及び無効に関する以下のアルゴリズムを有する。このスキームにおいて、ユーザ属性は、の要素である。我々は、最大でk個の属性が存在すると想定する。しかしながら、これは、限定事項ではない。実際において、例えば、ユーザは、の要素に対して属性ストリングをマッピングするため、衝突抵抗ハッシュ関数を用いることができる。1.:セットアップアルゴリズムは、プライムオーダーp及びランダム生成器g及びhのバイリニアグループを選択する。これは、バイリニアマップも選択する。更に、セットアップは、ランダムにを選び、属性のセットに対して、これはをセットする。セットアップアルゴリズムは、本書において無効アルゴリズムと呼ばれる別のサブアルゴリズムを有する。この無効アルゴリズムは、無効にされたユーザに関する共有物を生成するために用いられる。1.1無効無効の目的で用いられることができる各ユーザに関する共有物を生成するため、このアルゴリズムは、セットアップアルゴリズムでも実行される。無効の目的で、それは、を選び、に対する次数rのランダムな多項式を生成する。これは、P0=R=a0をセットする。ここで、多項式Pのt1の共有物は、Rを再構築するのに用いられることができる。秘密a0=R=P0を再構築するには、多項式Pのr1の共有物が必要とされる点に留意されたい。であり、Nがシステムにおけるユーザの総数であるような場合、ユーザに対して、共有物は、多項式Pから生成される。セットアップアルゴリズムは、r個の余分なダミー共有物も計算することができる。これは、無効にされたユーザの数がrより少ない場合、ブロードキャストされることができる又は、公開データベースに置かれる。例えば、rユーザが無効にされる場合、アルゴリズムは、を選択し、を有する無効データを生成する。するとこの無効データは、公開データベースに置かれるか、又はユーザにブロードキャストされる。公開鍵及びマスターキーは、以下の要素を有することができる。2.:鍵生成アルゴリズムは、属性セットω及び識別に関連付けられるユーザ秘密鍵を出力する。アルゴリズムは、ランダム要素を選び、以下の要素から成る秘密鍵を計算する。秘密鍵も、ユーザの個人化された共有物、即ちS2,1から成る。これは、ユーザが無効にされたユーザの1人でない場合、有効な署名を生成するため、無効にされたユーザの共有物と組み合わせるために用いられる。3.:このアルゴリズムは、入力として、ユーザ秘密鍵、無効にされたユーザの共有物及び署名されるメッセージmを取る。メッセージに署名するために、アルゴリズムは、ランダム要素を選択し、署名σを計算する。この署名は、以下の要素を有することができる。ユーザが無効にされていない場合にのみ、ユーザは、有効な署名を生成することが可能である。4.:このアルゴリズムは、入力として、検証される署名、公開鍵及びRVC要素を取る。RVC要素は、Setupアルゴリズムに示される公開鍵の一部である。しかしながら、明確さのため、我々は、それを別々に示す。署名は、のような態様で検証される。上記の式が成立する場合、署名は受け入れられることができる。属性ベースの署名ABSスキームにおいて、データは、属性のセットに基づき署名される。メッセージに署名することが可能であるために、ユーザは、信頼された認証局から、その者が持つことを許可された属性のセットに対応する特定の秘密鍵を得る。しかしながら、実際は、異なる属性が、異なる認証局により管理されることができる。従って、マルチ認証局の属性ベースの署名スキームに関する必要性が存在する。そこでは、ユーザが、異なる属性認証局から秘密鍵要素を得ることができる。例えば、個人が処方オーダーに署名するとき、彼は、複数の認証局により割り当てられた複数の属性に基づき署名する。例えば、個人は、大学でパートタイムとして働き、病院でパートタイムとして働くことがある。斯かるシナリオにおいて、ユーザは、例えば大学と病院の両方の組織から、秘密鍵要素を取得することができる。以下ユーザが文書に署名するとき、彼は、複数の認証局により管理されるこれらの属性に基づき署名する。この需要に対処するため、マルチ認証局の属性ベースの署名スキームが提案される。しかしながら、既知のマルチ認証局の属性ベースの署名スキームは、中央認証局の存在に依存する。この中央認証局は、システムにおける全ての属性認証局及びユーザにより信頼されているべきである。中央認証局の主要な機能は、分散された属性認証局の間の同期を確立することである。これは、共謀を防止するために必要である。共謀は、第1の属性認証局A1から第1のユーザに発行される第1の秘密鍵要素と第2の属性認証局A2から第2のユーザに発行される第2の秘密鍵要素の知識を持つ悪意あるユーザが、第1及び第2の秘密鍵に関連付けられる属性の組合せを用いて署名するため、第1の秘密鍵及び第2の秘密鍵の組合せに基づきメッセージに署名することができることを意味する。中央認証局は、既知のスキームをより有益でないものにし、実現をより困難にする。以下に、分散されたマルチ認証局の属性ベースの署名スキームが、説明される。これは、信頼された中央認証局なしに作動することができ、共謀からも解放されたままである。図3は、マルチ認証局属性ベースのデジタル署名システムのブロック図を示す。このシステムは、概略的に、ブロック301、302、303として示される複数の属性認証局を有する。しかしながら、属性の数は任意の数とすることができる。状況に応じて、3つの属性認証局より多くすることも少なくすることもできる。属性認証局301、302、303は、属性のセットに関連付けられる暗号鍵をユーザに独立して発行するよう構成される。例えば、属性認証局301は、暗号鍵311を発行し、属性認証局302は、暗号鍵312を発行し、属性認証局303は、暗号鍵313を発行する。属性認証局301、302、303は、互いの間で又は中央認証局と、秘密情報を交換する必要はない。属性認証局301、302、303は、それらの自身の秘密鍵を生成するよう構成されることができる。これは、例えば暗号アルゴリズムに現れる要素のフォーマット及び/又はサイズといった公開して共有される情報を用いて実行されることができる。暗号鍵311、312及び313は、同じユーザに関するものであるが、それらは異なる属性に関連付けられる。結果的に、ユーザは、異なる認証局301、302、303から複数の暗号鍵311、312、313を得ることができる。システムは更に、署名生成ユニット304を有する。通常、システムには、1つ以上の署名生成ユニット304が存在することができる。例えば、異なるユーザは、それらの自身の署名生成ユニットを持つことができる。署名生成ユニット304は、異なる属性認証局301、302、303から同じユーザに関する異なる属性のセットに関連付けられる暗号鍵311、312、313を受信するよう構成される受信ユニット307を有することができる。署名生成ユニット304は更に、結合ユニット308を有することができる。結合ユニット308は、外部ソースから又は署名生成ユニット304のストレージ手段からメッセージ305を受信するよう構成されることができる。結合ユニットは更に、受信ユニット307から暗号鍵311、312、313を受信することができる。結合ユニット308は更に、メッセージ305に関する暗号署名306を生成するため、同じユーザに関する複数の暗号鍵311、312、313を結合するよう構成されることができる。この場合、暗号署名306は、複数の暗号鍵311、312、313からの属性に関連付けられる。複数の属性認証局301、302、303は、共通のオーダーpの共通のバイリニアグループGに基づき、暗号鍵311、312、313を生成するよう構成されることができる。署名生成ユニット304、特に結合ユニット308は、バイリニアグループGのメンバーであるメッセージに関する署名を生成するよう構成されることができる。結果的に、独立属性認証局301、302、303からの暗号鍵はすべて、同じバイリニアグループGからのメッセージに関して作動する。更に又は代替的に、複数の属性認証局301、302、303は、共通のハッシュ関数に基づき暗号鍵311、312、313を生成するよう構成されることができる。例えば、ハッシュ関数は、バイリニアグループGの要素に対してユーザに関する識別子をマッピングするために用いられることができる。個別のユーザは、単一のユーザ識別子を用いて複数の属性認証局301、302、303にわたり特定されることができる。複数の属性認証局301、302、303は、対応するユーザ識別子に基づきユーザに関する暗号鍵311、312、313を生成するよう構成されることができる。同じユーザ識別子に基づかれる暗号鍵だけが、組み合わされた署名306を形成するために結合ユニットにより結合されることができるという態様で、暗号スキームはセットアップされることができる。署名生成ユニット304、特に結合ユニット308は、署名306の少なくとも一部を形成するため、図1を参照して説明されるように、ユーザ秘密鍵SKを、この場合暗号鍵311、312、313を、無効データR1、R2、R3に結合するよう構成されることができる。しかしながら、鍵無効に関するサポートはないが複数の属性認証局に関するサポートがあるようなシステムを構築することも可能である。鍵無効に関するサポートはあるが、複数の属性認証局に関するサポートがないようなシステムを構築することも可能である。図3のシステムは、ワークステーションにおいて、例えば分散型コンピュータシステムを用いて、実現されることができる。システムの部分、例えば署名生成ユニット304は、医療画像取得装置に組み込まれることができる。署名生成ユニット304及び属性認証局301、302、303の各々は、分離したデバイスにおいて実現されることができる。同じデバイスにおいてこれらの要素のいくつかを結合することも可能である。本書において、例えば、デバイスは、ワークステーション又は携帯型のデバイスとすることができる。図4は、複数の属性認証局からの属性を用いてメッセージに署名する方法を示す。この方法は、例示を介して、属性のセットに関連付けられる暗号鍵を複数の属性認証局によりユーザに独立して発行するステップ401を含む。この方法は更に、署名生成ユニットにより、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信するステップ402を含む。この方法は更に、署名生成ユニットにより、メッセージに関する暗号署名を生成するため、同じユーザに関する複数の暗号鍵を結合するステップ403を含む。ここで、暗号署名は、複数の暗号鍵からの属性に関連付けられる。この方法は、適切なストレージ媒体に格納される1つ又は複数のコンピュータプログラムにより、少なくとも部分的に実現されることができる。以下のアルゴリズムは、分散されたマルチ認証局の属性ベースの署名スキームにおいて用いられることができる。これらのアルゴリズムは、単に例示として機能するにすぎない。1.:このアルゴリズムは、入力として、セキュリティパラメータλを取り、システムに関するグローバルパラメータを返す。このパラメータは、公開である。これらのグローバルパラメータは、例えばハッシュ関数及びバイリニアマップといった情報を有することができる。これらのグローバルパラメータは、他のアルゴリズムにより用いられることができる。セキュリティパラメータλは、例えば属性認証局及び署名生成ユニットのアルゴリズムにおいて使用されるグループのオーダーといった情報を定めることができる。セキュリティパラメータλは、システムにおける最も重要な要素の入力及び/又は出力サイズを規定することができる。例えば、有限循環群、即ちG0及びG1に関して、それは、それらのオーダーnプライムとすることができる。ハッシュ関数の場合、グローバルパラメータは、それらの出力のサイズを定めることができる。この情報は、公開であり、公開パラメータPKの一部であると考えられる。グローバル設定は、すべての認証局において共通とすることができる。認証局は、例えばグループ、ハッシュ関数及びバイリニアマップといったアルゴリズムにおいて使用されるパラメータに同意することができる。2.:各属性認証局は、入力として、GPを取ることにより自身のセットアップを実行し、自身の公開及びマスター秘密鍵ペアであるPKi及びMKiを生成する。3.:鍵生成アルゴリズムは、入力として、属性認証局iのマスター秘密鍵MKi及び認証局が秘密鍵を発行することができるユーザの属性ωUを取る。更に、これは、入力として、ユーザの識別子IUを取り、ここで、IUは、マルチ認証局属性ベースの署名システムにおいてユニークである。例えば、IUは、社会保障番号を有する。アルゴリズムの出力は、属性認証局iにより発行されるユーザIUの属性に関する秘密鍵要素を有する。4.:署名アルゴリズムは、入力として、属性のセットωに関連付けられるユーザUの秘密鍵及び署名されるメッセージMを取る。アルゴリズムの出力は、署名σを有する。本書において、は、異なる属性認証局iにより発行される秘密鍵要素を有する。5.:検証アルゴリズムは、入力として、異なる属性認証局iに関して生成される公開鍵PKiを有する公開パラメータPK={PKi}i及び署名σを取る。検証が成功すれば、それはYを戻し、さもなければ、それはNを戻す。上述のマルチ認証局の属性ベースの署名スキームにおいて、属性認証局は、互いに秘密情報を共有する必要がない。効率性を改善するため及びスキーム共謀に抵抗するために、いくつかの公開情報だけが共有される。例示に過ぎないものを用いて、メインアルゴリズムの以下の説明において更なる詳細が与えられる。1.:セットアップアルゴリズムは、プライムオーダーp及びランダム生成器gのバイリニアグループG0を選択する。それは、バイリニアマップも選択する。これに加えて、ユーザuに関する識別子、即ちIuをG0の要素にマッピングするハッシュ関数の説明が公表される。2.:属性認証局は、ランダムにを選び、属性のセットに関して、をセットする。ここで、は、属性認証局iが秘密鍵要素を発行することができる属性のセットである点に留意されたい。公開鍵PKi及びマスター秘密鍵MKiは、以下の要素から成ることができる。3.:鍵生成アルゴリズムは、認証局iが秘密鍵要素を発行するにふさわしいillegible、eligible属性セットωiに関連付けられるユーザ秘密鍵を出力する。秘密鍵は、以下の要素を有することができる。ここで、h=HIuである。4.:メッセージに署名するため、アルゴリズムは、ランダム要素を選択し、以下の要素を有することができる署名σを計算する。ここで、が成り立ち、ωiは、属性認証局iにより管理される属性セットであり、nは、属性認証局の総数である。5.:署名を検証するため、検証者は、が成立するかを検証することができる。ここで、である。もしこれが成立する場合、署名は受け入れられることができる。本発明は、本発明を実行するよう構成されるコンピュータプログラムに、特に担体上又は内のコンピュータプログラムに延在することを理解されたい。このプログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた中間ソースコード及び中間オブジェクトコードの形式、又は本発明による方法を実現するための使用に適した他の任意の形式とすることができる。斯かるプログラムが、多くの異なる設計上のデザインを持つことができる点も理解されたい。例えば、本発明による方法又はシステムの機能を実現するプログラムコードは、1つ又は複数のサブルーチンに分割されることができる。これらのサブルーチンにおける機能を分散させる多くの異なる態様が当業者には明らかであろう。このサブルーチンは、自己完結的なプログラムを形成するため、1つの実行可能ファイルに一緒に格納されることができる。斯かる実行可能ファイルは、コンピュータ実行可能な命令、例えばプロセッサ命令及び/又はインタプリタ命令例えばJava登録商標インタプリタ命令を有することができる。代替的に、1つ又は複数又は全てのサブルーチンが、少なくとも1つの外部ライブラリファイルに格納されることができ、及び例えば実行時にメインプログラムに静的に又は動的にリンクされることができる。メインプログラムは、少なくとも1つのサブルーチンへの少なくとも1つの呼び出しを含む。サブルーチンは、互いに対する関数呼び出しを有することもできる。コンピュータプログラムに関する実施形態は、記載される方法の少なくとも1つにおける処理ステップの各々に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに再分割されることができ、及び/又は静的に若しくは動的にリンクされることができる1つ又は複数のファイルに格納されることができる。コンピュータプログラムに関する別の実施形態は、本書に記載されるシステム及び/又は製品のうちの少なくとも1つにおける各手段に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに再分割されることができ、及び/又は静的に若しくは動的にリンクされることができる1つ又は複数のファイルに格納されることができる。コンピュータプログラムの担体は、プログラムを実行することができる任意のエンティティ又はデバイスとすることができる。例えば、担体は、CD-ROM又は半導体ROMといったROMのようなストレージ媒体、又は例えばフロッピー登録商標ディスク又はハードディスクといった磁気記録媒体を含むことができる。更に、担体は、例えば電気又は光学信号といった通信可能担体とすることができる。これは、電気又は光学ケーブルを介して又は無線又は他の手段により搬送されることができる。プログラムが斯かる信号において実現されるとき、担体は、斯かるケーブル又は他のデバイス又は手段により構成されることができる。代替的に、担体は、プログラムが埋め込まれる集積回路とすることができる。この集積回路は、関連する方法を実行するよう構成されるか、又は関連する方法の実行に使用されるよう構成される。上述された実施形態は本発明を限定するものではなく、説明するものであり、当業者であれば、添付された請求項の範囲から逸脱することなく、多くの代替的な実施形態をデザインすることができることになることに留意されたい。請求項において、括弧内に配置されるいかなる参照符号も請求項を限定するものとして解釈されるべきではない。動詞有する及びその共役の使用は、請求項において述べられる要素又はステップ以外の要素又はステップの存在を排除するものではない。ある要素に先行する冠詞a又はanは、斯かる要素が複数存在することを除外するものではない。本発明は、複数の個別の要素を有するハードウェアを用いて、及び適切にプログラムされたコンピュータを用いて実現されることができる。複数の手段を列挙するデバイスクレームにおいて、複数のこれらの手段がハードウェアの1つの同じアイテムにより実現されることができる。特定の手段が相互に異なる従属項に記載されるという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示すものではない。"