ความครบถ้วนของข้อความ: เซิร์ฟเวอร์แก้แชทที่เข้ารหัสได้หรือไม่?

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

ประเด็นสำคัญ

• การเข้ารหัสแบบยืนยันความแท้จริงตรวจพบการดัดแปลงข้อความเข้ารหัส แต่ไม่จำเป็นต้องเก็บประวัติการแก้ไขและการลบ
• ตามเอกสารทางเทคนิคของ Livara นั้น AES-256-GCM ปกป้องข้อความส่วนตัวด้วยแท็กยืนยันความแท้จริง แพ็กเก็ตที่ถูกดัดแปลงไม่ควรถูกถอดรหัสเป็นข้อมูลที่ยอมรับได้
• การแก้ไขที่ได้รับอนุญาตควรเป็นเหตุการณ์ใหม่ที่เข้ารหัสจากต้นทางถึงปลายทาง ไม่ใช่การที่เซิร์ฟเวอร์แอบเขียนทับแพ็กเก็ตเดิม
• หมายเลขความปลอดภัยช่วยตรวจสอบกุญแจของอีกฝ่าย ไม่ได้วัดความซื่อสัตย์หรือความน่าเชื่อถือทางกฎหมายของภาพหน้าจอ
• สำหรับข้อพิพาทที่ละเอียดอ่อน ควรเก็บไฟล์ต้นฉบับ เวลา สถานะการแก้ไข และหลักฐานอิสระไว้นอกเธรดสนทนาด้วย

ความครบถ้วนของข้อความในแอปส่งข้อความคืออะไรแน่?

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

เป็นภาพแนวคิดที่มีป้ายข้อความเพื่อสาธิต ไม่ใช่หน้าจอจริงของ Livara หรือผลทดสอบการปฏิเสธข้อความที่ถูกดัดแปลง

ตามเอกสารทางเทคนิคของ Livara ข้อความโดยตรงเข้ารหัสจากต้นทางถึงปลายทางด้วย LVR1 และกลุ่มส่วนตัวที่รองรับใช้ LGS1 ตามหน้าความปลอดภัยของ Livara กลุ่มเก่าที่ไม่รองรับจะอยู่นอก E2EE โดยแสดงให้เห็นชัด และกลุ่มใหม่จะไม่ถูกสร้างพร้อมป้ายว่าเข้ารหัสจนกว่าสมาชิกทุกคนจะพร้อม ตรวจสอบสถานะของบทสนทนานั้น เอกสารระบุว่า LVR1 ใช้ ECDH P-256 และ ML-KEM-768 เพื่อสร้างกุญแจข้อความ การที่องค์ประกอบหนึ่งเป็นมาตรฐานไม่ได้หมายถึงการรับรองอิสระสำหรับการผสานทั้งหมดหรือผลิตภัณฑ์ จากนั้น Livara ใช้ AES-256-GCM ปกป้องเนื้อหา

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

การตรวจพบการดัดแปลงข้อความเข้ารหัสและ AES-256-GCM ของแอปส่งข้อความ

นอกจากเข้ารหัสเนื้อหาแล้ว AES-GCM ยังสร้างแท็กยืนยันความแท้จริง หากข้อความเข้ารหัสหรือข้อมูลที่ได้รับการยืนยันถูกเปลี่ยน การตรวจสอบแท็กควรล้มเหลว NIST SP 800-38D นิยามโหมด GCM และเตือนว่าการใช้ nonce ซ้ำกับกุญแจเดียวกันอาจทำให้ความปลอดภัยลดลงอย่างรุนแรง

ตามข้อกำหนดทางเทคนิคของ Livara ข้อความส่วนตัวใช้ AES-256-GCM หากเซิร์ฟเวอร์เปลี่ยนส่วนหนึ่งของแพ็กเก็ตที่ป้องกันไว้ ก็ไม่สามารถสร้างแท็กใหม่ได้โดยไม่มีกุญแจข้อความ ดังนั้นผู้รับไม่ควรยอมรับแพ็กเก็ตนั้นว่าปกติ คำตอบสั้น ๆ ของคำถามว่า “เซิร์ฟเวอร์แก้ข้อความได้หรือไม่?” คือ เซิร์ฟเวอร์สามารถลบ กักไว้ บล็อก หรือส่งข้อมูลช้าได้ แต่ไม่ควรทำให้เนื้อหาที่ดัดแปลงดูเป็นข้อมูลที่ถูกต้องได้

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

เซิร์ฟเวอร์แก้ข้อความได้ หรือการแก้ไขเป็นคนละเรื่อง?

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

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

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

การยืนยันความแท้จริงของข้อความแชทพิสูจน์อะไร?

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

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

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

ความครบถ้วนของเนื้อหาไม่ใช่ลำดับและความใหม่ของข้อความ

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

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

เมื่อเนื้อหาหรือสถานะข้อความผิดคาด

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

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

ประเมินคำกล่าวอ้างเรื่องความครบถ้วนของแอปส่งข้อความอย่างไร?

อย่าพอใจกับคำว่า “เข้ารหัสแล้ว” ให้ถามว่า:

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

Livara เผยแพร่ข้อกำหนดและเครื่องมือสำหรับตรวจสอบคำกล่าวอ้างบางส่วน และผู้ใช้ Android สามารถเปรียบเทียบ checksum ของไฟล์ APK ด้วย SHA-256 ใน Proof Lab สำหรับตรวจแอปแบบออฟไลน์ อย่างไรก็ตาม บทความนี้ไม่ได้เสนอหลักฐานการตรวจประเมินอิสระของรุ่นปัจจุบัน การเผยแพร่ข้อกำหนดและเวกเตอร์ทดสอบช่วยให้ตรวจสอบได้ แต่ไม่แทนการตรวจประเมินอิสระ

สำหรับบทสนทนาส่วนตัว คำกล่าวอ้างหลักของ Livara มีขอบเขตและชัดเจน: AES-256-GCM ควรตรวจพบการดัดแปลงแพ็กเก็ต และการแก้ไขก็ควรเข้ารหัสด้วย ไม่ได้หมายถึงบันทึกที่เปลี่ยนไม่ได้ การลบทุกสำเนาอย่างแน่นอน หรือหลักฐานทางกฎหมายโดยอัตโนมัติ

คำถามที่พบบ่อย

ผู้ดูแลเซิร์ฟเวอร์เปลี่ยนเนื้อหาข้อความเข้ารหัสได้หรือไม่?

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

ป้าย “แก้ไขแล้ว” พิสูจน์ได้หรือไม่ว่ารุ่นก่อนหน้ามีเนื้อหาอะไร?

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

หมายเลขความปลอดภัยรับประกันความแท้จริงของทุกข้อความหรือไม่?

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

ลบสำหรับทุกคนทำให้ข้อความหายจากทุกที่หรือไม่?

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