Как обеспечить создание ключей внутри TPM?

Question

Мне нужно

• запустить .exe на клиентском компьютере, что создаст пару ключей в TPM.
• А затем я создам CSR с частью открытого ключа из сгенерированной пары ключей.по TPM.

Меня беспокоит то, как я могу гарантировать, что ключи создаются внутри TPM, а не с помощью поддельного TPM.Что позволило бы перенести и скопировать закрытый ключ.

Я слышал, для этого и нужны AIK, но я не понимаю, как это может предотвратить подделку TPM?

Одно решение, котороея могу думать о том, что: я иду на клиент, загружаюсь с USB с доверенной ОС, а затем получаю EKpub.

Answer 1

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

• Для TPM 2.0: активация учетных данных, выполняется с помощью TPM2_ActivateCredential
• Для TPM 1.2: удостоверениеАктивация с применением TPM_ActivateIdentity

Этот метод выполняет множество задач, но одно из них - доказательство того, что ключ, сгенерированный после отправки запроса к доверенному платформенному модулю, на самом деле происходит из доверенного доверенного платформенного модуля и не был подделан.Для TPM 1.2, поскольку именно в этом и заключается вопрос, активация идентификации представляет собой 8-этапный процесс, который выглядит следующим образом (далее следует отрывок из регистрации сертификата AIK * TCG ):

• Шаг 1. Платформа просит TPM создать пару ключей AIK.

  • (a) Платформа (или прикладное программное обеспечение на платформе) выдает TSS CollateIdentityRequest команда.В свою очередь, TSS выдает команду TPM MakeIdentity.В результате TPM генерирует свежую пару открытых ключей AIK.
  • (b) В функции MakeIdentity TPM создает структуру IDENTITY_CONTENTS, содержащую следующие элементы: (i) Версия структуры, (ii)) Порядковый номер команды TPM, (iii) PrivCADigest метка и (iv) AIK_pub_key.
  • (c) TPM подписывает структуру IDENTITY_CONTENTS, используя AIK_priv_key, с результирующей частью сигнатуры, ссылающейся накак identityBinding.
  • (d) TPM выводит два (2) элемента в результате команды MakeIdentity: AIK_pub_key и identityBinding.

• Шаг 2: TSS создает структуру доказательства относительно AIK

  • (a) Следуя предыдущему шагу, TSS создает структуру IDENTITY_PROOF.Эта структура состоит из следующих элементов: (i) Структура identityBinding из шага 1 (d).(Примечание: структура identityBinding является частью подписи только над структурой IDENTITY_CONTENTS).Примечание. Следует отметить, что структура identityBinding НЕ является криптографическим доказательством того, что AIK является резидентным ключом TPM и что AIK был сертифицирован с использованием EK.Это только демонстрирует, что существует некоторая пара ключей.(ii) Версия спецификации TPM (iii) SubjectPublicKeyInfo (то есть AIK_pub_key) (iv) Сертификат IdentityLabel (v) EK (vi) Сертификат платформы
  • (b) TSS затемгенерирует симметричный ключ K1 (локальное случайное число из TPM) и шифрует структуру IDENTITY_PROOF, используя этот симметричный ключ K1.
  • (c) TSS затем шифрует ключ K1 с использованием открытогоключ АСА.Это шифрование с использованием открытого ключа Центра аттестации предназначено для ограничения раскрытия K1 только для ACA.Результатами этого шага являются два элемента: зашифрованная структура IDENTITY_PROOF и зашифрованный симметричный ключ K1.Зашифрованные IDENTITY_PROOF и зашифрованные K1 объединены в структуру IDENTITY_REQ, которая включает идентификаторы для симметричного и асимметричного алгоритмов, используемых для шифрования структур, плюс размеры зашифрованных структур.
• Шаг 3: Платформа отправляет запрос сертификата AIK в ACA.Платформа (или прикладное программное обеспечение на платформе) принимает IDENTITY_REQ, полученный в результате предыдущего шага, шифрует его и отправляет в ACA.
• Шаг 4: ACA проверяет запрос сертификата.После получения запроса на сертификат ACA должен выполнить ряд проверок.
  • (a) Чтобы получить доступ к структуре запроса сертификата AIK, ACA сначала должна расшифровать ключ K1, используя свой закрытый ключ ACA.
  • (b) Затем ACA использует K1расшифровать структуру IDENTITY_PROOF.
  • (c) Затем ACA должен воссоздать структуру IDENTITY_CONTENTS и убедиться в правильности подписи (представленной полученным identityBinding).ACA может выполнить проверку, потому что теперь у него есть элементы, перечисленные в шаге 2 выше, и он может собрать тот же PrivCADigestLabel, который был предоставлен TPM.В рамках проверки ожидается, что ACA проверит полученные сертификаты (т. Е. Сертификаты EK и Platform).Ожидается, что ACA будет использовать стандартные методы проверки сертификатов X.509,такие как проверка CRL [14] и / или запрос соответствующих ответчиков OCSP [15] к эмитенту сертификата EK (например, сайт производителя TPM).
• Шаг 5: ACA выдает aновый сертификат AIK.Затем ACA создает новый сертификат AIK, используя (в качестве открытого ключа) полученный открытый ключ AIK на предыдущем этапе.ACA выдает (подписывает) новый сертификат AIK, используя собственный подписывающий ключ AIK.
• Шаг 6: ACA шифрует новый сертификат AIK.На этом этапе ACA должен подготовить вновь выданный сертификат AIK в форме, распознаваемой TPM.Как часть команды TPM_ActivateIdentity (раздел 15.2 из [5]), TPM ожидает ввод в структуре TPM_EK_BLOB или (более старая версия спецификации) ASYM_CA_CONTENTS.ACA выполняет следующие задачи:
  • (a) ACA генерирует случайный симметричный ключ шифрования K2.Этот случайный K2 уникален для каждого запроса сертификата AIK.
  • (b) ACA шифрует новый сертификат AIK с помощью ключа K2.
  • (c) Затем ACA создает либоTPM_EK_BLOB или ASYM_CA_CONTENTS (в зависимости от версии TPM), которая содержит следующее: (i) Хеш открытого ключа AIK (а именно открытый ключ AIK, найденный в исходном запросе).(ii) Симметричный ключ K2.(iii) Дополнительная информация о ПЦР - только для TPM_EK_BLOB.TPM проверяет, чтобы убедиться, что PCR и месторасположение TPM находятся в правильном состоянии, как ожидается ACA для разблокировки K2.
  • (d) ACA шифрует структуру TPM_EK_BLOB или ASYM_CA_CONTENTS с использованиемОткрытый ключ EK (как указано в сертификате EK в исходном запросе).Цель последнего шага состоит в том, чтобы гарантировать, что только тот же запрашивающий TPM будет единственным объектом, который может расшифровать вновь выданный сертификат AIK, поскольку только этот TPM обладает закрытым ключом EK (который является резидентным ключом TPM).
• Шаг 7: ACA доставляет новый сертификат AIK в TPM на платформе.Затем ACA доставляет зашифрованный результат (зашифрованный сертификат AIK + блоб или структура ASYM) платформе запрашивающей стороны / TPM.
• Шаг 8: Расшифровка нового сертификата AIK с помощью TPM.После получения (зашифрованного) сертификата AIK от ACA платформа должна ввести структуру (структуру blob или ASYM) (в TPM и активировать ее с помощью команды TSS Tspi_TPM_ActivateIdentity. Эта команда дешифрует (зашифрованный) симметричный ключK2 из ACA с использованием закрытого ключа EK (который находится только в доверенном платформенном модуле) после того, как AIK с соответствующим ключом публикации находится в доверенном платформенном модуле, а затем использует симметричный ключ K2 для расшифровки сертификата AIK.

Важнейшей частью здесь является предпоследнее предложение:

Эта команда расшифровывает (зашифрованный) симметричный ключ K2 из ACA, используя EK-private-key (который находится только в доверенном платформенном модуле) после того, как AIK с соответствующим ключом публикации находится в доверенном платформенном модуле .

Это обеспечивается спецификацией того, что EKне будет дешифровать объект TPM_EK_BLOB, если в TPM не найден закрытый ключ, для которого запрашивается активация, и поскольку объект был зашифрован TSS без использования thСекреты доверенного платформенного модуля, и вы уже проверили открытый ключ EK в цепочке сертификатов CA производителя. Гарантируется, что ключ, для которого запрашивается активация идентификатора, был создан внутри доверенного платформенного модуля, созданного доверенным лицом.