- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
How Secure Is Encrypted File System?
In Windows 2000, Microsoft introduced Encrypted File System (EFS) -- a new feature built into the operating system that makes securing user files much better than just file system permissions that have been available on NTFS partitions in previous versions of Windows. In Windows 2000, Microsoft introduced Encrypted File System, a feature that offers a better way to secure user files than the file system permissions available on NTFS partitions in previous versions of Windows. This article discusses various considerations to keep in mind when deploying Encrypted File System in a Windows 2000/XP Professional environment.
The main reason for this enhancement is that NTFS security can be easily circumvented once an attacker gains physical access to the computer. A number of readily available third-party tools can be used to provide read and write access to data stored on NTFS partitions by circumventing protection provided by the operating system. Once the system is booted from a floppy containing the third-party NTFS driver, the disk and all of its data becomes easily accessible.
Although you can password protect the BIOS and restrict which devices are bootable, this still does not prevent someone from removing the hard drive, attaching it to another computer, and accessing it via another Windows 2000/XP installation or installing another instance of Windows altogether. Fortunately, EFS can help provide privacy of your data in such scenarios.
EFS uses the combination of symmetrical and public/private key encryption to secure content designated by the user in files residing on NTFS partitions. The symmetrical key (created dynamically at the time of encryption and different for each encrypted file) is used to perform the encryption process and is stored together with the encrypted file. The public key is used for encryption of the symmetrical key and is also stored along with the encrypted file. The private key, necessary for decryption, resides within the user profile. This way the information stored on the hard drive, although still accessible via third-party utilities, is in an unreadable format and therefore useless without the private key.
There are, however, still some possible security issues with the EFS that users should be aware of:
- Encrypted files are accessible to anyone who possesses a private key, which is used to retrieve the symmetrical key encrypted with a public key (from the same key pair that the private key belongs to). This applies to the user who encrypted these files and to another Windows account, designated as Data Recovery Agent (DRA). By default, on Windows 2000, this is the Administrator account (local Administrator on stand-alone systems and domain Administrator in the domain). Since it is possible to use third-party tools to reset the password of the local Administrator or any other local account (providing physical access to the target computer is available), stand-alone systems are inherently insecure.
- While in the Windows 2000 domain environment, resetting the local Administrator password will not impact the security of the computer's local files protected by EFS; however, the users' private keys might be compromised as long as they are available on the local computer. Since environments in which EFS is implemented typically rely on roaming profiles (this ensures that the same private key is used across all encrypted files for the same user), the user profile is copied to the local system during every login. To ensure that attackers will not be able to take advantage of copies of private keys stored in these profiles, you should use Group Policy to force the removal of roaming profiles at logoff. You should also designate a dedicated Disaster Recovery Agent account and ensure that its private key has been backed up and stored in a safe location.
Both problems described above have been eliminated on Windows XP Professional systems due to two changes to the EFS implementation:
- There is no longer default DRA. Also, unlike in Windows 2000, DRA is no longer necessary for the EFS to function. Administrators of Windows 2000 environments should keep this in mind. It was possible to prevent encryption the Windows 2000 domain environment on the domain level by initializing Empty Policy for Encrypted Data Recovery Agents. This was done by launching a Group Policy MMC snap-in, selecting group policy object linked to your domain, drilling down to Computer Configuration->Windows Settings->Security Settings->Public Key Policies->Encrypted Data Recovery Agents, right clicking on the last-level folder labeled Encrypted Data Recovery Agents, and selecting Initialize Empty Policy from the context-sensitive menu. This was sufficient to remove the capability to use EFS from users on any Windows 2000 system that is a member of the domain.
With Windows XP, this is no longer possible. To disable EFS on the domain level in an environment where Windows XP computers are used, you must launch Microsoft Management Console from a Windows XP Professional computer that was a member of the domain, load Group Policy Editor, and set the focus to the domain Group Policy object. Once the snap-in is loaded, drill down to Computer Configuration->Windows Settings->Security Settings->Public Key Policies->Encrypting File System folder, right click on it, and select Properties from the context-sensitive menu. After the dialog box with a single checkbox "Allow users to encrypt files using Encrypting File System (EFS)" is displayed, make sure that you clear the checkbox (which is checked on by default).
- EFS introduces another additional level of encryption, which utilizes the user's password to secure the private key residing in user's profile. On the one hand, this prevents a situation in which an attacker resets the password on any local account in an attempt to gain access to EFS encrypted files (since once the password is reset, the private key stored in the profile can no longer be used). On the other, it creates a problem if users forget their passwords (hence the need to ensure password recovery by using Password Recovery disk).
As you can see, a number of considerations must be kept in mind when deploying EFS in a Windows 2000/XP Professional environment. Increased security has its price in terms of administrative overhead, but it is well worth the extra effort in the long run.