本文共 5005 字，大约阅读时间需要 16 分钟。

简介

        在我多年致力于微软基础架构及企业部署的工作中，微软文件加密系统（Microsoft’s Encrypting File System，EFS）是我迄今为止见过的最强大的加密技术之一，但其中大多数安全功能却并未被充分利用到。我很少看到这种技术应用在企业级或中等规模的开发环境中，即使有，也只是个人或团队将其作为他们自己基于EFS安全控制中一些孤立的实例来使用。这样做是有一定的道理的。EFS易于进行个人设置和自主使用，但在大规模正确部署EFS时，就需要对其许可、恢复代理管理、备份、存储以及实现访问模型方面进行详细的计划。错误部署EFS可能导致失去对数据的访问权等严重的后果。为了说得更加具体一些，假设基于一个失败的场景，不合适的EFS控制设计可能导致在文件系统中无法对已加密的文件解密。虽然这个问题可以通过实体存储层去解决。

       EFS最简单的形式是一个基于Windows操作系统的特性，它允许用户（以管理员或其他身份）对文件夹或单个文件的内容进行加密。最典型的应用是使用EFS在文件夹层次上进行加密，因为它确保了所有添加到加密文件夹的文件都会自动进行加密。当然，也可以选择对单个的文件进行加密，本章使用的例子是基于对目录结构下创建的文件夹进行的，当选中一个文件夹并为之加密时，文件夹将标记为已加密。如前所述，当文件夹加密后，该文件夹内的所有文件都将被其各自的所有者加密。对文件夹进行加密非常简单；只需点击文件夹的高级属性，勾选“加密内容以便保护数据”即可，如图2.1所示。

       EFS是一种基于用户的加密控制。其基本工作方式为：当用户请求对一个文件或文件夹进行加密时，EFS为用户生成一个证书并将其私钥存放在用户的配置文件中。公钥与用户创建的文件一同存储，只有这样用户才能解密这些文件。正是因为如此，恢复代理证书通常与不同的用户帐号相关联，且这些用户的公钥也嵌入到该文件中。即使用户丢失了用来加密文件的证书，而恢复代理用户，或更具体地说是相关私钥的持有者也能将文件解密。同样，恢复代理的公钥是自动和加密文件一同存储的，也可以为文件分配其他用户的公钥，以便允许他们解密文件。这就允许了多个用户共享一个已加密的文件。当EFS证书通过CA（证书管理机构）分发，或在某个域环境中EFS操作第一次请求时而自动创建，用户证书的公钥存储在AD当中。对恢复代理认证同样如此，实际上，公钥自动包含在域中创建的EFS文件的方式为：在基于策略设定的AD上直接将文件恢复组织策略对象提取出来。我将在后续章节对此进行详细讲述。

       让我们花点时间详细讲述加密过程。当涉及到多个用户共享一个加密的文件时，了解其工作原理和加密处理层面上的相关知识有助于更好地理解EFS是如何在企业或更小的AD环境中工作的。EFS证书并没有什么神奇的。它只不过是一个用EFS作为密钥的X.509证书，是基于Rivest, Shamir, and Adleman (RSA)算法生成的一对私/公钥，如图2.2所示。

       当为用户创建证书时，系统采用RSA算法生成公钥和私钥，并将它们存放在用户证书当中。只有公钥存放在AD当中。数据使用公钥进行加密，私钥进行解密。这就是为什么公钥是公开的原因，因此，其他用户可以为你加密数据，而只有持有私钥的人才能对数据进行解密。这样，即使用户使用公钥对数据进行加密后，也不能立即对数据进行解密。

       在我认识的大多数人当中，似乎他们对RSA密钥的印象是其用来对已加密的文件中的实际数据进行加密和解密工作的。其实这适用于所有基于RSA的加密方式，而不仅仅是EFS。实际情况是，在文件加密之前，已经生成了一个强随机的密钥。在这种情况下，该密钥基于默认的高级加密标准（Advanced Encryption Standard，AES)的密码。实际上，RSA算法加密的是密钥，而不是数据本身。RSA公钥用于加密AES密钥，而AES密钥则是用来加密实际数据的。

RSA和AES

       RSA是一种非对称的加密算法。其使用一个密钥对数据进行加密，而采用其他密钥进行解密。这种类型的加密运算量是非常大的。实际上它的运算速度取决于处理器，在使用相同的密钥进行加密和解密的情况下，该算法比对称密码的运算要慢得多。一般的方式为：使用RSA公钥加密AES密钥，用户使用对应的RSA私钥解密AES密钥。这样就对文件进行了加解密。每次向拥有加密文件权限的用户列表中添加用户时，系统会生成新的AES密钥。列表中的每个用户都可以用其公钥加密这个AES密钥，只有这个用户能用对应的私钥进行解密。

       究其原因，是因为RSA密码可加密的文件数据量取决于其密钥长度。一个1024位（bits，下同）的RSA密钥可加密大约116字节的数据。这个加密量并不高。而2048位的RSA密钥可加密大约245字节（Bytes）的数据。这是因为：如果文件是由RSA方式生成的公钥加密的，那么该文件只能用其对应的私钥来解密。AES密钥却没有限制加密信息长度。AES用来分组加密文件，正因为如此，任意长度的文件都可以进行分组并加密，最后将加密后的内容输出到一个文件中。这种类型的加密方案产生了两种攻击途径：一种是攻击RSA密钥，另一种是攻击AES密钥。如果可以破解AES密钥，那么加密该密钥的RSA密钥再强大也无济于事。这就正是使用强加密密钥的原因。下面是一个使用Base64编码的256位AES密钥，该密钥使用2048位RSA密钥加密。

256位密钥。。。        真正的密钥本身要比上面字符串长度小很多，但通过这个例子我们对密钥有了基本认识。如果使用简单的词组如“bananadog”作为生成的AES密钥的密码，对这种简单密码暴力破解会比较容易，而对不基于密码组合的强加密密钥的破解则要相对困难一些。针对2048位的RSA密钥破解要更难。下面是有意生成的一个小例子，为一个用BASE64编码的2048位RSA私钥，其公钥可以从由C#实现的RSA加密服务提供者模块中获取。 2048位密钥。。。        试图通过蛮力破解该密钥需要大量的时间，所以通常认为蛮力破解是不可能的。目前，即使考虑摩尔定律对计算机性能增长的贡献，通过计算来破解2048位的RSA密码也被认为是不可能的。形象的来说，即使我们坐在餐厅中靠窗的位置一直等到宇宙毁灭，密码也破解不了。 但这只是以现在的眼光看待这个问题，谁又知道未来会怎么样呢。加密模型的描述见图2.3中的示意图。       一般认为AES是一种对称加密算法。但在利用AES算法生成密码时，也可为密码配置不同的加密方式，如椭圆曲线加密。对于公共环境中连续加密的方式，我设计编写了一个可自由使用的Windows加密程序，我称之为Thor’s Godly Privacy (TGP)。 提示：        由于种种原因，我不喜欢 Gnu Privacy Guard加密软件的标准，也不喜欢商业版的Pretty Good Privacy加密软件。所以我编写了TGP软件中，在该软件中用自己的方法进行加密数据通信和密钥分发。您可以在我的网站上获得更多关于TGP的信息：www.hammerofgod.com/tgp.aspx。 EFS计划和故障排除        有关EFS的最常见的问题之一是关于证书的妥善管理和恢复计划。我不想在EFS管理上花费太多的时间，但我会说明如何在管理员没有意识到的情况下创建一个恢复项。 最佳计划        先讲一个小故事。你在一个不断发展的组织中，该组织的管理员不停的换人，但政策规定需要对相关领域和企业管理员帐户进行精心控制和管理。当然，这并不会经常发生，但假设本例中出现了这种情况。在过去EFS的使用中，EFS文件的表现都挺不错的。例如：假设有一个已加密的EFS目录，目录下有一个名为Splinter.txt的文件，该文件中包含了成功通关游戏的所有步骤。该EFS文件的访问属性应该与图2.4中显示的相同。        看上去没什么问题，可是一旦系统崩溃，那么就不得不重建一个新的文件。更进一步地说，假设所有的数据存放在系统中互相独立的磁盘中，如果只需要备份一个磁盘，那么事情将变得简单。启动并运行系统，加载数据磁盘，访问SplinterCell.txt，获得如图2.5所示的对话框。        我们发现不能打开Splinter.txt文件，也不能打开其他已加密的文件。这时，可通过查看文件的EFS属性来了解谁可以对这个文件进行访问，如图2.3所示。我们发现用户可以访问文件，且管理员是恢复代理 。当正在使用中的电脑死机时，包含用于加密文件的私钥的EFS证书将存放到旧系统的配置文件当中。创建任何新的加密文件都会产生一个新的EFS证书（首次创建时，EFS将询问并要求创建证书），该证书将在后面继续使用。但这基本上没什么用。因为我们一般都是直接将文件清除了。然后不得不去乞求管理员，让他恢复你的数据。管理员将你的硬盘接到电脑上，以管理员的身份登录，找到SpinterCell.txt文件并打开，此时将出现如图2.6所示的欢迎对话框。        管理员再次检查文件，查看管理员账户是否真的是恢复管理，但这样做也无法打开文件。于是管理员决定将EFS属性中的证书指纹与域管理员帐户中的进行比较，如图2.7所示。        管理员会说“啊哦”，指纹不匹配，不能打开文件。这不是正确的证书。很明显，一般都认为证书指纹是由恢复策略定义的。管理员启动组策略管理器 （Group Policy Management Editor ），并在计算机|Windows设置|安全设置|公钥策略中可用的GPO中搜索和检查EFS条目。可看到GPO引用的证书（见图2.3顶部），打开并展开证书的属性，如图2.8所示。        看！指纹匹配了！证书上的金色标志的私钥帮管理员解围了。管理员现在所要做的是将证书和相关的私钥导出并安装到系统上，然后就可以恢复数据了。他会被用户当作英雄来崇拜。但当他导出文件时，将会看到如图2.9所示的对话框。        “啊哦”，没有私钥。不应该发生这样的问题的。这是因为证书是在用户的系统上创建的，其系统管理使了一些小伎俩。由于他们安装了自己的微软证书服务（Microsoft Certificate Services），管理员所要做的是展开证书列表，查找所有的证书项，在相应的证书中用指纹匹配的方法查找出其管理员用户。于是他进入CA管理控制台，按指纹对所有证书项进行排序，如图2.10所示。        “啊哦”，这里没有d2 43 57 e0 0f 45 d0 d6 1e d4 73 5a 7e b3 52 09 86 35 0e 50 指纹项。由于CA没有发布该证书，也就没有持有该证书的用户。用密钥加密的数据在系统中根本就不存在，而且也没办法找回来。 且据我所知，在这种情况下，不存在超级黑客或后门可以恢复数据，哪怕是王母娘娘也不能让管理员恢复数据。一个糟糕的结局。 后期用例分析

        这里解释下发生了什么。在创建域时，也就创建了域控制器，并在第一个域控制器上为管理员创建恢复证书。恢复证书存储于管理员用户的证书存储区，且在AD中存储一份其公钥证书的副本，并将其设置为恢复代理证书。当管理员首次转出EFS时，要特别注意上述概念。当然，也可以添加其他域控制器，但如果系统出现了某些情况导致第一个域控制器转出，那么将导致默认的恢复证书消失。在部署EFS时，需要注意两个方面，一是需要针对系统为恢复代理创建一定数量的信任帐户，二是需要备份这些私钥的证书并存储在一个安全的位置。

        现在建立一个常见的可运作的例子：基于网络的文件访问。该案例利用EFS和IIS一同大幅度增加安全系数。         虽然我选择这个平凡而常用的功能来作为示例可能有点令人惊讶，但这的确是经过深思熟虑的。 安全可不是说说而已。所以 我提出了一个相当复杂的网络设计，形象的来说，该网络由互相链接的交织的线和重叠的盒子组成。该网络模型难以建立，部署该模型的难度等同于同级别的安全问题。为该网络模型构建维护计划留给读者自己了，因为其内容超出了本书的范畴。我不会探讨过多关于管理和操作方面的知识，毕竟这是一本关于安全方面的宝典。这样做算是一种逃避，会让读者永远不会尝试这种模型。安全应该是简单和可持续的。但并不是意味着本书中的例子都是简单且易配置的。 本书的基本前提是设计一个能产生可重复结果的可记录和部署的安全控制基础架构。

转载地址：http://igrti.baihongyu.com/