Is ConfigurationManage -> section.SectionInformation.ProtectSection() machine dependent?

Question

in the code

Configuration config = ConfigurationManager.OpenExeConfiguration (Application.ExecutablePath);
ConnectionStringsSection section = config.GetSection("connectionStrings") as ConnectionStringsSection;
if (!section.SectionInformation.IsProtected)
{
    section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
}

I´m getting some trouble when I move the application to another machine.

is the section.SectionInformation.ProtectSection call machine dependent, meaning, I cannot copy the config file and use it on another machine ?

Is there a provider (other than DataProtectionConfigurationProvider ) that is machine independet ?

It is a requirement for my application that it works on several machines with the same config file (It must run from a flash drive).

Thanks, Fábio

Answer 1

Is the section.SectionInformation.ProtectSection call machine dependent, meaning, I cannot copy the config file and use it on another machine ?

Yes, that's correct as far as I can tell. This article says keys are stored on a per-machine or per-user basis.

Is there a provider (other than DataProtectionConfigurationProvider ) that is machine independet?

Not out of the box, the two providers I know of (DataProtectionConfigurationProvider and RSAProtectedConfigurationProvider) both have the same "problem". I found a few hints that the RSA provider allows for keys being re-used across machines, but have not found any examples on how to achieve this.

However, there is a way to achieve what you need, I just did it myself yesterday since I had a similar problem (I had a requirement to run an app from a network location, and all clients needed to share the same encrypted config file). You can roll your own ProtectedConfigurationProvider. Here's a few links that illustrate the concept:

• Implementing a Protected Configuration Provider
• How to: Build and Run the Protected Configuration Provider Example
• Protected Configuration Provider Implementation Example

Using these articles, I was able to build my own ProtectedConfigurationProvider that is not machine- or user-dependant and use it in an application. I have a post-build step in my release build that protects the config section and therefore I only ever deploy the protected version of it. Getting at the protected section data works as one would expect on other machines without any problems. Of course, you have to be very careful about how to encrypt and decrypt your sections safely. There's a few examples out there outlining how to do it, this is one of them I think.

One of the things that isn't clearly stated in any of the three articles is how to make your app find your provider if you're not using ASP.net. The usual way of installing it into the global assembly cache probably won't work for you since you state you're running an app from a flash drive. So, you'd need to add it to your app.config file instead, similar to this:

<?xml version="1.0"?>
<configuration>
  ... 
  <configProtectedData defaultProvider="MyEncryptionProvider">
    <providers>
      <add name="MyEncryptionProvider"
        type="MyAssembly.MyEncryptionProvider, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=whatever_the_assembly_token_is" />
    </providers>
  </configProtectedData>
  ...
</configuration>

This should work if the assembly that does the encryption is in the same path as your main assembly. I'm using a signed assembly, sn -T {Assembly} will give you the PublicKeyToken you need to enter in the config file.

Protecting a section is then done similar to this:

using System.Configuration;

...

Configuration oConfiguration = ConfigurationManager.OpenExeConfiguration(yourExePath);
oSection.SectionInformation.ProtectSection("MyEncryptionProvider");
oSection.SectionInformation.ForceSave = true;
oConfiguration.Save();

I tested it today, and it worked with a config file being encrypted on a development machine (XP SP3), and being used on XP SP2, Win7 32Bit and Win7 64Bit.

DISCLAIMER

• Not sure if any of this works if you don't sign your assemblies.
• Use at your own risk, I'm not an expert on security by any standards.