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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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