JP2016509443A - より低いエントロピーを有する入力レコードについて追加的セキュリティをもたらす検証システム及び方法 - Google Patents

Abstract

デジタルレコードのための認証システムは、デジタル署名が付されることのできる最上位ルートハッシュ値（xroot）を計算するハッシュツリー構造（２０００、３０００、４０００、５０００、６０００）を有する。乱数又は疑似乱数（rnd）がデジタルレコードのハッシュ値と共にハッシュされ、これがブラインディングマスク（mi）として作用して、比較的低エントロピーなデジタルレコードにおいても認証システムをセキュアなものにする。再計算パスにおける兄弟ハッシュ値及び疑似乱数が与えられている局面において、ハッシュツリーを通しての再計算によって同一のルートハッシュ値が計算された場合、候補デジタルレコードは検証されたものとみなされる。【選択図】図１

Description

関連出願の相互参照
本願は、２０１３年２月２２日に出願された米国仮特許出願第６１／７６８，３８６号の優先権を主張する。

本願発明は、他のレコードの内容について何らの情報を漏出させずに、デジタルレコードセット中の任意のものが変更されていないかを検証するシステム及び方法に関する。

デジタル世界はイベントによって規定されており、これらの多くはログされているかログされることができる。例えば、コンピュータシステムの文脈においては、syslogを「コンピュータデータロギングについての標準仕様として用いることができる。この仕組みは、メッセージを生成するソフトウェアを、これらを格納するシステム及びこれらをリポート及び分析するソフトウェアから分離する。Syslogは、コンピュータシステム管理及びセキュリティ監査に用いることができ、並びに、一般的な情報的分析及びメッセージデバッギングにも用いることができる。これは広範な装置（プリンタ及びルータ等）及び様々なプラットフォーム上のレシーバによってサポートされている。このため、多くの異なるタイプのシステムからのログデータを中央レポジトリに統合するためにsyslogを用いることができる」（http://en.wikipedia.org/wiki/Syslog）。

Rainer Gerhards氏によって開発されたRsyslogは、syslogを拡張したものであり「ＩＰネットワーク内にてログメッセージを転送するためにUNIX（登録商標）又はUNIXライクなコンピュータシステム上で用いられるオープンソースソフトウェアユーティリティとしたものである。これは基本的なsyslogプロトコルを実装して、内容フィルタリングとリッチフィルタリング機能性と柔軟な構成オプションとでそれを拡張し、TCPを伝送に用いる等の重要な特徴を追加する」（http://en.wikipedia.org/wiki/Rsyslog）。

このようなログは「実在的」なコンピュータシステムについてだけでなく仮想化されたコンピュータ（「仮想マシン」、ＶＭともいう。）についても維持されることができ、ＶＭ自体のシステムや状態に関しての変化をイベントとしてログすることができる。もちろん、イベントはコンピュータに限定されるものではない。別の例としては、電話会社は、音声・テキスト・ネットワーク通信に関しての交信を含む加入者の電話のあらゆる使用をログし、多くの場合タイムトラッキングも含まれ、用途は請求目的に限られない。つまり、デジタル形式にて記録・格納できる任意の活動は、ログすることができる（ロガブルな）イベントとしてみなされることができる。

様々な類いのレコードにデジタル署名を付す方法に関しては、多種の周知な方法がある。ロガブルなイベントは、単体的又は集合的に、このようなレコードとして処理され及び適当なものとして署名されることができ、後に提示されるに際してこれらのイベントのログ又は個別的に署名された何らかのサブセットが、署名されたものに完全に一致することについての一定程度の確実性を提供することができる。もっとも、１つのあり得る問題としては、イベントログ又は他のデータセットに含まれるデータが許容できない程に低いエントロピーを示す場合、即ち想定され得る入力データの幅が限定的すぎるか過度に「秩序化」されている場合が考えられ、例えばデータの取り得るバリエーションが比較的少数であったり、あるエントリを与えられた場合について特定のエントリが出現する確率が比較的高いものとなったりする場合がある。したがって、全てのあり得る一般的なドキュメント又はデジタルレコードの母集団は、網羅的な（全ての可能性を試みる態様の）分析の成功を阻む程に膨大であるものの、イベントが対象となる場合には、これが真とはいえない又は多くのユーザが望む信頼度にてこれが証明できないことがある。分布可能範囲が十分に小さいがために、網羅的な「ブルートフォース」攻撃が、任意のデータ署名スキームの何もなければ本来備わっていたであろうはずのセキュリティの突破に成功してしまうというこのような性質を、システムイベントログが多くの場合有し得る。もちろん、一般的な高エントロピー環境下でも、追加的で証明可能なセキュリティについての確証性は、いつでも望ましいことである。

様々な情報システムからのログが、従来以上に証拠として用いられるようになってきている。この傾向下においては、ログデータの維持及び提示に関しての要件も増加している。完全性（integrity）及び信憑性（authenticity）、即ちログ内の情報が改ざんされていない又は別のものと丸ごと差し替えられていないことについての確証は明確な要件であり、特にログデータが、紛争解決に用いられる場合、法的手続や税務調査等の証拠として提出される場合、マイグレーションを境に仮想マシンが変更されていないことについて確証を与えるために用いられる場合、金融取引についての証拠を提供するために用いられる場合、電話使用量を検証する場合等においてはそうであるといえる。情報システムは自己の全てのアクティビティを逐次的にログするがために、多くの場合、紛争に関するトランザクションの詳細事項内にはログ内の他の情報が散在していることになる。無関係なイベントの機密性を保持するためには、署名されたログから一部のレコードのみを抽出してなおその完全性を証明できるようにすることが望ましい。上述のことから、ログ署名スキームに関しての次の設計目標の全部又は少なくとも一部について対応する必要がある：
・ ログ全体の完全性を検証できるようにして検出不能な態様でのレコードの追加、削除、変更ができなくなるようにすること。
・ ログ内の他の任意のレコードの内容について何らの情報を漏出させずに、任意のレコードの完全性を証明可能とすること。
・ 署名プロセスは、時間及び領域の両面で効率的にすること。（理想的には、処理オーバーヘッドがレコード毎についての小さい定数的なものとなり、格納オーバーヘッドがログ毎についての小さい定数的なものとなる。）
・ 抽出プロセスは、時間及び領域の両面で効率的にすること。（理想的には、ログの大きさとの関係で亜線形時間にて、任意のレコードについて小さい定数的なサイズの完全性証明を抽出できるようにする。）
・ 検証プロセスは時間の面で効率的にすること。（理想的には、検証されるのがログ全体であるか又は単一のレコードであるかを問わずに、被検証データのサイズについて線形時間で実行される。）

米国特許第７，６９８，５５７号明細書 米国特許第８，３４７，３７２号明細書 米国特許第８，３１２，５２８号明細書

本願発明は、システムに入力されてシステムによって署名された後に、デジタル入力レコードのセットが変更されていないことを検証するためのシステム及び方法に関する。網羅的な攻撃の成功率が許容可能な水準を超える程に可能入力の母集団が小さい場合、即ち入力レコードのエントロピーが許容不可能な程に低い場合において、本願発明は追加的なセキュリティ機構を提供することによって特に役立つ。入力レコードが次のようなものの場合において先述の状況が多々として妥当する：コンピュータシステム（物理的及び仮想的なものの両方を含む）、電話や他の通信装置、コンピュータ制御マシンやプロセス等についてのシステムログや他のイベントログ等の類いのイベントログである場合。もっとも、本願発明は、強化されたセキュリティが望まれる任意の状況において用いることができ、ある者が検証可能としたい高エントロピーデータも対象に含まれる。

本願発明の様々な特徴を説明するために下記において用いられる主たる例はsyslog、rsyslog、Windows（登録商標）イベントログ等についてのものである。既述のように、これらは特に関連のある状況ではあるものの、それでもなお例示にすぎない。

検証ツリー構造内へのブラインディングマスクの算入を示す図である。 カノニカル２分木を示す図である。 カウンターモードでの本願発明の実施形態を示す図である。 一般化されたデジタルレコード検証・署名インフラストラクチャの様々なレイヤーを示す図である。 検証インフラストラクチャを、異なるレイヤー内で保持及び演算される様々なデータ及び演算構造とともに示す図である。 デジタル署名及び署名を用いて行う認証値の再計算を示す図５についてのサブセットを示す図である。 永続的なトラストフリー認証フィーチャを作成する公開を示す図である。 再計算によって行われるシステム独立な認証を可能とするためのデジタル署名の拡張を示す図である。

データモデル
本願発明の実施形態は、上述の目的ほぼ全てを達成するデジタルデータ署名スキームを提供し、一部の選択された実装例では効率性目的に関して幾ばくかのトレードオフは生じるものの一般的にはこれがセキュリティ目的を害するには至らない。イベントログをセキュアかつデジタル的に署名することとの関係で、純粋に例示的な観点から本願発明の特徴が以下説明され、本願明細書の別の箇所でも述べているように署名すべき他のタイプの入力レコードについても本願発明を用いてセキュリティを増強することができる。

ログを生成するコンピュテーショナルプロセスは原理的には無期限的に実行され続けることができるため、抽象的客体としてのログは明確に定義された始点と終点を有することを要さない（がもちろんこれを有することもできる）。下記においては、例示として、ログはブロックの順序立てられたシーケンスとしてモデル化される。つまり各ブロックは有限個数のレコードの順序立てられたシーケンスである。例えば図１では、ログ１００は、イベントのシーケンス… e(k-l), e(k), e(k+l), ..., e(k+5) ...を含むものとして示されている。極めて簡略化された例としては、e(k+l) - e(k+4)はブロックＢ１にグループ化されているものとして示されている。殆どの実際的状況においては、各ブロックは４件を遙かに超えるエントリを含むことができ、千件単位や百万件単位のオーダーとされることができるが、一般性を失わずに図示を容易化するためにＢ１は４件のみのエントリを有するものとして図中で示されている。システム設計者は、本願発明の特定の実装例について適切なブロックサイズを如何にして選択するかを知っている。

多くの実用的なロギングシステムはこのように機能し、例えばsyslogの場合には出力が定期的にローテーションされるログファイルに送られる。最も素直な戦略は、各ログブロックを単位として署名を付するというものであり、ブロック全体の処理に関する要求の全てを充足するが、ブロック内の残余の事項全てを露見させずに個別のレコードの完全性を証明することを不可能とする。もう一つの戦略として、各レコードに個別的に署名を付するというものが考えられるが、署名を付するというオペレーションがかなり大きな消費を伴うオペレーションであり署名のサイズが典型的なログレコードのサイズをたやすく超えてしまうため、必然的に処理及びストレージの両面で高いオーバーヘッドを伴い、さらに重要なことには、レコード及びそれについての署名に対しての削除はこのスキームでは通常検知されないため、ログ全体の完全性を包括的に保証することもできない。

上記の不十分な戦略両方に対しての改良としては、ログブロック内の各レコードについてのハッシュ値を算出して、そしてレコード自体ではなくハッシュ値のシーケンスに対して署名を付することが考えられる。この戦略は、ログブロック全体の完全性を保証し、各レコードに対して個別的に署名を付するのに比してオーバーヘッドを著しく低下させ、また、単一のレコードが証拠として必要とされた場合にログブロック全体を引き渡す必要性をなくするが、レコードについての証明のサイズはブロックサイズに対して依然線形であり、忙しいシステムにおいてブロックサイズはたやすく数百万レコードにも及ぶ。

本願発明は、処理すべきブロックのサイズを定義するための特定の方法に依存するものではない。１つのありふれたかつ自然な選択肢は、本願でも例示されているように、ブロックを特定の件数のエントリを有するものとして定義することである。この選択肢の１つの利点は、望まれるのであれば処理又はインデキシングが簡易に行える任意の件数、例えば２の累乗等、にブロックサイズを設定することができるという点にある。別の選択肢は、特定の時間インターバルにおいて生じる全てのエントリをブロックとして定義することである。さらに別の選択肢としては、特定のイベントをトリガとして定義して、１以上の開始イベント（例えば、仮想マシンのマイグレーション、選定されたプロセスの実行への切り替え、入出力要求等）の発生によって新規のブロックを開始して、また、任意の終了イベントの発生によって該ブロックを終結して処理することもできよう。熟練したプログラマはさらに他の選択肢をも知っており、例えば複数の選択ルールを伴うそれや、数値的及び時間的な制限及び／又はトリガをいずれも組み合わせるそれ等が含まれる。

より汎用的なデジタルレコードに関する入力セットに適用するために設計された本願発明の実装例では、任意の既知の方法を用いてそれらを不明瞭性のない処理用及び署名用のデジタルデータセットとして定義することができる。既述のように、本願発明は、比較的に低エントロピーな入力レコードのセットについての個々の構成要素の検証のために特に有用であるが、より汎用的には、デジタル形式に変換された又は当初からデジタル形式で作成された一般的なドキュメント、保険・財務・法律・医療に関する記録や結果、他の試験データ、ＳＭＳ電話メッセージ（電話での「テキストメッセージ」）、ハードディスクのサブセット、仮想マシンの全部又は一部の状態を表す１以上のファイル、セキュアに検証を行いたいと考えられる任意の様々な種類のデジタルレコード等の比較的高エントロピーな入力レコードのセットに関しても追加的なセキュリティを提供するのにも用いられることができる。

ブラインディングマスクを伴うマークルツリー
単一のレコードについての証拠のサイズをさらに削減するために、マークルツリー（Merkle tree）データ及び計算構造を用いてレコードをアグリゲートすることができ、同ツリーは２分木であり、そのリーフはレコードのハッシュ値であり、各非リーフノードはその子ノードの値の連結についてのハッシュ値として計算される。このようなマークルツリー構造又は類似のハッシュツリー構造は、（本願発明による適応を伴って）データ署名インフラストラクチャと共に用いられることができる。そして、ハッシュツリーのルートノード内のハッシュ値がデジタル的に署名されることができ、各リーフノードについてはコンパクトな（リーフ数が対数的である）証明であって、リーフ内のハッシュ値が署名されたルートハッシュ値を導出した計算に参加したことが示される証明、を抽出することができる。しかしながら、２つの問題がある。第１の問題は、このようなアグリゲーションスキームのセキュリティが参加証明として許容されるハッシュチェーンの形状について幾つかの制限を課した場合にしか一般的に証明することができない、という問題である。これを達成するために十分な方法としては、ハッシング前に子ノードからの連結ハッシュ値にサブツリーの高さを付加するという方法があり；これによって、検証時に許容されるハッシュチェーンの長さが制限されて、スキームのセキュリティを形式論的に証明できるようになる。

第２の問題は、マークルツリーから抽出された１つのノードに関してのハッシュチェーンが他のノードのハッシュ値を含んでいるということである。強度の高いハッシュ関数については一般的に直接的な逆算を行って連鎖内のハッシュ値をもたらした入力値を推知することはできないが、典型的なログレコードはこのことを成立させるためには不十分なエントロピーしか有さない場合があり、入力のパターンを知る攻撃者であれば、全ての可能性を網羅的に試して連鎖中に実際存在するハッシュ値をもたらす入力を見つけ出してそれによってレコードの内容を知ることができる場合がある。このような類いの情報を有した上での総当たり攻撃を阻止するために、本願発明によれば、好適にはハッシュ値をアグリゲートする前に各レコードに対して十分なエントロピーを有するブラインディングマスクを追加する。

図１は、チェーンドマスキングハッシュツリー（chained masking hash tree）２００である計算コンポーネント並びにインターリンク及びブラインディングマスクを有するマークルツリーを用いたログサイニングについての該コンポーネントの使用方法を示し：rec_iはサインされるべきレコードであり；r_iはレコードのハッシュ値であり；rndは乱数又は疑似乱数であり；m_iはブラインディングマスクであり；x_iはリーフであり；x_a,bはマークルツリーの内部ノードであり；x_rootはサインされるべき値である。図示の実施形態においては、各入力レコードrec_iは各イベント（e(k+1) ... e(k+4)）の１つである。代替的な適用例においては、r_iはアグリゲータからのルートハッシュ値であり、x_rootはコアによって計算されたカレンダー値であり、「アグリゲータ」と「カレンダー値」と「コア」という用語は以下において有利なサイニングインフラストラクチャの一例との関係で説明される。

図１は、結果として得られるデータ構造を示し、ハッシングプロセス及びサイニングプロセスは次のように実行されることができる：
・十分に強度のあるハッシュ関数が選択される。
・各ログブロックそれぞれについて好適には一意でランダムな番号rndが生成される。簡潔性のためにすぎないが、厳密に言えば「疑似乱数的」であるにすぎない場合においても番号rndは「乱数的」なものである。後述する再計算用途との関係で番号が保管されている限り、純粋に乱数的な番号をも用いることができるが、多くの場合においてはこれは過度に複雑なこととなる。例えば、図１においては、乱数rnd_B1は、ブロックＢ１について生成されたものとして示されている。乱数の生成（より正しく言えば疑似乱数の生成）は周知の手順であり、任意の既知の手法を用いて各イベントブロック毎にrndを生成することができる。計算効率及びセキュリティの観点からは、rndの値は好適にはハッシュ関数の出力と同程度の長さとされて、ログデータ自体と同じ機密性をもって管理され、暗号学的ハッシュ関数に精通している者は自らの具体的な実施形態の要件を充足させる上でrndのサイズをどのように選定すれば良いのかを理解している。
・ブロック内の各レコードrec_iについて：
− レコードのハッシュ値は、r_i= hash(rec_i)として計算され、ここでrec_iはレコードの内容である。
− ブラインディングマスクはm_i= hash(x_i-1 || rnd)として計算され、ここでx_i-1は先のレコードのリーフノードからのハッシュ値であり、rndは現在のブロックについて生成された乱数である。所与のブロックにおいて全てのx_i-1についてハッシングを行うに際して同一の乱数を用いることの利点としては、セキュリティを実質的に低下させずにストレージと計算量の観点からの負担を著しく減少させることができるという点が挙げられる。ここで、所与のブロックにおいて千件単位あるいは数百万件単位のイベントがあり得ることが想起され、イベント毎に別個の乱数を生成して格納及び関連付けていたのでは無用に時間及び記憶領域を消費することになってしまう。先のレコードが先のログブロックの最終レコードである場合があり、このようなインターブロックリンキングによってログからブロックが削除されていないかについて検証を行うことが可能となる。ログの第１のレコード（第１ブロックの第１レコード）については、存在していないx_i-1の代わりにゼロハッシュ値を用いることができる。なお、rndとこのプレースホルダー値とをハッシングする必要は依然として存在する；なぜならば、ハッシングしなければ第１レコードについてのハッシュチェーンがrndの値を漏出させてしまう可能性があり、転じてこれが他のレコードについて総当たり攻撃を行うために利用され得るからである。
− ツリー内のレコードに対応するリーフノードのレベルはl_i = 1として定義される。
− リーフについてのハッシュ値はx_i= hash(m_i || r_i|| l_i)として計算される。
・各非リーフノードx_a,bについて：
− ノードのレベルはl_a,b = max (l_a, l_b) + 1として定義され、ここでl_a及びl_bは子ノードのレベルである。
− ノードについての値はx_a,b= hash(x_a || x_b|| l_a,b)として計算され、ここでx_a及びx_bは自らの子ノードからのハッシュ値である。最後に、ルートノードx_root内のハッシュ値については上述のようにして署名を付す。

本願発明の特定の側面に関しての様々な例についての本願明細書では、標準的なハッシュ関数表記法が用いられており、異なるハッシュ関数が評価される。したがって、例えば連結（concatenation）を示すのに「||」が用いられる。本願発明は、例示されたハッシング順序を必要とはしていない。例えば、システムは、m_i = hash(x_i-1 || rnd)に代えてm_i = hash(rnd || x_i-1)として計算を行うことができ、または、x_a,b = hash(x_a|| x_b|| l_a,b)に代えてx_a,b = hash(x_a|| x_b || l_a,b)として計算を行うことができ、本願発明の任意の実装例が選定されたハッシング順序を一貫して用いる限りこのようにできる。なぜなら、典型的にはハッシュ関数について入力値との関係では交換則が成立しないからである。

このようなツリーを構築して署名を付したならば、任意のリーフからルートへのハッシュチェーンを抽出して、署名されたルートハッシュ値をもたらした計算においてそのリーフが関与したことの証拠としてそれを提出することができる。

例えば、rec₂それ自体が署名されたログブロックrec₂の一部であったということを証明するには、(right; m₂); (right; x_i); (left; x_3,4)とのシーケンス及びルートハッシュ値についての署名が提示される。「真正な」rec₂であると銘打ってある入力レコードが提示されたと仮定する。即ちこれは当初においては「候補」である。そして、検証者は以下のように再計算することができる：

そして、新たに計算されたx_rootが署名と一致することを検証する。一致する場合、候補入力レコードについては、x_rootのセキュリティレベルで検証がされたことになる。そして、x_rootがデジタル的に署名されて検証された場合、候補入力レコード自体もこのセキュリティレベルで検証されたことになる。

ここで説明した方法、即ちツリー構造におけるハッシュ計算にブラインディングマスクが追加される方法は、「ソルティング」（“salting”）として知られる手法とは異なるということに留意されたい。後者では、乱数（「ソルト」）が１対１の関係でパスワード／パスフレーズと関連付けられてそしてソルト＋パスワードの組合せがハッシュされる。そして、ハッシュ及びソルトが格納される。http://en.wikipedia.org/wiki/Salt_(cryptography) において説明されているように、「ソルトは、大量のパスワードに対してなされるクラッキングにおける辞書攻撃及び総当たり攻撃を格段に遅らせる（しかし、１つのパスワードのみをクラックする場合には妥当しない）。ソルトがない場合、一挙に大量のパスワードをクラッキングする攻撃者は、各パスワードについての推測を１回ずつハッシュして全てのハッシュと比較するだけで済む。要約すれば、ソルティングは単一のパスワード／パスフレーズと（少なくとも格納されているが故にハックされてしまう可能性にさらされているという意味で）既知のソルトとに基づく既知の関数の何らかの出力との１対１の関連付けを典型的に伴うため、ソルティングでは一般的には逆算を遅れさせることができるが、逆算されてしまう可能性がある。ソルト及びハッシュ出力は知られているため、入力データが典型的なパスワードの母集団と比べてより低いエントロピーを有する場合には、総当たり攻撃が許容不能な程度に実施可能なものとなる場合が多くなる。

対照的に、本願発明のハッシング構造では、x_i又はx_a,bの値から（攻撃者が既に有しているレコードを当然除く）任意の入力レコードに逆算することが実際的に不可能となる。なぜならば、所与のブロック内の全エントリに単一のrndが適用される実装例においても、攻撃者はrnd値へのアクセスを有していないからである。

カノニカル二分木（Canonical Binary Trees）
上記の議論では、マークルツリーの形状を指定していない。リーフの個数が２の累乗であってイーブンな場合には完全な２分木を構築するのが自然と思われるが、他の場合においては適切な形状が必ずしも明らかであるとはいえない。もっとも、唯一の要請は、ツリーを決定性を伴う態様で構築して、署名者が構築したツリーと完全に同一なツリーを検証者が構築できるようにすることである。ただ、実際的な考慮要素としては、個々のレコードの完全性証明を対数的なサイズに留めることを達成すべきであり、このためにはツリーは過度にアンバランスされていないほうが望ましい。したがって、ｎ個のリーフノード（図２ではｎ＝１１について図示）を有する構築可能なカノニカル二分木の１例が図２に示されている。図２では、３つの完全ツリー（２重リングのノード）にグループ化された１１個のリーフ（１重リングのノード）が、最小限の高さを有する１つのツリー（３重リングのノード）にマージされる。ツリー構築プロセスは次のように行える：
・ リーフノードは左から右へ向かって配される（図中の１重リングのノード）。
・ リーフノードは左から右へ向かって完全な２分木に集約され、依然利用可能なリーフを用いて各ツリーを最大限大きくする（図中の２重リングのノードを追加）。
・ 完全なツリーは左から右へ向かって単一のツリーにマージされ、これは各ステップで２つの最も小さいツリーを結合することを意味する（図中の３重リングのノードを追加）。

カノニカルツリーの有用な性質としては、ツリーの最終的なサイズを予め知らずにして新たなリーフノードが到着するに合わせてオンラインで構築していくことが可能な点と、対数的な個数だけのノード（即ち、これまでに構築してきた完全ツリーのルートノードだけ）をインメモリに格納しておくことで済む点が挙げられる。したがって、ここで概要が示されるスキームを用いるならば、全てのセキュリティ要件は達成され、また、性能要件の殆ども達成される：
・ 最小限で、１つのブロックあたりたったの１つのハッシュ値を（rnd）、署名それ自体に加えて格納することになる。
・ ログを署名するには、１つのレコードあたり３つのハッシングオペレーションと１つのブロックあたり１つの署名オペレーションとが必要となる。
・ ログを検証するには、１つのレコードあたり３つのハッシングオペレーションと１つのブロックあたり１つの署名検証オペレーションとが必要となる。
・ 個別のレコードの完全性の証明を抽出するには、１つのレコードあたり３つのハッシングオペレーションが必要となる。これは、抽出における亜線形性能（sub-linear performance）の望ましいが非本質的な目標に満たないが、後述するように、増大した格納オーバーヘッドの代償を払うことによって実行時間の削減を達成することができる。
・ 個別のレコードの完全性証明としては、（ログブロックのサイズとの関係で）対数的な個数のハッシュ値と１つの署名を引き渡す必要がある。これは形式的には定数サイズとはならないが、実務上では依然十分に小さい。
・ 個別のレコードの完全性証明の検証するためには、対数的な個数のハッシングオペレーションと１つの署名検証オペレーションとで足りる。

参考例としての手順
このセクションでは、例示的な観点においてのみではあるが、ログブロックをアグリゲートすることと、個別のレコードの完全性証明を抽出することと、そのような証明に基づいてレコードを検証することとについての参考例としての手順を提示する。また、増大した格納オーバーヘッドの代償を払うことによって獲得し得る追加的なセキュリティ上の利点又は実行時間についての削減に関しての幾つかの可能なトレードオフについても述べる。これらの参考例としての手順は、本願発明の１つの実装例のそれぞれの機能性を実装するための１つの手法を熟練したプログラマに見せるために含めてあるだけであることを強調する必要がある。このようなプログラマは、本願発明の主要概念から逸脱することなく、詳細事項、データ構造の配置、プログラミング言語の選定等に関して、当然自己の設計的嗜好を有する。

ログレコードのアグリゲーション
手順例１では、署名又は検証のために、レコードについてのブロックについてアグリゲーションを行う。入力に関しての説明はレコードを1, ..., Nと番号付けするが、Nの値は使用されず、手順例はレコードをオンラインで処理するための実装例に容易に用いられることができる。平準化されたレコードあたりの処理時間は定数であり、レコードあたりの実際的な最悪シナリオ時の処理時間はブロック内のレコード数との関係で対数的であり、必要とされる補助ワーキングメモリのサイズについても同じである。

ブロックを署名するには：
・ 新規でランダムな値がrndとして生成される。
・ 現在ブロックのログレコードと、rndと、先のブロックからの最後のリーフハッシュ値とが、手順例１に入力される。
・ 結果として得られたルートハッシュ値が署名され、かつ、このブロックからの最後のリーフハッシュ値が次のブロックにアグリゲーションの対象として渡される。
・ 最低でも、rndとルートハッシュ値についての署名とは事後の検証のため保存されなければならない。

署名されたブロックを検証するには：
・ ログレコードと、署名が付されている間に保存されたrndと、先のブロックからの最後のリーフハッシュ値とが、手順例１に入力される。
・ 改めて再計算されたルートハッシュ値が、保存されている署名と比較して検証される。

厳密に要求はされていないが、実際上、rnd及び署名に加えて、先のログブロックの最後のリーフハッシュ値も好適には保存されるべきである；さもなければ、現在検証のために要求されている入力を得るために、現在ブロックについての検証プロセスで先のブロックについて再ハッシュを行う必要が生じてしまうからである。一貫したストレージポリシーを仮定すると、このためには、転じて、その次の先のブロック等についても再ハッシュを行う必要が生じる。このようなことはもちろん非効率的であるが、より危険なこととしては、いずれかのログブロックにでも損傷が及ぶと、任意の後続のログブロックについて検証を行うことが不可能となってしまうという危険がある。なぜならば、検証のために必要とされる１つの入力がもはや利用不能となってしまうからである。

ネガティブなシナリオをより詳細に検討するに、失敗となった検証から導出される唯一の結論は、ログブロック又は認証データにおいて何かが変更されたという結論である。より正確に変更を検出することが望ましい場合、手順例１によって計算されたレコードハッシュ値r_i又はリーフハッシュ値x_iを他の認証データと共に保存することもできる。そして、レコードあたりの小さな格納オーバーヘッドの代償の下で、一連のハッシュ値を署名との間で認証して、また、各レコードを自らのハッシュ値との関係で検証することができる。また、レコードハッシュを保存するべき場合、ブラインディングマスクが阻止すべきものである情報を有した上での総当たり攻撃に該レコードハッシュが用いられるのを予防するために、それらはログデータ自体の機密性と同じレベルで保管されるべきであることにも留意されたい。

手順例１ − 署名又は検証のために、レコードについてのブロックについてアグリゲーションを行う

上記について、以下の通り：
Rec_{1 ... N}：入力レコード
rnd：ブラインディングマスクについての初期値
x₀：先のブロックの最後のリーフハッシュ（これが第１のブロックである場合、ゼロフィルされる）
{Initialize block: create empty roots list}：｛ブロックを初期化：空のルートリストを作成｝
R：＝空リスト
{Process records: add them to the Merkle forest in order}：｛レコードを処理：順番でそれらをマークル森に追加｝
{Add x_i to the forest as new leaf, update roots list}：｛新規のリーフとしてx_iを森に追加、ルートリストを更新｝
{Finalize block: merge forest into a single tree}：｛ブロックを確定：森を１つのツリーにマージ｝
root：このブロックの（署名又は検証されるべき）ルートハッシュ
x_N：このブロックの最後のリーフハッシュ（次のブロックへのリンキングのためのもの）

ハッシュチェーンの抽出
手順例２では、個別のレコードの完全性を証明又は検証するのに必要なハッシュチェーンを抽出する。核となる手順は手順例１のそれに類似しており、ターゲットレコードに依存するハッシュ値についてトラッキングが行われ、また、該トラッキングに基づいてハッシュチェーンを収集する。

手順例２ − １つのレコードを検証するためにハッシュチェーンを抽出する

上記について、以下の通り：
Rec_{1 ... N}：入力レコード
pos：ターゲットレコードのブロック内での位置（1 ... N）
rnd：ブラインディングマスクについての初期値
x0：先のブロックの最後のリーフハッシュ（これが第１のブロックである場合、ゼロフィルされる）
{Initialize block}：｛ブロックを初期化｝
R：＝空リスト
C：＝空リスト
{Target record not in any level yet}：｛ターゲットレコードはどのレベルにも入っていない｝
{Process records, keeping track of the target one}：｛レコードを処理し、ターゲットとなるものについてはトラッキングを維持｝
{Target to be added to right on leaf level}：｛リーフレベルでターゲットを右方に追加｝
{Moving target to left}：｛ターゲットを左方に移動｝
{Merging target to right for next level }：｛次レベルへ向けてターゲットを右方へマージ｝
{Moving target to left}：｛ターゲットを左方に移動｝
{Finalize block: merge forest into a single tree}：｛ブロックを確定：森を１つのツリーにマージ｝
{Moving target to right}：｛ターゲットを右方に移動｝
{Merging target to right for next level}：｛次レベルへ向けてターゲットを右方へマージ｝
C：レコードからブロックのルートへのハッシュチェーン

上記の手順例での選択肢を適用すると、出力値は一連のトリプルとなる（方向、兄弟ハッシュ、レベル補正）。方向は、着信するハッシュ値と兄弟ハッシュ値との連結順序を意味する。等しくない高さの２つのサブツリーがマージされており下位サブツリーのルートからマージされたツリーのルートへのステップにおいてノードレベル値が１より大きい増分で増える場合を捕捉するために、レベル補正値が含められている。（図２における下位の３重リングノードから上位の３重リングノードへのステップが一例である。）手順例２は手順例１に密接に基づいているため、該手順の性能は似たようなものとなり、ハッシュチェーン抽出における亜線形実行時間の提示された理想には若干届かない。しかし、このことはsyslog統合においては実際の問題とはなり難い。なぜならば、提示すべきレコードを検索することが典型的には線形時間を伴うタスクである以上、証明抽出時間を減少させても合計時間に関して重要な向上はもたらされないからである。もっとも、必要であれば、領域を時間と交換して、レコード毎に２つのハッシュ値を格納するという代償を払って、ハッシュチェーン抽出に関して対数的な実行時間を達成することができる。実際に、マークルツリーのノードの全て（図１において「x」ノードとして示されている）の値が保持される場合、新たなハッシュ計算を伴わずにしてハッシュチェーン全体を抽出することができる。例えば、手順例１においてx_i及びR_jとして計算される順序で同一サイズの値が、格納される場合、ハッシュ値をインデキシングして定数時間でそれぞれを検索することができる。同様の効果を得るのに他の手法を適用することもできる。

また、この手順例において完全体のログファイルにアクセスする必要があるのは機密性目標においての妥協とはならないことにも留意されたい。なぜならば、抽出プロセスはログファイルの所有者によって実行されることができ、かつ、関連性のあるログレコード及び手順例２で計算されたハッシュチェーンのみが外部の当事者に提供されるからである。

ハッシュチェーンの計算
本願発明の１つのプロトタイプにおいては、手順例３では、入力ハッシュチェーンの抽出元となったマークルツリーのルートハッシュ値が計算される。手順例２で生成されたハッシュチェーン及び対応するログレコードは、通常手順例３に入力され、出力ハッシュ値は署名との関係で検証されてレコードの完全性が証明される。

手順例３ − ハッシュチェーンからルート値を計算する

上記について、以下の通り：
Rec：入力レコード
C：レコードからブロックのルートへのハッシュチェーン
{direction, Sibling hash, Level correction}：｛方向、兄弟ハッシュ、レベル補正｝
root：このブロックの（署名を用いて検証されるべき）ルートハッシュ

本願発明の一部の実装例では、それぞれのブロックに関連付けられているx_root.値のレベルまで入力イベントを検証できさえすればユーザは満足するであろう。ここで、（望ましいが厳密には要求されていないものの）現在ブロック内の第１の値x₁についてのハッシュ値の計算に先の値x₀が含まれている場合、x_root..には以前のブロック全てからの情報もエンコードされていることになるという点を想起されたい。少しでも望まれる場合においては、任意の標準的な署名を用いてデジタル的にx_root..に対して署名を付することで十分となる。もっとも、格段により大規模となり得るフレームワークについてもx_rootの完全性を担保してさらに高度なセキュリティを提供するデジタル署名方法について後述する。換言すれば、図１及び図２に示した構造１００、２００内にて個別のイベントを検証できるものの、加えてx_root..について適切な署名システムを選定することによってさらなるセキュリティを提供することができる。

図１及び図２で示されて上記で説明された本願発明の実施形態は、値の連鎖化（chaining）を含み、チェーニングについては先のエントリブロックの最後の値x₀から行われ、rndとハッシュされてハッシュ値m₁が作成され、今度はそれがr₁とハッシュされてx₁が提供される。換言すれば、各「m」値からそれに続く「x」値に至り、それに続く「m」等に至る計算の「連鎖」が存在する。これだけが可能な実施形態ではない。例えば図３では、マスキングハッシュツリー計算モジュール２００についての「カウンターモード」の実施形態が示されており、m_jを計算するに際してはrndに関して先のx値x_j-1とのハッシングは行われない。代わりに、各m_jは好適には現在ブロックのrndとブロックレコード番号jとのハッシュとして計算される。したがって、m_j = hash(rnd || j)である。図１及び図２のチェーンモード実施形態についての説明が与えられれば、熟練したプログラマにとっては、x_rootを計算して後にrec値を検証するためのルーチンに加える変更は自明のものとなる。

実装例についての詳細
このセクションでは、syslog又は類似のイベントメッセージを署名するための、本願発明の１つの実施形態についての例に関しての実装方法に関する実際的な考慮事項についての概要を述べる。熟練したプログラマは、他の実装例のための適切な手順をどのようにして選定すれば良いかを知っている。可能な様々な展開シナリオの一例として、ここでの例は、Rainer Gerhards, The Syslog Protocol, RFC 5424, IETF, 2009において述べられているログ収集装置上のテキストファイルに向けられた出力に対して署名することについて専念している。

ログローテーション
ログが順序づけられたブロックのシーケンスとしてモデル化され、そして各ブロックが有限個のレコードの順序づけられたシーケンスであると仮定し、syslog出力が定期的にローテーションされるログファイルに送信される状況は、このモデルの一例であると解釈することができるという点に留意されたい。ここでは該モデルを改良して、物理ブロック（ローテーションされるファイル）を論理ブロック（署名により黙示されるもの）と区別する。なぜならば、ログファイルをローテーションする頻度よりも細かい粒度を用いてレコードに署名するのが多くの場合望ましいからである。実際的な理由から、システムは、ログファイルが複数の署名されたブロックを含むことを許容し得るが、サインされたブロックがファイル境界を跨がってスパンすることを禁止することができる。このため、ログがローテーションされた場合、現在の署名ブロックは常にクローズされており、新規のログファイルの先頭から新規のブロックが開始されることになる。もっとも、先のブロックの最後のレコードから次のブロックの最初のレコードへのハッシュリンクはファイル境界を跨がるが、どのようにファイルがローテーションされていようとログ全体の完全性を検証することが依然可能とされる。

マルチテナント環境におけるレコードレベルでのログサイニング
本願発明はマルチテナント環境におけるレコードレベルでのログサイニングについても実施されることができ、該環境とは、２以上の異なって定義されたエンティティが同一のログにログされるイベントを生成している環境を意味する。このような環境下では、ログの扱いに関して幾つかの一般的な仮定をするのが有用である。第１の仮定は、ログには異なるエンティティからのレコードがインターリービングされており、また、それぞれのテナントに引き渡す前にこれらのログを分離する必要があるということである。第２の仮定は、インターリービングされたログでは、各レコードの出所が明確に決定可能であるということである。この第２の仮定が破られた場合、ログ分離問題については有効な解決策がなくなり、署名分離の問題が不要となる。

マルチテナント局面の１つの性質としては、共通ログをインターリービングされたスレッドのセットに分離することが予め定められていることであるということが挙げられる：任意のログ処理における第１のステップはテナント毎にレコードを分離することであり、その後に各テナントが自己のサブセットに対して何らかのさらなる分析を行うことが想定される。したがって、各スレッドの完全性に加えてログ全体の完全性をも保護する署名メカニズムを提供することが有用となり得る。署名処理のオーバーヘッドが小さいことを考慮すると、１つの可能な解決策としては、各テナントのスレッドを共有ログ内の仮想ログとして捉えて、そして、ログ内の全てのレコードを含むグローバルスレッドに加えて各スレッド内のレコードについてリンキングとサイニングを行うということが考えられる。共通ログのＮ個のレコードがＫ個のテナント間でおおよそ等しく分割されていると仮定すると、インメモリで保持されるべきlog(N)サイズのルートリスト及びログ全体について長期的にアーカイブされるべき１つの署名に加えて、サーバは、Ｋ個の追加的なlog(N/K)サイズのルートリストを保持して、Ｋ個の追加的な署名をアーカイブする必要がある。

テナントの個数を漏出することを代償として、署名の数を１に再度減らすことが可能であり、そのためには、１つの追加的なアグリゲーション層（図１ではツリー中の１つの追加的な「レベル」に対応する）を追加して、Ｋ＋１個のルートハッシュ値を１つに合体させて、このアグリゲートに関してのアグリゲートたるものだけに署名することができる。そして、レコード自体（及び望む場合にはレコード毎のハッシュ値）を単体のコピーとしてホストで依然保持することができる。（そして、関連のあるレコードについて複製を作成して各テナントに提供することができる。）そして、各テナントは、ログが署名されてから自己のスレッドにおいてレコードが変更されておらず、レコードが追加されておらず、また、レコードが削除されていないことを検証することができる。

そして、既述のように、ツリー構造の最上位値x_rootは好適にはデジタル的に署名される。このようなデータに（タイムスタンピングを用いて又は用いないで）署名を付すための適切なスキームは多数存在する。周知かつ公知の極めて多数の方法のうちの３つは、PKCS#7又はOpenPGP署名又はPKI-署名RFC3161タイムスタンプである。

エストニア国タリンのGuardtime ASは、キーを必要としない（デジタル情報の任意のセットとして基本的に定義される）デジタルレコードについての認証を極めて高度な信頼性をもって提供する分散ハッシュツリー構造を含む署名アーキテクチャを開発した。Guardtimeテクノロジについての要約に関しては、例えばhttp://www.guardtime.com/signatures/technology-overview/を参照されたい。また、Guardtimeシステムの特徴は特許文献１、特許文献２及び特許文献３においても開示されている（いずれも発明の名称は「デジタル証明書を生成するシステム及び方法」）。既述のように、本願発明は特定の署名スキームを要するものではないが、Guardtimeシステムについて言及し、そうする理由は、一般的にいえば、同システムの具体的な長所（例えば、高度なセキュリティ、計算効率、実質的に無制限なスケーラビリティ、及びキーを必要としないこと等）及び本願発明の具体的な文脈における具体的な長所に基づく。

分散カレンダーインフラストラクチャを伴う一般的なハッシュツリーベースド検証
図４及び図５に示すように、一般的なGuardtimeインフラストラクチャは複数の異なるレイヤーを有し：幾つかのクライアントシステムを備えるクライアントレイヤー２０００と；ゲートウェイレイヤー３０００と；１以上のアグリゲーションシステムを含むレイヤー４０００と；後において詳述する「コア」を含む最上位レイヤー５０００とを有する。図４は、別個かつ明確に区別できるものとして様々なレイヤーを表すが、インフラストラクチャの主要原理についての一部の実装例では、幾つかのレイヤーを統合若しくは省略し、又は、管理上若しくは他の目的のため追加的なレイヤーを追加する必要があり得る。様々なレイヤーが何を行うか説明する以下の記載を参照すれば、システムアーキテクチャ設計に精通した当業者は先のような変更を如何にして行うべきかを明確に理解するであろう。

図４が示しているように、コアレイヤー５０００は一般的にはシステムのユーザの全部について共通のものとなり、これに対して下位レイヤー２０００、３０００、４０００は多くの実装例ではユーザのニーズ及び好みに従って固有の構成とされることができる。もっとも、「コア／共通」及び「固有／分散」の区別は絶対的ではなく、一部の実装例では、集中的に管理されているシステムたるコアが下位レイヤーでも使用されている構造及び機能を包含することができる。このインフラストラクチャの１つの利点は、非コアレイヤーにてほぼ無制限のスケーラビリティ及び再構成の可能性をもたらして特定の実装例のニーズの充足を可能とすることである。このために要求されるのは、検証システムにデジタルレコードを入力するため及び登録要求を生成するための共通プロトコルを伴って、それぞれのレイヤーが指定された機能を担うことだけである。

図示された構成において、クライアントはデジタルレコードを準備して検証／署名システムに入力するためのシステムである。図１及び図２に示された本願発明と、上述の本願発明との関係によれば、「クライアント」は、ログ１００（又はデジタルレコードの他の入力セットであって、低エントロピーであるか否かを問わないもの）を作成し、かつ、マスキングハッシュツリー２００を組み込んで、実装して、評価する、ハードウェア又はソフトウェアのエンティティである。同じハードウェア及び／又はソフトウェアエンティティがログ１００及びツリー２００を具現化する必要が無いことに留意されたい；例えば、ログ１００のシステムと同じシステム内にあるコンポーネントが、ログエントリを、ブラインディングマスクの生成及びマスキングハッシュツリーの評価に関係するアグリゲーション及びハッシュ計算を行う別個のシステムに送信することができる。本願発明の主要例の具体的文脈においては、検証システムのためのデジタル入力レコードはマスキングツリー計算モジュール２００によって出力されたx_root値となる。

ゲートウェイレイヤー３０００内のゲートウェイは典型的には、クライアントが提出する各デジタルレコードについての登録要求を受信できるように１以上のクライアントと通信可能なサーバ等のコンピュータシステムである。多くの実装例では、ゲートウェイは企業又は何らかの第三者によって管理されたサーバであり、これは、クライアントユーザが所属する組織に知られている若しくは場合によってはクライアントユーザが所属する組織によって管理されているサーバ、又は、インターネット等のネットワークを通じてアクセスされるサーバであってもよい。要するに、一般的にゲートウェイとは、任意の場所に配置されており、かつ、デジタルレコードについての登録要求をクライアントから受信するように構成されている任意のサーバであってもよい。ゲートウェイシステムは同じタイプである必要はなく、むしろ、あるゲートウェイは多数のクライアントを活用する企業内のサーバであることができ、別のゲートウェイは任意のユーザによってオンラインでアクセス可能なサーバであってもよい。もちろん、ゲートウェイは、料金が支払われなければ検証のためのアクセスが許可されないような商業的システムであってもよい。

同様に、アグリゲーションレイヤー４０００内のアグリゲータは、それぞれのゲートウェイによって集約された登録要求を受信するように意図されているサーバ等のコンピュータシステムである。所与の実装例のスケール及び設計上の要求に応じて、任意のアグリゲータは、コアの所有者又はゲートウェイ及びクライアントと同じシステムの所有者によって制御されることができ、又は、全く異なるエンティティによって提供されることができ、一部の場合においては特定のクライアントの集合についてアグリゲータ及びゲートウェイを集約することもできる。例えば、１つの設計上の選択肢は、一組のアグリゲータを「コア」システムの一部分として中央システムに含めて、「コアアグリゲータ」を通じて通信することによって下位レベルの非コアアグリゲータが要求を提出するようにできる。そして、待ち時間を減らすために又は管理上の理由から、１以上のアグリゲータをヨーロッパ・北米・アジアの各々に配置する等してコアアグリゲータを地理的に配置することができる。

別の例では、大企業又は政府機関は、自己の専用システムのみを用いてインフラストラクチャを実装してその利点を享受することを望むかもしれない。対極的な事例により近い場面では、「クラウドコンピューティング」を用いてゲートウェイ及びアグリゲータの全てが構成されていることができ、この場合、クライアントレベルのユーザは特定のゲートウェイ若しくはアグリゲータがいったいどこにあるのか又は誰がサーバを管理しているのかについて全く知らないことになる。このインフラストラクチャの利点の１つは、ユーザ及び他者がゲートウェイ又はアグリゲーションレイヤー３０００、４０００内のシステムを信頼できるか分からない場合であっても、完全に近いセキュリティをもって依然としてデジタル入力レコードを検証できるという点であり；実際には、検証について実質的に完全な信頼性を得るために、コア５０００の管理者を信頼する必要はない。

図５は、図４のインフラストラクチャをさらに詳細に示す。具体的には、図５は、認証プロセスにおいて使用される様々なデータ構造を示す。図５では、様々なクライアントが2010-1, ... , 2010-nとして表され；ゲートウェイが3010-1, 3010-2, ... , 3010-mとして表され；（例示的にすぎない）２つのアグリゲータが4010-1, 4010-kとして表される。アグリゲータは通常、コア内の最下位ハッシュツリーノード内に向かって通信を行う。簡素化のため、図５では２つのアグリゲータだけを示している。

後に行われる検証のために登録されるべきデジタルレコードを生成又は入力する任意のタイプのシステムであるクライアントシステム２０１０−１について検討する。デジタル入力レコードを作成でき、本願発明との関係でクライアントシステムたり得る数多くの物理的システム及びソフトウェアシステムを若干挙げるとすれば次のものが含まれる：物理的な若しくは仮想的なコンピュータ、携帯電話等の通信装置、これら２種類の装置についてのハイブリッド装置、状態変化若しくは他の活動がログされてコンピュータによって管理される他の機械（例えば、フライトデータレコーダ若しくは工業プロセス装置）、及び、純粋なソフトウェア上のエンティティであってログされる活動を伴うもの。

１つの実装例では、検証インフラストラクチャを使用することを望む各クライアントシステムには、デジタル情報を簡便に又は自動的に「上方へ向かって」通信及び提出するためのソフトウェアパッケージ若しくは内部システムルーチンが搭載される。ソフトウェアパッケージは、提出されたデジタルレコードを処理のために適切な形式に変換する何らかのアプリケーションプログラミングインターフェース（ＡＰＩ）２０１４を含むことができる。そして、作成、選定、若しくは何らかの方法によって入力されたデジタルレコード２０１２は、ＡＰＩ２０１４を介してソフトウェアモジュール２０１６に送られ、該モジュールはハッシュ関数等の変換関数においてレコード２０１２からのデジタルデータを少なくとも１つの引数として用いるものである。

イベントログを検証するために設計された本願発明の実装例においては、「クライアント」は典型的にはクライアントシステム自体の内部に存在するルーチンであって、イベントログの全部又は所望の部分を抽出して、これを署名されるべき及び検証されるべき入力レコードとして提出することのできるルーチンである。もっとも、一部の場合においては、イベントログは、イベント又はイベントログを受信又は抽出するシステムから分離されているか或いは遠隔地に置かれていることができる。例えば、これらのイベントは、携帯電話やタブレットコンピュータ等と中央の電話システム若しくは無線ネットワークシステムとの相互作用又はこれらの装置についての他のタイプのシステム状態の変化に関するものであると仮定する。このようなイベント／状態変化には、装置の立ち上げ及びシャットダウン、通話の開始及び終了、ＳＭＳメッセージ又は電子メールの送信又は受信、インターネットにアクセスする行為、あるセルラーゾーンから別のセルラーゾーンへの移動、ソフトウェア更新の受信等が含まれる。これらのイベントはサービスプロバイダによって運営される中央交換局においても検出可能であるため、装置上で装置によって行われるロギングに代えて又は加えて、中央局側でロギングして検証システムに入力することができる。

暗号学的ハッシュ関数は、コンピュータサイエンスの多くの分野で極めて周知となっており、それ故ここではさらに詳述しない。このアーキテクチャ内での使用に適した多数あるハッシュ関数のありきたりな分類のごく一例としてはMD2、MD3、MD4、MD5、...関数を含む「メッセージダイジェスト」（MD）ハッシュ関数及び様々な「セキュアハッシュアルゴリズム」ファミリ（SHA-1やSHA-2等）が挙げられる。

x_root値自体はマスキングハッシュツリー２００についての評価の結果であるため、多くの実装例では、クライアント内にてこれをさらにハッシングする必要はない。もっとも、インフラストラクチャのデザインプロトコルによっては、追加的な情報を含ませるために、クライアント内での追加的ハッシングが望まれる場合もあり得る。追加的なハッシュ関数２０１６の引数としてシステム設計者が任意に選択することのできる多くのもののうちのいくつかを挙げれば次のものが含まれる：登録を要求している個人又はエンティティの識別子、使用されている具体的なクライアントシステムの識別子、時間表示、クライアント又は他のシステムの地理的位置に関する情報、又は、登録要求の部分として取り込まれることが望まれている他の任意の情報。入力パラメータの個数に関係なく変換関数２０１６は一般的に１つの数又はベクトル２０１８を出力するため、関数２０１６が知られている限りにおいて再計算による後の認証は成功する（再度のことであり、常にこうなる訳ではないが、必要とされるデータ構造について対応する記録管理が実施されて維持されている限り、より複雑なスキームを用いることもできる）。ゲートウェイと通信して、変換２０１６の出力を、登録要求を開始するために必要な他の任意のパラメータやデータと共に、インフラストラクチャの上位レイヤーへ要求（REQ）として送信するためのソフトウェアモジュール２０２０が好適には含まれる。

本明細書において変換関数２０１６はハッシュ関数であると仮定する。なぜならば、これが最もありふれたかつ効率的な設計上の選択であり、また、ハッシュ関数の性質が非常に良く理解されているからである。また、多数の異なるハッシュ関数が、暗号学やセキュリティ等の分野において市販コンピュータ内で使用されているからである。ハッシュ関数の別の有利な性質としては、該関数によって、２つの異なる入力が同一の出力をもたらす確率が統計的に有意でないものとした上で大量のデジタル情報でさえもより処理しやすいサイズに縮小することができるという点がある。換言すれば、このインフラストラクチャのインフラストラクチャの至るところで多くの周知のハッシュ関数が用いられることが適切となり、通常の設計考慮事項を用いてこれらを選定することができる。もっとも、関数の性質が既知である限り、デジタルレコードを要求としての提出に適した形式に変換する関数は、ハッシュ関数である必要はない。例えば、特に小さなデジタルレコードに関しては、デジタルレコードデータを、その全体又はそのサブセットに関して、単にありのままで送信することがより効率的である場合があり、この場合変換関数を単なる恒等関数としてみることができ、コアシステム管理者によれば、この関数は、適式な登録要求を形成するのに必要であるとされている他の任意の追加的情報を付加することもできる。

２分ハッシュツリーのデータ構造はゲートウェイ３０１０−２内に図示されている。所与の実装例において要求を形成するのに用いられる任意の他のパラメータ又はデータと共にクライアントからの要求として提出される、変換されたデータセット２０１８に、最下位レベルノードの各々は対応する。図示のようにデータ構造内のノードの各組によって表された値は親ノードへの入力を形成し、そしてこれが組み合わせた出力値を計算し、例えば自らの「子」ノードからの２つの入力値についてのハッシュとしてこれを計算する。このようにして組み合わされた出力／ハッシュ値の各々は、２つの入力のうちの一方として「祖父母」ノードに提出され、そしてこれが該２つの入力についての組み合わされた出力／ハッシュ値を計算し、ゲートウェイ内のトップノードについて単一の組み合わされた出力／ハッシュ値が計算されるまで以後同様にしていく。

同様に、システム４０１０−１等のアグリゲータは、ハッシュツリーデータ構造の各ノードについて組み合わされた出力値を計算する計算モジュールを含む。ゲートウェイと同様に、アグリゲータのデータ構造内の各ノードについて計算された値は、自らの「子」ノード２つを入力として用いる。したがって、各アグリゲータは、該アグリゲータより下方のデータ構造内のゲートウェイに要求を提出したクライアント全てのデジタル入力レコードから導出された情報を含むものたるハッシュ関数の適用結果としての最上位の組み合わされた出力値を、最終的に計算する。もちろん可能ではあるが、アグリゲータレイヤー４０００は、コアレイヤー５０００を担当するシステム管理者と同じ者によって制御されている必要は必ずしもない。換言すれば、要請されるプロトコルに従って実装され、かつ、正しいハッシュ関数（又は所与の実装例で選ばれる任意の他のタイプの関数）が用いられるならば、様々なユーザが選好する任意のタイプのアーキテクチャを用いるようにクライアント、ゲートウェイ及びアグリゲーションレイヤーを構成することができる。

１つの実施形態では、コア５０００は統括システムアドミニストレータによって維持及び制御されている。コア内では、各アグリゲータのルートハッシュ値を最下位入力として用いてハッシュツリーデータ構造が計算される。結果として、コア内のハッシュ計算及び構造がアグリゲーション値についてのアグリゲーションをもたらす。したがって、コアは、単一の最上位コアハッシュ値を、各々のツリーノード５００１にて、各カレンダー時間インターバルt₀, t₁, ..., t_nにて、計算する。この最上位値はここでは、時間インターバルについての「カレンダー値」又は「現在カレンダー値」と代替的に称する。時間に関しての原点及び粒度はいずれも設計事項であることに留意されたい。

最上位ツリーノード５００１は、それに対して下位となるノードについてのツリー構造全体についてのルートノードを表す。後述するように、要求を蓄積し、及び、再計算パラメータを含む署名ベクトル（「データ署名」ともいう。）を生成する次回の期間の終了時に行われる新たな最上位コアハッシュ値の再計算によって、前述の状態は変わる。もっとも、他の構成も可能である。例えば、単一障害点の可能性を減らすため又はなくすためには、下位レベルのルートハッシュ値を含む当時において複数となっているルートハッシュ値の間でアービトレーションを行う及び／又はそれらを集約する機構が含まれる限り、要求を複数のアグリゲータに向かってかつ上方に向かって送信してハッシングを行うことができる。

図５では、ゲートウェイ３０１０−２内のハッシュツリーノード、アグリゲータ４０１０−１及びコア５０００の特定のものは、「Ｘ」でマーキングされている。Ｘでマーキングされたツリーノードの値及び一連の親ノードで適用されたハッシュ関数についての知識を与えられていれば、クライアント２０１０−１内の値２０１８から上方へ様々なツリーパスをトラバースしていけば、最新の最上位コア値５００１までに至るツリー構造内の上方において存在する値全てを計算することができるという点に留意されたい。要するに、「Ｘマーキングされた」値全てを含む署名がデジタルレコード２０１２に関連付けられている場合であって、ハッシュ関数が既定のもの（当然であるが、同じ関数であっても異なる関数であっても良い）であると仮定した場合、次の条件が充足される場合に限って、全てのツリー構造を通してのハッシュ値の再計算が現在カレンダー値と同じ値をもたらす。即ち、当初のデジタルレコード（特に現在イベントブロックについてのx_root）を表す開始時の入力値がオリジナルと全ての点において同一である場合に限る。デジタル入力レコードについて行われたほんの些細な変更であっても、即ちそれがレコード２０１２に関連付けられている署名のいずれかの値に関してのたった１ビットの変更であっても、そのような変更はノード５００１内のカレンダー値と同一でない再計算カレンダー値をもたらすことになる。また、コア内の各最上位計算値、即ち現在カレンダー値は、現在カレンダー時間インターバル中にシステムに入力された全てのデジタル入力レコードから導出された情報を含むということに留意されたい。

図６は、ノード５００１内の値に、即ちシステムの最上部までハッシュツリーパスを再計算するのに必要な情報を含むハッシュツリーノード値を有する、「簡易化された」インフラストラクチャを示す。特定のゲートウェイ、アグリゲータ又はコア内で再計算を行う必要はなく、実際には、デジタルレコード２０１２についての検証要求を当初提出したクライアント２０１０−１と同じクライアント内で再計算が行われる必要すらない。各レベルにおける「兄弟」ツリー値を含むベクトル、及び、各親ノードでどのハッシュ関数を用いて計算を行っているかについての知識、が必要な情報の全てである。換言すれば、この情報を有していれば、第三者であっても、再計算を行って、ノード値５００１と比較を行い、そしてそれによって、デジタルレコード２０１２であるとされている任意の表現を認証するか、又は、何らかの差異を検出することができる。

図６では、再計算のために必要な兄弟ハッシュ値は、０から９までナンバリングされている。ノードが時間順で作成され、かつ、選択されたハッシュ関数において順序が意味を有するのならば、各レベルにおいての兄弟がハッシュ構造の「左右」のどちらかにあるかということは意味を有するものとなる。図６に示す例においては、選択された任意の情報と共にデータ署名８０００として戻されるベクトル（｛兄弟値０−１｝，｛オーダービット｝，｛その他｝）内においては、値のみならず、順序（０：左から，１：右から）も示されている。ここで、２分ハッシュツリー構造を用いることについての１つの利点を見出すことができよう：各レベルにおいて、上方へ向かっての再計算のために必要となる兄弟値は１つだけとなることである。２分木でない構造も可能ではあるが、その場合には演算、ストレージ及びデータ構造において、増大した複雑度を甘受しなければならなくなる。図５及び図６を比較すると、任意の時間インターバルにおけるＮ個のデジタル入力レコードのセット１つを認証するための計算負荷は、たったのlog₂Nに比例するということも分かる。特に、再計算によって認証を行うことを望んでいるクライアント及び後続エンティティに関しては、様々なレイヤーの独立性を向上させるためには、新たなカレンダー値の計算時点毎に、即ち各カレンダー時間インターバルの終了時において、アグリゲータに、又はさらなる下位レイヤーに、あるいはクライアントにまでカレンダー全体を伝達することが有利である。これによって、システムの完全性に関して何ら妥協することなく、計算負荷の委譲及び分散が可能となる。単に現在カレンダー値のみを下方伝達することが可能ではあるが、アグリゲータがカレンダー値についての稼働しているデータベースを維持している場合、カレンダー全体が通常は大きいものではないが故に新たなエントリが計算される都度にカレンダー全体を容易に丸ごと送信することができる。したがって、図４は、システム時間の始まりからのカレンダー値全てを含むデータベース又はファイル（「カレンダー」）６０００を示す。これにより、最小限の管理上の負担だけで新たなアグリゲータ、ゲートウェイ及びクライアントがインフラストラクチャに参加できるようになり、デジタルレコードの認証を望むクライアントレベルエンティティよりも高位なレベルを関与させないで任意のデジタルレコードについて再計算及び検証を行うことができるようになる。

コアは、データ署名ベクトル８０００を直接クライアント及び／又は他のレイヤーに戻すことができ、あるいは、それを構築するか又は戻り値として「下方へ向けて」伝達することができる。例えば、新たなカレンダー時間インターバルにてコアが現在カレンダー値５００１を計算した場合、コアはアグリゲータ４０１０−ｋからの兄弟の（Ｘマーキングされた）最下位コアノード値をアグリゲータ４０１０−１に戻すことができ、そしてアグリゲータ４０１０−１はＸマーキングされたハッシュ値を下方に向けてゲートウェイ３０１０−２に戻すことができ、該ゲートウェイは上述の全て及び該ゲートウェイのハッシュツリー構造内にて計算されてＸマーキングされたハッシュ値を下方に向けてクライアント２０１０−１に戻すことができる。換言すれば、ハッシュ計算インフラストラクチャが様々なレイヤー間で（垂直的に）及び各レイヤーにて「水平的に」分散されることができるだけでなく、要求を上方に向けて又は部分的若しくは全体的な署名ベクトルを下方に向けて伝達する責任も分散されることができ、様々な箇所にて同時的に実行されることができる。もちろん、データ署名はそのもととなったデジタルレコードとの関係で一意なため、各クライアント２０１０−１についての各入力デジタルレコード２０１２（各時間インターバルにおいては、１つのクライアントが１より多いデジタルレコードを検証のために入力することができるという点に留意されたい）についての署名ベクトルを戻すための手順は、好適にはノード値５００１の計算のために値が蓄積された時間インターバル中に受信された全てのデジタル入力レコードについて、複製されるべきである。

図５に示され、本明細書で説明された分散インフラストラクチャの性質は、１つの時間インターバルから次の時間インターバルにわたって静的である必要はないことに留意されたい。むしろ、コアより下位の各コンポーネントは、他のものとは非同期的及び独立的に構築されることができ、デジタルレコードから対応するカレンダー値までの再計算を認証するのに必要なのは、当初の要求を構成した変換関数及び他の値と、ハッシュツリー兄弟値のベクトルと、各計算にて適用されるべきハッシュ関数についての知識とであってこれらが全てである。もちろん、最も単純なケースは全てのレベルで同じハッシュ関数が用いられている場合である。もう少し複雑な選択としては、特定のレベル（例えば、クライアント内、ゲートウェイ内、アグリゲータ内等）における全ての計算に同じハッシュ関数を用いて、レベル間で差異を設けることである。さらに複雑な他の選択は、データ構造及びハッシュ関数計算の分野における当業者によって着想され得るものとしてもちろん実現されることができる。各計算に用いられるハッシュ関数が知られている限り、インフラストラクチャは所与の入力レコードの有効性を検証することができる。

多くの場合、所与の計算インターバルにおいてはクライアントの個数が２の累乗に全く等しくなることの確率は高くはない。全体的に２分ハッシュツリーの構造を維持しながら実際のクライアント数に適応するためには、任意の既知の方法を用いることができる。このことに関しての解決法の１つの例にすぎないが、「欠損している」兄弟ノード値の全てについて既知のダミー値を用いることができる。代替的には、勝ち抜き戦スポーツトーナメントでみられる「bye」の付与に即した態様でハッシュツリーのブランチを調整することもできる。

１つの実施形態では、ゲートウェイ３０００は様々なクライアントとの関係でより局地的（ローカル）なものであり、対してアグリゲータはより地域的（リージョナル）なものである。例えば、負荷を分散させるためだけではなく、スループットを増加させるためにも、世界の異なる場所にアグリゲータを配置することができる。図４乃至図６では、クライアントは特定のゲートウェイと関連付けられており、ゲートウェイは特定のアグリゲータと関連付けられているようにみえるが、必ずしもそうではない。むしろ、クライアントからの要求はネットワークを通して提出されることができ、その認証トランザクションに関しては最初に応答したゲートウェイがそのクライアントと関連付けられることができる。同様に、ゲートウェイからの要求はオープンなネットワークに提出されて、最初に接続を確立したアグリゲータによって処理されることができる。アグリゲータ及びゲートウェイを物理的及び論理的に効率的な態様で配置することによって、より良く負荷は分散され遅延時間は減少する。しかし、他の実装例ではこれは望まれていない場合がある。例えば、政府、防衛関係の請負事業者又はインフラストラクチャの全体について厳格なセキュリティ及び厳格な管理を維持したい企業等のエンティティは、インフラストラクチャの全てのレイヤー又はそれらのサブセットの間での関係を制御及び指定することができる。

例として、何らかのエンティティが疑義の対象とされるデジタルレコード、即ち「候補デジタルレコード」がデジタルレコード２０１２についての同一コピーか否かを検証することを後の時点において希望している事例を検討する。同じ変換関数２０１６を候補デジタルレコードに適用して、対応するデータ署名８０００を用いて上方へ向かって再計算を行うと、エンティティは、当初のデジタルレコードについての登録要求から生じたカレンダー値と完全に同一の値を算出することになる。一部の実装例では、このレベルでの検証で十分とされる。１つのあり得る可能性としては、カレンダーが十分な個数の独立アグリゲータに配信されていると、１つの悪質な主体が何らかのカレンダー値を改ざんしようとした場合、同じカレンダーについての別のコピーと比較する何らかの手順が実装されているのならば、これを検出することができる。

もう１つの例としては、一部の実装例では、ユーザが、コアの管理者によるセキュリティを選択するか又はこれに依存せざるを得ないこととなる。特に、政府機関は、ユーザが政府の管理者を単純に信頼する他ないシステムを実装することができる。これらの場合においては、対応するカレンダー値までの再計算が、十分に信頼できる認証としてみなされることができる。このインフラストラクチャの文脈においては、これは「第１レベル」検証として捉えることができる。このようなシステムが実施され得る１つの仮定的な例としては、次の場合がある：即ち、企業等のシステムがカレンダーを更新した際に毎回自己のカレンダーのコピーを政府機関に提出することを、政府機関が企業や研究所等に義務付ける場合である。これにより、政府が保有することになる真正なカレンダー値に再計算を行うことによって、政府は企業等の記録を監査して与えられた任意のデジタルレコードの信憑性を検証することができる。これは、監査を行う主体（例えば、政府等）との関係で、「カレンダー監査トレイル」を企業等に更新させることを義務付けることを、実際的には意味する。

他の場面でも、最高位レベルのシステム管理者がカレンダーを安全に保管する能力を信用するのであれば、再計算が適切な格納済みカレンダー値になる場合、候補デジタルレコードの信憑性について満足することができる。見方によっては、クライアント又は他の第三者エンティティではなく、これらの場合においてはシステム管理者自身が、候補デジタルレコードの信憑性についての証拠を探しているといえる。したがって、システム管理者は、カレンダーのコピーを保管することに関して自己を信頼することのできる程度と同じ程度まで、再計算及びカレンダー値のセキュリティを信頼することができる。

あるカレンダー時間期間において登録を要求しているレコードのうち、最後のデジタルレコード以外の全てのレコードについては一般的には、そのカレンダー時間インターバル内の他の全ての要求が処理されるのを待たなければ、認証のための再計算を可能とするカレンダー値が利用可能とならない。カレンダー時間インターバルが十分に短いものとされれば、この遅延は許容可能となり得る。遅延の間のセキュリティのレベルを向上させるためには、クライアントが認証登録要求を提出した際にはデータ署名ベクトルのみならず現在のゲートウェイ、アグリゲータさらにはコア等の高位レイヤーシステムによって発行されることのできるキーベースド証明書をも生成して送り返すようにするオプションを実装することもできる。

図７は、基本的カレンダー依存検証プロセスについての拡張であって「第２レベル」検証をもたらす拡張を示しており、これは永続的な検証のための方法であって、キーを必要とせずに、また、コアの管理者さえも含む如何なるエンティティをも信頼することを要さない、方法である。図７では、公開時間インターバルＴｐにおいて計算されたカレンダー値の全てが、追加的ハッシュツリー構造の入力として用いられ、好適には先のカレンダー値と共に（例えば、マークルツリー構造を用いて）ハッシングされて結合カレンダー値（「公開値」）が計算され、これを何らかの媒体７０００に公開のために提出し、これが結合カレンダー値についての変更不能なレコードを形成する。該媒体は例えば新聞やオンラインポスティング等である。ここで、「変更不能」とは、最高に悪質な主体にとっても、たとえそれがコア管理者であったとしても、公表されている値の全ての出現箇所に変更を加えることが実際的には不可能となる、という意味である。「公開」は一般公衆にとってアクセス可能な任意の媒体にて行われている必要はないが、もちろんこのようにすることは信頼された機関の必要性を全くなくする１つの選択肢ではある；むしろ、自前でインフラストラクチャ全てを実装するような、場合によってはクローズドな、大規模組織においては、何らかのセキュアな論理的又は物理的位置に結合カレンダー値についてのデータベース又はジャーナルを保管することが単に選択される場合がある。

分散インフラストラクチャの様々なデータ構造及び手順のおかげで、公開された結合カレンダー値には全体の公開時間インターバルにおける全ての入力デジタルレコードから取得された情報がエンコードされており、図７に示すように現在カレンダー期間についての現在カレンダー値が先のカレンダー値と共にハッシングされており、先のカレンダー値はその前のカレンダー値と共にハッシングされており、以降同様である場合、各公開された結合カレンダー値には、カレンダー時間の開始時t₀以降に登録のために提出されたことがあるデジタルレコードの全てからの情報がエンコードされていることとなる。これによってシステム全体の完全性が担保される：過去に登録された１つのデジタルレコードを１ビットでも変えた場合、異なる公開値が計算され、実際の公開値と一致しないことになる。結合署名値（即ち公開値）が公開されると、何らかの署名されたデジタル証明書（該証明書は結合値が公開されるまでの間のセキュリティを向上させるために従来通り提供されることができるが、公開時点においてそれはもはや不要となる）と対応するデジタル入力レコードの署名ベクトルとを一時的に関連付ける必要性は二度と生じることはない；むしろ、データ署名ベクトルとカレンダー値（好適には各アグリゲータに格納されている）とを用いることによって、任意のデジタル入力レコードから上方へ向かって公開値までハッシュ値を再計算していくことができる。そのような再計算において用いられるデジタル入力レコードが公開値との一致をもたらす場合、検査されているデジタル入力レコードが対応する署名ベクトルを当初与えられたデジタル入力レコードと同一であるとの確証を、ハッシュ関数自体の確信度において得ることができる。

図８は、公開値の計算中に得られた値も含むようにした、署名ベクトルについての任意の拡張を示す。先述と同様に、「Ｘマーキングされた」ノードは、クライアント２０１０−１からの要求REQに対応するデジタルレコードについての兄弟ハッシュ値である。「Ｃ」でマーキングされたカレンダー値を再計算するためには、Ｘマーキングされた値があれば十分であるが、公開値７０００まで上方へ向かって再計算するには、カレンダー値を公開値に変換するためのコア内のデータ構造の内部にある「Ｅ」でマーキングされたノード内のハッシュ値が必要となる。したがって、カレンダー期間の最後に、好適にはコアは署名ベクトルを拡張又は強化して従前のようなオーダービットと共に「Ｅ」値が含まれるようにする。このような拡張された署名を用いると、任意の当事者は、拡張された署名ベクトルと用いられたハッシュ関数（又は他の関数）についての知識と対応する公開値とを把握している限り、所与のデジタルレコードの真正性を検証することができる。再計算が一致した場合にはデジタルレコードはオリジナルと同一であるということになり、そうでない場合には何かが変更されたことになる。また、任意のデジタルレコードについての受領時刻に関しての順序の変更は、コア内で計算される値及び公開される結合署名値に影響を与えることにも留意されたい。

本願発明はこのスキームについての拡張を伴う：ブラインディングマスクを備える追加的なハッシュノードが乱数又は疑似乱数として生成されて、好適にはコアレイヤーにおけるハッシュ計算に含められ、オプションとしては代替的に若しくは追加的に他のレイヤーにおけるハッシュ計算に含められる。そして、これらの追加的ノード値（ランダムに生成された数）は、他の任意のノード値と同じように、戻されるデータ署名に含められることができ、これにより再計算が可能とされる。

図７では、各公開時間インターバルTp内において８つのカレンダー値が示されている。換言すれば、各公開時間インターバルTp内のカレンダー時間インターバルの個数は、都合の良いことに２の累乗となっている。インターバルの選択の如何によっては、他の実装例ではこうなるとは限らない。例えば、カレンダー値が毎秒生成されるが公開は週に一回（604,800秒）しか行われない場合、マークルツリー構造のリーフノードとしてのカレンダー値の個数は２の累乗とはならない。他のツリーの場合と同様に、このことについては勝ち抜き戦スポーツトーナメントでみられる「bye」の付与に即した態様でツリーのブランチを調整したり、「ダミー」入力を用いたりする等して既知の方法を用いて対処することができる。

カレンダー時間の開始時点からのカレンダー全体についての情報を、公開値にエンコードしておくことが、多くの場合において望ましいこと又は要求されていることとされ得るが、適切な記録管理ルーチンが含まれている限り他の代替的手法をも実施することができる。例えば、マークルツリーに全てのカレンダー値を含めるよりはむしろ、各公開時刻において最近のカレンダー値の全てを、先の時間インターバルのカレンダー値からのランダムなサンプリングと共に、公開計算に含めることができる。これは、含まれるカレンダー値の個数が都合良く２の累乗となるように保証するための手法の一例である。

同様に、一部の場面においては、行政当局はレコードについての証明を、所定の期間、例えば３年、のみ遡って求める場合がある。このような場合、要求される期間中に生成されたカレンダー値のみを含めるのが有利となり得、この場合最新の公開値には関連のあるデジタルレコードのみがエンコードされる。

別の代替案では、システム時刻の開始からの全てのカレンダー値を含む公開値について１度だけ演算を行う。この案は、明確な時間制限又はデジタルレコード制限を伴うプロジェクトにおいて有用であり得る。例えば、訴訟又は取引においては、交換を容易化するために当事者は多くの場合デジタルレコードを「データルーム」に提出する。他の場合と同様に定期的にカレンダー値を生成することができるが、全当事者がデータルームを閉鎖することにつき合意した際に１度だけ公開値について演算を行う（なお、インフラストラクチャのインフラストラクチャについての大規模かつ普遍的にアクセス可能な実装例で行われるほどには頻繁にデジタルレコードが提出されるとは一般的にいえないので、場合によってはより長いカレンダー時間インターバルを伴うことができる。）。公開値は、提出されたデジタルレコードの集合上の「封印」の一種となり、任意の時点でデータルームに提出された任意のデジタルレコードについての再計算及び検証に後において用いられることができる。

公開値を計算するのには、必ずしも図７に示したマークルハッシュツリーデータ構造を用いらなくてもよい。例えば、１つの代案としては、公開時間インターバルにわたる全てのカレンダー値を連結して、疑似乱数と共に全体としてハッシングして拡張されたデータ署名ベクトルの一部とすることができる。他の代案も可能である。

再計算ベクトルについては、各イベント入力e(i)と関連付けて、その値からブラインディングマスクハッシュツリー（図示のケースでは、マークルツリー）の上方へ向かってのx_rootまでへの再計算を可能とすることができることに留意されたい。これを如何にして計算モジュール２００内で行うかの１例が手順例３である。この例としては、（ツリー構造２００についての「ローカルな」データ署名の一種である）ベクトル｛(left, m₂), (left, x₁), (right, x_3,4)｝が、e(k+2)に対応するrec₂と関連付けられていると仮定する。e(k+2)及びこの情報を与えられると、コンポーネント２００は、検証エンジンとして機能することとなり、rec₂ (e(k+2))をハッシングすることによってr₂を計算できるようになる。再計算において用いられるe(k+2)の値が当初においてx_rootの計算結果をもたらしたものの値と完全同一である場合に限り、m₁||r₁をハッシングすることによってx₁が得られ、x₁||x₂をハッシングすることによってx_1,2が得られ、そしてx_1,2||x_3,4をハッシングすることによってx_rootが得られる。e(k+2)を検証するためのこの再計算においては任意の他のイベントe(j)の値を知ることは必要ではなく、任意の他のイベント値に逆算しようとする如何なる試みもが実際的に不可能な行為、即ち、ブラインディングマスクのおかげで入力が高エントロピーとなっている1以上のハッシュ関数を遡ろうとする逆算、を要求するということに留意されたい。

本願発明について想定される実装例の多くにおいては通常、各ブロックＢ内において大量のイベントe(j)が存することになる。方向情報とイベント値e(j)からカレンダー値５００１までの要求される兄弟ノード値（全体的インフラストラクチャ内にて異なるハッシュ関数が用いられている場合にはハッシュ関数識別子をも含む値）とを含む完全なデジタル署名ベクトルをコンパイルして関連付けることは可能である。しかし、多くの場合においてこれは許容不能な程に大きなストレージ及び計算負荷を伴い、無用ともいえる。むしろ、好適な実装では、各ブロックについてx_root.値のみをデジタル的に署名して、そしてブロック内のエントリについてx_rootまでの再計算を検証するための内部署名ベクトルを維持する。各x_root.がグローバル的に検証された場合、そのレベルまでのエントリのみを検証するだけで足りる。

任意のレイヤー内のシステムが同一のハッシュ関数を適用することは要求されていない。例えば、異なるクライアントシステム内において用いられる変換関数は異なることができる。事後において再計算によってデジタルレコードを認証したいと希望する任意の者が、再計算パス中における各箇所の関数を知っている限り、認証プロセスは正常に動作する。登録要求の準備に関しての入力パラメータとしてハッシュ関数識別子を追加することは、将来のユーザが再計算によってデジタルレコードを正しく認証できるようにする便利な手法たり得る。

本願明細書においては、ハッシュ関数等の様々な関数を適用して値を計算することに言及している。例えば、図５ではクライアント２０１０−１はこのようなことを行うためのソフトウェアモジュール２０１６を有するものとして示されている。値の入力及び予めプログラムされた関数に基づいて出力を算出するために必要とされるハードウェア及びソフトウェアモジュールは、もちろん、コンピュータサイエンスの分野において周知である。インフラストラクチャの他のシステム並びにネットワークを経由する通信を含む図示された異なるシステム間の通信のために必要とされるハードウェア及びソフトウェア内には、類似の構造が見出される。

Claims (22)

1. デジタルレコードをセキュアに認証する方法であって、
   一連のレコードブロックを入力するステップであって、各ブロック（Ｂ１）は複数の前記デジタルレコード（rec₁, ..., rec₄）を備える、ステップと、
   少なくとも１つの実質的にランダムな数（rnd_B1）を生成するステップと、
   各レコードブロックが：
   入力レコードハッシュ値（r₁, ..., r₄）を、前記ブロック内の前記デジタルレコードの各々について計算するステップと、
   ブラインディングマスク値（m₁, ..., m₄）を、前記実質的にランダムな数を入力パラメータとして取るハッシュ関数として計算するステップと、
   各入力レコードハッシュ値について、マスクされたハッシュド入力値（x₁, ..., x₄）を、前記入力レコードハッシュ値と前記ブラインディングマスク値の対応する１つとについてのハッシュとして計算するステップであって、前記マスクされたハッシュド入力値はハッシュツリーのノードを構成する、ステップと、
   後にアグリゲートされるハッシュツリー値を計算して単一のルートハッシュ値（x_root）を形成するステップ
   とによって特徴付けられる、方法。
2. 前記ルートハッシュ値に対してデジタル的に署名するステップによってさらに特徴付けられる、請求項１に記載の方法。
3. 検証フェーズにおいて：
   指定された１つの前記デジタルレコードに対応する候補デジタル入力レコードを受信するステップと、
   前記指定されたデジタルレコードと関連付けられた前記ブラインディングハッシュ値と、前記指定されたデジタルレコードの兄弟ノード値であって前記指定されたデジタルレコードから前記ルートハッシュ値までの前記ハッシュツリー内の計算パス内の兄弟ノード値とを、与えられた上で、前記ルートハッシュ値（x_root）を再計算するステップであって、前記再計算されたルートハッシュ値と当初計算された際に得られた前記ルートハッシュ値とが等しい場合に前記候補デジタル入力レコードは前記対応する当初の入力デジタルレコードと同一であることが検証されたとみなされる、ステップ
   とによってさらに特徴付けられる、請求項１又は請求項２に記載の方法。
4. 前記ハッシュツリーはマークルツリーであることによって特徴付けられる、請求項１乃至請求項３のいずれか一項に記載の方法。
5. 前記ブラインディングマスク値（m₁, ..., m₄）を、前記実質的にランダムな数を片方の入力パラメータとして取り、かつ以前に提出されたデジタルレコードに対応するマスクされたハッシュド入力値を他方の入力パラメータとして取る前記ハッシュ関数として計算するステップであって、前記マスクされたハッシュド入力値についての前記計算は連鎖的にされる、ステップによってさらに特徴付けられる、請求項１乃至請求項４のいずれか一項に記載の方法。
6. 前記ブラインディングマスク値（m₁, ..., m₄）を、前記実質的にランダムな数を片方の入力パラメータとして取り、かつ現在ブロック内の前記複数のデジタル入力レコード内の前記デジタル入力レコードの各々の順序に関する位置を指示するカウンターを他方の入力パラメータとして取る前記ハッシュ関数として計算するステップによってさらに特徴付けられる、請求項１乃至請求項４のいずれか一項に記載の方法。
7. 後にアグリゲートされるハッシュツリー値を計算して単一のルートハッシュ値を形成するステップは、連続して減少する個数のノード値を計算するステップであって、各ノード値は少なくとも２つの下位ノード値と前記ハッシュツリー内における各ノードのレベルを指示するレベル値とについてのハッシュ関数として計算される、ステップによって特徴付けられる、請求項１乃至請求項６のいずれか一項に記載の方法。
8. 各ブロックについて異なる実質的にランダムな数を計算するステップと、
   同一ブロック内の前記マスクされたハッシュド入力値についてのブラインディングマスク値を計算する際に同一のランダムな数を用いるステップとによってさらに特徴付けられる、請求項１乃至請求項７のいずれか一項に記載の方法。
9. 前記デジタルレコードは、コンピュータのシステムログエントリ、syslogエントリ若しくはsyslog変形エントリ、rsyslogエントリ、通信装置のログされたイベント、仮想マシンの状態変化、移動体通信装置の状態変化等のシステムイベント（e(k-l), ..., e(k+5)）であることによって特徴付けられる、請求項１乃至請求項８のいずれか一項に記載の方法。
10. 前記デジタル入力レコードは共通ログ内にログされた１より多い個数のエンティティについてのイベントであり、
    前記イベントを、エンティティ毎に識別し、かつ、別個のイベントスレッドにグループ化するステップと、
    各スレッドについて、別個のスレッドルートハッシュ値を計算するステップ
    とによってさらに特徴付けられる、請求項１乃至請求項９のいずれか一項に記載の方法。
11. 各スレッドルートハッシュ値に対して別個にデジタル的に署名するステップによってさらに特徴付けられる、請求項１０に記載の方法。
12. 前記マスキングハッシュツリー計算コンポーネントは、前記ルートハッシュ値をキーレスな分散ハッシュツリー認証システム（２０００、３０００、４０００、５０００）に提出し、前記ルートハッシュ値と関連付けられたデジタル署名を前記キーレスな分散ハッシュツリー認証システムから受信することによって特徴付けられる、請求項２乃至請求項１１のいずれか一項に記載の方法。
13. コアプロセッシングレベル上のコアシステム（５０００）にて、各々の非コア最上位プロセッシングレベル（４０００）上の少なくとも１つの非コア最上位プロセッシングシステム（４０１０−１, ..., ４０１０−ｋ）の各々から、少なくとも１つのデジタル入力レコードのユーザレベルシステムにて計算されるデジタル変換として形成される最下位レベル入力を有する前記キーレスな分散ハッシュツリー認証システムのノード値として非コア下位プロセッシングレベルにて計算される一連の下位レベル結合出力値についてのデジタル結合として形成されて前記ルートハッシュ値を含む現在最上位レベル結合出力値を、受信するステップと、
    前記コアシステム内にて、現在ルートカレンダー値を、前記現在最上位レベル結合出力値及び少なくとも１つの先のルートカレンダー値に関しての関数についてのデジタル結合として、計算するステップと、
    前記最上位レベル結合出力値の少なくともサブセットについての関数として計算された公開出力値を、定期的に計算して、実質的に永続的な態様で公開させるステップと、
    対応するデジタル変換を被験デジタルレコードに適用して、かつ、前記現在カレンダー値の再計算パラメータ及び前記結合カレンダー値を用いて、ツリーデータ構造及びコアを通って上方に向かって前記ノード値を再計算した際に、当初計算時に得られたのと同一の結合カレンダー値が得られた場合に、任意の後続の被験デジタルレコードは対応するデジタル入力レコードとの関係で永続的に認証されたとみなすステップと、
    前記現在カレンダー値のみならず少なくとも１つの先の現在カレンダー値を含む公開期間にわたって計算された複数の現在カレンダー値についての関数として前記結合カレンダー値を、計算するステップ
    とによってさらに特徴付けられる方法であって：
    前記デジタル結合は暗号学的ハッシュであり、
    各デジタル入力レコードについて、前記再計算パラメータは、前記デジタル入力レコードについての前記デジタル変換から前記結合カレンダー値まで方向付けられた前記ツリーデータ構造内のパス内の兄弟ノード値を含み、
    前記再計算パラメータはキーレスであり、遅くとも前記結合カレンダー値の公開時において前記再計算パラメータはデジタル証明書や暗号キー等の任意の信頼権限パラメータから独立しているものとされる、
    請求項１２に記載の方法。
14. 前記スレッドルートハッシュ値を前記単一のルートハッシュ値内にアグリゲートするステップによってさらに特徴付けられる、請求項１０に記載の方法。
15. デジタルレコードをセキュアに認証するシステムであって、
    各々がデジタルレコードを構成する一連のイベント（e(k- l), ..., e(k+5)）についてのデジタル表現を含むログ（１００）と、
    マスキングハッシュツリー計算コンポーネント（２００）であって、該コンポーネントは：
    前記デジタルレコード（rec_i）を入力し、また、それらをブロック（Ｂ１）にグループ化するサブコンポーネントと、
    各レコードブロックについての：
    入力レコードハッシュ値（r_i）を、前記ブロック内の前記デジタルレコードの各々について計算するサブコンポーネントと、
    ブラインディングマスク値（m_i）を、実質的にランダムな数（rnd）を入力パラメータとして取るハッシュ関数として計算するサブコンポーネントと、
    各入力レコードハッシュ値について、マスクされたハッシュド入力値（x_i）を、前記入力レコードハッシュ値と前記ブラインディングマスク値の対応する１つとについてのハッシュとして計算するサブコンポーネントであって、前記マスクされたハッシュド入力値はハッシュツリー計算構造のノードを構成する、サブコンポーネントと、
    後にアグリゲートされたハッシュツリー値を計算して単一のルートハッシュ値（x_root）を形成するサブコンポーネント
    とを含む、コンポーネント
    とによって特徴付けられる、システム。
16. 前記マスキングハッシュツリー計算コンポーネントは、前記ルートハッシュ値をデジタル署名システム（６０００）に提出し、かつ、受信されたデジタル署名（８０００）を前記ルートハッシュ値と関連付けるサブモジュールをさらに備えることによって特徴付けられる、請求項１５に記載のシステム。
17. 前記マスキングハッシュツリー計算コンポーネントは、検証フェーズにおいて：
    指定された１つの前記デジタルレコードに対応する候補デジタル入力レコードを受信し、
    前記指定されたデジタルレコードと関連付けられた前記ブラインディングハッシュ値と、前記指定されたデジタルレコードの兄弟ノード値であって前記指定されたデジタルレコードから前記ルートハッシュ値までの前記ハッシュツリー計算構造内の計算パス内の兄弟ノード値とを、与えられた上で、前記ルートハッシュ値を再計算し、前記再計算されたルートハッシュ値と当初計算された際に得られた前記ルートハッシュ値とが等しい場合に前記候補デジタル入力レコードは前記対応する当初の入力デジタルレコードと同一であることが検証されたとみなされる、
    ことによってさらに特徴付けられる、請求項１６に記載のシステム。
18. 前記ブラインディングマスク値を、前記実質的にランダムな数（rnd）を片方の入力パラメータとして取り、かつ以前に提出されたデジタルレコードに対応するマスクされたハッシュド入力値を他方の入力パラメータとして取るハッシュ関数として計算するハッシュ計算サブモジュールであって、前記マスクされたハッシュド入力値についての前記計算は連鎖的にされる、ハッシュ計算サブモジュールによってさらに特徴付けられる、請求項１５乃至請求項１７のいずれか一項に記載のシステム。
19. 前記ブラインディングマスク値を、前記実質的にランダムな数を片方の入力パラメータとして取り、かつ現在ブロック内の前記複数のデジタル入力レコード内の前記デジタル入力レコードの各々の順序に関する位置を指示するカウンターを他方の入力パラメータとして取るハッシュ関数として計算するハッシュ計算サブモジュールによってさらに特徴付けられる、請求項１７に記載のシステム。
20. 前記ハッシュツリー計算構造は、連続して減少する個数のノード値を計算することによってアグリゲートされたハッシュツリー値を計算して単一のルートハッシュ値（x_root）を形成するマークルツリーハッシング構造であって、各ノード値は少なくとも２つの下位ノード値と前記ハッシュツリー内における各ノードのレベルを指示するレベル値とについてのハッシュ関数として計算される、ことによって特徴付けられる、請求項１５乃至請求項１９のいずれか一項に記載のシステム。
21. 前記デジタルレコードは、コンピュータのシステムログエントリ、syslogエントリ又はsyslog変形エントリ、rsyslogエントリ、通信装置のログされたイベント、仮想マシンの状態変化、移動体通信装置の状態変化等のシステムイベント（e(k-l), ..., e(k+5)）であることによって特徴付けられる、請求項１５乃至請求項２０のいずれか一項に記載のシステム。
22. キーレスな分散ハッシュツリー認証システム（２０００、３０００、４０００、５０００）によってさらに特徴付けられ、前記マスキングハッシュツリー計算コンポーネントは、前記ルートハッシュ値を前記キーレスな分散ハッシュツリー認証システムに提出し、前記ルートハッシュ値と関連付けられたデジタル署名を前記キーレスな分散ハッシュツリー認証システムから受信する、請求項１６に記載のシステム。