Comparing Encryption Key Fault Tolerance Options

Users might lose access to their EFS private keys through cases, like corrupted user profiles, hard disk failure, OS reinstall etc. Now
here are some important facts about EFS Keys before we start the comparison

1-     
A time valid certificate and private keys
needs to be available for encryption/decryption of data

2-     
The client will only check
for revocation status of the certificate, in the case of Encryption, or adding
users to the EFS ACL. In the case of decryption or data access, revocation
checking is not checked. Accordingly, revoking a certificate does not mean that
the user has lost access to data; it only means that he/she cannot encrypt more
files with it. The only way for it to become unusable is if it expires

Key Recovery Agent (KRA)

Key Recovery Agent is I would say the most systematic and
controlled key fault tolerance method available. The reason for this, is that
for key Recovery to occur the following conditions need to be fulfilled

1-     
One or more users need to
have a valid KRA certificate and private key

2-     
Key archival needs to be
enabled on the Issuing CA and on the Certificate template

3-     
By default the Certificate
manager needs to approve the issuance of the KRA certificate

4-     
The CA manager(s) needs to
manually extract a file from the CA Database that contains the intended private
key using the command Cetutil –getkey

5-     
The KRA need to take that
file and decrypt it using his/her KRA private key

From an operational perspective, it is easy to apply
governance to the KRA process especially if proper segregation of duties is
applied. However, it is definitely the most time consuming method, and
practically speaking, it might take the EFS Key owners too long to access files
when they don’t have access to their private keys. The downside of KRA is that,
data encrypted with old EFS keys cannot be recovered since they are not
archived in the CA.

Data Recovery Agent (DRA)

The DRA is a shadow user that has access to EFS encrypted data,
along with data owners and the designated users who have access to the data.

The issue with a DRA is that it is hard to govern the data
recovery process. Practically speaking, if the DRA has access to the data
location, he/she can access it maliciously. One way to govern DRA is use
Forefront Identity Manager or to use smart card n to m authentication for the
DRA user. The upside of DRA is that it provides the fastest recovery time.

Credential Roaming (CR)

Credential Roaming could be in a way looked at as a key
fault tolerance option, because it allows for replicating the local key store from
the user profile located on the computer to the user object on the ADDS. This
is a good option and involves very fast key recovery time. However the downside
of it is that it does not help when key deletion is intentional, since the
local key store will replicate the deletion action. However in cases of hard
disk failure or profile corruption (if the local profile is corrupted), there’s
a big chance that they key on the user object will be retained since the
deletion would most probably not be replicated.