アクセス制御装置及びユーザ端末及びプログラム
【課題】 追跡不能性と計算量の低減とを両立させ、ユビキタス計算環境において、実用的なアクセス制御を可能とすることである。
【解決手段】公開鍵と個人鍵（署名鍵）が一対一に対応する通常の構成による高速な署名方式を利用しつつ、ユーザ・エージェント手段が署名を乱数化する作用を加えることより追跡不能性を実現している。認証の健全性を保証するために、選択メッセージ攻撃に対して偽造不能性を有する一般的な署名方式を採用する。また、ユーザ・エージェント手段によって乱数化された電子署名は、署名の検証式により定義される曲面上を一様に分布することから、署名であるという事実以外の情報を含み得ない。したがって、ユーザの行動について追跡することは不可能となる。
【解決手段】公開鍵と個人鍵（署名鍵）が一対一に対応する通常の構成による高速な署名方式を利用しつつ、ユーザ・エージェント手段が署名を乱数化する作用を加えることより追跡不能性を実現している。認証の健全性を保証するために、選択メッセージ攻撃に対して偽造不能性を有する一般的な署名方式を採用する。また、ユーザ・エージェント手段によって乱数化された電子署名は、署名の検証式により定義される曲面上を一様に分布することから、署名であるという事実以外の情報を含み得ない。したがって、ユーザの行動について追跡することは不可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、近年、発展が著しいユビキタス計算環境におけるシームレスなアクセス環境において、ユーザをシステムによる追跡から保護する追跡を制限したアクセス制御技術に関する。
【背景技術】
【０００２】
従来の技術を３種類説明する。
【０００３】
第１：ＩＣカード
第１番目の従来技術として、住民基本台帳ネットワークや電子マネー等におけるＩＣカードの利用について説明する。
【０００４】
住民基本台帳ネットワークや電子マネーにおいて利用されるＩＣカードは、ＩＳＯ７８１６等の規格によって形状・寸法・通信方法・基本コマンド等が規定されており、マイクロコンピュータと暗号計算のためのコプロセッサと計算及び記録のためのメモリを内蔵したＩＣチップ（以下では、単なるメモリであるＩＣチップと区別するために、スマートチップと呼ぶ）を具備する。
【０００５】
ＩＣカードのアクセス制御
このスマートチップ内のメモリへのアクセスは、マイクロコンピュータによって制御される他、正規の通信を介さない不正なアクセス、例えば、プローブ（針刺し）に対して
も実装によって対抗する。この特性を耐タンパー特性と呼ぶ。
【０００６】
即ち、上記の耐タンパー特性と、マイクロコンピュータ及び暗号計算コプロセッサにより内部で計算を完結する能力とにより、安全な計算環境を提供している。
【０００７】
スマートチップの設計
さて、スマートチップの設計に当たっては、安全性を脅かす最も強力な脅威として、ＩＣカードを保持するユーザ本人を想定している。即ち、ＩＣカードはユーザに帰属するものであるが故に、このユーザがＩＣカードに対して任意に攻撃を行うことが可能であるからである。
【０００８】
電子マネー
これは、電子マネーの例を見れば明瞭に理解できる。即ち、スマートチップ中に記録されている電子マネーのデータを改竄することにより、ユーザは莫大な経済的利益を得ることが期待され、スマートチップに対して攻撃を行う顕著な動機が存在する。住民基本台帳カードのようなアイ・ディー（ＩＤ）カードにおいても、このような動機付けが存在する。
【０００９】
このように、ＩＣカード中のスマートチップは、ＩＣカードの所有者であるユーザから、機密のデータを保護することを目的としている。別の言い方をするならば、スマートチップは、ユーザに所持され、携行されるものの、実体としてはユーザに対抗する装置であると考えることができる。
【００１０】
この事実を、ユーザの立場から考えると、特にプライバシーの観点から、スマートチップは獅子身中の虫、或いは、Ｂｉｇ Ｂｒｏｔｈｅｒ に等しい存在であるといえる。実際、コンビニエンスストア等で電子マネーカードを使用する都度、ユーザのＩＤがネットワークを通じてサーバに送信され、ＩＤを元にユーザの残高情報が参照され、決済の可否が判断される。このＩＤを、店舗情報や購入した品物の情報と共にログとして記録しておけば（実際に、個人情報保護の下に厳重な管理の下記録されている）、ＩＤをタグとしてユーザの行動を追跡することが可能となる。もちろん、そのような行動の記録は厳重に管理され、外部に漏らされることはないようにされている。
【００１１】
住民基本台帳
一方、住民基本台帳カードの基本機能は電子署名であり、電子署名は明示的に検証可能である。したがって、「ユーザが望まない情報が電子署名中に含まれない」という事項は、一見、電子署名を検証することにより確認できるとも考えられる。
【００１２】
しかしながら、この思い込みは実際には正しくないのである。近年の電子署名は、選択メッセージ攻撃に対する証明可能安全性を求めるため、電子署名自体に乱数を含む構成となっている。例えば、Ｓｃｈｎｏｒｒ署名は、（Ｒ；ｓ）という数のペアから構成されるが、Ｒとｓはそれぞれ以下のように計算される。
【００１３】
【数１】
ここで、ｐは十分に大きな素数、ｑは
【数２】
を満足する最小の自然数であり、かつ、素数であるとする。また、ｘはスマートチップに内蔵される個人鍵であり、ＳＨＡは暗号学的一方向ハッシュ関数ＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）であるとする。
【００１４】
正しいスマートチップは、Ｓｃｈｎｏｒｒ 署名（Ｒ；ｓ）を生成するに当たり、一様にランダムにｒを生成するが、不正なスマートチップは、ｒに関して固有の分布によることにより、ユーザが仮に署名を検査したとしても検知されないように、秘密の情報を符号化することが可能となる。
【００１５】
以下、例を挙げてこれを説明する。
【００１６】
例えば、スマートチップが個別の識別子を有しており、異なる識別子のスマートチップは異なる領域からｒをランダムに選ぶとすると、この領域を知っている攻撃者はＲを検査することにより、スマートカードの識別子を知ることが可能となる。
【００１７】
一方、ユーザは（Ｒ；ｓ）を検査しても不正を発見することはできない。これは、ｒの領域が十分に広ければ、特定の領域からｒが選択されていることを検知することが困難だからである。
【００１８】
本発明では、ユーザによるアクセス権限の横流しを防止する目的で、スマートチップのような耐タンパー特性を備えた処理装置を仮定する。即ち、当該処理装置中にアクセス権限を表現するデータを記録することにより、ユーザが当該アクセス権限データのコピーを作成して、他のユーザに横流しする攻撃を防止する。しかしながら、これまでに述べたように、耐タンパー処理装置、即ち、スマートチップの利用は、ユーザの手許においてユーザのプライバシーがユーザに検知されずに漏洩される危険を孕んでおり、プライバシーの保護、又は、追跡の防止の観点からは、この問題の解決は不可避である。
【００１９】
第２：下位通信層レベルにおける追跡
第２の従来技術として、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ） 参照モデルにおける下位通信層、即ち、セッション層、トランスポート層、ネットワーク（ＩＰ） 層、データリンク層における通信を追跡不能とする技術について述べる。
【００２０】
これらの下位通信層では、ＩＰアドレスやＭＡＣアドレス等のアドレスを手がかりにパケットやデータグラムを配達するので、対策を施さない限り、これらのアドレスをユーザの追跡に利用することが可能となる。
【００２１】
下位の通信層において、ユーザを追跡から保護する方法は、その性質によって、理論的追跡不能性とシステム依存追跡不能性のいずれかに分類することが可能である。理論的追跡不能性においては、下位通信層が仮に何らかのアドレスをパケットの配達に利用するとしても、そのアドレスをユーザの追跡に利用できないことが理論的に演繹できるレベルの安全性を指す。以下に述べるように、仮名アドレスを用いる手法と、ブロードキャスト通信を用いる手法が知られている。
【００２２】
一方、システム依存追跡不能性においては、下位通信層は、ユーザの追跡に利用できるアドレスを用いてパケットの配達を行うが、機能としてアドレスを上位のアプリケーションから秘匿するレベルの安全性を指す。即ち、実際の安全性は下位通信層の信頼性に依存する。
【００２３】
さて、上述した仮名アドレスを用いた追跡不能通信とは、ユーザが動的に選択したアドレスを利用することで、追跡不能性を実現しようとする通信方式であり、赤外線通信やスマートカードにおいて実現性がある。
【００２４】
例えば、ＩｒＤＡ （Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）の通信規約であるＩｒＬＡＰ （Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）や、ＮＦＣ （Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ） の通信規約であるＩＳＯ／ＩＥＣ １８０９２ では、アドレスの衝突を回避するメカニズム（ａｄｄｒｅｓｓ ｃｏｌｌｉｓｉｏｎ ａｖｏｉｄａｎｃｅ ｍｅｃｈａｎｉｓｍｓ）を規定している。
【００２５】
ＩｒＤＡは赤外線通信の規格であり、ＮＦＣは、Ｔｙｐｅ Ｃと呼ばれる非接触型ＩＣカードのために開発された通信方式を、１０ｃｍの距離で１００〜４００ｋｂｐｓの伝送速度を提供する近接通信に汎化した規格である。ＩｒＤＡやＮＦＣでは、少数のノード間の通信を想定しており、通信の都度、動的にアドレスを決定しても衝突が発生する確率は小さい。
【００２６】
従って、ワールドワイドで非衝突性を保証するようにアドレスを静的にデバイスに割り当てる方法（ＭＡＣアドレスに適用されている方法）は、オーバーヘッドが大きいだけで効果を得る機会は少ない。逆に、接続の都度、動的にアドレスを生成するようにして、衝突が発生したときにアドレスを変更して衝突を回避する手段を講じる方が効果的である。
【００２７】
Ｔｙｐｅ Ａ、Ｔｙｐｅ Ｂの非接触型ＩＣカードの通信規約であるＩＳＯ／ＩＥＣ １４４４３でも、動的にアドレスを生成して利用する仕様となっている。
【００２８】
このように、赤外線通信、及び、非接触型ＩＣ カード通信では、証明者は自らのアドレスを動的に決定する自由度を有しているので、仮名アドレスを適当なタイミングで更新する（例えば、セッションの更新の都度）ことで、演繹可能な追跡不能性を実現することが可能となる。
【００２９】
動的に仮名アドレスを生成する手法は、衝突回避メカニズムが存在しないＩＰ通信層やデータリンク層にも適用可能できる可能性はある。即ち、ＩＰアドレスとＭＡＣアドレスを動的に生成して、仮名アドレスとして利用するのである。
【００３０】
但し、アドレスの衝突回避メカニズムを伴わないため、ＬＡＮのような大規模なネットワークに適用すると、アドレスが衝突する危険が高まることに注意しなければならない。例えば、仮名アドレスに利用できるＭＡＣアドレスの有効長は３バイトであるので、Ｂｉｒｔｈｄａｙ Ｐｒｏｂｌｅｍの理論から、ｎユーザの間で衝突が発生する確率は約
【数３】
となる。これは、ネットワークに５８１以上のデバイス（ＮＩＣ等）が同時に存在すると、１／１００より大きい危険率で衝突が発生することを意味し、また、危険率を１／１０まで許容しても、許容されるデバイス数は１，８８０程度である。この数値が大きいと考えるか小さいと考えるかは、適用場面に依存するが、衝突が発生することは想定しなければならない。
【００３１】
Ｅｔｈｅｒｎｅｔ（登録商標）のように、アドレスの衝突が発生しても、パケットが喪失することはなく、配達が重複するのみであることが仮定できれば、アプリケーション側で衝突に対応することができる。但し、アドレスが衝突している他のデバイスに宛てたパケットも混在するため、アプリケーションは、下位の通信スタックから渡されるペイロードを検査して、自分宛のペイロードを取捨できる必要がある。
【００３２】
ブロードキャスト通信も、追跡不能性を実現する目的に利用することができる。２５５．２５５．２５５．２５５ はＩＰ アドレスにおけるブロードキャスト・アドレス（ｂｒｏａｄｃａｓｔ ａｄｄｒｅｓｓ）であり、ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ はＭＡＣ アドレスにおけるブロードキャスト・アドレスである。例えば、証明者は、パケットを送信する際、ブロードキャスト・アドレスをパケットのＳｏｕｒｃｅフィールドに指定するものとする。
【００３３】
このようなパケットを受信した検証者は、Ｓｏｕｒｃｅフィールドを含むパケットヘッダを根拠に、送信者を特定することはできないだけではなく、それ以前に受信したパケットとリンクすることもできない。
【００３４】
一方、検証者が返信を行う際には、ブロードキャストでパケットを送信する。ブロードキャストされたパケットから、証明者が自分宛のパケットを選択できるためには、パケットのペイロードにそのための情報が指定されなければならない。加えて、ブロードキャスト通信では検証者は証明者とＴＣＰセッションを構成できないので、本来ならばＴＣＰスタックが提供している通信の信頼性はアプリケーション層でサポートする必要がある。
【００３５】
インターネット・プロキシによりＩＰアドレスを隠蔽したウェブアクセスが可能であることは知られている。また、ＮＡＴ或いはＮＡＴＰをサポートするルータは、プライベートＩＰアドレスとルータのグローバルＩＰアドレスの変換を行う。このように、インターネット・プロキシやある種のルータは、通信において仮名アドレスによる通信を提供している。
【００３６】
しかしながら、実際のユーザの追跡不能性は、プロキシとルータの信頼性に依存している。極端な例では、プロキシはウェブサイトと共謀している可能性もあるし、ルータの管理者がユーザによるアクセスを追跡している可能性もある。このように、インターネット・プロキシやルータを用いた仮名通信は理論的追跡不能性をサポートせず、下位通信層の信頼性に依存するシステム依存追跡不能性をサポートするに留まる。
【００３７】
以上、述べたように、アプリケーション層より下位の通信層では、追跡を防止する技術は一応存在する。しかしながら、サービスへのアクセス制御は、アプリケーション層において要求される機能であり、仮に下位の通信層で追跡不能性を実現したとしても、例えば、アクセスコントロールリスト（ＡＣＬ）のような従来技術を用いてアプリケーション層においてアクセス制御を行う場合には、ユーザの識別と認証を行わなければならず、総体としての追跡不能性が損なわれる。
【００３８】
即ち、アプリケーション層において追跡不能性を提供するアクセス制御技術がのぞまれているのである。
【００３９】
第３：グループ署名
第３の従来の技術として、アプリケーション層で利用可能な、追跡不能認証技術である、グループ署名について説明する。
【００４０】
グループ署名は、以下の特徴を備えた署名方式である。
【００４１】
（１）グループのメンバーはグループを代表して、任意に署名を生成することができる。
【００４２】
（２）グループの公開鍵（グループ公開鍵）にアクセスできる誰でもが署名を検証することが可能であるが、検証により署名者の身許が明らかになることはない。
【００４３】
（３）逆に、グループの管理者（ＴＧＡ）は、署名から署名者を特定することが可能であり、紛争等、必要に応じて署名者の身許を特定する。
【００４４】
オークションにおけるグループ署名
このようなグループ署名は電子オークションや匿名注文システム等に応用がある。例えば、電子オークションでは、以下のような手続きを行い、オークションの参加者のプライバシーを守りつつ、不正な参加者を排除している。
【００４５】
（１）入札者（ｂｉｄｄｅｒ）はオークションの開催者が管理するグループに登録し、グループ署名用の個人鍵（グループ署名鍵）を生成する。
【００４６】
（２）入札者は入札時に入札金額等を記載したデータにグループ署名を施して申し込みを行う。
【００４７】
（３）出品者はグループ署名を検証することにより、入札資格者による申し込みであることを検証できるが、入札者の身許を知ることはできない。
【００４８】
（４）オークション成立後は、開催者は入札の署名から落札者の身許を明らかにし、品物の配送や決済を行う。
【００４９】
さて、グループ署名のスキームは、以下に述べる、準備、加入、署名、検証、及び、開示の各フェーズから構成される。
【００５０】
「準備」のフェーズでは、ＴＧＡはグループの公開鍵ペアを生成する。公開鍵ペアの個人鍵はＴＧＡの鍵として安全に保管する。
【００５１】
「加入」のフェーズでは、ユーザは、ＴＧＡと協力してグループ署名鍵を生成し、グループに参加する。
【００５２】
「署名」のフェーズでは、グループのメンバーは、グループ公開鍵と自身のグループ署名鍵を用いて、任意のメッセージに署名する。
【００５３】
「検証」のフェーズでは、検証者は、メンバーが生成した署名を検証するために、グループ公開鍵のみを用いる。
【００５４】
「開示」のフェーズでは、ＴＧＡは、グループ公開鍵ペアを用いて、署名を生成したメンバーを特定する。
【００５５】
Ａｔｅｎｉｅｓｅ、Ｃａｍｅｎｉｓｃｈ、Ｊｏｙｅ とＴｓｕｄｉｋ 等が２００２年に発表したグループ署名方式は、証明可能な安全性を有するグループ署名方式としては従前の方式に比較して効率的であったが、それでも署名の生成や検証に必要な計算量が大きいという問題があった。このため、Ａｔｅｎｉｅｓｅ 等による提案以降、グループ署名の計算量を軽減し、計算効率を向上させようとする試みがなされており、古川・今井が発表しているグループ署名の方式等、複数の方式が現時点で最も効率がよいと評価されている（下記非特許文献１）。
【００５６】
しかしながら、古川・今井のグループ署名方式（非特許文献１）でも、アクセス頻度が飛躍的に増大するユビキタス計算環境に適用するには、まだ計算量が大きい。実際、Ｐｅｎｔｉｕｍ（登録商標）４ ３．２ＧＨｚを搭載したＰＣを用いて、１９２ビット長標数の素体上に定義された楕円曲線のスカラー倍演算の実行時間を実測し、その計測値をもとに古川・今井のグループ署名方式の実行時間を推定したところ、一回の署名の生成と検証に要する合計時間は約６００ミリ秒と計算された。現実の適用においては、ユーザが携帯する端末或いはデバイスは計算能力が制限されるので、上記の数倍程度は時間がかかることが予想される。即ち、実際の実行時間は少なくとも２秒程度にはなるものと想定される。
【００５７】
これまで記したように、アプリケーション層における追跡不能認証の従来技術であるグループ署名では、ユビキタス計算環境への適用では十分な効率を有しないという問題があることが理解されよう。
【００５８】
更に、グループ署名の第二の問題点として、グループ管理者は常に生成された電子署名から署名者を特定することができる絶対的な特権者として機能することがある。この特権者の存在は、多くのアクセスがシームレス、かつ、透過的に行われるユビキタス計算環境においては、結局、ユーザの行動を監視する絶対的な検閲者が存在することを意味しているに他ならず、望ましい環境とは言い難い。
【００５９】
ユビキタス計算環境においてシステムによる追跡・検閲を回避するためには、アクセスの追跡不能性或いは匿名性が保証されるべきであるが、機密性を有していたり、管理が必要であるような資源へのアクセス、また、保安上の理由により監視が必要なサービスへのアクセスにおいては、ユーザの匿名性を最優先にさせるわけにはいかない場合が存在する。
【００６０】
一方、システム側の要求を優先させると、検閲が正当化されてしまう。
【００６１】
この問題に対する最適な解決は、以下のような要件を満たすことによって達成できると考えられる。
【００６２】
第一に重要な要件は、情報の開示は必ずユーザの明示的な同意に基づくとし、かつ、情報の開示はサービスや資源へのアクセスと引き換えで行われるという要件である。
【００６３】
第二に重要な要件は、開示される情報が、ユーザが同意した範囲に限られるという要件である。
【００６４】
従来のグループ署名は、上記のユビキタス計算環境におけるプライバシー保護と合理的な追跡のバランスに対する要件を満足しないという問題がある。
【００６５】
先行特許文献
下記特許文献１には、匿名認証の認証データを画像データを用いて送受信する手法が記載されている。この記載によれば、認証データを送受信できる匿名通信路を、簡易に実現可能であるとされている。
【００６６】
また、下記特許文献２には、簡易な構成で匿名認証を実現できる装置が開示されている。
【００６７】
また、下記特許文献３には、タンパー装置が取り付けられた利用者端末の利用が開示されている。
【００６８】
また、下記特許文献４には、個人の生体的特徴が外部に洩れるのを防止するために、タンパー手段を設けた携帯端末が開示されている。
【００６９】
また、下記特許文献５には、電子証明書の盗難を防止し、組織として電子署名した電子データであることを保証できる電子署名システムが記載されている。
【００７０】
また、下記非特許文献１には、匿名性を有するグループ署名の手法が開示されている。
【００７１】
【特許文献１】特開２００６−２９３４７２号公報
【特許文献２】特開２００５−５７７８号公報
【特許文献３】特開２００４−３２０５６２号公報
【特許文献４】特開２００２−３５８４８８号公報
【特許文献５】特開２００３−３０４２４３号公報
【非特許文献１】J. Furukawa and H. Imai. An efficient group signature scheme from bilinear maps. In ACISP 2005, pages 455 467, 2005.
【発明の開示】
【発明が解決しようとする課題】
【００７２】
本発明が解決しようとする第１の課題は、追跡不能性と計算量の低減とを両立させ、ユビキタス計算環境において、実用的なアクセス制御を可能とすることである。
【００７３】
また、本発明が解決しようとする第２の課題は、機密管理や保安等の合理的な目的のためにシステムがユーザの追跡情報を収集する機能を、ユーザによる明示的な同意が存在し、かつ、ユーザが開示に同意した範囲の情報に限って行うように実現することである。
【課題を解決するための手段】
【００７４】
本発明においては、第１の課題を解決し、追跡不能性と実用的な計算量を両立させるために、グループ署名のように単一の公開鍵に対して複数の個人鍵（署名鍵）を対応させる構成により追跡不能性を実現するのではなく、公開鍵と個人鍵（署名鍵）が一対一に対応する通常の構成による高速な署名方式を利用し、耐タンパー特性を有するプロバイダ・エージェント手段がユーザの干渉を受けることなく署名を生成することで、認証の正確性と高速化を両立させる一方、ユーザ・エージェント手段が署名を乱数化する作用を加えることより追跡不能性を実現している点を特徴とする。
【００７５】
認証の健全性を保証するために、本発明で利用する署名方式として、選択メッセージ攻撃に対して偽造不能性を有する署名方式を採用している。上記性質を満足する署名方式は従来から広く知られているので、それらを利用すればよい。例えば、ＲＳＡ−ＰＳＳやＤＳＡ等、近年広く用いられている署名方式がある。
【００７６】
ユーザ・エージェント手段によって乱数化された電子署名は、署名の検証式により定義される曲面上で常に同じ分布で存在することから、署名であるという事実以外の情報を含み得ない。
【００７７】
また、第２の課題を解決するために、本発明では、検証手段が情報の開示を求めた場合において、ユーザ・エージェント手段がユーザの意図が反映するようにその可否を判断する。例えば、ユーザ・エージェント手段は、ユーザインタフェースを介してユーザに可否の判断を求める、ユーザが事前に記述した設定ファイルの記載に従って可否の判断を行う等の機能を有する。追跡情報の開示を拒否する場合には、ユーザ・エージェント手段は、単に通信を遮断する、或いは、プロバイダ・エージェント手段による電子署名を前述のように乱数化し、追跡情報を含むいかなる情報も含まないように変換してから検証手段に出力する等の手段をとる。
【００７８】
また、ユーザ・エージェント装置が追跡情報の開示を許諾した場合でも、プロバイダ・エージェント装置が出力する署名中にユーザ・エージェント装置が入力する追跡情報の暗号化以外のデータが含まれないことを、ユーザ・エージェント装置が検証した後、出力を乱数化する。この結果、この場合においても追跡不能性を実現している。このように、本発明においては、計算量の軽減と追跡不能性とを両立させつつ、上述した第２の課題を解決している。
【００７９】
以下、本発明を具体的に述べれば、以下の通りとなる。
【００８０】
（１）まず、本発明は、上記課題を解決するために、ユーザによるサービスや資源へのアクセスを制御するアクセス制御装置において、アクセス権限の認証のために、電子署名の検証処理を実行する検証手段と、耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、前記検証手段に出力するユーザ・エージェント手段と、を含み、前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするアクセス制御装置である。
【００８１】
（２）また、本発明は、上記課題を解決するために、アクセス権限の認証のために、電子署名の検証処理を実行する外部の検証手段と、所定の通信を行い、所定のサービスに対するアクセス権限の認証を得るユーザ端末において、耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、外部の前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、外部の前記検証手段に出力するユーザ・エージェント手段と、を含み、外部の前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするユーザ端末である。
【００８２】
（３）また、本発明は、コンピュータを、上記（１）又は（２）記載のユーザエージェント手段として動作させるプログラムにおいて、前記コンピュータに、前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介する手順と、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からのデータを乱数化する手順と、前記乱数化したデータを、前記検証手段に出力する手順と、を実行させることを特徴とするプログラムである。
【００８３】
（４）また、本発明は、前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする（１）に記載のアクセス制御装置。
【００８４】
（５）また、本発明は、前記ユーザ・エージェント手段と前記プロバイダ・エージェント手段とが、前記ユーザが所持する同一のユーザ端末中に具備されることを特徴とする（１）に記載のアクセス制御装置である。
【００８５】
（６）また、本発明は、前記ユーザ・エージェント手段は、ユーザがダウンロード可能なプログラムであることを特徴とする（５）に記載のアクセス制御装置である。
【００８６】
（７）また、本発明は、前記プロバイダ・エージェント手段は、ユーザ端末中に装着されるIC チップであることを特徴とする（５）に記載のアクセス制御装置である。
【００８７】
（８）また、本発明は、前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成されることを特徴とする（５）に記載のアクセス制御装置である。
【００８８】
（９）また、本発明は、前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着されるIC チップであることを特徴とする（５）に記載のアクセス制御装置である
（１０）また、本発明は、前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成され、前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着される耐タンパー処理装置であることを特徴とする（５）に記載のアクセス制御装置である。
【００８９】
（１１）また、本発明は、前記検証手段が所定のシグナルを送信して前記ユーザの追跡情報の開示を求めた場合、 前記ユーザ・エージェント手段は、前記シグナルを受信して情報の開示の可否を判断し、情報開示を許可する場合に限り開示するべき情報を前記プロバイダ・エージェント手段に入力し、前記プロバイダ・エージェント手段は、入力された前記開示情報を特権秘密鍵を保有する者のみが復号できるように暗号化して、電子署名とともに出力し、前記ユーザ・エージェント手段は、前記プロバイダ・エージェント手段による暗号化が前記開示情報以外を含んでいないことを検査し、前記開示情報以外の情報が暗号化されている場合には通信を遮断し、前記開示情報のみが暗号化されている場合には、前記追跡情報が含まれ、かつ、署名の検証式を満たすという特性を除いて、常に同一の分布を取るように前記プロバイダ・エージェント手段の出力を乱数化して前記検証手段に出力することを特徴とする（８）から（１０）に記載のいずれかのアクセス制御装置である。
【００９０】
ここで、特権秘密鍵とは、追跡情報の暗号を復号するための鍵をいう。後述する実施の形態では、公開鍵ペアの個人鍵、すなわちアクセスＩＤと秘密鍵との算術和に等しい例を示しているが、発明としては、必ずしも同一である必要はない。
【００９１】
（１２）また、本発明は、上記（１１）に記載のアクセス制御装置において、情報の開示の可否をユーザから入力するユーザインタフェース、を備え、前記ユーザ・エージェント手段は、前記ユーザが該ユーザインタフェースを介して入力した指示に従って、情報の開示の可否を判断することを特徴とするアクセス制御装置である。
【００９２】
（１３）また、本発明は、上記（４）に記載のアクセス制御装置において、前記ユーザが内容を指定する情報の開示の可否の判断の基準となる設定ファイルを格納した記憶手段、を備え、前記ユーザ・エージェント手段は、前記記憶手段中の前記設定ファイルの記載に基づき、情報の開示の可否を判断することを特徴とするアクセス制御装置である。
【００９３】
（１４）また、本発明は、ユーザ・エージェント手段は、前記設定ファイル中の記載に基づき、サービス毎に情報の開示の可否を判断することを特徴とする（１３）に記載のアクセス制御装置。
【００９４】
（１５）また、本発明は、サービス毎に定まる一対の公開鍵ペアに対し、前記検証手段は、前記プロバイダ・エージェント手段が生成する電子署名の検証に前記公開鍵ペアのうち公開鍵を利用し、前記プロバイダ・エージェント手段は電子署名の生成に安全に保持する秘密鍵を利用し、 更に、該秘密鍵は前記公開鍵ペアの個人鍵の一部であって、かつ、前記プロバイダ・エージェント手段毎に一意であることにより、特権秘密鍵を保有しない者は二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とする（１）〜（１１）のいずれか１項に記載のアクセス制御装置である。
【００９５】
（１６）また、本発明は、（１）〜（１４）のいずれか１項に記載のアクセス制御装置において、前記検証手段は、サービス毎に定まる一対の公開鍵ペア中の公開鍵を利用して、前記プロバイダ・エージェント手段が生成する電子署名の検証を行い、前記プロバイダ・エージェント手段は、前記公開鍵ペア中の個人鍵の一部である秘密鍵であって、前記プロバイダ・エージェント手段毎に一意に定められた前記秘密鍵を用いて、電子署名の生成を行い、前記特権秘密鍵を保有しない者は所定の二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、前記特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とするアクセス制御装置である。
【００９６】
なお、前記公開鍵ペア中の公開鍵とは、いわば権限の検証鍵である。この鍵は、権限検証者によって用いられ、ユーザに所定のサービスを受ける権限があるかどうか確認に用いられる。
【００９７】
また、プロバイダエージェント手段が利用する秘密鍵は、前記公開鍵ペアにおいて、検証の目的に使用される公開鍵とペアをなす個人鍵の一部分であり、後述する実施の形態において、アクセスＩＤとの和が前記個人鍵となる成分が、好ましい一例に相当する。
【００９８】
また、個人鍵と特権秘密鍵とは同一であってもよい。
【００９９】
（１７）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術和に分解した際の、一方であることを特徴とするアクセス制御装置である。
【０１００】
（１８）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術積に分解した際の、一方であることを特徴とするアクセス制御装置である。
【０１０１】
（１９）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を所定の算術演算によって二つの成分に分解した一方であることを特徴とするアクセス制御装置である。
【０１０２】
（２０）また、本発明は、（１７）〜（１９）のいずれか１項に記載のアクセス制御装置において、前記ユーザエージェント手段は、アクセスＩＤとして、前記個人鍵を分解した他方のデータが供給され、前記ユーザエージェント手段は、そのアクセスＩＤを乱数化して前記検証手段に送信することを特徴とするアクセス制御装置である。
【０１０３】
ここで、アクセスＩＤとは、アクセス識別子とも呼ばれる。
【０１０４】
（２１）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵を補完して前記公開鍵ペアの個人鍵を構成する補完部分を、アクセス識別子として前記ユーザ・エージェント手段が保持し、前記ユーザ・エージェント手段は、前記アクセス識別子を用いて前記プロバイダ・エージェント手段の出力を乱数化することを特徴とする上記（１５）〜（２０）のいずれか１項に記載のアクセス制御装置である。
【０１０５】
（２２）また、本発明は、アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とする発行手段、を含み、前記発行手段は、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする（２１）に記載のアクセス制御装置である。
【０１０６】
（２３）また、本発明は、（１）〜（２２）のいずれかに記載のアクセス制御装置に対して、サービス権限の発行を行う発行装置において、アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とし、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする権限発行装置である。
【０１０７】
（２４）また、本発明は、前記ユーザ・エージェント手段が前記プロバイダ・エージェント手段に入力する前記開示情報が、前記アクセス識別子、または、前記アクセス識別子を計算するのに十分な情報であることを特徴とする（１５）〜（２０）のいずれかに記載のアクセス制御装置である。
【０１０８】
（２５）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との和が前記公開鍵ペアの個人鍵と一致することを特徴とする（２１）に記載のアクセス制御装置である。
【０１０９】
（２６）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との積が前記公開鍵ペアの個人鍵と一致することを特徴とする（２１）に記載のアクセス制御装置である。
【０１１０】
（２７）また、本発明は、前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする（２）のユーザ端末である。
【０１１１】
（２８）また、本発明は、前記乱数化手順における乱数化した出力が、一様な分布であることを特徴とする（３）のプログラムである。
（２９）また、本発明は、前記ユーザ・エージェント手段は、ユーザが保持する通信機能を有するユーザ端末上に実装され、前記プロバイダ・エージェントは通信機能を有し、ユーザが保持する別のデバイスとして実装され、両者が互いに通信することで前記機能を実現することを特徴とする（１）のアクセス制御装置である。
【発明の効果】
【０１１２】
以上述べたように、第１の課題に対する本発明の効果に関しては、本発明では、プロバイダ・エージェント手段とユーザ・エージェント手段が協力して作成する署名データの分布を所定の曲面上で一様に分布させる工夫により、追跡不能性を実現している。
【０１１３】
また、実施の形態で述べるように、署名の生成及び検証における計算量が従来の技術に比べて減少しているので、より迅速な処理を行うことが可能である。
【０１１４】
また、第２の課題に対する本発明の効果に関しては、本発明では、ユーザ・エージェント手段はユーザによる直接・間接の指示に基づいて、情報の開示を実施するのみならず、開示するべき情報もユーザ・エージェント手段が指定する。したがって、実際のインプリメントにおいては、ユーザ・エージェント手段は、ユーザが信頼するベンダから取得するソフトウェア、又は、所定のハードウェアで構成されている。その結果、その作用は完全に公開検証が可能であるという性質から、常にユーザの同意に基づいた情報の開示を実現している。
【発明を実施するための最良の形態】
【０１１５】
以下、図面を用いて、発明の実施の形態を説明する。
【０１１６】
図１において、ユーザ端末１０としては、移動体通信端末（携帯電話）、携帯型計算機（ＰＤＡ等）、その他の専用端末（アクティブバッジ等）を想定し、環境からサービスの提供を受ける際に、ユーザが常に身に着けて携行するものと想定する。
【０１１７】
なお、「計算機」と「コンピュータ」とは同様の意味である。
【０１１８】
また、プロバイダ・エージェント手段２００は、いわゆる耐タンパー特性を有する装置である。ここで、耐タンパー特性とは、プロバイダ・エージェント手段２００が、その内部に保持されるデータやプログラム、及び、その内部で実行される計算処理が、外部から観察・干渉されない性質を言う。
【０１１９】
近年、交通機関の定期券や電子マネーに利用されている高セキュリティのＩＣチップは、価格、大きさ、使い易さ、安全性の観点から、将来性が有望視される耐タンパーＨ／Ｗである。
【０１２０】
また、ユーザ端末１０が移動体通信端末や携帯型計算機の場合には、プロバイダ・エージェント手段２００は、ＵＩＭ／ＳＩＭのように、外部から装着する実装が考えられる一方、アクティブバッジのように、プロバイダ・エージェント手段２００がユーザ端末１０と一体化している実装を想定することもできる。
【０１２１】
図１では、ユーザ端末１０は移動体通信端末や携帯型計算機であるとし、プロバイダ・エージェント手段２００は外部から装着され、ユーザ端末１０内の手段と外部装置インタフェース１４を介して通信する。
【０１２２】
ユーザ・エージェント手段３００は、ユーザ端末１０にインストールされるソフトウェア（プログラム）等で構成することが好ましい。また、外部装置インタフェース１４を介したプロバイダ・エージェント手段２００との通信は、必ず、ユーザ・エージェント手段３００を経由する。また例えば、ユーザ・エージェント手段３００はプロバイダ・エージェント手段２００のドライバプログラムを含む構成とすることも好適である。
【０１２３】
さらにそれに加えて、ユーザ端末１０は、ユーザ・エージェント手段３００と検証手段１００との間の通信機能を提供する通信手段１３と、情報の開示に関するユーザ・エージェント手段からの問い合わせをユーザが認識できるように表示する表示手段１２と、前記問い合わせに対してユーザが情報の開示の可否を指示する入力手段１１と、を含む。
【０１２４】
例えば、通信手段１３はＥｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ等の通信機能を提供する通信カードから構成することが好ましい。また、表示手段１２は液晶ディスプレイ等で構成することが好ましい。また、入力手段１１はタッチパネル、操作ボタン、キーボード等で構成することが好ましい。
【０１２５】
なお、検証手段と、ユーザ・エージェント手段と、プロバイダ・エージェント手段と、を含むシステムを、「アクセス制御装置」と呼ぶ。請求の範囲におけるアクセス制御装置も同様の意味である。
【０１２６】
図２は、検証手段１００の構成を示す。検証手段１００は、環境側に存在する計算機（コンピュータ）であり、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）等の汎用ＯＳを備える汎用のＰＣ、組み込みＯＳを備える専用機器のいずれで実現されてもよい。
【０１２７】
検証手段１００は、Ｅｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ等である通信媒体２０を介して、ユーザ端末１０内のユーザ・エージェント手段３００と通信を行うが、その為に通信手段１０１を内蔵する。
【０１２８】
ユーザ・エージェント手段３００との通信は、相互接続性を得るために共通の方式に従って符号化されたメッセージを介して実行される。メッセージ解析手段１１０は、符号化されたメッセージを復号して検証処理に必要なデータを取り出す機能を提供し、メッセージ生成手段１１１は、計算処理の結果をメッセージに符号化する機能を提供する。
【０１２９】
更に、検証手段１００は、メモリ等の記憶媒体として実現される公開鍵保持手段１５０、チャレンジ保持手段１４０、及び、乱数化アクセスＩＤ保持手段１２０を具備し、計算処理に必要な各種データを保持する。
【０１３０】
また、プロバイダ・エージェント手段２００が生成する署名の検証に関わる処理を実行するチャレンジ生成手段１３１、並びに、レスポンス検証手段１４１は、ソフトウェア（プログラム）とそれを実行するコンピュータとから構成することが一般的に好適である。また、擬似乱数列を生成する乱数生成手段１３０は、ソフトウェア（プログラム）とそれを実行するコンピュータで実現しても良いし、組み込みハードウェアで構成することも好ましい。
【０１３１】
検証手段１００は、一般的には環境に埋め込まれたセンサー中の組み込みプログラム（Firmware等）、または、センサーに接続した計算機中のプログラム（およびそれを実行する計算機）である。一つの形態としては、携帯端末にインストールされたプログラム（例えば音楽再生プログラム）であってもよい。
【０１３２】
図３は、ホスト機器（移動体通信端末、携帯型計算機）に組み込む外部機器を想定して、プロバイダ・エージェント手段２００を説明する。
【０１３３】
ユーザ・エージェント手段３００との通信は、プロバイダ・エージェント手段２００を実装するＩＣチップ等の外部機器に内蔵されたホスト機器インタフェース２０１を介して実行される。
【０１３４】
また、ユーザ・エージェント手段３００・検証手段１００間の通信の場合と同様に、相互接続性を確立することを目的として、ユーザ・エージェント手段３００・プロバイダ・エージェント手段２００間で交換されるデータは、予め規定された方式に従って、メッセージに符号化される。ユーザ・エージェント手段３００から受信したメッセージを復号してデータを取り出す機能はメッセージ解析手段２１０により、また、ユーザ・エージェント手段３００へ送信するデータを符号化してメッセージを組み立てる機能はメッセージ生成手段２１１により提供される。
【０１３５】
更に、プロバイダ・エージェント手段２００は、メモリ等の記憶媒体として実現される秘密鍵保持手段２２０、チャレンジ保持手段２３０、アクセスＩＤ差分保持手段２４０、署名パラメータ差分保持手段２５０、及び、署名パラメータ保持手段２６２を具備し、計算処理に必要なデータを保持する。また、署名の生成に関わる手段として、署名パラメータ生成手段２６０、レスポンス生成手段２７０、及び、乱数生成手段２６１を含む。署名パラメータ生成手段２６０及びレスポンス生成手段２７０は、ソフトウェアプログラムとして実現することが一般的であり、擬似乱数列を生成する乱数生成手段２６１は、ソフトウェアプログラム、組み込みハードウェア、いずれの手段でも現実的に実現である。
【０１３６】
図４は、ユーザ・エージェント手段３００の構成図である。
【０１３７】
ユーザ・エージェント手段３００は、不正なプロバイダ・エージェント手段２００がユーザの追跡に寄与する情報を外部に漏洩することを防止することを目的とし、ユーザが自由に選択可能でること、また、プロバイダ・エージェント手段２００とは独立に自由に交換可能であることが重要である。
【０１３８】
このような要件を満足するには、例えば、ユーザ・エージェント手段３００をユーザ端末１０にユーザが自由にインストールするソフトウェア（プログラム）で実現することが好適である。
【０１３９】
又は、プロバイダ・エージェント手段２００をユーザ端末１０に自由に装着する外部機器とする実装が考えられる。
【０１４０】
ここでは、図４に示しているように、ユーザ端末１０を、外部からソフトウェアのインストールが可能なホスト機器（移動体通信端末や携帯型計算機）であり、ユーザ・エージェント手段３００はユーザがインストールするソフトウェア（プログラム）で実現されているものとして説明を行う。
【０１４１】
まず、ユーザ・エージェント手段３００と、プロバイダ・エージェント手段２００と、の間の通信は、ユーザ端末１０が具備する外部装置インタフェース１４を介して行われる。また、ユーザ・エージェント手段３００と、検証手段１００との通信も、同様にユーザ端末１０が具備する通信手段１３を介して行われるが、先述したように、これらの通信において交換されるデータは、相互接続性を確立するために定められた方法で符号化されたメッセージにより運搬される。
【０１４２】
このようにメッセージを符号化し、復号する動作は、メッセージ生成手段３１０と３１３、及び、メッセージ解析手段３１１と３１２によって実行される。ユーザ・エージェント手段３００は、検証手段１００から追跡情報開示の要求をシグナルとして受信すると、秘密鍵保持手段３２０によって開示の可否を判断する。図４に示す構成では、秘密鍵保持手段３２０は、ユーザ端末１０が具備する表示手段１２を利用して、ユーザに情報開示の要求をユーザが認識できる形式で表示し、入力手段１１を利用して、ユーザの判断を取得する。
【０１４３】
更に、ユーザ・エージェント手段３００は、アクセスＩＤ保持手段３３０と、チャレンジ保持手段３４０と、アクセスＩＤ差分保持手段３５１と、署名パラメータ保持手段３６０と、及び、署名パラメータ差分保持手段３６２と、を具備し、計算処理に必要なデータを保持する。これら保持手段は、メモリ等の記憶媒体を用いて構成することが好ましい。
【０１４４】
また、
・プロバイダ・エージェント手段２００が生成する署名の検証、
・検証手段１００への出力とするための乱数化、
を実行するために、ユーザ・エージェント手段３００は、アクセスＩＤ乱数化手段３５０と、署名パラメータ差分生成手段３６１と、レスポンス検証手段３７０と、レスポンス変換手段３８０と、さらに、乱数生成手段３９０と、を具備する。
【０１４５】
具体的な動作例
以下では、検証手段１００が情報開示を要求しないケースと、要求するケースとに分けて、この実施の形態における作用を述べる。
【０１４６】
まず、以下の説明で用いる記号を説明する。まず、
【数４】
は Dicesion Diffie-Hellman 問題の解決が困難であるような加法群とする。例えば、安全に生成された楕円曲線の部分群はこの条件を満足する。また、
【数５】
を
【数６】
の生成点（生成元）であるとし、
【数７】
の位数をｎと表す。
【０１４７】
【数８】
の元
【数９】
を署名検証のための公開鍵とし、σを対応する個人鍵であるとする。即ち、以下の関係が成り立つ。
【数１０】
更に、σは、以下の関係（数１３）が成り立つように、
【数１１】
と
【数１２】
とに分解される。
【０１４８】
【数１３】
ここで、
【数１４】
及び
【数１５】
は、それぞれ、公開鍵保持手段１５０、アクセスＩＤ保持手段３３０、及び、秘密鍵保持手段２２０に保持される。
【０１４９】
ユーザが環境に対して所定のサービスへのアクセスを要求すると、検証手段１００は認証を開始するメッセージ（シグナル）をユーザ・エージェント手段３００に送付するが、メッセージは復号された後、情報開示判定手段３２０に送付される。情報開示判定手段３２０は、検証手段１００がユーザの追跡情報の開示を要求しているか否かを判定する。追跡情報の開示が要求されていない場合、アクセスＩＤ乱数化手段３５０は、乱数生成手段３９０から乱数ρを得て、
【数１６】
を乱数化し、
【数１７】
を以下のように計算する。
【０１５０】
【数１８】
ここで、乱数ρはアクセスＩＤ差分保持手段３５１に保持され、
【数１９】
はメッセージに符号化されて、検証手段１００に送付される。
【０１５１】
検証手段１００は、メッセージから復号された
【数２０】
を乱数化アクセスＩＤ保持手段１２０に保持した後、チャレンジ生成手段１３１によりチャレンジｃを生成する。この際、チャレンジ生成手段１３１は、乱数生成手段１３０を利用する。生成されたチャレンジｃは、チャレンジ保持手段１４０に保持されるとともに、メッセージに符号化されてユーザ・エージェント手段３００に送付される。
【０１５２】
チャレンジｃを受信したユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００に対して署名パラメータＷの出力を求める。プロバイダ・エージェント手段２００中の署名パラメータ生成手段２６０は、乱数生成手段２６１から乱数
【数２１】
を取得し、以下の式により署名パラメータＷを計算する。
【０１５３】
【数２２】
次いで、乱数
【数２３】
を署名パラメータ保持手段２６２に保存し、署名パラメータＷをメッセージに符号化して、ユーザ・エージェント手段３００に送付する。ユーザ・エージェント手段３００中の署名パラメータ差分生成手段３６１は、乱数生成手段３９０を利用して乱数
【数２４】
を生成し、署名パラメータ差分保持手段３６２に保持する。更に、ユーザ・エージェント手段３００は、チャレンジ保持手段３４０に保持しているチャレンジｃと、署名パラメータ差分保持手段３６２に保持している乱数
【数２５】
を符号化してメッセージを生成し、このメッセージをプロバイダ・エージェント手段２００に送付する。
【０１５４】
プロバイダ・エージェント手段２００は、メッセージを復号し、チャレンジｃと、乱数
【数２６】
をそれぞれ、チャレンジ保持手段２３０、及び、署名パラメータ差分保持手段２５０に保持する。更に、プロバイダ・エージェント手段２００中のレスポンス生成手段２７０は、署名パラメータ保持手段２６２に保持されている乱数
【数２７】
、
署名パラメータ差分保持手段２５０に保持されている乱数
【数２８】
チャレンジ保持手段２３０に保持されているチャレンジｃ、及び、秘密鍵保持手段２２０に保持されている
【数２９】
から、以下の式により、レスポンスｒを計算する。
【０１５５】
【数３０】
プロバイダ・エージェント手段２００は、計算したレスポンスｒを符号化してメッセージを生成し、このメッセージを、ユーザ・エージェント手段３００に送付する。
【０１５６】
ユーザ・エージェント手段３００中のレスポンス検証手段３７０は、署名パラメータ保持手段３６０に保持されているＷ、署名パラメータ差分保持手段３６２に保持されている
【数３１】
、
チャレンジ保持手段３４０に保持されているｃ、及び、アクセスＩＤ保持手段３３０に保持されている
【数３２】
を用いて、以下の関係を検証し、関係が検証できない場合には処理を中止する。
【０１５７】
【数３３】
上記の関係が検証できた場合は、後述する計算式から、
【数３４】
及び
【数３５】
を計算し、符号化してメッセージを作成し、このメッセージを検証手段１００に送付する。ここで、上記の計算式とは下記の通りである。
【０１５８】
【数３６】
検証手段１００は、メッセージを復号して、
【数３７】
と
【数３８】
とを取得し、以下の関係が成立するか検査する。
【０１５９】
【数３９】
検査の結果、上記関係が成立した場合、検証手段１００は、ユーザがサービスへのアクセス権限を保有しているものと判断し、サービスの提供を許諾するシグナルを出力する。検査の結果、上記関係がが不成立の場合、検証手段１００は、ユーザがサービスへのアクセス権限を保有していないものと判断し、サービスの提供を拒否するシグナルを出力する。
【０１６０】
追跡情報の暗号化
次に、検証手段１００が追跡情報の開示を要求している場合の処理について述べる。
【０１６１】
検証手段１００が、認証の開始を通知するメッセージ（シグナル）をユーザ・エージェント手段３００に送付すると、ユーザ・エージェント手段３００は、同メッセージ（シグナル）を復号後、情報開示判定手段３２０に送付する。情報開示判定手段３２０は、入力手段１１及び表示手段１２を利用して、ユーザから開示の可否の指示を受ける。
【０１６２】
ユーザが、追跡情報の開示を拒否した場合は、情報開示判定手段３２０は認証を中止する判定を行い、実際に、ユーザ・エージェント手段３００は検証手段１００との通信を中止する。
【０１６３】
一方、ユーザが、追跡情報の開示を許諾した場合は、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００にシグナルを送り、プロバイダ・エージェント手段２００から
【数４０】
を満足する数
【数４１】
を受け取る。但し、
【数４２】
は、プロバイダ・エージェント手段２００が生成する乱数である。
【０１６４】
更に、ユーザ・エージェント手段は、乱数
【数４３】
を生成し、更に、
【数４４】
を計算し、
【数４５】
をプロバイダ・エージェント手段２００に送付する。
【０１６５】
プロバイダ・エージェント手段２００は、ρを次の式で暗号化し、数ｅを得る。
【０１６６】
【数４６】
ｅは、
【数４７】
とペアとすることにより、いわゆる、ElGamal 暗号となる。実際、個人鍵σを保持するアクセス権限の発行者、すなわち、
【数４８】
を生成する機関は、下式によりρを計算することができる。
【０１６７】
【数４９】
一方、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００が出力したｅが正しいρの暗号化であることを検証し、プロバイダ・エージェント手段２００が、ユーザ・エージェント手段３００（ユーザ）の意図に反して、ρ、従って、
【数５０】
以外の情報を外部に開示していないことを検証する必要がある。
【０１６８】
しかしながら、ユーザ・エージェント手段２００は、σを知らないので、ｅを復号して、ρと一致するかを検査することはできないという問題がある。
【０１６９】
この問題を解決するために、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００に対して、
【数５１】
を送付する。プロバイダ・エージェント手段２００は、
【数５２】
に対し、後述する式を用いて
【数５３】
を計算して、ユーザ・エージェント手段３００に出力する。この計算式は、
【数５４】
である。
【０１７０】
ユーザ・エージェント手段３００は、関係
【数５５】
が成立するかを検査し、もし成立しない場合は、プロバイダ・エージェント手段２００が不正な出力を行ったと判断して、認証を中止する。
【０１７１】
上記検査が有効である理由は、プロバイダ・エージェント手段２００が正しくｅを計算した場合には、上記関係は必ず成立するのに対し、プロバイダ・エージェント手段２００に対して
【数５６】
が秘密であるという前提の下で、不正なｅが上記関係を満足する確率は１／ｎに等しく、無視しえるほど小さいからである。
【０１７２】
ユーザ・エージェント手段３００は、ｅの検証後、
【数５７】
に加えて、
【数５８】
を検証装置１００に送付する。検証装置１００は個人鍵σにアクセスできないので、
【数５９】
を受け取っても、ρ、即ち、
【数６０】
を復号することはできず、従って、ユーザを追跡することはできない。つまり、アクセス権の発行者であり、サービスのオーナーである機関のみが、
【数６１】
を復号してユーザを追跡することができる点が重要である。
【０１７３】
さて、上記手続きには、まだ、問題がある。即ち、ユーザ・エージェント手段３００が、ｅを偽造して、追跡を免れようとする企てを、検証手段１００が阻止できなければならない。この目的のためには、プロバイダ・エージェント手段２００が、ｅに対して署名を付与すればよい。
【０１７４】
例えば、
【数６２】
を計算し、
【数６３】
を出力するようにすれば、検証手段１００が、関係
【数６４】
が成り立つことを検証できれば、即ち、電子署名
【数６５】
の検証ができれば、ｒ及びｓがプロバイダ・エージェント手段２００によって生成されたものであることを確認することができる。ρ以外の情報が開示されないことを保証するためには、ユーザ・エージェント手段３００が、同じ関係
【数６６】
を検査すればよい。
【０１７５】
【数６７】
には、ユーザ・エージェント手段２００が生成した乱数
【数６８】
が含まれているため、追跡不能であることは、
【数６９】
の場合と同様に示される。
【０１７６】
効果について
以上述べたように、本実施の形態によれば、第１の課題に関し、以下のような効果が得られる。
【０１７７】
すなわち、プロバイダ・エージェント手段とユーザ・エージェント手段が協力して作成する署名データの分布を所定の曲面上で一様に分布させる工夫により、追跡不能性を実現している。
【０１７８】
その一方で、現在最も高速なグループ署名とされる古川・今井（非特許文献１）の方式において、署名の生成及び検証における計算量が楕円曲線上でのスカラー倍演算に換算して４９回であるのに対し、本実施の形態の方式では、情報を開示しないときには同じ換算で７回、情報を開示するときには２１回に相当する計算量を必要とするのみであり、実行効率を改善している。
【０１７９】
また、本実施の形態によれば、第２の課題に関し、以下のような効果が得られる。
【０１８０】
すなわち、本実施の形態によれば、ユーザ・エージェント手段は、ユーザによる直接・間接の指示に基づいて、情報の開示を実施するのみならず、開示するべき情報もユーザ・エージェント手段が指定する。実際のインプリメントにおいては、ユーザ・エージェント手段は、ユーザが信頼するベンダから取得するソフトウェア、又は、所定のハードウェアで構成されている。したがって、その作用は完全に公開検証が可能であるという性質から、ユーザの同意に基づく情報の開示を実現している。
【０１８１】
また、換言すれば、従来のグループ認証では、２者（２プログラム）が強調して処理を行っているのに対して、本実施の形態では、３者（３プログラム）が強調して処理を行った結果、処理速度の向上という効果が得られたものである。
【実施例】
【０１８２】
本実施の形態にかかるアクセス制御システムを実際に運用した場合の例の説明図が図５に示されている。ここでは、例えば、音楽配信サービスの提供を行うシステムについて説明する。
【０１８３】
この図において、権限発行者４００は、例えば音楽配信サービスを提供する音楽配信サイト、又は、そのサイトから委託を受けてアクセス権限（視聴権限）の発行を行う発行機関・発行サーバである。この権限発行者４００は音楽配信サービスに関して、公開鍵４１０と秘密鍵４１２と、を作成し、公開鍵４１０を公開し、秘密鍵４１２は秘密に保持する。
【０１８４】
本実施の形態において特徴的なことは、権限発行者４００が秘密鍵を算術和に分解していることである。そして、一方をアクセスＩＤとしてユーザに提供し、他方をそのユーザのユーザ端末に組み込まれている耐タンパー処理装置４２０に提供する。
【０１８５】
さて、算術和による分解の仕方はいくらでもありえる。したがって、各ユーザ毎に異なる分解を行うことによって、各ユーザ毎に異なるアクセスＩＤを発行することが可能である。ユーザ毎に異なるアクセスＩＤを作成した際に、当然、アクセスＩＤとの和が個人鍵と一致する秘密鍵もユーザ毎に異なる（図５参照）。この秘密鍵は耐タンパー処理装置４２０に秘密裏に送られる。具体的には何らかの暗号通信路を用いて耐タンパー装置４２０に送られ、耐タンパー装置４２０はこれを内部に保持する。暗号通信路はどのようなものでも良いが、一般的な公開鍵暗号を用いた通信路で秘密鍵を送ることが好ましい。例えば、Diffie-Hellman鍵交換アルゴリズムを適用することが好ましい。 なお、耐タンパー処理装置４２０は、上述した例でも示したように、ユーザ機器に装着するＩＣカード、ＳＩＭカードなどのＨ／Ｗで実現されることが好ましい。また、耐タンパー処理装置４２０は、請求の範囲のプロバイダ・エージェント手段の好適な一例に相当する。
【０１８６】
なお、本実施例では、算術和を使用したが、他の種類の演算でもかまわない。
【０１８７】
一方、ユーザ毎に発行されたアクセスＩＤが、ユーザに提供されることによって、ユーザに音楽配信サービス利用の権限が与えられる。具体的には、ユーザはこのアクセスＩＤをユーザ機器内部の記憶手段に格納しておく。このアクセスＩＤは、ユーザがユーザ機器にインストールしたプログラムが利用する。このユーザ機器のコンピュータ（プロセッサ）は、このプログラムを実行することによってユーザ・エージェント手段４３０が構成される（図５参照）。なお、このプログラムそのものを、便宜上ユーザエージェント手段４３０と呼ぶ場合もある。
【０１８８】
ユーザはこのアクセスＩＤを用いて例えば音楽配信サービスを受けることが出来る。ユーザは例えば自分がダウンロードしたプログラム（ユーザエージェント手段４３０）にこのアクセスＩＤを管理させることが可能である。ユーザはユーザ端末（例えば音楽再生機能付き携帯電話）内にこのユーザエージェント手段４３０をインストールし、音楽配信サービスを受けさせるのである。
【０１８９】
グループ署名と本実施例
ここで、従来技術であるグループ署名と、本実施例とを対比して説明する。
【０１９０】
一般的に、電子署名と呼ばれるものは、各ユーザ毎に、公開鍵と、個人鍵（秘密鍵）とを定めている。各個人（例えばＡ氏）は自分しか知らない個人鍵を用いて署名を生成する。他人は公開されているＡ氏の公開鍵を用いて、それがＡ氏の署名であることを確認できる。
【０１９１】
さて、グループ署名の構成説明図が図６に示されている。グループ署名では、各個人が個人鍵を持っているが、公開鍵は１個だけである。各個人は、自分の（例えばＡ氏の）個人鍵をもちいて署名をすることが出来る。そして誰もが、公開されている公開鍵を用いてそれが（グループのメンバーの誰かの）正しい署名であることを確認することは出来るが、グループ中の「誰」の署名かを特定することが出来ない。このような構成によってグループ署名は各個人の匿名性を保証出来る有力な手段として知られている。
【０１９２】
なお、グループ署名では、特権者がおり、この特権者が保有する特権個人鍵を用いて、各署名が誰のものかを特定することも可能である。すなわち、通常は匿名であるが、問題が生じた場合にはその署名者を特定することが出来る仕組みを提供している。この様子が図７に示されている。
【０１９３】
このようにグループ署名は非常に有用な特性を有しているが、計算量が多く、迅速な処理は困難であった。
【０１９４】
これに対して、本実施例では、公開鍵と個人鍵とが１対１に対応している古典的なスキームを用いているので、迅速な処理が可能となっている。すなわち、本実施例は、公開鍵と個人鍵とが１対１に対応している昔からの仕組みを用いつつ（すなわち高速処理を可能としつつ）、ユーザの匿名性を担保しうる点を、特徴とするものである。
【０１９５】
このような特性を実現できたのは、上述したように、秘密鍵４１２を２つの部分（アクセスＩＤ＋残余成分）に分けるという仕組みを採用したからである（図５参照）。これによって、各ユーザ毎にアクセスＩＤを設定することができ、従来のグループ署名のように各個人に秘密鍵を設定するのと同様の効果を得られたものである。
【０１９６】
上述したように、２つの部分に分ける演算はどのような演算でもかまわない。加算でも良いし、また乗算でもかまわない。また、算術演算だけでなく、ビット演算のような論理演算でもかまわない。
【０１９７】
サービス提供の実際
図５に戻って、ユーザがサービスの提供を受ける動作を説明する。
【０１９８】
ユーザはサービスを受けるために、権限検証者４４０に対してアクセスＩＤを呈示する。この際、図５に示すように乱数化してから呈示する。
【０１９９】
その一方、権限検証者４４０は、いわゆるチャレンジ−レスポンス認証するためにチャレンジを発行する。このチャレンジは耐タンパー処理装置４２０に渡され、耐タンパー処理装置はレスポンスを生成する。ユーザエージェント手段４３０は、このレスポンスを乱数化して権限検証者４４０に送る。
【０２００】
ここで、留意すべき点は、アクセスＩＤの乱数化と、レスポンスの乱数化と、は関連のある処理である点である。これによって、権限検証者４４０は、チャレンジレスポンス認証が成功し、アクセスＩＤが正しいＩＤであることを確認することが可能である。この検証には、権限発行者４００が発行した公開鍵４１０が必要であることはもちろんである。実際の処理（計算）についてこれまで述べた通りである。
【０２０１】
権限検証者４４０が、ユーザが正しい権限を有していると判断した場合には、ユーザは、サービス（例えば音楽配信サービス）を受けることが許可される。
【０２０２】
なお、乱数化は、所定の乱数に基づくスクランブル等を意味する。例えば、所定の乱数を発生させ、その乱数をアクセスＩＤに加算し、一方、その同じ乱数を用いて、レスポンスに所定のより複雑な演算を施す等の処理を実行する。これらの乱数化は、ユーザエージェント手段４３０が実行する。
【０２０３】
本実施の形態では、アクセスＩＤの乱数化と、レスポンスの乱数化に同じ乱数を用いたが、一般的に言えば、関連する乱数化であればよい。
【０２０４】
また、図５においては、権限発行者４００は、サービス提供者と同じでも良いし、外部の者でもかまわない。権限発行者４００は、ユーザがそのサービスを受ける権限を発行してもらう（アクセスＩＤを発行してもらう）際にその処理を実行するが、その後のサービス提供には関与していない。サービス提供の許可／不許可は、ユーザ（が使用するユーザ端末（例えば携帯電話、ＰＤＡなど））と、権限検証者４４０との間の通信によって行われる。
【０２０５】
権限検証者４４０がサービスの提供を許可した場合に、サービス提供者がサービスを提供するが、権限検証者４４０がサービス提供者と同一でもよい。同一サーバに、権限検証のためのプログラムと、サービス提供のためのプログラムが、共にインストールされ稼働している構成も不可能ではない。また、権限検証者４４０は、他のサーバ上で稼働するプログラムで実現しても良い。
【０２０６】
さらに、権限検証者４４０を実現するプログラムは、ユーザ端末に組み込まれる構成としても好適である。上述したように、ユーザ端末には、耐タンパー処理装置４２０が組み込まれるが、この耐タンパー装置４２０のハードウェアと権限検証者４４０のソフトウェアとが同一の端末装置に組み込まれていても良い。例えば、権限検証者４４０が端末内の音楽受信プログラムで実現され、ユーザエージェント手段４３０はこの音楽受信プログラムが受信した音楽をＣＤ等に格納するユーザ側のプログラムとして実現されていても良い。
【図面の簡単な説明】
【０２０７】
【図１】本実施の形態におけるユーザ端末の構成図である。
【図２】本実施の形態における検証手段の構成図である。
【図３】本実施の形態におけるプロバイダ・エージェント手段の構成図である。
【図４】本実施の形態におけるユーザ・エージェント手段の構成図である。
【図５】本実施例の構成図である。
【図６】従来のグループ署名の説明図である。
【図７】従来のグループ署名の説明図である。
【符号の説明】
【０２０８】
１０ ユーザ端末
１１ 入力手段
１２ 表示手段
１３ 通信手段
１４ 外部装置インターフェース
２０ 通信媒体
１００ 検証手段
１０１ 通信手段
１１０ メッセージ解析手段
１１１ メッセージ生成手段
１２０ 乱数化アクセスＩＤ保持手段
１３０ 乱数生成手段
１３１ チャレンジ生成手段
１４０ チャレンジ保持手段
１４１ レスポンス検証手段
１５０ 公開鍵保持手段
２００ プロバイダ・エージェント装置
２０１ ホスト機器インターフェース
２１０ メッセージ解析手段
２１１ メッセージ生成手段
２２０ 秘密鍵保持手段
２３０ チャレンジ保持手段
２４０ アクセスＩＤ差分保持手段
２５０ 署名パラメータ差分保持手段
２６０ 署名パラメータ生成手段
２６１ 乱数生成手段
２６２ 署名パラメータ保持手段
２７０ レスポンス生成手段
３００ ユーザ・エージェント手段
３１０、３１３ メッセージ生成手段
３１１、３１２ メッセージ解析手段
３２０ 情報開示判定手段
３３０ アクセスＩＤ保持手段
３４０ チャレンジ保持手段
３５０ アクセスＩＤ乱数化手段
３５１ アクセスＩＤ差分保持手段
３６０ 署名パラメータ保持手段
３６１ 署名パラメータ差分生成手段
３６２ 署名パラメータ差分保持手段
３７０ レスポンス検証手段
３８０ レスポンス変換手段
３９０ 乱数生成手段
４００ 権限発行者
４１０ 公開鍵
４１２ 秘密鍵
４２０ 耐タンパー処理装置
４３０ ユーザエージェント手段
４４０ 権限検証者
【技術分野】
【０００１】
本発明は、近年、発展が著しいユビキタス計算環境におけるシームレスなアクセス環境において、ユーザをシステムによる追跡から保護する追跡を制限したアクセス制御技術に関する。
【背景技術】
【０００２】
従来の技術を３種類説明する。
【０００３】
第１：ＩＣカード
第１番目の従来技術として、住民基本台帳ネットワークや電子マネー等におけるＩＣカードの利用について説明する。
【０００４】
住民基本台帳ネットワークや電子マネーにおいて利用されるＩＣカードは、ＩＳＯ７８１６等の規格によって形状・寸法・通信方法・基本コマンド等が規定されており、マイクロコンピュータと暗号計算のためのコプロセッサと計算及び記録のためのメモリを内蔵したＩＣチップ（以下では、単なるメモリであるＩＣチップと区別するために、スマートチップと呼ぶ）を具備する。
【０００５】
ＩＣカードのアクセス制御
このスマートチップ内のメモリへのアクセスは、マイクロコンピュータによって制御される他、正規の通信を介さない不正なアクセス、例えば、プローブ（針刺し）に対して
も実装によって対抗する。この特性を耐タンパー特性と呼ぶ。
【０００６】
即ち、上記の耐タンパー特性と、マイクロコンピュータ及び暗号計算コプロセッサにより内部で計算を完結する能力とにより、安全な計算環境を提供している。
【０００７】
スマートチップの設計
さて、スマートチップの設計に当たっては、安全性を脅かす最も強力な脅威として、ＩＣカードを保持するユーザ本人を想定している。即ち、ＩＣカードはユーザに帰属するものであるが故に、このユーザがＩＣカードに対して任意に攻撃を行うことが可能であるからである。
【０００８】
電子マネー
これは、電子マネーの例を見れば明瞭に理解できる。即ち、スマートチップ中に記録されている電子マネーのデータを改竄することにより、ユーザは莫大な経済的利益を得ることが期待され、スマートチップに対して攻撃を行う顕著な動機が存在する。住民基本台帳カードのようなアイ・ディー（ＩＤ）カードにおいても、このような動機付けが存在する。
【０００９】
このように、ＩＣカード中のスマートチップは、ＩＣカードの所有者であるユーザから、機密のデータを保護することを目的としている。別の言い方をするならば、スマートチップは、ユーザに所持され、携行されるものの、実体としてはユーザに対抗する装置であると考えることができる。
【００１０】
この事実を、ユーザの立場から考えると、特にプライバシーの観点から、スマートチップは獅子身中の虫、或いは、Ｂｉｇ Ｂｒｏｔｈｅｒ に等しい存在であるといえる。実際、コンビニエンスストア等で電子マネーカードを使用する都度、ユーザのＩＤがネットワークを通じてサーバに送信され、ＩＤを元にユーザの残高情報が参照され、決済の可否が判断される。このＩＤを、店舗情報や購入した品物の情報と共にログとして記録しておけば（実際に、個人情報保護の下に厳重な管理の下記録されている）、ＩＤをタグとしてユーザの行動を追跡することが可能となる。もちろん、そのような行動の記録は厳重に管理され、外部に漏らされることはないようにされている。
【００１１】
住民基本台帳
一方、住民基本台帳カードの基本機能は電子署名であり、電子署名は明示的に検証可能である。したがって、「ユーザが望まない情報が電子署名中に含まれない」という事項は、一見、電子署名を検証することにより確認できるとも考えられる。
【００１２】
しかしながら、この思い込みは実際には正しくないのである。近年の電子署名は、選択メッセージ攻撃に対する証明可能安全性を求めるため、電子署名自体に乱数を含む構成となっている。例えば、Ｓｃｈｎｏｒｒ署名は、（Ｒ；ｓ）という数のペアから構成されるが、Ｒとｓはそれぞれ以下のように計算される。
【００１３】
【数１】
ここで、ｐは十分に大きな素数、ｑは
【数２】
を満足する最小の自然数であり、かつ、素数であるとする。また、ｘはスマートチップに内蔵される個人鍵であり、ＳＨＡは暗号学的一方向ハッシュ関数ＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）であるとする。
【００１４】
正しいスマートチップは、Ｓｃｈｎｏｒｒ 署名（Ｒ；ｓ）を生成するに当たり、一様にランダムにｒを生成するが、不正なスマートチップは、ｒに関して固有の分布によることにより、ユーザが仮に署名を検査したとしても検知されないように、秘密の情報を符号化することが可能となる。
【００１５】
以下、例を挙げてこれを説明する。
【００１６】
例えば、スマートチップが個別の識別子を有しており、異なる識別子のスマートチップは異なる領域からｒをランダムに選ぶとすると、この領域を知っている攻撃者はＲを検査することにより、スマートカードの識別子を知ることが可能となる。
【００１７】
一方、ユーザは（Ｒ；ｓ）を検査しても不正を発見することはできない。これは、ｒの領域が十分に広ければ、特定の領域からｒが選択されていることを検知することが困難だからである。
【００１８】
本発明では、ユーザによるアクセス権限の横流しを防止する目的で、スマートチップのような耐タンパー特性を備えた処理装置を仮定する。即ち、当該処理装置中にアクセス権限を表現するデータを記録することにより、ユーザが当該アクセス権限データのコピーを作成して、他のユーザに横流しする攻撃を防止する。しかしながら、これまでに述べたように、耐タンパー処理装置、即ち、スマートチップの利用は、ユーザの手許においてユーザのプライバシーがユーザに検知されずに漏洩される危険を孕んでおり、プライバシーの保護、又は、追跡の防止の観点からは、この問題の解決は不可避である。
【００１９】
第２：下位通信層レベルにおける追跡
第２の従来技術として、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ） 参照モデルにおける下位通信層、即ち、セッション層、トランスポート層、ネットワーク（ＩＰ） 層、データリンク層における通信を追跡不能とする技術について述べる。
【００２０】
これらの下位通信層では、ＩＰアドレスやＭＡＣアドレス等のアドレスを手がかりにパケットやデータグラムを配達するので、対策を施さない限り、これらのアドレスをユーザの追跡に利用することが可能となる。
【００２１】
下位の通信層において、ユーザを追跡から保護する方法は、その性質によって、理論的追跡不能性とシステム依存追跡不能性のいずれかに分類することが可能である。理論的追跡不能性においては、下位通信層が仮に何らかのアドレスをパケットの配達に利用するとしても、そのアドレスをユーザの追跡に利用できないことが理論的に演繹できるレベルの安全性を指す。以下に述べるように、仮名アドレスを用いる手法と、ブロードキャスト通信を用いる手法が知られている。
【００２２】
一方、システム依存追跡不能性においては、下位通信層は、ユーザの追跡に利用できるアドレスを用いてパケットの配達を行うが、機能としてアドレスを上位のアプリケーションから秘匿するレベルの安全性を指す。即ち、実際の安全性は下位通信層の信頼性に依存する。
【００２３】
さて、上述した仮名アドレスを用いた追跡不能通信とは、ユーザが動的に選択したアドレスを利用することで、追跡不能性を実現しようとする通信方式であり、赤外線通信やスマートカードにおいて実現性がある。
【００２４】
例えば、ＩｒＤＡ （Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）の通信規約であるＩｒＬＡＰ （Ｉｎｆｒａｒｅｄ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）や、ＮＦＣ （Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ） の通信規約であるＩＳＯ／ＩＥＣ １８０９２ では、アドレスの衝突を回避するメカニズム（ａｄｄｒｅｓｓ ｃｏｌｌｉｓｉｏｎ ａｖｏｉｄａｎｃｅ ｍｅｃｈａｎｉｓｍｓ）を規定している。
【００２５】
ＩｒＤＡは赤外線通信の規格であり、ＮＦＣは、Ｔｙｐｅ Ｃと呼ばれる非接触型ＩＣカードのために開発された通信方式を、１０ｃｍの距離で１００〜４００ｋｂｐｓの伝送速度を提供する近接通信に汎化した規格である。ＩｒＤＡやＮＦＣでは、少数のノード間の通信を想定しており、通信の都度、動的にアドレスを決定しても衝突が発生する確率は小さい。
【００２６】
従って、ワールドワイドで非衝突性を保証するようにアドレスを静的にデバイスに割り当てる方法（ＭＡＣアドレスに適用されている方法）は、オーバーヘッドが大きいだけで効果を得る機会は少ない。逆に、接続の都度、動的にアドレスを生成するようにして、衝突が発生したときにアドレスを変更して衝突を回避する手段を講じる方が効果的である。
【００２７】
Ｔｙｐｅ Ａ、Ｔｙｐｅ Ｂの非接触型ＩＣカードの通信規約であるＩＳＯ／ＩＥＣ １４４４３でも、動的にアドレスを生成して利用する仕様となっている。
【００２８】
このように、赤外線通信、及び、非接触型ＩＣ カード通信では、証明者は自らのアドレスを動的に決定する自由度を有しているので、仮名アドレスを適当なタイミングで更新する（例えば、セッションの更新の都度）ことで、演繹可能な追跡不能性を実現することが可能となる。
【００２９】
動的に仮名アドレスを生成する手法は、衝突回避メカニズムが存在しないＩＰ通信層やデータリンク層にも適用可能できる可能性はある。即ち、ＩＰアドレスとＭＡＣアドレスを動的に生成して、仮名アドレスとして利用するのである。
【００３０】
但し、アドレスの衝突回避メカニズムを伴わないため、ＬＡＮのような大規模なネットワークに適用すると、アドレスが衝突する危険が高まることに注意しなければならない。例えば、仮名アドレスに利用できるＭＡＣアドレスの有効長は３バイトであるので、Ｂｉｒｔｈｄａｙ Ｐｒｏｂｌｅｍの理論から、ｎユーザの間で衝突が発生する確率は約
【数３】
となる。これは、ネットワークに５８１以上のデバイス（ＮＩＣ等）が同時に存在すると、１／１００より大きい危険率で衝突が発生することを意味し、また、危険率を１／１０まで許容しても、許容されるデバイス数は１，８８０程度である。この数値が大きいと考えるか小さいと考えるかは、適用場面に依存するが、衝突が発生することは想定しなければならない。
【００３１】
Ｅｔｈｅｒｎｅｔ（登録商標）のように、アドレスの衝突が発生しても、パケットが喪失することはなく、配達が重複するのみであることが仮定できれば、アプリケーション側で衝突に対応することができる。但し、アドレスが衝突している他のデバイスに宛てたパケットも混在するため、アプリケーションは、下位の通信スタックから渡されるペイロードを検査して、自分宛のペイロードを取捨できる必要がある。
【００３２】
ブロードキャスト通信も、追跡不能性を実現する目的に利用することができる。２５５．２５５．２５５．２５５ はＩＰ アドレスにおけるブロードキャスト・アドレス（ｂｒｏａｄｃａｓｔ ａｄｄｒｅｓｓ）であり、ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ はＭＡＣ アドレスにおけるブロードキャスト・アドレスである。例えば、証明者は、パケットを送信する際、ブロードキャスト・アドレスをパケットのＳｏｕｒｃｅフィールドに指定するものとする。
【００３３】
このようなパケットを受信した検証者は、Ｓｏｕｒｃｅフィールドを含むパケットヘッダを根拠に、送信者を特定することはできないだけではなく、それ以前に受信したパケットとリンクすることもできない。
【００３４】
一方、検証者が返信を行う際には、ブロードキャストでパケットを送信する。ブロードキャストされたパケットから、証明者が自分宛のパケットを選択できるためには、パケットのペイロードにそのための情報が指定されなければならない。加えて、ブロードキャスト通信では検証者は証明者とＴＣＰセッションを構成できないので、本来ならばＴＣＰスタックが提供している通信の信頼性はアプリケーション層でサポートする必要がある。
【００３５】
インターネット・プロキシによりＩＰアドレスを隠蔽したウェブアクセスが可能であることは知られている。また、ＮＡＴ或いはＮＡＴＰをサポートするルータは、プライベートＩＰアドレスとルータのグローバルＩＰアドレスの変換を行う。このように、インターネット・プロキシやある種のルータは、通信において仮名アドレスによる通信を提供している。
【００３６】
しかしながら、実際のユーザの追跡不能性は、プロキシとルータの信頼性に依存している。極端な例では、プロキシはウェブサイトと共謀している可能性もあるし、ルータの管理者がユーザによるアクセスを追跡している可能性もある。このように、インターネット・プロキシやルータを用いた仮名通信は理論的追跡不能性をサポートせず、下位通信層の信頼性に依存するシステム依存追跡不能性をサポートするに留まる。
【００３７】
以上、述べたように、アプリケーション層より下位の通信層では、追跡を防止する技術は一応存在する。しかしながら、サービスへのアクセス制御は、アプリケーション層において要求される機能であり、仮に下位の通信層で追跡不能性を実現したとしても、例えば、アクセスコントロールリスト（ＡＣＬ）のような従来技術を用いてアプリケーション層においてアクセス制御を行う場合には、ユーザの識別と認証を行わなければならず、総体としての追跡不能性が損なわれる。
【００３８】
即ち、アプリケーション層において追跡不能性を提供するアクセス制御技術がのぞまれているのである。
【００３９】
第３：グループ署名
第３の従来の技術として、アプリケーション層で利用可能な、追跡不能認証技術である、グループ署名について説明する。
【００４０】
グループ署名は、以下の特徴を備えた署名方式である。
【００４１】
（１）グループのメンバーはグループを代表して、任意に署名を生成することができる。
【００４２】
（２）グループの公開鍵（グループ公開鍵）にアクセスできる誰でもが署名を検証することが可能であるが、検証により署名者の身許が明らかになることはない。
【００４３】
（３）逆に、グループの管理者（ＴＧＡ）は、署名から署名者を特定することが可能であり、紛争等、必要に応じて署名者の身許を特定する。
【００４４】
オークションにおけるグループ署名
このようなグループ署名は電子オークションや匿名注文システム等に応用がある。例えば、電子オークションでは、以下のような手続きを行い、オークションの参加者のプライバシーを守りつつ、不正な参加者を排除している。
【００４５】
（１）入札者（ｂｉｄｄｅｒ）はオークションの開催者が管理するグループに登録し、グループ署名用の個人鍵（グループ署名鍵）を生成する。
【００４６】
（２）入札者は入札時に入札金額等を記載したデータにグループ署名を施して申し込みを行う。
【００４７】
（３）出品者はグループ署名を検証することにより、入札資格者による申し込みであることを検証できるが、入札者の身許を知ることはできない。
【００４８】
（４）オークション成立後は、開催者は入札の署名から落札者の身許を明らかにし、品物の配送や決済を行う。
【００４９】
さて、グループ署名のスキームは、以下に述べる、準備、加入、署名、検証、及び、開示の各フェーズから構成される。
【００５０】
「準備」のフェーズでは、ＴＧＡはグループの公開鍵ペアを生成する。公開鍵ペアの個人鍵はＴＧＡの鍵として安全に保管する。
【００５１】
「加入」のフェーズでは、ユーザは、ＴＧＡと協力してグループ署名鍵を生成し、グループに参加する。
【００５２】
「署名」のフェーズでは、グループのメンバーは、グループ公開鍵と自身のグループ署名鍵を用いて、任意のメッセージに署名する。
【００５３】
「検証」のフェーズでは、検証者は、メンバーが生成した署名を検証するために、グループ公開鍵のみを用いる。
【００５４】
「開示」のフェーズでは、ＴＧＡは、グループ公開鍵ペアを用いて、署名を生成したメンバーを特定する。
【００５５】
Ａｔｅｎｉｅｓｅ、Ｃａｍｅｎｉｓｃｈ、Ｊｏｙｅ とＴｓｕｄｉｋ 等が２００２年に発表したグループ署名方式は、証明可能な安全性を有するグループ署名方式としては従前の方式に比較して効率的であったが、それでも署名の生成や検証に必要な計算量が大きいという問題があった。このため、Ａｔｅｎｉｅｓｅ 等による提案以降、グループ署名の計算量を軽減し、計算効率を向上させようとする試みがなされており、古川・今井が発表しているグループ署名の方式等、複数の方式が現時点で最も効率がよいと評価されている（下記非特許文献１）。
【００５６】
しかしながら、古川・今井のグループ署名方式（非特許文献１）でも、アクセス頻度が飛躍的に増大するユビキタス計算環境に適用するには、まだ計算量が大きい。実際、Ｐｅｎｔｉｕｍ（登録商標）４ ３．２ＧＨｚを搭載したＰＣを用いて、１９２ビット長標数の素体上に定義された楕円曲線のスカラー倍演算の実行時間を実測し、その計測値をもとに古川・今井のグループ署名方式の実行時間を推定したところ、一回の署名の生成と検証に要する合計時間は約６００ミリ秒と計算された。現実の適用においては、ユーザが携帯する端末或いはデバイスは計算能力が制限されるので、上記の数倍程度は時間がかかることが予想される。即ち、実際の実行時間は少なくとも２秒程度にはなるものと想定される。
【００５７】
これまで記したように、アプリケーション層における追跡不能認証の従来技術であるグループ署名では、ユビキタス計算環境への適用では十分な効率を有しないという問題があることが理解されよう。
【００５８】
更に、グループ署名の第二の問題点として、グループ管理者は常に生成された電子署名から署名者を特定することができる絶対的な特権者として機能することがある。この特権者の存在は、多くのアクセスがシームレス、かつ、透過的に行われるユビキタス計算環境においては、結局、ユーザの行動を監視する絶対的な検閲者が存在することを意味しているに他ならず、望ましい環境とは言い難い。
【００５９】
ユビキタス計算環境においてシステムによる追跡・検閲を回避するためには、アクセスの追跡不能性或いは匿名性が保証されるべきであるが、機密性を有していたり、管理が必要であるような資源へのアクセス、また、保安上の理由により監視が必要なサービスへのアクセスにおいては、ユーザの匿名性を最優先にさせるわけにはいかない場合が存在する。
【００６０】
一方、システム側の要求を優先させると、検閲が正当化されてしまう。
【００６１】
この問題に対する最適な解決は、以下のような要件を満たすことによって達成できると考えられる。
【００６２】
第一に重要な要件は、情報の開示は必ずユーザの明示的な同意に基づくとし、かつ、情報の開示はサービスや資源へのアクセスと引き換えで行われるという要件である。
【００６３】
第二に重要な要件は、開示される情報が、ユーザが同意した範囲に限られるという要件である。
【００６４】
従来のグループ署名は、上記のユビキタス計算環境におけるプライバシー保護と合理的な追跡のバランスに対する要件を満足しないという問題がある。
【００６５】
先行特許文献
下記特許文献１には、匿名認証の認証データを画像データを用いて送受信する手法が記載されている。この記載によれば、認証データを送受信できる匿名通信路を、簡易に実現可能であるとされている。
【００６６】
また、下記特許文献２には、簡易な構成で匿名認証を実現できる装置が開示されている。
【００６７】
また、下記特許文献３には、タンパー装置が取り付けられた利用者端末の利用が開示されている。
【００６８】
また、下記特許文献４には、個人の生体的特徴が外部に洩れるのを防止するために、タンパー手段を設けた携帯端末が開示されている。
【００６９】
また、下記特許文献５には、電子証明書の盗難を防止し、組織として電子署名した電子データであることを保証できる電子署名システムが記載されている。
【００７０】
また、下記非特許文献１には、匿名性を有するグループ署名の手法が開示されている。
【００７１】
【特許文献１】特開２００６−２９３４７２号公報
【特許文献２】特開２００５−５７７８号公報
【特許文献３】特開２００４−３２０５６２号公報
【特許文献４】特開２００２−３５８４８８号公報
【特許文献５】特開２００３−３０４２４３号公報
【非特許文献１】J. Furukawa and H. Imai. An efficient group signature scheme from bilinear maps. In ACISP 2005, pages 455 467, 2005.
【発明の開示】
【発明が解決しようとする課題】
【００７２】
本発明が解決しようとする第１の課題は、追跡不能性と計算量の低減とを両立させ、ユビキタス計算環境において、実用的なアクセス制御を可能とすることである。
【００７３】
また、本発明が解決しようとする第２の課題は、機密管理や保安等の合理的な目的のためにシステムがユーザの追跡情報を収集する機能を、ユーザによる明示的な同意が存在し、かつ、ユーザが開示に同意した範囲の情報に限って行うように実現することである。
【課題を解決するための手段】
【００７４】
本発明においては、第１の課題を解決し、追跡不能性と実用的な計算量を両立させるために、グループ署名のように単一の公開鍵に対して複数の個人鍵（署名鍵）を対応させる構成により追跡不能性を実現するのではなく、公開鍵と個人鍵（署名鍵）が一対一に対応する通常の構成による高速な署名方式を利用し、耐タンパー特性を有するプロバイダ・エージェント手段がユーザの干渉を受けることなく署名を生成することで、認証の正確性と高速化を両立させる一方、ユーザ・エージェント手段が署名を乱数化する作用を加えることより追跡不能性を実現している点を特徴とする。
【００７５】
認証の健全性を保証するために、本発明で利用する署名方式として、選択メッセージ攻撃に対して偽造不能性を有する署名方式を採用している。上記性質を満足する署名方式は従来から広く知られているので、それらを利用すればよい。例えば、ＲＳＡ−ＰＳＳやＤＳＡ等、近年広く用いられている署名方式がある。
【００７６】
ユーザ・エージェント手段によって乱数化された電子署名は、署名の検証式により定義される曲面上で常に同じ分布で存在することから、署名であるという事実以外の情報を含み得ない。
【００７７】
また、第２の課題を解決するために、本発明では、検証手段が情報の開示を求めた場合において、ユーザ・エージェント手段がユーザの意図が反映するようにその可否を判断する。例えば、ユーザ・エージェント手段は、ユーザインタフェースを介してユーザに可否の判断を求める、ユーザが事前に記述した設定ファイルの記載に従って可否の判断を行う等の機能を有する。追跡情報の開示を拒否する場合には、ユーザ・エージェント手段は、単に通信を遮断する、或いは、プロバイダ・エージェント手段による電子署名を前述のように乱数化し、追跡情報を含むいかなる情報も含まないように変換してから検証手段に出力する等の手段をとる。
【００７８】
また、ユーザ・エージェント装置が追跡情報の開示を許諾した場合でも、プロバイダ・エージェント装置が出力する署名中にユーザ・エージェント装置が入力する追跡情報の暗号化以外のデータが含まれないことを、ユーザ・エージェント装置が検証した後、出力を乱数化する。この結果、この場合においても追跡不能性を実現している。このように、本発明においては、計算量の軽減と追跡不能性とを両立させつつ、上述した第２の課題を解決している。
【００７９】
以下、本発明を具体的に述べれば、以下の通りとなる。
【００８０】
（１）まず、本発明は、上記課題を解決するために、ユーザによるサービスや資源へのアクセスを制御するアクセス制御装置において、アクセス権限の認証のために、電子署名の検証処理を実行する検証手段と、耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、前記検証手段に出力するユーザ・エージェント手段と、を含み、前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするアクセス制御装置である。
【００８１】
（２）また、本発明は、上記課題を解決するために、アクセス権限の認証のために、電子署名の検証処理を実行する外部の検証手段と、所定の通信を行い、所定のサービスに対するアクセス権限の認証を得るユーザ端末において、耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、外部の前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、外部の前記検証手段に出力するユーザ・エージェント手段と、を含み、外部の前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするユーザ端末である。
【００８２】
（３）また、本発明は、コンピュータを、上記（１）又は（２）記載のユーザエージェント手段として動作させるプログラムにおいて、前記コンピュータに、前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介する手順と、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からのデータを乱数化する手順と、前記乱数化したデータを、前記検証手段に出力する手順と、を実行させることを特徴とするプログラムである。
【００８３】
（４）また、本発明は、前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする（１）に記載のアクセス制御装置。
【００８４】
（５）また、本発明は、前記ユーザ・エージェント手段と前記プロバイダ・エージェント手段とが、前記ユーザが所持する同一のユーザ端末中に具備されることを特徴とする（１）に記載のアクセス制御装置である。
【００８５】
（６）また、本発明は、前記ユーザ・エージェント手段は、ユーザがダウンロード可能なプログラムであることを特徴とする（５）に記載のアクセス制御装置である。
【００８６】
（７）また、本発明は、前記プロバイダ・エージェント手段は、ユーザ端末中に装着されるIC チップであることを特徴とする（５）に記載のアクセス制御装置である。
【００８７】
（８）また、本発明は、前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成されることを特徴とする（５）に記載のアクセス制御装置である。
【００８８】
（９）また、本発明は、前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着されるIC チップであることを特徴とする（５）に記載のアクセス制御装置である
（１０）また、本発明は、前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成され、前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着される耐タンパー処理装置であることを特徴とする（５）に記載のアクセス制御装置である。
【００８９】
（１１）また、本発明は、前記検証手段が所定のシグナルを送信して前記ユーザの追跡情報の開示を求めた場合、 前記ユーザ・エージェント手段は、前記シグナルを受信して情報の開示の可否を判断し、情報開示を許可する場合に限り開示するべき情報を前記プロバイダ・エージェント手段に入力し、前記プロバイダ・エージェント手段は、入力された前記開示情報を特権秘密鍵を保有する者のみが復号できるように暗号化して、電子署名とともに出力し、前記ユーザ・エージェント手段は、前記プロバイダ・エージェント手段による暗号化が前記開示情報以外を含んでいないことを検査し、前記開示情報以外の情報が暗号化されている場合には通信を遮断し、前記開示情報のみが暗号化されている場合には、前記追跡情報が含まれ、かつ、署名の検証式を満たすという特性を除いて、常に同一の分布を取るように前記プロバイダ・エージェント手段の出力を乱数化して前記検証手段に出力することを特徴とする（８）から（１０）に記載のいずれかのアクセス制御装置である。
【００９０】
ここで、特権秘密鍵とは、追跡情報の暗号を復号するための鍵をいう。後述する実施の形態では、公開鍵ペアの個人鍵、すなわちアクセスＩＤと秘密鍵との算術和に等しい例を示しているが、発明としては、必ずしも同一である必要はない。
【００９１】
（１２）また、本発明は、上記（１１）に記載のアクセス制御装置において、情報の開示の可否をユーザから入力するユーザインタフェース、を備え、前記ユーザ・エージェント手段は、前記ユーザが該ユーザインタフェースを介して入力した指示に従って、情報の開示の可否を判断することを特徴とするアクセス制御装置である。
【００９２】
（１３）また、本発明は、上記（４）に記載のアクセス制御装置において、前記ユーザが内容を指定する情報の開示の可否の判断の基準となる設定ファイルを格納した記憶手段、を備え、前記ユーザ・エージェント手段は、前記記憶手段中の前記設定ファイルの記載に基づき、情報の開示の可否を判断することを特徴とするアクセス制御装置である。
【００９３】
（１４）また、本発明は、ユーザ・エージェント手段は、前記設定ファイル中の記載に基づき、サービス毎に情報の開示の可否を判断することを特徴とする（１３）に記載のアクセス制御装置。
【００９４】
（１５）また、本発明は、サービス毎に定まる一対の公開鍵ペアに対し、前記検証手段は、前記プロバイダ・エージェント手段が生成する電子署名の検証に前記公開鍵ペアのうち公開鍵を利用し、前記プロバイダ・エージェント手段は電子署名の生成に安全に保持する秘密鍵を利用し、 更に、該秘密鍵は前記公開鍵ペアの個人鍵の一部であって、かつ、前記プロバイダ・エージェント手段毎に一意であることにより、特権秘密鍵を保有しない者は二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とする（１）〜（１１）のいずれか１項に記載のアクセス制御装置である。
【００９５】
（１６）また、本発明は、（１）〜（１４）のいずれか１項に記載のアクセス制御装置において、前記検証手段は、サービス毎に定まる一対の公開鍵ペア中の公開鍵を利用して、前記プロバイダ・エージェント手段が生成する電子署名の検証を行い、前記プロバイダ・エージェント手段は、前記公開鍵ペア中の個人鍵の一部である秘密鍵であって、前記プロバイダ・エージェント手段毎に一意に定められた前記秘密鍵を用いて、電子署名の生成を行い、前記特権秘密鍵を保有しない者は所定の二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、前記特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とするアクセス制御装置である。
【００９６】
なお、前記公開鍵ペア中の公開鍵とは、いわば権限の検証鍵である。この鍵は、権限検証者によって用いられ、ユーザに所定のサービスを受ける権限があるかどうか確認に用いられる。
【００９７】
また、プロバイダエージェント手段が利用する秘密鍵は、前記公開鍵ペアにおいて、検証の目的に使用される公開鍵とペアをなす個人鍵の一部分であり、後述する実施の形態において、アクセスＩＤとの和が前記個人鍵となる成分が、好ましい一例に相当する。
【００９８】
また、個人鍵と特権秘密鍵とは同一であってもよい。
【００９９】
（１７）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術和に分解した際の、一方であることを特徴とするアクセス制御装置である。
【０１００】
（１８）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術積に分解した際の、一方であることを特徴とするアクセス制御装置である。
【０１０１】
（１９）また、本発明は、（１６）記載のアクセス制御装置において、前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を所定の算術演算によって二つの成分に分解した一方であることを特徴とするアクセス制御装置である。
【０１０２】
（２０）また、本発明は、（１７）〜（１９）のいずれか１項に記載のアクセス制御装置において、前記ユーザエージェント手段は、アクセスＩＤとして、前記個人鍵を分解した他方のデータが供給され、前記ユーザエージェント手段は、そのアクセスＩＤを乱数化して前記検証手段に送信することを特徴とするアクセス制御装置である。
【０１０３】
ここで、アクセスＩＤとは、アクセス識別子とも呼ばれる。
【０１０４】
（２１）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵を補完して前記公開鍵ペアの個人鍵を構成する補完部分を、アクセス識別子として前記ユーザ・エージェント手段が保持し、前記ユーザ・エージェント手段は、前記アクセス識別子を用いて前記プロバイダ・エージェント手段の出力を乱数化することを特徴とする上記（１５）〜（２０）のいずれか１項に記載のアクセス制御装置である。
【０１０５】
（２２）また、本発明は、アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とする発行手段、を含み、前記発行手段は、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする（２１）に記載のアクセス制御装置である。
【０１０６】
（２３）また、本発明は、（１）〜（２２）のいずれかに記載のアクセス制御装置に対して、サービス権限の発行を行う発行装置において、アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とし、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする権限発行装置である。
【０１０７】
（２４）また、本発明は、前記ユーザ・エージェント手段が前記プロバイダ・エージェント手段に入力する前記開示情報が、前記アクセス識別子、または、前記アクセス識別子を計算するのに十分な情報であることを特徴とする（１５）〜（２０）のいずれかに記載のアクセス制御装置である。
【０１０８】
（２５）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との和が前記公開鍵ペアの個人鍵と一致することを特徴とする（２１）に記載のアクセス制御装置である。
【０１０９】
（２６）また、本発明は、前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との積が前記公開鍵ペアの個人鍵と一致することを特徴とする（２１）に記載のアクセス制御装置である。
【０１１０】
（２７）また、本発明は、前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする（２）のユーザ端末である。
【０１１１】
（２８）また、本発明は、前記乱数化手順における乱数化した出力が、一様な分布であることを特徴とする（３）のプログラムである。
（２９）また、本発明は、前記ユーザ・エージェント手段は、ユーザが保持する通信機能を有するユーザ端末上に実装され、前記プロバイダ・エージェントは通信機能を有し、ユーザが保持する別のデバイスとして実装され、両者が互いに通信することで前記機能を実現することを特徴とする（１）のアクセス制御装置である。
【発明の効果】
【０１１２】
以上述べたように、第１の課題に対する本発明の効果に関しては、本発明では、プロバイダ・エージェント手段とユーザ・エージェント手段が協力して作成する署名データの分布を所定の曲面上で一様に分布させる工夫により、追跡不能性を実現している。
【０１１３】
また、実施の形態で述べるように、署名の生成及び検証における計算量が従来の技術に比べて減少しているので、より迅速な処理を行うことが可能である。
【０１１４】
また、第２の課題に対する本発明の効果に関しては、本発明では、ユーザ・エージェント手段はユーザによる直接・間接の指示に基づいて、情報の開示を実施するのみならず、開示するべき情報もユーザ・エージェント手段が指定する。したがって、実際のインプリメントにおいては、ユーザ・エージェント手段は、ユーザが信頼するベンダから取得するソフトウェア、又は、所定のハードウェアで構成されている。その結果、その作用は完全に公開検証が可能であるという性質から、常にユーザの同意に基づいた情報の開示を実現している。
【発明を実施するための最良の形態】
【０１１５】
以下、図面を用いて、発明の実施の形態を説明する。
【０１１６】
図１において、ユーザ端末１０としては、移動体通信端末（携帯電話）、携帯型計算機（ＰＤＡ等）、その他の専用端末（アクティブバッジ等）を想定し、環境からサービスの提供を受ける際に、ユーザが常に身に着けて携行するものと想定する。
【０１１７】
なお、「計算機」と「コンピュータ」とは同様の意味である。
【０１１８】
また、プロバイダ・エージェント手段２００は、いわゆる耐タンパー特性を有する装置である。ここで、耐タンパー特性とは、プロバイダ・エージェント手段２００が、その内部に保持されるデータやプログラム、及び、その内部で実行される計算処理が、外部から観察・干渉されない性質を言う。
【０１１９】
近年、交通機関の定期券や電子マネーに利用されている高セキュリティのＩＣチップは、価格、大きさ、使い易さ、安全性の観点から、将来性が有望視される耐タンパーＨ／Ｗである。
【０１２０】
また、ユーザ端末１０が移動体通信端末や携帯型計算機の場合には、プロバイダ・エージェント手段２００は、ＵＩＭ／ＳＩＭのように、外部から装着する実装が考えられる一方、アクティブバッジのように、プロバイダ・エージェント手段２００がユーザ端末１０と一体化している実装を想定することもできる。
【０１２１】
図１では、ユーザ端末１０は移動体通信端末や携帯型計算機であるとし、プロバイダ・エージェント手段２００は外部から装着され、ユーザ端末１０内の手段と外部装置インタフェース１４を介して通信する。
【０１２２】
ユーザ・エージェント手段３００は、ユーザ端末１０にインストールされるソフトウェア（プログラム）等で構成することが好ましい。また、外部装置インタフェース１４を介したプロバイダ・エージェント手段２００との通信は、必ず、ユーザ・エージェント手段３００を経由する。また例えば、ユーザ・エージェント手段３００はプロバイダ・エージェント手段２００のドライバプログラムを含む構成とすることも好適である。
【０１２３】
さらにそれに加えて、ユーザ端末１０は、ユーザ・エージェント手段３００と検証手段１００との間の通信機能を提供する通信手段１３と、情報の開示に関するユーザ・エージェント手段からの問い合わせをユーザが認識できるように表示する表示手段１２と、前記問い合わせに対してユーザが情報の開示の可否を指示する入力手段１１と、を含む。
【０１２４】
例えば、通信手段１３はＥｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ等の通信機能を提供する通信カードから構成することが好ましい。また、表示手段１２は液晶ディスプレイ等で構成することが好ましい。また、入力手段１１はタッチパネル、操作ボタン、キーボード等で構成することが好ましい。
【０１２５】
なお、検証手段と、ユーザ・エージェント手段と、プロバイダ・エージェント手段と、を含むシステムを、「アクセス制御装置」と呼ぶ。請求の範囲におけるアクセス制御装置も同様の意味である。
【０１２６】
図２は、検証手段１００の構成を示す。検証手段１００は、環境側に存在する計算機（コンピュータ）であり、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）等の汎用ＯＳを備える汎用のＰＣ、組み込みＯＳを備える専用機器のいずれで実現されてもよい。
【０１２７】
検証手段１００は、Ｅｔｈｅｒｎｅｔ（登録商標）、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ等である通信媒体２０を介して、ユーザ端末１０内のユーザ・エージェント手段３００と通信を行うが、その為に通信手段１０１を内蔵する。
【０１２８】
ユーザ・エージェント手段３００との通信は、相互接続性を得るために共通の方式に従って符号化されたメッセージを介して実行される。メッセージ解析手段１１０は、符号化されたメッセージを復号して検証処理に必要なデータを取り出す機能を提供し、メッセージ生成手段１１１は、計算処理の結果をメッセージに符号化する機能を提供する。
【０１２９】
更に、検証手段１００は、メモリ等の記憶媒体として実現される公開鍵保持手段１５０、チャレンジ保持手段１４０、及び、乱数化アクセスＩＤ保持手段１２０を具備し、計算処理に必要な各種データを保持する。
【０１３０】
また、プロバイダ・エージェント手段２００が生成する署名の検証に関わる処理を実行するチャレンジ生成手段１３１、並びに、レスポンス検証手段１４１は、ソフトウェア（プログラム）とそれを実行するコンピュータとから構成することが一般的に好適である。また、擬似乱数列を生成する乱数生成手段１３０は、ソフトウェア（プログラム）とそれを実行するコンピュータで実現しても良いし、組み込みハードウェアで構成することも好ましい。
【０１３１】
検証手段１００は、一般的には環境に埋め込まれたセンサー中の組み込みプログラム（Firmware等）、または、センサーに接続した計算機中のプログラム（およびそれを実行する計算機）である。一つの形態としては、携帯端末にインストールされたプログラム（例えば音楽再生プログラム）であってもよい。
【０１３２】
図３は、ホスト機器（移動体通信端末、携帯型計算機）に組み込む外部機器を想定して、プロバイダ・エージェント手段２００を説明する。
【０１３３】
ユーザ・エージェント手段３００との通信は、プロバイダ・エージェント手段２００を実装するＩＣチップ等の外部機器に内蔵されたホスト機器インタフェース２０１を介して実行される。
【０１３４】
また、ユーザ・エージェント手段３００・検証手段１００間の通信の場合と同様に、相互接続性を確立することを目的として、ユーザ・エージェント手段３００・プロバイダ・エージェント手段２００間で交換されるデータは、予め規定された方式に従って、メッセージに符号化される。ユーザ・エージェント手段３００から受信したメッセージを復号してデータを取り出す機能はメッセージ解析手段２１０により、また、ユーザ・エージェント手段３００へ送信するデータを符号化してメッセージを組み立てる機能はメッセージ生成手段２１１により提供される。
【０１３５】
更に、プロバイダ・エージェント手段２００は、メモリ等の記憶媒体として実現される秘密鍵保持手段２２０、チャレンジ保持手段２３０、アクセスＩＤ差分保持手段２４０、署名パラメータ差分保持手段２５０、及び、署名パラメータ保持手段２６２を具備し、計算処理に必要なデータを保持する。また、署名の生成に関わる手段として、署名パラメータ生成手段２６０、レスポンス生成手段２７０、及び、乱数生成手段２６１を含む。署名パラメータ生成手段２６０及びレスポンス生成手段２７０は、ソフトウェアプログラムとして実現することが一般的であり、擬似乱数列を生成する乱数生成手段２６１は、ソフトウェアプログラム、組み込みハードウェア、いずれの手段でも現実的に実現である。
【０１３６】
図４は、ユーザ・エージェント手段３００の構成図である。
【０１３７】
ユーザ・エージェント手段３００は、不正なプロバイダ・エージェント手段２００がユーザの追跡に寄与する情報を外部に漏洩することを防止することを目的とし、ユーザが自由に選択可能でること、また、プロバイダ・エージェント手段２００とは独立に自由に交換可能であることが重要である。
【０１３８】
このような要件を満足するには、例えば、ユーザ・エージェント手段３００をユーザ端末１０にユーザが自由にインストールするソフトウェア（プログラム）で実現することが好適である。
【０１３９】
又は、プロバイダ・エージェント手段２００をユーザ端末１０に自由に装着する外部機器とする実装が考えられる。
【０１４０】
ここでは、図４に示しているように、ユーザ端末１０を、外部からソフトウェアのインストールが可能なホスト機器（移動体通信端末や携帯型計算機）であり、ユーザ・エージェント手段３００はユーザがインストールするソフトウェア（プログラム）で実現されているものとして説明を行う。
【０１４１】
まず、ユーザ・エージェント手段３００と、プロバイダ・エージェント手段２００と、の間の通信は、ユーザ端末１０が具備する外部装置インタフェース１４を介して行われる。また、ユーザ・エージェント手段３００と、検証手段１００との通信も、同様にユーザ端末１０が具備する通信手段１３を介して行われるが、先述したように、これらの通信において交換されるデータは、相互接続性を確立するために定められた方法で符号化されたメッセージにより運搬される。
【０１４２】
このようにメッセージを符号化し、復号する動作は、メッセージ生成手段３１０と３１３、及び、メッセージ解析手段３１１と３１２によって実行される。ユーザ・エージェント手段３００は、検証手段１００から追跡情報開示の要求をシグナルとして受信すると、秘密鍵保持手段３２０によって開示の可否を判断する。図４に示す構成では、秘密鍵保持手段３２０は、ユーザ端末１０が具備する表示手段１２を利用して、ユーザに情報開示の要求をユーザが認識できる形式で表示し、入力手段１１を利用して、ユーザの判断を取得する。
【０１４３】
更に、ユーザ・エージェント手段３００は、アクセスＩＤ保持手段３３０と、チャレンジ保持手段３４０と、アクセスＩＤ差分保持手段３５１と、署名パラメータ保持手段３６０と、及び、署名パラメータ差分保持手段３６２と、を具備し、計算処理に必要なデータを保持する。これら保持手段は、メモリ等の記憶媒体を用いて構成することが好ましい。
【０１４４】
また、
・プロバイダ・エージェント手段２００が生成する署名の検証、
・検証手段１００への出力とするための乱数化、
を実行するために、ユーザ・エージェント手段３００は、アクセスＩＤ乱数化手段３５０と、署名パラメータ差分生成手段３６１と、レスポンス検証手段３７０と、レスポンス変換手段３８０と、さらに、乱数生成手段３９０と、を具備する。
【０１４５】
具体的な動作例
以下では、検証手段１００が情報開示を要求しないケースと、要求するケースとに分けて、この実施の形態における作用を述べる。
【０１４６】
まず、以下の説明で用いる記号を説明する。まず、
【数４】
は Dicesion Diffie-Hellman 問題の解決が困難であるような加法群とする。例えば、安全に生成された楕円曲線の部分群はこの条件を満足する。また、
【数５】
を
【数６】
の生成点（生成元）であるとし、
【数７】
の位数をｎと表す。
【０１４７】
【数８】
の元
【数９】
を署名検証のための公開鍵とし、σを対応する個人鍵であるとする。即ち、以下の関係が成り立つ。
【数１０】
更に、σは、以下の関係（数１３）が成り立つように、
【数１１】
と
【数１２】
とに分解される。
【０１４８】
【数１３】
ここで、
【数１４】
及び
【数１５】
は、それぞれ、公開鍵保持手段１５０、アクセスＩＤ保持手段３３０、及び、秘密鍵保持手段２２０に保持される。
【０１４９】
ユーザが環境に対して所定のサービスへのアクセスを要求すると、検証手段１００は認証を開始するメッセージ（シグナル）をユーザ・エージェント手段３００に送付するが、メッセージは復号された後、情報開示判定手段３２０に送付される。情報開示判定手段３２０は、検証手段１００がユーザの追跡情報の開示を要求しているか否かを判定する。追跡情報の開示が要求されていない場合、アクセスＩＤ乱数化手段３５０は、乱数生成手段３９０から乱数ρを得て、
【数１６】
を乱数化し、
【数１７】
を以下のように計算する。
【０１５０】
【数１８】
ここで、乱数ρはアクセスＩＤ差分保持手段３５１に保持され、
【数１９】
はメッセージに符号化されて、検証手段１００に送付される。
【０１５１】
検証手段１００は、メッセージから復号された
【数２０】
を乱数化アクセスＩＤ保持手段１２０に保持した後、チャレンジ生成手段１３１によりチャレンジｃを生成する。この際、チャレンジ生成手段１３１は、乱数生成手段１３０を利用する。生成されたチャレンジｃは、チャレンジ保持手段１４０に保持されるとともに、メッセージに符号化されてユーザ・エージェント手段３００に送付される。
【０１５２】
チャレンジｃを受信したユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００に対して署名パラメータＷの出力を求める。プロバイダ・エージェント手段２００中の署名パラメータ生成手段２６０は、乱数生成手段２６１から乱数
【数２１】
を取得し、以下の式により署名パラメータＷを計算する。
【０１５３】
【数２２】
次いで、乱数
【数２３】
を署名パラメータ保持手段２６２に保存し、署名パラメータＷをメッセージに符号化して、ユーザ・エージェント手段３００に送付する。ユーザ・エージェント手段３００中の署名パラメータ差分生成手段３６１は、乱数生成手段３９０を利用して乱数
【数２４】
を生成し、署名パラメータ差分保持手段３６２に保持する。更に、ユーザ・エージェント手段３００は、チャレンジ保持手段３４０に保持しているチャレンジｃと、署名パラメータ差分保持手段３６２に保持している乱数
【数２５】
を符号化してメッセージを生成し、このメッセージをプロバイダ・エージェント手段２００に送付する。
【０１５４】
プロバイダ・エージェント手段２００は、メッセージを復号し、チャレンジｃと、乱数
【数２６】
をそれぞれ、チャレンジ保持手段２３０、及び、署名パラメータ差分保持手段２５０に保持する。更に、プロバイダ・エージェント手段２００中のレスポンス生成手段２７０は、署名パラメータ保持手段２６２に保持されている乱数
【数２７】
、
署名パラメータ差分保持手段２５０に保持されている乱数
【数２８】
チャレンジ保持手段２３０に保持されているチャレンジｃ、及び、秘密鍵保持手段２２０に保持されている
【数２９】
から、以下の式により、レスポンスｒを計算する。
【０１５５】
【数３０】
プロバイダ・エージェント手段２００は、計算したレスポンスｒを符号化してメッセージを生成し、このメッセージを、ユーザ・エージェント手段３００に送付する。
【０１５６】
ユーザ・エージェント手段３００中のレスポンス検証手段３７０は、署名パラメータ保持手段３６０に保持されているＷ、署名パラメータ差分保持手段３６２に保持されている
【数３１】
、
チャレンジ保持手段３４０に保持されているｃ、及び、アクセスＩＤ保持手段３３０に保持されている
【数３２】
を用いて、以下の関係を検証し、関係が検証できない場合には処理を中止する。
【０１５７】
【数３３】
上記の関係が検証できた場合は、後述する計算式から、
【数３４】
及び
【数３５】
を計算し、符号化してメッセージを作成し、このメッセージを検証手段１００に送付する。ここで、上記の計算式とは下記の通りである。
【０１５８】
【数３６】
検証手段１００は、メッセージを復号して、
【数３７】
と
【数３８】
とを取得し、以下の関係が成立するか検査する。
【０１５９】
【数３９】
検査の結果、上記関係が成立した場合、検証手段１００は、ユーザがサービスへのアクセス権限を保有しているものと判断し、サービスの提供を許諾するシグナルを出力する。検査の結果、上記関係がが不成立の場合、検証手段１００は、ユーザがサービスへのアクセス権限を保有していないものと判断し、サービスの提供を拒否するシグナルを出力する。
【０１６０】
追跡情報の暗号化
次に、検証手段１００が追跡情報の開示を要求している場合の処理について述べる。
【０１６１】
検証手段１００が、認証の開始を通知するメッセージ（シグナル）をユーザ・エージェント手段３００に送付すると、ユーザ・エージェント手段３００は、同メッセージ（シグナル）を復号後、情報開示判定手段３２０に送付する。情報開示判定手段３２０は、入力手段１１及び表示手段１２を利用して、ユーザから開示の可否の指示を受ける。
【０１６２】
ユーザが、追跡情報の開示を拒否した場合は、情報開示判定手段３２０は認証を中止する判定を行い、実際に、ユーザ・エージェント手段３００は検証手段１００との通信を中止する。
【０１６３】
一方、ユーザが、追跡情報の開示を許諾した場合は、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００にシグナルを送り、プロバイダ・エージェント手段２００から
【数４０】
を満足する数
【数４１】
を受け取る。但し、
【数４２】
は、プロバイダ・エージェント手段２００が生成する乱数である。
【０１６４】
更に、ユーザ・エージェント手段は、乱数
【数４３】
を生成し、更に、
【数４４】
を計算し、
【数４５】
をプロバイダ・エージェント手段２００に送付する。
【０１６５】
プロバイダ・エージェント手段２００は、ρを次の式で暗号化し、数ｅを得る。
【０１６６】
【数４６】
ｅは、
【数４７】
とペアとすることにより、いわゆる、ElGamal 暗号となる。実際、個人鍵σを保持するアクセス権限の発行者、すなわち、
【数４８】
を生成する機関は、下式によりρを計算することができる。
【０１６７】
【数４９】
一方、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００が出力したｅが正しいρの暗号化であることを検証し、プロバイダ・エージェント手段２００が、ユーザ・エージェント手段３００（ユーザ）の意図に反して、ρ、従って、
【数５０】
以外の情報を外部に開示していないことを検証する必要がある。
【０１６８】
しかしながら、ユーザ・エージェント手段２００は、σを知らないので、ｅを復号して、ρと一致するかを検査することはできないという問題がある。
【０１６９】
この問題を解決するために、ユーザ・エージェント手段３００は、プロバイダ・エージェント手段２００に対して、
【数５１】
を送付する。プロバイダ・エージェント手段２００は、
【数５２】
に対し、後述する式を用いて
【数５３】
を計算して、ユーザ・エージェント手段３００に出力する。この計算式は、
【数５４】
である。
【０１７０】
ユーザ・エージェント手段３００は、関係
【数５５】
が成立するかを検査し、もし成立しない場合は、プロバイダ・エージェント手段２００が不正な出力を行ったと判断して、認証を中止する。
【０１７１】
上記検査が有効である理由は、プロバイダ・エージェント手段２００が正しくｅを計算した場合には、上記関係は必ず成立するのに対し、プロバイダ・エージェント手段２００に対して
【数５６】
が秘密であるという前提の下で、不正なｅが上記関係を満足する確率は１／ｎに等しく、無視しえるほど小さいからである。
【０１７２】
ユーザ・エージェント手段３００は、ｅの検証後、
【数５７】
に加えて、
【数５８】
を検証装置１００に送付する。検証装置１００は個人鍵σにアクセスできないので、
【数５９】
を受け取っても、ρ、即ち、
【数６０】
を復号することはできず、従って、ユーザを追跡することはできない。つまり、アクセス権の発行者であり、サービスのオーナーである機関のみが、
【数６１】
を復号してユーザを追跡することができる点が重要である。
【０１７３】
さて、上記手続きには、まだ、問題がある。即ち、ユーザ・エージェント手段３００が、ｅを偽造して、追跡を免れようとする企てを、検証手段１００が阻止できなければならない。この目的のためには、プロバイダ・エージェント手段２００が、ｅに対して署名を付与すればよい。
【０１７４】
例えば、
【数６２】
を計算し、
【数６３】
を出力するようにすれば、検証手段１００が、関係
【数６４】
が成り立つことを検証できれば、即ち、電子署名
【数６５】
の検証ができれば、ｒ及びｓがプロバイダ・エージェント手段２００によって生成されたものであることを確認することができる。ρ以外の情報が開示されないことを保証するためには、ユーザ・エージェント手段３００が、同じ関係
【数６６】
を検査すればよい。
【０１７５】
【数６７】
には、ユーザ・エージェント手段２００が生成した乱数
【数６８】
が含まれているため、追跡不能であることは、
【数６９】
の場合と同様に示される。
【０１７６】
効果について
以上述べたように、本実施の形態によれば、第１の課題に関し、以下のような効果が得られる。
【０１７７】
すなわち、プロバイダ・エージェント手段とユーザ・エージェント手段が協力して作成する署名データの分布を所定の曲面上で一様に分布させる工夫により、追跡不能性を実現している。
【０１７８】
その一方で、現在最も高速なグループ署名とされる古川・今井（非特許文献１）の方式において、署名の生成及び検証における計算量が楕円曲線上でのスカラー倍演算に換算して４９回であるのに対し、本実施の形態の方式では、情報を開示しないときには同じ換算で７回、情報を開示するときには２１回に相当する計算量を必要とするのみであり、実行効率を改善している。
【０１７９】
また、本実施の形態によれば、第２の課題に関し、以下のような効果が得られる。
【０１８０】
すなわち、本実施の形態によれば、ユーザ・エージェント手段は、ユーザによる直接・間接の指示に基づいて、情報の開示を実施するのみならず、開示するべき情報もユーザ・エージェント手段が指定する。実際のインプリメントにおいては、ユーザ・エージェント手段は、ユーザが信頼するベンダから取得するソフトウェア、又は、所定のハードウェアで構成されている。したがって、その作用は完全に公開検証が可能であるという性質から、ユーザの同意に基づく情報の開示を実現している。
【０１８１】
また、換言すれば、従来のグループ認証では、２者（２プログラム）が強調して処理を行っているのに対して、本実施の形態では、３者（３プログラム）が強調して処理を行った結果、処理速度の向上という効果が得られたものである。
【実施例】
【０１８２】
本実施の形態にかかるアクセス制御システムを実際に運用した場合の例の説明図が図５に示されている。ここでは、例えば、音楽配信サービスの提供を行うシステムについて説明する。
【０１８３】
この図において、権限発行者４００は、例えば音楽配信サービスを提供する音楽配信サイト、又は、そのサイトから委託を受けてアクセス権限（視聴権限）の発行を行う発行機関・発行サーバである。この権限発行者４００は音楽配信サービスに関して、公開鍵４１０と秘密鍵４１２と、を作成し、公開鍵４１０を公開し、秘密鍵４１２は秘密に保持する。
【０１８４】
本実施の形態において特徴的なことは、権限発行者４００が秘密鍵を算術和に分解していることである。そして、一方をアクセスＩＤとしてユーザに提供し、他方をそのユーザのユーザ端末に組み込まれている耐タンパー処理装置４２０に提供する。
【０１８５】
さて、算術和による分解の仕方はいくらでもありえる。したがって、各ユーザ毎に異なる分解を行うことによって、各ユーザ毎に異なるアクセスＩＤを発行することが可能である。ユーザ毎に異なるアクセスＩＤを作成した際に、当然、アクセスＩＤとの和が個人鍵と一致する秘密鍵もユーザ毎に異なる（図５参照）。この秘密鍵は耐タンパー処理装置４２０に秘密裏に送られる。具体的には何らかの暗号通信路を用いて耐タンパー装置４２０に送られ、耐タンパー装置４２０はこれを内部に保持する。暗号通信路はどのようなものでも良いが、一般的な公開鍵暗号を用いた通信路で秘密鍵を送ることが好ましい。例えば、Diffie-Hellman鍵交換アルゴリズムを適用することが好ましい。 なお、耐タンパー処理装置４２０は、上述した例でも示したように、ユーザ機器に装着するＩＣカード、ＳＩＭカードなどのＨ／Ｗで実現されることが好ましい。また、耐タンパー処理装置４２０は、請求の範囲のプロバイダ・エージェント手段の好適な一例に相当する。
【０１８６】
なお、本実施例では、算術和を使用したが、他の種類の演算でもかまわない。
【０１８７】
一方、ユーザ毎に発行されたアクセスＩＤが、ユーザに提供されることによって、ユーザに音楽配信サービス利用の権限が与えられる。具体的には、ユーザはこのアクセスＩＤをユーザ機器内部の記憶手段に格納しておく。このアクセスＩＤは、ユーザがユーザ機器にインストールしたプログラムが利用する。このユーザ機器のコンピュータ（プロセッサ）は、このプログラムを実行することによってユーザ・エージェント手段４３０が構成される（図５参照）。なお、このプログラムそのものを、便宜上ユーザエージェント手段４３０と呼ぶ場合もある。
【０１８８】
ユーザはこのアクセスＩＤを用いて例えば音楽配信サービスを受けることが出来る。ユーザは例えば自分がダウンロードしたプログラム（ユーザエージェント手段４３０）にこのアクセスＩＤを管理させることが可能である。ユーザはユーザ端末（例えば音楽再生機能付き携帯電話）内にこのユーザエージェント手段４３０をインストールし、音楽配信サービスを受けさせるのである。
【０１８９】
グループ署名と本実施例
ここで、従来技術であるグループ署名と、本実施例とを対比して説明する。
【０１９０】
一般的に、電子署名と呼ばれるものは、各ユーザ毎に、公開鍵と、個人鍵（秘密鍵）とを定めている。各個人（例えばＡ氏）は自分しか知らない個人鍵を用いて署名を生成する。他人は公開されているＡ氏の公開鍵を用いて、それがＡ氏の署名であることを確認できる。
【０１９１】
さて、グループ署名の構成説明図が図６に示されている。グループ署名では、各個人が個人鍵を持っているが、公開鍵は１個だけである。各個人は、自分の（例えばＡ氏の）個人鍵をもちいて署名をすることが出来る。そして誰もが、公開されている公開鍵を用いてそれが（グループのメンバーの誰かの）正しい署名であることを確認することは出来るが、グループ中の「誰」の署名かを特定することが出来ない。このような構成によってグループ署名は各個人の匿名性を保証出来る有力な手段として知られている。
【０１９２】
なお、グループ署名では、特権者がおり、この特権者が保有する特権個人鍵を用いて、各署名が誰のものかを特定することも可能である。すなわち、通常は匿名であるが、問題が生じた場合にはその署名者を特定することが出来る仕組みを提供している。この様子が図７に示されている。
【０１９３】
このようにグループ署名は非常に有用な特性を有しているが、計算量が多く、迅速な処理は困難であった。
【０１９４】
これに対して、本実施例では、公開鍵と個人鍵とが１対１に対応している古典的なスキームを用いているので、迅速な処理が可能となっている。すなわち、本実施例は、公開鍵と個人鍵とが１対１に対応している昔からの仕組みを用いつつ（すなわち高速処理を可能としつつ）、ユーザの匿名性を担保しうる点を、特徴とするものである。
【０１９５】
このような特性を実現できたのは、上述したように、秘密鍵４１２を２つの部分（アクセスＩＤ＋残余成分）に分けるという仕組みを採用したからである（図５参照）。これによって、各ユーザ毎にアクセスＩＤを設定することができ、従来のグループ署名のように各個人に秘密鍵を設定するのと同様の効果を得られたものである。
【０１９６】
上述したように、２つの部分に分ける演算はどのような演算でもかまわない。加算でも良いし、また乗算でもかまわない。また、算術演算だけでなく、ビット演算のような論理演算でもかまわない。
【０１９７】
サービス提供の実際
図５に戻って、ユーザがサービスの提供を受ける動作を説明する。
【０１９８】
ユーザはサービスを受けるために、権限検証者４４０に対してアクセスＩＤを呈示する。この際、図５に示すように乱数化してから呈示する。
【０１９９】
その一方、権限検証者４４０は、いわゆるチャレンジ−レスポンス認証するためにチャレンジを発行する。このチャレンジは耐タンパー処理装置４２０に渡され、耐タンパー処理装置はレスポンスを生成する。ユーザエージェント手段４３０は、このレスポンスを乱数化して権限検証者４４０に送る。
【０２００】
ここで、留意すべき点は、アクセスＩＤの乱数化と、レスポンスの乱数化と、は関連のある処理である点である。これによって、権限検証者４４０は、チャレンジレスポンス認証が成功し、アクセスＩＤが正しいＩＤであることを確認することが可能である。この検証には、権限発行者４００が発行した公開鍵４１０が必要であることはもちろんである。実際の処理（計算）についてこれまで述べた通りである。
【０２０１】
権限検証者４４０が、ユーザが正しい権限を有していると判断した場合には、ユーザは、サービス（例えば音楽配信サービス）を受けることが許可される。
【０２０２】
なお、乱数化は、所定の乱数に基づくスクランブル等を意味する。例えば、所定の乱数を発生させ、その乱数をアクセスＩＤに加算し、一方、その同じ乱数を用いて、レスポンスに所定のより複雑な演算を施す等の処理を実行する。これらの乱数化は、ユーザエージェント手段４３０が実行する。
【０２０３】
本実施の形態では、アクセスＩＤの乱数化と、レスポンスの乱数化に同じ乱数を用いたが、一般的に言えば、関連する乱数化であればよい。
【０２０４】
また、図５においては、権限発行者４００は、サービス提供者と同じでも良いし、外部の者でもかまわない。権限発行者４００は、ユーザがそのサービスを受ける権限を発行してもらう（アクセスＩＤを発行してもらう）際にその処理を実行するが、その後のサービス提供には関与していない。サービス提供の許可／不許可は、ユーザ（が使用するユーザ端末（例えば携帯電話、ＰＤＡなど））と、権限検証者４４０との間の通信によって行われる。
【０２０５】
権限検証者４４０がサービスの提供を許可した場合に、サービス提供者がサービスを提供するが、権限検証者４４０がサービス提供者と同一でもよい。同一サーバに、権限検証のためのプログラムと、サービス提供のためのプログラムが、共にインストールされ稼働している構成も不可能ではない。また、権限検証者４４０は、他のサーバ上で稼働するプログラムで実現しても良い。
【０２０６】
さらに、権限検証者４４０を実現するプログラムは、ユーザ端末に組み込まれる構成としても好適である。上述したように、ユーザ端末には、耐タンパー処理装置４２０が組み込まれるが、この耐タンパー装置４２０のハードウェアと権限検証者４４０のソフトウェアとが同一の端末装置に組み込まれていても良い。例えば、権限検証者４４０が端末内の音楽受信プログラムで実現され、ユーザエージェント手段４３０はこの音楽受信プログラムが受信した音楽をＣＤ等に格納するユーザ側のプログラムとして実現されていても良い。
【図面の簡単な説明】
【０２０７】
【図１】本実施の形態におけるユーザ端末の構成図である。
【図２】本実施の形態における検証手段の構成図である。
【図３】本実施の形態におけるプロバイダ・エージェント手段の構成図である。
【図４】本実施の形態におけるユーザ・エージェント手段の構成図である。
【図５】本実施例の構成図である。
【図６】従来のグループ署名の説明図である。
【図７】従来のグループ署名の説明図である。
【符号の説明】
【０２０８】
１０ ユーザ端末
１１ 入力手段
１２ 表示手段
１３ 通信手段
１４ 外部装置インターフェース
２０ 通信媒体
１００ 検証手段
１０１ 通信手段
１１０ メッセージ解析手段
１１１ メッセージ生成手段
１２０ 乱数化アクセスＩＤ保持手段
１３０ 乱数生成手段
１３１ チャレンジ生成手段
１４０ チャレンジ保持手段
１４１ レスポンス検証手段
１５０ 公開鍵保持手段
２００ プロバイダ・エージェント装置
２０１ ホスト機器インターフェース
２１０ メッセージ解析手段
２１１ メッセージ生成手段
２２０ 秘密鍵保持手段
２３０ チャレンジ保持手段
２４０ アクセスＩＤ差分保持手段
２５０ 署名パラメータ差分保持手段
２６０ 署名パラメータ生成手段
２６１ 乱数生成手段
２６２ 署名パラメータ保持手段
２７０ レスポンス生成手段
３００ ユーザ・エージェント手段
３１０、３１３ メッセージ生成手段
３１１、３１２ メッセージ解析手段
３２０ 情報開示判定手段
３３０ アクセスＩＤ保持手段
３４０ チャレンジ保持手段
３５０ アクセスＩＤ乱数化手段
３５１ アクセスＩＤ差分保持手段
３６０ 署名パラメータ保持手段
３６１ 署名パラメータ差分生成手段
３６２ 署名パラメータ差分保持手段
３７０ レスポンス検証手段
３８０ レスポンス変換手段
３９０ 乱数生成手段
４００ 権限発行者
４１０ 公開鍵
４１２ 秘密鍵
４２０ 耐タンパー処理装置
４３０ ユーザエージェント手段
４４０ 権限検証者
【特許請求の範囲】
【請求項１】
ユーザによるサービスや資源へのアクセスを制御するアクセス制御装置において、
アクセス権限の認証のために、電子署名の検証処理を実行する検証手段と、
耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、
前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、前記検証手段に出力するユーザ・エージェント手段と、
を含み、前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするアクセス制御装置。
【請求項２】
アクセス権限の認証のために、電子署名の検証処理を実行する外部の検証手段と、所定の通信を行い、所定のサービスに対するアクセス権限の認証を得るユーザ端末において、
耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、
外部の前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、外部の前記検証手段に出力するユーザ・エージェント手段と、
を含み、外部の前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするユーザ端末。
【請求項３】
コンピュータを、請求項１又は２記載のユーザエージェント手段として動作させるプログラムにおいて、前記コンピュータに、
前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介する手順と、
署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からのデータを乱数化する手順と、
前記乱数化したデータを、前記検証手段に出力する手順と、
を実行させることを特徴とするプログラム。
【請求項４】
前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする請求項１記載のアクセス制御装置。
【請求項５】
前記ユーザ・エージェント手段と前記プロバイダ・エージェント手段とが、前記ユーザが所持する同一のユーザ端末中に具備されることを特徴とする請求項１記載のアクセス制御装置。
【請求項６】
前記ユーザ・エージェント手段は、ユーザがダウンロード可能なプログラムであることを特徴とする請求項３に記載のアクセス制御装置。
【請求項７】
前記プロバイダ・エージェント手段は、ユーザ端末中に装着されるICチップであることを特徴とする請求項５に記載のアクセス制御装置。
【請求項８】
前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成されることを特徴とする請求項５記載のアクセス制御装置。
【請求項９】
前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着されるIC チップであることを特徴とする請求項５に記載のアクセス制御装置。
【請求項１０】
前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成され、
前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着される耐タンパー処理装置であることを特徴とする請求項５に記載のアクセス制御装置。
【請求項１１】
前記検証手段が所定のシグナルを送信して前記ユーザの追跡情報の開示を求めた場合、 前記ユーザ・エージェント手段は、前記シグナルを受信して情報の開示の可否を判断し、情報開示を許可する場合に限り開示するべき情報を前記プロバイダ・エージェント手段に入力し、
前記プロバイダ・エージェント手段は、入力された前記開示情報を特権秘密鍵を保有する者のみが復号できるように暗号化して、電子署名とともに出力し、
前記ユーザ・エージェント手段は、前記プロバイダ・エージェント手段による暗号化が前記開示情報以外を含んでいないことを検査し、前記開示情報以外の情報が暗号化されている場合には通信を遮断し、前記開示情報のみが暗号化されている場合には、前記追跡情報が含まれ、かつ、署名の検証式を満たすという特性を除いて、常に同一の分布を取るように前記プロバイダ・エージェント手段の出力を乱数化して前記検証手段に出力することを特徴とする請求項８〜１０のいずれか１項に記載のアクセス制御装置。
【請求項１２】
請求項１１に記載のアクセス制御装置において、
情報の開示の可否をユーザから入力するユーザインタフェース、
を備え、
前記ユーザ・エージェント手段は、前記ユーザが該ユーザインタフェースを介して入力した指示に従って、情報の開示の可否を判断することを特徴とするアクセス制御装置。
【請求項１３】
請求項４に記載のアクセス制御装置において、
前記ユーザが内容を指定する情報の開示の可否の判断の基準となる設定ファイルを格納した記憶手段、
を備え、
前記ユーザ・エージェント手段は、前記記憶手段中の前記設定ファイルの記載に基づき、情報の開示の可否を判断することを特徴とするアクセス制御装置。
【請求項１４】
ユーザ・エージェント手段は、前記設定ファイル中の記載に基づき、サービス毎に情報の開示の可否を判断することを特徴とする請求項１３に記載のアクセス制御装置。
【請求項１５】
サービス毎に定まる一対の公開鍵ペアに対し、前記検証手段は、前記プロバイダ・エージェント手段が生成する電子署名の検証に前記公開鍵ペアのうち公開鍵を利用し、
前記プロバイダ・エージェント手段は電子署名の生成に安全に保持する秘密鍵を利用し、
更に、該秘密鍵は前記公開鍵ペアの個人鍵の一部であって、かつ、前記プロバイダ・エージェント手段毎に一意であることにより、特権秘密鍵を保有しない者は二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とする請求項１乃至１１のいずれか１項に記載のアクセス制御装置。
【請求項１６】
請求項１〜１４のいずれか１項に記載のアクセス制御装置において。
前記検証手段は、サービス毎に定まる一対の公開鍵ペア中の公開鍵を利用して、前記プロバイダ・エージェント手段が生成する電子署名の検証を行い、
前記プロバイダ・エージェント手段は、前記公開鍵ペア中の個人鍵の一部である秘密鍵であって、前記プロバイダ・エージェント手段毎に一意に定められた前記秘密鍵を用いて、電子署名の生成を行い、
前記特権秘密鍵を保有しない者は所定の二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、前記特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とするアクセス制御装置。
【請求項１７】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術和に分解した一方であることを特徴とするアクセス制御装置。
【請求項１８】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術積に分解した一方であることを特徴とするアクセス制御装置。
【請求項１９】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を所定の算術演算によって二つの成分に分解した一方であることを特徴とするアクセス制御装置。
【請求項２０】
請求項１７〜１９のいずれか１項に記載のアクセス制御装置において、
前記ユーザエージェント手段は、アクセス識別子として、前記個人鍵を分解した他方のデータが供給され、前記ユーザエージェント手段は、そのアクセス識別子を乱数化して前記検証手段に送信することを特徴とするアクセス制御装置。
【請求項２１】
前記プロバイダ・エージェント手段が保持する前記秘密鍵を補完して前記公開鍵ペアの個人鍵を構成する補完部分を、アクセス識別子として前記ユーザ・エージェント手段が保持し、
前記ユーザ・エージェント手段は、前記アクセス識別子を用いて前記プロバイダ・エージェント手段の出力を乱数化することを特徴とする請求項１５〜２０のいずれか１項に記載のアクセス制御装置。
【請求項２２】
アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とする発行手段、
を含み、前記発行手段は、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２３】
請求項１〜２２のいずれかに記載のアクセス制御装置に対して、サービス権限の発行を行う発行装置において、
アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とし、
前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする権限発行装置。
【請求項２４】
前記ユーザ・エージェント手段が前記プロバイダ・エージェント手段に入力する前記開示情報が、前記アクセス識別子、または、前記アクセス識別子を計算するのに十分な情報であることを特徴とする請求項１５〜２０のいずれか１項に記載のアクセス制御装置。
【請求項２５】
前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との和が前記公開鍵ペアの個人鍵と一致することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２６】
前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との積が前記公開鍵ペアの個人鍵と一致することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２７】
前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする請求項２記載のユーザ端末。
【請求項２８】
前記乱数化手順における乱数化した出力が、一様な分布であることを特徴とする請求項３記載のプログラム。
【請求項２９】
前記ユーザ・エージェント手段は、ユーザが保持する通信機能を有するユーザ端末上に実装され、前記プロバイダ・エージェントは通信機能を有し、ユーザが保持する別のデバイスとして実装され、両者が互いに通信することで前記機能を実現することを特徴とする請求項１記載のアクセス制御装置。
【請求項１】
ユーザによるサービスや資源へのアクセスを制御するアクセス制御装置において、
アクセス権限の認証のために、電子署名の検証処理を実行する検証手段と、
耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、
前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、前記検証手段に出力するユーザ・エージェント手段と、
を含み、前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするアクセス制御装置。
【請求項２】
アクセス権限の認証のために、電子署名の検証処理を実行する外部の検証手段と、所定の通信を行い、所定のサービスに対するアクセス権限の認証を得るユーザ端末において、
耐タンパー特性を備える処理装置であり、アクセス権限の証明のために電子署名の生成処理を実行するプロバイダ・エージェント手段と、
外部の前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介し、署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からの出力を乱数化した後、外部の前記検証手段に出力するユーザ・エージェント手段と、
を含み、外部の前記検証手段への出力の分布が常に一定であることから前記ユーザを追跡する情報が前記検証手段に開示されないことを特徴とするユーザ端末。
【請求項３】
コンピュータを、請求項１又は２記載のユーザエージェント手段として動作させるプログラムにおいて、前記コンピュータに、
前記検証手段と前記プロバイダ・エージェント手段との間の通信を傍受・仲介する手順と、
署名の特性を保持したまま常に同一の分布をとるように前記プロバイダ・エージェント手段からのデータを乱数化する手順と、
前記乱数化したデータを、前記検証手段に出力する手順と、
を実行させることを特徴とするプログラム。
【請求項４】
前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする請求項１記載のアクセス制御装置。
【請求項５】
前記ユーザ・エージェント手段と前記プロバイダ・エージェント手段とが、前記ユーザが所持する同一のユーザ端末中に具備されることを特徴とする請求項１記載のアクセス制御装置。
【請求項６】
前記ユーザ・エージェント手段は、ユーザがダウンロード可能なプログラムであることを特徴とする請求項３に記載のアクセス制御装置。
【請求項７】
前記プロバイダ・エージェント手段は、ユーザ端末中に装着されるICチップであることを特徴とする請求項５に記載のアクセス制御装置。
【請求項８】
前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成されることを特徴とする請求項５記載のアクセス制御装置。
【請求項９】
前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着されるIC チップであることを特徴とする請求項５に記載のアクセス制御装置。
【請求項１０】
前記ユーザ・エージェント手段は、前記ユーザが前記ユーザ端末中にインストールしうるプログラム及びそれを実行するコンピュータから構成され、
前記プロバイダ・エージェント手段は、前記ユーザ端末中に装着される耐タンパー処理装置であることを特徴とする請求項５に記載のアクセス制御装置。
【請求項１１】
前記検証手段が所定のシグナルを送信して前記ユーザの追跡情報の開示を求めた場合、 前記ユーザ・エージェント手段は、前記シグナルを受信して情報の開示の可否を判断し、情報開示を許可する場合に限り開示するべき情報を前記プロバイダ・エージェント手段に入力し、
前記プロバイダ・エージェント手段は、入力された前記開示情報を特権秘密鍵を保有する者のみが復号できるように暗号化して、電子署名とともに出力し、
前記ユーザ・エージェント手段は、前記プロバイダ・エージェント手段による暗号化が前記開示情報以外を含んでいないことを検査し、前記開示情報以外の情報が暗号化されている場合には通信を遮断し、前記開示情報のみが暗号化されている場合には、前記追跡情報が含まれ、かつ、署名の検証式を満たすという特性を除いて、常に同一の分布を取るように前記プロバイダ・エージェント手段の出力を乱数化して前記検証手段に出力することを特徴とする請求項８〜１０のいずれか１項に記載のアクセス制御装置。
【請求項１２】
請求項１１に記載のアクセス制御装置において、
情報の開示の可否をユーザから入力するユーザインタフェース、
を備え、
前記ユーザ・エージェント手段は、前記ユーザが該ユーザインタフェースを介して入力した指示に従って、情報の開示の可否を判断することを特徴とするアクセス制御装置。
【請求項１３】
請求項４に記載のアクセス制御装置において、
前記ユーザが内容を指定する情報の開示の可否の判断の基準となる設定ファイルを格納した記憶手段、
を備え、
前記ユーザ・エージェント手段は、前記記憶手段中の前記設定ファイルの記載に基づき、情報の開示の可否を判断することを特徴とするアクセス制御装置。
【請求項１４】
ユーザ・エージェント手段は、前記設定ファイル中の記載に基づき、サービス毎に情報の開示の可否を判断することを特徴とする請求項１３に記載のアクセス制御装置。
【請求項１５】
サービス毎に定まる一対の公開鍵ペアに対し、前記検証手段は、前記プロバイダ・エージェント手段が生成する電子署名の検証に前記公開鍵ペアのうち公開鍵を利用し、
前記プロバイダ・エージェント手段は電子署名の生成に安全に保持する秘密鍵を利用し、
更に、該秘密鍵は前記公開鍵ペアの個人鍵の一部であって、かつ、前記プロバイダ・エージェント手段毎に一意であることにより、特権秘密鍵を保有しない者は二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とする請求項１乃至１１のいずれか１項に記載のアクセス制御装置。
【請求項１６】
請求項１〜１４のいずれか１項に記載のアクセス制御装置において。
前記検証手段は、サービス毎に定まる一対の公開鍵ペア中の公開鍵を利用して、前記プロバイダ・エージェント手段が生成する電子署名の検証を行い、
前記プロバイダ・エージェント手段は、前記公開鍵ペア中の個人鍵の一部である秘密鍵であって、前記プロバイダ・エージェント手段毎に一意に定められた前記秘密鍵を用いて、電子署名の生成を行い、
前記特権秘密鍵を保有しない者は所定の二つの署名が同一のプロバイダ・エージェント手段により生成されたか否かを判断することが出来ず、かつ、前記特権秘密鍵を保有する者のみが前記の判断を行うことができることを特徴とするアクセス制御装置。
【請求項１７】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術和に分解した一方であることを特徴とするアクセス制御装置。
【請求項１８】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を二つの成分の算術積に分解した一方であることを特徴とするアクセス制御装置。
【請求項１９】
請求項１６記載のアクセス制御装置において、
前記公開鍵ペア中の個人鍵の一部である秘密鍵は、前記個人鍵を所定の算術演算によって二つの成分に分解した一方であることを特徴とするアクセス制御装置。
【請求項２０】
請求項１７〜１９のいずれか１項に記載のアクセス制御装置において、
前記ユーザエージェント手段は、アクセス識別子として、前記個人鍵を分解した他方のデータが供給され、前記ユーザエージェント手段は、そのアクセス識別子を乱数化して前記検証手段に送信することを特徴とするアクセス制御装置。
【請求項２１】
前記プロバイダ・エージェント手段が保持する前記秘密鍵を補完して前記公開鍵ペアの個人鍵を構成する補完部分を、アクセス識別子として前記ユーザ・エージェント手段が保持し、
前記ユーザ・エージェント手段は、前記アクセス識別子を用いて前記プロバイダ・エージェント手段の出力を乱数化することを特徴とする請求項１５〜２０のいずれか１項に記載のアクセス制御装置。
【請求項２２】
アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とする発行手段、
を含み、前記発行手段は、前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２３】
請求項１〜２２のいずれかに記載のアクセス制御装置に対して、サービス権限の発行を行う発行装置において、
アクセス権限の発行に際して、前記プロバイダ・エージェント手段と秘密裏に鍵交換を行い、交換した鍵を前記プロバイダ・エージェント手段が保持する秘密鍵とし、
前記公開鍵ペアの個人鍵と前記秘密鍵とからアクセス識別子を計算し、前記ユーザ・エージェント手段に発行することを特徴とする権限発行装置。
【請求項２４】
前記ユーザ・エージェント手段が前記プロバイダ・エージェント手段に入力する前記開示情報が、前記アクセス識別子、または、前記アクセス識別子を計算するのに十分な情報であることを特徴とする請求項１５〜２０のいずれか１項に記載のアクセス制御装置。
【請求項２５】
前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との和が前記公開鍵ペアの個人鍵と一致することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２６】
前記プロバイダ・エージェント手段が保持する前記秘密鍵と前記ユーザ・エージェント手段が保持する前記アクセス識別子との積が前記公開鍵ペアの個人鍵と一致することを特徴とする請求項２１に記載のアクセス制御装置。
【請求項２７】
前記ユーザ・エージェント手段が乱数化した出力が、一様な分布であることを特徴とする請求項２記載のユーザ端末。
【請求項２８】
前記乱数化手順における乱数化した出力が、一様な分布であることを特徴とする請求項３記載のプログラム。
【請求項２９】
前記ユーザ・エージェント手段は、ユーザが保持する通信機能を有するユーザ端末上に実装され、前記プロバイダ・エージェントは通信機能を有し、ユーザが保持する別のデバイスとして実装され、両者が互いに通信することで前記機能を実現することを特徴とする請求項１記載のアクセス制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００８−２７８１４４（Ｐ２００８−２７８１４４Ａ）
【公開日】平成２０年１１月１３日（２００８．１１．１３）
【国際特許分類】
【出願番号】特願２００７−１１８５４６（Ｐ２００７−１１８５４６）
【出願日】平成１９年４月２７日（２００７．４．２７）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００６年１１月９日 社団法人 情報処理学会発行の「情報処理学会研究報告会（２００６／１１／９〜１０） ２００６−ＵＢＩ−１２講演予稿集」に発表
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００７年２月２２日 社団法人 情報通信学会発行の「情報処理学会研究報告会（２００７／２／２２〜２３） ２００７−ＭＢＬ−４０，２００７−ＵＢＩ−１３講演予稿集」に発表
【出願人】（５０４１３７９１２）国立大学法人 東京大学 (1,942)
【Ｆターム（参考）】
【公開日】平成２０年１１月１３日（２００８．１１．１３）
【国際特許分類】
【出願日】平成１９年４月２７日（２００７．４．２７）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００６年１１月９日 社団法人 情報処理学会発行の「情報処理学会研究報告会（２００６／１１／９〜１０） ２００６−ＵＢＩ−１２講演予稿集」に発表
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り ２００７年２月２２日 社団法人 情報通信学会発行の「情報処理学会研究報告会（２００７／２／２２〜２３） ２００７−ＭＢＬ−４０，２００７−ＵＢＩ−１３講演予稿集」に発表
【出願人】（５０４１３７９１２）国立大学法人 東京大学 (1,942)
【Ｆターム（参考）】
[ Back to top ]