Ответ 1
RsaProtectedConfigurationProvider
и AesProtectedConfigurationProvider
, несмотря на очень похожие имена, являются частями разных юниверсов.
RsaProtectedConfigurationProvider
находится в System.Configuration
и используется (как другие поставщики, наследующие от абстрактного ProtectedConfigurationProvider
) для шифрования/дешифрования разделов конфигурации в web.config для приложений ASP.NET.
AesProtectedConfigurationProvider
, в свою очередь, находится в Microsoft.ApplicationHost
и используется только для шифрования конфигурации IIS. В файле конфигурации пула приложений по умолчанию (DefaultAppPool.config) вы найдете следующее:
<configProtectedData>
<providers>
<!-- ... -->
<add name="AesProvider" type="Microsoft.ApplicationHost.AesProtectedConfigurationProvider" ... />
<add name="IISWASOnlyAesProvider" type="Microsoft.ApplicationHost.AesProtectedConfigurationProvider" ... />
</providers>
</configProtectedData>
Вы можете прочитать о AesProvider
и IISWASOnlyAesProvider
в IIS Securing Configuration:
AesProvider - Шифрование разделов IIS, прочитанных рабочим процессом IIS с использованием AES-шифрования.
IISWASOnlyAesProvider - Шифрование разделов IIS, прочитанных WAS с использованием AES-шифрования.
Итак, отвечая на ваш первый вопрос:
- Подтвердите, безопасно ли использование AesProtectedConfigurationProvider. Он был удален Microsoft в последующих выпусках .NET, но я не может найти причину
Да, использование вашего пользовательского поставщика AES безопасно, если мы предположим, что вы внедрили его правильно, не имея недостатков безопасности. Microsoft не удалила AesProtectedConfigurationProvider
из .Net Framework, она никогда не была частью System.Configuration
. Если Microsoft обнаружила недостаток безопасности в своей реализации, они могли бы просто исправить, а не удалять, исправить?
- Предоставьте шаги для реализации AesProtectedConfigurationProvider и создания KeyContainer в ASPNET_REGIIS
Я считаю, что вы можете иметь AES-шифрование без реализации пользовательского AesProtectedConfigurationProvider
.
Я выкапываю исходный код RsaProtectedConfigurationProvider
и обнаружил, что он имеет следующую логику:
private SymmetricAlgorithm GetSymAlgorithmProvider() {
SymmetricAlgorithm symAlg;
if (UseFIPS) {
// AesCryptoServiceProvider implementation is FIPS certified
symAlg = new AesCryptoServiceProvider();
}
else {
// Use the 3DES. FIPS obsolated 3DES
symAlg = new TripleDESCryptoServiceProvider();
byte[] rgbKey1 = GetRandomKey();
symAlg.Key = rgbKey1;
symAlg.Mode = CipherMode.ECB;
symAlg.Padding = PaddingMode.PKCS7;
}
return symAlg;
}
Как вы видите, по умолчанию RsaProtectedConfigurationProvider
поддерживает переход с Triple DES на AES-шифрование с помощью System.Security.Cryptography.AesCryptoServiceProvider
.
UseFIPS
считывается из раздела конфигурации RsaProtectedConfigurationProvider
. Вы можете установить его на уровне машины (machine.config), чтобы он применялся ко всем зашифрованным конфигам или только для определенного web.config.
В следующем случае добавьте следующий раздел в web.config(я скопировал раздел из machine.config и добавил useFIPS = "true" ):
<configuration>
<!-- ... -->
<configProtectedData>
<providers>
<remove name="RsaProtectedConfigurationProvider"/>
<add name="RsaProtectedConfigurationProvider"
type="System.Configuration.RsaProtectedConfigurationProvider,System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
description="Uses RsaCryptoServiceProvider to encrypt and decrypt"
keyContainerName="NetFrameworkConfigurationKey"
cspProviderName=""
useMachineContainer="true"
useOAEP="false"
useFIPS="true"
/>
</providers>
</configProtectedData>
<!-- ... -->
</configuration>
Теперь, если вы запустите aspnet_regiis, вы увидите, что данные шифруются с помощью 256-битного AES:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
Симметричный ключ AES хранится так же, как и для режима Triple DES: ключ шифруется с помощью RSA и встроен в зашифрованный раздел, в то время как ключ RSA хранится в контейнере машинного ключа. Дополнительную информацию см. В этом блоге.
Я считаю, что использование AES-шифрования, которое уже реализовано в RsaProtectedConfigurationProvider
, намного лучше, чем пользовательский поставщик AES. Вы используете существующий метод хранения ключей, и вы защищены от возможных (весьма вероятных) недостатков безопасности.