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

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Hạt nhân GKI bao gồm một mô-đun hạt 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ã. Có thể gửi mô-đun này cho FIPS nếu sản phẩm chạy nhân GKI yêu cầu chứng chỉ đó.

Cụ thể, bạn phải đáp ứng các yêu cầu sau đây của FIPS 140-3 thì mới 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 thi và xác minh các thuật toán mã hoá đã phê duyệt bằng cách sử dụng tính năng tự kiểm tra có 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ô-đun nhân hệ điều hành riêng biệt

Việc xác thực FIPS 140-3 dựa trên ý tưởng rằng một khi một phần mềm hoặc phần cứng đã được chứng nhận thì 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 mã hoá không yêu cầu đánh giá lại mã hoá.

Nhân GKI dự kiến sẽ được cập nhật thường xuyên trong toàn bộ quá trình hỗ trợ vòng đời của thiết bị. Điều này khiến toàn bộ nhân hệ điều hành không thể nằm trong FIPS ranh giới của mô-đun, vì một mô-đun như vậy cần được chứng nhận lại sau mỗi nhân cập nhật. 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úp giảm thiểu vấn đề này 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 cần thiết.

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

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

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

Hạt nhân GKI tự chứa mã phụ thuộc vào quy trình mã hoá cũng được đóng gói vào mô-đun nhân FIPS 140-3. Do đó, mã hoá tích hợp sẵn các quy trình không thực sự được chuyển ra khỏi hạt 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ẽ bị 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 yêu cầu chứng nhận FIPS 140-3. Ngoài ra, mô-đun này không cung cấp thêm tính 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ể tích hợp mô-đun này vào bản dựng Android qua các bước sau:

• Thêm tên mô-đun vào BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Điều 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. Chiến dịch này khiến tên mô-đun được thêm vào modules.load trên mục tiêu. modules.load lưu giữ danh sách các mô-đun do 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 chuỗi đại diện HMAC-SHA256 của các phần .code và .rodata của chính mô-đun đó tại thời điểm tải mô-đun và so sánh chuỗi đại diện đó với chuỗi đại diện được ghi lại trong mô-đun. Quá 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 như xử lý di chuyển ELF và vá các thay thế cho lỗi CPU cho các phần đó. Nội dung sau đây thực hiện các bước bổ sung để đảm bảo rằng chuỗi đại diện có thể được tái tạo chính xác:

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

Bài kiểm tra tự đánh giá có câu trả lời đã biết

Mọi thuật toán đã triển khai thuộc phạm vi yêu cầu của FIPS 140-3 đều phải thực hiện kiểm thử tự động có câu trả lời đã biết 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 tra duy nhất cho mỗi thuật toán sử dụng bất kỳ độ dài khoá nào được hỗ trợ là đủ cho thuật toán mật mã, miễn là cả quá trình mã hoá và giải mã đều được kiểm tra.

Linux CryptoAPI có khái niệm ưu tiên thuật toán, trong đó một số những cách triển khai (chẳng hạn như một cách sử dụng các hướng dẫn đặc biệt về mật mã và một phương thức dự phòng) đối với những 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 đó, cần kiểm thử tất cả các cách triển khai cùng một thuật toán. Điều này là cần thiết vì Linux CryptoAPI cho phép mức độ ưu tiên lựa chọn dựa trên bị bỏ qua và để thuật toán có mức độ ưu tiên thấp hơn bị bỏ qua đã chọn thay thế.

Các thuật toán được đưa vào mô-đun

Tất cả các thuật toán có trong mô-đun FIPS 140-3 đượ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	Cách triển khai	Có thể chấp nhận	Đị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: Tất cả kích thước khoá (128 bit, 192 bit và 256 bit) đều được hỗ trợ. Tất cả các phương thức triển khai khác ngoài phương thức triển khai thư viện đều có thể được kết hợp 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ả 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 aes nào bằng cmac(<aes-impl>). Các phương thức 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ả kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu ecb với bất kỳ cách triển khai nào của aes bằ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ả 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 aes nào bằng ctr(<aes-impl>). Các phương thức 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 bị đánh cắp mật mã: Quy ước áp dụng là CS3; hai khối mật mã cuối cùng được hoán đổi vô điều kiện.Tất cả kích thước khoá AES đều được hỗ trợ.Bạn có thể tạo mẫu cts với bất kỳ cách triển khai nào của cbc bằng cts(<cbc(aes)-impl>). Các phương thức 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ả kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu ctr với bất kỳ cách triển khai nào của aes bằng ctr(<aes-impl>). Các phương thức 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ỉ hỗ trợ AES-128 và AES-256. Bạn có thể tạo mẫu xts với bất kỳ cách triển khai nào của ecb(aes) bằng xts(<ecb(aes)-impl>). Các phương thức triển khai khác là độc lập. Tất cả các hoạt động triển khai đều triển khai tính năng kiểm tra khoá yếu theo yêu cầu của FIPS; tức là các khoá XTS có nửa thứ nhất và nửa thứ hai bằng nhau sẽ bị từ chối.
gcm(aes)	gcm (mẫu), gcm-aes-ce	Không1	AES-GCM: Tất cả kích thước khoá AES đều được hỗ trợ. Chỉ hỗ trợ IV 96 bit. Giống như tất cả chế độ AES khác trong mô-đun này, phương thức gọi chịu trách nhiệm cung cấp IV. Bạn có thể tạo mẫu gcm với bất kỳ cách triển khai nào của ctr(aes) và ghash bằng gcm_base(<ctr(aes)-impl>,<ghash-impl>). Các phương thức 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	Thư viện sha256-generic, sha256-arm64, sha256-ce, SHA-256	Có	Hàm băm mật mã SHA-256: Ngoài giao diện CryptoAPI tiêu chuẩn, một giao diện thư viện cũng được cung cấp cho SHA-256. 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 hạt nhân phiên bản 6.6 trở lên.
sha3-256	sha3-256-generic	Có	Tương tự như trước, nhưng có độ dài chuỗi đại diện 256 bit (SHA3-256). Tất cả độ dài chuỗi đại diện đề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ước, nhưng có độ dài chuỗi đại diện 384 bit (SHA3-384). Tất cả độ dài chuỗi đại diện đề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ước, nhưng có độ dài chuỗi đại diện 512 bit (SHA3-512). Tất cả độ dài chuỗi đại diện đề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 khoá): Bạn có thể tạo mẫu hmac bằng bất kỳ thuật toán SHA hoặc phương thức triển khai 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 tạo bản sao bằng hàm băm được đặt tên và bật tính năng chống dự đoán: Bao gồm cả tính năng 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ó	Giống như các thuật toán drbg_pr_*, nhưng với tính năng đề xuất bị vô hiệu hoá. Mã này được chia sẻ với biến thể chống dự đoán. Trong kernel phiên bản 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, mã này 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 hệ điều hành 6.1 trở xuống) hoặc phiên bản 3.4.0 (phiên bản nhân hệ điều hành 6.6 trở lên). Người dùng giao diện này sẽ nhận được các phiên bản RNG Jitter riêng. Các hàm này 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 hạt nhân 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

• Dùng build.sh (cũ):

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

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

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

Hướng dẫn dành cho Chuyên viên tiền mã hoá

Để vận hành mô-đun hạt nhân, hệ điều hành phải bị hạn chế ở một chế độ hoạt động của toán tử. Android sẽ tự động xử lý sử dụ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 hạt nhân; mô-đun này được đưa vào phần mềm cơ sở của thiết bị và tự động tải khi khởi động. Ứng dụng này chỉ hoạt động ở một chế độ hoạt động được phê duyệt.

Người quản lý mã hoá có thể chạy 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 dành cho người dùng

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

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

Lỗi tự kiểm tra

Trong trường hợp tự kiểm thử không thành công, mô-đun nhân sẽ khiến nhân hệ điều hành hoảng loạn và thiết bị không tiếp tục khởi động được. 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 vào chế độ khôi phục để khắc phục vấn đề bằng cách cài đặt lại ROM cho thiết bị.