Securely handling private keys from the Windows keystore

Question

I am working on an application that encrypts the configuration file settings for the ASP.Net web server. The encryption method that I implement covers AES and RSA data. I generate the AES key using this AES key to encrypt my data, then encrypt the AES key using the public key from the certificate in my Windows certificate store. Then I save the data, together with the encrypted AES key and the serial number of the certificate used to encrypt it, back to the configuration file.

When I want to access this data, I read the serial number of the certificate used to encrypt the AES key, pulled the private key from this certificate and decrypted the AES key, and then decrypted the data using this key. Here I am not sure of my level of security.

In order to access the private key associated with the certificate, I must mark the private key as exportable and provide the user with my application to access the private key. Since this is an ASP.Net server, this user is Network Services. I am sure you can understand why this will be a security issue. Basically, if someone broke into my ASP.Net server via the Internet, possibly through some kind of injection, they would have access to this private key, wouldn't they?

Does anyone have any suggestions on how I can make my model more secure?

Decryption Function:

//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 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); } 

Thanks.

Answer 1

Just by writing

 RSACryptoServiceProvider rsaCSP = (RSACryptoServiceProvider)decryptionCertificate.PrivateKey 

this does not mean that you are assigning the actual "key". You can make the private key Non-Exportable and still be able to perform decryption.

Answer 2

If you have a private key certificate, it makes sense to use PKCS # 7 / CMS AES key encryption. This allows you to decrypt data using non-exported private keys.

Unfortunately, .NET does not offer classes for CMS encryption. CryptoAPI offers such functions ( CryptEncryptMessage and CryptDecryptMessage ), but they must be called through P / Invoke, which can be somewhat nontrivial. For a C # example of this, see Source Code here .

An alternative would be to use our SecureBlackbox components (TElMessageEncryptor, TElMessageDecryptor), although in your case this could be overkill.

Answer 3

I think there are some internal conflicts with your security model. You want the application running under the Network Services user to be able to decrypt the configuration file, but you want the encrypted information to be safe, even if the Network Services user is compromised. These two goals contradict each other - either the user can access the data, or can not. I think the best thing you can do is to segregate access to security, so that if Network Services on one machine is at risk, this does not compromise the security of other users or other machines. This is why the Windows security model provides each user on each computer with its own private key, and this is the key used by DPAPI to encrypt / decrypt configuration files.

You say that in your model you encrypt configuration information with a standard set of keys. In this model, if one trusted user on one computer is hacked, the attacker receives a key to access all encrypted configuration data for all users on all machines. You say that you use managed keys in the event of a machine failure. I would suggest that it is safer to back up and manage encrypted DATA, and then back up and manage the KEYS used to access this data.

My proposal uses the built-in .Net method to encrypt / decrypt configuration data, which uses the user's Windows private key on the local computer. (there are examples of standard aproach implementation here: http://weblogs.asp.net/jgalloway/archive/2008/04/13/encrypting-passwords-in-a-net-app-config-file.aspx and here: http: //www.codeproject.com/KB/security/ProtectedConfigWinApps.aspx ). If any data is inserted into the configuration files that are necessary and must be restored in the event of a machine failure, send this data to your database or other central data warehouse as a backup. This avoids the use of the same managed key or keys for all of your deployments.

Answer 4

Does anyone have any suggestions on how I can make my model more secure?

You are correct that any service running under vulnerable network services could potentially gain access to the private key. Sometime in 2005 or so, Microsoft realized this and began creating unique service accounts to limit the damage caused by a common compromised service, such as Network Services. For example, the SQL server has been moved to its service account, IIRC.

The main problem is the security design problem with the Microsoft model, and you cannot handle it. Microsoft realized this and moved on to a slightly different model with CryptoNG, IIRC. In CryptoNG, operations using the private key fail, and IPC is used to transfer requests and results between the service and the process that performs the key operations. This is mainly about the issue you are worried about.

Even in the new model, you still need software that introduces the model. You should be fine, say, IIS 7, but Apache can cause problems because its model only recognizes file system ACLs.

Moving key operations outside the process is becoming standard practice. For example, GnuPG does the same. GnuPG uses a library called libassuan that marshals queries and results between consumers and manufacturers.

I would not worry too much about performance issues between the client and the server in the model outside the process. Windows panels, Unix channels, and Unix domain sockets are quickly lit. In addition, it looks a lot like Dr. Jon Bentley said: If it’s not necessary, I can do it as quickly as you would like.