{"id":101,"date":"2018-10-03T12:52:23","date_gmt":"2018-10-03T12:52:23","guid":{"rendered":"http:\/\/172.23.1.43\/?p=101"},"modified":"2022-06-07T22:26:14","modified_gmt":"2022-06-07T22:26:14","slug":"encrypting-file-system","status":"publish","type":"post","link":"https:\/\/blog.n-dol.org\/2018\/10\/03\/encrypting-file-system\/","title":{"rendered":"Encrypting File System"},"content":{"rendered":"

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.\u00a0Let’s dive into it.<\/p>\n

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).<\/p>\n

<\/p>\n

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,\u00a0A support for FAT and exFAT have been added in Windows 10 1607 and Windows Server 2016<\/a>.<\/p>\n

\"Layout\"<\/p>\n

Certificates<\/h1>\n

While PKI management is not mandatory, EFS use certificates to encrypt the File Encryption Key. There is two type of certificates:<\/p>\n

Encrypting File System certificates<\/h4>\n

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<\/p>\n

File Recovery certificates<\/h4>\n

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<\/p>\n

How it works<\/h1>\n

A lot of documentation exist, plenty link down below for more information but in a nutshell, here’s how it works.<\/p>\n

Encryption<\/h2>\n

Step 1: File Encryption Key<\/h3>\n

EFS create a symmetric key, File Encryption KEY (FEK) for the file using CryptoAPI and use it to encrypt the file.<\/p>\n

Step 2: Public\/Private Key Pair<\/h3>\n

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.<\/p>\n

Step 3:\u00a0Data Decryption Field<\/h3>\n

The field contain the FEK encrypted with the user public key<\/p>\n

Step 4: Data Recovery Field<\/h3>\n

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.<\/p>\n

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, …<\/p>\n

\"EFS-File\"<\/p>\n

 <\/p>\n

Data Recovery Agent & Key Recovery Archiving<\/h1>\n

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.<\/p>\n

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.<\/p>\n

 <\/p>\n

\n

Sources :<\/p>\n