Как правильно и безопасно установить шифрование?

 
 
 
Сообщения:113
Никак не могу понять, как правильно происходит установка шифрованного канала связи между двумя узлами по не безопасному каналу(Сеть) без привлечения третьих лиц(Удостоверяющие Центры).

Например если использовать протокол обмена ключами ECDH.

Алиса и Боб генерирую пары ключей и меняются публичными ключами. Генерируют на основе своего приватного и полученных друг от друга публичного ключей общий AES секрет.
То что мешает Еве перехватить ихние публичные ключи и передать уже свои ключи им?
 
 
Сообщения:9995
Ничего не мешает :) Diffie-Hellman (DH) позволяет обменяться симметричным ключом не передавая его по открытому каналу - это единственная задача которую он решает. А правильному ли лицу мы передаем этот ключ.. это вопрос доверия:
- то ли доверяя третим лицам - как в случае HTTPS и Certification Authorities (CA)
- то ли непосредственно кому передаем данные - как с TOFU (trust on first use) в случае SSH
- то ли другими хитрыми средствами типа web of trust - как в GPG

Эти протоколы подразумевают что у отправителя есть приватный ключ (RSA, DSA, ECDSA), и этим ключом он подписывает данные. Это гарантирует что DH данные пришли не от Евы. Ну, конечно если ключ которому мы доверились не раздобыла Ева.
Изменен:22 июл 2020 20:42
 
 
Сообщения:113
Хорошо, если я не могу уверенно без задействования третьих лиц установить шифрованный канал связи, то с точки безопасности будет ли приемлема такая схема?

Например у меня есть сервер и программа клиента для подключения к этому серверу. На этапе сборки приложений Я заранее генерирую n количество асинхронных пар ключей. Закрытые ключи остаются в серверном приложении, а все публичные в клиенте. Клиент при подключении к серверу выбирает любой ключ шифрует им Синхронный секрет и отправляет серверу с указанием id ключа шифрования, сервер же заканчивает рукопожатие тем что отправляет подписанный Приватным ключом и зашифрованный этим Синхронным секретом ответ. Клиент соответственно проверяет подпись и тоже устанавливает этот алгоритм если подпись валидна.
Изменен:23 июл 2020 06:30
 
 
Сообщения:9995
Смотря насколько безопасно все должно быть. Чем больше мер предпринимается, тем сложней сломать. Соотвественно если твоя схема будет подвержена одной уязвимости, а не двум - уже лучше, но допустимо ли - это я не могу сказать за тебя :)

Dilettante:
На этапе сборки приложений Я заранее генерирую n количество асинхронных пар ключей.
Делать это на этапе сборки - странно. Такие вещи нужно уметь конфигурить и на клиенте, и на сервере. Что если нужно их поменять? Только ради этого пересобирать/редеплоить сервер и всех клиентов?

Также не понятно зачем n ключей, нужен всего один - серверный. И все клиенты должны ему доверять. Или сервер тоже должен доверять (идентифицировать) клиентов? Тогда у него должен быть список их публичных ключей. Как к примеру в случае с github'ом.
Dilettante:
Клиент при подключении к серверу выбирает любой ключ шифрует им Синхронный секрет
Если клиент шифрует симметричный ключ, то почему эта тема началась с DH? :)
Dilettante:
сервер же заканчивает рукопожатие тем что отправляет подписанный Приватным ключом и зашифрованный этим Синхронным секретом ответ. Клиент соответственно проверяет подпись и тоже устанавливает этот алгоритм если подпись валидна.
Звучит правдоподобно. Но я не эксперт, лучше спрашивать на сайтах типа Security SE и Crypto SE.

Складывается впечатление что ты хочешь изобрести какой-то свой протокол. В Security - это верный путь к неудаче. Это сложно и очень много нужно знать, поэтому лучше использовать какой-то из существующих протоколов, тот же HTTPS.
Изменен:23 июл 2020 07:01
 
 
Сообщения:113
Староверъ:
Делать это на этапе сборки - странно.

Это я образно, не в этом суть, это всегда можно сконфигурировать по разному.

Староверъ:
Также не понятно зачем n ключей

Мне кажется большой случайный первоначальный выбор безопасней одного единственного.

Староверъ:
Или сервер тоже должен доверять (идентифицировать) клиентов? Тогда у него должен быть список их публичных ключей.

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

Староверъ:
Если клиент шифрует симметричный ключ, то почему эта тема началась с DH? :)

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

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

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

Суть то вопроса для меня все равно непонятна, можно ли без посредников исключить атаку MITM при установке шифрования только между двумя компьютерами.
Изменен:23 июл 2020 07:30
 
 
Сообщения:9995
Dilettante:
Суть то вопроса для меня все равно непонятна, можно ли без посредников исключить атаку MITM при установке шифрования только между двумя компьютерами.
Только если клиент доверяет ключу сервера. Твой "образный" вариант со сборками - работоспособный, хоть может и не удобный. Всегда же можно купить сертификат у CA и использовать обычный HTTPS, ничего самому реализовывать не прийдется.
 
 
Сообщения:113
Все понятно, остановлюсь на своём варианте. Минус только в том, если использовать его для какого нибудь мессенджера, то клиент имеет все основания не доверять серверу, в том что он не будет читать переписку.

Спасибо.
Изменен:23 июл 2020 10:28
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет