Ключ подписи IdentityServer4, ключ проверки и защита данных .Net Core

Question

В документации Identity Server 4 (здесь http://docs.identityserver.io/en/latest/topics/crypto.html?highlight=data%20protection) обсуждаются ключи подписи и ключи проверки. Я знаю, что ключ подписи настроен с помощью

AddSigningCredential(<X509Certificate2>)

и есть два API для ключей проверки

AddValidationKey(<X509Certificate2>)
AddValidationKeys(<Microsoft.IdentityModel.Tokens.AsymmetricSecurityKey[]>) 

В документе говорится о подписывании ключа и добавлении нескольких ключей проверки в документ обнаружения. Вопросы -

• Когда вы используете AddValidationKey с X509Certificate2? Вам нужно сделать это, даже если вы используете AddSigningCredential?
• Что означает «вы запрашиваете / создаете новый ключевой материал»? Это новый сертификат? Или это ключ защиты данных Microsoft?
• Что такое AsymmetricSecurityKey? Есть ли способ создать из X509Certificate2?
• Мы используем проверку подлинности с использованием cookie-файлов. Являются ли ключи Validation такими же, как ключи, сохраненные в PersistKeysToAzureBlobStorage в Net Core 2.0? (https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-2.1&tabs=aspnetcore2x)

Answer 1

IdentityServer использует асимметричное шифрование. Асимметричное шифрование означает, что у вас есть открытый ключ и закрытый ключ. Открытый ключ является общедоступным (очевидно) и используется только для шифрования. Закрытый ключ, ну, в общем, закрытый. Он должен быть строго защищен и никогда не передаваться, и он используется для расшифровки. Ключ подписи - это ваш открытый ключ, а ключ проверки - ваш закрытый ключ, так что да, вам нужны оба. X509Certicate можно использовать, потому что в сертификатах используются как открытые, так и закрытые ключи, но в конечном итоге IdentityServer просто использует сертификат для получения ключей.

Метод AddValidationKeys (множественное число) явно используется для переключения клавиш. Например, срок действия вашего сертификата истекает через год (по умолчанию в большинстве случаев). В конце этого периода вы бы заменили его новым сертификатом. Однако клиенты могут по-прежнему иметь токены доступа и такие, зашифрованные с помощью открытого ключа из предыдущего сертификата, и IdentityServer понадобится закрытый ключ из предыдущего сертификата для его расшифровки. Используя этот метод, вы можете добавить предыдущие ключи только с целью проверки материала, который IdentityServer не может проверить с текущими ключами.

Защита данных действительно полностью отделена. Он тоже использует открытый и закрытый ключи, чтобы делать то, что он делает, поэтому технически вы могли бы использовать те же ключи и для IdentityServer. Однако лучше ограничить использование ваших ключей уникальными целями. Таким образом, если вы все-таки подвергнетесь риску, вы не будете полностью скомпрометированы и можете несколько ограничить объем потенциальной утечки.