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