โมดูลคริปโตเคอเรนซี GKI ที่ได้รับการรับรอง FIPS 140-3

เคอร์เนล GKI มีโมดูลเคอร์เนล Linux ชื่อ fips140.ko ที่เป็นไปตามข้อกำหนด FIPS 140-3 สำหรับโมดูลซอฟต์แวร์การเข้ารหัสลับ คุณส่งโมดูลนี้เพื่อขอรับการรับรอง FIPS ได้ หากผลิตภัณฑ์ที่ใช้งานเคอร์เนล GKI กำหนดให้ต้องระบุ

โดยเฉพาะอย่างยิ่ง คุณต้องปฏิบัติตามข้อกําหนด FIPS 140-3 ต่อไปนี้ก่อนจึงจะใช้รูทีนการเข้ารหัสได้

• โมดูลต้องตรวจสอบความสมบูรณ์ของตนเองก่อนทำให้อัลกอริทึมการเข้ารหัสพร้อมใช้งาน
• โมดูลนี้ต้องใช้และยืนยันอัลกอริทึมการเข้ารหัสที่ได้รับการอนุมัติโดยใช้การทดสอบคำตอบที่ทราบด้วยตนเองก่อนที่จะเปิดให้ใช้งาน

เหตุใดจึงต้องมีโมดูลเคอร์เนลแยกต่างหาก

การตรวจสอบ FIPS 140-3 อิงตามแนวคิดที่ว่าเมื่อโมดูลที่ใช้ซอฟต์แวร์หรือฮาร์ดแวร์ได้รับการรับรองแล้ว จะไม่มีการเปลี่ยนแปลงใดๆ หากมีการเปลี่ยนแปลง จะต้องได้รับการรับรองอีกครั้ง ซึ่งไม่ตรงกับกระบวนการพัฒนาซอฟต์แวร์ที่ใช้ในปัจจุบัน และข้อกำหนดนี้ส่งผลให้โดยทั่วไปแล้วโมดูลซอฟต์แวร์ FIPS ได้รับการออกแบบให้มุ่งเน้นที่คอมโพเนนต์การเข้ารหัสอย่างเข้มข้นที่สุดเท่าที่จะเป็นไปได้ เพื่อให้มั่นใจว่าการเปลี่ยนแปลงที่ไม่เกี่ยวข้องกับการเข้ารหัสจะไม่จําเป็นต้องประเมินการเข้ารหัสอีกครั้ง

เคอร์เนล GKI มีไว้เพื่อการอัปเดตอย่างสม่ำเสมอตลอดอายุการสนับสนุนทั้งหมด ด้วยเหตุนี้ จึงทำให้เคอร์เนลทั้งหมดอยู่ภายในขอบเขตของโมดูล FIPS ไม่ได้ เนื่องจากโมดูลดังกล่าวจะต้องได้รับการรับรองอีกครั้งทุกครั้งที่มีการอัปเดตเคอร์เนล การกำหนด "โมดูล FIPS" เป็นส่วนย่อยของอิมเมจเคอร์เนลจะช่วยลดปัญหานี้ได้แต่จะแก้ปัญหาไม่ได้ เนื่องจากเนื้อหาไบนารีของ "โมดูล FIPS" ยังคงมีการเปลี่ยนแปลงบ่อยกว่าที่จำเป็นมาก

ก่อนใช้เคอร์เนลเวอร์ชัน 6.1 ข้อควรพิจารณาอีกประการหนึ่งคือ GKI ได้รับการคอมไพล์โดยเปิดใช้ LTO (Link Time Optimization) เนื่องจาก LTO เป็นข้อกําหนดเบื้องต้นสําหรับ Control Flow Integrity ซึ่งเป็นฟีเจอร์ด้านความปลอดภัยที่สําคัญ

ดังนั้น โค้ดทั้งหมดที่อยู่ภายใต้ข้อกำหนด FIPS 140-3 จึงได้รับการจัดแพ็กเกจเป็นโมดูลเคอร์เนลแยกต่างหาก fips140.ko ซึ่งใช้เฉพาะอินเทอร์เฟซที่เสถียรซึ่งแสดงโดยซอร์สโค้ดเคอร์เนล GKI ที่ใช้สร้าง ซึ่งหมายความว่าโมดูลนี้สามารถใช้กับ GKI รุ่นต่างๆ ของรุ่นเดียวกันได้ และจะต้องอัปเดตและส่งเข้ารับการรับรองอีกครั้งก็ต่อเมื่อมีวิธีแก้ไขปัญหาในโค้ดที่โมดูลนั้นใช้

กรณีที่ควรใช้ข้อบังคับ

เคอร์เนล GKI จะมีโค้ดที่ขึ้นอยู่กับกิจวัตรคริปโตที่อยู่ในโมดูลเคอร์เนล FIPS 140-3 ด้วย ดังนั้น รูทีนการเข้ารหัสในตัวจึงไม่ได้ย้ายออกจากเคอร์เนล GKI แต่ระบบจะคัดลอกรูทีนดังกล่าวลงในโมดูล เมื่อโหลดโมดูลแล้ว ระบบจะยกเลิกการลงทะเบียนกิจวัตร Crypto ในตัวจาก Linux CryptoAPI และแทนที่ด้วยรายการที่จัดโดยโมดูล

ซึ่งหมายความว่าคุณเลือกใช้ข้อบังคับ fips140.ko หรือไม่ก็ได้ และควรเลือกใช้ก็ต่อเมื่อจำเป็นต้องได้รับการรับรอง FIPS 140-3 นอกจากนี้ โมดูลดังกล่าวไม่มีความสามารถเพิ่มเติมใดๆ และอาจส่งผลต่อเวลาในการบูตโดยไม่ให้ประโยชน์ใดๆ

วิธีทำให้โมดูลใช้งานได้

คุณรวมโมดูลไว้ในบิลด์ Android ได้โดยทำตามขั้นตอนต่อไปนี้

• เพิ่มชื่อโมดูลลงใน BOARD_VENDOR_RAMDISK_KERNEL_MODULES ซึ่งจะทําให้ระบบคัดลอกข้อบังคับไปยัง RAMdisk ของผู้ให้บริการ
• เพิ่มชื่อโมดูลลงใน BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD ซึ่งจะทําให้ระบบเพิ่มชื่อโมดูลลงใน modules.load บนเป้าหมาย modules.load เก็บรายการโมดูลที่ init โหลดเมื่ออุปกรณ์บูต

การตรวจสอบความสมบูรณ์ด้วยตนเอง

โมดูลเคอร์เนล FIPS 140-3 นำไดเจสต์ HMAC-SHA256 ของส่วน .code และ .rodata ของตัวเองไปใช้ในเวลาที่ใช้ในการโหลดของโมดูล แล้วนำไปเปรียบเทียบกับไดเจสต์ที่บันทึกในโมดูล ซึ่งจะเกิดขึ้นหลังจากที่โปรแกรมโหลดโมดูล Linux ทำการแก้ไขตามปกติแล้ว เช่น การดำเนินการย้ายข้อมูล ELF และการแก้ไขทางเลือกสำหรับข้อผิดพลาดของ CPU ในส่วนเหล่านั้น คุณต้องทำตามขั้นตอนเพิ่มเติมต่อไปนี้เพื่อให้แน่ใจว่าสร้างไดเจสต์อีกครั้งได้อย่างถูกต้อง

• ระบบจะเก็บการย้ายตำแหน่ง ELF ไว้ภายในโมดูลเพื่อให้ใช้ย้อนกลับกับอินพุตของ HMAC ได้
• โมดูลจะเปลี่ยนแพตช์โค้ดที่เคอร์เนลสร้างขึ้นสำหรับสแต็กการเรียกแบบไดนามิก กล่าวคือ โมดูลจะแทนที่คำสั่งที่พุชหรือเปิดขึ้นจากสแต็กการเรียกใช้เงาด้วยคำสั่งของรหัสการตรวจสอบสิทธิ์ตัวชี้ (PAC) ที่มีอยู่แต่แรก
• การแพตช์โค้ดอื่นๆ ทั้งหมดสำหรับโมดูลจะถูกปิดใช้ รวมถึงคีย์แบบคงที่ จุดติดตาม รวมถึงฮุกของผู้ให้บริการ

การทดสอบด้วยตนเองที่มีคำตอบที่ทราบ

อัลกอริทึมที่นำมาใช้ซึ่งอยู่ภายใต้ข้อกำหนดของ FIPS 140-3 จะต้องทำการทดสอบด้วยตนเองโดยใช้คำตอบที่ทราบก่อนนำไปใช้ ตามคำแนะนำในการใช้งาน FIPS 140-3 10.3.A เวกเตอร์การทดสอบ 1 รายการต่ออัลกอริทึมโดยใช้ความยาวคีย์ใดก็ได้ที่รองรับนั้นเพียงพอสำหรับการเข้ารหัส ตราบใดที่มีการทดสอบทั้งการเข้ารหัสและการถอดรหัส

CryptoAPI ของ Linux มีแนวคิดเกี่ยวกับลําดับความสําคัญของอัลกอริทึม ซึ่งการใช้งานหลายรายการ (เช่น การใช้งานที่ใช้คำสั่งการเข้ารหัสพิเศษและสำรองสำหรับ CPU ที่ไม่ได้ใช้คำสั่งเหล่านั้น) ของอัลกอริทึมเดียวกันอาจอยู่ร่วมกันได้ ดังนั้นจึงต้องมีการทดสอบการใช้งานอัลกอริทึมเดียวกันทั้งหมด ซึ่งเป็นสิ่งจำเป็นเนื่องจาก Linux CryptoAPI อนุญาตให้มีการเลือกตามลำดับความสำคัญ และจะเลือกอัลกอริทึมที่มีลำดับความสำคัญต่ำกว่าแทน

อัลกอริทึมที่รวมอยู่ในโมดูล

อัลกอริทึมทั้งหมดที่รวมอยู่ในข้อบังคับ FIPS 140-3 มีดังนี้ ซึ่งมีผลกับสาขาเคอร์เนล android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 และ android15-6.6 แต่จะมีการระบุความแตกต่างระหว่างเวอร์ชันเคอร์เนลตามความเหมาะสม

อัลกอริทึม	การใช้งาน	อนุมัติได้	คำจำกัดความ
aes	aes-generic, aes-arm64, aes-ce, ไลบรารี AES	ใช่	การเข้ารหัส AES แบบบล็อกที่ไม่มีโหมดการทำงาน: รองรับขนาดคีย์ทั้งหมด (128 บิต, 192 บิต และ 256 บิต) การติดตั้งใช้งานทั้งหมดนอกเหนือจากการใช้งานไลบรารีอาจประกอบด้วยโหมดการทํางานผ่านเทมเพลต
cmac(aes)	cmac (เทมเพลต), cmac-aes-neon, cmac-aes-ce	ใช่	AES-CMAC: รองรับขนาดคีย์ AES ทั้งหมด เทมเพลต cmac สามารถประกอบกับการใช้งาน aes ใดก็ได้โดยใช้ cmac(<aes-impl>) การติดตั้งใช้งานอื่นๆ เป็นแบบสแตนด์อโลน
ecb(aes)	ecb (เทมเพลต), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	ใช่	AES-ECB: รองรับขนาดคีย์ AES ทั้งหมด เทมเพลต ecb สามารถประกอบกับการใช้งาน aes ใดก็ได้โดยใช้ ecb(<aes-impl>) การติดตั้งใช้งานอื่นๆ เป็นแบบสแตนด์อโลน
cbc(aes)	cbc (เทมเพลต), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	ใช่	AES-CBC: รองรับขนาดคีย์ AES ทั้งหมด เทมเพลต cbc สามารถประกอบกับการใช้งาน aes ใดก็ได้โดยใช้ ctr(<aes-impl>) การติดตั้งใช้งานอื่นๆ เป็นแบบสแตนด์อโลน
cts(cbc(aes))	cts (เทมเพลต), cts-cbc-aes-neon, cts-cbc-aes-ce	ใช่	AES-CBC-CTS หรือ AES-CBC ที่มีการขโมยข้อความที่เข้ารหัส: รูปแบบที่ใช้คือ CS3 โดยระบบจะสลับบล็อกข้อความที่เข้ารหัส 2 บล็อกสุดท้ายโดยไม่มีเงื่อนไข รองรับขนาดคีย์ AES ทั้งหมด เทมเพลต cts สามารถประกอบกับการใช้งาน cbc ใดก็ได้โดยใช้ cts(<cbc(aes)-impl>) การติดตั้งใช้งานอื่นๆ เป็นแบบสแตนด์อโลน
ctr(aes)	ctr (เทมเพลต), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	ใช่	AES-CTR: รองรับขนาดคีย์ AES ทั้งหมด เทมเพลต ctr สามารถประกอบด้วยการใช้งาน aes แบบใดก็ได้โดยใช้ ctr(<aes-impl>) การติดตั้งใช้งานอื่นๆ จะทำงานแบบสแตนด์อโลน
xts(aes)	xts (เทมเพลต), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	ใช่	AES-XTS: ในเคอร์เนลเวอร์ชัน 6.1 และต่ำกว่า ระบบจะรองรับขนาดคีย์ AES ทั้งหมด ส่วนในเคอร์เนลเวอร์ชัน 6.6 ขึ้นไป ระบบจะรองรับเฉพาะ AES-128 และ AES-256 เทมเพลต xts สามารถประกอบกับการใช้งาน ecb(aes) ใดก็ได้โดยใช้ xts(<ecb(aes)-impl>) การติดตั้งใช้งานอื่นๆ เป็นแบบสแตนด์อโลน การติดตั้งใช้งานทั้งหมดจะใช้การตรวจสอบคีย์ที่อ่อนตามที่ FIPS กำหนด กล่าวคือ ระบบจะปฏิเสธคีย์ XTS ที่ครึ่งแรกและครึ่งหลังเท่ากัน
gcm(aes)	gcm (เทมเพลต), gcm-aes-ce	ไม่1	AES-GCM: รองรับขนาดคีย์ AES ทั้งหมด รองรับเฉพาะ IV 96 บิตเท่านั้น ผู้เรียกมีหน้าที่ระบุ IV เช่นเดียวกับโหมด AES อื่นๆ ทั้งหมดในโมดูลนี้ เทมเพลต gcm สามารถประกอบด้วยการใช้งาน ctr(aes) และ ghash โดยใช้ gcm_base(<ctr(aes)-impl>,<ghash-impl>) การติดตั้งใช้งานอื่นๆ จะทำงานแบบสแตนด์อโลน
sha1	sha1-generic, sha1-ce	ใช่	ฟังก์ชันการแฮชที่เข้ารหัสลับ SHA-1
sha224	sha224-generic, sha224-arm64, sha224-ce	ใช่	ฟังก์ชันการแฮชที่เข้ารหัสลับ SHA-224: รหัสนี้ใช้ร่วมกับ SHA-256
sha256	sha256-generic, sha256-arm64, sha256-ce, ไลบรารี SHA-256	ใช่	ฟังก์ชันแฮชการเข้ารหัส SHA-256: มีอินเทอร์เฟซไลบรารีสำหรับ SHA-256 นอกเหนือจากอินเทอร์เฟซ CryptoAPI มาตรฐาน อินเทอร์เฟซของไลบรารีนี้ใช้การติดตั้งใช้งานอื่น
sha384	sha384-generic, sha384-arm64, sha384-ce	ใช่	ฟังก์ชันแฮชการเข้ารหัสลับ SHA-384: รหัสนี้ใช้ร่วมกับ SHA-512
sha512	sha512-generic, sha512-arm64, sha512-ce	ใช่	ฟังก์ชันแฮชการเข้ารหัส SHA-512
sha3-224	sha3-224-generic	ใช่	ฟังก์ชันแฮชการเข้ารหัส SHA3-224 มีเฉพาะในเคอร์เนลเวอร์ชัน 6.6 ขึ้นไป
sha3-256	sha3-256-generic	ใช่	เหมือนกับรายการก่อนหน้า แต่มีความยาวของข้อมูลสรุป 256 บิต (SHA3-256) ความยาวข้อมูลสรุปทั้งหมดใช้การใช้งาน Keccak เดียวกัน
sha3-384	sha3-384-generic	ใช่	เหมือนกับรายการก่อนหน้า แต่มีความยาวข้อมูลสรุป 384 บิต (SHA3-384) ความยาวของไดเจสต์ทั้งหมดใช้การใช้งาน Keccak เดียวกัน
sha3-512	sha3-512-generic	ใช่	เหมือนกับก่อนหน้านี้ แต่มีความยาวของไดเจสต์ 512 บิต (SHA3-512) ความยาวข้อมูลสรุปทั้งหมดใช้การใช้งาน Keccak เดียวกัน
hmac	hmac (เทมเพลต)	ใช่	HMAC (Keyed-Hash Message Authentication Code): เทมเพลต hmac สามารถเขียนด้วยอัลกอริทึม SHA หรือการใช้งานใดก็ได้โดยใช้ hmac(<sha-alg>) หรือ hmac(<sha-impl>)
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	ใช่	HMAC_DRBG สร้างอินสแตนซ์ด้วยฟังก์ชันแฮชที่มีชื่อและเปิดใช้ความต้านทานการคาดการณ์ไว้: รวมการตรวจสอบประสิทธิภาพการทำงานแล้ว ผู้ใช้อินเทอร์เฟซนี้จะได้รับอินสแตนซ์ DRBG ของตนเอง
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	ใช่	เหมือนกับอัลกอริทึม drbg_pr_* แต่ปิดใช้การต่อต้านการคาดการณ์ ระบบจะแชร์รหัสกับตัวแปรที่ทนต่อการคาดการณ์ ในเคอร์เนลเวอร์ชัน 5.10 DRBG ที่มีลำดับความสำคัญสูงสุดคือ drbg_nopr_hmac_sha256 ในเคอร์เนลเวอร์ชัน 5.15 ขึ้นไปคือ drbg_pr_hmac_sha512
jitterentropy_rng	jitterentropy_rng	ไม่	Jitter RNG เวอร์ชัน 2.2.0 (เคอร์เนลเวอร์ชัน 6.1 และต่ำกว่า) หรือเวอร์ชัน 3.4.0 (เคอร์เนลเวอร์ชัน 6.6 ขึ้นไป) ผู้ใช้อินเทอร์เฟซนี้จะได้รับอินสแตนซ์ Jitter RNG ของตนเอง โดยจะไม่นำอินสแตนซ์ที่ DRBG ใช้มาใช้ซ้ำ
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	ไม่
xctr(aes)	xctr-aes-neon, xctr-aes-ce	ไม่	มีอยู่ในเคอร์เนลเวอร์ชัน 5.15 ขึ้นไปเท่านั้น
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	ไม่
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	ไม่

สร้างโมดูลจากซอร์ส

สำหรับ Android 14 ขึ้นไป (รวมถึง android-mainline) ให้สร้างโมดูล fips140.ko จากแหล่งที่มาโดยใช้คำสั่งต่อไปนี้

• บิลด์ด้วย Bazel

  tools/bazel run //common:fips140_dist

• บิลด์ด้วย build.sh (เดิม)

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

คำสั่งเหล่านี้จะทำการบิลด์อย่างเต็มรูปแบบ ซึ่งรวมถึงเคอร์เนลและfips140.ko โมดูลที่มีเนื้อหาข้อมูลสรุป HMAC-SHA256 ฝังอยู่

คำแนะนำสำหรับผู้ใช้ปลายทาง

คำแนะนำสำหรับเจ้าหน้าที่คริปโต

หากต้องการใช้โมดูลเคอร์เนล ระบบปฏิบัติการต้องถูกจำกัดให้ทำงานในโหมดการดำเนินการแบบโอเปอเรเตอร์เดียว Android จะจัดการเรื่องนี้โดยอัตโนมัติโดยใช้ฮาร์ดแวร์การจัดการหน่วยความจำในโปรเซสเซอร์

คุณจะติดตั้งโมดูลเคอร์เนลแยกต่างหากไม่ได้ เนื่องจากโมดูลนี้รวมอยู่ในเฟิร์มแวร์ของอุปกรณ์และโหลดโดยอัตโนมัติเมื่อบูต โดยทำงานในโหมด การทำงานที่ได้รับอนุมัติเท่านั้น

เจ้าหน้าที่คริปโตสามารถเรียกใช้การทดสอบด้วยตนเองได้ทุกเมื่อโดยรีสตาร์ทอุปกรณ์

คำแนะนำสำหรับผู้ใช้

ผู้ใช้ของโมดูลเคอร์เนลคือคอมโพเนนต์อื่นๆ ของเคิร์นเนลที่ต้องใช้อัลกอริทึมการเข้ารหัส โมดูลเคอร์เนลไม่มีตรรกะเพิ่มเติมในการใช้อัลกอริทึม และจะไม่จัดเก็บพารามิเตอร์ใดๆ เกินระยะเวลาที่จําเป็นในการดําเนินการเข้ารหัสลับ

การใช้อัลกอริทึมเพื่อวัตถุประสงค์ในการปฏิบัติตามข้อกำหนด FIPS จะจำกัดไว้เฉพาะอัลกอริทึมที่ผ่านการอนุมัติเท่านั้น โมดูลนี้มีฟังก์ชัน fips140_is_approved_service ที่ระบุว่าอัลกอริทึมได้รับอนุมัติหรือไม่ เพื่อให้เป็นไปตามข้อกำหนด "ตัวระบุบริการ" ของ FIPS 140-3

ข้อผิดพลาดในการทดสอบด้วยตนเอง

ในกรณีที่การทดสอบตัวเองไม่สำเร็จ โมดูลเคอร์เนลจะทำให้เคอร์เนลเข้าสู่โหมดตื่นตกใจและอุปกรณ์จะไม่บูตต่อ หากการรีบูตอุปกรณ์ไม่ช่วยแก้ปัญหาได้ อุปกรณ์จะต้องบูตเข้าสู่ Recovery Mode เพื่อแก้ไขโดยการแฟลชอุปกรณ์อีกครั้ง