Зашифрованное соединение без SSLStream?

Question

Мне нужно зашифровать данные, которые будут отправлены / получены, клиентским <> сервером и наоборот.

Поскольку я не могу использовать SSLStream прямо сейчас, я ищу другие альтернативы.

Размышляя над имеющимися у меня альтернативами, я застрял на том, как отправить данные клиенту так, чтобы их нельзя было прочитать / перехватить.

Вот как я думал об этом:

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

• После первоначального запроса на подключение сервер отправит идентификатор сеанса вместе с внутренним ключом AES / iv.

• С этого момента клиент будет общаться, используя как RSA, так и AES.

Я хотел бы услышать от опытных людей некоторые новые идеи или лучшие способы сделать то, что мне нужно здесь, а именно:

Отправка зашифрованных данных с клиента на сервер и наоборот без использования SSLStream и при этом с хорошим уровнем безопасности.

Я понимаю, что закрытый ключ на клиенте - это риск, но я пока не нашел лучшего решения.

Answer 1

Если вы действительно не можете использовать SSL, вы можете создать SSL для бедняка самостоятельно:

Клиент знает открытый ключ RSA, сервер знает соответствующий закрытый ключ.

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

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

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

Вам также следует использовать разные одноразовые номера / IV для потока server-> client и client-> server. Вы также можете добавить проверку целостности (MAC).

Answer 2

Возможный подход:

-Сервер имеет общеизвестный открытый ключ и закрытый ключ, о котором никто не знает (даже клиенты)

-Клиент генерирует пакет «рукопожатия» и шифрует его с помощью открытого ключа сервера. Пакет рукопожатия содержит все необходимое для инициализации / аутентификации, а также случайно сгенерированную фразу-пароль + IV для использования для шифрования AES.

-Сервер расшифровывает пакет рукопожатия, используя свой закрытый ключ, и теперь имеет доступ к парольной фразе AES + IV. Он отвечает пакетом ACK, указывающим на его готовность.

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

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

Answer 3

Единственный способ сделать это - использовать общий секрет : то, что знает и клиент, и сервер, но никто другой не знает.

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

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

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