Learn WIP with Joy – File Protection Deep Dive – Part 3

Hello! Hope you are all doing good and are safe along with your friends and family.

This is the last and concluding article on the Windows Information Protection series that I started “Learn WIP with Joy!” If you have not read Part 1 and Part2 of the series yet, I would urge you to read those in sequence 1st before continuing with this.

Today in this article, I will be taking you through the following topics

• the general flow of EFS file protection
• any deviations when EFS is invoked by WIP
• importance of DRA in WIP policy
• WIP file protection when file copied to removable media
• discuss the limitations of WIP

Let’s get started.

[Recap] EFS – The components involved

I will continue from where I left off in Part 2 of this article series – EFS the worker behind WIP file protection. Below is an overtly simplistic overview of the components that are responsible for the EFS functionalities.

The main components of EFS are

Kernel Mode

• NTFS File System
• EFS Driver

User Mode

• EFS service [runs within the LSASS process] (LSASS handles crypto key requests utilizing EFS functions)
• CryptoAPI

As mentioned, this is a very high-level view of the components involved. Explaining the entire flow in detail is not the scope of this article. You can find good documentation on EFS over the internet, like this.

Rather than the components involved, our focus is on the working mechanism of EFS encryption. Let’s start with uncovering the process flow for EFS file encryption in general.

EFS encryption process in a nutshell [Generalized]

If you have read Part 2, you would know that EFS file encryption uses both symmetric and asymmetric keys. The symmetric key (FEK) is used for encryption/decryption of the file content whereas an RSA public/private key pair generated for the user account is used to protect the FEK so as to ensure protection and restrict unauthorized file access.

A simplistic overview of the EFS encryption process is shown below

Preliminary Requirement – Check for a public/private key pair

On a Windows 10 endpoint, when you manually encrypt a file, either by

• using File Explorer, marking the checkbox for Encryption from the Advanced menu of file Properties

• using the cipher cmdline tool command: cipher /e <filename(complete path to file if not in present location)>

EFS checks to see

• if the currently signed-in user account has a public/private key pair that can be used for EFS encryption. Basically, a check in the user’s Personal certificate store to see if it has any cert with EKU for EFS.

• if no such key pair is found, EFS generates a public/private key pair (RSA 2048 bit) for the currently signed-in user account.

This results in a self-signed certificate (EKU is EFS) for the public/private key pair. The public key cert is added to the User Personal Certificate store as shown below. (%AppData%\Microsoft\SystemCertificates\My\Certificates)

The certificate thumbprint is also added to the registry under HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys where EFS makes use of it. You can see the same info using the Cipher cmdline tool command cipher /y which shows you the public key cert thumbprint/cert hash currently used by EFS.

Actual encryption workflow of EFS

• A log file called Efs(x).log (x is a unique number) is created in the System Volume Information folder on the same drive, as the file to be encrypted.

• NTFS sets the Encryption Flag and creates the $EFS attribute for the file to store the encryption information (DDF and DRF, explained in later steps)

• EFS utilizes the CryptoAPI functionality of Windows to generate the symmetric key (FEK) for file content encryption/decryption.

• EFS creates a Data Decryption Field (DDF) within the $EFS attribute of the file. The FEK is encrypted with the public key certificate of the currently signed-in user and placed in the DDF field.

• If the WIP policy defines a Data Recovery Agent, EFS also creates Data Recovery Field (DRF) within the $EFS attribute, where it places the FEK which is encrypted with the DRA cert (public) as provided.

• A temporary file Efs0.tmp is created in the same folder as the file being encrypted. The contents of the original file (plain text) are copied into a temporary file, after that the original is overwritten with encrypted data.

• After encryption is done, temporary and log files are deleted.

This entire process happens in the backend and as such is transparent to the end-user. The file gets encrypted when it is closed and automatically decrypted if the current user account has the private key matching the public key. To check the entire process in detail, please refer here.

EFS encryption with WIP is not the same as EFS encryption in general (?)

On a Windows Information Protection enabled Windows 10 endpoint (both with and without enrollment) where you have not manually encrypted a file using EFS,

• you will not find the self-signed cert in the User Personal Cert store. (there may be other user certs deployed by your organization reflected here)

• you will not see the CurrentKeys reg_key under  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\ and instead will have only entries for EDPCredentials

• you will not get any output if you run the command cipher /y to view the EFS cert thumbprint that EFS is currently using.

Let’s consider a WIP-enabled system, where you have files manually encrypted via EFS as well. Below, you can see I have two files

• one is WIP protected, and
• other is EFS encrypted manually

See the difference in file ownership?

• WIP protected file is tagged to the Enterprise Identity as defined in the WIP policy for File Ownership
• Manual EFS protected which shows the CN(SAN) of the EFS public key cert used for protecting the file

Using the EFSDump Sysinternals tool to check the protection information of the files, you will see that for the

•  WIP protected file, DDF field returned is empty.
•  Manual EFS encrypted file, the DDF field has the value of the public key cert thumbprint.

Checking the protection info of the two files using the Cipher utility

PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\Personal.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E Personal.txt
  Compatibility Level:
    Windows XP/Server 2003
 
  Users who can decrypt:
    AzureAD\JoymalyaBasuRoy [JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)]
    Certificate thumbprint: C855 DD0A D5B4 70DE 1FB7 C580 ADFC F355 E82B 2367
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256
 
PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\work2.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E work2.txt
  Compatibility Level:
    Enterprise Protected
 
  Enterprise protected by:
    joymalya.com
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256

For the manual EFS encrypted file, you will get public cert details with which the file was encrypted. Using the Certutil tool, you can find out the corresponding private key details as shown below

PS Cert:\CurrentUser\My> $cert = gi cert:\CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PS Cert:\CurrentUser\My> $cert | fl *
 
 
PSPath                   : Microsoft.PowerShell.Security\Certificate::CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E8
                           2B2367
PSParentPath             : Microsoft.PowerShell.Security\Certificate::CurrentUser\My
PSChildName              : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PSDrive                  : Cert
PSProvider               : Microsoft.PowerShell.Security\Certificate
PSIsContainer            : False
EnhancedKeyUsageList     : {Encrypting File System (1.3.6.1.4.1.311.10.3.4)}
DnsNameList              : {JoymalyaBasuRoy}
SendAsTrustedIssuer      : False
EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
PolicyId                 :
Archived                 : False
Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                           System.Security.Cryptography.Oid}
FriendlyName             :
IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter                 : 2/27/2120 6:54:09 PM
NotBefore                : 3/22/2020 6:54:09 PM
HasPrivateKey            : True
PrivateKey               : System.Security.Cryptography.RSACryptoServiceProvider
PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
RawData                  : {48, 130, 3, 25...}
SerialNumber             : 47DFA194526BE4AC4A62CF38C0B2D7D3
SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
SignatureAlgorithm       : System.Security.Cryptography.Oid
Thumbprint               : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
Version                  : 3
Handle                   : 1992566309712
Issuer                   : CN=JoymalyaBasuRoy
Subject                  : CN=JoymalyaBasuRoy
 
PS Cert:\CurrentUser\My> $cert.PrivateKey.CspKeyContainerInfo
 
 
MachineKeyStore        : False
ProviderName           : Microsoft Enhanced Cryptographic Provider v1.0
ProviderType           : 1
KeyContainerName       : c309ccd7-f8c6-4e7b-b4bf-6cc17b3fe76b
UniqueKeyContainerName : f9969d35521c72e688cffc35d6d9da2c_5f5f326a-34f7-469e-bdea-529234e0c80f
KeyNumber              : Exchange
Exportable             : True
HardwareDevice         : False
Removable              : False
Accessible             : True
Protected              : False
CryptoKeySecurity      : System.Security.AccessControl.CryptoKeySecurity
RandomlyGenerated      : False

Notice the CSP is Microsoft Enhanced Cryptographic Provider v1.0, a legacy CryptoAPI (CAPI) CSP (deprecated, for details check here) which implements both crypto algorithms and also provides key storage. CNG (CryptoAPI – Next Generation), the successor to CryptoAPI, separates cryptographic providers (implementation of algorithms) from key storage providers (KSP) services, providing better key isolation for protection.

The corresponding private key will be found at the user profile location  %APPDATA%\Microsoft\Crypto\RSA\{User SID}

Notice the filename of the key matches the Unique container name value as shown above.

This private key is turn protected by DPAPI using a symmetric key known as the User Master Key which is derived from the user logon credentials using some salt. The User Master Key itself is stored protected to the location %APPDATA%\Microsoft\Protect\{User SID}

If you go to the location mentioned, you will see that the folder is empty. However, checking the folder properties will reveal that it actually contains files. (The files in this location are protected OS files)

In general, you would see 2 files here. This is because the User Master Key protected by the Protected Storage service is stored in two parts

Part 1 – the Password Encryption Key (PEK), is produced by the HMAC and SHA1 message digest function and is a hash of:

• A symmetric encryption of the user’s master key is produced by 160-bit RC4.
• The user’s security identifier (SID).
• The user’s logon password.

Part 2 – the backup/restore form of the master key, which is used in case, the system fails to detect password changes and thereby fails to update the password encryption key, uses the backup to recover the previous key and regenerate Part 1.

For the WIP-protected file, you will only see that it is enterprise protected, but it will not show you details of any cert with which the file was encrypted.

When WIP invokes EFS for file protection, EFS does not check to see if there is a public/private key pair available in the User Personal cert store suitable to be used for EFS encryption. Even if there is one created by EFS for the current user account (in case you have manually encrypted files with EFS already), it won’t use it for file protection of WIP tagged files.

However, the file encryption process remains identical as explained above, in the sense, that the file content gets encrypted using a symmetric key which in turn is protected by an asymmetric key. The encryption key itself remains stored in the current user profile.

You can see the records for EDP Account that EFS will use at reg_path HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\EdpCredentials

In the event of unenrollment (or MDM handoff), the key still remains on the device, however, if the policy is configured to revoke access for such events, the key becomes useless as it can’t be accessed to decrypt the FEK to decrypt the file content. In such cases, the encrypted files can only be recovered with a DRA cert if the WIP policy defined one.

The key information is at location %UserProfile%\AppData\Local\Microsoft\EDP\Recovery

If the same user enrolls back the device to management (for WIP with enrollment) or the workplace joins the device back (for WIP without enrollment), access to the encryption key gets restored and the files can be accessed again.

EFS encryption – How secure is the protection?

As it is the public key of the public/private key pair generated for the currently active user account which is used to protect the FEK, only the same user account will have access to the private key for decrypting the FEK.

For multiple users logging in to the same system, a unique RSA key pair is generated for each user account which is mutually non-accessible. Thus by default, only the user account under which the file protection activity was performed will have access to the file contents due to the possession of the private key. Other user accounts will be denied access to file contents as they won’t have access to the original account’s private key.

Microsoft recommends WIP to be used by a single user per device – the account which enrolled the device. For multiple users signing in to the same device (Azure AD join device), there may be inconsistency and the service may fail to revoke access to encryption keys for secondary users.

To understand the security of EFS file protection better, see the structure of the DDF field in the $EFS attribute of the file. (Explained in detail here)

The DDF field can have multiple DDF Key entries. By default, it will have a single DDF entry for the original user account. Each DDF key entry is identified by the User SID.

Consider a scenario where the system is compromised (lost or stolen) but the user account is not compromised.

In such a case, if another user (attacker) creates a local account and tries to access EFS encrypted files present on the local disk, NTFS will get no match for the current user account SID against the SID value present in the DDF field of $EFS attribute of the protected file. NTFS will deny access to the file.

Even If the attacker decides to take the local disk out of the system and access the files from outside Windows, like attaching it to another system running Linux to access the files, EFS has no 3rd party component driver support for other OS filesystems. Thus the file becomes useless to the attacker as it cannot be opened.

The only way to get to the content of an EFS encrypted file is, either

• gain access to the user’s private key, the public key of which was used to protect the FEK (identified by the EFS cert hash in the DDF entry).

The private key is protected by the DPAPI master key which in turn is again protected by the user’s login credentials. A password change initiated from within the same user account session causes rekey/update of the DPAPI master key with the new user password, resulting rekeying of all the protected private keys which were protected by the previous version. Trying to reset the login credentials of the user account from outside the user account with special tools or from a recovery environment will render it impossible to decrypt the DPAPI master key thereby securing the private key. As such, unless the original user account is compromised, the EFS encrypted files can’t be misused.

• gain access to the DRA cert (private key) if the file has a DRF entry in the $EFS attribute, which is again quite impossible to gain access to.

However, once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication. Decryption happens transparently. Thus, any compromise of the user’s password automatically leads to access to that data.

Importance of DRA…

When WIP is enforced, work tagged data residing locally on an endpoint gets encrypted (EFS) using the WIP encryption key – an RSA public/private key pair generated locally on the system for the Azure AD Identity under the authority of the current signed-in User Account.

Windows 10 version 1709 onwards, the WIP encryption key information gets automatically backed up to Azure against the Azure AD identity account(UPN).

If the WIP policy is configured to revoke encryption keys on unenrollment, MDM handoff, or if the device lost its encryption keys due to an unprecedented event, any such action would lead WIP protected data residing locally on the endpoint to inaccessible.

Re-enrolling the device back with the same user identity causes Azure to restore the encryption key information on the endpoint making those protected files accessible again.

Still, this is like a single point of failure and there may be scenarios where re-enrolling the device with the same account is not an option. This is where a Data Recovery Agent certificate comes in handy. DRA is an RSA public/private key pair which can either be

• requested from a CA (to support key archival), or
• generated from a standalone device for a designated user account (maybe an EFS Recovery Service Account)

I will show them latter as that is easier. For this, sign in to a standalone workstation with the designated user account and use the Cipher cmdline to command cipher /r:<Name for Cert Package>

You will find two cert files in the current location.

• .pfx contains the private key which can later be used for recovery purposes and as such should be backed up to a safe location, and
• .cer which is the public key cert. (this is the one that needs to be added to the WIP policy to be distributed to the endpoints)

When a DRA cert is defined in the WIP policy, corporate tagged files are protected in a way that those can be accessed either by

• the primary user, or
• the IT admin has access to the private key of the DRA

For recovery using DRA, you would just need to import the private key to a system where you have admin rights. Also copy the encrypted inaccessible files to the same system. Then utilize the cipher utility to decrypt the encrypted file. 

WIP file protection is persistent when files are moved/copied to removable media (?)

The Microsoft documentation for WIP states that the file remains protected if copied to a USB drive.

However, this may or may not work as stated, since the protection status depends on the file system of the removable media. EFS is now supported with exFAT and FAT32 as well along with NTFS (default) however, is not supported with FAT and other filesystems.

To check if your removable media file format supports EFS, you can use the Windows fsutil cmdline tool command fsutil fsinfo volumeinfo <DriveLetter>:

If you check and see that the removable media supports EFS, when you try to move protected data from device local storage to removable storage, you get a prompt similar to below

Let’s consider that you lost the USB drive, but if you have copied it as Work Protected, you can rest assured that others won’t be able to open the file to get the data/content.

WIP – Limitations (?)

By design, WIP is intended to protect work data at rest residing locally on an endpoint, and/or protect work data if copied over to a removable media like a USB drive. However, WIP cannot protect work data in transit – when you attach a work file to an email or upload it to a file share or online storage like SharePoint.

This limitation is due to the fact that WIP depends on EFS to protect data residing locally on an endpoint by encrypting and this protection information is not stored within the file, but as an attribute of the file (protection information resides on local disk separately, the location being pointed by the File Header which contains the $EFS attribute)

This is where Azure Information Protection integration with WIP comes into the scenario since AIP protection stays with the file irrespective of its location,

AIP protection information is basically defined in the file metadata rather than a file attribute which is a filesystem feature.

However, this cannot be termed as a limitation, if you see how Microsoft has positioned Windows Information Protection in its lineup of Information Protection offerings.

The main purpose of WIP is to differentiate and separate work data from personal data on an endpoint and prevent users from accidentally leaking work data to personal space.

And this is what Windows Information Protection does exactly – it does not try to do what it was never supposed to do – protect data end-to-end throughout its lifecycle.

An Ending…

That was all that I had in store for you. Hope you all have liked the series and have learned something out of it which is the ultimate aim.

Stay tuned for a bonus article on Windows Information Protection – a complete troubleshooting guide for the Intune Admins out there.

Till then, read something every day, learn something every day but the most important of all – Stay Isolated, Stay Safe to help keep Others Safe!