基於文件的加密

Android 7.0 及更高版本支持基於文件的加密 (FBE)。基於文件的加密允許使用可以獨立解鎖的不同密鑰對不同的文件進行加密。

本文介紹如何在新設備上啟用基於文件的加密,以及系統應用程序如何使用 Direct Boot API 為用戶提供最佳、最安全的體驗。

直接啟動

基於文件的加密能夠在安卓7.0中引入了新的功能,稱為直接引導。直接啟動允許加密設備直接啟動到鎖定屏幕。此前,在使用加密設備全磁盤加密(FDE),所需要的任何數據之前提供憑據的用戶可以訪問,防止手機從執行所有,但最基本的操作。例如,警報無法操作,無障礙服務不可用,電話無法接聽電話,但僅限於基本的緊急撥號操作。

隨著基於文件的加密 (FBE) 和新 API 的引入使應用程序意識到加密,這些應用程序有可能在有限的上下文中運行。這可能發生在用戶提供憑據之前,同時仍然保護私人用戶信息。

在啟用 FBE 的設備上,設備的每個用戶都有兩個可供應用程序使用的存儲位置:

  • Credential Encrypted (CE) 存儲,這是默認存儲位置,僅在用戶解鎖設備後可用。
  • 設備加密 (DE) 存儲,這是在直接啟動模式期間和用戶解鎖設備後均可用的存儲位置。

這種分離使工作配置文件更安全,因為它允許一次保護多個用戶,因為加密不再僅基於啟動時密碼。

Direct Boot API 允許加密感知應用程序訪問這些區域中的每一個。有更改應用程序生命週期,以適應需求,當用戶的CE存儲響應第一輸入憑據在鎖屏解鎖,或工作資料中提供的情況下,通知應用程序的工作挑戰。運行 Android 7.0 的設備必須支持這些新的 API 和生命週期,無論它們是否實現 FBE。儘管沒有 FBE,DE 和 CE 存儲將始終處於解鎖狀態。

Android 開源項目 (AOSP) 中提供了 Ext4 和 F2FS 文件系統上基於文件的加密的完整實現,只需在滿足要求的設備上啟用即可。選擇使用 FBE 的製造商可能希望探索基於所使用的片上系統 (SoC) 優化功能的方法。

AOSP 中的所有必要軟件包都已更新為可直接啟動。但是,如果設備製造商使用這些應用程序的定製版本,他們將希望至少確保有提供以下服務的直接啟動感知包:

  • 電話服務和撥號器
  • 鎖屏密碼輸入法

示例和來源

Android提供的參考實現的基於文件的加密,其中的vold(系統/ vold的)提供了一種用於在Android管理存儲設備和卷的功能。 FBE 的添加為vold 提供了幾個新命令,以支持多個用戶的CE 和DE 密鑰的密鑰管理。除了核心更改為使用基於文件的加密內核能力,許多系統封裝,包括鎖屏和SystemUI已被修改,以支持FBE和直接引導功能。這些包括:

  • AOSP 撥號程序(包/應用程序/撥號程序)
  • 台鐘(包/應用程序/DeskClock)
  • LatinIME(包/輸入方法/LatinIME)*
  • 設置應用程序(包/應用程序/設置)*
  • SystemUI(框架/基礎/包/SystemUI)*

使用該*系統應用defaultToDeviceProtectedStorage清單屬性

的應用程序及加密感知服務更多的例子可以通過運行命令來找到mangrep directBootAware在AOSP源代碼樹的框架或包目錄。

依賴關係

要安全地使用 FBE 的 AOSP 實現,設備需要滿足以下依賴項:

  • 內核支持的ext4加密或F2FS加密。
  • 鑰匙大師支持與HAL版本1.0或2.0。不支持 Keymaster 0.3,因為它不提供必要的功能或確保對加密密鑰的充分保護。
  • 鑰匙大師/密鑰庫和關守必須在被實現可信執行環境(TEE)以提供用於DE鍵保護,使得未授權的OS(定制操作系統閃蒸到設備)不能簡單地請求DE密鑰。
  • 需要綁定到鑰匙大師初始化信託開機驗證的硬件根,以確保設備加密憑據不被未經授權的操作系統訪問。

:存儲策略應用到文件夾及其所有子文件夾。製造商應將未加密的內容限制在 OTA 文件夾和保存系統解密密鑰的文件夾中。大多數內容應駐留在憑據加密存儲中,而不是設備加密存儲中。

執行

根據directBootAware:首先,應用程序,如鬧鐘,電話,輔助功能應作出的Android直接引導開發者文檔。

內核支持

對 Ext4 和 F2FS 加密的內核支持在 Android 通用內核 3.18 及更高版本中可用。要在 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]]到的fs_mgr_flagsfstab用於線路userdata 。此選項定義內部存儲的加密格式。它最多包含三個以冒號分隔的參數:

  • 所述contents_encryption_mode參數定義的加密算法用於加密文件的內容。它可以是aes-256-xtsadiantum 。由於Android的11,也可以留空指定默認的算法,該算法是aes-256-xts
  • filenames_encryption_mode參數定義加密算法來加密文件名。它可以是aes-256-ctsaes-256-heh ,或adiantum 。如果沒有指定,則默認為aes-256-cts如果contents_encryption_modeaes-256-xts ,或adiantum ,如果contents_encryption_modeadiantum
  • flags參數,在Android的11個新的,是分離的標誌列表+字符。支持以下標誌:
    • v1標誌選擇版本1加密策略;在v2標誌選擇版本2加密策略。版本2加密策略使用更安全,更靈活的密鑰導出函數。缺省值是V2,如果發起設備上的Android 11或更高(如通過ro.product.first_api_level ),或V1如果推出Android電子器件10或更低。
    • 所述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_optimizedemmc_optimized標誌。

如果你不使用內嵌的加密硬件對於大多數設備的建議設置為fileencryption=aes-256-xts 。如果您使用內嵌的加密硬件對於大多數設備的建議設置為fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (或等價fileencryption=::inlinecrypt_optimized )。上沒有任何形式的AES加速度的裝置,鐵線蕨可以通過設置用來代替AES fileencryption=adiantum

的裝置上與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和可採用的存儲可以一起使用。

指定fileencryption的fstab中選擇userdata也將自動同時啟用FBE和元數據加密上可採用存儲。然而,可以通過在設置屬性覆蓋上可採用的存儲的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_algorithmro.crypto.fde_sector_size選擇上可採用的存儲元數據加密格式。請參閱元數據加密文檔

與 Keymaster 集成

按鍵和內核鑰匙圈管理的產生是通過處理vold 。 FBE 的 AOSP 實現要求設備支持 Keymaster HAL 1.0 或更高版本。不支持早期版本的 Keymaster HAL。

在第一次啟動時,用戶 0 的密鑰會在啟動過程的早期生成和安裝。由當時on-post-fs的階段init完成,鑰匙之王必須準備好處理請求。上像素器件,這是通過具有腳本塊確保之前鑰匙大師開始處理/data被安裝。

加密策略

基於文件的加密在目錄級別應用加密策略。當設備的userdata首先被創建的分區,基本結構和政策所施加init腳本。這些腳本將觸發第一個用戶(用戶 0 的)CE 和 DE 密鑰的創建,並定義使用這些密鑰加密哪些目錄。當創建額外的用戶和配置文件時,會生成必要的額外密鑰並將其存儲在密鑰庫中;他們的憑證和設備存儲位置被創建,加密策略將這些密鑰鏈接到這些目錄。

在Android的11和更高的加密策略,不再硬編碼到一個集中的位置,而是由參數定義mkdir在init腳本命令。目錄與系統DE密鑰使用加密encryption=Require ,同時未加密的目錄(或目錄的子目錄,其與每個用戶的密鑰加密)使用encryption=None

在 Android 10 中,加密策略被硬編碼到以下位置:

/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 存儲。使用此選項的設備製造商應仔細檢查他們存儲的數據,以確保其中不包含個人信息。

在此模式下運行時,以下系統 API 可用於在需要時顯式管理由 CE 存儲支持的上下文,這相當於它們的設備保護對應項。

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

支持多用戶

多用戶環境中的每個用戶都會獲得一個單獨的加密密鑰。每個用戶都有兩個密鑰:一個 DE 和一個 CE 密鑰。用戶 0 是特殊用戶,必須先登錄設備。這是相關的設備管理應用。

以這種方式加密的應用程序交互跨用戶: INTERACT_ACROSS_USERSINTERACT_ACROSS_USERS_FULL允許應用程序在所有設備上的用戶行為。但是,這些應用程序將只能訪問已解鎖用戶的 CE 加密目錄。

一個應用程序可能能夠跨 DE 區域自由交互,但一個用戶解鎖並不意味著設備上的所有用戶都被解鎖。應用程序應在嘗試訪問這些區域之前檢查此狀態。

每個工作資料用戶 ID 也有兩個密鑰:DE 和 CE。當遇到工作挑戰時,配置文件用戶被解鎖並且 Keymaster(在 TEE 中)可以提供配置文件的 TEE 密鑰。

處理更新

恢復分區無法訪問用戶數據分區上受 DE 保護的存儲。實施FBE設備使用強烈建議支持OTA A / B系統更新。由於可以在正常操作期間應用 OTA,因此無需恢復訪問加密驅動器上的數據。

當使用傳統的OTA解決方案,其需要恢復到接入上的OTA文件userdata分區:

  1. 創建一個頂級目錄(例如misc_ne在) userdata分區。
  2. 這個頂級目錄添加到加密策略例外(見加密策略上文)。
  3. 在頂級目錄中創建一個目錄來保存 OTA 包。
  4. 添加 SELinux 規則和文件上下文以控制對該文件夾及其內容的訪問。只有接收 OTA 更新的進程或應用程序才能讀取和寫入此文件夾。任何其他應用程序或進程都不應訪問此文件夾。

驗證

為了確保按預期的功能的工作原理的實現版本,首先運行許多CTS加密測試,如DirectBootHostTestEncryptionTest

如果設備運行的是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

此外,測試人員可以引導userdebug在初級用戶鎖屏設置實例。然後adb外殼到裝置和使用su成為根。確保/data/data包含加密文件名;如果沒有,則有問題。

我們也鼓勵設備製造商探索運行上游Linux的試驗fscrypt在他們的設備或內核。這些測試是 xfstests 文件系統測試套件的一部分。但是,Android 並不正式支持這些上游測試。

AOSP 實施詳情

本部分提供了有關 AOSP 實施的詳細信息,並介紹了基於文件的加密的工作原理。設備製造商無需在此處進行任何更改即可在其設備上使用 FBE 和直接啟動。

fscrypt 加密

AOSP 實現在內核中使用“fscrypt”加密(由 ext4 和 f2fs 支持),通常配置為:

  • 在 XTS 模式下使用 AES-256 加密文件內容
  • 在 CBC-CTS 模式下使用 AES-256 加密文件名

鐵線蕨加密也支持。啟用 Adiantum 加密後,文件內容和文件名都使用 Adiantum 加密。

有關fscrypt的更多信息,請參閱上游內核文檔

密鑰推導

基於文件的加密密鑰是 512 位密鑰,由 TEE 中保存的另一個密鑰(256 位 AES-GCM 密鑰)加密存儲。要使用此 TEE 密鑰,必須滿足三個要求:

  • 身份驗證令牌
  • 拉伸的憑證
  • “secdiscardable hash”

auth令牌的加密的認證的令牌通過產生關守,當用戶英寸的TEE將拒絕使用該密鑰,除非正確的身份驗證令牌被提供成功登錄。如果用戶沒有憑據,則不使用也不需要任何身份驗證令牌。

拉伸憑證鹽析,並與拉伸後的用戶憑據scrypt算法。憑證被傳遞給之前的鎖定設置服務實際上散列一次vold傳遞到scrypt 。這是加密綁定到所有適用於該擔保TEE關鍵KM_TAG_APPLICATION_ID 。如果用戶沒有憑據,則不會使用也不需要擴展憑據。

所述secdiscardable hash是一起存儲用於重構的關鍵,如種子的其他信息的隨機16 KB文件的512位散列。刪除密鑰時,該文件被安全刪除,或者以新的方式加密;這種額外的保護確保攻擊者必須恢復這個安全刪除的文件的每一位來恢復密鑰。這是加密綁定到所有適用於該擔保TEE關鍵KM_TAG_APPLICATION_ID

在大多數情況下,FBE 密鑰還會在內核中進行額外的密鑰派生步驟,以生成實際用於加密的子密鑰,例如每個文件或每個模式的密鑰。對於版本 2 加密策略,為此使用 HKDF-SHA512。