详细了解Windows Vista内核的安全性( 三 )


FVE 是过滤器驱动程序 , 因此它会自动查看 NTFS 发送到卷的所有 I/O 请求 , 在其写入时加密块 , 在其读取时(在初始配置使用 BitLocker 时 , 会使用分配到块的完整卷加密密钥 (FVEK) 读取它们)解密块 。默认情况下 , 使用 128 位 AES 密钥和 128 位扩散器密钥加密卷 。因为加密和解密发生在 I/O 系统的 NTFS 之下 , 所以卷在 NTFS 看来好象没有加密 , 并且 NTFS 甚至不需要知道已启用了 BitLocker 。不过 , 如果您尝试从 Windows 外读取卷上的数据 , 它又看来象是随机数据 。FVEK 使用卷主密钥 (VMK) 加密 , 并存储在卷的特殊元数据区域 。当您配置 BitLocker 时 , 会有许多关于如何保护 VMK 的选项 , 取决于系统的硬件功能 。如果系统有符合 TPM 规范 v1.2 的受信任的平台模块 (TPM) , 并有相关的 BIOS 支持 , 则您可以使用 TPM 加密 VMK(让系统使用存储在 TPM 中的密钥或存储在 USB 闪存设备中的密钥加密 VMK) , 或使用 TPM 存储的密钥和在系统启动时输入的 PIN 加密密钥 。对于没有 TPM 的系统 , BitLocker 提供使用存储在外部 USB 闪存设备中的密钥加密 VMK 的选项 。在任何情况下 , 您都需要一个未加密的 1.5GB NTFS 系统卷 , 在该卷中存储了启动管理器和引导配置数据库 (BCD) 。使用 TPM 的优势在于 , 如果 BIOS 或系统启动文件在启用 BitLocker 后做出更改 , BitLocker 会使用 TPM 功能确保不解密 VMK 和解除对引导卷的锁定 。当您第一次加密系统卷 , 以及每次对提及的所有组件执行更新时 , BitLocker 会借助于 TPM 设备驱动程序 (%Systemroot%System32DriversTpm.sys) 计算这些组件的 SHA-1 哈希 , 并将称为测量的每个哈希存储到不同的 TPM 平台配置注册表 (PCR) 。接下来 , 它使用 TPM 密封 VMK , 该操作使用存储在 TPM 中的私钥加密 TPM 和与 BitLocker 传递到 TPM 的其他数据一起存储在 PCR 中的值 。然后 , BitLocker 将密封的 VMK 和加密的 FVEK 存储在卷的元数据区域 。当系统启动时 , 它会测量自己的哈希和 PCR 加载代码 , 并将哈希写入 TPM 的第一个 PCR 。然后 , 它哈希 BIOS , 并将该测量存储到相应的 PCR 。接下来 , BIOS 按启动序列哈希下一个组件 , 即引导卷的主引导记录 (MBR) , 此过程会一直继续 , 直到测量操作系统加载器 。运行的每个后续代码段负责测量其加载的代码 , 并将测量结果存储到 TPM 中相应的注册表 。最后 , 当用户选择要启动哪个操作系统时 , 启动管理器 (Bootmgr) 会从卷读取加密的 VMK , 并要求 TPM 取消密封 。只有所有测量与密封 VMK 时相同时(包括可选的 PIN) , TPM 才成功解密 VMK 。您可以考虑将此方案作为验证链 , 其中启动序列中的每个组件会描述 TPM 的下一个组件 。只有所有描述与提供的原始描述相符时 , TPM 才泄露其秘密 。因此 , 即使卸下磁盘并装到其他系统、使用不同的操作系统启动系统或引导卷上未加密文件遭到破坏 , BitLocker 也会保护加密数据 。
5.代码完整性验证
作为内核模式设备驱动程序执行的恶意软件(包括 rootkit)与内核在相同的权限级别运行 , 因此最难识别和删除 。这类恶意软件可以修改内核和其他驱动程序的行为 , 以便使其变得不可见 。内核模式代码功能的 Windows Vista 代码完整性 , 也称为内核模式代码签名 (KMCS) , 仅允许加载由开发人员发布和经过数字签名的设备驱动程序 , 这些开发人员已经过为数不多的证书颁发机构 (CA) 之一的审查 。默认情况下 , KMCS 在 Windows Vista 64 位系统上强制执行 。因为证书颁发机构会对其服务收取费用并进行基本的背景检查 , 如验证业务识别 , 所以很难产生在 64 位 Windows Vista 上运行的匿名内核模式恶意软件 。此外 , 设法溜过验证进程的恶意软件可能会留下线索 , 这些线索在受到危害的系统发现恶意软件时 , 可以反击作者 。KMCS 还有一些次要的用途 , 如在怀疑驱动程序有使客户系统崩溃的错误和解除高清晰度多媒体内容锁定(我会在稍后简单介绍)时 , 会向 Windows 在线崩溃分析团队提供联系信息 。KMCS 使用 Windows 十多年来一直采用的公钥加密技术 , 并要求内核模式代码包括由受信任证书颁发机构之一生成的数字签名 。如果发布者将驱动程序提交给 Microsoft Windows 硬件质量实验室 (WHQL) , 并且驱动程序通过了可靠性测试 , 则 Microsoft 会充当签署代码的证书颁发机构 。大多数发布者将通过 WHQL 获得签名;但是如果驱动程序没有 WHQL 测试程序 , 发布者不想提交到 WHQL 测试 , 或者驱动程序是在系统启动早期加载的引导启动驱动程序 , 则发布者必须自己签署代码 。为此 , 他们必须首先从 Microsoft 确定为受信任内核模式代码签名的证书颁发机构之一获得代码签名证书 。然后 , 作者通过数字方式哈希代码 , 通过使用私钥进行加密来签署哈希 , 并将证书和加密的哈希包含在代码中 。当驱动程序尝试加载时 , Windows 会使用存储在证书中的公钥解密包含在代码中的哈希 , 然后验证哈希与代码中包含的哈希是否匹配 。证书的真实性也通过相同的方式进行检查 , 但使用 Windows 附带的证书颁发机构的公钥 。Windows 还检查相关的证书链 , 一直检查到 Windows 启动加载器和操作系统内核中嵌入的根颁发机构之一 。尝试加载未签名的 64 位驱动程序不应该发生在生产系统 , 因此不同于“即插即用”管理器(它在指向加载没有确认是否通过 WQHL 测试签名的驱动程序时显示警告对话框) , 64 位 Windows Vista 在阻止加载未签名驱动程序时 , 在无提示的情况下随时将事件写入代码完整性应用程序事件日志 , 如图 5 所示 。32 位 Windows Vista 也检查驱动程序签名 , 但允许加载未签名的驱动程序 。阻止它们将会破坏升级的 Windows XP 系统(要求在 Windows XP 上加载驱动程序 , 并且还允许支持仅存在 Windows XP 驱动程序的硬件) 。不过 , 32 位 Windows Vista 还会在加载未签名驱动程序时将事件写入代码完整性事件日志 。因为代码签名通常用来将代码标记为经过严格测试的官方发行版本 , 所以发布者通常并不想对测试代码签名 。因此 , Windows Vista 包括可以使用 Bcdedit 工具(在 TechNet 杂志 2007 年 3 月份我的文章中介绍过)启用和禁用的测试签名模式 , 它将加载使用由内部证书颁发机构生成的测试证书经过数字签名的内核模式驱动程序 。此模式设计为供程序员在开发其代码时使用 。当 Windows 处于此模式时 , 它会在桌面上显示标记 , 如图中所示 。

推荐阅读