4

After a system reboot (Win7 x64), an application reported that it couldn't access a file in an EFS-encrypted directory.

  • Accessing via programs gave "Access denied".
  • Permissions were normal and fine.
  • The problem affected 2 more, random-selected files.
  • There were no relevant changes or issues in a long time.

So this looked like this question, and indeed, the file was encrypted to a different certificate according to the certificate thumbprint shown in the dialog that pops up when you click "Details" in the "Advanced Attributes" dialog.

But here's the strange thing:

  • Opening the "Advanced Attributes" dialog (from the file properties dialog) took ~10 seconds and 100% CPU, every time, and only for this file.
    Stack traces obtained via ProcessHacker were full of "efscore.dll", "bcrypt.dll", "crypt32.dll", and such.
  • certmgr.msc showed a new EFS certificate that I didn't create myself. It was valid from 3 days ago, and its thumbprint was the one I saw on the file I couldn't access.
  • The export wizard allowed to export that new EFS certificate, but it gave an error message half-way ("Key not valid for use in specified state".) and the file it created didn't actually contain the selected certificate but a different one.
  • On a cloned copy of the system, after a while, the file was accessible again and its contents intact! I inspected the thumbprint of the certificate associated with it, and this time it was the thumbprint of my usual certificate, and not any more that of the newly-created certificate.

So, this makes me wonder about the reliability of EFS.

  1. Why was a new certificate silently created and apparently used for the encryption of a few files?
  2. Why did the certificate associated with the file appear to change?
Improve this question

1 Answer 1

Reset to default
2

After further analysis, I have reached the following conclusion:

The SSD containing the OS has been failing, causing silent, arbitrary data corruption for at least some days.
The observable effects were — in this order — decreased disk performance, maybe minor unspecific software errors, corruption of an EFS certificate's private key, Explorer crashes, BSOD.

This is my reconstruction of events:
Approx. 10-14 days before the incident, Windows for some reason created a new EFS certificate, whose private key became corrupted and thus inaccessible soon after. All the files that are now undecryptable have probably been rewritten after the private key was lost. The erratic behavior of Windows was probably caused by the dying SSD sometimes giving back correct data, sometimes not.

Also, I learnt that Windows may without any errors decode encrypted files to garbage. So being able to decrypt files doesn't prove their integrity. (That is, the SSD may have delivered corrupted data to Windows, but Windows did not detect this when decrypting the files.)

Improve this answer
2
  • Wow. My WinXP Pro system just mysteriously issued a new EFS certificate after a BSOD and I've been trying to troubleshot why. I do have an Intel 530 SSD for system volume. In light of your story, I will run an Extended Drive Self Test to verify the disk.
    – Syclone0044
    Commented Mar 27, 2016 at 21:21
  • 1
    I use CrystalDiskInfo to monitor my drives. My failed SSD had never shown any SMART issues. The long test did get stuck though, I seem to remember. Anyway, I wouldn't place too much trust in SMART readings. I'd rather run badblocks -n -p 2 (warning: some risk of data loss!) on my SSD every X months to ensure fitness and to prevent maximum data retention time from endangering static data. (After using badblocks on an SSD one should manually reissue TRIM commands from within Windows [Samsung Magician can do that].)
    – Norman
    Commented Mar 28, 2016 at 0:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .