AES Шифрование и хранение ключей? - PullRequest
11 голосов
/ 10 января 2010

Несколько лет назад, когда я впервые познакомился с ASP.net и .NET Framework, я создал очень простую онлайн-систему хранения файлов. Эта система использовала шифрование Rijndael для хранения файлов, зашифрованных на жестком диске сервера, и HttpHandler для расшифровки и отправки этих файлов клиенту.

Будучи одним из моих первых проектов с ASP.net и базами данных, не очень понимая, как все это работает (а также попав в ловушку , описанную Джеффом Этвудом на эту тему ), я решил хранить только что сгенерированные ключи и IV вместе с каждой записью файла в базе данных.

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

У меня вопрос: если я не хочу хранить один ключ для всех файлов, как должен Я храню ключи шифрования для лучшей безопасности? Что считается лучшей практикой? (т. е. на другом сервере, в текстовом файле, в зашифрованном виде). ​​

Кроме того, для чего используется вектор инициализации в алгоритме шифрования этого типа? Должно ли оно быть постоянным в системе?

Ответы [ 3 ]

12 голосов
/ 10 января 2010

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

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

Как вы храните ключи, зависит от того, как ваша система спроектирована. Я только что закончил KMS, где ключи хранятся вдали от основной системы, а функции для шифрования и дешифрования доступны через WCF. Вы отправляете простой текст и получаете ссылку на ключ и зашифрованный текст обратно - таким образом, KMS отвечает за всю криптографию в системе. Это может быть излишним в вашем случае. Если пользователь вводит пароль в вашу систему, вы можете использовать его для генерации пары ключей. Затем эту пару ключей можно использовать для шифрования хранилища ключей для этого пользователя - XML, SQL и т. Д. И использовать для расшифровки каждого ключа, который используется для защиты данных.

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

4 голосов
/ 18 июля 2011

На эту статью есть очень хорошая статья в http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html, которая охватывает как проблемы с капельницей, так и проблемы соления, а также проблемы с ЕЦБ, упомянутые выше.

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

3 голосов
/ 11 января 2010

В качестве неплохого решения вы можете сохранить свою пару Ключ / IV в таблице:

ID                    Key           IV
skjsh-38798-1298-hjj  FHDJK398720== HFkjdf87923==

При сохранении зашифрованного значения вместе с ним сохраняются идентификатор и случайное значение соли.

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

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

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