Analysis of data recovery solutions for situations EFS encrypted files can not be opened

(A) the type of fault: the EFS encrypted files can not be opened
(b) typical characteristics:

1. reinstall the system previously encrypted file can not be opened
2. encrypted file key file can not be opened resulting in the loss of

(C) the extent of the damage star rating: ★★★★
[fault principle and resume thinking]

when you encrypt a file using NTFS EFS, the system will first generate a pseudo-random number FEK (File Encryption Key, file encryption key), then FEK encrypted data and the file is overwritten in situ. The system then using the user's public key encryption FEK, and the encrypted FEK is stored in the EFS $ encrypted file attributes.

And when accessing encrypted file, the system first using the current user's private key to decrypt FEK, and then use the FEK to decrypt the file. When the EFS first use, if the user has not public / private key (referred to as a key), it will first generate a key, and the encrypted data. If a user logs on to a domain environment, the key generation depends on the domain controller, or it depends on the local machine.

User's private key to decrypt EFS file is the key, the private key stored in the Windows partition Documents and Settings \% UserName% \ Application Data \ Microsoft \ Crypto \ RSA \% UserSID% (user's SID is the security identifier, corresponding to the user ××× number, when you create an account, the system is assigned a unique SID number).

In order to protect the private key, Windows performed using the private key encryption master key, the master key is located Documents Windows partition and Settings \% UserName% \ Application Data \ Microsoft \ Protect \% UserSID%, and then use the secret user password generated key to encrypt the master key.

Thus forming a "user password -> Master Key -> private -> FEK-> EFS encrypted files" encryption chain. So if you want full access to EFS encrypted data, it must obtain the user's password, the master key and a private key.

(Iv) recovery process
1. Detection process:

(1) view the existing system footprint;
(2) to view the files in the directory are now mft number of occupied space.
Process Embodiment 2:
(1) Find FEK encrypted private key or recombinant;
(2) can find the master key encrypted private recombination;
(3) verify the user password matches the user Tigong decryption user files;
(4) out of the file decryption logical analysis and verification, the user needs to migrate data.
3. Acceptance Process:
(1) do statistical properties of all the data has been migrated from the file number of
aspects such as capacity and ensure that the required data users have been migrated successfully;
(2) do verify the integrity of all data has been migrated out to ensure that
the file in the directory structure is correct the underlying logic and the like;
(3) the critical file specified by the user targeted verification, to ensure user turns
the key data restored successfully.
(E) reliability analysis and estimated recovery time:
In most cases, such failures lead to reinstall the system is mainly caused by the loss of the key, reinstall the system due to the large number of files to be written to the system partition, the key is covered the probability is relatively high, which is leading an important reason for lower success rate of such recovery, the success rate of such failures are generally around 50%, the time required is usually 1-3 business days.

[Tips]
(a) by the EFS encrypted files should promptly back up the key and keep it;
(2) After such a failure occurs should stop immediately to continue to use the computer to reduce the probability of key covered.

Guess you like

Origin blog.51cto.com/sun510/2424445