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

     1.3  Защита и шифрование

     Защита  в NTFS построена на модели объектов Windows 2000. Файлы и каталоги защищены от доступа пользователей, не имеющих соответствующих прав. Открытый файл реализуется в виде объекта  «файл» с дескриптором защиты, хранящимся на диске как часть файла. Прежде чем процесс сможет открыть описатель какого-либо объекта, в том числе и объекта «файл», система защиты Windows 2000 должна убедится, что у этого процесса есть соответствующие полномочия. Дескриптор защиты в сочетании с требованием регистрации пользователя при входе в систему гарантирует, что ни один процесс не получит доступа к файлу без разрешения системного администратора или владельца файла.

     Пользователи  часто хранят на своих компьютерах  конфиденциальную информацию. Хотя данные на серверах компаний обычно надежно  защищены, информация, хранящаяся на портативном компьютере, может попасть в чужие руки в случае потери или кражи компьютера. Права доступа к файлам NTFS в таком случае не защитят данные, поскольку полный доступ к томам NTFS можно получить независимо от их защиты – достаточно воспользоваться программами, умеющими читать файлы NTFS вне среды Windows 2000. Кроме этого, права доступа к файлам NTFS становятся бесполезны при использовании другой системы Windows 2000 и учетной записи администратора, т.к. учетная запись администратора обладает привилегиями захвата во владение и резервного копирования, любая из которых позволяет получить доступ к любому защищенному объекту в обход его параметров защиты.

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

     NTFS не допускает шифрования файлов, расположенных в корневом каталоге  системного тома или в каталоге \Winnt, поскольку многие находящиеся там файлы нужны в процессе загрузки, когда EFS ещё не активна.

     EFS использует криптографические сервисы, предоставляемые Windows 2000 в пользовательском режиме, и состоит из драйвера устройства режима ядра, тесно интегрированного с NTFS и DLL5-модулями пользовательского режима, которые взаимодействуют с подсистемой1 локальной аутентификации и криптографическими DLL.

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

     2  Механизм EFS

     EFS использует средства поддержки шифрования, введенные Microsoft ещё в Windows NT 4. При первом шифровании файла EFS назначает учетной записи пользователя, шифрующего этот файл, криптографическую пару – закрытый и открытый ключи. Пользователи могут шифровать файлы с помощью Windows Explorer; для этого нужно открыть диалоговое окно Свойства применительно к нужному файлу, щелкнуть кнопку Другие и установить флажок Шифровать содержимое для защиты данных. Пользователи также могут шифровать файлы с помощью утилиты командной строки cipber.Windows 2000 автоматически шифрует файлы в каталогах, помеченных зашифрованными. При шифровании файла EFS генерирует случайное число, называемое шифровальным ключом файла (file encryption key, FEK8). EFS использует FEK для шифрования содержимого файла по более стойкому варианту DES3 (Data Encryption Standard) – DESX4. EFS сохраняет FEK вместе с самим файлом, но FEK шифруется по алгоритму RSA- шифрования на основе открытого ключа. После выполнения EFS этих действий файл защищен: другие пользователи не смогут расшифровать данные без расшифрованного FEK файла, а FEK они не смогут расшифровать без закрытого ключа пользователя – владельца файла.

     Для шифрования FEK  используется алгоритм криптографической пары, а для шифрования файловых данных – DESX, алгоритм симметричного шифрования (в нем применяется один и тот же ключ для шифрования и дешифрования). Как правило, алгоритмы симметричного шифрования работают очень быстро, что делает их подходящими для шифрования больших объемов данных, в частности файловых. Однако у алгоритмов симметричного шифрования есть одна слабая сторона: зашифрованный ими файл можно вскрыть, получив ключ. Если несколько человек собирается пользоваться одним файлом, защищенным только DESX, каждому из них понадобится доступ к FEK файла. Очевидно, что незашифрованный FEK – серьезная угроза безопасности. Но шифрование FEK все равно не решает проблему, поскольку в этом случае нескольким людям приходится пользоваться одним и тем же ключом расшифровки FEK.

     Защита FEK сложная проблема, для решения которой EFS использует ту часть своей криптографической архитектуры, которая опирается на технологии шифрования с открытым ключом. Шифрование FEK на индивидуальной основе позволяет нескольким лицам совместно использовать зашифрованный файл. EFS может зашифровать FEK файла с помощью открытого ключа каждого пользователя и хранить их FEK вместе с файлом. Каждый может получить доступ к открытому ключу пользователя, но никто не сможет расшифровать с его помощью данные, зашифрованные по этому ключу. Единственный способ расшифровки файла заключается в использовании операционной системой закрытого ключа, который она, как правило, хранит в безопасном месте. Закрытый ключ помогает расшифровать нужный FEK файла. Windows 2000 хранит закрытые ключи на жестком диске, что не слишком безопасно, но в следующих выпусках операционной системы пользователи смогут хранить закрытые ключи на компактных носителях вроде смарт-карт. Алгоритмы на основе открытого ключа обычно довольно медленные. Поэтому они используется EFS только для шифрования FEK. Разделение ключей на открытый и закрытый немного упрощает управление ключами по сравнению с таковым в алгоритмах симметричного шифрования и решает дилемму, связанную с защитой FEK.

      Функциональность EFS опирается на несколько компонентов, как видно на схеме архитектуры EFS (см. рисунок).

     Рисунок 2 - Архитектура EFS

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

     Подсистема  локальной аутентификации (Local Security Authentication Subsystem, Lsass13)(\Winnt\System32\Lsass.exe) не только управляет сеансами регистрации, но и выполняет рутинные операции, связанные с управлением ключами EFS. Например, когда драйверу EFS требуется расшифровать FEK для расшифровки данных файла, к которому обращается пользователь, драйвер EFS посылает запрос Lsass через вызов локальной процедуры (local procedure call или LPC11).

     Драйвер устройства KsecDD9 (\Winnt\System32\Drivers\Ksecdd.sys) экспортирует функции, необходимые драйверам для посылки Lpc-сообщений Lsass. Компонент Lsass, сервер локальной аутентификации (Local Security Authentication Server, Lsasrv12) (\Winnt\System32\Lsasrv.dll), ожидает запросы на расшифровку FEK через вызов отдаленной процедуры (remote procedure call или RPC16); расшифровка выполняется соответствующей функцией EFS. Которая также находится в Lsasrv. Для расшифровки FEK, получаемого от драйвера EFS в зашифрованном виде, Lsasrv использует функции Microsoft CryptoAPI, или сокращенно CAPI1.

     CAPI состоит из DLL компонентов доступа к криптографическим сервисам (шифрованию, дешифрованию и хэшированию). Например, эти DLL управляют получением открытого и закрытого ключей пользователя, что позволяет Lsasrv не заботиться о деталях защиты ключей и об особенностях работы алгоритмов шифрования. Расшифровав FEK, Lsasrv возвращает его драйверу EFS в ответном LPC-сообщении. Получив расшифрованный FEK, EFS с помощью DESX расшифровывает данные файла для NTFS.

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

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

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

     Обнаружив шифрованный файл, драйвер 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.

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

     К этому моменту 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, сопоставленных с файлом, и формат элемента ключа показан на рисунке 3. В первой части элемента ключа EFS хранит информацию, достаточную для точного описания открытого ключа пользователя. В нее входит пользовательский идентификатор защиты (SID), имя контейнера, в котором хранится ключ, имя компонента доступа к криптографическим сервисам и хеш сертификата криптографической пары. Во второй части элемента ключа содержится шифрованная версия FEK. Lsasrv шифрует FEK через CryptoAPI по алгоритму RSA с применением открытого ключа данного пользователя. 
 
 
 
 
 
 
 
 

     Рисунок 3 – Формат информации EFS и элемента ключа

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

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

     Агенты  восстановления (Recovery Agents) определяются в политике безопасности Encrypted Data Recovery Agents (Агенты восстановления шифрованных данных) на локальном компьютере или в домене, что показано на рисунке 4.

     Рисунок 4 – Групповая политика Encrypted Data Recovery Agents

     (Агенты  восстановления шифрованных данных)

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