2019, Vol. 40
伴随着物联网(IoT)的快速发展, 手机的应用已经发生了巨大变化, 从原来简单的通信变成包含多种应用(娱乐、购物、支付等)的综合体.同时在个人信息、支付信息等私有数据的存储和管理上也带来了新的挑战[1-3].目前有多种技术可以实现手机可信存储, 如:基于云的存储、虚拟化技术、安全单元(SE), 以及TEE(trusted execution environment)等安全存储方案.基于云的数据存储[4]需要用户将私密数据上传到第三方云存储服务中, 这就要求第三方拥有较高的信任值.手机虚拟化[5]通过隔离的方式为不同的OS或者进程提供运行资源, 将可信存储系统运行在隔离的虚拟环境中以防止外部攻击；但虚拟化技术无硬件支持, 安全性较弱, 同时Hypervisor的可信基(trusted compute base, TCB)太大, 容易出现漏洞而被攻击.SE[6]虽然提供了芯片级别防篡改能力, 可以通过SE构建TPM(trusted plateform module)[7-9], 但是, 单一芯片在计算能力上存在严重缺陷, 嵌入式的内存空间无法实现较多功能；同时, SE与其他设备的通信往往通过单一通道, 在时效上存在缺陷, 导致SE只能提供较少功能接口和有限工作能力.基于TEE[10-11]的可信存储方案能够保证敏感数据只能被授权的软件进行访问和处理.使用ARM Trusted Zone[12]技术将一个CPU分成两种执行状态——可信状态(secure world, 安全世界)和非可信状态(normal world, 非安全世界)；可信存储系统(trusted storage system, TSS)运行在可信状态下, 从而与非可信环境(例如Android)分开.与安全加密处理器不同, TEE能保证:①运行复杂的软件, 如操作系统; ②访问所有normal world中的资源, 如驱动等；③通过TEE来控制REE(rich execution environment).
1 相关工作基于TEE的可信存储系统主要集成在已有的TEE中, 目前在一些院校和企业有一些研究, 如表 1所示.密封存储能够保证私密性、完整性及数据的新鲜性, 同时保证数据的授权访问; 使用TEE的密封存储有3个特征:①安全加密密钥从来不会脱离TEE; ②标准加密机制; ③防回滚机制(如RPMB[8]).授权加密可以同时保证数据的私密性和授权访问.
|
表 1 基于不同TEE的可信存储系统特征 Table 1 Features of trusted storage system based on different TEEs |
在Open-TEE中只介绍了可信存储系统, 并没有给出具体设计方法和性能分析; 当前Linaro的OP-TEE 2.1版本[13-14]支持两种方式的可信存储:通过设置CFG_REE_FS和CFG_RPMB_FS编译选项, 使存储对象分别存储在REE的文件系统和RPMB(replay protected memory block)[8]中; 其中RPMB方案支持防回滚攻击功能, 而另外一种不支持.数据以块为单位进行读写和存储, 过多的数据块操作会增加切换次数而影响性能.由于RPMB空间有限, 将所有数据对象存储在RPMB中, 存在空间不够的问题.ANDIX OS[15]通过给TA提供SBD库来实现可信存储, 该方案使用Merkle-Tree & AE技术, 但其假设并非每个TA都需要快速随机地访问存储数据; 这种方案对开发者来说存在局限性.DroidVault[16]只提供基于AE的可信存储, 无法保证数据的新鲜性.本文TSS方案的数据结构和设计与上述方案有所不同, 具体如下:
1) 采用密封存储, 可以确保数据的保密性、完整性及授权访问, 同时确保数据的原子操作;
2) 使用RPMB机制保证数据的新鲜性, 通过保存存储对象的counter值来防止回滚攻击;
3) 每一个物理文件对应一个存储对象, 简化数据格式, 减少了两个世界中的切换次数;
4) 大数据对象存储特殊处理机制.
2 设计与实现安全环境中只提供了有限的安全存储空间, 无法完成所有私密数据的存储, 所以必须借用REE的存储空间来存储私密数据, 同时这种设计方式还可以减少TEE的TCB.根据图 1所示, 圆角方框代表了可信存储的主要功能模块, 在安全世界中, 将安全存储接口设计成为一个标准库.可信存储的所有存储特性都在可信存储API库中实现.可信存储系统(trusted storage system, TSS)提供了RPMB、密钥服务及文件访问功能.根据微内核的能力级访问机制, 在系统启动前需要配置好所有服务的访问权限.在非安全世界中, CA通过GP Client API访问TA的各项功能.Andorid系统包含三个主要设备节点(驱动程序)辅助TEE与REE之间的通信与数据访问存储, 即RPMB, Client API及虚拟文件系统的访问.在用户空间中的uTDaemon负责将通道中的数据读写到相应的存储设备中.数据通道默认容量为512KB，如果传输数据量大于该值, 则需要进行多次传输.
|
图 1 系统结构以及TSS功能模块 Fig.1 TEE architecture and modules of TSS |
TSS通过扩展Andorid的文件系统来完成可信存储的数据存取, 因此所有存储对象都是以加密方式存储在REE中.如图 2所示, 每个TA都有自己的存储空间, 即相应的存储路径.所有的存储对象, 如PO1, PO2都在指定的UUID(universally unique identifier)路径下.通过加密后的ObjectID对每个存储对象命名.为了提高更新效率, attr_data和data_info数据以块的方式存储, 大小限定为4KB, 允许存储的最大数据对象为4MB(4KB×1024).
|
图 2 存储对象、存储路径及详细结构 Fig.2 Detail structure of storage object and directory |
1) 数据私密性.设计中使用AES-CTR加密算法对数据对象进行加密.
加密密钥的使用:每个TA对应一个加密密钥, TSS需要通过密钥服务来获取本子系统可以使用的密钥, 这样就需要根据TA对当前TSS系统的密钥派生出每个TA的密钥.根据系统需求, 系统启动时通过满足RFC 2398[17]标准的PBKDF2算法将efuse在硬件芯片内的根密钥派生出8个子秘钥, 分别为不同的服务及功能扩展而保留.TSS通过KDF算法派生自己的加密密钥.
AES-CTR中Ⅳ(initialization vector)的使用:由于采用AES-CTR算法, 因此必须考虑Ⅳ的设计.为了安全考虑, 设计中将16B随机数(在本文设计中, 16B的长度已经足够)用于每个加密存储对象, 并将Ⅳ存储在明文部分.Ⅳ的格式为{xxxxxxxx0xxxxxxx}, x代表随机数, 所以如果前8个字节保持不变并采用加1的方法递增Ⅳ, 则可以生成最少231个Ⅳ.由于加密部分的数据长度被限定在4MB, 这种方式一定可以满足系统设计的需求.
2) 数据完整性.TSS通过计算存储文件Hmac的方法来确保数据完整性.为了提高性能, 在打开(Open)对象时, 保存该对象所有块的Hash值，构成Hash链表, 读取对象时, 只需要对比对象中相应块对应的Hash值是否一致即可, 简化了完整性验证流程.
3) 防回滚攻击.为了防止攻击者用以前的数据替换当前数据对TSS进行回滚攻击, TSS必须保证数据新鲜性.为了满足该系统属性, TSS采用RPMB作为辅助设备来存储对象的ObjectID和counter值, 同时counter值只能递增.如图 3所示, 由于系统需要, 供TSS使用的存储空间仅为544KB.如果为每个TA提供18KB存储空间用于满足数据新鲜性, 整个TSS系统最多可为30个TA提供存储功能.
|
图 3 RPMB空间布局 Fig.3 RPMB layout |
根据GP标准, ObjectID的最大长度为64B, 再加上counter的4B长, 一个TA最多只能存储240个objectID和counter值.为了解决存储空间受限的问题, TSS以存储objectID的Hash值的方式代替直接存储objectID本身, 这样比原来的长度减少了一半.具体结构如图 4所示, 其中metadata只有1B.
|
图 4 RPMB中objectID和counter值的布局 Fig.4 Layout of objectID and counter value in RPMB |
4) TSS中的API满足原子性.在TSS中, 原子操作是指执行一个API要么成功, 要么在失败时系统状态空间没有任何变化.整个TSS的状态空间包含物理存储, 内存信息要么变为指定的状态, 要么没有改变，这对整个TSS提出了很多挑战.根据GP specification1.1的要求, 6个GP API需要满足原子性.本文从原子执行方案和执行顺序进行分析.
为了满足API执行的原子性, 对数据对象的操作存在大量交错的读(R)、写(W)，以及在系统崩溃时的恢复操作(R), 其中读操作不会影响原子性.这些操作主要包含三个部分:对内存对象及快照的写操作; 物理文件及副本的写操作; 对RPMB的写操作.原子操作的关键是当系统处于异常或者崩溃(panic)时如何恢复到原来的状态.TSS关注物理文件和内存空间的原子性.对于物理文件, TSS采用先复制后操作的方式进行操作[18], 防止因panic而导致物理文件损坏或丢失; 对于内存空间对象, TSS采用了内存快照的方式, 将要修改的内存对象复制, 如果出现异常返回, 直接使用快照进行恢复.
执行顺序的优化:不同的执行顺序很可能对整个TSS的性能造成巨大影响, 在如上提到的三部分的操作中, 只有RPMB的操作是基于硬件的, 所以将其放到最后进行更新, 这样就能确保前两者更新成功后, RPMB的更新不会导致不可回退的情况发生.如下, 本文给出了相应的执行顺序和操作内容, 相关详细操作对应文献[18]中的相关操作.
① 执行原子操作的API, 将要修改的内存对象复制成为快照(例如:RPMB信息、ObjectID链表等), 并对内存快照进行修改, 如果失败, 返回指定的错误编码(如:TEE_PANIC等)并释放内存快照; 如果成功, 则继续执行.
② 对当前物理文件进行拷贝, 并根据预先组织的内存缓存进行更新(W1~W6), 但是与算法[18]不同的是不执行W7.如果这个过程出现panic, 则执行恢复原文件操作R1~R3, 回退到原来的物理文件.
③ 更新RPMB块信息, 如果更新成功, 删除原来复制的物理文件并释放写文件的锁(W7, W8), 根据快照更新内存对象; 如果更新失败, 则删除快照信息并将文件重新命名为原来的名字.如果删除旧文件失败, 则可以忽略, 因为并不会影响到原子操作流程.
2.2 性能优化方案如图 5所示, REE与TEE的通讯方式是通过数据通道和通讯通道协同完成的, 两个通道的实现方式为共享内存, 共享内存的大小是固定的.TSS中两个通道都为512KB.uTDaemon和uTGate分别用于解析和处理不同状态下两个通道中的数据.
|
图 5 TEE通讯通道和数据通道 Fig.5 Communication pipe and data pipe in TEE |
针对大数据对象的读写, TSS设计了另外一种方法, 即通过在REE中申请指定长度的内核空间连续内存, 通过通讯通道将地址映射到TEE中, 再由TEE完成数据的填充任务.采用这种方案可以有效减少两个世界中的切换次数以及内存的拷贝次数.
算法1：普通存储对象读算法
current_fd ← fd
current_length ← get_len(fd, len, block_size)
buffer_block ← allocate_buff(current_length)
if current_length > pipe_size then
while current_length > pipe_size do
current_length-=pipe_size
buffer_block=f_read(fd, pipe_size)
buffer_block+=pipe_size
end
else
buffer_block=f_read(fd, current_length)
end
decrypt(buffer_block)
buffer ← read_buffer(buffer_block, offset)
根据申请内存空间时机的不同, 可以使用两种策略:一种策略是在系统启动时预留一部分内存空间; 另外一种策略是根据TEE读写文件的需求, 动态地在REE中申请连续的内核内存空间.第一种策略绕过了所有的内存管理方式而不受控制; 第二种策略通过调用内核函数__get_free_page申请较大内核连续内存时可能失败, 但TSS还是选择了第二种策略, 因为在申请连续内核空间失败的情况下, 可以直接切换到原来的一般模式继续工作流程.算法2给出了具体的工作流程.
算法2：大数据对象读算法
current_fd ← fd
current_length ← get_len(fd, len, block_size)
buffer_block ← allocate_buff(current_length)
if current_length > pipe_size then
switch to REE
buffer_block_REE ← allocate_in_REE_kernel
(current_length)
if buffer_block_REE is NULL
goto Algorithm1
else
pass address of buffer_block_REE to TEE
copy buffer_block_REE to buffer_block
release buffer_block_REE
else
buffer_block=f_read(fd, current_length)
end
decrypt(buffer_block)
buffer ← read_buffer(buffer_block, offset)
3 实验分析 3.1 实验平台TSS的测试平台是MTK6797/Helio X20片上系统(Soc).它是一款包含4×4核芯, 并采用大小核设计架构的手机芯片.REE OS采用Andorid M.由于OP-TEE对硬件支持的差异性, 本文使用QEMU作为测试平台, 对比OP-TEE中的可信存储系统.TSS针对测试开发了专门的测试套件MDTester, 测试用例达5000多个.
3.2 性能分析 3.2.1 真实硬件测试第一个实验研究存储对象大小对TSS性能延迟的影响.对测试数据取平均值(分别测试5000次)以减少系统其他因素带来的误差.图 6为随机执行Open, Create, Read和Write操作的GP API性能对比, 可以看出, Create和Write操作的时间延迟几乎一样, Write操作的时间延迟比Create略有增加, 这是由于在Create操作时, 包含了Open操作.
|
图 6 一般操作的性能对比 Fig.6 Performance comparison of normal file operations |
图 7为使用大数据优化机制后的性能分析.当存储数据对象小于512KB时, 开和关BIG_MEM_CFG在读写性能上几乎一致; 然而, 当读写的数据超过512KB时, 读写的时间延迟有了明显变化.例如, 针对4096KB文件的读写, 两种状态下的性能差距为10%~15%.
|
图 7 BIG_MEM_CFG在开和关情况下的读写性能 Fig.7 Read/write performance in the case of BIG_MEM_CFG opened and closed |
当前的OP-TEE支持两种方式的文件存储：通过CFG_RPMB_FS预编译选项确定文件存储方式，这种方式将所有信息存储到RPMB中; 第二种方式通过REE的文件系统作为扩展来存储相关信息, 但这种方式没有提供数据的防回滚攻击.TSS和OP-TEE都涉及到借助REE文件系统扩展来存储相关信息, 本文以第二种存储方式进行性能对比, 结果如图 8所示.本文存储方案比OP-TEE有8%~10%的提升, 这是由于OP-TEE采用简单的块存储方案, 而TSS中针对大数据处理使用了优化策略.虽然本文也使用块存储方式, 但OP-TEE使用块为单位进行数据传输, 这样在大数据存储的操作过程中将大大增加REE与TEE之间的切换次数，从而影响了性能; 同时, OP-TEE没有对大数据进行相应的针对性操作.
|
图 8 OP-TEE与TSS的性能对比 Fig.8 Performance comparison between OP-TEE and TSS |
本文设计并实现了基于TEE的可信存储系统, 提出了相关策略来改善可信存储的读写性能.实验表明, 与当前主要以TEE为基础的可信存储系统相比, TSS的设计方案在安全性上得到了提高, 在数据读写的综合性能上提高了8%~10%.以后的工作将对REE端存储的安全性及TEE端安全存储代码本身的安全性进行分析, 采用的技术涉及快速系统访问及形式化方法的设计和验证.
| [1] |
The MITRE Corporation.CVE-2015-4421[EB/OL].[2018-05-10]. http://cve.mitre.org/cgibin/cvename.cgi?name=CVE-2015-4421.
|
| [2] |
The MITRE Corporation.CVE-2014-4322[EB/OL].[2018-05-10]. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4322.
|
| [3] |
The MITRE Corporation.CVE-2015-4422[EB/OL].[2018-05-10]. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4422.
|
| [4] |
Yang H J, Costan V, Zeldovich N, et al.Authenticated storage using small trusted hardware[C] // Proceedings of the 2013 ACM Workshop on Cloud Computing Security Workshop.New York: ACM, 2013: 35-46.
|
| [5] |
Park S W, Lim J D, Kim J N.
A secure storage system for sensitive data protection based on mobile virtualization[J]. International Journal of Distributed Sensor Networks, 2015, 11(2): 929380.
DOI:10.1155/2015/929380 |
| [6] |
GP.GlobalPlatform made simple guide: secure element[EB/OL].[2018-06-13]. http://www.global-platform.org/mediaguideSE.asp.
|
| [7] |
Zhang X, Acıiçmez O, Seifert J P.A trusted mobile phone reference architecture via secure kernel[C] // Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing.New York: ACM, 2007: 7-14.
|
| [8] |
Winter J.Trusted computing building blocks for embedded linux-based ARM trustzone platforms[C] // Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing.New York: ACM, 2008: 21-30.
|
| [9] |
Dietrich K, Winter J.Towards customizable, application specific mobile trusted modules[C]//Proceedings of the Fifth ACM Workshop on Scalable Trusted Computing.Chicago: ACM, 2008: 21-30.
|
| [10] |
Fitzek A.Development of an ARM TrustZone aware operating system ANDIX OS[EB/OL].[2018-05-09]. https://pure.tugraz.at/ws/portalfiles/portal/1937540/AndixOS_Final.pdf.
|
| [11] |
Ekberg J E, Kostiainen K, Asokan N.Trusted execution environments on mobile devices[C]//Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security.Bernlin: ACM, 2013: 1497-1498.
|
| [12] |
Santos N, Raj H, Saroiu S, et al.
Using ARM TrustZone to build a trusted language runtime for mobile applications[J]. ACM SIGARCH Computer Architecture News, 2014, 42(1): 67–80.
|
| [13] |
Linaro.LAS16-504: Secure storage updates in OP-TEE[EB/OL].[2018-05-18]. http://connect.linaro.org/resource/las16/las16-504.
|
| [14] |
Forissier J.Optee.secure storage[EB/OL].[2018-05-07]. https://www.slideshare.net/linaroorg/las16504-secure-storage-updates-in-optee.
|
| [15] |
Hein D, Winter J, Fitzek A.Secure block device: secure, flexible, and efficient data storage for ARM TrustZone Systems[C] // Trustcom/BigDataSE/ISPA.Washington DC: IEEE, 2015: 222-229.
|
| [16] |
Li X, Hu H, Bai G, et al.Droidvault: a trusted data vault for Android devices[C] // Engineering of Complex Computer Systems(ICECCS).Tianjin: Engineering of Complex Computer Systems(ICECCS), 2014: 29-38.
|
| [17] |
IETF.PKCS #5: Password-based cryptography specification: PBKDF2.[EB/OL]. Version 2.0.[2018-05-10]. https://tools.ietf.org/html/rfc2898/#section-5.
|
| [18] |
Microsoft.Atomic-writes-in-a-file[EB/OL].[2018-05-18]. https://blogs.msdn.microsoftcom/adioltean/2005/12/28/how-to-do-atomic-writes-in-a-file.
|