Этот сценарий безопасен?

Question

Я использую RSA для шифрования связи между сервером и клиентом. Допустим, у нас есть 2 асимметричных ключа, ключ 1 и ключ 2.

Сервер имеет ключ1 (частный) с самого начала, а клиент имеет ключ1 (общедоступный)

Итак, вот сценарий:

1. клиент генерирует ключ2
2. клиент подключается к серверу
3. отправка ключа 2 (общедоступного) в зашифрованном виде с помощью ключа 1 (общедоступного)
4. С этого момента сервер будет отправлять все данные, зашифрованные с помощью ключа 2 (общедоступный)
5. клиент отправляет некоторые случайные данные на сервер
6. сервер отправляет обратно те же хэшированные данные
7. клиент проверяет правильность данных

Насколько я понимаю, это должно предотвратить атаку "человек посередине", или я что-то упустил? В точке 7 клиент должен знать, пытается ли кто-то дать серверу неправильный ключ для шифрования, поскольку никто другой, кроме сервера, не может расшифровать ключ 2 (открытый).

Если есть что-то, что можно сделать для повышения безопасности, скажите мне.

Answer 1

Лучшее, что вы можете сделать для повышения безопасности, - это использовать существующий дизайн, а не пытаться изобретать велосипед. Я не говорю, что то, что вы сделали, обязательно неправильно, но просто то, что многие люди намного умнее нас с вами, потратили много времени на размышления над этой проблемой. Вместо этого используйте TLS.

Answer 2

Согласен, просто используйте TLS.

Кроме того, какое значение обеспечивают шаги с 5 по 7? MITM, желающий провести атаку, которая будет работать после шагов 1-4 (например, DoS некоторого рода, пропуская n транзакций и затем останавливаясь, вызывая повторную попытку с самого начала), мог бы делать это также хорошо после 5-7. Что они добавляют?

- MarkusQ

Answer 3

Нет, этот протокол небезопасен.

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

Конечно, вы могли бы вылечить свой протокол, чтобы исправить эти явные проблемы, но были бы другие. Если вы когда-нибудь исправите их все, у вас будет что-то, сопоставленное с TLS или SSH, так почему бы просто не начать там?

---

@ Petoj & ndash; проблема, на которой я сосредоточился, заключалась в том, что сервер доверял полученным сообщениям; ваше предложение не обеспечивает никакой безопасности там. Однако, если вы беспокоитесь о конфиденциальности, у вас все еще есть проблема, потому что MITM может передавать сообщения назад и вперед без изменений, пока он не увидит, что хочет найти, потому что у вас нет конфиденциальности в клиентских сообщениях.

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

Answer 4

Пока ключ1 (частный) не был каким-либо образом перехвачен третьей стороной, ваш сценарий выглядит безопасным.

Кажется, я видел это где-то в газете. В нем Алиса дала Бобу разблокированный ящик (ключ 1 публичный), затем Боб положил в него набор своих собственных ящиков (ключ 2 публичный), запер его и отправил обратно Алисе. Затем Алиса открывает коробку (ключ 1 закрытый), и теперь она может надежно запечатать коробки, которые ей только что дал Боб.

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

Answer 5

Я согласен с Грегом, что вы заново изобретаете колесо . По сути, вы описываете некоторую базовую форму обмена ключами . Между прочим, для того, чтобы обеспечить его защиту от атак «человек посередине», вы также должны быть уверены в идентичности сервера, то есть убедитесь, что клиент может с уверенностью знать, что то, что он считает публичным (key1), действительно является сервер, а не человек-посредник (например, с помощью ЦС или с открытым сервером (key1) в безопасном хранилище на стороне клиента.)

Кроме того, есть дополнительные соображения , которые вы должны знать с системной точки зрения, такие как:

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