檔案型加密

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 新增作業提供多種新指令，以便支援多位使用者 CE 和 DE 金鑰的金鑰管理。除了使用核心中的檔案加密功能的核心變更之外，許多系統套件 (包括鎖定畫面和 SystemUI) 也已修改為支援 FBE 和直接啟動功能。其中包括：

  • Android 開放原始碼計畫撥號程式 (套件/應用程式/撥號程式)
  • 桌面時鐘 (套件/應用程式/DeskClock)
  • LatinIME (套件/輸入法/LatinIME)*
  • 「設定」應用程式 (packages/apps/Settings)*
  • SystemUI (frameworks/base/packages/SystemUI)*

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

您可以在 Android 開放原始碼計畫來源樹狀結構的架構或套件目錄中執行 mangrep directBootAware 指令，取得更多具備加密感知功能的應用程式和服務。

依附元件

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

  • 核心支援：執行 Ext4 加密或 F2FS 加密。
  • 支援 HAL 1.0 以上版本的Keymaster 支援。不支援 Keymaster 0.3，因為這無法提供必要的功能，也無法保證加密金鑰的防護充足。
  • Keymaster/Keystore 和 Gatekeeper 必須在受信任的執行環境 (TEE) 中實作，以便為 DE 金鑰提供保護，讓未經授權的 OS (將自訂 OS 刷新至裝置上) 無法直接要求 DE 金鑰。
  • 需要與 Keymaster 初始化繫結的硬體信任根和驗證開機程序，確保未經授權的作業系統無法存取 DE 金鑰。

實作

首先，最重要的是，鬧鐘、手機和無障礙功能等應用程式應根據直接啟動開發人員說明文件 (直接啟動) 製作 android:directBootAware。

核心支援

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

CONFIG_FS_ENCRYPTION=y

如果是舊版核心，如果裝置的 userdata 檔案系統為 Ext4，請使用 CONFIG_EXT4_ENCRYPTION=y；如果裝置的 userdata 檔案系統為 F2FS，請使用 CONFIG_F2FS_FS_ENCRYPTION=y。

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

除了支援 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，但您可以視需要覆寫可用儲存空間的加密格式。

內部儲存空間

如要啟用 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 限制於 32 位元的 IV 產生方法。這個標記僅適用於符合 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 以上版本。這個標記只能用於啟用不支援資料單位的內嵌加密硬體，這類硬體不支援大於 4, 096 個位元組的資料單位，該裝置頁面大小大於 4096 位元組，且該設備採用 f2fs 檔案系統。

如果您未使用內嵌加密硬體，建議大多數裝置的設定為 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 整合

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

排除目錄

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

在 Android 11 以上版本中，init 套用至目錄的鍵可透過初始化指令碼中 mkdir 指令的 encryption=<action> 引數控制。如需 <action> 的可能值，請參閱 Android init 語言的 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 與 Device Protected 對應項目相同。

  • 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 實作詳細資料

本節將詳細說明 Android 開放原始碼計畫實作方式，並說明檔案型加密的運作方式。裝置製造商不必在此處進行任何變更，即可在裝置上使用 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 本身並不使用金鑰。
System 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} System 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 金鑰的 應用程式 ID 標記。您必須復原所有這些位元組，才能復原 FBE 金鑰。

內部儲存空間的 CE 金鑰會獲得更高層級的保護，確保在瞭解使用者的螢幕鎖定知識因素 (LSKF) (PIN 碼、模式或密碼)、安全密碼重設權杖或用戶端與伺服器端金鑰進行重新啟動作業時，無法解鎖金鑰。您只能為工作資料夾和全代管裝置建立密碼重設權杖。

為此，vold 會使用從使用者合成密碼衍生的 AES-256-GCM 金鑰，加密每個用於內部儲存空間的 CE 金鑰。合成密碼是針對每位使用者隨機產生的不可變更高熵加密金鑰。system_server 中的 LockSettingsService 會管理合成密碼及其保護方式。

為透過 LSKF 保護合成密碼，LockSettingsService 會先透過 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 和可安全檔案雜湊的雜湊，第二是使用已綁定至 Gatekeeper 註冊金鑰的 KeyStore 金鑰。這可為 LSKF 猜測提供 TEE 強制執行的頻率限制。

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