(57)【特許請求の範囲】
【請求項１】
ファイルシステムを有するコンピュータシステムにおいて、ファイル内のデータを暗号化又は解読する方法であって、
ファイルが暗号化されるとして指定されることを示す情報を、ファイルシステムにおいて受信するステップと、
前記ファイルに関連付けられたファイル暗号化キーを受信するステップと、
前記ファイル暗号化キーを複数のパブリックキーを用いて暗号化して複数の暗号化されたファイル暗号化キーとするステップと、
前記ファイルデータを不揮発性記憶装置に書き込むための要求を受信し、かつ前記ファイルデータを受信し、応答して、前記ファイル暗号化キーを使用して、前記ファイルデータを暗号化して暗号化されたファイルデータとし、前記暗号化されたファイルデータを前記不揮発性記憶装置に書き込み、前記ファイルに関連して前記複数の暗号化されたファイル暗号化キーを前記不揮発性記憶装置に書き込むステップと、
前記不揮発性記憶装置から前記暗号化されたファイルデータを読み取るための要求を受信し、応答して、前記不揮発性記憶装置から前記暗号化されたファイルデータを読み取り、前記暗号化されたファイル暗号化キーを使用して、読み取った前記暗号化ファイルデータを解読して解読ファイルデータとし、前記解読ファイルデータを戻すステップとを具えたことを特徴とする方法。
【請求項２】
前記複数のパブリックキーに対応する複数のプライベートキーのいずれかを用いて前記暗号化されたファイル暗号化キーを解読して前記ファイル暗号化キーとするステップをさらに具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記複数の暗号化されたファイル暗号化キーの少なくとも１つがユーザのパブリックキーを用いて暗号化され、前記複数の暗号化されたファイル暗号化キーの他の少なくとも１つが、回復エージェントのパブリックキーを用いて暗号化されることを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザのパブリックキーを用いて暗号化された前記暗号化されたファイル暗号化キーが、前記回復エージェントのパブリックキーを用いて暗号化された前記暗号化されたファイル暗号化キーとは別個のフィールド内に記憶されることを特徴とする請求項３に記載の方法。
【請求項５】
前記ユーザ又は前記回復エージェントのいずれかのプライベートキーを受信するステップと、一致が検出されるまで、前記プライベートキーを使用することにより、前記ファイルに記憶された前記暗号化されたファイル暗号化キーを走査するステップとをさらに具えたことを特徴とする請求項３に記載の方法。
【請求項６】
乱数を発生するステップと、前記ファイル暗号化キーをそれに基づかせるステップとをさらに具えることを特徴とする請求項１に記載の方法。
【請求項７】
データを暗号化及び解読するステップがそれぞれ、関数のランタイムライブラリへコールアウトを行うステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
ファイルシステムを有するコンピュータシステムにおいて、非暗号化ファイルデータ又は暗号化ファイルデータを読み取り、読み取られたデータを非暗号化ファイルデータとして戻す方法であって、不揮発性記憶装置からファイルデータを読み取るための要求を、ファイルシステムにおいて要求プログラムから受信するステップと、ファイルデータを読み取るステップと、ファイルデータが暗号化されているか否かを判定するステップと、ファイルデータが暗号化されていない場合、ファイルデータを要求プログラムに戻すステップと、ファイルデータが暗号化されている場合、ファイルデータの暗号化に使用され、複数のパブリックキーを用いて各々暗号化されてファイルに記憶された暗号化されたファイル暗号化キーを獲得するステップと、前記複数のパブリックキーのいずれかに対応するプライベートキーを用いて前記暗号化されたファイル暗号化キーを解読してファイル暗号化キーとするステップと、解読したファイル暗号化キーと暗号化されているファイルデータを解読メカニズムに提供するステップと、解読したファイル暗号化キーにより暗号化されているファイルデータを非暗号化ファイルデータに解読するステップと、非暗号化ファイルデータを要求された前記ファイルデータとして要求プログラムに戻すステップとを具えたことを特徴とする方法。
【請求項９】
不揮発性記憶装置からファイルデータを読み取る要求を受信するステップが、生データ読取りをファイルシステムに通知するステップを含み、データが不揮発性記憶装置から読み取られ、前記データを解読メカニズムに提供することなく戻されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記複数のパブリックキーの少なくとも１つがユーザのパブリックキーであり、前記複数のパブリックキーの他の少なくとも１つが回復エージェントのパブリックキーであることを特徴とする請求項８に記載の方法。
【請求項１１】
前記複数のパブリックキーのいずれかに対応するユーザ又は回復エージェントのいずれかのプライベートキーを受信するステップと、ファイル暗号化キーが検出されるまで、前記暗号化されたファイル暗号化キーを前記プライベートキーを用いて解読することにより、前記ファイルに記憶された前記暗号化されたファイル暗号化キーを走査するステップとをさらに具えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
ファイルシステムを有するコンピュータシステムにおいて、選択されたファイルデータを暗号化ファイルデータとして記憶する方法であって、ファイルデータを書き込む要求及び暗号化されて書き込まれるファイルデータをファイルシステムにおいて受信するステップと、ファイル暗号化キーを使用することにより、前記ファイルデータを暗号化して暗号化されたファイルデータとするステップと、前記ファイル暗号化キーを複数のパブリックキーを用いて暗号化して複数の暗号化されたファイル暗号化キーとするステップと、前記暗号化されたファイルデータ及び前記複数の暗号化されたファイル暗号化キーを不揮発性記憶装置に書き込むステップとを含むことを特徴とする方法。
【請求項１３】
不揮発性記憶装置にファイルデータを書き込む要求を受信するステップが、生データ書込みをファイルシステムに通知するステップを含み、データは、前記データをさらに暗号化することなく前記不揮発性記憶装置に書き込まれることを特徴とする請求項１２に記載の方法。
【請求項１４】
ファイルシステムを有するコンピュータシステムにおいて、ファイルシステムによって不揮発性記憶装置に書き込まれたデータを暗号化するためのシステムであって、
ファイル暗号化キーを獲得するための手段と、
前記ファイル暗号化キーを用いて非暗号化データを暗号化データに変換するための暗号化メカニズムと、
前記データの少なくとも一部を暗号化されたデータとして不揮発性記憶装置内のファイルに書き込む手段と、
前記ファイル暗号化キーを暗号化して暗号化されたファイル暗号化キーとするための手段と、
前記暗号化されたファイル暗号化キーを前記ファイルに関連付けて前記不揮発性記憶装置に書き込む手段と
を具え、
前記ファイル暗号化キーを暗号化するための手段は、前記ファイル暗号化キーを複数のパブリックキーを用いて暗号化して複数の暗号化されたファイル暗号化キーとすることを特徴とするシステム。
【請求項１５】
前記ファイルに関連して記憶されたファイル暗号化キーを検索するための手段であって、前記暗号化されたファイル暗号化キーを解読するための手段を含む、手段と、
前記ファイル暗号化キーを用いて前記暗号化データを解読データに変換するための解読メカニズムと
を含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記ファイル暗号化キーを獲得するための手段が、乱数発生器を含むことを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記ファイル暗号化キーを暗号化するための前記手段が、少なくとも１人のユーザのパブリックキーにアクセスするための手段を含むことを特徴とする請求項１５に記載のシステム。
【請求項１８】
ファイル暗号化キーを解読するための手段が、少なくとも１人のユーザのパブリックキーに対応するプライベートキーを受信するための手段を含むことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記ファイル暗号化キーを暗号化するための手段が、少なくとも１人の回復エージェントのパブリックキーにアクセスするための手段を含むことを特徴とする請求項１５に記載のシステム。
【請求項２０】
前記ファイル暗号化キーを解読するための手段が、少なくとも１人の回復エージェントのパブリックキーに対応するプライベートキーを受信するための手段を含むことを特徴とする請求項１７に記載のシステム。
【請求項２１】
前記暗号化メカニズムが暗号化ドライバを含むことを特徴とする請求項１４に記載のシステム。
【請求項２２】
前記暗号化メカニズムが、ファイルシステムを介して前記暗号化ドライバによって呼び出される関数のライブラリをさらに含むことを特徴とする請求項１４に記載のシステム。
【請求項２３】
前記暗号化ドライバと前記関数のライブラリの間で通信するための一般データ変換メカニズムをさらに具えたことを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記暗号化メカニズムと前記解読メカニズムが共通の暗号化ドライバを含む請求項１５に記載のシステム。
【請求項２５】
前記ファイル暗号化キーを獲得するための手段が、ファイルに関連してファイル暗号化キー情報を一時的に記憶するためのキーコンテキストバッファを含むことを特徴とする請求項１４に記載のシステム。
【請求項２６】
前記ファイル暗号化キーを検索するための手段が、ファイルに関連してファイル暗号化キー情報を一時的に記憶するためのキーコンテキストバッファを含むことを特徴とする請求項１５に記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、一般に、コンピュータ記憶技術に関し、さらに詳細には、コンピュータシステムのための暗号化ファイルシステム及び方法に関する。
【０００２】
（発明の背景）
極秘データの保護は、コンピュータのユーザにとって非常に重要な問題になっている。たとえば、個人用記録あるいは顧客のクレジットカード番号のようなデータは、コンピュータに記憶され、そのコンピュータ（あるいは単に記憶媒体）が盗難にあった場合、窃盗犯は極秘情報にアクセスする。これはとくに、ラップトップコンピュータでは厄介であり、それはしばしば知能的な窃盗犯により盗難にであう。さらに、無権限の個人がコンピュータにアクセスし（多分そのコンピュータが単にオンラインである）、そのファイルの部分又は全部から情報を複写する時のように、記憶媒体が物理的に取られない時でさえ情報は横領される。極秘情報にアクセスする権限があるユーザは、情報がコピーされたことさえも気がつかないことがある。
【０００３】
情報を保護するために、一形式の機密保持手順は、データを暗号化するものであり、そのため、データが悪意のある者の手に渡ったとしても、それはキーなしに読み取ることはできない。多くのアプリケーションレベルのプログラムは、ある形式のそのような暗号化を備える。しかし、ないよりはよいが、そのような現存する暗号化体系は、無数の問題をかかえる。
【０００４】
１つの重大な問題は、暗号化データがなお、多数の攻撃を許していることである。さらに詳細には、暗号化機能を備えるアプリケーションは、パスワード／パスフレーズ導出キーを使用するが、辞書攻撃等のために、定義に対して軟弱である。さらに、攻撃は、時間とともに、また、特にハードウェアの改良とともに進んでおり、かつてあるアプリケーションによって安全とみなされたものが、もはや安全ではないことがある。
【０００５】
また、ユーザは、キーを損失しがちである。損失キーの問題は、多様なユーザにキーを普及させることによって除去されるが、これは、さらに、安全性に妥協するものである。さらに、各ファイルは、異なるパスワードを有してもよいが、これは、再呼び出しを困難にする。したがって、便宜上、多数のユーザ達は、１つのファイルを暗号化するために使用されたと同一のパスワードキーにより多数のファイルを暗号化する。これにより、１つのファイルに対するキーを別の人に漏らすことはしばしば、多数の他のファイルに対するキーを、その人に不注意に与えることになる。さらに、１つ以上のファイルへのユーザアクセスを除去又は付加するために、各ファイル（および各ファイルのすべてのコピー）は、解読され、新キーで再暗号化され、その後、再配布されなければならない。
【０００６】
さらに別の重大な問題は、暗号化プロセスが不便であり、使用中各ファイルの暗号化及び解読を必要とすることである。結果として、多数の一般ユーザは、多様なファイルを暗号化することに悩むよりもむしろ、機密保持の心配を無視する傾向がある。
【０００７】
別の重大な問題は、大部分のアプリケーションは、ユーザが文書の作業中、一時的ファイルを作成することである。これらの一時的ファイルは、原文が保存された後、常に除去されるわけではなく、極秘データを攻撃され易いままにすることになる。また、最新のオペレーティングシステムでは、アプリケーションレベルの暗号化が、ユーザモードにおいてランし、こうして、ユーザの暗号化キーを含むすべてのデータは、ページファイルにされ、キーを検出する作業をきわめて容易にする。最近では、大部分のファイル暗号化アプリケーションは、組み込み暗号化アルゴリズムを有し、このため、異なる又は多様なアルゴリズムをサポートする時に、拡張性又は融通性がない。ここでのアルゴリズムは、アルゴリズムが時間の経過とともに改良される時、または、例えば、暗号化されるデータの秘密の度合に基づいて、速さ対強度の取捨選択をする、特定データに対する暗号化アルゴリズムから選択するために、暗号化アルゴリズムをユーザに更新させるようなものである。
【０００８】
（発明の目的及び要約）
したがって、本発明の一般的目的は、上記の問題を実質的に解消するデータ暗号化のための改良システム及び方法を提供することにある。
【０００９】
本発明の別の目的は、ファイルシステムへ統合される上記の種類のシステム及び方法を提供することにある。
【００１０】
本発明の関連した目的は、暗号化及び解読が合法なユーザに透過的に作用するシステム及び方法を提供することにある。
【００１１】
これらの目的を達成するために、極秘データを２人以上の合法なユーザの間で共有する能力を提供し、ユーザのためのアクセスの付加及び除去が簡単である上記の特徴を有するシステム及び方法を提供することが、本発明の関連した目的である。
【００１２】
本発明のさらに別の目的は、ユーザがキーを失う時などの、暗号化データ回復の処置を取る強力な暗号法を提供することにある。
【００１３】
本発明のさらに別の目的は、融通性及び拡張性のある上記の種類のシステム及び方法を提供することにある。
【００１４】
簡単に言うと、本発明は、ファイル内のデータを暗号化又は解読するためのシステム及び方法を提供する。ユーザが、ファイル又はその親ディレクトリの暗号化を指定する時は常に、暗号化ファイルシステムは、ファイルに関連付けられた暗号化キーを受け取る。その後、システムが非暗号化テキストファイルデータをディスクに暗号化の方法で書き込む要求を受け取る時、ファイルシステムは、ファイルデータを受け取り、暗号化キーを使用して、ファイルデータを暗号化ファイルデータに暗号化し、暗号化ファイルデータをディスクに書き込む。逆に、システムがディスクから暗号化ファイルデータを読み取る要求を受け取る時、ファイルシステムは、暗号化ファイルデータを読み取り、暗号化キーを使用して、読み取りデータを解読ファイルデータに解読し、解読ファイルデータをユーザに戻す。
【００１５】
暗号化キーは、少なくとも１人のユーザと少なくとも１人の回復エージェント（recovery agent）のパブリックキーによって暗号化された乱数である。これらのキーは、ファイルに記憶され、これにより、ファイルは、ユーザ又は回復エージェントのいずれかのプライベートキーにより常に解読されることができる。
【００１６】
他の目的及び利点は、図面を参照して、次の詳細な説明から明らかになるであろう。
【００１７】
（好ましい実施形態の詳細な説明）
一般アーキテクチャ
まず、図面の図１を参照するに、本発明が取り入れられた、一般的に２０で指定されたコンピュータシステム２０が示されている。例示のコンピュータシステム２０は、サーバ、ワークステーション、またはそれらの組み合わせであり、公知の方法で、１つ以上の他のコンピュータベースの資源へ接続される。もちろん、明らかになるように、発明は、特定形式のコンピュータ又はネットワークアーキテクチャに限定されず、スタンドアロン型パーソナルコンピュータ又は同等物へ取り入れてもよい。
【００１８】
図１に示されたように、コンピュータシステム２０は、オペレーティングシステム２６をロードしたメモリ２４に接続したプロセッサー２２を有する。好ましくは、オペレーティングシステム２６は、マイクロソフト社のＷｉｎｄｏｗｓ  ＮＴオペレーティングシステムである。コンピュータ２０は、Ｗｉｎｄｏｗｓ  ＮＴファイルシステム２８（ＮＴＦＳ２８）などのファイルシステム２８を、オペレーティングシステム２６に付随して又は含んでいる。しかし、理解できるように、本発明は、特定のオペレーティングシステム及び／又はファイルシステムに限定されないが、明確性のために、本発明は、以後、Ｗｉｎｄｏｗｓ  ＮＴとＮＴＦＳ２８を参照して説明される。メモリ２４における少なくとも１つのアプリケーションプログラム３０は、アプリケーションプログラミングインターフェース（ＡＰＩ）３２を介して、オペレーティングシステム２６及びファイルシステム２８とインターフェースする。
【００１９】
コンピュータシステム２０はまた、１つ以上のネットワーク装置、キーボード及び／又はマウスなどの１つ以上の入力装置３６、及び／又はモニタ及び／又はスピーカなどの１つ以上の出力装置３８へ、コンピュータシステム２０を接続するための入出力（Ｉ／Ｏ）回路３４を含む。コンピュータシステム２０はまた、ハードディスクドライブなどの不揮発性記憶装置４０を含む。理解できるように、不揮発性記憶装置４０は、メモリ２４のランダムアクセスメモリに関連して動作し、スワッピング技術により大量の仮想メモリを供給する。
【００２０】
ファイルシステム２８は、ファイルの管理をするために、通信するためのデバイスドライバ４２を介して不揮発性記憶装置４０と接続され、一般に、（１）ファイルを記憶、参照、共有及び確保し、（２）ファイルデータにアクセスし、および（３）ファイル保全性を維持するための方法を含む。それにも拘わらず、ファイルシステム２８とその関連オペレーティングシステムとの間に明確な区別が常にあるわけではなく、オペレーティングシステム内に含まれたファイルシステム２８については特にそうである。したがって、ファイルシステム２８に帰せられるプロセス又はステップのいずれか又はすべては、オペレーティングシステム２６によって代替的に実行され、またその逆も行われる。
【００２１】
不揮発性記憶装置４０は、多数のファイル４４1−４４nを格納し、ＮＴＦＳがファイルシステム２８として役立つ時、データは属性データストリームにおいて編成される。各ファイルに関連付けられたＮＴＦＳファイル制御ブロック（ＦＣＢ）は、それに属するデータストリームを識別する情報を維持する。Ｗｉｎｄｏｗｓ  ＮＴとＮＴＦＳ２８は、文献、Ｉｎｓｉｄｅ  Ｗｉｎｄｏｗｓ  ＮＴ、Ｈｅｌｅｎ  Ｃｕｓｔｅｒ著、Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ（１９９３）、およびＩｎｓｉｄｅ  ｔｈｅ  Ｗｉｎｄｏｗｓ  ＮＴ  Ｆｉｌｅ  Ｓｙｓｔｅｍ、Ｈｅｌｅｎ  Ｃｕｓｔｅｒ著、Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ（１９９４）、において記載されるが、これらの内容は参照してここに編入されている。図１において示され、以下に記載されるように、本発明により、ファイル４４1−４４nの少なくとも幾つかは、暗号化データを格納する。
【００２２】
ＥＦＳドライバ
本発明の１つの態様により、ファイルを暗号化及び解読するために、図２に最良に示されるように、暗号化ファイルシステム（ＥＦＳ）ドライバ４６と、ＥＦＳランタイムライブラリ（ＦＳＲＴＬ４８）４８と、ＥＦＳサービス５０とを備え、暗号化ファイルシステムが、提供されている。ＥＦＳドライバ４６は、ＮＴＦＳ２８の上に置かれ、ＥＦＳサービス５０と通信し、ファイル暗号化キー、解読フィールド（下記）、および他のキー管理サービスを要求する。ＮＴＦＳ２８を介して、ＥＦＳドライバ４６は、この情報をＦＳＲＴＬ４８へ伝達し、下記のように、開く、読み取る、書き込むおよび付加するなどのいろいろなファイルシステム動作を行う。発明により、一旦ファイルが暗号化され、あるいは暗号化ディレクトリにおいて記憶されると、暗号化及び解読プロセスは、ユーザに対して透過的に動作する。
【００２３】
ＮＴＦＳ２８が初期化された時、ＥＦＳドライバ４６は、ＮＴＦＳ２８によって動的にロードされる。ＮＴＦＳ２８は、特定ボリュームに対し、そのボリュームにおけるファイルを作成／開くためのＩ／Ｏ要求パケットを最初に受信する時、または、そのボリュームにおけるファイルに暗号化関連動作を試行するファイル制御動作によりＩ／Ｏ要求パケットを受信する時、ＥＦＳドライバ４６をＮＴＦＳ２８に接続させる（すなわち、層状ドライバチェーンへ挿入される）。ＥＦＳドライバ４６の初期化中、ＥＦＳは、ファイルシステムランタイムコールバックルーチンをＮＴＦＳ２８に登録する。下記のように、ＮＴＦＳ２８は、これらのＦＳＲＴＬ４８ルーチンを使用し、ファイル暗号化関連サービスを得るためにコールバックする。
【００２４】
ＥＦＳドライバ４６は、機密保持サブシステムの一部としてランするユーザモードＥＦＳサービス５０と通信するためのサポートを提供する。初期化中、ＥＦＳドライバ４６は、ＧｅｎｅｒａｔｅＳｅｓｓｉｏｎＫｅｙインターフェースを使用してＥＦＳサービス５０と通信し、ドライバ４６とＥＦＳサービス５０の間で確実に通信するために使用される対称セッションキーを確立する。両者の間で通信されたすべてのデータは、このセッションキーを使用して暗号化される。このセッションキーはまた、ＥＦＳサービス５０からのＩ／Ｏ制御を解読するために、ＦＳＲＴＬ４８への呼び出しによって使用される。
【００２５】
暗号化ファイルのオープン毎に、ＥＦＳドライバ４６は、データ解読及びデータ回復フィールド（図３〜図５、下記）を含むファイルメタデータを渡すことによりＥＦＳサービス５０と通信し、ファイル暗号化キーおよびファイルメタデータへの更新を取り戻す。ファイルメタデータは、ユーザが新キーに変更するので、更新され、あるいは回復エージェントのキーが更新される。ＥＦＳドライバ４６は、この情報をＦＳＲＴＬ４８へ伝達する。
【００２６】
非暗号化テキストファイル／ディレクトリの暗号化又は新暗号化ファイルの作成中、ＥＦＳドライバ４６は、ＥＦＳサービス５０と通信し、新ファイル暗号化キー、および暗号化ファイルに対する暗号化メタデータを得る。ＥＦＳドライバ４６はまた、この情報をＦＳＲＴＬ４８へ伝達する。
【００２７】
ＥＦＳ  ＦＳＲＴＬ
ＦＳＲＴＬ４８は、暗号化ファイル及びディレクトリにおける読み取り、書き込み及び開くなどのファイルシステム２８の各種の動作、ならびにディスクへの読み書きが行われた時、ファイルデータを暗号化、解読及び回復する動作を取り扱うために、ＮＴＦＳ呼び出しを実施するモジュールである。このために、本発明は、ＮＴＦＳ２８とＦＳＲＴＬ４８の間のインターフェースを含む、呼び出しメカニズムを備える。以下により詳細に記載されるように、このインターフェースは、データを暗号化する上記のものを含む、データを変換する適切なライブラリ（およびドライバ）に対して一般的であり、こうして、ＮＴＦＳ２８とＦＳＲＴＬ４８の間のインターフェースは、より正確には、データ変換インターフェース５２として参照される。たとえば、インデックシングドライバは、このインターフェースを使用し、ディスクへのすべての書込みを監視し、これらの書き込みに基づいて、インデックスを発生する。しかし、理解できるように、専用暗号化インターフェースが、代替的に提供されている。
【００２８】
ＥＦＳドライバ４６とＦＳＲＴＬ４８の間の動作は、ＥＦＳ属性データ（解読データ及び回復フィールド）を、ファイル属性として書き込むことと、ＥＦＳサービス５０において計算されたファイル暗号化キーを、オープンファイルのコンテキストにおいてセットされるようにＦＳＲＴＬ４８へ通信することとを含む。それから、このファイルコンテキストは、不揮発性記憶装置２４へ及びからのファイルデータの書き込み及び読み取りにおける透過的な暗号化及び解読のために使用される。
【００２９】
データ変換インターフェース５２は、事実上任意の方法でデータを変換するエンジン又はドライバへインターフェースすることができるが、ここでの目的のためには、インターフェース５２は、データ暗号化を達成するために、ＥＦＳドライバ４６をファイルシステム２８へインターフェースするとして記載される。それにも拘わらず、データ変換インターフェースは、データ暗号化に限定されず、事実上任意の形式のデータ変更を達成するために適切である。しかし、現在、この変換モデルは、少なくとも元の非暗号化テキスト程度しかデータスペースを取らない適当なデータ変換をサポートする。いずれにせよ、ＥＦＳドライバ４６は、これらのコールバックをファイルシステム２８に登録し、これにより、ファイルシステム２８は、適切な時点において登録ＥＦＳコールバック機能を使用して、ユーザが要求するいろいろな暗号化及び解読タスクを実行する。
【００３０】
発明にとって必ずしも必要ではないが、便宜上、ＦＳＲＴＬ４８は、ＥＦＳドライバ４６と共通ファイルにおいて格納される。事実、ＥＦＳドライバ４６とＦＳＲＴＬ４８は単一コンポーネントとして実行されるが、それらは直接には通信せず、代わりに、ＮＴＦＳファイル制御呼び出しメカニズムを使用する。すなわち、ＥＦＳドライバ４６は、ＦＳＲＴＬ４８を有効に呼び出す。ＮＴＦＳ呼び出しメカニズムの使用は、ＮＴＦＳ２８がすべてのファイル動作に参与することを保証し、２人のユーザがロックされたような場合に、各ユーザは他方のファイルの解放を待つというような状態は回避される。
【００３１】
データ変換インターフェース５２は、多数の関数ポインター、またはコールバックを含む。ファイルシステム２８が使用する最初のコールバック、ＦｉｌｅＣｒｅａｔｅコールバックは、登録ＥＦＳ関数に、ストリームが作成又はオープンされていることを通知する。ＥＦＳドライバ４６がこの点において取る作用（たとえば、ファイルが現存ファイルであるならばユーザがアクセスを有するかを判定すること、あるいは新ファイルに対してメタデータストリームを得ること）は、以下でさらに詳細に記載される。
【００３２】
アプリケーションがファイルを開く又は作成する時、Ｉ／Ｏサブシステム５６は、ファイルがあるファイルシステム、例えば、ＮＴＦＳ２８ファイルであるかを判定し、ＮＴＦＳ２８へ要求を伝達する。ＮＴＦＳ２８は、ＥＦＳがファイルに関与するか、例えば、ファイルが暗号化ディレクトリにおいて作成されるか、または、ストリームが作成されもしくは暗号化ファイルへ接続されるか、を判定する。ＮＴＦＳ２８が、ファイルがＥＦＳに関与することを判定し、ＥＦＳドライバ４６がドライバとして登録されたと判断するならば、ＮＴＦＳ２８は、登録ＥＦＳ関数、即ち、ＦｉｌｅＣｒｅａｔｅコールバックを呼び出す。要求が現存ファイル内のファイルオープン要求であるならば、ＦＳＲＴＬ４８は、ファイル属性からファイルメタデータを読み取り、コンテキストブロック（例えば、下記のように、ＥＦＳドライバ４６によって以前に割り当てられた図７のブロック９８1）に記入し、その情報をＥＦＳドライバ４６へ返送する。呼び出しがＮＴＦＳ２８から返る時、ＥＦＳドライバ４６は、メタデータ情報を取得し、ＥＦＳサービス５０と通信し、メタデータからファイル暗号化キー６０を抽出する。それから、この情報は、開かれているファイルについてキーコンテキスト９６をセットする下記の別のＦＳＲＴＬ４８インターフェース、ＦｉｌｅＣｏｎｔｒｏｌにより、ＮＴＦＳ２８へＥＦＳドライバ４６によって戻される。このキーコンテキスト９６は、その後、ファイルが閉じられるまで、ＥＦＳドライバ４６への今後の呼び出しのために、ＮＴＦＳ２８によって保持される。ファイルメタデータが更新されるならば、更新メタデータはまた、ＮＴＦＳコールバックを介して、登録ＥＦＳ関数によって属性へ再書き込みされる。
【００３３】
新ファイルが作成されるならば、ＦｉｌｅＣｒｅａｔｅコールは結果として、新ファイル暗号化キー及びメタデータに対する要求を、コンテキストバッファ９８1に記入するＦＳＲＴＬ４８となる。それから、ＦＳＲＴＬ４８は、コンテキストバッファ９８1をＥＦＳドライバ４６へ返送する。ＥＦＳドライバ４６は、この情報を取得し、ＥＦＳサービス５０と通信し、ＥＦＳサービス５０から新ファイル暗号化キーと新ファイルメタデータを獲得する。ファイル制御コールバック（下記）を使用して、ＥＦＳドライバ４６は、この情報をＦＳＲＴＬ４８へ返し、これにより、ＮｔＯｆｓコールを使用して、ＦＳＲＴＬ４８は、作成されているファイルについてキーコンテキスト９８をセットし、ファイルメタデータを書き込む。ＮｔＯｆｓ  ＡＰＩは、ＮＴＦＳ２８関数コールのセットであり、ＥＦＳドライバ４６はファイルシステム２８を呼び、暗号化メタデータを含むデータストリームを操作することができる。
【００３４】
別のコールバック、ＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿１は、ユーザがファイルの暗号化状態（ＥＦＳ＿ＳＥＴ＿ＥＮＣＲＹＰＴ）を、暗号化又は解読と記してセットしている時、ＥＦＳドライバ４６要求に応答して、ＮＴＦＳ２８によって呼び出される。応答して、ＮＴＦＳ２８は、暗号化ビットをセット又はクリアし、そしてＥＦＳドライバ４６は、必要なキー記憶を生成する。ＥＦＳ＿ＳＥＴ＿ＥＮＣＲＹＰＴはまた、非暗号化テキストファイルの暗号化が開始される時、ＥＦＳサービス５０において生じ、これにより、ファイル状態は、暗号化が完了するまで、他の動作はファイルにおいて許容されないように、修正される。
【００３５】
ＮＴＦＳ２８はまた、ＥＦＳドライバ４６からのいろいろな暗号化ドライバ特定ファイル制御要求により、ＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿２インターフェースを呼び出す。ＮＴＦＳ２８は、ＦＳＲＴＬ４８へコールを単に伝達する以外に、これらのコールバックに関してなにも作用を行わないことに注意せよ。新又は更新ファイルメタデータの書き込みが望まれる時、ＥＦＳフィルタードライバ４６から来るＥＦＳ＿ＳＥＴ＿ＡＴＴＲＩＢＵＴＥと、ＥＦＳドライバ４６またはファイルメタデータを問い合わせるためのユーザモードアプリケーション３０から来るＥＦＳ＿ＧＥＴ＿ＡＴＴＲＩＢＵＴＥとを、ファイル制御要求は含む。情報は、ユーザパブリックキー及び回復エージェントパブリックキー（下記）のリストを含み、ファイル暗号化キーを暗号化するために使用される。別の要求、ＥＦＳ＿ＤＥＣＲＹＰＴ＿ＢＥＧＩＮは、暗号化ファイルの解読を開始する時、ＥＦＳサービス５０から来る。応答して、ファイルの状態は、解読が完了されるまで、他の動作はファイルにおいて許容されないように修正される。ＥＦＳ＿ＤＥＬ＿ＡＴＴＲＩＢＵＴＥは、全暗号化ファイルの解読を終了し、ファイルメタデータ及び関連属性を削除することを望む時、ＥＦＳサービス５０において生ずる要求である。ＥＦＳ＿ＥＮＣＲＹＰＴ＿ＤＯＮＥ要求はまた、ファイル暗号化を良好に完了する時、ＥＦＳサービス５０から来る。ファイル状態は、この時点からの動作を可能にするように修正される。ＥＦＳ＿ＯＶＥＲＷＲＩＴＥ＿ＡＴＴＲＩＢＵＴＥは、暗号化ファイルがそのバックアップフォーマットから復元される時、ＥＦＳサービス５０から来る。ＥＦＳサービス５０は、ファイルにおいて現メタデータを重ね書きするために必要なファイルメタデータを供給する。この要求はまた、ファイルが復元されている間、読み取り又は書き込みが進行しないように、そのファイルに関連付けられたキーコンテキスト９６の削除と関連している。
【００３６】
ＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿２インターフェースはまた、下記のＦＳＣＴＬ＿ＥＮＣＲＹＰＴＩＯＮ＿ＦＳＣＴＬ＿ＩＯに応答して、ファイルシステム２８によって呼び出される。これは、ファイルの状態がＥＦＳドライバ４６の待機状態に対応することを、ＮＴＦＳ２８が認識する時などの、ＥＦＳドライバ４６がＮＴＦＳ２８にＥＦＳドライバ４６（自体）を呼び出させるための手段を備える。
【００３７】
ファイルシステム２８は、暗号化ファイルに対してディスクからデータを読み取った後、および、それをユーザに戻す前に、コールバック、ＡｆｔｅｒＲｅａｄＰｒｏｃｅｓｓを直接に使用する。ＡｆｔｅｒＲｅａｄＰｒｏｃｅｓｓ関数は、このコールバックに応答して、進行中のデータを解読する。読み取り動作は、図２０に関して、以下により詳細に記載される。
【００３８】
逆に、ＢｅｆｏｒｅＷｒｉｔｅＰｒｏｃｅｓｓは、暗号化ファイルに対してデータをディスクに書き込む前に、ファイルシステム２８によって呼び出される。関数は、このコールバックの結果として、データを暗号化する。書き込み動作は、図２１に関して、以下により詳細に記載される。
【００３９】
ＣｌｅａｎＵｐコールバックは、ＮＴＦＳ２８がストリームに関連付けられた資源を解放している時、ファイルシステム２８によって呼び出される。この時、ＥＦＳドライバ４６は、キー及び同等物を格納するように、使用中のメモリ資源を解放する。ＮＴＦＳ２８が、ストリームにおける最後のクローズを受信する時、ＮＴＦＳ２８は、キーコンテキスト９６を含む、このオープンファイルの情報を得るためにメモリにおいて格納されたすべてのものを解放するために、その標準動作を行う。さらに、ファイルシステム２８は、コンテキストブロック９８によりＥＦＳドライバ４６を呼び出し、このファイル、例えばコンテキストブロック９８、に対して消費しているメモリを解放する機会を与える。
【００４０】
ＡｔｔａｃｈＶｏｌｕｍｅコールバックは、上記のように（暗号化に係わる最初のユーザの動作中）ファイルシステム２８によって呼び出される。応答して、ＥＦＳドライバ４６は、Ｉ／Ｏサブシステムに、そのボリュームを表わす置対象に接続したい旨を通知し、これにより、そのボリュームに対して論理的にＮＴＦＳ２８の上に置かれ、その結果、Ｉ／Ｏサブシステムは、ＥＦＳドライバ４６へ情報を最初に伝達する。ＤｉｓｍｏｕｎｔＶｏｌｕｍｅは、ユーザがドライブを取り出し又は除去することを望むか、あるいはシステムが運転停止されているために、ボリュームが取り外されている時、ファイルシステム２８によって呼び出される。ＤｉｓｍｏｕｎｔＶｏｌｕｍｅコールに応答して、暗号化ドライバは、ＡｔｔａｃｈＶｏｌｕｍｅコールバック中にり当てられたメモリ資源を解放する。しかし、ＥＦＳドライバ４６は、通常、分離され、ボリューム取り外しをＩ／Ｏサブシステムによって通知された時、資源を解放するが、ＤｉｓｍｏｕｎｔＶｏｌｕｍｅコールバックが提供され、融通性をさらに高めていることに注意されたい。
【００４１】
ＥＦＳサービス
ＥＦＳサービス５０は、Ｗｉｎｄｏｗｓ  ＮＴ機密保持サブシステムの一部である。図２においてＥＦＳサービス５０／ドライバ通信５４として表わされたように、ＥＦＳサービス５０は、Ｌｏｃａｌ  Ｓｅｃｕｒｉｔｙ  Ａｕｔｈｏｒｉｔｙ（ＬＳＡ）とカーネルモード機密保持参照モニタの間の現局所手順呼び出し通信ポートを使用し、ＥＦＳドライバ４６と通信する。ユーザモードにおいて、ＥＦＳサービス５０は、マイクロソフトの暗号法ＡＰＩ、クリプトＡＰＩ５８とインターフェースし、ファイル暗号化キーを提供し、解読フィールド情報を生成する。
【００４２】
ＥＦＳサービス５０はまた、暗号化、解読、回復のためのプログラミングインターフェースであるＷｉｎ３２  ＡＰＩ３２のためのサポートを提供し、暗号化ファイルをインポート及びエクスポートするためのサポートを提供する。暗号化ファイルのインポート及びエクスポートにより、ユーザは、下記のように、バックアップ、復元のような動作、および一般ファイル転送目的のために、ファイルを不透過（暗号化）データに変換することができる。Ｗｉｎ３２  ＡＰＩ３２は、非暗号化テキストファイルを暗号化し、暗号文ファイルの解読又は回復、および（最初に解読することのない）暗号化ファイルのインポート及びエクスポートのためのプログラミングインターフェースを提供する。これらのＡＰＩ３２は、標準システムＤＬＬ、ａｄｖａｐｉ３２．ｄｌｌにおいてサポートされる。
【００４３】
ＥＦＳサービス５０は、セッションキーを生成し、ＥＦＳドライバ４６およびＦＳＲＴＬ４８とそれを交換することを含む、多数のサービスを提供する。ＥＦＳドライバ４６の要求に基づいて、ＥＦＳサービス５０は、（ＣｒｙｐｔｏＡＰＩを使用して）強力なセッションキーを暗号法により生成し、それをドライバおよびＦＳＲＴＬ４８へ通信する。ＥＦＳサービス５０はまた、ＥＦＳに対して定義されたユーザ及び回復エージェントのパブリックキーを使用して、ファイルに格納されたフィールド（図３〜図５を参照して以下に記載される、データ解読フィールド又はＤＤＦ、およびデータ回復フィールド又はＤＲＦ）においてファイル暗号化キーを生成する。ＥＦＳドライバ４６が新ファイル暗号化キーを要求する時、ＥＦＳサービス５０は、ＣｒｙｐｔｏＡＰＩを使用して、この情報を生成し、それをＥＦＳドライバ４６に戻す。
【００４４】
ＥＦＳサービス５０はまた、ファイル暗号化キーを抽出する。すなわち、ＥＦＳドライバ４６がこの動作を要求する時、ＥＦＳドライバ４６は、ＤＤＦ及びＤＲＦキーフィールドを含む、ファイルメタデータを供給する。その情報に基づいて、ＥＦＳサービス５０は、ＤＤＦおよび（必要ならば）ＤＲＦキーフィールドを順次に探索し、ユーザのキーの名称を抽出し、クリプトＡＰＩプロバイダー５８を介してそのプライベート部分にアクセスする。うまくいったならば、（以下により詳細に記載されるように）、それは、暗号化されたファイル暗号化キーを解読のためにそのプロバイダーに伝達する。サービスは、解読が（同様に以下に記載されるように）正しいことを確かめ、また、ファイルメタデータにおいて使用されたキーが最新であることを確かめる。キーが最新でないならば、サービスは、メタデータ（ＤＤＦ及び／又はＤＲＦ）を再生成し、抽出されたファイル暗号化キーとメタデータを、ＥＦＳドライバ４６に戻す。
【００４５】
ＥＦＳドライバ４６がＮＴＦＳ２８によってロードされる時、それは、最初に、その構造を初期化し、メモリが常に利用可能であることを保証するために、あるスペースを確保する。その後、ＥＦＳドライバ４６は、ＮＴＦＳ２８に関して登録される。最後に、ドライバと同期するために、ＥＦＳドライバ４６は、新イベントを作成しようとする。イベントがうまく作成されると、これは、ＥＦＳサービス５０が初期化されず、ＥＦＳドライバ４６が最初にロードされたことを示す。うまくいったならば、ＥＦＳドライバ４６は、スレッドを作成し、信号が送られるのをイベントにおいて待つ。後に、イベントが送られる、すなわち、ＥＦＳサービス５０が通信するためのレディ状態になる時、ＥＦＳドライバ４６は、セッションキーを得るために、ＥＦＳサービス５０を呼び出す。セッションキーはいったんＥＦＳサービス５０からＥＦＳドライバ４６へ転送され、ＥＦＳサービス５０とＥＦＳドライバ４６は同期化される。イベントがうまく作成されなかったならば、それは、通常、ＥＦＳサービス５０がすでに初期化されているためであり、このイベントでは、ＥＦＳドライバ４６は、セッションキーを得るために、単に呼び出しを行うことに注意されたい。
【００４６】
ＥＦＳサービス５０が最初にロードされた状況において、ＥＦＳサービス５０は、新イベントを作成しようとする。イベントがうまく作成されるならば、ＥＦＳドライバ４６は、初期化されていない。ＥＦＳサービス５０は、イベントを待つことなく、セッションキーを生成する。後に、ＥＦＳドライバ４６がロードされる時、ＥＦＳサービス５０は、セッションキーを提供するために、ＥＦＳドライバ４６によって呼び出される。ＥＦＳサービス５０がセッションキーを提供する時、ＥＦＳサービス５０は、ＥＦＳサービス５０によって以前に作成されたイベントを閉じ、そしてＥＦＳサービス５０とＥＦＳドライバ４６は同期される。イベントがうまく作成されなかったならば、それは、通常、ＥＦＳドライバ４６がすでに初期化されたためであり、このイベントでは、ＥＦＳサービス５０は、代わりに、イベントを開き、ＥＦＳサービス５０がレディ状態であることをＥＦＳドライバ４６に知らせるようにイベントを送ることに注意されたい。その後、ＥＦＳサービス５０は、ＥＦＳドライバ４６によってセッションキーを要求され、同期が完了する。
【００４７】
ＷＩＮ３２システムＡＰＩ
とくに図２２〜図２３に関して以下により詳細に記載されるように、ＥＦＳサービス５０はまた、多数の他のユーザモードインターフェースを提供する。これらのインターフェースは、ＷＩＮ３２システムＡＰＩと協働し、ユーザは、現存する非暗号化テキストファイルを暗号化ファイルへ変換し、暗号化ファイルを非暗号化テキストファイルへ変換し、バックアップ及び復元メカニズムを提供する等の、種々の動作を行うことができる。例示として、ＷＩＮ３２インターフェース３２は、ＥＦＳサービス５０と協働し、ＥＦＳの機能性を出し、ファイル暗号化（図２２）を行うためにＥＦＳサービス５０によって提供されるインターフェース中にコールするラッパーであるＥｎｃｒｙｐｔＦｉｌｅを含む。別のインターフェース、ＤｅｃｒｙｐｔＦｉｌｅは、ファイルの解読／回復（図２３）を行うために、ＥＦＳサービス５０によって提供されるインターフェースに同様にコールするラッパーである。
【００４８】
バックアップ／復元メカニズムはまた、システムＡＰＩ中にコールされ、ユーザとバックアップオペレータは、解読なしに暗号化ファイルをバックアップすることができる。このために、ＯｐｅｎＲａｗＦｉｌｅインターフェースにより、ユーザは、読み取りアクセスなしに、かつ、透過的な読み取り及び書込みを行うためのファイル暗号化キーをセットすることなく、暗号化ファイルを開くことができる。これらの動作に対して、ＮＴＦＳ２８は、アクセスレベルを認識するが、このファイルに対するキーを探し出すために暗号化ドライバ４６を呼び出さず、また、読み取りを解読し書込みを暗号化することもない。このインターフェースを介して開かれたファイルにおいて許される動作は、ファイル制御のみである。こうして、ＲｅａｄＲａｗＦｉｌｅインターフェースにより、ユーザは、バックアップされ後に復元できる連続的な不透過ストリームとして、暗号化メタデータを含むすべてのデータを、ファイルから読み取ることができる。ＷｒｉｔｅＲａｗＦｉｌｅインターフェースにより、ユーザは、暗号化ファイルを再作成するために、暗号化メタデータを含むすべてのデータを、そのバックアップからファイルに書き込むことができる。最後に、ＣｌｏｓｅＲａｗＦｉｌｅが、提供され、ユーザは、ＯｐｅｎＲａｗＦｉｌｅによって開かれた生ファイルを閉じることができる。
【００４９】
ＦｉｌｅＣｏｎｔｒｏｌインターフェースにより、バックアップ及び復元メカニズムを提供するＷｉｎ３２ＡＰＩは、生の暗号化データを読み書きすることができる。生データの読み書きは、ＮＴＦＳ２８とディスク（記憶装置）の間で直接的であることに注意されたい。ＥＦＳサービス５０とＥＦＳドライバ４６は、共通セッションキーを共有するので、ＥＦＳは連繋され、すべてのファイル制御は、（下記のように）確かめられる必要がある。ファイルをバックアップするために、Ｗｉｎ３２ＡＰＩは、ＥＦＳファイル制御を介してＥＦＳメタデータを読み取り、ＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿２へ変換され、ＥＦＳストリームが戻される。その後、ＮＴＦＳ２８ファイル制御は、実ファイルデータを読み取るために呼び出され、データは不透過ストリームへパッケージされ、書き出される。ファイルを（漸次的に）復元するために、逆プロセスが行われる。ＥＦＳファイル制御は、第１ストリームを識別するために呼び出され、別のＥＦＳファイル制御は、生データを書き戻すために呼び出される。
【００５０】
データ暗号化
図３〜図５において概念的に表わされているように、本発明は、パブリックキーベース体系を使用して、データ暗号化及び解読を実施する。このために、ファイルデータは、ファイル暗号化キー（ＦＥＫ）６０（図３）による高速対称アルゴリズムを使用して、暗号化される。ＦＥＫ６０は、選択アルゴリズムによって必要とされるか、あるいはそうでなければ、アルゴリズムが可変長キーをサポートするならば必要とされる、ある長さのランダムに発生されたキーである。図３において表わされるように、乱数発生器６２は、ＦＥＫ６０を生成する。ＦＥＫ６０を使用してファイルデータを暗号化するために、ファイルの非暗号化テキスト６４は、適切なアルゴリズム（例えば、ＤＥＳ）を使用して、ファイル暗号化メカニズム６６によって暗号化され、暗号化ファイル７０に暗号化テキスト６８として書き込まれる。
【００５１】
本発明の別の態様により、図３に示されたように、ランダムに発生されたＦＥＫ６０は、少なくとも１人のユーザのパブリックキー７２によりそれ自体、暗号化され、データ解読フィールド（ＤＤＦ）７４と呼ばれる特殊なＥＦＳ属性で暗号化ファイル７０に格納される。適切な暗号化アルゴリズム（例えば、ＲＳＡ）を使用して、データ解読フィールド発生器７６は、キー暗号化を行う。パブリックキーベース体系により、ユーザのキーペアのプライベート部分は、解読中、ただ使用される。すなわち、データ解読フィールド７４における暗号化ＦＥＫ６０は、キーペアのプライベート部分を使用して、解読される。ユーザキーペアのプライベート部分８４（図４）は、スマートカード及び／又は他の確実な記憶装置におけるように、別個の記憶場所に安全に記憶される。暗号化はまた、パスワード導出キーなどの、対称アルゴリズムを使用して行われるが、実行可能であるとしても、パスワードベース体系が辞書攻撃等のために本質的に弱いために、ＥＦＳは、好ましくは、そのような暗号化をサポートしないことに注意されたい。
【００５２】
本発明の１つの態様により、図３において表わされるように、ＦＥＫ６０はまた、１つ以上の回復パブリックキー７８を使用して、暗号化される。回復キー暗号化パブリックキー７８は、下記の回復ポリシーによって指定されるように、回復エージェントとして知られた信頼ある人に属する。ユーザのパブリックキーを使用するＦＥＫの暗号化と同様に、各回復キーペアのパブリック部分は、データ回復フィールド発生器８０を使用して（例えば、ユーザのパブリックキーでＦＥＫ６０を暗号化するために使用されるものと同一のアルゴリズムである必要はないが、ＲＳＡなどの適切な暗号化アルゴリズムを使用して）、ＦＥＫ６０を暗号化するために使用される。暗号化ＦＥＫのこのリストは、データ回復フィールド（ＤＲＦ）８２と呼ばれる特殊なＥＦＳ属性中にファイル７０といっしょに同様に格納される。こうして、回復キーペアのパブリック部分のみが、ＤＲＦ８２においてＦＥＫ６０の暗号化のために必要とされる。ユーザは任意の時点においてファイルを暗号化することを望むことから、適正な動作を容易にするために、これらのパブリック回復キーは、正常なファイルシステム２８の動作のためにＥＦＳシステムにおいて常時存在する。回復自体は、ユーザが組織を離れ、キーを失う等の時のみ必要とされるまれな動作であると想定される。結果として、回復エージェントはまた、スマートカード、フロッピーディスク、及び／又は他の確実な記憶装置においてキーのプライベート部分９０（図５）を記憶することができる。
【００５３】
本発明により、暗号化ファイルシステムアーキテクチャは、特定の暗号化アルゴリズムに限定されず、むしろ十分にアルゴリズム機敏性があり、いろいろな暗号化フェーズに対していずれかの暗号化アルゴリズムを使用する。結果として、本発明の暗号化ファイルシステムは、アルゴリズムが技術的に進歩するような場合に、ますます改良される暗号化アルゴリズムの使用を可能にする。さらに、ユーザは、暗号化及び解読の速度に対して（すなわち、より安全なアルゴリズムは一般により低速である）機密保持の程度を可変にしたアルゴリズム（すなわち、ユーザがその情報がどのくらい極秘か考えること基づいて）を選択することを、利用可能なアルゴリズムから選定することができる。このように、上記の記述において、ＤＥＳは、ファイルデータを暗号化するために使用される１つのアルゴリズムであるが、ＲＳＡは、ＦＥＫを暗号化するために使用される。
【００５４】
データ解読
図４は、ユーザ解読プロセスを概念的に示す。ユーザのプライベートキー８４（または回復エージェントのプライベートキー９０）は、データ解読フィールド７４において格納された対応する暗号化されたＦＥＫ項目を解読するために使用される。キーの解読を達成するために、ＤＤＦ７４（および必要ならば、ＤＲＦ８２）における各暗号化ＦＥＫ項目、およびユーザ又は回復エージェントのプライベートキーは、ＦＥＫ６０を適正に解読する一致が見いだされるまで、（ＥＦＳサービス５０における）抽出メカニズム８６へ対話式に送られる。そこから、ＦＥＫ６０は、暗号化テキスト６８を非暗号化テキスト６４に解読するために公知の方法で適切に対応する解読アルゴリズムを使用するファイル解読メカニズム８８へ送られる。多様な解読アルゴリズムが利用可能である時、データ解読フィールドは、ファイル解読メカニズム８８が正しい解読アルゴリズムを使用するように、暗号化アルゴリズムについての情報を記憶することに注意されたい。いくつかの各ファイルは、それ自身のアルゴリズムを有するが、唯一の暗号化アルゴリズムは、ファイル毎に使用される。
【００５５】
ファイルが開いている間に、解読されたＦＥＫ６０は、ファイル７０に関連してファイルシステム２８によって保存される。図６に示されたように、ＮＴＦＳ２８により、ストリーム制御ブロック９４は、各オープンファイルに対するファイル情報を維持し、そして暗号化ファイルに対応する各ストリーム制御ブロック（例えば、９４1）は、キーコンテキスト（例えば、９６1）を指している。キーコンテキスト９６は、それぞれ、ディスクへの書き込み及び読み取り中、ファイルを暗号化及び解読するために必要な情報を維持する。以下にさらに詳細に記載されるように、ＦＥＫ６０は、ブロック毎のベースでファイルデータ読み取りを解読するために使用される。すなわち、大きなファイルへのランダムアクセスは、そのファイルに対してディスクから読み取られた特定ブロックのみを解読する。全ファイルは、必ずしも解読されるとは限らない。
【００５６】
ファイル回復
図５は、回復プロセスを概念的に示す。回復プロセスは、ＤＲＦ８２においてＦＥＫ６０を解読するために、プロセスが回復エージェントのプライベートキー９０を使用することを除いて、ユーザ解読と同様である。結果的に、ＤＤＦ７４において一致は見いだされず、こうして、一致に対する探索は、ＤＲＦ８２へと継続する。回復を始めるために、回復エージェントは、プライベートキー９０を提出し、そしてデータ回復フィールド抽出メカニズム９２（好ましくは、上記の図４のデータ解読フィールド抽出メカニズム８６と同一）は、ＤＤＦ７４を探索するために、エージェントのプライベートキー９０を対話式に使用する。その時、それは回復エージェントであり、ユーザではないために、ＤＤＦ７４において一致は見いだされず、こうして、抽出メカニズムは、ＤＲＦ８２を探索し続ける。
【００５７】
正常なユーザオープンであるか、又は回復のためのオープンであるかに拘わらず、現コンテキストにおいてキーがいったん見いだされると（クリプトＡＰＩ５８は各ユーザに対してキーのセットを維持する）、キーは、そのキーで解読された既知情報とそれを比較することにより、確かめられる。さらに詳細には、暗号化の時点において、ユーザのパブリックキーは、ファイルのＦＥＫに付加され、その後、既知情報としてＦＥＫ６０により暗号化される。見いだされたキーが、記憶情報を解読し、既知情報に等しかったとするならば、キーが確かめられる。この体系は、強力な暗号化技術を提供するが、ファイルを回復する能力を、多数の可能な回復エージェントの１人に与え、これにより、回復手順を実施する際の冗長性と融通性を組織に提供する。
【００５８】
ＥＦＳは、こうして、「回復ポリシー」と呼ばれる、組み込みデータ回復サポートを備えている。好ましいシステムは、回復キーのコンフィギュレーションを実施し、システムが１つ以上の回復キーで構成される時のみ、使用可能であるように意図的に限定される。ファイル回復動作は、ユーザ又は他の回復エージェントのプライベートキーではなく、ランダムに発生されたファイル暗号化キー６０のみを露呈させる。理解できるように、これは、従業員が組織を去った又はキーを失った後、従業員によって暗号化されたデータを、組織が回復する必要がある大部分のビジネス環境にとって理想的である。
【００５９】
また、ＥＦＳポリシーとしても公知な回復ポリシーは、Ｗｉｎｄｏｗｓ  ＮＴドメインのドメインコントローラにおいて規定され、これにより、ポリシーは、そのドメインにおけるすべてのマシンにおいて施行される。ポリシーは、回復エージェントのパブリックキーを含む。結果として、回復ポリシーは、ドメイン管理者の制御下にだけあり、これにより、データの回復者を制御する。付加的機能として、家庭環境においてスタンドアロン型Ｗｉｎｄｏｗｓ  ＮＴワークステーションにおいて暗号化機能を使用できるようにするために、ＥＦＳは、回復キーを自動的に生成し、マシンキーとしてそれらを保存し、これにより、平均的なユーザに対する管理オーバーヘッドを縮小する。
【００６０】
ドメインにおいて、回復ポリシーは、ドメインにおけるマシンの各々へ送信され、これにより、接続されていない時さえも、ローカルマシンは、ローカルな機密保持権限ＬＳＡにおいてポリシーを維持する。このようにして、ＥＦＳは、接続されていない時、ファイルを暗号化するために動作する。マシンがドメインをつなぐ毎に、あるいは回復ポリシーが変化するならば、ポリシーは、接続時に、ドメイン内のマシンへ伝搬される。さらに、ファイルが開かれる毎に、そのファイルに対するメタデータは、回復ポリシーに対して比較され、回復ポリシーが変化したかを調べ、そうならば、メタデータは、新ユーザ及び／又は回復エージェントのパブリックキー情報により暗号化されたＦＥＫで更新される。ハッシュ（ＭＤ５）を含む、保護は、回復ポリシーが悪意のユーザ等によって変更されないことを保証するために使用される。
【００６１】
たとえば、悪意のユーザは、ＤＲＦ８２を変更することにより、ファイルを回復不能にしたがっているかもしれない。これを検出するために、ＤＲＦ８２の部分を使用して、暗号法ハッシュ（ＭＤ５）が作成され、ファイルのＦＥＫ６０を付され、ＤＲＦ８２に格納される。後に、ファイルが開かれ、ＦＥＫ６０が獲得される時、その部分は、ＦＥＫ６０で解読され、ＤＲＦ８２において格納された情報が一致するかを調べる。そうならば、格納された回復ポリシーは適正であり、そうでなければ、回復ポリシーは、ドメインの現回復ポリシーと置き換えられる。
【００６２】
マシンがドメインの一部でないならば、それはなお、ローカルの回復ポリシーを有するが、回復キーは、上記のようにマシン毎に発生され、かつ保持される。このようにして、ＥＦＳの下で暗号化されたすべてのファイルは、常に、ある回復ポリシーを有する。マシンが、後に、ドメインの一部になるならば、ローカルの回復ポリシーは、一掃され、ドメインポリシーと置き換えられる。
【００６３】
一般動作
発明の動作の説明に戻り、図１０の流れ図から始めると、アプリケーション３０が暗号化ファイルを作成する又は開くことを望む時、アプリケーション３０は、まず、適切なＡＰＩ３２を呼び出し、新ファイルが、暗号化ディレクトリにおいて作成され、または暗号化ファイルが開かれることを要求する。
【００６４】
図１０に示すように、いったん作成又はオープン要求が受信されると、Ｉ／Ｏサブシステム５６は、ステップ１０００〜１００２において、適切なファイルシステム、例えばＮＴＦＳ２８、へＩＲＰとして要求を伝達するように準備する。しかし、上記のように、ＩＲＰは、まず、図１１のステップ１１００においてＥＦＳドライバ４６によって受信され、ＩＲＰはオープン／作成動作を指定するものとして認識される。
【００６５】
ＥＦＳドライバ４６は、図１１に示されたように、前処理を行うことにより、ＥＦＳＣｒｅａｔｅＦｉｌｅ動作を始める。図１１のステップ１１０２によって表わされるように、ＥＦＳドライバ４６は、このファイルに対してＥＦＳコンテキストブロック９８1を割り当て、ＥＦＳコンテキストブロックチェーン９８（図７）へそれを追加する。ＥＦＳドライバ４６は、この時点において、ファイルがすでに暗号化されているかまたは暗号化されることになっているかどうかを判断できないために、ファイルは暗号化されていないとしても、ＥＦＳコンテキストブロック９８1は、各新ファイルに対して作成されることに注意されたい。ＥＦＳコンテキストブロック９８1は、「処理は必要でない」で初期化されるステータス情報を含み、ＩＲＰポインターは、現ファイルオブジェクトを指し、ＥＦＳメタデータストリームはＮＵＬＬに初期化される。最後に、ステップ１１０４において、ＩＲＰはＮＴＦＳ２８に伝達される。
【００６６】
図１０のステップ１００６において示されたように、ＮＴＦＳ２８がＥＦＳドライバ４６からＩＲＰを受信し、それをＮＴＦＳ２８作成パケットとして認識する時、ＮＴＦＳ２８は、作成／オープンＩＲＰを取り扱う。図１２は、ＮＴＦＳ２８がＩＲＰをいかに取り扱うかを一般的に示す。まず、ステップ１２００によって表わされるように、ＩＲＰにおける情報は、現ストリームが開かれるか、またはファイル／ディレクトリにおける新ストリームが作成されるかを判定するために検査される。現ストリームが開かれるならば、ＮＴＦＳ２８は、ステップ１２０２においてストリームを開く。ステップ１２０４において、ＮＴＦＳ２８は、ファイル又はそのディレクトリが暗号化されるかを判定し、もしそうならば、ステップ１２０８において、図１３を参照して以下に記載されたＦＳＲＴＬ４８オープン／作成コールアウトを呼び出す。
【００６７】
逆に、新ストリームがステップ１２００によって判定されたように作成されたならば、ＮＴＦＳ２８は、次に、ステップ１２０６において、親ディレクトリが暗号化されるかを判定する。親が暗号化されるならば、ステップ１２０８において、ＮＴＦＳ２８は、以下に記載されるように、ＦＳＲＴＬ４８オープン／作成コールアウトを呼び出す。親が暗号化される（ステップ１２０６）ことも、またファイル又はディレクトリが暗号化される（ステップ１２０４）ことも判定されないならば、ＮＴＦＳ２８は、ＦＳＲＴＬ４８コールアウトを行わず、これにより、ＮＴＦＳ２８は、ＥＦＳドライバ４６へ戻る前に、ステップ１２１０までに必要とするタスクを単に行う。
【００６８】
ＥＦＳ作成／オープンＦＳＲＴＬ４８コールアウトのステップは、図１３において一般に表現され、この場合、ＦＳＲＴＬ４８コールアウトは、ユーザによって要求されたアクセスの形式を最初に検査することから始める（ステップ１３００）。ファイル又はディレクトリにおける現ストリームが、読み取り、書き込み、付加又は実行（Ｒ／Ｗ／Ａ／Ｅ）アクセスなしに開かれるならば、呼び出しは、単純に良好とされ、暗号化／解読は必要とされない。たとえば、ユーザは、属性を読み取ることを望み、そして属性は暗号化されない。そうでなければ、ステップ１３０２において、ＦＳＲＴＬ４８は、（図１１のステップ１１０２において割り当てられた）このファイルに対応する適切なファイルオブジェクトに対してＥＦＳコンテキストチェーン９８を探索する。作成／オープンコールアウトは、以下に提示されたように、ファイル／ディレクトリの形式に基づいて、種々の動作を行う。
【００６９】
ファイルの形式が現ファイル（ステップ１３０４）であるならば、新ストリームが作成されたか、または現ストリームが開かれたために、ＦＳＲＴＬ４８が呼び出された。そうならば、ユーザは、確認される必要があり、そしてコールアウトプロセスは、図１４のステップ１４００へ継続する。ステップ１４００において、ファイルからのＥＦＳメタデータは、（ＮｔＯｆｓ）ＡＰＩを使用して、読み取られる。それから、ステップ１４０２において、読み取られたメタデータは、コンテキストブロック９８1においてセットされ、ブロックにおけるステータスは、「ユーザ確認が必要」を指示するために変更される。その後、キーコンテキスト９６が、ステップ１４０４においてチェックされ、そしてＮＴＦＳキーコンテキスト９６がＮＵＬＬであるならば、キーが必要とされる。キーコンテキスト９６がＮＵＬＬであるならば（ステップ１４０４）、このファイルは、読み取られず、こうして、解読ファイルデータがキャッシュメモリに存在する可能性はない。結果として、コンテキストブロックが、ステップ１４０６において「キャッシュチェックは必要とされない」を指示するためにセットされる。最後に、新ストリームがステップ１４０８によって判定されたように作成されたならば、コンテキストブロック９８1が、ステップ１４１０において「暗号化ビットをオンにする」を指示するためにセットされる。
【００７０】
代わりに、ファイルの形式が新ファイル（図１３のステップ１３０６）であるならば、新ＦＥＫおよびＥＦＳメタデータが必要とされる。最初に、ステップ１３０８において、ＥＦＳメタデータが、ＮｔＯｆｓ  ＡＰＩを使用して、親ディレクトリから読み取られる。ステップ１３１０は、コンテキストブロック９８1において読み取られたメタデータをセットし、そのブロックにおけるステータスを、「新ファイルＥｆｓが必要とされる」、「暗号化ビットをオンにする（ステップ１３１４）」および「キャッシュチェックは必要とされない（ステップ１３１２）」に変更する。
【００７１】
代わりに、ファイルオブジェクト形式が新ディレクトリ（ステップ１３２０）を指示するならば、新ＥＦＳメタデータのみが必要とされる。現在、ディレクトリにおけるストリームは暗号化されていないために、この場合においてＦＥＫはない。したがって、親ディレクトリからのＥＦＳメタデータは、（ＮｔＯｆｓ  ＡＰＩを使用して）ステップ１３２２において読み取られる。それから、ステップ１３２４において、たったいま読み取られたメタデータが、コンテキストブロック９８1においてセットされ、そしてそのブロックにおけるステータスは、「新ディレクトリＥｆｓが必要とされる」、「キャッシュチェックは必要とされない」（ステップ１３２６）、および「暗号化ビットをオンにする」（ステップ１３２８）に変更される。
【００７２】
最後に、形式が現ディレクトリ（ステップ１３３２）を表わすならば、新ストリームが作成されたか、または現ストリームが開かれた。現在、ディレクトリデータストリームは暗号化されていないために、作用はなにも行われない。しかし、ディレクトリストリームはまた、本発明の暗号化ファイルシステムを使用して、ファイルデータストリームが暗号化されるのと同様にして暗号化されることは、容易に理解される。
【００７３】
図１２において示されたように、ステップ１２１０において、コールアウトは、ＮＴＦＳ２８へ復帰し、これにより、ＮＴＦＳ２８は、それ自身の動作のいずれかを行う。ファイル／作成プロセスは、後処理のためにステップ１０１０（図１０）のＥＦＳフィルタードライバ４６へ復帰する。
【００７４】
ＥＦＳ作成／オープンファイル後処理プロセスは、図１５〜図１９において表わされる。図１５の最初のステップ１５００において、コンテキストブロック９８1が、「キャッシュチェックは必要とされない」ステータスに対して評価される。キャッシュチェックが必要とされるならば、プロセスはステップ１５０２に分岐し、ここで、呼び出し元の機密保持コンテキストが、ＥＦＳストリーム中に記憶されたファイルに対するＥＦＳ  ＩＤとともに、ＥＦＳキャッシュによって使用され、このファイルが最近、ユーザによって良好に開かれたかチェックされる。そうならば、キャッシュは適切な情報をすでに含むために、呼び出しは、良好である。
【００７５】
キャッシュにおいて、そうでないならば、ステップ１５０４において、読み取りデータ、書き込みデータ、付加データまたは実行アクセスが必要とされるかがチェックされる。これらのいずれも要求されず、新ストリームがステップ１５０６において判定されたように作成され、コンテキストブロック９８1が「暗号化ビットをオンにする」ステータス（ステップ１５０８）を指示するならば、ＥＦＳデータストリームは必要とされず、解放される。ストリームにおける暗号化ビットのみが、オンにされる必要があり、ステップ１５１０において行われる。後処理は、完了し、全プロセスは、図１０のステップ１０１２へ復帰する。
【００７６】
しかし、図１５に関して識別された上記の状況のいずれも満足されないならば、異なる動作が、図１６のステップ１６００から検査されるステータス情報に基づいて行われる必要がある。まず、コンテキストブロック９０1におけるステータスが、ユーザ確認がステップ１６００において必要とされることを指示するならば、ＥＦＳドライバ４６は、ステップ１６０２において（ＩＲＰにおいて提供された）機密保持コンテキストの役をする、ステップ１６０４において、ＥＦＳサービス５０を呼び出し、ＦＥＫを要求するためにＥＦＳメタデータを伝達する。
【００７７】
ステップ１６０６において、ＥＦＳサービス５０は、コンテキストの役をすることにより、呼び出しに応答し、ＥＦＳメタデータにおける情報を使用して、ＦＥＫを解読するために、ユーザのプライベートキーを調べる。ＥＦＳサービス５０はまた、ユーザのキーが更新されたか、または、回復キーがステップ１６０８によって判定されたように更新されるならば、ＥＦＳメタデータを更新する（ステップ１６１０）。いずれにせよ、ステップ１６１２において、ＥＦＳサービス５０は、ＦＥＫ６０の保全性を確認し、すべての情報をＥＦＳドライバ４６に戻す。さらに詳細には、保全性を確かめるために、キー保全性ブロックが、次のように構成される。
【００７８】
［Ｆ（ＦＥＫ，Ｐｕｋ），ＦＥＫ］Ｐｕｋ
【００７９】
ここで、
Ｆ（）は、適切なハッシュ関数である（好ましくはＭＤ５）。
Ｐｕｋは、ユーザのパブリックキーである。そして
［］Ｐｕｋは、ユーザのパブリックキーによる暗号化を表記する。
【００８０】
結果的に、妥当なＦＥＫがユーザのパブリックキーで解読されたと考えられる時、上記のブロックが本情報により計算され、ファイルにおいて格納されたブロックと比較される。それらが一致するならば、キー保全性が確認される。
【００８１】
代替的に、ユーザ確認が必要とされた（ステップ１６００）ことをステータスが指示しないが、代わりに、新ファイルＦＥＫが必要とされたことを指示したならば、ステップ１６１４は、図１７のステップ１７００へ分岐する。ステップ１７００において、ＥＦＳドライバ４６は、ＩＲＰにおける保護コンテキストの役をし、そしてステップ１７０２において、ＥＦＳサービス５０を呼び出し、親ディレクトリのＥＦＳメタデータを伝達し、新ＦＥＫおよびＥＦＳメタデータを要求する。ステップ１７０４において、ＥＦＳサービス５０は、コンテキストの役をし、ランダムＦＥＫ６０を生成する。ユーザがステップ１７０６によって判定されたように、キーを有さないならば、ステップ１７０８において、ＥＦＳサービス５０は、ユーザのためのキーペアを自動生成する。最後に、ステップ１７１０は、ユーザのパブリックキーおよび回復エージェントのパブリックキーの下で暗号化されたＦＥＫ６０により、ＥＦＳメタデータストリームを作成する。ＥＦＳサービス５０はまた、親ディレクトリへのアクセスを許容されたユーザがまたファイルへのアクセスを有する（ＮＴＦＳ２８のアクセス制御リストはそのようなアクセスを許容するとする）ように、親ディレクトリのＥＦＳメタデータにおけるすべてのパブリックキーを使用して、ＦＥＫ６０を暗号化する。
【００８２】
ステップ１６００もまた１６１４も満足されなかったならば、後処理は、ステップ１６１６へ分岐し、ＥＦＳ分岐は、新ディレクトリＦＥＫが必要とされることを指示したかを判定する。そうならば、後処理は、図１８のステップ１８００へ分岐し、ここで、ＥＦＳドライバ４６は、ＩＲＰにおける保護コンテキストの役をする。ステップ１８０２は、ＥＦＳサービス５０を呼び出し、親ディレクトリのＥＦＳメタデータを伝達し、新ＥＦＳメタデータを要求する。ディレクトリストリームはこの時点において暗号化されていないために、ＦＥＫは必要とされないことに注意されたい。しかし、将来には、ディレクトリストリームはまた、ファイルストリームが本発明により暗号化されると同様にして暗号化される。
【００８３】
いずれにせよ、ステップ１８０４において、ＥＦＳサービス５０は、コンテキストの役をし、空きＦＥＫを使用して、ＥＦＳメタデータストリームを作成する。ステップ１７０６は、ユーザがキーを有さないかをチェックし、有さないならば、ステップ１７０８において、ＥＦＳサービス５０は、ユーザのためのキーペアを自動生成する。その後、ステップ１８１０において、空きＦＥＫは、ユーザのパブリックキーと回復エージェントのパブリックキーの下で暗号化され、そしてＦＥＫはまた、親ディレクトリへのアクセスを許容されたユーザが、アクセス制御リストがそのようなアクセスを許容するならば、ファイルへのアクセスを有するように、親ディレクトリのＥＦＳメタデータにおけるすべてのパブリックキーを使用して、暗号化される。
【００８４】
最終的に、３つのステータスのどれがコンテキストにあるかに拘わらず、後処理は、適切なＦＳＣＴＬを発行するために、図１９のステップ１９００において終局する。２つのＦＳＣＴＬ呼び出しが利用可能である。即ち、ＦＳＣＴＬ＿ＳＥＴ＿ＥＮＣＹＲＰＴＩＯＮとＦＳＣＴＬ＿ＥＮＣＲＹＰＴＩＯＮ＿ＦＳＣＴＬ＿ＩＯである。ＦＳＣＴＬ＿ＳＥＴ＿ＥＮＣＹＲＰＴＩＯＮは、ストリームに対する暗号化ビットをオン又はオフにすることをＮＴＦＳ２８に告げる。ＦＳＣＴＬ＿ＥＮＣＲＹＰＴＩＯＮ＿ＦＳＣＴＬ＿ＩＯは、下記の多数の動作を行うために使用されるいろいろなＦＳＣＴＬである。
【００８５】
このために、ＦＳＣＴＬが、図８と図９に示されたように、データ構造１００を伴う。データ構造は、ＮＴＦＳ２８が２つの形式のＦＳＣＴＬ呼び出しを区別することができるようなパブリックコード、並びに、ＥＦＳドライバ４６及び／又はＥＦＳサービス５０に対する動作をさらに詳細に規定するためのＥＦＳサブコードを含む。データ構造はまた、ＦＥＫ情報（図８）またはファイルハンドル情報（図９）を指定するＥＦＳデータを含み、時々、ＥＦＳメタデータを含む。機密保持の目的のために、ＥＦＳサブコードとＥＦＳデータフィールドは、ＥＦＳサービス５０が上記などの初期化された時確立されるセッションキーにより暗号化される。
【００８６】
使用において、ＦＳＣＴＬ＿ＳＥＴ＿ＥＮＣＲＹＰＴＩＯＮが発行され、例えば、ファイルが暗号化ディレクトリに最初に入れられた時、そのファイルに対する暗号化ビットをオンにする。サブコードは、暗号化ビットがオン又はオフにされるかを指示する。そのような動作に対して、ＦＥＫ６０は、すでに既知であり、こうして、図８に示されたように、ＥＦＳデータは、ＦＥＫを含み、ＦＥＫは、セッションキーにより暗号化される。パブリックキーを除いてすべてが、セッションコードにより暗号化されることに注意されたい。データ構造１００の保全性及びソースを検証するために、データ構造の暗号化部分が、解読される。その後、暗号化ＦＥＫが解読され、他のＦＥＫと比較され、等しいならば、構造が確認される。ＥＦＳストリームは、利用できるならば、他の方法で知られたＥＦＳメタデータと比較される。ＦＥＫは常に知られているわけではないために、同様の検証は、図９に示されたように、セッションキーとファイルハンドルを使用して、行われる。繰り返されるファイルハンドルは、８バイトの長さに等しいように、適切なフィールド（図９）において実際に使用される。
【００８７】
（ＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿１またはＦｉｌｅＳｙｓｔｅｍＣｏｎｔｒｏｌ＿２を介し、ＮＴＦＳ２８を介して伝達された）ＦＳＲＴＬ４８へのコールアウトは、付随するサブコード次第で、属性を重ね書きし、またはセットするために使用される。２ビットのサブコードは、重ね書き属性又はセット属性動作を表わす。ＥＦＳストリームが新ファイルに対して書き込まれる時、ＦＩＬＥ＿ＳＹＳＴＥＭ＿ＣＯＮＴＲＯＬ＿１が、（上記のＮＴＦＳ２８によって行われるように）暗号化ビットをまたオンにするために、ＦＳＲＴＬ４８コールアウトで使用される。代替的に、ＦＩＬＥ＿ＳＹＳＴＥＭ＿ＣＯＮＴＲＯＬ＿２は、暗号化ビットへの変更が必要とされない時、例えば、ユーザが単にユーザキーを変更しただけならば、コールアウトにより使用される。
【００８８】
いずれが使用されるかに拘わらず、１ビットのサブコードは、動作「ＥＦＳ  ＫｅｙＢｌｏｂをセットする」を表わし、新暗号化キー情報が利用可能であり、適切なキーコンテキストへ入力される必要があることを、ＦＳＲＴＬ４８へ指示する。別のビットは、動作「ＥＦＳストリームを書き込む」を表現する。ＥＦＳストリームを書き込むは、ユーザ又は回復エージェントがパブリックキーを変更し、ファイルメタデータがデータ構造１００におけるＥＦＳメタデータで書き換えられる必要がある時等、ＥＦＳサービス５０によって発行される。１つの他のサブコードは、「ＥＦＳストリームを得る」を表わし、ユーザがストリームをエキスポートするか、またはキー名称を知ることを望む時等、ファイルに対する現ＥＦＳ属性が、ＥＦＳフィールドに書き込まれる。
【００８９】
こうして、図１９へ戻ると、ステップ１９００は、暗号化ビットをオンにすることが必要とされるかを検査し、そうならば、ステップ１９０２においてＦＳＣＴＬ＿ＳＥＴ＿ＥＮＣＹＲＰＴＩＯＮ制御を発行し、サブコードは、ビットをオンにすることを指示する。もちろん、セッションキー、ハンドル、同一物のハンドル及び暗号化コピーを含む、他のＥＦＳデータもまた、検証目的のためにデータ構造１００にある。いずれにせよ、ＦＳＣＴＬは、ＮＴＦＳ２８に達し、ＮＴＦＳ２８は、転回し、ストリームにおいて暗号化ビットを（すでにオンでないならばファイルにおいて）セットし、情報をＦＳＲＴＬ４８に伝達するためにＦＳＲＴＬコールアウトを呼び出す。
【００９０】
ステップ１９００が満足されないならば、ＥＮＣＲＹＰＴＩＯＮ＿ＦＳＣＴＬ＿ＩＯ  ＦＳＣＴＬは、データ構造１００における適切なサブコードで呼び出される必要がある。こうして、ステータスが「ユーザ確認が必要とされる」（ステップ１９０４）であるならば、サブコードが、ステップ１９０５においてＫｅｙＢｌｏｂにセットされる。次に、メタデータがステップ１９０６によって判定されたように更新されたならば、ステップ１９０７は、ステップ１９１４における呼び出しの前に、書き込みＥＦＳストリームサブコードビットをセットする。そうでなければ、ステータスが「新ファイルＦＥＫが必要とされる」（ステップ１９０８）であるならば、サブコードは、ステップ１９１０においてＫｅｙＢｌｏｂおよび書き込みＥＦＳストリームにセットされる。すなわち、両ビットがセットされる。これらのいずれでもないならば、ステータスは、「新ディレクトリＦＥＫが必要とされる」であり、そしてサブコードが、ステップ１９１２において書き込みＥＦＳストリームにセットされる。すなわち、他方のビットのみがセットされる。ＦＳＣＴＬは、ステップ１９１４において発行される。
【００９１】
読み取りおよび書き込み
図２０において最初に示されたように、本発明の読み書き動作の説明に戻ると、アプリケーション３０が、オープンファイルからデータを読み取ることを要求する時（ステップ２０００）、Ｉ／Ｏサブシステム５６は、読み取り要求を受信し、それをＩＲＰとして適切なファイルシステム２８、例えばＮＴＦＳへ伝達する。しかし、まず、ＩＲＰは、ＥＦＳドライバ４６によって受信され、ＩＲＰを読み取り要求に対応するとして認識し、結果として、ステップ２００２においてＩＲＰをＮＴＦＳ２８へ直接に送る。ステップ２００４において、ＮＴＦＳ２８は、他のファイルに対して非暗号化テキストデータを読み取るように、ディスクからバッファに暗号化データを読み取る。しかし、暗号化ファイルに対して、ファイルシステム２８は、ステップ２００６において、このファイルが暗号化されることを認識し、そしてステップ２００８において、暗号化ドライバ４６が以前に作成／オープンコールバックから返したキーコンテキスト９６1を記憶し、かつ得る。ステップ２０１０において、ＮＴＦＳ２８は、ＡｆｔｅｒＲｅａｄＰｒｏｃｅｓｓコールバックを使用し、データを解読するために、暗号化コンテキストを含むデータおよび十分な情報を登録関数に提供する。一般に、情報は、ファイルへのオフセット、読み取りバッファへのポインター、読み取り長、およびキーを含む。ステップ２０１２において、暗号化ドライバ４６は、データを解読し、それをファイルシステム２８に返し、これにより、ステップ２０１４において、ファイルシステム２８は、この非暗号化テキストをＩ／Ｏサブシステム５６を介してアプリケーションへ通常の方法で戻す。しかし、ファイルインデクシングおよび他の情報を含むＮＴＦＳ２８の内部メタデータストリームは、暗号化されていないことに注意されたい。ＮＴＦＳ２８は、ステップ２００６においてこれらのストリームを認識し、これらの特定ストリームに対して、ステップ２００８〜２０１２を一時的にスキップする。
【００９２】
図２１において示されたように、アプリケーション３０が、オープンファイルへデータを書き込むことを要求する時（ステップ２１００）、Ｉ／Ｏサブシステム５６は、書き込み要求を受信し、それをＩＲＰとして適切なファイルシステム２８、例えばＮＴＦＳ、へ伝達する。しかし、最初に、ＩＲＰは、ＥＦＳドライバ４６によって受信され、ＩＲＰを書き込み要求に対応するとして認識し、結果として、ステップ２１０２においてＩＲＰをＮＴＦＳ２８へ直接に送る。ステップ２１０４において、ＮＴＦＳ２８は、書き込まれるデータに変更がなされないように、書き込みデータを別個のバッファへ複写する。暗号化ファイルに対して、ファイルシステム２８は、ステップ２１０６において、このファイルが暗号化されることを認識し、ステップ２１０８において、暗号化ドライバ４６が以前に作成／オープンコールバックから返したキーコンテキスト９６1を記憶し、かつ得る。ステップ２１１０において、ＮＴＦＳ２８は、ＢｅｆｏｒｅＷｒｉｔｅＰｒｏｃｅｓｓコールバックを使用し、データを暗号化するために、暗号化コンテキストを含むデータおよび十分な情報を、関数に与える。ステップ２１１２において、暗号化ドライバ４６は、データを暗号化し、それをＮＴＦＳ２８へ返し、これにより、ステップ２１１４において、ファイルシステム２８は、別個のバッファ内の今暗号化されたデータを、不揮発性記憶装置４０へ通常の方法で、すなわち、任意の他のファイルに対する非暗号化テキストデータであるかのように、書き込む。再び、ファイルインデクシングと他の情報を含むＮＴＦＳ２８の内部メタデータストリームは、暗号化されていないことに注意されたい。ＮＴＦＳ２８は、ステップ２１０６においてこれらのストリームを認識し、そしてこれらの特定ストリームに対してステップ２１０８〜２１１２を一時的にスキップする。
【００９３】
ファイルＡＰＩ暗号化および解読
ＥＦＳはまた、格納されたファイルの暗号化及び解読を容易にするためにＡＰＩ３２を備える。Ｗｉｎ３２  ＥｎｃｒｙｐｔＦｉｌｅ  ＡＰＩは、非暗号化テキストファイル／ディレクトリを暗号化するために使用される。図２２において示されるように、このＡＰＩにより、アプリケーション３０（ユーザ）は、ステップ２２００において暗号化するためのファイル名を提供し、この呼び出しは、動作を行うために、ＥＦＳサービス５０に対する呼び出しへ変換される。ステップ２２０２において、ＥＦＳサービス５０は、ユーザのためにファイルを開き、障害回復の目的のためにバックアップコピーを作成し、そしてステップ２２０４において、ＳＥＴ＿ＥＮＣＲＹＰＴファイル制御（ＦＳＣＴＬ）を発行することにより暗号化のためにそれをマークする。ステップ２２０６において、ＥＦＳサービス５０は、コピー内の各ストリームからデータを読み取り、ステップ２２０８においてデータを原ファイルに書き戻す。書き込み動作中、暗号化ビットがセットされるので、データは、ディスクに書き込まれる前に、自動的に暗号化される。プロセスは、すべてのデータストリームが書き込まれるまで、ステップ２２１０を介して反復される。この呼び出しが良好に完了するならば（ステップ２２１２）、バックアップは、ステップ２２１４において削除され、そうでなければ、原ファイルは、ステップ２２１６において復元され、呼び出しは失敗になる。ディレクトリの場合に、暗号化するデータはないために、ディレクトリは単に暗号化されたと記される。上記のように、ＮＴＦＳ２８の内部メタデータストリームは暗号化されていないことに注意されたい。
【００９４】
ＷＩＮ３２  ＤｅｃｒｙｐｔＦｉｌｅ  ＡＰＩはまた、ＥＦＳサービス５０によって提供され、暗号化ファイル／ディレクトリ動作の逆動作である。図２３において示されたように、ステップ２３００〜２３０２において、ＥＦＳサービス５０は、ファイル名を提供され、ユーザのためにファイルを開く。ステップ２３０６〜２３１０は、すべてのストリームからデータを読み取り、解読は透過的に行われるために、これらのストリームを非暗号化テキストであるコピーに書き込む。ステップ２３１２において、サービスは、解読ファイル制御を発行し、メタデータを削除し、暗号化属性を除去する。その後、ステップ２３１４〜２３１８によって示されるように、ＡＰＩは、非暗号化テキストにおいて書き込まれた原文のコピーからのすべてのデータストリームを書き戻す。これが良好に完了するならば、コピーは、ステップ２３２２において削除され、そうでなければ、原文が、ステップ２３２４において復元される。ディレクトリの場合に、ディレクトリは、解読するデータはないために、メタデータと属性を削除するために、解読されたとして単に記される。
【００９５】
理解されるように、ＥＦＳファイル暗号化は、ファイル毎又は全ディレクトリベースでサポートされる（しかしＮＴＦＳ２８はストリーム毎に動作する）。ディレクトリ暗号化は、透過的に実施される。すなわち、暗号化のためにマークされたディレクトリにおいて作成されたすべてのファイル（またはサブディレクトリ）は、自動的に暗号化して作成される。さらに、ファイル暗号化キーは、ファイル毎であり、ファイルシステムボリュームにおける移動／複写動作に対して安全にする。現アプリケーションレベル体系とは異なり、以下に明らかになるように、暗号化及び解読動作が透過的に、かつバイトがディスクとの間で移動する最中に行われるために、ファイルは使用前に解読される必要はない。ＥＦＳは、暗号化ファイルを自動的に検出し、キー記憶装置からユーザのキーを見つけ出す。キー記憶装置のメカニズムは、ＣｒｙｐｔｏＡＰＩから梃入れされ、結果として、ユーザは、スマートカード及び／又はフロッピーディスクなどの、安全な装置においてキーを記憶する柔軟性を有する。
【００９６】
さらに、本発明により、ＥＦＳは、下側のファイルシステム２８（例えば、ＮＴＦＳ）と協同し、これにより、ＥＦＳは、暗号化された一時的ファイルの（適正に開発されたアプリケーションプログラムによる）書込みを容易にする。そのようなアプリケーションプログラムにより、一時的ファイルが作成される時、原ファイルからの属性が一時的ファイルへ複写され、一時的コピーもまた暗号化される。さらに、ＥＦＳドライバ４６は、Ｗｉｎｄｏｗｓ  ＮＴカーネルモードドライバであり、ファイル暗号化キーを記憶するために非ページプールを使用し、これにより、キーはそれをページファイルにしないことを保証する。
【００９７】
ＥＦＳアーキテクチャは、任意数の人員の間のファイル共有を、これらの人員のパブリックキーの単純な使用により可能にする。各ユーザは、プライベートキーを使用して、ファイルを独立に解読する。ユーザは、（構成されたパブリックキーペアを有するならば）容易に追加され、あるいは共有者の仲間から除去される。
【００９８】
スタンドアロン構成において、ＥＦＳにより、ユーザは、キーをセットする管理上の努力を払わずに、ファイルの暗号化／解読を開始することができる。すなわち、ＥＦＳは、構成されていないならば、ユーザに対するキーの自動生成をサポートする。ドメイン構成では、管理者は、ＥＦＳが動作可能になるために、１度ドメインポリシーをセットする必要がある。最後に、ＥＦＳはまた、ファイルサーバにおいて記憶された遠隔ファイルにおいて暗号化／解読をサポートする。しかし、ディスクからいったん読み取られたデータは、進行中に解読され、このため、ファイル共有プロトコルが通信の暗号化を実施しないならば、回線を非暗号化テキストで移動する。すなわち、ＥＦＳは、通信暗号化ではなく、記憶暗号化を扱う。通信プロトコルは、そのような暗号化を設けるために使用される。
【００９９】
前述の詳細な説明から判明するように、データを暗号化するためのシステム及び方法が提供され、システム及び方法は、暗号化及び解読が合法なユーザに透過的に作用するように、ファイルシステムへ統合される。システム及び方法は、２人以上の合法なユーザの間で極秘データを共有する能力を提供し、ユーザに対する追加及び除去アクセスは、単純である。ユーザがキーを失う時などの、暗号化されたデータ回復を扱う強力な暗号法が、提供される。そのシステム及び方法は、柔軟性及び拡張性がある。
【０１００】
本発明は種々の変更及び代替的構成を可能とするが、ある例示の実施形態が、図面に示され、詳細に上記に記載された。しかし、開示された特定の形態に本発明を限定する意図はなく、逆に、本発明の趣旨及び範囲内に包含されるすべての変更、代替的構成、及び等価物を含むことを意図する。
【図面の簡単な説明】
【図１】  本発明が取り入れられたコンピュータシステムを表わすブロック図である。
【図２】  本発明のコンポーネントの一般アーキテクチャを表わすブロック図である。
【図３】  データの暗号化において使用されたいろいろな論理コンポーネントを概念的に表わすブロック図である。
【図４】  データの解読において使用されたいろいろな論理コンポーネントを概念的に表わすブロック図である。
【図５】  暗号化データの回復において使用されたいろいろな論理コンポーネントを概念的に表わすブロック図である。
【図６】  ファイル暗号化及び解読のためのキーコンテキスト情報を少なくとも部分的に含むファイルに関連したストリーム制御ブロックの表現図である。
【図７】  暗号化ファイル及びディレクトリのための暗号化コンポーネントの間で情報を通信するために使用されるコンテキストチェーンの表現図である。
【図８】  暗号化キー情報を含むファイル情報を相互に通信するための一定のコンポーネントによって使用されるデータ構造の表現図である。
【図９】  暗号化キー情報を含むファイル情報を相互に通信するための一定のコンポーネントによって使用されるデータ構造の表現図である。
【図１０】  本発明の１つの態様により、ファイルを開く又は作成するための全制御フローを示す流れ図である。
【図１１】  ファイルを開く又は作成する一部として一般的に採用されるドライバ前処理ステップを表現する流れ図である。
【図１２】  ファイルオープン要求を取り扱うためにファイルシステムによって採用されるステップを表わす流れ図である。
【図１３】  本発明の１つの態様により、暗号化ファイルを開く又は作成するためにコールアウトによって採用される一般的なステップを表わす流れ図である。
【図１４】  本発明の１つの態様により、暗号化ファイルを開く又は作成するためにコールアウトによって採用される一般的なステップを表わす流れ図である。
【図１５】  ファイルを開く又は作成する一部として一般に採用されるドライバ後処理ステップを表わす流れ図である。
【図１６】  ファイルを開く又は作成する一部として一般に採用されるドライバ後処理ステップを表わす流れ図である。
【図１７】  ファイルを開く又は作成する一部として一般に採用されるドライバ後処理ステップを表わす流れ図である。
【図１８】  ファイルを開く又は作成する一部として一般に採用されるドライバ後処理ステップを表わす流れ図である。
【図１９】  ファイルを開く又は作成する一部として一般に採用されるドライバ後処理ステップを表わす流れ図である。
【図２０】  ファイル読み取り要求を取り扱うためにいろいろなコンポーネントによって採用されるステップを表わす流れ図である。
【図２１】  ファイル書き込み要求を取り扱うためにいろいろなコンポーネントによって採用されるステップを表わす流れ図である。
【図２２】  記憶非暗号化テキストファイルを暗号化するためのユーザ要求を取り扱うためにいろいろなコンポーネントによって採用されるステップを表わす流れ図である。
【図２３】  記憶暗号化ファイルを解読するためのユーザ要求を取り扱うためにいろいろなコンポーネントによって採用されるステップを表わす流れ図である。
【図１】
0004593774.tif 000002
【図２】
0004593774.tif 000003
【図３】
0004593774.tif 000004
【図４】
0004593774.tif 000005
【図５】
0004593774.tif 000006
【図６】
0004593774.tif 000007
【図７】
0004593774.tif 000008
【図８】
0004593774.tif 000009
【図９】
0004593774.tif 000010
【図１０】
0004593774.tif 000011
【図１１】
0004593774.tif 000012
【図１２】
0004593774.tif 000013
【図１３】
0004593774.tif 000014
【図１４】
0004593774.tif 000015
【図１５】
0004593774.tif 000016
【図１６】
0004593774.tif 000017
【図１７】
0004593774.tif 000018
【図１８】
0004593774.tif 000019
【図１９】
0004593774.tif 000020
【図２０】
0004593774.tif 000021
【図２１】
0004593774.tif 000022
【図２２】
0004593774.tif 000023
【図２３】
0004593774.tif 000024