W2k/WinXP Encrypting

Как это работает

"Encrypted File System", или EFS, основывается на поддержке шифрования в W2k/WinXP, аналог которой впервые появился ещё в Windows NT 4.0. Первоначально эти функции не использовались для шифрования файлов, а только для установки защищённых сетевых соединений, защиты паролей пользователя, и тому подобных нужд. Только с появлением Windows 2000 и NTFS 5.0, как основной файловой системой для него, появилась возможность шифровать любые файлы средствами ОС. Для шифрования EFS использует личный и публичный ключи пользователя, которые генерируются когда пользователь пользуется функцией шифрования впервые, и остаются неизменными всё время, пока существует аккаунт пользователя. Причём на эти ключи не влияет ничего, пользователь может менять свой пароль для входа в систему, переименовывать свой аккаунт, ключи останутся неизменными так долго, как долго пользователь будет иметь тот же "security identifier" (SID). При удалении аккаунта удаляются и ключи, и если создать заново аккаунт с таким же именем, паролем, и всем остальным, то вновь созданный пользователь не будет иметь никакого ключа, до тех пор пока не зашифрует хотя бы один файл или директорию. Как только он это сделает, сгенерируются новые ключи которые, конечно же, не будут иметь ничего общего ключами которые использовал аккаунт с таким же именем раньше.

При шифровании файла EFS генерирует случайный номер, длиной 128 бит, для каждого файла разный, который называется "File Encryption Key" (FEK). Этот номер используется для шифрования файла с использованием одного из вариантов Data Encryption Standard (DES) алгоритма – DESX . После того как файл зашифрован, FEK сохраняется вместе с файлом, но тоже шифруется, уже по алгоритму RSA, основанном на использовании публичного и известного всем (для шифрования) и личного, не известного никому (для расшифровки) ключей пользователя. Таким образом, для того что бы расшифровать содержимое файла требуется знать FEK, но для того что бы расшифровать FEK, требуется знать личный ключ пользователя зашифровавшего файл. Такие сложности нужны для ускорения работы функций шифрования, при сохранении достаточно высокой надёжности. DESX является симметричным алгоритмом, то есть для шифрования и расшифровки используется один и тот же ключ. Это не очень надёжно, зато работает такой алгоритм очень быстро, и его помощью можно шифровать и расшифровывать большие объёмы данных практически в реальном времени. Для того что бы обеспечить надёжность шифрования, FEK и шифруется по RSA, ассиметричному алгоритму, когда для шифрования и расшифровки используются разные ключи. Это слишком медленно, что бы шифровать таким образом большие объёмы данных, но для шифрования FEK, RSA с использованием открытого и личного ключей подходит наилучшим образом.

Encrypted File System (EFS) работает как драйвер, на уровне ядра, но для того что бы работала вся система шифрования необходимо взаимодействие нескольких компонентов ОС. EFS тесно связана с драйвером NTFS, таким образом когда пользователь или приложение обращаются к зашифрованному файлу, драйвер NTFS вызывает EFS. EFS самостоятельно работает с алгоритмом DESX, но её возможностей не хватает для того что бы разобраться с RSA. Поэтому, каждый раз когда после шифровки файла алгоритмом DESX требуется зашифровать FEK, или наоборот, когда для расшифровки файла требуется расшифровать FEK, она должен обратиться к базовой криптографической службе операционной системы, которая работает не уровне пользователя, а не системы как EFS. Для этого используется Local Security Authority Subsystem (Lsass - WinntSystem32Lsass.exe), которая управляет сессиями пользователей, залогиненных на машину и заодно обрабатывает обращения EFS. Непосредственно обработкой запросов EFS занимается Local Security Authority Server (Lsasrv - WinntSystem32Lsasrv.dll), компонент Lsass, который и занимается непосредственно шифровкой или расшивкой FEK, используя Microsoft's CryptoAPI (CAPI). Как только FEK зашифрован или расшифрован (в зависимости от того что требовалось), он возвращается обратно к EFS, и она делает всю остальную черновую работу.

Несмотря на столь тесное взаимодействие, для работы NTFS вовсе не требуется загруженного EFS драйвера (WinntSystem32DriversEfs.sys). Драйвер EFS подключается к драйверу NTFS через plug-in интерфейс, и вовсе не является неотъемлемой его частью. Конечно, драйвер NTFS имеет несколько функций, которые предназначены исключительно для поддержки EFS, но если модуль EFS не подключен, он прекрасно будет работать дальше. Свидетельством этому служит WinXP Home Edition, в которой EFS не поддерживается вовсе но NTFS прекрасно работает. Кроме этого, EFS можно включать/выключать на любой ОС из семейства W2k или WinXP. Для этого достаточно в реестре по адресу HKLMSoftwareMicrosoftWindows NTCurrentVersionEFS key создать или отредактировать уже существующий ключ типа DWORD под названием EfsConfiguration. Присвоив этому ключу значение 1 вы выключите EFS, а 0 включите обратно. Для того что бы изменения вошли в силу, необходимо перезагрузить компьютер. Очевидно, что отключив EFS вы потеряете возможность не только шифровать файлы, но и расшифровывать ранее зашифрованные. Как очевидно и то, что включение/отключение EFS влияет сразу на всех пользователей. Но на ключи пользователей, как открытые так и личные, это действие не окажет абсолютно никакого влияния, поэтому после того как EFS будет включена вновь, никаких проблем с доступом к своим файлам пользователи не испытают.

Как вы уже знаете, в WinXP пользователь может разрешать другим пользователям использовать его защищённые файлы. Для того что бы сделать это возможным, EFS сохраняет вместе с файлом дополнительный блок информации. Как и любой другой файл, зашифрованный файл начинается с заголовка. Первым записывается версия файла, которая имеет абсолютно стандартный вид, и содержит в себе имя файла, дату создания и последнего изменения, информацию о владельце, и тому подобные вещи. Потом идёт контрольная сумма файла, которая позволит убедиться что в процессе хранения файл не был изменён или повреждён каким-либо способом. После этого сообщается о количестве Data Decryption Field (DDF) в файле. Именно это и позволяет использовать файл нескольким пользователям. Каждый из пользователей, который имеет право расшифровывать и читать содержимое файла обязан иметь свой DDF. Эти поля равнозначны, и содержат одинаковую информацию. Это Security ID (SID) пользователя, так называемый container name, которое позволяет найти нужный для расшифровки ключ, имя криптографической службы (обычно Microsoft Base Cryptographic Provider), и EFS certificate hash, где находится открытый ключ пользователя. Кроме этого, DDF содержит 128 битный FEK, зашифрованный с открытым ключом пользователя.

Таким образом, когда пользователь разрешает кому-либо другому пользоваться зашифрованным файлом, то к файлу просто добавляется ещё один DDF. Для того что бы добавить его, от пользователя требуется расшифровать FEK со своим личным ключом, а потом зашифровать его с открытым ключом пользователя, которого он хочет добавить, что позволит тому расшифровать FEK со своим личным ключом, и получить доступ. Естественно, для этого у другого пользователя должен быть открытый и закрытый ключи которые, как уже говорилось, генерируются только тогда, когда пользователь впервые воспользуется шифрованием. Поэтому если вы не можете добавить нужного пользователя, хотя он правильно зарегистрирован в системе, значит этот пользователь никогда не пользовался шифрованием. И пока этого не произойдёт, добавить его в качестве пользователя какого-либо зашифрованного файла будет невозможно. После всех DDF записей, следует раздел о количестве Data Recovery Field (DRF), на чём основана система позволяющая восстанавливать файлы, в случае если ни один из ключей пользователей прописанных в DDF не доступен. Это может случится как в случае когда учётная запись пользователя случайно или намеренно удалена (что может произойти в случае, например, если пользователь уволился), так в случае если ключ физически утерян (конечно, по умолчанию личный ключ хранится на жёстком диске компьютера, который "физически" так просто не утеряется, но в целях повышения общей надёжности и безопасности системы, есть возможность организовать хранение личных ключей пользователя на, например, магнитных карточках, потерять которую уже гораздо проще). DRF имеет тот же самый формат что и DDF, принципиальная разница между ними в том, что DDF автоматически добавляется только один, а DRF столько, сколько Encrypted Data Recovery Agent прописано в системе. К каждому зашифрованному файлу. Очевидно, что Data Recovery Agent может восстанавливать только те файлы, которые были зашифрованы после того, как он зарегистрирован системе, но никак не те, которые зашифрованы раньше. В самом еле, откуда там возьмётся соответствующий ему DRF?