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

Hạt nhân GKI bao gồm Mô-đun nhân Linux có tên là fips140.ko tuân thủ Yêu cầu của FIPS 140-3 cho các mô-đun phần mềm mã hoá. 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ác yêu cầu cụ thể theo FIPS 140-3 sau đây phải được đáp ứng trước quy trình mã hoá có thể được sử dụng:

  • Mô-đun phải kiểm tra tính toàn vẹn của chính mình trước khi tạo thuật toán mật mã sẵn có.
  • Mô-đun phải thực thi và xác minh các thuật toán mật mã được phê duyệt bằng cách sử dụng phương pháp tự kiểm tra có câu trả lời đã biết trước khi cung cấp chúng.

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, thông tin này phải được chứng nhận lại. Điều này chưa phù hợp với các quy trình phát triển phần mềm trong sử dụng hiện nay, và 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ã có thể, để đảm bảo rằng những thay đổi không liên quan đến mật mã học chúng tôi cần đá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ộ 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. Định nghĩa "mô-đun FIPS" là tập con của hình ảnh hạt 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 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 đó. Chiến dịch này đảm bảo rằng mô-đun có thể được sử dụng với các bản phát hành GKI khác nhau của cùng một tạo, và bạn phải cập nhật rồi gửi lại chỉ để lấy chứng nhận liệu có vấn đề nào được khắc phục trong mã do chính mô-đun đó thực hiện hay không.

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ật mã tích hợp sẵn sẽ đã huỷ đăng ký khỏi Linux CryptoAPI và được thay thế bằng những API do .

Điều này có nghĩa là mô-đun fips140.ko là hoàn toàn không bắt buộc và chỉ tạo nếu bắt buộc phải có chứng chỉ FIPS 140-3. Ngoài ra, mô-đun này không cung cấp chức năng bổ sung nào và việc tải mô-đun 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. Điều này 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. 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 chứa danh sách các mô-đun được init tải khi thiết bị.

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 .code riêng và .rodata tại thời gian tải mô-đun rồi so sánh 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 một số sửa đổi thông thường như xử lý quy trình di dời ELF và bản vá thay thế cho bản vá 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 vị trí chuyển vị trí ELF được giữ nguyên bên trong mô-đun để có thể áp dụng trong đảo 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 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.

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 áp dụng của các yêu cầu FIPS 140-3 đều phải tự kiểm tra câu trả lời đã biết trước khi 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 phải kiểm thử tất cả các phương pháp triển khai 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 android12-5.10, android13-5.10, android13-5.15, Tuy nhiên, android14-5.15, android14-6.1 và android15-6.6 nhánh hạt nhân 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 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 á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 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ỉ 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 cách 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 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 android-mainline), tạo mô-đun fips140.ko từ nguồn bằng cách sử dụ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 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 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 giới hạn ở chế độ hoạt động của một 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ý.

Không thể cài đặt riêng mô-đun nhân; dữ liệu này có trong chương trình cơ sở của thiết bị và tự động tải khi khởi động. Tài khoản này chỉ hoạt động trong phương thức hoạt động được phê duyệt.

Chuyên viên tiề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 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 cho 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 thiết bị khởi động lại không giải quyết được sự cố, thiết bị phải khởi động vào chế độ khôi phục để sửa 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 đã phê duyệt" nhưng không "mô-đun được phê duyệt". Có thể xác thực các mã, nhưng AES-GCM không thể được coi là thuật toán được phê duyệt xét trên quan điểm mô-đun FIPS. Điều này là do các yêu cầu mô-đun FIPS cho GCM không tương thích với Những phương pháp triển khai GCM không tạo IV của riêng mình. ↩