EFS: Protecting Files at Rest
When concerned about our data, there are a few aspects that matter more than others. In security circles, this is expressed by the acronym: C. I. A.
Confidentiality, Integrity, and Authentication, Availability, Auditing, Access control. (The A stands for quite a bit.) Each of these is a legitimate concern, but we don’t always need all of them.
For example: Our public websites are not confidential in nature, anyone can access them. But it does matter to us that the content be what we intended. We don’t need confidentiality, but we do need integrity (the content hasn’t been subject to an unauthorized change.) Hash values on files can do this for us.
A file with trade secrets is a definite concern for Confidentiality. We only want authorized personnel to see it. NTFS permissions will protect the file on the network, but anywhere else it’s subject to security settings we can’t control.
An order for goods purchased is often not a secret, but it does matter that the order the vendor receives is the order you sent; that it hasn’t been changed en route.
For each of these concerns, we have mechanisms to enforce our security goals. Let’s take a look at protecting the file while it’s on the drive. EFS, the Encrypted File System can achieve Confidentiality, Integrity and Authentication of the author. It does this through encrypting the files and closely guarding the encryption keys.
There are actually a few encryption keys involved in this process, and understanding the relationship between them is critical to solving access/availability issues that arise. There are two different encryption mechanisms used for each file.
When a user creates a file that is tagged as encrypted (either by encrypting just that file, or by placing it in a folder that is tagged for encryption) then a completely unique File Encryption Key [FEK] is created, and attached to the file. This same key is used to encrypt and decrypt the file. When a single key is used for both processes, it is called SYMMETRICAL encryption.
Symmetrical encryption is fast, but also vulnerable to brute force attacks (trying all possible keys until one works.) All you need is the same key that was used to encrypt the file, and it’s right there, ON THE FILE. You might think this means anyone could access the FEK and us it to read the file, but that won’t work.
The FEK is attached to the file, but only AFTER it is encrypted. The FEK is encrypted using ASYMMETRICAL encryption. In asymmetrical encryption, different keys are used to encrypt and decrypt the data. You may know this as “Public key/Private key” encryption. Public keys are given away freely, while the Private key is very closely guarded.
In Pub/Priv encryption, there are key pairs which work together. Either key can be used to encrypt the data, but whichever key was used to encrypt CANNOT decrypt; you have to use the other key. Sometimes the Private key is used to encrypt, and the public to decrypt (this is the case with a signed email.) With EFS, the Public key is used to encrypt, and the Private key used to decrypt.
When a user creates a new file, tagged with EFS, the new file gets a new FEK. This FEK is then encrypted with the user’s Public key. In order to open the FEK, you must have access to the user’s Private key (which we DON’T give away freely) in order to decrypt the FEK. Then your session used the FEK to read the file and present the unencrypted file to your application. This all happens behind the scene, and is usually unnoticed by the user… until something goes wrong.
To keep from making your own files inaccessible, you should export your private key, and store it securely somewhere else. If you ever lose your Pub/Priv keys, you will not be able to access any of your encrypted files. If you have a backed up copy of a private key, you can import it into any user account, granting transparent access to the encrypted files. To keep this backup up copy of the key from presenting a threat itself, you should password protect the file, then physically secure the copy in a locked location.
To export a private key, open a blank MMC console by running mmc.exe. Add the Certificates snap-in, and choose User.
Browse to and select the user certificate for EFS [there may be several certificates, so select the correct one.] Right-click and choose to export. You will be prompted for a password. On Windows 8.1 or later, you may also have the option of selected existing user accounts to grant them access to using the key.
Once this key I exported, use the same certificates snap-in to import the certificate to any user account. You can re-assign it to the user who had it before, or you could import into another account when one person assumes the work/role of another.