Хранение ключей шифрования - лучшие практики?

Ответ 1

Один стандартный подход в мире webapp состоит в том, чтобы разделить ключ и поместить его в разные места. Например, вы можете разбить ключ и поместить его часть в файловую систему (вне каталога "webapps" ), часть его в конфигурации JNDI (или эквивалент .net) и ее часть в базе данных. Получение какой-либо отдельной части не особенно сложно, если вы подвергаетесь риску, например, изучая резервный носитель или SQL-инъекцию, но для получения всех частей потребуется намного больше работы.

Вы можете разбить ключ, используя XOR-ing со случайными номерами того же размера. (Используйте криптографически сильный генератор случайных чисел!) Вы можете повторить этот процесс несколько раз, если хотите разбить ключ на несколько частей. В конце процесса вы хотите, например, три частичных ключа, таких как p1 ^ p2 ^ p3 = key. Возможно, вам понадобится base64-кодировать некоторые частичные ключи, чтобы они могли быть сохранены правильно, например, в свойстве JNDI.

(Есть более сложные способы разделить ключ, например, алгоритм n-of-m, где вам не нужны все части для воссоздания ключа, но это -far- сверх того, что вам нужно здесь.)

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

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

Ответ 2

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

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

Эти подходы являются платформо-агностическими. Для более конкретных предложений информация о вашей платформе была бы полезной.

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

Ответ 3

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

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

Ответ 4

вставьте его в web.config и зашифруйте этот раздел

Этот вопрос SO обсуждает больше о шифровании web.config

Ответ 5

Это должно помочь...

http://msdn.microsoft.com/en-us/library/ms998280.aspx

Но вы действительно должны подумать о переходе на PKI, если серьезно относитесь к защите своих данных.