深入剖析EFS

继续打开新建的文本文件,现在打不开了

lougout user1,换回刚才的用户登录,试试打开新建的文本文件,没有问题,用户根本感觉不到该文件被加密了,这就是EFS的好处

很显然,刚才的操作说明系统用私钥加密了该文本文件,换用户登录后,因为不同的用户私钥不一样,所以不能打开该文件了。
那么,用户EFS使用的私钥放置在硬盘的什么位置呢?而且这个私钥肯定是和用户的SID相对应的。是不是在注册表中?答案是否定的,因为刚才我们根本没有动过注册表。想起一些网友经常遇到的情况是有EFS加密的文件忘记了解密就重装了系统,有些网友还有重装系统前的注册表备份,但是即使导入前系统的注册表也是无法解密的,所以私钥肯定不在注册表中。
参考了微软官方的一些文档,包括EFS的白皮书(white paper),只有这个说明:“EFS文件使用前不需要解密。当向磁盘存储和从磁盘读取字节时,加密和解密透明地完成。EFS 自动检测加密文件,并从系统密钥存储区定位用户密钥。”,而密钥存放区在硬盘的什么位置,更本没有说明。
经过多次的实验,分析,相同的组里面不同的用户设置的EFS,相互之间也是不能解密的,而这些用户对系统的操作,只有一个地方不同,那就是用户配置文件,存放在Documents and Settings中各不同的用户名字下。将重点锁定这个目录,经过反复实验,比较,得出结论:密钥存放在C:\Documents and Settings\Administrator\Application Data\Microsoft\Crypto\RSA下,如图: 
而S-1-5-21-360507124-1982380022-347760104-500就是我加密EFS文件使用的账户对应的SID,我是用内置的管理员账户直接加密的,可以看到这个SID最后是500,这个标记方法类似于linux对账户的标记
经过实验,发现一个很容易忽略的地方:这个文件夹不是安装系统的时候就生成的,也不是创建该账户时生成的,而是该账户第一次使用EFS的时候生成的,换句话说,如果没有使用EFS加密,该文件夹是没有的!这就会导致另外一个经常出现的问题: 网友经常安装调试好系统以后用ghost做个备份,以备以后恢复系统用。如果在ghost做完以后用EFS加密了文件,系统乱了的时候再从ghost文件恢复,记得一定要先导出证书,不然即使ghost回去的是一模一样的系统,该备份的系统中没有私钥,EFS仍然是打不开的!!!切记。所以ghost即使在同一台机器上使用,也并不是功能较多的,不同的机器使用差别就更大了。
笔者测试了和ghost功能类似的xp自带的系统还原,庆幸的是系统还原能避免这种现象。如果创建还原点以后用EFS加密了文件,回到还原点时,文件仍然是没有加密的,但是在撤销系统还原以后,该文件仍然是没有加密的!所以对于机密数据,在系统还原以后要慎用撤销系统还原功能!
接下来我们来寻找注册表中什么位置标记了用户账户的私钥放置位置呢?用刚才的SID在注册表中搜索,终于找到了,在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-360507124-1982380022-347760104-500中标记了,如图:(图很大,放大到100%才看的清)
四、恢复代理的设置和证书的备份
对于没有加入到域的机器,2000pro和2000server中默认的恢复代理就是内置的管理员账户,这样当管理员误删除了用户账号的时候,即使该用户有EFS加密的文件,管理员也可以打开(参见上面恢复代理的解释)。这样一来,管理员养成了非常不好的操作习惯,就是有员工辞职时,先删除该员工的账号,再来处理其留下的数据(因为即使有EFS加密的文件管理员也能打开的)。而在xp和2003中,内置的管理员账户不再是默认的恢复代理!不知道有多少管理员犯了经验主义错误,按照2000的方法来处理用户账户,导致很多EFS文件打不开了,强烈FT微软这种重大改动不在重要地方说明!
在xp和2003中以默认的管理员备份证书,运行secpol.msc时,提示先添加恢复代理,如图:
接下来先添加恢复代理,这个比较简单了:
以管理员登录计算机,运行:cipher /r:c:\dra