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 写操作流程

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

3.2 读操作流程

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

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

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

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

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，但有一些区别：

在基于 ICE 的 FDE 的情况下，VOLD 创建基于 dm-req-crypt 的映射设备。在设备创建时，VOLD 提供了已配置密钥的 ICE 密钥 LUT 的密钥索引。
在 ICE 的情况下，映射设备被配置为在透明（Transparent）模式下工作。
当基于 dm-req-crypt 的设备工作在透明模式时，VOLD 使用密钥索引更新映射的请求并将请求提交给 elevator。
该请求到达存储驱动程序，它为每个接收到的请求调用 ICE 驱动程序，以了解是否必须执行任何加密操作或绕过加密操作。
1. 如果请求需要加密操作，存储驱动程序会从 ICE 驱动程序返回密钥索引值。
2. 存储驱动程序将请求发送到存储硬件，ICE硬件将执行所需的加密操作。
当存储驱动程序完成请求时，执行返回到设备映射器驱动程序，该驱动程序调用基于 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 几乎不需要增加额外开销；
当然代价是需要增加专属硬件模块；

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

android 蓝牙低耗能（LBE）技术介绍
蓝牙低能耗(BLE)技术是低成本.短距离.可互操作的鲁棒性无线技术.工作在免许可的2.4GHz ISM射频频段.它从一開始就设计为超低功耗(ULP)无线技术. 它利用很多智能手段最大限度地减少功耗. ...
Android+6.0的全盘加密(,Android6.0强制全盘加密隐私牺牲性能
Android6.0强制全盘加密隐私牺牲性能 2015年10月20日 10:05作者:董岩编辑:董岩文章出处:泡泡网原创分享一款操作系统,刨去其可操作性,用户可能比较关注的就是其性能及安全性,两 ...
Android11取消强制加密,悲催！Android 6.0设备强制要求开启全盘加密
Android 6.0上大家最不愿意看到的事情发生了,不得不说真是挺悲剧的. 现在有外媒报道称,谷歌已经向所有厂商要求,Android 6.0的全盘加密(Full Disk Encryption,即F ...
【数据安全】3. Android 文件级加密（File-based Encryption）技术介绍
1. 概览 1.1 设计概览采用文件级加密时: 可以使用不同的密钥对不同的文件进行加密,也可以对加密文件单独解密可以有的放矢,没有安全要求的文件可以不加密支持多用户,不同用户使用不同的密钥基 ...
使能全盘加密后的Android ota升级
1. 背景知识关于Android全盘加密功能的实现可以参考https://source.android.google.cn/security/encryption/full-disk.data分区的 ...
Android加密之全盘加密详解
前言 Android 的安全性问题一直备受关注,Google 在 Android 系统的安全方面也是一直没有停止过更新,努力做到更加安全的手机移动操作系统. 在 Android 的安全性方面,有很多模 ...
AOSP ~系统安全全盘加密
在 Android 的安全性方面,有很多模块: 内核安全性应用安全性应用签名身份验证 Trusty TEE SELinux 加密 - 其中,加密又分全盘加密(Android 4.4 引入)和文件 ...
Android安全加密：非对称加密
Android安全加密专题文章索引 Android安全加密:对称加密 Android安全加密:非对称加密 Android安全加密:消息摘要Message Digest Android安全加密:数字签名 ...
Full Disk Encryption(FDE)全盘加密开关
android L 搭载 Android 5.0 系统的 Nexus 6 在强制开启了 FDE 的情况下,随机读取性能下降了 62.9%,随机写入性能下降了 50.5%,有序读取性能的下降幅度达到了惊 ...

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