Зачем нужен сертификат?

Question

[aopil]

1) base64 Данные
2) base64 RSA certificate chain including root CA
3) base64 Подпись (SHA1+RSA) Данных, подтвержденная с помощью сертификата (пункт 2).

Переводим данные из пункта 1 в hash, далее, имея Public Key я кодирую эти данные и получаю подпись.

Тот, кто имеет Private Key может расшифровать мою подпись и сравнить хэш данных.

ВОПРОС: Если я всё правильно понимаю, то зачем нужен пункт 2 (сертификаты) и что они даюит?)

Comments

[Valentin Barbolin]

> 2) base64 RSA certificate chain including root CA
цепочка обычно состоит из SBCA (подчиненный CA, может быть несколько) и root CA.
root CA выедт сертификаты SBCA, который в свою очередь уже выдает сертификат тебе.
root CA обычно установлены в системе для проверки все цепочки сертификата.

Answer 1

[SagePtr]

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

Comments

[aopil]

SagePtr таким образом, сертификат содержит RSA Public Key которым я ставлю подпись?
Ниже фото:

[SagePtr]

aopil, да, только подпись ставится закрытой частью ключа, открытой проверяется

[aopil]

SagePtr, вы уверены? В 100% случаев используется именно private key для подписи? В моём случае похоже используется Public Key для подписи, а private key для проверки.

[aopil]

SagePtr, получается, если в сертификате мы указываем private ключ или public ключ, не столь важно, то в сертификате данный ключ будет всегда один тот же, и ничто не мешает взять уже готовый сертификат от любого оригинального запроса и использовать его, или что мешает? время действия сертификата? Не знаю, но я посылаю просроченный сертификат оригинального запроса и сервер успешно принимает его)

[SagePtr]

aopil, по стандарту - private key используется для подписи и расшифровки, а public key - для проверки подписи и зашифровки. Именно потому мы и не можем взять любой сертификат и подписать данные ключом, приложенным к нему. В теории-то мы можем, но никто нам не поверит, ибо ключи работают в паре, чтобы подпись была верной - нужно подписывать ключом, противоположным тому, что приложен к сертификату (т.е. приватным, а не публичным). А приватный хранится в тайне на сервере.
По сути, если мы нарушим стандарт и договоримся с другой стороной, что подпись осуществляется публичным ключом, а проверка приватным (и внесём соответствующие правки в наше ПО), то результат проверки будет верным, но любой со стороны сможет подделать эту подпись, ибо публичный ключ доступен всем, в итоге мы просто скомпрометируем нашу систему и уберём оттуда секретность.

[aopil]

SagePtr, раз 20 прочитал ваше сообщение и не могу понять.

по стандарту - private key используется для подписи и расшифровки

Как Private key может использоваться и для подписи и для расшифровки?) Чем кодируем тем и декодируем?))))) Ну не логично же, или я что-то путаю!

Давайте еще раз сначала: У нас есть Public Key и Private Key. Подпись мы ставим через Public, а Private хранится на сервере куда мы отправляем наше сообщение, таким образом, сервер имея private key может разобрать какое сообщение мы ему отправили.

Теперь про сертификат:
Если мы ставим подпись через Public Key, то сертификат, который мы передаем должен иметь Private Key?

Не понимаю, что это даст, если мы передаем сертификат в котором есть Private Key, который сервер и без нас знает, к тому же сертификат может быть взят от любого оригинального запроса, наверное я что-то не догоняю)))

[SagePtr]

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

[aopil]

SagePtr, Данные (пункта 1) шифруются через SHA1 и полученный хеш подписывается через Public Key.

Далее, отправляем запрос на сервер, который имея Private Key может расшифровать нашу подпись и сравнить хеш, тем самым удостовериться, что данные не изменены.

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

На каком этапе я путаю? Не могу понять как сертификат может гарантировать что данные небыли изменены.

[SagePtr]

aopil, по-моему, у вас какая-то путаница в голове. SHA1 это алгоритм хэширования, а не шифрования, зашифровать алгоритмом SHA1 ничего нельзя, т.к. операция необратима. Подпись "расшифровать" тоже невозможно, её можно только проверить.

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

[aopil]

SagePtr, если есть интерес, напишите мне на почту которая указана в профиле.
Технология выглядит "Супер защищённой" , но фактически, есть умельцы которые могут как-то обходить это всё.

[SagePtr]

aopil, если могут легко обойти - значит, реализация неправильная, и где-то допущены ошибки

[aopil]

SagePtr, вот как раз нужно помочь найти эти "ошибки", если разбираетесь в этом вопроса, и сможете помочь, то вознаграждение гарантируется :)

[SagePtr]

aopil, увы, я не криптоаналитик. Единственное, что могу посоветовать - это использовать готовые реализации вроде openssl вместо самостоятельного велосипедостроения.

Answer 2

[Developer]

Сертификаты несут дополнительную информацию о владельце, а также имеют срок действия