JP3941711B2 - 電子機器および電子機器の制御方法 - Google Patents
電子機器および電子機器の制御方法 Download PDFInfo
- Publication number
- JP3941711B2 JP3941711B2 JP2003045837A JP2003045837A JP3941711B2 JP 3941711 B2 JP3941711 B2 JP 3941711B2 JP 2003045837 A JP2003045837 A JP 2003045837A JP 2003045837 A JP2003045837 A JP 2003045837A JP 3941711 B2 JP3941711 B2 JP 3941711B2
- Authority
- JP
- Japan
- Prior art keywords
- signature
- data
- history
- function
- electronic
- 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 - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
この発明はデータを検証する技術に関し、とくに連続する大量のデータ群、例えば利用履歴のようなデータを安全に伝送あるいは保持しなければならないような情報処理装置一般に用いるのに適したデータ検証技術に関する。
【０００２】
【従来の技術】
昨今のデジタル情報処理技術の発達や、情報ハイウェイ構想などにより、あらゆる情報がデジタル化され、ネットワークを通じて配付・流通される時代が到来しようとしている。すでにインターネットやパソコン通信、あるいはＣＤ−ＲＯＭという形態で、文字情報はもとより、画像、動画、音声、プログラムなどの様々な情報が配付・流通しはじめている。
【０００３】
しかしながら、そのような文字、画像、動画、音声、プログラムなどの様々なデジタル情報は物理的な物とは異なって実体を持たないため、利用しなければ価値がない、複写が容易で、かつ低コストで可能である、などの特徴を持つ。しかし、現在はその所有に対して対価を支払っているため、一旦、ある人に所有された情報が複写されるということを制限している。本来、デジタル情報の最も優れた特徴であるはずの複写容易性やそのコストの低さを無理やりに封じ込めていることになる。
【０００４】
これを解決するために、最近ではプログラムを代表とするデジタル情報を暗号化して自由に流通させ、利用する際には代金を支払って、デジタル情報を利用するための復号鍵を受取り、情報を復号化して利用するようなシステムも登場してきている。あるいは、情報は利用しなければ価値がないという観点から、特公平６−９５３０２号公報におけるソフトウェアサービスシステムや、特開平７−２１２７６号公報の情報利用量測定装置のような、情報の利用に対して課金するような技術が提案されている。
【０００５】
これらの技術によって、パーソナルコンピュータやワークステーションなどの情報処理装置上では、ユーザはプログラムを代表とするソフトウェアを利用する際にはソフトウェアを購入して利用するのではなく、無料または非常に安価に入手し、利用した時に利用に応じて利用料金という形で、例えば一回利用したから幾ら、というように課金がなされるようになった。
【０００６】
情報の利用に対して課金を行うためには、その利用の頻度に応じて個々の利用者から利用料金を回収しなければならない。あるいは場合によっては、一括回収した利用料金を情報を提供した側にその利用頻度に応じて分配しなければならない。そのためには、利用者の環境における利用の履歴を安全に記録し、そして安全に回収する必要がある。
【０００７】
しかし、特開平７−２１２７６号公報では利用履歴を記録する機能として、利用量メーターは存在するが、実際にそこに記録された利用量をどのように回収するかについては触れられていない。
【０００８】
そのための方法としては、利用履歴を利用者が利用する情報処理装置の管理する記憶装置、例えばハードディスク装置などではなく、それとは独立した安全な装置に記録する方法がある。例えば、特公平６−９５３０２号公報ではＩＣカード内に利用の履歴を書き込むようにしている。
【０００９】
また、特開平３−２５６０５号公報の課金情報送出方式や特開平６−１８０７６２号公報の課金情報収集システムではネットワークを通じて課金情報を回収するようにしている。
【００１０】
【発明が解決しようとする課題】
ＩＣカードのような安全な装置に書き込まれた履歴を回収するためには、ネットワークで回収するか、もしくは、その装置から直接に正当な権限を持った回収者が直接的に回収する方法がある。
【００１１】
しかしながら、ネットワークを通じて履歴を回収する方式では、課金情報の安全性すなわち、課金情報が途中で改竄されたり、あるいは利用者が不正な課金情報を作成してそれを送ったりという安全性の面についてはまったく考慮されていなかった。従って、企業内のような一定の信頼のおけるネットワーク内においては適用可能であったが、不特定多数の個人が参加するようなインターネットには、安全性の面から適用できないという問題があった。
【００１２】
従って、安全にＩＣカードのような装置内の履歴を回収するためには、その装置から直接に正当な権限を持った回収者が直接的に回収するしか方法がなかったのである。
【００１３】
しかし、最近になり研究の進んでいる暗号技術、特に電子署名技術を用いると、上記の問題を解決することが可能である。すなわち、安全装置に固有の秘密鍵を封入し、安全装置からデータを取り出す際には必ず署名を施す様にすればよい。これによって、データが正しいことが、データに付随している電子署名を確認することで、後から確認できるようになる。
【００１４】
電子署名はＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号を用いる手法が広く知られている。しかし、ＲＳＡ暗号による署名、あるいは、他の電子署名には、一般に非常に多くの計算量を必要とし、一回の処理に多大な時間がかかるのが普通である。従って、連続する多量のデータに対して署名を施さなければならない場合や、あるいは署名の処理を計算能力が低い計算機上で処理する場合には、非常に大きな問題となる。
【００１５】
利用履歴を記録するような安全装置としてＩＣカードのような装置を用いる場合に、一般にそのようなＩＣカードに搭載可能なＣＰＵの計算能力は低いことが多く、多量の計算をさせると非常に時間がかかるという問題があった。あるいは、計算時間を速くするために、計算能力を高くしようとすると非常に高いコストを要するという課題があった。
【００１６】
また、利用の履歴データは一般に長大になるため、ＩＣカードのような小さな装置にすべての履歴データを記録しようとすると記録容量が問題になるという課題もあった。
【００１７】
なお、元々ＲＳＡ暗号を始めとする現代の暗号技術の安全性は計算量に基礎を置いており、計算機の能力が伸びるとそれに伴って署名や暗号に用いられる鍵長が大きくされるようになっている。従って、将来的に計算機の能力が上がれば解決するという問題ではなく、その時代における最大の処理能力を持つ計算機に比べて低い処理能力の計算機しか使えないような機器（例えば、個人が用いるトークンなど）を用いる場合には将来に渡っても常にこの問題は本質的な課題となる。
【００１８】
この発明はこのような事情に鑑みてなされたものであり、その目的とするところは、計算能力の低い装置に置いても、高速にデータを検証可能なデータを生成できる方法を提供することにある。
【００１９】
すなわち、利用履歴全体をＩＣカード内に保持するのではなく、利用履歴から得られる検証値のみをＩＣカード内に保持し、利用履歴の本体はユーザの管理する情報処理装置（パソコンなど）側に保持させようとするものである。
【００２０】
検証値の観点から従来の技術を参照すると、データ通信に使用される技術であるＤＥＳ−ＭＡＣと呼ばれる技術がある。ＭＡＣとはＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅの略であり、メッセージが完全である（改竄されていない）ことを示す一定の長さを持ったコードである。オリジナルのメッセージに添付されて用いられたりする。データ通信は途中でエラーが発生することは致命的であるので、途中でデータが変わってしまったことを検知できるような構成になっている。
【００２１】
ここで、ＤＥＳとはＤａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄの略で６４ビットを一つのブロックとするブロック暗号のアルゴリズムである（Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ２６５）。ＣＢＣ（ＣｙｐｈｅｒＢｌｏｃｋ Ｃｈａｉｎ）モード（Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ１９３， ＪＩＳ−Ｘ５０５１）とはＤＥＳを代表とするブロック暗号の使い方の一種であり、個々のブロックを独立させて暗号化していくのではなく、直前の暗号化されたブロックとこれから暗号化しようとするブロックの排他的論理和を取り、それをＤＥＳの入力とする方式である。この方法だと同じ内容のブロックを暗号化した時にでも、それまでに暗号化したブロックが異なれば暗号化した結果も異なることになる。
【００２２】
ＤＥＳ−ＭＡＣ（ＣＢＣ−ＭＡＣについてＡｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ４５５を参照）は、ＤＥＳにおけるＣＢＣモードを応用したものであり、最後に得られたブロックをデータストリーム全体の検証値に用いようとするものである。
【００２３】
ＤＥＳ−ＭＡＣの構成を図２１に示す。図の上部が伝送しようとするデータストリームであり、データストリームはそれぞれ６４ビットづつのブロックに分割される。ＩＶとはＩｎｉｔｉａｌ Ｖｅｃｔｏｒの略で乱数で生成された初期値である。分割されたブロックはＤＥＳ−ＣＢＣモードと同様に連鎖的にＤＥＳ暗号器を通していき、先頭にＩＶを、そして最後に得られたブロックを伝送しようとするデータストリームの検証値を付加して伝送される。受信した側ではこの処理と逆の処理を行って得られた検証値が、等しくなるかどうかを検証する。
【００２４】
しかし、このような処理方法は基本的に通信によってデータを伝送することを目的としているものであり、送信者は完全なデータを短時間、確実に保持することが前提となっていることから、完全な履歴の回収に適用しようとすると、問題を生じる。すなわち、履歴データは長期に渡って蓄積され、その間ユーザの恣意的な管理や、システムの事故などの危険に曝される可能性があるからである。
【００２５】
第一に上記の方法（ＤＥＳ−ＭＡＣ）ではデータブロックが連続して伝送されることを前提としている。すなわち、通常データの伝送にはさらに下位の層が存在し（ＴＣＰ／ＩＰ：トランスミッション・コントロール・プロトコル／インターネット・プロトコルではＴＣＰ層が相当する）、その層によってデータブロックの順番が保証されることになる。
【００２６】
しかしながら、利用履歴の場合には、ユーザの管理下に置いてしまうと、その時点で履歴の順序は保証されなくなってしまう。すなわち、ユーザはＩＣカードを自分の使用可能な複数台のコンピュータ（例えばデスクトップＰＣと、ラップトップＰＣなど）に接続して使用することが可能である。利用履歴がコンピュータ側に記録されることを考えると、利用履歴は複数のコンピュータに分散されてしまう。従って、複数台に分散された履歴はその時間的順序は失われてしまうことになる。
【００２７】
利用履歴の場合には時間的な順序が非常に重要な要素となる。すなわち、複数の連続した利用履歴から、後で利用量を計算する可能性があるからである。例えば、簡単な例では利用開始時刻と利用終了時刻との差から利用時間を計算したり、利用開始時の操作対象データ長と利用終了時の操作対象データ長からデータ長の差を計算し、それを利用量としたりするなどの場合である。
【００２８】
ＤＥＳ−ＭＡＣはこういった課題には本質的な解決法を与えていない。
【００２９】
さらに、利用履歴をユーザの管理下に置いた場合のもう一つの課題は、故意もしくは事故によって、それらの一部が失われてしまう可能性があるということである。ＤＥＳ−ＭＡＣの場合、その一部が失われてしまうと、検証が不可能になってしまう。ＤＥＳ−ＭＡＣでは送信者が通信の間だけ完全なデータを保持していることが前提なので、そのような場合は再送信を行えば済む。しかし、利用履歴の場合には、履歴が失われるということは本質的にデータが失われることであるので、復元は不可能である。ＤＥＳ−ＭＡＣの方式をそのまま使用すると、残ったデータの検証さえ行うことができなくなってしまう。
【００３０】
さらにまた、利用量課金を行うようなシステムにおいては、ユーザの手もとに残された履歴を回収することは必須である。履歴を回収しないと、ユーザの利用料金を計算できなかったり、あるいは、回収した利用料金を情報の提供者に分配できなかったりするという問題があるからである。
【００３１】
従って、ユーザの手もとに残された利用履歴を安全に回収しなければならない。そのためには、偽の回収命令などによって、回収が行われてしまうようなことが無いようにしなければならない。
【００３２】
従って、この発明の目的とするところは、利用履歴等を確実に回収するのに適した電子機器の制御技術を提供することにある。
【００３３】
さらに、この発明の他の目的は、データを保持する装置を外部から安全に制御する方法を提供することにある。
【００３４】
さらに、この発明の他の目的は、機能が停止中の電子機器を不正に停止開示できないようにすることにある。
【００３５】
【課題を解決するための手段】
この発明は、上記の課題を解決するために、具体的な構成では、保持するデータ量を減らすために、データを防御装置内に記録せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保持するようにした。そして、具体的な構成では、高速にデータの検証を行うことができるように、電子署名の代わりに一方向性関数によって検証を行うようにした。一般にＭＤ５を代表とするハッシュ関数はＲＳＡの暗号化処理に比べるとソフトウエアで実現した場合には３桁程度ハッシュ値の方が速いという結果が出ている。また、特に、履歴データの順序を復元可能とするために、履歴データに順序を復元可能な情報を付加した。さらに、具体的には、防御装置を安全に制御するために、防御装置が保持する検証値に対して正当者の署名を付与した値が必要な構成とした。これにより防御装置内の検証値が正当者に強制的に送られ、検証の実行を確保している。
【００３６】
さらに、この発明の構成について説明する。この発明によれば、上述の目的を達成するために、履歴保持装置に、データを保持するためのデータ記憶手段と、機能を停止する際のある一定の条件を保持するための停止条件保持手段と、該停止条件保持手段に保持された条件を満たした時に機能を停止し、外部から正当な命令が与えられるまでは機能を停止しつづけるための機能停止手段と、秘密鍵を保持するための秘密鍵保持手段と、データ保持手段に保持されたデータ群に該秘密鍵保持手段に保持された秘密鍵を用いて電子署名を施すための電子署名手段と、署名した電子署名を保持するための電子署名保持手段と、外部の正当者の公開鍵を保持するための正当公開鍵保持手段とを設け、上記機能停止手段が機能を復帰させるために受け付ける命令が、上記電子署名保持手段に保持された電子署名に対して外部の正当者が電子署名を施したものであって、機能停止手段が命令を受け取った時に該正当公開鍵保持手段に保持されている公開鍵で署名を検証し、さらに署名されている値が、電子署名保持手段に保持されている値と等しいかどうかを確認するようにしている。
【００３７】
この構成においては、履歴の正当性が検証されて初めて正当者の署名した命令が送付され、この正当な命令が検証されて初めて装置の停止状態が解除される。従って、正当な履歴が回収されないままでサービスが提供され続けるという不都合がない。換言すると、正当な履歴の回収が確保される。
【００３８】
また、この発明によれば、電子機器に、所定の条件が満たされたときに電子機器本体の少なくとも一部の機能を停止する機能停止手段と、所定のデータを外部に出力する手段と、上記所定のデータに署名を施して生成された署名付きデータを受信する手段と、上記署名付きデータについて署名を検証する署名検証手段と、上記署名検証手段によって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除する手段とを設けている。
【００３９】
この構成においては、データの正当性が確認されて初めて電子機器の使用が継続できる。従って正当なデータを確保することができる。
【００４０】
また、この発明は、その一部をコンピュータプログラム製品として実現することができる。
【００４１】
この発明の上述の側面およびこの発明の他の側面は特許請求の範囲に記載され、以下、実施例を用いて詳細に説明される。
【００４２】
【発明の実施の態様】
［履歴保持システム］
以下、この発明の実施例について説明する。まずこの発明が前提とする電子機器例えば所定の情報処理を行いその履歴を保持する情報処理システムについて説明する。このシステムは、暗号化されて流通しているプログラムや画像情報などのデジタル情報一般を、パソコンやワークステーションなどの情報処理装置上で利用し、その際の利用履歴をその情報処理装置に接続したＩＣカード（以下、トークンと呼ぶ）において、情報を復号するタイミングをとらえて記録し、その利用履歴をセンターが回収するというシステムである。もちろん広く情報処理を行う電子機器に適用できる。また、履歴データのセキュリティ確保以外にもこの発明を適用することができる。
【００４３】
図１は、この情報処理システムの全体的な構成を示す。図１において、利用者の環境にはパソコンやワークステーションなど、デジタル情報を利用するための情報処理装置１１があり、それには暗号化された情報を復号する（あるいは復号するための鍵を復号する）ため、およびそのタイミングを捕らえて利用履歴を記録するためのトークン１２が接続されている。トークン１２と情報処理装置１１の間の接続は、ＰＣカード（ＰＣＭＣＩＡ：パーソナル・コンピュータ・メモリ・カード・インターフェース・アソシエーション）インターフェース、シリアル、パラレル、赤外線など、情報を伝達できる手段であれば何でも用いることができる。情報処理装置１１の内部に実装するようにしてもよい。
【００４４】
ユーザの情報処理装置１１はセンター側の、ワークステーションあるいは大型計算機などの情報処理装置で構成される回収装置１３と必要に応じて接続される。接続の形態は、モデムと電話回線、あるいはイーサネットなどのネットワークインターフェースでよい。この接続は常時行われる訳ではなく、利用者の情報処理装置１１から利用履歴の回収が必要な時のみ行われれば十分である。
【００４５】
図２にユーザ側の情報処理装置１１の構成を示す。ユーザの情報処理装置１１は一般のパソコンやワークステーションで良い。トークン１２が接続されているところのみが異なる。情報処理装置１１は、制御部１４、情報保持部１５、履歴保持部１６および履歴送信部１７を実現する。このような構成は、例えばプログラムが記録された記録媒体１１ａを用いて当該プログラムをインストールすることにより実現できる。
【００４６】
制御部１４はトークン１２と通信しながら、以下のような処理を行う。
▲１▼情報保持部１５に格納されている暗号化された情報を読み出し、トークン１２へ渡して復号してもらい、復号された情報を実行あるいは処理する。
▲２▼復号データを受け取った際に同時にトークン１２から渡される利用履歴を受け取り、それを履歴保持部１６に格納する。
▲３▼ユーザからの指示を受けて、トークン１２に「検証値出力」の命令を出し、その結果である電子署名の施された検証値を履歴送信部１７に渡す。
【００４７】
情報保持部１５は利用者が利用するデータや情報、あるいは暗号化されたデータが格納されている。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。
【００４８】
履歴保持部１６は制御部１４を通じてトークン１２側から渡された履歴が格納される。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。履歴の具体的な構成については後述する。
【００４９】
履歴送信部１７は制御部１４からの命令を受けて、制御部１４から渡された検証値と共に履歴保持部１６に保持されている履歴を読み出して、センターの回収装置１３に送信する。実際にはモデムと電話回線、あるいはイーサネットなどのネットワークインターフェースなどで構成される。あるいは、ネットワークでなくともフロッピーディスクなどの装置へ一旦格納し、それをユーザが人手でセンターの回収装置１３に入力するようにしてもよい。
【００５０】
図３にユーザ側のトークン１２の構成を示す。トークン１２は物理的には一般のＭＰＵ、メモリ等から構成される。トークン１２はそれ自体が、メモリの内容を読み出したり破壊したりするなど、外部からの物理的な攻撃に耐えるように攻撃対抗容器内に収められる。攻撃対抗容器は周知の技術であるので（特許第１８６３５３号、特許第１８６０４６３号、特開平３−１００７５３号公報等）、ここでは説明を省略する。なお、どの程度の攻撃に耐えうるものを選ぶかはデータのセキュリティの程度に応じて変化する。攻撃態勢が弱いものでもよい場合もある。
【００５１】
トークン１２はユーザの情報処理装置１１に接続され、情報処理装置１１からの指示に従って一定の処理を行い、その結果を返す。トークン１２はユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、検証値出力部２２、トークン秘密鍵保持部２３、電子署名部２４等を有している。トークン１２の各構成部については後に詳述する。トークン１２は以下の機能を持つ。
【００５２】
▲１▼情報の復号機能と利用履歴の保持
（１）情報処理装置１１から暗号化データを受け取り、それをユーザ秘密鍵保持部１８に格納されている秘密鍵で復号し、復号データを情報処理装置１１に返す。
（２）復号処理を行うと同時に復号されたデータのヘッダを参照し、そこに記されている情報識別子を参照し、その識別子を利用履歴として情報処理装置１１に返す。
（３）さらに、利用履歴は検証値生成部２０にも渡され、検証値生成部２０は利用履歴とその時点で検証値保持部２１に保持している検証値とに対して計算を行い、その計算結果を検証値保持部２１に格納する。
【００５３】
▲２▼検証値の出力機能
情報処理装置１１からの出力要求を受けて、その時点で検証値保持部２１に保持している検証値に電子署名を施して返す。その後、検証値保持部２１内のデータを消去する。
【００５４】
以下、トークン１２の各構成部について説明する。
【００５５】
復号部１９は情報処理装置１１からの復号要求に答えて、渡された暗号化データを、ユーザ秘密鍵保持部１８に保持されているユーザ固有の秘密鍵を用いて復号処理を行い、その結果を復号データとして情報処理装置１１側へ返す。このとき、それと同時に復号したデータのヘッダを読み取り、そこに記されている情報識別子を利用履歴として情報処理装置１１側へ返すと共に、検証値生成部２０にも渡す（この例では利用履歴は、利用した情報の情報識別子を用いている）。
【００５６】
このように構成することで、ユーザは情報を利用する際には必ずトークン１２へのアクセスが必要となり、利用履歴を確実に記録することができるようになる。
【００５７】
ここで、情報処理装置１１側から渡される暗号データは、情報そのものが暗号化されたものでもよいし、あるいは暗号化された情報を復号するための鍵を暗号化したものでもよい。後者の場合には情報処理装置１１側で情報本体の復号処理がなされることになる。
【００５８】
ユーザ秘密鍵保持部１８は、ユーザ固有の秘密鍵を保持する。一般的には、トークン１２は予めトークン発行センターなどによって、ユーザごとの固有の鍵を封入した形でユーザに配布される。従って、このユーザ秘密鍵はユーザ自身も知ることができない。
【００５９】
検証値保持部２１は順次更新される一つの検証値のみを保持する。検証値は一般に１６バイトなど、固定の長さを持つ値である。従って、検証値が１６バイトであるならば、１６バイトのメモリだけで構成される。図４に検証値の構成例を示す。
【００６０】
検証値出力部２２は、情報処理装置１１側からの検証値の出力要求を受けて、その時点で検証値保持部２１に格納されている検証値を読み出し、それを情報処理装置１１側に返すという機能を持つ。その際、検証値出力部２２は電子署名部２４を呼び出して、検証値に対して電子署名を施す。
【００６１】
電子署名部２４はそのトークン専用の秘密鍵を保持するトークン秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。トークン秘密鍵保持部２３は電子署名を行う際に用いられる署名用の秘密鍵を保持する構成部である。これらの構成部にはＲＳＡ署名などの電子署名技術を用いることが可能であり、従来の技術であるのでここでは詳細な説明は省略する。
【００６２】
検証値生成部２０は復号部１９から利用履歴（ここでは情報識別子）を受け取ったら、検証値保持部２１に保持されている検証値を読み取り、利用履歴と検証値とから、以下のような計算を行って新しい検証値を計算する。
【００６３】
【数１】
Ｈ＝Ｈａｓｈ（Ｕｓａｇｅ＋Ｈｏｌｄ）
ここで、Ｈは新しい検証値、Ｈｏｌｄは現在の検証値、Ｕｓａｇｅは利用履歴、Ｈａｓｈ（）は一方向性関数を意味し、実際にはＭＤ５やＳＨＡ（ＳｅｃｕｒｅＨａｓｈ Ａｌｇｏｒｉｔｈｍ）などが用いられる。この演算における”＋”という演算は実際に数値として足し算を行ってもよいし、長さが同じであれば排他的論理和を取っても、あるいは、単に二つのデータを順に並べただけでもよい。いずれにしろ二つの値を合成したものであればよい。検証値生成部２０はこのように計算した新しい検証値を、検証値保持部２１に格納する（つまり、古い値を上書きする）。
【００６４】
検証値出力部２２は情報処理装置１１からの出力要求を受け、その時点で検証値保持部２１に保持している検証値を返してから、検証値保持部２１を予め決められた値に初期化するようにする。あるいは単純にクリアするようにしてもよい。
【００６５】
次にセンターの回収装置１３について説明する。回収装置１３の構成を図５に示す。図５において、回収装置１３は、履歴受信部２５、履歴保持部２６、履歴検証部２７、トークン公開鍵保持部２８、署名検証部２９等を有している。回収装置１３はユーザの情報処理装置１１から送られた履歴を履歴受信部２５によって受信し、その内容を履歴保持部２６に格納する。格納された利用履歴は履歴検証部２７によって読み取られ、履歴が正しいかどうかが検証され、その結果はセンター側の管理者に出力される。
【００６６】
一般的にはセンターはこの後、その履歴の内容に従って、情報の利用料金を計算し、その料金を利用者から徴収し、徴収した利用料金を情報の利用履歴の明細に従って、情報提供者に分配するという処理を行う。しかし、本発明の本質とは直接は関係無いのでここでは説明を省略する。
【００６７】
以下、回収装置１３の各構成部について説明する。
【００６８】
履歴受信部２５は情報処理装置１１から送られてくる履歴情報を受信する。実際には情報処理装置１１の履歴送信部１７（図２）と同様にモデムと電話回線あるいはイーサネットなどのネットワークインターフェース、あるはフロッピーディスク装置などの外部からの情報入力装置で構成される。履歴受信部２５によって受信された利用履歴は履歴保持部２６に格納される。
【００６９】
さらに、情報処理装置１１から送られてきた検証値が正当なものであるかどうかを検証するために、トークン公開鍵保持部２８と署名検証部２９を有している。
【００７０】
情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。もし、検証結果が偽であるという結果が出た場合にはその検証値は改竄あるいは偽造された可能性があるので、以下の処理は続行せず、管理者にその旨のメッセージを出力して処理を停止する。
【００７１】
署名が検証された場合は以下の処理が続けられる。
【００７２】
履歴保持部２６は履歴受信部２５から渡された利用履歴および検証結果を保持する。履歴保持部２６は実際にはメモリなどの記憶装置で構成される。
【００７３】
履歴検証部２７は履歴保持部２６に保持された履歴を以下のようにして検証する。
（１）送信された履歴の系列を、ｕｄ1，ｕｄ2，ｕｄ3．．．ｕｄnとする。
（２）履歴の最後に添付されている検証値を、ｈｕｄとする。
（３）検証値の初期値をｉｈｕｄとすると、以下の計算式に従って、計算した結果であるｈｕｄ’が、送られてきたｈｕｄと等しくなるかどうかを調べる。
【００７４】
【数２】
ｈｕｄ’＝Ｈａｓｈ（ｕｄn＋Ｈａｓｈ（ｕｄn-1＋．．．Ｈａｓｈ（ｕｄ2＋Ｈａｓｈ（ｕｄ1＋ｉｈｕｄ））．．．））
ｈｕｄ＝？ｈｕｄ’
（４）もし等しければ、改竄されていない、等しくなければ改竄されていると判断し、その結果を回収装置の管理者に通知する。
【００７５】
次に各部で処理される情報の形式について説明する。
【００７６】
図６にトークン１２で復号の対象となる暗号化された情報の形式を示す。（ａ）は情報そのものをユーザの秘密鍵で暗号化している場合である。（ｂ）は、最初に情報本体を暗号化するのに用いている秘密鍵をユーザ固有の秘密鍵で暗号化したものを復号し、その結果得られた情報固有の秘密鍵を用いて、情報本体の復号を行うという場合である。（ｂ）の場合には情報本体の復号はトークン１２ではなく、情報処理装置側で行ってもよい。また、ここでは慣用暗号を用いている例を説明しているが、これらは公開暗号を用いてもよいことは言うまでもない。
【００７７】
ここで、情報識別子とは、センターが情報を暗号化させて流通させる時に付与される情報固有の識別子である。情報識別子はセンターによって管理され（データベースを持つなどによって）、情報識別子を特定すると、その情報が誰によって作成されたものであるのか、などを特定できる。
【００７８】
図７には利用履歴の形式を示す。（ａ）は本情報処理システムにおける情報処理装置１１内に記録される利用履歴であり、利用した（トークンで復号した情報の）情報識別子の列である。（ｂ）は情報処理装置１１からセンターに送付される利用履歴であり、（ａ）の最後にトークンが保持する検証値、および検証値に対するトークンの署名が添付されているところのみが異なる。
【００７９】
個々の利用履歴は本情報処理システムでは利用した情報識別子のみで構成されているが、これは任意のデータ、例えば、利用した時刻、利用者の識別子、利用量、利用金額などが含まれていてもよい。すなわち種々の情報を履歴として残す場合（一般に履歴は種々の情報を残すのが一般的である）には個々の履歴が長くなるため、本発明が有効となる。
【００８０】
次に情報処理装置１１およびトークン１２における処理を図８から図１２を参照して説明する。図８は情報処理装置１１の制御部１４において、利用者から情報の利用要求が有った時の処理の流れである。図９は同じく制御部１４において利用者から利用履歴回収命令が有った時の処理である。図１０はトークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理である。図１１はトークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理である。図１２はトークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理である。
【００８１】
図８に示すように、利用者から情報利用の要求があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ１１）、暗号化されていなければ情報をそのまま処理する（Ｓ１５）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ１２）。このとき、トークン１２からエラーが返されたら「トークンの履歴が一杯です」というエラーメッセージを出して処理を終了する（Ｓ１３、Ｓ１６）。エラーが返されなければ、トークン１２から過閲された利用履歴をディスク等の記録装置に記録する（Ｓ１４）。そして対象情報を処理する（Ｓ１５）。
【００８２】
図９に示すように、利用者から利用履歴回収命令があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ２１）、暗号化されていなければ情報をそのまま処理する（Ｓ２４）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ２２）。そしてトークン１２から返された利用履歴をディスク等の記録装置に記録する（Ｓ２３）。こののち対象情報を処理する（Ｓ２４）。
【００８３】
図１０に示すように、トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時にはつぎのように処理が進む。まず、ユーザ秘密鍵保持部１８からユーザ秘密鍵Ｋｕが取り出される（Ｓ３１）。暗号化データをユーザ秘密鍵Ｋｕで復号して復号データを記憶する（Ｓ３２）。復号データのヘッダを参照して情報識別子を読み取り、この識別子を引数として検証値生成部２０を呼び出し検証値生成処理を実行させる（Ｓ３３、Ｓ３４、図１１参照）。この後復号データと識別子とを情報処理装置１１に返す（Ｓ３５）。
【００８４】
図１１に示すように、トークン１２の検証値生成部２０がトークン１２の復号部１９から呼び出されたときにはつぎのように処理が進む。まず、検証値保持部２１から検証値を取り出す（Ｓ４１）。情報識別子と検証値とについてハッシュ計算を行って、計算結果を新たな検証値として検証値保持部２１に記憶する（Ｓ４２、Ｓ４３）。
【００８５】
図１２に示すように、トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時にはつぎのように処理が進む。まず、検証値保持部２１に記憶されている検証値を読み出す（Ｓ５１）。こののち、検証値保持部２１の記憶内容を初期化する（Ｓ５２）。読み出した検証値を引数として電子署名部２４を呼び出し、検証値に署名を施す（Ｓ５３）。検証値の後に署名を付して出力する（Ｓ５４）。
【００８６】
以上でこの発明の実施例が前提とする情報処理システムの説明を終了する。
【００８７】
なお、特願平８−６２０７６号のユーザ認証装置および方法を、本発明と組み合せて使用した場合には、発行するアクセスチケットごとにべき乗剰余の計算における法ｎを変えるようにすることで、法ｎを情報識別子として用いることができる。すなわち、特願平８−６２０７６号のユーザ認証手法ではアクセスチケット（認証用補助情報）を外部から受け取り、このアクセスチケットとユーザ識別情報とを用いて証明、例えば暗号データの復号を行うようになっている。そして、このときに用いる法ｎを情報識別子として利用する。その場合には、法ｎはトークンの内部の復号装置で復号されてから取り出されるのではなく、復号対象の情報と共に外部から与えられることになる。
【００８８】
このように構成することで、トークン１２内部に用意しなければならない検証値保持部２１の容量を最小に押さえることができ、トークン１２の生産コストを低くすることが可能となる。
【００８９】
［実施例］
次に本発明の実施例について説明する。ここで述べる実施例はさきに説明した情報処理システムに対して、幾つかの機能を追加したものである。以下にその機能と効果について列挙する。
【００９０】
▲１▼トークン１２が検証値を出力して機能を停止し、センターからメッセージを受け取ると機能を回復する。
【００９１】
検証値を外部に出力する時やあるいは時計機能を用いて一定時間を経過した時などに、利用者に履歴の回収を促すためにトークン１２がその時点での検証値を出力して停止するようにする（あるいは自律的に停止して検証値を要求するようにしてもよい）。利用者がトークン１２の機能を回復させるためにはセンターに履歴と検証値を送信して、確認してもらい、センターから機能を回復させるためのメッセージを受け取るしかない。センターが発行する機能回復用のメッセージは、ユーザから送られた検証値にセンターが電子署名を施したものとする。
【００９２】
▲２▼履歴としてその利用履歴を処理した時点での検証値も出力する。
【００９３】
利用履歴の内容を情報識別子だけではなく、その履歴を生成した時点での検証値も含ませる。これによって、個々の履歴の連続性を後から調べることが可能になり、情報処理装置側での履歴の（順序の）管理を厳密に行わなくても良いようにする。
【００９４】
▲３▼センター側で古い検証値を保持する。
【００９５】
さきの情報処理システムでは、利用者からの出力要求によって、トークン内部の検証値は初期化されていた。しかしながら、センターの回収装置側で利用者の前回の検証値を保持することによって、その機能を不要にすることができる。
【００９６】
図１３に本実施例におけるトークン１２の構成を示す。なお、図１３において図３に対応する箇所には対応する符号を付して詳細な説明を省略する。この図において、トークン１２は、ユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、トークン秘密鍵保持部２３、電子署名部２４、制御部３０、履歴生成部３１、計数部３２、センター公開鍵保持部３３、署名検証部３４等を有している。なお、必要に応じて時計部３５を設けてもよい。
【００９７】
本実施例では情報処理装置１１との通信はすべて制御部３０を介して行われるように構成され、制御部３０は情報処理装置１１からの要求に対し適切に他の処理部を呼出して処理を行う。
【００９８】
制御部３０はその内部にトークン１２の動作状態を保持しており、動作状態には通常モードと停止モードの二つのモードがある。通常モードにおいてはトークン１２は情報処理装置１１からの復号要求に対して、第１の実施例で述べたように復号処理を行い、その結果を返すという処理を行う。一方、停止モードにおいては復号要求の処理は受け付けない。停止モードにおいては基本的には機能再開要求（センター署名付き検証値）のみを受け付け、その要求が正当である場合には停止モードを解除し、通常モードへ移行するという処理を行う（実際にはそれ以外にもその時点で検証値保持部２１に保持している検証値に署名した検証値を出力するという処理も受け付けるようにしてもよい）。
【００９９】
通常モードから停止モードへの移行は、例えば復号処理を行った回数などによる。図１３の計数部３２は復号処理を行った回数を保持している。例えば、その回数が予め定められた回数（例えば１００回など）を超えたら、「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１００】
構成として時計を有する場合には、制御部３０内部に保持された前回の停止時刻の情報に基づいて行うようにしてもよい。すなわち、制御部は情報処理装置からの要求があったとき、制御部内に保持された前回停止時刻と現在の時刻を比較し、予め決められた時間（例えば一か月、など）が経過していた場合には「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１０１】
つぎにトークン１２の制御部３０の処理を図１４〜図１６を参照して詳細に説明する。なお、図１４〜図１６において点線で示してある箇所は制御部３０の処理ではなく、関連する構成部の処理であることを意味する。
【０１０２】
図１４において、情報処理装置１１からトークン１２の制御部３０に復号要求、検証値出力要求および機能再開要求のいずれかが入力される。まず、制御部３０のモードが停止モードかどうかが判別される（Ｓ６１）。停止モードでないときには計数部３２の計数値が読み取られ、この計数値が基準値、例えば１００を越えたかどうかが判別される（Ｓ６２、Ｓ６３）。１００を越えていない場合には図１６のノードＢに進み、復号処理等を行う。１００を越えている場合には署名付き検証値を出力する。すなわち、検証値保持部２１の値を読み出し、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ６４、Ｓ６５）。こののち、署名付き検証値と「停止モードへ移行」というメッセージを情報処理装置１１に返す（Ｓ６６）。そして計数部３２の計数値をクリアして停止モードに移行する（Ｓ６７、Ｓ６８）。
【０１０３】
ステップＳ６１において、制御部３０が停止モードの場合には、受け取った要求が復号要求か、検証値出力要求か、機能再開要求かが判別される（Ｓ６９、Ｓ７０、Ｓ７１）。要求が復号要求の場合には情報処理装置１１に「現在は停止モードである」というメッセージを返し、処理を終了する（Ｓ７２）。要求が検証値出力要求の場合には検証値保持部２１の検証値を読み取り、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ７３、Ｓ７４）。こののち、署名付き検証値を情報処理装置１１に返し処理を終了する（Ｓ７５）。機能再開要求のときには図１５のノードＡの機能再開処理に進む。受け取った要求が復号要求、検証値出力要求、機能再開要求のいずれでもない場合には情報処理装置１１にエラーを返して処理を終了する（Ｓ７６）。
【０１０４】
図１５は機能再開処理を示す。図１５において、まず、受け取ったセンター署名付き検証値を署名検証部２４に渡して署名の正当性を検証する（Ｓ７７）。署名が正しければ、渡された検証値と、検証値保持部２１の検証値とを比較し、双方が一致するかどうかを検査する（Ｓ７８〜Ｓ８０）。一致すれば制御部のモードを停止モードから通常モードに移行させ、「機能再開」のメッセージを情報処理装置１１に返す（Ｓ８１、Ｓ８２）。ステップＳ７８において署名が正しくない場合には、「署名が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８３）。ステップＳ８０において検証値が一致しない場合には「検証値が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８４）。
【０１０５】
図１６は計数値が閾値例えば１００を上回っていない場合の処理を示す。図１６において、まず要求が復号要求かどうかが検査される（Ｓ８５）。復号要求の場合には渡されたデータを復号部１９に送る（Ｓ８８）。復号部１９は復号を行う（Ｓ８９〜Ｓ９３）。また要求が復号要求でない場合には検証値要求かどうかが判別される（Ｓ８６）。検証値要求である場合には図１４のノードＣに進み、検証値出力処理を行う。ステップＳ８６において検証値出力要求でもない場合にはエラーを情報処理装置１１に返して処理を終了する（Ｓ８７）。
【０１０６】
以上でトークン１２の制御部３０の処理の説明を終える。
【０１０７】
なお、この例では、情報処理装置１１側から検証値要求が有った時にも停止モードへ移行するようにしているけれども（図１６のステップＳ８６から図１４のノードＣへ移行）、そうしなくても構わない。例えば通常モードにおける検証値要求に対しては、検証値を更新して単にその時点で保持している検証値に署名した値を返すようにしてもよい（このメリットについては本実施例の説明の最後で述べる）。
【０１０８】
復号部１９、ユーザ秘密鍵保持部１８は第１の実施例と同様の機能を有する。
【０１０９】
履歴生成部３１は図１６でも示したように復号部１９から渡された情報識別子と現在の検証値の三つの組を生成し、それを利用履歴として制御部３０に渡すという処理を行う。
【０１１０】
検証値生成部２０は履歴生成部３１から渡された履歴ｕｄに対し、
【０１１１】
【数３】
Ｈｕ＝Ｈａｓｈ（ｕｄ）
なるハッシュ値を計算し、それを検証値保持部２１に格納するという処理を行い、検証値保持部２１はその時点での検証値を保持する。
【０１１２】
電子署名部２４は第１の実施例と同様に、そのトークン専用の秘密鍵を保持する秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。本実施例ではさらに、署名検証部３４が設けられ、センター公開鍵保持部３３に保持されたセンターの公開鍵を用いて渡された署名がセンターの署名であるかどうかを検証するという処理を行う。これらの構成部には基本的にはＲＳＡ署名などの電子署名技術を用いることが可能であり、周知の技術であるのでここでは詳細な説明は省略する。
【０１１３】
本実施例における情報処理装置１１の構成を図１７に示す。図１７において図２と対応する箇所には対応する符号を付す。この図において、基本的にはさきの情報処理システムのものとほぼ同じ構成であるが、本実施例の情報処理装置１１ではある時点でトークンが停止モードに入ってしまうので、それを再開させるためにはセンターに履歴を送信し、それに対する再開メッセージを送ってもらわねばならない。そこで、センターからの署名付きの検証値を受け取る署名付き検証値受信部３６があるところが異なる。また、履歴保持部１６に保持される履歴の構成が異なっている。
【０１１４】
図１８に本実施例におけるセンターの回収装置１３の構成を示す。図１８において図５と対応する箇所には対応する符号を付す。この図において、構成としては第１の実施例のものに比べると、履歴の正当性が検証された場合には情報処理装置１１にセンターの署名付き検証値を送らねばならないので、それを行うための構成部、すなわちセンター秘密鍵保持部３７、電子署名部３８、署名付き検証値送信部３９が増設されている。また、情報処理装置１１側から送られる利用履歴の構成が異なっているので、当然回収センターで処理される履歴も異なる。
【０１１５】
図１９に各部で保持される利用履歴の構成を示す。
（ａ）は情報処理装置１１の履歴保持部１６に記録される利用履歴である。個々の履歴の内容は（ｃ）に示されたような情報識別子とその時点でトークンに保持されていた検証値のペアの構成となっている。
【０１１６】
情報処理装置１１からセンターに履歴を送付する際には、その履歴の列の最後にトークン１２の署名の付いた検証値が付与される（ｂ）。署名付き検証値はトークン１２が機能を停止した際に出力されるものであり、その時点での検証値にトークン１２が電子署名を施したものである（ｄ）。
【０１１７】
センターは履歴の検証のために（ｄ）の署名付き検証値を用いる。そして検証の結果、正当なものであると判断されると、トークン１２の機能を再開させるためのメッセージとして最後に添付された検証値にセンターが電子署名を施した値を情報処理装置１１に送る。それが（ｅ）である。
【０１１８】
次に回収装置１３の処理について説明する。情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。
【０１１９】
履歴の受信が終わると履歴検証部２７が動作しはじめる。履歴検証部２７は今受信した履歴を参照し、それに付随している署名の検証結果を参照する。署名の検証結果が正当でない場合には、これ以降の処理は行われない。履歴に付随している検証結果が正当であれば、さらに履歴の内容が正当であるかどうかを検証する。
【０１２０】
履歴の内容の検証処理は以下のように行われる。
（１）送られてきた履歴の列が以下のようなものであるとする。
（ｉｄ1，ｈｕ0），（ｉｄ2，ｈｕ1），（ｉｄ3，ｈｕ2），．．．，（ｉｄn，ｈｕn-1），ｓｉｇｎ（ｈｕn）
ただし、ここでｉｄは情報識別子、ｈｕはその履歴が生成された時点での検証値、ｓｉｇｎ（）はトークンのサインであるとする。
（２）トークンが前回送ってきた際の検証値を履歴保持部の中から捜し出し、それをＨｕｏｌｄとする。
（３）送られてきた利用履歴の最初の履歴（ＩＤ1，ｈｕ0）の中から検証値ｈｕ0を取り出し、それがＨｕｏｌｄと等しいかどうかを確かめる。
（４）次にＨａｓｈ（ｉｄ1，ｈｕ0）を計算し、それがｈｕ1になるかどうかを確かめる。
（５）以下同様にして最後の検証値ｈｕnまで確かめる。
（６）すべての検査にパスしたら利用履歴は正当なものであると判断する。
【０１２１】
検証処理の結果、履歴が正しいものと判断された場合のみ、最後の検証値ｈｕｎが電子署名部に送られ、センターの秘密鍵で電子署名が施される。そして、センターの署名付きの検証値が履歴を送付してきた情報処理装置に送り返される。
【０１２２】
以上のように構成することで、ある時点でトークンが機能を停止するため、その情報処理装置の利用者はトークンの機能を再開させるためには正当な履歴をセンターに送付しなければならなくなる。従って、履歴の回収を利用者に促すことが可能になる。
【０１２３】
また、センター側に最後の検証値が記録されているため、トークンから送付された正しい履歴が何らかの理由で一部が破壊されていた場合でも、単に検証が成功しなかっただけであるので、センター側の保持データは何も変化しない。従って、その場合にはトークンが履歴を再送付すれば検証は正常に行われることになる。
【０１２４】
また本実施例において、トークンが自律的に検証値を出力するように構成することで、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証可能なようにすることができる。
【０１２５】
すなわち、前述したように利用者が検証値を要求した時だけでなく、トークンの負荷が低いときにトークンが自律的にその時点で保持している検証値に署名したものを出力することによって、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証が可能になる。
【０１２６】
この場合には、センターへ送付される利用履歴は例えば図２０のような構成になる。この時、何らかの事故によって情報処理装置側で履歴２５が失われてしまったとする。
【０１２７】
先に示したような検証値を最後にしか持たないような利用履歴の場合には履歴２６以降は検証可能となるが、履歴１から履歴２４については内容が失われていないにもかかわらずそれが正当であることは検証できない。
【０１２８】
それが途中に署名付の検証値を挿入することによって、この例の場合には履歴２５が失われた場合には履歴２４のみが検証不可能となるだけで、残りの履歴については検証可能となるのである。つまり、履歴１から履歴１０までは署名付き検証値１によって、履歴１１から履歴２３までは署名付き検証値２によって、履歴２５から履歴３６までは署名付き検証値３によって、履歴３７から履歴５７までは署名付き検証値４によって、それぞれが検証可能となるからである。
【０１２９】
このように適当な間隔で署名付きの検証値を履歴中に挿入することで履歴の一部が失われた場合にでも残りの履歴の大部分について検証を可能とすることができるようになるのである。
【０１３０】
これを実現するためにはトークン内部の制御部において負荷が低いかどうかを判定する装置を設け、トークンの負荷が低い場合には自律的に署名付き検証値を生成しておくようにすればよい。
【０１３１】
また、トークンが自律的に行わなくても情報処理装置すなわち利用者からの要求によって署名付き検証値を出力するように構成すればよい。そのためには図１６のノードＣを図１４のノードＣ（ステップＳ６４）に分岐させるのではなく、検証値を更新して署名付き検証値を生成しそれを情報処理装置１１に返すように処理を変更すればよい。
【０１３２】
また、トークンに時計機能を持たせることによって、利用履歴として時刻の情報を取ることができるようになる。それによって、回収センター側は単にどの情報を利用したのかという履歴だけではなく、利用した時刻も知ることができるようになる。時計部は通常の時計機能であり、年月日および時刻を保持し、要求に従って現在の時刻を出力する機能を有するだけでよい。履歴に時刻を含ませるには、前述してきた情報識別子に時刻の情報も結合するだけでよい。また、時計機能を有すると、前述した停止モードへの移行の条件として、「前回に停止した時から経過した時間」にすることが可能になる。
【０１３３】
さらにまた、本実施例では外部に出力する履歴にその時点で保持していた検証値を付与するように構成しているが、これはトークン内部にカウンタ部を設け、履歴を出力するごとにカウンタの値をカウントしていくようにし、履歴を外部に出力する際に検証値ではなく、カウンタの値を出力するようにしてもよい。その場合は、これまでの説明中のハッシュ関数の入力となる部分が、利用履歴およびその時点で保持しているカウンタの値となる。
【０１３４】
以上説明したように、この実施例によれば、保持するデータ量を減らすために、データを防御装置内に保管せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保管するようにしている。したがって防御装置の記憶容量や必要処理能力を抑えることができる。検証値は署名を付して外部に送られるので改竄を防止でき、データの検証を確実に行える。また、データの順序を復元可能とするために、データに順序復元用の情報を付加することにより、分散して保管されているデータであってもその順序を復元して、検証を容易にすることができる。さらに、防御装置が保持するデータに対して正当者の署名を付与した値を、防御装置が受け取ったときに、関連する処理を継続実行できるようにしているので、継続実行するには、防御装置内に保持したデータを正当者に送り署名を受けた後返送してもらわなければならない。したがって、正当者には必然的に検証対象のデータが送られてきて、検証対象のデータを確実に回収することができる。また、署名付き検証値を頻繁に出力するようにすればデータの一部が破損等しても他の多くのデータについては確実に検証を行うことができる。
【０１３５】
【発明の効果】
以上説明したように、この発明によれば、例えば、防御装置が保持するデータに対して正当者の署名を付与した値を、防御装置が受け取ったときに、関連する処理を継続実行できるようにしているので、継続実行するには、防御装置内に保持したデータを正当者に送り署名を受けた後返送してもらわなければならない。したがって、正当者には必然的に検証対象のデータが送られてきて、検証対象のデータを確実に回収することができる。この発明によれば、署名付きデータの署名の正当性が検証されたときに、停止中の機能を停止解除するので、不正な停止解除要求に対処することができる。
【図面の簡単な説明】
【図１】 この発明の実施例が前提とする情報処理システムを全体として示すブロック図である。
【図２】 図１の情報処理装置１１の構成を示すブロック図である。
【図３】 図１のトークン１２の構成を示すブロック図である。
【図４】 図３の検証値保持部２１を説明する図である。
【図５】 図１の回収装置１３の構成を示すブロック図である。
【図６】 トークン１２において復号される情報を説明する図である。
【図７】 利用履歴の構成を説明する図である。
【図８】 利用者から情報の利用要求が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図９】 利用者から利用履歴回収命令が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図１０】 トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理を説明するフローチャートである。
【図１１】 トークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理を説明するフローチャートである。
【図１２】 トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理を説明するフローチャートである。
【図１３】 この発明の実施例に用いるトークン１２の構成を示すブロック図である。
【図１４】 図１３のトークン１２の処理を説明するフローチャートである。
【図１５】 図１３のトークン１２の処理を説明するフローチャートである。
【図１６】 図１３のトークン１２の処理を説明するフローチャートである。
【図１７】 上述実施例の情報処理装置１１において実現されている機能ブロックを示すブロック図である。
【図１８】 上述実施例の回収装置１３の構成を示すブロック図である。
【図１９】 上述実施例の利用履歴の構成を説明する図である。
【図２０】 上述実施例の利用履歴の他の構成を説明する図である。
【図２１】 関連技術を説明する図である。
【符号の説明】
１１ 情報処理装置
１２ トークン
１３ 回収装置
１４ 情報処理装置１１の制御部
１５ 情報処理装置１１の情報保持部
１６ 情報処理装置１１の履歴保持部
１７ 情報処理装置１１の履歴送信部
１８ トークン１２のユーザ秘密鍵保持部
１９ トークン１２の復号部
２０ トークン１２の検証値生成部
２１ トークン１２の検証値保持部
２２ トークン１２の検証値出力部
２３ トークン１２のトークン秘密鍵保持部
２４ トークン１２の電子署名部
２５ 回収装置１３の履歴受信部
２６ 回収装置１３の履歴保持部
２７ 回収装置１３の履歴検証部
２８ 回収装置１３のトークン公開鍵保持部
２９ 回収装置１３の署名検証部
【発明の属する技術分野】
この発明はデータを検証する技術に関し、とくに連続する大量のデータ群、例えば利用履歴のようなデータを安全に伝送あるいは保持しなければならないような情報処理装置一般に用いるのに適したデータ検証技術に関する。
【０００２】
【従来の技術】
昨今のデジタル情報処理技術の発達や、情報ハイウェイ構想などにより、あらゆる情報がデジタル化され、ネットワークを通じて配付・流通される時代が到来しようとしている。すでにインターネットやパソコン通信、あるいはＣＤ−ＲＯＭという形態で、文字情報はもとより、画像、動画、音声、プログラムなどの様々な情報が配付・流通しはじめている。
【０００３】
しかしながら、そのような文字、画像、動画、音声、プログラムなどの様々なデジタル情報は物理的な物とは異なって実体を持たないため、利用しなければ価値がない、複写が容易で、かつ低コストで可能である、などの特徴を持つ。しかし、現在はその所有に対して対価を支払っているため、一旦、ある人に所有された情報が複写されるということを制限している。本来、デジタル情報の最も優れた特徴であるはずの複写容易性やそのコストの低さを無理やりに封じ込めていることになる。
【０００４】
これを解決するために、最近ではプログラムを代表とするデジタル情報を暗号化して自由に流通させ、利用する際には代金を支払って、デジタル情報を利用するための復号鍵を受取り、情報を復号化して利用するようなシステムも登場してきている。あるいは、情報は利用しなければ価値がないという観点から、特公平６−９５３０２号公報におけるソフトウェアサービスシステムや、特開平７−２１２７６号公報の情報利用量測定装置のような、情報の利用に対して課金するような技術が提案されている。
【０００５】
これらの技術によって、パーソナルコンピュータやワークステーションなどの情報処理装置上では、ユーザはプログラムを代表とするソフトウェアを利用する際にはソフトウェアを購入して利用するのではなく、無料または非常に安価に入手し、利用した時に利用に応じて利用料金という形で、例えば一回利用したから幾ら、というように課金がなされるようになった。
【０００６】
情報の利用に対して課金を行うためには、その利用の頻度に応じて個々の利用者から利用料金を回収しなければならない。あるいは場合によっては、一括回収した利用料金を情報を提供した側にその利用頻度に応じて分配しなければならない。そのためには、利用者の環境における利用の履歴を安全に記録し、そして安全に回収する必要がある。
【０００７】
しかし、特開平７−２１２７６号公報では利用履歴を記録する機能として、利用量メーターは存在するが、実際にそこに記録された利用量をどのように回収するかについては触れられていない。
【０００８】
そのための方法としては、利用履歴を利用者が利用する情報処理装置の管理する記憶装置、例えばハードディスク装置などではなく、それとは独立した安全な装置に記録する方法がある。例えば、特公平６−９５３０２号公報ではＩＣカード内に利用の履歴を書き込むようにしている。
【０００９】
また、特開平３−２５６０５号公報の課金情報送出方式や特開平６−１８０７６２号公報の課金情報収集システムではネットワークを通じて課金情報を回収するようにしている。
【００１０】
【発明が解決しようとする課題】
ＩＣカードのような安全な装置に書き込まれた履歴を回収するためには、ネットワークで回収するか、もしくは、その装置から直接に正当な権限を持った回収者が直接的に回収する方法がある。
【００１１】
しかしながら、ネットワークを通じて履歴を回収する方式では、課金情報の安全性すなわち、課金情報が途中で改竄されたり、あるいは利用者が不正な課金情報を作成してそれを送ったりという安全性の面についてはまったく考慮されていなかった。従って、企業内のような一定の信頼のおけるネットワーク内においては適用可能であったが、不特定多数の個人が参加するようなインターネットには、安全性の面から適用できないという問題があった。
【００１２】
従って、安全にＩＣカードのような装置内の履歴を回収するためには、その装置から直接に正当な権限を持った回収者が直接的に回収するしか方法がなかったのである。
【００１３】
しかし、最近になり研究の進んでいる暗号技術、特に電子署名技術を用いると、上記の問題を解決することが可能である。すなわち、安全装置に固有の秘密鍵を封入し、安全装置からデータを取り出す際には必ず署名を施す様にすればよい。これによって、データが正しいことが、データに付随している電子署名を確認することで、後から確認できるようになる。
【００１４】
電子署名はＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号を用いる手法が広く知られている。しかし、ＲＳＡ暗号による署名、あるいは、他の電子署名には、一般に非常に多くの計算量を必要とし、一回の処理に多大な時間がかかるのが普通である。従って、連続する多量のデータに対して署名を施さなければならない場合や、あるいは署名の処理を計算能力が低い計算機上で処理する場合には、非常に大きな問題となる。
【００１５】
利用履歴を記録するような安全装置としてＩＣカードのような装置を用いる場合に、一般にそのようなＩＣカードに搭載可能なＣＰＵの計算能力は低いことが多く、多量の計算をさせると非常に時間がかかるという問題があった。あるいは、計算時間を速くするために、計算能力を高くしようとすると非常に高いコストを要するという課題があった。
【００１６】
また、利用の履歴データは一般に長大になるため、ＩＣカードのような小さな装置にすべての履歴データを記録しようとすると記録容量が問題になるという課題もあった。
【００１７】
なお、元々ＲＳＡ暗号を始めとする現代の暗号技術の安全性は計算量に基礎を置いており、計算機の能力が伸びるとそれに伴って署名や暗号に用いられる鍵長が大きくされるようになっている。従って、将来的に計算機の能力が上がれば解決するという問題ではなく、その時代における最大の処理能力を持つ計算機に比べて低い処理能力の計算機しか使えないような機器（例えば、個人が用いるトークンなど）を用いる場合には将来に渡っても常にこの問題は本質的な課題となる。
【００１８】
この発明はこのような事情に鑑みてなされたものであり、その目的とするところは、計算能力の低い装置に置いても、高速にデータを検証可能なデータを生成できる方法を提供することにある。
【００１９】
すなわち、利用履歴全体をＩＣカード内に保持するのではなく、利用履歴から得られる検証値のみをＩＣカード内に保持し、利用履歴の本体はユーザの管理する情報処理装置（パソコンなど）側に保持させようとするものである。
【００２０】
検証値の観点から従来の技術を参照すると、データ通信に使用される技術であるＤＥＳ−ＭＡＣと呼ばれる技術がある。ＭＡＣとはＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅの略であり、メッセージが完全である（改竄されていない）ことを示す一定の長さを持ったコードである。オリジナルのメッセージに添付されて用いられたりする。データ通信は途中でエラーが発生することは致命的であるので、途中でデータが変わってしまったことを検知できるような構成になっている。
【００２１】
ここで、ＤＥＳとはＤａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄの略で６４ビットを一つのブロックとするブロック暗号のアルゴリズムである（Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ２６５）。ＣＢＣ（ＣｙｐｈｅｒＢｌｏｃｋ Ｃｈａｉｎ）モード（Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ１９３， ＪＩＳ−Ｘ５０５１）とはＤＥＳを代表とするブロック暗号の使い方の一種であり、個々のブロックを独立させて暗号化していくのではなく、直前の暗号化されたブロックとこれから暗号化しようとするブロックの排他的論理和を取り、それをＤＥＳの入力とする方式である。この方法だと同じ内容のブロックを暗号化した時にでも、それまでに暗号化したブロックが異なれば暗号化した結果も異なることになる。
【００２２】
ＤＥＳ−ＭＡＣ（ＣＢＣ−ＭＡＣについてＡｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ ｐｐ４５５を参照）は、ＤＥＳにおけるＣＢＣモードを応用したものであり、最後に得られたブロックをデータストリーム全体の検証値に用いようとするものである。
【００２３】
ＤＥＳ−ＭＡＣの構成を図２１に示す。図の上部が伝送しようとするデータストリームであり、データストリームはそれぞれ６４ビットづつのブロックに分割される。ＩＶとはＩｎｉｔｉａｌ Ｖｅｃｔｏｒの略で乱数で生成された初期値である。分割されたブロックはＤＥＳ−ＣＢＣモードと同様に連鎖的にＤＥＳ暗号器を通していき、先頭にＩＶを、そして最後に得られたブロックを伝送しようとするデータストリームの検証値を付加して伝送される。受信した側ではこの処理と逆の処理を行って得られた検証値が、等しくなるかどうかを検証する。
【００２４】
しかし、このような処理方法は基本的に通信によってデータを伝送することを目的としているものであり、送信者は完全なデータを短時間、確実に保持することが前提となっていることから、完全な履歴の回収に適用しようとすると、問題を生じる。すなわち、履歴データは長期に渡って蓄積され、その間ユーザの恣意的な管理や、システムの事故などの危険に曝される可能性があるからである。
【００２５】
第一に上記の方法（ＤＥＳ−ＭＡＣ）ではデータブロックが連続して伝送されることを前提としている。すなわち、通常データの伝送にはさらに下位の層が存在し（ＴＣＰ／ＩＰ：トランスミッション・コントロール・プロトコル／インターネット・プロトコルではＴＣＰ層が相当する）、その層によってデータブロックの順番が保証されることになる。
【００２６】
しかしながら、利用履歴の場合には、ユーザの管理下に置いてしまうと、その時点で履歴の順序は保証されなくなってしまう。すなわち、ユーザはＩＣカードを自分の使用可能な複数台のコンピュータ（例えばデスクトップＰＣと、ラップトップＰＣなど）に接続して使用することが可能である。利用履歴がコンピュータ側に記録されることを考えると、利用履歴は複数のコンピュータに分散されてしまう。従って、複数台に分散された履歴はその時間的順序は失われてしまうことになる。
【００２７】
利用履歴の場合には時間的な順序が非常に重要な要素となる。すなわち、複数の連続した利用履歴から、後で利用量を計算する可能性があるからである。例えば、簡単な例では利用開始時刻と利用終了時刻との差から利用時間を計算したり、利用開始時の操作対象データ長と利用終了時の操作対象データ長からデータ長の差を計算し、それを利用量としたりするなどの場合である。
【００２８】
ＤＥＳ−ＭＡＣはこういった課題には本質的な解決法を与えていない。
【００２９】
さらに、利用履歴をユーザの管理下に置いた場合のもう一つの課題は、故意もしくは事故によって、それらの一部が失われてしまう可能性があるということである。ＤＥＳ−ＭＡＣの場合、その一部が失われてしまうと、検証が不可能になってしまう。ＤＥＳ−ＭＡＣでは送信者が通信の間だけ完全なデータを保持していることが前提なので、そのような場合は再送信を行えば済む。しかし、利用履歴の場合には、履歴が失われるということは本質的にデータが失われることであるので、復元は不可能である。ＤＥＳ−ＭＡＣの方式をそのまま使用すると、残ったデータの検証さえ行うことができなくなってしまう。
【００３０】
さらにまた、利用量課金を行うようなシステムにおいては、ユーザの手もとに残された履歴を回収することは必須である。履歴を回収しないと、ユーザの利用料金を計算できなかったり、あるいは、回収した利用料金を情報の提供者に分配できなかったりするという問題があるからである。
【００３１】
従って、ユーザの手もとに残された利用履歴を安全に回収しなければならない。そのためには、偽の回収命令などによって、回収が行われてしまうようなことが無いようにしなければならない。
【００３２】
従って、この発明の目的とするところは、利用履歴等を確実に回収するのに適した電子機器の制御技術を提供することにある。
【００３３】
さらに、この発明の他の目的は、データを保持する装置を外部から安全に制御する方法を提供することにある。
【００３４】
さらに、この発明の他の目的は、機能が停止中の電子機器を不正に停止開示できないようにすることにある。
【００３５】
【課題を解決するための手段】
この発明は、上記の課題を解決するために、具体的な構成では、保持するデータ量を減らすために、データを防御装置内に記録せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保持するようにした。そして、具体的な構成では、高速にデータの検証を行うことができるように、電子署名の代わりに一方向性関数によって検証を行うようにした。一般にＭＤ５を代表とするハッシュ関数はＲＳＡの暗号化処理に比べるとソフトウエアで実現した場合には３桁程度ハッシュ値の方が速いという結果が出ている。また、特に、履歴データの順序を復元可能とするために、履歴データに順序を復元可能な情報を付加した。さらに、具体的には、防御装置を安全に制御するために、防御装置が保持する検証値に対して正当者の署名を付与した値が必要な構成とした。これにより防御装置内の検証値が正当者に強制的に送られ、検証の実行を確保している。
【００３６】
さらに、この発明の構成について説明する。この発明によれば、上述の目的を達成するために、履歴保持装置に、データを保持するためのデータ記憶手段と、機能を停止する際のある一定の条件を保持するための停止条件保持手段と、該停止条件保持手段に保持された条件を満たした時に機能を停止し、外部から正当な命令が与えられるまでは機能を停止しつづけるための機能停止手段と、秘密鍵を保持するための秘密鍵保持手段と、データ保持手段に保持されたデータ群に該秘密鍵保持手段に保持された秘密鍵を用いて電子署名を施すための電子署名手段と、署名した電子署名を保持するための電子署名保持手段と、外部の正当者の公開鍵を保持するための正当公開鍵保持手段とを設け、上記機能停止手段が機能を復帰させるために受け付ける命令が、上記電子署名保持手段に保持された電子署名に対して外部の正当者が電子署名を施したものであって、機能停止手段が命令を受け取った時に該正当公開鍵保持手段に保持されている公開鍵で署名を検証し、さらに署名されている値が、電子署名保持手段に保持されている値と等しいかどうかを確認するようにしている。
【００３７】
この構成においては、履歴の正当性が検証されて初めて正当者の署名した命令が送付され、この正当な命令が検証されて初めて装置の停止状態が解除される。従って、正当な履歴が回収されないままでサービスが提供され続けるという不都合がない。換言すると、正当な履歴の回収が確保される。
【００３８】
また、この発明によれば、電子機器に、所定の条件が満たされたときに電子機器本体の少なくとも一部の機能を停止する機能停止手段と、所定のデータを外部に出力する手段と、上記所定のデータに署名を施して生成された署名付きデータを受信する手段と、上記署名付きデータについて署名を検証する署名検証手段と、上記署名検証手段によって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除する手段とを設けている。
【００３９】
この構成においては、データの正当性が確認されて初めて電子機器の使用が継続できる。従って正当なデータを確保することができる。
【００４０】
また、この発明は、その一部をコンピュータプログラム製品として実現することができる。
【００４１】
この発明の上述の側面およびこの発明の他の側面は特許請求の範囲に記載され、以下、実施例を用いて詳細に説明される。
【００４２】
【発明の実施の態様】
［履歴保持システム］
以下、この発明の実施例について説明する。まずこの発明が前提とする電子機器例えば所定の情報処理を行いその履歴を保持する情報処理システムについて説明する。このシステムは、暗号化されて流通しているプログラムや画像情報などのデジタル情報一般を、パソコンやワークステーションなどの情報処理装置上で利用し、その際の利用履歴をその情報処理装置に接続したＩＣカード（以下、トークンと呼ぶ）において、情報を復号するタイミングをとらえて記録し、その利用履歴をセンターが回収するというシステムである。もちろん広く情報処理を行う電子機器に適用できる。また、履歴データのセキュリティ確保以外にもこの発明を適用することができる。
【００４３】
図１は、この情報処理システムの全体的な構成を示す。図１において、利用者の環境にはパソコンやワークステーションなど、デジタル情報を利用するための情報処理装置１１があり、それには暗号化された情報を復号する（あるいは復号するための鍵を復号する）ため、およびそのタイミングを捕らえて利用履歴を記録するためのトークン１２が接続されている。トークン１２と情報処理装置１１の間の接続は、ＰＣカード（ＰＣＭＣＩＡ：パーソナル・コンピュータ・メモリ・カード・インターフェース・アソシエーション）インターフェース、シリアル、パラレル、赤外線など、情報を伝達できる手段であれば何でも用いることができる。情報処理装置１１の内部に実装するようにしてもよい。
【００４４】
ユーザの情報処理装置１１はセンター側の、ワークステーションあるいは大型計算機などの情報処理装置で構成される回収装置１３と必要に応じて接続される。接続の形態は、モデムと電話回線、あるいはイーサネットなどのネットワークインターフェースでよい。この接続は常時行われる訳ではなく、利用者の情報処理装置１１から利用履歴の回収が必要な時のみ行われれば十分である。
【００４５】
図２にユーザ側の情報処理装置１１の構成を示す。ユーザの情報処理装置１１は一般のパソコンやワークステーションで良い。トークン１２が接続されているところのみが異なる。情報処理装置１１は、制御部１４、情報保持部１５、履歴保持部１６および履歴送信部１７を実現する。このような構成は、例えばプログラムが記録された記録媒体１１ａを用いて当該プログラムをインストールすることにより実現できる。
【００４６】
制御部１４はトークン１２と通信しながら、以下のような処理を行う。
▲１▼情報保持部１５に格納されている暗号化された情報を読み出し、トークン１２へ渡して復号してもらい、復号された情報を実行あるいは処理する。
▲２▼復号データを受け取った際に同時にトークン１２から渡される利用履歴を受け取り、それを履歴保持部１６に格納する。
▲３▼ユーザからの指示を受けて、トークン１２に「検証値出力」の命令を出し、その結果である電子署名の施された検証値を履歴送信部１７に渡す。
【００４７】
情報保持部１５は利用者が利用するデータや情報、あるいは暗号化されたデータが格納されている。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。
【００４８】
履歴保持部１６は制御部１４を通じてトークン１２側から渡された履歴が格納される。実際にはメモリあるいはハードディスク装置などの外部記憶装置で構成される。履歴の具体的な構成については後述する。
【００４９】
履歴送信部１７は制御部１４からの命令を受けて、制御部１４から渡された検証値と共に履歴保持部１６に保持されている履歴を読み出して、センターの回収装置１３に送信する。実際にはモデムと電話回線、あるいはイーサネットなどのネットワークインターフェースなどで構成される。あるいは、ネットワークでなくともフロッピーディスクなどの装置へ一旦格納し、それをユーザが人手でセンターの回収装置１３に入力するようにしてもよい。
【００５０】
図３にユーザ側のトークン１２の構成を示す。トークン１２は物理的には一般のＭＰＵ、メモリ等から構成される。トークン１２はそれ自体が、メモリの内容を読み出したり破壊したりするなど、外部からの物理的な攻撃に耐えるように攻撃対抗容器内に収められる。攻撃対抗容器は周知の技術であるので（特許第１８６３５３号、特許第１８６０４６３号、特開平３−１００７５３号公報等）、ここでは説明を省略する。なお、どの程度の攻撃に耐えうるものを選ぶかはデータのセキュリティの程度に応じて変化する。攻撃態勢が弱いものでもよい場合もある。
【００５１】
トークン１２はユーザの情報処理装置１１に接続され、情報処理装置１１からの指示に従って一定の処理を行い、その結果を返す。トークン１２はユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、検証値出力部２２、トークン秘密鍵保持部２３、電子署名部２４等を有している。トークン１２の各構成部については後に詳述する。トークン１２は以下の機能を持つ。
【００５２】
▲１▼情報の復号機能と利用履歴の保持
（１）情報処理装置１１から暗号化データを受け取り、それをユーザ秘密鍵保持部１８に格納されている秘密鍵で復号し、復号データを情報処理装置１１に返す。
（２）復号処理を行うと同時に復号されたデータのヘッダを参照し、そこに記されている情報識別子を参照し、その識別子を利用履歴として情報処理装置１１に返す。
（３）さらに、利用履歴は検証値生成部２０にも渡され、検証値生成部２０は利用履歴とその時点で検証値保持部２１に保持している検証値とに対して計算を行い、その計算結果を検証値保持部２１に格納する。
【００５３】
▲２▼検証値の出力機能
情報処理装置１１からの出力要求を受けて、その時点で検証値保持部２１に保持している検証値に電子署名を施して返す。その後、検証値保持部２１内のデータを消去する。
【００５４】
以下、トークン１２の各構成部について説明する。
【００５５】
復号部１９は情報処理装置１１からの復号要求に答えて、渡された暗号化データを、ユーザ秘密鍵保持部１８に保持されているユーザ固有の秘密鍵を用いて復号処理を行い、その結果を復号データとして情報処理装置１１側へ返す。このとき、それと同時に復号したデータのヘッダを読み取り、そこに記されている情報識別子を利用履歴として情報処理装置１１側へ返すと共に、検証値生成部２０にも渡す（この例では利用履歴は、利用した情報の情報識別子を用いている）。
【００５６】
このように構成することで、ユーザは情報を利用する際には必ずトークン１２へのアクセスが必要となり、利用履歴を確実に記録することができるようになる。
【００５７】
ここで、情報処理装置１１側から渡される暗号データは、情報そのものが暗号化されたものでもよいし、あるいは暗号化された情報を復号するための鍵を暗号化したものでもよい。後者の場合には情報処理装置１１側で情報本体の復号処理がなされることになる。
【００５８】
ユーザ秘密鍵保持部１８は、ユーザ固有の秘密鍵を保持する。一般的には、トークン１２は予めトークン発行センターなどによって、ユーザごとの固有の鍵を封入した形でユーザに配布される。従って、このユーザ秘密鍵はユーザ自身も知ることができない。
【００５９】
検証値保持部２１は順次更新される一つの検証値のみを保持する。検証値は一般に１６バイトなど、固定の長さを持つ値である。従って、検証値が１６バイトであるならば、１６バイトのメモリだけで構成される。図４に検証値の構成例を示す。
【００６０】
検証値出力部２２は、情報処理装置１１側からの検証値の出力要求を受けて、その時点で検証値保持部２１に格納されている検証値を読み出し、それを情報処理装置１１側に返すという機能を持つ。その際、検証値出力部２２は電子署名部２４を呼び出して、検証値に対して電子署名を施す。
【００６１】
電子署名部２４はそのトークン専用の秘密鍵を保持するトークン秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。トークン秘密鍵保持部２３は電子署名を行う際に用いられる署名用の秘密鍵を保持する構成部である。これらの構成部にはＲＳＡ署名などの電子署名技術を用いることが可能であり、従来の技術であるのでここでは詳細な説明は省略する。
【００６２】
検証値生成部２０は復号部１９から利用履歴（ここでは情報識別子）を受け取ったら、検証値保持部２１に保持されている検証値を読み取り、利用履歴と検証値とから、以下のような計算を行って新しい検証値を計算する。
【００６３】
【数１】
Ｈ＝Ｈａｓｈ（Ｕｓａｇｅ＋Ｈｏｌｄ）
ここで、Ｈは新しい検証値、Ｈｏｌｄは現在の検証値、Ｕｓａｇｅは利用履歴、Ｈａｓｈ（）は一方向性関数を意味し、実際にはＭＤ５やＳＨＡ（ＳｅｃｕｒｅＨａｓｈ Ａｌｇｏｒｉｔｈｍ）などが用いられる。この演算における”＋”という演算は実際に数値として足し算を行ってもよいし、長さが同じであれば排他的論理和を取っても、あるいは、単に二つのデータを順に並べただけでもよい。いずれにしろ二つの値を合成したものであればよい。検証値生成部２０はこのように計算した新しい検証値を、検証値保持部２１に格納する（つまり、古い値を上書きする）。
【００６４】
検証値出力部２２は情報処理装置１１からの出力要求を受け、その時点で検証値保持部２１に保持している検証値を返してから、検証値保持部２１を予め決められた値に初期化するようにする。あるいは単純にクリアするようにしてもよい。
【００６５】
次にセンターの回収装置１３について説明する。回収装置１３の構成を図５に示す。図５において、回収装置１３は、履歴受信部２５、履歴保持部２６、履歴検証部２７、トークン公開鍵保持部２８、署名検証部２９等を有している。回収装置１３はユーザの情報処理装置１１から送られた履歴を履歴受信部２５によって受信し、その内容を履歴保持部２６に格納する。格納された利用履歴は履歴検証部２７によって読み取られ、履歴が正しいかどうかが検証され、その結果はセンター側の管理者に出力される。
【００６６】
一般的にはセンターはこの後、その履歴の内容に従って、情報の利用料金を計算し、その料金を利用者から徴収し、徴収した利用料金を情報の利用履歴の明細に従って、情報提供者に分配するという処理を行う。しかし、本発明の本質とは直接は関係無いのでここでは説明を省略する。
【００６７】
以下、回収装置１３の各構成部について説明する。
【００６８】
履歴受信部２５は情報処理装置１１から送られてくる履歴情報を受信する。実際には情報処理装置１１の履歴送信部１７（図２）と同様にモデムと電話回線あるいはイーサネットなどのネットワークインターフェース、あるはフロッピーディスク装置などの外部からの情報入力装置で構成される。履歴受信部２５によって受信された利用履歴は履歴保持部２６に格納される。
【００６９】
さらに、情報処理装置１１から送られてきた検証値が正当なものであるかどうかを検証するために、トークン公開鍵保持部２８と署名検証部２９を有している。
【００７０】
情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。もし、検証結果が偽であるという結果が出た場合にはその検証値は改竄あるいは偽造された可能性があるので、以下の処理は続行せず、管理者にその旨のメッセージを出力して処理を停止する。
【００７１】
署名が検証された場合は以下の処理が続けられる。
【００７２】
履歴保持部２６は履歴受信部２５から渡された利用履歴および検証結果を保持する。履歴保持部２６は実際にはメモリなどの記憶装置で構成される。
【００７３】
履歴検証部２７は履歴保持部２６に保持された履歴を以下のようにして検証する。
（１）送信された履歴の系列を、ｕｄ1，ｕｄ2，ｕｄ3．．．ｕｄnとする。
（２）履歴の最後に添付されている検証値を、ｈｕｄとする。
（３）検証値の初期値をｉｈｕｄとすると、以下の計算式に従って、計算した結果であるｈｕｄ’が、送られてきたｈｕｄと等しくなるかどうかを調べる。
【００７４】
【数２】
ｈｕｄ’＝Ｈａｓｈ（ｕｄn＋Ｈａｓｈ（ｕｄn-1＋．．．Ｈａｓｈ（ｕｄ2＋Ｈａｓｈ（ｕｄ1＋ｉｈｕｄ））．．．））
ｈｕｄ＝？ｈｕｄ’
（４）もし等しければ、改竄されていない、等しくなければ改竄されていると判断し、その結果を回収装置の管理者に通知する。
【００７５】
次に各部で処理される情報の形式について説明する。
【００７６】
図６にトークン１２で復号の対象となる暗号化された情報の形式を示す。（ａ）は情報そのものをユーザの秘密鍵で暗号化している場合である。（ｂ）は、最初に情報本体を暗号化するのに用いている秘密鍵をユーザ固有の秘密鍵で暗号化したものを復号し、その結果得られた情報固有の秘密鍵を用いて、情報本体の復号を行うという場合である。（ｂ）の場合には情報本体の復号はトークン１２ではなく、情報処理装置側で行ってもよい。また、ここでは慣用暗号を用いている例を説明しているが、これらは公開暗号を用いてもよいことは言うまでもない。
【００７７】
ここで、情報識別子とは、センターが情報を暗号化させて流通させる時に付与される情報固有の識別子である。情報識別子はセンターによって管理され（データベースを持つなどによって）、情報識別子を特定すると、その情報が誰によって作成されたものであるのか、などを特定できる。
【００７８】
図７には利用履歴の形式を示す。（ａ）は本情報処理システムにおける情報処理装置１１内に記録される利用履歴であり、利用した（トークンで復号した情報の）情報識別子の列である。（ｂ）は情報処理装置１１からセンターに送付される利用履歴であり、（ａ）の最後にトークンが保持する検証値、および検証値に対するトークンの署名が添付されているところのみが異なる。
【００７９】
個々の利用履歴は本情報処理システムでは利用した情報識別子のみで構成されているが、これは任意のデータ、例えば、利用した時刻、利用者の識別子、利用量、利用金額などが含まれていてもよい。すなわち種々の情報を履歴として残す場合（一般に履歴は種々の情報を残すのが一般的である）には個々の履歴が長くなるため、本発明が有効となる。
【００８０】
次に情報処理装置１１およびトークン１２における処理を図８から図１２を参照して説明する。図８は情報処理装置１１の制御部１４において、利用者から情報の利用要求が有った時の処理の流れである。図９は同じく制御部１４において利用者から利用履歴回収命令が有った時の処理である。図１０はトークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理である。図１１はトークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理である。図１２はトークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理である。
【００８１】
図８に示すように、利用者から情報利用の要求があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ１１）、暗号化されていなければ情報をそのまま処理する（Ｓ１５）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ１２）。このとき、トークン１２からエラーが返されたら「トークンの履歴が一杯です」というエラーメッセージを出して処理を終了する（Ｓ１３、Ｓ１６）。エラーが返されなければ、トークン１２から過閲された利用履歴をディスク等の記録装置に記録する（Ｓ１４）。そして対象情報を処理する（Ｓ１５）。
【００８２】
図９に示すように、利用者から利用履歴回収命令があったときには情報処理装置１１の制御部１４においてつぎのように処理が進む。まず、対象の情報が暗号化されているかどうかを判別し（Ｓ２１）、暗号化されていなければ情報をそのまま処理する（Ｓ２４）。暗号化されているときにはトークン１２に対して復号要求を出して、対象情報を引き渡す（Ｓ２２）。そしてトークン１２から返された利用履歴をディスク等の記録装置に記録する（Ｓ２３）。こののち対象情報を処理する（Ｓ２４）。
【００８３】
図１０に示すように、トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時にはつぎのように処理が進む。まず、ユーザ秘密鍵保持部１８からユーザ秘密鍵Ｋｕが取り出される（Ｓ３１）。暗号化データをユーザ秘密鍵Ｋｕで復号して復号データを記憶する（Ｓ３２）。復号データのヘッダを参照して情報識別子を読み取り、この識別子を引数として検証値生成部２０を呼び出し検証値生成処理を実行させる（Ｓ３３、Ｓ３４、図１１参照）。この後復号データと識別子とを情報処理装置１１に返す（Ｓ３５）。
【００８４】
図１１に示すように、トークン１２の検証値生成部２０がトークン１２の復号部１９から呼び出されたときにはつぎのように処理が進む。まず、検証値保持部２１から検証値を取り出す（Ｓ４１）。情報識別子と検証値とについてハッシュ計算を行って、計算結果を新たな検証値として検証値保持部２１に記憶する（Ｓ４２、Ｓ４３）。
【００８５】
図１２に示すように、トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時にはつぎのように処理が進む。まず、検証値保持部２１に記憶されている検証値を読み出す（Ｓ５１）。こののち、検証値保持部２１の記憶内容を初期化する（Ｓ５２）。読み出した検証値を引数として電子署名部２４を呼び出し、検証値に署名を施す（Ｓ５３）。検証値の後に署名を付して出力する（Ｓ５４）。
【００８６】
以上でこの発明の実施例が前提とする情報処理システムの説明を終了する。
【００８７】
なお、特願平８−６２０７６号のユーザ認証装置および方法を、本発明と組み合せて使用した場合には、発行するアクセスチケットごとにべき乗剰余の計算における法ｎを変えるようにすることで、法ｎを情報識別子として用いることができる。すなわち、特願平８−６２０７６号のユーザ認証手法ではアクセスチケット（認証用補助情報）を外部から受け取り、このアクセスチケットとユーザ識別情報とを用いて証明、例えば暗号データの復号を行うようになっている。そして、このときに用いる法ｎを情報識別子として利用する。その場合には、法ｎはトークンの内部の復号装置で復号されてから取り出されるのではなく、復号対象の情報と共に外部から与えられることになる。
【００８８】
このように構成することで、トークン１２内部に用意しなければならない検証値保持部２１の容量を最小に押さえることができ、トークン１２の生産コストを低くすることが可能となる。
【００８９】
［実施例］
次に本発明の実施例について説明する。ここで述べる実施例はさきに説明した情報処理システムに対して、幾つかの機能を追加したものである。以下にその機能と効果について列挙する。
【００９０】
▲１▼トークン１２が検証値を出力して機能を停止し、センターからメッセージを受け取ると機能を回復する。
【００９１】
検証値を外部に出力する時やあるいは時計機能を用いて一定時間を経過した時などに、利用者に履歴の回収を促すためにトークン１２がその時点での検証値を出力して停止するようにする（あるいは自律的に停止して検証値を要求するようにしてもよい）。利用者がトークン１２の機能を回復させるためにはセンターに履歴と検証値を送信して、確認してもらい、センターから機能を回復させるためのメッセージを受け取るしかない。センターが発行する機能回復用のメッセージは、ユーザから送られた検証値にセンターが電子署名を施したものとする。
【００９２】
▲２▼履歴としてその利用履歴を処理した時点での検証値も出力する。
【００９３】
利用履歴の内容を情報識別子だけではなく、その履歴を生成した時点での検証値も含ませる。これによって、個々の履歴の連続性を後から調べることが可能になり、情報処理装置側での履歴の（順序の）管理を厳密に行わなくても良いようにする。
【００９４】
▲３▼センター側で古い検証値を保持する。
【００９５】
さきの情報処理システムでは、利用者からの出力要求によって、トークン内部の検証値は初期化されていた。しかしながら、センターの回収装置側で利用者の前回の検証値を保持することによって、その機能を不要にすることができる。
【００９６】
図１３に本実施例におけるトークン１２の構成を示す。なお、図１３において図３に対応する箇所には対応する符号を付して詳細な説明を省略する。この図において、トークン１２は、ユーザ秘密鍵保持部１８、復号部１９、検証値生成部２０、検証値保持部２１、トークン秘密鍵保持部２３、電子署名部２４、制御部３０、履歴生成部３１、計数部３２、センター公開鍵保持部３３、署名検証部３４等を有している。なお、必要に応じて時計部３５を設けてもよい。
【００９７】
本実施例では情報処理装置１１との通信はすべて制御部３０を介して行われるように構成され、制御部３０は情報処理装置１１からの要求に対し適切に他の処理部を呼出して処理を行う。
【００９８】
制御部３０はその内部にトークン１２の動作状態を保持しており、動作状態には通常モードと停止モードの二つのモードがある。通常モードにおいてはトークン１２は情報処理装置１１からの復号要求に対して、第１の実施例で述べたように復号処理を行い、その結果を返すという処理を行う。一方、停止モードにおいては復号要求の処理は受け付けない。停止モードにおいては基本的には機能再開要求（センター署名付き検証値）のみを受け付け、その要求が正当である場合には停止モードを解除し、通常モードへ移行するという処理を行う（実際にはそれ以外にもその時点で検証値保持部２１に保持している検証値に署名した検証値を出力するという処理も受け付けるようにしてもよい）。
【００９９】
通常モードから停止モードへの移行は、例えば復号処理を行った回数などによる。図１３の計数部３２は復号処理を行った回数を保持している。例えば、その回数が予め定められた回数（例えば１００回など）を超えたら、「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１００】
構成として時計を有する場合には、制御部３０内部に保持された前回の停止時刻の情報に基づいて行うようにしてもよい。すなわち、制御部は情報処理装置からの要求があったとき、制御部内に保持された前回停止時刻と現在の時刻を比較し、予め決められた時間（例えば一か月、など）が経過していた場合には「期限が過ぎた」旨のメッセージを情報処理装置１１側に返して、停止モードへ移行する。
【０１０１】
つぎにトークン１２の制御部３０の処理を図１４〜図１６を参照して詳細に説明する。なお、図１４〜図１６において点線で示してある箇所は制御部３０の処理ではなく、関連する構成部の処理であることを意味する。
【０１０２】
図１４において、情報処理装置１１からトークン１２の制御部３０に復号要求、検証値出力要求および機能再開要求のいずれかが入力される。まず、制御部３０のモードが停止モードかどうかが判別される（Ｓ６１）。停止モードでないときには計数部３２の計数値が読み取られ、この計数値が基準値、例えば１００を越えたかどうかが判別される（Ｓ６２、Ｓ６３）。１００を越えていない場合には図１６のノードＢに進み、復号処理等を行う。１００を越えている場合には署名付き検証値を出力する。すなわち、検証値保持部２１の値を読み出し、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ６４、Ｓ６５）。こののち、署名付き検証値と「停止モードへ移行」というメッセージを情報処理装置１１に返す（Ｓ６６）。そして計数部３２の計数値をクリアして停止モードに移行する（Ｓ６７、Ｓ６８）。
【０１０３】
ステップＳ６１において、制御部３０が停止モードの場合には、受け取った要求が復号要求か、検証値出力要求か、機能再開要求かが判別される（Ｓ６９、Ｓ７０、Ｓ７１）。要求が復号要求の場合には情報処理装置１１に「現在は停止モードである」というメッセージを返し、処理を終了する（Ｓ７２）。要求が検証値出力要求の場合には検証値保持部２１の検証値を読み取り、電子署名部２４により署名付き検証値を生成させ、受け取る（Ｓ７３、Ｓ７４）。こののち、署名付き検証値を情報処理装置１１に返し処理を終了する（Ｓ７５）。機能再開要求のときには図１５のノードＡの機能再開処理に進む。受け取った要求が復号要求、検証値出力要求、機能再開要求のいずれでもない場合には情報処理装置１１にエラーを返して処理を終了する（Ｓ７６）。
【０１０４】
図１５は機能再開処理を示す。図１５において、まず、受け取ったセンター署名付き検証値を署名検証部２４に渡して署名の正当性を検証する（Ｓ７７）。署名が正しければ、渡された検証値と、検証値保持部２１の検証値とを比較し、双方が一致するかどうかを検査する（Ｓ７８〜Ｓ８０）。一致すれば制御部のモードを停止モードから通常モードに移行させ、「機能再開」のメッセージを情報処理装置１１に返す（Ｓ８１、Ｓ８２）。ステップＳ７８において署名が正しくない場合には、「署名が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８３）。ステップＳ８０において検証値が一致しない場合には「検証値が正しくない」というメッセージを情報処理装置１１に返して処理を終了する（Ｓ８４）。
【０１０５】
図１６は計数値が閾値例えば１００を上回っていない場合の処理を示す。図１６において、まず要求が復号要求かどうかが検査される（Ｓ８５）。復号要求の場合には渡されたデータを復号部１９に送る（Ｓ８８）。復号部１９は復号を行う（Ｓ８９〜Ｓ９３）。また要求が復号要求でない場合には検証値要求かどうかが判別される（Ｓ８６）。検証値要求である場合には図１４のノードＣに進み、検証値出力処理を行う。ステップＳ８６において検証値出力要求でもない場合にはエラーを情報処理装置１１に返して処理を終了する（Ｓ８７）。
【０１０６】
以上でトークン１２の制御部３０の処理の説明を終える。
【０１０７】
なお、この例では、情報処理装置１１側から検証値要求が有った時にも停止モードへ移行するようにしているけれども（図１６のステップＳ８６から図１４のノードＣへ移行）、そうしなくても構わない。例えば通常モードにおける検証値要求に対しては、検証値を更新して単にその時点で保持している検証値に署名した値を返すようにしてもよい（このメリットについては本実施例の説明の最後で述べる）。
【０１０８】
復号部１９、ユーザ秘密鍵保持部１８は第１の実施例と同様の機能を有する。
【０１０９】
履歴生成部３１は図１６でも示したように復号部１９から渡された情報識別子と現在の検証値の三つの組を生成し、それを利用履歴として制御部３０に渡すという処理を行う。
【０１１０】
検証値生成部２０は履歴生成部３１から渡された履歴ｕｄに対し、
【０１１１】
【数３】
Ｈｕ＝Ｈａｓｈ（ｕｄ）
なるハッシュ値を計算し、それを検証値保持部２１に格納するという処理を行い、検証値保持部２１はその時点での検証値を保持する。
【０１１２】
電子署名部２４は第１の実施例と同様に、そのトークン専用の秘密鍵を保持する秘密鍵保持部２３に保持された秘密鍵を用いて、与えられた値に対して電子署名を施す処理を行う。本実施例ではさらに、署名検証部３４が設けられ、センター公開鍵保持部３３に保持されたセンターの公開鍵を用いて渡された署名がセンターの署名であるかどうかを検証するという処理を行う。これらの構成部には基本的にはＲＳＡ署名などの電子署名技術を用いることが可能であり、周知の技術であるのでここでは詳細な説明は省略する。
【０１１３】
本実施例における情報処理装置１１の構成を図１７に示す。図１７において図２と対応する箇所には対応する符号を付す。この図において、基本的にはさきの情報処理システムのものとほぼ同じ構成であるが、本実施例の情報処理装置１１ではある時点でトークンが停止モードに入ってしまうので、それを再開させるためにはセンターに履歴を送信し、それに対する再開メッセージを送ってもらわねばならない。そこで、センターからの署名付きの検証値を受け取る署名付き検証値受信部３６があるところが異なる。また、履歴保持部１６に保持される履歴の構成が異なっている。
【０１１４】
図１８に本実施例におけるセンターの回収装置１３の構成を示す。図１８において図５と対応する箇所には対応する符号を付す。この図において、構成としては第１の実施例のものに比べると、履歴の正当性が検証された場合には情報処理装置１１にセンターの署名付き検証値を送らねばならないので、それを行うための構成部、すなわちセンター秘密鍵保持部３７、電子署名部３８、署名付き検証値送信部３９が増設されている。また、情報処理装置１１側から送られる利用履歴の構成が異なっているので、当然回収センターで処理される履歴も異なる。
【０１１５】
図１９に各部で保持される利用履歴の構成を示す。
（ａ）は情報処理装置１１の履歴保持部１６に記録される利用履歴である。個々の履歴の内容は（ｃ）に示されたような情報識別子とその時点でトークンに保持されていた検証値のペアの構成となっている。
【０１１６】
情報処理装置１１からセンターに履歴を送付する際には、その履歴の列の最後にトークン１２の署名の付いた検証値が付与される（ｂ）。署名付き検証値はトークン１２が機能を停止した際に出力されるものであり、その時点での検証値にトークン１２が電子署名を施したものである（ｄ）。
【０１１７】
センターは履歴の検証のために（ｄ）の署名付き検証値を用いる。そして検証の結果、正当なものであると判断されると、トークン１２の機能を再開させるためのメッセージとして最後に添付された検証値にセンターが電子署名を施した値を情報処理装置１１に送る。それが（ｅ）である。
【０１１８】
次に回収装置１３の処理について説明する。情報処理装置１１から履歴が送信されると、履歴受信部２５が受け取る。受け取った履歴は履歴保持部２６に格納されると共に、署名検証部２９に渡される。署名検証部２９はトークン公開鍵保持部２８に格納されている複数のトークン公開鍵の中から履歴を送信してきた情報処理装置１１に接続されているトークン１２の公開鍵を選択し、その公開鍵を用いて履歴の署名を検証する。その検証結果は履歴保持部２６に格納されている履歴とともに保持される。
【０１１９】
履歴の受信が終わると履歴検証部２７が動作しはじめる。履歴検証部２７は今受信した履歴を参照し、それに付随している署名の検証結果を参照する。署名の検証結果が正当でない場合には、これ以降の処理は行われない。履歴に付随している検証結果が正当であれば、さらに履歴の内容が正当であるかどうかを検証する。
【０１２０】
履歴の内容の検証処理は以下のように行われる。
（１）送られてきた履歴の列が以下のようなものであるとする。
（ｉｄ1，ｈｕ0），（ｉｄ2，ｈｕ1），（ｉｄ3，ｈｕ2），．．．，（ｉｄn，ｈｕn-1），ｓｉｇｎ（ｈｕn）
ただし、ここでｉｄは情報識別子、ｈｕはその履歴が生成された時点での検証値、ｓｉｇｎ（）はトークンのサインであるとする。
（２）トークンが前回送ってきた際の検証値を履歴保持部の中から捜し出し、それをＨｕｏｌｄとする。
（３）送られてきた利用履歴の最初の履歴（ＩＤ1，ｈｕ0）の中から検証値ｈｕ0を取り出し、それがＨｕｏｌｄと等しいかどうかを確かめる。
（４）次にＨａｓｈ（ｉｄ1，ｈｕ0）を計算し、それがｈｕ1になるかどうかを確かめる。
（５）以下同様にして最後の検証値ｈｕnまで確かめる。
（６）すべての検査にパスしたら利用履歴は正当なものであると判断する。
【０１２１】
検証処理の結果、履歴が正しいものと判断された場合のみ、最後の検証値ｈｕｎが電子署名部に送られ、センターの秘密鍵で電子署名が施される。そして、センターの署名付きの検証値が履歴を送付してきた情報処理装置に送り返される。
【０１２２】
以上のように構成することで、ある時点でトークンが機能を停止するため、その情報処理装置の利用者はトークンの機能を再開させるためには正当な履歴をセンターに送付しなければならなくなる。従って、履歴の回収を利用者に促すことが可能になる。
【０１２３】
また、センター側に最後の検証値が記録されているため、トークンから送付された正しい履歴が何らかの理由で一部が破壊されていた場合でも、単に検証が成功しなかっただけであるので、センター側の保持データは何も変化しない。従って、その場合にはトークンが履歴を再送付すれば検証は正常に行われることになる。
【０１２４】
また本実施例において、トークンが自律的に検証値を出力するように構成することで、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証可能なようにすることができる。
【０１２５】
すなわち、前述したように利用者が検証値を要求した時だけでなく、トークンの負荷が低いときにトークンが自律的にその時点で保持している検証値に署名したものを出力することによって、回収装置側で履歴を検証する際に、一部の履歴が壊れていた（失われていた）場合でも、他の部分のほとんどについては検証が可能になる。
【０１２６】
この場合には、センターへ送付される利用履歴は例えば図２０のような構成になる。この時、何らかの事故によって情報処理装置側で履歴２５が失われてしまったとする。
【０１２７】
先に示したような検証値を最後にしか持たないような利用履歴の場合には履歴２６以降は検証可能となるが、履歴１から履歴２４については内容が失われていないにもかかわらずそれが正当であることは検証できない。
【０１２８】
それが途中に署名付の検証値を挿入することによって、この例の場合には履歴２５が失われた場合には履歴２４のみが検証不可能となるだけで、残りの履歴については検証可能となるのである。つまり、履歴１から履歴１０までは署名付き検証値１によって、履歴１１から履歴２３までは署名付き検証値２によって、履歴２５から履歴３６までは署名付き検証値３によって、履歴３７から履歴５７までは署名付き検証値４によって、それぞれが検証可能となるからである。
【０１２９】
このように適当な間隔で署名付きの検証値を履歴中に挿入することで履歴の一部が失われた場合にでも残りの履歴の大部分について検証を可能とすることができるようになるのである。
【０１３０】
これを実現するためにはトークン内部の制御部において負荷が低いかどうかを判定する装置を設け、トークンの負荷が低い場合には自律的に署名付き検証値を生成しておくようにすればよい。
【０１３１】
また、トークンが自律的に行わなくても情報処理装置すなわち利用者からの要求によって署名付き検証値を出力するように構成すればよい。そのためには図１６のノードＣを図１４のノードＣ（ステップＳ６４）に分岐させるのではなく、検証値を更新して署名付き検証値を生成しそれを情報処理装置１１に返すように処理を変更すればよい。
【０１３２】
また、トークンに時計機能を持たせることによって、利用履歴として時刻の情報を取ることができるようになる。それによって、回収センター側は単にどの情報を利用したのかという履歴だけではなく、利用した時刻も知ることができるようになる。時計部は通常の時計機能であり、年月日および時刻を保持し、要求に従って現在の時刻を出力する機能を有するだけでよい。履歴に時刻を含ませるには、前述してきた情報識別子に時刻の情報も結合するだけでよい。また、時計機能を有すると、前述した停止モードへの移行の条件として、「前回に停止した時から経過した時間」にすることが可能になる。
【０１３３】
さらにまた、本実施例では外部に出力する履歴にその時点で保持していた検証値を付与するように構成しているが、これはトークン内部にカウンタ部を設け、履歴を出力するごとにカウンタの値をカウントしていくようにし、履歴を外部に出力する際に検証値ではなく、カウンタの値を出力するようにしてもよい。その場合は、これまでの説明中のハッシュ関数の入力となる部分が、利用履歴およびその時点で保持しているカウンタの値となる。
【０１３４】
以上説明したように、この実施例によれば、保持するデータ量を減らすために、データを防御装置内に保管せず、防御装置の外に出力し、その代わりとしてデータ量の小さな検証値を防御装置内に保管するようにしている。したがって防御装置の記憶容量や必要処理能力を抑えることができる。検証値は署名を付して外部に送られるので改竄を防止でき、データの検証を確実に行える。また、データの順序を復元可能とするために、データに順序復元用の情報を付加することにより、分散して保管されているデータであってもその順序を復元して、検証を容易にすることができる。さらに、防御装置が保持するデータに対して正当者の署名を付与した値を、防御装置が受け取ったときに、関連する処理を継続実行できるようにしているので、継続実行するには、防御装置内に保持したデータを正当者に送り署名を受けた後返送してもらわなければならない。したがって、正当者には必然的に検証対象のデータが送られてきて、検証対象のデータを確実に回収することができる。また、署名付き検証値を頻繁に出力するようにすればデータの一部が破損等しても他の多くのデータについては確実に検証を行うことができる。
【０１３５】
【発明の効果】
以上説明したように、この発明によれば、例えば、防御装置が保持するデータに対して正当者の署名を付与した値を、防御装置が受け取ったときに、関連する処理を継続実行できるようにしているので、継続実行するには、防御装置内に保持したデータを正当者に送り署名を受けた後返送してもらわなければならない。したがって、正当者には必然的に検証対象のデータが送られてきて、検証対象のデータを確実に回収することができる。この発明によれば、署名付きデータの署名の正当性が検証されたときに、停止中の機能を停止解除するので、不正な停止解除要求に対処することができる。
【図面の簡単な説明】
【図１】 この発明の実施例が前提とする情報処理システムを全体として示すブロック図である。
【図２】 図１の情報処理装置１１の構成を示すブロック図である。
【図３】 図１のトークン１２の構成を示すブロック図である。
【図４】 図３の検証値保持部２１を説明する図である。
【図５】 図１の回収装置１３の構成を示すブロック図である。
【図６】 トークン１２において復号される情報を説明する図である。
【図７】 利用履歴の構成を説明する図である。
【図８】 利用者から情報の利用要求が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図９】 利用者から利用履歴回収命令が有った時の情報処理装置１１の制御部１４の処理を説明するフローチャートである。
【図１０】 トークン１２の復号部１９が情報処理装置１１から暗号化された情報の復号要求を受け取った時の処理を説明するフローチャートである。
【図１１】 トークン１２の復号部１９から呼び出されるトークン１２の検証値生成部２０の処理を説明するフローチャートである。
【図１２】 トークン１２の検証値出力部２２が情報処理装置１１から検証値出力要求を受け取った時の処理を説明するフローチャートである。
【図１３】 この発明の実施例に用いるトークン１２の構成を示すブロック図である。
【図１４】 図１３のトークン１２の処理を説明するフローチャートである。
【図１５】 図１３のトークン１２の処理を説明するフローチャートである。
【図１６】 図１３のトークン１２の処理を説明するフローチャートである。
【図１７】 上述実施例の情報処理装置１１において実現されている機能ブロックを示すブロック図である。
【図１８】 上述実施例の回収装置１３の構成を示すブロック図である。
【図１９】 上述実施例の利用履歴の構成を説明する図である。
【図２０】 上述実施例の利用履歴の他の構成を説明する図である。
【図２１】 関連技術を説明する図である。
【符号の説明】
１１ 情報処理装置
１２ トークン
１３ 回収装置
１４ 情報処理装置１１の制御部
１５ 情報処理装置１１の情報保持部
１６ 情報処理装置１１の履歴保持部
１７ 情報処理装置１１の履歴送信部
１８ トークン１２のユーザ秘密鍵保持部
１９ トークン１２の復号部
２０ トークン１２の検証値生成部
２１ トークン１２の検証値保持部
２２ トークン１２の検証値出力部
２３ トークン１２のトークン秘密鍵保持部
２４ トークン１２の電子署名部
２５ 回収装置１３の履歴受信部
２６ 回収装置１３の履歴保持部
２７ 回収装置１３の履歴検証部
２８ 回収装置１３のトークン公開鍵保持部
２９ 回収装置１３の署名検証部
Claims (6)
- 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器において、
上記電子機器本体における利用履歴と、当該利用履歴の正当性を検証するために用いる検証値または利用履歴の送出カウントからなる所定のデータとを上記回収装置側に出力する手段と、
上記所定のデータが出力されるときに当該電子機器本体の少なくとも一部の機能を停止する機能停止手段と、
上記回収装置において上記所定のデータに署名を施して生成された署名付きデータを上記回収装置側から入力する手段と、
上記署名付きデータについて署名を検証する署名検証手段と、
上記署名検証手段によって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除する手段とを有することを特徴とする電子機器。 - 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器において、
所定の条件が満たされたときに当該電子機器本体の少なくとも一部の機能を停止する機能停止手段と、
上記所定の条件が満たされたときに上記電子機器本体における利用履歴と、当該利用履歴の正当性を検証するために用いる検証値または利用履歴の送出カウントからなる所定のデータとを上記回収装置側に出力する手段と、
上記回収装置において上記所定のデータに署名を施して生成された署名付きデータを上記回収装置側から入力する手段と、
上記署名付きデータについて署名を検証する署名検証手段と、
上記署名検証手段によって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除する手段とを有することを特徴とする電子機器。 - 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器において、
上記利用履歴を検証するために用いる検証値からなる所定のデータを保持するためのデータ記憶手段と、
機能を停止する一定の条件を保持するための停止条件保持手段と、
該停止条件保持手段に保持された条件を満たした時に機能を停止し、外部から正当な命令が与えられるまでは機能を停止し続けるための機能停止手段と、
秘密鍵を保持するための秘密鍵保持手段と、
データ保持手段に保持された上記データに該秘密鍵保持手段に保持された秘密鍵を用いて電子署名を施すための電子署名手段と、
署名した電子署名を保持するための電子署名保持手段と、
上記回収装置において電子署名用に用いられる回収装置側秘密鍵に対応する公開鍵を保持するための正当公開鍵保持手段とを有し、
上記機能停止手段が機能を復帰させるために受け付ける命令が、上記電子署名保持手段に保持された電子署名に対して上記回収装置において上記回収装置側秘密鍵による電子署名を施したものであり、
機能停止手段が命令を受け取った時に該正当公開鍵保持手段に保持されている公開鍵で上記命令の署名を検証し、さらに署名されている値が、電子署名保持手段に保持されている値と等しいかどうかを確認して当該確認が成功したときに機能停止を解除することを特徴とする電子機器。 - 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器の制御方法において、
上記電子機器本体における利用履歴と、当該利用履歴の正当性を検証するために用いる検証値または利用履歴の送出カウントからなる所定のデータとを上記回収装置側に出力するステップと、
上記所定のデータが出力されるときに当該電子機器本体の少なくとも一部の機能を停止する機能停止ステップと、
上記回収装置において上記所定のデータに署名を施して生成された署名付きデータを上記回収装置側から入力するステップと、
上記署名付きデータについて署名を検証する署名検証ステップと、
上記署名検証ステップによって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除するステップとを有することを特徴とする電子機器の制御方法。 - 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器の制御方法において、
所定の条件が満たされたときに上記電子機器本体の少なくとも一部の機能を停止する機能停止ステップと、
上記所定の条件が満たされたときに上記電子機器本体における利用履歴と、当該利用履歴の正当性を検証するために用いる検証値または利用履歴の送出カウントからなる所定のデータとを上記回収装置側に出力するステップと、
上記回収装置において上記所定のデータに署名を施して生成された署名付きデータを上記回収装置側から入力するステップと、
上記署名付きデータについて署名を検証する署名検証ステップと、
上記署名検証ステップによって上記署名付きデータの署名の正当性が検証されたときに上記一部の機能の停止を解除するステップとを有することを特徴とする電子機器の制御方法。 - 回収装置に回収される、電子機器本体における利用履歴のデータを出力する電子機器であって、上記利用履歴を検証するために用いる検証値からなる所定のデータを保持するためのデータ記憶手段と、機能を停止する一定の条件を保持するための停止条件保持手段と、該停止条件保持手段に保持された条件を満たした時に機能を停止し、外部から正当な命令が与えられるまでは機能を停止し続けるための機能停止手段と、秘密鍵を保持するための秘密鍵保持手段と、データ保持手段に保持された上記データに該秘密鍵保持手段に保持された秘密鍵を用いて電子署名を施すための電子署名手段と、署名した電子署名を保持するための電子署名保持手段と、上記回収装置において電子署名用に用いられる回収装置側秘密鍵に対応する公開鍵を保持するための正当公開鍵保持手段とを有する上記電子機器を制御する方法において、
上記機能停止手段の機能を復帰させるために外部から命令を受け付けるステップと、
上記受け付けた命令が、上記電子署名保持手段に保持された電子署名に対して上記回収装置において上記回収装置側秘密鍵による電子署名を施したものであるかどうかを、機能停止手段が命令を受け取った時に該正当公開鍵保持手段に保持されている公開鍵を用いて検証し、さらに署名されている値が、電子署名保持手段に保持されている値と等しいかどうかを確認し、この確認に基づいて上記受け付けた命令が正当な命令かどうかを判別するステップとを有し、
上記受け付けた命令が正当なものと判別されたときに上記機能の停止が解除されるようにしたことを特徴とする電子機器の制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003045837A JP3941711B2 (ja) | 2003-02-24 | 2003-02-24 | 電子機器および電子機器の制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003045837A JP3941711B2 (ja) | 2003-02-24 | 2003-02-24 | 電子機器および電子機器の制御方法 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27842396A Division JP3570114B2 (ja) | 1996-10-21 | 1996-10-21 | データ検証方法およびデータ検証システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004007432A JP2004007432A (ja) | 2004-01-08 |
| JP3941711B2 true JP3941711B2 (ja) | 2007-07-04 |
Family
ID=30437885
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003045837A Expired - Lifetime JP3941711B2 (ja) | 2003-02-24 | 2003-02-24 | 電子機器および電子機器の制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3941711B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5013694B2 (ja) * | 2005-09-09 | 2012-08-29 | キヤノン株式会社 | 画像処理方法、画像処理装置、プログラムコード及び記憶媒体 |
-
2003
- 2003-02-24 JP JP2003045837A patent/JP3941711B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004007432A (ja) | 2004-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3570114B2 (ja) | データ検証方法およびデータ検証システム | |
| US7270193B2 (en) | Method and system for distributing programs using tamper resistant processor | |
| EP0895148B1 (en) | Software rental system and method for renting software | |
| EP1253742B1 (en) | Method and system for generation and management of secret key of public key cryptosystem | |
| JP3799757B2 (ja) | 被検証データ生成装置、及び被検証データ生成プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| US7953977B2 (en) | Security and ticketing system control and management | |
| US5625690A (en) | Software pay per use system | |
| US7254705B2 (en) | Service providing system in which services are provided from service provider apparatus to service user apparatus via network | |
| US7249102B1 (en) | Original data circulation method, system, apparatus, and computer readable medium | |
| CN111027028A (zh) | 基于智能合约的版权数据处理方法以及装置 | |
| JPH11231775A (ja) | 条件付き認証装置および方法 | |
| JPH10303880A (ja) | サービス提供システム | |
| TW201141173A (en) | Verifiable, leak-resistant encryption and decryption | |
| JPH1131130A (ja) | サービス提供装置 | |
| CN200993803Y (zh) | 网上银行系统安全终端 | |
| JP3815022B2 (ja) | 利用資格検証装置および方法、ならびに、利用資格検証システム | |
| JP3659090B2 (ja) | 電子情報流通システム及び電子情報流通プログラムを格納した記憶媒体及び電子情報流通方法 | |
| JP3941711B2 (ja) | 電子機器および電子機器の制御方法 | |
| JP3979303B2 (ja) | 履歴保持方法および装置 | |
| JP3570781B2 (ja) | ソフトウェア保護システム | |
| JP2004309737A (ja) | 復号鍵保護プログラム及び復号鍵保護方法 | |
| JP2002352146A (ja) | コンテンツ部分課金方法及びシステム及びコンテンツ部分課金プログラム及びコンテンツ部分課金プログラムを格納した記憶媒体 | |
| JP2001350652A (ja) | 動作ログ蓄積装置および動作ログ蓄積管理方法 | |
| TWM579789U (zh) | Electronic contract signing device | |
| JPH1013402A (ja) | 公開鍵暗号の秘密鍵管理方法および装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061212 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070207 |
|
| 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: 20070313 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070326 |
|
| 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: 20110413 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120413 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140413 Year of fee payment: 7 |
|
| EXPY | Cancellation because of completion of term |