Để phù hợp với mô hình phát triển ổn định của nhánh chính và đảm bảo tính ổn định của nền tảng cho hệ sinh thái, chúng tôi sẽ xuất bản mã nguồn lên AOSP vào quý 2 và quý 4 năm 2026. Để tạo và đóng góp cho AOSP, hãy sử dụng android-latest-release. Nhánh tệp kê khai android-latest-release sẽ luôn tham chiếu đến bản phát hành gần đây nhất được chuyển đến AOSP. Để biết thêm thông tin, hãy xem bài viết Các thay đổi đối với AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Cụ thể, bạn phải đáp ứng các yêu cầu sau đây theo tiêu chuẩn 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 thuật toán mật mã trước khi cung cấp các thuật toán đó.

Tại sao cần 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ật mã học nhất có thể, nhằm đảm bảo rằng những thay đổi không liên quan đến mật mã học không yêu cầu đánh giá lại mật mã học.

Nhân GKI dự kiến sẽ được cập nhật thường xuyên trong suốt vòng đời được hỗ trợ. Điều này khiến toàn bộ hạt 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 hạ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 nhưng không giải quyết được vấn đề này, 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 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 hạt nhân riêng biệt fips140.ko. Mô-đun này chỉ dựa vào các giao diện ổn định do nguồn hạt nhân 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 theo 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 thực sự không đượ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ã 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ó 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. Việc 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 này 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 đối với đầ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ả 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ác điểm theo dõi cũng như các lệnh gọi của nhà cung cấp.

Quy trình tự kiểm tra thuật toán mật mã

Mô-đun hạt nhân FIPS 140-3 đáp ứng các yêu cầu tự kiểm tra thuật toán mật mã của FIPS 140-3 bằng cách triển khai các kiểm thử câu trả lời đã biết. Các kiểm thử đã triển khai sẽ khác nhau theo thuật toán và tuân thủ Hướng dẫn triển khai FIPS 140-3 10.3.A.

Thông thường, mỗi thuật toán chỉ cần một vectơ kiểm thử duy nhất. Các quy trình tự kiểm thử thuật toán mật mã FIPS chỉ được thiết kế để xác thực chức năng cơ bản. Quy trình kiểm thử toàn diện diễn ra riêng biệt, sử dụng Chương trình xác thực thuật toán mật mã (CAVP) và bộ kiểm thử mật mã của nhân nguồn trên.

Khi một thuật toán có nhiều cách triển khai mà người dùng có thể truy cập hoặc được các dịch vụ của mô-đun sử dụng, FIPS 140-3 yêu cầu tất cả các cách triển khai đó phải tự kiểm tra. Điều này có liên quan đến chiến lược tích hợp thường được Linux CryptoAPI sử dụng, trong đó mỗi thuật toán có thể có nhiều cách triển khai mà người dùng có thể truy cập. Ví dụ: trong nhân android16-6.12, SHA-256 có 3 cách triển khai: sha256-generic, sha256-arm64 và sha256-ce. Trên các CPU có tiện ích mã hoá ARMv8, sha256-ce được dùng theo mặc định, nhưng người dùng vẫn có thể truy cập vào các tiện ích khác một cách rõ ràng. Do đó, mô-đun tự kiểm thử cả 3 cách triển khai.

Trong nhân android17-6.18 trở lên, một số thuật toán sử dụng chiến lược tích hợp đơn giản hơn. Ví dụ: trong nhân android17-6.18, SHA-256 có một quy trình triển khai duy nhất sha256-lib, tự động chọn mã thích hợp cho CPU tại thời điểm tải mô-đun. Do đó, mô-đun này chỉ tự kiểm thử sha256-lib.

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, android15-6.6, android16-6.12 và android17-6.18, mặc dù sự khác biệt giữa các phiên bản hạt nhân đượ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()`. 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: Hỗ trợ tất cả các kích thước khoá AES. 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()`. 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 `cbc()`. 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ệ thống hỗ trợ tất cả các kích thước khoá AES. Bạn có thể tạo mẫu `cts` bằng mọi cách triển khai `cbc` bằng cách sử dụng `cts()`. 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ể tạo mẫu `ctr` bằng mọi cách triển khai `aes` bằng cách sử dụng `ctr()`. 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 nhân 6.1 trở xuống, tất cả các kích thước khoá AES đều được hỗ trợ; trong nhân 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()`. Các cách triển khai khác là độc lập. Tất cả các hoạt động triển khai đều thực hiện 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ông ¹	AES-GCM: Hỗ trợ tất cả các kích thước khoá AES. Chỉ hỗ trợ IV 96 bit. 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(,)`. Các cách triển khai khác là độc lập.
`sha1`	Kernel 6.12 trở xuống: `sha1-generic`, `sha1-ce`	Có	Hàm băm mật mã SHA-1. Đã xoá trong kernel 6.18 trở lên.
`sha224`	Kernel 6.18 trở lên: `sha224-lib`. Kernel 6.12 trở xuống: `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`	Kernel 6.18 trở lên: `sha256-lib`. Kernel 6.12 trở xuống: `sha256-generic`, `sha256-arm64`, `sha256-ce`, thư viện SHA-256	Có	Hàm băm mật mã SHA-256.
`sha384`	Kernel 6.18 trở lên: `sha384-lib`. Kernel 6.12 trở xuống: `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`	Kernel 6.18 trở lên: `sha512-lib`. Kernel 6.12 trở xuống: `sha512-generic`, `sha512-arm64`, `sha512-ce`	Có	Hàm băm mật mã SHA-512.
`sha3-224`	Kernel 6.6 trở lên: `sha3-224-generic`	Có	Hàm băm mật mã SHA3-224.
`sha3-256`	Kernel 6.6 trở lên: `sha3-256-generic`	Có	Tương tự như trên, nhưng có độ dài thông báo 256 bit (SHA3-256). Tất cả độ dài của hàm băm đều sử dụng cùng một phương thức triển khai Keccak.
`sha3-384`	Kernel 6.6 trở lên: `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 hàm băm đều sử dụng cùng một phương thức triển khai Keccak.
`sha3-512`	Kernel 6.6 trở lên: `sha3-512-generic`	Có	Tương tự như trên, nhưng có độ dài thông báo là 512 bit (SHA3-512). Tất cả độ dài của hàm băm đều sử dụng cùng một phương thức triển khai Keccak.
`hmac`	`hmac` (mẫu)	Có	Mã xác thực thông báo băm khoá (HMAC): 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()` hoặc `hmac()`.
`stdrng`	Tất cả các nhân: `drbg_pr_hmac_sha256`, `drbg_pr_hmac_sha384`, `drbg_pr_hmac_sha512`. Kernel 6.6 trở xuống: `drbg_pr_hmac_sha1`	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ẽ nhận được các thực thể DRBG riêng.
`stdrng`	Tất cả các nhân: `drbg_nopr_hmac_sha256`, `drbg_nopr_hmac_sha384`, `drbg_nopr_hmac_sha512`. Kernel 6.6 trở xuống: `drbg_nopr_hmac_sha1`	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 nhân 5.10, DRBG có mức độ ưu tiên cao nhất là `drbg_nopr_hmac_sha256`. Trong 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 kernel 6.1 trở xuống) hoặc phiên bản 3.4.0 (phiên bản kernel 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)`	Kernel 5.15 trở lên: `xctr-aes-neon`, `xctr-aes-ce`	Không
`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

^1. Các phương thức triển khai AES-GCM của mô-đun có thể được phê duyệt thuật toán nhưng không được phê duyệt mô-đun. Bạn có thể xác thực các thuật toán này, nhưng AES-GCM không được coi là một thuật toán đã được phê duyệt theo quan điểm của mô-đun FIPS. Nguyên nhân là do các yêu cầu về mô-đun FIPS đối với GCM không tương thích với những cách triển khai GCM không tạo IV riê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 có 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 Crypto Officer

Để vận hành mô-đun hạt nhân, 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ật mã 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 sự cố 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ị.