การเข้ารหัสจากต้นทางถึงปลายทางปกป้องเนื้อหาที่รองรับระหว่างอุปกรณ์ปลายทาง แต่ไม่ได้ทำให้อุปกรณ์หรือผู้ใช้เหล่านั้นไร้ข้อผิดพลาด
การเข้ารหัสจากต้นทางถึงปลายทาง (E2EE) ปกป้องเนื้อหาข้อความที่รองรับ โดยให้อุปกรณ์ผู้ร่วมสนทนาเป็นผู้ถือสิ่งที่จำเป็นในการอ่าน แทนบริการนำส่ง แต่ไม่ได้ซ่อนว่าใครสื่อสารกับใครโดยอัตโนมัติ ไม่ทำให้โทรศัพท์ที่ติดมัลแวร์ปลอดภัย และไม่ห้ามผู้รับคัดลอกข้อความ
คู่มือนี้ติดตามข้อความจากผู้ส่งถึงผู้รับ เปรียบเทียบ E2EE กับ HTTPS และอธิบายการตรวจสอบเชิงปฏิบัติที่อยู่เบื้องหลังคำกล่าวอ้างการเข้ารหัสของแอปส่งข้อความ
การเข้ารหัสจากต้นทางถึงปลายทางคืออะไร?
การเข้ารหัสจากต้นทางถึงปลายทางเป็นวิธีปกป้องข้อมูลโดยเข้ารหัสบนอุปกรณ์ผู้ส่ง และถอดรหัสเฉพาะบนอุปกรณ์ผู้รับที่ร่วมในการสื่อสาร
ในบทสนทนา E2EE ที่ออกแบบถูกต้อง ข้อความจะไม่ออกจากอุปกรณ์ผู้ส่งเป็นข้อความธรรมดาที่อ่านได้ แต่จะออกไปเป็นข้อความเข้ารหัสหรือไซเฟอร์เท็กซ์ ซึ่งเป็นข้อมูลที่ถูกแปลงรูปและไม่ควรนำมาใช้ได้หากไม่มีกุญแจเข้ารหัสที่ถูกต้อง
บริการส่งข้อความช่วยนำส่งและซิงค์ข้อมูลที่เข้ารหัสได้โดยไม่จำเป็นต้องมีเนื้อหาที่ปกป้องไว้ในรูปแบบอ่านได้ หลักการเดียวกันนี้อาจใช้ได้กับการสื่อสารแบบตัวต่อตัวหรือแบบกลุ่ม ขึ้นอยู่กับโพรโทคอล
“ปลายทาง” คืออุปกรณ์ที่ร่วมสื่อสาร ไม่จำเป็นต้องเป็นโทรศัพท์แค่สองเครื่อง กลุ่มหรือแล็ปท็อปที่เชื่อมโยงของคนหนึ่งอาจเพิ่มอุปกรณ์ปลายทางที่ได้รับอนุญาตเข้ามา
นี่คือความแตกต่างหลักระหว่างการเข้ารหัสจากต้นทางถึงปลายทางกับการเข้ารหัสระหว่างรับส่งตามปกติ
E2EE ทำงานอย่างไร?
คณิตศาสตร์อาจซับซ้อน แต่เส้นทางพื้นฐานของข้อความนั้นเข้าใจได้
1. ผู้ร่วมสนทนาแต่ละคนมีกุญแจเข้ารหัส
ไคลเอนต์ส่งข้อความที่ปลอดภัยสร้างหรือจัดเก็บข้อมูลกุญแจเข้ารหัสบนอุปกรณ์ผู้ใช้
กุญแจบางประเภทแบ่งปันสู่สาธารณะได้ แต่กุญแจส่วนตัวต้องได้รับการปกป้อง เพราะช่วยให้อุปกรณ์สร้างหรือกู้คืนข้อมูลลับที่จำเป็นในการถอดรหัสข้อความ
2. อุปกรณ์สร้างค่าลับร่วมสำหรับข้อความ
ผู้ร่วมสนทนาแลกเปลี่ยนข้อมูลสาธารณะที่จำเป็นเพื่อคำนวณค่าลับที่ตรงกัน
ไม่ควรต้องส่งตัวค่าลับเองเป็นข้อมูลที่อ่านได้ แต่ละอุปกรณ์ดำเนินการเข้ารหัสที่จำเป็นอย่างเป็นอิสระ
3. ข้อความถูกเข้ารหัสในเครื่อง
เมื่อผู้ส่งแตะ ส่ง แอปจะเข้ารหัสข้อความบนอุปกรณ์ผู้ส่ง
ประโยคที่อ่านได้กลายเป็นข้อความเข้ารหัสก่อนอัปโหลดหรือส่งต่อ
4. เซิร์ฟเวอร์นำส่งข้อความเข้ารหัส
โครงสร้างพื้นฐานของบริการส่งข้อความนำข้อความที่เข้ารหัสไปยังผู้รับ และอาจเก็บข้อความเข้ารหัสเพื่อรองรับการซิงค์ การนำส่ง และอุปกรณ์ที่ได้รับอนุญาตหลายเครื่อง
เซิร์ฟเวอร์ยังทำงานด้านการดำเนินงานที่สำคัญ E2EE เปลี่ยนรูปแบบเนื้อหาข้อความที่เซิร์ฟเวอร์จัดการ
5. ผู้รับถอดรหัส
อุปกรณ์ผู้รับที่ได้รับอนุญาตใช้ข้อมูลเข้ารหัสของตนตรวจสอบความแท้จริงและถอดรหัสข้อความ
ข้อความที่อ่านได้ปรากฏบนอุปกรณ์ปลายทางที่ได้รับอนุญาต หลังจากนั้น ประวัติในเครื่อง การแจ้งเตือน ข้อมูลสำรอง และการส่งออกต้องมีการป้องกันของตนเอง
การเข้ารหัสจากต้นทางถึงปลายทางปกป้องอะไร?
E2EE ออกแบบมาเพื่อปกป้อง เนื้อหา ของบทสนทนาเป็นหลัก
ขึ้นอยู่กับแอปและการนำไปใช้ เนื้อหานั้นอาจรวมถึง:
- ข้อความตัวอักษรโดยตรง
- รูปภาพและวิดีโอ
- ข้อความเสียง
- เอกสารและไฟล์แนบ
- การโทรเสียงหรือวิดีโอ
- การแก้ไขข้อความและการตอบกลับ
เมื่อเนื้อหานี้เข้ารหัสบนไคลเอนต์อย่างถูกต้อง ผู้โจมตีที่ดักรับการจราจรเครือข่ายควรเห็นข้อมูลที่เข้ารหัสแทนข้อความต้นฉบับ
นอกจากนี้ยังลดปริมาณเนื้อหาสนทนาที่อ่านได้ซึ่งโครงสร้างพื้นฐานของบริการเข้าถึงได้
แต่ไม่ควรมองคำว่า “เข้ารหัส” เป็นคำวิเศษ ผู้ใช้ควรรู้ว่าครอบคลุมบทสนทนาประเภทใดและเส้นทางเนื้อหาใดอย่างแน่นอน
สิ่งที่ E2EE ไม่ได้ปกป้องโดยอัตโนมัติ
การเข้ารหัสจากต้นทางถึงปลายทางมีประสิทธิภาพสูง แต่ผู้คนมักเข้าใจขอบเขตผิด
เมทาดาทาของข้อความ
ระบบอาจต้องใช้ข้อมูลการดำเนินงานเพื่อส่งต่อและซิงค์ข้อความ
ขึ้นอยู่กับบริการ อาจรวมถึง:
- บัญชีใดส่งข้อความ
- บทสนทนาใดได้รับข้อความ
- ข้อความส่งเมื่อใด
- สถานะส่งถึงและอ่าน
- สมาชิกของบทสนทนา
- ขนาดข้อความที่เข้ารหัส
- ข้อมูลอุปกรณ์หรือเซสชัน
เนื้อความอาจอ่านไม่ได้ ขณะที่ข้อมูลแวดล้อมบางส่วนยังเข้าถึงได้โดยระบบ
นี่จึงเป็นเหตุผลที่ “เนื้อหาข้อความเข้ารหัส” และ “บริการไม่เก็บเมทาดาทา” เป็นคำกล่าวคนละเรื่อง
อุปกรณ์ที่ถูกเจาะ
การเข้ารหัสจากต้นทางถึงปลายทางไม่ปกป้องข้อความที่อ่านได้จากมัลแวร์หรือผู้โจมตีอื่นที่เข้าถึงอุปกรณ์ปลายทางได้มากพอ การเข้าถึงนั้นไม่จำเป็นต้องอาศัยหน้าจอที่ปลดล็อก หน้าจอที่ล็อกอยู่เพียงอย่างเดียวไม่ได้พิสูจน์ว่าระบบปฏิบัติการที่ถูกเจาะจะเข้าถึงข้อมูลข้อความไม่ได้
ท้ายที่สุดข้อความต้องอ่านได้บนอุปกรณ์ที่ได้รับอนุญาต ผู้โจมตีที่เข้าถึงข้อมูลที่แอปถอดรหัสแล้ว หน่วยความจำ หรือหน้าจอ อาจได้เนื้อหานั้น ขอบเขตการเปิดเผยจริงขึ้นอยู่กับอุปกรณ์ ซอฟต์แวร์ และการบุกรุก
ความปลอดภัยของอุปกรณ์ยังจำเป็น:
- ติดตั้งการอัปเดตระบบปฏิบัติการ
- ใช้รหัสปลดล็อกอุปกรณ์ที่แข็งแกร่ง
- ตรวจสอบส่วนขยายเบราว์เซอร์
- ปกป้องข้อมูลกู้คืนบัญชี
- หลีกเลี่ยงแอปและไฟล์ดาวน์โหลดที่ไม่รู้จัก
การกระทำของผู้รับ
E2EE ไม่สามารถห้ามผู้ร่วมสนทนาคัดลอก ส่งต่อ ถ่ายภาพ หรือจับภาพหน้าจอข้อความหลังถอดรหัสแล้ว
การเข้ารหัสปกป้องการนำส่งระหว่างอุปกรณ์ปลายทาง แต่ไม่ได้ควบคุมบุคคลที่ปลายทางอีกด้าน
ความผิดพลาดในการกู้คืนบัญชี
ระบบกู้คืนต้องสมดุลระหว่างความปลอดภัยกับความสะดวกในการใช้งาน
กระบวนการกู้คืนที่อ่อนแออาจบั่นทอนการเข้ารหัสที่แข็งแกร่ง ในทางกลับกัน ระบบที่ไม่ให้กู้คืนเลยอาจทำให้ประวัติที่เข้ารหัสเข้าถึงไม่ได้ตลอดไปเมื่อกุญแจสูญหาย
แอปที่น่าเชื่อถือควรอธิบายว่าการกู้คืนทำงานอย่างไร สำรองข้อมูลอะไร และเกิดอะไรขึ้นเมื่อข้อมูลรับรองสำหรับกู้คืนสูญหาย
E2EE และ TLS ไม่ใช่สิ่งเดียวกัน
เว็บไซต์สมัยใหม่ส่วนใหญ่ใช้ HTTPS และ TLS ปกป้องการรับส่งข้อมูลระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์
สิ่งนี้สำคัญ เพราะช่วยป้องกันไม่ให้คนในเครือข่ายเดียวกันหรือจุดอื่นระหว่างทางอ่านหรือแก้ไขการเชื่อมต่อได้ง่าย ๆ
TLS ปกป้องการเชื่อมต่อระหว่างจุดปลายของมัน สำหรับการส่งข้อความบนเว็บทั่วไป จุดปลายหนึ่งคือบริการนั้นเอง บริการอ่านข้อมูลแอปได้ เว้นแต่มีชั้นเข้ารหัสเนื้อหาแยกต่างหากปกป้องไว้ ข้อกำหนด TLS อธิบายการป้องกันการดักฟัง การดัดแปลง และการปลอมแปลงบนการเชื่อมต่อนั้น
ในการส่งข้อความมาตรฐานที่เซิร์ฟเวอร์อ่านได้:
- อุปกรณ์ของคุณเข้ารหัสการเชื่อมต่อเครือข่าย
- เซิร์ฟเวอร์รับและประมวลผลเนื้อหาข้อความที่อ่านได้
- เซิร์ฟเวอร์เปิดการเชื่อมต่อที่ปกป้องไว้อีกเส้นทางไปยังผู้รับ
เมื่อใช้การเข้ารหัสจากต้นทางถึงปลายทาง ตัวข้อความเองเข้ารหัสสำหรับผู้ร่วมสนทนาก่อนถูกใส่ลงในการเชื่อมต่อเครือข่ายที่ได้รับการปกป้อง
เปรียบเทียบอย่างง่าย:
| การป้องกัน | การส่งข้อความที่ใช้ TLS เท่านั้น | การเข้ารหัสจากต้นทางถึงปลายทาง |
|---|---|---|
| ปกป้องข้อมูลระหว่างเดินทางบนเครือข่าย | ใช่ | ใช่ |
| ปกป้องก่อนข้ามเครือข่าย | ใช่ สำหรับการเชื่อมต่อ TLS นั้น | ใช่ สำหรับอุปกรณ์ปลายทางการส่งข้อความที่ตั้งใจไว้ |
| บริการนำส่งอ่านเนื้อหาข้อความที่ปกป้องไว้ได้ | โดยทั่วไปได้ หากไม่มีการเข้ารหัสเนื้อหาเพิ่มเติม | ไม่ได้จากข้อความเข้ารหัสเพียงอย่างเดียวภายใต้การออกแบบกุญแจที่ตั้งใจไว้ |
| ยังต้องมีความปลอดภัยของอุปกรณ์ปลายทาง | ใช่ | ใช่ |
| ซ่อนเมทาดาทาโดยอัตโนมัติ | ไม่ | ไม่ |
TLS และ E2EE ไม่ใช่คู่แข่ง ระบบส่งข้อความส่วนตัวโดยทั่วไปต้องมีการรับส่งที่ปลอดภัย และ การเข้ารหัสเนื้อหาที่นำไปใช้อย่างถูกต้อง
นำคำนิยามมาใช้กับ Livara
ตามเอกสารความปลอดภัย Livara ใช้การตกลงกุญแจแบบผสม LVR1 ด้วย P-256 และ ML-KEM-768 สำหรับการสื่อสารโดยตรง กลุ่มส่วนตัวที่เข้ากันได้ใช้กุญแจผู้ส่ง LGS1 ที่แจกจ่ายผ่านเซสชันแบบจับคู่ ช่องสาธารณะเป็นเนื้อหาที่เซิร์ฟเวอร์อ่านได้และไม่ควรเรียกว่า E2EE
ความแตกต่างขึ้นกับรูปแบบการสื่อสารจริง ไม่ใช่ชื่อแบรนด์ เอกสารยังอธิบายการเข้ารหัสการโทรแยกต่างหาก รวมถึงโหมดบันทึกที่มองเห็นได้ซึ่งมีขอบเขตความไว้วางใจต่างกัน ตรวจสถานะบทสนทนาและการโทรปัจจุบัน แทนการสมมติว่าทุกคุณสมบัติได้รับการปกป้องแบบเดียวกัน
สิ่งเหล่านี้เป็นคำกล่าวที่ผลิตภัณฑ์ระบุในเอกสาร ไม่ใช่การตรวจสอบอิสระที่ทำสำหรับบทความนี้ เมทาดาทาการดำเนินงานและอุปกรณ์ที่ถูกเจาะยังเป็นข้อจำกัดสำคัญ การตกลงกุญแจแบบหลังควอนตัมแก้ความเสี่ยงทางการเข้ารหัสประเภทหนึ่ง แต่ไม่ได้ทำให้ฟิชชิง ข้อมูลสำรองไม่ปลอดภัย หรือหน้าจอที่ปลดล็อกอยู่ไม่มีอันตราย
เหตุใดลายนิ้วมือดิจิทัลของกุญแจสาธารณะจึงสำคัญ
บทสนทนาที่เข้ารหัสขึ้นอยู่กับการสื่อสารกับกุญแจที่ตั้งใจไว้ ไม่ใช่เพียงกุญแจใดก็ตามที่ระบบแสดง
ลายนิ้วมือดิจิทัลของกุญแจสาธารณะเป็นตัวแทนแบบย่อของกุญแจสาธารณะของผู้ร่วมสนทนา คนสองคนเปรียบเทียบลายนิ้วมือดิจิทัลผ่านช่องทางอื่นที่เชื่อถือได้ เช่น การพูดคุยต่อหน้าหรือการโทรที่ยืนยันแล้ว
ลายนิ้วมือดิจิทัลที่ตรงกันเพิ่มความมั่นใจว่ากำลังใช้กุญแจที่คาดหมาย
ลายนิ้วมือที่เปลี่ยนไม่ได้พิสูจน์การโจมตีโดยอัตโนมัติ อาจเกิดหลังการรีเซ็ตกุญแจที่ถูกต้องหรือการกู้คืนอุปกรณ์ แต่ควรเห็นการเปลี่ยนแปลงและอธิบายได้ ไม่ใช่เพิกเฉยอย่างเงียบ ๆ
การสำรองและกู้คืนแยกจากการเข้ารหัสข้อความระหว่างสนทนา
แอปอาจเข้ารหัสข้อความปัจจุบันจากต้นทางถึงปลายทาง ขณะที่ข้อมูลสำรองแยกต่างหากมีกุญแจและกฎเข้าถึงต่างกัน การส่งออกแบบไม่เข้ารหัสก็อาจย้ายเนื้อหาที่อ่านได้ออกนอกบทสนทนาที่เข้ารหัส ถามว่าสำรองอะไร ใครถอดรหัสได้ และเกิดอะไรขึ้นเมื่อข้อมูลสำหรับกู้คืนสูญหาย
ข้อมูลสำรองกู้คืนของ Livara ตามเอกสารถูกผนึกด้วยการเข้ารหัสก่อนอัปโหลด และกู้คืนข้อมูลตัวตน ไม่ใช่ประวัติแชต อย่าอนุมานว่าการกู้บัญชีหรือตัวตนทำให้ทุกบทสนทนาเก่ากลับมา สำหรับการตัดสินใจที่ครอบคลุมกว่า ดูวิธีสำรองแชตที่เข้ารหัสอย่างปลอดภัย
วิธีประเมินแอปส่งข้อความส่วนตัว
อย่าตัดสินบริการส่งข้อความจากคำว่า “เข้ารหัส” หรือ “ปลอดภัย” เพียงอย่างเดียว
ถามอย่างเจาะจง
บทสนทนาใดเป็น E2EE?
ตรวจว่าการป้องกันครอบคลุมแชตโดยตรง กลุ่ม ช่อง การโทร และไฟล์แนบหรือไม่
กุญแจสร้างและเก็บที่ใด?
มองหาคำอธิบายชัดเจนว่ากุญแจสร้างบนไคลเอนต์หรือไม่ และข้อมูลสำรองได้รับการปกป้องอย่างไร
เซิร์ฟเวอร์เก็บอะไรไว้?
บริการที่รับผิดชอบควรแยกเนื้อหาข้อความออกจากข้อมูลส่งต่อ เวลา สมาชิก ข้อมูลนำส่ง และข้อมูลการดำเนินงานอื่น
เกิดอะไรขึ้นเมื่อกุญแจเปลี่ยน?
การแทนที่กุญแจที่ไม่คาดหมายควรมองเห็นได้ การเปลี่ยนกุญแจเงียบ ๆ ลดความสามารถของผู้ใช้ในการตรวจสอบผู้ติดต่อ
การกู้คืนทำงานอย่างไร?
ตรวจว่าผู้ให้บริการกู้กุญแจได้หรือไม่ ต้องใช้ข้อมูลลับสำหรับกู้คืนหรือไม่ และเกิดอะไรขึ้นหากข้อมูลลับนั้นสูญหาย
คำกล่าวได้รับการตรวจสอบอิสระหรือไม่?
เอกสารความปลอดภัย โพรโทคอลเปิด บทวิจารณ์จากผู้เชี่ยวชาญ และการตรวจสอบอิสระ ให้ความมั่นใจต่างระดับกัน
ภาษาการตลาดเพียงอย่างเดียวไม่ใช่การตรวจสอบ
ความเป็นส่วนตัวขึ้นอยู่กับขอบเขตที่ชัดเจน
คำกล่าวความเป็นส่วนตัวที่หนักแน่นที่สุดไม่ใช่ “เชื่อใจเรา”
แต่เป็นคำอธิบายที่แม่นยำและทดสอบได้ว่า:
- อะไรเข้ารหัส
- เข้ารหัสที่ใด
- เกี่ยวข้องกับกุญแจใด
- เซิร์ฟเวอร์ได้รับอะไร
- เมทาดาทาใดยังเหลือ
- บทสนทนาประเภทใดไม่รวมอยู่
- การกู้คืนเปลี่ยนแบบจำลองภัยคุกคามอย่างไร
การเข้ารหัสจากต้นทางถึงปลายทางไม่ใช่ทั้งหมดของความเป็นส่วนตัว แต่เมื่อใช้อย่างรอบคอบและอธิบายอย่างตรงไปตรงมา ก็เป็นรากฐานสำคัญของการสื่อสารส่วนตัว
สำหรับขั้นตอนปฏิบัติต่อไป ใช้รายการตรวจสอบแอปส่งข้อความปลอดภัย 12 ข้อตรวจคุณสมบัติที่คุณใช้จริง ได้แก่ แชตส่วนตัว กลุ่ม ไฟล์แนบ การโทร และข้อมูลสำรอง
คำถามที่พบบ่อย
E2EE ย่อมาจากอะไร?
E2EE ย่อมาจากการเข้ารหัสจากต้นทางถึงปลายทาง หมายถึงเนื้อหาที่ปกป้องไว้เข้ารหัสที่อุปกรณ์ปลายทางของผู้ร่วมสนทนาคนหนึ่ง และถอดรหัสที่อุปกรณ์ปลายทางอีกเครื่องซึ่งได้รับอนุญาต
ผู้ให้บริการอินเทอร์เน็ตอ่านข้อความ E2EE ได้หรือไม่?
ผู้ให้บริการอินเทอร์เน็ตอาจเห็นว่ามีการเชื่อมต่ออยู่และเห็นข้อมูลระดับเครือข่ายบางอย่าง แต่เนื้อหาข้อความที่เข้ารหัสถูกต้องไม่ควรปรากฏเป็นข้อความธรรมดาที่อ่านได้ระหว่างเดินทาง
การเข้ารหัสจากต้นทางถึงปลายทางซ่อนเมทาดาทาหรือไม่?
ไม่ใช่โดยอัตโนมัติ ระบบส่งข้อความอาจยังประมวลผลการส่งต่อ สมาชิก เวลา สถานะนำส่ง ขนาดข้อความเข้ารหัส หรือข้อมูลอื่นที่จำเป็นในการดำเนินบริการ
E2EE ปกป้องโทรศัพท์ที่ถูกขโมยและปลดล็อกอยู่ได้หรือไม่?
ไม่มีโพรโทคอลเข้ารหัสใดปกป้องข้อความได้เต็มที่เมื่อผู้โจมตีควบคุมอุปกรณ์ที่ได้รับอนุญาตและปลดล็อกแล้ว ความปลอดภัยอุปกรณ์ที่แข็งแกร่งยังจำเป็น
ทุกบทสนทนาใน Livara เข้ารหัสจากต้นทางถึงปลายทางหรือไม่?
ปัจจุบัน Livara ระบุ E2EE สำหรับเนื้อความและสื่อในการสื่อสารโดยตรงแบบตัวต่อตัว และสำหรับกลุ่มส่วนตัวที่เข้ากันได้ กลุ่มเหล่านั้นเข้ารหัสจากต้นทางถึงปลายทางด้วย LGS1 และหมุนเวียนกุญแจผู้ส่งอัตโนมัติเมื่อสมาชิกเปลี่ยน ช่องใช้ TLS และสิทธิ์ฝั่งเซิร์ฟเวอร์ที่ผ่านการยืนยันตัวตน และไม่ได้อ้างว่าเข้ารหัสจากต้นทางถึงปลายทาง
กู้คืนกุญแจเข้ารหัส Livara ที่สูญหายได้หรือไม่?
เอกสารสาธารณะอธิบายการกู้ข้อมูลตัวตนที่สำรองไว้ด้วยข้อมูลลับสำหรับกู้คืนที่จำเป็น สิ่งนี้ไม่กู้ประวัติแชต อ่านขั้นตอนกู้คืนปัจจุบันก่อนลบข้อมูลหรือเปลี่ยนอุปกรณ์เดิม
E2EE เหมือนกับความลับไปข้างหน้าหรือไม่?
ไม่ E2EE อธิบายว่าใครควรอ่านเนื้อหาที่ปกป้องไว้ได้ ความลับไปข้างหน้าเกี่ยวกับผลที่การรั่วไหลของกุญแจในภายหลังมีต่อข้อความก่อนหน้า ส่วนความปลอดภัยหลังถูกเจาะเกี่ยวกับการกลับมามีการป้องกันหลังถูกเจาะภายใต้เงื่อนไขที่กำหนด คุณสมบัติเหล่านี้ขึ้นอยู่กับโพรโทคอลและการนำไปใช้ เช่น ข้อกำหนด MLS นิยามทั้งสองอย่างไว้ชัดเจนสำหรับการออกแบบกุญแจกลุ่มของตน แต่ไม่ได้หมายความว่าแอปส่งข้อความที่เข้ารหัสทุกแอปมีคุณสมบัติเหล่านี้โดยอัตโนมัติหรือใช้ MLS
