一、前言
使用者資料加密是移動裝置的重要功能，是使用對稱加密算法對Android裝置上的所有使用者資料進行編碼的過程，防止使用者資料被未經授權的使用者或應用程式通路。
本文是Android系統安全技術系列第二篇，主要介紹基于檔案的加密技術。首先介紹Android保護使用者隐私資料的技術方案，包括全盤加密FDE、檔案加密FBE和中繼資料加密ME。其次介紹基于檔案加密FBE的密鑰管理，涉及HAL、Linux Kernel、TEE和Hardware。
1.1、說明
Google FBE是Android系統中較為複雜的子產品之一。從硬體角度，Google FBE特性依賴ICE（Inline Crypto Engine）、硬體加速引擎或高安子系統。從軟體角度，Google FBE特性涉及frameworks、HAL、Linux Kernel、ATF和TEEOS。本着以點帶面的原則，本文以密鑰管理為主線進行梳理，涉及VOLD、Linux Kernel Keyring、Linux Kernel Fscrypt、KSM、Keymaster和ICE，不涉及VOLD子系統存儲管理、Fscrypt使用者空間部分和F2FS檔案系統IO處理等。
1.2、聲明
本文檔所有代碼來自:
AndroidAOSPhttps://cs.android.com/android/platform/superproject
Linux AOSP https://elixir.bootlin.com/linux/v5.15.111/source
Google Trusty
https://github.com/haitao52198/TrustyOS/tree/master/AndroidTrustyOS
1.3、縮略語
二、使用者隐私資料保護方案
下圖是DCCI（網際網路資料中心）聯合360釋出的《中國Android手機使用者隐私安全認知調查報告》，調查發現，圖檔、聯系人和各種賬号/密碼是三大Android使用者認為屬于隐私的資訊，也是使用者最擔心洩露的三大隐私資訊:
Android裝置可以通路和存儲使用者的個人隐私資料，如果裝置一旦丢失，會極大的增加使用者資料洩露的風險。Google規避該風險的措施之一就是磁盤加密（Disk Encryption）。從Android 4.4開始，Google相繼推出FDE全盤加密、FBE檔案加密和ME中繼資料加密。如果裝置丢失，加密可以将洩露使用者隐私資料的風險降至最低。但必須認識到，無論哪種技術手段，主要解決Android裝置丢失或被盜等場景下，無法有效地擷取使用者資料，即使将使用者資料複制到其它Android裝置，依然可以有效保護使用者的隐私資料。而對于Android裝置運作過程中，攻擊者通過提權等手段擷取使用者的隐私資料，上述技術手段無能為力。
2.1、全盤加密FDE
Full-Disk Encryption，全盤加密，Android 5.0到Android 9.0版本支援，使用密鑰（密鑰本身也會被加密）對Android裝置上的所有使用者資料進行編碼的過程。裝置經過加密後，所有由使用者建立的資料在存入磁盤前都會自動加密，并且所有讀操作都會将資料傳回給調用者之前自動解密。
從Google針對FDE這段描述可知，在系統啟動過程中，會随機生成userdata partition加密密鑰DEK（Disk Encryption Key），同時使用者還需要輸入Credentials來加密保護DEK。使用時，先要求使用者輸入Credentials并解密DEK，接下來OS才可以使用DEK解密userdata partition上的資料。所謂使用者Credentials是開機啟動過程中，在鎖屏界面前，OS會提供單獨的UI供使用者輸入密碼。
從Google針對建立DEK這段描述可知，系統啟動過程中産生16位元組随機數作為DEK，并基于HBK和使用者密鑰建立KEK（Key Encryption Key）。将KEK作為輸入密鑰，采用AES_CBC算法加密DEK。
雖然全盤加密FDE可以保護整個userdata partition，但在啟動時，使用者必須先提供Credentials，然後才可以通路userdata partition，這意味着使用者提供Credentials前，系統無法通路使用者資料，導緻鬧鐘、無障礙服務等無法運作，手機也無法接聽電話，是以全盤加密FDE逐漸被檔案加密FBE替代。
2.2、檔案加密FBE
File-Based Encryption，基于檔案加密，由于Android将userdata partition格式化為F2FS類型檔案系統，是以也可以了解為基于F2FS類型系統的加密。
Android 7.0及更高的版本支援FBE。采用檔案級加密時，允許使用不同密鑰對不同檔案進行加密，同時允許對加密檔案進行單獨解密。支援檔案級加密的裝置支援直接啟動，當使能該功能時，已加密裝置在啟動後可以直接進入鎖屏界面，進而使使用者可以快速使用Android系統的鬧鐘和無障礙服務。這些系統服務主要包括:
總而言之，可以在使用者解鎖前使用系統服務，同時還可以保護使用者的隐私資料。
2.3、中繼資料加密ME
Android 9引入對存在硬體支援的中繼資料加密的支援。采用Metadata Encryption時，啟動時出現的單個密鑰會加密未通過FBE進行加密的任何内容，包括目錄布局、檔案大小、權限和建立/修改時間。該密鑰受Keymaster保護，而Keymaster受到啟動時驗證功能的保護。
三、FBE密鑰架構
3.1、FBE TOP HW Architecture
Android FBE特性依賴UFS和TEE，如果晶片支援高安子系統，還依賴高安子系統。
TEE或高安子系統提供基于硬體環境的KMS（Key Management Service），該服務提供密鑰操作，如密鑰建立（Key Generation）、密鑰派生（Key Derivation）、密鑰程式設計（Key Programming）等。
UFS包括UFS Core和UFS Device，UFS Controller工作在UFS Core内部，用于接收來自AP的資料和指令。
3.2、FBE TOP SW Architecture
在不考慮平台高安子系統的前提下，可以從User space-Kernel space、REE-TEE等多個次元來劃分FBE整體架構。
3.3、FBE設計思路
FBE将userdata partition劃分為Uncrypted Storage、System DE Storage、User DE Storage和User CE Storage等4個區域:
不同的Storage使用不同密鑰。其中，System DE Storage對應SYSTEM_DE_KEY，User DE Storage對應USER_DE_KEY，User CE Storage對應USER_CE_KEY。
3.4、挂載檔案fstab
下圖是Android AOSP的挂載檔案device/linaro/dragonboard/fstab.common:
● fileencryption
格式"fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]"，最多包含3個以英文冒号為分割參數。
● contents_encryption_mode
加密檔案内容算法，可選值有"aes-256-xts"和"adiantum"。從Android 11開始，允許留白以預設加密算法，即"aes-256-xts"。
● filenames_encryption_mode
加密檔案名算法，可選值有"aes-256-cts"、"aes-256-heh"和"adiantum"。如果不指定，當"contents_encryption_mode"為"aes-256-xts"，該參數預設為"aes-256-cts"。如果"contents_encryption_mode"為"adiantum"時，該參數預設為"adiantum"。
● v1 & v2 flag
v2是第二版加密政策，且第二版加密政策使用更安全、更靈活的密鑰派生函數。如果裝置搭載Android 11或更高版本，預設選擇第二版，如果裝置搭載Android 10或更低版本，預設選擇第一版。
● inlinecrypt_optimized
針對無法高效處理大量密鑰的内嵌加密硬體進行優化的加密格式。僅為每個CE或DE密鑰派生一個檔案内容加密密鑰，而不是為每個檔案派生一個，且初始向量IV生成也會相應調整。
● emmc_optimized
與inlinecrypt_optimized類似，初始向量IV限制為32位，該标記僅在符合JEDEC eMMC v5.2規範的内嵌加密硬體上使用，是以僅支援32位IV。在其他内嵌加密硬體上，使用inlinecrypt_optimized，此标記一律不得在基于UFS的儲存設備上使用（UFS規範允許使用64位IV）。
● wrappedkey_v0
在支援内嵌加密硬體的裝置上，允許為FBE使用硬體封裝的密鑰。此标記隻能與inlinecrypt挂載選項以及标記inlinecrypt_optimized或标記emmc_optimized結合使用。
四、VOLD對密鑰的處理
VOLD子系統對密鑰的處理主要可以分為4步，分别是"Mount userdata partition"、"Retrieve or Generate Key"、"Install key into Linux Kernel Keyring"和"Encryption Policy"。
4.1、Mount userdata partition
Init程序是Android系統啟動的第一個程序，調用mount_all指令挂載userdata partition，該指令在system/core/init/builtins.cpp内實作，對應函數do_mount_all。該指令讀取并解析fstab挂載檔案，在挂載userdata partition後發送event。
4.2、Retrieve or Generate Key
Init程序是Android系統啟動的第一個程序。類似mount的處理流程，調用installkey指令建立或提取FBE Class Key，該指令在system/core/init/builtins.cpp内實作，對應函數do_installkey:
該函數首先判斷是否為檔案加密方式，如果是，則執行vdc指令，進而正式進入加密流程。
/system/bin/vdc程序向VOLD發送參數"cryptfs"等，最終調用fscrypt_initialize_systemwide_keys函數，該函數是VOLD子系統處理密鑰的入口函數。
首先調用get_data_file_encryption_options讀取并解析挂載檔案fstab，擷取加密模式、加密算法和加密标志等。其次，函數retrieveOrGenerateKey的處理可以分為系統首次啟動和非首次啟動兩種場景。當系統首次啟動時，将FBE Class Key（encrypted_key）和Keymaster_key（KEK）以KeyBlob形式，并落盤到userdata partition。當系統非首次啟動時，從userdata partition分别提取FBE Class Key和Keymaster_key對應KeyBlob到TEEOS的Keymaster TA進行解密。
4.2.1、解析挂載檔案fstab
函數ParseOptionsForApiLevel讀取并解析挂載檔案fstab，并填充EncryptionOptions結構體:
4.2.2、Retrieve or Generate Key
當系統首次啟動時，将FBE Class Key（encrypted_key）和Keymaster_key（KEK）以KeyBlob形式，并落盤到userdata partition。當系統非首次啟動時，從userdata partition分别提取FBE Class Key和Keymaster_key對應KeyBlob到TEEOS的Keymaster TA進行解密。
4.3、Install key into Linux Kernel Keyring
将FBE Class Key安裝到Linux Kernel Keyring的入口函數是install_storage_key:
VOLD子系統下發IOCTL指令FS_IOC_ADD_ENCRYPTION_KEY到Linux Kernel Keyring，傳回長度為128bit的FBE Class Key Identifier:
函數fscrypt_ioctl_add_key首先接收來自User Space的VOLD子系統的參數。其次可以分為系統首次啟動和非首次啟動兩種場景進行處理。當系統首次啟動時，将Encrypted FBE Class Key儲存在Linux Kernel Keyring。當系統非首次啟動時，從Linux Kernel Keyring提取Encrypted FBE Class Key，最終傳回FBE Class Key Identifier到VOLD子系統。這裡，傳回的Key Identifier使用fscrypt_key_specifier結構體來描述:
4.4、Encryption Policy
4.4.1、Encryption Policy Overview
Android FBE Encryption Policy與mkdir指令參數"encryption"的配置有關:
● "Encryption=Require"
強制設定和校驗目錄Encryption Policy，必須嚴格比對。
● "Encryption=None"
不設定或不校驗目錄Encryption Policy，即該目錄不需要加密。
● "Encryption=Attempt"
嘗試設定/校驗目錄Encryption Policy，即使設定/校驗失敗，不進行任何處理。
● "Encryption=DeleteNecessary"
嘗試設定/校驗目錄Encryption Policy，如果設定/校驗失敗，清空目錄，并再次強制設定和校驗。
4.4.2、Setup Encryption Policy
Init程序是Android系統啟動的第一個程序，調用mkdir指令建立目錄并設定加密政策，該指令在system/core/init/builtins.cpp内實作，對應函數do_mkdir。
最終調用到函數EnsurePolicy設定目錄的加密政策:
從挂載檔案fstab可知，Android FBE選擇V2加密政策。接下來初始化檔案内容加密模式、檔案名加密模式、加密标志和密鑰辨別符（Key Identifier）。
VOLD子系統使用結構體fscrypt_policy_v2描述加密政策:
五、Linux Kernel對密鑰的處理
5.1、核心對FBE Class Key處理架構
fscrypt用于Linux檔案系統加密管理工具，負責管理中繼資料、密鑰生成、密鑰封裝與 PAM 內建，并提供用于建立和修改加密目錄的統一界面。fscrypt 核心部分已內建到諸如ext4檔案系統中。
blk-mq是 Linux 塊裝置層多隊列機制，它将Linux Kernel存儲棧中請求層的單隊列改成多隊列以提升性能。如果blk-mq支援内聯加密（Inline Encryption），它能夠在存儲棧中向下傳遞加密上下文。在Linux Kernel源碼的commit中是這樣解釋的:
這段話的含義是，必須通過某種方式讓儲存設備驅動程式知道應該用于加密/解密請求的加密上下文，上層（如Filesystem or Fscrypt）知道情況并且管理加密上下文。當上層送出 BIO 到塊層，該BIO最終到達的裝置驅動程式支援内聯加密，則裝置驅動程式已經表明BIO加密上下文。回落到代碼上具體改動是将結構體struct bio_crypt_ctx添加到struct bio中，用來表示加密上下文，同時引入各種用于操作 bio_crypt_ctx并使 bio/request合并邏輯知曉 bio_crypt_ctx 的函數。
● Fscrypt從Kernel Keyring提取FBE Class Key。
● F2FS将Wrapped key和Encryption Policy儲存在encryption context。
● KSM負責管理ICE Keyslot，維護Keyslot狀态機。
● TEEOS Keymaster TA負責對ICE Keyslot執行Program和Evict操作。
5.2、Fscrypt
下面這段話是Linux Kernel對fscrypt的描述:
Fscrypt是一個庫，檔案系統可以通過它以支援檔案和目錄的透明加密功能。fscrypt運作在檔案系統級别，而不是塊級别，這允許它使用不同的密鑰加密不同的檔案，并在同一檔案系統上擁有未加密的檔案。必須注意的是，除Filename外，fscrypt不會加密檔案系統的中繼資料。
Fscrypt不作為本文檔介紹的重點，仍然回到和FBE密鑰處理相關的流程。接下來分析fscrypt如何處理目錄/檔案的加密政策。從4.4.2章節可知，VOLD下發IOCTL指令FS_IOC_SET_ENCRYPTION_POLICY到Linux Kernel，并調用函數fscrypt_ioctl_set_policy繼續處理加密政策:
該函數的處理邏輯并不複雜，首先從VOLD子系統擷取Encryption Policy，并将Encryption Policy儲存到目錄/檔案的inode，儲存前會先比較是否已經設定Encryption Policy，如果是，判斷兩次設定是否一緻，不一緻則報錯。
5.3、F2FS filesystem
F2FS，Flash Friendly File System，專門為基于NAND儲存設備設計的新型開源flash檔案系統，特别針對NAND閃存存儲媒體進行了友好設計。
F2FS将整個卷切分成大量的Segments，每個Segment的大小固定為2MB。連續若幹個Segments構成Section，連續若幹個Section構成Zone。F2FS檔案系統将整個卷切分成6個區域，除了超級塊（Superblock，簡稱SB）外，其餘每個區域都包含多個Segments，其結構如下圖所示:
5.3.1、Segments
連續的Blocks集合成Segments，一個Segment的大小是512個Blocks（2MB），每個Segment都有一個Segment Summary Block中繼資料結構，描述了Segment 中的每個Block的所有者（該塊所屬的檔案及塊在檔案内的偏移）。Segment Summary主要用于在執行Cleaning操作時識别哪些Blocks中的資料需要轉移到新的位置，以及在轉移之後如何更新Blocks的索引資訊。一個Block就可以完全存儲512個Blocks的summary資訊，每個blocks都有一個1 bit的額外空間用于其它目的。
5.3.2、Superblock
F2FS 的 f2fs_super_block 存儲在裝置的第二個塊中，僅包含隻讀資料，稱為超級塊 Superblock 。一旦檔案系統建立，SB 的資訊就不會再改變，SB 描述了檔案系統有多大、Segment 有多大、Section有多大、Zone 有多大以及配置設定了多少空間給各個部分的“中繼資料”區域以及其他少量的細節資訊。SB 位于檔案系統分區的開頭，有兩個備份以避免檔案系統 crash 無法恢複的情況發生。它包含基本的分區資訊和預設的 F2FS 參數。
5.3.3、Main Area
Main Area被4KB大小的block所填充，這些block可以配置設定給檔案的data或者檔案的node，是F2FS檔案系統的主要資料儲存區域。
5.4、KSM
KeySlot Manager，密鑰槽管理器，下面是Linux Kernel對KSM的描述:
由此可知，KSM是Linux kernel用于維護ICE（Inline Crypto Engine）内部keyslot硬體密鑰槽的狀态機，由結構體blk_keyslot_manager來描述:
該結構體的重點是成員struct blk_ksm_ll_ops ksm_ll_ops，定義對ICE Keyslot的操作函數集。成員函數keyslot_program用于對Keyslot執行Program操作，成員函數keyslot_evict用于對Keyslot執行Evict操作。
5.4.1、keyslot_program
以keyslot_program回調函數cqhci_crypto_keyslot_program@drivers/mmc/host/cqhci-crypto.c為例來說明如何對ICE Keyslot執行Program操作，且晶片平台廠商可以客制化。
該函數将參數key指向的加密上下文程式設計到處于idle狀态的keyslot中，将程式設計成功keyslot index儲存到參數slot。通過這種方式實作了"密鑰可用不可見"，即密鑰被儲存在ICE硬體Keyslot内，軟體隻可以擷取儲存密鑰的keyslot index。
5.4.2、keyslot_evict
以keyslot_evict回調函數cqhci_crypto_keyslot_program@drivers/mmc/host/cqhci-crypto.c為例來說明如何對ICE Keyslot執行evict操作，且晶片平台廠商可以客制化。
根據參數key指向的加密上下文，擷取在ICE硬體的keyslot index，并請求TEEOS Keymaster TA，根據keyslot index對ICE硬體内部keyslot執行evict操作。通過這種方式實作了"密鑰可用不可見"，即密鑰被儲存在ICE硬體Keyslot内，軟體隻可以根據密鑰keyslot index執行evict操作。
六、TEEOS對密鑰的處理
注：以Google Trusty來分析TEEOS對AES對稱密鑰的處理流程。
6.1、Trusty TEE Architecture
Google Trusty是一種安全OS，可為Android提供可信執行環境（TEE）。Trusty OS和Android OS在同一處理器上運作，通過硬體和軟體與系統的其餘元件進行隔離，且Trusty與Android彼此并行運作。Trusty可以通路裝置主處理器和記憶體的全部功能，但完全隔離。隔離可以保護Trusty免受使用者安裝的惡意應用以及可能在Android中發現的潛在漏洞的侵害。
運作時，Trusty 應用在 Trusty 核心下以隔離程序的形式在非特權模式下運作。每個程序都會利用 TEE 處理器的記憶體管理單元功能在各自的虛拟記憶體沙盒中運作。
6.2、Trusty Keymaster Architecture
Android Keystore API和Keymaster HAL提供一組加密原語，允許使用通路受控、硬體支援的密鑰來實作協定。Keymaster HAL是OEM提供的可動态加載的庫，Keystore服務使用它來提供硬體支援的加密服務。為確定安全，HAL實作不會在使用者空間甚至核心空間中執行任何敏感操作。敏感操作委托給通過某些核心接口達到的TEEOS，總的架構如下圖所示:
Android裝置中，Keymaster HAL的用戶端包含App、frameworks、KeyStore daemon，其目的不是實作安全敏感型算法，而是對發送到TEEOS的請求進行編排和解排，真正實作安全敏感計算的是位于TEEOS的Keymaster TA。下圖是Google對Keymaster架構的描述:
6.3、Keymaster Feature
下面是Google對Keymaster feature的定義:
可以看出，Keymaster功能強大。回歸到FBE密鑰架構領域，FBE密鑰派生依賴Keymaster TA的Key generation特性，該特性與Key characteristics、Purpose、Client binding、Root of trust binding和version binding多重因素有關。
6.3.1、Key characteristics
無論是FBE Class key，還是加密FBE Class key的KEK，均采用AES對稱算法，下面是Keymaster支援AES對稱算法種類的描述:
是以，請求Keymaster派生密鑰時，需要提供key characteristics:
6.3.2、Key Purpose
系統首次啟動時需要建立FBE Class key和KEK，并以Keyblob形式落盤在userdata partition，這種場景下需要使用Keymaster加密功能。系統非首次啟動時，從userdata partition提取Keyblob以擷取FBE Class key和KEK，這種場景下需要使用Keymaster解密功能。是以，向Keymaster發送請求時，需要指定密鑰目的:
6.3.3、Client binding
Keymaster要求産生的密鑰需要和對應的應用進行綁定，綁定參數是APP_ID或ADD_DATA:
6.3.4、Root of trust binding
下圖是Google對Root of trust的描述:
6.3.5、version binding
下圖是Google對version binding的描述:
6.4、FBE key hierarchy
下圖是Android FBE密鑰體系:
在密鑰派生系統中，主要包含"FileContens Encryption Key"、"FileName Encryption Key"和"Key Identifier"。
Linux Kernel KSM子產品提供回調函數可以使用blk_crypto_ll_ops::keyslot_program将FileContents Encryption Key程式設計到ICE硬體Keyslot内，使用blk_crypto_ll_ops::derive_sw_secret進行密鑰派生。
6.5、Keymaster派生FBE Class key
該函數處理邏輯并不複雜，最終FBE Class key以Keyblob形式落盤到userdata partition。
七、Inline Crypto Engine
基于軟體的加密解決方案使用CPU來執行加密和解密任務，雖然這種方法提供了相當多的性能，但由于需要不斷提高存儲速度，是以存在不足。為了客服性能下降，JEDEC等标準機構向主機控制器内添加基于硬體的内聯加密功能。内聯意味着硬體加密引擎位于主機控制器内部，并動态加密和解密資料。使用内聯硬體加密引擎處理大量安全資料。
就Android裝置而言，内聯加密引擎ICE位于UFS内部。當AP從DDR寫資料到UFS Device時，需要對資料流進行加密。當AP從UFS Device讀資料到DDR時，需要對資料流進行解密。下圖是包含AES加解密引擎的UFS Controller内部邏輯框圖:
八、總結
本文首先介紹了使用者隐私資料保護方案，包括全盤加密FDE、檔案加密FBE和中繼資料加密ME。其次本着以點帶面的原則，以密鑰管理為主線詳細梳理了VOLD子系統、Linux Kernel和TEEOS的密鑰處理流程，最後對内聯加密引擎ICE進行了介紹。
希望讀者可以通過這篇文檔對Android檔案加密FBE有整體認識，受限于篇幅，更受限于晶片廠商專利等諸多因素，很多技術細節和方案無法更詳細展開，希望在後續文章中能夠結合開源方案和代碼可以更深入剖析FBE技術細節，如Linux Kernel Keyring、Fscrypt、檔案IO等。
參考資料
Full Disk Encryption https://source.android.com/docs/security/features/encryption/full-disk
File-Based Encryption https://source.android.com/docs/security/features/encryption/file-based
Metadata Encryption https://source.android.com/docs/security/features/encryption/metadata
Hardware-Wrapped Keys https://source.android.com/docs/security/features/encryption/hw-wrapped-keys
Android AOSP https://cs.android.com/android/platform/superproject
Linux AOSP https://elixir.bootlin.com/linux/v5.15.111/source
Google Trusty https://source.android.com/docs/security/features/trusty
Google Keystore https://source.android.com/docs/security/features/keystore
Google Trusty Code https://github.com/haitao52198/TrustyOS/tree/master/AndroidTrustyOS
Inline Encryption https://www.synopsys.com/designware-ip/technical-bulletin/emmc-and-ufs-inline-encryption-2017q4.html