概述

今天分享的论文是UCB团队在2019年发表的Keystone Enclave，它的卖点在于可以定制化，Keystone设计了一套流程，让硬件制造商，平台提供者，开发人员可以进行协作开发可信执行程序。只要硬件提供了最基础的隔离原语，就可以通过Keystone定义一套软件自定义的可信执行环境。它在论文中提出自己有这几点贡献，可定制、模块化、开源、低开销。

威胁模型

​ 这里假设攻击者分为几种类型：基于硬件的攻击者，他可以修改、重发、拦截离开SoC的信号；基于软件方法的攻击者，它可以控制Host端的User Mode程序，不可信的操作系统，网络通信，不受TEE保护的内存和发送给Enclave的消息；使用侧信道漏洞的攻击者可以观测到可信组件和不可信组件通信过程中泄露的信息。但是不考虑拒绝服务攻击。

​ 这里再一次提出，Keystone是一个可以定制的TEE框架，它可以基于平台的特性和应用的场景开启或者关闭一些特性，来达到想要的安全性和性能。

设计

接口


​ 在可信组件中，Keystone介绍了Security Monitor和Runtime。Security Monitor负责将不可信的组件和我们所执行的tee环境隔开，而runtime负责代表我们开发的可信App和Security Monitor通信。如上是我们的security monitor接口，下面三个由于我们Runtime分则发起，而上面三个有我们的Linux内核发起用于撤销Enclave在内核中申请的资源。

隔离

​ 尽管keystone不限于RISC-V平台，但是这里实现在RISC-V平台之上，所以使用的是PMP进行隔离。

​ 如上就是论文中的配图，最左边是PMP配置寄存器和PMP寄存器用于可信区域的隔离，Keystone将Security Monitor、Enclave和不可信的OS通过PMP隔离开。而执行时又将PMP进行翻转，那么就可执行User Mode中的Enclave程序，Security Monitor连接起了可信区和不可信的区域。

​ 同时Keystone在进行隔离域的建立和释放时还进行了核间同步，和之前的工作一样，Keystone也支持Secure Boot、安全随机源（目前没有）、可信时钟、远程验证、异常委托。

组件


​ 如上图所示，这里构想了一种工作模式就是一旦硬件制造好了，平台的提供者可以根据已有的硬件对于Security Monitor继续配置，然后软件开发者可以根据SDK跟腱自己的程序。

​ 而组件就是平台提供者可以自定的东西，但是虽然是组件，其实很多的组件基本是必须有的。

  • Free Memory，可以申请一段空间空间，供之后动态申请。

  • Dynamic Resizing，可能地的话，扩大region的大小。

  • Edge Call，由于可信App和Host之间无法之间访问，Keystone中构建了一个缓冲区，通过偏移信息。

  • Syscall，和Edge Call相似可以向Linux内核发送一些IO请求。

  • 多线程，在一个核上一个Enclave内跑多核线程。

  • Cache分区，和以前的TEE论文中采用相同方法，可以根据平台而定。

实现和测试

​ SM的TCB自己写的部分只有不到2000行，Runtime最小只用3000行，加上一些Security Monitor的库大概10000行代码。

​ 测了RV8、Beebs、CoreMark、IOZone。

​ 上图是IOZone的结果，并不是很好。但是在其他计算密集型任务中效果不错, 论文中说明只有10%的开销，毕竟Keystone并不用修改App原本的代码。

总结

​ 论文中提到卖点，在今天看来可能不是Keystone受到重视的原因。模块化还是可定制，从设计层面Keystone并没有走的很远，但它是MIT的Sanctum的续作，第一个开源RISC-V TEE，它可以真正的运行，文档也较为详实。