把加解密放进文件系统微过滤驱动，难点不在密码算法。AES-256、SM4 都是标准化原语，调用库函数即可。工程复杂度分布在三个位置：过滤回调在什么上下文中被调用、密文容器如何组织才能让应用层看到的文件语义不变、密钥封装链在断电和离线条件下如何保持可解。下面按这三条线索展开。
一、过滤回调的上下文问题
微过滤驱动通过 FltRegisterFilter 注册 FLT_REGISTRATION，按 altitude 挂入过滤栈，对 IRP_MJ_CREATE、IRP_MJ_READ、IRP_MJ_WRITE、IRP_MJ_SET_INFORMATION、IRP_MJ_QUERY_INFORMATION、IRP_MJ_CLEANUP 等主功能码注册 pre/post 回调。回调拿到的是 PFLT_CALLBACK_DATA，通过 Iopb->Parameters 取缓冲区和参数。
第一个约束是文件名与进程身份的取得时机。pre-create 阶段可用 FileObject->FileName 拿到路径，但那是相对路径且可能是短名；规范化的绝对路径要调 FltGetFileNameInformation，而该调用本身可能触发 I/O 重入。稳妥做法是在 post-create 里取 FLT_FILE_NAME_NORMALIZED，并配 FLT_FILE_NAME_OPENED 区分“打开路径”和“最终路径”——重命名、硬链接、符号链接都会让两者分离，而加密策略若按路径匹配，判定必须落在最终路径上。进程身份则通过 FltGetRequestorProcessId 取得 PID，但 PID 可复用，真正的授信判定通常要拿进程映像的文件哈希或签名，这一步必须在驱动侧缓存，否则每个 I/O 都去校验会拖垮吞吐。
第二个约束是缓存一致性与写路径选择。post-write 阶段缓冲区的数据已被 Cache Manager 接收并可能已标记为脏页，此时在回调里原地修改缓冲区来加密，并不改变后续由内存管理器发起的 paging write 所写出的内容，明文仍可能落盘。可行路径有二：一是在 pre-write 中返回 FLT_PREOP_COMPLETE，自己构造并同步发起加密后的写（FltAllocateCallbackData + FltPerformSynchronousIo），代价是要处理自发起 I/O 被自身回调再次拦截的重入，通常用实例上下文或 TopLevelIrp 检测来区分；二是走 FLTFL_OPERATION_REGISTRATION_SKIP_CACHED_IO 之外的完整拦截，接受额外的 I/O 放大。两者都是真实存在的取舍，选择取决于是否容忍备份、杀毒等第三方进程读到密文页。
第三个约束是paging I/O 与内存映射。应用用 CreateFileMapping 映射文件后，页错误触发的读由内存管理器以 paging I/O 发起，此时进程上下文是 System，FltGetRequestorProcessId 拿到的不是发起映射的进程。这意味着“按进程授权解密”的判定在 paging 路径上失效。可用的替代信号是文件对象的 stream handle context：在 create 阶段判定授权状态并挂接到文件对象，后续 paging 读沿同一文件对象传播，即可复用该判定。同步读写还可能走 FastIO 路径绕过 IRP，需要评估是否注册对应回调，否则小文件读写会出现“有时加密、有时不加密”的行为分裂。
二、密文容器与文件语义的保持
密文并非整文件密文替换明文。文件头部要携带足够解封所需的元数据：magic、容器版本、算法标识与模式、密钥版本号、被 KEK 封装的 DEK、初始 nonce、以及策略标识。这部分开销直接导致文件长度变化，而应用层期望 GetFileSize 返回的是原始明文长度。因此在 IRP_MJ_QUERY_INFORMATION 的 FileStandardInformation 上要对 EndOfFile 与 AllocationSize 做负向补偿，目录枚举（FileDirectoryInformation 等）返回的大小同样要修正，IRP_MJ_SET_INFORMATION 的 FileEndOfFileInformation 则要反向加回。漏掉任何一条，都会表现为“文件能打开但大小不对”或“截断后内容损坏”。文件头而非文件尾的选择也是出于这个原因：尾部元数据会让追加写每次都要移动元数据。
模式的另一个决策点是随机访问能力。AES-GCM 这类 AEAD 需要从流首开始累积 GHASH，无法对文件中段做独立解密，适合整体读入内存的小文件，不适合大文件的随机读写。需要随机访问时，常见选择是 AES-XTS（无扩展、支持按扇区/按块寻址，但不提供完整性）或 CTR 模式加独立的分块 HMAC。前者牺牲完整性校验换取寻址能力，后者需要额外的认证标签存储与分块编号管理。这个选择实际上由业务负载决定——Office 文档与小源码文件和中大型二进制、数据库文件，适用的模式并不相同，把它做成容器版本字段而非写死在代码里，是后续可演进的前提。
三、密钥封装链与断电原子性
典型结构是文件级 DEK 由 KEK 封装。封装算法用 AES-KW（RFC 3394）比直接用 AES-CBC 加密 DEK 更合适，前者带完整性校验，能检测封装块被篡改。KEK 的来源有两种：用户口令经 Argon2 或 PBKDF2 派生，或由策略服务器下发并与终端身份绑定。DEK 的生成用 CSPRNG，封装后的 blob 与密钥版本号一同写入文件头。
重封装必须原子。KEK 轮换时，操作用旧 KEK 解出 DEK、新 KEK 重新封装、写回头部，正文不动。若此过程断电，写了一半的文件头会让文件永久不可解——这是这类系统最不能接受的数据损失形态。可行做法是文件头采用 A/B 双槽：两槽各带单调递增的版本号和 CRC，写入时先写非活动槽并刷盘，再翻转活动槽指针并再次刷盘。恢复时取 CRC 校验通过且版本号较大的槽。代价是每次头部更新至少两次刷盘，收益是把“断电即毁文件”降为“回退到上一版本头”。
离线授权需要把 KEK 的解封能力带到客户端，同时不把长期密钥固化在磁盘上。常见做法是服务器签发带有效期的票据，票据内以设备公钥加密或以票据密钥封装 KEK 材料，附 Ed25519 签名覆盖设备标识、用户 SID、到期时间和 KEK 版本。客户端验签后仅在有效期内持有解封材料。时钟回拨是这条路径上的现实攻击面，纯软件侧无法完全防御，需要单调计数器或 TPM 提供可信时间源；这一点决定了离线票据的有效期不能设得过长。
四、边界的技术定位
上述机制共同覆盖的范围是“文件作为字节流经文件系统 I/O 离开授权环境”。截屏、剪贴板粘贴到非受控进程、进程把解密后的内容另存为新文件，都不经过过滤驱动的判定路径，加密引擎不介入——这不是实现缺陷，而是拦截点位置决定的边界。同理，审计事件必须在驱动内部产生：一次加解密发生在哪个进程、命中哪条策略、使用哪个 DEK 版本，只有过滤回调知道，通用终端审计无法从应用层观测到。迪康文件加密系统在驱动层拦截与密钥封装之间做的取舍，基本落在上述约束的框架内：拦截点选在 Minifilter，容器带版本化头部，密钥走 DEK/KEK 两级封装并保留版本路由字段。评估这类方案时，值得追问的不是它支持哪些算法，而是它在 paging I/O、文件大小补偿和头部原子更新这三处如何处理——这三处决定了系统在真实负载和异常断电下的行为是否可预测。
