Как безопасно обрабатывать значения AES "Key" и "IV"

Ответ 1

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

Первый...

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

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

Разработчики уже давно справляются с этой проблемой, и нет серебряной пули.

Все это настроено в среде с одним сервером (приложение плюс dbase), поэтому я не могу отправить/получить ключ ко второму серверу. Кроме того, в этом "специальном" случае Im не может зашифровать ключ контейнером ключей RSA на уровне машинного уровня или пользовательского уровня.

Я могу представить два возможных решения.

Вариант 1:

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

Плюсы:

• Перезапускается без вмешательства человека.

Минусы:

• Вы должны сделать право безопасности ОС, и нет места для ошибок.
• Злоумышленник с доступом администратора может перейти к ключу.

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

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

Вариант 2:

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

Плюсы:

• Ключ никогда не будет на диске.
• Даже если сервер коренится, переход к ключу не является простой задачей.

Минусы:

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

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

Ответ 2

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

Ключи шифрования - это труднее всего управлять, и самое лучшее, что вы можете сделать, это сохранить базу данных и приложение отдельно, поэтому "если" они "взломают сервер и получат dbase" (скажем, SQL-инъекция позволяет им делать дамп таблиц базы данных), они по-прежнему не могут дешифровать сами поля.

Ответ 3

Правила большого пальца:

• Ключ должен быть секретным во все времена (нигде не должно быть рядом с базой данных)
• IV для каждой записи должен отличаться.
• IV должен быть "неотличимым от случайного" и непредсказуемым, предпочтительно, он должен происходить из того же источника, что и ваши ключи AES; другой вариант - зашифровать некоторое значение (другое для каждой записи) с помощью секретного ключа.
• IV не обязательно быть секретным

Следовательно, можно использовать одну схему:

• Создайте таблицу с идентификаторами полей (уникальный, int), IV (уникальный, 16 байт), зашифрованный (переменные байты, NULLable)
• Чтобы записать новую запись в базу данных, создайте новый уникальный IV и создайте новую запись в базе данных с пустыми зашифрованными данными (для предотвращения коллизий).
• Зашифруйте данные с помощью секретного ключа и IV с шага 2 (режим CBC или CTR - лучше CTR) и обновите запись.

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

Это будет настолько же безопасно, как вы можете получить с AES, что означает безопасность CCA/CPA. Единственное, что это не мешает, - это подделка

Ответ 4

Здесь будет полезно разделить ваш веб-сервер и сервер db. Вы хотите заблокировать доступ (с разрешениями) к вашим ключам шифрования и сохранить их в памяти как SecureString. Не могу сделать гораздо больше. Выбирайте надежные пароли и следите за современными методами безопасности.

Здесь также хороший пост Где хранить ключи шифрования MVC-приложения

Ответ 5

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