EFS and Digital Certificates
In order to encrypt files and folders with EFS, a user must have a valid X.509 certificate. When a user attempts to encrypt data, EFS looks in the user’s personal certificate store for an EFS certificate. If it doesn’t find one, it attempts to enroll you for an EFS certificate with a Windows certification authority. If you’re not using a domain account or if it is unable to request a certificate through a CA, EFS generates a self-signed certificate. However, there are problems inherent in using self-signed certificates:
- Unlike a certificate issued by a trusted third party (CA), a self-signed certificate signifies only self-trust. It’s sort of like relying on an ID card created by its bearer, rather than a government-issued card. Since encrypted files aren’t shared with anyone else, this isn’t really as much of a problem as it might at first appear, but it’s not the only problem.
- If the self-signed certificate’s key becomes corrupted or gets deleted, the files that have been encrypted with it can’t be decrypted. The user can’t request a new certificate as he could do with a CA.
Note:
Because of the danger of data loss in the wake of a lost or corrupted key, you should ensure that all users export their private keys and maintain a copy offline (password protected for security). For better security, you can delete the key from the local system after exporting it. When the key is maintained on the system, an attacker who cracks the user’s password will be able to decrypt the user’s encrypted files. If the key is kept offline, the encrypted files will still be safe in this scenario, although it may present some inconvenience to users to have to import the key each time they want to decrypt their data.
EFS and the PKI
Although self-signed certificates can be used in a domain, the best practice is to only use EFS in a PKI environment. A Windows 2000 or 2003 server can be configured as a certification authority with the certificate services built into the operating system. You can integrate the CA with Active Directory to automate the process of requesting certificates.
Enterprise CAs issue certificates that are based on certificate templates. The templates are stored in Active Directory. They define the attributes of certificates to be issued to users or computers. You can set permissions on certificate templates if you want to prevent some users from obtaining EFS certificates. You may have certain groups of users whom you don’t want to be able to encrypt their data. In that case, you can deny those users Enroll permission on the template and they’ll be unable to obtain an EFS certificate. Users who have enroll permission can request an EFS certificate from the CA using the Certificates MMC snap-in.
It is also possible to use third-party certificates (issued by a CA other than a Windows certificate server) for EFS. The certificates must be Personal Information Exchange (PKCS #12) compliant and must meet several requirements. The third party CA may have to be configured to issue certificates that meet these requirements. For more information about using third-party certificates, see KB article 273856.
“Moving on up” to a PKI
If you have implemented EFS in an environment that doesn’t have a CA, and then you deploy a PKI, you will need to explicitly replace the self-signed certificates that users had been using with CA-issued certificates. Even if the CA issues them a new certificate, by default the self-signed certificate will continue to be used until the user archives the self-signed certificate and requests a new CA-issued certificate by using the cipher command with the /k switch.
EFS in a Domain
Within a Windows forest, users can store encrypted files on remote servers. The remote files must be stored in either network shares or WebDAV folders. To encrypt remote files in a share, the remote server must be trusted for delegation before users can encrypt files on the remote server. This is done via the Active Directory Users and Computers tool. See http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/b742ce99-e53a-4bce-8bc5-f3f3fa89af9d.mspx for instructions. Then, to encrypt a file on the remote server, you need to map a network drive. Remotely encrypting files using a share can only be done in a domain because EFS must use Kerberos delegation to impersonate the user.
It’s important to note that EFS only encrypts data when it’s stored on the disk. It does not encrypt data during transmission over the network. For that purpose, you can use IPsec. Also, if you encrypt a file and then copy or move it to a WebDAV folder, it stays encrypted while in transit.
Problems with EFS in a Domain
There are some potential problems you should be aware of before implementing EFS in a domain. For example, a user only has to have NTFS modify (write) permission to a file to be able to encrypt it. This means that if multiple users have permission to access a file, one of them could encrypt it and make it inaccessible to the others.
Note:
One change in EFS for Windows XP/2003, as compared to Windows 2000, is that encrypted files can be shared among multiple users. All users who share the encrypted file must have an EFS certificate on the computer on which it’s stored.
The EFS domain recovery agent certificate is stored by default on the first domain controller in the domain. It’s important to remember this if you’re considering demoting the DC or if it is in danger of crashing. You should export the private key to avoid a situation where you are unable to decrypt the files if a user’s account is deleted.
The Data Protection API (DPAPI) protects EFS private keys, along with other private credentials in Windows 2000/XP/2003. If a user changes the domain password over a remote access dialup or VPN connection, the DPAPI master key may not be replicated immediately to all domain controllers. This can cause the user to get an Access Denied message when trying to access local encrypted files after making the password change. You can solve this problem by creating a registry value named ProtectionPolicy in
HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb.
Set the value to 1.
Warning:
This registry modification will allow the user to access encrypted files after a remote access password change, but it can also expose the user’s account to the threat of attack.
When implementing EFS in a domain, by default the Administrator of the first domain controller is the recovery agent. You should create new recovery agent accounts and remove the recovery agent role from the Administrator account. The recovery agent account(s) should be used only for that purpose.
If a computer was previously a standalone system and then joins a domain that uses a CA to issue EFS certificates, you might not be able to open files that were encrypted with a self-signed certificate prior to joining the domain. You can access these files by logging off the domain and logging back onto the local computer.
Increasing EFS Security
You can make EFS more secure on Windows XP and Server 2003 systems by configuring EFS to use the 3DES encryption algorithm instead of DESX, the default. You can enable 3DES using Group Policy; this will cause both EFS and IPsec to use 3DES. If you want to use 3DES only for EFS, you have to edit the registry and create a new DWORD value named AlgorithmID in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS
Set the value data to 0x6603 (hex) to enable 3DES for EFS and restart the computer to make the setting take effect.
Note:
Windows 2000 does not support using 3DES for EFS out of the box. However, you can use 3DES with Windows 2000 if you have installed the High Encryption Pack. You can download the High Encryption Pack from the Microsoft Web site at http://www.microsoft.com/windows2000/downloads/recommended/encryption/
You should also be aware of EFS security issues. For example, many applications create temporary files when you’re working. These temp files may not be encrypted. You can fix this by encrypting the folder in which the application stores its temp files; then files placed in that folder will automatically be encrypted.
Also be aware that an application may copy the contents of an encrypted file to the paging file during use. The paging file can’t be encrypted because it’s a system file. Data can remain in the paging file even after the application closes the file, and an unauthorized person could start the computer with a different operating system and read the contents of the paging file. To prevent this, you can configure the local Group Policy to clear the contents of the paging file at shutdown. This is done by enabling the Shutdown: Clear Virtual Memory Pagefile policy under Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.
