ความคล่องตัวทางการเข้ารหัสในการส่งข้อความ: อัปเกรดโพรโทคอลอย่างปลอดภัย

ความคล่องตัวทางการเข้ารหัสคือความสามารถในการย้ายโพรโทคอลจากชุดอัลกอริทึมการเข้ารหัสหนึ่งไปยังอีกชุดหนึ่ง โดยยังคงข้อกำหนดด้านความปลอดภัยที่ชัดเจนไว้ ในการส่งข้อความ นั่นหมายถึงมากกว่าการเพิ่มชื่ออัลกอริทึมใหม่ ไคลเอนต์เก่า ผู้รับที่ออฟไลน์ ข้อความที่เก็บไว้ และอุปกรณ์ที่เชื่อมโยง ล้วนต้องทำงานอย่างคาดการณ์ได้ระหว่างการเปลี่ยนผ่าน

RFC 7696 ของ IETF อธิบายความคล่องตัวของอัลกอริทึมว่าเป็นปัญหาการย้ายระบบที่เกี่ยวข้องกับตัวระบุ การนำไปใช้งาน และการเปลี่ยนแปลงการดำเนินงาน หมายเลขเวอร์ชันช่วยระบุว่าสิ่งใดกำลังถูกใช้งาน แต่ไม่ได้ทำให้การย้ายระบบปลอดภัยด้วยตัวมันเอง

เวอร์ชันสามประเภทที่สับสนได้ง่าย

แอปส่งข้อความอาจมี เวอร์ชันแอป เวอร์ชันโพรโทคอลที่ใช้รับส่งข้อมูล และ ตัวระบุชุดอัลกอริทึมการเข้ารหัส แต่ละประเภทตอบคำถามต่างกัน:

ตัวระบุ	สิ่งที่บอกผู้ตรวจสอบ	สิ่งที่ไม่ได้ยืนยัน
รุ่นของแอป	ติดตั้งซอฟต์แวร์บิลด์ใดอยู่	ทุกการสนทนาใช้โพรโทคอลใหม่ล่าสุด
เวอร์ชันโพรโทคอล	ใช้รูปแบบข้อความและกฎเกี่ยวกับสถานะใด	การนำไปใช้งานปฏิบัติตามกฎเหล่านั้นอย่างถูกต้อง
ตัวระบุอัลกอริทึมหรือชุดอัลกอริทึม	เลือกองค์ประกอบทางการเข้ารหัสใด	ไม่สามารถบังคับลดระดับระหว่างการเจรจาได้

บันทึกประจำรุ่นควรระบุความสัมพันธ์นี้อย่างชัดเจน คำว่า “เปิดตัวการเข้ารหัสใหม่แล้ว” ยังคลุมเครือ หากมีเพียงการสนทนาที่สร้างขึ้นใหม่เท่านั้นที่ใช้ หรือหากไคลเอนต์เก่าที่เชื่อมโยงอยู่ทำให้ย้อนกลับไปใช้โหมดเดิม

การย้ายระบบอย่างปลอดภัยต้องระบุอะไรบ้าง

เริ่มจากสถานการณ์ที่ชัดเจน: อลิซอัปเดตวันนี้ แต่บ็อบยังออฟไลน์อยู่บนโทรศัพท์รุ่นเก่า อลิซส่งข้อความแล้วเพิ่มอุปกรณ์เครื่องที่สองในภายหลัง อุปกรณ์แต่ละเครื่องควรยอมรับ เก็บ และแสดงอะไร?

การออกแบบที่ตรวจสอบได้ต้องตอบคำถามอย่างน้อยดังต่อไปนี้:

• แต่ละฝ่ายทราบได้อย่างไรว่าอีกฝ่ายรองรับเวอร์ชันใดบ้าง?
• เวอร์ชันที่เลือกได้รับการยืนยันความถูกต้องเป็นส่วนหนึ่งของเซสชันหรือไม่?
• จะเกิดอะไรขึ้นเมื่อไม่มีเวอร์ชันร่วมกันที่ยอมรับได้?
• รีเลย์ที่เป็นอันตรายสามารถตัดข้อมูลความสามารถออกและทำให้ใช้โหมดที่อ่อนแอกว่าได้หรือไม่?
• ข้อความเก่ายังอ่านได้หรือไม่ และยังจำเป็นต้องใช้กุญแจเก่าใดบ้าง?
• การกู้คืนข้อมูลสำรองทำให้สถานะโพรโทคอลที่ล้าสมัยกลับมาใช้งานอีกหรือไม่?
• อัลกอริทึมที่เลิกแนะนำให้ใช้จะถูกปิดใช้งานเมื่อใด แทนที่จะแค่ไม่สนับสนุนให้ใช้?

ความล้มเหลวที่มองเห็นได้มักปลอดภัยกว่าการเปลี่ยนไปใช้โหมดที่ผู้ใช้ไม่ได้ตั้งใจอย่างเงียบ ๆ แต่ควรบันทึกพฤติกรรมเมื่อเกิดความล้มเหลวและการกู้คืนอย่างแม่นยำ เพื่อไม่ให้ผู้คนหลีกเลี่ยงปัญหาโดยเปลี่ยนไปใช้ช่องทางที่ไม่มีการป้องกัน

ตารางทดสอบการอัปเกรดที่นำไปใช้ได้จริง

การอัปเกรดความปลอดภัยต้องการมากกว่าการแชตสำเร็จระหว่างการติดตั้งใหม่สองชุด ทดสอบกรณีต่อไปนี้ด้วยข้อมูลที่ไม่อ่อนไหว:

การทดสอบ	หลักฐานที่ควรบันทึก
ไคลเอนต์ใหม่สื่อสารกับไคลเอนต์เก่า	โพรโทคอลที่เลือกหรือผลความไม่เข้ากันที่ชัดเจน
ผู้รับออฟไลน์ระหว่างอัปเกรด	พฤติกรรมการส่งถึงและการถอดรหัสหลังเชื่อมต่ออีกครั้ง
อุปกรณ์เก่าที่เชื่อมโยงกลับมาใช้งาน	อุปกรณ์นั้นอ่าน ส่ง หรือบังคับใช้โหมดที่ไม่คาดคิดได้หรือไม่
กลุ่มเพิ่มสมาชิกที่เข้ากันไม่ได้	นโยบายกลุ่มที่ชัดเจนและสถานะที่ผู้ใช้มองเห็น
กู้คืนข้อมูลสำรองหลังเลิกสนับสนุน	สถานะที่ไม่รองรับถูกปฏิเสธหรือถูกย้ายไปสู่สถานะใหม่
ข้อมูลเมตาของเวอร์ชันถูกดัดแปลง	การยืนยันความถูกต้องล้มเหลว แทนที่จะลดระดับโดยไม่มีใครสังเกต

สิ่งเหล่านี้เป็นเกณฑ์การประเมิน ไม่ใช่คำกล่าวอ้างว่าผลิตภัณฑ์ที่ระบุชื่อได้ผ่านการทดสอบแล้ว เก็บตัวระบุบิลด์และผลที่สังเกตไว้ เพื่อแยกปัญหาถดถอยในภายหลังออกจากการเปลี่ยนแปลงเอกสาร

วิธีทำความเข้าใจชื่อโพรโทคอลของ Livara

Livara ใช้ชื่อ LVR1 สำหรับแชตโดยตรง และ LGS1 สำหรับกลุ่มส่วนตัวในเอกสารด้านความปลอดภัย ชื่อเหล่านี้แยกหน้าที่ความรับผิดชอบ ไม่ควรมองว่าเป็นหลักฐานของการจัดทำมาตรฐานหรือการตรวจสอบโดยอิสระ หน้านี้ยังกล่าวถึงพฤติกรรมของไคลเอนต์หรือกลุ่มที่ไม่สามารถทำตามเงื่อนไขเบื้องต้นของโหมดเข้ารหัสได้

หลักฐานที่มีประโยชน์ในขั้นต่อไป ได้แก่ ข้อกำหนดที่มีเวอร์ชัน เวกเตอร์ทดสอบ กฎความเข้ากันได้ และผลการตรวจทานที่ผูกกับรุ่นใดรุ่นหนึ่ง Proof Lab ระบุอย่างชัดเจนว่าการสาธิตของตนมีขอบเขตเล็กกว่า การทดสอบองค์ประกอบพื้นฐานทางการเข้ารหัสในเบราว์เซอร์ไม่เหมือนกับการทดสอบทุกเส้นทางการย้ายระบบในแอป

ผู้ใช้ควรทำอะไรระหว่างการอัปเกรดการเข้ารหัส

อัปเดตไคลเอนต์ที่ยังรองรับอยู่ อ่านประกาศด้านความปลอดภัยเกี่ยวกับความเข้ากันได้ของอุปกรณ์ และใส่ใจตัวบ่งชี้ตัวตนหรือสถานะการเข้ารหัสที่เปลี่ยนไป อย่าสันนิษฐานว่าไอคอนแอปใหม่หมายความว่ากลุ่มและข้อมูลสำรองเก่าทั้งหมดได้รับการป้องกันแบบใหม่แล้ว หากผลิตภัณฑ์อธิบายไม่ได้ว่าข้อมูลใดมีการป้องกันเปลี่ยนไป ให้ถามก่อนแบ่งปันเนื้อหาที่อ่อนไหว

ความคล่องตัวทางการเข้ารหัสที่ดีทำให้การเปลี่ยนแปลงตรวจสอบได้ โดยระบุว่าอะไรเปลี่ยนไป คู่สื่อสารตกลงกันอย่างไร อะไรอาจผิดพลาด และกลไกเก่าจะหยุดได้รับการยอมรับเมื่อใด