数据防泄露的技术变革

透明加密技术是近年来针对企业数据保密需求应运而生的一种数据加密技术。所谓透明，是指对使用者来说是透明的，感觉不到加密存在，当使用者在打开或编辑指定文件时，系统将自动对加密的数据进行解密，让使用者看到的是明文。保存数据的时候，系统自动对数据进行加密，保存的是密文。而没有权限的人，无法读取保密数据，从而达到数据保密的效果。

自WindowsNT问世以来，微软提出的分层的概念，使透明加密有了实现的可能。自上而下，

应用软件，应用层APIhook(俗称钩子), 文件过滤驱动，卷过滤驱动，磁盘过滤驱动，另外还有网络过滤驱动，各种设备过滤驱动。其中应用软件和应用层apihook在应用层(R3), 从文件过滤驱动开始，属于内核层(R0).

数据透明加密技术，目前为止，发展了3代，分别为

第一代APIHOOK应用层透明加密技术；

第二代文件过滤驱动层（内核）加密技术；

第三代内核级纵深加密技术 ；

第一代：APIHOOK应用层透明加密技术

应用层透明加密技术俗称钩子透明加密技术。这种技术起源于win98时代，后来随着windows2000而流行起来。就是将上述两种技术（应用层API和Hook）组合而成的。通过windows的钩子技术，监控应用程序对文件的打开和保存，当打开文件时，先将密文转换后再让程序读入内存，保证程序读到的是明文，而在保存时，又将内存中的明文加密后再写入到磁盘中。应用层APIHOOK加密技术，特点是实现简单，缺点是可靠性差，速度超级慢，因为需要临时文件，也容易破解。但由于直接对文件加密直观感觉非常好，对于当初空白的市场来讲，这一旗号确实打动了不少企业。

第二代：文件过滤驱动加密技术

驱动加密技术是基于windows的文件系统（过滤）驱动技术，起源于WindowsNT发布之后，其工作在windows的内核层，处于应用层APIHook的下面，卷过滤和磁盘过滤的上面。设计思想是建立当应用程序(进程)和文件格式(后缀名)进行关联，当用户 *** 作某种后缀文件时对该文件进行加密解密 *** 作，从而达到加密的效果。

内核层文件过滤驱动技术，分IFS和Minifilter2类。IFS出现较早，Minfilter出现在xp以后。两者的区别可以理解为VC++和MFC的区别，IFS很多事情需要自己处理，而Minifilter是微软提供了很多成熟库，直接用。由于windows文件保存的时候，存在缓存，并不是立即写入文件，所以根据是否处理了双缓bug，后来做了些细分，但本质还是一样，都是问题的修正版本而已。但由于工作在受windows保护的内核层，运行速度比APIHOOK加密速度快，解决了很多问题和风险。

文件过滤驱动技术实现相对简单，但稳定性一直不太理想。

第三代：内核级纵深沙盒加密技术

之所以叫内核级纵深沙盒加密技术，主要原因是使用了磁盘过滤驱动技术，卷过滤驱动技术，文件过滤驱动技术，网络过滤驱动(NDIS/TDI)技术等一系列内核级驱动技术，从上到下，纵深防御加密。该技术也起源于WindowsNT之后，但由于技术复杂，开发要求高，公开资料少，而发展较慢。但随着微软公布了部分Windows源代码之后，此技术开始逐渐成熟。内核级沙盒加密，是当使用者 *** 作涉密数据的时候，对其存储过程进行控制，对其结果进行加密保存，每个模块只做自己最擅长的那块，所以非常稳定。加密的沙盒是个容器，把涉密软件，文件扔到容器中加密。而这个容器是透明的，使用者感觉不到它的存在。，

第三代透明加密技术的特点是，涉密数据使用前，先初始化涉密沙盒，沙盒加密一旦成功，之后所有的数据都是数据实体，不针对文件个体，所以无数据破损等问题。特点是速度快，稳定。

第一代，第二代本质都是采用的针对单个文件实体进行加密，如a.txt内容为1234, 加密后变成@#$%% +标记。@#$%%是把原文1234进行加密之后的密文。而标记的用途是用来区分一个a.txt文件是否是已经被加密。当系统遇到一个文件的时候，首先判断这个标记是否存在，如果存在，表明是被系统加密过的，则走解密读取流程，如果不是加密的，就无需解密，直接显示给使用者，只是当保存的时候，再进行加密，使其成文密文+标记。

这就带来一个巨大的风险 ：如果是一个较大文件，加密过程中发生异常，标记没加上，那么下次读这个文件的时候，因为没有读到表记，而采用原文读取，然后再加密，那么这个文件就彻底毁坏了。这个现象在第一代APIHOOK透明加密技术的产品中特别明显，在第二代文件过滤驱动产品中，因为速度变快了，使文件破损发生概率减低了很多，但并没有本质解决这个问题。

另外， 由于是进程和文件后缀名进行关联，也造成了一个缺陷 ：很多编程类软件，复杂制图软件的编译，晒图等 *** 作，都是很多进程同时 *** 作某个文件，这个时候进行进程和文件关联显然太牵强了，因为进程太多了。即使进行关联，多个进程交替访问文件，加密解密混在一起，极容易造成异常。所以才会出现VC等环境下如不能编译，调试等。

其他方面，版本管理无法对比，服务器上存放的是密文（服务器存密文，是个极大的风险，目前没有哪家大企业敢这么做，毕竟太依赖加密软件，持续性没有了），大文件速度慢等，一系列问题，无法解决。

而第三代内核纵深加密技术是在前者2个基础之上发展而来的，每个过滤层都只做自己最擅长的事情，所以特别稳定，速度快，性能可靠，不存在第一代和第二代的问题。由于内核级纵深透明加密技术要求高，涉及技术领域广，极其复杂，开发周期长，所以国内的能做开发的厂商不多。目前， 深信达公司推出的SDC机密数据保密系统， 给人一眼前一亮的感觉，其产品是第三代透明加密保密技术的典型产品，其产品主要特点是：

1）采用了磁盘过滤，卷过滤，文件过滤，网络过滤等一系列纵深内核加密技术，采用沙盒加密，和文件类型和软件无关，沙盒是个容器。

2）在 *** 作涉密数据的同时，不影响上外网，QQ,MSN等。

3）保密彻底，包括网络上传，邮件发送，另存，复制粘贴，屏幕截取等，特别是屏幕保密，做得非常炫。

4）服务上存放的是明文，客户端存放的是密文，文件上传服务器自动解密，到达客户端自动加密。服务器上明文，减少了业务连续性对加密软件的依赖。

5）不但可以针对普通文档图纸数据进行保密需求，同时更是研发性质的软件公司( 游戏 ，通讯，嵌入式，各种BS/CS应用系统)源代码保密首选。

1、获得文件全路径以及判断时机

除在所有 IRP_MJ_XXX 之前自己从头创建 IRP 发送到下层设备查询全路径外，不要尝试在 IRP_MJ_CREATE 以外的地方获得全路径，因为只有在 IRP_MJ_CREATE

中才会使用 ObCreateObject() 来建立一个有效的 FILE_OBJECT。而在 IRP_READ IRP_WRITE 中它们是直接 *** 作 FCB (File Control Block)的。

2、从头建立 IRP 发送关注点

无论你建立什么样的 IRP，是 IRP_MJ_CREATE 也好还是 IRP_MJ_DIRECTORY_CONTROL也罢，最要提醒的就是一些标志。不同的标志会代来不同的结果，有些结果是直接返回失败。这里指的标志不光是 IRP->Flags，还要考虑 IO_STACK_LOCATION->Flags还有其它等等。尤其是你要达到一些特殊目的，这时候更需要注意，如 IRP_MN_QUERY_DIRECTORY，不同的标志结果有很大的不同。

3、从头建立 IRP 获取全路径注意点

自己从头建立一个 IRP_MJ_QUERY_INFORMATION 的 IRP 获取全路径时需要注意，不仅在 IRP_MJ_CREATE 要做区别处理，在 IRP_MJ_CLOSE 也要做同样的处理，否则如果目标是 NTFS 文件系统的话可能产生 deadlock。如果是 NTFS 那么在 IRP_MJ_CLEANUP 的时候也需要对 FO_STREAM_FILE 类型的文件做同样处理。

4、获得本地/远程访问用户名（域名/SID）

方法只有在 IRP_MJ_CREATE 中才可用，那是因为 IO_SECURITY_CONTEXT 只有在 IO_STACK_LOCATION->Parameters.Create.SecurityContext 才会有效。这样你才有可能从 IO_SECURITY_CONTEXT->SecurityContext->AccessState->SubjectSecurityContext.XXXToken 中获得访问 TOKEN，从而进一步得到用户名或 SID。记得 IFS 中有一个库，它的 LIB 导出一个函数可以让你在获得以上信息后得到用户名与域名。但如果你想兼容 NT4 的话，只能自己分析来得出本地和远程的 SID。

5、文件与目录的判断

正确的方法在楚狂人的文档里已经说过了，再补充一句。如果你的文件过滤驱动要兼容所有文件系统，那么不要十分相信从 FileObject->FsContext 里取得的数据。正确的方法还是在你传递下去 IRP_MJ_CREATE 后从最下层文件系统延设备栈返回到你这里后再获得。

6、加/解密中判断点

只判断 IRP_PAGING_IO，IRP_SYNCHRONOUS_PAGING_IO，IRP_NOCACHE 是没错的。如果有问题，相信是自己的问题。关于有人提到在 FILE_OBJECT->Flags中的 FO_NO_INTERMEDIATE_BUFFERING 是否需要判断，对此问题的回答是只要你判断了 IRP_NOCACHE 就不用再判断 FILE_OBJECT 中的，因为它最终会设置 IRP->Flags 为 IRP_NOCACHE。关于你看到的诸如 IRP_DEFER_IO_COMPLETION 等 IRP 不要去管它，因为它只是一个过程。最终读写还是如上所介绍。至于以上这些 IRP 哪个是由 CC MGR 发送的，哪些是由 I/O MGR 发送和在什么时候发送的，这个已经有很多讨论了，相信可以找到。

7、举例说明关于 IRP 传递与完成注意事项

只看 Walter Oney 的那本 《Programming the Microsoft Windows driver model》里介绍的流程，自己没有实际的体会还是不够的，那里只介绍了基础概念，让自己有了知识。知道如何用，在什么情况下用，用哪种方法，能够用的稳定这叫有了技术。我们从另一个角度出发，把问题分为两段来看，这样利于总结。一个 IRP 在过滤驱动中，把它分为需要安装 CompleteRoutine 的与无需安装 CompleteRoutine 的。那么在不需要安装 CompleteRoutine 的有以下几类情况。

(1) 拿到这个 IRP 后什么都不做，直接调用 IoCompleteRequest() 来返回。

(2) 拿到这个 IRP 后什么都不做，直接传递到底层设备，使用IoSkipCurrentIrpStackLocation() 后调用 IoCallDriver() 传递。

(3) 使用 IoBuildSynchronousFsdRequest() 或 IoBuildDeviceIoControlRequest()来建立 IRP 的。

以上几种根据需要直接使用即可，除了一些参数与标志需要注意外，没有什么系统机制相关的东西需要注意了。那么再来看需要安装 CompleteRoutine 的情况。我们把这种情况再细分为两种，一是在 CompleteRoutine 中返回标志为STATUS_MORE_PROCESSING_REQUIRED 的情况。二是返回处这个外的标志，需要使用函数IoMarkIrpPending() 的情况。在 CompleteRoutine 中绝大多数就这么两种情况，你需要使用其中的一种情况。那么为什么需要安装 CompleteRoutine 呢？那是因为我们对其 IRP 从上层驱动，经过我们驱动，在经过底层设备栈返回到我们这一层驱动时需要得到其中内容作为参考依据的，还有对其中内容需要进行修改的。再有一种情况是没有经过上层驱动，而 IRP 的产生是在我们驱动直接下发到底层驱动，而经过设备栈后返回到我们这一层，且我们不在希望它继续向上返回的，因为这个 IRP 本身就不是从上层来的。综上所述，先来看下 IoMarkIrpPending() 的情况。

(1) 在 CompleteRoutine 中判断 Irp->PendingReturned 并使用 IoMarkIrpPending()然后返回。这种方法在没有使用 KeSetEvent() 的情况下，且不是自建 IRP 发送到底层驱动返回时使用。也就是说有可能我所做的工作都是在 CompleteRoutine 中进行的。比如加/解密时，我在这里对下层驱动返回数据的判断并修改。修改后因为没有使用 STATUS_MORE_PROCESSING_REQUIRED 标志，它会延设备堆一直向上返回并到用户得到数据为止。这里一定要注意，在这种情况下 CompleteRoutine返回后，不要在碰这个 IRP。也就是说如果这个时候你使用了 IoCompleteRequest()的话会出现一个 MULTIPLE_IRP_COMPLIETE_REQUEST 的 BSOD 错误。

(2) 在 CompleteRoutine 中直接返回 STATUS_MORE_PROCESSING_REQUIRED 标志。这种情况在使用了 KeSetEvent() 的函数下出现。这里又有两个小小的分之。

1) 出现于上层发送到我这里，当我这里使用 IoCallDriver() 后，底层返回数据经过我这一层时，我想让它暂时停止继续向上传递，让这个 IRP 稍微歇息一会，等我对这个 IRP 返回的数据 *** 作完成后（一般是没有在 CompleteRoutine中对返回数据进行 *** 作情况下，也就是说等到完成例程返回后再进行 *** 作），由我来调用 IoCompleteRequest() 让它延着设备栈继续返回。这里要注意，我们是想让它返回的，所以调用了 IoCompleteRequest()。这个可不同于下面所讲的自己从头分配 IRP 时在 CompleteRoutine 中已经调用 IoFreeIrp() 释放了当前IRP 的情况。比如我在做一个改变文件大小，向文件头写入加密标志的驱动时，在上层发来了 IRP_MJ_QUERY_INFORMATION 查询文件，我想在这个时候获得文件信息进行判断，然后根据我的判断结果再移动文件指针。注意：上面是两步，第一步是先获得文件大小，那么在这个时候我就需要用到上述办法，先让这个 IRP传递下去，得到我想要的东西后在进行对比。等待适当时机完成这个 IRP，让数据继续传递，直到用户收到为止。第二步我会结合下面小节来讲。

2) 出现于自己从头建立 IRP，当使用 IoAllocate() 或 IoBuildAsynchronousFsdRequest()创建 IRP 调用 IoCallDriver() 后，底层返回数据到我这一层时，我不想让这个 IRP 继续向上延设备栈传递。因为这个 IRP 就是在我这层次建立的，上层本就不知道有这么一个 IRP。那么到这里我就要在 CompleteRoutine 中使用 IoFreeIrp()来释放掉这个 IRP，并不让它继续传递。这里一定要注意，在 CompleteRoutine函数返回后，这个 IRP 已经释放了，如果这个时候在有任何关于这个 IRP 的 *** 作那么后果是灾难性的，必定导致 BSOD 错误。前面 1) 小节给出的例子只完成了第一步这里继续讲第二步，第一步我重用这个 IRP 得到了文件大小，那么这个时候虽然知道大小，但我还是无法知道这个文件是否被我加过密。这时，我就需要在这里自己从头建立一个 IRP_MJ_READ 的 IRP 来读取文件来判断是否我加密过了的文件，如果是，则要减少相应的大小，然后继续返回。注意：这里的返回是指让第一步的IRP 返回。而不是我们自己创建的。我们创建的都已经在CompleteRoutine 中销毁了。

8、关于完成 IRP 的动作简介

当一个底层驱动调用了 IoCompleteRequest() 函数时，基本上所有设备栈相关 IRP 处理工作都是在它那里完成的。包括 IRP->Flags 的一些标志的判断，对 APC 的处理，抛出MULTIPLE_IRP_COMPLETE_REQUESTS 错误等。当它延设备栈一直调用驱动所安装的 CompleteRoutine时，如果发现 STATUS_MORE_PROCESSING_REQUIRED 这个标志，则会停止向上继续回滚。这也是为什么在 CompleteRoutine 中使用这个标志即可暂停 IRP 的原因。

9、关于 ObQueryNameString 的使用

这个函数的使用，在有些环境下会有问题。它的上层函数是 ZwQueryObject()。在某些情况下会导致系统挂起，或者直接 BSOD。它是从 对象管理器中的 ObpRootDirectoryObject开始遍历，通过 OBJECT_HEADER_TO_NAME_INFO 获得对象名称。今天问了下 PolyMeta好象是在处理 PIPE 时会挂启，这个问题出现在 2000 系统。在 XP 上好象补丁了。

10、关于重入问题

其实这个问题在很久前的 IFS FAQ 里已经介绍的很清楚，包括处理方法以及每种方法可能带来的问题。IFS FAQ 里的 Q34 一共介绍了四种方法，包括自己从头建立 IRP发送，使用 ShadowDevice，使用特征字符串，根据线程 ID，在 XP 下使用IoCreateFileSpecifyDeviceObjectHint() 函数。并且把以上几种在不同环境下使用要处理的问题也做了简单的介绍。且在 Q33 里介绍了在 CIFS 碰到的 FILE_COMPLETE_IF_OPLOCKED 问题的解决方法。

---