Alternate certificate replacement

Oct 25, 2007 at 7:27 PM
Seeing as I am a victim of the installer not working (I voted on the issue that I am experiencing), is there another way of forcing the OS to use the CA-issued certificate, as opposed to an existing self-signed certificate (SSC)?
I'd like to not have to:
  1. Decrypt user files
  2. Backup self-signed certificate
  3. Remove SSC
  4. Import CA-issued certificate
  5. Re-encrypt all files

I have about 120 laptops users out there, and they are not always connected to the network. I am sure that something like System Center would help with reporting and such, but I don't have that deployed yet.

How can I force a computer to use the CA cert, and to update the existing encrypted files?

Thanks!
Coordinator
Oct 26, 2007 at 4:52 PM
Thank you for bringing this issue to my attention, and I'm sorry that the installer was so broken.

I have uploaded a new installer for this utility which should resolve the installation problems you and others have experienced, so hopefully you won't need a manual solution for your SSC migration. Please download version 1.1 and try it, and please let me know if there are still problems (same or new).

Now, for the record I would like to address one aspect of the steps you've outlined that shouldn't be necessary (with or without this utility):
  • If you update a user's EFS configuration to use a new digital certificate, you shouldn't need to decrypt the user's files
  • There are two ways that you could avoid this time-consuming (and insecure, of course) extra step:
    • Manually overwrite the certificate hash currently in the Registry's CertificateHash setting with the value of the CA-issued certificate - this is difficult to get right, and is a daunting task for most non-programming-friendly systems administrators (of which I was one up until a year ago), which is why I created the EFS Certificate Configuration Updater utility in the first place
    • First remove the SSC certificate (but leave behind the certificate's private key) and then import/enroll the CA-issued certificate - this has the effect of setting up EFS to look for (but not find) its old certificate, and find the new one, but also leave it with the ability to decrypt existing files (with the old cert's private key) so it can update those files with the new cert
  • Once you take one of those steps, then you can simply run CIPHER.EXE /U to "update" all encrypted files to use the new certificate
    • The trick here is that EFS doesn't have to decrypt each file's contents - it just has to decrypt the FEK (file encryption key) that is stored in the DDF (data decryption field)
    • That is, EFS decrypts the user's copy of the FEK with the old private key, and encrypts it again with the new EFS certificate('s private key)

The reason I emphasize this point is that the update operation takes significantly less time than decrypting & encrypting all the files themselves:
  • In both cases, EFS has to decrypt the FEK using the original private key
  • In the update scenario, EFS then only has to perform the RSA encryption operation on the FEK (which is a very small piece of data - e.g. 256 bits of data for an AES key, plus a little metadata)
  • In the decrypt-then-encrypt scenario, EFS has to perform the symmetric decryption on the file's content (which is usually much larger in size than a 256-bit key) and another symmetric encryption operation on each of the files again.

I try to avoid decrypt-then-encrypt whenever possible - not that it shouldn't ever be done, but when we're talking hundreds or thousands of PCs, that's hundreds or thousands of hours of extra time consumed for something that (with the right tools) should not be necessary. Hopefully the EFS Certificate Configuration Updater will help achieve that savings of time.