【论文阅读】——BASTION-SGX: Bluetooth and Architectural Support for Trusted I/O on SGX

BASTION-SGX: Bluetooth and Architectural Support for Trusted I/O on SGX

作者：Travis Peters、Reshma Lal、Srikanth Varadarajan、Pradeep Pappachan、David Kotz
来源：ISAP@HASP

算是正式读的第一篇可信计算？的论文

感觉本文在SGX中的应用并没有很多，更多的是在APP与Controller之间信息传输的保护工作更多，引入可信硬件（蓝牙）和固件（HCI）来实现可信路径，本质是需要一个特定协议的硬件，而非一个针对任意外设的框架
SGX不仅用于云端，也适用于IoT？

感觉这篇的行文逻辑好乱啊，不知道为啥

Abstract

本文所做的工作是在SGX支持的平台上实现的蓝牙可信I/O体系结构，目标是提供不依赖系统安全软件的IO数据保护，实际上，我们主要关心的是保护IO免受软件攻击(包括特权软件)。本文，我们描述了在蓝牙体系结构上设计和实现可信IO可能会遇到的挑战，并针对这些挑战提出解决方案。此外我们描述了我们的Proof-of-concept工作，通过在蓝牙Controller和SGX enclave之间保护用户数据将现有的over-the-air(OTA encryption)蓝牙拓展到SGX enclave中

1 Introduction

对于一些APP来说，其中的IO数据与用TEE保护的数据(PII、passwd、health data)有这相同的安全敏感级别。因此有很多需要使用TEE的APP依旧需要使用一个机制来保护用户的IO数据。

以前的工作是构建Trusted path——APP和IO数据的可信通道，这个方法主要是使用可信驱动、中间件、操作系统、虚拟机、hypervisors的组合来实现，这种方法对于SGX的应用并不是很有效，因为在SGX软件之外的构件并没有方法向enclave做attest。因此，使用这种方法的话，APP的安全骤减为驱动、中间件、系统、VM、hypervisor的安全性（见fig1(b)）。

本文提出的架构（见fig1©）
本文假定，CPU等硬件都是可信的。

本文主要关注蓝牙和SGX，关注在有SGX的平台上蓝牙发出或者接收的敏感数据针对蓝牙设备和SGX程序建立可信路径，并假设同样的技术也适用WiFI和NFC等短距离通信。

现有的五险除数技术，定义了硬件方面的保护，但是对于client端的安全交给了OS。在蓝牙中，Controller和蓝牙设备的安全由现有的OTA进行保护，但是APP与Controller的传输是明文传输，本文主要是解决这方面的问题，本文的工作没有对蓝牙协议、硬件做任何修改

针对目前的可信IO方便的问题，我们需要一个可信IO机制来选择性的只对指明的可信APP和设备传输的用户数据进行保护，其他的数据按照往常一样传输。

本文的主要贡献：
1、指出并解决了实现蓝牙设备可信IO的一些挑战，我们描述了一个可以在客户端的蓝牙Controller中应用的链接监控方法，允许它不受干扰的收集蓝牙设备和信道的Metadata
2、提出了Bastion-SGX，一种在SGX支持的平台上实现蓝牙可信IO的体系结构，该架构提出了对现有IO框架的轻量化拓展，来达到蓝牙可信IO的功能
3、在一个案例研究（在键盘和鼠标和一个可信APP之间实现安全敏感的蓝牙IO）中证明了我们的Proof-of-concept(POF)工作。具体来说，我们的工作展示了如何将现有的OTA蓝牙安全扩展到一个具有我们提出的新的安全特性的可信app，即蓝牙Controller和可信APP之间的蓝牙IO安全

再次强调，该项工作只对client的蓝牙Controller和APP的固件做修改，其他地方不做任何改动

2 Background

2.1 Bluetooth

详细的蓝牙架构及其协议的描述超出了本文的范围，对于蓝牙基础的了解还是需要的

客户端内部的蓝牙典型部署由HOST和一个或多个Controller组成，HCI是HOST和Controllers的命令接口，HOST是蓝牙核心文件之间所有层组成的逻辑实体？？。Controller是HCI之下所有层的逻辑实体，使得client能与其他蓝牙设备通信。很多设备中，HOST由软件构成，Controllers由固件和硬件构成(fig2)

一个物理信道可能被两个或者多个设备共享，所以有着很复杂的连接，控制协议使得属于的传输能正常运行。
Logical Link Control and Adaptation Protocol(L2CAP)对APP和服务提供信道抽象，L2CAP层提供很多功能：应用数据的分割和重组，以及在共享逻辑链路上复用和解复用多个通道。交付给L2CAP协议的应用程序数据可以在支持L2CAP协议的任何逻辑链路上运输。

本文工作主要关注两个协议：HCI、L2CAP.

2.2 Intel SGX

SGX这块很常见，不翻译了。
总之就是SGX可以保护用户的data、code，但是没法进行IO保护

3 Security Model & Challenges

本文的工作主要关注Controller与APP的交互路径和trusted软件和trusted Controller在不安全的HOST 上怎么保证安全IO

3.1 Security Model

Threats & Adversaries
只关注软件攻击(包含特权软件)：非法数据访问，数据注入和重放攻击

攻击者可以读系统软件和untrusted app的data、code，可以创造他们自己的trusted app，还可以介入通信(即截获、插入、更改、拒绝消息)，不管是在客户端内的trusted app和trusted IO硬件之间，还是在客户端和设备之间。

但是攻击者不能物理访问client、device，不能读写由TEE保护的trusted app或者trusted hardware中的data、code，攻击者也不能突破现今已知安全的加密协议

DDoS和side-channel攻击不在本文工作范围内
Assumption&Trust Model
假设用户不是攻击者，假设蓝牙设备部署正确，假设客户端支持SGX，假设系统软件和其他App不可信，假设所有trusted 软硬件部署启动正确，假设Trusted app相信controller会遵守协议，并在client与device之间实施OTA保护，假设OTA可以保护物理信道的安全
Goals
鉴于上述，力求达到四个目标：
G1：设计与之前可信路径(依赖可信hypervisor、可信OS、可信驱动)不同的一个客户端架构
G2：为可信软件和硬件之间选中的用户私密数据提供私密，完整，重发保护
G3：防止假冒软件或硬件冒充
G4：在不干扰现在的蓝牙IO协议和回路机制情况下实现上述目标

3.2 Bluetooth Trusted IO Security Policies

本文应用L2CAP来传输用户数据

Bluetooth Trusted IO Security Policies指定可信APP和蓝牙Controller之间需要保护哪些蓝牙IO数据，以及用于保护数据安全的信息？
具体来说，Policies主要有两个要素组成：
1、用于识别secure channel的信息
2、对称密钥：用于对指定channel数据进行加密保护
这里所指的secure channel主要包含G2和G3两个目标的属性

在3.3讨论识别携带用户IO数据的secure channel所需信息，在4.1.2中讨论如何将安全策略编程到controller中

因为我们的架构旨在为用户IO数据提供机密，一个编有安全策略的trusted app对策略中定义的channel有着独占访问权限。确保没有其他软件可以访问trusted app想要保护的蓝牙I/O数据。OS一定程度上可以实现上述的安全，但是OS或者其他系统软件不在我们架构的TCB范围中，我们要在不依赖这些untrusted software的情况下实现相同的保护

3.3 Challenges

我们需要在工作中实现G4，因此，我们Trusted IO策略旨在选择性的保护trusted app和指定的设备中用户数据，这方面有三个主要问题：
1、将多路复用和交替的数据包关联到各自的设备和通道；
2、仅隔离和保护用户数据；
3、克服只有低级别环境中实施高级安全策略之间的紧张关系

3.3.1 Packet Multiplexing & Interleaving

Controller维护了一个HCI连接句柄和其相关的蓝牙设备地址的mapping，是的Controller知道packet属于哪个设备，然而这对于保护用户数据来说不够

L2CAP中的channel identifier(CID)只是指定同一个设备的不同channel对应不同CID，不同设备可能会有相同CID，就会有歧义，在这种情况下，消除歧义的属性是物理链路的标识符(例如HCI链接句柄，蓝牙设备地址)

所以，HCI 链接句柄和L2CAP CID可以指示特定的channel

3.3.2 Isolating & Securing User Data Only

L2CAP packets有两种，一个是携带控制信息，一个是携带数据。如果我们把所有的packet都进行保护，不论什么类型，可能会对蓝牙的功能有影响。
为了实现G4，我们不能对携带控制信息的packet防护，携带数据的packet也只有在需要的时候才防护。

L2CAP packet中没有用于消除控制分组与数据分组的歧义的类型描述符。然而有这样的描述符，在创建L2CAP channel时，将交换PSM值，PSM值对于保护channel很有用，因为通过PSM值可以洞察到通道目的和通道交换的数据类型，此外，在规范中定义了一些数据和控制信道，并为其分配了指示其用途(数据与控制)的保留信道标识符。因此，虽然信道类型信息并不包含在所有分组中，但是这种信息要么标准化(因此不需要直接观察)，要么在创建信道期间可用(因此在Controller内是可观察的)

3.3.3 Understanding Device Types

蓝牙定义了Class of Device(COD)的观念，指定了设备的目的和功能，每个蓝牙设备属于一个class，使用蓝牙CID信息在安全策略中表示设备可能很好地映射到人类和应用程序对设备的高级理解

4 ProposedArchitecture：Bastion-SGX

the client trusted software
the client`s Trusted IO hardware
some number of wirelessly connected devices

4.1 Bluetooth Trusted IO Controller

实现了以下功能：
1、监视连接事件，维护一个Metadata Table来存储蓝牙设备和相关的channel信息
2、提供API以支持与主机软件的可信I/O交互
3、使用Metadata Table来过滤packet
4、应用加密技术以在channel上提供所需的安全属性

4.1.1 Connection Event Monitoring & the Bluetooth Trusted IO Metadata Table

对于3.3节中描述的各种挑战，我们设想的解决方案在于我们能够获取有关设备及其各自的HCI和L2CAP通道的元数据

我们断言，只需要扩展蓝牙Controller固件就可以获得所有必要的信息，具体来说，Bastion-SGX提出了新的功能来监控HCI和L2CAP的连接断开事件，并维护了一个包含3.3节中提到的信息的Metadata Table

图5总结了相关的HCI和L2CAP事件，以及控制器捕获的元数据

当蓝牙设备连接到client时候，Controller会创建一个用于HOST Software和设备进行通信的HCI Connection Handle(CONN_HDL)，设备使用Bluetooth Device Address(BD_ADDR)和COD来描述，完成连接之后，HOST Software使用CONN_HDL来进行通信。
之后这些实体会交换L2CAP连接请求来创建一个逻辑连接用于control、data packet的传输：HOST Software发送REMOTE_CID和PSM（指明channel用途）,channel 有两个端点，一个是LOCAL_CID，另一个是device端的REMOTE_CID.

通过监视HCI和L2CAP的时间，Controller能够用来创建和维护非常细粒度的信息：device(CONN_HDL,BD_ADDR)，device type(COD)，逻辑channel(LOCAL_CID,REMOTE_CID)，服务类型(PSM)

4.1.2 Bluetooth Trusted IO API

Trusted IO的功能用来给予可信APP创建可信信道来保护用户数据的能力，这方面有两个问题：可信软件怎么把可信策略编程到Controller中、可信软件如何根据Controller独立维护的Metadata来描述安全策略

HCI可以用来解决上面的第一个问题，HCI用来HOST和Controller的通信，HCI协议提供了可扩展接口——VSDC接口，VSDC使得用户可以添加非标准的功能，该功能也能让APP去使用，我们可以使用此接口在支持可信I/O的蓝牙Controller中支持新的Bluetooth Trusted IO API，例如用于添加和删除安全策略的规范API

指定安全策略的一种方法是确定一类应与密钥一起保护的设备(COD，key)，并依靠控制器来确定哪些通道传输敏感数据，哪些通道不传输。
通过COD和PSM我们可以识别(并随后保护)携带用户数据的通道(使用策略的KEY)。这种定义安全策略的方法比较保守，因为它允许受信任的软件保护它与任何与其策略中的COD匹配的设备之间的I/O

4.1.3 Bluetooth Trusted IO Filtering

该功能用于：1、基于已知的设备和安全策略来识别携带敏感用户数据的packet2、使用KEY（4.1.4）来进行保护

给出一些信息（之前描述的一些标识符），通过filter来指明哪个packet需要进行防护策略

4.1.4 Bluetooth Trusted IO Security

4.2 Trusted IO Host Software

trusted app需要使用Bluetooth Trusted IO API把安全策略编写到controller中，对于每个可信channel，app需要使用一个新的对称密钥，然后把密钥发送给controller。可信的app还需要对传入/传出数据执行加密操作

具体来说，SGX SDK扩展将实现常见的蓝牙可信I/O操作，如用于保护I/O数据的密钥生成和加密/解密、安全策略API等等

5 Proof of Concept

这里，我们证明：
1、Metadata table能被创建，并用于可信IO channel的选择
2、安全策略能够在controller中添加或者删除
3、packet filter能够隔离并加密用户数据而不加密相应的协议头
4、只有trusted app能够解密可信channel传递过来的IO数据

步骤：
创建metadata table，在现有的固件中添加hook来监视HCI和L2CAP的链接、断开事件，并更新table。拓展controller来支持两个新的VSDC用于创建、删除安全策略，当packet到达controller，controller查找packet的信息，决定是否需要进行相关操作。

TA首先利用SGX SDK创建KEY，并使用上述VSDC来编程对应的key到controller中，因为metadata table中有各种信息，可以通过信息对应的channel是否有key来判断是否为可信channel，通过OTA送来的数据，使用OTA key解密之后得到相应的packet，如果属于可信通道的话，controller会对该packet中的数据进行key programming，如果非可信通道的话， 照常执行

6 Summary & Related Work