【分享】由Windows 的安全实践看可信计算的价值和局限
图片来自网络，点击上方【中关村可信计算产业联盟】可订阅
会员单位投稿：tcpu_sec@163.com
背景介绍
美国人詹姆斯·安德森(James P.Anderson)在他1972年10月发表的论文《计算机安全技术规划研究》(Computer Security Technology Planning Study)中，最早提出了面向系统安全事务处理的可信(Trustworthy)概念。1983年，美国国防部公布了《可信计算机系统评价准则》(TCSEC，Trusted Computer System Evaluation Criteria)，并在其中使用了可信计算基(TCB，Trusted Computing System)概念。1984年，《可信数据库解释》(Trusted Dadabase Interpretation，TDI)和《可信网络解释》(Trusted Network Interpretation，TNI)分别制定。由此，在信息系统安全领域的“彩虹系列”丛书陆续发行，提出了许多系统基本概念、原则和方法。2002年初，比尔·盖茨向微软全体员工发出公开信，表明微软公司未来的工作重点将由产品功能和特性向产品安全性转移，并提出了微软的“可信计算”(Trustworthy Computing)战略，并同芯片制造商Intel、AMD 一道，在产品中逐步引入可信计算技术，WinVista和Win7就是具有代表性的产品。本文将Windows安全演进中与可信计算相关的几个关键点进行分析，以讨论可信计算的安全价值和局限性。
Windows安全保护机制
微软公司从DOS 时代因恶意代码等问题就遭到一定的压力和诟病，因此也进行了一些改善产品的安全的尝试，包括内置基于TSR机制的监控程序VSafe、OEM自CPAV的杀毒工具MSAV等。在Win95遭遇OOB Nuke攻击后，微软也开始初步建立的补丁升级机制，但是直到WinXP SP2开始，才逐渐坚定了基本安全架构的基础，并在此基础上不断加入新的安全特性。如图1所示，这些安全特性涵盖了数据加密、应用控制、内存保护、安全策略和响应防护等各个方面，全方位地提供了由硬件支持、系统支持、软件支持和外围安全机制的支持。
图1 Windows安全保护机制
如果将这些安全保护机制重新划分，梳理各项安全特性之间的关系，就可以得到图2所展示的安全特性分类图。在中心圆里面列出的安全特性，都是与可信计算密切相关的，包括：访问控制、驱动签名、AppLocker、UEFI BIOS、证书体系、BitLocker，以及对可信平台模块(TrustedPlatform Module，TPM)的支持。
图2 Windows保护机制分类
限于篇幅，本文仅讨论基于可信计算模型的BitLocker、证书体系和驱动签名这几个方面的安全特性。
BitLocker
BitLocker是微软从WinVista开始加入的安全特性。使用BitLocker加密硬盘数据，可防止因计算机丢失而导致硬盘数据泄露。在计算机具有TPM的情况下，BitLocker可以将用户密钥等信息存储于TPM中；否则，需要用户修改组策略实现开启BitLocker功能，并提供U盘等外部存储介质保存密钥。相对U盘而言，TPM具有更为安全的密钥保障机制。BitLocker在TPM的配合下可以实现系统卷的加密，这是此前版本Windows所使用的EFS加密机制无法完成的。图3展示了启用BitLocker前后同一个扇区的数据变化情况。
图3 BitLocker加密前后扇区比较
在讨论TPM对BitLocker的影响之前，先看一下图4所展示的Win7完整启动过程：计算机在接通电源后将执行自检例程，然后读取MBR(Master Boot Record，主引导记录)，将控制权交给MBR上存储的导引程序，导引程序先后访问DPT(Disk Partition Table，磁盘分区表)和PBR(Partition Boot Record，分区引导记录)，最后将控制权交给Windows启动管理器(BootMgr)。此时，Windows 启动管理器负责加载启动配置数据，执行Windows系统的引导代码。引导代码找到系统所在盘符，并执行%system32%\winload.exe。其后由Ntoskrnl.exe加载硬件抽象层(HAL)模块，根据注册表配置加载各驱动程序。加载完毕后，启动会话管理器(smss.exe)，初始化系统(Wininit.exe)，执行本地安全验证(Lsass.exe)，再由services.exe启动各个服务进程，显示登录界面。用户登录成功后，会加载当前用户的专有配置，执行启动项各应用程序，将桌面环境呈现给用户。
图4 Win7完整启动过程
如果用户的计算机具有TPM并且启用了BitLocker，Win7操作系统启动过程就会发生变化：计算机在接通电源后，在执行自检例程之前首先检测可信度量根(CRTM，Core Root of Trust for Measurement)，在最初的可信度量执行后，依次检测TPM的PCR寄存器中保存的BIOS、MBR、PBR、BootMgr启动模块的各个度量值。各项检测通过后，BootMgr申请TPM使用PCR 寄存器中的值对VMK(Volume Master Key，密钥卷主密钥)解密，度量值和VMK封装时的度量结果一致时，VMK成功解密，并取得FVEK(Full Volume Encrypt Key，全卷加密密钥)，供BitLocker解密加密卷。这个过程完成后，控制权交给BootMgr并由它完成后续引导工作，如图5所示。
图5 启用BitLocker后的系统启动过程
在借助TPM妥善保管VMK及FVEK的情况下，BitLocker可以有效地保护磁盘静态数据的安全。综合来看Bitlocker是一个基于信任引导链的一套静态验证的安全机制，其可以较好的应对下列问题：
1)设备丢失，或者存储介质被窃取；
2)使用其他引导介质启动后窃取硬盘数据或者进行写入木马、破坏安全策略等操作。
但是，在操作系统完成引导过程后，其对内存获取、硬盘文件获取等是无效的。
应用验证、证书体系和第三方信任链
操作系统的安全问题并不是操作系统厂商单方面能够解决的。操作系统如果想与硬件厂商发布的驱动程序、软件开发者发布的应用程序之间建立信任关系，就必须引入一套基于PKI体系的可执行程序和模块的证书签名机制。
数字证书由CA(Certificate Authority，证书认证机构)颁发，包含公开密钥所有者、公开密钥、签发者信息、有效期等信息，可供通过互联网验证身份，具有权威、唯一、真实和可靠等特点。数字证书签名申请、颁发及使用流程如图6所示。
1)软件开发者产生密钥对；
2)软件开发者与证书认证机构签订合同；
3)软件开发者向证书认证机构提供自身信息、公钥并支付费用；
4)证书认证机构核实软件开发者身份；
5)证书认证机构向软件开发者颁发证书并提供必要工具；
6)软件开发者使用签名证书为其软件产品签名；
7)软件开发者发布具有签名证书的软件产品；
8)普通用户获取并运行签名后软件产品；
9)操作系统准备运行带有签名的软件产品；
10)操作系统由可信根证书库验证签名有效性；
11)操作系统运行通过签名验证的软件产品。
图6 数字证书签名相关流程
为程序(尤其是驱动程序)加入数字签名证书可以极大改善系统的安全状况，对于厂商、软件产品、用户、操作系统以及证书颁发机构都会带来益处。比如，对于厂商而言，数字签名证书可以为厂商程序提供抗伪造能力，有助于建立厂商信誉和保护厂商的知识产权；对于软件产品而言，数字签名证书保护其不被篡改，表明其出品厂商身份，避免其被反病毒软件误判为恶意程序；对于用户而言，数字签名证书提供了简便的判别未知应用程序可信性、完整性的方法；对于操作系统而言，使用数字签名证书的程序可以获得TPM的支持，可以通过检查驱动程序的数字签名完整性识别其是否被恶意代码感染，是保证系统安全稳定的基础；对于证书颁发者CA而言，这会规范厂商程序的发布流程，推动产业的良性发展，以及获取必要的收益。
数字证书的申请、管理与废止有着严格的规范(如图7所示)，而且获得有效数字证书必然涉及到真实的支付过程，如果带有数字证书的程序产生恶意行为，很容易追溯到具体厂商或软件开发者。
图7 数字证书的申请、管理和废止
与传统反病毒采用的“通缉令”工作模式不同，可执行程序证书是一种类似“良民卡”的机制。这就使得CA自身的证书制作环境、软件开发者的开发环境和软件开发者的证书签发环境的安全性保障显得十分关键。令人遗憾的是，这三方面都是问题频现：
1)在CA自身的安全性方面，荷兰CA因被入侵倒闭，印度国家信息安全中心NIC被发现使用Indian CCA的次级CA证书发行了多个假的Google和雅虎SSL证书，甚至，软件证书签发机构VeriSign也曾在2010年遭到黑客入侵。
2)在开发环境方面，2014年3月曾有国内某银行网银密码输入控件的开发环境被病毒感染，导致安装该控件的用户主机均受到感染。
3)在证书签发环境方面，最令人震惊的教训莫过于2010年“震网”蠕虫盗用RealTek与JMicron两公司的数字签名，绕过多数反病毒产品的恶意代码检测机制，这使得当时的反病毒工程师惊醒：数字签名并不是表明程序安全无害的标签。其后被曝光的Winnti蠕虫，甚至专门有一个功能就是用于窃取软件的签名证书并回传给攻击者。
不过，上述问题还不是最普遍的，当前最大问题在于：面对海量的软件开发者的申请，证书管理机构几乎不可能建立起一套严格的审核机制，也无法形成面向软件开发者签发文件的快速采集和问题证书废止机制，证书滥用的情况已经非常严重。2014年07月12日，我们就当日某样本来源的全部73,111个不重复样本进行统计，发现该来源提供的全部PE格式恶意代码样本中，接近半数都带有数字签名，而数字签名过期或被吊销的情况尚不足1%，如图8所示。这些带有数字签名的恶意代码样本，主要集中在威胁用户隐私的广告件和窃取用户银行账号的木马两大类。如果没有一个强审计的应用商店机制来配合，数字签名的信任机制的安全性已经形同虚设，对攻击者的攻击成本的提升也极为有限。
图8 某第三方恶意代码样本来源中具有数字签名的样本统计
另外，我们也听到“可信计算能够消灭病毒”这类的说法，显然这里的“病毒”是指狭义的感染式病毒，而非已经概念泛化等同与所有恶意代码的“病毒”。站在可信计算研究者的角度，病毒感染宿主程序后，会导致原有证书签名失效，进而系统拒绝被感染的程序运行，这是没有问题的。不过，当前绝大多数恶意代码都不是感染式，而是独立的可执行程序，这些恶意程序与正常应用程序同样可以被签名。同时，理论上也不能排除这样的极端情况：感染式病毒携带私钥证书，为被感染后的宿主程序签名加入新的数字签名。
图9 2013年安天捕获各类样本比例
从已知的APT攻击事件上看，为了提升攻击的成功率，高级攻击中不乏先攻击CA再实施后续攻击的案例，而直接窃取厂商的数字签名，二次作案的案例早已经非常常见。
当然不能因为有证书的盗用和滥用问题就完全否定这个机制的价值，通过与UAC等机制与签名验证机制相结合，增加程序运行的用户确认交互，确实也提到了一定降低恶意代码运行的作用。
驱动强制签名
Windows作为一个长期存在、广泛应用的桌面操作系统，要求所有程序带有数字签名才能被执行是不现实的，因为这样会导致大量既有应用无法运行，对很多中小开发者来说，也带来了一定的成本代价。作为一个折中的策略，微软尝试在Win7中引入了驱动程序强制签名的机制，以保证引导链的安全。不过对于Win7，仅在64位系统中才默认启用驱动模块强制检测数字签名的安全机制。而Win8中引入了统一可扩展固件接口(UEFI，Unified Extensible Firmware Interface)标准，并在UEFI BIOS中内置了Secure Boot功能，用于对抗感染MBR、BIOS的恶意代码。Win8缺省启用Secure Boot功能，即在启动过程中由UEFI固件验证模块的数字签名，仅会加载具有签名的模块。Win8与Win7的启动过程区别如图10所示。
图10 Win7与Win8的启动过程比较
在Win8的启动过程中，UEFI BIOS首先会校验OEM厂商预置于主机固件的签名库，如校验失败，说明固件不可信，需使用OEM厂商指定恢复程序修复固件。如果问题出现在Windows启动管理器(BootMgr)中，固件则尝试通过Windows启动管理器的复本完成启动过程。如果无法使用其复本，固件则使用OEM厂商指定恢复程序进行修复。Windows启动管理器运行时，若发现驱动或NTOS内核存在问题，则加载Windows恢复环境(Windows Recovery Environment，简称WinRE)，由驱动或内核镜像进行修复。如果一切顺利，Windows会加载反病毒软件及其它驱动程序，然后初始化用户态进程，见图11。需要注意的是，Win8所提供的SecureBoot功能给第三方反病毒厂商程序预留了驱动接口ELAM(Early Launch Anti-Malware)。ELAM驱动经微软签名受信验证后，先于其它驱动程序加载执行。
图11 Win8提供的安全启动
操作系统严格检查启动链驱动程序的数字签名有助于保障系统的稳定性，也在一定程度上提升了系统的安全性。而也解决了原有Windows安全中心与安全厂商的对接仅仅靠注册接口保护所带来的问题。
当然对于目前Windows系统的强制驱动签名也存在一些绕过手段，这基本为安全工作者所熟知，一些工具很容易被找到。可以借助带有数字签名证书的驱动程序的漏洞加载不具有数字签名证书的驱动程序，进入内核执行恶意行为，就是一个可能的攻击路径。如图12所示。
图12 Win7利用工具Win64UDL加载无签名驱动
结 语
可信计算技术为Windows操作系统带来了新的安全特性，如更加强壮的引导链、如Bit Locker与TPM结合提升的防盗和数据安全能力、通过证书验证与UAC 的结合增强了对应用的交互确认等等，可信计算已经显露出其独特的安全价值。但从一个安全工作者的长期研究实践来看，不可能有任何一种安全技术可以包打天下，可信计算技术也是如此。如果没有DEP、ASLR、UAC等安全机制的引入，可信计算所带来的安全价值必然大打折扣；而EMET、Windows Defender等安全工具的存在，也显然可以为微软系统提供了可靠的实时防护能力与响应统计手段。特别值得关注的是，微软在新一代操作系统产品的Secure Boot功能中专门为反病毒产品保留了关键位置，将传统反病毒置于可信链的验证之下，也从一个侧面证明可信计算技术与反病毒技术，不仅并不冲突矛盾，而且完全可以更深度的耦合。可信计算需要将反病毒纳入到自身开放框架的一个能力点，同时，反病毒也需要针对可信计算需求做出适应性改进。唯有可信架构、主动防御、反病毒能力、软件生态体系等因素都得到充分强化，才能够带给我们一个相对安全的系统环境。
参考文献
[1]《可信计算》(A PracticalGuide toTrusted Computing)，(美)David Challener 等著，赵波等译.
[2]《XP停服后对安全威胁版图的影响》，肖新光，YOCSEF 报告.
[3]《2013年互联网信息安全威胁综合报告》，安天实验室.
[4] TrustedBoot: Secure Boot – MeasuredBoot，http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx，2013.1.9.
[5] Secure BootOverview，http://technet.microsoft.com/en-us/library/hh824987.aspx，2014.5.5.
（文章发表于《信息安全与通信保密》2014年9期）
中关村可信计算产业联盟（订阅号：z-TCIA）
电话：010-62961219 ·邮箱：tcpu_sec@163.com