แคชภายใน แกลเลอรี และ RAM เป็นขอบเขตที่ต่างกันสามส่วน การลบสำเนาหนึ่งไม่ได้พิสูจน์ว่าลบทุกสำเนาแล้ว
การเข้ารหัสจากต้นทางถึงปลายทางปกป้องเส้นทางส่งรูปภาพ เมื่อเปิดรูปแล้ว ความปลอดภัยของสำเนาที่มองเห็นได้ยังขึ้นอยู่กับอุปกรณ์และวิธีจัดเก็บของแอปด้วย แต่ไม่ใช่ทุกไฟล์ชั่วคราวใน Android จะเป็นสาธารณะ และไม่ใช่ทุกรูปที่อยู่ในแคชจะเข้าแกลเลอรีโดยอัตโนมัติ
ในการพิจารณาความเสี่ยง ให้แยกสามตำแหน่งแทนคำกำกวมว่า “รั่วจากแคช”: พื้นที่ส่วนตัวของแอป พื้นที่ร่วมอย่างแกลเลอรี และหน่วยความจำที่กระบวนการกำลังใช้งานหรือ RAM แต่ละตำแหน่งมีสิทธิ์เข้าถึงและวงจรชีวิตต่างกัน
รูปที่ถอดรหัสแล้วอาจเหลืออยู่ที่ไหน?
| ตำแหน่ง | การใช้งานทั่วไป | ข้อควรคำนึงด้านความปลอดภัย |
|---|---|---|
| แคชภายในส่วนตัวของแอป | แสดงรูปซ้ำได้รวดเร็ว | แอปทั่วไปอื่นไม่ควรเข้าถึงได้อย่างอิสระ |
| แกลเลอรีหรือพื้นที่ร่วม | บันทึก แก้ไข หรือแชร์รูป | แอปที่มีสิทธิ์และบริการสำรองข้อมูลอาจเข้าถึงได้ |
| RAM และหน่วยความจำของส่วนแสดงผล | ประมวลผลรูปขณะใช้งาน | ความเป็นข้อมูลชั่วคราวไม่ได้หมายถึงปลอดภัยจากอุปกรณ์ที่ถูกบุกรุก |
| สำเนาที่ส่งออกหรือภาพตัวอย่าง | เปิดไฟล์ในแอปอื่น | อาจมีวงจรการลบแยกต่างหาก |
เอกสารการจัดเก็บของ Android แยกพื้นที่เฉพาะแอปออกจากพื้นที่ร่วม ดังนั้นคำว่า “MediaStore จัดทำดัชนีไฟล์แคชทุกไฟล์” จึงไม่ถูกต้อง เส้นทางจัดเก็บ API ที่ใช้ และสิทธิ์เป็นปัจจัยตัดสิน
แคชภายในได้รับการปกป้องอย่างไร?
Android แยกพื้นที่ภายในเฉพาะแอปออกจากแอปทั่วไปอื่น คู่มือทางการแนะนำพื้นที่นี้สำหรับข้อมูลชั่วคราวที่อ่อนไหวด้วย แอปหรือระบบอาจลบไฟล์แคชก่อนถอนการติดตั้งแอป แต่นักพัฒนาไม่ควรฝากการล้างไว้กับภาวะพื้นที่อุปกรณ์ใกล้เต็มเพียงอย่างเดียว คู่มือไฟล์เฉพาะแอป
การปกป้องนี้ไม่เท่ากับ “ไม่มีใครดึงไฟล์ออกมาได้” การเข้าถึงของผู้โจมตีบนโทรศัพท์ที่ล็อกอยู่ โทรศัพท์ที่ปลดล็อก ระบบปฏิบัติการที่มีช่องโหว่ หรืออุปกรณ์ที่มีสิทธิ์ root ไม่เหมือนกัน ข้ออ้างทางนิติวิทยาศาสตร์ดิจิทัลที่น่าเชื่อถือต้องระบุรุ่นอุปกรณ์ เวอร์ชันระบบ สถานะการล็อก และลักษณะการเข้าถึงของผู้โจมตี
เหตุใดการเก็บใน RAM จึงไม่รับประกันการลบอย่างสมบูรณ์?
การไม่เขียนสำเนาที่ไม่เข้ารหัสลงดิสก์ช่วยลดจำนวนสำเนาที่คงอยู่ได้ การล้างบัฟเฟอร์ที่มีข้อมูลอ่อนไหวก็อาจเป็นส่วนหนึ่งของการออกแบบเชิงป้องกัน อย่างไรก็ตาม ไม่อาจประกาศว่าโอกาสกู้คืนเป็นศูนย์เพียงเพราะกล่าวถึง “การเขียนศูนย์ทับ RAM”
รูปอาจถูกคัดลอกไปหลายบัฟเฟอร์ ไลบรารี หรือส่วนแสดงผลระหว่างการประมวลผล การล้างบัฟเฟอร์หนึ่งไม่ได้พิสูจน์ว่าทุกสำเนาถูกลบ แม้ไม่มีไฟล์ถาวรถูกสร้างขึ้น มัลแวร์ที่เข้าถึงข้อมูลระหว่างแสดงผลก็อาจคัดลอกได้ การเข้ารหัสกับการจัดการหน่วยความจำเป็นส่วนเสริมกัน ไม่ใช่สิ่งทดแทนกัน
ผู้ใช้ทำอะไรได้บ้าง?
- ตรวจสอบการบันทึกลงแกลเลอรีแยกจากการดาวน์โหลดอัตโนมัติ การรับสื่อเพื่อแสดงในแอปไม่จำเป็นต้องเท่ากับการบันทึกลงแกลเลอรี
- ควบคุมการสำรองรูปภาพ รูปที่ส่งออกอาจขึ้นคลาวด์โดยไม่เกี่ยวกับแชต
- ทบทวนสิทธิ์รูปภาพและไฟล์ของแอปอื่น อย่าสับสนระหว่างสิทธิ์ที่จำเป็นสำหรับงานเฉพาะกับสิทธิ์เข้าถึงชุดรูปภาพอย่างถาวร
- ตรวจสอบด้วยรูปทดสอบ ดูว่าหลังรับ เปิด บันทึก และลบ สำเนาใดยังคงอยู่ในแกลเลอรีหรือแอปอื่น
- ตรวจสอบวิธีกู้คืนก่อนลบข้อมูลแอป “ล้างแคช” “ล้างพื้นที่เก็บข้อมูล” และออกจากบัญชีให้ผลต่างกัน วิธีที่สองอาจลบกุญแจหรือข้อมูลในเครื่องที่จำเป็น
การทดสอบด้วยรูปที่ไม่อ่อนไหวมีประโยชน์ แต่การไม่พบไฟล์ในแกลเลอรีไม่ได้พิสูจน์ว่าไม่มีร่องรอยใดในอุปกรณ์
นักพัฒนาควรทดสอบการล้างอย่างไร?
การตรวจสอบควรครอบคลุมเส้นทางสื่อทั้งหมด: รับ ถอดรหัส แสดง แชร์ ปิดหน้า ออกจากบัญชี และเข้าสู่ระบบอีกครั้ง การดาวน์โหลดหรือสร้างภาพตัวอย่างที่กำลังทำงานต้องสอดคล้องกับนโยบายการออกจากบัญชี มิฉะนั้นอาจมีไฟล์ใหม่ถูกเขียนหลังล้างเสร็จ นี่คือสถานการณ์ที่ทดสอบได้ ไม่ใช่ข้ออ้างที่พิสูจน์แล้วเกี่ยวกับแอปส่งข้อความทุกตัว
ทดสอบกับเวอร์ชันที่ระบุชัด และบันทึกตำแหน่งไฟล์กับผลของแต่ละขั้นตอน คำแนะนำด้านความปลอดภัยของ Android เน้นการลดสิทธิ์เข้าถึงให้เหลือน้อยที่สุดและเก็บข้อมูลอ่อนไหวในตำแหน่งที่เหมาะสม
ประเด็นนี้บอกอะไรเกี่ยวกับ Livara?
แบบจำลองภัยคุกคามของ Livara ไม่รับประกันการปกป้องอุปกรณ์ที่ถูกบุกรุกหรือปลดล็อกอยู่ เอกสารการเข้ารหัสระหว่างส่งเพียงอย่างเดียวไม่ใช่หลักฐานของข้ออ้างว่า “ไม่มีสำเนาที่ไม่เข้ารหัสหลงเหลือในแคช” ข้ออ้างเช่นนี้ต้องตรวจสอบเวอร์ชันแอปที่ระบุและเส้นทางสื่อ
สรุป: รู้ตำแหน่งและจำนวนสำเนาของรูป การลดสำเนาส่วนเกิน ใช้การล็อกอุปกรณ์ที่เหมาะสม และอัปเดตเป็นเรื่องสำคัญ คำสัญญาว่า “กู้คืนไม่ได้เลย” โดยไม่มีการทดสอบและแบบจำลองภัยคุกคามไม่ใช่เกณฑ์ที่เชื่อถือได้
