Encrypting File System: Difference between revisions
No edit summary |
m added link to disk encryption |
||
| Line 26: | Line 26: | ||
Anyone with administrator permissions can set himself as recovery agent. This is very serious issue, since an attacker can simply break the administrator account (using third party tools), set administrator as recovery agent and wait. When users sign in, their private keys are automatically encrypted to the administrator's public key. The attacker only needs to access the computer once again as administrator to gain full access to all EFS-encrypted files. Even using SYSKEY mode2 or 3 does not protect against the attack, because the attacker can bypass SYSKEY and gain admin access and create new keys for admin and restore syskey back to use and wait for user to sign in. Of course, if the attacker can gain physical access to the computer, you might consider all security features to be irrelevant, because he could also install rootkits, software or even hardware keyloggers etc. to the computer anyway. |
Anyone with administrator permissions can set himself as recovery agent. This is very serious issue, since an attacker can simply break the administrator account (using third party tools), set administrator as recovery agent and wait. When users sign in, their private keys are automatically encrypted to the administrator's public key. The attacker only needs to access the computer once again as administrator to gain full access to all EFS-encrypted files. Even using SYSKEY mode2 or 3 does not protect against the attack, because the attacker can bypass SYSKEY and gain admin access and create new keys for admin and restore syskey back to use and wait for user to sign in. Of course, if the attacker can gain physical access to the computer, you might consider all security features to be irrelevant, because he could also install rootkits, software or even hardware keyloggers etc. to the computer anyway. |
||
==See Also== |
|||
* [[Disk encryption]] |
|||
==External links== |
==External links== |
||
Revision as of 19:15, 24 June 2006
- This article is about the Microsoft Windows file system, for the old IRIX file system, see EFS (IRIX).
The EFS or Encrypting File System is a file system available in Microsoft's Windows 2000, Windows XP Professional Edition, Windows Server 2003, and now Windows Media Center 2005 operating systems. The technology transparently allows files to be stored encrypted on NTFS file systems to protect confidential data from attackers with physical access to the computer.
User authentication and access control lists can protect files from unauthorized access while the operating system is running, but are easily circumvented if an attacker gains physical access to the computer. A solution is to store the files encrypted on the disks of the computer. EFS does this using public key cryptography, and aims to ensure that decrypting the files is practically impossible without the correct key. However, EFS does not prevent brute-force attacks against the user account passwords. In other words, file encryption doesn't provide much protection if the account password is easily guessed.
Operation
Files and folders that are to be encrypted by the file system must be marked with an encryption attribute. As with file permissions in NTFS, if a folder is marked for encryption then by default all files and subfolders that exist in the folder are also encrypted. When files are copied to another volume that is formatted with another file system (for instance FAT32) then the files and/or folders are decrypted before copying them over to that file system. The only exception is when files are backed up, in which case the files are not decrypted.
EFS works by encrypting a file with a bulk symmetric key (also known as the File Encryption Key, or FEK), which is used because it takes a relatively smaller amount of time to encrypt and decrypt large amounts of data than if an asymmetric key cipher is used. The symmetric key that is used to encrypt the file is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted data is stored in the header of the encrypted file. To decrypt the file, the file system uses the private key of the user to decrypt the symmetric key that is stored in the file header. It then uses the symmetric key to decrypt the file. Because this is done at the file system level, it is transparent to the user.
Security
There are two important security holes in Windows 2000 EFS.
First, in Windows 2000, the administrator is by default the recovery agent, capable of decrypting all files encrypted in EFS. Win2k cannot function without recovery agent, so basically there is always someone who can decrypt encrypted files of the users. In Windows XP and on, there are no default recovery agents and no need to have one. Setting SYSKEY to mode2 or higher (syskey typed in during bootup or stored in floppy) will prevent this attack, since the private keys will be stored in encrypted SAM file that attacker cannot decrypt, because he cannot know the SYSKEY passphrase/keyfile.
Second, in Win2k, the private key is not stored in "truly" encrypted form. If attacker can get physical access to the computer and reset users passphrases (with, for example, third party tools), he can login as that user (or recovery agent) and gain access to private key and decrypt all files. In Windows XP and on, the private key is encrypted using the hash of the users passphrase and username, and therefore it is impossible to recover the private key without knowing the users passphrase. Also, again, setting SYSKEY to mode2 or higher (syskey typed in during bootup or stored in floppy) will prevent this attack, since the private keys will be stored in encrypted SAM file that hacker cannot decrypt, because he cannot know the SYSKEY passphrase/keyfile.
Other issues to consider regarding EFS security:
Windows can store plaintext versions of user passphrases, it also can and will store, by default, the passphrases in LM hash, which can be attacked and broken relatively easily. It also stores passphrases in NTLM hash, which can be attacked using "rainbow tables". To defeat these attacks, Windows needs to be configured (from security policy) to never store or send LM/NTLM hashes or plaintext passwords, and, of course, to turn off automatic login (which stores passphrases in registry). Also, using passphrases over 14 marks long prevents the LM hash being recorded and makes attacks against NTLM hash harder. Of course, if you consider the fact that EFS uses Triple DES or AES to encrypt files, you should use proper passphrase lengths (over 20 marks long) anyway.
When encrypting files with EFS, the plaintext files are not wiped, but simply deleted. This means that they can be easily recovered, unless they are overwritten. To properly use EFS, you should mark complete folders as EFS encrypted (so that all temporary files like Word document backups too are encrypted), and when you wish to encrypt particular files, copy them to that folder, and then securely wipe the plaintext versions. You can use Windows Cipher Utility to wipe files, folders or free space, or a third-party utility.
Anyone with administrator permissions can set himself as recovery agent. This is very serious issue, since an attacker can simply break the administrator account (using third party tools), set administrator as recovery agent and wait. When users sign in, their private keys are automatically encrypted to the administrator's public key. The attacker only needs to access the computer once again as administrator to gain full access to all EFS-encrypted files. Even using SYSKEY mode2 or 3 does not protect against the attack, because the attacker can bypass SYSKEY and gain admin access and create new keys for admin and restore syskey back to use and wait for user to sign in. Of course, if the attacker can gain physical access to the computer, you might consider all security features to be irrelevant, because he could also install rootkits, software or even hardware keyloggers etc. to the computer anyway.