2.8.4 EFS – Part 2
By Val Bakh
The most important aspect of using EFS pertains to encryption keys. There are two kinds of keys: a file encryption key (FEK) and a private/public key pair. EFS automatically generates a FEK for each file that you want to protect and uses the FEK to encrypt the file. Private and public keys come with certificates. A certificate is a digital object that affirms your identity by associating your name or user account with a pair of keys. The two keys complement each other; the public key is usually available to everyone, and the private key is securely stored in your user profile. Alternatively, in more secure environments, a private key can be stored on a smart card or other similar device.
To encrypt a file, you need to open the file’s properties, click Advanced on the General tab, and select Encrypt contents to secure data. Decryption of an encrypted file occurs transparently; that is, when you open the file, it is decrypted automatically. When you subsequently close the file, it is automatically re-encrypted. To share the file with others, you should click Advanced on the General tab in the file’s properties, click Details in the Advanced Attributes dialog box, click Add, and select the appropriate users. You can select only those users who have an EFS certificate. If someone whom you want to allow access to your file doesn’t have a certificate, ask that user to encrypt any file. Depending on the specific situation, it can be a file on your computer or, sometimes, on another computer. EFS will automatically obtain or generate a certificate for the user.
You can request an EFS certificate from a certification authority (CA) that might be available on your corporate network. A CA is a specially configured computer that can issue and revoke certificates, publish certificate revocation lists (CRLs), and perform other related certificate-management tasks. When you initiate a request from the Certificates console on your computer, the computer generates a private/public key pair and sends the public key to the CA. The CA issues a certificate, sends it back to your computer, and optionally, publishes the certificate to Active Directory Domain Services (AD DS). The published certificate together with the associated public key, but without the private key, is stored in your domain user account. Thus your certificate and your public key become available to all AD DS users. The copy of the certificate that is sent to your computer is placed into your personal certificate store, and the private key is securely stored in your user profile. If the profile is local, the key is stored on the computer from which you requested the certificate. If the profile is roaming, the key is stored in the profile on a file server and also in the local copy of the profile on each computer you logged on to.
When you attempt to encrypt a file on your computer, EFS generates a FEK, encrypts the file by using the FEK, and looks for a suitable certificate that is issued to you. If such a certificate exists, EFS uses the associated public key to encrypt the FEK. If EFS has not found your certificate, EFS attempts to obtain one from an enterprise CA. If there is no CA or if EFS cannot obtain a certificate for you, EFS automatically generates a self-signed certificate. The important difference between a certificate issued by a CA and a self-signed certificate is that the former is usually automatically trusted by all relevant entities, such as users and computers on your corporate network, whereas the latter is not. You can successfully use a certificate only if it is trusted by the relevant entities. This is similar to getting past a security checkpoint at your workplace with an ID card issued by your company’s management versus presenting a similar-looking card that you manufactured yourself. Imagine yourself trying to convince a security guard that it’s OK to let you in because you really work there. A quick phone call from your boss might resolve the issue for the guard who is on duty at the moment, but next time you try to go in or out, another guard will require another phone call.
When you attempt to open a file that you encrypted earlier, EFS looks in your user profile for a private key that matches the public key used to encrypt the FEK. If EFS finds the private key, EFS uses it to decrypt the FEK and then uses the FEK to decrypt the file. If EFS cannot find the matching private key, you are denied access to the file.
In Part 1 of this blog post, we described how you can share your encrypted files with colleagues. But what would happen if you did not share your encrypted files with anyone and if someone had a legitimate need to access them while you were on vacation? Or how would you gain access to your files if the OS on your computer crashed and your private key were lost? To mitigate such circumstances, an administrator on your network can designate an EFS data recovery agent (DRA). First, a trusted user must be issued an appropriate certificate. A DRA’s certificate is different from regular users’ EFS certificates. The value of the Extended Key Usage attribute in a regular EFS certificate is Encrypting File System, whereas in a DRA’s certificate, it is File Recovery. The administrator can add the DRA’s certificate to the Computer Management\Policies\Windows Settings Security Settings\Public Key Policies\Encrypting File System folder in a Group Policy object (GPO) that targets the appropriate computers. Then each time you encrypt a file on a computer targeted by the GPO, EFS encrypts a copy of the FEK by using the public key from the DRA’s certificate and attaches that encrypted FEK to the file along with another copy of the FEK encrypted by using the public key from your EFS certificate. As a result, the DRA can always decrypt your files, even if you lose your private key and can’t open them yourself.
This is similar to how you can share your encrypted files with trusted colleagues, except that you need to add your colleagues’ certificates to your files manually, whereas the DRA’s certificate is added automatically. On one hand, automatically is good because it is convenient; once an administrator has designated a DRA, no one needs to take any further action. On the other hand, the proverbial devil is often in the details. We’ll talk about some of those details in the next post.
So far, we have introduced EFS and the main concepts related to encryption and decryption. In part 1 of this blog post, we described everything in common-sense terms. In this blog post, we made the discussion more technical. Next month, we’ll continue talking about certificates and present a few common scenarios involving EFS.
Are you preparing for a Microsoft certification exam? Try our Microsoft Practice Exam demos and Microsfoft Practice Lab demos today!