本出願は、平成23年(2011年)10月14日に出願された日本特許出願特願2011−227308の優先権を主張し、その内容を参照することにより、本出願に取り込む。
以下に、本発明の一実施形態について、図1〜図9の図面を用いて説明する。
まず、本発明の第一の実施形態の構成について、図1を用いて説明する。
図1は、本発明の第一の実施形態が適用されたデータ処理システムの一例を示すブロック図である。
本実施形態では、利用者の計算機に対して業務アプリケーションやデータベース等を提供するアプリケーションサーバ102−1〜アプリケーションサーバ102−L(以下、アプリケーションサーバの総称の符号は102とする)と、アプリケーションサーバ102のログを収集して管理するログ管理サーバ101と、それぞれのサーバを接続するネットワーク103からなる。
次に、図1のシステムを構成する各装置について説明する。
まず、図2を用いて、ログ管理サーバ101を説明する。図2はログ管理サーバ101の機能要素の一例を示すブロック図である。
ログ管理サーバ101は、アプリケーションサーバ102から送付されたログデータからログレコードを生成したり、ユーザからの要求に応じてログレコードの検証及び真正性の判定を行う処理部201と、ログ管理サーバ101が生成したログデータや処理に必要な鍵等のデータを記憶する記憶部202と、ユーザ又は管理者からの入力を受け付ける入出力部210と、アプリケーションサーバ102から出力されるログデータを受取る通信部211を有する。なお、以下では、アプリケーションサーバ102が出力するログをログデータとし、ログ管理サーバ101で後述するように処理したログをログレコードとする。
処理部201はログデータとログレコードのハッシュ値を合わせたデータに署名を付与する署名生成部203と、ログレコードの署名を検証する署名検証部204と、ログレコードに含まれるハッシュ値と当該ハッシュ値の元となるログレコードを比較して検証するハッシュ値比較部205と、ログレコードのハッシュ値を取りハッシュ値を生成するハッシュ値生成部206と、これらを制御する制御部207を有する。
記憶部202は、署名処理などが終了したログを記憶するログレコード保持部208と署名生成、検証を行なうための秘密鍵と証明書及び公開鍵を保持しておく、秘密鍵・証明書保持部209を有する。秘密鍵・証明書はたとえば、耐タンパー装置に保存しておくことも考えられる。
なお、図示はしないが、署名検証部204がハッシュ値比較部205を含み、署名生成部203がハッシュ値生成部206を含んでいてもよい。
次に、図3を用いて、アプリケーションサーバ102を説明する。図3はアプリケーションサーバ102の機能要素の一例を示すブロック図である。
アプリケーションサーバ102はアプリケーションを実行し、ログを出力するための処理部301と、記憶部302と、ユーザからの入力を受け付ける入出力部307と、ログ管理サーバ101や他のアプリケーションサーバと通信を行うための通信部308を有する。
処理部301はアプリケーションサーバ102で生成されるログをログ管理サーバ101に送付する処理を行うログ出力処理部303と、アプリケーションの実行などを行うアプリケーション処理部304と、これらを制御する制御部305を有する。
記憶部302はアプリケーションを実行するために必要なデータを記憶するアプリケーションデータ保持部306を有する。
なお、図2、図3に例示する、ログ管理サーバ101、アプリケーションサーバ102の処理部201、301は、例えば、図4に示すような、CPU401と、メモリ402と、ハードディスク等の外部記憶装置404と、インターネットやネットワーク103を介して他装置と通信を行なうための通信装置403と、キーボードやマウス等の入力装置405と、表示装置やプリンタ等の出力装置406と、可搬性を有する記憶媒体408から情報を読み取る読取装置407と、これらの各装置間を接続する内部通信線409を備えた、一般的な電子計算機において、CPU401がメモリ402上にロードされた所定のプログラムを実行することにより、具現化できる。
上記各装置は、CPU401と記憶装置とを備える一般的な計算機、あるいは一般的な計算機と同等の機能を有するプログラムやハードウェアを用いて実現することができる。
そして、CPU401が外部記憶装置404からメモリ402上にロードされた所定のプログラムを実行することにより、上述の各処理部を実現できる。すなわち、通信部211、308は、CPU401が通信装置403を利用することにより実現される。入出力部210、307は、CPU401が入力装置405や出力装置406や読取装置407を利用することにより実現される。また、記憶部202、302は、CPU401がメモリ402や外部記憶装置404を利用することにより実現される。また、処理部201、301は、CPU401のプロセスとして実現される。
これらのプログラムは、あらかじめ、上記電子計算機内のメモリ402または外部記憶装置404に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体408から、または通信媒体(ネットワーク103など、またはそれらの上を伝搬する搬送波やデジタル信号など)を介して他の装置から、導入されてもよい。
また、本実施例では、図1〜図3に示されるような構成により実現できるとしているが、本発明は当該構成に限定されるものではない。ログ管理サーバ101だけでなく、アプリケーションサーバ102にログレコードを管理する機能があってもよい。
次に、図5を用いてログ管理サーバ101のログレコード保持部208に保持されるログレコードの詳細について説明する。本実施形態では、一例として、複数個前のログレコードとして3個前のログレコードと6個前のログレコードを含む場合を説明する。なお、これらのログレコードはログ管理サーバ101の署名生成部203で生成される。
ひとつのログレコード501は、アプリケーションサーバ102から送信されたログデータ本体であるログデータ502と、ログデータ502を表すユニークなIDであるデータID503と、1個前のログレコードのハッシュ値である1個前のハッシュ値504と、1個前のハッシュ値504を表すユニークなIDである連結用ID1505と、3個前のログレコードのハッシュ値である3個前のハッシュ値506と、3個前のハッシュ値を表すユニークなIDである連結用ID2507と、6個前のログレコードのハッシュ値である6個前のハッシュ値508と、6個前ハッシュ値を表すユニークなIDである連結用ID3509(以後、連結用ID1〜連結用ID3の総称を『連結用ID』と称する)と、各フィールド502〜509に対してデジタル署名を付与した署名510からなる。
以後、a番目のログレコードをログレコードSaと称する。また、以下、ログレコードS8を例に具体的に説明する。ログレコードS8には、ログデータ502であるM8とログデータM8のデータID503である8と、1個前のハッシュ値504であるH(S7)(『H(S7)』はS7から計算したハッシュ値を示す。以下同様)と連結用ID1である「7」と、3個前のハッシュ値506であるH(S5)と連結用ID2である「5」と、6個前のハッシュ値508であるH(S2)と連結用ID3である「2」と、ログデータM8とH(S7)とH(S5)とH(S2)に対して署名した結果である署名510からなる。
ログ管理サーバ101の署名生成部203は、アプリケーションサーバ102から受信したログデータについて、1個前(直前)のログレコードのハッシュ値504と、3個前のログレコードのハッシュ値506とをそれぞれ演算し、6個前のログレコードのハッシュ値508は3個前のログレコードから複製し、当該ログレコードにデジタル署名を付与する。また、署名生成部203は、1個前、3個前及び6個前のログレコードに連結用IDを付与する。
なお、図5のログレコードは、アプリケーションサーバ102で処理を行った特定のデータのログデータからログ管理サーバ101が生成したログレコードの署名510の履歴を示したものである。ログレコード保持部208には、アプリケーションサーバ102で処理したデータのそれぞれについて、図5で示すようなログレコードの署名510の履歴が格納される。
次に、図6のハッシュチェーン601の構造を用いて図5で例示したログレコードのハッシュチェーンの構造を可視化したものを示す。図5で示したように、ひとつのログレコードは1個前と3個前と6個前のハッシュ値を含んでおり、図6で示すように、全てのログレコードは1個前と3個前と6個前のハッシュ値によってログレコードの連鎖(ハッシュチェーン)がそれぞれ構成される。つまり、ひとつのログレコードから、複数のハッシュチェーンが生成されている。
次に、本実施の形態によるデータ処理システムの処理の一例について説明する。まず、図7を用いてログレコードの生成方法の例を示す。図7は図5のログレコードを一つ生成する時のログ管理サーバ101の制御部207が行う処理の一例を示すフローチャートである。ここでは、図4のログレコードS11を生成する処理を例に説明する。なお、図7の処理は、ログ管理サーバ101がログデータを受信したとき等、所定のタイミングで実行される。
制御部207はアプリケーションサーバ102からログデータM11を受け取る事で当該処理を開始する。まず、通信部211から取得したログデータM11を新たなログレコードとして、ログレコード保持部208に保存する(ステップ701)。なお、新たなログレコードの生成は、署名生成部203で行うようにしても良い。
次に、署名検証部204は、ログレコード保持部208に保存されている一個前のログレコードであるログレコードS10を検証する(ステップ702)。すなわち、署名検証部204は、秘密鍵・証明書保持部209に予め保存されている証明書から公開鍵を取得し、ログレコードS10の署名510に対して前記公開鍵を適用して解読したデータを取得し、取得したデータとログレコードS10のハッシュ値を比較する。署名検証部204は、デジタル署名された署名510からログデータM10、ハッシュ値H(S9)、H(S7)、H(S4)を公開鍵で取得し、ログレコードS10のログデータ502と、ハッシュ値504、506、508と比較することでログレコードS10の真正性を検証する。つまり、デジタル署名された署名510に含まれるログデータとハッシュ値が、ログレコードS10のログデータ502と、各ハッシュ値504、506、508にそれぞれ等しければ、当該ログレコードS10は改ざんされていない正当なデータであることが保証される。なお、署名検証部204の検証は、デジタル署名された署名510に含まれるハッシュ値と、ログレコードS10の各ハッシュ値504、506、508について行うようにしてもよい。
署名検証部204は、検証した結果、ログレコードS10が改ざんされていないことが確認された場合(ステップ702で検証成功)、署名生成部203のハッシュ値生成部206によりログレコードS10のハッシュ値を生成し、データID503である「10」と共にログレコード保持部208に保存する(ステップ704)。これにより、S10が改ざんされていない事を署名検証部204が検証した上で、署名生成部203は1個前のログレコードS10のハッシュ値をログレコードS11のハッシュチェーンに追加できる。一方、1個前のログレコードS10が改ざんまたは消去されている場合には、ステップ703へ進んで、署名検証部204は後述するようにエラー処理を実施する。
次に、ログレコード保持部208に保存されている3個前のログレコードであるログレコードS8を、署名検証部204によって上記ステップ702と同様に検証し、検証結果が正しい場合(ステップ705で検証成功)には、ハッシュ値生成部206によりログレコードS8のハッシュ値を生成し、連結用ID1506である「8」と共にログレコード保持部208に保存する(ステップ707)。これにより、ログレコードS8が改ざんされていない事を署名検証部204が検証した上で、ハッシュ値生成部206は3個前のログレコードS8のハッシュ値をログレコードS11のハッシュチェーンに追加できる。一方、3個前のログレコードS8が改ざんまたは消去されている場合には、ステップ706へ進んで、署名検証部204は後述するようにエラー処理を実施する。
また、3個前のログレコードS8には6個前のログレコードのハッシュ値H(S5)も保存されているため、ハッシュ値生成部206はハッシュ値H(S5)を複製して連結用ID2509の「5」と共にログレコード保持部208に保存する(ステップ708)。このとき、3個前のログレコードS8が改ざんされていない事は、ステップ705で既に検証されているため、当該ログレコードS8の一部であるH(S5)も改ざんされていない事は検証済みである。
次に、アプリケーションサーバ102から取得したログデータ(メッセージ)M11とハッシュ値H(S10)、H(S8)、H(S5)と、これらのハッシュ値のIDである、データID503である「11」、連結用IDである「10」、「8」、「5」に対して署名生成部203がデジタル署名を行う。すなわち、署名生成部203は、秘密鍵・証明書保持部209に保存されている秘密鍵を用いて、前記ログデータに対する署名値を計算する。次に、署名生成部203は、得られた署名510をログレコード保持部208に保存する(ステップ709)。
上記ステップ701〜709の処理によって、ログ管理サーバ101は、受信したログデータM11からログレコードS10、S8、S5のハッシュ値に秘密鍵でデジタル署名を行ったログレコードS11を生成して、ログレコード保持部208に格納する。
以上の処理において、複数個前のログレコードの選択の仕方として、N×2^(p−1)個前のログレコードを取得する例を示す。
ただし、Nは自然数の定数、pは1〜nまでの値を取る自然数の変数で、nは複数個前のハッシュ値をいくつ取得するか表す値である。なお、上記図5の例では、直前のログレコードと、N×2^(p−1)個前のログレコードをn個取得する例を示した。
ログレコードごとに行う改ざんされていない事の検証と、ハッシュ値の計算は、1回のハッシュ値の比較とハッシュ値の複製によって行う事が出来るため、ログレコードを生成する時のログ管理サーバ101の演算負荷が軽減される。
N=3、p={1、2、3、4}、n=4として具体的に説明する。このとき選択される複数個前のログレコードは、p=1のとき3個前、p=2のとき6個前、p=3のとき12個前、p=4のとき24個前となり全てのログレコードは、3個前、6個前、12個前、24個前のログレコードのハッシュ値を持つ。署名生成部203が新しいログレコードを生成する場合は、3個前のログレコードを署名検証部204で検証したあとは、3個前のログレコードに含まれる6個前のログレコード(3個前のログレコードにとっては3個前のログレコード)のハッシュ値を取得して複製すると共に、取得したハッシュ値と、6個前のログレコードから計算したハッシュ値とを比較して6個前のログレコードの検証を行う。署名検証部204で検証された6個前のログレコードは、12個前(6個前のログレコードにとっては6個前)のログレコードのハッシュ値を含むため、12個前のハッシュ値を取得して複製すると共に、取得したハッシュ値と12個前のログレコードから計算したハッシュ値を比較して12個前のログレコードの検証を行う。署名検証部204で検証された12個前のログレコードは24個前(12個前のログレコードにとっては12個前)のログレコードを含むため、これを複製して処理を終了する。
このように、署名生成部203では、1回の署名検証処理と2回のハッシュ値の比較処理と、4回の複製処理を行う事により3個前、6個前、12個前、24個前のハッシュ値を含んだログレコードを生成する事ができる。
一方、署名検証部204が実行するステップ703とステップ706のエラー処理は、ログレコードの検証処理が失敗し、検証対象のログレコードが改ざんまたは消去された可能性がある事をユーザに警告する。例えば、エラーメッセージと共に、改ざんされたログレコードのデータID503をユーザが利用する計算機へ出力し、当該計算機の出力装置406に表示する。
以上のように、本発明では、特定のログデータの新たなログレコードを生成する際には、特定のログデータに関する複数のログレコードを署名510の時系列順に並べ、直前のログレコードと、署名510の新しいものから古いログレコードに向けて、所定の間隔N個毎にn個のログレコードを選択する。そして、ログ管理サーバ101は、直前のログレコードと、N個前のログレコードのハッシュ値をそれぞれ演算する。そして、N個前よりも古い(N×2以降)ログレコードのハッシュ値は、N個前のログレコードに格納されているハッシュ値を複製する。ログ管理サーバ101は、新たなログレコードにn+1個のハッシュ値を格納するが、実際にハッシュ値を演算するのは直前のログレコードとN個前のログレコードの2回で済み、その他は複製すればよいので、演算負荷を低減することができる。
換言すれば、ログ管理サーバ101は、新たなログレコードを生成する際に、デジタルの署名510の時系列上の所定の間隔で複数のログレコードを選択し、当該選択した複数のログレコードのうち最新のログレコードのハッシュ値を演算し、直前のログレコードのハッシュ値を演算する。そして、ログ管理サーバ101は、選択した複数のログレコードのうち最新のログレコード以外のハッシュ値は、各ログレコード保持するハッシュ値を複製するのである。
次に、図8と図9を用いて特定のログレコードの高速検証方法の一例を示す。ここで、特定のデータとは、入出力部210がユーザの計算機から検証の要求を受け付けたログレコードや、入力装置212から検証の要求を受け付けたログレコードである。
図8は、高速検証を行う際にログを辿る一例を示す図である。図8の高速検証ルート801は、ログレコードS11をトラストポイントとした時に、S1を検証する最短ルートを例示した図である。このとき、ログレコードS1〜S10の署名は既に有効期限が切れているものと仮定する。ここでは一例として、3ステップで検証する例を示している。この例ではログレコードに含まれるハッシュ値のうち、一番古い6個前のログレコードS5のハッシュ値について署名510とハッシュ値の比較検証を行う事で、ひとつずつハッシュチェーンをたどるのに比べてステップ数を省略することができる。このとき、一番古いハッシュ値が特定データより古い場合は二番目に古いハッシュ値についてハッシュ値の比較を行い、二番目に古いハッシュ値が特定データより古い場合は三番目に古いハッシュ値について比較していくように、徐々に省略範囲を狭くして行く事で、最少のステップでの特定データの真正性の検証を実現している。
図8の例では、ログレコードS11に含まれるハッシュ値のうち、最も古い6個前のログレコードS5について、署名検証部204は、ログレコードS11に含まれるハッシュ値H(S5)と、ログレコードS5のハッシュ値を計算して検証を行う。
次に、署名検証部204は、ログレコードS5に含まれる最古のハッシュ値H(S2)とログレコードS2のハッシュ値を計算して上記と同様に検証を行う。
最後に、署名検証部204は、ログレコードS2に含まれる最古(直前)のハッシュ値H(S1)とログレコードS1についてハッシュ値を計算して上記と同様に検証を行う。
以上の3回の検証によって、署名検証部204は、ログレコードS11がログレコードS1の真正なデータであることを保証することができる。これにより、ログレコードS1〜S10の全てを辿ることなく、ログ管理サーバ101は、要求されたログレコードS11の真正性についてログレコードS5、S2を辿ることで、迅速に検証を行うことができる。
図9は、署名検証部204で行われる図8の高速検証ルート802の検証処理の一例を示すフローチャートを表したものである。以下に図9の詳細な説明を行う。
まず、検証を行うログレコードを入出力部210から取得して、トラストポイントの選定を行う。トラストポイントは署名の有効期限が切れていないログレコードで、かつ、検証対象のログデータに一番近いログレコードを選定する。この場合、図8に示したログレコードS1〜S10までの署名は有効期限が切れていると仮定されているため、ログレコードS11がトラストポイントとして選定される(ステップ901)。
次に、トラストポイントの署名を署名検証部204で検証する(ステップ902)。トラストポイントが検証された場合、検証済みのログレコードのデータIDを保持する変数xをトラストポイントのデータIDで初期化する(ステップ904)。図8の例に従うと、ここでは変数xに「11」が代入される。以下、変数xが検証対象のID(図8の例に従うとIDは1)に到達するまでステップ906からステップ908を繰り返す(ステップ905)。
一方、署名検証部204は、ステップ902でログレコードの検証に失敗した場合には、ステップ903へ進んで後述するエラー処理を実行する。
署名検証部204は、ログレコードSxのログレコードに含まれる連携IDのうち、検証対象のログレコードのデータIDと同一か、検証対象のログレコードより新しいもののうち、一番古い連結用IDを選択して、変数xに代入する(ステップ906)。具体的には図5におけるログレコードS11に含まれるハッシュ値のうち、上記条件を満たすハッシュ値H(S5)の連結用IDは「5」のため、変数xには「5」が代入される。
次に、ハッシュ値比較部205により、ハッシュ値H(S5)とログレコードS5のハッシュ値を計算した値との比較を行い、図5に示したハッシュチェーン601の部分的な検証を行なう(ステップ907)。これにより、署名検証部204は、ログレコードS5が改ざんされていないことを保証する。
ログレコードS5は検証対象のログレコードではないため、ステップ906から908を繰り返す。すなわち、ログレコードS5に含まれるハッシュ値のうち、上記条件を満たすH(S2)とS2のハッシュ値を計算した値との比較を行い、図6に示したハッシュチェーン601の部分的な検証をさらに行なう。ログレコードS2は検証対象ログレコードではないため、ログレコードS2に含まれるハッシュ値のうち、上記条件を満たすH(S1)と、ログレコードS1のハッシュ値を計算した値との比較を行い、ハッシュチェーンの部分的な検証を行い、検証対象のログレコードの検証が終了する。
ステップ903のエラー処理では、署名検証部204は、トラストポイントのデータが改ざんまたは消去された可能性がある事をユーザに警告する。例えば、エラーメッセージと共に、改ざんされたログレコードのデータID503を、ユーザの計算機に送信し、当該計算機の出力装置406に表示する。
このステップ903のエラー処理では、ステップ901へ戻って、新しいトラストポイントの選定を行なう。このとき、新しいトラストポイントは署名の有効期限が切れていないログレコードで、かつ、検証対象のログデータに一番近いログレコードを選定し、かつ、エラーが発生したログレコードではないものとする。その後、上述したステップ902以降の処理を実行する。
また、署名検証部204は、ステップ907でログレコードの検証に失敗した場合には、ステップ908へ進んで後述するエラー処理を実行する。
ステップ908のエラー処理では、検証処理が失敗し当該ログレコードが改ざんまたは消去された可能性がある事をユーザに警告する。例えば、エラーメッセージと共に、改ざんされたログレコードのデータID503を、ユーザの計算機に送信し、当該計算機の出力装置406に表示する。
次に、このステップ903のエラー処理では、他の検証ルートで特定データの検証を続行するようにしてもよい。例えば、図8に示した高速検証ルート801以外の検証ルートを選択することも可能である。例えば、他の検証ルートの選定方法としては、検証済みログレコードに含まれる他のハッシュ値から発生する検証ルートや、検証済みログレコードを保証していたログレコードに含まれる他のハッシュ値から発生する検証ルートを選定することが考えられる。
一例として、上記特定データの検証処理において、ログレコードS5のデータが検証に失敗した場合を示す。署名検証部204は、まず、トラストポイントとしてログレコードS11を選定する(ステップ901)。署名検証部204により、選定したトラストポイントのログレコードS11の検証を行い(ステップ902)、変数xに「11」を代入する(ステップ904)。「11」は検証対象データのデータIDではないため(ステップ905)、ログレコードS11に含まれるハッシュ値のうち、検証対象ログデータのデータIDと同一か、検証対象ログデータより新しいもののうち、一番古い連結用IDという条件を満たす、IDが「5」を変数xに代入する(ステップ906)。次に、ハッシュ値H(S5)とログレコードS5をハッシュ値比較部205により検証する(ステップ205)。ここで、ログレコードS5は上述したように検証に失敗するため、エラー処理(ステップ908)が行われ、ユーザへの警告と他の検証ルートが選定される。この例では、ログレコードS11に含まれる他のハッシュ値であるH(S8)とH(S10)のうち、より検証対象のS1に近いハッシュ値であるH(S8)を、新たな検証ルートとして選択する。次に、ハッシュ値H(S8)とログレコードS8をハッシュ値比較部205により検証する(ステップ908)。ログレコードS8は検証可能なため、上記で説明した通常の特定データの検証の処理が行われ、ステップ906〜ステップ908が繰り返される。具体的には、ログレコードS8に含まれるハッシュ値のうち、ハッシュ値H(S2)が選択され(ステップ906)、ハッシュ値H(S2)とログレコードS2から計算したハッシュ値をハッシュ値比較部205により検証する(ステップ908)。検証されたハッシュ値H(S2)に含まれる、ハッシュ値H(S1)とログレコードS1から計算したハッシュ値がハッシュ値比較部205により検証され、S1の検証が終了する。このように、あるデータが改ざんまたは消去された場合でも、トラストポイントのログレコードに含まれる他のログレコードのハッシュ値を利用することで、検証に失敗した場合でもログレコードの検証を行う事ができ、真正性の検証を確実に行うことができる。
以上、本発明の第一実施形態について説明した。
本実施の形態によれば、大量かつ随時発生するデータの真正性を長期間保証するためのデジタル署名技術において、全てのログレコードが複数個前のログレコードのハッシュ値を複数個持つことにより、複数のハッシュチェーンを構成する。
これにより、あるログレコードが改ざんされた場合でも、他のハッシュチェーンによってその他のログレコードの真正性は担保される。
このとき、複数個前のログレコードの検証を効率的に行い、デジタル署名の検証ステップを減らす事で、デジタル署名生成時の計算機の負荷を低減しながらログレコードを生成する事ができる。
また、生成時に複数個前のログレコードに対するハッシュチェーンを作る事で、ハッシュチェーンの検証処理が削減されるため、特定データの高速検証を実現する事ができる。
さらに、ログレコード生成時に複数個前のログレコードが改ざんされているかどうかを検証する処理を行なうため、ログレコードの改ざんを早期に発見できる可能性がある。
なお、本発明は、上記の実施形態に限定される物ではなく、その要旨の範囲内で数々の変形が可能である。
第一実施形態では、3個前、6個前のログレコードを取得するとしているが、いくつ前のログレコードのハッシュ値をいくつ取るかは任意に設定でき、N個前(Nは定数)としてもよく、ランダムな値の個数前のログレコードとしてもよい。つまり、過去の複数個前のログレコードから複数取得するようにしてもよい。また、一定時間前のログレコードのハッシュ値を取るという設定も可能である。上記のように任意でログレコードのハッシュ値を取得する場合、ログ生成時のログレコードが改ざんされていない事の確認と特定データの検証における特定データまでの検証ルートの構築手法は、周知または公知のグラフ理論を応用する事で最適なルートを計算可能である。
また、本実施形態では、図1〜図3に示されるような構成により実現できるとしているが、本発明は上記構成に限定されるものではない。ログ管理サーバ101だけでなく、アプリケーションサーバ102に図5のログレコードを生成し、管理する機能があってもよい。
さらに、上記実施形態では、アプリケーションサーバ102はログが発生するごとにログデータをログ管理サーバ101に送付しているが、例えば、一日に発生したログデータをファイルにまとめてからログ管理サーバ101に送付する事も可能である。この場合、ファイルがログ管理サーバ101に送付される前に改ざんされる可能性があるため、その対策として、アプリケーションサーバ102にハッシュチェーンを生成する機能を持たせることや、タイムスタンプを活用することが考えられる。送付されたファイルのログ管理サーバ101における処理方式としては、ファイル中のログレコードによりハッシュチェーンを作る方式や、ファイルそのものをログデータのように扱い、ファイル単位のハッシュチェーンを作る方式などが考えられる。
また、本実施形態では、検証するデータをログデータとした例を示したが、電子データにデジタル署名を行う計算機システムに適用することができる。
図10、図11を用いて本発明の特定のログレコードの高速検証方法の第二の実施形態の例を示す。本第二の実施形態の特徴は、ハッシュチェーンの検証回数が最小となるトラストポイントを選定し、選定したトラストポイントと検証対象のハッシュチェーンの検証を行い、さらに検証に使用したハッシュチェーンを出力することである。第一の実施形態では、署名の有効期限が切れていないログレコードで、かつ、検証対象のログレコードに一番近いログレコードをトラストポイントとして選定しているが、本実施形態では、署名の有効期限が切れていないログレコードで、かつハッシュチェーンの検証回数が最小となる署名をトラストポイントとして選定する。
本実施形態は第一の実施形態において、図8と図9を用いて説明した高速検証方法を変更した方法であり、図1〜図7を用いて説明したシステム構成やログレコード生成方法で、ログレコードが生成されていることを前提とする。
この時、トラストポイントは有効期限が切れていない署名であり、通常の電子証明書は通常5年程度の有効期限があることから、ある時点において、署名の有効期限が切れていないログレコード(トラストポイント)が複数存在することとなる。たとえば、5年間の有効期限の電子証明書を用いる場合、最大で5年間のログレコードすべてトラストポイントとすることができる。
図10は本実施の形態において高速検証を行う際にハッシュチェーンを辿る一例を示す図である。図10では、例としてログレコードS11〜S13が署名の有効期限が切れていないログレコードとし、S1を検証対象のログレコードとする。この時、署名の有効期限が切れていないログレコードなど、トラストポイントになりうるログレコードの集合は図2の記憶部202に記憶され、例えばDBやファイルなどに記憶される。
以下に処理方法を説明する。本実施の形態では、トラストポイントを最初に確定せず、ハッシュチェーンの検証と並行してトラストポイントの選定を行う。具体的には、検証対象のS1とハッシュチェーンで接続されているS7、S13のハッシュチェーンの検証と並行して、S1とハッシュチェーンで接続されているS7、S13の署名の有効期限を確かめ、トラストポイントとなりうる署名が見つかった場合にハッシュチェーンを辿るのを終了し、当該署名をトラストポイントとする。そして、トラストポイントの署名検証を行い、検証対象であるS1とトラストポイントがハッシュチェーンで接続されており、検証対象であるS1が改ざんされていないことを確かめる。
以上より、検証対象のS1はS11〜S13のログレコードのうち、S13をトラストポイントとして検証を行うと、2回のハッシュ値検証で検証が終了する。
図11は、署名検証部204で行われる図10の検証回数が最小になる検証ルート1001の検証処理の一例を示すフローチャートを表したものである。以下に図11の詳細な説明を行う。
まず、検証を行うログレコードを入出力部210から取得し、取得したログレコードのIDを、検証対象のログレコードのIDを保持する変数xに代入する(ステップ1101)。具体的には、xに「1」を代入する。
次に、署名検証部204はSxのハッシュ値を持つログレコードを算出し、算出したログレコードのうち最新のログレコードのIDを比較対象のログレコードのIDを保持する変数yに代入する。(ステップ1102)。具体的には、検証対象のログレコード(S1)のハッシュ値を持つのはS2、S4、S7のログレコードであり、そのうちの最新のものであるS7のログレコードの連結用ID「7」が変数yに代入される。
次に、ハッシュ値比較部205により、ログレコードSyに含まれるハッシュ値H(Sx)とログレコードSxのハッシュ値を計算した値との比較を行い、図6に示したハッシュチェーン601の部分的な検証を行う(ステップ1103)。具体的には、S7に含まれるハッシュ値H(S1)とログレコードS1のハッシュ値を計算した値を比較する。これにより、署名検証部204はログレコードS1が改ざんされていないことを確認する。
次に、署名検証部204はログレコードSyがトラストポイントとして登録されているか確認を行い、登録されていない場合に変数xに変数yを代入し、ステップ1102に進む。具体的にはS7はトラストポイントとして登録されていないため、変数xにS7の連結用ID「7」を代入し、S7のハッシュ値を持つログレコードであるS8、S10、S13のうち、最新のものであるS13を変数yに代入し(ステップ1102)、S13に含まれるハッシュ値H(S7)とログレコードS7のハッシュ値を計算した値を比較する(ステップ1103)。
次に、署名検証部204はログレコードS13がトラストポイントとして登録されていることを確認し、ステップ1106に進みログレコードS13の署名検証を行う。ログレコードS13の署名検証に成功した場合、ログレコードS13に含まれるハッシュ値H(S7)が改ざんされていないことが確認できる。以上の全ての処理に成功した場合、トラストポイントとして選択したログレコードS13の署名検証、およびトラストポイントから検証対象のログレコードS1までのハッシュチェーンの検証が確認できた事になる。
次に、署名検証部204は、検証結果と、検証に使用したログレコードのリストをユーザに提示して検証対象のログレコードの検証が終了する(ステップ1108)。検証に使用したログレコードのリストとは、具体的には、S1、S7、S13であり、これらの一連のログレコードのデータID503をユーザに提示する。なお、ユーザは、当該一連のログレコードのデータID503をキーに、ログレコード保持部208から当該一連のログレコードを取得してもよい。
なお、ステップ1104、ステップ1107のエラー処理では、署名検証部204は、記憶部202に記録されているログレコードSyが改ざんまたは消去された可能性があることをユーザに警告する。たとえば、エラーメッセージと共に、改ざんされたログレコードのデータID503を、ユーザの計算機に送信し、当該計算機の出力装置406に表示する。
このステップ1104、ステップ1107のエラー処理では、他の検証ルートで特定データの検証を続行するようにしてもよい。たとえば、図10に示した検証回数が最小になる検証ルート1001以外の検証ルートを選択することも可能である。たとえば、他の検証ルートの選定方法としては、検証済みログレコードに含まれる他のハッシュ値から発生する検証ルートや、検証済みログレコードを保証していたログレコードに含まれる他のハッシュ値から発生する検証ルートを選定することが考えられる。
以上、本発明の第二実施形態について説明した。本実施形態により、複数のトラストポイントから最適なトラストポイントを選定することで、ハッシュ値の検証回数を最小にし、最古のトラストポイントを選択する、第一の実施形態で示した方法よりさらに高速に検証を行うことを可能とする。
また、検証に使用したログレコードのリストをユーザに提示することで、検証結果のエビデンスを第三者に提供すことが可能となる。ユーザは当該提示されたログレコードのリストに含まれる一連のログレコードを、ログレコード保持部208から取得し、第三者に提供することができる。第三者はログ管理サーバ101にアクセスすることなく、ユーザから提供されたログレコードのリストを用いて検証対象のログレコードの真正性を検証することができる。すなわち、第三者はユーザから提供されたエビデンス情報を用いて、自身で検証対象のログレコードの真正性を確認することができる。
なお、本第二実施形態では、3個前と6個前のログレコードのハッシュ値を含む場合を想定しているが、いくつ前のログレコードをいくつ含むかは任意に設定でき、設定した方法において、ハッシュチェーンの検証回数が最小となるトラストポイントを選定できるようにする。選定方法の一例としては、周知または公知のグラフ理論を応用することがある。
次に、図12、図13を用いて本発明における第三の実施形態の構成について説明する。本実施形態の特徴は、第一及び第二の実施形態で記述したデータ処理システムを、情報連携システムに適用したものである。
情報連携システムとは、ある人物や企業等の組織に関する情報を、情報照会システムと情報提供システムという異なる組織間でやり取りする際に、中継を行うシステムである。たとえば、情報照会システムと情報提供システムがある人物や企業等の組織を、異なるIDで管理している場合等に、情報照会システムIDから情報提供システムのIDへ変換を行い、情報連携を中継する。
情報連携システムでやり取りされる情報は個人や企業等の組織に関するセンシティブな情報も多く含むため、処理に関わった情報照会システムと情報提供システムの情報ややり取りされた個人情報の種類等を証跡として保存しておく必要があり、これら情報連携の証跡をログデータとしてログ管理サーバで保管する。
本実施形態は第一の実施形態において、図1〜図3を用いて説明したデータ処理システムを、情報連携システムに適用したものであり、図5〜図7を用いて説明したログレコードが生成され、図8、図9、または第二の実施形態において説明した処理によって高速検証が可能になる。
図12は、本発明の第三の実施形態が適用された情報連携システムにおけるログデータ処理の一例を示すブロック図である。
情報連携システムと情報照会システム及び情報提供システムはインターネットや広域WAN等のネットワーク103で接続されている。情報連携システムはログ管理サーバ101と情報中継装置1201から構成され、組織内ネットワーク1202で接続されている。情報照会システムと情報提供システムは情報連携装置12031〜12032(「情報連携装置1203」と総称する)とログ管理サーバ12041〜1204Nから構成され、組織内ネットワーク12021〜1202Nで接続されている。
次に、図12の情報連携システムを構成する各装置について説明する。情報中継装置1201と情報連携装置1203はアプリケーションサーバ102と同様の構成からなる。すなわち、情報連携に関わる処理をアプリケーション処理部304によって行い、情報連携の証跡とすべきデータをログ出力処理部303によって出力する。
次に、図13を用いて本実施の形態による、情報連携システムにおけるログデータ処理の一例について説明する。情報照会システムの情報連携装置1203は、情報連携装置1203の操作者等からの情報連携開始指示を受けたタイミング等で、情報中継装置1201に対して情報連携要求を送付する(ステップS1301)。情報連携要求を行った情報照会システムはその記録をログ管理サーバ1204に出力し(ステップS1302)、ログ管理サーバ1204は、図7の処理を行うことで記録に署名を付与し、保管する(ステップS1303)。
情報連携要求を受信した情報中継装置1201は、連携対象個人または組織を表すIDを、情報照会システムで使用されるIDから情報提供システムで使用されるIDへ変換を行う等の情報中継処理を行う(ステップS1304)。そして、情報中継装置1201は、情報提供システムの情報連携装置1203に対して情報連携要求を送信し(ステップS1305)、ステップS1304とステップS1305の処理結果の記録をログ管理サーバ1204に出力する(ステップS1306)。ログ管理サーバ1204は、図7の処理を行うことで記録に署名を付与し、保管する(ステップS1307)。
情報連携要求を受信した情報提供システムの情報連携装置1203は情報連携要求に応じて送信する情報の生成等の処理を行い(ステップS1308)、その結果を情報照会システムに送信する(ステップS1309)。情報連携装置1203は、ステップS1308とステップS1309の処理の結果のログデータをログ管理サーバ1204に出力し(ステップS1310)、ログ管理サーバ1204は、図7の処理を行うことで署名を付与し、保管する(ステップS1311)。
要求した情報を受信した情報照会システムの情報連携装置1203は、その受信結果をログ管理サーバ1204に出力し(ステップS1312)、ログ管理サーバ1204は図7の処理を行うことで署名を付与して保管する(ステップS1313)。さらに、情報照会システムの情報連携装置1203は情報中継装置に受信結果を送付し(ステップS1314)、ステップ1314の処理の結果の記録をログ管理サーバ1204に出力し、ログ管理サーバ1204は、図7の処理を行うことで、当該記録に署名を付与し、保管する(ステップ1316)。
次に、受信結果を受信した情報中継装置1201は、受信処理の結果をログ管理サーバ1204に出力し(ステップS1317)、ログ管理サーバ1204は図7の処理を行うことで署名を付与して保管する。
また、ステップS1309で要求された情報を送付した情報照会システムは、その送信結果を情報中継装置に送信し(ステップS1319)、その結果の記録をログ管理サーバ1204に出力し(ステップS1320)、ログ管理サーバ1204は、図7の処理を行うことでログに署名を付与し、保管する(ステップS1321)。
ステップS1319の送信結果を受信した情報中継装置は、受信結果をログ管理サーバ1204に出力し(ステップS1322)、ログ管理サーバ1204は図7の処理を行うことでログに署名を付与し、保管する(ステップS1323)。
以上、本発明の第三実施形態について説明した。
本実施形態によれば、通信が発生する毎に情報連携に関わる処理の記録を生成し情報連携の証跡として長期間真正性を保証する必要があるユースケースに対して、証跡の真正性を長期間保証するためのデジタル署名技術における、全てのログレコードが複数個前のログレコードのハッシュ値を複数個持つことにより、複数のハッシュチェーンを構成する。
これにより、あるログレコードが改ざんされた場合でも、他のハッシュチェーンによってその他のログレコードの真正性は担保される。
このとき、複数個前のログレコードの検証を効率的に行い、デジタル署名の検証ステップを減らす事で、デジタル署名生成時の計算機の負荷を低減しながらログレコードを生成する事ができる。
また、生成時に複数個前のログレコードに対するハッシュチェーンを作る事で、ハッシュチェーンの検証処理が削減されるため、特定データの高速検証を実現する事ができる。
なお、本実施形態の例では、S1309において、情報提供システムの機関から、情報照会システムの機関に対して情報連携結果を応答するアクセストークン方式を説明しているが、情報提供システムの機関から情報連携システムを経由して情報照会システムの機関に対して情報連携を行う、ゲートウェイ方式を使用した情報連携においても、情報連携の証跡の真正性を保つことができる。
図14、図15を用いて本発明のハッシュチェーン生成時にさらに複雑性を向上する第四の実施形態の例を示す。
本実施形態の特徴は、複数のハッシュチェーンからなるハッシュチェーンの集合体が複数存在する場合に、あるハッシュチェーンの集合体のログレコードに、他のハッシュチェーンの集合体のログレコードの複数個前のハッシュ値を含めることで、ハッシュチェーンの集合体を接続する事である。
ハッシュチェーンの集合体が複数存在する場合とは、たとえば、アプリケーションサーバ102毎にハッシュチェーンの集合体を作成する場合がある。すなわち、アプリケーションサーバ1021から出力されたログデータからログレコードを生成する際に、アプリケーションサーバ1021の3個前のログデータから生成されたログレコードのハッシュ値と、アプリケーションサーバ1021の6個前のログデータから生成されたログレコードのハッシュ値を含めることで、アプリケーションサーバ1021のハッシュチェーンの集合体を構成する。以上より、アプリケーションサーバと同数の複数のハッシュチェーンの集合体が存在することとなる。
なお、本実施形態では、一例としてハッシュチェーンの集合体が2つ存在する(仮にアプリケーションサーバ1021の集合体を「集合体s」、アプリケーションサーバ1022の集合体を「集合体t」と呼ぶ)場合を説明する。
本実施形態は、図1〜図10を用いて行った第一の実施形態の説明のうち、ログレコードの生成方法で生成するログレコードの詳細内容(図5〜図6)について改良を行ったものであり、図8〜図9または第二の実施形態において説明した処理によって高速検証が可能になる。
まず、図14を用いて、ログレコードの詳細について説明する。
集合体sのひとつのログレコード1401は、図5に示した502〜510のフィールドに加えて、集合体を識別するためのユニークIDである集合体ID1402と、集合体tの3個前のログレコードのハッシュ値である集合体tの3個前のハッシュ値1403と、tの3個前のハッシュ値1403を表すユニークなIDである連結用ID1404と、集合体tの6個前のログレコードのハッシュ値である、tの6個前のハッシュ値1405と、tの6個前のハッシュ値1405を表すユニークなIDである連結用ID1406と、からなる。なお、連結用IDは集合体のIDを含め、連結用IDから集合体を識別できることとする。また、署名1407は図5の署名510と同様で、フィールド502〜509、1402〜1406に対するデジタル署名である。
ログ管理サーバ101の署名生成部203は、アプリケーションサーバ1021から受信したログデータについて、アプリケーションサーバ1021のハッシュチェーンの集合体(集合体s)の1個前、3個前、6個前のログレコードのハッシュ値を実施形態1と同様に生成する。署名生成部203は、さらに、アプリケーションサーバ1022のハッシュチェーンの集合体(集合体t)の3個前のログレコードのハッシュ値1403を演算し、集合体tの6個前のハッシュ値を集合体tの3個前のハッシュ値から複製し、当該ログレコードにデジタル署名を付与する。また、署名生成部203は、集合体sの1個前、3個前、6個前のログレコードと、集合体tの3個前、6個前のログレコードに連結用IDを付与する。
次に、図15のハッシュチェーンの構造1501を用いて、図14で例示したログレコードのハッシュチェーンの構造を可視化したものを示す。図15で示すように、集合体sのログレコードは自集合体の1個前と3個前と6個前のハッシュ値と、集合体tの3個前と6個前のハッシュ値を含んでおり、図15で示すように、すべてのログレコードは自集合体の1個前と3個前と6個前のハッシュ値と、集合体tの3個前と6個前のハッシュ値によってログレコードの連鎖(ハッシュチェーン)がそれぞれ構成される。つまり、集合体s、集合体tの間にもハッシュチェーンが構成されている。
通常、図14、図15を用いて方法を用いて生成したハッシュチェーンは、第一の実施形態、第二の実施形態で説明した方法で検証するが、攻撃者によって秘密鍵が漏えいするなど、自集合体中にトラストポイントが存在しない場合は、他集合体に存在するトラストポイントと検証対象をつなぐハッシュチェーンを辿ることで検証する。
以上、第四の実施形態を説明した。本実勢形態を適用すると、他の集合体との間にハッシュチェーンを生成される。これにより、チェーンの複雑性が向上し、攻撃に対する耐性が向上する。たとえば、ある集合体に対応する秘密鍵が漏えいするなどにより、署名が失効した場合においても、他の集合体の署名が失効していなければその集合体からハッシュチェーンを辿るなどして、検証を行うことができる。
なお、本実施形態の結果生成されるログレコードは第二の実施形態の高速検証、第三の実施形態の情報連携システムにおいても適用可能である。
次に、図16〜図18を用いて本発明における第五の実施形態の構成について説明する。
本第五の実施形態の特徴は、第三の実施例で説明した、情報照会システムや情報提供システムなどにおいて、それぞれログ管理サーバを配置するのではなく、共通化可能な機能をログ管理サーバとして複数システムで共有し、共有不可能な部分をログ管理クライアントとして各システムに配置する点である。 具体的には、ログ管理クライアントはハッシュ値を計算する機能を持ち、ログデータのハッシュ値を計算したのちに、当該ハッシュ値をログ管理サーバに送付する。ログ管理サーバはログ管理クライアントから受け取ったハッシュ値に対して署名を行う。
本実施形態は第三の実施形態において、図13を用いて説明したタイミングでログが出力され、第一の実施例、第四の実施例で説明したログレコードが生成され、第一の実施形態と第二の実施形態で説明した高速検証を行う。
図16は、本発明の第五の実施形態が適用されたログ管理システムの一例を示すブロック図である。ログ管理システムと情報照会システム及び情報提供システムはインターネットや広域WAN等のネットワーク103で接続されている。ログ管理システムはログ管理サーバ101から構成される。情報照会システムと情報提供システムは情報連携装置12031〜12032(「情報連携装置1203」と総称する)とログ管理クライアント16011〜1601Nから構成され、組織内ネットワーク12051〜1205Nで接続されている。
次に、図17を用いて、ログ管理クライアント1603を説明する。図17はログ管理クライアント1603の機能要素の一例を示すブロック図である。
ログ管理クライアント1603は、情報連携装置1203から送付されたログデータからログデータのハッシュ値を計算したり、ログ管理サーバに検証要求を行う処理部1701と、情報連携装置1203から送付されたログデータ等を記憶する記憶部1702と、ユーザ又は管理者からの入力を受取る入出力部1707と、情報連携装置1203から出力されるログデータを受取る通信部1708を有する。
処理部1701はログデータのハッシュ値を生成するハッシュ値生成部1703と、ログ管理サーバに検証要求を行う署名検証要求部1704と、それらを制御する制御部1705を有する。
記憶部1702はログデータを記憶するログデータ保持部1706を有する。
ログ管理システムを使用する情報照会システムまたは情報提供システムは、それぞれの秘密鍵をログ管理システムに対して送付し、ログ管理システムは秘密鍵・証明書保持部209にそれらを保存する。
なお、図17に例示したログ管理クライアント1603は、第一の実施形態のログ管理サーバ101、アプリケーションサーバ102と同様に、図4に示すような装置および同等の機能を有するプログラムやハードウェアを用いて実現することができる。
次に、図18を用いて本実施の形態による、ログ生成処理の一例について説明する。
情報連携装置1203はステップ1302、1310、1312、1315、1320のタイミングで、ログ管理クライアント1601にログデータを送信する(ステップS1801)。ログデータを受信したログ管理クライアントはログデータ保持部1706にログデータを保存し、ハッシュ値生成部1703でログデータのハッシュ値を生成し(ステップS1802)、ログ管理サーバにログデータのハッシュ値を送信する(ステップS1803)。
ログデータのハッシュ値を受信したログ管理サーバ101は、図6の処理を行うことでログに署名を付与(ステップS1804)し、保管する(ステップS1805)し、処理結果を応答する(ステップS1806)。この時、上記で説明した通り、ログ管理サーバはログ管理クライアントから送付されたログデータのハッシュ値に対して署名を行うため、ログレコード501におけるログデータはH(M1)となり、署名510はSign(H(M1)||IV||IV||IV)となる。次に、図18を用いて、本実施の形態によるログ検証処理の一例について説明する。
ログ管理クライアント1603は記憶部1702に保持されている検証対象のログデータを取得し、ハッシュ値生成部1703でログデータのハッシュ値を生成(ステップS1901)し、ログ管理サーバにログデータのハッシュ値を送信する(ステップS1902)。
ログデータのハッシュ値を受信したログ管理サーバは、受信したログデータのハッシュ値を検索キーに、当該ログデータを含むログレコードを検索(ステップS1903)し、検索したログレコードを図9または図11の処理を行うことで検証し(ステップS1904)、その検証結果をログ管理クライアントに応答(ステップS1905)する。
応答を受けたログ管理クライアントは送信したハッシュ値を含むログレコードが存在することからログデータが改ざんされていないことを確認して、検証を終了する。
以上、第五の実施形態を説明した。本実施形態を適用すると、第三の実施形態において、情報照会システムまたは情報提供システム側のコストを最小限にして、情報連携の記録等のログデータの真正性を保証できる。
この時、ログ管理クライアントにおいて、ログデータそのものでなく、ログデータのハッシュ値を計算してログ管理サーバに送信することで、ネットワーク103の負荷を減らすことができる。
なお、ネットワーク103が十分な性能を備えている場合等においてはログデータをログ管理サーバに送信して管理してもよい。
また、ログ管理クライアントが秘密鍵の記憶、署名生成機能を持ち、署名の保存のみをログ管理システムが行うことも可能である。
また、ステップS1806において、ログ管理サーバがログ管理クライアントに対して、データID503や集合体ID1402などログレコードを識別する情報合わせて応答してもよい。さらに、ログ管理サーバが検索を行う際に、当該識別する情報を使用して検索してもよい。
以上のように、本発明はデジタル署名に有効期限のあるデータを検証する計算機や計算機システムに適用することができ、特に、ヒステリシス署名を行う計算機システムに好適である。