【数据安全】2. Android 全盘加密（Full Disk Encryption）技术介绍

FDE (Full disk encryption) 的发展经历了几个阶段：

• 基于软件/硬件实现的 dm-crypt
• 基于硬件 GPCE 实现的 request-dm-crypt
• 基于硬件 ICE 实现的 dm-req-crypt

1. 术语解释

dm-crypt / request-dm-crypt / dm-req-crypt

它们都是位于 linux kernel block 层， 用于加解密数据的 Device Mapper 驱动模块，下文统称 dm crypt 驱动。Device Mapper 可以将整个 block 设备或 block  设备的部分映射到单个设备。

这些 dm crypt 驱动模块使用这个特性将整个用户数据分区，即用户数据分区中的所有扇区映射到另一个设备，例如/dev/dm-N。此时用户数据分区上的任何操作都由设备映射层处理，dm crypt 驱动模块加密所有写操作，并解密所有的读操作。最终整个加密和解密数据的过程对于用户来说是透明的。

至于这些 dm crypt 驱动模块的区别则是拥有更好的 I/O 性能，主要表现在 I/O 吞吐量和 I/O 延时，下文详细介绍。

GPCE

general-purpose crypto engine，ARM 体系结构提供的通用加密引擎。

ICE

inline crypto engine，一般由 SOC 厂商实现，内嵌到存储器控制器的加密引擎。

2. 基于软件/硬件实现的 dm-crypt

该方案已经被废弃，这里只做简单介绍，架构如下所示：

使用 dm-crypt 加密磁盘：

• dm-crypt 是在基于 BIO 的设备映射器之上提供的磁盘加密机制，它在物理块设备之上提供虚拟块层。
• dm 层将接收到的块 I/O (BIO) 克隆并映射到底层物理设备。
• Android系统中的 VOLD 使用 dm-crypt 将用户数据分区映射到 cryptfs 文件系统。所有对 cryptfs 文件系统的写入都被加密，读取被解密。
• Android 使用 128 位 AES-CBC 模式以及 ESSIV:SHA256 来加密和解密数据。所有加密材料，例如加密密钥和加密类型，都存储在用户数据分区的底部 16 K 中。
• dm-crypt 使用 512 字节的数据包大小来加密和解密数据。这意味着必须为每个扇区创建一个新的密码上下文。除此之外，每次为每个扇区生成 IV，即使用 SHA-256 的 512 字节，这是一个昂贵的机制。
• VOLD 管理所有加密材料并在启动时将其提供给设备映射设备。

基于软件的实现

从安全的角度来看，如果加密操作是在软件中完成的，那么密钥必须存在于软件中，这是不可取的。基于软件的磁盘加密有几个缺点：

• 它很慢。
• 所有加密操作都发生在软件中，因此非常耗电且消耗大量电力。
• 将密钥存储在 RAM 中，可以被转储和搜索，所以并不安全。

基于硬件的实现

由于通用硬件加密引擎不能很好地处理较小的数据包大小，因此仍然存在性能问题。

3. 基于硬件 GPCE 实现的 request-dm-crypt

该方案已经被废弃，这里只做简单介绍，架构如下所示：

相比基于 BIO 的映射器的 dm-crypt， request-dm-crypt 是基于请求的设备映射器，不同之处在于：

• request-dm-crypt 设备映射器不是克隆和映射 BIO，而是移动到软件架构 stack 中的较低位置，它克隆和映射 I/O 请求。
• 不需要和 dm-crypt 一样，使用 512 字节的数据包大小来加密和解密数据，大大释放了 GPCE 的性能。

3.1 写操作流程

1. dm 层调用已注册插件 (request-dm-crypt) 的 map API；
2. map 函数还会遍历请求中的所有 BIO，并创建所有数据的 SGL（scatter gather list）；
3. 然后 map 函数调用 Kernel Crypto API，该 API 最终调用 GPCE 加密驱动程序以执行加密操作；
4. 加密完成后，克隆的请求被添加到 I/O 调度程序队列；

3.2 读操作流程

1. 当块驱动完成读请求时，请求被传递到通用块层（blk_end_bidi_request）以完成请求；
2. 通用块层通过调用请求的end_io函数来完成请求；
3. end_io 函数然后调用 request-dm-crypt 的 end_io 函数；
4. request-dmcrypt end_io 函数遍历请求中的 BIO 并创建一个 SGL。然后该函数使用此列表调用内核加密 API；
5. Kernel Crypto API 最终调用 GPCE 加密驱动程序来执行解密操作；
6. 最终将数据返回到文件系统。

使用通用加密引擎 (GPCE) 提供了可以接受的性能量，但由于存储速度不断提高，它还不够。因为 I/O 请求需要通过 request-dm-crypt 处理来执行数据加密和解密，从架构图中可以看出，在原来的 I/O 流程中增加了一个环节增加了延时。因此 FDE 又进化到下文介绍的基于 ICE 实现的 dm-req-crypt。

4. 基于硬件 ICE 实现的 dm-req-crypt

为了克服性能下降，较新的芯片将内联加密引擎 (ICE) 嵌入到存储设备中。基于 ICE 的 FDE 在 ICE 硬件中执行所有加密操作，而无需返回软件。该解决方案提供几乎线速的吞吐量，即加密设备上的 I/O 吞吐量不会降低。

 FDE Architecture

4.1 硬件相关的实现

ICE 是嵌入到 UFS/eMMC 等存储设备中的硬件块。默认情况下，ICE工作在 Bypass 模式，即ICE硬件不对存储设备要处理的数据进行任何加密操作，这称为 ICE 的全局旁路模式。如果需要，可以将 ICE 配置为在一个方向（即加密或解密）或两个方向（加密和解密）执行加密操作。

ICE 硬件的一些特征：

• 支持 AES-128/-256 位 ECB 和 XTS 模式加密算法；
• 加密操作的密钥是从软件中加载的；
• 密钥存储在位于 ICE 硬件内部的查找表 (LUT) 中；
• ICE key LUT 中最多可以加载 32 个 key；
• LUT 中的 key 可以通过 key 索引来引用；

4.2 软件相关的实现

ICE 硬件将 ICE 寄存器分为两组：

• 只能被安全端访问的寄存器，即 TZ
• 非安全端也可以访问的寄存器，例如 HLOS

这种分类要求将 ICE 驱动程序分成两部分：一个从 TZ 空间运行，另一个从 HLOS 空间运行。

TZ 的 ICE 驱动程序根据 HLOS 端的要求配置密钥：

• 出于安全考虑，ICE 驱动程序的 TZ 端负责在冷启动期间重置所有 ICE 密钥 LUT。
• 根据 HLOS 的请求，TZ 设置所需的 ICE 硬件寄存器以配置 ICE 硬件中的密钥。
  • 密钥配置的一部分是设置上下文，包括算法、模式、密钥长度等。
  • 另一部分是设置实际密钥。

HLOS 侧的 ICE 驱动程序：

• 负责 ICE 硬件的初始化。
• 帮助存储驱动程序决定是否对请求执行加密操作。如果决定执行加密操作，则 HLOS 端的 ICE 驱动程序提供所需的配置参数。比如高通平台：
  • 在首次加密或加密后重启设备时，当 VOLD 准备好开始加密时（即用户数据分区已卸载），它会通过 libQSEECom 的 API 创建或设置密钥。
  • libQSEECom 使用基于 IOCTL 的机制与 QSEECom 驱动程序通信，最终调用 TZ 端的 ICE 驱动程序。

基于 GPCE 和 ICE 的 FDE 解决方案的密钥管理方式没有重大变化。但是，密钥管理有两个不同之处：

• 基于 ICE 的解决方案在 ICE 硬件密钥 LUT 中设置密钥。
• 基于 GPCE 的 FDE 的情况下，密钥在管道寄存器中设置。
• 基于 ICE 的解决方案在已设置密钥的 ICE 硬件中返回密钥 LUT 中的密钥索引。
• 基于 GPCE 的 FDE 的情况下，对 TZ 的调用将返回成功（即正整数）或失败（负整数）。

4.3 数据的处理流

加解密时，数据路径类似于基于 GPCE 的 FDE，但有一些区别 ：

1. 在基于 ICE 的 FDE 的情况下，VOLD 创建基于 dm-req-crypt 的映射设备。在设备创建时，VOLD 提供了已配置密钥的 ICE 密钥 LUT 的密钥索引。
2. 在 ICE 的情况下，映射设备被配置为在透明（Transparent）模式下工作。
3. 当基于 dm-req-crypt 的设备工作在透明模式时，VOLD 使用密钥索引更新映射的请求并将请求提交给 elevator。
4. 该请求到达存储驱动程序，它为每个接收到的请求调用 ICE 驱动程序，以了解是否必须执行任何加密操作或绕过加密操作。
   1. 如果请求需要加密操作，存储驱动程序会从 ICE 驱动程序返回密钥索引值。
   2. 存储驱动程序将请求发送到存储硬件，ICE硬件将执行所需的加密操作。
5. 当存储驱动程序完成请求时，执行返回到设备映射器驱动程序，该驱动程序调用基于 dm-req-crypt 的 endio 函数来完成请求。由于 ICE 硬件已经执行了加密操作，endio 函数立即完成请求。

对比基于 GPCE 的 FDE 的架构图可知，它们的最大的区别在于第 2 和第5步，基于 ICE 的 FDE，在这两个步骤中几乎没有损耗，而基于 GPCE 的 FDE 则在这里面分别执行加密和解密数据的操作。

5.总结

几个 FDE 版本的不断迭代，收益主要是体现在：

 密钥管理越来越安全

• 用于数据加解密的实际密钥不会出现在 HLOS ，同时 HLOS 也无法访问，由 TZ KMS 统一管理；
• 密钥无法被 dump、搜索以及 debug (e.g. JTAG)；
• 密钥的创建、更新和删除等操作以及使用都严格控制；

对 I/O 性能的性能越来越小

• 基于 ICE 的实现，执行 I/O 时，数据在存储器控制器里流式加解密；
• kernel I/O 软件 stack 几乎不需要增加额外开销；
• 当然代价是需要增加专属硬件模块；