2

I have a .NET Windows Service that needs to store a secret on the machine and protect that secret from local system administrators. It is OK if domain admins have access.

This secret is not user entered. It is generated at installation time, and the installation can be automated.

My first thought was to use EFS. If I ran my Windows Service as a domain account and stored the secret in an EFS encrypted file, even local system administrators couldn't access the file unless they were also domain admins and utilized an EFS recovery certificate.

Is there a better option? Is there a way to do this without requiring the Windows Service run as a domain account?

RMD
  • 131
  • 1
  • 1
  • 6
  • 1
    This should never have been migrated because the solution is to use encryption, which means this needs to be done programmatically instead of trying to make it an OS level issue. – John Gardeniers Sep 14 '10 at 21:27
  • @John - agreed. What on earth does this have to do with anything server related? Voting to close as Belongs on SO – Mark Henderson Sep 14 '10 at 21:36
  • (for the naysayers when this gets back to SO, **if** the question was about EFS, then yes it could stay here, but the question is **not** about EFS, it's about appropriate techniques for storing a secret, of which EFS was offered as a possible solution, but the OP is asking for a **better** way than this) – Mark Henderson Sep 14 '10 at 21:38

2 Answers2

1

I think using public key cryptography would be a good fit for this.

Generate the secret, then encrypt it with the public key. Save it locally. Share it everywhere for all anyone cares. Provided your initial encryption is good enough, there is no issue with local administrators having access to the encrypted secret.

This assumes of course you do not share the private key for the crypto with your local administrators :)

Brennan
  • 1,398
  • 6
  • 18
  • OK, but where is your private key stored? – Gabe Jun 30 '14 at 20:10
  • To securely store a private key, I would use a cryptographic device, and not store it on the filesystem. For low security uses, filesystem can be good enough though. – Brennan Feb 17 '15 at 03:42
  • But how do you ensure that a local administrator can't access this cryptographic device (or file)? – Gabe Feb 17 '15 at 04:21
  • A crypto device with serious functionality e.g. FIPS 140-2 level 2 have its' own operating system, and separation of duties. These devices are commonly called hardware security modules (HSMs) with PCI, pciE, USB, and network based form factors, or in the lower end side, smartcard/microSD based versions. If you are storing it in software on the filesystem the administrator would have access. You may be successful in moving the crypto functionality to TPM type of modules on some newer motherboards, e.g. http://download.intel.com/support/motherboards/server/sb/g21682003_tpm_hwug.pdf – Brennan Feb 17 '15 at 21:47
0

The registry is built for that. You can specify permissions at the key level.