Чтобы кто-то не мог легко захватить мои данные, я кэширую данные с моей службы в виде зашифрованных файлов (в основном, защита от копирования).
Однако для этого я должен сохранить ключ шифрования в сборке .NET, чтобы он мог шифровать и расшифровывать эти файлы.
Зная о таких инструментах, как Red Gate.NET Reflector, которые могут вытащить мой ключ, я чувствую, что это не очень безопасный способ сделать это... есть ли какие-либо рекомендации для этого?
Вы должны решить, какой приемлемый уровень риска. Нет никакого "безопасного" способа сделать это.
Если риск того, что кто-то использует отражатель, или просто открывает сборку с использованием класса System.Reflection.Assembly и захватывает ресурс таким образом, слишком велик, то следующим шагом, вероятно, является загрузка ключа с сервера, когда вы начинаете.
Затем кому-то придется делать что-то вроде отладки при использовании вашего кода и захватить ключ таким образом. Вы можете истекли вещи, которые кэшируются и заменяют ключи. Вы можете сделать это так, чтобы каждый пользователь имел свои собственные ключи для защиты одного пользовательского данных от другого пользователя.
Вы можете делать много вещей, но если ваша цель - не дать кому-либо возможность расшифровать информацию, которую сборка, которую вы ставите на своей машине, имеет возможность расшифровать, вы должны знать, что это практически невозможно. Все, что вы действительно можете сделать, это повысить стоимость пиратства ваших ключей/данных; вы не можете остановить его.
Вы не можете предотвратить decription, но вы можете предотвратить повторное шифрование фальсифицированных данных:
Пока ваш код работает на компьютере, доступном другим, вы не можете препятствовать им изучать программу. Однако декомпиляция и анализ требуют времени. Как указывает MaxGuernseyIII, все зависит от приемлемых уровней угрозы.
В вашем случае проблема заключается не в том, что хакер может декомпилировать ваш код, но гораздо больше, чтобы они могли изменять данные, которые вы хотите защитить (кто владеет лицензией).
Таким образом, вы можете использовать метод метод шифрования с открытым ключом для шифрования данных. Таким образом, хакер может читать, но он не может повторно шифровать.
Как подсказывает Макс, вам нужно рассмотреть модель угрозы.
О каких злоумышленниках вы беспокоитесь? (Это законно беспокоиться о некоторых, и не настолько законно беспокоиться о других). Типичными категориями могут быть "не-компьютерный пользователь, который приобрел программу", "преданный человек, желающий потратить часы на решение", "случайный пользователь, который знает, как найти трещины в Интернете" и т.д.
В зависимости от вашего точного сценария решения могут быть разными.
Один интересный/грустный пункт, который следует отметить, заключается в том, что если ваш продукт популярен, тогда требуется только один или два посвященных человека, чтобы сесть и сломать его, а затем освободить патч для всех. Это, по-моему, природа программного обеспечения, и это нерешенная проблема, когда все ваше приложение работает на своей машине.
Очевидно, что подразумевается, что это не проблема, если ваше приложение работает как веб-сайт, то есть на компьютере вашего контроля.
Я знаю, что это не очень полезный ответ.