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 của 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 chứng nhận này.

Bạn phải đáp ứng các yêu cầu sau đây của FIPS 140-3 trước khi có thể sử dụng các quy trình mật mã:

• Mô-đun phải tự kiểm tra tính toàn vẹ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 bài kiểm tra tự trả lời đã biết trước khi cung cấp các thuật toán đó.

Lý do cần có mô-đun nhân riêng

Quy trình xác thực FIPS 140-3 dựa trên ý tưởng rằng sau khi được chứng nhận, mô-đun dựa trên phần mềm hoặc phần cứng sẽ không bao giờ thay đổi. Nếu thay đổi, mô-đun đó phải được 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ẽ nhất có thể vào các thành phần mật mã, nhằm đảm bảo rằng những thay đổi không liên quan đến mật mã không yêu cầu đánh giá lại mật mã.

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 nhân hệ điều hành sẽ giảm thiểu vấn đề này nhưng không giải quyết được, vì nội dung tệp 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ã được đề cập trong các yêu cầu của FIPS 140-3 đều được đóng gói vào một mô-đun nhân riêng fips140.ko chỉ dựa vào các giao diện ổn định do nguồn nhân GKI mà mô-đun đó được xây dựng cung cấp. Điều này có nghĩa là bạn có thể sử dụng mô-đun này với các bản phát hành GKI khác nhau của cùng một thế hệ và bạn chỉ phải cập nhật và gửi lại mô-đun này để được 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.

Thời điểm sử dụng mô-đun

Bản thân nhân GKI mang theo mã phụ thuộc vào các quy trình mật mã cũng được đóng gói vào mô-đun nhân FIPS 140-3. Do đó, các quy trình mật mã tích hợp không thực sự được 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ật mã tích hợp sẽ bị huỷ đăng ký khỏi Linux CryptoAPI và được thay thế bằng các quy trình do mô-đun mang theo.

Đ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 cần có chứng nhận FIPS 140-3. 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ó thể ả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. Thao tác này sẽ 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 được init tải khi thiết bị khởi động.

Quy trình tự kiểm tra tính toàn vẹn

Mô-đun nhân FIPS 140-3 lấy chuỗi đại diện HMAC-SHA256 của các phần .code và .rodata tại thời điểm tải mô-đun, đồng thời so sánh chuỗi đại diện đó với chuỗi đại diện được ghi trong mô-đun. Quy trình 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ý việc di dời ELF và vá lỗi thay thế cho các lỗi CPU ở các phần đó. Bạn cần thực hiện thêm các bước sau để đảm bảo có thể tái tạo chính xác chuỗi đại diện:

• Việc di dời ELF được giữ nguyên bên trong mô-đun để có thể áp dụng ngược lại cho dữ liệu đầu vào của HMAC.
• Mô-đun đả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 lệnh đẩy hoặc bật từ ngăn xếp lệnh gọi bóng bằng các lệnh Mã xác thực con trỏ (PAC) vốn có.
• Tất cả các bản vá mã khác đều bị tắt đối với mô-đun này, bao gồm cả các khoá tĩnh và do đó cả các điểm theo dõi cũng như các hook của nhà cung cấp.

Các bài kiểm tra tự trả lời đã biết trước

Mọi thuật toán đã triển khai được đề cập trong các yêu cầu của FIPS 140-3 đều phải thực hiện bài kiểm tra tự trả lời đã biết trước trước khi được sử dụng. Theo FIPS 140-3 Hướng dẫn triển khai 10.3.A, một vectơ kiểm thử duy nhất cho mỗi thuật toán sử dụng bất kỳ độ dài khoá được hỗ trợ nào là đủ cho các thuật toán 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 triển khai sử dụng các lệnh mật mã đặc biệt và một cách triển khai dự phòng cho các CPU không triển khai các lệnh đó) 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 việc lựa chọn dựa trên mức độ ưu tiên và chọn một thuật toán có mức độ ưu tiên thấp hơ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 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 nhân được ghi chú khi thích hợp.

Thuật toán	Chi tiết 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ật mã khối AES thuần tuý, không có chế độ hoạt động: Tất cả các kích thước khoá (128 bit, 192 bit và 256 bit) đều được hỗ trợ. Bạn có thể kết hợp tất cả các cách triển khai khác ngoài cách triển khai thư viện với 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ể kết hợp mẫu cmac với bất kỳ cách triển khai nào của 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ể kết hợp mẫu ecb với bất kỳ cách triển khai nào của 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ể kết hợp mẫu cbc với bất kỳ cách triển khai nào của 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 với 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 được hoán đổi vô điều kiện. Tất cả các kích thước khoá AES đều được hỗ trợ.Mẫu cts có thể được kết hợp với bất kỳ cách triển khai nào của 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: Tất cả các kích thước khoá AES đều được hỗ trợ. Bạn có thể kết hợp mẫu ctr với bất kỳ cách triển khai nào của 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ể kết hợp mẫu xts với bất kỳ cách triển khai nào của 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 cách 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: Tất cả các kích thước khoá AES đều được hỗ trợ. Chỉ các IV 96 bit được hỗ trợ. Giố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 các IV. Bạn có thể kết hợp mẫu gcm với bất kỳ cách triển khai nào của 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 cách 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 phiên bản kernel 6.6 trở lên.
sha3-256	sha3-256-generic	Có	Tương tự như trên, nhưng có độ dài chuỗi đại diện là 256 bit (SHA3-256). Tất cả các độ dài chuỗi đại diện đều sử dụng cùng một cách triển khai Keccak.
sha3-384	sha3-384-generic	Có	Tương tự như trên, nhưng có độ dài chuỗi đại diện là 384 bit (SHA3-384). Tất cả các độ dài chuỗi đại diện đều sử dụng cùng một cách triển khai Keccak.
sha3-512	sha3-512-generic	Có	Tương tự như trên, nhưng có độ dài chuỗi đại diện là 512 bit (SHA3-512). Tất cả các độ dài chuỗi đại diện đều sử dụng cùng một cách triển khai Keccak.
hmac	hmac (mẫu)	Có	HMAC (Mã xác thực thông báo được khoá): Bạn có thể kết hợp mẫu hmac với bất kỳ thuật toán hoặc cách 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à bật tính năng chống dự đoán: Các quy trình kiểm tra tình trạng được đưa vào. Người dùng giao diện này sẽ nhận đượ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 dự đoán. Mã này được chia sẻ với biến thể 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 phiên bản kernel 5.15 trở lên, đó là drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Không	Jitter RNG, phiên bản 2.2.0 (phiên bản nhân 6.1 trở xuống) hoặc phiên bản 3.4.0 (phiên bản nhân 6.6 trở lên). Người dùng giao diện này sẽ nhận được các thực thể Jitter RNG riêng. Họ 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 phiên bản kernel 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 (phiên bản cũ):

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

Các lệnh này thực hiện toàn bộ quy trình tạo bản dựng, bao gồm cả nhân hệ điều hành và mô-đun fips140.ko có nội dung chuỗi đại diện HMAC-SHA256 được nhúng trong đó.

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

Hướng dẫn cho Nhân viên mật mã

Để vận hành mô-đun nhân, hệ điều hành phải bị hạn chế ở một chế độ vận hành duy nhất. Android 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 mô-đun nhân riêng; mô-đun này được đưa vào chương trình cơ sở của thiết bị và tự động tải khi khởi động. Mô-đun này chỉ hoạt động ở chế độ vận hành đã được phê duyệt.

Nhân viên mật mã có thể chạy các bài kiểm tra tự động 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 nhân là các thành phần nhân khác cần sử dụng thuật toán mật mã. Mô-đun nhân không cung cấp thêm logic trong việc 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 thao tác mật mã.

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ụ" của 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 kiểm tra tự động

Trong trường hợp kiểm tra tự động thất bại trong kiểm thử, 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 thiết bị.