JP6648555B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理装置及びプログラムに関する。

デジタルデータはコピーや編集が可能であるため、そのままでは証拠として利用できない。

デジタルデータに証拠性を持たせるための技術として、例えばタイムスタンプ技術がよく知られている。例えばRFC3161に規定されるタイムスタンププロトコルでは、ユーザがデジタルデータのハッシュ値をタイムスタンプ局（TSA: Time Stamp Authority）に送る。タイムスタンプ局は、そのハッシュ値に現在時刻の情報を合成し、その合成結果のデータに対してＰＫＩ（公開鍵基盤）ベースのデジタル署名を施してタイムスタンプトークンを生成し、これをユーザに返す。このトークンのデジタル署名を検証することで、そのデジタルデータがそのトークンに含まれる時刻に存在していたこと、及びその時刻以降改ざんされていないことを検証できる。

また、文書データがある時点で存在していたことを、タイムスタンプ局のような単一の認証システムに依拠せずに証明できるようにするサービスとして、Proof of Existence（https://www.proofofexistence.com/）が知られている。このサービスは、ビットコイン（Bitcoin）で取引履歴の記録に用いられているブロックチェーンに対し、文書データに対応するブロックを登録することで、その文書データの存在証明を可能にする。ブロックチェーンにブロックを登録できるのは、P2P（ピア・トゥー・ピア）ネットワーク上に多数存在する「採掘者」と呼ばれる複数のノードのうち、プルーフ・オブ・ワーク（Proof of Work）を算出する処理を最初に成功した者である。このように、ブロックチェーンの信頼性は、中央システムの信頼性に依存するのではなく、ブロックチェーンの仕組み自体の信頼性に依拠している。

また、特許文献１に開示された技術では、デジタルカメラの撮影時刻を証明可能にするために、タイムスタンプサーバーと呼ばれる電子署名された時刻情報をネットワークから受け取り、その時刻とカメラ内部の時刻を同期することで、カメラの撮影時刻の信用を確立する。

特許文献２に開示された撮像装置は、撮影時に、ＧＰＳ受信部により検出した現在時刻及び現在日時に基づいて、撮影日時を示すタイムスタンプと、撮影場所を示す位置スタンプを作成する。そして、このタイムスタンプおよび位置スタンプの電子署名を作成し、これをそれらスタンプと共に、撮影で得た画像データに付加する。

特許文献３には、製品に対して製造時刻を刻印する装置に対して時刻情報を提供するシステムが開示されている。このシステムは、時刻の経過に伴って変化する経時変化情報を外部サーバから取得し、刻印しようとする現在時刻の情報とそのとき取得した経時変化情報とを合成し、これにより得られた合成データに対して電子署名を施したものを刻印装置に提供する。このシステムでは、経時変化情報として気象情報のように事前の予測が困難な情報を用いている。

特許文献４に開示されたシステムでは、各端末が、相手端末との通話開始時に、時刻認証局サーバから、事前に推測することが困難な一意な背景音を取得する。そして、通話中は、取得した背景音を再生しながら話者の発生音声を混合して送話しつつ、自端末の話者発声及び背景音と相手端末からの話者発声及び背景音を録音する。この文献の第８頁第１７行〜第９頁第１６行には、端末が背景音と合成して録音した会話音の音声データを時刻認証局サーバに送信して時刻認証を受けること、及び、その録音音声データは、背景音の認証時刻以降に発生し、その録音音声データの認証時刻には存在していたことが証明できること、が記載されている。

特開２００２−２１５０２９号公報 特開２００５−０４５４８６号公報 特許第３４７５１４５号明細書 国際公開第２００６／０５４７５４号

データが存在する前の時刻を証明する根拠情報を時刻認証サーバ等の特定の管理主体が管理するサービスに依存する方式では、その特定の管理主体が関与すれば、時刻の証明に不正を加えることが可能になってしまう。

本発明は、データが存在する前の時刻を証明する根拠となる情報を特定の管理主体が管理するサービスから取得する方式よりも、時刻の証明に不正がなされにくいようにすることを目的とする。

請求項１に係る発明は、対象データが生成される際に、ブロックチェーン内の最新のブロックの特徴情報を取得する取得手段と、生成された前記対象データと、前記対象データが生成される際に前記取得手段が取得した前記特徴情報と、が互いに対応するものであることを示す証明情報を時刻証明サービスに登録する登録手段と、を有する情報処理装置である。

請求項２に係る発明は、前記時刻証明サービスが、前記登録手段から登録された前記証明情報を前記ブロックチェーンに登録するものである、ことを特徴とする請求項１に記載の情報処理装置である。

請求項３に係る発明は、前記登録手段は、前記特徴情報と前記対象データとを合成して得られた合成データに対して、前記情報処理装置の秘密鍵を用いて電子署名演算を行って得た署名値を、前記証明情報として前記時刻証明サービスに登録する、ことを特徴とする請求項１又は２に記載の情報処理装置である。

請求項４に係る発明は、ユーザからの指示に応じて、新たな秘密鍵を生成し、前記電子署名演算に用いる秘密鍵として前記登録手段に設定する手段、を更に有する請求項３に記載の情報処理装置である。

請求項５に係る発明は、前回の対象データが生成された際に前記取得手段が取得した特徴情報を前回特徴情報として保持する特徴情報保持手段、を更に有し、前記登録手段は、前記証明情報として、今回生成された前記対象データと、この対象データが生成される際に前記取得手段が取得した前記特徴情報と、前記特徴情報保持手段に保持された前記前回特徴情報と、が互いに対応するものであることを示す証明情報を、前記時刻証明サービスに登録する、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置である。

請求項６に係る発明は、コンピュータを、対象データが生成される際に、ブロックチェーン内の最新のブロックの特徴情報を取得する取得手段、生成された前記対象データと、前記対象データが生成される際に前記取得手段が取得した前記特徴情報と、が互いに対応するものであることを示す証明情報を時刻証明サービスに登録する登録手段、として機能させるためのプログラムである。

請求項７に係る発明は、コンピュータを、対象データ、前記対象データの生成の際のブロックチェーンから取得された最新のブロックの特徴情報、及び、前記対象データと前記特徴情報が互いに対応するものであることを示す証明情報を入手した場合に、前記特徴情報に対応するブロックの時刻情報を前記ブロックチェーンから取得して第１時刻とする第１時刻取得手段、前記証明情報を含んだブロックの時刻情報を前記ブロックチェーンから取得して第２時刻とする第２時刻取得手段、前記対象データが前記第１時刻から前記第２時刻までの間に生成されたことを示す情報を提示する提示手段、として機能させるためのプログラムである。

請求項１、６又は７に係る発明によれば、データが存在する前の時刻を証明する根拠となる情報を特定の管理主体が管理するサービスから取得する方式よりも、時刻の証明に不正がなされにくいようにすることができる。

請求項２に係る発明によれば、特徴情報を取得するブロックチェーンを利用しない時刻証明サービスに証明情報を登録する場合よりも、装置構成を簡素化することができる。

請求項３に係る発明によれば、その証明情報、ひいては対象データが当該情報処理装置で生成されたものであることを署名値により確認することができる。

請求項４に係る発明によれば、登録手段に最初から設定されている秘密鍵をユーザが信頼できない場合等に、新たな秘密鍵に変更することができる。

請求項５に係る発明によれば、前回特徴情報を考慮しない証明情報を登録する構成と比べて、情報処理装置以外の装置によるなりすましが行われた可能性があることを、より容易に検出することができる。

実施形態のシステム構成の例を示す図である。 対象装置が実行する処理の流れの例を説明するための図である。 対象データの生成時期を確認する装置が実行する処理の流れの例を説明するための図である。 変形例１のシステム構成の例を示す図である。 変形例２のシステム構成の例を示す図である。 変形例３のシステム構成の例を示す図である。

図１を参照して、本発明の一実施形態の装置を説明する。

図１に示す対象装置１０は、本実施形態の手法の適用対象の装置である。対象装置１０は、データを生成し、そのデータの生成時期を証明可能にするための処理を実行する。そのデータがある時刻Ｔ１以前には存在していないことが証明でき、かつそのデータが時刻Ｔ１より後の時刻Ｔ２には存在していたことが証明できる場合、そのデータの「生成時期」が時刻Ｔ１からＴ２までの期間であることが証明できる。その証明のために、本実施形態ではブロックチェーン２２を利用する。

ブロックチェーン２２は、ビットコイン（Bitcoin）という仮想通貨決済システムで用いられる分散型の台帳システム、又はこれと同等の分散型台帳システムである。

ビットコインは、ピア・ツー・ピア（Ｐ２Ｐ）型のシステムであり、いくつかの取引情報をブロックにまとめ、それらブロックをＰ２Ｐネットワーク上に分散して記録する。ブロックは時系列順に連鎖（チェーン）構造をなす。各ブロックが直前のブロックのハッシュ値を含むことで、ブロックチェーンの改ざんがきわめて困難となっている。Ｐ２Ｐネットワーク上には、マイナー（採掘者）と呼ばれるノードが複数存在しており、送金者が生成した取引情報はそれらマイナーにブロードキャストされる。それら複数のマイナーのうち、プルーフ・オブ・ワーク（Proof of Work）と呼ばれる計算を最初に解いた者が、直近の一定期間に発行された取引情報をまとめたブロックをブロックチェーンに追加し、その追加についての報酬を得る。プルーフ・オブ・ワークは、ブロックチェーンに追加しようとするブロックに含めるナンス（nonce）という値を調整することで、そのブロックのハッシュ値として、特定の条件（例えば、ハッシュ値の先頭に指定個数以上の０が並ぶ）を満たすハッシュ値を求める計算である。ビットコインでは、その特定条件が、理論的な計算所要時間が１０分となるように管理されている。したがって、ブロックチェーンには、約１０分ごとに新たなブロックが追加されることになる。新たに追加するブロックのハッシュ値は、直前のブロックのハッシュ値や直前のブロックの追加後に発生した取引情報群に対してプルーフ・オブ・ワークの計算に成功して初めて求められるので、事前予測が実質的に不可能である。またブロックチェーンには特定の管理主体は不在であり、ブロックチェーンの信頼性は、そのような特定の管理主体への信頼ではなく、プルーフ・オブ・ワーク等のような不正を防止する仕組み自体が確率論的に高い信頼性を持つことに依拠している。

以上、ビットコインのブロックチェーンについて概説したが、ブロックチェーン２２としては、これに限らず、他のシステムのブロックチェーンを用いてもよい。ビットコイン以外にも、プルーフ・オブ・ワークの仕組みを利用したブロックチェーンを採用しているシステムが存在する。また、プルーフ・オブ・ワークの代わりに、プルーフ・オブ・ステーク（Proof of Stake）等の別のコンセンサス・アルゴリズムを用いるブロックチェーンも存在する。プルーフ・オブ・ステーク等の他のコンセンサス・アルゴリズムでも、ブロックのハッシュ値の事前予測困難性や、特定管理主体に依存せずにシステムの信頼性を担保すること、が実現できる。

存在証明サービス２０は、ユーザからデータの存在証明の依頼を受け付け、その依頼に応じて存在証明のための処理を行うサービスである。存在証明サービス２０は、ユーザからの存在証明依頼の対象であるデータ（あるいはそのデータの特徴情報）をブロックチェーン２２に登録することで、そのデータが存在している時刻を証明可能にする。存在証明サービス２０の具体例としては、Proof of Existenceがある。この例では、存在証明サービス２０は、ブロックチェーン２２へのブロックの追加を行うマイナー（採掘者）ノード群であると捉えてもよい。存在証明サービス２０がProof of Existenceである場合、ブロックチェーン２２は、ビットコインのブロックチェーンである。なお、Proof of Existenceはあくまで一例に過ぎない。存在証明サービス２０としては、ビットコインのブロックチェーンを利用する別のサービス、あるいは、ビットコイン以外のブロックチェーンを利用する別のサービス、を用いてもよい。

対象装置１０の説明に戻ると、対象装置１０が生成するデータは特に限定されない。例えば、対象装置１０は、デジタルカメラのように画像（静止画）データや動画データを生成するものであってもよいし、録音機のように音声データを生成するものであってもよい。また撮影機能や録音機能を併せ持つスマートフォン等の装置であってもよい。また、位置、速度、加速度の物理的な計測データや、濃度等の化学的な計測データ等のように、画像や音声以外のデータであってもよい。

制御部１２は、対象装置１０の動作全体を制御するシステムである。例えば、対象装置１０がデジタルカメラである場合、制御部１２は、撮影条件やシャッター押下等の指示の受付等を行うユーザインタフェース処理や、それら指示に応じて対象装置１０の各部の動作を制御する処理、撮影された画像を内蔵ストレージ等に保存する処理等を実行する。制御部１２が実行する制御処理は、対象装置１０の種類に依存する。

制御部１２は、対象装置１０の種類に応じた一般的な制御に加え、耐タンパモジュール１００に対して存在証明可能なデータの生成を指示する機能、及び根拠情報取得部１４に根拠情報の取得を指示する機能を有する。

典型的には、制御部１２は、ＣＰＵ（中央演算装置）で制御プログラムを実行することにより実現される。

根拠情報取得部１４は、制御部１２からの取得指示に応じて、ブロックチェーン２２に含まれる最新のブロックの特徴情報を、根拠情報として取得する。ブロックの特徴情報は、例えば、そのブロックのハッシュ値である。前述のように、ブロックのハッシュ値は、そのブロックがブロックチェーン２２に追加される時点までは実質的に予測不能な値である。また、ブロックの特徴情報として、ハッシュ値以外の別の情報を用いることも考えられる。例えば、ブロック中のナンスの値は、ハッシュ値と同様、そのブロックがブロックチェーン２２に追加されるまでは実質上予測不能な値なので、そのナンスをブロックの特徴情報として用いてもよい。ナンスだけでは偶然の一致が懸念される場合には、ナンスと、ブロック中の他の情報、例えばタイムスタンプ、取引情報のうちの先頭のもの、等との組を、そのブロックの特徴情報としてもよい。本実施形態では、根拠情報取得部１４が取得した特徴情報を、存在証明の対象のデータが存在する前の時刻を特定する「根拠情報」として用いる。以下では、根拠情報として、ブロックチェーン２２の最新ブロックのハッシュ値を用いる場合を代表例にとって説明を行う。

根拠情報取得部１４は、例えば、ブロックチェーン２２の操作のためのＡＰＩ（アプリケーション・プログラム・インタフェース）を用いて、ブロックチェーン２２から最新ブロックの特徴情報（例えばハッシュ値）を取得する。根拠情報取得部１４は、例えば、その取得の処理のプログラムをＣＰＵで実行することにより実現される。

なお、図１の例では、根拠情報取得部１４は耐タンパモジュール１００の外に設けられているが、根拠情報取得部１４を耐タンパモジュール１００内に設けてもよい。根拠情報取得部１４を耐タンパモジュール１００内に設けることで、ブロックの特徴情報の取得の段階で不正が行われる可能性が低減される。

耐タンパモジュール１００は、耐タンパ性を持つモジュールである。このモジュール内のデータ生成部１０２や秘密鍵保持部１０８等の各処理部を構成している各ハードウエア、各ソフトウエア、それらハードウエアが保持しているデータは、そのモジュールの外装パッケージ、及びそれら各ハードウエアの個別のパッケージを破壊しなければアクセスすることができず、解析やデータ改変が不可能となっている。また、これに限らず他の方式の耐タンパ性、例えばパッケージが破られたことを検知すると内部のデータ（例えば秘密鍵）を消去するといった形の耐タンパ性を持つものであってもよい。データ生成部１０２や秘密鍵保持部１０８等の各処理部が耐タンパモジュール１００により保護されているので、データ生成部１０２が生成するデータを別のデータに入れ替えられたり、秘密鍵保持部１０８内の秘密鍵が盗難したりする不正が事実上不可能になっている。

耐タンパモジュール１００内には、データ生成部１０２、データ合成部１０４、署名処理部１０６、秘密鍵保持部１０８及び登録処理部１１０の各処理部が設けられている。耐タンパモジュール１００に耐タンパ性を持たせているのに加え、そのモジュール内のデータ生成部１０２等の各処理部に個別に耐タンパ性を持たせてもよい。

データ生成部１０２は、存在証明の対象となるデータを生成する機構である。典型的には、データ生成部１０２は、物理的刺激や化学的刺激を電気信号に変換し、データとして出力するセンサである。例えば、デジタルカメラにおけるＣＣＤ撮像素子、録音機におけるマイク、などがデータ生成部１０２の具体例である。

データ合成部１０４は、データ生成部１０２が生成した、存在証明の対象であるデータ（以下「対象データ」と呼ぶ）と、その生成に対応付けて根拠情報取得部１４が取得した根拠情報（最新ブロックのハッシュ値）とを合成して、合成データを生成する。両データの合成の仕方に特に限定はない。例えば、対象データのテキスト表現の末尾に根拠情報のテキスト表現を付加するという単純な合成方式でもよい。なお、データ合成部１０４が用いる合成方式は公開しておき、対象装置１０以外の装置、例えば対象データの生成時期を確認するプログラムが、その合成方式を利用できるようにしておく。

秘密鍵保持部１０８は、公開鍵方式における対象装置１０に固有の秘密鍵を保持する。この秘密鍵は、耐タンパモジュール１００の外に出ないよう保護されている。この秘密鍵に対応する公開鍵は、例えば公開鍵証明書に含まれる形で耐タンパモジュール１００の外部に出力してもよく、また公開のデータベースに登録して検索できるようにしてもよい。

署名処理部１０６は、データ合成部１０４から出力された合成データについて、秘密鍵保持部１０８内の秘密鍵を用いてデジタル署名を計算する。すなわち、署名処理部１０６は、例えばその合成データのハッシュ値を計算し、計算したハッシュ値をその秘密鍵で暗号化することで、デジタル署名の署名値を求める。この署名値は、対象データと根拠情報とを合成した合成データから求められる値なので、対象データと根拠情報とが互いに対応するものであることを証明する値として用いることができる。例えば、対象データと根拠情報と署名値とが入手できた場合、対象データと根拠情報から合成データを生成し、署名値を公開鍵で復号した値と、その合成データ又はその合成データのハッシュ値とが一致していれば、それら対象データ、根拠情報及び署名値が相互に対応しているものであると判定できる。なお、対象装置１０が、少ないデータ量の対象データを生成する種類のものである場合、署名処理部１０６は、合成データのハッシュ値を求めずに、その合成データを秘密鍵で直接暗号化することで署名値を計算してもよい。

登録処理部１１０は、署名処理部１０６が求めた署名値を、存在証明サービス２０に登録するための処理を実行する。登録処理部１１０は、例えば存在証明サービス２０のＡＰＩを用いて、その署名値を含む取引（トランザクション）情報を存在証明サービス２０に送信する（例えばマイナー群に向けてブロードキャストする）。送信されたその取引情報は、プルーフ・オブ・ワークに勝利したマイナーにより、最新のブロックに含まれる形で、ブロックチェーン２２に追加される。その最新ブロックが追加された時刻を示すタイムスタンプは、その署名値の元になった対象データの生成より時間的に後である。したがって、そのタイムスタンプは、その対象データが既に存在している時点の時刻を示す。

なお、存在証明サービス２０への取引情報の登録が失敗する場合もある。この場合、対象データを破棄して登録処理全体を取りやめてもよいし、登録が成功するまで取引情報の送信を繰り返すようにしてもよい。

また登録処理部１１０は、署名値を含む取引情報を存在証明サービス２０に登録できた場合、対象データと、その対象データの生成時期の確認に用いる各種情報を制御部１２へ出力する。対象データの生成時期の確認に用いる各種情報には、例えば、署名値、その署名値の元になった根拠情報（根拠情報取得部１４がブロックチェーン２２から取得した情報）等が含まれる。図１に示す例では、登録処理部１１０は、対象データＡ、根拠情報Ｂ、署名値Ｃ、及びその署名値Ｃの計算に用いた秘密鍵に対応する公開鍵証明書、を１つのファイル３０にパッケージしたものを制御部１２に出力する。このファイル３０が、制御部１２からのデータ生成・登録指示に対する制御部１２への応答である。制御部１２は、受け取ったファイル３０を、対象装置１０の内蔵ストレージ等に保存する。

次に、図２に示す具体例を参照して、対象装置１０が実行するデータ生成及び登録処理の流れを説明する。

図２に示す例では、ブロックチェーン２２には１０分ごとに新たなブロックが追加され、３月５日の１０時０分の時点では、ブロックチェーン２２の末尾のブロック（すなわち最新ブロック）が、ブロックＩＤ（識別子）が「1392」のブロックであるとする。この例では、ブロックチェーン２２内の各ブロックには、ブロックＩＤ、タイムスタンプ、ハッシュ値、ナンス（Nonce）及び取引情報が含まれている。タイムスタンプは、このブロックが生成（及びブロックチェーン２２に追加）された時刻を示す。ハッシュ値は、当該ブロックのハッシュ値であり、前述の通りプルーフ・オブ・ワーク等の処理により特定された、特定条件を満たすハッシュ値である。ナンスは、そのプルーフ・オブ・ワーク等の処理で特定条件を満たすハッシュ値を求めるのに使った値である。取引情報は、前述の通り、当該ブロックの直前のブロックの生成以降に生じた取引の内容を示す情報である。なお、ブロックには、直前のブロックのハッシュ値等、他の情報も含まれ得るが、図示は省略した。

３月５日の１０時９分の時点で、ユーザが、対象装置１０（この例ではデジタルカメラであるとする）のシャッターボタンを押下して、撮影を指示したとする（Ｓ１０）。この指示を受けた制御部１２は、データ生成部１０２に対してデータ生成すなわち画像の撮影を指示すると共に、根拠情報取得部１４に対して根拠情報の取得を指示する。ここで、制御部１２は、データ生成部１０２へのその撮影指示と、根拠情報取得部１４へのその取得指示とを、一定の時間的関係をもって互いに対応付けて、発する。この一定の時間的関係は、例えば、それら両指示が実質的に「同時」に発行されるという関係である。根拠情報の利用目的（対象データがまだ存在していない時刻を証明すること）からして、根拠情報取得部１４への取得指示の発行は、撮影指示の発行より少し前か、同時か、少し遅れる程度とする。

なお、制御部１２に不正がなされる可能性を考慮した構成も考えられる。この構成では、根拠情報取得部１４を耐タンパモジュール１００内に組み込む。耐タンパモジュール１００内のプロセッサが実行する制御プログラムは、制御部１２から撮影指示を受け取ると、データ生成部１０２及び根拠情報取得部１４に対して一定の時間的関係で動作指示を発する。制御プログラムは耐タンパモジュール１００内にあるので、撮影指示と根拠情報の取得指示との時間的関係等に対する不正な改変を受けにくい。

撮影指示を受けたデータ生成部１０２は、撮影処理を行い、対象データＡとして画像データを生成する（Ｓ１２）。また、取得指示を受けた根拠情報取得部１４は、ブロックチェーン２２から最新のブロックの特徴情報であるハッシュ値を、根拠情報Ｂとして取得する（Ｓ１４）。この取得の時点（３月５日１０時９分）でブロックチェーン２２の最新ブロックはブロックＩＤ「1392」のブロックなので、根拠情報Ｂとしては、そのブロック「1392」のハッシュ値「9d65a302」が取得される。

データ合成部１０４は、生成された対象データＡと取得された根拠情報Ｂとを合成して、合成データを生成する（Ｓ１６）。署名処理部１０６は、対象装置１０の秘密鍵を用いて、その合成データのデジタル署名の署名値Ｃを計算する（Ｓ１８）。例えば、合成データのハッシュ値を計算し、そのハッシュ値をその秘密鍵で暗号化することで署名値を求める。

署名値Ｃが計算されると、登録処理部１１０が、例えば、取引情報中のユーザ側で自由に利用可能なあらかじめ定められた項目にその署名値Ｃを含め、その取引情報を存在証明サービス２０に送る（Ｓ２０）。この後、存在証明サービス２０内でプルーフ・オブ・ワーク等の計算を最初に解いたマイナーが、その取引情報を含むブロックをブロックチェーン２２の末尾に追加する。

図示例では、その署名値Ｃを含む取引情報の登録が根拠情報Ｂの由来元のブロック「1392」の次のブロック「1393」の生成までに間に合わず、その取引情報は更に次のブロック「1394」に登録された。ブロック「1394」内の取引情報の項目に含まれる値「889c903e5f31203a56d9」が、Ｓ１８で求められた署名値Ｃである。図２では、煩雑さを避けるために、ブロックの取引情報の項目には、１つの取引情報中の署名値Ｃのみを示したが、取引情報には署名値Ｃ以外の項目が含まれていてもよいし、その項目内に複数の取引情報が含まれていてもよい。なお、署名値Ｃを含む取引情報の登録のための処理がもっと早く実行され、次のブロック「1393」の生成までに間に合えば，その取引情報なそのブロック「1393」に登録されることになる。

登録処理部１１０がＳ２０で送信した取引情報が存在証明サービス２０により正しく受信されると、登録処理部１１０は先ほど生成した対象データＡ、根拠情報Ｂ、署名値Ｃを互いに対応付けて（例えば１つのファイルにパッケージして）制御部１２に出力する（Ｓ２２）。制御部１２はその出力データを、内蔵ストレージに保存したり、あらかじめ指定されたサーバに送って格納したりする。

以上に説明した処理により、対象装置１０が生成した対象データＡの生成時期が特定可能な情報がブロックチェーン２２に登録される。すなわち、Ｓ２０で対象装置１０から存在証明サービス２０に送信した取引情報がブロックチェーン２２に登録された時刻、すなわちその取引情報を含んだブロック「１３９４」のタイムスタンプ「３／５ １０：２０」には、その対象データＡは存在している。したがって、このタイムスタンプは、生成時期の末尾Ｔ２として用いることができる。また、その取引情報には署名値Ｃが含まれ、この署名値Ｃは対象データＡと根拠情報Ｂとの合成データに由来する。したがって、対象データＡ、根拠情報Ｂ及び署名値Ｃを得た者は、公開されている対象装置１０の公開鍵を用いることでその署名値Ｃを検証できる。署名値Ｃが正しいと検証できると、対象データＡがその公開鍵に対応する対象装置１０で生成されたこと、その署名値Ｃと共に取得した対象データＡと根拠情報Ｂに改ざんが加えられていないこと、が確認できる。この根拠情報Ｂは、ブロックチェーン２２内のブロック「１３９２」内の情報（ハッシュ値）なので、ブロックチェーン２２から検索できる。そのブロック「１３９２」は、ユーザが対象装置１０に対して撮影指示を行った時点で既に存在しているので、そのブロックのタイムスタンプ「３／５ １０：００」の示す時点では対象データＡはまだ存在していない。したがって、このタイムスタンプは、生成時期の先頭Ｔ１として用いることができる。このように、ブロックチェーン２２の登録情報を用いることで、対象データＡが時刻Ｔ１からＴ２までの間に生成されたことが確認できる。

しかも、ブロックチェーン２２内の各ブロックが正しいものであることは、プルーフ・オブ・ワーク又はプルーフ・オブ・ステーク等といった、ブロックチェーン２２の基盤をなすプロトコルにより保証されている。すなわち、信頼できる特定の管理主体が存在しなくても、ブロックチェーン２２から取得した情報は正しいと信頼することができる。

この例では約１０分ごとにブロックが追加されるビットコインのブロックチェーンを用いているため、対象データの生成時期の絞り込みはそれらブロックの時間幅約１０分が限界である。しかし、ブロックの追加をもっと短い間隔で行うブロックチェーン２２を用いて、特定できる生成時期の幅をもっと短くすることもできる。

図２の例では、ユーザが行った撮影指示をトリガとして、対象データＡの生成（Ｓ１２）と根拠情報Ｂの取得（Ｓ１４）を行ったが、Ｓ１２及びＳ１４のトリガはユーザからの指示に限らない。例えば、対象装置１０が監視カメラのように、あらかじめ定められた基準で自動的に決定されるタイミングで対象データ（例えば監視カメラで撮影した画像）を生成する装置の場合、自動的に決定されるその生成タイミングの到来をＳ１２及びＳ１４のトリガとして用いる。

次に、対象装置１０が生成した対象データＡの生成時期を確認する処理の手順の一例を、図３を参照して説明する。この処理は、例えばパーソナルコンピュータやスマートフォン等のコンピュータで実行可能なアプリケーションプログラム又はその一部として実装可能である。

この処理では、まずコンピュータは、対象データＡと、その対象データＡに対応する根拠情報Ｂ及び署名値Ｃを取得する（Ｓ３０）。コンピュータは、対象装置１０が出力したファイル３０（図１参照）を入手した場合、そのファイル３０の中からそれらデータをすべて取得できる。

次にコンピュータは、取得した署名値Ｃを検証する（Ｓ３２）。この検証処理では、対象データＡと根拠情報Ｂとを、対象装置１０のデータ合成部１０４と同じ合成方式で合成して合成データを生成し、この合成データのハッシュ値Ｄを計算する。一方、署名値Ｃを、署名者の公開鍵を用いて復号する。ここで用いる公開鍵は、ファイル３０内に含まれている。あるいは、ファイル３０内の署名値Ｃにはその署名値Ｃを署名した署名者の情報が付随しており、公開鍵の情報なネットワーク上に公開されているので、その署名者に対応する公開鍵をネットワークから取得すればよい。そして、署名値Ｃの復号の結果得られた値Ｅが、合成データのハッシュ値Ｄと一致すれば、署名値Ｃが正しいと判定する（検証成功）。

Ｓ３２の署名値Ｃの検証が失敗した場合にはエラー処理を実行する（Ｓ３３）。

一方、署名値Ｃの検証が成功した場合には、コンピュータは、ブロックチェーン２２から、根拠情報Ｂを「ハッシュ値」として含むブロック（すなわち当該ブロックのハッシュ値が根拠情報Ｂの値に等しい）の、タイムスタンプの値を取得する（Ｓ３４）。この値が、対象データＡの生成時期の先端Ｔ１である。また、コンピュータは、その署名値Ｃを取引情報として含んだブロックをブロックチェーン２２から取得し、取得したブロックのタイムスタンプの値を取得する（Ｓ３６）。この値が、対象データＡの生成時期の末尾Ｔ２である。そしてコンピュータは、対象データＡが、時刻Ｔ１からＴ２までの期間内に生成されたことを示す情報を、ユーザに提示する（Ｓ３８）。

以上に説明した例では、対象装置１０は、対象データＡと根拠情報Ｂとを合成した合成データのハッシュ値から求めた署名値Ｃを存在証明サービス２０（ブロックチェーン２２）に登録した（図２のＳ２０）。しかし、これは一例に過ぎない。図２のＳ２０で、署名値Ｃの代わりに、合成データそのもの、又はその合成データのハッシュ値を、存在証明サービス２０に登録してもよい（他のステップは図２と同じ）。合成データそのもの又は合成データのハッシュ値を登録する方式の場合、対象データＡの生成時期の確認処理（図３参照）では、Ｓ３６において、署名検証（Ｓ３２）の際に求めた合成データ又はその合成データのハッシュ値を取引情報として含んだブロックを、ブロックチェーン２２から取得すればよい。それ以外の各ステップは図３に示したものと同じでよい。

なお、対象装置１０が生成するすべての対象データに対して生成時期の証明が必要であるとは限らない。生成する対象データに、生成時期の証明が必要なものとそうでないものがある場合、例えばユーザから対象データの生成の指示を受ける際、制御部１２は、生成時期の証明が必要か否かの指定をユーザから求め、生成時期の証明が必要と指定された場合には、耐タンパモジュール１００に上述の処理を実行させるようにすればよい。また生成時期の証明が不要と指定された場合には、制御部１２は、根拠情報取得部１４、データ合成部１０４、署名処理部１０６、登録処理部１１０に対して存在証明サービス２０への登録のための処理を実行させずに、単にデータ生成部１０２に対象データを生成させればよい。

＜変形例１＞
以上に説明した例では、登録処理部１１０が署名値Ｃ（又は合成データ等）を登録する存在証明サービス２０は、その署名値等を、対象データがまだ存在していない時点を規定する根拠情報Ｂの取得元のブロックチェーン２２に登録していた。この方式では、対象装置１０内の、対象データＡの生成時期の証明のための手段は、ブロックチェーン２２のプロトコルに対応していれば足りる。ただし、この方式は一例に過ぎない。

この代わりに、図４に例示するように、根拠情報Ｂの提供元のブロックチェーン２２を利用しない存在証明サービス２０Ａを用いてもよい。この例では、存在証明サービス２０Ａは、対象装置１０から受信した署名値Ｃ等の情報を、その存在証明サービス２０Ａ自身の方式で、その受信の時刻に対応付けて記録する。存在証明サービス２０Ａは、ブロックチェーン２２とは別のブロックチェーンに署名値Ｃ等を登録するものであってもよいし、ブロックチェーン以外のそのサービスの固有のデータベースに署名値Ｃ等を登録するものであってもよい。

対象データＡの生成時期を確認する装置は、図３の手順のうち、Ｓ３４では図１の実施形態同様ブロックチェーン２２から根拠情報Ｂを取得すればよいが、Ｓ３６では存在証明サービス２０Ａから署名値Ｃ等を登録した時刻Ｔ２の情報を取得する。この時刻Ｔ２はブロックチェーン２２内の情報ではなく、それとは別体の存在証明サービス２０Ａが保証する情報である。

この図４の変形例でも、対象データＡがまだ存在しない時点を特定する根拠情報Ｂについては、信頼できる特定の管理主体がいなくても、登録されている情報の信頼性が保証されるブロックチェーン２２から入手できる。

＜変形例２＞
上記実施形態の構成では、秘密鍵保持部１０８に記憶された秘密鍵は、耐タンパモジュール１００等により外部からの不正アクセスから守られている。しかし、秘密鍵保持部１０８内の秘密鍵は、対象装置１０の製造者によって書き込まれるため、その秘密鍵が対象装置１０の外部に漏れていないかどうかは、その製造者次第ということになる。すなわち、その製造者から秘密鍵が漏洩したり、製造者自身が不正にその秘密鍵を流用したりした場合、対象装置１０とは別の装置が同じ秘密鍵を使って、虚偽のデータからその対象装置１０の電子署名を生成することが可能になる。

このような一種のなりすましに対抗する一つの方法として、対象装置１０のユーザが任意のタイミングで秘密鍵保持部１０８内に保持される秘密鍵を再設定できるようにすることが考えられる。すなわち、図５に示すように、対象装置１０に秘密鍵再設定部１１２を設けておき、ユーザが対象装置１０に秘密鍵の再設定を指示すると、秘密鍵再設定部１１２が乱数を生成し、それを秘密鍵とする。ここで乱数には、例えば（データ生成部１０２等の）内蔵センサが生成したデータや時刻などを種にした擬似乱数を用いるなどとすることにより、秘密鍵の生成方法が外部からは推定できないようにする。秘密鍵再設定部１１２は、このとき生成した秘密鍵を秘密鍵保持部１０８内の既存の秘密鍵と置き換えると共に、その秘密鍵に対応する公開鍵の情報を登録処理部１１０等に設定する（あるいは、その公開鍵についての公開鍵証明書を取得し、これを登録処理部１１０に設定する）ことにより、その公開鍵の情報が、対象装置１０の出力するファイル３０に含まれるようにする。図５の例では、秘密鍵再設定部１１２は耐タンパモジュール１００内に設けられているので、秘密鍵の再設定自体が外部から保護される。

なお、図５には、ブロックチェーン２２を利用する存在証明サービス２０を用いる場合を例示したが、この変形例２の構成は、上記変形例１に示したブロックチェーン２２を利用しない存在証明サービス２０Ａを用いる場合にも適用可能である。また、このことは以下に示す変形例についても同様である。

＜変形例３＞
ここで、上述した変形例２の秘密鍵再設定部１１２はユーザの指示に応じて乱数を発生し、これを秘密鍵として設定しているが、秘密鍵再設定部１１２が本当に乱数を発生しているのかはユーザには分からない。例えば、製造者ならば自分の望む「乱数」を発生するよう秘密鍵再設定部１１２を製造することも可能であり、仮にこのようになされていると、製造者は対象装置１０の秘密鍵と同じ秘密鍵を入手してなりすましを行うことが可能になる。以下では、秘密鍵保持部１０８に保持されている秘密鍵と同じ秘密鍵を用いたなりすましを検知する方式を提案する。

この方式では、図６に示すように、対象装置１０内に前回根拠保持部１１４を設ける。前回根拠保持部１１４は、前回生成した対象データについて根拠情報取得部１４が取得した根拠情報を保持する機構であり、フラッシュメモリ等のように、電源が切られても記憶内容を保持可能な記憶装置から構成される。データ合成部１０４は、データ生成部１０２が今回生成した対象データＡと、これに対応して根拠情報取得部１４が取得した今回の根拠情報Ｂ２と、前回根拠保持部１１４が保持している前回の根拠情報Ｂ１とを合成して合成データを生成する。そして、この合成データに対して署名処理部１０６が、秘密鍵を用いて電子署名を行い、これにより得られた署名値Ｃを登録処理部１１０Ａが存在証明サービス２０に登録する。この登録処理の後、登録処理部１１０Ａは、対象データＡ、前回の根拠情報Ｂ１、今回の根拠情報Ｂ２、署名値Ｃ、公開鍵証明書を含むファイル３０Ａを制御部１２に出力する。署名値Ｃの存在証明サービス２０への登録の後、データ合成部１０４は、今回の根拠情報Ｂ２を前回根拠保持部１１４内の前回の根拠情報Ｂ１に上書きする。これにより、次に生成される対象データＡについては、今回取得した根拠情報Ｂ２が「前回の根拠情報Ｂ１」として、署名値Ｃやファイル３０Ａに反映されることになる。

このように、この変形例３では、存在証明サービス２０に登録される署名値Ｃ、及び出力された対象データＡに対応付けられる情報（ファイル３０Ａ）に、今回の根拠情報Ｂ２だけでなく前回の根拠情報Ｂ１も反映される。これにより、例えば、前回の根拠情報Ｂ１は同じだが今回の根拠情報Ｂ２は異なるファイル３０Ａが世の中から２以上見つかった場合、対象装置１０内の秘密鍵と同じ秘密鍵を用いたなりすましが発生している可能性があると判断することができる。

すなわち、同じ秘密鍵を用いたなりすましを行う者は、対象装置１０と同じ処理を行う別の装置を用意し、正当な対象装置１０が出力したファイル３０Ａを入手し、このファイル３０Ａの中の今回の根拠情報αを自分の装置の前回根拠保持部１１４に格納し、その装置の利用を開始すると考えられる。この根拠情報αは正当な対象装置１０に由来するので、なりすまし者の装置がその後存在証明サービス２０に登録するデータの信用が増すからである。このように構成されたなりすまし者の装置が新たにデータを生成してそれを存在証明サービス２０に登録すると、対象装置１０に由来するその根拠情報αを前回の根拠情報Ｂ１として含み、新たに取得した今回の根拠情報Ｂ２を更に含んだファイル３０Ａが生成され、出力されることになる。

その一方で、正当な対象装置１０が次の対象データを生成すると、その根拠情報αを前回の根拠情報Ｂ１として含み、その対象データの生成の際に新たに取得した根拠情報を今回の根拠情報Ｂ２として含むファイル３０Ａが生成される。この結果、同じ根拠情報αを含んだファイルが世の中に２つ存在することになる。なりすまし者がいなければ、このような事態は生じないので、このような事態が生じた場合には、対象装置１０内の秘密鍵と同じ秘密鍵を持ったなりすまし者が存在する可能性があることになる。

また、存在証明サービス２０に対して、署名値Ｃだけでなく、前回の根拠情報Ｂ１、今回の根拠情報Ｂ２も合わせて登録する構成とすれば、世の中に流通するファイル３０Ａを監視しなくても、存在証明サービス２０に登録された情報から、前回の根拠情報が同じデータが複数存在することを検出できる。

なお、ファイル３０Ａ（あるいは存在証明サービス２０に登録した情報）の中の前回の根拠情報Ｂ１及び今回の根拠情報Ｂ２等が正しい値（改ざん等が加えられていない値）であるかどうかは、それらの情報に対応する署名値Ｃにより検証可能である。

ちなみに、図１の実施形態のように前回の根拠情報を用いない構成の場合、正当な対象装置１０が生成した対象データと、なりすまし者の装置が生成したデータとが、同じ「前回の根拠情報」に対応付けられているという、検知しやすい目印がないため、なりすましの検出は困難である。

以上に例示した対象装置１０は、コンピュータにそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）等の固定記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ＨＤＤ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。また、耐タンパモジュール１００は、制御部１２の処理を実行するＣＰＵとは別のプロセッサにより、上述した当該モジュールの処理の全部又は一部をその別プロセッサにより実行してもよい。

１０ 対象装置、１２ 制御部、１４ 根拠情報取得部、２０，２０Ａ 存在証明サービス、２２ ブロックチェーン、３０，３０Ａ ファイル、１００ 耐タンパモジュール、１０２ データ生成部、１０４ データ合成部、１０６ 署名処理部、１０８ 秘密鍵保持部、１１０，１１０Ａ 登録処理部、１１２ 秘密鍵再設定部、１１４ 前回根拠保持部。

Claims (7)

1. 対象データが生成される際に、ブロックチェーン内の最新のブロックの特徴情報を取得する取得手段と、
   生成された前記対象データと、前記対象データが生成される際に前記取得手段が取得した前記特徴情報と、が互いに対応するものであることを示す証明情報を時刻証明サービスに登録する登録手段と、
   を有する情報処理装置。
2. 前記時刻証明サービスが、前記登録手段から登録された前記証明情報を前記ブロックチェーンに登録するものである、ことを特徴とする請求項１に記載の情報処理装置。
3. 前記登録手段は、前記特徴情報と前記対象データとを合成して得られた合成データに対して、前記情報処理装置の秘密鍵を用いて電子署名演算を行って得た署名値を、前記証明情報として前記時刻証明サービスに登録する、ことを特徴とする請求項１又は２に記載の情報処理装置。
4. ユーザからの指示に応じて、新たな秘密鍵を生成し、前記電子署名演算に用いる秘密鍵として前記登録手段に設定する手段、を更に有する請求項３に記載の情報処理装置。
5. 前回の対象データが生成された際に前記取得手段が取得した特徴情報を前回特徴情報として保持する特徴情報保持手段、を更に有し、
   前記登録手段は、前記証明情報として、今回生成された前記対象データと、この対象データが生成される際に前記取得手段が取得した前記特徴情報と、前記特徴情報保持手段に保持された前記前回特徴情報と、が互いに対応するものであることを示す証明情報を、前記時刻証明サービスに登録する、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. コンピュータを、
   対象データが生成される際に、ブロックチェーン内の最新のブロックの特徴情報を取得する取得手段、
   生成された前記対象データと、前記対象データが生成される際に前記取得手段が取得した前記特徴情報と、が互いに対応するものであることを示す証明情報を時刻証明サービスに登録する登録手段、
   として機能させるためのプログラム。
7. コンピュータを、
   対象データ、前記対象データの生成の際のブロックチェーンから取得された最新のブロックの特徴情報、及び、前記対象データと前記特徴情報が互いに対応するものであることを示す証明情報を入手した場合に、
   前記特徴情報に対応するブロックの時刻情報を前記ブロックチェーンから取得して第１時刻とする第１時刻取得手段、
   前記証明情報を含んだブロックの時刻情報を前記ブロックチェーンから取得して第２時刻とする第２時刻取得手段、
   前記対象データが前記第１時刻から前記第２時刻までの間に生成されたことを示す情報を提示する提示手段、
   として機能させるためのプログラム。