problem with NTFS file encryption
Hi all
I using NTFS file encryption for preventing others to
use my private files.
Everything is going well,Until Today I get a strange
problem with NTFS file encryption.
Yesterday I repalce my problemed network card with
new one and setup it normally (Only this change)but
it affect my encrypted files and this files can't be
opened again.
WHY?????!!!!!!!
It terrible that lost all of my files!
sincerely yours
Sounds very strange, the encryption keys should not be bound to the hardware in any way, only to the user accounts... Exactly what happens, can you access the harddisk at all? Are there any error messages? Maybe the drive was damaged while you were poking around inside the computer?
No there is no error message
everything work correctly(every file is accessable normaly),
except ones that encrypted before this accident.
Yes, dELTA. It is strange. May be a bug in NTFS part of Windows, because I known the GUID number created with some information of network card.
afshin_pir, what your Windows OS ?
If you still have the old network card (even though it doesn't work quite right), can you just put it back in, decrypt the files, and then replace the card?
I agree, though. This is very strange. Even if GUID's are generated using info about your network card, they don't change once the account is created.
The only explanation I can offer would be if you were using a domain account. If your new card isn't working, you might be logging on with a local account on your computer instead, and just didn't notice. Of course, you'd have to have a local account with the exact same username and password as your domain account for that to work, but it's certainly possible if you're using the "administrator" account. I've seen a lot of windows domains where some admin thought it was safe to use the same password for the local admin account as he uses for the domain admin account.
At any rate, if you had it defined in group policy, there should be at least one recovery account -- usually "Administrator" -- which can decrypt anyone's files.
There are no GUIDS that affect EFS in this way. EFS is handled via your private keys, which you can export from any MMC certificate snapin. It sounds like either a) your private key in the user account certificate store has been corrupted, or b) the files themselves have been damaged in some way. When you say "can't be opened", what do you mean precisely? If a user attempts to open an EFS encrypted file owned by another user, they'll get an "access denied". Otherwise the process is transparent. You could also try dragging them to a FAT32 drive (or floppy), which will cause Windows to decrypt on the copy.
One other option is to log on as the EFS Recovery Agent (local admin if it's a workgroup machine, domain admin if it's in a domain) and use escrow to recover the files.
Still here...
Hi,
It's very strange.
Can you tell me your windows version.
I think you can access your file if you login as administrator.
or if your previous network card is in a perfect condition or you have access to it so try it.
I use it at win2000 and win2003 without any problem.
so tell me your version.
regards
A bit of inside info... Remour control has it that the magic code is generated by your mac address which is lifted from your NIC....
If this is correct (and I am not saying it is; because i haven't peeked, only heard) then I'd guess thats what happened.. And in some ways it makes sence...
If i was 'attain' your HDD, the only thing between your data with encrypted file system and me would be your logon password..
Even if we had the same CPU, motherboard, our NIC's mac address would be different.. So it makes sense...
**Greetz to all the ole school lads who are lurking around**
-=-ADDED-=-
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1='200100 44782'.PGNR.&OS=DN%2F20010044782&RS=DN%2F20010044782
==============SNIP===============
[0015] In one aspect, the system includes a software product resident on a computer, the software product having an associated product ID. The software product generates a hardware ID that identifies the set of hardware components on the computer. In one embodiment, a 64-bit hardware ID that identifies a set of ten hardware components within the computer is derived. The 64 bit hardware ID represents ten different components of the user's computer: the CD-ROM device, the disk adapter, the disk device, the display adapter, the first drive serial number, the MAC address, the processor serial number, the processor type, the RAM size in Mb, and the SCSI adapter. Each time the software product is opened, the expanded H/W ID is compared to the hardware on the computer to determine whether a predetermined minimum number of components match. In one embodiment, the expanded H/W ID allows for expansion of the user's computer because so long as the component originally listed in the expanded H/W ID can be found on the computer, then that component matches the expanded H/W ID. Typically, seven out of ten components in the expanded H/W ID must match the computer before the software product will operate.
==============UNSNIP=============
^----Note MAC addy bit
===============SNIP==============
[0016] In another aspect of the invention, the software product is subsequently launched following installation and the software product retrieves the 64-bit hardware ID. The hardware ID is compared to the set of hardware components on the computer on which the software product is installed. If a suitable match occurs, the software product is enabled to operate on the computer. Otherwise, if a suitable match does not occur, the software product is locked and prevented from operating on the computer. Typically, a suitable match is found when at least seven out of ten components identified by the hardware ID are found in the set of hardware components on the current computer. Thus, the invention prevents a user from installing the software product onto multiple different computers because it uses the hardware ID to identify a specific computer.
=================UNSNIP===============
Now okay yes this is 'mainly' applicable for your WinXP/2003 OS activation stuff.... But Now if I want to encrypt a HDD what would be the easiest way to indentify 'this computer and only this computer'???
Programmers are usually lazy and choose the easiest path.. And why not.. If its good enough to ensure Billy Gates makes more money from reduced sales, surely its a good enough method to lock down your precious file system...
http://www.licenturion.com/xp/fully-licensed-wpa.txt
==========Snipped {last 1 trust me}===============
Our answers to these questions are based on Windows XP Release
Candidate 1 (build 2505). Later builds as well as the final version of
Windows XP might differ from build 2505, e.g. in the employed
cryptographic keys or the layout of some of the data
structures.
==========UNSNIPPED==========================
As I said originally; I've had it mentioned to me; and never wasted the time (nor needed) to look into how it works... but maybe this might help..
Looks like you may a hot little project on your hands if you are curious enough to pursue.. You understand how the product key is created.. now look @ how the file encryption system works..
0100hrs time for a snooze
Hi,
Since only the NIC was changed the files should still be accessable.
The drive still meets the other 9 criteria.
Why was the NIC changed ? Are the files on a network drive ?
Are they on another server outside of the network?
EFS will not work on transferred files IE; you cant send them over a network.
Were they encrypted using a method other then MS encryption?
Given the information, local hard drive and changed NIC, this should not be a problem. I think something else has happened like lost or damaged keys.
Woodmann
Let me just clear up some confusion here.
There is absolutely NO MAGIC WHATSOEVER behind EFS. It doesn't use your NIC's MAC address, your CPU's serial, your hd's volume label or your dog's birthday. It uses an assymetric key system managed via pki certificates. The only Windows system that uses lunar cycles, your wedding anniversary and the average age of your goldfish is the product activation system. EFS has absolutely nothing to do with that.
If you delete the owner keys, the owner loses access to the file. If you delete the EFS recovery agent keys, the EFS recovery agent (usually the local or domain administrator) loses the ability to decrypt ALL files encrypted with the local machine or domain key and any user's key.
EFS is transparent to users. Copy an EFS encrypted file from an NTFS drive to another NTFS drive, it stays encrypted. Copy it to a share on a remote NTFS drive, it stays encrypted. Copy it to a FAT32 disk or share, it is decrypted transparently on the fly. Copy it to a floppy disk (or any other media not NTFSv5 formatted), it will be decrypted transparently on the fly.
Sorry texnass, your statements on EFS are wrong.
Still here...
Mate no problems.. I dont mind being proven wrong.. Never had a need to peek inside or look at how the drive encryption works..
For anyone interested these 2 links explain most of it..
http://www.winntmag.com/Articles/Index.cfm?ArticleID=5387
http://www.winntmag.com/Articles/Index.cfm?ArticleID=5592
Thanks for the correction Silver.
TexNAss
Posting Permissions
Bookmarks