Encrypting File System

From Wikipedia, the free encyclopedia

Jump to: navigation, search

The Encrypting File System (EFS) is a file system driver that provides filesystem-level encryption in Microsoft Windows (98 and later) operating systems, except Windows XP Home Edition, Windows Vista Basic, and Windows Vista Home Premium. The technology enables files to be transparently 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. One 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 extremely difficult without the correct key. However, EFS is in practice susceptible to brute-force attacks against the user account passwords. In other words, encryption of files is only as strong as the password to unlock the decryption key.

Contents

[edit] Operation

EFS works by encrypting a file with a bulk symmetric key, also known as the File Encryption Key, or FEK. It uses a symmetric encryption algorithm 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 encryption algorithm used will vary depending on the version and configuration of the operating system; see Algorithms Used by Operating System Version below. The FEK (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 FEK is stored in the $EFS alternate data stream of the encrypted file. To decrypt the file, the EFS component driver uses the private key that matches the EFS digital certificate (used to encrypt the file) to decrypt the symmetric key that is stored in the $EFS stream. The EFS component driver then uses the symmetric key to decrypt the file. Because the encryption & decryption operations are performed at a layer below NTFS, it is transparent to the user and all their applications.

Folders whose contents are to be encrypted by the file system are marked with an encryption attribute. The EFS component driver treats this encryption attribute in a way that is analogous to the inheritance of file permissions in NTFS: if a folder is marked for encryption, then by default all files and subfolders that are created under the folder are also encrypted. When encrypted files are moved within an NTFS volume, the files remain encrypted. However, there are a number of occasions in which the file could be decrypted without the user explicitly asking Windows to do so.

Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32. Finally, when encrypted files are copied over the network using the SMB/CIFS protocol, the files are decrypted before they are sent over the network.

The most significant way of preventing the decryption-on-copy is using backup applications that are aware of the "Raw" APIs. Backup applications that have implemented these Raw APIs will simply copy the encrypted file stream and the $EFS alternate data stream as a single file. In other words, the files are "copied" (e.g. into the backup file) in encrypted form, and are not decrypted during backup.

Starting with Windows Vista, a user's private key can be stored on a smart card; Data Recovery Agent (DRA) keys can also be stored on a smart card.[1]

[edit] Security

There are two significant security vulnerabilities in Windows 2000 EFS.

[edit] Decrypting files using the local Administrator account

In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user. EFS in Windows 2000 cannot function without a recovery agent, so there is always someone who can decrypt encrypted files of the users. Any non-domain-joined Windows 2000 computer will be susceptible to unauthorized EFS decryption by anyone who can take over the local Administrator account, which is trivial given many tools available freely on the Internet.[2]

In Windows XP and later, there is no default local Data Recovery Agent and no requirement to have one. Setting SYSKEY to mode 2 or 3 (syskey typed in during bootup or stored on a floppy disk) will mitigate the risk of unauthorized decryption through the local Administrator account. This is because the local user's password hashes, stored in the SAM file, are encrypted with the Syskey, and the Syskey value is not available to an offline attacker who does not possess the Syskey passphrase/floppy.

[edit] Accessing private key via password reset

In Windows 2000, the user's RSA private key is not only stored in a truly encrypted form, but there is also a backup of the user's RSA private key that is more weakly protected. If an attacker gains physical access to the Windows 2000 computer and resets a local user account's password[2], the attacker can log in as that user (or recovery agent) and gain access to the RSA private key which can decrypt all files. This is because the backup of the user's RSA private key is encrypted with an LSA secret, which is accessible to any attacker who can elevate their login to LocalSystem (again, trivial given numerous tools on the Internet).

In Windows XP and beyond, the user's RSA private key is backed up using an offline public key whose matching private key is stored in one of two places: the password reset disk (if Windows XP is not a member of a domain) or in the Active Directory (if Windows XP is a member of a domain). This means that an attacker who can authenticate to Windows XP as LocalSystem still does not have access to a decryption key stored on the PC's hard drive.

In Windows 2000, XP or later, the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name - use of a salted hash makes it extremely difficult to reverse the process and recover the private key without knowing the user's passphrase. Also, again, setting Syskey to mode 2 or 3 (Syskey typed in during bootup or stored on a floppy disk) will mitigate this attack, since the local user's password hash will be stored encrypted in the SAM file,

[edit] Other issues

Windows can store plaintext versions of user account passphrases, though this is no longer default behaviour; it also can store (and will by default on Windows XP and lower) the local user account passphrases in LM hash, which can be attacked and broken relatively easily. It also stores local user account passphrases as NTLM hashes, which can be fairly easily attacked using "rainbow tables". To mitigate the threat of trivial brute-force attacks on local passphrases, Windows needs to be configured (using the Security Settings portion of Group Policy) to never store LM hashes, and of course, to turn off Autologon (which stores plaintext passphrases in the registry). Further, using local user account passphrases over 14 characters long prevents Windows from storing an LM hash in the SAM - and has the added benefit of making brute-force attacks against the 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 characters long) to achieve equivalent strength against brute-force attacks.

When encrypting files with EFS - when converting plaintext files to encrypted files - the plaintext files are not wiped, but simply deleted. This means that they can be easily recovered unless they are overwritten. To fully mitigate known, non-challenging technical attacks against EFS, you should configure encryption at the folder level (so that all temporary files like Word document backups which are created in these directories are also encrypted). When you wish to encrypt individual files, copy them to an encrypted folder or encrypt the file "in place", and then securely wipe the disk volume. You can use the Windows Cipher utility (with the /W option) to wipe free space including that which still contains deleted plaintext files; various third-party utilities may work as well.

Anyone that can gain Administrators access can overwrite, override or change the Data Recovery Agent configuration. This is a very serious issue, since an attacker can for example hack the Administrator account (using third-party tools), set whatever DRA certificate they want as the Data Recovery Agent and wait. This is sometimes referred to as a two-stage attack, which is a significantly different scenario than the risk due to a lost or stolen PC, but which highlights the risk due to malicious insiders.

When the user encrypts files after the first stage of such an attack, the FEKs are automatically encrypted with the designated DRA's public key. The attacker only needs to access the computer once more as Administrator to gain full access to all those subsequently EFS-encrypted files. Even using Syskey mode 2 or 3 does not protect against this attack, because the attacker could back up the encrypted files offline, restore them elsewhere and use the DRA's private key to decrypt the files. Of course, if such a malicious insider 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. on the computer - which is potentially much more interesting and effective than overwriting DRA policy.

[edit] Recovery

Files encrypted with EFS can only be decrypted by using the RSA private key(s) matching the previously-used public key(s). The stored copy of the user's private key is ultimately protected by the user's logon password. Accessing encrypted files from outside Windows with other operating systems (Linux, for example, or even another instance of Windows) is not possible — not least of which because there is currently no third party EFS component driver. Further, using special tools to reset the user's login password will render it impossible to decrypt the user's private key and thus useless for gaining access to the user's encrypted files. The significance of this is occasionally lost on users, resulting in data loss if a user forgets his or her password, or fails to back up the encryption key. This led to coining of the term "delayed recycle bin", to describe the seeming inevitability of data loss if an inexperienced user encrypts his or her files.

If EFS is configured to use keys issued by a Public Key Infrastructure and the PKI is configured to enable Key Archival and Recovery, encrypted files can be recovered by recovering the private key first.

[edit] Keys

  • user password (or smart card private key): used to generate a decryption key to decrypt the user's DPAPI Master Key
  • DPAPI Master Key: used to decrypt the user's RSA private key(s)
  • RSA private key: used to decrypt each file's FEK
  • File Encryption Key (FEK): used to decrypt/encrypt each file's data (in the primary NTFS stream)
  • SYSKEY: used to encrypt the cached domain verifier and the password hashes stored in the SAM

[edit] Supported Operating Systems

[edit] New Features available by OS version

  • Windows XP:
    • encryption of the Client-Side Cache
    • protection of DPAPI Master Key backup using domain-wide public key
    • autoenrollment of user certificates (including EFS certificates)
    • multiple-user (shared) access to encrypted files (on a file-by-file basis)
  • Windows XP SP1: support for and default use of AES-256 symmetric encryption algorithm for all EFS-encrypted files
  • Windows XP SP2 + KB 912761: prevent enrollment of self-signed EFS certificates
  • Windows Server 2003:
    • DIMS
    • enforcement of RSAKeyLength setting for enforcing a minimum key length when enrolling self-signed EFS certificates
  • Windows Vista[3] and Windows Server 2008[4][5]:
    • per-user encryption of Client-Side Cache (offline files)
    • support for storing (user or DRA) RSA private keys on a PC/SC smart card
    • EFS Re-Key Wizard
    • EFS Key backup prompts
    • support for deriving DPAPI Master Key from PC/SC smart card
    • support for encryption of pagefile.sys
    • protection of EFS-related secrets using BitLocker (Enterprise or Ultimate edition of Windows Vista)[6][7]
    • Group Policy controls to enforce:
      • encryption of Documents folder
      • offline files encryption
      • indexing of encrypted files
      • requiring smart card for EFS
      • creating a caching-capable user key from smart card
      • displaying a key backup notification when a user key is created or changed
      • specifying the certificate template used for enrolling EFS certificates automatically
  • Windows Server 2008[8]:
    • EFS self-signed certificates enrolled on the Windows Server 2008 server will default to 2048-bit RSA key length
    • all EFS templates (user and data recovery agent certificates) default to 2048-bit RSA key length

[edit] Algorithms Used by Operating System version

Windows EFS supports a range of symmetric encryption algorithms, depending on the version of Windows in use when the files are encrypted:

Operating System Default Algorithm Other Algorithms
Windows 2000 DESX (none)
Windows XP RTM DESX 3DES
Windows XP SP1 AES 3DES, DESX
Windows Server 2003 AES 3DES, DESX
Windows Vista AES 3DES, DESX
Windows Server 2008 AES 3DES, DESX (?)

[edit] See also

Cryptography portal

[edit] References

  1. ^ Chris Corio (May 2006). "First Look: New Security Features in Windows Vista". TechNet Magazine. Microsoft. http://www.microsoft.com/technet/technetmag/issues/2006/05/FirstLook/. Retrieved on 2006-11-06. 
  2. ^ a b ntpasswd, available since 1997
  3. ^ Kim Mikkelsen (2006-09-05). "Windows Vista Session 31: Rights Management Services and Encrypting File System" (PDF). presentation. Microsoft. http://download.microsoft.com/download/e/b/a/ebafefc9-4b64-4816-8778-9fb33c8c43d9/31_Rights_Management_og_Encrypting_File_Systems.pdf. Retrieved on 2007-10-02. 
  4. ^ "Encrypting File System". documentation. Microsoft. 2007-04-30. http://technet2.microsoft.com/windowsserver2008/en/library/69f04dd7-bced-4079-84e9-095b8dc563991033.mspx?mfr=true. Retrieved on 2007-11-06. 
  5. ^ "Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008: Encrypting File System". documentation. Microsoft. 2007-09-01. http://technet2.microsoft.com/windowsserver2008/en/library/f843023b-bedd-40dd-9e5b-f1619eebf7821033.mspx?mfr=true. Retrieved on 2007-11-06. 
  6. ^ Scott Field (June 2006). "Microsoft Windows Vista Security Enhancements" (DOC). whitepaper. Microsoft. http://download.microsoft.com/documents/uk/msdn/events/Windows_Vista_Security_WP.doc. Retrieved on 2007-06-14. 
  7. ^ Microsoft Corporation (2006-11-30). "Data Communication Protocol". patent. Microsoft. http://www.freepatentsonline.com/20060271697.html. Retrieved on 2007-06-14. 
  8. ^ "Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008: Encrypting File System". documentation. Microsoft. 2007-09-01. http://technet2.microsoft.com/windowsserver2008/en/library/f843023b-bedd-40dd-9e5b-f1619eebf7821033.mspx?mfr=true. Retrieved on 2007-11-06. 

[edit] External links

v • d • e
Windows components
Core
Management
tools
Applications
Games
Kernel
Services
File systems
Server
Architecture
Security
Compatibility
Retrieved from "http://en.wikipedia.org/wiki/Encrypting_File_System"
Personal tools