本文深入探讨了基于进程的透明加密技术在文件加密市场的应用，特别是如何处理文件缓存带来的安全问题。通过分析Windows操作系统对文件读写的缓存机制，提出了通过不断刷新文件缓存以确保加密文件在授权与非授权进程间的正确加解密。然而，作者引用英国专家的观点指出，快速解决此类问题可能带来后续难以预见的问题。文章随后反思技术路线，强调了底层文件系统层（如dmk的LayeredFSD）的重要性，并提出了持续优化和解决技术难题的思考。
一直以来，基于进程的透明加密技术是国内文件加密市场运用最为广泛、而且也最能 为用户认可的技术。该类技术有一个最基础的问题，即加解密需要区分不同的进程，一般称为加密进程和非加密进程 或者是授权进程和非授权进程（下面我们统一简称为 授权进程和非授权进程 ）。
基本的需求是：授权进程操作的文件需要加解密：如word进程操作 doc文件 就需要加解密，而非授权进程 比如 explorer.exe 在拷贝文件的时候 就不需要加解密。这样在普通的文件拷贝和黏贴操作中 加密的文件就始终保持密文状态，从而防止文件的泄密。
但是Windows操作系统的设计中，为了提高效率，对文件的读写使用了缓存。这样一个加密文件如 a.doc 在被 授权进程 如 word.exe 打开过一次后 文件的内容就已经解密后被缓存到了操作的缓存管理器（CM）。此后任何进程对该文件的读写都首先检查缓存是否有该文件的内容。如果应用程序使用 FileMaping（一种对文件读写抽象技术）来读取文件的话，甚至不会发出任何的IRP请求包，这样基于文件过滤器的透明加密产品根本没有机会去处 理。
这样就不能满足刚才我们所说的基本要求，在osr的ntfsd新闻组 你会经常看到国内的程序员在咨询这样的技术问题。在单纯的文件过滤驱动中 最迅速的解决方式就是 不断的刷新文件的缓存，使得任何进程对加密文件的访问都发出 非缓存方式的IRP读写，然后根据进程的不同，授权进程的读写就加解密，而非授权进程的读写不加解密。貌似这样的方案是能够很快的解决问题，但直到有一天 我看到有个英国的老外回复了一句很有深意的话，大意是这样：“用2分钟的时间 完成了这个需求 但是你得用10年的时间来解决由此带来的问题”。
此后在基于MiniFiler的SEFS2..0系列的项目实施过程中发现，尽管你通宵达旦的熬夜去解决某个问题，而 且似 乎问题也得到了解决。但其实另一个问题同时又产生了。
由此我们开始反思技术路线，尽管此时 osr 的 dmk 已经发布了 3 年之久。但在这以前我们一直认为 dmk 的存在只是为了展示技术的先进性，而不能想到 dmk 为什么要做LayeredFSD。
待续。。。。。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
