Share via

Key Recovery vs Data Recovery Differences

  • Article

I am often asked when talking to my customers about the differences between Key Recovery and Data Recovery for encrypted files, in addition to which method to use. As a result, This Blog will focus on both areas, explaining the differences and best practices.

Both methods can easily be understood, after understanding the Encrypting File System (EFS) process in a domain environment including certificate enrollment and file encryption 

EFS Certificate Enrollment:

 When a user attempts to encrypt a file without having an EFS certificate the following process takes place: 

  1. The user’s registry (HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash) is queried for an Encryption Certificate
  2. If there isn’t a default certificate, then the user store is queried for any viable certificate with the Encrypting File System Object Identifier OID (1.3.6.1.4.1.311.10.3.4.)
  3. If there isn’t a viable encryption certificate, then the user will request an Encrypting File System certificate based on the BasicEFS template from an Enterprise CA, or any other template superseding it.
  4. If the BasicEFS template is not available at any Enterprise CA, and any other template for EFS is not available then the computer will generate a self-signed EFS certificate. 

Note: I am not a big fan of self-signed certificates especially when there are Enterprise Issuing CAs in a given Active Directory Forest. As a result, I recommend disabling the machine’s ability to generate an EFS Self-Signed certificate using the hotfix for Windows XP or Windows Server 2003

Windows Server 2008 and Windows 7 have a group policy setting which can disable the generation of an EFS Self-Signed certificate simply by unchecking the option to “Allow EFS to generate self-signed certificates when a certification authority is not available.

 

 

File Encryption Process:

 Once the user has a valid Encrypting File System (EFS) certificate, then they can encrypt their files and folders following this process:

  1. The user’s computer generates a random symmetric encryption key called File Encryption Key (FEK)
  2. The computer retrieves the user’s Encrypting File System (EFS) certificate in the user store and obtains the user’s Public Key
  3. The FEK created in step one is encrypted by the user’s Public Key in step 2 

For more information about EFS Encryption, refer to How EFS Works on TechNet

Why Should I Implement Any Recovery Method?

An organization’s security policy typically lists the following reasons for allowing data or key recovery: 

  1. A user profile is deleted. When an encryption private key is stored in a user’s profile folder, the private key is lost if a anyone deletes that specific profile. Many organizations use profile deletion to fix problems with user logon. For example, if the desktop fails or takes a long time to appear, many organizations prescribe deleting the user’s profile and generating a new profile. This results in deletion of the user’s private key material.
  2. A hard disk is corrupted. The corruption of a hard disk can cause users to lose access to their profiles. This can mean a total loss of access or loss of access to the private key material within the user profile.
  3. The operating system is reinstalled. When the operating system is reinstalled, access to the previous user profiles is lost, including any private keys stored in the user’s profile.
  4. A computer is stolen or lost. When a computer is stolen or lost, access to the private key material in the user profile is lost or compromised.

Note: A difference among the reasons listed, however, is that a computer theft or loss can mean the user’s private key is compromised and, therefore, the certificate associated with the private key should be revoked. There is no reason to revoke the certificate for the other reasons in this list because the user’s private key is not compromised.

Where is the File Recovery Agent role in the File Encryption Process?

If your domain has a designated File Recovery Agent certificate enrolled, also known as the Data Recovery Agent, then the computer will retrieve its information from the local computer configuration – deployed through Group Policy – extract the Public Key from the recovery agent’s certificate, and encrypts the File Encryption Key (FEK) with it. This process will apply to all the Data Recovery Agents in the domain. 

Where is the Key Recovery Agent Role in the File Encryption Process?

This is not a trick question; the Key Recovery Agent (KRA) certificate doesn’t come to play at all when encrypting a file a folder. Key Recovery Agent (KRA) is enrolled using the Key Recovery Agent Certificate Template, and then added to the CA configuration. The Key Recovery Agent (KRA) can extract the end user’s Encrypting File System (EFS) Private Key and Certificate from the CA’s database, which in turn can be used by the end user to decrypt their files.

When a certificate template specifies Key Archival, the private key with a certificate request must be securely transmitted from the requesting client computer to the Certification Authority for archival in the CA database. When a client requests a certificate that has Key Archival enabled, the following process takes place:

  1. The client queries the Enrollment Services container in the configuration partition of Active Directory to find an Enterprise CA
  2. The client requests the CA’s CA Exchange Certificate
  3. The client examines the received CA Exchange certificate to ensure it was signed by the CA’s signing certificate, and performs a certificate validation and revocation status check on the CA Exchange certificate
  4. The client encrypts the private key corresponding to the request using the CA Exchange certificate’s public key and send the request to the Certification Authority
  5. The Certification Authority verifies that the encrypted private key is the matched key to the public key, validates the signature on the request with the Public key in request to ensure the contents were not tampered with.
  6. The Certification Authority encrypts the user’s request with a random symmetric key and then encrypts the symmetric key with one or more Key Recovery Agent (KRA) public keys defined in the Certification Authority’s properties
  7. The Certification Authority saves the encrypted key BLOB which contains the encrypted private key and the symmetric key encrypted with one or more Key Recovery Agent (KRA) public keys
  8. Lastly, the Certification Authority processes the request and issues a certificate to the requestor.  

Which Method Should I Use?

There isn’t a correct answer for this question. It all depends on your company’s policies and procedures. It is also important to note that the person or group performing Key Recovery or File Recovery should be trustworthy and held to the highest levels of scrutiny. Understanding the difference between Key Recovery and File Recovery Procedures can help you determine the correct answer to your infrastructure’s requirements.

With Key recovery . The user’s original certificate and private key are recovered from the CA database and restored to the user’s profile. Recovery of the user’s certificate and private key allows the user to access the FEK stored in the EFS-encrypted file, returning access to the file to the user.

The major advantages for Key Recovery are: 

  1. Quick EFS decryption resolution by restoring the user’s Private Key and Certificate
  2. The data doesn’t leave the end user’s computer

The major disadvantages of Key Recovery are: 

  1. The CA has to be prepared for Key Archival and requires the enrollment of Key Recovery Agents before rolling out EFS
  2. The restore of the Private Keys might be a little complicated if the user has multiple Encrypting File System (EFS) certificates.
  3. The Certification Authority must be installed on the Enterprise or Data Center SKU of the Operating System

Data recovery on the other hand, allows a designated EFS Recovery Agent to decrypt all EFS-encrypted files on a computer. By default, where the private key associated with the EFS Recovery Agent certificate exists – which can be a designated recovery computer, or the end user’s computer.

The major advantages of Data Recovery are: 

  1. Data Recovery Agents can be added to the File Encryption Key (FEK) after a user had already encrypted their files. This means a new Data Recovery Agent can be enrolled and added to the domain group policy, which allows the new Data Recovery Agent to recovery encrypted files
  2. The Data Recovery Agent can decrypt the files for the end user
  3. Data Recovery Agents can decrypt files and folders encrypted using self-signed encryption certificates or an encryption certificate issued by an enterprise issuing CA.
  4. It doesn’t have any Certification Authority operating system pre-requisites 

The major disadvantage of Data Recovery is the recovery method itself, because the Data Recovery Agent has to decrypt the end user’s files either on premise or remotely. This can have a significant impact on data transfers from remote sites to hub sites, or vice versa because the encrypted/decrypted data has to be copied twice.

Common Misconception:

A common misconception is that the Administrator account is the Data Recovery Agent (DRA) or the Key Recovery Agent (KRA). Both recovery methods rely on the certificates (Private and Public Key Pairs) of the KRA and DRA, which means anyone who has possession of them can recover keys.  If an end user manages to possess the Data Recovery keys as an example, then they can decrypt any encrypted file in the organization. As a result, you should protect these keys, and establish a chain of custody anytime the key is used. 

Conclusion:

Encrypting File System (EFS) shouldn’t be implemented without proper planning because of complexities in Data and Key Recovery. Make sure to understand both recovery methods before enrolling the first EFS certificate, and test recovery multiple times in a lab environment. Lastly, consider implementing both methods for extra recovery protection

Amer F Kamal

Senior Premier Field Engineer

 

 

Comments

  • Anonymous
    January 01, 2003
    Nice information

  • Anonymous
    August 01, 2012
    Thank you for very useful advices according safe data and key recovery. I would try to follow them. Here I found an article about <a href="www.dataretrieval.com/.../recovering-data-from-disk-after-a-flood-or-flooding.html">recovering data</a> from disk after a flood or flooding. Very interesting, as for me.

  • Anonymous
    June 07, 2013
    What is the difference between "Key Recovery" and "Key Recovery Agent" in the Extended Key Usage options dialog? They really should show the OID after you move the mouse over an item... Maybe you can send them this feedback?

  • Anonymous
    June 10, 2015
    You say
    "Data Recovery Agents can be added to the File Encryption Key (FEK) after a user had already encrypted their files."
    Does this mean that any files encrypted by a user can be decrypted retroactively or that once the key has been added as a DRA any files going forward can be decrypted?

  • Anonymous
    June 13, 2016
    Nice information!!! Thanks for sharing an informative blog with us...

  • Anonymous
    June 23, 2016
    A question on the CA Exchange certificate. When I setup our original CA's (on 2008) about 6 years ago...not knowing exactly what I was doing - I changed the CA Exchange certificate's renewal period to be 5 years (default was 1 week I think) - as I thought that was part of how to make the max length of a certificate be 5 years. Whoops! We replaced our CA's with 2012r2 about 2 years ago...and I forgot to change the template back to 1 week - so the new CA's also have a 5 year CA Exchange certificate issued...and won't be renewed for a couple more years.I changed the template back to 1 week...is there a way I can force the renewal earlier than a couple of years from now without causing any issues with key recovery (for EFS) or something else to break? I thought maybe I could put the certificate on hold (in case the renewal didn't work) and that may make it renew the certificate earlier.Thank you!

    • Anonymous
      February 23, 2017
      Actually I know the answer to this one :)Change the template back to 1 week and revoke the old CA exchange certificate. After it is revoked run the following command to get the machine to generate a new one. certutil -cainfo xchg