(57)【特許請求の範囲】
【請求項１】
属性ベースのデジタル署名システムであって、
ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき署名を生成することによりメッセージに署名する署名生成ユニットを有し、
前記署名生成ユニットが、無効データと前記ユーザ秘密鍵とを組み合わせて前記署名の少なくとも一部を形成するよう構成され、
前記無効データ及び前記ユーザ秘密鍵が、共有された秘密スキームに基づかれ、前記ユーザ秘密鍵が、秘密の共有物を有し、
前記無効データは、複数の有効なユーザ秘密鍵の個別の１つを補完し、
前記無効データが、前記無効にされたユーザ秘密鍵における前記共有物を除き、前記ユーザ秘密鍵における個別の共有物を補完して、前記無効データが、前記ユーザ属性のセットを用いてメッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止し、
更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の一部を選択的に除去する無効ユニットを更に有し、
前記更新された無効データが、前記無効にされるユーザ秘密鍵の一部に基づかれる、システム。
【請求項２】
前記無効ユニットが更に、前記更新された無効データに対応する無効検証要素を提供するよう構成され、
前記システムは、前記無効検証要素に基づき、前記署名を検証する署名検証ユニットを有する、請求項１に記載のシステム。
【請求項３】
前記無効ユニットが、前記無効データを用いて、前記ユーザ秘密鍵の少なくとも１つのユーザ属性に関連付けられる前記署名能力を選択的に除去するよう構成される、請求項１に記載のシステム。
【請求項４】
複数の属性認証局であって、一の属性認証局が、他の属性認証局と独立してユーザに秘密鍵を発行するよう構成され、前記秘密鍵が、属性のセットに関連付けられる、複数の属性認証局と、
署名生成ユニットであって、
異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の秘密鍵を受信する受信ユニットと、
メッセージに関する暗号署名を生成するため、前記同じユーザに関する前記複数の秘密鍵を結合する結合ユニットであって、前記暗号署名が、前記複数の秘密鍵からの属性に関連付けられる、結合ユニットとを含む、署名生成ユニットとを有する、請求項１に記載の属性ベースのデジタル署名システム。
【請求項５】
前記複数の属性認証局が、公開パラメータを用いて、自身の公開及びマスター秘密鍵を生成するよう構成される、請求項４に記載のシステム。
【請求項６】
個別のユーザが、ユーザ識別子を用いて前記複数の属性認証局にわたり特定され、
前記複数の属性認証局が、前記対応するユーザ識別子に基づきユーザに関する前記秘密鍵を生成するよう構成される、請求項４に記載のシステム。
【請求項７】
請求項１に記載のシステムを有するワークステーション。
【請求項８】
請求項１に記載のシステムを有する医療画像取得装置。
【請求項９】
属性ベースのデジタル署名処理システムの作動方法において、
ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき、無効データと前記ユーザ秘密鍵とを組み合わせて署名を生成する前記システムに含まれる署名生成ユニットにより、メッセージに署名するステップを有し、
前記無効データ及び前記ユーザ秘密鍵が、共有された秘密スキームに基づかれ、前記ユーザ秘密鍵が、秘密の共有物を有し、
前記無効データが、複数の有効なユーザ秘密鍵の個別の１つを補完し、
前記無効データが、前記無効にされたユーザ秘密鍵における前記共有物を除き、前記ユーザ秘密鍵における個別の共有物を補完して、前記無効データは、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止し、
前記システムに含まれる無効ユニットにより、更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の一部を選択的に除去するステップを更に有し、
前記更新された無効データが、前記無効にされるユーザ秘密鍵の一部に基づかれる、作動方法。
【請求項１０】
前記システムに含まれる複数の属性認証局により、属性のセットに関連付けられる秘密鍵をユーザに独立して発行するステップと、
前記署名生成ユニットにより、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の秘密鍵を受信するステップと、
前記署名生成ユニットにより、メッセージに関する暗号署名を生成するため、前記同じユーザに関する前記複数の秘密鍵を結合するステップであって、前記暗号署名が、前記複数の秘密からの属性に関連付けられる、ステップとを有する、請求項９に記載の作動方法。
【請求項１１】
属性ベースのデジタル署名処理のコンピュータプログラムであって、コンピュータを、
ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき、無効データと前記ユーザ秘密鍵とを組み合わせて署名を生成する署名生成手段として機能させ、
前記無効データ及び前記ユーザ秘密鍵が、共有された秘密スキームに基づかれ、前記ユーザ秘密鍵が、秘密の共有物を有し、
前記無効データが、複数の有効なユーザ秘密鍵の個別の１つを補完し、
前記無効データが、前記無効にされたユーザ秘密鍵における前記共有物を除き、前記ユーザ秘密鍵における個別の共有物を補完して、前記無効データは、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止し、
更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の一部を選択的に除去する無効手段として更に機能させ、
前記更新された無効データが、前記無効にされるユーザ秘密鍵の一部に基づかれる、コンピュータプログラム。
【請求項１２】
異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の秘密鍵を受信する手段と、
メッセージに関する暗号署名を生成するため、前記同じユーザに関する前記複数の秘密鍵を結合する手段であって、前記暗号署名が、前記複数の秘密からの属性に関連付けられる、手段としてコンピュータを更に機能させる、請求項１１に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、属性ベースのデジタル署名システムに関する。本発明は更に、属性ベースのデジタル署名システムにおけるユーザの無効に関する。
【背景技術】
【０００２】
従来のヘルスケアからホームヘルスケアを介して健康サービスへと及ぶケアサイクルに関係する異なる通信相手の間でのデータ交換に関する増大する必要性は、健康データの安全な管理を重要な問題にした。今日の手法は、物理及び管理手順に補われる従来のセキュリティ機構に基づかれる。これは、健康情報の有用性を制限し、健康記録の交換を困難にする。デジタルポリシー管理及びポリシー施行技術は、以下の点でこれらの手法より優れている。（１）異機種間接続ネットワークにおけるエンドツーエンドのプライバシー及びセキュリティが、データが通信されるインフラストラクチャ又は組織の境界とは関係なく、データを保護する。（２）役割ベース又は属性ベースのアクセス制御機構により暗号化が施行される。（３）相互運用可能なセキュリティ設計が、ネットワークを選ばない方法においてシステムを開発することを可能にし、ネットワーク特有なセキュリティ準備に関する必要性をなくし、及び従って、実装及び維持コストを減らすことを可能にする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
データ保護の別の側面は、起源（origin）の否認防止を提供することである。その結果、データの消費者は、データ起源を検証することができる。日常生活では、否認防止を提供するため、デジタル署名が用いられる。これらのデジタル署名方式において、プライベート（又は秘密）及び公開鍵ペアがユーザごとに生成される。この場合、秘密鍵が、メッセージに署名するために用いられることができ、公開鍵が、メッセージにおける署名を検証するために用いられることができる。しかしながら、ヘルスケア組織において、ユーザの役割及び識別を決定するため、通常は属性が用いられ、データに対するアクセス及びメッセージに署名する権限は、ユーザ属性に基づき認可される。斯かる組織のために構築されるコンピュータシステムにおいて、ユーザは、自分が適切な属性のセットを持つ場合にのみ、データを作成又は修正及びデータに署名することができる。したがって、ヘルスケア組織において、属性は、データ起源の重要な側面であるとみなされる。例えば、特殊な役割又は属性を持つユーザ（例えば医師）により署名された場合、薬局は処方オーダーを受け入れる。特殊な属性のセットを持つユーザとしてメッセージ又はコンテンツに署名することを可能にするデジタル署名方式は、属性ベースの署名（ＡＢＳ）方式である。斯かる属性ベースの署名方式は、Dalia Khaderによる「Attribute Based Group Signature with Revocation」、Cryptology ePrint Archive、Report 2007/241、2007、http://eprint.iacr.orgに記載される。引用されたレポートは、属性ベースのグループ署名（ＡＢＧＳ）方式を開示する。そこでは、ユーザが無効にされる場合、検証者が、無効にされたユーザを特定し、及び従って、署名を拒絶する能力を持つ。ユーザが無効にされるかどうかをチェックする（又は検証する）処理は、無効にされたユーザのリストを介して１対１で行われることで、検証認証局によりローカルで行われる。属性ベースの署名（ＡＢＳ）方式において、データは、アクセス構造に基づき署名される。その結果、正しい属性を持つユーザだけがデータに署名することができる。メッセージに署名することが可能であるよう、ユーザは、そのユーザが持つ認証された属性のセットに対応する特殊な秘密鍵を信頼された認証局から得る。しかしながら、開示された属性ベースの署名方式は、ユーザの無効に関して、制限されたサポートしか提供しない。一般に、例えばユーザの秘密鍵が危殆化されるとき、又は、ユーザの状態が変化するとき、ユーザの無効化が望ましい。例えば、ユーザが、別の仕事に変わり、その仕事に関連付けられる他の属性に変化することがある。
【０００４】
改良された属性ベースのデジタル署名システムを持つことが有利である。
【課題を解決するための手段】
【０００５】
この懸念により好適に対処するため、本発明の第１の側面は、あるシステムを提供する。このシステムは、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づきメッセージに署名する署名生成ユニットを有し、上記署名生成ユニットが、上記署名の少なくとも一部を形成するよう無効データと上記ユーザ秘密鍵とを結合するよう構成され、上記無効データは、複数の有効なユーザ秘密鍵の個別の１つを補足し、上記無効データが、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する。
【０００６】
このシステムは、無効データを提供することにより、ユーザ秘密鍵が選択的に無効にされることを可能にする。ユーザを無効にするには、無効データだけが更新されることを必要とする。なぜなら、無効データは、無効にされたユーザ秘密鍵が用いられることを防止し、有効なユーザ秘密鍵を補足するからである。結果として、署名生成ユニットは、新しいユーザ秘密鍵を具備する必要がない。更に、無効データは、無効にされたユーザ秘密鍵でなく、有効なユーザ秘密鍵だけを補足するので、メッセージに署名するために無効にされたユーザ秘密鍵が用いられることが防止される。結果的に、無効にされたユーザ秘密鍵を用いて署名が作られたかどうか見るために、検証ユニットが無効にされたユーザのリストを調べる必要がない。署名生成ユニットは、無効データの最新版を用いるよう構成されることができる。
【０００７】
このシステムは、更新された無効データを提供することにより、無効にされるユーザの秘密鍵の署名能力の少なくとも一部を選択的に除去する無効ユニットを有することができる。この場合、上記更新された無効データが、上記無効にされるユーザ秘密鍵の少なくとも一部に基づかれる。署名生成ユニットにより用いられる更新された無効データは、以前は署名することが許可されていたユーザを無効にする。更新された無効データは、署名生成ユニットに分散されることができる。
【０００８】
上記無効ユニットは、上記更新された無効データに対応する無効検証要素を提供するよう構成され、上記システムは、上記無効検証要素に基づき、上記署名を検証する署名検証ユニットを有することができる。無効検証要素は、例えば数といったデータ要素を有することができる。無効検証要素は、最新の無効データの使用が署名生成ユニットによりどのように実施されるかの例である。
【０００９】
上記無効ユニットが、上記無効データを用いて、上記ユーザ秘密鍵の少なくとも１つのユーザ属性に関連付けられる署名能力を選択的に除去するよう構成されることができる。これは、完全なユーザ秘密鍵の代わりに、ユーザ秘密鍵に関連付けられる属性の１つだけ又はいくつかを無効にすることを可能にする。
【００１０】
無効データ及びユーザ秘密鍵は、共有秘密スキームに基づかれることができる。これは、システムの無効部分を実現する効率的なスキームである。
【００１１】
ユーザ秘密鍵は、秘密の共有物を有することができる。これは、共有秘密のスキームを実現する効率的な態様である。
【００１２】
上記無効データが、上記無効にされたユーザ秘密鍵における上記共有物を除く、上記ユーザ秘密鍵における個別の共有物を補足する。これは、無効を実現する効率的な態様である。無効にされたユーザの共有物は、無効にされていないユーザによる使用のため無効データに含まれることができる。
【００１３】
本発明の別の側面は、属性ベースのデジタル署名システムを提供する。このシステムは、
複数の属性認証局であって、一の属性認証局が、他の属性認証局と独立してユーザに暗号鍵を発行するよう構成され、上記暗号鍵が、属性のセットに関連付けられる、複数の属性認証局と、
署名生成ユニットであって、
異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信する受信ユニットと、
メッセージに関する暗号署名を生成するため、上記同じユーザに関する上記複数の暗号鍵を結合する結合ユニットであって、上記暗号署名が、上記複数の暗号鍵からの属性に関連付けられる、結合ユニットとを含む、署名生成ユニットとを有する。
【００１４】
これは、異なる独立認証局により許可される属性をサポートすることをより容易にする。なぜなら、認証局は、ユーザに発行される属性を調整するために中央認証局に依存する必要なしに、ユーザに鍵を発行することができるからである。署名生成ユニットは、中央又は媒介認証局に依存することなしに、鍵を受信し、これらを結合することもできる。属性認証局に特有な秘密情報を発行する中央認証局を持つ必要がなくなる。
【００１５】
複数の属性認証局は、自身の公開及びマスター秘密鍵を生成するよう構成されることができる。公開及びマスター秘密鍵は、公開パラメータに基づかれることができる。公開パラメータは、すべての属性認証局に関して同じとすることができる。こうして、属性認証局は、秘密鍵を得るのに中央認証局に依存しない。これは、属性認証局が独立して作動することを可能にするのを助ける。
【００１６】
複数の属性認証局は、メッセージのサイズを含む公開パラメータのセットに基づき、暗号鍵を生成するよう構成されることができる。これは、メッセージが、異なる属性認証局からの暗号鍵を用いて容易に処理されることを可能にする。代替的に、複数の属性認証局は、共通のオーダーｐの共通のグループＧに基づき、暗号鍵を生成するよう構成されることができ、署名生成ユニットは、グループＧのメンバーであるメッセージｍに関する署名を生成するよう構成される。これは、独立認証局からの暗号鍵を結合することをより容易にする。なぜなら、それらの全ては、グループＧのメンバーであるメッセージに関して用いられることができるからである。結果的に、１つのグループから他のグループに対しメッセージを変換する必要がない。同様に、属性認証局は、同じハッシュ関数を用いるよう構成されることができる。
【００１７】
個別のユーザは、ユーザ識別子を用いて複数の属性認証局にわたり特定されることができる。更に、複数の属性認証局は、対応するユーザ識別子に基づきユーザに関する暗号鍵を生成するよう構成されることができる。異なる独立認証局における同じユーザ識別子を用いて、組み合わされたデジタル署名を形成するために暗号鍵を結合することはより容易である。更に、異なるユーザに関して生成される暗号鍵が、複数のユーザからの属性を用いて署名を生成するために署名生成ユニットにより結合されることが、防止されることができる。
【００１８】
本発明の別の側面は、上述されたシステムを有する医療ワークステーションを提供する。これは、このシステムが都合よく作動することを可能にする。
【００１９】
本発明の別の側面は、上述されたシステムを有する医療画像取得装置を提供する。これは、一体化された機能の提供を可能にする。例えば、それは、取得した画像データの署名を生成することを容易にする。
【００２０】
本発明の別の側面は、属性ベースのデジタル署名処理の方法を提供し、この方法は、ユーザ属性のセットに関連付けられるユーザ秘密鍵に基づき、メッセージに署名するステップを有し、上記生成が、無効データと上記ユーザ秘密鍵とを結合することを含み、上記無効データが、有効なユーザ秘密鍵を補足し、上記無効データは、メッセージに有効に署名するのに無効にされたユーザ秘密鍵が用いられることを防止する。
【００２１】
本発明の別の側面は、プロセッサシステムに上述された方法を実行させる命令を有するコンピュータプログラムを提供する。
【図面の簡単な説明】
【００２２】
【図１】属性ベースのデジタル署名システムの側面を示すブロック図である。
【図２】属性ベースのデジタル署名処理の方法の側面を示すフローチャートである。
【図３】マルチ認証局の属性ベースのデジタル署名システムの側面を示すブロック図である。
【図４】マルチ認証局システムにおける属性ベースのデジタル署名処理の方法の側面を示すフローチャートである。
【発明を実施するための形態】
【００２３】
本発明のこれら及び他の側面が、以下に説明される実施形態を参照して明らかとなり、これらの実施形態を参照して説明されることになる。
【００２４】
属性ベースの署名方式において、署名者は、属性のセットに関連付けられる秘密鍵を持つ。彼は、メッセージにおける署名を作成するのにこの秘密鍵を使用することができる。署名が正しい属性のセットと関連付けられる秘密鍵により生成される場合にだけ、この署名が受け入れられる。属性ベースの署名は、グループ署名の一形式とみなされることができる。大きな差異は、それが検証者が署名者の属性（例えば役割）を決定することを可能にする点にある。しかしながら、実際には、特殊な属性のセットを持つユーザが特殊なメッセージに署名することが許されない場合があるシナリオが存在する（例えば、ユーザは、自分自身の出張リクエストを承認するため署名することは許されない。また、このユーザの秘密鍵が無効にされれば、将来いかなるメッセージに署名することも許されない。）。本書では、特殊なユーザを無効にする能力を持つ属性ベースの署名方式が記載される。こうして、無効にされたユーザがメッセージに署名する場合、それが検証者によって受け入れられることはない。
【００２５】
属性ベースの署名（ＡＢＳ）において、データは、アクセス構造（又は属性のセット）に基づき署名される。その結果、正しい属性を持つユーザだけがデータに署名することができる。メッセージに署名することが可能であるよう、ユーザは、そのユーザが持つ認証された属性のセットに対応する特殊な秘密鍵を信頼された認証局から得る。ユーザの状態は変化することができる（例えば、ユーザは、仕事を変える。）。また、ユーザの秘密鍵は、危殆化されるかもしれない。そのような場合、理想的には、システムは、最初からもう一度システム（及び他のユーザのすべての秘密鍵）をセットアップすることなしに、ユーザを無効にすることが可能であるべきである。
【００２６】
上述したニーズに対処するため、ＡＢＳは、無効能力を持つよう拡張されることができる。これは、例えば、秘密共有に基づき実行されることができる。各ユーザは、個人化された共有物を、例えばベキ指数において得る。この個人化された共有物は、例えば鍵認証局から秘密鍵を要求するとき得られることができ、その後更新されることができる。各ユーザは、秘密を回復するため、無効にされたユーザの共有物を自分の共有物と結合する。これは、署名者が、有効な署名を生成するのを助ける。無効は、署名者ローカルである。なぜなら、署名者が、共有物の組合せを実行するからであり、この組み合わせは、無効でないユーザにとってのみ可能だからである。結果的に、無効は、署名を生成する時すでに明らかになる。こうして、ユーザが無効にされず（メッセージに署名することが許される）、正しい属性のセットを所有する場合、彼は有効な署名を生成することが可能である。そうでなければ、彼は、有効な署名を生成することができない。
【００２７】
図１は、属性ベースのデジタル署名システムのブロック図を示す。このシステムは、電子回路において、又は、ソフトウェアを用いて実現されることができる。通常、システム要素は、示されたデータ要素を通信することにより互いに相互作用する複数のデバイスにわたり分散される。
【００２８】
システムは、ユーザ属性のセットωと関連付けられるユーザ秘密鍵ＳＫに基づき署名σを生成することにより、メッセージｍに署名する署名生成ユニット１を有する。署名生成ユニット１は、秘密鍵ＳＫを用いて属性セットωに基づきメッセージｍに署名するよう構成されることができる。異なるユーザに対して複数のユーザ秘密鍵ＳＫが存在することができる。複数の署名生成ユニット１が存在することもできる。各署名生成ユニット１は、ユーザ秘密鍵ＳＫの１つを用いるよう構成されることができる。
【００２９】
署名生成ユニット１は、無効ユニット２から無効データＲを得るよう構成されることができる。このために、無効ユニット２は、無効データＲをネットワーク位置で利用可能にするよう構成されることができる。斯かるネットワーク位置及び無効データＲは、複数の署名生成ユニット１に対して利用可能とされることができる。署名生成ユニット１は、署名σの少なくとも一部を形成するため、無効データＲとユーザ秘密鍵ＳＫとを結合するよう構成されることができる。このために、無効データＲは、複数の有効なユーザ秘密鍵の個別の１つを補う。本書において、有効なユーザ秘密鍵は、無効にされていないユーザの秘密鍵を参照する。無効データＲは有効なユーザの秘密鍵だけを補うので、無効データＲは、ユーザ秘密鍵ＳＫと関連付けられる属性のセットωを持つメッセージｍに有効に署名するために無効にされたユーザ秘密鍵ＳＫが用いられることを防止する。結果的に、ユーザ秘密鍵ＳＫは、秘密鍵ＳＫを用いて属性のセットωに基づきメッセージｍに署名するために用いられることができない。
【００３０】
このシステムは、更新された無効データＲを提供することにより、無効にされるユーザ秘密鍵ＳＫの署名能力の少なくとも一部を選択的に除去する無効ユニット２を有することができる。この場合、更新された無効データＲは、無効にされるユーザ秘密鍵ＳＫの少なくとも一部に基づかれる。
【００３１】
無効ユニット２は更に、更新された無効データＲに対応する無効検証要素ＲＶＣを提供するよう構成されることができる。この無効検証要素ＲＶＣは、署名σの有効性を検証するために用いられることができる。
【００３２】
システムは、無効検証要素ＲＶＣに基づき署名σを検証する署名確認ユニット３を有することができる。検証ユニット３の出力ｖは、署名σの有効性を示すことができる。例えば、署名σ及び無効検証要素ＲＶＣを含む暗号処理の結果は、署名σの有効性を示す。署名確認ユニット３は更に、検証のため公開鍵ＰＫを使用することができる。
【００３３】
無効ユニット２は、無効データＲを用いて、ユーザ秘密鍵ＳＫの少なくとも１つのユーザ属性に関連付けられる署名能力を選択的に除去するよう構成されることができる。例えば、ユーザ属性を表すユーザ秘密鍵ＳＫの一部は、無効データにより補われることができる。署名生成ユニット１は、無効データＲとユーザ属性を表す部分とを結合するよう構成されることができる。こうして、全部のユーザの秘密鍵ＳＫではなく、ユーザ秘密鍵ＳＫに関連付けられる属性だけを無効にすることが可能である。結果的に、署名生成ユニットは、無効にされた属性を必要としないポリシーに対する署名を生成するためにまだ使用されることができる。
【００３４】
無効データＲ及びユーザ秘密鍵ＳＫは、共有秘密方式に基づかれることができる。例えば、ユーザ秘密鍵ＳＫは、秘密の共有物を有する。無効データＲは、無効にされたユーザ秘密鍵ＳＫにおける共有物を除き、ユーザ秘密鍵における個別の共有物を補う。例えば、ｎ個の異なる共有物の最小数が、秘密を再構築するために必要とされることができる。無効データは、ｎ−１個の共有物を有することができる。ユーザ秘密鍵ＳＫは、１つの共有物を有することができる。この場合、各ユーザ秘密鍵ＳＫは、異なる共有物を有する。無効データのｎ−１個の共有物は、ｎ個の共有物の最小数を形成するため、ユーザ秘密鍵の共有物の個別の１つを補う。ユーザ秘密鍵を無効にするため、無効にされたユーザの共有物は、ｎ−２個の他の共有物と共に、無効データＲに含まれることができる。無効にされていないユーザ秘密鍵は、ｎ個の共有物を形成するため無効データＲと組み合わせられるので、それらは秘密を再構築することができる。しかしながら、無効にされたユーザ秘密鍵の共有物は、無効データＲにおける共有物の１つと同じである。従って、無効データＲと結合される無効にされたユーザ秘密鍵は、ｎ−１個の共有物を形成するだけである。これは、秘密を再構築するには不十分である。結果的に、無効にされたユーザ秘密鍵は、秘密を再構築するために用いられることができない。
【００３５】
システムは更に、鍵生成ユニット４を有することができる。鍵生成ユニット４は、例えばマスター秘密鍵ＭＫに基づき、署名生成ユニット１により使用されるユーザ秘密鍵ＳＫを生成することができる。無効に対するサポートを実現するため、秘密鍵ＳＫは、秘密の共有物を有することができる。マスター秘密鍵ＭＫは、セットアップユニット５により生成されることができる。また、セットアップユニット５は、１つ又は複数の公開鍵ＰＫ、無効データＲ及び／又は無効検証要素ＲＶＣを生成するよう構成されることができる。後者は、無効ユニット２により検証ユニット３に提供されることができる。公開鍵ＰＫは、署名確認ユニット３により使用されることができる。鍵生成ユニット４及びセットアップユニット５は、信頼された認証局６の一部であるか、又はこれにより制御されることができる。図において無効ユニット２は、信頼された認証局６とは分離しているが、無効ユニット２も、信頼された認証局６の一部であるか、又はこれにより制御されることができる。ユーザを無効にするため、セットアップユニット５は、無効にされたユーザの共有物を含むよう無効データＲを更新し、及び無効検証データＲＶＣを更新することができる。これは、検証ユニット３が、更新された無効データＲに基づき、署名生成ユニット１により生成される署名σを検証することを可能にする。
【００３６】
このシステムは、例えば放射線学ワークステーションといった医療ワークステーションに組み込まれることができる。署名生成ユニット１、無効ユニット２、署名検証ユニット３及び／又は鍵生成ユニット４の１つ又は複数の機能を提供するため、このワークステーションは、プロセッサ及び適切なソフトウェアがロードされるメモリだけでなく、ワークステーションを作動させるためのモニタ、キーボード及び／又はマウスを有することができる。
【００３７】
このシステムは、例えばＸ線装置又はＭＲＩスキャナといった医療画像取得装置に組み込まれることができる。例えば、ユーザインタフェースは、医療画像取得装置により提供されることができる。これは、ユーザが、ユーザ秘密鍵ＳＫを用いて画像データを認証することを可能にする。
【００３８】
システムは、例えば病院情報システム又は画像アーカイブシステムといった医療情報システムに組み込まれることもできる。斯かるシステムにおいて、図１により表される機能は、１つ又は複数の中央サーバを用いて実現されることができる。
【００３９】
実装においては、図示される機能が、例えばユニット、処理又はサブルーチンへと多くの異なる態様で分けられることができる点を理解されたい。この点で、図１のブロック図は、単なる例示を提供するにすぎない。更に、機能は、複数のハードウェア装置にわたり分散されることができる。図１の異なるブロックが、異なるデバイス上で実行されるように設計されることができるが、これは限定でない。
【００４０】
図２は、属性ベースのデジタル署名処理の方法を示す。この方法は、ユーザ属性のセットに関連付けられるユーザ秘密鍵ＳＫに基づき、署名σを生成するステップ２０２を有する。ステップ２０２は、無効データＲとユーザ秘密鍵ＳＫとを結合するサブステップ２０３を有することができる。本書において、無効データＲは、複数の有効なユーザ秘密鍵の個別の１つを補足する。ここで、無効データＲは、上述された態様で、メッセージｍに有効に署名するために無効にされたユーザ秘密鍵ＳＫが用いられることを防止する。ステップ２０４において、署名σは、検証されることができる。ステップ２０５において、ユーザ秘密鍵が無効にされるべきかが決定される。無効にされるべきでない場合、処理は、ステップ２０２に戻る。ユーザ秘密鍵を無効にするため、処理は、更新された無効データＲ及び更新された無効検証要素ＲＶＣを生成するため、ステップ２０６へ進む。更新された無効データＲは、ステップ２０２の次の実行において用いられ、無効検証要素ＲＶＣは、ステップ２０４の次の実行において用いられる。この方法は、コンピュータプログラムとして実現されることができる。
【００４１】
以下に、より詳細な例示的な実施形態が説明される。
【００４２】
ユーザ無効能力を持つ例示的な属性ベースの署名スキームにおいて、ユーザがデータに署名するとき、ユーザは、信頼された認証局から無効にされたユーザ共有物
0006014585.tif 000002
のリストを受け取ることができる（代替的に、署名者は、例えば、無効ユニット２により維持される公開データベースにおいて
0006014585.tif 000003
を探すことができる）。有効な署名を生成するため、ユーザは、ユーザが所有する属性セットωに関連付けられる秘密鍵を必要とする。ユーザの共有物は、
0006014585.tif 000004
の中にあるべきではない。ユーザの共有物が
0006014585.tif 000005
の中にある場合、ユーザは、有効な署名を生成することが可能であるべきでない。
【００４３】
署名スキームに関係するアルゴリズムは、セットアップ、鍵生成、署名、検証及び無効を含むことができる。これらが、以下に説明されることができる。
【００４４】
0006014585.tif 000006
：セットアップアルゴリズムは、初期化フェーズの間、システムパラメータを構成し、公開パラメータ又は公開鍵
0006014585.tif 000007
及びマスターキー
0006014585.tif 000008
を出力する。無効アルゴリズム
0006014585.tif 000009
は、セットアップアルゴリズムのサブアルゴリズムとして実現されることができ、セットアップユニット５又は信頼された認証局６により実行されることができる。しかしながら、無効サブアルゴリズムは、初期セットアップの間に実行される残りのステップとは独立して実行されることができる。無効データ
0006014585.tif 000010
は、無効ユニット２により、署名生成ユニット１及び／又は署名検証ユニット３へと分散されることができる。無効サブアルゴリズムは、入力として、既存の無効データ
0006014585.tif 000011
及び無効にされたユーザのユーザ識別
0006014585.tif 000012
を取り、更新された無効データ
0006014585.tif 000013
を出力する。この更新されたデータにおいて、識別
0006014585.tif 000014
を持つユーザが無効にされる。また、無効アルゴリズムは、無効検証要素
0006014585.tif 000015
を生成することができる。
【００４５】
0006014585.tif 000016
：鍵生成ユニット４により実行され、鍵生成アルゴリズムは、入力として、ユーザが所有する属性セット
0006014585.tif 000017
、ユーザ識別
0006014585.tif 000018
及びマスター秘密鍵
0006014585.tif 000019
を取り、ユーザ秘密鍵
0006014585.tif 000020
を出力する。
【００４６】
0006014585.tif 000021
：署名生成ユニット１により実行され、このアルゴリズムは、入力として、メッセージｍ、ユーザ秘密鍵
0006014585.tif 000022
、公開鍵
0006014585.tif 000023
、及び、例えば無効にされたユーザの共有物を含む共有物のセットの形で、無効データ
0006014585.tif 000024
を取る。アルゴリズムは、メッセージ
0006014585.tif 000025
の署名σωを戻す。署名は、特定のポリシーを満たす署名として検証可能でありえる。代替的に、署名が、ユーザ秘密鍵
0006014585.tif 000026
に関連付けられる属性
0006014585.tif 000027
で署名された署名として検証可能でありえる。
【００４７】
0006014585.tif 000028
：このアルゴリズムは、署名検証ユニット３により実行されることができる。このアルゴリズムは、入力として、メッセージ
0006014585.tif 000029
、公開鍵
0006014585.tif 000030
、署名σω及び無効検証要素
0006014585.tif 000031
を取る。アルゴリズムは、署名σωが有効な署名であるかどうかを示すデータ値を戻す。
【００４８】
アルゴリズムは、無効にされたユーザの数
0006014585.tif 000032
に線形依存する複雑さを持つことができる。署名スキームの計算の複雑性及びサイズは更に、ユーザの総数
0006014585.tif 000033
ではなく、アクセス構造における属性の数に線形依存することができる。このアクセス構造に基づき、署名が署名される。
【００４９】
例えば、ユーザは、セットアップフェーズの間（秘密鍵生成（ＰＫＧ）認証局から秘密鍵を得るとき）、個人化された共有物を指数において得ることができる。その後、各無効にされていないユーザは、（ＰＫＧにより又は無効ユニットによりブロードキャストされる）無効にされたユーザの共有物又はダミー共有物と指数における個人化された共有物とを結合することができる。これは、署名の有効な要素の回復を生じさせる。
【００５０】
ユーザの無効化を支持するため、検証認証局は、署名検証をするため、無効リストからの１つのグループ要素を具備することができる。検証のとき、ユーザが無効にされるかどうかを検証するため、無効にされたユーザの全体のリストを調べる必要がない。ユーザが無効にされる場合、署名は、共有された秘密のスキームに基づかれる無効な要素を含み、署名が、無効であることが検証される。
【００５１】
提案されたスキームは、例えば、共謀抵抗、非可鍛性、ユーザ匿名及び非リンク性といった署名スキームの望ましい特性を満たすことができる。
【００５２】
ある実施形態は、セットアップ、鍵生成、署名、検証及び無効に関する以下のアルゴリズムを有する。このスキームにおいて、ユーザ属性は、
0006014585.tif 000034
の要素である。我々は、最大でｋ個の属性が存在すると想定する。しかしながら、これは、限定事項ではない。実際において、例えば、ユーザは、
0006014585.tif 000035
の要素に対して属性ストリングをマッピングするため、衝突抵抗ハッシュ関数を用いることができる。
【００５３】
１．
0006014585.tif 000036
：セットアップアルゴリズムは、プライムオーダーｐ及びランダム生成器ｇ及びｈのバイリニアグループ
0006014585.tif 000037
を選択する。これは、バイリニアマップ
0006014585.tif 000038
も選択する。更に、セットアップは、ランダムに
0006014585.tif 000039
を選び、属性のセット
0006014585.tif 000040
に対して、これは
0006014585.tif 000041
をセットする。セットアップアルゴリズムは、本書において無効アルゴリズムと呼ばれる別のサブアルゴリズムを有する。この無効アルゴリズムは、無効にされたユーザに関する共有物を生成するために用いられる。
【００５４】
１．１  無効:無効の目的で用いられることができる各ユーザに関する共有物を生成するため、このアルゴリズムは、セットアップアルゴリズムでも実行される。無効の目的で、それは、
0006014585.tif 000042
を選び、
0006014585.tif 000043
に対する次数ｒのランダムな多項式
0006014585.tif 000044
を生成する。これは、Ｐ（０）＝Ｒ＝ａ０をセットする。ここで、多項式Ｐのｔ＋１の共有物は、Ｒを再構築するのに用いられることができる。秘密ａ０＝Ｒ＝Ｐ（０）を再構築するには、多項式Ｐのｒ＋１の共有物が必要とされる点に留意されたい。
0006014585.tif 000045
であり、Ｎがシステムにおけるユーザの総数であるような場合、ユーザ
0006014585.tif 000046
に対して、共有物
0006014585.tif 000047
は、多項式Ｐから生成される。セットアップアルゴリズムは、ｒ個の余分なダミー共有物
0006014585.tif 000048
も計算することができる。これは、無効にされたユーザの数がｒより少ない場合、ブロードキャストされることができる（又は、公開データベースに置かれる）。例えば、ｒユーザが無効にされる場合、アルゴリズムは、
0006014585.tif 000049
を選択し、
0006014585.tif 000050
を有する無効データを生成する。
【００５５】
するとこの無効データは、公開データベースに置かれるか、又はユーザにブロードキャストされる。
【００５６】
公開鍵
0006014585.tif 000051
及びマスターキー
0006014585.tif 000052
は、以下の要素
0006014585.tif 000053
を有することができる。
【００５７】
２．
0006014585.tif 000054
：鍵生成アルゴリズムは、属性セットω及び識別
0006014585.tif 000055
に関連付けられるユーザ秘密鍵を出力する。アルゴリズムは、ランダム要素
0006014585.tif 000056
を選び、以下の要素
0006014585.tif 000057
から成る秘密鍵
0006014585.tif 000058
を計算する。
【００５８】
秘密鍵も、ユーザの個人化された共有物、即ちＳ（２，１）から成る。これは、ユーザが無効にされたユーザの１人でない場合、有効な署名を生成するため、無効にされたユーザの共有物と組み合わせるために用いられる。
【００５９】
３．
0006014585.tif 000059
：このアルゴリズムは、入力として、ユーザ秘密鍵、無効にされたユーザの共有物及び署名されるメッセージｍを取る。メッセージ
0006014585.tif 000060
に署名するために、アルゴリズムは、ランダム要素
0006014585.tif 000061
を選択し、署名σを計算する。この署名は、以下の要素
0006014585.tif 000062
を有することができる。
【００６０】
ユーザが無効にされていない場合にのみ、ユーザは、有効な署名を生成することが可能である。
【００６１】
４．
0006014585.tif 000063
：このアルゴリズムは、入力として、検証される署名、公開鍵及びＲＶＣ要素を取る。ＲＶＣ要素は、Ｓｅｔｕｐ（）アルゴリズムに示される公開鍵の一部である。しかしながら、明確さのため、我々は、それを別々に示す。署名は、
0006014585.tif 000064
のような態様で検証される。
【００６２】
上記の式が成立する場合、署名は受け入れられることができる。
【００６３】
属性ベースの署名（ＡＢＳ）スキームにおいて、データは、属性のセットに基づき署名される。メッセージに署名することが可能であるために、ユーザは、信頼された認証局から、その者が持つことを許可された属性のセットに対応する特定の秘密鍵を得る。しかしながら、実際は、異なる属性が、異なる認証局により管理されることができる。従って、マルチ認証局の属性ベースの署名スキームに関する必要性が存在する。そこでは、ユーザが、異なる属性認証局から秘密鍵要素を得ることができる。例えば、個人が処方オーダーに署名するとき、彼は、複数の認証局により割り当てられた複数の属性に基づき署名する。例えば、個人は、大学でパートタイムとして働き、病院でパートタイムとして働くことがある。斯かるシナリオにおいて、ユーザは、例えば大学と病院の両方の組織から、秘密鍵要素を取得することができる。以下ユーザが文書に署名するとき、彼は、複数の認証局により管理されるこれらの属性に基づき署名する。
【００６４】
この需要に対処するため、マルチ認証局の属性ベースの署名スキームが提案される。しかしながら、既知のマルチ認証局の属性ベースの署名スキームは、中央認証局の存在に依存する。この中央認証局は、システムにおける全ての属性認証局及びユーザにより信頼されているべきである。中央認証局の主要な機能は、分散された属性認証局の間の同期を確立することである。これは、共謀を防止するために必要である。共謀は、第１の属性認証局「Ａ１」から第１のユーザに発行される第１の秘密鍵要素と第２の属性認証局「Ａ２」から第２のユーザに発行される第２の秘密鍵要素の知識を持つ悪意あるユーザが、第１及び第２の秘密鍵に関連付けられる属性の組合せを用いて署名するため、第１の秘密鍵及び第２の秘密鍵の組合せに基づきメッセージに署名することができることを意味する。
【００６５】
中央認証局は、既知のスキームをより有益でないものにし、実現をより困難にする。以下に、分散されたマルチ認証局の属性ベースの署名スキームが、説明される。これは、信頼された中央認証局なしに作動することができ、共謀からも解放されたままである。
【００６６】
図３は、マルチ認証局属性ベースのデジタル署名システムのブロック図を示す。このシステムは、概略的に、ブロック３０１、３０２、３０３として示される複数の属性認証局を有する。しかしながら、属性の数は任意の数とすることができる。状況に応じて、３つの属性認証局より多くすることも少なくすることもできる。属性認証局３０１、３０２、３０３は、属性のセットに関連付けられる暗号鍵をユーザに独立して発行するよう構成される。例えば、属性認証局３０１は、暗号鍵３１１を発行し、属性認証局３０２は、暗号鍵３１２を発行し、属性認証局３０３は、暗号鍵３１３を発行する。属性認証局３０１、３０２、３０３は、互いの間で又は中央認証局と、秘密情報を交換する必要はない。属性認証局３０１、３０２、３０３は、それらの自身の秘密鍵を生成するよう構成されることができる。これは、例えば暗号アルゴリズムに現れる要素のフォーマット及び／又はサイズといった公開して共有される情報を用いて実行されることができる。暗号鍵３１１、３１２及び３１３は、同じユーザに関するものであるが、それらは異なる属性に関連付けられる。結果的に、ユーザは、異なる認証局３０１、３０２、３０３から複数の暗号鍵３１１、３１２、３１３を得ることができる。システムは更に、署名生成ユニット３０４を有する。通常、システムには、１つ以上の署名生成ユニット３０４が存在することができる。例えば、異なるユーザは、それらの自身の署名生成ユニットを持つことができる。署名生成ユニット３０４は、異なる属性認証局３０１、３０２、３０３から同じユーザに関する異なる属性のセットに関連付けられる暗号鍵３１１、３１２、３１３を受信するよう構成される受信ユニット３０７を有することができる。署名生成ユニット３０４は更に、結合ユニット３０８を有することができる。結合ユニット３０８は、外部ソースから又は署名生成ユニット３０４のストレージ手段からメッセージ３０５を受信するよう構成されることができる。結合ユニットは更に、受信ユニット３０７から暗号鍵３１１、３１２、３１３を受信することができる。結合ユニット３０８は更に、メッセージ３０５に関する暗号署名３０６を生成するため、同じユーザに関する複数の暗号鍵３１１、３１２、３１３を結合するよう構成されることができる。この場合、暗号署名３０６は、複数の暗号鍵３１１、３１２、３１３からの属性に関連付けられる。
【００６７】
複数の属性認証局３０１、３０２、３０３は、共通のオーダーｐの共通のバイリニアグループＧに基づき、暗号鍵３１１、３１２、３１３を生成するよう構成されることができる。署名生成ユニット３０４、特に結合ユニット３０８は、バイリニアグループＧのメンバーであるメッセージに関する署名を生成するよう構成されることができる。結果的に、独立属性認証局３０１、３０２、３０３からの暗号鍵はすべて、同じバイリニアグループＧからのメッセージに関して作動する。更に又は代替的に、複数の属性認証局３０１、３０２、３０３は、共通のハッシュ関数に基づき暗号鍵３１１、３１２、３１３を生成するよう構成されることができる。例えば、ハッシュ関数は、バイリニアグループＧの要素に対してユーザに関する識別子をマッピングするために用いられることができる。
【００６８】
個別のユーザは、単一のユーザ識別子を用いて複数の属性認証局３０１、３０２、３０３にわたり特定されることができる。複数の属性認証局３０１、３０２、３０３は、対応するユーザ識別子に基づきユーザに関する暗号鍵３１１、３１２、３１３を生成するよう構成されることができる。同じユーザ識別子に基づかれる暗号鍵だけが、組み合わされた署名３０６を形成するために結合ユニットにより結合されることができるという態様で、暗号スキームはセットアップされることができる。
【００６９】
署名生成ユニット３０４、特に結合ユニット３０８は、署名３０６の少なくとも一部を形成するため、図１を参照して説明されるように、ユーザ秘密鍵（ＳＫ）を、この場合暗号鍵３１１、３１２、３１３を、無効データ（Ｒ１、Ｒ２、Ｒ３）に結合するよう構成されることができる。しかしながら、鍵無効に関するサポートはないが複数の属性認証局に関するサポートがあるようなシステムを構築することも可能である。鍵無効に関するサポートはあるが、複数の属性認証局に関するサポートがないようなシステムを構築することも可能である。
【００７０】
図３のシステムは、ワークステーションにおいて、例えば分散型コンピュータシステムを用いて、実現されることができる。システムの部分、例えば署名生成ユニット３０４は、医療画像取得装置に組み込まれることができる。
【００７１】
署名生成ユニット３０４及び属性認証局３０１、３０２、３０３の各々は、分離したデバイスにおいて実現されることができる。同じデバイスにおいてこれらの要素のいくつかを結合することも可能である。本書において、例えば、デバイスは、ワークステーション又は携帯型のデバイスとすることができる。
【００７２】
図４は、複数の属性認証局からの属性を用いてメッセージに署名する方法を示す。この方法は、例示を介して、属性のセットに関連付けられる暗号鍵を複数の属性認証局によりユーザに独立して発行するステップ４０１を含む。この方法は更に、署名生成ユニットにより、異なる属性認証局から同じユーザに関する異なる属性のセットに関連付けられる複数の暗号鍵を受信するステップ４０２を含む。この方法は更に、署名生成ユニットにより、メッセージに関する暗号署名を生成するため、同じユーザに関する複数の暗号鍵を結合するステップ４０３を含む。ここで、暗号署名は、複数の暗号鍵からの属性に関連付けられる。この方法は、適切なストレージ媒体に格納される１つ又は複数のコンピュータプログラムにより、少なくとも部分的に実現されることができる。
【００７３】
以下のアルゴリズムは、分散されたマルチ認証局の属性ベースの署名スキームにおいて用いられることができる。これらのアルゴリズムは、単に例示として機能するにすぎない。
【００７４】
１．
0006014585.tif 000065
：このアルゴリズムは、入力として、セキュリティパラメータλを取り、システムに関するグローバルパラメータを返す。このパラメータは、公開である。これらのグローバルパラメータは、例えばハッシュ関数及びバイリニアマップといった情報を有することができる。これらのグローバルパラメータは、他のアルゴリズムにより用いられることができる。セキュリティパラメータλは、例えば属性認証局及び署名生成ユニットのアルゴリズムにおいて使用されるグループのオーダーといった情報を定めることができる。セキュリティパラメータλは、システムにおける最も重要な要素の入力及び／又は出力サイズを規定することができる。例えば、有限循環群、即ちＧ０及びＧ１に関して、それは、それらのオーダーｎ（プライム）とすることができる。ハッシュ関数の場合、グローバルパラメータは、それらの出力のサイズを定めることができる。この情報は、公開であり、公開パラメータ（ＰＫ）の一部であると考えられる。グローバル設定は、すべての認証局において共通とすることができる。認証局は、例えばグループ、ハッシュ関数及びバイリニアマップといったアルゴリズムにおいて使用されるパラメータに同意することができる。
【００７５】
２．
0006014585.tif 000066
：各属性認証局は、入力として、ＧＰを取ることにより自身のセットアップを実行し、自身の公開及びマスター秘密鍵ペアであるＰＫｉ及びＭＫｉを生成する。
【００７６】
３．
0006014585.tif 000067
：鍵生成アルゴリズムは、入力として、属性認証局「ｉ」のマスター秘密鍵ＭＫｉ及び認証局が秘密鍵を発行することができるユーザの属性ωＵを取る。更に、これは、入力として、ユーザの識別子ＩＵを取り、ここで、ＩＵは、マルチ認証局属性ベースの署名システムにおいてユニークである。例えば、ＩＵは、社会保障番号を有する。アルゴリズムの出力は、属性認証局ｉにより発行されるユーザＩＵの属性に関する秘密鍵要素
0006014585.tif 000068
を有する。
【００７７】
４．
0006014585.tif 000069
：署名アルゴリズムは、入力として、属性のセット「ω」に関連付けられるユーザ「Ｕ」の秘密鍵
0006014585.tif 000070
及び署名されるメッセージ「Ｍ」を取る。アルゴリズムの出力は、署名「σ」を有する。本書において、
0006014585.tif 000071
は、異なる属性認証局ｉにより発行される秘密鍵要素を有する。
【００７８】
５．
0006014585.tif 000072
：検証アルゴリズムは、入力として、異なる属性認証局ｉに関して生成される公開鍵ＰＫｉを有する公開パラメータＰＫ＝｛ＰＫｉ｝ｉ及び署名σを取る。検証が成功すれば、それは「Ｙ」を戻し、さもなければ、それは「Ｎ」を戻す。
【００７９】
上述のマルチ認証局の属性ベースの署名スキームにおいて、属性認証局は、互いに秘密情報を共有する必要がない。効率性を改善するため及びスキーム共謀に抵抗するために、いくつかの公開情報だけが共有される。
【００８０】
例示に過ぎないものを用いて、メインアルゴリズムの以下の説明において更なる詳細が与えられる。
【００８１】
１．
0006014585.tif 000073
：セットアップアルゴリズムは、プライムオーダーｐ及びランダム生成器ｇのバイリニアグループＧ０を選択する。それは、バイリニアマップ
0006014585.tif 000074
も選択する。これに加えて、ユーザｕに関する識別子、即ちＩｕをＧ０の要素にマッピングするハッシュ関数
0006014585.tif 000075
の説明が公表される。
【００８２】
２．
0006014585.tif 000076
：属性認証局は、ランダムに
0006014585.tif 000077
を選び、属性のセット
0006014585.tif 000078
に関して、
0006014585.tif 000079
をセットする。
【００８３】
ここで、
0006014585.tif 000080
は、属性認証局ｉが秘密鍵要素を発行することができる属性のセットである点に留意されたい。
【００８４】
公開鍵ＰＫｉ及びマスター秘密鍵ＭＫｉは、以下の要素
0006014585.tif 000081
から成ることができる。
【００８５】
３．
0006014585.tif 000082
：鍵生成アルゴリズムは、認証局ｉが秘密鍵要素を発行するにふさわしい（illegible、eligible?）属性セットωｉに関連付けられるユーザ秘密鍵を出力する。秘密鍵
0006014585.tif 000083
は、以下の要素
0006014585.tif 000084
を有することができる。ここで、ｈ＝Ｈ（Ｉｕ）である。
【００８６】
４．
0006014585.tif 000085
：メッセージ
0006014585.tif 000086
に署名するため、アルゴリズムは、ランダム要素
0006014585.tif 000087
を選択し、以下の要素
0006014585.tif 000088
を有することができる署名σを計算する。ここで、
0006014585.tif 000089
が成り立ち、ωｉは、属性認証局ｉにより管理される属性セットであり、ｎは、属性認証局の総数である。
【００８７】
５．
0006014585.tif 000090
：署名を検証するため、検証者は、
0006014585.tif 000091
が成立するかを検証することができる。ここで、
0006014585.tif 000092
である。もしこれが成立する場合、署名は受け入れられることができる。
【００８８】
本発明は、本発明を実行するよう構成されるコンピュータプログラムに、特に担体上又は内のコンピュータプログラムに延在することを理解されたい。このプログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた中間ソースコード及び中間オブジェクトコードの形式、又は本発明による方法を実現するための使用に適した他の任意の形式とすることができる。斯かるプログラムが、多くの異なる設計上のデザインを持つことができる点も理解されたい。例えば、本発明による方法又はシステムの機能を実現するプログラムコードは、１つ又は複数のサブルーチンに分割されることができる。これらのサブルーチンにおける機能を分散させる多くの異なる態様が当業者には明らかであろう。このサブルーチンは、自己完結的なプログラムを形成するため、１つの実行可能ファイルに一緒に格納されることができる。斯かる実行可能ファイルは、コンピュータ実行可能な命令、例えばプロセッサ命令及び／又はインタプリタ命令（例えばＪａｖａ（登録商標）インタプリタ命令）を有することができる。代替的に、１つ又は複数又は全てのサブルーチンが、少なくとも１つの外部ライブラリファイルに格納されることができ、及び例えば実行時にメインプログラムに静的に又は動的にリンクされることができる。メインプログラムは、少なくとも１つのサブルーチンへの少なくとも１つの呼び出しを含む。サブルーチンは、互いに対する関数呼び出しを有することもできる。コンピュータプログラムに関する実施形態は、記載される方法の少なくとも１つにおける処理ステップの各々に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに再分割されることができ、及び／又は静的に若しくは動的にリンクされることができる１つ又は複数のファイルに格納されることができる。コンピュータプログラムに関する別の実施形態は、本書に記載されるシステム及び／又は製品のうちの少なくとも１つにおける各手段に対応するコンピュータ実行可能な命令を有する。これらの命令は、サブルーチンに再分割されることができ、及び／又は静的に若しくは動的にリンクされることができる１つ又は複数のファイルに格納されることができる。
【００８９】
コンピュータプログラムの担体は、プログラムを実行することができる任意のエンティティ又はデバイスとすることができる。例えば、担体は、ＣＤ−ＲＯＭ又は半導体ＲＯＭといったＲＯＭのようなストレージ媒体、又は例えばフロッピー（登録商標）ディスク又はハードディスクといった磁気記録媒体を含むことができる。更に、担体は、例えば電気又は光学信号といった通信可能担体とすることができる。これは、電気又は光学ケーブルを介して又は無線又は他の手段により搬送されることができる。プログラムが斯かる信号において実現されるとき、担体は、斯かるケーブル又は他のデバイス又は手段により構成されることができる。代替的に、担体は、プログラムが埋め込まれる集積回路とすることができる。この集積回路は、関連する方法を実行するよう構成されるか、又は関連する方法の実行に使用されるよう構成される。
【００９０】
上述された実施形態は本発明を限定するものではなく、説明するものであり、当業者であれば、添付された請求項の範囲から逸脱することなく、多くの代替的な実施形態をデザインすることができることになることに留意されたい。請求項において、括弧内に配置されるいかなる参照符号も請求項を限定するものとして解釈されるべきではない。動詞「有する」及びその共役の使用は、請求項において述べられる要素又はステップ以外の要素又はステップの存在を排除するものではない。ある要素に先行する冠詞「ａ」又は「ａｎ」は、斯かる要素が複数存在することを除外するものではない。本発明は、複数の個別の要素を有するハードウェアを用いて、及び適切にプログラムされたコンピュータを用いて実現されることができる。複数の手段を列挙するデバイスクレームにおいて、複数のこれらの手段がハードウェアの１つの同じアイテムにより実現されることができる。特定の手段が相互に異なる従属項に記載されるという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示すものではない。
【図１】
0006014585.tif 000093
【図２】
0006014585.tif 000094
【図３】
0006014585.tif 000095
【図４】
0006014585.tif 000096