Как правильно использовать Crypto Api для шифрования и дешифрования между клиентом и сервером?

Question

После многих головных болей и людей, советовавших прекратить, мне наконец удалось заставить мое Серверное / Клиентское приложение работать с этим API и создать необходимые ключи, то есть Сеанс и Exchange.

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

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

Или

Должен ли я на самом деле шифровать сеансовый ключ клиента с помощью открытого ключа сервера, а затем возвращать его? (Мне это не кажется правильным, но я весь в ушах !!!)

Пожалуйста, оставьте комментарии, чтобы перейти к другому API или скопировать информацию из MSDN (я уже все это читал). Я работаю с Crypto API, и мне просто нужно четкое объяснение того, какие ключи сервер должен передать клиенту, а затем, что клиент должен сделать и передать обратно, чтобы я наконец смог перейти ...

Answer 1

Похоже, что вы на правильном пути, если вы действительно намерены придерживаться этого API:)

В криптографии есть два разных семейства алгоритмов шифрования. 1) те, которые используют симметричные ключи и 2) те, которые используют асимметричные ключи. Алгоритмы с симметричным ключом (например, AES, DES ...) очень быстрые и должны использоваться, если есть безопасный способ убедиться, что и клиент, и сервер имеют одинаковый ключ (т. Е. Ключ сеанса), и никто другой не может получить доступ к этот ключ. С другой стороны, алгоритмы асимметричного ключа (например, RSA ...), которые также являются известными алгоритмами частного / открытого ключа, намного дороже в вычислительном отношении. У них есть один ключ, который можно использовать только для шифрования данных, и второй ключ, который можно использовать только для дешифрования данных. Эти алгоритмы, как вы узнали, идеально подходят для первоначального рукопожатия и обмена ключами сеанса. Сервер создает пару открытый / закрытый ключ и отправляет клиенту открытый ключ. Любой может перехватить его, но когда клиент кодирует ключ сеанса и отправляет его обратно, ключ pbulic бесполезен, если перехватчик хочет узнать ключ сеанса. Только сервер может декодировать сообщение, так как это единственный объект, который держит закрытый ключ. Итак, ваша первоначальная проблема заключалась в том, что когда сообщение возвращалось, вместо использования закрытого ключа из пары, вы использовали синхронный ключ сеанса и, таким образом, получали мусор.

По сути, вы только что реализовали базовое рукопожатие, которое делает SSL (и вы можете легко сделать это с очень небольшим количеством строк кода, если используете библиотеку OpenSSL).

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

Это то место, где SSL использует сертификаты. Сертификаты являются еще одним примером использования открытых / закрытых ключей. Доверенный орган использует закрытый ключ для подписи хеш-кода сертификатов, и любой может проверить действительность сертификата, используя свой открытый ключ присоединения к данным идентификации сертификатов. Таким образом, даже если злоумышленник захватит IP-адрес вашего сервера, он не сможет подделать сертификат вашего сервера.