檔案型加密

Android 7.0 以上版本支援檔案型加密 (FBE)。 檔案型加密功能可加密不同檔案 方便個別解鎖不同按鍵

本文說明如何在新裝置上啟用檔案型加密 以及系統應用程式如何運用 Direct Boot API 為使用者提供服務 最安全的使用環境

搭載 Android 10 以上版本的所有裝置： 必須採用以檔案為基礎的加密機制。

直接啟動

檔案型加密提供 Android 7.0 中推出的新功能，名為「Direct (直接) 啟動。直接啟動功能可讓加密裝置直接啟動鎖定狀態 。先前在加密裝置上，必須使用 full-disk 加密 (FDE)，使用者必須先提供憑證才能取得資料 防止手機執行所有基本工作，而不執行所有基本操作 作業。舉例來說，可能無法使用鬧鐘、無障礙服務 且手機無法接聽來電，但僅限基本型 緊急撥號程式作業

導入檔案型加密 (FBE) 和新的 API 後 如果應用程式知道加密功能，這些應用程式可能在 並在少部分情況下派上用場這種情況可能會在使用者提供 憑證，同時仍保護使用者私人資訊

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

  • 憑證加密 (CE) 儲存空間 (預設的儲存位置) 而且只有在使用者解鎖裝置後才能使用。
  • 裝置加密 (DE) 儲存空間，為兩者的儲存位置 進入直接啟動模式，以及使用者解鎖裝置後。
，瞭解如何調查及移除這項存取權。

這種區隔功能允許多個工作資料夾，因此安全性更高 每個使用者皆須受到保護，因為加密不再僅根據 啟動時間密碼。

Direct Boot API 可讓加密感知應用程式存取每個 在這些區塊建構 AI 應用項目時 必須特別小心應用程式生命週期經過變更，這是為了滿足 當使用者的 CE 儲存空間解鎖以回應 請先在鎖定畫面或工作資料夾的情況下輸入憑證 提供 公司 挑戰。搭載 Android 7.0 的裝置必須支援這些新的 API 和 生命週期內的高度。不過 FBE、DE 和 CE 儲存空間一律會處於解鎖狀態。

完整實作 Ext4 和 F2FS 檔案型的檔案加密機制 Android 開放原始碼計畫 (AOSP) 提供了系統， 並在符合規範的裝置上啟用選擇使用 FBE 的製造商 您可能會想探索如何針對晶片系統最佳化這項功能 (SoC)。

Android 開放原始碼計畫中的所有必要套件已更新，現在具備直接啟動感知特性。 但如果裝置製造商使用這類應用程式的自訂版本， 必須確保至少具有直接啟動感知套件 下列服務：

  • 電話服務與撥號
  • 用於在螢幕鎖定畫面中輸入密碼的輸入法

範例和來源

Android 提供檔案型加密的參考實作， 伏特 (system/vold) 提供了管理儲存空間裝置的功能 包括磁碟區新增 FBE 後，新增了幾個新的指令 支援多個使用者的 CE 和 DE 金鑰管理金鑰此外， 對核心異動採用以檔案為基礎的 核心的加密功能，許多系統套件包括 並修改了 SystemUI，以便支援 FBE 和 Direct 啟動功能。其中包括：

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

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

如需更多具備加密感知能力的應用程式和服務，請前往 執行 mangrep directBootAware 指令即可 AOSP 的架構或套件目錄 來源樹狀結構。

依附元件

如要安全地使用 Android 開放原始碼計畫實作 FBE，裝置必須符合 下列依附元件：

  • 核心支援：執行 Ext4 加密或 F2FS 加密。
  • Keymaster 支援 HAL 1.0 以上版本。我們不支援 Keymaster 0.3 無法提供必要的功能或保證 因此能充分保護加密金鑰
  • Keymaster/Keystore 和 把關者必須在受信任的執行中實作 環境 (TEE)，為 DE 金鑰提供保護， 授權的作業系統 (自訂 OS 刷新至裝置上) 不得 DE 金鑰。
  • 硬體信任根和驗證開機程序 必須繫結至 Keymaster 初始化，確保 DE 金鑰不會 遭到未經授權的作業系統存取。

實作

首先最重要的是，如鬧鐘、手機和無障礙功能等應用程式 應根據 Direct 啟動開發人員說明文件。

核心支援

Android 提供 Ext4 和 F2FS 加密的核心支援 核心 3.18 以上版本。如何在 5.1 版的核心中啟用這個模式 或更高版本，請使用： 

CONFIG_FS_ENCRYPTION=y

如果是較舊的核心，請使用 CONFIG_EXT4_ENCRYPTION=y userdata 檔案系統為 Ext4，或 如果裝置的「userdata」型號，則CONFIG_F2FS_FS_ENCRYPTION=y 也就是 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，才能在裝置上啟用 FBE (userdata)。這麼做也會自動將 FBE 啟用採用 儲存空間；但合併式儲存裝置的加密格式可能會遭到覆寫 並視需要顯示。

內部儲存空間

新增選項即可啟用 FBE fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] 新增到 fstab 行的 fs_mgr_flags 欄，以取得： userdata。這個選項會定義內部的加密格式 如果 30 天內讀取資料不到一次 建議使用 Coldline Storage最多可包含三個以半形冒號分隔的參數：

  • 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-cts aes-256-xts，或是 adiantum (如果 contents_encryption_mode為 adiantum。
  • flags 參數 (Android 新功能) 11) 是一組旗標清單，以 + 個半形字元。系統支援下列標記：
    • v1 旗標會選取版本 1 的加密政策。這個 v2 旗標會選取版本 2 的加密政策。版本 2 項加密政策會使用更安全靈活的金鑰衍生函式。預設值為 v2。 裝置搭載 Android 11 以上版本 (由 ro.product.first_api_level 決定) 或 v1 (如有) 裝置搭載 Android 10 或 較低
    • inlinecrypt_optimized 旗標會選取加密機制 這種格式，為非使用情境的內嵌加密硬體進行最佳化 有效率地處理大量金鑰做法是 每個 CE 或 DE 金鑰只有一個檔案內容加密金鑰 每個檔案一個 ID因 IV (初始化向量) 而產生 做出相應調整
    • emmc_optimized 標記類似於 inlinecrypt_optimized，但同時選取 IV 將 IV 限制在 32 位元以內。這個標記 用於符合 JEDEC eMMC v5.2 規格，因此僅支援 32 位元 IV。如果是其他內嵌加密硬體，請使用 請改為使用「inlinecrypt_optimized」。這個旗標不應 在 UFS 式儲存空間上使用UFS 規格允許 。
    • 使用支援硬體包裝的裝置 鍵，wrappedkey_v0 旗標可讓您使用 適用於 FBE 的硬體包裝金鑰只能搭配 呼叫 inlinecrypt 掛接選項，然後 inlinecrypt_optimized 或 emmc_optimized 旗標。
    • dusize_4k 旗標會強制加密資料單位大小 大小為 4096 個位元組，即使檔案系統區塊大小不是 4096 一個位元組加密資料單位大小是指檔案精細程度 也就是內容加密這個旗標自 Android 起可以使用 15.這個旗標只能用於啟用 使用的內嵌加密硬體不支援資料 單位大於 4096 位元組 (在包含頁面大小的裝置上) ，且使用 f2fs 檔案系統。

如果您未使用內嵌加密硬體，那麼我們建議大多數的 裝置為fileencryption=aes-256-xts。如果您使用內嵌方式 對大多數裝置而言 fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (或相當於 fileencryption=::inlinecrypt_optimized)。啟用 如果不是任何形式 AES 加速功能的裝置，那麼可在以下情況使用 Adiantum 而非 AES： 正在設定 fileencryption=adiantum。

自 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 的裝置 11 以上版本，便無法使用這個模式，且 請改用標準加密格式。

根據預設，系統會使用 Linux kernel 的 以及 Google Cloud 中經過加密編譯的若要改用內嵌加密硬體 新增 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 和 共用儲存空間可以搭配使用。

為以下項目指定 fileencryption fstab 選項： userdata 也會自動在採用時啟用 FBE 和中繼資料加密 如果 30 天內讀取資料不到一次 建議使用 Coldline Storage不過，您可以覆寫 FBE 和/或中繼資料加密格式， 方法是在 PRODUCT_PROPERTY_OVERRIDES。

如果你使用搭載 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> 引數 加入 init 指令碼中的某個指令<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 儲存空間。裝置 採用這個選項的製造者應仔細檢查 以確保當中不含任何個人資訊。

在這個模式下執行時，下列 System API 並可視需要明確管理 CE 儲存空間支援的結構定義 相當於裝置受保護的裝置。

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

支援多位使用者

多使用者環境中的每位使用者都會取得個別的加密金鑰。每位使用者 會有兩組金鑰：DE 與 CE 金鑰使用者 0 必須先以原樣登入裝置 特殊使用者這適用於 Device 管理用途。

加密編譯應用程式會以下列方式與使用者互動： 「INTERACT_ACROSS_USERS」和「INTERACT_ACROSS_USERS_FULL」 允許應用程式對裝置上的所有使用者執行動作。不過 應用程式只能存取 CE 加密目錄： 表示已解鎖

應用程式可以跨越 DE 區域自由互動，但只有一位使用者 未解鎖時，表示裝置上的所有使用者都已解鎖。 應用程式應該先檢查這個狀態，然後再嘗試存取這些區域。

每個工作資料夾使用者 ID 也會取得兩個金鑰：DE 和 CE。工作挑戰時 一旦達到設定檔，設定檔使用者就會解鎖，Keymaster (在 TEE 中) 則可提供 設定檔的 TEE 金鑰。

處理更新

復原分區無法存取 使用者資料分區。強烈建議導入 FBE 的裝置支援 使用 A/B 系統更新的 OTA。阿斯 您在一般作業期間可套用 OTA，不需要復原至 存取加密硬碟中的資料

使用舊版 OTA 解決方案時，需要復原程序才能存取 OTA 檔案 userdata 分區：

  1. 在以下位置建立頂層目錄 (例如 misc_ne)： userdata 個分區。
  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 編碼， 檔案名稱已加密，且目前無法使用解密金鑰。 如果檔案名稱以明文列出，表示發生錯誤。

我們也建議裝置製造商嘗試在裝置上或執行上游 Linux 加密編譯測試，或 核心。這些測試屬於 xfstests 檔案系統測試套件的一部分。不過 這些上游測試不受 Android 強制支援

Android 開放原始碼計畫實作詳情

本節將詳細說明 Android 開放原始碼計畫實作方式，並 檔案型加密因此裝置製造商不須進行這項設定 並在此處進行任何調整，以便在裝置上使用 FBE 和直接啟動功能。

fscrypt 加密

Android 開放原始碼計畫實作項目會使用「fscrypt」加密 (由 ext4 和 f2fs 支援) 並通常會設為：

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

Adiantum 加密 。啟用 Adiantum 加密時，檔案內容和檔案名稱皆 都會透過 Adiantum 加密

fscrypt 支援兩種版本的加密政策：第 1 版和第 2 版。 第 1 版已淘汰，若裝置的 CDD 要求， Android 11 以上版本只與版本相容 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 金鑰，讓 FBE 金鑰可以 會安全地從 Keymaster 支援的復原機制裝置上刪除。阿斯 為了恢復無法使用時的復原能力，SHA-512 就會 儲存在 secdiscardable 檔案中 16384 隨機位元組的雜湊 會用來做為應用程式編號 KeyStore 金鑰的標記。所有這些位元組都需要復原，才能復原 FBE 金鑰。

內部儲存空間的 CE 金鑰可獲得更強大的保護 使用者無法自行解鎖裝置，得知使用者的螢幕鎖定畫面 知識因素 (LSKF) (PIN 碼、解鎖圖案或密碼)、安全 密碼重設權杖，或是用戶端和伺服器端金鑰 在重新啟動時繼續執行作業。 您只能為工作資料夾和 完整 受管理的裝置。

為此，vold 會加密每個 CE 金鑰，以便用於內部儲存空間 使用衍生自使用者綜合密碼的 AES-256-GCM 金鑰。 合成密碼是不可變的高熵加密編譯密鑰， 隨機產生一個 IDLockSettingsService 英吋 system_server 會管理合成密碼及 都會受到保護

為了透過 LSKF 保護合成密碼， LockSettingsService 會先穿過 LSKF，透過其經過的方式伸展 scrypt，指定時間大約為 25 毫秒 大約有 2 MiB 的記憶體用量LSKF 通常很短，因此這個步驟通常 無法提供太多安全性防護。安全第一層是 元素 (SE) 或下文所述的 TEE 強制執行頻率限制。

如果裝置含有安全元件 (SE)，則LockSettingsService 使用 Weaver HAL。LockSettingsService之後會加密 產生兩次的綜合密碼：首先是軟體金鑰衍生自 拉長的 LSKF 和 Weaver 密鑰，第二部分使用未驗證的 KeyStore 鍵。以便針對 LSKF 猜測提供 SE 強制執行的頻率限制。

如果裝置沒有 SE，請改為使用 LockSettingsService 延展的 LSKF 擔任總機人員 密碼。接著，LockSettingsService 會加密合成密碼 兩次：首先，軟體金鑰衍生自延伸的 LSKF 和 安全檔案，以及第二個使用受驗證的 KeyStore 金鑰。 總機人員註冊。這可以提供 TEE 強制執行的 LSKF 猜測頻率限制。

LSKF 變更時，LockSettingsService 會全部刪除 與合成密碼繫結相關資訊 LSKF。在支援 Weaver 或復原防復原 KeyStore 金鑰的裝置上， 可安全刪除舊繫結。因此，保護措施 就算使用者沒有 LSKF，也是如此。