การเข้ารหัสแบบ End-to-End คืออะไร? ปกป้องรูปภาพของคุณอย่างไร
การเข้ารหัสแบบต้นทางถึงปลายทางกันเนื้อหารูปภาพที่อ่านได้และคีย์เนื้อหาแบบข้อความธรรมดาไว้ให้พ้นจากผู้ให้บริการจัดเก็บข้อมูล
การเข้ารหัสแบบต้นทางถึงปลายทาง (E2EE) คือแบบจำลองความปลอดภัยที่ข้อความธรรมดาถูกเข้ารหัสบนอุปกรณ์ปลายทางที่ได้รับอนุญาตเครื่องหนึ่ง และถอดรหัสบนอีกเครื่องหนึ่ง ผู้ให้บริการจัดเก็บหรือรับส่งข้อมูลไม่ได้ถือคีย์เนื้อหาแบบข้อความธรรมดา ขอบเขตนี้ปกป้องเนื้อหาจากการอ่านโดยตรงฝั่งเซิร์ฟเวอร์ แต่ไม่ได้ซ่อนข้อมูลเมตาทุกรายการ และไม่ได้ปกป้องอุปกรณ์ปลายทางที่ถูกเจาะ ข้อมูลรับรองสำหรับการกู้คืน ผู้รับที่แชร์ด้วย หรือการอัปเดตแอปไคลเอ็นต์ที่เป็นอันตราย
สำหรับการจัดเก็บรูปภาพ การเข้ารหัสแบบต้นทางถึงปลายทางหมายความว่าโทรศัพท์ของคุณเข้ารหัสเนื้อหารูปภาพก่อนอัปโหลด และคลาวด์เก็บไซเฟอร์เท็กซ์แทนรูปภาพที่อ่านได้ การถอดรหัสต้องใช้คีย์ที่ได้จากอุปกรณ์ที่ได้รับอนุญาตหรือเส้นทางการกู้คืน ขนาดไฟล์ เวลา ข้อมูลบัญชี ความสัมพันธ์ในการแชร์ และข้อมูลเมตาอื่นๆ อาจยังมองเห็นได้ คู่มือนี้อธิบายขอบเขตดังกล่าวและเปรียบเทียบรูปแบบบริการที่พบบ่อย
วิธีทำงานของการเข้ารหัสแบบ End-to-End
กลไกหลักมีสามขั้นตอน: การสร้างกุญแจ การเข้ารหัส และการถอดรหัส
การสร้างกุญแจ
อุปกรณ์ของผู้ใช้สร้างกุญแจเข้ารหัส ในการเข้ารหัสแบบ symmetric (เช่น AES-256) กุญแจเดียวกันเข้ารหัสและถอดรหัส ในการเข้ารหัสแบบ asymmetric (เช่น RSA) กุญแจสาธารณะเข้ารหัสและกุญแจส่วนตัวถอดรหัส ระบบ E2EE หลายระบบรวมทั้งสองแบบ: การเข้ารหัสแบบ asymmetric แลกเปลี่ยน session key แบบ symmetric ซึ่งจัดการการเข้ารหัสจำนวนมาก
แอปห้องนิรภัยรูปภาพใช้การออกแบบการจัดการคีย์หลายแบบ บางแอปสร้างคีย์ไฟล์จากรหัสผ่านโดยตรง ส่วนการออกแบบแบบหลายชั้นที่แข็งแกร่งกว่าสามารถใช้คีย์ปลดล็อกที่สร้างจากข้อมูลรับรองเพื่อห่อหุ้มคีย์ไฟล์แบบสุ่ม Vaultaire ใช้ PBKDF2-HMAC-SHA512 สร้างคีย์ห้องนิรภัยขนาด 256 บิตจากรูปแบบ 5x5 และซอลต์ระดับอุปกรณ์ คีย์ห้องนิรภัยนั้นรับรองความถูกต้องของดัชนีที่เข้ารหัสและแกะมาสเตอร์คีย์แบบสุ่มแยกต่างหากที่ใช้เข้ารหัสไฟล์
การเข้ารหัส
ข้อความธรรมดา (รูปภาพของคุณ) ถูกแปลงเป็นข้อความรหัสโดยใช้กุญแจเข้ารหัสและอัลกอริทึมการเข้ารหัส AES-256-GCM เป็น symmetric cipher ที่ใช้กันอย่างแพร่หลายที่สุดสำหรับวัตถุประสงค์นี้ GCM (Galois/Counter Mode) ให้การเข้ารหัสแบบ authenticated — เข้ารหัสข้อมูลและสร้างแท็กการพิสูจน์ตัวตนที่ตรวจจับการดัดแปลงใด ๆ ไฟล์แต่ละไฟล์ได้รับ initialization vector (IV) ที่ไม่ซ้ำกัน ทำให้ไฟล์ที่เหมือนกันสร้างข้อความรหัสที่แตกต่างกัน
การถอดรหัส
อุปกรณ์ของผู้รับใช้กุญแจเดียวกัน (symmetric) หรือกุญแจส่วนตัวที่ตรงกัน (asymmetric) เพื่อย้อนกลับการแปลง โดยไม่มีกุญแจที่ถูกต้อง ข้อความรหัสแยกแยะจากข้อมูลสุ่มไม่ได้ ไม่มีทางลัดทางคณิตศาสตร์ AES-256 มีกุญแจที่เป็นไปได้ 2^256 — มากกว่าจำนวนอะตอมที่ประมาณในจักรวาลที่สังเกตได้
การเข้ารหัสแบบ End-to-End เทียบกับโมเดลการเข้ารหัสอื่น
ไม่ใช่การเข้ารหัสทั้งหมดที่เป็น end-to-end ความแตกต่างกำหนดว่าใครสามารถเข้าถึงข้อมูลของคุณได้
การเข้ารหัสระหว่างการรับส่ง (TLS/SSL)
ข้อมูลถูกเข้ารหัสระหว่างอุปกรณ์ของคุณและเซิร์ฟเวอร์ เซิร์ฟเวอร์ถอดรหัสเมื่อรับได้ ซึ่งป้องกันการดักฟังระหว่างการรับส่งแต่ทำให้ข้อมูลอ่านได้บนเซิร์ฟเวอร์ บริการคลาวด์รายใหญ่ทุกรายใช้การเข้ารหัสระหว่างการรับส่ง เป็นพื้นฐาน ไม่ใช่มาตรฐาน
การเข้ารหัสขณะจัดเก็บ (ฝั่งเซิร์ฟเวอร์)
เซิร์ฟเวอร์เข้ารหัสข้อมูลที่จัดเก็บโดยใช้กุญแจที่เซิร์ฟเวอร์จัดการ ซึ่งป้องกันการขโมยทางกายภาพของฮาร์ดแวร์เซิร์ฟเวอร์แต่ไม่ป้องกันจากผู้ให้บริการเอง พนักงานของพวกเขา หรือคำร้องทางกฎหมายที่ส่งถึงผู้ให้บริการ iCloud, Google Drive และ Dropbox ทั้งหมดใช้การเข้ารหัสฝั่งเซิร์ฟเวอร์ขณะจัดเก็บ ผู้ให้บริการถือกุญแจ
การเข้ารหัสแบบ End-to-End
ข้อมูลถูกเข้ารหัสบนอุปกรณ์ปลายทางที่ได้รับอนุญาตก่อนที่ผู้ให้บริการจัดเก็บข้อมูลจะได้รับ การออกแบบที่ดีจะกันคีย์เนื้อหาแบบข้อความธรรมดาไว้นอกการดูแลตามปกติฝั่งเซิร์ฟเวอร์ของผู้ให้บริการ การเจาะเฉพาะที่เก็บข้อมูลหรือคำสั่งทางกฎหมายให้ส่งเนื้อหาที่จัดเก็บไว้จึงได้แค่ไซเฟอร์เท็กซ์ ไม่ใช่รูปภาพที่อ่านได้ ผู้ให้บริการอาจยังส่งมอบไซเฟอร์เท็กซ์และข้อมูลเมตา แจกจ่ายซอฟต์แวร์ไคลเอ็นต์ หรือดำเนินระบบกู้คืนและระบบแชร์ ซึ่งต้องนับรวมไว้ในแบบจำลองภัยคุกคาม
| โมเดลการเข้ารหัส | ใครถือกุญแจ | ผู้ให้บริการอ่านข้อมูลได้? | ป้องกันจากผู้ให้บริการ? |
|---|---|---|---|
| ระหว่างการรับส่งเท่านั้น (TLS) | เซิร์ฟเวอร์ | ใช่ | ไม่ |
| ขณะจัดเก็บ (ฝั่งเซิร์ฟเวอร์) | เซิร์ฟเวอร์ | ใช่ | ไม่ |
| End-to-end | อุปกรณ์ปลายทางที่ได้รับอนุญาตหรือผู้ถือข้อมูลกู้คืน | ไม่ได้จากไซเฟอร์เท็กซ์ที่จัดเก็บไว้เพียงอย่างเดียว | ปกป้องเนื้อหาจากคีย์จัดเก็บที่ผู้ให้บริการถือ |
| การเข้ารหัสฝั่งไคลเอ็นต์ที่ผู้ให้บริการมองไม่เห็นเนื้อหา | แอปไคลเอ็นต์และเส้นทางการกู้คืนที่มีเอกสารระบุไว้ | เข้าถึงเนื้อหาแบบข้อความธรรมดาไม่ได้ตามการออกแบบ | ปกป้องเนื้อหา แต่ข้อมูลเมตาและความไว้วางใจในแอปไคลเอ็นต์ยังคงอยู่ |
วิธีที่บริการที่เก็บรูปภาพจัดการกับการเข้ารหัส
โมเดลการเข้ารหัสแตกต่างกันอย่างมีนัยสำคัญในบริการที่เก็บรูปภาพต่าง ๆ บางบริการโฆษณา "การเข้ารหัส" โดยไม่ระบุโมเดล ซึ่งอาจทำให้ผู้ใช้เข้าใจผิดว่ารูปภาพของตนเป็น E2EE ทั้งที่ไม่ใช่
รูปภาพบน iCloud
Apple ใช้การเข้ารหัสระหว่างการรับส่งและขณะจัดเก็บ Apple ถือกุญแจเข้ารหัสตามค่าเริ่มต้น ด้วยคำร้องทางกฎหมายที่ถูกต้อง Apple สามารถให้ข้อมูล รูปภาพบน iCloud ได้ ข้อยกเว้น: การปกป้องข้อมูลขั้นสูง (ADP) ของ Apple ที่มีให้ตั้งแต่ธันวาคม 2022 เพิ่มการเข้ารหัสแบบ end-to-end ให้กับรูปภาพบน iCloud ADP ต้องเปิดใช้งานอย่างชัดเจนในการตั้งค่า เมื่อเปิดใช้แล้ว Apple ไม่สามารถเข้าถึงข้อมูล รูปภาพบน iCloud ได้ ผู้ใช้ส่วนใหญ่ยังไม่ได้เปิดใช้ ADP
Google Photos
Google ใช้การเข้ารหัสระหว่างการรับส่งและขณะจัดเก็บด้วยกุญแจฝั่งเซิร์ฟเวอร์ Google ถือกุญแจเข้ารหัสสำหรับข้อมูล Google Photos ทั้งหมด รวมถึงเนื้อหาใน Locked Folder Google สามารถปฏิบัติตามคำร้องข้อมูลทางกฎหมายได้ Google ไม่เสนอตัวเลือกการเข้ารหัสแบบ end-to-end สำหรับ Google Photos
Dropbox
การเข้ารหัสระหว่างการรับส่ง (TLS 1.2+) และขณะจัดเก็บ (AES-256 ด้วยกุญแจที่ Dropbox จัดการ) Dropbox ถือกุญแจและสามารถเข้าถึงไฟล์ของคุณ Dropbox ประสบการละเมิดข้อมูล (2012, 68 ล้านบัญชี) Dropbox Vault (คุณสมบัติแบบชำระเงิน) เพิ่มการป้องกัน PIN แต่ไม่ใช่การเข้ารหัสแบบ end-to-end
OneDrive
Microsoft ใช้การเข้ารหัสระหว่างการรับส่งและขณะจัดเก็บด้วยกุญแจที่ Microsoft จัดการ Microsoft ถือกุญแจ OneDrive Personal Vault เพิ่มการยืนยันตัวตน (2FA) แต่ไม่ใช่การเข้ารหัสแบบ end-to-end — Microsoft ยังสามารถเข้าถึงข้อมูลได้ สำหรับลูกค้าองค์กร กุญแจที่ลูกค้าจัดการมีให้
Vaultaire
การเข้ารหัสฝั่งไคลเอ็นต์ที่ไม่มีคีย์อยู่กับผู้ให้บริการ Vaultaire เข้ารหัสรูปภาพและข้อมูลเมตาบนอุปกรณ์ด้วย AES-256-GCM ก่อนอัปโหลดขึ้นคลาวด์ มาสเตอร์คีย์แบบสุ่มเข้ารหัสข้อมูลห้องนิรภัย คีย์ห้องนิรภัยในเครื่องที่สร้างจากรูปแบบของผู้ใช้และซอลต์ของอุปกรณ์ห่อหุ้มมาสเตอร์คีย์นั้น ส่วนคีย์สำรองแยกต่างหากที่สร้างจากรูปแบบปกป้องบันทึกการสำรองข้อมูล CloudKit แบบส่วนตัว Vaultaire ไม่ได้ดำเนินเซิร์ฟเวอร์เนื้อหาหรือรับคีย์เหล่านั้น จึงเปลี่ยนบันทึก CloudKit ให้เป็นข้อความธรรมดาไม่ได้ ตัวแอป iOS และอุปกรณ์ที่ปลดล็อกอยู่ยังอยู่ภายในขอบเขตความไว้วางใจ และคำขอทางกฎหมายยังได้รับข้อมูลเมตาของบัญชีหรือบริการที่ผู้ให้บริการที่เกี่ยวข้องถือไว้ได้
| บริการ | การเข้ารหัสระหว่างการรับส่ง | การเข้ารหัสขณะจัดเก็บ | การเข้ารหัสแบบ End-to-End | ผู้ให้บริการเข้าถึงได้ |
|---|---|---|---|---|
| รูปภาพบน iCloud (ค่าเริ่มต้น) | ใช่ | ใช่ (กุญแจ Apple) | ไม่ | ใช่ |
| รูปภาพบน iCloud (เปิดใช้ ADP) | ใช่ | ใช่ | ใช่ | ไม่ |
| Google Photos | ใช่ | ใช่ (กุญแจ Google) | ไม่ | ใช่ |
| Dropbox | ใช่ | ใช่ (กุญแจ Dropbox) | ไม่ | ใช่ |
| OneDrive | ใช่ | ใช่ (กุญแจ Microsoft) | ไม่ | ใช่ |
| Vaultaire | ใช่ | ใช่ | การสำรองข้อมูลที่เข้ารหัสฝั่งไคลเอ็นต์ เปิดตามค่าเริ่มต้นและปิดได้ | ไม่มีคีย์เนื้อหาแบบข้อความธรรมดา แต่ข้อมูลเมตาของ CloudKit ยังคงอยู่ |
สาเหตุที่การเข้ารหัสแบบ End-to-End มีความสำคัญต่อรูปภาพ
รูปภาพเป็นข้อมูลที่ละเอียดอ่อนเป็นพิเศษ มีใบหน้า ตำแหน่ง (ข้อมูลเมตา GPS) เวลา และบันทึกภาพของช่วงเวลาส่วนตัว การละเมิดคลังรูปภาพของคุณเปิดเผยข้อมูลส่วนบุคคลมากกว่าข้อมูลประเภทอื่นเกือบทุกประเภท
การละเมิดข้อมูล
เมื่อผู้ให้บริการจัดเก็บรูปภาพด้วยคีย์ฝั่งเซิร์ฟเวอร์ การเจาะทั้งที่เก็บข้อมูลและเส้นทางการจัดการคีย์อาจเปิดเผยเนื้อหาที่อ่านได้ เมื่อใช้ E2EE ที่ออกแบบดี การเจาะเฉพาะที่เก็บข้อมูลจะได้แค่ไซเฟอร์เท็กซ์และข้อมูลเมตาที่บริการเก็บไว้ การเจาะอุปกรณ์ปลายทาง ข้อมูลรับรองสำหรับการกู้คืนที่ถูกขโมย ซอฟต์แวร์ไคลเอ็นต์ที่เป็นอันตราย และข้อบกพร่องของบริการคีย์ ยังเป็นเส้นทางแยกที่นำไปสู่ข้อความธรรมดาได้
การเข้าถึงทางกฎหมายและรัฐบาล
ผู้ให้บริการอาจถูกบังคับให้ส่งมอบบันทึกที่ตนมีอยู่ เมื่อใช้ E2EE สิ่งนั้นอาจรวมถึงไซเฟอร์เท็กซ์ ข้อมูลบัญชี บันทึกการเข้าถึง ขนาดบันทึก เวลา และข้อมูลเมตาของการแชร์ แทนเนื้อหารูปภาพที่อ่านได้ ส่วนคำสั่งนั้นจะเข้าถึงอุปกรณ์ วิธีกู้คืน ผู้รับ หรือพฤติกรรมของแอปไคลเอ็นต์ในอนาคตได้หรือไม่ เป็นคำถามทางกฎหมายและทางเทคนิคอีกข้อหนึ่ง
การเข้าถึงภายใน
พนักงานหรือผู้โจมตีที่เข้าถึงคีย์จัดเก็บที่ผู้ให้บริการจัดการได้ อาจเข้าถึงเนื้อหาที่เข้ารหัสฝั่งเซิร์ฟเวอร์ได้ E2EE ตัดเส้นทางผ่านคีย์จัดเก็บโดยตรงนั้นออก เมื่อผู้ให้บริการไม่มีคีย์เนื้อหาแบบข้อความธรรมดา แต่ไม่ได้ทำให้การละเมิดจากคนในเป็นไปไม่ได้โดยสิ้นเชิง เพราะผู้ให้บริการอาจควบคุมการแจกจ่ายแอปไคลเอ็นต์ สถานะบัญชี ข้อมูลเมตา การแชร์ หรือส่วนประกอบของการกู้คืน
การป้องกันข้อมูลเมตา
การใช้งาน E2EE บางแบบเข้ารหัสเฉพาะเนื้อหาไฟล์ และปล่อยข้อมูลเมตา เช่น ชื่อไฟล์และวันที่ไว้โดยไม่ป้องกัน Vaultaire ปกป้องส่วนหัวของไฟล์ ประเภท MIME ดัชนี ภาพขนาดย่อ และข้อมูลเมตาอื่นๆ ของห้องนิรภัยด้วยการเข้ารหัสแบบรับรองความถูกต้อง AES-256-GCM ความยาวของไซเฟอร์เท็กซ์ที่จัดเก็บไว้และจำนวนไฟล์ดัชนีที่เข้ารหัสยังเปิดเผยข้อมูลเชิงโครงสร้างให้คนที่เข้าถึงคอนเทนเนอร์ของแอปได้
ความเข้าใจผิดทั่วไปเกี่ยวกับ E2EE
"ที่เก็บคลาวด์ของฉันเข้ารหัส ดังนั้นรูปภาพของฉันปลอดภัย" การเข้ารหัสฝั่งเซิร์ฟเวอร์ป้องกันการละเมิดภายนอกของฮาร์ดแวร์เซิร์ฟเวอร์ ไม่ป้องกันจากผู้ให้บริการเอง คำร้องทางกฎหมาย หรือภัยคุกคามจากคนใน ผู้ให้บริการถือกุญแจ
"HTTPS หมายความว่ารูปภาพของฉันเข้ารหัสแบบ end-to-end" HTTPS (TLS) เข้ารหัสข้อมูลระหว่างการรับส่งระหว่างอุปกรณ์ของคุณและเซิร์ฟเวอร์ เมื่อข้อมูลมาถึงเซิร์ฟเวอร์ ก็ถูกถอดรหัส HTTPS เป็นการเข้ารหัสท่อ ไม่ใช่การเข้ารหัสข้อมูล
"การเข้ารหัสแบบ end-to-end หมายความว่าไม่มีใครเห็นรูปภาพของฉันได้เลย" E2EE หมายความว่าไม่มีใครที่ไม่มีกุญแจสามารถเห็นรูปภาพของคุณได้ ถ้าใครมีรหัสผ่านหรือกุญแจของคุณ พวกเขาสามารถถอดรหัสข้อมูลได้ การจัดการกุญแจและรหัสผ่านที่แข็งแกร่งยังคงสำคัญ
"Apple/Google ไม่สามารถเห็นรูปภาพของฉัน" ตามค่าเริ่มต้น บริษัททั้งสองถือกุญแจเข้ารหัสสำหรับรูปภาพที่จัดเก็บบนคลาวด์ Apple เสนอ การปกป้องข้อมูลขั้นสูง เป็นตัวเลือกเสริม Google ไม่เสนอตัวเลือก E2EE สำหรับ Google Photos เลย
วิธีที่ Vaultaire ใช้การเข้ารหัสแบบ End-to-End
Vaultaire ใช้แนวทาง E2EE แบบหลายชั้น:
- AES-256-GCM เข้ารหัสเนื้อหาไฟล์ทั้งหมด ไฟล์แต่ละไฟล์ได้รับ initialization vector ที่ไม่ซ้ำกัน การเข้ารหัสแบบ authenticated ตรวจจับการดัดแปลง
- PBKDF2 ด้วย HMAC-SHA512 สร้างคีย์ห้องนิรภัยในเครื่องจากรูปแบบที่ผู้ใช้วาดและซอลต์ของอุปกรณ์ ค่าความยากในการคำนวณทำให้การเดาแบบออฟไลน์แต่ละครั้งมีต้นทุนสูงขึ้น โดยไม่ได้เพิ่มเอนโทรปีให้รูปแบบ คีย์ห้องนิรภัยนั้นรับรองความถูกต้องของดัชนีที่เข้ารหัสและแกะมาสเตอร์คีย์แบบสุ่มที่ใช้กับข้อมูลไฟล์
- AES-256-GCM สำหรับข้อมูลเมตา ปกป้องชื่อไฟล์ วันที่ ขนาดภาพ ดัชนี และภาพขนาดย่อด้วยการเข้ารหัสแบบรับรองความถูกต้อง
- iOS Keychain และ Data Protection ปกป้องซอลต์ของอุปกรณ์และฐานข้อมูลกู้คืนที่เข้ารหัส การทำงานของ AES-GCM และคีย์สมมาตรที่ใช้งานอยู่ยังอยู่ในโปรเซสของแอปขณะที่ห้องนิรภัยเปิดอยู่
- การแยกคีย์ออกจากผู้ให้บริการ หมายความว่า Wraxle ไม่ได้รับคีย์ห้องนิรภัย มาสเตอร์คีย์ คีย์สำรอง หรือคีย์กู้คืนแบบข้อความธรรมดา การสำรองข้อมูล CloudKit (เปิดอยู่ตามค่าเริ่มต้น) การซิงค์ และการแชร์จัดเก็บบันทึกไซเฟอร์เท็กซ์และซองคีย์ที่เข้ารหัส ขณะที่ Apple ยังสังเกตข้อมูลเมตาของบริการได้ Vaultaire ไม่ต้องใช้บัญชีระบุตัวตนของ Vaultaire
Vaultaire เก็บข้อมูลกู้คืน รวมถึงรูปแบบ ไว้ในฐานข้อมูลที่เข้ารหัสด้วย AES-GCM ซึ่งเก็บอยู่ใน iOS Keychain ข้อมูลนี้ไม่ได้เขียนลงไฟล์ข้อความธรรมดาหรือส่งไปยังบริการบัญชีของ Vaultaire หากไม่มีรูปแบบ วลีกู้คืน หรืออุปกรณ์ที่ปลดล็อกอยู่แล้วเหลือให้ใช้ Vaultaire ไม่มีคีย์กู้คืนฝั่งผู้ให้บริการที่จะคืนการเข้าถึงได้
คำถามที่พบบ่อย
การเข้ารหัสแบบ end-to-end ถูกกฎหมายไหม?
การปฏิบัติทางกฎหมายต่อการเข้ารหัส การบังคับให้เปิดเผยข้อมูล และบริการที่เข้ารหัส แตกต่างกันไปตามเขตอำนาจศาลและอาจเปลี่ยนแปลงได้ คู่มือนี้อธิบายแบบจำลองทางเทคนิค ไม่ใช่คำแนะนำทางกฎหมาย ตรวจสอบกฎหมายท้องถิ่นฉบับปัจจุบัน หากการใช้งานของคุณเกี่ยวข้องกับการตรวจค้นที่ชายแดน คำสั่งศาล เอกสารที่อยู่ภายใต้การกำกับดูแล หรือสถานการณ์เสี่ยงสูงอื่นๆ
หน่วยงานกฎหมายสามารถทำลายการเข้ารหัสแบบ end-to-end ได้ไหม?
การโจมตีแทบไม่ต้องค้นหาคีย์ AES-256 ทั้งหมด ผู้ตรวจสอบอาจมุ่งเป้าไปที่รหัสผ่านหรือรูปแบบที่อ่อนแอ อุปกรณ์ปลายทางที่ปลดล็อกอยู่ หน่วยความจำ วลีกู้คืน ผู้รับ ข้อมูลสำรอง หรือข้อบกพร่องในการพัฒนา AES-256-GCM ที่พัฒนาอย่างถูกต้องพร้อมคีย์สุ่มที่มีเอนโทรปีสูงถูกออกแบบให้ต้านทานการค้นหาคีย์โดยตรง แต่นั่นเป็นเพียงส่วนหนึ่งของระบบ
ความแตกต่างระหว่าง E2EE และการเข้ารหัสแบบ zero-knowledge คืออะไร?
E2EE อธิบายว่าการเข้ารหัสและถอดรหัสข้อความธรรมดาเกิดขึ้นที่ใด และใครถือคีย์เนื้อหาที่ใช้งานได้ "Zero-Knowledge" มักใช้ในการตลาดของผลิตภัณฑ์สำหรับการเข้ารหัสที่ผู้ให้บริการมองไม่เห็นเนื้อหา แต่ไม่ควรตีความตามตัวอักษร เพราะบริการอาจไม่มีคีย์แบบข้อความธรรมดา แต่ยังเห็นไซเฟอร์เท็กซ์ ข้อมูลบัญชี ขนาด เวลา ความสัมพันธ์ในการแชร์ และข้อมูลเมตาอื่นๆ ให้ประเมินเส้นทางของคีย์และการกู้คืนที่มีเอกสารระบุไว้ แทนการดูแค่ป้ายกำกับ
การเข้ารหัสแบบ end-to-end ทำให้โทรศัพท์ช้าลงไหม?
อุปกรณ์สมัยใหม่ประมวลผล AES-256 ได้อย่างมีประสิทธิภาพด้วยการเร่งความเร็วด้วยฮาร์ดแวร์ผ่านไลบรารีการเข้ารหัสของระบบ บน iPhone นั้น Vaultaire ทำงาน AES-GCM ในโปรเซสของแอปผ่าน CryptoKit API สาธารณะของ Secure Enclave ของ Apple ไม่ใช่เอนจิน AES-GCM ทั่วไปสำหรับเข้ารหัสไฟล์ ภาระของการเข้ารหัสและถอดรหัสขึ้นอยู่กับขนาดไฟล์และอุปกรณ์ แต่ออกแบบมาไม่ให้รบกวนการใช้งานตามปกติ
จะเกิดอะไรขึ้นถ้าฉันทำกุญแจเข้ารหัสหาย?
หากสูญเสียเส้นทางการถอดรหัสและการกู้คืนที่ใช้งานได้ทั้งหมด ข้อมูลที่เข้ารหัสจะกู้คืนไม่ได้ ระบบ E2EE จำนวนมากจึงใช้วลีกู้คืน อุปกรณ์ที่เชื่อถือได้ ผู้ติดต่อสำหรับกู้คืน ชุดข้อมูลฉุกเฉิน หรือซองคีย์ที่เข้ารหัส กลไกเหล่านี้รักษาการเข้าถึงไว้ แต่แต่ละกลไกก็กลายเป็นส่วนหนึ่งของแบบจำลองความปลอดภัยด้วย
สรุป
การเข้ารหัสแบบต้นทางถึงปลายทางตัดเส้นทางคีย์แบบข้อความธรรมดาของผู้ให้บริการจัดเก็บข้อมูลออกได้ เมื่อการเข้ารหัสเกิดขึ้นบนอุปกรณ์ปลายทางที่ได้รับอนุญาตก่อนอัปโหลด นั่นคือการป้องกันที่มีความหมาย ไม่ใช่การรับประกันทั้งระบบ ตรวจสอบผู้ถือคีย์เนื้อหา การกู้คืน ข้อมูลเมตา การอัปเดตแอปไคลเอ็นต์ ความปลอดภัยของอุปกรณ์ปลายทาง และการแชร์ ก่อนไว้วางใจบริการใดด้วยรูปภาพส่วนตัว
Vaultaire ใช้การเข้ารหัสฝั่งไคลเอ็นต์บน iOS รูปภาพและข้อมูลเมตาของห้องนิรภัยของคุณถูกเข้ารหัสบนอุปกรณ์ด้วย AES-256-GCM ก่อนสำรองข้อมูลหรือซิงค์ Vaultaire ไม่ได้รับคีย์ถอดรหัส และไม่ได้ดำเนินเซิร์ฟเวอร์ที่เปลี่ยนบันทึกที่เข้ารหัสเหล่านั้นกลับเป็นรูปภาพของคุณได้ ขอบเขตฝั่งผู้ให้บริการนี้ไม่ได้ทำให้ iPhone ที่ถูกเจาะหรือปลดล็อกอยู่กลายเป็นอุปกรณ์ที่ไว้วางใจได้