คำตอบสั้นๆ
การเข้ารหัสตั้งแต่ต้นทางถึงปลายทางที่ใช้งานอย่างถูกต้องหมายความว่าเนื้อหาข้อความได้รับการเข้ารหัสบนอุปกรณ์ของผู้ส่งและสามารถถอดรหัสได้โดยปลายทางการรับที่ต้องการเท่านั้น บริการจัดส่งควรจัดการข้อความเข้ารหัส ไม่ใช่ข้อความธรรมดาหรือคีย์การสนทนา แต่ E2EE ปกป้องเส้นทางระหว่างปลายทาง มันไม่ได้ทำให้ปลายทาง ผู้รับ ข้อมูลเมตาทุกชิ้น หรือการสำรองข้อมูลทุกรายการน่าเชื่อถือ
คำว่า "จบจนจบ" จริงๆ แล้วหมายถึงอะไร
ตำแหน่งข้อมูลคืออุปกรณ์หรืออินสแตนซ์ของแอปพลิเคชันที่เก็บคีย์ที่จำเป็นในการอ่านการสนทนา การเข้ารหัสจะเกิดขึ้นก่อนที่ข้อความจะออกจากตำแหน่งข้อมูลของผู้ส่ง การถอดรหัสจะเกิดขึ้นหลังจากไปถึงจุดรับปลายทางที่ได้รับอนุญาตแล้ว
ขอบเขตนั้นมีความสำคัญ การเข้ารหัสการขนส่ง เช่น TLS ปกป้องการเชื่อมต่อระหว่างอุปกรณ์และเซิร์ฟเวอร์ การเข้ารหัสจากต้นทางถึงปลายทางจะเพิ่มขอบเขตระดับข้อความแยกต่างหากโดยมีจุดประสงค์เพื่อป้องกันไม่ให้คนกลางรับคีย์ข้อความธรรมดา มาตรฐาน Messaging Layer Security ของ IETF อธิบายถึงเป้าหมายในการทำให้ข้อความสามารถเข้าถึงการสื่อสารปลายทางได้ แทนที่จะให้เซิร์ฟเวอร์ส่งข้อความเหล่านั้น
ฉลากผลิตภัณฑ์เพียงอย่างเดียวไม่สามารถพิสูจน์ได้ การรับรองความถูกต้องของข้อมูลประจำตัว การจัดการคีย์ การเปลี่ยนแปลงการเป็นสมาชิกกลุ่ม การลบคีย์เก่า คุณภาพการใช้งาน และลักษณะการทำงานของการสำรองข้อมูล ล้วนส่งผลต่อผลลัพธ์ด้านความปลอดภัยที่แท้จริง
สิ่งที่ E2EE ออกแบบมาเพื่อปกป้อง
การรับประกันที่แน่นอนขึ้นอยู่กับโปรโตคอลและการใช้งาน แต่ E2EE ที่ผ่านการรับรองความถูกต้องสมัยใหม่มีจุดประสงค์เพื่อจัดการกับความเสี่ยงเหล่านี้:
การสกัดกั้นเครือข่าย
ผู้สังเกตการณ์ Wi-Fi, ISP หรือเครือข่ายระดับกลางควรเห็นการรับส่งข้อมูลที่เข้ารหัส แทนที่จะเห็นเนื้อหาข้อความที่อ่านได้
ผู้ให้บริการที่อยากรู้อยากเห็น
บริการจัดส่งที่ไม่มีคีย์การสนทนาไม่ควรเปิดไซเฟอร์เท็กซ์ข้อความธรรมดาได้
การประนีประนอมเซิร์ฟเวอร์การจัดส่ง
การเข้ารหัสระดับข้อความสามารถรักษาความลับของเนื้อหาได้ แม้ว่าการกำหนดเส้นทางโครงสร้างพื้นฐานหรือการเข้ารหัสข้อความในคิวชั่วคราวจะถูกบุกรุกก็ตาม
การเปลี่ยนแปลงข้อความที่ตรวจไม่พบ
การเข้ารหัสที่มีการรับรองความถูกต้องสามารถอนุญาตให้ผู้รับปฏิเสธข้อความไซเฟอร์เท็กซ์ที่ถูกเปลี่ยนแปลงหรือปลอมแปลง โดยขึ้นอยู่กับการรับรองความถูกต้องและการใช้งานคีย์ที่ถูกต้อง
การเปิดเผยข้อความในอดีตบางส่วน
โปรโตคอลที่มีการส่งต่อความลับจะลบหรือเลื่อนเนื้อหาคีย์เก่า ดังนั้นการประนีประนอมคีย์ในภายหลังจะไม่เปิดเผยข้อความก่อนหน้าทั้งหมดโดยอัตโนมัติ นี่คือคุณสมบัติโปรโตคอลเพิ่มเติม ไม่ใช่คำพ้องความหมายสำหรับ E2EE
สิ่งที่ E2EE ไม่ได้ป้องกันโดยอัตโนมัติ
ความเข้าใจผิดด้านความปลอดภัยส่วนใหญ่เริ่มต้นเมื่อการปกป้องเนื้อหาข้อความถือเป็นการป้องกันระบบการสื่อสารทั้งหมด
ปลายทางที่ถูกบุกรุกหรือปลดล็อค
มัลแวร์ อุปกรณ์ที่ถูกขโมยมาแบบปลดล็อค การแสดงตัวอย่างการแจ้งเตือน ภาพหน้าจอ แป้นพิมพ์ และบริการการเข้าถึงอาจพบข้อความธรรมดาก่อนการเข้ารหัสหรือหลังการถอดรหัส
บุคคลที่ได้รับข้อความ
ผู้รับที่ได้รับอนุญาตสามารถคัดลอก ถ่ายรูป อ้างอิง หรือส่งต่อสิ่งที่พวกเขาสามารถอ่านได้อย่างถูกกฎหมาย การควบคุมที่หายไปจะลดประวัติที่เก็บไว้ พวกเขาไม่สามารถทำให้ผู้รับที่ไม่เป็นมิตรลืมได้
ข้อมูลเมตาทั้งหมด
การนำส่งสามารถเปิดเผยเวลา ปริมาณการรับส่งข้อมูล ที่อยู่ IP ปลายทาง โทเค็นของอุปกรณ์ หรือการดำเนินการของกลุ่ม โปรโตคอลและสถาปัตยกรรมสามารถย่อหรือป้องกันบางส่วนของข้อมูลเมตานี้ได้ แต่การเข้ารหัสเนื้อหาเพียงอย่างเดียวไม่สามารถลบข้อมูลดังกล่าวได้
การสำรองข้อมูลและการส่งออกที่ไม่ได้เข้ารหัส
ถ้าประวัติข้อความธรรมดาหรือคีย์ที่สามารถกู้คืนได้ถูกคัดลอกไปยังระบบอื่น สำเนานั้นมีขอบเขตความปลอดภัยของตัวเอง “การแชทคือ E2EE” ไม่ได้พิสูจน์ว่าทุกการสำรองข้อมูลเป็น
ใครอยู่อีกฟากหนึ่งจริงๆ
การเข้ารหัสคีย์ผิดหรือถูกแทนที่สามารถสร้างการสนทนาที่เข้ารหัสได้อย่างสมบูรณ์แบบกับฝ่ายที่ไม่ถูกต้อง การตรวจสอบคีย์และการผูกข้อมูลประจำตัวที่น่าเชื่อถือยังคงมีความสำคัญ
ความพร้อมใช้งานและการบังคับ
บริการยังคงสามารถชะลอ บล็อก จำกัดอัตรา หรือลบการรับส่งข้อมูลที่เข้ารหัสได้ E2EE also cannot prevent a person from being compelled to unlock an endpoint or disclose what they know.
โมเดลภัยคุกคาม: E2EE ช่วยได้หรือไม่
คำถามเพื่อความปลอดภัยที่เป็นประโยชน์จะตั้งชื่อฝ่ายตรงข้าม แทนที่จะถามว่าแอปนั้น "ถูกเข้ารหัส" หรือไม่
| สถานการณ์ | E2EE ปกป้องเนื้อหาหรือไม่ | มีอะไรอีกที่สำคัญ |
|---|---|---|
| ผู้สังเกตการณ์เครือข่ายสกัดกั้นการรับส่งข้อมูล | ปกติแล้วใช่ | โปรโตคอลที่แข็งแกร่ง การใช้งานที่ปลอดภัย ข้อจำกัดในการวิเคราะห์การรับส่งข้อมูล |
| เซิร์ฟเวอร์การจัดส่งถูกละเมิด | ปกติแล้วใช่ | คีย์จะต้องอยู่บนปลายทางที่ได้รับอนุญาต ข้อมูลเมตาอาจยังคงมองเห็นได้ |
| โทรศัพท์ถูกขโมยขณะปลดล็อค | เลขที่ | ล็อคอุปกรณ์, การป้องกันที่เก็บข้อมูลในเครื่อง, นโยบายการแจ้งเตือน, การเก็บรักษาระยะสั้น |
| ผู้รับจงใจบันทึกข้อความ | เลขที่ | ความน่าเชื่อถือ นโยบาย ลายน้ำ การเปิดเผยอย่างจำกัด การควบคุมทางกฎหมาย |
| ผู้โจมตีใช้แทนรหัสประจำตัว | ไม่ใช่ด้วยตัวเอง | การตรวจสอบคีย์ ความโปร่งใส การรับรองความถูกต้อง คำเตือนการเปลี่ยนแปลง |
| บริการปฏิเสธที่จะส่งข้อความ | เลขที่ | การออกแบบความพร้อมใช้งาน การติดตาม แผนการสื่อสารทางเลือก |
City of Hats จัดการกับขอบเขตนี้อย่างไร
City of Hats ถือว่า E2EE เป็นหนึ่งเลเยอร์ในรูปแบบภัยคุกคามที่กว้างขึ้น ข้อความด้านล่างอธิบายถึงสถาปัตยกรรมที่เผยแพร่และพฤติกรรมผลิตภัณฑ์ของเรา ไม่ใช่การอ้างว่าซอฟต์แวร์สามารถขจัดความเสี่ยงปลายทางหรือพฤติกรรมของผู้รับได้
การเข้ารหัสระดับข้อความ
City of Hats ทำเอกสาร E2EE ฝั่งไคลเอ็นต์สำหรับข้อความ ไฟล์ และการโทร Hat-to-Hat โดยใช้การสร้างคีย์ X25519 และ ML-KEM-768 แบบไฮบริดด้วยการสร้างคีย์ Double Ratchet และ AES-256-GCM คีย์ถอดรหัสการสนทนามีวัตถุประสงค์เพื่อให้คงอยู่ในอุปกรณ์ที่ได้รับอนุญาต
ความโปร่งใสทางเทคนิค →ข้อมูลประจำตัวการลงทะเบียนน้อยลง
สามารถสร้าง Hat ได้โดยไม่ต้องใช้หมายเลขโทรศัพท์หรืออีเมล Phrase IDs, Hats หลายรายการ และ Hats แบบใช้แล้วทิ้งช่วยลดความจำเป็นในการผูกบริบทการสื่อสารทั้งหมดกับผู้ให้บริการรายเดียวหรือข้อมูลประจำตัวของกล่องจดหมาย พวกเขาไม่ได้เปิดเผยชื่ออุปกรณ์หรือการเชื่อมต่อเครือข่ายที่ถูกบุกรุก
Disposable Hats →ส่งต่อการโทรที่เข้ารหัส
เอกสาร City of Hats ถ่ายทอดเสียงและวิดีโอ ดังนั้นผู้เข้าร่วมรายอื่นจึงไม่ได้รับที่อยู่ IP แบบเพียร์ทูเพียร์โดยตรง รีเลย์จะจัดการกับสื่อที่เข้ารหัส ในขณะที่เมตาดาต้าระดับเครือข่ายยังคงต้องการโมเดลภัยคุกคามที่สมจริง
การโทรที่เข้ารหัส →ไม่มีเส้นทางการกู้คืนการสนทนา
โปรแกรมส่งข้อความสำหรับผู้บริโภคได้รับการออกแบบโดยไม่มีห้องนิรภัยกู้คืนข้อความที่ผู้ให้บริการเป็นเจ้าของ การสูญเสียอุปกรณ์ที่ได้รับอนุญาตเพียงเครื่องเดียวอาจหมายถึงการสูญเสียประวัติข้อความ ซึ่งช่วยเพิ่มความต้านทานต่อความต้องการในการกู้คืนฝั่งเซิร์ฟเวอร์ แต่เป็นการแลกเปลี่ยนความพร้อมใช้งานโดยเจตนา
ความเป็นส่วนตัวและการจัดการข้อมูล →ควบคุมหลังคลอด
View Once, Recall, GeoLock, Certified Send, Channel Seal และโหมดความปลอดภัยอื่นๆ สามารถจำกัดการเข้าถึงหรือการเก็บรักษาตามปกติ การควบคุมเหล่านี้ช่วยลดการสัมผัส พวกเขาไม่สามารถเอาชนะผู้รับที่ได้รับอนุญาตโดยใช้กล้องตัวที่สองหรืออุปกรณ์ปลายทางที่ถูกบุกรุกอยู่แล้ว
โหมดความปลอดภัย →บริบทการสื่อสารที่สามารถเบิร์นได้
Hats และช่องสัญญาณสามารถถูกเผาหรือปล่อยให้หมดอายุได้ ดังนั้นจึงไม่จำเป็นต้องมีการระบุตัวตนที่มีอายุการใช้งานยาวนานและประวัติการสนทนาแบบไม่จำกัด การทำลายล้างจะลดสิ่งที่เหลืออยู่ในภายหลัง ไม่สามารถดึงข้อมูลที่บันทึกไว้แล้วนอกระบบที่ได้รับการป้องกันได้
Channel Seal →วิธีประเมินผู้ส่งสารที่เข้ารหัส
อย่าหยุดอยู่แค่เพียงวลี “เข้ารหัสจากต้นทางถึงปลายทาง” สอบถามผู้ให้บริการหรือเอกสารประกอบ:
- ประเภทการสื่อสารใดบ้างที่เป็น E2EE ตามค่าเริ่มต้น—ข้อความ กลุ่ม ไฟล์ การโทร และการโต้ตอบทางธุรกิจ
- คีย์ถูกสร้างขึ้น จัดเก็บ หมุนเวียน สำรองข้อมูล และลบที่ไหน
- คีย์ข้อมูลประจำตัวได้รับการตรวจสอบอย่างไร และจะเกิดอะไรขึ้นเมื่อมีการเปลี่ยนแปลงคีย์
- เนื้อหาและข้อมูลเมตาใดที่บริการสามารถสังเกตหรือเก็บรักษาได้
- จะเกิดอะไรขึ้นกับอุปกรณ์ที่ถูกบุกรุก สูญหาย หรือเชื่อมโยงใหม่
- ผู้รับสามารถส่งออก ส่งต่อ จับภาพ หรือเก็บรักษาเนื้อหาอย่างถาวรได้หรือไม่
- มีข้อกำหนดโปรโตคอล ซอร์สโค้ด การตรวจสอบ หรือหลักฐานทางเทคนิคที่สามารถทำซ้ำได้หรือไม่
- คุณสมบัติความปลอดภัยใดบ้างที่ไม่ขึ้นอยู่กับ E2EE เช่น การส่งต่อความลับ การรักษาความปลอดภัยภายหลังการบุกรุก การต่อต้านข้อมูลเมตา และความพร้อมใช้งาน
บรรทัดล่าง
การเข้ารหัสจากต้นทางถึงปลายทางถือเป็นสิ่งสำคัญเนื่องจากสามารถลบบริการจัดส่งและเครือข่ายออกจากกลุ่มฝ่ายที่เชื่อถือเนื้อหาข้อความได้ ไม่ใช่ระบบความเป็นส่วนตัวทั้งหมด การสื่อสารที่ปลอดภัยที่แข็งแกร่งยังขึ้นอยู่กับอุปกรณ์ปลายทาง ข้อมูลประจำตัว ข้อมูลเมตา การเก็บรักษา การกู้คืน พฤติกรรมของผู้รับ และเอกสารประกอบที่ซื่อสัตย์เกี่ยวกับข้อดีข้อเสีย
แหล่งข้อมูลหลักและการอ่านเพิ่มเติม
มาตรฐานและเอกสารทางเทคนิคของบุคคลที่หนึ่งที่ใช้สำหรับบทความนี้ เข้าถึงเมื่อ 9 สิงหาคม 2569.
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
คำชี้แจงผลิตภัณฑ์ City of Hats เชื่อมโยงกับเอกสารที่เผยแพร่ของเราเอง และควรได้รับการประเมินเป็นการกล่าวอ้างของบุคคลที่หนึ่งจนกว่าจะมีการตรวจสอบอย่างอิสระ
← กลับไปที่ศูนย์ความรู้