LINUX.ORG.RU

Как работает проверка подписи сертификатов (CA)?

 , ,


1

2

Не совсем linux, но честно, не знаю куда еще податься. Прочитал кучу статей, наконец разобрался как работают технологии симметричных и ассиметричных ключей SSL, но так и не понял как именно (в математическом смысле) работает проверка валидности (читай подлинности) сертификата.

Допустим: Есть «клиент», желающий общаться с «сервером» в зашифрованном виде, клиент просит у сервера его публичный ключ, после чего его каким-то образом проверяет с имеющимся у него сертификатом (открытый ключ) доверительного центра сертификации (ЦС). А дальше история про Боба и Алису. Но как именно проверяется сертификат на его валидность и подписанность ЦС?

Конечно, есть контрольные суммы - это очевидно. Но подпись центра сертификации в сертификате сервера генерируется с использованием закрытого ключа того же ЦС от чего никто кроме самого ЦС не может фальсифицировать сертификаты, тогда как именно клиент поймёт, что этот сертификат действительно подписан ЦС и пренадлежит серверу, имея у себя только открытую часть ключа ЦС и то, что ему дал сервер. Помогите разобраться?

Я даже, вроде как, нашел формулу на википедии
http://bit.ly/1DXwL4u (Сертификат открытого ключа / Формальное описание)
Но в этой офигенной формуле один большой изъян: откуда блин взялась переменная Ss которой неожиданно владеет А2 ?!

Перемещено JB из general

Почитай про ЭЦП

Если на пальцах, то схема такая:
1. Сервер генерирует приватный ключ и запрос на получение сертификата - csr.
2. Отправляет csr сертифакионному центру
3. СЦ возвращает серверу сертификат (открытый ключ, подписанный закрытым ключом СЦ).
4. Когда клиент обращается к серверу, он первым делом смотрит на сертификат сервера. Если у него корректная подпись СЦ, значит ему можно доверять. Подписать сертификат сервера может только СЦ, ведь приватный ключ СЦ есть только у СЦ :)

generator ★★★
()

Кратенько:

1. Есть корневые CA. Это компании, которым большинство решило доверять. Каждая CA имеет приватный и публичный ключ (RSA или ECDSA). При помощи приватного ключа подписывается сертификат, который содержит публичный ключ. Все браузеры таскают с собой некоторый набор сертификатов корневых CA.

2. Сами корневые CA напрямую сертификаты не продают, а перепоручают это промежуточным CA. У промежуточного CA тоже есть свой публичный и приватный ключ. Промежуточный CA вставляет свой публичный ключ в заготовок для сертификта (CSR) и просит корневую CA подписать ее своим ключем. Корневая CA подписывает заготовку своим приватным ключем и получается сертификат промежуточного CA. Важно: подписанный корневым CA сертификат для промежуточного CA имеет право подписи ( в сертификате для этого делается специальная запись).

3. Промежуточные CA тоже часто сами не подписывают клиентам сертификаты, а перепоручают это дело другим промежуточным, подписывая уже своим приватным ключем сертификаты с правом подписи.

4. В конце концов мы приходим к конечному CA, который и выдает сертификаты клиентам. Итак, есть пользователь Вася. Он хочет для vasya.ru сертификат. Он генерирует приватный и публичный ключи, делает заготовку для сертификата с публичным ключем и отправляет запрос к CA для создания сертификата. Конечная CA подписывает своим приватным ключем запрос от клиента и получается сертификат для клиента. Этот сертификат + сертификаты ВСЕХ промежуточных CA, отдаются клиенту Васе. Вася в своем любимом веб сервере указывает путь к приватному ключу и путь к ЦЕПОЧКЕ сертификатов. Важно: Васин сертификат уже права подписи не имеет.

5. Маша в браузере Firefox, который с собой таскает набор корневых сертификатов, идет на https://vasya.ru. Сервер в ответ на запрос firefox возвращает ВСЮ ЦЕПОЧКУ сертификатов.

Пусть цепочка выглядет так - <Сертификат Васи> --> <Сертификат конечного CA> --> <Сертификат промежуточного CA> и будем считать, что <Сертификат промежуточного CA> подписан корневым CA. Firefox при помощи публичного ключа из сертификата конечного CA проверяет, что сертификат Васи подписан приватным ключем этого конечного CA. Если проверка прошла успешно, то далее Firefox при помощи публичного ключа из сертификата промежуточного CA проверяет, что сертификат конечного CA подписан приватным ключем этого промежуточного CA. Если проверка проходит успешно, то Firefox переходит к сертификату промежуточного CA. Поскольку цепочка оборвалась, то Firefox смотрит в локальном хранилище сертификатов корневых CA ту CA, которая своим приватным ключем подписывала сертификат для промежуточного CA - эта информация (кто подписал сертификат) зашита в каждом сертификате. Далее при помощи публичного ключа корневой CA, проверяется, что сертификат промежуточной CA подписан приватным ключем корневой CA. Если проверка прошла успешно, то вся цепочка считается валидной и ей доверяют.

Vovka-Korovka ★★★★★
()

generator, Vovka-Korovka спасибо за общий алгоритм, но с ним я и так разобрался. Идём по цепочки и проверяем пока не дойдем до корневого... это всё понятно.

Но вопрос совсем в другом. Блин.. Довольно сложно формулировать вопрос. Попробую иначе.

Имеем:
- Некий сертификат с некой подписью (причем подпись генерируется с использованием неизвестной переменной)
- Имеется некий открытый ключ доверительного центра сертификации

И собственно всё. Как я зная всего лишь открытую часть, которая в доступе у всех однозначно определю что эта подпись верна? Ну да, пришел какой-то сертификат, ну да, кем-то там подписан. Всё что я могу «проверить» можно «подделать» т.к. и я и мошенник имеем публичную часть сертификата ЦС и только.

ilmenshik
() автор топика
Ответ на: комментарий от ilmenshik

И собственно всё. Как я зная всего лишь открытую часть, которая в доступе у всех однозначно определю что эта подпись верна? Ну да, пришел какой-то сертификат, ну да, кем-то там подписан. Всё что я могу «проверить» можно «подделать» т.к. и я и мошенник имеем публичную часть сертификата ЦС и только.

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

Т.е. берется сертификат (сочетание открытого ключа, имени, периода действия, серийного номера и прочего), от этого всего считается хэш-функция (SHA1, SHA-2 или ещё какая-нибудь), затем результат хэш-функции зашифровывается закрытм (приватным) ключом. Результат шифрования и есть цифровая подпись. Для проверки подпись расшифровывается открытым ключом из сертификата CA и полученный хэш сравнивается с хэшем, который проверяющий считает самостоятельно от проверяемого сертификата

Harald ★★★★★
()
29 августа 2016 г.
Ответ на: комментарий от anonymous

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

Именно отсутствие права подписи мешает, например, Васе Пупкину, получив сертификат для домена vasya-pupkin.ru, подписать своим приватным ключом от этого сертификата сертификат для другого домена, например, google.ru. Точнее, подписать он по прежнему может, но нормальные реализации SSL/TLS будут ругаться на такую цепочку сертификатов.

Vovka-Korovka ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.