In-depth analysis of EFS [zt]

EFS is an encryption File System. It can be applied to partitions in NTFS5 format on windows 2000 or later operating systems (not supported by windows xp home ).

EFS can only encrypt data stored on disks. It is a secure local information encryption service. EFS uses the core file encryption technology to store encrypted files on NTFS volumes.
It can prevent unauthorized physical access to sensitive data (theft of laptops, hard disks, etc)

How EFS works

When a user uses EFS to encrypt a file, there must be a public key and a private key. If the user does not, the EFS service automatically generates a pair. For beginners, even if they do not understand encryption at all, they can also encrypt files. They can encrypt a single file or a folder, in this way, all files written into the folder will be automatically encrypted.

Once a user publishes a command to encrypt a file or tries to add a file to an encrypted folder, EFS performs the following steps:

Step 1: NTFS first creates a log file named efs0.log in the volume information directory (which is hidden under the root directory) of the file, use this file for restoration when an error occurs during the copy process.

Step 2: Then EFS calls the CryptoAPI device environment. the device environment uses Microsoft Base Cryptographic Provider 1.0 to generate a Key. When the device environment is enabled, EFS generates a FEK (File Encryption Key, File Encryption Key ). the length of FEK is 128 bits (only US and Canada). This file is encrypted using the DESX encryption algorithm.

Step 3: Obtain the public/private key pair. If this key is not available (when EFS is called for the first time), EFS generates a new key pair. EFS uses the 1024-bit RSA algorithm to encrypt FEK.

Step 4: EFS creates a Data decryption block Data Decryptong Field (DDF) for the current user, stores FEK here, and encrypts FEK with a public key.


Step 5: if the system sets an encrypted proxy, EFS will also create a Data Recovery block Data Recovery Field (DRF), and then store the FEK encrypted with the restored proxy key in DRF. each time a Recovery Agent is defined, EFS will create a Data Recovery Agent (DRA ). winxp does not restore the proxy function, so this step is not available ., the purpose of this region is to prevent users from decrypting files. These users are called Recovery agents, which are defined in EDRP (Encryption Data Recovery Policy, encrypted Data Recovery Policy) as a domain security Policy. If the EDRP of a domain is not set, the local EDRP is used. In either case, EDRP must exist when an encryption occurs (so at least one recovery proxy is defined ). DRF contains the RSA-encrypted FEK and the recovery proxy public key. If multiple recovery proxies exist in the EDRP list, the FEK must be encrypted with the public key of each recovery proxy. Therefore, a DRF must be created for each recovery proxy.

Step 6: Encrypted data, DDF, and all DRF files are written to the disk.

Step 7: create a temporary file named Efs0.tmp in the folder where the encrypted file is located. the content to be encrypted is copied to this temporary file, and the original file is overwritten by the encrypted data. by default, EFS uses the 128-bit DESX algorithm to encrypt file data, but Windows also allows more powerful 168-bit 3DES algorithm to encrypt files, which must be enabled by the FIPS algorithm, because it is disabled by default.

Step 8: The text files created in step 1 and the temporary files generated in Step 7 are deleted.

Encryption process pictures refer to http://up.2cto.com/ OS /200506/20050624090936375.gif

After the file is encrypted, only users who can decrypt the FEK from DDF or DRF can access the file. unlike general security mechanisms, this mechanism does not mean that in order to access a file, in addition to the permission to access this file, it must also have the FEK encrypted by the user's public key. only users who use private keys to decrypt files can access the files. in this case, there is a problem: a user who can access a file can encrypt the file, but the real owner of the file cannot access the file. solution to this problem: when you encrypt a file, you only create one file to decrypt the block Data Decryption Field (DDF). However, only the user can be added to the key queue. in this case, EFS simply encrypts the FEK with the private key of the user who wants to access other users. then, use the public keys of these users to encrypt the FEK. The newly added DDF is put together with the first DDF (these newly added users only have access to the file ).

The decryption process and the encryption process are the opposite, refer to the http://up.2cto.com/ OS /200506/20050624090938620.gif

First, the system checks whether a user has a private key used by EFS. if yes, the system will read the EFS attribute and search for the current user's DDF In the DDF column. if DDF is found, the user's private key will decrypt the FEK. use the decrypted FEK and EFS to decrypt the encrypted file data. it should be noted that files are never completely encrypted, but sometimes some special sectors will be encrypted if the upper-layer module requires.


EFS Composition

EFS consists of EFS service, EFS driver, EFS File System Runtime Library (FSRTL) and Win32 API. The EFS service runs as a standard system service and is part of the Windows 2000 Security Subsystem. It and the CryptoAPI interface Generate Keys, DDF and DRF. The EFS driver is like a part of NTFS. It calls the EFS service request key, and DDF and DRF are created as needed, an EFS driver is composed of efs fsrtl, which defines the functions that the EFS driver can execute as a representative of NTFS.

How EFS and NTFS coexist

EFS can be considered as a second-level protection Except NTFS. to access an encrypted file, you must have the NTFS permission to access the file. Users with the NTFS permission can view the files in the folder, but cannot open the file unless there is a decryption key. Similarly, a user has a key but does not have the NTFS permission to access the file. Therefore, a user must be able to open the encrypted file and require NTFS permission and decryption key.

However, NTFS permissions may be crossed by a large number of methods, including password cracking programs, the user does not exit the system before leaving, or the NTFSDOS inside the system. In NT4.0, the game is over-all data on the hard disk can be accessed. In Windows 2000, when a file is encrypted with EFS, an unauthorized user cannot access the file data even if the file on the disk is accessed, because no private key is assigned to the user.

EFS attributes

When NTFS encrypts a file, it first sets an encryption flag for the file, and then creates a $ EFS attribute for the file where DDF and DDR are stored. the property ID of this attribute is 0x100. It can be extended, occupying a size of k to several k. The size is determined by the number of DDF and DRF.

Http://up.2cto.com/ OS /200506/20050624090939371.gif

The following is a detailed EFS attribute example.

Http://up.2cto.com/ OS /200506/20050624090940350.gif

Purple: EFS attribute size

Sky Blue: The computer security identifier and user number. It specifies the folder where the EFS stores the certificate. In order to get the file
Folder name. EFS will perform some conversions.

5A56B378 1C365429 A851FF09 D040000-data stored in $ EFS.

78B3565A 2954361C 09FF15A8 000004D0-converted result.

2025018970-693384732-167712168-1232-convert to decimal.

S-1-5-21-2025018970-693384732-167712168-1232-with a security identifier prefix.

The obtained folder is:

% UserProfile % ApplicationDataMicrosoftCryptoRSAS-1-5-21-2025018970-693384732167712168-1232

Pink: Public Key Features

Yellow: Globally Unique Identifier of the private key (also treated as the container name ). this name is used when EFS obtains the device environment from the CryptoAPI provider. if the $ EFS attribute has only one DDF, the container name can be calculated from $ efs. however, when more users add this file (more DDF and DRF will be available), the globally unique identifier of the private key is not used to store all users, others must be recovered from the certificate based on the public key storage feature.

RED: name of the cipher Provider (Microsoft Base Cryptographic Provider v.1.0)

Green: User Name, owner of DDF and DRF.

Blue: Encrypted FEK. Usually FEK is 128 bits, but after being encrypted by the 1024-bit RSA key, the length is changed to 1024 bits.


Reference: http://www.ntfs.com http://www.nsfocus.net

You are welcome to repost it, but be sure to keep the author information (Mrcool)