Обмен симметричными ключами

У меня есть клиент WinForms, который отправляет зашифрованные данные в веб-службу. Клиент WinForms создает симметричный сеансовый ключ RijndaelManaged, а также имеет «жестко закодированный асимметричный открытый ключ RSA».

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

Веб-служба имеет «жестко запрограммированные» закрытый и открытый ключи и может успешно расшифровать SessionKey, а затем использовать его для расшифровки фактических данных, которые я отправляю.

Это в значительной степени обрабатывается автоматически классом EncryptedData.

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

Прежде чем приступать к расшифровке на стороне веб-службы, я вижу зашифрованный сеансовый ключ, но после расшифровки XML он исчезает (поэтому у меня нет сеансовых ключей для ответа).

Любые идеи, как я могу получить этот незашифрованный ключ?


comment
Нам понадобится немного больше информации, чем «Оно пропало». Фрагменты кода? Также не рекомендуется жестко кодировать ключи RSA. Почему бы не прочитать сертификаты из хранилища ключей Windows и не использовать их для шифрования/дешифрования?   -  person Petey B    schedule 21.06.2011
comment
Это почти дословно код в MSDN: msdn.microsoft.com/en-us /library/ms229746.aspx В методе Decrypt() после вызова DecryptDocument я могу видеть свои данные, но как мне получить SessionKey (который использовался в методе Encrypt()), чтобы я мог ответить на Отправитель?   -  person Tim    schedule 21.06.2011
comment
Почему вы просто не используете SSL?   -  person CodesInChaos    schedule 22.06.2011


Ответы (1)


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

encryptedxml.decryptencryptedkey

И ты должен быть в порядке. Обратите внимание, что для всех менее важных предупреждений безопасности представленный здесь код уязвим как для атак «человек посередине», так и в меньшей степени для атак оракула заполнения. Это должно помочь против большинства попыток подслушивания.

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

person Maarten Bodewes    schedule 21.06.2011