Contents of this directory is archived and no longer updated.

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

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

 Private key options during certificate enrollment

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

Private key strong protection level select Private key strong protection password input

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

Private key strong protection permission request

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

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

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

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

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

  1. Local Security AuthorityLSA (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

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


Share this article:

Comments:

Comments are closed.