Encryption is always a double-edged sword making backup of certs or passwords or data doubly important. I doubt there's anything that can be done.
Im a tech with the USAF and I have a customer that brought in a laptop that he had encrypted files on it with his smartcard. He then came to this base and tried to access the files with the same smartcard, but it is telling him access is denied. Either the encryption became corrupt or the certificates on the card have. Either way I really need to get into these files for him, is there anyway to do this?
Was the encryption only begun recently, or from way back?
Any images/backups/restore-points from before the point in time when encryption began?
If you did, how many files would not be included in those?
The encryption is probably about4 months old. He said it was working for a short period and then it all of a sudden started telling him access is denied. Only one folder is encrypted, but it has about 150 files within. Do you think it may be a certificates issue? At first when I went into the details of the encryption it was telling his cert was not trusted. So I imported it into the trusted root authority and it started to trust it, but it still gives me acces is denied. Would a system restore fix this problem?
I was assuming, probably incorrectly, that this was third-party encryption and not Native Windows NTFS using EFS but I now realise that Windows EFS is available via SmartCards on some or all versions of Vista using an appropriate CSP.
Under WinXP Pro's EFS an Administrator could retrieve a Recovery Agent's certificate or a User could retrieve the original User's certificate by simply importing the backed-up .cer, .pfx, etc, file (the password to import it would need to be known of course) from Internet Explorer >> Tools >> Internet Options >> Contents >> Certificates >> Import.
It's probably the same under Vista so if the relevant cert can be exported from the SmartCard and then imported in the above manner you may be OK unless it works differently under Vista or the certs cannot be exported from the smart card in an un-damaged or usable way.
If this is another OS or if it is a third party encryption system then the approach would need to be different.
There's quite a good read-up of Using File Encryption in WinXP-Pro that may give some other pointers.
You say you have the Root Certificate Authority trusting it but if there is still some problem access the cert via the SmartCard you might overcome things by importing the cert as above.
I notice some interesting info included in the linked article on encryption that might be used to obtain access to the files and/or decrypt them:
To keep your encrypted files and folders secure, you need to apply several strict conditions. For example:
* Your computer must use the NTFS file system.
* You need a strong user password.
* Always set the BIOS to require a password and then disable the floppy disk boot option. This prevents someone using a utility like NTFSDOS to read files without having to provide a username and password.
* Rather than encrypt individual files, you should encrypt folders like the My Documents folder.
* To ensure temporary files are encrypted, also encrypt the %TEMP% and %TMP% folders.
* Never copy encrypted files to a FAT volume (including floppy disk) or to an NTFS volume running Windows NT; otherwise the files will be decrypted.
Do site rules permit me to point this out Paul?
I don't think that it is particularly problematic because the best that NTFSDOS can do is to read files on NTFS volumes that are not encrypted. That is no more, functionally, than accessing the drive from another NT-based OS could do in its own right. I say functionally because any way of accessing the files from any other OS be it Linux, DOS or whatever may be able to access the files, as such, but will only see encrypted "garbage" on them. That's the point of the encryption and the only way, without cracking the encryption, of accessing the data is to brute force any passwords set for the user log-on or for the certificates that can unlock the access. Those areas would however definitely be outside the remit or policies of these forums.
As for copying the files to a FAT volume that can be either a fix or a liability and I think the article is just pointing out that it is a way to remove encryption that users may not be aware of. To use the Windows EFS the partition(s) must be, de facto, NTFS formatted and the OS must be a relevant version such as WXP Pro but not Home. And the user must first be able to access the files before they could be copied, which is not the situation to date.
It doesn't help the situation here because the user or admin when logged on cannot access the files. I have also simply guessed that it is Vista and a SmartCard but there are other methods "out there". If this is Windows EFS then, without access to the user or recovery agent certificate, getting access is going to be all but impossible.
Just did a bit of experimenting to be quite sure. Knoppix and WinXP Home and WinXP Pro can all navigate to an encrypted file on another installation but cannot access it in any way via the file system. Part of the point being that much of the file header information is encrypted into the bargain as well as the file's own data. Using a forensic Hex Editor such as WinHex one can however locate the hex on the relevant cluster(s) only to find, of course, that it is all garbled.
Of additional interest to those that want to know such things, is that the hex of a file before encryption is normal and if composed of text is completely readable. After encryption the same sectors are found to be zeroed (yes actual zeros) and the encrypted data is now to be found on a different location of the hard drive altogether.
The significance of this is I suspect twofold. Firstly one cannot do a search of the disk for any of the original unencrypted data because it has actually been zeroed as part of the encryption process and secondly I doubt if system restore, which works via the file system pointers as far as I know, could thus find the original data even if it still had the file pointers in its collections.
There are currently 1 users browsing this thread. (0 members and 1 guests)