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

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ã. Bạn có thể gửi mô-đun này để được chứng nhận theo tiêu chuẩn FIPS nếu sản phẩm chạy hạt nhân GKI yêu cầu.

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 đó.

Lý do sử dụng mô-đun nhân riêng

Quy trình xác thực theo tiêu chuẩn 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, 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 đó, 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ã hoá, để đảm bảo rằng những thay đổi không liên quan đến mật mã học cũng không cần phải đánh giá lại quy trình mã hoá.

Hạt nhân GKI được dự kiến sẽ được cập nhật thường xuyên trong toàn bộ thời gian hoạt động đượ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 đó 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 ảnh nhân sẽ giảm thiểu vấn đề này nhưng không giải quyết được vấn đề, 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 với tính năng LTO (Tối ưu hoá thời gian liên kết) được bật, vì LTO là điều kiện tiên quyết để Kiểm soát tính toàn vẹn của luồng, đây là một tính năng bảo mật quan trọng.

Do đó, tất cả mã thuộc phạm vi của các yêu cầu FIPS 140-3 sẽ được đóng gói thành một mô-đun nhân hệ điều hành fips140.ko riêng biệt, chỉ dựa vào các giao diện ổn định do nguồn hạt nhân GKI hiển thị mà mô-đun đó được tạo từ đó. Đ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ự mang mã phụ thuộc vào các quy trình mã hoá cũng được đóng gói vào mô-đun hạt nhân FIPS 140-3. Do đó, các quy trình mã hoá tích hợp sẵn không thực sự được di 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ể đưa mô-đun này vào bản dựng Android bằng 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. Thao tác này sẽ thêm tên mô-đun 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 đó. 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:

  • 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 hạt nhân tạo ra cho Ngăn xếp lệnh gọi bóng động. Cụ thể, mô-đun này thay thế mọi lệnh đẩy hoặc bật lên 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) ban đầu.
  • Tất cả các hoạt động vá mã khác đều bị vô hiệu hoá cho mô-đun, bao gồm cả khoá tĩnh và do đó là các điểm theo dõi cũng như các trình bổ trợ của nhà cung cấp.

Quy trình tự kiểm tra đáp án đã biết

Mọi thuật toán đã triển khai thuộc phạm vi của các yêu cầu FIPS 140-3 đều phải thực hiện một quy trình tự kiểm thử câu trả lời đã biết trước khi được sử dụng. Theo Hướng dẫn triển khai 10.3.A của FIPS 140-3, 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 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 ưu tiên thuật toán, trong đó một số phương thức triển khai (chẳng hạn như một phương thức sử dụng các lệnh mã hoá đặc biệt và một phương án 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 đó, 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 bỏ qua lựa chọn dựa trên mức độ ưu tiên và thay vào đó, 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 đượ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ể phê duyệt Định nghĩa
aes aes-generic, aes-arm64, aes-ce, thư viện AES Có Mã hoá khối AES đơn giản, 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ể biên soạn 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 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ả 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ể kết hợp mẫu ecb với bất kỳ cách triển khai aes nào bằng ecb(<aes-impl>). Các phương thức 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 được sử dụng là CS3; 2 khối mật mã cuối cùng được hoán đổi vô điều kiện. Hỗ trợ tất cả kích thước khoá AES.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ể kết hợp mẫu ctr với bất kỳ cách triển khai aes nào bằ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 hạt nhân 6.1 trở xuống, tất cả kích thước khoá AES đều được hỗ trợ; trong phiên bản hạt nhân 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 phương thức 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ỉ 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 sha256-generic, sha256-arm64, sha256-ce, thư viện 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 cách triển khai Keccak.
sha3-384 sha3-384-generic Có Giống 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 cách 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 cách triển khai Keccak.
hmac hmac (mẫu) Có HMAC (Mã xác thực thông điệp băm được khoá): Mẫu hmac có thể được kết hợp với bất kỳ thuật toán hoặc phương thức triển khai SHA nào bằ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 thực thể bằng hàm băm được đặt tên và bật tính năng đề kháng dự đoán: Bao gồm các bước kiểm tra tình trạng. Người dùng giao diện này sẽ nhận được các phiên bản 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ư 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 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 thực thể Jitter RNG 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

  • 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 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 dành 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 tự động xử lý việc này bằng cách 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 nhân; mô-đun này nằm trong chương trình cơ sở của thiết bị và được tải tự động 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 của 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ã hoá. Mô-đun nhân không cung cấp logic bổ sung khi sử dụng 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ã hoá.

Việc sử dụng các thuật toán cho mục đích tuân thủ FIPS chỉ được giới hạn ở các thuật toán được phê duyệt. Để đáp ứng yêu cầu về "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 tự kiểm tra

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

  1. Dự kiến, việc triển khai AES-GCM của mô-đun có thể là "thuật toán được phê duyệt" nhưng không phải là "mô-đun được phê duyệt". Bạn có thể xác thực các thuật toán này, nhưng không thể coi AES-GCM 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 cho GCM không tương thích với các phương thức triển khai GCM không tạo IV của riêng mình. ↩