Silverlight и Encryption, как хранить / генерировать им ключ / iv пару?

Question

У меня есть приложение Silverlight, которое подключается к веб-сервису php.Я хочу зашифровать связь между веб-сервисом и клиентом Silverlight.Я не полагаюсь на SSL.Я сам шифрую / дешифрую строку POST, используя 256-битный ключ AES и IV.

Тогда возникают большие вопросы:

1. Как мне создать случайную уникальную пару ключ / iv в PHP.

2. Как мне безопасно и безопасно разделить эту пару ключ / iv между веб-сервисом и клиентом Silverlight.

Кажется невозможным без какого-либо жестко закодированного ключаили iv на клиенте.Что может поставить под угрозу безопасность.

Это общедоступный веб-сайт, здесь нет логинов.Просто требование безопасной связи.

Я могу жестко запрограммировать начальное значение для ключа / iv (который хэшируется с помощью SHA256 с солью метки времени, а затем назначается в качестве ключа или iv) в исходном коде PHP, этона сервере, так что это довольно безопасно.Однако на клиенте семя для пары ключ / iv будет видно, если оно жестко закодировано.

Более того, использование отметки времени в качестве основы для уникальности / случайности определенно не подходит, поскольку отметки времени предсказуемы.Однако он обеспечивает общий фактор между кодом C # и кодом PHP.

Единственный другой вариант, о котором я могу подумать, это задействовать третью службу, предоставляющую ключ / iv клиенту Silverlight,а также веб-сервис php.Это, конечно, начинает цикл заново, с вопроса о том, как сохранить учетные данные для доступа к службе распространения ключа / iv на клиенте Silverlight.

Похоже, что решение - это асимметричное шифрование, поскольку конфиденциальные данные будутпросматривается только на административной части сайта.К сожалению, Silverlight не имеет классов асимметричного шифрования.Решение?Сверните мой собственный обмен ключами Диффи-Хеллмана!Вставьте этот ключ в AES256!

Answer 1

Ответы на ваши вопросы: «SSL».

Симметричное шифрование расширяет общий секрет относительно небольшого размера (например, 256-битный ключ) в безопасный туннель передачи данных, который обеспечивает конфиденциальность и целостность. Это не так просто, как может показаться; Есть много мелких, но смертельных деталей.

Асимметричная криптография - это установление этого общего секрета по небезопасной сети. RSA-шифрование, Диффи-Хеллман ... это алгоритмы, которые могут вам в этом помочь. Вы все еще должны начать где-нибудь; то есть, если вы используете открытый ключ сервера (его открытый ключ RSA, его половина Diffie-Hellman ...), то у вас должен быть какой-то способ узнать, что вы используете право открытый ключ, а не открытый ключ какого-то плохого парня, который перехватывает сообщение и вместо этого передает вам свой собственный ключ. Есть способы сделать это, главным образом с помощью жесткого кодирования открытого ключа в клиентском приложении, открытого ключа, который является либо открытым ключом сервера, либо ключом, который можно использовать для его подписи (это сертификация). Конечно, с помощью Silverlight клиентский код также загружается, поэтому потенциально может быть изменен тем же плохим парнем, поэтому вам придется подписать код и браузер проверит эту подпись.

Все это тяжелая работа и имеет множество подводных камней. Протокол SSL прошел через все из них и был терпеливо, но мучительно обновлен и исправлен. Это заняло много лет и много умных людей, и было много зубов. Аналогичный протокол - SSH (некоторые детали кодирования отличаются, но принципы те же). Если вы хотите разработать свой собственный протокол, скорее всего, вы воспроизведете большинство слабых сторон и проблем, которые преследуют SSL и SSH. Простое использование SSL или SSH сэкономит вам много времени и усилий.

Answer 2

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

Что возвращает нас к вопросу: почему вы не используете SSL?