เปรียบเทียบต้นทุนของการทำงานที่ระบุชัดและหลักฐานสำหรับภัยคุกคามที่กำหนด ไม่ใช่แค่ภาพต้นไม้กับภาพกุญแจผู้ส่ง
Messaging Layer Security (MLS) และ LGS1 ของ Livara ไม่ใช่ใบรับรองความปลอดภัยแชตกลุ่มสองใบที่ใช้แทนกันได้ MLS เป็นมาตรฐานโปรโตคอลของ IETF ส่วน LGS1 เป็นการออกแบบเฉพาะผลิตภัณฑ์ที่ Livara จัดทำเอกสารไว้ การเปรียบเทียบอย่างเป็นธรรมต้องแยกสถาปัตยกรรม หลักฐานการนำไปใช้ และพฤติกรรมที่ผู้ใช้พบจริงออกจากกัน
ข้อแตกต่างหลักคือสถานะกลุ่มที่ใช้ร่วมกันแบบต้นไม้ กับกุญแจผู้ส่งที่แจกจ่ายผ่านเซสชันระหว่างสองฝ่าย ชื่อของระบบเพียงอย่างเดียวไม่ได้บอกว่าแอปใดจัดการสมาชิกที่ถูกนำออก อุปกรณ์ที่มีสถานะเก่า หรือกุญแจที่ถูกเจาะได้ถูกต้องหรือไม่
ความแตกต่างทางสถาปัตยกรรม
RFC 9420 กำหนด MLS สำหรับการสร้างกุญแจกลุ่มแบบอะซิงโครนัส โดยใช้ต้นไม้แรตเชตและช่วงสถานะของกลุ่ม พร้อมคุณสมบัติรักษาความลับย้อนหลังและความปลอดภัยหลังถูกเจาะภายใต้เงื่อนไขที่ระบุ โครงสร้างต้นไม้ช่วยลดต้นทุนการอัปเดตกุญแจบางส่วนเมื่อกลุ่มใหญ่ขึ้น
เอกสารความปลอดภัยของ Livara อธิบาย LGS1 ว่าเป็นสายโซ่ผู้ส่งที่มีลายเซ็นสำหรับสมาชิกแต่ละคน แจกจ่ายผ่านเซสชัน LVR1 ระหว่างสองฝ่าย และเปลี่ยนเมื่อสมาชิกเปลี่ยน นี่เป็นคำกล่าวอ้างของผลิตภัณฑ์ ไม่ใช่หลักฐานว่า LGS1 สอดคล้องกับ MLS หรือได้รับการวิเคราะห์แบบเดียวกัน
| คำถาม | MLS | เอกสาร Livara LGS1 |
|---|---|---|
| โครงสร้างร่วม | ต้นไม้แรตเชตและช่วงสถานะ | สายโซ่แยกสำหรับผู้ส่งแต่ละคน |
| การอัปเดตกุญแจ | ยืนยันการเปลี่ยนสถานะกลุ่มเข้าสู่ช่วงสถานะใหม่ | แจกจ่ายกุญแจผู้ส่งใหม่ให้สมาชิก |
| สถานะข้อกำหนด | มาตรฐาน IETF คือ RFC9420 | คำอธิบายเฉพาะผลิตภัณฑ์ที่เผยแพร่แล้ว |
| สิ่งที่ยังต้องประเมิน | การผสานเข้ากับแอปและการนำไปใช้ | ข้อกำหนดครบถ้วน การนำไปใช้ และหลักฐานอิสระ |
ตารางนี้อธิบายประเภทการออกแบบ ไม่ใช่ผลทดสอบสมรรถนะหรืออันดับความปลอดภัย
“ลอการิทึม” หมายถึงอะไร และไม่ได้หมายถึงอะไร
การอัปเดตเชิงการเข้ารหัสอาจใช้องค์ประกอบเส้นทางต้นไม้ที่เข้ารหัสจำนวนแบบลอการิทึม โดยไม่ได้ทำให้งาน ทั้งหมด ในระบบเป็นแบบลอการิทึม ข้อความยังต้องแจกจ่าย ไคลเอนต์ยังเก็บสถานะ และพฤติกรรมขึ้นกับโครงสร้างกลุ่มและการทำงาน การเปรียบเทียบเดิมที่ว่า “MLS ต้องใช้ O(log N) ข้อความ แต่ทุกอย่างใน LGS1 เร็วกว่า” ปะปนต้นทุนคนละชนิดและไม่มีผลวัดรองรับ
สถาปัตยกรรม MLS ใน RFC 9750 แยกบริการส่งข้อความออกจากการสร้างกุญแจเชิงการเข้ารหัส และกล่าวถึงการแจกจ่ายข้อความกับการเรียงลำดับการเปลี่ยนแปลงกลุ่ม การแยกนี้สำคัญ เพราะการคำนวณของไคลเอนต์ จำนวนไบต์ในคอมมิต ปริมาณการกระจายทั้งหมดจากเซิร์ฟเวอร์ และทราฟฟิกเมื่อเชื่อมต่อใหม่เป็นตัวชี้วัดคนละอย่าง
รายงานประสิทธิภาพที่มีความหมายควรระบุ:
- ขนาดกลุ่มและจำนวนอุปกรณ์ต่อคน
- การทำงานนั้นเป็นข้อความทั่วไป การนำสมาชิกออก การอัปเดตกุญแจ หรือการเชื่อมต่อใหม่
- จำนวนไบต์ที่ไคลเอนต์ผู้เริ่มต้นส่ง เทียบกับทราฟฟิกการส่งทั้งหมด
- เวลาที่ใช้ รุ่นอุปกรณ์ รุ่นของการนำไปใช้ และสภาพเครือข่าย
- ต้นทุนจากการพลาดอัปเดตและการเปลี่ยนสมาชิกซ้ำ ๆ
หากไม่มีรายละเอียดเหล่านี้ คำกล่าวอ้างว่า “ระดับมิลลิวินาที” “โอเวอร์เฮดสถานะต่ำ” หรือเหนือกว่าเมื่อกลุ่มมีขนาดใดขนาดหนึ่ง ยังไม่ได้รับการพิสูจน์
การนำสมาชิกออกเป็นการทดสอบวงจรชีวิต
การที่ผู้ดูแลนำบัญชีออกเป็นเพียงส่วนหนึ่งของเรื่องความปลอดภัย ไคลเอนต์ต้องเห็นตรงกันเรื่องสถานะสมาชิกใหม่ ใช้กุญแจใหม่ที่เหมาะสม และไม่ให้กุญแจเหล่านั้นแก่อุปกรณ์ที่ถูกกันออก ผู้ที่มีข้อความอ่านได้หรือกุญแจเก่าอยู่แล้วอาจยังเข้าถึงเนื้อหาเก่าได้ การนำออกไม่สามารถทำให้สำเนาของเขาหายไป
สำหรับทั้งสองระบบ การทดสอบที่มีประโยชน์ถามว่า: หลังนำออกเสร็จแล้ว อุปกรณ์ที่ถูกนำออกยังถอดรหัสข้อความทดสอบที่ไม่อ่อนไหวและเป็นข้อความ ใหม่ ได้หรือไม่? สมาชิกที่เคยออฟไลน์ตามอัปเดตได้อย่างปลอดภัยหรือไม่? ครอบคลุมอุปกรณ์ทุกเครื่องของบัญชีหรือไม่? อินเทอร์เฟซแสดงความล้มเหลวหรือการเปลี่ยนสมาชิกหรือไม่?
นี่เป็นคำถามที่เสนอให้ใช้ประเมิน ไม่ใช่ผลการทดสอบที่ดำเนินการในบทความนี้ การเปรียบเทียบผลิตภัณฑ์ควรเผยแพร่ผลที่สังเกตได้และรุ่นที่ทดสอบ แทนการถือว่าผู้ดูแลคลิกสำเร็จเท่ากับการกีดกันทางการเข้ารหัสสำเร็จ
การรักษาความลับย้อนหลังและการฟื้นตัวมีเงื่อนไข
การปกป้องข้อความเก่าหลังถูกเจาะในภายหลังขึ้นกับการเลิกใช้ข้อมูลลับเก่า การฟื้นการปกป้องข้อความในอนาคตขึ้นกับการนำความลับใหม่เข้ามาหลังผู้โจมตีสูญเสียการเข้าถึงที่เกี่ยวข้อง ใน MLS การประมวลผลอัปเดตกลุ่มเป็นส่วนหนึ่งของการฟื้นตัว แค่ส่งอัปเดตไม่เท่ากับสมาชิกทุกคนได้นำไปใช้แล้ว ดูข้อพิจารณาด้านความปลอดภัยใน RFC 9420
สำหรับการออกแบบกุญแจผู้ส่ง ให้ถามว่าสถานะที่ถูกเจาะของผู้ส่งแต่ละคนถูกแทนที่และแจกจ่ายใหม่อย่างไร ไม่ควรอธิบายว่าสายโซ่ทางเดียวเพียงอย่างเดียวฟื้นตัวอัตโนมัติจากผู้โจมตีที่รู้สถานะปัจจุบัน การป้องกันระหว่างสองฝ่ายขณะแจกจ่ายใหม่มีความเกี่ยวข้อง แต่ไม่แทนการวิเคราะห์ระดับกลุ่มอย่างครบถ้วน
คำกล่าวอ้างต้านทานควอนตัมต้องมีชุดการเข้ารหัสและขอบเขตที่ชัดเจน
ชุดการเข้ารหัสที่กำหนดใน RFC9420 พื้นฐานใช้กลไกกุญแจสาธารณะแบบดั้งเดิม MLS ขยายได้ ดังนั้นคำกล่าวอ้างเกี่ยวกับการนำไปใช้รายใดควรระบุชุดและส่วนขยายที่ใช้จริง แทนที่จะประกาศว่า MLS ทุกระบบจะเป็นแบบดั้งเดิมตลอดไป
การที่เอกสาร LGS1 ระบุว่าใช้การแจกจ่าย LVR1 แบบผสม เป็นคนละคำกล่าวอ้างกับการรับประกันต้านทานควอนตัมที่ผ่านการวิเคราะห์อิสระสำหรับทุกการทำงานของกลุ่ม FIPS 203 กำหนดมาตรฐาน ML-KEM แต่ไม่ได้รับรองโปรโตคอลกลุ่มทั้งชุดที่นำมันมาใช้ ประเมินการยืนยันตัวตน การเปลี่ยนสมาชิก การถูกเจาะกุญแจ และการนำไปใช้ร่วมกัน ไม่ใช่ดูแค่ชื่อ KEM
สิ่งที่ควรขอก่อนตัดสินใจเลือกผลิตภัณฑ์
ขอข้อกำหนดโปรโตคอลปัจจุบัน เวกเตอร์ทดสอบ และการทบทวนอิสระที่ตรงกับรุ่น รวมถึงข้อค้นพบที่ยังไม่แก้ไข จากนั้นเปรียบเทียบความต้องการทั่วไปของผลิตภัณฑ์ ได้แก่ อุปกรณ์ที่รองรับ พฤติกรรมการอัปเดต การกู้คืน บทบาทดูแล และข้อมูลที่เซิร์ฟเวอร์เก็บรักษา
สถาปัตยกรรม MLS พิจารณาบริการของแอปและสมมติฐานความไว้วางใจอย่างชัดเจน เช่นเดียวกัน ควรอ่านแบบจำลองภัยคุกคามของ Livara ควบคู่กับคำกล่าวอ้างของผลิตภัณฑ์ การเข้ารหัสไม่ได้ทำให้ผู้ร่วมสนทนาที่ได้รับอนุญาตน่าไว้วางใจ ไม่ได้หยุดการจับภาพหน้าจอ และไม่ได้กำจัดเมทาดาทาทุกรูปแบบ
หากขาดหลักฐาน ให้บันทึกว่า “ยังไม่พิสูจน์” แทนการระบุทันทีว่าการออกแบบไม่ปลอดภัยหรือเหนือกว่า การตัดสินใจควรสะท้อนความเสี่ยงของกลุ่มและคุณภาพของหลักฐานที่มี
คำถามที่พบบ่อย
LGS1 เป็นการนำ MLS ไปใช้หรือไม่?
คำอธิบายที่เผยแพร่แสดงสถาปัตยกรรมต่างกัน บทความนี้ไม่ได้ระบุว่า LGS1 เป็นการนำ MLS ไปใช้ และไม่ได้อ้างว่าสามารถทำงานร่วมกันได้
MLS ต้องให้สมาชิกทุกคนออนไลน์พร้อมกันหรือไม่?
ไม่ต้อง การใช้งานแบบอะซิงโครนัสเป็นส่วนหนึ่งของการออกแบบ แต่แอปยังต้องมีนโยบายสำหรับอัปเดตล่าช้า สถานะเก่า และสมาชิกที่ออฟไลน์นาน
การแจกจ่ายกุญแจต้านทานควอนตัมทำให้เรื่องความปลอดภัยกลุ่มจบลงหรือไม่?
ไม่ มันจัดการส่วนหนึ่งของการสร้างกุญแจ ตัวตน สมาชิก วงจรชีวิตกุญแจ ความปลอดภัยจุดปลายทาง และการนำไปใช้ยังต้องมีหลักฐาน
การออกแบบใดเร็วกว่า?
บทความนี้ไม่มีผลทดสอบสมรรถนะที่ตัดสินผู้ชนะ ควรวัดการทำงานและสภาพแวดล้อมการใช้งานที่สำคัญต่อกลุ่มของคุณ
