Симметричное хранилище ключей

Question

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

---

Спасибо за ваши ответы, все.

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

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

При этом ключ необходимо будет вызвать по одной из трех причин:

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

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

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

Answer 1

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

1. Модуль аппаратного обеспечения безопасности (HSM) - обычно довольно дорогой и непростой в реализации. Может быть выделенным устройством (например, nCipher) или специальным токеном (например, Alladin eToken). И тогда вам еще предстоит определить, как обращаться с этим оборудованием ...

2. DPAPI (API защиты данных Windows). Для этого есть классы в System.Security.Cryptography (ProtectedMemory, ProtectedStorage и т. Д.). Это отдает управление ключами ОС - и хорошо с этим справляется. Используемый в «USER_MODE», DPAPI блокирует расшифровку ключа для одного пользователя, который его зашифровал. (Не вдаваясь в подробности, пароль пользователя является частью схемы шифрования / дешифрования - и нет, изменение пароля не нарушает его.)

ДОБАВЛЕНО: Лучше всего использовать DPAPI для защиты вашего мастер-ключа, а не для непосредственного шифрования данных вашего приложения. И не забудьте установить надежные списки ACL для вашего зашифрованного ключа ...

Answer 2

У нас та же проблема, и мы прошли через тот же процесс.
Нам нужно запустить процесс на одном компьютере (клиент), который затем войдет на второй компьютер (сервер базы данных).

В настоящее время мы считаем, что наилучшей практикой будет:

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

По сути, логин-пароль оператора является ключом, но он нигде не хранится.

Answer 3

В ответ на # 3 этого ответа из ОП

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

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

Answer 4

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

После первоначального безопасного обмена ключ согласовывается, и остальная часть сеанса (или новый сеанс) может использовать этот новый симметричный ключ.

Answer 5

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

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

Answer 6

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

В этом случае у вас есть два очевидных варианта:

• Физический: запись на USB-накопитель, запись на компакт-диск и т. Д. Хранить в физически безопасном месте. Но вы сталкиваетесь с рекурсивной проблемой: где вы храните ключ от хранилища? Как правило, вы назначаете двух или более человек (или команду) для удержания клавиш.

• Программное обеспечение: Cyber-Ark Private Ark - это то, что моя компания использует для хранения своей секретной цифровой информации. Мы храним все наши пароли администратора, лицензионные ключи, закрытые ключи и т. Д. Он работает, используя сервер «хранилища» Windows, который не присоединен к домену, защищает все порты, кроме его собственного, и сохраняет все свои данные в зашифрованном виде на диске. Пользователи получают доступ через веб-интерфейс, который сначала аутентифицирует пользователя, а затем безопасно связывается с сервером хранилища через интерфейс, подобный проводнику. Все изменения и версии регистрируются. Но у этого также есть та же самая рекурсивная проблема ... главный диск доступа администратора. Это хранится в нашем физическом хранилище с ограниченным доступом.

Answer 7

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

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

Это не так безопасно, как использование аппаратного токена, но все же может быть достаточно хорошим и довольно простым в использовании.

Answer 8

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

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

Answer 9

Microsoft Rights Management Server (RMS) имеет похожую проблему. Он просто решает проблему путем шифрования конфигурации с помощью мастер-пароля. ... пароль на пароль, если хотите.