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

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

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

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

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

Тем не менее, ключ должен быть вызван по одной из трех причин:

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

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

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

Ответ 1

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

Аппаратный модуль безопасности (HSM) - обычно довольно дорогостоящий и не простой в реализации. Может быть выделенным устройством (например, nCipher) или конкретным токеном (например, Alladin eToken). И тогда вам еще нужно определить, как обращаться с этим оборудованием...
DPAPI (API защиты данных Windows). Существуют классы для этого в System.Security.Cryptography(ProtectedMemory, ProtectedStorage и т.д.). Это отводит управление ключами ОС - и это хорошо работает. Используемый в "USER_MODE", DPAPI блокирует дешифрование ключа для одного пользователя, который зашифровал его. (Не становясь слишком подробным, пароль пользователя является частью схемы шифрования/дешифрования - и нет, изменение пароля не нарушает его.)

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Физическое: запись на USB-накопитель, запись на CD и т.д. Хранить в физически защищенном месте. Но вы сталкиваетесь с рекурсивной проблемой: где вы храните ключ в хранилище? Как правило, вы делегируете 2 или более человек (или группу) для хранения ключей.
Программное обеспечение: Cyber-Ark Private Ark - это то, что моя компания использует для хранения секретной цифровой информации. Мы сохраняем все наши пароли администратора, лицензионные ключи, закрытые ключи и т.д. Он работает, запустив сервер хранилища Windows, который не подключен к домену, брандмауэры всех портов, кроме его собственных, и хранят все свои данные, зашифрованные на диске. Пользователи получают доступ через веб-интерфейс, который сначала аутентифицирует пользователя, а затем надежно связывается с сервером хранилища через интерфейс, подобный проводнику. Все изменения и версии регистрируются. Но это также имеет ту же рекурсивную проблему... мастер-доступ к CD. Это сохраняется в нашем физическом хранилище с ограниченным доступом.

Ответ 8

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

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

Ответ 9

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

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