JP3570114B2

JP3570114B2 - データ検証方法およびデータ検証システム

Info

Publication number: JP3570114B2
Application number: JP27842396A
Authority: JP
Inventors: 和雄齊藤; 吉浩申; 幸史竹田
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 1996-10-21
Filing date: 1996-10-21
Publication date: 2004-09-29
Anticipated expiration: 2016-10-21
Also published as: JPH10123950A; EP0837383B1; US6161183A; DE69737083D1; EP0837383A3; DE69737083T2; EP0837383A2

Description

【０００１】
【産業上の利用分野】
この発明はデータを検証する技術に関し、とくに連続する大量のデータ群、例えば利用履歴のようなデータを安全に伝送あるいは保持しなければならないような情報処理装置一般に用いるのに適したデータ検証技術に関する。
【０００２】
【従来の技術】
昨今のデジタル情報処理技術の発達や、情報ハイウェイ構想などにより、あらゆる情報がデジタル化され、ネットワークを通じて配付・流通される時代が到来しようとしている。すでにインターネットやパソコン通信、あるいはＣＤ−ＲＯＭという形態で、文字情報はもとより、画像、動画、音声、プログラムなどの様々な情報が配付・流通しはじめている。
【０００３】
しかしながら、そのような文字、画像、動画、音声、プログラムなどの様々なデジタル情報は物理的な物とは異なって実体を持たないため、利用しなければ価値がない、複写が容易で、かつ低コストで可能である、などの特徴を持つ。しかし、現在はその所有に対して対価を支払っているため、一旦、ある人に所有された情報が複写されるということを制限している。本来、デジタル情報の最も優れた特徴であるはずの複写容易性やそのコストの低さを無理やりに封じ込めていることになる。
【０００４】
これを解決するために、最近ではプログラムを代表とするデジタル情報を暗号化して自由に流通させ、利用する際には代金を支払って、デジタル情報を利用するための復号鍵を受取り、情報を復号化して利用するようなシステムも登場してきている。あるいは、情報は利用しなければ価値がないという観点から、特公平６−９５３０２号公報におけるソフトウェアサービスシステムや、特開平７−２１２７６号公報の情報利用量測定装置のような、情報の利用に対して課金するような技術が提案されている。
【０００５】
これらの技術によって、パーソナルコンピュータやワークステーションなどの情報処理装置上では、ユーザはプログラムを代表とするソフトウェアを利用する際にはソフトウェアを購入して利用するのではなく、無料または非常に安価に入手し、利用した時に利用に応じて利用料金という形で、例えば一回利用したから幾ら、というように課金がなされるようになった。
【０００６】
情報の利用に対して課金を行うためには、その利用の頻度に応じて個々の利用者から利用料金を回収しなければならない。あるいは場合によっては、一括回収した利用料金を情報を提供した側にその利用頻度に応じて分配しなければならない。そのためには、利用者の環境における利用の履歴を安全に記録し、そして安全に回収する必要がある。
【０００７】
しかし、特開平７−２１２７６号公報では利用履歴を記録する機能として、利用量メーターは存在するが、実際にそこに記録された利用量をどのように回収するかについては触れられていない。
【０００８】
そのための方法としては、利用履歴を利用者が利用する情報処理装置の管理する記憶装置、例えばハードディスク装置などではなく、それとは独立した安全な装置に記録する方法がある。例えば、特公平６−９５３０２号公報ではＩＣカード内に利用の履歴を書き込むようにしている。
【０００９】
また、特開平３−２５６０５号公報の課金情報送出方式や特開平６−１８０７６２号公報の課金情報収集システムではネットワークを通じて課金情報を回収するようにしている。
【００１０】
【発明が解決しようとする課題】
ＩＣカードのような安全な装置に書き込まれた履歴を回収するためには、ネットワークで回収するか、もしくは、その装置から直接に正当な権限を持った回収者が直接的に回収する方法がある。
【００１１】
しかしながら、ネットワークを通じて履歴を回収する方式では、課金情報の安全性すなわち、課金情報が途中で改竄されたり、あるいは利用者が不正な課金情報を作成してそれを送ったりという安全性の面についてはまったく考慮されていなかった。従って、企業内のような一定の信頼のおけるネットワーク内においては適用可能であったが、不特定多数の個人が参加するようなインターネットには、安全性の面から適用できないという問題があった。
【００１２】
従って、安全にＩＣカードのような装置内の履歴を回収するためには、その装置から直接に正当な権限を持った回収者が直接的に回収するしか方法がなかったのである。
【００１３】
しかし、最近になり研究の進んでいる暗号技術、特に電子署名技術を用いると、上記の問題を解決することが可能である。すなわち、安全装置に固有の秘密鍵を封入し、安全装置からデータを取り出す際には必ず署名を施す様にすればよい。これによって、データが正しいことが、データに付随している電子署名を確認することで、後から確認できるようになる。
【００１４】
電子署名はＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号を用いる手法が広く知られている。しかし、ＲＳＡ暗号による署名、あるいは、他の電子署名には、一般に非常に多くの計算量を必要とし、一回の処理に多大な時間がかかるのが普通である。従って、連続する多量のデータに対して署名を施さなければならない場合や、あるいは署名の処理を計算能力が低い計算機上で処理する場合には、非常に大きな問題となる。
【００１５】
利用履歴を記録するような安全装置としてＩＣカードのような装置を用いる場合に、一般にそのようなＩＣカードに搭載可能なＣＰＵの計算能力は低いことが多く、多量の計算をさせると非常に時間がかかるという問題があった。あるいは、計算時間を速くするために、計算能力を高くしようとすると非常に高いコストを要するという課題があった。
【００１６】
また、利用の履歴データは一般に長大になるため、ＩＣカードのような小さな装置にすべての履歴データを記録しようとすると記録容量が問題になるという課題もあった。
【００１７】
なお、元々ＲＳＡ暗号を始めとする現代の暗号技術の安全性は計算量に基礎を置いており、計算機の能力が伸びるとそれに伴って署名や暗号に用いられる鍵長が大きくされるようになっている。従って、将来的に計算機の能力が上がれば解決するという問題ではなく、その時代における最大の処理能力を持つ計算機に比べて低い処理能力の計算機しか使えないような機器（例えば、個人が用いるトークンなど）を用いる場合には将来に渡っても常にこの問題は本質的な課題となる。
【００１８】
この発明はこのような事情に鑑みてなされたものであり、その目的とするところは、計算能力の低い装置に置いても、高速にデータを検証可能なデータを生成できる方法を提供することにある。
【００１９】
すなわち、利用履歴全体をＩＣカード内に保持するのではなく、利用履歴から得られる検証値のみをＩＣカード内に保持し、利用履歴の本体はユーザの管理する情報処理装置（パソコンなど）側に保持させようとするものである。
【００２０】
検証値の観点から従来の技術を参照すると、データ通信に使用される技術であるＤＥＳ−ＭＡＣと呼ばれる技術がある。ＭＡＣとはＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎＣｏｄｅの略であり、メッセージが完全である（改竄されていない）ことを示す一定の長さを持ったコードである。オリジナルのメッセージに添付されて用いられたりする。データ通信は途中でエラーが発生することは致命的であるので、途中でデータが変わってしまったことを検知できるような構成になっている。
【００２１】
ここで、ＤＥＳとはＤａｔａＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄの略で６４ビットを一つのブロックとするブロック暗号のアルゴリズムである（ＡｐｐｌｉｅｄＣｒｙｐｔｏｇｒａｐｈｙｐｐ２６５）。ＣＢＣ（ＣｙｐｈｅｒＢｌｏｃｋＣｈａｉｎ）モード（ＡｐｐｌｉｅｄＣｒｙｐｔｏｇｒａｐｈｙｐｐ１９３，ＪＩＳ−Ｘ５０５１）とはＤＥＳを代表とするブロック暗号の使い方の一種であり、個々のブロックを独立させて暗号化していくのではなく、直前の暗号化されたブロックとこれから暗号化しようとするブロックの排他的論理和を取り、それをＤＥＳの入力とする方式である。この方法だと同じ内容のブロックを暗号化した時にでも、それまでに暗号化したブロックが異なれば暗号化した結果も異なることになる。
【００２２】
ＤＥＳ−ＭＡＣ（ＣＢＣ−ＭＡＣについてＡｐｐｌｉｅｄＣｒｙｐｔｏｇｒａｐｈｙｐｐ４５５を参照）は、ＤＥＳにおけるＣＢＣモードを応用したものであり、最後に得られたブロックをデータストリーム全体の検証値に用いようとするものである。
【００２３】
ＤＥＳ−ＭＡＣの構成を図２１に示す。図の上部が伝送しようとするデータストリームであり、データストリームはそれぞれ６４ビットづつのブロックに分割される。ＩＶとはＩｎｉｔｉａｌＶｅｃｔｏｒの略で乱数で生成された初期値である。分割されたブロックはＤＥＳ−ＣＢＣモードと同様に連鎖的にＤＥＳ暗号器を通していき、先頭にＩＶを、そして最後に得られたブロックを伝送しようとするデータストリームの検証値を付加して伝送される。受信した側ではこの処理と逆の処理を行って得られた検証値が、等しくなるかどうかを検証する。
【００２４】
しかし、このような処理方法は基本的に通信によってデータを伝送することを目的としているものであり、送信者は完全なデータを短時間、確実に保持することが前提となっていることから、完全な履歴の回収に適用しようとすると、問題を生じる。すなわち、履歴データは長期に渡って蓄積され、その間ユーザの恣意的な管理や、システムの事故などの危険に曝される可能性があるからである。
【００２５】
第一に上記の方法（ＤＥＳ−ＭＡＣ）ではデータブロックが連続して伝送されることを前提としている。すなわち、通常データの伝送にはさらに下位の層が存在し（ＴＣＰ／ＩＰ：トランスミッション・コントロール・プロトコル／インターネット・プロトコルではＴＣＰ層が相当する）、その層によってデータブロックの順番が保証されることになる。
【００２６】
しかしながら、利用履歴の場合には、ユーザの管理下に置いてしまうと、その時点で履歴の順序は保証されなくなってしまう。すなわち、ユーザはＩＣカードを自分の使用可能な複数台のコンピュータ（例えばデスクトップＰＣと、ラップトップＰＣなど）に接続して使用することが可能である。利用履歴がコンピュータ側に記録されることを考えると、利用履歴は複数のコンピュータに分散されてしまう。従って、複数台に分散された履歴はその時間的順序は失われてしまうことになる。
【００２７】
利用履歴の場合には時間的な順序が非常に重要な要素となる。すなわち、複数の連続した利用履歴から、後で利用量を計算する可能性があるからである。例えば、簡単な例では利用開始時刻と利用終了時刻との差から利用時間を計算したり、利用開始時の操作対象データ長と利用終了時の操作対象データ長からデータ長の差を計算し、それを利用量としたりするなどの場合である。
【００２８】
ＤＥＳ−ＭＡＣはこういった課題には本質的な解決法を与えていない。
【００２９】
さらに、利用履歴をユーザの管理下に置いた場合のもう一つの課題は、故意もしくは事故によって、それらの一部が失われてしまう可能性があるということである。ＤＥＳ−ＭＡＣの場合、その一部が失われてしまうと、検証が不可能になってしまう。ＤＥＳ−ＭＡＣでは送信者が通信の間だけ完全なデータを保持していることが前提なので、そのような場合は再送信を行えば済む。しかし、利用履歴の場合には、履歴が失われるということは本質的にデータが失われることであるので、復元は不可能である。ＤＥＳ−ＭＡＣの方式をそのまま使用すると、残ったデータの検証さえ行うことができなくなってしまう。
【００３０】
さらにまた、利用量課金を行うようなシステムにおいては、ユーザの手もとに残された履歴を回収することは必須である。履歴を回収しないと、ユーザの利用料金を計算できなかったり、あるいは、回収した利用料金を情報の提供者に分配できなかったりするという問題があるからである。
【００３１】
従って、ユーザの手もとに残された利用履歴を安全に回収しなければならない。そのためには、偽の回収命令などによって、回収が行われてしまうようなことが無いようにしなければならない。
【００３２】
従って、この発明の目的とするところは、計算能力の低く、記憶容量が小さくても、高速にかつ長大なデータを検証可能な装置を提供することにある。
【００３３】
さらに、この発明の第二の目的は、データの順序が保存されないような環境においても、順序を復元可能な方法を提供することになる。
【００３４】
さらに、この発明の第三の目的はデータの一部が失われた場合でも、残ったデータの検証が可能な方法を提供することである。
【００３５】
さらに、この発明の第四の目的は、データを保持する装置を外部から安全に制御する方法を提供することにある。
【００３６】
【課題を解決するための手段】
この発明は、上記の課題を解決するために、基本的には、保持するデータ量を減らすために、データを防御装置内に記録せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保持するようにした。そして、具体的な構成では、高速にデータの検証を行うことができるように、電子署名の代わりに一方向性関数によって検証を行うようにした。一般にＭＤ５を代表とするハッシュ関数はＲＳＡの暗号化処理に比べるとソフトウエアで実現した場合には３桁程度ハッシュ値の方が速いという結果が出ている。また、特に、履歴データの順序を復元可能とするために、履歴データに順序を復元可能な情報を付加した。さらに、具体的には、防御装置を安全に制御するために、防御装置が保持する検証値に対して正当者の署名を付与した値が必要な構成とした。これにより防御装置内の検証値が正当者に強制的に送られ、検証の実行を確保している。
【００３７】
さらに、この発明の構成について説明する。この発明の一側面によれば、上述の目的を達成するために、防御された装置の内部において順次に生成される複数のデータ本体を、上記防御された装置の外部に送出して、上記防御された装置の外部に設けられ上記防御された装置の記憶容量より大きな記憶容量を有するデータ本体記憶部に記憶するデータ記憶システムにおいて上記データ本体の真正を検証するデータ検証方法において：上記防御された装置の内部において順次に生成され、かつ上記防御された装置の外部に送出される複数のデータ本体の各々について、当該データ本体と、当該データ本体に先行するデータ本体の検証値とを合成したものに対して一方向性関数を適用して、当該データ本体に先行するデータ本体を参照することなしに、当該データ本体の検証値を、上記防御された装置の内部において、生成するステップと；一度に検証される複数のデータ本体のグループごとに、上記複数のデータ本体の内の最後のデータ本体に対して生成された検証値に上記防御された装置の内部においてデジタル署名を施して署名付き検証値を生成するステップと；上記署名付き検証値を、上記防御された装置の外部に送出するステップと、上記複数のデータ本体と上記署名付き検証値とに基づいて上記複数のデータ本体を上記防御された装置の外部において検証するステップとを実行するようにしている。
【００３８】
この構成においては、検証値にデジタル署名を施せばよく計算能力が低くてもよい。また、検証は先行するデータ本体に対する検証値と今回のデータ本体と出計算されるので、１つのデータ本体と１つの検証値のみ保持できれば処理可能であり、記憶容量が小さくてもよい。
【００３９】
また、この発明の他の側面においては、上述の目的を達成するために、防御された装置の内部において複数のデータ本体を順次に生成し、上記防御された装置の外部に送出して、上記防御された装置の外部に設けられ上記防御された装置の記憶容量より大きな記憶容量を有するデータ本体記憶部に記憶するデータ生成装置と、上記防御された装置の外部に送出されたデータの真正を検証するデータ検証装置とを含んでなるデータ検証システムにおいて、上記データ生成装置は：順次にデータ本体を生成する手段と；検証値を保持する検証値保持手段と；上記検証値保持手段において保持されている検証値と新たに生成されたデータ本体とを合成したものに対して一方向性関数を適用して、当該新たに生成されたデータ本体に先行するデータ本体自体を参照することなしに、新たな検証値を生成し、上記新たな検証値で上記検証値保持手段に保持されている検証値を更新する検証値生成手段と；一度に検証される複数のデータ本体のグループごとに、上記複数のデータ本体のグループの内の最後のデータ本体に対して生成された検証値に上記防御された装置の内部においてデジタル署名を施して上記署名付き検証値を生成する署名手段とを上記防御された装置内に設けてなり、上記データ検証装置は：順次に生成された複数のデータ本体と、上記複数のデータ本体から計算された検証値に署名が施された署名付き検証値とを受け取る手段と；受け取った上記署名付き検証値の署名を検証する署名検証手段と；上記署名検証手段により署名の検証された検証値から、受け取った上記複数のデータ本体が正しいことを検証する検証手段とを有してなるようにしている。
【００４０】
この構成においても、検証値にデジタル署名を施せばよく計算能力が低くてもよい。また、検証は先行するデータ本体に対する検証値と今回のデータ本体と出計算されるので、１つのデータ本体と１つの検証値のみ保持できれば処理可能であり、記憶容量が小さくてもよい。
【００４１】
この発明の上述の側面およびこの発明の他の側面は特許請求の範囲に記載され、以下、実施例を用いて詳細に説明される。
【００５６】
また、この発明は、その一部をコンピュータプログラム製品として実現することができる。
【００５７】
【発明の実施の態様】
［第１の実施例］
以下、この発明の実施例について説明する。まず第１の実施例について説明する。この実施例も後述する他の実施例も、暗号化されて流通しているプログラムや画像情報などのデジタル情報一般を、パソコンやワークステーションなどの情報処理装置上で利用し、その際の利用履歴をその情報処理装置に接続したＩＣカード（以下、トークンと呼ぶ）において、情報を復号するタイミングをとらえて記録し、その利用履歴をセンターが回収するというシステムである。もちろん履歴データのセキュリティ確保以外にもこの発明を適用することができる。
【００５８】
図１は、この実施例の全体的な構成を示す。図１において、利用者の環境にはパソコンやワークステーションなど、デジタル情報を利用するための情報処理装置１１があり、それには暗号化された情報を復号する（あるいは復号するための鍵を復号する）ため、およびそのタイミングを捕らえて利用履歴を記録するためのトークン１２が接続されている。トークン１２と情報処理装置１１の間の接続は、ＰＣカード（ＰＣＭＣＩＡ：パーソナル・コンピュータ・メモリ・カード・インターフェース・アソシエーション）インターフェース、シリアル、パラレル、赤外線など、情報を伝達できる手段であれば何でも用いることができる。情報処理装置１１の内部に実装するようにしてもよい。
【００５９】
ユーザの情報処理装置１１はセンター側の、ワークステーションあるいは大型計算機などの情報処理装置で構成される回収装置１３と必要に応じて接続される。接続の形態は、モデムと電話回線、あるいはイーサネットなどのネットワークインターフェースでよい。この接続は常時行われる訳ではなく、利用者の情報処理装置１１から利用履歴の回収が必要な時のみ行われれば十分である。
【００６０】
図２にユーザ側の情報処理装置１１の構成を示す。ユーザの情報処理装置１１は一般のパソコンやワークステーションで良い。トークン１２が接続されているところのみが異なる。情報処理装置１１は、制御部１４、情報保持部１５、履歴保持部１６および履歴送信部１７を実現する。このような構成は、例えばプログラムが記録された記録媒体１１ａを用いて当該プログラムをインストールすることにより実現できる。
【００６１】
制御部１４はトークン１２と通信しながら、以下のような処理を行う。
▲１▼情報保持部１５に格納されている暗号化された情報を読み出し、トークン１２へ渡して復号してもらい、復号された情報を実行あるいは処理する。
▲２▼復号データを受け取った際に同時にトークン１２から渡される利用履歴を受け取り、それを履歴保持部１６に格納する。
▲３▼ユーザからの指示を受けて、トークン１２に「検証値出力」の命令を出し、その結果である電子署名の施された検証値を履歴送信部１７に渡す。
【００６２】
情報保持部１５は利用者が利用するデータや情報、あるいは暗号化されたデータが格納されている。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。
【００６３】
履歴保持部１６は制御部１４を通じてトークン１２側から渡された履歴が格納される。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。履歴の具体的な構成については後述する。
【００６４】
履歴送信部１７は制御部１４からの命令を受けて、制御部１４から渡された検証値と共に履歴保持部１６に保持されている履歴を読み出して、センターの回収装置１３に送信する。実際にはモデムと電話回線、あるいはイーサネットなどのネットワークインターフェースなどで構成される。あるいは、ネットワークでなくともフロッピーディスクなどの装置へ一旦格納し、それをユーザが人手でセンターの回収装置１３に入力するようにしてもよい。
【００６５】
図３にユーザ側のトークン１２の構成を示す。トークン１２は物理的には一般のＭＰＵ、メモリ等から構成される。トークン１２はそれ自体が、メモリの内容を読み出したり破壊したりするなど、外部からの物理的な攻撃に耐えるように攻撃対抗容器内に収められる。攻撃対抗容器は周知の技術であるので（特許第１８６３５３号、特許第１８６０４６３号、特開平３−１００７５３号公報等）、ここでは説明を省略する。なお、どの程度の攻撃に耐えうるものを選ぶかはデータのセキュリティの程度に応じて変化する。攻撃態勢が弱いものでもよい場合もある。
【００６６】
トークン１２はユーザの情報処理装置１１に接続され、情報処理装置１１からの指示に従って一定の処理を行い、その結果を返す。トークン１２はユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、検証値出力部２２、トークン秘密鍵保持部２３、電子署名部２４等を有している。トークン１２の各構成部については後に詳述する。トークン１２は以下の機能を持つ。
【００６７】
▲１▼情報の復号機能と利用履歴の保持
（１）情報処理装置１１から暗号化データを受け取り、それをユーザ秘密鍵保持部１８に格納されている秘密鍵で復号し、復号データを情報処理装置１１に返す。
（２）復号処理を行うと同時に復号されたデータのヘッダを参照し、そこに記されている情報識別子を参照し、その識別子を利用履歴として情報処理装置１１に返す。
（３）さらに、利用履歴は検証値生成部２０にも渡され、検証値生成部２０は利用履歴とその時点で検証値保持部２１に保持している検証値とに対して計算を行い、その計算結果を検証値保持部２１に格納する。
【００６８】
▲２▼検証値の出力機能
情報処理装置１１からの出力要求を受けて、その時点で検証値保持部２１に保持している検証値に電子署名を施して返す。その後、検証値保持部２１内のデータを消去する。
【００６９】
以下、トークン１２の各構成部について説明する。
【００７０】
復号部１９は情報処理装置１１からの復号要求に答えて、渡された暗号化データを、ユーザ秘密鍵保持部１８に保持されているユーザ固有の秘密鍵を用いて復号処理を行い、その結果を復号データとして情報処理装置１１側へ返す。このとき、それと同時に復号したデータのヘッダを読み取り、そこに記されている情報識別子を利用履歴として情報処理装置１１側へ返すと共に、検証値生成部２０にも渡す（この例では利用履歴は、利用した情報の情報識別子を用いている）。
【００７１】
このように構成することで、ユーザは情報を利用する際には必ずトークン１２へのアクセスが必要となり、利用履歴を確実に記録することができるようになる。
【００７２】
ここで、情報処理装置１１側から渡される暗号データは、情報そのものが暗号化されたものでもよいし、あるいは暗号化された情報を復号するための鍵を暗号化したものでもよい。後者の場合には情報処理装置１１側で情報本体の復号処理がなされることになる。
【００７３】
ユーザ秘密鍵保持部１８は、ユーザ固有の秘密鍵を保持する。一般的には、トークン１２は予めトークン発行センターなどによって、ユーザごとの固有の鍵を封入した形でユーザに配布される。従って、このユーザ秘密鍵はユーザ自身も知ることができない。
【００７４】
検証値保持部２１は順次更新される一つの検証値のみを保持する。検証値は一般に１６バイトなど、固定の長さを持つ値である。従って、検証値が１６バイトであるならば、１６バイトのメモリだけで構成される。図４に検証値の構成例を示す。
【００７５】
検証値出力部２２は、情報処理装置１１側からの検証値の出力要求を受けて、その時点で検証値保持部２１に格納されている検証値を読み出し、それを情報処理装置１１側に返すという機能を持つ。その際、検証値出力部２２は電子署名部２４を呼び出して、検証値に対して電子署名を施す。
【００７６】
電子署名部２４はそのトークン専用の秘密鍵を保持するトークン秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。トークン秘密鍵保持部２３は電子署名を行う際に用いられる署名用の秘密鍵を保持する構成部である。これらの構成部にはＲＳＡ署名などの電子署名技術を用いることが可能であり、従来の技術であるのでここでは詳細な説明は省略する。
【００７７】
検証値生成部２０は復号部１９から利用履歴（ここでは情報識別子）を受け取ったら、検証値保持部２１に保持されている検証値を読み取り、利用履歴と検証値とから、以下のような計算を行って新しい検証値を計算する。
【００７８】
【数１】
Ｈ＝Ｈａｓｈ（Ｕｓａｇｅ＋Ｈｏｌｄ）
ここで、Ｈは新しい検証値、Ｈｏｌｄは現在の検証値、Ｕｓａｇｅは利用履歴、Ｈａｓｈ（）は一方向性関数を意味し、実際にはＭＤ５やＳＨＡ（ＳｅｃｕｒｅＨａｓｈＡｌｇｏｒｉｔｈｍ）などが用いられる。この演算における”＋”という演算は実際に数値として足し算を行ってもよいし、長さが同じであれば排他的論理和を取っても、あるいは、単に二つのデータを順に並べただけでもよい。いずれにしろ二つの値を合成したものであればよい。検証値生成部２０はこのように計算した新しい検証値を、検証値保持部２１に格納する（つまり、古い値を上書きする）。
【００７９】
検証値出力部２２は情報処理装置１１からの出力要求を受け、その時点で検証値保持部２１に保持している検証値を返してから、検証値保持部２１を予め決められた値に初期化するようにする。あるいは単純にクリアするようにしてもよい。
【００８０】
次にセンターの回収装置１３について説明する。回収装置１３の構成を図５に示す。図５において、回収装置１３は、履歴受信部２５、履歴保持部２６、履歴検証部２７、トークン公開鍵保持部２８、署名検証部２９等を有している。回収装置１３はユーザの情報処理装置１１から送られた履歴を履歴受信部２５によって受信し、その内容を履歴保持部２６に格納する。格納された利用履歴は履歴検証部２７によって読み取られ、履歴が正しいかどうかが検証され、その結果はセンター側の管理者に出力される。
【００８１】
一般的にはセンターはこの後、その履歴の内容に従って、情報の利用料金を計算し、その料金を利用者から徴収し、徴収した利用料金を情報の利用履歴の明細に従って、情報提供者に分配するという処理を行う。しかし、本発明の本質とは直接は関係無いのでここでは説明を省略する。
【００８２】
以下、回収装置１３の各構成部について説明する。
【００８３】
履歴受信部２５は情報処理装置１１から送られてくる履歴情報を受信する。実際には情報処理装置１１の履歴送信部１７（図２）と同様にモデムと電話回線あるいはイーサネットなどのネットワークインターフェース、あるはフロッピーディスク装置などの外部からの情報入力装置で構成される。履歴受信部２５によって受信された利用履歴は履歴保持部２６に格納される。
【００８４】
さらに、情報処理装置１１から送られてきた検証値が正当なものであるかどうかを検証するために、トークン公開鍵保持部２８と署名検証部２９を有している。
【００８５】
情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。もし、検証結果が偽であるという結果が出た場合にはその検証値は改竄あるいは偽造された可能性があるので、以下の処理は続行せず、管理者にその旨のメッセージを出力して処理を停止する。
【００８６】
署名が検証された場合は以下の処理が続けられる。
【００８７】
履歴保持部２６は履歴受信部２５から渡された利用履歴および検証結果を保持する。履歴保持部２６は実際にはメモリなどの記憶装置で構成される。
【００８８】
履歴検証部２７は履歴保持部２６に保持された履歴を以下のようにして検証する。
（１）送信された履歴の系列を、ｕｄ_１，ｕｄ_２，ｕｄ_３．．．ｕｄ_ｎとする。
（２）履歴の最後に添付されている検証値を、ｈｕｄとする。
（３）検証値の初期値をｉｈｕｄとすると、以下の計算式に従って、計算した結果であるｈｕｄ’が、送られてきたｈｕｄと等しくなるかどうかを調べる。
【００８９】
【数２】
ｈｕｄ’＝Ｈａｓｈ（ｕｄ_ｎ＋Ｈａｓｈ（ｕｄ_ｎ−１＋．．．Ｈａｓｈ（ｕｄ_２＋Ｈａｓｈ（ｕｄ_１＋ｉｈｕｄ））．．．））
ｈｕｄ＝？ｈｕｄ’
（４）もし等しければ、改竄されていない、等しくなければ改竄されていると判断し、その結果を回収装置の管理者に通知する。
【００９０】
次に各部で処理される情報の形式について説明する。
【００９１】
図６にトークン１２で復号の対象となる暗号化された情報の形式を示す。（ａ）は情報そのものをユーザの秘密鍵で暗号化している場合である。（ｂ）は、最初に情報本体を暗号化するのに用いている秘密鍵をユーザ固有の秘密鍵で暗号化したものを復号し、その結果得られた情報固有の秘密鍵を用いて、情報本体の復号を行うという場合である。（ｂ）の場合には情報本体の復号はトークン１２ではなく、情報処理装置側で行ってもよい。また、ここでは慣用暗号を用いている例を説明しているが、これらは公開暗号を用いてもよいことは言うまでもない。
【００９２】
ここで、情報識別子とは、センターが情報を暗号化させて流通させる時に付与される情報固有の識別子である。情報識別子はセンターによって管理され（データベースを持つなどによって）、情報識別子を特定すると、その情報が誰によって作成されたものであるのか、などを特定できる。
【００９３】
図７には利用履歴の形式を示す。（ａ）は本実施例における情報処理装置１１内に記録される利用履歴であり、利用した（トークンで復号した情報の）情報識別子の列である。（ｂ）は情報処理装置１１からセンターに送付される利用履歴であり、（ａ）の最後にトークンが保持する検証値、および検証値に対するトークンの署名が添付されているところのみが異なる。
【００９４】
個々の利用履歴は本実施例では利用した情報識別子のみで構成されているが、これは任意のデータ、例えば、利用した時刻、利用者の識別子、利用量、利用金額などが含まれていてもよい。すなわち種々の情報を履歴として残す場合（一般に履歴は種々の情報を残すのが一般的である）には個々の履歴が長くなるため、本発明が有効となる。
【００９５】
次に情報処理装置１１およびトークン１２における処理を図８から図１２を参照して説明する。図８は情報処理装置１１の制御部１４において、利用者から情報の利用要求が有った時の処理の流れである。図９は同じく制御部１４において利用者から利用履歴回収命令が有った時の処理である。図１０はトークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理である。図１１はトークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理である。図１２はトークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理である。
【００９６】
図８に示すように、利用者から情報利用の要求があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ１１）、暗号化されていなければ情報をそのまま処理する（Ｓ１５）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ１２）。このとき、トークン１２からエラーが返されたら「トークンの履歴が一杯です」というエラーメッセージを出して処理を終了する（Ｓ１３、Ｓ１６）。エラーが返されなければ、トークン１２から過閲された利用履歴をディスク等の記録装置に記録する（Ｓ１４）。そして対象情報を処理する（Ｓ１５）。
【００９７】
図９に示すように、利用者から利用履歴回収命令があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ２１）、暗号化されていなければ情報をそのまま処理する（Ｓ２４）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ２２）。そしてトークン１２から返された利用履歴をディスク等の記録装置に記録する（Ｓ２３）。こののち対象情報を処理する（Ｓ２４）。
【００９８】
図１０に示すように、トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時にはつぎのように処理が進む。まず、ユーザ秘密鍵保持部１８からユーザ秘密鍵Ｋｕが取り出される（Ｓ３１）。暗号化データをユーザ秘密鍵Ｋｕで復号して復号データを記憶する（Ｓ３２）。復号データのヘッダを参照して情報識別子を読み取り、この識別子を引数として検証値生成部２０を呼び出し検証値生成処理を実行させる（Ｓ３３、Ｓ３４、図１１参照）。この後復号データと識別子とを情報処理装置１１に返す（Ｓ３５）。
【００９９】
図１１に示すように、トークン１２の検証値生成部２０がトークン１２の復号部１９から呼び出されたときにはつぎのように処理が進む。まず、検証値保持部２１から検証値を取り出す（Ｓ４１）。情報識別子と検証値とについてハッシュ計算を行って、計算結果を新たな検証値として検証値保持部２１に記憶する（Ｓ４２、Ｓ４３）。
【０１００】
図１２に示すように、トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時にはつぎのように処理が進む。まず、検証値保持部２１に記憶されている検証値を読み出す（Ｓ５１）。こののち、検証値保持部２１の記憶内容を初期化する（Ｓ５２）。読み出した検証値を引数として電子署名部２４を呼び出し、検証値に署名を施す（Ｓ５３）。検証値の後に署名を付して出力する（Ｓ５４）。
【０１０１】
以上で第１の実施例の説明を終了する。
【０１０２】
なお、特願平８−６２０７６号のユーザ認証装置および方法を、本発明と組み合せて使用した場合には、発行するアクセスチケットごとにべき乗剰余の計算における法ｎを変えるようにすることで、法ｎを情報識別子として用いることができる。すなわち、特願平８−６２０７６号のユーザ認証手法ではアクセスチケット（認証用補助情報）を外部から受け取り、このアクセスチケットとユーザ識別情報とを用いて証明、例えば暗号データの復号を行うようになっている。そして、このときに用いる法ｎを情報識別子として利用する。その場合には、法ｎはトークンの内部の復号装置で復号されてから取り出されるのではなく、復号対象の情報と共に外部から与えられることになる。
【０１０３】
このように構成することで、トークン１２内部に用意しなければならない検証値保持部２１の容量を最小に押さえることができ、トークン１２の生産コストを低くすることが可能となる。
【０１０４】
［第２の実施例］
次に本発明の第２の実施例について説明する。ここで述べる実施例は第１の実施例に対して、幾つかの機能を追加したものである。以下にその機能と効果について列挙する。
【０１０５】
▲１▼トークン１２が検証値を出力して機能を停止し、センターからメッセージを受け取ると機能を回復する。
【０１０６】
検証値を外部に出力する時やあるいは時計機能を用いて一定時間を経過した時などに、利用者に履歴の回収を促すためにトークン１２がその時点での検証値を出力して停止するようにする（あるいは自律的に停止して検証値を要求するようにしてもよい）。利用者がトークン１２の機能を回復させるためにはセンターに履歴と検証値を送信して、確認してもらい、センターから機能を回復させるためのメッセージを受け取るしかない。センターが発行する機能回復用のメッセージは、ユーザから送られた検証値にセンターが電子署名を施したものとする。
【０１０７】
▲２▼履歴としてその利用履歴を処理した時点での検証値も出力する。
【０１０８】
利用履歴の内容を情報識別子だけではなく、その履歴を生成した時点での検証値も含ませる。これによって、個々の履歴の連続性を後から調べることが可能になり、情報処理装置側での履歴の（順序の）管理を厳密に行わなくても良いようにする。
【０１０９】
▲３▼センター側で古い検証値を保持する。
【０１１０】
これまでの実施例では、利用者からの出力要求によって、トークン内部の検証値は初期化されていた。しかしながら、センターの回収装置側で利用者の前回の検証値を保持することによって、その機能を不要にすることができる。
【０１１１】
図１３に本実施例におけるトークン１２の構成を示す。なお、図１３において図３に対応する箇所には対応する符号を付して詳細な説明を省略する。この図において、トークン１２は、ユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、トークン秘密鍵保持部２３、電子署名部２４、制御部３０、履歴生成部３１、計数部３２、センター公開鍵保持部３３、署名検証部３４等を有している。なお、必要に応じて時計部３５を設けてもよい。
【０１１２】
本実施例では情報処理装置１１との通信はすべて制御部３０を介して行われるように構成され、制御部３０は情報処理装置１１からの要求に対し適切に他の処理部を呼出して処理を行う。
【０１１３】
制御部３０はその内部にトークン１２の動作状態を保持しており、動作状態には通常モードと停止モードの二つのモードがある。通常モードにおいてはトークン１２は情報処理装置１１からの復号要求に対して、第１の実施例で述べたように復号処理を行い、その結果を返すという処理を行う。一方、停止モードにおいては復号要求の処理は受け付けない。停止モードにおいては基本的には機能再開要求（センター署名付き検証値）のみを受け付け、その要求が正当である場合には停止モードを解除し、通常モードへ移行するという処理を行う（実際にはそれ以外にもその時点で検証値保持部２１に保持している検証値に署名した検証値を出力するという処理も受け付けるようにしてもよい）。
【０１１４】
通常モードから停止モードへの移行は、例えば復号処理を行った回数などによる。図１３の計数部３２は復号処理を行った回数を保持している。例えば、その回数が予め定められた回数（例えば１００回など）を超えたら、「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１１５】
構成として時計を有する場合には、制御部３０内部に保持された前回の停止時刻の情報に基づいて行うようにしてもよい。すなわち、制御部は情報処理装置からの要求があったとき、制御部内に保持された前回停止時刻と現在の時刻を比較し、予め決められた時間（例えば一か月、など）が経過していた場合には「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１１６】
つぎにトークン１２の制御部３０の処理を図１４〜図１６を参照して詳細に説明する。なお、図１４〜図１６において点線で示してある箇所は制御部３０の処理ではなく、関連する構成部の処理であることを意味する。
【０１１７】
図１４において、情報処理装置１１からトークン１２の制御部３０に復号要求、検証値出力要求および機能再開要求のいずれかが入力される。まず、制御部３０のモードが停止モードかどうかが判別される（Ｓ６１）。停止モードでないときには計数部３２の計数値が読み取られ、この計数値が基準値、例えば１００を越えたかどうかが判別される（Ｓ６２、Ｓ６３）。１００を越えていない場合には図１６のノードＢに進み、復号処理等を行う。１００を越えている場合には署名付き検証値を出力する。すなわち、検証値保持部２１の値を読み出し、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ６４、Ｓ６５）。こののち、署名付き検証値と「停止モードへ移行」というメッセージを情報処理装置１１に返す（Ｓ６６）。そして計数部３２の計数値をクリアして停止モードに移行する（Ｓ６７、Ｓ６８）。
【０１１８】
ステップＳ６１において、制御部３０が停止モードの場合には、受け取った要求が復号要求か、検証値出力要求か、機能再開要求かが判別される（Ｓ６９、Ｓ７０、Ｓ７１）。要求が復号要求の場合には情報処理装置１１に「現在は停止モードである」というメッセージを返し、処理を終了する（Ｓ７２）。要求が検証値出力要求の場合には検証値保持部２１の検証値を読み取り、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ７３、Ｓ７４）。こののち、署名付き検証値を情報処理装置１１に返し処理を終了する（Ｓ７５）。機能再開要求のときには図１５のノードＡの機能再開処理に進む。受け取った要求が復号要求、検証値出力要求、機能再開要求のいずれでもない場合には情報処理装置１１にエラーを返して処理を終了する（Ｓ７６）。
【０１１９】
図１５は機能再開処理を示す。図１５において、まず、受け取ったセンター署名付き検証値を署名検証部２４に渡して署名の正当性を検証する（Ｓ７７）。署名が正しければ、渡された検証値と、検証値保持部２１の検証値とを比較し、双方が一致するかどうかを検査する（Ｓ７８〜Ｓ８０）。一致すれば制御部のモードを停止モードから通常モードに移行させ、「機能再開」のメッセージを情報処理装置１１に返す（Ｓ８１、Ｓ８２）。ステップＳ７８において署名が正しくない場合には、「署名が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８３）。ステップＳ８０において検証値が一致しない場合には「検証値が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８４）。
【０１２０】
図１６は計数値が閾値例えば１００を上回っていない場合の処理を示す。図１６において、まず要求が復号要求かどうかが検査される（Ｓ８５）。復号要求の場合には渡されたデータを復号部１９に送る（Ｓ８８）。復号部１９は復号を行う（Ｓ８９〜Ｓ９３）。また要求が復号要求でない場合には検証値要求かどうかが判別される（Ｓ８６）。検証値要求である場合には図１４のノードＣに進み、検証値出力処理を行う。ステップＳ８６において検証値出力要求でもない場合にはエラーを情報処理装置１１に返して処理を終了する（Ｓ８７）。
【０１２１】
以上でトークン１２の制御部３０の処理の説明を終える。
【０１２２】
なお、この例では、情報処理装置１１側から検証値要求が有った時にも停止モードへ移行するようにしているけれども（図１６のステップＳ８６から図１４のノードＣへ移行）、そうしなくても構わない。例えば通常モードにおける検証値要求に対しては、検証値を更新して単にその時点で保持している検証値に署名した値を返すようにしてもよい（このメリットについては本実施例の説明の最後で述べる）。
【０１２３】
復号部１９、ユーザ秘密鍵保持部１８は第１の実施例と同様の機能を有する。
【０１２４】
履歴生成部３１は図１６でも示したように復号部１９から渡された情報識別子と現在の検証値の三つの組を生成し、それを利用履歴として制御部３０に渡すという処理を行う。
【０１２５】
検証値生成部２０は履歴生成部３１から渡された履歴ｕｄに対し、
【０１２６】
【数３】
Ｈｕ＝Ｈａｓｈ（ｕｄ）
なるハッシュ値を計算し、それを検証値保持部２１に格納するという処理を行い、検証値保持部２１はその時点での検証値を保持する。
【０１２７】
電子署名部２４は第１の実施例と同様に、そのトークン専用の秘密鍵を保持する秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。本実施例ではさらに、署名検証部３４が設けられ、センター公開鍵保持部３３に保持されたセンターの公開鍵を用いて渡された署名がセンターの署名であるかどうかを検証するという処理を行う。これらの構成部には基本的にはＲＳＡ署名などの電子署名技術を用いることが可能であり、周知の技術であるのでここでは詳細な説明は省略する。
【０１２８】
本実施例における情報処理装置１１の構成を図１７に示す。図１７において図２と対応する箇所には対応する符号を付す。この図において、基本的には第１の実施例のものとほぼ同じ構成であるが、本実施例の情報処理装置１１ではある時点でトークンが停止モードに入ってしまうので、それを再開させるためにはセンターに履歴を送信し、それに対する再開メッセージを送ってもらわねばならない。そこで、センターからの署名付きの検証値を受け取る署名付き検証値受信部３６があるところが異なる。また、履歴保持部１６に保持される履歴の構成が異なっている。
【０１２９】
図１８に本実施例におけるセンターの回収装置１３の構成を示す。図１８において図５と対応する箇所には対応する符号を付す。この図において、構成としては第１の実施例のものに比べると、履歴の正当性が検証された場合には情報処理装置１１にセンターの署名付き検証値を送らねばならないので、それを行うための構成部、すなわちセンター秘密鍵保持部３７、電子署名部３８、署名付き検証値送信部３９が増設されている。また、情報処理装置１１側から送られる利用履歴の構成が異なっているので、当然回収センターで処理される履歴も異なる。
【０１３０】
図１９に各部で保持される利用履歴の構成を示す。
（ａ）は情報処理装置１１の履歴保持部１６に記録される利用履歴である。個々の履歴の内容は（ｃ）に示されたような情報識別子とその時点でトークンに保持されていた検証値のペアの構成となっている。
【０１３１】
情報処理装置１１からセンターに履歴を送付する際には、その履歴の列の最後にトークン１２の署名の付いた検証値が付与される（ｂ）。署名付き検証値はトークン１２が機能を停止した際に出力されるものであり、その時点での検証値にトークン１２が電子署名を施したものである（ｄ）。
【０１３２】
センターは履歴の検証のために（ｄ）の署名付き検証値を用いる。そして検証の結果、正当なものであると判断されると、トークン１２の機能を再開させるためのメッセージとして最後に添付された検証値にセンターが電子署名を施した値を情報処理装置１１に送る。それが（ｅ）である。
【０１３３】
次に回収装置１３の処理について説明する。情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。
【０１３４】
履歴の受信が終わると履歴検証部２７が動作しはじめる。履歴検証部２７は今受信した履歴を参照し、それに付随している署名の検証結果を参照する。署名の検証結果が正当でない場合には、これ以降の処理は行われない。履歴に付随している検証結果が正当であれば、さらに履歴の内容が正当であるかどうかを検証する。
【０１３５】
履歴の内容の検証処理は以下のように行われる。
（１）送られてきた履歴の列が以下のようなものであるとする。
（ｉｄ_１，ｈｕ_０），（ｉｄ_２，ｈｕ_１），（ｉｄ_３，ｈｕ_２），．．．，（ｉｄ_ｎ，ｈｕ_ｎ−１），ｓｉｇｎ（ｈｕ_ｎ）
ただし、ここでｉｄは情報識別子、ｈｕはその履歴が生成された時点での検証値、ｓｉｇｎ（）はトークンのサインであるとする。
（２）トークンが前回送ってきた際の検証値を履歴保持部の中から捜し出し、それをＨｕｏｌｄとする。
（３）送られてきた利用履歴の最初の履歴（ＩＤ_１，ｈｕ_０）の中から検証値ｈｕ_０を取り出し、それがＨｕｏｌｄと等しいかどうかを確かめる。
（４）次にＨａｓｈ（ｉｄ_１，ｈｕ_０）を計算し、それがｈｕ_１になるかどうかを確かめる。
（５）以下同様にして最後の検証値ｈｕ_ｎまで確かめる。
（６）すべての検査にパスしたら利用履歴は正当なものであると判断する。
【０１３６】
検証処理の結果、履歴が正しいものと判断された場合のみ、最後の検証値ｈｕｎが電子署名部に送られ、センターの秘密鍵で電子署名が施される。そして、センターの署名付きの検証値が履歴を送付してきた情報処理装置に送り返される。
【０１３７】
以上のように構成することで、ある時点でトークンが機能を停止するため、その情報処理装置の利用者はトークンの機能を再開させるためには正当な履歴をセンターに送付しなければならなくなる。従って、履歴の回収を利用者に促すことが可能になる。
【０１３８】
また、センター側に最後の検証値が記録されているため、トークンから送付された正しい履歴が何らかの理由で一部が破壊されていた場合でも、単に検証が成功しなかっただけであるので、センター側の保持データは何も変化しない。従って、その場合にはトークンが履歴を再送付すれば検証は正常に行われることになる。
【０１３９】
また本実施例において、トークンが自律的に検証値を出力するように構成することで、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証可能なようにすることができる。
【０１４０】
すなわち、前述したように利用者が検証値を要求した時だけでなく、トークンの負荷が低いときにトークンが自律的にその時点で保持している検証値に署名したものを出力することによって、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証が可能になる。
【０１４１】
この場合には、センターへ送付される利用履歴は例えば図２０のような構成になる。この時、何らかの事故によって情報処理装置側で履歴２５が失われてしまったとする。
【０１４２】
先に示したような検証値を最後にしか持たないような利用履歴の場合には履歴２６以降は検証可能となるが、履歴１から履歴２４については内容が失われていないにもかかわらずそれが正当であることは検証できない。
【０１４３】
それが途中に署名付の検証値を挿入することによって、この例の場合には履歴２５が失われた場合には履歴２４のみが検証不可能となるだけで、残りの履歴については検証可能となるのである。つまり、履歴１から履歴１０までは署名付き検証値１によって、履歴１１から履歴２３までは署名付き検証値２によって、履歴２５から履歴３６までは署名付き検証値３によって、履歴３７から履歴５７までは署名付き検証値４によって、それぞれが検証可能となるからである。
【０１４４】
このように適当な間隔で署名付きの検証値を履歴中に挿入することで履歴の一部が失われた場合にでも残りの履歴の大部分について検証を可能とすることができるようになるのである。
【０１４５】
これを実現するためにはトークン内部の制御部において負荷が低いかどうかを判定する装置を設け、トークンの負荷が低い場合には自律的に署名付き検証値を生成しておくようにすればよい。
【０１４６】
また、トークンが自律的に行わなくても情報処理装置すなわち利用者からの要求によって署名付き検証値を出力するように構成すればよい。そのためには図１６のノードＣを図１４のノードＣ（ステップＳ６４）に分岐させるのではなく、検証値を更新して署名付き検証値を生成しそれを情報処理装置１１に返すように処理を変更すればよい。
【０１４７】
また、トークンに時計機能を持たせることによって、利用履歴として時刻の情報を取ることができるようになる。それによって、回収センター側は単にどの情報を利用したのかという履歴だけではなく、利用した時刻も知ることができるようになる。時計部は通常の時計機能であり、年月日および時刻を保持し、要求に従って現在の時刻を出力する機能を有するだけでよい。履歴に時刻を含ませるには、前述してきた情報識別子に時刻の情報も結合するだけでよい。また、時計機能を有すると、前述した停止モードへの移行の条件として、「前回に停止した時から経過した時間」にすることが可能になる。
【０１４８】
さらにまた、本実施例では外部に出力する履歴にその時点で保持していた検証値を付与するように構成しているが、これはトークン内部にカウンタ部を設け、履歴を出力するごとにカウンタの値をカウントしていくようにし、履歴を外部に出力する際に検証値ではなく、カウンタの値を出力するようにしてもよい。その場合は、これまでの説明中のハッシュ関数の入力となる部分が、利用履歴およびその時点で保持しているカウンタの値となる。
【０１４９】
【発明の効果】
以上説明したように、この発明によれば、保持するデータ量を減らすために、データを防御装置内に保管せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保管するようにしている。したがって防御装置の記憶容量や必要処理能力を抑えることができる。検証値は署名を付して外部に送られるので改竄を防止でき、データの検証を確実に行える。また、データの順序を復元可能とするために、データに順序復元用の情報を付加することにより、分散して保管されているデータであってもその順序を復元して、検証を容易にすることができる。さらに、防御装置が保持するデータに対して正当者の署名を付与した値を、防御装置が受け取ったときに、関連する処理を継続実行できるようにしているので、継続実行するには、防御装置内に保持したデータを正当者に送り署名を受けた後返送してもらわなければならない。したがって、正当者には必然的に検証対象のデータが送られてきて、検証対象のデータを確実に回収することができる。また、署名付き検証値を頻繁に出力するようにすればデータの一部が破損等しても他の多くのデータについては確実に検証を行うことができる。
【図面の簡単な説明】
【図１】この発明の第１の実施例を全体として示すブロック図である。
【図２】図１の情報処理装置１１の構成を示すブロック図である。
【図３】図１のトークン１２の構成を示すブロック図である。
【図４】図３の検証値保持部２１を説明する図である。
【図５】図１の回収装置１３の構成を示すブロック図である。
【図６】トークン１２において復号される情報を説明する図である。
【図７】利用履歴の構成を説明する図である。
【図８】利用者から情報の利用要求が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図９】利用者から利用履歴回収命令が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図１０】トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理を説明するフローチャートである。
【図１１】トークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理を説明するフローチャートである。
【図１２】トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理を説明するフローチャートである。
【図１３】第２の実施例のトークン１２の構成を示すブロック図である。
【図１４】図１３のトークン１２の処理を説明するフローチャートである。
【図１５】図１３のトークン１２の処理を説明するフローチャートである。
【図１６】図１３のトークン１２の処理を説明するフローチャートである。
【図１７】第２の実施例の情報処理装置１１において実現されている機能ブロックを示すブロック図である。
【図１８】第２の実施例の回収装置１３の構成を示すブロック図である。
【図１９】第２の実施例の利用履歴の構成を説明する図である。
【図２０】第２の実施例の利用履歴の他の構成を説明する図である。
【図２１】関連技術を説明する図である。
【符号の説明】
１１情報処理装置
１２トークン
１３回収装置
１４情報処理装置１１の制御部
１５情報処理装置１１の情報保持部
１６情報処理装置１１の履歴保持部
１７情報処理装置１１の履歴送信部
１８トークン１２のユーザ秘密鍵保持部
１９トークン１２の復号部
２０トークン１２の検証値生成部
２１トークン１２の検証値保持部
２２トークン１２の検証値出力部
２３トークン１２のトークン秘密鍵保持部
２４トークン１２の電子署名部
２５回収装置１３の履歴受信部
２６回収装置１３の履歴保持部
２７回収装置１３の履歴検証部
２８回収装置１３のトークン公開鍵保持部
２９回収装置１３の署名検証部

Claims

防御された装置の内部において順次に生成される複数のデータ本体を、上記防御された装置の外部に送出して、上記防御された装置の外部に設けられ上記防御された装置の記憶容量より大きな記憶容量を有するデータ本体記憶部に記憶するデータ記憶システムにおいて上記データ本体の真正を検証するデータ検証方法において、
上記防御された装置の内部において順次に生成され、かつ上記防御された装置の外部に送出される複数のデータ本体の各々について、当該データ本体と、当該データ本体に先行するデータ本体の検証値とを合成したものに対して一方向性関数を適用して、当該データ本体に先行するデータ本体を参照することなしに、当該データ本体の検証値を、上記防御された装置の内部において、生成するステップと、
一度に検証される複数のデータ本体のグループごとに、上記複数のデータ本体の内の最後のデータ本体に対して生成された検証値に上記防御された装置の内部においてデジタル署名を施して上記署名付き検証値を生成するステップと、
上記署名付き検証値を、上記防御された装置の外部に送出するステップと、
上記複数のデータ本体と上記署名付き検証値とに基づいて上記複数のデータ本体を上記防御された装置の外部において検証するステップとを有することを特徴とするデータ検証方法。
防御された装置の内部において順次に生成される複数のデータ本体を、上記防御された装置の外部に送出して、上記防御された装置の外部に設けられ上記防御された装置の記憶容量より大きな記憶容量を有するデータ本体記憶部に記憶するデータ記憶システムにおいて、上記防御された装置の内部で生成されたデータ本体を上記防御された装置外部に保持した場合に当該防御された装置外部に保持されたデータ本体が当該防御された装置の内部で生成されたことを検証する検証方法において、
上記防御された装置の内部において順次に生成され、かつ上記防御された装置の外部に送出される複数のデータ本体の各々について、当該データ本体と、当該データ本体に先行するデータ本体の検証値とを合成したものに対して一方向性関数を適用して、当該データ本体に先行するデータ本体を参照することなしに、当該データ本体の検証値を、上記防御された装置の内部において、生成するステップと、
一度に検証される複数のデータ本体のグループごとに、上記複数のデータ本体の内の最後のデータ本体に対して生成された検証値に上記防御された装置の内部においてデジタル署名を施して署名付き検証値を生成するステップと、
上記署名付き検証値を、上記防御された装置の外部に送出するステップと、
上記複数のデータ本体と上記署名付き検証値とに基づいて上記複数のデータ本体を上記防御された装置の外部において検証するステップとを有することを特徴とするデータ検証方法。
防御された装置の内部において複数のデータ本体を順次に生成し、上記防御された装置の外部に送出して、上記防御された装置の外部に設けられ上記防御された装置の記憶容量より大きな記憶容量を有するデータ本体記憶部に記憶するデータ生成装置と、上記防御された装置の外部に送出されたデータの真正を検証するデータ検証装置とを含んでなるデータ検証システムにおいて、
上記データ生成装置は、
順次にデータ本体を生成する手段と、
検証値を保持する検証値保持手段と、
上記検証値保持手段において保持されている検証値と新たに生成されたデータ本体とを合成したものに対して一方向性関数を適用して、当該新たに生成されたデータ本体に先行するデータ本体自体を参照することなしに、新たな検証値を生成し、上記新たな検証値で上記検証値保持手段に保持されている検証値を更新する検証値生成手段と、
一度に検証される複数のデータ本体のグループごとに、上記複数のデータ本体のグループの内の最後のデータ本体に対して生成された検証値に上記防御された装置の内部においてデジタル署名を施して上記署名付き検証値を生成する署名手段とを上記防御された装置内に設けてなり、
上記データ検証装置は、
順次に生成された複数のデータ本体と、上記複数のデータ本体から計算された検証値に署名が施された署名付き検証値とを受け取る手段と、
受け取った上記署名付き検証値の署名を検証する署名検証手段と、
上記署名検証手段により署名の検証された検証値から、受け取った上記複数のデータ本体が正しいことを検証する検証手段とを有してなることを特徴とするデータ検証システム。