Главная > Active Directory > Active Directory Certification Services. Часть 1.

Active Directory Certification Services. Часть 1.

Crypto_stub_with_puzzleДоброго времени суток коллеги. Это моя первая статья из цикла статей посвящённых Active Directory Certification Services. В данной статье я расскажу о базовых принципах работы инфраструктуры открытого ключа.

Active Directory Certification Services предназначен для развёртывания в компании инфраструктуры открытого ключа (Public Key Infrastructure или PKI). Давайте для начала разберёмся с некоторыми основами, которые необходимы для понимания, как работает инфраструктура открытого ключа.

Инфраструктура открытого ключа использует шифрование. Какое бывает шифрование? Шифрование бывает симметричным и асимметричным. В симметричном шифровании ключ шифрования равен ключу разшифрования. С точки зрения математики это описывается уравнениями, какие я не буду описывать для простоты понимания данной темы. Существует целый ряд алгоритмов симметричного шифрования. Например, AES, DES, Blowfish, 3DES (TripleDES). Как говорилось ранее, существуют алгоритмы асимметричного шифрования. Пример такого алгоритма это RSA. Асимметричные алгоритмы требуют использование пары ключей. Такая пара ключей являются взаимосвязанными между собой. При использовании асимметричного шифрования, один ключ доступен всем, он называется открытым или публичным (Public), другой ключ известен только хозяину, и называется секретным или приватным (Private). Особенностью приватного ключа является то, что он никогда не покидает своего хранилища. Исключением является процесс его переноса или процесс резервного копирования. Этот метод возник из необходимости предоставления шифрованных данных другим пользователям, когда нет возможности передать ключ шифрования по защищённому каналу. Основная идея ассиметричного шифрования в том, что у нас есть пара связанных ключей, и то, что зашифровано открытым ключом, может быть расшифровано только секретным ключом. Асимметричные алгоритмы также используются для цифровой подписи. Алгоритм цифровой подписи такой: сообщение преобразовывается к двоичному виду, затем из сообщения получают его хеш-значение, из хеш-значения при помощи несимметричной криптографии получают цифровой блок информации, которая выступает в роли цифровой подписи.

imageТеперь давайте поговорим о сертификатах. Сертификат — это электронный документ, который содержит открытый ключ пользователя, информацию о пользователе, которому принадлежит сертификат, удостоверяющую подпись центра выдачи сертификатов и информацию о сроке действия сертификата, алгоритм цифровой подписи, также дополнительную информацию, которую центр сертификации включает в данный сертификат (например, e-mail пользователя, его телефон, и т.д.). Давайте разберёмся более детально с сертификатом. Важной частью сертификата является открытый ключ пользователя и подпись центра выдачи сертификатов.

Как всё-таки получается сертификат. Вначале на стороне пользователя, компьютера или смарт-карты (всё зависит кто является инициатором получения сертификата), с помощью крипто провайдера (Cryptography Service Provider, CSP) генерируется пара ключей, используя алгоритм асимметричного шифрования. Один из полученных ключей (секретный) в результате генерирования, остаётся на стороне пользователя (пользователем считается тот, кто инициирует получение сертификата). Ключ, который остаётся у пользователя называют закрытым или приватным ключом. Закрытий ключ никогда не должен покидать своего хранилища, а если он и будет покидать, то должен быть защищён. На втором шаге пользователь отправляет второй ключ (открытый или публичный) на подпись центру сертификатов. На третьем шаге центр сертификатов полученный ключ от пользователя помешает в некий контейнер, и добавляет в этот контейнер информацию: кому принадлежит открытый ключ; дата выдачи сертификата; дата окончания действия сертификата; кем выдан сертификат (проверил/подписал); назначение сертификата. Но перед тем как начать третий шаг, центр сертификатов или администратор центра сертификатов проверяет аутентичность того, кто прислал открытый ключ. После чего, если проверка завершилась успешно, центр сертификатов подписывает этот контейнер, с помощью своего закрытого ключа. Если же мы генерируем самоподписанный сертификат, проводятся такие же шаги, но подпись сертификат проводится не с помощью закрытого ключа центра сертификатов, так как он не используется в данном процессе, а с помощью своего же закрытого ключа.

Что же тогда такое цифровая подпись сертификата? Цифровая подпись сертификата, это ни что иное, как зашифрованный хеш сертификата. Хеш шифруется закрытым ключом подписчика (тот кто подписывает, например центр сертификатов). Цифровая подпись сертификата нам позволяет проверить, кто подписал сертификат и на основе этого принять решение о доверии к этому издателю сертификатов. Для того чтобы проверить подпись, необходимо иметь сертификат подписчика (издателя), а если быть более точным, то открытый ключ подписчика. В механизме создания и проверки цифровой подписи сертификата используется алгоритм асимметричного шифрования, при использовании которого расшифровать информацию можно только противоположным ключом (если шифруем закрытым ключом, то расшифруем открытым, и наоборот).

На данном этапе, мы разобрались с тем как выписываются сертификаты, какие механизмы используются в этом процессе. Теперь стоит разобраться с механизмами проверки валидности сертификата.

Каждый сертификат, который существует в мире, является подписанным или центром сертификации или своим же закрытым ключом (самоподписанный сертификат). В мире существуют авторизированные центры выдачи сертификатов, их сертификаты присутствуют во всех сервисах, которые ответственные за проверку валидности/доверия к сертификату. Данные сертификаты находятся в специальном хранилище сервиса, который проверяет сертификат на валидность. Эти сертификаты отмечены как доверительные корневые сертификаты. Как говорилось раньше, существуют самоподписанные сертификаты. Самоподписанные сертификаты считаются не доверительными, если принудительно не записаны в хранилище сертификатов как доверительные (небольшим исключение являются сертификаты для работы с EFS, но об этом в другой статье). И если у вас сертификат подписан своим собственным ключом, он будет не доверительным, пока сертификат, которым был подписан вами, не будет внесён в хранилище сертификатов как доверительный. Если же ваш сертификат подписан корневым центром сертификатом, которому вы доверяете, это ещё не значит, что он будет валидным. Сертификат выдаётся на определённый период, и если он будет использоваться вне этого периода времени, он будет считаться не валидным. Также существует ещё одна дополнительная система безопасности, которая называется Certificate Revocation List или CRL. Данная система используешься для получения отозванных сертификатов, которые были скомпрометированы и к которым нет доверия.

Проше говоря, какие условия необходимы для того чтобы сертификат считался валидным:

· Необходимо доверие к центру сертификатов, которым был выдан данный сертификат, если сертификат центра сертификации выдан другим центром сертификации, то необходимо доверие к вышестоящему центру сертификации.

· Ни один из сертификатов в иерархии не должен быть отозван.

· Время использования сертификата должно находиться в пределах времени, которое указанные в самом сертификате, такое же требование есть и сертификату центра сертификации.

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

  1. Ноябрь 4, 2011 в 16:37

    Евгений, ваша статья, мягко говоря, не айс. Километры текста без какого-либо форматирования (неужели в блокноте набираете), разделения на заголовки/подзаголовки и ни (!!!) единой картинки. Но это пол беды. Текст вообще унылый чуть более чем полностью.

    > Это моя первая статья из цикла статей посвящённых Active Directory Certification Services.

    всё-таки, это вторая (анонимус помнит весенний пост про ADCS, анонимус не забывает :)).

    > Инфраструктура открытого ключа использует шифрование.

    ВНЕЗАПНО!

    > В симметричном шифровании ключ шифрования равен ключу разшифрования.

    раСшифрования (хотя и это слово не совсем верно. Правильней будет «дешифрования»). Вам, как участнику программы MVP предлагается доступ к подпискам TechNet и MSDN, а там есть очень годные Office Proofing Tools.

    > С точки зрения математики это описывается уравнениями, какие я не буду описывать для простоты понимания данной темы.

    это как из бородатого анека: жена мужу — ах, ты не знаешь, за что я на тебя обиделась? Тогда я тебе вообще ничего не скажу!

    > Этот метод возник из необходимости предоставления шифрованных данных другим пользователям, когда нет возможности передать ключ шифрования по защищённому каналу

    какой метод? Переноса (резервного копирования) ключа?

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

    тоже идеологически верно. Из этого не следует, что возможна обратная операция. Правильней было бы сказать так: «то, что зашифровано одним ключом, может быть расшифровано другим ключом конкретной пары». Благодаря этому можно выкинуть несколько предложений из этого потока сознания.

    > сообщение преобразовывается к двоичному виду

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

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

    а можно рассказать, как это всё происходит в реальной жизни? Например, почему асиметричное шифрование никогда не используется как единственный метод? Почему сначала шифруют симметричными ключами, потом применяют асимметричное? Почему бы сразу не использовать асимметричное и забыть эти ваши DES/AES как музейный экспонат?

    > Теперь давайте поговорим о сертификатах. Сертификат — это электронный документ, который содержит открытый ключ пользователя, информацию о пользователе

    пользователь — частный случай. Правильно будет — владелец.

    > генерируется пара ключей, используя алгоритм асимметричного шифрования.

    хм. А что там делает алгоритм асимметричного шифрования? Что он там шифрует? Он шифрует null и получает ключи? И налицо взаимоисключающие параграфы — выше было сказано, что для асимметричного шифрования нужна пара ключей. Но на этапе генерации этих самых ключей их ещё нету (рекурсия). Раскройте, пожалуйста, этот момент.

    > Ключ, который остаётся у пользователя называют закрытым или приватным ключом.

    спасибо, кэп!

    > в некий контейнер

    сферический контейнер в криптографическом вакууме?

    > Но перед тем как начать третий шаг, центр сертификатов или администратор центра сертификатов проверяет аутентичность того, кто прислал открытый ключ.

    почему нельзя было соблюдать последовательность и сказать, что по получении запроса CA авторизует пользователя. И каким боком сюда вылезла аутентичность?

    > подписчика (тот кто подписывает

    спасибо, кэп!

    > На данном этапе, мы разобрались с тем как выписываются сертификаты, какие механизмы используются в этом процессе.

    вы — может быть и разобрались, но я с трудом понимаю как это всё происходит.

    > В мире существуют авторизированные центры выдачи сертификатов

    а кто их авторизует?

    > Данные сертификаты находятся в специальном хранилище сервиса, который проверяет сертификат на валидность.

    про сервис уже было сказано в предыдущем предложении. И, на самом деле, никакого сервиса не существует. Это же API.

    > И если у вас сертификат подписан своим собственным ключом, он будет не доверительным, пока сертификат, которым был подписан вами, не будет внесён в хранилище сертификатов как доверительный

    про это тоже было сказано в предыдущем предложении. Остальная часть абзаца просто нечитабельна. А если её прочитать, получишь кучку отрывочных фраз, которые мало связаны друг с другом и не раскрывают своего назначения.

    > система безопасности, которая называется Certificate Revocation List

    CRL — это не система безопасности, это список отзыва. А система — отзыв сертификатов (certificate revocation).

    > если сертификат центра сертификации выдан другим центром сертификации, то необходимо доверие к вышестоящему центру сертификации.

    простите, сломал мозг.

    > Ни один из сертификатов в иерархии не должен быть отозван.

    а как это отзыв работает?

    > В ней мы теоретически разобрались как создаётся сертификат, как проверяется сертификат на валидность, и получили общее представление о асимметричном алгоритме шифрования.

    здесь «мы» надо заменить на «я», потому что анонимус ничего не понимает.

    что делать и как быть? Посмотрите блог товарища Богомолова, а конкретнее его посты про PKI:
    http://www.alexxhost.ru/2011/05/pki.html
    http://www.alexxhost.ru/2011/05/pki_25.html

    я даже успел провести экспресс-опрос, показав людям 2 статьи (вашу и Алексея) и спросил, что они стали бы читать в первую очередь. Результаты опроса, увы, не в вашу пользу.

  2. Ноябрь 4, 2011 в 17:00

    Спасибо за кометарий. Да действительно всё происходит именно в блокноте.

  3. Ноябрь 4, 2011 в 17:23

    Попробуйте Windows Live Writer — http://get.live.com

  4. Ноябрь 4, 2011 в 17:54

    Учитывая, что прошлая попытка написать про PKI была с год назад, с такой скоростью можно ждать, что лет через 20 будет статья с названием «Вы, верно, будете таки смеяться, но это опять моя первая статья про PKI». В принципе Вадимс много что написал, могу лишь акцентироваться на некоторых моментах.

    0. Язык статьи не русский, не украинский и не английский. При прочтении создаётся четкое и недвусмысленное впечатление, что использовался робоперевод. Неплохо бы за такое время, прошедшее после первого try, хотя бы вычитать статью. Ряд фраз банально с 5го раза не очень понятен при перечитывании по слогам.

    1. «с помощью крипто провайдера (Cryptography Service Provider, CSP) генерируется пара ключей, используя алгоритм асимметричного шифрования»

    Это очень, очень фиговый fail. Ключи создаются при помощи алгоритмов генерации ключей. При помощи алгоритма RSA нельзя создать ключи RSA, равно как при помощи AES нельзя создать ключ для AES.

    2. «Цифровая подпись сертификата нам позволяет проверить, кто подписал сертификат и на основе этого принять решение о доверии к этому издателю сертификатов»

    Цифровая подпись сама по себе не позволяет проверить, кто подписал сертификат. Она нужна, чтобы проверить уже указанную в сертификате информацию об этом. Т.е. вначале из сертификата видно кто подписал, а потом, путём неких операций с цифровой подписью, становится понятно — правда это или нет. И уж тем более «на основе этого» никак нельзя принять решение о доверии к издателю. То есть на основе результатов проверки конкретного сертификата X, в котором указано, что он выпущен центром Y, никак нельзя сделать вывод, что центр Y плохой. Максимум — что сертификат X плохой.

    3. «Время использования сертификата должно находиться в пределах времени, которое указанные в самом сертификате»

    Я так понимаю, что в сертификате указано два диапазона времени — «время использования сертификата» и «время, которое указанные в самом сертификате», и их надо сравнить?

    4. «Данная система используешься для получения отозванных сертификатов, которые были скомпрометированы и к которым нет доверия.»

    Из фразы следует, что CRL — некий сервис для мазохистов, который позволяет получить сами скомпрометированные сертификаты. Это мало того что не так, так ещё и было бы и не очень нужно, и не безопасно.

    Ещё из статьи следует, что доверенными бывают или сертификаты корневых центров, или самоподписанные. Это не так.

    Евгений, если Вы за год, прошедший с прошлой попытки публикации, пишете подобное и даже не вычитываете, то это очень плохо. Вы реально попробуйте чем-нибудь другим заняться, я не шучу совсем. Не мучайте себя и других, в IT много направлений деятельности. Можно хорошо разбираться в SQL Server, допустим, или в Exchange, или в виртуализации. Раз в год писать статью на две страницы, в которой находят десятки ошибок при первом прочтении — это просто тратить своё время.

  5. Ноябрь 4, 2011 в 18:41

    Руслан, спасибо за коментарий.
    0) Вы не первый кто говорит об этом. Что вfм ответить на это даже не знаю. Но перевода тут нет.
    1) Эту часть я обязательно перечитаю. Но я написал, как я воспринял, читая другую литературу.
    2) Да действительно совсем не правильно. Имея информацию и цифровую подпись мы можем проверить, действительно ли данный сертификат был подписан именно тем, кем заявлено. И имея данную информацию мы сможем сделать первый вывод, о том можем ли мы доверять сертификату.
    3) В сертификате указано время его создания и длительность его жизни. Говорилось об этих пределах
    4) Это не система, я не правильно выразился, это механизм. И как уже была замечено ранее, механизм, называясь не CRL, а CR.

    Да Руслан вы правы о том что много направлений. Но прочитав гору информации по PKI, думал что получится написать статью. Как не странно её перечитывал не один человек до того как я её опубликовал.
    Наверное не стоит вообще лезть в «мир статей».

  6. Ноябрь 4, 2011 в 19:48

    > В сертификате указано время его создания и длительность его жизни. Говорилось об этих пределах

    тоже неверно. В сертификате указано с какого и до какого времени сертификат считается time valid (длительность жизни — тоже не очень верно, потому что там нету типа 5 лет. Есть дата окончания действия открытого ключа). Причём, поле Valid From ни разу не означает, когда он создан. Если упереться совсем в детали, ни один инструмент MS не делает сертификат действительным сразу на момент выдачи Windows CA использует рандомную сдвижку, называемую clock skew. При генерации самоподписанного сертификата средствами .NET или WinAPI, срок действия сертификата начинается только через 4 часа после генерации сертификата. И, в конце концов, это поле может быть переопределено.

    И знаете ли вы, что закрытый ключ и связанный с ним сертификат могут иметь разные сроки действия?

    > Это не система, я не правильно выразился, это механизм

    снова мимо. Расшифруйте последнюю букву (подсказываю — List, что в переводе означает список). Это просто напросто список отозванных сертификатов. Предвосхищая следующий вопрос — там никаких сертификатов нету, только их серийные номера.

    > Наверное не стоит вообще лезть в «мир статей».

    думаю, что не стоит лезть в те направления, в которых плохо разбираетесь. Знание материала на уровень 100 совсем не означает, что вы можете написать статью на этот же уровень.

  7. Ноябрь 4, 2011 в 20:05

    Женя, не обижайся, но статьи это не твое призвание! Лучше не пиши пока не поймешь что готов

  8. Ноябрь 4, 2011 в 22:05

    Маленькие замечания по ответам Евгения на замечания Руслана:

    п.2 Убедившись в индентичности цифровой подписи, доверия не буде. Доверие будет построено после РЯДА проверок, как то проверка «цепочки доверия», «получение информации о том не отозван ли сертификато по КАКОЙ-ЛИБО причине» и мн. другое.
    п.3. В сертификате указаны дата и время создания сертификата и ДАТА и ВРЕМЯ когда сертификат не должен приниматься системами.

    Если не секрет, кто перечитывал?

    С Вадимом абсолютно согласен.

    О себе. Мой писательский слог не ахти, потому и не пишу статьи.

  9. Ноябрь 5, 2011 в 08:43

    Всем спасибо за коменты.
    Андрей, имелось в виду первое принятие решение из целого списка, об этом говорилось и в статье.🙂
    Никто из из читателей не будет против если я внесу исправления в статью?

  1. No trackbacks yet.

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: