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

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

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

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

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

     Рисунок 5 – Схема работы EFS

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

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

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

2.5  Шифрование с открытым ключом

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

     В традиционном шифровании с секретным ключом (secret key) (симметричное шифрование) зашифровывающий и расшифровывающий ключи, совпадают. Стороны, обменивающиеся зашифрованными данными, должны знать общий секретный ключ. Процесс обмена информацией о секретном ключе представляет собой брешь в безопасности вычислительной системы.

     Фундаментальное отличие шифрования с открытым ключом (асимметричное шифрование) заключается в том, что зашифровывающий и расшифровывающий ключи не совпадают. Шифрование информации является односторонним процессом: открытые данные шифруются с помощью зашифровывающего ключа, однако с помощью того же ключа нельзя осуществить обратное преобразование и получить открытые данные. Для этого необходим расшифровывающий ключ, который связан с зашифровывающим ключом, но не совпадает с ним. Подобная технология шифрования предполагает, что каждый пользователь имеет в своем распоряжении пару ключей — открытый ключ (public key) и личный или закрытый ключ (private key). Свободно распространяя открытый ключ, вы даете возможность другим пользователям посылать вам зашифрованные данные, которые могут быть расшифрованы с помощью известного только вам личного ключа. Аналогично, с помощью личного ключа вы можете преобразовать данные так, чтобы другая сторона убедилась в том, что информация пришла именно от вас. Эта возможность применяется при работе с цифровыми или электронными подписями. Шифрование с открытым ключом имеет все возможности шифрования с закрытым ключом, но может проходить медленнее из-за необходимости генерировать два ключа. Однако этот метод безопаснее.

     Появление пары "личный ключ/открытый ключ" привело к возникновению нескольких новых технологий, наиболее важными из которых являются цифровые подписи, распределенная аутентификация, соглашение о секретном ключе, достигаемое с применением открытого ключа, и шифрование больших объемов данных без предварительного соглашения о секретном ключе. Существует несколько хорошо известных алгоритмов шифрования с открытым ключом. Некоторые из них, например RSA (Rivest-Shamir-Adelman) и шифрование с помощью эллиптической кривой (Elliptic Curve Criptography, ECC), являются алгоритмами общего употребления в том смысле, что они поддерживают все упомянутые выше операции. Другие алгоритмы поддерживают только некоторые операции. К ним относятся: алгоритмцифровой подписи (Digital Signature Algorithm, DSA), используемый только для работы с цифровыми подписями, и алгоритм DiJfie-Hetlman (D-H), применяемый только для соглашений о секретных ключах.

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

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

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

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

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

     Для доступа к шифрованному содержимому  файлов утилиты резервного копирования в Windows 2000 используют новый EFS API: функции OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw и CloseEncryptedFileRaw. Эти функции, предоставляемые Advapi32.dll, вызывают соответствующие функции Lsasrv по механизму LPC. Например, после того как утилита резервного копирования открывает файл, она вызывает ReadEncryptedFileRaw, чтобы получить данные. Lsasrv-функция EfsReadFileRaw выдает управляющие команды, шифруемые по алгоритму DESX с помощью сеансового ключа EFS, драйверу NTFS для чтения сначала атрибута EFS файла, а затем его шифрованного содержимого.