PKI: Мифы о мифах.

Еще один миф о мифах, связанный с PKI. Недавно прочитал блог одного специалиста, в котором он рассказывает, что же такое PKI, философию этой инфраструктуры.
В свою очередь, этот специалист писал, так называемую, рецензию на статью другого специалиста, тот на третьего. Запутанная цепочка. Надеюсь, она продолжится. И кто-то напишет про мои неточности и ошибки.

Меня заинтересовали (проще говоря - прикапался) некоторые высказывания, которые достаточно пространно (а на мой взгляд неправильно) характеризуют эту инфраструктуру.
Примерно это звучало как, инфраструктура PKI – это набор правил, которые должны соблюдаться. Что эти правила соблюдаются во всех аспектах PKI. Что у PKI железная логика. Что доверие к сертификату строится по наличию «сертификатов пути» в контейнерах Trusted Root Authority и Trusted People (если говорить о реализации в Windows). Что при использовании приватного ключа для электронной подписи налагаются ограничения на валидность сертификата (конкретно шел разговор о просроченности сертификата). Вроде все.

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

Начнем с размышлений о том, что такое PKI. PKI – это инфраструктура открытого ключа. То есть это набор правил, политик, программных и аппаратных средств, которые и составляют эту инфраструктуру. И необязательно это только электронные виды средств, это и люди, и документы (писульки) и т.д. А ключевыми фигурами в этой инфраструктуре выступают закрытый и открытый ключи. Как вы их будете использовать – это ваше дело. Все зависит от требований.
PKI настолько гибкая инфраструктура, что каких-либо правил не налагает, а предоставляет только вспомогательные средства, позволяющие принимать решения по использованию ключей входящих в эту инфраструктуру.
Для меня всегда остается загадкой использование PKI конкретным приложением. Например, нельзя с полной уверенностью сказать налагает ли приложение какие-либо ограничения на сертификат, должен ли этот сертификат быть доверенным, действительным по датам, должен ли он содержать определенную политику приложений, в какое хранилище этот сертификат нужно устанавливать. Я даже не могу точно сказать, как строится цепочка доверия – используются ли промежуточные сертификаты из хранилища пользователя или компьютера.
И это все из-за того, что инфраструктура PKI очень гибкая и ни какой железной логики у нее нет. Используйте ключи так, как хотите.

Рассмотрим пример использования ключей PKI. Попутно ответим на другие заблуждения.
1) Сгенерируем наш объект испытаний (статья написана 08.04.2010):
makecert -a sha1 -sky signature -b 04/01/2011 -e 04/02/2011 -r -pe -sr CurrentUser -n "CN=Self" -ss My
Этот сертификат является самоподписанным, недоверяемым и просроченным. Устанавливается в хранилище пользователя.

2) Продолжим следующим кодом (c#):

X509Store store = new X509Store("My", StoreLocation.CurrentUser);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);

X509Certificate2 cert = store.Certificates[1]; // Сертификатов у меня 2. Сгенерированный находится под номером 1. Можно также воспользоваться методом Find для поиска по атрибутам сертификата

RSACryptoServiceProvider csp = null;

csp = (RSACryptoServiceProvider)cert.PrivateKey;

SHA1Managed sha = new SHA1Managed();

string str = "VADIM";

UnicodeEncoding encoding = new UnicodeEncoding();

byte[] data = encoding.GetBytes(str);

byte[] hash = sha.ComputeHash(data); //генерим хэш

byte[] signature = csp.SignHash(hash, CryptoConfig.MapNameToOID("SHA1")); //Генерируем сигнатуру

//Здесь представим, что принимающая сторона проверяет сигнатуру

str = "VADIM1"; // Исходная строка.. злоумышленник ее изменил.. Затем замените на VADIM без единички.. в конце должно показать true

byte[] destData = encoding.GetBytes(str);

byte[] hashdest = sha.ComputeHash(destData);

csp = (RSACryptoServiceProvider)cert.PublicKey.Key;

MessageBox.Show(

(csp.VerifyHash(hashdest, CryptoConfig.MapNameToOID("SHA1"), signature)).ToString()); // Должно отобразиться false.

Сейчас я даже не задумывался о проверке валидности сертификата. И здесь нигде проверки не делается. Проверка делается вообще отдельно.

Что мы получили? Мы развеяли миф об использовании нехороших сертификатов при подписывании. Шифрование нехорошими сертификатами не буду демонстрирова – поверьте на слово или прочитайте про анонимный TLS в Exchange 2010 (в качестве примера).
Давайте теперь разберемся с контейнерами Trusted Root Authority и Trusted People. Не факт, что приложение будет использовать контейнер Trusted People при определении доверия к сертификату.

Проверка происходит следующим образом (опять же конкретная реализация):

X509Chain chain = new X509Chain(false);

chain.Build(cert); // проверяем наш предыдущий сертификат

На данном этапе сертификат не установлен в Trusted Root Authority и не установлен в Trusted People.
Массив chain.Status должен содержать два элемента – один говорит о том, что нет доверия, второй, что сертификат просрочен.

Давайте теперь добавим сертификат в Trusted People. Copy-Paste.
Выполним тот же код:

X509Chain chain = new X509Chain(false);

chain.Build(cert);

Массив chainStatus содержит те же два элемента.

А теперь добавим в Trusted Root Authority.

Код:

X509Chain chain = new X509Chain(false);

chain.Build(cert);

На этот раз chain.Status содержит только один элемент – просроченный сертификат.
Здесь мы развеяли миф о том, что при построении доверия используются оба контейнера.
Стоит обратить внимание на параметр конструктура – false. True означает, что мы будем использовать при проверке сертификата контекст компьютера, false – пользователя (как в нашем случае). Видите, даже тут нельзя точно сказать какое хранилище будет использоваться при проверке валидности. Гибкий PKI.

Мы провели проверку валидности по умолчанию (можно было указать проверку других параметров). Вопрос: используется или нет Trusted People при построении доверия? Нельзя сказать точно. Поскольку в проверку все-таки можно включить этот контейнер или даже другие контейнеры. Но в нашем случае Trusted People не использовался, а Trusted Root Authority использовался.

После того как мы провели проверку, мы же сами и принимаем решение использовать ли пару ключей, ассоциированную с этим сертификатом или нет.
Все зависит от требований.

Спасибо за внимание, комментарии приветствуются.