Google致力於提高黑人社區的種族平等。 怎麼看。
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

基於文件的加密

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

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

直接啟動

基於文件的加密可啟用Android 7.0中引入的一項名為Direct Boot的新功能。直接啟動允許加密的設備直接啟動到鎖定屏幕。以前,在使用全盤加密 (FDE)的加密設備 ,用戶需要提供憑據才能訪問任何數據,從而阻止電話執行除最基本的操作以外的所有操作。例如,警報無法運行,無障礙服務不可用,電話無法接聽電話,但僅限於基本的緊急撥號器操作。

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

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

  • 憑據加密(CE)存儲,這是默認存儲位置,僅在用戶解鎖設備後可用。
  • 設備加密(DE)存儲,這是在直接啟動模式下以及用戶解鎖設備後都可用的存儲位置。

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

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

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

AOSP中所有必需的軟件包已更新為可直接引導。但是,在設備製造商使用這些應用程序的自定義版本的情況下,他們將希望確保至少存在能夠提供以下服務的直接啟動感知程序包:

  • 電話服務和撥號器
  • 在鎖定屏幕中輸入密碼的輸入方法

實例和來源

Android提供了基於文件的加密的參考實現,其中vold( system / vold )提供了用於在Android上管理存儲設備和卷的功能。 FBE的添加為vold提供了幾個新命令,以支持對多個用戶的CE和DE密鑰進行密​​鑰管理。除了在內核中使用基於文件的加密功能的核心更改之外,還對許多系統軟件包(包括鎖屏和SystemUI)進行了修改,以支持FBE和Direct Boot功能。這些包括:

  • AOSP撥號程序(程序包/應用程序/撥號程序)
  • 桌面時鐘(包/應用/桌面時鐘)
  • LatinIME(軟件包/輸入法/ LatinIME)*
  • 設置應用(軟件包/應用/設置)*
  • SystemUI(框架/基礎/軟件包/ SystemUI)*

*使用defaultToDeviceProtectedStorage清單屬性的系統應用程序

通過在AOSP源樹的frameworks或packages目錄中運行命令mangrep directBootAware ,可以找到更多具有加密意識的應用程序和服務的示例。

依存關係

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

  • 對Ext4加密或F2FS加密的內核支持
  • HAL 1.0或2.0版本的Keymaster支持 。不支持Keymaster 0.3,因為它不提供必要的功能或不能確保對加密密鑰的足夠保護。
  • 必須在受信任的執行環境 (TEE)中實現Keymaster / Keystore和Gatekeeper,以提供對DE密鑰的保護,以便未經授權的OS(自定義OS閃存到設備上)不能簡單地請求DE密鑰。
  • 需要綁定到密鑰主初始化的硬件信任根和經過驗證的引導 ,以確保未經授權的操作系統無法訪問設備加密憑據。

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

實作

首先,應根據Direct Boot開發人員文檔將諸如鬧鐘,電話,可訪問性功能之類的應用程序設置為android:directBootAware。

內核支持

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。但是,必要時可以覆蓋可採用存儲上的加密格式。

內部存儲器

通過將選項fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]userdatafstab行的fs_mgr_flags列中來啟用FBE。此選項定義內部存儲器上的加密格式。它最多包含三個冒號分隔的參數:

  • contents_encryption_mode參數定義使用哪種加密算法來加密文件內容。它可以是aes-256-xtsadiantum
  • filenames_encryption_mode參數定義使用哪種加密算法來加密文件名。它可以是aes-256-ctsaes-256-hehadiantum 。如果沒有指定,則默認為aes-256-cts如果contents_encryption_modeaes-256-xts ,或adiantum ,如果contents_encryption_modeadiantum
  • Android R中新增的flags參數是由+字符分隔的標誌列表。支持以下標誌:
    • v1標誌選擇版本1加密策略; v2標誌選擇版本2加密策略。版本2加密策略使用更安全,更靈活的密鑰派生功能 。如果設備在Android R或更高版本(由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密鑰不是由軟件生成的,而是由Keymaster使用STORAGE_KEY標記生成的。然後,實際上提供給內核的每個FBE密鑰都是從Keymaster導出的STORAGE_KEY密鑰,這使它被每次引導的臨時密鑰包裝。然後,內核將包裝的密鑰直接提供給嵌入式加密硬件。正確實施後,解開的密鑰將永遠不會出現在系統內存中,並且重新啟動後無法使用已破壞的換行密鑰。該標誌需要硬件支持,對STORAGE_KEY Keymaster支持,內核驅動程序支持, inlinecrypt掛載選項以及inlinecrypt_optimizedemmc_optimized標誌。

如果您不使用嵌入式加密硬件,則大多數設備的建議設置為fileencryption=aes-256-xts 。如果您使用嵌入式加密硬件,則大多數設備的推薦設置為fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized 。在沒有任何形式的AES加速的設備上,可以通過設置fileencryption=adiantum來使用Adiantum代替AES。

在使用Android 10或更低版本啟動的設備上,也接受fileencryption=ice來指定使用FSCRYPT_MODE_PRIVATE文件內容加密模式。 Android通用內核尚未實現此模式,但是供應商可以使用自定義內核補丁來實現。此模式產生的磁盤格式是特定於供應商的。在使用Android R或更高版本啟動的設備上,不再允許該模式,而必須使用標準加密格式。

默認情況下,文件內容加密是使用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和元數據加密上可採用存儲。但是,您可以通過在PRODUCT_PROPERTY_OVERRIDES設置屬性來覆蓋可採用的存儲上的FBE和/或元數據加密格式。

在以Android R或更高版本啟動的設備上,使用以下屬性:

  • ro.crypto.volume.options (Android R中的新增功能)在採用的存儲上選擇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完成,鑰匙之王必須準備好處理請求。在Pixel設備上,這可以通過確保在掛載/data之前啟動Keymaster的腳本塊來解決。

加密政策

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

在Android R及更高版本中,加密策略不再硬編碼到集中位置,而是由init腳本中mkdir命令的參數定義。使用系統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屬性是將應用程序中的所有組件標記為可directBootAware加密的簡寫形式。

defaultToDeviceProtectedStorage屬性將默認應用程序存儲位置重定向到指向DE存儲,而不是指向CE存儲。使用此標誌的系統應用程序必須仔細審核存儲在默認位置的所有數據,並更改敏感數據的路徑以使用CE存儲。使用此選項的設備製造商應仔細檢查其存儲的數據,以確保其中不包含任何個人信息。

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

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

支持多個用戶

多用戶環境中的每個用戶都有一個單獨的加密密鑰。每個用戶都有兩個密鑰:DE和CE密鑰。用戶0是特殊用戶,必須首先登錄設備。這與“ 設備管理”用途有關。

支持加密的應用程序以這種方式在用戶之間交互: INTERACT_ACROSS_USERSINTERACT_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加密測試,例如DirectBootHostTestEncryptionTest

如果設備運行的是Android R或更高版本,請同時運行VtsKernelEncryptionTest

atest vts_kernel_encryption_test

要么:

vts-tradefed run vts -m VtsKernelEncryptionTest

此外,設備製造商可能會執行以下手動測試。在啟用了FBE的設備上:

  • 檢查ro.crypto.state存在
    • 確保ro.crypto.state已加密
  • 檢查ro.crypto.type存在
    • 確保將ro.crypto.type設置為file

此外,測試人員可以在主用戶上設置userdebug來啟動userdebug實例。然後,將adb shell插入設備並使用su成為root。確保/data/data包含加密的文件名;如果沒有,則說明有問題。

還鼓勵設備製造商探索在其設備或內核上運行上游Linux測試fscrypt的方法 。這些測試是xfstests文件系統測試套件的一部分。但是,Android官方不支持這些上游測試。

AOSP實施細節

本節提供有關AOSP實現的詳細信息,並描述基於文件的加密如何工作。設備製造商不必在此處進行任何更改即可在其設備上使用FBE和Direct Boot。

fscrypt加密

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

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

還支持Adiantum加密 。啟用Adiantum加密後,文件內容和文件名都會用Adiantum加密。

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

密鑰派生

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

  • 身份驗證令牌
  • 擴展的憑證
  • “可丟棄的哈希”

身份驗證令牌是用戶成功登錄後由Gatekeeper生成的經過密碼驗證的令牌。除非提供了正確的身份驗證令牌,否則TEE將拒絕使用該密鑰。如果用戶沒有憑據,則無需使用也不使用身份驗證令牌。

拉伸憑證是使用scrypt算法進行鹽析和拉伸後的用戶憑證。憑證實際上在鎖定設置服務中被哈希一次,然後傳遞給vold傳遞給scrypt 。這與所有適用於KM_TAG_APPLICATION_ID的保證一起,加密地綁定到TEE中的密鑰。如果用戶沒有憑據,則無需使用或不需要擴展的憑據。

secdiscardable hash是與其他用於重建密鑰的信息(例如種子)一起存儲的16 KB隨機文件的512位哈希。刪除密鑰或以新方式對其進行加密後,該文件將被安全刪除。這項附加的保護措施可確保攻擊者必須恢復此安全刪除文件的每一位,才能恢復密鑰。這與所有適用於KM_TAG_APPLICATION_ID的保證一起,加密地綁定到TEE中的密鑰。

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