11

If I understood correctly, when I enable NTFS encryption (EFS) for a specific folder in Windows, it uses specific account's user name/password (salted) to create asymmetric keys for data encryption and decryption. If I enable encryption for a certain folder, I presume this means that other system accounts (like LocalSystem or NetworkService) won't be able to access contents of this folder.

How does this work if you enable encryption for the entire drive? I.e. how are Windows services able to use the disk at all in this case?

The reason I am asking is that I would like to enable encryption on a certain folder containing deployed executables for several applications (a service, a gui console, some command line tools, etc.), so I'd like to understand exactly how I will need to configure all this to work.

(Update)

To clarify, we have a server located at a remote location, and we would like to protect our installed software from copying or disassembly. The server is running some services which receive data from devices and store them around, and it has a web app for visualization. Login is protected by a rather strong password, but this doesn't stop anyone from pulling out the disks and making a copy.

If EFS suitable for this? Or should we take a different approach?

  • 1
    This answer may be helpful security.stackexchange.com/a/8314 – Purefan Nov 2 '15 at 11:55
  • @Purefan: Thanks, it's helpful, I have a feeling this might be the wrong tool for the job. – Groo Nov 2 '15 at 12:19
  • I'm guessing: s/compression for the entire drive/encryption for the entire drive/? – StackzOfZtuff Nov 2 '15 at 12:23
6

Maybe BitLocker instead of EFS?

we have a server located at a remote location [...] stop anyone from pulling out the disks and making a copy.

Well, you could use BitLocker Full-Disk-Encryption and store the decryption key inside the mainboard's TPM chip. And set BitLocker to automatically unlock the volume on boot.

This would mean that a thief would have to steal the WHOLE SERVER and not just pull out a disk.

This BitLocker volume unlocking mode of operation is called TPM only.

Here's a blog article that lists the different modes:

Luis Rocha, Count Upon Security blog, 2014-06-23, BitLocker with TPM in 10 steps. (Archived here.):

  • TPM Only: No authentication required for the boot sequence but protects against offline attacks and is the most transparent method to the user.

This would at least make any attempt to get at the key much easier to prevent/detect.

  • 1
    TPM is prone to Cold Boot Attacks. If an attacker is able to physically access the server (hence, pulling a disk) he would be possible to also retrieve the key stored in TPM, without stealing the whole server. It would be a lot more difficult to pull off, but it's no impossible. – Daniel Jan 4 '16 at 12:31
3

No EFS for system folders.

Documentation says: You can't do it. (I haven't tried, but the docs are rather clear about it.)

The MSDN entry File Encryption (archived here) says:

Note that the following items cannot be encrypted:

  • Compressed files
  • System files
  • System directories
  • Root directories
  • Transactions
  • Thanks, but still, what if I encrypt a user folder and there is a service application inside which should be run before logon, or any data to which a system service should have access to? How could the service access this data without having user's password stored somewhere? – Groo Nov 2 '15 at 12:28
  • Second/different answer added. – StackzOfZtuff Nov 2 '15 at 14:44
  • @Groo EFS does have the concept of file recovery agents, which tells EFS to encrypt and store additional copies of the file encryption key for those agents. It's possible you could create a cert and key pair for your service account and then designate that through file recovery policy. This might allow both your primary user (Administrator?) and the service account to access the encrypted data. I have not tested this configuration with a service account so I'm unsure if it will work. – PwdRsch Nov 2 '15 at 17:12
  • @Groo Ultimately I think you will be better off looking into a full disk encryption solution as recommended by WoJ. – PwdRsch Nov 2 '15 at 17:18
3

Sooner or later your executable will need to be in the memory of the server hosting it. So it will be available for analysis anyway.

In order to be loaded to memory, it must be decrypted if it was encrypted earlier.

In other words, once you have control over the remote server the data which you will be running there will be available for analysis.

  • I am presuming the attacker cannot get control of the server, but only pull the disks out (or boot a different OS to access disk contents). – Groo Nov 2 '15 at 13:23
  • 2
    In that case (provided that you control the server) a full-disk encryption is the solution. Such a disk is useless when taken from the server. The encryption layer is low in the stack, so from an application perspective, it is accessing unencrypted data. – WoJ Nov 2 '15 at 13:25
-1

To answer the question: If EFS suitable for this?

I think EFS is suitable:

  • Encrypt with EFS protect in case hard disk would be put in another computer. Files cannot be read without security certificate
  • In order to protect your source code in the running server, encrypt all folder source code with an user just you manage. In this way, neither an administrator or system account can read or access your source code. But apache cannot read the file. You must run apache service with the same user account you encrypted the folder. Make sure you disable file list in your apache server configuration.
  • if an attacker reset your user password, encrypted files won't be available for nobody, you must provide a security certificate.

Edit:

  • Of course, you must have access to web server you are deploying your site, and be able to create and manage a user.

does someone detect something missing to this approach?

  • 3
    Yes, this is what the person asking is talking about, but you have not actually answered the question. – schroeder Jun 4 '18 at 6:17

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.