กุญแจเฉพาะไฟล์ไม่ได้หมายถึงการดูได้ครั้งเดียวหรือการเรียกสำเนาของผู้รับกลับคืน
เพื่อปกป้องไฟล์แนบ แอปส่งข้อความอาจเข้ารหัสไฟล์บนอุปกรณ์ผู้ส่งด้วยกุญแจแบบสุ่ม อัปโหลดสำเนาที่เข้ารหัสแล้ว และส่งกุญแจไฟล์ให้ผู้รับภายในข้อความที่เข้ารหัสแบบต้นทางถึงปลายทาง บางครั้งเรียกรูปแบบนี้ว่าการเข้ารหัสแบบซองจดหมาย: ไฟล์ขนาดใหญ่กับข้อมูลขนาดเล็กที่จำเป็นต่อการเปิดไฟล์เดินทางผ่านเส้นทางที่ต่างกันแต่เชื่อมโยงกัน
คำอธิบายนี้เกี่ยวกับไฟล์แนบในการสนทนาที่มี E2EE การส่งไฟล์ในแอปใดก็ตามหรือช่องทางทุกประเภทไม่ได้มีการปกป้องแบบเดียวกันเสมอไป
เส้นทางของรูปภาพส่วนตัวจากอุปกรณ์ไปยังผู้รับ
- อุปกรณ์ผู้ส่งสร้างกุญแจเนื้อหาสำหรับไฟล์
- ไฟล์ถูกเข้ารหัสด้วยการเข้ารหัสแบบยืนยันความถูกต้อง ผู้รับต้องตรวจพบการเปลี่ยนแปลงข้อมูลที่ไม่ได้รับอนุญาตได้
- สำเนาที่เข้ารหัสแล้วถูกนำไปเก็บในบริการจัดเก็บไฟล์
- ที่อยู่หรือตัวระบุของไฟล์และกุญแจที่จำเป็นถูกส่งให้ผู้รับภายในข้อความที่ได้รับการปกป้อง
- อุปกรณ์ผู้รับรับไฟล์ ตรวจสอบความถูกต้อง แล้วจึงเปิดไฟล์
เอกสารความปลอดภัยของ Livara อธิบายกุญแจสุ่มเฉพาะไฟล์สำหรับไฟล์แนบและการส่งกุญแจผ่านเซสชันข้อความ บทความนี้อธิบายสถาปัตยกรรมที่ประกาศไว้ ไม่ใช่ผลการตรวจสอบการนำระบบไปใช้งานจริง
“กุญแจเฉพาะไฟล์” ต่างจาก “ไฟล์เปิดได้เพียงครั้งเดียว”
กุญแจที่สร้างสำหรับไฟล์หนึ่งอาจจำเป็นต่อการอ่านไฟล์เดิมหลายครั้ง การมีกุญแจเฉพาะไม่ได้หมายความว่าจะทิ้งกุญแจทันทีหลังการดูครั้งแรก ลบไฟล์โดยอัตโนมัติ หรือป้องกันไม่ให้ผู้รับบันทึกไฟล์
นอกจากนี้ การใช้กุญแจข้อความเพียงครั้งเดียวกับการใช้กุญแจเนื้อหาสำหรับไฟล์แนบเป็นคนละแนวคิดกัน ไม่ควรอนุมานคุณสมบัติอย่าง View Once หรือข้อความที่หายไปเองจากชื่ออัลกอริทึมเพียงอย่างเดียว
ทำไมทั้งกุญแจและ nonce จึงสำคัญ?
นอกจากการรักษาความลับแล้ว AES-GCM ยังมีการตรวจสอบความแท้ของข้อมูล แต่การใช้อย่างถูกต้องเป็นสิ่งจำเป็น มาตรฐาน NIST SP 800-38D อธิบายกฎของ GCM การใช้คู่กุญแจและ nonce เดิมซ้ำกับข้อมูลที่ต่างกันอาจทำให้ความปลอดภัยตกอยู่ในความเสี่ยง
สำหรับผู้ใช้ ข้อสรุปในทางปฏิบัติคือ คำว่า “AES-256” เพียงอย่างเดียวยังไม่พอ ต้องตรวจสอบข้อกำหนดเรื่องการจัดการกุญแจ การสร้างค่าสุ่ม การตรวจสอบไฟล์ และการจัดการข้อผิดพลาดด้วย การเปลี่ยนแปลงหนึ่งไบต์ควรทำให้ระบบปฏิเสธไฟล์ที่ไม่ถูกต้อง ไม่ใช่แสดงเนื้อหาที่ถูกแก้ไขราวกับเป็นไฟล์ที่สมบูรณ์
ผู้รับ เซิร์ฟเวอร์ และแอปแกลเลอรีมองเห็นอะไร?
| ตำแหน่ง | คำถามด้านความปลอดภัย |
|---|---|
| บริการจัดเก็บไฟล์ | มีเพียงไบต์ที่เข้ารหัสแล้ว หรือเข้าถึงกุญแจได้ด้วย? |
| ข้อความที่มีกุญแจ | กุญแจ ชื่อไฟล์ และคำอธิบายได้รับการปกป้องในการสนทนา E2EE หรือไม่? |
| อุปกรณ์ผู้รับ | หลังเปิดแล้ว ไฟล์คงอยู่ตรงไหนในหน่วยความจำ แคช หรือแกลเลอรี? |
| ข้อมูลสำรองบนคลาวด์ | สำเนาที่บันทึกเข้าสู่ข้อมูลสำรองรูปภาพหรือไม่ และข้อมูลสำรองนั้นได้รับการปกป้องอย่างไร? |
การเข้ารหัสระหว่างส่งไม่ควบคุมสำเนาที่ผู้รับบันทึกลงแกลเลอรี ก่อนส่งเอกสารที่อ่อนไหว ให้ตรวจสอบส่วนที่ไม่จำเป็นในภาพ ข้อความในพื้นหลัง และข้อมูลตำแหน่งของไฟล์ด้วย
ไฟล์ในกลุ่มส่วนตัวต่างออกไปอย่างไร?
จำนวนผู้ที่ได้รับอนุญาตให้ถือกุญแจเพิ่มขึ้น Livara อธิบายขอบเขตการปกป้องไฟล์แนบของกลุ่มส่วนตัวที่รองรับในโหมด E2EE ไว้ใน LGS1 ไม่ควรขยายคำกล่าวนี้ไปถึงช่องสาธารณะ สมาชิกคนใดก็ตามที่ได้รับไฟล์อาจเก็บสำเนาไว้ การนำสมาชิกออกหรือหมุนเวียนกุญแจในอนาคตไม่สามารถเรียกสำเนาเดิมของเขากลับคืนได้
รายการตรวจสอบก่อนส่งไฟล์ที่อ่อนไหว
- ตรวจสอบพื้นที่สนทนาและผู้รับอีกครั้ง
- หากตัวตนของผู้ติดต่อมีความสำคัญ ให้ยืนยันลายนิ้วมือกุญแจผ่านช่องทางที่เชื่อถือได้
- ส่งเฉพาะข้อมูลที่จำเป็น ไม่จำเป็นต้องส่งภาพเอกสารทั้งฉบับเสมอไป
- ตกลงกับผู้รับเรื่องการบันทึกลงแกลเลอรี การดาวน์โหลดอัตโนมัติ และการสำรองข้อมูลบนคลาวด์
- อย่าทิ้งไฟล์ที่ถอดรหัสแล้วไว้บนอุปกรณ์ที่ใช้ร่วมกันหรือไม่ได้ล็อก
คำถามที่พบบ่อย
กุญแจเฉพาะไฟล์รับประกันว่าการส่งจะปลอดภัยหรือไม่?
ไม่ ความปลอดภัยของอุปกรณ์ การยืนยันตัวตนผู้รับ และการนำระบบไปใช้อย่างถูกต้องก็จำเป็นเช่นกัน อ่านแบบจำลองภัยคุกคามของ Livara ควบคู่กับข้อกำหนดการเข้ารหัส
รูปภาพในช่องสาธารณะมีการปกป้องแบบเดียวกันหรือไม่?
ตามขอบเขตที่ Livara ประกาศ ช่องต่าง ๆ เป็นสาธารณะและอ่านได้ จึงไม่มีคำมั่นว่าจะรักษาความลับแบบไฟล์แนบส่วนตัวให้กับช่องเหล่านี้
แค่ลิงก์ไฟล์เพียงอย่างเดียวเพียงพอหรือไม่?
ขึ้นอยู่กับการออกแบบบริการ ให้ตรวจสอบลิงก์ กุญแจ และสิทธิ์เข้าถึงแยกกัน การที่ URL ยาวหรือมีลักษณะสุ่มเพียงอย่างเดียวไม่ใช่หลักฐานว่ามี E2EE
