Файловая система NTFS Механизм EFS

| Категория реферата: Рефераты по информатике, программированию
| Теги реферата: дипломная работа, бесплатные дипломные работы скачать
| Добавил(а) на сайт: Райков.

Предыдущая страница реферата | 1 2 3 4 5 6 | Следующая страница реферата

Регистрация функций обратного вызова

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

Первое шифрование файла

Обнаружив шифрованный файл, драйвер NTFS вызывает функции, зарегистрированные EFS. О состоянии шифрования файла сообщают его атрибуты.
NTFS и EFS имеют специальные интерфейсы для преобразования файла из незашифрованной в зашифрованную форму, но этот процесс протекает в основном под управлением компонентов пользовательского режима. Windows 2000 позволяет шифровать файлы двумя способами: утилитой командной строки cipber или с помощью Windows Explorer. Windows Explorer и cipber используют Win32- функцию EncryptFile экспортируемую Advapi32.dll (Advance Win32 API DLL).
Чтобы получить доступ к API, который нужен для LPC-вызова интерфейсов EFS в
Lsasrv, Advapi32 загружает другую DLL, Feclient.dll (File Encryption Client
DLL).

Получив LPC-сообщение c запросом на шифрование файла от Feclient,
Lsasrv использует механизм олицетворения Windows 2000 для подмены собой пользователя, запустившего программу, шифрующую файл (cipber или Windows
Explorer). Это заставляет Windows 2000 воспринимать файловые операции, выполняемые Lsasrv, как операции, выполняемые пользователем, желающим зашифровать файл. Lsasrv обычно работает под учетной записью System. Если бы Lsasrv не олицетворял пользователя, то не получил бы прав на доступ к шифруемому файлу.

Далее Lsasrv создает файл журнала в каталоге System Volume Information, где регистрирует ход процесса шифрования. Имя файла журнала, обычно
EFS0.log, но, если шифруется несколько файлов , 0 заменяется числом, которое последовательно увеличивается на 1, до тех пор, пока не будет получено уникальное имя журнала для текущего шифруемого файла.

CryptoAPI полагается на информацию пользовательского профиля, хранящуюся в реестре, поэтому следующий шаг Lsasrv – загрузка в реестр профиля олицетворяемого пользователя вызовом функции LoadUserProfile из
Userenv.dll (User Environment DLL). Обычно профиль пользователя к этому моменту уже загружен, поскольку Winlogon загружает его при входе пользователя в систему. Но если пользователь регистрируется под другой учетной записью с помощью команды RunAS, то при попытке обращения к зашифрованному файлу под этой учетной записью соответствующий профиль может быть не загружен.

После этого Lsasrv генерирует для файла FEK, обращаясь к средствам шифрования RSA, реализованным в Microsoft Base Cryptographic Provider 1.0.

Создание связок ключей

К этому моменту Lsasrv уже получил FEK и может сгенерировать информацию
EFS, сохраняемую вместе с файлом, включая зашифрованную версию FEK. Lsasrv считывает из параметра реестра HKEY_CURRENT
_USERSoftwareMicrosoftWindows
NTCurrentVersionEFSCurrentKeysCertificateHash значение, присвоенное пользователю, который затребовал операцию шифрования, и получает сигнатуру открытого ключа этого пользователя. Этот раздел не появляется в реестре, если ни один файл или каталог не зашифрован. Lsasrv использует эту сигнатуру для доступа к открытому ключу пользователя и для шифрования FEK.

Теперь Lsasrv может создать информацию, которую EFS сохранит вместе с файлом. EFS хранит в зашифрованном файле только один блок информации, в котором содержаться записи для всех пользователей этого файла. Данные записи называются элементами ключей (key entries); они хранятся в области сопоставленных с файлом данных EFS, которая называется Data Decryption
Field (DDF2). Совокупность нескольких элементов ключей называется связкой ключей (key ring), поскольку EFS позволяет нескольким лицам совместно использовать шифрованный файл.

Формат данных EFS, сопоставленных с файлом, и формат элемента ключа показан на рисунке. В первой части элемента ключа EFS хранит информацию, достаточную для точного описания открытого ключа пользователя. В нее входит пользовательский идентификатор защиты (SID), имя контейнера, в котором хранится ключ, имя компонента доступа к криптографическим сервисам и хеш сертификата криптографической пары. Во второй части элемента ключа содержится шифрованная версия FEK. Lsasrv шифрует FEK через CryptoAPI по алгоритму RSA с применением открытого ключа данного пользователя.

Далее Lsasrv создает еще одну связку ключей, содержащую элементы ключей восстановления (recovery key entries). EFS хранит информацию об этих элементах в поле файла DRF6. Формат элементов DRF идентичен формату DDF.
DRF служит для расшифровки пользовательских данных по определенным учетным записям (агентов восстановления) в тех случаях, когда администратору нужен доступ к пользовательским данным.

Допустим, сотрудник компании использовал CryptoAPI для хранения своего закрытого ключа на смарт-карте, а потом потерял ее. В этом случае восстановить его зашифрованные данные можно только с помощью агентов восстановления.

Агенты восстановления (Recovery Agents) определяются в политике безопасности Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) на локальном компьютере или в домене. Эта политика доступна через оснастку Group Policy (Групповая политика) консоли ММС.
Можно добавить агенты восстановления и указать, какие криптографические пары (обозначенные их сертификатами) могут использовать эти агенты для восстановления шифрованных данных. Lsasrv интерпретирует политику восстановления в процессе своей инициализации или при получении уведомления об изменении политики восстановления. EFS создает DRF-элементы ключей для каждого агента восстановления, используя компонент доступа к криптографическим сервисам, зарегистрированный для EFS-восстановления.
Компонентом по умолчанию служит Base Cryptographic Provider 1.0.

На завершающем этапе создания информации EFS для файла Lsasrv вычисляет контрольную сумму для DDF и DRF по механизму хеширования MD5 из Base
Cryptographic Provider 1.0. Lsasrv хранит вычисленную контрольную сумму в заголовке данных EFS. EFS ссылается на эту сумму при расшифровке, чтобы убедиться в том, что сопоставленные с файлом данные EFS не повреждены и не взломаны.

Шифрование файловых данных

После создания всех данных, необходимых для шифруемого пользователем файла, Lsasrv приступает к шифрованию файла и создает его резервную копию,
Efs0.tmp (если есть другие резервные копии, Lsasrv просто увеличивает номер в имени резервного файла). Резервная копия помещается в тот каталог, где находится шифруемый файл. Lsasrv применяет к резервной копии ограничивающий дескриптор защиты, так что доступ к этому файлу можно получить только по учетной записи System. Далее Lsasrv инициализирует файл журнала, созданный им на первом этапе процесса шифрования и регистрирует в нем факт создания резервного файла. Lsasrv шифрует исходный файл только после его резервирования.

Далее, Lsasrv посылает через NTFS драйверу устройства EFS команду на добавление к исходному файлу созданной информации EFS. NTFS получает эту команду, но поскольку она не понимает команд EFS, то просто вызывает драйвер EFS. Драйвер EFS принимает посланные Lsasrv данные EFS и применяет их к файлу через функции, экспортируемые NTFS. Эти функции позволяют EFS добавить к NTFS-файлу атрибут $LOGGED_UTILITY_STREAM. После этого управление возвращается к Lsasrv, который копирует содержимое шифруемого файла в резервный. Закончив создание резервной копии (в том числе скопировав все дополнительные потоки данных), Lsasrv отмечает в файле журнала, что резервный файл находится в актуальном состоянии. Затем Lsasrv посылает NTFS другую команду, требуя зашифровать содержимое исходного файла.

Получив от EFS команду на шифрование файла, NTFS удаляет содержимое исходного файла и копирует в него данные резервного. По мере копирования каждого раздела файла NTFS сбрасывает данные раздела из КЭШа файловой системы, и они записываются на диск. Так как файл помечен как шифрованный,
NTFS вызывает EFS для шифрования раздела данных перед записью на диск. EFS использует незашифрованный FEK, переданный NTFS, чтобы шифровать файловые данные по алгоритму DESX порциями, равными по размеру одному сектору (512 байт).

В версиях Windows 2000, разрешенных к экспорту за пределы США, драйвер
EFS реализует 56-битный ключ шифрования DESX, тогда как в версии, подлежащей использованию только в США, длина ключа DESX равна 128 битам.

После того как файл зашифрован, Lsasrv регистрирует в файле журнала, что шифрование успешно завершено, и удаляет резервную копию файла. В заключении
Lsasrv удаляет файл журнала и возвращает управление приложению, запросившему шифрование файла.

Схема процесса шифрование файла через EFS

1. Загружается профиль пользователя, если это необходимо.

Рекомендуем скачать другие рефераты по теме: бесплатные рефераты и курсовые, сочинение на тему зимой.

Claw.ru | Рефераты по информатике, программированию | Файловая система NTFS Механизм EFS

Файловая система NTFS Механизм EFS

Категории:

Поделитесь этой записью или добавьте в закладки

Рефераты от А до Я

Полезные заметки