Аттестация ключей доверенного платформенного модуля (TPM Key) Attestation

Автор: Джастин Тернер, старший инженер по эскалации поддержки с группой Windows

Обзор

Хотя поддержка защищенных TPM ключей существует с Windows 8, не было механизмов шифрования ЦС для криптографически проверки того, что закрытый ключ запрашивающего сертификата фактически защищен доверенным платформенным модулем (TPM). Это обновление позволяет ЦС выполнять эту аттестацию и отражать эту аттестацию в выданном сертификате.

Терминология

Общие сведения

Начиная с Windows 8, доверенный модуль платформы (TPM) можно использовать для защиты закрытого ключа сертификата. Поставщик ключей ключей поставщика шифрования microsoft platform (KSP) включает эту функцию. Существует две проблемы, связанные с реализацией:

• Не было никакой гарантии, что ключ на самом деле защищен TPM (кто-то может легко спуфинть программный KSP как TPM KSP с учетными данными локального администратора).

• Невозможно ограничить список TPM, разрешенных для защиты выданных корпоративными сертификатами (в случае, если администратор PKI хочет контролировать типы устройств, которые можно использовать для получения сертификатов в среде).

Аттестация ключей доверенного платформенного модуля (TPM)

Аттестация ключей доверенного платформенного модуля — это возможность сущности, запрашивающей сертификат для шифрования, доказать ЦС, что ключ RSA в запросе сертификата защищен "a" или "TPM", которым доверяет ЦС. Модель доверия доверенного платформенного модуля рассматривается далее в разделе " Общие сведения о развертывании".

Почему важно аттестация ключа доверенного платформенного модуля?

Сертификат пользователя с ключом TPM обеспечивает более высокую безопасность, резервную копию неэкспортируемости, защиты от молотка и изоляции ключей, предоставляемых TPM.

Благодаря аттестации ключа доверенного платформенного модуля теперь возможна новая парадигма управления: администратор может определить набор устройств, которые пользователи могут использовать для доступа к корпоративным ресурсам (например, VPN или беспроводной точке доступа) и иметь надежные гарантии того, что другие устройства не могут использоваться для доступа к ним. Эта новая парадигма управления доступом сильна, так как она привязана к удостоверению пользователя, привязанного к оборудованию, что сильнее, чем учетные данные на основе программного обеспечения.

Как работает аттестация ключей доверенного платформенного модуля?

Как правило, аттестация ключа доверенного платформенного модуля основана на следующих принципах:

1. Каждый TPM поставляется с уникальным асимметричным ключом, называемым ключом подтверждения (EK), сожженным производителем. Мы ссылаемся на общедоступную часть этого ключа как EKPub и связанный закрытый ключ как EKPriv. Некоторые микросхемы TPM также имеют сертификат EK, выданный производителем для EKPub. Мы ссылаемся на этот сертификат как EKCert.

2. ЦС устанавливает доверие к доверенному платформенного модуля через EKPub или EKCert.

3. Пользователь докажет ЦС, что ключ RSA, для которого запрашивается сертификат, криптографически связан с EKPub и что пользователь владеет EKpriv.

4. ЦС выдает сертификат с специальной политикой выдачи OID, чтобы указать, что ключ теперь подтверждается защитой доверенного платформенного модуля.

Общие сведения о развертывании

В этом развертывании предполагается, что корпоративный ЦС Windows Server 2012 R2 настроен. Кроме того, клиенты (Windows 8.1) настроены для регистрации в этом корпоративном ЦС с помощью шаблонов сертификатов.

Существует три этапа развертывания аттестации ключей доверенного платформенного модуля:

1. Планирование модели доверия доверенного платформенного модуля. Первый шаг — решить, какую модель доверия доверенного платформенного модуля следует использовать. Для этого поддерживаются 3 способа:

   • Доверие на основе учетных данных пользователя: корпоративный ЦС доверяет предоставленному пользователем EKPub в рамках запроса сертификата, и проверка не выполняется, кроме учетных данных домена пользователя.

   • Доверие на основе EKCert: корпоративный ЦС проверяет цепочку EKCert, предоставляемую в рамках запроса на сертификат, в соответствии с управляемым администратором списком допустимых цепочек сертификатов EK. Допустимые цепочки определяются для каждого производителя и выражаются через два пользовательских хранилища сертификатов в выдаваемом ЦС (одно хранилище для промежуточных и один для корневых сертификатов ЦС). Этот режим доверия означает, что все TPM от заданного производителя являются доверенными. Обратите внимание, что в этом режиме TPMs, используемые в среде, должны содержать EKCerts.

   • Доверие на основе EKPub: корпоративный ЦС проверяет, что EKPub, предоставленный в рамках запроса на сертификат, отображается в управляемом администратором списке разрешенных EKPubs. Этот список выражается как каталог файлов, где имя каждого файла в этом каталоге является хэшОМ SHA-2 разрешенного EKPub. Этот параметр обеспечивает высокий уровень гарантии, но требует больше административных усилий, так как каждое устройство определяется по отдельности. В этой модели доверия только устройства, у которых есть EKPub доверенного платформенного модуля, добавленные в список разрешенных EKPubs, могут регистрироваться для сертификата доверенного платформенного модуля.

   В зависимости от того, какой метод используется, ЦС будет применять другой идентификатор политики выдачи к выданному сертификату. Дополнительные сведения о политиках выдачи см. в таблице OID политики выдачи в разделе "Настройка шаблона сертификата" в этой статье.

   Обратите внимание, что можно выбрать сочетание моделей доверия доверенного платформенного модуля. В этом случае ЦС примет любой из методов аттестации, а OID политики выдачи будет отражать все методы аттестации, которые успешно выполнены.

2. Настройка шаблона сертификата. Настройка шаблона сертификата описана в разделе сведений о развертывании в этой статье. В этой статье не описывается, как этот шаблон сертификата назначается корпоративному ЦС или как доступ к регистрации предоставляется группе пользователей. Дополнительные сведения см. в контрольном списке. Настройка центров сертификации для выдачи сертификатов и управления ими.

3. Настройка ЦС для модели доверия доверенного платформенного модуля

   1. Доверие на основе учетных данных пользователя: не требуется определенная конфигурация.

   2. Доверие на основе EKCert: администратор должен получить сертификаты EKCert цепочки от производителей доверенного платформенного модуля и импортировать их в два новых хранилища сертификатов, созданных администратором, в ЦС, выполняющих аттестацию ключей доверенного платформенного модуля. Дополнительные сведения см. в разделе конфигурации ЦС в этой статье.

   3. Доверие на основе EKPub: администратор должен получить EKPub для каждого устройства, которое потребует сертификатов TPM и добавить их в список разрешенных EKPubs. Дополнительные сведения см. в разделе конфигурации ЦС в этой статье.

   Примечание.

   • Для этой функции требуется Windows 8.1/Windows Server 2012 R2.
   • Аттестация ключей доверенного платформенного модуля для сторонних поставщиков ключевых показателей эффективности смарт-карт не поддерживается. Необходимо использовать KSP поставщика шифрования платформы Майкрософт.
   • Аттестация ключей TPM работает только для ключей RSA.
   • Аттестация ключей доверенного платформенного модуля не поддерживается для автономного ЦС.
   • Аттестация ключей TPM не поддерживает обработку непрестантных сертификатов.

Сведения о развертывании

Настройка шаблона сертификата

Чтобы настроить шаблон сертификата для аттестации ключей доверенного платформенного модуля, выполните следующие действия по настройке:

1. Вкладка совместимости

   В разделе "Параметры совместимости":

   • Убедитесь, что Windows Server 2012 R2 выбран для центра сертификации.

   • Убедитесь, что для получателя сертификата выбраны Windows 8.1 или Windows Server 2012 R2.

   

2. Вкладка "Криптография "

   Убедитесь, что поставщик хранилища ключей выбран для категории поставщика, а RSA выбран для имени алгоритма. Убедитесь, что запросы должны использовать один из следующих поставщиков, и параметр поставщика шифрования Microsoft Platform выбран в разделе "Поставщики".

   

3. Вкладка "Аттестация ключей"

   Это новая вкладка для Windows Server 2012 R2:

   

   Выберите режим аттестации из трех возможных вариантов.

   

   • Нет. Подразумевает, что аттестация ключей не должна использоваться

   • Обязательно, если клиент может: позволяет пользователям на устройстве, которое не поддерживает аттестацию ключа доверенного платформенного модуля, чтобы продолжить регистрацию для этого сертификата. Пользователи, которые могут выполнять аттестацию, будут различаться с помощью специальной политики выдачи OID. Некоторые устройства могут не выполнять аттестацию из-за старого доверенного платформенного модуля, который не поддерживает аттестацию ключей, или устройство не имеет доверенного платформенного модуля вообще.

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

   Затем выберите модель доверия доверенного платформенного модуля. Существует еще три варианта:

   

   • Учетные данные пользователя: разрешить аутентификации пользователя для допустимого доверенного платформенного модуля, указав учетные данные домена.

   • Сертификат подтверждения: EKCert устройства должен проверяться с помощью промежуточных сертификатов ЦС, управляемых администратором, до сертификата корневого ЦС, управляемого администратором. Если этот параметр выбран, необходимо настроить хранилища сертификатов EKCA и EKRoot в выдаваемом ЦС, как описано в разделе конфигурации ЦС в этой статье.

   • Ключ подтверждения: EKPub устройства должен отображаться в списке, управляемом администратором PKI. Этот параметр предлагает высокий уровень гарантии, но требует больше административных усилий. Если этот параметр выбран, необходимо настроить список EKPub в выдаваемом ЦС, как описано в разделе конфигурации ЦС в этой статье.

   Наконец, решите, какая политика выдачи будет отображаться в выданном сертификате. По умолчанию каждый тип принудительного применения имеет связанный идентификатор объекта (OID), который будет вставлен в сертификат, если он передает этот тип принудительного применения, как описано в следующей таблице. Обратите внимание, что можно выбрать сочетание методов принудительного применения. В этом случае ЦС примет любой из методов аттестации, а OID политики выдачи будет отражать все методы аттестации, которые успешно выполнены.

   OID политики выдачи

   OID	Тип аттестации ключей	Description	Уровень гарантии
   1.3.6.1.4.1.311.21.30	EK	"Проверено EK": для управляемого администратором списка EK	Высокая
   1.3.6.1.4.1.311.21.31	Сертификат подтверждения	"Проверен сертификат EK": при проверке цепочки сертификатов EK	Средняя
   1.3.6.1.4.1.311.21.32	Учетные данные пользователя	"EK Trusted on Use": for user-attested EK	Низкая

   Идентификаторы OID будут вставлены в выданный сертификат, если выбрана политика включения выдачи (конфигурация по умолчанию).

   

   Совет

   Одним из возможных способов использования OID в сертификате является ограничение доступа к VPN или беспроводной сети определенным устройствам. Например, политика доступа может разрешить подключение (или доступ к другой виртуальной локальной сети), если OID 1.3.6.1.4.1.311.21.30 присутствует в сертификате. Это позволяет ограничить доступ к устройствам, чьи TPM EK присутствуют в списке EKPUB.

Конфигурация ЦС

1. Настройка хранилищ сертификатов EKCA и EKROOT в выдаваемом ЦС

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

   1. Используйте Windows PowerShell для создания двух новых хранилищ сертификатов на сервере центра сертификации (ЦС), который будет выполнять аттестацию ключа доверенного платформенного модуля.

   2. Получите промежуточные и корневые сертификаты ЦС от изготовителей, которые вы хотите разрешить в корпоративной среде. Эти сертификаты необходимо импортировать в ранее созданные хранилища сертификатов (EKCA и EKROOT) соответствующим образом.

   Следующий скрипт Windows PowerShell выполняет оба этих шага. В следующем примере производитель TPM Fabrikam предоставил корневой сертификат FabrikamRoot.cer и выдавающий сертификат ЦС Fabrikamca.cer.

   PS C:>\cd cert:
   PS Cert:\>cd .\\LocalMachine
   PS Cert:\LocalMachine> new-item EKROOT
   PS Cert:\ LocalMachine> new-item EKCA
   PS Cert:\EKCA\copy FabrikamCa.cer .\EKCA
   PS Cert:\EKROOT\copy FabrikamRoot.cer .\EKROOT
   

2. Настройка списка EKPUB при использовании типа аттестации EK

   Если в параметрах шаблона выбран ключ подтверждения, необходимо создать и настроить папку в выдаваемом ЦС, содержащую 0-байтовые файлы, каждый из которых называется хэш SHA-2 разрешенного EK. Эта папка служит списком разрешенных устройств, которые могут получить сертификаты с ключом доверенного платформенного модуля. Так как необходимо вручную добавить EKPUB для каждого и каждого устройства, для которых требуется сертификат с подтверждением, он предоставляет предприятия гарантию устройств, авторизованных для получения сертификатов доверенного платформенного модуля. Настройка ЦС для этого режима требует двух шагов.

   1. Создайте запись реестра ПодтверждениеKeyListDirectory: используйте средство командной строки Certutil для настройки расположений папок, в которых определены доверенные EKpubs, как описано в следующей таблице.

      Операция	Синтаксис команд
      Добавление расположений папок	certutil.exe -setreg CA\ПодтверждениеKeyListDirectory +"<folder>"
      Удаление расположений папок	certutil.exe -setreg CA\ПодтверждениеKeyListDirectory -"<folder>"

      В команде certutil в certutil используется параметр реестра, как описано в следующей таблице.

      Value name	Тип	Data
      ПодтверждениеKeyListDirectory	REG_MULTI_SZ	<Локальный или UNC-путь к спискам разрешений EKPUB> Пример: \\blueCA.contoso.com\ekpub \\bluecluster1.contoso.com\ekpub D:\ekpub

      HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Sanitized Name>

      ПодтверждениеKeyListDirectory будет содержать список путей UNC или локальной файловой системы, каждый из которых указывает на папку, к которым цС имеет доступ на чтение. Каждая папка может содержать ноль или больше записей списка разрешений, где каждая запись является файлом с именем, который является хэшом SHA-2 доверенного EKpub без расширения файла. Для создания или редактирования этой конфигурации раздела реестра требуется перезапуск ЦС, как и существующие параметры конфигурации реестра ЦС. Однако изменения в параметре конфигурации вступают в силу немедленно и не требуют перезапуска ЦС.

      Внимание

      Защитите папки в списке от изменения и несанкционированного доступа, настроив разрешения, чтобы только авторизованные администраторы имели доступ на чтение и запись. Для учетной записи компьютера ЦС требуется только доступ на чтение.

   2. Заполните список EKPUB: используйте следующий командлет Windows PowerShell для получения хэша открытого ключа TPM EK с помощью Windows PowerShell на каждом устройстве, а затем отправьте этот хэш открытого ключа в ЦС и сохраните его в папке EKPubList.

      PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256
      PS C:>$b=new-item $a.PublicKeyHash -ItemType file
      

Устранение неполадок

Поля аттестации ключей недоступны в шаблоне сертификата

Поля аттестации ключей недоступны, если параметры шаблона не соответствуют требованиям аттестации. Распространенные причины:

1. Параметры совместимости настроены неправильно. Убедитесь, что они настроены следующим образом:

   1. Центр сертификации: Windows Server 2012 R2

   2. Получатель сертификата: Windows 8.1/Windows Server 2012 R2

2. Параметры шифрования настроены неправильно. Убедитесь, что они настроены следующим образом:

   1. Категория поставщика: поставщик хранилища ключей

   2. Имя алгоритма: RSA

   3. Поставщики: поставщик шифрования Microsoft Platform

3. Параметры обработки запросов настроены неправильно. Убедитесь, что они настроены следующим образом:

   1. Параметр "Разрешить экспорт закрытого ключа" не должен быть выбран.

   2. Параметр шифрования закрытого ключа субъекта архива не должен быть выбран.

Проверка устройства TPM для аттестации

Используйте командлет Windows PowerShell, Confirm-CAEndorsementKeyInfo, чтобы убедиться, что определенное устройство доверенного платформенного модуля является доверенным для аттестации центра сертификации. Существует два варианта: один для проверки EKCert, а другой — для проверки EKPub. Командлет выполняется локально в ЦС или на удаленных центрах сертификации с помощью удаленного взаимодействия Windows PowerShell.

1. Чтобы проверить доверие к EKPub, сделайте следующее:

   1. Извлеките EKPub с клиентского компьютера: EKPub можно извлечь с клиентского компьютера с помощью Get-TpmEndorsementKeyInfo. В командной строке с повышенными привилегиями выполните следующие действия:

      PS C:>\$a=Get-TpmEndorsementKeyInfo -hashalgorithm sha256
      

   2. Проверьте доверие к EKCert на компьютере ЦС: скопируйте извлеченную строку (хэш SHA-2 EKPub) на сервер (например, по электронной почте) и передайте его командлету Confirm-CAEndorsementKeyInfo. Обратите внимание, что этот параметр должен иметь 64 символов.

      Confirm-CAEndorsementKeyInfo [-PublicKeyHash] <string>
      

2. Для проверки доверия в EKCert сделайте следующее:

   1. Извлеките EKCert с клиентского компьютера: EKCert можно извлечь с клиентского компьютера с помощью Get-TpmEndorsementKeyInfo. В командной строке с повышенными привилегиями выполните следующие действия:

      PS C:>\$a=Get-TpmEndorsementKeyInfo
      PS C:>\$a.manufacturerCertificates|Export-Certificate -filepath c:\myEkcert.cer
      

   2. Проверьте доверие на компьютере ЦС EKCert: скопируйте извлеченный EKCert (EkCert.cer) в ЦС (например, через электронную почту или xcopy). Например, если скопировать файл сертификата в папку c:\diagnose на сервере ЦС, выполните следующую команду, чтобы завершить проверку:

      PS C:>new-object System.Security.Cryptography.X509Certificates.X509Certificate2 "c:\diagnose\myEKcert.cer" | Confirm-CAEndorsementKeyInfo
      

См. также

Общие сведения овнешних ресурсах доверенного модуля платформы: модуль доверенной платформы