How does EFS Work?
How does EFS work?
EFS uses an encryption attribute to designate files for EFS protection. When a file’s encryption attribute is on, EFS stores the file as encrypted cipher text. When an authorized user opens an encrypted file in an application, EFS decrypts the file in the background and provides a plaintext copy to the application. The authorized user can view or modify the file, and EFS saves any changes transparently as cipher text. Other users are denied permission to view or modify EFS-encrypted files. EFS-protected files are bulk encrypted to provide confidentiality even from intruders who bypass EFS and attempt to read files by using low-level disk tools.
When you specify that you want to use EFS to encrypt a file or a folder, EFS generates a file encryption key (FEK), which consists of a pseudo-random number. The system uses this number and the Data Extended Standard X (DESX) algorithm to create the encrypted file and write it to the hard disk. The system then encrypts the FEK with your public key and stores it with the encrypted file. When you access the encrypted file, the system uses your private key to decrypt the FEK and then uses the FEK to decrypt the file. When you use EFS for the first time, the system automatically generates a public/private key pair if one doesn’t already exist. If you’re logged on to a domain, the public/private key pair resides on a domain controller (DC); otherwise, it resides on the local machine.
EFS, which is based on public key cryptography, uses a randomly generated file encryption key (FEK) to encrypt data (e.g., local NTFS files). A public key-based system uses a pair of keys: one private and one public. Only the user who owns the private key has access to the private key. The public key is available to anyone who requests it. The user’s public key encrypts FEKs; the private key decrypts FEKs.
NTFS stores a list of encrypted FEKs with the encrypted file in special EFS attributes known as Data Decryption Fields (DDFs) and Data Recovery Fields (DRFs).
When EFS encrypts a file, it does the following:
Generates a bulk symmetric encryption key.
Encrypts files by using the bulk encryption key.
Encrypts the bulk encryption key by using the EFS user’s public key.
Stores the encrypted bulk key in a special field called the data decryption field (DDF), which is attached to the EFS file.
EFS can then use the user’s private key to decrypt the bulk encryption key and decrypt the file as necessary. Because only the user has the private key, others cannot unlock the DDF.
EFS’s key-storage mechanism is based on W2K’s CryptoAPI architecture, which stores users’ public and private keys separately from the randomly generated FEK. This setup lets users store their private keys on secure devices (e.g., NTFS volumes, smart cards). Smart cards, which require smart card readers on computers, are credit-card sized devices that let users log on to W2K with a PIN. Smart cards make personal information (e.g., account numbers, passwords, digital certificates) portable.
You might also want to read the following related articles:
More in Security
CISA Advises Federal Agencies to Patch Windows LSA Flaw Affecting Domain Controllers
Jul 5, 2022 | Rabia Noureen
Microsoft Defender for Endpoint Now Detects Network Threats on Android and iOS Devices
Jul 5, 2022 | Rabia Noureen
Microsoft Defender Vulnerability Management Adds New CVE Reporting Feature
Jun 30, 2022 | Rabia Noureen
Microsoft Releases Patches to Address Azure FabricScape Flaw Affecting Linux Workloads
Jun 29, 2022 | Rabia Noureen
Microsoft Defender for Identity Can Now Detect Insecure Domain Configurations
Jun 27, 2022 | Rabia Noureen
CISA Warns Unpatched VMware Servers Remain Vulnerable to Log4Shell
Jun 24, 2022 | Rabia Noureen
Most popular on petri