เมื่อประเมินความปลอดภัยของการโทร อย่าถามเพียงว่า “เข้ารหัสหรือไม่” แต่ให้ถามว่าการเข้ารหัสสิ้นสุดที่ใด และการบันทึกเปลี่ยนแปลงอะไรบ้าง
การเข้ารหัสแชตเพียงอย่างเดียวไม่ได้พิสูจน์ว่าเสียง วิดีโอ การแชร์หน้าจอ หรือการบันทึกการโทรได้รับการปกป้องแบบเดียวกันด้วย ในการประเมินการโทร ควรถามว่า สื่อยังคงถูกเข้ารหัสไปจนถึงจุดใด ใครถือกุญแจ และการเปิดใช้คุณสมบัติอย่างการบันทึกเปลี่ยนแปลงอะไรบ้าง
คู่มือนี้แยกข้ออ้างด้านความปลอดภัยออกเป็นชั้นต่าง ๆ ที่ตรวจสอบได้ ชื่อโพรโทคอลหรือสัญลักษณ์แม่กุญแจไม่อาจใช้แทนคำตอบของคำถามเหล่านี้
สามเส้นทางที่ต่างกันในแอปเดียว
| เส้นทาง | ตัวอย่างข้อมูล | คำถามด้านความปลอดภัย |
|---|---|---|
| ข้อความที่จัดเก็บไว้ | ข้อความ รูปภาพ ไฟล์ และข้อความเสียง | ใครอ่านสำเนาบนอุปกรณ์ เซิร์ฟเวอร์ และข้อมูลสำรองได้บ้าง? |
| สื่อสด | เสียงจากไมโครโฟน วิดีโอ และการแชร์หน้าจอ | การเข้ารหัสสิ้นสุดที่อุปกรณ์ของผู้รับหรือที่เซิร์ฟเวอร์ตัวกลาง? |
| สัญญาณควบคุมการเชื่อมต่อ | คำเชิญเข้าร่วมการโทร การตอบรับ และข้อมูลประสานการเชื่อมต่อ | ใครแก้ไขข้อความควบคุมหรือตัวตนของปลายทางได้บ้าง? |
ข้อความเสียงที่ส่งในแชตเป็นไฟล์ ส่วนการโทรด้วยเสียงเป็นสตรีมสด ผลิตภัณฑ์หนึ่งอาจใช้กุญแจและกลไกที่แตกต่างกันสำหรับสองอย่างนี้ คุณภาพเสียงที่ดีหรือข้อความที่ส่งไปไม่ถึงก็ไม่ได้บอกอะไรเกี่ยวกับความปลอดภัยของอีกอย่างหนึ่งด้วยตัวมันเอง
DTLS-SRTP บอกอะไรได้บ้าง?
ใน WebRTC นั้น SRTP ปกป้องสตรีมสื่อ ส่วน DTLS-SRTP เป็นวิธีหนึ่งในการจัดตั้งข้อมูลกุญแจที่ใช้กับสตรีมนั้น RFC 5764 อธิบายกลไก DTLS-SRTP และ RFC 3711 อธิบายการปกป้องแพ็กเก็ตสื่อ
แต่คำว่า “เราใช้ WebRTC” เพียงอย่างเดียวไม่ได้ตอบว่าเซิร์ฟเวอร์การประชุมถอดรหัสสื่อหรือไม่ ต้องระบุให้ชัดเจนว่าจุดปลายของการเข้ารหัสอยู่ที่ใดและยืนยันตัวตนของจุดเหล่านั้นอย่างไร การเชื่อมต่อระหว่างผู้ใช้กับเซิร์ฟเวอร์อาจถูกเข้ารหัส แต่เซิร์ฟเวอร์อาจเข้าถึงเนื้อหาที่ถอดรหัสแล้วเพื่อประมวลผลหรือบันทึก สถานการณ์นี้ไม่เหมือนกับ E2EE ระหว่างผู้เข้าร่วม
สถาปัตยกรรมความปลอดภัยของ WebRTC ใน RFC 8827 ยังแสดงให้เห็นว่า ความไว้วางใจในเว็บแอป เส้นทางของสัญญาณควบคุม และตัวตนของอีกฝ่ายมีความสำคัญควบคู่ไปกับการปกป้องสื่อ การเข้ารหัสแพ็กเก็ตไม่ได้หมายความว่าส่วนประกอบทั้งหมดของผลิตภัณฑ์เชื่อถือได้
ทำไมต้องประเมินสัญญาณควบคุมแยกต่างหาก?
สัญญาณควบคุมประสานว่าใครจะโทรหาใครและจะสร้างการเชื่อมต่ออย่างไร หากแอปปกป้องข้อความควบคุม ก็ยังต้องตรวจสอบว่าการปกป้องนั้นผูกกับตัวตนที่แท้จริงของผู้เข้าร่วมและกุญแจของสื่ออย่างไร
ในการอ่านเอกสาร ให้เริ่มจากคำถามสามข้อนี้:
- คำเชิญ การตอบรับ และข้อมูลกุญแจได้รับการปกป้องจากการแก้ไขหรือไม่?
- ผู้ใช้รู้ได้อย่างไรว่ากุญแจเป็นของบุคคลที่ต้องการติดต่อจริง?
- เมื่อกุญแจหรืออุปกรณ์เปลี่ยน จะมีคำเตือนใดแสดงขึ้น?
บริการอาจทราบข้อมูลการกำหนดเส้นทาง เวลา และผู้เข้าร่วมการโทร แม้จะเป็นการโทรแบบ E2EE ก็ตาม คำอธิบายเมทาดาทาของแอปรับส่งข้อความกล่าวถึงความแตกต่างนี้
การบันทึกการโทรคือขอบเขตความปลอดภัยใหม่
คำว่า “การโทรที่เข้ารหัส” ไม่ได้ให้คำตอบครบถ้วนเกี่ยวกับสำเนาที่บันทึกไว้ ผู้เข้าร่วมสามารถใช้อุปกรณ์ของตนบันทึกเสียงหรือภาพได้ การบันทึกฝั่งเซิร์ฟเวอร์ก็ควรมีเอกสารอธิบายแยกต่างหากด้วยว่า เซิร์ฟเวอร์เข้าถึงสื่อในรูปแบบที่อ่านได้เพื่อบันทึกหรือไม่ ใครเก็บไฟล์ไว้ และไฟล์จะถูกลบเมื่อใด?
หากการเปิดบันทึกเปลี่ยนโหมดความปลอดภัย ผู้เข้าร่วมต้องเห็นการเปลี่ยนแปลงนี้อย่างชัดเจน ก่อนสนทนาเรื่องละเอียดอ่อน ให้ตรวจสอบสถานะการบันทึกและความยินยอมของทุกคน การที่ตัวบ่งชี้การบันทึกภายในแอปไม่ทำงานไม่ได้รับประกันว่าจะไม่มีใครใช้อุปกรณ์อื่นบันทึกอยู่
ควรอ่านเอกสารปัจจุบันของ Livara อย่างไร?
หน้าความปลอดภัยของ Livara อธิบายว่าการโทรโดยตรงและการโทรแบบกลุ่มใช้ E2EE แต่ ระบุว่าการบันทึกฝั่งเซิร์ฟเวอร์ซึ่งเลือกเปิดได้เป็นข้อยกเว้น: ในโหมด REC ที่แสดงให้เห็น การปกป้องการโทรจะเปลี่ยนเป็นการเข้ารหัสระหว่างการรับส่งข้อมูล นี่คือข้ออ้างในเอกสารของผลิตภัณฑ์ ไม่ใช่ผลการทดสอบหรือการตรวจสอบอิสระของบทความนี้
ข้อความเก่าที่จำกัดการโทรแบบกลุ่มทั้งหมดไว้ที่ “ผู้ใช้ Android 2 ถึง 6 คน” ไม่สอดคล้องกับเอกสารปัจจุบันและไม่ได้นำมาใช้เป็นพื้นฐานของคู่มือนี้ สำหรับความจุ แพลตฟอร์ม และเวอร์ชันที่ต้องการ ควรตรวจสอบคำแนะนำปัจจุบันและพฤติกรรมจริงของแอป บทความนี้ไม่ได้นำเสนอผลทดสอบความจุ
นอกจากนี้ ชื่ออัลกอริทึมของแชต เช่น ML-KEM เพียงอย่างเดียวไม่ได้พิสูจน์ว่าใช้กับสื่อการโทรด้วย การกล่าวอ้างว่าการโทรใช้การเข้ารหัสหลังยุคควอนตัมต้องมีหลักฐานเฉพาะสำหรับเส้นทางสื่อและการยืนยันตัวตน อ่านแบบจำลองภัยคุกคามของ Livara ควบคู่กับหน้าคุณสมบัติ ไม่ใช่ใช้แทนการทดสอบอิสระ
รายการตรวจสอบสั้น ๆ ก่อนเปรียบเทียบสองบริการ
สำหรับทุกข้อที่ตอบว่า “ใช่” ให้จดชื่อเวอร์ชันและแหล่งข้อมูลด้วย:
- มีคำอธิบายแยกสำหรับการโทรสองคน การโทรแบบกลุ่ม และการแชร์หน้าจอหรือไม่?
- ระบุชัดหรือไม่ว่าเซิร์ฟเวอร์เพียงส่งต่อแพ็กเก็ต หรือสามารถถอดรหัสสื่อได้ด้วย?
- สามารถตรวจสอบตัวตนและกุญแจของผู้เข้าร่วมได้หรือไม่?
- มีการแสดงอย่างชัดเจนหรือไม่เมื่อเปลี่ยนอุปกรณ์ เพิ่มสมาชิก หรือเปิดการบันทึก?
- เส้นทางการโทรบนเว็บกับในแอปเหมือนกันหรือต่างกัน?
- มีคำอธิบายเรื่องการเก็บรักษาไฟล์บันทึกและเมทาดาทาหรือไม่?
- หลักฐานการทดสอบหรือการตรวจสอบเกี่ยวข้องกับเวอร์ชันและคุณสมบัติเดียวกันหรือไม่?
หากเอกสารไม่มีคำตอบ ให้เขียนว่า “ไม่ทราบ” การไม่มีคำตอบไม่ใช่ทั้งหลักฐานยืนยันความปลอดภัยและหลักฐานยืนยันการดักฟัง
คำถามที่พบบ่อย
การโทรแบบ E2EE ป้องกันไม่ให้อีกฝ่ายบันทึกได้หรือไม่?
ไม่ได้ ผู้รับที่ได้รับอนุญาตเข้าถึงเนื้อหาในรูปแบบที่อ่านได้ และอาจบันทึกด้วยซอฟต์แวร์หรืออุปกรณ์อื่น
การเข้ารหัสระหว่างการรับส่งข้อมูลเป็นสิ่งไม่ดีหรือไม่?
การเข้ารหัสระหว่างการรับส่งข้อมูลให้การปกป้องที่สำคัญจากการดักฟังระหว่างทาง ความแตกต่างคือบริการที่เป็นจุดปลายสามารถเข้าถึงเนื้อหาที่ถอดรหัสแล้วได้ จึงไม่ควรเรียกสิ่งนี้ว่า E2EE ระหว่างผู้ใช้
การใช้การเข้ารหัสหลังยุคควอนตัมในแชตทำให้การโทรเป็นแบบหลังยุคควอนตัมด้วยหรือไม่?
ไม่ ข้ออ้างต้องเกี่ยวข้องกับชั้น อัลกอริทึม และเวอร์ชันการนำไปใช้เดียวกัน ควรประเมินแชตและการโทรแยกกัน
