В данном FAQ я постараюсь как можно проще и наглядней рассмотреть некоторое аспекты Асимметричного шифрования используемого в CA. FAQ позиционируется исключительно для новичков в данной теме (профи это просто не интересно).
Важно понимать одно: Какое бы ПО Вы не использовали (OpenSSL, Microsoft CA….) алгоритм останется тем же, меняться будут лишь нюансы. Постараюсь пополнять FAQ по мере возникновения вопросов или… просто так.
1. Что такое асимметричное шифрование?
Это тип шифрования основанный на 2 ключах: открытом и секретном.
Открытый ключ (он же публичный ключ) позволяет шифровать данные, но не умеет расшифровывать, то, что зашифровал сам. В данном FAQ он всегда будет встречаться под другим именем - сертификат. Почему так? Смотрите ответ на следующий вопрос.
Секретный ключ (он же личный ключ) действует с точностью наоборот. Он умеет расшифровывать данные зашифрованные открытым ключом (сертификатом), но не используется для шифрования.
Следует заметить, что использование CA автоматом подразумевает использование асимметричного шифрования. В то же время асимметричное шифрование можно использовать и без CA (но это уже выходит из рамках данного FAQ и из темы CA вообще).
2. Что такое сертификат?
Сертификат - это всего лишь набор данных в закодированном виде (не зашифрованном!), которые обычно хранятся в файле.
Рассмотрим типичные данные, которые хранятся в любом сертификате:
2.1 Серийный номер сертификата.
Это обычный порядковый номер, который поставил CA, когда подписывал сертификат. Что такое порядковый номер, думаю объяснять не надо (0,1,2,3,4,5….,n).
Тут стоит оговориться, что самоподписанный сертификат всегда имеет свой собственный номер, который либо генерится случайным образом либо задаётся администратором CA при создании сертификата .
2.2 Информация о владельце сертификата.
Это данные о местоположении владельца сертификата, наименование владельца сертификата (ФИО или наименование организации), e-mail владельца сертификата и т.п. Все эти данные вводятся вручную при создании запроса на сертификат (или самоподписанного сертификата).
Ценность этих данных только одна – информативность. Т.е. чем больше заполнено, тем больше будет известно о владельце тем, кто будет использовать данный сертификат (а это может быть кто угодно).
Остановлюсь только на самом важном значении Common Name (далее CN). Рассмотрим варианты заполнения CN в зависимости от того, где будет использоваться сертификат:
2.2.1 Сертификат физического лица (пользователя)
Тут обычно ФИО пользователя (CN=Пупкин Василий Семёнович).
2.2.2 Сертификат организации (CA выдающий сертификаты тоже организация
).
Тут обычно юридическое имя организации (CN=ООО Моя фирма).
2.2.3 Сертификат для сервера
А вот тут правильность написания CN очень важна. В данном случае CN должно соответствовать FQDN имени сервера по которому за данным сертификатом будут обращаться. Т.е. в случае запроса клиента на https://www.server.ru - ему должен быть выслан сертификат, у которого CN=www.server.ru. Если CN будет отличаться хоть на одну букву, то, какой бы золотой и доверенный у Вас CA не был, сертификат изначально будет признан несоответствующим.
Небольшой пример: Предположим, что У Вас на одном сервере имеется несколько сервисов, которые используют шифрование канала. Вы, для удобства пользования, ввели псевдонимы (www.server.ru, smtp.server.ru, ftp.server.ru). Теперь Вам придётся создавать сертификат для каждого сервиса с соответствующим CN (CN=www.server.ru для доступа по https, CN= smtp.server.ru для доступа по smtps, CN=ftp.server.ru для доступа по ftps).
2.3 Открытый ключ.
Вот мы дошли до самой интересной и самой главной части сертификата. Как раз именно открытый ключ позволяет шифровать данные для владельца сертификата и проверять достоверность подписи (ЭЦП) владельца сертификата (все примеры в разделах ниже посвящены этому). Хоть эти операции и выполняются с помощью открытого ключа, но клиентам-то на руки уходят сертификаты целиком (а не открытый ключ отдельно). Именно поэтому во всех примерах действия выполняются с помощью сертификатов! Это было последнее упоминание, об открытом ключе, как о чём-то отдельном от сертификата.
2.4 Сроки действия сертификата.
Это даты начала и окончания действия сертификата. Подписывая сертификат, администратор CA выставляет период его действия (например 365 дней). За дату начала автоматически принимается момент подписания сертификата. Думаю понятно откуда берётся дата окончания действия сертификата (для непонятливых: Дата окончания = Дата Начала + Период действия).
2.5 Информация о CA подписавшим этот сертификат.
При подписи любого сертификата (за исключением самоподписанного о котором ниже) используется сертификат CA (Только не запутайтесь! Используются некоторые данные из него, а сама ЭЦП всегда ставится только секретным ключом!!!). Думаю понятно, что сертификат CA, как и другие сертификаты, тоже создавался - следовательно у него заполнена информация о владельце сертификата (см. п. 2.2). Вот именно это и содержится в данной части сертификата.
Теперь про самоподписанный, который опять исключение из общего правила. Данный сертификат подписывался только секретным ключом CA (причём своим же). Мысля логически - у него, по идее, не должно быть здесь никаких данных (ну нет над ним CA его подписавшим). Но т.к. данное поле обязательно, то данные есть и содержание этих данных – дублирование информации о владельце сертификата (см. п. 2.2)
2.6 Информация об использованных криптографических алгоритмах.
Чисто информационные данные. Тут содержатся названия криптоалгоритмов которые применялись при создании/подписи сертификата.
2.7 ЭЦП удостоверяющего центра (CA).
А вот это уже основа CA. Содержимое этого раздела появляется в момент подписи запроса на сертификат секретным ключом CA.
Как мы знаем (п. 2.3), сертификат позволяет проверить ЭЦП установленную секретным ключом (который является его парой см п. 1) . В данном случае подпись производилась секретным ключом CA и, что логично, проверить её достоверность может сертификат CA (т.к. он содержит открытый ключ, являющийся парой секретного ключа). Что из того следует? А то, что, во всех примерах ниже, с помощью сертификата CA по этой ЭЦП и определяют - является ли сертификат доверенным (= подписанным секретным ключом CA).
А теперь догадайтесь, чья ЭЦП стоит у самоподписанного сертификата.
2.8 Расширения сертификата (extensions).
С помощью расширений задаётся, как будет использоваться сертификат (его возможности и ограничения). Иногда расширения сертификата называют набором политик сертификата (Certificate Policies).
Возьмём простой пример: Вы задумывались чем отличается клиентский сертификат от сертификата CA? Если сказать просто, то у CA сертификата стоит флаг (собственно расширение), который и говорит, что сертификат может (и будет) использоваться при подписи других сертификатов.
3. Как создать самоподписанный CA?
3.1 Создаём секретный ключ CA.
3.2 Создаём на основе ключа (п. 3.1) самоподписанный сертификат.
Тут я сразу оговорюсь, что в общем создание ключа для CA мало чем отличается от создания ключа для клиента (рассмотренного ниже), так, что алгоритм может выглядеть и так (всё зависит только от используемого Вами ПО):
3.1 Создаём секретный ключ CA.
3.2 Создаём на основе ключа (п. 3.1) запрос на сертификат.
3.3 Подписываем запрос на сертификат (п. 3.2) используя тот же ключ CA (п. 3.1)
Так же стоит отметить, что секретный ключ очень желательно сразу же зашифровать (обычно используется DES). Никто не мешает сделать это при его создании.Но! Не потеряйте пароль! Если Вы его потеряете, то весь Ваш CA в один момент накроется медным тазом, т.к. вы не сможете больше удостоверить ни одного ключа.
Так же не вздумайте потерять или как-то дискредитировать (сделать его доступным кому-либо) секретный ключ! В случае его попадания не в те руки, всё, для чего используется CA (защита от подделки сертификатов), теряет смысл, т.к. злоумышленник сможет наделать кучу легальных сертификатов (CA сертификат-то в открытом доступе для всех).
На выходе имеем: секретный ключ CA и сертификат CA.
4. Как создать клиентские ключи на основе CA?
4.1 Создаём секретный ключ клиента.
4.2 На основе клиентского ключа (п. 4.1) создаём запрос на сертификат.
4.3 Подписываем запрос (п. 4.2) используя секретный ключ CA и сертификат CA (весь п. 3 посвящён им).
4.4 {опционно} Если сертификаты будут использовать некоторые стандартные службы Windows (например IE), то переводим сертификат из PEM в DER. Стоит ознакомиться с документацией софта, который будет использоваться для шифрования, т.к. возможно он работает под Windows, но прекрасно понимает PEM (что такое PEM и DER тоже позже).
4.5 {по желанию} Шифруем секретный ключ клиента используя des. После этого он не будет работать (расшифровывать) без ввода пароля.
У клиента на руках должно быть: секретный ключ клиента, сертификат клиента и сертификат CA.
5. Как происходит процесс обмена зашифрованной информацией между клиентами имеющими сертификаты, которые были подписаны с помощью CA?
Дано: 2 пользователя: Вася и Петя. У каждого полный комплект сертификатов и ключей (смотрите 4 раздел). Они хотят передавать друг другу файлы в зашифрованном виде.
Собственно весь алгоритм:
5.1 Вася даёт Пете свой сертификат (не обязательно из рук в руки, можно переслать по e-mail или выложить на своей страничке).
5.2 Петя с помощью сертификата CA проверяет, что сертификат ему дал именно Вася.
Если CA не подтверждает, что подписывал этот клиентский сертификат, то тут есть варианты:
a) У Васи другой CA (или его ключ и сертификат были сделаны вообще без использования CA)
b) Вася – это не Вася
В любом случае данная проверка предупредит если будет не схождение (собственно это и есть защита от man in the middle), а доверять этому ключу или нет – решать Пете.
5.3 Петя даёт Васе свой сертификат (полностью аналогично 5.1).
5.4 Вася, с помощью сертификата CA, делает тоже, что и Петя, т.е. проверяет и, если надо, принимает к сведению.
Предположим, что всё нормально и все они и есть за кого себя выдают (что подтвердила проверка с помощью CA сертификата).
5.5 Вася шифрует файл Петиным сертификатом и посылает Пете.
5.6 Петя расшифровывает файл с помощью своего секретного ключа и очень рад полученной информации.
5.7 Петя шифрует файл Васиным сертификатом и посылает Васе.
5.8 Вася расшифровывает файл с помощью своего секретного ключа.
6. Как происходит процесс обмена зашифрованной информацией между клиентами имеющими сертификаты, которые были выданы без использования CA?
Дано: 2 пользователя: Вася и Петя. У каждого имеется свой собственный секретный ключ и сертификат (при генерации ключа и сертификата CA не использовался и они были сделаны в совершенно разных местах). Они хотят передавать друг другу файлы в зашифрованном виде.
Алгоритм тогда такой (с его изъянами):
6.1 Вася даёт Пете свой сертификат (причём Петя Может, получая сертификат, не знать Вася ли это….Почему? Смотрите п. 5.1).
6.2 Петя даёт Васе свой сертификат (Вася совершенно аналогично не знает Петя это или нет).
6.3 Вася шифрует файл Петиным сертификатом и посылает Пете (а если там не Петя и сертификат не его?).
6.4 Петя (или злоумышленник) расшифровывает файл с помощью своего секретного ключа.
6.5 Петя шифрует файл Васиным сертификатом и посылает Васе (но 100% уверенности, что именно Васе - быть не может).
6.6 Вася (Хммм. А может нет?) расшифровывает файл с помощью своего секретного ключа.
7. Как происходит процесс обмена подписанными (ЭЦП) данными между клиентами имеющими сертификаты, которые были удостоверены с помощью CA?
Дано: 2 пользователя: Коля и Федя (Петя с Васей уже надоели). У каждого полный комплект сертификатов и ключей (смотрите 4 раздел). Они хотят передавать друг другу файлы удостоверенные своей ЭЦП.
Алгоритм теперь такой:
7.1 Коля передаёт Феде свой сертификат (п 5.1, ну никакой разницы).
7.2 Федя с помощью сертификата CA проверяет, что сертификат ему дал именно Вася (п. 5.2 в чистом виде, включая все предупреждения).
7.3 Федя даёт Коле свой сертификат (и опять аналогично 5.1).
7.4 Коля, с помощью сертификата CA, делает тоже, что и Федя, т.е. проверяет и, если надо, принимает к сведению (Вася и Петя вроде уже это делали в п. 5.4 и 5.2).
В очередной раз предположим, что всё нормально и все они и есть за кого себя выдают (что подтвердила проверка с помощью CA сертификата). На этом закончим повторяться, так как с данного момента и начинаются отличия от шифрования.
7.5 Коля подписывает файл своим секретным ключом и посылает Феде.
7.6 Федя проверяет ЭЦП пришедшего файла с помощью сертификата Коли (заметьте проверяет ЭЦП, а не снимает/расшифровывает).
7.7 Теперь Федя отправляет файл Коле подписав его своим секретным ключом.
7.8 Коля, совершенно аналогично Феде, проверяет ЭЦП пришедшего файла с помощью сертификата Феди.
Раздела “Как происходит процесс обмена подписанными (ЭЦП) данными между клиентами имеющими сертификаты, которые не были удостоверены с помощью CA?” не будет, т.к. основные риски данного метода уже был рассмотрены в 6 разделе.
8. Как происходит шифрование канала при анонимном (т.е. без клиентского сертификата) соединении с сервером использующим систему сертификатов? (например HTTPS).
8.1 Клиент обращается к серверу, отправляя некоторую информацию о себе (никакого шифрования тут нет, просто разновидность HELLO в зависимости от протокола).
8.2 Сервер отправляет клиенту свой сертификат (ну практически точь в точь, как Вася передал Пете чуть выше).
8.3 Клиент проверяет пришедший от сервера сертификат, по своему хранилищу доверенных CA сертификатов.
Если ни один сертификат CA из хранилища не знает кто подписал этот (пришедший в п. 8.2) сертификат, то будет выдано предупреждение о неизвестно откуда взявшемся сертификате. Продолжить шифровать с его помощью или нет – решать только пользователю получившему предупреждение (короче всё тоже самое, что п. 5.2).
8.4 Клиент сверяет CN запись сертификата с FQDN именем сервера.
Если эти записи не совпадают, то опять же будет выдано предупреждение о несоответствии. Угадайте кому решать - принимать данный сертификат или нет? Конечно пользователю.
Данные пункты (8.3 и 8.4) выполняются одновременно и предупреждение в любом случае будет одно и тоже: “несоответствие сертификата”. Я разнёс их только для понимания алгоритма (в одном пункте это выглядело слишком громоздко).
Думаю понятно, что в случае непринятия сертификата, соединение на этом и закончится.
8.5 Клиент генерирует симметричный сеансовый ключ.
8.6 Затем этот ключ (п. 8.5) шифруется полученным сертификатом сервера (п. 8.2) и отправляется на этот самый сервер.
8.7 Сервер расшифровывает послание своим закрытым ключом. Тем самым он получил симметричный ключ (п. 8.5) от клиента.
8.8 На этом использование сертификатов для шифрования заканчивается.
Теперь будет использоваться только симметричный сеансовый ключ для установки и поддержания защищённого соединения с клиентом (т.е. это уже симметричное шифрование).
Вывод: В данном случае шифрование с использованием сертификатов происходит только на этапе установки соединения. Далее тип шифрования меняется на симметричное и ключи с сертификатами в нём никак не участвуют.
9. Шифровать или подписывать?
Этот раздел предназначен специально для тех, кто плохо понимает разницу между этими 2-мя терминами.
Для начала рассмотрим их область применения:
a) Шифрование применяется для обеспечения конфиденциальности информации.
Конфиденциальность информации, если сказать кратко и простым языком - скрывание данных от посторонних глаз. Т.е. если злоумышленник и перехватит что-то в зашифрованном виде (например: файл), то доступ к самому содержимому для него будет очень сильно затруднён (практически невозможен).
b) ЭЦП применяется для обеспечения аутентичности информации.
Аутентичность информации, если опять кратко и просто – это подтверждение того, что источником информации (от первого до последнего символа) является её владелец. При этом никаких секретов не скрывается и информация доступна любому лицу (т.е. конфиденциальности нет).
Теперь ответ на вопрос раздела: “Как Вам нужно, учитывая вышесказанное!”.
При этом никто не мешает комбинировать эти методы! Например можно: подписать документ (файл), после этого зашифровать его и ещё раз сверху подписать.
10. Как отзывают сертификаты?
Предположим, что кому-то (или чему-то) сертификат больше не нужен (человек уволился, скомпрометирован секретный ключ и т.п.). Срок действия сертификата ещё не кончился, но нужно, чтобы он не работал. Для этого администратор CA обновляет список отозванных сертификатов (Certificate revocation list – далее CRL) и размещает его в доступном для всех месте (это может быть сайт, ftp, какая-то шара, да и мало ли что ещё). По своей сути CRL – это файл.
Собственно порядок формирования:
10.1.1 Администратор CA отзывает сертификат.
10.1.2 Обновляется CRL. Выполняется ли данная операция автоматически или вручную администратором CA – зависит от ПО.
10.1.3 CRL размещается в доступном для всех месте.
Получается, чтобы узнать, можно доверять сертификату или нет, нам так же необходимо проверить – а не отозван ли он (думаю понятно, что отозванному доверять нельзя). Для этого мы берём CRL от туда, куда его положил администратор CA и проверяем сертификат на непопадание в список (если всё нормально и сертификата в списке нет, можно продолжать работать с сертификатом). Стоит заметить, что если Вы проверяете сертификат, подписанный не Вашим CA, то и брать CRL надо соответственно из места куда он был выложен Администратором соответствующего (не Вашего) CA. И хорошо если используемое Вами ПО позволяет (после небольшой настройки) делать это автоматом, в противном случае Вам придётся делать это (скачивать и устанавливать CRL или проводить проверку on-line по CRL) руками.
Основной недостаток CRL в том, что в некоторых случаях (особенно по незнанию и/или лени) его можно просто игнорировать – т.е. не проверять сертификаты на попадание в список или не регулярно обновлять список (в случае если проверка не on-line). В таком случае корректно выданный, но отозванный сертификат успешно пройдёт проверку и будет считаться действительным (хотя таковым уже не является).
Рассмотрим на примере:
10.2.1 Петя уволился (сам или нет..)
10.2.2 На место Пети посадили Колю, который получил полный доступ к всей информации Пети. При этом ещё не все знают, что Пети нет.
10.2.3 Маша (которая ещё не знает, что случилось) шлёт Пете файл (что-то личное?!), зашифровав его Петиним открытым ключом.
10.2.4 Коля имеет доступ к секретному ключу Пети и может прочитать информацию от Маши. Так же не забываем, что он может ставить ЭЦП от имени Пети.
Если бы Маша проверила Петин сертификат по CRL, то она бы узнала, что сертификатом Пети шифровать уже нельзя. Да и другие люди должны знать, что Петя ничего больше подписывать не должен. Т.е. все должны регулярно обновлять CRL (если это не делается автоматически или ПО само не производит on-line проверку сертификата).
11. Что такое иерархия CA?
Любой толковый словарь скажет Вам, что иерархия – это порядок подчинения (сверху вниз).
Теоретический (т.к. это только один из вариантов) пример иерархии CA (порядка подчинения) показан на Рисунке 1.
Рисунок 1
Не правда ли иерархия CA сильно напоминает доменную структуру (лес, ветки, листья)?
Чаще всего (если Вы конечно не администратор крупного CA, который удостоверяет сертификаты половины страны) Вы будете иметь дело с простой иерархией. Два примера простой иерархии и приведены на рисунке 2.
Рисунок 2
Примечание к обоим рисункам:
Root CA (корневой CA) – это самый верхний уровень иерархии. Именно тут (и только тут) используется самоподписанный сертификат. В идеале (но мир не идеален) компьютер на котором содержится Root CA должен быть отключен от LAN, выключен и спрятан в сейф (Почему? смотрите предупреждения в 3 разделе данного FAQ).
CA – центр сертификации, сертификат которого был заверен вышестоящим CA.
Клиент – именной сертификат клиента.
HTTPS, SMTPS – сертификаты соответствующих сервисов.
Естественно каждый из объектов в данном примечании подразумевает наличие персонального (для каждого объекта) секретного ключа!
Источник: здесь
Важно понимать одно: Какое бы ПО Вы не использовали (OpenSSL, Microsoft CA….) алгоритм останется тем же, меняться будут лишь нюансы. Постараюсь пополнять FAQ по мере возникновения вопросов или… просто так.
1. Что такое асимметричное шифрование?
Это тип шифрования основанный на 2 ключах: открытом и секретном.
Открытый ключ (он же публичный ключ) позволяет шифровать данные, но не умеет расшифровывать, то, что зашифровал сам. В данном FAQ он всегда будет встречаться под другим именем - сертификат. Почему так? Смотрите ответ на следующий вопрос.
Секретный ключ (он же личный ключ) действует с точностью наоборот. Он умеет расшифровывать данные зашифрованные открытым ключом (сертификатом), но не используется для шифрования.
Следует заметить, что использование CA автоматом подразумевает использование асимметричного шифрования. В то же время асимметричное шифрование можно использовать и без CA (но это уже выходит из рамках данного FAQ и из темы CA вообще).
2. Что такое сертификат?
Сертификат - это всего лишь набор данных в закодированном виде (не зашифрованном!), которые обычно хранятся в файле.
Рассмотрим типичные данные, которые хранятся в любом сертификате:
2.1 Серийный номер сертификата.
Это обычный порядковый номер, который поставил CA, когда подписывал сертификат. Что такое порядковый номер, думаю объяснять не надо (0,1,2,3,4,5….,n).
Тут стоит оговориться, что самоподписанный сертификат всегда имеет свой собственный номер, который либо генерится случайным образом либо задаётся администратором CA при создании сертификата .
2.2 Информация о владельце сертификата.
Это данные о местоположении владельца сертификата, наименование владельца сертификата (ФИО или наименование организации), e-mail владельца сертификата и т.п. Все эти данные вводятся вручную при создании запроса на сертификат (или самоподписанного сертификата).
Ценность этих данных только одна – информативность. Т.е. чем больше заполнено, тем больше будет известно о владельце тем, кто будет использовать данный сертификат (а это может быть кто угодно).
Остановлюсь только на самом важном значении Common Name (далее CN). Рассмотрим варианты заполнения CN в зависимости от того, где будет использоваться сертификат:
2.2.1 Сертификат физического лица (пользователя)
Тут обычно ФИО пользователя (CN=Пупкин Василий Семёнович).
2.2.2 Сертификат организации (CA выдающий сертификаты тоже организация
). Тут обычно юридическое имя организации (CN=ООО Моя фирма).
2.2.3 Сертификат для сервера
А вот тут правильность написания CN очень важна. В данном случае CN должно соответствовать FQDN имени сервера по которому за данным сертификатом будут обращаться. Т.е. в случае запроса клиента на https://www.server.ru - ему должен быть выслан сертификат, у которого CN=www.server.ru. Если CN будет отличаться хоть на одну букву, то, какой бы золотой и доверенный у Вас CA не был, сертификат изначально будет признан несоответствующим.
Небольшой пример: Предположим, что У Вас на одном сервере имеется несколько сервисов, которые используют шифрование канала. Вы, для удобства пользования, ввели псевдонимы (www.server.ru, smtp.server.ru, ftp.server.ru). Теперь Вам придётся создавать сертификат для каждого сервиса с соответствующим CN (CN=www.server.ru для доступа по https, CN= smtp.server.ru для доступа по smtps, CN=ftp.server.ru для доступа по ftps).
2.3 Открытый ключ.
Вот мы дошли до самой интересной и самой главной части сертификата. Как раз именно открытый ключ позволяет шифровать данные для владельца сертификата и проверять достоверность подписи (ЭЦП) владельца сертификата (все примеры в разделах ниже посвящены этому). Хоть эти операции и выполняются с помощью открытого ключа, но клиентам-то на руки уходят сертификаты целиком (а не открытый ключ отдельно). Именно поэтому во всех примерах действия выполняются с помощью сертификатов! Это было последнее упоминание, об открытом ключе, как о чём-то отдельном от сертификата.
2.4 Сроки действия сертификата.
Это даты начала и окончания действия сертификата. Подписывая сертификат, администратор CA выставляет период его действия (например 365 дней). За дату начала автоматически принимается момент подписания сертификата. Думаю понятно откуда берётся дата окончания действия сертификата (для непонятливых: Дата окончания = Дата Начала + Период действия).
2.5 Информация о CA подписавшим этот сертификат.
При подписи любого сертификата (за исключением самоподписанного о котором ниже) используется сертификат CA (Только не запутайтесь! Используются некоторые данные из него, а сама ЭЦП всегда ставится только секретным ключом!!!). Думаю понятно, что сертификат CA, как и другие сертификаты, тоже создавался - следовательно у него заполнена информация о владельце сертификата (см. п. 2.2). Вот именно это и содержится в данной части сертификата.
Теперь про самоподписанный, который опять исключение из общего правила. Данный сертификат подписывался только секретным ключом CA (причём своим же). Мысля логически - у него, по идее, не должно быть здесь никаких данных (ну нет над ним CA его подписавшим). Но т.к. данное поле обязательно, то данные есть и содержание этих данных – дублирование информации о владельце сертификата (см. п. 2.2)
2.6 Информация об использованных криптографических алгоритмах.
Чисто информационные данные. Тут содержатся названия криптоалгоритмов которые применялись при создании/подписи сертификата.
2.7 ЭЦП удостоверяющего центра (CA).
А вот это уже основа CA. Содержимое этого раздела появляется в момент подписи запроса на сертификат секретным ключом CA.
Как мы знаем (п. 2.3), сертификат позволяет проверить ЭЦП установленную секретным ключом (который является его парой см п. 1) . В данном случае подпись производилась секретным ключом CA и, что логично, проверить её достоверность может сертификат CA (т.к. он содержит открытый ключ, являющийся парой секретного ключа). Что из того следует? А то, что, во всех примерах ниже, с помощью сертификата CA по этой ЭЦП и определяют - является ли сертификат доверенным (= подписанным секретным ключом CA).
А теперь догадайтесь, чья ЭЦП стоит у самоподписанного сертификата.
2.8 Расширения сертификата (extensions).
С помощью расширений задаётся, как будет использоваться сертификат (его возможности и ограничения). Иногда расширения сертификата называют набором политик сертификата (Certificate Policies).
Возьмём простой пример: Вы задумывались чем отличается клиентский сертификат от сертификата CA? Если сказать просто, то у CA сертификата стоит флаг (собственно расширение), который и говорит, что сертификат может (и будет) использоваться при подписи других сертификатов.
3. Как создать самоподписанный CA?
3.1 Создаём секретный ключ CA.
3.2 Создаём на основе ключа (п. 3.1) самоподписанный сертификат.
Тут я сразу оговорюсь, что в общем создание ключа для CA мало чем отличается от создания ключа для клиента (рассмотренного ниже), так, что алгоритм может выглядеть и так (всё зависит только от используемого Вами ПО):
3.1 Создаём секретный ключ CA.
3.2 Создаём на основе ключа (п. 3.1) запрос на сертификат.
3.3 Подписываем запрос на сертификат (п. 3.2) используя тот же ключ CA (п. 3.1)
Так же стоит отметить, что секретный ключ очень желательно сразу же зашифровать (обычно используется DES). Никто не мешает сделать это при его создании.Но! Не потеряйте пароль! Если Вы его потеряете, то весь Ваш CA в один момент накроется медным тазом, т.к. вы не сможете больше удостоверить ни одного ключа.
Так же не вздумайте потерять или как-то дискредитировать (сделать его доступным кому-либо) секретный ключ! В случае его попадания не в те руки, всё, для чего используется CA (защита от подделки сертификатов), теряет смысл, т.к. злоумышленник сможет наделать кучу легальных сертификатов (CA сертификат-то в открытом доступе для всех).
На выходе имеем: секретный ключ CA и сертификат CA.
4. Как создать клиентские ключи на основе CA?
4.1 Создаём секретный ключ клиента.
4.2 На основе клиентского ключа (п. 4.1) создаём запрос на сертификат.
4.3 Подписываем запрос (п. 4.2) используя секретный ключ CA и сертификат CA (весь п. 3 посвящён им).
4.4 {опционно} Если сертификаты будут использовать некоторые стандартные службы Windows (например IE), то переводим сертификат из PEM в DER. Стоит ознакомиться с документацией софта, который будет использоваться для шифрования, т.к. возможно он работает под Windows, но прекрасно понимает PEM (что такое PEM и DER тоже позже).
4.5 {по желанию} Шифруем секретный ключ клиента используя des. После этого он не будет работать (расшифровывать) без ввода пароля.
У клиента на руках должно быть: секретный ключ клиента, сертификат клиента и сертификат CA.
5. Как происходит процесс обмена зашифрованной информацией между клиентами имеющими сертификаты, которые были подписаны с помощью CA?
Дано: 2 пользователя: Вася и Петя. У каждого полный комплект сертификатов и ключей (смотрите 4 раздел). Они хотят передавать друг другу файлы в зашифрованном виде.
Собственно весь алгоритм:
5.1 Вася даёт Пете свой сертификат (не обязательно из рук в руки, можно переслать по e-mail или выложить на своей страничке).
5.2 Петя с помощью сертификата CA проверяет, что сертификат ему дал именно Вася.
Если CA не подтверждает, что подписывал этот клиентский сертификат, то тут есть варианты:
a) У Васи другой CA (или его ключ и сертификат были сделаны вообще без использования CA)
b) Вася – это не Вася
В любом случае данная проверка предупредит если будет не схождение (собственно это и есть защита от man in the middle), а доверять этому ключу или нет – решать Пете.
5.3 Петя даёт Васе свой сертификат (полностью аналогично 5.1).
5.4 Вася, с помощью сертификата CA, делает тоже, что и Петя, т.е. проверяет и, если надо, принимает к сведению.
Предположим, что всё нормально и все они и есть за кого себя выдают (что подтвердила проверка с помощью CA сертификата).
5.5 Вася шифрует файл Петиным сертификатом и посылает Пете.
5.6 Петя расшифровывает файл с помощью своего секретного ключа и очень рад полученной информации.
5.7 Петя шифрует файл Васиным сертификатом и посылает Васе.
5.8 Вася расшифровывает файл с помощью своего секретного ключа.
6. Как происходит процесс обмена зашифрованной информацией между клиентами имеющими сертификаты, которые были выданы без использования CA?
Дано: 2 пользователя: Вася и Петя. У каждого имеется свой собственный секретный ключ и сертификат (при генерации ключа и сертификата CA не использовался и они были сделаны в совершенно разных местах). Они хотят передавать друг другу файлы в зашифрованном виде.
Алгоритм тогда такой (с его изъянами):
6.1 Вася даёт Пете свой сертификат (причём Петя Может, получая сертификат, не знать Вася ли это….Почему? Смотрите п. 5.1).
6.2 Петя даёт Васе свой сертификат (Вася совершенно аналогично не знает Петя это или нет).
6.3 Вася шифрует файл Петиным сертификатом и посылает Пете (а если там не Петя и сертификат не его?).
6.4 Петя (или злоумышленник) расшифровывает файл с помощью своего секретного ключа.
6.5 Петя шифрует файл Васиным сертификатом и посылает Васе (но 100% уверенности, что именно Васе - быть не может).
6.6 Вася (Хммм. А может нет?) расшифровывает файл с помощью своего секретного ключа.
7. Как происходит процесс обмена подписанными (ЭЦП) данными между клиентами имеющими сертификаты, которые были удостоверены с помощью CA?
Дано: 2 пользователя: Коля и Федя (Петя с Васей уже надоели). У каждого полный комплект сертификатов и ключей (смотрите 4 раздел). Они хотят передавать друг другу файлы удостоверенные своей ЭЦП.
Алгоритм теперь такой:
7.1 Коля передаёт Феде свой сертификат (п 5.1, ну никакой разницы).
7.2 Федя с помощью сертификата CA проверяет, что сертификат ему дал именно Вася (п. 5.2 в чистом виде, включая все предупреждения).
7.3 Федя даёт Коле свой сертификат (и опять аналогично 5.1).
7.4 Коля, с помощью сертификата CA, делает тоже, что и Федя, т.е. проверяет и, если надо, принимает к сведению (Вася и Петя вроде уже это делали в п. 5.4 и 5.2).
В очередной раз предположим, что всё нормально и все они и есть за кого себя выдают (что подтвердила проверка с помощью CA сертификата). На этом закончим повторяться, так как с данного момента и начинаются отличия от шифрования.
7.5 Коля подписывает файл своим секретным ключом и посылает Феде.
7.6 Федя проверяет ЭЦП пришедшего файла с помощью сертификата Коли (заметьте проверяет ЭЦП, а не снимает/расшифровывает).
7.7 Теперь Федя отправляет файл Коле подписав его своим секретным ключом.
7.8 Коля, совершенно аналогично Феде, проверяет ЭЦП пришедшего файла с помощью сертификата Феди.
Раздела “Как происходит процесс обмена подписанными (ЭЦП) данными между клиентами имеющими сертификаты, которые не были удостоверены с помощью CA?” не будет, т.к. основные риски данного метода уже был рассмотрены в 6 разделе.
8. Как происходит шифрование канала при анонимном (т.е. без клиентского сертификата) соединении с сервером использующим систему сертификатов? (например HTTPS).
8.1 Клиент обращается к серверу, отправляя некоторую информацию о себе (никакого шифрования тут нет, просто разновидность HELLO в зависимости от протокола).
8.2 Сервер отправляет клиенту свой сертификат (ну практически точь в точь, как Вася передал Пете чуть выше).
8.3 Клиент проверяет пришедший от сервера сертификат, по своему хранилищу доверенных CA сертификатов.
Если ни один сертификат CA из хранилища не знает кто подписал этот (пришедший в п. 8.2) сертификат, то будет выдано предупреждение о неизвестно откуда взявшемся сертификате. Продолжить шифровать с его помощью или нет – решать только пользователю получившему предупреждение (короче всё тоже самое, что п. 5.2).
8.4 Клиент сверяет CN запись сертификата с FQDN именем сервера.
Если эти записи не совпадают, то опять же будет выдано предупреждение о несоответствии. Угадайте кому решать - принимать данный сертификат или нет? Конечно пользователю.
Данные пункты (8.3 и 8.4) выполняются одновременно и предупреждение в любом случае будет одно и тоже: “несоответствие сертификата”. Я разнёс их только для понимания алгоритма (в одном пункте это выглядело слишком громоздко).
Думаю понятно, что в случае непринятия сертификата, соединение на этом и закончится.
8.5 Клиент генерирует симметричный сеансовый ключ.
8.6 Затем этот ключ (п. 8.5) шифруется полученным сертификатом сервера (п. 8.2) и отправляется на этот самый сервер.
8.7 Сервер расшифровывает послание своим закрытым ключом. Тем самым он получил симметричный ключ (п. 8.5) от клиента.
8.8 На этом использование сертификатов для шифрования заканчивается.
Теперь будет использоваться только симметричный сеансовый ключ для установки и поддержания защищённого соединения с клиентом (т.е. это уже симметричное шифрование).
Вывод: В данном случае шифрование с использованием сертификатов происходит только на этапе установки соединения. Далее тип шифрования меняется на симметричное и ключи с сертификатами в нём никак не участвуют.
9. Шифровать или подписывать?
Этот раздел предназначен специально для тех, кто плохо понимает разницу между этими 2-мя терминами.
Для начала рассмотрим их область применения:
a) Шифрование применяется для обеспечения конфиденциальности информации.
Конфиденциальность информации, если сказать кратко и простым языком - скрывание данных от посторонних глаз. Т.е. если злоумышленник и перехватит что-то в зашифрованном виде (например: файл), то доступ к самому содержимому для него будет очень сильно затруднён (практически невозможен).
b) ЭЦП применяется для обеспечения аутентичности информации.
Аутентичность информации, если опять кратко и просто – это подтверждение того, что источником информации (от первого до последнего символа) является её владелец. При этом никаких секретов не скрывается и информация доступна любому лицу (т.е. конфиденциальности нет).
Теперь ответ на вопрос раздела: “Как Вам нужно, учитывая вышесказанное!”.
При этом никто не мешает комбинировать эти методы! Например можно: подписать документ (файл), после этого зашифровать его и ещё раз сверху подписать.
10. Как отзывают сертификаты?
Предположим, что кому-то (или чему-то) сертификат больше не нужен (человек уволился, скомпрометирован секретный ключ и т.п.). Срок действия сертификата ещё не кончился, но нужно, чтобы он не работал. Для этого администратор CA обновляет список отозванных сертификатов (Certificate revocation list – далее CRL) и размещает его в доступном для всех месте (это может быть сайт, ftp, какая-то шара, да и мало ли что ещё). По своей сути CRL – это файл.
Собственно порядок формирования:
10.1.1 Администратор CA отзывает сертификат.
10.1.2 Обновляется CRL. Выполняется ли данная операция автоматически или вручную администратором CA – зависит от ПО.
10.1.3 CRL размещается в доступном для всех месте.
Получается, чтобы узнать, можно доверять сертификату или нет, нам так же необходимо проверить – а не отозван ли он (думаю понятно, что отозванному доверять нельзя). Для этого мы берём CRL от туда, куда его положил администратор CA и проверяем сертификат на непопадание в список (если всё нормально и сертификата в списке нет, можно продолжать работать с сертификатом). Стоит заметить, что если Вы проверяете сертификат, подписанный не Вашим CA, то и брать CRL надо соответственно из места куда он был выложен Администратором соответствующего (не Вашего) CA. И хорошо если используемое Вами ПО позволяет (после небольшой настройки) делать это автоматом, в противном случае Вам придётся делать это (скачивать и устанавливать CRL или проводить проверку on-line по CRL) руками.
Основной недостаток CRL в том, что в некоторых случаях (особенно по незнанию и/или лени) его можно просто игнорировать – т.е. не проверять сертификаты на попадание в список или не регулярно обновлять список (в случае если проверка не on-line). В таком случае корректно выданный, но отозванный сертификат успешно пройдёт проверку и будет считаться действительным (хотя таковым уже не является).
Рассмотрим на примере:
10.2.1 Петя уволился (сам или нет..)
10.2.2 На место Пети посадили Колю, который получил полный доступ к всей информации Пети. При этом ещё не все знают, что Пети нет.
10.2.3 Маша (которая ещё не знает, что случилось) шлёт Пете файл (что-то личное?!), зашифровав его Петиним открытым ключом.
10.2.4 Коля имеет доступ к секретному ключу Пети и может прочитать информацию от Маши. Так же не забываем, что он может ставить ЭЦП от имени Пети.
Если бы Маша проверила Петин сертификат по CRL, то она бы узнала, что сертификатом Пети шифровать уже нельзя. Да и другие люди должны знать, что Петя ничего больше подписывать не должен. Т.е. все должны регулярно обновлять CRL (если это не делается автоматически или ПО само не производит on-line проверку сертификата).
11. Что такое иерархия CA?
Любой толковый словарь скажет Вам, что иерархия – это порядок подчинения (сверху вниз).
Теоретический (т.к. это только один из вариантов) пример иерархии CA (порядка подчинения) показан на Рисунке 1.
Рисунок 1
Не правда ли иерархия CA сильно напоминает доменную структуру (лес, ветки, листья)?
Чаще всего (если Вы конечно не администратор крупного CA, который удостоверяет сертификаты половины страны) Вы будете иметь дело с простой иерархией. Два примера простой иерархии и приведены на рисунке 2.
Рисунок 2
Примечание к обоим рисункам:
Root CA (корневой CA) – это самый верхний уровень иерархии. Именно тут (и только тут) используется самоподписанный сертификат. В идеале (но мир не идеален) компьютер на котором содержится Root CA должен быть отключен от LAN, выключен и спрятан в сейф (Почему? смотрите предупреждения в 3 разделе данного FAQ).
CA – центр сертификации, сертификат которого был заверен вышестоящим CA.
Клиент – именной сертификат клиента.
HTTPS, SMTPS – сертификаты соответствующих сервисов.
Естественно каждый из объектов в данном примечании подразумевает наличие персонального (для каждого объекта) секретного ключа!
Источник: здесь
Комментариев нет:
Отправить комментарий