A lot of folks have the perception that EFS is complicated as it may use PKI management (not mandatory) and messing around with the Key can result in a data loss but in fact it’s rather simple and you need to have some concept specific to EFS. Let’s dive into it.
While EFS have been used in enterprises for quite some times, it came back in the spotlight with Windows Information Protection (WIP) (More info on WIP later).
Encrypting File System (EFS) is an encryption residing at the file system level, while BitLocker is at the disk level, it embedded in NTFS and Windows since Windows 2000. Each Windows gives new feature and support more algorithm, A support for FAT and exFAT have been added in Windows 10 1607 and Windows Server 2016.
Certificates
While PKI management is not mandatory, EFS use certificates to encrypt the File Encryption Key. There is two type of certificates:
Encrypting File System certificates
Used to encrypt and decrypt the FEK for the end-user, it have Encrypting File System (1.3.6.1.4.1.311.10.3.4) as the Key Usage
File Recovery certificates
Used to have Data Recovery Agent as backup in case the user lost his password or access to the certificate, it have File Recovery (1.3.6.1.4.1.311.10.3.4.1) as a the key usage
How it works
A lot of documentation exist, plenty link down below for more information but in a nutshell, here’s how it works.
Encryption
Step 1: File Encryption Key
EFS create a symmetric key, File Encryption KEY (FEK) for the file using CryptoAPI and use it to encrypt the file.
Step 2: Public/Private Key Pair
EFS access the user public key to encrypt the FEK. The public/private key pair can be a self-signed certificate, PKI certificate, smartcard, or an auto generated at EFS activation.
Step 3: Data Decryption Field
The field contain the FEK encrypted with the user public key
Step 4: Data Recovery Field
If the EFS policy define a Data Recovery Agent, then EFS use the public key of the DRA to encrypt the FEK and store in the Data Recovery Field.
High level view of the attributes used, there are more attributes outside and within each field used by EFS, such as User SID, Checksum, EFS Certificate hash, …
Data Recovery Agent & Key Recovery Archiving
When an enterprise use PKI to generate DRA certificate, will face the issue of archiving the keys, while EFS itself don’t have any clue whether the Key haven been archived or not, this will lead to have device with one key and other device with the newer one.
Another aspect of the DRA certificates is that they can be cumulated and used all together. Imagine a self-signed cert valid for 50 years and another one PKI generated for 2 years, the file can decrypted by one or the other, this help to decrypt file in case the PKI is not there anymore or if the key archiving was not done properly.
Sources :
- https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc875821(v=technet.10)
- https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc162507(v=msdn.10)
- https://en.wikipedia.org/wiki/NTFS#Encryption
- http://www.ntfs.com/internals-encrypted-files.htm
- https://en.wikipedia.org/wiki/Encrypting_File_System