И снова EFS. Казалось бы, над ним уже давно расставлены все точки, ан-нет, кому-то обязательно не будет покоя. А покоя сегодня нет по следующим поводам: EFS sharing и как правильно состряпать сертификат агента восстановленя EFS.

EFS sharing

Поступил по почте мне вопрос с ссылкой на ОСЗоне: http://forum.oszone.net/showthread.php?p=1922709. Краткое содержание серий:

Update 28.05.2012: новые фичи не были мною обнаружены в Windows 7 и Windows Server 2008 R2 (на других не проверял), а следовательно — выпилены из поста. Т.е. в Windows 7 и Windows Server 2008 R2 для шифрования по сети применяются те же правила и требования, что и для систем pre-Vista.

Наконец-то нашёл повод, чтобы написать в бложек. В последнее время как-то интересных тем не нахожу и занятных случаев для разбора не наблюдается. Всё самое интересное я публикую в своём буржуйском бложеке. Помогая разным пользователям на технетах решать их проблемы, пришёл к выводу, что очень многие не читают документацию по технологиям, которые они внедряют. С одной стороны это обычное явление. Зачем что-то читать, если можно залезть на технетики, где вам всё расскажут и починят? С другой стороны, они доставляют лулзы, когда у них всё накрывается медным тазом.

Казалось бы, а причём тут EFS? Недавний тред на русскоязычных технетах:

С постепенным уменьшением количества систем на базе Windows XP и Windows Server 2003 и увеличением доли более новых операционных систем, всё большую популярность приобретают новые криптографические алгоритмы. Эти алгоритмы (их ещё называют Suite B) включены в концепцию Cryptography Next Generation или сокращённо CNG. Эти алгоритмы отличаются более высокой стойкостью при меньшей длине ключа, а так же поддерживают более стойкие (и более длинные) алгоритмы хеширования семейства SHA2 (SHA256, SHA384, SHA512). А ещё они поддерживают новую модель криптоповайдеров — Key Storage Provider (KSP). В этой статье я расскажу про некоторые особенности применения CNG в EFS и Key Archival.

Encrypting File System и CNG

Начиная с Windows Vista вы можете использовать CNG для шифрующей файловой системы (CNG). Для этого вам придётся скопировать шаблон BasicEFS в оснастке Certificate Templates. Когда вы копируете шаблон, вы видите вот такой выбор:

Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

Мне иногда задают вопрос про сущность этой опции Enable private strong protection, а так же встречаются любители обезопасить свои ключи данной опцией. Итак, что это такое? Private key strong protection позволяет вам шифровать ваш закрытый ключ отдельным паролем и является некоторым подобием поведения, когда сертификат находится на смарт-карте. Включить данную опцию вы можете при энроллменте или импорте сертификата. При энроллменте выберите нужный вам шаблон сертификата, нажмите Properties, перейдите на вкладку Private key, раскройте Key options и поставьте галочку на Strong private key protection:

после нажатия Ok, вылезет окошко, которое потребует у вас указать степень защиты и пароль (если выбран High):

Я выбрал уровень High и следующим окном меня попросили ввести пароль. Этот пароль не обязательно должен быть такой же как и пароль от учётной записи. Поэтому пароль можно указывать любой. И когда вы захотите использовать закрытый ключ от этого сертификата (например, подписать почтовое сообщение или аутентифицироваться по сертификату на веб-узле), то появится запрос для подтверждения использования закрытого ключа:

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

• сертификатов компьютера, которые хранятся в LocalMachine store

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

• для сертификатов EFS пользователей

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

1. Local Security Authority — LSA (lsass.exe) проверяет наличие сертификата EFS в профиле пользователя или на смарт-карте. Если не находит, то в зависимости от настроек политик может запросить новый сертификат у CA или сгенерировать самоподписанный. Самоподписанный сертификат генерируется если в доменной сети не зарегистрировано ни одного CA или машина находится в рабочей группе и в политиках не запрещено использование самоподписанных сертификатов EFS;
2. LSA генерирует симметричный ключ шифрования FEK (File Encryption Key) в закрытой и недоступной для пользователя области памяти;
3. LSA этим симметричным ключом шифрует сами данные;
4. LSA выбирает из профиля пользователя открытый ключ сертификата EFS и им шифрует симметричный ключ шифрования и записывает шифр в DEF (Data Encryption Field) файла.

Здесь как бы особого криминала нет, поскольку на данном этапе LSA ничего не знает про закрытый ключ, но при попытке расшифровать файл получается такая картина:

1. LSA читает DEF файла и выясняет Thumprint сертификата, который использовался при шифровании симметричного ключа (FEK);
2. LSA пытается взять закрытый ключ от сертификата, но его ожидаем облом. Закрытый ключ зашифрован паролем, который известен только пользователю. Т.к. lsass.exe — это системный процесс и работает в закрытой области памяти, не представляется возможным (по условиям безопасности) передать окно для ввода пароля в сессию пользователя. Просто это наиболее короткий путь к повышению своих привелегий :-)

Поэтому окошка вы никакого не видите и, следовательно, доступ к данным сразу же теряете. Чтобы избежать этого было сделано хорошее решение — не шифровать файлы вообще, если сертификат EFS защищён отдельным паролем и запросить/сгенерировать новый сертификат не представляется возможным. Т.е. на стадии 1 LSA попутно проверяет статус закрытого ключа. И если он защищён, то пробует запросить новый сертификат EFS для пользователя. Если CA недоступен или нет шаблона Basic EFS, то пытается сгенерировать самоподписанный. Если политиками запрещено использовать самоподписанные сертификаты EFS, то получаете ошибку и никакого шифрования не производится.

Нужен ли этот Strong protection в реальной жизни? В реальной жизни есть смысл использовать смарт-карты, тем более сейчас всё больше приложений поддерживают их. И EFS в том числе. Тогда strong protection можно отключить на уровне политик:

Computer Configuration –> Policies –> Windows Settings Security Options –> System Cryptography: Force strong key protection for user keys stored on the computer

Если не уверены, что оно вам надо, то лучше отключить эту возможность на уровне домена. Включать эту политику не рекомендуется, поскольку она может привести к катастрофическим последствиям, что сертификаты у вас просто перестанут работать.

В предыдущих частях мы разговаривали о применении смарт-карт для хранения и использования ключей шифрования EFS в Windows Server 2008. Мы так же рассмотрели вопросы реализации агентов восстановления и самого процесса восстановления. Предыдущие 3 части:

• EFS и смарт-карты в Windows Server 2008 (часть 1)
• EFS и смарт-карты в Windows Server 2008 (часть 2)
• EFS и смарт-карты в Windows Server 2008 (часть 3)

И у нас остался только одна категория вопросов: что будет, если сертификат просрочен или будет отозван. В принципе, разницы в поведении между просроченными и отозванными сертификатами не будет, а именно:

• пользователи не могут шифровать новые файлы отозванными или просроченными сертификатами, но сохраняется возможность расшифровывать ранее зашифрованные файлы;
• агенты восстановления EFS файлов теряют возможность дешифрования файлов, которые были зашифрованы после истечения срока или отзыва сертификата агента восстановления. В этом случае когда пользователи шифруют файлы, то они заполняют только DDF, но не DRF, который остаётся пустым.
• агенты восстановления Key Archival так же утрачивают возможность восстановления закрытых ключей пользователей из базы CA, которые были сгенерированы после истечения срока Key Archival сертификата. В этом случае закрытые ключи пользователей не шифруются просроченными сертификатами агентов Key Archival. В результате извлечение BLOB файла из базы CA будет невозможно. Однако, эти агенты могут дешифровывать ключи пользователей, которые запрашивали сертификаты в период валидности сертификатов агентов Key Archival.

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

Вот теперь, я так полагаю, мы в достаточной мере рассмотрели вопрос использования смарт-карт для EFS. В качестве эпилога скажу, что рекомендуется использовать комбинированные шаблоны для агентов восстановления. Например, если агент восстановления будет хранить свои закрытые ключи от EFS и Key Archival на смарт-карте, то выгодней будет использовать шаблон Smart Card Logon и в его EKU добавить уже необходимые области применения (например, Key Archival), что упрощает процедуру эксплуатации таких сертификатов в будущем. Не нужно будет теперь заботиться, что отдельные сертификаты будут истекать в разное время и при компрометации смарт-карты придётся отзывать несколько сертификатов - достаточно будет отозвать один сертификат. То же самое касается и пользователей, которые используют смарт-карты. Достаточно в Smart Card Logon EKU добавить Basic EFS и всё будет хорошо. Почти хорошо, если у вас есть Enterprise или Datacenter редакция Windows Server :)

Вопросы обновления сертификатов и прочие lifecycle эксплуатации (например, введение Certificate Autoenrollment и прочее) смарт-карт и EFS уже выходят за рамки моей статьи, поэтому вам придётся этот материал изучать самостоятельно. И на последок я подобрал несколько полезных ссылок, которые помогут с освоением данного материала:

• The Encrypting File System
• Protecting Data by Using EFS to Encrypt Hard Drives
• Implementing Key Archival Walkthrough
• Key Archival and Management in Windows Server 2003
• Certificate Revocation and Status Checking
• Certificate Autoenrollment in Windows Server 2003 (.doc)