Best practice to automatically import a Key File.

Topics: Cryptography Application Block, Enterprise Library Core
Dec 4, 2007 at 9:36 AM
Edited Dec 4, 2007 at 9:39 AM
We're building a WinForms application which is going to be deployed using Systems Management Server on hundreds of machines. So we need a way to automatically import a key file on each machine. I've thought of serveral possible ways to do this:

1. Write a custom action that is run by the installer, which imports the password protected key file to a DPAPI protected key file for each machine.
2. Import the password protected key file to a DPAPI protected key file when the application starts.

There are some problems with both these two strategies. The 1st strategy suffers from references to managed code (Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.dll), which doesn't work well for custom actions. I've even tried creating a managed code console application that is executed after InstallFinalize, but then there was a problem on Vista machines, because that custom action didn't run under administrator preveliges, so the key file that is written to the Program Files folder is placed in VirtualStore instead (which is not recommended).

The 2nd stategy has several possible ways to do it, and I wonder which is the best:
A. The config section can be modified to refer to the AppData or temp folder of the current user, when the application starts. And the key file can be imported to one of those folders.
B. The application block can use a key file placed in the current users temp folder, without reading the location from a config section.
C. The application block can be modified to look for the key file in a special folder, which is relative to the current user (AppData or temp folder).

I don't know if solution B is possible without doing any modifications to the application block. If not, I guess both B and C are not recommended.

For solution A, I wonder if there is a way to modify the values of the config section at runtime without actually writing the modification to the <application name>.exe.config file, because writing to this file is also a problem on Vista (the modified version is placed in the VirtualStore). We do that to the connection string section, using My.Settings.Item("<key>") = <connection string value> when the application starts. The value is not written to the file, but reading from that property gets the new connection string value at runtime, even if the config file has the old value. But My.Settings.Item(...) doesn't work for EntLib configurations, so I wonder if the Configuration Application Block also has the ability to use runtime values which differs from the actual values of the config file?

There might also be another strategy to deal with this problem, which I haven't thought of.