Windows Vista Security IN&OUT
事件と課題から考えるWindows Vistaのセキュリティ(第2回)

マイクロソフト
セキュリティ レスポンス マネージャ
小野寺 匠

 前回は,実際に起きている問題の視点(OUT側の視点)からWindows Vistaのセキュリティの概要を解説した。今回は技術的な視点(IN側の視点)からWindows Vistaのセキュリティ面を解説する。本コラムでは,OUT側の視点での解説とIN側の視点での解説を交互に連載していく予定である。

 IN側の視点での第1回目となる今回は,データ暗号化の基本的な技術である「EFS」(Encrypted File System)について解説することにする。EFSはWindows 2000から実装されている技術で,今となっては目新しいものではない。ただ,BitLockerやRMS(Rights Management Service)といった最新の暗号化技術を理解する上ではEFSを避けては通れない。

 EFSは手軽にファイルを暗号化できるばかりでなく,退職や事故によって暗号鍵が使えなくなった場合でも,これをリカバリーする仕組みを持っている。実用性が高く,低コストで実装できる暗号化ファイル・システムである。ただ,その技術的な実装については,意外に知られていない。

EFSの暗号化方式

 EFSはファイル単位で暗号化を行うNTFSファイル・システムのオプション機能で,DESX,3DES,AES256を使ってデータの暗号処理を行う。利用する暗号方式はOSのバージョンに依存しており,Windows XP SP1以降はAES256,それ以前のシステムではDESX(標準)または3DESを使用する。


図1 EFSの三つの鍵(FEK,DDF,DRF)
[画像のクリックで拡大表示]

 これらの暗号方式は共通鍵暗号方式であり,共通鍵の漏えい防止策が重要になる。EFSではこれを,DDF(Data Decryption Field:データ復号化フィールド),DRF(Data Recovery Field:データ回復フィールド)という概念で解決している(図1)。この仕組みによって,暗号化したファイルへのアクセス制御を実現する。特にDDFの使い方を理解しておかないと,必要なユーザー同士でファイルを共有できないといったトラブルを招く可能性が出てくる。


図2 EFSファイルの暗号化
[画像のクリックで拡大表示]

 EFSでデータの暗号化に利用する共通鍵は,FEK(File Encryption Key)と呼ばれ,ユーザーがファイルを暗号化する際に自動的に生成される。当然,ほかのユーザーがこのEFSファイルを利用するには,復号化のためにFEKを入手しなければならない。ただ,誰もがFEKを利用できるようになっていると,暗号化の意味がない。そこでEFSでは,暗号化したファイルのヘッダ部分に特定の領域を設け,そこに公開鍵暗号方式で暗号化したFEKを格納する(図2)。この領域がDDFで,アクセス権を割り当てるユーザーごとに用意される。つまり,10人にアクセス権を与える場合には,それぞれのユーザーごとに公開鍵を使ってFEKを暗号化し,10人分のDDFを設けるようになっている。


図 3 EFSファイルの復号化
[画像のクリックで拡大表示]

 ユーザーがEFSファイルにアクセスする場合,ユーザーが持つEFS秘密鍵を使ってDDFを復号化し,FEKを取り出す(図3)。そして,取り出したFEKを使ってデータの暗号処理(暗号化・復号化)を行う。各ユーザーのEFS用秘密鍵は,ユーザープロファイルに格納されており,PC上のディスク,Active Directoryまたはスマートカードで管理することができる。

 ここで,紛失や退職等により,ユーザーの公開鍵暗号方式の秘密鍵が利用できなくなる場合を考慮し,EFSにはDRFという概念を取り入れてある。DRFは,いわば回復エージェント(非常時にファイルを復号化するエージェント)用のDDFに相当するもので,回復エージェントの公開鍵で暗号化したFEKを格納する。DRFについても,DDFと同様に複数の回復エージェントを指定することができる。


図4 EFSファイルの回復処理
[画像のクリックで拡大表示]

 回復処理は,回復エージェントの秘密鍵を使ってFEKを復号化するほかは,通常の復号処理と同じである(図4)。ただ,回復エージェントはファイルを直接操作することはできず,操作は,暗号を解除したコピー・ファイルの作成に限定される。

 EFSの利用に際しては,大別して二つの注意事項がある。一つはEFSで暗号化したファイルへのアクセス権限の設定方法。もう一つは回復エージェントの設定方法である。

 EFSファイルのアクセス権限は,DDFの作成と独立に扱われる。ユーザーがファイルをEFSで暗号化しても,そのファイルに作成されるDDFはログインしたユーザーの分だけ。アクセス権を持つほかのユーザーのDDFは自動的には 作成されない。ほかのユーザーのDDFを追加する場合は,明示的にDDFを作成しなければならない。


写真1 ファイルの権限
[画像のクリックで拡大表示]

写真2 DDF,DRFが登録されているユーザー
[画像のクリックで拡大表示]

写真3 フォルダの属性の詳細
[画像のクリックで拡大表示]

 具体例を示そう。写真1はEFSfile2.txtというファイルのプロパティ画面である。この例では,EFSfile2.txtへのアクセス権を4つのアカウントに与えている。このファイルをEFSで暗号化し,そのDDF,DRFを表示させたものが写真2である。ファイル作成者のDDFしか作成されていないことが分かるだろう(DDFとDRFの表示は,プロパティ画面から,詳細設定(D)→詳細(D)とたどる)。

 DDFはオブジェクト間で継承されない。フォルダのプロパティでは,DDFを追加するための詳細権限のボタンがディスエーブルになっているため,複数のユーザーがEFSを利用する場合は,常にファイル単位で指定する必要がある(写真3)。

 もう一つの回復エージェントは,ドメイン単位(PC単体を含む)で指定する。このため,特定のファイルではなく所属するドメインのすべてのファイルに対してDDFが有効になる。セキュリティ・ポリシー上,一定の領域ごとに回復エージェントを分けたいような場合には注意が必要である。

 回復エージェントは,ローカル・セキュリティ・ポリシーや,グループ・ポリシーなどを使って設定することができる。ポリシーの適用先として回復エージェントを複数登録すれば,DRFも複数作成される。ただし,ファイルごとにDRFを持つことから,回復エージェントを追加しても,そのDRFは既存のEFSファイルに対しては自動的には追加されない。この点も要注意だ。

EFSのアーキテクチャ概要

 次に,EFSのアーキテクチャの概要を解説しよう。EFSはEFSドライバ,FSRTL(file system runtime library),EFSサービスで構成され,これらのモジュールが,Crypto APIを使って暗号処理を行う(図5)。


図5 EFSのアーキテクチャ概要
[画像のクリックで拡大表示]

 EFSドライバは,NTFSの最上位に位置するドライバで,FEK,DDF,DRFのハンドリング,I/Oリクエストに対する暗号化と復号化の受け口となっている。EFSドライバは,I/Oリクエストに対して,内部モジュールであるFSRTLを使った透過的な暗号化・復号化を提供する。なお,EFSドライバはフィルタ・ドライバであるため,通常のファイルに対するI/OリクエストもEFSドライバを経由する。EFSドライバはこれを単にスルーする。

 EFSドライバは,暗号化に関連した処理を行うため,セキュリティ・サブシステムの一部であるEFSサービスに対して,ローカル・プロシージャ・コール(LPC)を使ってリクエストを行う。EFSドライバは,EFSサービスを通じてCrypto APIによるFEK,DDF,DRFの生成,暗号化,復号化などを実行する。

 一連の暗号処理で利用される公開鍵と秘密鍵は,ユーザー・プロファイルに格納される証明書のローカル・ストアから,Crypto APIを通じてEFSサービスに提供される。暗号鍵の管理をEFSから分離したことによって,認証の方法に依存しない一貫した暗号処理と証明書管理を提供している。

 今回は,EFSの技術的な側面から,特に暗号に関連した部分を中心に解説を行った。EFSはシステム・レベルでの動作を伴うため,EFSに関連したサービスがすべて稼動するまでは,暗号処理ができない。このため,システム属性のついたファイルや,systemrootフォルダ内のファイルには利用できない。次回の技術面の視点(INからの視点)は,この制限に対してシステム・ボリュームを暗号化することで補完するBitLockerを取り上げる。

 なお,大規模な環境で使っていくためには,証明書の取り扱いや,回復エージェントの秘密鍵の管理など,運用面で注意が必要な要素がいくつかある。これらの要素については,実際に起きている問題の視点(OUT側の視点)として,改めて取り上げることにする。