TEE+SE 是移动安全的终极解决方案吗？

转自：https://www.sohu.com/a/167500361_279109

  随着移动智能设备的快速普及，移动应用全方位地改变着网民的生活习惯，对人们的通信、社交、娱乐和购物等各方面产生重要影响。近年来，各类移动应用的用户规模和使用率均保持快速增长，电子商务类应用和娱乐类应用表现尤为突出，移动应用逐渐从碎片化的沟通、信息类应用向时长较长的娱乐、商务类应用发展，并通过打车、共享单车、地图和支付等应用加大对社会生活服务的渗透。

  用户在享受移动支付、移动办公、移动娱乐等带来的巨大便利的同时，也面临着信息泄露、信息破坏、非法访问、窃听假冒、木马病毒等日益严重的安全威胁。日常生活中，由于移动智能设备安全问题导致信息泄露、财产受损的事例比比皆是。

纵观这些问题的根源，是密钥运行环境和密钥的安全问题。现代密码体系是唯密钥安全的安全架构，身份认证的基础依赖于传统PKI体系的私钥安全，存储在移动终端上的密钥就成为攻击者攻击整个安全系统的最主要的手段。本文将从传统的PC环境开始，回顾总结过去、现在、未来终端密钥保护技术的趋势和方向。

一、基于安全元件(Secure Element)密钥保护技术

在传统的PC上，密钥通常都直接存储在硬盘上。随着移动支付的普及，这种密钥裸奔的方式逐渐的暴露出了各种问题，导致支付等应用屡屡出现问题，根本原因是：密钥需要存储在可信的安全的环境中。由于操作系统的复杂性，导致这杂种假设根本不成立，所以产生了第一代U盾产品，也就是国内比较早的安全元件的概念产品，既然操作系统很复杂，可以找个低复杂度的系统来完成运算，保证密钥不出U盾，从而保证了密钥的安全。但随着时间的推移，发现运行在Slave状态下的U盾非常容易受到欺骗，病毒程序可以随意欺骗U盾完成密码运算，所以，一代U盾就自然地过渡到了可显示、可确认的第二代U盾，即用户必须通过不能被操作系统软件控制的显示器和物理按键来完成密码计算，从而确保密码设备正确接受了真实的用户意愿。安全元件的安全不仅仅在于隔离，还需要考虑正确执行真实的用户意图问题。

我们需要更强的安全假设，来服务于需要更高安全级别的系统信任根。将密钥存储到简单安全元件里，解决了复杂的软件不可控，容易有漏洞从而关键信息容易被偷窃盗用的安全风险，安全元件自身还需要面对各种各样的其他攻击。因为软件系统简单，硬件元器件相对较少，故而容易建立物理防护和实施安全保障，从而提高安全元件的安全强度，从而可以服务于安全假设更强的安全系统。

随着移动互联网的发展，在移动终端上使用额外的安全元件会导致成本的提高，外置安全元件时会导致用户体验下降。我们迫切需要一种更为便捷易用和价格低廉的密钥保护技术。TEE的概念，正逐渐地重视起来。

二、基于可信执行环境(TEE)的密钥保护技术

为了解决纯硬件安全防护在移动终端上部署不便的弊端，开放移动终端组织提出了可信执行环境 (Trusted Execution Environment，简称TEE)的概念和方案，即纯软件的环境和安全元件之间的折中方案。TEE旨在构建一个资源丰富的执行环境，从设备自身来提高安全性，能够进行各种各样的应用扩展，为用户使用和服务提供商的开发提供了更大的空间与自由度。

TEE总体层次架构图如下所示：

普通执行环境(Rich Execution Environment，简称REE)包括运行在通用的嵌入式处理器上的普通操作系统(Rich Operating System，简称Rich OS)及其上的客户端应用程序。尽管在REE中采取了很多诸如设备访问控制、设备数据加密机制、应用运行时的隔离机制、基于权限的访问控制等安全措施，但仍无法保证敏感数据的安全性。TEE是运行于普通操作系统之外的独立运行环境，其向一般操作系统提供安全服务并且与Rich OS隔离。Rich OS及其上的应用程序无法直接访问TEE的硬件和软件资源。

TEE的目标是在移动设备的主芯片中建立一个可信执行环境，它是硬件可信的。TEE为可信应用(通过TEE授权的、可信的软件)提供可信赖的运行环境，再通过对机密性、完整性的保护和数据访问权限的控制，确保端到端的安全。可信执行环境与终端原有操作系统并行，通过安全的API与原有系统进行交互。

TEE提供了介于典型操作系统和安全元件(SE)之间的一种适度安全性。它提供了一个比Rich OS更高安全等级的运行环境，但无法提供硬件隔离级别的安全的密钥存储和密钥运行环境由于TEE中的密码单元仍旧通过API供REE调用，简单采用TEE编制的密码模块仍旧会工作在被动被调用的Slave模式下，在Slave模式下的SE的安全弱点它也都有。人们也正在设计更好的工作方法，确保具备更好的安全性。

三、基于TEE+SE的密钥保护技术

在认识到TEE存在的这些问题后，金融界发力、厂商配合，华为等公司推出了板载SE的手机。尤其随着生物识别技术的爆发式发展， FIDO等协议的推广，板载SE的支撑也逐步成了目前移动终端的标配。

TEE+SE的方案整体来说比较复杂，原理上也会觉得有冗余，业界一般希望通过TEE来构建可信的显示，打通领会真实用户意图的通道，SE来构建可信的安全的密钥存储和密钥运算环境，试图终结移动安全方面针对密钥安全问题的讨论。然而，用户又如何知道和区分TEE和REE呢，用户又如何有效地控制SE呢。当病毒或黑客的能力足够强大的时候，我们如何保障SE不被非法地调用，手机用户不会被病毒和黑客欺骗就成为目前的重要问题。

四、基于CloudSE的密钥保护技术

基于安全元件SE、基于可信执行环境TEE和基于TEE+SE的身份认证方案中，密钥及关键数据都是在移动终端中进行保护，不但面临着移动终端上各种恶意软件的威胁，同时也存在着丢失后难以恢复等问题。在SE为基础的系统中，SE的安全是信任的锚点，但是SE真的安全吗?SE在焊接到手机板卡后，他已经没有能力来抵御未来存在的可能的攻击。

CloudSE将密钥及关键数据在云端进行保护，不再依赖于移动终端自身的防护能力，可以提供集中式的安全防护，同时方便用户进行恢复。同时，其不再依赖于安全元件SE的安全存储和可信执行环境TEE，由云端的服务器模拟完成SE功能，从软件层面摆脱了硬件的限制，为安全支付领域的应用扩展提供了便利条件。CloudSE方案不依赖特殊的安全硬件，应用厂商可以独立完成业务流程，脱离了传统的SE芯片载体的限制，各类应用的密钥被存储在云端服务器，在云端调用相应密钥进行身份认证，大大降低了移动终端受到侵害后导致关键数据泄露的风险。

云端成为整个方案的核心部位，虽然可以对关键数据进行更高强度的保护，但是一旦被敌手攻破，就会导致大量用户的关键数据被窃取，造成巨大的经济损失。况且，作为云端，未来数据集中、计算集中后，最大的问题就是如何得到用户信任的问题。

五、基于移动KEY的密钥保护技术

上述四种身份认证方案将密钥等关键信息存储在单一节点(移动终端或者云端)，这使得该存储节点成为整个系统的瓶颈：一旦该节点被攻破，移动智能终端将会面临严重的安全威胁。为了解决密钥在单一节点存储带来的安全隐患，中国科学院数据与通信保护研究教育中心(DCS中心)提出了基于密钥拆分技术的移动KEY密钥保护方案：将密钥将拆分成两个部分，分别存储在服务端和移动终端，使用时进行协作计算，密钥不会在任何一方完整出现，即参与运算的任何一方都不会拿到完整的密钥。同时，存储在移动终端的部分密钥也采用白盒密码的相关技术分散在终端内，并于设备绑定，永远不合成出现。DCS中心移动KEY的密钥保护方案通过了国家密码管理局的安全性审查，并取得了商用密码产品型号证书，命名为SHM1703智能移动终端安全密码模块。

移动KEY可为电子政务、移动办公、智慧城市、银行、互联网金融、电子商务等移动互联网应用提供了密码运算支撑能力，可用于身份认证、电子签名、数据保护等。

此种方案的核心思想是对密钥进行了拆分和分别的存储，云端和终端有了一定的安全制衡关系，只有双方协作才能完成密码运算功能，参与运算的任何一方不能完整掌握密钥。在不需要可信显示的应用场景，这个方案的安全级别可以归约到安全元件的安全级别。在最坏的攻击场景下，攻击者可以有条件地使用密钥，但不能完全掌握密钥。

移动KEY的安全特点主要有：

1. 是国内首款达到GM/T 0028-2014 《密码模块安全技术要求》安全等级第二级的软件密码模块，可以支持一般的金融交易和网上政务商务应用。

2. 利用移动终端中的硬件信息构造本地部分密钥的部分密钥，从而实现密钥与设备的绑定。通过硬件信息绑定确保即使全部内存和软件全部拷贝到其他设备也无法重现该设备中的部分密钥。

3. 在部分密钥中除硬件信息外，剩下的部分密钥继续采用拆分算法和白盒密码的手段，同时确保部分密钥在计算过程中永远不合成，来提高包括侧信道攻击在内的各种攻击手段的门槛。直接在拆分状态下进行计算确保了一般的黑客无法直接发现设备中部分密钥。

4. 由于移动KEY采用软件实现，其集成的监控功能只有用户许可的APP才能使用密码计算，从而确保病毒和其他非法软件无法调用移动KEY的密码功能。

5. 移动KEY的关键部分采用汇编和C编码，整体还采用了常规的代码混淆技术，确保一般软件分析难以奏效。

6. 通过预设的安全图片和安全提示，确保用户只在移动KEY正确运行时用户输入PIN码、验证指纹和查看签名信息，确保移动 KEY仅执行用户授意的数字签名和密码计算。

结束语尽管移动KEY具备很多安全优势和应用便利，但仍旧有许多可以改进的空间，绝对安全的设备是不存在的。比如，将白盒密码运算部分移植到TEE就可以更加增强移动KEY的安全性。我们热切期盼新一代移动KEY尽快诞生，为进一步推进自主可控密码在金融等重要领域的深入广泛应用做出更大的贡献。

(本文刊登于《中国信息安全》杂志2017年第7期)