Introduction: Why Did I Build This Tool?

The Problem with EFS

One of the classic problems with an enterprise adoption of EFS is that it's so difficult to be sure that all encrypted data can be recovered using centralized Key Archival. Even though centralized Data Recovery is always an option (once the organization has deployed at least one DRA certificate and they've safely backed up the associated PFX backup file), centralized Data Recovery is still a slow and laborious process:
  1. Backup all the encrypted files
  2. Ship them off to the central Recovery team
  3. Decrypt all the data, and
  4. Ship it back to the user for re-encryption with new keys.

(Please Note: every organization should still preserve the ability to use EFS Data Recovery, in case any of the files has been encrypted by the user with an EFS certificate for which there isn't an available backup. No matter what, if you wish to ensure you can always recover a user's EFS-encrypted files, you should ensure that you have at least one valid DRA certificate with a known, backed-up private key, and that this DRA certificate(s) has been assigned to every Windows PC on which EFS has not been explicitly disabled.)


Many organizations find it preferable to recover a user's access to EFS-encrypted data by keeping an archive of the user's encryption keys and providing a copy of those keys to the user when recovery is required. To do this, many of these organizations (at least those using Active Directory and a Windows Server 2003 Enterprise Edition-based PKI) use the Key Archival feature of digital certificate enrollment by Windows clients to their Windows Server 2003 CA. This can automatically and securely archive a copy of the user's RSA keypair that is associated with the digital certificate issued by their CA.

However, even when the user has enrolled an EFS certificate whose keys are centrally archived in this manner, that doesn't mean that the user's encrypted files can be recovered with that archived private key. The EFS component driver (from Windows 2000 through Windows Vista) will continue to use whichever EFS certificate was originally selected until that certificate expires or its private key is no longer available for decrypting the encrypted files.

Therefore, once you have enrolled a user for an EFS certificate which you want the user to use when encrypting all new files (and to update all existing encrypted files), you must take additional steps to ensure EFS uses the new certificate:
  1. (Required) Update the user's EFS configuration setting i.e. the CertificateHash registry value in the user's HKCU registry hive. (This application does this for you automatically.)
  2. (Optionally) Mark any other EFS certificates as "archived" so that Windows will no longer use the digital certificate, but that the private key remains available in the user's profile (in case the user needs to access files encrypted with the old certificate). Marking a certificate as "archived" in the MY store is a different thing than the Key Archival feature of the Windows Server 2003 (or later) Certificate Server. Archiving the certificate in the local certificate store has no effect on the associated private key (i.e. it is still available for local decryption, but it is not centrally backed up to the CA), which is the most important feature of Key Archival.
  3. (Recommended) Update all encrypted files on the user's PC to use the new, centrally-enrolled EFS certificate. (This is often done with the /U option of the CIPHER.EXE utility, but will also happen gradually whenever the user next opens each encrypted file.)

Finally, note that the EFS component driver will always enroll for a self-signed digital certificate (i.e. a certificate generated on the client, not by a Certificate Authority) if (a) it cannot contact an Enterprise CA and (b) it cannot find a valid EFS certificate in the user's MY store. This means there's often cases where a user who had originally enrolled a CA-generated EFS certificate will later inadvertently encrypt their sensitive data using a self-signed certificate.

Since EFS does not automatically update the CertificateHash setting on its own, I believe it was necessary to build a tool like this. Note: CIPHER /K is intended to help migrate away from self-signed EFS certificates, but it has two problems that ensure it doesn't address this gap:
  1. It is hard-coded to enroll only version 1 certificate templates from a CA
  2. It will fall back to enrolling another self-signed certificate if any problems occur while the client attempts to enroll for a version 1 certificate from the CA

Last edited Oct 27, 2007 at 11:48 PM by MikeSL, version 2


No comments yet.