เซิร์ฟเวอร์ของแอปส่งข้อความถูกเจาะไม่ได้แปลว่าข้อความทั้งหมดจะถูกอ่านเสมอไป ผลขึ้นอยู่กับข้อมูลที่จัดเก็บ ตำแหน่งของกุญแจ และระดับสิทธิ์ของผู้โจมตี แม้ข้อความแชตจะเข้ารหัสจากต้นทางถึงปลายทางอย่างถูกต้อง ข้อมูลบัญชี เวลา สมาชิกกลุ่ม และเส้นทางการส่งก็อาจเป็นข้อมูลอ่อนไหวได้
ในการประเมินเหตุการณ์ ให้ถามก่อนว่าผู้โจมตีได้อะไรไป: สำเนาฐานข้อมูล กุญแจของโครงสร้างพื้นฐาน เซิร์ฟเวอร์ที่ทำงานอยู่ หรือระบบเผยแพร่ซอฟต์แวร์? สถานการณ์เหล่านี้มีผลกระทบไม่เหมือนกัน
ฐานข้อมูลที่ถูกขโมยต่างจากเซิร์ฟเวอร์ที่ถูกควบคุม
ผู้โจมตีที่มีเพียงสำเนาฐานข้อมูลเก่าจะจำกัดอยู่กับข้อมูลที่บันทึกไว้ในนั้น การควบคุมบริการที่กำลังทำงานอาจทำให้บันทึกข้อมูลใหม่ ขโมยเซสชัน เปลี่ยนการตอบกลับ หรือพยายามแทนที่กุญแจของผู้ติดต่อได้ การเข้าถึงกระบวนการเผยแพร่ซอฟต์แวร์เป็นอีกความเสี่ยงหนึ่ง: โค้ดอันตรายบนเอนด์พอยต์อาจเห็นข้อความก่อนเข้ารหัสหรือหลังถอดรหัส
ดังนั้นคำกล่าวว่า “ฐานข้อมูลไม่มีกุญแจสำหรับข้อความ” จึงสำคัญ แต่ไม่ใช่คำตอบที่ครอบคลุมการบุกรุกทุกประเภท
เปรียบเทียบรูปแบบสถาปัตยกรรมห้าแบบ
นี่คือรูปแบบเพื่อการอธิบาย ไม่ใช่การจัดอันดับผลิตภัณฑ์ห้ารายการ บริการหนึ่งอาจใช้หลายรูปแบบสำหรับฟีเจอร์ที่ต่างกัน
| รูปแบบ | ข้อมูลที่เข้าถึงได้จากฐานข้อมูล | ขอบเขตสำคัญ |
|---|---|---|
| ข้อความและรหัสผ่านแบบไม่เข้ารหัส | อ่านเนื้อหาและข้อมูลรับรองได้โดยตรง | ข้อมูลทั้งสองประเภทไม่มีการป้องกันที่เหมาะสม |
| รหัสผ่านผ่านการแฮช แต่ข้อความไม่เข้ารหัส | อ่านเนื้อหาได้ และอาจทดสอบการเดารหัสผ่านได้ | คุณภาพของวิธีเก็บรหัสผ่านไม่ได้ป้องกันข้อความแชต |
| เนื้อหาเข้ารหัสด้วยกุญแจของเซิร์ฟเวอร์ | ข้อความเข้ารหัส การอ่านขึ้นอยู่กับการเข้าถึงกุญแจ | การแยกกุญแจออกจากข้อมูลอย่างแท้จริงมีความสำคัญ |
| แชต E2EE พร้อมข้อมูลสำรองที่ผู้ให้บริการเข้าถึงได้ | แชตสดอาจได้รับการป้องกัน แต่สำเนาประวัติมีเส้นทางรั่วไหลแยกต่างหาก | ต้องตรวจสอบนโยบายและกุญแจของข้อมูลสำรอง |
| แชต E2EE พร้อมการกู้คืนที่เข้ารหัสและกุญแจอิสระ | ข้อความเข้ารหัสและข้อมูลปฏิบัติการ การป้องกันเนื้อหาขึ้นอยู่กับการออกแบบและการป้องกันกุญแจ | อุปกรณ์ วลีกู้คืน และการยืนยันตัวตนผู้ติดต่อยังสำคัญ |
การเข้ารหัสดิสก์ของเซิร์ฟเวอร์มีประโยชน์เมื่อดิสก์ถูกขโมยไปโดยตรง แต่หากผู้โจมตีควบคุมบริการที่ทำงานอยู่หรือได้กุญแจถอดรหัสด้วย ก็ไม่ควรถือว่ายังมีการป้องกันแบบเดิม เป้าหมายของ E2EE คือบริการตัวกลางไม่มีกุญแจที่จำเป็นในการอ่านเนื้อหาที่ได้รับการป้องกัน
เมทาดาทาแสดงอะไรบ้าง?
เมทาดาทาอาจแสดงว่าบัญชีใดติดต่อกัน ใช้งานเมื่อใด เป็นสมาชิกกลุ่มใด และรับส่งข้อมูลมากเพียงใด ข้อมูลนี้ไม่ใช่ข้อความในแชต แต่มีคุณค่าในการทำความเข้าใจเครือข่ายความสัมพันธ์หรือรูปแบบกิจกรรม
หน้าความปลอดภัยของ Livara อธิบายอย่างชัดเจนถึงการเก็บและประมวลผลข้อมูลปฏิบัติการ เช่น การกำหนดเส้นทาง สมาชิก เวลา ขนาดข้อความเข้ารหัส และสถานะการส่ง ไม่ควรตีความการรักษาความลับของเนื้อหาส่วนตัวว่าเป็นการไม่เปิดเผยตัวตนอย่างสมบูรณ์ หรือไม่มีข้อมูลใดอยู่บนเซิร์ฟเวอร์เลย
SRP ไม่ได้ทำให้ข้อมูลบัญชีพ้นจากความเสี่ยงการเดา
SRP เป็นวิธีพิสูจน์ว่ารู้รหัสผ่านโดยไม่ต้องส่งรหัสผ่านนั้นโดยตรง เซิร์ฟเวอร์ยังคงเก็บข้อมูลตรวจสอบที่เรียกว่า verifier หัวข้อความปลอดภัยของ RFC 5054 อธิบายว่าการขโมย verifier อาจเปิดทางให้โจมตีแบบพจนานุกรมเพื่อเดารหัสผ่านได้
ดังนั้น “ไม่ส่งรหัสผ่านผ่านเครือข่าย” จึงต่างจาก “ไม่มีข้อมูลเกี่ยวกับรหัสผ่านให้ขโมย” รหัสผ่านที่ไม่ซ้ำและแข็งแรง การป้องกันอุปกรณ์ และการตอบสนองเหตุการณ์อย่างเหมาะสมยังจำเป็น SRP ไม่ได้ใช้แทนการเข้ารหัสเนื้อหาหรือการป้องกันเซสชันเข้าสู่ระบบเช่นกัน
Livara ประกาศขอบเขตอะไรไว้บ้าง?
เอกสารความปลอดภัยของ Livara อธิบาย LVR1 สำหรับข้อความโดยตรง และ LGS1 สำหรับกลุ่มที่ได้รับการป้องกัน การป้องกันกลุ่มขึ้นอยู่กับสถานะจริง กลุ่มเก่าที่ไม่รองรับไม่ควรถูกติดป้ายว่าเป็น E2EE ช่องสาธารณะอยู่นอกขอบเขตการรักษาความลับนี้
เอกสารเดียวกันอธิบายการกู้คืน v7 ว่าเป็นชุดข้อมูลตัวตนที่เข้ารหัสและได้รับการป้องกันก่อนอัปโหลด กระบวนการนี้กู้คืนตัวตนทางการเข้ารหัส ไม่ใช่ประวัติแชต การรั่วไหลของวลีกู้คืนหรืออุปกรณ์ที่เก็บกุญแจเป็นคนละสถานการณ์กับการขโมยฐานข้อมูลเพียงอย่างเดียว
สิ่งเหล่านี้เป็นคำอธิบายที่ผลิตภัณฑ์เผยแพร่ ไม่ใช่ผลการตรวจสอบอิสระโดยบทความนี้ การกล่าวถึง AES หรือ ML-KEM เพียงอย่างเดียวก็ไม่ได้พิสูจน์ว่าการจัดการกุญแจและการพัฒนาแอปถูกต้อง
ควรถามอะไรเมื่อมีประกาศเหตุการณ์?
- ช่วงเวลาและระบบใดได้รับผลกระทบ? คำกว้าง ๆ ว่า “ข้อมูลผู้ใช้” ยังไม่เพียงพอ
- เข้าถึงข้อความที่ไม่เข้ารหัส ไฟล์ กุญแจ verifier เซสชันเข้าสู่ระบบ หรือเพียงข้อความเข้ารหัสได้หรือไม่?
- ผู้โจมตีสามารถเปลี่ยนบริการหรือซอฟต์แวร์ที่ส่งถึงผู้ใช้ได้หรือไม่?
- ต้องดำเนินการใดผ่านช่องทางทางการ: ออกจากเซสชัน เปลี่ยนรหัสผ่าน อัปเดต หรือตรวจสอบตัวตนผู้ติดต่อ?
- คำแนะนำในการกู้คืนอาจทำให้ประวัติในเครื่องหายไปหรือไม่? อ่านข้อจำกัดก่อนลบแอป
อย่าใช้ลิงก์จากข้อความของคนที่ไม่รู้จักเพื่อ “ยืนยันบัญชีด่วน” ให้เปิดประกาศจากที่อยู่ทางการด้วยตนเอง แบบจำลองภัยคุกคามของ Livara มีประโยชน์ต่อการเข้าใจขอบเขตทั่วไป แต่ขอบเขตของเหตุการณ์จริงต้องกำหนดจากหลักฐานของเหตุการณ์นั้นเอง
