Encrypting File System в семействе Windows Server 2003

Encrypting File System в семействе Windows Server 2003

Знакомьтесь с Encrypting File System (EFS) - сервисом прозрачного шифрования файлов, используемым в семействе операционных систем Windows Server 2003. EFS описывается в статье в том виде, в каком он существует в Windows XP Professional и Windows Server 2003. Сначала мы рассмотрим архитектуру EFS: работу, восстановление данных и компоненты EFS. Затем расскажем, как использовать EFS из оболочки и программным способом. В конце статьи будут рассмотрены некоторые вопросы защиты с помощью EFS.

Аннотация

Содержание

Введение
Архитектура
Использование EFS
Программное использование
Безопасность
Об авторах
Справочная информация

Введение

EFS (Encrypting File System) - сервис прозрачного шифрования файлов, входящий в операционные системы семейства Windows Server 2003. EFS обеспечивает конфиденциальность, но не гарантирует целостность и защиту на основе аутентификации. В нем имеются дополнительные средства восстановления данных, позволяющие обращаться к файлам, пользовательские ключи к которым утеряны или уничтожены. Кроме того, EFS обеспечивает совместный доступ нескольких пользователей к зашифрованному файлу по их удостоверениям доступа.

EFS описывается в этой статье в том виде, в каком он существует в Windows XP Professional и Windows Server 2003. Сначала мы рассмотрим архитектуру EFS, в том числе работу, восстановление данных и компоненты EFS. Затем расскажем, как использовать EFS из оболочки и программно. В конце статьи будут рассмотрены некоторые вопросы защиты с помощью EFS.

Архитектура

Ключи и сертификаты

В EFS в качестве удостоверений доступа используются стандартные сертификаты x509. Каждый защищенный файл шифруется по алгоритму симметричного шифрования с помощью генерируемого случайным образом FEK (File Encryption Key). EFS создает "оболочку" для FEK, шифруя его с открытым ключом из одного или нескольких EFS-сертификатов. У пользователя, который обращается к зашифрованному файлу, должен быть закрытый ключ, соответствующий одному из открытых ключей, заданных при создании "оболочки" FEK. Любой, у кого есть доступ к одному из закрытых ключей, может обратиться к файлу, сначала расшифровав "обернутый" FEK по закрытому ключу, а затем расшифровав файл по восстановленному FEK.

Работа

EFS выполняет четыре основных операции: открытие, чтение, запись и преобразование файлов. Каждая из этих операций рассматривается в следующих разделах. Поскольку EFS - прозрачный сервис, открытие, чтение и запись зашифрованных файлов не отличаются от операций с обычными файлами: приложения используют обычный Win32 API. Преобразование файлов - это шифрование текстового файла или расшифровка зашифрованного файла. Для преобразования нужен специальный интерфейс, рассматриваемый далее.

Открытие

Для открытия зашифрованных файлов приложение использует стандартные Win32-функции CreateFile() или OpenFile(). При открытии зашифрованного файла EFS развертывает (unwraps) ключ шифрования файла и создает контекст, необходимый для шифрования или дешифрования данных.

Чтение

Для чтения зашифрованных файлов приложения используют стандартные Win32-функции ReadFile(), ReadFileEx() и ReadFileScatter(). При чтении зашифрованного файла данные сначала считываются в память, и EFS расшифровывает данные "на лету". Расшифрованные данные возвращаются приложению. Когда приложение запрашивает проецирование зашифрованного файла в память, данные расшифровываются непосредственно перед проецированием в память.

Write

Для записи зашифрованных файлов приложение использует стандартные Win32-функции WriteFile(), WriteFileEx() и WriteFileScatter(). При записи зашифрованного файла EFS шифрует данные "на лету", затем зашифрованные данные записываются на диск. Когда приложение запрашивает отмену проецирования файла в память, проецируемые данные шифруются перед их записью обратно на диск. Преобразование

Одним из главных требований при проектировании процесса преобразования заключалось в том, чтобы данные никогда не терялись - даже при отключении питания или другом катастрофическом сбое. Поэтому в EFS зложен очень осторожный подход к хранению резервных копий расшифрованных данных, которые сохраняются до тех пор, пока преобразование не завершится полностью.

Когда EFS получает запрос на преобразование файла, выполняется несколько операций.

Сначала EFS производит несколько проверок, в частности, можно ли шифровать файл и достаточно ли на диске места для шифрования файла. Если файл помечен как системный или находится в каталоге %systemroot%, его нельзя шифровать.
Затем EFS генерирует ключ шифрования файла и "заворачивает" его в открытый ключ текущего пользователя. Если задана политика восстановления (описывается ниже), то FEK, кроме того, "обертывается" в открытые ключи агентов восстановления.
После того как ключ шифрования файла подготовлен, создаются метаданные EFS. В них содержится DDF (Data Decryption Field), представляющее собой FEK, обернутый во все открытые ключи пользователей, которым предоставлен доступ к файлу. Метаданные также содержат DRF (Data Recovery Field), представляющее собой FEK, обернутый во все открытые ключи агентов восстановления. EFS запоминает в метаданных и другую информацию, такую как версия EFS и алгоритм шифрования.
Далее EFS создает в каталоге временный файл. Для резервирования каждый поток данных в исходном файле копируется во временный файл. Потом каждый поток данных в исходном файле усекается до нулевой длины, а затем длине потока снова присваивается первоначальное значение. В результате все данные потока удаляются. EFS записывает метаданные в исходный файл. С этого момента у EFS имеются текстовые данные во временном файле и пустой исходный файл, помеченный как зашифрованный (поскольку для него имеются метаданные EFS).
EFS читает потоки из временного файла и записывает их в исходный файл. Благодаря транспарентности EFS данные шифруются в процессе записи на диск.
Когда все данные записаны обратно в исходный файл, EFS проверяет, что файл зашифрован успешно, и удаляет временный файл. Если по каким-то причинам преобразование потерпело неудачу, EFS восстанавливает первоначальное состояние файла.

Преобразование в текст выполняется аналогично: тоже создается временный файл, в который записывается исходный. Затем исходный файл усекается, данные считываются из временного файла и записываются в исходный в незашифрованном виде.

Примечание Побочный эффект этой процедуры состоит в том, что, когда временный файл удаляется, части текста могут остаться в неиспользуемом дисковом пространстве. Вы можете, запустив утилиту командной строки cipher.exe с ключом /W, стереть содержимое пространства раздела, помеченного как свободное. Эта операция стирает оставшиеся после шифрования части текста файлов, не умещающихся в одну запись MFT (Master File Table). Размер записи MFT зависит от размера кластера диска и обычно составляет 1024 байта. Уместится ли файл в запись MFT, зависит от того, сколько места осталось в записи MFT после формирования метаданных файла. В MFT могут содержаться и другие данные, например атрибуты файла или потоки. Кроме того, в файле может быть больше данных, чем вмещает запись MFT. Дополнительную информацию о MFT см. в Microsoft Developer Network, в разделе Master File Table and MFT Zone документации Platform SDK.

Чтобы полностью исключить вероятность того, что на диске останутся части текста, рекомендуется никогда не выполнять преобразование текстовых файлов. Вместо этого следует создать каталог и пометить его как зашифрованный. Файл, создаваемый в зашифрованном каталоге, сразу же записывается на диск в зашифрованном виде, а временный файл не создается.

Очевидно, когда пользователю требуется зашифровать уже существующие файлы, этот прием не сработает. В таком случае рекомендуется преобразовать все существующие файлы, которые нужно защитить, а затем с помощью cipher.exe очистить все свободное пространство раздела. После этого следует создавать все файлы, требующие защиты, в зашифрованных каталогах.

Восстановление данных

В EFS есть средства восстановления данных. Они применяются, чтобы восстановить зашифрованные файлы в случаях, когда пользовательские ключи утеряны или уничтожены. Кроме того, они позволяют организациям определять и применять политику доступа к данным, хранящимся в компьютерах. Восстановление данных определяется политикой восстановления, автоматически активизируемой на компьютерах домена и отключаемой на изолированных компьютерах. В домене политика восстановления распространяется из активного каталога через политику группы.

Если определена политика восстановления, все FEK дополнительно обертываются открытыми ключами агентов восстановления. Эти обернутые FEK образуют DRF (Data Recovery Field), которые EFS перезаписывает при каждой операции, чтобы гарантированно использовалась последняя версия политики восстановления.

Очень большое значение имеют закрытые ключи агента восстановления. У каждого зашифрованного файла домена имеется свой FEK, обернутый открытым ключом восстановления. Если злоумышленник получит доступ к соответствующему закрытому ключу восстановления, он сможет обращаться к любому зашифрованному файлу домена. Защитить эти ключи крайне важно.

Политика восстановления

Домен

Политика восстановления, по умолчанию используемая в домене, определяется администратором домена. Когда администратор домена первый раз входит на контроллер домена, генерируется EFS-сертификат восстановления, записываемый в локальный профиль. Этот сертификат добавляется в политику восстановления. Затем любой администратор домена может создать в домене агенты восстановления и сгенерировать EFS-сертификаты для этих агентов. Полученные сертификаты можно добавить в политику восстановления.

При загрузке компьютера, работающего в домене, политика группы, в том числе политика восстановления, считывается из Active Directory. Затем политика восстановления, ранее определенная на этом компьютере, замещается полученной из политики группы. Компьютер периодически опрашивает Active Directory, не изменилась ли политика группы, в частности политика восстановления.

Политика восстановления, полученная из Active Directory, локально кэшируется на компьютере, работающем в домене. Если компьютер не может связаться с Active Directory и загрузить обновленную политику, используется кэшированная политика.

Администратор домена также может задать для домена пустую политику восстановления. Пустая политика восстановления отключает EFS для клиентов, работающих под Windows 2000, но не для клиентов, использующих XP или Windows Server 2003. Определение пустой политики восстановления - вовсе не то же самое, что полное отсутствие политики, так как администратор создает политику, но не добавляет в нее никакие агенты восстановления. Если администратор удалит политику, политика восстановления будет считаться отсутствующей.

Объекты политики группы можно создавать на нескольких уровнях дерева Active Directory. Кроме того, на компьютере, работающем в домене, можно определить локальную политику восстановления. Однако она никогда не будет использоваться, так как политика восстановления, определенная для домена, имеет более высокий приоритет. Дополнительную информацию о распространении и приоритетах политики группы см. в справочной системе Windows Server 2003.

Автономный компьютер

Изначально на автономных компьютерах политики восстановления нет. Администраторы автономных компьютеров могут изменять политику восстановления EFS, в частности создать и добавить в политику сертификаты восстановления.

Компоненты

Чтобы сервис EFS работал прозрачно, его компоненты должны присутствовать на многих уровнях операционной системы. Эти компоненты делятся на две группы: работающие в пользовательском режиме и работающие в режиме ядра. На рис. 1 показаны компоненты, используемые при обращении к файлам. Компоненты, помеченные (EFS), содержат только код EFS, а компоненты с обозначением EFS в рамке, лишь частично состоят из кода EFS. Ниже описан каждый из компонентов, содержащих код EFS.

Рис. 1. Компоненты операционной системы и их взаимосвязь

{Рисунок:
winlogon - winlogon
EFS - EFS
Shell - Shell
RPC - RPC
App - Приложение
Feclient - Feclient
Efsadu - Efsadu
LSA - LSA
Crypt - шифрование
CSP - CSP
Mm (Memory Manager) - Диспетчер памяти
I/O Manager - Диспетчер ввода-вывода
Kernel - Ядро
Cc (Cache Controller) - Контроллер кэша
MUP (Multiple UNC Provider) - MUP (многосетевой UNC-провайдер)
NTFS - NTFS
WebDAV - WebDAV
ksecdd - ksecdd
}

Компоненты пользовательского режима

Код EFS содержится в пяти компонентах пользовательского режима: LSA, Feclient, Efsadu, Shell и Winlogon. Взаимосвязь между ними показана на рис. 1. Каждый из этих компонентов подробно рассматривается в следующих разделах.

Local Security Authority

LSA (Local Security Authority) выполняет большую часть EFS-операций пользовательского режима. LSA отвечает на поступающие от ядра запросы на создание FEK и обертывает FEK открытыми ключами пользователя и агентов восстановления. FEK возвращается ядру и используется при шифровании файла. Кроме того, LSA выполняет обратную операцию: развертывает FEK и возвращает его ядру для расшифровки файла.

При обертывании LSA обращается к политике восстановления, чтобы определить, нужно ли обертывать FEK открытыми ключами агентов восстановления. При развертывании тоже происходит обращение к политике восстановления, чтобы определить, существуют ли дополнительные или новые сертификаты, в которые нужно заново обернуть FEK. Кроме того, LSA проверяет, изменился ли EFS-сертификат текущего пользователя, поскольку в таком случае также требуется повторное обертывание FEK.

LSA экспортирует несколько RPC-интерфейсов для взаимодействия с Feclient и несколько LPC-интерфейсов для взаимодействия с Ksecdd.

Для большей производительности LSA хранит в кэше описатели (handles) закрытых ключей, используемых для обертывания и развертывания FEK. Эти описатели указывают на закрытые ключи, остающиеся в CSP, т. е. находящиеся в безопасном месте.

Feclient

Win32 API передают все относящиеся к EFS вызовы библиотеке Feclient.DLL. Затем Feclient вызывает RPC-интерфейсы LSA, используемые EFS. Причина такого двухуровневого вызова EFS-процедур LSA заключается в том, что EFS поддерживает удаленное хранение зашифрованных файлов на других серверах, работающих под управлением Windows Server 2003 или Windows Server 2000. Feclient определяет, на каком сервере хранится файл, и обращается к LSA этого сервера.

Efsadu

Efsadu.DLL реализует пользовательский интерфейс (UI) настройки EFS-атрибутов. Эта DLL вызывается, когда из диалогового окна Properties пользователь открывает диалоговое окно Advanced и щелкают кнопку Details, находящуюся рядом с Encrypt file. По щелчку этой кнопки открывается диалоговое окно Encryption Details, рассматриваемое далее.

Оболочка

Имена зашифрованных файлов могут показываться оболочкой (в окнах Windows Explorer) зеленым цветом. Оболочка определяет, зашифрован ли файл, вызывая EFS-функцию, возвращающую состояние файла.

Winlogon

Winlogon по-разному работает на контроллерах домена и локальных компьютерах. Когда администратор домена впервые входит в контроллер домена, Winlogon создает политику восстановления по умолчанию. На локальном компьютере Winlogon обращается к механизму конфигурирования защиты, чтобы применить EFS-политику восстановления, получаемую из политики группы.

Компоненты режима ядра

Три компонента режима ядра содержат код EFS: NTFS, WebDAV Redirector и Ksecdd. Взаимосвязь между ними показана на рис. 1.

NTFS

Большая часть кода EFS режима ядра содержится в драйвере NTFS. Этот драйвер отвечает на FSCTL-команды (file system controls), отправляемые LSA для шифрования или дешифрования файлов. При открытии файла драйвер передает обернутый FEK компоненту Ksecdd, чтобы LSA развернул этот FEK. Затем драйвер расшифровывает данные, которые читаются из файла, и шифрует данные, которые записываются в файл.

EFS API в драйвере NTFS также предоставляет ряд функций чтения и записи файлов в режиме побитового ввода (raw mode). Режим побитового ввода позволяет напрямую читать и записывать шифрованный текст. Это позволяет Win32 API резервного копирования файлов при соответствующих операциях читать и записывать зашифрованные данные, сохраняя конфиденциальность. Этот API предназначен только для приложений резервного копирования.

Драйвер NTFS хранит в кэше неразвернутые FEK, принимаемые от LSA. Это повышает производительность, когда файлы несколько раз открываются один за другим через небольшие промежутки времени. По умолчанию FEK хранятся в кэше пять секунд. При настройке можно задать время кэширования в пределах от двух до тридцати секунд.

WebDAV Redirector

Клиентский редиректор WebDAV управляет зашифрованными файлами в общих каталогах WebDAV. Редиректор считывает файл с сервера и локально кэширует его на время редактирования. Когда файл закрывается, редиректор сохраняет файл на сервере. Во время локального кэширования файла редиректор вызывает NTFS-драйвер для чтения и записи файла.

Когда файл записывается на сервер, клиентский редиректор вызывает BackupRead() для локально кэшированного файла, получает данные и сохраняет их на сервере. BackupRead()возвращает зашифрованное содержимое файла, при этом в компьютере файл остается в зашифрованном виде. Когда файл считывается с сервера, редиректор вызывает для кэшированного файла функцию BackupWrite(), принимающую зашифрованные данные и записывающую их в зашифрованный NTFS-файл.

Ksecdd

Ksecdd - это очень "тонкий" компонент, который NTFS вызывает, чтобы обмениваться данными с LSA. Ksecdd осуществляет LPC-взаимодействие с LSA.

Использование EFS

EFS разработан как сервис, прозрачный для пользователей и приложений. Однако пользователям для выполнения некоторых операций требуется взаимодействовать с EFS напрямую. К таким операциям относятся преобразование файлов (шифрование и дешифрование), а также добавление и удаление пользователей файлов. Все эти действия выполняются в диалоговом окне Advanced (рис. 2), которое вызывается из окна Properties, открываемого щелчком файла правой кнопкой мыши в Windows Explorer.

Рис. 2. Диалоговое окно Advanced, открываемое в окне Properties

Шифрование

Для шифрования файла установите флажок Encrypt contents to secure data в диалоговом окне Advanced и щелкните OK. Тогда EFS преобразует файл, как было описано ранее.

При шифровании каталога выполняются те же операции, что и при шифровании файла. Если каталог пустой, в заголовке каталога устанавливается флаг шифрования (encrypted flag), сообщающий EFS, что любой файл, создаваемый в этом каталоге, должен шифроваться. Если каталог не пустой, открывается еще одно диалоговое окно (рис. 3), запрашивающее, нужно ли зашифровать только эту папку или вместе с подпапками и файлами.

Рис. 3. Диалоговое окно для подтверждения шифрования

Если выбран переключатель Apply changes to this folder only, каталог обрабатывается так, будто он пустой, и в его заголовке устанавливается флаг шифрования. Если же выбран переключатель Apply changes to this folder, subfolders and files, то каждый файл в каталоге и всех его подкаталогах шифруется в соответствии с приведенным выше описанием. Флаг шифрования устанавливается в заголовке каждого подкаталога и текущего каталога.

Дешифрование

Дешифрование - операция, обратная шифрованию. Выполняется процедура, аналогичная процедуре шифрования файла. Чтобы расшифровать файл, снимите флажок Encrypt contents to secure data в диалоговом окне Advanced и щелкните OK. Тогда EFS расшифрует файл, как было описано ранее.

При дешифровании каталога выполняются те же операции, что и при дешифровании файла. Если каталог пустой, в заголовке каталога снимается флаг шифрования. Если каталог непустой, открывается еще одно диалоговое окно (рис. 4), запрашивающее, нужно ли дешифровать только эту папку или вместе с подпапками и файлами.

Рис. 4. Диалоговое окно для подтверждения дешифрования

Если установлен переключатель Apply changes to this folder only, каталог обрабатывается так, будто он пустой, и в заголовке каталога снимается флаг шифрования. Если же выбран переключатель Apply changes to this folder, subfolders and files, то каждый файл в каталоге и всех его подкаталогах дешифруется в соответствии с приведенным выше описанием. Флаг шифрования снимается в заголовке каждого подкаталога и текущего каталога.

Добавление пользователей

При добавлении пользователей какого-либо файла предоставляется криптографический доступ к этому файлу. Под криптографическим доступом понимается, что пользователи могут дешифровать и шифровать файл, а также добавлять или удалять других пользователей. Однако наличие криптографического доступа не означает, что у пользователя есть права доступа в файловой системе. Права доступа в файловой системе задаются списками управления доступом к файлам (ACL) в NTFS. Чтобы у пользователя был полный доступ к защищенному файлу, нужно не только предоставить криптографический доступ, но и указать в ACL, что данному пользователю разрешается обращаться к файлу.

Кнопка Details в диалоговом окне Advanced открывает диалоговое окно Encryption Details (рис. 5).

Рис. 5. Диалоговое окно Encryption Details

С помощью кнопки Add можно указать дополнительных пользователей файла, EFS-сертификат которых хранится в списках сертификатов Trusted People или Other People, известных текущему пользователю. Кроме того, можно искать пользователей в Active Directory.

Удаление пользователей

Удаление пользователя файла запрещает ему криптографический доступ к этому файлу. Эта операция выполняется аналогично добавлению пользователей. Щелчком кнопки Details в диалоговом окне Advanced открывается диалоговое окно Encryption Details (рис. 5).

С помощью кнопки Remove удаляются пользователи файла. Как и при добавлении пользователей, при удалении отменяется только криптографический доступ к файлу. Если не вносить изменения в ACL файловой системы, удаленные пользователи по-прежнему будут обладать правами доступа файловой системы к этому файлу.

Восстановление

Восстановление файла выполняется так же, как и его дешифрование. Агент восстановления должен войти на компьютер, где находится файл, и у него должен быть доступ к закрытому ключу сертификата восстановления.

Агент восстановления может открыть файл и сохранить его в новом файле, находящемся вне иерархии зашифрованных каталогов, тем самым сохранив файл в незашифрованном виде.

Чтобы агенту восстановления не приходилось импортировать закрытый ключ сертификата восстановления на компьютер пользователя, можно настроить станцию восстановления (recovery station). Тогда можно сделать так, чтобы пользователи отправляли файлы, нуждающиеся в восстановлении, на эту станцию, а агент восстановления входил на нее и восстанавливал файлы.

Программное использование

Интерфейсы

EFS предоставляет несколько открытых Win32-интерфейсов, работающих с зашифрованными файлами. Эти интерфейсы доступны в Platform SDK. Ниже приведена базовая информация по этим интерфейсам, а полное описание содержится в документации Platform SDK.

EncryptFile

Определение

BOOL WINAPI EncryptFile (
LPCWSTR   lpFilename)

Параметры

lpFilenameПуть к шифруемому файлу или каталогу.

Возвращаемые значения

Если функция выполнена успешно, возвращается ненулевое значение.

Если функция потерпела неудачу, возвращается 0. Для получения информации об ошибке вызовите GetLastError().

Описание

Дополнительную информацию и пример исходного кода см. в разделе EncryptFile Microsoft Developer Network.

DecryptFile

Определение

BOOL WINAPI DecryptFile (
LPCWSTR   lpFilename,
DWORD   dwReserved)

Параметры

lpFilenameПуть к дешифруемому файлу или каталогу.
dwReservedЗарезервирован на будущее, должен быть нулем.

Возвращаемые значения

Если функция выполнена успешно, возвращается ненулевое значение.

Если функция потерпела неудачу, возвращается 0. Для получения информации об ошибке вызовите GetLastError().

Описание

Дополнительную информацию и пример исходного кода см. в разделе DecryptFile Microsoft Developer Network.

AddUsersToEncryptedFile

Определение

DWORD WINAPI AddUsersToEncryptedFile (
LPCWSTR   lpFilename,
PENCRYPTION_CERTIFICATE_LIST   pUsers)

Параметры

lpFilenameПуть к зашифрованному файлу, к которому добавляются пользователи.
pUsersУказатель на структуру ENCRYPTION_CERTIFICATE_LIST, содержащую список ключей пользователей, добавляемых в файл.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Если функция потерпела неудачу, возвращается системный код ошибки. Для получения информации об ошибке вызовите GetLastError().

Описание

Дополнительную информацию и пример исходного кода см. в разделе AddUsersToEncryptedFile Microsoft Developer Network.

RemoveUsersFromEncryptedFile

Определение

DWORD WINAPI RemoveUsersFromEncryptedFile (
LPCWSTR   lpFilename,
PENCRYPTION_CERTIFICATE_HASH_LIST   pHashes)

Параметры

lpFilenameПуть к зашифрованному файлу, для которого удаляются пользователи.
pHashesУказатель на структуру ENCRYPTION_CERTIFICATE_HASH_LIST, содержащую список удаляемых из данного файла хэшей сертификатов.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Описание

Дополнительную информацию и пример исходного кода см. в разделе RemoveUsersFromEncryptedFile Microsoft Developer Network.

DuplicateEncryptionInfoFile

Копирует метаданные EFS из одного файла или каталога в другой. Позволяет пользователю скопировать файл, не запрашивая доступ ко всем сертификатам, в которые обернут FEK. Функция особенно важна для разработчиков приложений, в которых к зашифрованным файлам будут обращаться несколько пользователей. С ее помощью разработчики могут обеспечить, чтобы для всех пользователей применялись общие параметры шифрования и обернутые FEK.

Определение

DWORD WINAPI DuplicateEncryptionInfoFile (
LPCTSTR   lpSourceFilename,
LPCTSTR   lpDestinationFilename,
DWORD   dwCreationDistribution,
DWORD   dwAttributes,
LPSECURITY_ATTRIBUTES   lpSecurityAttributes)

Параметры

lpSourceFilenameПуть к зашифрованному файлу или каталогу, из которого читаются метаданные EFS.
lpDestinationFilenameПуть к файлу или каталогу, в который записываются метаданные EFS. Если источник - каталог, то и адресат должен быть каталогом. Если источник - файл, то адресат тоже должен быть файлом.

dwCreationDistributionЗначение, которое берется из следующей таблицы.

CREATE_NEW	Создать файл или каталог адресата, только если его еще нет. Иначе функция терпит неудачу
CREATE_ALWAYS	Всегда создавать файл или каталог адресата. При указании любого значения, отличного от CREATE_NEW, всегда используется это значение

dwAttributesФайловые атрибуты файла или каталога адресата. Эта функция игнорирует атрибуты FILE_READ_ONLY и FILE_ENCRYPTED.
lpSecurityAttributesУказатель на структуру SECURITY_ATTRIBUTES, задающую атрибуты защиты файла или каталога адресата, если его еще нет. При указании NULL применяется описатель защиты по умолчанию, полученный от родителя.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Описание

Дополнительную информацию и пример исходного кода см. в разделе DuplicateEncryptionInfoFile Microsoft Developer Network.

QueryUsersOnEncryptedFile

Эта функция запрашивает и возвращает список хэшей сертификатов пользователей зашифрованного файла.

Определение

DWORD WINAPI QueryUsersOnEncryptedFile (
LPCWSTR   lpFilename,
PENCRYPTION_CERTIFICATE_HASH_LIST   pUsers)

Параметры

lpFilenameПуть к зашифрованному файлу, для которого возвращается список пользователей.
pUsersУказатель на структуру ENCRYPTION_CERTIFICATE_HASH_LIST, принимающую список пользователей.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Описание

Дополнительную информацию и пример исходного кода см. в разделе QueryUsersOnEncryptedFile Microsoft Developer Network.

QueryRecoveryAgentsOnEncryptedFile

Запрашивает и возвращает список хэшей сертификатов агентов восстановления зашифрованного файла.

Определение

DWORD WINAPI QueryRecoveryAgentsOnEncryptedFile (
LPCWSTR   lpFilename,
PENCRYPTION_CERTIFICATE_HASH_LIST   pRecoveryAgents)

Параметры

lpFilenameПуть к зашифрованному файлу, для которого возвращается список агентов восстановления.
pRecoveryAgentsУказатель на структуру ENCRYPTION_CERTIFICATE_HASH_LIST, принимающую список агентов восстановления.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Описание

Дополнительную информацию и пример исходного кода см. в разделе QueryRecoveryAgentsOnEncryptedFile Microsoft Developer Network.

FileEncryptionStatus

Получает информацию о состоянии EFS данного файла, в частности, зашифрован ли файл и можно ли его шифровать.

Определение

BOOL FileEncryptionStatus (
LPCTSTR   lpFilename,
LPDWORD   lpStatus)

Параметры

lpFilenameПуть к файлу или каталогу, состояние которого вы хотите узнать.

lpStatusУказатель на переменную, в которую заносится состояние файла. Возможные значения перечислены в следующей таблице.

FILE_ENCRYPTABLE	Файл можно шифровать
FILE_IS_ENCRYPTED	Файл зашифрован
FILE_SYSTEM_ATTR	Файл является системным. Системные файлы нельзя шифровать
FILE_ROOT_DIR	Файл является корневым каталогом. Корневые каталоги нельзя шифровать
FILE_SYSTEM_DIR	Файл является системным каталогом. Системные каталоги нельзя шифровать
FILE_UNKNOWN	Состояние шифрования файла неизвестно. Файл можно шифровать
FILE_SYSTEM_NOT_SUPPORT	Файловая система не поддерживает шифрование
FILE_USER_DISALLOWED	Файл нельзя шифровать
FILE_READ_ONLY	Файл доступен только для чтения

Возвращаемые значения

Если функция выполнена успешно, возвращается ненулевое значение.

Если функция потерпела неудачу, возвращается 0. Для получения информации об ошибке вызовите GetLastError().

Описание

Дополнительную информацию и пример исходного кода см. в разделе FileEncryptionStatus Microsoft Developer Network.

SetUserFileEncryptionKey

Задает EFS-сертификат текущего пользователя.

Определение

BOOL WINAPI SetUserFileEncryptionKey (
PENCRYPTION_CERTIFICATE   pEncryptionCertificate)

Параметры

pEncryptionCertificateУказатель на структуру ENCRYPTION_CERTIFICATE, содержащую пользовательский ключ.

Возвращаемые значения

Если функция выполнена успешно, возвращается ERROR_SUCCESS.

Описание

Дополнительную информацию и пример исходного кода см. в разделе SetUserFileEncryptionKey Microsoft Developer Network.

EncryptionDisable

Разрешает или запрещает шифрование заданного каталога.

Определение

BOOL WINAPI EncryptionDisable (
LPCWSTR   lpDirectoryname,
BOOL   bDisable)

Параметры

lpDirectoryNameПуть к каталогу, шифрование которого разрешается или запрещается.
bDisableЕсли параметр имеет значение TRUE, шифрование запрещается, если FALSE - разрешается.

Возвращаемые значения

Если функция выполнена успешно, возвращается ненулевое значение.

Если функция потерпела неудачу, возвращается 0. Для получения информации об ошибке вызовите GetLastError().

Описание

Дополнительную информацию и пример исходного кода см. в разделе EncryptionDisable Microsoft Developer Network.

Структуры данных

В описанных выше EFS-функциях используется несколько структур данных. Эти структуры описаны ниже.

EFS_CERTIFICATE_BLOB

Содержит реальные данные сертификата.

Определение

typedef struct _CERTIFICATE_BLOB {
DWORD   dwCertEncodingType;
DWORD   cbData;
PBYTE   pbData;
} EFS_CERTIFICATE_BLOB, *PEFS_CERTIFICATE_BLOB;

Члены

dwCertEncodingTypeТип кодирования сертификата. Возможные значения перечислены в следующей таблице.

CRYPT_ASN_ENCODING CRYPT_NDR_ENCODING

X509_ASN_ENCODING X509_NDR_ENCODING
cbDataЧисло байтов в буфере pbData.
pbDataДвоичные данные сертификата. Формат сертификата задается членом dwCertEncodingType.

Описание

Дополнительную информацию и пример исходного кода см. в разделе EFS_CERTIFICATE_BLOB Microsoft Developer Network.

ENCRYPTION_CERTIFICATE

Содержит сертификат.

Определение

typedef struct _ENCRYPTION_CERTIFICATE {
DWORD   cbTotalLength;
SID   *pUserSid;
PEFS_CERTIFICATE_BLOB   pCertBlob;
} ENCRYPTION_CERTIFICATE, *PENCRYPTION_CERTIFICATE;

Члены

cbTotalLengthРазмер структуры в байтах.
*pUserSid SID пользователя, владеющего сертификатом.
pCertBlobУказатель на структуру EFS_CERTIFICATE_BLOB.

Описание

Дополнительную информацию и пример исходного кода см. в разделе ENCRYPTION_CERTIFICATE Microsoft Developer Network.

Дополнительную информацию о структуре данных SID см. в разделе SID Microsoft Developer Network.

ENCRYPTION_CERTIFICATE_LIST

Содержит список сертификатов.

Определение

typedef struct _ENCRYPTION_CERTIFICATE_LIST {
DWORD   nUsers;
PENCRYPTION_CERTIFICATE   *pUsers;
} ENCRYPTION_CERTIFICATE_LIST, *PENCRYPTION_CERTIFICATE_LIST;

Члены

nUsersКоличество сертификатов в списке.
*pUsersУказатель на первую структуру ENCRYPTION_CERTIFICATE в списке.

Описание

Дополнительную информацию и пример исходного кода см. в разделе ENCRYPTION_CERTIFICATE_LIST Microsoft Developer Network.

EFS_HASH_BLOB

Содержит данные хэша сертификата.

Определение

typedef struct _EFS_HASH_BLOB {
DWORD   cbData;
PBYTE   pbData;
} EFS_HASH_BLOB, *PEFS_HASH_BLOB;

Члены

cbDataЧисло байтов в буфере pbData.
pbDataХэш сертификата.

Описание

Дополнительную информацию и пример исходного кода см. в разделе EFS_HASH_BLOB Microsoft Developer Network.

ENCRYPTION_CERTIFICATE_HASH

Содержит хэш сертификата.

Определение

typedef struct _ENCRYPTION_CERTIFICATE_HASH {
DWORD   cbTotalLength;
SID   *pUserSid;
PEFS_HASH_BLOB   pHash;
LPWSTR   lpDisplayInformation;
} ENCRYPTION_CERTIFICATE_HASH, *PENCRYPTION_CERTIFICATE_HASH;

Члены

cbTotalLengthРазмер структуры в байтах.
*pUserSid SID пользователя, владеющего сертификатом.
pHashУказатель на структуру EFS_HASH_BLOB.
lpDisplayInformationИнформация о сертификате, показываемая пользователю.

Описание

Дополнительную информацию и пример исходного кода см. в разделе ENCRYPTION_CERTIFICATE_HASH Microsoft Developer Network.

Дополнительную информацию о структуре данных SID см. в разделе SID Microsoft Developer Network.

ENCRYPTION_CERTIFICATE_HASH_LIST

Содержит список хэшей сертификатов.

Определение

typedef struct _ENCRYPTION_CERTIFICATE_HASH_LIST {
DWORD   nUsers;
PENCRYPTION_CERTIFICATE_HASH   *pUsers;
} ENCRYPTION_CERTIFICATE_HASH_LIST, *PENCRYPTION_CERTIFICATE_HASH_LIST;

Члены

nUsersКоличество хэшей сертификатов в списке.
*pUsersУказатель на первую структуру ENCRYPTION_CERTIFICAT_HASH в списке.

Описание

Дополнительную информацию и пример исходного кода см. в разделе ENCRYPTION_CERTIFICATE_HASH_LIST Microsoft Developer Network.

SECURITY_ATTRIBUTES

Содержит описатель защиты объекта.

Определение

typedef struct _SECURITY_ATTRIBUTES {
DWORD   nLength;
LPVOID   lpSecurityDescriptor;
BOOL   bInheritHandle;
} SECURITY_ATTRIBUTES, *PSECURITY_ATTRIBUTES;

Члены

nLengthРазмер структуры в байтах.
lpSecurityDescriptorУказатель на дескриптор защиты объекта, управляющий доступом к нему. При значении NULL используется дескриптор по умолчанию, получаемый из вызывающего процесса.
bInheritHandlesУказывает, наследуется ли возвращаемый описатель, когда создается новый процесс. Если этот член имеет значение TRUE, новый процесс наследует описатель.

Описание

Дополнительную информацию и пример исходного кода см. в разделе SECURITY_ATTRIBUTES Microsoft Developer Network.

Безопасность

В целом EFS обеспечивает приемлемую конфиденциальность файлов. EFS-компоненты удачно спроектированы и реализованы. Код EFS успешно справляется с очисткой ресурсов по окончании их использования и с восстановлением после системных ошибок, возникших при выполнении операций. Кроме того, EFS-компоненты повторно используют существующий код, обращаясь к системным API при управлении ключами и сертификатами.

Важно отметить, что EFS не используется для обеспечения целостности файлов и защиты на основе аутентификации.

Разработчики EFS сознательно пошли на компромисс между абсолютной безопасностью и удобством. Из-за этих компромиссных решений возможны некоторые граничные случаи, описанные ниже. Эти случаи не относятся к ошибкам - они стали возможными вследствие определенных решений при проектировании и были известны с самого начала. Кроме того, при обычной работе подавляющее большинство пользователей EFS никогда не столкнется с этими граничными случаями. Мы рассмотрим их лишь для того, чтобы подчеркнуть, что применение EFS требует более высокого уровня знаний в области управления файлами.

Во-первых, определенные действия могут привести к тому, что два файла будут использовать один и тот же FEK. Тогда пользователь, имеющий криптографический доступ к одному файлу, сумеет с помощью этого FEK расшифровать другой файл. У такого пользователя должны быть права доступа файловой системы к этому файлу.
Например, Боб создал зашифрованный файл. Затем скопировал его в новый файл с помощью Explorer или других способом на основе Win32-функции CopyFile(). В результате новый файл использует тот же FEK, что и исходный. Если Мэлори получит FEK для одного из этих файлов, она сможет обращаться к обоим файлам.
Чтобы этого избежать, рекомендуется открывать исходный файл в редакторе и для сохранения данных в новом файле выполнять команду Save As. Тогда создается совершенно новый файл с новым FEK.
Во-вторых, когда удаляется пользователь зашифрованного файла, нет абсолютной гарантии, что криптографический доступ полностью запрещен. Если у удаленного пользователя есть резервная копия исходного файла, доступ к которой разрешен, он сможет расшифровать FEK из файла резервной копии и обратиться к новому файлу. У пользователя должны быть права файловой системы на доступ к этому файлу.
Например, Алиса создает зашифрованный файл и добавляет Боба, и тот может обращаться к файлу. Через какое-то время Алиса удаляет Боба из числа пользователей файла. Если бы Боб сохранил FEK файла в период, когда имел к нему доступ, или если бы он сделал резервную копию исходного файла, он смог бы расшифровать новый файл, из которого Алиса его удалила. Для этого Бобу потребовалось бы получить физический доступ к этому файлу и написать код расшифровки файла.
Рекомендаций, как избежать такой ситуации, нет, поскольку пользователь, получив доступ к текстовым данным файла, может скопировать данные на другой носитель, физически не связанный с исходным зашифрованным файлом.
В-третьих, EFS не поддерживает защиту целостности файлов или аутентификацию доступа к файлам. Если пользователь получает права доступа файловой системы к файлу, например каким-то образом обойдя обычный контроль доступа к файлам, то он может заменить исходный зашифрованный файл другим, не уведомляя владельца файла. Конечно, такая ситуация возможна и без применения EFS, но поскольку EFS обеспечивает конфиденциальность, этот пользователь не узнает содержимое исходного зашифрованного файла.
Например, Bob создает зашифрованный файл. Мэлори может каким-то образом получить права доступа файловой системы к этому файлу. Она не может прочитать содержимое файла, но может заменить зашифрованный файл другим файлом, не уведомляя Боба.
Рекомендуемый способ избежать такой ситуации - строго контролировать доступ к файлам и физически ограничивать его, чтобы не допустить атак с подменой (spoofing attacks).

Об авторах

Авторы этого документа - Уэсли Гриффин (Wesley Griffin), Майкл Хейман (Michael Heyman), Ричард Клэйтон (Richard Clayton), Майкл Ст. Джонс (Michael St. Johns) и Дэвид Карман (David Carman) - члены группы Cryptographic Technologies Group в Network Associates Laboratories. Network Associates Laboratories - многопрофильная исследовательская организация, завоевавшая всемирное признание в области сетевой безопасности, криптографических технологий, компонентов инфраструктуры защиты, сред безопасного выполнения, адаптивной защиты сетей, защиты распределенных систем и моделирования архитектуры защиты.

Авторы хотели бы выразить признательность Майку Лаи (Mike Lai), Дэвиду Кроссу (David Cross), Роберту Гу (Robert Gu) и Дрю Купер (Drew Cooper) (все они - сотрудники Microsoft), предоставившим информацию о EFS. Мы также хотели бы поблагодарить Дуга Бейера (Doug Bayer) и Дэйва Томпсона (Dave Thompson) за предоставленные ими ресурсы Microsoft.

Справочная информация

Дэвид Кросс (David Cross) Encrypting File System in Windows XP and Windows Server 2003, Microsoft, август 2002 г.
Microsoft MSDN Library, январь 2002 г.
Раджив Нагар (Rajeev Nagar), О'Рейли (O'Reilly) Windows NT File System Internals: A Developer's Guide, сентябрь 1997 г.