МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Файловая система NTFS Механизм EFS

    недоступны. 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

    _USER\Software\Microsoft\Windows

    NT\CurrentVersion\EFS\CurrentKeys\CertificateHash значение, присвоенное

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

    открытого ключа этого пользователя. Этот раздел не появляется в реестре,

    если ни один файл или каталог не зашифрован. 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 служит для расшифровки пользовательских данных по определенным учетным

    записям (агентов восстановления) в тех случаях, когда администратору нужен

    доступ к пользовательским данным.

    |Пользовательский SID |

    |(S-1-5-21-…) |

    |Имя контейнера |

    |(ее341-2144-55ba…) |

    |Имя компонента доступа |

    |(Microsoft Base |

    |Cryptographic Provider |

    |1.0) |

    |Хэш сертификата EFS |

    |(cb3e4e…) |

    |Зашифрованный FEK |

    |(03fe4f3c…) |

    |Версия |

    |Контрольная сумма |

    |Число элементов ключей |

    |DDF |

    |DDF-элемент ключа 1 |

    |DDF-элемент ключа 2 |

    |Число элементов ключей |

    |DRF |

    |DRF-элемент ключа 1 |

    Допустим, сотрудник компании использовал 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. Загружается профиль пользователя, если это необходимо.

    2. В каталоге System Volume Information создается файл журнала с именем

    EFSx.log, где х – уникальное целое число от 0. По мере выполнения

    следующих этапов в журнал заносятся записи, позволяющие восстановить

    файл после сбоя системы в процессе шифрования.

    3. Base Cryptographic Provider 1.0 генерирует для файла случайное 128-

    битное число, используемое в качестве FEK.

    4. Генерируется или считывается криптографическая пара ключей

    пользователя. Она идентифицируется в HKEY_CURRENT_USER\ Software

    \Microsoft\Windows NT\CurrentVersion \EFS\CurrentKeys\

    CertificateHash.

    5. Для файла создается связка ключей DDF с элементом для данного

    пользователя. Этот элемент содержит копию FEK, зашифрованную с

    помощью открытого EFS-ключа пользователя.

    6. Для файла создается связка ключей DRF. В нем есть элементы для

    каждого агента восстановления в системе, и при этом в каждом

    элементе содержится копия FEK, зашифрованная с помощью открытого EFS-

    ключа пользователя.

    7. Создается резервный файл с именем вида EFS0.tmp в том каталоге, где

    находится шифруемый файл.

    8. Связка ключей DDF и DRFдобавляются к заголовку и сопоставляются с

    файлом как атрибут EFS.

    9. Резервный файл помечается как шифрованный, и в него копируется

    содержимое исходного файла.

    10. Содержимое исходного файла уничтожается, в него копируется

    содержимое резервного. В результате этой операции данные исходного

    файла шифруются, так как теперь файл помечен как шифрованный.

    11. Удаляется резервный файл.

    12. Удаляется файл журнала.

    13. Выгружается профиль пользователя, загруженный на шаге 1.

    При сбое системы во время шифрования согласованные данные непременно

    сохраняются в одном из файлов – исходном или резервном. Когда Lsasrv

    инициализируется после сбоя системы, он ищет файлы журнала в каталоге

    System Volume Information на каждом NTFS-томе в системе. Если Lsasrv

    находит один или несколько файлов журнала, он изучает их содержимое и

    определяет порядок восстановления. Если исходный файл не был модифицирован

    на момент аварии, Lsasrv удаляет файл журнала и соответствующий резервный

    файл; иначе он копирует резервный файл поверх исходного (частично

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

    того как Lsasrv обработает файлы журналов, файловая система возвращается в

    целостное состояние без потери пользовательских данных.

    Процесс расшифровки

    Процесс расшифровки начинается, когда пользователь открывает шифрованный

    файл. При открытии файла NTFS анализирует его атрибуты и выполняет функцию

    обратного вызова в драйвере EFS. Драйвер EFS считывает атрибут

    $LOGGED_UTILITY_STREAM, сопоставленный с шифрованным файлом. Чтобы

    прочитать этот атрибут, драйвер вызывает функции поддержки EFS, которые

    NTFS экспортирует для EFS. NTFS выполняет все необходимые действия, чтобы

    открыть файл. Драйвер EFS проверяет наличие у пользователя, открывающего

    файл, прав доступа к данным шифрованного файла, т.е. зашифрованный FEK в

    связке ключей DDF и DRF должен соответствовать криптографической паре

    ключей, сопоставленной с пользователем. После такой проверки EFS получает

    расшифрованный FEK файла, применяемый для обработки данных в операциях,

    которые пользователь может выполнять над файлом.

    EFS не может расшифровать FEK самостоятельно и полагается в этом на

    Lsasrv, который может использовать CryptoAPI. С помощью драйвера KsecDD.sys

    EFS посылает LPC-сообщение Lsasrv, чтобы тот извлек из атрибута

    $LOGGED_UTILITY_STREAM FEK пользователя, открывающего файл, и расшифровал

    его.

    Получив LPC-сообщение, Lsasrv вызывает функцию LoadUserProfile из

    Userenv.dll для загрузки в реестр профиля пользователя, если он еще не

    загружен. Lsasrv перебирает все поля ключей в данных EFS, пробуя

    расшифровать каждый FEK на основе закрытого ключа пользователя; с этой

    целью Lsasrv пытается расшифровать FEK в DDF или DRF элементе ключа. Если

    хэш сертификата в поле ключа не подходит к ключу пользователя, Lsasrv

    переходит к следующему полю ключа. Если Lsasrv не удастся расшифровать ни

    одного FEK в DDF или DRF, пользователь не получит FEK файла, и EFS запретит

    доступ к файлу приложению, которое пыталось открыть этот файл. А если

    Lsasrv найдет какой-нибудь хэш, который соответствует ключу пользователя,

    он расшифрует FEK по закрытому ключу пользователя через CryproAPI.

    Lsasrv, обрабатывая при расшифровке FEK связки ключей DDF и DRF,

    автоматически выполняет операции восстановления файла. Если к файлу

    пытается получить доступ агент восстановления, не зарегистрированный на

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

    ключей DDF, EFS позволит ему обратиться к файлу, потому что агент имеет

    доступ к пере ключей для поля ключа в связке ключей DRF.

    Путь от драйвера EFS до Lsasrv и обратно требует довольно много времени –

    в процессе расшифровки FEK в типичной системе CryptoAPI использует

    результаты более 2000 вызовов API-функций реестра и 400 обращений к

    файловой системе. Чтобы сократить издержки от всех этих вызовов, драйвер

    EFS использует кэш в паре с NTFS.

    Открыв шифрованный файл, приложение может читать и записывать его данные.

    Для расшифровки файловых данных NTFS вызывает драйвер EFS по мере чтения

    этих данных с диска – до того, как помещает их в кэш файловой системы.

    Аналогичным образом, когда приложение записывает данные в файл, они

    остаются незашифрованными в кэше файловой системы, пока приложение или

    диспетчер кэша не сбросит данные обратно на диск с помощью NTFS. При записи

    данных шифрованного файла из кэша на диск NTFS вызывает драйвер EFS, чтоб

    зашифровать их.

    Драйвер EFS выполняет шифрование и расшифровку данных порциями по 512

    байт. Такой размер оптимален для драйвера, потому что объем данных при

    операциях чтения и записи кратен размеру сектора.

    Резервное копирование шифрованных файлов

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

    том, что приложения не могут получить доступ к расшифрованным данным иначе,

    чем через механизмы шифрования. Это ограничение особенно важно для утилит

    резервного копирования, с помощью которых файлы сохраняются на архивных

    носителях. EFS решает эту проблему, предоставляя утилитам резервного

    копирования механизм, с помощью которого они могут создавать резервные

    копии файлов и восстанавливать их в шифрованном виде. Таким образом,

    утилитам резервного копирования не обязательно шифровать или расшифровывать

    данные файла в процессе резервного копирования.

    Для доступа к шифрованному содержимому файлов утилиты резервного

    копирования в Windows 2000 используют новый EFS API: функции

    OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw и

    CloseEncryptedFileRaw. Эти функции, предоставляемые Advapi32.dll, вызывают

    соответствующие функции Lsasrv по механизму LPC. Например, после того как

    утилита резервного копирования открывает файл, она вызывает

    ReadEncryptedFileRaw, чтобы получить данные. Lsasrv-функция EfsReadFileRaw

    выдает управляющие команды, шифруемые по алгоритму DESX с помощью

    сеансового ключа EFS, драйверу NTFS для чтения сначала атрибута EFS файла,

    а затем его шифрованного содержимого.

    EfsReadFileRaw может понадобиться несколько операций чтения, чтобы

    считать большой файл. По мере того как EfsReadFileRaw считывает очередную

    порцию файла, Lsasrv посылает Advapi32.dll RPC-сообщение, в результате

    которого выполняется функция обратного вызова, указанная программой

    резервного копирования при вызове ReadEncryptedFileRaw. Функция

    EfsReadFileRaw передает считанные шифрованные данные функции обратного

    вызова, которая записывает их на архивный носитель.

    Восстанавливаются шифрованные файлы аналогичным образом. Программа

    резервного копирования вызывает API-функцию WriteEncryptedFileRaw, которая

    активизирует функцию обратного вызова программы резервного копирования для

    получения нешифрованных данных с архивного носителя, в то время как Lsasrv-

    функция EfsWriteFileRaw восстанавливает содержимое файла.

    Заключение

    Шифрованная файловая система защищает конфиденциальные данные в файлах на

    томах NTFS. EFS - основная технология шифрования и расшифровки файлов на

    томах NTFS. Открывать файл и работать с ним может только пользователь, его

    зашифровавший. Это чрезвычайно важно для пользователей переносных

    компьютеров: даже если взломщик получит доступ к потерянному или

    украденному компьютеру, он не сможет открыть зашифрованные файлы. В Windows

    XP шифрованная файловая система также поддерживает автономные файлы и папки

    (Offline Files and Folders).

    Зашифрованный файл останется недоступным для просмотра в исходном виде,

    даже если атакующий обойдет системную защиту, например, загрузив другую ОС.

    EFS обеспечивает устойчивое шифрование по стандартным алгоритмам и тесно

    интегрирована с NTFS. EFS в Windows XP Professional предоставляет новые

    возможности совместного использования зашифрованных файлов или отключения

    агентов восстановления данных, а также облегчает управление посредством

    групповой политики и служебных программ командной строки.

    Приложение. Сокращения.

    [pic]

    Список используемой литературы

    1. Д. Соломон, М. Руссинович. Внутреннее устройство Microsoft Windows 2000.

    Мастер-класс. / Пер. с англ. — СПб.: Питер; М.: Издательско-торговый дом

    «Русская Редакция», 2001.

    2. В. Столлингс. Криптография и защита сетей: принципы и практика (2-е

    издание). / Пер. с англ. — М.: Издательский дом «Вильямс», 2001.

    3. Баричев С. Г., Гончаров В. В., Серов Р. Е. Основы современной

    криптографии. — М.: Горячая линия — Телеком, 2001.

    -----------------------

    Компоненты доступа

    к криптографическим сервисам

    Lsass

    Lsasr

    Функции EFS

    Microsoft Base

    Cryptographic

    Provider 1.0

    Приложение

    KSecDD

    EFS

    NTFS

    EFS-вызовы

    внешних функций

    Доступ к зашифрованному файлу

    Поле расшифровки данных (DDF)

    Поле восстановления данных (DRF)

    Информация EFS

    Заголовок

    Страницы: 1, 2


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.