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

Question

Мне необходимо

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

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

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

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

Answer 1

Процесс доказательства того, что ключ происходит от TPM, известен как:

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

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

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

  • (a) Платформа (или прикладное программное обеспечение на платформе) выдает TSS CollateIdentityRequest команда. В свою очередь TSS выпускает MakeIdentity Команда для TPM. В результате TPM генерирует свежую пару открытых ключей AIK.
  • (б) в пределах 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(г). (Обратите внимание identityBinding структура является частью подписи только над IDENTITY_CONTENTS состав). Примечание: необходимо отметить, что identityBinding структура НЕ является криптографическим доказательством того, что AIK является резидентным ключом TPM и что AIK был сертифицирован с использованием EK. Это только демонстрирует, что существует некоторая пара ключей. (ii) версия спецификации TPM (iii) SubjectPublicKeyInfo (т.е. AIK_pub_key) (iv) IdentityLabel (v) сертификат EK (vi) сертификат платформы
  • (б) TSS затем генерирует симметричный ключ K1 (локальное случайное число из TPM) и шифрует IDENTITY_PROOF структура с использованием этого симметричного ключа K1,
  • (c) TSS затем шифрует ключ K1 используя открытый ключ ACA. Это шифрование с использованием открытого ключа Центра аттестации предназначено для ограничения раскрытия K1 только в ACA. Результатами этого шага являются два элемента: зашифрованный IDENTITY_PROOF структура и зашифрованный симметричный ключ K1, Зашифрованные IDENTITY_PROOF и зашифрованы K1 связаны в IDENTITY_REQ структура, которая включает идентификаторы для симметричных и асимметричных алгоритмов, используемых для шифрования структур, плюс размеры зашифрованных структур.
• Шаг 3: Платформа отправляет запрос сертификата AIK в ACA. Платформа (или прикладное программное обеспечение на платформе) принимает IDENTITY_REQ в результате предыдущего шага, зашифровывает его и отправляет в ACA.
• Шаг 4: ACA проверяет запрос сертификата. После получения запроса на сертификат ACA должен выполнить ряд проверок.
  • (a) Чтобы получить доступ к структуре запроса сертификата AIK, ACA должен сначала расшифровать ключ K1 используя свой закрытый ключ ACA.
  • (б) 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 выдает новый сертификат 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 выполняет следующие задачи:
  • (а) 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 (который находится только в TPM) после того, как AIK с соответствующим ключом публикации находится в TPM.

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