一.  引言

近年来，可信执行的概念在物联网安全领域也逐渐流传。可信执行环境（TEE，Trusted ExecutionEnvironment）在智能手机中的应用非常广泛，如OP-TEE1、Trusty TEE等开源TEE。几乎所有新上市的安卓手机都有TEE。那问题来了， TEE解决了什么问题？集成在物联网终端中否有必要？如果有，哪些能力能帮助终端或者物联网提升安全等级？

这些都是笔者初次听说TEE这个概念的时候，脑子里出现的一些问题，本文就讲一讲笔者对TEE应用在物联网终端上的一些认识。

二.  名词

2.1  认证

一般我们说，认证通过后，才能建立可信的沟通。比如对面一个人说，他是你爸爸，但他蒙着脸，但你还是叫他爸爸，那是因为你听他的声音，看走路的动作，都能识别到他就是你爸爸，你通过他的声音和动作做判断的过程就是一个认证的过程。

OpenSSL集成了许多加密算法，依托密码学来对通信对象做认证，认证通过表示通信对象是可信的。可信任程度则依据密码安全程度、通信场景来确定。一般，我们认为在物联网应用场景中（除军工外），RSA算法的认证方式已经足够强，该算法也被集成到了SSL开源库中，开发者可以根据自身产品需求集成一个合适的SSL库，再基于SSL库编写好相应的认证程序即可。

2.2  OTP Fuse

物联网终端内集成了微控制器、微处理器、应用处理器等作为其运算、控制的核心。这些元件内部往往会有一个比较特别的存储区域。一般存储器提供给我们的基本功能就是读取和写入，但是这个区域中的存储器，可以支持一次性写入后不能第二次写入，也就是说，存储在这个区域里面的数据不会被软件更改。这就提供了一个可信任的基础。因为更改该存储区域的信息是很难的，而且一个每个终端内，该区域的信息是不同的，攻击者攻击了花费很大的时间、金钱来更改这个区域的信息也很难获得很大的利益，所以这个信息在物联网终端中是非常可信的。

OTP全称One-Time-Programmable，是由可以烧断的一个保险丝控制读写逻辑的读写控制技术。我们暂时把这个存储区域叫OTP区域。OTP区域内的数据可以被用来作为硬件唯一ID来用，在OP-TEE中对应HUK（Hardware Unique Key），基于HUK，可以衍生其他密钥，比如SSK（secure storage key）、TSK（Trusted app Storage Key）、FEK（File Encryption Key）等。

2.3  Trust Application

在一个终端上如果需要同时运行两个操作系统，需要对时间和内存分片，分别将资源划分给相应的操作系统，一般像Linux这种非安全操作系统，在OP-TEE里面被称为REE（Rich ExecutionEnvironment），与TEE对应。在REE中，如果想对比TEE中的资源，比如指纹，签名，需要通过Secure Monitor这个“独木桥”，如图1所示。有了这个独木桥，即可对操作信息、数据的合法性做校验，如果不是授权的操作，则不允许访问TEE的服务和资源。而TA则像是一个后台服务，可以与合法的操作进行交互，代替REE访问TEE内的敏感资源，比如把指纹信息接收后，通过比对存储在TEE中的指纹，验证指纹合法性。

图 1 OP-TEE设计结构

与TA交互的应用程序被称为CA（Client Application），比如支付宝，指纹登录等应用程序。CA存储在REE（如Linux）中，具体交互流程网络上已经有相关专家分析4，这里不再详述。

三.  在物联网终端内应用密钥安全存储

一般，嵌入式Linux终端组成结构如下：

图 2 嵌入式系统存储结构

Bootloader、Boot parameters、Kernel、Root filesystem这几部分都存储在终端的硬盘中，具体存储结构如图2所示。从代码角度看，TEE更像是集成内存分区、读取终端唯一ID、加解密库、校验等功能和机制于一体的代码块，把这个代码块移植到终端的哪个部分是没有定论的，只要能保证代码可信即可。一般，在系统初始化完芯片的频率、中断、总线等以后，就可以使用TEE的代码引导后续的代码了。TEE相当于给bootloader加入了安全能力。如果我们把密钥加密存储在TEE的TA中，那么密钥也就在硬盘里，防护有没有效果，是和攻击者逆向分析能力和对TEE系统的理解程度相关的。这也就决定了TEE只能在软件上做安全存储，无法实现硬件级别的安全存储。在这种认识的前提下，我们怎么基于TEE实现密钥的安全存储呢？

此处，我们假设产品的各种调试接口（JTAG、UART等）已经关闭，攻击者无法连接到芯片上进行调试，并以证书保护为例。一般，运行在REE侧的应用，在连接互联网时，如果考虑到通信安全，会使用强认证来对云端做认证，云端为了认证客户端的合法性，也要验证客户端的证书，所以证书、密钥往往需要得到保护。在使用TEE时，有一个保护的思路，下面分享出来以抛砖引玉：

使用TSK把REE中用到的密钥加密以后放到TA中，使用时，CA向TA发起请求，获取密钥，TA把密钥解密后，传给CA，CA利用密钥进行下阶段的任务。

然而，信息就在终端内，只要能获取终端，信息已经在手，只不过获取信息途径的难度不同。可以暂时分以下三类途径：

1.   把硬盘整个复制出来；

2.   得到设备运行时的root权限，获取CA运行时获取到的解密的密钥信息；

3.   直接利用精密仪器把内存数据读取出来。

对于第一种攻击，如果把设备断电后，拆开设备，取出硬盘或者读出flash芯片，密钥就已经从终端内转存到自己的电脑里面了，我们怎么找到它呢？得明确密钥的位置：密钥在TEE的TA中。

第一种攻击实施成功，需要具备的能力如下：

1.   了解TEE启动流程，知道TA中可能存在密钥。

2.   具备很强的逆向分析能力，熟悉芯片结构。

3.   识别加密代码的加密算法和加密模式，找到加密后的密钥的密文。

4.   提取出加密密钥和其他加密参数。解密密钥密文。

所以，如果攻击者没有具备齐全这四个能力，是无法获取密钥明文信息的，信息也就得到了保密。如果攻击者实力强大，这四项能力都能具备，密钥的安全也就无法保证。

第二种攻击中，获取root的形式有两种：一种是获取终端自身的root权限，另一种是通过qemu模拟启动第一种攻击中读取到的硬盘文件。我们假设终端没有在硬件上暴露调试接口，如果芯片的是BGA封装，是没办法引出UART接口到另一台PC机，进而获取root权限的。所以需要把硬盘文件中文件系统中的passwd文件和shadow文件做些调整，并开启telnet服务，这样，终端运行时候联网即可通过网络访问到telnet服务，并获取root权限。然而，在基于TEE的系统中实现这一套攻击流程有一定难度，原因在于：从TEE的第一行代码开始，已经对后续的代码签名。如果更改文件系统，需要把集成在TEE里面用来验证代码合法性的公钥更改，改完再用配套的私钥签名后，重新启动才行。

另一种是用qemu模拟整个系统。用qemu模拟系统是可行的，但是也很有难度。难度之一是TEE本身需要读取到OTP区域的ID作为根密钥。必须要编写一个可以和TEE系统交互的程序配合TEE完成OTP区域的读写过程，才能进入后续阶段2。难度之二是这个交互的过程需要逆向分析TEE的代码后才能找到。如果这两步骤完成，系统外设可以正常模拟，那么root权限的shell也就可见了。

获取到root后，启动CA，密钥会被CA读取到内存中，这时只要采集内存信息即可读取到密钥的明文信息。

第三种攻击是可行的，直接读取内存数据，可以用一个可以高速采集的逻辑分析仪读取总线上的数据。然而这种难度只会比前两个更大，一来，这种精密一起比较昂贵。二来，读取出来的数据也要变成可读的，这对攻击者的内存读写技术方面的知识积累要求很高。攻击者必须了解什么时候总线信号在传输地址信号，什么时候总线信号在传输数据，还要分离出密钥的明文。

四.  总结

由上可知，在物联网终端上应用安全存储，实际上并不能真正的实现100%的不可读，但是却能提高逆向分析终端的难度。而实际上，随着智能手机应用TEE技术，终端自身的安全问题的确少了许多，但是随着攻击者攻击手段和知识水平的提高，仅仅用TEE做安全存储并不是长久之计。还需要结合比如NXP的Kinetis Security and Flash Protection Features5，或者ST公司的RDP6的思路，把密钥写入到一个真正只有拆解芯片来拍照逆向才能读取的一块区域中，这样才能达到芯片级别的防护。而物联网环境下，达到芯片级别的防护，其破解成本已经足够强，而且能很好的应对前两种攻击手段，因为密钥并不在外部的flash中，在开启读保护的前提下，攻击者只能读内存或者拆芯片来获取密钥。而厂家只需要保证自身产品的升级流程是安全的即可，因为升级过程可以重新刷写芯片内部flash区域，如果攻击者利用了升级漏洞，会把读保护标志位置为可读。

TEE是可信执行环境，在应对敏感数据持久化存储方面尽管不是目前最好的解决办法，但是自身的安全机制已经提高了破解条件。结合其他技术，物联网终端一定可以比较完美地保护起来。

其他因为TEE机制导致的性能损失，可以经过测试后7，根据自身产品现状决定需不需要采用TEE这样一套机制，或者决定需不需要优化TEE的性能。

笔者接触TEE的时间比较短，如果文章中有些描述或者思路有些错误、不成熟、或者不合理的，希望读者能向作者提出，欢迎指正。

参考链接

1.    OP-TEE官方文档，https://buildmedia.readthedocs.org/media/pdf/optee/latest/optee.pdf

2.    Emulating Exynos 4210 BootROM in QEMU，https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html

3.   构建嵌入式Linux系统，https://goooooouwa.github.io/coding/2012/10/30/%E6%9E%84%E5%BB%BA%E5%B5%8C%E5%85%A5%E5%BC%8FLinux%E7%B3%BB%E7%BB%9F.html

4.    TEE 软件交互流程概述，http://kernel.meizu.com/tee.html

5.    Using the Kinetis Security and Flash Protection Features，https://www.nxp.com/docs/en/application-note/AN4507.pdf

6.    Proprietary Code Read Out Protection on STM32L1 microcontrollers，https://www.st.com/content/ccc/resource/technical/document/application_note/b4/14/62/81/18/57/48/05/DM00075930.pdf/files/DM00075930.pdf/jcr:content/translations/en.DM00075930.pdf

7.    Developing Secure Services for IoT with OP-TEE A First Look atPerformance and Usability，https://www.researchgate.net/publication/332726463_Developing_Secure_Services_for_IoT_with_OP-TEE_A_First_Look_at_Performance_and_Usability