一：加密簡介：

加密是使用對稱加密密鑰對 Android 設(shè)備上的所有用戶數(shù)據(jù)進行編碼的過程。設(shè)備經(jīng)過加密后，所有由用戶創(chuàng)建的數(shù)據(jù)在存入磁盤之前都會自動加密，并且所有讀取操作都會在將數(shù)據(jù)返回給調(diào)用進程之前自動解密數(shù)據(jù)。加密可確保未經(jīng)授權(quán)方在嘗試訪問相應(yīng)數(shù)據(jù)時無法進行讀取。

Android 有兩種設(shè)備加密方法，即文件級加密和全盤加密。

1）全盤加密(FDE)：Android 5.0 到 Android 9 支持全盤加密。全盤加密是使用單個密鑰（由用戶的設(shè)備密碼加以保護）來保護設(shè)備的整個用戶數(shù)據(jù)分區(qū)。在啟動時，用戶必須先提供其憑據(jù)，然后才能訪問磁盤的任何部分。

雖然這種加密方式非常有利于確保安全性，但這也意味著當重新啟動設(shè)備時，用戶無法立即使用手機的大多數(shù)核心功能。由于此單個用戶憑據(jù)的保護，系統(tǒng)無法訪問用戶的數(shù)據(jù)，所以鬧鐘等功能將無法運行，無障礙服務(wù)將無法使用，并且手機也無法接聽電話。

2）文件級加密(FBE)：Android 7.0 及更高版本支持文件級加密。采用文件級加密時，可以使用不同的密鑰對不同的文件進行加密，也可以對加密文件單獨解密。支持文件級加密的設(shè)備還可以支持直接啟動。該功能處于啟用狀態(tài)時，已加密設(shè)備在啟動后將直接進入鎖定屏幕，從而可讓用戶快速使用重要的設(shè)備功能，例如無障礙服務(wù)和鬧鐘。

引入文件級加密和可以將應(yīng)用設(shè)為加密感知型應(yīng)用的 API 后，應(yīng)用可以在受限環(huán)境中運行。這意味著，應(yīng)用可以在用戶提供憑據(jù)之前運行，同時系統(tǒng)仍能保護私密用戶信息。

3）Android 9 引入了對存在硬件支持的元數(shù)據(jù)加密的支持。采用元數(shù)據(jù)加密時，啟動時出現(xiàn)的單個密鑰會加密未通過 FBE 進行加密的任何內(nèi)容（例如目錄布局、文件大小、權(quán)限和創(chuàng)建/修改時間）。該密鑰受到 Keymaster 的保護，而 Keymaster 受到啟動時驗證功能的保護。

二：文件加密介紹FBE：

Android 7.0 及更高版本支持文件級加密 (FBE)。采用文件級加密時，可以使用不同的密鑰對不同的文件進行加密，也可以對加密文件單獨解密。

注意事項：

1）搭載 Android 10 及更高版本的新設(shè)備需要使用文件級加密。

2）搭載 Android 9 及更高版本的設(shè)備可以同時使用文件級加密和可合并的存儲設(shè)備。

3）對于搭載 Android 7.0-8.1 的設(shè)備，無法同時使用文件級加密和可合并的存儲設(shè)備。如果在這些設(shè)備上啟用文件級加密，則必須將新添加的存儲媒介（例如 SD 卡）用作傳統(tǒng)存儲設(shè)備。

直接啟動

借助文件級加密，Android 7.0 中引入了一項稱為直接啟動的新功能。該功能處于啟用狀態(tài)時，已加密設(shè)備在啟動后將直接進入鎖定屏幕。之前，在使用全盤加密?(FDE) 的已加密設(shè)備上，用戶在訪問任何數(shù)據(jù)之前都需要先提供憑據(jù)，以致于手機只能執(zhí)行最基本的操作。例如，手機甚至無法接聽電話，只能執(zhí)行基本的緊急撥號操作，而且鬧鐘無法運行，無障礙服務(wù)也不可用。

引入文件級加密 (FBE) 和可以將應(yīng)用設(shè)置為加密感知型應(yīng)用的新 API 后，這些應(yīng)用將能夠在受限環(huán)境中運行。這意味著，應(yīng)用可以在用戶提供憑據(jù)之前運行，同時系統(tǒng)仍能保護私密用戶信息。

在啟用了 FBE 的設(shè)備上，每位用戶均有兩個可供應(yīng)用使用的存儲位置：

憑據(jù)加密 (CE) 存儲空間，這是默認存儲位置，僅在用戶解鎖設(shè)備后可用。

設(shè)備加密 (DE) 存儲空間，該存儲位置在直接啟動模式下和用戶解鎖設(shè)備后均可使用。

這種分離能夠使工作資料更加安全，因為這樣一來，加密不再只基于啟動密碼，從而能夠同時保護多位用戶。

Direct Boot API 允許加密感知型應(yīng)用訪問上述任何一個存儲空間。應(yīng)用生命周期會發(fā)生一些變化，以便系統(tǒng)在以下情況下通知應(yīng)用：用戶的 CE 存儲空間因用戶在鎖定屏幕上首次輸入憑據(jù)而解鎖時，或者在工作資料提供工作資料安全質(zhì)詢時。無論是否實現(xiàn)了 FBE，搭載 Android 7.0 的設(shè)備都必須支持這些新的 API 和生命周期。不過，如果沒有啟用 FBE，DE 和 CE 存儲空間將始終處于解鎖狀態(tài)。

Android 開源項目 (AOSP) 中提供了 Ext4 和 F2FS 文件系統(tǒng)中的文件級加密的完整實現(xiàn)。在滿足相關(guān)要求的設(shè)備上，只需啟用該實現(xiàn)即可使用該功能。選擇使用 FBE 的制造商可能想要了解基于所用系統(tǒng)芯片 (SoC) 優(yōu)化該功能的方法。

AOSP 中的所有必要程序包均已更新為直接啟動感知型程序包。不過，如果設(shè)備制造商使用的是這些應(yīng)用的定制版本，則需要確保至少存在能夠提供以下服務(wù)的直接啟動感知型程序包：

1）電話服務(wù)和撥號器

2）用于在鎖定屏幕中輸入密碼的輸入法

示例和來源

Android 提供了文件級加密的參考實現(xiàn)，其中 vold (system/vold) 負責提供用于管理 Android 上的存儲設(shè)備和存儲卷的功能。添加 FBE 會為 vold 提供一些新命令，以便支持對多位用戶的 CE 密鑰和 DE 密鑰進行密鑰管理。除了為使用內(nèi)核中的文件級加密功能而進行的核心更改外，許多系統(tǒng)程序包（包括鎖定屏幕和 SystemUI）也經(jīng)過了修改，以支持 FBE 和“直接啟動”功能。這些選項包括：

AOSP 撥號器 (packages/apps/Dialer)

桌面時鐘 (packages/apps/DeskClock)

LatinIME (packages/inputmethods/LatinIME)*

“設(shè)置”應(yīng)用 (packages/apps/Settings)*

SystemUI (frameworks/base/packages/SystemUI)*

* 使用?defaultToDeviceProtectedStorage?清單屬性的系統(tǒng)應(yīng)用

?

啟用文件級加密

如需在設(shè)備上啟用文件級加密 (FBE)，就必須在內(nèi)部存儲設(shè)備 (userdata) 上啟用 FBE。這也會自動為可合并的存儲設(shè)備啟用 FBE；但是，如有必要，可以覆蓋可合并的存儲設(shè)備的加密格式。內(nèi)部存儲設(shè)備通過將?fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]?選項添加到?userdata?的?fstab?行?fs_mgr_flags?列，可啟用 FBE。此選項用于定義內(nèi)部存儲設(shè)備的加密格式。它最多包含三個以英文冒號分隔的參數(shù)：

Android10：ext4 fileencryption=ice,

Android11：f2fs fileencryption=aes-256-xts:

• contents_encryption_mode?參數(shù)指定將哪種加密算法用于加密文件內(nèi)容，可為?aes-256-xts?或?adiantum。
• filenames_encryption_mode?參數(shù)指定將哪種加密算法用于加密文件名，可為?aes-256-cts、aes-256-heh?或?adiantum。如果不指定，則當?contents_encryption_mode?為?aes-256-xts?時該參數(shù)默認為?aes-256-cts，當?contents_encryption_mode?為?adiantum?時該參數(shù)默認為?adiantum。
• Android 11 中新增的?flags?參數(shù)是以?+?字符分隔的一個標記列表。支持以下標記：
  • v1?標記用于選擇第 1 版加密政策；v2?標記用于選擇第 2 版加密政策。第 2 版加密政策使用更安全、更靈活的密鑰派生函數(shù)。如果設(shè)備搭載的是 Android 11 或更高版本（由?ro.product.first_api_level?確定），則默認選擇第 2 版；如果設(shè)備搭載的是 Android 10 或更低版本，則默認選擇第 1 版。
  • inlinecrypt_optimized?標記用于選擇針對無法高效處理大量密鑰的內(nèi)嵌加密硬件進行了優(yōu)化的加密格式。其具體做法是僅為每個 CE 或 DE 密鑰派生一個文件內(nèi)容加密密鑰，而不是為每個文件派生一個。IV（初始化向量）的生成也會相應(yīng)地進行調(diào)整。
  • emmc_optimized?標記與?inlinecrypt_optimized?類似，但它還選擇了將 IV 限制為 32 位的 IV 生成方法。此標記應(yīng)僅在符合 JEDEC eMMC v5.2 規(guī)范的內(nèi)嵌加密硬件上使用，因此僅支持 32 位 IV。在其他內(nèi)嵌加密硬件上，請改用?inlinecrypt_optimized。此標記一律不得在基于 UFS 的存儲設(shè)備上使用；UFS 規(guī)范允許使用 64 位 IV。
  • wrappedkey_v0?標記允許使用硬件封裝的密鑰。啟用該標記后，FBE 密鑰就不會由軟件生成，而是由 Keymaster 使用?STORAGE_KEY?標簽生成。然后，實際向內(nèi)核提供的每個 FBE 密鑰都是從 Keymaster 導(dǎo)出的?STORAGE_KEY?密鑰，這會導(dǎo)致每次啟動時都使用臨時密鑰對密鑰進行封裝。然后，內(nèi)核會將封裝的密鑰直接提供給內(nèi)嵌加密硬件。正確實現(xiàn)后，系統(tǒng)內(nèi)存中永遠不會顯示解封的密鑰，并且已破解的封裝密鑰在重新啟動后將無法使用。此標記需要硬件支持、對?STORAGE_KEY?的 Keymaster 支持、內(nèi)核驅(qū)動程序支持、inlinecrypt?裝載選項以及?inlinecrypt_optimized?標記或?emmc_optimized?標記。

如果不使用內(nèi)嵌加密硬件，則對于大多數(shù)設(shè)備推薦設(shè)置為?fileencryption=aes-256-xts。如果使用內(nèi)嵌加密硬件，則對于大多數(shù)設(shè)備推薦設(shè)置為?fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized。在沒有采用任何形式的 AES 加速的設(shè)備上，可以設(shè)置?fileencryption=adiantum，從而用?Adiantum代替 AES。

在搭載 Android 10 或更低版本的設(shè)備上，也可以使用?fileencryption=ice?來指定使用?FSCRYPT_MODE_PRIVATE?文件內(nèi)容加密模式。Android 通用內(nèi)核未實現(xiàn)該模式，但供應(yīng)商可使用自定義內(nèi)核補丁程序?qū)崿F(xiàn)該模式。該模式生成的磁盤格式因供應(yīng)商而異。在搭載 Android 11 或更高版本的設(shè)備上，不允許再使用該模式，而必須使用標準加密格式。

設(shè)備制造商還可以執(zhí)行以下手動測試。在啟用了 FBE 的設(shè)備上進行以下手動測試：

• 檢查?ro.crypto.state?是否存在
  • 確認?ro.crypto.state?是否已加密
• 檢查?ro.crypto.type?是否存在
  • 確認?ro.crypto.type?是否已設(shè)置為?file

?

?

總結(jié)

以上是生活随笔為你收集整理的Android 加密之文件加密（FBE）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。