Шифрование AES и хранение ключей?
Несколько лет назад, сначала будучи представленным ASP.net и Платформе.NET, я создал очень простую систему хранилища файлов онлайн. Эта система использовала шифрование Rijndael для того, чтобы хранить файлы, зашифрованные на жестком диске сервера и HttpHandler, чтобы дешифровать и отправить те файлы клиенту.
Будучи одним из моего первого проекта с ASP.net и базами данных, не понимая очень о том, как все это работает (а также падающий на то же прерывание, описанное Jeff Atwood на этом предмете), я решил сохранить недавно сгенерированные ключи и IVS вместе с каждой записью файла в базе данных.
Для создания вещей немного более ясными шифрование было только для защиты файлов с прямого доступа на сервер, и ключи не были сгенерированы вводимыми пользователями паролями.
Мой вопрос, предполагая, что я не хочу сохранять один ключ для всех файлов, как я должен сохранить ключи шифрования для лучшей безопасности? Что считают лучшей практикой? (т.е.: На другом сервере, на файле простого текста, зашифрованном).
Кроме того, для чего используется вектор инициализации в этом типе алгоритма шифрования? Это должно быть постоянно в системе?
2 ответа
Ключи должны быть защищены и храниться в секрете, вот так просто. Реализация не является таковой. Системы управления ключами продаются за большие деньги доверенными вендорами, так как решение проблемы трудно .
Вы, конечно, не хотите использовать один и тот же ключ для каждого пользователя, чем больше используется ключ, тем "легче" его сломать, или, по крайней мере, получить утечку информации. AES является блочным шифром, он разделяет данные на блоки и передает результаты последнего шифрования блока в следующий блок. Вектор инициализации - это исходная подача в алгоритм, потому что в начальной точке начинать не с чего. Использование случайных IV с одним и тем же ключом снижает риск утечки информации - она должна быть разной для каждого зашифрованного блока данных.
Как вы храните ключи, зависит от того, как архитектурно оформлена ваша система. Я только что закончил KMS, где ключи хранятся подальше от основной системы, а функции шифрования и расшифровки открываются через WCF. Вы посылаете простой текст и получаете ссылку на ключ и зашифрованный текст назад - таким образом KMS ответственна за всю криптографию в системе. В вашем случае это может быть излишеством. Если пользователь вводит пароль в вашу систему, то вы можете использовать его для генерации пары ключей. Эта пара ключей может быть использована для шифрования хранилища ключей для этого пользователя - XML, SQL, что угодно, и используется для расшифровки каждого ключа, который используется для защиты данных.
Не зная больше о том, как настроена ваша система, или о ее назначении, трудно порекомендовать что-либо, кроме "Ключи должны быть защищены, ключи и IV не должны использоваться повторно"
. Это невозможно выполнить с помощью XPath. При использовании XPathDocument можно использовать метод AddSort .
Однако, если вы уже используете (и/или должны быть в состоянии обновить XML DOM), его, вероятно, просто легко выгрузить результат, полученный при работе с GroupNodes, в SortedDictionary , используя значение атрибута Key в качестве значения Key.
Одной из проблем, возникших при запуске JMeter в Windows XP, было ограничение TCP-подключения Windows XP. Ограничение должно быть снято, чтобы использовать JMeter для полного потенциала рабочей станции Дополнительная информация здесь . AFAIK, не относится к другим ОС.
-121--1304571-Как довольно хорошее решение, вы можете сохранить ваш ключ/IV в таблице:
ID Key IV
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923==
При сохранении зашифрованного значения сохраните идентификатор и случайное значение соли вместе с ним.
Затем, когда нужно расшифровать значение, найдите пару ключ/iv, используя идентификатор и соль, сохраненные вместе с данными.
Вы хотели бы убедиться, что у вас есть хорошая модель безопасности вокруг ключевых мест хранения. При использовании SQL Server не предоставляйте права SELECT пользователю, получающему доступ к базе данных из приложения. Ты не хочешь, чтобы кто-то получил доступ ко всему столу.