3

The following youtube video does a pretty good job at summarizing how EFS works. For those interested in a summary of the contents of such windows I have attached it below. However this leaves me with one question concerning security:

  1. When a user logs on in Windows, presumably a hash is computed from the password (or alternatively from the password plus the username and perhaps other data such as a salt). When a user first creates a password, such hash must be stored somewhere on the hard drive if I am not mistaken. At least, old Unix systems used to work in such manner (with such has stored in /etc/passwd). Thus when a user logs on, the password hash is computed and compared to what is stored in such file in order to authenticate the user. If the hashes match, the user is logged in.

So far so good. If the above mechanism is the one used (on modern Windows systems), this means that when someone hacks into a Window system, they can read such password hash, and thus, using the special Microsoft symmetric encryption algorithm (as described below) which is stored on the hard drive and thus can be learned by a hacker, the password hash plus the Microsoft special symmetric algorithm plus knowledge of where the encrypted private key is stored on the hard drive allows the hacker to decrypt it, thus obtaining the private key. And once the private key is obtained of course, then all data encrypted using the public key in the certificate can be decrypted by the hacker.

Can someone please point out the flaw in my reasoning? Presumably the flaw is due to a misunderstanding of mine concerning how Windows authentication is carried out.

Thanks.

http://www.youtube.com/watch?v=YxgWsa-slOU

Summary of the contents of the above video: - EFS (available in the NTFS file system) is designed to allow users to encrypt files and folders so that nobody except for the person encrypting such file or folder can access it. Administrative accounts on stolen machines can be created with minimal hacking knowledge, and can thus gain access to virtually any files contained on the hard drive. Symmetric key encryption algorithms work about 100 to 1000 times faster than public key encryption algorithms. right-click -> Properties -> General -> Advanced... -> Encrypt Contents to Secure Data and click on Apply, (you can then choose between encrypting just the file or encrypting the file and its parent folder and then click on OK). Windows will turn the file green and we will still have full access to the file. Once this someone logging in with an administrator account will not be able to see the file. You can in fact access the certificate manager with the "certmgr" command, and from there you can view the contents of the Personal -> Certificates application folder, which can start out as empty. When we encrypt a file in the above manner, a symmetric key called a DESX algorithm file encryption key (FEK) is generated and then the certificate's public key is used to encrypt the FEK and store it with the encrypted data. In the certificate contained in the certificate store you can get access to the public key but not the private key (the cerificate attests that user such and such are who they say they are and displays the user's public key). The certificate also points to the private key, but such private key is stored in a special location on the hard drive, and is encrypted using a special Microsoft symmetric key algorithm generated master key, where the master key is generated using a hash component from the username and password of the user every time the user logs on, and the resulting symmetric key is not stored anywhere on the hard drive (i.e. it must be kept somewhere in memory).

AstroCB
  • 12,337
  • 20
  • 57
  • 73
John Sonderson
  • 3,238
  • 6
  • 31
  • 45

2 Answers2

4

The hash value that is used to access the private key, which unlocks the symmetric key, is not the same as the hash value that is stored (used for authentication). Both hashes are derived from the password, but they are not computed the same way. Neither are reversible, and they cannot be used interchangeably.

To access your files, they need you to either be logged in already, or they need your password.

Also note that EFS normally designates the administrator or domain administrator as the "recovery agent". When the private key is stored, it also stores a copy that can be accessed by the administrator.

As shown in Figure 15.9, encryption with EFS requires the presence of at least two certificates in the certificate store on the local computer: one for the user (file owner) and one for a recovery agent account.

You can disable this feature by setting another of your accounts as the recovery agent, but in a domain, normally your domain administrator will set this policy and not allow you to disable it. So, the administrator can still access your files.

As long as an attacker doesn't gain the password for the recovery agent's account (or yours), your data should still be safe from an attacker, assuming the attacker isn't the same person as the recovery agent.

It's important to have strong passwords, keep them safe, and avoid running malicious software that could access the data directly.

Community
  • 1
  • 1
Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • Thank you for your post and for the link, which among other things displays the fact that there is also a mandatory Data Recovery Field (DRF) and zero or more optional Data Recovery Fields (DRFs) as you pointed out. As you mention, there has to be a Data Recovery Agent (DRA), whether the default one, another one, or one set by the Windows domain administrator. – John Sonderson Nov 22 '13 at 18:02
  • Now I understand: as you explained, the hash is computed using a different hashing function than the one used to store hash values on the hard drive used for authenticating users. The hash value is not stored on the hard drive. This closes the security hole I had conceived of. – John Sonderson Nov 22 '13 at 18:09
  • 1
    @JohnSonderson, I improved my answer, so hopefully it's more clear to future readers. – Marcus Adams Nov 22 '13 at 18:13
  • Thanks. I would like to point out one thing though. From the diagram you posted, it is necessary that an attacker gain access to either your password, or any one of the recovery agent passwords, in order to recover the file encryption key (FEK) and hence decrypt and thus read the contents of your encrypted files. It is not necessary that the hacker have access to more than one of these. – John Sonderson Nov 22 '13 at 18:18
  • 1
    @JohnSonderson, that's right. I mistakenly used the word "also", and removed it. It should be technically correct now, and is hopefully more clear. – Marcus Adams Nov 22 '13 at 18:19
  • 1
    The other way the system can be compromised, although I guess this should be much harder, is if the hacker found a whole in the operating system which allowed them to read memory used by processes pertaining to other user accounts, hence enabling them to read all the keys and functions used in the algorithm. I'll let someone else post a comment on how hard or easy this would be though. – John Sonderson Nov 22 '13 at 18:20
1

Thanks for your views on my YouTube video. I am certainly no expert on the details of current encryption technology and so my answer won't do your question justice. The video is intended to give someone who is unfamiliar with the details of EFS a more coherent understanding of how it all works.

However, having said that.. it looks like the previous reply answers the question. Hashes are not reversible. I think I used the words 'virtually impossible' to reverse engineer.. but really Hashes are used because they cannot be reversed to give the passwords. Password crack programs, from my limited understanding, start with a plaintext word from a dictionary, use the same hash algorithm and attempt to generate the same hash as the target hash they are attempting to decrypt. As long as you've used a good password, you can't crack the hash. Bad passwords are the only way passwords get cracked.

It is easy to set up an administrative account if you have access to any machine, but any new account set up will not have access to any private keys. A recovery agent has to be set up PRIOR to encrypting anything with EFS in order for the recovery agent to have access to a user's file. But then, both the Recovery Agents private key hash and the target person's private key hash are both unrecoverable to a new admin account.

I think that's the way it needs to work, or there is no real security.

Dave Crabbe

Dave
  • 69
  • 1
  • 4
  • Commenting on your comment regarding hashes, I am no expert either, but since hashes are not reversible, one known way to crack bad passwords is, if the passwords are short, one could use rainbow tables, which are tables which compute the hash value for each one of a set of usually short passwords, and record the password together with its hash. These can for example compute a list of all passwords which are from zero to 8 or 9 or even 10 characters long, and then compare the result with the hash value to see if any of them matches. If a match is found the password is compromised. – John Sonderson Nov 22 '13 at 18:28
  • One way to prevent this sort of attack is through the use of the salt you mention in your video, which ensures that the rainbow table would have to be computed taking that specific salt value into account, and thus the resulting rainbow table would only be applicable to the specific computer the hacker wants to crack and not in general, thus increasing security a bit. – John Sonderson Nov 22 '13 at 18:29
  • Nevertheless, as you mention, if passwords are short or just bad, they can be guessed by a hacker using the above method, thus it is just as important to use strong passwords. – John Sonderson Nov 22 '13 at 18:30