การเข้ารหัสจากต้นทางถึงปลายทางไม่ได้กำหนดให้แอปส่งข้อความต้องหลีกเลี่ยงการจัดเก็บส่วนกลาง เซิร์ฟเวอร์สามารถเก็บข้อความที่เข้ารหัสเพื่อซิงค์ได้โดยไม่ถือข้อมูลลับที่จำเป็นต่อการอ่านเนื้อหา
ส่วนที่ยากของการส่งข้อความหลายอุปกรณ์คือการตัดสินใจว่าอุปกรณ์ใดได้รับอนุญาต ได้รับกุญแจใด และเข้าถึงประวัติเก่าได้หรือไม่ การตัดสินใจเหล่านี้สำคัญกว่าการที่ระบบใช้ฐานข้อมูลหรือไม่
สี่การทำงานที่ต่างกันแต่มักเรียกรวมว่า “ซิงค์”
| การทำงาน | สิ่งที่ต้องทำให้สำเร็จ |
|---|---|
| ส่งข้อความใหม่ | ส่งเนื้อหาที่ได้รับการปกป้องไปยังอุปกรณ์ที่ได้รับอนุญาตในปัจจุบัน |
| เชื่อมโยงอุปกรณ์ใหม่ | ยืนยันว่าเจ้าของบัญชีอนุมัติปลายทางใหม่นี้ |
| โอนประวัติ | ให้อุปกรณ์ใหม่เข้าถึงเนื้อหาเก่าที่เลือกไว้และวัสดุสำหรับถอดรหัส |
| กู้คืนตัวตน | กู้คืนหรือแทนที่กุญแจตัวตนโดยไม่จำเป็นต้องกู้คืนประวัติข้อความ |
ผลิตภัณฑ์อาจรองรับหนึ่งการทำงานโดยไม่รองรับทั้งสี่อย่าง การลงชื่อเข้าใช้สำเร็จไม่ได้พิสูจน์ว่ากู้คืนประวัติแชตเก่าได้
การนำส่งแบบเข้ารหัสรองรับหลายอุปกรณ์ได้อย่างไร
วิธีหนึ่งคือรักษาเซสชันแยกสำหรับแต่ละอุปกรณ์ ข้อกำหนด Sesame ของ Signal อธิบายการจัดการเซสชันในสภาพแวดล้อมหลายอุปกรณ์แบบอะซิงโครนัส รวมถึงการเพิ่มหรือลบอุปกรณ์และข้อความที่มาถึงไม่ตามลำดับ
นี่เป็นตัวอย่างการออกแบบที่มีเอกสาร ไม่ใช่ข้อกำหนดสากล ระบบอื่นอาจเข้ารหัสเนื้อหาครั้งเดียวแล้วแจกกุญแจเนื้อหาที่ได้รับการปกป้อง ใช้กลไกกลุ่ม หรือผสมหลายวิธี คำกล่าวว่า “E2EE ต้องทำสำเนาเพย์โหลดทั้งหมดสำหรับทุกอุปกรณ์” จึงกว้างเกินไป
ไม่ว่าจะเลือกการออกแบบใด การเพิ่มอุปกรณ์ที่ถอดรหัสได้คือการเพิ่มปลายทางที่ต้องปกป้อง แล็ปท็อปที่ถูกละเลยอาจเปิดเผยข้อความธรรมดาที่ได้รับ แม้เซิร์ฟเวอร์ไม่เคยเห็นข้อความธรรมดานั้นเลย
ข้อความเข้ารหัสที่จัดเก็บยังมีผลต่อความเป็นส่วนตัวและการเก็บรักษา
การจัดเก็บแบบเข้ารหัสไม่เหมือนกับการไม่จัดเก็บ ผู้ให้บริการอาจเก็บข้อมูลการนำส่ง บันทึกอุปกรณ์ เวลา สมาชิก หรือประวัติข้อความเข้ารหัส รายละเอียดแตกต่างกันและควรระบุให้ชัดเจน
เอกสารความปลอดภัย ของ Livara ระบุว่ารีเลย์เก็บข้อความเข้ารหัสและข้อมูลการทำงานเพื่อการซิงค์และการกู้คืนหลังเชื่อมต่อใหม่ โดยอธิบายข้อมูลเส้นทาง สมาชิก เวลา สถานะการนำส่ง และบันทึกอื่น ๆ จึงไม่ควรบรรยายว่าเป็นคิวชั่วคราวที่ไม่มีเอกสารและย่อมหายไปทันทีที่ทุกอุปกรณ์ได้รับข้อความ
ดังนั้นความลับของเนื้อหากับการเก็บรักษาเมทาดาทาจึงต้องตั้งคำถามแยกกัน ถามว่าเก็บอะไร นานแค่ไหน และการลบข้อมูลหรือลบบัญชีเปลี่ยนแปลงอะไร อย่าสร้างระยะเวลาเก็บรักษาขึ้นเองหากยังไม่ได้ยืนยัน
การกู้คืน v7 ของ Livara กู้คืนอะไรจริง ๆ
Livara อธิบาย v7 ว่าเป็นข้อมูลสำรองตัวตนที่เข้ารหัสและผนึกก่อนอัปโหลดด้วยกุญแจกู้คืนแบบสุ่มขนาด 256 บิต เพย์โหลดตามเอกสารประกอบด้วยวัสดุกุญแจตัวตน และรูปแบบข้อมูลตรวจสอบความแท้ของชุดอัลกอริทึม epoch ของตัวตน และรุ่นการสร้าง
หน้าเดียวกันระบุว่ากู้คืนตัวตน ไม่ใช่ประวัติแชต จึงไม่ควรนำเสนอวลีกู้คืนว่าเป็นการรับประกันว่าอุปกรณ์ใหม่จะแสดงบทสนทนาเก่าทั้งหมดได้
ก่อนเปลี่ยนหรือล้างอุปกรณ์ ให้ตรวจสอบตัวเลือกโอนประวัติและสำรองข้อมูลที่คุณใช้ได้จริงในปัจจุบัน เก็บข้อมูลกู้คืนทุกอย่างเป็นความลับ อย่าส่งวลีกู้คืนให้บัญชีฝ่ายสนับสนุนหรือวางลงในเว็บไซต์ที่ยังไม่ได้ตรวจสอบ
Forward secrecy ไม่ได้ลบกล่องข้อความของอุปกรณ์ที่ได้รับอนุญาต
กลไกแรตเช็ตอาจจำกัดสิ่งที่การรั่วไหลของกุญแจในภายหลังเปิดเผยเกี่ยวกับการสื่อสารเข้ารหัสก่อนหน้า เมื่อสมมติฐานเป็นจริงและลบข้อมูลลับที่เลิกใช้แล้ว แต่ไม่สามารถซ่อนข้อความธรรมดาที่ปลายทางเก็บไว้แล้ว หรือหยุดมัลแวร์ที่ยังทำงานอยู่ไม่ให้อ่านข้อความใหม่
ในทำนองเดียวกัน ความปลอดภัยหลังถูกเจาะต้องอาศัยการอัปเดตใหม่ที่เหมาะสมหลังผู้โจมตีสูญเสียการเข้าถึง ไม่ใช่คำมั่นว่าแท็บเล็ตเก่าจะปลอดพิษภัยทุกครั้งที่ตัวนับข้อความเพิ่มขึ้น
รายการตรวจสอบเพื่อเปลี่ยนอุปกรณ์อย่างปลอดภัยขึ้น
- สำรวจอุปกรณ์ที่เชื่อมโยงอยู่ก่อนเพิ่มอีกเครื่อง
- ใช้ขั้นตอนเชื่อมโยงและตรวจสอบตามเอกสารของแอป ไม่ใช่คิวอาร์โค้ดที่คนแปลกหน้าส่งมา
- ตรวจว่าอุปกรณ์ใหม่ได้รับประวัติใดด้วยบทสนทนาทดสอบที่ไม่มีข้อมูลอ่อนไหว
- ยืนยันข้อมูลกู้คืนและข้อมูลสำรองประวัติที่แยกต่างหากก่อนล้างอุปกรณ์เก่า
- เพิกถอนอุปกรณ์ที่คุณไม่ได้ควบคุมแล้ว และตรวจว่าคู่สนทนาได้รับแจ้งการเปลี่ยนตัวตนหรือไม่
- ทบทวนไฟล์ดาวน์โหลดในเครื่อง การแจ้งเตือน และข้อมูลสำรองระบบปฏิบัติการในทุกปลายทาง
แบบจำลองภัยคุกคามของ Livara รวมข้อจำกัดด้านปลายทางและผู้รับไว้อย่างชัดเจน ข้อจำกัดเหล่านี้ยังสำคัญบนทุกหน้าจอ คำมั่นเรื่องหลายอุปกรณ์ที่มีประโยชน์ต้องอธิบายการอนุญาตอุปกรณ์ ข้อมูลที่จัดเก็บ และขอบเขตการกู้คืนแยกกัน
