GetECDsaPrivateKey возвращает дескриптор к закрытому ключу в TPM?

Question

Мы генерируем сертификаты, для которых предполагается, что ключ ECDSA хранится в TPM.Насколько я понимаю, метод расширения GetECDsaPrivateKey загрузит дескриптор алгоритма для закрытого ключа в TPM.Это правда?Сертификаты, с которыми мы тестируем, продолжают возвращать нуль, и мне нужно знать, просто ли они создаются неправильно или тестовый код плохой.Описание метода MSDN в этом случае не очень полезно.

Answer 1

Да, если это было сказано, чтобы посмотреть там.

В Windows .50 Xer9Certificate2 .NET поддерживается API сертификатов Windows. Сертификаты Windows имеют свойства (в дополнение к их атрибутам в сертификате), и одно из свойств определяет, где находится закрытый ключ (по сути, аргументы для CngKey.Open) - если свойство отсутствует (и «У меня есть уже открыт закрытый ключ [здесь] "свойство также отсутствует), тогда у сертификата" нет личного ключа "(cert.HasPrivateKey == false).

Если ваш сертификат является частью хранилища сертификатов Windows, и при просмотре этого хранилища через MMC отображается значок закрытого ключа, тогда GetECDsaPrivateKey() может открыть его (при условии, что ключ не был удален после факта, и что это ECDsa -кабельный ключ).

Если вы загружаете сертификат из файла .cer или каким-либо другим способом, то сертификат не знает о наличии закрытого ключа и никогда его не ищет. Если вы знаете, как найти закрытый ключ и открыть его в объект ECDsa (например, ECDsaCng), то вы можете (в памяти) связать их с помощью X509Certificate2 certWithKey = cert.CopyWithPrivateKey(key);. В этот момент, когда ему сообщили, где находится закрытый ключ, новый объект GetECDsaPrivateKey() работает, как и ожидалось.

Answer 2

То, что GetECDsaPrivateKey получает ключ, только если он является частью сертификата. Чтобы использовать ключ из TPM, необходимо использовать метод CngKey.Open () с именем ключа и поставщиком хранилища.