การลงนามในใบสมัคร

การลงนามแอปพลิเคชันช่วยให้นักพัฒนาสามารถระบุผู้สร้างแอปพลิเคชันและอัปเดตแอปพลิเคชันได้โดยไม่ต้องสร้างอินเทอร์เฟซและสิทธิ์ที่ซับซ้อน ทุกแอปพลิเคชันที่ทำงานบนแพลตฟอร์ม Android จะต้อง ลงนามโดยนักพัฒนา แอปพลิเคชันที่พยายามติดตั้งโดยไม่ได้ลงนามจะถูกปฏิเสธโดย Google Play หรือตัวติดตั้งแพ็คเกจบนอุปกรณ์ Android

บน Google Play การลงนามแอปพลิเคชันจะเชื่อมโยงความไว้วางใจที่ Google มีกับนักพัฒนาและความไว้วางใจที่นักพัฒนามีต่อแอปพลิเคชันของพวกเขา นักพัฒนาทราบว่าแอปพลิเคชันของตนได้รับการจัดเตรียมให้กับอุปกรณ์ Android โดยไม่มีการแก้ไข และนักพัฒนาสามารถรับผิดชอบต่อพฤติกรรมของแอปพลิเคชันของตนได้

บน Android การลงนามแอปพลิเคชันเป็นขั้นตอนแรกในการวางแอปพลิเคชันใน Application Sandbox ใบรับรองแอปพลิเคชันที่ลงนามจะกำหนดว่า ID ผู้ใช้ใดเชื่อมโยงกับแอปพลิเคชันใด แอปพลิเคชันที่แตกต่างกันทำงานภายใต้ ID ผู้ใช้ที่แตกต่างกัน การลงนามแอปพลิเคชันช่วยให้แน่ใจว่าแอปพลิเคชันหนึ่งไม่สามารถเข้าถึงแอปพลิเคชันอื่นได้ ยกเว้นผ่าน IPC ที่กำหนดไว้อย่างดี

เมื่อติดตั้งแอปพลิเคชัน (ไฟล์ APK) ลงในอุปกรณ์ Android ตัวจัดการแพ็คเกจจะตรวจสอบว่า APK ได้รับการลงนามอย่างถูกต้องด้วยใบรับรองที่รวมอยู่ใน APK นั้น หากใบรับรอง (หรือถ้าให้แม่นยำกว่านั้นคือคีย์สาธารณะในใบรับรอง) ตรงกับคีย์ที่ใช้ในการลงนาม APK อื่น ๆ บนอุปกรณ์ APK ใหม่จะมีตัวเลือกให้ระบุในรายการว่าจะแชร์ UID กับอันอื่นในทำนองเดียวกัน APK ที่ลงนามแล้ว

แอปพลิเคชันสามารถลงนามโดยบุคคลที่สาม (OEM, ผู้ดำเนินการ, ตลาดทางเลือก) หรือลงนามด้วยตนเอง Android ให้การลงนามโค้ดโดยใช้ใบรับรองที่ลงนามเองซึ่งนักพัฒนาสามารถสร้างได้โดยไม่ต้องได้รับความช่วยเหลือหรืออนุญาตจากภายนอก การสมัครไม่จำเป็นต้องลงนามโดยหน่วยงานกลาง ขณะนี้ Android ไม่ได้ทำการตรวจสอบ CA สำหรับใบรับรองแอปพลิเคชัน

แอปพลิเคชันยังสามารถประกาศสิทธิ์ด้านความปลอดภัยในระดับการป้องกันลายเซ็น โดยจำกัดการเข้าถึงเฉพาะแอปพลิเคชันที่ลงนามด้วยคีย์เดียวกัน ในขณะที่ยังคงรักษา UID และ Application Sandbox ที่แตกต่างกัน ความสัมพันธ์ที่ใกล้ชิดยิ่งขึ้นกับ Application Sandbox ที่ใช้ร่วมกันนั้นได้รับอนุญาตโดยใช้ คุณลักษณะ UID ที่ใช้ร่วมกัน โดยที่แอปพลิเคชันตั้งแต่สองตัวขึ้นไปที่ลงนามด้วยคีย์นักพัฒนาเดียวกันสามารถประกาศ UID ที่ใช้ร่วมกันในรายการของพวกเขาได้

แผนการลงนาม APK

Android รองรับรูปแบบการลงนามแอปพลิเคชันสามรูปแบบ:

  • รูปแบบ v1: อิงตามการลงนาม JAR
  • รูปแบบ v2: APK Signature Scheme v2 ซึ่งเปิดตัวใน Android 7.0
  • รูปแบบ v3: APK Signature Scheme v3 ซึ่งเปิดตัวใน Android 9

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

การลงนาม JAR (รูปแบบ v1)

การลงนาม APK เป็นส่วนหนึ่งของ Android ตั้งแต่เริ่มต้น มันขึ้นอยู่กับ JAR ที่ลงนาม สำหรับรายละเอียดเกี่ยวกับการใช้รูปแบบนี้ โปรดดูเอกสารประกอบของ Android Studio เกี่ยวกับ การลงนามแอปของคุณ

ลายเซ็น v1 ไม่ได้ปกป้อง APK บางส่วน เช่น ข้อมูลเมตา ZIP เครื่องมือตรวจสอบ APK จำเป็นต้องประมวลผลโครงสร้างข้อมูลที่ไม่น่าเชื่อถือ (ยังไม่ได้รับการยืนยัน) จำนวนมาก จากนั้นจึงละทิ้งข้อมูลที่ลายเซ็นไม่ครอบคลุม นี่เป็นพื้นผิวการโจมตีที่ใหญ่มาก นอกจากนี้ ตัวตรวจสอบ APK จะต้องคลายการบีบอัดรายการที่ถูกบีบอัดทั้งหมด ซึ่งใช้เวลานานและหน่วยความจำมากขึ้น เพื่อแก้ไขปัญหาเหล่านี้ Android 7.0 ได้เปิดตัว APK Signature Scheme v2

APK Signature Scheme v2 & v3 (รูปแบบ v2+)

อุปกรณ์ที่ใช้ Android 7.0 และใหม่กว่ารองรับ APK Signature Scheme v2 (V2 Scheme) และใหม่กว่า (รูปแบบ v2 ได้รับการอัปเดตเป็น v3 ใน Android 9 เพื่อรวมข้อมูลเพิ่มเติมไว้ในบล็อกการลงชื่อ แต่ก็ใช้งานได้เหมือนกัน) เนื้อหาของ APK จะถูกแฮชและลงนาม จากนั้น APK Signing Block ที่เป็นผลลัพธ์จะถูกแทรกลงใน APK สำหรับรายละเอียดเกี่ยวกับการใช้รูปแบบ v2+ กับแอป โปรดดูที่ APK Signature Scheme v2

ในระหว่างการตรวจสอบความถูกต้อง รูปแบบ v2+ จะถือว่าไฟล์ APK เป็น Blob และทำการตรวจสอบลายเซ็นทั่วทั้งไฟล์ การแก้ไข APK รวมถึงการแก้ไขข้อมูลเมตา ZIP จะทำให้ลายเซ็น APK เป็นโมฆะ การยืนยัน APK รูปแบบนี้เร็วกว่ามาก และช่วยให้ตรวจพบคลาสการแก้ไขที่ไม่ได้รับอนุญาตได้มากขึ้น

รูปแบบใหม่นี้เข้ากันได้แบบย้อนหลัง ดังนั้น APK ที่ลงนามด้วยรูปแบบลายเซ็นใหม่จึงสามารถติดตั้งบนอุปกรณ์ Android รุ่นเก่าได้ (ซึ่งไม่ต้องสนใจข้อมูลเพิ่มเติมที่เพิ่มลงใน APK) ตราบใดที่ APK เหล่านี้ได้รับการรับรอง v1 ด้วย

กระบวนการตรวจสอบลายเซ็น APK

รูปที่ 1 กระบวนการตรวจสอบลายเซ็น APK

แฮชทั้งไฟล์ของ APK ได้รับการตรวจสอบเทียบกับลายเซ็น v2+ ที่จัดเก็บไว้ใน APK Signing Block แฮชครอบคลุมทุกอย่างยกเว้น APK Signing Block ซึ่งมีลายเซ็น v2+ การแก้ไข APK ภายนอก APK Signing Block จะทำให้ลายเซ็น v2+ ของ APK เป็นโมฆะ APK ที่มีลายเซ็น v2+ แบบแยกออกก็ถูกปฏิเสธเช่นกัน เนื่องจากลายเซ็น v1 ระบุว่า APK นั้นมีลายเซ็น v2 ซึ่งทำให้ Android 7.0 และใหม่กว่าปฏิเสธที่จะยืนยัน APK โดยใช้ลายเซ็น v1

สำหรับรายละเอียดเกี่ยวกับกระบวนการตรวจสอบลายเซ็น APK โปรดดู ส่วนการตรวจสอบ ของ APK Signature Scheme v2