Hello! I hope you are all doing well 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 Part 2 of the series yet, I will urge you to read those in sequence 1st before continuing with this.
In the Modern Workplace, employee experience comes first. But information protection is also crucial. Finding the right balance is challenging for organizations. Strict measures can affect employee experience, while lenient measures leave security vulnerabilities. IT and security administrators must make tough decisions to balance these extremes, impacting employees’ workplace experience.
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 a file is 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 is the worker behind WIP file protection. Below is an overtly simplistic overview of the components 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.
We focus on the working mechanism of EFS encryption rather than the components involved. Let’s start by uncovering the general process flow for EFS file encryption.
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, ensuring protection and restricting 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 cmd line 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 uses it. You can see the same info using the Cipher cmd line 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 Windows’s CryptoAPI functionality 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 a 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 encrypted file. The original file’s contents (plain text) are copied into a temporary file, and then 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 a 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 forEDPCredentials
- If you run the command cypher/y to view the EFS cert thumbprint that EFS is currently using, you will not get any output.
Let’s consider a WIP-enabled system where you also have files manually encrypted via EFS. 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 protection, 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.
- The DDF field has the public key cert thumbprint value for the Manual EFS encrypted file.
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) that implements both crypto algorithms and also provides key storage. CNG (CryptoAPI—Next Generation), the successor to CryptoAPI, separates cryptographic providers (algorithm implementation) 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 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 and 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:
- Asymmetric 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.
You will only see that the WIP-protected file 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 for EFS encryption. Even if one is created by EFS for the current user account (in case you have manually encrypted files with EFS already), it won’t be used 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 the 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 defines one.
The key information is at the location %UserProfile%\AppData\Local\Microsoft\EDP\Recovery
If the same user enrols the device back to management (for WIP with enrollment) or the workplace joins the device back (for WIP without enrollment), access to the encryption key is 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 that 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 remove the local disk from the system and access the files from outside Windows, like attaching it to another Linux system, EFS has no third-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 is again protected by the user’s login credentials. A password change initiated from within the same user account session causes a rekey/update of the DPAPI master key with the new user password, rekeying all the private keys 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. The EFS encrypted files can’t be misused unless the original user account is compromised.
- You can only gain access to the DRA cert (private key) if the file has a DRF entry in the $EFS attribute, which is, again, quite impossible.
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 automatically backs 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 that 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 later as that is easier. For this, sign in to a standalone workstation with the designated user account and use the Cipher cmd line 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 as NTFS (default); however, it is not supported with FAT and other filesystems.
To check if your removable media file format supports EFS, you can use the Windows fsutil cmd line 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’s 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 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 because 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 defined in the file metadata rather than a file attribute, a filesystem feature.
However, this cannot be considered 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– Learn WIP with Joy – File Protection Deep Dive
That was all I had in store for you. I hope you all have liked the series and learned something from it, which is the ultimate aim.
Stay tuned for a bonus article on Windows Information Protection—a complete troubleshooting guide for Intune Admins.
Until then, read something every day, learn something every day, but most importantly, Stay Isolated, Stay Safe, and help keep Others Safe!
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site, MDM Tech Space, at https://joymalya.com.
Hey Joymalya,
Awesome series on WIP – just finished going through it including the bonus on troubleshooting.
Where I struggle with WIP is getting Azure RMS templates to protect USB files. My understanding is that when you copy a work file (EFS encrypted) to USB, it should let you copy, but protect it using the Azure RMS template you specify. However, in all my testing and configuration, I just get an error that reads I cannot place the file on the USB. The only way I’ve been able to do it is to not use Azure RMS, just EFS, but that means the USB cannot be shared with other users.
Do you have any advice on troubleshooting such a problem?
Hi Ruairidh,
Azure RMS (AIP) integration with WIP helps to protect file when it shared as an email attachment or uploaded to cloud locations or file servers.
For USB, what error are you exactly getting. Is it completely blocking you to copy or it allows to copy by removing protection (depends on the file format of USB drive as it needs to support EFS).
I haven’t heard or faced anything like that if you have azure RMS configured with WIP, you cannot copy to USB. The AIM of RMS is to keep the file protected irrespective of the file location as unlike WIP, where the EFS protection is applied as file attribute (function of file system), Azure RMS protection is built into the file metatdata and has no dependecy on the underlying filesystem.
Hey Joymalya, thanks for the reply. I can copy to the drive (NTFS) if I remove protection in the ‘allow overrides’ WIP method. Here’s exactly what happens recorded as a GIF – https://i.imgur.com/be0PxtL.gif
The error for copying as work protected is simply the ‘organisation does not allow you to place this file here’. This is a clean system with only this app protection policy configured (no BitLocker USB requirements for example). Interestingly, when I copy as personal and then try to change ownership on the USB, it gives me error 0x80071787 (which returns no Google results) saying ‘specified file could not be encrypted with Windows Information Protection’. There are no logs in Event Viewer, and I have tried on MDM enrolled and MAM only PCs.
I’ve confirmed in registry that the AIP template ID is retrieved but I get the feeling the problem is getting the AIP protection from the AIP service, but not sure. I even added a label policy to confirm permissions.
Hi Ruairidh,
What is the output of fsutil fsinfo volumeinfo as example fsutil fsinfo volumeinfo D:
Does is shows EFS as supported?
You are unable to copy to USB drive either because your WIP policy defined EDP enforcement is set to Block or the USB drive itself does not supports EFS. Just a thought!
Hey Joymalya, thanks for the feedback. The output of dsutil looks fine as it reports “supports encrypted file system.” All very strange as I can copy and change to personal, so it’s definitely not in block mode either. I will keep investigating and update this thread if I find a solution.
Hi Ruairidh,
Did you find a solution for your problem? We are having the same issue at the moment, I always worked fine before and nothing has changed.
Your post here is the only one that google can find with the exact error code 0x80071787.
Any updates here? 🙂 I have the same on a few tenants with the default WIP policy.
Hi Joymalya,
great series regarding WIP!
I have just one question. How is WIP working together with SMB File Shares? File Shares are not supporting EFS. What occurs if a users access data on a file share from an enterprise location? Are the data automated protected if accessed? Is it possible to disallow access from non WIP protected apps?
Many Thanks,
Markus
Hi Markus,
WIP helps tag files to corporate identity and protect them when downloaded to local device storage only. It does not protect files in transit or when shared or when uploaded to a file share. (Need to integrate with AIP)
If you identify your file server as a WIP protected resource, then files downloaded from that server will be tagged as corp and protection applied.
And off course, you can disallow access to corporate resources from non-WIP apps. By default, only apps in the protected apps and exempted apps can access corp resources. Apps not in either list gets blocked.
Regards,
Joy
Hi Joymalya,
Great series regarding WIP!
I have a unique situation where we are using WIP but it is not working with a mapped cloud drive. I assume this is sort of similar to One Drive but we are using Citrix ShareFile they have a program that can map a drive to their cloud storage platform. WIP doesn’t look to have a place to specify that the Z:\ drive contains protected content nor does the drive support encrypted files. Can I use PowerShell to encrypt a file using the WIP system when it is moved from the Z drive? Any other suggestion would be helpful as well as far as I know it is a Microsoft Virtual Drive so I am quite puzzled on what to do.
WIP can help protect data on the local storage of an endpoint by tagging the data to the corp identity and encrypting it. However, as I have mentioned in the blogs, WIP encryption is dependant on EFS which requires NTFS file system. WIP can’t protect data if that data is being shared over the wire or uploaded to cloud storage. Being said that, if you have a file share that is being mapped as Z drive on the endpoint, I believe you could possibly add the URL of the file share as a protected resource within the WIP policy. (Add a Cloud resource with either the URL or IP of the file share) This would make the endpoint treat any file coming from the Z drive as corp data protecting it automatically if saved on the local storage. [This won’t encrypt your files within the file share].
If you are worried about protecting data, AIP (now Unified labeling and M365 DLP solutions) would be the way to go forward as it will ensure the protection of data remains with the data and not dependent on the file system.
Hi Joymalya,
Excellent blog!!!