Главная Security, Без рубрики PKI: Мифы о мифах
  • PKI: Мифы о мифах

    10270_0Еще один миф о мифах, связанный с 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 использовался.

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

    Все зависит от требований.

     

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

    Ефимов Геннадий, MCP

Комментарии

  1. А при чём тут вообще Trusted People и почему такая жопа с орфографией у автора?

  2. причем здесь Trusted People – не знаю..
    орфография – значит пора повторить русский. займусь.

  3. Предлагаю еще один миф – “открытый” ключ отличается от “закрытого”. 🙂

  4. Работаю журналистом, поэтому с орфографией и пунктуацией, так сказать, накоротке. Статья написана очень простым, понятным языком. И это несмотря на то, что тема в ней поднята довольно серьезная, узкопрофессиональная. Поэтому не стоит ругать автора за пару пропущенных запятых. Главное – смысл сказанного. Над ним и задумайтесь, Ruslan V. Karmanov.
    gexeg очень быстро поправит свой русский. А вот сможете ли вы подняться до его интеллектуального уровня – большой вопрос…

  5. Тамина!

    Вы очень хорошая и уже мне нравитесь.

    Но в плане русского языка я пленных не беру, даже девушек, даже весной.
    Язык изложения средненький, орфография – ниже оного. Тема, которая поднята – вполне обычная, просто не-“нулевая”. Не всё, что не-нулевое, является профессиональным, просто поверьте. А насчёт того, когда он сможет знать PKI на уровне хотя бы допуска к гос.тайне – да, вопрос. Наверное, никогда.

    Но я верю, что Вы будете его любить и без этого. И это – очень хорошо.

    Счастья Вам, женщины (ц).

  6. Тамина, по ходу дела вы не знаете кто такой Ruslan V. Karmanov, но зато очень хорошо знакомы с Геннадием 🙂

  7. PS Тем не менее, статья на уровне, Геннадий, спасибо.

  8. Руслан Владимирович, здравствуйте! Я у Вас учился на CCNP, хотел бы узнать, будет ли скидка, если я запишусь на курс по безопасности?

  9. Сразу предупреждаю – троллинг, мат и переход на личности буду удалять

    А то знаю я вас 😉

  10. Sanches, будет.

  11. СПАСИБО!

  12. Пожалуйста. Только это лучше в почту написать, которая ruslan@karmanov.org , а не в паблике. Не уверен, что всем читающим это сильно интересно.

  13. Руслан, если женщина оставляет комментарий под статьей, которую написал мужчина, это совершенно не значит, что она питает к автору нежные чувства. Не стоит делать банальные выводы. Я просто озвучила свои мысли по поводу прочитанного. Кстати, то, как пишете вы, говорит о том, что в русском вы точно не ас. Зачем тогда указывать на неграмотность других?

  14. Если хотите, докажу вышесказанное на примерах.

  15. >>>Vladislav Artukov
    >>>Предлагаю еще один миф — «открытый» ключ отличается от «закрытого».
    Это я где-то написал, что они одинаковые? или к другому чему то относится?

    Тамина – это человек, которого я попросил прокомментировать мою орфографию.. Честно говоря, не ожидал, что начнет вдаваться в смысл статьи и писать про уровень чего-либо, кого-либо и ум..

    >>> Руслану Карманову
    вы прокомментируйте где я не прав.. конкретно – это не правильно… это не так..
    говорить загадками не очень как-то: статья не нулевая, потому что не нулевая.. или автор не знает что такое PKI, потому что не знает…

  16. Тамина, мысли по поводу прочитанного могут быть двух видов:

    1. Общечеловеческие.
    2. Технические.

    Так как в техническом плане Вы ничего не написали, то я сразу обратился к первому варианту.

    А то, что Вы тонко заигрываете с пунктуацией – ну, я про “Кстати, то, как пишете вы, говорит о том, …” опосредованно говорит о том, что Вы – темпераментная и неглупая девушка. Это очень хорошо. А у Вас фотка есть?

  17. Если хотите, докажу вышесказанное на примерах. Конечно, упражняться в орфографии и пунктуации будем на ваших комментах.

  18. to gexeg:

    Если бы автор не знал, что такое PKI, это было бы ощутимо более заметно. Поверьте. :). Тут не такой случай. А Вы Тамину только на тему орфографии будете просить? Я так, просто, исключительно из научных побуждений выясняю, если что…

  19. Тамина, я ж не против. Вперёд. Я не декларирую себя как журналиста, поэтому могу лишь предложить начать с фразы “И это несмотря на то, что тема в ней поднята довольно серьезная, узкопрофессиональная.”

    Как Вы думаете, как журналист, чем примечательна эта фраза?

    ЗЫ. Я про фотку, кстати, напоминаю.

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

    ну а результат мы видим.. 🙂 немного отошла от договоренностей .. ну это ее дело..

  21. Вот! Совсем другое дело. Сестра – это позитив. Это даже почти как PKI, но лучше. Сразу всё стало на свои места. :))))

  22. Давайте комментировать не орфографию, а статью, ее содержание, ее правильность.

  23. Вот именно! Люблю своего братика. Он такой умница. А некоторые проблемы с орфографией – не беда. Исправится. Я в него верю очень.

  24. А что комментировать правильность? В статье рассмотрен конкретный случай. Притом пошагово. Это типовая статья серии HOW-TO. Она не несёт цели обучить какой-то технологии, либо открыть какой-то хак. Что тут комментировать? Где фотка сестры? Это ключевые вопросы.

  25. Я позволю себе дать ссылку на статью + комментарии, которую я собственно и рецензировал
    http://www.sysadmins.lv/CommentView,guid,35798bb0-c669-435d-aa45-66f1d07d9dd8.aspx

  26. Руслан, у меня такое подозрение, что вы эту статью не читали..

  27. Геннадий, ну Вам виднее, конечно, что я читал, а что – нет. Ссылка на блог Вадимса хорошая и внушает уверенность, но не в моём случае – я достаточно много консультировал Вадимса в своё время, чтобы хорошо знать то, что там написано.

    КонTROLLьный вопрос – можете в одной фразе выразить суть статьи?

  28. PKI – это инфраструктура открытого ключа. То есть, это набор правил, политик, программных и аппаратных средств, которые и составляют эту инфраструктуру. И необязательно это только электронные виды средств, это и люди, и документы, и регламенты и т.д. А ключевыми фигурами в этой инфраструктуре выступают закрытый и открытый ключи. Как вы их будете использовать – это ваше дело.

    >>>Все зависит от требований. Все зависит от реализации!!!!<<<

  29. видимо это мой косяк, что вы не увидели суть этой статьи..
    хотя эти слова и мысли я повторяю много раз в статье!!!

  30. Руслан, я уже много-много раз замечал, насколько плохи дела с орфографией и грамматикой у MCP. Слушать подкасты и вебкасты некоторых просто невозможно.

  31. Ключевыми фигурами в PKI выступают регламентирующие документы и субъекты применения. Асимметричное шифрование, равно как и схема Эль-Гамаля и прочие математические экзерсисы, выступают лишь как инструменты реализации. А насчёт того, что всё зависит от реализации – с определённым допуском это так. Куда делась сестра, Геннадий? Умница, красавица, да ещё и журналистка? Признавайтесь быстро.

  32. to Belotserkovsky Alexander:
    создайте отдельную тему, и обсуждайте там орфографию.. зачем офтопить?

  33. Но за статью спасибо. Когда гонял тестовые экзамены по сетевой безопасности, PKI были откровенно слабым местом. 🙁

  34. Александр, если эту тему развивать – ну, владение языком вообще и методологией изложения в частности – то сразу проще стреляться, да и дешевле. Хотя, если в толпу MCP забежать, возможно, дешевле будет C4 (я бы выбрал Шилку, но это негуманно).

  35. Геннадий, Вы пишете про контейнеры Trusted Root Authority и Trusted People. А почему упускаете Third-Party Root Certification Authorities, Intermediate и прочие Enterprise Trust? Можете добавить их в статью, указав порядок и приоритет применения?

  36. Ключевыми фигурами в PKI выступают регламентирующие документы и субъекты применения. Асимметричное шифрование, равно как и схема Эль-Гамаля и прочие математические экзерсисы, выступают лишь как инструменты реализации. А насчёт того, что всё зависит от реализации — с определённым допуском это так. Куда делась сестра, Геннадий? Умница, красавица, да ещё и журналистка? Признавайтесь быстро.

    ——-
    не согласен, регламентирующие документы и субъекты применения это часть инфраструктуры, но не ключевые фигуры. Ключевой фигурой можно назвать такой объект, на котором все завязано, вокруг которого выстраивается эта инфраструктура.. регламенты и субъекты могут поменяться.. ключевые фигуры должны остаться неизменными.

    опять же ключевые фигуры могут быть разными.. и реализовываться могут по разному.. но опять же, вокруг них выстраивается инфраструктура…

  37. Насчёт мифов о мифах: было бы офигенно, если бы кто-нибудь детально расписал, почему у закрытого и открытого ключа разная длина (surprise). Это вот было бы реально полезно. И ещё, сразу – почему софт класса OpenSSL, декларируя теоретическую стойкость в много-много бит, не принят ни одним государством в мире как средство стойкого шифрования. Сможете?

  38. Геннадий. PKI делается для того, чтобы этих участников обеспечить заданными функциями – например, безопасным обменом данными. Не наоборот. Эта инфраструктура появилась, потому что стандартные средства шифрования с секретным ключом не решала целую пачку вопросов – безопасный обмен ключами, например. А не наоборот.

  39. Геннадий, Вы пишете про контейнеры Trusted Root Authority и Trusted People. А почему упускаете Third-Party Root Certification Authorities, Intermediate и прочие Enterprise Trust? Можете добавить их в статью, указав порядок и приоритет применения?

    ————
    это не цель статьи.. поэтому я писать про это не стал… просто показал, что проверка сертификатов Trusted People не является правилом!!!
    в статью добавить не могу.. потому как придется повторять (подзабыл уже) реализацию PKI в Windows…

    p.s.: а что такое AKI/SKI я в курсе..

  40. Это не цель… Поэтому не стал… Просто показал… Добавить не могу…

    Я ушёл работать. Сестре привет.

  41. Геннадий. PKI делается для того, чтобы этих участников обеспечить заданными функциями — например, безопасным обменом данными. Не наоборот. Эта инфраструктура появилась, потому что стандартные средства шифрования с секретным ключом не решала целую пачку вопросов — безопасный обмен ключами, например. А не наоборот.

    ———-
    и это доказательство того что ключевой фигурой является участник(и) для которых предназначена инфраструктура?

    Вдумайтесь в слова: PKI делается для того (это уже говорит о том, что это инфраструктура с каким либо ключевым компонентом), чтобы этих участников обеспечить заданными функциями.. (уже можно сказать что участники стоят за инфраструктурой и только ее пользуются.. или для них она создана.. хотя я с этим не согласен)…

  42. !!!!!

  43. оффтоп: древовидные комментарии бы упровтили бы чтение комментариев.
    Нормальная статья – пошаговое HOW-TO. Все остальное детали.

  44. Сергей, о каком How-To вы говорите? вы где-то такое делали или будете делать?

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

  45. Эксперимент, конечно же, интерсный вне всякого сомнения. Только вот конечная цель мне неизвестна (видимо, не только мне). В первом случае вы нам продемонстрировали основной механизм подписи. Посчитали хеш, подписали, изменили хеш, проверили, получили отрицательный результат. КО счастлив.

    Но в реальной жизни цифровые подписи (бинарные) немного сложнее. Они обязательно включают проверку доверия. Кстати, в этом случае доверие организовывается классическим способом через Trusted Root CAs. А так же (в зависимости от реализации приложения) доверие цифровой подписи может быть явным и неявным. Неявное — это когда сертификат подписи выдан доверенным CA. Вот Руслан говорил вам про другие контейнеры (и не зря говорил), а вы подумали, что вас просто троллят. Но в этом был и другой намёк. Для явного доверия цифровой подписи, копия сертификата должна быть в контейнере Trusted Publishers. Если бы озадачились сутью остальных контейнеров, возможно, к вам бы и пришло сознание что к чему. Кстати, про подписи можно сорвать покровы на тему binary signing и catalog signing. Тоже хорошая тема.

    Вторая часть эксперимента с X509Chain показала, что вы что-то усвоили из моего блога, но не всё. Опять же, знание некоторых принципов компенсирует незнание многих фактов. Контейнер называется Trusted People (обратите внимание на последнее слово в названии), следовательно доверие можно организовывать между людьми (principals). Но ваш сертификат, который вы сгенерировали через makecert не содержит информации о конкретном человеке. Если вы в этот сертификат добавите расширение Subject Alternative Names и укажите UPN (можно и произвольный, лишь бы был rfc822-compliant), тогда X509Chain.build() будет возвращать True и свойство ChainStatus будет пустым. А у сертификата появится новое свойство: Extended Error Information (которое не всегда указывает на ошибку), где будет указано Peer Trust. Вот и вся правда. Хотя, не вся. Peer Trust можно устанавливать только для сертификатов, которые действительны для аутентификации клиента, EFS и secure e-mail.

  46. >>>>В первом случае вы нам продемонстрировали основной механизм подписи. >>>>Посчитали хеш, подписали, изменили хеш, проверили, получили отрицательный результат. КО счастлив.

    Вы считаете, что механизм подписывания как-то по другому работает?
    или это игрушечный API?

    >>>Но в реальной жизни цифровые подписи (бинарные) немного сложнее.

    удивлю вас, но тип объекта signature – byte[].. интересно он бинарный или нет? да и что в ит не бинарное?

    >>> А так же (в зависимости от реализации приложения) доверие цифровой подписи может быть явным и неявным.

    я про это написал.. от вас я этого не услышал.. из ваших уст это звучала как “можно только если”.. ни каких но не было.

    >>>Вот Руслан говорил вам про другие контейнеры (и не зря говорил), а вы подумали, что вас просто троллят.

    Про доп контейнеры я ответил..

    >>>Если вы в этот сертификат добавите расширение Subject Alternative Names и укажите UPN (можно и произвольный, лишь бы был rfc822-compliant), тогда X509Chain.build () будет возвращать True и свойство ChainStatus будет пустым.

    ну вы уж продемонстрируйте нам.. я вот например не верю.. 🙂
    доп. вопрос: а где он имя то возьмет, с чем сравнивать? 🙂 ну то есть, одно имя понятно, в сертификате, а второе? Или ему по барабану с чем сравнивать, лишь бы было имя UPN?

  47. >>> А так же (в зависимости от реализации приложения) доверие цифровой подписи может быть явным и неявным.

    да нет такого понятия.. явный/неявный.. мы можем проверять доверие.. можем нет.. мы можем по разному проверять доверие.. воспользоваться стандартными способами.. можем своими..

  48. > Вы считаете, что механизм подписывания как-то по другому работает?
    Нет. Поэтому я и сказал, что КО одобряет.

    > удивлю вас, но тип объекта signature — byte[]
    вы определённо устраиваете парад КО.

    > я про это написал
    не видел, чтобы про это что-то было написано. Кстати, начало тут: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.truststatus.aspx

    > Про доп контейнеры я ответил…
    это был не ответ.

    > ну вы уж продемонстрируйте нам… я вот например не верю…
    да вы сами можете проверить. Добавьте в свой сертификат SAN (UPN) и убедитесь лично.

    > а где он имя то возьмет, с чем сравнивать?
    так это же Peer Trust. Он ни с чем сравнивать не будет. Просто за счёт UPN конкретный сертификат условно говоря мапится к какому-то человеку.

    > Или ему по барабану с чем сравнивать, лишь бы было имя UPN?
    считайте, что это так. Чтобы понять это посмотрите как работает шифрование почты в домене Active Directory и вне домена.

    > да нет такого понятия…
    вы уверены? Ещё раз: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.truststatus.aspx

    > мы можем по разному проверять доверие… воспользоваться стандартными способами… можем своими…
    что-то мне это напоминает линуксоидов, которые реализуют вещи по-своему, лишь бы не так, как в Windows. Если не будете следовать стандартам Internet PKI, ваша PKI будет нафиг никому не нужной и ей доверять никому не будет, потому что это не детский сад.

  49. >>>так это же Peer Trust. Он ни с чем сравнивать не будет. Просто за счёт UPN конкретный сертификат условно говоря мапится к какому-то человеку.

    чудо PKI.. искусственный интеллект прямо таки…. какие-то люди еще 🙂

    еще один опыт.

    Сертификат, в SAN – UPN. RFC822комплиант?
    ——————————-
    Subject:
    E=Administrator@ex10.com
    CN=Administrator
    CN=Users
    DC=ex10
    DC=com
    ….
    Subject Alternative Name
    Other Name:
    Principal Name=Administrator@ex10.com
    RFC822 Name=Administrator@ex10.com
    ….
    ——————————–

    Выдан EntCA, рутовым, но серт из Root Auth удален.
    Но добавлен в Trusted People!!!

    Запускаем код:

    X509Store store = new X509Store(“My”, StoreLocation.CurrentUser);
    store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
    X509Certificate2 cert = store.Certificates[0]; // сейчас под индексом 0
    X509Chain chain = new X509Chain(false);
    chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
    Console.WriteLine(chain.Build(cert).ToString());
    foreach (X509ChainStatus status in chain.ChainStatus)
    {
    Console.WriteLine(status.Status.ToString());
    Console.WriteLine(status.StatusInformation);
    Console.WriteLine(“——————————“);
    }

    и о чудо!!!!

    False <<<
    PartialChain
    A certificate chain could not be built to a trusted root authority.

    ——————————

    Добавим в Trusted Publishers?
    Мне почему то всегда казалось, что там лежат сертификаты, которые проверяют подпись издателя, например издателя ПО, при проверке подписи ПО. И сертификат должен (на самом деле ни кому не должен) иметь определенное назначение (политику?).
    Но тут у нас комментарий: "Для явного доверия цифровой подписи, копия сертификата должна быть в контейнере Trusted Publishers." .. не слова об условиях использования!!! Видимо всех цифровых подписей…

    Вообще идея добавить туда сертификат бредовая.. но проверим..
    False <<<
    PartialChain
    A certificate chain could not be built to a trusted root authority.

    Я абсолютно верю, что если мы посмотрим на подпись софта (соответствующая вкладочка), то эффект будет. Но тут то другой случай!!!

    Моя статья, еще раз повторюсь, говорит о гибкости, о том что есть Public Key есть Private Key.. все остальное как вспомогательные средства…

  50. > чудо PKI… искусственный интеллект прямо таки… какие-то люди еще
    вы стебётесь?

    > RFC822комплиант?
    вы это у меня спрашиваете?

    > False << Я абсолютно верю, что если мы посмотрим на подпись софта (соответствующая вкладочка), то эффект будет.
    не будет. Потому что одного наличия сертификата подписи в Trusted Publishers недостаточно.

    > Моя статья, еще раз повторюсь, говорит о гибкости
    она гибка ровно на столько на сколько это позволяют требования безопасности. Но это и без вас было известно. Ваша статья вообще ни о чём не говорит, кроме вашего непонимания технологии. Да, какие-то моменты вы понимаете и можете связать. Но когда вы пытаетесь связать их с более глобальными вещами получается фейл, потому что имеете только частичные и обрывочные знания. Над этим нужно работать, учиться и читать технеты. Ну и практиковать тоже.

  51. Геннадий.
    Читал и не согласен с некоторыми моментами.
    Почему не HOW-TO, разве не похоже?

    Задача и пошаговое решение, другой разговор что задача не совсем стандартная, чем не how-to?

    PS дискуссию вы вызвали хорошую…

  52. >>> не будет. Потому что одного наличия сертификата подписи в Trusted Publishers недостаточно.
    пусть будет так…

    >>>Ваша статья вообще ни о чём не говорит, кроме вашего непонимания технологии.
    вот это поворот!!!
    главное ни одно ваше высказывание не подтверждается, а местами являются бредовыми. И вы будете говорить о моей некомпетентности?

    Приведу пример бредовых высказываний, чтоб уж не быть голословным:
    1) так это же Peer Trust. Он ни с чем сравнивать не будет. Просто за счёт UPN конкретный сертификат условно говоря мапится к какому-то человеку. <<< чудеса, не могу представить как это можно реализовать в контексте PKI
    2) считайте, что это так. Чтобы понять это посмотрите как работает шифрование почты в домене Active Directory и вне домена. <<< шифрование почты в AD, что-то новенькое 🙂
    3) Для явного доверия цифровой подписи, копия сертификата должна быть в контейнере Trusted Publishers. <<< без комментариев!!!
    4) Если вы в этот сертификат добавите расширение Subject Alternative Names и укажите UPN (можно и произвольный, лишь бы был rfc822-compliant), тогда X509Chain.build () будет возвращать True и свойство ChainStatus будет пустым. <<< проверил, результат на лицо.. скажите мне, как профи PKI, что мне нужно сделать чтобы он все таки стал доверенным, находясь в Trusted People?

  53. Руслану Карманову:
    >>>Насчёт мифов о мифах: было бы офигенно, если бы кто-нибудь детально расписал, почему у закрытого и открытого ключа разная длина (surprise).

    Я не занимаюсь изучением информационной безопасности и PKI.. поэтому для меня это будет ресурсоемкой задачей….

    Давайте вы напишите про это статью, а нам будет интересно прочитать. Поскольку мне известно, что вы являетесь специалистом в области инф. безопасности, неотъемлемой частью которой являются PKI, я думаю для вас это не составит труда.

    p.s.: а что длиннее d или e? 🙂

  54. > чудеса, не могу представить как это можно реализовать в контексте PKI
    Чтобы представить как это можно реализовать, посмотрите на Trusted Root CAs (в котором установлены сертификаты корневых CA). Например, там есть сертификат верисайна. Вопрос: откуда вы знаете, что это сертификат верисайна? С чем вы сравниваете Subject или Issuer этого сертификата? Поэтому прежде чем установить сертификат в контейнер Trusted Root CAs вы должны как-то проверить (либо персонально, либо через иные авторитетные источники), что этот сертификат принадлежит тому, кто вписан в него, и что есть все основания ему доверять. Это потребует определённых ручных операций.

    То же самое и с Trusted People, за одной лишь разницей: этот контейнер предназначен только для пользовательских (это видно из названия) сертификатов шифрования и/или аутентификации клиенты. Сразу видно логическое разделение, один для CA, второй для пользователей. Чтобы доверять конкретному пользовательскому сертификату (который удовлетворяет определённым требованиям), владелец системы должен как-то или лично или через авторитетный источник убедиться, что сертификат принадлежит пользователю, UPN которого соответствует UPN’у сертификата и ему можно доверять. На основании этого вы принимаете решение добавлять этот самоподписанный сертификат в Trusted People или нет. Плюс, доверие включается только для конкретного сертификата, но не сертификатов, которые могут находиться ниже по цепочке.

    Если вы попытаетесь добавить не-самоподписанный сертификат в Trusted Root CAs или Trusted People, доверие к этому сертификату не появится. Если сертификат не-самоподписан, корневой сертификат из его цепочки должен быть помещён в Trusted Root CAs.

    > шифрование почты в AD, что-то новенькое
    вместо того, чтобы передёргивать, лучше бы почитали про сабж. Ну и про EFS тоже.

    > без комментариев!!!
    вы согласились уже?

    > скажите мне, как профи PKI, что мне нужно сделать чтобы он все таки стал доверенным, находясь в Trusted People?

    вообще-то вы тут срываете покровы, а не я. И это я должен задавать вам вопросы, как реализовать то-то и то-то, а не вы у меня. Но я отвечу, каким уловиям должен удовлетворять сертификат:

    -сертификат должен быть самоподписан.
    -это должеен быть сертификат конечного субъекта (Basic Contraints = End Entity или расширение должно отсутствовать)
    -сертификат должен быть валиден для одного из EKU: Client Authentication, Secure email, EFS Encryption.
    -должен содержать расширение SAN с указанием UPN пользователя.

  55. >>> Если вы попытаетесь добавить не-самоподписанный сертификат в Trusted Root CAs (…) доверие к этому сертификату не появится.

    Это конечно понятно почему.. и я прекрасно понимаю что такое Subject Name, Issuer Name, AKI, SKI и т.д… но писать про это не стал.. ибо статья не об этом..

    >>> вместо того, чтобы передёргивать, лучше бы почитали про сабж. Ну и про EFS тоже.

    про AD было сказано не в тему.. поэтому и передернул..

    >>>вы согласились уже?

    нет.. сами подумайте.. мы ведем разговор о цифровой подписи просроченным сертификатом (или не доверенным), а вы говорите “Для явного доверия цифровой подписи, копия сертификата должна быть в контейнере Trusted Publishers.” .. это даже комментировать не нужно…

    еще один эксперимент.. код тот же.. сертификат изменился.
    Сертификат:
    1) сгенерирован при первом шифровании файлов с помощью EFS. Самоподписаный. В Trusted People он не оказался, то есть сам туда не добавляется. Возможно это зависит от версии Windows.. у меня XP SP3.. на других версиях может быть как-то и по другому.. но это только подтверждает мои слова о гибкости и о конкретной реализации.. в свою очередь вы утверждаете что PKI железный, железная логика…
    2) Basic Constraints: End Entity, path length constr: none
    3) EKU: EFS (много циферек)
    4) SAN: UPN@Suffix.com

    ну FALSE и хоть ты тресни!!!

    Это опять же говорит о том что вы не правы. И Trusted People используется в конкретных случаях, конкретными приложениями. Я это и не отрицал!!! Это суть статьи!!!
    Например, почему бы приложению не открыть хранилище Trusted People и не запросить от туда серт по отпечатку? Скорее всего, EFS и другие программы так и проверяют это самое доверие.

  56. > ибо статья не об этом…
    угу. Она вообще ни о чём.

    > это даже комментировать не нужно…
    ок, не комментируйте.

    > еще один эксперимент… код тот же… сертификат изменился
    это вы сами с собой разговариваете сейчас?

    > Это опять же говорит о том что вы не правы.
    в случае с XP/2003 — да, не совем прав. Потому что в этих системах с криптографией не всё было хорошо и в висте они очень многое привели в порядок. Например, привели контейнер Trusted People в соответствие с его предназначением (т.е. он и раньше выполнял свои функции, но внешне это выглядело как баг, о котором вы здесь пишите). Можете взять другой пример. Тот же самый X509Chain в XP и семёрке. В XP он в любом случае позволял проверять доверие до пользовательского контейнера Trusted Root CAs (с использованием любого конструктора). Это тоже было багом, потому что пользователь не может выбирать стартовую точку доверия. В семёрке такой фокус уже не пройдёт, потому что они исправили неправильное поведение X509Chain.

    Ваша ошибка заключается в том, что вы на основании какого-то кода получили какие-то результаты, но не проанализировали эти результаты. Даже с документацией. И теперь пытаетесь под эти результаты подогнать какое-то объяснение, которое просто несостоятельно. Это как натягивание шарика на кактус. Вроде налезает, а рвётся же.

    > Например, почему бы приложению не открыть хранилище Trusted People и не запросить от туда серт по отпечатку?

    потому что отпечаток не всегда заранее извесен.

  57. >>> это вы сами с собой разговариваете сейчас?
    понятно 🙂

    >>> В семёрке такой фокус уже не пройдёт, потому что они исправили неправильное поведение X509Chain.
    видно непонимание, что такое dot.net… в основном функции основаны на Win API.. то есть dot.net это среда выполнения, эдакая виртуальная машина, построенная над Win32 в текущей реализации… ну это конечно не говорит, что у этой среды ничего своего нету.. но мы отошли от темы..
    выбор области проверки (конструктор X509Chain) возможен и ведет себя как описан… даже в W7

    >>> потому что отпечаток не всегда заранее извесен.
    мде… его не трудно подсчитать.

  58. > выбор области проверки (конструктор X509Chain) возможен и ведет себя как описан… даже в W7
    я про дефолтный конструктор: http://msdn.microsoft.com/en-us/library/tabw4a47.aspx он на разных системах работает по-разному.

    > мде… его не трудно подсчитать.
    из чего посчитать? Допустим, вы хотите дать доступ к шифрованному файлу другому пользователю (в условиях рабочей группы). И как вы посчитаете отпечаток, без предварительного чтения всех сертификата из Trusted People/Other People?

  59. >>> я про дефолтный конструктор: msdn.microsoft.com/en-us/…ry/tabw4a47.aspx он на разных системах работает по-разному.

    ваши слова:
    “В XP он в любом случае позволял проверять доверие до пользовательского контейнера Trusted Root CAs (с использованием любого конструктора). Это тоже было багом, потому что пользователь не может выбирать стартовую точку доверия. В семёрке такой фокус уже не пройдёт, потому что они исправили неправильное поведение X509Chain. ”
    я проверил, недефолтный позволяет выбирать.. вы написали что нет… дефолтный понятно что не позволит выбирать.. потому что нечем.. не из чего.. параметра то нет.. значит настроен на какое-то конкретное поведение…
    проверять ваши слова я уже устал..

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

    меня испугали ваши слова “потому что отпечаток не всегда заранее извесен”.. я чего то не понимаю? или какие-то сейчас другие сертификаты X509v3? Почему то всегда казалось что CA Digital Signature присутствует в сертификате…

  60. фигню написал..
    перепишу..

    > мде… его не трудно подсчитать.

    в общем когда я писал.. “получить по отпечатку”… я имел ввиду поле CA digital signature…
    вы мне пишите “он иногда не известен” .. я подумал, что вы подумали про хэш.. написал что его можно посчитать..
    через какое-то время понял что лоханулся.. и удалил комент..
    коммент вернул.

    но!!!

    >>> потому что отпечаток не всегда заранее извесен.
    ^^^^^^^^^^^
    Это уже ни в какие ворота не лезет!!! объяснения:
    чего то не понимаю? или какие-то сейчас другие сертификаты X509v3? Почему то всегда казалось что CA Digital Signature присутствует в сертификате…
    http://tools.ietf.org/html/rfc5280#section-4.1

  61. вообще после таких слов “потому что отпечаток не всегда заранее извесен” можно другие слова не воспринимать всерьез.. 🙂

  62. что-то я перестаю улавливать вашу мысль. Сформулируйте, пожалуйста, ваш вопрос ещё раз (на счёт запроса сертификата по отпечатку из Trusted People). Я не очень понимаю, что вы этим хотите достичь.

  63. 1) субъект 1 подписал что-либо, своим закрытым ключом…
    2) субъект 2 используя сертификат субъекта 1 извлекает публичный ключ субъекта 1..
    3) субъект 2 хочет проверить валидность сертификата. Запускает валидацию:
    а) стандартная проверка (та что реализована в Windows, в большинстве версиях) говорит что сертификат не доверенный
    б) субъект 2 начинает искать сертификат по отпечатку в контейнере Trusted People

    в зависимости от выполнения пункта пунктов 3а и 3б .. делает вывод о доверии….

    выполняет проверку подписи..

  64. Ну вот, уже лучше. Теперь я понял, почему я перестал улавливать вашу нить. Дело в том, что вы плохо читаете, что вам пишут. Trusted People используется только для сертификатов шифрования.

    Trusted Publishers не заменяет доверие сертификату подписи (как это происходит в случае с самоподписанными сертификами шифрования в Trusted People), а является дополнительным элементом доверия. Чтобы проверить достоверность подписи, сертификат подписи должен быть выдан доверенным CA (там ещё куча всяких проверок). Приложения MS (3rd-party вроде не используют это) как правило требуют, чтобы конкретный сертификат подписи (конкретного паблишера) был помещён в Trusted Publishers. В противном случае они или выдают назойливые окошки, чтобы убедиться, что вы доверяете этому паблишеру или отвергают такую подпись. Что касается стандартного UI из вкладки Digital Signatures, ему достаточно, чтобы сертификат был выдан доверенным CA и всё. Остальное уже на совести самих приложений.

  65. Геннадий, Вы сами себя обманываете. Вы говорите, что PKI – это “гибкая инфраструктура”. Это несомненно так. Но Вы мешаете PKI и программные средства, обеспечивающие необходимый функционал для работы с сертификатами стандарта x.509, а также особенности и возможности реализации PKI у конкретного вендора.

    В общем, мне не понятно, о чем Ваша статья. Вот если бы Вы потрудились, да написали пару-другую bug-репортов или подтвердили, что тот или иной процесс/формат не соответсвует общепринятым стандартам – был бы Вам почет…

  66. Кстати, по поводу “Trusted Publishers” и “Trusted People”. Контейнеры эти очень специфичны. Так, например SRP/Applocker/WinPoSh обращаются к контейнеру Trusted Publishers, а Explorer’у для того, чтобы не “алармить пользователя”, достаточно доверия к “корню”. По поводу Trusted People Вадимс уже объяснил…

  67. Кстати, по поводу “Trusted Publishers”. Контейнер этот очень специфичен, как и “Trusted People”. Так, например SRP/Applocker/WinPoSh обращаются к этому контейнеру, а Explorer’у для того, чтобы не “алармить пользователя”, достаточно доверия к “корню”. По поводу Trusted People Вадимс уже объяснил…

  68. to Дмитрий Пономарев:
    >>> Геннадий, Вы сами себя обманываете. Вы говорите, что PKI — это «гибкая инфраструктура». Это несомненно так.

    именно об этом..

    >>> Но Вы мешаете PKI и программные средства, обеспечивающие необходимый функционал для работы с сертификатами стандарта x.509, а также особенности и возможности реализации PKI у конкретного вендора.

    не совсем понимаю, что здесь написано, но советую все таки узнать, что же такое >>>инфраструктура<<

    >> Кстати, по поводу «Trusted Publishers». Контейнер этот очень специфичен, как и «Trusted People». Так, например SRP/Applocker/WinPoSh обращаются к этому контейнеру, а Explorer’у для того, чтобы не «алармить пользователя», достаточно доверия к «корню». По поводу Trusted People Вадимс уже объяснил…

    Доверять какому либо сертификату, решает приложение.. я об этом и пишу…

    to Vadims Podāns:
    >>> Ну вот, уже лучше. Теперь я понял, почему я перестал улавливать вашу нить. Дело в том, что вы плохо читаете, что вам пишут. Trusted People используется только для сертификатов шифрования.

    вы путаетесь в своих показаниях.. ваша реплика: “Peer Trust можно устанавливать только для сертификатов, которые действительны для аутентификации клиента, EFS и secure e-mail.”
    аналогичные реплики можно найти в других комментариях..
    все течет.. все меняется..

    >>> а является дополнительным элементом доверия.
    браво.. браво.. ну неужели согласились.. и кто же это доверие организует? неужели железный PKI?

    >>>>Чтобы проверить достоверность подписи, сертификат подписи должен быть выдан доверенным CA (там ещё куча всяких проверок).
    я хорошо показал на примере как можно сделать из слова “должен” – “может”

    >>> .. как правило требуют…
    вот оно.. понеслась.. наконец-то умные слова пошли..

    >>>Trusted People используется только для сертификатов шифрования.
    уже устал проверять ваши выдумки.. снабжайте их хоть какими-то ссылками что ли.. проверю.. но немного позже..

  69. > вы путаетесь в своих показаниях… ваша реплика:

    реплика правильная. Только к сертификатам подписей она не имеет никакого отношения. Это вы уже сами зачем-то их приплели к моей фразе.

    > браво… браво… ну неужели согласились… и кто же это доверие организует? неужели железный PKI?

    да. Или это уже не PKI?

    > я хорошо показал на примере как можно сделать из слова «должен» — «может»

    вы показали только частный пример, который не является общим правилом.

    > как правило требуют

    обратите внимание на слова «правило» и «требуют». Я надеюсь, вы владеете русским языком в достаточной мере, чтобы понять их значение. Можете попробовать объяснить это, например, SRP. С другой стороны это говорит о вашей слабой практике с PKI в реальном мире.

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

    извините, статья ваша, вам её и защищать и снабжать ссылками.

  70. Спасибо за комментарии, прежде всего. Я тоже не понял цель статьи. Показать интересную особенность? Да наверное, развеять мифы – какие? То есть получается, что всем ребятам в банках, у которых есть веб клиент и где в качестве корневых сертификатов используются сертификаты доверенных коммерческих центров, вот “прям щас” надо всё порушить и “ваще” всё переделать? Кстати, а Application Policy, благородные доны совсем использовать не собираются? По моему, это как раз та часть инфраструктуры, которая делает ее строгой, стройной если хотите. Но ведь и для Application Policy, и для Issuace Policy, как раз и требуются проработанные Policy в целом.

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

    Конечно, как у любой сложной системы у PKI есть свои недостатки, автору спасибо за то, что он на них указал.

  71. to Sergey Ammosov:
    Не совсем так. Я вовсе не собирался сказать, что все ошибаются и дураки, а я вот такой умный.
    И эта статья вовсе не говорит, что нужно все рушить.
    Она говорит примерно о следующем:
    есть требования, есть цели, есть задачи, которые вам нужно решить. Вы их решаете. Криптосредства Windows (или какие-либо другие) дают вам для этого полную свободу. Это и будет PKI. Ваш PKI. И жестко прописанных правил и истин нет.
    Если вам нужно требовать определенную политику в сертификатах – требуйте. Если вы хотите использовать сертификаты только для шифрования (или целостности, аутентификации) – используйте только для этого. Ограничивать вас опять же ни кто не будет.

    А миф как раз в том, что PKI это не прописные истины и правила, которые необходимо безмолвно соблюдать. Если бы это было так, то использование его было бы ограниченным и выглядел бы он так – PKI.exe.

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

    Все перечисленное хоть и присутствует, но смысл достаточно скрытый. это конечно упущение.