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

Question

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

Однако для этого я должен сохранить ключ шифрования в сборке .NET, чтобы он мог шифровать и расшифровывать эти файлы.

Зная о таких инструментах, как Reflector от Red Gate, который может вытащить мой ключ, у меня возникает ощущение, что это не очень безопасный способ сделать это ... есть ли какие-либо рекомендации для этого?

Answer 1

Вы должны решить, какой приемлемый уровень риска. Не существует «безопасного» способа сделать это.

Если риск того, что кто-то использует отражатель или просто открывает сборку с использованием класса System.Reflection.Assembly и захватывает ресурс таким образом, слишком велик, то следующим шагом, вероятно, является загрузка ключа с сервера когда вы запускаете.

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

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

Answer 2

Вы не можете предотвратить Decription, но вы можете предотвратить повторное шифрование фальсифицированных данных:

Пока ваш код работает на компьютере, доступном для других, не существует никакого способа, вы можете предотвратить их изучения программы. Однако декомпиляция и анализ требуют времени. Как указывает MaxGuernseyIII, речь идет о приемлемых уровнях угрозы.

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

Для шифрования данных вы можете использовать метод public key cryptography. Таким образом, хакер может читать, но он не может повторно шифровать.

Answer 3

Как подсказывает Макс, вам необходимо рассмотреть модель угрозы.

О каких злоумышленниках вы беспокоитесь? (Правомерно беспокоиться о некоторых, и не настолько законно беспокоиться о других). Типичными категориями могут быть «некоммерческий опытный пользователь, который приобрел программу», «преданный человек, желающий потратить часы на решение», «случайный пользователь, который знает, как найти трещины в Интернете» и т. Д.

В зависимости от вашего точного сценария , решения могут быть разными.

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

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

Я знаю, что это не очень полезный ответ.