JP3896909B2 - 電子チケットを用いたアクセス権管理装置 - Google Patents
電子チケットを用いたアクセス権管理装置 Download PDFInfo
- Publication number
- JP3896909B2 JP3896909B2 JP2002183739A JP2002183739A JP3896909B2 JP 3896909 B2 JP3896909 B2 JP 3896909B2 JP 2002183739 A JP2002183739 A JP 2002183739A JP 2002183739 A JP2002183739 A JP 2002183739A JP 3896909 B2 JP3896909 B2 JP 3896909B2
- Authority
- JP
- Japan
- Prior art keywords
- client device
- electronic ticket
- data
- key
- access right
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 claims description 89
- 238000004891 communication Methods 0.000 claims description 65
- 230000008859 change Effects 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 6
- 230000008520 organization Effects 0.000 claims description 4
- 238000011157 data evaluation Methods 0.000 claims 3
- 208000033748 Device issues Diseases 0.000 claims 1
- 230000037406 food intake Effects 0.000 claims 1
- 238000012546 transfer Methods 0.000 description 64
- 230000006870 function Effects 0.000 description 40
- 238000012797 qualification Methods 0.000 description 24
- 238000010586 diagram Methods 0.000 description 22
- 238000004422 calculation algorithm Methods 0.000 description 21
- 238000012545 processing Methods 0.000 description 19
- 238000007689 inspection Methods 0.000 description 17
- 230000000694 effects Effects 0.000 description 12
- 238000012795 verification Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004364 calculation method Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 6
- 238000012360 testing method Methods 0.000 description 6
- 239000000284 extract Substances 0.000 description 5
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 4
- 239000002131 composite material Substances 0.000 description 4
- 230000014759 maintenance of location Effects 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 3
- 229920001690 polydopamine Polymers 0.000 description 3
- 241000209094 Oryza Species 0.000 description 2
- 235000007164 Oryza sativa Nutrition 0.000 description 2
- 239000000654 additive Substances 0.000 description 2
- 230000000996 additive effect Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 235000009566 rice Nutrition 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- HMUNWXXNJPVALC-UHFFFAOYSA-N 1-[4-[2-(2,3-dihydro-1H-inden-2-ylamino)pyrimidin-5-yl]piperazin-1-yl]-2-(2,4,6,7-tetrahydrotriazolo[4,5-c]pyridin-5-yl)ethanone Chemical compound C1C(CC2=CC=CC=C12)NC1=NC=C(C=N1)N1CCN(CC1)C(CN1CC2=C(CC1)NN=N2)=O HMUNWXXNJPVALC-UHFFFAOYSA-N 0.000 description 1
- OVSKIKFHRZPJSS-UHFFFAOYSA-N 2,4-D Chemical compound OC(=O)COC1=CC=C(Cl)C=C1Cl OVSKIKFHRZPJSS-UHFFFAOYSA-N 0.000 description 1
- LDXJRKWFNNFDSA-UHFFFAOYSA-N 2-(2,4,6,7-tetrahydrotriazolo[4,5-c]pyridin-5-yl)-1-[4-[2-[[3-(trifluoromethoxy)phenyl]methylamino]pyrimidin-5-yl]piperazin-1-yl]ethanone Chemical compound C1CN(CC2=NNN=C21)CC(=O)N3CCN(CC3)C4=CN=C(N=C4)NCC5=CC(=CC=C5)OC(F)(F)F LDXJRKWFNNFDSA-UHFFFAOYSA-N 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000010411 cooking Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001771 impaired effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【発明の属する技術分野】
この発明は、電子的データによって表現された各種サービス利用権の発行、検証、ならびに前記利用権データに対する無効化、譲渡、分割、変更などの操作を行うアクセス権管理技術に関する。
【0002】
【背景の技術】
アクセス権管理システムにおいては、リソースやサービスに対するアクセスを欲する主体がアクセス要求を行い、一方、リソースを管理する主体がアクセスを欲するものを認証することによってそのアクセスを許可したり拒絶したりする。
【0003】
情報システムとしては、このようなアクセス権認証は、アクセス要求主体とアクセス管理主体が、それぞれアクセス資格を証明する証明情報とアクセス資格を認証する検証情報に基づいて、データの交換と評価を行うことによって実現される。
【0004】
アクセス資格保持者を他のアクセス資格を持たない第三者から区別する機能の原理は、畢竟アクセス資格証明情報の保持にかかっており、どのような暗号学的な技法が用いられるかに依存しない事実である。
【0005】
情報システムにおいて、アクセス資格の保持はユーザのアクセス資格証明情報保持と直結しているが故に、アクセス管理主体から見ると、アクセス資格保持者がアクセス資格証明情報を第三者にそのまま引き渡すことが常に原理的脅威となる。
【0006】
この脅威を取り除くことを目的に、従来技術によるアクセス権管理システムでは、アクセス要求主体たるユーザの保持する証明情報は当ユーザの利害に直接関与する情報とし、その情報の濫用、つまり、第三者への開示がアクセス要求主体にとって望ましくないような状況を演出する。例えば、アクセスアカウントをユーザの銀行口座番号やクレジットカード番号に関連付けてデータベースに記録したり、公開鍵インフラ(PKI)で公開鍵証明書の発行に際して運転免許証のような身分証明を要求するのは、これが理由である。つまり、アクセス管理におけるアクセス要求主体たるユーザの証明情報は、ユーザのアイデンティティを指示する識別情報そのものであるか、もしくは、このような識別情報とシステム的に緊密に関連付けられた情報である。
【0007】
従って、アクセス権管理システムは、ユーザの身許を認証するシステムレイヤと、認証の結果に基づいて該ユーザに許されているアクセス権を確認するシステムレイヤとから構成され、アクセス権の管理は次のステップに従って実行させる。
【0008】
[ステップ1]:ユーザはリソースへのアクセスをアクセス管理主体に対して要求する。
[ステップ2]:アクセス管理主体は、予め定められた適切な手段を用いて、ユーザの身許を認証する。この目的に供される手段の例としては、アクセス管理主体が適正と認める認証局(Certification Authority)が発行する公開鍵証明書と公開鍵暗号アルゴリズムによる認証プロトコルの実行や、予めデータベース中に記録されたユーザの身許証明データ(銀行預金口座番号、クレジットカード番号など)の暗証番号をキーとする照会などがある。
[ステップ3]:アクセス管理主体は、前記ユーザの身許認証に失敗した場合、該ユーザのアクセス要求を拒否する。
[ステップ4]:予めデータベース中に記録されたレコードを参照し、身許の確認された該ユーザに許可されているアクセス資格を確認する。レコードには行使条件(有効期限など)やアクセス種別(読み出し、書き込み、変更など)などアクセス資格の定義が記録される。データベース中に記録されるアクセス資格定義のレコードの集まりをアクセス制御リスト(ACL,Access Control List)と呼ぶこともある。
[ステップ5]:アクセス管理主体は、ステップ4で確認されたアクセス資格の範囲内で、該ユーザによるリソースへのアクセスを許可する。
【0009】
このように、従来技術によるアクセス権管理システムは、次の二つの特徴を有する。
1、ユーザの身許(アイデンティティ)を認証するステップを含む。
2、アクセス制御リストなどによりユーザのアクセス資格の集中管理を行う。
【0010】
【発明が解決する課題】
前節で述べた従来技術に鑑み、本発明では、従来技術が有する以下の5項目の課題を解決することを目的とする。
【0011】
1、アクセス資格の集中管理に起因する運用側のコストの増大と運用時の性能上の制約
2、アクセス資格の集中管理に起因する流通フローを実現する上での制約
3、ユーザが複数のクライアント装置を取得しなければならないことの不便
4、秘密情報が介在することに起因して発生する、サービス提供者、クライアント装置提供者、アプリケーション装置提供者の間の相互運用性の阻害
5、ユーザによるアクセス権の行使における匿名性の欠如
【0012】
以下では、従来技術がとる構成上の特徴に関連付けて、上記の課題に関して説明する。
【0013】
従来技術の構成上の第1の特徴はつぎのようなものである。従来技術においては、ユーザを特定してサービスの利用を制御するために、サービスの提供者がユーザを管理するための手段を保持する必要があった。典型的な例としては、サービスの提供者が管理するサーバ上にデータベースを構築し、ユーザの識別情報を含むユーザ固有の情報を格納するデータレコードを記憶しておく。ここでは、このユーザ固有のデータレコードをアカウントと呼ぶ。サービスの提供者は、特定のユーザによるサービスへのアクセスの可否を判断する際に、このアカウントを参照する。アカウントには、ユーザの身許の識別情報が記憶されており、この識別情報を用いて、たとえユーザがネットワークを挟んで存在した場合においても、その身許を認証して、然る後、ユーザによるサービスへのアクセスの可否を判断する。アカウントには、該ユーザによるサービスの利用に関わる種々の情報、例えば、アクセス種別、アクセス許諾期間、アクセス許諾回数などが記録され、サービスの提供者はこれらの情報をもとに、粒度の細かい制御を実施する。
【0014】
本発明が解決しようとする従来技術の第一の課題は、従来技術による上記構成に起因する、アカウントの管理コストのオーバーヘッドと性能上の制約である。
【0015】
サービスの提供者が管理するアカウントは、サービスへのアクセス制御を行う上で根幹となる情報が格納されている。従って、外部からの侵入や内部の不正行為により、これらの情報が改竄されたり消去されたりすると、ユーザによるサービスの利用を正しく制御することができなくなり、サービスの提供者は損害を蒙る危険がある。ために、当アカウントのセキュリティの管理は厳重に行わなければならず、ファイアウォールによる外部からの侵入の防止、内部からのアクセスの制御などの対策を、システム管理者による不断の注意のもとで継続的に実施する必要があった。
【0016】
サービスを利用するユーザの数が増加し、また、ユーザによるサービスの利用頻度が高まることによってアカウントへのアクセス数が増大すると、アカウントを管理するための上記オーバーヘッドは飛躍的に増大し、サービス提供者の大きな負担となる。勿論、多数のユーザのアカウントを記録するための大きな記憶媒体の調達や、物理アクセスの制限、停電などの事故に備えたバックアップなどのオーバーヘッドも大きくなる。
【0017】
サービス提供の性能の観点からは、アカウントを格納するサーバの処理能力やネットワークとの接続環境が限界要因となり、アクセスが集中した場合、単位時間あたりの処理数(スループット)や1処理あたりの処理時間(ターンアラウンドタイム)が低下する恐れがある。特に、ユーザによるサービスの利用のたびにアカウントにアクセスする、所謂、オンライン・オンデマンド型の制御方法では、この課題による弊害はより顕著になり、ユーザに堪えがたい不便を強いることとなる。
【0018】
従来技術の課題の原因となる、従来技術の構成の第2の特徴は以下のとおりである。
【0019】
前記、データベースによるユーザのアカウントの管理の例にみるように、従来技術の構成では、ユーザによるサービスの利用の制御は、単一のサーバや装置によって集中的に行われる。
【0020】
この構成上の特徴に起因する、従来技術の第二の課題は、前記集中管理的な利用制御は市場で求められている流通フローを実現する上での阻害要因となる、少なくとも、重要なコスト要因となる点である。
【0021】
例えば、商品の流通フローとしては、再販モデル(リテイルモデル)と呼ばれる形態が一般的である。再販モデルにおいては、最上流の商品の生産者と最下流の消費者との間で、複数の卸業者と小売業者が介在し、商品は上流から下流に流れていく。商品が一旦生産者の手をはなれ、卸業者の手に渡されると、該卸業者による次工程の卸業者或いは小売業者への商品の販売は、全く該卸業者の恣意にゆだねられ、上流に位置する生産者は取引に関与することはない。この事実は、更に下流の卸業者及び小売業者に関しても同様である。
【0022】
一方、従来技術によるサービスの利用制御では、サービスの利用権の流通は全て中央のサーバないし装置で管理されるため、商品の生産者に当たるサービスの提供者の介在を省くことができない。この事実は、商品たるサービスの利用権の流通にあたり、トランザクションが煩雑になるのに加え、中央のサーバないし装置で流通経路を管理する必要が生じ、また、利用権の移動が発生する都度中央のサーバないし装置に対してアクセスが発生することから、システムが大規模にならざるを得ず、構築及び運用のコストも増大する。
【0023】
別の例としては、近年、デジタルコンテンツの新しい流通形態として注目を浴びているピア・ツー・ピアの流通がある。ピア・ツー・ピアの流通では、消費者は、サービスの提供者が許諾する範囲で、自ら購入したサービスの利用権のコピーを作成し、他の消費者に譲渡することが認められる(私的利用に限定した複製の許諾)。従来技術の構成により、ピア・ツー・ピアの流通を実現しようとすると、個人消費者間での利用権の譲渡は、中央のサーバないし装置を経由して実行されるため、前述の再販モデルの場合と同様に、システムの構築及び運用コストの増大をもたらす。これは、また、プライバシー保護の観点からも問題となる。
【0024】
従来技術の課題の原因となる、従来技術の構成上の第3の特徴は以下のとおりである。
【0025】
ユーザによるサービスの利用制御を確実に実行するためには、サービスに対するアクセスが許諾されたユーザとそれ以外のユーザとを確実に区別するための手段が必須となる。このために、システム固有の秘密の識別情報が用いられることがある。例えば、アカウントにユーザを識別するためのパスワードを記録しておき、ユーザに対するサービス利用の可否を判断するたびに、ユーザにパスワードの入力を促し、記録されたパスワードと入力されたパスワードとの一致を検査する。この方式は、現在インターネット上で提供されている多くのサービスで採用されているものである。前記システム固有の識別情報の秘密性は、サービス提供者の利益の保全に緊密に関わっており、外部に漏洩することによりサービスの提供者の利益を著しく損なう危険がある。このため、異なるサービスの提供者のシステム間で、前記識別情報を共有することができない。
【0026】
また、前記従来技術の構成上の特徴と関連して、従来技術の課題の原因となる、従来技術の構成上の第4の特徴は、サービスの利用制御の仕組みと、ユーザに対して実際にサービスを提供するアプリケーション装置とが一体化しており、複数のサービスの提供者による異なるシステム間での相互運用性がない点である。このような構成は、ユーザによるサービスの利用の制御にシステム固有の秘密情報(暗号の鍵など)を利用している点に起因している。異なるアプリケーション装置の提供者が提供するアプリケーション装置と、サービス提供者が運用する利用制御装置とを相互に連携させて運用する場合、利用制御装置に帰属する秘密情報がアプリケーション装置中に現れることとなる。アプリケーションの提供者に悪意があり、アプリケーション装置がサービスの提供者に帰属する前記秘密情報を外部に漏洩するように作成されていた場合(バックドア)、サービスの不正な濫用を許す結果になる。
【0027】
従来技術の第三の課題は、従来技術の前記構成に起因する。
【0028】
即ち、ユーザが複数のサービスの提供者が提供するサービスを利用する際、ユーザは自らのアクセス権を証明する手段(例えば、パスワード)をサービスの提供者の数だけ、或いは、サービスの数だけ保持しなければならないという、ユーザの利便性に関する課題である。
【0029】
前記パスワードによる方法は、パスワードが横流しされる危険があり、ユーザのアクセス権を認証する手段としてはあまり安全ではない。より安全な利用制御を行おうとすると、識別のための秘密情報を内蔵するクライアント装置の存在を仮定する。
【0030】
クライアント装置は、例えば、PC上で稼動するプログラムの形態をとったり、ICカードなどのデバイスの形態をとったりするが、クライアント装置にはサービスの提供者の利害に影響する秘密情報が内蔵されていることから、複数のサービス提供者の間で共有ができないという事由と、アプリケーション装置と一体化している必要があるという自由により、ユーザは、サービスの提供者毎、或いは、サービスやコンテンツの種別毎にクライアント装置を調達しなければならない。これは、ユーザが、サービスの提供者やサービスごとに異なるプログラムを自分のPCにインストールしたり、ICカードを取得して携行しなければならないということを意味し、ユーザにとっての大きな参入障壁となる。
【0031】
前記課題を、サービスの提供者の観点から見てみると、サービスの提供者が自ら保有するサービスを、確実な利用制御を前提とした上で、広くユーザに提供しようとした場合に、ユーザが前記クライアント装置を取得する際の閾が問題となる。ユーザに対して、自分のサービスだけにのみ使用できるクライアント装置の取得を動機付けることは、ユーザの手間を考えると、易しいことではなく、サービスをユーザに提供する上での重大な阻害要因となる。
【0032】
このように、本発明では、クライアント装置とアプリケーション装置との間の相互運用性を実現することで、前記第三の課題を解決することを目指すが、このことは、サービスの提供者、クライアント装置の提供者、アプリケーション装置の提供者が互いに異なることを前提とする。
【0033】
従って、本発明が解決しようとする第四の課題は、サービス提供者が運用する管理システム、ユーザが保持するクライアント装置、アプリケーション提供者が供給しユーザにサービスを提供するアプリケーション装置が協調してサービスの利用制御を行う際に、互いに、それぞれの提供者の利益を損なうことがないにする点にある。
【0034】
具体的な例では、クライアント装置とアプリケーション装置が協調することにより、クライアント装置の秘密情報がアプリケーション装置に露呈し、その結果アプリケーションの提供者が偽のクライアント装置を構成できる脅威がある。また、サービス提供者が運用する管理システムは、正当なユーザにのみサービスを提供するようにアプリケーション装置を制御するわけであるが、この時アクセス資格の偽造につながる秘密情報がアプリケーション装置に流れることがあってはならない。
【0035】
このように、システム間の相互運用性を確保するためには、システム間で相互の秘密情報が流れることがない設計である必要がある。
【0036】
本発明が解決しようとする第五の課題は、従来技術によるアクセス権権利システムがユーザの身許認証を含むことに起因する。
【0037】
公共、商用を問わず、現在実際にユーザに提供されているサービスを観察すると、必ずしも、ユーザの身許の認証を必要としないものが多いことが分かる。例えば、多くの商用サービスでは、アクセスを要求しているユーザが対価を支払っているか否かが、サービスを提供するか否かを決定する要因であって、そのユーザの身許を認証する必要は些かも存しない。これは、従来技術のアクセス資格管理システムが、アクセス資格の横流しといった脅威に対して脆弱であるため、ユーザの身許情報とアクセス資格を緊密に結びつけることでこの脆弱性を補おうとする、いわば、必要悪である。
【0038】
実際、ユーザの視点から見ると、サービスの利用に際して、必須ではないにもかかわらず自らの身許を明らかにしなければならないというのは、プライバシー保護の観点からは好ましくない。
【0039】
【課題を解決するための手段】
この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。
【0040】
本発明は、ユーザに対して、該ユーザが保有するアクセス資格を電子チケット(チケットデータ)の形態で発行し、サービスを提供するアプリケーション装置と、ユーザが保有し、該ユーザを他のユーザと区別するための手段であるクライアント装置とが、互いに協調して該電子チケットを処理することで、サービスのアクセス制御を実現するものである。
【0041】
本発明の第1の側面によれば、上述の第一の課題を解決するために、クライアント装置を特定する目的に供する特定情報であって、かつ、第三者に開示しても安全性を損なうことのない情報を、公開の手順で取得する手段を設けることで、サービスの提供者がアカウント管理等の手段を用いて前記特定情報を集中管理することなく、チケットデータを生成することを可能とする。
【0042】
クライアント装置の特定情報は、クライアント装置が必要に応じて生成したり、電子チケット生成装置が、ディレクトリサービスなどの第三者機関を介して、取得することが可能である。
【0043】
更に、チケットデータの生成及び発行の過程で、クライアント装置内に電子チケット生成装置との間の共有鍵を保持せしめるとともに、アプリケーション装置が検査するチケットデータを該共有鍵に依存せしめ、ユーザがサービスにアクセスする際にクライアント装置内に保持される該共有鍵の存在を根拠にアクセス資格を証明することにより、サービスの提供者のシステムが関与することなくアクセス資格の認証を可能とし、結果としてアクセス資格の集中管理を排する。
【0044】
また、本発明の他の側面によれば、上述の第二の課題を解決するために、チケットデータの無効化、譲渡、分割、条件の変更を、サービス提供者が運用するシステムを介することなく、アプリケーション装置とクライアント装置との間のトランザクションのみにより実行可能となる構成とすることで解決する。
【0045】
チケットデータに関わる前記の操作がアプリケーション装置とクライアント装置との間で実行可能であることは、チケットデータの流通の過程で、流通に関わる当事者、例えば、販売者と購買者が、第三者の干渉やサポートを受けることなく取引を完結することができることを意味し、現在すでに存在するものも含めて、多様な流通フローを直接的に実現できることを意味する。
【0046】
また、さきに述べたように上述の本発明の第1の側面によれば、クライアント装置の特定情報を開示可能で、かつ、電子チケット生成装置が公開された手続きにより取得できる手段を設けていいる。このに併せて、公開の手続きで取得された特定情報に基づいて、電子チケット生成装置とクライアント装置が、電子チケット毎の共有鍵を生成し、該共有鍵を用いてアクセス制御を実行する構成すれば、チケットデータの生成に当たってクライアント装置固有の秘密情報が電子チケット生成装置に送られることがなくなり、よって一つのクライアント装置で異なるサービス提供者が運用する複数の電子チケット生成装置から、チケットデータの供給を受けることが可能となる。これにより上述の第三の課題も解決できる。
【0047】
また、本発明のさらに他の側面によれば、第四の課題を解決するために、第一に、アプリケーション装置とクライアント装置が、一方向性関数手段を用いて通信データを生成し、よって各々の秘密情報が相手方に伝わらない構成としている。更に、電子チケット生成装置がアプリケーション設定データ及びクライアント証明データを評価する手段を設けることで、サービスの提供者が、アプリケーション装置及びクライアント装置の提供者を認証することを可能とし、結果として、相互運用性の実現において問題となる提供者間(従って、装置間)の信頼の確立に手段を与える。
【0048】
また、上述した本発明の第1の側面によれば、ユーザの識別情報ではなく、クライアント装置の特定情報に基づきチケットデータを生成するので、第五の課題を解決することができる。より厳密に考えるならば、アクセス制御が電子チケット生成装置とクライアント装置との間で共有される共有鍵に基づいて実施され、加えて、クライアント装置に内部データの改竄や窃取に対する保護手段が施されており、該共有鍵の横流しが困難であることから、クライアント装置の特定情報をユーザの識別情報にバインドして抑止効果を狙うことなく、安全を確保することが可能となる。
【0049】
なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品(記録媒体)もこの発明の技術的な範囲に含まれることも当然である。
【0050】
【発明の実施の形態】
以下、この発明の実施例について説明する。
【0051】
[実施例1]
[全体の構成]
図1は本発明を適用した実施例の構成図である。本実施例は、コンピュータ・携帯端末・ICカード、その他専用のデバイス・専用端末から構成され、これらが協調して動作することで電子チケットの発行・流通・検証を行う。
【0052】
図1において、110は電子チケットを生成して発行する電子チケット生成装置である。
【0053】
120は、ユーザに帰属するクライアント装置であり、パーソナルコンピュータやワークステーション、携帯電話やPDA等の携帯型端末、演算機能を内蔵したICカード(スマートカード)などの上に実装されるプログラムである。
【0054】
130はアプリケーション装置であり、電子チケット201を検査することによりユーザのアクセス権を検査し、検査が成功した場合に限ってコンテンツの復号などのサービスをユーザに提供する。アプリケーション装置130は、クライアント装置120と同一の機器上で実現されても、また、異なる機器上に実現されてもよい。
【0055】
さて、電子チケット生成装置110は、クライアント装置120を特定して、電子チケット201を生成する。電子チケット201は特定のユーザによるサービスへのアクセス権を表現するデータであることから、電子チケット生成装置110は該ユーザを他のユーザから区別できる必要がある。本発明では、該ユーザが所有するクライアント装置120を特定する特定情報202を、電子チケット生成装置110が利用することでこの目的を果たす。
【0056】
さて、本発明を構成する要件の第一は、電子チケット生成装置110が、クライアント装置120の特定情報202を管理するデータベースなどを独自に保持することはせず、公開された手続きを介して外部から必要に応じて取得する点にある。このために、電子チケット生成装置110は、特定情報取得手段111を内部に保持する。特定情報取得手段111は、例えば、インターネット上の電子メールシステムであったり、ディレクトリサーバに接続するためのネットワーク接続プログラム並びに通信デバイスであったりする。
【0057】
一方、アプリケーション装置130が電子チケットを検査するに当たっては、クライアント装置120と通信を行う。アプリケーション装置130が電子チケット201を検査する目的は、特定のユーザが該アプリケーション装置130の提供するサービスに対するアクセス権を保有していることを検査する点にあり、言い換えるならば、該電子チケット201が該ユーザに帰属することを検査する点にあるが、この検査を該ユーザに帰属する固有のクライアント装置と通信を行い、該クライアント装置のみが生成できるデータを取得することで実行する。
【0058】
従って、クライアント装置120とアプリケーション装置130とは、それぞれ相手と通信するための通信手段(2)121、通信手段(1)131を含む。通信手段(2)121、通信手段(1)131による具体的な通信方式は、クライアント装置120とアプリケーション装置130の実施例に依存して、適切なものを選択する。クライアント装置120とアプリケーション装置130が同一のパーソナルコンピュータやワークステーション上のプログラムとして実現される場合、例えば、クライアント装置120はダイナミックリンクライブラリ(DLL)やコム(COM)として実装され、アプリケーション装置130は所定のアプリケーションプログラムインターフェース(API)を介した関数呼び出しによりクライアント装置120と通信するように構成することができる。クライアント装置120とアプリケーション装置130とがネットワークを介して接続している場合、リモートプロシージャコール(RPC)やHTTPなどを介して通信が行われる。クライアント装置120が特殊なデバイスである場合は、それぞれのデバイスの機能や仕様に応じた通信手段が選ばれる。ICカードであればISO7816準拠の通信プロトコル、携帯端末ではIrDA(Infra Red Data Access)、Bluetooth(商標)、IEEE802.11bなどの赤外線や無線による通信プロトコルが利用される。
【0059】
[クライアント装置の特定情報の取得の例]
アプリケーション装置130は、電子チケットを検査することで、特定のユーザが特定のリソース或いはサービスに対するアクセス権を有しているか検査する。仮に、電子チケットが正しいアクセス権を有するユーザ以外のユーザの手に渡った場合においても、アプリケーション装置130は電子チケットを検査することで、該ユーザが正当なユーザでないことを検知して、アクセスを拒否しなければならない。
【0060】
アプリケーション装置130は、例えば、図6〜図8に示すように構成でき、通信手段(1)131の他に、秘密鍵保持手段132、電子チケット保持手段133、アクセス権認証手段134、コマンド発行手段136等を有している。
【0061】
この機能を実現するために、本発明では、少なくともアプリケーション装置130が電子チケットを検査する時点において、正当なアクセス権を保有するユーザが保持するクライアント装置120に、該クライアント装置120に固有であり、かつ、外部に知られることのない秘密情報を保持せしめると同時に、電子チケットを該秘密情報に依存するように生成する。アプリケーション装置130は、該秘密情報、または、該秘密情報を用いて計算されるデータを、通信手段(1)131を介してクライアント装置120から取得し、該秘密情報、もしくは、該通信データに基づいて電子チケットを検査する。電子チケットは、該秘密情報に依存するように構成されるので、アプリケーション装置130が、該秘密情報、もしくは、該秘密情報から計算されるデータにアクセスできない限り、電子チケットの検査に成功することはない。本実施例では、該秘密情報を、認証情報と呼ぶことにする。
【0062】
電子チケットを生成するに当たって、該クライアント装置120を特定して前記認証情報を保持せしめることを目的として、電子チケット生成装置110はクライアント装置120の特定情報202を使用する。
【0063】
一方、特定情報202の正当性、即ち、特定情報202がどのユーザのクライアント装置を特定するかを知らしめる機能は、必ずしも、特定情報202に具備されない。この機能は、PKIなど、外部の仕組みで実現することが可能であるからであり、リソースやサービスの特性によって適切なものを選択することができる。
【0064】
以下では、前述の全体構成に基づき、電子チケット生成装置110がクライアント装置120の特定情報202を取得する方法について、より具体的な実施例を示す。
【0065】
電子チケット生成装置110による特定情報202の取得方式は、電子チケット生成装置110がクライアント装置120から特定情報202を取得する方式と、電子チケット生成装置110がクライアント装置120の特定情報202が登録されている第三者機関(ディレクトリサービスなど)から取得する方式とに大別される。
【0066】
図2〜図5は、電子チケット生成装置110がクライアント装置120から特定情報を取得する方式の構成を示している。クライアント装置120は特定情報生成手段122を含み、該手段により特定情報202を生成して電子チケット生成装置110に提供する。
【0067】
電子チケット生成装置110は、必ずしもネットワークなどの通信手段を使って特定情報202を取得する必要はなく、たとえば、フロッピーディスクに記録されたり、バーコードなどに準拠して印刷された形式を受け取って処理してもよいので、電子チケット生成装置110とクライアント装置120との間の通信手段は設けない。
【0068】
該クライアント装置120の特定情報は、該クライアント装置120が保持する秘密情報に依存して生成されるが、該秘密情報は、該クライアント装置120に固有かつ固定のデータである場合と、動的に生成される使い捨てのデータである場合の両様がありえる。
【0069】
前者の典型的な例は、前記秘密情報が、該クライアント装置120の製造業者が付与する識別番号や暗号の秘密鍵のような場合である。
【0070】
一方、後者の典型的な例は、前記秘密情報が、該クライアント装置120固有の方式で生成されるシリアル番号や都度生成される乱数である場合である。
本発明の目的を達するための要件の一つとして、電子チケット生成装置110は特定情報を必ずしも安全ではないチャネルを介して、公開の手続きで取得できなければならない。そのため、秘密情報がクライアント装置120固有でかつ固定的である場合はいうに及ばず、シリアル番号や乱数のような都度使い捨てられる場合であっても、クライアント装置120が詐称される(成りすまされる)ことを防ぐために、特定情報から秘密情報が漏れることがあってはならない。
【0071】
この要件を満足するような特定情報の構成例のひとつは、クライアント装置120の前記秘密情報を、例えば、電子チケット生成装置110に帰属する公開鍵暗号の公開鍵を用いて暗号化したデータを、特定情報202とする場合である。
【数1】
特定情報=暗号化関数電子チケット生成装置の公開鍵(クライアント装置の秘密情報)
【0072】
この構成方法例では、クライアント装置120は、電子チケット生成装置110の公開鍵を取得する必要がある。該公開鍵はクライアント装置の中に予め格納しておいたり、公開鍵証明書のように認証機関によって裏書きされた形式で都度クライアント装置120に入力するなどの方法で供給する。
【0073】
一方、公開鍵のような電子チケット生成装置110に依存する情報を利用しない方法もある。
【0074】
例えば、Diffie−Hellman鍵交換アルゴリズムを用いる方法である。以下では、表記の都合から、楕円曲線を公開鍵暗号利用におけるベースの群とするが、本発明に関する説明において、楕円曲線暗号に基づく設定に限定する意図は全くない。例えば、体の乗法群をもちいるような場合は、加法と乗法を、スカラー倍と冪乗を読み替えれば、以下に述べる例はそのまま乗法群上の例と解釈することができる。
【0075】
以下の実施例においては、楕円曲線E上で十分大きな位数をもつ点Gを基点として定めておき、クライアント装置120は、図10に記載の手順で特定情報を生成する。
【0076】
[ステップ1]:(511)Gの位数より小さい正の整数rをランダムに生成する。
[ステップ2]:(512,513)楕円曲線E上で、R=rGを計算し、Rを特定情報とし、電子チケット生成装置に送付する。
【0077】
一方、電子チケット生成装置110は、次の手順で電子チケットを生成する。[ステップ1]:(514)Gの位数より小さい正の整数r’をランダムに生成する。
[ステップ2]:(515,516)楕円曲線E上で、K=r’Rを計算し、Kに依存するように電子チケットを生成する。
[ステップ3]:(517,518)R’=r’Gを計算し、R’を電子チケットに添付して発行する。
【0078】
クライアント装置120はrを保持しておき、R’(=r’G)が入力された段階で、K=rR’(=rr’G)を計算する。このKが認証情報となる。
クライアント装置120は、アプリケーション装置130との通信に際して、Kを用いた計算により通信データを生成する。認証情報Kは、rを知っている該クライアント装置120のみが計算しえる値であるので、アプリケーション装置130は正しいクライアント装置120を他のクライアント装置から区別できるのである。
【0079】
また、電子チケット生成装置110の公開鍵を用いない別の例として、一方向性ハッシュ関数を利用する方法も存在する。一方向性ハッシュ関数は、「出力から入力を求める計算量が極めて大きく、そのため、実用的には出力から入力を推測することは不可能である」という性質をもつ関数である。米国連邦政府調達規格(FIPS)で規定されているSHA−1(Secure Hash Algorithm)は、世界的に広く利用されている一方向性ハッシュ関数の実例である。
【0080】
この場合、クライアント装置120は、電子チケット毎に使い捨ての秘密情報を生成し、それに一方向性ハッシュ関数を施した結果を特定情報とする。
【数2】
特定情報=一方向性ハッシュ関数(クライアント装置の使い捨ての秘密情報)
【0081】
一方向性ハッシュ関数の特性により、特定情報から秘密情報を得ることはできない。一方、クライアント装置120はアプリケーション装置130と通信を行う際に、該使い捨ての秘密情報を提示する。アプリケーション装置130は、受信した該秘密情報に同じ一方向性ハッシュ関数を施し、電子チケットが得られたハッシュ値に依存して生成されていることを検査する。この例では、クライアント装置120が生成した該秘密情報が認証情報となる。
【0082】
ここまでで述べた特定情報の実施例では、電子チケット生成装置110が特定情報の正当性を確認する手段が提供されない。即ち、クライアント装置120が意図するユーザに帰属するクライアント装置の特定情報であることを保証する機能は提供されない。特定情報の正当性を検証するための手段は別途与えられることを前提とするが、この手段は、電子チケット生成装置110がクライアント装置120を所持するユーザを識別する際のポリシーに強く依存する。
【0083】
例えば、電子チケット生成装置110が、対価を支払ったユーザに対しては無条件に電子チケットを発行するというポリシーをもっていた場合、特定情報は一旦決済機関に送付され、該決済機関において対価の支払いが確認された時点で、該決済機関が該特定情報に電子署名を施して、電子チケット生成装置110に送付するという構成がありえる。
【0084】
別の例としては、電子チケット生成装置110がユーザの身許を確認した後に電子チケットを発行するポリシーを採用している場合、ユーザが特定情報に電子署名を施し、電子チケット生成装置110はユーザの公開鍵証明書により署名を検査して電子チケットの発行の可否を判断するという構成がありえる。
【0085】
前記2例では、特定情報の正当性を確認する手段を電子チケット生成装置110及びクライアント装置120の外部に設けたが、内部に設ける方法も可能である。
【0086】
特定情報の正当性を内部的に保証する方法のもっとも典型的な実施例は、クライアント装置120の公開鍵、より実際的には、該公開鍵を含む公開鍵証明書を特定情報として利用す方法である。この場合、クライアント装置120は、該公開鍵に対応する秘密鍵(個人鍵、私有鍵、プライベート鍵などともいう)を保持する秘密情報保持手段(秘密鍵保持手段)123を含む。
【0087】
例えば、電子チケットに該公開鍵を含めておき、クライアント装置120が秘密情報保持手段123に保持されている秘密鍵を用いて生成したデータを、アプリケーション装置130が電子チケットに含まれる該公開鍵を用いて検査する方法である。この例では、クライアント装置120の秘密鍵が認証情報として用いられる。
【0088】
また、電子チケット生成装置110が、認証情報となる共有鍵kを生成し、kをクライアント装置120の公開鍵で暗号化した暗号化データを生成し、該暗号化データを電子チケットとともに発行する方法も可能である。クライアント装置120は、該暗号化データの入力を受けて、秘密情報保持手段123に保持されている秘密鍵を用いてkを復号し、アプリケーション装置130との通信においてkを用いて通信データを生成する。
【0089】
先述したように、クライアント装置120の公開鍵を特定情報とする方法の最大の利点は、公開鍵証明書(ITU−T X.509など)と公開鍵インフラ(PKI)の仕組みを用いたインフラを、電子チケット生成装置110が特定情報202の正当性を確認する手段として利用できることから該機能を外部に求める必要がない。公開鍵インフラは、認証局が公開鍵に裏書きすることで公開鍵の正当性を保証する仕組みであることから、電子チケット生成装置110は偽のクライアント装置120によるなり済ましの危険を排除することが可能となる。
【0090】
一方、上記の方法を組み合わせて、特定情報202を、クライアント装置120の公開鍵とクライアント装置120が部分特定情報生成手段124を利用して生成する動的な部分特定情報とから構成するようにもできる。
【0091】
例えば、変形Menezes−Qu−Vanstone鍵交換アルゴリズムを用いて、図11に記載の手順で特定情報を構成することができる。
【0092】
クライアント装置120は、特定情報を生成する。
[ステップ1]:(521)基点Gの位数より小さい正の整数rをランダムに生成する。
[ステップ2]:(522、523)楕円曲線E上で、R=rGを計算し、Rを部分特定情報とする。
【0093】
一方、電子チケット生成装置110は、図11に記載の手順で電子チケットを生成する。
[ステップ1]:(524)クライアント装置120の公開鍵であるE上の点PとRとを併せて特定情報とする。
[ステップ2]:(525)Gの位数より小さい正の整数r’をランダムに生成する。
[ステップ3]:(526)楕円曲線E上で、K=r’(R+π(R))Pを計算し、Kに依存するように電子チケットを生成する。但し、π(R)はRのx座標から所定の方法で計算される正の整数である。
[ステップ4]:(527,528)R’=r’Gを計算し、R’を電子チケットに添付して発行する。
【0094】
クライアント装置120はrを保持しておき、R’(=r’G)の入力を受けた段階で、認証情報Kを、次式のように計算する。
【数3】
(r+π(R)p)R’=(r+π(R)p)(r’G)
=((r+π(R)p)r’)G=r’R=K
【0095】
クライアント装置120は、アプリケーション装置130との通信に際して、Kを用いた計算により通信データを生成する。
【0096】
但し、pは公開鍵Pに対応する秘密鍵で、楕円曲線E上でP=pGを満足する。
【0097】
認証鍵Kはrとpとを知っている該クライアント装置120のみが計算しえる値であるので、アプリケーション装置130は正しいクライアント装置120を不正なクライアント装置から区別できるのである。
【0098】
[電子チケットの構成方法の例]
電子チケットは、ユーザによるサービスへのアクセスに関する種々の属性、例えば、有効アクセス期限(アクセス開始期日、アクセス終了期日)、有効アクセス回数、クライアントの特定情報、サービスの特定情報、その他、アプリケーション装置130が解釈し実行する種々のルールを指定する属性を含む。この属性の中には、アプリケーション装置130が実行するスクリプトのようなプログラムを含めることもできる。
【0099】
さて、電子チケットに求められる安全性に関しては、以下の2点の要請が重要である。
【0100】
(ア)アプリケーション装置130は、前記属性を含む電子チケットに対する改竄を検知できること。
(イ)アプリケーション装置130は、正当なクライアント装置120を認証できること。正当なクライアント装置120とは、電子チケット生成装置110が該電子チケットを生成する際に参照した特定情報202に対応するクライアント装置120を指す。
【0101】
特定情報の生成方法に関する前述の例のいくつかに基づいて、上記要件を満足する電子チケットの構成方法を例示する。
【0102】
特定情報が、クライアント装置120が保持する使い捨ての秘密情報と一方向性ハッシュ関数から生成される場合、電子チケットは、例えば、以下のように構成することができる。
【数4】
【0103】
アプリケーション装置130は、電子チケット生成装置110による電子署名を検査することで、電子チケットが改竄されているかを検査することができる。この場合、アプリケーション装置130は、電子チケット生成装置110の署名検証用の公開鍵を何らかの手段で取得している必要がある。
【0104】
次いで、アプリケーション装置130は、現在サービスへのアクセスを要求しているユーザが、電子チケット生成装置110が意図している正しいユーザであることを確かめるために、該ユーザが保持するクライアント装置120と通信を行う。
図12は、検証の手順である。
[ステップ1]:(611,612)クライアント装置120は、特定情報を生成する際に使用した使い捨ての秘密情報を、アプリケーション装置130に送付する。
[ステップ2]:(613)アプリケーション装置は、
【数5】
指定されている特定情報=一方向性ハッシュ関数(受信した秘密情報)
が成立するかを検査する。
[ステップ3]:(614)検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【0105】
ここで、一方向性ハッシュ関数としては、SHA−1のような公知の関数を用いるので、アプリケーション装置130は、電子チケット生成装置110、クライアント装置120のいずれとも秘密情報を共有することなく、上記アクセス権の検査を実行することが可能となる。
【0106】
一方向性ハッシュ関数を用いた特定情報に基づく電子チケットの別の実施例として、電子チケットの属性データを、電子チケット生成装置110が受け取った特定情報を鍵として暗号化する方法がある。
【数6】
【0107】
アプリケーション装置による電子チケットの検査は図13のように実行される。
[ステップ1]:(621,622)クライアント装置120は、特定情報を生成する際に使用した使い捨ての秘密情報を、アプリケーション装置130に送付する。
[ステップ2]:(623)アプリケーション装置130は、
【数7】
復号鍵=一方向性ハッシュ関数(受信した秘密情報)
により復号鍵を計算する。
[ステップ3]:(624,625)前記復号鍵を用いて電子チケットを復号し、
【数8】
復号鍵=電子チケットに指定されたクライアント装置の特定情報
を検査して、電子チケットが正しく復号されていることを確認する。
[ステップ4]:(626)検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【0108】
ここまでに述べた例の特定情報の実施例のうち、電子チケット生成装置110の公開鍵で暗号化した鍵kをクライアント装置120が送付する構成例、クライアント装置120の公開鍵で暗号化した鍵kを電子チケット生成装置110が送付する構成例、Diffie−Hellman鍵交換アルゴリズムを利用した構成例、及び、変形Menezes−Qu−Vanstone鍵交換アルゴリズムを用いた構成例では、クライアント装置120のみではなく、電子チケット生成装置110も認証情報を共有する。
例えば、特定情報が
【数9】
特定情報=暗号化関数電子チケット生成装置の公開鍵(クライアント装置の認証情報)
と定義される場合には、電子チケット生成装置110は自らの秘密鍵を用いて特定情報を復号することにより、クライアント装置120が生成した認証情報を共有することとなる。
【0109】
Diffie−Hellman鍵交換アルゴリズム、及び、変形Menezes−Qu−Vanstone鍵交換アルゴリズムに基づく例では、認証情報Kは、クライアント装置120がR’を受け取った時点で、電子チケット生成装置110とクライアント装置120との間で共有されることとなる。
【0110】
電子チケット生成装置110とクライアント装置120との間で認証情報が共有されるとき、認証情報を特に共有鍵と呼ぶこととする。
電子チケット生成装置110とクライアント装置120との間で共有される共有鍵を、少なくとも鍵の一部として使って得られる暗号化データを電子チケットの定義とすることができる。
【0111】
最も、原始的な例としては、
【数10】
と定義する方法である。
【0112】
図14は、検証手順である。
[ステップ1]:(631)アプリケーション装置130は電子チケットをクライアント装置120に送付する。
[ステップ2]:(632)クライアント装置120は共有鍵Kを用いて電子チケットを復号し、アプリケーション装置130に送付する。
[ステップ3]:(634)アプリケーション装置130は、送付されたデータが、正しい平文であるかを検査する。
[ステップ4]:(635)検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【0113】
次に、共有鍵Kを用いた暗号化により電子チケットを生成する方法で、安全上ならびに機能上のより高度な要請に応える方法を述べる。
【0114】
前提として、サービスは該サービスに固有の公開鍵Sと緊密に対応付けられているものとする。例えば、サービスがデジタルコンテンツである場合、コンテンツデータを公開鍵Sによって暗号化しておく。このような処置を施すことにより、公開鍵Sに対応する秘密鍵sによる復号計算を何らかの形で実行しない限り、コンテンツデータにアクセスすることができないようにすることができる。以下の記述では、楕円曲線上の公開鍵暗号を仮定し、S=sGが成り立つものとするが、一般の公開鍵暗号でも同様の構成が可能である。
【0115】
さて、電子チケットは次のように定義される。
【数11】
【0116】
上記の定義中の電子チケット鍵は以下のように定義する。
【0117】
以下、表記の簡明のために、次の記号を用いる。
【数12】
t:電子チケット鍵
S:サービスに割り当てられた公開鍵
s:Sに対応する秘密鍵、楕円曲線E上でS=sGを満たす
K:電子チケット生成装置110とクライアント装置120の間で共有する共有鍵
TcktDef:サービスの識別子、アクセスの有効期限・有効回数、その他のアクセスに関するルールなど、電子チケットの属性から構成されるデータ
ApplDef:アプリケーション装置130を認証するための方法、アプリケーション装置130の特権など、アプリケーション装置のの属性から構成されるデータ(後述)
H|s|( ):秘密鍵sと同じサイズ(ビット長)の出力を返す一方向性・非衝突ハッシュ関数
t=s−H|s|(ApplDef|TcktDef|K)
ApplDefの役割に関しては後述する。
tは、秘密鍵sをH|s|(ApplDef|TcktDef|K)を鍵として暗号化したものであり、Kの値がわからないと鍵を計算することができない。
さて、コンテンツデータCをElGamal暗号によって暗号化したデータを(A,B)とおく。即ち、
【数13】
が成り立つ。但し、ξ(aS)は楕円曲線上の点aSのx座標であるとする。
(A,B)はコンテンツデータに添付されて、アプリケーション装置130に与えられる。
アプリケーション装置130とクライアント装置120との間の通信は、図15に従って、実行される。
【0118】
[ステップ1]:(641)アプリケーション装置130はAをクライアント装置120に送付する。
[ステップ2]:(642,643)クライアント装置120は、H|s|(ApplDef|TcktDef|K)を計算し、
【数14】
R=H|s|(ApplDef|TcktDef|K)A
をアプリケーション装置130に送付する。
[ステップ3]:(644)アプリケーション装置130は、
【数15】
aS=tA+R
を計算し、
【数16】
によりCを復号する。aS=tA+Rが成り立つことは、
【数17】
から分かる。
【0119】
上記の方法が満足する安全上の特徴は以下である。
【0120】
1、サービス提供者の秘密である秘密鍵sが、アプリケーション装置130に対しても、クライアント装置120に対しても開示されない。
【0121】
2、ApplDef或いはTcktDefが改竄され、ApplDef’及びTcktDef’が与えられると、
【数18】
)となり、aSと一致しない。従って、コンテンツデータCをアプリケーション装置130はコンテンツデータを復号することができない。
【0122】
3、クライアント装置120が共有鍵Kを知らず、異なる鍵K’を計算に使用すると、
【数19】
となり、aSと一致しない。従って、コンテンツデータCをアプリケーション装置130はコンテンツデータを復号することができず、ユーザはサービスを享受することができない。
【0123】
機能上の特徴を述べると、電子チケットのデータ中に、TcktDefにあたる情報が電子チケット中で平文で現れるため、電子チケットが共有鍵Kによる暗号文である例の場合とは異なり、クライアント装置120による復号を待たず属性の評価を実施することができる。
【0124】
なお、電子チケット生成装置110は、図5に示すように、特定情報取得手段111の他に、例えば、鍵共有手段(1)112、鍵共有データ生成手段113、秘密情報保持手段(2)114を有し、種々の態様で特定情報を取得して電子チケットを生成できる。
【0125】
[アプリケーション装置の認証]
前記のように、アプリケーション装置130はクライアント装置120と通信することで、該クライアント装置120を所有するユーザがサービスに対するアクセス権を有することを検証する。このとき、電子チケットに記載される様々なアクセスに関する属性が改竄されていないことも併せて検証される。
【0126】
一方、サービスの提供者には、予め認定したアプリケーション装置130以外による上記通信の実行を阻止したいという要請がある。コンテンツデータCを復号する例を見れば明らかなように、上記通信を実行することにより、サービスの提供者の秘密情報であるコンテンツデータCが現れるからである。
【0127】
この目的のために、アプリケーションの設定データApplDefが用いられる。
【0128】
一義的には、ApplDefには、アプリケーション装置130をクライアント装置120が認証するための方法が記述される。
【0129】
具体的な例としては、アプリケーション設定データ中にアプリケーション装置130の公開鍵を指定することができる。クライアント装置120は、アプリケーション設定データ中の公開鍵を利用することで、アプリケーションを認証することができる。
【0130】
一方、サービスの提供者は、電子チケット中の電子チケット鍵tを計算する時にアプリケーション設定データを計算に含めることにより、該電子チケットによる認証の結果サービスをユーザに提供するアプリケーション装置130を特定することができる。
【0131】
クライアント装置120へのアプリケーション設定データの供給方式は自由である。アプリケーション装置130がクライアント装置120と通信する際に、自らに関する設定データを入力してもよいし、クライアント装置120がアプリケーション装置130を介さずに事前に取得しておく方法でもよい。ただし、いずれの場合も、少なくともアプリケーション装置130と通信を行う間、該アプリケーション設定データを保持しておく設定データ保持手段125が必要である。これは、例えば、メモリ上の一時記憶領域でもよい。
【0132】
以下では、(1)と同じ電子チケット鍵に従うが、ElGamal暗号とは別の公開鍵暗号アルゴリズムに基づいて、クライアント装置120によるアプリケーション装置130の効率的な認証の実施例について述べる。
【0133】
ここでベースとする公開鍵暗号アルゴリズムは、Schnorr零知識識別アルゴリズムと呼ばれるものである。ElGamal暗号とは異なり、コンテンツデータなどを暗号化する機能は提供せず、認証に限定して利用されるが、計算量が極めて小さく、スマートカードなど演算能力に制約のある実装で威力を発揮する公開鍵暗号アルゴリズムである。
【0134】
アプリケーション設定データには、アプリケーション装置130の公開鍵Aが記載されており、他方、アプリケーション装置130は秘密鍵保持手段132を含み、秘密鍵保持手段132に公開鍵Aに対応する秘密鍵aを保持する。楕円曲線E上で、
【数20】
A=aG
が成立する。
【0135】
クライアント装置120とアプリケーション装置130は、図16に記載の手順で、通信を実行する。
【0136】
[ステップ1]:(701,702,703)クライアント装置120は、基点Gの位数より小さい乱数wを生成し、楕円曲線E上の点W=wGを計算して、アプリケーション装置130に送付する。
[ステップ2]:(704,705,706,707)アプリケーション装置130は、乱数cを生成するとともに、メッセージ認証鍵kをk=ξ(aW)により計算する。次いで、kを鍵として乱数cに対するメッセージ認証コード(MAC、Message Authentication Codes)MAC(k,c)を計算し、cとMAC(k,c)の組をクライアント装置120に送付する。
[ステップ3]:(708,709)クライアント装置120は、アプリケーション設定データ中に指定されているアプリケーション装置130の公開鍵Aを取り出し、k’=ξ(wA)によりメッセージ認証鍵k’を計算する。次いで、
【数21】
MAC(k,c)=MAC(k’,c)
を検査し、検査が成功しなかった場合、以後の処理を行わない。
(710,711)メッセージ認証コードの検査が成功した場合、クライアント装置120は
【数22】
r=H|s|(ApplDef|TcktDef|K)c+w
を計算し、アプリケーション装置130に送付する。
(712)アプリケーション装置130は、楕円曲線Eの上で
【数23】
(ct+r)G=cS+W
が成立することを検査する。
【0137】
アプリケーション装置130が、アプリケーション設定データに記載されている公開鍵Aに対応する秘密鍵aを保持している場合、k=k’が成り立ち、上記ステップ3においてメッセージ認証コードの検査に成功する。これは、
【数24】
aW=a(wG)=(aw)G=w(aG)=wA
が成り立つことによる。
【0138】
逆に、秘密鍵aを知らずに、A=aGが得られて、楕円曲線E上の点Wに対してそのa倍を計算することができるかという問題は、Diffie−Hellman問題と呼ばれ、計算量的に解決不可能であるとされている。従って、秘密鍵aを正しく保有するアプリケーション装置130以外がクライアント装置120と通信を行おうとした場合、確実に、ステップ3において拒否される。
【0139】
一方、アプリケーション設定データApplDefを改竄して、虚偽のアプリケーション装置130が保持している秘密鍵a’に対応する公開鍵A’を書き込んだApplDef’をクライアント装置120に入力した場合、クライアント装置120は正しいrを計算することができない。
【0140】
アプリケーション設定データ中の公開鍵を書き換える攻撃手法は、虚偽のアプリケーション装置が、正しいアプリケーション装置130とクライアント装置120の間に割り込み、クライアント装置120と通信することで、正しいアプリケーション装置に対してなりすましを図る、Man−In−The−Middleとよばれる攻撃に用いられる。
【0141】
[電子チケットに対する操作]
本実施例では、特権を有するアプリケーション装置130が、正当なクライアント装置120と協力して、存在する電子チケットの状態を多様に変更する機能を提供する。具体的には以下の機能を提供する。
【0142】
[無効化] 現在の電子チケットを無効化し、今後、該電子チケットを用いたアクセス権の検査が必ず失敗するようにする。該電子チケットで表現されているユーザのサービスに対するアクセス権を無効化する目的に用いる。
【0143】
[譲渡] 現在の電子チケットを無効化するとともに、現在のクライアント装置と異なる別のクライアント装置によるアクセス権の検査を成功させる、新しい電子チケットを生成する。現在の電子チケットで表現されているアクセス権を、異なるクライアント装置を所有する他のユーザに譲渡する目的に用いる。
【0144】
[分割] 電子チケットを無効化するとともに、新しい電子チケットを二つ以上生成する。即ち、現在の電子チケットで表現されているアクセス権を、二つ以上の独立のアクセス権に分割する目的に用いる。
【0145】
[変更] 現在の電子チケットを無効化するとともに、サービスへのアクセスに関する異なるルールに従う新しい電子チケットを生成する。例えば、有効利用回数を減じるなど、サービスへのアクセスに伴い、次回以降のサービスへのアクセスの条件が変更した時、その変更を電子チケットに反映させる目的に用いる。
【0146】
ここで、重要な性質は、上記機能は、サービスの提供者を煩わせることなく、特権を有するアプリケーション装置130とクライアント装置120との間で、完結して実行される点である。
【0147】
上記性質を満たすように上記機能を提供することにより、「発明が解決しようとする課題」の節で述べたような「アクセス権の多様な流通フローへの対応」を可能とする。
【0148】
電子チケットが、
【数25】
t=s−H|s|(ApplDef|TcktDef|K)
と定義される場合を例にとって、前記機能の具体的な実現方法を述べる。
【0149】
[無効化の具体例]
共有鍵Kがクライアント装置120内に生成されるタイミングは、Kの生成方法によって異なる。電子チケットの生成時に、クライアント装置120がKを生成し、電子チケット生成装置の公開鍵で暗号化して特定情報とする実施例では、クライアント装置120は電子チケットの生成時点で共有鍵Kを保持することとなる。一方、R=rGを計算して、特定情報或いは部分特定情報として用いる実施例では、電子チケット生成装置110が電子チケットとともに生成するR’=r’Gが入力された時点で、クライアント装置120はK=rR’又はK=(r+π(R)p)R’によって共有鍵Kを計算する。
【0150】
しかしながら、どちらのケースでも、クライアント装置120はアプリケーション装置130との通信時には、共有鍵を共有鍵保持手段126に保持しており、通信時に共有鍵Kを用いて通信データを生成する。逆に、この共有鍵Kなしでは、クライアント装置120は、アプリケーション装置によるアクセス権認証を成功せしめる通信データを生成することができない。共有鍵保持手段126の共通鍵は共通鍵保護手段127によりセキャアに保護される。
【0151】
この性質を用いて、電子チケットの確実な無効化が可能となる。即ち、クライアント装置120は、共有鍵保持手段126に保持されている共有鍵Kを消去することにより、Kに依存して生成された電子チケットを完全に無効化することができるのである。
【0152】
前記、電子チケットの無効化は、無効化を実行する特権を有するアプリケーション装置130の指示によって実行される。
【0153】
具体的には、アプリケーション装置130は、コマンド発行手段136を含み、通信手段(1)131を介して、クライアント装置120に無効化のコマンドを送付し、一方、クライアント装置120は通信手段(2)121を介して無効化のコマンドを受け取り、更に、コマンド受理手段137においてコマンドを解釈する。
【0154】
前記のSchnorr零知識識別アルゴリズムに基づくクライアント装置120とアプリケーション装置130との通信手続きを例にとって、図17の記載に従って、無効化のコマンドの発行・受理・実行の手順を説明する。
【0155】
[ステップ1]:(801,802,803)クライアント装置120は、基点Gの位数より小さい乱数wを生成し、楕円曲線E上の点W=wGを計算して、アプリケーション装置130に送付する。
[ステップ2]:(804,805,806,807)アプリケーション装置130は、乱数cを生成するとともに、メッセージ認証鍵kをk=ξ(aW)により計算する。
更に、電子チケットの無効化コマンド“revoke”と乱数cを合わせてメッセージとし、kを鍵としてメッセージ認証コード(MAC、Message Authentication Codes)
【数26】
MAC(k,“revoke”|c)
を計算し、“revoke”とcとMAC(k,“revoke”|c)とをクライアント装置120に送付する。
[ステップ3]:(808,809,810)クライアント装置120は、アプリケーション設定データ中に指定されているアプリケーション装置130の公開鍵Aを取り出し、k’=ξ(wA)によりメッセージ認証鍵k’を計算する。次いで、
【数27】
MAC(k,“revoke”|c)=MAC(k’,“revoke”|c)
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ApplDefを参照し、公開鍵Aに対応付けられているアプリケーション装置に電子チケットを無効化する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
[ステップ4]:(811,812,813)メッセージ認証コードの検査が成功した場合、クライアント装置120は
【数28】
r=H|s|(ApplDef|TcktDef|K)c+w
を計算し、アプリケーション装置130に送付する。同時に、共有鍵保持手段126に保持されている共有鍵Kを消去し、電子チケットを無効化する。
[ステップ5]:(814)アプリケーション装置130は、楕円曲線Eの上で
【数29】
(ct+r)G=cS+W
が成立することを検査する。
【0156】
[譲渡の具体例]
Schnorr零知識識別アルゴリズムに基づく実施例を例にとり、譲渡のコマンドの発行・受理・実行の手順に関し、図18の記載に従って述べる。
【0157】
クライアント装置120(A)は、差分データ生成手段128及び外部特定情報保持手段129を含む。なお譲渡もとのクライアント装置120を(A)で表し、譲渡先のクライアント装置120を(B)で表す。
【0158】
[ステップ1]:(901,902,903)クライアント装置120(A)は、基点Gの位数より小さい乱数wを生成し、楕円曲線E上の点W=wGを計算して、アプリケーション装置130に送付する。
[ステップ2]:(904,905,906,907,908)アプリケーション装置130は、乱数cを生成するとともに、メッセージ認証鍵kをk=ξ(aW)により計算する。更に、電子チケットの譲渡コマンドはコマンド名“transfer”と譲渡先のクライアント装置120(B)の特定情報を与えるパラメータClientIdとから構成される。アプリケーション装置130は上とコマンドと乱数cを合わせてメッセージとし、kを鍵としてメッセージ認証コード(MAC、Message Authentication Codes)
【数30】
MAC(k,“transfer”|ClientId|c)
を計算し、“transfer”とClientIDとcとMAC(k,“transfer”|ClientId|c)とをクライアント装置120に送付する。
[ステップ3]:(909,910,911)クライアント装置120(A)は、アプリケーション設定データ中に指定されているアプリケーション装置130の公開鍵Aを取り出し、
【数31】
k’=ξ(wA)
によりメッセージ認証鍵k’を計算する。次いで、
【数32】
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ApplDefを参照し、公開鍵Aに対応付けられているアプリケーション装置に電子チケットを譲渡する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
[ステップ4]:(912)クライアント装置120(A)はClientIdを外部特定情報保持手段129に保持する。
[ステップ5]:(913,914)クライアント装置120(A)は、差分データ生成手段128に外部特定情報保持手段129が保持している外部のクライアント装置120(B)の特定情報を入力する。差分データ生成手段128は、電子チケット生成装置とクライアント装置との間で行う鍵共有と同じ方法で、外部のクライアント装置120(B)との間の共有鍵K1を生成し、次式により差分データΔを計算する。
【数33】
[ステップ6]:(915,916,917)クライアント装置120(A)は、
【数34】
r=H|s|(ApplDef|TcktDef|K)c+w
を計算し、アプリケーション装置130に送付する。同時に、共有鍵保持手段126に保持されている共有鍵Kを消去し、電子チケットを無効化する。
[ステップ7]:(918)アプリケーション装置130は、楕円曲線Eの上で
【数35】
(cT+r)G=cS+W
が成立することを検査する。
【0159】
差分データΔは、オリジナルの電子チケット鍵t
【数36】
t=s−H|s|(ApplDef|TcktDef|K)
から、新たな電子チケットt1を生成する目的で使用される。すなわち、
【数37】
は、クライアント装置120(B)が計算可能な共有鍵K1による新たな電子チケットである。共有鍵K1は、外部のクライアント装置120(B)の共有鍵保持手段によって保持されるため、アプリケーション装置130は、電子チケット鍵t1に基づいて、クライアント装置120(B)と通信することで、クライアント装置120(B)を所有するユーザが該サービスに対するアクセス権を保持していることを検査することができるようになる。
【0160】
前記の新たな電子チケット鍵の計算は、いかなる方法で実行してもよい。たとえば、以下のような構成が可能である。
【0161】
1、クライアント装置120が通信データrとともにアプリケーション装置130に送付し、アプリケーション装置130が新たな電子チケット鍵t1を計算する。アプリケーション装置は、ユーザのアクセス権を認証するために電子チケット鍵tTを保持しているので、新たな電子チケット鍵t1の計算を実行することができる。
【0162】
2、クライアント装置120がスマートカードのような可搬型デバイスである場合、電子チケットをクライアント装置に記録して携行する態様はきわめて自然である。このようなケースでは、クライアント装置120が新たな電子チケット鍵t1T1を計算することが可能である。
【0163】
[分割の具体例]
Schnorr零知識識別アルゴリズムに基づく実施例を例にとり、分割のコマンドの発行・受理・実行の手順に関し、図19の記載に従って述べる。
【0164】
クライアント装置120は、差分データ生成手段128を含む。
【0165】
[ステップ1]:(1001,1002,1003)クライアント装置120は、基点Gの位数より小さい乱数wを生成し、楕円曲線E上の点W=wGを計算して、アプリケーション装置130に送付する。
【0166】
[ステップ2]:(1004,1005,1006,1007,1008)アプリケーション装置130は、乱数cを生成するとともに、メッセージ認証鍵kをk=ξ(aW)により計算する。
更に、電子チケットの分割コマンドはコマンド名“divide”と分割後の電子チケットの定義データを与える二つのパラメータTcktDef1及びTcktDef2とから構成される。アプリケーション装置130は上とコマンドと乱数cを合わせてメッセージとし、kを鍵としてメッセージ認証コード(MAC、Message Authentication Codes)
【数38】
MAC(k,“divide”|TcktDef1|TcktDef2|c)
を計算し、“divide”とTcktDef1とTcktDef2cとMAC(k,“divide”|TcktDef1|TcktDef2|c)とをクライアント装置120に送付する。
【0167】
[ステップ3]:(1009,1010,1011)クライアント装置120は、アプリケーション設定データ中に指定されているアプリケーション装置130の公開鍵Aを取り出し、k’=ξ(wA)によりメッセージ認証鍵k’を計算する。次いで、
【数39】
MAC(k,“divide”|TcktDef1|TcktDef2|c)
=MAC(k’,“divide”|TcktDef1|TcktDef2|c)
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ApplDefを参照し、公開鍵Aに対応付けられているアプリケーション装置に電子チケットを分割する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
【0168】
[ステップ4]:(1012,1013)クライアント装置120は、差分データ生成手段128にコマンドのパラメータTcktDef1とTcktDef2とを入力する。差分データ生成手段128は、新たな共有鍵K1とK2とを生成し、次式により差分データΔ1及びΔ2を計算する。
【数40】
Δ1=H|s|(ApplDef|TcktDef1|K1)−H|s|(ApplDef|TcktDef|K)
Δ2=H|s|(ApplDef|TcktDef2|K2)−H|s|(ApplDef|TcktDef|K)
【0169】
[ステップ5]:(1014,1015)クライアント装置120は、
【数41】
r=H|s|(ApplDef|TcktDef|K)c+w
を計算し、アプリケーション装置130に送付する。
【0170】
[ステップ6]:(1016,1017)共有鍵保持手段126に保持されている共有鍵Kを消去し、電子チケットを無効化するとともに、共有鍵K1とK2とを共有鍵保持手段126に記録する。
【0171】
[ステップ7]:(1018)アプリケーション装置130は、楕円曲線Eの上で
【数42】
(ct+r)G=cS+W
が成立することを検査する。
差分データΔ1及びΔ2は、オリジナルの電子チケット鍵t
【数43】
t=s−H|s|(ApplDef|TcktDef|K)
から、新たな電子チケット鍵t1を生成する目的で使用される。すなわち、
【数44】
t1= t+Δ1
=s−H|s|(ApplDef|TcktDef|K)+H|s|(ApplDef|TcktDef1|K1)
−H|s|(ApplDef|TcktDef|K)
=s−H|s|(ApplDef|TcktDef1|K1)
t2= t+Δ2
=s−H|s|(ApplDef|TcktDef|K)+H|s|(ApplDef|TcktDef2|K2)
−H|s|(ApplDef|TcktDef|K)
=s−H|s|(ApplDef|TcktDef2|K2)
は、クライアント装置120の共有鍵保持手段126に保持されている共有鍵K1とK2による新たな電子チケットである。
【0172】
[変更の具体例]
Schnorr零知識識別アルゴリズムに基づく実施例を例にとり、変更のコマンドの発行・受理・実行の手順に関し、図20の記載に従って述べる。
【0173】
クライアント装置120は、差分データ生成手段128を含む。
【0174】
[ステップ1]:(1101,1102,1103)クライアント装置120は、基点Gの位数より小さい乱数wを生成し、楕円曲線E上の点W=wGを計算して、アプリケーション装置130に送付する。
【0175】
[ステップ2]:(1104,1105,1106,1107,1108)アプリケーション装置130は、乱数cを生成するとともに、メッセージ認証鍵kをk=ξ(aW)により計算する。
更に、電子チケットの変更コマンドはコマンド名“modify”と変更後の電子チケットの定義データを与えるパラメータTcktDef1とから構成される。アプリケーション装置130は上とコマンドと乱数cを合わせてメッセージとし、kを鍵としてメッセージ認証コード(MAC、Message Authentication Codes)
【数45】
MAC(k,“modify”|TcktDef1|c)
を計算し、“modify”とTcktDef1とcとMAC(k,“modify”|TcktDef1|c)とをクライアント装置120に送付する。
【0176】
[ステップ3]:(1109,1110,1111)クライアント装置120は、アプリケーション設定データ中に指定されているアプリケーション装置130の公開鍵Aを取り出し、k’=ξ(wA)によりメッセージ認証鍵k’を計算する。次いで、
【数46】
MAC(k,“modify”|TcktDef1|c)=MAC(k’,modify”|TcktDef1|c)
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ApplDefを参照し、公開鍵Aに対応付けられているアプリケーション装置に電子チケットを分割する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
【0177】
[ステップ4]:(1112,1113)クライアント装置120は、差分データ生成手段128にコマンドのパラメータTcktDef1を入力する。差分データ生成手段128は新たな共有鍵K1を生成し、次式により差分データΔ1を計算する。
【数47】
Δ1=H|s|(ApplDef|TcktDef1|K1)−H|s|(ApplDef|TcktDef|K)
【0178】
[ステップ5]:(1114,1115)クライアント装置120は、
【数48】
r=H|s|(ApplDef|TcktDef|K)c+w
を計算し、アプリケーション装置130に送付する。
【0179】
[ステップ6]:(1116,1117)共有鍵保持手段126に保持されている共有鍵Kを消去し、電子チケットを無効化するとともに、共有鍵K1とK2とを共有鍵保持手段126に記録する。
【0180】
[ステップ7]:(1118)アプリケーション装置130は、楕円曲線Eの上で
【数49】
(ct+r)G=cS+W
が成立することを検査する。
【0181】
差分データΔ1は、オリジナルの電子チケット鍵t
【数50】
t=s−H|s|(ApplDef|TcktDef|K)
から、新たな電子チケット鍵t1を生成する目的で使用される。すなわち、
【数51】
t1=t+Δ1
=s−H|s|(ApplDef|TcktDef|K)+H|s|(ApplDef|TcktDef1|K1)
−H|s|(ApplDef|TcktDef|K)
=s−H|s|(ApplDef|TcktDef1|K1)
は、クライアント装置120の共有鍵保持手段126に保持されている共有鍵K1による新たな電子チケット鍵である。
【0182】
[操作に関連する属性とその変更ルール]
電子チケットに記述可能な属性として、該電子チケットによるリソース及びサービスへのアクセスに関する有効期限及び有効回数を指定できることは、先述の実施例において述べた。
【0183】
本実施例では、有効回数属性の管理方法を述べる。
【0184】
アプリケーション装置130が、有効回数属性に値が指定されている電子チケットを検査し、その結果として、ユーザにサービスを提供する場合には、図21に記載の手順で処理を行う。
【0185】
[ステップ1]:(1201,1202)アプリケーション装置130は、クライアント装置120との通信の過程において、現在の電子チケットの有効回数属性に指定されている値から1減じた値を有効回数属性にもつ電子チケットの定義データTcktDef1を引数として、コマンド“modify”をクライアント装置120に発行する。
【0186】
[ステップ2]:(1203,1204,1205,1206)クライアント装置120は、例えば、先に述べた実施例での方法に従って、アプリケーション装置130を認証したあと、現在の電子チケットを無効化し(対応する共有鍵を消去し)、次いで、TcktDef1をチケット定義として持つ新たな電子チケット鍵t1と現在の電子チケット鍵tとの差分データΔ1を計算して、アプリケーション装置130への通信データの一部として送付する。
【数52】
Δ1=H|s|(ApplDef|TcktDef1|K1)−H|s|(ApplDef|TcktDef|K)
【0187】
[ステップ3]:(1207,1208)アプリケーション装置130は、クライアント装置120からの前記通信データに基づいて、電子チケット鍵tを検査し、検査が成功した場合に限り、新たな電子チケット鍵t1を
【数53】
t1=t+Δ1
により生成する。電子チケット鍵tはクライアント装置120により無効化されており、かつ、電子チケット鍵t1は有効回数属性が1減じられているので、リソース或いはサービスへの有効アクセス回数が1度数費消されたことになる。
【0188】
同様の仕組で譲渡回数の上限を定める譲渡可能回数属性、分割可能回数属性等を、チケット定義に含めることができる。
【0189】
[操作の取り消し]
電子チケットに対する無効化、譲渡、分割、及び、変更の操作を行った後、アプリケーションからの指示によりこれらの操作を取り消す機能の実施例を、これまでに述べた無効化、譲渡、分割、及び、変更の実施例に基づいて述べる。
【0190】
無効化、譲渡、分割、及び、変更の実施例では、クライアント装置120は、認証情報として共有鍵保持手段126に保持されている共有鍵を消去することで、操作前の電子チケットを無効化していた。
【0191】
以下で図22に記載の操作の取り消し実現する実施例では、クライアント装置120は、共有鍵退避手段126’を含む。
【0192】
[ステップ1]:(1301)クライアント装置120が、操作前の電子チケットを無効化する際には、共有鍵保持手段126に保持されている共有鍵を消去する前に、該共有鍵を共有鍵退避手段126’に記憶する。
【0193】
[ステップ2]:(1302,1303)アプリケーション装置130が、コマンド発行手段136により、操作の取り消しコマンド“resume”を発行すると、クライアント装置120はコマンド受理手段において同コマンドを解釈し、その後、共有鍵退避手段126’に記録されている操作前の共有鍵を取り出し、共有鍵保持手段126に記録する。
【0194】
[ステップ3]:(1304)加えて、電子チケットに対する前記操作によって、新たに生成された共有鍵が共有鍵保持手段126に保持されている場合には、共有鍵保持手段126中から該共有鍵を消去する。同共有鍵を、共有鍵退避手段126’に記録した後に、共有鍵保持手段126から消去する実装様態でもよい。
【0195】
以上の手順により、クライアント装置120は、操作前の電子チケットに付随する共有鍵を用いて通信を行うことが可能となり、アプリケーション装置130による該操作の効果を取り消し、操作前の電子チケットを再度有効にすることが可能となる。
【0196】
[実施例2:ビジネスモデルの実現]
以下では、本発明における電子チケットの無効化、譲渡、分割、変更の機能を用いて、アクセス権の表現である電子チケットの様々な流通フローを実現する実施例を示す。
【0197】
[再販モデル]
再販モデルとは、サービスの所有者であるサービスプロバイダがエンドユーザに対して電子チケットを販売するにあたり、サービスプロバイダとエンドユーザとの間に複数の流通業者が存在するモデルである。
【0198】
図23は、再販モデルの流通フローを示す構成図であり、1401はサービスを所有するサービスプロバイダ、1402は卸業者、1403はエンドユーザに利用権を販売する小売業者、1404は最終的なエンドユーザである。
【0199】
卸業者1402は、サービスプロバイダ1401から電子チケットの形でサービスを購入し、小売業者1403に転売する。
【0200】
また、サービスプロバイダ1401は卸業者1402から、卸業者1402は小売業者1403から、売れ残りの電子チケットの返品も受付けることができる。
【0201】
図24は、具体的な例に基づいた、電子チケットの流通のフロー図である。
【0202】
[ステップ1]:(1501)サービスプロバイダ1401は卸業者1402に1つの電子チケットを出荷する。該電子チケットは、サービスプロバイダ1401が提供するサービスに対するアクセス権を表現しており、更に、該電子チケットに対する分割操作回数の上限が属性(分割可能回数属性)として記述される。例えば、前記分割可能回数属性に100が指定されたときは、該電子チケットを100回分割することができる、言い換えると、分割して最大100人のエンドユーザに販売することができることを意味する。
【0203】
[ステップ2]:(1502)小売業者1403から注文を受けると、卸業者1402は前記電子チケットを2つに分割し(分割操作)、その一方を小売業者に譲渡する(譲渡操作)。例えば、小売業者1403からの注文が「30人分の電子チケット」である場合、分割された一方の電子チケットの分割可能回数属性には100−30=70が指定され、他方の電子チケットの分割可能回数属性には30が指定される。卸業者は後者の電子チケットを小売業者に販売(譲渡)し、70が分割可能回数属性に指定された電子チケットを手許に残す。前述のように、電子チケットの分割操作と譲渡操作とは、卸業者1402が所持するクライアント装置とアプリケーション装置とにより、サービスプロバイダ1401を介在させることなく実行される。
【0204】
[ステップ3]:(1503)小売業者1403によるエンドユーザ1404への電子チケットの販売も、電子チケットに対する分割操作と譲渡操作により実行される。小売業者1403は、エンドユーザ1404の注文を受けて、所有する電子チケットを2分割する。小売業者1403はそのうち1つを保持し、もう一方を顧客であるエンドユーザ1404に譲渡する。小売業者1403が手許に残す電子チケットの分割可能回数属性には、分割前の電子チケットの分割可能回数属性に指定される値から1減じた値が指定される。一方、エンドユーザ1404に譲渡される電子チケットの分割可能回数属性には0が指定され、エンドユーザ1404にはそれ以上電子チケットを分割することは許されない。前記、電子チケットに対する分割操作と譲渡操作は、サービスプロバイダ1401及び卸業者1402を介在させることなく、小売業者1403が所持するクライアント装置とアプリケーション装置とによって実行される。
【0205】
[ステップ4]:(1504,1506)卸業者1402は、更に、別の小売業者1403に「50人分の電子チケット」を販売し、総計で90人分のアクセス権に相当する電子チケットを販売したところで、それ以上の販売を断念するものとする。卸業者1402の手許には分割可能回数属性に値10が指定された有効な電子チケットが残されており、卸業者1402は該電子チケットをサービスプロバイダ1401に該電子チケットを「返品」して、払い戻しを受ける。この返品操作は、売れ残った該電子チケットをサービスプロバイダ1401に譲渡することで(譲渡操作)実行される。卸業者1402が小売業者1403に電子チケットを販売する過程で過渡時に所持する電子チケット、即ち、分割可能回数属性にそれぞれ100及び70が指定されている電子チケットは、販売による分割操作後、アプリケーション装置とクライアント装置により無効化されているため(無効化操作)、これらの電子チケットをサービスプロバイダ1401に対して返品することはできない。正確にはサービスプロバイダ1401は、返品された該電子チケットを検査することで、無効化された要ることを検知できる。アプリケーション装置は、譲渡操作において譲渡対象となる電子チケットの検査を実行するため、無効化された電子チケットに対して譲渡操作を実行すると、無効化されていることがアプリケーション装置によって検知されるからである。
【0206】
[ステップ5]:(1507,1508)サービスプロバイダ1401は、譲渡された電子チケットを、自らの所有するクライアント装置及びアプリケーション装置を用いて検査する。検査が成功しなかった場合には、該電子チケットの受理を拒否し、返品を受け付けない。検査に成功した場合には、該電子チケットの分割可能回数属性に指定された値を見て、該値に相当する電子チケットの返品を受理し、払い戻しを行う。例えば、該分割可能回数属性に10が指定されている場合、サービスプロバイダ1401は10個分の電子チケットの代金を卸業者1402に払い戻す。
【0207】
[ピア・ツー・ピアモデル]
インターネットによるデジタルコンテンツ流通の普及に伴い、ピア・ツー・ピアによる新しいコンテンツ配信モデルが注目されるようになってきた。ピア・ツー・ピアモデルは、「私的使用に限定したコピーの作成権」を根拠に、デジタルコンテンツの購買者がデジタルコンテンツのコピーを配信する流通モデルである。ただし、消費者間でのコンテンツのコピーが無制限に実行されると、コンテンツの著作者の権利を著しく侵害することから、ピア・ツー・ピアモデルを実現するにあたっては、消費者にコンテンツ著作者の意図した範囲でのみ、コンテンツのコピーと配布を許すシステム的な保証が必要となる。
【0208】
ここでは、本発明における電子チケットに対する、無効化、譲渡、分割、変更の機能を用いて、ピア・ツー・ピアモデルを実現する実施例を示す。
【0209】
図25は、実施例の構成図、図26は実施例のフロー図である。以下、図26に従って説明する。
【0210】
前提として、コンテンツの著作者は、コンテンツを暗号化して配布する。コンテンツは暗号化されたままでは再生することができないので、暗号化コンテンツの配布に何らの制限を加える必要はない。例えば、暗号化コンテンツを、公開されたダウンロードサイトにアップロードして、任意のユーザに自由にダウンロードすることを許すこともできる。
【0211】
コンテンツの販売とアクセス制御は、正当な対価を支払った消費者ユーザに対して、電子チケットを発行することで実現する。
【0212】
この場合、アプリケーション装置は、暗号化コンテンツを復号して、再生する能力を有し、例えば、パーソナルコンピュータ上で動作するコンテンツプレイヤプログラムや専用の再生端末のような実現となる。いずれの実装においても、アプリケーション装置は、ユーザが保有するクライアント装置と通信して電子チケットを検査し、検査に合格した場合に限り、コンテンツを復号して、再生する。このとき、先述の実施例で示したように、電子チケットの検査の結果として、コンテンツそのものやコンテンツを復号するための鍵が得られるような構成とすれば、検査ルーチンをバイパスするような攻撃に対しても安全となる。
【0213】
[ステップ1]:(1701)ユーザは、暗号化されたコンテンツを復号し、再生するためのアクセス権として電子チケットを購入する。電子チケットは分割可能回数属性を含み、電子チケットの販売者が該電子チケットの販売時に値を指定する。この属性に指定される値は、該電子チケットの販売を受けたユーザがコンテンツの共有を許されるユーザ数の最大値である。例えば、コンテンツの共有が、電子チケットを購入したユーザを含めて6人まで許可されるのであれば、該電子チケットの分割可能回数属性には5が指定される。
【0214】
[ステップ2]:(1702,1703)ユーザは、電子チケットを分割し、譲渡することで、他のユーザとコンテンツを共有する。アプリケーション装置は、まず、電子チケットの分割可能回数属性に指定されている値を検査し、値が0であれば処理を中止する。次いで、クライアント装置と通信して、電子チケットの検査を行い、電子チケットに指定された属性、就中、該分割可能回数属性の値が改竄されていないことを確認する。改竄が検知された場合は、処理を中止する。
【0215】
[ステップ3]:(1704)アプリケーション装置は、クライアント装置に分割コマンドを発行し、電子チケットを二つに分割する。分割された電子チケットの一方は、分割可能回数属性に、分割前の前記電子チケットの分割可能回数属性に指定されていた値から1減じた値をもち、他方は、分割可能回数属性に値0を持つ。引き続いて、アプリケーション装置は、譲渡先のユーザが有するクライアント装置の特定情報を指定して、クライアント装置に譲渡コマンドを発行する。該コマンドによって譲渡される電子チケットは、その分割可能回数属性に値0が指定されている電子チケットである。例えば、分割前の電子チケットの分割可能回数属性に5が指定されている場合、分割後、該ユーザの手許に残され、利用が可能な電子チケットの分割可能回数属性には4が指定されており、譲渡される電子チケットの分割可能回数属性には0が指定される。
【0216】
[ステップ4]:(1705)譲渡先のユーザは、前記譲渡された電子チケットを、電子メールなど任意の手段で受け取る。該ユーザは、該電子チケットを使って、コンテンツを再生することができる。しかし、該電子コンテンツの分割可能回数属性には0が指定されているため、該電子チケットを分割して、他のユーザとコンテンツを共有することはできない。
【0217】
[モニタリング]
電子チケットの仕組みを用いて、デジタルコンテンツの無料プロモーションを行う例を説明する。
【0218】
図27は、この実施例の説明図である。
【0219】
本実施例では、ある音楽レーベルが新人バンドのプロモーションとして、インターネット上で楽曲の電子データを公開し、ユーザによるダウンロード、さらにユーザ間の自律的な配布によって、低コストで認知拡大を図るキャンペーンを実施する場合を想定する。
【0220】
このキャンペーンへのリスナーの参加を促すため、曲を最も多く再配布したユーザに賞を与えることとし、この再配布数の正確な把握のために電子チケットを利用する。
【0221】
ここで、電子チケットには2種類ある。即ち、通常の再生権のみを持つ電子チケットと、自身が再配布権を持ち、他人に対して再生権を持つ電子チケットばかりでなく、再配布権も持つ電子チケットも発行可能な権利を持つ電子チケットである。
【0222】
前者は、単純なリスナーであり、指定された回数の再生のみが許されている。後者は、このキャンペーンにおいて、プロモータの役割を果たすユーザであり、彼らが発行した再生権チケット、換言するならば楽曲を聞かせたリスナーの数が賞の対象となる仕組みである。
【0223】
図28は実施例のフロー図である。以下、図28に従って説明する。
【0224】
[ステップ1]:(1901)音楽レーベルは、コンテンツを暗号化して配布する。これは正しいアプリケーションと正しい電子チケットの組合せによってのみ復号可能である。
【0225】
[ステップ2]:(1902)楽曲にアクセスしたユーザには、分割可能回数属性にNの指定された電子チケットが発行される。また、この電子チケットには、新たに電子チケットを生成できる権利(分割)が属性設定される。
【0226】
[ステップ3]:(1903)ユーザが電子チケットを分割して、他のユーザに発行するたびに、手元に残される電子チケットの分割可能回数が1ずつ減算される。この時、再配布権つきの電子チケットに設定される分割可能回数は、分割元の分割可能回数の現在値によらず一定である。
【0227】
[ステップ4]:(1904)再配布権付電子チケットを持つユーザは、再配布権を持たない再生権のみの電子チケットを発行することも可能である。この時の再生権は一定回数以下あるいはキャンペーン期間のみといった期日指定とすることも可能である。
【0228】
[ステップ5]:(1905)こうして何回かのチケット分割を繰り返したのち、キャンペーン期間が終了する。この時、賞に応募するには、有効な最新の電子チケットを音楽レーベルに返送(譲渡)するだけでよい。
【0229】
[ステップ6]:(1906)返送された電子チケットには、元の分割可能回数Nから分割した回数だけ減算された回数が分割可能回数として設定されている。従って、音楽レーベルは所定の認証手続きに従って電子チケットを検査することで、ユーザによる電子チケットの再配布数を把握する。
【0230】
ここでより詳しい分割の状況として、再配布先や時刻をモニタしたい場合には、ユーザの手許でローカルに蓄積されたログを電子チケットと同時に音楽レーベルに送付するような設定も可能である。その場合には、ログデータを電子チケットの属性として指定し、電子チケットを認証すると同時にログが改竄されていないことを検証することができる。
【0231】
[チェックイン、チェックアウトモデル]
デジタルコンテンツなどの利用において、据付型の機器から、携帯型の機器に対して、利用権の一時的な移動が必要な場合がある。
【0232】
このような場合における電子チケットの実施例を説明する。
【0233】
図29は、本実施例の構成図である。チケット発行元から発行された電子チケットは据付型の機器Aに格納されている。
【0234】
図30は、本実施例に基づく据付型機器へ利用権の移動・回収の動作フロー図である。以下、図30に従って、説明する。
【0235】
[ステップ1]:(2101)コンテンツプロバイダは、対象となるユーザに帰属する据付型機器に対して、当該コンテンツの利用権を発行する。これには、オンデマンドでのライセンス発行でも良いし、予めコンテンツに一定条件の利用権を同梱しておいても良い。またこの電子チケットには、分割可能な権利を付与する。
ユーザは、入手した利用権を元に据付型機器上のビューワでコンテンツの再生などをすることができる。
【0236】
[ステップ2]:(2102)据付型機器上のクライアント装置は、利用権操作アプリケーションから電子チケットの転送要求を受ける。
【0237】
[ステップ3]:(2103)まず、要求のあった電子チケットが譲渡可能なものであるか検査し、譲渡不可能な場合は以降の処理を中止する。
【0238】
[ステップ4]:(2104)ついで、利用権操作アプリケーションを認証する。認証に失敗すると以降の処理を中止する。
【0239】
[ステップ5]:(2105,2106,2107)電子チケットの譲渡の手続きに従って、新たな電子チケットを生成し、携帯型機器に転送する。据付型機器の電子チケットは転送後、無効化される。なお、利用権は元々のコンテンツプロバイダから与えられた権利に基づいて、そのまま残しておくこともできる。
【0240】
[ステップ6]:(2108)ユーザは、携帯機器上のビューワを用いて、コンテンツの再生をできる。しかし、他の機器に利用権を譲渡したり、分割することは許可されない。
【0241】
[ステップ7]:(2109,2110,2111,2112,2113)ユーザは、携帯機器上でのコンテンツの利用が終了した時点で、再び電子チケットの譲渡の手続きに従って、元の据付型機器に利用権を戻す。これで、据付型機器での再生が再び可能となる。携帯型機器に転送する利用権に予め制限(利用回数制限、利用期間制限など)をつけることで、据付型機器への書き戻しをしない方式などもバリエーションとして考えられる。
【0242】
[複数アプリケーションから構成される「アプリケーション」の例(ICカードによるチケッティング)]
ここでは、役割の異なる複数のアプリケーション装置が、協調して一貫したサービスを提供するとともに、クライアント装置が各々のアプリケーション装置に付与された特権(役割)を認証することで、不正なアプリケーション装置による電子チケットの不正操作を防止する実施例を示す。
【0243】
図31は、構成図であり、ICカードによって実現されるクライアント装置2201に格納された電子チケットに対して、電子チケットの確認を行うユーザ端末2202、譲渡・分割・変更などの操作を行う操作端末2203、および電子チケットの検証を行う検証器2204から構成されている。
【0244】
ユーザ端末2202は、例えば、ユーザのパーソナルコンピュータの上で動作するアプリケーションプログラムとして実現されたり、また、液晶画面を備えたキーホルダー型のICカードリーダライタとして実現されたりする。ユーザ端末2202は、電子チケットを検査して、検査された電子チケットが有効であるか否かを表示するとともに、電子チケットに含まれる属性のうちから必要な項目を選択して表示する。ユーザは、ユーザ端末2202の画面上で、一義的には購入した電子チケットが正しく生成されていることを確認し、二義的には何のための電子チケットであるかを確認する。ユーザ端末には、電子チケットに対する無効化、譲渡、分割、変更の操作を行う特権が与えられない。
【0245】
一方、操作端末2203は、駅や店舗に設置される端末であり、ユーザはこの端末を用いて、電子チケットに対する無効化、譲渡、分割、変更の諸操作を伴う種々の操作を行う。
【0246】
例えば、ユーザが一度購入した電子チケットを別のユーザに譲渡したい時、また、ユーザが代表してまとめて買った電子チケットを分割して別のユーザに渡したい時などに、この操作端末2203を利用する。
【0247】
操作端末2203には、電子チケットに対する無効化、譲渡、分割、変更の操作を実行する(クライアント装置2201に対して指示する)特権が付与されている。そのため、操作端末2203の実装や運用には、ユーザ端末2202に比較してより厳重なセキュリティが必要とされ、ユーザのパーソナルコンピュータ上で動作するアプリケーションプログラムなどの形態ではなく、管理の行き届く専用端末として実現する。
【0248】
ICカード2201に格納された電子チケットを、別のユーザに譲渡・分割する場合の操作を、図32のフローチャートに従って説明する。
【0249】
[ステップ1]:(2301)譲渡・分割対象となる電子チケットの格納されているICカードを操作端末に装着する。この時、ICカード内の電子チケットの内容がディスプレイに表示される。
[ステップ2]:(2302)譲渡・分割する電子チケットを選択する。
[ステップ3]:(2303)譲渡・分割の詳細条件を入力する。例えば、操作が譲渡なのか分割なのかの指示、分割である場合何枚と何枚とに分割するかなどの指示を、このステップで行う。
[ステップ4]:(2304)譲渡・分割先のICカードを操作端末に読ませる。ICカードが非接触型インターフェースを備えている場合、複数のICカードを同時に読ませることが可能となる。
[ステップ5]:(2305)譲渡分割条件と譲渡・分割先を確認の上、譲渡・分割操作を実行する。
[ステップ6]:(2306)他に譲渡・分割対象の電子チケットがあれば、ステップ2に戻る。
[ステップ7]:(2307)2枚のICカードを操作端末から抜くことでアプリケーションは終了する。
【0250】
検証器2204は、駅の改札やイベント会場の入り口に設置される機器であり、電子チケットを検査して、ユーザに対してサービスを提供することの可否を判断し、例えば、電子チケットが1回限りの使いきりのチケットである場合には検査後無効化し、回数券のように有効利用回数が指定されている場合には、チケット定義を変更して有効利用回数属性の値を1減じる操作を行う。
【0251】
このように、電子チケットを用いたデジタルチケッティングにおいて、それぞれの役割を持つ複数のアプリケーション装置が協調して、全体のサービスを構成する。セキュリティの観点からいえば、不正なアプリケーション装置が不正な処理を行わないようアプリケーションの認証を行うとともに、それぞれのアプリケーション装置に許される特権を認証する必要がある。
【0252】
本実施例では、アプリケーション装置に関わる種々の設定を定義するアプリケーション設定データと、該アプリケーション設定データに依存して生成される電子チケットと、アプリケーション装置の認証を実行するクライアント装置によって、上記機能を実現する。
【0253】
具体的には、アプリケーション設定データは、次のように定義される。
【数54】
【0254】
上記の例では、ユーザ端末は、UserTermで名前が与えられる<Application>要素で定義が与えられ、<Privilege>要素が空であることで特権が付与されていないことが規定される。<PubKey>要素ではユーザ端末を認証する際に用いる公開鍵がBase64に従って指定される。
【0255】
クライアント装置は、前記実施例に示したように、公開鍵を用いてアプリケーション装置を認証し、また、該アプリケーション装置から操作コマンドが発行された場合、<Privilege>要素を参照して、指示された操作を行う特権を該アプリケーション装置が有しているかを確かめる。
【0256】
[複数アプリケーションから構成される「アプリケーション」の例(家電製品の制御)]
本実施例では、家庭内ネットワーク上に接続された家電製品などの制御に電子チケットを用いる例を説明する。
【0257】
図33は、その構成例である。この図において、2410は、ホームサーバーであり、電子チケットを発行するともに、公衆回線と家庭内のネットワークのハブとして、各個別家電製品とクライアントの認証を仲介する。
【0258】
2420は、外部から家庭内の家電製品を制御するクライアント装置となる携帯電話である。無論、携帯電話以外にもPDA,NotePCなどであっても構わない。クライアント装置は、例えば公開鍵証明書などを送付することによって、ユーザへの帰属を明らかにし、他の権限をもたないユーザと区別される。
【0259】
2430,2440,2450,2460は、各個別家電製品であり、おのおの特定のサービスを提供するアプリケーションとして機能する。各家電製品はここではホームサーバーに特権などを記述したアプリケーション設定表を設置時に登録するものとする。
【0260】
1、ユーザは自宅のホームサーバに対して、電話あるいはメイルなどでアクセスし、電子チケットの発行要求を出す。
【0261】
2、ホームサーバはクライアントを認証し、正当なクライアントには所望の電子チケットを発行する。
ここで、ホームサーバーは管理下のクライアントおよび機器の権限についての情報を事前に蓄積しているので、正しい条件の電子チケットのみを発行できる。
例えば、ビデオデッキの予約は家庭内の全員に可能だが、炊飯器の設定は特定の人間しかできないといったユーザごとアプリケーションごとの権利設定が可能となる。
【0262】
3、ユーザは、電子チケットの条件の許す範囲において、入手した電子チケットを使って、家庭内の家電製品を制御することができる。
具体的には、ユーザは入手した電子チケットをホームサーバーをゲートウェーとして、制御対象となる機器に送付する。例えば、ビデオデッキの予約設定、空調の調整、風呂への給湯、炊飯器の炊きあがり時間設定などである。
【0263】
[実施例3:完結したスキームの実施例]
[概要]
本発明に基づいたシステムにおける管理的ロールはクライアント配布者・アプリケーション管理者・電子チケット発行者の三者である。これらはそれぞれ独立なロールであり,さらに各ロールはそれぞれ複数の独立な主体が務めることができる。また逆に一つの主体が複数のロールを兼ねることもできる。
【0264】
システムにおける装置はクライアント装置・アプリケーション装置・電子チケット生成装置の三種類がある。
【0265】
クライアント装置は、クライアント配布者によって作成されユーザに配布される。典型的な実現としては、CPUの特殊機能、ICカード、PCカード、USB機器、携帯電話やPDA中の特殊モジュール等のハードウェア、或いは、OSの特殊コンポーネント、PC上にインストールされるアプリケーションプログラム等のソフトウェアの形態をとる。ハードウェア、ソフトウェア、いずれの実装の場合であっても、ユーザが携帯するのに便利なもの、また、ユーザの身近にあるものが望ましい。
【0266】
本実施例では、クライアント装置は機能的には、電子チケット生成装置と通信を行い、電子チケット生成装置からユーザのアクセス資格を表現するデータとして電子チケットを取得する。また、アプリケーション装置と通信を行い、その電子チケットを用いてユーザのアクセス資格をアプリケーション装置に対して証明する。さらに、アプリケーション装置を介して他のクライアント装置と通信を行い、その電子チケットが許可する範囲で譲渡・分割を行うことによって、他のクライアント装置へチケットを発行したり、他のクライアント装置が保持する電子チケットの譲渡・分割によって生成された電子チケットを取得する。
【0267】
クライアント装置に仮定される性質はクライアント装置毎に異なるクライアント公開鍵が割り当てられていて、外部から観測不能な記憶領域(クライアント秘密鍵及びチケット共有値が格納される)及び計算環境を備えることである。
【0268】
アプリケーション装置はアプリケーション管理者によって作成されサービス提供におけるプラットフォーム乃至ゲートウェイとなる。典型的な実現としては、ハードウェアとして、改札などの条件的ゲート施設、カードリーダー、POS端末、各種コンテンツフォーマットに対応したセキュアコンテンツデバイス、また、ソフトウェアとして、PC上にインストールされた電子チケット管理ツール、各種コンテンツフォーマットに対応したセキュアコンテンツビューア、暗号の復号や署名生成を行うPKIにおけるユーザの個人鍵処理モジュール等がある。いずれにせよ何らかの意味でユーザに条件的にサービスを提供するものならば何であっても構わない。つまり、任意の家電製品(有資格者には機能する)や任意のアプリケーションプログラム(有資格者は起動できる)でも良い。
【0269】
アプリケーション装置は機能的にはクライアント装置と通信を行い、電子チケットを用いてユーザのアクセス資格を認証してサービスを提供する。また、さらに他のクライアント装置と通信を行い、その電子チケットが許可する範囲で譲渡・分割を行うことによって他のクライアント装置へ電子チケットを発行する。
【0270】
アプリケーション装置に仮定される性質はアプリケーション公開鍵が割り当てられていて、外部から観測不能な記憶領域(アプリケーション秘密鍵が格納される)及び計算環境を備え、ユーザのサービスに対するアクセス資格を検証するために、提供するサービスに対応するサービス公開鍵を少なくともサービス提供時に持つことである。
【0271】
電子チケット生成装置は電子チケット発行者によって使用され、ユーザの所持するクライアント装置向けに電子チケットを発行する。
【0272】
典型的な実現としては、家電製品の組み込みモジュールであっても良いし、PC上のアプリケーションプログラムでも良いし、また、多数のサービスを扱い多数のクライアントに対して大量にアクセス資格を発行する電子商取引サイトの機能であるならばデータベースを備えた大規模システムからなるものであっても良い。
【0273】
電子チケット生成装置は機能的にはクライアント装置と通信を行い、ユーザのアクセス資格を電子チケットとして発行する。
【0274】
電子チケット生成装置に仮定される性質はサービス公開鍵に対応するサービス秘密鍵を外部から観測不能な記憶領域に保持し、計算環境を備え、サービス公開鍵ペアが割り当てられている。
【0275】
[因数分解型の公開鍵暗号アルゴリズム]
多くの公開鍵暗号アルゴリズムにおける秘密鍵の属する空間は安全性を留保したまま公開可能なアーベル群であり、その群構造とアルゴリズムは親和性を持つ。例えば、素因数分解が困難な合成数nに対して、RSAにおける秘密鍵dは加法群Zの元と見なせ、Guillou−Quisquater認証における秘密鍵sは乗法群Gm(Z/nZ)の元と見なせる。また、素数位数pの基底Gが定められた離散対数問題が困難な群EにおけるSchnorr認証やDiffie−Hellman鍵共有の秘密鍵xは加法群Ga(Fp)の元である。
【0276】
[実施例3−1:RSA公開鍵暗号に基づく実施例]
ここでは因数分解型の公開鍵暗号アルゴリズムに基づく本発明の実施例の一例として、RSA公開鍵暗号に基づく構成を示す。
【0277】
クライアント配布者がクライアント鍵ペア(T,τ)を生成し、あるクライアント装置にRSA公開鍵(T,216+1)を割り当て、保護された記憶領域には対応する秘密鍵τを格納するものとする。つまりTは素因数分解が困難な合成数で任意のc∈Gm(Z/TZ)に対して
【数55】
となっている。
【0278】
また、サービスのオーナが同様にサービス鍵ペア(S,σ)を生成し、所有するあるサービスにRSA公開鍵(S,216+1)を割り当てるものとする。ここでS<Tとする。
【0279】
σを知るサービスオーナが
1、ランダムにκ(チケット共有値)を生成する。チケット共有値とは、先術の実施例において、認証情報、或いは、共有鍵と呼ぶデータと一致する。
ただし0<κ<Sとする。
2、
【数56】
(チケット共有値のクライアント公開鍵による暗号化)を計算する。
3、t=σ−κ(サービス秘密鍵とチケット共有値お差分)を計算する。
として、クライアント装置Tに(I,t)を発行する。クライアント装置はIを入力されると
1、
【数57】
としてIを復号する。
2、κを保護された記憶領域に格納する。
という電子チケットの登録作業を行うものとする。また、クライアント装置はc(ただし0<c<S)を入力されると
1、r=cκ mod Sを計算する。
2、rを出力する。
というレスポンス生成の機能も持つものとする。t+κ=σであるからctrmod S=cσ mod Sであり、クライアント装置を保持しているユーザは電子チケットtを用いることによってサービス秘密鍵σを知ることなくサービス秘密鍵σによる関数cσ mod Sを計算することができる。
【0280】
さらに電子チケット登録においてサービス鍵Sの識別子s=h(S)を併せて入力することによって保護された記憶領域に(s,κ)を格納するようにし、レスポンス生成においてサービス鍵Sを併せて入力し、対応するκを検索して利用するようにすれば、多数のサービス鍵に応じたレスポンス生成が行える。さらに、電子チケットに対して有効期限などを記述するチケット定義D(オクテット列として符号化されて表現されているものとする)という量を導入し、t=σ−hS(D|k)とすることによって電子チケットに対して有効期限などを設定することが可能である。ただし、ここで|はオクテット列の連接を表しており、本実施例において、例えばここにおけるκのような数学的量には常に適当なオクテット列へのエンコードメソッドが用意されているものとしている。また、hS(D|k)は、サービス公開鍵Sに依存する一方向性及び非衝突性を満足するハッシュ関数であるとする。
【0281】
また電子チケット生成に先立って、クライアント装置がランダムなチケット要求鍵Rを生成するものとし、チケット共有値κがRに依存するようにすることができる。一例として、サービスオーナがランダムにチケット共有値シードιを生成し、
【数58】
とするなどの方法がある。チケット共有値κの生成にクライアント装置が内部で生成する乱数Rが関与するものとすると、クライアント装置のテーブルから一度消去されたチケット共有値κを再現することが不可能になる。この事実を利用して電子チケットの効果的な消去を実行できる。また、電子チケットの初期状態が再現できないというこの技法と秘密鍵の空間がアーベル群をなすことを組み合わせて、遷移型の電子チケットを定義することができる。電子チケット(D,t)に対して異なるチケット定義を持つ電子チケットを生成するのに、以下のステップを実行する
【数59】
【0282】
また、電子チケット(D,t)を異なるクライアント装置用のものに変換する電子チケットの譲渡も以下のように実現できる。
1、譲渡先のクライアント装置からチケット要求鍵R’を取得する。
2、ランダムに新しいチケット共有値シードt’を生成する。
3、譲渡先のクライアント装置の公開鍵T’で共有値シードt’を暗号化し、それをI’とする。
【数60】
4、譲渡先のクライアント装置におけるチケット共有値k’を計算する。
【数61】
k’=hS(i’|R’)。
5、チケット鍵の差分Δ’=hS(D|k)−hS(D’|k’)を計算する。6、クライアント装置のテーブルに格納するチケット共有値κを削除する。
7、譲渡先のクライアント装置用の新しいチケット鍵t’=t+Δ’を計算する。
8、(I’,D’,t’)を電子チケットとして譲渡先のクライアント装置へ送付する。
譲渡先のクライアント装置が電子チケットの登録を行う方法はサービスオーナが生成した電子チケットを登録する方法と同一である。さらに、更新と譲渡を組み合わせることで電子チケットの分割も実現できる。
【0283】
電子チケットの更新が行えることから利用回数制限のような指定をチケット定義Dに含めることができる。これらの電子チケットに副作用を与えるような処理は任意の第三者が行えてはいけない。そこで、チケット定義中にこれらの指示を出すことができるアプリケーションの公開鍵を指定して、その公開鍵で検証できるような動作つまりアプリケーション秘密鍵の保持をテストするような動作を要求することによってクライアント装置がアプリケーションを認証し、これら特権を持ったアプリケーションのみがチケットへの副作用を及ぼす処理の指示が可能であるようにするべきである。電子チケットの更新・譲渡・分割は電子チケット認証と同期して行うこともできる。
【0284】
[実施例3−2:Guillou−Quisquater零知識認証に基づく実施例]
ここでは、因数分解型公開鍵暗号アルゴリズムに基づく実施例の第二として、Guillou−Quisquater零知識認証に基づいた実施例を述べる。
【0285】
以下でpは共通の素数であり、公開されているものとする。
【0286】
クライアント配布者は、該クライアント配布者が配布するクライアント装置で共通に用いられる法数nを固定的に定める。Nは素因数分解の困難な合成数である。
【0287】
更に、クライアント配布者は、クライアント装置毎にGuillou−Quisquaterクライアント鍵ペア(T,τ)を生成し、Tを該クライアント装置の公開鍵として公開し、秘密鍵τをクライアント装置内の保護された記憶領域に格納する。即ち、
【数62】
τp=T mod N
が成立する。
【0288】
一方、サービスオーナは公開の法数nと,任意のc∈Gm(Z/nZ)に対して
【数63】
cpc−1=c mod n
を満足するマスター鍵dを秘密裡に保持する。即ち、(p,d)は法数nに対応するRSA公開鍵暗号の公開鍵ペアとなる。
【0289】
更に、Guillou−Quisquaterサービス鍵ペア(S,σ)を
【数64】
σp=S mod n
を満足するように定める。
【0290】
本実施例では、クライアント装置が特定情報と認証情報を都度生成し、電子チケット生成装置に送付する。以下は、特定情報の計算手順である。
【0291】
[ステップ1]:サービス法数n、及び、サービス公開鍵Sの入力を受け、サービス公開鍵識別子s=h(n,S)を計算する。
[ステップ2]:認証情報(共有鍵)κをランダムに生成し、(s,κ)をクライアント装置内の保護された記憶領域に格納する。
[ステップ3]:乱数ε∈Gm(Z/nZ)を生成し、Guillou−Quisquater電子署名(ρ0,ρ1)を以下のように生成する。
【数65】
ρ0=εp mod n
ρ1=ετh(ρ0κ mod n
【0292】
[ステップ4]:κをRSA公開鍵暗号の公開鍵(p,n)で暗号化し、(κpmod n,ρ0,ρ1)を特定情報として出力する。
【0293】
電子チケット生成装置は、特定情報(κp mod n,ρ0,ρ1)、クライアント公開鍵T、及び、チケット定義TcktDefを入力として、以下の手順で電子チケットを生成する。
【0294】
[ステップ1]:マスター鍵dにより、κを復号する。
[ステップ2]:Guillou−Quisquater電子署名(ρ0,ρ1)が、κに対する電子署名であることを、クライアント公開鍵Tを用いて検査する。検査に失敗したときには、以降の処理を中止する。
[ステップ3]:下式により、電子チケット鍵tを計算する。
【数66】
t=σh(κ|TcktDef)−1 mod n
【0295】
以下、本実施例では、もっとも基本的な電子チケットの認証手順を述べる。クライアント装置によるアプリケーション装置の認証や、アプリケーションによる、電子チケットの無効化、譲渡、分割、変更は、これまでに述べた実施例と同一の構成によって実現できるので、本実施例では説明を割愛する。
【0296】
[ステップ1]:クライアント装置は、入力(n,S)からs=h(n,S)を計算し、sを検索の鍵として、クライアント装置内の保護された記憶領域から(s,κ)を取得する。
[ステップ2]:コミットメントχ∈Gm(Z/nZ)をランダムに生成し、ウィットネスωを以下の式で計算し、アプリケーション装置に送付する。
【数67】
ω=χp mod n
【0297】
[ステップ3]:アプリケーション装置は、チャレンジcをランダムに生成し、クライアント装置に送付する。
[ステップ4]:クライアント装置は、レスポンスrを以下の式で計算し、アプリケーション装置に送付する。
【数68】
r=χh(κ|TcktDef)c mod n
【0298】
[ステップ5]:アプリケーション装置は、tpcrp=ωSc mod nを検査し、検査が成功した場合に限り、ユーザが正しくアクセス権を有しているものと認定し、サービスを提供する。
【0299】
[実施例4:ロール間の信頼関係]
クライアント配布者は、各クライアント装置にユニークな公開鍵・個人鍵対を生成し、公開鍵を証明する証明書を併せて発行する。通常の証明書は現実に存在し責任能力のあるエンティティと公開鍵情報のバインドを保証するためのものだが、本発明のケースでは、対応する個人鍵がクライアント装置内に耐タンパー性をもって格納され、個人鍵の漏洩が起きないことをクライアント配布者がチケット発行者に対して保証する意味付けがなされている。述べ方を替えるならば、公開鍵に対応する個人鍵を保持するものはクライアント装置プログラムのみに限ることをクライアント装置配布者が保証するという意味になる。本発明の電子チケットは、電子チケット生成装置と発行先のクライアント装置において共有される値に基づいてサービスに対応する個人鍵を変形したものであり、第三者が電子チケット発行者との間で共有値を得ることができれば、直ちにサービスに対応する個人鍵を得られてしまう。電子チケット発行者は、発行先のクライアント装置の発行者を信頼することによって、電子チケット発行を行うことができる。
【0300】
アプリケーションは電子チケットに対して副作用を及ぼすことができる。電子チケットに対して副作用を及ぼすことができるのは、電子チケットに指定されたアプリケーションに限られる。アプリケーションは、認証の対象となるサービスに対応したサービス公開鍵を用いてユーザのアクセス資格を認証し、また、アプリケーションの特権を表す公開鍵・個人鍵対の個人鍵を用いてクライアント装置へ電子チケットへの副作用を指示することができる。アプリケーション管理者は、アプリケーションの特権を特徴付ける公開鍵・個人鍵対を生成し、公開鍵を証明する証明書を併せて発行する。本発明の電子チケットは、電子チケットによって指定されたアプリケーションの個人鍵を用いることによって指定された範囲で副作用を及ぼすことができるので、第三者がアプリケーションの個人鍵を得ることができれば、自由にチケットに副作用を及ぼすことができてしまう。チケット発行者は、発行する電子チケットを用いた認証を行うアプリケーションプログラムの管理者たるアプリケーション管理者を信頼することによって、チケット発行を行うことができる。
【0301】
以上説明したように本発明の実施例によれば、アクセス資格を集中管理しないので、アクセス資格の運用コストを増大させることがなく、また、通通フローに適用が容易となる。また、クライアントは秘密情報を管理するための装置を複数保持する必要がなくなる。また秘密情報の漏洩等のおそれがなくサービス提供者、クライアント装置提供者、アプリケーション装置提供者の間の相互運用を容易にする。さらに、アクセス権行使に際し、匿名性を確保できる。さらに、各種サービス利用権の発行、検証、ならびに前記利用権データに対する無効化、譲渡、分割、変更などの操作を行うことができる。
【0302】
なお、この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。
【0303】
【発明の効果】
以上説明したように、この発明によれば、アクセス資格の集中管理等に起因していた従来のアクセス権管理上の種々の問題を解消することができる。
【図面の簡単な説明】
【図1】 本発明の実施例1の全体構成を説明する図である。
【図2】 上述実施例1のクライアント装置の構成例を説明する図である。
【図3】 上述実施例1のクライアント装置の他の構成例を説明する図である。
【図4】 上述実施例1のクライアント装置の他の構成例を説明する図である。
【図5】 上述実施例1のクライアント装置のさらに他の構成例を説明する図である。
【図6】 上述実施例1のアプリケーション装置の構成例を説明する図である。
【図7】 上述実施例1のアプリケーション装置の他の構成例を説明する図である。
【図8】 上述実施例1のアプリケーション装置のさらに他の構成例を説明する図である。
【図9】 上述実施例において信頼できるクライアント装置やアプリケーション装置を選択する構成を説明する図である。
【図10】 上述実施例における電子チケット発行フローを説明するフローチャートである。
【図11】 上述実施例における他の電子チケット発行フローを説明するフローチャートである。
【図12】 上述実施例における電子チケット検証フローを説明するフローチャートである。
【図13】 上述実施例における他の電子チケット検証フローを説明するフローチャートである。
【図14】 上述実施例における他の電子チケット検証フローを説明するフローチャートである。
【図15】 上述実施例におけるさらに他の電子チケット検証フローを説明するフローチャートである。
【図16】 上述実施例におけるアプリケーション装置によるクライアント装置の認証のフローを説明するフローチャートである。
【図17】 上述実施例における電子チケットを無効化するフローを説明するフローチャートである。
【図18】 上述実施例における電子チケットを譲渡するフローを説明するフローチャートである。
【図19】 上述実施例における電子チケットを分割するフローを説明するフローチャートである。
【図20】 上述実施例における電子チケットを変更するフローを説明するフローチャートである。
【図21】 上述実施例における有効回数の管理フローを説明するフローチャートである。
【図22】 上述実施例における副作用の取消フローを説明するフローチャートである。
【図23】 本発明の実施例2の再販モデルの構成を説明する図である。
【図24】 上述再販モデルの電子チケットの発行・検証のフローを説明するフローチャートである。
【図25】 上述実施例2のピア・ツー・ピアモデルの構成を説明する図である。
【図26】 上述ピア・ツー・ピアモデルの利用権配布フローを説明するフローチャートである。
【図27】 上述実施例2のモニタリングの構成を説明する図である。
【図28】 上述モニタリングのフローを説明するフローチャートである。
【図29】 上述実施例2のチェックイン・チェックアウトの構成を説明する図である。
【図30】 上述チェックイン・チェックアウトのフローを説明するフローチャートである。
【図31】 上述実施例2の複合アプリケーションの構成を説明する図である。
【図32】 上述実施例2のチケットの譲渡・分割の操作手順を説明するフローチャートである。
【図33】 上述実施例2の家電製品の制御を説明する図である。
【符号の説明】
110 電子チケット生成装置
111 特定情報取得手段
120 クライアント装置
121 通信手段(2)
122 特定情報生成手段
123 秘密情報保持手段
124 部分特定情報生成手段
125 設定データ保持手段
126 共有鍵保持手段
126 共有鍵退避手段
126 共有鍵保持手段
127 共有鍵保護手段
128 差分データ生成手段
129 外部特定情報保持手段
130 アプリケーション装置
131 通信手段(1)
132 秘密鍵保持手段
133 電子チケット保持手段
134 アクセス権認証装置
136 コマンド発行手段
137 コマンド受理手段
201 電子チケット
202 特定情報
1401 サービスプロバイダ
1402 卸業者
1403 小売業者
1404 エンドユーザ
2201 カード
2201 クライアント装置
2202 ユーザ端末
2203 操作端末
2204 検証器
Claims (29)
- サービスを提供するアプリケーション装置と、サービスの提供を受けるユーザ側のクライアント装置とを含み、ユーザによるサービスへのアクセスを制御するアクセス権管理システムであって、
前記アプリケーション装置は、
ユーザの前記サービスに対するアクセス権を電子的に表現したチケットデータを保持する電子チケット保持手段と、
クライアント装置と通信を行うための第1の通信手段と、
前記電子チケット保持手段に保持されるチケットデータと前記第1の通信手段を介して前記クライアント装置から得られる通信データとに基づいて認証を実行するアクセス権認証手段とを含み、
前記クライアント装置は、
前記アプリケーション装置と通信を行うための第2の通信手段と、
前記第2の通信手段を介して前記アプリケーション装置から得られる通信データに基づいて認証を実行するアプリケーション認証手段とを含み、
前記アプリケーション装置は、前記アクセス権認証手段による認証が成功した時に限り、ユーザが該サービスに対するアクセス権を有しているものと判断してサービスを提供し、他方、前記クライアント装置は、前記アプリケーション認証手段による認証が成功した時に限り、前記アプリケーション装置が該サービスを提供する特権を有していることを認証し、認証が成功した場合に限り前記アプリケーション装置の要求に応えて通信データを送付し、
さらに、前記アプリケーション装置は、前記クライアント装置に対してコマンドを発行するためのコマンド発行手段を含み、前記クライアント装置は前記コマンドを受理するためのコマンド受理手段を含み、前記コマンド発行手段によって発行されたコマンドは、前記第1の通信手段及び第2の通信手段を介して、前記コマンド受理手段に伝達され、
さらに、前記クライアント装置は、特権を有するアプリケーション装置の認証方法を記載した設定データを保持するクライアント装置用設定データ保持手段を含み、前記アプリケーション認証手段は前記クライアント装置用設定データ保持手段に保持される設定データを参照することにより、前記アプリケーション装置が特権を有することを認証し、
前記クライアント装置は差分データ生成手段と、外部のクライアント装置の特定情報を保持する外部特定情報保持手段とを含み、前記クライアント装置及びアプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は前記チケットデータを他のユーザのアクセス権を表現する別のチケットデータに変更するためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置は、前記コマンド受理手段により該コマンドを受理し、前記クライアント装置用設定データ保持手段に保持されている設定データを用いて、前記アプリケーション装置が該コマンドを発行する特権を有していることを認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変更するとともに、差分データ生成手段と外部特定情報保持手段とを用いて前記チケットデータを前記新しいチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理システム。 - サービスを提供するアプリケーション装置と、サービスの提供を受けるユーザ側のクライアント装置とを含み、ユーザによるサービスへのアクセスを制御するアクセス権管理システムであって、
前記アプリケーション装置は、
ユーザの前記サービスに対するアクセス権を電子的に表現したチケットデータを保持する電子チケット保持手段と、
クライアント装置と通信を行うための第1の通信手段と、
前記電子チケット保持手段に保持されるチケットデータと前記第1の通信手段を介して前記クライアント装置から得られる通信データとに基づいて認証を実行するアクセス権認証手段とを含み、
前記クライアント装置は、
前記アプリケーション装置と通信を行うための第2の通信手段と、
前記第2の通信手段を介して前記アプリケーション装置から得られる通信データに基づいて認証を実行するアプリケーション認証手段とを含み、
前記アプリケーション装置は、前記アクセス権認証手段による認証が成功した時に限り、ユーザが該サービスに対するアクセス権を有しているものと判断してサービスを提供し、他方、前記クライアント装置は、前記アプリケーション認証手段による認証が成功した時に限り、前記アプリケーション装置が該サービスを提供する特権を有していることを認証し、認証が成功した場合に限り前記アプリケーション装置の要求に応えて通信データを送付し、
さらに、前記アプリケーション装置は、前記クライアント装置に対してコマンドを発行するためのコマンド発行手段を含み、前記クライアント装置は前記コマンドを受理するためのコマンド受理手段を含み、前記コマンド発行手段によって発行されたコマンドは、前記第1の通信手段及び第2の通信手段を介して、前記コマンド受理手段に伝達され、
さらに、前記クライアント装置は、特権を有するアプリケーション装置の認証方法を記載した設定データを保持するクライアント装置用設定データ保持手段を含み、前記アプリケーション認証手段は前記クライアント装置用設定データ保持手段に保持される設定データを参照することにより、前記アプリケーション装置が特権を有することを認証し、
前記クライアント装置は差分データ生成手段を含み、前記クライアント装置及び前記アプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は、前記チケットデータを同一のサービスに関する二つの異なるチケットデータに変更するためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置は、前記クライアント装置用設定データ保持手段に保持されている設定データを用いて、アプリケーション装置が該コマンドを発行する特権を有していることを認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変化するとともに、前記差分データ生成手段を用いて前記チケットデータを前記新しい二つのチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理システム。 - 請求項1または2に記載のアクセス権管理システムにおいて、前記クライアント装置が共有鍵保持手段と共有鍵保護手段を含み、前記共有鍵保持手段は前記サービスの提供者に帰属する電子チケット生成装置との間で共有する共有鍵を保持し、前記アプリケーション認証手段は前記共有鍵を用いて、前記アプリケーション装置に送付する通信データを生成し、さらに、前記共有鍵保護手段はクライアント装置内に現れる共有鍵が改竄されたり摂取されたりすることを防止することを特徴とするアクセス権管理システム。
- 請求項1〜3のいずれかに記載のアクセス権管理システムにおいて、前記クライアント装置は、前記アプリケーション装置と通信を行うに当たって、前記クライアント装置用設定データ保持手段に保持されている設定データに依存して前記アプリケーション装置に送付する通信データを生成することで、前記クライアント装置用設定データ保持手段に保持されている設定データが不正であった場合、前記アプリケーション装置が正しいデータを前記クライアント装置から受け取ることを防止することを特徴とするアクセス権管理システム。
- 請求項1〜4のいずれかに記載のアクセス権管理システムにおいて、前記クライアント装置及び前記アプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は前記チケットデータに付与されている属性であって、チケットデータの利用開始日 時、利用終了日時、利用可能回数、譲渡の可否、譲渡可能回数、分割の可否、分割可能回数、及び、アプリケーション装置が解釈できるプログラムコードのうちの一つ、或いは、複数の組み合わせである属性を変更して新しいチケットデータを生成するためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置は、前記コマンド受理手段により該コマンドを受理し、前記クライアント装置用設定データ保持手段に保持されている設定データを用いて、アプリケーション装置が該コマンドを発行する特権を有していることを認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変更するとともに、前記差分データ生成手段を利用して前記チケットデータを前記新しいチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理システム。
- 請求項1〜5のいずれかに記載のアクセス権管理システムにおいて、前記クライアント装置及びアプリケーション装置が各々一方向性関数手段を保持し、互いの認証を目的とする通信時に、前記一方向性関数手段の出力を相手に送付することにより、互いに自らの秘密情報を開示しないことを特徴とするアクセス権管理システム。
- 請求項1〜6のいずれかに記載のアクセス権管理システムであって、前記チケットデータを生成する電子チケット生成装置を含み、
前記電子チケット生成装置が前記クライアント装置を特定する特定情報を取得するための特定情報取得手段を含み、前記電子チケット生成装置はチケットデータを生成するにあたり、公開された手順に従って前記特定情報取得手段から前記クライアント装置の特定情報を取得し、該特定情報に依存するようにチケットデータを生成することを特徴とするアクセス権管理システム。 - 請求項7に記載のアクセス権管理システムにおいて、前記クライアント装置が該クライアント装置を特定する特定情報を生成する特定情報生成手段を含み、前記電子チケット生成装置は前記特定情報取得手段を介して、該クライアント装置が前記特定情報生成手段を用いて生成した特定情報を取得して、チケットデータを生成することを特徴とするアクセス権管理システム。
- 請求項8に記載のアクセス権管理システムにおいて、前記クライアント装置が該クライアント装置の秘密情報を保持する秘密情報保持手段を含み、前記クライアント装置の特定情報を前記秘密情報保持手段に保持される秘密情報から前記特定情報生成手段を用いて生成することを特徴とするアクセス権管理システム。
- 請求項8に記載のアクセス権管理システムにおいて、前記クライアント装置が秘密情報生成手段を含み、前記クライアント装置の特定情報を前記秘密情報生成手段が生成する秘密情報から前記特定情報生成手段を用いて生成することを特徴とするアクセス権管理システム。
- 請求項9または10に記載のアクセス権管理システムにおいて、前記クライアント装置が前記電子チケット生成装置からの特定情報発行要求を受け付ける要求受付手段を含み、前記特定情報生成手段を用いた特定情報の計算を、前記電子チケット生成装置から前記要求受付手段に要求が発行される都度、実行することを特徴とするアクセス権管理システム。
- 請求項10に記載のアクセス権管理システムにおいて、前記秘密情報生成手段が生成する秘密情報が乱数であることを特徴とするアクセス権管理システム。
- 請求項9に記載のアクセス権管理システムにおいて、前記秘密情報保持手段に保持される秘密情報が、前記クライアント装置に帰属する暗号の秘密鍵であることを特徴とするアクセス権管理システム。
- 請求項8に記載のアクセス権管理システムにおいて、前記クライアント装置が秘密情報生成手段と秘密情報保持手段とを含み、前記特定情報生成手段は、前記秘密情報生成手段が生成する第1の秘密情報と前記秘密情報保持手段が保持する第2の秘密情報とから、前記特定情報を生成することを特徴とするアクセス権管理システム。
- 請求項7に記載のアクセス権管理システムにおいて、前記クライアント装置は秘密鍵保持手段を含み、前記秘密鍵保持手段は、前記クライアント装置に帰属する公開鍵暗号の秘密鍵(個人鍵、私有鍵、プライベート鍵ともいう)を保持し、前記クライアント装置を特定する情報が前記秘密鍵に対応する公開鍵暗号の公開鍵であることを特徴とするアクセス権管理システム。
- 請求項7に記載のアクセス権管理システムにおいて、クライアント装置を特定する特定情報を第三者の機関に登録し、前記電子チケット生成装置は、前記特定情報取得手段を介して前記第三者の機関から前記クライアント装置の特定情報を取得することを特徴とするアクセス権管理システム。
- 請求項7に記載のアクセス権管理システムにおいて、前記クライアント装置が該クライアント装置を一部特定するための部分特定情報生成手段と、該クライアント装置に帰属する公開鍵暗号の秘密鍵を保持するための秘密鍵保持手段とを含み、前記部分特定情報生成手段が生成する部分特定情報と、前記秘密鍵保持手段に保持される秘密鍵に対応する公開鍵とを合わせて、前記クライアント装置の特定情報とすることを特徴とするアクセス権管理システム。
- 請求項7に記載のアクセス権管理システムにおいて、前記電子チケット生成装置は第1の鍵共有手段を含み、前記クライアント装置の特定情報から前記クライアント装置と共有するべき共有鍵を計算し、該共有鍵に依存するようにチケットデータを生成し、また、前記クライアント装置は第2の鍵共有手段と共有鍵保護手段を含み、前記第1の鍵共有手段が生成する共有鍵と一致する共有鍵を生成することを特徴とするアクセス権管理システム。
- 請求項18に記載のアクセス権管理システムにおいて、前記クライアント装置の前記第2の鍵共有手段は、前記電子チケット生成装置に帰属する公開鍵暗号の公開鍵を用いて前記共有鍵を生成することを特徴とするアクセス権管理システム。
- 請求項18に記載のアクセス権管理システムにおいて、前記電子チケット生成装置が鍵共有のために前記クライアント装置に送付する鍵共有データのための鍵共有データ生成手段を含み、また、前記クライアント装置の前記第2の鍵共有手段は、前記電子チケット生成装置が生成した鍵共有データを用いて共有鍵を生成することを特徴とするアクセス権管理システム。
- 請求項20に記載のアクセス権管理システムにおいて、前記電子チケット生成装置が秘密情報を保持する電子チケット生成装置用秘密情報保持手段を含み、前記第1の鍵共有手段は、クライアント装置の前記特定情報と併せて、前記電子チケット生成装置用秘密情報保持手段に保持される秘密情報を用いて共有鍵を生成し、前記鍵共有データ生成手段は該秘密情報を用いて鍵共有データを生成することを特徴とするアクセス権管理システム。
- 請求項21に記載のアクセス権管理システムにおいて、前記電子チケット生成装置用秘密情報保持手段に保持される秘密情報が、該電子チケット装置に帰属する暗号の秘密鍵であることを特徴とするアクセス権管理システム。
- 請求項20に記載のアクセス権管理システムにおいて、前記電子チケット生成装置が電子チケット生成装置用秘密情報生成手段を含み、前記第1の鍵共有手段は、クライアント装置の前記特定情報と併せて、前記電子チケット生成装置用秘密情報生成手段により生成される秘密情報を用いて共有鍵を生成し、前記鍵共有データ生成手段は該秘密情報を用いて鍵共有データを生成することを特徴とするアクセス権管理システム。
- 請求項23に記載のアクセス権管理システムにおいて、前記電子チケット生成装置用秘密情報生成手段が生成する秘密情報が乱数であることを特徴とするアクセス権管理システム。
- 請求項22に記載のアクセス権管理システムにおいて、前記電子チケット生成装置用秘密情報保持手段に保持される秘密鍵が公開鍵暗号の秘密鍵(個人鍵、私有鍵、プライベート鍵ともいう)であり、前記クライアント装置の第2の鍵共有手段は、前記電子チケット生成装置が生成する前記鍵共有データに併せて、前記秘密鍵に対応する公開鍵暗号の公開鍵を用いて共有鍵を生成することを特徴とするアクセス権管理システム。
- 請求項18に記載のアクセス権管理システムにおいて、前記電子チケット生成装置が秘密情報生成手段と秘密情報保持手段とを含み、前記第1の鍵共有手段は、前記秘密情報生成手段が生成する第1の秘密情報と前記秘密情報保持手段に保持される第2の秘密情報とを用いて共有鍵を生成し、前記鍵共有データ生成手段は、前記秘密情報生成手段が生成する第1の秘密情報と前記秘密情報保持手段に保持される第2の秘密情報とを用いて鍵共有データを生成することを特徴とするアクセス権管理システム。
- 請求項1〜26のいずれかに記載のアクセス権管理システムであって、前記チケットデータを生成する電子チケット生成装置を有し、前記電子ケット生成装置が、前記アプリケーション装置の供給者が提供するアプリケーション装置の設定データを評価するアプリケーション設定データ評価手段を含み、前記電子チケット生成装置は、前記設定データと前記アプリケーション設定データ評価手段からの出力のいずれか一方、もしくは、両方を用いてチケットデータを生成することで、設定データに記載された正当なアプリケーション装置のみに該チケットデータに基づいてサービスを提供する特権を付与することを特徴とするアクセス権管理システム。
- 請求項27に記載のアクセス権管理システムであって、前記設定データには一つないし複数のアプリケーション装置に帰属する公開鍵暗号の公開鍵を含み、一方、個別のアプリケーション装置は、前記公開鍵に対応する秘密鍵(個人鍵、私有鍵、プライベート鍵ともいう)を保持する秘密鍵保持手段を含み、クライアント装置によるアプリケーション装置の特権の認証時に、該秘密鍵を用いて生成する通信データを送付することを特徴とするアクセス権管理システム。
- 請求項1〜28のいずれかに記載のアクセス権管理システムであって、前記チケットデータを生成する電子チケット生成装置を有し、前記電子チケット生成装置が、クライアント装置の供給者が提供するクライアント装置の証明データを評価するクライアント証明データ評価手段を含み、前記電子チケット生成装置は、前記証明データと前記クライアント証明データ評価手段からの出力のいずれか一方、もしくは、両方を用いてチケットデータを生成することで、前記証明データに記載された正当なクライアント装置のみに該チケットデータに基づいてサービスにアクセスするアクセス権を付与することを特徴とするアクセス権管理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002183739A JP3896909B2 (ja) | 2002-06-24 | 2002-06-24 | 電子チケットを用いたアクセス権管理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002183739A JP3896909B2 (ja) | 2002-06-24 | 2002-06-24 | 電子チケットを用いたアクセス権管理装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004032220A JP2004032220A (ja) | 2004-01-29 |
JP3896909B2 true JP3896909B2 (ja) | 2007-03-22 |
Family
ID=31179803
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002183739A Expired - Fee Related JP3896909B2 (ja) | 2002-06-24 | 2002-06-24 | 電子チケットを用いたアクセス権管理装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3896909B2 (ja) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4681819B2 (ja) * | 2004-03-30 | 2011-05-11 | パイオニア株式会社 | コンテンツ取引システム、コンテンツ取引方法、コンテンツ配信制御用の媒体およびプログラム |
KR100677344B1 (ko) * | 2004-07-29 | 2007-02-02 | 엘지전자 주식회사 | 권리객체 처리를 위한 메시지 및 이를 이용한 권리객체 처리 방법 및 시스템 |
JP4602099B2 (ja) * | 2005-01-25 | 2010-12-22 | 日本電信電話株式会社 | アクセスコード発行システム、アクセスコード発行方法およびアクセスコード発行プログラム |
JP4645302B2 (ja) * | 2005-05-23 | 2011-03-09 | 富士ゼロックス株式会社 | 顧客管理装置及びプログラム |
BRPI0614667A2 (pt) * | 2005-08-12 | 2011-04-12 | Lg Electronics Inc | método para mover objeto de direitos em gerenciamento de direitos digitais |
JP4801417B2 (ja) * | 2005-10-28 | 2011-10-26 | 日本電信電話株式会社 | Vod制御方法,映像コンテンツ視聴準備方法,映像コンテンツ公開方法,vodサーバ,vodシステム,映像コンテンツ視聴システム,映像コンテンツ公開システム |
JP5129313B2 (ja) * | 2010-10-29 | 2013-01-30 | 株式会社東芝 | アクセス認可装置 |
JP6285474B2 (ja) * | 2016-01-28 | 2018-02-28 | ヤフー株式会社 | 管理装置、管理方法、プログラム、端末装置、および制御方法 |
KR101999188B1 (ko) * | 2016-02-23 | 2019-07-11 | 엔체인 홀딩스 리미티드 | 비밀 공유를 위한 타원 곡선 암호를 사용하는 개인용 장치 보안 |
JP7029051B2 (ja) * | 2017-12-22 | 2022-03-03 | 富士通株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
JP7234849B2 (ja) | 2019-08-05 | 2023-03-08 | 富士通株式会社 | 情報処理装置、アクセス制御システム及びアクセス制御プログラム |
JP7019087B2 (ja) * | 2020-07-20 | 2022-02-14 | 株式会社メディアドゥ | ブロックチェーンを活用したデジタルコンテンツのアクセス権保証の為の、コンテンツ管理システム、コンテンツ管理プログラム及びコンテンツ管理方法 |
CN112948874B (zh) * | 2021-02-10 | 2023-04-18 | 上海凯馨信息科技有限公司 | 一种密态数据访问方法 |
-
2002
- 2002-06-24 JP JP2002183739A patent/JP3896909B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2004032220A (ja) | 2004-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5695120B2 (ja) | システム間シングルサインオン | |
US8843415B2 (en) | Secure software service systems and methods | |
JP5165598B2 (ja) | 秘密鍵とのアカウントリンク | |
US20180359092A1 (en) | Method for managing a trusted identity | |
Claessens et al. | (How) can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions | |
JP4274421B2 (ja) | 擬似匿名によるネットワーク上におけるユーザーおよびグループ認証方法およびシステム | |
US7293098B2 (en) | System and apparatus for storage and transfer of secure data on web | |
JP4971572B2 (ja) | 電子商取引での取引の容易化 | |
US8019881B2 (en) | Secure cookies | |
US20010020228A1 (en) | Umethod, system and program for managing relationships among entities to exchange encryption keys for use in providing access and authorization to resources | |
JP2019511147A (ja) | デジタルコンテンツの制御及び配信のためのブロックチェーンにより実施される方法 | |
JP4548441B2 (ja) | コンテンツ利用システム、及びコンテンツ利用方法 | |
JP2003531447A5 (ja) | ||
JP2004537095A (ja) | 情報セキュリティシステム | |
JP2004509399A (ja) | ネットワークにわたって配布されるオブジェクトを保護するためのシステム | |
US7194759B1 (en) | Used trusted co-servers to enhance security of web interaction | |
JP3896909B2 (ja) | 電子チケットを用いたアクセス権管理装置 | |
Hwang et al. | Securing on-line credit card payments without disclosing privacy information | |
Guo et al. | Using blockchain to control access to cloud data | |
CA3050487A1 (en) | System and method for storing and distributing consumer information | |
US20220318356A1 (en) | User registration method, user login method and corresponding device | |
KR100612925B1 (ko) | 공인 인터넷 아이디 서비스 시스템 및 운영방법 | |
JP3999527B2 (ja) | コンピュータネットワークの認証方法及びデータ配信方法 | |
TW200941996A (en) | Using mobile device to construct a secure E-DRM method | |
Davidson et al. | Content sharing schemes in DRM systems with enhanced performance and privacy preservation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040122 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20040315 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050906 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051107 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060815 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061006 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061128 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061211 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110105 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120105 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120105 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130105 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130105 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140105 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |