TPM и защита закрытого ключа

Допустим, я создаю самозаверяющий сертификат в Powershell следующим образом:

New-SelfSignedCertificate -Provider "Microsoft Platform Crypto Provider" -Subject "CN=foobar" -KeyExportPolicy NonExportable -KeyAlgorithm RSA  -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -NotAfter $((Get-Date).AddYears(10))

Сертификат предполагается использовать для подписи кода сценариев PowerShell.

Поскольку поставщиком является MS platform crypto provider, ключи будут генерироваться микросхемой доверенного платформенного модуля (TPM), встроенной в мою материнскую плату.

Таким образом, закрытый ключ теперь хранится в «черном ящике» TPM. Так есть ли необходимость обернуть/защитить паролем закрытый ключ?


powershell public-key-encryption tpm
person joop s    schedule 23.12.2018    source источник
comment
На первый взгляд я бы с вами согласился. Но вам нужно поделиться некоторыми подробностями об ожидаемом использовании вновь созданного сертификата. Это просто для внутреннего тестирования? Что, если кто-то получит доступ к машине, нужно ли решать эту проблему?   -  person Mötz    schedule 24.12.2018
comment
Я полагаю, если кто-то получит доступ к машине, мои секреты все равно будут потеряны?   -  person joop s    schedule 24.12.2018
comment
Это зависит от того, как вы используете/храните пароль. Если вы планируете что-то вроде использования сертификата для конвейеров CI/CD, вам в какой-то момент придется где-то хранить секрет, и если вы сделаете это на машине, это действительно не имеет значения. Итак, для какой цели предназначен сертификат и насколько велик риск, по вашему мнению, в случае кражи сертификата, включая вероятность того, что это произойдет...   -  person Mötz    schedule 24.12.2018

Ответы (1)


arrow_upward
2
arrow_downward

Любой ключ, созданный доверенным платформенным модулем, уже упакован:

  • Корневой ключ хранилища для TPM 1.2 или
  • Один из первичных ключей, указанный как родительский ключ для TPM 2.

Таким образом, ключ оборачивается одним из корневых ключей во время создания ключа, и вам не нужно делать ничего особенного, чтобы это произошло. На самом деле, вы не можете сделать так, чтобы это не происходило.

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

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

person mnistic    schedule 24.12.2018
comment
Можете ли вы дать какую-либо ссылку, пожалуйста? - person joop s; 24.12.2018
comment
Ну, кроме спецификации TPM, больше ничего нет. Например, для TPM 1.2: trustedcomputinggroup.org/resource/tpm-main-specification - person mnistic; 24.12.2018
comment
Взгляните на Часть 3: Команды, раздел 10.4: TPM_CreateWrapKey, который используется для создания ключа с помощью TPM, шаг 16: Шифрование частных частей структуры wrapKey с помощью ключа в parentHandle - person mnistic; 24.12.2018
comment
Обратите внимание, что я сделал ответ немного упрощенным, так как у вас может быть целая иерархия ключей между SRK и вашим новым ключом, но на практике это случается редко. - person mnistic; 24.12.2018
comment
И Tspi_Key_CreateKey вызывает TPM_CreateWrapKey: linux.die.net/man/3/tspi_key_createkey - person mnistic; 24.12.2018
comment
Я не смог найти ссылку на powershell, но они также ограничены спецификацией TPM, не то чтобы они могли изобрести новую команду TPM, которая не упаковывает ключ... - person mnistic; 24.12.2018
comment
docs.microsoft.com/ en-us/powershell/module/pkiclient/ Пример 6 говорит примерно то же самое. - person joop s; 25.12.2018