Блог

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

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

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

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

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

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