Хранение ключей шифрования - лучшие практики? - PullRequest
59 голосов
/ 07 апреля 2009

У меня есть веб-приложение, которое использует алгоритм симметричного шифрования.

Как бы вы сохранили секретный ключ и вектор инициализации? Хранение как литерала в коде кажется плохой идеей. Как насчет настроек приложения? Какова лучшая практика здесь?

Ответы [ 5 ]

53 голосов
/ 07 апреля 2009

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

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

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

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

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

11 голосов
/ 07 апреля 2009

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

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

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

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

6 голосов
/ 07 апреля 2009

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

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

4 голосов
/ 07 апреля 2009

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

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

2 голосов
/ 07 апреля 2009

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

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

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

...