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 FAT The most significant way of preventing the decryption-on-copy is using backup applications that are aware of the "Raw" APIs.
In other words, the files are "copied" e. Two significant security vulnerabilities existed in Windows EFS, and have been variously targeted since. In Windows , the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user.
EFS in Windows cannot function without a recovery agent, so there is always someone who can decrypt encrypted files of the users. Any non-domain-joined Windows 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. 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.
In Windows , 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 computer and resets a local user account's password [5] , 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 , 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. 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. Of course, if you consider the fact that EFS uses Triple DES or AES to encrypt files, you should use proper passphrases 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. It only takes one unscrupulous or disgruntled employee to hand a drive over to your competition to destroy your company. Applications typically create temporary files containing at least portions of a document, and if these files are not protected by encryption, they pose a security risk.
So, rather than look to solutions that provide file-by-file encryption or encrypting individual files with EFS, you need a solution that can automatically encrypt and decrypt files in an entire folder or volume. EFS does just that. In addition, EFS does nothing the encrypt network traffic, so when a user accesses encrypted files from a server or transfers encrypted files from his workstation to another computer, those files are sent unencrypted across the network and are therefore subject to the same security risks as unencrypted files.
If you need the highest possible security for your data and added security for network transfers, implement a network encryption mechanism such as IPSec in addition to EFS. Using a unique encryption key for each file provides an excellent level of security and makes it extremely difficult to break the encryption on an entire volume or even a single folder.
Brute force attempts would eventually succeed on a single file, but the time required to decrypt a large amount of data would be impractically large. You should also configure policies to prevent the last logon account from appearing in the logon dialog box, which would otherwise give the thief a significant leg up on cracking into the system.
Out of the box, Windows provides the ability to encrypt and decrypt files. EFS automatically generates a bulk symmetric encryption key and encrypts the file using that key. The DRF can contain data for multiple recovery agents. If you encrypt a folder, the folder will no longer be compressed and the same is true for individual files.
If you compress an encrypted folder, it will no longer be encrypted. So, you can encrypt a folder or compress it, but not both. When you click OK, Windows asks if you want to apply the change only to the folder or to the child objects as well. If you apply the change only to the folder, any items already encrypted in the folder remain encrypted, but new items you add are not encrypted.
If you choose to apply the change to all child objects, all child objects are decrypted. For example, you might need to incorporate encryption or decryption tasks in a batch file or even a logon script. This option sets the encryption attribute for the folder. This clears the encryption attribute, and new files are not encrypted, but existing encrypted child objects are unaffected.
Objects already encrypted are skipped by default. All other options are ignored if any are specified in conjunction with this switch. Use the CIPHER command without any parameters or switches to view the current encryption state of files in the current folder or in the folder specified by the pathname parameter.
Copy a compressed file to an uncompressed folder, for example, and the copy of the file is not compressed. Encryption works similarly with a few differences. Windows uses the encryption attribute of the target folder to determine how to process the file.
When you copy or move encrypted files to another computer, those folders and files are encrypted only if the other computer supports encryption. The target volume must be NTFS, and the domain or local security policy affecting the target computer must allow encryption. When you copy or move unencrypted folders or files to encrypted volumes or folders, Windows encrypts the folders and files.
This occurs for both local and remote operations.
0コメント