Mô-đun mật mã GKI có thể chứng nhận 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ã hoá. Bạn có thể gửi mô-đun này để lấy chứng nhận FIPS nếu sản phẩm chạy nhân GKI yêu cầu mô-đun đó.

Cụ thể, bạn phải đáp ứng các yêu cầu cụ thể 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 mình trước khi cung cấp 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 phương thức tự kiểm thử trả lời đã biết trước khi cung cấp.

Tại sao cần có mô-đun nhân hệ điều hành 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ột 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 có thay đổi, thì URL đó 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 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 thì không cần phải đánh giá lại phương thức mã hoá.

Nhân GKI 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ộ nhân hệ điều hành không thể nằm trong ranh giới mô-đun FIPS, vì một 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 ảnh nhân sẽ giảm thiểu vấn đề này nhưng không giải quyết được, 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 khác cần cân nhắc là GKI được biên dịch khi bật LTO (Link Time Optimization) vì LTO là điều kiện tiên quyết để Kiểm soát tính toàn vẹn của flow. Đây là một tính năng bảo mật quan trọng.

Do đó, tất cả mã chịu sự điều chỉnh 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 riêng biệt fips140.ko. Mô-đun này chỉ dựa trên 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 đảm bảo rằng 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ùng một thế hệ, đồng thời chỉ được cập nhật và gửi lại mô-đun để chứng nhận nếu bạn đã khắc phục mọi vấn đề trong mã do chính mô-đun đó mang theo.

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 nhân FIPS 140-3. Do đó, các lộ 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ật mã tích hợp sẵn sẽ bị huỷ đăng ký khỏi Linux CryptoAPI và được thay thế bằng các quy trình do mô-đun cung cấp.

Đ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 bắt buộc phải có chứng chỉ FIPS 140-3. Ngoài ra, mô-đun 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ể 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. Việc này sẽ khiến mô-đun được sao chép vào ổ đĩa ram của nhà cung cấp.
  • Thêm tên mô-đun vào BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Điều này 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.

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 riêng tại thời gian tải mô-đun, rồi so sánh với chuỗi đại diện đã ghi trong mô-đun. Việc 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ý quá trình chuyển vị trí ELF và vá các giải pháp thay thế để phân tích CPU cho các phần đó. Bạn nên thực hiện các bước bổ sung sau đây để đảm bảo có thể tái tạo chuỗi đại diện một cách chính xác:

  • Các vị trí chuyển vị trí ELF được giữ nguyên bên trong mô-đun để có thể áp dụng ngược với đầ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 Ngăn xếp lệnh gọi bóng động (Dynamic Shadow Call Stack). Cụ thể, mô-đun này sẽ thay thế mọi hướng dẫn đẩy hoặc bật lên từ ngăn xếp lệnh gọi bóng bằng hướng dẫn Mã xác thực con trỏ (PAC) có ban đầu.
  • Tất cả các bản vá mã khác đều bị tắt cho mô-đun, bao gồm cả các khoá tĩnh và điểm theo dõi cũng như các hook của nhà cung cấp.

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

Mọi thuật toán được 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 đó, bạn cần phải kiểm thử tất cả các phương thức 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 đó, 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 đư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ú nếu thích hợp.

Thuật toán Triển khai Có thể chấp nhận Đị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ợ. 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 soạ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ả các kích thước khoá AES đều được hỗ trợ. Bạn có thể tạo mẫu cmac với bất kỳ cách triển khai nào của aes bằ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ả 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ể tạo mẫu cbc với bất kỳ cách triển khai nào của aes bằ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 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 sẽ đượ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 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 với bất kỳ cách triển khai nào của aes 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 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ỉ có AES-128 và AES-256 được hỗ trợ. 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 cách triển khai khác là độc lập. Tất cả các lần 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 thứ hai bằng nhau sẽ bị từ chối.
gcm(aes) gcm (mẫu), gcm-aes-ce Số1 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 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 Thư viện sha256-generic, sha256-arm64, sha256-ce, SHA-256 Có Hàm băm mật mã SHA-256: Một giao diện thư viện được cung cấp cho SHA-256 ngoài giao diện CryptoAPI truyền thống. 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ước, nhưng có độ dài thông báo 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ó Giống 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 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ó Giống như các thuật toán drbg_pr_*, nhưng với tính năng đề kháng dự đoán đang tắt. 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 kernel phiên bản 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 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. 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.

  • Dùng Bazel để tạo bản dựng:

    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 thực hiện một bản dựng đầy đủ bao gồm hạt nhân và mô-đun fips140.ko có nội dung chuỗi đại diện 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 nhân, hệ điều hành phải được hạn chế ở một chế độ hoạt động duy nhất của toán tử. Việc này được Android xử lý tự động 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 chỉ hoạt động ở chế độ hoạt động đã được phê duyệt.

Chuyên viên mã hoá có thể kích hoạt quá trình tự kiểm thử bất cứ lúc nào bằng cách khởi động lại thiết bị.

Hướng dẫn 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 thuật toán để tuân thủ FIPS đượ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ụ" FIPS 140-3, mô-đun này sẽ cung cấp một hàm fips140_is_approved_service cho biết liệu 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 thử không thành công, mô-đun hạt nhân sẽ khiến hạt nhân 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ể được "phê duyệt" chứ không phải "được phê duyệt mô-đun". Các thuật toán này có thể được xác thực, nhưng không thể xem AES-GCM là thuật toán được phê duyệt từ quan điểm mô-đun FIPS. Điều này là do các yêu cầu về mô-đun FIPS cho GCM không tương thích với những cách triển khai GCM không tạo IV của riêng họ. ↩