จะตรวจสอบแอปส่งข้อความโอเพนซอร์สอย่างไร? แฮช ลายเซ็น และการตรวจสอบ

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

หลักฐานแต่ละอย่างบอกอะไรแน่?

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

การบิลด์ที่ทำซ้ำได้ไม่ใช่การดาวน์โหลดไฟล์ที่มีแฮชตรงกัน

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

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

จะตีความการตรวจสอบ APK อย่างถูกต้องได้อย่างไร?

1. รับไฟล์จากช่องทางทางการและระบุเวอร์ชันให้ชัดเจน
2. รับค่าไดเจสต์และข้อมูลผู้ลงนามจากแหล่งที่คุณเชื่อถือความแท้ของแหล่งนั้น
3. คำนวณแฮชของไฟล์และเปรียบเทียบกับเวอร์ชันเดียวกัน
4. ในการตรวจสอบทางเทคนิค ให้ตรวจสอบลายเซ็นด้วย เครื่องมือทางการ apksigner รองรับการทำเช่นนี้
5. หากพบความต่าง ให้หยุดติดตั้งและหาสาเหตุให้ชัดเจน อย่าลงนามไฟล์ใหม่เพื่อข้ามข้อผิดพลาด

ตัวอย่างคำสั่งตรวจสอบสำหรับผู้เชี่ยวชาญที่มี Android SDK Build Tools:

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

ชื่อ app.apk เป็นเพียงตัวอย่าง การรันคำสั่งสำเร็จไม่ได้ทำให้ไม่จำเป็นต้องรู้จักกุญแจที่ถูกต้องของผู้เผยแพร่

Proof Lab มีบทบาทอย่างไร?

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

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

ควรถามอะไรเมื่ออ่านรายงานการตรวจสอบ?

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

อย่าสรุปอย่างเด็ดขาดจากคำอย่าง “ผ่านการรับรอง” โดยยังไม่มีคำตอบให้คำถามเหล่านี้ การใช้อัลกอริทึมมาตรฐานก็ไม่เท่ากับการรับรองตามมาตรฐานของผลิตภัณฑ์ทั้งชิ้น

ข้อสรุปสำหรับการเลือกแอปส่งข้อความ

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