ASPNET_REGIIS: Поместите ключ AES и IV в KeyContainer

Возможно ли разместить ключ AES и IV в KeyContainer с помощью ASPNET_REGIIS? Если да, то как?

Контекст:

Я создал AesProtectedConfigurationProvider для шифрования данных web.config с использованием AES в отличие от Triple DES (т.е. 3DES). Я также создал консольное приложение, которое использует AesProtectedConfigurationProvider для генерации ключа AES и вектора инициализации (IV). Я могу сохранить ключ в текстовом файле, а затем ссылаться на текстовый файл в провайдере web.config. Оттуда я могу зашифровать файл web.config. Но я хотел бы защитить файл keys.txt, переместив их в KeyContainer, если это возможно.

Итак, в теге провайдера раздел для keyContainerName будет следующим:

keyContainerName="AesKeyContainer" 

в отличие от

keyContainerName="C:\AesKey.txt"

Мое понимание - текущее предложение шифрования, доступное из коробки в ASPNET_REGIIS, использует 3DES для шифрования содержимого файла web.config, в то время как RsaProtectedConfigurationProvider используется для шифрования ключей 3DES (пожалуйста, исправьте меня, если я ошибаюсь это). Итак, если можно использовать RsaProtectedConfigurationProvider для шифрования ключей AES в KeyContainer, это будет полезно. Я просмотрел следующие сайты, и я не уверен, что это возможно:

https://msdn.microsoft.com/en-us/library/33ws57y0.aspx

Как зашифровать web.config с помощью AES вместо 3DES

EDIT: Кто-нибудь знает, почему Microsoft вытащила AesProtectedConfigurationProvider в последующих выпусках .NET? Это похоже на шаг назад, поскольку AES является текущим стандартом, а 3DES больше не рекомендуется. Говоря с коллегой, они упомянули, что, возможно, они были удалены из-за нарушения безопасности, например; возвышение привилегий. Microsoft, как известно, делает необъявленные изменения в отношении безопасности. Но я хотел бы знать, знает ли кто-нибудь точно. Если в AesProtectedConfigurationProvider был обнаружен недостаток, я мог бы склониться к тому, чтобы оставаться с 3DES.

Ответ 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 обнаружила недостаток безопасности в своей реализации, они могли бы просто исправить, а не удалять, исправить?

  1. Предоставьте шаги для реализации 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. Вы используете существующий метод хранения ключей, и вы защищены от возможных (весьма вероятных) недостатков безопасности.