TPM 2.0: предотвращение накладных расходов (пере) генерации ключей при каждом использовании - PullRequest
0 голосов
/ 01 февраля 2020

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

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

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

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

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

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

1 Ответ

0 голосов
/ 04 февраля 2020

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

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

...