Как безопасно хранить ключ шифрования в .Net?

Question

Если у вас есть приложение .Net (или любое другое приложение в этом отношении), как безопасно хранить внутренние ключи шифрования?Я не говорю о ключах, введенных пользователем, а о клавишах, которые жестко запрограммированы в самой программе, для связи между другими экземплярами программы.Например, если у вас есть программа типа peer-to-peer, вы можете зашифровать пакеты, чтобы быть уверенным, что вы общаетесь с другим экземпляром вашей программы, а не с кем-то еще.Мое решение состоит в том, чтобы жестко закодировать ключ в клиентах и ​​просто зашифровать / расшифровать все таким образом.

Однако мне интересно, безопасно ли это делать в .Net.Я не много работал с Reflector или чем-то в этом роде, но, насколько я слышал, довольно легко деконструировать .Net-приложения из CIL.Будет ли поиск и поиск моего магического номера тривиальным для кого-то с одним из этих приложений?

Answer 1

Нет абсолютно никакого способа проверить, что исполняемый файл на другом конце соединения является тем, который вы написали.Если вы шифруете ключ ключом, где вы храните второй ключ?Если вы, Диффи-Хеллман, получили от сервера секретный ключ, где вы храните этот ключ?(подсказка: в памяти, откуда его можно сбросить, затем прочитать).Это рекурсивная проблема, которую вы никогда не сможете решить.

Я читал, что серверы AOL Instant Messenger периодически запрашивают у клиента AIM хэш определенных адресов кода (т. Е. Вычисляют SHA1 (address1 -> address2))и затем отключите клиент, если хэш был неправильным.Это произошло потому, что незаконно перераспределять исполняемый файл (и невозможно создать таблицу хэша между каждыми двумя интервалами), так что это всего лишь юридическая, а не техническая задача.

Если вам нужно программное обеспечение, котороедействительно изо всех сил пытается победить реверс-инжиниринг (и на самом деле делает хорошую работу), попробуйте подключить отладчик к Skype: -)

Answer 2

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

Answer 3

Если ключ хранится в исполняемом коде вашей программы или в ресурсе (или в TCB Windows, использующем ключ в исполняемом коде), кто-то может с достаточными усилиями декодировать его.

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

Для начала:

• Не создавайте свои собственные механизмы, слишком много простых способов поставить под угрозу безопасность (экспертам часто требуется несколько попыток, чтобы сделать это правильно).
• Подумайте о ценности того, что вы пытаетесь защитить, и о ресурсах, доступных тем, кто может на него напасть. Если мало что защищать, вам не нужно так много защиты.
• Если вы не защищаете где-то вроде Олдермастон , вам не нужно Высокий Безопасность .

Принцип KISS послужит вам хорошо.

Answer 4

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

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

Если вам действительно нужно хранить секретные данные, вы можете использовать класс ProtectedData .Вы можете вызвать его во время настройки, чтобы сохранить свой секрет (ключ).