TPM 2.0: предотвращение накладных расходов (повторной) генерации ключей при каждом использовании

Я разрабатываю приложение, которому необходимо сгенерировать ключ RSA в TPM, который будет использоваться для операций подписи. Публичная часть регистрируется в серверной части один раз, а частная часть затем повторно используется для аутентификации. Это будет использоваться в циклах выключения / перезапуска машины. В корне моей иерархии у меня есть SRK-ключ (т.е. на основе такого шаблона), созданный с помощью CreatePrimary (). Я знаю, что могу восстановить этот ключ для последующих сеансов (сохраняя случайный ввод в данных программы). Фактический ключ подписи программы также может быть сохранен в зашифрованном виде и затем загружен с помощью функции загрузки после регенерации SRK-ключа.

Так что функционально все работает, но хотелось бы избежать накладных расходов на регенерацию ключей. Какие у меня здесь варианты?

1) Насколько я могу прочитать (но, пожалуйста, поправьте, если я ошибаюсь), ContextSave не выдержит цикла включения питания (в документации указано, что он сбрасывается при сбросе питания). Пожалуйста, подтвердите, можно ли использовать ContextSave.

2) есть функция EvictControl, которая выполняет эту работу. Но он включает в себя ограниченную память NV (поэтому, если приложение «забывает» такой возвращенный дескриптор, память никогда не может быть освобождена без сброса всего TPM) и будет использовать TPM (только при начальной регистрации). Это подходит?

3) Возможно, есть еще один вариант, который я не нашел? Есть ли SRK "по умолчанию", который можно использовать, чтобы мне не пришлось (повторно) генерировать его, например?

Если ничего не работает, я планирую использовать эту функцию, но мне было интересно, есть ли другой вариант. Я не понимаю, почему нет ExportPrimary () / ImportPrimary () или такого, который мог бы экспортировать первичный объект, который можно было бы импортировать позже, не касаясь хранилища NV. Экспорт будет выполняться под ключом, хранящимся внутри TPM в хранилище NV (регенерируется только при очистке TPM и т. Д.) И, таким образом, будет иметь тот же уровень безопасности, что и EvictControl, но без использования NV-хранилища для каждого сгенерированного ключа.


tpm
person Morty    schedule 01.02.2020    source источник


Ответы (1)


Судя по моему чтению вопроса, похоже, что вы повторно генерируете SRK при каждом включении питания. Вы действительно не должны этого делать, SRK должен быть постоянным ключом, см. https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf.

Что касается того, как сделать его постоянным, похоже, вы уже знаете, как это сделать, просто используйте EvictControl.

person mnistic    schedule 04.02.2020
comment
Есть как концепция общих, так и выделенных SRK. Использование общего SRK не без проблем в моем случае использования (поскольку устройство может быть или не может быть подготовлено заранее, поэтому я не могу знать, записано ли оно в NV, и я бы предпочел не писать его сам). Таким образом, выделенный SRK - единственный вариант, но здесь кажется, что нельзя сохранить SRK вне TPM (даже если это технически возможно), а только на самом TPM, в NV. На мой взгляд, общий SRK в спецификации должен был быть обязательным (также очищен при очистке TPM). - person Morty; 10.02.2020
comment
Похоже, у вас есть небольшая проблема с процессом ... Если вам приходится иметь дело как с подготовленными, так и с неподготовленными TPM, количество и сложность вариантов использования, которые необходимо охватить, будут быстро расти. Удачи! - person mnistic; 11.02.2020
comment
Хорошо, может быть, глупый вопрос: но могу ли я на практике предположить (например, на ПК с Windows с TPM 2.0), что там уже есть SRK? Я не был уверен, была ли выполнена подготовка, когда, например, включение Bitlocker, или если SRK всегда присутствует, как только TPM включен (без каких-либо действий пользователя)? - person Morty; 11.02.2020
comment
Что ж, если вы очистите TPM, SRK там не будет. Чтобы создать выделенный SRK, вам понадобится аутентификация иерархии, поэтому должен быть выполнен некоторый уровень подготовки ... Я не знаю, что именно BitLocker делает, но я предполагаю, что он выполняет минимальную подготовку на неподготовленном чипе, например: docs.microsoft.com/en- нас / powershell / module / - person mnistic; 11.02.2020