The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS [1] that provides filesystem-level encryption. The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.
EFS is available in all versions of Windows except the home versions (see Supported operating systems below) from Windows 2000 onwards. [2] By default, no files are encrypted, but encryption can be enabled by users on a per-file, per-directory, or per-drive basis. Some EFS settings can also be mandated via Group Policy in Windows domain environments. [3]
Cryptographic file system implementations for other operating systems are available, but the Microsoft EFS is not compatible with any of them. [4] See also the list of cryptographic file systems.
When an operating system is running on a system without file encryption, access to files normally goes through OS-controlled user authentication and access control lists. However, if an attacker gains physical access to the computer, this barrier can be easily circumvented. One way, for example, would be to remove the disk and put it in another computer with an OS installed that can read the filesystem; another, would be to simply reboot the computer from a boot CD containing an OS that is suitable for accessing the local filesystem.
The most widely accepted solution to this is to store the files encrypted on the physical media (disks, USB pen drives, tapes, CDs and so on).
In the Microsoft Windows family of operating systems EFS enables this measure, although on NTFS drives only, and does so using a combination of public key cryptography and symmetric key cryptography to make decrypting the files extremely difficult without the correct key.
However, the cryptography keys for EFS are in practice protected by the user account password, and are therefore susceptible to most password attacks. In other words, the encryption of a file is only as strong as the password to unlock the decryption key.
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 less 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 Windows 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 alternative data stream of the encrypted file. [5] 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 alternative 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. [6]
Two significant security vulnerabilities existed in Windows 2000 EFS, and have been variously targeted since.
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. [7]
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.
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, [7] 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.
Once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication, decryption happens transparently. Thus, any compromise of the user's password automatically leads to access to that data. Windows can store versions of user account passphrases with reversible encryption, though this is no longer default behaviour; it can also be configured to store (and will by default on the original version of Windows XP and lower) Lan Manager hashes of the local user account passphrases, which can be attacked and broken easily. It also stores local user account passphrases as NTLM hashes, which can be fairly easily attacked using "rainbow tables" if the passwords are weak (Windows Vista and later versions don't allow weak passwords by default). To mitigate the threat of trivial brute-force attacks on local passphrases, older versions of Windows need to be configured (using the Security Settings portion of Group Policy) to never store LM hashes, and of course, to not enable 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.
When encrypting files with EFS – when converting plaintext files to encrypted files – the plaintext files are not wiped, but simply deleted (i.e. data blocks flagged as "not in use" in the filesystem). This means that, unless they for example happen to be stored on an SSD with TRIM support, they can be easily recovered unless they are overwritten. To fully mitigate known, non-challenging technical attacks against EFS, encryption should be configured at the folder level (so that all temporary files like Word document backups which are created in these directories are also encrypted). When encrypting individual files, they should be copied to an encrypted folder or encrypted "in place", followed by securely wiping the disk volume. The Windows Cipher utility can be used (with the /W option) to wipe free space including that which still contains deleted plaintext files; various third-party utilities may work as well. [8]
Anyone who 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. If such a malicious insider can gain physical access to the computer, all security features are to be considered irrelevant, because they 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.
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) 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.
No other operating systems or file systems have native support for EFS.
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 | Triple DES |
Windows XP SP1 | AES | Triple DES, DESX |
Windows Server 2003 | AES | Triple DES, DESX [16] |
Windows Vista | AES | Triple DES, DESX |
Windows Server 2008 | AES | Triple DES, DESX (?) |
Windows 7 Windows Server 2008 R2 | Mixed (AES, SHA, and ECC) | Triple DES, DESX |
Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.
New Technology File System (NTFS) is a proprietary journaling file system developed by Microsoft. Starting with Windows NT 3.1, it is the default file system of the Windows NT family. It superseded File Allocation Table (FAT) as the preferred filesystem on Windows and is supported in Linux and BSD as well. NTFS reading and writing support is provided using a free and open-source kernel implementation known as NTFS3 in Linux and the NTFS-3G driver in BSD. By using the convert
command, Windows can convert FAT32/16/12 into NTFS without the need to rewrite all files. NTFS uses several files typically hidden from the user to store metadata about other files stored on the drive which can help improve speed and performance when reading data. Unlike FAT and High Performance File System (HPFS), NTFS supports access control lists (ACLs), filesystem encryption, transparent compression, sparse files and file system journaling. NTFS also supports shadow copy to allow backups of a system while it is running, but the functionality of the shadow copies varies between different versions of Windows.
A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic data. Based on the used method, the key can be different sizes and varieties, but in all cases, the strength of the encryption relies on the security of the key being maintained. A key's security strength is dependent on its algorithm, the size of the key, the generation of the key, and the process of key exchange.
Hushmail is an encrypted proprietary web-based email service offering PGP-encrypted e-mail and vanity domain service. Hushmail uses OpenPGP standards. If public encryption keys are available to both recipient and sender, Hushmail can convey authenticated, encrypted messages in both directions. For recipients for whom no public key is available, Hushmail will allow a message to be encrypted by a password and stored for pickup by the recipient, or the message can be sent in cleartext. In July, 2016, the company launched an iOS app that offers end-to-end encryption and full integration with the webmail settings. The company is located in Vancouver, British Columbia, Canada.
FileVault is a disk encryption program in Mac OS X 10.3 Panther (2003) and later. It performs on-the-fly encryption with volumes on Mac computers.
The SAM Lock Tool, better known as Syskey, is a discontinued component of Windows NT that encrypts the Security Account Manager (SAM) database using a 128-bit RC4 encryption key.
The Security Account Manager (SAM) is a database file in Windows XP, Windows Vista, Windows 7, 8.1, 10 and 11 that stores users' passwords. It can be used to authenticate local and remote users. Beginning with Windows 2000 SP4, Active Directory authenticates remote users. SAM uses cryptographic measures to prevent unauthenticated users accessing the system.
LAN Manager is a discontinued network operating system (NOS) available from multiple vendors and developed by Microsoft in cooperation with 3Com Corporation. It was designed to succeed 3Com's 3+Share network server software which ran atop a heavily modified version of MS-DOS.
Ransomware is a type of cryptovirological malware that permanently block access to the victim's personal data unless a ransom is paid. While some simple ransomware may lock the system without damaging any files, more advanced malware uses a technique called cryptoviral extortion. It encrypts the victim's files, making them inaccessible, and demands a ransom payment to decrypt them. In a properly implemented cryptoviral extortion attack, recovering the files without the decryption key is an intractable problem, and difficult to trace digital currencies such as paysafecard or Bitcoin and other cryptocurrencies are used for the ransoms, making tracing and prosecuting the perpetrators difficult.
BitLocker is a full volume encryption feature included with Microsoft Windows versions starting with Windows Vista. It is designed to protect data by providing encryption for entire volumes. By default, it uses the Advanced Encryption Standard (AES) algorithm in cipher block chaining (CBC) or "xor–encrypt–xor (XEX)-based Tweaked codebook mode with ciphertext Stealing" (XTS) mode with a 128-bit or 256-bit key. CBC is not used over the whole disk; it is applied to each individual sector.
Data Protection Application Programming Interface (DPAPI) is a simple cryptographic application programming interface available as a built-in component in Windows 2000 and later versions of Microsoft Windows operating systems. In theory, the Data Protection API can enable symmetric encryption of any kind of data; in practice, its primary use in the Windows operating system is to perform symmetric encryption of asymmetric private keys, using a user or system secret as a significant contribution of entropy. A detailed analysis of DPAPI inner-workings was published in 2011 by Bursztein et al.
The Linux Unified Key Setup (LUKS) is a disk encryption specification created by Clemens Fruhwirth in 2004 and originally intended for Linux.
Disk encryption is a technology which protects information by converting it into code that cannot be deciphered easily by unauthorized people or processes. Disk encryption uses disk encryption software or hardware to encrypt every bit of data that goes on a disk or disk volume. It is used to prevent unauthorized access to data storage.
There are a number of security and safety features new to Windows Vista, most of which are not available in any prior Microsoft Windows operating system release.
This is a technical feature comparison of different disk encryption software.
There are various implementations of the Advanced Encryption Standard, also known as Rijndael.
Database encryption can generally be defined as a process that uses an algorithm to transform data stored in a database into "cipher text" that is incomprehensible without first being decrypted. It can therefore be said that the purpose of database encryption is to protect the data stored in a database from being accessed by individuals with potentially "malicious" intentions. The act of encrypting a database also reduces the incentive for individuals to hack the aforementioned database as "meaningless" encrypted data is of little to no use for hackers. There are multiple techniques and technologies available for database encryption, the most important of which will be detailed in this article.
Linux.Encoder is considered to be the first ransomware Trojan targeting computers running Linux. There are additional variants of this Trojan that target other Unix and Unix-like systems. Discovered on November 5, 2015, by Dr. Web, this malware affected at least tens of Linux users.
KeRanger is a ransomware trojan horse targeting computers running macOS. Discovered on March 4, 2016, by Palo Alto Networks, it affected more than 7,000 Mac users.
This article's use of external links may not follow Wikipedia's policies or guidelines.(March 2020) |