ที่เก็บข้อมูลเข้ารหัสแยกไบต์ของไฟล์ออกจากสิทธิ์ถอดรหัส แต่ผู้รับ เมทาดาทา และสำเนาในเครื่องยังคงเป็นส่วนหนึ่งของโมเดลภัยคุกคาม
ไฟล์แนบที่เข้ารหัสจากต้นทางถึงปลายทางสามารถเก็บบนเซิร์ฟเวอร์ได้โดยไม่ให้เซิร์ฟเวอร์นั้นได้ไฟล์ข้อความชัดเจน การออกแบบทั่วไปเข้ารหัสไฟล์บนอุปกรณ์ผู้ส่งด้วยกุญแจเนื้อหาใหม่ อัปโหลดข้อความเข้ารหัส แล้วส่งกุญแจให้ผู้รับที่ตั้งใจไว้ภายในข้อความเข้ารหัสที่ยืนยันความแท้จริง
การแยกส่วนนี้มีประโยชน์ แต่ “ที่เก็บข้อมูลแบบไม่รู้ข้อมูล” ไม่ใช่ข้อกำหนดที่ครบถ้วน ยังต้องถามว่าระบบจัดการกุญแจ การอ้างอิงไฟล์ ชื่อไฟล์ การควบคุมสิทธิ์เข้าถึง และสำเนาที่ดาวน์โหลดอย่างไร
วงจรชีวิตของไฟล์แนบ
- เตรียมไฟล์ ผู้ส่งเลือกรูปภาพ วิดีโอ หรือเอกสาร การลบเมทาดาทาหรือแปลงรหัสเป็นขั้นตอนแยกต่างหาก การเข้ารหัสอย่างเดียวไม่ได้ลบ EXIF หรือคุณสมบัติเอกสาร
- สร้างวัสดุการเข้ารหัส การพัฒนาที่ปลอดภัยสร้างกุญแจและ nonce ที่จำเป็นตามรูปแบบที่เลือก
- เข้ารหัสก่อนอัปโหลด บริการจัดเก็บได้รับไบต์ที่เข้ารหัสแทนเนื้อหาต้นฉบับ
- ส่งข้อมูลอ้างอิงที่ยืนยันความแท้จริง ข้อความแชตเข้ารหัสบรรทุกข้อมูลที่ผู้รับต้องใช้ เช่น ตำแหน่งไฟล์ กุญแจถอดรหัส และเมทาดาทาที่เกี่ยวข้องกับความครบถ้วน
- ดึงและตรวจสอบ ไคลเอนต์ผู้รับดึงก้อนข้อมูลและตรวจสอบการยืนยันความแท้จริงก่อนถือว่าผลลัพธ์เป็นเนื้อหาที่ถูกต้อง
- จัดการสำเนาในเครื่อง การแสดง ส่งออก แก้ไข หรือบันทึกลงแกลเลอรีอาจสร้างสำเนานอกขอบเขตที่เก็บข้อมูลเข้ารหัสเดิม
กุญแจอาจผ่านโครงสร้างพื้นฐานของผู้ให้บริการรายเดียวกันในซองเข้ารหัส การเรียกสิ่งนี้ว่า “นอกแบนด์” อาจทำให้เข้าใจผิด เพราะเป็นการแยกเชิงตรรกะจากที่เก็บก้อนข้อมูล ไม่จำเป็นต้องส่งผ่านช่องทางสื่อสารอิสระ
การเข้ารหัสแบบยืนยันความแท้จริงเพิ่มอะไร
รูปแบบการเข้ารหัสแบบยืนยันความแท้จริงปกป้องความลับและตรวจพบการเปลี่ยนแปลงที่ไม่ได้รับอนุญาตภายในขอบเขตที่ยืนยัน ข้อกำหนด GCM ของ NIST กำหนดโครงสร้างลักษณะนี้แบบหนึ่งและข้อกำหนดที่ต้องทำ การจัดการกุญแจและ nonce อย่างถูกต้องรวมถึงตรวจผลการยืนยันเป็นสิ่งจำเป็น ชื่ออัลกอริทึมที่ได้รับการยอมรับไม่ได้ทำให้ทุกการพัฒนาปลอดภัย
แอปต้องผูกไฟล์เข้ากับข้อความและบทสนทนาที่ถูกต้องด้วย ก้อนข้อมูลเข้ารหัสที่ถูกต้องเพียงอย่างเดียวไม่ใช่หลักฐานว่ามันเป็นของแชตนี้ ตัวระบุไฟล์ ขนาดที่คาดหมาย ลำดับชิ้นข้อมูล และเมทาดาทาไฟล์แนบต้องมีการออกแบบยืนยันความแท้จริงที่เหมาะสม
บริการจัดเก็บยังอาจรู้อะไร
| ข้อมูล | การเข้ารหัสเนื้อหาอย่างเดียวซ่อนได้หรือไม่? |
|---|---|
| ไบต์ของไฟล์ต้นฉบับ | ออกแบบมาเพื่อซ่อนจากฝ่ายที่ไม่มีกุญแจ |
| ขนาดโดยประมาณหลังเข้ารหัส | โดยปกติไม่ได้ |
| เวลาอัปโหลดและดาวน์โหลด | โดยปกติไม่ได้ |
| บัญชีใดขอไฟล์ | ขึ้นอยู่กับการออกแบบเส้นทางและการควบคุมสิทธิ์ |
| ชื่อไฟล์และคำบรรยาย | ได้เฉพาะเมื่อโปรโตคอลปกป้องสิ่งเหล่านี้ด้วย |
| สำเนาที่ผู้รับบันทึก | ไม่ได้ ผู้รับมีสิทธิ์เข้าถึงข้อความชัดเจนอยู่แล้ว |
การควบคุมสิทธิ์เข้าถึงยังสำคัญแม้ก้อนข้อมูลเข้ารหัสอยู่ มันจำกัดการดาวน์โหลดที่ไม่ต้องการ การใช้งานผิดวัตถุประสงค์ และการเปิดเผยตัวระบุได้ การเข้ารหัสไม่แทนการอนุญาต นโยบายเก็บรักษา หรือความพร้อมใช้งาน
ไฟล์ใหญ่ต้องการมากกว่าคำขวัญ
การออกแบบสำหรับไฟล์ใหญ่อาจส่งข้อมูลเป็นสตรีมหรือแบ่งเป็นชิ้นที่ยืนยันความแท้จริง วิธีนี้ลดการใช้หน่วยความจำได้ แต่ต้องกำหนดหมายเลขชิ้น ความยาวสุดท้าย การลองใหม่ และการจัดการข้อมูลที่ถูกตัด อย่าสร้างตัวเลขประสิทธิภาพหรืออ้างว่าการใส่ไฟล์ในข้อความทำให้ “สถานะแรตเช็ตบวม” อย่างหลีกเลี่ยงไม่ได้ ผลเหล่านั้นขึ้นอยู่กับการพัฒนาระบบ
การทดสอบที่มีประโยชน์ประกอบด้วยไฟล์ที่ถูกต้อง การเปลี่ยนหนึ่งไบต์ การดาวน์โหลดที่ถูกตัด ชิ้นข้อมูลที่สลับลำดับ และความพยายามดึงไฟล์โดยไม่มีสิทธิ์ ทำการทดสอบเหล่านี้เฉพาะในสภาพแวดล้อมทดสอบที่ได้รับอนุญาตและใช้ไฟล์ที่ไม่ละเอียดอ่อน บันทึกว่าไคลเอนต์ปฏิเสธข้อมูลที่ไม่ถูกต้องก่อนเปิดหรือไม่
สิ่งที่ Livara ระบุในเอกสาร
หน้าความปลอดภัยของ Livara อธิบายการเข้ารหัสก่อนอัปโหลด กุญแจสุ่มแยกต่อไฟล์ที่ส่งภายในเซสชันที่ปกป้อง และการปกป้องชื่อไฟล์กับคำบรรยายในบทสนทนาที่ E2EE ทำงาน รวมถึงกลุ่มส่วนตัวที่รองรับ กลุ่มเก่าที่ไม่รองรับอยู่นอกความครอบคลุมนี้อย่างชัดเจน เอกสารแยกบทสนทนาที่ปกป้องออกจากช่องเผยแพร่สาธารณะ สิ่งเหล่านี้เป็นคำกล่าวอ้างของผลิตภัณฑ์ที่มีเอกสาร ไม่ใช่การตรวจประเมินการพัฒนาระบบใหม่ในบทความนี้
โมเดลภัยคุกคาม ยังยอมรับว่าผู้รับหรืออุปกรณ์ที่ถูกเจาะอาจเปิดเผยเนื้อหาที่อ่านได้ ดังนั้นที่เก็บข้อมูลเข้ารหัสจึงรับรองไม่ได้ว่าภาพจะหายจากทุกอุปกรณ์เมื่อลบข้อความแชตของมัน
คำถามก่อนแชร์ไฟล์ละเอียดอ่อน
ตรวจสอบว่าประเภทบทสนทนารองรับ E2EE หรือไม่ ผู้รับที่ตั้งใจไว้ทุกคนเชื่อถือได้หรือไม่ และตัวไฟล์มีเมทาดาทาที่ระบุตัวตนหรือไม่ ตรวจสอบการบันทึกลงแกลเลอรีอัตโนมัติและการสำรองรูปภาพบนคลาวด์แยกกัน สำหรับเอกสาร ให้พิจารณาว่าควรลบความคิดเห็น ประวัติการแก้ไข หรือคุณสมบัติที่ฝังไว้ก่อนส่งหรือไม่
สุดท้าย ทำความเข้าใจการลบและการกู้คืน การลบก้อนข้อมูลบนเซิร์ฟเวอร์หยุดการดาวน์โหลดในอนาคตได้ แต่เรียกสำเนาที่ผู้รับมีอยู่แล้วคืนไม่ได้ การสูญเสียกุญแจที่จำเป็นอาจทำให้ไฟล์เข้ารหัสที่ยังเหลืออยู่ไม่สามารถอ่านได้ การออกแบบไฟล์แนบที่ดีอธิบายผลทั้งสองอย่างตรงไปตรงมา
