Deploy EFs: Part 1

Deploy EFs: Part 1

John Morello

So far, many people have heard of similar reports, that is, the loss of personal data or sensitive data due to the theft or loss of portable computers. Portable computers regularly lose data. As identity theft is becoming more and more serious and regulatory compliance is more and more important than ever, comprehensive protection for all data in mobile computing systems will become a top priority.

One solution is to use an encrypted file system (EFS), which is included in Windows 2000 and later versions, providing a disk-based Built-in high-performance encryption method. EFS is seamlessly integrated with Windows Explorer, so end users often do not know when the files they are using are encrypted. In addition, EFS also applies to local Windows Authentication and access control technology, so users do not need to remember each password to access data. Finally, EFS provides manageable options to restore data when users lose access to their encryption keys (such as deleting or damaging user configuration files or losing their smart cards.

EFS uses Windows built-in encryption technology to generate, store, and deploy strong encryption keys to protect data. In Windows XP Service Pack 1 (SP1) and later versions, EFS encrypts data on disks using the 256-bit key Advanced Encryption Standard (AES) algorithm. Then, asymmetric (RSA) key pairs are used to protect these symmetric keys. EFS uses the AES key to encrypt each file. Then, the key is encrypted using the user's RSA key and the results are stored in the file. For more information about EFS encryption, see the "EFS resources" sidebar. Now, I will skip the EFS technical support and focus on how to deploy EFS and make it available in your environment. Therefore, this article assumes that the reader has knowledge about the concept of EFS encryption in advance.

EFS security considerations

Some applications claim to be able to crack EFS encryption technology. Note that these applications encrypt the ciphertext by decrypting AES (or Data Encryption Standard, des; or extending the Data Encryption Standard, desx, instead of cracking the User Password forcibly to obtain the EFS private key access permission. Remember that the most important aspect of EFS encryption is that the private key uses the data protection API (dpapi) to generate and protect encrypted data. Dpapi uses User Login creden to protect data. The final result is that using EFS to protect data is as good as using a user password to protect data. If you are using Windows Vista, you can now store the EFS encrypted certificate on a smart card. This will change this example and greatly improve the security of the data protected by EFS.

How long is the password used to defend against these attacks? Given today's Hardware capabilities and modern cryptographic attack algorithms, we recommend that you use a password of 11 characters or longer (more accurately, a cryptographic phrase ). The 11-character or longer cryptographic phrase can better resist most of today's advanced attack methods, including pre-computed hash attacks (such as rainbow table; for details, please refer to the blog article "why you shouldn't be using passwords of any kind on your Windows networks" listed on the "Resources" sidebar (the reason why password of any type should not be used on Windows networks) )).

Is PKI used?

One of the most common misunderstandings about EFS is that EFS uses a public key infrastructure (PKI. Although EFS can be easily integrated and used with PKI (your company should already have PKI), this is absolutely not necessary. That is to say, the decision on whether to use PKI in EFS deployment will affect many future deployment decisions. It is best to think twice.

The key advantage of combining PKI and EFS is the ability to perform key archiving and key recovery. The Administrator is allowed to perform data recovery only when EFS is used, and automatic key recovery is only available when PKI is run, or even when Windows Server 2003 Enterprise Edition is used only as a Certificate Authority (CA). After a user loses access to the encryption key, the user provides the encrypted data to the specified administrator, also known as the data recovery proxy (DRA, the administrator can then decrypt the data and return it to the user, or re-encrypt the data to use it through a new private key. This process is called data recovery. Dra is like the shadow of the user's encryption process, that is, the user uses a copy of The Dra key to encrypt any content using the key to repeat the same operation. Therefore, after the user loses the key, he can use the DRA to obtain the ciphertext data, then apply the DRA key to it for decryption (or re-encryption), and finally return the data to the user. The Dra method works very well, but it is difficult to manage it if you have a large amount of encrypted data or no local IT staff is responsible for Dra.

On the other hand, the CA needs to back up the user's encryption key during key creation, and securely store the key copy to the CA database. After the user loses the access permission to the encrypted file, the Ca administrator only needs to access the database and retrieve the user's key. In this way, you can immediately obtain data access permissions without using DRA for restoration. You can use this method to quickly and efficiently restore keys. However, note that the best practice is to always set DRA, even when key recovery is used, to provide a backup mechanism for key loss events. It also supports distributed recovery systems for large organizations. Local IT administrators can recover user data without joining the PKI Administrator group.

The combination of PKI and EFS makes it easier to share encrypted files. Note that EFS is not only limited to portable computer systems; it is equally useful in any situations where the physical security of computers cannot be guaranteed. In these cases, multiple users may need to access the same encrypted data. Although Windows only allows sharing a single file, rather than a directory, it also imposes some restrictions on the support for sharing encrypted files, but it is also a useful tool. To simplify EFS file sharing, users who are sharing files must have the permission to access the public key of the user who is sharing files with them (if these users have valid EFS certificates published to accounts in Active Directory, this will be very simple ). Although publishing can be performed manually, Windows ca installed in Enterprise (integrated with Active Directory) mode can completely automate the entire process.

EFS Key Management

If you are using a Windows Server 2003-based PKI, the EFS certificate generation process is very simple. Windows Server 2003 CA has a set of default Certificate Templates, including basic EFS. However, this template is a version 1 template and does not support key archiving. Therefore, you need to copy the template to create a new version 2 template (for example, EFS with key archive, as shown in Figure 1) before using it on the CA ). On this new template, go to the "processing requests" tab and select the option to archive the user encryption key. Note that you must configure the key archive on the CA before enabling this option. The Resources Section includes the best practices for this process. You should also use this template to replace the basic EFS template to ensure that the client can use this new version (see figure 2 ).

Figure 1 EFS with key archive (click the image to get a small view)
Figure 1 EFS with key archive (click the image to get a large view)
Figure 2 replace the basic EFS template (click the image to get a smaller view)
Figure 2 replace the basic EFS template (click the image to get a larger view)

Next, you need to set the appropriate permissions on this template to allow the specified user group to have the corresponding registration and access permissions. When you use EFs for the first time, the EFS component in Windows automatically requests the certificate. Therefore, you do not need to register the EFS template automatically. In fact, we recommend that you do not enable automatic registration of EFS certificates unless you are sure that all automatically registered users use EFS. Figure 3 shows the EFS registration settings. By issuing certificates to users who may have never used EFS, you can expand the scale of the CA database, but this is not helpful. Although the CA database is not limited in size, database management becomes more difficult if the number of certificates is increasing (using the Microsoft Management Console (MMC) ).

Figure 3 set EFS user permissions (click the image to get a small view)
Figure 3 set EFS user permissions (click the image to get a larger view)

Finally, to support the sharing of encrypted files, it is best to have ca automatically publish user certificates to Active Directory.

Once you have correctly configured the template on the CA, the user will obtain the certificate from your ca when encrypting the file through EFs for the first time, at the same time, the CA will automatically archive its private key.

Dra Key Management

If PKI is used, the next question to consider is whether to use the DRA certificate generated by CA. Why don't I want to use the DRA certificate from PKI? Consider this situation, that is, the validity period of the certificate issued by the CA is quite short (two years or even shorter ). This Ca cannot issue any certificate with a longer validity period than its own, which means that your DRA certificate can only be used for a maximum of two years. This results in extremely complex data recovery. The following is an example of this assumption.

1. The user encrypted a file on July 15, January 2006. The Dra certificate issued to his computer through group policy is valid for two years (expired on July 15, January 2008 ).
2. The user continues to use EFS to encrypt new files.
3. After the DRA certificate expires on April 9, January 2008, the Administrator issues a new certificate through the Group Policy.
4. From now on, all encryption operations will be performed with the new DRA certificate (including opening all files encrypted with the original DRA certificate and using the new DRA for encryption during storage ), however, files that have not been moved by the user are still protected by the original Dra.
5. If the user accidentally destroys the configuration file and needs to recover the data.
6. The IT administrator must provide two sets of DRA certificates: Files modified after Step 3 use the new DRA certificate, and files not modified use the original DRA certificate.

 

Although the IT administrator can use the new DRA to update all files (using cipher.exe/U) after step 3, this process takes a lot of time. More specifically, although the recovery policy contains an expired DRA certificate, the EFS component will not allow any new encryption operations, the Dra key pair is not completely useless after expiration. There is no doubt that old files encrypted by the expired DRA key pair can still be recovered by them. Therefore, even if the DRA key pair has expired, do not discard it. It may be used in the future.

Therefore, we recommend that you use a self-Signed DRA certificate with a long validity period in the environment of a CA with a short validity period. The password utility includes a switch that automatically creates an EFS recovery proxy key pair with a 100 life cycle (see figure 4 ). The certificate in this key pair can be attached to the Group Policy object (GPO) and used as the DRA for the entire organization. Because the EFS component does not check the trust chain of the DRA certificate, you can use these self-signed certificates without modifying the list of Trusted Root Certificate Authorities on the system. No matter how long the Organization's Ca is used, we recommend that you create at least one DRA certificate with a long service life and attach it to the domain GPO. This is the backup data recovery option used when all other options are unavailable. It is particularly important to use the DRA key generated by the CA in the absence of the CA key archive. If the DRA certificate has been damaged, you can update the GPO using the new certificate and use the cipher.exe/u mentioned above to update the file.

Figure 4 run ciquer/R (click the image to get a smaller view)
Figure 4 run ciquer/R (click the image to get a large view) EFS Resource

You can visit the following sites to learn more about EFS details and best practices.

• Why you shouldn't be using passwords of any kind on your Windows networks)
• Implementing key archival Walkthrough)
• Encrypting File System in Windows XP and Windows Server 2003)

 

Deploy KRA and Dra

Key archive allows the CA administrator to restore the managed encryption key on behalf of the user. Obviously, this is a sensitive and powerful capability because it allows the CA administrator to decrypt any data in the organization that uses the key signed by the CA. Therefore, key archiving and recovery should be treated with caution and permissions should be granted to only a few trusted security personnel. In view of the sensitive nature of key recovery, if you want to use it as the main mechanism for re-obtaining EFS encrypted data access permissions, it is very important to clearly define the recovery request upgrade process to be sent to the CA administrator team. The recovery process can be started only after the request is fully checked. After that, once the key is actually restored, it should be provided to the user in a safe way (in other words, do not use email, because the recovered key provides the permission to access all user data protected by EFS.

The key recovery agent (or KRA key) is generated and kept by the CA administrator and is not advertised through the Group Policy. In fact, EFS itself cannot determine whether the key it uses is archived; it only performs encryption as usual. In addition, the Kra key created on the CA is not in any way specific to EFS. The CA that uses the key archive appends an unlimited number of KRA keys at the Ca level to protect all the keys archived by the CA. These keys include keys used together with EFS, secure email, or any other purpose that includes encrypted certificates. A dedicated key recovery proxy should be used to securely store the Kra key, and at least two KRA keys should be available in case of key loss.

When the Administrator first creates a domain region Controller in a newly created domain, the Administrator uses the self-signed certificate and key pair stored in the DC Administrator configuration file to create a default recovery policy at the domain level. This DRA certificate has a validity period of three years. The recommended method is to delete this default certificate and generate a self-signed certificate with a longer validity period or a certificate issued by PKI. If the default self-signed certificate is not deleted, the EFS created by the default self-signed certificate will stop encrypting new files within the entire domain after three years. This is because the certificate has expired. If the EFS recovery policy contains an expired DRA certificate, EFS will prevent any data from being encrypted. Although you can operate Windows XP and later versions without a proxy recovery policy, we strongly recommend that you do not. This means that if a user loses access to the Encrypted Key for some reason and cannot restore the key, all data of the user will be irrecoverable.

As mentioned earlier, the DRA key can be self-signed or issued by the CA. In most cases, the best combination of the two is to use at least two long-lived self-Signed DRA as the final option for recovery proxy within the enterprise. Because the DRA certificate is deployed through a group policy object, it has the same inheritance function as other GPO. In other words, the standard machine, site, domain, organization unit (OU) GPO accumulation and application algorithm used to control other GPO settings of the application are also applicable to Dra. Therefore, for DRA, organizations can easily implement hierarchical methods. The central IT group has the permission to access each part of the enterprise, however, the local IT group also reserves the access permission for the specific region in which it is responsible. This is a very helpful asset for large and geographically dispersed organizations, because it can ease the need for massive encrypted data transmission through WAN links and facilitate data recovery. Figure 5 shows a typical multi-layer DRA deployment.

Figure 5 Multi-layer DRA deployment

In this case, users in the Baton Rouge ou will eventually obtain six DRA for each encrypted file: two local administrators, two North American it groups, and two from the domain level. Therefore, if you lose access to the encrypted data, you can recover it through the local DRA or North American it group in Baton Rouge. As the final backup, if neither of the four DRA is available or has been lost, the data can be restored through the domain-level Dra. Regardless of which DRA performs the recovery operation, the process is basically the same. The user first makes the data available to Dra. It is important that DRA take the necessary steps to determine that the request is valid and the real owner from the data. After this step is completed, Dra will load the DRA certificate, decrypt (preferably re-encrypt) the data, and then return the data to the end user. Some organizations also choose to perform local recovery. Dra loads the DRA key pair to the configuration file for users with physical access problems, decrypts the data, and deletes the key pair. Then, the user will obtain the access permission to the data in plaintext format and can use the new key to re-encrypt the data. It should be noted that this method is less secure because the DRA key pair is copied to a local computer (even temporarily), but this method can save time, especially when a large amount of data must be restored.

Note that, if the user is restored through key archiving and restoration, the method for processing the recovery request will be completely different from the above process. If you do not use DRA at all, your key recovery request will be forwarded to the CA administrator. After checking the request, the Administrator will go to the archive and retrieve the user's private key. Then, they allow users to securely use this private key, such as placing it on a secure website for download. (If you use a smart card to store your EFS Key and it is available on Windows Vista, the key should be released again .) You can load the key to the configuration file to instantly access all encrypted data.

Since both DRA and KRA key pairs can be used to decrypt sensitive data, it is important that they be protected properly. Dra and KRA key pairs should not be stored in the Administrator's conventional desktop configuration file (that is, the configuration file the administrator wants to complete daily tasks. Instead, these key pairs are securely stored offline to media such as floppy disks, CDs, and flash disks, and stored in physically secure locations. Then, when recovery is required, the recovery proxy can load the key pair from the media to the recovery workstation, perform the recovery operation, and finally Delete the key pair. Dedicated workstations can be designated within an organization that is extremely sensitive to security to further enhance the security of these key pairs, but not all organizations need this.

Next content

Since EFS planning for key management, data recovery, and active directory has been introduced, I will focus on client deployment issues in the second part of this topic. This will involve, for example, controlling the use of EFS through group policies, selecting the content to be encrypted, and automatically encrypting data through login scripts, and improve the Windows Explorer client to make it easier to use EFS to protect data.

John MorelloI graduated from LSU with the best academic performance and held many different positions in Microsoft's six years of work. As a senior consultant, he once designed security solutions for Fortune 100 companies and federal civil and defense customers. At present, he is the project manager of the Windows server group, responsible for security and remote access technical work.
From February 2007 journal technet magazine.
You are welcome to give your comments. You are welcome to send us feedback.