In Windows XP Professional there is a function which utilizes the Encrypting File System (EFS) of NTFS. It is not usable in Windows XP Home Edition. Using it is very simple, with selecting "Encrypt contents to secure data" checkbox in the "Advanced Attributes" dialog box which appears when clicking "Advanced" button in the "General" tab of Properties dialog box of any folder. After that, any file stored in the folder is encrypted automatically. The file names of encrypted files appear green in Explorer (which can be disabled by "folder option"). However the encrypting function cannot be applicable with compressing function of NTFS simultaneously (they are exclusive). For the user who encrypted the files there is nothing different with normal files and encrypted files. No password is necessary when using them.
< Note > Because folder structure and file names are not encrypted, you should be careful not to include sensitive information in them. For example, you should not use a secret customer's name on any file. Since there is no idea of encryption on folder structure, the checkbox of encryption in the properties dialog box of a folder simply sets encoding flag that indicates automatic encryption of any file which is stored in it. Because of this, when the other user who has access permission to the folder puts a file in it, the file becomes an encrypting file of that user. Encrypted files remain encrypted even when moved or copied to another folder or volume as far as they are formatted with NTFS. Unless the encrypting flag is set to a folder, there is a risk of cancellation of encrypting of a file in it when the file is edited and saved (in a case the application program deletes the file and makes a file with the same name instead of overwriting the same file).
A file encrypted with EFS is accessible only by the same user who encrypted it in the same system. EFS adds another access restriction from access permission (security) and prohibit anyone from accessing the encrypted files. Therefore, if another user has an access permission of the encrypted file he/she can move or delete it since this is an operation to the folder structure and is not an operation to the file, but cannot read or copy it. Because the encrypted files are recorded on the NTFS volume in encoded format, even if the hard drive is removed and read arbitrarily with the other system, the data become meaningless and cannot recovered. Likewise, if you have reinstalled Windows operating system in the same machine, you cannot access the encrypted files which you encrypted on old system, even if you create a user with the same username and the same logon password. The reason of this is because the encryption key used in encrypting files with EFS is not your logon password. The encryption key used for EFS is created automatically when a user encrypts a file for the first time, but it is unique (one in the world) and never recreated repeatedly. Therefore, if you lose the encryption key, there is no way to recover the encrypted files at all. Your logon password is used to secure the encryption key only by encrypting the encryption key. For this reason, in the case some failure occurred in Windows and you are forced to reinstall it and lost your encryption key, you become inaccessible to your own encrypted files even if you remember your logon password perfectly. Therefore, it is essential to backup (export) your encryption key to a safe place beforehand in order to avoid such miserable situation and the method is offered properly although this necessity is not recognized widely.
EFS uses a combination of symmetric-key cryptography and public-key cryptography. Practically, the file is encrypted with a symmetric key which is generated automatically and the symmetric key which is encrypted by the encrypter's public key and the symmetric key encrypted by the public key of the Data Recovery Agent (DRA) are attached to that file. So anyone who obtained the private key of the encrypter or the private key of the DRA can extract the symmetric key from the file and decrypt that file. Since the automatically generated symmetric key is unique for each file, a symmetric key of a file is not usable to decrypt another file.
< Note > Because the encryptosystem adopted to EFS differs depending upon the version of Windows, be careful to share the encrypted files between different Windows. Windows 2000 and Windows XP prior to SP1 use DESX (an enforced version of DES with 56-bit key length) for common-key cryptography while Windows XP with SP1 or later and Windows Server 2003 use AES (with 256-bit key length) for common-key cryptography. The public-key cryptography is RSA (with 1024-bit key length) for all Windows.
The encrypter's public key and/or private key is called an EFS certificate and the "Usage" of the certificate is displayed by the system as "Encrypting File System".
The DRA's public key and/or private key is called an EFS DRA certificate and the "Usage" of the certificate is displayed by the system as "File Recovery".
These two certificates are used for different purpose and not compatible. Therefore, you must not confuse them. For example, the certificate created by the command cipher.exe with an option /r is a new EFS DRA certificate for adding to the system while the certificate created with an option /x is the current EFS certificate which is used by that user. The term "Data Recovery Agent" does not point a specific user on the system; it indicates a user who imported the private key (certificate) which is the counterpart of the public key (certificate) added to that system as DRA.
There is a very important thing which you should aware of while using EFS. It is that; when you get successful access to an encrypted file by using an EFS DRA certificate, the attached symmetric key encrypted by that EFS DRA certificate is replaced immediately by the symmetric key encrypted by the current system's EFS DRA certificate. Also, when you get successful access to an encrypted file by using an EFS certificate, the attached symmetric key encrypted by that EFS certificate is replaced immediately by the symmetric key encrypted by your current EFS certificate, and the attached symmetric key encrypted by any EFS DRA certificate is replaced immediately by the symmetric key encrypted by the current system's EFS DRA certificate. The replacement occurs not only when you open that file, but when a hidden access by the system occurs for displaying balloon information in Explorer as you point that file without opening it.
This requires utmost caution because there is a case where you can open an encrypted file only once at the best.
For example, assume that you have a PC named PC1 and you have created an EFS DRA certificate and added it to the system as DRA and saved the certificate in a safe place. After that any file encrypted on PC1 has a symmetric key encrypted by that EFS DRA certificate. Also the file has the symmetric key encrypted by the encrypter's EFS certificate too.
Then, assume that Windows of PC1 is damaged and you are forced to reinstall Windows in it; consequently the PC becomes to PC2.
On PC2, regardless of adding any DRA to the system, you should import the old EFS DRA certificate to open the old encrypted files. Of course if you saved the EFS certificate of the encrypter on PC1 beforehand, you can import that EFS certificate. But in this case assume that you have not saved the EFS certificate, so you should import the EFS DRA certificate.
Serious thing occurs here. If you have not added any DRA to the current system, immediately when you open the encrypted file by using the old EFS DRA certificate, the attached symmetric key encrypted by that EFS DRA certificate is deleted completely from that file. And if you close that file unconsciously, you can never open the file forever, because there is no longer any EFS DRA certificate at all on that file; the file has merely an EFS certificate of the encrypter on PC1. In many cases, an access occurs while you are not aware, resulting in that you cannot open the file even once.
(If you have added a DRA to PC2 prior to attempting opening the file, the attached EFS DRA certificate is replaced by the current EFS DRA certificate of PC2 instead of deleting it. So you can re-open the file any times by importing current EFS DRA certificate of PC2. At this moment the file has the current EFS DRA certificate of PC2 and the EFS certificate of the encrypter on PC1. When you are accessing an encrypted file by using EFS DRA certificate, opening, copying or overwriting the file does not replace the EFS certificate of it. Decrypting and re-encrypting the file or opening and saving it as a new file replaces the EFS certificate by your currently using EFS certificate.)
In other words, "When you try to open an encrypted file by importing an EFS DRA certificate on a system which has no DRA, and if you do not have the EFS certificate of the encrypter, you can open it at the first time only at the best." Adding a DRA to the system afterwards is useless because you are not accessible to the file any longer and no EFS DRA certificate can be added.
On the contrary, if you opened the file by importing the EFS certificate of the encrypter on PC1 instead of the PC1's EFS DRA certificate, the file's EFS certificate is replaced by your current EFS certificate, allowing you to open it as many times as you want. Simultaneously, any EFS DRA certificate attached to the file is replaced by the EFS DRA certificate of current system. By the way, if you imported an EFS certificate when you have never encrypted any file and you do not have any EFS certificate, the imported EFS certificate becomes your current EFS certificate. Even when you encrypt a file for the first time afterwards, the EFS certificate is used to encrypt the file and no EFS certificate is created separately.
Therefore, backing up the EFS DRA certificate only is insufficient to prepare for system malfunction. Since the DRA was set to every system with Windows 2000 as default and the Administrator had the EFS DRA certificate, this type of hazards has seldom occurred. In Windows XP, no DRA was set as default, causing many people falling in the trap.
As measure, backing up not only the EFS DRA certificate of the system but also the EFS certificates of all users is strongly recommended. And when you import an EFS DRA certificate, be sure that there is a DRA set on the current system. Also, you should import the EFS DRA certificate of the current system too because in many cases, while you are not aware, an access occurs and the second access becomes necessary.
To make an EFS DRA certificate (a file which contains the private key for a DRA with an extension of .PFX), use cipher.exe with an option /r.
Type
cipher /r:FileNameWithoutExtension
in the command prompt. Then input a password to protect the file twice.
By this execution, you get a .PFX file (a certificate with a private key and a public key for a new DRA) and a .CER file (a certificate with a public key only) in the current working directory. These files are valid for using as EFS DRA certificates only. These files cannot be used as the user's EFS certificate, as they are not related to a specific user. When you import this .PFX file, the "Usage" of it is displayed as "File Recovery".
Of course you have to register this DRA to the system to take effect.
To designate a DRA,
.CER file you have created and select it. Click "Next" and then click "Finish" to complete.If you are administrating multiple PCs, you can use the same EFS DRA certificate to designate DRAs in those systems to avoid maintaining many certificates.
As for the files encrypted before the DRA designation, the EFS DRA certificates of them are not renewed until next access, but you can use the cipher command with an option /u which is available in Windows XP to renew compulsorily. Note that in order to renew, successful access to the files is necessary (access should not be denied). So it is necessary to execute the cipher command by the encrypter. But if there is any DRA designated already in the system and to add another DRA or to replace the DRA, you can renew all the EFS DRA certificates of all encrypted files in the system by importing the old EFS DRA certificate (private key in the .PFX file) first and then execute cipher /u command.
Note that the EFS DRA certificates (a pair of .CER file and .PFX file) generated by cipher /r command are unique and never reproduced. The .PFX file contains a private key and a public key while the .CER file contains only a public key. The private key exists only in the .PFX file and never exists elsewhere. To use the private key of the DRA, you should import the .PFX file. Because the certificates are unique and never reproduced, you should distinguish them each other if you executed the cipher /r command repeatedly. Save the .PFX file in conjunction with the .CER file which is designated as DRA. Saving other .PFX file in error is useless. On the contrary, the EFS certificate (a .PFX file) of the current user produced by executing the cipher command with an option /x is identical even if executed repeatedly. This is because the user's private key is retained in another place.
You should copy the EFS DRA certificates (especially .PFX file) to a removable media and preserve it in a safe place like a vault. In addition, make multiple copies and save them in separate places, as backup is also necessary to the certificates. Also, make sure to delete the .PFX file from the corresponding PCs. This is necessary to reduce a risk of the encrypted files being decrypted in case if the PC is stolen. The .PFX file is a very sensitive file protected only by the password supplied when it is generated, and the password is likely weak in general. If you deleted the .PFX file form the PC, there is no private key of the DRA in that PC. The private key of the DRA should be imported from the file only when it is required, and surely be deleted as soon as the use is accomplished.
Each user's EFS certificate can be produced by using the cipher command with an option /x or using "Export" button of "Personal" tab of "Certificates" section of "Content" tab of the "Internet Options", as described in
When you import this .PFX file, the "Usage" of it is displayed as "Encrypting File System".
You should copy the EFS certificate (.PFX file) to a removable media and preserve it in a safe place like a vault. In addition, make multiple copies and save them in separate places, as backup is also necessary to the certificate. Also, make sure to delete the .PFX file from the PC. This is necessary to reduce a risk of the encrypted files being decrypted in case if the PC is stolen. The .PFX file is a very sensitive file protected only by the password supplied when it is generated, and the password is likely weak in general. Although the user's private key is retained in the "User Profile", encrypted by the user's logon password, absolutely there is no need to increase any risk.
To import a certificate, evoke the "Certificate Import Wizard" by double-clicking the .PFX file or clicking the "Import" button on the "Personal" tab of the "Internet Options". In the wizard, select "Personal" to the certificate store location.
A common way to share data between distant PCs (for example call them PC1 and PC2) is to save the data in a removable media and carry it. There are USB 2.0 interfaced portable 2.5-inch size hard drives with a capacity up to 100 GB, providing a convenient way to carry a large amount of data. But if the portable drive is lost or stolen, a danger of secret leakage occurs.
In such a case, if the portable drive is formatted by NTFS and the data is encrypted by EFS, even when the drive is stolen the data is safe. You can use EFS on USB flash memories by converting them to NTFS by convert.exe command. For example, to convert E: drive to NTFS, type convert E: /FS:NTFS in the command prompt.
When using EFS in such a way, it is necessary that the data is accessible from both PCs. For example, if User1 of PC1 and User2 of PC2 want to share the data, each user should import the other's EFS certificate. That is, User1 imports the EFS certificate which User2 has exported and User2 imports the EFS certificate of User1 reversely. Doing this enables each user to access, read and write any data on the portable drive.
One important thing to take care is that, as described above, when you have a successful access to an encrypted file, the EFS certificate of the file is immediately replaced with the EFS certificate of your own. If User1 of PC1 encrypted a file and then User2 (who has imported User1's EFS certificate) accessed the file, immediately after the access the EFS certificate of the file is replaced by the EFS certificate of User2. Therefore, if the portable drive is conveyed between the PCs many times and accessed by both users many times, there may be some files with User1's EFS certificate and others with User2's EFS certificate. So if one another user want to access the data in the portable drive, the user should import both of the EFS certificates of User1 and User2.
To avoid increasing the number of the certificates, it is required for the certificates of all users to be identical. Unifying the EFS certificates can be achieved by the following method; it is advisable that one of the user has never encrypted a file. The following shows the way to unify the EFS certificate of User2 to that of User1; if User2 has never encrypted a file (that is, the "Personal" tab of User2 is empty from the beginning), it is easy because exporting User2's EFS certificate is unnecessary.
user1.pfx file. Double-clicking the certificate in the "Personal" tab brings a certificate window and the "Details" tab in the window has a list of descriptions. At the end of the list there is a field named "Thumbprint". Click on it and record the value displayed in the lower pane (you can copy it by selecting by mouse and pressing Ctrl-C keys) which consists of 40-digit hexadecimal number.user2.pfx file. The thumbprint should also be recorded.user1.pfx which User1 has exported.user2.pfx file which User2 has exported, import it to User2 again (otherwise User2 cannot decrypt the old encrypted files).cipher /u command and renew all the EFS certificates of old encrypted files to the new EFS certificate that is identical to the User1's EFS certificate. Then User2 can delete the old EFS certificate again from the "Personal" tab. When deleting the EFS certificate, make sure of the certificate with its thumbprint. On the other hand, the thumbprint of the EFS certificate of an encrypted file can be checked by right-clicking on the file and selecting "Properties", clicking "Advanced" button, and clicking "Details" button.Above sequence is useful to migrate encrypted files to a new account of a new machine when you upgraded your PC. Another merit of unifying EFS certificates between PCs is that if any machine got a trouble and it needed EFS certificate, you can get it by exporting from another machine. That is, each PC becomes a backup to others and you can get the certificate even if you cannot immediately access to the vault where you preserved the certificate. Of course, each PC's logon password should be sufficiently long and unguessable under proper administration.
Do not delete your EFS certificate form the "Personal" tab, unless you have exported and saved it to a .PFX file. If you delete it and once logoff, you cannot access your encrypted files forever unless you have designated any DRA to the system. Although a warning message is displayed to you when you attempt to delete your EFS certificate, if you actually deleted the file, never logoff the system. Stay logon, and decrypt all the files you have encrypted right away. Then logoff the system and re-logon it, and then redo encryption. Then a new EFS certificate is created automatically. Although a new EFS certificate can be created by the cipher command with an option /k, do not execute it right after the EFS certificate deletion. Doing so makes all the old private key inaccessible.
Executing cipher /k without deleting EFS certificate creates a new certificate too, but you can still access encrypted files because old private key stays accessible in user profile. But since the old EFS certificate cannot be exported anymore, you should renew the EFS certificates of all the encrypted files as soon as possible by executing cipher /u command, as they may become inaccessible if the old EFS certificate becomes inaccessible. Do not forget to export the new EFS certificate. The case when executing cipher /k command is necessary is when a suspicion of leakage of the preserved EFS certificate happens. Renewing all the EFS certificates of encrypted files prevent the one who has only old EFS certificate from decrypting the files.
If you are planning using EFS on mobile computers such as laptops as a precaution against an occasion of loss or theft, some considerations are necessary. In the hard drive with the system, there are user's private keys. Definitely these keys should not be used easily without authorization. That is, the computer should not be logged on easily. For example, if the PC is set to enable auto-logon without any password when booted, the EFS protection becomes completely useless. All the logon password of the PC should be sufficiently long and unguessable. Also, make sure that the PC is set to require the password when it returns from a standby or a hibernation mode when letting closing the laptop bring standby or hibernation active.
As for Windows XP, because the user's EFS private key is encrypted by the user's logon password and saved in the user profile and never exists elsewhere, the private key is safe as long as the logon password is not cracked. But the security depends on the strength (uncrackableness) of the logon password. If the logon password is not longer enough or somewhat guessable, the security degrades significantly.
(On the other hand, in Windows 2000, the user's EFS private keys are copied to a store called LSA Secrets. The reason of that is to enable user re-access to their private keys even after the administrator reset the user's logon password. LSA Secrets is encrypted by a master password called system key which is created automatically when installing the system. However, the system key is stored in the hard drive and becomes accessible automatically if anyone successfully logon, causing no protection to the EFS private key against illegal logon. An attacker can directly read and write to the hard drive and replace the storage of hashed users' logon passwords called SAM Database with a fake one, enabling him to logon the system as an Administrator without cracking any user's password. Then he can get the private key directly form LSA Secrets. To prevent this, it is necessary to delete the system key from the hard drive and provide it every time the PC startup. This makes an attacker inaccessible to the EFS private keys, because the attacker has to crack the LSA Secrets to get them. So it is necessary to delete the system key from the hard drive using a command namedsyskey in Windows 2000. On the contrary, in Windows XP, if an administrator reset the logon password of any user because he forgot his password, the user cannot decrypt his encrypted files because his old private key is inaccessible to him with his new password. Of course if the password change is made by himself after valid logon, the change is properly reflected in his private key.)
The reason why EFS does not use the user's logon password as EFS encryption key resides in this point; that is, the strength of a user password is generally extremely weak than an automatically randomly generated unique encryption key with very long key length. Using automatically generated keys ensure the security of encrypted files at the case where the files solely leaked (such as an incident of external hard drive theft). But when the files leaked with the encryption key which is encrypted by the user password, the security of the files depends on the security of the user password. Therefore, when a mobile PC has been stolen, the security of the encrypted files in the PC depends on how difficult to crack the logon password is.
For example, because the system key is used even to encrypt the SAM Database which retains the hash of user passwords, using the syskey command to delete the system key from the hard drive in Windows XP makes it a bit difficult to crack the user password, as an attacker needs to crack both of the SAM Database and the hash of the password serially. But this is not very effective to make cracking the password difficult. Multiplying password protection makes it difficult twice at the utmost. This is equivalent to make the key length one bit longer. Assuming that the characters used for the password are some 64 varieties with alphanumerical and signs, single character has 6-bit length. So making a password longer with one character makes it significantly difficult to crack the password than applying two password protections.
(To present comprehensive example, assume that there is a secret number protection with four digits. In this case, an attacker can crack the protection with ten thousand trial of 0000-9999. If you decided to apply the protection twice and to remember eight digits in total, the attacker can crack the protection with twenty thousand trial with ten thousand each. On the contrary, if you applied a secret number protection only once but with a digit longer, that is, with five digits, the attacker needs a hundred thousand trial of 00000-99999.)
In other words, the essential of making cracking a password difficult is its length. The longer the password is, the difficulty of cracking grows exponentially. So it is essential to make your logon password as longer as possible. It is recommended to have at least 16 characters.
After all, in regard to the data protection of mobile PCs, below is necessary not only using EFS.
syskey command. (You provide a password for it every time the PC startup. Make sure the password is also sufficiently long and unguessable.)In addition, to make security assure, you should consider clearing paging file and hibernation file from the system hard drive. Details are shown in the link at the end of this section.
You may encounter a trouble as described below by some chance while using EFS.
The exact reason of this symptom is unclear, but it seems that the root of the issue is the fact that somehow the system creates a bunch of unnecessary system files in your user profile directory. Specifically, there is a directory with a name of your SID in the C:\Documents and Settings\<your name>\Application Data\Microsoft\Protect directory and it contains thousands of or several tens of thousands of small (hidden) files. This is the directory where your master key which encrypts your secret key is stored, and the master key is updated and only a file is added to there every 90 days as default (you may not discard any of them). Obviously, it seems abnormal that the system creates countless files similar to the master key in that directory in a short period. However, you can solve the problem by deleting all the files in that directory. But you should be conscious of it means a loss of your master key, so you should export all of your certificates in advance. You will need to import them once again. The procedure is as follows.
.PFX file..PFX file which you exported previously.After this operation, a folder of your SID name is created again in the Protect directory and a master key is stored in it, but other many files are not created there at once. As a known phenomenon, if you use the PC as a network file server in non domain environment and when you upload EFS encrypted files to the PC from another machine (with acceptance of losing encryption), a considerable number of files are created in the SID directory in the Protect directory of the destination PC. In non domain environment, when you try to upload EFS files to another machine, a warning message appears that shows that the encryption will be lost. If you select "Ignore" or "Ignore All", the files are decrypted at the source PC and transferred to the destination PC. But at that time, many small files are created in the SID directory in the Protect directory of your account on the destination PC, as several numbers of files for only one EFS file transmission. No files are created in that directory when you decrypt the files beforehand in the source PC and avoid popping up the warning message.