JP5928741B2 - デジタル署名の監査を可能にするためのシステム - Google Patents

Description

本発明は、広義には、デジタル署名の監査を可能するためのコンピュータ化された方法及びシステムに関し、具体的には、アプリケーション関連イベントについてのタイムスタンプを要求する多数の並行アプリケーションと通信するサーバを含むコンピュータ化されたシステムに関する。

安全な暗号プロセッサは、種々の物理的な安全対策を用いてパッケージ内に埋め込まれている暗号演算を実行し、ある程度の不正防止が行われる、専用チップ又はマイクロプロセッサであることが知られている。例えば、スマート・カードは、安全な暗号プロセッサの周知の形態であるが、現金自動預け払い機などの機密システムではより複雑な暗号プロセッサが広く採用されており、例えば非特許文献１を参照されたい。

ハードウェア・セキュリティ・モジュール（ＨＳＭ）、すなわち、デジタル鍵を管理し、デジタル署名に関する暗号プロセスを加速させ、サーバ・アプリケーションの重要な鍵にアクセスするための強力な認証を与える、安全な暗号プロセッサの一種も知られている。このようなモジュールは、従来から、コンピュータ（サーバ又は汎用コンピュータ）に直接取り付けることができるプラグイン・カード又は外部ＴＣＰ／ＩＰセキュリティ装置の形態の物理的装置であり、例えば、非特許文献２を参照されたい。

ＨＳＭは、特に、タイムスタンプのようなデジタル的に署名されたデータを配信するのに用いることができる。デジタル署名は、一般に、データ単位に付加されたデータ又はデータ単位の暗号変換を意味し、データ単位の受信者がデータ単位のソース及び完全性を証明することを可能にして、例えば受信者による偽造を防ぐものである。例えば、非特許文献３を参照されたい。

証明サービス・プロバイダの署名動作のための暗号モジュールの仕様も知られている。そのような暗号モジュールは、そのサービスのユーザに対して、識別情報の認証、アクセス制御、及び監査を提供する［非特許文献３］。

また、システム侵害の前にロギング機能によって格納されたデータは、検出されることなく侵害された後では変更することができないという、強力な暗号保証を提供するシステム「Ｌｏｇｃｒｙｐｔ」も知られている［非特許文献４］。影響され難いハッシュ・チェインの特性に基づく他の実装形態もある。

「Ｓｅｃｕｒｅ ｃｒｙｐｔｏｐｒｏｃｅｓｓｏｒ．」 ウィキペディア フリー百科事典 ２０１０年１１月２９日、 Ｗｅｂ． ２０１１年２月２３日 「Ｈａｒｄｗａｒｅ ｓｅｃｕｒｉｔｙ ｍｏｄｕｌｅ．」ウィキペディア フリー百科事典 ２０１１年２月８日、 Ｗｅｂ． ２０１１年２月２３日 ［ＣＥＮ０３］ ＣＥＮ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｏｃｉｅｔｙ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｙｓｔｅｍ ＣＷＡ １４１６７−４： Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｍｏｄｕｌｅ ｆｏｒ ＣＳＰ Ｓｉｇｎｉｎｇ Ｏｐｅｒａｔｉｏｎｓ Ｐｒｏｔｅｃｔｉｏｎ Ｐｒｏｆｉｌｅ ２００３年１０月、バージョン０．２８ ＣＥＮ／ＩＳＳＳ Ｅｌｅｃｔｒｏｎｉｃ Ｓｉｇｎａｔｕｒｅ （Ｅ−ＳＩＧＮ） Ｗｏｒｋｓｈｏｐ ［ＧＲ０１］ Ｒｏｓａｒｉｏ Ｇｅｎｎａｒｏ及びＰａｎｋａｊ Ｒｏｈａｔｇｉ著 「Ｈｏｗ ｔｏ ｓｉｇｎ ｄｉｇｉｔａｌ ｓｔｒｅａｍｓ」 Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｐｕｔａｔｉｏｎ １６５（１）：１００−１１６頁、 ２００１年 ［Ｇｕｒ１０］ Ｅｍｉｌ Ｇｕｒｅｖｉｔｃｈ著 「Ｐｒｏｖｉｄｉｎｇ ａ ｔａｍｐｅｒ−ｅｖｉｄｅｎｔ ｌａｙｅｒ ｆｏｒ ｌｏｇｓ ｕｓｉｎｇ ｓｅｃｕｒｅ ｈａｒｄｗａｒｅ」 Ａｃａｄｅｍｉｃ ｄｉｓｓｅｒｔａｔｉｏｎ ＩＭＭ−Ｂ．Ｅｎｇ．−２０１０−３４頁、２０１０年、 デンマーク工科大学（ＤＴＵ） ［Ｈｏｌ０６］ Ｊａｓｏｎ Ｅ． Ｈｏｌｔ著「Ｌｏｇｃｒｙｐｔ： ｆｏｒｗａｒｄ ｓｅｃｕｒｉｔｙ ａｎｄ ｐｕｂｌｉｃ ｖｅｒｉｆｉｃａｔｉｏｎ ｆｏｒ ｓｅｃｕｒｅ ａｕｄｉｔ ｌｏｇｓ」 ＡＣＳＷ Ｆｒｏｎｔｉｅｒｓ ’０６：Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００６ Ａｕｓｔｒａｌａｓｉａｎ ｗｏｒｋｓｈｏｐｓ ｏｎ Ｇｒｉｄ ｃｏｍｐｕｔｉｎｇ ａｎｄ ｅ−ｒｅｓｅａｒｃｈ ２０３−２１１頁、 オーストラリアコンピュータ学会 ２００６年

本発明の目的は、デジタル署名の監査を可能にするためのシステムを提供することである。

第１の態様によると、本発明は、アプリケーションと通信するサーバを含むコンピュータ化されたシステムに実装される、デジタル署名の監査を可能にするための方法として具体化され、サーバにおいて、
−アプリケーションの１つ又は複数によって発行された１つ又は複数の署名要求を受信するステップと、
−受信した署名要求に対応する第１のデータを、第１のデータの後の署名のために、１つ又は複数の署名エンティティに転送するステップと、
−基準システム状態と、
−受信した署名要求に対応する第２のデータと
の関数を用いて計算された更新システム状態を格納するステップであって、基準システム状態及び更新システム状態は署名要求を証明するものである、格納するステップと、
−更新システム状態を新たな基準システム状態として用いて、上述のステップを繰り戻すステップと、
を含む。

他の実施形態においては、本方法は、以下の特徴のうちの１つ又は複数を含むことができる。
−本方法は、サーバにおいて、第１のデータの転送に応答して、署名エンティティから応答を受信することをさらに含み、第２のデータは、受信した応答におけるデータに対応する第３のデータを含む。
−転送された第１のデータは、要求側アプリケーション当たり最大で１つの署名要求を保持する。
−更新システム状態は、以前のシステム状態と、少なくとも２つの別個のアプリケーションから受信した署名要求に対応する第２のデータとの関数を用いて計算される。
−格納することは、第２のデータを基準システム状態と更新システム状態とを含むシステム状態のシーケンスに集約することによって得られる集約データの組を格納することを含み、集約することは、好ましくは、第２のデータをシステム状態のシーケンスにインターレースすることを含む。
−転送することは、サーバにおいて受信したそれぞれの署名要求に各々が対応する第１のデータのサブセットの組を、第１のデータのサブセットの後の署名のために、それぞれの署名エンティティにディスパッチすることを含む。
−いつディスパッチするかは、好ましくは量子化された時間間隔を用いて、タイミング制約に基づいてサーバにおいて判断される。
−本方法は、以前に転送された第１のデータが１つ又は複数の署名エンティティにおいて署名されている間、対応する第１のデータを転送する前に、受信した１つ又は複数の署名要求を遅延させることをさらに含む。
−格納することは、第２のデータを基準システム状態と更新システム状態とを含むシステム状態のシーケンスに集約することによって得られる集約データの組を格納することを含み、本方法は、サーバにおいて、アプリケーションの１つからクエリを受信し、集約データの組に基づいて、アプリケーションの１つに応答することをさらに含む。
−本方法は、サーバにおいて、第１のデータを転送することに応答して、署名エンティティから応答を受信することをさらに含み、応答は信頼できる時間データを含む。
−署名エンティティはハードウェア・セキュリティ・モジュールである。
−本方法は、基準システム状態及び更新システム状態に基づいて、署名要求又は関連データを監査することをさらに含む。
−前述の関数は、非可逆関数である。

別の態様によると、本発明は、アプリケーション及び署名エンティティと通信するように適合されたサーバを含み、サーバは上述の実施形態による方法のステップを実装するように構成された、コンピュータ化されたシステムとして具体化される。

最後の態様によると、本発明は、コンピュータ化されたシステムに、上述の実施形態のステップを実装させるための命令を含む、コンピュータ可読媒体上に常駐するコンピュータ・プログラムとして具体化される。

実施形態による、署名エンティティから戻されてシステムレベルの状態のシーケンスに集約された、タイムスタンプのような発行されたデジタル・イベントのシステムレベルの図を示す。 実施形態による、図１の状態シーケンス内のアプリケーション固有の状態チェインを示す。 実施形態による、デジタル署名の監査を可能にするためのコンピュータ化されたシステムの種々の構成要素を示す。 実施形態において得られる、タイムスタンプ・シーケンスの典型的なアプリケーションの図を示す。 実施形態による、署名をディスパッチ／受信するサーバによって用いられる時間許容ウィンドウを示す。 実施形態における、署名エンティティ、サーバ及びアプリケーションによって行われる典型的なステップのフローチャートである。 本発明の実施形態による方法のステップを実装するのに適したコンピュータ化されたユニット（例えば、サーバ・コンピュータ、署名者エンティティ、又はサポートする実行アプリケーション）の例を概略的に示す。

ここで、本発明を具体化するシステム、方法、及びコンピュータ・プログラム機能が、限定されない例として、添付図面を参照して説明される。

第１に、本発明の実施形態による方法の一般的な態様が、その高レベルの異なる形態と共に説明される（第１節）。次に第２節において、より具体的な実施形態が説明される。

１．本発明の一般的な態様
図１乃至図６を参照すると、本方法は、典型的には、アプリケーションＡ，Ｂ，Ｃ，・・・の組３０と通信する、すなわち要求をサーバに送信しサーバから更新を受信する、サーバ１０を含むコンピュータ化されたシステム１に実装される。サーバ１０は、前述のアプリケーションと、それ自体が公知であるタイムスタンプなどのデジタル署名を配信する、典型的にはＨＳＭである署名エンティティＳｉｇ_ｍの組２０との間のインターフェースとしても機能する。このように、システム１は、主として、サーバ１０、例えばタイムスタンプ・サーバを含む。システム１は、アプリケーション及び／又は署名エンティティと、本明細書に記載される認証機関４０、署名者証明書５０、システム状態チェイン１５等の他のエンティティ／構成要素とを「含む」ものとみなすこともできる。

１．１．本方法の一般的な実施形態
以下のステップは、サーバ側の視点から説明されるものとして実装される（図６のフローチャートに重点が置かれる）。
−ステップＳ１３：それぞれのアプリケーションＡ，Ｂ，Ｃによって発行された（ステップＳ３１）アプリケーション状態又はアプリケーション関連イベントのようなアプリケーション関連データａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・が、サーバにおいて受信される。そのようなデータａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・は、一般に、署名が要求されるアプリケーションのアクティビティ又はイベントを示し、これらは、サーバによって署名要求として解釈される。このような要求をサーバにおいてどのように正確に扱うことができるかについては、後述される。

−ステップＳ１４：サーバは、受信した署名要求に対応する第１のデータ（Ｄ_１，ｎと呼ぶ）を、後の署名（ステップＳ２１）のために、署名エンティティＳｉｇ_ｍ（又は略して「署名者」）の組２０に転送する。サーバが署名要求をどのように正確に署名者にディスパッチできるかは、後で考察される。

−次にステップＳ１５では、典型的には、非可逆である関数ｆを用いて更新システム状態Ｓ_ｎ＋１、すなわちｓ_ｎ＋１＝ｆ（ｓ_ｎ，Ｄ_２，ｎ）が計算され、次いで、更新システム状態Ｓ_ｎ＋１は、ステップＳ１６において、サーバによって、何らかの都合の良い位置に格納されるよう命令される。この関数ｆは、引数として以下のものを取る。
−典型的には以前に計算された状態であり、現在のサイクルｎの基準状態として機能する、基準システム状態ｓ_ｎ（ステップＳ１２を参照されたい）
−同じサイクル中に受信され署名者に転送された署名要求に対応する第２のデータ（一般にＤ_２，ｎによって示される）

Ｄ_１，ｎ及びＤ_２，ｎはいずれも、受信した要求に対応するデータである（すなわち、Ｄ_１，ｎ及びＤ_２，ｎの各々は、要求に論理的に関連する）が、これらは同じデータである必要はない。理解されるように、Ｄ_２，ｎは、
−現在のサイクルｎ中にサーバにおいて受信したアプリケーション関連データａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・、及び／又は、
−ａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・に対応するデータＡ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・
に対応するか又はこれらを含むこともでき、Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・は、特に、サイクルｎ内で署名エンティティによって戻されたタイムスタンプ（ステップＳ２２）を含む。興味深いことに、Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・が含まれない場合には、システム状態の更新は、署名と並行して行うことができる。しかし、Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・を含むことによって、署名データより価値があると考えることができる発行された署名を集約することにより、より高レベルの保証がもたらされる。

−最後に、更新システム状態ｓ_ｎ＋１を、システム状態に対する後の更新の計算のための新しい基準状態として用いて、前述のステップ（Ｓ１２−Ｓ１６）が繰り返される。

その結果、システム状態のシーケンス｛・・・，ｓ_ｎ，・・・｝が得られ、これが署名要求を証明する。具体的には、２つの連続する（又は少なくとも後続の）状態、すなわちｓ_ｎ及びｓ_ｎ＋１＝ｆ（ｓ_ｎ，Ｄ_２，ｎ）は、Ｄ_２，ｎを証明する。シーケンス全体が、署名要求の履歴をたどるものとなる。そのようなシステム状態の更新プロセスによって、後で監査プロセスの際に調査されるように（ステップＳ４１）、完全性の保証を提供するシステムレベルのシーケンス（例えば、図１におけるｓ_１−４を参照）が得られる。

１．２．高レベルの異なる形態
好ましくは、上述のように、サーバは、Ｄ_１，ｎに応答して署名者から戻されたデータを用いて（ステップＳ２２）、システム状態を更新する。戻されるデータは、Ｄ_１，ｎに論理的に関連するタイムスタンプ（及び場合によっては付加的な信頼できる時間データｔ_ｉ）のような第３のデータＤ_３，ｎ＝Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・を含む。

実際には、戻される応答は、タイムスタンプである。タイムスタンプは、例えば、高保証環境のために、更新プロセスに含まれることが好ましい。戻されるタイムスタンプは、これを生じさせた要求に対する何らかの参照又はその要求に含まれるか若しくはその要求において参照されるイベントａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・等を保持することができる。従って、要求それ自体は、廃棄されることがある。しかし、各々の関連するデータ（要求又はアプリケーション関連イベント＋タイムスタンプ）を集める方がより簡単な場合もある。

これに従って幾つかのケースを区別することができる。
（ｉ）ｓ_ｎ＋１＝ｆ（ｓ_ｎ，ａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・）、すなわち、システム状態は、以前の状態ｓ_ｎ及び署名要求（又は関連データ）のみに基づいて更新され、これはある程度の並行化を可能にする。
（ｉｉ）ｓ_ｎ＋１＝ｆ（ｓ_ｎ，ａ_ｉ，ｂ_ｉ，ｃ_ｉ，・・・，Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・）、すなわち、更新プロセスはさらに、署名者から戻された応答を考慮する。
（ｉｉｉ）ｓ_ｎ＋１＝ｆ（ｓ_ｎ，Ａ_ｉ（ａ_ｉ），Ｂ_ｉ（ｂ_ｉ），Ｃ_ｉ（ｃ_ｉ），・・・）、同じように、署名者から戻された応答は、要求に対する何らかの参照を保持しており、従って、（サーバで最初に受信される）アプリケーション関連イベントは、更新プロセスにおいて保持される必要がない。
（ｉｖ）ｓ_ｎ＋１＝ｆ（ｓ_ｎ，Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・）、ここでは、サーバにおいて受信された要求は更新プロセスから廃棄されるが、そうでなければ、Ａ_ｉ，Ｂ_ｉ，Ｃ_ｉ，・・・をａ_ｉ，ｂ_ｉ，ｃ_ｉ，…にマッピングすることができるものと仮定される。
（ｖ）その他。

第２節において与えられる理由のため、上述のケース（ｉｉｉ）又は（ｉｖ）が好ましい。

次に、一義的なディスパッチ・プロセスは、更新の同じサイクルｓ_ｎ−ｓ_ｎ＋１内で、要求側アプリケーションＡ，Ｂ，Ｃ当たり最大で１つの署名要求ａ_ｉ，ｂ_ｉ，ｃ_ｉを保持することが好ましい。

さらに、図１に示されるように、システム状態の更新プロセスは、並行アプリケーションに関するデータをエンコードすることが好ましい。すなわち、状態ｓ_ｎ＋１は、２つ又はそれより多い別個のアプリケーションからの要求に対応し得る第２のデータＤ_２，ｎに基づいて得られる。例えば、図１に示されるように、ｓ_２は、特にＡ_１及びＢ_２、すなわち、アプリケーション・データａ_１、ｂ_２すなわちアプリケーションＡ及びＢに対応するデータを用いて、ｓ_１から得られる。同様に、ｓ_３は、Ａ_２及びＣ_１を用いてｓ_２から得られ、以下同様である。消されたボックスの意味は後で説明される。

さらに異なる形態も想定することができ、ここでは、システムの更新が、ベクトルすなわちｓ_ｎ＋１＝｛ｓ_{Ａ，ｎ＋１}，ｓ_{Ｂ，ｎ＋１}，ｓ_{Ｃ，ｎ＋１}，・・・｝として構造化され、その成分がそれぞれのアプリケーションＡ，Ｂ，Ｃ，・・・に対応する（これは、いずれにしても１つのアプリケーションだけがサーバと情報をやりとりする場合である）。そうした異なる形態は、アプリケーションの数が一定であるか又は限定されたシステムに適している場合がある。しかしながら、これらの形態は、サーバが変更可能なクライアント・アプリケーションと情報のやりとりを行う場合、特にサーバが不正アプリケーションＲにさらされている場合は、システム状態の進化ｓ_{Ｒ，ｎ＋１} ＝ ｆ（ｓ_Ｒ，ｎ， …）が、より予測可能に、おそらくあまりにも予測可能になり過ぎることがあるため、好ましくない。そうした異なる形態は、例えば、
（ｖｉ）ｓ_ｎ＋１＝｛ｓ_{Ａ，ｎ＋１}，ｓ_{Ｂ，ｎ＋１}，ｓ_{Ｃ，ｎ＋１}，・・・｝＝｛ｆ（ｓ_Ａ，ｎ，ａ_ｉ，・・・），ｆ（ｓ_Ｂ，ｎ，ｂ_ｉ，・・・），ｆ（ｓ_Ｃ，ｎ，ｃ_ｉ，・・・），・・・｝
（ｖｉｉ）ｓ_ｎ＋１＝｛ｓ_{Ａ，ｎ＋１}，ｓ_{Ｂ，ｎ＋１}，ｓ_{Ｃ，ｎ＋１}，・・・｝＝｛ｆ（ｓ_Ａ，ｎ，Ａ_ｉ，・・・），ｆ（ｓ_Ｂ，ｎ，Ｂ_ｉ，・・・），ｆ（ｓ_Ｃ，ｎ，Ｃ_ｉ，・・・），・・・｝
（ｖｉｉｉ）その他
と示すことができる。同様に、システムの更新は、ベクトルｓ_ｎ＋１＝｛・・・，ｓ_{ｍ，ｎ＋１}，ｓ_{ｍ＋１，ｎ＋１}，ｓ_{ｍ＋２，ｎ＋１}，・・・｝として構造化することができ、各成分は特定の署名者ｍに対応する。

ついでに言えば、さらに他の異なる形態を想定することができ、ここでは、関数ｆは、引数として、例えばｓ_ｎ＋１＝ｆ（ｓ_ｎ−１，Ｄ_２，ｎ）のように、Ｄ_２，ｎに加えて以前に計算されたいずれかの状態ｓ_ｎ−ｐ又はその組み合わせ｛ｓ_ｎ−ｐ，ｓ_ｎ−ｑ｝をとる。従って、基準状態は、必ずしも、直前に計算されたシステム状態とは限らない。すべての場合において、アプリケーション要求の履歴を記録することを可能にするスキームが達成される。

次に、更新された状態を格納することは、前述の第２のデータＤ_２，ｎをシステム状態のシーケンス｛ｓ_ｎ，ｓ_ｎ＋１｝１５に集約すること（ステップＳ１６）を含むことができる。結果として得られる典型的な構造は、図１の構造を反映する。例えば、簡単な集約スキームは、第２のデータを前述の状態のシーケンスにインターレースすることからなり、これは、保持される計算スキームに応じて、｛ｓ_ｎ，｛ａ_ｉ，ｂ_ｉ，・・・｝，ｓ_ｎ＋１｝又は｛ｓ_ｎ，｛ａ_ｉ，ｂ_ｉ，・・・｝，｛Ａ_ｉ，Ｂ_ｉ，・・・｝，ｓ_ｎ＋１｝等と示すことができる。シーケンスは、例えば暗号化などを行って適切に格納され、後で監査エンティティ４０が利用できるようにすることが可能である。必要であれば、サーバは、ステップＳ１８において、要求に応じて前述のシーケンスへのアクセスを与えることができる。異なる形態では、監査エンティティ４０は、格納されたシーケンス１５にアクセスする。

ここで、署名者への要求の割り当てをより詳細に説明する。好ましくは、前述の第１のデータを転送すること（ステップＳ１４）は、ステップＳ１３において受信されたそれぞれの署名要求ａ_ｉ，ｂ_ｉ，・・・に対応するデータのサブセットを、後の署名のために、それぞれの署名者にディスパッチすることを含む。以下は、図１を反映する例である。
−最初に基準システム状態ｓ_１を識別する（図６のステップＳ１２も参照）
−署名要求｛ａ_１，ｂ_２｝を受信する（図６のステップＳ１３も参照）
−対応するデータを署名のために送信する（ステップＳ１４、Ｓ２１）。より正確には、署名要求ａ_１及びｂ_１のそれぞれに対応する第１及び第２のデータのサブセットが、後の署名のために、それぞれ署名者Ｓｉｇ_１及びＳｉｇ_２に割り当てられる。署名者Ｓｉｇ_１及びＳｉｇ_２は、ステップＳ２２において、対応するタイムスタンプ・データ｛Ａ_１，Ｂ_１｝を戻し、これら自体を用いて（ａ_１，ｂ_１に加えて／ａ_１，ｂ_１の代わりに）システム状態をｓ_２等に進めることができる。

従って、図１における基準ｓ_１乃至ｓ_５は、連続的なシステム状態を示す。水平のラインは、所与の署名者に対応する。署名者は並行して動作する。従って、
−Ａ_１は、署名者Ｓｉｇ_１から戻された第１のタイムスタンプを示し、アプリケーションＡの第１のアプリケーション状態／イベントａ_１に対応する。
−同様に、Ｂ_１は、アプリケーションＢの第１のアプリケーション・データｂ_１についての第１のタイムスタンプに対応するが、ｂ_１に対応するデータは、署名者Ｓｉｇ_２にディスパッチされたものである。
−Ａ_２は、アプリケーションＡについてＳｉｇ_１から戻された第２のタイムスタンプに対応する。Ｓｉｇ_１が、アプリケーションＡ専用であるように見えるのは偶然であるが、原則的に、署名者が専用アプリケーションに割り当てられる実施形態を想定することができる。
−Ｃ_１は、アプリケーションＣについて第２の署名者Ｓｉｇ_２から戻された第１のタイムスタンプに対応する。
−その他。

いつディスパッチを行うかは、例えば、量子化された時間間隔などのタイミング制約に基づいて、サーバにおいて判断される。例えば、サーバは、以前に転送された要求が署名者Ｓｉｇ_１−４において署名されている間、受信されつつある署名要求ａ_ｉ，ｂ_ｉ，ｃ_ｉをバッファに格納する。このことについては、図５を参照して後で再度説明される。他の異なる形態も想定することができる。例えば、受信された要求が所定数に達したときに、サーバは、要求を署名者に転送する。

図２は、図１に対応する状態チェインの経路を、さらにアプリケーションの視点から示す。図３に示されるように、アプリケーションは、自分自身の状態チェイン３５を保持することができるが、保持しなくてもよい。この点について、実施形態は、アプリケーションが自分自身の状態を照会／チェックすることを可能にするものである。典型的には、所望の場合には、アプリケーションは、例えば、所与の基準アプリケーション状態、タイムスタンプ、又はさらにシステム状態についても、サーバに照会することができる。これに応答して、サーバは、単に集約データ１５を検査することによって、いずれかの関連する答えを提供することができる。例えば、サーバは、先に説明されたものと同様のスキーム、すなわち図６のステップＳ１３乃至１５、Ｓ１７を反映するスキームを用いて得られる更新システム状態を計算し、これを前述のアプリケーションに戻すことができる。興味深いことに、システムは、システム状態チェイン１５に必要なデータ以上には、アプリケーション・データを持続的に格納する必要はない。システム状態チェイン１５に必要なデータには、いずれかの場所に格納されたアプリケーション関連データを指し示す識別子を用いる簡略化されたフォーマットの接頭辞を与えることができ、その結果として拡張性を有する。

ここで、より具体的な実施形態を参照して、さらに詳細を説明する。

２．具体的な実施形態
以下では、デジタル署名の監査を可能にするための方法及びシステムの具体的な実施形態が、図１乃至図４を参照して説明される。具体的には、集中システムと分散システムの要素を組み合わせ、例えばアプリケーション関連イベントのようなアプリケーション・データを証明するタイムスタンプのようなデジタル署名を生成することができる、タイムスタンピング・サービスなどの署名サービスが説明される。

独立のデジタル署名（タイムスタンプを含む）に加えて、そのようなシステムは、後でイベントのシーケンス全体が変更されるのを防ぐように、各々が、進化するシステム状態（全体及び個々のアプリケーションのシステム状態を含む）の単一方向のシーケンスを追跡することを可能にする、多数のアプリケーションをサポートすることができる。そのようなシーケンスを、高保証の暗号化により安全な監査ログとして用いて、個々のタイプスタンプだけでなく、イベントのシーケンス全体の完全性及び確実性を証明することができる。

そうしたシステムはまた、システムレベルの集約状態のシーケンスを提供し、同じ完全性の保証の下でシステム全体に及ぶ監査を可能にするものである。組み合わされたログによって、このシステムが、接続されたクライアント・アプリケーションの履歴について強力な証拠を与えることが可能になる。システムは、バックエンドの署名デバイス数をユーザに意識させないで変更して、任意の大きな署名スループットをもたらすことができる。

２．１．システムの構成要素
前述のように、システムはサーバ１０を含み、サーバ１０は、要求キューを調整し、より権限の低いアプリケーション／ジョブの組を供給し、以下の構成要素（例えば、図３を参照）を備えた中央ディスパッチャとして機能する。

１．関連する情報を暗号的に強力な方法で集約する、非可逆的な一方向性関数を通して進められた、システム状態のシーケンス（図１における「状態チェイン」、ｓ_１−ｓ_５）。このような関数自体は周知である。前述のように、状態ｓ_ｎ＋１は、以前の状態ｓ_ｐ（ｐ≦ｎ）、すなわち（署名者からの応答に対応するデータのような）受信された要求に対応するデータに基づいて計算される。典型的な実装形態は、偽造（要素の挿入又は除去）が不可能な「ハッシュ・チェイン」又は同様な一方向シーケンスを用いる。

２．その入力キューからタイムスタンプ要求を（一義的に）オーダーし、任意の数の署名者Ｓｉｇ_ｎにディスパッチし、対応する応答を経路指定して要求側アプリケーションに戻す、ディスパッチャ。ディスパッチャはまた、時間を量子化し、「タイムスタンプ（発行）サイクル」（図５）を生成し、以前にディスパッチされた要求が署名されている間に到着する要求を遅延させる（図１におけるＡ_１・・・Ｃ_２を参照）。

タイムスタンプ・サイクルは、時間を量子化して、所与の、例えば最悪の場合には署名待ち時間の解像度まで、小さくする。署名待ち時間は、ディスパッチャに影響を与えないように十分に短いものであると仮定する。これは、署名エンティティの十分な署名能力を仮定するものである。

３．ディスパッチャ（サーバ）は、署名者のハードウェア・セキュリティ・モジュール（ＨＳＭ）又は同等の高保証署名デバイスなどの適切な署名者Ｓｉｇ_１−ｎの組２０を保持する（例えば、非特許文献３を参照されたい）。例えば、新たに挿入された後端の署名者ｓ_５は、図１においてｓ_４が到達したときにアクティブにすることができる（Ｓ１１、図６）。異なる形態では、署名者はまた、その内部クロックを維持し、信頼できる時間値をタンプスタンプ構造に挿入するので、ホスト自体のクロックの信頼性は必要としない。

ディスパッチャは、サービス品質保証、優先レベル、又は他の既知のキュー管理機能を提供することができる。簡単にするために、中央キューが用いられるものと仮定されるので、これらの詳細は、ここでこれ以上説明しない。

４．自分自身のアプリケーションレベルの状態ａ_ｉ，ｂ_ｉ，ｃ_ｉ，…を各々が保持し、イベントの論理チェイン３５を形成する、１つ又は複数のアプリケーションＡ，Ｂ，Ｃ，…の組３０。アプリケーションは、自分自身の状態を保持し、その状態に対する更新に基づいて（図１又は図２におけるＡ_１−Ａ_４又はＢ_１−Ｂ_３のような）論理チェインを形成する。

アプリケーションは、要求を一義的にオーダーするので、同じアプリケーション状態から複数のイベントをサブミットしないことが好ましい（こうしたイベントをサブミットすることによって、曖昧になり、チェインを分岐させ、従って無効になる）。しかし、そのような無効な呼び出しシーケンスに対しては、実装形態に応じた応答を想定することができる。適切な応答は、例えば、そうした最初の要求を処理し、同じアプリケーションからのその後のイベントを無視するものである。換言すれば、新たなシステム状態の計算のために、要求側アプリケーション当たり最大で１つの署名要求が現在のサイクル内で保持される。従って、アプリケーションレベル・データａ_ｉ，ｂ_ｉ，ｃ_ｉ，…は、アプリケーション状態と、任意のアプリケーションレベル・イベントとを示す。他のシステム特有の反応を定義することもできる。

５．タイムスタンプについての要件を有するが、状態の論理的なシーケンスは保持しない、サーバと通信する付加的なアプリケーションを提供することができる。そのようなアプリケーションは、デジタル署名されたタイムスタンプを所有の証明として保持するが、相対的な順序付けの証拠を構成しない、従来のタイムスタンプ・ユーザである。リアルタイム・クロックの差は、複数の署名者がいる場合には、タイムスタンプが存在していたとしても順序付けが不正確なことを意味する場合があることに留意されたい。

ここで説明される具体的な実施形態においては、システムは、副次的な効果として従来のタイムスタンプ・ユーザを管理し、本発明の目的の場合には、これらのユーザは、自分自身の状態チェインを無視するが、実際にはシステム全体に及ぶチェインに含まれるアプリケーションである。

この点で、図１において消された署名は、独立のタイムスタンプに対応しており、状態への破線の接続は、送信元アプリケーションが無視するシステム状態の更新を示す。

６．サーバによって実装される一義的なソート／割り当て戦略であり、これは、要求を署名者に割り当て（すなわち、ステップＳ１４における転送）、その割り当て（すなわち、ａ_ｉ，ｂ_ｉ，ｃ_ｉ又は対応するデータ）をシステム状態ｓ_ｎの更新ｓ_ｎ＋１にエンコードする（ステップＳ１６）。前述のように、ステータスの更新は、システム要件に応じて、署名されたタイムスタンプＡ_ｉ，Ｂ_ｉ，Ｃ_ｉを含んでもよいし、含まなくてもよい。タイムスタンプが含まれない場合には、ステータスの更新は、署名と並行して行われ、プロセスの効率を改善することができる。

７．ハッシュ値のようなイベント（例えば、アプリケーションＢのアプリケーション状態ｂ_１≡｛ｂ_００，ｂ_０１｝に関するイベントｅ_ｂ，１、図４を参照）と、必要に応じてアプリケーションレベルの状態自体（ｂ_１≡｛ｂ_００，ｂ_０１｝）とを、署名されたタイムスタンプ構造Ｂ_１に変換して、存在する場合にはアプリケーションの状態を（ｂ_２≡ ｛ｂ_００，ｂ_０２｝に）進め、すべての場合においてシステムの状態を（ｓ_１からｓ_２に）進める、公開インターフェース。アプリケーション関連イベントは、文書の暗号学的ハッシュなどの暗号学的ハッシュとするか、又は、アプリケーションがログを取る価値があると考えるシステム変更とすることができる。従って、例えば、同様な一方向性関数を用いるなどして、同じサーバを用いてシステム状態及びアプリケーション状態の両方を進ませ、結果としてｂ０１／ｂ０２／ｓ１／ｓ２等の集約が得られる。

呼び出し側アプリケーションが要求する場合には、タイムスタンプＢ_１の発行前のシステム状態（ｓ_１）及び発行後のシステム状態（ｓ_２）が与えられることになる。図４において、ｓ_１及びｓ_２は、ｓ_２に進んだ後でアプリケーションＢに戻される（図６におけるステップ１７も参照）。同様に、この例においては、ｓ_３及びｓ_４は、ｓ_４に進んだ後で戻される。信頼できる時間値ｔ_１、ｔ_２も同様に戻すことができる。アプリケーションの視点からは、自分自身の状態チェインに沿ってアプリケーションが見るシステム状態のシーケンスは、連続的でない場合があることに留意されたい。例えば、図１において、Ｂ_１の発行後のシステム状態（状態ｓ_２）は、Ｂ_２（すなわち、アプリケーション視点からのＢ_１の論理的後継者）の発行前の初期システム状態ｓ_３とは異なっている。

２．２ 利点
上述の構成要素から構築されたシステムは、ここで説明されるように、多くの利点を有する。

２．２．１ アプリケーションの独自性
固定サイズのシステム全体に及ぶチェイン状態１５が格納される。より具体的には、「固定サイズ」とは、どれだけ多くのデータが集約されたかに関係なく、固定数のビットで表わされる暗号学的ハッシュを意味する。チェイン状態１５は、典型的には、図１のシステムレベルのチェインを反映して｛…，ｓ_ｎ，｛Ａ_ｉ，Ｂ_ｉ，…｝，ｓ_ｎ＋１，…｝として表わすことができる。従って、アプリケーション状態は、アプリケーション・ストレージに属するので、システムは、多数のアプリケーションに合わせてスケーリングすることができる。これによって、システムは、アプリケーション特有のリソース・リークを伴うアプリケーションのターンオーバーに容易に耐えることができるようになる。

２．２．２ 複数のアプリケーションに対する無制限のスケーリング
固定サイズのシステム全体にわたるチェイン状態のみが格納されるので、システムは、アプリケーション状態の追跡が分散されるときに、多数のアプリケーションに合わせてスケーリングすることができる。アプリケーションレベルのチェインの値は、別個に保持することができるが、アプリケーションレベルの状態のチェインは、システムレベルの状態の単一のシーケンス１５に統合される。システムレベルの監査が行われる場合には、この結合によって、構成要素であるすべてのアプリケーション・チェインの否認防止が可能になる。

アプリケーションは、さらに、各タイムスタンプを用いて現在のシステム状態を照会することができるので、自分自身の状態を証明し、システムレベルの状態を差し戻す、対応する能力を得る。アプリケーションとシステムとの間のこのような結合は、複数の（相互に信頼できない）アプリケーションが直接やりとりして瞬時性／所有権を証明しなければならないときに、特に有利である。従って、これらは、本スキームに頼ることができるという利点を有する。

２．２．３ 署名者のスムーズな管理
署名者は、要求の経路指定に直接参加しないので、署名者の追加又は削除は、アプリケーションからは見えない。例えば、オフライン管理は、全サイクルの開始時（例えば、図１において状態ｓ_４を得た後）に挿入される署名者を設定する（例えば、図６におけるステップＳ１１）と仮定することができる。システムは、その第１の動作として「署名者が導入した」イベントを署名し、新たな署名者常駐鍵の導入を監査チェインに結合するものと仮定することもできる。

２．２．４ アプリケーションの初期状態の集中割り当て
偶発的な状態の衝突からシステムを保護するために、アプリケーション状態を、更新された状態と固定的な状態とに分割することができ、アプリケーション状態の更新プロセスは、可変部分しか更新しない。例えば、図４におけるｂ_１−３ ≡｛ｂ_００，ｂ_{０１−０３}｝のように、ｂ_００（固定状態）は、集中割り当てされたと仮定すると、更新されない。しかし、アプリケーション接頭辞は、集中レジストリなしで割り当てることができる。例えば、集中ディスパッチャは、ホスト・アプリケーションについて十分に知っており、実質的に固有の識別子をホスト・アプリケーションから導き出すことができる。

実際的なシステムは、衝突の機会が無視できる程度である状態導出関数を用いる可能性が高いので、未知の脅威に対する保護も望まれるシステムの場合には、明確な衝突防止が関心事である。

２．２．５ ディスパッチャの複雑性
キュー管理オーバーヘッドとは別に、システムは、アプリケーション要求の集中管理と、アクティブな証明者の組への一義的なディスパッチとを要求することがある。キューイング・アルゴリズムが最優先の要求を選択すると、これらの動作のほとんどは、署名デバイスの数に対応する。署名デバイスの数は、一般に、特に高保証の集中環境においては、要求側アプリケーションの数よりはるかに少ないので、ディスパッチャの動作は、それほど大きなオーバーヘッドを加えるものではない。

２．３ 発展形態
ここで幾つかの発展形態を説明する。

２．３．１ 複数の例
本発明のシステムの幾つかのコピーは、メインフレームのシスプレックスのような結合システムに配置された場合には、連携することができる。そのようなグループの公開鍵は、例えば管理された制御の下で同期することができ、管理されたタイムスタンプ・サイクルが、周期的に導入される場合がある。複数のインスタンス間のクロス署名タイムスタンプによって、複数のインスタンスが、相互のクロック・スキューを監視し、インスタンスが分岐するときにシステムに警報を出すことが可能になる。

２．３．２ 鍵付き状態変換
ＨＭＡＣのような鍵付き変換を用いて状態を進める場合には、システムは、ハッシュ関数の選択にかかわらず、アプリケーションによって引き起こされるハッシュ衝突に対する耐性（イミュニティ）を獲得する。アプリケーションがタイムスタンプのディスパッチャを危険にさらすものではないと仮定すれば、ディスパッチャによって格納される状態変換鍵（ＳＴＫ）は、こうした発展形態に対して十分に安全である。

鍵付き変換でシステム状態を進めることは、わずかなオーバーヘッドを加えるだけであるが、アプリケーションが次のシステム状態を予測すること又はシステムを既知の状態に導くことを不可能にする。理論的には、軽負荷のシステムにおいては、又は、不正アプリケーションが他のアプリケーションにタイムスタンプ・サービスを要求させないようにする場合には、（システムは公衆データ構造及びアルゴリズムのみに基づいて構築される可能性が高いため）システム状態を進めるために組み合わされるすべてのデータをモデル化し、予測することができる。不正アルゴリズムは、自分自身のイベントを適応的に選択できるものと仮定すると、タイムスタンプを高精度で推測し、照会を通して他の状態を得ることができる。対照的に、ディスパッチャによって制御される鍵と共に、鍵付き変換を用いると、状態変化は、アプリケーションによって観察され影響を受けるだけであり、予測はされない。

典型的なサーバ又は共有環境においては、非同期アプリケーションＡ，Ｂ，Ｃ，…は、こうした状態制御攻撃を実行不可能にするのに十分な要求のストリームを混乱させる可能性があることに留意されたい。他のシステムにおいては、状態を進めさせるために、鍵付き変換を義務付けることが賢明である。

タイムスタンプはＨＳＭ常駐署名者によって生成されるので、発行されたタイムスタンプのセキュリティは、ＳＴＫの機密性と無関係である。従って、ＳＴＫは、ホスト内に常駐することができ、安全なハードウェア内での保護は不要である。アプリケーションがディスパッチャを危険にさらす可能性がある場合には、アプリケーションは、インフラストラクチャのレベルで−暗号的にではなく、サービス妨害によって−システムを混乱させることもあり、従って、本実施形態は、特にＳＴＫの損失を防ぐものではない。

２．４ 付加的な考慮事項
付加的な実装形態の詳細が以下で説明される。

２．４．１ 署名鍵と状態の格納の分離
システムは、安全な署名デバイスの外部に、イベントの相対的な順序付けについての状態情報を格納するが、安全なハードウェア内部に高保証の署名鍵を格納する。結果として、幾つかの実施形態は、イベントが署名者に送信される前に、少なくとも、連携するホスト・コードに依存してイベントを適切に順序付ける必要がある。しかし、安全なハードウェアは、既に、ホスト・エンティティ（プロセス、ジョブ、スレッド）の分離／追跡のためのホスト連携と、Ｉ／Ｏデバイスには見えない同様な概念とに依存している。従って、本実施形態は、この依存性を、個々の要求だけでなく、イベントのシーケンスまで拡張する。署名は、シーケンス全体を暗号的に結合するため、動作が異常なホスト・ライブラリが、システムの監査中に顕在化することになる。しかし、不正なホスト・コードは、要求をローカルに再順序付け又は変更したとしても、署名を、従ってそれらのタイムスタンプの認証されたシーケンスを、依然として偽造しない場合がある。

２．４．２ 時間の同期
バックエンドの署名者間でのクロック・ドリフトは、一貫性のない署名者内部時間なしでシステムを稼働できるようにするのに十分なだけ小さいものと仮定する。署名者のクロック・ドリフトは、異なる署名者間の最悪の場合のタイムスタンプが矛盾しないように、十分に小さいままであることが必要な場合がある。システムは、要求を同期させるため、最悪の場合のイベントでさえ含まなければならない明確に定義されたウィンドウが存在する。従って、図５を参照すると、許容（時間）ウィンドウ２１０、２２０が、公称タイムスタンプ・ウィンドウ２３０の両側に設けられ、ウィンドウ構成要素２１０、２３０及び２２０を並べると、全サイクル２４０となる。図５の例においては、ウィンドウ２１０は、「速い署名者」に対するものであり、一方、ウィンドウ２２０は「遅い」署名者に対するものである。
１．速い署名者（クロックが適正時間よりわずかに進んでいる）は、前のディスパッチの中間時点の後にタイムスタンプを生成しなければならない。
２．遅い署名者のタイムスタンプは、次のディスパッチの中間時点の前でなければならない。

理想的には、すべてのタイムスタンプが、公称時間ウィンドウ内からの時間値、すなわち、署名者が要求された後であるがディスパッチャによって受信される前の時間値を含むように、署名者のクロックを同期させる。中間時点まで分岐を可能にすることは、要件を多少緩和するものであるが、高保証環境においては、又はそのような緩和された処理が不要な場合には、禁止されることがある。

緩和された最悪の場合の保証があっても、異なるサイクルにおいて発行されたタイムスタンプは、単調であることが保証される。正確な同期は、異なる署名者によって同じサイクルにおいて発行されたタイムスタンプ間の相対的な順序付けを保証するために支払わなければならない代償である。しかしながら、すべてのアプリケーションの要求は個々に直列化されるので（同じサイクルにおける同じアプリケーションに対しては、複数のタイムスタンプは発行されない）、以前のタイムスタンプが処理された後でのみ新たなタイムスタンプを要求するアプリケーションのため、すべてのアプリケーション・チェイン内の時間は、構築によって一貫性のあるものとなる。

発行されたタイムスタンプは、連続して監視することができるので、「障害となっている」署名者（すなわち、大幅なクロック・ドリフトを伴う署名者）をオフラインにし、タイムスタンプ・サイクルを繰り返して、故障サイクルからのすべての要求を再発行することができる。オフラインになると、ドリフトする署名者のクロックを訂正することができる。

より一般には、サーバ１０は、署名要求を受信し（図６、ステップＳ１３）、これらを格納する。サーバは次いで、好ましくはタイミング制約に基づいて、例えば上述の量子化された時間間隔を用いて、要求をいつ署名者にディスパッチするか判断する。他のスキームを考えることができる。例えば、サーバが、署名のためにディスパッチする前に所与の要求数に達するのを待つという実施形態もある。タイミング制約を義務付けない、さらに他のスキームを考えることができる。

２．４．３ 組み合わされたタイムスタンプ及びハッシュ・チェイン
タイムスタンプと共に時間値及びチェイン情報の両方に依存する実施形態は、実時間と相対的な順序付け能力との両方を提供する。アプリケーションは、次いで、どちらの証拠を優先するかを選択することができる。しかし、状態チェインを通した相対的な順序付けのみが、否認防止の証拠を与える（従って、幾つかの実施形態にとって十分なものである）。

識別文書発行プリケーションのような、すべての署名が説明されなければならないシステムにおいては、相対的な順序付け及びタイムスタンプの削除／挿入に対する暗号保護（共に、本監査チェインによって与えられる）は、絶対的な時間値より重要である。

２．４．４ 署名者の利用
タイムスタンプのサイクル時間は最悪の場合の値の近くで選択することができるので、署名待ち時間が署名者間で概ね一様である場合には、署名者の利用を最大化することができる。

ホスト（ドライバ）も署名者の利用を監視する場合には、処理負荷を最適化するために、量子化によって、システムが採用することができる予測可能な利用パターンを生成することができる。

２．４．５ 署名者鍵のない同期
署名鍵の有限な選択は、証明の階層によって表わすことができ、アプリケーションは、適格な鍵のいずれか１つによって生成された鍵を検証することができるものと仮定する。この仮定が、タイムスタンプのインフラストラクチャ全体に対して保たれる場合には、システムは、複数のＨＳＭ間で鍵を同期することなく動作することができる。そのような環境においては、「保持された鍵」、すなわち、それを内部で生成したＨＳＭから決してなくなることのない署名鍵を、用いることができる。

単一のバックエンドの鍵がすべてのタイムスタンプを発行するシステムにおいては、通常の鍵クローニングの手順が要求される。これらの手順はここではこれ以上説明しないが、明確な時間量子化によってバックエンドを追加／削除するための利点がもたらされ、従って、システムには、鍵同期のいずれかの解決法が簡単に組み込まれる。

２．４．６ 状態ベースのチェックポイント動作
実施形態によるシステムは、暗号的に結合された状態の単一の組を通じて進化するため、状態は、常に、以前の動作を組み込む。従って、監査は、特定の状態が「既知の良好状態（ｋｎｏｗｎ ｇｏｏｄ）」であることを見出し、監査履歴の周期的なトリミングを可能にすることができる。システムが周期的な検査によって増強され、既知の良好状態が文書化された場合には、アーカイブ・ログを、大きさの点で結合することができる（タイムスタンプ計数）。

２．５ 既存システムとの比較、性能
以下では、他の安全なロギング・システムとの比較が行われる。

２．５．１ 鍵付き同期のない複数の署名者 対 鍵付き同期のある複数の署名者
特に秘密鍵動作についてのスケーラビリティ問題に対する典型的な解決法は、後で置き換え可能になる署名鍵のグループ間での明確な鍵同期である。安全な方法で複数の署名者間で鍵を移行することは、困難な課題である。本実施形態は、共有されるシステム状態を通して異なる署名者を結合することによって、複製に関連する問題のクラス全体に予め対処する。実際の設定においては、同じ制御認証機関４０によって署名者証明書を割り当て（図３を参照）、従って、アプリケーションに、最初に署名鍵を探すように要求することができる。しかしながら、同様な問題が、（新たなタイムスタンプ・サーバが追加されたときに）署名鍵の置き換えにおいても生じるため、ここでは単に、解決されたインスタンスに対して検証アプリケーションを示すだけでよい。

本質的には、実施形態は、同期された鍵の複数のインスタンスではなく、複数の独立した鍵を用いることによって、スケーリング能力を提供する。監査検証アプリケーションに与えられる唯一のオーバーヘッドは、以前の未知の署名者鍵に最初に遭遇したときの付加的な証明の構文解析／検証である。高保証環境においては、この付加的なステップ（キャッシュ可能でもある）は、署名者間で鍵を同期させるのに好ましい。実際には、多くの高保証の署名者環境は、寿命の長い鍵のエクスポートを禁止しており、実施形態は、依然として、これらのルールの下でスケーリング可能な解決法を提供する。

２．５．２ 署名鍵のロールオーバー
安全なタイムスタンピングの暗号研究は、署名鍵の暗号的に強力な進化（置き換え）を優先する傾向があるが、それは、このことが、個々の鍵の脆弱性ウィンドウを最小にするためである（非特許文献５）。しかしながら、固有の直列化のため、頻繁な鍵の進化はまた、多数のアプリケーションに対するスケーラビリティを制限する。このことは、単一の監査チェインのみを考慮する場合は問題ではない。しかしながら、このことは、エンタープライズ・サーバのような共有システムにおいては、深刻な性能のボトルネックをもたらす。

本実施形態は、鍵のロールオーバー問題を証明書ライフサイクルの管理、すなわちオフライン問題に変えることを可能にする秘密鍵署名を用いる。

２．５．３ 性能
秘密鍵署名の使用は、一般に、対称性をベースとした方法より効率が悪く、これは、所与の署名についてのスループットが低いことを意味する。実際には、ここでは、より多くの署名者を、同等のターゲット・スループットを得るように対応させることができる。

２．５．４ 複数のアプリケーション・チェインのネイティブな統合
現在用いられる監査機構は、システム全体に及ぶログに集中するか、又は、集約されたログを用いることなく、アプリケーション・イベントのチェインを独立のエンティティとして処理する傾向がある。複数のログを扱う能力に言及するときには、この能力は一般に、過去の全システム履歴のシステム全体に及ぶ集約ではなく、個別のイベント・ログの論理的なリンクを指す（非特許文献６、第９節）。

本例の場合には、本発明の実施形態は、無限数のアプリケーションレベルのログを統合するように設計される。

２．５．５ 公監査ログ
システムの実施形態は、制限のない監査のために設計されており、そのデータのほとんどすべてとすべての生成されたログとを安全なハードウェアの外部に格納するように設計されている（図３）。そのような手法は、データベース管理の問題でホストに負荷をかける一方で、署名者のハードウェアが保持する状態を最小にすることを可能にする。ＨＳＭ常駐ログに依存することは要求されていないため、本実施形態によるシステムは、安全な署名デバイスのリソースと比較するとホストのリソースは実質的に無制限なので、（原理的に）無制限にスケーリングすることができる。内部ログを義務付けることは、署名デバイスに対する瑣末なサービス妨害攻撃を引き起こすことに留意されたい［非特許文献３、５．１．１．３］。

公的に検証可能な監査チェインの場合には、ＭＡＣベースのスキームを用いることができず、従って、対称性をベースとするログ認証と比較すると、性能上の不利につながる。しかしながら、複数の署名者に対応できるため、必要に応じて署名者の性能をスケーリングすることができる。監査チェインが非対称的技術によって署名されたときには、システムによって提供される監査ログは、ＭＡＣベースの方法とは異なり、否認防止保証を伴って永遠に続くことがある［非特許文献４］。

小さい署名者の内部状態を格納することの重要な結果として、本署名者は、（異なるユーザの署名鍵の間における十分な分離を仮定すると）他のアプリケーションもホストすることができ、従って、本システムは、実施形態において、安全なコプロセッサの他のユーザと共存することができる。ホストの視点からは、わずかな未使用の能力を有するコプロセッサが、本署名者をホストすることができる。このことは、システムを多くの既存システムに対する漸進的な特徴として加えることを可能にする。

２．６ 技術的実装形態の詳細
最後に、図７は、本発明の態様を実装するのに適したコンピュータ化されたユニットの例示的な実施形態を示す。本明細書において説明される方法は、大部分がインタラクティブなものではなく、自動化されていることが理解されるであろう。例示的な実施形態においては、本明細書に記載される方法は、インタラクティブなシステム、部分的にインタラクティブなシステム、又は非インタラクティブなシステムのいずれにも実装することができる。本明細書に記載の方法は、ソフトウェア（例えばファームウェア）、ハードウェア、又はそれらの組合せとして実装することができる。例示的な実施形態においては、本明細書に記載の方法は、実行可能プログラムとしてソフトウェアで実装することができ、パーソナル・コンピュータ、ワークステーション、ミニコンピュータ、又はメインフレーム・コンピュータのような専用又は汎用のデジタル・コンピュータによって実行することができる。従って、システム１００は、汎用コンピュータ１０１を含む。

例示的な実施形態においては、図７に示されるようなハードウェア・アーキテクチャの観点から、コンピュータ１０１は、プロセッサ１０５と、メモリ・コントローラ１１５に結合されたメモリ１１０と、ローカル入力／出力（Ｉ／Ｏ）コントローラ１３５を介して通信可能に結合された１つ又は複数の入力／出力デバイス１４０、１４５（又は周辺装置）とを含む。入力／出力コントローラ１３５は、当該技術分野で公知のように、１つ又は複数のバス又はその他の有線若しくは無線の接続とすることができるが、それらに限定されない。入力／出力コントローラ１３５は、通信を可能にするために、コントローラ、バッファ（キャッシュ）、ドライバ、中継器、及び受信機といった追加の要素を有することもあるが、これらは、簡略化のために省略されている。さらに、ローカル・インターフェースは、上記の構成要素間の適切な通信を可能にするために、アドレス、コントロール、及び／又はデータの接続を含むこともできる。本明細書に記載されるように、Ｉ／Ｏデバイス１４０、１４５は、当該技術分野において公知の、いずれかの汎用暗号カード又はスマート・カードとすることができる。

プロセッサ１０５は、ソフトウェア、特にメモリ１１０に格納されたソフトウェアを実行するためのハードウェア・デバイスである。プロセッサ１０５は、カスタム・メード又は市販のいずれかのプロセッサ、中央処理ユニット（ＣＰＵ）、コンピュータ１０１に関連する幾つかのプロセッサのうちの補助プロセッサ、半導体ベースのマイクロプロセッサ（マイクロチップ又はチップセットの形態）、マクロプロセッサ、又はソフトウェア命令を実行する殆どすべてのデバイスとすることができる。

メモリ１１０として、揮発性メモリ素子（例えば、ランダム・アクセス・メモリ（ＤＲＡＭ、ＳＲＡＭ、ＳＤＲＡＭなどのＲＡＭ））及び不揮発性メモリ素子（例えば、ＲＯＭ、消去可能プログラム可能読取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読取り専用メモリ（ＥＥＰＲＯＭ）、プログラム可能読取り専用メモリ（ＰＲＯＭ）、テープ、コンパクト・ディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、ディスク、ディスケット、カートリッジ、カセットなど）のいずれか１つ又はこれらの組合せを挙げることができる。さらに、メモリ１１０は、電子的、磁気的、光学的、及び／又は他のタイプのストレージ媒体を組み込むことができる。メモリ１１０は、種々の構成要素が互いに遠隔に位置しているがプロセッサ１０５によってアクセスすることができる、分散型アーキテクチャを有することができることに留意されたい。

メモリ１１０内のソフトウェアは、１つ又は複数の別個のプログラムを含んでいてもよく、その各々は、論理関数を実装するための実行可能命令の順序付きリストを含む。図７の例において、メモリ１１０内のソフトウェアは、例示的な実施形態に従って本明細書に記載された方法と、適切なオペレーティング・システム（ＯＳ）１１１とを含む。ＯＳ１１１は、他のコンピュータ・プログラム、例えば本明細書に記載の方法の実行を実質的に制御し、スケジューリング、入出力制御、ファイル及びデータ管理、メモリ管理、並びに通信制御及び関連サービスを提供する。

本明細書に記載の方法は、ソース・プログラム、実行可能プログラム（オブジェクト・コード）、スクリプト、又は実行される命令のセットを含む他のいずれかのエンティティの形態とすることができる。ソース・プログラムの形態のときには、プログラムは、ＯＳ１１１と関連して適正に動作するように、コンパイラ、アセンブラ、インタープリタ等を介して翻訳される必要があり、これらは、メモリ１１０内に含まれていてもよく、含まれていなくてもよい。さらに、本方法は、データ及び方法のクラスを有するオブジェクト指向プログラミング言語として記述することもでき、ルーチン、サブルーチン、及び／又は関数を有する手続き型プログラミング言語として記述することもできる。

例示的な実施形態においては、従来のキーボート１５０及びマウス１５５を、入力／出力コントローラ１３５に結合することができる。Ｉ／Ｏデバイス１４０、１４５のような他の出力デバイスは、例えば、プリンタ、スキャナ、マイクロホンなどを含むがこれらに限定されない入力デバイスを含むことができる。最後に、Ｉ／Ｏデバイス１４０、１４５は、入力と出力の両方を通信するデバイス、例えば、限定されるものではないが、ネットワーク・インターフェース・カード（ＮＩＣ）又は変調器／復調器（他のファイル、デバイス、システム、又はネットワークにアクセスするためのもの）、無線周波数（ＲＦ）又はその他のトランシーバ、電話インターフェース、ブリッジ、ルータなどをさらに含むことができる。本明細書に記載されるように、Ｉ／Ｏデバイス１４０／１４５は、当該技術分野において公知のいずれかの汎用暗号カード又はスマート・カードとすることができる。システム１００はさらに、ディスプレイ１３０に結合されるディスプレイ・コントローラ１２５を含むことができる。例示的な実施形態においては、システム１００はさらに、ネットワーク１６５に結合するためのネットワーク・インターフェース１６０を含むことができる。ネットワーク１６５は、コンピュータ１０１と外部のいずれかのサーバ、クライアントなどとの間でブロードバンド接続を介して通信するための、ＩＰベースのネットワークとすることができる。ネットワーク１６５は、コンピュータ１０１と外部システムとの間でデータを送信及び受信する。例示的な実施形態においては、ネットワーク１６５は、サービス・プロバイダによって運営される管理されたＩＰネットワークとすることができる。ネットワーク１６５は、例えばＷｉＦｉ（登録商標）、ＷｉＭａｘ（登録商標）などのような無線プロトコル及び技術を用いて、無線方式で実装することができる。ネットワーク１６５は、ローカル・エリア・ネットワーク、広域ネットワーク、インターネット・ネットワーク、又は他のタイプのネットワーク環境のような、パケット交換ネットワークとすることもできる。ネットワーク１６５は、固定無線ネットワーク、無線ローカル・エリア・ネットワーク（ＬＡＮ）、無線広域ネットワーク（ＷＡＮ）、パーソナル・エリア・ネットワーク（ＰＡＮ）、仮想私設ネットワーク（ＶＰＮ）、インターネット又は他の適切なネットワークシステムとすることができ、信号を受信及び送信するための機器を含む。

コンピュータ１０１が、ＰＣ、ワークステーション、又はインテリジェント・デバイスなどの場合には、メモリ１１０内のソフトウェアは、基本入出力システム（ＢＩＯＳ）（簡略化のために省略）をさらに含むことができる。ＢＩＯＳは、コンピュータ１０１が起動されたときに実行することができるように、ＲＯＭに格納されている。

プロセッサ１０５は、コンピュータ１０１が動作しているときに、メモリ１１０内に格納されたソフトウェアを実行し、データをメモリ１１０との間で送受信し、ソフトウェアに従ってコンピュータ１０１の動作を一般に制御するように、構成されている。本明細書に記載の方法、及びＯＳ１１１は、全体又は一部が、プロセッサ１０５によって読み出され、場合によってはプロセッサ１０５内にバッファされ、その後実行される。

図７に示されるように、本明細書に記載のシステム及び方法がソフトウェアに実装されるときには、本方法は、いずれかのコンピュータ関連システム若しくは方法によって又はそれらに関連して用いるために、ストレージ１２０のようないずれかのコンピュータ可読媒体上に格納することができる。

当業者であればわかるように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又は、本明細書においてすべて一般的に「回路」、「モジュール」若しくは「システム」と呼ばれるソフトウェア及びハードウェア態様を組み合わせる実施形態の形式を取ることができる。さらに、本発明の態様は、具体化されたコンピュータ可読プログラム・コードを有する１つ又は複数のコンピュータ可読媒体として具体化された、コンピュータ・プログラム製品の形式を取ることができる。

１つ又は複数のコンピュータ可読媒体のいずれかの組み合わせを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体とすることができる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学、電磁気、赤外線若しくは半導体のシステム、装置、若しくはデバイス、又はこれらの任意の適切な組み合わせとすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、以下のもの、すなわち、１つ又は複数の配線を有する電気的接続、携帯可能コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、携帯可能コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、又はこれらの任意の適切な組み合わせを含む。本文書の文脈においては、コンピュータ可読記憶媒体は、命令実行システム、装置若しくはデバイスによって又はこれらとの関連で用いられるプログラムを含むか又は記憶することができるいずれかの有形媒体とすることができる。

コンピュータ可読信号媒体は、ベースバンドにおいて又は搬送波の一部として、コンピュータ可読プログラム・コードが具体化された伝搬データ信号を含むことができる。こうした伝搬信号は、電磁気、光又はこれらのいずれかの適切な組み合わせを含むがこれらに限定されない、様々な形式のいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置若しくはデバイスによって又はこれらとの関連で用いられるプログラムを通信し、伝搬し、又は搬送することができる、いずれかのコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に具体化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦ等、又はこれらのいずれかの適切な組み合わせを含むがこれらに限定されない、いずれかの適切な媒体を用いて、送信することができる。

本発明の態様についての動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラム言語及び「Ｃ」プログラム言語又は同様のプログラム言語といった従来の手続き型プログラミング言語を含む、１つ又は複数のプログラム言語のいずれかの組み合わせで、記述することができる。プログラム・コードは、全体をユーザのコンピュータ上で実行するか、一部をユーザのコンピュータ上で実行するか、独立型ソフトウェア・パッケージとして実行するか、一部をユーザのコンピュータ上で実行し一部をリモート・コンピュータ上で実行するか、又は、全体をリモート・コンピュータ若しくはサーバ上で実行することができる。後者のシナリオにおいては、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通してユーザのコンピュータに接続することができ、又は、（例えば、インターネット・サービス・プロバイダを用いてインターネットを通して）外部コンピュータに接続することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して、上述された。フローチャート図及び／又はブロック図の各ブロックは、コンピュータ・プログラム命令によって実装できることが理解されるであろう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えられてマシンを生成し、コンピュータ又は他のプログラム可能データ処理装置のプロセッサを介して実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて特定される機能／動作を実装するための手段を生成するようにすることができる。

コンピュータ、他のプログラム可能データ処理装置又は他の装置に一連の動作ステップを実施させるように、コンピュータ・プログラム命令をコンピュータ、他のプログラム可能データ処理装置又は他の装置にロードして、コンピュータ実装プロセスを生成し、コンピュータ又は他のプログラム可能データ処理装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて特定される機能／動作を実装するためのプロセスを提供するようにすることができる。

図面におけるフローチャート及びブロック図は、本発明の様々な実施形態によるシステム、方法及びコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能及び動作を示す。この点において、フローチャート又はブロック図の各ブロックは、１つ又は複数の特定の論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すものとすることができる。また、いくつかの代替的な実装形態においては、ブロックに記された機能は、当該図に記された順序以外の順序で行われる場合があることに留意されたい。例えば、関連する機能に応じて、連続して示された２つのブロックが、実際には、実質的に同時に実行される場合があり、又は、ブロックが逆順で実行される場合もある。また、ブロック図及び／又はフローチャート図の各ブロック、及び、ブロック図及び／又はフローチャート図におけるブロックの組み合わせは、特定の機能又は動作を行う専用ハードウェアベースのシステムによって、又は、専用ハードウェアとコンピュータ命令との組み合わせによって、実装することができる。

特定の実施形態を参照しながら、本発明を説明したが、当業者であれば、本発明の範囲から逸脱することなく、様々な変更を行なうことができ、均等物によって代替できることを理解されたい。さらに、その範囲から逸脱することなく、特定の状況を本発明の教示に適合させるように多くの修正を行うことができる。従って、本発明は、開示された特定の実施形態に限定されるものではなく、特許請求の範囲に入るすべての実施形態を包含することが意図される。例えば、時間の制約又は受信した要求の臨界数に基づいて、種々のディスパッチ・スキームに頼ることができる。また、更新されたシステム状態、スカラー、ベクトル、マトリクス等について、種々の構造を想定することができる。さらに、関数「ｆ」は更新された状態の計算に関するものに対して言及されるが、特定の関数には明示的には依拠しないが、例えば、一連のステップ等に依拠する更新されたシステム状態を達成するために、そのアルゴリズムを用いることができることが明らかである。

１：コンピュータ化されたシステム
１０：サーバ
１５：システム状態のチェイン
２０：署名エンティティの組
３０：アプリケーションの組
３５：アプリケーション状態のチェイン
４０：認証機関
５０：署名者証明書
２１０、２２０：許容ウィンドウ
２３０：公称タイムスタンプ・ウィンドウ
２４０：全サイクル

Claims (14)

1. 複数のアプリケーションと通信するサーバを含むコンピュータ化されたシステムに実装される、デジタル署名の監査を可能にするための方法であって、前記サーバが、
   前記複数のアプリケーションの１つ又は複数によって発行された１つ又は複数の署名要求を受信するステップと、
   前記受信した署名要求に対応する第１のデータを、１つ又は複数の署名エンティティに転送するステップであって、前記第１のデータの前記転送に応じて、前記転送された第１のデータに対応する応答が前記署名エンティティによって当該サーバに戻される、前記転送するステップと、
   ｉ）基準システム状態とｉｉ）前記受信した署名要求に対応する第２のデータとの関数を用いて計算された更新システム状態を格納するステップであって、前記第２のデータは、前記受信した応答におけるデータに対応する第３のデータを含み、前記基準システム状態及び前記更新システム状態は前記署名要求を証明するものであり、前記更新システム状態は、以前の基準システム状態と、少なくとも２つの別個のアプリケーションから受信した署名要求に対応する第２のデータとの関数を用いて計算される、前記格納するステップと、
   前記更新システム状態を新たな基準システム状態として用いて、前記受信するステップ、前記転送するステップ、及び前記格納するステップを繰り返すステップと
   を実行することを含む、前記方法。
2. 前記サーバが、
   前記第１のデータの転送に応答して、前記署名エンティティから応答を受信するステップ
   をさらに実行することを含む、請求項１に記載の方法。
3. 前記転送された第１のデータは、要求側アプリケーション１つ毎に最大で１つの署名要求を保持する、請求項２に記載の方法。
4. 前記格納するステップは、
   前記第２のデータを前記基準システム状態と前記更新システム状態とを含むシステム状態のシーケンスに集約することによって得られる集約データの組を格納するステップ
   を含み、
   前記集約することは、前記第２のデータをシステム状態の前記シーケンスにインターレースすることをさらに含む、
   請求項１に記載の方法。
5. 前記転送するステップは、
   前記サーバにおいて受信したそれぞれの署名要求に各々が対応する第１のデータのサブセットの組を、それぞれの署名エンティティにディスパッチするステップ
   を含む、請求項１〜４のいずれか１項に記載の方法。
6. いつディスパッチするかが、好ましくは量子化された時間間隔を用いて、タイミング制約に基づいて前記サーバにおいて判断される、請求項５に記載の方法。
7. 以前に転送された第１のデータが前記１つ又は複数の署名エンティティにおいて署名されている間、前記対応する第１のデータを転送する前に、前記受信した１つ又は複数の署名要求を遅延させること
   をさらに含む、請求項６に記載の方法。
8. 前記格納することは、前記第２のデータを前記基準システム状態と前記更新システム状態とを含むシステム状態のシーケンスに集約することによって得られる集約データの組を格納することを含み、
   前記サーバが、
   前記複数のアプリケーションの１つからクエリを受信するステップと、
   前記集約データの組に基づいて、前記アプリケーションの前記１つに応答するステップと
   をさらに実行することを含む、請求項１〜７のいずれか１項に記載の方法。
9. 前記サーバが、
   前記第１のデータを転送することに応答して、前記署名エンティティから応答を受信するステップ
   をさらに実行することを含み、前記応答は信頼できる時間データを含む、
   請求項１〜８のいずれか１項に記載の方法。
10. 前記署名エンティティはハードウェア・セキュリティ・モジュールである、請求項１〜９のいずれか１項に記載の方法。
11. 前記基準システム状態及び前記更新システム状態に基づいて、前記署名要求又は、前記アプリケーションのアクティビティ又はイベントを示し、前記サーバによって署名要求として解釈される関連データを監査することをさらに含む、請求項１〜１０のいずれか１項に記載の方法。
12. 前記関数は非可逆関数である、請求項１〜１１のいずれか１項に記載の方法。
13. 複数のアプリケーション及び１つ又は複数の署名エンティティと通信するように適合されたサーバを含み、前記サーバは請求項１〜９のいずれか１項に記載の方法の各ステップを実装するように構成された、コンピュータ化されたシステム。
14. 複数のアプリケーションと通信するサーバを含むコンピュータ化されたシステムにおいて、前記サーバに、請求項１〜９のいずれか１項に記載の方法の各ステップを実行させる、コンピュータ・プログラム。

Images