โมดูลคริปโตเคอเรนซี 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 (การเพิ่มประสิทธิภาพเวลาลิงก์) เนื่องจาก LTO เป็นข้อกำหนดเบื้องต้นสำหรับการควบคุม ความสมบูรณ์ของโฟลว์ ซึ่งเป็นฟีเจอร์ด้านความปลอดภัยที่สำคัญ

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

กรณีที่ควรใช้โมดูล

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

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

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

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

• เพิ่มชื่อโมดูลใน BOARD_VENDOR_RAMDISK_KERNEL_MODULES ซึ่งทำให้ ที่จะคัดลอกไปยัง RAM ของผู้ให้บริการ
• เพิ่มชื่อโมดูลใน 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.ก เวกเตอร์ทดสอบ 1 เวกเตอร์ต่ออัลกอริทึมโดยใช้ความยาวคีย์ใดก็ได้ที่รองรับคือ เพียงพอสำหรับการเข้ารหัส ตราบใดที่มีการทดสอบทั้งการเข้ารหัสและการถอดรหัส

Linux CryptoAPI มีแนวคิดเกี่ยวกับลำดับความสำคัญของอัลกอริทึม ที่ (เช่น การติดตั้งโดยใช้วิธีการเกี่ยวกับคริปโตพิเศษและการใช้วิธีสำรอง สำหรับ 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 ที่ฝั่งที่ 1 และ 2 เท่ากันจะถูกปฏิเสธ
gcm(aes)	gcm (เทมเพลต) gcm-aes-ce	ไม่1	AES-GCM: รองรับคีย์ AES ทุกขนาด รองรับเฉพาะ IV 96 บิตเท่านั้น เช่นเดียวกับโหมด AES อื่นๆ ทั้งหมดในโมดูลนี้ ผู้โทรจะต้องเป็นผู้รับผิดชอบต่อการระบุ IV เทมเพลต 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: นอกเหนือจากอินเทอร์เฟซ CryptoAPI มาตรฐานจะมีอินเทอร์เฟซไลบรารีให้แก่ SHA-256 อินเทอร์เฟซไลบรารีนี้ใช้การติดตั้งใช้งานที่ต่างออกไป
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 จะจัดการส่วนนี้โดยอัตโนมัติ โดยใช้ฮาร์ดแวร์การจัดการหน่วยความจำในโปรเซสเซอร์

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

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

คำแนะนำผู้ใช้

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

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

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

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