Безопасная обработка личных ключей из Windows Key Store - PullRequest
6 голосов
/ 06 мая 2011

Я работаю над приложением, которое шифрует настройки файла конфигурации для веб-сервера ASP.Net. Метод шифрования, который я реализую, заключается в конвертации данных с использованием AES и RSA. Я генерирую ключ AES, использую этот ключ AES для шифрования моих данных, затем шифрую ключ AES открытым ключом из сертификата в моем хранилище сертификатов Windows. Затем я сохраняю данные вместе с зашифрованным ключом AES и серийным номером сертификата, использованным для его шифрования, обратно в файл конфигурации.

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

Чтобы получить доступ к закрытому ключу, связанному с сертификатом, я должен пометить закрытый ключ как экспортируемый и дать пользователю, чтобы мое приложение работало с доступом к закрытому ключу. Поскольку это сервер ASP.Net, этим пользователем является «Сетевые службы». Я уверен, вы понимаете, почему это будет проблемой безопасности. По сути, если бы кто-нибудь взломал мой сервер ASP.Net через Интернет, возможно, с помощью какого-то рода инъекции, у них был бы доступ к этому секретному ключу, не так ли?

У кого-нибудь есть предложения относительно того, как я могу сделать свою модель более безопасной?

Функция расшифровки:

//need an rsa crytpo provider to decrypt the aes key with the private key associated with the certificate
using (RSACryptoServiceProvider rsaCSP = (RSACryptoServiceProvider) decryptionCertificate.PrivateKey)
{
    //decrypt the aes key with the cert's private key
    byte[] aesKey = rsaCSP.Decrypt(encryptedAESKey, false);

    //decrypt data using the decrypted aes key and the IV passed in
    decryptedData = decryptWithAes(encryptedData, aesKey, aesIV);
}

Спасибо.

Ответы [ 4 ]

2 голосов
/ 04 июня 2011

Просто написав

RSACryptoServiceProvider rsaCSP = (RSACryptoServiceProvider)decryptionCertificate.PrivateKey

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

1 голос
/ 14 июля 2011

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

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

Мое предложение заключается в использовании встроенных .Net методов шифрования / дешифрования.данные конфигурации, которые используют закрытый ключ пользователя Windows на локальной машине.(здесь есть несколько примеров реализации стандартного подхода: http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx и здесь: http://www.codeproject.com/KB/security/ProtectedConfigWinApps.aspx) Если в конфигурационные файлы заносятся какие-либо данные, которые необходимы и должны быть восстановлены в случае сбоя компьютеразатем отправьте эти данные в базу данных или другое центральное хранилище данных в качестве резервной копии, чтобы избежать использования одного и того же управляемого ключа или ключей для всех ваших развертываний.

1 голос
/ 07 мая 2011

Если у вас есть сертификат с закрытым ключом, имеет смысл использовать шифрование ключа AES PKCS # 7 / CMS.Это позволяет вам расшифровывать данные с помощью неэкспортируемых закрытых ключей.

К сожалению, .NET, похоже, не предлагает классов для шифрования CMS.CryptoAPI действительно предлагает такие функции ( CryptEncryptMessage и CryptDecryptMessage ), но они должны вызываться через P / Invoke, что может быть в некоторой степени нетривиальным.Для примера C # см. Исходный код здесь .

Альтернативным вариантом будет использование наших SecureBlackbox компонентов (TElMessageEncryptor, TElMessageDecryptor), хотя в вашем случаеэто может быть излишним.

0 голосов
/ 03 января 2016

У кого-нибудь есть какие-либо предложения относительно того, как я могу сделать свою модель более безопасной?

Вы правы в том, что любая служба, работающая в Сетевые службы , которая может быть взломана, потенциально может получить доступ к закрытому ключу.Когда-то в 2005 году или около того, Microsoft осознала это и начала создавать уникальные учетные записи служб, чтобы ограничить ущерб, нанесенный общей скомпрометированной службе, такой как Network Services .Например, сервер SQL был перенесен в свою собственную учетную запись службы, IIRC.

Основная проблема - это проблема проектирования безопасности в модели Microsoft, и с ней мало что можно сделать.Microsoft поняла это и перешла на немного другую модель с CryptoNG, IIRC.В CryptoNG операции, использующие закрытый ключ, выполняются вне процесса, а IPC используется для передачи запросов и результатов между службой и процессом, который выполняет ключевые операции.В основном это побочный шаг к проблеме, которая вас волнует.

Даже в новой модели вам все равно понадобится программное обеспечение, осведомленное о модели.Вы должны быть в порядке с, скажем, IIS 7, но Apache может вызвать проблемы, потому что его модель распознает только ACL файловой системы.

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

Я бы не слишком беспокоился о проблемах эффективности между клиентом и сервером вмодель процесса.Windows Pipes, Unix Pipes и Unix Domain Sockets быстро растут.Кроме того, это очень похоже на Dr.Джон Бентли сказал: Если это не должно быть правильно, я могу сделать это так быстро, как вам хотелось бы.

...