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

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

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

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

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

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

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

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.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.