ยึดหรือเจาะเซิร์ฟเวอร์แชต: ข้อมูลใดเสี่ยงบ้าง?

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

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

เริ่มจากระบุประเภทการเข้าถึง

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

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

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

ตามเอกสารของ Livara เซิร์ฟเวอร์มองเห็นข้อมูลอะไรบ้าง?

หน้าความปลอดภัยของ Livara ที่ระบุเวอร์ชัน 0.1.68 แยกเนื้อหาการสนทนาโดยตรงภายใต้ LVR1 และกลุ่มส่วนตัวที่รองรับ LGS1 ออกจากข้อมูลด้านการทำงาน หน้าเดียวกันระบุชัดเจนว่ากลุ่มเก่าที่เข้ากันไม่ได้ยังอยู่นอกขอบเขต E2EE ดังนั้นจึงต้องตรวจสอบสถานะของการสนทนานั้นโดยเฉพาะ

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

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

ตารางนี้อธิบายคำกล่าวอ้างของผลิตภัณฑ์ ไม่ใช่ผลการทดลองยึดเซิร์ฟเวอร์จริง หรือผลการตรวจสอบอิสระของสำเนาฐานข้อมูลทั้งหมด

เมทาดาทาสำคัญได้มากเพียงใด?

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

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

การควบคุมเซิร์ฟเวอร์ก่อความเสี่ยงใดต่อข้อความในอนาคต?

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

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

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

คุณสมบัติหลังยุคควอนตัมช่วยเพิ่มอะไร?

มาตรฐาน NIST FIPS 203 สำหรับ ML-KEM ช่วยสร้างความลับร่วม การใช้อย่างถูกต้องในโครงสร้างแบบไฮบริดอาจลดความเสี่ยงจากการโจมตีการแลกเปลี่ยนกุญแจบางชนิดในอนาคตได้ แต่คุณสมบัตินี้ไม่ทดแทนความปลอดภัยของอุปกรณ์ การจำกัดการเก็บเมทาดาทา หรือการควบคุมการเข้าถึงเซิร์ฟเวอร์

Proof Lab ก็แสดงเพียงการทำงานบางส่วนของ P-256, HKDF และ AES-GCM ภายในเครื่อง และระบุว่าโครงสร้าง LVR1/LGS1 แบบครบถ้วนอยู่นอกขอบเขตการทดลองนั้น ผลสำเร็จไม่ได้รับประกันว่าผลิตภัณฑ์ทั้งหมดจะต้านทานการยึดครองโครงสร้างพื้นฐานได้

ควรทำอย่างไรในการประเมินหรือเหตุการณ์จริง?

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

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