JP3641909B2 - 証明データ生成装置 - Google Patents
証明データ生成装置 Download PDFInfo
- Publication number
- JP3641909B2 JP3641909B2 JP18880197A JP18880197A JP3641909B2 JP 3641909 B2 JP3641909 B2 JP 3641909B2 JP 18880197 A JP18880197 A JP 18880197A JP 18880197 A JP18880197 A JP 18880197A JP 3641909 B2 JP3641909 B2 JP 3641909B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- proof
- authentication
- access
- user
- 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
Images
Landscapes
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ユーザの権限を証明するために生成された証明データの正当性を検証することによりユーザのアクセス資格を認証する技術に関し、とくに上記証明データを生成する証明データ生成装置に関するものである。
【０００２】
【従来の技術】
本発明と同分野に属する先行技術としてプログラムの実行制御技術が知られている。プログラム実行制御技術は、
▲１▼アプリケーションプログラム中にユーザ認証のためのルーチンを埋め込み、
▲２▼該ルーチンはアプリケーションの実行を試みているユーザが正規の認証用の鍵を保有していることを検査し、
▲３▼前記認証用の鍵の存在が確認された場合に限りプログラムを続行し、それ以外の場合にはプログラムの実行を停止する
技術である。
【０００３】
このような技術を利用することにより、認証鍵を保有する正規のユーザにのみアプリケーションプログラムの実行を可能ならしめることが出来る。当技術はソフトウェア頒布事業において実用化されており、製品として、例えばＲａｉｎｂｏｗ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．社のＳｅｎｔｉｎｅｌＳｕｐｅｒＰｒｏ（商標）や、Ａｌａｄｄｉｎ Ｋｎｏｗｌｅｄｇｅ Ｓｙｓｔｅｍｓ Ｌｔｄ．社のＨＡＳＰ（商標）等がある。
【０００４】
これらの技術では、ユーザの認証鍵は、ソフトウェアベンダが、複製を防ぐためにハードウェア中のメモリに厳重に封入し、郵便などの物理的手段を用いてユーザに配布し、ユーザはこれを所有のパソコンなどに装着して利用する。
【０００５】
これらの技術は、アプリケーションプログラムを作成する際に、プログラム作成者がユーザが持つ認証鍵を予め想定した上で、該認証鍵に基づいてプログラムの保護処理を行わなければならない。つまり、プログラム作成者は、鍵内蔵ハードウェアからの正しい返信をプログラム作成時に予測して、正しい返信を受けた場合にのみプログラムが正常に動作するようにプログラムの作成を行わなければならない。
【０００６】
このような特徴を有する従来技術の利用形態は、基本的に以下の２通りとなる。
【０００７】
▲１▼第１の方法では、ユーザの認証鍵をユーザ毎に異なるように用意する。即ち、ユーザ甲には認証鍵甲、ユーザ乙には認証鍵乙というように、ユーザ毎に異なる認証鍵を一つずつ用意する。
【０００８】
▲２▼第２の方法では、プログラム作成者はアプリケーション毎にそれぞれ異なる認証鍵を用意する。即ち、アプリケーション甲には認証鍵甲、アプリケーション乙には認証鍵乙というように、アプリケーション毎に異なる認証鍵を一つずつ用意し、固有の認証鍵を識別するように各アプリケーションプログラムを作成する。
【０００９】
しかし、これらのいずれの場合にも、以下に述べるような問題を有する。
【００１０】
第１の方法の場合、プログラム作成者は、プログラム中の認証ルーチンをユーザ毎に適切に変えてプログラムを作成する必要がある。つまり、ユーザ毎に認証鍵が異なるので、プログラム中の認証ルーチンは該プログラムを利用するユーザ固有の認証鍵を識別するように作成されなければならず、プログラム作成者は利用ユーザの数だけ異なるプログラムを作成する必要がある。
【００１１】
対象となるユーザが多数の場合、プログラムをユーザ毎に個別化する作業はプログラム作成者にとって耐えがたい労力を要求し、管理しなければならないユーザ認証鍵のリストも膨大なものとなる。
【００１２】
第２の方法の場合、第１の方法の場合のようにユーザ毎にプログラムを個別的に作成する必要は無くなるが、逆に、ユーザは利用するアプリケーションの数だけ認証鍵を保持しなければならないこととなる。
【００１３】
この制約はプログラム作成者及びユーザそれぞれに以下のような問題を惹起する。
【００１４】
前述のように、認証鍵はハードウェアに厳重に封入した状態でユーザに配布する必要がある。従って、プログラム自身はネットワークを介して簡便に配布することができるのと対照的に、認証鍵を内蔵するハードウェアの配布は郵便等の物理手段に頼らざるを得ない。この制限は、コスト、時間、梱包の手間いずれをとっても、プログラム作成者とって大きな負担となる。
【００１５】
プログラム作成者は、ユーザの要求に応えるべく、アプリケーション毎に異なるハードウェアを一定個数ストックしておかなければならず、在庫管理のコストを必要とする。
【００１６】
また、ユーザは利用するアプリケーションを変更する度にハードウェアを交換しなければならないという煩雑さに甘んじなければならない。
【００１７】
ユーザがあるアプリケーションを使いたいとしても、認証鍵が封入されたハードウェアが届くまで待たねばならず、即座に利用できないという点での不便さも生ずる。
【００１８】
この問題を解決する技術として、本出願人は新たなアクセス資格検証手法を提案している（特願平０８−０６２０７６号、現在未公開）。
【００１９】
特願平０８−０６２０７６号の提案では、証明用補助情報（アクセスチケット）を導入することにより、アクセス資格認証の特徴情報とユーザ固有情報とを独立させ、プロテクト側も、ユーザ側も１つの固有情報を準備しておけばすむようにしている。
【００２０】
アクセスチケットは、特定のユーザの固有情報とアクセス資格認証の特徴情報とに基づいて計算されるデータであり、また、ユーザ固有情報を知らずに、アクセスチケットからアクセス資格認証の特徴情報を計算することは困難である。そして、ユーザ固有情報とアクセスチケットとの正しい組み合わせ、すなわち、ユーザ固有情報と該ユーザ固有情報に基づいて計算されたアクセスチケットの組み合わせが入力された場合に限って、正しい証明用データが計算される。
【００２１】
したがってユーザはあらかじめ固有情報を保持し、プログラム作成者等のプロテクト者はユーザが所持する固有情報とは独立にアクセス資格認証の特徴情報を用意し、アクセスチケットをユーザの固有情報とアプリケーションプログラムの作成等に使用したアクセス資格認証の特徴情報とに応じて作成し、配布することにより、実行制御等のユーザのアクセス資格の認証を行う事ができる。
【００２２】
この技術を用いて、アプリケーションプログラムにプロテクトを行ってユーザに配布し、アプリケーションプログラムの利用を希望するユーザに、アクセスチケットを提供するサービスが考えられる。
【００２３】
希望するユーザに、ユーザ毎に異なる固有情報を封入したＩＣカードなどの媒体を渡しておき、またプログラム作成者はアクセス資格認証の特徴情報を用いてプログラムにプロテクトをかけて配布し、プログラムの利用を希望するユーザに、プログラム作成者またはプログラム作成者から委託を受けたチケット発行業者がアクセスチケットを提供する。
【００２４】
このようなサービスを考えた場合、いつどのようにして課金するかということが問題になる。この例の場合では、アクセスチケットを発行する際に、チケットの発行と引換えにプログラムの代金に相当する料金を徴収することができる。
【００２５】
ところで、このようなプログラムの利用権の売買サービスを考える場合、以下のような権利の形態が考えられる。
▲１▼パーチェス（ｐｕｒｃｈａｓｅ）：利用権を買いとってしまう方法。一度購入すると、永久に利用することができる。その後、利用する、しないにかかわらず、料金は同じである。
▲２▼ペイ・パー・ユース（ｐａｙ−ｐｅｒ−ｕｓｅ）：利用量課金とも呼ばれる。利用した量に応じて課金される。
▲３▼レント（ｒｅｎｔ）：一定期間の利用権を購入する。期限が過ぎれば利用できなくなる。
【００２６】
前述の特願平０８−０６２０７６号の技術を用いた場合、パーチェスを実現することは容易であるが、レントを実現するのは困難である。
【００２７】
ペイ・パー・ユースについては、利用する度毎にユーザが利用希望をチケット発行業者へ提出し、チケット発行業者は１回のみ使用可能なアクセスチケットを発行することにより実現することが可能であるが、頻繁にチケット発行操作が必要になる上に、１回のみ使用可能なアクセスチケットを実現するために、ユーザのＩＣカード中に使用したチケットに対するログを記録していく必要があるため、あまり現実的ではない。
【００２８】
この問題に対しては、本出願人は利用制御情報をアクセスチケットの資格認証手法に導入することを提案している（特願平０８−１９１７５６号、現在未公開）。特願平０８−１９１７５６号の手法では、特願平０８−０６２０７６号に利用制御情報を導入し、情報を復号化する際に、この利用制御情報も用いるものである。利用制御情報の例としては、使用期限、使用可能回数、総使用可能時間、使用上限金額、処理の履歴を取るか否かの情報などが記載されている。
【００２９】
利用制御情報が使用期限の場合には、レントを実現することが可能である。
【００３０】
また利用制御情報が処理の履歴を取るという情報の場合には、一定期間後にその履歴を回収して集計することにより、利用した回数を計算し課金するという方法で、ペイ・パー・ユースに近い機能を実現することができる。さらに利用制御情報に１回あたりの利用額を記載するようにすれば、柔軟なペイ・パー・ユースを実現することが可能になる。
【００３１】
つまり特願平０８−１９１７５６号の手法では、前述した権利の形態パーチェス、ペイ・パー・ユースおよびレントを全部実現できることになる。
【００３２】
次に、支払の方法について考える。支払の方法としては、以下の２つが考えられる。
【００３３】
▲１▼チケット発行時に支払う方法：
チケット発行業者がアクセスチケットを発行する際に、支払う方法。
電子貨幣により支払う場合や、発行業者側で料金を記録し、銀行振り込みなどにより清算を行う場合などがある。
【００３４】
▲２▼プリペイドで支払う方法：
ユーザが予めプリペイド度数を購入して、ＩＣカード中などに保持しておき、購入の際や利用の際に、プリペイドから相当する度数を引き落とす。
【００３５】
特願平０８−１９１７５６号の技術を用いると、▲１▼チケット発行時に支払う方法で、前述した権利の形態パーチェス、ペイ・パー・ユースおよびレントを全部実現できる。
【００３６】
他方、▲２▼プリペイドで支払う方法では、ペイ・パー・ユースは容易に実現できる。つまり、利用制御情報に１回あたりの利用額を記載し、認証を行う度に、保持しているプリペイド情報から、利用制御情報記載の度数分ずつ引き落とせばよい。
【００３７】
しかし、▲２▼プリペイドで支払う方法で、パーチェスやレントを実現するのは困難である。パーチェスは最初の利用時にのみプリペイドによる課金を行い、２回目以降の利用時には課金を行わないという処理が必要なためである。
【００３８】
パーチェスに関しては、利用制御情報に利用権の買取り額を記載しておき、最初の利用時にその額を保持しているプリペイド情報から引き落として、該利用したアクセスチケットの情報をＩＣカードに登録するようにし、２回目以降の利用時には、利用しようとするチケットが既にＩＣカードに登録されているかをチェックして、登録されている時にはプリペイド情報から引き落とさないように構成することで実現することも可能ではある。しかし、この登録情報は、非常に長い期間消すことはできないので、多くのチケットを使うような場合には、ＩＣカードの記憶容量が不足することになり、あまり現実的な解決策ではない。
【００３９】
レントの場合も、利用制御情報にレンタル額と有効期限を記載しておき、パーチェスと同様の方法を取ることで、実現することは可能ではあるが、同じくＩＣカードの記憶容量が不足することになり、あまり現実的な解決策ではない。
【００４０】
【発明が解決しようとする課題】
本発明は、以上のような問題点に鑑みなされたものであり、プリペイドで支払う方法においても、証明データ生成装置（ＩＣカード）側に余分な負荷をかけることなく、パーチェスやレントを実現することを可能にすることを課題とする。
【００４１】
【課題を解決するための手段】
本発明によれば、上述の課題を解決するために、ユーザのアクセス資格を認証するために生成され、正当性を検証される証明データを生成する証明データ生成装置に、認証用データを入力する認証用データ入力手段と、ユーザの固有情報を記憶するユーザ固有情報記憶手段と、ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス条件を記述した利用条件情報とに対し、所定の計算を実行して生成した証明用補助情報と、利用条件情報との組を含む証明用補助情報セットを記憶する証明用補助情報セット記憶手段と、入力された認証用データに対応する証明用補助情報セットを上記証明用補助情報セット記憶手段から取り出し、上記取り出した証明用補助情報セットの利用条件情報に従い、以降の処理を継続するかどうかの判断を行う利用条件判断手段と、上記利用条件判断手段において継続と判断されたときに、上記取り出した証明用補助情報セットと、上記認証用データ入力手段から入力された認証用データと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報とに所定の計算を施して証明データを生成し出力する証明データ生成出力手段とを設け、上記認証用データ入力手段から、第１の証明用補助情報セットを暗号関数における暗号化鍵で暗号化した暗号化証明用補助情報セットを入力し、上記利用条件判断手段は、上記証明用補助情報セット記憶手段から、入力された暗号化証明用補助情報セットに対応する第２の証明用補助情報セットを取り出し、上記取り出した第２の証明用補助情報セットの利用条件情報に従い、所定の処理を行った後、以降の処理を継続するかどうかの判断を行い、上記証明データ生成出力手段は、上記処理を行うことにより、上記暗号化証明用補助情報セットを復号化した結果である第１の証明用補助情報セットを出力するようにしている。
【００４２】
つまり、通常の証明用補助情報セット（アクセスチケット）である第１の証明用補助情報セットを暗号化して暗号化証明用補助情報セットを作成しておき、この暗号化証明用補助情報セットへアクセスするための第２の証明用補助情報セットを用いて、通常の認証処理と全く同じ処理を行うことにより、暗号化証明用補助情報セットから、第１の証明用補助情報セットを復号化する。
【００４３】
このように構成することにより、利用料金が無料のチケット（第１の証明用補助情報セット）を作成して暗号化し、暗号化されたチケットを復号化するためのチケット（第２の証明用補助情報セット）を発行し、このチケット（第２の証明用補助情報セット）の利用料金を有料としプリペイドで支払うように構成することで、全体としてプリペイドにおけるパーチェス機能の実現を可能にする。
【００４４】
レント機能は、これに加えて第２の証明用補助情報セットの利用条件情報に有効期限情報を記載することで実現可能である。
【００４５】
なお、暗号化されたチケットを復号化するには、通常のチケットの認証処理と同じ処理を行うように構成したので、比較的容量の少ないＩＣカード内に、余分なプログラムやデータを入れることなく、効率的に実現することが可能である。
【００４６】
【発明の実施の形態】
以下、この発明の実施例について説明する。
【００４７】
図１はこの実施例の構成図を示す。この実施例では、証明データ生成装置内にプリペイド情報を保持し、そのプリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する例（パーチェス）について説明する。
【００４８】
図１では、証明データ生成装置で生成され出力された証明データを検証する証明データ検証装置を含めて示す。
【００４９】
まず、図１に基づいて、本実施例の構成について説明したあと、証明データ検証装置、証明データ生成装置の処理の流れをフローチャートで示しながら説明する。処理の流れの説明には、通常の認証処理を例にして説明し、利用条件情報Ｌには、１回の利用の度ごとにプリペイドから引き落とされる例について説明する。そして、通常の認証処理の説明の後に、アプリケーションプログラムのアクセス権を購入する例（パーチェス）について説明する。
【００５０】
［実施例の構成］
図１は実施例の構成を全体として示すものであり、この図において、証明データ生成装置１０はユーザが保持するものであり、例えばＩＣカードのように内部に計算機能を持った携帯型の装置である。ＩＣカード以外にも、計算機能を持ったＰＣカードや、携帯型情報ツール、あるいはサブノートパソコンなどでもよい。内部の情報が、外部から簡単に改竄されたりすることがないように防御されていることが望ましい。
【００５１】
証明データ検証装置２０はユーザがアプリケーションプログラムを使用するパソコンであり、パソコンのスロットに証明データ生成装置１０であるＩＣカードを装着して使用する。
【００５２】
証明データ検証装置２０は、大きく認証用データ生成部２１と証明データ検証部２２とから構成されている。認証用データ生成部２１は、認証が必要な時に、認証用データを生成して、証明データ生成装置１０に送付する。証明データ検証部２２は、証明データ生成装置１０から送り返された証明データが正しいかどうかを検証する。
【００５３】
アプリケーションプログラムは、暗号化などによりプロテクトされており、ユーザがアプリケーションプログラムを利用しようとすると、証明データ検証装置２０は、そのアプリケーションプログラムに対応した認証用データを作成し、証明データ生成装置１０に送り、証明データ生成装置１０から送り返された証明データを検証して、正しいと検証された場合に限り、アプリケーションプログラムのプロテクトを解除して、利用することを可能にする。
【００５４】
一方、証明データ生成装置１０は、ユーザ固有情報記憶部１１、度数情報保持部１２、アクセスチケット記憶部１３、認証用データ入力部１４、利用条件判断部１５、証明データ生成出力部１６を含んで構成される。
【００５５】
ユーザ固有情報記憶部１１は、ユーザの秘密情報を保持する部分であり、ユーザ毎に異なる情報である。ユーザ固有情報は、証明データ生成装置１０が作成された時に封入され、ユーザにも取り出せないように構成されていることが望ましい。
【００５６】
度数情報保持部１２は、プリペイド情報を保持する部分であり、アプリケーションプログラムの利用や購入などに応じて、必要な額が減額されていく。額が少なくなった時には、増額することも可能である。増額の方法は、例えば、特願平９−２１３７３号で提案されている手法を用いることができる。この手法では、度数情報と署名した度数情報とを用いて度数情報を増額する。度数情報保持部１２における額の増減は、安全に行われることが必要であり、定められた方法以外でのアクセスができないように構成することが望ましい。
【００５７】
アクセスチケット記憶部１３は、複数のアクセスチケットを記憶している。アクセスチケットは、ユーザにアクセス資格を与えるものであり、アプリケーションプログラム作成者、またはアプリケーションプログラム作成者から委託を受けたチケット発行業者によって作成される。本実施例では、アクセスチケットは、ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス資格認証のアクセス条件を記述した利用条件情報とに対し、所定の計算を実行して計算された証明用補助情報と利用条件情報との組である。本実施例では、アクセスチケット記憶部は、ＩＣカード中に構成されているが、アクセスチケットは発行された本人しか使えないため、コピーは自由であり、ＩＣカード外部に構成しても構わない。
【００５８】
認証用データ入力部１４は、証明データ検証装置２０から送られた認証用データを入力する部分である。
【００５９】
利用条件判断部１５は、入力された認証用データに対応するアクセスチケットをアクセスチケット記憶部１３から取り出し、アクセスチケット中の利用条件情報を元に、利用条件を判断する。例えば、アクセスチケットの有効期限が切れていないか、利用料金は保持しているプリペイドで支払うのに足りているか、などの利用条件を判断し、以降の処理を継続するか否かを判断する。
【００６０】
証明データ生成出力部１６は、利用条件判断部１５で継続と判断された時のみ、証明データを生成して出力する。証明データは、利用条件判断部１５で取り出したアクセスチケット中の証明用補助情報と、認証用データと、ユーザの固有情報とに所定の計算を施して作成する。
【００６１】
次に、具体例を挙げて、さらに詳細に説明する。ここでの説明は、通常の認証処理を例にして説明し、利用条件情報Ｌには、１回の利用の度ごとにプリペイドから引き落とされる例について説明する。
【００６２】
図２は、図１の構成図に記号を付けたものである。記号は以下の説明と対応している。
【００６３】
［通常の認証処理］
以下では、法ｎにおけるＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｅｌｍａｎ）暗号を用いた例について詳細に説明する。まず、通常の認証処理について説明する。以下の例では、アプリケーションプログラムの作成者であるソフトウェアベンダが、ＩＣカードの発行からチケットの発行まですべてを行う例について説明する。この例ではソフトウェアベンダは、すべてのユーザの秘密情報ｄｕを知っている。これ以外にも、ＩＣカードの発行とチケットとをチケット発行業者が行う構成も可能である。
【００６４】
ソフトウェアベンダは、プロテクトしたいアプリケーションプログラムに対する暗号鍵を作成する。ここではＲＳＡ暗号を用いるので、大きな素数ｐ，ｑを秘密に作成し、法数ｎをｎ＝ｐ・ｑとして作成する。次に法数ｎの元で暗号鍵Ｅと復号鍵Ｄを、
【００６５】
【数１】
ＥＤ≡１ ｍｏｄ φ（ｎ）
を満たすように生成する。ここでφ（ｎ）はオイラー数であり、φ（ｎ）＝（ｐ−１）（ｑ−１）である。
【００６６】
次にソフトウェアベンダは、共通暗号鍵Ｋを作り、プロテクトしたいアプリケーションプログラムの一部または全部を、Ｋで暗号化し、
【００６７】
【数２】
Ｋ’＝ＫE ｍｏｄ ｎ
を計算して、Ｋ’を暗号化したアプリケーションプログラムに、第３者が取り出せないように埋め込んで配布する。
【００６８】
このアプリケーションプログラムを利用したいユーザは、予めこれに対応するアクセスチケットを入手しておくことになる。
【００６９】
ソフトウェアベンダは、ユーザからのアクセスチケット発行要求を受けて、アクセスチケットを発行する。ソフトウェアベンダは、要求したユーザの秘密情報ｄｕと、アプリケーションプログラムの暗号化の際に用いた暗号鍵（Ｅ，ｎ）に対応する復号鍵（Ｄ，ｎ）とをデータベースから取り出す。次にアクセスチケットに付与する利用条件情報Ｌを作成する。ここではプリペイドから引き落として課金するので、１回の利用について引き落とす利用額をＬとする。
そして、これらの情報を用いて、
【００７０】
【数３】
ｔ＝Ｄ−Ｆ（ｎ，Ｌ，ｄｕ）
として証明用補助情報ｔを作成する。ここで関数Ｆ（）は一方向性の関数であり、一方向性ハッシュ関数ＭＤ５、ＳＨＡなどや、共通鍵暗号ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などを用いることができる。
【００７１】
ソフトウェアベンダは、（ｔ，Ｌ，ｎ）の組をアクセスチケットとしてユーザに発行する。
【００７２】
ユーザが、アプリケーションプログラムを利用しようとすると、証明データ検証装置は、そのアプリケーションプログラムに対応した認証用データ（Ｃ，ｎ）を作成し、証明データ生成装置に送る。
【００７３】
この処理の流れを図３のフローチャートに示し、これに基づいて説明する。
（ステップＳ１１）：証明データ生成部２１は、プロテクトされたアプリケーションプログラムから、Ｋ’とｎとを取り出す。
（ステップＳ１２）：証明データ生成部は、乱数ｒを生成し、乱数保持部に格納する。
（ステップＳ１３）：Ｃ＝ｒEＫ’ ｍｏｄ ｎを計算する。
（ステップＳ１４）：（Ｃ，ｎ）の組を認証用データとして証明データ生成装置１０に送付する。
【００７４】
次に、証明データ生成装置１０の流れを図４に示し、これに基づいて証明データ生成装置１０の処理を説明する。
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｃ，ｎ）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎをキーにしてアクセスチケット記憶部を検索し、アクセスチケット（ｔ，Ｌ，ｎ）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ（利用額）と、度数情報保持部の度数情報Ｖとを比較する。
（ステップＳ２４〜Ｓ２５）：Ｖ≧Ｌの時は、証明データ生成出力部１６は、（ステップＳ２６）に進む。そうでないときは、証明データ生成出力部は、エラーを出力して終了する。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件（利用額）Ｌの分だけ減額する。
（ステップＳ２６〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ、利用条件Ｌ（利用額）と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【００７５】
【数４】
Ｒ’＝ＣF(n,L,du) ｍｏｄ ｎ
Ｒ＝ＣtＲ’ ｍｏｄ ｎ
図４では、証明データＲを計算するのに、一旦Ｒ’の計算を分けている。これは、Ｒ’の計算にはユーザの秘密情報を用いるため、その処理が外部に漏れないように計算する必要があるが、一旦Ｒ’の計算が終われば、Ｒの計算は外部で行っても構わないためである。このようにＲ’とＲとに分けて計算してもよいし、一度に計算しても構わない。
【００７６】
次に、証明データ検証装置２０の証明データ検証部の処理について説明する。証明データ生成装置１０から出力された証明データＲは、正しいユーザ固有情報ｄｕと、正しいアクセスチケット（正しい証明用補助情報ｔ、正しい利用条件Ｌ）を用いて計算されたときには、
【００７７】
【数５】
となる。
【００７８】
そこで、証明データ検証部２２では、乱数保持部２３から乱数ｒを取り出し、
【００７９】
【数６】
ｒ-1Ｒ ｍｏｄ ｎ
を計算することで、アプリケーションを暗号化していた共通暗号鍵Ｋを入手することができる。証明データ検証装置は、この共通暗号鍵Ｋでアプリケーションの暗号化されていた部分を復号し、アプリケーションを実行することができる。
【００８０】
この例では、証明データ検証装置は、アプリケーションが正しく実行できたことをもって、正しく検証ができたと判断する。
【００８１】
以上で通常の認証処理の説明を終了する。
【００８２】
［パーチェス］
次に、プリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する（パーチェス）例について説明する。
【００８３】
この機能を実現するには、通常のアクセスチケットである第１のアクセスチケットを暗号化して暗号化アクセスチケットを作成しておき、この暗号化アクセスチケットへアクセスするための第２のアクセスチケットを用いて、通常の認証処理と全く同じ処理を行うことにより、暗号化アクセスチケットから、第１のアクセスチケットを復号化する。
【００８４】
そしてこのとき、第１のアクセスチケットは、利用料金が無料のチケットとして作成し、第２のアクセスチケットは、利用料金を有料としプリペイドで支払うように構成することで、全体としてプリペイドにおけるパーチェス機能の実現を可能にする。
【００８５】
まず、パーチェスの機能を実現したいアプリケーションプログラムをＡＰ１とする。上述の説明と同様に、ＡＰ１をプロテクトする。
【００８６】
＜アプリケーションプログラムＡＰ１のプロテクトの説明＞
ソフトウェアベンダは、プロテクトしたいアプリケーションプログラムに対する暗号鍵を作成する。ここではＲＳＡ暗号を用いるので、大きな素数ｐ1，ｑ1を秘密に作成し、法数ｎ1をｎ1＝ｐ1・ｑ1として作成する。次に法数ｎ1の元で暗号鍵Ｅ1と復号鍵Ｄ1を、
【００８７】
【数７】
Ｅ1・Ｄ1≡１ ｍｏｄ φ（ｎ1）
を満たすように生成する。ここでφ（ｎ1）はオイラー数であり、φ（ｎ1）＝（ｐ1−１）（ｑ1−１）である。
【００８８】
次にソフトウェアベンダは、共通暗号鍵Ｋ1を作り、プロテクトしたいアプリケーションプログラムの一部または全部をＫ1で暗号化し、さらに共通暗号鍵Ｋ1を以下の式に従って、暗号鍵Ｅ1で暗号化して、Ｋ1’を生成する。
【００８９】
【数８】
Ｋ1’＝Ｋ1Ｅ1 ｍｏｄ ｎ1
そして、Ｋ1’を暗号化したアプリケーションプログラムに、第３者が容易に取り出せないように埋め込んで配布する。また、ｎ1も、暗号化したアプリケーションプログラムに埋めこむ。
【００９０】
ソフトウェアベンダは、作成した（ｎ1，Ｄ1，φ（ｎ1））の組をアクセスチケット情報データベースに記憶する。
【００９１】
次に、プリペイド払いパーチェス・チケットの作成について説明する。図５は、証明用補助情報生成装置３０の構成例を示したものである。この例では、第１の利用条件情報と第１の復号鍵とユーザ固有情報と第２の利用条件情報とを入力として、プリペイド払いパーチェス・チケットを出力する。図５において、入力部３１は、第１の利用条件情報と第１の復号鍵とユーザ固有情報と第２の利用条件情報とを入力する部分である。第１復号鍵記憶部３３は、入力部３１から入力された第１の復号鍵を記憶する部分である。第１の復号鍵は、アプリケーションプログラムＡＰ１の暗号化に用いた共通暗号鍵Ｋ1を暗号化した暗号鍵（Ｅ1，ｎ1）に対応する復号鍵（Ｄ1，ｎ1）である。
【００９２】
ユーザ固有情報記憶部３４は、入力部３１から入力されたユーザ固有情報を記憶する部分である。これは、ユーザの証明データ生成装置１０に格納されているものと同一のものである。
【００９３】
ユーザがチケットの発行を依頼する時には、ユーザの識別情報Ｕと、ユーザが利用を希望するアプリケーションプログラムＡＰ１から取り出したｎ1とを、ソフトウェアベンダに送る。ソフトウェアベンダは、ユーザの識別情報Ｕとユーザ固有情報ｄｕとを対応づけて保持しているユーザ情報データベースから、ユーザの識別情報Ｕに対応するユーザ固有情報ｄｕを検索することによってユーザ固有情報を得、また（ｎ，Ｄ，φ（ｎ））の組を保持しているアクセスチケット情報データベースから、ｎ1に対応する復号鍵（Ｄ1，ｎ1）を得て、証明用補助情報生成装置３０に入力する。
【００９４】
第１利用条件情報記憶部３２と第２利用条件情報記憶部３５は、それぞれ第１の利用条件情報と第２の利用条件情報とを記憶する部分である。第１の利用条件情報は、アプリケーションプログラムＡＰ１の利用条件を記述したものであり、第２の利用条件情報は、プリペイド払いパーチェス・チケットの利用条件を記述したものである。プリペイド払いパーチェス・チケットの場合には、１回目の利用時に課金され、２回目以降の利用時には課金されないという特性を持つので、第１の利用条件情報には少なくとも無料であることを意味する情報が含まれており、第２の利用条件情報には、少なくとも有料であることを意味する情報が含まれている。
【００９５】
第１チケット生成部３６は、入力された第１の利用条件情報と第１の復号鍵とユーザ固有情報とに所定の計算を実行してアクセスチケットを生成する部分である。
【００９６】
第１利用条件情報記憶部３２と第１復号鍵記憶部３３とユーザ固有情報記憶部３４と第１チケット生成部３６とからなる構成部分４１は、通常のアクセスチケットを生成するのと同様の構成をなしている。
【００９７】
第２の鍵生成部３７は、第１チケット生成部３６で生成された第１のアクセスチケットを暗号化するための鍵を生成する部分である。
【００９８】
暗号化部３８は、第１チケット生成部３６で生成された第１のアクセスチケットを、第２の鍵生成部３７で生成された暗号化鍵を用いて暗号化する部分である。
【００９９】
第２チケット生成部３９は、暗号化部３８で暗号化された暗号化アクセスチケットを復号化するために必要となる第２のアクセスチケットを生成する部分である。
【０１００】
チケット出力部４０は、暗号化部３８で暗号化された暗号化アクセスチケットと、第２チケット生成部３９で生成された第２のアクセスチケットとを組み合わせて、プリペイド払いパーチェス・チケットとして出力する。
【０１０１】
＜プリペイド払いパーチェス・チケットの作成＞
以下に、プリペイド払いパーチェス・チケットの作成の方法について図６のフローチャートを用いて説明する。
【０１０２】
ソフトウェアベンダは、ユーザからのプリペイド払いパーチェス・チケット発行要求を受けて、プリペイド払いパーチェス・チケットを発行する。チケットの発行を依頼するユーザは、ユーザの識別情報Ｕと、ユーザが利用を希望するアプリケーションプログラムＡＰ１から取り出したｎ1とを、ソフトウェアベンダに送る。
【０１０３】
（ステップＳ３１）：ソフトウェアベンダは、ユーザからのプリペイド払いパーチェス・チケット発行要求であるユーザの識別情報ＵとアプリケーションプログラムＡＰ１から取り出したｎ1との組（Ｕ，ｎ1）を入力する。また、アプリケーションプログラムＡＰ１の利用条件を記述した第１の利用条件情報Ｌ1と、プリペイド払いパーチェス・チケットの利用条件を記述した第２の利用条件情報Ｌ2も入力する。ここでは、プリペイド払いパーチェス・チケットの生成を目的としているので、第１の利用条件情報Ｌ1は、利用料金が無料であることを意味する
【０１０４】
【数９】
Ｌ1＝０
であり、第２の利用条件情報Ｌ２は、パーチェスの料金が有料であることを意味する
【０１０５】
【数１０】
Ｌ2＝Ａ
とする。ただしＡは０以外の数字であり、たとえば１００である。
【０１０６】
（ステップＳ３２）：ユーザの識別情報Ｕとユーザ固有情報ｄｕとを対応づけて保持しているユーザ情報データベースから、ユーザの識別情報Ｕに対応するユーザ固有情報ｄｕを検索する。
（ステップＳ３３）：（ｎ，Ｄ，φ（ｎ））の組を保持しているアクセスチケット情報データベースから、ｎ1に対応する第１の復号鍵（Ｄ1，ｎ1）を検索する。
（ステップＳ３４）：ユーザがＡＰ１にアクセスするための第１のアクセスチケットＴ1を作成する。
【０１０７】
【数１１】
Ｔ1＝（ｔ1，Ｌ1，ｎ1）
ｔ1＝Ｄ1−Ｆ（ｎ1，Ｌ1，ｄｕ）
（ステップＳ３５）：第１のアクセスチケットＴ1を暗号化するために、第２の法数ｎ2、第２の暗号鍵Ｅ2、第２の復号鍵Ｄ2を生成する。大きな素数ｐ2，ｑ2を生成し、以下の式が成り立つように、法数ｎ2、暗号鍵Ｅ2、復号鍵Ｄ2を生成する。
【０１０８】
【数１２】
ｎ2＝ｐ2・ｑ2
Ｅ2・Ｄ2≡１ ｍｏｄ φ（ｎ2）
φ（ｎ2）＝（ｐ2−１）（ｑ2−１）
（ステップＳ３６）：生成した第２の暗号鍵Ｅ2で第１のアクセスチケットＴ1を暗号化する。Ｔ1を暗号化したものをＴ1’とする。
【０１０９】
【数１３】
Ｔ1’＝Ｔ1Ｅ2 ｍｏｄ ｎ2
（ステップＳ３７）：暗号化されたアクセスチケットＴ1’をユーザが復号するための第２のアクセスチケットＴ2を作成する。
【０１１０】
【数１４】
Ｔ2＝（ｔ2，Ｌ2，ｎ2）
ｔ2＝Ｄ2−Ｆ（ｎ2，Ｌ2，ｄｕ）
（ステップＳ３８）：（（Ｔ1’，ｎ2），Ｔ2）を組にしてプリペイド払いパーチェス・チケットとして出力する。
【０１１１】
ソフトウェアベンダは、出力されたプリペイド払いパーチェス・チケット（（Ｔ1’，ｎ2），Ｔ2）を、ユーザに送付する。
【０１１２】
次に、プリペイド払いパーチェス・チケットの使用例について説明する。
【０１１３】
＜プリペイド払いパーチェス・チケットの使用例＞
（ａ）プリペイド払いパーチェス・チケット（（Ｔ1’，ｎ2），Ｔ2）を受け取ったユーザは、まずＴ2をアクセスチケット記憶部１３に格納する。
（ｂ）次に、（Ｔ1’，ｎ2）を自分が保持している証明データ生成装置１０の認証用データ入力部１４より入力する。
【０１１４】
以下、証明データ生成装置１０における処理が図４に従って行われる。今、証明データ生成装置１４の度数情報保持部１２には、８００度数のプリペイド情報Ｖが保持されているとする。（Ｖ＝８００）
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｔ1’，ｎ2）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎ2をキーにしてアクセスチケット記憶部１３を検索し、アクセスチケットＴ2＝（ｔ2，Ｌ2，ｎ2）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ2と、度数情報保持部１２の度数情報Ｖとを比較する。
（ステップＳ２４）：今、Ｌ2＝１００、Ｖ＝８００なので、
【０１１５】
【数１５】
Ｖ≧Ｌ2
が成り立ち、（ステップＳ２６）へ進む。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件Ｌ2の分だけ減額する。
【０１１６】
【数１６】
Ｖ＝８００−１００＝７００
つまり、度数情報Ｖは、プリペイド払いパーチェス・チケットの買取り料金として、１００度数引き落とされ、残り７００度数となる。
（ステップＳ２７〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ2、利用条件Ｌ2と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【０１１７】
【数１７】
Ｒ’＝Ｔ1’F(n2,L2,du) ｍｏｄ ｎ2
Ｒ＝Ｔ1’t2Ｒ’ ｍｏｄ ｎ2
Ｒの計算を行うと、
【０１１８】
【数１８】
という計算が成り立ち、証明データ生成出力部１６から、証明データＲとして
【０１１９】
【数１９】
Ｒ＝Ｔ1
が出力される。
【０１２０】
つまり、（Ｔ1’，ｎ2）を自分が保持している証明データ生成装置１０の認証用データ入力部１４より入力すると、Ｌ2が度数情報Ｖから引き落とされて、結果としてＴ1’が復号されたＴ1が出力される。
【０１２１】
（ｃ）ユーザは、入手したＴ1をアクセスチケット記憶部１３に格納する。
【０１２２】
（ｄ）ユーザは、アプリケーションプログラムＡＰ１を利用するためのアクセスチケットＴ1を入手できたので、アプリケーションプログラムＡＰ１を利用する。
【０１２３】
以下、証明データ検証装置１０における認証用データ生成処理が図３に従って行われる。
（ステップＳ１１）：認証用データ生成部２１は、プロテクトされたアプリケーションプログラムから、Ｋ1’とｎ1とを取り出す。
（ステップＳ１２）：認証用データ生成部２１は、乱数ｒを生成し、乱数保持部２３に格納する。
（ステップＳ１３）：Ｃ＝ｒEＫ1’ ｍｏｄ ｎ1を計算する。
（ステップＳ１４）：（Ｃ，ｎ1）の組を認証用データとして証明データ生成装置１０に送付する。
（ｅ）証明データ生成装置１０における処理が再び図４に従って行われる。
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｃ，ｎ1）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎ1をキーにしてアクセスチケット記憶部１３を検索し、アクセスチケットＴ1＝（ｔ1，Ｌ1，ｎ1）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ1と、度数情報保持部１２の度数情報Ｖとを比較する。
（ステップＳ２４）：今、Ｌ１＝０、Ｖ＝７００なので、
【０１２４】
【数２０】
Ｖ≧Ｌ1
が成り立ち、（ステップＳ２６）へ進む。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件Ｌ1の分だけ減額する。
【０１２５】
【数２１】
Ｖ＝７００−０＝７００
つまり、度数情報Ｖは、最初にプリペイド払いパーチェス・チケットの買取り料金として、１００度数引き落とされているので、２回目以降の利用では引き落とされず、残り７００度数のままとなる。
（ステップＳ２７〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ1、利用条件Ｌ1と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【０１２６】
【数２２】
Ｒ’＝ＣF(n1,L1,du) ｍｏｄ ｎ1
Ｒ＝Ｃt1Ｒ’ ｍｏｄ ｎ1
つまり、
【０１２７】
【数２３】
（ｆ）証明データ検証装置２０の証明データ検証部２２は通常の認証と同様に処理を行い、乱数保持部２３から乱数ｒを取り出し、
【０１２８】
【数２４】
ｒ-1Ｒ ｍｏｄ ｎ1
を計算することで、アプリケーションを暗号化していた共通暗号鍵Ｋを入手することができる。証明データ検証装置は、この共通暗号鍵Ｋでアプリケーションの暗号化されていた部分を復号し、アプリケーションを実行することができる。
【０１２９】
これ以降は、何度アプリケーションプログラムＡＰ１を実行しても、同様の処理が行われ、無料で利用することができる。
【０１３０】
以上説明したように、上記のように構成することで、プリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する（パーチェス）ことが可能になる。
【０１３１】
以上、プリペイドにおけるパーチェス機能の実現について説明した。
【０１３２】
これ以外にも、証明データ生成装置に時計を備え、第１のアクセスチケットの利用条件情報Ｌの中に、利用額が無料という情報に加えて、有効期限情報を記載し、第１のアクセスチケットの利用のたびに、時刻と比較することによって、プリペイドにおけるレント機能を実現することも可能である。
【０１３３】
さらに、別の例としては、証明データ生成装置に時計を備え、第２のアクセスチケットの利用条件情報Ｌの中に、有効期限情報を記載し、暗号化された第１のアクセスチケットの復号の際に、時刻と比較することによって、第１のアクセスチケットを配布（解凍）する期限を限定することなども可能である。
【０１３４】
また、本実施例では、ＲＳＡ暗号を元にして説明を行ったが、これに限らず他の暗号方式を用いても構わない。また、アクセスチケットの実現式もこれに限ることはない。
【０１３５】
【発明の効果】
実行制御等のユーザのアクセス資格の認証を行うに際して、ユーザはあらかじめ固有情報を保持し、プログラム作成者等のプロテクト者はユーザが所持する固有情報とは独立にアクセス資格認証の特徴情報を用意し、アクセスチケットをユーザの固有情報とアプリケーションプログラムの作成等に使用したアクセス資格認証の特徴情報とに応じて作成し、配布することにより、ユーザおよびプロテクト者の双方を、アクセス権情報管理のわずらわしさから開放させるという特徴を残したまま、従来は困難だったプリペイドにおけるパーチェス機能およびレント機能を実現することを可能にした。
【０１３６】
さらにこれらの機能を実現するにおいて、通常のチケットの認証処理と同じ処理を行うように構成したので、比較的容量の少ないＩＣカード内に、余分なプログラムやデータを入れることなく、効率的に実現することが可能である。
【図面の簡単な説明】
【図１】 本発明の実施例の構成を示すブロック図である。
【図２】 図１の構成を詳細に説明する図である。
【図３】 図１の証明データ検証装置の認証用データ生成処理を説明するフローチャートである。
【図４】 図１の証明データ生成装置の証明データ生成処理を説明するフローチャートである。
【図５】 図１の証明データの生成に用いるチケットを生成する証明用補助情報生成装置を示すブロック図である。
【図６】 図１の証明データの生成に用いるチケットの生成を説明する図である。
【符号の説明】
１０ 証明データ生成装置
１１ ユーザ固有情報記憶部
１２ 度数情報保持部
１３ アクセスチケット記憶部
１４ 認証用データ入力部
１５ 利用条件判断部
１６ 証明データ生成出力部
２０ 証明データ検証装置
２１ 認証用データ生成部
２２ 証明データ検証部
２３ 乱数保持部
３０ 証明用補助情報生成装置
３２ 第１利用条件情報記憶部
３３ 第１復号鍵記憶部
３４ ユーザ固有情報記憶部
３５ 第２利用条件記憶部
３６ 第１チケット生成部
３７ 第２の鍵生成部
３８ 暗号化部
３９ 第２チケット生成部
４０ チケット出力部
【発明の属する技術分野】
本発明は、ユーザの権限を証明するために生成された証明データの正当性を検証することによりユーザのアクセス資格を認証する技術に関し、とくに上記証明データを生成する証明データ生成装置に関するものである。
【０００２】
【従来の技術】
本発明と同分野に属する先行技術としてプログラムの実行制御技術が知られている。プログラム実行制御技術は、
▲１▼アプリケーションプログラム中にユーザ認証のためのルーチンを埋め込み、
▲２▼該ルーチンはアプリケーションの実行を試みているユーザが正規の認証用の鍵を保有していることを検査し、
▲３▼前記認証用の鍵の存在が確認された場合に限りプログラムを続行し、それ以外の場合にはプログラムの実行を停止する
技術である。
【０００３】
このような技術を利用することにより、認証鍵を保有する正規のユーザにのみアプリケーションプログラムの実行を可能ならしめることが出来る。当技術はソフトウェア頒布事業において実用化されており、製品として、例えばＲａｉｎｂｏｗ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．社のＳｅｎｔｉｎｅｌＳｕｐｅｒＰｒｏ（商標）や、Ａｌａｄｄｉｎ Ｋｎｏｗｌｅｄｇｅ Ｓｙｓｔｅｍｓ Ｌｔｄ．社のＨＡＳＰ（商標）等がある。
【０００４】
これらの技術では、ユーザの認証鍵は、ソフトウェアベンダが、複製を防ぐためにハードウェア中のメモリに厳重に封入し、郵便などの物理的手段を用いてユーザに配布し、ユーザはこれを所有のパソコンなどに装着して利用する。
【０００５】
これらの技術は、アプリケーションプログラムを作成する際に、プログラム作成者がユーザが持つ認証鍵を予め想定した上で、該認証鍵に基づいてプログラムの保護処理を行わなければならない。つまり、プログラム作成者は、鍵内蔵ハードウェアからの正しい返信をプログラム作成時に予測して、正しい返信を受けた場合にのみプログラムが正常に動作するようにプログラムの作成を行わなければならない。
【０００６】
このような特徴を有する従来技術の利用形態は、基本的に以下の２通りとなる。
【０００７】
▲１▼第１の方法では、ユーザの認証鍵をユーザ毎に異なるように用意する。即ち、ユーザ甲には認証鍵甲、ユーザ乙には認証鍵乙というように、ユーザ毎に異なる認証鍵を一つずつ用意する。
【０００８】
▲２▼第２の方法では、プログラム作成者はアプリケーション毎にそれぞれ異なる認証鍵を用意する。即ち、アプリケーション甲には認証鍵甲、アプリケーション乙には認証鍵乙というように、アプリケーション毎に異なる認証鍵を一つずつ用意し、固有の認証鍵を識別するように各アプリケーションプログラムを作成する。
【０００９】
しかし、これらのいずれの場合にも、以下に述べるような問題を有する。
【００１０】
第１の方法の場合、プログラム作成者は、プログラム中の認証ルーチンをユーザ毎に適切に変えてプログラムを作成する必要がある。つまり、ユーザ毎に認証鍵が異なるので、プログラム中の認証ルーチンは該プログラムを利用するユーザ固有の認証鍵を識別するように作成されなければならず、プログラム作成者は利用ユーザの数だけ異なるプログラムを作成する必要がある。
【００１１】
対象となるユーザが多数の場合、プログラムをユーザ毎に個別化する作業はプログラム作成者にとって耐えがたい労力を要求し、管理しなければならないユーザ認証鍵のリストも膨大なものとなる。
【００１２】
第２の方法の場合、第１の方法の場合のようにユーザ毎にプログラムを個別的に作成する必要は無くなるが、逆に、ユーザは利用するアプリケーションの数だけ認証鍵を保持しなければならないこととなる。
【００１３】
この制約はプログラム作成者及びユーザそれぞれに以下のような問題を惹起する。
【００１４】
前述のように、認証鍵はハードウェアに厳重に封入した状態でユーザに配布する必要がある。従って、プログラム自身はネットワークを介して簡便に配布することができるのと対照的に、認証鍵を内蔵するハードウェアの配布は郵便等の物理手段に頼らざるを得ない。この制限は、コスト、時間、梱包の手間いずれをとっても、プログラム作成者とって大きな負担となる。
【００１５】
プログラム作成者は、ユーザの要求に応えるべく、アプリケーション毎に異なるハードウェアを一定個数ストックしておかなければならず、在庫管理のコストを必要とする。
【００１６】
また、ユーザは利用するアプリケーションを変更する度にハードウェアを交換しなければならないという煩雑さに甘んじなければならない。
【００１７】
ユーザがあるアプリケーションを使いたいとしても、認証鍵が封入されたハードウェアが届くまで待たねばならず、即座に利用できないという点での不便さも生ずる。
【００１８】
この問題を解決する技術として、本出願人は新たなアクセス資格検証手法を提案している（特願平０８−０６２０７６号、現在未公開）。
【００１９】
特願平０８−０６２０７６号の提案では、証明用補助情報（アクセスチケット）を導入することにより、アクセス資格認証の特徴情報とユーザ固有情報とを独立させ、プロテクト側も、ユーザ側も１つの固有情報を準備しておけばすむようにしている。
【００２０】
アクセスチケットは、特定のユーザの固有情報とアクセス資格認証の特徴情報とに基づいて計算されるデータであり、また、ユーザ固有情報を知らずに、アクセスチケットからアクセス資格認証の特徴情報を計算することは困難である。そして、ユーザ固有情報とアクセスチケットとの正しい組み合わせ、すなわち、ユーザ固有情報と該ユーザ固有情報に基づいて計算されたアクセスチケットの組み合わせが入力された場合に限って、正しい証明用データが計算される。
【００２１】
したがってユーザはあらかじめ固有情報を保持し、プログラム作成者等のプロテクト者はユーザが所持する固有情報とは独立にアクセス資格認証の特徴情報を用意し、アクセスチケットをユーザの固有情報とアプリケーションプログラムの作成等に使用したアクセス資格認証の特徴情報とに応じて作成し、配布することにより、実行制御等のユーザのアクセス資格の認証を行う事ができる。
【００２２】
この技術を用いて、アプリケーションプログラムにプロテクトを行ってユーザに配布し、アプリケーションプログラムの利用を希望するユーザに、アクセスチケットを提供するサービスが考えられる。
【００２３】
希望するユーザに、ユーザ毎に異なる固有情報を封入したＩＣカードなどの媒体を渡しておき、またプログラム作成者はアクセス資格認証の特徴情報を用いてプログラムにプロテクトをかけて配布し、プログラムの利用を希望するユーザに、プログラム作成者またはプログラム作成者から委託を受けたチケット発行業者がアクセスチケットを提供する。
【００２４】
このようなサービスを考えた場合、いつどのようにして課金するかということが問題になる。この例の場合では、アクセスチケットを発行する際に、チケットの発行と引換えにプログラムの代金に相当する料金を徴収することができる。
【００２５】
ところで、このようなプログラムの利用権の売買サービスを考える場合、以下のような権利の形態が考えられる。
▲１▼パーチェス（ｐｕｒｃｈａｓｅ）：利用権を買いとってしまう方法。一度購入すると、永久に利用することができる。その後、利用する、しないにかかわらず、料金は同じである。
▲２▼ペイ・パー・ユース（ｐａｙ−ｐｅｒ−ｕｓｅ）：利用量課金とも呼ばれる。利用した量に応じて課金される。
▲３▼レント（ｒｅｎｔ）：一定期間の利用権を購入する。期限が過ぎれば利用できなくなる。
【００２６】
前述の特願平０８−０６２０７６号の技術を用いた場合、パーチェスを実現することは容易であるが、レントを実現するのは困難である。
【００２７】
ペイ・パー・ユースについては、利用する度毎にユーザが利用希望をチケット発行業者へ提出し、チケット発行業者は１回のみ使用可能なアクセスチケットを発行することにより実現することが可能であるが、頻繁にチケット発行操作が必要になる上に、１回のみ使用可能なアクセスチケットを実現するために、ユーザのＩＣカード中に使用したチケットに対するログを記録していく必要があるため、あまり現実的ではない。
【００２８】
この問題に対しては、本出願人は利用制御情報をアクセスチケットの資格認証手法に導入することを提案している（特願平０８−１９１７５６号、現在未公開）。特願平０８−１９１７５６号の手法では、特願平０８−０６２０７６号に利用制御情報を導入し、情報を復号化する際に、この利用制御情報も用いるものである。利用制御情報の例としては、使用期限、使用可能回数、総使用可能時間、使用上限金額、処理の履歴を取るか否かの情報などが記載されている。
【００２９】
利用制御情報が使用期限の場合には、レントを実現することが可能である。
【００３０】
また利用制御情報が処理の履歴を取るという情報の場合には、一定期間後にその履歴を回収して集計することにより、利用した回数を計算し課金するという方法で、ペイ・パー・ユースに近い機能を実現することができる。さらに利用制御情報に１回あたりの利用額を記載するようにすれば、柔軟なペイ・パー・ユースを実現することが可能になる。
【００３１】
つまり特願平０８−１９１７５６号の手法では、前述した権利の形態パーチェス、ペイ・パー・ユースおよびレントを全部実現できることになる。
【００３２】
次に、支払の方法について考える。支払の方法としては、以下の２つが考えられる。
【００３３】
▲１▼チケット発行時に支払う方法：
チケット発行業者がアクセスチケットを発行する際に、支払う方法。
電子貨幣により支払う場合や、発行業者側で料金を記録し、銀行振り込みなどにより清算を行う場合などがある。
【００３４】
▲２▼プリペイドで支払う方法：
ユーザが予めプリペイド度数を購入して、ＩＣカード中などに保持しておき、購入の際や利用の際に、プリペイドから相当する度数を引き落とす。
【００３５】
特願平０８−１９１７５６号の技術を用いると、▲１▼チケット発行時に支払う方法で、前述した権利の形態パーチェス、ペイ・パー・ユースおよびレントを全部実現できる。
【００３６】
他方、▲２▼プリペイドで支払う方法では、ペイ・パー・ユースは容易に実現できる。つまり、利用制御情報に１回あたりの利用額を記載し、認証を行う度に、保持しているプリペイド情報から、利用制御情報記載の度数分ずつ引き落とせばよい。
【００３７】
しかし、▲２▼プリペイドで支払う方法で、パーチェスやレントを実現するのは困難である。パーチェスは最初の利用時にのみプリペイドによる課金を行い、２回目以降の利用時には課金を行わないという処理が必要なためである。
【００３８】
パーチェスに関しては、利用制御情報に利用権の買取り額を記載しておき、最初の利用時にその額を保持しているプリペイド情報から引き落として、該利用したアクセスチケットの情報をＩＣカードに登録するようにし、２回目以降の利用時には、利用しようとするチケットが既にＩＣカードに登録されているかをチェックして、登録されている時にはプリペイド情報から引き落とさないように構成することで実現することも可能ではある。しかし、この登録情報は、非常に長い期間消すことはできないので、多くのチケットを使うような場合には、ＩＣカードの記憶容量が不足することになり、あまり現実的な解決策ではない。
【００３９】
レントの場合も、利用制御情報にレンタル額と有効期限を記載しておき、パーチェスと同様の方法を取ることで、実現することは可能ではあるが、同じくＩＣカードの記憶容量が不足することになり、あまり現実的な解決策ではない。
【００４０】
【発明が解決しようとする課題】
本発明は、以上のような問題点に鑑みなされたものであり、プリペイドで支払う方法においても、証明データ生成装置（ＩＣカード）側に余分な負荷をかけることなく、パーチェスやレントを実現することを可能にすることを課題とする。
【００４１】
【課題を解決するための手段】
本発明によれば、上述の課題を解決するために、ユーザのアクセス資格を認証するために生成され、正当性を検証される証明データを生成する証明データ生成装置に、認証用データを入力する認証用データ入力手段と、ユーザの固有情報を記憶するユーザ固有情報記憶手段と、ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス条件を記述した利用条件情報とに対し、所定の計算を実行して生成した証明用補助情報と、利用条件情報との組を含む証明用補助情報セットを記憶する証明用補助情報セット記憶手段と、入力された認証用データに対応する証明用補助情報セットを上記証明用補助情報セット記憶手段から取り出し、上記取り出した証明用補助情報セットの利用条件情報に従い、以降の処理を継続するかどうかの判断を行う利用条件判断手段と、上記利用条件判断手段において継続と判断されたときに、上記取り出した証明用補助情報セットと、上記認証用データ入力手段から入力された認証用データと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報とに所定の計算を施して証明データを生成し出力する証明データ生成出力手段とを設け、上記認証用データ入力手段から、第１の証明用補助情報セットを暗号関数における暗号化鍵で暗号化した暗号化証明用補助情報セットを入力し、上記利用条件判断手段は、上記証明用補助情報セット記憶手段から、入力された暗号化証明用補助情報セットに対応する第２の証明用補助情報セットを取り出し、上記取り出した第２の証明用補助情報セットの利用条件情報に従い、所定の処理を行った後、以降の処理を継続するかどうかの判断を行い、上記証明データ生成出力手段は、上記処理を行うことにより、上記暗号化証明用補助情報セットを復号化した結果である第１の証明用補助情報セットを出力するようにしている。
【００４２】
つまり、通常の証明用補助情報セット（アクセスチケット）である第１の証明用補助情報セットを暗号化して暗号化証明用補助情報セットを作成しておき、この暗号化証明用補助情報セットへアクセスするための第２の証明用補助情報セットを用いて、通常の認証処理と全く同じ処理を行うことにより、暗号化証明用補助情報セットから、第１の証明用補助情報セットを復号化する。
【００４３】
このように構成することにより、利用料金が無料のチケット（第１の証明用補助情報セット）を作成して暗号化し、暗号化されたチケットを復号化するためのチケット（第２の証明用補助情報セット）を発行し、このチケット（第２の証明用補助情報セット）の利用料金を有料としプリペイドで支払うように構成することで、全体としてプリペイドにおけるパーチェス機能の実現を可能にする。
【００４４】
レント機能は、これに加えて第２の証明用補助情報セットの利用条件情報に有効期限情報を記載することで実現可能である。
【００４５】
なお、暗号化されたチケットを復号化するには、通常のチケットの認証処理と同じ処理を行うように構成したので、比較的容量の少ないＩＣカード内に、余分なプログラムやデータを入れることなく、効率的に実現することが可能である。
【００４６】
【発明の実施の形態】
以下、この発明の実施例について説明する。
【００４７】
図１はこの実施例の構成図を示す。この実施例では、証明データ生成装置内にプリペイド情報を保持し、そのプリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する例（パーチェス）について説明する。
【００４８】
図１では、証明データ生成装置で生成され出力された証明データを検証する証明データ検証装置を含めて示す。
【００４９】
まず、図１に基づいて、本実施例の構成について説明したあと、証明データ検証装置、証明データ生成装置の処理の流れをフローチャートで示しながら説明する。処理の流れの説明には、通常の認証処理を例にして説明し、利用条件情報Ｌには、１回の利用の度ごとにプリペイドから引き落とされる例について説明する。そして、通常の認証処理の説明の後に、アプリケーションプログラムのアクセス権を購入する例（パーチェス）について説明する。
【００５０】
［実施例の構成］
図１は実施例の構成を全体として示すものであり、この図において、証明データ生成装置１０はユーザが保持するものであり、例えばＩＣカードのように内部に計算機能を持った携帯型の装置である。ＩＣカード以外にも、計算機能を持ったＰＣカードや、携帯型情報ツール、あるいはサブノートパソコンなどでもよい。内部の情報が、外部から簡単に改竄されたりすることがないように防御されていることが望ましい。
【００５１】
証明データ検証装置２０はユーザがアプリケーションプログラムを使用するパソコンであり、パソコンのスロットに証明データ生成装置１０であるＩＣカードを装着して使用する。
【００５２】
証明データ検証装置２０は、大きく認証用データ生成部２１と証明データ検証部２２とから構成されている。認証用データ生成部２１は、認証が必要な時に、認証用データを生成して、証明データ生成装置１０に送付する。証明データ検証部２２は、証明データ生成装置１０から送り返された証明データが正しいかどうかを検証する。
【００５３】
アプリケーションプログラムは、暗号化などによりプロテクトされており、ユーザがアプリケーションプログラムを利用しようとすると、証明データ検証装置２０は、そのアプリケーションプログラムに対応した認証用データを作成し、証明データ生成装置１０に送り、証明データ生成装置１０から送り返された証明データを検証して、正しいと検証された場合に限り、アプリケーションプログラムのプロテクトを解除して、利用することを可能にする。
【００５４】
一方、証明データ生成装置１０は、ユーザ固有情報記憶部１１、度数情報保持部１２、アクセスチケット記憶部１３、認証用データ入力部１４、利用条件判断部１５、証明データ生成出力部１６を含んで構成される。
【００５５】
ユーザ固有情報記憶部１１は、ユーザの秘密情報を保持する部分であり、ユーザ毎に異なる情報である。ユーザ固有情報は、証明データ生成装置１０が作成された時に封入され、ユーザにも取り出せないように構成されていることが望ましい。
【００５６】
度数情報保持部１２は、プリペイド情報を保持する部分であり、アプリケーションプログラムの利用や購入などに応じて、必要な額が減額されていく。額が少なくなった時には、増額することも可能である。増額の方法は、例えば、特願平９−２１３７３号で提案されている手法を用いることができる。この手法では、度数情報と署名した度数情報とを用いて度数情報を増額する。度数情報保持部１２における額の増減は、安全に行われることが必要であり、定められた方法以外でのアクセスができないように構成することが望ましい。
【００５７】
アクセスチケット記憶部１３は、複数のアクセスチケットを記憶している。アクセスチケットは、ユーザにアクセス資格を与えるものであり、アプリケーションプログラム作成者、またはアプリケーションプログラム作成者から委託を受けたチケット発行業者によって作成される。本実施例では、アクセスチケットは、ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス資格認証のアクセス条件を記述した利用条件情報とに対し、所定の計算を実行して計算された証明用補助情報と利用条件情報との組である。本実施例では、アクセスチケット記憶部は、ＩＣカード中に構成されているが、アクセスチケットは発行された本人しか使えないため、コピーは自由であり、ＩＣカード外部に構成しても構わない。
【００５８】
認証用データ入力部１４は、証明データ検証装置２０から送られた認証用データを入力する部分である。
【００５９】
利用条件判断部１５は、入力された認証用データに対応するアクセスチケットをアクセスチケット記憶部１３から取り出し、アクセスチケット中の利用条件情報を元に、利用条件を判断する。例えば、アクセスチケットの有効期限が切れていないか、利用料金は保持しているプリペイドで支払うのに足りているか、などの利用条件を判断し、以降の処理を継続するか否かを判断する。
【００６０】
証明データ生成出力部１６は、利用条件判断部１５で継続と判断された時のみ、証明データを生成して出力する。証明データは、利用条件判断部１５で取り出したアクセスチケット中の証明用補助情報と、認証用データと、ユーザの固有情報とに所定の計算を施して作成する。
【００６１】
次に、具体例を挙げて、さらに詳細に説明する。ここでの説明は、通常の認証処理を例にして説明し、利用条件情報Ｌには、１回の利用の度ごとにプリペイドから引き落とされる例について説明する。
【００６２】
図２は、図１の構成図に記号を付けたものである。記号は以下の説明と対応している。
【００６３】
［通常の認証処理］
以下では、法ｎにおけるＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｅｌｍａｎ）暗号を用いた例について詳細に説明する。まず、通常の認証処理について説明する。以下の例では、アプリケーションプログラムの作成者であるソフトウェアベンダが、ＩＣカードの発行からチケットの発行まですべてを行う例について説明する。この例ではソフトウェアベンダは、すべてのユーザの秘密情報ｄｕを知っている。これ以外にも、ＩＣカードの発行とチケットとをチケット発行業者が行う構成も可能である。
【００６４】
ソフトウェアベンダは、プロテクトしたいアプリケーションプログラムに対する暗号鍵を作成する。ここではＲＳＡ暗号を用いるので、大きな素数ｐ，ｑを秘密に作成し、法数ｎをｎ＝ｐ・ｑとして作成する。次に法数ｎの元で暗号鍵Ｅと復号鍵Ｄを、
【００６５】
【数１】
ＥＤ≡１ ｍｏｄ φ（ｎ）
を満たすように生成する。ここでφ（ｎ）はオイラー数であり、φ（ｎ）＝（ｐ−１）（ｑ−１）である。
【００６６】
次にソフトウェアベンダは、共通暗号鍵Ｋを作り、プロテクトしたいアプリケーションプログラムの一部または全部を、Ｋで暗号化し、
【００６７】
【数２】
Ｋ’＝ＫE ｍｏｄ ｎ
を計算して、Ｋ’を暗号化したアプリケーションプログラムに、第３者が取り出せないように埋め込んで配布する。
【００６８】
このアプリケーションプログラムを利用したいユーザは、予めこれに対応するアクセスチケットを入手しておくことになる。
【００６９】
ソフトウェアベンダは、ユーザからのアクセスチケット発行要求を受けて、アクセスチケットを発行する。ソフトウェアベンダは、要求したユーザの秘密情報ｄｕと、アプリケーションプログラムの暗号化の際に用いた暗号鍵（Ｅ，ｎ）に対応する復号鍵（Ｄ，ｎ）とをデータベースから取り出す。次にアクセスチケットに付与する利用条件情報Ｌを作成する。ここではプリペイドから引き落として課金するので、１回の利用について引き落とす利用額をＬとする。
そして、これらの情報を用いて、
【００７０】
【数３】
ｔ＝Ｄ−Ｆ（ｎ，Ｌ，ｄｕ）
として証明用補助情報ｔを作成する。ここで関数Ｆ（）は一方向性の関数であり、一方向性ハッシュ関数ＭＤ５、ＳＨＡなどや、共通鍵暗号ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などを用いることができる。
【００７１】
ソフトウェアベンダは、（ｔ，Ｌ，ｎ）の組をアクセスチケットとしてユーザに発行する。
【００７２】
ユーザが、アプリケーションプログラムを利用しようとすると、証明データ検証装置は、そのアプリケーションプログラムに対応した認証用データ（Ｃ，ｎ）を作成し、証明データ生成装置に送る。
【００７３】
この処理の流れを図３のフローチャートに示し、これに基づいて説明する。
（ステップＳ１１）：証明データ生成部２１は、プロテクトされたアプリケーションプログラムから、Ｋ’とｎとを取り出す。
（ステップＳ１２）：証明データ生成部は、乱数ｒを生成し、乱数保持部に格納する。
（ステップＳ１３）：Ｃ＝ｒEＫ’ ｍｏｄ ｎを計算する。
（ステップＳ１４）：（Ｃ，ｎ）の組を認証用データとして証明データ生成装置１０に送付する。
【００７４】
次に、証明データ生成装置１０の流れを図４に示し、これに基づいて証明データ生成装置１０の処理を説明する。
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｃ，ｎ）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎをキーにしてアクセスチケット記憶部を検索し、アクセスチケット（ｔ，Ｌ，ｎ）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ（利用額）と、度数情報保持部の度数情報Ｖとを比較する。
（ステップＳ２４〜Ｓ２５）：Ｖ≧Ｌの時は、証明データ生成出力部１６は、（ステップＳ２６）に進む。そうでないときは、証明データ生成出力部は、エラーを出力して終了する。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件（利用額）Ｌの分だけ減額する。
（ステップＳ２６〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ、利用条件Ｌ（利用額）と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【００７５】
【数４】
Ｒ’＝ＣF(n,L,du) ｍｏｄ ｎ
Ｒ＝ＣtＲ’ ｍｏｄ ｎ
図４では、証明データＲを計算するのに、一旦Ｒ’の計算を分けている。これは、Ｒ’の計算にはユーザの秘密情報を用いるため、その処理が外部に漏れないように計算する必要があるが、一旦Ｒ’の計算が終われば、Ｒの計算は外部で行っても構わないためである。このようにＲ’とＲとに分けて計算してもよいし、一度に計算しても構わない。
【００７６】
次に、証明データ検証装置２０の証明データ検証部の処理について説明する。証明データ生成装置１０から出力された証明データＲは、正しいユーザ固有情報ｄｕと、正しいアクセスチケット（正しい証明用補助情報ｔ、正しい利用条件Ｌ）を用いて計算されたときには、
【００７７】
【数５】
【００７８】
そこで、証明データ検証部２２では、乱数保持部２３から乱数ｒを取り出し、
【００７９】
【数６】
ｒ-1Ｒ ｍｏｄ ｎ
を計算することで、アプリケーションを暗号化していた共通暗号鍵Ｋを入手することができる。証明データ検証装置は、この共通暗号鍵Ｋでアプリケーションの暗号化されていた部分を復号し、アプリケーションを実行することができる。
【００８０】
この例では、証明データ検証装置は、アプリケーションが正しく実行できたことをもって、正しく検証ができたと判断する。
【００８１】
以上で通常の認証処理の説明を終了する。
【００８２】
［パーチェス］
次に、プリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する（パーチェス）例について説明する。
【００８３】
この機能を実現するには、通常のアクセスチケットである第１のアクセスチケットを暗号化して暗号化アクセスチケットを作成しておき、この暗号化アクセスチケットへアクセスするための第２のアクセスチケットを用いて、通常の認証処理と全く同じ処理を行うことにより、暗号化アクセスチケットから、第１のアクセスチケットを復号化する。
【００８４】
そしてこのとき、第１のアクセスチケットは、利用料金が無料のチケットとして作成し、第２のアクセスチケットは、利用料金を有料としプリペイドで支払うように構成することで、全体としてプリペイドにおけるパーチェス機能の実現を可能にする。
【００８５】
まず、パーチェスの機能を実現したいアプリケーションプログラムをＡＰ１とする。上述の説明と同様に、ＡＰ１をプロテクトする。
【００８６】
＜アプリケーションプログラムＡＰ１のプロテクトの説明＞
ソフトウェアベンダは、プロテクトしたいアプリケーションプログラムに対する暗号鍵を作成する。ここではＲＳＡ暗号を用いるので、大きな素数ｐ1，ｑ1を秘密に作成し、法数ｎ1をｎ1＝ｐ1・ｑ1として作成する。次に法数ｎ1の元で暗号鍵Ｅ1と復号鍵Ｄ1を、
【００８７】
【数７】
Ｅ1・Ｄ1≡１ ｍｏｄ φ（ｎ1）
を満たすように生成する。ここでφ（ｎ1）はオイラー数であり、φ（ｎ1）＝（ｐ1−１）（ｑ1−１）である。
【００８８】
次にソフトウェアベンダは、共通暗号鍵Ｋ1を作り、プロテクトしたいアプリケーションプログラムの一部または全部をＫ1で暗号化し、さらに共通暗号鍵Ｋ1を以下の式に従って、暗号鍵Ｅ1で暗号化して、Ｋ1’を生成する。
【００８９】
【数８】
Ｋ1’＝Ｋ1Ｅ1 ｍｏｄ ｎ1
そして、Ｋ1’を暗号化したアプリケーションプログラムに、第３者が容易に取り出せないように埋め込んで配布する。また、ｎ1も、暗号化したアプリケーションプログラムに埋めこむ。
【００９０】
ソフトウェアベンダは、作成した（ｎ1，Ｄ1，φ（ｎ1））の組をアクセスチケット情報データベースに記憶する。
【００９１】
次に、プリペイド払いパーチェス・チケットの作成について説明する。図５は、証明用補助情報生成装置３０の構成例を示したものである。この例では、第１の利用条件情報と第１の復号鍵とユーザ固有情報と第２の利用条件情報とを入力として、プリペイド払いパーチェス・チケットを出力する。図５において、入力部３１は、第１の利用条件情報と第１の復号鍵とユーザ固有情報と第２の利用条件情報とを入力する部分である。第１復号鍵記憶部３３は、入力部３１から入力された第１の復号鍵を記憶する部分である。第１の復号鍵は、アプリケーションプログラムＡＰ１の暗号化に用いた共通暗号鍵Ｋ1を暗号化した暗号鍵（Ｅ1，ｎ1）に対応する復号鍵（Ｄ1，ｎ1）である。
【００９２】
ユーザ固有情報記憶部３４は、入力部３１から入力されたユーザ固有情報を記憶する部分である。これは、ユーザの証明データ生成装置１０に格納されているものと同一のものである。
【００９３】
ユーザがチケットの発行を依頼する時には、ユーザの識別情報Ｕと、ユーザが利用を希望するアプリケーションプログラムＡＰ１から取り出したｎ1とを、ソフトウェアベンダに送る。ソフトウェアベンダは、ユーザの識別情報Ｕとユーザ固有情報ｄｕとを対応づけて保持しているユーザ情報データベースから、ユーザの識別情報Ｕに対応するユーザ固有情報ｄｕを検索することによってユーザ固有情報を得、また（ｎ，Ｄ，φ（ｎ））の組を保持しているアクセスチケット情報データベースから、ｎ1に対応する復号鍵（Ｄ1，ｎ1）を得て、証明用補助情報生成装置３０に入力する。
【００９４】
第１利用条件情報記憶部３２と第２利用条件情報記憶部３５は、それぞれ第１の利用条件情報と第２の利用条件情報とを記憶する部分である。第１の利用条件情報は、アプリケーションプログラムＡＰ１の利用条件を記述したものであり、第２の利用条件情報は、プリペイド払いパーチェス・チケットの利用条件を記述したものである。プリペイド払いパーチェス・チケットの場合には、１回目の利用時に課金され、２回目以降の利用時には課金されないという特性を持つので、第１の利用条件情報には少なくとも無料であることを意味する情報が含まれており、第２の利用条件情報には、少なくとも有料であることを意味する情報が含まれている。
【００９５】
第１チケット生成部３６は、入力された第１の利用条件情報と第１の復号鍵とユーザ固有情報とに所定の計算を実行してアクセスチケットを生成する部分である。
【００９６】
第１利用条件情報記憶部３２と第１復号鍵記憶部３３とユーザ固有情報記憶部３４と第１チケット生成部３６とからなる構成部分４１は、通常のアクセスチケットを生成するのと同様の構成をなしている。
【００９７】
第２の鍵生成部３７は、第１チケット生成部３６で生成された第１のアクセスチケットを暗号化するための鍵を生成する部分である。
【００９８】
暗号化部３８は、第１チケット生成部３６で生成された第１のアクセスチケットを、第２の鍵生成部３７で生成された暗号化鍵を用いて暗号化する部分である。
【００９９】
第２チケット生成部３９は、暗号化部３８で暗号化された暗号化アクセスチケットを復号化するために必要となる第２のアクセスチケットを生成する部分である。
【０１００】
チケット出力部４０は、暗号化部３８で暗号化された暗号化アクセスチケットと、第２チケット生成部３９で生成された第２のアクセスチケットとを組み合わせて、プリペイド払いパーチェス・チケットとして出力する。
【０１０１】
＜プリペイド払いパーチェス・チケットの作成＞
以下に、プリペイド払いパーチェス・チケットの作成の方法について図６のフローチャートを用いて説明する。
【０１０２】
ソフトウェアベンダは、ユーザからのプリペイド払いパーチェス・チケット発行要求を受けて、プリペイド払いパーチェス・チケットを発行する。チケットの発行を依頼するユーザは、ユーザの識別情報Ｕと、ユーザが利用を希望するアプリケーションプログラムＡＰ１から取り出したｎ1とを、ソフトウェアベンダに送る。
【０１０３】
（ステップＳ３１）：ソフトウェアベンダは、ユーザからのプリペイド払いパーチェス・チケット発行要求であるユーザの識別情報ＵとアプリケーションプログラムＡＰ１から取り出したｎ1との組（Ｕ，ｎ1）を入力する。また、アプリケーションプログラムＡＰ１の利用条件を記述した第１の利用条件情報Ｌ1と、プリペイド払いパーチェス・チケットの利用条件を記述した第２の利用条件情報Ｌ2も入力する。ここでは、プリペイド払いパーチェス・チケットの生成を目的としているので、第１の利用条件情報Ｌ1は、利用料金が無料であることを意味する
【０１０４】
【数９】
Ｌ1＝０
であり、第２の利用条件情報Ｌ２は、パーチェスの料金が有料であることを意味する
【０１０５】
【数１０】
Ｌ2＝Ａ
とする。ただしＡは０以外の数字であり、たとえば１００である。
【０１０６】
（ステップＳ３２）：ユーザの識別情報Ｕとユーザ固有情報ｄｕとを対応づけて保持しているユーザ情報データベースから、ユーザの識別情報Ｕに対応するユーザ固有情報ｄｕを検索する。
（ステップＳ３３）：（ｎ，Ｄ，φ（ｎ））の組を保持しているアクセスチケット情報データベースから、ｎ1に対応する第１の復号鍵（Ｄ1，ｎ1）を検索する。
（ステップＳ３４）：ユーザがＡＰ１にアクセスするための第１のアクセスチケットＴ1を作成する。
【０１０７】
【数１１】
Ｔ1＝（ｔ1，Ｌ1，ｎ1）
ｔ1＝Ｄ1−Ｆ（ｎ1，Ｌ1，ｄｕ）
（ステップＳ３５）：第１のアクセスチケットＴ1を暗号化するために、第２の法数ｎ2、第２の暗号鍵Ｅ2、第２の復号鍵Ｄ2を生成する。大きな素数ｐ2，ｑ2を生成し、以下の式が成り立つように、法数ｎ2、暗号鍵Ｅ2、復号鍵Ｄ2を生成する。
【０１０８】
【数１２】
ｎ2＝ｐ2・ｑ2
Ｅ2・Ｄ2≡１ ｍｏｄ φ（ｎ2）
φ（ｎ2）＝（ｐ2−１）（ｑ2−１）
（ステップＳ３６）：生成した第２の暗号鍵Ｅ2で第１のアクセスチケットＴ1を暗号化する。Ｔ1を暗号化したものをＴ1’とする。
【０１０９】
【数１３】
Ｔ1’＝Ｔ1Ｅ2 ｍｏｄ ｎ2
（ステップＳ３７）：暗号化されたアクセスチケットＴ1’をユーザが復号するための第２のアクセスチケットＴ2を作成する。
【０１１０】
【数１４】
Ｔ2＝（ｔ2，Ｌ2，ｎ2）
ｔ2＝Ｄ2−Ｆ（ｎ2，Ｌ2，ｄｕ）
（ステップＳ３８）：（（Ｔ1’，ｎ2），Ｔ2）を組にしてプリペイド払いパーチェス・チケットとして出力する。
【０１１１】
ソフトウェアベンダは、出力されたプリペイド払いパーチェス・チケット（（Ｔ1’，ｎ2），Ｔ2）を、ユーザに送付する。
【０１１２】
次に、プリペイド払いパーチェス・チケットの使用例について説明する。
【０１１３】
＜プリペイド払いパーチェス・チケットの使用例＞
（ａ）プリペイド払いパーチェス・チケット（（Ｔ1’，ｎ2），Ｔ2）を受け取ったユーザは、まずＴ2をアクセスチケット記憶部１３に格納する。
（ｂ）次に、（Ｔ1’，ｎ2）を自分が保持している証明データ生成装置１０の認証用データ入力部１４より入力する。
【０１１４】
以下、証明データ生成装置１０における処理が図４に従って行われる。今、証明データ生成装置１４の度数情報保持部１２には、８００度数のプリペイド情報Ｖが保持されているとする。（Ｖ＝８００）
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｔ1’，ｎ2）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎ2をキーにしてアクセスチケット記憶部１３を検索し、アクセスチケットＴ2＝（ｔ2，Ｌ2，ｎ2）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ2と、度数情報保持部１２の度数情報Ｖとを比較する。
（ステップＳ２４）：今、Ｌ2＝１００、Ｖ＝８００なので、
【０１１５】
【数１５】
Ｖ≧Ｌ2
が成り立ち、（ステップＳ２６）へ進む。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件Ｌ2の分だけ減額する。
【０１１６】
【数１６】
Ｖ＝８００−１００＝７００
つまり、度数情報Ｖは、プリペイド払いパーチェス・チケットの買取り料金として、１００度数引き落とされ、残り７００度数となる。
（ステップＳ２７〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ2、利用条件Ｌ2と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【０１１７】
【数１７】
Ｒ’＝Ｔ1’F(n2,L2,du) ｍｏｄ ｎ2
Ｒ＝Ｔ1’t2Ｒ’ ｍｏｄ ｎ2
Ｒの計算を行うと、
【０１１８】
【数１８】
【０１１９】
【数１９】
Ｒ＝Ｔ1
が出力される。
【０１２０】
つまり、（Ｔ1’，ｎ2）を自分が保持している証明データ生成装置１０の認証用データ入力部１４より入力すると、Ｌ2が度数情報Ｖから引き落とされて、結果としてＴ1’が復号されたＴ1が出力される。
【０１２１】
（ｃ）ユーザは、入手したＴ1をアクセスチケット記憶部１３に格納する。
【０１２２】
（ｄ）ユーザは、アプリケーションプログラムＡＰ１を利用するためのアクセスチケットＴ1を入手できたので、アプリケーションプログラムＡＰ１を利用する。
【０１２３】
以下、証明データ検証装置１０における認証用データ生成処理が図３に従って行われる。
（ステップＳ１１）：認証用データ生成部２１は、プロテクトされたアプリケーションプログラムから、Ｋ1’とｎ1とを取り出す。
（ステップＳ１２）：認証用データ生成部２１は、乱数ｒを生成し、乱数保持部２３に格納する。
（ステップＳ１３）：Ｃ＝ｒEＫ1’ ｍｏｄ ｎ1を計算する。
（ステップＳ１４）：（Ｃ，ｎ1）の組を認証用データとして証明データ生成装置１０に送付する。
（ｅ）証明データ生成装置１０における処理が再び図４に従って行われる。
（ステップＳ２１）：認証用データ入力部１４より、認証用データ（Ｃ，ｎ1）を入力する。
（ステップＳ２２）：利用条件判断部１５は、ｎ1をキーにしてアクセスチケット記憶部１３を検索し、アクセスチケットＴ1＝（ｔ1，Ｌ1，ｎ1）を取り出す。
（ステップＳ２３）：利用条件判断部１５は、取り出したアクセスチケット中の利用条件Ｌ1と、度数情報保持部１２の度数情報Ｖとを比較する。
（ステップＳ２４）：今、Ｌ１＝０、Ｖ＝７００なので、
【０１２４】
【数２０】
Ｖ≧Ｌ1
が成り立ち、（ステップＳ２６）へ進む。
（ステップＳ２６）：利用条件判断部１５は、度数情報保持部１２に保持されている度数情報Ｖを利用条件Ｌ1の分だけ減額する。
【０１２５】
【数２１】
Ｖ＝７００−０＝７００
つまり、度数情報Ｖは、最初にプリペイド払いパーチェス・チケットの買取り料金として、１００度数引き落とされているので、２回目以降の利用では引き落とされず、残り７００度数のままとなる。
（ステップＳ２７〜Ｓ２９）：証明データ生成出力部１６は、利用条件判断部１５が取り出した証明用補助情報ｔ1、利用条件Ｌ1と、ユーザ固有情報記憶部１１から読み出したｄｕとを用いて証明データＲを計算して出力する。
【０１２６】
【数２２】
Ｒ’＝ＣF(n1,L1,du) ｍｏｄ ｎ1
Ｒ＝Ｃt1Ｒ’ ｍｏｄ ｎ1
つまり、
【０１２７】
【数２３】
【０１２８】
【数２４】
ｒ-1Ｒ ｍｏｄ ｎ1
を計算することで、アプリケーションを暗号化していた共通暗号鍵Ｋを入手することができる。証明データ検証装置は、この共通暗号鍵Ｋでアプリケーションの暗号化されていた部分を復号し、アプリケーションを実行することができる。
【０１２９】
これ以降は、何度アプリケーションプログラムＡＰ１を実行しても、同様の処理が行われ、無料で利用することができる。
【０１３０】
以上説明したように、上記のように構成することで、プリペイド情報を用いて、アプリケーションプログラムのアクセス権を購入する（パーチェス）ことが可能になる。
【０１３１】
以上、プリペイドにおけるパーチェス機能の実現について説明した。
【０１３２】
これ以外にも、証明データ生成装置に時計を備え、第１のアクセスチケットの利用条件情報Ｌの中に、利用額が無料という情報に加えて、有効期限情報を記載し、第１のアクセスチケットの利用のたびに、時刻と比較することによって、プリペイドにおけるレント機能を実現することも可能である。
【０１３３】
さらに、別の例としては、証明データ生成装置に時計を備え、第２のアクセスチケットの利用条件情報Ｌの中に、有効期限情報を記載し、暗号化された第１のアクセスチケットの復号の際に、時刻と比較することによって、第１のアクセスチケットを配布（解凍）する期限を限定することなども可能である。
【０１３４】
また、本実施例では、ＲＳＡ暗号を元にして説明を行ったが、これに限らず他の暗号方式を用いても構わない。また、アクセスチケットの実現式もこれに限ることはない。
【０１３５】
【発明の効果】
実行制御等のユーザのアクセス資格の認証を行うに際して、ユーザはあらかじめ固有情報を保持し、プログラム作成者等のプロテクト者はユーザが所持する固有情報とは独立にアクセス資格認証の特徴情報を用意し、アクセスチケットをユーザの固有情報とアプリケーションプログラムの作成等に使用したアクセス資格認証の特徴情報とに応じて作成し、配布することにより、ユーザおよびプロテクト者の双方を、アクセス権情報管理のわずらわしさから開放させるという特徴を残したまま、従来は困難だったプリペイドにおけるパーチェス機能およびレント機能を実現することを可能にした。
【０１３６】
さらにこれらの機能を実現するにおいて、通常のチケットの認証処理と同じ処理を行うように構成したので、比較的容量の少ないＩＣカード内に、余分なプログラムやデータを入れることなく、効率的に実現することが可能である。
【図面の簡単な説明】
【図１】 本発明の実施例の構成を示すブロック図である。
【図２】 図１の構成を詳細に説明する図である。
【図３】 図１の証明データ検証装置の認証用データ生成処理を説明するフローチャートである。
【図４】 図１の証明データ生成装置の証明データ生成処理を説明するフローチャートである。
【図５】 図１の証明データの生成に用いるチケットを生成する証明用補助情報生成装置を示すブロック図である。
【図６】 図１の証明データの生成に用いるチケットの生成を説明する図である。
【符号の説明】
１０ 証明データ生成装置
１１ ユーザ固有情報記憶部
１２ 度数情報保持部
１３ アクセスチケット記憶部
１４ 認証用データ入力部
１５ 利用条件判断部
１６ 証明データ生成出力部
２０ 証明データ検証装置
２１ 認証用データ生成部
２２ 証明データ検証部
２３ 乱数保持部
３０ 証明用補助情報生成装置
３２ 第１利用条件情報記憶部
３３ 第１復号鍵記憶部
３４ ユーザ固有情報記憶部
３５ 第２利用条件記憶部
３６ 第１チケット生成部
３７ 第２の鍵生成部
３８ 暗号化部
３９ 第２チケット生成部
４０ チケット出力部
Claims (11)
- ユーザのアクセス資格を認証するために生成される証明データであって、検証装置により、アクセス資格認証の特徴情報に基づいて生成されていることが検証され、もって正当性を検証される証明データを生成する証明データ生成装置において、
認証用データを入力する認証用データ入力手段と、
ユーザの固有情報を記憶するユーザ固有情報記憶手段と、
（ａ）ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス条件を記述した利用条件情報とに対し、所定の第１の計算を実行して生成した証明用補助情報と
（ｂ）上記利用条件情報と
の組を含む、証明用補助情報セットを記憶する証明用補助情報セット記憶手段と、
入力された認証用データに対応する証明用補助情報セットを上記証明用補助情報セット記憶手段から取り出し、上記取り出した証明用補助情報セットの利用条件情報に従い、利用状態が当該利用条件情報を満たす場合には証明データ生成処理を継続するとの判断を行い、上記利用状態が当該利用条件情報を満たさない場合には証明データ生成処理を中止するとの判断を行う利用条件判断手段と、
上記利用条件判断手段において継続と判断されたときに、上記取り出した証明用補助情報セットと、上記認証用データ入力手段から入力された認証用データと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報とに所定の第２の計算を施して証明データを生成し出力する証明データ生成出力手段とを有し、
上記証明用補助情報を生成するために実行される上記所定の第１の計算と、上記証明データを生成するために実行される上記所定の第２の計算とを、上記ユーザの固有情報、上記アクセス資格認証の特徴情報および上記証明用補助情報が対応する場合に上記検証装置により上記証明データが上記アクセス資格認証の特徴情報に基づいて生成されたものであると検証されるように選定し、
さらに、上記認証用データ入力手段から、第１の証明用補助情報セットを暗号関数における暗号化鍵で暗号化した暗号化証明用補助情報セットを入力し、
上記利用条件判断手段は、上記証明用補助情報セット記憶手段から、入力された暗号化証明用補助情報セットに対応する第２の証明用補助情報セットであって上記第１の証明用補助情報セットをアクセス資格認証の特徴情報とする上記第２の証明用補助情報セットを取り出し、上記取り出した第２の証明用補助情報セットの利用条件情報に従い、利用状態が利用条件情報を満たすかどうかを判断し、満たす場合には、課金処理の実行を行った後、上記第２の証明用補助情報を用いた証明データ生成処理を継続し、満たさない場合には上記証明データ生成処理を中止し、
上記証明データ生成出力手段は、上記第２の証明用補助情報セットを用いた上記証明データ生成処理を行うことにより、上記暗号化証明用補助情報セットを復号化した結果である第１の証明用補助情報セットを出力し、上記第１の証明用補助情報セットを用いた証明データの生成を行なえるようにすることを特徴とする証明データ生成装置。 - 少なくとも、上記ユーザ固有情報記憶手段と、上記利用条件判断手段と、上記証明データ生成出力手段とが、内部のデータおよび処理手続きを外部から観測することを困難ならしめる防御手段中に保持されている請求項１記載の証明データ生成装置。
- さらに電子度数情報を保持する度数情報保持手段を備え、上記利用条件情報には、利用したときに支払うべき利用度数を含み、上記利用条件判断手段は、上記度数情報保持手段に保持されている電子度数情報と、上記利用条件情報に含まれる利用度数とを比較して、上記度数情報保持手段に保持されている電子度数情報が利用条件情報に含まれる利用度数以上の時にのみ、上記度数情報保持手段に保持されている電子度数情報から上記利用条件情報に含まれる利用度数分の度数を減額して、以降の処理を継続するという判断を行う請求項１または２記載の証明データ生成装置。
- 上記第１の証明用補助情報セットに含まれる第１の利用条件情報に含まれる利用度数は０度数であり、上記第２の証明用補助情報セットに含まれる第２の利用条件情報に含まれる利用度数は０以外であることを特徴とする請求項３記載の証明データ生成装置。
- さらに時刻を示す時計を備え、上記第１の証明用補助情報セットに含まれる第１の利用条件情報には、さらに有効期限情報が記載され、上記利用条件判断手段は、上記時刻と上記有効期限情報とを比較し、該時刻が有効期限内にある時にのみ、以降の処理を継続するという判断を行う請求項１、２、３または４記載の証明データ生成装置。
- 少なくとも、上記証明用補助情報セット記憶手段以外の手段が、携帯可能な小型演算装置として構成されている請求項１、２、３、４または５記載の証明データ生成装置。
- ユーザのアクセス資格を証明するために生成された証明データがアクセス資格認証の特徴情報に基づいて生成されていることを検証することにより上記ユーザのアクセス資格を認証するアクセス資格認証装置において、
予備的なアクセス資格認証と、当該予備的なアクセス資格認証が成功した場合には、以降、実行可能となる主たるアクセス資格認証とを行い、
さらに、
ユーザの固有情報を記憶するユーザ固有情報記憶手段と、
上記ユーザの固有情報と、主たるアクセス資格認証の特徴情報とに対して所定の第１の計算を実行して生成した主たるアクセス資格認証の証明用補助情報を暗号化して生成した暗号化証明用補助情報を入力する暗号化証明用補助情報入力手段と、
（ａ）上記ユーザの固有情報と、予備的なアクセス資格認証の特徴情報としての上記暗号化の復号鍵と、アクセス条件を記述した利用条件情報とに対して、上記所定の第１の計算を実行して生成した予備的なアクセス資格認証の証明用補助情報と
（ｂ）上記利用条件情報と
からなる、予備的なアクセス資格認証の証明用補助情報セットを記憶する証明用補助情報セット記憶手段と、
上記証明用補助情報セット記憶手段に記憶されている上記予備的なアクセス資格認証の証明用補助情報セットに含まれる上記利用条件情報にしたがい、利用状態が当該利用条件情報を満たす場合には課金処理を実行し証明データ生成処理を継続すると判断し、上記利用状態が当該利用条件情報を満たさない場合には課金処理および証明データ生成を中止すると判断する手段と、
上記課金処理を実行し証明データ生成処理を継続すると判断したときに、上記課金処理を行ない、さらに、上記暗号化証明用補助情報記憶手段に記憶されている上記暗号化証明用補助情報と、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報と、上記証明用補助情報セット記憶手段に記憶されている上記予備的なアクセス資格認証の証明用補助情報セットとに対して上記所定の第２の計算を実行して証明データを生成して、もって上記主たるアクセス資格認証の証明用補助情報を復元する手段と、
主たるアクセス資格認証用の認証用データを入力する認証用データ入力手段と、
上記認証用データ入力手段により入力された上記認証用データと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報と、復元した上記主たるアクセス資格認証の認証用補助情報とに対して上記所定の第２の計算を実行して証明データを生成する手段と、
生成された上記証明データを検証する手段とを有し、
上記証明用補助情報を生成するために実行される上記所定の第１の計算と、上記証明データを生成するために実行される上記所定の第２の計算とを、上記ユーザの固有情報、上記アクセス資格認証の特徴情報および上記証明用補助情報が対応する場合に上記検証手段により上記証明データが上記アクセス資格認証の特徴情報に基づいて生成されたものであると検証されるように選定することを特徴とするアクセス資格認証装置。 - ユーザのアクセス資格を証明するために生成された証明データがアクセス資格認証の特徴情報に基づいて生成されていることを検証することにより上記ユーザのアクセス資格を認証するアクセス資格認証装置において、
予備的なアクセス資格認証と、当該予備的なアクセス資格認証が成功した場合には、以降、実行可能となる主たるアクセス資格認証とを行い、
ユーザの固有情報を記憶するユーザ固有情報記憶手段と、
（ａ１）上記ユーザの固有情報と、主たるアクセス資格認証の特徴情報と、アクセス条件を記述した第１の利用条件情報とに対し、所定の第１の計算を実行して生成した主たるアクセス資格認証の証明用補助情報と
（ｂ１）上記第１の利用条件情報と
からなる主たるアクセス資格認証の証明用補助情報セットを暗号化して生成した暗号化証明用補助情報セットを入力する暗号化証明用補助情報セット入力手段と、
（ａ２）上記ユーザの固有情報と、予備的なアクセス資格認証の特徴情報としての上記暗号化の復号鍵と、アクセス条件を記述した第２の利用条件情報とに対して、上記所定の第１の計算を実行して生成した予備的なアクセス資格認証の証明用補助情報と
（ｂ２）上記第２の利用条件情報と
からなる予備的なアクセス資格認証の証明用補助情報セットを記憶する証明用補助情報セット記憶手段と、
上記証明用補助情報セット記憶手段に記憶されている上記予備的なアクセス資格認証の証明用補助情報セットに含まれる上記第２の利用条件情報にしたがって、利用状態が当該第２の利用条件情報を満たす場合には課金処理を実行し予備的なアクセス資格認証の証明データ生成処理を継続すると判断し、上記利用状態が上記第２の利用条件情報を満たさない場合には上記課金処理及び予備的なアクセス資格認証の証明データ生成を中止すると判断する手段と、
上記課金処理を実行し予備的なアクセス資格認証の証明データ生成処理を継続すると判断したときに、上記課金処理を行い、さらに、上記暗号化証明用補助情報セット入力手段により入力された上記暗号化証明用補助情報セットと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報と、上記証明用補助情報セット記憶手段に記憶されている上記予備的なアクセス資格認証の証明用補助情報セットとに対して所定の第２の計算を実行して予備的な資格認証の証明データを生成し、もって、上記主たる資格認証の証明用補助情報セットを復元する手段と、
主たるアクセス資格認証用の認証用データを入力する認証用データ入力手段と、
復元された上記主たるアクセス資格認証の証明用補助情報セットに含まれる上記第１の利用条件情報にしたがって、利用状態が上記第１の利用条件情報を満たす場合に主たるアクセス資格認証の証明データ生成処理を継続すると判断し、上記利用状態が上記第１の利用条件情報が満たさない場合に上記主たるアクセス資格認証の証明データ生成処理を中止すると判断する手段と、
上記主たるアクセス資格認証の証明データ生成処理を継続すると判断したときに、上記認証用データ入力手段により入力された上記認証用データと、上記ユーザ固有情報記憶手段に記憶されている上記ユーザの固有情報と、復元した上記主たるアクセス資格認証の証明用補助情報セットとに対して上記所定の第２の計算を実行して主たるアクセス資格認証の証明データを生成する手段と、
生成された上記主たるアクセス資格認証の証明データを検証する手段とを有し、
上記証明用補助情報を生成するために実行される上記所定の第１の計算と、上記証明データを生成するために実行される上記所定の第２の計算とを、上記ユーザの固有情報、上記アクセス資格認証の特徴情報および上記証明用補助情報が対応する場合に上記検証手段により上記証明データが上記アクセス資格認証の特徴情報に基づいて生成されたものであると検証されるように選定することを特徴とするアクセス資格認証装置。 - ユーザのアクセス資格を証明するために生成された証明データの正当性を検証することにより上記ユーザのアクセス資格を認証するアクセス資格認証方法において、
当該アクセス資格認証方法は、であって、予備的なアクセス資格認証と、当該予備的な アクセス資格認証が成功した場合には、以降、実行可能となる主たるアクセス資格認証とを行うものであり、
ユーザの固有情報をユーザ固有情報記憶手段に記憶するステップと、
（ａ１）上記ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス条件を記述した第１の利用条件情報とに対し、所定の第１の計算を実行して生成した、主たるアクセス資格認証の証明用補助情報と
（ｂ１）上記第１の利用条件情報と
からなる主たるアクセス資格認証の証明用補助情報セットを暗号化して生成した暗号化証明用補助情報セットを、暗号化証明用補助情報入力手段により入力するステップと、
（ａ２）上記ユーザの固有情報と、予備的なアクセス資格認証の特徴情報としての上記暗号化の復号鍵と、アクセス条件を記述した第２の利用条件情報とに対して、上記所定の第１の計算を実行して生成した第２の証明用補助情報と
（ｂ２）上記第２の利用条件情報と
からなる予備的なアクセス資格認証の証明用補助情報セットを証明用補助情報セット記憶手段に記憶するステップと、
上記証明用補助情報セット記憶手段に記憶された上記予備的なアクセス資格認証の証明用補助情報セットに含まれる上記第２の利用条件情報にしたがって、利用状態が当該第２の利用条件情報を満たす場合には課金処理を実行し予備的なアクセス資格認証の証明データ生成処理を継続すると判断手段により判断し、上記利用状態が上記第２の利用条件情報を満たさない場合には上記課金処理及び予備的なアクセス資格認証の証明データ生成を中止すると上記判断手段により判断するステップと、
上記課金処理を実行し予備的なアクセス資格認証の証明データ生成処理を継続すると判断したときに、上記課金処理を行い、さらに、上記暗号化証明用補助情報セット入力手段により入力された上記暗号化証明用補助情報セットと、上記ユーザ固有情報記憶手段に記憶された上記ユーザの固有情報と、上記証明用補助情報セット記憶手段に記憶された上記予備的なアクセス資格認証の証明用補助情報セットとに対して所定の第２の計算を証明データ生成手段により実行して予備的な資格認証の証明データを生成し、もって、上記主たるアクセス資格認証の証明用補助情報セットを復元するステップと、
主たるアクセス資格認証用の認証用データを認証用データ入力手段により入力するステップと、
復元された上記主たるアクセス資格認証の証明用補助情報セットに含まれる上記第１の利用条件情報にしたがって、利用状態が上記第１の利用条件情報を満たす場合には判断手段により主たるアクセス資格認証の証明データ生成処理を継続すると判断し、上記利用状態が上記第１の利用条件情報を満たさない場合には上記判断手段により上記主たるアクセス資格認証の証明データ生成処理を中止すると判断するステップと、
上記主たるアクセス資格認証の証明データ生成処理を継続すると判断したときに、上記認証用データ入力手段により入力された上記認証用データと、上記ユーザ固有情報記憶手段に記憶された上記ユーザの固有情報と、復元した上記主たるアクセス資格認証の証明用補助情報セットとに対して上記所定の第２の計算を上記証明データ生成手段により実行して主たるアクセス資格認証の証明データを生成するステップと、
生成された上記主たるアクセス資格認証の証明データを検証手段により検証するステップとを有し、
上記証明用補助情報を生成するために実行される上記所定の第１の計算と、上記証明データを生成するために実行される上記所定の第２の計算とを、上記ユーザの固有情報、上記アクセス資格認証の特徴情報および上記証明用補助情報が対応する場合に上記検証手段により上記証明データが上記アクセス資格認証の特徴情報に基づいて生成されたものであると検証されるように選定することを特徴とするアクセス資格認証方法。 - 請求項８記載のアクセス資格認証装置で用いられる上記暗号化証明用補助情報セットおよび上記予備的なアクセス資格認証の証明用補助情報セットを複合的な証明用補助情報として構成して出力する証明用補助情報生成装置において、
ユーザの固有情報と、主たるアクセス資格認証の特徴情報と、アクセス条件を記述した第１の利用条件情報とに対し、所定の第１の計算を実行して主たるアクセス資格認証の証明用補助情報を生成する手段と、
上記主たるアクセス資格認証の証明用補助情報と、上記第１の利用条件情報とからなる主たるアクセス資格認証の証明用補助情報セットを暗号化する手段と、
上記ユーザの固有情報と、予備的なアクセス資格認証の特徴情報としての上記暗号化の復号鍵と、アクセス条件を記述した第２の利用条件情報とに対して、上記所定の第１の計算を実行して予備的なアクセス資格認証の証明用補助情報を生成する手段と、
上記暗号化した主たるアクセス資格認証の証明用補助情報セットと上記予備的なアクセス資格認証の証明用補助情報セットとから複合的な証明用補助情報を生成して出力する手段とを有することを特徴とする証明用補助情報生成装置。 - 請求項８記載のアクセス資格認証装置で用いられる上記暗号化証明用補助情報セットおよび上記予備的なアクセス資格認証の証明用補助情報セットを複合的な証明用補助情報として構成して出力する証明用補助情報生成方法において、
ユーザの固有情報と、アクセス資格認証の特徴情報と、アクセス条件を記述した第１の利用条件情報とに対し、主たるアクセス資格認証の証明用補助情報生成手段により、所定の第１の計算を実行して主たるアクセス資格認証の証明用補助情報を生成するステップと、
上記主たるアクセス資格認証の証明用補助情報と、上記第１の利用条件情報とからなる主たるアクセス資格認証の証明用補助情報セットを暗号化手段により暗号化するステップと、
上記ユーザの固有情報と、予備的なアクセス資格認証の特徴情報としての上記暗号化の復号鍵と、アクセス条件を記述した第２の利用条件情報とに対して、予備的なアクセス資格認証の証明用補助情報生成手段により、上記所定の第１の計算を実行して予備的なアクセス資格認証の証明用補助情報を生成するステップと、
上記暗号化した主たるアクセス資格認証の証明用補助情報セットと上記予備的なアクセス資格認証の証明用補助情報セットとから、証明用補助情報出力手段により、複合的な証明用補助情報を生成して出力するステップとを有することを特徴とする証明用補助情報生成方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18880197A JP3641909B2 (ja) | 1997-07-14 | 1997-07-14 | 証明データ生成装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18880197A JP3641909B2 (ja) | 1997-07-14 | 1997-07-14 | 証明データ生成装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1132037A JPH1132037A (ja) | 1999-02-02 |
| JP3641909B2 true JP3641909B2 (ja) | 2005-04-27 |
Family
ID=16230050
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP18880197A Expired - Fee Related JP3641909B2 (ja) | 1997-07-14 | 1997-07-14 | 証明データ生成装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3641909B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08263438A (ja) | 1994-11-23 | 1996-10-11 | Xerox Corp | ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法 |
| AU3456200A (en) * | 1999-03-31 | 2000-10-16 | Vertex Software Co., | Rental ware system |
| US8275716B2 (en) | 2001-05-31 | 2012-09-25 | Contentguard Holdings, Inc. | Method and system for subscription digital rights management |
| US6895503B2 (en) | 2001-05-31 | 2005-05-17 | Contentguard Holdings, Inc. | Method and apparatus for hierarchical assignment of rights to documents and documents having such rights |
| US6876984B2 (en) | 2001-05-31 | 2005-04-05 | Contentguard Holdings, Inc. | Method and apparatus for establishing usage rights for digital content to be created in the future |
| US7350231B2 (en) | 2001-06-06 | 2008-03-25 | Yahoo ! Inc. | System and method for controlling access to digital content, including streaming media |
| US7356838B2 (en) | 2001-06-06 | 2008-04-08 | Yahoo! Inc. | System and method for controlling access to digital content, including streaming media |
| WO2003044716A2 (en) | 2001-11-20 | 2003-05-30 | Contentguard Holdings, Inc. | An extensible rights expression processing system |
| KR20040101312A (ko) | 2002-03-14 | 2004-12-02 | 콘텐트가드 홀딩즈 인코포레이티드 | 변조된 신호를 사용하여 사용권을 표현하는 시스템 및 방법 |
| DE102004061442B4 (de) * | 2004-12-17 | 2017-01-19 | Thermo Fisher Scientific (Bremen) Gmbh | Verfahren und Vorrichtung zur Messung von Ionen |
-
1997
- 1997-07-14 JP JP18880197A patent/JP3641909B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1132037A (ja) | 1999-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7184986B2 (en) | Content transaction system and method, and program providing medium therefor | |
| US8117128B2 (en) | Content usage management system method, and program providing medium therefor | |
| US7099479B1 (en) | Information transmission system, transmitter, and transmission method as well as information reception system, receiver and reception method | |
| US5590197A (en) | Electronic payment system and method | |
| EP0895148B1 (en) | Software rental system and method for renting software | |
| US6195432B1 (en) | Software distribution system and software utilization scheme for improving security and user convenience | |
| KR100962860B1 (ko) | 소프트웨어 라이센스 관리 시스템, 소프트웨어 제어기, 라이센스 관리 서버, 소프트웨어 제품 사용의 제어 방법 및 라이센스 관리 서버의 작동 방법 | |
| US20030105720A1 (en) | Content secondary distribution management system and method, and program providing medium therefor | |
| US20080154782A1 (en) | Apparatus, method and system for protecting personal information | |
| JP2002141895A (ja) | コンテンツ配信システムおよびコンテンツ配信方法 | |
| JP2002140630A (ja) | チケットに基づくコンテンツ料金精算システムおよびチケットに基づくコンテンツ料金精算方法 | |
| JPH1049584A (ja) | 課金システムおよびその方法 | |
| JP3641909B2 (ja) | 証明データ生成装置 | |
| JP3758316B2 (ja) | ソフトウェアライセンス管理装置および方法 | |
| JP3659090B2 (ja) | 電子情報流通システム及び電子情報流通プログラムを格納した記憶媒体及び電子情報流通方法 | |
| JP2001256413A (ja) | コンテンツ二次配信制限システムおよびコンテンツ二次配信制限方法、並びにプログラム提供媒体 | |
| JP4193920B2 (ja) | 認証方法および装置 | |
| JP2001256196A (ja) | コンテンツ世代間配信制限システムおよびコンテンツ世代間配信制限方法、並びにプログラム提供媒体 | |
| JP3396638B2 (ja) | 利用者署名を用いた電子現金方法、その装置及び記録媒体 | |
| KR100423506B1 (ko) | 아이씨칩내장카드를 이용한 온라인상에서의 소프트웨어불법복제방지방법 | |
| JP2001256403A (ja) | コンテンツ利用料金管理システムおよびコンテンツ利用料金管理方法、並びにプログラム提供媒体 | |
| JP4270589B2 (ja) | 電子度数による支払方法および装置 | |
| JP2001256355A (ja) | コンテンツ利用管理システムおよびコンテンツ利用管理方法、並びにプログラム提供媒体 | |
| JP3329438B2 (ja) | 監視機関つき電子現金方法及びそれを実施するための利用者装置及び監視機関装置 | |
| JP2004046754A (ja) | Ｉｃカード認証システム及びｉｃカード認証方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040928 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041129 |
|
| 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: 20050104 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050117 |
|
| 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: 20080204 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090204 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100204 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110204 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120204 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120204 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130204 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130204 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140204 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |