(57)【要約】【課題】効率的な態様で、進行中のハッシュが維持され、かつ絶え間なく更新されるようにファイルの内容をハッシュする新規な方法を提供する。【解決手段】２つの関数のうち第１の関数は、同じ結果にハッシュする２つのデータ値を見つけることが計算上不可能であるような、一方向ハッシュ関数「Ｈ」である。第２の関数は、可換的かつ連想的関数「Ｆ」との逆関数「Ｆｉｎｖ」であり、合計ハッシュおよび更新された記録のハッシュを結合する。これらのハッシュは、関数「Ｆ」を用いて結合され、それによって、各記録が、その逆関数である「Ｆｉｎｖ」を用いて抽出される。このようにして、各記録が合計ハッシュから抽出され、更新される。更新の度に、計算されたファイルハッシュは、有効なユーザのみによって知られている鍵によって暗号化された後書き込まれる。【選択図】図１
2006092574.tif 000002
【特許請求の範囲】
【請求項１】
関連するデータ処理システムによって修正される当該データ処理システムの記憶手段に記憶された複数の個別データユニットの集合体を保護するための方法であって、
前記データ処理システムのハッシュ処理手段が、記憶手段に記憶された保護すべきデータユニットの少なくともデータ値部分を用いてハッシュ処理を行うことによって、各個別データユニットのハッシュ値を取得するステップと、
前記データ処理システムの演算手段が、各個別ハッシュ値を個々に包含および削除することを許可する関数を用いて、前記ハッシュ処理手段が取得したデータの各個別データユニットのハッシュ値を合計して合計ハッシュ値を取得するステップとを備え、さらに
個別データユニットを加算、更新、または削除するとき、前記ハッシュ処理手段が当該加算、更新、または削除する個別データユニットのハッシュ値を取得するステップと、
前記合計ハッシュ値、前記加算、更新、または削除する個別データユニットのハッシュ値、および前記関数の逆関数を用いて、前記演算手段が個別データユニットを加算、更新、または削除した後の新たな合計ハッシュ値を取得するステップとを備える、保護方法。
【請求項２】
前記個別データユニットのハッシュ値を取得するステップは、前記データ処理システムが個別データユニットを削除するとき、当該削除する個別データユニットの個別のハッシュ値を前記関数の逆関数を用いて前記合計ハッシュ値から削除するステップをさらに含む、請求項１に記載の保護方法。
【請求項３】
各データユニットのためにハッシュされるべきデータの一部として、各データユニットの相対命令を他のデータユニットと区別する標識を含めて記憶手段に記憶するステップをさらに含む、請求項１に記載の保護方法。
【請求項４】
前記個別データユニットのハッシュ値を取得するステップは、
前記データ処理システムの更新手段が記憶手段に記憶された前記個別データユニットの一つを更新するステップと、
前記更新するステップに対応して、前記関数および当該関数の逆関数を用いて前記演算手段が前記合計ハッシュに対して処理を行うステップとを含む、請求項１に記載の保護方法。
【請求項５】
記憶手段に記憶された前記標識は、複数の連続命令データユニット番号である、請求項３に記載の保護方法。
【請求項６】
記憶手段に記憶された前記標識は、前記個別データユニットに関連的に索引を付けるために用いられるキー値である、請求項３に記載の保護方法。
【請求項７】
記憶手段に記憶された前記個別データユニットが記録である、請求項１に記載の保護方法。
【請求項８】
データ処理システムが更新中に中断された場合に、当該データ処理システムのデータ生成手段が生成するデータ構造を、用いられるデータユニットに関連する情報を含む前記個別データユニットの少なくとも一つと関連付けるステップをさらに含む、請求項１に記載の保護方法。
【請求項９】
記憶手段に記憶された前記個別データユニットがバイトである、請求項１に記載の保護方法。
【請求項１０】
記憶手段に記憶された前記個別データユニットがセクタである、請求項１に記載の保護方法。
【請求項１１】
前記データ処理システムの更新手段が遂行されるべき更新処理を識別するために用いられる前記データ構造に含まれるフィールドを前記データ生成手段が提供するステップをさらに含む、請求項８に記載の保護方法。
【請求項１２】
前記データ処理システムの更新手段が合計ハッシュ値の修正バージョンを識別するために用いられる前記データ構造に含まれるフィールドを前記データ生成手段が提供するステップをさらに含む、請求項８に記載の保護方法。
【請求項１３】
前記データ処理システムの更新手段が前記データ構造のフィールドのハッシュを格納するために用いられる前記データ構造に含まれるフィールドを前記データ生成手段が提供するステップをさらに含む、請求項８に記載の保護方法。
【請求項１４】
前記データ処理システムの暗号化手段が前記データ構造の少なくとも一部を暗号化するステップをさらに含む、請求項８に記載の保護方法。
【請求項１５】
前記演算手段が、記憶手段に前記合計ハッシュ値を、記憶するステップをさらに含む、請求項１に記載の保護方法。
【請求項１６】
前記演算手段が、前記合計ハッシュ値を権限を有するユーザ以外の者には修正が不可能であるように記憶手段に格納するステップをさらに含む、請求項１に記載の保護方法。
【請求項１７】
前記演算手段が用いる前記関数が排他的論理和処理である、請求項１に記載の保護方法。
【請求項１８】
前記演算手段が用いる前記関数が加算処理である、請求項１に記載の保護方法。
【請求項１９】
データ処理システムによって修正される当該データ処理システムの記憶手段に記憶されたデータ集合体を保護するための方法であって、
前記データ処理システムのハッシュ処理手段が、記憶手段に記憶された第１のデータグループと、前記第１のデータグループを識別する標識とに対して、所定のハッシュ処理を行って第１のハッシュ値を取得するステップと、
前記ハッシュ処理手段が、記憶手段に記憶された第２のデータグループと、前記第２のデータグループを識別する標識とに対して、所定のハッシュ処理を行って第２のハッシュ値を取得するステップと、
前記データ処理システムの演算手段が、関数を用いて合計ハッシュを決定するためにハッシュを結合し、それによって、前記第１のデータグループの前記ハッシュと、前記第２のデータグループの前記ハッシュとが、前記関数の逆関数を用いて合計ハッシュから引き続いて抽出されうるステップとを備える、保護方法。
【請求項２０】
前記データ処理システムの更新手段が、記憶手段に記憶された前記データグループの一つを更新するステップと、
前記演算手段が、前記更新するステップに対応して前記関数の逆関数を用いて、前記合計ハッシュに対して処理を行うステップとを含む、請求項１９に記載の保護方法。
【請求項２１】
前記ハッシュ値を取得するステップで、前記ハッシュ処理手段が前記第１のデータグループを識別する標識と、前記第２のデータグループを識別する標識とを用いる、請求項１９に記載の保護方法。
【請求項２２】
記憶手段に記憶される前記第１のデータグループおよび前記第２のデータグループが記録である、請求項１９に記載の保護方法。
【請求項２３】
前記データ処理システムのデータ生成手段が生成するデータ構造を前記第１のデータグループおよび前記第２のデータグループの少なくとも一つに関連付けるステップをさらに含み、
前記データ構造は、更新中にデータ処理システムが中断された場合に用いられる各グループに関する情報を含む、請求項１９に記載の保護方法。
【請求項２４】
前記データ処理システムの更新手段が遂行されるべき更新処理を識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項２３に記載の保護方法。
【請求項２５】
前記データ処理システムの更新手段が合計ハッシュの修正バージョンを識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項２３に記載の保護方法。
【請求項２６】
前記データ処理システムの更新手段が前記データ構造のフィールドのハッシュを格納するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項２３に記載の保護方法。
【請求項２７】
前記データ処理システムの暗号化手段が前記データ構造の少なくとも一部を暗号化するステップをさらに含む、請求項２３に記載の保護方法。
【請求項２８】
前記演算手段が前記合計ハッシュ値を権限を有するユーザ以外の者には修正が不可能であるように記憶手段に格納するステップをさらに含む、請求項１９に記載の保護方法。
【請求項２９】
前記演算手段が用いる前記関数が排他的論理和処理である、請求項１９に記載の保護方法。
【請求項３０】
前記演算手段が用いる前記関数が加算処理である、請求項１９に記載の保護方法。
【請求項３１】
複数のデータ記録を含み、関連ファイルハッシュを有する更新可能なデータファイルの有効性標識をデータ処理システムの記憶手段に保持するための方法であって、
前記データ処理システムのアクセス手段が記憶手段に格納された前記ファイルハッシュにアクセスするステップと、
前記データ処理システムの更新手段が前記複数のデータ記録の一つを更新して、更新データ記録を生成するステップと、
前記データ処理システムのハッシュ処理手段が、前記更新データ記録のハッシュ値を取得するステップと、
前記更新データ記録を用いて、前記データ処理システムの演算手段が可換的かつ連想的プロパティを有する関数と前記関連ファイルハッシュと更新データ記録のハッシュ値とを適用することによって、新たな関連ファイルハッシュを取得するステップとを備える、保持方法。
【請求項３２】
前記データ処理システムのデータ生成手段が生成するデータ構造を前記複数のデータ記録の少なくとも一つに関連付け、
前記データ構造は、更新中に前記データ処理システムが中断された場合に用いられる前記一つのデータ記録に関する情報を含む、請求項３１に記載の保持方法。
【請求項３３】
前記更新手段が前記複数のデータ記録の一つに対して遂行されるべき更新処理を識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項３２記載の保持方法。
【請求項３４】
前記更新手段が前記関連ファイルハッシュの修正バージョンを識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項３２に記載の保持方法。
【請求項３５】
前記更新手段が前記データ構造のフィールドのハッシュを格納するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項３４に記載の保持方法。
【請求項３６】
前記データ生成手段が前記データ構造の少なくとも一部を暗号化するステップをさらに含む、請求項３２に記載の保持方法。
【請求項３７】
前記演算手段が前記新たな関連ファイルハッシュを記憶手段に格納するステップをさらに含む、請求項３１に記載の保持方法。
【請求項３８】
前記演算手段が前記新たな関連ファイルハッシュを権限を有するユーザ以外の者には修正が不可能であるように記憶手段に格納するステップをさらに含む、請求項３１に記載の保持方法。
【請求項３９】
前記演算手段が用いる前記関数が排他的論理和処理である、請求項３１に記載の保持方法。
【請求項４０】
前記演算手段が用いる前記関数が加算処理である、請求項３１に記載の保持方法。
【請求項４１】
データ処理システムの記憶手段に記憶された複数のディジタルデータ記録を保護するための方法であって、
前記複数のディジタルデータ記録それぞれに対して、前記データ処理システムのデータ結合手段が合計データストリングを決定するために前記ディジタルデータ記録それぞれの情報内容を記録識別子と結合するステップと、
前記データ処理システムのハッシュ処理手段が、ハッシュ値を決定するために、前記複数のディジタルデータ記録の前記合計データストリングそれぞれに対してハッシュ処理を行うステップと、
前記データ処理システムの演算手段が、可換的かつ連想的プロパティを有する関数を用いて、前記複数のハッシュ値を合計して合計ハッシュ値を取得するステップとを備え、
合計データストリングを加算、更新、または削除するとき、前記ハッシュ処理手段が当該加算、更新、または削除する合計データストリングのハッシュ値を取得するステップと、
前記合計ハッシュ値、前記加算、更新、または削除する合計データストリングのハッシュ値、および前記関数を用いて、前記演算手段が合計データストリングを加算、更新、または削除した後の新たな合計ハッシュ値を取得するステップとを備える、保護方法。
【請求項４２】
前記データ処理システムのデータ生成手段が生成するデータ構造を、更新中にデータ処理システムが中断された場合に用いられる複数の合計データストリングの少なくとも一つに関連づけるステップをさらに含む、請求項４１に記載の保護方法。
【請求項４３】
前記データ処理システムの更新手段が前記データ記録に対して遂行されるべき更新処理を識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項４２に記載の保護方法。
【請求項４４】
前記データ処理システムの更新手段が合計ハッシュの修正バージョンを識別するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項４２に記載の保護方法。
【請求項４５】
前記更新手段が前記データ構造のフィールドのハッシュを格納するためのフィールドを前記データ生成手段が前記データ構造に提供するステップをさらに含む、請求項４４に記載の保護方法。
【請求項４６】
前記データ処理システムの暗号化手段が前記データ構造の少なくとも一部を暗号化するステップをさらに含む、請求項４２に記載の保護方法。
【請求項４７】
前記演算手段が、記憶手段に前記合計ハッシュを格納するステップをさらに含む、請求項４４に記載の保護方法。
【請求項４８】
前記演算手段が、前記合計ハッシュを、権限を有するユーザ以外の者には修正が不可能であるように記憶手段に格納するステップをさらに含む、請求項４４に記載の保護方法。
【請求項４９】
前記演算手段が用いる前記関数が排他的論理和処理である、請求項４１に記載の保護方法。
【請求項５０】
前記演算手段が用いる前記関数が加算処理である、請求項４１に記載の保護方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概略的にはコンピュータデータの機密保護に関する。より特定的には、定期的に更新されるファイルのハッシュを発生させるための方法に関する。
【背景技術】
【０００２】
特に、電子的なビジネス取引の出現に伴って、ワークステーションデータ（ラップトップコンピュータ、メインフレーム端末、独立のＰＣまたはあらゆるタイプのコンピュータネットワークワークステーションによって発生されるデータ）の機密性および完全性を確保することが大変重要になっている。例えば、多くのラップトップコンピュータユーザは、データの機密性を確保するために、全てのハードドライブデータを暗号化している。暗号化は、不所望な露見からデータを隠す。
【０００３】
本来、暗号化それ自身は、データの完全性を確保しない。例えば、暗号化は、コンピュータを内密にアクセスできる不正者が、特別の破壊プログラムを実行するのを防ぐことができず、この破壊プログラムは、暗号化されたデータの個々の意味を理解することはできないが、暗号化されたデータを、他の恐らくランダムな情報でランダムに上書きすることによって、他の処理への入力のためにデータが最終的に解読されるときに、誤った分析結果を生じさせるであろう。
【０００４】
暗号化プロトコル、損傷したファイルの形式およびいかにして損傷したかによっては、データの改変は検出されなくなり、データが適切な所有者によって処理される際に、誤った結果を導く可能性がある。例えば、損傷したデータが２進数のデータを含んでいる場合、このことは特に容易に生じる。所有者は、間違った結果によって誤った動作に導かれるであろう。
【０００５】
ファイルの完全性は、ファイルの内容に対して単方向ハッシュを採用することによって（例えば、ＭＤ５または機密ハッシュアルゴリズムＳＨＡを用いることによって）保護できることが良く知られている。予め記憶されたハッシュ値を用いて、新しく計算されたハッシュ値を実行かつチェックすることにより、正しいファイルの完全性は、故意の改変処理の恐れ（または、偶然の外部からの変更でさえも）が検出できることを保証し、それによって最終結果の信頼性および機密性が改善される。ファイルハッシュが自身の完全性を保護する方法で格納されている場合、ファイルハッシュは、全てのファイルが損傷を受けていないことまたは故意に改変されていないことを保証するために用いることができる。
【０００６】
ファイルが連続的に処理される場合、そのようなハッシュは計算できる。ファイルが連続的に構築されたとき（または連続的に構築されるに従って）、ハッシュは計算でき、ファイルが使用される度に再度チェックできる。ユーザのみが知っている鍵によって暗号化されることにより、またはユーザによって信用できる方法でディジタル署名されることにより、または信頼性のあるトークン装置に記憶されることにより、ハッシュ値が改変から保護されている場合、ファイルのいかなる部分を変更しても異なるハッシュ値の再計算を生じるので、ユーザは、ファイルが改変されていないことを信用することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
既存の技術は、全てのファイルがハッシュ値を計算または再計算するために連続的に処理されることを要求する。これらの技術は、たとえ非現実的でないとしても、頻繁に更新されたり、「ランダムに」処理されるファイルにとっては、扱いにくいものである。
【０００８】
従来の完全性検査処理は、ファイルが最初にアクセスされたときにハッシュを確認し、ファイルを変更し、その後全ての変更が適用された後に修正されたファイルのハッシュを再計算することから成る。この従来の処理は、ある種のアプリケーション、例えば長時間実行し続けるアプリケーション、またはファイルが頻繁に変更されるアプリケーション、または絶えずファイルが使用状態にあるアプリケーション、または更新されたファイルが保管されて新規のハッシュが再計算され記憶された最終結果にプログラムが到達する前に、ファイルを更新する特定のプログラムまたはコンピュータシステムが中断されるような（例えばコンピュータが停止されるような）危険性があるアプリケーションにはあまり適していない。なぜなら、更新が起こる度に全てのファイルのためのハッシュを再計算することは、通常、非現実的だからである。そのような計算を行わないと、明らかにファイルは、最初の更新時から最終ハッシュが再計算されるまでの間、明らかに改変状態に置かれる。
【０００９】
そのような実用上の問題は、従来のハッシュ技術を、ある種のファイルに適用するときに生じる。索引データベースのようなファイルは、「ランダムに」更新され（すなわち記録の部分集合のみが非連続的命令で更新され）、かつ長期間にわたって更新される。当該ファイルは、数分、数時間、または（メインフレームまたは「サーバ」の場合は）数日にわたって絶え間なく更新されるであろう。
【００１０】
ハッシュが全てのファイルに対して計算され、かつファイルが頻繁に更新される場合には、ファイルが変更される度に全てのファイルに対して修正されたハッシュを計算することは、許容し得ないようなオーバーヘッドを生じる。また、ハッシュが全てのファイルに対して計算され、かつファイルが頻繁に更新される場合には、修正されたファイルハッシュの計算をファイルがクローズされるまで（または、プログラムが終了するまで）遅らせると、最初の更新時と最終のハッシュの再計算との間、明らかな誤り状態にファイルがさらされることになる。システムまたは他のプログラムが早く終了した場合、ファイルは、この明らかな状態にさらされる。
【００１１】
ハッシュが各記録について保持されるならば、追加の記録スペースが必要となり、この記録スペースは、ファイルまたはその記録の配置に影響を与える可能性がある。通常、各記録のハッシュは、各記録の端から少し離れて設けられた場所に格納される。そのようなファイル配置の変更は、幾つかのアプリケーションでは許容されるかもしれないが、このような対処は、各記録について追加の記憶域が必要となるといった種々の欠点を招く。
【００１２】
記録毎にのみハッシュを保持することの他の欠点は、不正者が更新前のデータベースを複製し（たとえ、データベースが暗号化されていたとしても）、かつそのような更新前の記録を分離できることである。「ランダムに」更新されるべく設計されたようなデータベースは、記録単位で暗号化されなければならないが、記録の境界にまたがる暗号連鎖によって、ランダム更新は不可能となる。そこで、不正者は、手探り状態で、これらの更新前の記録をデータベースの現在稼働中のコピーに対応する記録に置換する可能性があり（これは、たとえ不正者が記録の実際の内容をよく知らず、混乱を起こすことだけを望んでいる場合でも可能である）、それによって、自動的に検出することが不可能な方法でデータベースの完全性を損なう。
【００１３】
本発明は、効率的な態様で、進行中のハッシュが維持され、かつ絶え間なく更新されるようにファイルの内容をハッシュする新規な方法に向けられている。データベースの完全性は、繰り返し全ファイルを再処理するという不適当で過度な追加のオーバーヘッドを導入することなく、またファイルを長期間（例えば、長時間のリアルタイムプログラムが実行されている期間）明らかに改変される状態に置くことなく、維持されうる。
【課題を解決するための手段】
【００１４】
本発明は、各ファイルについての他の情報と共に、各ファイルのための少量の追加の記憶容量を必要とするだけであり、当該追加の記憶容量は、システムのディレクトリにおいて、または特別の補助の（可能ならば暗号化された）ファイルにおいて容易に確保できる。本発明は、基本的なファイルフォーマットおよび構造をそれぞれ変更しなくてもよく、従って、既存のプログラムを変更することなしに、ファイル処理の一部として、可能な限り「システム」レベルまたはそれに近いレベルで完全性を「簡単に」提供する。これにより、通常の操作へ付加する簡単なサービスとして、（特定のアプリケーションとは無関係に）この追加の完全性サービスを提供しようとするシステム間の互換性における困難性が克服される。
【００１５】
本発明の方法により、機密性の確保されていない計算システムが高度の機密性を有する電子金融取引を安全に遂行することができる。本明細書において後に詳細に説明されるように、本発明により、ファイルのハッシュが増分ベースで取られることができる。これにより、ファイルのどの部分でも変更が可能であるとともに、修正されたファイル部分および以前の合計ハッシュに基づいて新規の合計ハッシュを計算することができる。本発明に従えば、合計ハッシュは、各記録の修正に伴って即座に更新することができ、従来技術に従って全ファイルのハッシュを再計算する必要がない。
【００１６】
実施例は、２つの関数を用いてこれらの目的を達成する。第１の関数は、同じ結果にハッシュする２つのデータ値を見つけることが計算上不可能であるような、効果的な一方向ハッシュ関数「Ｈ」である。そのような関数の例には、周知のＭＤ５およびＳＨＡアルゴリズムが含まれる。第２の関数は、可換的かつ連想的関数「Ｆ」（およびその逆関数「Ｆｉｎｖ」）であり、合計ハッシュおよび更新された記録のハッシュを結合するための機構を提供する。後者の関数の例には、排他的論理和（「ＸＯＲ」）および算術加算が含まれる。
【００１７】
本方法は、各ファイル記録のハッシュと、記録識別（すなわち記録番号または鍵）のハッシュとを結合することを含む。これらのハッシュは、関数（「Ｆ」）を用いて結合され、それによって、各記録が、その逆関数である「Ｆｉｎｖ」を用いて抽出される。このようにして、各記録が合計ハッシュから抽出され、更新される。更新の度に、本発明に従って計算されたようなファイルハッシュは、好ましくは、有効なユーザのみによって知られている鍵によって暗号化された後、または有効なユーザによってディジタル的に署名された場合、または変更阻止記憶装置に保持された場合に書き込まれる。各記録は、そのデータ内容とともに、ハッシュされた識別によって表される。全てのそのような記録は合計されて、高度な機密完全性チェックを提供する。この合計ハッシュは、全データベースを反映し、いかなるデータ記録の変更（または再配列）であっても、ハッシュ計算において記録識別子（すなわち記録番号）を用いることによって明らかになる。これは、ハッシュ計算が、合計ハッシュ（例えば合計）に影響を与えるからである。この方法を用いることで、ユーザは、騙されて誤ったデータを用いた処理を行うことがなくなる。
【００１８】
本発明は、少なくとも、従来の欠点、つまり、各ファイル変更のために大量の再計算が行われること、アプリケーションまたはシステムが突然に終了した場合にファイルが「無効」とみなされる危険な状態に長期間置かれること、各記録のハッシュ（または、ＭＡＣ）のために追加の記憶容量を必要とすることおよび不正者が失効した記録を代替することができることをうまく解消する。これは、全ファイルの完全性および全記録の相互関係が、各ファイルの更新が実行されたときに変更される単一ファイルハッシュ値内に保護されたままになる。
【００１９】
本発明の上記特徴およびその他の特徴は、付随する図面と共に行われる本発明の好ましい実施例の以下の記述を読むことによって、より良く理解されであろう。
【発明の効果】
【００２０】
本発明によれば、機密性の確保されていない計算システムが高度の機密性を有する電子金融取引を安全に遂行することができる。本明細書において後に詳細に説明されるように、本発明により、ファイルのハッシュが増分ベースで取られることができる。これにより、ファイルのどの部分でも変更が可能であるとともに、修正されたファイル部分および以前の合計ハッシュに基づいて新規の合計ハッシュを計算することができる。本発明に従えば、合計ハッシュは、各記録の修正に伴って即座に更新することができ、従来技術に従って全ファイルのハッシュを再計算する必要がない。
【発明を実施するための最良の形態】
【００２１】
図１は、典型的なコンピュータシステムを示すブロック図であって、電子商業コンピュータネットワークの一部として本発明が用いられる場合を示す。本発明は、そのような通信ネットワーク環境において用いられるが、同様に、データの機密性が重視されるラップトップコンピュータ，独立ＰＣ，メインフレームコンピュータまたは他のコンピュータシステムに関連して用いられる。
【００２２】
図１に示すシステムは、ターミナルＡ，Ｂ，…Ｎ間の通信が機密性の確保されていない通信チャネル１２を用いて行われるような典型的なコンピュータネットワークを含む。通信チャネル１２は、例えば、電話線であってもよい。ターミナルＡ，Ｂ〜Ｎは、単なる一例として、従来のキーボード／ＣＲＴ４に連結された（メインメモリを有する）プロセッサ２を備えたＩＢＭ  ＰＣであってもよい。各ターミナルＡ，Ｂ〜Ｎは、従来のＩＢＭ  ＰＣ通信ボード（図示せず）を含み、この通信ボードは、それぞれが従来のモデム６，８，１０に接続されたときに、ターミナルにメッセージの送受信を許容する。各ターミナルは、コンピュータにデータベース情報の読み出し、書き込みおよび記憶を許容するような、従来のＩＢＭ  ＰＣディスク記憶装置を含む。
【００２３】
各ターミナルは、普通テキストまたは暗号化されていないメッセージを生成し、署名処理が要求されるものなら何でも署名を行うことが可能であり、通信チャネル１２（または、通信チャネル１２に接続されうる図示しない通信ネットワーク）に接続された他のターミナルのいずれかにメッセージを送信することが可能である。さらに、ターミナルＡ，Ｂ〜Ｎは、各メッセージについての署名の検証を行うことが可能である。
【００２４】
各ターミナルユーザは、公開暗号化鍵および関連する個人の秘密解読鍵を有している。図１に示す公開鍵暗号化システムにおいて、各ターミナルユーザは、他のターミナルユーザがメッセージを暗号化するために用いる一般的な暗号化方法を知っている。さらに、各ターミナルユーザは、どのような暗号化鍵を用いてターミナルの暗号化処理が暗号化されたメッセージを生成するかを知っている。
【００２５】
しかしながら、各ターミナルユーザは、ターミナルユーザの暗号化処理および暗号化鍵を公表することによっては、暗号化されたメッセージを解読し、かつ署名を作成するために必要となるターミナルユーザの個人解読鍵を明らかにするものではない。これに関し、暗号化鍵の知識から解読鍵を計算することは、計算的に不可能である。
【００２６】
個人メッセージを送信することができるのに加えて、各ターミナルユーザは、送信されたメッセージをディジタル的に署名することもできる。メッセージは、ターミナルユーザによってディジタル的に署名されて、自分の個人暗号化鍵で当該メッセージを暗号化してから、当該メッセージを送信する。メッセージの受信に応答して、受信者は、送信者の公開暗号化鍵を用いてメッセージを読むことができる。このようにして、受信者は、秘密暗号化鍵の保持者のみがメッセージを作成したかを確認することができる。このように、署名されたメッセージの受信者は、メッセージが送信者から生じたという証明を得る。
【００２７】
さらに、本発明に関連して用いられ得る典型的なディジタル署名方法の詳細が米国特許第４，４０５，８２９号に開示されており、米国特許第４，８６８，８７７号および第５，００５，２００号には出願人のディジタル署名方法が開示されており、これら米国特許は、本明細書において明らかに援用される。
【００２８】
各コンピュータターミナルＡ〜Ｎは、好ましくは、電子商取引のための機密保護ワークステーションとして設計されている。本発明によれば、コンピュータターミナルの全メモリ領域が、後に詳細に述べられる態様で保護され、もし望むならばメモリの一部の領域のみが保護される。ターミナルメモリ領域に常駐する各プログラムは、好ましくは、本願出願人の同時係属出願である出願番号０７／８８３，８６８号、名称「プログラム許可情報データ構造を有するコンピュータシステム機密保護方法および装置」に記述されたような、プログラム許可情報（ＰＡＩ）に従って保護され、当該出願は本明細書において援用される。本発明の典型的な実施に従えば、関連するＰＡＩに従って許可されない限り、プログラムはターミナルＡ〜Ｎ上で実行される。ＰＡＩ情報は、プログラムを改変から保護するために用いられる。従来技術に従ったデータ暗号化は、プログラムによって処理されるデータの秘密性を保護するために用いられる。本発明は、データファイルを改変から保護するために用いられる。特に、同時に用いられたとき、高度に機密保護されるワークステーションは、電子商取引において信頼して用いられることになるであろう。
【００２９】
ターミナルＡがこの方法に従って保護されたラップトップコンピュータならば、このターミナルはどこに持ち運んでも良く、またウイルスを含むかもしれないプログラムを実行するために用いても良い。この方法に従ったメモリ領域の保護部分は、後述するように、そのような改変プログラムに対して免疫を有し、ユーザは、コンピュータシステムにおいて処理され、記憶され、そこから送信されるデータに対して非常に高度な信頼性を持つことができる。
【００３０】
図２は、本発明の図解された実施例に従う典型的な記録フォーマットを、簡素化された態様で示している。図２に示すに、ファイルは、ｎ個の個別の記録Ｒi （ｉ＝１〜ｎ）を含む。各記録Ｒi は、関連する記録識別子、例えば記録番号でもよい「Ｋi 」を有する。Ｋi は、例えば従業員番号のような指標値であっても良い。このように、ファイルは、連続的なファイル（記録１で始まり、記録２〜ｎが続く）として編成される。記録識別子は、ディスク上のセクタ番号であっても良い。記録識別子は、各記録が一律にかつ首尾一貫して識別されれば、いかなる関連する態様で（例えば、従業員番号等によって）編成されても良い。記録識別子Ｋi に加えて、各記録は、当業者によって理解されるような従来の媒体制御信号と共にデータに関連付けられる。
【００３１】
本明細書において用いられるように、記録の解釈は、用いられるアプリケーションまたはコンピュータシステムによって異なりうる。各バイトを記録として処理することが適切な場合もある。各バイトを処理することによって、全ファイルの完全なハッシュを常に保持することが可能となる。そのように編成されたディスクにおいて、各セクタを記録とみなすことも可能である。Ｓ／３６０アーキテクチャシステム等のようなシステムにおいては、連続番号付けのような分類された方法で規定され得るような個別の記録がある。あるデータベースシステムにおいては、記録はデータ鍵であるＫi 、つまり特定の記録を見分けるために用いられる値によって、最もよく識別される。
【００３２】
当然ながら、この典型的な実施例は、本発明を実現するための唯一の可能な方法とみなされるべきである。他の技術には、データの一部のみを用いること、またはデータ自身に代えて幾つかの特有のデータのハッシュを用いること、または未処理データおよびまたは他のデータのハッシュ値の組み合わせとしてデータ記録を構成することが含まれる。
【００３３】
本発明の典型的な実施例に従えば、後述するデータ構造は、ファイルが、通常の中断の場合に（ファイルが更新されているときに、どのようにシステムが中断されたとしても）常に復旧可能であることを保証する。他のいかなるタイプのデータ損傷も、それが偶然であっても意図的であっても、常に検出され得る。あらゆる中断の際に完全な復旧が望まれているというわけではない場合、後続の論理の一部が取り去られる。
【００３４】
実施例では、絶対的な変更阻止に加えて（中断からの）完全な復旧性を提供するために、「作業データ」構造とともにデータベースファイル構造と、「ファイルハッシュ」データ構造とを使用する。データベースファイルのデータ構造は、ユーザデータを含む。作業データのデータ構造は、更新の進行中にシステムが中断された場合の記録処理情報を含む。
【００３５】
作業データファイルがデータベースファイルに関連付けられる方法は、実施態様によって決まる。例えば、データベースファイルがオープンされて、以前に使用が中断され、復旧が必要になったことを示す作業データが存在する場合、作業データは、ファイル名によってデータベースに関連付けられるファイルとなる。ファイルをオープンする際に作業データファイルが存在しない場合、作業データファイルは、新しく作成され、データベースファイルが問題なくクローズされる度に消去される。この手法は、後述するように典型的な実施によって図示される。代わりに、作業データ要素のプールを処理環境によって維持される固定記憶装置内に常駐させ、データベースファイルをオープンする度に、ファイルをクローズするときに当該データベースファイルがプールに戻される度に、および進行中の更新を一掃するためのシステム中断後にチェックされる度に、動作中のデータベースファイルに関連づけてもよい。
【００３６】
作業データ処理中に停電が生じた場合には、ファイルは本来信頼性を有すると認識することができる。代わりに、ファイル処理中に停電が生じた場合には、作業データファイルに記憶されたデータが、ファイルを復旧可能にするために用いられる。このようにして、ファイルに対する必要な行為を見失わず、かつ適切な処理を作業データ構造を用いて行うことにより、ファイルは、このような中断に関して実質的に「防弾」の役割を果たすことになる。
【００３７】
図３に示すように、典型的な作業データのデータ構造５０は、５つのフィールドを有する。処理フィールド５２は、「加算」、「更新」、「削除」または「ナル」処理のいずれかを示す。記録識別子フィールド５４は、Ｋi を識別する。さらに、作業データのデータ構造は、修正された記録Ｒi の値（５６）、全てのまたは将来のデータベースハッシュの修正されたバージョン（５８）およびフィールド５２，５４，５６，および５８のハッシュ（６０）を含む。フィールド５４および５６は、「ナル」処理の場合には無視され、フィールド５８は、「削除」処理の場合には無視される。
【００３８】
無目的な破壊、通常のハードウェア（例えば媒体）障害、または書き込み中の中断によって、作業データ自身のいかなる部分でも不正となるか損傷を受けた場合には、作業データのデータ構造のフィールド６０内に保持された作業のハッシュとの不一致によって検出される。作業データは、不正者が作業データを変更してデータベースファイルを故意に変更しないように、ファイルハッシュと同様の方法で保護されなければならない。好ましい実施例においては、全てのファイルハッシュ、作業データおよびデータベースファイルのデータ構造は、有効なユーザのみに知られている鍵で暗号化されたフォームで記憶される。記録は、暗号化されてから書き込みが行われ、読み出される際に解読される。
【００３９】
データベースファイルの機密性ではなく、その完全性のみが要求される場合には、暗号化される必要があるデータは、作業データ記録内のフィールド６０およびファイルハッシュのみである。これにより、ファイルハッシュおよび作業データのいずれもが抜け目のない不正者によって操作され得ないことが保証される。
【００４０】
考慮する必要がある侵害行為の一つに、不正者が、古いデータをデータベースファイル、作業データおよびファイルハッシュの全てと取り替える可能性があるということがある。この場合には、データベースは一貫しており、以前のデータベースの状態を完全に反映し、それによって全ての有効性チェックと一致するが、現在のデータではないデータを反映しており、それによってデータを誤って導く可能性がある。
【００４１】
このような恐れには、いくつかの方法で対処することが可能で、例えば最終の更新日時を追加フィールドとして保持し、ファイルハッシュデータとともにそれを格納する。その後、この日時データを、毎回ファイルをオープンする行為の一部として、ユーザに対して示すこともできる。これにより、ユーザは、データベースファイルの古いバージョンを故意に再格納または使用することもできる。最終の「オープン」日時をファイルハッシュデータの一部として格納することも可能であり、ユーザトークン（例えばスマートカード）内にこれを格納することも可能である。ユーザトークンは、不正な修正に対して安全である（トークンは、また、暗号化鍵を格納するために用いられてもよい）。ファイルハッシュとともに見いだされる日時がユーザトークン内の日時と一致しない場合は、ユーザは古いバージョンのデータベースファイルが用いられようとしているという事実が知らされる。通常期待されるように日時が一致していれば、ユーザは決定をする必要がなく、処理を進めることが許可される。
【００４２】
この恐れには、ファイルハッシュおよび作業データを隠すために用いられる暗号化鍵を各オープン要求の開始の一部として変更することによって対処してもよい。これにより、各ファイルハッシュおよび作業データは、セッションからセッションへ複写されることができなくなる。最新の鍵は、ユーザによって保持される改変不可能なトークン内に格納されてもよい。
【００４３】
ファイルハッシュは、データベースファイルに関連付けられうる場所に格納される。ファイルハッシュは、権限を有するユーザ以外の者が不正に変更を行えないように設計されなければならない。これには幾つかの方法によって行うことが可能で、例えば有効なユーザのみに知られている対称的な暗号化鍵による暗号化、有効なユーザに知られた公開鍵に対応する公開鍵による暗号化または有効なユーザがファイルハッシュが信頼性を有することを証明できるなディジタル署名を含む。
【００４４】
他の技術を用いて、有効なユーザがファイルハッシュを信頼でき、かつ侵害者が変更できないようにしてもよい。信頼性のあるファイルハッシュは、例えば、当該ファイルに対応するディレクトリエントリ内に格納するか、ファイル自身の付属物として格納するかまたは当該ファイルと関連づけることを許可する特別のデータベース内に格納することができる。
【００４５】
実施例に従って、ファイルのハッシュは以下のように計算される。ファイルハッシュは、まず、初期値（例えば０）と同一にセットされる。その後、ハッシュルーチンが、ファイル内の全記録に対して索引をつけ、記録１からＮまでのすべての記録識別子Ｋiを用いて、この値を計算する。
ファイルハッシュ＝Ｆ（ファイルハッシュ、Ｈ（Ｋi ＆Ｒi ））
【００４６】
Ｋi ＆Ｒi という表記は、「Ｋi 」の値と関連の記録Ｒi の値とを明確に結びつける処理を示す。この処理を行うための簡単な方法の一つとしては、Ｋi がすべての鍵に対して単一の長さを有している場合（おそらく４バイトが付加された２進整数）、２つの値を連結する。フィールド「Ｋi 」の長さが異なる場合には、「Ｋi 」の値と「Ｒi 」の値とを明確に区別し、長さ（Ｋi ）‖Ｋi ‖Ｒi のような３つの値を連結するために、値「Ｋi 」に長さの表示を効果的に前置するように処理が詳述されなければならない。
【００４７】
Ｋi および記録Ｒi の内容が（たとえば連結により）明確に結合された後、データストリング全体のハッシュがハッシュ関数Ｈを用いて取り出され、その結果は、特別の関数Ｆを用いて適切なファイルハッシュ値全体と結合される。ハッシュ関数Ｈは一方向ハッシュ関数であって、ハッシュによって同じ結果となる２つのデータ値を見つけることは、計算上不可能である。そのような関数の例には、ＭＩＴ（マサチューセッツ工科大学）のリヴェスト教授が開発したＭＤ５ハッシュアルゴリズムや、機密ハッシュアルゴリズムＳＨＡが含まれる。
【００４８】
関数Ｆは、可換的かつ連想的関数であり、関連する逆関数「Ｆｉｎｖ」を有し、ハッシュ全体と更新記録のハッシュとを結合する手法を提供する。可換的かつ連想的関数の例には、排他的論理和（ＸＯＲ）および算術加算が含まれる。関数Ｆを適用した後、ハッシュ全体は、新規の記録を含む古い記録すべてのハッシュとなる。この処理は、ファイル内の全記録に対して行われる。記録が索引データ鍵、すなわち特定の記録を識別するために用いられる値Ｋi によって最もよく区別される場合には、上述の処理ループは、すべての活動索引入力に対して行われる。
【００４９】
記録Ｋi が更新されると（Ｒi は古い記録、Ｒ２i は新規の記録値である場合）、新規の更新されたファイルハッシュが以下のように再計算される。
ファイルハッシュ＝Ｆ（Ｆｉｎｖ（ファイルハッシュ，Ｈ（Ｋi ＆Ｒi ）），Ｈ（Ｋi ＆Ｒ２i ））
【００５０】
言い換えれば、以前の記録のハッシュは削除され、新規の値が挿入される。記録Ｋiがデータベースから削除されると、データファイルハッシュは以下のように改訂される。
ファイルハッシュ＝Ｆｉｎｖ（ファイルハッシュ，Ｈ（Ｋi ＆Ｒi ））
【００５１】
新規の記録Ｋi が導入されると、改訂されたハッシュは、以下のようになる。
ファイルハッシュ＝Ｆ（ファイルハッシュ、Ｈ（Ｋii＆Ｒi ））
【００５２】
このプロトコルを用いることによって、改訂されたハッシュが、計算、修正、格納可能となる。
【００５３】
図４は、システムが（方法の如何を問わず改訂しようとするまたは用いようとする）ファイルをオープンしてファイルの有効性を証明する場合の処理のシーケンスを示すフローチャートである。ファイル処理は、データベースファイルをオープンすることによって開始する（１０１０）。最初に、ブロック１０１２において、データベースファイルが初めて作成されようとしているか又は再初期化（すなわち上書き）されようとしているかどうかを決定するチェックが行われる。
【００５４】
ファイルが新規のファイルかまたは再初期化されている場合には、変数「ファイルハッシュ」は０にセットされて、ルーチンは分岐してブロック１２３０へ進む。ファイルハッシュを０に初期化することにより、ファイルを走査するためにステージがセットされ、すべての記録が存在し新規であることおよびどの記録も侵害および再構成されていないことを保証し、かつ該当するすべてのファイルが適切なチェックと合致することを保証する。従って、データベースを最初に用いる度に、ファイルが走査されて格納されたハッシュをチェックする。
【００５５】
ブロック１０１２におけるチェックによって、処理されているデータベースファイルが古いファイルであることが示されると、ルーチンは分岐してブロック１０２０へ進み、関連する「ファイルハッシュ」がアクセスされる。ファイルハッシュは機密性を有するディレクトリに格納され、ユーザのみに知られる鍵で暗号化されてもよい。この値は、ファイルが最後に用いられた時の状態を反映する。ファイルが正確にどこに格納されるかは、実施の仕方による。本発明の好ましい実施例では、ファイルハッシュは、個別のデータベース内か、ファイルとは異なる場所か、またはファイルのディレクトリ入力の近傍内に格納されうる。
【００５６】
ブロック１０２５において、データベースファイルに対応する作業データが存在するかどうかのチェックが行われる。上記図３で示すような作業データがデータベースファイル用に存在しない場合は、ルーチンは分岐してブロック１２３０へ進む。
【００５７】
ブロック１０２５におけるチェックによって、作業データのデータ構造が存在することが示されると、ブロック１０３０において、以前の処理中に中断されていたであろうデータベースファイルの更新のための復帰を行うための処理が開始される。最初に、作業データのデータ構造がオープンされて、読み出される。好ましい実施例では、作業データファイルは暗号化されているので、内容を読み込むには復号化しなければならない。その後、ブロック１０３０において、フィールド５２，５４，５６，５８のハッシュを計算し、その計算されたハッシュと図３のフィールド６０内の格納されたハッシュとを比較することによって、作業データ自身が有効であることを確認するためのチェックが行われる。このようにして、作業データ情報が処理されているときに中断は生じなかったことを確認することができる。
【００５８】
計算されたハッシュが、フィールド６０内の格納されたハッシュと一致しない場合は（１０５０）、ルーチンは分岐してブロック１２２０へ進み、新規の作業データを作成する処理が開始する。ハッシュが一致しないということは、作業データ自身が書き込み中に中断されたことを意味する。このような場合は、データベースファイルおよびファイルハッシュは、正しいものであり、かつ一致していなければならず、このことは、ブロック１２２０における継続処理によって証明されることが期待されている。
【００５９】
ハッシュが一致する場合、処理はブロック１０６０へと続き、以前の処理に含まれている更新が再適用される。従って、データベースファイルに対して行われた最終の処理が繰り返され、繰り返す際には、フィールド５２において指定された処理に基づく作業データのデータ構造、フィールド５４の記録識別子、フィールド５６からの修正記録の値、および図３に示すデータ構造のフィールド５８内のデータベースハッシュ全体（新規または将来のハッシュ）の修正バージョンからのデータを用いる。
【００６０】
その後、ブロック１０６５において、作業データのデータ構造５０のフィールド５２に示す処理が加算処理かどうかを決定する処理が行われる。加算処理の場合は、ルーチンは分岐してブロック１０７０へ進み、加算処理の繰り返しを開始する。（作業データのデータ構造５０のフィールド５６の記録の内容を示す）Ｒn の値が、識別子Ｋn によって識別される記録に配置される。記録Ｋn が存在する場合は、記録Ｋn を値Ｒn に置換する。記録Ｋn が存在しない場合は、新規のＲn が挿入される。その後、ルーチンは分岐してブロック１２００へ進み、ファイルハッシュ値が更新される。
【００６１】
ブロック１０６５でのチェックによって、処理が加算処理でないことが示されると、処理が更新処理かどうかを決定するチェックが行われる（１０８０）。ブロック１０８０でのチェックによって更新処理であることがと示されると、ブロック１０９０において、記録Ｋn 内の値が値Ｒn （修正記録データ内容）に置換されることによって更新処理が行われ、ルーチンは分岐してブロック１２００へ進む。
【００６２】
ブロック１０８０でのチェックによって、処理が更新処理でないことが示されると、ブロック１１００において、処理が削除処理であるかどうかを決定するためのチェックが行われる。処理が削除処理である場合は、ルーチンは分岐してブロック１１１０へ進み、識別子Ｋn によって識別された記録が存在しないことを確認するためのチェックが行われる。Ｋn によって識別された記録が存在する場合は、記録は削除され、ルーチンは分岐してブロック１２００へ進む。
【００６３】
ブロック１１００でのチェックによって、処理が削除処理でないことが示されると、ブロック１１２０において、処理が「ナル」処理かどうかを決定するためのチェックが行われる。ナル処理は、ファイル開閉時において作業データファイルを準備するために、ファイル処理の最初および最後に行われる。処理がナル処理の場合は、データベースファイルおよびデータハッシュは共に正確で一致しているものとして、ルーチンは分岐してブロック１２２０へ進む。ブロック１１２０でのチェックによって、処理がナル処理でないことが示されると、エラー状態が存在し、処理はブロック１１３０において抑止される。ブロック１１３０に到達すると、作業ファイルは正しく構築されていないと決定されたこととなる。
【００６４】
ブロック１０６５，１０８０または１１００でのチェックによって、加算処理、更新処理、または削除処理が示されると、処理は分岐してブロック１２００へ進み、ファイルハッシュ値が、各処理の遂行後の最新の既知の値を反映するように更新される。このようにして、ファイルハッシュ値が、所望する処理の遂行後に、保護された作業データおよび保護されたファイルデータに基づいて、新規のファイルハッシュに予定される値にセットされる。この新規のファイルハッシュ値は、所望通りに暗号化され、ファイルハッシュデータ構造に書き込まれる。
【００６５】
処理はブロック１２２０へと続き、作業データフィールド５２がナル処理にリセットされる。所望するならば、リセットされた作業データは暗号化され、作業データ５０に書き込まれる。その後、作業データファイル全体が削除される。
【００６６】
ルーチンがブロック１２３０で処理を開始すると、作業データは吸収および削除され、関連ファイルデータが更新される。処理のこの時点において、関連ファイルは正確でなければならない。ブロック１２３０において、新規の作業データファイルが作成され、ナル処理に初期化され、必要があれば暗号化されて書き込まれる。
【００６７】
新規の作業データファイルが作成された後に、ブロック１４００において、データベースファイルがファイルハッシュと一致することを確認する処理が開始する。この処理を開始するために、計算されたハッシュは０にセットされる。ブロック１４１０において、ファイル内のすべての記録を通過するループが入力される。すべての記録がループ内で処理されると（ブロック１４２０）、ルーチンは分岐してブロック１４３０へ進む。データベースファイルがちょうど作成中の場合は、レコードは存在せず、このループは全く実行されず、ルーチンはすぐに分岐してブロック１４３０へ進む。
【００６８】
ブロック１４２０において、Ｋn が識別する記録の値Ｒn が読み出され、必要に応じて復号化される。その後、以下を計算することによって、計算されたハッシュに新規のＲn が増補される。
計算されたハッシュ＝Ｆ（計算されたハッシュ，ハッシュ，（（Ｋn の長さ）‖Ｋn ‖Ｒn ））
【００６９】
好ましい実施例において、ＦおよびＦの逆関数が排他的論理和である場合は、以下のようになる。
計算されたハッシュ＝計算されたハッシュ  ＸＯＲ  ハッシュ，（Ｋn の長さ‖Ｋn ‖Ｒn ）
【００７０】
ルーチンは、すべての記録が確実に一度処理されるまで、分岐してブロック１４１０に戻る。
【００７１】
すべての記録が処理された後、ブロック１４３０において、新規の「ファイルハッシュ」が「計算されたハッシュ」と等しいかどうかを決定するチェックが行われる。ハッシュが一致すると、データベースファイルは有効で、一致しており、改変されていないことが証明され、ルーチンはメインルーチンに戻って、信頼性のあるデータが処理される。代わりに、ハッシュが一致しない場合は、データベースファイル、ファイルハッシュまたは作業データの少なくとも一つが、何らかの方法で害されているか、改変されていることになる。このエラー状態は、ユーザまたはアプリケーションプログラムに示され（１４４０）、そこでアプリケーションは中止されるか、または実施例によっては、ユーザが処理を中断するかまたは危険を承知で処理を継続させるかを決定することができてもよい。
【００７２】
図５は、加算処理、更新処理または削除処理を遂行する処理のシーケンスを示すフローチャートである。図５に示すルーチンは、示された処理が加算処理、更新処理、または削除処理である場合に実行される。図５において、以下に述べる用語は、処理が記録Ｋn に対して行われ、かつ加算処理、更新処理および削除処理用に、新規のＲn は挿入されるべき記録Ｋn の値だと推定している。以下に述べる用語は、更新処理および削除処理用に、処理開始時の古いＲn は記録Ｋn の新規値であると推定している。従って、以下に示す２つの値は、加算処理および更新処理用の「新規のＲn 」であり、挿入されるべき記録Ｋn の新規値であって、かつ更新処理および削除処理用の「古いＲn 」であり、処理開始時の記録Ｋn の新規値である。
【００７３】
ブロック２０１０において、フィールド５２における当該処理（加算、更新または削除）の挿入および図３のフィールド５４における記録識別子Ｋn （その長さを含む）の挿入によって新規の作業データを作成する準備を行うことによって、処理が開始する。ブロック２０２０において、処理が更新かまたは削除かを決定するチェックが行われる。処理が更新または削除であれば（古い記録が置換中であれば）、ブロック２０３０において、ファイル全体のハッシュが、古い記録を控除して計算される。古い記録をハッシュ全体から取り除くには、関数Ｆｉｎｖを以下のように用いる。
ファイルハッシュ＝Ｆｉｎｖ（ファイルハッシュ，ハッシュ（Ｋn の長さ‖Ｋn ‖古いＲn ））
【００７４】
ＦおよびＦｉｎｖが排他的論理和である好ましい実施例においては、以下のようになる。
ファイルハッシュ＝ファイルハッシュＸＯＲハッシュ（Ｋn の長さ‖Ｋn ‖古いＲn ）
【００７５】
削除処理が示される場合は、変更された記録の値が存在しないので、変更された記録の値のためにダミーフィールド５４および５６が挿入される。
【００７６】
処理が更新処理または削除処理でない場合（またはブロック２０３０で既存の記録のハッシュの再計算後の場合）は、コントロールはブロック２０４０へ到達し、処理が加算処理か更新処理かを決定するチェックが行われる。処理が加算処理かまたは更新処理の場合は、ルーチンは分岐してブロック２０５０へ進み、新規の記録が作業データのデータ構造５６に挿入され、変更される記録である新規Ｒn が、ファイルハッシュ全体に以下を用いて組み込まれて処理される。
ファイルハッシュ＝Ｆ（ファイルハッシュ，ハッシュ（Ｋn の長さ‖Ｋn ‖新規Ｒn ））
【００７７】
ＦおよびＦｉｎｖが排他的論理和である好ましい実施例においては、以下のようになる。
ファイルハッシュ＝ファイルハッシュ  ＸＯＲ  ハッシュ（Ｋn の長さ‖Ｋn ‖新規Ｒn ）
【００７８】
処理が加算処理または更新処理でない場合（またはブロック２０５０での処理後の場合）は、すべてのデータベースの変更されたファイルハッシュは、作業データのデータ構造５０のフィールド５８に挿入される（２０６０）。新規に出された作業データフィールド５２，５４，５６および５８の連結ハッシュが計算され、作業データのデータ構造５０のフィールド６０に挿入される。新規の作業データは、作業データファイルに書き込まれる前に、必要があれば、暗号化される。少なくともフィールド６０の作業データファイルは保護のため暗号化されるべきである。
【００７９】
ブロック２０７０において、例えばディスクメモリ上に上記の情報の書き込みが正しくなされたかどうかの決定するためのチェックが行われる。書き込みに失敗すると、ルーチンは分岐してブロック２０８０へ進む。書き込みが正しく行われていれば、ブロック２１００に進む。
【００８０】
エラーの場合でも、データベースファイルの処理のこの段階においては、ファイルハッシュは変更されずに一致しており、将来の復旧の際にも正しいデータを生じるのは、以下の理由による。すなわち、作業データが実際には全く書き込みがなされていなかった場合に、復旧は最終の更新を見に行き、データベースファイルを現在の状態に再格納する。作業データが部分的にまたは誤って書き込まれた場合は、フィールド６０内の最終ハッシュ内に後続の復旧に対して失敗が示される。何のアクションも行われず、データベースは現在の（正しい）状態のままでいることができる。作業データが実際に所望通りに書き込みがなされた場合は、復旧は正しい記録を見に行き、所望通りの最新の変更を適用する。その後、更新は中断される。
【００８１】
ブロック２０７０のチェックによって、書き込みが順調に行われたことが示されると、所望する更新処理（例えば加算、更新、削除）が、ブロック２１００で行われる。その後、ブロック２１１０において、処理が順調に行われたかどうかを決定するためのチェックが行われる。処理は種々の理由で失敗するかもしれない（例えばユーザによる電源遮断を含む）。いずれにせよ、復旧処理過程中に処理が再び試みられる。実施例では、ルーチンは現在の加算ルーチン、更新ルーチンまたは削除ルーチンを出て（２１１５）、呼出者に対してエラーを提示する。
【００８２】
処理が正しく行われると、更新されたファイルハッシュ値が書き込まれ、暗号化される（２１２０）。ファイルハッシュ値が順調に書き込まれたとブロック２１３０でのチェックによって決定されると、ルーチンは戻って、データベースファイルの修正が成功したことを示す（２１４５）。書き込みに失敗したとブロック２１３０でのチェックに決定されれば、ルーチンは分岐してブロック２１４０に進み、ルーチンはエラーを伴って出る。将来どのような復旧を行おうとしても、ファイルハッシュを正しくセットしようとして行われる作業を繰り返すこととなる。図４および図５に関連して説明される実施例は、当業者によって理解される一度に単一の記録および単一の処理のみを扱うことに関連していたが、複数の記録を扱うように拡張されてもよい。
【００８３】
図６は、クローズ処理を含む処理のシーケンスを示すフローチャートである。ブロック３０１０において示すように、新規の最終作業データ構造５０が構成され、そこではナル処理表示がフィールド５２に挿入され、ダミーフィールドがフィールド５４および５６に挿入される。最終のファイルハッシュがフィールド５８に挿入され、新規に構成された作業データフィールド５２，５４，５６および５８の連結ハッシュが計算される。その後、このハッシュは、作業データ構造フィールド６０に挿入される。最終の作業データ構造は、適切に暗号化されて、メモリに書き込まれる。その後、ファイルと共に最終のファイルハッシュ値が、ファイルディレクトリまたは他の安全な場所に移動される等して格納されることを確認する処理ステップが行われる（３０２０）。その後、データベースファイルはクローズして（３０３０）、作業データファイルが消去されるか、または現在のデータベースファイルから関連付けが解除される（３０４０）
【００８４】
実施例は、従来の問題を避けつつ、全ファイルの完全性を提供する。確実な完全性は、以下のように、若干のオーバーヘッドを追加することによって達成される。すなわち、システムファイルディレクトリ内（状況によっては、ハードドライブ全体がファイルとみなされる場合もある）または特に機密性のあるデータベース内の各ファイルに関連するあるハッシュ値の格納、および各ファイルを最初にアクセスする（オープンする）ときに全ファイルを走査して、格納されたハッシュでハッシュを証明するために当該ハッシュを計算する追加処理、およびある時点で用いられているファイルのハッシュを格納するための追加作業メモリ、およびどの記録でも加算、更新または削除される際に、修正されたハッシュの計算およびファイルに当該ハッシュを再書き込みを行う追加処理である。
【００８５】
以上開示された方法により、機密性の確保されていない計算システムが高度の機密性を有する電子金融取引を安全に遂行することができる。本発明により、ファイルのハッシュが増分ベースで取られることができる。これにより、ファイルのどの部分でも変更が可能であるとともに、修正されたファイル部分および以前の合計ハッシュに基づいて新規の合計ハッシュを計算することができる。本発明に従えば、合計ハッシュは、各記録の修正に伴って即座に更新することができ、従来技術に従って全ファイルのハッシュを再計算する必要がない。
【００８６】
本発明を、現在最も実用的で好ましい実施例と考えるものと関連して説明してきたが、本発明は、開示された実施例に限定されるべきではなく、逆に、追加されたクレームの精神および範囲内に含まれる種々の修正および同等の構成を含むことが想定されていると理解されるべきである。
【産業上の利用可能性】
【００８７】
本発明に係る方法は、定期的に更新されるファイルのハッシュを発生させること等が必要なコンピュータデータの機密保護等の用途にも適用できる。
【図面の簡単な説明】
【００８８】
【図１】本発明で用いられる通信システムのブロック図である。
【図２】本発明の実施例に従う典型的な記録フォーマットを概略的に示す図である。
【図３】作業データのデータ構造の典型的な状態を表現する図である。
【図４】システムがファイルをオープンして、どんな方法にせよ更新または使用する場合に、典型的な実施例に従って遂行される動作のシーケンスを示すフローチャートである。
【図５】加算、更新または削除動作を実行する際に、典型的な実施例に従って遂行される動作のシーケンスを示すフローチャートである。
【図６】動作を終了するために、典型的な実施例に従って遂行される動作のシーケンスを示すフローチャートである。
【符号の説明】
【００８９】
Ａ〜Ｎ…ターミナル
２…プロセッサ
４…キーボード／ＣＲＴ
６，８，１０…モデム
【図１】
2006092574.tif 000003
【図２】
2006092574.tif 000004
【図３】
2006092574.tif 000005
【図４】
2006092574.tif 000006
【図５】
2006092574.tif 000007
【図６】
2006092574.tif 000008