Encrypting File System (EFS)

Before I get into the configuration details, I first want to explore how EFS encryption works. EFS uses public-key cryptography in order to secure files. This means that both a public key and private key exist for the purpose of encryption and decryption. However, what the public key encrypts is not the files themselves. Instead, every file is encrypted with a unique key, called a FEK (file encryption key), and this FEK is stored in the header of the encrypted file, in a field called the Data Decryption Field (DDF). The FEK isn’t just left there all open and exposed, however. It is encrypted with the user’s public key. When the user wants to open the file, their private key is used to decrypt the FEK, and then the FEK is used to decrypt the file. The beauty of this arrangement is that even if a hacker were able to decrypt the FEK, they still only get into a single file, since every file has a unique FEK.

Having said this, how is it that the recovery agent is also able open the file? Well, the FEK is also separately encrypted by the public key of each recovery agent, and stored in different header fields in the encrypted file, called Data Recovery Fields (yes, if there is more than one recovery agent, there will be more than one DRF for the file). For a recovery agent to decrypt the file, the private key of the agent is used to decrypt the FEK, which in turn decrypts the file. So who generates the FEK? The system itself, by way of the CryptoAPI.

Now that we’re all cryptography experts (don’t I wish!), lets take a look at how all this gets dealt with from the system admin point of view. First of all, you do not need a Certificate server in order to use EFS, though EFS will contact the configured certificate authority for certification is one exists. If a CA for a user is not present, EFS will create a key-pair and will self-sign the certificate, which allows a user to begin using EFS without any further configuration. So, right from the get-go, users can begin encrypting files and folders as necessary. For the sake of simplicity, folders should have the encryption attribute set, and users should be taught to save files into the encrypted folder. Just remember – for the user to be able to open the existing files saved there, the folder must be encrypted while logged on with their own account! As for private key storage, this is stored encrypted by system keys as part of the user’s profile. So, if you’re using roaming profiles, EFS capabilities follow the user. Otherwise, files encrypted by a user on a given machine can only be opened on that machine, since their key-pair is stored as part of their local profile.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of 2000Trainers.com. He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.