การนำใครออกจากกลุ่มที่เข้ารหัสควรทำให้คนนั้นหยุดได้รับข้อมูลลับที่จำเป็นสำหรับข้อความที่ได้รับการปกป้องในอนาคต การเปลี่ยนรายชื่อสมาชิกเพียงอย่างเดียวไม่ทำให้เกิดผลนั้น หากผู้ส่งที่เหลือยังใช้วัสดุกุญแจที่อดีตสมาชิกรู้อยู่แล้ว
การเปลี่ยนสถานะไม่ได้เกิดขึ้นทันทีทั่วเครือข่ายที่ไม่น่าเชื่อถือด้วย การออกแบบกลุ่มที่ปลอดภัยต้องกำหนดว่าข้อความหนึ่งอยู่ในสถานะสมาชิกใด และผู้ส่งทำอะไรหากยังไม่ได้ประมวลผลการนำสมาชิกออก
ข้อความในอดีตกับอนาคตเป็นคนละปัญหา
อดีตสมาชิกอาจเก็บข้อความ ไฟล์ และกุญแจที่ได้รับขณะยังมีสิทธิ์ไว้ได้ การนำออกไม่สามารถทำให้คนนั้นลืมประวัติหรือลบภาพหน้าจอของเขา
เป้าหมายที่ทำได้คือกีดกันคนนั้นจากสถานะการเข้ารหัสใหม่หลังการนำออกมีผล เช่นเดียวกัน การเพิ่มคนก่อให้เกิดคำถามอีกข้อว่าเขาจะเข้าถึงประวัติเก่าได้หรือไม่ ผลิตภัณฑ์และโปรโตคอลใช้คำอย่าง forward secrecy ในบริบทต่างกัน ดังนั้นการอธิบายกฎการเข้าถึงที่ตั้งใจไว้ด้วยภาษาตรงไปตรงมามักชัดเจนกว่าป้ายกำกับที่กำกวม
เหตุใดกลุ่มแบบกุญแจผู้ส่งจึงต้องมีสถานะใหม่
ในการออกแบบแบบกุญแจผู้ส่ง ผู้เข้าร่วมแต่ละคนสามารถเข้ารหัสข้อความกลุ่มทั่วไปด้วยสายโซ่ที่แบ่งปันกับผู้รับที่ได้รับอนุญาต วิธีนี้อาจหลีกเลี่ยงการต้องเข้ารหัสเนื้อหาทั้งหมดแยกให้ผู้รับแต่ละคนทุกครั้งที่ส่ง
หลังนำออก อดีตสมาชิกอาจยังมีสายโซ่เดิม ดังนั้นผู้ส่งที่เหลือจึงต้องมีสถานะทดแทนที่ไม่แจกให้สมาชิกที่ถูกกีดกัน และไคลเอนต์ต้องมีบริบทสมาชิกที่ตกลงร่วมกันในการใช้มัน การหมุนเวียนกุญแจต้องครอบคลุมผู้ส่งและอุปกรณ์ที่เกี่ยวข้อง การเปลี่ยนแฟล็กฝั่งเซิร์ฟเวอร์เพียงตัวเดียวไม่เพียงพอ
รายละเอียดของโปรโตคอลมีความสำคัญ MLS ที่ระบุใน RFC 9420 จัดการการนำออกผ่านการเปลี่ยน epoch ที่คอมมิตแล้ว ซึ่งให้เอนโทรปีใหม่แก่สมาชิกที่เหลือ นี่เป็นตัวอย่างการเปลี่ยนสถานะที่กำหนดไว้ชัดเจน ไม่ใช่ข้อกล่าวอ้างว่า Livara ใช้ MLS
สิ่งที่ Livara ระบุเกี่ยวกับ LGS1
หน้าความปลอดภัย ของ Livara อธิบายว่ามีสายโซ่ผู้ส่งที่ลงลายเซ็นหนึ่งสายต่อผู้ส่ง โดยแจกกุญแจผู้ส่งผ่านเซสชัน LVR1 แบบคู่ต่อคู่ และระบุว่าจะสร้างและแจกกุญแจผู้ส่งใหม่เมื่อสมาชิกเปลี่ยนแปลง
สิ่งนี้รองรับข้อกล่าวอ้างเกี่ยวกับการออกแบบการเปลี่ยนกุญแจที่เผยแพร่แล้ว แต่ไม่ได้ยืนยันระยะเวลา “เพิกถอนทันที” ที่ผ่านการวัด และไม่ได้พิสูจน์ว่าทุกภาวะแข่งขัน สถานการณ์อุปกรณ์ออฟไลน์ และการลองใหม่ถูกจัดการอย่างถูกต้อง เรื่องเหล่านี้ต้องอาศัยการวิเคราะห์การนำไปใช้และการทดสอบ
การควบคุมสมาชิกฝั่งเซิร์ฟเวอร์กับการกีดกันด้วยการเข้ารหัสยังทำหน้าที่ต่างกัน บริการสามารถปฏิเสธการนำส่งหรือการเข้าถึง ส่วนการเข้ารหัสควรป้องกันฝ่ายที่ถูกกีดกันซึ่งมีสำเนาข้อความเข้ารหัสในภายหลัง ไม่ให้เปิดได้หากไม่มีข้อมูลลับชุดใหม่
แผนทดสอบการนำออกที่มีประโยชน์
สำหรับกลุ่มทดสอบที่ได้รับอนุญาต ให้ตรวจสอบสถานการณ์เหล่านี้ด้วยข้อความที่ไม่อ่อนไหว:
| สถานการณ์ | คำถามที่ควรตอบได้ |
|---|---|
| นำสมาชิกออกขณะทุกคนออนไลน์ | ข้อความใดเป็นข้อความแรกภายใต้สถานะสมาชิกใหม่? |
| ผู้ส่งที่เหลือคนหนึ่งออฟไลน์ | ต้องรีเฟรชสมาชิกและกุญแจก่อนส่งอีกครั้งหรือไม่? |
| สมาชิกที่ถูกนำออกกลับมาเชื่อมต่อภายหลัง | รับกุญแจผู้ส่งชุดใหม่ที่แจกได้หรือได้เฉพาะเนื้อหาเก่าที่เคยมีสิทธิ์? |
| สมาชิกหลายคนเปลี่ยนพร้อมกัน | อุปกรณ์ที่เหลือทั้งหมดเข้าสู่สถานะเดียวกันหรือไม่? |
| ลองส่งข้อความเก่าอีกครั้ง | ยังคง epoch เดิมแทนที่จะระบุผิดว่าเป็นเนื้อหาใหม่หรือไม่? |
การทดสอบเฉพาะ UI ยืนยันพฤติกรรมที่มองเห็นได้ แต่เพียงอย่างเดียวไม่สามารถพิสูจน์การกีดกันด้วยการเข้ารหัส การประเมินอย่างเข้มงวดต้องตรวจว่าอุปกรณ์ทดสอบที่ถูกกีดกันรับกุญแจและข้อความเข้ารหัสใดได้บ้าง
สิ่งที่ผู้ดูแลควรจำ
นำผู้เข้าร่วมที่ไม่จำเป็นออก ทบทวนสมาชิกที่เหลือ และหลีกเลี่ยงส่งข้อมูลอ่อนไหวใหม่จนกว่าแอปจะประมวลผลการเปลี่ยนแปลง หากผู้เข้าร่วมปัจจุบันจงใจส่งต่อเนื้อหา การเปลี่ยนกุญแจกลุ่มไม่สามารถป้องกันการเปิดเผยนั้น
สำหรับการใช้งานที่อ่อนไหวมาก ให้ถามผู้ให้บริการถึงความหมายที่แน่นอนของการนำออก พฤติกรรมการเพิกถอนอุปกรณ์ และหลักฐานการทดสอบ คำมั่นสำคัญคือขอบเขตที่ชัดเจนสำหรับข้อความในอนาคต ไม่ใช่ข้อกล่าวอ้างไร้หลักฐานว่าปุ่มนำออกทำลายสำเนาทุกชุดในอดีต
