Каким образом формируется сертификация открытых ключей?

Question

[marmuff]

Имеется стандартный ассиметричный алгоритм шифрования (пусть будет RSA).
Вопрос касательно сертификации открытых ключей центром сертификации для организации end-to-end шифрования.

Вопрос - каким образом происходит сертификация и проверяется подпись?
Выдержка из Вики:

Сертификат открытого ключа выдаётся центром сертификации и состоит из таких полей как:

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

Как я понял принцип работы:
Пользователь А генерирует открытый и закрытый ключи. Открытый ключ направляется центру сертификации. Он генерирует некий DTO примерно следующего вида:

{
    "public_key": "здесь открытый, для которого и создаётся сертификат",
    "sertification_center_name": "название центра сертификации",
    "sertificate_owner_name": "имя владельца сертификата",
    "sign": "MD5 хэш всех этих данных после того, как они были зашифрованы закрытым ключом центра сертификации"

Мы направляем данный сертификат собеседнику. Он расшифровывает подпись сертификата, после чего вычисляет хэш-функцию от всех его полей (за исключением самой подписи) и сравнивает хэши. Если они совпали - все ок, публичным ключом можно шифровать.

Все верно? Если да, то возникает вопрос: в чем здесь дополнительное обеспечение безопасности? Что мешает подменить не обычный отправляемый публичный ключ, а сам сертификат на сертификат другого ключа?

Comments

[res2001]

ЦА отправляется запрос на сертификат, на который генерируется сертификат.
Для проверки подписи сертификата нужен открытый открытый ключ (сертификат) ЦА.

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

1.Появляется третья сторона (ЦА), которой "доверяют" обе стороны обмена. Обычно ЦА являются некие общеизвестные организации c хорошей репутацией. В РФ сертифицированные ЦА имеют сертификат от ФСБ.
2.Открытый и закрытый ключи работают в паре, если по дороге на сертификацию будет подменен открытый ключ и на него будет выдан сертификат, то зашифрованное этим поддельным сертификатом сообщение нельзя будет расшифровать оригинальным закрытым ключем.
Кроме того подпись ЦА на сертификате генерируется с помощью закрытого ключа ЦА, а проверяется с помощью открытого ключа ЦА. За безопасностью своих закрытых ключей ЦА должен очень строго следить. Фактически на этом держится вся защита в PKI - т.е. закрытый ключ ЦА должен быть строго секретный. Все остальное можно отрегулировать списками отзыва, но если будет утечка закрытого ключа ЦА, то вся сеть PKI будет скомпрометирована.

Answer 1

[CityCat4]

У сертификата с ключом есть некий уникальный ID, по которому они друг друга опознают, ключ чужого сертификата бесполезен. И кроме того, считается, что ключ сертификата хранится в безопасном месте и не доступен кому попало. Утечка ключа = компроментация сертификата.

Answer 2

[granty]

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

Вы только что описали атаку MitM SSL.
Но, как уже отметил res2001 в камментах, есть третья доверенная сторона - Центр Сертификации(Центр аттестации), он подтверждает валидность используемого SSL-сертификата.

spoiler

Поскольку все РФ-сертификационные центры (центры аттестации) должны иметь сертификат от ФСБ, последние имеют доступ ко всем приватным ключам. Поэтому любой, установленный на ПК, российский SSL-сертификат потенциально небезопасен.