檔案型加密

Android 7.0 以上版本支援檔案型加密 (FBE)。檔案加密功能可讓不同檔案使用不同金鑰加密，且這些金鑰可獨立解鎖。

本文說明如何在全新裝置上啟用檔案型加密，以及系統應用程式如何使用直接啟動 API，盡可能為使用者提供最佳且最安全的體驗。

凡是搭載 Android 10 以上版本的裝置，都必須使用檔案型加密。

直接啟動

檔案型加密可啟用 Android 7.0 導入的新功能「直接啟動」。直接啟動功能可讓加密裝置直接啟動至鎖定畫面。先前，如果裝置採用全磁碟加密 (FDE)，使用者必須先提供憑證才能存取任何資料，因此手機只能執行最基本的操作。例如，鬧鐘無法運作、無法使用無障礙服務，且手機無法接聽電話，只能撥打緊急電話。

導入檔案加密 (FBE) 和新版 API 後，應用程式就能瞭解加密狀態，並在有限的環境中運作。這類要求可能在使用者提供憑證前發生，但仍會保護私密的使用者資訊。

在啟用 FBE 的裝置上，裝置的每位使用者都有兩個儲存空間位置可供應用程式使用：

• 憑證加密 (CE) 儲存空間，這是預設的儲存位置，只有在使用者解鎖裝置後才能使用。
• 裝置加密 (DE) 儲存空間，這是在直接啟動模式中，以及使用者解鎖裝置後皆可使用的儲存位置。

這種分離式設計可讓工作資料夾更安全，因為加密不再只依據開機密碼，因此可同時保護多位使用者。

加密感知應用程式可透過 Direct Boot API 存取上述各個區域。應用程式生命週期有所變更，以因應在使用者於鎖定螢幕上首次輸入憑證，或在工作資料夾提供工作驗證時，需要通知應用程式使用者 CE 儲存空間已解鎖的需求。搭載 Android 7.0 的裝置必須支援這些新的 API 和生命週期，無論是否實作 FBE 皆然。不過，如果沒有 FBE，DE 和 CE 儲存空間一律會處於解鎖狀態。

Android 開放原始碼計畫 (AOSP) 提供 Ext4 和 F2FS 檔案系統的完整檔案加密實作，只要在符合需求的裝置上啟用即可。如果製造商選擇使用 FBE，可以根據所用的晶片系統 (SoC)，探索如何最佳化這項功能。

Android 開放原始碼計畫中的所有必要套件都已更新，可支援直接啟動。 不過，如果裝置製造商使用這些應用程式的自訂版本，至少要確保有支援直接啟動的套件提供下列服務：

• 電話服務和撥號程式
• 在鎖定畫面上輸入密碼的輸入法

範例和來源

Android 提供檔案型加密的參考實作，其中 vold (system/vold) 提供管理 Android 儲存裝置和磁碟區的功能。新增 FBE 後，vold 會提供多個新指令，支援多位使用者的 CE 和 DE 金鑰管理。除了核心的檔案加密功能，許多系統套件 (包括鎖定螢幕和 SystemUI) 也經過修改，可支援 FBE 和直接啟動功能。其中包括：

• Android 開放原始碼計畫撥號鍵盤 (packages/apps/Dialer)
• 桌鐘 (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• 「設定」應用程式 (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* 使用 defaultToDeviceProtectedStorage 資訊清單屬性的系統應用程式

如要查看更多支援加密的應用程式和服務範例，請在 AOSP 來源樹狀結構的架構或套件目錄中執行 mangrep directBootAware 指令。

依附元件

如要安全使用 FBE 的 AOSP 實作方式，裝置必須符合下列依附元件：

• 核心支援 Ext4 加密或 F2FS 加密。
• KeyMint (或 Keymaster 1.0 以上版本) 支援。Keymaster 0.3 不提供必要的加密金鑰功能或足夠的保護措施，因此不支援這項功能。
• KeyMint/Keymaster 和 Gatekeeper 必須在受信任的執行環境 (TEE) 中實作，才能保護 DE 金鑰，防止未經授權的作業系統 (刷入裝置的自訂作業系統) 輕易要求 DE 金鑰。
• 必須將硬體信任根和驗證開機程序繫結至 KeyMint 初始化，確保未經授權的作業系統無法存取 DE 金鑰。

實作

首先，鬧鐘、電話和無障礙功能等應用程式應根據直接啟動開發人員文件，設為 android:directBootAware。

核心支援

Android 通用核心 3.18 以上版本支援 Ext4 和 F2FS 加密。如要在 5.1 以上版本的核心中啟用這項功能，請使用：

CONFIG_FS_ENCRYPTION=y

如果是較舊的 Kernel，請使用 CONFIG_EXT4_ENCRYPTION=y (如果裝置的userdata檔案系統是 Ext4)，或使用 CONFIG_F2FS_FS_ENCRYPTION=y (如果裝置的userdata檔案系統是 F2FS)。

如果裝置支援可採用儲存空間，或在內部儲存空間使用中繼資料加密，請一併啟用中繼資料加密所需的 Kernel 設定選項，詳情請參閱中繼資料加密說明文件。

除了支援 Ext4 或 F2FS 加密功能，裝置製造商也應啟用加密加速功能，加快檔案加密速度並提升使用者體驗。舉例來說，在 ARM64 型裝置上，您可以設定下列核心設定選項，啟用 ARMv8 CE (Cryptography Extensions) 加速功能：

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

為進一步提升效能及降低耗電量，裝置製造商也可以考慮實作內嵌加密硬體，在資料傳輸至/自儲存裝置時進行加密/解密。Android 通用核心 (4.14 以上版本) 包含一個架構，可在硬體和供應商驅動程式支援的情況下，使用內嵌加密功能。如要啟用內嵌加密架構，請設定下列核心設定選項：

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

如果裝置使用 UFS 型儲存空間，請一併啟用：

CONFIG_SCSI_UFS_CRYPTO=y

如果裝置使用 eMMC 型儲存空間，請一併啟用下列項目：

CONFIG_MMC_CRYPTO=y

啟用檔案型加密

如要在裝置上啟用 FBE，必須在內部儲存空間 (userdata) 上啟用。這也會自動在可採用儲存空間上啟用 FBE；不過，如有必要，可覆寫可採用儲存空間的加密格式。

內部儲存空間

如要啟用 FBE，請在 userdata 的 fstab 行中，將 fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] 選項新增至 fs_mgr_flags 欄。這個選項會定義內部儲存空間的加密格式。最多可包含三個以半形冒號分隔的參數：

• contents_encryption_mode 參數會定義用於加密檔案內容的加密演算法。可以是 aes-256-xts 或 adiantum。自 Android 11 起，您也可以將這個欄位留空，指定預設演算法 (即 aes-256-xts)。
• filenames_encryption_mode 參數會定義用於加密檔案名稱的加密演算法。可以是 aes-256-cts、aes-256-heh、adiantum 或 aes-256-hctr2。如未指定，如果 contents_encryption_mode 為 aes-256-xts，則預設為 aes-256-cts；如果 contents_encryption_mode 為 adiantum，則預設為 adiantum。
• Android 11 新增的 flags 參數是以 + 半形字元分隔的旗標清單。系統支援下列旗標：
  • v1 標記會選取第 1 版加密政策；v2 標記則會選取第 2 版加密政策。版本 2 加密政策採用更安全且彈性的金鑰衍生函式。如果裝置搭載 Android 11 以上版本 (由 ro.product.first_api_level 決定)，預設為 V2；如果裝置搭載 Android 10 以下版本，預設為 V1。
  • inlinecrypt_optimized 旗標會選取經過最佳化的加密格式，適用於無法有效處理大量金鑰的內嵌加密硬體。這項功能會為每個 CE 或 DE 金鑰衍生一個檔案內容加密金鑰，而非為每個檔案衍生一個金鑰。系統會相應調整 IV (初始化向量) 的產生方式。
  • emmc_optimized 旗標與 inlinecrypt_optimized 類似，但也會選取 IV 生成方法，將 IV 限制為 32 位元。這個旗標只能用於符合 JEDEC eMMC v5.2 規格的內嵌加密硬體，因此僅支援 32 位元 IV。如果是其他內嵌加密硬體，請改用 inlinecrypt_optimized。這個標記絕不應在 UFS 型儲存空間上使用；UFS 規格允許使用 64 位元 IV。
  • 在支援硬體包裝金鑰的裝置上，wrappedkey_v0 標記可啟用硬體包裝金鑰，用於 FBE。這項選項只能與 inlinecrypt 掛接選項，以及 inlinecrypt_optimized 或 emmc_optimized 旗標搭配使用。
  • 即使檔案系統區塊大小不是 4096 個位元組，dusize_4k 標記仍會強制加密資料單元大小為 4096 個位元組。加密資料單元大小是檔案內容加密作業的精細程度。這個標記適用於 Android 15 以上版本。如果裝置使用大於 4096 位元組的頁面大小，且使用 f2fs 檔案系統，則只有在啟用不支援大於 4096 位元組資料單位的內嵌加密硬體時，才應使用這個標記。

如果沒有使用內嵌加密硬體，建議大多數裝置採用 fileencryption=aes-256-xts 設定。如果您使用內嵌加密硬體，建議大多數裝置採用 fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (或同等的 fileencryption=::inlinecrypt_optimized) 設定。如果裝置沒有任何形式的 AES 加速功能，可以設定 fileencryption=adiantum，改用 Adiantum 取代 AES。

自 Android 14 起，對於具備加速加密指令的裝置，AES-HCTR2 是檔案名稱加密的首選模式。不過，只有較新的 Android 核心支援 AES-HCTR2。在日後的 Android 版本中，這項功能預計會成為檔案名稱加密的預設模式。如果核心支援 AES-HCTR2，您可以將 filenames_encryption_mode 設為 aes-256-hctr2，啟用檔案名稱加密功能。在最簡單的情況下，這會透過 fileencryption=aes-256-xts:aes-256-hctr2 完成。

如果裝置搭載 Android 10 以下版本，也可以使用 fileencryption=ice 指定使用 FSCRYPT_MODE_PRIVATE 檔案內容加密模式。Android 通用核心並未實作這個模式，但供應商可使用自訂核心修補程式實作。這個模式產生的磁碟格式是特定於供應商。如果裝置搭載 Android 11 以上版本，就不再允許使用這個模式，必須改用標準加密格式。

根據預設，檔案內容加密作業會使用 Linux 核心的密碼編譯 API 進行。如要改用內嵌加密硬體，請一併新增 inlinecrypt 掛接選項。舉例來說，完整的 fstab 行可能如下所示：

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

合併儲存空間

自 Android 9 起，FBE 和可採用儲存空間可一併使用。

為 userdata 指定 fileencryption fstab 選項，也會自動在可採用儲存空間上啟用 FBE 和中繼資料加密。不過，您可以在 PRODUCT_PROPERTY_OVERRIDES 中設定屬性，覆寫可採用儲存空間的 FBE 或中繼資料加密格式。

如果裝置搭載 Android 11 以上版本，請使用下列屬性：

• ro.crypto.volume.options (Android 11 的新功能) 會在可攜式儲存空間上選取 FBE 加密格式。其語法與 fileencryption fstab 選項的引數相同，且使用相同的預設值。請參閱上方的 fileencryption 建議，瞭解這裡應使用的內容。
• ro.crypto.volume.metadata.encryption 會選取可攜式儲存空間上的中繼資料加密格式。請參閱中繼資料加密說明文件。

在搭載 Android 10 以下版本的裝置上，請使用下列屬性：

• ro.crypto.volume.contents_mode 選取內容加密模式。這相當於 ro.crypto.volume.options 的第一個以半形冒號分隔的欄位。
• ro.crypto.volume.filenames_mode 選取檔案名稱 加密模式。這相當於 ro.crypto.volume.options 的第二個以半形冒號分隔的欄位，但搭載 Android 10 以下版本的裝置預設為 aes-256-heh。在大多數裝置上，這項設定必須明確覆寫為 aes-256-cts。
• ro.crypto.fde_algorithm，然後選取可設為合併儲存空間的資料加密格式。ro.crypto.fde_sector_size請參閱中繼資料加密說明文件。

與 KeyMint 整合

KeyMint HAL 應做為 early_hal 類別的一部分啟動。這是因為 FBE 要求 KeyMint 必須在 post-fs-data 開機階段準備好處理要求，而 vold 會在這個階段設定初始金鑰。

排除目錄

init 會將系統 DE 金鑰套用至 /data 的所有頂層目錄，但必須保持未加密的目錄除外，例如包含系統 DE 金鑰本身的目錄，以及包含使用者 CE 或 DE 目錄的目錄。加密金鑰會以遞迴方式套用，且無法由子目錄覆寫。

在 Android 11 以上版本中，您可以透過 init 指令碼中 mkdir 指令的 encryption=<action> 引數，控制 init 套用至目錄的鍵。<action> 的可能值記錄在 Android 初始化語言的 README 中。

在 Android 10 中，init 加密動作已硬式編碼到下列位置：

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

在 Android 9 以下版本中，位置為：

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

您可以新增例外狀況，防止特定目錄遭到加密。如果進行這類修改，裝置製造商應加入 SELinux 政策，只允許需要使用未加密目錄的應用程式存取。這樣應該就能排除所有不受信任的應用程式。

目前已知唯一可接受的用途是支援舊版 OTA 功能。

在系統應用程式中支援直接啟動

讓應用程式支援直接啟動模式

為利於快速遷移系統應用程式，您可以在應用程式層級設定兩個新屬性。defaultToDeviceProtectedStorage 屬性僅適用於系統應用程式。所有使用者都能使用 directBootAware 屬性。

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

應用程式層級的 directBootAware 屬性是簡寫，可將應用程式中的所有元件標示為加密感知。

defaultToDeviceProtectedStorage 屬性會將預設應用程式儲存位置重新導向至 DE 儲存空間，而非 CE 儲存空間。使用這個標記的系統應用程式必須仔細稽核預設位置儲存的所有資料，並變更機密資料的路徑，改用 CE 儲存空間。使用這個選項的裝置製造商應仔細檢查儲存的資料，確保資料不含個人資訊。

在此模式下執行時，您可以視需要使用下列系統 API，明確管理 CE 儲存空間支援的 Context，這些 API 等同於裝置保護的對應項目。

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

支援多位使用者

在多使用者環境中，每位使用者都會取得個別的加密金鑰。每位使用者都會取得兩把金鑰：DE 金鑰和 CE 金鑰。使用者 0 是特殊使用者，因此必須先登入裝置。這與裝置管理用途相關。

支援加密的應用程式會以這種方式與使用者互動： INTERACT_ACROSS_USERS和INTERACT_ACROSS_USERS_FULL 允許應用程式對裝置上的所有使用者執行各種動作。不過，這些應用程式只能存取已解鎖使用者的 CE 加密目錄。

應用程式可能可以在 DE 區域自由互動，但使用者解鎖裝置後，不代表裝置上的所有使用者都已解鎖。應用程式應先檢查這個狀態，再嘗試存取這些區域。

每個工作資料夾使用者 ID 也會取得兩組金鑰：DE 和 CE。工作挑戰完成後，設定檔使用者就會解鎖，KeyMint (在 TEE 中) 可以提供設定檔的 TEE 金鑰。

處理更新

復原磁碟分割區無法存取 userdata 磁碟分割區中受 DE 保護的儲存空間。強烈建議實作 FBE 的裝置使用 A/B 系統更新支援 OTA。由於 OTA 可以在正常運作期間套用，因此不需要復原即可存取加密磁碟機上的資料。

使用舊版 OTA 解決方案時，需要透過復原模式存取 userdata 分區中的 OTA 檔案：

1. 在 userdata 分區中建立頂層目錄 (例如 misc_ne)。
2. 將這個頂層目錄設為未加密 (請參閱「排除目錄」)。
3. 在頂層目錄中建立目錄，用來存放 OTA 套件。
4. 新增 SELinux 規則和檔案情境，控管這個目錄和內容的存取權。只有接收 OTA 更新的程序或應用程式，才能讀取及寫入這個目錄。其他應用程式或程序不得存取這個目錄。

驗證

為確保實作的功能版本運作正常，請先執行多項 CTS 加密測試，例如 DirectBootHostTest 和 EncryptionTest。

如果裝置搭載 Android 11 以上版本，請一併執行 vts_kernel_encryption_test：

atest vts_kernel_encryption_test

或：

vts-tradefed run vts -m vts_kernel_encryption_test

此外，裝置製造商可以執行下列手動測試。在啟用 FBE 的裝置上：

• 確認 ro.crypto.state 是否存在
  • 確認 ro.crypto.state 已加密
• 確認 ro.crypto.type 是否存在
  • 確認 ro.crypto.type 已設為 file

此外，測試人員可以驗證 CE 儲存空間是否已鎖定，裝置必須先解鎖，才能在開機後首次存取 CE 儲存空間。如要這麼做，請使用 userdebug 或 eng 版本，在主要使用者帳戶中設定 PIN 碼、解鎖圖案或密碼，然後重新啟動裝置。解鎖裝置前，請先執行下列指令，檢查主要使用者的 CE 儲存空間。如果裝置使用無頭系統使用者模式 (大多數車用裝置)，主要使用者為使用者 10，因此請執行：

adb root; adb shell ls /data/user/10

在其他裝置 (大多數非 Automotive 裝置) 上，主要使用者是使用者 0，因此請執行：

adb root; adb shell ls /data/user/0

確認列出的檔案名稱經過 Base64 編碼，表示檔案名稱已加密，且解密金鑰尚未提供。如果檔案名稱以明文列出，表示發生錯誤。

我們也鼓勵裝置製造商在裝置或核心上，探索執行 fscrypt 的上游 Linux 測試。這些測試是 xfstests 檔案系統測試套件的一部分。不過，Android 並未正式支援這些上游測試。

Android 開放原始碼計畫實作詳細資料

本節詳細說明 AOSP 實作方式，並說明檔案型加密的運作方式。裝置製造商應該不需要在此進行任何變更，即可在裝置上使用 FBE 和直接啟動。

fscrypt 加密

Android 開放原始碼計畫實作會在核心中使用「fscrypt」加密 (ext4 和 f2fs 支援此加密)，且通常會設定為：

• 使用 XTS 模式的 AES-256 加密檔案內容
• 以 CBC-CTS 模式使用 AES-256 加密檔案名稱

也支援 Adiantum 加密。啟用 Adiantum 加密後，檔案內容和檔案名稱都會以 Adiantum 加密。

fscrypt 支援兩種版本的加密政策：版本 1 和版本 2。 版本 1 已淘汰，搭載 Android 11 以上版本的裝置 CDD 需求僅與版本 2 相容。第 2 版加密政策會使用 HKDF-SHA512，從使用者空間提供的金鑰衍生實際加密金鑰。

如要進一步瞭解 fscrypt，請參閱上游核心說明文件。

儲存空間類別

下表詳細列出 FBE 金鑰及其保護的目錄：

金鑰儲存與保護

所有 FBE 金鑰都由 vold 管理，並以加密形式儲存在磁碟上，但每次開機時使用的金鑰不會儲存。下表列出各種 FBE 金鑰的儲存位置：

如上表所示，大多數 FBE 金鑰都儲存在由另一個 FBE 金鑰加密的目錄中。您必須先解鎖包含金鑰的儲存空間類別，才能解鎖金鑰。

vold 也會對所有 FBE 金鑰套用一層加密。除了內部儲存空間的 CE 金鑰外，所有金鑰都會使用自己的 Keystore 金鑰，以 AES-256-GCM 加密，且不會在 TEE 外部公開。這可確保除非已啟動受信任的作業系統 (由驗證開機程序強制執行)，否則無法解鎖 FBE 金鑰。此外，系統也會要求 Keystore 金鑰具備回溯防護功能，以便在 KeyMint 支援回溯防護的裝置上安全刪除 FBE 金鑰。如果無法提供回溯阻力，系統會盡力提供備援機制，也就是使用儲存在金鑰旁邊 secdiscardable 檔案中的 16384 個隨機位元組的 SHA-512 雜湊值，做為金鑰儲存區金鑰的 Tag::APPLICATION_ID。必須復原所有這些位元組，才能復原 FBE 金鑰。

內部儲存空間的 CE 金鑰受到更嚴密的保護，確保在不知道使用者螢幕鎖定知識因子 (LSKF) (PIN 碼、解鎖圖案或密碼)、安全密碼重設權杖，或重新啟動後繼續作業的用戶端和伺服器端金鑰的情況下，無法解鎖。密碼重設權杖只能為工作資料夾和完全受管理裝置建立。

為此，vold 會使用衍生自使用者合成密碼的 AES-256-GCM 金鑰，加密每個 CE 金鑰以供內部儲存。合成密碼是不可變動的高熵加密密碼，系統會為每位使用者隨機產生。LockSettingsService 中的 system_server 管理合成密碼和保護方式。

為使用 LSKF 保護合成密碼，LockSettingsService 會先將 LSKF 傳遞至 scrypt，藉此擴展 LSKF，目標時間約為 25 毫秒，記憶體用量約為 2 MiB。由於 LSKF 通常很短，這個步驟通常無法提供多少安全性。主要安全層是安全元件 (SE) 或 TEE 強制執行的速率限制，詳情請參閱下文。

如果裝置有安全元件 (SE)，LockSettingsService 會使用 Weaver HAL，將延展的 LSKF 對應至儲存在 SE 中的高熵隨機密碼。LockSettingsService 接著會將合成密碼加密兩次：第一次是使用衍生自延展 LSKF 和 Weaver 密碼的軟體金鑰，第二次是使用非驗證繫結的 Keystore 金鑰。這項功能可對 LSKF 猜測強制執行 SE 頻率限制。

如果裝置沒有 SE，LockSettingsService 則會改用延展的 LSKF 做為 Gatekeeper 密碼。LockSettingsService 接著會將合成密碼加密兩次：第一次使用衍生自擴展 LSKF 和 secdiscardable 檔案雜湊的軟體金鑰，第二次使用與 Gatekeeper 註冊程序進行驗證綁定的 Keystore 金鑰。這項功能可對 LSKF 猜測實施 TEE 強制執行的速率限制。

變更 LSKF 時，LockSettingsService 會刪除與舊 LSKF 繫結合成密碼相關的所有資訊。如果裝置支援 Weaver 或可抵禦復原作業的 Keystore 金鑰，這項功能可確保舊繫結安全無虞地遭到刪除。因此，即使使用者沒有 LSKF，系統仍會套用本文所述的保護措施。