GKI 核心包含名為 fips140.ko 的 Linux 核心模組，符合FIPS 140-3 對加密編譯軟體模組的要求。如果執行 GKI 核心的產品需要 FIPS 認證，則可將此模組提交進行認證。
您必須先滿足下列 FIPS 140-3 要求，才能使用加密常式：
- 模組必須先檢查自身的完整性，才能提供密碼編譯演算法。
- 模組必須使用已知答案的自我測試，驗證已核准的加密編譯演算法，才能提供這些演算法。
為何要使用獨立的核心模組
FIPS 140-3 驗證是以軟體或硬體模組經過認證後，永遠不會改變的概念為基礎。如果變更，就必須重新認證。這與目前使用的軟體開發程序不相容。因此，為了符合這項規定，FIPS 軟體模組通常會盡可能以加密機制元件為重點，確保與加密機制無關的變更不需要重新評估加密機制。
GKI 核心會在整個支援的生命週期內定期更新。這會導致整個核心無法位於 FIPS 模組邊界內，因為此模組需要在每次核心更新時重新認證。將「FIPS 模組」定義為核心映像檔的子集可以減緩此問題，但也無法解決，因為「FIPS 模組」的二進位檔內容仍會比所需的頻率高許多。
在核心版本 6.1 之前，另一項考量是 GKI 編譯時啟用了 LTO (Link Time Optimization)，因為 LTO 是控制流程完整性 (這是重要的安全性功能) 的必要條件。
因此，所有符合 FIPS 140-3 規定的程式碼都會封裝到獨立的核心模組 fips140.ko 中，該模組只會依賴所建構的 GKI 核心來源所公開的穩定介面。這表示模組可與同一代的不同 GKI 版本搭配使用，且只有在模組本身所附帶的程式碼修正任何問題時，才需要更新並重新提交以取得認證。
模組的使用時機
GKI 核心本身會攜帶程式碼，而這項程式碼會依賴加密例程，這些例程也會封裝至 FIPS 140-3 核心模組。因此，內建的加密例程並未實際移出 GKI 核心，而是複製到模組中。載入模組時，內建的加密例行程序會從 Linux CryptoAPI 取消註冊，並由模組所載的例行程序取代。
這表示 fips140.ko 模組是完全選擇性的，而且只有在 FIPS 140-3 認證的情況下才適合部署模組。除此之外，模組不會提供任何額外功能，因此不必要載入模組，只會影響開機時間，不會帶來任何好處。
如何部署模組
您可以按照下列步驟，將模組納入 Android 建構：
- 將模組名稱新增至
BOARD_VENDOR_RAMDISK_KERNEL_MODULES。這會導致模組複製至供應商的 RAM 磁碟。 - 將模組名稱新增至
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 實作項目應可獲得「演算法核准」認證，但無法獲得「模組核准」認證。這些演算法可以驗證，但從 FIPS 模組的角度來看，AES-GCM 並非核准的演算法。這是因為 GCM 的 FIPS 模組規定與不產生自身 IV 的 GCM 實作不相容。 ↩