Безопасен ли этот сценарий?

Question

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

Сервер имеет ключ1 (закрытый) с самого начала, а клиент имеет ключ1 (открытый)

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

- MarkusQ

Answer 4

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

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

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

<Ч>

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

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

Answer 5

Я соглашусь с Грегом в том , что вы изобретаете велосипед заново.То, что вы, по сути, описываете, является некоторой базовой формой обмен ключами.Кстати, чтобы гарантировать, что он защищен от атак типа "человек посередине", вы также должны быть уверены в подлинности сервера, т.е.убедитесь, что клиент может с уверенностью знать, что то, что он считает открытым (ключ1), на самом деле принадлежит серверу, а не человеку посередине (напримериспользование центра сертификации или наличие открытого ключа сервера (key1) в защищенном хранилище на стороне клиента.)

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

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