Вопрос про безопасность с примером. как работает RSA при работе с сертификатами и зашифрованными сессиями?

Question

[huang05]

у меня вопрос по поводу RSA, тема касается как и Сертификатов (ЭЦП) так и обычной защищённой коммуникации.

ЭЦП/Сертификат/Подпись и тд. могут ли использоваться для создания защищённых сессий? Просто если так, то что тогда, если допустим я обменялся с другим человеком открытым ключом сертификата RSA, т.е. он имеет возможность расшифровать подписанный мной документ и проверить хэш, и с помощью этих же ключей RSA я установил с ним защищённую сессию, т.е. скинул ему ключ для зашифовки, то получается у него два два моих ключа и сертификат в придачу?

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

Comments

[mayton2019]

Ты описал очень правильный сценарий. Когда ты лично встретился с человеком. Собственно это и есть главная
проблема современной криптографии. Невозможность личной встречи всех со всеми. Вот отсюда и возникли различные хитрые способы как бы так сделать чтоб Алиса и Боб удостоверились что они те за кого себя выдают.

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

Попробуй вместо ответа - скачай утилиту OpenSSL и с помощью нее понаблюдай как происходит процесс
установления секретного соедниения для https. Там в логах много интересного будет.

[huang05]

mayton2019, спасибо

Попробуй вместо ответа - скачай утилиту OpenSSL и с помощью нее понаблюдай как происходит процесс
установления секретного соедниения для https. Там в логах много интересного будет.

будет ссылка на статью или на что нибудь где объясняется как это сделать?

[mayton2019]

huang05, ну вот тут например https://stackoverflow.com/questions/17742003/how-t...

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента. Также обратите внимание на п.2.2

Answer 1

[Saboteur]

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

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

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

Если у кого-то оба ключа, и этот кто-то не ты, это значит что твои ключи скомпроментированы.

По поводу сертификата.
Для установки шифрованного соединения используется тот же самый ассиметричный алгоритм шифрования с приватным и публичным ключом. Просто в сертификате есть публичный ключ.
Разница в том, что в сертификате есть и другие поля, например центр который выдал сертификат, сроки годности сертификата, может быть доменное имя и другие поля.
Перед установкой https сессии, твой браузер может провалидировать сертификат сервера на соответствие доменному имени, на то, что браузер доверяет этому сертификату (или центру который его выдал), что сертификат не просрочен. А для установкий самой https сессии уже используется публичный ключ из сертификата.
Для каждой https сессии создается свой уникальный секрет, который шифруется публичным ключом и передается на сервер.

Comments

[huang05]

Нет, он не имеет возможность расшифровать. Он может только провалидировать, что документ был подписан тобой.

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

Просто вопрос, зачем тогда нужен закрытый ключ в вашем примере, если допустим подписанные мной документы (открытым ключём) я высылаю всегда другим людям и они проверяют его тем самымоткрытым ключём

Нет, он не имеет возможность расшифровать. Он может только провалидировать, что документ был подписан тобой..

И то есть по сути они имеют возможность подписывать документа от моего имени имея такую возможность и сам сертификат?

На всякий случай скажу что сверху я имел ввиду ЭЦП.

[Василий Банников]

асинхронный

Ассиметричный*
(душнила off)

[Василий Банников]

huang05,

Просто вопрос, зачем тогда нужен закрытый ключ в вашем примере, если допустим подписанные мной документы я высылаю всегда другим людям и они проверяют его открытым ключём

Закрытый ключ нужен тебе для подписывания документа.
ЭЦП работает так:

1. Вычисляем хэш-сумму документа

2. Шифруем её при помощи закрытого ключа - это и будет подпись.

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

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

В случае HTTPS используется немного другая схема - там ассиметричное шифрование используется только для обмена частями сеансового ключа между клиентом и сервером по протоколу Диффи-Хеллмана.

[huang05]

Василий Банников,

Закрытый ключ нужен тебе для подписывания документа.

1. Вычисляем хэш-сумму документа
2. Шифруем её при помощи открытого ключа - это и будет подпись.

А где конкретно в вашем примере используется закрытый ключ для шифрования и подписи? Я правильно понимаю что я подписал документ открытым ключом(а не закрытым) и отправил этот самый открытый ключ другому человеку и т.е. он может подписывать документы от меня? И зачем мне вообще этот закрытый ключ?

[huang05]

huang05, ах, поправили, извиняюсь)

[huang05]

Василий Банников,
Вот мы и пришли к тому что ключ расшифровки снова попадает другому человеку.
У меня вопрос, а если у меня с ним так же настроено шифрованное соединение по RSA с тем же сертификатом? Я же ему ещё и ключ для зашифровки скидывал
Как пример для легкого восприятия скину картинку с пеинта

Получается у него два моих ключа?

[Василий Банников]

huang05, опечатался. Для подписи действительно используется закрытый ключ)

[Василий Банников]

huang05,

Вот мы и пришли к тому что ключ расшифровки снова попадает другому человеку.

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

Как пример для легкого восприятия скину картинку с пеинта

Из твоей схемы вообще ничего не понятно) Какие-то кругляши и стрелочки.

[Василий Банников]

huang05, Давай остановимся на конкретных схемах:

При подписании документа у нас есть такие действующие лица:
1. Отправитель документа, который хочет отправить документ получателю
2. Получатель документа, который хочет получить документ и убедиться, что его никто не изменил во время доставки, и что его отправил действительно отправитель.
3. Удостоверяющий центр, которому доверяют отправитель и получатель.

При подписании документа по сути есть три больших шага:
1. Выпуск приватного и публичного сертификата.
2. Подписание документа.
3. Проверка подлинности документа.

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

При подписании документа отправитель берёт такую пару ключей и алгоритм, при которых шифрование происходит с закрытым ключом, а расшифровка - с открытым (RSA)

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

Получатель затем расшифровывает хэш и проверяет его с вычисленным самостоятельно.

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

А для получения сессионного ключа используется DH

https://tls.dxdt.ru/tls.html

[Valentin Barbolin]

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

Островные тезисы
Сертификат один
У сертификата два ключа, приватный и публичный, эта пара ключей уникальна, и только они могут работать вместе.
Публичный для шифрования и ВАЛИДАЦИИ подписи (все называют расшифровкой, это не расшифровка, а валидация). Публичный ключ можно раздавать всем.
Приватный для расшифровки и подписи (подпись с точки зрения алгоритма это шифрование, но никто не будет ее расшифровывать, ее будут валидировать)

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

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

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

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

Если взять всем известный vpn от WireGuard, то там тоже у каждого есть пара ключей, но сертификат не нужен т.к. все участники vpn сессии заранее знают кому принадлежат ключ и валидация не требуется.

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

[Saboteur]

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

[Valentin Barbolin]

Saboteur,

а публичный ключ который можно приложить к этому письму не считается безопасным способом,

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

Нет необходимости скрывать публичный ключ, т.к. есть механизм его проверки.

[Saboteur]

Valentin Barbolin,
Если к тебе приходит подписанное письмо, как ты убедишься, что оно подписано автором?
Приложенным к письму сертификатом?

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

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

[Valentin Barbolin]

Saboteur,

Если к тебе приходит подписанное письмо, как ты убедишься, что оно подписано автором?
Приложенным к письму сертификатом?

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

Ты выполняешь цепочку проверок в результате которой ты можешь сказать что сертификат и публичный ключ валидны.

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

[Saboteur]

Valentin Barbolin, В случае того же gmail, либо никто не может себе сделать сертификат на gmail.com, либо любой может сделать себе сертификат на UserName, и визуально не поймешь, что адрес не тот.

[Valentin Barbolin]

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

В первом случае ты не можешь подтвердить валидность сертификата, можешь только поверить на слово.

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

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

И тут начивает работать цепочка. Руты - сертификат - подпись.
Центр сертификации позволяет проверить предоставленный тебе сертификат с помощью рутов, подпись и публиный ключ позволяют проверить что данные в сертификате целостные и не были изменены, а значит публичный ключ тоже валидный.

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

[Saboteur]

Valentin Barbolin,
Как происходит валидация домена - это понятно.
Как происходит валидация владельца почтового ящика?

Вот есть у меня [e-mail], я себе заказал/купил официальный сертификат в каком-нить amazon или digicert

Злоумышленник сделал себе [e-mail], и тоже в дигисерте заказал сертификат.

Получается что если не заметишь глазами, то не поймешь. А еще могут from подделать.

[Valentin Barbolin]

Saboteur,

Как происходит валидация владельца почтового ящика?

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

Получается что если не заметишь глазами, то не поймешь.

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

А еще могут from подделать.

Для защиты от такого есть DKIM.
DKIM (DomainKeys Identified Mail): Настройте DKIM для вашего домена. DKIM добавляет цифровую подпись к письму, позволяя получающему серверу проверить подлинность отправителя.

Конечно, если принимающая сторона не выполняет банальных проверок SPF, DKIM, PTR DNS то и безопасности говорить не стоит, сертификат будет как пластырь на пулевое ранение.

Answer 2

[CityCat4]

ЭЦП/Сертификат/Подпись и тд. могут ли использоваться для создания защищённых сессий? Просто если так, то что тогда, если допустим я обменялся с другим человеком открытым ключом сертификата RSA, т.е. он имеет возможность расшифровать подписанный мной документ и проверить хэш,

Разумеется. Это все стопицто раз описано в тырнете.

Есть Алиса и есть Боб. Предположим, у каждого сертификаты для подписи почты (это важно - у сертификата есть поле применяемости - если там не стоит что он для почты - хрен чего сделаешь), выпущенные ... ну допустим GlobalSign CA.

У Алисы есть свой сертификат (открытый ключ) и ключ (закрытый ключ). Сертификат свой Алиса может хоть на заборе писать, ключ же должна хранить пуще девственности.
У Боба тоже есть свой сертификат и свой ключ. И он его тоже должен беречь пуще ящика пива.

Алиса пишет письмо Бобу.

Сначала она набирает текст "Dear Bob, I'm very pleasant be fucked by you yesterday. I'd like to repeat ASAP"

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

Боб получает письмо и проверяет подпись открытым ключом Алисы. Если подпись проверена правильно, то это доказывает, что письмо на самом деле от Алисы, а не от Мэри, которая давно мечтает отдаться Бобу.
После проверки подписи Боб расшифровывает его своим закрытым ключом и читает.

Все. Шифрование и подпись документа, допустим делается так же, только сертификат ессно должен иметь применимость "шифрование документов".

Answer 3

[Valentin Barbolin]

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

Островные тезисы
Сертификат один
У сертификата два ключа, приватный и публичный, эта пара ключей уникальна, и только они могут работать вместе.
Публичный для шифрования и ВАЛИДАЦИИ подписи (все называют расшифровкой, это не расшифровка, а валидация). Публичный ключ можно раздавать всем.
Приватный для расшифровки и подписи (подпись с точки зрения алгоритма это шифрование, но никто не будет ее расшифровывать, ее будут валидировать)

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

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

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

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

Если взять всем известный vpn от WireGuard, то там тоже у каждого есть пара ключей, но сертификат не нужен т.к. все участники vpn сессии заранее знают кому принадлежат ключ и валидация не требуется.

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