檔案型加密

Android 7.0 以上版本支援檔案型加密 (FBE)。檔案式加密功能可讓您使用不同的金鑰加密不同的檔案，並且可個別解鎖。

本文將說明如何在新裝置上啟用檔案式加密功能，以及系統應用程式如何使用 Direct Boot API，為使用者提供最佳、最安全的體驗。

所有搭載 Android 10 以上版本的裝置都必須使用檔案型加密機制。

直接啟動

檔案型加密可啟用 Android 7.0 中推出的全新功能「直接啟動」。直接啟動可讓已加密的裝置直接啟動至鎖定畫面。先前，在使用全磁碟加密 (FDE) 的加密裝置上，使用者必須先提供憑證，才能存取任何資料，這會導致手機無法執行所有操作，只剩下最基本的操作。舉例來說，鬧鐘無法運作、無法使用無障礙服務，且手機無法接聽電話，只能進行基本緊急撥號操作。

隨著檔案型加密 (FBE) 和新 API 的推出，應用程式可辨識加密功能，因此這些應用程式可以在受限的環境中運作。這可能發生在使用者提供憑證之前，同時保護私人使用者資訊。

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

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

這項分隔功能可讓工作資料夾更安全，因為加密作業不再只依據啟動時間密碼，因此可同時保護多位使用者。

直接啟動 API 可讓加密感知應用程式存取這些區域。應用程式生命週期有所變更，以便在使用者首次在鎖定畫面輸入憑證時，或在工作資料夾提供工作挑戰時，通知應用程式解鎖使用者的 CE 儲存空間。無論是否實作 FBE，搭載 Android 7.0 的裝置都必須支援這些新的 API 和生命週期。不過，如果沒有 FBE，DE 和 CE 儲存空間一律會處於解鎖狀態。

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

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

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

範例和來源

Android 提供檔案型加密機制的參考實作項目，其中 vold (system/vold) 提供管理 Android 上的儲存裝置和磁碟區的功能。加入 FBE 後，vold 可使用多個新指令，支援多位使用者的 CE 和 DE 金鑰管理。除了使用核心中的檔案加密功能的核心變更之外，許多系統套件 (包括鎖定畫面和 SystemUI) 也已修改為支援 FBE 和直接啟動功能。其中包括：

  • AOSP 撥號程式 (packages/apps/Dialer)
  • 桌面時鐘 (套件/應用程式/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • 「設定」應用程式 (packages/apps/Settings)*
  • SystemUI (frameworks/base/packages/SystemUI)*

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

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

依附元件

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

  • 核心支援：Ext4 或 F2FS 加密。
  • Keymaster 支援 HAL 1.0 以上版本。我們不支援 Keymaster 0.3，因為該版本不提供必要功能，也無法確保加密金鑰獲得充分保護。
  • Keymaster/Keystore 和 Gatekeeper 必須在受信任的執行環境 (TEE) 中實作，才能保護 DE 金鑰，避免未經授權的作業系統 (在裝置上刷新的自訂作業系統) 輕易要求 DE 金鑰。
  • 您必須使用 Hardware Root of Trust 和 Verified Boot 綁定至 Keymaster 初始化，才能確保未經授權的作業系統無法存取 DE 金鑰。

實作

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

核心支援

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

CONFIG_FS_ENCRYPTION=y

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

如果裝置支援可採用儲存空間，或在內部儲存空間使用中繼資料加密功能，請按照中繼資料加密功能說明文件所述，啟用中繼資料加密功能所需的核心設定選項。

除了支援 Ext4 或 F2FS 加密功能外，裝置製造商也應啟用密碼編譯加速功能，以加快檔案式加密速度並改善使用者體驗。舉例來說，在 ARM64 裝置上，您可以設定下列核心設定選項，啟用 ARMv8 CE (加密擴充功能) 加速功能：

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，請將 fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] 選項新增至 userdata 的 fstab 列的 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。
  • flags 參數是 Android 11 的新功能，是一系列以 + 字元分隔的標記。支援下列標記：
    • 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 第 5.2 版規格的內嵌加密硬體，因此只支援 32 位元 IV。在其他內嵌加密硬體上，請改用 inlinecrypt_optimized。這個標記絕不應用於 UFS 型儲存空間；UFS 規格允許使用 64 位元 IV。
    • 在支援硬體包裝金鑰的裝置上，wrappedkey_v0 標記可讓您使用硬體包裝金鑰來執行 FBE。這個旗標只能與 inlinecrypt 掛載選項，以及 inlinecrypt_optimized 或 emmc_optimized 旗標搭配使用。
    • 即使檔案系統區塊大小不是 4096 位元組，dusize_4k 標記也會強制加密資料單位大小為 4096 位元組。加密資料單位大小是檔案內容加密的精細程度。這個旗標自 Android 15 起可供使用。這個標記應僅用於在使用 f2fs 檔案系統的裝置上，啟用不支援超過 4096 位元組的資料單位的內嵌加密硬體。此裝置必須使用超過 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 會選取可採用儲存空間的中繼資料加密格式。請參閱結構描述加密說明文件。

與 Keymaster 整合

應在 early_hal 類別中啟動 Keymaster HAL。這是因為 FBE 要求 Keymaster 在 post-fs-data 啟動階段 (vold 設定初始金鑰時) 準備好處理要求。

排除目錄

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

在 Android 11 以上版本中，init 套用至目錄的鍵可透過初始化指令碼中 mkdir 指令的 encryption=<action> 引數控制。<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，這與裝置保護模式的對應項目相同。

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

支援多位使用者

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

加密貨幣感知應用程式會以以下方式與使用者互動：INTERACT_ACROSS_USERS 和 INTERACT_ACROSS_USERS_FULL 可讓應用程式對裝置上的所有使用者採取動作。不過，這些應用程式只能存取已解鎖使用者的 CE 加密目錄。

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

每個工作資料夾使用者 ID 也會取得兩個金鑰：DE 和 CE。在符合工作挑戰條件後，系統會解鎖設定檔使用者，而 Keymaster (在 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 儲存空間是否已鎖定。如要這麼做，請使用 userdebug 或 eng 版本，為主要使用者設定 PIN 碼、解鎖圖案或密碼，然後重新啟動裝置。在解鎖裝置前，請執行下列指令，檢查主要使用者的 CE 儲存空間。如果裝置使用無頭系統使用者模式 (大多數車用裝置)，主要使用者為使用者 10，因此請執行：

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

在其他裝置 (大多數非汽車裝置) 上，主要使用者為使用者 0，因此請執行以下命令：

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

請確認列出的檔案名稱已以 Base64 編碼，表示檔案名稱已加密，且尚未提供解密金鑰。如果檔案名稱以明文列出，表示有問題。

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

AOSP 實作詳細資料

本節將詳細說明 AOSP 實作方式，並說明檔案為基礎的加密機制運作方式。裝置製造商不必在此處進行任何變更，即可在裝置上使用 FBE 和 Direct Boot。

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 金鑰和這些金鑰保護的目錄：

儲存空間級別 說明 目錄
未加密 /data 中無法或不需要受 FBE 保護的目錄。在使用中繼資料加密功能的裝置上，這些目錄並非完全未加密，而是受到中繼資料加密金鑰保護，這類金鑰等同於系統 DE。
  • /data/apex (不含 /data/apex/decompressed 和 /data/apex/ota_reserved，這是系統 DE)
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • 所有子目錄使用不同 FBE 金鑰的目錄。舉例來說，由於每個 /data/user/${user_id} 目錄都使用個別使用者金鑰，因此 /data/user 本身不會使用任何金鑰。
系統 DE 裝置加密資料未與特定使用者連結
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • 這份表格未提及的 /data 其他所有子目錄，皆屬於不同的類別
每次啟動 不需要在重新啟動後保留的臨時系統檔案 /data/per_boot
使用者 CE (內部) 內部儲存空間中的個別使用者憑證加密資料
  • /data/data (/data/user/0 的別名)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
使用者 DE (內部) 內部儲存空間中的個別使用者裝置加密資料
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
使用者 CE (可採用) 可採用儲存空間中的每位使用者憑證加密資料
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
使用者 DE (可採用) 可採用儲存空間中的個別使用者裝置加密資料
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

金鑰儲存和防護

所有 FBE 金鑰都由 vold 管理，並以加密方式儲存在磁碟上，但每個啟動金鑰都不會儲存。下表列出各種 FBE 金鑰的儲存位置：

金鑰類型 金鑰位置 鍵位置的儲存空間級別
系統 DE 鍵 /data/unencrypted 未加密
使用者 CE (內部) 金鑰 /data/misc/vold/user_keys/ce/${user_id} 系統 DE
使用者 DE (內部) 金鑰 /data/misc/vold/user_keys/de/${user_id} 系統 DE
使用者 CE (可採用) 金鑰 /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} 使用者 CE (內部)
使用者 DE (可採用) 鍵 /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} 使用者 DE (內部)

如上表所示，大部分的 FBE 金鑰都儲存在由其他 FBE 金鑰加密的資料夾中。只有在包含金鑰的儲存類別解除鎖定後，才能解除金鑰的鎖定狀態。

vold 也會為所有 FBE 金鑰套用一層加密機制。除了內部儲存空間的 CE 金鑰之外，所有金鑰都會使用 AES-256-GCM 加密，並使用其專屬的 Keystore 金鑰進行加密，該金鑰不會在 TEE 外部公開。這可確保在 驗證開機強制執行的情況下，除非已啟動可信任的作業系統，否則無法解鎖 FBE 金鑰。您也可以要求 Keystore 金鑰具備回溯防護功能，這樣一來，在 Keymaster 支援回溯防護功能的裝置上，就能安全地刪除 FBE 金鑰。當無法使用回溯防護功能時，系統會盡力採用備用方案，將 secdiscardable 檔案中儲存的 16384 個隨機位元組的 SHA-512 雜湊值，用作 Keystore 金鑰的 Tag::APPLICATION_ID。您必須復原所有這些位元組，才能復原 FBE 金鑰。

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

為達成這項目標，vold 會使用 AES-256-GCM 金鑰 (由使用者的合成密碼衍生而來) 為內部儲存空間的每個 CE 金鑰加密。合成密碼是針對每位使用者隨機產生的不可變更高熵加密祕密。system_server 中的 LockSettingsService 會管理合成密碼及其保護方式。

為了使用 LSKF 保護合成密碼，LockSettingsService 會先將 LSKF 經由 scrypt 延長，目標時間約為 25 毫秒，記憶體用量約為 2 MiB。由於 LSKF 通常很短，因此這個步驟通常不會提供太多安全性。主要安全層是安全元素 (SE) 或下文所述的 TEE 強制執行的速率限制。

如果裝置有安全元素 (SE)，LockSettingsService 會使用 Weaver HAL，將經過拉伸的 LSKF 對應至儲存在 SE 中的高熵隨機密鑰。LockSettingsService 接著會對合成密碼加密兩次：第一次使用從拉長的 LSKF 和 Weaver 密鑰衍生的軟體金鑰，第二次使用未綁定驗證的 KeyStore 金鑰。這可為 LSKF 猜測提供 SE 強制執行的頻率限制。

如果裝置沒有 SE，LockSettingsService 會改為使用經過拉伸的 LSKF 做為 Gatekeeper 密碼。LockSettingsService 接著會對合成密碼加密兩次：首先使用從拉長的 LSKF 和可安全捨棄檔案的雜湊值衍生的軟體金鑰，然後使用與 Gatekeeper 註冊程序相關聯的 KeyStore 金鑰。這可為 LSKF 猜測提供 TEE 強制執行的頻率限制。

當 LSKF 變更時，LockSettingsService 會刪除與合成密碼繫結至舊 LSKF 的所有相關資訊。在支援 Weaver 或可防回溯的 Keystore 金鑰的裝置上，這可確保舊版繫結安全刪除。因此，即使使用者沒有 LSKF，也會套用這裡所述的防護措施。