GKI 核心包含名為 fips140.ko
的 Linux 核心模組,符合FIPS 140-3 對密碼編譯軟體模組的要求。如果執行 GKI 核心的產品需要 FIPS 認證,則可提交這個模組進行認證。
特別是下列 FIPS 140-3 要求。 以下程式碼可用於加密處理常式:
- 該模組必須先檢查其完整性,才能建立加密編譯演算法 廣告。
- 模組必須使用已知答案的自我測試,驗證已核准的加密編譯演算法,才能提供這些演算法。
為何要使用獨立的核心模組
FIPS 140-3 驗證是根據軟體或硬體 而且任何基礎模組都已通過認證,現在沒有任何改變。如果日後有變更 重新認證。這與目前使用的軟體開發程序不相符。因此,FIPS 軟體模組通常會盡可能以密碼編譯元件為重點,確保與密碼編譯無關的變更不需要重新評估密碼編譯。
GKI 核心會在其整個支援生命週期中定期更新。因此整個核心無法納入 FIPS 中 模組邊界,例如每個核心都必須重新認證 更新。定義「FIPS 模組」是核心映像檔的一部分 這雖然緩解了此問題,但還是無法解決,因為 「FIPS 模組」結果仍可能會比平常來得高
在核心 6.1 版之前,另一個考量是 GKI 是以 已啟用 LTO (連結時間最佳化),因為 LTO 是控制組的先決條件 資料流完整性是重要的安全性功能,
因此,符合 FIPS 140-3 規範的所有程式碼都會封裝
變成只依賴穩定版的獨立核心模組 fips140.ko
由建構的 GKI 核心原始碼公開的介面。這表示模組可與同一代的不同 GKI 版本搭配使用,且只有在模組本身所附帶的程式碼修正任何問題時,才需要更新並重新提交以取得認證。
模組的使用時機
GKI 核心本身會攜帶程式碼,而這項程式碼會依賴加密例程,這些例程也會封裝至 FIPS 140-3 核心模組。因此,內建的加密例程並未實際移出 GKI 核心,而是複製到模組中。載入模組時,系統會執行內建的加密處理常式 已從 Linux CryptoAPI 取消註冊,並取代由 後續課程我們將逐一介紹 預先訓練的 API、AutoML 和自訂訓練
這表示 fips140.ko
模組完全是選擇性的,且只有在
部署 FIPS 140-3 認證時更合理。除此之外,模組不會提供任何額外功能,不必要載入模組只會影響開機時間,不會帶來任何好處。
如何部署模組
您可以按照下列步驟,將模組納入 Android 建構:
- 將模組名稱新增至
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
。如此一來, 模組,以便複製到供應商 ramdisk。 - 將模組名稱新增至
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
。這個 會將模組名稱新增至目標的modules.load
中。modules.load
會保留init
在當 裝置開機
完整性自檢查
FIPS 140-3 核心模組會在模組載入時取得自身 .code
和 .rodata
區段的 HMAC-SHA256 摘要,並與模組中記錄的摘要進行比較。在 Linux 模組載入器
但我們已對其進行一般修改,例如 ELF 重新配置處理
將 CPU 錯誤修補的替代方法我們會採取下列額外步驟,確保摘要能正確重現:
- ELF 重新安置會保留在模組中,以便反向套用至 HMAC 的輸入內容。
- 這個模組會反轉核心為動態遮罩呼叫堆疊所做的任何程式碼修補程式。具體來說,這個模組會將從陰影呼叫堆疊中推送或彈出的任何指示,替換為原本存在的指標驗證碼 (PAC) 指示。
- 系統會停用模組的所有其他程式碼修補功能,包括靜態金鑰和 因此追蹤點和廠商掛鉤
已知答案的自我測驗
任何已納入 FIPS 140-3 規範的實作演算法,皆必須 確認模型在使用前先執行已知的答案自我測試根據 FIPS 140-3 導入指南 10.3.A、 使用任一支援的金鑰長度為每個演算法的單一測試向量為 足以因應加密的需求。
Linux CryptoAPI 具有演算法優先順序的概念, 實作方式 (例如使用特殊密碼編譯指示的一種, 針對不採用這些指令的 CPU) 共存。因此,請善加測試 演算法。此為必要步驟,因為 Linux CryptoAPI 允許優先順序 而且優先順序較低的演算法 改為選取
模組中包含的演算法
以下列出 FIPS 140-3 模組中包含的所有演算法。
此規定適用於 android12-5.10
、android13-5.10
、android13-5.15
、
android14-5.15
、android14-6.1
和 android15-6.6
核心分支版本
會視情況指出核心版本之間的差異。
演算法 | 導入 | 可核准 | 定義 |
---|---|---|---|
aes |
aes-generic 、aes-arm64 、aes-ce 、AES 程式庫 |
是 | 純 AES 區塊加密法,不含運作模式:支援所有金鑰大小 (128 位元、192 位元和 256 位元)。除了程式庫實作項目,所有實作項目都能透過範本以作業模式編寫。 |
cmac(aes) |
cmac (範本)、cmac-aes-neon 、cmac-aes-ce |
是 | AES-CMAC:支援所有 AES 金鑰大小。cmac 範本可與使用 cmac(<aes-impl>) 的任何 aes 實作項目組合。其他實作方式則是獨立的。 |
ecb(aes) |
ecb (範本)、ecb-aes-neon 、ecb-aes-neonbs 、ecb-aes-ce |
是 | AES-ECB:支援所有 AES 金鑰大小。ecb 範本可透過 ecb(<aes-impl>) ,透過任何實作的 aes 編寫。其他實作方式則是獨立的。 |
cbc(aes) |
cbc (範本)、cbc-aes-neon 、cbc-aes-neonbs 、cbc-aes-ce |
是 | AES-CBC:支援所有 AES 金鑰大小。cbc 範本可與使用 ctr(<aes-impl>) 的任何 aes 實作項目組合。其他實作方式則是獨立的。 |
cts(cbc(aes)) |
cts (範本)、cts-cbc-aes-neon 、cts-cbc-aes-ce |
是 | 竊取密文的 AES-CBC-CTS 或 AES-CBC:採用的慣例是 CS3 ;最後兩個密文區塊會無條件交換支援所有 AES 金鑰大小。cts 範本可透過 cts(<cbc(aes)-impl>) ,透過任何實作的 cbc 編寫。其他實作方式則是獨立的。 |
ctr(aes) |
ctr (範本)、ctr-aes-neon 、ctr-aes-neonbs 、ctr-aes-ce |
是 | AES-CTR:支援所有 AES 金鑰大小。ctr 範本可與使用 ctr(<aes-impl>) 的任何 aes 實作項目組合。其他實作方式則是獨立的。 |
xts(aes) |
xts (範本)、xts-aes-neon 、xts-aes-neonbs 、xts-aes-ce |
是 | AES-XTS:在核心版本 6.1 以下,系統支援所有 AES 金鑰大小;在核心版本 6.6 以上,系統僅支援 AES-128 和 AES-256。xts 範本可與使用 xts(<ecb(aes)-impl>) 的任何 ecb(aes) 實作項目組合。其他實作方式則是獨立的。所有實作都會實作 FIPS 所需的弱式金鑰檢查。也就是說,第一和第二個半相等的 XTS 金鑰會遭到拒絕。 |
gcm(aes) |
gcm (範本),gcm-aes-ce |
否1 | AES-GCM:支援所有 AES 金鑰大小。僅支援 96 位元 IV。如同該模組中的其他所有 AES 模式,呼叫端必須負責提供 IV。gcm 範本可透過使用 gcm_base(<ctr(aes)-impl>,<ghash-impl>) ,透過任何實作 ctr(aes) 和 ghash 編寫編寫。其他實作方式則是獨立的。 |
sha1 |
sha1-generic 、sha1-ce |
是 | SHA-1 加密編譯雜湊函式 |
sha224 |
sha224-generic 、sha224-arm64 、sha224-ce |
是 | SHA-224 加密編譯雜湊函式:程式碼會與 SHA-256 共用。 |
sha256 |
sha256-generic 、sha256-arm64 、sha256-ce 、SHA-256 程式庫 |
是 | SHA-256 加密雜湊函式:除了標準 CryptoAPI 介面外,SHA-256 也提供程式庫介面。這個程式庫介面採用的實作方式不同。 |
sha384 |
sha384-generic 、sha384-arm64 、sha384-ce |
是 | SHA-384 加密編譯雜湊函式:程式碼會與 SHA-512 共用。 |
sha512 |
sha512-generic 、sha512-arm64 、sha512-ce |
是 | SHA-512 加密編譯雜湊函式 |
sha3-224 |
sha3-224-generic |
是 | SHA3-224 加密編譯雜湊函式。僅在核心 6.6 以上版本中顯示。 |
sha3-256 |
sha3-256-generic |
是 | 與前述相同,但摘要長度為 256 位元 (SHA3-256)。所有摘要長度都使用相同的 Keccak 實作方式。 |
sha3-384 |
sha3-384-generic |
是 | 與上述相同,但採用 384 位元摘要長度 (SHA3-384)。所有摘要長度都使用相同的 Keccak 實作方式。 |
sha3-512 |
sha3-512-generic |
是 | 與上述相同,但採用 512 位元摘要長度 (SHA3-512)。所有摘要長度都使用相同的 Keccak 實作方式。 |
hmac |
hmac (範本) |
是 | HMAC (金鑰雜湊訊息驗證碼):hmac 範本可透過任何 SHA 演算法,也可使用 hmac(<sha-alg>) 或 hmac(<sha-impl>) 進行實作。 |
stdrng |
drbg_pr_hmac_sha1 、drbg_pr_hmac_sha256 、drbg_pr_hmac_sha384 、drbg_pr_hmac_sha512 |
是 | 使用已命名雜湊函式並啟用預測防護功能來例項化 HMAC_DRBG:包含健康狀態檢查。使用這個介面的使用者會取得自己的 DRBG 例項。 |
stdrng |
drbg_nopr_hmac_sha1 、drbg_nopr_hmac_sha256 、drbg_nopr_hmac_sha384 、drbg_nopr_hmac_sha512 |
是 | 與 drbg_pr_* 演算法相同,但預測抗力已停用。程式碼會與不受預測影響的變化版本共用。在核心 5.10 版中,優先順序最高的 DRBG 為 drbg_nopr_hmac_sha256 。在核心 5.15 以上版本中,則為 drbg_pr_hmac_sha512 。 |
jitterentropy_rng |
jitterentropy_rng |
不可以 | Jitter RNG,版本為 2.2.0 (核心版本 6.1 以下) 或 3.4.0 (核心版本 6.6 以上)。使用這個介面的使用者會取得自己的 Jitter RNG 例項。不會重複使用 DRBG 使用的執行個體。 |
xcbc(aes) |
xcbc-aes-neon 、xcbc-aes-ce |
不可以 | |
xctr(aes) |
xctr-aes-neon 、xctr-aes-ce |
不可以 | 僅在核心 5.15 以上版本中顯示。 |
cbcmac(aes) |
cbcmac-aes-neon 、cbcmac-aes-ce |
不可以 | |
essiv(cbc(aes),sha256) |
essiv-cbc-aes-sha256-neon 、essiv-cbc-aes-sha256-ce |
不可以 |
從來源建構模組
針對 Android 14 以上版本 (包括 android-mainline
),請使用下列指令從來源建構 fips140.ko
模組。
使用 Bazel 建構:
tools/bazel run //common:fips140_dist
使用
build.sh
(舊版) 建構:BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
這些指令會執行完整建構作業,包括核心和 fips140.ko
模組中嵌入 HMAC-SHA256 摘要內容。
使用者指引
加密編譯人員指南
如要操作核心模組,作業系統必須限定於 單一運算子作業模式。Android 會使用處理器中的記憶體管理硬體自動處理這項作業。
核心模組無法單獨安裝。包含在 裝置韌體,並在開機時自動載入。只會在 核准的作業模式。
加密管理員可以隨時重新啟動裝置,執行自我測試。
使用指南
使用者是需要使用密碼編譯演算法的其他核心元件。核心模組不會在 使用演算法,且不會在一段時間後儲存任何參數。 執行加密編譯作業所需的資源。
為了符合 FIPS 規定,您只能使用已核准的演算法。符合 FIPS 140-3「服務指標」要求
模組提供 fips140_is_approved_service
函式,可指出
確認是否通過演算法
自我測試錯誤
如果發生自檢測失敗的情況,核心模組會導致核心發生恐慌,裝置就不會繼續開機。如果重新啟動裝置無法解決問題,則必須將裝置重新啟動至復原模式,藉由重新刷新裝置來修正問題。
-
模組的 AES-GCM 實作項目應為「演算法」 已核准」但並非「模組已核准」這些加密可通過驗證,但 AES-GCM 無法視為 FIPS 模組的已核准演算法。 這是因為 GCM 的 FIPS 模組要求與 GCM 不相容 不會產生自身 IV 的 GCM 實作。 ↩