Protecting EFS Encryption Keys

by [Published on 30 Aug. 2005 / Last Updated on 30 Aug. 2005]

If you have mobile users in your organization, then implementing security can be especially challenging. You must secure the users’ laptops in such a way that if the laptops were lost or stolen that sensitive data would not be compromised. One way of accomplishing this task is by using the Encrypting File System (EFS). In this article, I will explain how to counteract some potential problems when using EFS.

EFS can encrypt individual files on the hard disk so that no one can read them except for the person who created them. Although EFS certainly provides extra security for mobile users, it has some risks of its own. The encryption keys themselves can be lost or stolen. If a key is lost, then the user loses access to their encrypted files. If the key is stolen, then the person who possesses the key can access the user’s files. I will explain how you can counteract both of these problems.

Why Key Protection is Important

As you probably know, the primary file level security mechanism in Windows is the access control list (ACL). ACLs work great for securing files against access from across the network, but they do very little to protect files from being accessed by someone with physical access to the machine. There are numerous utilities that can bypass the operating system and gain full access to the NTFS file system. This is where EFS comes into play. EFS encrypts files so that if someone does access the file system outside of the operating system, the encrypted files will be unreadable. The only way (outside of using a recovery agent) to access the encrypted files is to log in as the user who has encrypted the files.

The argument could be made that if all someone has to do to access encrypted files is log in as the user who encrypted them, then the files aren’t really safe. The reason for this is that there are utilities that can be used to reset any local user’s password without actually having to know the user’s original password and without even having to log into the operating system (the reset process occurs outside of the operating system). Windows has a safety mechanism built in though. If a user’s password is reset, then the encryption keys are invalidated and encrypted files can no longer be accessed by the user. The user can change their own password, but password resets trigger the key’s “self destruct” mechanism.

As you can see, it is possible for someone to lock a user out of their own files, just by resetting the user’s password. At the same time though, the whole encryption and decryption process is tied to the user’s account. If the user forgets their password then they can not log in and therefore can’t access the encrypted files. If an administrator resets the user’s password, the user can log in, but loses access to any files that have been encrypted.

Recovery Agents

To prevent data loss, you should have a designated recovery agent. Designating a recovery agent is kind of like giving a neighbor a key to your house in case you ever lock yourself out. You are trusting your neighbor not to use your key to enter your house when you aren’t home, and you are trusting your neighbor to let you into your house if you ever lock yourself out.

Recovery agents work similarly. A recovery agent is someone who has a backup copy of the encryption key and can decrypt files for you if you ever lose your encryption keys. There is both good news and bad news regarding the recovery agent though. The good news is that you already have one. The local Administrator account (the Administrator account, not someone from the Administrators group) is automatically a recovery agent for the machine. If a user locks themselves out of an encrypted file, the Administrator can log in, take ownership of the file, grant themselves access to the file, and then remove the encryption bit or use the Cipher command to decrypt the file.

The bad news is that the recovery agent is the local Administrator account. Being that the Administrator account is a favorite target of hackers, it would be really nice to designate a different account as a recovery agent. While it is possible to designate an alternate account as a recovery agent, you can’t do it without the aide of a certificate authority (CA).

Windows Server doesn’t install a CA by default. It takes a fair amount of planning and work to implement a CA. Once you do though, you can use it to designate accounts of your choice to act as recovery agents.

Exporting Certificates

By now we have established that encrypted files are secure in that only the authorized user and a designated recovery agent have access to them. There is one remaining problem though. If a thief knows the user’s password, then they can gain access to the user’s encrypted files. Imagine the scenario for a moment. A user is sitting in an airport getting some work done. The guy sitting next to the user sees the user type in his password and therefore knows what the password is. If that person were to steal the laptop, they could log in as the user whom they stole the laptop from and gain access to all of the user’s encrypted files.

There is a way of protecting your users against this type of theft though. By default, the encryption keys are stored on the system’s hard drive. You can however export the keys onto some form of removable media and then remove the keys from the system’s hard disk. That way, if someone does steal a laptop and knows the user’s password, they still won’t be able to access the encrypted files because they do not have the encryption keys.

If you decide to export the encryption keys to removable media, then I recommend using a USB flash drive. They tend to be a lot more durable than floppies and CDs. You might also burn a copy to CD and put it in a safe place just in case anything ever happens to your USB drive.

To export your EFS keys, enter the MMC command at the Run prompt. When you do, Windows will load an empty Microsoft Management Console. Now, choose the Add / Remove Snap-In command from the console’s File menu. You will now see the Add / Remove Snap-in properties sheet. Click the Add button found on the properties sheet’s Standalone tab and you will see a list of the available snap-ins. Select the Certificates option and click Add. Next, select the My User Account option and click Finish , followed by Close and OK.

Now that the Certificates snap-in has been loaded, navigate through the console tree to Console Root | Certificates - Current User | Personal | Certificates. Your certificates will now appear in the column to the right. Right click on the certificate that you want to export and select the All Tasks | Export commands from the resulting shortcut menu. Windows will now launch the Certificate Export Wizard.

Click Next to bypass the wizard’s Welcome screen. You will now be asked if you would like to export the private key along with the certificate. The private key is needed to decrypt encrypted files, so be sure to export it. Click Next and you will be prompted for the export options that you want to use. I recommend including all certificates in the certification path, enabling strong protection, and deleting the private key when the export completes. Click Next and you will be prompted to enter a password. Since you have chosen to export a private key, you must password protect the key. Click Next and you will be prompted to enter a filename for the exported file. The last screen that you will see gives you a chance to review all of the options that you have selected prior to performing the actual export. If everything looks good, then click Finish to complete the process.

Conclusion

In this article, I have explained why encrypting files may provide users with a false sense of security. I then went on to explain how users could gain greater security by removing encryption keys from their hard drive. I also explained why having a designated recovery agent is important.

Advertisement

Featured Links