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

Question

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

Сервер имеет key1 (Private) с самого начала, и клиент имеет key1 (публичное)

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

---

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

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

Answer 4

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

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

- MarkusQ

Answer 5

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

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

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