「ゴーディアンノットを切る」またはWindowsの情報暗号化の問題を克服する

最新のオペレーティングシステムは、情報を処理および管理する複雑な階層プロセスです。 この問題における現在のバージョンのWindowsも例外ではありません。 セキュリティツールをWindowsオペレーティングシステムの環境に統合するには、多くの場合、アプリケーションレベルでの統合で十分です。 ただし、Windows環境で情報を暗号化することになると、事態はさらに複雑になります。



このプロセスにおける暗号化ツールの開発者の主な「頭痛」は、「暗号化の透明性」、つまり オペレーティングシステムのプロセス構造に調和して統合すると同時に、ユーザーが暗号化プロセスに関与しないようにし、さらにメンテナンスを行う必要があります。 現代の保護手段の要件により、ユーザーは情報を保護するプロセスからますます除外されています。 したがって、このユーザー自身にとって、情報を保護するために「理解できない」決定を採用する必要のない快適な条件が作成されます。

この記事では、ディスク暗号化ツールとWindowsファイルシステムのプロセスとの効果的な統合のアイデアを明らかにします。

開発者の目標は、ユーザーの最大の透過性の要件を満たすディスク上の情報を暗号化するメカニズムを作成することでした。 この暗号化メカニズムと、ファイルシステムの管理を担当するWindowsオペレーティングシステムのプロセスとの効果的な相互作用を通じて、要件を満たす必要があります。 暗号化メカニズムの有効性は、暗号化プロセスの高いパフォーマンスとオペレーティングシステムリソースの合理的な使用によっても確認する必要があります。

タスクは、暗号化および復号化されたコンテンツへの同時アクセスとファイル名の暗号化を提供するように最初に設定されました。 これは主な問題を引き起こします、なぜなら このような要件は、Windowsの現在のアーキテクチャに反します。 問題の本質を理解するには、まずこのオペレーティングシステムの主要なポイントを分析する必要があります。

Windowsでは、すべてのファイルシステムはメモリマネージャーやキャッシュマネージャーなどのサブシステムに依存しており、メモリマネージャーはファイルシステムに依存しています。 それは悪循環のように思えますが、すべてがさらに明らかになります。 以下の図1では、これらのコンポーネントと、サブシステム（Win32など）および他のシステムドライバーからの要求を受け入れるI / Oマネージャーが示されています。 「フィルター」および「ファイルシステムのスタック」という用語も図で使用されています。これについては、以下で詳しく説明します。



図1









ファイルをメモリにマッピングするなどのメカニズムを分析しましょう。 その本質は、実際に仮想メモリにアクセスすると、ファイルの一部が読み取られるという事実にあります。 これは、プロセッサのハードウェアメカニズムとメモリマネージャ自体を使用して実装されます。 プロセス仮想メモリの範囲は、記述子で記述されます。 ある範囲に対して記述子がない場合、仮想メモリのこのセクションには何も存在せず、そのような範囲へのアクセスはプロセスの崩壊につながります。 物理メモリが任意の範囲に割り当てられている場合、これらの仮想アドレスへのアクセスは物理メモリへの通常のアクセスにつながります。そのようなメモリは匿名とも呼ばれます。 ファイルが仮想メモリにマップされている場合、これらのアドレスにアクセスすると、ファイルの一部がディスクから物理メモリに読み取られ、その後通常の方法でファイルへのアクセスが実行されます。 つまり これら2つのケースは非常に似ていますが、唯一の違いは、後者の場合、ファイルの一部が対応する物理メモリに以前に読み込まれることです。 これらのアクセスタイプはすべて記述子であり、情報が含まれています。 これらの記述子は、必要なタスクを実行するために管理するメモリマネージャーの構造です。 ご想像のとおり、ファイルの一部を物理メモリのページに読み込むには、メモリマネージャがファイルシステムにリクエストを送信する必要があります。 図2は、AとBの2つの範囲を持つプロセス仮想メモリの例を示しています。これまでにアクセスしたことはありません。



図2









範囲Aはプロセス自体の実行可能ファイルを表示し、範囲Bは物理メモリを表示します。 これで、プロセスが範囲Aへの最初のアクセスを実行すると、メモリマネージャが制御を受け取り、最初に行うことは範囲のタイプを評価することです。 ファイルは範囲Aにマッピングされるため、メモリマネージャーは最初に物理メモリ内のファイルから対応する部分を検討し、次にそれをプロセス範囲Aにマッピングするため、メモリマネージャーなしで読み取り内容へのアクセスがさらに実行されます。 範囲Bの場合、メモリマネージャーは同じシーケンスを実行しますが、唯一の違いは、ファイルからデータを読み取る代わりに、メモリの空き物理ページを範囲Bにマップするだけです。その後、この範囲へのアクセスは、メモリマネージャーの関与なしに実行されます。 図3は、範囲AおよびBへの最初のアクセス後のプロセスの仮想メモリの例を示しています。



図3









図からわかるように、両方の範囲にアクセスする場合、物理メモリへのアクセスはメモリマネージャの関与なしに実行されます。 以前、最初のアクセスで、彼は物理メモリを範囲AとBにマッピングし、対応するファイルの一部を以前に範囲Aの物理メモリに読み込みました。

キャッシュマネージャは、すべてのディスク上のシステムで開かれているすべてのファイルの中心的なメカニズムです。 このメカニズムを使用すると、ファイルへのアクセスを高速化できるだけでなく、物理メモリを節約できます。 キャッシュマネージャーは、メモリマネージャーとは異なり、単独では機能しません。 ファイルシステムによって完全に管理され、ファイルに関する必要な情報（サイズなど）はすべてファイルシステムによって提供されます。 読み取り/書き込み要求がファイルシステムに送信されるたびに、ファイルシステムはディスクからファイルを読み取らず、代わりにキャッシュマネージャーサービスを呼び出します。 キャッシュマネージャは、メモリマネージャのサービスを使用して、ファイルを仮想メモリにマップし、メモリからリクエスタのバッファにコピーします。 したがって、このメモリにアクセスすると、メモリマネージャはファイルシステムにリクエストを送信します。 そして、これは特別な要求であり、ファイルをディスクから直接読み取る必要があることを示します。 キャッシュマネージャーによって以前にマップされたファイルにアクセスしている場合、そのファイルは再び仮想メモリにマップされません。 代わりに、キャッシュマネージャーは、ファイルが以前にマップされた仮想メモリを使用します。 ファイルマッピングは、ファイルシステムがサービスを呼び出すときにキャッシュマネージャーに渡す構造を通じて監視されます。 これらの構造については、以下で詳しく説明します。 図4は、ファイルを読み取るプロセスの例を示しています。



図4









上の図に示すように、プロセスはファイルをバッファーBに読み取ります。読み取るために、プロセスはI / Oマネージャーに接続し、I / Oマネージャーが要求を生成してファイルシステムに送信します。 ファイルシステムは、リクエストを受信すると、ディスクからファイルを読み取りませんが、キャッシュマネージャーを呼び出します。 次に、キャッシュマネージャーは、ファイルがその仮想メモリにマップされているかどうかを評価し、マップされていない場合は、メモリマネージャーを呼び出してファイル/ファイルの一部を表示します。 この例では、ファイルはすでに表示されており、アクセスは一度も行われていません。 さらに、キャッシュマネージャーは、仮想メモリAの範囲にマップされたファイルをプロセスバッファーBにコピーします。範囲Aへのアクセスは初めて実行されるため、メモリマネージャーは制御を受け取り、範囲を評価し、メモリにマップされたファイルであるため、その一部と見なしますその後、仮想メモリAの範囲に表示されます。その後、既に説明したように、メモリマネージャをバイパスして範囲Aへのアクセスが実行されます。

何回でもファイルをキャッシュし、メモリにマップすることを何回も妨げることはありません。 ファイルがキャッシュされ、多数のプロセスのメモリにマップされている場合でも、このファイルに使用される物理メモリは同じです。 これが物理メモリの保存の本質です。 図5は、1つのプロセスが通常の方法でファイルを読み取り、別のプロセスが同じファイルをその仮想メモリにマップする例を示しています。



図5









上の図からわかるように、物理メモリはプロセスBの仮想メモリとキャッシュマネージャの仮想メモリにマップされます。 プロセスAがファイルをバッファーDに読み込むと、I / Oマネージャーに接続し、要求を作成してファイルシステムに送信します。 次に、ファイルシステムはキャッシュマネージャーを使用します。キャッシュマネージャーは、マネージャーのキャッシュの仮想メモリ範囲CにマップされたファイルをプロセスAのバッファーDに単にコピーします。ファイルは表示されるだけでなく、キャッシュマネージャーへのアクセス時に以前に実行されていたためファイルがマップされている範囲Cへのアクセス、メモリマネージャーの参加なしで操作が実行されます。 範囲Eを読み書きするとき、プロセスBは、キャッシュマネージャーがファイルをコピーするときにアクセスしたメモリの同じ物理ページに基本的にアクセスします。

ファイルシステムは、ユーザーソフトウェアまたは他のドライバーからの要求を受け入れます。 アクセスする前に、ファイルを開いておく必要があります。 ファイルを開く/作成する要求が正常に実行されると、ファイルシステムはキャッシュマネージャーとメモリマネージャーが使用するメモリ構造を形成します。 これらの構造はファイルに固有であることにも注意してください。 つまり 同じファイルに対する同じ要求が来たときに特定のディスクファイルが開かれた場合、ファイルシステムは以前に形成されたメモリ構造を使用します。 本質的に、これらはメモリ内のディスクファイルのソフトウェア表現です。 図6は、開いているファイルのインスタンスとその構造を照合する例を示しています。



図6









図では、プロセスAがファイルCとファイルDを開き、プロセスBがファイルCを2回開いています。 したがって、ファイルシステムによって形成される構造が1つだけの場合、ファイルCの3つの開いているインスタンスがあります。 ファイルDは一度開かれたため、ファイルシステムによって形成された構造に対応する1つの開いたインスタンスがあります。

ファイルシステムに送信された要求は、すぐには処理されません。 リクエストは、まずそのようなリクエストを追跡したいドライバーのチェーンを通過します。 このようなドライバーはフィルターと呼ばれます。 ファイルシステムに到達する前、およびファイルシステムがリクエストを処理した後、リクエストを表示することができます。 たとえば、ファイル暗号化フィルターは、データを復号化/暗号化するために、読み取り/書き込み要求を追跡できます。 したがって、ファイルシステム自体を変更することなく、ファイルデータを暗号化できます。 フィルタは、ファイルシステムが形成するファイル構造に一意のデータをバインドできます。 フィルタードライバーとファイルシステムドライバーが一緒になって、ファイルシステムスタックを形成します。 フィルターの数は異なる場合があり、フィルター自体も異なる場合があります。 理論的には、まったくそうではないかもしれませんが、実際には起こりません。 図7は、3つのフィルターを含むファイルシステムスタックを示しています。



図7









要求がファイルシステムに到達する前に、フィルター1、2、3を順番に通過します。ファイルシステムによって要求が処理されると、フィルターと逆の順序で表示されます。 また、上記の例では、フィルター1およびフィルター3は、ファイルを開いたり作成したりする要求が実行された後にファイルシステムが形成したファイル構造に構造を付加しました。

ほとんどのタスクはフィルタリングによって解決されますが、私たちのケースは独特です。 前述のように、ファイル名を暗号化するだけでなく、暗号化および復号化されたコンテンツへの同時アクセスを提供する必要があるという点でユニークです。 それでも、この問題を解決するフィルターの開発を試みます。

図8は、ファイルが以前に解読されて開かれたときの状況を示しています。



図8









これは、フィルターが復号化された名前を確認したことを意味し、図に示すように、ファイルシステムが形成する構造にこの名前をバインドできます（前述のように、この構造は特定のディスクファイルに固有です）。 その瞬間、ファイルは暗号化されて開かれます。つまり、フィルターは暗号化された名前を見ました。 復号化された名前が既にファイル構造に関連付けられている場合、このような状況でどのように動作しますか？ 結果が致命的である必要はありませんが、明らかに、動作は予測できません。

上記の続きで、ファイルのコンテンツにアクセスすると、問題が発生し、さらに深刻な問題が発生することを追加できます。 ファイルが復号化と暗号化の両方で開かれたときの状況に戻りましょう。 この状況を図9に示します;ファイルは一度も読み書きされていません。



図9









ここで、復号化されたコンテンツを読み取る要求が来たとします。 ファイルシステムはキャッシュマネージャーのサービスを使用してファイル構造を提供し、キャッシュマネージャーとメモリマネージャーの両方が独自のデータを添付して、ファイルの表示とキャッシュをさらに制御します。 この状況を図10に示します。



図10









次に、要求は暗号化されたコンテンツを読み取るようになり、ファイルシステムは再びファイル構造をキャッシュマネージャーに渡します。キャッシュマネージャーとメモリマネージャーは以前にこのファイルの一意のデータをこの構造に関連付けていたため、それらを使用して単純に要求を実行します。 つまり これで、これらの構造はファイルがマップされた場所を示し、キャッシュマネージャーはファイルデータを仮想メモリからリクエスターのバッファーに単にコピーします。 ファイルは最初にアクセスされたときに復号化されてキャッシュされたため、暗号化されたアクセスの場合、復号化者のバッファには復号化されたデータが含まれます。

2つの基本的な問題を整理しました。 実際には、もっとありました。 たとえば、タスクの一部として、各暗号化ファイルにヘッダー情報を追加する必要がありますが、これもフィルタリングでは解決されません。 これらすべての問題を一度に回避するために、仮想ファイルシステムという解決策が見つかりました。

本質的に、仮想ファイルシステムは通常のシステムと大差ありません。 根本的な違いは、通常のファイルシステムがディスクで動作し、仮想システムが他のファイルシステムのファイルで動作することです。 ファイルシステムサービスの一般的な消費者です。 図11は、仮想ファイルシステムの概念を示しています。



図11





通常のファイルシステムとは異なり、仮想ファイルシステムはそれ自体をシステムに登録しません（これは上記では言及しませんでしたが、オペレーティングシステムが特定のファイルシステムのサービスを使用するには登録する必要があります）。その場合、リクエストを送信する必要がありますなりません。 この問題を解決するために、通常のファイルシステムにフィルターを使用しますが、今回はその機能が非常にシンプルで制限されます。そのうちの1つ（および主な機能）は暗号化ファイルへのアクセスを追跡します。 フィルターがそのような要求を検出するとすぐに、単純にそれを仮想ファイルシステムにリダイレクトします。 通常のファイルへのアクセスが実行されると、要求は元のファイルシステムに転送されます。

次に、仮想ファイルシステムのコンテキストで、復号化および暗号化されたアクセスをもう一度見てみましょう。 図12は、特定のファイルの復号化および暗号化されたコンテンツにアクセスした場合の例を示しています。



図12





もう一度、ファイルが復号化されて開かれたときの状況を想像してください。 これは、ファイルを開く要求の実行中に、フィルターがそれを確認し、仮想ファイルシステムにリダイレクトしたことを意味します。 仮想ファイルシステムは、リクエストを受信すると、アクセスのタイプ（復号化または暗号化）を評価し、復号化されたアクセスが実行されるため、仮想ファイルシステムはまず復号化された名前を暗号化された名前に変換してから、その名前（つまり名前）でネイティブファイルシステムを介してファイルを開こうとしますネイティブファイルシステム上のファイルは暗号化されます）。 成功すると、仮想ファイルシステムはメモリ構造を形成し、後でキャッシュマネージャとメモリマネージャが使用します。 ここで、ファイルが暗号化されて開かれ、フィルターが評価を行わずに要求を仮想ファイルシステムに再度リダイレクトするとします。 仮想ファイルシステムはアクセスのタイプを評価し、アクセスは暗号化されているため、その名前でネイティブファイルシステムを介してファイルを開こうとします。 また、成功すると、仮想ファイルシステムはキャッシュマネージャーとメモリマネージャーのメモリ構造を形成します。 ただし、復号化されたアクセスとは異なり、これらは他の構造になります。 これで、ファイルが再び復号化されて開かれた場合、仮想ファイルシステムは、最初の復号化されたアクセス中に形成されたものと同じ構造を使用します。 ファイルが再び暗号化されて開かれる場合、ファイルシステムは最初の暗号化されたアクセス中に形成された構造を使用します。 したがって、復号化および暗号化されたコンテンツへのアクセスを共有しました。

図13は、復号化および暗号化されたファイルコンテンツへの読み取り/書き込みアクセスが実行されたことがない状況を示しています。



図13





ここで、解読された読み取りが実行されると、図14に示すように、キャッシュマネージャーサービスを使用する仮想ファイルシステムは、解読されたファイルが開かれたときに返されたメモリ構造を提供します。



図14





キャッシュマネージャーは、ファイルを仮想メモリにマップし、データをリクエスターのバッファーにコピーします。 したがって、コピーのプロセスでは、メモリマネージャーが仮想ファイルシステムに読み取り要求を送信し、仮想ファイルシステムが読み取り要求をネイティブファイルシステムに送信します。また、復号化されたファイルのメモリ構造がキャッシュマネージャーに転送されたため、仮想ファイルシステムはデータを復号化し、完了をメモリマネージャーに通知します、復号化されたコンテンツはキャッシュされます。 暗号化された読み取りが実行されると、仮想ファイルシステムは、図15に示すように、ファイルが暗号化されて開かれたときに生成したメモリ構造のマネージャーにキャッシュを転送します。



図15





キャッシュマネージャーは再びファイルを仮想メモリにマップし（これらの構造にはまだファイルが表示されていないため）、データをリクエスターのバッファーにコピーします。 また、コピーのプロセスで、メモリマネージャーは仮想ファイルシステムに読み取り要求を送信し、仮想ファイルシステムは読み取り要求をネイティブファイルシステムに再度送信します。暗号化されたファイルのメモリ構造はデータを復号化せずにキャッシュマネージャーに転送されたため、仮想ファイルシステムはメモリマネージャーに通知します完了。 そのため、ファイルは暗号化されてキャッシュされます。

ご覧のように、仮想ファイルシステムは、ファイルの復号化および暗号化されたコンテンツへの同時アクセスを許可しない基本的な問題を解決するため、オペレーティングシステムの従来のメカニズムを放棄する必要があります。 フィルタリングプロセスでは、ファイルシステムが返すファイルメモリ構造にのみデータを追加できます。また、これらの構造を形成しないため、それらに介入して管理することはできません。 そして、仮想ファイルシステムを通じてそれらを完全に形成するため、これらを完全に制御できます。これは、この問題を解決するフレームワークで必要です。 たとえば、復号化および暗号化されたコンテンツファイルの一貫性を確保する必要があります。 データが復号化されたファイルに書き込まれ、データがディスクではなくキャッシュに残っている状況を想像してください。 そしてその瞬間に、ファイルの暗号化されたコンテンツを読み取る要求が来ます。 これに応じて、仮想ファイルシステムは復号化されたコンテンツをディスクにダウンロードし、暗号化されたキャッシュをフラッシュします。これにより、キャッシュマネージャーは暗号化された読み取りのために読み取り要求を仮想ファイルシステムに再送信します。 ろ過の枠組みでは、このような問題は原則的に解決されていません。

仮想ファイルシステムを開発するとき、私は異常な問題に対処しなければなりませんでした。 これは、通常のファイルシステムがディスクを操作するときにファイルシステムファイルを操作するためです。 そのため、たとえば、NTFSファイルシステムでエラーが見つかりました。 ファイルXへのアクセスで明らかになりました：\ $ mft \ <任意の名前>は、Xドライブへのすべてのアクセスのハングにつながりました。調査の結果、NTFSはすべてのファイルの列挙子であるファイル$ mftの同期メカニズムをリリースしませんでしたドライブ。 したがって、ディスク上のファイルを見つけるには、最初に$ mftファイルを読み取る必要があります。このファイルへのアクセスは一時停止されています。 異常とは言えないもう1つの例は、Windows 8カーネルで見つかったエラーです。その結果、メモリマネージャーは、ファイルのメモリ構造が常に最新バージョンであると判断します。 このため、彼はこの構造の一部を使用しようとしていますが、実際にはそうではないかもしれません。 そして、それがBSODにつながりました。

仮想ファイルシステムの実装は、フィルタの実装よりもはるかに複雑ですが、このようなメカニズムの存在は、ファイルを操作する際の柔軟性を高めます。 先ほどお話ししたものを含めて。 一見したところ、タスクは簡単なように思えるかもしれませんが。

このアプローチを暗号化に適用した結果、暗号化および復号化されたコンテンツへのソフトウェアプロセスの同時アクセスを提供する機能が正常に実装され、ファイル名の暗号化が実装されました。これにより、暗号情報保護の実装の高度な透明性が実現します。

Windowsでファイル暗号化の「透明性」を確保するこのアプローチは、ロシアの多くの組織で使用されているSecret Disk Enterprise企業製品（Aladdin R.D.）で正常に実装されていることに注意してください。 これは、ディスク上のファイルの暗号化プログラムを作成するプロセスでこのアイデアを適用することの実行可能性と見通しを示しています。

結論として、Windowsファイルシステムの技術的な複雑さと、この記事で説明したような問題を解決するための標準メカニズムの欠如は、情報を保護する便利でシンプルなプログラムを作成する上で常に障害となることに注意してください。 この場合、唯一の正しい決定は、ソフトウェア機能を失うことなくこれらの制限を回避するために元のメカニズムを独立して実装することです。