Mô-đun mã hoá GKI có thể chứng nhận theo FIPS 140-3

Nhân GKI bao gồm một mô-đun nhân Linux có tên là fips140.ko tuân thủ các yêu cầu FIPS 140-3 đối với các mô-đun phần mềm mật mã. Bạn có thể gửi mô-đun này để được chứng nhận FIPS nếu sản phẩm chạy nhân GKI yêu cầu.

Cụ thể, bạn phải đáp ứng các yêu cầu sau đây theo FIPS 140-3 trước khi có thể sử dụng các quy trình mã hoá:

• Mô-đun phải kiểm tra tính toàn vẹn của chính nó trước khi cung cấp các thuật toán mật mã.
• Mô-đun phải thực hiện và xác minh các thuật toán mật mã đã được phê duyệt bằng cách sử dụng các quy trình tự kiểm tra câu trả lời đã biết trước khi cung cấp các thuật toán đó.

Tại sao cần có một mô-đun nhân riêng biệt

Quy trình xác thực FIPS 140-3 dựa trên ý tưởng rằng một khi mô-đun dựa trên phần mềm hoặc phần cứng đã được chứng nhận, thì mô-đun đó sẽ không bao giờ thay đổi. Nếu thay đổi, bạn phải chứng nhận lại. Điều này không phù hợp với các quy trình phát triển phần mềm đang được sử dụng hiện nay. Do yêu cầu này, các mô-đun phần mềm FIPS thường được thiết kế để tập trung chặt chẽ vào các thành phần mã hoá nhất có thể, nhằm đảm bảo rằng những thay đổi không liên quan đến hoạt động mã hoá không yêu cầu đánh giá lại hoạt động mã hoá.

Nhân GKI dự kiến sẽ được cập nhật thường xuyên trong toàn bộ vòng đời được hỗ trợ. Điều này khiến toàn bộ nhân không thể nằm trong ranh giới mô-đun FIPS, vì mô-đun như vậy sẽ cần được chứng nhận lại sau mỗi lần cập nhật nhân. Việc xác định "mô-đun FIPS" là một tập hợp con của hình ảnh hạt nhân sẽ giảm thiểu nhưng không giải quyết được vấn đề này, vì nội dung nhị phân của "mô-đun FIPS" vẫn sẽ thay đổi thường xuyên hơn nhiều so với mức cần thiết.

Trước phiên bản kernel 6.1, một điểm cần cân nhắc khác là GKI được biên dịch khi bật LTO (Tối ưu hoá thời gian liên kết), vì LTO là điều kiện tiên quyết cho Tính toàn vẹn của luồng điều khiển (một tính năng bảo mật quan trọng).

Do đó, tất cả mã thuộc phạm vi yêu cầu FIPS 140-3 đều được đóng gói vào một mô-đun kernel riêng biệt fips140.ko chỉ dựa vào các giao diện ổn định do nguồn kernel GKI mà mô-đun đó được tạo ra cung cấp. Điều này có nghĩa là mô-đun có thể được dùng với nhiều bản phát hành GKI của cùng một thế hệ và bạn chỉ phải cập nhật và gửi lại để chứng nhận nếu có vấn đề nào được khắc phục trong mã do chính mô-đun đó mang theo.

Trường hợp sử dụng mô-đun

Bản thân nhân GKI mang mã phụ thuộc vào các quy trình mã hoá cũng được đóng gói vào mô-đun nhân FIPS 140-3. Do đó, các quy trình mã hoá tích hợp không thực sự được di chuyển ra khỏi nhân GKI mà được sao chép vào mô-đun. Khi mô-đun được tải, các quy trình mã hoá tích hợp sẽ được huỷ đăng ký khỏi Linux CryptoAPI và được thay thế bằng các quy trình do mô-đun thực hiện.

Điều này có nghĩa là mô-đun fips140.ko hoàn toàn không bắt buộc và bạn chỉ nên triển khai mô-đun này nếu chứng nhận FIPS 140-3 là một yêu cầu. Ngoài ra, mô-đun này không cung cấp thêm chức năng nào và việc tải mô-đun này một cách không cần thiết chỉ có khả năng ảnh hưởng đến thời gian khởi động mà không mang lại lợi ích nào.

Cách triển khai mô-đun

Bạn có thể kết hợp mô-đun này vào bản dựng Android bằng cách thực hiện các bước sau:

• Thêm tên mô-đun vào BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Điều này khiến mô-đun được sao chép vào ramdisk của nhà cung cấp.
• Thêm tên mô-đun vào BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Thao tác này sẽ khiến tên mô-đun được thêm vào modules.load trên mục tiêu. modules.load chứa danh sách các mô-đun mà init tải khi thiết bị khởi động.

Tự kiểm tra tính toàn vẹn

Mô-đun hạt nhân FIPS 140-3 lấy bản tóm tắt HMAC-SHA256 của các phần .code và .rodata tại thời điểm tải mô-đun, rồi so sánh bản tóm tắt đó với bản tóm tắt được ghi trong mô-đun. Điều này diễn ra sau khi trình tải mô-đun Linux đã thực hiện các sửa đổi thông thường, chẳng hạn như xử lý di dời ELF và vá các lựa chọn thay thế cho lỗi CPU đối với những phần đó. Các bước bổ sung sau đây được thực hiện để đảm bảo rằng bạn có thể tái tạo đúng bản tóm tắt:

• Các hoạt động di dời ELF được giữ nguyên bên trong mô-đun để có thể áp dụng theo hướng ngược lại cho đầu vào của HMAC.
• Mô-đun này đảo ngược mọi bản vá mã do nhân thực hiện cho Ngăn xếp lệnh gọi bóng động. Cụ thể, mô-đun này sẽ thay thế mọi chỉ dẫn đẩy hoặc bật từ ngăn xếp lệnh gọi bóng bằng các chỉ dẫn Mã xác thực con trỏ (PAC) có sẵn ban đầu.
• Tất cả các hoạt động vá mã khác đều bị vô hiệu hoá đối với mô-đun, bao gồm cả các khoá tĩnh và do đó, các điểm theo dõi cũng như các lệnh gọi của nhà cung cấp.

Bài tự kiểm tra có đáp án sẵn

Mọi thuật toán đã triển khai thuộc phạm vi yêu cầu FIPS 140-3 đều phải thực hiện một quy trình tự kiểm tra câu trả lời đã biết trước khi được sử dụng. Theo Hướng dẫn triển khai FIPS 140-3 10.3.A, một vectơ kiểm thử duy nhất cho mỗi thuật toán bằng cách sử dụng bất kỳ độ dài khoá nào được hỗ trợ là đủ cho các mật mã, miễn là cả quá trình mã hoá và giải mã đều được kiểm thử.

Linux CryptoAPI có khái niệm về mức độ ưu tiên của thuật toán, trong đó một số cách triển khai (chẳng hạn như một cách sử dụng các chỉ dẫn mã hoá đặc biệt và một cách dự phòng cho những CPU không triển khai các chỉ dẫn đó) của cùng một thuật toán có thể cùng tồn tại. Do đó, bạn cần kiểm thử tất cả các cách triển khai của cùng một thuật toán. Điều này là cần thiết vì Linux CryptoAPI cho phép bỏ qua lựa chọn dựa trên mức độ ưu tiên và thay vào đó, một thuật toán có mức độ ưu tiên thấp hơn sẽ được chọn.

Các thuật toán có trong mô-đun

Tất cả các thuật toán có trong mô-đun FIPS 140-3 đều được liệt kê như sau. Điều này áp dụng cho các nhánh hạt nhân android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 và android15-6.6, mặc dù sự khác biệt giữa các phiên bản hạt nhân sẽ được ghi chú khi thích hợp.

Thuật toán	Triển khai	Có thể phê duyệt	Định nghĩa
aes	aes-generic, aes-arm64, aes-ce, thư viện AES	Có	Thuật toán mã hoá khối AES thuần tuý, không có chế độ hoạt động: Hỗ trợ tất cả các kích thước khoá (128 bit, 192 bit và 256 bit). Tất cả các cách triển khai khác ngoài cách triển khai thư viện đều có thể được tạo bằng một chế độ hoạt động thông qua một mẫu.
cmac(aes)	cmac (mẫu), cmac-aes-neon, cmac-aes-ce	Có	AES-CMAC: Tất cả các kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu cmac bằng mọi cách triển khai aes bằng cách sử dụng cmac(<aes-impl>). Các cách triển khai khác là độc lập.
ecb(aes)	ecb (mẫu), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	Có	AES-ECB: Tất cả các kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu ecb bằng mọi cách triển khai aes bằng cách sử dụng ecb(<aes-impl>). Các cách triển khai khác là độc lập.
cbc(aes)	cbc (mẫu), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	Có	AES-CBC: Tất cả các kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu cbc bằng mọi cách triển khai aes bằng cách sử dụng ctr(<aes-impl>). Các cách triển khai khác là độc lập.
cts(cbc(aes))	cts (mẫu), cts-cbc-aes-neon, cts-cbc-aes-ce	Có	AES-CBC-CTS hoặc AES-CBC có tính năng đánh cắp văn bản mã hoá: Quy ước được sử dụng là CS3; hai khối văn bản mã hoá cuối cùng sẽ được hoán đổi vô điều kiện. Hỗ trợ tất cả các kích thước khoá AES. Bạn có thể kết hợp mẫu cts với mọi cách triển khai cbc bằng cách sử dụng cts(<cbc(aes)-impl>). Các cách triển khai khác là độc lập.
ctr(aes)	ctr (mẫu), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	Có	AES-CTR: Hỗ trợ tất cả các kích thước khoá AES. Bạn có thể tạo mẫu ctr bằng mọi cách triển khai aes bằng cách sử dụng ctr(<aes-impl>). Các cách triển khai khác là độc lập.
xts(aes)	xts (mẫu), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Có	AES-XTS: Trong phiên bản kernel 6.1 trở xuống, tất cả các kích thước khoá AES đều được hỗ trợ; trong phiên bản kernel 6.6 trở lên, chỉ AES-128 và AES-256 được hỗ trợ. Bạn có thể tạo mẫu xts bằng mọi cách triển khai ecb(aes) bằng cách sử dụng xts(<ecb(aes)-impl>). Các cách triển khai khác là độc lập. Tất cả các quy trình triển khai đều triển khai quy trình kiểm tra khoá yếu theo yêu cầu của FIPS; tức là các khoá XTS có nửa đầu và nửa sau bằng nhau sẽ bị từ chối.
gcm(aes)	gcm (mẫu), gcm-aes-ce	Không1	AES-GCM: Hỗ trợ tất cả các kích thước khoá AES. Chỉ các IV 96 bit mới được hỗ trợ. Cũng như tất cả các chế độ AES khác trong mô-đun này, người gọi chịu trách nhiệm cung cấp IV. Bạn có thể tạo mẫu gcm bằng mọi cách triển khai ctr(aes) và ghash bằng cách sử dụng gcm_base(<ctr(aes)-impl>,<ghash-impl>). Các cách triển khai khác là độc lập.
sha1	sha1-generic, sha1-ce	Có	Hàm băm mật mã SHA-1
sha224	sha224-generic, sha224-arm64, sha224-ce	Có	Hàm băm mật mã SHA-224: Mã này được chia sẻ với SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, thư viện SHA-256	Có	Hàm băm mật mã SHA-256: Giao diện thư viện được cung cấp cho SHA-256 ngoài giao diện CryptoAPI tiêu chuẩn. Giao diện thư viện này sử dụng một phương thức triển khai khác.
sha384	sha384-generic, sha384-arm64, sha384-ce	Có	Hàm băm mật mã SHA-384: Mã này được chia sẻ với SHA-512.
sha512	sha512-generic, sha512-arm64, sha512-ce	Có	Hàm băm mật mã SHA-512
sha3-224	sha3-224-generic	Có	Hàm băm mật mã SHA3-224. Chỉ có trong kernel phiên bản 6.6 trở lên.
sha3-256	sha3-256-generic	Có	Tương tự như trên, nhưng có độ dài thông báo là 256 bit (SHA3-256). Tất cả độ dài của bản tóm tắt đều sử dụng cùng một phương thức triển khai Keccak.
sha3-384	sha3-384-generic	Có	Tương tự như trên, nhưng có độ dài thông báo tóm tắt là 384 bit (SHA3-384). Tất cả độ dài của bản tóm tắt đều sử dụng cùng một phương thức triển khai Keccak.
sha3-512	sha3-512-generic	Có	Tương tự như trên, nhưng có độ dài thông báo tóm tắt là 512 bit (SHA3-512). Tất cả độ dài của bản tóm tắt đều sử dụng cùng một phương thức triển khai Keccak.
hmac	hmac (mẫu)	Có	HMAC (Mã xác thực thông báo băm có khoá): Bạn có thể tạo mẫu hmac bằng bất kỳ thuật toán hoặc phương thức triển khai SHA nào bằng cách sử dụng hmac(<sha-alg>) hoặc hmac(<sha-impl>).
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	Có	HMAC_DRBG được khởi tạo bằng hàm băm được đặt tên và có bật tính năng chống dự đoán: Bao gồm các quy trình kiểm tra tình trạng. Người dùng giao diện này sẽ có các thực thể DRBG riêng.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Có	Tương tự như các thuật toán drbg_pr_*, nhưng đã tắt tính năng chống đoán. Mã này được chia sẻ với biến thể có khả năng chống dự đoán. Trong phiên bản kernel 5.10, DRBG có mức độ ưu tiên cao nhất là drbg_nopr_hmac_sha256. Trong kernel phiên bản 5.15 trở lên, đây là drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Không	Jitter RNG, phiên bản 2.2.0 (kernel phiên bản 6.1 trở xuống) hoặc phiên bản 3.4.0 (kernel phiên bản 6.6 trở lên). Người dùng giao diện này sẽ có các thực thể RNG Jitter riêng. Chúng không sử dụng lại các thực thể mà DRBG sử dụng.
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	Không
xctr(aes)	xctr-aes-neon, xctr-aes-ce	Không	Chỉ có trong kernel phiên bản 5.15 trở lên.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	Không
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	Không

Tạo mô-đun từ nguồn

Đối với Android 14 trở lên (bao gồm cả android-mainline), hãy tạo mô-đun fips140.ko từ nguồn bằng các lệnh sau.

• Tạo bằng Bazel:

  tools/bazel run //common:fips140_dist

• Tạo bằng build.sh (cũ):

  BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

Các lệnh này thực hiện một bản dựng đầy đủ, bao gồm cả hạt nhân và mô-đun fips140.ko với nội dung tóm tắt HMAC-SHA256 được nhúng trong đó.

Hướng dẫn cho người dùng cuối

Hướng dẫn dành cho Nhân viên phụ trách tiền mã hoá

Để vận hành mô-đun kernel, hệ điều hành phải bị hạn chế ở một chế độ vận hành duy nhất. Android sẽ tự động xử lý việc này bằng phần cứng quản lý bộ nhớ trong bộ xử lý.

Bạn không thể cài đặt riêng mô-đun kernel; mô-đun này được đưa vào dưới dạng một phần của chương trình cơ sở thiết bị và tự động tải khi khởi động. Thiết bị này chỉ hoạt động ở chế độ hoạt động được phê duyệt.

Nhân viên phụ trách mã hoá có thể chạy các quy trình tự kiểm tra bất cứ lúc nào bằng cách khởi động lại thiết bị.

Hướng dẫn cho người dùng

Người dùng mô-đun kernel là các thành phần kernel khác cần sử dụng thuật toán mã hoá. Mô-đun hạt nhân không cung cấp thêm logic khi sử dụng các thuật toán và không lưu trữ bất kỳ tham số nào ngoài thời gian cần thiết để thực hiện một thao tác mã hoá.

Việc sử dụng các thuật toán cho mục đích tuân thủ FIPS chỉ giới hạn ở các thuật toán được phê duyệt. Để đáp ứng yêu cầu "chỉ báo dịch vụ" FIPS 140-3, mô-đun này cung cấp một hàm fips140_is_approved_service cho biết liệu một thuật toán có được phê duyệt hay không.

Lỗi tự kiểm tra

Trong trường hợp tự kiểm tra không thành công, mô-đun nhân sẽ khiến nhân gặp lỗi nghiêm trọng và thiết bị không tiếp tục khởi động. Nếu việc khởi động lại thiết bị không giải quyết được vấn đề, thì thiết bị phải khởi động ở chế độ khôi phục để khắc phục vấn đề bằng cách cài đặt lại hệ thống cho thiết bị.