วิธีตรวจสอบ APK ของ Android: SHA-256 ลายเซ็น และบิลด์ที่สร้างซ้ำได้

ก่อนติดตั้ง APK ของ Android ให้แยกการตรวจสอบสามอย่างออกจากกัน: ไฟล์นี้ตรงกับรุ่นที่คาดไว้หรือไม่? มีการลงนามด้วยกุญแจที่คาดไว้หรือไม่? ผู้สร้างบิลด์อิสระสามารถสร้างผลลัพธ์เดียวกันจากซอร์สโค้ดที่ระบุได้หรือไม่? เช็กซัม SHA-256, ลายเซ็น APK และบิลด์ที่สร้างซ้ำได้ตอบคำถามเหล่านี้ในคนละแง่มุม

ไม่มีวิธีใดตัดสินได้ด้วยตัวเองว่าโปรแกรมเป็นมัลแวร์หรือไม่ โปรแกรมที่มีลายเซ็นถูกต้องและสร้างบิลด์ซ้ำได้ก็ยังอาจมีข้อบกพร่องด้านความปลอดภัยหรือพฤติกรรมที่เป็นอันตรายโดยเจตนา

การตรวจสอบแต่ละวิธียืนยันอะไรได้บ้าง

การตรวจสอบ	ผลลัพธ์ที่เป็นประโยชน์	ข้อจำกัดสำคัญ
ค่าไดเจสต์ SHA-256 ของไฟล์	ไบต์ในไฟล์ของคุณตรงกับค่าไดเจสต์ที่เชื่อถือได้ค่าหนึ่ง	ผู้โจมตีที่แทนที่ได้ทั้งไฟล์และไดเจสต์สามารถทำให้การเปรียบเทียบนี้ใช้ป้องกันไม่ได้
การตรวจสอบลายเซ็น APK	ลายเซ็นของแพ็กเกจผ่านการตรวจสอบด้วยใบรับรองการลงนามของแพ็กเกจนั้น	ต้องยืนยันว่ากุญแจลงนามใดคือกุญแจที่คาดไว้ ความถูกต้องของลายเซ็นเพียงอย่างเดียวไม่ได้ยืนยันตัวตนของผู้เผยแพร่
การเปรียบเทียบบิลด์ที่สร้างซ้ำได้	สามารถสร้างผลลัพธ์ที่ระบุขึ้นใหม่จากอินพุตที่มีเอกสารกำกับ	การที่ซอร์สโค้ดกับไบนารีตรงกันไม่ได้พิสูจน์ว่าซอร์สโค้ดปลอดภัย
การทบทวนความปลอดภัย	มีการประเมินประเด็นเฉพาะด้านการออกแบบหรือการนำไปใช้งาน	ขอบเขต เวอร์ชัน ข้อค้นพบ และปัญหาที่ยังไม่ได้แก้ไขล้วนมีความสำคัญ

Android กำหนดให้ APK ต้องมีการลงนามจึงจะติดตั้งและอัปเดตได้ เมื่อใช้ Play App Signing ทาง Google สามารถจัดการกุญแจลงนามของแอปและสร้าง APK สำหรับแจกจ่ายจากแอปบันเดิลได้ สิ่งเหล่านี้เป็นรูปแบบการมอบความไว้วางใจที่มีเอกสารระบุไว้ ไม่ใช่หลักฐานว่าตัวกลางรายใดก็สามารถแอบเปลี่ยนแพ็กเกจโดยยังคงลายเซ็นที่ถูกต้องไว้ได้ ดู คู่มือการลงนามแอปของ Android

ขั้นที่ 1: ระบุผลลัพธ์จากการบิลด์ให้ตรงตัว

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

APK ที่ดาวน์โหลดจากผู้เผยแพร่โดยตรงอาจต่างจาก APK ที่ร้านแอปสร้างขึ้นสำหรับอุปกรณ์เครื่องหนึ่ง เวอร์ชัน สถาปัตยกรรม วิธีจัดแพ็กเกจ หรือรูปแบบการลงนามที่ต่างกันอาจทำให้ค่าแฮชของไฟล์ต่างกันได้โดยมีเหตุผลที่ถูกต้อง ก่อนถือว่าความไม่ตรงกันเป็นหลักฐานการดัดแปลง ให้แน่ใจก่อนว่ากำลังเปรียบเทียบผลลัพธ์ชนิดเดียวกัน

คำถามที่ควรถามในทางปฏิบัติคือ: ค่าที่คาดไว้มาจากไหน และเหตุใดฉันจึงเชื่อถือแหล่งที่มานั้น? การคำนวณแฮชแบบออฟไลน์ไม่ได้แก้ปัญหาเรื่องความน่าเชื่อถือของไดเจสต์ที่ได้มาทางออนไลน์

ขั้นที่ 2: คำนวณ SHA-256 บนเครื่องของคุณ

แทนที่ messenger.apk ด้วยชื่อไฟล์ที่คุณดาวน์โหลด ตัวอย่างเหล่านี้อ่านไฟล์เท่านั้น ไม่ได้ติดตั้งไฟล์

Linux:

sha256sum messenger.apk

macOS:

shasum -a 256 messenger.apk

พรอมต์คำสั่งของ Windows:

certutil -hashfile messenger.apk SHA256

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

หากค่าต่างกัน ให้หยุดก่อนติดตั้ง ตรวจสอบผลลัพธ์จากการบิลด์และเวอร์ชัน ดาวน์โหลดใหม่จากแหล่งที่เชื่อถือได้หากเหมาะสม และสอบถามผู้เผยแพร่เกี่ยวกับความไม่ตรงกันที่ยังอธิบายไม่ได้ อย่า “แก้” เช็กซัมที่คาดไว้เพื่อให้ตรงกับไฟล์ที่บังเอิญได้รับมา

ขั้นที่ 3: ตรวจสอบลายเซ็น APK

สำหรับผู้ใช้ที่มี Android SDK Build Tools นั้น เอกสาร apksigner ของ Google อธิบายการตรวจสอบลายเซ็นและการแสดงข้อมูลใบรับรองไว้ดังนี้:

apksigner verify --verbose --print-certs messenger.apk

การตรวจสอบควรสำเร็จสำหรับแพลตฟอร์มที่ APK รองรับ เปรียบเทียบข้อมูลใบรับรองของผู้ลงนามกับบันทึกการเผยแพร่ที่เชื่อถือได้ หรือประวัติลำดับการสืบทอดกุญแจลงนามที่ผู้เผยแพร่บันทึกไว้ ลายเซ็นที่สร้างด้วยกุญแจที่ไม่คุ้นเคยไม่ได้กลายเป็นสิ่งน่าเชื่อถือเพียงเพราะมีคำว่า “ตรวจสอบแล้ว” การเปลี่ยนกุญแจลงนามอย่างถูกต้องก็ต้องมีหลักฐานเช่นกัน ไม่ใช่เพียงคำสั่งให้มองข้ามค่าที่ไม่ตรงกัน

ไดเจสต์ SHA-256 ของไฟล์ APK กับลายนิ้วมือ SHA-256 ของใบรับรองการลงนามเป็นคนละค่า อย่านำค่าหนึ่งไปเปรียบเทียบกับอีกค่าหนึ่ง

ขั้นที่ 4: มองหาหลักฐานของบิลด์ที่สร้างซ้ำได้

คำกล่าวอ้างว่าสร้างบิลด์ซ้ำได้ต้องระบุรีวิชันของซอร์สโค้ด สภาพแวดล้อมการบิลด์ คำแนะนำ และผลลัพธ์เป้าหมายอย่างชัดเจน บุคคลอิสระควรสามารถสร้างผลลัพธ์นั้นขึ้นใหม่และเปรียบเทียบผลได้ คำนิยามของโครงการ Reproducible Builds กำหนดให้อินพุตเหล่านี้เป็นส่วนหนึ่งของคำกล่าวอ้าง

สำหรับแอปส่งข้อความ หลักฐานการเผยแพร่ที่เป็นประโยชน์ ได้แก่ แท็กของซอร์สโค้ด เวอร์ชันของส่วนพึ่งพาและชุดเครื่องมือที่ตรึงไว้ คำแนะนำการบิลด์ และผลการเปรียบเทียบโดยบุคคลอิสระ ให้ถามว่าเปรียบเทียบอะไรกันแน่: ผลลัพธ์ที่ยังไม่ได้ลงนาม, APK ที่ลงนามแล้ว หรือเนื้อหาบางส่วนในแพ็กเกจ อย่าสรุปว่าสร้างซ้ำได้เพียงเพราะมีการเผยแพร่ซอร์สโค้ดและค่าแฮชของไฟล์ดาวน์โหลด

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

Proof Lab ของ Livara มีบทบาทตรงไหน

Proof Lab ของ Livara ให้คุณคำนวณแฮช APK บนเครื่องแล้วเปรียบเทียบกับไดเจสต์ที่เผยแพร่ไว้ การสาธิตด้านวิทยาการเข้ารหัสลับในนั้นมีขอบเขตแคบกว่าการตรวจสอบโปรโตคอลส่งข้อความทั้งระบบ ใช้การตรวจแฮชตามวัตถุประสงค์ที่ระบุไว้ ควบคู่กับข้อมูลรุ่นเผยแพร่และการลงนามที่คาดหวัง อย่าถือว่าเป็นหลักฐานอิสระว่าสร้างบิลด์ซ้ำได้หรือไม่มีแบ็กดอร์

แบบจำลองภัยคุกคาม ระบุข้อจำกัดไว้อย่างชัดเจนสำหรับกรณีที่ทั้ง APK และไดเจสต์ที่แสดงอยู่สามารถถูกแทนที่ได้ นี่คือเหตุผลที่แหล่งที่มาของค่าอ้างอิงสำคัญพอ ๆ กับการคำนวณอย่างถูกต้อง

คำถามที่พบบ่อย

เช็กซัมที่ตรงกันพิสูจน์ว่า APK ปลอดภัยหรือไม่?

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

หากเช็กซัมตรงกัน การตรวจลายเซ็นยังจำเป็นหรือไม่?

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

ไฟล์ที่ดาวน์โหลดจากร้านแอปต้องตรงกับค่าแฮช APK บนเว็บไซต์หรือไม่?

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

การตรวจเหล่านี้ตรวจพบสปายแวร์ที่อยู่ในโทรศัพท์แล้วได้หรือไม่?

ไม่ได้ การตรวจเหล่านี้ประเมินผลลัพธ์ที่ใช้สำหรับติดตั้ง ไม่ใช่ทุกองค์ประกอบของสถานะการทำงานปัจจุบันบนอุปกรณ์