Share via

Remote EFS decryption and Trusted for Delegation requirements

  • Article

One of our customers reported the following:

We have been evaluating EFS on Windows 7 as part of our upgrade from Windows XP project and have discovered that if you share a folder and encrypt a file within it locally, the same user is able to decrypt it remotely without the workstation being trusted for delegation.
If the user logs off then the remote EFS decryption operation fails. If the user logs on again and opens any file encrypted with the same EFS certficate the remote user can decrypt it again.
We're concerned that this is a security risk in Windows 7 and from our tests with Notepad and encrypted .txt files we don't see the same behaviour when the target machine doing the sharing and encrypting is Windows XP.

After researching this we determined the following:

  • EFS loads a mini-profile on the target server and uses it for the decryption - if a user is already logged on to the target no profile loading is required.
  • As long as the same user has a handle open to an encrypted file, remote EFS decryption is possible even if the "server" isn't trusted for delegation.This is because the handle caches the private key used for the decryption operation and using it from the cache doesn't require delegation while loading it from disk does.
  • Additional caching options for private keys were introduced in Vista SP2 (per CSP instance caching) - they were however not turned on by default.
  • The same caching options are turned on by default in Windows 7.
  • The per-CSP instance caching behaviour can be turned on or off on Vista SP2 and Windows 7 by setting the DWORD values CachePrivateKeys and PrivateKeyLifetimeSeconds under HKLMSoftwarePoliciesMicrosoftCryptography.

I.e. remote EFS decryption without the target machine being trusted for delegation is also possible in Windows XP - as long as an open handle to the EFS-encrypted file exists locally on the remote server and the same user is logged onto it.
Notepad however closes the handle to the EFS-encrypted file as soon as it has finished decrypting it - using Notepad to test this on an XP machine is therefore not likely to give reliable results.

If you're quick enough to open it on the other machine however you can still manage to hit the window where the key is still loaded by the handle that Notepad has to the file and in that case decryption succeeds.
For testing this on XP, something that keeps a file handle open is needed (a ZIP file and 7-Zip or WinZip for example).

In short; private key caching is present on XP, W2k3 and Vista/W2k8/W2k8R2/Win7 - it's the caching that enables the remote EFS-decryption without needing to be delegated *if* the same user is already logged on and has already decrypted the file. 
On Win7 the additional per-CSP instance caching makes this more visible because the improvements introduced in Vista have been turned on by default and this allows the CSP to keep the key cached even if the handle to the encrypted file has been closed.

Further details:

Private Key Caching Constants
http://msdn.microsoft.com/en-us/library/aa387403(VS.85).aspx

You are no longer prompted to enter your private key password every time that the private key is accessed after you upgrade your computer to Windows XP Service Pack 2
http://support.microsoft.com/kb/890062

Windows Prompts You for Your Password Multiple Times When You Use Outlook If Strong Private Key Protection Is Set to High
http://support.microsoft.com/kb/821574/

The "Request For Permission to Use a Key" dialog box appears whenever you try to send an e-mail message in Outlook 2007 after you configure Outlook 2007 to use a digital signature in Windows Vista
http://support.microsoft.com/kb/936029

Using Encrypting File System
http://technet.microsoft.com/en-us/library/bb457116.aspx

Comments

  • Anonymous
    August 11, 2010
    Great (and quick) post! We got there in the end:)