3

Problem: I have a windows service running under the local system account. I have a blob of data that I want to store securely and persistently between reboots. I have decided to store it as a file( as opposed to a binary blob key in the windows registry?). Since I'm running in a service I cannot have user interaction to get a password and use something like pbkdf2 etc to derive an encryption key to encrypt the file which contains the data blob. I'm looking for the best possible way to store the file securely on the windows file system. Below is the set of assumptions that I have made on what I trust and what attack scenarios are important to be followed by a proposed implementation. It'll be great if anybody can poke holes and also suggest better alternatives.

Assumptions and attack scenarios: I assume the operating system ie windows to be trusted and secure. If a security flaw is found in windows and my secret/encrypted file is compromised, it is okay. If the admin account is compromised and the file is deleted, it's okay. However, other users without access to say windows\system32(which seems like one of the most locked down directories) should not be able to access or delete this file through code or UI. It would be preferable if the file can be stored in a location where even admin users don't have access but my service does but I don't know of such a location. Dumb admin users who delete system files are not a threat/problem. The main goal is to protect against trivial deletion and modification of the file through UI and user code.

Implementation: I plan to use windows DPAPI without using user credentials(because I can't in the local system account service) to lock it to a particular user. I plan to encrypt the file to the local system and also provide some entropy/service specific key to encrypt and decrypt the file. The app-specific entropy will be a guide plus some information that is hardware specific(such as firmware rev or other data that can be read off hard-coded hardware registers) and only my service have access to and no other software can access this information. I realize if the firmware rev is updated or hardware changed, decryption will not work but this should be a rare situation. An attacker can dump/analyze my service binary and figure out the guide but hopefully, the hardware specific information should be difficult to get to. If I do this, and place the encrypted blob In a file in windows\system32, only admin/higher privilege users allowed access to this through file system API/UI will be able to decrypt it using DPAPI(if they get the guide and hardware specific info that nobody should be able to get to) or read/write delete the file through code or UI. Storing the blob unencrypted in the registry should nearly offer the same protection against most attacks except that an admin user can modify the binary data/blob and can cause bad software behavior. DPAPI offers integrity protection so I chose this over simply writing to a secure-ish location in the registry which nobody other than admin users can get to.

Does this look okay or are there better ways to achieve this? Any other security holes to watch out for or think about? This is a fairly simple issue so I'd like to implement the simplest solution.

  • 1
    Storing in registry is not recommended for largish data. - A folder with access granted to SYSTEM (or the user your service runs as) and explicitly revoked from Administrators is not secure enough, I suppose? In the end, Administrator can impersonate a lot ... – Hagen von Eitzen Aug 29 '15 at 15:16
  • I think you will no be able to protect against somebody with admin rights whatsoever. Using the extra entropy for DPAPI is a good idea. If you already take Reverse Engineering into account, you will not be able to keeps the Hardware related entropy secret. In the end you rely on OS syscalls for that or System libraries which would be visible to an adversary. So he could access this information the same way you did (with Admin/System rights). – John Aug 29 '15 at 18:46
  • 1
    Basically the question is how secure do you really need it to be? Your idea is enough to protect against the everyday User and with some tricks also against unintentional deletion/modification by admins. But if you have somebody Who really tries to break your program and has hardware access, it is just a matter of time and expertise. – John Aug 29 '15 at 18:55
  • Can you store the data off the computer? Sending the data to a remote file would reduce the damage a local admin could do (eg: perhaps they could append the file but not delete or read). – Neil Smithline Aug 29 '15 at 19:55
  • It's hard to defend against a local admin as they could, for example, modify your program to store the file in a less secure manner. Without hardware security and you being the only admin, they'll always be some risk. – Neil Smithline Aug 29 '15 at 19:56
1

The most common scenario for services running independently of logged in users is to just use the file system protection provided by the OS.

Here, that means that the service has to be runned under a trusted account. A trusted account is something that only trusted users (and admins) can access. By the way, as you say in comments that you do not care of trying to defend against local admin, that should be enough. SYSTEM can be an acceptable account but (maybe because I use Unix as well as Windows) I think that a dedicated account can make things more clear. When an admin sees a folder owned by SYSTEM and accessible only to that, they could wonder what system service uses it, but when it is owned by an explicit account, the question vanishes.

Once you have choosen the account (local or AD), you only have to give access only to that account (and the admin account you use to configure that), remove all other permissions, optionaly give ownership to the specific account, and let Windows system protect the folder.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.