0

I have a windows exe which has to write some secure data to HKEY_LOCAL_MACHINE (HKLM). I also have a service running as NetworkService account which has to read that secure data. Note that exe and service run as different users.

Problem here is with securing the data. I tried with CryptProtectData, but the problem is that service cannot decrypt because the data was not encrypted using NetworkService account. I don't want to use CRYPTPROTECT_LOCAL_MACHINE flag while calling CryptProtectData as any user can decrypt it and essentially making it unsecure.

I am guessing that this is a common use case, but unable to find any solution. Any ideas please?

FYI, i am using visual C++ to write the exe and the service.

Bajji
  • 2,243
  • 2
  • 22
  • 35

1 Answers1

0

You're trying to use the registry as an inter-process communication (IPC) mechanism and you're finding that it's not very elegant.

A better architecture for what you're looking for would be to handle the encryption / decryption totally within the service and use a real IPC mechanism (TCP sockets, mailslot, etc) to transfer the data from the EXE to the service for encryption.

Edit:

The registry doesn't sound like the right place for this data, encryption aside. Putting on my "sysadmin hat" I'd much rather have your data in the filesytem than in the registry. Using the registry as a store-and-forward queue mechanism gives me the willies.

Insofar as cryptographic architecture I think you'd be best served using assymetric encryption. Let the EXE encrypt the data using the service's public key. The service can decrypt the data with its private key.

Evan Anderson
  • 14,051
  • 3
  • 21
  • 14
  • Reason for storing encrypted data in the registry is because the service will not be running (it will not be created as well) when the exe runs, and the exe will collect secure data from the user and stores it in the registry so that after the service is installed and started, it can pick that data, decrypt it and start using it. – Bajji Aug 23 '11 at 17:13
  • I agree with you on preferring file over registry, makes lot sense not to play with registry unless not avoidable. Regarding encryption, is it true that it is easy to take a dump of the process and take a look at the key which is present in the code ? (I am new to windows programming, so i am not quiet sure how secure that key would be) – Bajji Aug 23 '11 at 17:25
  • You definitely don't want to embed the key in your code if you can help it. I suggest you continue using CryptProtectData, but have the executable install and start the service (in a special mode if necessary) and use IPC to encrypt the data in the NetworkService account context. (If you really can't install the service ahead of time, create a second service for this purpose.) – Harry Johnston Aug 23 '11 at 22:24
  • Also, you might want to consider using a security context other than NetworkService. Lots of code runs in NetworkService, and if any of that code has a vulnerability, then so do you. If this is Windows 7, consider using a managed service account or a virtual account (although I'm not sure whether virtual accounts support encryption or not). – Harry Johnston Aug 23 '11 at 22:27
  • @evan-anderson, inline with your suggestion i tried storing it in the file and encrypting the file (EFS) and granting permission to NetworkService account to decrypt the file, but that didn't work (im guessing) because NetworkService account does not have any certificate associated with it. Thank you very much for your time. – Bajji Sep 04 '11 at 06:42
  • @harry-johnston: i guess your original suggestion of letting the NetworkService account requires design change, but i think that's the only way left. I'll try with that. Thank you very much for your time. – Bajji Sep 04 '11 at 06:44