Android 17 (API ระดับ 37) ขอแนะนำ APK Signature Scheme v3.2 ซึ่งเป็น Signature Scheme แบบไฮบริดที่ออกแบบมาเพื่อรองรับการเปลี่ยนผ่านของระบบนิเวศ Android ไปสู่การเข้ารหัสลับหลังควอนตัม (PQC)
เนื่องจากอุตสาหกรรมกำลังใช้การเข้ารหัสลับหลังควอนตัม (PQC) ในวงกว้าง Scheme v3.2 จึงเป็นการป้องกันเชิงลึก โดยกำหนดให้คุณต้องรับรอง APK ด้วยอัลกอริทึมแบบคลาสสิก เช่น RSA หรือ ECDSA และอัลกอริทึม PQC แนวทางแบบไฮบริดนี้ใช้การเข้ารหัสลับแบบคลาสสิกเพื่อปกป้อง APK ของคุณในขณะที่ป้องกันภัยคุกคามจากคอมพิวเตอร์ควอนตัม
วัตถุประสงค์และรายละเอียด
Scheme v3.2 ทำงานเป็นกลไกการเปลี่ยนผ่านที่เป็นมาตรฐานและสอดคล้องกับอุตสาหกรรม แนวทางแบบไฮบริดนี้จะช่วยให้คุณได้รับประโยชน์จากการเข้ารหัสลับหลังควอนตัม (PQC) ที่ทนทานต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัม ในขณะที่ยังคงใช้ประโยชน์จากความปลอดภัยที่ได้รับการพิสูจน์แล้วของอัลกอริทึมลายเซ็นแบบคลาสสิก เมื่ออัลกอริทึม PQC ที่ได้มาตรฐานใหม่มีความพร้อมในการใช้งานในวงกว้างแล้ว คุณจะเปลี่ยนจากการกำหนดค่าแบบไฮบริดนี้ไปใช้คีย์การรับรอง PQC เดียวได้ การรองรับแพลตฟอร์มสำหรับ Signature Scheme v3.2 จะเริ่มใน Android 17 Android เวอร์ชันต่ำกว่าจะข้ามบล็อก v3.2 และใช้ Scheme ก่อนหน้าสำหรับการยืนยันลายเซ็น
Scheme v3.2 บังคับใช้ลักษณะการทำงานต่อไปนี้เพื่อรักษาความปลอดภัยและป้องกันการโจมตีแบบลดเวอร์ชันระหว่างการเปลี่ยนผ่านนี้
- เนื้อหาคีย์ใหม่: การเปลี่ยนไปใช้บล็อกแบบไฮบริดกำหนดให้ต้องสร้างคีย์แบบคลาสสิกและคีย์ PQC ใหม่ อย่าใช้เนื้อหาคีย์ซ้ำระหว่างการกำหนดค่าแบบไฮบริดและแบบไม่ใช่ไฮบริด
- การหมุนเวียนโดยนัย: แพลตฟอร์มจะถือว่าบล็อกแบบไฮบริดเป็นการหมุนเวียนคีย์โดยนัย แพลตฟอร์มจะเพิ่มคีย์แบบคลาสสิกใหม่ลงในลำดับการรับรองที่มีอยู่ของแอปเป็นคีย์ลำดับที่ 2 จากสุดท้าย และถือว่าคีย์ PQC ใหม่เป็นข้อมูลประจำตัวการรับรองปัจจุบันของแอป
- ลำดับการรับรองที่แชร์: ทั้งคีย์แบบคลาสสิกใหม่และคีย์ PQC ใหม่ภายในบล็อกแบบไฮบริดต้องแชร์ลำดับการรับรองเดียวกันเพื่อให้การหมุนเวียนโดยนัยดำเนินการได้สำเร็จ คุณต้องทำซ้ำประวัติการรับรองที่มีอยู่ของแอป ไม่ว่าจะเป็นคีย์เดิมเดียวหรือลำดับการรับรองของคีย์ที่หมุนเวียนก่อนหน้านี้ สำหรับผู้รับรองแบบไฮบริดใหม่ทั้ง 2 ราย แพลตฟอร์มใช้ลำดับการรับรองที่แชร์นี้เพื่อยืนยันว่าเอนทิตีที่เปลี่ยนแอปไปใช้ Scheme แบบไฮบริดเป็นเจ้าของที่ถูกต้องของข้อมูลประจำตัวการรับรองปัจจุบันของแอป
- ข้อจำกัดของผู้รับรอง PQC รายเดียว: ในช่วงแรกของการเปิดตัว PQC, Android จะจำกัดการใช้อัลกอริทึม PQC ไว้ที่บล็อกแบบไฮบริด v3.2 อย่างชัดเจน แพลตฟอร์มจะไม่ยืนยันการกำหนดค่า PQC ของผู้รับรองรายเดียวโดยใช้ Signature Scheme ก่อนหน้า เช่น v2, v3.0 หรือ v3.1
- การเปลี่ยนกลับ: เมื่อเปลี่ยนจากบล็อกแบบไฮบริด v3.2 กลับไปเป็นบล็อกของผู้รับรองรายเดียว ไม่ว่าจะเป็นผู้รับรองแบบคลาสสิกหรือผู้รับรอง PQC เมื่อได้รับการรองรับในรุ่นที่จะเปิดตัวในอนาคต แพลตฟอร์มจะยืนยันว่าทั้งคีย์แบบคลาสสิกและคีย์ PQC จากบล็อกแบบไฮบริดอยู่ในลำดับการรับรองใหม่และรับรองผู้รับรองรายเดียวใหม่
แนวทางปฏิบัติแนะนำสำหรับการเปลี่ยนผ่าน
APK ต้องมีบล็อกลายเซ็น v3.0 หรือ v3.1 มาตรฐานที่รับรองโดยคีย์แบบคลาสสิกเดียวต่อไป เพื่อรักษาความเข้ากันได้กับ Android เวอร์ชันต่ำกว่าและมอบเส้นทางการอัปเกรดที่ปลอดภัยระหว่างการเปลี่ยนผ่านไปใช้การรับรอง PQC เนื่องจากมีเพียง Android 17 (API ระดับ 37) ขึ้นไปเท่านั้นที่รองรับ Scheme แบบไฮบริด v3.2 ข้อกำหนดนี้จึงช่วยให้อุปกรณ์ที่ใช้เวอร์ชันต่ำกว่าสามารถยืนยันและติดตั้งแอปได้
การกำหนดค่าสำรองแบบคลาสสิก
ใช้การกำหนดค่าสำรองแบบคลาสสิกเพื่อมอบความปลอดภัยในการดำเนินงานระหว่างการเปลี่ยนผ่าน PQC
- แอปที่มีอยู่: คีย์การรับรองที่กำหนดไว้ในปัจจุบันของแอป K0 จะเป็นพื้นฐานตามธรรมชาติสำหรับการสำรองนี้
- แอปใหม่: สร้างคีย์การรับรองแบบคลาสสิกพื้นฐาน K0 พร้อมกับคีย์แบบไฮบริดใหม่ C_K1 และ PQC_K1 เพื่อกำหนดข้อมูลประจำตัวเริ่มต้น
ในทั้ง 2 กรณี APK ต้องมีบล็อกลายเซ็น v3.0 หรือ v3.1 มาตรฐานที่รับรองโดยคีย์แบบคลาสสิก K0 พร้อมกับบล็อกแบบไฮบริด v3.2 ที่รับรองโดยคีย์แบบไฮบริดใหม่ C_K1 และ PQC_K1
ในระหว่างการติดตั้งใช้งาน Scheme v3.2 ครั้งแรก ลำดับการรับรองสำหรับบล็อกแบบไฮบริดควรให้ความสามารถ ROLLBACK แก่ K0 หากเกิดปัญหาในการติดตั้งใช้งาน ความสามารถนี้จะช่วยให้แอปกลับไปใช้ลายเซ็นแบบคลาสสิกได้โดยไม่ขัดขวางการอัปเดตของผู้ใช้ เมื่อข้อมูลรันไทม์เพียงพอแล้วยืนยันว่าการติดตั้งใช้งานแบบไฮบริดมีเสถียรภาพ เราขอแนะนำให้ลบความสามารถ ROLLBACK ในการอัปเดตครั้งต่อๆ ไปเพื่อรักษาความปลอดภัยคีย์ใหม่ของคุณอย่างเต็มที่
ข้อกำหนดในการกำหนดค่าระยะยาว
คุณต้องรักษาการกำหนดค่าการรับรองแบบไฮบริดนี้ไว้ตราบใดที่แอปกำหนดเป้าหมายเป็นแพลตฟอร์มที่เปิดตัวซึ่งรองรับเฉพาะ Scheme แบบไฮบริด แม้ว่าแพลตฟอร์มเวอร์ชันหนึ่งจะรองรับคีย์ PQC ของผู้รับรองรายเดียว คุณก็ต้องรับรอง APK ใดก็ตามที่กำหนดเป้าหมายเป็นรุ่นที่ต้องใช้บล็อกแบบไฮบริด v3.2 ด้วยคีย์ทั้ง 2 รายการ
บล็อก APK Signature Scheme v3.2
บล็อกการรับรอง APK จะจัดเก็บบล็อกลายเซ็น v3.2 ไว้ข้างๆ บล็อกลายเซ็น v2, v3.0 และ v3.1
โครงสร้างบล็อก v3.2 คล้ายกับ v3.0 แต่ใช้รหัสบล็อกใหม่ 0x70e1c89f เพื่อส่งสัญญาณว่าเป็นบล็อกแบบไฮบริด บล็อก v3.2 ที่ถูกต้องต้องมีผู้รับรอง 2 รายพอดี
อัลกอริทึมที่รองรับ
Scheme v3.2 รองรับอัลกอริทึมลายเซ็น PQC ต่อไปนี้ในตอนแรก
- ML-DSA-65
- ML-DSA-87
อัลกอริทึมเหล่านี้จะจับคู่กับอัลกอริทึมลายเซ็นแบบคลาสสิกมาตรฐาน เช่น อัลกอริทึมที่รองรับใน v3.0 และ v3.1 เพื่อสร้างบล็อกแบบไฮบริด
รูปแบบ
บล็อกการรับรอง APK จะจัดเก็บบล็อก APK Signature Scheme v3.2 ไว้ภายใต้รหัส 0x70e1c89f
รูปแบบของบล็อก v3.2 เหมือนกับ v3.0 แต่ลำดับองค์ประกอบของผู้รับรองระดับบนสุดต้องมีรายการ 2 รายการพอดีที่กำหนดเป้าหมายเป็น SDK เวอร์ชันเดียวกัน ดังนี้
- ลำดับของผู้รับรองที่มีคำนำหน้าความยาวและมีคำนำหน้าความยาว:
- ผู้รับรองที่มีคำนำหน้าความยาว (แบบคลาสสิก)
- ผู้รับรองที่มีคำนำหน้าความยาว (PQC)
ผู้รับรองแต่ละรายใช้รูปแบบ v3 มาตรฐาน ดังนี้
- ข้อมูลที่รับรองซึ่งมีคำนำหน้าความยาว:
- ลำดับของเนื้อหาโดยรวมที่มีคำนำหน้าความยาวและมีคำนำหน้าความยาว:
- รหัสอัลกอริทึมลายเซ็น (4 ไบต์)
- เนื้อหาโดยรวม (มีคำนำหน้าความยาว)
- ลำดับของใบรับรองที่มีคำนำหน้าความยาว:
- ใบรับรอง X.509 ที่มีคำนำหน้าความยาว (รูปแบบ ASN.1 DER)
- minSDK (uint32)
- maxSDK (uint32)
- ลำดับของแอตทริบิวต์เพิ่มเติมที่มีคำนำหน้าความยาวและมีคำนำหน้าความยาว:
- รหัส (uint32)
- ค่า (ความยาวผันแปร: ความยาวของแอตทริบิวต์เพิ่มเติม - 4 ไบต์)
- minSDK (uint32)
- maxSDK (uint32)
- ลำดับของลายเซ็นที่มีคำนำหน้าความยาวและมีคำนำหน้าความยาว:
- รหัสอัลกอริทึมลายเซ็น (4 ไบต์)
- ลายเซ็นที่มีคำนำหน้าความยาวเหนือข้อมูลที่รับรอง
- คีย์สาธารณะที่มีคำนำหน้าความยาว (
SubjectPublicKeyInfo, รูปแบบ ASN.1 DER)
การยืนยัน
ใน Android 17 (ระดับ API 37) ขึ้นไป แพลตฟอร์มจะยืนยันทั้งผู้เซ็นแบบคลาสสิกและผู้เซ็น PQC ยืนยันความเข้ากันได้ และตรวจสอบลำดับการรับรองของการหมุนเวียนโดยนัยเพื่อยืนยันลายเซ็น v3.2 ในแพลตฟอร์มที่เปิดตัว Android 16 (API ระดับ 36) และต่ำกว่า แพลตฟอร์มจะไม่ประมวลผลบล็อกลายเซ็นแบบไฮบริดนี้และจะใช้ Scheme ก่อนหน้าแทน
กระบวนการโดยรวมมีดังนี้
- ค้นหาบล็อก APK Signature Scheme v3.2 (รหัส 0x70e1c89f)
- ยืนยันว่าบล็อกมีผู้รับรอง2 รายพอดี หากมีผู้รับรองน้อยกว่าหรือมากกว่า 2 ราย การยืนยันจะไม่สำเร็จ
- ยืนยันว่าผู้รับรองรายหนึ่งใช้อัลกอริทึมลายเซ็นแบบคลาสสิกและอีกรายใช้อัลกอริทึมลายเซ็น PQC หากทั้ง 2 รายเป็นแบบคลาสสิกหรือทั้ง 2 รายเป็น PQC การยืนยันจะไม่สำเร็จ
- ยืนยันว่าผู้รับรองทั้ง 2 รายกำหนดเป้าหมายเป็นช่วง SDK เดียวกัน (
minSdkVersionและmaxSdkVersion) - ดำเนินการยืนยัน v3 มาตรฐานสำหรับผู้รับรองทั้ง 2 ราย ดังนี้
- เลือกรหัสอัลกอริทึมลายเซ็นที่รองรับและแข็งแกร่งที่สุดจากลายเซ็น
- ยืนยันลายเซ็นที่เกี่ยวข้องจากลายเซ็นกับข้อมูลที่รับรองโดยใช้คีย์สาธารณะ
- ยืนยันว่า
minSdkVersionและmaxSdkVersionในข้อมูลที่รับรองตรงกับminSdkVersionและmaxSdkVersionที่ไม่ได้ลงชื่อ - แยกวิเคราะห์ใบรับรองและยืนยันว่าใบรับรองแรกตรงกับคีย์สาธารณะ
- แยกวิเคราะห์แอตทริบิวต์เพิ่มเติมเพื่อแยกโครงสร้างหลักฐานแสดงการหมุนเวียนคีย์
- ยืนยันประวัติการรับรอง (หลักฐานแสดงการหมุนเวียนคีย์) ดังนี้
- ตรวจสอบว่าผู้รับรองทั้ง 2 รายมีประวัติการรับรองก่อนหน้าเหมือนกัน
- ความยาวของลำดับการรับรองต้องตรงกัน และใบรับรองและแฟล็กความสามารถทั้งหมดที่นำไปสู่ผู้รับรองปัจจุบันต้องเหมือนกัน
- หากประวัติการรับรองตรงกัน ให้ผสานลำดับการรับรอง โดยถือว่าใบรับรองของผู้รับรองแบบคลาสสิกเป็นรุ่นก่อนหน้าของใบรับรองของผู้รับรอง PQC และกำหนดให้ผู้รับรอง PQC เป็นโหนดปลายทางปัจจุบัน
- ยืนยันเนื้อหาโดยรวม ดังนี้
- วนซ้ำแผนที่เนื้อหาโดยรวมสำหรับผู้รับรองทั้ง 2 ราย
- ยืนยันว่าสำหรับอัลกอริทึมเนื้อหาโดยรวมที่ตรงกัน ค่าเนื้อหาโดยรวมที่คำนวณได้จะเหมือนกันระหว่างผู้รับรองแบบคลาสสิกและผู้รับรอง PQC
- ใช้เนื้อหาโดยรวมที่ตรงกันจากผู้รับรองที่ยืนยันแล้วเพื่อยืนยันความสมบูรณ์ของเนื้อหา APK (คล้ายกับ v2 และ v3)
- หากติดตั้งแอปแล้ว ให้ยืนยันลำดับการรับรองการอัปเดตแพ็กเกจ ดังนี้
- การอัปเดตจากผู้รับรองรายเดียว: หากแอปที่ติดตั้งได้รับการรับรองด้วยคีย์แบบคลาสสิกเดียว คีย์นั้นต้องอยู่ในลำดับการรับรองของบล็อกแบบไฮบริดใหม่ในฐานะรุ่นก่อนหน้าของผู้รับรองแบบไฮบริด
- การอัปเดตจากผู้รับรองแบบไฮบริดเพื่อใช้แบบไฮบริดต่อไป: หากแอปที่ติดตั้งได้รับการรับรองด้วยบล็อกแบบไฮบริด v3.2 ทั้งคีย์แบบคลาสสิกและคีย์ PQC ก่อนหน้าต้องยังคงเป็นผู้รับรองที่ใช้งานอยู่ในปัจจุบันในบล็อก v3.2 ของ APK ที่อัปเดต หรือทั้ง 2 คีย์ต้องอยู่ในลำดับการรับรองใหม่ที่รับรองคีย์แบบไฮบริดที่หมุนเวียนใหม่
- การเปลี่ยนจากผู้รับรองแบบไฮบริด: หากแอปที่ติดตั้งได้รับการรับรองด้วยบล็อกแบบไฮบริด v3.2 และ APK ที่อัปเดตเปลี่ยนกลับไปเป็นผู้รับรองรายเดียว (PQC หรือแบบคลาสสิก) ผู้รับรองแบบไฮบริดก่อนหน้าทั้ง 2 รายต้องอยู่ในลำดับการรับรองของ APK ที่อัปเดตและรับรองคีย์การรับรองเดียวใหม่
- เส้นทางการอัปเดตที่ไม่ถูกต้อง: หากนักพัฒนาแอปพยายามอัปเดตแอปที่รับรองแบบไฮบริดโดยใช้คีย์แบบไฮบริดเพียงคีย์เดียวเป็นผู้รับรองรายเดียวโดยไม่มีการหมุนเวียนที่เหมาะสม การอัปเดตจะไม่สำเร็จ ต้องใช้คีย์ทั้ง 2 รายการอย่างชัดเจนในการเปลี่ยนผ่านใดๆ เพื่อป้องกันการโจมตีแบบลดเวอร์ชัน
- หากขั้นตอนใดขั้นตอนหนึ่งไม่สำเร็จ การยืนยันจะไม่สำเร็จ
การป้องกันการลบ
Scheme v3.2 มีแอตทริบิวต์การป้องกันการลบที่คล้ายกับการวนซ้ำ Scheme ก่อนหน้า เพื่อป้องกันการโจมตีแบบลดเวอร์ชันไปยัง Signature Scheme ที่ต่ำกว่า
เครื่องมือการรับรองจะเขียนแอตทริบิวต์การป้องกันการลบแบบไฮบริด 2 รายการลงในแอตทริบิวต์เพิ่มเติมของบล็อกลายเซ็น v3.0 และ v3.1 แอตทริบิวต์เหล่านี้กำหนดขอบเขตเวอร์ชัน SDK ที่แน่นอนซึ่งบล็อกแบบไฮบริด v3.2 ต้องมีอยู่และได้รับการยืนยัน ดังนี้
- แอตทริบิวต์เวอร์ชัน SDK ขั้นต่ำ (รหัส
0xbf940529): ค่าของแอตทริบิวต์นี้ กำหนดเวอร์ชัน SDK ขั้นต่ำที่บล็อกการรับรองแบบไฮบริดรองรับ - แอตทริบิวต์เวอร์ชัน SDK สูงสุด
(รหัส
0x9f06b79c): ค่าของแอตทริบิวต์นี้กำหนด เวอร์ชัน SDK สูงสุดที่บล็อกการรับรองแบบไฮบริดรองรับ แอตทริบิวต์นี้ช่วยให้คุณเปลี่ยนไปใช้การกำหนดค่าของผู้รับรองรายเดียวได้เมื่อแพลตฟอร์มที่เปิดตัวเวอร์ชันสูงกว่าไม่จำเป็นต้องใช้ลายเซ็นแบบไฮบริด
หากแพลตฟอร์มข้ามการยืนยัน v3.2 เนื่องจากไม่มีบล็อกหรือช่วง SDK ของบล็อกใช้ไม่ได้กับอุปกรณ์ แพลตฟอร์มจะยืนยัน APK กับบล็อกถัดไปที่มีอยู่ หากบล็อกก่อนหน้ามีแอตทริบิวต์การป้องกันการลบเหล่านี้ แพลตฟอร์มจะใช้การตรวจสอบต่อไปนี้
- การยืนยันการมีอยู่และช่วง: หากบล็อกลายเซ็น v3.0 หรือ v3.1 มีแอตทริบิวต์ SDK ขั้นต่ำ (รหัส
0xbf940529, ค่า X) หรือแอตทริบิวต์ SDK สูงสุด (รหัส0x9f06b79c, ค่า Y) แพลตฟอร์มกำหนดให้บล็อกแบบไฮบริด v3.2 ต้องอยู่ใน APK แพลตฟอร์มจะอ่านบล็อกแบบไฮบริดเพื่อยืนยันว่าช่วง SDK ที่กำหนดเป้าหมายตรงกับขอบเขตที่ระบุโดยแอตทริบิวต์เหล่านี้ หากไม่มีบล็อก v3.2 หรือค่า SDK ขั้นต่ำและ สูงสุดภายในไม่เท่ากับ X และ Y แพลตฟอร์มจะ ปฏิเสธการติดตั้ง - การบังคับใช้ภายในช่วง: หากเวอร์ชัน SDK ของอุปกรณ์อยู่ในช่วงที่ถูกต้องซึ่งระบุโดยแอตทริบิวต์เหล่านี้ (มากกว่าหรือเท่ากับ X และน้อยกว่าหรือเท่ากับ Y เมื่อคุณระบุแอตทริบิวต์สูงสุด) แพลตฟอร์มกำหนดให้ต้องใช้บล็อกแบบไฮบริด v3.2 อย่างเคร่งครัดสำหรับการยืนยันลายเซ็น หากแพลตฟอร์มยืนยันบล็อก v3.0 หรือ v3.1 ในอุปกรณ์ที่อยู่ในช่วง SDK ที่กำหนดเป้าหมายนี้ แพลตฟอร์มจะปฏิเสธการติดตั้งเนื่องจากมีการข้ามหรือลบบล็อก v3.2 โดยเจตนาร้าย
แพลตฟอร์มจะกำหนดว่าเมื่อใดที่ APK ต้องมีบล็อก v3.2 โดยการบังคับใช้ขอบเขตเหล่านี้ หากมีการลบบล็อก แพลตฟอร์มจะปฏิเสธการติดตั้งเพื่อป้องกันการโจมตีแบบลดเวอร์ชัน
ตรวจสอบการติดตั้งใช้งาน
หากต้องการทดสอบการติดตั้งใช้งาน Signature Scheme v3.2 ให้เรียกใช้การทดสอบ CTS HybridSignatureVerificationTest.java ที่อยู่ใน cts/hostsidetests/appsecurity/src/android/appsecurity/cts/
การทดสอบเหล่านี้ครอบคลุมสถานการณ์ที่หลากหลาย รวมถึงการติดตั้งสำเร็จ การอัปเดตจากเวอร์ชันแบบคลาสสิกเท่านั้น การเปลี่ยนกลับโดยใช้ความสามารถ ROLLBACK และการยืนยันการลดการโจมตีแบบลบ